Toto je starší verze dokumentu!

Rozšiřující znalostní báze

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.)

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

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

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

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

Pohled na ohlašovatele a vykonavatele agendy

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

Základní povinnosti ohlašovatele agendy

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

Základními povinnostmi ohlašovatele jsou:

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

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

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

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

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

Cizinecký informační systém

Cizinecký informační systém (také jako "CIS") je spravován Policií České republiky a Ministerstvem vnitra a obsahuje údaje o cizincích s trvalým nebo dlouhodobým pobytem, občanech EU, azylantech, tzv. jiných fyzických osobách

do CIS jsou zapisovány údaje:

  • příjmení, jméno, popřípadě jména, adresa místa pobytu, datum, místo a okres narození, u narozeného v cizině datum, místo a stát (Policie České republiky)
  • datum, místo a okres úmrtí, u zemřelého v cizině údajů datum úmrtí, místo a stát. U rozhodnutí soudu o prohlášení za mrtvého se vede v rozhodnutí uvedený den smrti nebo den, který nepřežil a právní moc tohoto rozhodnutí (matriční úřad)
  • státní občanství, popřípadě více státních občanství
  • čísla elektronicky čitelných identifikačních dokladů - průkaz o povolení k pobytu (Policie České republiky)
Agendový informační systém cizinců

Agendový informační systém cizinců (také jako "AISC") je zrcadlem Cizineckého informačního systému, který slouží k editaci a poskytování údajů do základních registrů. Hlavním důvodem rozdělení CIS a AISC je bezpečnost a nutnost oddělit vnitřní a vnější prostředí Policie ČR.

CzechPOINT

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

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

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

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

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

Služby CzechPOINT

Pro zobrazení seznamu klikněte

Pro zobrazení seznamu klikněte

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

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

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

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

Pohled na univerzální kontaktní místo

Editorské agendové informační systémy

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

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

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

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

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

eGovernment 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.

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.

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 není momentálně k dispozici z důvodu probíhajících prací na jeho aktualizaci. Děkujeme za pochopení.
{{url>https://app.powerbi.com/view?r=eyJrIjoiOTNiOGM3NzUtMzRhOC00NjUzLWI4MGYtZmZjMTY4MzQ2NjM0IiwidCI6IjFkYjQxZDZmLTFmMzctNDZkYi1iZDNlLWM0ODNhYmI4MTA1ZCIsImMiOjh9 100%,1000}}

Pravidla eGovernment cloudu

Přístup správců ISVS k eGC

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

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

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

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

Publikování portálu OVM

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

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

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

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

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

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

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

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

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

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

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

V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami G1:gsbCtiData a G11:gsbZapisData pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí ORG identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby G1:gsbCtiData či G11:gsbZapisData zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.

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

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

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

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

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

  • Údaje jsou ohlášeny v registru práv a povinností jako údaje, které agenda zpracovává na základě zákonného zmocnění
  • Údaj musí být vedený v AIS
  • U údaje je jasné, jak vznikl, kdo je zodpovědný za jeho zápis, změny a správu, v jakém AIS je veden a jakým způsobem může být změněn či zrušen.
  • Poskytovatelem údaje je vždy správce AIS, v němž je údaj veden a evidován.
  • Údaj je vždy vázán na subjekt práva, či objekt práva v ZR.
  • Bude umožněno subjektu práva si pořídit výpis údajů jako výpis z informačního systému veřejné správy.
  • Důrazně doporučujeme používat služby pouze v synchronním režimu – každé volání je nezávislé na ostatních a není třeba čekat a serializovat
  • Využívat volání po více vláknech a tím dosáhnout dostatečnou průchodnost i na velký počet požadavků

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

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

Informace k informačnímu systému sdílení údajů jsou k dispozici na stránkách SZR ČR včetně dokumentů:

Způsob komunikace mezi čtenáři a publikátory

Čtenář čte od publikátora

typ akce popis
evidence vyměňovaných údajů – agenda publikátora údaje jsou evidovány v agendě publikátora
udělení oprávnění v RPP publikátor dává čtenáři souhlas (typicky v agendě čtenáře) pro čtení (R, Rh, Rn, Rhn)
evidence a atributy vyměňovaných údajů – agenda - čtenářečtené údaje budou evidovány i v agendě čtenáře jako agendové přebírané a budou odkazovat na zdroj (údaj publikátora)
vytvoření kontextu publikátor vytváří kontext pro eGSB
kód údaje v kontextu v kontextu eGSB bude v komentáři kód údaje z agendy publikátora

 

Čtenář zapisuje údaj do agendy publikátora

typ akce popis
evidence vyměňovaných údajů – agenda publikátora údaje jsou evidovány v agendě publikátora
udělení oprávnění v RPP publikátor dává čtenáři souhlas pro zápis (W)
evidence a atributy vyměňovaných údajů – agenda - čtenářev agendě čtenáře (zapisovatele) budou zapisované údaje evidovány jako agendové přebírané a budou odkazovat na zdroj (údaj publikátora)
vytvoření kontextu publikátor vytváří kontext pro eGSB
kód údaje v kontextu v kontextu eGSB bude v komentáři kód údaje z agendy publikátora

Seznam služeb eGSB / ISSS

KódPodrobný popis službyVerze
G1 gsbCtiData 1.03
G2 gsbCtiZmeny 1.01
G3 gsbVlozOdpoved 1.02
G4 gsbVlozSoubor 1.04
G5 gsbCtiSoubor 1.01
G6 gsbVypisFronty 1.01
G7 gsbOdpovedZFronty 1.01
G8 gsbSmazatFrontu 1.01
G9 gsbProbe 1.01
G10 gsbCtiKontexty 1.01
G11 gsbZapisData 1.04
K1 katCtiSluzby 1.01
K2 katCtiDetailSluzby 1.01
K3 katCtiPrilohu 1.01
K4 katCtiEndpoint 1.01

Kontext eGSB / ISSS

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

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

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

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

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

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

Konceptuální modely kontextů

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

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

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

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

Seznam kontextů

Detailní seznam kontextů je dostupný na adrese https://egsbkatalog.cms2.cz/. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.

PořadíKód Název
1 A1029.1 Pojištěnec
2 A1029.2 Osoba samostatně výdělečně činná
3 A1029.3 Zaměstnavatel
4 A1029.4 Územně organizační jednotka
5 A1041.2001 Osoba - doklady
6 A1041.4001 Provozovatel plavidla - plavidla
7 A1041.4004 Vlastník plavidla - plavidla
8 A1041.9001 Osoba - doklady, plavidla
9 A1046.1 Řidič - podklady pro podání žádosti o řidičský průkaz
10 A1046.2 Řidič - podání žádosti o řidičský průkaz
11 A1046.2001 Osoba - zkoušky řidiči
12 A1046.3 Řidič - registrace k notifikacím změn bodového hodnocení
13 A1046.4 Řidič - osvědčení o digitálním úkonu
14 A1046.RidicRozsirene Řidič - rozšířené údaje
15 A1046.RidicZakladni Řidič - základní údaje
16 A1046.RidicZakladni Řidič - základní údaje
17 A1061.1 NBU Avizace
18 A120.1 Předání a zneplatnění ÚZ
19 A121.1 Přehled o údajích autentizované osoby
20 A121.2 Výpis údajů podnikatelského subjektu
21 A124.1 ISKN - Evidence práv pro osobu
22 A124.2 ISKN - List vlastnictví
23 A1341.1 Ověření v.z.p. pojištěnce
24 A1341.2 Oznámení OSVC PP
25 A1341.3 Oznámení OSVC PP ZP
26 A1341.4 Seznam OSVC PP
27 A1381.1 Vozidlo v Systému Elektronického Mýtného
28 A1381.2 Zahraniční provozovatel vozidla v Systému Elektronického Mýtného
29 A344.1 Notifikace prostřednictvím Portálu Občana
30 A3726.1 Pacient
31 A385.1 Oznámení OSVC PP
32 A385.2 Seznam OSVC PP
33 A385.3 Výpis z Daňové Informační Schránky
34 A385.4 Oznámení stavu účetní závěrky
35 A385.5 Výpis prijmů z Daňového priznami
36 A392.1 Dlužník
37 A392.2 ODU
38 A392.3 Nedoplatky dle ukladatele
39 A4003.1 Poskytovatelé zdravotních služeb
40 A4003.2 Zdravotnická dokumentace pacienta
41 A418.1 Osoba v pátrání
42 A418.2 Vozidlo v pátrání
43 A418.3 NBU Lustrace
44 A476.1 Registr ISIN
45 A483.1 Výpis údajů z Rejstříku trestů
46 A561.1 Výzva
47 A561.2 Projekt
48 A561.3 Vypočtené indikátory
49 A575.1 IS ÚCL
50 A8566.1 Notifikace
51 A998.1 Registr silničních vozidel
Seznam datových obsahů kontextů

Termínem datové obsahy se rozumí definice XML schémat popisujících rozhraní pro dotazování publikačních AIS, které publikují data v rámci jimi vedených agend prostřednictvím eGSB/ISSS.

PořadíKód Název
1 1 Žádost o poskytnutí údajů o vozidle z evidence Systému Elektronického Mýtného.
2 2 Žádost o poskytnutí údajů zahraničního provozovatele vozidla z evidence Systému Elektronického Mýtného.
3 A124.1.PravaProOsobu Dotaz práva osoby vedená v KN
4 A124.2.ListVlastnictvi Dotaz na list vlastnictví v KN
5 A344.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele Portálu Občana
6 A8566.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele
7 CRRDotaz Dotaz do registru řidičů
8 CrrOsvedceniDigiUkon Osvědčení o digitálním úkonu
9 CrrRidicNotifikaceBoduReg Registrace k notifikacím změn bodového hodnocení
10 CrrRidicRozsirene Dotaz do CRŘ na rozšířené údaje o řidiči
11 CrrRidicUdaje Dotaz do CRŘ na údaje o řidiči
12 CrrRidicZadostPodani Podání žádosti o řidičský průkaz
13 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
14 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
15 CSCEPANDLUZNIK Dotaz na nedoplatky do evidence přeplatků a nedoplatků Celní správy
16 CSCEPANNEDOPLATKYDLEUKLADATELE Dotaz na evidované nedoplatky podle ukladatele u Celní správy
17 CSCEPANODU Dotaz na stav osobního daňového účtu do evidence přeplatků a nedoplatků Celní správy
18 CSSZOsvc Dotaz do ČSSZ na údaje o OSVČ
19 CSSZPojistenec Dotaz do ČSSZ na údaje o pojištěnci
20 CSSZUoj Dotaz do ČSSZ na údaje o Územně organizační jednotce
21 CSSZZamestnavatel Dotaz do ČSSZ na údaje o Zaměstnavateli
22 DAPPRIJEM Dotaz na prijmy z Daňového přiznání
23 DISDOTAZ Dotaz na výpis z Daňové Informační Schránky
24 DISZADOST Žádost na výpis z Daňové Informační Schránky
25 EtestyOsobaZkousky Dotaz do IS eTesty na vykonané zkoušky odborné a profesní způsobilosti.
26 EVIDOSVC EvidenceOSVC
27 FormularePOCti Formuláře Portálu občana - čtení
28 FormularePOZapis Formuláře Portálu občana - čtení
29 INFPREHL Informovani o DAP
30 KALENDAR Dotaz na výpis z Daňové Informační Schránky
31 KONTROLAOSVC Kontrolní zjištění OSVČ
32 KONTROLAZC Kontrolní zjištění závislé činnosti
33 MSProjekt Projekt
34 MSVypIndi Vypočtené indikátory
35 MSVyzva Výzva
36 NBU_Lustrace NBU Lustrace
37 NBUAVIZACE NBU Avizace
38 OBNOVENISVC385 Opětovné zahájení SVČ
39 PaisCtiRSVKontexty Dotaz na vozidlo
40 PaisRsvCtiAifo Dotaz na vozidlo
41 PaisRsvCtiFormular Formuláře - čtení
42 PaisRsvCtiIco Dotaz na vozidlo
43 PaisRsvCtiNovaEkoVozidla Dotaz na vozidlo
44 PaisRsvCtiNovaEkoVozidlaAsync Dotaz na vozidlo
45 PaisRsvCtiOrv Dotaz na vozidlo
46 PaisRSVCtiOsvedceniFormular Dotaz na vozidlo
47 PaisRsvCtiPoplatek Suma poplatku
48 PaisRsvCtiPrilohu Dotaz na vozidlo
49 PaisRsvCtiRz Dotaz na vozidlo
50 PaisRsvCtiSazebnikPoplatku Sazebník poplatků
51 PaisRsvCtiSeznamFormularu Seznam registračních míst z RSV
52 PaisRsvCtiSeznamIcoAsync Dotaz na vozidlo
53 PaisRsvCtiSeznamRcAsync Dotaz na vozidlo
54 PaisRsvCtiSeznamRm Seznam registračních míst z RSV
55 PaisRsvCtiTp Dotaz na vozidlo
56 PaisRsvCtiVin Dotaz na vozidlo
57 PaisRsvCtiVozidloId Dotaz na vozidlo
58 PaisRsvCtiZmeny Dotaz na vozidlo
59 PaisRsvCtiZmenyAsync Dotaz na vozidlo
60 PaisRsvVlozPrilohu Formuláře - vložení přílohy
61 PaisRsvVozidlaAsyncOdpoved Dotaz na vozidlo
62 PaisRsvZamkniFormular Formuláře - zamknutí
63 PaisRsvZapisFormular Formuláře - zápis
64 PaisRsvZapisInformaceOPlatbe Zápis informací o platbě
65 PATRMV Dotaz na vozidlo v pátrání
66 PATROS Dotaz na osobu v pátrání
67 PDFCertifikatu Dotaz na certifikát tazatele v PDF
68 PODANPREHLED Podán přehled OSVCPP ZP
69 PODANPREHLED385 Podán přehled OSVCPP ZP
70 PONDUKONC Podnět ukončení
71 PONDUKONC385 Podnět ukončení
72 PREHLEDPLATEB Přehled plateb
73 PREVYSUZVESL Oznámení stavu účetní závěrky
74 RTFODotaz Dotaz do Rejstříku trestů
75 RTNastaveniBlokace Požadavek do Rejstříku trestů na vytvoření, popř. zrušení blokace
76 RTZadosti Dotaz do Rejstříku trestů
77 RTZadostiDokument Požadavek do Rejstříku trestů na vystavení výstupního dokumentu.
78 RTZadostiStav Dotaz do Rejstříku trestů na stav manuálně zpracovávaných žádostí.
79 SeznamCertifikatu Dotaz na certifikáty tazatele
80 SEZNAMOSVCPP Seznam OSVCPP
81 SEZNAMOSVCPP385 Seznam OSVCPP
82 SeznamPoskytovatelu Seznam poskytovatelů s dostupnou zdravotnickou dokumentací osoby
83 SPSOsobaDoklady Dotaz do IS SPS na průkazy způsobilosti, které vlastní.
84 SPSOsobaDokladyPlavidla Dotaz do IS SPS na průkazy způsobilosti a vlastněná/provozovaná plavidla.
85 SPSProvozovatelPlavidla Dotaz do IS SPS na plavidla, která provozuje.
86 SPSVlastnikPlavidla Dotaz do IS SPS na plavidla, která osoba vlastní.
87 UCETNIZAVERKA Předání a zneplatnění ÚZ
88 UclUdaje Dotaz na údaje z IS ÚCL
89 UKONCENI Ukonceni
90 Vozidlo Dotaz na vozidlo
91 VYPFOISVS Dotaz na osobu podle zákona 365/2000 Sb.
92 VypisVozidelPDF Výpis vozidel v PDF
93 VYPOOCRP Dotaz na ověření osoby vůči CRP
94 VYPSUBJISVS Dotaz na subjekt podle zákona 365/2000 Sb.
95 ZadostOVypis Žádost o výpis
96 ZAPOSVCPP Zápis OSVC PP
97 ZdravotnickaDokumentace Dokument se zdravotnickou dokumentací pacienta
98 ZMENACISPOJ Změna čísla pojištěnce
99 ZMENACISPOJ385 Změna čísla pojištěnce

Pohled na propojení integračních platforem

Evidence jiných fyzických osob

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

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

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

Výše popsaná situace však nefunguje, respektive z mnoha důvodů na všech zúčastněných stranách je nemožné ji tímto způsobem realizovat. Níže je tedy popsán budoucí stav, ke kterému je třeba dospět, aby se eliminovaly nežádoucí efekty plynoucí z toho, že jednotlivé evidence veřejné správy spravují subjekty, které nejsou v základních registrech.

Nový navrhovaný stav EjFO

Současný stav předpokládá, že jednotlivé agendy veřejné správy budou subjekty, které ve svých evidencích vedou a nejsou v základních registrech, editovat pomocí komponenty cizineckého informačního systému. Z důvodu legislativních nesrovnalostí o tom, jaké subjekty může cizinecký informační systém vést, se navrhuje vytvořit novou evidenci, která bude mít za úkol vést evidenci jiných fyzických osob a bude se chovat jako ostatní editační systémy registru obyvatel, tedy především:

  • Vést si ke každému subjektu plnou historii údajů
  • Přijímat a řešit notifikace na údaje o subjektech v evidenci
  • Zapisovat údaje do základního registru bez zbytečného prodlení
  • Publikovat na dotaz oprávněného systému nebo uživatele historické údaje
  • Umožnit oprávněnému žadateli ztotožnění subjektu pomocí aktuálních i historických údajů pomocí kombinace údajů
  • Umožnit oprávněnému uživateli výdej údajů o subjektu pomocí jeho AIFO

Správce evidence EjFO bude shromažďovat údaje o subjektech z jednotlivých evidencí veřejné správy a propagovat je do registru obyvatel prostřednictvím referenčního rozhraní veřejné správy.

Diagram zápisu údajů do registru obyvatel. Oranžově vyznačená je část, která se musí upravit, světle zeleně jsou části, které musí vzniknout.

Diagram zápisu údajů do EjFO. Oranžově vyznačená je část, která se musí upravit, světle zeleně jsou části, které musí vzniknout.

Možné problémy EjFO

Problémy, které mohou nastat a je nutné je vyřešit před uvedením EjFO do produkčního prostředí:

  • Může se stát, že u primárního editora přestane subjekt existovat (prodá nemovitost, přestane s lékařskou praxí…), což ale neznamená, že přestane existovat u všech ostatních evidencí. Je tedy nutné vyřešit, zda se primární editorství přesouvá nebo se pro EjFO vůbec neuplatňuje
  • Bez propojení evidencí občanů EU či jiných třetích států nikdy nedosáhneme zaručené aktualizace údajů. Je proto nutné, aby agendy, které vedou jiné fyzické osoby měly zákonné zmocnění vyžadovat aktualizaci údajů od subjektu. Dokazování o existenci jedné identity je vždy v rukou subjektu, on musí prokázat, že i přechozí záznamy se týkají jeho – pokud se tak neprokáže, budou se nadále evidovat identity 2 nebo více – tento stav nebude horší než současný stav, může být pouze lepším nebo při nejhorším stejný

Evidence jiných právnických osob

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

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

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

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šší

Identifikace klientů 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:

Fyzická identifikace právnických osob

Pokud jde o právnické osoby v pojetí českého právního řádu, tyto nemohou z jejich povahy nikdy právně jednat samy, musí za ně vždy jednat zástupce, kterým je (byť i nepřímo, např. je-li právnická osoba statutárním orgánem jiné právnické osoby) finálně vždy fyzická osoba (příp. fyzické osoby). Pro použití ve fyzickém prostředí se identifikační prostředky právnických osob v České republice nevydávají. Je tomu tak proto, že právnická osoba není ve fyzickém prostoru přítomna a vždy za ni jedná fyzická osoba, která prokazuje svou vlastní totožnost.

Elektronická identifikace

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

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

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

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

Elektronická identifikace právnických osob

Pokud jde o právnické osoby v pojetí českého právního řádu, tyto nemohou z jejich povahy nikdy právně jednat samy, musí za ně vždy jednat zástupce, kterým je (byť i nepřímo, např. je-li právnická osoba statutárním orgánem jiné právnické osoby) finálně vždy fyzická osoba (příp. fyzické osoby). Z toho plyne, že ustanovení § 2 zákona o elektronické identifikaci, které dopadá na případy fyzických osob, se tak vztahuje i na jednání právnických osob, neboť jsou to vždy fyzické osoby, které fakticky jednají, ať již za sebe, či za jinou fyzickou osobu nebo právnickou osobu.

V elektronickém prostředí, zejména jde-li o automatizovanou komunikaci, jsou nicméně používány mechanismy, které mají charakter identifikačního prostředku právnické osoby. Jde např. o certifikát pro evidenci tržeb podle zákona č. 112/2016 Sb., o evidenci tržeb, nebo certifikáty vydané Českou národní bankou pro automatizovanou komunikaci mezi ČNB a subjekty podléhající jejímu dozoru, typicky bankami. Platí nicméně, že identifikační prostředky právnických osob s použitím bez ohledu na agendy, ekvivalentní např. občanským průkazům, se v České republice nevydávají.

Zatímco samotná autentizace fyzické osoby není problematická, problematická se jeví otázka určení, zda fyzická osoba jedná v dané situaci za sebe (popř. v jaké roli za sebe) anebo zda jedná za jinou fyzickou osobu nebo za právnickou osobu. Problematika mandátů a oprávnění je řešena níže.

Skutečnost, že daná fyzická osoba, má právo se identifikovat a autentizovat za určitou právnickou osobu (tj. „přihlásit se ke službě jménem právnické osoby“), ještě nezakládá bez dalšího právo na to, že tato fyzická osoba má právo za danou právnickou osobu činit úkony prostřednictvím digitální služby. Autorizaci dané fyzické osoby k poskytnutí digitální služby musí posoudit ten, ke komu se fyzická osoba hlásí na základě jím dostupných údajů (informace z obchodního rejstříku, plná moc opravňující konkrétní osobu jednat jménem právnické osoby,…) ve spojení s příslušnými právními předpisy.

Jako příklad takového přístupu můžeme uvést datové schránky, do nichž se fyzická osoba přihlásí například novým občanským průkazem s aktivovaným čipem. Po úspěšné autentizaci s pomocí prostředku pro elektronickou identifikaci (tj. např. s pomocí „eObčanky)“ a souhlasu s předáním osobních údajů na portálu Národního bodu pro identifikaci a autentizaci, je fyzická osoba pro účely informačního systému datových schránek (ISDS) ztotožněna. Po ztotožnění tak nabídne ISDS fyzické osobě seznam datových schránek, ve vztahu k nimž je přihlášená fyzická osoba oprávněná jednat.

Autentizovaná fyzická osoba si tedy vybírá, za koho a v jaké roli bude prostřednictvím datových schránek jednat. Informaci o tomto oprávnění si ISDS obstarává např. z ROS, z jiných zdrojů (např. údaj o tom, že určitá osoba je advokátem nebo insolvenčním správcem) anebo jej vede na základě sdělení samotného držitele datové schránky (např. údaj o tzv. pověřené osobě). Bez ohledu na zdroj informace o oprávnění k zastupování jiné osoby, resp. na zdroj informace o roli je však na samotném ISDS jakožto poskytovateli služeb, aby oprávnění k zastupování jiné osoby ve svém prostředí řádně implementoval tak, aby osoby mohly toto oprávnění realizovat. Nabídka jednotlivých oprávnění, resp. rolí, tedy spadá do kompetence daného poskytovatele služeb a odvíjí se od údajů a oprávnění, které vede v rámci svého informačního systému nebo od údajů, ke kterým má přístup.

Mandáty, role a práva v elektronické komunikaci

Zajištění správné obsazení do role neboli autorizace, klienta využívajícího elektronické služby je jedním ze základních předpokladů jejího správného fungování. Různé role mají v rámci služby různá oprávnění a povinnosti a poskytovatel služby je povinen nabídnout klientovi veškeré role, do kterých se v rámci služby může pasovat, včetně rolí jako zástupce právnické osoby, zástupce nezletilého, registrující lékař pacienta a další. Tyto role s oprávněními vůči jiným klientům veřejné správy jsou mandáty. Aby proběhlo správné obsazení do role a zjištění mandátu, je pro poskytování elektronických služeb klientům veřejné správy nutné mít zajištěno několik základních náležitostí:

  1. Znalost typů mandátů při jednání s veřejnou správou
  2. Jednoznačnou identifikaci a autentizaci klienta veřejné správy
  3. Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu
  4. Vlastní zajištění autorizace klienta veřejné správy
Mandáty pro jednání s veřejnou správou

Při výkonu veřejné správy a to zejména při jakékoliv interakci a komunikaci s klientem veřejné správy je nutné, aby veřejná správa respektovala mandáty k zastupování jedné osoby druhou na základě různých titulů. Zjednodušeně se dá rozdělit forma mandátu zastupování dle následující tabulky.

Typ subjektu Mandát
Fyzická osoba Jednající sama svým jménem
Jednající jménem jiné fyzické osoby ze zákona:
- rodič dítěte,
- manžel/manželka,
- registrovaný partner/partnerka,
- opatrovník, 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.
  • Zákon 250/2014 Sb., o elektronické identifikaci. Systém, který vyžaduje ověření totožnosti
  • Nařízení eIDAS

Více o využívání údajů propojeného datového fondu a infrastruktuře referenčního rozhraní je napsáno v kapitolách:

Centrální sdílené služby eGovernmentu dokáží zajistit následující mandáty pro fyzické osoby, které se prokázaly u poskytovatele služeb svou zaručenou elektronickou identitou:

  • eGON služba rosCtiPodleUdaju, rosCtiIco, rosCtiAifo (základní registr osob)
    • pro zajištění ověření, zda je fyzická osoba statutárním zástupcem
  • eGON služba aiseoCtiPodleUdaju, aiseoCtiAifo (agendový informační systém evidence obyvatel)
    • pro zajištění ověření, zda je fyzická osoba rodič nezletilého, který není svéprávný
    • pro zajištění ověření, zda je fyzická osoba zákonným zástupcem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba opatrovníkem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba manžel/manželka
  • eGON služba isknCtiVlastniky (informační systém katastru nemovitostí)
    • pro zajištění ověření, zda je fyzická osoba vlastníkem nemovitosti
  • Služba ISDS
    • Pro zajištění, zda je fyzická osoba pověřená k činění úkonů v ISDS vlastníkem datové schránky

Žádné další centrální služby ověření oprávnění/mandátů se v současné, ani dohledné době, neplánují. Proto je důležité, aby si každý poskytovatel elektronických služeb zajistit jiné typy mandátů sám.

Vlastní zajištění autorizace klienta veřejné správy

Každá vykonávaná agenda (výkon veřejné správy) může pro svoji potřebu vyžadovat jiné mandáty. Například mandát podání daňového přiznání za jinou fyzickou osobu, mandát nahlížení na zdravotnickou dokumentaci jiné fyzické osoby, nakládání s majetkem právnické osoby, u které nejsem statutární zástupce, či například mandát k zastupování při dědickém řízení.

Všechny tyto mandáty se musí řešit v rámci dané agendy a jako ideální řešení navrhujeme:

  • Zřídit buď v jednotlivých agendových informačních systémech, nebo v rámci centralizované správy subjektů mandátní registr.
  • V rámci mandátního registru určit předem definované typy mandátů přípustné v dané agendě a způsob zápisu mandátů pro nahlížení a pro transakce ze strany klienta
  • Povolit zapisovat všem klientům mandáty dle definovaných typů pod svou zaručenou elektronickou identitou.
  • Umožnit klientům přidat mandát i offline, například na přepážce úřadu.
  • Při každém přihlášení klienta kontrolovat kromě mandátů z centrálních sdílených služeb eGovernmentu i vlastní mandátní registr a dát vždy při přihlášení vybrat klientovi, v jaké roli a s jakým mandátem chce pracovat.

Je důležité zdůraznit, že veřejná správa nemá rozlišovat formu komunikace a jednání s klientem. Tedy mandát obecně platící pro osobní jednání s úředníkem, nebo pro fyzické prováděné úkony na přepážce, musí mít klient umožněn využívat i při elektronické komunikaci a naopak. Také proto je nutné vést mandáty standardizovanou formou na jednom místě a využívat jich i při elektronické komunikaci klienta.

Mandát plynoucí z veřejnoprávního nebo soukromoprávního titulu a to včetně plných mocí a dohod o zastupování při správním jednání s úřady patří mezi společné rozhodné skutečnosti, tak jak jsou zakotveny v souvisejících ustanoveních Správního řádu (zejména § 6 a § 50 a související). Proto je nanejvýš vhodné, aby příslušný orgán veřejné moci, pokud

  • využívá a buduje centrální evidenci subjektů,
  • centrální evidenci rozhodných skutečností,
  • skutečnosti o zapsaném anebo z něčeho plynoucím mandátu k zastupování,
  • je zahrnul do rozhodných skutečností.

Klient se totiž může odvolat na příslušná ustanovení správního řádu a neposkytovat zejména plné moci a další dokumenty, z nichž mandát plyne, úřadu opakovaně.

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.

Evidence subjektů

Popis evidence subjektů

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

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

Identifikátory fyzických osob

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

Název Popis Příklady Slouží k
Agendový identifikátor fyzické osoby (AIFO) Identifikátor, který přiděluje ORG pro danou agendu a je jedinečný pro osobu a agendu. AIFO v agendě evidence obyvatel, AIFO v agendě řidičských průkazů Technický identifikátor pro účely jednoznačné identifikace fyzické osoby v agendě a jako identifikátor osoby při výměně údajů. Je pouze v agendě, nikdy se neposkytuje a nepředává, překládá se výhradně přes ORG.
Bezvýznamný směrový identifikátor (BSI) (Pseudonym od NIA) Identifikátor, který přiděluje NIA každému kvalifikovanému poskytovateli služeb (resp. "uživateli" ve smyslu Z 12/2020, §12a (1)), na základě kombinace poskytnutých identifikačních údajů FO. Je jedinečný pro kombinaci FO a poskytovatele služby. Nesmí se používat veřejně, tj. mimo uživatele služby, kterému byl přidělen, s výjimkou použití vůči OVM.BSI pro portál občana, BSI pro portál ČSSZ, BSI pro všeobecnou fakultní nemocnici Speciální typ stykového identifikátoru pro účely jednoznačné identifikace fyzické osoby pouze v kontextu daného poskytovatele služby. Fakticky nahrazuje rodné číslo sadou těchto identifikátorů různých pro každého poskytovatele. Každý OVM si může přeložit kterékoliv BSI pomocí služeb základních registrů na své AIFO.
Stykový Identifikátor (SI) Jednoznačný identifikátor pocházející z veřejné listiny, kterým lze identifikovat osobu při komunikaci s veřejnou správou. Jakýkoliv stykový identifikátor musí být v ROB, kromě BSI. Typ a číslo dokladu (OP, pas, ŘP) Využívá se při prezenční či listinné či elektronické komunikaci s klientem, namísto nebo vedle KI. Podle něj se provede překlad na KI pro vnitřní práci v agendě a AIS, i na AIFO v agendě pro komunikaci v rámci PPDF. AIS poté ví, jak AIFO, tak KI, v systémech se tento identifikátor (SI) neeviduje a neukládá.
Klientský identifikátor (KI) Klientské číslo používané v dané agendě nebo skupině agend jednoho resortu (ve výjimečných případech více úřadů spolupracujících nad jednou agendou, pak však nesmí spolupracující úřad přenést toto KI mimo agendu), jako úředníkům i klientům známý bezvýznamový identifikátor DIČ, Číslo pojištěnce, klientské číslo Úřední identifikátor, na rozdíl od AIFO je prezentován klientovi i úředníkovi. Využívá se při vnitřním i vnějším úředním styku v dané agendě nebo skupině příbuzných agend, zpravidla se neposkytuje mimo, ale využívá se jen v rámci této agendy. Klient si své číslo může, ale nemusí pamatovat, užívat či dokládat, k tomu slouží stykový klientský identifikátor (SI).
Evidence jiných fyzických osob

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

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

Identifikátory právnických osob

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

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

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

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

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

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

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

Evidence jiných právnických osob

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

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

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

Pohled na identifikátory ve VS

Pravidla evidence subjektů

Využívání jednotlivých identifikátorů

Jako identifikátor fyzické osoby (a potažmo i právnické, protože za právnickou osobu vždy jedná fyzická osoba), se v různých agendách používají různé druhy identifikátorů, a to jak pro účely vnitřních procesů a služeb (uvnitř úřadu), tak i při výměně údajů (ven z úřadu). Identifikátory subjektů se využívají při úřední komunikaci a interakci s klientem, při evidenci údajů v příslušných informačních systémech a ve spisové dokumentaci a při výměně údajů s dalšími informačními systémy.

Pravidla pro klientský identifikátor

Klientský identifikátor je možné přidělovat všem subjektům vedeným v evidenci daného úřadu. Není nutné mít legislativní úpravu, přesto je vhodné mít doložitelná pravidla, která klientský identifikátor v úřadu upravují.

  • Vydání klientského identifikátoru se musí týkat pouze subjektů ztotožněných proti základním registrům, tedy obdržením AIFO pro fyzické osoby
  • Klientský identifikátor lze přidělit i subjektům, které v evidenci ještě nejsou, ale existuje oprávněný zájem na daný subjekt od jiného oprávněného tazatele.
    • Příkladem mohou být evidence, které mají dávat zpětné informace oprávněných tazatelů ve chvíli, kdy se subjekt v evidenci objeví. Tedy oprávněný tazatel chce po evidenci vědět, kdy se v ní subjekt teprve objeví. Aby se nemuselo komunikovat osobními údaji, vydá evidence tazateli klientský identifikátor na subjekt, který dosud v evidenci nemá a bude jej informovat, jakmile se v ní objeví.
  • Předchozí bod znamená vedení AIFO na subjekt, který v evidenci neexistuje, a k němu klientský identifikátor. Tento tzv. "klientský kmen" je odlišným od "datového kmene" související s předmětným právem nebo povinností agendy. Klientský kmen je evidencí současných a teprve potenciálních klientů.
Při evidenci subjektů v datovém kmenu úřadu

Cílem PPDF a pseudonymizace je zavést jednotnou formu identifikace subjektu při jeho evidenci. Nelze nadále využívat dosud zneužívané persistentní identifikátory, ale je naopak nutné rychle se přizpůsobit povinnostem pseudonymizace. Proto je nutno respektovat níže uvedené základní principy pro evidenci subjektů:

  1. Identifikátorem pro komunikaci mezi jednotlivými agendovými informačními systémy je vždy AIFO (AIFO se překládá přes služby ISZR a ISSS).
  2. AIFO se nikdy v systému nezobrazí a úředník k němu nesmí mít žádný přístup.
  3. Úředním/klientským identifikátorem fyzické osoby nesmí být AIFO, ale vždy klientské číslo pro danou agendu, které přidělí správce dané agendy a které se využívá jako prezentovaný identifikátor v AISu a pro úředníka. Tento identifikátor musí být bezvýznamový, nelze tedy z něj odvodit další osobní údaje fyzické osoby. Agenda přidělující klientský identifikátor musí poskytovat služby pro jeho získání na základě stykového identifikátoru či AIFO a zpět. Současně řídí oprávnění k použití takové služby.
  4. Při komunikaci s klientem (osobní jednání na přepážce i zpracování doručených dokumentů a zpráv) se využívají stykové identifikátory, jako jsou typ a číslo dokladu a využije se služba jednorázového překladu na AIFO a služby vydavatele klientského identifikátoru pro získání tohoto identifikátoru.
  5. Stykové identifikátory si primárně neeviduji, leda by byly zároveň klientským číslem.
  6. AIFO osoby se nikdy nesmí přímo poskytnout, vždy se využívá služeb překladu z mého AIFO na AIFO příjemce výměny údajů.
  7. Pokud k tomu nejsou specifické důvody, tak při výměně údajů se vyměňuje pouze AIFO a nepřidávají se další identifikátory nebo údaje.

Služby pro překlad aktuálního stykového identifikátoru musí být poskytovány s úrovní dostupnosti kritická – jedná se o ztotožnění osoby. Vydavatel či správce stykového identifikátoru musí zajistit jeho historickou jednoznačnost a služby zajišťující překlad na AIFO i pro historické hodnoty identifikátoru (pro historické hodnoty je požadovaná úroveň dostupnosti – primární služba).

Při interakci s klientem
  1. Při osobním jednání s klientem nebo při jeho prezenčním ztotožnění se využije typ a číslo dokladu, který klient předložil, nebo jinak ověřený stykový identifikátor.
    • Klient předloží doklad s uvedeným identifikátorem, který je stykovým identifikátorem.
    • Prostřednictvím daného AIS se zavolá služba jednorázového ztotožnění osoby přeložením stykového identifikátoru na dané AIFO v jeho agendě.
    • Dále úředník pracuje v AIS podle AIFO subjektu (které sám na obrazovce nevidí), stykový identifikátor si dále neuchovává. Pokud existuje klientský identifikátor, ten při komunikaci uchovat může.
    • Při komunikaci s ostatními AISy a ostatními agendami využije služby svého AISu (kdy AIS prostřednictvím ISSS zajistí výměnu údajů po překladu AIFO).
  2. Při osobním jednání s klientem se využije klientský identifikátor vydaný klientovi dříve
    • Dle povahy poskytované služby může stačit pouze identifikace pomocí klientského identifikátoru, pokud nedostačuje, následuje ověření totožnosti či doložení dalších identifikátorů, např. stykových.
    • Klient předloží u poskytovatele zdravotních služeb klientský identifikátor (číslo pojištěnce na kartičce pojištění)
    • Pro potřebu identifikace v čekárně dostačující způsob identifikace
    • Pro potřebu poskytnutí zdravotních služeb klient dokládá stykový identifikátor
    • Při nutnosti obstarat si další údaje z jiných systémů veřejné správy se postupuje obdobně jako výše.

Při zpracování formulářů pak nastávají tyto tři situace a z nich plynoucí postupy:

  1. Elektronický formulář: Formulář musí být vytvořen tak, aby umožňoval již přenos identity klienta, a při jeho zpracování provede AIS dohledání aktuálních údajů podle AIFO subjektů.
  2. Listinný formulář: Na listinném formuláři se vyžaduje kombinace údajů křestní jméno, příjmení a typ a číslo dokladu, nebo jiný stykový identifikátor. Při zpracování formuláře se opět v AIS provede zavolání příslušné služby pro jednorázový překlad stykového identifikátoru na AIFO, a tím i ztotožnění subjektu pro daný AIS. V tomto případě se všechny údaje (včetně identifikátorů) pamatují z důvodu nutnosti uchovávání samotného formuláře.
  3. Asistované podání: Při asistovaném podání na přepážce příslušný pracovník provede prezenční ztotožnění podle dokladu, a pokud na základě jednání na přepážce bude činit něco jménem subjektu, bude k tomu využívat příslušné služby. Pokud bude pak činit úkon jménem OVM, opět při zápisu do AIS tento AIS zavolá službu jednorázového překladu stykového identifikátoru na AIFO.

Formulářový agendový informační systém

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

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

FAIS tedy poskytuje mimo jiné:

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

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

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

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

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

Implementace zpracování hromadných požadavků

Dále je popsán detailní návrh implementace pro oblast „Zpracování hromadných požadavků“ ve FAIS.

Primárním cílem hromadného zpracování je řízené využití služeb ISSS, které povede k zásadnímu omezení rizik plynoucích ze vznikajících potřeb hromadného zpracování dat prostřednictvím ISSS.

Zpracování hromadných požadavků

Obsahem návrhu a implementace požadavku na zpracování hromadných požadavků ve FAIS je obecná implementace příjmu požadavku na hromadné zpracování prostřednictvím ISDS, respektive prostřednictvím služby referenčního rozhraní PPDF a následné zpracování tohoto požadavku prostřednictvím ISSS, respektive ISZR.

Motivace

Zpracování dat prostřednictvím ISSS je omezeno na zpracování požadavků pro jeden subjekt. V praxi aktuálně vzniká potřeba zpracování dávkových úloh obsahujících rozsáhlou množinu subjektů. V současné době je tato potřeba řešena na úrovni AIS, které v rámci své individuální implementace využívají různé přístupy, které zajišťují rozpad dávkové úlohy na individuální žádosti a zpracování těchto individuálních žádostí prostřednictvím rozhraní webových služeb ISSS.

Výše popsaný přístup znamená, že AIS může ke své implementaci přistoupit způsobem, který je buď sám o sobě nevyhovující z pohledu zátěže generované na ISSS, respektive může být nevyhovující společně v kombinaci s dalšími AIS, které řeší hromadné zpracování prostřednictvím ISSS.

Nevyhovujícím přístupem z pohledu ISSS se rozumí potenciální přetěžování jak vlastního ISSS, tak i potenciální přetěžování navázaných služeb ISZR.

Rizika plynoucí z možného přetěžování ISSS ošetřuje ISSS vlastními kontrolními mechanismy, jejichž výsledkem může být omezování povolených přístupů AIS ke službám ISSS, důsledkem čehož mohou nastávat problémy na straně AIS a jejich business procesů.

Aby bylo možné řídit zátěž ISSS pro účely dávkového zpracování a efektivně zpracovávat dávkové úlohy, požaduje OHA implementovat efektivní podporu pro dávkové zpracování prostřednictvím úprav systému FAIS, který je součástí implementace ISZR a tedy se i stane součástí referenčního rozhraní PPDF.

Aplikační architektura

Na následujícím obrázku je znázorněna stávající aplikační architektura FAIS.

Obsah obrázku text, diagram, Plán, Technický výkres Popis byl vytvořen automaticky

Interní aplikační komponenty FAIS

Interní komponenty FAIS jsou realizovány formou objektů vystavujících metody pro provádění příslušných operací.

  • Příjem z ISDS – komponenta FAIS zabezpečující vyzvedávání a validaci datových zpráv doručených do příslušné datové schránky sloužící pro příjem požadavků na zpracování.
  • Odesílání ISDS – komponenta FAIS slouží pro odesílání výsledků zpracování požadavků formou datových zpráv prostřednictvím definované datové schránky ISDS.
  • WS – komponenta FAIS vystavující rozhraní webových služeb pro příjem a validaci požadavků doručených webovou službou na eGON rozhraní ISZR.
  • Orchestrace – komponenta FAIS zajišťující proces získání dat a přípravu výstupů s využitím dalších podpůrných komponent FAIS a eGON rozhraní ISZR.
  • Logování – komponenta FAIS zajišťující logování průběhu zpracování požadavku.
  • Formátovací šablony – komponenta FAIS poskytující formátovacímu procesu XSLT šablony pro generování výstupů.
  • Formátování výstupů – komponenta FAIS zajišťující sestavení výstupů na základě dat a s využitím formátovacích šablon.
  • Podepisování a pečetění – komponenta FAIS zajišťující s využitím HSM modulu podepisování sestavených PDF výstupů.

Externí komponenty

Externí komponenty jsou systémy nebo rozhraní systémů mimo implementační perimetr FAIS. Tyto systémy a rozhraní jsou nutné pro zpracování požadavků doručovaných do systému FAIS.

  • ISDS – webové služby ISDS, příjem a odesílání datových zpráv. Do datové schránky pro příjem požadavků na formuláře jsou doručovány žádosti o zpracování a výsledek zpracování je odesílán zpět žadateli.
  • ISZR – interní orchestrátor ISZR zpracovávající požadavky na formuláře doručované prostřednictvím webových služeb eGON rozhraní ISZR
  • HSM – HSM modul pro podepisování sestavených PDF výstupů
  • eGON ISZR – eGON rozhraní webových služeb ISZR vystavující služby využívané při zpracování požadavků.

Architektonický model FAIS

Na následujícím obrázku je znázorněn model technologické infrastruktury FAIS ve vazbě na předchozí model aplikační architektury FAIS.

Obsah obrázku diagram, text, Plán, řada/pruh Popis byl vytvořen automaticky

Na logických uzlech FAIS (Fx.DCx – virtuální server v datovém centru DC1 a DC2, tj. STC nebo CP) je spuštěn řídící proces. Na všech serverech jsou nainstalovány všechny interní aplikační komponenty FAIS (viz předchozí kapitola – aplikační role). Konfiguračně je řízeno, jaká konkrétní aplikační komponenta (nebo více komponent, respektive aplikačních rolí) je na konkrétním serveru spuštěna.

Popsaná architektura umožňuje jednotlivým serverům přiřazovat aplikační role s ohledem na aktuální potřeby (procesně řízeno provozem).

Zpracování hromadných požadavků

FAIS bude implementovat podporu pro hromadné zpracování vůči ISSS, respektive ISZR. Jde o implementaci nového procesu, který dosud FAIS nepodporuje.

V následujícím popisu je popsána funkcionalita primárně s ohledem na zpracování HP vůči ISSS, zpracování vůči ISZR je principiálně totožné, pokud jsou ve zpracování rozdílu, jsou v textu uvedeny.

Definice hromadného zpracování

Hromadným zpracováním se v kontextu FAIS se rozumí zpracování, kdy je technicky zabezpečeno zpracování více než jednoho volání ISSS nebo ISZR na základě jednoho vstupního požadavku do FAIS.

Jednotlivá volání ISSS, respektive ISZR musí být v rámci zpracování jednoho hromadného požadavku na sobě nezávislá, tj. musí být proveditelná v libovolném pořadí, respektive souběžně.

Hromadné zpracování je určeno pro provedení více volání ISSS respektive ISZR, kdy je v rámci každého volání zpracováván právě jeden subjekt. Subjektem se rozumí buď subjekt vedený v ROB (identifikovaný jeho AIFO) nebo subjekt vedený v ROS (identifikovaný jeho IČO).

V rámci hromadného zpracování jsou podporovány operace jednoho typu, tj. buď zápis, nebo čtení, nad jedním typem subjektu a v jednom kontextu.

V rámci hromadného zpracování budou existovat logická omezení oproti případnému řešení na straně AIS. Tato omezení jsou vyvážena zjednodušením a zefektivněním procesu zpracování, omezením rizik přetížení ISSS a ISZR, a zjednodušením implementace na straně AIS v oblasti hromadného zpracování.

Přínosy hromadného zpracování

Hromadné zpracování bude generovat přínosy na prakticky všech stranách zúčastněných v procesu zpracování:

  • Pro ISSS a ISZR bude přínosem optimalizace procesu, snížení nutné zátěže systému a omezení rizik přetížení těchto systémů.
  • Pro AIS žadatelů bude přínosem zjednodušení implementace procesu generování hromadných požadavků. Na straně AIS žadatelů nebude nutné řešit mechanismy řídící zátěž vůči ISSS a ošetřovat chybové stavy plynoucí z potenciálních problémů přetížení ISSS, požadavky AIS budou zpracovány optimálně.
  • Pro AIS poskytovatelů služeb prostřednictvím ISSS (PAIS a AISSÚ) bude výsledkem implementace omezení potenciálních rizik plynoucích z generování současné zátěže z více AIS žadatelů, tzn., že požadavky budou přicházet řízeně.

Omezení hromadného zpracování

Zpracování hromadných požadavků bude mít následující základní omezení:

  • Předávání dat prostřednictvím souborů, případně vyzvednutí souboru na ISSS si musí zajistit žadatel voláním služby ISSS.
  • Nelze provést současnou specifikaci primární entit různých typů (subjekt ROB a subjekt ROS).
  • Velikost požadavku je omezena maximální možnou velikostí volání webové služby (bude definováno v provozních parametrech služby), respektive maximální možnou velikostí datové zprávy.

Princip hromadného zpracování

Z principu je hromadné zpracování asynchronní proces, zpracování řídí FAIS dle aktuálního provozního stavu systému. V procesu hromadného zpracování existují z pohledu žadatele dva kroky:

  • Předání hromadného požadavku a obdržení potvrzení o jeho přijetí FAIS
  • Získání odpovědi

Předání hromadného požadavku

Předání požadavku na hromadné zpracování může být provedeno buď voláním webové služby nebo datovou zprávou prostřednictvím ISDS. Na následujícím diagramu je znázorněn proces předání požadavku ke zpracování.

Obsah obrázku text, diagram, Plán, Paralelní Popis byl vytvořen automaticky

Popis procesu pro jednotlivé vstupní rozhraní je uveden v následujících podkapitolách.

Identifikátor hromadného požadavku

Každému hromadnému požadavku bude na vstupu FAIS přidělen globální identifikátor transakce. Účelem tohoto identifikátoru bude kromě jednoznačné identifikace v rámci FAIS také příprava na integraci na jednotné logovací a auditní prostředí RR PPDF.

Tento globální identifikátor transakce bude v rámci procesu zpracování průběžně využíván při předávání požadavků mezi systémy, pokud to bude příslušný systém umožňovat, respektive bude připraven k předání tak, aby byla dodržena koncepce budoucí integrace na jednotné logovací a auditní prostředí RR PPDF.

Formát hromadného požadavku

Hromadný požadavek bude předáván v XML souboru definovaném XSD schématem. Návrh XML je optimalizován pro účely hromadného zpracování.

Základní řídící informace budou definovány typově fixovanou strukturou, vlastní data určená pro hromadné zpracování budou v XML vložena jako CDATA nebo odkazem.

V principu jsou součástí požadavku informace jako identifikace žadatele, identifikace požadované operace, identifikace subjektů, a další datové položky detailně specifikující požadavek na zpracování.

Předání požadavku webovou službou

Základní princip zpracování hromadných požadavků zasílaných webovou službou bude následující:

  • Žadatel odešle na definované rozhraní webové služby požadavek ke zpracování. Požadavek bude předán prostřednictvím XML dokumentu v definovaném formátu, tento XML dokument bude součástí volání webové služby.
  • FAIS provede validaci požadavku s ohledem na způsob doručení webovou službou.
    • Validní požadavky jsou předány do procesu orchestrace, žadatel dostane v odpovědi na volání přidělený identifikátor požadavku a informaci o přijetí.
    • Pro nevalidní požadavky dostane žadatel v odpovědi identifikátor požadavku, informaci o nepřijetí a informaci o důvodu nepřijetí. Zpracování je ukončeno.

Poznámka: požadavky předávané webovou službou mohou obsahovat AIFO pro specifikaci subjektů ROB. Pro případné předání identity subjektů ROB je možné volitelně použít i úložku AIFO (služba ISZR E175 ulozMapaAifo). FAIS je součástí referenčního rozhraní a jako důvěryhodný systém vůči ISZR bude mít automaticky implicitní přístup pro čtení úložky AIFO).

Technická implementace rozhraní webové služby pro příjem HP

V současném stavu referenčního rozhraní PPDF je rozhraní FAIS pro konzumenty dostupné prostřednictvím eGON rozhraní ISZR. Stejným způsobem bude dostupné rozhraní webových služeb FAIS pro zpracování hromadných požadavků.

Poznámka: ISZR zprostředkovává ve stávající architektuře dostupnost FAIS na eGON rozhraní, tento stav bude využit i pro příjem hromadných požadavků. V budoucnu v rámci rozvoje konceptu RR PPDF, kdy bude FAIS integrální součástí referenčního rozhraní, bude možné tento mezikrok vypustit.

Hromadné požadavky budou přijímány prostřednictvím eGON služby E153 iszrZpracujFormular. Tato eGON služba je připravena na příjem obecného XML, prostřednictvím kterého budou zadávány hromadné požadavky. Současně bude možné touto službou získat informace o stavu zpracování HP a výsledek zpracovaného HP.

Předání požadavku datovou schránkou

Základní princip zpracování hromadných požadavků zasílaných přes datovou schránku bude následující:

  • Žadatel odešle do definované technické datové schránky požadavek ke zpracování. Požadavek bude popsán prostřednictvím XML souboru v definovaném formátu, který bude přílohou odeslané datové zprávy.
  • FAIS provede vyzvednutí datové zprávy z technické datové schránky a provede validaci požadavku s ohledem na způsob doručení prostřednictvím ISDS.
    • Validní požadavky jsou předány do procesu orchestrace. FAIS odešle datovou zprávu o přijetí požadavku ke zpracování do datové schránky odesílatele hromadného požadavku, zohlední identifikátory zdrojové DZ, číslo jednací, respektive spisovou značku.
    • Pro nevalidní požadavky je vytvořen PDF a XML protokol o zamítnutí požadavku, který je vložen do výstupní fronty pro odeslání datovou zprávou. Výstup (PDF i XML) obsahuje identifikátor požadavku, informaci o nepřijetí a informaci o důvodu nepřijetí. Zpracování je ukončeno.

Poznámka: požadavky předávané datovou schránkou nesmí obsahovat AIFO pro specifikaci subjektů ROB. Případné předání identity subjektů ROB je možné výhradně úložku AIFO (služba ISZR E175 ulozMapaAifo). FAIS je součástí referenčního rozhraní a jako důvěryhodný systém vůči ISZR bude mít automaticky implicitní přístup pro čtení úložky AIFO.

Stavy zpracování hromadného požadavku

Stavy zpracování hromadného požadavku ve FAIS jsou znázorněny na následujícím obrázku.

Obsah obrázku text, snímek obrazovky, kruh, Písmo Popis byl vytvořen automaticky

Stavy požadavku jsou:

  • Nový – požadavek je vytvořen a čeká na zahájení validace. V principu je relevantní pouze pro požadavky doručené do datové schránky, požadavky doručené webovou službou jsou buď přijaté, nebo zamítnuté.
  • Přijatý – požadavek je validní a čeká na zahájení zpracování.
  • Zamítnutý – požadavek je nevalidní, existuje výsledek s informací o chybě.
  • Probíhá zpracování – pro validní požadavek probíhá zpracování.
  • Zpracovaný – zpracování bylo dokončeno, existuje validní výsledek s informací o výsledku zpracování.

Poznámka: informace o tom, zda byla žadateli, v případě iniciace prostřednictvím ISDS, odeslána DZ o přijetí / zamítnutí / odeslání výsledku bude řešena samostatnými příznaky spojenými s informací o ID DZ, tj. například stav = Zamítnutý, DS o zamítnutí = odeslána + ID DZ. Tyto příznaky se pro iniciaci WS nevyužívají.

Orchestrace zpracování

  • FAIS zajistí optimalizované zpracování požadavku.
  • FAIS předá výsledek zpracování požadovaným způsobem na výstup.

Jednotlivé kroky orchestrace realizované na straně FAIS jsou popsány v následujících kapitolách.

Validace požadavku

Formální validace

V rámci formální validace je zkontrolován formát požadavku (XML) vůči stanovenému schématu – viz kapitoly Formát hromadného požadavku a splnění logických pravidel na obsah požadavku.

V rámci hlavičky požadavku jsou zkontrolovány údaje nutné pro ověření oprávnění, specifikaci požadované operace a řídící informace.

V rámci těla požadavku je zkontrolována provázanost požadované operace, šablony požadavku a optimalizovaných dat. Je ověřena existence a konzistence datových vět v rámci optimalizovaných dat a podobně.

Validace oprávnění

Pro přístup k datům publikovaným prostřednictvím RR je třeba validovat oprávnění žadatele v rámci výkonu agendy. Atributy nutné pro ověření přístupu musí žadatel předat v rámci hlavičky požadavku.

V hlavičce požadavku musí žadatel specifikovat následující údaje:

  • Kód OVM (nebo SPUU)
  • Kód agendy
  • Kód činnosti
  • Kód AIS
  • Subjekt
  • Uživatel
  • Důvod nebo účel

Při validaci oprávnění se ověří, zda údaje uvedené v těle požadavku odpovídají známým informacím:

  • Kombinace OVM/SPUU, agenda, činnost, AIS je vedena v RPP (s využitím služeb online matice oprávnění) a oprávněna využívat požadované údaje v členění dle katalogu RPP.

Dále se ověří, že žadatel vyplnil hodnoty subjekt, uživatel a důvod nebo účel.

Validace požadavku doručeného webovou službou

U požadavků doručených webovou službou se navíc oproti společným validacím ověří, že:

  • Žadatel volající webovou službu (metadata procesu) odpovídá specifikaci v hlavičce. Tj. údaje hlavičky HP odpovídají žadateli o eGON službu (ZadostInfo).

Validace požadavku doručeného přes datovou schránku

U požadavků doručených prostřednictvím ISDS se navíc oproti společným validacím ověří, že:

  • datová schránka odesílatele (metadata procesu) je zapsána pro OVM (SPUU) v ROS z hlavičky HP.

Věcná validace

V rámci věcné validace jsou provedeny podle obsahu řídících dat následující operace:

  • Přečtení seznamu AIFO (hlavička požadavku nebo úložka AIFO)
  • Přečtení seznamu IČO (hlavička požadavku)
  • Ověření údajů hlavičky
  • Ověření existence šablony a datových vět

Zpracování validního požadavku

Validní požadavek je požadavek splňující všechna validační pravidla. Po úspěšném provedení validace je požadavek uložen do interního úložiště FAIS, ze kterého je následně přejímán k dalšímu zpracování.

Interní úložiště validovaných požadavků funguje na principu fronty, ze které jsou položky vybírány ke zpracování orchestrační komponentou (jedna nebo více instancí – v závislosti na dostupné infrastruktuře prostředí a konfiguraci).

Komponenty FAIS a proces zajišťující zpracování hromadných požadavků jsou znázorněny na následujícím obrázku.

Obsah obrázku text, diagram, Plán, Nalepovací papírek Popis byl vytvořen automaticky

Princip zpracování validního hromadného požadavku

FAIS nově obsahuje komponentu (službu) – HPIniciator - zajišťující zpracování validních hromadných požadavků – požadavků ve stavu „Přijatý“.

FAIS provede změnu stavu hromadného požadavku do stavu „Probíhá zpracování“. Následně FAIS dekomponuje vstupní hromadný požadavek na individuální požadavky, u nichž si zaznamená informace o zdrojové hromadné žádosti (čas, celkový počet nutných volání, kontext volání) a tyto dekompozice si uloží ke zpracování).

Komponenta pro individuální zpracování – HPProces - má definovaný počet vláken, ve kterých provádí zpracování individuálních požadavků. Počet těchto vláken je závislý na aktuálním množství HW zdrojů (na kolika HW prostředcích je komponenta spuštěna, jaké má k dispozici systémové zdroje).

Po zpracování všech dekomponovaných požadavků jednoho hromadného požadavku je sestavena hromadná odpověď a hromadný požadavek interně označen jako zpracovaný.

Výsledek zpracovaného hromadného požadavku obslouží k tomu určená samostatná komponenta (služba) FAIS – HPVysledek, která buď připraví výsledek pro proces iniciovaný voláním webové služby, nebo zajistí kroky nutné pro odeslání odpovědi datovou schránkou. Tento proces je popsán v kapitole Předání výsledku zpracování.

Bezpečnostní aspekty zpracování ve FAIS

Princip zpracování je založený na tom, že FAIS zprostředkovává optimalizovaná individuální volání ISSS a ISZR v zastoupení za žadatelské AIS.

V okamžiku zahájení zpracování validního požadavku je z předchozího zpracování ve FAIS zajištěno, že:

  • Požadavek je syntakticky správný
  • Žadatel je oprávněn k volání požadavku prostřednictvím ISSS,

FAIS je v tomto okamžiku součástí interních komponent referenčního rozhraní PPDF a může využít optimalizovaný přístup k ISZR a ISSS na základě prokázání svojí identity obdobně jako již prokazuje svoji identitu ISSS vůči ISZR.

FAIS v aktuálním stavu implementace prokazuje svoji identitu vůči ISZR na základě vlastnictví privátního klíče certifikátu vydaného CA SZR, totožný certifikát bude používán i při komunikaci s ISSS.

Zpracování požadavku a optimalizace výkonu a zátěže na ISZR a ISSS

Optimalizace výkonu a zátěže ISZR a ISSS bude spočívat ve dvou oblastech:

  • Odstranění redundantních kontrol
  • Optimalizace současného volání ISSS (a v důsledku následně ISZR, PAIS a AISSÚ)

Stávající proces zpracování požadavku prostřednictvím ISSS

Proces zpracování jednoho typického volání služby ISSS je následující:

  1. Ověření oprávnění žadatele prostřednictvím eGON služby ISZR
  2. Operace s AIFO na vstupu (úložka AIFO)
  3. Operace s IČO na vstupu
  4. Předání do PAIS / AISSÚ
  5. Operace s AIFO na výstupu (úložka AIFO)
  6. Operace s IČO na výstupu
  7. Čtení AIFO
  8. Čtení IČO

To, které z výše uvedených operací jsou pro konkrétní požadavek provedeny, závisí na datech požadavku. Vždy je provedena minimálně jedna z operací 1, 2, 3, vždy je provedena operace 4, a podle dat jsou provedeny některé z operací 5, 6, 7 a 8.

Uvedený proces je znázorněn na následujícím obrázku.

Obsah obrázku text, diagram, číslo, Paralelní Popis byl vytvořen automaticky

Každé volání služby ISZR, jak je znázorněno i na obrázku výše, vyžaduje samostatné ověření oprávnění (autorizaci) procesem „Přístupová vrstva eGON rozhraní ISZR“.

V případě zpracování hromadných požadavků je počet nutných operací autorizace v ISZR násoben počtem subjektů předávaných v rámci hromadného zpracování, přičemž provedení operace autorizace vyžaduje v ISZR nezanedbatelný čas a konzumuje (s ohledem na počty souběžných volání ISZR obecně) nezanedbatelné množství systémových zdrojů.

Optimalizace redundantních kontrol

V rámci optimalizovaného procesu zpracování na ISSS na základě bezpečně prokázané identity volajícího AIS (vůči ISSS je touto identitou v tomto okamžiku FAIS) lze:

Při volání z FAIS na straně ISSS neprovádět kontrolu oprávnění prostřednictvím služeb ISZR. Při volání ISZR v rámci zpracování požadavku iniciovaném v ISSS prostřednictvím FAIS na straně ISZR neprovádět kontrolu oprávnění interními mechanismy ISZR. ISSS a ISZR pro tyto účely budou na svém rozhraní umožňovat důvěryhodné předání informace o prokázané identitě žadatele a prokázaných oprávněních žadatele.

Princip optimalizace je znázorněn na následujícím obrázku.

Obsah obrázku text, diagram, řada/pruh, Paralelní Popis byl vytvořen automaticky

Namísto opakovaného ověřování oprávnění na všech úrovních je v rámci přípravy implementace koncepce referenčního rozhraní PPDF prováděno předávání informace o prokázané identitě a prokázaných oprávněních, na základě které se lze vyhnout opakovaným komplexním procesům ověřování oprávnění v rámci individuálních voláních mezi komponentami RR PPDF (ISZR, ISSS, FAIS).

Procesy „eGON-d WS *“ tedy postihují modifikaci standardního volání eGON služby zahrnující převzetí a ověření důvěry volajícího.

Poznámka: v případě přímého volání z AIS na ISSS (mimo proces zpracování HP FAIS) provede iniciální kontrolu ISSS a informaci o provedení kontroly předá do ISZR. V procesu zpracování HP je kontrola předsunuta před ISSS a provede se pro každý HP právě jednou.

Optimalizace současného volání ISSS

Optimalizace současného volání ISSS je prováděna na základě dvou skutečností:

  • FAIS v konkrétním okamžiku zná požadavky, které musí prostřednictvím ISSS zpracovat a může tedy zajistit, že sám o sobě nebude generovat zátěž, která by sama o sobě generovala riziko přetížení ISSS (nebo PAIS/AISSÚ).
  • FAIS jako interní komponenta referenčního rozhraní PPDF může optimalizovat volání na základě znalosti aktuálního zatížení ISSS.
  • FAIS při výběru individuálních požadavků ke zpracování vytváří logické fronty pro jednotlivé datové kontexty. Jednotlivé fronty jsou zpracovávány cyklicky. Z každé z těchto front pak vybírá a paralelně zpracovává požadavky tak, aby v konkrétním kontextu nebyla překročena definovaná hranice současného počtu žádostí per kontext. Výběr požadavků z fronty probíhá pseudonáhodně, se zohledněním data doručení hromadného požadavku a pořadí individuálního požadavku tak, aby zpracování jednoho hromadného požadavku nezpůsobilo dlouhodobé odložení zpracování jiných hromadných požadavků.
  • FAIS jako interní komponenta RR PPDF má přístup k aktuálním stavovým informacím ISSS a na základě těchto informací může dynamicky řídit zátěž generovanou vůči ISSS. FAIS získává aktuální informace o stavu zátěže v rámci zpracování jednotlivých požadavků a tyto informace pak bere v úvahu při výběru dalších požadavků čekajících na zpracování.

Parametry pro optimalizaci známé při běhu:

  • P - Aktuální počet dekomponovaných požadavků zpracovávaných v ISSS
  • Pk - Aktuální počet dekomponovaných požadavků na kontext v ISSS
  • I – Aktuální průměrná zátěž ISZR
  • Omezující parametry pro optimalizaci:
  • M – Maximální počet paralelních požadavků vůči ISSS
  • Mk – Maximální počet paralelních požadavků na kontext v ISSS
  • Imax – Maximální zátěž ISZR včetně FAIS HP
  • Počet požadavků, pro které FAIS v daném okamžiku zahájí zpracování:
  • S = Imax – I – P

Zpracování je zahajováno periodicky v definovaných intervalech (konfigurace – řádově sekundy)

Prioritizace požadavků

FAIS v této popisované verzi nepodporuje funkci prioritizace hromadných požadavků.

Prioritizace spočívá v zavedení vhodných mechanismů pro výběr pořadí, v jakém jsou požadavky vybírány ke zpracování. V současné době nejsou jasné požadavky na způsob prioritizace a implementace mechanismů by byla založena na více či měně uměle smyšlených potřebách. Podporu prioritizace bude možné implementovat v budoucnu.

Ošetření výsledku operace

V rámci zpracování výsledku volání ISSS ošetřuje FAIS chybové stavy, které je možné z principu ošetřit na jeho úrovni. Jde o následující stavy:

  • Nedostupnost ISSS
  • Nedostupnost ISZR (v rámci zpracování na ISSS)
  • Nedostupnost PAIS/AISSÚ (v rámci zpracování na ISSS).
  • Ošetření těchto stavů řeší FAIS dočasným pozastavením zpracování v úrovni, která příslušnému stavu odpovídá.
  • V případě nedostupnosti ISSS nebo ISZR pozastavuje FAIS kompletně zpracování hromadných požadavků. Znovuspuštění po zastavení se provádí automaticky pokusem o opakované provedení nejstaršího čekajícího individuálního požadavku.

Poznámka: nedostupnost rozhraní ISZR anebo ISSS je vždy dočasná provozní záležitost, tj. tato událost se ošetří automaticky a není třeba provádět další činnosti. Žadatel, pokud má pochybnosti, může získat informaci o stavu zpracování.

Informace o stavu zpracování je dostupná v administraci FAIS a je možné ji monitorovat prostřednictvím standardních dohledových nástrojů v rámci provozní infrastruktury, viz kapitola Provozní monitoring.

Ostatní chybové stavy jsou propagovány do výsledku zpracování hromadného požadavku pro zdrojový AIS.

Sestavení výsledku pro předání žadateli

Výsledek odpověď pro předání žadateli je dán sjednocením jednotlivých odpovědí individuálních požadavků.

Takto sestavená odpověď, pokud by byla řešena jedním „dokumentem“, by však mohla překročit technické limity pro předání odpovědi prostřednictvím podporovaných rozhraní. Toto FAIS ošetřuje zavedením možnosti dělení odpovědi na části při předání výsledku.

Interně tedy FAIS výsledek nesestavuje průběžně při zpracování ani při dokončení všech individuálních požadavků, ale připravuje jej až v okamžiku, kdy je předáván žadateli, způsob sestavení je uveden v kapitole Předání výsledku zpracování v členění podle možných způsobů předání.

Předání výsledku zpracování

Formát výsledku

Technický výsledek je vždy předáván jako XML dokument, který se skládá z hlavičky, popisující předávaná data a z datové části obsahující výsledky zpracování individuálních požadavků.

V hlavičce je uvedeno:

  • Identifikátor hromadného požadavku
  • Datum, čas a výsledek zpracování
  • Identifikátor výsledku, pořadí výsledku a celkový počet výsledků (počet výsledků je větší než jedna v případě, kdy je překročeno technické omezení pro velikost předávaných dat).

Předání AIFO na výstupu

Seznam AIFO je předáván v případě, že je ve výstupu alespoň jednoho individuálního požadavku uvedena neprázdná MapaAifo.

Předání může být provedeno dvěma způsoby, přičemž pro hromadný požadavek iniciovaný datovou zprávou připadá v úvahu pouze jeden z těchto způsobů:

  • Předání v MapaAifo (pouze pro HP iniciované webovou službou)
  • Předání prostřednictvím úložky AIFO
  • Volbu způsobu předání volí žadatelský AIS při iniciaci HP (viz Řídící data).
  • V případě předaní prostřednictvím MapaAifo obsahuje výstup seznam MapaAifo, kde je každá položka seznamu vázána na konkrétní individuální požadavek prostřednictvím gsbZadostId.
  • V případě předání prostřednictví úložky AIFO obsahuje výstup seznam ID úložek AIFO, kde je každá položka seznamu vázána na konkrétní individuální požadavek prostřednictvím gsbZadostId.

Poznámka: MapaAifo jednotlivých individuálních výsledků nejsou na výstupu slučována do jedné množiny, protože každá odpověď má individuální vazbu.

Předání výsledku webovou službou

Zpracování HP je z pohledu AIS žadatele asynchronní proces. Získání výsledku zpracování HP si ošetřuje žadatelský AIS ve vlastní režii voláním FAIS (popis rozhraní FAIS viz kapitola Rozhraní WS FAIS pro hromadné požadavky) prostřednictvím eGON služby ISZR E153.

Poznámka: WS služby FAIS jsou pro konzumenty zprostředkovány prostřednictvím eGON služby ISZR E153.

Vyzvednutí výsledku žadatelem

V kompetenci AIS žadatele je dotaz na stav zpracování HP. Prostřednictvím WS může AIS žadatele jednak číst stav zpracování HP, jednak získat výsledek zpracování.

AIS žadatele kontroluje periodicky stav zpracování hromadného požadavku. Podle aktuálního stavu zpracování pak přizpůsobuje četnost kontroly.

Periodické čtení stavu a omezení četnosti volání

FAIS implementuje interní mechanismy na řízení zátěže při zpracování HP. Jedním z těchto mechanismů je ochrana proti nadměrnému přetěžování při získávání informací o stavu zpracování, respektive při pokusech o vyzvednutí výsledku dosud nezpracovaného požadavku.

V případě zjištění opakovaného volání operací dotazu na stav požadavku, respektive čtení odpovědi dosud nedokončeného požadavku může FAIS operaci odmítnout bez zahájení jejího provádění.

Důvod odmítnutí z důvodu nadměrného opakování bude uveden v odpovědi pro volající AIS v souladu s implementací požadavku na řízení zátěže na externím rozhraní ISZR.

Podpora asynchronního PUSH režimu na ISSS

Speciální funkcionalitou rozšiřující zpracování HP je podpora asynchronního PUSH režimu ISSS.

FAIS bude podporovat asynchronní režim ISSS s podporou aktivního doručení odpovědi do AIS. V tomto režimu zajistí FAIS iniciaci všech individuálních požadavků na ISSS v asynchronním PUSH režimu, přičemž konzumentem PUSH operace výsledku bude přímo AIS žadatele.

V tomto režimu bude výsledek zpracování individuálního požadavku doručen na žadatelský AIS přímo z ISSS. AIS obdrží výsledek individuálního zpracování ihned po zpracování na ISSS a nemusí čekat na dokončení kompletního zpracování ve FAIS.

Tento režim je řízen prostřednictvím specifikace v řídících datech HP, viz kapitola Identifikace operace.

Příjem asynchronního výsledku z ISSS je standardně definován v dokumentaci ISSS (chování, požadavky na AIS na vystavení cílového bodu pro příjem výsledku, jeho registraci v ISSS , atd.).

Poznámka: ISSS současně s dokončením asynchronního zpracování kromě odeslání výsledku na žadatelský AIS notifikuje o dokončení zpracování i FAIS, viz kapitola Notifikace z ISSS o dokončení individuálního požadavku. V případě neúspěchu notifikace ISSS notifikuje individuální požadavky do FAIS opakovaně v definovaných intervalech, přičemž v případě detekce dočasného selhání konektivity je proces notifikace na straně ISSS uspán a probuzen po definované době.

Předání výsledku datovou zprávou

Výsledek je předán datovou zprávou do datové schránky, ze které byla žádost provedena.

Při předání výsledku je podporována vazba prostřednictvím čísla jednacího, respektive spisové značky, pokud je žadatel specifikoval v jím zaslané iniciační datové zprávě.

Požadavek zpracován

Pokud bude provedena alespoň jedna požadovaná operace, pak bez ohledu na její výsledek bude do výstupní datové zprávy předáno definované XML s výsledkem zpracování.

V případě, že by velikost výsledku překročila maximální povolenou velikost, bude předání provedeno ve více datových zprávách, z XML je patrná informace o rozdělení, aktuální části a celkovém počtu datových zpráv, ze kterých se skládá výsledek.

Požadavek nezpracován

Pokud nebude možné z nějakých důvodů požadavek zpracovat, tzn., že nebude provedena žádná požadovaná operace, bude výstupní datová zprava obsahovat PDF s popisem chyby a současně XML v definované struktuře, obsahující informaci o chybě.

Provozní podpora zpracování hromadných požadavků

Stav zpracování požadavku pro žadatele

Informace o stavu zpracování hromadného požadavku lze získat jak pro požadavky iniciované prostřednictvím webové služby, tak pro požadavky iniciované prostřednictvím datové zprávy. Při čtení informace o stavu hromadného zpracování musí být na vstupu uveden minimálně buď:

  • Identifikátor hromadného požadavku zadaný z AIS (musí být jedinečný v rámci AIS, zabezpečuje AIS).
  • Identifikátor přidělený identifikátor žádosti ve FAIS
  • Identifikátor vstupní datové zprávy (pro žádosti doručené přes ISDS).

Pro získání informace o stavu zpracování je možné použít pouze rozhraní webových služeb. Popis je uveden v kapitole Dotaz na stav požadavku.

Přehled hromadných požadavků

V uživatelském rozhraní FAIS (řídící pult FAIS) je možné zobrazovat přehled hromadných požadavků.

Primárním cílem tohoto přehledu je podpora provozu, pro zobrazení výstupu bude nutné zadat filtry pro zobrazení.

Požadavky bude možné vyhledat:

  • Dle identifikátoru konkrétní operace na vstupu, ve FAIS, v ISZR nebo v ISSS
  • Dle identifikátoru datové zprávy
  • Dle identifikátoru volání webové služby
  • Dle data doručení do DS nebo přijetí WS
  • Zobrazit dosud nedokončené požadavky

Provozní monitoring

API pro provozní monitoring

FAIS v souvislosti s implementací hromadného zpracování vystavuje pro infrastrukturní nástroje monitorovací rozhraní, prostřednictvím kterého lze průběžně monitorovat provozní stav FAIS. V rámci tohoto rozhraní jsou dostupné informace:

  • Stav komunikace FAIS s ISSS/ISZR (dostupný / nedostupný)
  • Stav komunikace ISSS s PAIS/AISSÚ (dostupný / nedostupný)
  • Stav logických front pro jednotlivé kontexty (fronta, počet čekajících požadavků, čas nejstaršího a nejnovějšího požadavku)
  • Počty hromadných požadavků seskupené dle stavu požadavku

Monitorovací rozhraní je dostupné prostřednictvím http protokolu v rámci interní sítě.

Rozhraní tohoto API je dostupné na adrese IszrFaisHPMon/Full v rámci webového rozhraní webových služeb FAIS. Výstupní formát rozhraní je JSON.

Provozní monitoring v ŘP FAIS

Informace o provozním stavu vystavované prostřednictvím API pro provozní monitoring (popsané v předchozí kapitole API pro provozní monitoring) jsou dostupné i v uživatelském rozhraní FAIS.

V ŘP FAIS jsou výše popsané informace dostupné v menu Monitoring / Hromadné požadavky.

Sdílené služby INSPIRE

Popis Sdílených služeb INSPIRE

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

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

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

Pravidla pro Sdílené služby INSPIRE

Stručný přehled povinností pro naplnění technických požadavků INSPIRE (detailně viz Strategie implementace INSIRE):

  1. vytvořit, zpřístupňovat a aktualizovat metadata dat a služeb INSPIRE (v souladu s nařízením (ES) č. 1205/2008); Metadata musí být zpřístupněna na Národní geoportál INSPIRE buď pomocí služby vytvořené nad katalogem každého poskytovatele nebo uložením metadat do katalogu geoportálu. Metadaty je možné popsat i aplikace využívající prostorová data.
  2. zpřístupňovat vyhledávací a prohlížecí síťové služby (v souladu s nařízením (ES) č. 976/2009); Požaduje se vytvořit vyhledávací službu, která umožní vyhledat služby na základě specifikovaných vyhledávacích kritérií, a prohlížecí službu, která umožní datové sady zobrazit.
  3. vytvořit a aktualizovat nově vytvořené nebo rozsáhle rekonstruované datové sady; Požaduje se publikovat prostorová data ve formátu GML dle datových specifikací maximálně do 6 měsíců od počátku jejich platnosti v produkčních databázích, sledovat jejich kvalitu a informace o ní zpřístupnit v metadatech.
  4. zpřístupňovat stahovací a transformační síťové služby (mít je v souladu s nařízením (ES) č. 976/2009); Požaduje se umožnit stahování INSPIRE datových sad on-line (WFS) nebo tzv. předpřipravených datových sad off-line způsobem. Transformační služby musí umožňovat transformovat datové sady neharmonizovaných dat ve formátu GML do požadovaného geodetického referenčního systému. Je požadováno zajistit kvalitu služby a popsat ji v metadatech;
  5. poskytovat přístup k datovým sadám a službám orgánům a subjektům Evropské unie (v souladu s nařízením (EU) č. 268/2010); Požaduje se poskytovat datové sady nebo služby orgánům a subjektům Evropské unie do 20 dnů od doručení žádosti s možností využití standardizované licence.
  6. mít interoperabilní a harmonizované služby prostorových dat v souladu s nařízením (EU) č. 1089/2010; mít v souladu s novelizovaným nařízením (ES) č. 976/2009 služby umožňující spuštění služeb založených na prostorových datech; Požaduje zpřístupnit informace o kvalitě služeb a doplnit ke službám další operace zajišťující interoperabilitu (do října 2020).

Při implementaci technických požadavků Směrnice INSPIRE je nutné náročnosti jednotlivých činností poskytovatelů dat dále rozlišit podle role ve vztahu k tvorbě, správě a rozvoji infrastruktury INSPIRE. Zapojení všech dotčených subjektů do infrastruktury INSPIRE předpokládá jejich rozdělení do různých rolí ve vztahu k prostorovým datům, službám založených na prostorových datech, anebo aplikacím, které jsou nad daty nebo službami vytvořeny. Je samozřejmostí, že jeden poskytovatel může vystupovat ve více rolích:

  • Povinný subjekt (definován v § 2 písm. b) zákona č. 123/1998 Sb.)
  • Jiný poskytovatel (definován v § 11a odst. 3 zákona č. 123/1998 Sb.)
  • Gestor národní datové sady INSPIRE – povinný subjekt odpovědný za konsolidaci a publikaci výsledné národní datové sady INSPIRE, pokud je jediným poskytovatelem pro dané téma příloh Směrnice INSPIRE. V opačném případě koordinuje spolugestory přispívající svými prostorovými daty do obsahu národní datové sady INSPIRE (přesně a úplně definován ve Strategii implementace INSPIRE)
  • Spolugestor národní datové sady INSPIRE - Jeden či více povinných subjektů k danému tématu příloh Směrnice INSPIRE, který odpovídá za harmonizaci příslušné části NDSI (přesně a úplně definován ve Strategii implementace INSPIRE)

Tabulka uvádí základní přehled oblastí, které jsou pro jednotlivé role závazné:

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ě:

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

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

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í.

Informační systém datových schránek

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.

Informační systém Evidence obyvatel

Informační systém Evidence obyvatel (také jako ISEO či AISEO) je upravený zákonem č. 133/2000 Sb., o evidenci obyvatel a rodných číslech a o změně některých zákonů (zákon o evidenci obyvatel), ve znění pozdějších předpisů, patří mezi základní informační systémy veřejné správy a jeho účelem je zpracovávání údajů o obyvatelích České republiky, např. shromažďování a uchovávání těchto údajů a jejich poskytování oprávněným subjektům. Správcem informačního systému evidence obyvatel je Ministerstvo vnitra.

Zpracovateli údajů vedených v informačním systému evidence obyvatel v zákonem stanoveném rozsahu jsou Ministerstvo vnitra, krajské úřady, obecní úřady obcí s rozšířenou působností a ohlašovny, tj. v hlavním městě Praze a ve městech Brno, Ostrava a Plzeň úřady městských částí nebo městských obvodů, pokud tak stanoví statuty těchto měst, a na území vojenských újezdů újezdní úřady.

Uživateli údajů vedených v informačním systému evidence obyvatel v zákonem stanoveném rozsahu jsou:

  • Ministerstvo vnitra (§ 3 odst. 5 zákona o evidenci obyvatel),
  • kraje a krajské úřady, obecní úřady obcí s rozšířenou působností, obce a obecní úřady (§ 3a, 4 a 5 zákona o evidenci obyvatel),
  • Ministerstvo zahraničních věcí (§ 8 zákona o evidenci obyvatel),
  • subjekty, které získávají osobní údaje na základě zvláštních právních předpisů nebo stanoví-li tak mezinárodní smlouva, kterou je Česká republika vázána,
  • obyvatelé (§ 8 odst. 3 a 4 zákona o evidenci obyvatel).

Informační systém evidence obyvatel je jedním z editorů základního registru obyvatel a tedy editorských informačních systémů.

Statistiky z informačního systému evidence obyvatel

Osoby, které mají stejné jméno, příjmení a datum narození:

Aktuální příjmení, jméno a datum narození – živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
4 1 4 Existují 4 osoby, které mají všechny údaje shodné. Tzn. existuje 4x Jan Novák narozen 1.1.1990
3 109 327 Existuje celkem 109 různých kombinací „aktuální příjmení, jméno a datum narození“, které jsou společné vždy pro tři osoby. Tzn. existuje 109x trojice lidí, kteří mají shodné jméno, příjmení a datum narození
2 12 221 24 442 Existuje celkem 12 221 různých kombinací „aktuální příjmení, jméno a datum narození“, které jsou společné vždy pro dvě osoby. Tzn. existuje 12 221x dvojice lidí, kteří mají shodné jméno, příjmení a datum narození
Celkem 12 331 24 773 Existuje cca 25 000 osob, u kterých údaje „aktuální příjmení, jméno a datum narození“ nejsou unikátní.

Rodné příjmení, jméno a datum narození - živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
3 124 372 Existuje celkem 124 různých kombinací „rodné příjmení, jméno a datum narození“, které jsou společné vždy pro tři osoby.
2 12 564 25 128 dtto
Celkem 12 688 25 500 Existuje přes 25 000 osob, u kterých údaje „rodné příjmení, jméno a datum narození“ nejsou unikátní.

Rodné příjmení, jméno a datum narození - živé osoby + zesnulé osoby:

Velikost (n-tice)Četnost n-ticPočet osobPozn.
4 1 4 Existují 4 osoby se stejnými údaji.
3 251 753 Existuje celkem 251 různých kombinací „rodné příjmení, jméno a datum narození“, které jsou společné vždy pro tři osoby.
2 19 487 38 974 dtto
Celkem 19 739 39 731 Existuje cca 40 000 osob (živých+zesnulých), u kterých údaje „rodné příjmení, jméno a datum narození“ nejsou unikátní.
Osoby, které mají stejné jméno, příjmení, datum narození a místo narození:

Aktuální příjmení, jméno, datum narození a místo narození – živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 283 566 Existuje 566 osob, u kterých údaje „aktuální příjmení, jméno, datum narození a místo narození“ nejsou unikátní.

Rodné příjmení, jméno, datum narození a místo narození – živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 322 644 Existuje 644 osob, u kterých údaje „rodné příjmení, jméno, datum narození a místo narození“ nejsou unikátní.

Rodné příjmení, jméno, datum narození a místo narození (v případě zesnulých osob je posuzováno místo úmrtí) – živé osoby + zesnulé osoby:

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 499 998 Existuje 998 osob (živých + zesnulých), u kterých údaje „rodné příjmení, jméno, datum narození a místo narození (popř. místo úmrtí u zesnulých osob)“ nejsou unikátní.
Osoby, které mají stejné jméno, příjmení, datum narození, místo narození a místo trvalého pobytu:

Aktuální příjmení, jméno, datum narození, místo narození a místo trvalého pobytu – živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 10 20 Existuje 20 osob, u kterých údaje „aktuální příjmení, jméno, datum narození, místo narození a místo trvalého pobytu“ nejsou unikátní.

Rodné příjmení, jméno, datum narození, místo narození a místo trvalého pobytu – živé osoby (celkový počet živých osob, nad kterými probíhalo vyhledávání, bylo 10 366 872):

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 12 24 Existuje 24 osob, u kterých údaje „rodné příjmení, jméno, datum narození, místo narození a místo trvalého pobytu“ nejsou unikátní.

Rodné příjmení, jméno, datum narození, místo narození (v případě zesnulých osob je posuzováno místo úmrtí) a místo trvalého pobytu – živé osoby+ zesnulé osoby:

Velikost (n-tice)Četnost n-ticPočet osobPozn.
2 65 130 Existuje 130 osob (živých + zesnulých), u kterých údaje „rodné příjmení, jméno, datum narození, místo narození (popř. místo úmrtí u zesnulých osob) a místo trvalého pobytu“ nejsou unikátní.

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

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

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

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

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

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

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

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

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

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

Katalog eGON služeb ISZR

Vždy aktuální seznam eGON služeb je dostupný na stránkách SZR Katalog eGON služeb. Zde uvedený seznam je platný ke konci ledna 2022.

Jednotlivé eGON služby jsou rozdělený do hlavních kategorií:

  1. Služby založené základních registrech
    1. Služby založené na ROB
    2. Služby založené na ROS
    3. Služby založené na RUIAN
    4. Služby založené na RPP
    5. Služby založené na ORG
    6. Služby založené na ISZR
  2. Služby založené na AIS - tzv. kompozitní služby

Mimo výše zmíněné kategorie existují speciální popisné dokumenty pro specifické sady služeb

 Popis_eGON_služeb-obecné_vlastnosti RUIAN.pdf439.92 KB
 Změny_RÚIAN_-_dopad_do_webových_služeb_ISZR.pdf219.86 KB
 rob-dereference_1.pdf340.55 KB
Kategorie Podrobný popis služby Verze Datum poslední aktualizace
Služby založené na ROB  E01 - robVlozObyvatele.pdf (920,58 KB) 01.00 1. 7. 2016
 E02 - robZmenObyvatele.pdf (924,89 KB) 01.00 1. 7. 2016 
 E03 - robCtiAifo.pdf (482,86 KB) 01.02 12. 12. 2016
 E04 - robAutentizace.pdf (825,48 KB) 01.00 25. 12. 2016
 E05 - robCtiPodleUdaju.pdf1.13 MB 01.03 24. 4. 2017
 E06 - robVymazObyvatele.pdf (872,15 KB) 01.00 25. 12. 2016
 E07_robCtiZmeny.pdf446.98 KB 01.02 13. 12. 2021
 E08 - robCtiHromadneAIFO.pdf (849,33 KB) 01.00 1. 7. 2016
 E15 - robCtiEditora.pdf (424,38 KB) 01.02 13.12. 2016
 E102 - robPoskytnutiJineOsobe.pdf (922,00 KB)  01.00 26. 12. 2016
 E103_robCtiZmenyZaloz.pdf498.92 KB 01.01 13. 12. 2021
 E154_robVypisVyuzitiPoskytnuti.pdf547.32 KB 01.01 12. 12. 2021
 E183 - robOverHromadneAIFO.pdf1.20 MB 01.03 26. 11. 2019
 E274_robVlozObyvatele2.pdf572.85 KB 01.00 12. 12. 2021
 E275_robZmenObyvatele2.pdf579.48 KB 01.00 12. 12. 2021
 E276_robCtiAifo2.pdf506.00 KB 01.00 12. 12. 2021
 E277_robCtiHromadneAifo2.pdf520.35 KB 01.00 12. 12. 2021
 E278_robCtiPodleUdaju2.pdf552.79 KB 01.00 12. 12. 2021
 E279_robOverHromadneAifo2.pdf482.79 KB 01.00 12. 12. 2021 
Služby založené na ROS  E16_rosPridelIco.pdf1.21 MB 01.01 22. 8. 2019
 E17 - rosPridelIcp.pdf (822,01 KB) 01.00 1. 7. 2016
 E18 - rosVlozOsobu.pdf585.81 KB 02.01 15. 3. 2021
 E19 - rosZmenOsobu.pdf541.42 KB 02.01 15. 3. 2021
 E20 - rosCtiIco.pdf543.96 KB 02.04 15. 3. 2021
 E21 - rosCtiAifo.pdf551.17 KB 02.03 15. 3. 2021
 E22 - rosCtiPodleUdaju.pdf542.34 KB 02.03 15. 3. 2021
 E23 - rosZapisDatovouSchranku.pdf (800,12 KB) 01.00 1. 7. 2016
 E24 - rosVymazOsobu.pdf (402,13 KB) 01.00 1. 7. 2016
 E25 - rosVlozProvozovnu.pdf (811,46 KB) 01.00 1. 7. 2016 
 E26 - rosZmenProvozovnu.pdf (718,73 KB) 01.00 27. 12. 2016
 E27 - rosVymazProvozovnu.pdf (795,31 KB) 01.00 1. 7. 2016
 E28 - rosCtiZmeny.pdf524.10 KB 01.01 27. 11. 2020
 E29 - rosCtiSeznamIco.pdf549.07 KB 02.03 15. 3. 2021
 E31 - rosCtiSeznamEditoru.pdf448.45 KB 01.01 15. 3. 2021  
 E253 -_rosVlozOsobu2.pdf455.83 KB 01.00 5. 11. 2020
 E254 - rosZmenOsobu2.pdf434.40 KB 01.00 5. 11. 2020 
 E255 - rosZapisPravniStav2.pdf402.33 KB 01.00 5. 11. 2020 
 E256 - rosCtiIco2.pdf477.69 KB 01.01 23. 11. 2021 
 E257_rosCtiAifo2.pdf456.26 KB 01.01 23. 11. 2021 
 E258_rosCtiSeznamIco2.pdf482.39 KB 01.01 23. 11. 2021 
 E259_rosCtiPodleUdaju2.pdf461.71 KB 01.00 5. 11. 2020 
 E93 - rosZapisPravniStav.pdf 540.83 KB 02.01 15. 3. 2021
 E273_rosZapisKontaktniUdaje.pdf457.46 KB 01.00 8. 11. 2021
Služby založené na RUIAN  E34a_ruianVyhledejPrvekAdresniMisto.pdf640.02 KB 01.05 10. 6. 2019
 E34c_ruianVyhledejPrvekCastObce.pdf623.60 KB 01.05 10. 6. 2019
 E34d_ruianVyhledejPrvekKatastralniUzemi.pdf627.47 KB 01.05 10. 6. 2019
 E34e_ruianVyhledejPrvekKraj.pdf622.58 KB 01.05 10. 6. 2019
 E34f_ruianVyhledejPrvekMomc.pdf631.53 KB 01.05 10. 6. 2019
 E34g_ruianVyhledejPrvekMop.pdf625.71 KB 01.05 10. 6. 2019
 E34h_ruianVyhledejPrvekObec.pdf623.71 KB 01.05 10. 6. 2019
 E34i_ruianVyhledejPrvekOkres.pdf625.67 KB 01.05 10. 6. 2019
 E34j_ruianVyhledejPrvekOrp.pdf620.01 KB 01.05 10. 6. 2019
 E34k_ruianVyhledejPrvekParcela.pdf628.56 KB 01.05 10. 6. 2019
 E34l_ruianVyhledejPrvekPou.pdf620.08 KB 01.05 10. 6. 2019
 E34m_ruianVyhledejPrvekRegionSoudrznosti.pdf629.57 KB 01.05 10. 6. 2019
 E34n_ruianVyhledejPrvekSpravniObvod.pdf627.13 KB  01.05 10. 6. 2019
 E34p_ruianVyhledejPrvekStavebniObjekt.pdf623.10 KB 01.05 10. 6. 2019
 E34q_ruianVyhledejPrvekUlice.pdf628.17 KB 01.05 10. 6. 2019
 E34r_ruianVyhledejPrvekVusc.pdf621.76 KB 01.05 10. 6. 2019
 E34s_ruianVyhledejPrvekZsj.pdf623.21 KB 01.05 10. 6. 2019
 E34t_ruianVyhledejPrvekVolebniOkrsek.pdf452.97 KB 04.04 10. 6. 2019
 E35a_ruianCtiPrvekAdresniMisto.pdf622.95 KB 01.02 19. 12. 2016
 E35c_ruianCtiPrvekCastObce.pdf627.39 KB 01.02 19. 12. 2016
 E35d_ruianCtiPrvekKatastralniUzemi.pdf639.13 KB 01.02 19. 12. 2016
 E35e_ruianCtiPrvekKraj.pdf631.26 KB 01.02 19. 12. 2016
 E35f_ruianCtiPrvekMomc.pdf707.82 KB 01.02 19. 12. 2016
 E35g_ruianCtiPrvekMop.pdf696.25 KB  01.02 19. 12. 2016
 E35h_ruianCtiPrvekObec.pdf637.47 KB 01.02 19. 12. 2016
 E35i_ruianCtiPrvekOkres.pdf623.37 KB  01.02 19. 12. 2016
 E35j_ruianCtiPrvekOrp.pdf623.67 KB  01.02 19. 12. 2016
 E35k_ruianCtiPrvekParcela.pdf626.70 KB 01.02 19. 12. 2016
 E35l_ruianCtiPrvekPou.pdf622.50 KB 01.02 19. 12. 2016
 E35m_ruianCtiPrvekRegionSoudrznosti.pdf628.46 KB 01.02 19. 12. 2016
 E35n_ruianCtiPrvekSpravniObvod.pdf624.26 KB 01.02 19. 12. 2016
 E35o_ruianCtiPrvekStat.pdf620.40 KB 01.02 19. 12. 2016
 E35p_ruianCtiPrvekStavebniObjekt.pdf630.32 KB 01.02 19. 12. 2016
 E35q_ruianCtiPrvekUlice.pdf626.11 KB 01.02 19. 12. 2016
 E35r_ruianCtiPrvekVusc.pdf622.21 KB  01.02 19. 12. 2016
 E35s_ruianCtiPrvekZsj.pdf627.67 KB 01.02 19. 12. 2016
 E35t_ruianCtiPrvekVolebniOkrsek.pdf458.40 KB 01.01 27. 12. 2017
 E36_ruianCtiAdresu.pdf449.54 KB 01.00 1. 7. 2016
 E37 - ruianVyhledejAdresu.pdf (429,02 KB) 01.00 1. 7. 2016
 E38 - ruianCtiSeznamZmen.pdf1.36 MB 01.03 21. 11. 2018
 E39 - ruianSouboryZmen.pdf (851,33 KB) 01.00 26. 12. 2016
 E40 - ruianSouboryDat.pdf (852,54 KB) 01.00 26. 12. 2016
 E249a_ruianVyhledejPrvekAdresniMisto2.pdf565.67 KB 01.00 9. 12. 2020
 E249c_ruianVyhledejPrvekCastObce2.pdf563.57 KB 01.00 9. 12. 2020
 E249d_ruianVyhledejPrvekKatastralniUzemi2.pdf567.30 KB 01.00 9. 12. 2020
 E249f_ruianVyhledejPrvekMomc2.pdf572.44 KB 01.00 9. 12. 2020
 E249g_ruianVyhledejPrvekObvodPrahy2.pdf562.95 KB 01.00 9. 12. 2020
 E249h_ruianVyhledejPrvekObec2.pdf565.13 KB 01.00 9. 12. 2020
 E249i_ruianVyhledejPrvekOkres2.pdf565.51 KB 01.00 9. 12. 2020
 E249j_ruianVyhledejPrvekOrp2.pdf558.52 KB 01.00 9. 12. 2020
 E249k_ruianVyhledejPrvekParcela2.pdf576.25 KB 01.00 9. 12. 2020
 E249l_ruianVyhledejPrvekPou2.pdf560.19 KB 01.00 9. 12. 2020
 E249m_ruianVyhledejPrvekRegionSoudrznosti2.pdf565.67 KB01.00 9. 12. 2020
 E249n_ruianVyhledejPrvekSpravniObvod2.pdf569.26 KB 01.00 9. 12. 2020
 E249p_ruianVyhledejPrvekStavebniObjekt2.pdf561.81 KB 01.00 9. 12. 2020
 E249q_ruianVyhledejPrvekUlice2.pdf567.40 KB 01.00 9. 12. 2020
 E249r_ruianVyhledejPrvekVusc2.pdf559.10 KB 01.00 9. 12. 2020
 E249s_ruianVyhledejPrvekZsj2.pdf562.00 KB 01.00 9. 12. 2020
 E249t_ruianVyhledejPrvekVolebniOkrsek2.pdf562.52 KB 01.00 9. 12. 2020
 E250a_ruianCtiPrvekAdresniMisto2.pdf620.25 KB 01.01 30. 11. 2021
 E250c_ruianCtiPrvekCastObce2.pdf564.44 KB 01.00 9. 12. 2020
 E250d_ruianCtiPrvekKatastralniUzemi2.pdf570.70 KB 01.00 9. 12. 2020
 E250f_ruianCtiPrvekMomc2.pdf575.15 KB 01.00 9. 12. 2020
 E250g_ruianCtiPrvekObvodPrahy2.pdf565.29 KB 01.00 9. 12. 2020
 E250h_ruianCtiPrvekObec2.pdf567.65 KB 01.00 9. 12. 2020
 E250i_ruianCtiPrvekOkres2.pdf561.75 KB 01.00  9. 12. 2020
 E250j_ruianCtiPrvekOrp2.pdf563.99 KB 01.00 9. 12. 2020
 E250k_ruianCtiPrvekParcela2.pdf621.62 KB 01.01 30. 11. 2021
 E250l_ruianCtiPrvekPou2.pdf563.40 KB 01.00 9. 12. 2020
 E250m_ruianCtiPrvekRegionSoudrznosti2.pdf567.68 KB 01.00 9. 12. 2020
 E250n_ruianCtiPrvekSpravniObvod2.pdf564.07 KB 01.00 9. 12. 2020
 E250o_ruianCtiPrvekStat2.pdf562.57 KB 01.00 9. 12. 2020
 E250p_ruianCtiPrvekStavebniObjekt2.pdf631.81 KB 01.01 30. 11. 2021
 E250q_ruianCtiPrvekUlice2.pdf564.79 KB 01.00 9. 12. 2020
 E250r_ruianCtiPrvekVusc2.pdf562.74 KB 01.00 9. 12. 2020
 E250s_ruianCtiPrvekZsj2.pdf566.17 KB 01.00 9. 12. 2020
 E250t_ruianCtiPrvekVolebniOkrsek2.pdf566.84 KB 01.00 9. 12. 2020
 E251_ruianCtiAdresu2.pdf429.23 KB 01.00 9. 12. 2020
 E170 - ruianVyhledejSeznamAMVO.pdf (730,20 KB) 04.02 27. 12. 2016
 E184 - ruianCtiSeznamAdres.pdf (797,00 KB) 01.01 27. 12. 2016
 E185 ruianCtiSeznamZmenAD.pdf1.01 MB 01.00 15. 9. 2019
 E281_ruianVyhledejUup.pdf560.79 KB 01.00  8. 11. 2021
 E282_ruianVyhledejUupEd.pdf 561.67 KB 01.00  8. 11. 2021 
 E283_ruianCtiUup.pdf582.04 KB 01.00  8. 11. 2021
 E284_ruianCtiUupEd.pdf579.23 KB 01.00  8. 11. 2021
Služby založené na ORG  E45 - orgPrihlasAifo.pdf (467,83 KB) 01.00 8. 5. 2015
 E46 - orgOdhlasAifo.pdf (470,50 KB) 01.00 8. 5. 2015
 E69 - orgSpojZIFO.pdf (417,45 KB) 01.00 1. 7. 2016 
 E70 - orgRozdelZIFO.pdf (817,79 KB) 01.00 25. 12. 2016
 E71 - orgZkontrolujAIFO.pdf (410,16 KB) 01.00 14. 12. 2016
 E75 - orgCtiDavkuAIFO.pdf (417,08 KB) 01.00 14. 12. 2016
 E76 - orgPredchudciAIFO.pdf (413,17 KB) 01.00 14. 12. 2016
 E77 - orgRodokmenAIFO.pdf (422,70 KB) 01.00 14. 12. 2016
 E78 - orgCtiZmenyAIFO.pdf (466,56 KB) 01.00 8. 5. 2015
 E95 - orgZalozAIFOPE.pdf (796,78 KB) 01.00 1. 7. 2016 
 E53 - isuiReklamujPrvek.pdf.pdf393.20 KB 01.09 18. 1. 2022
 E199 - orgZjistiAis.pdf (661,47 KB) 01.00 14. 7. 2015
Služby založené na ISZR  E62 - iszrReklamujUdajeRob.pdf (849,43 KB) 01.02 21. 12. 2016
 E63 - iszrReklamujUdajeRos.pdf (943.02 KB) 01.05 5. 2. 2018
 E97 - iszrCtiSeznamCiselniku.pdf (696,38 KB) 01.00 25. 12. 2016
 E99 - iszrAsyncVypisFronty.pdf (365,10 KB) 01.02 13. 12. 2016
  E100 - iszrAsyncOdpovedZFronty.pdf (395,79 KB) 01.03 13. 12. 2016
 E101 - iszrAsyncSmazatFrontu.pdf (352,58 KB) 01.02 13. 12. 2016
 E164 - iszrProbe.pdf (791,58 KB) 04.01 27. 12. 2016
 E166 - iszrAutentizaceAis.pdf (691,89 KB) 01.01 27. 12. 2016
 E175 - iszrUlozMapaAifo.pdf514.80 KB 06.00 16. 6. 2019
 E176 - iszrPodejMapaAifo.pdf502.87 KB 05.00 16. 6. 2019
 E177 - iszrCtiReklamaci.pdf (791,96 KB) 01.02 20. 12. 2016
 E227 - iszrVypisOpravneniPolozky.pdf (699,82 KB) 01.00 10. 5. 2018 
Služby založené na RPP  E105 - rppCtiZmeny.pdf (354,54 KB) 01.02 14. 12. 2016
 E106 - rppVypisSeznamAgend.pdf (365,68 KB) 01.00 1. 7. 2016
 E107 - rppVypisAgendu.pdf (369,16 KB) 01.00 1. 7. 2016  
 E115 - rppVlozRozhodnuti.pdf (735,85 KB) 01.00 27. 12. 2016
 E129 - rppVypisSeznamPusobnostiOVM.pdf (707,04 KB) 01.02 20. 12. 2016
 E130 - rppVypisPusobnostOvm.pdf (701,41 KB) 01.02 20. 12. 2016
 E135 - rppVypisSeznamSluzeb.pdf (697,36 KB) 01.02 20. 12. 2016
 E136 - rppVypisSluzbu.pdf (699,54 KB) 01.02 20. 12. 2016
 E140 - rppVypisSeznamSLA.pdf (689,94 KB) 01.00 26. 12. 2016
 E148 - ppVypisOpravneni.pdf (740,98 KB) 01.02 20. 12. 2016
 E228 – rppVypisOvmSpuu2.pdf (781,86 KB) 01.00 25. 7. 2018
 E229 – rppVypisAgendu3.pdf (784,80 KB) 01.00 2. 9. 2018
 E230 - rppCtiZmenyUkonuNaZadost.pdf (770,88 KB) 01.00 25. 7. 2018
 E231 - rppVypisSeznamUkonuNaZadost.pdf (776,57 KB) 01.00 25. 7. 2018
 E232 – rppVypisUkonNaZadost.pdf (768,55 KB) 01.00 2. 9. 2018
 E233 – rppVypisPusobnostOvm3.pdf (780,33 KB) 01.00 25. 7. 2018
 E244 – rppVypisSeznamUdajuAgendy.pdf1.03 MB 01.00 20. 11. 2019
 E245-rppVypisPusobnostOvm4.pdf1.05 MB 01.00 1. 4. 2020
 E246-rppVypisAgendu4.pdf1.04 MB 01.00 1. 4. 2020
 E247-rppVypisUkonNaZadost2.pdf1.04 MB 01.00 1. 4. 2020
 E260_rppVypisAgendu5.pdf399.03 KB 01.00 5. 12. 2020
 E261_rppVypisPusobnostOvm5.pdf410.67 KB 01.00 5. 12. 2020
 E262_rppCtiZmenySluzebVs.pdf434.50 KB 01.00 5. 12. 2020
 E263_rppVypisSluzbuVs.pdf412.02 KB 01.00 5. 12. 2020
 E264_rppVypisSeznamSluzebVs.pdf445.97 KB 01.00 5. 12. 2020
 E210 - rppVypisSeznamOvmSpuu.pdf (801,34 KB) 01.00 21.7. 2017
 E211 - rppVypisOvmSpuu.pdf (793,86 KB) 01.01 2. 9. 2018 
 E214 - rppVypisSeznamKategoriiOvmSpuu.pdf (767,25 KB) 01.00 25. 7. 2017 
 E215 - rppVypisKategoriiOvmSpuu.pdf (765,23 KB) 01.00 26. 7. 2017 
 E218 - rppCtiZmenyOvmSpuu.pdf (764,19 KB) 01.00 23. 7. 2017
 E219 - rppCtiEditoraOvmSpuu.pdf (756,78 KB) 01.00 24. 7. 2017 
Služby založené na AIS – kompozitní služby
Agendový informační systém evidence obyvatel  E158 - aiseoZtotozneni.pdf (765,50 KB) 04.01 27. 12. 2016
 E171 - aiseoCtiAifo2.pdf (795,86 KB) 04.01 27. 12. 2016
 E172_aiseoCtiPodleUdaju2.pdf503.57 KB 05.00 14. 6. 2021
Agendový informační systém cizinců  E162 - aiscCtiAifo.pdf591.28 KB 01.01 20. 3. 2018
 E163 - aiscCtiPodleUdaju.pdf599.56 KB 01.01 20. 3. 2018
 E173 - aiscCtiAifo2.pdf569.23 KB 01.00 26. 11. 2019
 E174 - aiscCtiPodleUdaju2.pdf566.74 KB 01.00 20. 11. 2019
Evidence občanských průkazů  E188 - eopCtiAifo.pdf1.20 MB 02.03 26. 8. 2019
 E191 - eopCtiHromadneAifo.pdf1.16 MB 02.03 26. 8. 2019
E194 - eopCtiPodleUdaju.pdf1.09 MB 02.03 24. 8. 2019
 Evidence cestovních dokladů E189 - ecdCtiAifo.pdf1.13 MB 02.02 26. 8. 2019
E192 - ecdCtiHromadneAifo.pdf1.12 MB 02.02 26. 8. 2019
E195 - ecdCtiPodleUdaju.pdf1.14 MB 02.02 26. 8. 2019
Získání fotografie a podpisu fyzické osoby E197 - agendaMediaDataCtiAifo.pdf452.08 KB 01.05 18. 7. 2018
E198 - agendaMediaDataCtiPodleUdaju.pdf468.25 KB 01.03  26. 9. 2017
Elektronická identita - překlad BSI  E226 - eidentitaCtiAifo.pdf (707,01 KB) 01.00  29. 11. 2017
AIS Působnostní RPP  E235 – aispVypisSeznamIs.pdf (713.39 KB) 01.00 4. 2. 2019
 E236 – aispVypisDetailIs.pdf (712.96 KB) 01.00 4. 2. 2019
 E237 – aispCtiZmenyIs.pdf (706.85 KB) 01.00 4. 2. 2019
E265_aispVypisSeznamIsV2_1.00.pdf413.66 KB 01.00 5. 12. 2020
E266_aispVypisDetailIs2_1.00.pdf407.42 KB 01.00 5. 12. 2020
Informační systém katastru nemovitostí  E238 – isknCtiVlastniky2.pdf491.83 KB 01.00 15. 7. 2020
E242d – isknCtiPrvekKDatuKatastralniUzemi.pdf1.16 MB 01.01 26.11.2019
E242k – isknCtiPrvekKDatuParcela.pdf1.15 MB 01.01 26.11.2019
 E94 - isknReklamujPrvek.pdf (1,37 MB) 01.00 14. 11. 2017
Informační systém územní identifikace  E252a_isuiCtiPrvekAdresniMistoKDatu2.pdf520.13 KB 01.00 9. 12. 2020
 E234 – isuiVyhledejParceluGP.pdf 435.11 KB 01.00 29.10.2018
E252c_isuiCtiPrvekCastObceKDatu2.pdf516.27 KB 01.00 9. 12. 2020
E252f_isuiCtiPrvekMomcKDatu2.pdf529.78 KB 01.00 9. 12. 2020
E252g_isuiCtiPrvekObvodPrahyKDatu2.pdf516.06 KB 01.00 9. 12. 2020
E252h_isuiCtiPrvekObecKDatu2.pdf521.06 KB 01.00 9. 12. 2020
E252i_isuiCtiPrvekOkresKDatu2.pdf515.16 KB 01.00 9. 12. 2020
E252j_isuiCtiPrvekOrpKDatu2.pdf516.33 KB 01.00 9. 12. 2020
E252l_isuiCtiPrvekPouKDatu2.pdf518.38 KB 01.00 9. 12. 2020
E252m_isuiCtiPrvekRegionSoudrznostiKDatu2.pdf521.36 KB 01.00 9. 12. 2020
E252n_isuiCtiPrvekSpravniObvodKDatu2.pdf514.37 KB 01.00 9. 12. 2020
E252o_isuiCtiPrvekStatKDatu2.pdf515.83 KB 01.00 9. 12. 2020
E252p_isuiCtiPrvekStavebniObjektKDatu2.pdf522.22 KB 01.00 9. 12. 2020
E252q_isuiCtiPrvekUliceKDatu2.pdf517.46 KB 01.00 9. 12. 2020
E252r_isuiCtiPrvekVuscKDatu2.pdf515.94 KB 01.00 9. 12. 2020
E252s_isuiCtiPrvekZsjKDatu2.pdf516.55 KB 01.00 9. 12. 2020
E285_isuiCtiUupKDatu.pdf558.12 KB 01.00 8. 11. 2021 
E286_isuiCtiStavReklamace.pdf517.99 KB  01.00  8. 11. 2021

Integrovaná Telekomunikační Síť

Ministerstvo vnitra vybudovalo v předešlých obdobích Integrovanou Telekomunikační Síť (ITS) zajištující základní potřeby komunikace Policie, Hasičů a záchranných složek (dále také IZS ČR) k zajištění bezpečnosti občanů ČR a výkonu veřejné správy na území České republiky. ITS se v průběhu let modernizovala tak, že v současné době slouží, jak pro potřeby Policie a IZS ČR tak pro potřeby pokrytí potřeb výkonu přenesené působnosti samosprávy v území. MVČR působí jako správce a poskytovatel KIVS(Komunikační infrastruktura veřejné správy)/CMS(Centrální místo služeb).

Geograficky ITS propojuje krajská města v České republice v kruhu, s propustností až 10Gb a dále nově pokrývá až na úroveň okres jednotlivá pracoviště veřejné správy. Přípojnými body k ITS jsou krajské konektory v jednotlivých krajích a 77 okresních měst v  ÚO PČR (územní odbor Policie ČR, bývalé okresní ředitelství Policie).

Potřeba komunikace mezi centrálními úřady a jejich územními složkami neustále stoupá.

Příklad úřadů v území:

  • Policie ČR, Hasiči, Záchranka
  • Úřad obce s rozšířenou působností
  • MPSV – úřady práce
  • ČSSZ – okresní správa sociálního zabezpečení
  • GFŘ – Finanční úřady
  • GŘC – Celní správa
  • MSp – Soudy
  • ČUZK - Pozemkové a katastrální úřady
  • MZ – Krajské Hygienické stanice
  • MŠMT - Školská zařízení

Každá z těchto organizací viz. výše využívá pro komunikaci vlastní síť založenou na vlastních, pronajatých, nebo KIVS linkách. Cílem je nastartování procesu sdílení komunikačních sítí na principu jedné robustní komunikační sítě s přípojnými body v krajích a okresech, na které se připojují metropolitní sítě jednotlivých měst a obcí.

Průlomem pro využití sdílených komunikací bylo jednání 9.6.2020 zástupců MVČR a Policie na Policejním prezidiu, kde proběhlo odsouhlasení připojování metropolitních sítí obcí k ITS. Důsledkem tohoto jednání je možnost samosprávy se prostřednictvím ITS připojit ke službám publikovaných v CMS2.

Metropolitní a krajské sítě samosprávy ideálně propojují jednotlivé úřady v území (viz výše), které prostřednictvím CMS čerpají centrální agendy státu.

Do dnešního dne bylo vybudováno 5 krajských sítí (Vysočina, Plzeň, Karlovy vary, Zlín a částečně Pardubice) a jednotky metropolitních sítí (Chomutov, …) z prostředků EU.

Pro další plánované období IROP 2021-2027 jsou plánovány prostředky a programy pro další budování metropolitních a krajských sítí a posílení komunikace páteřní sítě ITS a Centrálního místa služeb.

Jednotné obslužné kanály úř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.

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

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 Ministerstvo vnitra. Na základě znění zákona zavedení jakékoli osoby do tohoto autentizačního informačního systému vyžaduje její jednoznačné ztotožnění oproti základnímu registru obyvatel. Ministerstvo dále spravuje prostředky pro autentizaci, které vydává.

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

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ů.

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.

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 není momentálně k dispozici z důvodu probíhajících prací na jeho aktualizaci. Děkujeme za pochopení.

{{url>https://app.powerbi.com/view?r=eyJrIjoiOTNiOGM3NzUtMzRhOC00NjUzLWI4MGYtZmZjMTY4MzQ2NjM0IiwidCI6IjFkYjQxZDZmLTFmMzctNDZkYi1iZDNlLWM0ODNhYmI4MTA1ZCIsImMiOjh9 100%,1000}}

Katalog služeb veřejné správy

Co je katalog služeb

Katalog služeb veřejné správy (VS) vznikl na základě zákona o právu na digitální služby. Jeho smyslem je na jednom místě poskytnou kompletní přehled všech existujících služeb VS. Za tímto účelem:

  • inventarizuje všechny služby, jejich úkony (transakce) a obslužné kanály (způsoby vyřízení)
  • popisuje služby srozumitelným jazykem

Jednotný popis je přínosem jak pro klienta, tak i pro poskytovatele (zaručené a aktuální informace od garanta služby).

Katalog služeb slouží k evidenci služeb, poskytování informací o jednotlivých službách a k plánování jejich digitalizace. Služby evidované v Katalogu služeb a jejich úkony charakteru podání mají být, dle příručky pro plánování digitalizace, povinně dostupné pomocí určených digitálních kanálů.

Veškerá data v katalogu služeb je možné procházet pomocí Power BI nástěnky.

Služba vedená v katalogu

  • Představuje funkci nebo činnost úřadu, která je vědomě poskytnuta konkrétním orgánem veřejné moci (OVM) konkrétnímu příjemci služby podle příslušného právního předpisu. Služba přináší příjemci vnímanou hodnotu, ať už v podobě benefitu nebo splnění zákonné povinnosti.
  • Na službu VS lze také pohlížet jako na dosažení práva či naplnění povinnosti klienta, které nelze splnit jinak než interakcí či sérií interakcí mezi klientem a OVM.
    • Proto se evidují pouze služby, kde dochází k interakci mezi OVM a klientem či obráceně.
    • Naopak neevidují se služby, kde dochází pouze interakci mezi OVM a OVM.
  • Každá služba se dále skládá z nejméně jednoho úkonu. Služby také dělíme podle toho, zdali jsou:
    • iniciovány klientem
    • nebo vykonávány z moci úřední.

Proces vytvoření katalogu služeb VS

Evidence služeb VS představuje inventarizaci všech služeb, které poskytují OVM. K přesnější kategorizaci slouží řada atributů, které se pro každou službu vyplňují. Následně pro každou službu vzniká detailní popis - uživatelsky přívětivý text, jak se služba vyřizuje.

Zákonné zmocnění

Povinnost provést evidenci služeb je specifikována v § 51 odst. 6 písm. d) a e) zákona č. 111/2009 Sb., o základních registrech. Zatímco zákon o právu na digitální služby se omezuje na digitální služby/úkony, zákon o základních registrech požaduje evidovat i ty nedigitální. Povinnost provést detailní popis služeb je specifikována v § 51 odst. 6 písm. f) a g) zákona č. 111/2009 Sb., o základních registrech. Popis se má provést dle vyhlášky č. 515/2020 Sb., kterou konkretizuje metodika uvedená níže.

Zákon o právu na digitální služby tyto údaje souhrnně nazývá katalog služeb. Jinými slovy: pro každou agendu je nutné vyplnit katalog služeb.

1. Evidence služeb VS

Ohlašovatel agendy ručně vyplní evidenci služeb a úkonů do AIS RPP Působnostní.

Postup při evidování služeb VS:

  • Prostudování metodiky pro evidenci služeb.
  • Projít právní předpisy upravující agendu.
  • Identifikovat služby VS dle definičních znaků v metodice.
  • Ke každé službě popsat její atributy podle metodiky.

Tipy:

2. Vyplnění detailního popisu služby

Pro každou službu je nutné vytvořit tzv. detailní popis. Jedná se o uživatelsky přívětivé texty, které je nutné vytvořit, aby byla splněna informační povinnost vyplývající ze zákona o právu na digitální služby, zákona o svobodném přístupu k informacím a dalších (podrobněji rozvedeno v metodice). Předpokladem pro vyplňování popisů je schválení evidence služeb v AIS RPP Působnostní.

Detailní popisy obsahují především informace o tom, komu je služba určena a jakým způsobem je možné jí vyřídit.

Postup vypracování detailních popisů:

  1. Prostudování metodiky|. Informační seminář můžete zhlédnout na této stránce.
  2. Zařízení přístupu do redakčního systému AIS RPP Správa katalogů (AISK). Potřebná oprávnění a návod k používání systému naleznete v uživatelské příručce k AISK.
  3. Na začátek doporučujeme vyplnit a odeslat ke schválení 2-3 popisy. Po jejich schválení ze strany DIA pak bude jasnější, jakým způsobem vyplňovat i ty ostatní.

Pravidla pro vyplnění detailních popisů služeb vykonávaných z moci úřední se liší od těch iniciovaných klientem a rozdíly naleznete vysvětlené v metodickém pokynu k detailním popisům služeb vykonávaných z moc úřední. Hlavním rozdílem je, že velká část atributů, které se vyplňují jsou v případě služeb z moci úřední nepovinné.

V ideálním případě by měl popisy vyplňovat věcný gestor, který agendu zná. Autor popisů by také měl mít přímo zařízený vstup do AISK. Pro přístup není nutné zřizovat komerční certifikát, vstup je řízen přes Identitu občana. Je tedy možné využít např. i bankovní identitu nebo mobilní klíč eGovernmentu.

V oprávněných případech je možné převést detailní popis na jiné OVM. Takové situace nastávají především pokud danou agendu nebo její část vykonává jiný úřad podřízený ministerstvu.

Kontaktní osobou pro problematiku detailních popisů je Martin Kryšpín Vimmr (martin.vimmr@dia.gov.cz).

Časté dotazy

Co se stane, pokud katalog služeb nebude po 1. 2. 2025 kompletní? Pro rozbalení nebo schování klikněte

Co se stane, pokud katalog služeb nebude po 1. 2. 2025 kompletní? Pro rozbalení nebo schování klikněte

Pokud nějaká služba nebo úkon bude v katalogu služeb chybět, nestanovuje-li jiný zákon jinak, je možné danou službu nebo úkon řešit i digitálně. (Vizte § 14 odst. 5 zákona č. 12/2020 Sb., o právu na digitální služby). Uživatel služby se tedy od 1. 2. 2025 bude oprávněně domáhat činit vše, co v katalogu služeb nenalezne, jako digitální úkon, pokud to povaha tohoto úkonu nebo jiný zákon nevylučuje.

Jak se zveřejňují elektronické formuláře dle zákona č. 12/2020 Sb.? Pro rozbalení nebo schování klikněte

Jak se zveřejňují elektronické formuláře dle zákona č. 12/2020 Sb.? Pro rozbalení nebo schování klikněte

Odkaz na elektronický formulář dle § 4, odst. 3 zákona č. 12/2020 Sb., o právu na digitální služby (ZoPDS), se zveřejňuje v rámci detailního popisu služby. Jde o atributy:

  • Název transakčního portálu
  • Odkaz na službu na transakčním portálu

Elektronický formulář dle ZoPDS je takový formulář, který po přihlášení přes prostředky NIA zajistí předvyplnění údajů uživatele služby.


Publikace dat z katalogu služeb

Možnosti práce s daty z katalogu služeb

Hotové texty se publikují na gov.cz a pro další využití se zveřejňují i v podobě otevřených dat a přes zvláštní rozhraní (API).

1. Práce s XLS jednotlivých agend

  • Rozcestník slouží ke stažení souboru XLS k vybrané agendě.
  • Data k jednotlivým agendám se denně aktualizují.
Výhody Nevýhody
1:1 k datům v AIS RPP Působnostnípotřeba omezovat pouze na aktuální agendy (obsahuje také minulé a ukončené agendy)
kompletní data parsing dat (příklad práce s parsingem XLS)
obsahuje i budoucí verze agend

2. API ke katalogu služeb

  • API ke katalogu služeb je možné najít zde. Data se denně aktualizují.
  • Primárně slouží pro detailní popisy služeb (viz výše).
Výhody Nevýhody
Standardizované API jen údaje o službách (chybí úkony a obslužné kanály)
GraphQL (definice výstupu již při dotazu)zatím nedisponuje dokumentací

3. Otevřená data

Výhody Nevýhody
data jsou ve formátu JSON pokud má platná agenda i budoucí verzi, není v datech (platí i pro katalog služeb)
existuje dokumentace chybí důvody nevhodnosti digitalizace
k dotazům lze využít API-SPARQL endpoint (ukázky dotazů je možné najít zde)

Procházení dat v katalogu služeb

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ů:

  1. 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).
  2. Prostřednictvím metropolitních sítí připojených např. na Integrovanou telekomunikační sít (ITS) MVČR.
  3. 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.
  4. 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ů:

  1. 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).
  2. Prostřednictvím metropolitních sítí připojených např. na Integrovanou telekomunikační sít (ITS) MVČR.
  3. 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.
  4. 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:

  1. Spojení realizovaná prostřednictvím kryptografických prostředků přes veřejný internet nejsou vhodná jako primární způsob čerpání služeb, které mají mít garantovanou funkčnost a dostupnost. Systém CDBP je koncepčně založen na předpokladu provozu na vyhrazené síti, která je zcela oddělena od běžného internetového provozu a tomu odpovídá i úroveň jeho zabezpečení.
  2. V rámci spojení realizovaných prostřednictvím veřejného internetu není možné dostatečným způsobem garantovat následující:
    • požadavek na dostupnost, protože internet není zaručeně garantované přenosové prostředí s definovanými SLA,
    • požadavek na propustnost, protože systém CDBP využívá na ORP "těžkého" klienta se vzdálenou správou; nezbytná je tedy komunikace oběma směry (centrum systému CDBP – ORP a ORP – centrum systému CDBP) pro instalací nových verzí aplikace pomocí "balíčků" o velikosti cca 500 MB/PC a pro stahováním logů z PC o velikosti cca 100 MB/PC,
    • požadavek na fungování protokolu WoL, který umožňuje dálkové „probouzení“ jednotlivých pracovních stanic systému CDBP bez zásahu obsluhy, je nezbytný z důvodů distribuce nových verzí SW, stahování logů či jiných činností souvisejících s provozem Systému CDBP.
  3. Na základě výše uvedeného reálně hrozí, v případě využití IPsec, riziko výpadků spojení při pořizování žádostí o občanské průkazy a cestovní pasy, což může vést ke zpomalení nebo úplné nedostupnosti pracovišť systému CDBP. V případě, že by v důsledku užívání IPsec, nebylo možné dálkově nainstalovat na koncová pracoviště systému CDBP aktualizace, bude nezbytné, aby instalaci provedl technik při výjezdu, který by úřad musel uhradit.

CMS, popis zahrnutých služeb

Odbor Hlavního architekta eGovernmentu a Ministerstvo vnitra v rámci svých kompetencí požaduje od jednotlivých správců ISVS, aby služby ISVS publikovaly v rámci Centrálního místa služeb – CMS (služba CMS2 -02, CMS2 -04).

Jednotliví uživatelé ISVS na úrovní státní správy a samosprávy služby těchto systémů konzumují, resp. k ISVS přistupují výhradně prostřednictvím CMS (služba CMS2 -03).

Služba CMS2 – 02 – Zveřejnění aplikace
Název parametru Vysvětlení
Kód služby CMS2-02
Název služby Zveřejnění aplikace
Popis služby Služba vytvoří prostředí pro publikaci aplikační služby informačního systému OVM. Varianty služby se liší podle cílového prostředí. Možné varianty jsou: 1. do sítě Internet 2. do sítě CMS 3. do sítě TESTA-ng 4. do Extranetu

Aplikační služba může být umístěna v infrastruktuře orgánu nebo v infrastruktuře Národního datového centra (NDC). Aplikační služba může být zveřejněna do více prostředí současně. Aplikační služba je zveřejněna na definovaných protokolech a portech.

Při zveřejnění aplikace do sítě Internet jsou aplikaci přiděleny veřejné IP adresy z prostoru CMS. Přístup ke zveřejněné službě může být omezen na definované zdrojové IP adresy.

Při zveřejnění aplikace do sítě CMS jsou aplikaci přiděleny privátní IP adresy z prostoru CMS (Konsolidované IP adresy). Službu je možné zveřejnit pro všechny ostatní subjekty připojené do sítě CMS (Veřejná služba) nebo pro definované subjekty a skupiny subjektů (Schvalovaná služba). O přístup ke Schvalované službě musí přistupující subjekty žádat prostřednictvím služby CMS203-1.

Při zveřejnění aplikace do sítě TESTA-ng (síť EU)1) 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.

Kontext eGSB/ISSS

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

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

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

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

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

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

Konceptuální modely kontextů

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

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

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

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

Seznam kontextů

Detailní seznam kontextů je dostupný na adrese https://egsbkatalog.cms2.cz/. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.

PořadíKód Název
1 A1029.1 Pojištěnec
2 A1029.2 Osoba samostatně výdělečně činná
3 A1029.3 Zaměstnavatel
4 A1029.4 Územně organizační jednotka
5 A1041.2001 Osoba - doklady
6 A1041.4001 Provozovatel plavidla - plavidla
7 A1041.4004 Vlastník plavidla - plavidla
8 A1041.9001 Osoba - doklady, plavidla
9 A1046.1 Řidič - podklady pro podání žádosti o řidičský průkaz
10 A1046.2 Řidič - podání žádosti o řidičský průkaz
11 A1046.2001 Osoba - zkoušky řidiči
12 A1046.3 Řidič - registrace k notifikacím změn bodového hodnocení
13 A1046.4 Řidič - osvědčení o digitálním úkonu
14 A1046.RidicRozsirene Řidič - rozšířené údaje
15 A1046.RidicZakladni Řidič - základní údaje
16 A1046.RidicZakladni Řidič - základní údaje
17 A1061.1 NBU Avizace
18 A120.1 Předání a zneplatnění ÚZ
19 A121.1 Přehled o údajích autentizované osoby
20 A121.2 Výpis údajů podnikatelského subjektu
21 A124.1 ISKN - Evidence práv pro osobu
22 A124.2 ISKN - List vlastnictví
23 A1341.1 Ověření v.z.p. pojištěnce
24 A1341.2 Oznámení OSVC PP
25 A1341.3 Oznámení OSVC PP ZP
26 A1341.4 Seznam OSVC PP
27 A1381.1 Vozidlo v Systému Elektronického Mýtného
28 A1381.2 Zahraniční provozovatel vozidla v Systému Elektronického Mýtného
29 A344.1 Notifikace prostřednictvím Portálu Občana
30 A3726.1 Pacient
31 A385.1 Oznámení OSVC PP
32 A385.2 Seznam OSVC PP
33 A385.3 Výpis z Daňové Informační Schránky
34 A385.4 Oznámení stavu účetní závěrky
35 A385.5 Výpis prijmů z Daňového priznami
36 A392.1 Dlužník
37 A392.2 ODU
38 A392.3 Nedoplatky dle ukladatele
39 A4003.1 Poskytovatelé zdravotních služeb
40 A4003.2 Zdravotnická dokumentace pacienta
41 A418.1 Osoba v pátrání
42 A418.2 Vozidlo v pátrání
43 A418.3 NBU Lustrace
44 A476.1 Registr ISIN
45 A483.1 Výpis údajů z Rejstříku trestů
46 A561.1 Výzva
47 A561.2 Projekt
48 A561.3 Vypočtené indikátory
49 A575.1 IS ÚCL
50 A8566.1 Notifikace
51 A998.1 Registr silničních vozidel

Seznam datových obsahů kontextů

Termínem datové obsahy se rozumí definice XML schémat popisujících rozhraní pro dotazování publikačních AIS, které publikují data v rámci jimi vedených agend prostřednictvím eGSB/ISSS.

PořadíKód Název
1 1 Žádost o poskytnutí údajů o vozidle z evidence Systému Elektronického Mýtného.
2 2 Žádost o poskytnutí údajů zahraničního provozovatele vozidla z evidence Systému Elektronického Mýtného.
3 A124.1.PravaProOsobu Dotaz práva osoby vedená v KN
4 A124.2.ListVlastnictvi Dotaz na list vlastnictví v KN
5 A344.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele Portálu Občana
6 A8566.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele
7 CRRDotaz Dotaz do registru řidičů
8 CrrOsvedceniDigiUkon Osvědčení o digitálním úkonu
9 CrrRidicNotifikaceBoduReg Registrace k notifikacím změn bodového hodnocení
10 CrrRidicRozsirene Dotaz do CRŘ na rozšířené údaje o řidiči
11 CrrRidicUdaje Dotaz do CRŘ na údaje o řidiči
12 CrrRidicZadostPodani Podání žádosti o řidičský průkaz
13 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
14 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
15 CSCEPANDLUZNIK Dotaz na nedoplatky do evidence přeplatků a nedoplatků Celní správy
16 CSCEPANNEDOPLATKYDLEUKLADATELE Dotaz na evidované nedoplatky podle ukladatele u Celní správy
17 CSCEPANODU Dotaz na stav osobního daňového účtu do evidence přeplatků a nedoplatků Celní správy
18 CSSZOsvc Dotaz do ČSSZ na údaje o OSVČ
19 CSSZPojistenec Dotaz do ČSSZ na údaje o pojištěnci
20 CSSZUoj Dotaz do ČSSZ na údaje o Územně organizační jednotce
21 CSSZZamestnavatel Dotaz do ČSSZ na údaje o Zaměstnavateli
22 DAPPRIJEM Dotaz na prijmy z Daňového přiznání
23 DISDOTAZ Dotaz na výpis z Daňové Informační Schránky
24 DISZADOST Žádost na výpis z Daňové Informační Schránky
25 EtestyOsobaZkousky Dotaz do IS eTesty na vykonané zkoušky odborné a profesní způsobilosti.
26 EVIDOSVC EvidenceOSVC
27 FormularePOCti Formuláře Portálu občana - čtení
28 FormularePOZapis Formuláře Portálu občana - čtení
29 INFPREHL Informovani o DAP
30 KALENDAR Dotaz na výpis z Daňové Informační Schránky
31 KONTROLAOSVC Kontrolní zjištění OSVČ
32 KONTROLAZC Kontrolní zjištění závislé činnosti
33 MSProjekt Projekt
34 MSVypIndi Vypočtené indikátory
35 MSVyzva Výzva
36 NBU_Lustrace NBU Lustrace
37 NBUAVIZACE NBU Avizace
38 OBNOVENISVC385 Opětovné zahájení SVČ
39 PaisCtiRSVKontexty Dotaz na vozidlo
40 PaisRsvCtiAifo Dotaz na vozidlo
41 PaisRsvCtiFormular Formuláře - čtení
42 PaisRsvCtiIco Dotaz na vozidlo
43 PaisRsvCtiNovaEkoVozidla Dotaz na vozidlo
44 PaisRsvCtiNovaEkoVozidlaAsync Dotaz na vozidlo
45 PaisRsvCtiOrv Dotaz na vozidlo
46 PaisRSVCtiOsvedceniFormular Dotaz na vozidlo
47 PaisRsvCtiPoplatek Suma poplatku
48 PaisRsvCtiPrilohu Dotaz na vozidlo
49 PaisRsvCtiRz Dotaz na vozidlo
50 PaisRsvCtiSazebnikPoplatku Sazebník poplatků
51 PaisRsvCtiSeznamFormularu Seznam registračních míst z RSV
52 PaisRsvCtiSeznamIcoAsync Dotaz na vozidlo
53 PaisRsvCtiSeznamRcAsync Dotaz na vozidlo
54 PaisRsvCtiSeznamRm Seznam registračních míst z RSV
55 PaisRsvCtiTp Dotaz na vozidlo
56 PaisRsvCtiVin Dotaz na vozidlo
57 PaisRsvCtiVozidloId Dotaz na vozidlo
58 PaisRsvCtiZmeny Dotaz na vozidlo
59 PaisRsvCtiZmenyAsync Dotaz na vozidlo
60 PaisRsvVlozPrilohu Formuláře - vložení přílohy
61 PaisRsvVozidlaAsyncOdpoved Dotaz na vozidlo
62 PaisRsvZamkniFormular Formuláře - zamknutí
63 PaisRsvZapisFormular Formuláře - zápis
64 PaisRsvZapisInformaceOPlatbe Zápis informací o platbě
65 PATRMV Dotaz na vozidlo v pátrání
66 PATROS Dotaz na osobu v pátrání
67 PDFCertifikatu Dotaz na certifikát tazatele v PDF
68 PODANPREHLED Podán přehled OSVCPP ZP
69 PODANPREHLED385 Podán přehled OSVCPP ZP
70 PONDUKONC Podnět ukončení
71 PONDUKONC385 Podnět ukončení
72 PREHLEDPLATEB Přehled plateb
73 PREVYSUZVESL Oznámení stavu účetní závěrky
74 RTFODotaz Dotaz do Rejstříku trestů
75 RTNastaveniBlokace Požadavek do Rejstříku trestů na vytvoření, popř. zrušení blokace
76 RTZadosti Dotaz do Rejstříku trestů
77 RTZadostiDokument Požadavek do Rejstříku trestů na vystavení výstupního dokumentu.
78 RTZadostiStav Dotaz do Rejstříku trestů na stav manuálně zpracovávaných žádostí.
79 SeznamCertifikatu Dotaz na certifikáty tazatele
80 SEZNAMOSVCPP Seznam OSVCPP
81 SEZNAMOSVCPP385 Seznam OSVCPP
82 SeznamPoskytovatelu Seznam poskytovatelů s dostupnou zdravotnickou dokumentací osoby
83 SPSOsobaDoklady Dotaz do IS SPS na průkazy způsobilosti, které vlastní.
84 SPSOsobaDokladyPlavidla Dotaz do IS SPS na průkazy způsobilosti a vlastněná/provozovaná plavidla.
85 SPSProvozovatelPlavidla Dotaz do IS SPS na plavidla, která provozuje.
86 SPSVlastnikPlavidla Dotaz do IS SPS na plavidla, která osoba vlastní.
87 UCETNIZAVERKA Předání a zneplatnění ÚZ
88 UclUdaje Dotaz na údaje z IS ÚCL
89 UKONCENI Ukonceni
90 Vozidlo Dotaz na vozidlo
91 VYPFOISVS Dotaz na osobu podle zákona 365/2000 Sb.
92 VypisVozidelPDF Výpis vozidel v PDF
93 VYPOOCRP Dotaz na ověření osoby vůči CRP
94 VYPSUBJISVS Dotaz na subjekt podle zákona 365/2000 Sb.
95 ZadostOVypis Žádost o výpis
96 ZAPOSVCPP Zápis OSVC PP
97 ZdravotnickaDokumentace Dokument se zdravotnickou dokumentací pacienta
98 ZMENACISPOJ Změna čísla pojištěnce
99 ZMENACISPOJ385 Změna čísla pojištěnce

Mandáty a zastupování v elektronické komunikaci

Zajištění správného obsazení identifikovaného a autentizovaného klienta do agendové aplikační role interpretovatelné přistupovaným AISem při vykonávání elektronického úkonu neboli jinými slovy autorizace klienta využívajícího elektronické (digitální) služby veřejné správy, je jedním ze základních předpokladů správného fungování těchto služeb.

Uživatelé služeb veřejné správy mohou mít v rámci každé služby různá oprávnění a povinnosti, tj. vystupují v různých rolích, ať již generických (například žadatel, příjemce výsledného benefitu, jiný účastník řízení), agendově specifických (řidič, podnikatel) nebo odborných/profesních (lékař, advokát, daňový poradce, …). Poskytovatel služby je povinen nabídnout klientovi IT podporu pro veškeré role, do kterých v rámci služby může na základě aktuální životní situace ve vztahu k veřejné správě potřebovat vstoupit a v nich konat.

V takových rolích může klient veřejné správy, nositel prostředku elektronické identifikace, vystupovat buď přímo za sebe, vlastním jménem, nebo na základě platného oprávnění nebo zmocnění k zastupování generálně nebo jenom ve výkonu určité role jménem jiné osoby, například jako statutární zástupce právnické osoby, zástupce nezletilého, registrující lékař pacienta a další. Tato oprávnění a zmocnění zastupovat jiné klienty veřejné správy nazýváme mandáty.

Systém eGovernmentu v ČR předpokládá, že každý klient s prokazatelnou identitou, s prostředkem pro elektronickou nebo prezenční identifikaci, může úměrně tomuto prostředku vstupovat do interakce s veřejnou správou (konat) za sebe bez omezení, pokud nejsou tato jeho práva omezena, například věkem (15 - 18 let) nebo rozhodnutím autority (typicky soudu).

Naopak pro vykonávání některých úkonů ve vybraných rolích, ať již vlastním jménem nebo v zastoupení, je třeba ověřit ještě splnění kvalifikačních předpokladů pro obsazení takové role. Pro zajištění přístupu identifikovaného a autentizovaného klienta veřejné správy k úkonu digitální služby a pro uživatelská oprávnění podle jeho obsazení do role je nezbytné zajistit zejména:

  1. Jednoznačnou identifikaci a autentizaci klienta veřejné správy
  2. Oprávnění jednat vlastním jménem (test svéprávnosti)
  3. Mandáty pro zastoupení při jednání s veřejnou správou
  4. Splnění kvalifikačních předpokladů pro obsazení do vybraných rolí

    Pro všechny tyto úlohy je třeba větší nebo menší měrou aby:

  5. Informační systém veřejné správy (zde AIS) byl schopný komunikovat s klientem, základními registry a získávat údaje z propojeného datového fondu

Jednoznačná identifikace a autentizace klienta veřejné správy

Všechny subjekty povinné dle § 2 zákona č. 250/2017 Sb., o elektronické identifikaci musí využívat k prokázání totožnosti klienta při elektronické komunikaci pouze kvalifikovaný systém elektronické identifikace, 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 elektronické identifikace spravuje kvalifikovaný správce (státní orgán nebo akreditovaná osoba, nikoliv správce přistupovaného AISu) 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 - její identifikace a autentizaci, 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á. NIA nezajišťuje další služby typu autorizace.

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ů a mandáty definující kvalifikaci osoby pro obsazení do role. Obecně platí, že jednat musí vždy fyzická osoba.

Fyzická osoba může jednat:

  • sama za sebe obsazená v té či oné roli
  • jako zástupce jiné fyzické nebo právnické osoby vystupující v té či oné roli

Zástupcem může být fyzická osoba a v některých vztazích i právnická osoba, za níž jedná zase její zástupce, kterým je fyzická osoba (řetězení vztahů). Zastupování z hlediska svého původu (právního titulu) lze rozdělit na tři základní typy:

  • na základě zákona (přímo), např. zastupování:
    • členem statutárního orgánu PO (např. jednatelem, společníkem, komplementářem, ředitelem, starostou, hejtmanem,….)
    • zákonným zástupcem (rodičem nezletilého dítěte, kterým je i osvojitel nezletilého dítěte zapsaný v matrice)
    • manželem/manželkou či registrovaným partnerem/partnerkou (využití tohoto zastupování v jednání vůči VS je velmi omezené)
  • na základě dohody mezi zastupovaným a zástupcem, např. zastupování:
    • zmocněncem FO nebo PO (rozsah zmocnění je uveden v plné moci a může být omezen i profesní rolí, které je zmocnění uděleno, tj. role advokát, notář, patentový zástupce, daňový poradce),
    • prokuristou
    • společným zmocněncem (zmocnění dle specifických procesních právních úprav – DŘ, SŘ apod., přičemž rozsah zmocnění je nejčastěji vázán na nějaké řízení, více účastníků řízení je zastupováno jedním zmocněncem)
    • zaměstnancem PO (rozsah zmocnění je uveden v pověření právnické osoby a odpovídá rozsahu pracovního zařazení nebo funkci)
  • na základě rozhodnutí autority, např. zastupování:
    • opatrovníkem, pěstounem, poručníkem FO (rozhodnutím soudu, přičemž zejména u opatrovníka je rozsah zmocnění je velmi variabilní)
    • opatrovníkem PO (rozhodnutím soudu, přičemž rozsah zmocnění odpovídá přiměřeně oprávnění člena statutárního orgánu)
    • likvidátorem, nuceným správce, insolvenčním správcem/předběžným správcem (rozhodnutím soudu, přičemž rozsah zmocnění je dán příslušnou rolí)
    • ustanoveným zástupcem, opatrovníkem nebo společným zástupcem (rozhodnutí OVM dle specifických procesních právních úprav – DŘ,SŘ apod.)

Základní mandáty v elektronické komunikaci

Základní mandáty, které každý orgán veřejné moci musí zajistit pro identifikovanou a autentizovanou osobu jsou popsány v následující tabulce. Orgán veřejné moci nemusí některý z následujících mandátů zajistit pouze v případě, že v jeho agendě nemůže takovéto zastupování nastat.

Právní titul Typ mandátu Popis Kde mandát získat
Na základě právního předpisu Člen statutárního orgánu právnické osoby Jedná se o právo a povinnost fyzické osoby, která zastupuje právnickou osobu (např. jednatel, společník, komplementář, ….) eGON služba rosCtiPodleUdaju, rosCtiIco, rosCtiAifo (základní registr osob)
Zákonný zástupce Jedná se o právo a povinnost fyzické osoby, která zastupuje jinou nezletilou či jinak nesvéprávnou osobu eGON služba aiseoCtiPodleUdaju, aiseoCtiAifo (agendový informační systém evidence obyvatel)

* pro zajištění ověření, zda je fyzická osoba rodič nezletilého, který není svéprávný

* pro zajištění ověření, zda je fyzická osoba zákonným zástupcem jiné fyzické osoby

* pro zajištění ověření, zda je fyzická osoba opatrovníkem jiné fyzické osoby
Manžel/manželka či registrovaný partner/partnerkaJedná se o právo a povinnost zastupování mezi manželi a partnery. Využití je zde omezené dle konkrétní agendy. eGON služba aiseoCtiPodleUdaju, aiseoCtiAifo (agendový informační systém evidence obyvatel)
Na základě dohody mezi zastupovaným a zástupcemPlná moc Jedná se o právo a povinnost mezi dvěma subjekty, kdy zmocnitel uděluje zmocněnci práva a povinnosti. Obecná úprava je v občanském zákoníku § 441-449 Pro plné moci neexistuje centrální systém či služba a je tedy plně na správci konkrétní agendy, aby plnou moc implementoval do elektronické části agendy, stejně jako je využívána v neelektronické části.

Plné moci se pro potřeby vyřízení služby v agendě nesmí dělit na elektronické a neelektronické, tedy je možné udělit plnou moc elektronicky pro vyřízení služby neelektronicky a naopak. Obdobně se postupuje při změně či rušení plné moci.
Prokura Jedná se o právo a povinnost, kterou uděluje podnikatel při provozu obchodního závodu, popřípadě pobočky, a to i k těm, pro která se jinak vyžaduje zvláštní plná moc. Obecná úprava je v občanském zákoníku § 450-456Pro prokuru neexistuje centrální systém či služba a je tedy plně na správci konkrétní agendy, aby prokuru implementoval do elektronické části agendy, stejně jako je využívána v neelektronické části.

Prokury se pro potřeby vyřízení služby v agendě nesmí dělit na elektronické a neelektronické, tedy je možné udělit prokuru elektronicky pro vyřízení služby neelektronicky a naopak. Obdobně se postupuje při změně či rušení prokury.
Na základě rozhodnutí autority Opatrovnictví fyzické osoby Jedná se o právo a povinnost, kdy nad fyzickou osobou bylo rozhodnutím soudu určeno opatrovnictví. Nemusí se nutně jednat o omezení svéprávnosti. * eGON služba robCtiPodleUdaju, robCtiAifo (agendový informační systém evidence obyvatel)

Příklady služeb v elektronické komunikaci

Orgán veřejné moci poskytuje řadu služeb, ve kterých se mandát využívá. 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

Systém veřejné správy schopný publikovat a získávat údaje z propojeného datového fondu

Aby si orgán veřejné moci mohl obstaral dostupné údaje o subjektech práva včetně případných oprávněních k zastupování v rolích, je potřeba, aby byl připojen k tzv. propojenému datovému fondu. V propojeném datovém fondu jsou k dispozici služby poskytující potřebné údaje pro zajištění následujících mandátů:

  • eGON služba rosCtiPodleUdaju, rosCtiIco, rosCtiAifo (základní registr osob)
    • pro zajištění ověření, zda je fyzická osoba statutárním zástupcem
  • eGON služba aiseoCtiPodleUdaju, aiseoCtiAifo (agendový informační systém evidence obyvatel)
    • pro zajištění ověření, zda je fyzická osoba rodič nezletilého, který není svéprávný
    • pro zajištění ověření, zda je fyzická osoba zákonným zástupcem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba opatrovníkem jiné fyzické osoby
    • pro zajištění ověření, zda je fyzická osoba manžel/manželka
  • eGON služba isknCtiVlastniky (informační systém katastru nemovitostí)
    • pro zajištění ověření, zda je fyzická osoba vlastníkem nemovitosti
  • Služba ISDS
    • Pro zajištění, zda je fyzická osoba pověřená k činění úkonů v ISDS vlastníkem datové schránky

Žádné další centrální služby ověření oprávnění/mandátů se v současné, ani dohledné době, neplánují. Proto je důležité, aby si každý poskytovatel elektronických služeb zajistit jiné typy mandátů sám.

Z organizačně procesních povinností musí systém poskytující elektronické služby veřejné správy odpovídat předpisům a splňovat několik předpokladů, které předchází technickému propojení:

  • 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 či působnosti v agendě.
  • Zákon 250/2014 Sb., o elektronické identifikaci. Systém, který vyžaduje ověření totožnosti
  • Agenda, ve které bude dotčený informační systém působit, musí být řádně ohlášená v registru práv a povinností a to včetně definic údajů objektů a subjektů a jejich technické struktury.
  • Z definovaných údajů objektů a subjektů v agendě, které se v agendě spravují, vytvořit tzv. kontext, který bude sloužit pro publikaci agendově specifických mandátů pro ostatní agendy veřejné správy přes systém eGSB/ISSS.
  • Definovat údaje objektů a subjektů v agendě, které spravují jiné agendy, a které jsou potřebné pro její výkon. Mezi tyto údaje mohou samozřejmě patřit i mandáty ve formě kontextů jiných agend.

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:

Závěrečná společná pravidla pro mandáty v elektronické komunikaci

Při výkonu veřejné správy je nutné, aby příslušný orgán veřejné moci vykonávající působnost v rámci 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.

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, 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ě.

Připojování Metropolitních sítí do CMS

Níže jsou popsány varianty a způsob připojení Metropolitních sítí (MAN) k Centrálnímu místu služeb (CMS) prostřednictvím Krajských sítí, Územních odborů Policie ČR, Akademické sítě CESNET nebo Finančních úřadů (síť GFŘ).

Definice Metropolitní sítě (MAN)

Metropolitní síť je optická páteřní komunikační síť města – vysokokapacitní a vysokorychlostní komunikační infrastruktura. Primární účel této sítě je propojovat veřejnosprávní úřady ve městě, školská zařízení, nemocniční zařízení, hasičský záchranný sbor, kulturní a sociální zařízení města a další subjekty zřízené městem. Jedna ze služeb, kterou Metropolitní sítě budoucnosti poskytují je připojení k CMS/KIVS.

Příklad metropolitní sítě a možností propojení

Popis způsobu připojení Metropolitní sítě do CMS

Připojení Metropolitní sítě prostřednictví Krajské sítě

Podmínkou připojení MAN přes Krajskou síť je vybudovaný funkční optický propoj mezi MAN a Krajskou sítí viz. následující obrázek

Příklad připojení Metropolitní sítě prostřednictvím Krajské sítě

Připojení Metropolitní sítě prostřednictví Akademické sítě CESNET

Podmínkou připojení MAN přes Akademickou síť CESNET je členství v Zájmovém sdružení CESNET a mít vybudovaný funkční optický propoj mezi MAN a Akademickou sítí CESNET viz. následující obrázek

Příklad připojení Metropolitní sítě prostřednictvím Akademické sítě CESNET

Připojení Metropolitní sítě prostřednictví sítě GFŘ

Podmínkou připojení MAN přes síť GFŘ je vybudovaný funkční optický propoj mezi MAN a sítí GFŘ viz. následující obrázek

Příklad připojení Metropolitní sítě prostřednictvím sítě GFŘ

Mezistátní komunikace informačních systémů

Spolupráce a komunikace mezi státy na úrovni propojení informačních systémů fungovala po dlouhou dobu na základě bilaterárních dohod a budování specifických řešení pro konkrétní situace. To sebou přináší nejednotnost a potřebu udržování mnoha systémů, protokolů a řešení, které musí jednotlivé státy podporovat. Přitom je obsahem většiny mezistátní komunikace informace vztahující se k fyzické nebo právnické osobě v konkrétní situaci - například výměna informací o platbě sociálního pojištění je výměna údajů vztahující se k fyzické osobě a dodatečných údajů o tom, jak dlouho a v jaké výši platil sociální pojištění v dané zemi. Pokud se tedy vyměňují údaje o vztahující se k fyzickým a právnickým osobám, nabízí se forma standardizace prostředí a protokolů, které zajistí jednotnost struktury údajů o fyzických a právnických osobách a následně stanoví specifické atributy pro konkrétní situace.

Mezi současné systémy, které slouží pro mezistátní výměnu údajů patří:

  • EESSI (The Electronic Exchange of Social Information). EESSI je IT systém financovaný z Nástroje pro propojení Evropy (CEF), který zavádí přeshraniční digitální služby a umožňuje příslušným institucím vyměňovat si informace o sociálním zabezpečení. To zahrnuje nároky na důchod, nemocenské dávky, rodinné dávky, dávky v nezaměstnanosti a mnoho dalších, jak vyžadují pravidla EU o koordinaci sociálního zabezpečení občanů při pohybu v rámci Evropy (Evropského hospodářského prostoru a Švýcarska). EESSI proto usnadňuje rychlejší a efektivnější zpracování údajů o sociálním zabezpečení pro občany a podniky v EU. Kromě toho umožňuje vnitrostátním institucím sociálního zabezpečení určovat práva na sociální zabezpečení, bojovat proti podvodům a chybám a bezpečně zpracovávat osobní údaje.
  • EUCARIS. EUCARIS je celoevropské technické rozhraní, které umožňuje výměnu informací z národních registrů. Jedním z modulů vázaných na systém EUCARIS je modul CBE, který umožňuje automatizovanou výměnu informací o vozidle, jímž byl na území členského státu spáchán vybraný dopravní delikt, jeho vlastnících a provozovatelích a výměna je upravena směrnicí. Každá země, která poskytuje a přijímá data, musela projít schvalovacím procesem tzv. evaluací, kde zástupci organizace EUCARIS prověřili správnost nastavení jednotlivých rozhraní v propojovaných systémech a potvrdili možnost funkčního propojení. Po odsouhlasení se všechny již připojené země mohou prostřednictvím sítě EUCARIS dotázat na vozidlo evidované v ČR.
  • IMI. Systém pro výměnu informací o vnitřním trhu (IMI) je bezpečný, mnohojazyčný online nástroj, který usnadňuje výměnu informací mezi veřejnými orgány zapojenými do praktického provádění práva EU. IMI pomáhá orgánům plnit jejich povinnosti týkající se přeshraniční spolupráce v řadě oblastí politiky jednotného trhu. V současné době IMI umožňuje provádění 67 postupů správní spolupráce v 17 různých oblastech politiky EU. Systém IMI lze s minimálním úsilím rozšiřovat a upravovat, aby se dal využívat pro další oblasti. Jeho prostřednictvím se podařilo modernizovat přeshraniční administrativní spolupráci a přispívá i k tomu, že jednotný trh funguje v praxi. Ačkoli jsou koncovými uživateli systému IMI orgány veřejné moci v členských státech, z této vyspělejší spolupráce těží podniky i občané.

Existují i další systémy, ale cílem bylo především ukázat, že pokud existovala potřeba výměny informací, vytvořil se specifický systém sloužící přesně pro danou potřebu. Ovšem nebylo jej následně možné použít na nic jiného. Z tohoto důvodu se v rámci nařízení o jednotné digitální bráně ustanovil tzv. systém pouze jednou (v angl. once-only technical system), který by měl sloužit pro různé druhy služeb v rámci různých účelů.

Aktuální a budoucí stav v Česku

Současný stav výměny údajů mezi IS VS v rámci ČR a ostatními státy je ponechán na každém správci daného ISVS zvlášť. Jediná centrální standardizace je prostřednictvím síťové/komunikační infrastruktury, kde Ministerstvo vnitra spravuje v Centrálním místě služeb jednotný bod připojení do sítě TESTA-ng. Každý správce, kterému český či jiný právní předpis ukládá výměnu údajů, tedy poskytuje své údaje bez využití referenčního rozhraní. Referenční rozhraní (v rámci ČR) se nyní explicitě skládá ze 2 systémů (Informační systém základních registrů, Informační systém sdílené služby/eGovernment On-Line Service Bus), které slouží pouze pro komunikaci vnitrostátní – ISZR pro komunikaci se základními registry a editory základních registrů, ISSS/eGSB pro komunikaci s jinými agendami veřejné správy.

Budoucí stav musí odpovídat znění zákona 2) tedy zabezpečit všem správcům ISVS, aby mohli své údaje se zahraničím vyměňovat pomocí referenčního rozhraní a zabránit tak vstupům do prostředí českého eGovernmentu mimo centrální kontrolu. Současně nadále platí povinnost jednotlivých systémů ISVS komunikovat se základními registry a editory základních registrů pomocí služeb ISZR. Tato komunikace je vždy a pouze mezi ISZR a ISVS a v souvislosti s mezistátní výměnou je potřebná identifikace (pro jednoznačné ztotožnění) subjektů / objektů o kterém se komunikuje a který se dotazuje.

Pro dosažení budoucího stavu je nutné vytvořit ISVS pro mezistátní výměnu, který bude jako kterýkoliv jiný ISVS komunikovat s ostatními ISVS pomocí referenčního rozhraní a jako jediný bod (IS) v českém prostředí eGovernmentu bude komunikovat mezistátně o objektech a subjektech v propojeném datovém fondu. ISVS pro mezistátní výměnu bude obsahovat soubor tzv. Access pointů, což samo o sobě naznačuje, že komunikace se zahraničím nebude vždy jednotná ve formě technologií či standardů. Tento soubor bude obsahovat tolik forem komunikace, kolik jich je specifických pro daný účel výměny údajů. Ideálním stavem je samozřejmě mít jich co nejmenší počet, o což se snaží evropská komise vytvořením tzv. Bulding Blocku eDelivery, který by byl jedním z těchto Access Pointů.

ISVS pro mezistátní výměnu bude obsahovat i logiku, která bude u volání ze zahraničí rozhodovat o tom, jaký AIS, Agendu, agentovou roli a kontext na eGSB/ISSS systém použije, pamatovat si toto volání a při odpovědi jednoho nebo více ISVS sestaví odpověď a odešle ji zpět zahraničnímu systému (obdobný požadavek jako u ISZR v rámci ČR na komplexní služby). Při dotazu českého ISVS na zahraniční systém naopak musí být připravena logika na určení, který Access Point se má využít, zda se jedná o synchronní nebo asynchronní službu, pamatovat si toto volání a při zpětné odpovědi zahraničního systému poslat odpověď tázajícímu se ISVS.

ISVS pro mezistátní výměnu se stane dalším prvkem centrálně řízené části referenčního rozhraní veřejné správy a propojeného datového fondu. Stejně jako zbývající prvky tohoto rozhraní (tedy ISZR a ISSS) bude pod správou Digitální a informační agentury. Podstatné body k implementaci:

  • Volání v prostředí českého eGovernmentu je přes referenční rozhraní vždy synchronní, jednotlivé Access Pointy však mohou mít i asynchronní povahu.
  • Převzetím Access Pointů přebírá Digitální a informační agentura také zodpovědnost za funkčnost přenosu.
  • Každý správce ISVS, který by potřeboval jakoukoliv výměnu se zahraničním systémem, nemusí řešit, jak tuto funkcionalitu implementuje do svého systému, pouze vytvoří kontext na eGSB/ISSS (pro odpověď na volání zahraničního systému) nebo naopak začne číst kontexty (pro příjem ze zahraničního systému). Platí tedy, že volání zahraničního IS je shodné, jako volání AIS v rámci ČR. Volající AIS použije stejné kontexty jako v případě dotazu na eGSB/ISSS.

Byznys architektura

Aplikační architektura

Jednotná digitální brána (SDG) a systém pouze jednou (OOTS)

Jednotná digitální brána EU (Single Digital Gateway; SDG) dle nařízení Evropského parlamentu a Rady (EU) 2018/1724 (dále jako "nařízení") byla spuštěna závěrem roku 2020 na portálu //Your Europe// jakožto elektronický rozcestník, jehož prostřednictvím jsou občanům a podnikatelům poskytovány relevantní informace, elektronické postupy a asistenční služby v různorodých oblastech, jako jsou podnikání, sociální zabezpečení, daně a řady dalších, a to na celoevropské úrovni. Zásadní vlastností poskytovaných informací, postupů a asistenčních služeb je jejich dostupnost vedle národních jazyků také v angličtině, což představuje potenciál pro jejich přeshraniční využití. 

Role jednotlivých rezortů v implementaci SDG byla definována v usnesení vlády ze dne 11. května 2020 č. 525 k implementaci nařízení. Gestorem samotného nařízení je Ministerstvo průmyslu a obchodu, hlavním spolugestorem je Digitální a informační agentura, která plní roli technického garanta implementace a která tuto roli převzala po Ministerstvu vnitra. Jelikož však povinnosti dané nařízením dopadají téměř na všechny ústřední orgány státní správy, byla formálně stanovena spolugesce několika dalším nejvíce dotčených rezortům (Ministerstvo dopravy, Ministerstvo financí, Ministerstvo pro místní rozvoj, Ministerstvo práce a sociálních věcí, Ministerstvo školství, mládeže a tělovýchovy a Ministerstvo zdravotnictví), které mají odpovědnost za konkrétní oblasti pokryté nařízením.

Nařízení uložilo členským státům povinnost zveřejnit informace týkající se životních situací, jejichž rozsah je definován v Příloze I nařízení, a to do 12. prosince 2020. V době přípravy tohoto materiálu bylo v ČR plněno nebo částečně plněno 94 % informačních požadavků ve vztahu k Příloze I nařízení. To současně uložilo ČS elektronizovat 21 postupů uvedených v Příloze II nařízení, a to do 12. prosince 2023. Všechny tyto postupy byly v ČR elektronizovány, případně v souladu s nařízením nemusely být elektronizovány. Tyto postupy se týkají oblastí práce, studia, podnikatelské činnosti aj.

Pokud jde o centrální rozpočet na implementaci SDG, ten byl celkově stanoven na 279,62 mil. Kč na roky 2020 až 2023. Ministerstvo průmyslu a obchodu v roce 2020 obdrželo 42 mil. Kč k přerozdělení mezi rezorty pro účely implementace. V letech 2021 až 2023 rezorty již žádaly o prostředky na implementaci SDG do svých rozpočtových kapitol samy. V rámci Národního plánu obnovy je přiděleno 237,62 mil. Kč3) na dokončení digitalizace čtyř online postupů v gesci MŠMT a MPSV, jejichž proplacení se předpokládá během roku 2024.

Důležitým milníkem pro úplnou implementaci nařízení byl 12. prosinec 2023 a spuštění systému OOTS.

Vzhledem k přetrvávajícímu neúplného plnění předmětných povinností a jednak vzhledem k vývoji zejména na straně Evropské komise (dále jen „Komise“ nebo „EK“), kde došlo k více než ročnímu zpoždění v přijímání prováděcího předpisu k technickému systému pro automatizovanou výměnu důkazů „pouze jednou“ („Once-Only Technical System“, dále jen „OOTS“), je nutné právě i s ohledem na napojení na tento systém provést a dokončit řadu úkolů, aby mohlo být nařízení posléze považováno za zcela implementované. Současně je na místě poznamenat, že vzhledem ke stále častějšímu rozšiřování příloh nařízení novými unijními právními akty nemusí být trvalé a úplné implementace zcela dosaženo, a samotná implementace bude tedy dlouhotrvajícím a kontinuálním procesem.

Popis nařízení

Cílem nařízení je vytvořit elektronický rozcestník, jehož prostřednictvím jsou občanům a podnikatelům poskytovány relevantní informace, elektronické postupy a asistenční služby v různorodých oblastech, jako jsou podnikání, sociální zabezpečení, daně a řady dalších, a to na celoevropské úrovni. Nařízení tak reaguje na snahu odstranit překážky způsobené nedostupností informací, které vyvstávají pro občany a podnikatele uvažující o usídlení se, prodeji zboží, nebo poskytování služeb v jiných členských státech Evropské unie. SDG by tak v konečném důsledku měla být svými uživateli pravidelně využívána v případě, že se rozhodnou hledat dostupné a kvalitní informace, elektronické postupy nebo asistenci při jejich přeshraničních aktivitách v rámci Evropské unie, a to nejen v jazyce či jazycích daného členského státu, ale také v angličtině.

SDG vychází ze současné sítě Jednotných kontaktních míst (dále také jen „JKM“) a elektronických JKM (dále jen „eJKM“), které na základě směrnice Evropského parlamentu a Rady 2006/123/ES ze dne 12. prosince 2006 o službách na vnitřním trhu, fungují v členských státech od roku 2006. JKM poskytují pomoc podnikatelům v oblasti poskytování služeb, a to především v podobě usnadnění zahájení podnikání prostřednictvím informací a kontaktů, které poskytují. Vedle toho eJKM poskytují potřebné informace a přístup k elektronickým službám online, a právě na tomto příkladu dobré praxe vyrostla myšlenka Jednotné digitální brány, která primárně rozšiřuje pokrývané oblasti a jasně definuje kvalitativní požadavky na poskytované informace, elektronické postupy a asistenční služby.

V současnosti již mohou čeští i evropští uživatelé skrze SDG nalézt na portálu //Your Europe// (Vaše Evropa) potřebné informace pro svůj pohyb napříč Unií, a to jak přímo informace poskytované Komisí o pravidlech, která jsou pro celou EU stejná, tak i informace o národních pravidlech v předepsaných oblastech. Informace tak jsou dostupné na jednom místě, v přehledné a uživatelsky přívětivé podobě a v neposlední řadě také v angličtině. Analogicky mají uživatelé prostřednictvím národních odkazů také přístup k jednotlivým požadovaným online postupům a asistenčním službám.

Informace

Nařízení uložilo členským státům povinnost zveřejnit informace týkající se životních událostí z Přílohy I a informací týkající se postupů z Přílohy II nařízení, a to do 12. prosince 2020. Nařízení ve svých Přílohách obsahuje seznam oblastí informací a postupů, které musí být dostupné skrze Jednotnou digitální bránu. Mezi informace relevantní pro občany patří například téma cestování, práce, registrace vozidel, pobyt, vzdělávání atd., zatímco pro podnikatele jsou zveřejňovány informace týkající se například zahájení podnikání, zaměstnávání, daní, financování a mnoho dalších. Povinnost zveřejnit tyto informace dle čl. 4 nařízení mají jak Evropská komise, tak i členské státy, přičemž primární odpovědnost za jednotlivé oblasti je rozdělena podle klíče, který bere v potaz míru harmonizace dané oblasti unijním právem a který je také naznačen v části k rozdělení gescí.

Požadavky na kvalitu samotných informací popisuje čl. 9 nařízení. Evropská komise pravidelně aktualizuje tzv. vodítka, resp. pokyny k informacím z Přílohy I, které bodově popisují, jaké konkrétní informace by měly být pod každou z oblastí dostupné. Na vodítka pak navazují dílčí dokumenty, které údaje v postupech a informacích doplňují. Nařízení ukládá povinnost členským státům, aby poskytovaly výše popsané informace nejen ve svých úředních jazycích, ale také v angličtině či dalších úředních jazycích EU. Evropská komise současně členským státům nabízí možnost částečného hrazení překladů do anglického jazyka. Požadavky na překlady je možné Evropské komisi předložit prostřednictvím nástroje, který Komise poskytuje od roku 2020, přičemž ČR této možnosti každoročně využívá.

Postupy

Členské státy mají současně povinnost dle čl. 6 odst. 1 Nařízení elektronizovat postupy dané Nařízením v Příloze II, a to pouze ty, které jsou již v příslušném státě zavedeny, tedy jsou poskytovány v „off-line“ režimu. Elektronizací se rozumí zpřístupnění těchto postupů „zcela online“. Ke každému příslušnému postupu musí být rovněž vytvořena stručná popisná informace, přičemž termín pro zpřístupnění postupů online byl 12. prosince 2023.

Postup je považován za „zcela online“ pokud splňuje následující:

  • prokazování totožnosti uživatelů, poskytnutí informací a podpůrných důkazů, podepsání a konečné podání lze provést elektronicky na dálku prostřednictvím služebního kanálu, který uživateli umožní uživatelsky vstřícným a strukturovaným způsobem splnit všechny požadavky související s daným postupem;
  • je uživatelům poskytnuto automatické potvrzení o přijetí, pokud nebyl výstup postupu doručen okamžitě;
  • je výstup postupu doručen elektronicky, nebo pokud je to nezbytné pro splnění použitelného práva Unie nebo vnitrostátního práva, je doručen fyzickými prostředky;
  • jsou uživatelé elektronicky vyrozuměni o dokončení postupu.

Rovněž musí dle čl. 13 nařízení členské státy zajistit, aby přeshraniční uživatelé měli přístup k jednotlivým krokům postupu a mohli je plnit stejně snadno jako vnitrostátní uživatelé. To znamená zajištění následujících požadavků:

  • uživatelům je umožněn přístup k pokynům pro splnění postupu v úředním jazyce Unie, kterému obecně rozumí co nejvyšší počet přeshraničních uživatelů, tedy v angličtině;
  • přeshraniční uživatelé mohou předkládat požadované informace, i pokud se struktura těchto informací liší od obdobných informací v dotčeném členském státě; přeshraniční uživatelé mají možnost prokázat svou totožnost a ověřit ji, podepsat dokumenty elektronicky nebo je opatřit elektronickou pečetí podle Nařízení eIDAS, a to ve všech případech, kdy tuto možnost mají i uživatelé, kteří nejsou přeshraničními uživateli;
  • přeshraniční uživatelé mají možnost poskytnout důkaz o splnění platných požadavků a obdržet výsledky postupů v elektronické podobě ve všech případech, kdy tuto možnost mají i uživatelé, kteří nejsou přeshraničními uživateli;
  • pokud splnění určitého postupu vyžaduje platbu, uživatelé mají možnost uhradit veškeré poplatky online prostřednictvím široce dostupných přeshraničních platebních služeb, aniž by došlo k diskriminaci na základě místa usazení poskytovatele služby, místa vydání platebního prostředku či umístění platebního účtu v rámci Unie.
Asistenční služby

Nařízení v neposlední řadě stanovuje požadavky na asistenční služby a služby pro řešení problémů, které jsou uvedeny v Příloze III nařízení. Patří mezi ně ty asistenční služby, které byly zřízeny závaznými akty Unie a kterými jsou:

  • jednotná kontaktní místa,
  • kontaktní místa pro výrobky,
  • kontaktní místa pro stavební výrobky,
  • národní centra pomoci pro odbornou kvalifikaci,
  • vnitrostátní kontaktní místa pro přeshraniční zdravotní péči,
  • evropská síť služeb zaměstnanosti EURES, a
  • řešení spotřebitelských sporů online.

Další služby, které fungují na základě dobrovolnosti, jakými jsou například síť SOLVIT či Enterprise Europe Network, mohou být prostřednictvím jednotné digitální brány přístupné v okamžiku, budou-li plnit požadavky stanovené nařízením v čl. 7. Při splnění stejných podmínek mohou členské státy Komisi navrhnout přidání do Jednotné digitální brány těch asistenčních služeb, které jsou poskytovány soukromými či polosoukromými organizacemi.

Sběr statistiky a zpětné vazby

Nařízení také ukládá povinnost sbírat statistiku a zpětnou vazbu o návštěvách a využití jednotlivých elektronických či asistenčních služeb, které jsou napojeny na SDG. Technické specifikace samotného sběru statistiky a zpětné vazby jsou uvedeny v prováděcím nařízením Komise (EU) 2020/11214).

Technický systém OOTS

Nařízení v neposlední řadě povinuje Evropskou komisi k vyvinutí a ČS k následnému napojení relevantních elektronických služeb na technický systém pro výměnu důkazů „pouze jednou“ (OOTS). Tento systém by měl uživatelům umožnit, aby při využívání jednotlivých elektronických postupů dle Přílohy II nařízení a také dle směrnic o službách, uznávání odborných kvalifikací a veřejných zakázkách mohli využít důkazy, které již orgány státní správy v souladu s čl. 14(2) Nařízení poskytují v elektronické podobě, která umožňuje automatizovanou výměnu, a to právě v přeshraničních situacích. Technické specifikace tohoto systému jsou v souladu s prováděcím nařízením Komise (EU) 2022/14635) ve spolupráci s ČS průběžně aktualizovány.

Stav implementace dle jednotlivých částí nařízení

Implementace nařízení je společným úkolem Evropské komise a členských států. S ohledem na to, že koordinace mezi těmito entitami je pro implementaci klíčová, byla zřízena na úrovni EU koordinační skupina pro SDG (dále jen „koordinační skupina“).

Koordinační skupina je složená z expertů jednotlivých členských států a zástupců Komise. Jejich úkolem je podporovat jednotnou a hladkou implementaci nařízení v rámci jednotlivých členských států. Koordinační skupina slouží jako platforma pro výměnu osvědčených postupů a pro diskuze nad vývojem společných informačních a komunikačních technologií.

Koordinace mezi národními koordinátory členských států a zástupci EK probíhá během pravidelných setkání v Bruselu, popř. online. Od zahájení implementace do konce roku 2023 proběhlo 50 setkání koordinační skupiny. V kontextu implementace a přípravy na napojení jednotlivých služeb na technický systém OOTS organizuje Evropská komise pravidelná online setkání pracovních podskupin, které jsou tematicky zaměřené na jednotlivé dílčí aspekty problematiky OOTS. ČS tak s EK pravidelně diskutují nad otázkami k mapování důkazů, specifikacím samotného OOTS, operačního řízení, bezpečnosti, standardizaci datových modelů v rámci OOTS a testování a nasazování OOTS. Dále se zástupci ČS na nepravidelných online setkáních zabývají aktivitami spojenými s propagací SDG v rámci tzv. „Communication Café“ a jsou také seznamováni s vývojem v informačních nástrojích v rámci tzv. „IT Clinic“.

Evropská komise současně pravidelně aktualizuje jednotlivé dokumenty, které popisují funkční, technické a systematické požadavky na interoperabilitu pro implementaci Jednotné digitální brány. Tyto dokumenty jsou dostupné na veřejně přístupné webové stránce a jejich účelem je co nejvíce usnadnit jednotnou implementaci SDG napříč členskými zeměmi.

Za účelem zajištění efektivní a včasné implementace probíhá koordinace také na národní úrovni mezi gestorem nařízení MPO a gestorem eGovernmentu DIA, ve které DIA plní roli technického garanta implementace. Konkrétní rozsah spolugesce dalších resortů nad jednotlivými částmi nařízení je v části gesce_nad_informacemi_a_postupy, přičemž tabulky v ní uvedené podrobně stanovují gesce a odpovědnosti určených veřejných orgánů do úrovně jednotlivých oblastí informací, postupů a asistenčních služeb dle Příloh I, II a III nařízení. Prvotní rozdělení gescí u jednotlivých rezortů bylo schváleno usnesením vlády ze dne 11. května 2020 č. 525 k implementaci nařízení, nicméně od té doby byly některé oblasti i v kontextu komisních vodítek upřesněny.

Zasazení nařízení do inciativ ČR v oblasti e-governmentu

Nařízení je plně integrováno do prostředí eGovernmentu v ČR. Nařízení ukládá povinnost členským státům digitalizovat služby a zveřejňovat odpovídající informace v elektronické podobě. Tato povinnost koresponduje se zněním české legislativy, jmenovitě zákonem č. 12/2020 Sb., o právu na digitální služby 6) (dále jen „zákon o právu na digitální služby“). Podle tohoto zákona má uživatel právo využívat digitální službu a orgán veřejné moci má povinnost poskytovat digitální službu (v podobě elektronického podání). Implementace SDG je tedy prováděna plně v souladu se zákonem o právu na digitální služby a technicky je ve své informační části implementována skrze Katalog služeb veřejné správy. Implementace SDG je také součástí programu Digitální Česko jako jeden z jeho prioritních programů a záměrů.

Z rozhodnutí předsedy Rady vlády pro informační společnost (dále „RVIS“) byla v roce 2019 zřízena Pracovní skupina pro SDG (dále jen „Pracovní skupina“ nebo „PS“). PS poskytuje koordinační, metodickou a technickou podporu gestorům jednotlivých částí nařízení. Jejími členy jsou experti z DIA a MPO a další vybraní odborníci z jednotlivých rezortů. Úkolem PS je koordinace průběžného plnění implementačních povinností a vzájemná konzultace možných problémů vyvstanuvších při implementaci Nařízení. Členové PS jsou většinou oslovováni prostřednictvím emailové komunikace, případně se schází celá PS, přičemž od vzniku PS do konce roku 2023 proběhlo celkem pět setkání PS. Gestor implementace současně pravidelně informuje o stavu implementace předsednictvo RVISu a náležitě aktualizuje související komponenty v rámci Katalogu záměrů Digitálního Česka.

Implementace informačních povinností

MPO průběžně provádí analýzu stavu plnění informačních povinností a jejich souladu s vodítky EK. Pravidelnou kontrolou back-office části portálu Your Europe bylo ověřováno, zda informace a postupy, které jsou tímto portálem dohledatelné a dostupné, jsou aktuální, relevantní, kompletní a dostupné i v anglickém jazyce. Vyhodnocení stavu informací je průběžně předáváno jednotlivým gestorům, kteří jsou současně žádáni o aktualizaci, doplnění či úpravu svých záznamů a tím i k naplňování svých povinností vyplývajících z implementace nařízení. Vyhodnocení plnění povinností bylo aktualizováno na základě mezirezortního připomínkového řízení, které bylo ukončeno 22. února 2024.

Technické řešení implementace informačních povinností

Vzhledem k tomu, že implementaci informačních povinností bylo možno úzce propojit s pracemi souvisejícími s implementací zákona o právu na digitální služby, byl využit ekosystém Katalogu služeb veřejné správy připravovaný pro tento zákon. Přesto však bylo potřebné doplnit některé funkcionality, které jsou nezbytné právě pro plnění potřeb nařízení.

Jedním z výstupů Katalogu služeb je zveřejňování detailních popisů služeb veřejné správy, které byly využity i pro služby dle SDG a doplněny o některé potřebné atributy (kategorie a oblasti SDG, anglická verze popisu apod.). Pro SDG dále také vznikly další typy záznamů, a to v rámci Katalogů informací a rozcestníků. Informace je typ záznamů, který je využíván pro texty, které nejsou definovány jako služby veřejné správy, ale přesto by tyto texty měly být veřejně publikovány (ať už proto, že spadají pod nařízení nebo proto, že pro veřejnou správu je účelné tyto informace sdílet). Rozcestníky se poté používají jako jakési menu, kde se návštěvník webu dozví základní informace o dané problematice a je odkázán na další texty (detailní popisy, informace), které mu téma více přiblíží.

DIA (dříve v rámci MV) ve spolupráci s MPO vypracovala technické řešení pro publikování informací, které je soustředěno na minimálním počtu míst, resp. portálů, a zajišťuje tak uživatelskou přívětivost, vizuální jednolitost a snadnější kontrolu kvality a údržby. Toto technické řešení navržené DIA (resp. MV) odpovídá požadavkům Informační koncepce ČR. Zveřejňování informací probíhá na Portálu veřejné správy (gov.cz) (dále jen „PVS“) a BusinessInfo.cz (dále jen „BI.cz“).7) Tyto dva portály byly EK oznámeny jako místa, kde komisní nástroje mohou hledat záznamy pokrývající informace požadované nařízením.

Za tímto účelem je využíván Registr práv a povinností a na něj navázaný AIS RPP Správa katalogů (dále jen „AISK“), který plní funkce týkající se zveřejňování informací na PVS. AISK pomáhá naplňovat potenciál Katalogu služeb dle zákona o právu na digitální služby, který stanovuje povinnost všechny služby veřejné správy detailně popsat. Jednotliví gestoři vytváří kvalitní a pro veřejnost přívětivé texty, přičemž detailní popisy služeb relevantních pro SDG jsou zaneseny v češtině i angličtině.

Ke všem záznamům spadajícím pod SDG byly také přiřazeny odpovídající metadata (metatagy) dle požadavků EK tak, aby s nimi mohlo být dále automaticky pracováno, konkrétně aby mohly na ohlášených portálech nalezeny a načteny nástrojem („crawlerem“) vytvořeným Evropskou komisí a nemusely tak být ručně importovány do úložiště odkazů.

Využití zmíněného komisního nástroje, „crawleru“, má současně tu výhodu, že povinnosti dané nařízením v otázce sběru statistiky a zpětné vazby či umístění loga Your Europe jsou v případě informací plněny pouze na dvou portálech (PVS a BI), a gestoři jednotlivých informačních oblastí tak nemusí vlastní data posílat Evropské komisi.

Informační povinnost se však netýká pouze Přílohy I nařízení, kde jsou uvedeny jednotlivé informační oblasti, ale také Příloh II a III nařízení. V případě Přílohy III nařízení, která se týká asistenčních služeb, již potřebné informace o těchto službách byly ve spolupráci s gestory publikovány. Ovšem v případě Přílohy II nařízení jsou členské státy povinovány nejen k elektronizaci souvisejících postupů, ale také k poskytnutí relevantních informací o těchto postupech. I tyto informační povinnosti jsou naplňovány prostřednictvím AISK, analogicky k popisování oblastí v rámci Přílohy I nařízení.

V otázce překladů jednotlivých informačních záznamů mají jejich gestoři na výběr, kdy buď mohou využít překladů nabízených EK, nebo mohou záznamy přeložit vlastními silami či na vlastní náklady. V případě překladů zprostředkovaných Evropskou komisí jsou příslušné záznamy v Katalogu služeb indikovány národnímu koordinátorovi pro SDG, který jej následně v .html formátu z Katalogu služeb exportuje a nahrává do příslušného modulu v rámci back-office prostředí portálu Your Europe. Po přeložení těchto záznamů jsou jednotlivé záznamy opětovně nahrány do Katalogu služeb a gestoři jsou posléze vyzváni ke schválení těchto překladů.

Jelikož je jednou z povinností daných nařízením pravidelná aktualizace poskytovaných informací, gestoři by v tomto ohledu měli náležitě kontrolovat své záznamy v rámci AISK, označené jako relevantní pro SDG, a v případě potřeby je patřičně aktualizovat. Pokud v záznamu není třeba učinit žádnou změnu, měli by gestoři pouze aktualizovat údaj o datu poslední kontroly. Tyto kontroly a aktualizace by se měly dít pravidelně a v ideálním případě okamžitě, jakmile dojde k předmětným změnám, minimálně však jednou ročně. Gestoři jednotlivých záznamů relevantních pro SDG by pak v tomto ohledu měli informovat gestora implementace o výsledcích zmíněných kontrol.

Dosavadní stav implementace informačních povinností

Celkový počet oblastí informací v rámci Přílohy I nařízení je 88, přičemž u 20 z nich převzala odpovědnost za jejich poskytnutí Evropská komise. Předmětem plnění ze strany České republiky je tedy zbylých 68 informačních oblastí.  V Příloze č. 1 tohoto materiálu je rozdělení gescí k jednotlivým informacím tak, jak bylo schváleno v rámci usnesení vlády ze dne 11. května 2020 č. 525 k implementaci nařízení. U vybraných oblastí je naznačena také změna gescí, která byla s dotčenými gestory dojednána mj. i na základě vodítek EK k obsahu jednotlivých oblastí Přílohy I nařízení, které EK pravidelně aktualizuje.

Jak již bylo řečeno výše, gestoři musí jednotlivé informační povinnosti naplňovat prostřednictvím Katalogu služeb, informací a rozcestníků v rámci AISK, a tyto záznamy musí současně překládat do angličtiny, popřípadě mohou požádat o jejich přeložení prostřednictvím Evropské komise. V případě překladů nechala ČR do konce roku 2023 prostřednictvím EK přeložit celkem 542 normostran8) textu, čímž při ceně přibližně 100 EUR za normostranu9) ušetřila státnímu rozpočtu 54 200 EUR.

Na základě přezkoumání gestora implementace a na základě dat, které uvádí back-office prostředí portálu Your Europe, do kterého jsou odkazy nahlašovány, bylo vyhodnoceno, že k xx. únoru 2024 byly formálně splněny požadavky nařízení v 59 oblastech (asi 87 %), což znamená, že daná oblast má záznam v AISK jak v češtině, tak v angličtině. V případě některých oblastí existuje v AISK záznam v češtině, nemá však již svou anglickou verzi, proto jsou takové záznamy vyhodnoceny jako „částečně plnící“ povinnosti dané nařízením, přičemž těchto oblastí je 5 (asi 7 %). V neposlední řadě jsou oblasti, které v AISK nemají ani český ani anglický záznam. Tyto oblasti byly v době vyhodnocení 4 (asi 6 %) a jsou označeny jako „neplnící“, nicméně na nápravě a jejich dokončení MPO společně s gestory dotčených oblastí k datu zpracování tohoto materiálu pracuje. Konkrétní přehled plnění Přílohy I nařízení je obsažen v Příloze č. 1 materiálu.

V případě informování o elektronických postupech z Přílohy II nařízení jsou prostřednictvím AISK publikovány a EK nahlášeny záznamy celkem k 9 postupům z celkových 21 (asi 43 %) s tím, že jeden z nich postrádá anglickou verzi. Navzdory tomu, že EK zatím plnění v této oblasti nemonitoruje, spolupracuje i v tomto případě MPO s gestory jednotlivých dílčích služeb na nápravě. V neposlední řadě v případě informování o asistenčních službách z Přílohy III nařízení jsou pak tyto povinnosti plněny ze 100 %.

Implementace digitalizačních povinností

MPO společně s DIA dohlížejí na implementaci digitalizačních povinností daných nařízením, zejména pak na řádnou elektronizaci služeb uvedených v Příloze II nařízení tak, aby splňovaly požadavky dané nařízením. Současně připravují napojení příslušných elektronických služeb na technický systém OOTS a v tomto kontextu podporují dotčené gestory.

Technické řešení implementace digitalizačních povinností

Na rozdíl od informační části a vzhledem k vnitřním digitalizačním plánům a nastavení jednotlivých úřadů není ze strany gestorů implementace možné stanovit jednotnou podobu digitalizace dotčených služeb a související technické řešení. Gestoři jednotlivých služeb však musí vedle naplňování požadavků samotného nařízení také dodržovat principy a pravidla v rámci prostředí architektury českého eGovernmentu.

Dosavadní stav implementace digitalizačních povinností

Nařízení povinuje elektronizovat 21 postupů (transakčních služeb) uvedených v Příloze II, přičemž tři z těchto postupů byly vyhodnoceny tak, že v ČR nejsou zavedeny, resp. že neexistují, a proto v souladu s čl. 6 odst. 1 nařízení nemusí být zaváděny. Jedná se konkrétně o postupy „Žádost o evropský průkaz zdravotního pojištění (EHIC)“, „Registrace změny adresy“ a „Získání emisních známek vydávaných veřejným orgánem nebo institucí“. Ze zbylých 18 postupů bylo úspěšně plněno (tj. plně elektronizováno dle požadavků nařízení) 16 postupů, gestoři zbývajících dvou postupů v současnosti dokončují poslední úpravy, které je také umožní považovat za plně elektronizované. Současně ovšem funkcionalita a uživatelská přívětivost některých z postupů budou v průběhu následujících let průběžně vylepšovány.

  • Žádost o potvrzení registrace narození (gesce MV)
    • V souladu s vodítky EK bylo určeno, že v českém prostředí se jedná o „opis rodného listu“, o který je v současnosti možné požádat prostřednictvím datové schránky, popř. žádostí podepsané kvalifikovaným elektronickým podpisem. Výsledný opis je následně žadateli doručen v souladu s nařízením fyzicky. Do budoucna se počítá s implementací této služby v rámci chystaného projektu eMatrika. Služba samotná je dostupná i pro zahraniční uživatele narozené v ČR.
    • Více informací je k dispozici v rámci detailního popisu služby „Zápis narození dítěte“.
  • Žádost o potvrzení místa pobytu (gesce MV)
    • V souladu s vodítky EK bylo určeno, že v českém prostředí lze využít již existující služby „výpis z registru obyvatel“ prostřednictvím Portálu občana. Tato služba je dostupná i pro zahraniční uživatele s trvalým pobytem v ČR.
    • Více informací je k dispozici v rámci detailního popisu služby „Výpis údajů z registru obyvatel“.
  • Žádost o financování vysokoškolského studia, například formou stipendia a půjčky od veřejného orgánu nebo instituce (gesce MŠMT/Veřejné vysoké školy)
    • V českém prostředí neexistuje jedna centralizovaná služba, která by obsáhla tento postup v celé jeho šíři. Veřejné vysoké školy mají svá vlastní pravidla pro udělování stipendií, stejně tak platí jiná pravidla pro stipendia poskytovaná MŠMT. Proto jednotliví aktéři na elektronizaci těchto služeb pracují odděleně, nicméně přístup k těmto službám je umožněn ze společného rozcestníku, a to i pro zahraniční uživatele.
  • Podání počáteční žádosti o přijetí na veřejnou vysokoškolskou instituci (gesce MŠMT/Veřejné vysoké školy)
    • Podobně jako u žádosti o financování vysokoškolského studia výše, ani u podání počáteční žádosti neexistuje v českém prostředí jedna centralizovaná služba, jelikož si samotný proces řídí VVŠ samy. Proto, podobně jako výše, jednotlivé VVŠ pracují na elektronizaci této služby odděleně, nicméně přístup k těmto službám je umožněn ze společného rozcestníku, a to i pro zahraniční uživatele.
    • Více informací je také dostupných v rámci detailního popisu služby „Přijetí ke studiu na vysoké škole“.
  • Žádost o akademické uznání diplomů, osvědčení či jiných dokladů o studiu nebo kurzech (gesce MŠMT, MV, MO)
  • Žádost o určení použitelných právních předpisů sociálního zabezpečení v souladu s hlavou II Nařízení (ES) č. 883/2004 (gesce MPVS/ČSSZ)
    • V českém prostředí se v případě této služby jedná o žádost o vystavení dokumentu A1. Tato služba byla digitalizována a zpřístupněna prostřednictvím ePortálu ČSSZ, přičemž je dostupná i pro zahraniční uživatele.
  • Oznámení změn osobní nebo profesní situace osoby pobírající dávky sociálního zabezpečení, které jsou pro tyto dávky relevantní (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronicky vyplnitelných tiskopisů na ePortálu ČSSZ, dostupných i pro zahraniční uživatele.
  • Podání přiznání k dani z přijmu (fyzické osoby) (gesce MF/GFŘ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronických podání na portálu Moje daně, a to i pro zahraniční uživatele.
  • Registrace motorového vozidla pocházejícího z jiného členského státu nebo v členském státě již registrovaného, standardními postupy (gesce MD)
    • V českém prostředí je tato služba implementována jako jedna ze služeb v rámci Portálu dopravy prostřednictvím podání související žádosti, dostupného i pro zahraniční uživatele. V současnosti je možné žádost zahájit elektronicky, nicméně samotné podání je nutné učinit fyzicky na úřadě, v brzké budoucnosti bude možné žádost podat také elektronicky.
  • Získání známek pro používání vnitrostátní silniční infrastruktury: časové poplatky (kupóny), poplatky na základě ujeté vzdálenosti (mýtné) vydané veřejným orgánem či institucí (gesce MD)
  • Žádost o důchod a předdůchodové dávky z povinných systémů (gesce MPSV/ČSSZ)
    • Služby související s žádostmi o důchod a předdůchodové dávky jsou v českém prostředí elektronizovány jako jedny ze služeb poskytovaných prostřednictvím ePortálu ČSSZ, přičemž jsou dostupné i pro zahraniční uživatele mající příslušné nároky.
  • Žádost o informace o údajích souvisejících s důchodem z povinných systémů (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronické služby dostupné na ePortálu ČSSZ, přístupné i pro zahraniční uživatele mající příslušné nároky.
  • Ohlašování podnikatelské činnosti, povolení k podnikatelské činnosti, změny v podnikatelské činnosti a ukončení podnikatelské činnosti bez insolvenčního nebo likvidačního řízení vyjma počáteční registrace podnikatelské činnosti v obchodním rejstříku a vyjma postupů týkajících se založení nebo jakékoli následné evidence společností ve smyslu čl. 54 druhého pododstavce Smlouvy o fungování EU (gesce MPO)
    • Tato služba se v podstatě skládá ze čtyř samostatných leč propojených služeb, které mají pokrýt celý životní cyklus podnikání. V českém prostředí je řešena prostřednictvím Portálu živnostenského podnikání a je přístupná i pro zahraniční uživatele.
  • Registrace zaměstnavatele (fyzické osoby) do povinného důchodového systému a systému pojištění (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronicky vyplnitelných tiskopisů na ePortálu ČSSZ, dostupných i pro zahraniční uživatele.
  • Registrace zaměstnanců do povinného důchodového systému a systému pojištění (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronicky vyplnitelných tiskopisů na ePortálu ČSSZ, dostupných i pro zahraniční uživatele.
  • Podání přiznání k dani z příjmu (právnické osoby) (gesce MF)
    • Podobně jako v případě fyzických osob, je i tato služba v českém prostředí digitalizována prostřednictvím elektronických podání na portálu Moje daně, a to i pro zahraniční uživatele.
  • Oznámení určené systému sociálního zabezpečení o ukončení smlouvy se zaměstnancem, s výjimkou postupů pro hromadné propouštění zaměstnanců (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronicky vyplnitelných tiskopisů na ePortálu ČSSZ, dostupných i pro zahraniční uživatele.
  • Úhrada příspěvků na sociální zabezpečení za zaměstnance (gesce MPSV/ČSSZ)
    • V českém prostředí je tato služba digitalizována prostřednictvím elektronicky vyplnitelných tiskopisů na ePortálu ČSSZ, dostupných i pro zahraniční uživatele.

Do Přílohy II nařízení byly ke dni 24. září 2023 nad rámec původních 21 postupů doplněny další dva postupy, a to jako součást novelizace nařízení prostřednictvím Aktu o správě dat10).

  • Oznámení poskytovatele služeb zprostředkování dat
    • Elektronizaci této služby bude mít v gesci ČTÚ, jakmile vstoupí v účinnost adaptační zákon k Aktu o správě dat.
  • Registrace jako organizace pro datový altruismus uznaná v Unii
    • Elektronizaci této služby bude mít v gesci ČTÚ, jakmile vstoupí v účinnost adaptační zákon k Aktu o správě dat.
Pokyny pro implementaci online postupů dle Přílohy II včetně systému OOTS

Evropská komise pravidelně aktualizuje dokument „Návod k rozsahu postupů dle Přílohy II“. Tento dokument vysvětluje samotný obsah jednotlivých postupů z pohledu front-office a rovněž zahrnuje očekávaný výstup pro uživatele. Vodítka Evropské komise pro zajištění nediskriminace a zpřístupnění postupů pro přeshraniční uživatele jsou obsažené v dalším dokumentu „Pokyny pro přeshraniční přístup k online procedurám“. Pro národní potřeby byla vytvořena tzv. Příručka k digitalizaci postupů. Ta zahrnuje všechny postupy z Přílohy II nařízení, které je třeba na národní úrovni digitalizovat, včetně jejich aktuálního stavu.

Termín pro dokončení digitalizace postupů byl nařízením stanoven na 12. prosinec 2023. Vzhledem k velké variabilitě postupů a jejich různého stavu připravenosti nebylo účelné svazovat postupy v předchozích materiálech jednotným harmonogramem pro implementaci na národní úrovni. Související usnesení ze dne 1. února 2023 č. 81 ve svém bodě II. 3. c) požadovalo, aby gestoři jednotlivých postupů informovali o dosažením pokroku v implementaci k 30. červnu 2023 a k 12. prosinci 2023, což gestoři naplnili. U většiny postupů pokrytých nařízením však bude zapotřebí dále pracovat v kontextu jejich funkcionality, a to zejména ve vztahu k zahraničním uživatelům.

Online postupy uvedené v nařízení musejí být elektronizovány tak, aby umožňovaly přeshraniční výměnu důkazů prostřednictvím technického systému OOTS, jehož základní principy měly být schváleny v prováděcím předpise do 30. června 2021. EK představila svůj návrh prováděcího předpisu „pouze jednou“ již na jaře 2021, nicméně ten nebyl komitologickým výborem pro SDG schválen. Členské státy včetně České republiky následně v průběhu roku 2021 měly možnost své výhrady adresovat EK, za tímto účelem proběhla i série bilaterálních jednání. Vzhledem k velkému množství připomínek se Evropská komise rozhodla přepracovat svůj původní návrh prováděcího předpisu k OOTS. Finální verze předpisu byla schválena 5. srpna 2022 a následně zveřejněna 7. září 2022 jako prováděcí nařízení Komise (EU) 2022/1463, což je více než rok po termínu stanoveném v nařízení. Současně je nutno poznamenat, že konkrétní technické specifikace jsou vypracovávány a průběžně aktualizovány ve spolupráci s ČS v rámci souvisejících pracovních podskupin zmíněných na str. 8 tohoto materiálu. EK současně zpřístupnila back-end systémy pro OOTS těsně před samotným spuštěním systému, které tak nemohly být včas naplněny ze strany ČS.

Jednak z důvodu zpoždění Komise v rámci schvalování dotčeného prováděcího aktu a také z důvodu neexistence finálních technických dokumentů došlo k výraznému zpoždění v implementaci OOTS na úrovni všech členských států, ale jak již bylo zmíněno výše, i samotné Evropské komise. Toto zpoždění bude znatelné i v průběhu roku 2024, kdy bude většina ČS napojovat své orgány a jejich dotčené služby na OOTS. Některé ČS již však avizovaly, že ani na konci roku 2024 nebudou na systém napojeny ani jednou ze svých služeb. V ČR není zatím na systém OOTS k xx. únoru 2024 napojena žádná ze služeb požadovaných nařízením.

Členské státy mají povinnost systém OOTS nabídnout uživatelům při využití elektronických postupů uvedených v Příloze II nařízení, ale také u postupů zavedených směrnicemi 2005/36/ES11), 2006/123/ES12), 2014/24/EU13) a 2014/25/EU14). V případě výše uvedených směrnic je potřeba k dalšímu postupu v implementaci konkrétnějších vodítek ze strany Evropské komise, které bohužel v tuto chvíli nejsou dostupné. V této souvislosti je potřeba zmínit i potvrzení možnosti využití datových schránek a jejich kompatibility s nařízením ze strany EK, kde však Komise současně upozornila, že způsob získání českých datových schránek nelze považovat pro zahraničního uživatele za „zcela online“. Z toho důvodu je v případech, kdy by se použila datová schránka, umožněno zahraničnímu uživateli vykonat dané postupy prostřednictvím žádosti podepsané kvalifikovaným elektronickým podpisem.

Protože je česká část systému OOTS stejným informačním systémem veřejné správy (dále jen „ISVS“), jako jakýkoliv jiný ISVS, je komunikace s ním možná pouze prostřednictvím referenčního rozhraní veřejné správy. Nedefinují se tedy žádná API, stejně tak popis volání a odpovědi je shodný pro všechny údaje volané na eGSB/ISSS pomocí služby „G1 gsbCtiData“ nebo „G11 gsbZapisData“.15) V neposlední řadě je také zapotřebí připojení do Centrálního místa služeb.

Co se týče procesních požadavků, je nutné, aby gestoři náležitě ohlásili související agendy veřejné správy do AISP a přiřadili jim oprávnění na údaje jiných relevantních agend (např. ztotožnění fyzických osob proti registru občanů), a současně umožnili poskytování údajů, které jsou součástí důkazů relevantních pro služby v rámci nařízení. Pro samotnou přeshraniční výměnu důkazů je zapotřebí nejprve naplnit ve spolupráci s DIA a MPO portál EK „Common Services“, který má sloužit jako úložiště informací o důkazech, jejich poskytovatelích a návaznostech na postupy dle Přílohy II nařízení. Na základě těchto informací pak budou směřovány jednotlivé požadavky z jiných členských států na české poskytovatele důkazů a naopak.

Implementace asistenčních služeb

Členské státy jsou povinovány poskytnout ve vztahu k asistenčním službám základní informace o jednotlivých službách, přičemž obsah i kvalita samotných asistenčních služeb je nařízením konkretizována. Asistenční služby musí být poskytovány v přiměřených lhůtách s přihlédnutím ke složitosti žádosti, uživatelé musí být informováni o případném prodloužení těchto lhůt a o eventuální nové lhůtě a o způsobu uhrazení případných poplatků za danou službu.

Nařízení také ukládá povinnost členským státům, aby sbíraly statistiky a zpětnou vazbu od uživatelů, kteří využijí asistenční služby. Tato data se týkají konkrétně počtu, původu a typu uživatelů asistenčních služeb a služeb pro řešení problémů. Tyto statistiky jsou v současné době sbírány jednotlivými službami individuálně a dvakrát ročně jsou prostřednictvím MPO předávány Evropské komisi skrze back-office portálu Your Europe.

Financování

MPO na základě hodnocení dopadů EK a jejich vztažení na tehdejší míru plnění požadavků nařízení vyhodnotilo v roce 2019 náklady na elektronizaci SDG na 265 mil. Kč. Tato částka však nebrala v potaz míru elektronizace jednotlivých postupů, a z toho důvodu byly jednotlivé resorty na podzim 2019 vyzvány k poskytnutí vlastních odhadů. Částka 265 mil. Kč včetně DPH byla předběžně dohodnuta v rámci programu Digitální Česko a rozdělena na následující roky s tím, že v roce 2020 bylo MPO přiděleno 42 mil. Kč k přerozdělení mezi resorty, zatímco pro roky 2021 (173 mil. Kč) a 2022 (50 mil. Kč) si resorty již žádaly o prostředky do svých rozpočtových kapitol samy.

V reakci na výzvu NAKIT MPO rovněž zkoordinovalo doplnění projektu „Implementace SDG“ do Národního plánu obnovy. MPO vyzvalo gestory jednotlivých postupů, zda by měly zájem využít prostředky z NPO pro dokončení digitalizace postupů. V návaznosti na zájem projevený MŠMT a MPSV/ČSSZ byly do NPO zařazeny čtyři níže uvedené online postupy v rámci SDG:

  • „Žádost o určení použitelných právních předpisů v souladu s hlavou II nařízení (ES) č. 883/2004“, (Gestor a realizátor: MPSV, ČSSZ)
  • „Žádost o důchod a předdůchodové dávky z povinných systémů“, (Gestor a realizátor: MPSV, ČSSZ)
  • „Žádost o financování vysokoškolského studia, například formou stipendia a půjčky od veřejného orgánu nebo instituce“ (Gestor a realizátor: v oblasti vládních stipendií je MŠMT věcným gestorem a realizátorem je DZS, v oblasti stipendií VVŠ je MŠMT věcným gestorem, a realizátorem jsou VVŠ)
  • „Podání počáteční žádosti o přijetí na veřejnou vysokoškolskou instituci“ (Gestor a realizátor: MŠMT je věcným gestorem a realizátorem jsou VVŠ)

V rámci prostředků z NPO ČSSZ pro elektronizaci dvou služeb identifikovalo celkovou částku 69,99 mil. Kč, zatímco MŠMT identifikovalo jako nutnou částku 167,63 mil. Kč.16) Celkový centrální rozpočet na implementaci SDG tedy dosáhl částky 279, 62 mil. Kč na roky 2020 až 2023. V tuto chvíli nejsou nárokovány dodatečné náklady na implementaci SDG nad rámec tohoto rozpočtu, nicméně nelze vyloučit, že při naplňování požadavků souvisejících s implementací a napojením na systém OOTS nevyvstanou další požadavky. Jednotná digitální brána je tak v rámci Národního plánu obnovy uvedena v rámci komponenty 1.1 „Digitální služby pro koncové uživatele“, jejíž vlastníkem je MV.

Propagace SDG

Nařízení ve svém článku 23 ukládá členským státům a Evropské komisi povinnost propagovat projekt Jednotné digitální brány. První fáze propagace začala akcí „The Digital Roadshow“ (26. května 2021). V rámci této aktivity jednotlivé členské státy ve spolupráci s EK uspořádaly událost, která se tematicky dotýkala jedné z životních událostí z Přílohy I nařízení. Informace spojené s ní se pak staly dohledatelné prostřednictvím portálu Your Europe. Tato fáze propagace měla za cíl zvýšit povědomí o značce Your Europe.

V druhé fázi byla propagace zaměřena na všechny věkové kategorie uživatelů, a to prostřednictvím tzv. „influencerů“ a za použití sociálních sítí např. Facebook, Twitter či LinkedIn nebo participací na vybraných společenských akcích.

V roce 2023 se pozornost Evropské komise i členských států soustředila primárně na finální fázi implementaci, z toho důvodu nebyly pořádány specifičtější propagační akce ani ze strany EK ani ze strany ČS. Komise však průběžně informuje o portálu Your Europe na svých sociálních sítích. V souvislosti s uplynutím posledního implementačního termínu, kterým byl 12. prosinec 2023, kdy také došlo k oficiálnímu spuštění systému OOTS, se EK chystá k řadě nových propagačních aktivit. Ze strany členských států je však Komise od přílišné propagace odrazována, minimálně do chvíle, než bude na OOTS napojena většina států a většina služeb.

V okamžiku, kdy v roce 2018 nařízení vstoupilo oficiálně v platnost, bylo jasné, že obsah jeho jednotlivých Příloh nebude konečný, ale bude předmětem nepravidelného rozšiřování. O to se pokouší řada legislativních návrhů z různých oblastí, všechny jsou však provázány s tématem vnitřního trhu a také mají související právní základ v podobě čl. 114 SFEU.

Kromě dvou postupů vyplývajících z Aktu o správě dat, jež jsou zmíněny v rámci kapitoly 2.3.2. tohoto materiálu, jsou k xx. únoru 2024 v unijním legislativním procesu následující předpisy, které určitým způsobem rozšiřují Přílohy nařízení:

Vzhledem k uplynutí termínu pro digitalizaci daného nařízením budou termíny pro položky nově zařazené do Příloh nařízení dány příslušnými předpisy, což musí zejména gestoři těchto předpisů vést v patrnosti.

Gesce nad informacemi a postupy

Dosavadní stav implementace informací a postupů včetně gescí

Příloha I – informace
Oblasti informací Informace Gestor Cílový portál
A. Cestování v rámci Unie 1. dokumenty požadované od občanů Unie, jejich rodinných příslušníků, kteří nejsou občany Unie, nezletilých cestujících bez doprovodu a osob, které nejsou občany Unie, cestují-li přes hranice v rámci Unie (průkaz totožnosti, vízum, cestovní pas) MV PVS
2. práva a povinnosti osob cestujících v Unii a z Unie letadlem, vlakem, lodí, autobusem, a osob, které si zakoupily soubory cestovních služeb nebo další služby spojené s cestováním EK
3. asistence v případě snížené pohyblivosti při cestování v Unii a z Unie EK
4. přeprava zvířat, rostlin, alkoholu, tabáku, cigaret a dalšího zboží při cestování v Unii EK
5. hlasová volání a odesílání a přijímání elektronických zpráv a elektronických údajů v rámci Unie EK
B. Práce a důchod v rámci Unie 1. hledání zaměstnání v jiném členském státě MPSV PVS
2. nástup do zaměstnání v jiném členském státě MPSV
3. uznávání kvalifikací za účelem získání zaměstnání v jiném členském státě MŠMT
4. zdanění v jiném členském státě MF
5. pravidla pro pojištění odpovědnosti a povinné pojištění v souvislosti s bydlištěm nebo zaměstnáním v jiném členském státě MF
6. podmínky zaměstnávání, včetně vyslaných pracovníků, jak jsou stanovené zákonem nebo podzákonným právním předpisem (včetně informací o pracovní době, placené dovolené, nárocích na dovolenou, právech a povinnostech týkajících se práce přesčas, zdravotních prohlídkách, ukončení smluv, výpovědích a propouštění pro nadbytečnost)MPSV

MZd
7. rovné zacházení (pravidla zakazující diskriminaci na pracovišti, pravidla pro stejnou odměnu za tutéž práci pro muže a ženy a pro stejnou odměnu za práci pro zaměstnance pracující na základě smlouvy na dobu určitou či smlouvy na dobu neurčitou) MPSV

ÚVL
8. ochrana zdraví a bezpečnosti v souvislosti s různými druhy činností MZd

MPSV
9. práva a povinnosti týkající se sociálního zabezpečení v Unii, včetně práv a povinností souvisejících se získáním důchodu MPSV
C. Vozidla v Unii 1. dočasné či trvalé přemístění vozidla do jiného členského státu MD PVS
2. získání řidičského průkazu a prodloužení jeho platnosti MD
3. uzavření povinného pojištění motorového vozidla MF
4. nákup a prodej motorového vozidla v jiném členském státě MF

MPO
5. vnitrostátní pravidla silničního provozu a požadavky na řidiče, včetně obecných pravidel pro používání vnitrostátní silniční infrastruktury: časové poplatky (kupóny), poplatky na základě ujeté vzdálenosti (mýtné), emisní známky MD

MŽP
D. Pobyt v jiném členském státě 1. dočasné či trvalé přestěhování do jiného členského státu MV PVS
2. koupě a prodej nemovitého majetku, včetně podmínek a povinností, pokud jde o zdanění, vlastnictví nebo užívání tohoto majetku, včetně jeho užívání jakožto přechodného bydliště MZeMV

MF

MSp
3. účast v obecních volbách a volbách do Evropského parlamentu MV
4. požadavky týkající se povolení k pobytu pro občany Unie a jejich rodinné příslušníky, včetně rodinných příslušníků, kteří nejsou občany Unie MV
5. podmínky platné pro naturalizaci pro státní příslušníky jiného členského státu MV
6. pravidla použitelná v případě úmrtí, včetně pravidel pro repatriaci tělesných ostatků do jiného členského státu MMR

MPO

MV

MZd

MZV
E. Vzdělávání nebo stáž v jiném členském státě 1. vzdělávací systém v jiném členském státě, včetně předškolního vzdělávání a péče, základní vzdělávání, středoškolské vzdělávání, vysokoškolské vzdělávání a vzdělávání dospělých MŠMT

MPSV 		PVS
2. dobrovolnická činnost v jiném členském státě MV
3. stáž v jiném členském státě MPSV
4. provádění výzkumu v jiném členském státě jakožto součást vzdělávacího programu MŠMT
F. Zdravotní péče 1. poskytování zdravotní péče v jiném členském státě MZd PVS
2. nákup předepsaných léčivých přípravků v jiném členském státě, než kde byl vydán lékařský předpis, online nebo osobně EK
3. pravidla zdravotního pojištění platná pro krátkodobý nebo dlouhodobý pobyt v jiném členském státě, včetně postupu, jak podat žádost o evropský průkaz zdravotního pojištění MZd PVS
4. všeobecné informace o právech na přístup k dostupným veřejným preventivním opatřením v oblasti zdravotní péče nebo o povinnostech vyplývajících z účasti na těchto opatřeních MZd
5. služby poskytované na vnitrostátních číslech tísňového volání, včetně čísel „112“ a „116“ MPO

MV
6. práva a podmínky pro umístění do zařízení ústavní péče MZd

MPSV
G. Občanská a rodinná práva 1. narození, opatrovnictví nezletilých dětí, rodičovská odpovědnost, pravidla pro náhradní mateřství a osvojení, včetně osvojení druhým rodičem, vyživovací povinnost vůči dítěti v přeshraniční rodinné situaci MSp

MV

MPSV 		PVS
2. život v páru osob s různou státní příslušností včetně párů stejného pohlaví (manželství, občanské nebo registrované partnerství, rozluka, rozvod, manželská majetková práva, práva osob žijících ve společné domácnosti) MSp

MV
3. pravidla uznávání pohlaví MSp

MV

MZd
4. práva a povinnosti týkající se dědictví v jiném členském státě, včetně daňových předpisů MSp

MF
5. práva a pravidla použitelná v případě přeshraničního únosu dítěte rodičem EK
H. Práva spotřebitele 1. nákup zboží, digitálního obsahu nebo služeb (včetně finančních služeb) z jiného členského státu, online nebo osobně EK
2. vlastnictví bankovního účtu v jiném členském státě EK
3. připojení k veřejným službám, jako například plyn, elektřina, voda, nakládání s odpadem, telekomunikační služby a internet MPO

MŽP

MZe 		PVS
4. platby, včetně úhrad a prodlení při přeshraničních platbách EK
5. práva spotřebitelů a záruky týkající se nákupu zboží a služeb, včetně postupů pro řešení spotřebitelských sporů a odškodnění MPO

MSP

MF 		PVS
6. bezpečnost spotřebního zboží MPO
7. pronájem motorového vozidla EK
I. Ochrana osobních údajů 1. výkon práv subjektů údajů v souvislosti s ochranou osobních údajů EK
J. Založení podniku, jeho provozování a ukončení jeho činnosti1. registrace, změna právní formy nebo ukončení činnosti podniku (registrační postupy a právní formy pro vykonávání obchodní činnosti) MSp

MPO 		BI.cz
2. přemístění podniku do jiného členského státu MSp

MPO
3. práva duševního vlastnictví (žádost o patent, registrace ochranné známky, náčrt nebo návrh, získání licence pro reprodukování) MPO
4. korektnost a transparentnost v obchodních praktikách, včetně práv spotřebitele a záruk týkajících se prodeje zboží a služeb MPO
5. nabízení online platforem pro přeshraniční platby při prodeji zboží a služeb online EK
6. práva a povinnosti vyplývající ze smluvního práva, včetně úroků z opožděných plateb MSp BI.cz
7. insolvenční řízení a likvidace společností MSp
8. pojištění úvěrů MF
9. fúze společností nebo prodej podniku MSp
10. občanskoprávní odpovědnost ředitelů společnosti MSp
11. pravidla a povinnosti, pokud jde o zpracování osobních údajů EK
K. Zaměstnanci 1. podmínky zaměstnávání stanovené zákonem nebo podzákonným právním předpisem (včetně pracovní doby, placené dovolené, nároků na dovolenou, práv a povinností týkajících se práce přesčas, zdravotních prohlídek, ukončení smluv, výpovědí a propouštění pro nadbytečnost) MPSV BI.cz
2. práva a povinnosti týkající se sociálního zabezpečení v Unii (registrace jako zaměstnavatel, registrace zaměstnanců, oznámení ukončení smlouvy zaměstnance, úhrada příspěvků na sociální zabezpečení, práva a povinnosti týkající se důchodů) MPSV
3. zaměstnávání pracovníků v jiném členském státě (vysílání pracovníků, pravidla týkající se volného pohybu služeb, požadavky týkající se pobytu pracovníků) MPSV

MŠMT

MPO

MV
4. rovné zacházení (pravidla zakazující diskriminaci na pracovišti, pravidla pro stejnou odměnu za tutéž práci pro muže a ženy a stejnou odměnu za práci pro zaměstnance pracující na základě smlouvy na dobu určitou nebo smlouvy na dobu neurčitou) MPSV

ÚVL
5. pravidla týkající se zastoupení zaměstnanců MPSV
L. Daně 1. DPH: informace týkající se obecných pravidel, sazby a osvobození od daně, registrace k DPH a platba DPH, vrácení DPH MF BI.cz
2. spotřební daně: informace týkající se obecných pravidel, sazby a osvobození od daně, registrace ke spotřební dani a platba spotřební daně, vrácení spotřební daně MF
3. cla a jiné odvody z dovozu EK
4. celní postupy pro dovoz a vývoz v rámci celního kodexu Unie EK
5. ostatní daně: platba, sazby, daňová přiznání MF BI.cz
M. Zboží 1. získání označení CE EK
2. pravidla a požadavky týkající se výrobků MPO

MZe

MZd 		BI.cz
3. určení použitelných norem, technické specifikace a získání certifikace výrobků MPO
4. vzájemné uznávání výrobků, na které se nevztahují unijní specifikace MPO
5. požadavky týkající se klasifikace, označování a balení nebezpečných chemických látek EK
6. prodej na dálku/mimo obchodní prostory: informace, které musí být zákazníkům sděleny předem, písemné potvrzení smlouvy, odstoupení od smlouvy, dodání zboží, další zvláštní povinnosti EK
7. vadné výrobky: práva spotřebitelů a záruky, povinnosti po uzavření obchodu, prostředky nápravy pro poškozenou stranu MPO BI.cz
8. certifikace a štítky (EMAS, energetické štítky, ekodesign, ekoznačka EU) EK
9. recyklace a nakládání s odpady MŽP BI.cz
N. Služby 1. získání licencí, oprávnění a povolení za účelem zahájení a provozování podnikání MPO BI.cz
2. oznámení přeshraniční činnosti orgánům MPO

MŠMT
3. uznávání odborných kvalifikací, včetně odborného vzdělání a odborné přípravy MŠMT

MPO
O. Financování podniku 1. získání přístupu k financím na úrovni Unie, včetně programů Unie týkajících se financování a podnikatelských grantů EK
2. získání přístupu k financím na vnitrostátní úrovni MMR

MPO

MF

MZe 		BI.cz
3. iniciativy určené podnikatelům (výměny pořádané pro nové podnikatele, poradenské programy atd.) MPO
P. Veřejné zakázky 1. účast ve veřejných nabídkových řízeních: pravidla a postupy MMR BI.cz
2. online předložení nabídky v reakci na veřejné výběrové řízení MMR
3. oznamování nesrovnalostí v souvislosti s výběrovým řízením MMR
Q. Zdraví a bezpečnost při práci 1. ochrana zdraví a bezpečnosti v souvislosti s různými druhy činností, včetně prevence rizik, informací a školení MZd BI.cz
Příloha II - postupy
Životní událost Postup Očekávaný výstup Gestor Cílový portál
Narození Žádost o potvrzení registrace narození Potvrzení o registraci narození nebo rodný list MV PVS/PO
Místo pobytu Žádost o potvrzení místa pobytu Potvrzení registrace stávající adresy MV PVS/PO
Studium Žádost o financování vysokoškolského studia, například formou stipendia a půjčky od veřejného orgánu nebo instituce Rozhodnutí ve věci žádosti o financování nebo potvrzení o přijetí žádosti MŠMT PVS/PO
Podání počáteční žádosti o přijetí na veřejnou vysokoškolskou instituci Potvrzení o přijetí žádosti MŠMT PVS/PO
Žádost o akademické uznání diplomů, osvědčení či jiných dokladů o studiu nebo kurzech Rozhodnutí týkající se žádosti o uznání MŠMT

MV

MO 		PVS/PO
Práce Žádost o určení použitelných právních předpisů v souladu s hlavou II nařízení (ES) č. 883/2004 Rozhodnutí ve věci použitelných právních předpisů MPSV

(ČSSZ) 		PVS/PO
Oznámení změn osobní nebo profesní situace osoby pobírající dávky sociálního zabezpečení, které jsou pro tyto dávky relevantní Potvrzení o přijetí oznámení o změně MPSV

(ČSSZ,

GŘ ÚP)		PVS/PO
Žádost o evropský průkaz zdravotního pojištění (EHIC) Evropský průkaz zdravotního pojištění (EHIC) MZd (Zdravotní pojišťovny) PVS/PO
Podání přiznání k dani z příjmu (fyzické osoby) Potvrzení o přijetí přiznání MF PVS/PO
Přestěhování Registrace změny adresy Potvrzení o zrušení registrace předchozí adresy a o registraci nové adresy MV PVS/PO
Registrace motorového vozidla pocházejícího z členského státu nebo v členském státě již registrovaného, standardními postupy Doklad o registraci motorového vozidla MD PVS/PO
Získání známek pro používání vnitrostátní silniční infrastruktury: časové poplatky (kupóny), poplatky na základě ujeté vzdálenosti (mýtné) vydané veřejným orgánem či institucí Převzetí potvrzení o úhradě elektronické dálniční známky nebo potvrzení o úhradě mýtného MD PVS/PO
Získání emisních známek vydávaných veřejným orgánem nebo institucí Převzetí emisních známek nebo jiného dokladu o zaplacení MŽP PVS/PO
Důchod Žádost o důchod a předdůchodové dávky z povinných systémů Potvrzení o přijetí žádosti nebo rozhodnutí týkající se žádosti o důchod nebo předdůchodových dávekMPSV

(ČSSZ) 		PVS/PO
Žádost o informace o údajích souvisejících s důchodem z povinných systémů Přehled osobních údajů souvisejících s důchodem MPSV

(ČSSZ) 		PVS/PO
Zahájení, provozování a ukončení podnikatelské činnostiOhlašování podnikatelské činnosti, povolení k podnikatelské činnosti, změny v podnikatelské činnosti a ukončení podnikatelské činnosti bez insolvenčního nebo likvidačního řízení vyjma počáteční registrace podnikatelské činnosti v obchodním rejstříku a vyjma postupů týkajících se založení nebo jakékoli následné evidence společností ve smyslu čl. 54 druhého pododstavce Smlouvy o fungování EUPotvrzení o přijetí ohlášení nebo změny, nebo žádosti o povolení podnikatelské činnosti MPO BI.cz
Registrace zaměstnavatele (fyzické osoby) do povinného důchodového systému a systému pojištění Potvrzení o registraci nebo registrační číslo sociálního zabezpečení MPSV

(ČSSZ) 		BI.cz
Registrace zaměstnanců do povinného důchodového systému a systému pojištění Potvrzení o registraci nebo registrační číslo sociálního zabezpečení MPSV

(ČSSZ) 		BI.cz
Podání přiznání k dani z příjmu (právnické osoby) Potvrzení o podání přiznání MF BI.cz
Oznámení určené systému sociálního zabezpečení o ukončení smlouvy se zaměstnancem, s výjimkou postupů pro hromadné propouštění zaměstnanců Potvrzení o přijetí oznámení MPSV

(ČSSZ) 		BI.cz
Úhrada příspěvků na sociální zabezpečení za zaměstnance Příjmový doklad nebo jiná forma potvrzení úhrady příspěvků na sociální zabezpečení za zaměstnance MPSV

(ČSSZ) 		BI.cz
Příloha III - asistenční služby
Název asistenční služby nebo služby pro řešení problémů Gestor Cílový portál
Jednotná kontaktní místa MPO BI.cz
Kontaktní místa pro výrobky MPO BI.cz
Kontaktní místa pro stavební výrobky MPO BI.cz
Národní centra pomoci pro odbornou kvalifikaci MŠMT PVS
Vnitrostátní kontaktní místa pro přeshraniční zdravotní péčiMZd (KZP) PVS
Evropská síť služeb zaměstnanosti (EURES) MPSV (GŘ ÚP)PVS
Řešení spotřebitelských sporů on-line MPO (ESC) PVS

Mobilní klíč eGovernmentu

Úroveň záruky: Značná

Mobilní klíč eGovernmentu (aplikace pro mobilní telefon či tablet) původně vznikl jako jedna z možností přihlašování k Informačnímu systému Datových schránek. Pro jeho snadné použití, a také možnost využít již existující mobilní aplikaci, proběhlo rozšíření o možnost přihlášení i přes Národní bod.

Nosičem Mobilního klíče eGovernmentu je zařízení, na kterém je naistalována aplikace „Mobilní klíč eGovernmentu“. Aplikaci je možné naistalovat z obchodu s aplikacemi (dostupné pro Google Play a Apple App Store). Aplikace funguje na principu sejmutí QR kódu z obrazovky zařízení, na kterém se někam přihlašujete. Není tedy nutné si pamatovat často složité přihlašovací údaje, ani opisovat dlouhé kódy ze SMS, zaslané do vašeho mobilního telefonu.

Pro umožnění přihlašování je třeba danou instanci jednorázově navázat (registrovat) na fyzickou osobu. To je možné provést několika způsoby, pro každý způsob je v rámci aplikace připraven jednoduchý návod, jak postupovat.

Jakmile je účet aktivní, tak již nic nebrání jej využívat pro přihlašování k elektronickým službám státu. Jednou z výhod je možnost zasílání upozornění, že Vaše identita byla použita k přihlášení k nějaké online službě prostřednictvím Národního bodu a přispívá tak k případnému odhalení zneužití některého z prostředků. Vyjma zasílání upozornění z Národního bodu umožňuje aplikace zasílání upozornění i z Informačního systému Datových schránek, a uživatel tak má přehled, zda obdržel datovou zprávu.

Využití: Přihlašování pomocí Mobilního klíče eGovermentu lze využít pro přihlašování k online službám státu na úrovni značná a nižší. Jednou z největších výhod je snadnost použití, kdy po odemčení aplikace stačí prosté sejmutí obrazovky fotoaparátem a celý přihlašovací proces již nevyžaduje další zadávání hesel či nějakého uživatelského jména. V případě přihlašování na zařízení, kde je vlastní aplikace nainstalována (na vlastním mobilním telefonu) je situace ještě jednodušší a odpadá kopírování různých SMS kódů a podobně mezi okny aplikací. Jak již bylo zmíněno, tak další výhodou je získávání upozornění, ať už z Národního bodu, tak z Informačního systému Datových schránek.

Více informací: Info Identita Občana

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.

Národní identitní autorita

Popis Národní identitní autority

Národní identitní autorita vytváří federativní systém zajišťující orgánům veřejné správy státem garantované služby identifikace a autentizace, který se skládá z následujících komponent:

  • Národní bod pro identifikaci a autentizaci jako centrální bod federativního systému, který zajišťuje komunikaci a registraci účastníků federace. Tato komponenta zajišťuje současně vždy jednoznačné ztotožnění osoby, která prokazuje svoji totožnost s využitím autentizačních prostředků (prostředků pro elektronickou identifikaci). Je definován v zákoně č. 250/2017 Sb. jakožto informační systém veřejné správy podporující proces elektronické identifikace a autentizace prostřednictvím kvalifikovaného systému elektronické identifikace. Zajišťuje orgánům veřejné správy státem garantované služby identifikace a autentizace včetně federace údajů o subjektu práva ze základních registrů a možnost předávání přihlašovací identity dle principy Single Sign-On.
  • Kvalifikovaný správce, který vydává jednoznačně identifikovaným fyzickým osobám prostředky pro vzdálenou autentizaci (prokázání totožnosti) a provádí veškeré činnosti spojené se správou těchto prostředků a prokazováním totožnosti fyzické osoby, tj. spravuje kvalifikovaný systém elektronické identifikace.
  • Kvalifikovaný poskytovatel online služeb, který připojuje k Národnímu bodu online služby, ke kterým je vyžadováno přihlášení prostředky vydanými kvalifikovanými správci.
  • Základní registry, které poskytují jednoznačnou identifikaci osoby a zajištění vazeb této osoby vůči referenčním údajům o osobě.
  • Národní uzel eIDAS, který je samostatnou součástí Národního bodu a zajišťuje přijímání vzdáleného prokázání totožnosti z ohlášených systémů dle nařízení eIDAS a předávání vzdálené identifikace a autentizace z České republiky ostatním státům EU. Ostatní státy EU musí akceptovat české identity od 13.9.2020, kdy vypršela roční lhůta pro zavedení akceptace ohlášeného prostředku elektronického občanského průkazu.

Pro osoby uvedené v ROB přihlašující se prostředky pro elektronickou identifikaci vydanými v ČR nebo přihlašující se identitou v rámci eIDAS z členských států EU nemusí OVS řešit přihlašovací identity pro své klienty samo.

  • V současném stavu ROB (stav As-Is) tedy pouze pro občany ČR a cizince s trvalým/přechodným pobytem (cizinec musí být evidován v ROB).
  • V budoucím stavu (stav To-Be) pro občany ČR, cizince s trvalým/přechodným pobytem a jiné fyzické osoby (EjFO), které mají k ČR právní či majetkový vztah (zahraniční vlastník nemovitosti, zahraniční lékař, zahraniční student, apod.).

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

Seznam poskytovatelů identity (Identity Provider; IdP)

Název identitního prostředku Typ prostředku úroveň záruky prostředku (LoA) Popis URL Použití pro mezinárodní ověření identity v eIDAS
eObčanka Elektronický občanský průkaz s aktivovanou částí elektronické identifikace Vysoká (nejvyšší možná dle eIDAS) Přihlášení prostřednictvím nového občanského průkazu vydaného po 1. 7. 2018, který obsahuje čip a jeho elektronická funkcionalita byla aktivována. Pro přihlášení tímto občanským průkazem je zapotřebí čtečka dokladů a nainstalovaný příslušný software.https://info.identitaobcana.czANO - eObčanka je zatím jako jediný prostředek ohlášen dle eIDAS pro potřeby mezinárodní identifikace a autentizace. Její použití je pro ostatní státy v rámci eIDAS povinné k použití od září 2020.
Mobilní klíč eGovernmentuMobilní aplikace s funkcí ověřování QR kódůZnačná Mobilní klíč eGovermentu představuje využití přihlašování bez potřeby zadávání dalších ověřovacích kódů. Po jeho instalaci a aktivaci Vám bude umožněno přihlašování ke službám využívajícím elektronickou identifikaci prostřednictvím Národního bodu. Aby vše fungovalo, je nutné mít nainstalovanou aplikaci mobilního klíče na svém mobilním zařízení. Aplikace mobilního klíče je shodná se stávající aplikací mobilního klíče ISDS. Pokud již vlastníte tuto aplikaci pro přihlašování k datovým schránkám, aktualizací této aplikace získáte i možnost využít ji i pro přihlašování ke službám prostřednictvím Národního bodu. Tento prostředek nevyžaduje od uživatele zadávat při jeho použití žádné hodnoty, stačí pouze vyfotit QR kód mobilním zařízením, anebo jej nechat přečíst z obrazovky téhož mobilního zařízení. Mobilní klíč má dále jednu mimořádnou vlastnost, kterou ostatní prostředky nemohou nabídnout. Díky svému propojení s jádrem systému Národního bodu (NIA) dovoluje zapnout notifikaci přihlášení i jakýmkoliv jiným prostředkem téhož uživatele. To je výrazný bezpečnostní prvek, který dovoluje uživateli být v reálném čase informován o tom, že případně někdo jiný nějaký jeho prostředek zneužil a přihlásil se jím.https://info.identitaobcana.cz/mep/NE
NIA ID Jméno + heslo + sms. Klasické přihlašování pomocí druhého faktoru. Značná Přihlášení prostřednictvím uživatelského jména a hesla, které jste zadali při založení Vašeho identifikačního prostředku na portálu národního bodu. Přihlášení dokončíte zadáním ověřovacího kódu, který Vám bude zaslán ve formě SMS na Vaše telefonní číslo.https://info.identitaobcana.cz/ups/NE
První certifikační autorita, a.s. Čipová karta Starcos s identifikačním certifikátem Vysoká (nejvyšší možná dle eIDAS) Přihlášení prostřednictvím čipové karty Starcos společnosti První certifikační autorita, a.s., která byla použita pro generování a uložení privátního klíče identitního komerčního certifikátu. Pro přihlášení budete potřebovat čtečku čipových karet (pokud není integrována do PC/NTB) a nainstalovaný ovládací software SecureStore (ke stažení z www.ica.cz).https://www.ica.cz/ica-identity-providerNE
MojeID - úroveň "značná" Přihlašovací údaje do účtu MojeID spárovaný s prostředkem FIDO Značná Přihlášení prostřednictvím účtu mojeID. Pro přihlášení je potřeba zabezpečit účet bezpečnostním klíčem (tokenem) certifikovaným od FIDO Alliance alespoň na úroveň L1, a to buď fyzickým (USB, NFC, Bluetooth), anebo systémovým (Windows Hello, Android v. 7 a vyšší). Dále je nutné mít účet mojeID aktivován pro přístup ke službám veřejné správy a jednorázově ověřit svou totožnost (již existujícím prostředkem nebo návštěvou Czech POINTu). Službu mojeID provozuje CZ.NIC, správce domény .CZ.https://www.mojeid.cz/NE
MojeID - úroveň "vysoká" Přihlašovací údaje do účtu MojeID spárovaný s prostředkem FIDO Vysoká Přihlášení prostřednictvím účtu mojeID. Pro přihlášení je potřeba zabezpečit účet bezpečnostním klíčem (tokenem) certifikovaným od FIDO Alliance alespoň na úroveň L1, a to fyzickým USB, NFC. Dále je nutné mít účet mojeID aktivován pro přístup ke službám veřejné správy a jednorázově ověřit svou totožnost (již existujícím prostředkem nebo návštěvou Czech POINTu). Službu mojeID provozuje CZ.NIC, správce domény .CZ.https://www.mojeid.cz/NE
IIG - International ID Gateway Výběr z možných identitních prostředků, které jsou ohlášené jinými členskými státy EU v rámci eIDAS uzlů nízká až vysoká dle daného prostředku Aktuálně je možné v rámci eIDAS uzlů vybírat z prostředků, které jsou zveřejnyny na stránkác eIDAS https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS NE
Bankovní identitaIdentita poskytovaná Československou obchodní bankou, a. s. Značná https://www.csob.cz/portal/csob/csob-identita Ne
Identita poskytovaná Českou spořitelnou, a. s. Značná https://www.csas.cz/cs/o-nas/bezpecnost-ochrana-dat/bankovni-identita Ne
Identita poskytovaná Bankou CREDITAS a.s Značná https://www.creditas.cz/ Ne
Identita poskytovaná Komerční bankou, a. s. Značná https://www.kb.cz/cs/podpora/bankovnictvi-a-nastroje/kb-bankovni-identita Ne
Identita poskytovaná Air Bankou, a. s. Značná https://www.airbank.cz/produkty/bankovni-identita/ Ne
Identita poskytovaná Fio Bankou, a. s. Značná https://www.fio.cz/bankovni-sluzby/bankovni-identita Ne
Identita poskytovaná MONETA Money Bank, a. s. Značná https://www.moneta.cz/otevrene-bankovnictvi/bankovni-identita Ne
Identita poskytovaná Raiffeisenbank, a.s. Značná https://www.rb.cz/informacni-servis/pro-media/tiskove-zpravy/tiskove-zpravy-2021/tiskove-zpravy-202109/01092021-bankovni-identita Ne
Identita poskytovaná UniCredit Bank Czech Republic and Slovakia, a.s. Značná https://www.unicreditbank.cz/cs/obcane/bankID.html Ne

Statistiky využití identitních prostředků

Data jsou informativní a platná k datu 1.5.2024

Celkové statistiky identitních prostředků
Celkem ID prostředků 15 580 362
Počet profilů alespoň s jedním aktivním prostředkem6 601 443
Celkový počet unikátních přihlášení 3 353 499
Konverze - procentuální zastoupení těch, kdo se skutečně přihlásili z těch, kdo se přihlásit mohli 50.80 %
Statistika za jednotlivé poskytovatele služeb
URL portálu Název portálu Celkem přihlášení
http://adisdpr.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy_2 309
http://adisepo.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy 24097
http://adisspr.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy_3 2353
http://sso.plzensky-kraj.cz http://sso.plzensky-kraj.cz 1
https://adisspr.mfcr.cz/auth MOJE daně – Elektronické služby Finanční správy 656280
https://agw.pardubickykraj.cz/authgateService Autentizační brána 1
https://aispms.justice.cz/cas Portál Probační a mediační služby - PP 5
https://aisportal.mpo.cz/AISCIPortal/NIA/overeni CzechInvest 538
https://aisportal.mpo.cz/aisportal/nia/overeni AIS MPO 74518
https://alpha.ezconvey.cz/AKVych/ProviderMetadata https://alpha.ezconvey.cz/AKVych/ProviderMetadata 3
https://api.dipsy.cz/v1/auth/nia-secure DiPSy 132010
https://api.vvz.nipez.cz/vvz-nia/ Věstník veřejných zakázek - Prod 4428
https://auth.mpsv.cz/ Jenda MPSV 324323
https://auth.projektovezamery.cz/auth/response/nia MMR 799
https://auth.vzp.cz Moje VZP 152635
https://authgate.kraj-jihocesky.gov.cz Jihočeký kraj - AuthGate 36
https://authgate.kr-vysocina.cz IDM Kraje Vysočina 1677
https://caas.szif.cz/cas/login?client_name=NIA Státní zemědělský intervenční fond 15
https://cak.cz.s6.abuco.cz/admin-moje-cak/ https://cak.cz.s6.abuco.cz/admin-moje-cak/ 12
https://card2.dev.cvut.cz/PrivateAccess CARD2 2
https://cas.cuni.cz/cas/sp/metadata Univerzita Karlova SDG CAS 1008
https://cas.mestouvaly.cz/simplesaml/module.php/clave/sp/metadata.php/clave/eidasSP/eidasSP Město Úvaly 220
https://cas.portalzp.cz/kms-cas PZP KMS NIA 1250
https://code.gov.cz/ code.gov.cz 3578
https://cportal.celnisprava.cz/cas cPortál Celní správy 45933
https://cro.slu.cz Centrální registr osob Slezské univerzity (CRO SU) 1
https://crv.mdcr.cz/ Registr silničních vozidel (RSV) 1
https://crz.policie.cz/WEB_CRZ_PRIHLASENI/Default.aspx Centrální registr zbraní 4190
https://ctu.gov.cz Český telekomunikační úřad - WWW 12
https://dataportal.eru.cz/ https://dataportal.eru.cz/ 198
https://dataportal.eru.gov.cz/ Datový portál ERÚ 1770
https://davkyuk.mpsv.cz/login/nia Dávky UK 260452
https://des.mpsv.cz/login Portál Dětské skupiny 1702
https://development.niatest.vfn.cz/ https://development.niatest.vfn.cz/ 1
https://dev-pacient.vfn.cz VFN DEV portál pacienta 11
https://dicr.cz/podani/zadost-dle-zakona-c-106-1999-sb 106 5
https://dmvs.cuzk.cz/cas ČÚZK - portál DMVS 2195
https://dotace.kr-karlovarsky.cz/gordic/ginis/app/RAP05/ Karlovarský kraj 1447
https://dotace.pardubickykraj.cz/portal Dotační portál Pk 1334
https://dotace-soc.pardubickykraj.cz/sp/shibboleth DOTACE-SOC Dotační portál 1
https://dpmkportal.mkcr.cz/NIA/overeni DPMK 6621
https://drazby.financnisprava.cz/nia_saml2/ drazby.financnisprava prod 1673
https://dron.caa.cz Registrace bezpilotních systémů 49209
https://dron.notia.cz Registrace bezpilotních systémů - test 54
https://dron.notia.cz/ Registrace bezpilotních systémů - test 1
https://dtm.jmk.cz/auth/realms/JMK DTM-JMK 53
https://dtm.kraj-lbc.cz/auth/realms/LBC DTM-LBC 32
https://dtm.kr-karlovarsky.cz/auth/realms/KVK DTM-KVK 14
https://dtm.zlinskykraj.cz/auth/realms/ZLK DTM-ZLK 134
https://dvbtform.ctu.cz/ Český telekomunikační úřad - DVBT Form 264
https://eagri.cz/ssl/app/eagriapp/OOS/Uvod.aspx Elektronický přenos dat s Odborem osiv a sadby ÚKZÚZ 11
https://eagri.cz/ssl/app/rmext/ Registr množitelských porostů 39
https://eagri.cz/ssl/app/rvext/ Registr vinic 23
https://eagritest.cz/ssl/app/rmext/ https://eagritest.cz/ssl/app/rmext/ 1
https://edoklady.gov.cz/auth eDoklady 409036
https://eforms.zpmvcr.cz/eforms/ekomunikace E-Komunikace ZP MV ČR 1
https://eforms.zpmvcr.cz/eforms/ekomunikace/niasaml E-Komunikace ZP MV ČR 23916
https://e-health-auth.bnzlin.cz/signin-e-identity Krajská nemocnice T. Bati, a. s. 13
https://e-health-auth.ftn.cz/signin-e-identity Fakultní Thomayerova nemocnice 16
https://e-health-auth.hospital-bn.cz/signin-e-identity Nemocnice Rudolfa a Stefanie Benešov, a.s., nemocnice Středočeského kraje 34
https://e-health-auth.msk.cz/signin-e-identity Portál pacienta Moravskoslezského kraje 3336
https://e-health-auth.nemocnicepribram.cz/signin-e-identity Oblastní nemocnice Příbram, .a.s. 119
https://e-health-auth.nudz.cz/signin-e-identity Portál pacienta 131
https://e-health-auth.pnvd.cz/signin-e-identity Psychiatrická nemocnice v Dobřanech 5
https://e-health-auth.uhkt.cz/signin-e-identity Ústav hematologie a krevní transfuze 6
https://e-health-auth.unbr.cz/signin-e-identity Úrazová nemocnice v Brně 45
https://elektronicky.trest.cz/gordic/ginis/app/rap05/ Město Třešť 45
https://elisportal.mpo.cz/elisportal/nia/overeni ELIS EPODATELNA 5
https://ems.mestys-svitavka.cz/Gordic/RAP05.test/ https://ems.mestys-svitavka.cz/Gordic/RAP05.test/ 1
https://ems.mestys-svitavka.cz/Gordic/RAP05/ Městys Svitávka 83
https://ems.mestys-svitavka.cz:8443/Gordic/RAP05/ https://ems.mestys-svitavka.cz:8443/Gordic/RAP05/ 1
https://epacient.fnkv.cz/ eHealth Portál Fakultní nemocnice Královské Vinohrady 5
https://epo.plzen.eu/irj/portal/anonymous/login Statutární město Plzeň 1445
https://eportal.archirepo.com/ https://eportal.archirepo.com/ 1
https://eportal.cssz.cz/ikr-cas ePortál ČSSZ 1015992
https://eportal.mo.gov.cz/auth/realms/eportal/broker/eidas-saml/endpoint ePortál Ministerstva obrany České republiky TEST 1
https://eportal.pardubice.eu/gordic/ginis/app/RAP05 eportal.pardubice.eu 1604
https://eportal.rumburk.cz/portal Město Rumburk 36
https://eportal.statistika.cz Centrální autentizační bod ČSÚ 9
https://ereg.ksrzis.cz/ Ústav zdravotnických informací a statistiky ČR 14317
https://esfcr.cz https://esfcr.cz 5
https://esluzby.ckrumlov.cz/portal/ Město Český Krumlov 157
https://eurad.mestock.cz/ Město Červený Kostelec 5
https://flexi.bucovice.cz/portal/ Město Bučovice 116
https://frs.gov.cz/api/ip/saml2/authenticate/nia https://frs.gov.cz/api/ip/saml2/authenticate/nia 1
https://ginis.mu-lostice.cz/Gordic/Ginis/App/RAP05/ Město Loštice 67
https://gordic.muchropyne.cz Chropyně 77
https://hades.uhk.cz/nia/ UHK eCŽV přihláška 5
https://hlksehealthportal.azurewebsites.net/home/home HLKS eHealth Portál TEST 4
https://iam.env.cz Ministerstvo životního prostředí 15431
https://identity.semily.cz:8184/ Portál občana 149
https://iiptp.metodickecentrum.cz Metodické centrum 259
https://iiptpt.metodickecentrum.cz Metodické centrum - test 10
https://insis.vse.cz/ VŠE Praha – studijní systém 557
https://is.cuni.cz/studium/index.php Univerzita Karlova SDG SIS 766
https://is.czu.cz/ ČZU v Praze - studijní systém 154
https://is.jamu.cz/ Janáčkova akademie múzických umění 5
https://is.mendelu.cz MENDELU Brno - Univerzitní informační systém 378
https://is.muni.cz/ Masarykova univerzita 11490
https://is.slu.cz Informační systém Slezské univerzity (IS SU) 5
https://is.vstecb.cz/ Vysoká škola technická a ekonomická v Českých Budějovicích 3
https://isdtm.olkraj.cz/auth/realms/OLK DTM - OLK 6
https://isdv.upv.cz/webapp/webapp.nia.niareg https://isdv.upv.cz/webapp/webapp.nia.niareg 3250
https://isdv.upv.gov.cz/webapp/webapp.nia.niareg Úřad průmyslového vlastnictví 2190
https://isdvakc.upv.cz/webapp/webapp.nia.niareg https://isdvakc.upv.cz/webapp/webapp.nia.niareg 10
https://isdvakc.upv.gov.cz/webapp/webapp.nia.niareg AKC - ÚPV 10
https://isdvtst.int.upv.cz/webapp/webapp.nia.niareg TST - ÚPV 7
https://iskp21.mssf.cz/ ISKP21+ 25745
https://iskp21.mssf.cz/sd/ ISKP21+ -údaje 20469
https://iskp21-ref.mssf.cz/ ISKP21+ Ref 12
https://iskp21-sandbox.mssf.cz/ https://iskp21-sandbox.mssf.cz/ 2
https://iskp21-test.mssf.cz/ ISKP21+ Test 403
https://iskp21-test.mssf.cz/sd/ ISKP21+ -test údaje 31
https://is-stag.osu.cz/nia/shibboleth is-stag.osu.cz 357
https://istp.mdcr.cz/Logon.aspx Informační systém technických prohlídek 7459
https://jaas.justice.cz/ Justiční autentizační a autorizační služba 25935
https://jaaspreauth.justice.cz/ Justiční autentizační a autorizační služba 1
https://jck.krajdtm.cz/auth/realms/JCK DTM-JCK 46
https://jenda.mpsv.cz/ https://jenda.mpsv.cz/ 584860
https://khk.krajdtm.cz/auth/realms/KHK DTM-KHK 26
https://kissos.pardubickykraj.cz/sp/shibboleth KISSOS Dotační portál 2
https://kko-nia.mkcr.bootiq-preview.eu/private KKO-TEST 3
https://klient.fnol.cz/ Fakultní nemocnice Olomouc – eHealth portál 108
https://kp.vozp.cz Vojenská zdravotní pojišťovna České republiky 14271
https://lektor.metodickecentrum.cz Metodické centrum (lektor) 171
https://lektort.metodickecentrum.cz Metodické centrum - test (lektor) 8
https://lime.sazka.cz/bank-business-card/saml/SSO SAZKA a.s. 8078
https://lime.uat.sazka.cz/bank-business-card/saml/SSO SAZKA a.s. UAT 2
https://login.cmi.cz/auth/realms/CMI_Portaly ČMI Portály 1
https://login.cuzk.cz/nia/ ČÚZK - přihlašovací portál 509180
https://login.vspj.cz IS VŠPJ 72
https://modurad.otevrenamesta.cz/mutabor/nia info.mutabor.cz 169
https://moje.cak.cz/admin-moje-cak/ ČAK 8
https://moje.test2.kdpcr.cz/ Moje KDP ČR - Test2 5
https://mojeid.cz/nia/client mojeID 13876
https://moje-kdp.dimov-pc.ldock.dev.feo.cz/ Moje KDP ČR - Dev/MD/PC 1
https://monitoringtrhu.ctu.cz/ Český telekomunikační úřad - ESD 2085
https://moodle.mssf.cz/auth/saml2/sp/metadata.php Moodle MS2021+ 2
https://moodle-test.mssf.cz/auth/saml2/sp/metadata.php Moodle MS2021+ Test 3
https://msk.krajdtm.cz/auth/realms/MSK DTM-MSK 48
https://mytocz.eu/selfcare/ Ředitelství silnic a dálnic ČR, Doručovací adresa: Čerčanská 12, CZ-14000 PRAHA 19736
https://nadmery.mdcr.cz IS NADR 851
https://nahlizeni.nsa.gov.cz/ Národní sportovní agentura 3
https://nahlizeni.uohs.cz/Gordic/Ginis/App/RAP05/ https://nahlizeni.uohs.cz/Gordic/Ginis/App/RAP05/ 381
https://nahlizeni.uohs.gov.cz/Gordic/Ginis/App/RAP05/ Úřad pro ochranu hospodářské soutěže 182
https://nahlizeni.uohs.gov.cz/Gordic/Ginis/App/RAP07/ Úřad pro ochranu hospodářské soutěže 4
https://ncp.nixzd.cz NÁRODNÍ KONTAKTNÍ BOD PRO PŘESHRANIČNÍ VÝMĚNU ZDRAVOTNÍ DOKUMENTACE 7
https://nia.eidentita.cz/sep1/secure/ https://nia.eidentita.cz/sep1/secure/ 81
https://nia.eidentita.cz/sep2/secure/ https://nia.eidentita.cz/sep2/secure/ 15
https://nia.eidentita.cz/sep3/secure/ https://nia.eidentita.cz/sep3/secure/ 133
https://nia.eidentita.cz/sep4/secure/ https://nia.eidentita.cz/sep4/secure/ 9
https://nia.eidentita.cz/sep5/ https://nia.eidentita.cz/sep5/ 10
https://nia.eidentita.cz/sep6/ https://nia.eidentita.cz/sep6/ 4
https://nia.identitaobcana.cz/sep1/secure/ SeP 1 32
https://nia.identitaobcana.cz/sep2/secure/ SeP 2 2
https://nia.identitaobcana.cz/sep3/secure/ SeP 3 24
https://nia.identitaobcana.cz/sep4/secure/ SeP 4 4
https://nia.identitaobcana.cz/sep5/ SeP 5 9
https://nia.sukl.cz/login Externí identity - NIA 1185
https://nia.upol.cz/ UPOL NIA API 166
https://niatest.scio.cz/ws-callback Scio 10
https://niatest.vfn.cz/ https://niatest.vfn.cz/ 6
https://nsaweb.ssw.cz/app Národní sportovní agentura 16
https://obcan.benesov-city.cz/ Město Benešov 1537
https://obcan.bilovec.cz/portal/ Město Bílovec 60
https://obcan.bilovicens.cz/obcan/ PO Bílovice nad Svitavou 146
https://obcan.bohumin.cz Portál občana Bohumín 760
https://obcan.bystricenp.cz/Gordic/Ginis/App/RAP05/ Město Bystřice nad Pernštejnem 101
https://obcan.jaromer-josefov.cz/obcan PO Jaroměř 41
https://obcan.kraliky.eu/obcan/ PO Králíky 44
https://obcan.kravare.cz/portal Portál Města Kravaře 75
https://obcan.litomerice.cz/obcan PO Litoměřice 840
https://obcan.mestolysa.cz/obcan LYSÁ NAD LABEM - PORTÁL OBČANA MĚSTA LYSÁ NAD LABEM 354
https://obcan.mesto-nymburk.cz/obcan/ PO Nymburk 367
https://obcan.mesto-uh.cz/portal/ Portál občana Uherské Hradiště 604
https://obcan.mnhradiste.cz/obcan MNICHOVO HRADIŠTĚ - PORTÁL OBČANA MĚSTA MNICHOVO HRADIŠTĚ 276
https://obcan.mubruntal.cz/portal/ BRUNTÁL - PORTÁL OBČANA MĚSTA BRUNTÁL 397
https://obcan.mupe.cz/obcan Město Pelhřimov 452
https://obcan.mutabor.cz/ Město Tábor 1397
https://obcan.novy-bor.cz/ PO Nový Bor 107
https://obcan.otrokovice.cz Identity 101
https://obcan.portal.gov.cz/auth Portál občana 1209672
https://obcan.rajecjestrebi.cz/Gordic/Ginis/App/RAP05/ Město Rájec-Jestřebí 83
https://obcan.ricany.cz/obcan PO Říčany 1030
https://obcan.suchdol.cz/obcan/ PO Suchdol na Lužnicí 11
https://obcan.zdarns.cz Portál občana 371
https://obcan.zidlochovice.cz/obcan/ Portál občana Města Židlochovice 77
https://obcan-stage.portal.gov.cz/auth Portál veřejné správy - Stage 281
https://ocko.uzis.cz/ Ústav zdravotnických informací a statistiky ČR 923860
https://oidc.kraslice.cz/id/ PO Kraslice 55
https://oidc.mag-ul.cz/id/ Statutární město Ústí nad Labem 687
https://oidc-tst.kraslice.cz/id/ https://oidc-tst.kraslice.cz/id/ 1
https://online.nkcr.cz/nia/login Notářská komora České republiky 179
https://onlinescitani.cz/#/ Sčítání lidu, domů a bytů 2021 94120
https://oslavice.cz/nia-formular OBEC OSLAVICE 18
https://osu.zpspraha.cz/id/ Osobní stránky uživatele ZPS 29331
https://pacient.erecept.sukl.cz/suklerp/Pacient https://pacient.erecept.sukl.cz/suklerp/Pacient 43332
https://pacient.erecept.sukl.cz/suklweb/Pacient/Home eRecept - pacientská aplikace 106950
https://pacient.nmbbrno.cz/ Nemocnice Milosrdných bratří, příspěvková organizace 12
https://pacient.vfn.cz Všeobecná fakultní nemocnice - rezervace léků 469
https://pak.krajdtm.cz/auth/realms/PAK DTM-PAK 43
https://pardubice.chytrejsiparking.cz Pardubice - parkovací systém 1877
https://parking.masterit.cz/pardubice Pardubice - parkovací systém 4
https://parkovani.jihlava.cz Statutární město Jihlava 1359
https://pavlinov.cz/nia-formular Obec Pavlínov 11
https://pct22007.b2clogin.com/pct22007.onmicrosoft.com/B2C_1A_TrustFrameworkBase https://pct22007.b2clogin.com/pct22007.onmicrosoft.com/B2C_1A_TrustFrameworkBase 1
https://pisek.mestopodpalcem.cz/api/sep/ MPP Písek 33
https://podatelna.msk.cz/rap05/ ePodatelna Moravskoslezského kraje 2988
https://portal.baska.cz Obec Baška 1
https://portal.baska.cz/ Obec Baška 36
https://portal.baska.cz/portal https://portal.baska.cz/portal 3
https://portal.bilina.cz Portál občana 379
https://portal.brusperk-mesto.cz/ Městský úřad Brušperk 2
https://portal.bystriceph.cz Město Bystřice pod Hostýnem 5
https://portal.caa.cz Portál úřadu pro civilní letectví 563
https://portal.chotebor.cz/portal/ CHOTĚBOŘ - PORTÁL OBČANA MĚSTA CHOTĚBOŘ 386
https://portal.chrustenice.cz/ Obec Chrustenice 58
https://portal.ckrumlov.cz/portal/ https://portal.ckrumlov.cz/portal/ 2
https://portal.cpzp.cz/app Česká průmyslová zdravotní pojišťovna 17719
https://portal.cvikov.cz/ Portál občana Cvikov 3
https://portal.dacice.cz/portal/ Město Dačice 262
https://portal.drnholec.eu/ OSP Městys Drnholec 19
https://portal.dron.caa.cz https://portal.dron.caa.cz 11883
https://portal.dron.notia.com https://portal.dron.notia.com 5
https://portal.fulnek.cz/portal/ Portál občana města Fulnek 203
https://portal.holesov.cz/portal HOLEŠOV - PORTÁL OBČANA MĚSTA HOLEŠOV 149
https://portal.homolka.cz/NiaLogin Nemocnice na Homolce 155
https://portal.horskelazne.cz/home/home HLKS eHealth Portál 7
https://portal.hosteradice.cz/ Osobní Portál Občana Hostěradice 28
https://portal.hukvaldy.eu/ Obec Hukvaldy 7
https://portal.hulin.cz/portal Město Hulín 149
https://portal.hustopece.cz Město Hustopeče 289
https://portal.jilove.cz/ Město Jílové u Prahy 105
https://portal.jirkov.cz/portal Město Jirkov 313
https://portal.kojetin.cz/portal/ Město Kojetín 92
https://portal.koprivnice.cz/portal Město Kopřivnice 500
https://portal.kozlovice.cz/ Obec Kozlovice 98
https://portal.letohrad.eu/portal/ Letohrad - Portál občana města Letohrad 761
https://portal.liberec.cz/id Statutární město Liberec 3699
https://portal.liberec.cz/id/ Statutární město Liberec 3
https://portal.libina.cz/ Obec Libina 37
https://portal.litovel.eu/ Město Litovel 179
https://portal.litvinov.cz/id/ Město Litvínov 593
https://portal.ludgerovice.cz/ Obec Ludgeřovice 34
https://portal.mbudejovice.cz/ Město Moravské Budějovice 218
https://portal.mesto-albrechtice.cz/ Město Albrechtice 48
https://portal.mestobystrice.cz/ Město Bystřice 333
https://portal.mestocernosice.cz/ MĚSTO ČERNOŠICE 1107
https://portal.mesto-domazlice.cz/portal Portál občana města Domažlice 7
https://portal.mesto-humpolec.cz/portal/ Město Humpolec 201
https://portal.mestokladno.cz/id/ Portál občana SMK 3362
https://portal.mesto-kunovice.cz/portal/ Město Kunovice 89
https://portal.mesto-podebrady.cz/obcan PO Poděbrady 270
https://portal.mesto-slavicin.cz/ Slavičín 13
https://portal.mesto-studenka.cz/ Město Studénka 373
https://portal.mesto-studenka.cz/rap05 Město Studénka 3
https://portal.mesto-vlasim.cz/portal/ Město Vlašim 12
https://portal.mestovsetin.cz/portal/ Město Vsetín 413
https://portal.mesto-zruc.cz/ Město Zruč nad Sázavou 24
https://portal.meucaslav.cz/portal/ Město Čáslav 103
https://portal.mezibori.cz/ OSP Portál Meziboří 5
https://portal.mmdecin.cz/portal/ statutární město Děčín 169
https://portal.mmhk.cz HRADEC KRÁLOVÉ - PORTÁL OBČANA MĚSTA HRADEC KRÁLOVÉ 2698
https://portal.mmkv.cz/gordic/ginis/app/rap05/ Magistrát Města Karlovy Vary - Portál občana 745
https://portal.mnisek.cz/portal/ Město Mníšek pod Brdy 248
https://portal.msk.cz/ IDM Moravskoslezský kraj 222
https://portal.mu-bridlicna.cz/ Město Břidličná 36
https://portal.mucl.cz/portal/ Město Česká Lípa 644
https://portal.muhodonin.cz/Gordic/Ginis/App/RAP05/ Město Hodonín 401
https://portal.muhodonin.cz/rap05/ https://portal.muhodonin.cz/rap05/ 5
https://portal.mujicin.cz/ město Jičín 375
https://portal.mukolin.cz/portal/ Město Kolín 1575
https://portal.mukrnov.cz/portal/ Město Krnov 671
https://portal.mu-vk.cz/Gordic/Ginis/App/RAP05/ Město Valašské Klobouky 31
https://portal.muvrchlabi.cz:4433/portal/ Město Vrchlabí 496
https://portal.nemcl.cz Nemocnice s Poliklinikou Česká Lípa,a.s. – eHealth portál 3
https://portal.nemkyj.cz/ Nemocnice Kyjov, příspěvková organizace – eHealth portál – PROD 10
https://portal.novybydzov.cz/portal/ Město Nový Bydžov 150
https://portal.novyjicin.cz/portal/ Portál občana města Nový Jičín 255
https://portal.obec-ostravice.cz/ Obec Ostravice 111
https://portal.ochrance.cz/nia Portal Ochrance 1759
https://portal.olomouc.eu/id/ Statutární město Olomouc - Portál Olomoučana 5526
https://portal.opava-city.cz Portál občana města Opavy 4401
https://portal.palkovice.cz/ Obec Palkovice 214
https://portal.podborany.net:444/portal/ Portál občana Podobořany 69
https://portal.prestice-mesto.cz Město Přeštice 249
https://portal.pribor-mesto.cz/portal/ Město Příbor 260
https://portal.roudnicenl.cz/ Město Roudnice nad Labem 42
https://portal.ruda.cz/ Obec Ruda nad Moravou 45
https://portal.rychnov-city.cz/portal/ Město Rychnov nad Kněžnou 4
https://portal.rychvald.cz/portal Město Rychvald 344
https://portal.rymarov.cz/portal Město Rýmařov 183
https://portal.sfpi.cz Státní fond podpory investic 851
https://portal.slapanice.cz/portal/ Město Šlapanice 253
https://portal.slavkov.cz/portal/ Město Slavkov u Brna 112
https://portal.sternberk.eu Město Šternberk 117
https://portal.steti.cz/ Město Štětí - portál občana 202
https://portal.stramberk.cz/portal/ Portál občana města Štramberk 111
https://portal.svetlahora.cz/ Světlá Hora 7
https://portal.svitavy.cz/portal/ Město Svitavy - portál občana 223
https://portal.telc.eu/ Město Telč 174
https://portal.tesin.cz/portal Město Český Těšín 183
https://portal.trebic.cz/portal Město Třebíč 749
https://portal.trinecko.cz/portal Portál občana města Třince 195
https://portal.trutnov.cz/ Město Trutnov OSP 12
https://portal.uhostroh.cz Portál Uherský Ostroh 3
https://portal.ujep.cz/nia/shibboleth Univerzita Jana Evangelisty Purkyně v Ústí nad Labem 812
https://portal.upce.cz/nia/shibboleth IS/STAG 621
https://portal.varnsdorf.cz/ Portál občana Varnsdorf 23
https://portal.velkemezirici.cz/portal/ Město Velké Meziříčí 361
https://portal.veseli.cz/ Město Veselí nad Lužnicí 289
https://portal.vinarskyfond.cz Vinařský fond 154
https://portal.vratimov.cz Město Vratimov 44
https://portal.vrbnopp.cz/ Město Vrbno pod Pradědem 167
https://portal.zcu.cz/nia/shibboleth IS/STAG ZČU 367
https://portal.zlin.eu/obcan PO Zlín 727
https://portal.zpspraha.cz/id/ Zóny placeného stání - Praha 52784
https://portal1-test.wps.vsb.cz/cz.vsb.edison.edu.admission.web/nia Elektronická přihláška (test 2 - vývoj) 2
https://portal-auth.eambulance.cz/signin-e-identity eAmbulance 2990
https://portal-auth.krajprozdravi.cz/signin-e-identity Portál krajprozdravi 130
https://portal-auth.kzcr.eu/signin-e-identity Portál pacienta Ústeckého kraje 453
https://portal-auth.ncpeh.cz/signin-e-identity Portál NCPeH 460
https://portal-auth.nem-km.cz/signin-e-identity Kroměřížská nemocnice a.s. 20
https://portal-auth.nemocnice-vs.cz/signin-e-identity Vsetínská nemocnice a.s. 11
https://portal-auth.nemuh.cz/signin-e-identity Uherskohradišťská nemocnice a.s. 5
https://portal-auth.upmd.cz/signin-e-identity Ústav pro péči o matku a dítě 8
https://portal-auth.vfn.cz/signin-e-identity Všeobecná fakultní nemocnice v Praze - Portál pacienta 5
https://portal-auth-ppt.ncpeh.cz/signin-e-identity Portál NCPeH - PPT 376
https://portal-auth-test.nemocnice-vs.cz/signin-e-identity Vsetínská nemocnice a.s. 1
https://portal-caa.notia.com Portál úřadu pro civilní letectví - test 18
https://portaldopravy.cz/auth Portál Dopravy 333010
https://portaldron.caa.cz Portál provozovatele bezpilotních systémů 1878
https://portalmostecana.cz/portal/ Statutární město Most - Magistrát města Mostu 1393
https://portalobcana.cheb.cz/gordic/ginis/app/rap05/ Město Cheb - Portál občana 404
https://portalobcana.chomutov.cz/id/ Portál občana 2085
https://portalobcana.horovice.net/gordic/ginis/app/RAP05/ Město Hořovice - Portál občana 12
https://portalobcana.jihlava.cz/portal/ Statutární město Jihlava 1462
https://portalobcana.karvina.cz/portal/ Statutární město Karviná 1197
https://portalobcana.mestokralupy.cz/RAP05/ Město Kralupy nad Vltavou 276
https://portalobcana.meulovo.cz/id/ Portál občana Lovosice 2814
https://portalobcana.meuslany.cz/portal/ Portál občana Město Slaný 12
https://portalobcana.mikulov.cz/portal Mikulov - Portál občana města Mikulova 576
https://portal-obcana.morberoun.cz Moravský Beroun 52
https://portalobcana.muas.cz/portal/ Portál občana města Aš 403
https://portalobcana.muberoun.cz/id/ Portál občana města Beroun 470
https://portalobcana.mulouny.cz/ Město louny 81
https://portalobcana.muor.cz Město Orlová 734
https://portalobcana.muor.cz/ Město Orlová 1
https://portalobcana.muor.cz/portal https://portalobcana.muor.cz/portal 1
https://portalobcana.olomouc.eu/id Statutární město Olomouc 7
https://portalobcana.petrvald-mesto.cz/ Město Petřvald 26
https://portalobcana.praha13.cz ÚMČ Praha 13 336
https://portalobcana.praha3.cz/id/ Městská část Praha 3 4
https://portalobcana.praha5.cz MČ Praha 5 2165
https://portalobcana.pribram.eu/id/ Město Příbram 1463
https://portalobcana.ssgh.cz/ Střední škola gastronomická a hotelová s.r.o. 2
https://portalobcana.veseli-nad-moravou.cz/Gordic/Ginis/App/RAP05 město Veselí nad Moravou 2555
https://portalobcana.vodnany.eu/gordic/ginis/app/rap05/ Město Vodňany - Portál občana 6
https://portalpacienta.bulovka.cz/ eHealth Portál Fakultní nemocnice Bulovka 95
https://portalpacienta.fnhk.cz/ FAKULTNÍ NEMOCNICE HRADEC KRÁLOVÉ – PORTÁL PACIENTA 581
https://portal-pacienta.msk.cz/signin-e-identity https://portal-pacienta.msk.cz/signin-e-identity 1
https://portaltest.nacr.cz Národní archiv test 56
https://portal-test-auth.nem-km.cz/signin-e-identity Kroměřížská nemocnice a.s. 7
https://portal-test-auth.nemuh.cz/signin-e-identity Uherskohradišťská nemocnice a.s. (test) 5
https://portal-test-auth.vfn.cz/signin-e-identity Všeobecná fakultní nemocnice v Praze - TEST Portál pacienta 1
https://portal-ts-auth.eambulance.cz/signin-e-identity eAmbulance TS 25
https://posoh.brno.cz/gordic/ginis/app/rap05/ MMB Gordic POSOH 7987
https://prihlaska.amu.cz/apps/kos/prihlaska/ Přihláška ke studiu na Akademii múzických umění v Praze 44
https://prihlaska.amu.cz/apps/kos/prihlaska/wpr_stip_pg.main AMU - Žádosti o stipendium 5
https://prihlaska.cvut.cz/apps/kos/prihlaska/ Přihláška ČVUT 594
https://prihlaska.cvut.cz/apps/kos/prihlaska/wpr_stip_pg.main ČVUT - Žádosti o stipendium 5
https://prihlaska.utb.cz/muj-profil Univerzita Tomáše Bati ve Zlíně 110
https://prihlaska.vsb.cz/cz.vsb.edison.edu.admission.web/nia Elektronická přihláška 405
https://pristupy.sukl.cz/login Externí identity - Portál 12556
https://prod.frs.gov.cz/api/ip/saml2/authenticate/nia IP-PROD (FRS.GOV.CZ) 4
https://prod.portaldopravy.cz/auth https://prod.portaldopravy.cz/auth 9
https://prodpristupy8.iniba.eu/login Externí identity - Portál - Referenční 23
https://pssd.sporicidluhopisycr.cz/pssd-war/login DLUHOPIS REPUBLIKY 52650
https://psz.pardubickykraj.cz/Gordic/Ginis/App/RAP05/ GINIS Dotační portál 442
https://pz.kraj-jihocesky.gov.cz/gordic/ginis/app/rap05/ Jihočeký kraj - Portál občana 2879
https://rap.blansko.cz/gordic/ginis/app/rap05.test město Blansko - test 3
https://rap.blansko.cz/Gordic/Ginis/App/RAP05/ město Blansko 913
https://rap.olkraj.cz/gordic/ginis/app/RAP05/ RAP - OLK 166
https://rap.prostejov.eu Statutární město Prostějov 4
https://rap.prostejov.eu/ Statutární město Prostějov 1057
https://rap.sumperk.cz/ Šumperk 697
https://ref.api.vvz.nipez.cz/vvz-nia/ Věstník veřejných zakázek - ref 48
https://ref-login.cuzk.cz/nia/ ČÚZK - přihlašovací portál (REF - TEST) 8
https://registrace.mzcr.cz/detail Ministerstvo zdravotnictví 43542
https://registrace.mzcr.cz/Registration Ministerstvo zdravotnictví 4897
https://registrace.uzis.cz/detail https://registrace.uzis.cz/detail 2
https://rejstriksportu.cz/app Národní sportovní agentura 2995
https://rest-webauthenticationapplication.caais.gov.cz/ CAAIS 127
https://ros.caa.cz Žádost o ověření spolehlivosti 11080
https://ros.notia.cz Žádost o ověření spolehlivosti - test 8
https://samotestovani.uzis.cz/ Ústav zdravotnických informací a statistiky ČR 777
https://sd21.mssf.cz/ SD21+ 9142
https://sd21-ref.mssf.cz/ SD21+ Ref 5
https://sd21-sandbox.mssf.cz/ https://sd21-sandbox.mssf.cz/ 2
https://sd21-test.mssf.cz/ SD21+Test 121
https://sdg.cuni.cz/saml2/service-provider-metadata/NIA Univerzita Karlova SDG 5
https://sdg.vscht.cz/saml2/service-provider-metadata/NIA Vysoká škola chemicko-technologická v Praze - SDG 14
https://sdt.nipez.cz/csm_nen_external?id=homepage_nia CSD NIPEZ 13
https://sep.ustrcr.cz/ABS/Meta eBadatelna Archivu bezpečnostních složek 3430
https://sista.tacr.cz/idm/api/v1/nia/login TAČR SISTA 1397
https://skoleni-istp.mdcr.cz/Logon.aspx Informační systém technických prohlídek - ŠKOLÍCÍ 1243
https://sluzby.alis.cz/cejc Obec Čejč 16
https://sluzby.alis.cz/ckyne obec Čkyně 34
https://sluzby.alis.cz/hrusice Obec Hrusice 72
https://sluzby.alis.cz/kamenicky-senov Město Kamenický Šenov 303
https://sluzby.alis.cz/ledenice/ Městys Ledenice 2
https://sluzby.alis.cz/ludvikovice Obec Ludvíkovice 19
https://sluzby.alis.cz/mestobechyne Město Bechyně 325
https://sluzby.alis.cz/mestozliv Město Zliv 339
https://sluzby.alis.cz/mlade-buky Městys Mladé Buky 152
https://sluzby.alis.cz/mukarov Obec Mukařov 600
https://sluzby.alis.cz/obecdoubravice Obec Doubravice 14
https://sluzby.alis.cz/obechermanicky Obec Heřmaničky 62
https://sluzby.alis.cz/obecrimov Obec Římov 42
https://sluzby.alis.cz/obec-roudne Obec Roudné 50
https://sluzby.alis.cz/obecstarehodejovice Obec Staré Hodějovice 54
https://sluzby.alis.cz/rokytnice-nad-jizerou Město Rokytnice nad Jizerou 95
https://sluzby.alis.cz/ronov-nad-doubravou Město Ronov nad Doubravou 8
https://sluzby.alis.cz/rtyne Město Rtyně v Podkrkonoší 168
https://sluzby.alis.cz/sardice Obec Šardice 17
https://sluzby.alis.cz/usti usti 9
https://sluzby.alis.cz/zs-panskapole Svazková základní škola Panská pole 1
https://sluzby.alis.cz/zubri Město Zubří 12
https://sluzby.breclav.eu/portal/ Město Břeclav 98
https://sluzby.muznojmo.cz/Portal/ Znojmo - Portál občana města Znojma 1724
https://sportal.odolenavoda.cz/portal VERA portál občana sml2 419
https://sps.portaldopravy.cz/zadost-191/ Státní plavební správa 522
https://sps.test.portaldopravy.cz/zadost-191/ https://sps.test.portaldopravy.cz/zadost-191/ 6
https://ssl.boskovice.cz/Gordic/Ginis/App/RAP05/ Město Boskovice 366
https://sso.esfcr.cz/cas/login IS ESF 463
https://sso.plzensky-kraj.cz Plzeňský kraj 127
https://stag.tul.cz/nia/shibboleth stag.tul.cz 621
https://stag.uhk.cz/nia/shibboleth IS/STAG 298
https://stag.utb.cz/nia/shibboleth Univerzita Tomáše Bati ve Zlíně 3
https://stag-avu.zcu.cz/nia/shibboleth stag-avu.zcu.cz 25
https://stag-demo.uhk.cz/nia/shibboleth IS/STAG TEST 2
https://stag-demo.utb.cz/nia/shibboleth Univerzita Tomáše Bati ve Zlíně 1
https://stag-demo.zcu.cz/nia/shibboleth IS/STAG 5
https://stage.portaldopravy.cz/auth Portál Dopravy - STAGE 49
https://stagweb.vfu.cz/nia/shibboleth stagweb.vfu.cz 119
https://studium.vsb.cz/financovani/nia Žádost o financování studia 6
https://sujb.gov.cz/aplikace/ireg2/irp/am/#/private/vyber-aplikace sujb.gov.cz 91
https://testag.msk.cz/authgate/pages/user.xhtml Identitní brána MSK – vývoj 97
https://test-pacient.vfn.cz VFN TEST pacient 7
https://tnc.ssw.cz/nsa Národní sportovní agentura 40
https://tsm-eru-portal.datalite.cloud/ ERÚ test - portál 10
https://tsm-portal.eru.cz/ https://tsm-portal.eru.cz/ 24
https://tsm-portal-dev.eru.cz/ Datový portál ERÚ - DEV 10
https://udeska.olkraj.cz/Gordic/Ginis/App/RAP05.test/ RAP_test 7
https://udeska.olkraj.cz/Gordic/Ginis/App/RAP05/ Olomoucký kraj 1331
https://usk.krajdtm.cz/auth/realms/USK DTM-USK 29
https://utilityreport.eu/ UtilityReport 188
https://utilityreport.eu/PN/ UtilityReport - Plzeňský kraj 76
https://utilityreport.eu/VN/ UtilityReport 105
https://verejnost.cbusbs.cz/cas Český báňský úřad 237
https://verso.sukl.cz/shibboleth Verso 133
https://vns.doarmady.cz Virtuální Náborové Středisko 3224
https://vns.doarmady.cz/ Virtuální Náborové Středisko 2
https://vouchery.kreativnicesko.cz/private KKO 5410
https://vps2.rsts.cz/cibis-sale/eidas Raiffeisen stavební spořitelna 2
https://vtk-test.ozp.cz/vkol https://vtk-test.ozp.cz/vkol 6
https://vuapraha.cz/badatelna/api/prihlaseni/nia Ministerstvo obrany České republiky 792
https://vys.krajdtm.cz/auth/realms/VYS DTM-VYS 169
https://web.mpsv.cz/cas https://web.mpsv.cz/cas 237
https://webservices.sumperk.cz/webservices/zapis Zápis Šumperk 1
https://webservices.sumperk.cz/webservices/zapis/ Zápis Šumperk 1
https://wstag.jcu.cz/nia/shibboleth IS/STAG 766
https://wstag-test.jcu.cz/nia/shibboleth IS/STAG - test 1
https://www.1zdar.cz/nia-formular Základní škola Žďár nad Sázavou, Palachova 2189/35, příspěvková organizace 1
https://www.3zsvm.cz/nia-formular Základní škola Velké Meziříčí, Školní 2055, příspěvková organizace 2
https://www.ak-vych.cz AK Vych & Partners 2
https://www.chyne.cz/ucet Obec Chýně 450
https://www.ctu.cz https://www.ctu.cz 12
https://www.ctu.cz/ https://www.ctu.cz/ 16
https://www.czechpoint.cz/ JIP Czech POINT 8967
https://www.horniradslavice.cz/nia-formular Obec Horní Radslavice 7
https://www.kzmpribyslav.cz/mia-formular Město Přibyslav 4
https://www.martinice.eu/nia-formular Obec Martinice 9
https://www.mateda.cz Mateda, a.s. 7
https://www.mojedatovaschranka.cz/portal/ISDS/ Informační systém datových schránek 1146702
https://www.mpsv.cz/cas Klientský portál MPSV 395121
https://www.msbites.cz/nia-formular Mateřská škola Velká Bíteš, U Stadionu 538, příspěvková organizace 5
https://www.msbudisovtr.cz/nia-formular Mateřská škola Budišov 3
https://www.msmerin.cz/nia-formular Mateřská škola Měřín, příspěvková organizace 12
https://www.msostrovno.cz/nia-formular Mateřská škola Ostrov nad Oslavou, okres Žďár nad Sázavou, příspěvková organizace 6
https://www.nabidkamajetku.cz/Login.ashx Úřad pro zastupování státu ve věcech majetkových 6186
https://www.naevia.cz Naevia Estate s.r.o. 3
https://www.obecbabice.eu/nia-formular Obec Babice 2
https://www.obeccerna.cz/nia-formular Obec Černá 12
https://www.obec-dobravoda.cz/nia-formular Dobrá Voda 23
https://www.obecruda.eu/nia-formular Obec Ruda 7
https://www.obec-tasov.cz/nia-formular Obec Tasov 6
https://www.obec-uncin.cz/nia-formular Obec Unčín 7
https://www.obec-zablati.cz/nia-formular Obec Záblatí 1
https://www.orechov-ronov.cz/nia-formular Obec Ořechov 20
https://www.ozp.cz/auth/realms/ozp https://www.ozp.cz/auth/realms/ozp 9224
https://www.ozp.cz/prod2vtk/vkol ICIS Vitakarta 12465
https://www.paropisek.cz/appsep.php PaRo Písek 377
https://www.portalprazana.cz/auth Portál Pražana 32703
https://www.postsignum.cz/certifikatonline/ Česká pošta, s.p. 3401
https://www.radnoves.cz/nia-formular Obec Radňoves 1
https://www.rapotice.cz/nia-formular Obec Rapotice 7
https://www.rejstriksportu.cz/app https://www.rejstriksportu.cz/app 3
https://www.roklen.cz Roklen360 a.s. 12
https://www.rzp.cz/niaeis Ministerstvo průmyslu a obchodu 62217
https://www.skolaradostinno.cz/nia-formular Základní škola a Mateřská škola Radostín nad Oslavou, příspěvková organizace 5
https://www.skola-ruda.cz/nia-formular Základní škola a mateřská škola Ruda, příspěvková organizace 6
https://www.slavicky.cz/nia-formular Obec Slavičky 1
https://www.sujb.cz/aplikace/ireg2/irp/am/#/private/vyber-aplikace Portál elektronických podání SÚJB 107
https://www.svetlavm.cz/nia-formular Hotelová škola Světlá a Střední odborná škola řemesel Velké Meziříčí 16
https://www.uradfm.cz/portal Portál občana Frýdek-Místek 2791
https://www.uradfm.cz/portal/ Portál občana Frýdek-Místek 1
https://www.vidonin.cz/nia-formular Obec Vidonín 1
https://www.vlkov.cz/nia-formular Obec Vlkov 14
https://www.vut.cz IS VUT - ePřihláška 5
https://www.vut.cz/eprihlaska IS VUT - ePřihláška 185
https://www.zadnizhorec.cz/nia-formular Obec Zadní Zhořec 7
https://www.zdirec.cz/nia-formular Město Ždírec nad Doubravou 21
https://www.zsdolnihermanice.cz/nia-formular Základní škola a Mateřská škola Dolní Heřmanice, příspěvková organizace 2
https://www.zsmerin.cz/nia-formular ZŠ Měřín 13
https://www.zsmostiste.cz/nia-formular Základní škola a mateřská škola Velké Meziříčí, Mostiště 50, příspěvková organizace 7
https://www.zsoslavice.cz/nia-formular Základní škola Oslavice 4
https://www.zsostrovno.cz/nia-formular Základní škola Ostrov nad Oslavou, příspěvková organizace 1
https://www.zssokolovska.cz/nia-formular Základní škola Velké Meziříčí, Sokolovská 470/13 2
https://www.zsvaclav.cz/nia-formular Základní škola Třebíč, Horka-Domky, Václavské nám. 44/12 3
https://www.zusvm.cz/nia-formular Základní umělecká škola Velké Meziříčí, příspěvková organizace 16
https://www-test.ozp.cz/auth/realms/ozp https://www-test.ozp.cz/auth/realms/ozp 11
https://www-test.ozp.cz/vkol ICIS - VITAKARTA - TEST 5
https://zadosti.sfzp.cz/AISPortal/NIA/overeni Státní fond životního prostředí České republiky 245204
urn:mep:demoportal MEP Test Portal 1
urn:moris:adu ADU 2073
urn:moris:eidasproxyservice eIDAS ProxyService 7415
urn:moris:ocisteniidp NIA Overeni Meg 829
urn:moris:overovaciportal Ověřovací portál 4404
urn:moris:portal Portál Národního bodu (NIA Portál) 1068185
urn:moris:portal:mep:proofing Portál Národního bodu - Identity MEP proofing IDP 24350
urn:moris:portal4 Portál Národního bodu - Identity proofing IDP 129987

Seznam poskytovatelů služeb (Service Provider; SeP)

Poskytovatelů služeb je již více než 50 a v přípravě jsou další. Konečný počet je v řádu stovek. Aktuální seznam je dostupný zde https://info.identitaobcana.cz/sep/.

Podobně jako jsou jiné státy v rámci eIDAS povinni přijímat české ohlášené prostředky identity (eObčanka), jsou čeští poskytovatelé služeb povinni akceptovat identitu ohlášenou jiným státem v rámci eIDAS. Povinnost umožnit přihlášení pomocí IIG - International Identity Gateway je všem poskytovatelům služeb zapnuta od 30.6.2020. Současné znění nařízení eIDAS, povinuje členské státy, které oznámily systém elektronické identifikace, aby zajistily jedinečnou identifikaci osoby.

Nicméně je vhodné na tomto místě upozornit, že pomocí údajů obdržených na základě využití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace, nemusí být vždy možné udělat jednoznačný „identity matching“ – tj. jednoznačné ztotožnění osoby, která se přihlašuje pomocí „zahraničního“ prostředku pro elektronickou identifikaci s údaji, které vede poskytovatel online služeb. Pro účely „identity matchingu“ by pak mohl posloužit také údaj(či údaje), který by musel zadat sám uživatel. Nejlépe samozřejmě údaj, který by měl být znám ze své podstaty pouze samotnému uživateli. Výše uvedené vychází z předpokladu spolehnutí se na základní osobní údaje obdržené na základě využití prostředku pro elektronickou identifikaci a na údaj (či údaje), které doplní sám uživatel. Seznam dostupných atributů u jednotlivých ohlášených systému elektronické identifikace je k dispozici na: https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+available+attributes+of+pre-notified+and+notified+eID+schemes.

Atributy vydávané poskytovatelům služeb (Service Providerům; SeP)

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

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

Při použití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace se množina osobních údajů (v případě fyzických osob) skládá minimálně z následujících údajů:

  • příjmení,
  • jméno,
  • datum narození a
  • unikátního identifikátoru (pseudonymu).

Seznam dostupných atributů u jednotlivých ohlášených systému elektronické identifikace je k dispozici na: https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+available+attributes+of+pre-notified+and+notified+eID+schemes.

Při použití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace nicméně není možné využít služby základních registrů E226 eidentitaCtiAifo pro překlad pseudonymu na AIFO dané agendy.

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

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

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

Nevizuální přihlašování z mobilních aplikací

Principem tzv. nevizuálního přihlašování je uspořádání, kdy konkrétní instance aplikace daného uživatele byla jednorázově zaregistrována v Národním bodu (NIA), prostřednictvím klasického vizuálního přihlášení. Pro běžné použití této aplikace pak stačí ověření uživatele při vstupu do této mobilní aplikace (typicky otisk prstu, fotografie obličeje, nebo PIN). Jakmile se uživatel dostane do mobilní aplikace a ta zjistí, že od posledního přihlášení k NIA uběhla více než určitá doba (vývojářům aplikace je doporučeno dodržovat hodnotu 24 hodin), provede aplikace automatické přihlášení daného uživatele k NIA a to způsobem, který nevyžaduje žádnou jeho interakci. Tímto způsobem se mobilní aplikace dozví o možné změně údajů daného uživatele, ke které mezitím v ROB mohlo dojít, například změna příjemní atp. Uživatel má dále možnost vyhledat si v konfiguraci NIA seznam, zobrazující které mobilní aplikace má připojené v režimu nevizuálního přihlašování a z jakého zařízení. V případě potřeby (například ztráty svého mobilního telefonu) je pak možno v tomto seznamu konkrétní aplikaci odpojit. Aby se tento fakt mobilní aplikace dozvěděla a uvedla sama sebe do nezaregistrovaného stavu, je mobilní aplikace povinna v pravidelných intervalech volat příslušnou službu. Doporučená hodnota periodicity tohoto volání je vývojářům mobilní aplikace doporučena v úrovni 60 minut.

NIA poskytuje soubor rozhraní, které mají za cíl umožnit poskytovatelům služeb (SeP) vytvoření takových vlastních mobilních aplikací a vlastních backendových API, které dohromady budou umět ověřit identitu občana prostřednictvím volání webových služeb, tedy nevizuálně bez interakce občana.

Původně generická Mobilní aplikace bude muset být uživatelem nejprve registrována k užívání a následně bude umožňovat opakované přihlašování k NIA nevizuálním způsobem. Mobilní aplikace bude předávat informaci o provedeném přihlášení do API poskytovatele služeb, které následně z NIA získá JSON Web Token s detaily o přihlášeném uživateli. Fakt registrace bude opakovaně kontrolován na NIA prostřednictvím procesů mobilní aplikace a API, aby uživatel mohl např. při ztrátě zařízení možnosti nevizuálního přihlašování zabránit.

Cílem funkcionality není, aby mobilní aplikace poskytovatele služeb byla na úrovni poskytovatele identity (není to Identity provider). Není ji tedy možné používat pro přihlašování k portálům a jiným službám ostatních poskytovatelů služeb.

Více viz popis na stránkách SZR ČR.

Pravidla pro Národní identitní autoritu

Zásadním požadavkem bezpečnosti a transparentnosti pro informační systémy veřejné správy je požadavek na jednotnou elektronickou identifikaci externích uživatelů. Pro každou operaci je nutná znalost osoby, která tuto operaci provádí zvláště z hlediska nepopiratelné zodpovědnosti osoby. Externí uživatelé (klienti) informačních systémů veřejné správy musí být jednoznačně identifikováni zvláště z důvodů ochrany osobních údajů a dále z procesního hlediska, jak předpokládá správní řád (jednoznačné prokázání totožnosti účastníků řízení).

Úloha správy přístupů se pro každý informační systém veřejné správy skládá z následujících kroků:

  • Identifikace – jednoznačné a nepopiratelné určení fyzické osoby, která přistupuje k informačnímu systému veřejné správy
  • Autentizace – prokázání, že přistupující osoba je tou osobou, za kterou se vydává. Autentizace probíhá předložením autentizačních prostředků (například uživatelské jméno a heslo, autentizační certifikát), které osobě přidělil správce informačního systému
  • Autorizace – na základě údajů o identifikované a autentizované osobě a dalších údajů o této osobě (například zařazení na pracovní pozici) zařazení osoby do odpovídající role a z toho vyplývající vyhodnocení oprávnění na úkony a data v rámci informačního systému.

NAP v této oblasti vyžaduje naplnění následujících principů pro všechny informační systémy veřejné správy:

  1. Každý úřad, který poskytuje své služby elektronicky, potřebuje svého klienta ověřit (ztotožnit) s využitím kvalifikovaného systému elektronické identifikace, jehož služby jsou poskytovány Národní identitní autoritě. Ověření totožnosti vyžaduje právní předpis nebo výkon působnosti.
  2. Pro využití Národní identitní autority se musí organizace stát tzv. kvalifikovaným poskytovatelem služeb (Service provider; SeP), dle postupu popsaném níže.
  3. Každý úřad musí akceptovat nejen identitu českého občana, ale kteréhokoliv občana Evropské Unie dle eIDAS.
  4. Jakýkoliv nový identitní prostor musí být budován tak, aby byl federovaný v rámci Národní identitní autority.
    1. Před tvorbou nového identitního prostoru je potřeba si prvně udělat analýzu, zda nepostačuje některý z federovaných identitních prostředků v rámci Národní identitní autority.
  5. Prostředky pro identifikaci a autentizaci jsou vždy vydány bezpečnou a jednoznačnou cestou identifikované osobě tak, aby byla zajištěna minimální úroveň důvěry. O vydání prostředků existuje trvalý záznam spolu s údaji, jak byla ověřena identita osoby.
  6. Osoba, jíž byly prostředky vydány, zachází s prostředkem s náležitou péčí tak , aby nedošlo k jeho zneužití či odcizení.
  7. Osoba, jíž byly prostředky vydány, nese nedílnou zodpovědnost za všechny úkony, které byly v informačním systému provedeny při použití těchto prostředků.
  8. Věcný správce agend, které jsou vykonávány v rámci informačního systému, zodpovídá za obsazení osob do rolí (technicky vykonává technický správce informačního systému, vždy však na základě podkladů věcných správců). Tuto svoji zodpovědnost může delegovat v rámci organizační struktury na více zodpovědných osob.

Postup ohlášení kvalifikovaného poskytovatele služby (Service provider; SeP)

Následující kroky popisují jednotlivé části procesu, který je naznačen níže, na základě ověření přes ISDS. Aktuálně je registrace organizace prostřednictvím portálu národního bodu přístupná pouze pro orgány veřejné moci, ostatní subjekty musí provést registraci přímo u Správy základních registrů (viz krok 8). Kompletní příručka je dostupná zde.

  1. Uživatel jako zástupce organizace požaduje po portálu národního bodu, který je Service Providerem, službu umožňující registraci dané organizace. Tato registrace umožní fungování dané organizace v NIA a vytváření jednotlivých Service Providerů.
  2. Portál národního bodu kontaktuje Národní identitní autoritu, která ověření zprostředkovává, s požadavkem na ověření dané osoby (uživatele).
  3. Pro ověření uživatele pro registraci organizace či konfigurací jednotlivých Service Providerů je jako Identity Provider určen Informační systém datových schránek (ISDS). Národní identitní autorita provede přesměrování na přihlášení prostřednictvím datových schránek.
  4. Uživatel provede ověření vlastní osoby přihlášením k datovým schránkám. Aby mohl uživatel registrovat organizaci na portálu národního bodu, musí být přihlášen prostřednictvím ISDS (v definované roli a typem schránky OVM). V případě, že organizace není OVM, je potřeba provést registraci u Správy základních registrů.
  5. V případě, kdy je uživatel úspěšně ověřen, Informační systém datových schránek předá Národní identitní autoritě jako výsledek ověření autentizační token obsahující IČO a název subjektu, roli přihlašovaného uživatele a další atributy.
  6. Národní identitní autorita provede sběr atributů v Informačním systému základních registrů (ISZR) na jehož základě následně provede kontrolu existence IČO.
  7. Národní identitní autorita předává portálu národního bodu potřebné atributy z Informačního systému základních registrů a atributy přijaté v autentizačním tokenu z Informačního systému datových schránek, které jsou nutné ke zpracování formuláře pro registraci.
  8. Na základě úspěšného splnění předchozích kroků umožní portál národního bodu uživateli službu registrace organizace (SeP) a zobrazí mu vyplněný formulář pro registraci. Toto platí pouze pro organizace, které jsou OVM. Není-li organizace OVM, jsou místo registračního formuláře zobrazeny podrobné informace o tom, jakým způsobem provést registraci přímo u Správy základních registrů.
  9. Uživatel potvrdí správnost údajů a provedení registrace organizace (SeP).
  10. Portál národního bodu zpracuje přijatý požadavek na registraci a po úspěšném zaregistrování umožní uživateli provést konfiguraci jednotlivých Service Providerů spadající pod danou organizaci (seznam konfigurací kvalifikovaných poskytovatelů).
  11. Uživatel provede konfiguraci Service Providera zahrnující následující údaje:
    • IČO subjektu
    • Název kvalifikovaného poskytovatele
    • Popis kvalifikovaného poskytovatele
    • URL adresa odkazující na úvodní webové stránky kvalifikovaného poskytovatele
    • URL adresa pro odeslání požadavků
    • Adresa pro příjem vydaného tokenu
    • URL adresa, na kterou bude uživatel přesměrován při odhlášení z Vašeho webu
    • Načtení certifikátu
    • Adresa pro načtení veřejné části šifrovacího certifikátu z metadat
    • Zpřístupnění autentizace prostřednictvím brány eIDAS
    • Logo kvalifikovaného poskytovatele
Příklad pro poskytovatele zdravotních služeb

Poskytovatel zdravotních služeb není orgán veřejné moci, a proto je třeba zajistit kromě výše uvedeného postupu i následující kroky:

  1. Požádat Ministerstvo zdravotnictví o zavedení do registru práv a povinností jako SPUÚ dle povinností vyplývající ze zákonů č. 250/2017 Sb. a č. 372/2011 Sb., ideálně pod agendou A1086
  2. Na adrese https://www.identitaobcana.cz/Home/Ovm se přihlásit jako oprávněný uživatel datovou schránkou poskytovatele zdravotních služeb
    • Nově by se mělo nabídnout ruční zadání údajů s dalším postupem
    • Pokud se neobjeví, postupovat dle obecných bodů výše – poslání datové zprávy obsahující potřebné údaje (URL, logo….)
  3. Upravit si svůj profil na https://www.identitaobcana.cz/Home/Ovm pro přístup jiných osob (IT oddělení např.) a správu svého profilu, konfigurovat pro Portál pacienta poskytovatele zdravotních služeb.

Podmínky pro nevizuální přihlašování

Přihlašování z mobilních aplikací je založeno na následujících předpokladech:

Poskytovatel služby musí

  • vytvořit svoji mobilní aplikaci
  • vytvořit svoje API
  • zabezpečit komunikace mezi svým API a mobilní aplikaci
  • provést registraci svého API a mobilní aplikace v NIA
  • definovat a zaregistrovat sadu atributů, které budou obsahem JWT (JSON Web Token)
  • zajistit komunikaci mezi API a NIA pro vyzvedávání JWT

NIA poskytuje

  • rozhraní pro interaktivní přihlášení
  • rozhraní pro registraci mobilní aplikace
  • rozhraní pro přihlášení mobilní aplikace
  • rozhraní pro API, které si z NIA vyzvedne JWT

Uživatel

  • musí mít platný a funkční profil NIA a musí mít k dispozici, alespoň jeden platný přihlašovací prostředek, např. mobilní klíč eGovernmentu anebo bankovní identitu,
  • nainstaluje si mobilní aplikaci od poskytovatele služby,
  • po prvním spuštění aplikace provede interaktivní přihlášení přes NIA, které zajistí registraci aplikace v NIA,
  • podle potřeby bude opakovat interaktivní přihlášení z aplikace, pokud z nějakého důvodu bude registrace v NIA zrušena/zneplatněna (změna konfigurace SePa anebo každých 6 měsíců).

Po registraci mobilní aplikace může provést přihlášení k NIA. Výsledkem přihlášení je tzv. access token, který mobilní aplikace předá komponentě (API) poskytovatele služeb. Tato komponenta (API) následně zavolá definované rozhraní NIA, kde předá access token a své přihlašovací údaje. Na základě tohoto volání NAI provede vydání JWT.

Pravidla určení úrovně záruky pro poskytované služby (LoA)

Každý poskytovatel služby si sám určuje, jakou úroveň záruky (LoA) po uživateli vyžaduje25)), pokud neexistuje právní předpis, který by výslovně stanovoval úroveň záruky. Ideální stav je, že toto určení je provedeno pro každou jednotlivou službu, která se na portále poskytuje. Protože se však typicky uživatel předem nehlásí k jedné jednotlivé službě, ale k portálu jakožto agregaci více služeb, má poskytovatel služeb následující možnost:

  1. Nastaví úroveň záruky podle nejčastěji využívaných služeb nebo dle nejčetnější úrovně záruky u nabízených služeb. Tato možnost zajistí, že uživateli bude po autentizaci dostupná většina služeb a zároveň se po uživateli nepožaduje prostředek s vysokou úrovní záruky. Pokud však uživatel chce využít služby s vyšší úrovní záruky, než použil při původní autentizaci, měl by být uživatel vyzván k autentizaci prostředkem s vyšší úrovní záruky.
  2. Nenastaví žádnou vstupní úroveň záruky. Tato možnost zajistí, že se uživatel autentizuje na daný portál jakýmkoliv identitním prostředkem NIA a až následně se při výběru služby uživatelem kontroluje, zda je pro ni splněna minimální úroveň záruky. Pokud není, měl by být uživatel vyzván k autentizaci prostředkem s vyšší úrovní záruky.
  3. Potřebnou úroveň záruky nastaví podle nejpřísnější služby. Tato možnost zajistí, že uživatel bude moci vždy využít všechny služby, které jsou na portále dostupné k vyřízení. Nevýhodou je, že se po uživateli může vyžadovat zbytečně vysoká úroveň záruky, kterou nemusí disponovat prostředky, které vlastní.

Pro jakoukoliv zvolenou variantu z pohledu poskytovatele služeb však platí několik povinností:

  1. Požadovaná úroveň záruky u jednotlivých služeb odpovídá informacím uvedených v katalogu služeb a v případném právním předpise, který výslovně stanovuje úroveň záruky.
  2. Uživateli autentizovaném s nižší úrovní záruky se neskrývá nabídka služeb vyžadující vyšší úroveň záruky.

Podstatné otázky a odpovědi na využívání NIA

Otázky týkající se Centrálního registru životního prostředí

Otázky týkající se přihlašování uživatelů do systémů Centrální registr životního prostředí, potažmo Integrovaného systému ohlašovacích povinností. Předání proběhlo přípisy Ministerstva životního prostředí:

  1. ze dne 19. ledna 2024, sp. zn. ZN/MZP/2024/280/6, odpověď DIA byla poskytnuta pod sp. zn. DIA- 2188-2/OPL-2024
  2. ze dne 21. listopadu 2023, sp. zn. MZP/2023/110/787, odpověď DIA byla poskytnuta pod sp. zn. DIA- 16244-2/OHA-2023
Žádám o doložení právního předpisu nebo o doložení faktu, že výkon působnosti vyžaduje prokázání totožnosti fyzické osoby. Zákon č. 250/2017 Sb., §2 říká, že pokud je nutné prokázání totožnosti, lze to pouze prostřednictvím kvalifikovaného systému. Neříká však, že ISPOP má právo vyžadovat identifikaci fyzické osoby. Roční hlášení je prováděno za právnickou osobu, nikoli za fyzickou.

Jak je vysvětleno výše, pokud agendový zákon neomezí způsob činit podání, je nutné se řídit obecnou úpravou podání uvedenou ve správním řádu, která je pro elektronické podání upravena zejména v ZoPDS a dalších speciálních předpisech. Informační systém veřejné správy je pouze jednou z možností, jak činit podání vůči orgánu veřejné správy. Pokud je agendovým zákonem stanoveno, že se podání vůči orgánu veřejné správy činí prostřednictvím informačního systému veřejné správy dle § 4 odst. (1) písm. d) ZoPDS, je nutné, aby se fyzická osoba, která za povinný subjekt jedná, přihlásila do informačního systému veřejné správy prostřednictvím identity občana, jak ostatně vyplývá také z § 2 ZoEI. V takovém případě pak není nutné podání ani podepisovat, jelikož se uplatní fikce podpisu dle § 8 zákona č. 365/2000 Sb., o informačních systémech veřejné správy.

Identitu občana nemám a nebudu si ji zřizovat, takovou povinnost jako občan nemám, jak se mám nadále přihlašovat?

V případě, kdy agendový zákon omezí způsob činit podání vůči orgánu veřejné správy pouze na elektronickou podobu (a agendový zákona nijak blíže neurčuje závaznou podobu úkonu a jeho podání), je možné úkon činit nejen za použití informačního systému, ale dále též např. prostřednictvím datové schránky či sítě elektronických komunikací za použití uznávaného elektronického podpisu dle §4 odst. (1) ZoPDS. Fyzická osoba jednající jménem PO není povinna si pořizovat identitu občana. Identita občana, resp. elektronická identifikace, je obecně pouze jednou z možností, jak učinit podání vůči orgánům veřejné moci.

Nebudu identitu občana využívat v rámci plnění pracovních povinností. Z jakého důvodu by řadoví zaměstnanci měli používat svoji Identitu občana pro plnění zákonných povinností svého zaměstnavatele? Proč není dostačující současný způsob přihlašování do systémů CRŽP? Proč je zásadní znát totožnost ohlašovatele/zaměstnance právnické osoby při takových úkonech jako je ohlášení produkce odpadů?

Využití identity občana je pouze jednou z možností, jak činit úkony vůči orgánům veřejné správy. Zajištění potřebných nástrojů pro plnění povinností povinného subjektu vyplývajících z agendových zákonů by mělo být primárně povinností konkrétního subjektu, na který plnění zákonných povinností dopadá. Pokud zaměstnanci povinného subjektu odmítají využívat či si pořídit identitu občana, měl by jim subjekt, za který mají jednat, umožnit užití datové schránky či zprostředkovat vydání certifikátu pro uznávaný elektronický podpis.

Pokud si propojím Identitu občana ke svému účtu v ISPOP, jak to pak funguje ohledně pokut atp.? Nemůže se stát, že firma bude po mě vymáhat zaplacení pokuty nebo nějakého poplatku, kterou obdrží, na základě podaného hlášení, když tam teď bude moje identita? Předtím to byl účet firemní a bral jsem to jako hlášení za firmu, teď to bude hlášení s mojí identitou.

Odpovědnost fyzické osoby (FO) za digitální úkony činěné v zastoupení právnické osoby (PO) je shodná, jako v případě úkonů činěných v listinné, nedigitální formě. Pokud FO činí úkon vůči orgánu veřejné moci svým jménem, ale v zastoupení a při plnění povinnosti stanovené PO, tak její odpovědnost za toto právní jednání není neomezená, ale odvíjí se od právního titulu, kterým je FO oprávněna za PO jednat. Ať už se jedná například o jednatele uvedeného v Obchodním rejstříku, zaměstnance pověřeného k určitým úkolům nebo zmocněnce na základě plné moci, odvíjí se odpovědnost této FO od konkrétního právního titulu a způsobené škody.

Do SEPNO ohlašuji automatizovaně ze SW přes účet, který jsme si zřídili jako systémový (tzn. pro komunikaci systém-systém), vztahuje se povinnost i na tyto účty? Lze i nadále využívat přihlašování přes Jméno + Heslo + 2. faktor?

Není-li nutné prokazovat totožnost, tak není povinnost využívat identitu občana. Komunikace mezi systémy nevyžaduje prokazování totožnosti, ovšem když je potřeba například zřídit danou komunikaci (vystavení či evidence systémového certifikátu) je nutné tuto službu obsloužit s prokázanou totožností, a tedy i využitím identity občana.

Jakým způsobem je zajištěna bezpečnost úniku dat z identity občana, může zaměstnavatel přikázat zaměstnancům, ať poskytnou svoje osobní údaje? Nedojde tím k porušení zákona GDPR?

Při přihlášení do informačního systému veřejné správy za použití identity občana uživatele přesměruje na Národní bod pro identifikaci a autentizaci (NIA), kde jsou popsány předávané osobní údaje, způsob jejich předání, důvod jejich zpracování, a osoba je vyzvána k udělení trvalého nebo jednorázového souhlasu s jejich zpracováním. Toto řešení je v souladu s právními předpisy upravujícími zpracování osobních údajů. Více informací k této věci konec konců uvádí i MŽP v dokumentu k CRŽP dostupném na tomto odkazu.

Dle jakého konkrétního ustanovení právního předpisu je dovozována povinnost užívat Identity občana, popř. Bankovní identitu k přihlašování do systému ISPOP?

Pokud jde o předmětné ustanovení § 2 zákona č. 250/2017 Sb., o elektronické identifikaci, platí, že „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 (dále jen „kvalifikovaný systém“).“ Elektronickou identifikací se podle čl. 3 odst. 1 Nařízení Evropského parlamentu a Rady č. 910/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 (nařízen eIDAS) rozumí mj. postup používání osobních identifikačních údajů v elektronické podobě, které jedinečně identifikují fyzickou osobu zastupující právnickou osobu.

Ministerstvo životního prostředí, jak sám uvádíte, je správcem obou zmíněných informačních systémů veřejné správy, správa zmíněných informačních systémů je tedy součástí výkonu jeho působnosti. Ke správě informačních systémů veřejné správy nepochybně patří též řízení přístupu k informačním systémům, které probíhá mj. požadavkem na prokázání totožnosti osob, které k těmto informačním systémům přistupují. Prokázání totožnosti je tedy vyžadováno v rámci výkonu působnosti Ministerstva životního prostředí jakožto orgánu veřejné moci a není nutné, aby bylo uvedeno v právním předpisu explicitně. Postup zjišťování totožnosti v rámci přístupu ke zmíněným informačním systémům odpovídá výše uvedené definici elektronické identifikace uvedené v nařízen eIDAS, toto nařízení zároveň počítá s tím, že svou totožnost prokazuje fyzická osoba mj. při zastupování právnické osoby.

Shrnuji, že pokud požadavek na prokázání totožnosti vyplývá z výkonu působnosti a je činěn s využitím elektronické identifikace, lze jej umožnit pouze prostřednictvím kvalifikovaného systému elektronické identifikace (označovaný též jako NIA, identita občana, atd.), nikoliv jiným způsobem, jak uvádí závěrečná část výše zmíněného zákonného ustanovení.

S ohledem na uvedené považuje Digitální a informační agentura postup Ministerstva životního prostředí za souladný s právní předpisy upravujícími elektronickou identifikaci.

Z jakého důvodu není při přihlašování zaměstnance postupováno stejně jako v případě přihlašování úřední osoby, když se vždy rovněž jedná de facto o zaměstnance?

Pokud jde o jednání při zastupování právnické osoby, je vhodné zmínit, že pokud jde fyzické prokazování totožnosti při jednání za právnickou osobu, je používání fyzických dokladů, které nepochybně nejsou vydány jen pro jednání za právnickou osobu, naprosto běžné. Např. pokud jednatel společnosti s ručením omezeným nebo jiný její zástupce jedná vůči orgánu veřejné moci za tuto společnost osobně nebo činí za tuto společnost písemné právní jednání vyžadující úředně ověřený podpis, prokáže vůči orgánu veřejné moci svou totožnost občanským průkazem nebo např. cestovním pasem, nikoliv dokladem vydaným jen pro kontext zastupování právnické osoby. Digitální a informační agentura neshledává používání kvalifikovaných prostředků elektronické identifikace v těchto situacích od používání fyzických dokladů totožnosti zásadně odlišným. V této souvislosti lze pro úplnost poukázat na to, že je rovněž běžné, že osoby, které nejsou statutárními orgány právnické osoby, ale jde o zmocněné zaměstnance či jiné zmocněné osoby, sdělují v rámci svého zastupování právnické osoby řadu osobních údajů, které se následně objevují např. ve sbírce listin obchodního rejstříku, např. datum narození nebo adresu trvalého pobytu takového zmocněnce.

Pokud jde o autentizaci, tedy o spojení totožnosti určité fyzické osoby s jejím oprávněním jednat za právnickou osobu, a s rozsahem tohoto oprávnění, je toto záležitostí nastavení předmětných informačních systémů a legislativy je upravující. Lze v tomto směru odkázat na analogii např. s nastavením přihlašování k informačnímu systému datových schránek, kdy relevantní právní úprava odlišuje osoby mající primární oprávnění přihlašovat se do datové schránky, tj. v případě právnické osoby její statutární orgán nebo členy statutárního orgánu (srov. § 8 odst. 3 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů) od osob majících odvozené oprávnění přihlašovat se do datové schránky, tj. tzv. pověřených osob (srov. § 8 odst. 6 písm. b) zákona o elektronických úkonech a autorizované konverzi dokumentů). Rovněž právní úprava přihlašování k informačním systémům v působnosti orgánů Finanční správy rozlišuje mezi primárně oprávněnými přihlašujícími se osobami a odvozeně oprávněnými přihlašujícími se osobami (zde např. daňový poradce). Používání kvalifikovaných prostředků elektronické identifikace tedy nebrání společnosti ORLEN Unipetrol RPA s.r.o., aby oprávnění k přístupu k předmětným informačním systémům udělovala a odnímala sama.

Pokud jde o vyjádření pověřence pro ochranu osobních údajů Ministerstva životního prostředí, k tomu uvádíme, že přechod z tzv. proprietární (tj. jen pro konkrétní informační systém vytvořené) elektronické identifikace je procesem postupným a nelze tedy vyloučit, že proprietární identifikace je k přístupu k některým informačním systémům stále využívána do doby zavedení přístupu výlučně prostřednictvím kvalifikovaného systému elektronické identifikace. Vyjádření pověřence pro ochranu osobních údajů Ministerstva životního prostředí je tedy vyjádřením popisu praktické implementace již účinné právní úpravy, nikoliv popis právní úpravy účinné v budoucnu.

Pokud jde o důvody, proč není postupováno stejně jako v případě úřední osoby, platí, že autentizační informační systém (JIP/KAAS) podle § 56a zákona č. 111/2009 Sb., o základních registrech, je zřízen pro ztotožnění fyzických osob, které vykonávají činnosti v agendách jako tzv. nositelé rolí. Cílem je nejen řádná autentizace těchto fyzických osob, ale též vedení řádných záznamů o využívání údajů obsažených v informačních systémech veřejné správy, a to až na úroveň konkrétní fyzické osoby, která údaje využila. Na rozdíl od elektronické identifikace určuje konkrétní fyzické osoby jakožto nositelé rolí přímo orgán veřejné moci, tyto údaje se zapisují do základního registru práv a povinností. S ohledem na výše uvedené je JIP/KAAS určen pro ztotožnění úředníků, kteří jménem orgánu veřejné moci jednají, tj. pro státní zaměstnance, zaměstnance nebo jiné osoby v podobném vztahu k orgánu. Pro úplnost dodávám, že právnická osoba nemůže být nositelem role.

Jakým způsobem se bude postupovat, pokud nastane technická porucha na straně provozovatele systému Identity občana popř. Bankovní identity a systém bude nedostupný a proto nebude možno ověřit ohlašovatele a přihlásit se zejména do systému SEPNO, kde je nutno v krátkých časových intervalech provádět ohlášení? Zákon o odpadech řeší v §79 odst. 3 pouze náhradní postup ohlašování přepravy nebezpečných odpadů při přerušení provozu ISPOP. Nedostupnost systému Identity občana popř. Bankovní identity není nikde řešena, Toto ve svém důsledku znemožní odvoz nebezpečných odpadů a způsobí provozovatelům zvýšenou administrativní i finanční zátěž.

Právní úprava postupu pro případy technických poruch není ve vztahu k elektronické identifikaci zavedena, je nicméně vhodné doplnit, že právní úprava postupu pro případy technických poruch není zavedena ve valné většině případů ani např. ve vztahu např. k technické poruše informačních systémů veřejné správy nebo datových schránek a není mi známo, že by úprava postupu pro případy technických poruch byla zavedena ve vztahu k technické poruše dosud používaných identifikačních nástrojů vůči informačním systémům zmíněným v přípisu. Právní úprava počítá s tím, že tyto nástroje budou dostupné. V případě potřeby je možné využít zmírňujících institutů podle příslušných právních předpisů, v tomto doporučujeme konzultaci s Ministerstvem životního prostředí. Upozorňuje, že v případě využití prostředku elektronické identifikace, jejichž vydavatelem je banka (tzv. bankovní identita nebo bankID), může nastat technická porucha též na straně konkrétní vydávající banky.

Jak bude řešeno neohlášení ve smyslu odmítání požadovaného přihlášení za právnickou osobu prostřednictvím individuálních možností fyzické osoby dle výše uvedených argumentací?

V tomto doporučujeme konzultaci s Ministerstvem životního prostředí.

I.CA

Garant: I.CA

Úroveň záruky: Vysoká

Popis: Čipová karta Starcos 3.5 a vyšší s komerčním identitním certifikátem je stejně jako občanské průkazy vydávané od 1. 7. 2018 nástrojem, kterým se prostřednictvím NIA prokazuje, že přihlašující se uživatel je skutečně tím, za koho se vydává.

Čipová karta Starcos od výrobce Giesecke&Devrient je v České republice poskytována společností První certifikační autorita a. s. (I.CA), a to především jako nástroj pro splnění některých požadavků nařízení eIDAS.

Ve spojení s komerčním identitním certifikátem splňuje požadavky na kvalifikovaný prostředek pro elektronickou identifikaci.

Z hlediska uživatele je proces získání identitního certifikátu jednoduchý – je obdobný, jako při vydání kvalifikovaného certifikátu pro elektronický podpis s uložením soukromého klíče v bezpečném hardwarovém prostředku, tj. čipové kartě nebo tokenu. Stejně tak je jednoduché jeho používání. Certifikáty vydávají tytéž registrační autority I.CA, které vydávají i jiné typy certifikátů a kterých je v ČR více než 30. Jejich aktuální seznam je na webových stránkách I.CA.

Zájemci mají možnost zvolit využití čipu pro uložení

  • komerčního identitního certifikátu pro elektronickou identifikaci
  • komerčního identitního certifikátu pro elektronickou identifikaci a kvalifikovaného certifikátu pro elektronický podpis (produkt Identitní TWINS, tj. TWINS pro elektronickou identifikaci).

U varianty TWINS je výhodou vydání obou certifikátů na základě jedné žádosti a jednoho ověření totožnosti žadatele.

Čipová karta Starcos je zabezpečena PIN a PUK. Citlivé operace na kartě je možné realizovat vždy pouze po zadání PIN. PUK lze využít v případě zablokování karty pro získání dalších pokusů pro zadání PIN. Při dodávce čipových karet je možné si vybrat ze dvou možných nastavení PIN a PUK:

  • PIN a PUK je generován při personalizaci a je umístěn do tzv. PIN obálky
  • karta není po personalizaci vybavena PIN a PUK a klient je při prvním použití karty požádán o jejich zadání.

Čipová karta Starcos umožňuje:

  • zadat informace o majiteli karty, doplnit identifikační údaje vlastníka karty a fotografii
  • zvolit podporované (důvěryhodné) Certifikační autority, jejichž klientské certifikáty může klient využívat (standardně certifikáty I.CA); jiné klientské certifikáty pak není možné na kartu umístit, čímž se významně omezuje možnost použití karty k nepovoleným operacím.

Čipová karta ve standardní velikosti je určena pro použití se čtečkou čipových karet. Oblíbená je varianta plug-in, tj. s vylamovacím čipem. V tomto případě si klient samostatnou čtečku čipových karet nepořizuje.

Některé z nabízených čteček umožňují kromě připojení k USB portu PC rovněž bezdrátové připojení prostřednictvím Bluetooth.

Využití: V současné době se čipová karta Starcos 3.5 a vyšší s komerčním identitním certifikátem využívá například v systému Zákaznické samoobsluhy systému elektronického mýtného a v Informačním systému technických prohlídek. Stala se také jednou z možností registrace do dotačních programů COVID pro firmy a OSVČ. Samozřejmě je možné použít tento prostředek i pro přihlášení do datové schránky či Portálu občana.

Více informací: I.CA provider, I.CA prostředek.

Bankovní identita

Úroveň záruky: Značná

Popis: Bankovní identita je metoda digitálního ověření v online světě provozovaná bankami. Stejně jednoduše jako se občané přihlašují do svého internetového bankovnictví, se s bankovní identitou mohou identifikovat při vstupu na webové portály se službami státu (eGovernmentu) nebo i do služeb soukromých společností jako jsou eShopy a další portály.

Princip fungování bankovní identity je jednoduchý a bezpečný, prověřený řadou let úspěšného užívání v severských státech a dalších digitálně vyspělých zemích.

Občané si pro využití bankovní identity nemusí nic zřizovat, nikam chodit ani se nic nového učit – většina z nich již totiž svou bankovní identitu u své banky má a aktivně ji používá při přihlašování do svého internetového bankovnictví. Využití bankovní identity je zdarma, v případě jakýchkoli problémů s použitím se občané navíc mohou spolehnout na klientský servis své banky.

Klíčovým prvkem při používání bankovní identity je její bezpečnost, na níž si banky obecně dlouhodobě zakládají, a to nejen z důvodů přísných regulatorních pravidel, ale i za účelem udržení důvěry svých klientů. Díky propracovanému systému vícefaktorového ověření, které je v případě bank naprostým standardem a jehož součástí je dnes zpravidla i biometrická identifikace v rámci mobilní potvrzovací aplikace, zajišťují banky svým klientům při využívání tohoto druhu e-identity maximální možnou bezpečnost.

Každé ověření je provedeno pouze na základě iniciativy a souhlasu občana. Banky uskutečňují pouze identifikaci, tím jejich zapojení končí. To znamená, že banky přihlašovací údaje svých klientů nikomu nepředávají, dále je pečlivě chrání, a samozřejmě ani nevidí, jaké úkony klient následně po úspěšné identifikaci realizuje a na jakém portálu.

Využití: Bankovní identitu je možné využít jako identifikační prostředek, kterým je možné se přihlásit k většině online služeb (agend) státu, které jsou na odpovídající úrovni záruk (značná), jakožto i službám soukromých společností, pokud se tento identifikační prostředek rozhodnou svým klientům nabídnout a implementovat do svých systémů.

Více informací: Bankovní identita, webové stránky jednotlivých českých bank a BankID společnosti Bankovní identita, a.s, zprostředkovávající implementaci tohoto řešení soukromým společnostem pod názvem BankID.

eObčanka

Úroveň záruky: Vysoká

Popis: Občanský průkaz vydávaný od 1. července 2018 (tzv. „eObčanka“) je možné využít pro elektronickou identifikaci a autentizaci, pokud si držitel v okamžiku jeho vyzvednutí na úřadě aktivoval jeho elektronický čip. Aktivaci může provést osoba starší 15 let tím, že na úřadě příslušném k vydávání občanských průkazů zadá identifikační osobní kód (IOK) a deblokační osobní kód (DOK). Pokud chceme využívat všechny vlastnosti eObčanky, je nutné si na svůj počítač, tablet či mobilní telefon naistalovat obslužný software (obsahující aplikace „eObčanka – Identifikace“ a „eObčanka - Správce karty“), který je volně ke stažení na internetové adrese: Info Identita Občana, a mít k němu připojenu příslušnou čtečku čipových karet (tu je potřeba si dokoupit). Čtečka čipových karet by měla splňovat základní parametry – soulad s normou ISO 7816, CCID (Chip Card Interface Device), komunikační standard PC/SC a být kompatibilní s operačním systémem počítače. U mobilních platforem, které většinou nedisponují USB konektorem pro připojení běžné čtečky, je možné použít čtečku s rozhraním Bluetooth, která je o něco dražší, a je potřeba jí samostatně nabíjet.

Občanský průkaz lze použít také pro účely podepisování elektronických dokumentů a dále pro přihlašování do informačních systémů s využitím autentizačních certifikátů. Za tímto účelem je držitel občanského průkazu oprávněn uložit do kontaktního elektronického čipu kvalifikované certifikáty pro elektronické podpisy a autentizační certifikáty. Pokud chce občan využít svoji eObčanku jako úložiště svého elektronického podpisu nebo autentizačních certifikátů, musí nastavit také další přístupové kódy – PIN, QPIN a PUK, jejichž popis a postup nastavení je popsán na Info Identita Občana. Pro účely správy kvalifikovaných certifikátů pro elektronické podpisy, autentizačních certifikátů a změny přístupových kódů, je k dispozici zmiňovaná aplikace "eObčanka – správce karty", která je součástí instalačního balíčku s obslužným softwarem.

Využití: eObčanku s aktivovaným čipem lze použít jako prostředek pro elektronickou identifikaci s vysokou úrovní záruky a rovněž jako úložiště svého elektronického podpisu a autentizačních certifikátů. eObčanka, jako zatím jediný prostředek pro elektronickou identifikaci vydávaný v ČR, je notifikována do EU v souladu s nařízení eIDAS. Tj. občané mohou svoji eObčanku s aktivovaným čipem používat i pro přístup k online službám, které jsou poskytovány jinými členskými státy v EU, při splnění podmínek daných nařízením eIDAS.

Více informací o eObčance je k dispozici na adresách: Info Identita Občana a MVČR

NIA ID

Úroveň záruky: Značná

Popis: Prostředek NIA ID je spjatý s Národním bodem již od jeho počátku v roce 2018 (původně se prostředek jmenoval „jméno, heslo a SMS“). Občané ČR a cizinci vedení v Registru obyvatel a zároveň starší 18 let, si mohou založit prostředek, ať již skrze odkaz pod oknem pro přihlášení tímto prostředkem, či přímo na webové stránce NIA ID. Pro založení prostředku je vyžadováno výhradní vlastnictví emailové adresy a mobilního telefonního čísla pro příjem SMS (přičemž číslo musí mít českou předvolbu +420).

Samotné založení prostředku je prvním krokem do elektronického světa přihlašování k online službám státu. Účet je třeba aktivovat připojením k identitě konkrétní fyzické osoby. Dokud není účet aktivován, tj. navázán na fyzickou osobu, tak je umožněno přihlášení pouze k portálu Národního bodu. Možností, jak navázat identifikační prostředek NIA ID na fyzickou osobu, je několik:

Jakmile je účet aktivní, tak již nic nebrání jej využívat pro přihlašování k elektronickým službám státu.

Využití: NIA ID je možné využít jako identifikační prostředek, kterým je možné se přihlásit ke všem online službám Kvalifikovaných poskytovatelů, které akceptují úroveň značná, což je dnes drtivá většina. Pro použití prostředku není potřeba speciálních zařízení, ale uživatel si vystačí se znalostí přihlašovacích údajů a výhradním vlastnictvím mobilního telefonního čísla, registrovaného v České republice. Tato metoda přihlášení usnadňuje použití NIA ID napříč všemi věkovými kategoriemi obyvatelstva.

Více informací: Info Identita Občana

MojeID

Garant: CZ.NIC

Úroveň záruky: Nízká, značná a vysoká

Popis: Služba mojeID vznikla již v roce 2010 a patří tak k jedné z prvních široce dostupných služeb elektronické identifikace v Česku. V roce 2020 prošla služba mojeID akreditačním procesem na MV ČR. S mojeID je možné se přihlašovat k mnoha službám v ČR, a dokonce také v zahraničí.

Ověřené údaje uživatelů

Již od vzniku služby mojeID byl jednou z jejích hlavních předností důraz na ověřování údajů, které o sobě uživatel uvádí. U všech účtů dochází k ověření e-mailového a telefonického kontaktu. Dobrovolně je pak možné ověřit i korespondenční adresu a jako nejvyšší stupeň ověření je možné provázat účet s registrem obyvatel a díky tomu je možné působit jako identitní prostředek v rámci NIA. V takovém případě lze ověřit totožnost několika způsoby – návštěvou pobočky Czech POINT, systémem datových schránek nebo eObčankou, případně dalšími prostředky elektronické identifikace.

Bezpečnost

Druhým klíčovým znakem služby mojeID je od začátku snaha nabídnout nejmodernější a nejbezpečnější prostředky elektronické identifikace pro vícefaktorové přihlašování. Již krátce po spuštění se objevila možnost využití generátoru jednorázových hesel, následovala vlastní mobilní aplikace pro jednoduché potvrzování jedním kliknutím. V roce 2019 byla do služby mojeID implementována možnost přihlašovat se bezpečnostním klíčem podle standardu FIDO. Technologie FIDO zajišťuje maximální ochranu proti útokům typu MITM (nabourání útočníka do komunikace mezi dvěma účastníky). Pro její použití v nejběžnějších zařízeních, jako jsou ty s operačním systémem Windows 10 nebo Android, není nutné nic dalšího pořizovat a je možné použít bezpečnostní klíč zabudovaný přímo v operačním systému. Bezpečnostní klíč FIDO je možné nahradit nebo doplnit o přihlašování pomocí mobilní aplikace MojeID Klíč, která je k dispozici zdarma pro telefony a tablety využívající systémy Android nebo iOS. Přihlašování je tak nejen maximálně bezpečné, ale zároveň maximálně pohodlné. Pro nejvyšší úroveň záruky je možné použít externí HW klíč s odpovídající certifikací.

Využití: S prostředkem mojeID je možné se přihlašovat nejen ke službám eGovernmentu, ale také do různých elektronických obchodů, zpravodajských portálů, městských knihoven a do mnoha portálů obcí a měst a řady dalších služeb. Přehled smluvních partnerů je k dispozici v katalogu služeb dostupném na mojeID katalog. Účet je také možné použít pro správu domény u některých doménových registrátorů.

Od září 2020 je možné používat účet mojeID také pro přihlašování ke službám veřejné správy. Více informací: mojeID.

Systémové a uživatelské notifikace, hlavní principy a rozdíly

Co to jsou notifikace klientů/uživatelů a notifikace informačního systému, jaké jsou principy jejich realizace a užití, jaký je u nich potenciál centrálních sdílených služeb a způsob užití kontaktních údajů FO?

Klíčové vysvětlované pojmy:

  1. Uživatelská/ klientská notifikace = upozornění pro klienta
  2. Vyrozumění o změně údajů = upozornění jednoho IS jiným na změnu údajů nebo jinou událost

V hantýrce eGovernmentu se pro některé formy komunikace vžilo označení „notifikace“.

Vedle činění vzájemných úkonů poskytovateli a klienty služeb v obslužných kanálech jsou důležitou složkou komunikace státu s klienty (subjekty práva FO i PO) různá osobní upozornění a oznámení, často generovaná automaticky na základě pravidel nebo změny údajů. Tato oznámení jsou i nadále nazývána notifikace, někdy přesněji klientská notifikace.

Stejný pojem notifikace je ale v současnosti používán pro techniku sloužící jako jeden z nástrojů řízení integrace mezi dvěma systémy, kde je závislý (řízený) systém, má-li to ve vedoucím (řídícím) systému nastaveno (předplaceno, abonováno ), upozorňován na nějakou změnu údajů v systému hlavním a může například požádat službou o změněné údaje. V tomto případě se jedná o tzv. systémovou notifikaci. Tento proces bude v rámci propojeného datového fondu ČR nadále nazýván Vyrozumění o změně údajů.

Cílem architektury eGovernmentu je definovat a implementovat centrální sdílené služby pro oba druhy komunikace, pro notifikaci i pro vyrozumění o změně údajů. Pro vyrozumění o změně údajů subjektů (ROB, ROS) a objektů (RUIAN) vedených v základních registrech je doporučeno užívání služeb ISZR. V prostředí ISZR a základních registrů bude vybudována jednotná sdílená služba pro registraci a zasílání vyrozumívání o změně údajů..

Sdílené služby pro notifikace klientům by měly být dostupné ve všech univerzálních, agendových i územních obslužných a komunikačních kanálech, samoobslužných i asistovaných. Architektonická vize eGovernmentu v NAP předpokládá vznik sady centrálních aplikací, podporujících sdílenými službami všechny kanály - hovoříme o komponentách kategorie CRM (Citizen Relationship Management). Jednou z nich by měl být klientský notifikační engine a integrace na jednu nebo několik komunikačních platforem pro každou z forem předávání sdělení (SMS brána, mail-server, IVR, skript kontaktního centra, hybridní pošta, ISDS, apod.).

Klientské notifikace jsou vždy předávány výhradně subjektům práva na základě údajů uložených v základních registrech či v agendách dle zvláštních předpisů.

Kontakty klienta pro předávání klientských notifikací jsou tedy udržovány na více úrovních platnosti, jako centrální v základních registrech a jako lokální v agendových systémech a agendových nebo územních portálech. Centrální kontaktní údaje uložené v Registru obyvatel nebo Registru osob spravuje fyzická osoba prostřednictvím portálu Národního bodu po své identifikaci a autentizaci.

Návrh využití kontaktních údajů centrálními sdílenými službami pro klientské notifikace předpokládá, že pokud zpráva z AIS, volající sdílenou notifikační službu, nese jako parametr vedle sdělení i preferovaný komunikační kanál a kontaktní údaj v něm, má tato lokální preference klienta (nebo poskytovatele služby ) přednost před kontaktními údaji z profilu. Pokud preferovaných kanál a kontakt z lokálního AIS chybí a je přenášeno pouze AIFO a text sdělení, použijí se centrální kontaktní údaje.

Otevřená data

Popis otevřených dat

Otevřená data jsou:

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

Využívání otevřených dat při výkonu veřejné správy

Nejsou stanovené žádné limitace možného použití publikovaných otevřených dat a lze je tedy využít pro libovolné agendové i neagendové činnosti. Publikovaná data jsou zpřístupněna prostřednictvím NKOD a lze je získat jako soubory s datovými sadami. K datům lze také přistupovat s využitím aplikací třetích stran, které příslušné data využívají. Při importu dat do aplikací a informačních systémů veřejné správy by však měl úřad data čerpat primárně z Propojeného datového fondu a Veřejného datového fondu přes referenční rozhraní.

Publikace otevřených dat

Příprava ISVS pro export otevřených dat

Zásadní je zajištění přístupu k datům IS. Provozovaný IS tedy musí:

  • umožňovat přístup k databázi nebo
  • mít možnost stahovat volitelně strukturovaná data (tabulky) z reportingového modulu systému, nebo
  • nabídnout API, ze kterého se dají pravidelně získávat kompletní data v podobě datových souborů.

Vhodné otevřené formáty:

  • tabulková data - CSV, XML, JSON, RDF (JSON-LD, Turtle, …),
  • hierarchická data - XML, JSON, RDF (JSON-LD, Turtle, …),
  • grafová data - RDF (JSON-LD, Turtle, …),
  • geodata(prostorová data) - GeoJSON, ESRI Shapefile, OGC GML, OGC GeoPackage.

Struktura dat musí být zdokumentována lidsky čitelným dokumentem, ale také strojově čitelným schématem. Doporučené jazyky pro definici schémat schémata:

  • CSV - schéma CSV on the Web,
  • XML - XML Schema,
  • JSON - JSON schema,
  • RDF - RDFS, OWL, SHACL

Při dodržení výše uvedených bodů jsou získaná kompletní data z IS připravena k publikaci formou otevřených dat.

Export dat nebo API v proprietárním formátu

Pokud se jedná o rozšíření existujícího IS, který neumožňuje export dat nebo nenabízí API ve strojově čitelném a otevřeném formátu a takovou úpravu nelze v IS provést, využije se stávající export či API, které již systém nabízí (např. do MS Excel), a tento výstup se dále zpracuje do otevřeného formátu pomocí dalších nástrojů tak, aby bylo dosaženo stavu jako v případě přímého exportu do otevřeného formátu.

Závěrečná příprava dat k publikaci v podobě otevřených dat

Data získaná z IS jedním z popsaných způsobů je následně třeba publikovat jako otevřená data. To znamená minimálně:

  1. V případě API zajistit jeho vytěžení pro získání kompletních dat k publikaci (tj. případná přímá publikace API nenaplňuje podmínky otevřených dat)
  2. Zajistit pravidelnou aktualizaci získaných dat (dle charakteru dat to může být ve frekvenci např. denně, měsíčně nebo ročně)
  3. Publikovat získaná data na web ke stažení a následně publikovat každou jejich aktualizaci
  4. Opatřit je dokumentací, podmínkami užití a kontaktem na kurátora
  5. Katalogizovat je v Národním katalogu otevřených dat (NKOD)

K tomu lze využít nástrojů pro přípravu, publikaci a katalogizaci otevřených dat, jako je třeba LinkedPipes ETL. Publikace otevřených dat by měla být zajištěna koncepčně na úrovni celé organizace. Kompletní postupy jsou k dispozici na POD, včetně vyžadovaných standardů.

Pravidla pro otevřená data

Organizační a procesní zajištění publikace dat

Publikující organizace by měla realizovat vhodná organizační opatření, přiřadit pracovníkům příslušné procesní role a implementovat činnosti publikačních procesů do pracovních náplní pracovníků. Jako minimum je vyžadováno přiřazení těchto klíčových procesních rolí:

Koordinátor otevírání dat, do jehož kompetencí a povinností spadá:

  • zajištění součinnosti a kontroly výstupů všech ostatních rolí, které se na otevírání dat podílejí,
  • komunikace se všemi zapojenými pracovníky do publikace dat,
  • externí komunikace s uživateli otevřených dat VS,
  • komunikace a spolupráce s Národním koordinátorem otevřených dat,
  • komunikace s Datovou kanceláří a s příslušným Chief data officer (CDO).

Kurátor dat - klíčová role pro:

  • zajištění kvality, správnosti, aktuálnosti a tím i právní závaznosti dat konkrétní agendy,
  • publikaci datových sad v souladu s platnými právními předpisy ČR a Standardy publikace a katalogizace otevřených dat VS ČR.

Kompletní doporučení, vhodné vzory interních dokumentů, všechny navržené procesní role a standardní publikační procesy jsou uvedeny na Portále otevřených dat a na portále pro poskytovatele.

Ochrana osobních údajů

Pokud jsou předmětem evidence informačního systému osobní údaje ve smyslu zákona č. 110/2019 Sb., o zpracování osobních údajů a nařízení (EU) č. 2016/679, Obecné nařízení o ochraně osobních údajů (GDPR), neznamená to, že nelze ze systému publikovat otevřená data. V těchto případech platí následující doporučení.

  1. V případě, že se jedná o veřejnou evidenci či rejstřík a zvláštní právní předpis nařizuje zveřejnění informací, lze zveřejnit osobní údaje v podobě otevřených dat.
  2. Ochranu osobních údajů lze zajistit Anonymizací či Pseudonymizací. Z dat se odstraní osobní údaje a případně se nahradí bezvýznamovým umělým identifikátorem. Data bez osobních údajů se pak mohou zveřejnit v podobě otevřených dat. V závislosti na charakteru dat je ale nutné zkontrolovat, zda data ve své kombinaci neumožňují identifikaci konkrétní osoby i po odstranění zjevných osobních údajů. Může se jednat o kombinace typu město, věk a pohlaví a podobné.
  3. Data, která není možné nebo vhodné zveřejnit dle předchozího bodu, lze zveřejnit v agregované podobě. Tedy v podobě statistik. V případě zveřejnění statistik je ale žádoucí použít co nejjemnější granularitu dat a časové členění.

Právní aspekty

Legislativní rámec otevřených dat v České republice tvoří jejich úprava obsažená v Zákoně č. 106/1999 Sb., o svobodném přístupu k informacím a v Nařízení vlády č. 425/2016 Sb., o seznamu informací zveřejňovaných jako otevřená data, které stanovuje vybraným orgánům veřejné správy povinnost zveřejňovat data z konkrétních jimi spravovaných informačních systémů ve formě otevřených dat. Podrobnější informace o strategických dokumentech, akčních plánech a souvisejících předpisech ČR i EU jsou k dispozici v aktualizované podobě na stránkách Portálu otevřených dat (POD).

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:

  1. 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
  2. žá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í využívat datovou základnu katalogu služeb a životních situací, jaká je v RPP
  • 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ů:
  • 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í splňovat bezpečnostní požadavky dle minimálního bezpečnostního standardu
  • 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

  • Klienti se identifikují a autentizují s využitím služeb NIA a jsou v portále identifikováni pomocí BSI do doby, než si klient zvolí službu, která je poskytována agendou
  • 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í využívat datovou základnu katalogu služeb a životních situací, jaká je v RPP
  • 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ů:
  • 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í splňovat bezpečnostní požadavky dle minimálního bezpečnostního standardu
  • 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:

  • Klienti se identifikují a autentizují s využitím služeb NIA a jsou v portále identifikováni pomocí BSI do doby, než si klient zvolí službu, která je poskytována agendou
  • 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:

  1. Musí mít zřízenou datovou schránku pro komunikaci s veřejnou správou
    • Právnické osoby mají datovou schránku zřízenou ze zákona
    • Zřídit datovou schránku je možné dle informací na webu České pošty
    • Datová schránka se může obsluhovat skrze webové rozhraní na adrese www.mojedatovaschranka.cz nebo mít funkcionality integrovány do vnitřních systémů organizace. Nejčastěji se jedná o elektronickou spisovou službu.
  2. Musí být ohlášen v rejstříku SPUÚ v registru práv a povinností. Zde je možnost kontroly https://rpp-ais.egon.gov.cz/AISP/verejne/katalog-spuu.
    • Ohlášení do rejstříku SPUÚ probíhá pomocí agendového informačního systému působnostního viz https://rpp-ais.egon.gov.cz/AISP/. Do tohoto systému má přistup každý ohlašovatel agendy.
    • Pokud tedy existuje agenda, v rámci které je SPUÚ oprávněn čerpat údaje ze základních registrů nebo z agendového informačního systému, je třeba kontaktovat správce agendy a požadovat zavedení do rejstříku SPUÚ.
    • Pokud není soukromoprávní uživatel údajů ohlášen v AISP a správce agendy, ani jiné OVM, jej ohlásit nechce, může SPUÚ kontaktovat správce Registru práv a povinností (posta@mvcr.cz) se žádostí o ohlášení do rejstříku SPUÚ s těmito údaji (Název organizace, adresa organizace, IČO, DIČ, zákon a paragraf opravňující k přístupu do základních registrů nebo agendovému informačnímu systému, kontaktní osoba)
  3. Musí být ohlášen jako kvalifikovaný poskytovatel služeb online služeb (dále též Service Provider). Více také zde https://www.eidentita.cz/Home/Ovm. Ohlášení může proběhnout automatizovaně skrze formulář, pokud to umožňuje typ zřízení datové schránky (typ 10, 14, 15, 16). Pokud žadatel tento typ nemá, je nutné kontaktovat Správu základních registrů skrze datovou schránku napřímo s požadavkem obsahujíc všechny údaje, jako v případě automatizovaného způsobu:
    • IČO subjektu
    • Název kvalifikovaného poskytovatele (SeP)
    • Popis kvalifikovaného poskytovatele
    • URL adresa odkazující na úvodní webové strá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
  4. 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!

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

Popis Portálu občana a Portálu veřejné správy

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

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

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

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

Pravidla Portálu občana a Portálu veřejné správy

Portál občana i portál veřejné správy jsou centrálně poskytované a provozované portály. Integrovat, či federovat služby úřadu lze přes vlastní řešení v podobě agendových portálů, portálů území či soukromoprávních uživatelů údajů. Integrace je celkem na 3 stupních:

  1. Proklik na vlastní řešení s využitím Single Sign-On. Obsahuje pouze vlastní prostor na portálu občana, kde úřad zveřejní svou informační dlaždici, skrze kterou se klient dostane, s využitím principu Single Sign-On a zapojení do národního identitního prostoru, na vlastní řešení
  2. Poskytování údajů do vlastního prostoru na portálu občana. Kromě možnosti prokliku na vlastní řešení zapojeného do národního identitního prostoru obsahuje i vždy aktuální údaje o klientovi poskytované skrze propojený datový fond
  3. Kompletní vyřešení služby veřejné správy na portálu občana pomocí formulářového řešení se všemi integracemi v bodech 1 a 2.

Přihlášení k portálu občana

Pro přístup na Portál občana je nutností přihlášení uživatele. Zvolený způsob přihlášení určuje i rozsah služeb, které jsou pro uživatele přístupné. Přihlašovací stránka Portálu občana je dostupná na adrese https://obcan.portal.gov.cz. Přihlášení je možné:

  • prostřednictvím kvalifikovaného systému elektronické identifikace (NIA) v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci, a to s využitím občanského průkazu s elektronickou částí (pouze průkazy vydávané od 1. 7. 2018, nevyžadována registrace) nebo s využitím identifikačního prostředku Jméno, heslo a SMS (nutná registrace), příp. s využitím dalších prostředků identifikace.
  • prostřednictvím autentizačního rozhraní Informačního systému datových schránek v souladu se zákonem č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů. Přihlášení je umožněno pouze těmto typům subjektů – držitelů datových schránek:
    • fyzická osoba (FO)
    • podnikající fyzická osoba (PFO)

Přitom lze využít pouze datové schránky zřízené na žádost, nikoli ze zákona, tedy nikoli ty zřizované automaticky advokátům, statutárním auditorům, daňovým poradcům nebo insolvenčním správcům. Všechny možnosti přihlášení jsou na sobě nezávislé, ale pro plné využití všech služeb Portálu občana je doporučeno použít elektronický občanský průkaz a dále mít připojenou datovou schránku. V obou případech se jedná o přístup se zaručenou identitou v souladu se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, jinými slovy o přístup do informačního systému veřejné správy nebo elektronické aplikace s využitím prostředku pro elektronickou identifikaci, při jehož vydání nebo v souvislosti s ním anebo v souvislosti s umožněním jeho využití byla totožnost osoby ověřena státním orgánem, orgánem územního samosprávného celku nebo orgánem veřejné moci, který není státním orgánem ani orgánem územního samosprávného celku, nebo který byl vydán v rámci kvalifikovaného systému elektronické identifikace.

Evidence údajů

Portál občana uchovává perzistentně typově takovéto informace:

  • BSI (bezvýznamové směrové identifikátory) – jde o celou sadu identifikátorů, které slouží ke komunikaci s okolními systémy (např. AIFO – ISZR, SePP – NIA atd.). Tyto identifikátory mají význam cizího klíče. Z jejich hodnoty (převážně jde o GUID) nelze přímo vyčíst žádné informace o uživateli. Tyto identifikátory neopouštějí perimetr PO jinak, než při komunikaci s dotčeným systémem.
  • Nastavení – jde o informace ovlivňující zobrazené informace na Portálu občana (např. zobrazení dlaždic, nastavení notifikací apod.). Z jejich hodnot nelze přímo vyčíst žádné informace o uživateli.
  • Dokumenty – jde o celou řadu „souborů“, které se vytvářejí v Portálu občana a nebo které si uživatel do PO nahrál. Jde například o tisknutelnou formu podání, archiv DZ apod. Tyto dokumenty se ukládají do speciální zabezpečené oblasti, která se „odemyká“ až při přihlášení uživatele. Tyto dokumenty mohou obsahovat i zvláštní kategorie osobních údajů (dříve jako citlivé údaje), ale z pohledu PO jsou „neviditelné“ (Portál občana neprovádí parsování těchto dokumentů).
  • Komunikační atributy – v současné době jde o e-mail a telefonní číslo. Komunikační atributy neopouštějí přímo perimetr Portálu občana, ale slouží pouze pro navázání komunikace Portálu občana s uživatelem, resp. zasílání notifikací. Portál občana uživatele notifikuje pouze v případě jeho žádosti ve specifických případech (nastavení).

Transientně přes Portál občana prochází mnoho uživatelských informací. Jejich šíře se nedá přesně specifikovat – záleží, s jakým AIS uživatel prostřednictví Portálu občana komunikuje. Nicméně tyto informace se neukládají (jde pouze o on-line náhledy na informace). Co se týče notifikací změn údajů v základních registrech, proces je spouštěn v definovaných časech (konfigurace Portálu občana), Portál občana zjišťuje na základních registrech změnu přihlášených AIFO. Pokud taková změna proběhla a uživatel si nastavil notifikaci, PO vytvoří zprávu (podle nastavení uživatele) a uloží ji do fronty seznamu zpráv.

Komunikace na úrovni frontend

Komunikací na úrovni frontend je míněno především sdílení společného prostoru kvalifikovaného systému elektronické identifikace (NIA). V tomto prostoru má uživatel možnost procházet přes jednotlivá portálová řešení a využívat tzv. principu „single sign-on“, tj. jednotného přihlášení sdíleného mezi všemi portály či aplikacemi. NIA se řídí ustanoveními zákona č. 250/2017 Sb., o elektronické identifikaci. V návaznosti na výše uvedené slouží tzv. statické dlaždice na Portálu občana pro přechod uživatele mezi Portálem občana a dalšími portály či aplikacemi bez potřeby další autentizace. Portál občany tedy z pohledu funkcionality statických dlaždic slouží jako rozcestník. V současné době si uživatel Portálu občana sám vybírá a aktivuje služby (v podání dlaždic) z katalogu. V dalších fázích rozvoje je uvažováno o nabízení relevantních dlaždic dle jejich obsahu a rolí, ve kterých uživatel bude vystupovat. Aktivní služby v podobě dlaždic jsou uživateli zobrazeny na dashboardu Portálu občana.

Komunikace na úrovni backend

Portál občana standardně napřímo komunikuje s jen omezeným množstvím systémů, a to centrálně sdílených služeb. Konkrétně jde o:

  • Informační systém základních registrů prostřednictvím svých vlastních nebo kompozitních služeb,
  • Informační systém datových schránek.

Pro komunikaci s ostatními systémy Portál občana výhradně využívá eGon Service Bus / Informační systém sdílené služby.

Komunikace prostřednictvím ISZR
  • Čtení ze Základních registrů (ROB, ROS):
    • přístup k údajům v základních registrech probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na přístup k Základním registrům.
  • Čtení přes kompozitní služby (AIS EO):
    • čtení přes kompozitní služby probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na čtení z AIS.
    • činnost musí mít oprávnění na čtení z ROB podle typu použité služby (ověření AIFO nebo referenčních údajů použitých pro vyhledávání).

Mezi napřímo volané služby patří např. E03 robCtiAifo (čtení referenčních údajů z registru ROB), E22 rosCtiPodleUdaju, E45 orgPrihlasAifo (zaevidování AIFO k notifikaci změn v ROB a ORG pro volající AIS), E98 iszrCtiSouborCiselniku, E106 rppVypisSeznamAgend, E153 iszrZpracujFormular, E181 robVypisSouhlasuPoskytnuti, E199 orgZjistiAis (zjištění kombinací AIFO / Agenda, ve kterých v ORG existuje AIFO odpovídající vstupnímu AIFO) nebo E226 eidentitaCtiAifo (převod bezvýznamového identifikátoru fyzické osoby na odpovídající AIFO AIS).

Komunikace prostřednictvím eGSB/ISSS

Pokud hovoříme o spolupráci přes back-end, je tím míněno napojení Portálu občana na publikační AIS a spolupracovat přes služby, které jsou vystaveny na eGSB/ISSS. Připojení publikačního AIS je z pohledu náročnosti poměrně složité a vyžaduje součinnost ze strany provozovatele eGSB/ISSS. Jeho vstupy jsou nezbytné zejména při definování kontextů (schémat datových zpráv), které jsou sice v kompetenci publikátora, ale pro zachování jednotného formátu přes všechny publikátory, je nutné schválení ze strany provozovatele eGSB/ISSS. Portál občana nekonzumuje veškerá data, která jsou publikována na eGSB/ISSS už i z toho důvodu, že ne vše je určeno pro uživatele – fyzickou osobu. Výběr toho, co a jak zobrazovat na Portálu občana, je tedy výsledkem konkrétní spolupráce gestora publikačního AIS a Portálu občana. Po shodě na rozsahu služeb postupují řešitelé Portálu občana v těchto krocích:

  1. vývoj pro čtení dat (čtenářská aplikace),
  2. oprávnění pro čtení a získání testovacích dat,
  3. testování čtení dat.

Po ověření dostupnosti eGSB/ISSS si Portál občana z katalogu služeb stáhne potřebné WSDL a XSD definice služeb a kontextů pro dostupné publikační AIS. Na základě těchto souborů unikátních pro každý publikační AIS a obecného popisu služeb eGSB/ISSS popsaných v dokumentu „Využití služeb eGSB/ISSS čtenářskými AIS“ si Portál občana vytvoří vlastní klientské rozhraní webových služeb pro čtení dat pomocí eGSB/ISSS.

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:

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

Obecně o přístupnosti

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

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

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í:

  1. Obecná úroveň
    1. Mezinárodní přímo aplikovatelná Úmluva o právech osob se zdravotním postižením
    2. Zákon č. 198/2009 Sb., o rovném zacházení a o právních prostředcích ochrany před diskriminací
  2. Úroveň základních služeb
    1. Procesně-správní předpisy, jako je Zákon č. 500/2004 Sb., Správní řád, apod.
    2. Zákon č. 155/1998 Sb., o komunikačních systémech neslyšících a hluchoslepých osob
    3. Nařízení EU č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu (zejména článek 15)
    4. Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů
  3. Úroveň internetových stránek a mobilních aplikací
    1. Zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací subjektů veřejného sektoru
    2. Zákon č. 365/2000 Sb., o informačních systémech veřejné správy (zejména § 5, odst. 2, písm. f), § 9, a další)
    3. Částečně legislativa ohledně spisové služby
  4. Úroveň realizace veřejných zakázek
    1. Zákon č. 134/2016 Sb., o zadávání veřejných zakázek (zejména § 93)

Vesměs z legislativy plynou pro OZP následující práva a pro veřejnou správu povinnosti:

  1. OZP musí mít možnost využívat všechny služby veřejné správy jako kdokoliv jiný
  2. OZP musí mít možnost plnohodnotně využívat elektronické služby stát i elektronické služby subjektů veřejného sektoru
  3. Existuje zde obecná absolutní povinnost přístupnosti výsledků všech veřejných zakázek či zakázek podle legislativy k VZ, pokud jsou jejich výsledky určeny pro jakékoliv užívání fyzickými osobami, to se pochopitelně vztahuje i obecně na veškeré ICT zakázky.
  4. Subjekty veřejného sektoru musejí mít svoje informace přístupné a to zejména na internetových stránkách a ve svých aplikacích
  5. Přístupnost se vztahuje i na veškeré informační systémy pro zaměstnance, protože ani zaměstnanec s OZP nesmí být diskriminován tím, že není schopen pracovat se svým pracovním systémem

Standardy a metodiky

K dispozici jsou technické standardy a metodiky, které určují konkrétní technické postupy pro tvorbu a správu přístupného obsahu. Nejdůležitějšími v oblasti informačních systémů jsou následující:

  • WCAG - Web content accessibility guidelines - Základní standard pro přístupnost obsahu
  • WAI-ARIA: Standard Accessible Rich Internet Applications suite - Standard pro webové aplikace
  • MAAP - Mobile accessibility applications principles - Soubor opatření pro přístupnost mobilních aplikací (přičemž pro jednotlivé platformy jsou opět k dispozici podrobné standardy)

Více o standardech a jejich realizaci se můžete dočíst třeba 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.

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
  • Notifikace o změnách referenčních a agendových údajů pro údaje v AIS vedené
  • Podpora reklamace chybných údajů

Pohled na propojený datový fond

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.

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.

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

Popis Prostorových dat a služeb nad prostorovými daty

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

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

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

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

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

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

Schéma NIPI

Systémy a služby prostorových dat

Pravidla Prostorových dat a služeb nad prostorovými daty

Veřejná správa využívá prostorová data ve všech agendách (a jsou jejich nedílnou součástí), které zajišťuje, např. se jedná o agendy v oblastech dopravy, regionálním rozvoji, ochraně životního prostředí, územním plánování, stavební činnosti, zemědělství, lesnictví, při řešení daňových potřeb státu, v oblasti evidence a správy majetku, pro ochranu kulturního dědictví. Prostorová data mají mimořádný význam pro bezpečnost státu, ochranu obyvatelstva, pro předcházení haváriím a živelním pohromám a řešení mimořádných situací. Aktuální, jednotná a rychle dostupná prostorová data jsou nezbytná pro kvalitní operační a krizové řízení na všech úrovních.

Pro zajištění sdílení a efektivního využívání prostorových dat a informací je nezbytné vytvořit odpovídající soustavu zásad, znalostí, institucionálních opatření, technologií, dat a lidských zdrojů, která se označuje jako infrastruktura pro prostorové informace. V řadě zemí je národní infrastruktura pro prostorové informace (NIPI) upravena a definována, v České republice doposud ucelené, přehledné, systematické a formálně zakotvené stanovení NIPI schází, proto byla alespoň stanovena strategie rozvoje této infrastruktury, viz Strategie rozvoje infrastruktury pro prostorové informace v České republice do roku 2020.

Aby bylo možné NIPI efektivně budovat, je kromě centrálních prvků infrastruktury a sdílených služeb, vhodné definovat typovou funkcionalitu (na obecné úrovni) pro informační systém spravující prostorová data jako součást informačních systémů veřejné správy příslušného orgánu veřejné moci. Protože prostorová data a služby jsou pouhým nástrojem pro podporu výkonu agend veřejné správy, ať již na úrovni státní správy, tak i na úrovni samosprávy, je pro stanovení obecného modelu na úrovni business architektury zásadní definovat klíčové konzumenty poskytovaných služeb ve formě agend a činností (dle terminologie základního registru agend orgánů veřejné moci a některých práv a povinností). Je zřejmé, že business vrstva bude odlišná pro jednotlivé segmenty, nicméně vykazuje určité společné rysy, zejména v řídících, podpůrných a provozních činnostech. Z pohledu podpory tzv. hlavních činností je důležitá vazba na Registr práv a povinností zakládající určité kompetence pro výkon konkrétních agend ve smyslu vazby na legislativu a jednotlivé aktéry (účastníky).

Uplatnění prostorových dat a služeb lze tedy fakticky nalézt ve všech oblastech, typicky, bez ohledu na konkrétní segment, při:

  • formulování strategických dokumentů souvisejících zejména s rozvojem území, služeb a segmentů (např. zdravotnictví, školství, sociální služby) či správou zdrojů,
  • podpoře výkonu agend veřejné správy související např. s územním plánováním, výstavbou, životním prostředím, dopravou, památkami, lesním hospodářstvím či integrovaným záchranným systémem,
  • správě majetku, zejména při evidování, údržbě a opravě, investování (např. budovy, pozemky, komunikace, zeleň, infrastruktura),
  • plánování kontrolních činností či řízení rizik v kontextu prostorových souvislostí.

Součástí business architektury je rovněž identifikace klíčových aktérů. Mezi externí lze zařadit veřejnost (fyzické osoby, fyzické osoby podnikající, právnické osoby), odbornou veřejnost, partnery a dodavatelé. Mezi interní patří např. politická reprezentace, vedení OVM, zaměstnanci vykonávající konkrétní agendy a činnosti a také zástupci ICT útvaru jako poskytovatelé ICT (GIS) služeb. Při popisu aplikační architektury je kromě vlastní funkcionality týkající se tvorby a správy prostorových dat potřebné se zaměřit také na sdílení dat nejen uvnitř vlastní organizace, ale také vůči ostatním informačním systémům veřejné správy.

Vlastní funkce systému pro správu prostorových dat tvoří na obecné úrovni zejména:

  • tvorba a pořízení dat
  • správa prostorových dat
  • správa metadat
  • transformace dat
  • vizualizace
  • analýzy
  • workflow
  • statistiky a reporting
  • harmonizace dat INSPIRE
  • tiskové úlohy
  • opendata
  • archiv

Pro publikaci a sdílení jsou klíčové služby vyhledávací služby, prohlížecí, stahovací, transformační a spouštěcí. Z pohledu vnitřního propojení s ostatními prvky ICT infrastruktury organizace jsou zásadní integrace na:

  • Agendové informační systémy (např. stavební a územní řízení, státní správa lesů, památková péče), kde GIS pomáhá zejména s vizualizací agendových údajů v mapě, vizualizací souvislostí či trendů, s jejich tematizací.
  • Elektronický systém spisové služby včetně spisovny; vztah mezi spisovou službu a digitální spisovnou a GIS není zpravidla realizován, přestože množství vstupů a výstupů z GIS má charakter dokumentu v kontextu zákona č. 499/2004 Sb. a národního standardu (NSESSS). GIS se v takových případech chová jako samostatná evidence dokumentů, nicméně nerespektuje příslušné legislativní povinnosti. Jedním z možných řešení je realizace vazby právě na spisovou službu.
  • Správa majetku a řízení investic, kdy majetek je primárně evidován a spravován v ERP (zpravidla v provázaných modulech evidence a údržby majetku a řízení investic s vazbou na účetní evidenci a rozpočet). Pro správu majetku jsou klíčová data katastru nemovitostí (vedená v ISKN) obsahující jak popisnou, tak i grafickou složku. Tato data ISKN jsou zpravidla v pravidelných intervalech dávkově aktualizována (lze však rovněž využít webových služeb dálkového přístupu katastru nemovitostí ČÚZK), přičemž dochází k často k duplicitní správě dat (včetně pravidelných aktualizací) rovněž v GIS. Optimální je zajistit společnou správu referenčních dat, zajistit jejich sdílení a vzájemnou iteraci na úrovni klientů.

Mezi klíčové, z pohledu vnější integrace na sdílené prvky eGovernmentu, patří:

  • Registr územní identifikace, adres a nemovitostí
  • Informační systém katastru nemovitostí
  • Národní geoportál INSPIRE
  • Digitální technická mapa ČR (IS DMVS)
  • Informační systém identifikačního čísla stavby

Pseudonymizace subjektů v datovém fondu úřadu

Pseudonymizace znamená uložení dat technikou oddělení agendových a identifikačních údajů a jejich propojení pomocí AIFO dle uvedeného schématu:

Pseudonymizace není anonymizací údajů, a i pseudonymizované údaje jsou nadále osobní údaje.

Účelem pseudonymizace je tedy:

  1. Snížení rizika neoprávněného nakládání s osobními údaji
  2. Snížení rizika neoprávněného spojování osobních údajů (dále také „Profilování“)

Oproti dnes běžně používanému postupu, kdy veškeré údaje o osobách jsou uloženy v jedné tabulce (tj. včetně údajů osobních), jde o systematické rozdělení uložených údajů tak, aby od sebe byly odděleny minimálně údaje:

  • Agendové vlastní – údaje vytvářené v rámci agendy, ve které se úřaduje
  • Referenční – údaje získané z registru obyvatel či jiných ZR
  • Agendové – údaje získané z jiných agend, relevantní k dané agendě

Právní aspekty pro pseudonymizaci

Zákonem 111/2009 Sb. o základních registrech byl zaveden základní princip pseudonymizace ve veřejné správě formou Agendového identifikátoru fyzické osoby (AIFO)(§9 až §11 zákona 111/209 Sb. o základních registrech), který zajišťuje pseudonymizaci v rámci výkonu veřejné správy. Důsledné využívání AIFO v rámci ISVS zajišťuje snížení rizika Profilování ve smyslu neoprávněného spojování údajů o konkrétní osobě z různých agend.

Nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů (dále jen GDPR) ve článku 4. definuje pseudonymizaci následovně:

„pseudonymizací“ zpracování osobních údajů tak, že již nemohou být přiřazeny konkrétnímu subjektu údajů bez použití dodatečných informací, pokud jsou tyto dodatečné informace uchovávány odděleně a vztahují se na ně technická a organizační opatření, aby bylo zajištěno, že nebudou přiřazeny identifikované či identifikovatelné fyzické osobě

S odkazem na výše uvedené je nutné poznamenat, že v současnosti stále ještě využívané rodné číslo je v přímém konfliktu s požadavkem na pseudonymizaci, protože RČ, kromě toho že jde o významový identifikátor (obsahuje údaj o datu narození a pohlaví osoby), zejména umožňuje spojování jakýchkoli údajů, které jsou ve spojení s ním vedeny.

Odbor Hlavního architekta eGovernmentu Ministerstva vnitra

Ministerstvo vnitra je podle § 12 zákona č. 2/1969 Sb., kompetenčního zákona ústředním orgánem státní správy mj. pro oblast ISVS a plní též koordinační úlohu pro informační a komunikační technologie, jakož i obecně pro organizaci a výkon veřejné správy. Tyto kompetence jsou dále rozvedeny v ZoISVS, podle něhož se ministerstvo vnitra vyjadřuje k návrhům, projektům a investičním záměrům OVS v oblasti informačních a komunikačních technologií.

Na základě příslušných předpisů plní popsanou koordinační úlohu v oblasti informačních a komunikačních technologií Odbor Hlavního architekta eGovernmentu Ministerstva vnitra (OHA). OHA má nadresortní působnost, to znamená, že je pověřen a zodpovědný za koordinaci a vedení rozvoje eGovernmentu v celé veřejné správě. Samotný eGovernment zahrnuje nejen samotné informační technologie, ale také optimalizaci a zjednodušování služeb veřejné správy vázané na legislativní prostředí. Kromě zmíněných právních předpisů je OHA ke zmíněné koordinační úloze výslovně povolán též usnesením vlády ze dne 27. ledna 2020, č. 86.

Požadavky na pseudonymizaci

Požadavky na pseudonymizaci osobních údajů jsou architektonické, implementační a procesní. Jejich zavedení musí být provedeno tak, aby v žádném případě neomezilo výkon veřejné správy. V ideálním případě by uživatelé ISVS neměli zaznamenat, že pro ukládání a práci s osobními údaji jsou použity procesy pseudonymizace.

Konkrétní realizace tohoto požadavku závisí na komplexitě daného informačního systému a agend, které podporuje

Architektonické postupy pseudonymizace

Pseudonymizace není výslovnou podmínkou zpracování osobních údajů, je však doporučeným postupem snižování rizika neoprávněného nakládání s osobními údaji, spolu s jinými technikami např. šifrováním.

  • Celostátní úroveň – důsledné využívání identifikátoru AIFO, prostřednictvím komunikace s Informačním systémem základních registrů a eGON Service Bus / Informačního systému sdílené služby, při výměně údajů mezi jednotlivými ISVS, a současně zamezení/ukončení jakékoliv výměny agendových dat bez použití AIFO.
  • Lokální úroveň – oddělení primárních identifikačních údajů osoby (referenční údaje vedené v Registru obyvatel) od údajů vytvářených v rámci vlastní agendy, a také oddělení od údajů případně získaných z jiných agend na základě oprávnění při výkonu konkrétní agendy
  • Agendová úroveň: Zajištění využívání pseudonymizovaných agendových identifikátorů v AISech a možnosti výměny údajů z propojeného datového fondu prostřednictvím překladu identifikátorů přes ISZR
  • Doprovodná opatření – šifrování uložených dat, které zvyšuje ochranu osobních údajů v případě odcizení datových souborů (i ve formě záloh) a důsledné logování přístupu k osobním údajům

Na celostátní úrovni

Na celostátní úrovni je zavedením Základních registrů založen bezpečný způsob výměny a správy osobních údajů. Každá agenda má přiděleno AIFO osoby a pouze převodník AIFO (ORG) je schopen převádět AIFO dané osoby mezi jednotlivými agendami. Každý takovýto převod je důsledně zalogován a výměna údajů je zaznamenána v logu Registru obyvatel.

Při výměně údajů mezi agendami je vždy nutné zvážit rozsah údajů, které jsou přenášeny. Současný právní řád v mnoha případech zakládá oprávnění pro získání velkého rozsahu údajů mezi agendami z důvodu zajištění jednoznačné identifikace osoby, o které jsou údaje předávány. Zde je nutné si ale uvědomit, že ačkoli může existovat široké legislativní zmocnění k získávání údajů ze zdrojové agendy, s ohledem na ochranu osobních údajů je doporučeno využívat pouze údaje nezbytně nutné.

Pro identifikaci fyzické osoby při jejím kontaktu s veřejnou správou je ideální použití platného identifikačního dokladu, neboť každý orgán veřejné moci, který při své činnosti využívá některé referenční údaje vedené v registru obyvatel, je oprávněn využívat údaj o čísle a druhu elektronicky čitelných identifikačních dokladů(§18 odst. 5 zákona 111/2009 Sb. o základních registrech). Pokud tedy fyzická osoba předloží nebo ve formuláři uvede druh a číslo svého elektronicky čitelného dokladu, pak může být jednoznačně ztotožněna v Registru obyvatel. V případě vzdálené identifikace a autentizace prostřednictvím Národního bodu(Zákona 250/2017 Sb. o elektronické identifikaci) je fyzická osoba jednoznačně identifikována bezvýznamovým směrovým identifikátorem (BSI), který je možné převést prostřednictvím informačního systému základních registrů na AIFO (službou E226).

Na lokální úrovni

V rámci informačních systémů jednotlivého orgánu veřejné moci je doporučeno využívání stejných principů, které jsou používány na celostátní úrovni s respektem k faktu, že jde o úřadování v konkrétní agendě, kde se velmi pravděpodobně vyskytují agendově specifické údaje, výjimečně i údaje z agend jiných.

Doprovodná opatření

  • Logování – každý přístup k osobním údajům a jejich aktuální propojení musí být uložen do provozního logu po dobu minimálně dvou let v souladu s pravidly dle zákona 111/2009 Sb. Musí být tedy dohledatelné, kdo a v rámci jaké činnosti přistupoval k údajům a provedl jejich propojení.
  • Aktualizace údajů – referenční údaje o fyzické osobě musí být udržovány v aktuálním stavu prostřednictvím notifikačního systému základních registrů. Agendové údaje z jiných agend pak musí být udržovány aktuální podle pravidel platných v agendách, které údaje poskytují. Dle GDPR musí zpracovatel osobních údajů zajistit, že pracuje s aktuálními údaji tak, aby bylo minimalizováno nebezpečí chybného rozhodnutí na základě neaktuálních dat (např. zaslání rozhodnutí na neaktuální adresu osobu, či nevyužití datové schránky fyzické osoby, pokud ji má osoba zřízenu). Zde je nutné poznamenat, že každý orgán veřejné moci, který při své činnosti využívá některé referenční údaje vedené v registru obyvatel, je oprávněn rovněž využívat údaj o adrese, na kterou mají být doručovány písemnosti, o typu datové schránky a identifikátoru datové schránky, je-li tato datová schránka zpřístupněna(§18 odst. 5) zákona 111/2009 Sb. o základních registrech).

Uvedené architektonické požadavky musí být provedeny na databázové a aplikační úrovni tak, aby uživatelé informačního systému nebyli omezováni ve výkonu podporovaných agend. Současně při nutné datové analýze musí být stanoveno, jaké údaje je nezbytně nutné vést v rámci informačního systému. Opět je nutné vzít do úvahy, že ačkoli zákonné ustanovení umožňuje vedení údaje, nemusí být tento údaj veden ve své hodnotě, ale může být veden formou referenční či jiné vazby. Konkrétní rozhodnutí věcného správce agendy musí vycházet s procesních požadavků agendy a není zde možné stanovit paušální jednoznačné pravidlo.

Příkladem může být vedení adres v rámci České republiky, kdy je doporučeným postupem vedení tohoto údaje formou referenční vazby do Registru územní identifikace (RUIAN) či lokální kopie adresních míst, která je udržována aktuální v souladu s RUIAN. Tím je následně vyloučen chybný správní postup, kdy je použita neplatná adresa.

Dalším příkladem je situace, kdy v agendě není využíváno například datum narození osoby pro vyhledávání či třídění, pak toto datum narození je možné vést ve formě referenční vazby do registru obyvatel a konkrétní údaj získávat pouze v potřebných případech.

Referenční rozhraní veřejné správy

Popis referenčního rozhraní

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vždy aktuální seznam eGON služeb je dostupný na stránkách SZR Katalog eGON služeb. Zde uvedený seznam je platný ke konci ledna 2022.

Jednotlivé eGON služby jsou rozdělený do hlavních kategorií:

  1. Služby založené základních registrech
    1. Služby založené na ROB
    2. Služby založené na ROS
    3. Služby založené na RUIAN
    4. Služby založené na RPP
    5. Služby založené na ORG
    6. Služby založené na ISZR
  2. Služby založené na AIS - tzv. kompozitní služby

Mimo výše zmíněné kategorie existují speciální popisné dokumenty pro specifické sady služeb

 Popis_eGON_služeb-obecné_vlastnosti RUIAN.pdf439.92 KB
 Změny_RÚIAN_-_dopad_do_webových_služeb_ISZR.pdf219.86 KB
 rob-dereference_1.pdf340.55 KB
Kategorie Podrobný popis služby Verze Datum poslední aktualizace
Služby založené na ROB  E01 - robVlozObyvatele.pdf (920,58 KB) 01.00 1. 7. 2016
 E02 - robZmenObyvatele.pdf (924,89 KB) 01.00 1. 7. 2016 
 E03 - robCtiAifo.pdf (482,86 KB) 01.02 12. 12. 2016
 E04 - robAutentizace.pdf (825,48 KB) 01.00 25. 12. 2016
 E05 - robCtiPodleUdaju.pdf1.13 MB 01.03 24. 4. 2017
 E06 - robVymazObyvatele.pdf (872,15 KB) 01.00 25. 12. 2016
 E07_robCtiZmeny.pdf446.98 KB 01.02 13. 12. 2021
 E08 - robCtiHromadneAIFO.pdf (849,33 KB) 01.00 1. 7. 2016
 E15 - robCtiEditora.pdf (424,38 KB) 01.02 13.12. 2016
 E102 - robPoskytnutiJineOsobe.pdf (922,00 KB)  01.00 26. 12. 2016
 E103_robCtiZmenyZaloz.pdf498.92 KB 01.01 13. 12. 2021
 E154_robVypisVyuzitiPoskytnuti.pdf547.32 KB 01.01 12. 12. 2021
 E183 - robOverHromadneAIFO.pdf1.20 MB 01.03 26. 11. 2019
 E274_robVlozObyvatele2.pdf572.85 KB 01.00 12. 12. 2021
 E275_robZmenObyvatele2.pdf579.48 KB 01.00 12. 12. 2021
 E276_robCtiAifo2.pdf506.00 KB 01.00 12. 12. 2021
 E277_robCtiHromadneAifo2.pdf520.35 KB 01.00 12. 12. 2021
 E278_robCtiPodleUdaju2.pdf552.79 KB 01.00 12. 12. 2021
 E279_robOverHromadneAifo2.pdf482.79 KB 01.00 12. 12. 2021 
Služby založené na ROS  E16_rosPridelIco.pdf1.21 MB 01.01 22. 8. 2019
 E17 - rosPridelIcp.pdf (822,01 KB) 01.00 1. 7. 2016
 E18 - rosVlozOsobu.pdf585.81 KB 02.01 15. 3. 2021
 E19 - rosZmenOsobu.pdf541.42 KB 02.01 15. 3. 2021
 E20 - rosCtiIco.pdf543.96 KB 02.04 15. 3. 2021
 E21 - rosCtiAifo.pdf551.17 KB 02.03 15. 3. 2021
 E22 - rosCtiPodleUdaju.pdf542.34 KB 02.03 15. 3. 2021
 E23 - rosZapisDatovouSchranku.pdf (800,12 KB) 01.00 1. 7. 2016
 E24 - rosVymazOsobu.pdf (402,13 KB) 01.00 1. 7. 2016
 E25 - rosVlozProvozovnu.pdf (811,46 KB) 01.00 1. 7. 2016 
 E26 - rosZmenProvozovnu.pdf (718,73 KB) 01.00 27. 12. 2016
 E27 - rosVymazProvozovnu.pdf (795,31 KB) 01.00 1. 7. 2016
 E28 - rosCtiZmeny.pdf524.10 KB 01.01 27. 11. 2020
 E29 - rosCtiSeznamIco.pdf549.07 KB 02.03 15. 3. 2021
 E31 - rosCtiSeznamEditoru.pdf448.45 KB 01.01 15. 3. 2021  
 E253 -_rosVlozOsobu2.pdf455.83 KB 01.00 5. 11. 2020
 E254 - rosZmenOsobu2.pdf434.40 KB 01.00 5. 11. 2020 
 E255 - rosZapisPravniStav2.pdf402.33 KB 01.00 5. 11. 2020 
 E256 - rosCtiIco2.pdf477.69 KB 01.01 23. 11. 2021 
 E257_rosCtiAifo2.pdf456.26 KB 01.01 23. 11. 2021 
 E258_rosCtiSeznamIco2.pdf482.39 KB 01.01 23. 11. 2021 
 E259_rosCtiPodleUdaju2.pdf461.71 KB 01.00 5. 11. 2020 
 E93 - rosZapisPravniStav.pdf 540.83 KB 02.01 15. 3. 2021
 E273_rosZapisKontaktniUdaje.pdf457.46 KB 01.00 8. 11. 2021
Služby založené na RUIAN  E34a_ruianVyhledejPrvekAdresniMisto.pdf640.02 KB 01.05 10. 6. 2019
 E34c_ruianVyhledejPrvekCastObce.pdf623.60 KB 01.05 10. 6. 2019
 E34d_ruianVyhledejPrvekKatastralniUzemi.pdf627.47 KB 01.05 10. 6. 2019
 E34e_ruianVyhledejPrvekKraj.pdf622.58 KB 01.05 10. 6. 2019
 E34f_ruianVyhledejPrvekMomc.pdf631.53 KB 01.05 10. 6. 2019
 E34g_ruianVyhledejPrvekMop.pdf625.71 KB 01.05 10. 6. 2019
 E34h_ruianVyhledejPrvekObec.pdf623.71 KB 01.05 10. 6. 2019
 E34i_ruianVyhledejPrvekOkres.pdf625.67 KB 01.05 10. 6. 2019
 E34j_ruianVyhledejPrvekOrp.pdf620.01 KB 01.05 10. 6. 2019
 E34k_ruianVyhledejPrvekParcela.pdf628.56 KB 01.05 10. 6. 2019
 E34l_ruianVyhledejPrvekPou.pdf620.08 KB 01.05 10. 6. 2019
 E34m_ruianVyhledejPrvekRegionSoudrznosti.pdf629.57 KB 01.05 10. 6. 2019
 E34n_ruianVyhledejPrvekSpravniObvod.pdf627.13 KB  01.05 10. 6. 2019
 E34p_ruianVyhledejPrvekStavebniObjekt.pdf623.10 KB 01.05 10. 6. 2019
 E34q_ruianVyhledejPrvekUlice.pdf628.17 KB 01.05 10. 6. 2019
 E34r_ruianVyhledejPrvekVusc.pdf621.76 KB 01.05 10. 6. 2019
 E34s_ruianVyhledejPrvekZsj.pdf623.21 KB 01.05 10. 6. 2019
 E34t_ruianVyhledejPrvekVolebniOkrsek.pdf452.97 KB 04.04 10. 6. 2019
 E35a_ruianCtiPrvekAdresniMisto.pdf622.95 KB 01.02 19. 12. 2016
 E35c_ruianCtiPrvekCastObce.pdf627.39 KB 01.02 19. 12. 2016
 E35d_ruianCtiPrvekKatastralniUzemi.pdf639.13 KB 01.02 19. 12. 2016
 E35e_ruianCtiPrvekKraj.pdf631.26 KB 01.02 19. 12. 2016
 E35f_ruianCtiPrvekMomc.pdf707.82 KB 01.02 19. 12. 2016
 E35g_ruianCtiPrvekMop.pdf696.25 KB  01.02 19. 12. 2016
 E35h_ruianCtiPrvekObec.pdf637.47 KB 01.02 19. 12. 2016
 E35i_ruianCtiPrvekOkres.pdf623.37 KB  01.02 19. 12. 2016
 E35j_ruianCtiPrvekOrp.pdf623.67 KB  01.02 19. 12. 2016
 E35k_ruianCtiPrvekParcela.pdf626.70 KB 01.02 19. 12. 2016
 E35l_ruianCtiPrvekPou.pdf622.50 KB 01.02 19. 12. 2016
 E35m_ruianCtiPrvekRegionSoudrznosti.pdf628.46 KB 01.02 19. 12. 2016
 E35n_ruianCtiPrvekSpravniObvod.pdf624.26 KB 01.02 19. 12. 2016
 E35o_ruianCtiPrvekStat.pdf620.40 KB 01.02 19. 12. 2016
 E35p_ruianCtiPrvekStavebniObjekt.pdf630.32 KB 01.02 19. 12. 2016
 E35q_ruianCtiPrvekUlice.pdf626.11 KB 01.02 19. 12. 2016
 E35r_ruianCtiPrvekVusc.pdf622.21 KB  01.02 19. 12. 2016
 E35s_ruianCtiPrvekZsj.pdf627.67 KB 01.02 19. 12. 2016
 E35t_ruianCtiPrvekVolebniOkrsek.pdf458.40 KB 01.01 27. 12. 2017
 E36_ruianCtiAdresu.pdf449.54 KB 01.00 1. 7. 2016
 E37 - ruianVyhledejAdresu.pdf (429,02 KB) 01.00 1. 7. 2016
 E38 - ruianCtiSeznamZmen.pdf1.36 MB 01.03 21. 11. 2018
 E39 - ruianSouboryZmen.pdf (851,33 KB) 01.00 26. 12. 2016
 E40 - ruianSouboryDat.pdf (852,54 KB) 01.00 26. 12. 2016
 E249a_ruianVyhledejPrvekAdresniMisto2.pdf565.67 KB 01.00 9. 12. 2020
 E249c_ruianVyhledejPrvekCastObce2.pdf563.57 KB 01.00 9. 12. 2020
 E249d_ruianVyhledejPrvekKatastralniUzemi2.pdf567.30 KB 01.00 9. 12. 2020
 E249f_ruianVyhledejPrvekMomc2.pdf572.44 KB 01.00 9. 12. 2020
 E249g_ruianVyhledejPrvekObvodPrahy2.pdf562.95 KB 01.00 9. 12. 2020
 E249h_ruianVyhledejPrvekObec2.pdf565.13 KB 01.00 9. 12. 2020
 E249i_ruianVyhledejPrvekOkres2.pdf565.51 KB 01.00 9. 12. 2020
 E249j_ruianVyhledejPrvekOrp2.pdf558.52 KB 01.00 9. 12. 2020
 E249k_ruianVyhledejPrvekParcela2.pdf576.25 KB 01.00 9. 12. 2020
 E249l_ruianVyhledejPrvekPou2.pdf560.19 KB 01.00 9. 12. 2020
 E249m_ruianVyhledejPrvekRegionSoudrznosti2.pdf565.67 KB01.00 9. 12. 2020
 E249n_ruianVyhledejPrvekSpravniObvod2.pdf569.26 KB 01.00 9. 12. 2020
 E249p_ruianVyhledejPrvekStavebniObjekt2.pdf561.81 KB 01.00 9. 12. 2020
 E249q_ruianVyhledejPrvekUlice2.pdf567.40 KB 01.00 9. 12. 2020
 E249r_ruianVyhledejPrvekVusc2.pdf559.10 KB 01.00 9. 12. 2020
 E249s_ruianVyhledejPrvekZsj2.pdf562.00 KB 01.00 9. 12. 2020
 E249t_ruianVyhledejPrvekVolebniOkrsek2.pdf562.52 KB 01.00 9. 12. 2020
 E250a_ruianCtiPrvekAdresniMisto2.pdf620.25 KB 01.01 30. 11. 2021
 E250c_ruianCtiPrvekCastObce2.pdf564.44 KB 01.00 9. 12. 2020
 E250d_ruianCtiPrvekKatastralniUzemi2.pdf570.70 KB 01.00 9. 12. 2020
 E250f_ruianCtiPrvekMomc2.pdf575.15 KB 01.00 9. 12. 2020
 E250g_ruianCtiPrvekObvodPrahy2.pdf565.29 KB 01.00 9. 12. 2020
 E250h_ruianCtiPrvekObec2.pdf567.65 KB 01.00 9. 12. 2020
 E250i_ruianCtiPrvekOkres2.pdf561.75 KB 01.00  9. 12. 2020
 E250j_ruianCtiPrvekOrp2.pdf563.99 KB 01.00 9. 12. 2020
 E250k_ruianCtiPrvekParcela2.pdf621.62 KB 01.01 30. 11. 2021
 E250l_ruianCtiPrvekPou2.pdf563.40 KB 01.00 9. 12. 2020
 E250m_ruianCtiPrvekRegionSoudrznosti2.pdf567.68 KB 01.00 9. 12. 2020
 E250n_ruianCtiPrvekSpravniObvod2.pdf564.07 KB 01.00 9. 12. 2020
 E250o_ruianCtiPrvekStat2.pdf562.57 KB 01.00 9. 12. 2020
 E250p_ruianCtiPrvekStavebniObjekt2.pdf631.81 KB 01.01 30. 11. 2021
 E250q_ruianCtiPrvekUlice2.pdf564.79 KB 01.00 9. 12. 2020
 E250r_ruianCtiPrvekVusc2.pdf562.74 KB 01.00 9. 12. 2020
 E250s_ruianCtiPrvekZsj2.pdf566.17 KB 01.00 9. 12. 2020
 E250t_ruianCtiPrvekVolebniOkrsek2.pdf566.84 KB 01.00 9. 12. 2020
 E251_ruianCtiAdresu2.pdf429.23 KB 01.00 9. 12. 2020
 E170 - ruianVyhledejSeznamAMVO.pdf (730,20 KB) 04.02 27. 12. 2016
 E184 - ruianCtiSeznamAdres.pdf (797,00 KB) 01.01 27. 12. 2016
 E185 ruianCtiSeznamZmenAD.pdf1.01 MB 01.00 15. 9. 2019
 E281_ruianVyhledejUup.pdf560.79 KB 01.00  8. 11. 2021
 E282_ruianVyhledejUupEd.pdf 561.67 KB 01.00  8. 11. 2021 
 E283_ruianCtiUup.pdf582.04 KB 01.00  8. 11. 2021
 E284_ruianCtiUupEd.pdf579.23 KB 01.00  8. 11. 2021
Služby založené na ORG  E45 - orgPrihlasAifo.pdf (467,83 KB) 01.00 8. 5. 2015
 E46 - orgOdhlasAifo.pdf (470,50 KB) 01.00 8. 5. 2015
 E69 - orgSpojZIFO.pdf (417,45 KB) 01.00 1. 7. 2016 
 E70 - orgRozdelZIFO.pdf (817,79 KB) 01.00 25. 12. 2016
 E71 - orgZkontrolujAIFO.pdf (410,16 KB) 01.00 14. 12. 2016
 E75 - orgCtiDavkuAIFO.pdf (417,08 KB) 01.00 14. 12. 2016
 E76 - orgPredchudciAIFO.pdf (413,17 KB) 01.00 14. 12. 2016
 E77 - orgRodokmenAIFO.pdf (422,70 KB) 01.00 14. 12. 2016
 E78 - orgCtiZmenyAIFO.pdf (466,56 KB) 01.00 8. 5. 2015
 E95 - orgZalozAIFOPE.pdf (796,78 KB) 01.00 1. 7. 2016 
 E53 - isuiReklamujPrvek.pdf.pdf393.20 KB 01.09 18. 1. 2022
 E199 - orgZjistiAis.pdf (661,47 KB) 01.00 14. 7. 2015
Služby založené na ISZR  E62 - iszrReklamujUdajeRob.pdf (849,43 KB) 01.02 21. 12. 2016
 E63 - iszrReklamujUdajeRos.pdf (943.02 KB) 01.05 5. 2. 2018
 E97 - iszrCtiSeznamCiselniku.pdf (696,38 KB) 01.00 25. 12. 2016
 E99 - iszrAsyncVypisFronty.pdf (365,10 KB) 01.02 13. 12. 2016
  E100 - iszrAsyncOdpovedZFronty.pdf (395,79 KB) 01.03 13. 12. 2016
 E101 - iszrAsyncSmazatFrontu.pdf (352,58 KB) 01.02 13. 12. 2016
 E164 - iszrProbe.pdf (791,58 KB) 04.01 27. 12. 2016
 E166 - iszrAutentizaceAis.pdf (691,89 KB) 01.01 27. 12. 2016
 E175 - iszrUlozMapaAifo.pdf514.80 KB 06.00 16. 6. 2019
 E176 - iszrPodejMapaAifo.pdf502.87 KB 05.00 16. 6. 2019
 E177 - iszrCtiReklamaci.pdf (791,96 KB) 01.02 20. 12. 2016
 E227 - iszrVypisOpravneniPolozky.pdf (699,82 KB) 01.00 10. 5. 2018 
Služby založené na RPP  E105 - rppCtiZmeny.pdf (354,54 KB) 01.02 14. 12. 2016
 E106 - rppVypisSeznamAgend.pdf (365,68 KB) 01.00 1. 7. 2016
 E107 - rppVypisAgendu.pdf (369,16 KB) 01.00 1. 7. 2016  
 E115 - rppVlozRozhodnuti.pdf (735,85 KB) 01.00 27. 12. 2016
 E129 - rppVypisSeznamPusobnostiOVM.pdf (707,04 KB) 01.02 20. 12. 2016
 E130 - rppVypisPusobnostOvm.pdf (701,41 KB) 01.02 20. 12. 2016
 E135 - rppVypisSeznamSluzeb.pdf (697,36 KB) 01.02 20. 12. 2016
 E136 - rppVypisSluzbu.pdf (699,54 KB) 01.02 20. 12. 2016
 E140 - rppVypisSeznamSLA.pdf (689,94 KB) 01.00 26. 12. 2016
 E148 - ppVypisOpravneni.pdf (740,98 KB) 01.02 20. 12. 2016
 E228 – rppVypisOvmSpuu2.pdf (781,86 KB) 01.00 25. 7. 2018
 E229 – rppVypisAgendu3.pdf (784,80 KB) 01.00 2. 9. 2018
 E230 - rppCtiZmenyUkonuNaZadost.pdf (770,88 KB) 01.00 25. 7. 2018
 E231 - rppVypisSeznamUkonuNaZadost.pdf (776,57 KB) 01.00 25. 7. 2018
 E232 – rppVypisUkonNaZadost.pdf (768,55 KB) 01.00 2. 9. 2018
 E233 – rppVypisPusobnostOvm3.pdf (780,33 KB) 01.00 25. 7. 2018
 E244 – rppVypisSeznamUdajuAgendy.pdf1.03 MB 01.00 20. 11. 2019
 E245-rppVypisPusobnostOvm4.pdf1.05 MB 01.00 1. 4. 2020
 E246-rppVypisAgendu4.pdf1.04 MB 01.00 1. 4. 2020
 E247-rppVypisUkonNaZadost2.pdf1.04 MB 01.00 1. 4. 2020
 E260_rppVypisAgendu5.pdf399.03 KB 01.00 5. 12. 2020
 E261_rppVypisPusobnostOvm5.pdf410.67 KB 01.00 5. 12. 2020
 E262_rppCtiZmenySluzebVs.pdf434.50 KB 01.00 5. 12. 2020
 E263_rppVypisSluzbuVs.pdf412.02 KB 01.00 5. 12. 2020
 E264_rppVypisSeznamSluzebVs.pdf445.97 KB 01.00 5. 12. 2020
 E210 - rppVypisSeznamOvmSpuu.pdf (801,34 KB) 01.00 21.7. 2017
 E211 - rppVypisOvmSpuu.pdf (793,86 KB) 01.01 2. 9. 2018 
 E214 - rppVypisSeznamKategoriiOvmSpuu.pdf (767,25 KB) 01.00 25. 7. 2017 
 E215 - rppVypisKategoriiOvmSpuu.pdf (765,23 KB) 01.00 26. 7. 2017 
 E218 - rppCtiZmenyOvmSpuu.pdf (764,19 KB) 01.00 23. 7. 2017
 E219 - rppCtiEditoraOvmSpuu.pdf (756,78 KB) 01.00 24. 7. 2017 
Služby založené na AIS – kompozitní služby
Agendový informační systém evidence obyvatel  E158 - aiseoZtotozneni.pdf (765,50 KB) 04.01 27. 12. 2016
 E171 - aiseoCtiAifo2.pdf (795,86 KB) 04.01 27. 12. 2016
 E172_aiseoCtiPodleUdaju2.pdf503.57 KB 05.00 14. 6. 2021
Agendový informační systém cizinců  E162 - aiscCtiAifo.pdf591.28 KB 01.01 20. 3. 2018
 E163 - aiscCtiPodleUdaju.pdf599.56 KB 01.01 20. 3. 2018
 E173 - aiscCtiAifo2.pdf569.23 KB 01.00 26. 11. 2019
 E174 - aiscCtiPodleUdaju2.pdf566.74 KB 01.00 20. 11. 2019
Evidence občanských průkazů  E188 - eopCtiAifo.pdf1.20 MB 02.03 26. 8. 2019
 E191 - eopCtiHromadneAifo.pdf1.16 MB 02.03 26. 8. 2019
E194 - eopCtiPodleUdaju.pdf1.09 MB 02.03 24. 8. 2019
 Evidence cestovních dokladů E189 - ecdCtiAifo.pdf1.13 MB 02.02 26. 8. 2019
E192 - ecdCtiHromadneAifo.pdf1.12 MB 02.02 26. 8. 2019
E195 - ecdCtiPodleUdaju.pdf1.14 MB 02.02 26. 8. 2019
Získání fotografie a podpisu fyzické osoby E197 - agendaMediaDataCtiAifo.pdf452.08 KB 01.05 18. 7. 2018
E198 - agendaMediaDataCtiPodleUdaju.pdf468.25 KB 01.03  26. 9. 2017
Elektronická identita - překlad BSI  E226 - eidentitaCtiAifo.pdf (707,01 KB) 01.00  29. 11. 2017
AIS Působnostní RPP  E235 – aispVypisSeznamIs.pdf (713.39 KB) 01.00 4. 2. 2019
 E236 – aispVypisDetailIs.pdf (712.96 KB) 01.00 4. 2. 2019
 E237 – aispCtiZmenyIs.pdf (706.85 KB) 01.00 4. 2. 2019
E265_aispVypisSeznamIsV2_1.00.pdf413.66 KB 01.00 5. 12. 2020
E266_aispVypisDetailIs2_1.00.pdf407.42 KB 01.00 5. 12. 2020
Informační systém katastru nemovitostí  E238 – isknCtiVlastniky2.pdf491.83 KB 01.00 15. 7. 2020
E242d – isknCtiPrvekKDatuKatastralniUzemi.pdf1.16 MB 01.01 26.11.2019
E242k – isknCtiPrvekKDatuParcela.pdf1.15 MB 01.01 26.11.2019
 E94 - isknReklamujPrvek.pdf (1,37 MB) 01.00 14. 11. 2017
Informační systém územní identifikace  E252a_isuiCtiPrvekAdresniMistoKDatu2.pdf520.13 KB 01.00 9. 12. 2020
 E234 – isuiVyhledejParceluGP.pdf 435.11 KB 01.00 29.10.2018
E252c_isuiCtiPrvekCastObceKDatu2.pdf516.27 KB 01.00 9. 12. 2020
E252f_isuiCtiPrvekMomcKDatu2.pdf529.78 KB 01.00 9. 12. 2020
E252g_isuiCtiPrvekObvodPrahyKDatu2.pdf516.06 KB 01.00 9. 12. 2020
E252h_isuiCtiPrvekObecKDatu2.pdf521.06 KB 01.00 9. 12. 2020
E252i_isuiCtiPrvekOkresKDatu2.pdf515.16 KB 01.00 9. 12. 2020
E252j_isuiCtiPrvekOrpKDatu2.pdf516.33 KB 01.00 9. 12. 2020
E252l_isuiCtiPrvekPouKDatu2.pdf518.38 KB 01.00 9. 12. 2020
E252m_isuiCtiPrvekRegionSoudrznostiKDatu2.pdf521.36 KB 01.00 9. 12. 2020
E252n_isuiCtiPrvekSpravniObvodKDatu2.pdf514.37 KB 01.00 9. 12. 2020
E252o_isuiCtiPrvekStatKDatu2.pdf515.83 KB 01.00 9. 12. 2020
E252p_isuiCtiPrvekStavebniObjektKDatu2.pdf522.22 KB 01.00 9. 12. 2020
E252q_isuiCtiPrvekUliceKDatu2.pdf517.46 KB 01.00 9. 12. 2020
E252r_isuiCtiPrvekVuscKDatu2.pdf515.94 KB 01.00 9. 12. 2020
E252s_isuiCtiPrvekZsjKDatu2.pdf516.55 KB 01.00 9. 12. 2020
E285_isuiCtiUupKDatu.pdf558.12 KB 01.00 8. 11. 2021 
E286_isuiCtiStavReklamace.pdf517.99 KB  01.00  8. 11. 2021

Základní registry

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

Jedná se o referenční údaje o

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

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

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

Registr obyvatel (ROB)

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

Subjekty údajů vedených v registru obyvatel jsou

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

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

  • 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 Český statistický úřad. Primárními editory jsou orgány a instituce, které již v současnosti mají zákonnou povinnost osoby registrovat. Jedná se o obchodní rejstřík, rejstřík živnostenského podnikání, evidence nebo informační systémy vybraných ministerstev a ústředních orgánů státní správy, profesních komor, obcí, krajů apod. Sekundárním editorem je Ministerstvo vnitra se systém Datových schránek (ISDS).

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

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

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

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

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

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

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

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

Editory údajů jsou:

Název osoby Typ osobyAgendaEditor ROS
Advokáti FO A8 Česká advokátní komora
Agentury práce FO A531 Ministersvo práce a sociálních věcí
Akreditovaná osoba podle zákona o spotřebitelském úvěru FO A11 Česká národní banka
Auditoři FO A6 Komora auditorů České republiky
Auditoři bezpečnosti pozemních komunikací FO A1381 Ministerstvo dopravy
Autorizovaní architekti FO A54 Česká komora architektů
Autorizovaní inženýři a technici FO A54 Česká komora autorizovaných inženýrů a techniků činných ve výstavbě
Církve a náboženské společnosti PO A5 Ministerstvo kultury
Česká národní banka, Česká televize, Český rozhlas, Regionální rada regionu soudržnosti, Všeobecná zdravotní pojišťovna PO A325 Ministerstvo vnitra
Daňoví poradci FO A7 Komora daňových poradců ČR
Dobrovolné svazky obcí PO A343 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Držitelé licencí pro podnikání v energetických odvětvích FO A684 Energetický regulační úřad
Evropská seskupení pro územní spolupráci PO A561 Ministerstvo pro místní rozvoj
Fyzické osoby - provozovatelé poštovních služeb FO A926 Český telekomunikační úřad
Fyzické osoby provozující živnost (živnostníci) FO A121 Místně příslušný živnostenský úřad
Honební 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í organizacePO A120 Místně příslušný rejstříkový soud

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

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

Registr územní identifikace adres a nemovitostí je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje základní územní prvky, 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.

Referenční údaje

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

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

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

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

Základní povinnosti editora tedy jsou:

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

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

Virtuální referenční údaje

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

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

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

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

Údaje typu indikátor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Editorské AIS

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

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

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

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

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

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

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

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

V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami G1:gsbCtiData a G11:gsbZapisData pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí ORG identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby G1:gsbCtiData či G11:gsbZapisData zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.

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

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

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

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

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

  • Údaje jsou ohlášeny v registru práv a povinností jako údaje, které agenda zpracovává na základě zákonného zmocnění
  • Údaj musí být vedený v AIS
  • U údaje je jasné, jak vznikl, kdo je zodpovědný za jeho zápis, změny a správu, v jakém AIS je veden a jakým způsobem může být změněn či zrušen.
  • Poskytovatelem údaje je vždy správce AIS, v němž je údaj veden a evidován.
  • Údaj je vždy vázán na subjekt práva, či objekt práva v ZR.
  • Bude umožněno subjektu práva si pořídit výpis údajů jako výpis z informačního systému veřejné správy.
  • Důrazně doporučujeme používat služby pouze v synchronním režimu – každé volání je nezávislé na ostatních a není třeba čekat a serializovat
  • Využívat volání po více vláknech a tím dosáhnout dostatečnou průchodnost i na velký počet požadavků

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

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

Informace k informačnímu systému sdílení údajů jsou k dispozici na stránkách SZR ČR včetně dokumentů:

Způsob komunikace mezi čtenáři a publikátory

Čtenář čte od publikátora

typ akce popis
evidence vyměňovaných údajů – agenda publikátora údaje jsou evidovány v agendě publikátora
udělení oprávnění v RPP publikátor dává čtenáři souhlas (typicky v agendě čtenáře) pro čtení (R, Rh, Rn, Rhn)
evidence a atributy vyměňovaných údajů – agenda - čtenářečtené údaje budou evidovány i v agendě čtenáře jako agendové přebírané a budou odkazovat na zdroj (údaj publikátora)
vytvoření kontextu publikátor vytváří kontext pro eGSB
kód údaje v kontextu v kontextu eGSB bude v komentáři kód údaje z agendy publikátora

 

Čtenář zapisuje údaj do agendy publikátora

typ akce popis
evidence vyměňovaných údajů – agenda publikátora údaje jsou evidovány v agendě publikátora
udělení oprávnění v RPP publikátor dává čtenáři souhlas pro zápis (W)
evidence a atributy vyměňovaných údajů – agenda - čtenářev agendě čtenáře (zapisovatele) budou zapisované údaje evidovány jako agendové přebírané a budou odkazovat na zdroj (údaj publikátora)
vytvoření kontextu publikátor vytváří kontext pro eGSB
kód údaje v kontextu v kontextu eGSB bude v komentáři kód údaje z agendy publikátora
Seznam služeb eGSB / ISSS
KódPodrobný popis službyVerze
G1 gsbCtiData 1.03
G2 gsbCtiZmeny 1.01
G3 gsbVlozOdpoved 1.02
G4 gsbVlozSoubor 1.04
G5 gsbCtiSoubor 1.01
G6 gsbVypisFronty 1.01
G7 gsbOdpovedZFronty 1.01
G8 gsbSmazatFrontu 1.01
G9 gsbProbe 1.01
G10 gsbCtiKontexty 1.01
G11 gsbZapisData 1.04
K1 katCtiSluzby 1.01
K2 katCtiDetailSluzby 1.01
K3 katCtiPrilohu 1.01
K4 katCtiEndpoint 1.01
Kontext eGSB / ISSS

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

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

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

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

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

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

Konceptuální modely kontextů

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

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

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

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

Seznam kontextů

Detailní seznam kontextů je dostupný na adrese https://egsbkatalog.cms2.cz/. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.

PořadíKód Název
1 A1029.1 Pojištěnec
2 A1029.2 Osoba samostatně výdělečně činná
3 A1029.3 Zaměstnavatel
4 A1029.4 Územně organizační jednotka
5 A1041.2001 Osoba - doklady
6 A1041.4001 Provozovatel plavidla - plavidla
7 A1041.4004 Vlastník plavidla - plavidla
8 A1041.9001 Osoba - doklady, plavidla
9 A1046.1 Řidič - podklady pro podání žádosti o řidičský průkaz
10 A1046.2 Řidič - podání žádosti o řidičský průkaz
11 A1046.2001 Osoba - zkoušky řidiči
12 A1046.3 Řidič - registrace k notifikacím změn bodového hodnocení
13 A1046.4 Řidič - osvědčení o digitálním úkonu
14 A1046.RidicRozsirene Řidič - rozšířené údaje
15 A1046.RidicZakladni Řidič - základní údaje
16 A1046.RidicZakladni Řidič - základní údaje
17 A1061.1 NBU Avizace
18 A120.1 Předání a zneplatnění ÚZ
19 A121.1 Přehled o údajích autentizované osoby
20 A121.2 Výpis údajů podnikatelského subjektu
21 A124.1 ISKN - Evidence práv pro osobu
22 A124.2 ISKN - List vlastnictví
23 A1341.1 Ověření v.z.p. pojištěnce
24 A1341.2 Oznámení OSVC PP
25 A1341.3 Oznámení OSVC PP ZP
26 A1341.4 Seznam OSVC PP
27 A1381.1 Vozidlo v Systému Elektronického Mýtného
28 A1381.2 Zahraniční provozovatel vozidla v Systému Elektronického Mýtného
29 A344.1 Notifikace prostřednictvím Portálu Občana
30 A3726.1 Pacient
31 A385.1 Oznámení OSVC PP
32 A385.2 Seznam OSVC PP
33 A385.3 Výpis z Daňové Informační Schránky
34 A385.4 Oznámení stavu účetní závěrky
35 A385.5 Výpis prijmů z Daňového priznami
36 A392.1 Dlužník
37 A392.2 ODU
38 A392.3 Nedoplatky dle ukladatele
39 A4003.1 Poskytovatelé zdravotních služeb
40 A4003.2 Zdravotnická dokumentace pacienta
41 A418.1 Osoba v pátrání
42 A418.2 Vozidlo v pátrání
43 A418.3 NBU Lustrace
44 A476.1 Registr ISIN
45 A483.1 Výpis údajů z Rejstříku trestů
46 A561.1 Výzva
47 A561.2 Projekt
48 A561.3 Vypočtené indikátory
49 A575.1 IS ÚCL
50 A8566.1 Notifikace
51 A998.1 Registr silničních vozidel
Seznam datových obsahů kontextů

Termínem datové obsahy se rozumí definice XML schémat popisujících rozhraní pro dotazování publikačních AIS, které publikují data v rámci jimi vedených agend prostřednictvím eGSB/ISSS.

PořadíKód Název
1 1 Žádost o poskytnutí údajů o vozidle z evidence Systému Elektronického Mýtného.
2 2 Žádost o poskytnutí údajů zahraničního provozovatele vozidla z evidence Systému Elektronického Mýtného.
3 A124.1.PravaProOsobu Dotaz práva osoby vedená v KN
4 A124.2.ListVlastnictvi Dotaz na list vlastnictví v KN
5 A344.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele Portálu Občana
6 A8566.1.Notifikace Definice jednotlivých kanálů pro notifikování uživatele
7 CRRDotaz Dotaz do registru řidičů
8 CrrOsvedceniDigiUkon Osvědčení o digitálním úkonu
9 CrrRidicNotifikaceBoduReg Registrace k notifikacím změn bodového hodnocení
10 CrrRidicRozsirene Dotaz do CRŘ na rozšířené údaje o řidiči
11 CrrRidicUdaje Dotaz do CRŘ na údaje o řidiči
12 CrrRidicZadostPodani Podání žádosti o řidičský průkaz
13 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
14 CrrRidicZakladni Dotaz do CRŘ na základní údaje o řidiči
15 CSCEPANDLUZNIK Dotaz na nedoplatky do evidence přeplatků a nedoplatků Celní správy
16 CSCEPANNEDOPLATKYDLEUKLADATELE Dotaz na evidované nedoplatky podle ukladatele u Celní správy
17 CSCEPANODU Dotaz na stav osobního daňového účtu do evidence přeplatků a nedoplatků Celní správy
18 CSSZOsvc Dotaz do ČSSZ na údaje o OSVČ
19 CSSZPojistenec Dotaz do ČSSZ na údaje o pojištěnci
20 CSSZUoj Dotaz do ČSSZ na údaje o Územně organizační jednotce
21 CSSZZamestnavatel Dotaz do ČSSZ na údaje o Zaměstnavateli
22 DAPPRIJEM Dotaz na prijmy z Daňového přiznání
23 DISDOTAZ Dotaz na výpis z Daňové Informační Schránky
24 DISZADOST Žádost na výpis z Daňové Informační Schránky
25 EtestyOsobaZkousky Dotaz do IS eTesty na vykonané zkoušky odborné a profesní způsobilosti.
26 EVIDOSVC EvidenceOSVC
27 FormularePOCti Formuláře Portálu občana - čtení
28 FormularePOZapis Formuláře Portálu občana - čtení
29 INFPREHL Informovani o DAP
30 KALENDAR Dotaz na výpis z Daňové Informační Schránky
31 KONTROLAOSVC Kontrolní zjištění OSVČ
32 KONTROLAZC Kontrolní zjištění závislé činnosti
33 MSProjekt Projekt
34 MSVypIndi Vypočtené indikátory
35 MSVyzva Výzva
36 NBU_Lustrace NBU Lustrace
37 NBUAVIZACE NBU Avizace
38 OBNOVENISVC385 Opětovné zahájení SVČ
39 PaisCtiRSVKontexty Dotaz na vozidlo
40 PaisRsvCtiAifo Dotaz na vozidlo
41 PaisRsvCtiFormular Formuláře - čtení
42 PaisRsvCtiIco Dotaz na vozidlo
43 PaisRsvCtiNovaEkoVozidla Dotaz na vozidlo
44 PaisRsvCtiNovaEkoVozidlaAsync Dotaz na vozidlo
45 PaisRsvCtiOrv Dotaz na vozidlo
46 PaisRSVCtiOsvedceniFormular Dotaz na vozidlo
47 PaisRsvCtiPoplatek Suma poplatku
48 PaisRsvCtiPrilohu Dotaz na vozidlo
49 PaisRsvCtiRz Dotaz na vozidlo
50 PaisRsvCtiSazebnikPoplatku Sazebník poplatků
51 PaisRsvCtiSeznamFormularu Seznam registračních míst z RSV
52 PaisRsvCtiSeznamIcoAsync Dotaz na vozidlo
53 PaisRsvCtiSeznamRcAsync Dotaz na vozidlo
54 PaisRsvCtiSeznamRm Seznam registračních míst z RSV
55 PaisRsvCtiTp Dotaz na vozidlo
56 PaisRsvCtiVin Dotaz na vozidlo
57 PaisRsvCtiVozidloId Dotaz na vozidlo
58 PaisRsvCtiZmeny Dotaz na vozidlo
59 PaisRsvCtiZmenyAsync Dotaz na vozidlo
60 PaisRsvVlozPrilohu Formuláře - vložení přílohy
61 PaisRsvVozidlaAsyncOdpoved Dotaz na vozidlo
62 PaisRsvZamkniFormular Formuláře - zamknutí
63 PaisRsvZapisFormular Formuláře - zápis
64 PaisRsvZapisInformaceOPlatbe Zápis informací o platbě
65 PATRMV Dotaz na vozidlo v pátrání
66 PATROS Dotaz na osobu v pátrání
67 PDFCertifikatu Dotaz na certifikát tazatele v PDF
68 PODANPREHLED Podán přehled OSVCPP ZP
69 PODANPREHLED385 Podán přehled OSVCPP ZP
70 PONDUKONC Podnět ukončení
71 PONDUKONC385 Podnět ukončení
72 PREHLEDPLATEB Přehled plateb
73 PREVYSUZVESL Oznámení stavu účetní závěrky
74 RTFODotaz Dotaz do Rejstříku trestů
75 RTNastaveniBlokace Požadavek do Rejstříku trestů na vytvoření, popř. zrušení blokace
76 RTZadosti Dotaz do Rejstříku trestů
77 RTZadostiDokument Požadavek do Rejstříku trestů na vystavení výstupního dokumentu.
78 RTZadostiStav Dotaz do Rejstříku trestů na stav manuálně zpracovávaných žádostí.
79 SeznamCertifikatu Dotaz na certifikáty tazatele
80 SEZNAMOSVCPP Seznam OSVCPP
81 SEZNAMOSVCPP385 Seznam OSVCPP
82 SeznamPoskytovatelu Seznam poskytovatelů s dostupnou zdravotnickou dokumentací osoby
83 SPSOsobaDoklady Dotaz do IS SPS na průkazy způsobilosti, které vlastní.
84 SPSOsobaDokladyPlavidla Dotaz do IS SPS na průkazy způsobilosti a vlastněná/provozovaná plavidla.
85 SPSProvozovatelPlavidla Dotaz do IS SPS na plavidla, která provozuje.
86 SPSVlastnikPlavidla Dotaz do IS SPS na plavidla, která osoba vlastní.
87 UCETNIZAVERKA Předání a zneplatnění ÚZ
88 UclUdaje Dotaz na údaje z IS ÚCL
89 UKONCENI Ukonceni
90 Vozidlo Dotaz na vozidlo
91 VYPFOISVS Dotaz na osobu podle zákona 365/2000 Sb.
92 VypisVozidelPDF Výpis vozidel v PDF
93 VYPOOCRP Dotaz na ověření osoby vůči CRP
94 VYPSUBJISVS Dotaz na subjekt podle zákona 365/2000 Sb.
95 ZadostOVypis Žádost o výpis
96 ZAPOSVCPP Zápis OSVC PP
97 ZdravotnickaDokumentace Dokument se zdravotnickou dokumentací pacienta
98 ZMENACISPOJ Změna čísla pojištěnce
99 ZMENACISPOJ385 Změna čísla pojištěnce
Pohled na propojení integračních platforem

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

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

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

FAIS tedy poskytuje mimo jiné:

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

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

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

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

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

Implementace zpracování hromadných požadavků

Dále je popsán detailní návrh implementace pro oblast „Zpracování hromadných požadavků“ ve FAIS.

Primárním cílem hromadného zpracování je řízené využití služeb ISSS, které povede k zásadnímu omezení rizik plynoucích ze vznikajících potřeb hromadného zpracování dat prostřednictvím ISSS.

Zpracování hromadných požadavků

Obsahem návrhu a implementace požadavku na zpracování hromadných požadavků ve FAIS je obecná implementace příjmu požadavku na hromadné zpracování prostřednictvím ISDS, respektive prostřednictvím služby referenčního rozhraní PPDF a následné zpracování tohoto požadavku prostřednictvím ISSS, respektive ISZR.

Motivace

Zpracování dat prostřednictvím ISSS je omezeno na zpracování požadavků pro jeden subjekt. V praxi aktuálně vzniká potřeba zpracování dávkových úloh obsahujících rozsáhlou množinu subjektů. V současné době je tato potřeba řešena na úrovni AIS, které v rámci své individuální implementace využívají různé přístupy, které zajišťují rozpad dávkové úlohy na individuální žádosti a zpracování těchto individuálních žádostí prostřednictvím rozhraní webových služeb ISSS.

Výše popsaný přístup znamená, že AIS může ke své implementaci přistoupit způsobem, který je buď sám o sobě nevyhovující z pohledu zátěže generované na ISSS, respektive může být nevyhovující společně v kombinaci s dalšími AIS, které řeší hromadné zpracování prostřednictvím ISSS.

Nevyhovujícím přístupem z pohledu ISSS se rozumí potenciální přetěžování jak vlastního ISSS, tak i potenciální přetěžování navázaných služeb ISZR.

Rizika plynoucí z možného přetěžování ISSS ošetřuje ISSS vlastními kontrolními mechanismy, jejichž výsledkem může být omezování povolených přístupů AIS ke službám ISSS, důsledkem čehož mohou nastávat problémy na straně AIS a jejich business procesů.

Aby bylo možné řídit zátěž ISSS pro účely dávkového zpracování a efektivně zpracovávat dávkové úlohy, požaduje OHA implementovat efektivní podporu pro dávkové zpracování prostřednictvím úprav systému FAIS, který je součástí implementace ISZR a tedy se i stane součástí referenčního rozhraní PPDF.

Aplikační architektura

Na následujícím obrázku je znázorněna stávající aplikační architektura FAIS.

Obsah obrázku text, diagram, Plán, Technický výkres Popis byl vytvořen automaticky

Interní aplikační komponenty FAIS

Interní komponenty FAIS jsou realizovány formou objektů vystavujících metody pro provádění příslušných operací.

  • Příjem z ISDS – komponenta FAIS zabezpečující vyzvedávání a validaci datových zpráv doručených do příslušné datové schránky sloužící pro příjem požadavků na zpracování.
  • Odesílání ISDS – komponenta FAIS slouží pro odesílání výsledků zpracování požadavků formou datových zpráv prostřednictvím definované datové schránky ISDS.
  • WS – komponenta FAIS vystavující rozhraní webových služeb pro příjem a validaci požadavků doručených webovou službou na eGON rozhraní ISZR.
  • Orchestrace – komponenta FAIS zajišťující proces získání dat a přípravu výstupů s využitím dalších podpůrných komponent FAIS a eGON rozhraní ISZR.
  • Logování – komponenta FAIS zajišťující logování průběhu zpracování požadavku.
  • Formátovací šablony – komponenta FAIS poskytující formátovacímu procesu XSLT šablony pro generování výstupů.
  • Formátování výstupů – komponenta FAIS zajišťující sestavení výstupů na základě dat a s využitím formátovacích šablon.
  • Podepisování a pečetění – komponenta FAIS zajišťující s využitím HSM modulu podepisování sestavených PDF výstupů.

Externí komponenty

Externí komponenty jsou systémy nebo rozhraní systémů mimo implementační perimetr FAIS. Tyto systémy a rozhraní jsou nutné pro zpracování požadavků doručovaných do systému FAIS.

  • ISDS – webové služby ISDS, příjem a odesílání datových zpráv. Do datové schránky pro příjem požadavků na formuláře jsou doručovány žádosti o zpracování a výsledek zpracování je odesílán zpět žadateli.
  • ISZR – interní orchestrátor ISZR zpracovávající požadavky na formuláře doručované prostřednictvím webových služeb eGON rozhraní ISZR
  • HSM – HSM modul pro podepisování sestavených PDF výstupů
  • eGON ISZR – eGON rozhraní webových služeb ISZR vystavující služby využívané při zpracování požadavků.
Architektonický model FAIS

Na následujícím obrázku je znázorněn model technologické infrastruktury FAIS ve vazbě na předchozí model aplikační architektury FAIS.

Obsah obrázku diagram, text, Plán, řada/pruh Popis byl vytvořen automaticky

Na logických uzlech FAIS (Fx.DCx – virtuální server v datovém centru DC1 a DC2, tj. STC nebo CP) je spuštěn řídící proces. Na všech serverech jsou nainstalovány všechny interní aplikační komponenty FAIS (viz předchozí kapitola – aplikační role). Konfiguračně je řízeno, jaká konkrétní aplikační komponenta (nebo více komponent, respektive aplikačních rolí) je na konkrétním serveru spuštěna.

Popsaná architektura umožňuje jednotlivým serverům přiřazovat aplikační role s ohledem na aktuální potřeby (procesně řízeno provozem).

Zpracování hromadných požadavků

FAIS bude implementovat podporu pro hromadné zpracování vůči ISSS, respektive ISZR. Jde o implementaci nového procesu, který dosud FAIS nepodporuje.

V následujícím popisu je popsána funkcionalita primárně s ohledem na zpracování HP vůči ISSS, zpracování vůči ISZR je principiálně totožné, pokud jsou ve zpracování rozdílu, jsou v textu uvedeny.

Definice hromadného zpracování

Hromadným zpracováním se v kontextu FAIS se rozumí zpracování, kdy je technicky zabezpečeno zpracování více než jednoho volání ISSS nebo ISZR na základě jednoho vstupního požadavku do FAIS.

Jednotlivá volání ISSS, respektive ISZR musí být v rámci zpracování jednoho hromadného požadavku na sobě nezávislá, tj. musí být proveditelná v libovolném pořadí, respektive souběžně.

Hromadné zpracování je určeno pro provedení více volání ISSS respektive ISZR, kdy je v rámci každého volání zpracováván právě jeden subjekt. Subjektem se rozumí buď subjekt vedený v ROB (identifikovaný jeho AIFO) nebo subjekt vedený v ROS (identifikovaný jeho IČO).

V rámci hromadného zpracování jsou podporovány operace jednoho typu, tj. buď zápis, nebo čtení, nad jedním typem subjektu a v jednom kontextu.

V rámci hromadného zpracování budou existovat logická omezení oproti případnému řešení na straně AIS. Tato omezení jsou vyvážena zjednodušením a zefektivněním procesu zpracování, omezením rizik přetížení ISSS a ISZR, a zjednodušením implementace na straně AIS v oblasti hromadného zpracování.

Přínosy hromadného zpracování

Hromadné zpracování bude generovat přínosy na prakticky všech stranách zúčastněných v procesu zpracování:

  • Pro ISSS a ISZR bude přínosem optimalizace procesu, snížení nutné zátěže systému a omezení rizik přetížení těchto systémů.
  • Pro AIS žadatelů bude přínosem zjednodušení implementace procesu generování hromadných požadavků. Na straně AIS žadatelů nebude nutné řešit mechanismy řídící zátěž vůči ISSS a ošetřovat chybové stavy plynoucí z potenciálních problémů přetížení ISSS, požadavky AIS budou zpracovány optimálně.
  • Pro AIS poskytovatelů služeb prostřednictvím ISSS (PAIS a AISSÚ) bude výsledkem implementace omezení potenciálních rizik plynoucích z generování současné zátěže z více AIS žadatelů, tzn., že požadavky budou přicházet řízeně.
Omezení hromadného zpracování

Zpracování hromadných požadavků bude mít následující základní omezení:

  • Předávání dat prostřednictvím souborů, případně vyzvednutí souboru na ISSS si musí zajistit žadatel voláním služby ISSS.
  • Nelze provést současnou specifikaci primární entit různých typů (subjekt ROB a subjekt ROS).
  • Velikost požadavku je omezena maximální možnou velikostí volání webové služby (bude definováno v provozních parametrech služby), respektive maximální možnou velikostí datové zprávy.
Princip hromadného zpracování

Z principu je hromadné zpracování asynchronní proces, zpracování řídí FAIS dle aktuálního provozního stavu systému. V procesu hromadného zpracování existují z pohledu žadatele dva kroky:

  • Předání hromadného požadavku a obdržení potvrzení o jeho přijetí FAIS
  • Získání odpovědi
Předání hromadného požadavku

Předání požadavku na hromadné zpracování může být provedeno buď voláním webové služby nebo datovou zprávou prostřednictvím ISDS. Na následujícím diagramu je znázorněn proces předání požadavku ke zpracování.

Obsah obrázku text, diagram, Plán, Paralelní Popis byl vytvořen automaticky

Popis procesu pro jednotlivé vstupní rozhraní je uveden v následujících podkapitolách.

Identifikátor hromadného požadavku

Každému hromadnému požadavku bude na vstupu FAIS přidělen globální identifikátor transakce. Účelem tohoto identifikátoru bude kromě jednoznačné identifikace v rámci FAIS také příprava na integraci na jednotné logovací a auditní prostředí RR PPDF.

Tento globální identifikátor transakce bude v rámci procesu zpracování průběžně využíván při předávání požadavků mezi systémy, pokud to bude příslušný systém umožňovat, respektive bude připraven k předání tak, aby byla dodržena koncepce budoucí integrace na jednotné logovací a auditní prostředí RR PPDF.

Formát hromadného požadavku

Hromadný požadavek bude předáván v XML souboru definovaném XSD schématem. Návrh XML je optimalizován pro účely hromadného zpracování.

Základní řídící informace budou definovány typově fixovanou strukturou, vlastní data určená pro hromadné zpracování budou v XML vložena jako CDATA nebo odkazem.

V principu jsou součástí požadavku informace jako identifikace žadatele, identifikace požadované operace, identifikace subjektů, a další datové položky detailně specifikující požadavek na zpracování.

Předání požadavku webovou službou

Základní princip zpracování hromadných požadavků zasílaných webovou službou bude následující:

  • Žadatel odešle na definované rozhraní webové služby požadavek ke zpracování. Požadavek bude předán prostřednictvím XML dokumentu v definovaném formátu, tento XML dokument bude součástí volání webové služby.
  • FAIS provede validaci požadavku s ohledem na způsob doručení webovou službou.
    • Validní požadavky jsou předány do procesu orchestrace, žadatel dostane v odpovědi na volání přidělený identifikátor požadavku a informaci o přijetí.
    • Pro nevalidní požadavky dostane žadatel v odpovědi identifikátor požadavku, informaci o nepřijetí a informaci o důvodu nepřijetí. Zpracování je ukončeno.

Poznámka: požadavky předávané webovou službou mohou obsahovat AIFO pro specifikaci subjektů ROB. Pro případné předání identity subjektů ROB je možné volitelně použít i úložku AIFO (služba ISZR E175 ulozMapaAifo). FAIS je součástí referenčního rozhraní a jako důvěryhodný systém vůči ISZR bude mít automaticky implicitní přístup pro čtení úložky AIFO).

Technická implementace rozhraní webové služby pro příjem HP

V současném stavu referenčního rozhraní PPDF je rozhraní FAIS pro konzumenty dostupné prostřednictvím eGON rozhraní ISZR. Stejným způsobem bude dostupné rozhraní webových služeb FAIS pro zpracování hromadných požadavků.

Poznámka: ISZR zprostředkovává ve stávající architektuře dostupnost FAIS na eGON rozhraní, tento stav bude využit i pro příjem hromadných požadavků. V budoucnu v rámci rozvoje konceptu RR PPDF, kdy bude FAIS integrální součástí referenčního rozhraní, bude možné tento mezikrok vypustit.

Hromadné požadavky budou přijímány prostřednictvím eGON služby E153 iszrZpracujFormular. Tato eGON služba je připravena na příjem obecného XML, prostřednictvím kterého budou zadávány hromadné požadavky. Současně bude možné touto službou získat informace o stavu zpracování HP a výsledek zpracovaného HP.

Předání požadavku datovou schránkou

Základní princip zpracování hromadných požadavků zasílaných přes datovou schránku bude následující:

  • Žadatel odešle do definované technické datové schránky požadavek ke zpracování. Požadavek bude popsán prostřednictvím XML souboru v definovaném formátu, který bude přílohou odeslané datové zprávy.
  • FAIS provede vyzvednutí datové zprávy z technické datové schránky a provede validaci požadavku s ohledem na způsob doručení prostřednictvím ISDS.
    • Validní požadavky jsou předány do procesu orchestrace. FAIS odešle datovou zprávu o přijetí požadavku ke zpracování do datové schránky odesílatele hromadného požadavku, zohlední identifikátory zdrojové DZ, číslo jednací, respektive spisovou značku.
    • Pro nevalidní požadavky je vytvořen PDF a XML protokol o zamítnutí požadavku, který je vložen do výstupní fronty pro odeslání datovou zprávou. Výstup (PDF i XML) obsahuje identifikátor požadavku, informaci o nepřijetí a informaci o důvodu nepřijetí. Zpracování je ukončeno.

Poznámka: požadavky předávané datovou schránkou nesmí obsahovat AIFO pro specifikaci subjektů ROB. Případné předání identity subjektů ROB je možné výhradně úložku AIFO (služba ISZR E175 ulozMapaAifo). FAIS je součástí referenčního rozhraní a jako důvěryhodný systém vůči ISZR bude mít automaticky implicitní přístup pro čtení úložky AIFO.

Stavy zpracování hromadného požadavku

Stavy zpracování hromadného požadavku ve FAIS jsou znázorněny na následujícím obrázku.

Obsah obrázku text, snímek obrazovky, kruh, Písmo Popis byl vytvořen automaticky

Stavy požadavku jsou:

  • Nový – požadavek je vytvořen a čeká na zahájení validace. V principu je relevantní pouze pro požadavky doručené do datové schránky, požadavky doručené webovou službou jsou buď přijaté, nebo zamítnuté.
  • Přijatý – požadavek je validní a čeká na zahájení zpracování.
  • Zamítnutý – požadavek je nevalidní, existuje výsledek s informací o chybě.
  • Probíhá zpracování – pro validní požadavek probíhá zpracování.
  • Zpracovaný – zpracování bylo dokončeno, existuje validní výsledek s informací o výsledku zpracování.

Poznámka: informace o tom, zda byla žadateli, v případě iniciace prostřednictvím ISDS, odeslána DZ o přijetí / zamítnutí / odeslání výsledku bude řešena samostatnými příznaky spojenými s informací o ID DZ, tj. například stav = Zamítnutý, DS o zamítnutí = odeslána + ID DZ. Tyto příznaky se pro iniciaci WS nevyužívají.

Orchestrace zpracování
  • FAIS zajistí optimalizované zpracování požadavku.
  • FAIS předá výsledek zpracování požadovaným způsobem na výstup.

Jednotlivé kroky orchestrace realizované na straně FAIS jsou popsány v následujících kapitolách.

Validace požadavku
Formální validace

V rámci formální validace je zkontrolován formát požadavku (XML) vůči stanovenému schématu – viz kapitoly Formát hromadného požadavku a splnění logických pravidel na obsah požadavku.

V rámci hlavičky požadavku jsou zkontrolovány údaje nutné pro ověření oprávnění, specifikaci požadované operace a řídící informace.

V rámci těla požadavku je zkontrolována provázanost požadované operace, šablony požadavku a optimalizovaných dat. Je ověřena existence a konzistence datových vět v rámci optimalizovaných dat a podobně.

Validace oprávnění

Pro přístup k datům publikovaným prostřednictvím RR je třeba validovat oprávnění žadatele v rámci výkonu agendy. Atributy nutné pro ověření přístupu musí žadatel předat v rámci hlavičky požadavku.

V hlavičce požadavku musí žadatel specifikovat následující údaje:

  • Kód OVM (nebo SPUU)
  • Kód agendy
  • Kód činnosti
  • Kód AIS
  • Subjekt
  • Uživatel
  • Důvod nebo účel

Při validaci oprávnění se ověří, zda údaje uvedené v těle požadavku odpovídají známým informacím:

  • Kombinace OVM/SPUU, agenda, činnost, AIS je vedena v RPP (s využitím služeb online matice oprávnění) a oprávněna využívat požadované údaje v členění dle katalogu RPP.

Dále se ověří, že žadatel vyplnil hodnoty subjekt, uživatel a důvod nebo účel.

Validace požadavku doručeného webovou službou

U požadavků doručených webovou službou se navíc oproti společným validacím ověří, že:

  • Žadatel volající webovou službu (metadata procesu) odpovídá specifikaci v hlavičce. Tj. údaje hlavičky HP odpovídají žadateli o eGON službu (ZadostInfo).
Validace požadavku doručeného přes datovou schránku

U požadavků doručených prostřednictvím ISDS se navíc oproti společným validacím ověří, že:

  • datová schránka odesílatele (metadata procesu) je zapsána pro OVM (SPUU) v ROS z hlavičky HP.
Věcná validace

V rámci věcné validace jsou provedeny podle obsahu řídících dat následující operace:

  • Přečtení seznamu AIFO (hlavička požadavku nebo úložka AIFO)
  • Přečtení seznamu IČO (hlavička požadavku)
  • Ověření údajů hlavičky
  • Ověření existence šablony a datových vět
Zpracování validního požadavku

Validní požadavek je požadavek splňující všechna validační pravidla. Po úspěšném provedení validace je požadavek uložen do interního úložiště FAIS, ze kterého je následně přejímán k dalšímu zpracování.

Interní úložiště validovaných požadavků funguje na principu fronty, ze které jsou položky vybírány ke zpracování orchestrační komponentou (jedna nebo více instancí – v závislosti na dostupné infrastruktuře prostředí a konfiguraci).

Komponenty FAIS a proces zajišťující zpracování hromadných požadavků jsou znázorněny na následujícím obrázku.

Obsah obrázku text, diagram, Plán, Nalepovací papírek Popis byl vytvořen automaticky

Princip zpracování validního hromadného požadavku

FAIS nově obsahuje komponentu (službu) – HPIniciator - zajišťující zpracování validních hromadných požadavků – požadavků ve stavu „Přijatý“.

FAIS provede změnu stavu hromadného požadavku do stavu „Probíhá zpracování“. Následně FAIS dekomponuje vstupní hromadný požadavek na individuální požadavky, u nichž si zaznamená informace o zdrojové hromadné žádosti (čas, celkový počet nutných volání, kontext volání) a tyto dekompozice si uloží ke zpracování).

Komponenta pro individuální zpracování – HPProces - má definovaný počet vláken, ve kterých provádí zpracování individuálních požadavků. Počet těchto vláken je závislý na aktuálním množství HW zdrojů (na kolika HW prostředcích je komponenta spuštěna, jaké má k dispozici systémové zdroje).

Po zpracování všech dekomponovaných požadavků jednoho hromadného požadavku je sestavena hromadná odpověď a hromadný požadavek interně označen jako zpracovaný.

Výsledek zpracovaného hromadného požadavku obslouží k tomu určená samostatná komponenta (služba) FAIS – HPVysledek, která buď připraví výsledek pro proces iniciovaný voláním webové služby, nebo zajistí kroky nutné pro odeslání odpovědi datovou schránkou. Tento proces je popsán v kapitole Předání výsledku zpracování.

Bezpečnostní aspekty zpracování ve FAIS

Princip zpracování je založený na tom, že FAIS zprostředkovává optimalizovaná individuální volání ISSS a ISZR v zastoupení za žadatelské AIS.

V okamžiku zahájení zpracování validního požadavku je z předchozího zpracování ve FAIS zajištěno, že:

  • Požadavek je syntakticky správný
  • Žadatel je oprávněn k volání požadavku prostřednictvím ISSS,

FAIS je v tomto okamžiku součástí interních komponent referenčního rozhraní PPDF a může využít optimalizovaný přístup k ISZR a ISSS na základě prokázání svojí identity obdobně jako již prokazuje svoji identitu ISSS vůči ISZR.

FAIS v aktuálním stavu implementace prokazuje svoji identitu vůči ISZR na základě vlastnictví privátního klíče certifikátu vydaného CA SZR, totožný certifikát bude používán i při komunikaci s ISSS.

Zpracování požadavku a optimalizace výkonu a zátěže na ISZR a ISSS

Optimalizace výkonu a zátěže ISZR a ISSS bude spočívat ve dvou oblastech:

  • Odstranění redundantních kontrol
  • Optimalizace současného volání ISSS (a v důsledku následně ISZR, PAIS a AISSÚ)
Stávající proces zpracování požadavku prostřednictvím ISSS

Proces zpracování jednoho typického volání služby ISSS je následující:

  1. Ověření oprávnění žadatele prostřednictvím eGON služby ISZR
  2. Operace s AIFO na vstupu (úložka AIFO)
  3. Operace s IČO na vstupu
  4. Předání do PAIS / AISSÚ
  5. Operace s AIFO na výstupu (úložka AIFO)
  6. Operace s IČO na výstupu
  7. Čtení AIFO
  8. Čtení IČO

To, které z výše uvedených operací jsou pro konkrétní požadavek provedeny, závisí na datech požadavku. Vždy je provedena minimálně jedna z operací 1, 2, 3, vždy je provedena operace 4, a podle dat jsou provedeny některé z operací 5, 6, 7 a 8.

Uvedený proces je znázorněn na následujícím obrázku.

Obsah obrázku text, diagram, číslo, Paralelní Popis byl vytvořen automaticky

Každé volání služby ISZR, jak je znázorněno i na obrázku výše, vyžaduje samostatné ověření oprávnění (autorizaci) procesem „Přístupová vrstva eGON rozhraní ISZR“.

V případě zpracování hromadných požadavků je počet nutných operací autorizace v ISZR násoben počtem subjektů předávaných v rámci hromadného zpracování, přičemž provedení operace autorizace vyžaduje v ISZR nezanedbatelný čas a konzumuje (s ohledem na počty souběžných volání ISZR obecně) nezanedbatelné množství systémových zdrojů.

Optimalizace redundantních kontrol

V rámci optimalizovaného procesu zpracování na ISSS na základě bezpečně prokázané identity volajícího AIS (vůči ISSS je touto identitou v tomto okamžiku FAIS) lze:

Při volání z FAIS na straně ISSS neprovádět kontrolu oprávnění prostřednictvím služeb ISZR. Při volání ISZR v rámci zpracování požadavku iniciovaném v ISSS prostřednictvím FAIS na straně ISZR neprovádět kontrolu oprávnění interními mechanismy ISZR. ISSS a ISZR pro tyto účely budou na svém rozhraní umožňovat důvěryhodné předání informace o prokázané identitě žadatele a prokázaných oprávněních žadatele.

Princip optimalizace je znázorněn na následujícím obrázku.

Obsah obrázku text, diagram, řada/pruh, Paralelní Popis byl vytvořen automaticky

Namísto opakovaného ověřování oprávnění na všech úrovních je v rámci přípravy implementace koncepce referenčního rozhraní PPDF prováděno předávání informace o prokázané identitě a prokázaných oprávněních, na základě které se lze vyhnout opakovaným komplexním procesům ověřování oprávnění v rámci individuálních voláních mezi komponentami RR PPDF (ISZR, ISSS, FAIS).

Procesy „eGON-d WS *“ tedy postihují modifikaci standardního volání eGON služby zahrnující převzetí a ověření důvěry volajícího.

Poznámka: v případě přímého volání z AIS na ISSS (mimo proces zpracování HP FAIS) provede iniciální kontrolu ISSS a informaci o provedení kontroly předá do ISZR. V procesu zpracování HP je kontrola předsunuta před ISSS a provede se pro každý HP právě jednou.

Optimalizace současného volání ISSS

Optimalizace současného volání ISSS je prováděna na základě dvou skutečností:

  • FAIS v konkrétním okamžiku zná požadavky, které musí prostřednictvím ISSS zpracovat a může tedy zajistit, že sám o sobě nebude generovat zátěž, která by sama o sobě generovala riziko přetížení ISSS (nebo PAIS/AISSÚ).
  • FAIS jako interní komponenta referenčního rozhraní PPDF může optimalizovat volání na základě znalosti aktuálního zatížení ISSS.
  • FAIS při výběru individuálních požadavků ke zpracování vytváří logické fronty pro jednotlivé datové kontexty. Jednotlivé fronty jsou zpracovávány cyklicky. Z každé z těchto front pak vybírá a paralelně zpracovává požadavky tak, aby v konkrétním kontextu nebyla překročena definovaná hranice současného počtu žádostí per kontext. Výběr požadavků z fronty probíhá pseudonáhodně, se zohledněním data doručení hromadného požadavku a pořadí individuálního požadavku tak, aby zpracování jednoho hromadného požadavku nezpůsobilo dlouhodobé odložení zpracování jiných hromadných požadavků.
  • FAIS jako interní komponenta RR PPDF má přístup k aktuálním stavovým informacím ISSS a na základě těchto informací může dynamicky řídit zátěž generovanou vůči ISSS. FAIS získává aktuální informace o stavu zátěže v rámci zpracování jednotlivých požadavků a tyto informace pak bere v úvahu při výběru dalších požadavků čekajících na zpracování.

Parametry pro optimalizaci známé při běhu:

  • P - Aktuální počet dekomponovaných požadavků zpracovávaných v ISSS
  • Pk - Aktuální počet dekomponovaných požadavků na kontext v ISSS
  • I – Aktuální průměrná zátěž ISZR
  • Omezující parametry pro optimalizaci:
  • M – Maximální počet paralelních požadavků vůči ISSS
  • Mk – Maximální počet paralelních požadavků na kontext v ISSS
  • Imax – Maximální zátěž ISZR včetně FAIS HP
  • Počet požadavků, pro které FAIS v daném okamžiku zahájí zpracování:
  • S = Imax – I – P

Zpracování je zahajováno periodicky v definovaných intervalech (konfigurace – řádově sekundy)

Prioritizace požadavků

FAIS v této popisované verzi nepodporuje funkci prioritizace hromadných požadavků.

Prioritizace spočívá v zavedení vhodných mechanismů pro výběr pořadí, v jakém jsou požadavky vybírány ke zpracování. V současné době nejsou jasné požadavky na způsob prioritizace a implementace mechanismů by byla založena na více či měně uměle smyšlených potřebách. Podporu prioritizace bude možné implementovat v budoucnu.

Ošetření výsledku operace

V rámci zpracování výsledku volání ISSS ošetřuje FAIS chybové stavy, které je možné z principu ošetřit na jeho úrovni. Jde o následující stavy:

  • Nedostupnost ISSS
  • Nedostupnost ISZR (v rámci zpracování na ISSS)
  • Nedostupnost PAIS/AISSÚ (v rámci zpracování na ISSS).
  • Ošetření těchto stavů řeší FAIS dočasným pozastavením zpracování v úrovni, která příslušnému stavu odpovídá.
  • V případě nedostupnosti ISSS nebo ISZR pozastavuje FAIS kompletně zpracování hromadných požadavků. Znovuspuštění po zastavení se provádí automaticky pokusem o opakované provedení nejstaršího čekajícího individuálního požadavku.

Poznámka: nedostupnost rozhraní ISZR anebo ISSS je vždy dočasná provozní záležitost, tj. tato událost se ošetří automaticky a není třeba provádět další činnosti. Žadatel, pokud má pochybnosti, může získat informaci o stavu zpracování.

Informace o stavu zpracování je dostupná v administraci FAIS a je možné ji monitorovat prostřednictvím standardních dohledových nástrojů v rámci provozní infrastruktury, viz kapitola Provozní monitoring.

Ostatní chybové stavy jsou propagovány do výsledku zpracování hromadného požadavku pro zdrojový AIS.

Sestavení výsledku pro předání žadateli

Výsledek odpověď pro předání žadateli je dán sjednocením jednotlivých odpovědí individuálních požadavků.

Takto sestavená odpověď, pokud by byla řešena jedním „dokumentem“, by však mohla překročit technické limity pro předání odpovědi prostřednictvím podporovaných rozhraní. Toto FAIS ošetřuje zavedením možnosti dělení odpovědi na části při předání výsledku.

Interně tedy FAIS výsledek nesestavuje průběžně při zpracování ani při dokončení všech individuálních požadavků, ale připravuje jej až v okamžiku, kdy je předáván žadateli, způsob sestavení je uveden v kapitole Předání výsledku zpracování v členění podle možných způsobů předání.

Předání výsledku zpracování
Formát výsledku

Technický výsledek je vždy předáván jako XML dokument, který se skládá z hlavičky, popisující předávaná data a z datové části obsahující výsledky zpracování individuálních požadavků.

V hlavičce je uvedeno:

  • Identifikátor hromadného požadavku
  • Datum, čas a výsledek zpracování
  • Identifikátor výsledku, pořadí výsledku a celkový počet výsledků (počet výsledků je větší než jedna v případě, kdy je překročeno technické omezení pro velikost předávaných dat).
Předání AIFO na výstupu

Seznam AIFO je předáván v případě, že je ve výstupu alespoň jednoho individuálního požadavku uvedena neprázdná MapaAifo.

Předání může být provedeno dvěma způsoby, přičemž pro hromadný požadavek iniciovaný datovou zprávou připadá v úvahu pouze jeden z těchto způsobů:

  • Předání v MapaAifo (pouze pro HP iniciované webovou službou)
  • Předání prostřednictvím úložky AIFO
  • Volbu způsobu předání volí žadatelský AIS při iniciaci HP (viz Řídící data).
  • V případě předaní prostřednictvím MapaAifo obsahuje výstup seznam MapaAifo, kde je každá položka seznamu vázána na konkrétní individuální požadavek prostřednictvím gsbZadostId.
  • V případě předání prostřednictví úložky AIFO obsahuje výstup seznam ID úložek AIFO, kde je každá položka seznamu vázána na konkrétní individuální požadavek prostřednictvím gsbZadostId.

Poznámka: MapaAifo jednotlivých individuálních výsledků nejsou na výstupu slučována do jedné množiny, protože každá odpověď má individuální vazbu.

Předání výsledku webovou službou

Zpracování HP je z pohledu AIS žadatele asynchronní proces. Získání výsledku zpracování HP si ošetřuje žadatelský AIS ve vlastní režii voláním FAIS (popis rozhraní FAIS viz kapitola Rozhraní WS FAIS pro hromadné požadavky) prostřednictvím eGON služby ISZR E153.

Poznámka: WS služby FAIS jsou pro konzumenty zprostředkovány prostřednictvím eGON služby ISZR E153.

Vyzvednutí výsledku žadatelem

V kompetenci AIS žadatele je dotaz na stav zpracování HP. Prostřednictvím WS může AIS žadatele jednak číst stav zpracování HP, jednak získat výsledek zpracování.

AIS žadatele kontroluje periodicky stav zpracování hromadného požadavku. Podle aktuálního stavu zpracování pak přizpůsobuje četnost kontroly.

Periodické čtení stavu a omezení četnosti volání

FAIS implementuje interní mechanismy na řízení zátěže při zpracování HP. Jedním z těchto mechanismů je ochrana proti nadměrnému přetěžování při získávání informací o stavu zpracování, respektive při pokusech o vyzvednutí výsledku dosud nezpracovaného požadavku.

V případě zjištění opakovaného volání operací dotazu na stav požadavku, respektive čtení odpovědi dosud nedokončeného požadavku může FAIS operaci odmítnout bez zahájení jejího provádění.

Důvod odmítnutí z důvodu nadměrného opakování bude uveden v odpovědi pro volající AIS v souladu s implementací požadavku na řízení zátěže na externím rozhraní ISZR.

Podpora asynchronního PUSH režimu na ISSS

Speciální funkcionalitou rozšiřující zpracování HP je podpora asynchronního PUSH režimu ISSS.

FAIS bude podporovat asynchronní režim ISSS s podporou aktivního doručení odpovědi do AIS. V tomto režimu zajistí FAIS iniciaci všech individuálních požadavků na ISSS v asynchronním PUSH režimu, přičemž konzumentem PUSH operace výsledku bude přímo AIS žadatele.

V tomto režimu bude výsledek zpracování individuálního požadavku doručen na žadatelský AIS přímo z ISSS. AIS obdrží výsledek individuálního zpracování ihned po zpracování na ISSS a nemusí čekat na dokončení kompletního zpracování ve FAIS.

Tento režim je řízen prostřednictvím specifikace v řídících datech HP, viz kapitola Identifikace operace.

Příjem asynchronního výsledku z ISSS je standardně definován v dokumentaci ISSS (chování, požadavky na AIS na vystavení cílového bodu pro příjem výsledku, jeho registraci v ISSS , atd.).

Poznámka: ISSS současně s dokončením asynchronního zpracování kromě odeslání výsledku na žadatelský AIS notifikuje o dokončení zpracování i FAIS, viz kapitola Notifikace z ISSS o dokončení individuálního požadavku. V případě neúspěchu notifikace ISSS notifikuje individuální požadavky do FAIS opakovaně v definovaných intervalech, přičemž v případě detekce dočasného selhání konektivity je proces notifikace na straně ISSS uspán a probuzen po definované době.

Předání výsledku datovou zprávou

Výsledek je předán datovou zprávou do datové schránky, ze které byla žádost provedena.

Při předání výsledku je podporována vazba prostřednictvím čísla jednacího, respektive spisové značky, pokud je žadatel specifikoval v jím zaslané iniciační datové zprávě.

Požadavek zpracován

Pokud bude provedena alespoň jedna požadovaná operace, pak bez ohledu na její výsledek bude do výstupní datové zprávy předáno definované XML s výsledkem zpracování.

V případě, že by velikost výsledku překročila maximální povolenou velikost, bude předání provedeno ve více datových zprávách, z XML je patrná informace o rozdělení, aktuální části a celkovém počtu datových zpráv, ze kterých se skládá výsledek.

Požadavek nezpracován

Pokud nebude možné z nějakých důvodů požadavek zpracovat, tzn., že nebude provedena žádná požadovaná operace, bude výstupní datová zprava obsahovat PDF s popisem chyby a současně XML v definované struktuře, obsahující informaci o chybě.

Provozní podpora zpracování hromadných požadavků
Stav zpracování požadavku pro žadatele

Informace o stavu zpracování hromadného požadavku lze získat jak pro požadavky iniciované prostřednictvím webové služby, tak pro požadavky iniciované prostřednictvím datové zprávy. Při čtení informace o stavu hromadného zpracování musí být na vstupu uveden minimálně buď:

  • Identifikátor hromadného požadavku zadaný z AIS (musí být jedinečný v rámci AIS, zabezpečuje AIS).
  • Identifikátor přidělený identifikátor žádosti ve FAIS
  • Identifikátor vstupní datové zprávy (pro žádosti doručené přes ISDS).

Pro získání informace o stavu zpracování je možné použít pouze rozhraní webových služeb. Popis je uveden v kapitole Dotaz na stav požadavku.

Přehled hromadných požadavků

V uživatelském rozhraní FAIS (řídící pult FAIS) je možné zobrazovat přehled hromadných požadavků.

Primárním cílem tohoto přehledu je podpora provozu, pro zobrazení výstupu bude nutné zadat filtry pro zobrazení.

Požadavky bude možné vyhledat:

  • Dle identifikátoru konkrétní operace na vstupu, ve FAIS, v ISZR nebo v ISSS
  • Dle identifikátoru datové zprávy
  • Dle identifikátoru volání webové služby
  • Dle data doručení do DS nebo přijetí WS
  • Zobrazit dosud nedokončené požadavky
Provozní monitoring
API pro provozní monitoring

FAIS v souvislosti s implementací hromadného zpracování vystavuje pro infrastrukturní nástroje monitorovací rozhraní, prostřednictvím kterého lze průběžně monitorovat provozní stav FAIS. V rámci tohoto rozhraní jsou dostupné informace:

  • Stav komunikace FAIS s ISSS/ISZR (dostupný / nedostupný)
  • Stav komunikace ISSS s PAIS/AISSÚ (dostupný / nedostupný)
  • Stav logických front pro jednotlivé kontexty (fronta, počet čekajících požadavků, čas nejstaršího a nejnovějšího požadavku)
  • Počty hromadných požadavků seskupené dle stavu požadavku

Monitorovací rozhraní je dostupné prostřednictvím http protokolu v rámci interní sítě.

Rozhraní tohoto API je dostupné na adrese IszrFaisHPMon/Full v rámci webového rozhraní webových služeb FAIS. Výstupní formát rozhraní je JSON.

Provozní monitoring v ŘP FAIS

Informace o provozním stavu vystavované prostřednictvím API pro provozní monitoring (popsané v předchozí kapitole API pro provozní monitoring) jsou dostupné i v uživatelském rozhraní FAIS.

V ŘP FAIS jsou výše popsané informace dostupné v menu Monitoring / Hromadné požadavky.

Pravidla referenčního rozhraní

Detailní průvodce připojení k referenčnímu rozhraní veřejné správy je uveden zde https://pruvodcepripojenim.gov.cz/

Způsob získání referenčních údajů

Webové služby

Prostřednictvím webových služeb může subjekt čerpat referenční údaje ze ZR. Subjekt, který působí v agendě, má tuto agendu řádně ohlášenou v RPP, má zaregistrovaný svůj agendový informační systém (také jako AIS) a vydaný platný certifikát od správy základních registrů (také jako SZR), přičemž na čerpání údajů musí mít vlastní zákonné zmocnění ve svém zákoně a dle zákona č.111/2009 Sb., o základních registrech, je tento subjekt oprávněn čerpat referenční údaje ze ZR prostřednictvím vnějších služeb informačního systému správy základních registrů (také jako ISZR).

Pro získávání referenčních údajů webovými službami je nezbytné nejdříve ztotožnit svůj datový kmen vůči ZR a následně se přihlásit pro příjem notifikací o změnách.

Czech POINT

Zkratka Czech POINT znamená Český Podací Ověřovací a Informační Národní Terminál. Jde o kontaktní místo veřejné správy, které poskytuje občanům zejména ověřené údaje vedené v centrálních registrech, jako jsou rejstřík trestů, obchodní rejstřík nebo registr živnostenského podnikání. Kromě standardních služeb, lze využít výpisy ze základních registrů podle zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů. Občané tak mají možnost ověřit si údaje, které jsou o nich v registrech vedeny, úředníci pak mají prostřednictvím formulářů v části CzechPOINT@office přístup k referenčním údajům ze základních registrů.

Jedním z cílů zavádění je zrychlit, zpřístupnit a zefektivnit služby občanům a dalším subjektům. Czech POINT je tedy kontaktním místem veřejné správy, které umožňuje na jediném místě získávat výpisy nebo činit podání.

Informační systém datových schránek

Pomocí datových schránek je možné zasílat dokumenty v elektronické podobě orgánům veřejné moci a také je takto od nich přijímat.

Komunikace prostřednictvím datových schránek nahrazuje klasický způsob doručování v listinné podobě, protože zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, zrovnoprávňuje papírovou a elektronickou verzi zasílaného dokumentu. Orgánům veřejné moci a právnickým osobám jsou datové schránky zřízeny automaticky, všem ostatním na základě jejich žádosti. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů.

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

Fyzické osoby (občané) mají možnost žádat o výpisy ze základních registrů prostřednictvím datové schránky na svém personalizovaném účtu portálu občana, pokud mají na portálu občana zřízenou datovou schránku a připojenou do svého profilu. Do portálu občana je možné se přihlásit datovou schránkou, jménem – heslem – SMS nebo elektronickou občankou s čipem, vydávanou od 1. 7. 2018.

Kdo může žádat o referenční údaje ze ZR

Webové služby

Subjekt státní správy svým AIS, který má zákonné zmocnění ve svém zákoně využívat referenční údaje ze ZR, působící v řádně ohlášené agendě v registru práv a povinností a má vydaný platný certifikát od správy základních registrů pro přístup do ZR. Dále soukromoprávní subjekt práva zprostředkovaně přes AIS některého z orgánu veřejné moci, který má opět zákonné zmocnění využívat údaje ze základních registrů v rámci přidělené agendy řádně ohlášené v RPP.        

Czechpoint

Na kontaktním místě, dle typu jednotlivých formulářů, které jsou v rámci Czechpoint k dispozici, může žádat fyzická, podnikající fyzická osoba i právnická osoba. Bližší informace, kdo může žádat u jednotlivého typu formuláře je k dispozici v sekci Typy žádostí pro získání referenčních údajů ze ZR.

Informační systém datových schránek

Informační systém datových schránek je prostředek pro získávání referenčních údajů ze základních registrů formou zaslání jednoho z formulářů v sekci  Typy žádostí pro získání referenčních údajů ze ZR. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů. Ostatní subjekty si mohou datovou schránku zřídit volitelně.

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

Žádat o výpis údajů ze základních registrů v rámci portálu občana má možnost podat každá fyzická osoba (občan), která má na svém personalizovaném účtu portálu občana zřízenou datovou schránku připojenou ke svému profilu. V rámci portálu veřejné správy, má možnost podat žádost o získání referenčních údajů ze základních registrů každý subjekt, který je uveden v sekci Typy žádostí pro získání referenčních údajů ze ZR, dle typu žádosti.    

Typy žádostí pro získání referenčních údajů ze ZR

Žádost o výpis údajů z registru obyvatel – dle § 58 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny.
  • Za subjekt práva podle § 58 odst. 9 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů, může žádat jeho zákonný zástupce.
  • Za subjekt práva může žádat zmocněnec na základě plné moci s úředně ověřeným podpisem zmocnitele.

Žádost o veřejný výpis údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat jakákoliv fyzická osoba (nemusí být subjektem práva).
  • Žádat lze o poskytnutí údajů o jakékoliv podnikající fyzické osobě, právnické osobě nebo orgánu veřejné moci.
  • Ve výpisu se objeví všechny údaje jako v neveřejném výpisu (viz níže) kromě osobních údajů osob, které jsou ve vazbě na registr obyvatel.

Žádost o výpis (neveřejný) údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny v registru osob.

Žádost o záznam o využívání údajů v registru obyvatel – dle § 14 zák. č.111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny v registru obyvatel.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá fyzická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru obyvatel automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.
  • Informace, jak číst záznam o využívání údajů naleznete v praktické příručce: viz http://www.szrcr.cz/obcan-a-podnikatel

Žádost o záznam o využívání údajů v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá podnikající fyzická a právnická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru osob automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru obyvatel – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru obyvatel může žádat subjekt práva (fyzická osoba).
  • Na základě žádosti dojde k podání návrhu na změnu referenčních údajů vedených o subjektu práva v registru obyvatel.
  • Dojde-li ke změně referenčního údaje, obdrží fyzická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru osob může žádat subjekt práva (podnikající fyzická osoba nebo statutární orgán právnické osoby).
  • Na základě žádosti podává žadatel návrh na změnu referenčních údajů vedených o osobě v registru osob.
  • O změnu údajů při zjištění nesouladu v registru osob může žádat podnikající fyzická osoba nebo statutární orgán právnické osoby.
  • Dojde-li ke změně referenčního údaje, obdrží každá podnikající fyzická nebo právnická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti poskytne subjekt práva (fyzická osoba) své údaje jiné fyzické nebo právnické osobě.
  • Těmto je možné poskytnout všechny nebo vybrané údaje vedené k Vaší osobě v registru obyvatel.
  • Orgánu veřejné moci není nutné poskytnout Vaše údaje tímto způsobem, neboť tento má povinnost si referenční údaje zjistit.

Žádost o odvolání poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti přestanou být poskytovány Vaše údaje jiné fyzické nebo právnické osobě. Dojde k odvolání Vámi vybraných předchozích souhlasů s poskytnutím údajů třetí osobě učiněných žádostí výše.
Poplatky spojené s žádostmi o výpisy
  • Portál občana a portál veřejné správy – podání žádostí datovou schránkou využitím formulářů uveřejněných na Portálu občana a portálu veřejné správy a vydání výpisů je bezplatné.
  • Czech POINT – žádosti podané prostřednictvím kontaktního místa veřejné správy Czech POINT jsou zpoplatněny, avšak podání žádostí o změnu referenčních údajů a poskytnutí/odvolání poskytnutí referenčních údajů třetí osobě jsou bezplatné.

Povinnost využívat referenční rozhraní

Povinnost využívat referenční rozhraní pro uskutečňování takzvaných "vazeb" mezi jednotlivými informačními systémy veřejné správy ukládá zákon o informačních systémech veřejné správy. Tedy obecně platí, že pro sdílení údajů, výměnu údajů a propojování jednotlivých informačních systémů veřejné správy různých správců, má být primárně využíváno právě referenční rozhraní. U informačních systémů stejného správce toto nemusí platit vždy, pokud se nevyužívá překlad agendových identifikátorů při komunikaci o subjektu práva vedené v rámci dvou nebo více agend.

Je nutné zdůraznit, že pouze využitím referenčního rozhraní je korektně prováděn překlad AIFO (AIFO jedné osoby v jedné agendě nesmí být poskytnuto jiné agendě). Pouze referenční rozhraní je napojeno na registr ORG a provádí překlad AIFO.

Možnost využívat referenční rozhraní

Mimo povinnost pro správce informačních systémů veřejné správy, je zde i možnost využití referenčního rozhraní, resp. služeb, které poskytuje, i pro jiné subjekty. Konkrétně jde o subjekty typu SPUÚ (Soukromoprávní uživatel údajů) dle zákona 111/2009 Sb., kteří pro využití služeb referenčního rozhraní potřebují zákonné zmocnění.

Užívání referenčního rozhraní při výměně údajů v rámci propojeného datového fondu

Výměna/sdílení údajů mezi jednotlivými informačními systémy veřejné správy se realizuje výhradně prostřednictvím referenčního rozhraní, a to konkrétně komponenty eGSB/ISSS. Jak se upřesňuje v části propojený datový fond, tak výměna údajů se realizuje vždy v rámci kontextu na subjekt práva.

Přístup ke službám referenčního rozhraní je na síťové úrovni možný pouze prostřednictvím Centrálního místa služeb (CMS), potažmo komunikační infrastruktury veřejné správy (KIVS), které můžeme nazvat privátní sítí pro výkon veřejné správy na území státu.

Správci agendových informačních systémů musejí realizovat napojení na referenční rozhraní, a to podle příslušných metodických dokumentů a provozních řádů:

Užívání referenčního rozhraní pro čerpání referenčních údajů

Správci agendových informačních systém se kromě provozních řádů řídí i dalšími postupy a to především legislativními. Současný stav (rok 2020) stále nutí k zákonnému zmocnění pro využívání referenčních údajů. V

Užívání referenčního rozhraní pro poskytování agendových údajů

Správci agendových informačních systémů poskytujících údaje z daných agend realizují napojení svých AISů na eGSB/ISSS v roli publikátora a kontrolu oprávnění k využívání údajů podle oprávnění v RPP. Pro výměnu údajů vybudují služby svého AIS tak, aby mohly být volány a zprostředkovány eGSB/ISSS.

Užívání referenčního rozhraní pro čerpání agendových údajů

Správci agendových informačních systémů využívajících údaje poskytované jinou agendou realizují volání služeb eGSB/ISSS (nemusí znát konkrétní AIS, požadují údaje od agendy), a to jen tehdy, pokud k tomu mají příslušné oprávnění zapsané u agendy poskytovatele v RPP.

Užívání referenčního rozhraní při zápisu a editace údajů v základních registrech

Editoři referenčních údajů v základních registrech realizují napojení svých editorských agendových informačních systémů na ISZR službami vnějšího rozhraní podle příslušné dokumentace Správy základních registrů a v případech, kdy agendové informační systémy nejsou též samostatnými evidencemi dokumentů, pak napojení těchto systémů na eSSL v rámci vnitřních vazeb. Pro editaci údajů a vyřizování reklamací údajů v základních registrech nevyužívají jiné rozhraní než právě ISZR.

Referenční údaje

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

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

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

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

Základní povinnosti editora tedy jsou:

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

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

Virtuální referenční údaje

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

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

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

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

Údaje typu indikátor

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

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

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

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

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

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

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

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

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

Proces reklamace správnosti údaje

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

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

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

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

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

Registr obyvatel

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

Subjekty údajů vedených v registru obyvatel jsou

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

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

  • 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

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

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

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

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

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

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

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

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

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

Editory údajů jsou:

Název osoby Typ osobyAgendaEditor ROS
Advokáti FO A8 Česká advokátní komora
Agentury práce FO A531 Ministersvo práce a sociálních věcí
Akreditovaná osoba podle zákona o spotřebitelském úvěru FO A11 Česká národní banka
Auditoři FO A6 Komora auditorů České republiky
Auditoři bezpečnosti pozemních komunikací FO A1381 Ministerstvo dopravy
Autorizovaní architekti FO A54 Česká komora architektů
Autorizovaní inženýři a technici FO A54 Česká komora autorizovaných inženýrů a techniků činných ve výstavbě
Církve a náboženské společnosti PO A5 Ministerstvo kultury
Česká národní banka, Česká televize, Český rozhlas, Regionální rada regionu soudržnosti, Všeobecná zdravotní pojišťovna PO A325 Ministerstvo vnitra
Daňoví poradci FO A7 Komora daňových poradců ČR
Dobrovolné svazky obcí PO A343 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Držitelé licencí pro podnikání v energetických odvětvích FO A684 Energetický regulační úřad
Evropská seskupení pro územní spolupráci PO A561 Ministerstvo pro místní rozvoj
Fyzické osoby - provozovatelé poštovních služeb FO A926 Český telekomunikační úřad
Fyzické osoby provozující živnost (živnostníci) FO A121 Místně příslušný živnostenský úřad
Honební 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í organizacePO A120 Místně příslušný rejstříkový soud

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

Registr práv a povinností

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.

Registr územní identifikace adres a nemovitostí

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ů.

Sdílené agendové IS pro samostatnou působnost

Popis Sdílených agendových IS pro samostatnou působnost

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

Pravidla Sdílených agendových IS pro samostatnou působnost

OVS, které musí vybudovat IT podporu pro samosprávné agendy a mají pro to k dispozici potřebné zázemí (infrastrukturu, kapacity, znalosti), typicky ORP (zejména statutární města a bývalá okresní města) nebo kraje, mohou poskytnout podporu v malým obcím (1. a 2. typu) ve svém správním území. A to za podmínek daných změnami legislativy, ke kterým bude muset pro plnou realizaci tohoto konceptu dojít. Stejná forma sdílení je možná mezi těmito úrovněmi samosprávy i v případě spisové služby a provozních systémů, pokud malé obce nevyužijí možnosti sdílení centrálních služeb, budou-li k dispozici.

NAP doporučuje municipalitám pro určitou dílčí sadu sdílených služeb použít jako základní prvek správní obvody ORP a vychází z následujících předpokladů:

  • ORP jsou nejmenšími subjekty, které zpracovávají architektonický plán.
  • Správní obvod ORP je jednoznačně dán a všechny subjekty, kterých se bude sdílení ve správním obvodě týkat, jsou známy.
  • Poskytování služeb a dat je určeno standardy (např. u spisové služby).
  • Tento model již v řadě ORP funguje.

Pro jiné sdílené služby (například dlouhodobé ukládání dokumentů v elektronických digitálních spisovnách) se mohou využít technologická centra krajů, neboť:

  • Mají vybudovanou infrastrukturu
  • Disponují IT kapacitami a kompetencemi

Pro další sdílené služby, například pro aplikační služby ekonomických systémů nebo spisových služeb, bude možné v dohledné době 3 let (2022) využít SaaS služby eGovernment Cloudu, protože:

  • Procesy a o IT potřeby v těchto oblastech fungování samospráv jsou vysoce standardizované a opakovatelné, proto jsou velmi vhodné pro řešení v cloudu
  • Tyto funkce a jejich podpora zůstávají v plné zodpovědnosti obcí, a proto tyto potřebují multi-tenantní řešení

Sdílené aplikační služby kraje

Doporučujeme, aby kraje pro obce zřídily a poskytovaly služby například informačního systému spisové služby.

Krajské sítě

Publikace služeb krajských center do krajské sítě a dále přes krajský konektor do CMS.

Sdílené aplikační, technologické a síťové služby ORP

Malé obce, typicky všechny obce prvního a druhého typu, provozující méně než 10 přístupových zařízení, jsou zproštěny povinnosti zajišťovat informatizaci svých služeb veřejné správy a svůj podíl na eGovernmentu vlastními silami.

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

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

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

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

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

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

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

Popis Sdílených provozních informačních systémů

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

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

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

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

Státní pokladna má před sebou několik možných směrů rozvoje, například integraci na nákupní řešení, na Registr smluv nebo podporu controllingu (nákladové, manažerské účetnictví) veřejné správy.

Monitor Státní pokladny je specializovaný informační portál Ministerstva financí, který umožňuje veřejnosti volný přístup k rozpočtovým a účetním informacím ze všech úrovní státní správy a samosprávy. Prezentované informace pocházejí ze systému Státní pokladny a Centrálního systému účetních informací státu a jsou čtvrtletně aktualizovány. Monitor zahrnuje grafickou webovou část, analytickou část a strojově čitelná zdrojová data.

Centrální registr administrativních budov (CRAB) má vyřešit dosavadní absenci aktuálního celostátního přehledu o administrativních objektech v majetku státu, o jejich obsazenosti a dislokaci státních zaměstnanců. Registr na základě získaných informací umožní maximální využití státních objektů. Ve své činnosti se opírá o Usnesení vlády České republiky ze dne 20. prosince 2012 č. 954 o Centrálním registru administrativních budov.

Informační systém CEDR jako celek je nástrojem zejména pro poskytování, evidenci a kontrolu dotací a pro výkon řady s tím souvisejících agend. Systém se skládá z řady vzájemně provázaných subsystémů, které jsou provozovány na MF- GFŘ, resortech, agenturách a územních orgánech finanční správy.

V informačním systému CEDR jsou shromažďovány údaje o všech dotacích a návratných finančních výpomocích ze státního rozpočtu, státních fondů, státních finančních aktiv a Národního fondu a jejich příjemcích na základě Usnesení vlády č. 584/1997Sb. (subsystém CEDRIII).

  • CEDR - resorty: Údaje jsou do IS CEDR zaznamenávány buď pomocí subsystému CEDR - resorty, který mohou využívat všichni poskytovatelé dotací, nebo prostřednictvím jiných informačních systémů, ve kterých jsou všechny požadované údaje také shromažďovány (např. EDS/SMVS, MSC2007). Předávání údajů do IS CEDR ukládá zákon č. 218/2000 Sb., o rozpočtových pravidlech, §75. Lhůty pro předávání dat a povinné položky stanoví vyhláška č. 296/2005 Sb., o centrální evidenci dotací.
  • CEDR II - Kontrolní útvary FÚ - Všechny údaje, shromážděné v IS CEDR III, jsou předávány do subsystému CEDR II, který využívají kontrolní útvary finančních úřadů. CEDR II proto obsahuje i moduly pro podporu evidence kontrol a vymáhání nedoplatků nebo částek, které mají být vráceny v případě zjištění porušení rozpočtové kázně. Informace o výsledcích provedených kontrol jsou na vyžádání zpřístupněny příslušným poskytovatelům dotací.
  • CEDR III - Veřejnost: Veřejné údaje z databáze CEDR jsou zpřístupněny prostřednictvím subsystému CEDR – web na Internetu MF, který umožňuje i tvorby sestav a výběrů.

ISPROFIN-EDS/SMVS - Informační Systém PROgramového FINancování (ISPROFIN) je manažerský systém pro řízení a kontrolu čerpání položek státního rozpočtu. Dělí se na:

  • EDS - Evidenční Dotační Systém eviduje a řídí poskytování návratných finančních výpomocí a dotací ze státního rozpočtu na pořízení nebo technické zhodnocení dlouhodobého hmotného a nehmotného majetku
  • SMVS - Správa Majetku ve Vlastnictví Státu řídí poskytování prostředků ze státního rozpočtu na pořízení nebo technické zhodnocení hmotného a nehmotného dlouhodobého majetku státu.

MS2014+ - Informační systém MS2014+, oficiální monitorovací systém evropských strukturálních a investičních fondů (ESIF) pro programové období 2014 -2020. Je určen k procesnímu i datovému zabezpečení kompletního řízení a administrativních procesů nad projekty dotačních programů ze strukturálních fondů EU v České republice v programovém období 2014 - 2020.

Funkcionalita systému Monit2014+ pokrývá veškeré základní procesy životního cyklu dotačních programů i v rámci nich realizovaných konkrétních projektů.

Monit2014+ je napojen řadou rozhraní na desítky informačních systémů státní správy České republiky i Evropské unie podílejících se na implementaci dotačních programů EU.

Centrální systém nákupu a veřejných zakázek

Národní elektronický nástroj (NEN), jako klíčový prvek soustavy Národní infrastruktury pro elektronické zadávání veřejných zakázek (NIPEZ), je komplexní elektronický nástroj pro administraci a zadávání veřejných zakázek a koncesí pro všechny kategorie veřejných zakázek a všechny kategorie zadavatelů, vč. sektorových. NEN podporuje všechny rozsahy elektronizace od evidence zadávacích řízení po plně elektronické postupy.

NEN umožní provázání (elektronickou procesní integraci) na interní systémy zadavatelů i dodavatelů či systémy eGovernmentu v ČR. Plně podpoří plánovací aktivity, neboť často bude využíván pro veřejné zakázky realizované v rámci dlouhodobých investičních projektů.

Pro operace relevantní pro Státní rozpočet musí být NEN integrován jak na lokální rozpočetnictví úřadů, tak zejména na RIS-PR a RIS-RE z IISSP.

Uživatelské rozhraní NEN musí být zařazeno do centrálního Portálu úředníka (PÚ), dostupného pro ty OVS, pro něž by bylo nehospodárné budovat svůj lokání PÚ. Dále musí být uzpůsobeno tak, aby jej ostatní OVS jako jednu z mnoha centrálních služeb mohly řady zařadit do svých lokálních Portálů úředníka (Intranet).

Uživatelé NEN se k němu musí přihlašovat pomocí JIP. To znamená klienti VS (dodavatelé) pomocí NIA a úředníci pomocí JIP/KAAS.

Pravidla Sdílených provozních informačních systémů

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Sdílené statistické, analytické a výkaznické systémy

Popis Sdílených statistických, analytických a výkaznických systémů

Statistické, analytické a výkaznické systémy systémy (existující i plánované) budou zahrnuty po zpracování podkladů od věcných správců.

Pravidla Sdílených statistických, analytických a výkaznických systémů

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

Sdílení údajů veřejné správy ČR

Orgány veřejné moci (OVM) a soukromoprávní uživatelé údajů (SPUÚ) při výkonu svých agend používají údaje vedené v základních registrech (ZR), údaje vedené v agendových informačních systémech (AIS) a případně další údaje. Pro zajištění efektivní veřejné správy je nutné, aby měli OVM a SPUÚ pro sdílení údajů k dispozici jasně definovanou sadu metod a nástrojů ukotvenou v celkové architektuře eGovernmentu.

Údaje veřejné správy jsou údaje evidované jednotlivými OVM v jejich informačních systémech. Z pohledu sdílení údajů je důležité jejich členění na:

  • údaje evidované v registru práv a povinností (RPP) v rámci ohlášení agendy (dále jen registrované údaje) a ostatní údaje (dále jen neregistrované údaje)
  • veřejné a neveřejné údaje

Jako registrované údaje se pro účely tohoto dokumentu označují všechny údaje zaevidované do RPP při ohlášení agend dle § 51 odst. 6, písm. k) zákona č. 111/2009 Sb., o základních registrech (ZoZR). Dále se jako registrované údaje označují číselníky evidované v RPP dle § 50 odst. 2 a § 54 odst. 1, písm. a) ZoZR. Ostatní údaje spravované OVM jsou pro účely tohoto dokumentu označovány jako neregistrované údaje. Neregistrovaným údajem je např. i agregace údaje evidovaného v RPP sloužící ke statistickým účelům, pokud není samotná agregace evidována v RPP. Je nutno poznamenat, že neregistrovaný údaj by měl být výjimkou. Údaje, které si mezi sebou vyměňují OVM musí být registrovány všechny bezpodmínečně. Cílem je minimalizovat množinu neregistrovaných údajů.

Jako veřejné údaje označujeme údaje, které může kdokoliv číst bez omezení přístupu. Omezení veřejnosti údajů vychází primárně ze zákona č. 106/1999 Sb., o svobodném přístupu k informacím (InfoZ), a to zejména z ochrany utajovaných informací, ochrany obchodního tajemství, ochrany důvěrnosti majetkových poměrů, ochrany osobních údajů a dalších omezení práva na informace dle tohoto zákona, sekundárně veřejnost údajů upravují další speciální právní předpisy. Neveřejné údaje jsou ty, pro jejichž čtení je oprávnění nutné. Pro zápis údajů je nutné oprávnění vždy. Veřejnost údaje označuje ohlašovatel agendy. Údaj označí jako neveřejný, pokud existuje legislativní ustanovení, ze kterého neveřejnost údaje jednoznačně vyplývá. V opačném případě je údaj označen veřejný. Číselníky jsou veřejné všechny bez výjimky.

Z výše uvedeného vyplývá klasifikace údajů veřejné správy znázorněná na následujícím obrázku.

Registrované údaje jsou údaje, o jejichž existenci explicitně informuje OVM jako ohlašovatel agendy prostřednictvím evidence v RPP. Registrované údaje OVM nabídne ke sdílení tím, že je poskytne do propojeného datového fondu (PPDF) a do veřejného datového fondu (VDF) prostřednictvím referenčního rozhraní. Neregistrované údaje jsou všechny ostatní údaje. Jejich správce však musí vést v patrnosti, že nelze obejít zveřejňování údajů do referenčního rozhraní tím, že je nebude registrovat do RPP. Správce si musí neexistenci evidence údaje v RPP obhájit. Neregistrované údaje je možné sdílet, a to pomocí otevřeného přístupu a řízeného přístupu.

  • Přístup k PPDF slouží ke sdílení registrovaných údajů (veřejných i neveřejných) mezi jednotlivými OVM a ke zpřístupnění těchto údajů jednotlivým SPUÚ pro účely výkonu jejich agend, a to na základě oprávnění pro čtení nebo pro zápis evidovaných v RPP.
  • Přístup k VDF slouží ke sdílení veřejných registrovaných údajů mezi jednotlivými OVM a ke zpřístupnění těchto údajů jednotlivým SPUÚ v podobě otevřených dat dle § 3 odst. 11 InfoZ. Ve všech případech se jedná o čtení údajů bez omezení přístupu a tudíž není nutné pro OVM a SPUÚ získat oprávnění pro čtení a evidovat jej v RPP.
  • Řízený přístup slouží k přístupu k neveřejným údajům (registrovaným i neregistrovaným) kýmkoliv (tj. jednotlivými OVM, SPUÚ mimo výkon agend i veřejností) ke čtení na základě definovaných oprávnění.
  • Otevřený přístup slouží k přístupu k veřejným údajům (registrovaným i neregistrovaným) kýmkoliv ke čtení, a to bez omezení přístupu, v podobě otevřených dat dle § 3 odst. 11 InfoZ.

Údaje sdílené prostřednictvím PPDF a VDF jsou poskytovány čerpajícím OVM a SPUÚ přes referenční rozhraní s veškerými garancemi potřebnými k výkonu veřejné správy. Čerpající OVM a SPUÚ považují takto získané údaje za formálně správné (tj. správné, úplné, platné a aktuální). Veřejné registrované údaje sdílejí jejich správci prostřednictvím VDF. Ve výjimečných a odůvodněných případech je sdílejí také prostřednictvím PPDF.

Údaje sdílené prostřednictvím řízeného a otevřeného přístupu jsou poskytovány bez garancí. Přístup k nim je zajištěn z veřejného internetu, proto se jedná o přístupy vhodné spíše pro veřejnost, i když je mohou využít i OVM a SPUÚ, nikoliv však pro výkon veřejné správy, ale pouze např. pro analytickou činnost, při návrhu svých AIS apod. OVM a SPUÚ musí tyto přístupy využít pro čerpání neregistrovaných údajů, neboť k nim jiný přístup neexistuje. Protože tyto přístupy neposkytují garance, čerpání neregistrovaných údajů s garancemi potřebnými pro výkon veřejné správy není možné. Pokud je nutné garance zajistit, je nezbytné údaje nejprve zaregistrovat v RPP, aby k nim mohl být zajištěn odpovídající přístup prostřednictvím PPDF nebo VDF.

Následující obrázek zobrazuje typy údajů dle výše uvedené klasifikace seskupené podle přístupů, prostřednictvím kterých je možné údaje čerpat. Ukazuje, že OVM a SPUÚ přistupují prostřednictvím přístupu k PPDF k údajům obsaženým v PPDF (registrované údaje - především neveřejné, ale ve výjimečných případech i veřejné) a prostřednictvím přístupu k VDF k údajům obsaženým ve VDF (registrované veřejné údaje). Dále pak ukazuje, že kdokoliv (ať už OVM či SPUÚ, tak obecně i jiný subjekt, např. fyzická osoba) může přistupovat k neveřejným údajům prostřednictvím řízeného přístupu a k veřejným údajům prostřednictvím otevřeného přístupu. Zatímco řízený přístup vyžaduje autentizaci a autorizaci přistupujícího subjektu, otevřený přístup je anonymní. Barevné šipky pak naznačují vlastnosti přístupů k údajům (nutnost oprávnění/bez omezení, s garancemi/bez garancí).

Poslední obrázek v této kapitole ukazuje, jakým technickým způsobem je k údajům zajištěn dálkový přístup (ve smyslu §3 odst.2 InfoZ). Přístupy k PPDF a VDF jsou zajištěny prostřednictvím referenčního rozhraní. Řízený a otevřený přístup jsou zajištěny prostřednictvím rozhraní vystavených do veřejného internetu.

Rychlá navigace

Národní architektura veřejné správy ČR

1.Architektonické dokumenty

2.Klíčové oblasti architektury

3.Schvalování projektů a záměrů ICT

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

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

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.

Systémy správy dokumentů

Popis Systému správy dokumentů

Obecně o spisové službě

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

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

Legislativní rámec pro výkon spisové služby určuje zákon č. 499/2004 Sb., o archivnictví a spisové službě a 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 a samostatných evidencí dokumentů. 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.

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

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

  1. Vykonávat spisovou službu tak, že eviduje dokumenty v eSSL nebo v samostatné evidenci dokumentů.
  2. Zajistit soulad eSSL a všech samostatných evidencí dokumentů vedených v elektronické podobě s požadavky NSESSS.
  3. Mít alespoň jeden eSSL.
  4. Zajistit integraci mezi ISSD dle požadavků NSESSS.
  5. Vést jmenný rejstřík, přiřazovat subjektům bezvýznamové identifikátory a vytvářet a spravovat vazby všech dokumentů obsahujících osobní údaje na osoby ve jmenném rejstříku.
  6. Řádně uchovávat a spravovat digitální dokumenty a jejich komponenty v eSSL nebo samostatné evidenci dokumentů.
  7. Provádět evidenci metadat o spisech, dokumentech a dalších entitách a zajistit evidenci všech transakcí a definovaných operací v eSSL či v samostatné evidenci dokumentů v souladu s požadavky NSESSS.
  8. Zajistit příjem, evidenci, rozdělování, oběh, vyřizování, vyhotovování, podepisování, odesílání, ukládání a vyřazování dokumentů ve skartačním řízení v souladu se Zákonem, vyhláškou č. 259/2012 Sb, a NSESSS
  9. Zajistit řádné ověření autenticity a integrity doručených dokumentů v digitální podobě v souladu s nařízením eIDAS a zákonem č. 297/2016 Sb. a zajistit v souladu s uvedenými předpisy řádné připojení autentizačních a autorizačních prvků na dokumenty v digitální podobě vyhotovené původcem
  10. Uchovávat dokumenty a umožnit výběr archiválií, vybrané archiválie v analogové podobě předávat 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 archivní zákon jako původce dokumentů (viz § 3 Zákona). Chystaná novela Zákona z roku 2024 zavádí navíc § 3a, dle kterého by veřejnoprávní původci měli 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é připravovaná vyhláška 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
    1. Zákon č. 499/2004 Sb., o archivnictví a spisové službě
    2. Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby
    3. Národní standard pro elektronické systémy spisové služby
  • Technické a architektonické požadavky
    1. Národní architektonický plán
  • Vnitřní řídící dokumenty úřadu
    1. Spisový řád (jehož součástí je spisový a skartační plán a podpisový řád)
    2. Informační koncepce úřadu
  • Dokumentace k elektronickému systému spisové služby
    1. Dokumentace k ISSD
    2. Dokumentace k integracím ESSL a jiných ISSD, popř. integracím mezi ISSD
    3. Dokumentace související s výkonem spisové služby

Další zdroje

V souvislosti s výkonem spisové služby existuje celá řada dalších zdrojů informací a metodických dokumentů publikovaných zejména Odborem archivnictví a spisové služby (OAS) Ministerstva vnitra a Národním archivem (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 pro Informační systémy spravující dokumenty

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ů, včetně samostatných evidencí dokumentů (informačních systémů veřejné správy i provozních informačních systémů), zajistit úkony spojené se správou dokumentů (příloh k transakcím) a s výkonem spisové služby formou integrace na 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 (samostatné evidence dokumentů i systémy, které dokumenty nespravují)
  • Samostatné evidence dokumentů integrované na rozhraní eSSL

Jelikož legislativa obecně počítá s tím, že v rámci úřadu je vždy provozován jeden eSSL a ostatní ISSD jsou na něj integrovány a úkony spojené s dokumenty se realizují formou rozhraní eSSL, měla by v úřadu být implementována integrace všech samostatných evidencí dokumentů (pokud samy nezajišťují minimální požadavky stanovené NSESSS pro samostatné evidence dokumentů) s eSSL a samotný eSSL navázán na úložiště pro uchovávání komponent digitálních dokumentů. Na obrázku níže je znázorněn obecný stav pochopení integrace eSSL za využití jednoho centrálního úložiště pro digitální dokumenty.

Hovoříme-li o integraci samostatné evidence dokumentů 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:

  1. Digitální dokument, respektive jeho komponenty a datové soubory, jsou uloženy v úložišti digitálních dokumentů, které zajišťuje péči o digitální soubory
  2. Metadata o dokumentu jsou spravována evidenčním nástrojem, tedy:
    • eSSL, nebo
    • informačním systémem, který plní funkci samostatné evidence
  3. Se soubory v úložišti jsou oprávněny pracovat:
    • eSSL, nebo
    • samostatná evidence dokumentů, nebo
    • samostatná evidence dokumentů integrovaná na eSSL prostřednictvím rozhraní eSSL
  4. 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. Chystaná 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. Vesměs existují dvě formy, jak zajistit povinnosti výkonu spisové služby v souvislosti s daným ISSD, a to následující:

  1. Integrovat samostatnou evidenci dokumentů na eSSL prostřednictvím předepsaného rozhraní a zajistit, aby úkony spojené s dokumentem vykonávala samostatná evidence dokumentů prostřednictvím tohoto rozhraní.
  2. Zajistit, aby daný ISSD splňoval požadavky NSESSS kladené na samostatnou evidenci dokumentů a vykonávat úkony spojené s dokumenty a všechny procesy týkající se výkonu spisové služby v samostatné evidenci tímto systémem.

Vazby na architekturu provozních systémů

Velice často se zapomíná na to, že výkon spisové služby se týká všech dokumentů, a tedy nejen úředních dokumentů typu podání a rozhodnutí v rámci výkonu agend veřejné správy. U veřejnoprávních původců se jedná o evidenci a správu veškerých dokumentů (s výjimkou těch, které si daný původce odůvodněně vyňal z evidence ve svém spisovém řádu), a tedy je nutno zajistit výkon spisové služby v elektronické podobě také pro pracovní a provozní 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 na samostatné evidence pro tyto systémy by s sebou přineslo neúměrné finanční náklady spojené s pořízením a rozvojem těchto provozních IS. Integrací na eSSL se také zajistí řádné realizování skartačních řízení u těchto druhů dokumentů.

Souvislosti s architekturou údajů o subjektech

Určení původci, 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 samostatné evidence dokumentů, na něž se také vztahuje NSESSS.

Možné způsoby zajištění digitální kontinuity dokumentů

Je velmi důležité pamatovat na problematiku digitální kontinuity a o své elektronické dokumenty se aktivně starat. Veřejnoprávní původci musí zajistit evidenci dokumentů a to buď v systému spisové služby, nebo v samostatných evidencích dokumentů. Oba výše uvedené způsoby pak musí splňovat požadavky Národního standardu pro elektronické systémy spisové služby v souladu se zákonem č. 499/2004 Sb. Zaměříme-li se na elektronické dokumenty ve smyslu nařízení eIDAS, pak budeme hovořit o elektronickém systému spisové služby a elektronických evidencích dokumentů. Jedním z klíčových požadavků Národního standardu je existence tzv. transakčního protokolu – zápisu provedených operací uskutečněných v rámci elektronického systému spisové služby nebo v rámci samostatné evidence dokumentů v elektronické podobě. Transakční protokol v případě elektronických dokumentů zajišťuje, že od okamžiku zaevidování dokumentu až do okamžiku jeho předání do archivu nebo okamžiku vyřazení a zničení je systematicky evidována jakákoliv operace týkající se evidovaného dokumentu. Tímto je zcela jednoznačně po dobu životního cyklu dokumentu zajištěno, že lze v rámci evidenčního systému garantovat určité vlastnosti elektronického dokumentu, zejména pak věrohodnost původu a neporušenost obsahu. U každého elektronického dokumentu musí být rovněž zajištěna po celou dobu životního cyklu jeho čitelnost, a to jak v technickém slova smyslu, tak z pohledu jeho uživatelsky vnímatelné podoby.

U veřejnoprávních původců je s ohledem na výše zmíněný požadavek prokázání věrohodnosti původu a neporušitelnosti obsahu dokumentu stanovena zákonná povinnost ověřování elektronických podpisů, elektronických pečetí a elektronických časových razítek, pokud je příchozí elektronický dokument obsahuje. Uvedení původci jsou ze zákona povinni výsledky ověření zaznamenat ve svých evidenčních systémech, které jak bylo uvedeno výše, musí splňovat zákonem stanovené požadavky, včetně požadavku na vedení transakčního protokolu. Proto není nutné po prvotním ověření u veřejnoprávních původců používat takové metody, jaké se používají běžně pro zajištění „věrohodnosti původu“ u soukromoprávních původců - například není nutné opětovně opatřovat elektronické dokumenty časovými razítky před jejich expirací a podobně - věrohodnost původu elektronických dokumentů je u veřejnoprávních původců zajištěna řádnou systematickou evidencí dokumentů v určených systémech, kde je navíc pomocí transakčního protokolu možné po celou dobu životního cyklu dokumentu prokázat veškeré operace, které se s evidovaným dokumentem uskutečnily - tj. pro prokázání věrohodnosti původu je zcela dostačující systematická evidence a transakční protokol28).

Výše uvedené lze u veřejnoprávních původců i snadno ověřit – audit systémů zajišťujících vedení spisové služby je možné realizovat v průběhu času a každý veřejnoprávní původce má zákonem stanovenou povinnost kontroly těchto činností. Elektronické systémy spisové služby, ale i některé významné samostatné evidence dokumentů (typicky informační systémy veřejné správy), splňují z pohledu zákona o kybernetické bezpečnosti charakteristiku tzv. významného informačního systému, neboť v případě jejich výpadku nebo nesprávného fungování by veřejnoprávní původci nemohli plnit řádně a souvisle svůj výkon. S ohledem na to by tyto měly být jako významné informační systémy identifikovány a oznámeny Národnímu úřadu pro kybernetickou a informační společnost procedurou dle kybernetického zákona. Tím se tyto systémy dostanou rovněž pod pravidelný dohled útvarů zajišťujících kybernetickou bezpečnost.

Elektronické systémy spisové služby a samostatné evidence dokumentů též zpracovávají osobní údaje fyzických osob, proto veřejnoprávní původci nad těmito systémy mají s ohledem na povinnosti vyplývající z obecného nařízení na ochranu osobních údajů a ze zákona o zpracování osobních údajů řadu povinností, které též zvyšují celkovou důvěryhodnost systémů, ve kterých veřejnoprávní původci evidují své dokumenty.

Výše uvedenými opatřeními lze u veřejnoprávních původců zcela spolehlivě prokázat věrohodnost původu a to i u přijatých dokumentů obsahující elektronické podpisy, elektronické pečetě a elektronická časová razítka a to bez nutnosti jejich opětovného opatřování časovými razítky nebo jinými autentizačními či autorizačními prvky.

Možné problémy

Možným rizikem zajištění digitální kontinuity založeného na základě transakčních protokolů eSSL je problematika kolizních dokumentů. Jedná se o situaci, kdy je do transakčního protokolu v souladu s NSESSS poznamenán otisk (tzv. hash) dokumentu spolu s označení použitého hashovacího algoritmu, ovšem stejný hash může odpovídat i jiným dokumentům. Následně není možné, především u přijatých dokumentů, dovodit o jakém dokumentu (skrze jeho hash) transakční protokol pojednává, což výrazně komplikuje případné dosvědčení právní validity.

Pro eliminaci tohoto rizika, lze využít postupy, kterými se prodlužuje ověřitelnost podle standardu ETSI (The European Telecommunications Standards Institute) a který odpovídá předpisům eIDAS. Jde tedy o opakovaného přidávání kvalifikovaných elektronických časových razítek a validačních informací sloužící k prodlužování možnosti ověření platnosti podpisů a pečetí na elektronických dokumentech. Zjednodušeně lze říci, že tato opatření mají charakter nového elektronického podepsání, nového zapečetění či nového opatření kvalifikovaným elektronickým časovým razítkem. Tyto možnosti totiž znamenají, že se na autentizaci původního dokumentu použijí aktuálně dostatečně silné kryptografické postupy a algoritmy (konkrétně dostatečně robustní hashovací funkce a dostatečně velké klíče), a tím je – opět na určitou dobu – dostatečně ztíženo hledání kolizních dokumentů. Vzhledem k různým právním účinkům elektronických podpisů (představujících projev vůle), elektronických pečetí (představujících vyjádření původu) a časových razítek (představujících „fixaci v čase“) se v praxi, k prodloužení možnosti ověření platnosti původních podpisů a pečetí, využívají právě kvalifikovaná elektronická časová razítka. Důležité je, aby každý jednotlivý krok tohoto dlouhodobého procesu byl proveden včas. Tedy aby další časové razítko bylo přidáno ještě dříve, než zaúčinkuje tzv. časová pojistka (než skončí v čase omezená možnost ověření původního podpisu či pečeti). Případně promeškání nejzazšího okamžiku způsobí, že pozdě přidané časové razítko již nemá prodlužující účinek.

V praxi přitom není nutné (včas) přidávat časová razítka k jednotlivým dokumentům. Vhodnými postupy je možné minimalizovat spotřebu časových razítek, například společným umístěním více dokumentů (či pouze jejich otisků) do vhodného kontejneru (ASiC), a časovými razítky opatřovat pouze kontejner jako takový. Sdružování do kontejnerů je vhodné dle logického spojení dokumentů, například do úrovně spisů. Stejně tak není podstatné, kdo podniká výše naznačená opatření, nutná pro zajištění digitální kontinuity dokumentů.

Je však nutné konstatovat, že ač riziko kolizních dokumentů existuje, současné legislativní prostředí nedává veřejnoprávním původcům dostatečný prostor k rozhodnutí a vlastnímu zvážení rizik a dodatečné připojování elektronických pečetí či časových razítek by mohlo být v rozporu s péčí řádného hospodáře, neboť u nákladů na zajištění takového postupu by se mohlo jednat o neúčelně vynaložené prostředky veřejného rozpočtu.

Dalším možným řešení je předávání transakčních protokolů do archivu v krátké lhůtě.

Univerzální kontaktní místo

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 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

Pro zobrazení seznamu klikněte

Pro zobrazení seznamu klikněte

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

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

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

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

Asistovaná specializovaná kontaktní místa

Specializovaná asistovaná kontaktní místa slouží pro klienty, kteří z jakéhokoliv důvodu nemohou využít služeb samoobslužných kontaktních míst, a zároveň není služba kvůli své specializaci dostupná v univerzálním asistovaném kontaktním místě. Jedná se ve většině případů o přepážky úřadů, na kterých služby vyřizuje personál proškolený pro danou specializaci. Příkladem může být finanční úřad (daňové povinnosti), Katastrální úřad (vlastnictví nemovitostí) nebo Ministerstvo zemědělství (zemědělské dotace). Jakkoliv je 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:

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.

Ú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é.
  • Využívá Jednotný identitní prostor veřejné správy a Elektronickou identifikaci pro klienty veřejné správy .
  • Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.

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

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

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

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

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

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
    • požadovaná úroveň dostupnosti distribucí je stejná jako požadovaná úroveň dostupnosti ostatních služeb ISZR a ISSS
  • 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.

  1. 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).
  2. 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ě.
  3. Agenda 1 vytváří a udržuje číselník, který je dostupný ve VDF a je publikován jako otevřená data.
  4. 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.
  5. U údaje D je v RPP evidováno, že je kódován číselníkem (v příkladu je uvedena situace s číselníkem, který agenda přímo vytváří, ale vše uvedené platí, pro jakýkoliv využívaný číselník). Evidence údaje v RPP proto také obsahuje IRI datové sady v NKOD, který obsahuje publikovaný číselník.
  6. 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).
  7. 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í.
  • 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:

  1. Přístup ke kompletnímu obsahu datové sady v podobě datových souborů voláním
    1. 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é)
  2. 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é)
  3. 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:

  1. označování veřejnosti a neveřejnosti údaje
    1. včetně odkazů na legislativu v případě neveřejnosti údaje
    2. včetně IRI datových sad v NKOD, prostřednictvím kterých je veřejný údaj publikován
  2. evidenci veřejných číselníků
    1. pro každý veřejný číselník existuje 1..- verzí, které chápeme jako jednotlivé datové sady
    2. všechny datové sady reprezentující jednotlivé verze číselníku jsou seskupeny do zastřešující datové sady
    3. 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
      1. mimo vlastnosti poskytovatel, protože tato vlastnost reprezentuje poskytovatele datové sady do VDF
        1. kterým je u číselníků vždy MV ČR, nikoliv poskytovatel číselníku
      2. pro zastřešující datovou sadu je navíc evidováno
        1. OVM, který zavádí veřejný číselník do RPP, jako poskytovatele číselníku
          1. 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
      3. pro verzi číselníku je navíc evidováno
        1. lokální proprietární identifikátor či kód číselníku
          1. potřebné pro konstrukci lokálních IRI číselníků a jejich položek
          2. může vyplnit poskytovatel číselníku nebo je vygenerováno automaticky, pokud poskytovatel číselníků vlastní identifikátor či kód číselníku neeviduje
    4. 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:
      1. Je verzí (reference na zastřešující datovou sadu)
      2. Má předchozí verzi (reference na datovou sadu s předchozí verzí číselníku, existuje-li)
  3. zavedení nového veřejného číselníku poskytovatelem číselníku
    1. poskytovatel číselníku specifikuje metadata pro zastřešující datovou sadu číselníku
      1. lze převzít nebo jinak použít existující formulář pro registraci datové sady
    2. poskytovatel číselníku specifikuje metadata pro datovou sadu s první verzí číselníku
      1. může zvolit možnost kopírovat hodnoty zadané pro zastředující datovou sadu
    3. 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
    4. předchozí tři body lze realizovat také automatizovaně načtením seznamu veřejných číselníků poskytovatele z URL, které zadá
      1. seznam musí být zpřístupněn dle otevřené formální normy pro rozhraní katalogů otevřených dat.
      2. veřejné číselníky ale nemusí být pro účely předání zpřístupněny jejich správcem jako otevřená data.
    5. předaný obsah je zvalidován vůči otevřené formální normě pro číselníky
    6. obsah je uložen v podobě zkontrolovaného předaného datového souboru
      1. obsah veřejného číselníku pouze eviduje, ale nejsou nad ním stavěny žádné aplikační funkce
  4. zavedení nové verze již zavedeného veřejného číselníku poskytovatelem číselníku
    1. 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
    2. původní verze zůstává evidována včetně její publikace do VDF a jako otevřená data
  5. funkcionality systému pro zpřístupnění údajů prostřednictvím VDF
    1. 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
    2. další veřejné údaje evidované v RPP již jsou získávány z interní databáze RPP a AIS působnostní v podobě definované otevřenými formálními normami a předávány do úložiště veřejných číselníků a datových sad RPP
  6. funkcionality úložiště veřejných číselníků a datových sad RPP
    1. bude vytvořeno ze stávajícího úložiště obsahu datových sad publikovaných z RPP jako otevřená data
    2. 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
    3. 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)
    4. 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
    5. je nutné zajistit dostupnost nejen z veřejného internetu jako doposud, ale také prostřednictvím ISGOD (referenční rozhraní) a garantovat dostupnost
  7. 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
    1. zpřístupňuje do NKOD katalogizační záznam pro každou datovou sadu:
      1. datové sady zastřešující verze číselníků a datové sady s verzemi číselníků
        1. metadata o datových sadách jsou získány od poskytovatele
        2. metadata o distribucích jsou doplněny automatizovaně na základě vytvářených distribucí v úložišti
      2. 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)
        1. metadata jsou fixně předvyplněna
    2. je registrován pod MV ČR
  8. označování údaje jako údaje kódovaného verzí veřejného číselníku
    1. včetně zaznamenávání IRI datové sady s touto verzí veřejného číselníku z NKOD
      1. 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.
  9. 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

  1. 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
    • Evidence odkazů na datové sady v RPP
  2. 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ávyvysoká 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 popisu29)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 objektyIRI IRI IRI

Základní registry

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

Jedná se o referenční údaje o

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

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

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

Registr obyvatel (ROB)

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

Subjekty údajů vedených v registru obyvatel jsou

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

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

  • 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 Český statistický úřad. Primárními editory jsou orgány a instituce, které již v současnosti mají zákonnou povinnost osoby registrovat. Jedná se o obchodní rejstřík, rejstřík živnostenského podnikání, evidence nebo informační systémy vybraných ministerstev a ústředních orgánů státní správy, profesních komor, obcí, krajů apod. Sekundárním editorem je Ministerstvo vnitra se systém Datových schránek (ISDS).

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

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

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

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

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

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

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

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

Editory údajů jsou:

Název osoby Typ osobyAgendaEditor ROS
Advokáti FO A8 Česká advokátní komora
Agentury práce FO A531 Ministersvo práce a sociálních věcí
Akreditovaná osoba podle zákona o spotřebitelském úvěru FO A11 Česká národní banka
Auditoři FO A6 Komora auditorů České republiky
Auditoři bezpečnosti pozemních komunikací FO A1381 Ministerstvo dopravy
Autorizovaní architekti FO A54 Česká komora architektů
Autorizovaní inženýři a technici FO A54 Česká komora autorizovaných inženýrů a techniků činných ve výstavbě
Církve a náboženské společnosti PO A5 Ministerstvo kultury
Česká národní banka, Česká televize, Český rozhlas, Regionální rada regionu soudržnosti, Všeobecná zdravotní pojišťovna PO A325 Ministerstvo vnitra
Daňoví poradci FO A7 Komora daňových poradců ČR
Dobrovolné svazky obcí PO A343 Místně příslušný krajský úřad nebo Magistrát hl. m. Prahy
Držitelé licencí pro podnikání v energetických odvětvích FO A684 Energetický regulační úřad
Evropská seskupení pro územní spolupráci PO A561 Ministerstvo pro místní rozvoj
Fyzické osoby - provozovatelé poštovních služeb FO A926 Český telekomunikační úřad
Fyzické osoby provozující živnost (živnostníci) FO A121 Místně příslušný živnostenský úřad
Honební 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í organizacePO A120 Místně příslušný rejstříkový soud

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

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

Registr územní identifikace adres a nemovitostí je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje základní územní prvky, 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.

Způsoby získání referenčních údajů ze ZR

Webové služby

Prostřednictvím webových služeb může subjekt čerpat referenční údaje ze ZR. Subjekt, který působí v agendě, má tuto agendu řádně ohlášenou v RPP, má zaregistrovaný svůj agendový informační systém (také jako AIS) a vydaný platný certifikát od správy základních registrů (také jako SZR), přičemž na čerpání údajů musí mít vlastní zákonné zmocnění ve svém zákoně a dle zákona č.111/2009 Sb., o základních registrech, je tento subjekt oprávněn čerpat referenční údaje ze ZR prostřednictvím vnějších služeb informačního systému správy základních registrů (také jako ISZR).

Pro získávání referenčních údajů webovými službami je nezbytné nejdříve ztotožnit svůj datový kmen vůči ZR a následně se přihlásit pro příjem notifikací o změnách.

Czech POINT

Zkratka Czech POINT znamená Český Podací Ověřovací a Informační Národní Terminál. Jde o kontaktní místo veřejné správy, které poskytuje občanům zejména ověřené údaje vedené v centrálních registrech, jako jsou rejstřík trestů, obchodní rejstřík nebo registr živnostenského podnikání. Kromě standardních služeb, lze využít výpisy ze základních registrů podle zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů. Občané tak mají možnost ověřit si údaje, které jsou o nich v registrech vedeny, úředníci pak mají prostřednictvím formulářů v části CzechPOINT@office přístup k referenčním údajům ze základních registrů.

Jedním z cílů zavádění je zrychlit, zpřístupnit a zefektivnit služby občanům a dalším subjektům. Czech POINT je tedy kontaktním místem veřejné správy, které umožňuje na jediném místě získávat výpisy nebo činit podání.

Informační systém datových schránek

Pomocí datových schránek je možné zasílat dokumenty v elektronické podobě orgánům veřejné moci a také je takto od nich přijímat.

Komunikace prostřednictvím datových schránek nahrazuje klasický způsob doručování v listinné podobě, protože zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, zrovnoprávňuje papírovou a elektronickou verzi zasílaného dokumentu. Orgánům veřejné moci a právnickým osobám jsou datové schránky zřízeny automaticky, všem ostatním na základě jejich žádosti. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů.

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

Fyzické osoby (občané) mají možnost žádat o výpisy ze základních registrů prostřednictvím datové schránky na svém personalizovaném účtu portálu občana, pokud mají na portálu občana zřízenou datovou schránku a připojenou do svého profilu. Do portálu občana je možné se přihlásit datovou schránkou, jménem – heslem – SMS nebo elektronickou občankou s čipem, vydávanou od 1. 7. 2018.

Kdo může žádat o referenční údaje ze ZR

Webové služby

Subjekt státní správy svým AIS, který má zákonné zmocnění ve svém zákoně využívat referenční údaje ze ZR, působící v řádně ohlášené agendě v registru práv a povinností a má vydaný platný certifikát od správy základních registrů pro přístup do ZR. Dále soukromoprávní subjekt práva zprostředkovaně přes AIS některého z orgánu veřejné moci, který má opět zákonné zmocnění využívat údaje ze základních registrů v rámci přidělené agendy řádně ohlášené v RPP.        

Czechpoint

Na kontaktním místě, dle typu jednotlivých formulářů, které jsou v rámci Czechpoint k dispozici, může žádat fyzická, podnikající fyzická osoba i právnická osoba. Bližší informace, kdo může žádat u jednotlivého typu formuláře je k dispozici v sekci Typy žádostí pro získání referenčních údajů ze ZR.

Informační systém datových schránek

Informační systém datových schránek je prostředek pro získávání referenčních údajů ze základních registrů formou zaslání jednoho z formulářů v sekci  Typy žádostí pro získání referenčních údajů ze ZR. Požádat o výpisy může každý, kdo má zřízenou datovou schránku a je oprávněnou osobou podle § 8 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů. Ostatní subjekty si mohou datovou schránku zřídit volitelně.

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

Žádat o výpis údajů ze základních registrů v rámci portálu občana má možnost podat každá fyzická osoba (občan), která má na svém personalizovaném účtu portálu občana zřízenou datovou schránku připojenou ke svému profilu. V rámci portálu veřejné správy, má možnost podat žádost o získání referenčních údajů ze základních registrů každý subjekt, který je uveden v sekci Typy žádostí pro získání referenčních údajů ze ZR, dle typu žádosti.    

Typy žádostí pro získání referenčních údajů ze ZR

Žádost o výpis údajů z registru obyvatel – dle § 58 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny.
  • Za subjekt práva podle § 58 odst. 9 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů, může žádat jeho zákonný zástupce.
  • Za subjekt práva může žádat zmocněnec na základě plné moci s úředně ověřeným podpisem zmocnitele.

Žádost o veřejný výpis údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat jakákoliv fyzická osoba (nemusí být subjektem práva).
  • Žádat lze o poskytnutí údajů o jakékoliv podnikající fyzické osobě, právnické osobě nebo orgánu veřejné moci.
  • Ve výpisu se objeví všechny údaje jako v neveřejném výpisu (viz níže) kromě osobních údajů osob, které jsou ve vazbě na registr obyvatel.

Žádost o výpis (neveřejný) údajů z registru osob – dle § 61 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny v registru osob.

Žádost o záznam o využívání údajů v registru obyvatel – dle § 14 zák. č.111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (fyzická osoba), o kterém jsou údaje vedeny v registru obyvatel.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá fyzická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru obyvatel automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.
  • Informace, jak číst záznam o využívání údajů naleznete v praktické příručce: viz http://www.szrcr.cz/obcan-a-podnikatel

Žádost o záznam o využívání údajů v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Žádost může podat subjekt (podnikající fyzická osoba nebo statutární orgán právnické osoby), o kterém jsou údaje vedeny.
  • V žádosti subjekt uvede období, za které má být záznam poskytnut.
  • Každá podnikající fyzická a právnická osoba, která má zřízenu datovou schránku, obdrží vždy za uplynulý kalendářní rok bezplatně Záznam o využívání údajů v registru osob automaticky do datové schránky, v souladu s § 14 odst. 4 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru obyvatel – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru obyvatel může žádat subjekt práva (fyzická osoba).
  • Na základě žádosti dojde k podání návrhu na změnu referenčních údajů vedených o subjektu práva v registru obyvatel.
  • Dojde-li ke změně referenčního údaje, obdrží fyzická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o změnu údajů při zjištění nesouladu v registru osob – dle § 14 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • O změnu údajů při zjištění nesouladu v registru osob může žádat subjekt práva (podnikající fyzická osoba nebo statutární orgán právnické osoby).
  • Na základě žádosti podává žadatel návrh na změnu referenčních údajů vedených o osobě v registru osob.
  • O změnu údajů při zjištění nesouladu v registru osob může žádat podnikající fyzická osoba nebo statutární orgán právnické osoby.
  • Dojde-li ke změně referenčního údaje, obdrží každá podnikající fyzická nebo právnická osoba, která má zřízenu datovou schránku, bezplatně Výpis referenčních údajů automaticky do datové schránky, v souladu s § 14 odst. 5 zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

Žádost o poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti poskytne subjekt práva (fyzická osoba) své údaje jiné fyzické nebo právnické osobě.
  • Těmto je možné poskytnout všechny nebo vybrané údaje vedené k Vaší osobě v registru obyvatel.
  • Orgánu veřejné moci není nutné poskytnout Vaše údaje tímto způsobem, neboť tento má povinnost si referenční údaje zjistit.

Žádost o odvolání poskytnutí údajů z registru obyvatel třetí osobě – dle § 58a zák. č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

  • Na základě žádosti přestanou být poskytovány Vaše údaje jiné fyzické nebo právnické osobě. Dojde k odvolání Vámi vybraných předchozích souhlasů s poskytnutím údajů třetí osobě učiněných žádostí výše.

Poplatky spojené s žádostmi o výpisy

  • Portál občana a portál veřejné správy – podání žádostí datovou schránkou využitím formulářů uveřejněných na Portálu občana a portálu veřejné správy a vydání výpisů je bezplatné.
  • Czech POINT – žádosti podané prostřednictvím kontaktního místa veřejné správy Czech POINT jsou zpoplatněny, avšak podání žádostí o změnu referenčních údajů a poskytnutí/odvolání poskytnutí referenčních údajů třetí osobě jsou bezplatné.
1)
Interaktivní mapa TESTA-ng https://ec.europa.eu/isa2/solutions/testa_map_en/
2)
§ 2 odst. 1 písm. i) zákona č. 365/2000 Sb. o informačních systémech veřejné správy
Referenčním rozhraním se rozumí souhrn právních, technických, organizačních a jiných opatření vytvářejících jednotné integrační prostředí informačních systémů veřejné správy, které poskytuje kvalitní soustavu společných služeb informačních systémů veřejné správy, včetně služeb výměny oprávněně vyžadovaných informací mezi jednotlivými informačními systémy, a to i se systémy mimo Českou republiku
3)
Tato hodnota je uváděna včetně DPH. V rámci Národního plánu obnovy jsou projekty financovány bez DPH, přičemž rozdíl (DPH) je financován ze státního rozpočtu.
4)
Prováděcí nařízení Komise (EU) 2020/1121 ze dne 29. července 2020 o získávání a sdílení uživatelských statistik a zpětné vazby od uživatelů o službách jednotné digitální brány v souladu s nařízením Evropského parlamentu a Rady (EU) 2018/1724
5)
Prováděcí nařízení Komise (EU) 2022/1463 ze dne 5. srpna 2022, kterým se stanoví technické a provozní specifikace technického systému pro přeshraniční automatizovanou výměnu důkazů a uplatňování zásady „pouze jednou“ v souladu s nařízením Evropského parlamentu a Rady (EU) 2018/1724
6)
Totéž se vztahuje na povinnost informovat o službách v Katalogu služeb.
7)
A výhledově také na portálu pro cizince FRS.
8)
EK považuje za jednu normostranu 1500 znaků bez mezer.
9)
Cena je zprůměrována z cen posledních překladů v roce 2023, které měla ČR od EK pro informaci k dispozici.
10)
Nařízení Evropského parlamentu a Rady (EU) 2022/868 ze dne 30. května 2022 o evropské správě dat a o změně nařízení (EU) 2018/1724.
11)
Směrnice Evropského parlamentu a Rady 2005/36/ES ze dne 6. července 2005 o uznávání odborných kvalifikací.
12)
Směrnice Evropského parlamentu a Rady 2006/123/ES ze dne 12. prosince 2006 o službách na vnitřním trhu.
13)
Směrnice Evropského parlamentu a Rady 2014/24/EU ze dne 26. února 2014 o zadávání veřejných zakázek a o zrušení směrnice 2004/18/ES.
14)
Směrnice Evropského parlamentu a Rady 2014/25/EU ze dne 26. února 2014 o zadávání zakázek subjekty působícími v odvětví vodního hospodářství, energetiky, dopravy a poštovních služeb a o zrušení směrnice 2004/17/ES.
15)
https://archi.gov.cz/nap:egsb.
16)
Hodnoty jsou uváděny včetně DPH. V rámci Národního plánu obnovy jsou projekty financovány bez DPH, přičemž rozdíl (DPH) je financován ze státního rozpočtu.
17)
Návrh nařízení Evropského parlamentu a Rady o shromažďování a sdílení údajů týkajících se služeb v oblasti krátkodobých pronájmů ubytování a o změně nařízení (EU) 2018/1724.
18)
Návrh směrnice Evropského parlamentu a Rady o řidičských průkazech, kterou se mění směrnice Evropského parlamentu a Rady (EU) 2022/2561 a nařízení Evropského parlamentu a Rady (EU) 2018/1724 a zrušuje směrnice Evropského parlamentu a Rady 2006/126/ES a nařízení Komise (EU) č. 383/2012.
19)
Návrh nařízení Evropského parlamentu a Rady, kterým se zřizuje rámec opatření pro posílení evropského ekosystému výroby produktů technologií pro nulové čisté emise (akt o průmyslu pro nulové čisté emise).
20)
Návrh nařízení Evropského parlamentu a Rady, kterým se stanoví rámec pro zajištění bezpečných a udržitelných dodávek kritických surovin a mění nařízení (EU) č. 168/2013, (EU) 2018/858, (EU) 2018/1724 a (EU) 2019/1020.
21)
Návrh směrnice Evropského parlamentu a Rady o evropských přeshraničních sdruženích.
22)
Návrh nařízení Evropského parlamentu a Rady, kterým se mění nařízení (EU) č. 1024/2012 a (EU) 2018/1724, pokud jde o využívání systému pro výměnu informací o vnitřním trhu a jednotné digitální brány pro účely některých požadavků stanovených směrnicí Evropského parlamentu a Rady (EU) / o evropských přeshraničních sdruženích.
23)
Návrh směrnice Evropského parlamentu a Rady, kterou se stanoví harmonizované požadavky na transparentnost zastupování zájmů jménem třetích zemí na vnitřním trhu a kterou se mění směrnice (EU) 2019/1937.
24)
Návrh nařízení Evropského parlamentu a Rady, kterým se mění nařízení (EU) č. 1024/2012 a (EU) 2018/1724, pokud jde o některé požadavky stanovené směrnicí (EU) XXXX/XXXX.
25)
Přehled prostředků s jejich úrovní záruky seznam_poskytovatelu_identity_identity_provideridp
26) , 27) , 30)
Některé údaje ještě nejsou dostupné, protože změny zákona č. 111/2009 Sb. jsou pouze platné, nikoliv účinné. Všechny zde uvedené údaje budou dostupné k 1.2.2022
28)
Může být v rozporu eIDAS ver 2.0, recitál 33 a 33a a článek 45 g a článek 45ga (jde o draft) https:%%//%%data.consilium.europa.eu/doc/document/ST-14959-2022-INIT/cs/pdf
29)
Pro definici oprávnění a řízení přístupu je popis nutný. V současné době ale žádný systematický nástroj popisu neexistuje a bude nutné jej vytvořit. Tímto nástrojem bude sémantický slovník pojmů vyjádřený v podobě ontologických modelů právních předpisů a agend. Ten bude navíc sloužit jako zastřešující model a popis všech dat v datových fondech OVM.

Diskuze

Vložte svůj komentář: