Globální architektura propojeného datového fondu veřejné správy České republiky předkládá popis propojeného datového fondu, pravidla práce jednotlivých rolí (editor, publikátor, čtenář, správce, auditor) a pravidla poskytování údajů o subjektech a objektech v informačních systémech veřejné správy.

Vzhledem k faktu, že se jedná o strategický dokument, nemusí být všechna uváděná pravidla a požadavky na propojený datový fond v souladu s aktuálním technickým a procesním stavem informačních systémů veřejné správy a s platnou legislativou. Cílem dokumentu je vytvořit závazný strategický rámec, který bude dále rozpracován v jednotlivých oblastech (architektura informačních systémů, legislativní rámec).

Propojený datový fond je vytvářen:

• Agendovými informačními systémy, které na základě výkonu agend zajišťují vytváření údajů o subjektech či objektech práva (údaje zde vznikají) - dále “autoritativní původce údaje”.
• Základními registry ROB a ROS, které jako specializované Agendové informační systémy zajišťuji poskytování referenčních údajů o subjektech práva a zajišťují jednoznačnou vazbu údajů na subjekt práva.
• Základním registrem RÚIAN, který jako specializovaný Agendový informační systém zajišťuje jednoznačnou vazbu údajů k územním prvkům a adresám.
• Převodníkem ORG, který zajišťuje převod Základního identifikátoru fyzické osoby a dělené elektronické identity v jednotlivých agendách (Agendový identifikátor fyzické osoby).
• Registrem práv a povinností – poskytuje referenční údaje pro řízení a správu propojeného datového fondu.
• Referenčním rozhraním – sdílené a bezpečné rozhraním informačních systémů veřejné správy dostupné prostřednictvím Centrálního místa služeb.
• Informačním systémem základních registrů a Informačním systémem sdílené služby – součást referenčního rozhraní, která zajišťuje aplikační přístup k referenčním údajům a údajům agendových informačních systémů

Propojený datový fond slouží tedy k výměně údajů o subjektech a objektech práva.

Propojený datový fond veřejné správy vytváří kompletní údajovou bázi, která obsahuje veškeré údaje o subjektech či objektech práva, které jsou vedeny v informačních systémech veřejné správy. Slučování údajů o jednom subjektu však není možné provádět bez potřebných oprávnění jednotlivých agend, a zvláště osobní údaje fyzických osob jsou vysoce zabezpečeny před neoprávněným slučováním.

Jednotlivé role Agendových informačních systémů pro činnost v propojeném datovém fondu jsou:

• Publikátor - Agendové informační systémy poskytující údaje o identifikovaných subjektech či objektech.
• Čtenář – Agendové informační systémy a určené informační systémy soukromoprávních uživatelů údajů.
• Referenční rozhraní zajišťující komunikaci mezi čtenáři a publikátory

Obrázek 1: Rozdělení údajů a schéma výměny

V rámci každé agendy jsou o subjektech v jednotlivých rolích (kontextech) z hlediska propojeného datového fondu vedeny údaje následujících typů:

• Referenční údaje ze základních registrů.
• Údaje z jiných agend (Agendových informačních systémů).
• Údaje vytvářené v rámci činnosti agendy – pouze tyto údaje může agenda poskytovat do propojeného datového fondu jako údaje agendového informačního systému.

Je nutné zdůraznit, že referenční údaje a údaje agendových informačních systémů je možné poskytovat v rámci propojeného datového fondu pouze o subjektech, které existují či existovaly (např. zemřelé osoby po dobu před výmazem zápisu) v základních registrech. U jiných osob neexistuje tato jednoznačná vazba na záznam v základních registrech a není tedy zajištěna prvotní podmínka jednoznačné identifikace osoby, o níž jsou údaje předávány, a tudíž tyto údaje mají vždy pouze informativní charakter a neplatí o nich, že orgán veřejné moci využívající tyto údaje nemusí ověřovat jejich platnost.

Propojený datový fond veřejné správy poskytuje nejvyšší přínos subjektům práva, neboť jim zajišťuje to, že veřejná správa bude pracovat s jejich aktuálními údaji a jednotlivé úřady/agendy nebudou po občanech či právnických osobách opakovaně vyžadovat dokládání jejich údajů.

Významným přínosem pro zaměstnance veřejné správy je právě status správnosti údajů o subjektech práva, které získají prostřednictvím propojeného datového fondu. Jde tedy o údaje garantované agendami, ve kterých jsou vytvářeny a příjemce nemusí provádět složité ověřování údajů, které jsou nutné pro výkon jejich agendy.

Základním nástrojem zabezpečení osobních údajů fyzických osob je využití dělené identity, kde fyzická osoba je v každém Agendovém informačním systému vedena s jednoznačnou elektronickou identifikací pomocí AIFO (Agendový identifikátor fyzické osoby), který je mezi agendami různý. Převodník těchto AIFO (ORG) je spravován Úřadem pro ochranu osobních údajů a je dostupný pouze prostřednictvím Informačního systému základních registrů (ISZR). Bez spolupráce převodníku ORG a ISZR tedy není možné sloučit údaje o jedné fyzické osobě z různých agend (včetně základních registrů Registr obyvatel a Registr osob).

Řízení a popis celého propojeného datového fondu je uložen v Registru práv a povinností, který obsahuje popis všech částí propojeného datového fondu až do technických detailů, umožňujících jednoznačnou implementaci a řízení veškeré funkcionality včetně orchestrační mapy skládání údajů.

Tyto údaje jsou pak využívány jednotlivými komponentami propojeného datového fondu k řízení procesů a oprávnění při předávání a využívání údajů.

Registr práv a povinností je kromě jiného úložištěm všech informací potřebných k předávání údajů v rámci propojeného datového fondu. Obsahuje údaje o jednotlivých účastnících procesu (Agendové informační systémy, Orgány veřejné moci a Soukromoprávní uživatelé), strukturu předávaných údajů, jejich ztvárnění (formuláře) a struktury pro řízení oprávnění přístupu k údajům. Všichni účastníci propojeného datového fondu jsou povinni se řídit těmito údaji.

Předávání údajů propojeného datového fondu lze provádět na základě přímé či nepřímé vazby

• Přímá vazba – přímá komunikace mezi jednotlivými informačními systémy veřejné správy. Při této komunikaci jsou vyměňovány údaje bez účasti ISZR či ISSS. V případě komunikace přímou vazbou o subjektech práva nesmí být přenášeno AIFO a komunikace musí být doplněna nepřímou komunikací přes ISZR či ISSS, při které je kromě překladu AIFO doplněn i výčet údajů, které jsou přenášeny v přímé vazbě (z důvodu zaznamenání tohoto přenosu).
• Nepřímá vazba – přenášení údajů prostřednictvím ISZR a ISSS. Při použití této vazby je zajištěna vazba na základní registry (ověření existence subjektu v základních registrech a překlad AIFO) a zaznamenání výčtu přenášených údajů. Při použití nepřímé vazby je také ulehčena práce publikátora, který nemusí vytvářet a udržovat své vlastní rozhraní dle pravidel PPDF.

Registr práv a povinností obsahuje řídící údaje pro přenášení údajů včetně oprávnění pro přístup k jednotlivým údajům a technických údajů o jednotlivých komponentách a údajích.

Je nutné zdůraznit, že preferovaným postupem je používání nepřímé vazby, tj. použití ISZR a ISSS. Přímou vazbu je možné použít pouze při přenosu velkých objemů dat o subjektech (např. pravidelné výpisy) a to ještě jen dokud není zajištěn přenos nepřímou vazbou prostřednictvím ISSS. Přímou vazbu je možné nadále používat pro přenos údajů o objektech bez vazby na subjekty.

Publikátor musí zajistit následující funkcionalitu:

• Výdej údajů o identifikovaném subjektu v identifikované roli (kontextu) v souladu s oprávněním čtenáře.
• Identifikaci subjektu dle dané sady údajů předaných čtenářem o tomto subjektu v dané roli (kontextu).
• Záznam všech požadavků a odpovědí (log) včetně údajů, který je chráněn proti neoprávněnému přístupu a využití. Tento záznam musí být opatřen technickými prostředky (identifikátory transakcí) pro zajištění vazby záznamů v celém propojeném datovém fondu. Stejná povinnost se vztahuje i na čtenáře, potažmo každý ISVS dle vyhlášek k zákonu 365/2000 Sb., především vyhlášky o referenčním rozhraní.
• Prostředky pro příjem reklamací údajů v souladu se zákonnými pravidly agendy
• Prostředky pro předávání informací o změnách údajů registrovaných subjektů
• Prostředky pro technické ověření dostupnosti služeb publikátora (probe).

Výměna údajů vždy musí odpovídat logice vyjádřené v následujícím schématu.

Obrázek 2: Schéma výměny údajů

Toto schéma s nutným zjednodušením stanovuje pravidla pro vytváření a sdílení údajů a pro jejich následnou údržbu formou reklamací.

Povinnosti publikátora musí zajistit věcný správce ve spolupráci s případným technickým správcem informačního systému/ů, které zajištují výkon agendy. V dalším textu je zdůrazněno, zda informace jsou určeny primárně pro věcného správce agendy či technického správce informačních systémů.

V této kapitole jsou shrnuty operačních pravidel na propojeném datovém fondu, které jsou v následujícím textu detailněji popsány.

Nutnou podmínkou zajištění správnosti údajů a využívání propojeného datového fondu je to, že jednotlivé orgány veřejné moci budou údaje ze svých agend (agendových informačních systémů) řádně publikovat do propojeného datového fondu. Zde je nutné uvést, že publikací údajů ze svých informačních systémů správce agendy okamžitě získá následující výhody:

• Nemusí budovat a udržovat komunikační rozhraní k různým subjektům (zajišťující přímou vazbu), cílově postačuje komunikace s centrálními komponentami referenčního rozhraní (nepřímá vazba).
• Nemusí udržovat a spravovat ověřování komunikačních partnerů, údaje o čtenáři (orgán veřejné moci, agenda, Agendový informační systém atd.) jsou ověřovány centrálními komponentami a důvěryhodně předány.
• Nemusí spravovat systém oprávnění k přístupu. Údaje o oprávněních získává z Registru práv a povinností.

Je tedy v zájmu všech správců agend, aby maximálně urychlili publikaci údajů agendových informačních systémů v rámci propojeného datového fondu.

Propojený datový fond zajišťuje, že veřejná správa při svých procesech pracuje s aktuálními údaji o subjektech a objektech, které jsou správné. Slovem správné je míněno to, že autoritativní původce (editor agendy poskytující údaj či editor referenčního údaje v základních registrech) podle svých znalostí potvrzuje jeho správnost.

Údaje získané z propojeného datového fondu tedy nemusí být příjemcem ověřovány. Může nastat situace, kdy autoritativní původce údajů má pochybnosti o správnosti údaje (vyřizuje reklamaci), pak je údaj označen tímto původcem za nesprávný. Naopak příjemce údaje při své činnosti může zjistit skutečnosti, které jsou v rozporu s poskytnutými údaji, pak zahájí proces reklamace, tj. oznámí původci tuto pochybnost ve formě reklamace údaje.

Subjekt práva, fyzická nebo právnická osoba, pak nemusí při kontaktu s veřejnou správou dokládat údaje, které lze získat z propojeného datového fondu a prokazovat jejich správnost.

Správce agendového informačního systému udržuje datový fond tohoto AIS v aktuálním tvaru využitím procesů vyrozumívání o změnách údajů na propojeném datovém fondu a uživatel AIS tedy má jistotu, že při své práci pracuje se správnými údaji (ve výše uvedeném smyslu). Z hlediska uživatele AIS (úředníka) jde tedy o zásadní zvýšení efektivity a jistoty při jeho práci.

Údaje z propojeného datového fondu jsou z jedné agendy poskytované jiné agendě prostřednictvím příslušných agendových informačních systémů. Tento proces se děje na pozadí prostřednictvím referenčního rozhraní a uživatele AIS nijak nezatěžuje.

Druhým způsobem využití údajů je standardní forma žádosti o výdej údajů (i hromadných jako je například seznam změn za určité období). Tento proces zpracovávání formulářů zajišťuje Formulářový agendový informační systém (FAIS), který zajišťuje rozhraní mezi Datovými schránkami (podání žádosti a výstup) a Propojeným datovým fondem veřejné správy (FAIS při vyřizování žádosti využívá služeb referenčního rozhraní).

V dalších kapitolách tohoto dokumentu jsou jednotlivé procesy detailně popsány s doplněním požadovaných architektonických a technických standardů.

Propojený datový fond veřejné správy slouží především k zvýšení efektivity podpory výkonu veřejné správy z hlediska podpory informačními systémy. Základní východiska propojeného datového fondu:

• Každý subjekt či objekt práva vystupuje v informačních systémech v roli (kontextu) vyjádřeném v legislativě (např. Občan, Vlastník vozidla, Pacient apod.). Jedna agenda může obsahovat více rolí (kontextů) pro daný typ subjektu (fyzická osoba, podnikající fyzická osoba, právnická osoba), čímž je rozlišen rozsah údajů vedených o daném subjektu. Obdobně je tomu s objekty práva. Každý kontext je definován unikátním kódem v Registru práv a povinností.
• Údaje o subjektech či objektech práva “vznikají” jednoznačně
  • Údaj vedený o subjektu či objektu v informačních systémech podporujících výkon agendy (Agendový informační systém dle zákona 111/2009 Sb. o základních registrech) je definován v příslušných zákonech, kterými je řízen výkon agendy. Zákonem je tedy určeno, jaké údaje se v agendovém informačním systému o daném subjektu práva vedou v příslušné roli (kontextu). Obdobně je tomu pro objekty práva. Tento výčet je ohlašovatel agendy povinen uvést do Registru práv a povinností.
• Každý údaj je definován unikátním kódem v Registru práv a povinností a existuje unikátní místo odkud je poskytován do propojeného datového fondu. Takto poskytovaný údaj je označen v ohlášení agendy jako “referenční” ve smyslu „garantovaný“ (buď referenční ze základních registrů či údaj agendového informačního systému). Smyslem označení jako referenční je, že orgán veřejné moci může využívat tyto údaje “aniž by ověřoval jejich správnost” ve smyslu zákona o základních registrech pro údaje ze základních registrů a jednotlivých zákonů upravujících výkon agend. Údaje, které již existují o subjektu práva v propojeném datovém fondu, nemusí subjekt práva prokazovat.
  • Každý čtenář údaje z propojeného datového fondu musí zajistit identifikaci subjektu či objektu, pro který údaj čerpá. Agenda poskytující konkrétní údaj tedy není zodpovědná za správnou identifikaci subjektu údaje, ale spoléhá na identifikaci poskytnutou čtenářem v rámci dotazu.
  • Čtenář nesmí zpětně poskytovat údaj získaný z propojeného datového fondu s tím, že ho poskytuje jako garantovaný údaj, tedy údaje svého agendového informačního systému (může ho poskytovat vždy pouze jen jako informativní údaj).
  • Referenční údaje a údaje agendového informačního systému (ve smyslu zákona o základních registrech) je možné poskytovat pouze o subjektech práva, které jsou nebo byly vedeny v základních registrech Registr obyvatel a Registr osob (tedy existuje pro ně přidělené ZIFO/AIFO či IČO dle zákona o základních registrech). Údaje agendových informačních systémů o ostatních subjektech práva (bez vazby na AIFO či IČO) je možné poskytovat pouze jako informativní na základě identifikace subjektu dle údajů.
• Údaje je v rámci propojeného datového fondu možné poskytovat pouze prostřednictvím referenčního rozhraní (§ 2 písm. j zákona č. 365/2000 Sb. o informačních systémech veřejné správy). Referenční rozhraní zajišťuje především
  • Identitu zdroje i čtenáře – každý informační systém je jednoznačně identifikovatelný pomocí SSL certifikátu vydaného Certifikační autoritou Správy základních registrů.
  • Soukromí – veškerá výměna údajů je realizována v uzavřeném komunikačním prostředí.
  • Důvěryhodnost – veškeré řídící údaje jsou uloženy v Registru práv a povinností, nemůže dojít k podvržení zdroje údajů ani identity čtenáře údajů.
  • Auditovatelnost – Referenční rozhraní ukládá provozní údaje zajišťující zpětnou auditovatelnost komunikace.
  • Nezpochybnitelnost – Jsou nastavena pravidla zajišťující nezpochybnitelnost a prokazatelnost předávaných údajů (z hlediska jejich předání a původu, nikoli z hlediska jejich faktické správnosti, ta musí být zajištěna legislativně při tvorbě údaje).
  • Referenční rozhraní je čerpáno výhradně prostřednictvím Centrálního místa služeb (CMS).

Uvedená základní pravidla zajištují, že v rámci celého propojeného datového fondu je vždy nezpochybnitelně zřejmé, kdo je původcem údajů, o jakém konkrétním subjektu jsou předávány údaje, jaké jsou předávány údaje (včetně jejich statutu referenčnosti) a kdo je příjemcem údajů. Vzhledem k logické nepřesnosti popisných názvů jednotlivých údajů (např. pod pojmem “jméno” může být vnímáno prosté jméno, jména, celé jméno bez titulů, celé jméno s tituly atd.) je v Registru práv a povinností každý údaj veden pod jednoznačným identifikátorem tak, aby nemohlo dojít k záměně na základě chybné interpretace názvu.

Součástí Globální architektury propojeného datového fondu je dále definice provozních pravidel pro jednotlivé části propojeného datového fondu sjednocení požadavků na tyto jednotlivé části.

Každý správce agendového informačního systému ve spolupráci s věcnými správci agend, které podporuje, musí učinit následující kroky:

• Provést základní analýzu potřebných a uložených údajů agendy a rozdělit je na:
  • Referenční údaje ze základních registrů,
  • Údaje pocházející z jiných agend (ačkoli je v současné době z těchto agend nečerpá),
  • Údaje vytvářené činností agendy, kterou vykonává.
• Provést technické připojení k ISZR a ISSS, pokud tak již neučinil, v roli čtenáře. Zajistit technické podmínky jako je logování transakcí.
• Ztotožnit celý svůj datový kmen. Výsledkem ztotožnění pro fyzickou osobu je získání AIFO, výsledkem ztotožnění pro právnickou osobu (včetně fyzické podnikající osoby) je IČO.
• Pro referenční údaje a údaje z jiných agendových informačních systémů aktualizovat údaje z propojeného datového fondu a zahájit odběr vyrozumění o změnách údajů.
• Připravit publikaci kontextu/kontextů “údaje o subjektu” v plném rozsahu pro každý kontext (právní postavení subjektu práva v agendě) a tento kontext opublikovat na ISSS:
  • Subjekt práva má přístup k celému kontextu,
  • Ostatní agendy žádají o přístup k jednotlivým částem/údajům prostřednictvím RPP.
• Poskytnout služby vyrozumívání o změnách údajů, aby čtenáři mohli aktualizovat své datové kmeny.

Nelze očekávat splnění těchto kroků pro všechny informační systémy veřejné správy v krátkém čase, nicméně je v zájmu všech správců AIS, aby tyto kroky činili a postupně pak získávali údaje z jiných AIS. Tyto kroky jsou naprosto nutné k tomu, aby byla naplněna strategie propojeného datového fondu a je naprosto nutná součinnost a aktivita všech věcných i technických správců agend a agendových informačních systémů.

Fyzická osoba profituje z existence propojeného datového fondu i bez jakýchkoli kroků ze své strany. Pokud jednotliví správci agend a agendových informačních systému budou pracovat na strategii propojeného datového fondu dle výše uvedených pravidel, nebudou po subjektu práva vyžadovat dokládání skutečností, které jsou již dostupné prostřednictvím PPDF a tím se podstatně sníží zátěž na fyzické a právnické osoby.

Nicméně pokud fyzická osoba chce zaujmout aktivní roli, což je vítaný přístup, pak pro plné použití a využití prostředí propojeného datového fondu veřejné správu doporučujeme následující kroky:

• Zřízení prostředku vzdálené identifikace a autentizace – umožní fyzické osobě nahlížet na údaje, které jsou o ní vedeny v jednotlivých agendách/agendových informačních systémech. Takto získané údaje slouží především pro ujištění, že veřejná správa pracuje se správnými údaji. V opačném případě subjekt práva může okamžitě vyvolat reklamaci údaje a zajistit tak, že veřejná správa bude pracovat se správnými údaji.
• Zřízení datové schránky fyzické osoby – umožní odesílání a příjem dokumentů mezi veřejnou správou a touto osobou. Tento proces splňuje veškeré náležitosti osobního podání či přijetí dokumentů a je podmínkou nutnou pro to, aby držitel datové schránky mohl s veřejnou správou komunikovat důvěryhodně a bezpečně vzdáleně.

Fyzická osoba vybavená prostředkem vzdálené identifikace a autentizace bude moci plně využívat veškerých digitálních služeb eGovernmentu.

Obrázek 3: Ilustrační schéma využívání digitálních služeb eGOV ze strany fyzických osob

Již v současné době má řada právnických osob a OSVČ zřízenu datovou schránku. Pro právnické osoby zapsané v obchodním rejstříku nebo zřízené zákonem, jakož i pro některé typy fyzických osob (např. advokáti) je datová schránka zřízena přímo zákonem č. 300/2008 Sb. o elektronických úkonech a autorizované konverzi dokumentů. Pro právnické osoby a podnikající fyzické osoby, ať již mají datovou schránku povinně či nikoliv, platí stejné doporučení jako pro fyzické osoby, tedy plošné zřízení datové schránky pro zajištění důvěryhodné a bezplatné komunikace s veřejnou správou.

Právnická osoba ze své povahy nikdy nemůže jednat “sama”, ale pouze prostřednictvím fyzické osoby, která má k tomuto oprávnění. V zájmu všech právnických osob tedy je:

• Zřízení prostředku vzdálené identifikace a autentizace pro všechny fyzické osoby, které mohou jejím jménem jednat.
• Ověření, že základní mandáty (tj. oprávnění osoby jednat za jinou osobu) pro jednání vedené v Registru osob jsou platné – v opačném případě u editora těchto údajů vyvolat reklamaci pro zjednání nápravy.
• U každého správce agend vyžadovat zajištění elektronického mandátního registru, kde oprávněná osoba dle Registru osob může zmocnit stanovenou fyzickou osobu k provádění příslušných úkonů.

Základem je tedy opět vzdálená identifikace a autentizace fyzické osoby a vedení vazby této fyzické osoby k provádění úkonů v zastoupení právnické osoby v dané agendě. V Registru osob jsou jako referenční údaje vedeny základní mandáty, tj. mandáty plynoucí z postavení, jako je např. statutární orgán právnické osoby. Další mandáty, typicky mandáty vznikající dohodou o zastoupení (na základě plné moci) nebo z postavení neevidováno v ROS (např. zaměstnanec v určitém pracovním zařazení) nemohou být vedeny centrálně a musí být vedeny v jednotlivých AIS podle pravidel agend, které vykonávají.

Z hlediska uživatele AIS nesmí dojít k žádným zvýšeným nárokům. Získávání potřebných údajů z propojeného datového fondu řeší AIS, se kterým pracuje, na pozadí a uživateli AIS jsou údaje získané z PPDF zobrazovány s vyznačením, že se jedná o aktuální referenční údaje či údaje jiných AIS získané přes PPDF a nemusí tedy být dále ověřovány.

Pokud uživatel AIS při své činnosti dojde ke zjištění, že předkládané údaje jsou v rozporu se skutečností, pak musí použít proces reklamace údaje. Tento proces musí být podporován správcem agendy, ideálně přímo v AIS, ve kterém uživatel pracuje.

Obrázek 4: Ilustrační schéma využívání údajů z propojeného dat. fondu z hlediska úředníka

Technický správce AIS zajišťuje technické propojení s PPDF a napojení na všechny služby podpory výměny údajů (tedy nejen čtení, ale i příjem vyrozumívání o změnách, aktualizaci údajů atd.).

Významnou činností je udržování datového fondu AIS aktuálním. Pro tento proces povinně registruje v ORG ta AIFO, která jsou v agendě vedena pro příjem vyrozumívání o změnách údajů a obdobně odregistrovává AIFO, která již nejsou vedena v produkčním prostředí (převedeny do archivu) a tedy již není potřeba aktualizovat údaje o těchto osobách. Proces aktualizace provádí pravidelně v souladu s pracovními postupy vydanými Správou základních registrů.

Aktualizaci údajů za delší časové období provádí pouze při porušení datového fondu (obnova ze zálohy a podobně). Opakované čtení vyrozumívání o změnách údajů a aktualizací za dlouhé období neúměrně zatěžuje jak referenční rozhraní, tak datový zdroj (základní registry a AIS).

Ve spolupráci s věcným správcem agendy řeší ztotožnění datového kmene o fyzických osobách (získání AIFO) tak, aby následná údržba údajů mohla probíhat komunikací podle AIFO.

Opakované ztotožňování téže osoby dle údajů bez uložení AIFO v agendě je nepřípustným plýtváním prostředky referenčního rozhraní a datových zdrojů.

Následující obrázek, či spíše architektonický diagram, zobrazuje budoucí stav propojeného datového fondu z hlediska jeho komponent, služeb, aktérů, HW a SW technologií a fyzického propojení. Jde tedy o komplexní pohled skrze všechny vrstvy tzv. čtyřvrstvé architektury českého eGovernmentu v souladu s Národním architektonickým rámcem.

Na levé straně jsou klienti PPDF se svými systémy a technologiemi, které využívají pro doručení služeb koncovému uživateli. Napravo jsou zdroje PPDF neboli editoři a publikátoři se svými systémy a technologiemi. Uprostřed jsou systémy a technologie PPDF.

Obrázek 5: Zobrazení budoucího stavu PPDF z hlediska jeho komponent, služeb, aktérů, HW a SW technologií a fyzického propojení

media_image5.emf

Následující architektonické schéma znázorňuje budoucí stav PPDF z pohledu subjektu práva. Subjekt práva se ke svým údajům v PPDF může dostat pomocí specifických rozhraní, které mu poskytuje čtenář PPDF. Cílem je, aby se subjekt práva dostal ke všem svým údajům ve všech agendách veřejné správy ČR pomocí pro něho nejpohodlnějšího přístupu.

Obrázek 6: Zobrazení budoucího stavu PPDF z pohledu subjektu práva

media_image6.emf

Následující architektonické schéma znázorňuje současný stav PPDF z pohledu subjektu práva a jeho možnosti přistupovat k údajům jednotlivých agend. Jednotlivé agendy bez vazeb neposkytují nyní subjektu žádné údaje pomocí služeb PPDF, přesto jsou zde znázorněny, aby byla vidět šíře, kterou má PPDF pro subjekt práva obsáhnout.

Obrázek 7: Zobrazení současného stavu PPDF z pohledu subjektu práva

media_image7.emf

Vedle PPDF jsou údaje sdíleny také prostřednictvím Veřejného datového fondu (VDF). Prostřednictvím VDF jsou údaje sdíleny v následujících scénářích:

1. OVM při sdílení údajů prostřednictvím PPDF potřebuje obsah číselníku nebo definici vybraných položek číselníku, který spravuje jiný OVM. Nezískává je prostřednictvím PPDF, ale prostřednictvím VDF jako otevřená data.
2. OVM nevykonává správní činnost, ale provádí jinou doplňkovou úlohu (např. sestavuje analytický report). Potom využívá veřejné údaje v podobě otevřených dat dostupné z VDF. Rozdíl oproti obecným otevřeným datům a otevřeným datům dostupným z VDF je, že údaje ve VDF mají pro OVM garantovánu dostupnost a publikující OVM garantuje jejich správnost.

Jiným způsobem než prostřednictvím PPDF a VDF si OVM mezi sebou žádné údaje nevyměňují.

Z pohledu PPDF je důležitý první scénář. Druhý scénář je detailněji rozpracován v dokumentu Architektura VDF. Cílem prvního scénáře je, aby číselníky nebyly duplikovány a neřízeně a nekoncepčně rozšiřovány v různých ISVS. Pokud pro interpretaci údajů získaných z PPDF potřebuje OVM číselník, který spravuje jiný OVM, pak tento OVM nevytváří kopii číselníku ve svém informačním systému v podobě nového číselníku. V údajích získaných z PPDF získá IRI položek číselníku, které kódují hodnoty údajů. Plné údaje o položkách číselníku získá dereferencí IRI ve VDF. Tam získá i IRI číselníku a dalším dereferencováním může v případě potřeby získat celý číselník. Pokud si ale číselník ukládá, potom vždy jen z důvodů optimalizace či zajištění dostupnosti a tuto kopii udržuje vždy aktuální vůči zdroji prostřednictvím VDF. Konkrétní mechanismy jsou popsány v Architektuře VDF.

V budoucnu může být množina typů údajů, které nejsou sdíleny prostřednictvím PPDF ale pouze výhradně prostřednictvím VDF, z pouhých číselníků rozšířena i na další typy.

Propojený datový fond (také jako PPDF) je tematická oblast tvořená především Informačním systémem základních registrů a 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.

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 Informační systém sdílené služby.

Veškeré poskytování služeb v rámci PPDF je vždy propojeno 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 a podnikajících fyzický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 sdílení údajů 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…) s 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íce je popsáno v kapitole 4.

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.
• V o změnách referenčních a agendových údajů pro údaje v AIS vedené.
• Podpora reklamace chybných údajů.

Referenčním rozhraním se v souladu s jeho fakticky zakotvenou definicí 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. 

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é je definováno v zákoně 365/2000 Sb. Centrální místo služeb je systém, jehož primárním účelem je zprostředkovávat řízené a evidované propojení informačních systémů OVM a SPUÚ ke službám (aplikacím), které poskytují informační systémy jiných subjektů 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 je možné realizovat prostřednictvím:

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

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 pouze prostřednictvím KIVS/CMS.

Centrálně řízená a spravovaná část referenčního rozhraní zajišťuje sdílení dat v propojeném datovém fondu s ohledem na zákon 111/2009 Sb. o základních registrech s centrálním zajištěním všech požadavků kladených na referenční rozhraní.

Tato centrálně řízená a spravovaná část Referenční rozhraní se skládá ze tří komponent.

Tabulka 1: Komponenty centrálně řízené a spravované části referenčního rozhraní

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 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ů.
  • Provádí editoři základních registrů s využitím služeb vnějšího rozhraní ISZR.
• Realizuje využívání údajů ze základních registrů.
  • S ohledem na oprávnění k přístupu k údajům 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 vyrozumívání o změnách údajů 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 a výměny údajů. V případě výměny údajů o fyzických osobách provádí překlad AIFO prostřednictvím služeb ORG.

• 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 vyrozumívání o změnách údajů 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. o informačních systémech veřejné správy, 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í svého soukromoprávního informačního systému pro využívání údajů nebo prostřednictvím AIS jiného OVM.
• Každý AIS nebo informační systém SPUÚ pro využívání údajů 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 či objektech práva 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 nebo SPUÚ požadující údaje o konkrétním subjektu, je zodpovědný za jeho řádné ztotožnění ve své agendě, tj. získání AIFO, pokud jde o fyzickou osobu nebo IČO, pokud jde o právnickou osobu nebo podnikající fyzickou osobu. Pokud subjekt není řádně ztotožněn, pak údaje vedené v daném AIS 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í se spisovou službou (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 (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. o informačních systémech veřejné správy), 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ů 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í.

Tabulka 2: Rozhraní ISZR

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

• Přístup k údajům vedeným v základních registrech.
• Služby reklamace, zpochybnění, vyrozumívání o změnách údajů, 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.
• Vynucení dodržování oprávnění zapsaných v RPP.

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

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

Základní registry jsou 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 a podnikajících fyzických osobách,
• Adresách, ú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.

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.

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 správné, 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.
• Zajistit správnost a aktuálnost údajů.  

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, ale jsou vedeny v RPP jako speciální typ údaje s vazbou na konkrétní údaje základního registru.

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í. Zavedení indikátoru do základního registru je podmíněno jeho uvedením jako referenčního údaje v zákoně č. 111/2009 Sb., o základních registrech. Pro inicializaci takové legislativní úpravy je nutné posoudit, zda zavedením nového indikátoru bude splněn účel odstranění zbytečných dotazů do agendových informačních systémů (indikovaný údaj se vyskytuje u významné menšiny osob či objektů).

Pro referenční údaj typu indikátor musí být zavedeny všechny odpovídající procesy jako pro jiné referenční údaje. Musí být tedy určen editor údaje včetně publikace služeb pro editaci údaje tímto editorem a musí být zajištěny další procesy životního cyklu referenčního údaje ( reklamace, vyrozumění o změně údaje, poskytnutí údaje na žádost subjektu atd.).

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,
• identifikátor AIS + identifikátor agendy,
• nepovinný identifikátor kontextu, v rámci něhož lze získat přes ISSS detailní data,
• 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.

Proces reklamace správnosti údaje

Proces reklamace správnosti referenčního ú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 a napojuje svoje agendové informační systémy, nebo využívá některý z jiných nástrojů.

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 způsobů či kombinací dvou následujících, vždy však v souladu s provozní dokumentací ISZR:
  1. Využíváním mechanismu vyrozumívání 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 (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 Ministerstvo vnitra a Policie České republiky prostřednictvím Agendového informačního systému evidence obyvatel a Agendového informačního systému cizinců. Subjekty práva vedených v registru obyvatel jsou:

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

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

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

Subjekty práva 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čí fyzické osoby uvedené v § 25 písm. e) a f); 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.

 Aktuální seznam editorů údajů v ROS je zveřejněný na následujících web stránkách: https://www.czso.cz/csu/czso/editori-ros. U nereferenčních údajů bude editorem MVČR.

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

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

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

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

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

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

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

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

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

Registr práv a povinností (RPP) 

Registr práv a povinností spravuje Ministerstvo vnitra a 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 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 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ů, která kromě povinností stanovených vyhláškou k zákonu 111/2009 Sb. o základních registrech popsána i v kapitole 3.2. 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 OVM, agendy, údaje o jejich správcích, apod. 

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.

Tabulka 3: Role definované v souvislosti s využíváním ZR

Systémy, jejichž údaje jsou publikované kompozitními službami. 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), 
• Cizinecký informační systém – AISC (Správcem je Policie ČR), 
• Evidence cestovních dokladů – AISECD (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 – není v současné době editorem základních registrů, poskytuje však údaje ve vazbě na referenční záznam v ROB (správcem je Správa základních registrů).

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 povinnost existence dokumentů evidovaných ve spisové službě v systémech eSSL nebo samostatných evidencí dokumentů v souladu s právními předpisy. Čtenář může čerpat nereferenční údaje formou 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 (historické údaje o subjektu práva a další údaje, které se v ZR nenachází). 

Informační systém sdílené služby (v IT prostředí označen pojmem eGovernment On-Line Service Bus, eGSB) je unifikované rozhraní pro sdílení údajů mezi jednotlivými agendovými informačními systémy. Jedná se o součást referenčního rozhraní umožňující jednotlivým AIS OVM č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 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ů a umožňuje: 

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

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

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

Tabulka 4: Role definované v souvislosti s využíváním ISSS

V souvislosti se sdílením údajů prostřednictvím 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, správu a jakým způsobem může být změněn či zrušen. 
• Poskytovatelem údaje je vždy správce AIS, v němž je údaj veden a evidován. 
• Údaj je vždy vázán na subjekt práva, či objekt práva v ZR. 
• Bude umožněno subjektu práva si pořídit výpis údajů jako výpis z informačního systému veřejné správy. 

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

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

Kontext používaný v 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ů. 
• Metodika realizace nového kontextu subjektu či objektu údajů předávaného prostřednictvím ISSS. 

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 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 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 ISSS. Proto si nejdříve musí zavolat zvláštní službu ISSS pro čtení Katalogu kontextů, ve kterém pak zjistí, jaký kontext musí volat, aby mohl získat údaje z poskytující agendy. 

Obrázek 8: Pohled na propojení integračních platforem

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 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 a ISSS 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.

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 subjektů – 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. Aby byly i další části tohoto dokumentu pochopitelné, níže je tabulka s přehledem identifikátorů týkajících se fyzické osoby: 

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.

Identifikátory právnických osob a podnikajících fyzických osob

U právnických osob a podnikajících fyzický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ů a zvláštní kategorie osobních údajů (dříve jako citlivých 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 také vytvářen.
• Má-li právnická osoba nebo podnikající fyzická osoba provozovnu evidovanou dle živnostenského zákona, 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 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ů, a dalších informačních systémech veřejné správy 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 údajů o fyzických osobách. 

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.

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 při každé komunikaci prostřednictvím 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ů (tento překlad je v ISZR a ISSS vždy vykonáván bez vnějšího zásahu jako součást zpracování služeb). 
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 osobní údaje. 

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

Při interakci s klientem 

Při osobním jednání s klientem nebo při jeho prezenčním ztotožnění se využije typ a číslo dokladu, který klient předložil, nebo jinak ověřený stykový identifikátor. 

• Klient předloží doklad s uvedeným identifikátorem, který je stykovým identifikátorem. 
• Prostřednictvím daného AIS se zavolá služba jednorázového ztotožnění osoby přeložením stykového identifikátoru na dané AIFO v jeho agendě. 
• Dále úředník pracuje v AIS podle AIFO subjektu (které sám na obrazovce nevidí), stykový identifikátor si dále neuchovává. Pokud existuje klientský identifikátor, ten při komunikaci uchovat může. 
• Při komunikaci s ostatními AISy a ostatními agendami využije služby svého AISu (kdy AIS prostřednictvím ISSS zajistí výměnu údajů po překladu AIFO). 

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

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

Obrázek 9: Pohled na identifikátory ve VS

Po právní stránce je vždy údaj definován na úrovni ustanovení konkrétního zákona. Na základě takového ustanovení konkrétního zákona vzniká definice agendy a v jejím rámci definice subjektu či objektu, jehož vlastností je hodnota uvedeného údaje.

Definice agendy, vazba agendy na zákon, popis subjektu či objektu dle ustanovení zákona včetně rozpadu na definované věcné údaje jsou uloženy v RPP.

Každá agenda vedená v RPP má přiřazený jednoznačný kód, který se v průběhu času nemění. Kód agendy je klíčovým identifikátorem při vedení dalších, zákonem definovaných atributů agendy. Kód agendy je složen z písmene “A” a číselného označení agendy, například “A101” odpovídá agendě “Základní registr – registr obyvatel”.

Každý typ subjektu či objektu definovaný v agendě (kontext) má přiřazený jednoznačný identifikátor v rámci RPP. Identifikátor typu subjektu či objektu je složen z číselného označení agendy a z číselného označení subjektu či objektu v rámci agendy, například “101-1” odpovídá subjektu “Obyvatel” v agendě “A101” - “Základní registr, registr obyvatel”.

Každý věcný údaj subjektu či objektu agendy má taktéž přiřazený jedinečný identifikátor v rámci RPP. Identifikátor údaje subjektu či objektu agendy je složen z identifikátoru subjektu či objektu v agendě a z číselného označení údaje v rámci subjektu či objektu agendy, například “101-1-1" odpovídá údaji “Příjmení” objektu “101-1” - “Obyvatel” v agendě “A101” - “Základní registr, registr obyvatel”.

Jednoznačné identifikátory agendy, subjektů či objektů v agendě a jejich údajů dle definice v agendě tvoří základní právní rámec pro předávání dat na referenčním rozhraní PPDF.

Údaj je tedy vždy jednoznačně definován svým kódem v RPP. Název údaje je dán příslušným právním předpisem a nemusí být v rámci propojeného datového fondu jednoznačný.

Ke každé definici údaje subjektu či objektu agendy (ÚA) v RPP po právní stránce existuje minimálně jedna odpovídající technická definice tohoto údaje subjektu či objektu agendy. Tato technická definice je označována jako Technická specifikace údaje agendy (TSÚA) a je vedena v AIS RPP.

Poznámka: AIS RPP je agendový informační systém ve správě MV, jde o primární editační AIS základního registru RPP.

Poznámka: možnost existence více definic TSÚA je dána možností verzování technické specifikace údaje agendy.

V rámci technické specifikace ÚA jsou jednotlivé údaje definovány kódem údajem, názvem, údaje, popisem, datovým typem a doplňkovými atributy (například veřejnost údaje a podobně).

Tabulka 5: Atributy, které jsou součástí každého údaje

Poznámky:

1. Další okolnosti změny hodnoty údaje (autor, OVM, důvod, …) musí být uloženy v logu změn příslušného systému.
2. Hodnota platnost_od může být nižší než hodnota datum_zápisu (přistěhování na adresu) nebo vyšší než hodnota datum_zápisu (adresa pro doručování písemností).

Za účelem vytvoření datového typu údaje agendy se údaj evidovaný v agendě na základě jeho právní definice v rámci PPDF normalizuje na skupinu dále logicky nedělitelných objektů. Při této normalizaci se zohledňuje jak dosavadní technická implementace v AISech editorů, tak jejich ideální technická reprezentace.

Technická specifikace ÚA, respektive datového typu údaje subjektu či objektu agendy je založena na standardu W3C XML Schema Definition Language (XSD).

Technickou specifikaci ÚA provádí oprávnění uživatelé v AIS RPP. AIS RPP z důvodů přehlednosti povoluje využívat pouze omezenou množinu vlastností standardu XSD. V principu jde o omezení na:

1. Jednoduché datové typy (dle standardu).
2. Komplexní datové typy.

Jednoduché datové typy mohou být doplněny o objekty typy atribut.

Komplexní datové typy mohou být doplněny o objekty typu atribut, element, sekvence a výběr.

Datové typy jsou definovány v AIS RPP v Katalogu datových typů údajů agendy (Katalog DTÚA), nebo přímo v rámci definice údaje agendy.

Správcem katalogu DTÚA je MV, Odbor hlavního architekta eGovernmentu.

Volba konkrétního způsobu v principu závisí na zhodnocení obecné použitelnosti datového typu mezi různými agendami.

Základní společné datové typy jsou definovány v AIS RPP v Katalogu DTÚA.

Základní společné datové typy jsou definovány v globálních kontejnerech, které jsou sdílené pro všechny agendy.

Základní společné datové typy vznikají na základě obecného posouzení rozsahu použitelnosti konkrétního datového typu. Definice základních společných datových typů provádí správce Katalogu DTÚA, jejich schválení pro další použití je podmíněno souhlasných stanoviskem odboru hlavního architekta eGovernmentu.

Klíčové základní společné typy jsou typy, které jsou obecně používány v rámci referenčního rozhraní PPDF. Klíčové základní společné typy jsou fixní, jejich změna se nepředpokládá.

Vybrané klíčové základní datové typy jsou fixně definovány na úrovni XSD v rámci Informačního systému základních registrů (RegTypy.xsd).

Mezi klíčové základní společné typy, které jsou mimo jiné dále uváděny v dalším textu této kapitoly, patří následující typy:

• UUID (UuidType) – univerzální unikátní identifikátor.
• CasovaZnacka (CasovaZnackaType) – datum a čas.
• AIFO (AifoType) - identifikátor obyvatele v agendě.
• BSI (BsiType) - bezvýznamový identifikátor fyzické osoby.
• IČO (IcoType) - identifikátor právnické nebo podnikající fyzické osoby.
• IČP – identifikátor provozovny
• KodOvm (KodOvmType) - identifikátor OVM nebo SPUU.
• KodAgendy (KodAgendyType) - identifikátor agendy.
• KodAdresniMisto (KodAdresniMistoType) - kód adresního místa.
• AdresniLokalita (AdresniLokalitaType) - identifikátor adresní jednotky.

Důvodem pro zavedení základních společných datových typů je zajištění kompatibility, interoperability a logické vazby mezi totožnými druhy údajů v rámci různých systémů.

V rámci technické specifikace údaje agendy je definována technická reprezentace každého konkrétního údaje. Technická reprezentace musí v maximální možné míře postihovat dekompozici údaje na jeho dále nedělitelné prvky.

Proces dekompozice údaje objektu agendy je klíčovým procesem normalizace propojeného datového fondu.

Při dekompozici údaje objektu agendy musí být vždy zohledněny existující datové typy definované v globálních kontejnerech v Katalogu DTÚA.

V rámci technické specifikace údaje agendy mohou být definovány související provozní údaje.

Umístění provozních údajů v rámci technické definice definuje správce agendy na základě logické granularity údaje.

Příklady provozních údajů jsou:

• Datum poslední změny hodnoty technického údaje.
• Identifikátor poslední změny.

Provozní údaje nejsou v definici údaje nikdy vedeny samostatně, vždy jsou svázány s konkrétním údajem publikovaným agendou.

Při definici provozního údaje objektu agendy musí být vždy zohledněny existující datové typy definované v globálních kontejnerech v Katalogu DTÚA.

Definice údajů po právní stránce uložená v RPP je přehledem kontextů a jejich údajů vedených v agendách. Technická stránka definice údajů pak popisuje syntaktické vyjádření kontextů v podobě XML schémat. Definice významu údajů je vyjádřena v podobě konceptuálních modelů na konceptuální rovině. Je vyjádřena ve strukturované podobě sémantických vazeb prvku reprezentujícího údaj v konceptuálním modelu na:

• věcně související prvky v témže konceptuálním modelu,
• věcně související prvky v konceptuálních modelech ostatních věcně souvisejících kontextů,
• ontologii veřejné správy,
• definující ustanovení právních předpisů,
• související externí slovníky a ontologie (např. EU ISA2 Core Vocabularies).

Definice každého údaje po právní stránce evidovaná v RPP je propojena s odpovídajícím prvkem nebo prvky příslušného konceptuálního modelu prostřednictvím jejich IRI. Pro každý údaj evidovaný v RPP tak lze zjistit, jakému prvku nebo prvkům v jakém konceptuálním modelu odpovídá. Prostřednictvím IRI těchto prvků lze získat plnou strojově zpracovatelnou definici významu údaje.

Konceptuální model je vyjádřen ve strojově zpracovatelné podobě. Strojově zpracovatelná podoba je technicky postavena na modelu RDF konsorcia W3 a je vyjádřena pomocí jazyků RDF Schema a Web Ontology Language (OWL). Sémanticky vychází z Unified Foundation Ontology (UFO).

Konceptuální modely jsou uloženy v samostatném Úložišti konceptuálních modelů, které je grafovou databázi postavenou na modelu RDF. Každý konceptuální model a každý jeho prvek je jednoznačně identifikován svým IRI v podobě URL, které zároveň umožňuje prostřednictvím HTTPS požadavku získat strojově zpracovatelnou podobu konceptuálního modelu nebo prvku. Úložiště také nabízí službu pro databázové dotazování nad konceptuálními modely. Technicky je toto API v podobě SPARQL endpointu, tj. webové služby umožňující dotazování v jazyku SPARQL definovaném konsorciem W3. Toto dotazování lze kombinovat s dotazováním nad kompletním veřejným obsahem RPP publikovaným jako otevřená data též prostřednictvím SPARQL endpointu. Stejným způsobem je také možné dotazování kombinovat s obsahem eSbírky, která prostřednictvím SPARQL endpointu zpřístupňuje legislativu ve strukturované podobě jednotlivých právních ustanovení a jejich hierarchických souvislostí.

Správcem Úložiště konceptuálních modelů je MV, Odbor hlavního architekta eGovernmentu. Ten je také správcem a věcným garantem ontologie veřejné správy. Konceptuální modely kontextů vypracovávají ohlašovatelé agend a ukládají je do Úložiště konceptuálních modelů. MV, Odbor hlavního architekta eGovernmentu pro tvorbu konceptuálních modelů poskytuje volně dostupný Nástroj pro konceptuální modelování kontextů a také Metodiku konceptuálního modelování kontextů. Dále pak kontroluje požadovanou kvalitu konceptuálních modelů dodaných do Úložiště konceptuálních modelů a jejich vazby na evidenci definic údajů v RPP a dožaduje potřebné opravy zjištěných nedostatků od ohlašovatelů agend.

Proces aktualizace údaje publikovaného na referenčním rozhraní vychází z obecného architektonického schématu popisujícího princip fungování propojeného datového fondu.

Obrázek 10: Princip fungování propojeného datového fondu

V tomto procesu jsou definovány dvě klíčové role:

1. Editor údaje.
2. Správce publikace údaje.

Editor údaje zodpovídá za editaci údaje v AIS editora (úroveň -2 – AIS editora). Editaci údaje provádí bezodkladně a zodpovídá za bezodkladnou propagaci informace o změně údaje a změněné hodnoty do AISu publikujícího údaje na referenční rozhraní (úroveň -1 – AIS publikátora). Editor údaje zodpovídá za správnost údaje.

Správce publikace údaje na referenční rozhraní zodpovídá za příjem informace o změně údaje publikovaného na referenčním rozhraní z AIS editora a její bezodkladnou publikaci na referenčním rozhraní, včetně publikace informace změny v dotčeném kontextu. Správce publikace zodpovídá za to, že údaj je publikován v nepozměněné formě.

Editor údaje dále zodpovídá za implementaci procesu vyrozumívání o změně v údaji z AIS editora do AIS publikátora. Za definici vzájemného technického rozhraní mezi AIS editora a AIS publikátora zodpovídá správce publikace, přičemž definice je obvykle je založena na vzájemné dohodě AIS editora a AIS publikátora.

Na rozhrání mezi AIS editora a AIS publikátora je třeba při implementaci dodržet následující principy:

• Každá změna má jedinečný identifikátor změny – doporučený datový typ UUID.
• Každá změna má atribut data změny v AIS editora – doporučený datový typ CasovaZnacka.
• Každá změna obsahuje jednoznačnou identifikaci změněných údajů dle definice údaje agendy v RPP, tj. změna se může dotýkat více údajů, vždy však pouze jednoho objektu / subjektu.
• Každá změna obsahuje jednoznačnou identifikaci AIS editora tak, aby s touto informací mohly pracovat systémy na vyšších úrovních, tj. aby na každé úrovni bylo patrné, kde je zdroj změny údaje.

Proces čtení údaje probíhá vždy na referenčním rozhraní PPDF.

Čtenář údaje musí být vždy identifikován v rozsahu:

• Kód čerpající agendy a činnostní role.
• Kód čerpajícího OVM nebo SPUU.
• Kód AIS, který provádí čtení.

Tato identifikace se použije pro ověření oprávnění na čtení údajů.

Čtenář musí identifikovat údaje agendy, které chce v rámci procesu čtení získat. Údaj agendy je identifikován jeho jednoznačným identifikátorem v definici údaje agendy.

Při čtení musí čtenář povinně uvést další provozní informace:

• Identifikátor dotazu v čtenářském AIS.
• Důvod nebo účel čtení údaje.
• Zřejmá identifikace subjektu, který údaje využívá, respektive kterému jsou údaje poskytovány (identifikací je BSI nebo pracoviště kontaktního místa VS).
• Identifikace uživatele, který čtení inicioval.

Identifikace uživatele je z pohledu jeho obsahu na referenčním rozhraní bezvýznamová, nicméně je povinností správce AIS zabezpečit evidenci uživatelských identifikátorů (včetně historie) tak, aby:

• Byla v souladu s Vyhláškou o kybernetické bezpečnosti (IdM a podobně)
• Byla evidována vazba uživatele na činnostní role dle RPP.

Poznámka: v případě přístupu uživatele prostřednictvím AIS využívajícího pro autentizaci uživatelů JIP je doporučeným identifikátorem uživatele jeho uživatelský identifikátor v JIP.

Na referenčním rozhraní PPDF jsou výše uvedené provozní informace při přístupu k údajům logovány. Takto zalogované informace o přístupu k údajům předávaným prostřednictvím referenčního rozhraní jsou v rámci referenčního rozhraní PPDF poskytovány oprávněným subjektům.

Oprávnění na údaje publikované na referenčním rozhraní se ověřují proti oprávnění na čerpání údajů, která jsou vedena v RPP.

Kontrola oprávnění na přístup k údaji na referenčním rozhraní probíhá vždy před vlastním přístupem k požadovanému údaji, přístup k údaji je proveden až po ověření oprávnění. V případě pokusu o přístup k údaji, na který není oprávnění, zabezpečí funkcionalita referenčního rozhraní zamítnutí celého požadavku (a to i v případě, že by v rámci konkrétního požadavku existovalo oprávnění na čtení jiných údajů).

Referenční rozhraní s ohledem na legislativní omezení (například GDPR), kdy by měla být pro konkrétní úkon v agendě využívána pouze taková množina údajů, která je pro úkon nezbytná, nebude povolovat čtení bez uvedení údajů, které čtenář požaduje (tedy nebude existovat možnost čerpání dle implicitních oprávnění, čtení dle maximálního rozsahu povolených údajů dle RPP).

V rámci procesu čtení údaje jsou podstatné oprávnění na čtení. Stávající oprávnění pro čtení v RPP jsou:

• R – čtení aktuálního stavu údaje
• RH – čtení aktuálního i historického stavu údaje

V RPP dále existují oprávnění pro zápis údaje (W) a oprávnění pro zápis historie (WH), tato oprávnění implikují oprávnění čtení včetně historie (RH).

Kromě výše uvedených oprávnění je s ohledem na legislativu nutné řešit i problematiku objemu vydávaných dat, typicky v situacích, kdy je prováděno vyhledávání dle údajů (tedy nikoliv pro situace čtení dle jedinečného identifikátoru objektu / subjektu).

Z pohledu fungování referenčního rozhraní je klíčové, zda má daný čtenář oprávnění na čtení údaje (tedy oprávnění typu “R”). Z pohledu publikujícího AIS jsou však podstatné další atributy oprávnění, tj. zda má čtenář oprávnění na čtení historie (případně na jaký rozsah historie má čtenář oprávnění), na jaký objem dat má čtenář oprávnění při vyhledávání a podobně.

Referenční rozhraní by tedy mělo zajistit, kromě ověření oprávnění na čtení (a případného zamítnutí požadavku), i předání dalších atributů oprávnění z RPP do publikujícího AIS, aby publikující AIS mohl tato oprávnění zohlednit bez vedení těchto informací přímo v publikujícím AIS.

Technický tvar každého konkrétního údaje agendy vedeného v RPP, jehož hodnota je publikována na referenčním rozhraní PPDF, je definován v AISP jako nedílná součást definice agendy a údajů, které jsou v agendě vedeny.

V každém okamžiku je tedy k dispozici aktuální technická definice konkrétního údaje agendy publikovaného prostřednictvím referenčního rozhraní PPDF.

Verzování technické specifikace údaje agendy je vždy vztažena ke konkrétnímu okamžiku, kdy byla schválena. V případě požadavku na změnu technické specifikace, lze v AISP vytvořit novou verzi technické specifikace, a to v souladu s principem verzování XSD.

Pro každou verzi technické specifikace poskytuje AISP konzumentům, což jsou především čtenářské AIS, ucelenou definici XSD typu odpovídajícího publikovanému objektu na referenčním rozhraní PPDF.

V rámci AIS publikujícího data na referenčním rozhraní PPDF mohou být vedeny provozní údaje.

Provozní údaje mají vztah k objektu / subjektu, respektive k údaji agendy. Provozní údaje se dělí do dvou skupin:

• Provozní údaje související s hodnotou údaje.
• Provozní údaje související s přístupem k údaji.

Provozní údaje související s hodnotou údaje (například datum a čas poslední změny objetu či subjektu, respektive jeho údaje, identifikátor poslední změny, stav údaje), mohou být definovány v rámci technické specifikace údaje agendy v AIS RPP, v tom případě jsou poskytovány na referenčním rozhraní PPDF při čtení objektu či subjektu.

Provozní údaje související s přístupem k údaji, tj. informace o tom, kdo, kdy a za jakým účelem k údaji přistupoval, se v rámci technické specifikace údaje agendy neuvádí. Pokud jsou tyto informace poskytovány na referenčním rozhraní PPDF, pak jsou poskytovány samostatně, odděleně a v jednotné formě pro všechny definované agendy a nejsou svázány s technickou specifikací údaje agendy.

Na základě technické specifikace údaje definované v AISP je vytvářena XSD definice objektu / subjektu údaje. Tato XSD definice je vytvářena automaticky.

XSD definice vytvořená v AISP je publikována na referenčním rozhraní.

V rámci ISSS je výše uvedená XSD definice využívána pro zajištění shody technické specifikace údajů agenty a jejich technické implementace v AIS publikátorů.

Proces vyrozumívání o změnách údaje je podmíněn editací údaje na úrovni procesu aktualizace údaje editorem údaje.

Změnou se rozumí vytvoření, změna nebo smazání údaje.

Pro každý objekt/subjekt existující v rámci propojeného fondu, tedy objekt definovaný v RPP existuje mechanismus umožňující čtenářům údajů sledovat změny údajů, na jejichž čtení mají zákonná oprávnění.

Místem, přes které čtenář získává informace o změně údajů, je referenční rozhraní.

Mechanismy, které s procesem vyrozumívání o změnách souvisí, jsou:

• Přihlášení / odhlášení čtení změn objektu / subjektu.
• Získání změn v zadaném intervalu pro přihlášené objekty / subjekty.
• Získání změn v zadaném intervalu pro konkrétní subjekt / objekt.
• Získání dat souvisejících se změnou.

Poznámka: není striktně požadována implementace všech uvedených mechanismů pro všechny objekty / subjekty. Například u subjektu – obyvatel v ROB je nevyužitým mechanismem získání změn pro konkrétní subjekt, u subjektu – PFO nebo PO v ROS naopak přihlášení k odběru změn.

Získáním změn se rozumí získání seznamu identifikátorů objektů / subjektů, jejichž prostřednictvím lze aktualizovat data o změněném objektu / subjektu. Vlastní aktualizace dat o objektu / subjektu se provádí procesem čtení údaje.

Získáním dat souvisejících se změnou se rozumí získání dodatečných informací o změně (identifikátor změny, datum změny, typ změny, seznam změněných údajů a případně další, nejsou vydávaný vlastní hodnoty údajů).

U všech výše uvedených mechanismů může identifikovaný čtenář obecně volit mezi:

• Změny v libovolné agendě.
• Změny v konkrétní agendě.
• Změny na konkrétním údaji.

Pro podporu procesu vyrozumívání o změnách jsou na referenčním rozhraní vystaveny služby podporující výše uvedené mechanismy, a to opět se zohledněním vhodnosti pro konkrétní typ objektu či subjektu.

Pro každý podporovaný objekt / subjekt práva existuje informační systém, který udržuje seznam změn údajů daného subjektu/objektu:

• Subjekt – Obyvatel – vedeno v ROB.
• Subjekt – PFO nebo PO – vedeno v ROS.
• Objekt / subjekt vedený v RPP – vedeno v ZR.
• Jiný objekt / subjekt – ISSS (například objekt “Vozidlo” v “Centrálním registru vozidel”, subjekt “Řidič” v “Centrálním registru vozidel” atd. Definice identifikace identifikátoru těchto objektů musí být vedena RPP).

Popis těchto systémů je uveden v kapitole Systém evidující změny.

Výjimku z uvedeného mechanismu tvoři data vedená v RUIAN, který má vlastní systém výdeje změn.

Vytvoření / úprava / smazání

• Subjektu či objektu.
• Údaje.

Obecně jsou v rámci PPDF podporovány dvě strategie pro vyrozumívání o změně údaje, jde o strategie:

• PULL – čtenář sám z vlastní iniciativy ověřuje existenci změn a sám čte jejich seznam.
• PUSH – čtenář vystavuje rozhraní, na které jsou mu z referenčního datového rozhraní zasílány informace o změnách.

Pro obě tyto strategie platí, že čtenář získává informace o změnách objektů / subjektů. Podle typu subjektu či objektu mohou tyto informace zahrnovat proces přihlašování k odběru změn v konkrétních agendách.

Strategie typu PULL je na úrovni PPDF podporovaná vždy pro všechny typy subjektů či objektů. Strategie typu PUSH je nepovinná a nemusí být vždy pro všechny typy subjektů či objektů na referenčním rozhraní podporována.

Obdoba stávajících mechanismů implementovaných v ISZR. Referenční rozhraní PPDF vystavuje služby, prostřednictvím kterých lze získat seznam změn.

V souladu s přehledovou architekturou jsou technicky odděleny služby pro čerpání změn referenčních údajů vedených v ZR a změn údajů vedených v jiných ISVS (AIS_{publikátorů}).

Obrázek 11: Ilustrační využití mechanismu pro údaje v ROB

Systém udržující změny pro objekt / subjekt při každém zápisu změny údaje (vložení / smazání) prostřednictvím referenčního rozhraní PPDF umožňuje vyrozumívat přihlášeného čtenáře údajů.

Při změně údaje je informace o změně pro konkrétního příjemce předána na referenční rozhraní. V rámci referenčního rozhraní ISSS jsou udržovány endpointy pro zasílání vyrozumění jednotlivých čtenářů.

V rámci referenčního rozhraní jsou dostupné prostředky, které umožňují čtenářům se přihlásit ke čtení informací o změnách údajů objektů / subjektů (a s tím související prostředky na zrušení těchto přihlášení).

Speciálním případem vznik nového objektu / subjektu agendy. V tomto případě se čtenář přihlašuje k odběru tohoto typu změny bez specifikace konkrétního objektu / subjektu.

Referenční rozhraní při přihlášení čtenáře k odběru změn ověřuje oprávnění čtenáře na požadovaný rozsah čtení změn dle RPP. Referenční rozhraní nepovolí přihlášení k odběru změn, které jsou v rozporu a aktuálními oprávněními na čtení v RPP.

Poznámka: referenční rozhraní nevydá informace o změnách, na které není oprávnění v okamžiku čtení změn; tj. je prováděno ověření oprávnění oproti aktuálnímu stavu v okamžiku výdeje.

Pro všechny systémy evidující změny musí platit, že jejich implementace musí být taková, aby bylo možné, případně s využitím mechanismů implementovaných na úrovni referenčního rozhraní, zajistit následující funkčnost:

1. Čtenář získá pouze seznam takových změn, které se dotýkají údajů, na které má oprávnění a o sledování jejichž změn požádal.

Volitelně, podle typu objektu / subjektu:

2. Při čtení změn získá čtenář u každého objektu / subjektu i seznam údajů, které byly v zadaném intervalu změněny.

Cílem (a) je minimalizovat čtení údajů na základě vyrozumění o změnách, jejich výsledkem by bylo pouze přečtení stavu tak, jak jej aktuálně eviduje čtenář (neboť čtenář se dotáže pouze na údaje, na které má oprávnění, a ty nebyly změněny).

Cílem (b) je možnost reagovat pouze na změny konkrétních údajů, které čtenář potřebuje pro realizaci konkrétního procesu v agendě.

Fiktivní příklad pro (b): pro AIS je procesně zajímavá informace o změně údajů “datová schránka” a “číslo účtu”. AIS požádá o výdej změn těchto dvou údajů. AIS získá informaci, že u jednoho objektu proběhla změna údaje “datová schránka”, u druhého objektu změna údaje “číslo účtu”. AIS se může rozhodnout, že změna údaje “datová schránka” není procesně důležitá pro daný okamžik a nemusí provést pro tento objekt čtení přes referenční rozhraní, naopak změna údaje “číslo účtu” pro daný okamžik důležitá je, a musí provést bezodkladné čtení údajů druhého objektu.

V rámci systému základních registrů zůstává nezávisle na obecném mechanismu vyrozumívání o změnách zachována funkcionalita mechanismů vyrozumívání o změnách tak, jak je implementována prostřednictvím eGON služeb ISZR.

V rámci procesů podporujících změny a souvisejících mechanismů vyrozumívání o změnách budou zavedena pravidla s ohledem na možnost historického čtení změn (typickým příkladem takového pravidla je omezení na získání seznamu změn s ohledem na dobu, která od změny proběhla; lze se zeptat na změny pouze za posledních několik dnů, nelze se ptát na změny od počátku století a podobně, délka období by mohla být řešena případně individuálně).

V ROB jsou vedeny referenční údaje o subjektu údajů obyvatel:

• Obyvatel – kód objektu dle RPP 101-1.

Podpora vyrozumívání o změnách referenčních údajů vedených v ROB pro objekt práva Obyvatel je přímo součástí ROB, v procesu je dále zahrnut ORG. Mechanismus vyrozumívání o změnách je z pohledu čtenáře i editora obsluhován prostřednictvím eGON služeb ISZR.

Podpora vyrozumívání o změnách údajů předávaných prostřednictvím referenčního rozhraní z publikačních AIS bude řešena rozšířením eGON rozhraní ISZR.

Provedení změny údaje, který je publikován prostřednictvím referenčního rozhraní:

• AIS editora, jímž editované údaje o obyvateli vedeném v ROB jsou publikovány prostřednictvím referenčního rozhraní, zapíše každou změnu publikovaného údaje (identifikace údaje dle RPP) jím vedené agendy prostřednictvím eGON služby ISZR do ROB.

eGON služba ISZR předává data o změně do ROB po překladu AIFO v ORG. V ROB je uložena informace o změně na úložiště změn.

AIS zapisuje: AIFO, čas změny, identifikátor změny, seznam identifikátorů změněných údajů (identifikace údaje dle RPP, je svázán s agendou editora).

Získání změny údaje publikovaného na referenčním rozhraní:

• Čtenářský AIS volá rozšířenou verzi eGON služby publikované na eGON rozhraní ISZR (PULL).
• Čtenářský AIS je zaregistrován jako příjemce PUSH vyrozumívání o změnách údajů a vystavuje definované rozhraní pro příjem vyrozumívání o změnách údajů.

V rámci rozšíření procesu vyrozumívání o změnách údajů bude moci čtenářský AIS:

• Získat seznam AIFO, u kterých byla v definovaném období provedena změna. Tento seznam bude svázán na přihlášení AIS k vyrozumívání o změnách údajů pro AIFO, tak jak jsou evidovány v ORG. V rámci požadavku bude muset čtenářský AIS specifikovat seznam údajů, které mají být ověřeny na provedení změny.

V souvislosti se zavedením mechanismů vyrozumívání o změnách údajů vzniknou další dodatečné eGON služby, které řeší situace, které nejsou doposud řešitelné, nebo které lze řešit pouze s využitím složitých a komplexních mechanismů.

V rámci referenčního rozhraní bude možné:

• Získat seznam změněných údajů (v rámci oprávnění čerpající agendy), u kterých došlo pro konkrétní AIFO v rámci zadaného časového intervalu ke změně. Výdej těchto údajů nebude vázán na přihlášení AIFO k vyrozumívání o změnách údajů.

Poznámka: aktuálně nelze jednoduše ověřit existenci změn konkrétních údajů pro konkrétní AIFO bez čtení těchto údajů, například pro účely předání jiným osobám.

• Získat seznam změn na základě územního členění (s ohledem na oprávnění čerpající agendy). Výstupem bude seznam změn, které se v rámci zadaného časového intervalu k takové změně, která ovlivňuje příslušnost obyvatele do uvedené územní působnosti. Výdej těchto údajů nebude vázán na přihlášení AIFO k vyrozumívání o změnách údajů.

Poznámka: zjednodušení dostupnosti dat nyní získávaných prostřednictvím výpisů pro obce. V rámci této změny získá konzument i informaci o novém obyvateli v rámci jeho územní působnosti.

Důsledkem výše uvedeného popisu je nutnost rozšíření doby, po kterou jsou údaje o obyvateli vedeny v ROB tak, aby bylo možné evidovat změny údajů publikovaných na referenčním po takovou dobu, po jakou jsou tyto údaje vedeny dotčené subjekty práva publikovány na referenčním rozhraní.

V ROS jsou vedeny referenční údaje o subjektu práva typu právnická osoba nebo podnikající fyzická osoba:

• Osoba – kód objektu dle RPP 102-1.

V rámci ROS jsou aktuálně evidovány změny prováděné na jednotlivých subjektech prováděných v ROS pro referenční údaje ROS.

ROS bude z pohledu vedení evidence změn a podpory procesu vyrozumívání o změnách údajů fungovat obdobně jako ROB. Mechanismus vyrozumívání o změnách údajů je z pohledu čtenáře i editora obsluhován prostřednictvím eGON služeb ISZR.

Podpora procesu vyrozumívání o změnách údajů předávaných prostřednictvím referenčního rozhraní z publikačních AIS bude řešena rozšířením eGON rozhraní ISZR.

Provedení změny údaje, který je publikován prostřednictvím referenčního rozhraní:

• AIS editora, jímž editované údaje o subjektu vedeném v ROS jsou publikovány prostřednictvím referenčního rozhraní, zapíše každou změnu publikovaného údaje (identifikace údaje dle RPP) jím vedené agendy prostřednictvím eGON služby ISZR do ROS.

eGON služba ISZR předává data o změně do ROS. V ROS je uložena informace o změně na úložiště změn včetně identifikace údajů (dle RPP), kterých se změna týkala.

AIS zapisuje: IČO, čas změny, identifikátor změny, seznam identifikátorů změněných údajů (identifikace údaje dle RPP, je svázán s agendou editora).

Získání změny údaje publikovaného na referenčním rozhraní:

• Čtenářský AIS volá rozšířenou verzi eGON služby publikované na eGON rozhraní ISZR (PULL).
• Čtenářský AIS je zaregistrován jako příjemce PUSH vyrozumívání o změnách údajů a vystavuje definované rozhraní pro příjem vyrozumívání o změnách údajů.

V rámci rozšíření procesu vyrozumívání o změnách údajů bude moci čtenářský AIS:

• Omezit čtení změn na základě časového intervalu, seznamu údajů, o jejichž změnách chce čtenář získat údaje, a na základě identifikace subjektů ROS, které jsou z pohledu čtenáře relevantní (například seznam IČO, typ osoby, právní forma a podobně).

V souvislosti se zavedením mechanismů vyrozumívání o změnách údajů vzniknou další dodatečné eGON služby, které řeší situace, které nejsou doposud řešitelné, nebo které lze řešit pouze s využitím složitých a komplexních mechanismů.

V rámci referenčního rozhraní bude možné:

• Získat seznam změněných údajů (v rámci oprávnění čerpající agendy), u kterých došlo pro konkrétní IČO (seznam IČO) v rámci zadaného časového intervalu ke změně.

Poznámka: aktuálně nelze jednoduše ověřit existenci změn konkrétních údajů pro konkrétní IČO bez čtení těchto údajů.

Získat seznam změn na základě územního členění (s ohledem na oprávnění čerpající agendy). Výstupem bude seznam změn, které se v rámci zadaného časového intervalu k takové změně, která ovlivňuje příslušnost obyvatele do uvedené územní působnosti.

V RPP jsou vedeny referenční údaje následujících objektech / subjektech údajů:

• Agenda a výkon agendy – kód objektu dle RPP 104-1.
• Právo a povinnost – kód objektu dle RPP 104-2.
• OVM a kategorie OVM – kód objektu dle RPP 104-3.
• SPUU a kategorie SPUU – kód objektu dle RPP 104-4.

Pro objekt “Agenda a výkon agendy” bude princip fungování obdobný jako mechanismus fungování v RPP.

Pro objekt “Právo a povinnost” - je svázáno s AIFO, respektive IČO, s ohledem na princip fungování ROB a ROS musí být informace o změně zapsána do těchto ZR.

Pro objekt “SPUU a kategorie SPUU” - jde o subjekt vedený v ROS, tedy změna s ohledem na výše popsaný princip musí být vedena v ROS.

Pro objekt “OVM a kategorie OVM” - dle stávající legislativy mají některé OVM právní subjektivitu, a tudíž jsou vedena v ROS, ale existují i OVM, které nemají právní subjektivitu a v ROS vedeny nejsou (přestože pro jejich identifikátor bylo rezervováno IČO v ROS, typický případ jsou městské části). Tuto situaci lze řešit buď zavedením obdobného mechanismu změn v RPP, nebo takovou úpravou zákona, která umožní vedení všech OVM v ROS a evidencí změn přímo v ROS.

Pro ostatní objekty / subjekty je v rámci ISSS vytvořen mechanismus umožňující vedení seznamu změn. ISSS zabezpečuje:

• Příjem informace o změně údaje.
• Propagaci informace o změně údaje.

V rámci mechanismu příjmu informace o změně údaje předává AIS publikátora do ISSS při každé změně publikovaného údaje informaci obsahující:

• Identifikátor změněného objektu / subjektu.
• Datum změny.
• Identifikátor změny.
• Typ změny.
• Seznam změněných údajů agendy (dle definice údaje agendy v RPP).

V rámci mechanismu propagace informace o změně údaje ukládá ISSS předané informace změnách údajů získané mechanismem příjmu informace o změně údaje v úložišti ISSS pro poskytování těchto informací strategií PULL a současně informace o změnách předává na čtenářské AIS.

Proces reklamace údaje publikovaného na referenčním rozhraní vychází z obecného architektonického schématu popisujícího princip fungování propojeného datového fondu.

Obrázek 12: Proces reklamace údaje publikovaného na referenčním rozhraní

Proces reklamace údaje se zahajuje v situaci, kdy “úředník” při výkonu agendy zjistí, že hodnota údaje, která byla získána čtením prostřednictvím referenčního rozhraní, neodpovídá realitě.

Popisovaný proces reklamace se netýká situací, kdy je nesprávnost zjištěna u hodnoty údaje, která nebyla získána prostřednictvím referenčního rozhraní (tj. například jde údaj, který je zpracováván AISem, se kterým ”úředník” pracuje přímo v rámci výkonu agendy). Tato situaci by měla nastat pouze v případě, že vykonávaná agenda je současně editorem nesprávných údajů.

Základní princip reklamace hodnoty údaje získaného prostřednictvím referenčního rozhraní lze shrnout do konstatování, že “reklamace se předává prostřednictvím referenčního rozhraní směrem doleva”.

Při předávání informace o reklamaci směrem k editorovi (tj. směrem “doleva”) musí být v rámci reklamace uveden zdroj reklamovaného údaje tak, aby byl v každém okamžiku zpracovávající systém předat reklamaci na systém, ze kterého informaci sám čerpal.

Specifickou situací jsou referenční údaje vedené v základních registrech a publikované prostřednictvím referenčního rozhraní. Informace o editorech údajů jsou evidovány v ZR, reklamace jsou řešeny individuálně na eGON rozhraní ISZR.

Výše uvedený popis předávání informace směrem k editorovi je zobecněním procesu, častou situací bude stav, kdy čtenář předá reklamaci prostřednictvím referenčního rozhraní s informací o zdrojovém systému (publikátoru) a publikátor bude zároveň editorem údaje.

Z výše uvedeného popisu plyne, že s výjimkou údajů vedených v ZR musí konzument údajů čtení pro provedení reklamace zpracovávat informaci o tom, z jakého zdroje údajů reklamovanou hodnotu získal, aby mohl reklamaci výše popsaným procesem provést.

Prezentace neboli ztvárnění údajů z propojeného datového fondu převádí technické vyjádření ve formě XML souboru do lidsky čitelné formy. Toto formou prezentace je nejčastěji zobrazení na obrazovce klientského zařízení (HTML a jeho varianty) a dokument ve formě PDF. Doposud byla tato úloha vnímána jako zcela nezávislá aktivita jednotlivých subjektů, které spravují webovské stránky, či vytváří PDF dokumenty.

Stávající proces normalizace ztvárnění údajů je založen na vzoru formulářů, které je přiloženy k normativním textům a stanovují vzhled daných formulářů. Tento postup vychází z převažujícího ztvárnění formulářů na papíře a je v současné době zcela archaický.

Propojený datový fond umožňuje zcela jednoznačnou definici a identifikaci jednotlivých údajů ve formě XSD předpisů vedených v Registru práv a povinností dle §54 odst. 1 písmeno c) zákona 111/2009 o základních registrech. Při prezentaci těchto údajů je tedy nutné definovat, jak budou umístěny na daném formuláři, jaký budou mít popis, omezení a podobně. Tuto úlohu řeší doporučení W3C doporučení pro XSL Transformaci (XSLT) v aktuální verzi 3.0 (https://www.w3.org/TR/xslt-30/).

XSLT 3.0 je jazyk určený pro transformaci XML dokumentů do jiných ztvárnění. Definicí formuláře je tedy nastavení pravidel pro transformaci jednotlivých kontextů (XML dokumentů), které obsahují údaje vyskytující se na příslušném formuláři. Takto definovaný formulář je pak jednotně interpretován (ztvárněn) při jeho použití.

Prvotní je tedy datová definice formuláře, která bude uložena v Registru práv a povinností, respektive AIS RPP. Použití formuláře pak musí respektovat tuto uloženou definici. Každý formulář obsahuje:

• Původce formuláře (Orgán veřejné moci, který ho definuje).
• ID formuláře.
• Případný podtyp formuláře.
• Verzi definice (pro jedno ID formuláře může existovat více verzí).
• Platnost verze OD-DO.
• Obsah definice formuláře v XSLT notaci.

Definice formuláře (daná verze daného formuláře) jednoznačně určuje potřebné datové zdroje (kontexty údajů agend v RPP), jejich transformaci pro daný formulář, umístění jednotlivých údajů v rámci formuláře atd. Současně určuje případné hlavičky a patičky formuláře, ostatní grafické prvky a případné jazykové verze.

Formulář může mít několik podtypů, vycházejících z kompletního formuláře. V dané situaci může být použít tento podtyp obsahující pouze část kompletního formuláře.

Při zpracování předpisu formuláře (XSLT definice) určený XSLT procesor na základě vstupních XML údajů a tohoto předpisu vytvoří ztvárnění formuláře.

V případě HTML ztvárnění, tedy HTML dokumentu na portále, je každý správce portálu zodpovědný za použití aktuální verze formuláře a použití buď kompletního formuláře či vybraného podtypu.

Pro zajištění jednotného ztvárnění formulářů ve formě PDF/A-3 dle normy ISO 19005-3 bude zajištěna správcem Informačního systému sdílené služby komponenta zajišťující jednotný převod XSLT formuláře do PDF/A-3 ztvárnění. Tato komponenta tedy na základě požadavku oprávněného subjektu (má odpovídající oprávnění k získání údajů v rámci potřebných datových kontextů vyžadovaných daným formulářem) vytvoří odpovídající PDF/A-3. Oprávněný subjekt následně takto vytvořené ztvárnění následně zpracovává, tedy případně opatřuje časovými razítky, kvalifikovanými pečetěmi atd. Jde tedy o funkcionalitu “univerzální PDF/A-3 tiskárny”.

Zákon č. 111/2009 Sb., o základních registrech, ukládá informačním systémům používat při komunikaci se základními registry neveřejný agendový identifikátor fyzické osoby (dále jen AIFO) – viz § 8, odst. 5. Takováto komunikace zaručuje, že subjekt práva je jednoznačně určen.

AIFO přiděluje fyzické osobě primární editor ROB. IS primárního editora ROB musí zajistit přidělení AIFO osobě až v okamžiku, kdy se subjekt práva zapisuje do ROB. Dále musí zajistit, aby při komunikaci s ostatními IS v rámci ISSS nikdy nevydal AIFO osoby, kterou ještě do ROB nezapsal.

Aby mohl jiný informační systém AIFO používat, musí jej nejprve získat. To se děje ztotožněním, tzn. vyhledáním osoby podle známých s osobou svázaných údajů, a to buď v ROB, v agendě primárního editora ROB, tedy v AISEO, AISC nebo EJFO, popřípadě v jiné agendě umožňující jednoznačné vyhledání fyzické osoby. Nejvýhodnější je využít jednoznačné údaje nebo jejich jednoznačné kombinace, například číslo a druh dokladu, identifikátor datové schránky, bezvýznamový směrový identifikátor BSI, sériové číslo kvalifikovaného certifikátu, kombinace jméno, příjmení nebo rodné příjmení a datum narození, rodné číslo, jméno, příjmení nebo rodné příjmení.

Ve všech případech odpověď obsahuje AIFO osoby – pokud si je uživatel jistý, že se osoba vyhledala správně, potvrdí ve svém systému ztotožnění osoby a AIFO uloží do svého informačního systému. AIFO je v odpovědi na vyhledání obsaženo pouze tehdy, je-ji vedeno v ROB.

AIFO je neveřejný údaj a správce informačního systému je povinen jej příslušným způsobem chránit.

Aby mohl informační systém využívat služby vyrozumívání o změnách údajů, musí každé AIFO přihlásit k odběru vyrozumění o změnách údajů (použije službu orgPrihlasAIFO). Systém vyrozumívání o změnách údajů toto přihlášení využívá pro odfiltrování nepřihlášených AIFO ze seznamu změn, takže pak do informačního systému přichází pouze seznam těch AIFO, k odběru jejichž změn se přihlásil. Obecně je proces vyrozumívání o změnách údajů popsán v kapitole 3.5.

Pokud nastane situace, kdy subjekt práva již není předmětem zpracování v informačním systému, zodpovídá správce systému za odhlášení AIFO z odběru vyrozumívání o změnách údajů (službou orgOdhlasAifo). Ukončením odběru vyrozumívání o změnách údajů se zabrání zbytečnému a neoprávněnému využívání údajů subjektu.

Data, která informační systém získává bez použití AIFO, nelze považovat za referenční, ani v případě jednoznačné odpovědi z dotazovaného systému.

Právnické osoby a podnikající fyzické osoby jsou jednoznačně identifikovány pomocí identifikačního čísla osoby (IČO). IČO je na rozdíl o AIFO veřejný údaj. Pro podnikající fyzické osoby platí, že IČO má být pevně svázáno s AIFO podnikající osoby a že tato vazba je jednoznačná.

Typicky jsou fyzické osoby v ROS vedeny právě pomocí AIFO a jejich údaje se vedou pomocí referenční vazby do ROB. Jedná se o údaje jméno, příjmení a adresa pobytu. V případech, kdy fyzická osoba není vedena v ROB, je možné místo AIFO do ROSu zapsat jméno, příjmení a adresu pobytu textem. Tato nutnost by měla odpadnout v okamžiku, kdy bude možné takovou fyzickou osobu zapsat do EJFO.

ROS umožňuje vyhledání IČO podle údajů i podle AIFO.

Na základě IČO je možné přijímat vyrozumívání o změnách údajů o změnách údajů. Obecně je proces vyrozumívání o změnách údajů popsán v kapitole 4.5. Vyrozumění o změnách údajů ROS jsou prováděna na základě na přihlášení / odhlášeni IČO k vyrozumívání o změnách údajů (rosPrihlasIco / rosOdhlasIco).

Pokud nastane situace, kdy IČO již není předmětem zpracování v informačním systému, zodpovídá správce systému za odhlášení IČO z odběru služby vyrozumívání o změnách údajů (službou rosOdhlasIco). Ukončením odběru vyrozumívání o změnách údajů se zabrání zbytečnému a neoprávněnému využívání údajů osoby z ROS.

Data, která informační systém získává bez použití IČO, nelze považovat za referenční, a to ani v případě jednoznačné odpovědi.

Vyhláška č. 53/2007 Sb., o referenčním rozhraní, v § 3 odst. 3 ustanovuje povinnost informačního systému veřejné správy uskutečňujícího vazbu vytvářet záznamy o vazbě.

Záznamy obsahují:

1. identifikaci informačního systému veřejné správy, který žádá o službu nebo informaci,
2. čas přijetí žádosti o službu nebo informaci,
3. jednoznačný identifikátor požadavku dotazujícího se systému,
4. strukturu předávaných dat a technický otisk hodnot údajů (HASH),
5. údaje o tom, zda byla služba nebo informace informačnímu systému veřejné správy poskytnuta.

Zákon č. 110/2019 Sb., o zpracování osobních údajů, ukládá v návaznosti na nařízení GDPR v § 36 spravujícímu orgánu povinnost pořizovat záznamy alespoň o operacích shromáždění, vložení, pozměnění, kombinování, nahlédnutí, předání, sdělení a výmazu osobních údajů. Záznamy o operacích shromáždění, vložení, nahlédnutí nebo sdělení umožňují určit a ověřit důvod a čas těchto operací, totožnost osoby provádějící operaci a totožnost příjemce. Záznamy jsou uchovávány po dobu 3 let od výmazu osobních údajů, ke kterým se vztahují.

Zákon č. 111/2009 Sb., o základních registrech, ve znění zákona č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů.

Podle ustanovení § 18 odst. 5 a § 19 odst. 5 zákona o základních registrech, ve znění účinném od 1. 2. 2022, registr obyvatel vede provozní údaje o využívání nebo poskytování údajů z registru obyvatel.

Záznamy obsahují:

1. kód agendy,
2. kód agendového informačního systému, prostřednictvím kterého byly údaje využity,
3. uživatelské jméno fyzické osoby, která je nositelem role, které je neveřejné,
4. označení subjektu, pro jehož účely se údaje využívají nebo poskytují,
5. datum a čas využívání nebo poskytnutí údajů,
6. obchodní firma nebo název nebo jméno, popřípadě jména, a příjmení subjektu, kterému jsou na základě žádosti poskytovány údaje podle § 58a,
7. datum a čas udělení nebo odvolání souhlasu subjektu práva s poskytnutím údajů podle § 58a,
8. identifikátor souhlasu,
9. agendový identifikátor fyzické osoby pro agendu registru obyvatel, jejíž údaje jsou využívány nebo poskytovány,
10. důvod a konkrétní účel přístupu do registru obyvatel.

Podle ustanovení § 26 odst. 4 odst. e) zákona o základních registrech, účinného od 1. 2. 2022, registr osob vede provozní údaje o využívání údajů z registru osob.

Podle ustanovení § 57 odst. 2 zákona o základních registrech orgán veřejné moci, který byl zaregistrován pro výkon agendy, vede záznamy o přístupu k údajům obsaženým v základních registrech, nejde-li o přístup k údajům veřejně přístupným, a uchovává je po dobu 2 let.

Záznamy obsahují:

1. uživatelské jméno fyzické osoby, která je nositelem role a která přístup učinila,
2. roli, ve které fyzická osoba přístup učinila,
3. výčet údajů, ke kterým fyzická osoba, která je nositelem role, získala přístup,
4. datum a čas přístupu,
5. důvod a konkrétní účel přístupu.

Podle ustanovení § 57 odst. 2 zákona o základních registrech, účinného od 1.2.2022, Ministerstvo vnitra vede záznamy o přístupu k údajům obsaženým v základních registrech, nejde-li o přístup k údajům veřejně přístupným, a uchovává je po dobu 2 let.

Záznamy obsahují:

1. agendový informační systém,
2. kód agendy,
3. uživatelské jméno fyzické osoby, která je nositelem role,
4. označení subjektu, pro jehož účely se údaje využívají nebo poskytují,
5. roli, ve které fyzická osoba přístup učinila,
6. výčet údajů, ke kterým byl získán přístup,
7. datum a čas přístupu,
8. důvod a konkrétní účel přístupu.

Podle ustanovení § 7 odst. 4 zákona o základních registrech, účinného od 1. 2. 2022, Správa základních registrů vede pro účely správy informačního systému sdílené služby záznam o přístupu k údajům vedeným v agendových informačních systémech, nejde-li o přístup k údajům veřejně přístupným, a uchovává jej po dobu 2 let.

Záznam obsahuje:

1. označení agendového informačního systému,
2. kód agendy,
3. uživatelské jméno fyzické osoby, která je nositelem role,
4. označení subjektu, pro jehož účely se údaje využívají nebo poskytují,
5. roli, ve které fyzická osoba přístup učinila,
6. výčet údajů, ke kterým byl získán přístup,
7. datum a čas přístupu,
8. důvod a konkrétní účel přístupu.

Podle ustanovení § 7 odst. 5 účinného od 1.2.2022 Správa základních registrů vydá na žádost osoby, o níž se vedou údaje v agendových informačních systémech, záznam o přístupu k těmto údajům. Záznam o přístupu k údajům vedeným v agendových informačních systémech se vydává rovněž v podobě ověřeného výstupu z informačního systému veřejné správy.

Zákon č. 12/2020, o právu na digitální služby

Podle ustanovení § 11 odst. 4 účinného od 1.2.2020 má uživatel služby právo na poskytnutí informace o změně údajů vedených o své osobě nebo svých právech a povinnostech v základních registrech nebo agendových informačních systémech neprodleně po jejich změně do datové schránky. Správce příslušného základního registru nebo agendového informačního systému poskytne uživateli služby informaci podle věty první v rozsahu údajů, které nevyužívá z jiného základního registru nebo agendového informačního systému.

Identifikace navazujících logových záznamů

Záznamy logů jednotlivých systémů musí umožnit dohledat jednotlivé kroky zpracování transakce. Dotazující systém musí zajistit generování jednoznačného ID požadavku (GUID) pro všechny své dotazy. Tento GUID je součástí dotazu ve všech fázích zpracování, a navíc je k němu v referencím rozhraní připojen jedinečný GUID rozhraní. Tyto identifikátory musí být uloženy v logu dotazujícího systému, v logu rozhraní i v logu publikačního systému. Pokud publikační systém v rámci zpracování odpovědi potřebuje vygenerovat dotaz do jiného systému, tzn. vzniká kompozitní transakce, použije pro dotaz do referenčního rozhraní původní GUID dotazující agendy (negeneruje tedy vlastní GUID).

Referenční rozhraní a všechny ostatní systémy musí být schopny na základě GUID požadavku čtenáře, publikačního systému nebo referenčního rozhraní dohledat řetězec všech navazujících požadavků včetně všech údajů, které jsou systémy povinny logovat. Tím je zaručena úplná auditovatelnost jakéhokoli dotazu na referenční rozhraní.

Získání informací pro logování

Všechny služby vyžadují vyplnění informací o žadateli. Tyto informace jsou shromážděny ve struktuře ZadostInfo a jsou až na jednu výjimku povinné. Zapsáním těchto údajů do logu jsou splněny všechny požadavky pro logování dotazovací části transakce. Je nutno požadovat, aby důvod a účel dotazu byl vždy uveden konkrétně, nikoli např. odkazem na paragraf zákona, podle kterého má dotazující na údaje nárok, ale např. odkazem na číslo jednací.

Tabulka 6: Struktura ZadostInfo

Referenční rozhraní loguje všechny údaje uvedené v předchozí tabulce, seznam přenesených údajů (bez konkrétních hodnot údajů) a jednosměrnou šifru přenášené zprávy. Zprávu včetně přenášených údajů nelze z šifry rekonstruovat, ale lze ověřit, že předložená zpráva je totožná s přenášenou.

Informace o vydaných údajích a interní identifikátory subjektů údajů pro všechny odpovědi musí vycházet z informací uložených v odpovídajícím informačním systému.

Jednotlivé další prvky PPDF logují celý otisk zprávy, kterou vydaly nebo přijaly, tedy včetně hodnot údajů. Pokud tyto logy obsahují osobní údaje je nutno ukládat je v šifrované podobě a přístup k nim logovat podle stejných pravidel jako pro přístup k osobním údajům. Správce informačního systému má povinnost tyto logy chránit před zneužitím a pozměněním a v případě potřeby musí být schopen určit fyzickou osobu, které uživatelské jméno v logu patří.

Pokud údaje využívá automatizovaný proces (například proces automatických aktualizací), zodpovídá za jeho přístupy k osobním údajům správce sytému.

Pro účely dokazování vydaných údajů (může dojít ke sporu, jaká data byla z informačního systému vydána, nebo zda došlo ke správnému ztotožnění subjektu) je vhodné, aby informační systém ukládal i úplné XML dotazu a odpovědi. Je však nutné mít na zřeteli, že pokud logy obsahují nejen výčet názvů údajů, ale také hodnoty osobních údajů, je nutné tyto logy při zpracování chránit stejně jako jiné osobní údaje.

Referenční rozhraní a publikační systémy musí povinně provádět audit svých logů tak, aby zamezily neoprávněnému využívání osobních údajů a nadměrnému zatěžování systémů ISVS. Tento audit by měl zejména ověřovat:

• Správné vyplňování položky DuvodUcel. Tato položka má uvádět konkrétní důvod využití údajů a s výjimkou automatizovaného zpracování vyrozumění o změnách údajů by měla odpovídat aktuálnímu úkonu, který uživatel uvádí. Položka by tedy měla obsahovat řadu jednoznačných hodnot.
• Správné vyplňování položky Uzivatel. S výjimkou automatizovaného zpracování vyrozumění o změnách údajů by toto pole mělo obsahovat identifikaci uživatelů. Položka by měla obsahovat dostatečné množství identifikátorů uživatelů a počet jejich dotazů by měl odpovídat možnostem fyzického uživatele.
• Uvádění správného kódu agendy. Řada AIS je přihlášena k vykonávání více agend, ale některé z nich jsou celostátní. Pokud dojde k tomu, že dotazující se systém lokálního OVM použije k dotazu agendu s centrálním AIS, je to pravděpodobně zneužití údajů.
• Správné využívání systému vyrozumívání o změnách údajů. Typicky by se měly vyrozumění o změnách údajů zpracovávat jen několikrát denně a neměly by opakovaně číst stejné změny.
• Seznam čtených údajů by neměl vždy odpovídat maximálnímu rozsahu údajů, které má dotazující se systém právo získat. Podle zákona se má dotazovat pouze na údaj potřebné pro provedení konkrétního úkonu.
• Správné využívání AIFO a IČO. Čtenář má subjekt ztotožnit a potom pro dotazy využívat jeho identifikátor, nikoli jej znovu a znovu ztotožňovat. Kontrola je možná sledováním poměru využití jednotlivých služeb.

Služba Probe slouží k ověření, že dotazovaný systém je funkční. Služba předává dotazujícímu výsledek jednoduché diagnostiky registru obyvatel typu "běží / neběží". Z tohoto důvodu nemá služba žádné vstupní parametry.

Protože každý systém PPDF musí ukládat logy podle předchozí kapitoly a bez jejich zápisu nemůže žádné údaje vydávat, musí tato služba ověřit funkčnost logovacího systému.

Každý publikační systém poskytující kritické služby musí v rámci služby probe udat, v jakém režimu pracuje. Možnosti jsou

• Plný provoz: normální provoz, všechny služby jsou v provozu.
• Omezený provoz: omezený provoz, v provozu jsou pouze definované služby kritického jádra.
• Mino provoz: systém neposkytuje služby (stav při havárii, pokud není přerušena komunikace).

Základní registry

Vzhledem k významu základních registrů, který mají z hlediska důvěryhodných a bezpečných elektronických služeb veřejné správy, věnovala Evropská komise ve spolupráci s členskými státy této problematice několik studií a dokumentů²⁾.

V kontextu přeshraničních služeb veřejné správy považuje základní registry za pilíř eGovernmentu, neboť představují důvěryhodný, autentický a autoritativní zdroj informací spravovaný orgánem veřejné správy či pověřenou organizací. Dle Evropského rámce interoperability 2.0, představují základní registry spolehlivé zdroje základních informací o fyzických a právnických osobách, koncesích, budovách a územní identifikaci. Následně jsou zdroje informací o dalších objektech (jako jsou například vozidla, či pozemní komunikace) vázány na tyto spolehlivé zdroje.

Základní registry jsou praktickou aplikací zásady „data pouze jednou“, která přispívá k uživatelské přívětivosti služeb. Namísto toho, aby veřejná správa opakovaně vyžadovala údaje, které má k dispozici, dokáže je při poskytování digitálních služeb mezi sebou sdílet a opětovně využívat.

Interoperabilita

Interoperabilita neboli schopnost 2 a více systémů vzájemně spolupracovat a vyměňovat si údaje prostřednictvím důvěryhodných služeb, je jedním z pilířů nejen českého, ale i evropského eGovernmentu či eGovernance.

Vzhledem k technologickému pokroku a snaze moderní veřejné správy naplňovat zásadu „digital by default“ (tj. budovat přednostně digitální služby tam, kde je to z podstaty věci možné), se stále více služeb poskytovaných koncovým klientům přesouvá z fyzického světa do elektronického a je nutné řešit důvěryhodné výměny údajů a s ní spojené problémy jako elektronická identita, bezpečná přenosová infrastruktura, principy „jen jednou“, atd.

Interoperabilita je základním předpokladem elektronické komunikace a výměny informací mezi orgány veřejné správy, mezirezortně a přeshraničně. Je tedy i základním předpokladem pro dosažení jednotného digitálního trhu. Programy interoperability v EU se v průběhu času vyvíjejí. Zpočátku se týkaly dosažení interoperability v určitých prioritních oblastech, poté zavádění společné infrastruktury. V poslední době se začaly zabývat interoperabilitou na sémantické úrovni. Některé z otázek, které je třeba řešit jako další, aby bylo dosaženo plnohodnotných veřejných služeb, je řízení, slučitelnost právních předpisů, sladění organizačních procesů a zabezpečení přístupu ke zdrojům údajů.

Čtyři úrovně interoperability

Evropský rámec interoperability³⁾ při vývoji mezirezortních a přeshraničních služeb veřejné správy doporučuje zohledňovat 4 úrovně interoperability – právní (legislativní), organizační, technickou a sémantickou.

Ke každé úrovni nabízí Evropský rámec interoperability specifická doporučení, jak překonávat překážky, na něž může mezirezortní a přeshraniční poskytování elektronických služeb narážet⁴⁾.

Evropské služby veřejné správy zahrnují všechny rezortní a mezirezortní služby s přeshraniční dimenzí, které si orgány veřejné správy poskytují navzájem nebo které poskytují občanům a firmám v Evropské unii. Pro včasné zohlednění požadavků přeshraniční interoperability a potenciálních přeshraničních digitálních služeb můžeme vycházet z informací o projektech, které řeší či řešit budou, výměnu údajů a služeb. Jmenovat lze:

• >

  Implementace eIDAS

V rámci nařízení eIDAS jsou členské státy povinny vytvořit společný rámec, který rozpozná elektronikou identitu z jiných členských států a zároveň zjistí jejich pravost a bezpečnost, což zjednodušeně znamená umožnit výměnu zaručených identit. Zaručená identita je v ČR řešena pomocí existence subjektu práva v základním registru obyvatel a objektu práva v základním registru osob a základním registru územní identifikace, adres a nemovitostí.

Stav AS IS:

Implementace eIDAS do národního prostředí na business vrstvě architektury byla provedena vytvořením zákona 250/2017 Sb. – Zákon o elektronické identifikaci. Z technického pohledu potom implementací Národní Identitní Autority (NIA), kde součástí projektu je i výstavba mezinárodní gateway pro přeshraniční identifikaci a autentizaci občanů z ostatních členských států EU a tím zajištění využití jednotlivých služeb poskytovaných v ČR. Dále také ohlášením identifikačního elektronického prostředku na úrovni vysoká, kterým je občanský průkaz.

Stav TO BE:

Další kroky povedou k rozvoji výše uvedených technických prostředků k elektronizaci služeb na národní úrovni, aby bylo možné poskytovat co nejvíce služeb v rámci interoperability ostatním členským státům EU. Nyní prováděné legislativní změny a zavedení katalogu služeb, povede ke kategorizaci jednotlivých služeb a jejich následné poskytnutí pro přeshraniční využívání.

Gestorem za tuto aktivitu na národní úrovni je Ministerstvo vnitra.

• SDG – Jednotná digitální brána ⁵⁾

Stav AS IS:

V současné době je implementována 1. etapa tohoto projektu. Jedná se o poskytnutí informací o jednotlivých službách stanovených projektem. Technické řešení představuje vybudování katalogu služeb do registru práv a povinností a následnou úpravu pro potřeby projektu SDG.

Stav TO BE:

Druhou etapou projektu je poté výměna jednotlivých údajů k definovaným službám projektu SDG. Pro výměnu údajů se plánuje použití technického řešení na bázi komunikačního protokolu AS4.

Gestorem za tuto aktivitu na národní úrovni je z věcného pohledu Ministerstvo obchodu a průmyslu a z technického pohledu Ministerstvo vnitra.

• >

  EESSI – Elektronická výměna informací o sociálním zabezpečení

Stav AS IS:

V současné době jsou implementovány 3 kontaktní body (access point) a jsou napojeny na centrální komunikační prvek, vytvořený evropskou komisí. 1. access point je implementován na České kanceláři pojistitelů, 2. access point je implementován na Ministerstvu práce a sociálních věcí a 3. access point je implementován na České správě sociálního zabezpečení. Všechny access pointy jsou připraveny přijímat i odesílat elektronické formuláře. Dle projektu EESSI k výměně formulářů dochází zatím v rámci omezeného počtu služeb.

Stav TO BE:

Dochází k rozvoji technického řešení pro výměnu elektronických formulářů celého rozsahu služeb, který pokrývá projekt EESSI.

Gestorem této aktivity na národní úrovni jsou Česká kancelář pojistitelů, Ministerstvo práce a sociálních věcí a Česká správa sociálního zabezpečení.

• >

  CPSV – Základní slovník veřejných služeb

Stav AS IS:

V současné době z pohledu business architektury, byl schválen zákon 12/2020 Sb. – Zákon o právu na digitální služby, který zakládá prostředí pro vytvoření katalogu služeb a z technického pohledu je prováděna implementace katalogu služeb do registru práv a povinností.

Stav TO BE:

Plánuje se rozvoj katalogu služeb, aby byla možná výměna údajů vztahujících se ke službám v rámci interoperability.

Gestorem této aktivity na národní úrovni je Ministerstvo vnitra

• >

  ABR – Přístup k základním registrům⁶⁾

Stav AS IS:

Základní registry byly postaveny v roce 2012. Za tuto dobu dochází k jejich neustálému rozvoji v národním prostředí, aby splňovali veškeré legislativní, technické, architektonické a jiné požadavky na neustále se vyvíjející státní správu.

Stav TO BE:

Rozvoj základních registrů je prováděn kontinuálně a především ve vazbě v reakci na vývoj projektu ABR. Interoperabilita je jedním ze základních principů na národní úrovni architektury veřejné správy, o čemž svědčí tento a další dokumenty.

Gestorem za tuto aktivitu na národní úrovni je Ministerstvo vnitra.

• >

  BRIS – Systém propojení obchodních rejstříků

Stav ASIS:

V současné chvíli jsou již propojené obchodní rejstříky všech členských států EU (dostupné z url: https://e-justice.europa.eu/content_find_a_company-489-cs.do?clang=cs). Zde je možné vyhledat a zobrazit všechny základní informace o obchodních společnostech a jejich příslušné listiny (některé státy mají stažení listin zdarma, některé za poplatek).

Stav TO BE:

V budoucnosti chce Evropská komise BRIS využít zejména také pro skutečné majitele a informace o nich. Zároveň probíhají práce a přípravy na aktualizaci technologií a příslušných integrací – tzv. BRIS 2.0.

• >

  Elektronické propojení insolvenčních rejstříků v EU

Stav AS IS:

Aktuálně je ČR jako jedna z devíti zemí připojena na testovací verzi IRI (dostupné z url https://e-justice.europa.eu/content_interconnected_insolvency_registers_search-246-en.do). V projektu došlo k pozdržení, neboť ne všechny státy mají insolvenční rejstříky veřejné (některé je mají zpoplatněné atp.).

Stav TO BE:

V současné chvíli probíhá přepracování struktury DB systému ISIR a úprava příslušných webových služeb v návaznosti na upravenou specifikaci API portálu evropské e-Justice. Změny v systému ISIR budou plánovaně distribuovány v červnu tohoto roku.

Gestorem za tuto aktivitu na národní úrovni je Ministerstvo spravedlnosti.

• >

  MOSS – Zjednodušení jednoho správního místa DPH

Gestorem za tuto aktivitu na národní úrovni je Generální finanční ředitelství.

• >

  ESPD – Jednotné evropské osvědčení pro veřejné zakázky

Jednotné evropské osvědčení pro veřejné zakázky (dále také jako „JEO“) je nástroj, jehož cílem je snížení jak administrativní tak i finanční náročnosti účasti v zadávacím řízení. Prostřednictvím tohoto instrumentu totiž jednotliví dodavatelé v rámci prokazování splnění podmínek účasti mohou předložit standardizované čestné prohlášení namísto dosavadní nutnosti předkládat jednotlivá osvědčení, certifikáty a jiné doklady (nadto často požadované v různých formách dle konkrétních požadavků toho kterého zadavatele). To má usnadnit účast zejména malým a středním podnikům nebo také zahraničním dodavatelům, kteří již nebudou muset pátrat po vzorech certifikátů užívaných v zahraničí. JEO má tedy pro tyto subjekty potenciál zjednodušit přípravu jejich nabídek, aby měli širší možnost zúčastňovat se jednotlivých zadávacích řízení. V případě této širší účasti dodavatelů pak mají zadavatelé možnost získat plnění v lepší kvalitě a za nižší cenu. Výsledkem tak má být větší demokratizace procesu zadávání veřejných zakázek a podpora volné soutěže v rámci společného evropského trhu.

Další projekty a iniciativy EU:

• >

  Evropská e-karta služeb

• >

  Právo obchodních společností

• >

  Dodatek k diplomu a Evropský systém přenosu a akumulace kreditů⁷⁾

Každý údaj (pokud není upraven speciální bezpečnostní či jinou výjimkou, např. zákon č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti) vyměňovaný mimo území ČR musí být referenčním údajem nebo mít vazbu na referenční subjekt či objekt vedený v základních registrech a musí být o výměně vedet auditní záznam.

ISA²: V rámci programu Evropské komise ISA² byly definovány slovníky pro základní objekty a subjekty vizte https://ec.europa.eu/isa2/solutions/core-vocabularies_en. Obsah těchto slovníků je pouze základní a nedosahuje plného výčtu údajů, které je potřeba vést v informačních systémech pro následnou interoperabilitu. Dostatečný výčet obsahují až slovníky SEMIC vizte zde https://joinup.ec.europa.eu/page/core-vocabularies, jejichž podrobnější popis je v příloze 2.

Provoz a komunikace: Na perimetr základních registrů, vzhledem ke všem výše zmíněným skutečnostem, budou kladeny požadavky bezodstávkového provozu (především čtecí části), které umožní, aby interoperabilita údajů mohla probíhat bezproblémově v režimu 7x24.

Pro interoperabilitu referenčních údajů neexistuje nyní žádný nástroj ani legislativní prostředí. Prvně by se tedy musel zajistit legislativní předpis, který přeshraniční výměnu referenčních údajů umožní a následně vybudovat AIS, který by sloužil pro přeshraniční předávání údajů, aby se zajistil princip, že se základními registry, potažmo informačním systémem základních registrů, komunikuje pouze informační systém typu AIS. Komunikační infrastruktura by byla stejná jako v případě vnitrostátní komunikace, tedy využití infrastruktury KIVS a CMS s publikací do evropské sítě TESTA-ng.

Pro interoperabilitu nereferenčních údajů existuje vždy nějaký právní předpis české či evropské úrovně a pro komunikaci se většinou využívají VPN nástroje v prostřednictví internetu. Tento postup by chtělo co nejvíce přesunout do prostředí TESTA-ng a eliminovat komunikaci skrze veřejný internet.

Důležité je podotknout, že správcem infrastruktury TESTA-ng je Evropská komise a slouží pro podporu aplikací a služeb naplňující některou evropskou politiku, kterou spravuje některý z orgánů Evropské komise. Pokud by se našla aplikace či služba, která by tuto infrastrukturu chtěla využívat a nesplňovala kritéria výše, může se vstoupit v bilaterální jednání.

Kromě komunikace v rámci TESTA-ng, Evropská komise nyní preferuje výměnu údajů s využitím komunikačního protokolu AS4 ve vazbě na building block eDelivery⁸⁾ v kombinaci s eIDAS. Každý systém, u kterého dochází k přeshraniční výměně údajů s využitím protokolu AS4, by měl mít implementovanou komponentu Domibus⁹⁾, kde samotná komunikace je pak prováděna prostřednictvím volného internetu. V rámci přeshraniční výměny údajů se s touto okolností na národní úrovni počítá a budou učiněny kroky pro rozvoj infrastruktury, které povedou k vybudování centrální komponenty, jakožto sdílené služby v rámci centrálního místa služeb (CMS), kterou budou moci jednotlivé instituce čerpat, aniž by bylo nutné, aby každý úřad implementoval technické prostředky na své straně.

Tento odstavec definuje znakové sady pro předávání textových údajů a pravidla pro vyhledávání v textových údajích vedených Informačních systémech ve Veřejné správě ČR (nikoli pouze informační systémy veřejné správy ve smyslu zákona o informačních systémech veřejné správy).

Každý správce informačního systému musí zajistit správnou interpretaci údajů získaných prostřednictvím referenčního rozhraní a na referenční rozhraní předávat údaje dle tohoto dokumentu.

Z hlediska snižování nákladů na provoz a správu informačních systémů doporučujeme, aby i ukládání údajů v informačních systémech veřejné správy respektovalo uvedená pravidla tak, aby nemusely být vytvářeny náročné převodníky z jiných znakových sad při komunikaci přes referenční rozhraní.

Tedy platí:

• Celý propojený datový fond pracuje s touto jedinou definicí (bez ohledu na aktuální způsob uložení textových údajů v informačních systémech).
• PPDF je schopen přenášet plnou sadu UNICODE v kódování UTF-8 a údaje musí být přenášeny v této znakové sadě.

• Metody vyhledávání se používají tak, jak jsou uvedeny v dokumentu níže v kapitole „Vyhledávání textového údaje“.

Povinnosti správců ISVS:

• V ISVS je možné ukládat údaje pouze v souladu s nařízením vlády č. 594/2006 Sb. (tj. celý řetězec je schopen přenést třeba čínský znak, ale není umožněn jeho zápis, protože je to v rozporu s vyhláškou).
• V ISVS musí být zavedeny kontroly zakazující ukládat samostatné akcenty a čísla v textu kam nepatří (jména). Současně nesmí být ukládány speciální znaky tam, kde nepatří, viz tabulky níže.

Předávání prostřednictvím referenčního rozhraní

Při předávání údajů mezi informačními systémy ve veřejné správě musí být vždy použito znakové sady Unicode a kódování UTF-8. Předané znaky musí být interpretovány v této znakové sadě. Pokud je při předávání údajů využita i jiná znaková sada, pak údaj musí být povinně uveden i ve znakové sadě Unicode v kódování UTF-8 a takto uvedený údaj je referenční. Údaj v jiné znakové sadě je pouze dodatečným tvarem údaje a má pouze informativní charakter.

Předávané údaje musí být normalizovány do NFC (Normalization Form Canonical Composition).

Pro účely tohoto dokumentu rozdělujeme symboly Unicode na:

• písmena (v poli name uvedeno slovo LETTER nebo LIGATURE),
  • malá písmena (v poli name uvedeno slovo SMALL LETTER nebo SMALL LIGATURE),
  • velká písmena (v poli name uvedeno slovo CAPITAL LETTER nebo CAPITAL LIGATURE),
  • latinková písmena (v poli name uvedeno slovo LATIN),
  • číslice (symboly ze skupiny C0 Controls and Basic Latin v jejichž poli name uvedeno slovo DIGIT), nepovolujeme použití znaků pro zlomky, římské číslice aj. z bloku U+2150 až U+218F.
• řídicí znaky (vybrané kódy ze skupiny C0 Controls and Basic Latin: U+0000 až U+001F, U+007F až U+009F).

Tento dokument definuje způsob nakládání s písmeny a speciálními znaky, které nejsou číslicemi nebo řídícími znaky. Číslice a řídící znaky se přenáší též ve znakové sadě UNICODE v kódování UTF-8, nejsou však pro ně definovány způsoby vyhledávání jiné než přímá shoda.

Při přenášení textových údajů, musí být zajištěno, že diakritická znaménka (viz. následující tabulka) nebudou použita samostatně. Musí být také zajištěno, že v textových polích nebude použita číslice, pokud není v textovém poli povolena (např. u Jména či Příjmení) a nedojde pak časté záměně číslice 0 a písmena O či číslice 1 a písmena malé L (l).

Tabulka 7: Přehledová tabulka diakritických znamének

Vyhledávání textového údaje

Při vyhledávání dle textového údaje musí být dostupné minimálně následující metody

• CSAS (Case Sensitive, Accent Sensitive) – rozlišování malých a velkých písmen, respektování národních znaků (diakritiky) -tj. text je vyhledáván tak jak je předán
• CIAS (Case Insensitive, Accent Sensitive) – nerozlišování malých a velkých písmen, respektování národních znaků (diakritiky).

Doporučením je dostupnost následující metody

• CIASCII (Case Insensitive, ASCII) – nerozlišování malých a velkých písmen, transliterace na základní sadu písmen ASCII (kódy 0x41 až 0x5A) popř. náhrada speciálních symbolů.

Převod pro mód CIASCII je proveden následujícím způsobem:

• Písmena jsou transliterována podle tabulky LATIN písmen uvedené v Příloze 1 převedením na písmeno s názvem vzniklým odstraněním názvu připojeného diakritického znaménka a případnou změnou SMALL na CAPITAL.
• Ligatury jsou transliterovány převodem tabulky Transliterace ligatur uvedené v Příloze 1.
• Písmena, ke kterým není postupem podle prvního bodu 1 nalezen ekvivalent v základní sadě ASCII, jsou převedena podle tabulky Transliterace písmen bez ekvivalentu v ASCII uvedené v Příloze 1.

Pro bezpečné fungování a postupného rozšiřování eGovernmentu je základním předpokladem poskytování spolehlivých služeb, které jsou nabízeny ve smluvených a takto také predikovaných parametrech.

Pro určení základních parametrů služeb je klíčové dodržet:

• Dostupnost (systémy poskytující služby jsou dostupné ve smluvených režimech, bez výpadků a s omezeným počtem odstávek).
• Důvěrnost (informace jsou přístupné jen tomu, kdo je oprávněn se s nimi seznamovat).
• Integritu (služby jsou poskytovány tak, aby nemohlo dojít k neautorizované modifikaci systému a informací).

Pro spolehlivé poskytování služeb PPDF hraje dostupnost datových rozhraní klíčovou roli. Funkčnost a vysoká dostupnost referenčního rozhraní při přístupu k obecným údajům uloženým v PPDF je jednou ze základních stavebních kamenů celého eGovernmentu. Bez zaručené dostupnosti služeb PPDF nelze realizovat myšlenku sdílení údajů.

Vlastní dostupnost je pak možné chápat jako provozní spolehlivost rozhraní (služby jsou dostupné) a jeho transakční výkon (služby jsou odbavované s odpovídající odezvou).

• Spolehlivosti rozhraní – služby jsou dostupné bez výpadků a s omezeným počet odstávek – jedná se o požadavek na architekturu systémů – součin dostupností všech dílčích systémů včetně podpůrných aktiv.
• Kapacita rozhraní – služby jsou dostupné, odbavované s odpovídající odezvou a systém umožňuje rozšiřování jeho kapacity – jedná se o požadavek na výkonnost systémů – součet doby odbavení všech dílčích systémů.

Spolehlivost rozhraní

Služby poskytované v rámci propojeného datového fondu mohou být na referenčním rozhraní poskytovány s různou dostupností a definovanou dobou odezvy (SLA).

Služby klientské

• Výdej údajů – čtení údajů z PPDF – jako klient vystupuje občan, úředník, podnikatel.
• Editace údajů – zápis/změna údajů v PPDF – jako klient vystupuje občan, úředník, podnikatel.
• Ověření identity – autentizační služby – jako klient vystupuje občan.

Služby podle způsobu obsluhy požadavku

• Synchronní.
• Asynchronní.

Tabulka 8: Režim využívání služeb z pohledu požadavku klientů služeb

Tabulka 9: Režim využívání služeb z pohledu poskytovaných služeb

Zajištění dostupnosti z pohledu poskytovaných služeb

Z hlediska uživatele služeb propojeného datového fondu (čtenář, editor) není podstatné technické vyjádření dostupnosti služeb vyjádřené tradičně ve formě SLA, ale skutečná dostupnost služeb včetně plánovaných odstávek. Plánované odstávky nejsou typicky vykazovány jako porušení dostupnosti, nicméně pro uživatele je služba fakticky nedostupná.

Níže uvedené rozdělení služeb je tedy navrženo právě z pohledu uživatele služeb a má zásadní důsledky na architekturu poskytování jednotlivých služeb. Pokud má pro danou službu být zajištěna kritická dostupnost, či se jedná o primární službu, pak musí být technická a aplikační architektura navržena tak, aby bylo zajištěna nepřetržitá dodávka služeb i v případě plánované údržby.

Každý informační systém či část komunikační infrastruktury, která se podílí na poskytování kritické služby či primární služby tedy musí mít navrženy a implementovány mechanismy zajišťující bezodstávkové poskytování služeb.

• Elektronická identifikace – čtení údajům z Registru obyvatel, čtení údajů z převodníku ORG, část ISZR zajišťující uvedené služby, služby elektronické identifikace Národního bodu pro identifikaci a autentizaci.

• Autentizační služby – ověření Bezpečnostního osobního kódu v ROB, služby kvalifikovaných správců dle zákona 250/2017 o elektronické identifikaci a návazné služby Národního bodu pro identifikaci a autentizaci
• Přístup k datům PPDF – komponenty zajišťující čtení údajů v propojeném datovém fondu, Informační systém základních registrů, Informační systém sdílené služby

• Editace dat PPDF – služby pro zápis, změnu a reklamaci údajů v propojeném datovém fondu

• Výpisy
• Asynchronně poskytovaná data

Tabulka 10: Dostupnost služeb

• Elektronická identifikace – Získání elektronické identifikace fyzické osoby (AIFO) na základě údajů v ROB a Národním bodu (BSI) – kritické služby.
• Výdej údajů – čtení údajů z PPDF – primární služby.
• Editace údajů – zápis/změna údajů v PPDF – sekundární služby.
• Ověření identity – autentizační služby – primární služby.

Prezentační služby:

• Portály – Portál občana, Portál veřejné správy.
• CzechPoint.
• ISDS.

Služby rozhraní:

• ISZR – rozhraní pro přístup k ZR.
• ISSS – rozhraní pro přístup k PPDF.
• NIA – Národní bod pro identifikaci a autentizaci.

Zdroje dat:

• Jednotlivé ZR (ROB, ROS, RUIAN, RPP, ORG).
• Identity provider – eveOP, ISDS.
• Publikující AIS – AIS publikující data v rámci ISSS.

Podpůrné služby:

• Komunikační infrastruktura KIVS.
• Centrální místo služeb – CMS.

Obrázek 13: Systémy PPDF

Tabulka 11: Vazby systémy a služby

Propojený datový fond jako každý datový zdroj musí mít definována přesná pravidla pro celý životní cyklus vedených údajů. Tento životní cyklus obsahuje kroky vložení, údržby a odstranění jednotlivého údaje či konkrétní entity (subjektu nebo objektu, o kterém jsou údaje vedeny). Bez nastavení a dodržování těchto pravidel není možno zajistit konzistenci a důvěryhodnost údajů poskytovaných tímto datovým zdrojem.

Dle definice je konzistence dat zajišťována na úrovni vnitřní (v rámci jednoho zdroje dat či databáze) a externí neboli vazbová (konzistence mezi jednotlivými zdroji dat). Z tohoto pohledu se Propojený datový fond musí z pohledu čtenáře údajů jevit jako zcela konzistentní systém se zajištěním kompletní platnosti dat i vazeb.

Základním nástrojem vazby pro subjekty je referenční odkaz na identifikátor fyzické osoby (AIFO) v Registru obyvatel nebo identifikátor právnické osoby (IČO) v Registru osob. V rámci eGovernmentu je prosazován princip, že veškeré údaje o subjektech práva jsou vedeny s referenční vazbou na tento odkaz a pokud tomu tak není (fyzická osoba nemá záznam v ROB, právnická osoba nemá záznam v ROS), pak údaje o těchto subjektech jsou pouze informativního charakteru a příjemce-čtenář těchto údajů nemá záruku jejich správnosti a zajištěného vztahu k osobě.

Prvotní úlohou zajištění konzistence PPDF je tedy zajištění stálé platnosti referenčních odkazů-vazeb ve všech informačních systémech veřejné správy a soukromoprávních uživatelů údajů dle zákona o základních registrech.

Následně musí být pro každý údaj o osobě znám jeho autoritativní původce, tedy v rámci jaké agendy a agendového informačního systému vzniká a je poskytován do propojeného datového fondu. Pouze z tohoto zdroje může být konkrétní údaj čerpán ostatními čtenáři a považován za správný. Stejný zdroj také musí poskytovat nástroje pro údržbu jím publikovaného údaje, tedy vyrozumívání o změnách údaje a příjem a zpracování reklamace údaje.

Z hlediska zajištění konzistence PPDF je možné definovat následující základní role AIS/OVM, uvedené dle přirozeného životního cyklu údaje:

• Editor údaje – je orgán veřejné moci, který vykonává určitou agendu a v rámci této agendy zajišťuje proces vzniku údaje na základě své úřední činnosti. Je to tedy například příslušný obecní úřad, který zakládá údaj o místě trvalého pobytu občana ČR. Následně tento údaj zapisuje do agendového informačního systému, který je buď dalším zapisovatelem nebo již zajišťuje jeho distribuci v rámci propojeného datového fondu (publikátor). V uvedeném případě je údaj zapisován do informačního systému evidence obyvatel.
• Publikátor údaje – zajišťuje publikaci údaje v referenční vazbě na subjekt práva do Propojeného datového fondu jako referenční (ze základních registrů) nebo jako údaj agendového informačního systému (autoritativní původce údaje). Ve výše uvedeném případě, je informační systém obyvatel editorem aktuálního údaje o adrese místa pobytu v Registru obyvatel nebo publikátorem historických údajů o adrese místa pobytu.
• Čtenář údaje – je orgán veřejné moci či soukromoprávní uživatel údajů, který při výkonu agendy využívá údaje z propojeného datového fondu poskytované publikátory ve vazbě na subjekt práva. Takto získané údaje může ukládat v datové bázi své agendy (svého informačního systému), pokud má k tomuto uložení zákonné oprávnění
• Auditor – typicky správce základního registru či jiného společného publikačního systému, který neověřuje platnost uložených údajů, ale zajišťuje jejich syntaktickou platnost (např. výskyt číslice v řetězci, kde mají být pouze písmena – záměna nuly 0 a velkého písmena O) a aktuálnost referenčních vazeb (subjekt s danou vazbou existuje v příslušném základním registru).

Z výše uvedeného rozdělení je zřejmé, že může existovat celý řetězec editorů, než je údaj publikován do Propojeného datového fondu.

V případě základních registrů jsou definovány speciální role primární editor a sekundární editor. Pouze primární editor může zakládat, měnit (slučovat či rozdělovat) či odstraňovat subjekt práva. Sekundární editor následně může pouze měnit odpovídající údaj pro existující subjekt práva.

Jak bylo řečeno výše, každý údaj PPDF vzniká činností příslušného orgánu veřejné moci a postupným řetězcem editorů je zapsán do Agendového informačního systému, který tyto údaje publikuje ve vazbě na subjekt či objekt práva.

Věcný správce publikačního AIS stanovuje pravidla pro své editory tak, aby zajistil, že jím publikované údaje mají zajištěnu:

• Správnost – údaj je správný do té míry, do jaké jsou schopni editoři tuto správnost zajistit.
• Referenční vazba – údaj je navázán na správnou osobu referenční vazbou v ROB či ROS.
• Formální správnost – údaj je zapsán a publikován formálně správně.

Věcný správce zajišťuje správné ohlášení agendy v RPP a jeho AISech. Označuje údaje, které jsou publikovány jako údaje AIS (tedy v agendě – AIS) vznikají a za jejichž správnost tedy ručí výkonem své agendy. Technický správce AIS musí zajistit plnění a vynucování těchto pravidel věcného správce včetně podkladů pro technickou specifikaci údajů v rámci AIS RPP, které mohou obsahovat i případné regulární kontroly na formální správnost zápisu údaje (např. V údaji se nesmí vyskytovat číslice a speciální znaky).

Publikátor musí zajistit, že jím publikované údaje jsou na propojený datový fond předávány v nezměněném tvaru (tak, jak byly zapsány editorem) a že jsou využívány a poskytovány v souladu s ohlášením příslušné agendy v RPP a jeho AISech.

Pozn: pro základní registry tuto funkcionalitu zajišťuje Informační systém základních registrů.

Věcný správce publikačního AIS nesmí do propojeného datového fondu publikovat jako údaj agendového informačního systému takový údaj, který nevzniká činností jeho agendy/agend a byl získán z propojeného datového fondu jako údaj od jiného publikátora. Takový údaj může být publikován pouze jako informativní a publikátor neručí žádným způsobem za jeho správnost.

Při činnosti agendy mohou být dle zákonných oprávnění využívány a ukládány údaje vznikající v jiných agendách. Zde je nutné upozornit, že využívání a ukládání údajů je z hlediska ochrany osobních údajů jiný proces. Je možné daný údaj v procesu výkonu agendy využít, ale nemusí být umožněno ho dále ukládat v agendovém informačním systému podporujícím výkon příslušné agendy.

Údaje z propojeného datového fondu se primárně získávají s vazbou na příslušný subjekt – AIFO či IČO. Čtenář je tedy zodpovědný za správnou identifikaci subjektu, jehož údaj z jiného agendového informačního systému chce využít – předání AIFO či IČO. Pokud čtenář není schopen identifikovat subjekt dle údajů, které jsou mu známy, může využít službu publikátora, kterému předá odpovídající údaje a na základě takto předaných údajů získá AIFO či IČO – čtení dle údajů. V tomto případě je opět čtenář zodpovědný za předání správných údajů, na základě kterých je osoba identifikována. Publikátor je zodpovědný za to, že identifikaci subjektu provede dle poskytnutých údajů.

Čtenář nesmí údaje, které získal z propojeného datového fondu zpětně publikovat jako údaje agendového informačního systému, tj. jako by vznikaly činností agendy, kterou AIS podporuje.

Při činnosti v rámci agendy může být zjištěn nesoulad údajů poskytnutých publikátorem a faktického stavu. V tom případě je čtenář povinen inicializovat reklamaci takového údaje.

V případě, že čtenář údaje z propojeného datového fondu či auditor zjistí nesoulad získaného údaje s faktickým stavem, pak je povinen realizovat reklamaci takového údaje. Reklamaci předává správci odpovídajícího publikačního AIS s tím, že musí uvést důvod reklamace a případně návrh správného tvaru údaje dle svých zjištění.

Reklamace je předávána věcnému správci publikačního AIS. Pokud správce publikačního AIS zpřístupňuje v propojeném datovém fondu službu pro příjem reklamací, pak je čtenář povinen tuto službu použít. V opačném případě postupuje dle správního řádu.

Správce publikačního AIS po příjmu reklamace předává příslušnému editorovi. Opět, pokud editor poskytuje službu pro příjem reklamací, je publikátor povinen tuto službu využít, v opačném případě postupuje dle správního řádu.

Editor údaje po příjmu reklamace údaje neprodleně rozhodne o tom, zda bude probíhat šetření správnosti údaje. V tomto případě neprodleně označí údaj u publikátora jako nesprávný a zahájí šetření, které vede buď k potvrzení stavu údaje či jeho opravě. Po ukončení tohoto šetření editor případně aktualizuje údaj a odstranění označení jako nesprávný.

Zde je nutné upozornit, že tyto procesy se jednak řídí správním řádem (z hlediska lhůt), jednak je v zájmu všech účastníků propojeného datového fondu, aby stav údajů byl aktuální a správný. Pouze v tomto případě mohou agendy pracovat s údaji v PPDF efektivně bez nutnosti jejich ověřování.

Audit údajů a referenčních vazeb provádí správce publikačního AIS. Musí zajistit procesy údržby údajů a referenčních vazeb

• Ověřování aktuálnosti referenčních vazeb – AIFO, IČO či kódy RUIAN odkazují na existující subjekt či objekt v základních registrech. V případě, že zjistí porušení referenčních vazeb označí tuto vazbu za nesprávnou publikátor a informuje editora s výzvou na zjednání nápravy.
  • Editor řeší opravu referenčních vazeb dle pravidel své agendy. Například pokud jde o adresu zapsanou odkazem na adresní bod a v agendě musí zůstat uložena poslední platná adresa, pak ji přepíše textem z posledního známého tvaru adresy. Jiným příkladem je fyzická osoba, jejíž údaje byly již z ROB odstraněny. V tom případě zachová AIFO osoby (záznamy v převodníku ORG jsou platné) a zaznamená, že osoba byla z ROB odstraněna.
• Ověřování formální správnosti údajů – publikátor pravidelně ověřuje, zda údaje zapsané editory jsou po formální stránce zapsány správně. Tuto formální stránku definuje publikátor v ohlášení agendy v RPP a AIS RPP v sekci Technická struktura údajů agendy. V případě, že zjistí porušení formální správnosti údaje, označí tento údaj za nesprávný a informuje editora s výzvou na zjednání nápravy.

Vyrozumívání o změně údajů je nástroj, kterým je zajištěna aktualizace údajů o subjektech a objektech v informačních systémech veřejné správy a soukromoprávních uživatelů. Správci jednotlivých informačních systémů jsou povinni udržovat aktuální údaje, které o subjektech a objektech získávají z propojeného datového fondu. Pro efektivní správu těchto aktualizací poskytují všichni publikátoři službu vyrozumívání o změnách údajů.

Každý publikátor by tedy pro údaje, jichž je autoritativním zdrojem, měl poskytovat službu vyrozumívání o změně údajů. Tato služba poskytuje čtenářům informace o změně údajů a umožňuje jim získání aktuálního údaje.

V případě, že publikátor tuto službu neposkytuje, musí čtenáři údajů pravidelně aktualizovat získané údaje čtením údajů pro celý kmen subjektů a objektů, které ve svém informačním systému vedou. V případě, že by takto bylo aktualizováno větší množství údajů, dojde k zásadnímu přetížení služeb publikátora.

Naopak, pokud publikátor poskytuje služby vyrozumívání o změnách údajů, je čtenář povinen tyto služby využívat pro údržbu získaných údajů.

Údaje o subjektech či objektech získané z propojeného datového fondu mohou být v agendovém informačním systému uloženy ve formě referenční vazby (odkaz na záznam v základních registrech) nebo v takzvaném dereferencovaném stavu (přímý zápis hodnoty údaje).

V základních registrech je preferovaným způsobem uložení referenční vazby (AIFO, IČO, Adresní bod). V jednotlivých AIS může být údaj uložen jako referenční vazba i jako přímá dereferencovaná hodnota údaje. Rozhodnutí o způsobu uložení údaje vychází z procesních pravidel agend, které jsou prostřednictvím AIS vykonávány. Z hlediska ochrany osobních údajů a jednoznačnosti údajů je doporučovaným způsobem současné uložení referenční vazby a částečně dereferencovaných údajů (údaje, které jsou například nutné pro vyhledávání v datech agendy).

Správce AIS, zvláště pak jednotlivých základních registrů, musí udržovat referenční vazby aktuální. Musí tedy mít nastaveny procesy reagující na změnu či zánik uložené referenční vazby. Pro zjištění těchto změn využívá procesy uvedené v předchozí kapitole. Správce:

• Poskytuje služby vyrozumívání o změnách údajů
• Odebírá vyrozumívání o změnách referenčních vazeb (například rozdělení či sloučení AIFO, zánik Adresního bodu)
• Provádí audit stavu referenčních vazeb
• Zajišťuje reklamaci údaje v případě jejich změny. Zvláště pak při porušení referenční vazby zánikem odkazovaného objektu či subjektu (zaniklý adresní bod, sloučené či rozdělené AIFO) označí vazbu za nesprávnou a inicializuje reklamaci u editora údaje

Správci základních registrů musí zajistit službu, která umožní buď získání následovníka referenční vazby (objekt či subjekt, který nahrazuje zrušený) nebo poslední známou hodnotu údajů, které se k referenční vazbě vztahují v okamžiku jejího zrušení. Čtenář pak může referenční vazbu nahradit přímým zápisem posledních známých údajů.

Bude vypracováno až po připomínkování ze strany všech správců ZR.

• Mechanismy vyrozumívání o změnách údajů na obyvatele v ROB.
• Dobu pro vedení čísla dokladu v ROB prodloužit na dobu, kdy je vedená v ROB samotná osoba – z důvodu možnosti zpětného ověření platnosti.
• Vedení evropských nařízení a směrnic v RPP jako podklad pro mezinárodní sdílení údajů.
• Mechanizmy vyrozumívání o změnách údajů právnických a fyzických osob v ROS.

Bude vypracováno až po připomínkování ze strany všech správců ZR.

• Příloha č. 1_UNICODE
• Příloha č. 2_SEMIC