Architektura eGovernmentu ČR - nap

Katalog služeb veřejné správy - [2. Vyplnění detailního popisu služby]

Šimon Trusina (simon.trusina@undisclosed.example.com) — 2026-10-12T11:10:57+00:00

2026/02/24 07:16		aktuální
Řádek 55:		Řádek 55:
	Pro každou službu je nutné vytvořit tzv. //detailní popis//. Jedná se o uživatelsky přívětivé texty, které je nutné vytvořit, aby byla splněna informační povinnost vyplývající ze zákona o právu na digitální služby, zákona o svobodném přístupu k informacím a dalších (podrobněji rozvedeno v metodice). Předpokladem pro vyplňování popisů je schválení evidence služeb v [[https://rpp-ais.egon.gov.cz/AISP/\|AIS RPP Působnostní]].		Pro každou službu je nutné vytvořit tzv. //detailní popis//. Jedná se o uživatelsky přívětivé texty, které je nutné vytvořit, aby byla splněna informační povinnost vyplývající ze zákona o právu na digitální služby, zákona o svobodném přístupu k informacím a dalších (podrobněji rozvedeno v metodice). Předpokladem pro vyplňování popisů je schválení evidence služeb v [[https://rpp-ais.egon.gov.cz/AISP/\|AIS RPP Působnostní]].

-	Detailní popisy obsahují především informace o tom, komu je služba určena a jakým způsobem je možné jí vyřídit.	+	Detailní popisy obsahují především informace o tom, komu je služba určena a jakým způsobem je možné jí vyřídit. Popisy jsou zveřejňovány na [[https://portal.gov.cz\|Portálu veřejné správy]].

	Postup vypracování detailních popisů:		Postup vypracování detailních popisů:

-	- Prostudování {{ :znalostni_baze:ks:metodika-detailniho-popisu.pdf\|metodiky}}\|. Informační seminář můžete zhlédnout na [[https://www.youtube.com/watch?v=vs8oWsjh-bc\|této stránce]].	+	- Prostudování {{ :znalostni_baze:ks:metodika_dps_10_2026.pdf \|metodiky}}. Záznam ze semináře k novinkám v poslední verzi metodiky na [[https://digitalniagentura-my.sharepoint.com/:v:/g/personal/martin_vimmr_dia_gov_cz/IQBKC7BCR5ccSJAQVim3RETvAZkTeQruwBHZ6n0f_FBoOns?e=6h1TPC&referrer=Outlook.Win32&referrerScenario=email-linkwithoutembed\|tomto odkaze]].
-	- Zařízení přístupu do redakčního systému [[https://rpp-ais.egon.gov.cz/AISK/\|AIS RPP Správa katalogů (AISK)]]. Potřebná oprávnění a návod k používání systému naleznete v {{ :znalostni_baze:ks:uzivatelska-prirucka-k-ais-sprava-katalogu-v2.1.doc\|uživatelské příručce k AISK}}.	+	- Zařízení přístupu do redakčního systému [[https://rpp-ais.egon.gov.cz/AISK/\|AIS RPP Správa katalogů (AISK)]]. Potřebná oprávnění a návod k používání systému naleznete v metodice a {{ :znalostni_baze:ks:uzivatelska-prirucka-k-ais-sprava-katalogu-v2.1.doc\|uživatelské příručce k AISK}}.
	- Na začátek doporučujeme vyplnit a odeslat ke schválení 2-3 popisy. Po jejich schválení ze strany DIA pak bude jasnější, jakým způsobem vyplňovat i ty ostatní.		- Na začátek doporučujeme vyplnit a odeslat ke schválení 2-3 popisy. Po jejich schválení ze strany DIA pak bude jasnější, jakým způsobem vyplňovat i ty ostatní.

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

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

-	V oprávněných případech je možné převést detailní popis na jiné OVM. Takové situace nastávají především pokud danou agendu nebo její část vykonává jiný úřad podřízený ministerstvu.	+	V oprávněných případech je možné převést detailní popis na jiné OVM. Takové situace nastávají především pokud danou agendu nebo její část vykonává jiný úřad podřízený ministerstvu. V takovém případě je potřeba, aby obě OVM kontaktovaly DIA s žádostí o převod.

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

Ověření aktuálnosti výpisů/výstupů ISVS - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:34:28+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== Ověření aktuálnosti výpisů/výstupů ISVS ======
	+
	+	Stav: koncept v přípravě, pilotně ho implementuje Ministerstvo spravedlnosti. Technický profil a adresy uvedené na této stránce jsou pracovním návrhem Digitální a informační agentury (DIA) a mohou se změnit. Závazně je stanoví technický profil a revize otevřené formální normy pro strojově čitelnou vrstvu dokumentů.
	+
	+	===== Shrnutí =====
	+
	+	Výpis nebo výstup z informačního systému veřejné správy (ISVS), typicky výpis z evidence Rejstříku trestů, vypovídá o stavu údajů jen k jedinému okamžiku – k okamžiku platnosti údajů. Pozdější změna údajů se do již vydaného výpisu nepromítne a příjemce nemá jak zjistit, zda údaje ve výpisu stále odpovídají evidenci. Praxe tento problém obchází požadavky typu „výpis ne starší než …“, které ho ale neřeší a vedou k opakovanému vyžadování nových výpisů.
	+
	+	DIA proto navrhuje doplnit k vydaným výpisům ověřitelnou informaci o jejich aktuálnosti pomocí tzv. status listů. Vydavatel výpisu vede veřejně publikovaný a elektronicky zapečetěný seznam, ve kterém má každý vydaný výpis svou pozici s jediným příznakem. Výpis ve své strojově čitelné vrstvě nese odkaz na status list a číslo své pozice. Příjemce si seznam stáhne a aktuálnost ověří sám – bez kontaktování vydavatele a bez toho, aby se vydavatel dozvěděl, který výpis je ověřován.
	+
	+	Mechanismus je technicky totožný se status listy, které DIA buduje pro atestace vydávané do evropské digitální peněženky (EUDI Wallet) v Informačním systému k podpoře peněženky (IS PP). Liší se pouze význam sledovaného příznaku: u výpisů jde o aktuálnost údajů, u atestací o jejich zneplatnění (revokaci). Obě řešení tak od počátku vznikají jako jeden slučitelný systém.
	+
	+	Pilotně mechanismus zavádí Ministerstvo spravedlnosti pro výpisy z evidence Rejstříku trestů.
	+
	+	Přínosy:
	+	* vyšší právní jistota příjemce veřejné listiny – aktuálnost ověří kdykoli, i opakovaně, bez kontaktování vydavatele,
	+	* méně opakovaného vyžadování a předkládání výpisů „pro jistotu“ (zásada „pouze jednou“),
	+	* jednotný mechanismus pro výpisy i pro atestace v EUDI Wallet bez duplicitní infrastruktury,
	+	* ochrana soukromí – vydavatel se z ověřování nedozví, komu držitel výpis předložil.
	+
	+	===== Co status list vypovídá a co ne =====
	+
	+	^ Otázka příjemce ^ Odpovídá na ni status list? ^ Čím se ověřuje ^
	+	\| Změnily se od vydání výpisu údaje, ze kterých byl vytvořen? \| ano – to je jediný předmět výpovědi \| status list \|
	+	\| Je výpis pravý a nebyl pozměněn? \| ne \| elektronická pečeť výpisu \|
	+	\| Je platná elektronická pečeť nebo podpis výpisu? \| ne \| validace pečeti nebo podpisu \|
	+	\| Je výpis právně platnou veřejnou listinou? \| ne \| právní platnost listiny se označením za neaktuální nemění \|
	+
	+	Výsledek „aktuální“ je formulován záměrně opatrně. Neznamená potvrzení správnosti všech údajů, ale pouze to, že vydavatel výpis k okamžiku vydání status listu neoznačil jako neaktuální. Mezi změnou v evidenci a jejím promítnutím do status listu může uplynout až jeden obnovovací cyklus (24 hodin) a ověřovatel může používat kopii listu z mezipaměti.
	+
	+	===== Výchozí stav a právní rámec =====
	+
	+	* [[https://www.e-sbirka.cz/sb/2000/365\|Zákon č. 365/2000 Sb.]] v § 9 rozlišuje výpis z ISVS (odst. 1), výstup z ISVS, tedy výpis nebo potvrzení v elektronické podobě zabezpečené způsobem zajišťujícím integritu, případně původ dat (odst. 2), a ověřený výstup, tedy listinu, která vznikla převodem výstupu z ISVS do listinné podoby na kontaktním místě veřejné správy (odst. 3). Všechny jsou veřejnými listinami (odst. 5).
	+	* Podle § 9c téhož zákona odpovídá správce ISVS za soulad výstupu se stavem zápisu k okamžiku platnosti údajů. Status list tento údaj nenahrazuje, ale doplňuje o informaci, zda se stav zápisu od tohoto okamžiku změnil.
	+	* [[https://www.e-sbirka.cz/sb/2004/499\|Zákon č. 499/2004 Sb.]] v § 69a odst. 5 až 7 ukládá veřejnoprávním původcům opatřit vyhotovovaný dokument v digitální podobě strojově čitelnou vrstvou podle schématu, které zveřejňuje DIA. Strojově čitelná vrstva je nosičem odkazu na status list; odkaz se do ní zapisuje podle rozšíření otevřené formální normy [[https://ofn.gov.cz/spole%C4%8Dn%C3%A9-%C4%8D%C3%A1sti-elektronick%C3%BDch-dokument%C5%AF/2024-10-04/\|Společné části elektronických dokumentů]].
	+	* [[https://www.e-sbirka.cz/sb/2012/259\|Vyhláška č. 259/2012 Sb.]], o podrobnostech výkonu spisové služby.
	+	* Nařízení (EU) č. 910/2014 (eIDAS) ve znění nařízení (EU) 2024/1183 a Architektonický a referenční rámec EUDI Wallet (ARF) – pro atestace v peněžence.
	+
	+	Žádný předpis dnes vydavatelům neukládá povinnost informovat o trvání aktuálnosti vydaných výpisů. Zapojení je proto zatím dobrovolné (pilotní provoz). Plošná povinnost vyžaduje změnu právních předpisů – viz [[#postup_zavadeni\|Postup zavádění]].
	+
	+	===== Jak mechanismus funguje =====
	+
	+	==== Role ====
	+
	+	^ Role ^ Kdo ^ Odpovědnost ^
	+	\| Vydavatel výpisu \| správce ISVS (původce výpisu) \| přiděluje výpisu pozici ve status listu, eviduje vydané výpisy, rozhoduje o označení výpisu jako neaktuálního, vydává a pečetí status list \|
	+	\| Poskytovatel publikace \| cílově DIA (centrální publikační bod), přechodně vydavatel na delegovaném segmentu \| zveřejňuje status listy na trvalých adresách, provozuje agregační index \|
	+	\| Držitel \| subjekt údajů \| získá výpis obvyklou cestou a předá ho příjemci digitálně, případně v listinné podobě \|
	+	\| Příjemce (ověřovatel) \| úřad, zaměstnavatel, jiný soukromý subjekt \| ověří pečeť výpisu a jeho aktuálnost; hromadní příjemci ověřují opakovaně a strojově \|
	+
	+	Označit výpis jako neaktuální smí pouze jeho vydavatel. Generování a publikaci status listů lze svěřit jinému subjektu, odpovědnost za obsah status listu však zůstává vydavateli.
	+
	+	==== Životní cyklus výpisu ====
	+
	+	- Vydání. Vydavatel přidělí výpisu náhodně zvolenou volnou pozici (index, ''idx'') v aktuálním status listu a do strojově čitelné vrstvy výpisu zapíše adresu status listu (''uri''), index a datum konce doby ověřitelnosti. Tyto údaje musí být v rozsahu elektronické pečeti výpisu, jinak by bylo možné odkaz podvrhnout a přesměrovat ověření na jinou pozici.
	+	- Evidence. Vydavatel eviduje vazbu mezi vydaným výpisem a dvojicí ''uri'' + ''idx'' po celou dobu ověřitelnosti výpisu, aby při změně údajů dokázal určit dotčené výpisy.
	+	- Změna údajů. Při agendové události, která mění údaje obsažené ve výpisu (zápis, oprava, zrušení nebo nahrazení záznamu), vydavatel označí dotčené výpisy jako neaktuální. Označení je nevratné.
	+	- Obnova listu. Status list se obnovuje automaticky nejméně jednou za 24 hodin a publikuje se vždy na téže adrese. V mimořádných situacích (např. při bezpečnostním incidentu) lze list vydat i mimo pravidelný cyklus.
	+	- Ověření. Příjemce ověří pečeť výpisu, stáhne status list (nebo použije dostatečně čerstvou kopii z mezipaměti) a přečte hodnotu na pozici výpisu.
	+	- Konec ověřitelnosti. Každý výpis má dobu ověřitelnosti, jejíž konec je uveden přímo ve strojově čitelné vrstvě výpisu. Délka se odvozuje od skartační lhůty příslušného druhu výpisu. Po jejím uplynutí se aktuálnost výpisu již neověřuje; příznak ve status listu se kvůli uplynutí lhůty nemění, takže výsledek NEAKTUÁLNÍ vždy znamená skutečnou změnu údajů. Status list se přestane vydávat, jakmile skončí doba ověřitelnosti všech výpisů, které na něj odkazují.
	+
	+	==== Výsledek ověření ====
	+
	+	Ověření má vždy jeden ze tří výsledků:
	+
	+	^ Výsledek ^ Kdy nastane ^ Význam pro příjemce ^
	+	\| AKTUÁLNÍ \| hodnota na pozici výpisu je 0 a všechny kontroly proběhly úspěšně \| vydavatel výpis k okamžiku vydání status listu neoznačil jako neaktuální \|
	+	\| NEAKTUÁLNÍ \| hodnota na pozici výpisu je 1 \| údaje ve výpisu již neodpovídají evidenci; příjemce si aktuální údaje opatří od držitele (nový výpis), případně na základě jeho plné moci \|
	+	\| NELZE OVĚŘIT \| uplynula doba ověřitelnosti výpisu, status list není dostupný, jeho pečeť je neplatná, list je prošlý, index je mimo rozsah listu nebo selhala jiná kontrola \| o aktuálnosti nelze učinit žádný závěr; o přijetí výpisu rozhoduje příjemce podle vlastního posouzení rizik \|
	+
	+	Výsledek NELZE OVĚŘIT nesmí být nikdy vykládán jako AKTUÁLNÍ.
	+
	+	==== Způsoby ověření ====
	+
	+	* Strojové ověření – informační systém příjemce načte ze strojově čitelné vrstvy ''uri'' a ''idx'' a ověří status list podle algoritmu uvedeného níže. Příjemci, kteří pracují s velkým množstvím výpisů (např. organizace s tisíci členy), si mohou odkazy uložit do vlastní evidence, status listy pravidelně stahovat přes agregační index a ověřovat aktuálnost všech výpisů opakovaně bez lidského zásahu. Strojové ověření je hlavním a autoritativním způsobem ověření.
	+	* Ověření člověkem přes QR kód – doplňková služba. QR kód na vizuální vrstvě výpisu povede na centrální ověřovací stránku, která status list stáhne, ověří a zobrazí výsledek. QR kód se na výpisy začne umisťovat až po zprovoznění centrální ověřovací služby; jeho podoba se však stanoví předem, aby ho šlo doplnit bez změny schématu.
	+	* Listinná podoba – výpis v listinné podobě ani ověřený výstup nemají strojově čitelnou vrstvu; jejich aktuálnost bude možné ověřit pouze přes QR kód, a to jako doplňkovou informaci. Pravost listiny se nadále ověřuje dosavadními způsoby.
	+
	+	==== Bezpečnostní zásady pro QR kód ====
	+
	+	QR kód je doplňkem, který nesmí z hlediska bezpečnosti zhoršit současný stav. Platí proto tyto zásady:
	+
	+	* Strojové ověření na QR kódu nikdy nezávisí. Nedostupnost QR kódu ani ověřovací stránky nemá vliv na platnost ani použitelnost výpisu.
	+	* Ověření přes QR kód vypovídá pouze o aktuálnosti výpisu, na který kód odkazuje, a nepotvrzuje pravost listiny, na které je natištěn. QR kód lze zkopírovat z jiného, pravého výpisu na padělek. Ověřovací stránka to proto musí u každého výsledku výslovně uvádět a odkazovat na postup ověření pravosti (elektronická pečeť výpisu, ověřovací doložka ověřeného výstupu, doložka autorizované konverze).
	+	* Ověřovací stránka běží pouze na jedné pevně stanovené doméně ''gov.cz'', která se zveřejní a uvádí i na výpisu. Nikdy nežádá přihlášení, osobní údaje ani platbu, aby nebylo možné zaměnit ji s podvodnou stránkou, na kterou by vedl podvržený QR kód.
	+	* QR kód neobsahuje osobní údaje, pouze adresu status listu a index. Výsledek se vyhodnocuje v prohlížeči, takže se ověřovací služba nedozví, který výpis je ověřován.
	+	* Ověřovací stránka zobrazí výsledek AKTUÁLNÍ jen po úspěšném ověření pečeti status listu; jinak zobrazí NELZE OVĚŘIT.
	+
	+	===== Technický profil (návrh) =====
	+
	+	Profil přebírá beze změny formát, který pro atestace v EUDI Wallet používá IS PP. Díky tomu lze sdílet komponenty a použít existující knihovny a validátory. Vlastní formáty listu (XML ani JSON) se nepoužijí.
	+
	+	^ Parametr ^ Hodnota ^ Poznámka ^
	+	\| Formát listu \| Status List Token podle [[https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/\|IETF Token Status List]] v podobě JWT, typ ''statuslist+jwt'' \| totožné s IS PP; na tentýž mechanismus odkazuje ETSI TS 119 472-1 pro elektronická potvrzení atributů (EAA) \|
	+	\| Bitů na výpis \| ''bits'' = 1 \| 0 = výpis neoznačen jako neaktuální, 1 = výpis označen jako neaktuální; hodnota 1 odpovídá registrovanému stavu INVALID (0x01), jehož význam pro výpisy upřesňuje profil \|
	+	\| Směr změny \| pouze 0 → 1 \| vratný stav (např. dočasné pozastavení) by vyžadoval 2 bity a musí být rozhodnut před vydáním prvních výpisů \|
	+	\| Pořadí bitů \| podle TSL: index 0 je nejnižší bit prvního bajtu \| nepoužívá se vlastní konvence „nejvyšší bit první“ \|
	+	\| Komprese a kódování \| DEFLATE ve formátu ZLIB, base64url bez doplňování \| nikoli gzip \|
	+	\| Zabezpečení \| JWS s certifikátem pro kvalifikovanou elektronickou pečeť vydavatele, řetězec certifikátů v hlavičce ''x5c'' \| k časovému razítku viz níže \|
	+	\| Obnova a mezipaměť \| nejméně 1× za 24 h; ''ttl'' = 86 400 s; ''exp'' = ''iat'' + 48 h \| překryv zajistí, že výpadek jedné obnovy nezneplatní kopie v mezipaměti ověřovatelů \|
	+	\| Velikost listu \| nejméně 10 000 pozic (shodně s IS PP) \| výpisy agend s malým počtem vydání se sdružují do společných listů \|
	+	\| Přidělení pozice \| náhodně z volných pozic; nevyužité pozice mají hodnotu 0 \| z pozice nelze odvodit pořadí ani čas vydání; nevyužité pozice zakrývají počet vydaných výpisů \|
	+	\| Účel listu \| údaj ''purpose'' s hodnotou ''dataCurrency'' v tokenu a zároveň kolekce v adrese listu \| ověřovací software si účel listu kontroluje; listy pro aktuálnost výpisů a listy pro revokaci atestací se nikdy nemíchají v jednom tokenu; název údaje sjednotí technický profil s ETSI TS 119 472-1 \|
	+	\| Odkaz ve výpisu \| ''uri'' + ''idx'' + konec doby ověřitelnosti ve strojově čitelné vrstvě, v nové nepovinné sekci //ověření aktuálnosti// OFN Společné části elektronických dokumentů \| zrcadlení do metadat XMP v PDF je přípustné jen jako doplněk; jmenný prostor přidělí DIA \|
	+	\| Doba ověřitelnosti \| datum konce ověřitelnosti uvedené ve výpisu; délka odvozená od skartační lhůty \| po uplynutí je výsledek NELZE OVĚŘIT; příznak ve status listu se nemění \|
	+
	+	Stav standardizace: specifikace IETF Token Status List byla schválena IESG jako navrhovaný standard (Proposed Standard) a čeká ve frontě RFC Editoru na vydání jako RFC. Poslední verzí je draft-ietf-oauth-status-list-21 z 21. 6. 2026 (stav k 6. 10. 2026). Po vydání RFC se odkazy na této stránce aktualizují.
	+
	+	==== Příklad odkazu ve strojově čitelné vrstvě ====
	+
	+	Ilustrativní podoba nové sekce; názvy elementů, jmenný prostor a ekvivalent v JSON Schema stanoví revize OFN.
	+
	+	<code xml>
	+	<ověření_aktuálnosti xmlns="http://dia.gov.cz/ns/spolecne-casti-elektronickych-dokumentu/overeni-aktualnosti">
	+	<uri_status_listu>https://status.gov.cz/isvs/{id-ISVS}/listiny/2026-07</uri_status_listu>
	+	<index_ve_status_listu>136547</index_ve_status_listu>
	+	<ověřitelné_do>2031-07-22</ověřitelné_do>
	+	</ověření_aktuálnosti>
	+	</code>
	+
	+	==== Příklad status list tokenu ====
	+
	+	Hlavička:
	+	<code json>
	+	{
	+	"alg": "ES256",
	+	"typ": "statuslist+jwt",
	+	"x5c": ["<certifikát pečeti vydavatele>", "<certifikát vydávající CA>"]
	+	}
	+	</code>
	+
	+	Obsah (payload):
	+	<code json>
	+	{
	+	"sub": "https://status.gov.cz/isvs/{id-ISVS}/listiny/2026-07",
	+	"iat": 1784700000,
	+	"ttl": 86400,
	+	"exp": 1784872800,
	+	"purpose": "dataCurrency",
	+	"status_list": {
	+	"bits": 1,
	+	"lst": "<bitové pole komprimované ZLIB a kódované base64url>"
	+	}
	+	}
	+	</code>
	+
	+	Hodnota ''sub'' musí být shodná s ''uri'' uvedenou ve výpisu. V příkladu ''iat'' odpovídá 22. 7. 2026 6:00 UTC a ''exp'' je o 48 hodin později. Algoritmus (''alg'') odpovídá klíči pečeti vydavatele. Adresa je pouze ilustrativní.
	+
	+	==== Příklad bitového pole ====
	+
	+	Status list pro 32 výpisů, ve kterém jsou jako neaktuální označeny výpisy s indexy 5, 17 a 29:
	+
	+	^ Bajt ^ 0 ^ 1 ^ 2 ^ 3 ^
	+	\| Indexy (bit 7 … bit 0) \| 7 … 0 \| 15 … 8 \| 23 … 16 \| 31 … 24 \|
	+	\| Bity \| ''00100000'' \| ''00000000'' \| ''00000010'' \| ''00100000'' \|
	+	\| Hodnota \| ''0x20'' \| ''0x00'' \| ''0x02'' \| ''0x20'' \|
	+
	+	Po kompresi a zakódování: ''"lst": "eNpTYGBSAAAAqABD"''
	+
	+	Pro index 136547 platí: bajt = 136547 div 8 = 17068, bit = 136547 mod 8 = 3, maska ''0x08''.
	+
	+	==== Algoritmus ověření ====
	+
	+	- Ověřit elektronickou pečeť výpisu a to, že údaje sekce ověření aktuálnosti jsou v jejím rozsahu.
	+	- Zkontrolovat, zda neuplynula doba ověřitelnosti výpisu; pokud ano, výsledek je NELZE OVĚŘIT.
	+	- Získat status list token z adresy ''uri'' (HTTP GET s hlavičkou ''Accept: application/statuslist+jwt''), případně použít kopii z mezipaměti, která není starší než ''ttl''.
	+	- Ověřit pečeť tokenu a to, že ho vydal oprávněný vydavatel.
	+	- Ověřit, že ''sub'' se rovná ''uri'', že token není prošlý (''exp'') a že účel listu je ''dataCurrency''.
	+	- Dekomprimovat ''lst'' (ZLIB) a přečíst hodnotu: ''bajt = idx div 8'', ''bit = idx mod 8'', ''hodnota = (lst[bajt] >> bit) & 1''.
	+	- Hodnota 0 znamená AKTUÁLNÍ, hodnota 1 NEAKTUÁLNÍ. Index mimo rozsah listu nebo selhání kteréhokoli kroku znamená NELZE OVĚŘIT.
	+
	+	Implementaci se doporučuje ověřit proti testovacím vektorům ve specifikaci IETF Token Status List.
	+
	+	==== Časové razítko a dlouhodobá prokazatelnost ====
	+
	+	Status list token ve formátu JWT používá kompaktní serializaci JWS, do které nelze vložit kvalifikované elektronické časové razítko na úrovni JAdES B-T. Token se proto pečetí na úrovni odpovídající JAdES B-B a kvalifikované elektronické časové razítko vydavatel pořizuje ke každé vydané verzi tokenu odděleně.
	+
	+	Pro běžné ověřování aktuálnosti časové razítko ani dlouhodobé uchování nejsou potřeba. Každá nová verze listu je zapečetěna aktuálně platným certifikátem, takže obměna certifikátů pečeti ověřování neomezuje. Pro případnou potřebu prokázat stav k určitému okamžiku v minulosti vydavatel archivuje každou vydanou verzi tokenu spolu s časovým razítkem, a to nejméně do konce doby ověřitelnosti všech výpisů v listu. Veřejné dotazy na historický stav služba nenabízí.
	+
	+	===== Publikace a jmenný prostor =====
	+
	+	Klíčovým principem je oddělení jmenného prostoru od infrastruktury. Adresy zapsané do vydaných výpisů musí zůstat platné po celou dobu jejich ověřitelnosti. DIA proto doporučuje, aby i pilotní a resortní řešení od prvního vydaného výpisu používala adresy v jednotném, centrálně spravovaném jmenném prostoru, i když za nimi zpočátku stojí infrastruktura vydavatele.
	+
	+	* Pracovní návrh tvaru adresy: ''%%https://status.gov.cz/isvs/{id-ISVS-dle-RPP}/{kolekce}/{období}%%''
	+	* Do zprovoznění centrální služby se segment příslušného ISVS technicky deleguje na infrastrukturu vydavatele (reverzní proxy nebo delegace na úrovni cesty). Vydavatel generování, pečetění i publikaci zajišťuje ve vlastní režii.
	+	* Po zprovoznění centrální služby se směrování přepne na ni. Migruje se backend, nikoli odkazy – již vydané výpisy se nemění.
	+	* Centrální publikační služba bude kromě výdeje status list tokenů se správným nastavením mezipaměti nabízet agregační index všech aktivních listů (ve formátu Status List Aggregation podle TSL), odběr změn pro hromadné ověřovatele a ověřovací stránku pro QR kód.
	+	* Status listy jsou přístupné veřejně a bez přihlášení; přihlašování by vydavateli umožnilo zjistit, kdo ověřuje.
	+	* Pracovní návrh obsahu QR kódu: ''%%https://overeni.gov.cz/l#u={uri}&i={idx}%%'', tedy tytéž dva údaje, které výpis nese ve strojově čitelné vrstvě. Údaje jsou v části adresy za znakem „#“, kterou prohlížeč neodesílá na server, a výsledek se vyhodnocuje v prohlížeči.
	+
	+	Konkrétní doménové názvy a tvar adres slouží k ilustraci principu; závazně je stanoví technický profil. Závazný je princip jednotného, trvalého, centrálně spravovaného jmenného prostoru nezávislého na infrastruktuře konkrétního resortu.
	+
	+	===== Vazba na EUDI Wallet a IS PP =====
	+
	+	IS PP vydává atestace (např. výpisu z Rejstříku trestů) do EUDI Wallet jako elektronická potvrzení atributů poskytovaná subjektem veřejného sektoru odpovědným za autentický zdroj (PuB-EAA), ve formátu mdoc podle ISO/IEC 18013-5. U atestací s platností delší než 24 hodin je zveřejňování stavu podle pravidel EUDI Wallet povinné a IS PP k tomu používá status listy. Výpisy z ISVS využívají tentýž mechanismus ve druhé instanci:
	+
	+	^ Vrstva ^ Výpisy z ISVS ^ Atestace v EUDI Wallet (IS PP) ^
	+	\| Formát listu \| Token Status List (JWT), ''bits'' = 1 \| Token Status List podle ARF \|
	+	\| Význam příznaku \| aktuálnost údajů \| zneplatnění (revokace) \|
	+	\| Nevratnost \| ano \| ano \|
	+	\| Obnova \| nejméně 1× za 24 h \| nejméně 1× za 24 h \|
	+	\| Jmenný prostor \| status.gov.cz (segment ISVS) \| status.gov.cz (kolekce IS PP) \|
	+	\| Zdroj změny \| agendový úkon, změna v evidenci \| notifikace změn z AISV ISZR \|
	+	\| Ochrana soukromí \| nejméně 10 000 pozic, náhodný index \| nejméně 10 000 pozic, náhodný index \|
	+
	+	* Jeden spouštěč, dva výstupy. Tam, kde tentýž autentický zdroj sytí výpis i atestaci (typicky Rejstřík trestů), musí jedna změna údajů vyvolat současně označení výpisu jako neaktuálního i revokaci atestace. Nikdy nesmí nastat stav, kdy je atestace revokována, ale „stejný“ výpis se jeví jako aktuální.
	+	* Sdílená implementace. Generátor listů, správa indexů, pečetění a publikační řetězec vyvinuté pro IS PP jsou pro výpisy znovupoužitelné; liší se jen kolekce a profil.
	+	* Oddělení účelu. Listy pro aktuálnost a listy pro revokaci se nemíchají; ověřovatel vždy ví, na jakou otázku dostává odpověď.
	+
	+	===== Ochrana soukromí =====
	+
	+	* Anonymita v davu (herd privacy). Jeden status list pokrývá nejméně 10 000 pozic, takže ze stažení listu nelze poznat, o který výpis jde.
	+	* Náhodné přidělování pozic. Pozice přidělovaná popořadě by sama byla identifikátorem a prozrazovala by čas vydání.
	+	* Stahování do zásoby. Ověřovatelé si listy stahují předem a ukládají do mezipaměti, nikoli až v okamžiku předložení výpisu. Usnadňuje to agregační index.
	+	* Malé agendy. U agend s malým počtem vydaných výpisů by samostatný list nebo četnost jeho změn mohly prozradit více, než je žádoucí. Jejich výpisy se proto sdružují do společných listů.
	+	* Omezení dlouhodobého sledování. Příjemce, který si uloží odkaz na status list, by bez omezení mohl aktuálnost údajů držitele sledovat neomezeně dlouho. Doba ověřitelnosti výpisu toto sledování časově omezuje.
	+	* Bez historických dotazů. Služba neumožňuje zjišťovat stav k libovolnému okamžiku v minulosti.
	+	* Ověřování přes QR kód probíhá v prohlížeči; ověřovací služba se nedozví, který výpis je ověřován.
	+	* Evidence vydaných výpisů u vydavatele a vazba výpisu na pozici v listu jsou zpracováním osobních údajů; jejich rozsah a právní titul budou posouzeny v rámci legislativní analýzy.
	+
	+	===== Postup zavádění =====
	+
	+	Zavádění je rozděleno do fází tak, aby pilotní provoz nebyl závislý na výstavbě centrální infrastruktury. Ministerstvo spravedlnosti mechanismus pilotně implementuje; zavedení povinnosti pro další správce ISVS je podmíněno změnou právních předpisů. Uvedená období jsou orientační.
	+
	+	^ Fáze ^ Období ^ Obsah ^
	+	\| 0 – Dohoda základů \| 2026 \| stanovení tvaru adres a jmenného prostoru, technický profil status listu, delegace segmentu pro pilotní provoz, přidělení jmenného prostoru pro odkaz ve výpisu; lze vydat rozhodnutím OHA bez změny právních předpisů \|
	+	\| 1 – Standardizace \| 2026 – 2027 \| návrh rozšíření OFN Společné části elektronických dokumentů o nepovinnou sekci ověření aktuálnosti, registrace pojmů ve slovník.gov.cz, JSON Schema, veřejná konzultace \|
	+	\| 2 – Metodiky a pilot \| 2026 – 2027 \| vydání revize OFN; metodický pokyn pro vydavatele (kdy a jakým úkonem výpis označit jako neaktuální, evidence odkazů ve spisové službě, mimořádná obnova listu, délka doby ověřitelnosti); metodika pro ověřovatele; pilotní provoz Ministerstva spravedlnosti (evidence Rejstříku trestů) \|
	+	\| 3 – Centrální služba \| 2027 – 2028 \| výstavba centrální publikační a ověřovací služby (publikace, agregační index, monitoring, ověřovací stránka, QR kód); převedení delegovaných segmentů beze změny adres \|
	+	\| 4 – Závaznost \| po přijetí právní úpravy \| legislativní zakotvení povinnosti – novela vyhlášky č. 259/2012 Sb. a doplnění zákona č. 365/2000 Sb.; zapojení dalších správců ISVS \|
	+
	+	Kritickou cestou je dohoda základů a pilotní provoz. Standardizace a metodiky běží souběžně s pilotem a promítají do něj zkušenosti. Centrální služba není pro pilot podmínkou díky delegaci segmentu jmenného prostoru.
	+
	+	===== Otevřené otázky =====
	+
	+	* Délka doby ověřitelnosti pro jednotlivé druhy výpisů a její vazba na skartační lhůty.
	+	* Vratnost stavu – potvrzení pilotními resorty, že postačuje jednosměrný přechod 0 → 1.
	+	* Hromadné ověřování – popis scénářů pro příjemce, kteří ověřují velké množství výpisů (odběr přes agregační index, notifikace).
	+	* Právní rámec – posouzení zmocnění, ochrany osobních údajů a rozsahu potřebných změn právních předpisů.
	+
	+	===== Související předpisy, normy a odkazy =====
	+
	+	* [[https://www.e-sbirka.cz/sb/2000/365\|Zákon č. 365/2000 Sb., o informačních systémech veřejné správy]] – § 9 až 9d
	+	* [[https://www.e-sbirka.cz/sb/2004/499\|Zákon č. 499/2004 Sb., o archivnictví a spisové službě]] – § 69a
	+	* [[https://www.e-sbirka.cz/sb/2012/259\|Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby]]
	+	* [[https://ofn.gov.cz/spole%C4%8Dn%C3%A9-%C4%8D%C3%A1sti-elektronick%C3%BDch-dokument%C5%AF/2024-10-04/\|OFN Společné části elektronických dokumentů]]
	+	* [[https://www.dia.gov.cz/egovernment/schemata-pro-strojove-citelnou-vrstvu-dle-zakona-499-2004-sb/\|Schémata pro strojově čitelnou vrstvu dle zákona č. 499/2004 Sb.]] (DIA)
	+	* [[https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/\|IETF Token Status List]]
	+	* [[https://www.etsi.org/deliver/etsi_ts/119400_119499/11947201/\|ETSI TS 119 472-1 – Profiles for Electronic Attestation of Attributes]]
	+	* [[https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/\|EUDI Wallet – Architecture and Reference Framework (ARF)]]
	+	* [[https://data.gov.cz/ofn/\|Otevřené formální normy]]
	+	* [[nap:czechpoint\|Czech POINT]], [[nap:system_spravy_dokumentu\|Systém správy dokumentů]], [[nap:iszr\|Informační systém základních registrů]]
	+
	+	===== Pojmy =====
	+
	+	^ Pojem ^ Význam ^
	+	\| Status list \| veřejně publikovaný seznam stavů mnoha výpisů v podobě komprimovaného bitového pole \|
	+	\| Status list token \| elektronicky zapečetěný token (JWT), který status list obsahuje \|
	+	\| Index (''idx'') \| pozice výpisu ve status listu \|
	+	\| Aktuálnost údajů \| skutečnost, že údaje, ze kterých byl výpis vytvořen, nebyly od okamžiku platnosti údajů změněny; nezaměňovat s právní platností listiny ani s platností pečeti \|
	+	\| Doba ověřitelnosti \| doba, po kterou lze aktuálnost výpisu ověřovat; její konec je uveden ve výpisu (v dřívějších podkladech též „administrativní platnost“) \|
	+	\| Agregační index \| seznam adres všech aktivních status listů vydavatele nebo celé služby \|
	+	\| Anonymita v davu (herd privacy) \| ochrana soukromí dosažená tím, že jeden list pokrývá velké množství výpisů \|
	+
	+	{{tag>status_list overeni_aktualnosti vypis_isvs eudi_wallet strojove_citelna_vrstva}}

Referenční rozhraní veřejné správy - [Popis referenčního rozhraní]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:26:44+00:00

2024/09/20 07:10		aktuální
Řádek 40:		Řádek 40:
	* 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ů.		* Záznamy (logy) o identifikaci žádajícího systému, času odpovědi, struktuře a obsahu poskytnutých údajů vede poskytující systém. Identifikaci poskytujícího systému, času přijetí odpovědi, struktuře a obsahu údajů vede přijímající systém. Referenční rozhraní zaznamenává identifikaci obou systémů, čas a strukturu předávaných údajů.
	* Procesní provázání s [[nap:system_spravy_dokumentu\|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.		* Procesní provázání s [[nap:system_spravy_dokumentu\|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.
		+
		+	==== Kontextový pohled na referenční rozhraní ====
		+
		+	{{ :nap:referencni_rozhrani_kontextovy_pohled.png?direct&850 \|Kontextový pohled na referenční rozhraní veřejné správy ČR}}
		+
		+	//Obrázek – Referenční rozhraní veřejné správy ČR v kontextu okolních systémů//
		+
		+	Pohled ukazuje referenční rozhraní jako jednotné rozhraní, přes které agendové informační systémy v perimetru orgánu veřejné moci (OVM) sdílejí údaje. Rozhraní realizují komponenty propojeného datového fondu (PPDF): [[nap:iszr\|ISZR]], [[nap:egsb\|ISSS/eGSB]] a [[nap:fais\|Formulářový AIS]].
		+
		+	Agendový informační systém (AIS) vystupuje vůči referenčnímu rozhraní v několika rolích:
		+	* jako čtenářský systém PPDF čte údaje jiných agend,
		+	* jako poskytovatel dat publikuje údaje své agendy,
		+	* jako systém pro zavádění a editaci dat zapisuje a edituje údaje (typicky editorské AIS základních registrů),
		+	* spolu s podpůrnými IS zajišťuje výkon agendy.
		+
		+	K referenčnímu rozhraní se dále vážou:
		+	* datové schránky (ISDS), přes které jsou mimo jiné doručovány požadavky a odpovědi Formulářového AIS,
		+	* centrální služby jednotné identity úředníků – CAAIS pro identifikaci a autentizaci úředníků v AIS a JIP/KAAS pro identifikaci a autentizaci soukromoprávních uživatelů údajů (SPUÚ),
		+	* otevřená data – Národní katalog otevřených dat, ze kterého čerpají koncové systémy včetně informačních systémů komerčních subjektů.
		+
		+	Nad perimetrem OVM leží obslužné kanály (CzechPOINT, digitální služby veřejné správy realizované portálem úřadu a AIS), elektronická identita (služby [[nap:nia\|Národního bodu pro identifikaci a autentizaci]]) a koncové systémy a klientské aplikace: Portál občana, koncové aplikační nástroje subjektů práva, soukromoprávní systémy pro využívání údajů a informační systémy komerčních subjektů.

	==== Informační systém správy čerpání a publikace údajů referenčního rozhraní veřejné správy ČR ====		==== Informační systém správy čerpání a publikace údajů referenčního rozhraní veřejné správy ČR ====
Řádek 140:		Řádek 161:
	[[nap:editorske_ais\|Editoři referenčních údajů v základních registrech]] realizují napojení svých editorských agendových informačních systémů na [[nap:iszr\|ISZR]] službami vnějšího rozhraní podle příslušné dokumentace Správy základních registrů a v případech, kdy agendové informační systémy nejsou též samostatnými evidencemi dokumentů, pak napojení těchto systémů na [[nap:system_spravy_dokumentu\|eSSL]] v rámci vnitřních vazeb. Pro editaci údajů a vyřizování reklamací údajů v základních registrech nevyužívají jiné rozhraní než právě ISZR.		[[nap:editorske_ais\|Editoři referenčních údajů v základních registrech]] realizují napojení svých editorských agendových informačních systémů na [[nap:iszr\|ISZR]] službami vnějšího rozhraní podle příslušné dokumentace Správy základních registrů a v případech, kdy agendové informační systémy nejsou též samostatnými evidencemi dokumentů, pak napojení těchto systémů na [[nap:system_spravy_dokumentu\|eSSL]] v rámci vnitřních vazeb. Pro editaci údajů a vyřizování reklamací údajů v základních registrech nevyužívají jiné rozhraní než právě ISZR.

-	==== Technické náležitosti uskutečňování vazeb ====	+	==== Pravidla užívání referenčního rozhraní ====
-		+
-	Před uskutečněním vazby musí správce informačního systému veřejné správy zajistit:	+
-	- Ztotožnění všech objektů a subjektů práva vedených v informačních systémech veřejné správy proti základním registrům. Pro neztotožněné subjekty nelze uskutečnit vazbu mezi informačními systémy veřejné správy.	+
-	- Přístup k centrálnímu místu služeb, pomocí kterého je referenční rozhraní výlučně přístupné.	+
-	- Přístup ke kompletnímu a aktuálnímu obsahu údajů strukturovaných dle § 23 odst. 1 písm. c) vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy jako údaje vlastní nereferenční. Přístup musí být zajištěn v otevřeném a strojově zpracovatelném formátu a v podobě datových souborů s kompletním aktuálním obsahem údajů nebo v podobě programovacího aplikačního rozhraní, které umožní získání kompletního obsahu údajů.	+
-	- Zároveň s obsahem údajů umožňuje poskytování metadat popisujících obsah údajů dle otevřené formální normy, kterou vydává Digitální a informační agentura.	+
-	- Orgán veřejné správy je povinen zabezpečit datové zdroje neveřejných údajů podle bodu 3 proti neoprávněnému přístupu.	+
-		+
-	Vazba, v rámci které se předávají údaje o subjektu či objektu práva, musí splnit následující technické náležitosti:	+
-	- Požívat pro údaje znakovou sadu UNICODE v kódování UTF-8	+
-	- Využívat šifrování SHA-256 nebo vyšší	+
-	- Využívat datového formátu XML	+
-	- Využívat pro uskutečnění vazby certifikát vydaný Správou základních registrů, který není certifikátem pro elektronický podpis, certifikátem pro elektronickou pečeť nebo certifikátem pro autentizaci internetových stránek. Tento certifikát je v rámci vazby vydaný pro každý systém zvlášť a slouží k technickému zabezpečení vazby. (zajištění přístupu dle 111/2009 § 7 odst. 2 písm. f) a g)	+
-		+
-	Vazba, v rámci které se nepředávají údaje o subjektu práva, musí splnit pouze náležitost dle bodu 4 výše.	+
-		+
-	==== Funkční náležitosti uskutečňování vazeb ====	+

-	- Vazbu je možné uskutečnit pouze mezi informačními systémy veřejné správy uvedenými v rejstříku informačních systémů veřejné správy (dle zákona 111/2009 Sb.).	+	{{page>znalostni_baze:pravidla_ref_rozhrani}}
-	- Vazbou se mohou vyměňovat pouze údaje, jejichž výčet a struktura je uvedena v základním registru práv a povinností (dle §51 odst. 6 písm. j) zákona 111/2009 Sb.).	+
-	- Využití služeb referenčního rozhraní pro uskutečnění vazby mezi informačními systémy veřejné správy musí být činěno prostřednictvím Centrálního místa služeb. Taková vazba nesmí být uskutečněna pomocí služby publikace do internetu Centrálního místa služeb	+
-	- Vazba nesmí být uskutečňována s informačním systémem veřejné správy, jehož certifikát byl zveřejněn jako zneplatněný	+
-	- Informační systém veřejné správy využívající vazby (využívající služby) z referenčního rozhraní je opatřen funkcí zaznamenávání a uchovávání záznamů o událostech spojených s vazbou; funkce zaznamenávání vytvoří o vazbě vždy záznam, který se skládá z:	+
-	- identifikace informačního systému veřejné správy, který je žádán o data,	+
-	- času odeslání žádosti o data,	+
-	- informaci o tom, zda byla požadovaná data informačnímu systému veřejné správy přijata,	+
-	- v případě, že data byla přijata, informaci o času přijetí dat,	+
-	- v případě, že data byla přijata, hodnoty, které reprezentují obsah dat přijatých informačním systém veřejné správy; hodnoty se mohou vést v zašifrované podobě umožňující zpětně ověřit jaký, obsah dat byl přijat.	+
-	- Informační systém veřejné správy uskutečňující vazby (poskytující služby) na referenční rozhraní je opatřen funkcí zaznamenávání a uchovávání záznamů o událostech spojených s vazbou; funkce zaznamenávání vytvoří o vazbě vždy záznam, který se skládá z:	+
-	- identifikace informačního systému veřejné správy, který žádá o data,	+
-	- času přijetí žádosti data,	+
-	- informaci o tom, zda byla požadovaná data informačnímu systému veřejné správy poskytnuta,	+
-	- v případě, že data byla poskytnuta, informaci o času poskytnutí dat,	+
-	- v případě, že data byla přijata, hodnoty, které reprezentují obsah dat poskytnutých informačnímu systému veřejné správy; hodnoty se mohou vést v zašifrované podobě umožňující zpětně ověřit jaký, obsah dat byl poskytnut.	+
-	- Každý informační systém veřejné správy využívající služby referenčního rozhraní musí při zpracovávání bezvýznamového identifikátoru k objektu nebo subjektu práva zajistit, aby vnitřní uspořádání informačního systému veřejné správy umožňovalo oddělit údaje evidenční a údaje identitní dle § 23 odst. 3 vyhlášky č. 360/2023 Sb. o dlouhodobém řízení informačních systémů veřejné správy	+
-	- Každý informační systém veřejné správy uskutečňující vazby na referenčním rozhraní je povinen zveřejnit provozní řád dle § 12 odst. 6 vyhlášky č. 360/2023 Sb. o dlouhodobém řízení informačních systémů veřejné správy stanovící podmínky a pravidla pro využívání vazby na referenčním rozhraní ostatními informační systémy veřejné správy	+
-	- Informační systém veřejné správy uskutečňující vazbu na referenčním rozhraní má právo zrušit vazbu (neboli neposkytnout službu), pokud informační systém veřejné správy využívající vazbu na referenčním rozhraní poruší jeho pravidla stanovené provozním řádem dle § 12 odst. 6 vyhlášky č. 360/2023 Sb. o dlouhodobém řízení informačních systémů veřejné správy.	+
-	- Nastane-li spor mezi informačním systémem veřejné správy uskutečňující vazbu na referenční rozhraní a informačním veřejné správy využívající vazbu na referenčním rozhraní dle bodu 9, může správce informačního systému veřejné správy využívající vazbu na referenčním rozhraní požádat Digitální a informační agenturu o přezkoumání provozního řádu informačního systému veřejné správy uskutečňujícího vazbu na referenčním rozhraní.	+
-	- Shledá-li Digitální a informační agentura dle bodu 10, že vazba informačního systému uskutečňujícího vazbu na referenčním rozhraní neměla být zrušena, je správce tohoto informačního systému veřejné správy povinen neprodleně vazbu obnovit a opravit svůj provozní řád pro zamezení dalších sporů.	+

-	Veškeré technické a funkční náležitosti a jejich splnění uvede správce informačního systému veřejné správy do Informační koncepce orgánu veřejné správy dle § 3 vyhlášky č. 360/2023 Sb. o dlouhodobém řízení informačních systémů veřejné správy.

	{{tag>"referenční rozhraní" "Základní registry" ISZR eGSB ISSS FAIS "Funkční celek"}}		{{tag>"referenční rozhraní" "Základní registry" ISZR eGSB ISSS FAIS "Funkční celek"}}

Národní identitní autorita - [Nevizuální přihlašování z mobilních aplikací]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:18:29+00:00

2025/10/03 06:40		aktuální
Řádek 15:		Řádek 15:
	* V budoucím stavu (stav To-Be) pro občany ČR, cizince s trvalým/přechodným pobytem a [[nap:ejfo\|jiné fyzické osoby (EjFO)]], které mají k ČR právní či majetkový vztah (zahraniční vlastník nemovitosti, zahraniční lékař, zahraniční student, apod.).		* V budoucím stavu (stav To-Be) pro občany ČR, cizince s trvalým/přechodným pobytem a [[nap:ejfo\|jiné fyzické osoby (EjFO)]], které mají k ČR právní či majetkový vztah (zahraniční vlastník nemovitosti, zahraniční lékař, zahraniční student, apod.).

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

	==== Seznam poskytovatelů identity (Identity Provider; IdP) ====		==== Seznam poskytovatelů identity (Identity Provider; IdP) ====
Řádek 998:		Řádek 998:
	Více viz popis [[https://dev.azure.com/SpravaZakladnichRegistru/NIA%20pro%20v%C3%BDvoj%C3%A1%C5%99e/_wiki/wikis/NIA-pro-v%C3%BDvoj%C3%A1%C5%99e.wiki/53/P%C5%99ihla%C5%A1ov%C3%A1n%C3%AD-z-mobiln%C3%ADch-aplikac%C3%AD\|na stránkách SZR ČR]].		Více viz popis [[https://dev.azure.com/SpravaZakladnichRegistru/NIA%20pro%20v%C3%BDvoj%C3%A1%C5%99e/_wiki/wikis/NIA-pro-v%C3%BDvoj%C3%A1%C5%99e.wiki/53/P%C5%99ihla%C5%A1ov%C3%A1n%C3%AD-z-mobiln%C3%ADch-aplikac%C3%AD\|na stránkách SZR ČR]].

		+	==== Certifikáty poskytovatele služby a autorizace digitálního úkonu ====
		+
		+	Oddíl odpovídá na časté dotazy poskytovatelů služeb (SeP), kteří využívají Národní bod k přihlašování uživatelů a ke službě autorizace digitálního úkonu (ADU), například pro zajištění fikce podpisu na portálu orgánu veřejné moci. Odpovědi vycházejí z vyjádření správce NIA (DIA, září 2026).
		+
		+	Technická dokumentace pro vývojáře je ve [[https://dev.azure.com/SpravaZakladnichRegistru/NIA%20pro%20v%C3%BDvoj%C3%A1%C5%99e/_wiki/wikis/NIA-pro-v%C3%BDvoj%C3%A1%C5%99e.wiki/67/Autorizace-digit%C3%A1ln%C3%ADho-%C3%BAkonu\|wiki NIA pro vývojáře – Autorizace digitálního úkonu]].
		+
		+	=== Dva různé certifikáty v konfiguraci SeP ===
		+
		+	V administraci SeP se pracuje se dvěma certifikáty, které spolu nesouvisejí:
		+
		+	^ Certifikát ^ K čemu slouží ^ Jak se do NIA dostane ^ Je potřeba privátní klíč? ^
		+	\| Šifrovací certifikát SeP \| NIA jeho veřejnou částí šifruje údaje předávané poskytovateli služby v tokenu. \| Import ze SAML 2.0 metadat SeP (element ''KeyDescriptor use="encryption"'') z URL nebo z lokálního souboru. Platí to i pro SeP, který přihlašuje přes OIDC. \| Ano, ale jen na straně SeP pro dešifrování tokenu. NIA pracuje s veřejnou částí. \|
		+	\| Certifikát pro autorizaci digitálního úkonu \| Pouze rozlišuje konfiguraci ADU daného SeP. Nejde o autentizační prostředek. \| Ruční nahrání jednoho souboru ''.cer'' v administraci SeP. V požadavcích ''TR_ADU_*'' se předává celý certifikát (DER v Base64) v poli ''CertifikatHashBase64'' a porovnává se s certifikátem uloženým v konfiguraci SeP. \| Ne, stačí veřejný certifikát. \|
	===== Pravidla pro Národní identitní autoritu =====		===== Pravidla pro Národní identitní autoritu =====

Evidence jiných fyzických osob

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:16:52+00:00

XML validátor DIA - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:14:13+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== XML validátor DIA ======
	+
	+	Digitální a informační agentura provozuje XML validátor, kterým lze ověřit, zda XML dokument odpovídá schématu stanovenému pro vybrané typy elektronických dokumentů a záznamů veřejné správy. Validátor je určen orgánům veřejné moci a dodavatelům jejich informačních systémů, kteří tyto dokumenty vytvářejí nebo přijímají.
	+
	+	Stabilní verze validátoru je na platformě DIA nasazena od dubna 2026 a pokrývá všechny požadované validace, včetně podpory verze schématu, o kterou DIA požádala.
	+
	+	===== Podporované validace =====
	+
	+	Validátor nabízí webové rozhraní pro nahrání souboru i aplikační rozhraní (API).
	+
	+	^ Typ dokumentu ^ Webové rozhraní ^
	+	\| Osvědčení o digitálním úkonu \| [[https://xml-validator.dia.gov.cz/osvedceni-digitalniho-ukonu/upload]] \|
	+	\| Doložka ověření elektronického podpisu (záznam informačního systému nahrazující úředně ověřený podpis) \| [[https://xml-validator.dia.gov.cz/zaznam-informacniho-systemu-nahrazujici-uredne-overeny-podpis/upload]] \|
	+	\| Dokumenty elektronického podání z formulářů podle zákona o právu na digitální služby \| [[https://xml-validator.dia.gov.cz/dokumenty-z-formularu-ZoPDS/upload]] \|
	+	\| Společné části elektronických dokumentů \| [[https://xml-validator.dia.gov.cz/spolecne-casti-elektronickych-dokumentu/upload]] \|
	+	\| Strojově čitelná vrstva – metadata dokumentů veřejnoprávních původců \| [[https://xml-validator.dia.gov.cz/metadata-dokumentu-verejnopravnich-puvodcu/upload]] \|
	+
	+	===== Použití =====
	+
	+	* Ruční kontrola: dokument nahrajte přes webové rozhraní příslušného typu; validátor vrátí výsledek kontroly proti schématu.
	+	* Automatizovaná kontrola: pro začlenění do vývoje nebo testování informačního systému použijte API validátoru.
	+
	+	Potřebujete-li úpravu validátoru nebo jeho vyladění pro konkrétní použití, obraťte se na DIA.

AIFO pro osoby, které nejsou vedeny v registru obyvatel - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-10-07T13:13:43+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== AIFO pro osoby, které nejsou vedeny v registru obyvatel ======
	+
	+	Stránka popisuje architektonický návrh, jak by mohl agendový informační systém primárního editora resortní evidence získat agendový identifikátor fyzické osoby (AIFO) pro osobu, kterou nelze ztotožnit proti registru obyvatel (ROB), a jak by se k údajům o takové osobě dostaly ostatní agendy prostřednictvím [[nap:referencni_rozhrani\|referenčního rozhraní]]. Návrh je popsán na příkladu Kmenového registru pacientů (KRP) resortu zdravotnictví. Princip je však použitelný pro každou agendu, která vede osoby mimo ROB – typicky cizince bez pobytu na území, přeshraniční pracovníky a jejich rodinné příslušníky, samoplátce nebo jednorázově obsloužené osoby.
	+
	+	Řešení nezavádí žádnou novou komponentu a nemění rozhraní žádné eGON služby. Využívá službu převodníku identifikátorů, která umí vydat AIFO i osobě mimo ROB a je v provozu od 1. 7. 2012. Mění se pouze okruh agend, které ji smějí volat, a informační systém sdílené služby (ISSS) se upravuje tak, aby prošel dotaz na osobu, která v ROB není.
	+
	+	{{ :nap:aifo_mimo_rob_prehled.png?direct&900 \|Přehled řešení}}
	+
	+	//Obrázek 1 – Přehled řešení. Žlutě je vyznačeno, co se mění: volání navíc na straně resortní evidence (získání AIFO) a úprava ISSS. Vše ostatní je dnešní provoz.//
	+
	+	===== Zkratky =====
	+
	+	^ Zkratka ^ Význam ^
	+	\| AIFO \| agendový identifikátor fyzické osoby \|
	+	\| ZIFO \| zdrojový identifikátor fyzické osoby \|
	+	\| ROB \| registr obyvatel \|
	+	\| ISZR \| informační systém základních registrů \|
	+	\| ISSS \| informační systém sdílené služby (dříve eGSB) \|
	+	\| ORG \| převodník identifikátorů fyzických osob \|
	+	\| AISV \| agendový informační systém vyrozumívací \|
	+	\| PPDF \| propojený datový fond \|
	+	\| RPP \| registr práv a povinností \|
	+	\| RAZR \| registrační autorita základních registrů \|
	+	\| PAIS \| publikační agendový informační systém \|
	+	\| EJFO \| evidence jiných fyzických osob \|
	+	\| KRP \| Kmenový registr pacientů \|
	+	\| RID \| resortní identifikátor pacienta \|
	+	\| PZS \| poskytovatel zdravotních služeb \|
	+	\| ZP \| zdravotní pojišťovna \|
	+	\| SPUÚ \| soukromoprávní uživatel údajů \|
	+
	+	===== Proč to řešit =====
	+
	+	Resortní evidence ztotožňuje osoby proti základním registrům. Osobu, kterou ztotožnit nelze, vede také, ale bez AIFO. Taková osoba je pro zbytek státu neviditelná: nelze o ní číst údaje z propojeného datového fondu, nelze nikoho vyrozumět o změnách jejích údajů, a nelze si o ní tedy standardně vyměňovat údaje s jinými orgány (v příkladu zdravotnictví se zdravotními pojišťovnami). Resorty pak budují vlastní řešení identity, notifikačního kanálu a bilaterálních rozhraní.
	+
	+	Co řešení přináší:
	+	* O osobě lze komunikovat identifikátorem a sdílet o ní údaje včetně vyrozumívání o jejich změnách, a to týmž rozhraním, které se používá pro ostatní osoby.
	+	* Resortní identifikátor (v příkladu RID) není nutné používat pro meziresortní komunikaci. Tuto roli plní AIFO a mechanismus jeho převodů přes ORG. AIFO je pro každou agendu jiné a nelze z něj nic odvodit.
	+	* Získá-li osoba později pobyt a vznikne jí záznam v ROB, lze obě identity sloučit a stát změnu rozešle všem čtenářům. Resortní identifikátor se přitom nemění.
	+
	+	Co řešení nepřináší:
	+	* Nezabrání vzniku duplicitních identit. Do budoucna je lze omezovat, existující duplicity lze vyhledat a navrhnout ke sloučení, pokud je dost důkazů, že jde o tutéž osobu. Část agendy zůstane ruční (viz [[#zivotni_cyklus_identity_a_duplicity\|Životní cyklus identity a duplicity]]).
	+	* Není náhradou [[nap:ejfo\|evidence jiných fyzických osob]]. Referenčnost údajů, ztotožňování osob podle údajů a rozhodování sporů o duplicitní identity zůstávají mimo rozsah. Až EJFO vznikne, převezme existující identity; AIFO se podle § 10 odst. 3 zákona č. 111/2009 Sb. nemění a na straně resortu to neznamená žádnou implementaci.
	+
	+	===== Výchozí stav =====
	+
	+	==== Jak AIFO vzniká dnes ====
	+
	+	{{ :nap:aifo_mimo_rob_vznik_aifo_dnes.png?direct&700 \|Jak AIFO vzniká dnes}}
	+
	+	//Obrázek 2 – Jak AIFO vzniká dnes//
	+
	+	ZIFO a první AIFO vznikají dříve než záznam v ROB a nezávisle na něm. Zápis do ROB je samostatný krok, který provádí editor podle § 19 zákona č. 111/2009 Sb. Řešení využívá pouze první čtyři kroky tohoto řetězce; kroky 5 až 7 u osoby mimo ROB neproběhnou.
	+
	+	Právní opora je v § 9 odst. 1 zákona č. 111/2009 Sb.: AIFO je přiřazeno záznamu o fyzické osobě v agendovém informačním systému, základním registru nebo soukromoprávním systému pro využívání údajů, tedy nikoli výhradně záznamu v ROB.
	+
	+	==== Co selže u osoby mimo ROB ====
	+
	+	{{ :nap:aifo_mimo_rob_selhani.png?direct&700 \|Co selže u neztotožněné osoby}}
	+
	+	//Obrázek 3 – Co selže u neztotožněné osoby//
	+
	+	Nejde jen o chybějící identifikátor. Kontrola v ISSS je explicitní: podle popisu služby G1 gsbCtiData (v. 1.06) musí entity uvedené na vstupu (AIFO, IČO) standardně existovat, jinak je volání zamítnuto. Ověření existence AIFO a překlad mezi agendami se přitom zaznamenává v ROB jako využití údajů. Pro osobu bez záznamu v ROB tedy dnes neprojde ani samotné volání, ani jeho auditní záznam.
	+
	+	===== Princip řešení =====
	+
	+	* AIFO se vydá i bez zápisu do ROB, na žádost AIS primárního editora resortní evidence, službou //E95 orgZalozAIFOPE//. Služba je aktivní od 1. 7. 2012 a nemění se vstup, výstup ani logika. Mění se pouze konfigurace oprávnění na straně ISZR a RAZR.
	+	* Zdrojem identifikačních údajů je datový kontext resortu publikovaný do ISSS, nikoli ROB. Údaje jsou nereferenční a musí tak být i označeny.
	+	* Informace, že identita nemá vazbu na ROB, je odvoditelná z ORG, nejde o nový údaj. ORG ví, ve kterých agendách k danému ZIFO existuje AIFO, a vydá to službou //E199 orgZjistiAis//. Nepřítomnost AIFO agendy A101 je spolehlivá negace „osoba v ROB není“. Opačná implikace neplatí: přítomnost A101 neprokazuje, že záznam v ROB vznikl a dosud trvá; autoritativní odpověď dává jedině ROB. Scénář čtenáře je proto postaven tak, aby pozitivní tvrzení nepotřeboval.
	+	* Resortní identifikátor se do centra neukládá. Zůstává v resortu, a je-li potřeba, publikuje se jako běžný údaj v kontextu. Centrální tabulka „AIFO ↔ resortní identifikátor“ se nezavádí; § 9 zákona č. 111/2009 Sb. staví systém na tom, že z AIFO ani ZIFO nelze dovodit žádný jiný údaj o osobě.
	+	* Až vznikne EJFO, převezme existující identity. ZIFO i AIFO už existují a podle § 10 odst. 3 je nelze měnit. Migrace tedy znamená doplnit editora a referenční údaje, nikoli přečíslovat osoby v navazujících systémech.
	+
	+	===== Cílová architektura =====
	+
	+	{{ :nap:aifo_mimo_rob_cilova_architektura.png?direct&900 \|Cílová architektura}}
	+
	+	//Obrázek 4 – Cílová architektura//
	+
	+	Žádná nová komponenta nevzniká. AIS resortní evidence přibývají dvě role, které dnes nemá: žadatel o vydání AIFO a publikační AIS pro kontext s identifikačními údaji osoby.
	+
	+	===== Změny na straně resortní evidence =====
	+
	+	==== Založení identity osoby mimo ROB ====
	+
	+	{{ :nap:aifo_mimo_rob_zalozeni_identity.png?direct&800 \|Založení identity osoby mimo ROB}}
	+
	+	//Obrázek 5 – Založení identity osoby mimo ROB (příklad KRP)//
	+
	+	Pravidla, na kterých toto pořadí stojí:
	+	* AIFO se vydá až po neúspěšném ztotožnění proti ROB, nikdy paralelně. Jinak by osobě, která v ROB je, vždy vznikla další identita.
	+	* Vstupem E95 je pouze kód agendy a kód AIS, výstupem AIFO. Služba nepředává žádný osobní údaj a ORG žádný osobní údaj nedostane ani nevede.
	+	* U novorozence se AIFO mimo ROB nevydává. Zápis do ROB proběhne dnešním postupem do tří měsíců a vydání identity mimo ROB by vytvořilo duplicitu, které lze předejít.
	+	* Ve scénáři nevzniká žádná identitní událost. Vyrozumívání o //vzniku// identity není součástí řešení; čtenář se k osobě dostane cestami popsanými v kapitole [[#jak_se_ctenar_dostane_k_udajum\|Jak se čtenář dostane k údajům]].
	+
	+	==== Stav záznamu ====
	+
	+	V příkladu KRP dnes údaj TypZaznamu rozlišuje ztotožněný a neztotožněný záznam, přičemž ztotožněný fakticky znamená „má AIFO odvozené z ROB“. Přibývá třetí stav ztotožněný mimo ROB: záznam má AIFO, ale osoba není subjektem údajů ROB a její identifikační údaje jsou nereferenční. Údaje typicky plynou z dokladů cizince vydaných zdrojovou zemí a mohou se v čase měnit, aniž se to evidence dozví.
	+
	+	^ Stav záznamu ^ AIFO ^ Zdroj identifikačních údajů ^ Referenčnost ^
	+	\| Ztotožněný \| ano, přes ztotožnění proti ROB \| ROB \| referenční \|
	+	\| Ztotožněný mimo ROB \| ano, přes E95 \| kontext resortní evidence publikovaný do ISSS \| nereferenční \|
	+	\| Neztotožněný \| ne \| pouze resortní evidence \| nereferenční \|
	+
	+	Stav „neztotožněný“ nezaniká. Zůstává pro záznamy před vydáním identity a pro případy, kdy identita vydána nebude.
	+
	+	==== Publikace datového kontextu do ISSS ====
	+
	+	Resortní evidence se stává publikačním AIS pro kontext s identifikačními údaji osoby. Postup je standardní: žádost o publikaci kontextu se podává v aplikaci RAZR, definice publikovaných kontextů a datových obsahů se zveřejňují v Katalogu ISSS a oprávnění čtenáře na konkrétní kontext a jednotlivé údaje vzniká ohlášením agendy v [[nap:rpp\|RPP]] a žádostí v RAZR.
	+
	+	Rozsah kontextu je věcné rozhodnutí resortu. Závisí na něm použitelnost pro čtenáře i možnost budoucího ztotožňování podle údajů.
	+
	+	Údaje musí být čtenáři předány s příznakem, že nejsou referenční. Z hlediska § 5 odst. 2 zákona č. 111/2009 Sb., tedy využívání údajů bez ověřování jejich správnosti, je to rozdíl, který nesmí zaniknout.
	+
	+	==== Registrace jako publikační AIS v AISV ====
	+
	+	AISV je v provozu od 1. 9. 2024 a jeho správcem je DIA. Publikační AIS musí být předem zaregistrován včetně číselníku změn údajů, který se kontroluje proti RPP. Události nad záznamem se v AISV označují klíčovými slovy NovyZaznam, ZrusenyZaznam, SkartovanyZaznam a ZmenaEditora; při založení záznamu se použije pouze klíčové slovo, nikoli kódy jednotlivých údajů.
	+
	+	AISV se pro toto řešení nijak neupravuje – resortní evidence se registruje jako kterýkoli jiný publikační systém.
	+
	+	==== Evidování změn a vyrozumívání čtenářů ====
	+
	+	{{ :nap:aifo_mimo_rob_vyrozumivani.png?direct&800 \|Evidování změn a vyrozumívání čtenářů}}
	+
	+	//Obrázek 6 – Evidování změn a vyrozumívání čtenářů//
	+
	+	AISV nese informaci o tom, //že// se údaj změnil, nikoli jeho hodnotu. Hodnotu si čtenář dočte z kontextu přes ISSS. Vlastní notifikační systém resortu (v příkladu Systém notifikací EZ pro poskytovatele a zdravotnické pracovníky) zůstává pro subjekty uvnitř resortu a nemění se.
	+
	+	Poznámka k načasování: služby //E07 robCtiZmeny// a //E28 rosCtiZmeny// mají ukončenou podporu k 30. 6. 2026 a od 1. 1. 2027 je nebude možné používat. Čtenáři tedy na služby E315 až E318 migrují tak jako tak.
	+
	+	==== Změny AIFO po sloučení identit ====
	+
	+	Sloučí-li se dvě identity službou //E69 orgSpojZIFO//, nahrazují se původní ZIFO jedním novým a generují se nová AIFO ve všech dotčených agendách. Resortní evidence i čtenáři to zpracují službou //E78 orgCtiZmenyAIFO//, která vrací dvojice původní a nové AIFO.
	+
	+	Resortní identifikátor se tím nemění, mění se pouze AIFO uložené k záznamu. Tvrzení „AIFO se nemění“ platí pro převzetí identity jiným editorem podle § 10 odst. 3 zákona č. 111/2009 Sb., nikoli pro sloučení dvou identit.
	+
	+	===== Změny na straně DIA =====
	+
	+	^ # ^ Komponenta ^ Změna ^ Povaha ^
	+	\| Z1 \| ORG a ISZR – konfigurace \| Rozšířit okruh agend oprávněných volat E95 mimo dnešní primární editory ROB. Jde o zápis bezpečnostního profilu v RAZR a jeho import do ISZR; release ORG ani ISZR není potřeba. \| konfigurace \|
	+	\| Z2 \| ISSS \| Kontrolu existence entity provádět proti ORG, nikoli proti ROB, a vyřešit auditní záznam o využití údajů tam, kde záznam v ROB neexistuje. Jediná vývojová položka řešení. \| vývoj \|
	+	\| Z4 \| RPP a RAZR \| Registrace kontextu resortu, oprávnění čtenářů na údaje kontextu i na vyrozumívání, metodika pro ohlašovatele. \| konfigurace \|
	+	\| Z7 \| Metodika a legislativa \| Ustanovení v zákoně č. 111/2009 Sb., provozní řád, dokumentace a metodika pro čtenáře vydaná dříve než první AIFO. \| metodika \|
	+	\| Z8 \| ISZR – vlna 2, volitelná \| E276 robCtiAifo2 nevrací pro AIFO bez záznamu v ROB chybu, ale řízený stav „identita není vedena v ROB, primární evidencí je agenda A####“. Šetří čtenáři jedno volání a odstraňuje závislost na chybovém kódu. Není podmínkou spuštění. \| vývoj \|
	+
	+	Konfigurace oprávnění: ISZR povoluje volání podle RPP (agenda, role, OVM, AIS) a podle bezpečnostního profilu evidovaného v RAZR pro dvojici agenda × AIS. E95 je dnes zařazena pouze v profilu X10 „Primární editor – ORG“, který obsahuje i další editační služby ORG. Aby resortní editor nedostal víc, než potřebuje, je vhodné založit vlastní profil (pracovně RE10) jen se službami, které potřebuje.
	+
	+	===== Jak se čtenář dostane k údajům =====
	+
	+	==== Pořadí dotazů: nejdřív ROB, E199 až při neúspěchu ====
	+
	+	{{ :nap:aifo_mimo_rob_poradi_dotazu.png?direct&900 \|Pořadí dotazů čtenáře}}
	+
	+	//Obrázek 7 – Pořadí dotazů: nejdřív ROB, E199 až při neúspěchu (příklad zdravotní pojišťovny jako čtenáře)//
	+
	+	Pořadí stojí na třech důvodech:
	+	- Většina osob v ROB je. Předřazení E199 před dotaz do ROB by zatížilo ORG jedním voláním navíc pro celou populaci kvůli jejímu zlomku.
	+	- E199 se v menšinovém případě volá tak jako tak, protože čtenář z ní nepotřebuje jen příznak „není v ROB“, ale hlavně adresu primární evidence.
	+	- Odpověď ROB je autoritativní, odvození z ORG jen nepřímé.
	+
	+	Volání E199 je jednorázové na osobu, ne na transakci. Údaj o tom, která agenda je primární evidencí, je stabilní a čtenář si jej uloží ke svému záznamu spolu s AIFO.
	+
	+	Metodika pro čtenáře musí pokrýt tři významy záporné odpovědi ROB:
	+
	+	^ Význam ^ Jak se rozliší ^ Co má čtenář udělat ^
	+	\| Osoba v ROB skutečně není \| E199 vrátí agendu resortu a nevrátí A101 \| číst kontext přes ISSS \|
	+	\| Osoba je nebo byla vedena v ROB, ROB přesto vrátil, že záznam neexistuje (např. při jeho dočasné nedostupnosti) \| E199 vrátí i A101 \| dotaz zopakovat, do resortní evidence nechodit \|
	+	\| Čtenář drží neplatné AIFO po sloučení identit \| vstupní AIFO neprojde, resp. E199 nevrátí nic použitelného \| zjistit nové AIFO službou E78 orgCtiZmenyAIFO \|
	+
	+	==== Odkud čtenář vezme AIFO ====
	+
	+	{{ :nap:aifo_mimo_rob_zdroj_aifo_ctenare.png?direct&900 \|Odkud čtenář vezme AIFO}}
	+
	+	//Obrázek 8 – Odkud čtenář vezme AIFO//
	+
	+	Pro předávání osob mezi dvěma AIS v rámci procesu je podstatná dvojice služeb //E175 iszrUlozMapaAifo// a //E176 iszrPodejMapaAifo//. Zdrojový AIS uloží do ISZR dvojice svých a lokálních AIFO a předá cílovému AIS identifikátor úložky; cílový AIS si podle něj vyzvedne vlastní AIFO. Slouží to k podpoře předávání nereferenčních údajů mezi dvěma AIS – v příkladu zdravotnictví přesně scénář „KRP předává data zdravotní pojišťovně“.
	+
	+	Tyto služby už dnes umějí předávat AIFO, která v ROB neexistují. Verze V2 účinná od 27. 6. 2019 rozšířila službu o předávání AIFO neexistujících v ROB: AIFO, které není v ORG evidováno pro ROB nebo v ROB není platné, se ukládá a cílovému AIS předává s odpovídajícím příznakem. Chování navrhované pro ISSS tedy v PPDF již existuje.
	+
	+	Co tato cesta neřeší: čtenář, který má jen jméno a datum narození, se k AIFO osoby mimo ROB nedostane. Vyhledání podle údajů je k dispozici pouze nad ROB a AISC a ISSS se dotazuje výhradně podle AIFO nebo IČO. Řešení tuto mezeru nevytváří ani neuzavírá – jde o funkci ztotožňování podle údajů, tedy o roli [[nap:ejfo\|EJFO]]. Proti dnešku se nic nezhoršuje: dnes takový dotaz selže ve všech krocích, po zavedení řešení jen v tomto jediném.
	+
	+	===== Životní cyklus identity a duplicity =====
	+
	+	{{ :nap:aifo_mimo_rob_zivotni_cyklus.png?direct&600 \|Životní cyklus identity}}
	+
	+	//Obrázek 9 – Životní cyklus identity (příklad KRP)//
	+
	+	Přechod z identity mimo ROB do ROB nevede přes zápis k existujícímu ZIFO, ale přes vznik druhé identity a její následné sloučení. Stav „dvojí identita“ je tedy běžný, nikoli výjimečný.
	+
	+	{{ :nap:aifo_mimo_rob_duplicita.png?direct&300 \|Vznik a řešení duplicity}}
	+
	+	//Obrázek 10 – Vznik a řešení duplicity//
	+
	+	Proč duplicitám nelze předejít: editor ROB se nemá jak dozvědět, že osoba už je vedena v resortní evidenci. Musel by ji před zápisem vyhledat podle údajů v resortních kontextech a taková služba neexistuje – ISSS se dotazuje výhradně podle AIFO nebo IČO. Získání pobytového statusu navíc není událost, kterou by osoba hlásila resortu.
	+
	+	Model detekce a slučování je technicky průchozí: E199, E78, přihlášení AIFO, rodokmen i editační služby E68, E69 a E70 pracují i nad ZIFO bez vazby na ROB a ani u služeb pro spojení a rozdělení se nekontroluje, zda k identitě vzniklo AIFO pro ROB. ZIFO bez AIFO agendy A101 je legitimní trvalý stav – neobjeví se v žádné chybové sestavě ani úklidovém procesu.
	+
	+	Co v řešení chybí: kanál, kterým lze nahlásit podezření na duplicitu. E69 smí volat jen AIS primárního editora a jejím vstupem jsou konkrétní ZIFO, která se mají spojit – služba tedy předpokládá, že volající už odpověď zná. Forma ani rozsah takového kanálu zatím nejsou rozhodnuty. Do té doby zůstane část agendy ruční a bude se řešit na podnět.
	+
	+	===== Dopad do resortních standardů a datových modelů =====
	+
	+	Na příkladu standardu EZ Kmenové registry (v. 0.6 ze 6. 6. 2025) se mění tři místa. Obdobná místa je třeba zkontrolovat v každé resortní evidenci, která řešení převezme.
	+
	+	^ Místo ^ Dnešní stav ^ Nutná úprava ^
	+	\| Typ záznamu \| ztotožněný / neztotožněný, kde ztotožněný fakticky znamená „má AIFO z ROB“ \| přibývá třetí stav ztotožněný mimo ROB \|
	+	\| Omezení slučování \| „nelze sloučit dva záznamy ztotožněné vůči ROB, které mají AIFO“ \| Pravidlo je opřené o nesprávné kritérium. Jakmile AIFO dostanou i osoby mimo ROB, zablokuje právě ty případy, které je třeba slučovat. Kritérium je nutné přeformulovat na „vedený v ROB“, nikoli „má AIFO“. \|
	+	\| Slučování záznamů \| popsáno jen uvnitř resortu \| doplnit, že sloučení identit službou E69 mění AIFO ve všech agendách a čtenáři je zpracují přes E78, zatímco resortní identifikátor se nemění \|
	+
	+	===== Hraniční situace =====
	+
	+	^ Situace ^ Řešení ^
	+	\| Osoba získá pobyt a stane se subjektem ROB \| Vznikne druhá identita, sloučí se službou E69 orgSpojZIFO. Předejít tomu nelze. \|
	+	\| Táž osoba u dvou resortů \| Totéž – dvě ZIFO, sloučení až zpětně. \|
	+	\| Sloučení mění AIFO \| Čtenáři i resortní evidence zpracují změnu přes E78 orgCtiZmenyAIFO; resortní identifikátor se nemění. \|
	+	\| Dvojí událost o vzniku téže osoby \| Při vzniku záznamu v ROB vznikne událost NovyZaznam podruhé, v publikačním systému ROB a pod jiným AIFO. Čtenář vede o osobě dva záznamy až do sloučení; metodika musí říct, že se po sloučení spojují podle E78. \|
	+	\| Chybně založená identita \| E68 orgZneplatniZIFO – služba je určena výhradně pro AIS primárních editorů. \|
	+	\| Reklamace údaje \| Reklamaci nereferenčních údajů řeší editor kontextu, nikoli správce ROB. (Reklamační rozhraní KRP již dnes pracuje s referencí do úložky ORG.) \|
	+	\| Novorozenec \| Dnešní postup, zápis do ROB do tří měsíců. AIFO mimo ROB se nevydává. \|
	+	\| Zánik účelu evidence \| Skartační lhůta se řídí věcným zákonem (u zdravotnické dokumentace 50 let od úmrtí). Zneplatnění ZIFO při zániku účelu je nutné ošetřit metodicky. \|
	+	\| Nedostatky v přidělení AIFO podle § 10 zákona č. 111/2009 Sb. \| § 10 odst. 7 směruje řešení na správce ROB, který u osoby mimo ROB nemá o čem rozhodovat. Náhradní uspořádání je nutné řešit legislativní úpravou. \|
	+
	+	===== Použité eGON služby =====
	+
	+	^ Služba ^ Kdo volá ^ K čemu ^ Stav ^
	+	\| E95 orgZalozAIFOPE \| AIS primárního editora resortní evidence \| vytvoření ZIFO a odvození AIFO pro agendu editora \| aktivní od 1. 7. 2012, nemění se \|
	+	\| E308 aisvEvidujZmenu \| resortní evidence jako PAIS \| evidence změny publikovaného údaje v AISV \| aktivní, nemění se \|
	+	\| E78 orgCtiZmenyAIFO \| resortní evidence i čtenáři \| změny samotných AIFO po sloučení nebo rozdělení identity \| aktivní, nemění se \|
	+	\| E68 orgZneplatniZIFO, E69 orgSpojZIFO \| primární editor \| zneplatnění a sloučení identit \| aktivní, nemění se \|
	+	\| G1 gsbCtiData \| čtenáři \| čtení údajů z publikovaného kontextu přes ISSS \| upravuje DIA (změna Z2) \|
	+	\| E276 robCtiAifo2 \| čtenáři \| čtení referenčních údajů z ROB, první krok čtenáře \| beze změny ve vlně 1, řízený stav ve vlně 2 (Z8) \|
	+	\| E199 orgZjistiAis \| čtenáři \| nalezení agendy a AIS, ve kterých k témuž ZIFO existuje AIFO \| aktivní od 1. 8. 2015, nemění se \|
	+	\| E315 až E318 \| čtenáři \| přihlášení identifikátorů a odběr změn z AISV \| aktivní, nemění se \|
	+	\| E175 iszrUlozMapaAifo, E176 iszrPodejMapaAifo \| resortní evidence a čtenáři \| předání AIFO mezi dvěma AIS v rámci procesu \| aktivní, od 27. 6. 2019 podporují AIFO neexistující v ROB \|
	+
	+	Podrobné popisy služeb jsou v [[https://szrcr.cz/cs/sluzby/spravci-a-vyvojari/vyvojari-agendovych-informacnich-systemu/podrobny-popis-egon-sluzeb-zakladnich-registru\|katalogu eGON služeb]].
	+
	+	===== Co musí rozhodnout resort =====
	+
	+	Resort, který by chtěl řešení převzít, musí vyjasnit:
	+	* kdo vystupuje jako primární editor identity pro osoby mimo ROB a odpovídá za to, že nezaloží identitu někomu, kdo ji už má (v příkladu KRP zakládají záznamy poskytovatelé i zdravotní pojišťovny, je tedy nutné určit, kdo volá E95 a kdo odpovídá za kvalitu identity),
	+	* rozsah datového kontextu, tedy které identifikační údaje bude publikovat do ISSS,
	+	* počet dnes neztotožněných záznamů a odhad ročního přírůstku (pro dimenzování ISZR a ORG a pro odhad objemu duplicitní agendy),
	+	* připravenost evidence vystupovat jako publikační systém v AISV, tedy zaregistrovat se včetně číselníku změn údajů a volat E308,
	+	* postoj k tomu, zda se úprava zakotví v zákoně o základních registrech, nebo ve věcném resortním zákoně.
	+
	+	===== Otevřené otázky =====
	+
	+	* Obsah bezpečnostního profilu pro resortní editory (pracovně RE10).
	+	* Návratové chování E276 pro AIFO bez záznamu v ROB – rozhoduje o tom, zda změna Z8 zůstane volitelnou vlnou 2.
	+	* Forma a rozsah kanálu pro hlášení podezření na duplicitu.
	+	* Paragrafové znění úpravy zákona č. 111/2009 Sb.
	+	* Vyhledání osoby, která svou vazbu na jinou evidenci doloží, aby jí nevznikla druhá identita, není součástí návrhu.
	+
	+	===== Související stránky =====
	+
	+	* [[nap:ejfo\|Evidence jiných fyzických osob]]
	+	* [[nap:evidence_udaju_o_subjektech\|Evidence údajů o subjektech]]
	+	* [[nap:pseudonymizace_subjektu_v_datovem_fondu\|Pseudonymizace subjektů v datovém fondu]]
	+	* [[nap:referencni_rozhrani\|Referenční rozhraní veřejné správy]]
	+	* [[nap:iszr\|Informační systém základních registrů]]
	+	* [[nap:egsb\|Informační systém sdílené služby]]
	+	* [[nap:rpp\|Registr práv a povinností]]

Komunikační infrastruktura veřejné správy - [Služby Centrálního místa služeb 2. generace (služby 2.0)]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-09-18T13:29:06+00:00

2026/04/30 11:48		aktuální
Řádek 81:		Řádek 81:
	==== Služby Centrálního místa služeb 2. generace (služby 2.0) ====		==== Služby Centrálního místa služeb 2. generace (služby 2.0) ====

-	<WRAP center round info 60%>	+	<WRAP center round info 60%>Popis služeb na této stránce vychází z dokumentu Ministerstva vnitra [[https://mv.gov.cz/soubor/prehled-sluzeb-cms.aspx\|Přehled služeb CMS]], verze 2.8.0 ze dne 11. 3. 2025. Závazným zdrojem je vždy aktuální verze tohoto dokumentu; rozcestník je na [[https://mv.gov.cz/clanek/komunikacni-infrastruktura-verejne-spravy-a-centralni-misto-sluzeb.aspx?q=Y2hudW09NA%3D%3D\|webu MV]].</WRAP>
-	Přehled služeb k nalezení také na webu MV [[https://mv.gov.cz/clanek/komunikacni-infrastruktura-verejne-spravy-a-centralni-misto-sluzeb.aspx?q=Y2hudW09NA%3d%3d]]	+
-	</WRAP>	+

		+	=== Rejstřík katalogových služeb CMS 2.0 ===
		+
		+	^ Kód služby ^ Název služby ^ Stav služby ^
		+	\| CMS2-01-1 \| Akceptace provozních podmínek CMS \| V provozu \|
		+	\| CMS2-01-2 \| Akceptace provozních podmínek Extranetu CMS \| V provozu \|
		+	\| CMS2-02-1 \| Zveřejnění aplikace \| V provozu \|
		+	\| CMS2-03-1 \| Přístup k aplikaci v síti CMS \| V provozu \|
		+	\| CMS2-03-2 \| Přístup k aplikaci v síti TESTA-ng \| V provozu \|
		+	\| CMS2-03-3 \| Přístup k aplikaci v síti Internet \| V provozu \|
		+	\| CMS2-04-1 \| Publikace AIS na eGSB \| Ukončena \|
		+	\| CMS2-05-1 \| Odchozí provoz elektronické pošty \| V provozu \|
		+	\| CMS2-05-2 \| Příchozí provoz elektronické pošty \| V provozu \|
		+	\| CMS2-05-3 \| Server elektronické pošty \| V provozu \|
		+	\| CMS2-06-1 \| DNS hosting – Veřejná registrovaná doména do Internetu \| V provozu \|
		+	\| CMS2-06-2 \| DNS hosting – Veřejná doména CMS \| V provozu \|
		+	\| CMS2-06-3 \| DNS hosting – Neveřejná doména \| V provozu \|
		+	\| CMS2-06-4 \| DNS – Distribuce veřejně registrované domény do KIVS \| Ukončena \|
		+	\| CMS2-06-5 \| DNS – Hosting veřejně registrované domény do KIVS \| Ukončena \|
		+	\| CMS2-07-1 \| Služby TESTA-ng \| V provozu \|
		+	\| CMS2-08-1 \| Přístup do CMS přes KIVS \| V provozu \|
		+	\| CMS2-08-2 \| Přístup do CMS přes IPsec \| V provozu \|
		+	\| CMS2-08-3 \| Přístup do CMS přes SSL \| V provozu \|
		+	\| CMS2-08-4 \| Přístup do CMS z NDC \| V provozu \|
		+	\| CMS2-08-5 \| Přístup technických pracovníků Subjektu do CMS přes SSL \| V provozu \|
		+	\| CMS2-09-1 \| Přímý přístup do Internetu \| V provozu \|
		+	\| CMS2-09-2 \| Bezpečný přístup do Internetu \| V provozu \|
		+	\| CMS2-10-1 \| Přístup k záznamům o provozu \| Nerealizovaná \|
		+	\| CMS2-11-1 \| Přístup k účtovacím informacím \| Nerealizovaná \|
		+	\| CMS2-12-1 \| Propojovací bod Subjektu \| V provozu \|
		+	\| CMS2-12-2 \| Propojovací bod pro Extranet \| V provozu \|
		+	\| CMS2-13-1 \| Testování publikace aplikace \| V provozu \|
		+	\| CMS2-13-2 \| Testování distribuce veřejně registrované domény do KIVS \| V provozu \|
		+	\| CMS2-13-3 \| Testování hostingu veřejně registrované domény do KIVS \| V provozu \|
		+	\| CMS2-14-1 \| MS WSUS – Aktualizační služba WSUS \| V provozu \|
		+
		+	Služby označené jako Nerealizovaná nelze objednat, přestože jsou v katalogu popsány. Služby označené jako Ukončena se již neposkytují.
		+
		+	=== Přehled SLA u služeb CMS 2.0 ===
		+
		+	^ Kód služby ^ Název služby ^ SLA v % ^ Max. reakční doba ^ Max. doba obnovy ^ Doba držení SLA ^ Měřicí bod služby ^
		+	\| CMS2-01-1 \| Akceptace provozních podmínek CMS \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost Portálu CMS \|
		+	\| CMS2-01-2 \| Akceptace provozních podmínek Extranetu CMS \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost Propojovacího bodu Extranetu \|
		+	\| CMS2-02-1 \| Zveřejnění aplikace \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost aplikace na hraně CMS \|
		+	\| CMS2-03-1 \| Přístup k aplikaci v síti CMS \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost konektivity z připojovacího bloku \|
		+	\| CMS2-03-2 \| Přístup k aplikaci v síti TESTA-ng \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost konektivity z připojovacího bloku \|
		+	\| CMS2-03-3 \| Přístup k aplikaci v síti Internet \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost konektivity z připojovacího bloku \|
		+	\| CMS2-04-1 \| Publikace AIS na eGSB (ukončena) \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost AIS na hraně CMS \|
		+	\| CMS2-05-1 \| Odchozí provoz elektronické pošty \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost MTA služby CMS \|
		+	\| CMS2-05-2 \| Příchozí provoz elektronické pošty \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost MTA služby CMS \|
		+	\| CMS2-05-3 \| Server elektronické pošty \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost virtuálního mailserveru CMS \|
		+	\| CMS2-06-1 \| DNS hosting – veřejná registrovaná doména \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost DNS služby CMS \|
		+	\| CMS2-06-2 \| DNS hosting – veřejná doména CMS \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost DNS služby CMS \|
		+	\| CMS2-06-3 \| DNS hosting – neveřejná doména \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost DNS služby CMS \|
		+	\| CMS2-06-4 \| DNS – distribuce domény do KIVS (ukončena) \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost DNS služby CMS \|
		+	\| CMS2-06-5 \| DNS – hosting domény do KIVS (ukončena) \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost DNS služby CMS \|
		+	\| CMS2-07-1 \| Služby TESTA-ng \| N/A \| – \| – \| – \| – \|
		+	\| CMS2-08-1 \| Přístup do CMS přes KIVS \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost konektivity z připojovacího bloku \|
		+	\| CMS2-08-2 \| Přístup do CMS přes IPsec \| N/A \| – \| – \| – \| – \|
		+	\| CMS2-08-3 \| Přístup do CMS přes SSL \| N/A \| – \| – \| – \| – \|
		+	\| CMS2-08-4 \| Přístup do CMS z NDC \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost konektivity z NDC bloku \|
		+	\| CMS2-08-5 \| Přístup technických pracovníků do CMS přes SSL \| N/A \| – \| – \| – \| – \|
		+	\| CMS2-09-1 \| Přímý přístup do Internetu \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost Internetu \|
		+	\| CMS2-09-2 \| Bezpečný přístup do Internetu \| 99 \| 30 min \| 8 h \| 24x7 \| Dostupnost proxy CMS \|
		+	\| CMS2-10-1 \| Přístup k záznamům o provozu \| 99 \| 30 min \| 8 h \| 8x5 \| Dostupnost portálu \|
		+	\| CMS2-11-1 \| Přístup k účtovacím informacím \| 99 \| 30 min \| 8 h \| 8x5 \| Dostupnost portálu \|
		+	\| CMS2-12-1 \| Propojovací bod Subjektu \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost FW Subjektu \|
		+	\| CMS2-12-2 \| Propojovací bod pro Extranet \| 99,9 \| 30 min \| 4 h \| 24x7 \| Dostupnost FW Extranet \|
		+	\| CMS2-13-1 \| Testování publikace aplikace \| N/A \| 30 min \| BE \| 24x7 \| Dostupnost SSL VPN koncentrátoru \|
		+	\| CMS2-13-2 \| Testování distribuce domény do KIVS \| N/A \| – \| – \| – \| Služba není monitorována \|
		+	\| CMS2-13-3 \| Testování hostingu domény do KIVS \| N/A \| – \| – \| – \| Služba není monitorována \|
		+	\| CMS2-14-1 \| MS WSUS – Aktualizační služba WSUS \| N/A \| – \| – \| – \| Dostupnost Aktualizační služby WSUS CMS \|
		+
		+	N/A = dostupnost služby bez garance. BE = doba obnovy bezodkladně.

	=== Služba CMS2 – 01 – Akceptace provozních podmínek CMS ===		=== Služba CMS2 – 01 – Akceptace provozních podmínek CMS ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-01 \|		\| Kód služby \| CMS2-01 \|
	\| Název služby \| Akceptace provozních podmínek CMS \|		\| Název služby \| Akceptace provozních podmínek CMS \|
-	\| Popis služby \| Služba je procesní nástroj pro akceptaci provozních podmínek systému CMS pro jeho nové uživatele. Bez akceptování provozních podmínek není možné žádat o další služby CMS – viz kapitola 4 Závislosti služeb CMS 2.0. Varianty služby:\ - 1. Celé CMS\ - 2. Extranet CMS – viz služba CMS2-12-2 \|	+	\| Varianty a stav \| CMS2-01-1 Celé CMS – v provozu \\ CMS2-01-2 Extranet CMS – v provozu (viz služba CMS2-12-2) \|
		+	\| Popis služby \| Služba je procesním nástrojem pro akceptaci provozních podmínek systému CMS novými uživateli. Bez akceptace provozních podmínek nelze žádat o další služby CMS, viz [[#zavislosti_sluzeb_cms_20\|Závislosti služeb CMS 2.0]]. \|

-	Akceptaci provozních podmínek CMS (CMS2-01-1) musí provést oprávněná osoba Subjektu (OVM) prostřednictvím datové schránky. Aktualizaci provozních podmínek CMS bude možné akceptovat prostřednictvím Portálu CMS. Při akceptaci Vám bude zřízena tzv. GOV položka s pořadovým číslem ve tvaru GOVxxxxxx, kde x je pořadové číslo. GOV položka slouží jako jednoznačný identifikátor služby daného Subjektu, kterým můžete nahlašovat změny, poruchy či rušení služby. Akceptováním provozních podmínek CMS a vytvořením GOV položky získáváte přístup na Portál CMS.	+	Akceptaci provozních podmínek CMS (CMS2-01-1) musí provést oprávněná osoba Subjektu (OVM) prostřednictvím datové schránky. Aktualizaci provozních podmínek bude možné akceptovat prostřednictvím Portálu CMS. Při akceptaci je zřízena tzv. GOV položka s pořadovým číslem ve tvaru GOVxxxxxx. GOV položka slouží jako jednoznačný identifikátor služby daného Subjektu, kterým lze nahlašovat změny, poruchy či rušení služby. Akceptováním provozních podmínek a vytvořením GOV položky Subjekt získává přístup na Portál CMS na adrese [[https://www.cms2.cz/\|https://www.cms2.cz/]], dostupný pouze z prostředí CMS (zadáním adresy z Internetu se uživatel dostane na web Ministerstva vnitra). O zřízení služby je Subjekt informován e-mailem.

-	Akceptace provozních podmínek Extranetu CMS (CMS2-01-2) – oprávněná osoba Subjektu Extranetu zašle „Žádost o přístup do Extranetu“ do datové schránky správce CMS. Po schválení žádosti Správcem CMS je žádost postoupena provozovateli CMS, který vystavuje předávací protokol k danému Extranetu.	+	Akceptace provozních podmínek Extranetu CMS (CMS2-01-2) – oprávněná osoba Subjektu Extranetu zašle „Žádost o přístup do Extranetu“ do datové schránky správce CMS. Po schválení žádosti správcem CMS je žádost postoupena provozovateli CMS, který vystavuje předávací protokol k danému Extranetu. V protokolu jsou informace o operátorech, přes které je možné se k Extranetu připojit, a technické parametry realizace připojení.

	=== Služba CMS2 – 02 – Zveřejnění aplikace ===		=== Služba CMS2 – 02 – Zveřejnění aplikace ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-02 \|		\| Kód služby \| CMS2-02 \|
	\| Název služby \| Zveřejnění aplikace \|		\| Název služby \| Zveřejnění aplikace \|
-	\| Popis služby \| Služba vytvoří prostředí pro publikaci aplikační služby informačního systému OVM. Službu lze zřídit do následujících prostředí:\ - 1) do sítě CMS\ - 2) do sítě Internet\ - a) zveřejnění IPsec koncentrátoru Subjektu\ - 3) do sítě TESTA-ng\ - 4) do Extranetu \|	+	\| Varianty a stav \| CMS2-02-1 Zveřejnění aplikace – v provozu \|
		+	\| Popis služby \| Služba vytvoří prostředí pro publikaci aplikační služby informačního systému OVM. Službu lze zřídit do prostředí: \\ 1) sítě CMS \\ 2) sítě Internet, včetně zveřejnění IPsec koncentrátoru Subjektu \\ 3) sítě TESTA-ng \\ 4) Extranetu \|

-	Aplikační služba může být umístěna v infrastruktuře OVM nebo v infrastruktuře Národního datového centra (NDC). Aplikační služba může být zveřejněna do více prostředí současně. Nejdříve je aplikace publikována do sítě CMS.	+	Aplikační služba může být umístěna v infrastruktuře OVM nebo v infrastruktuře Národního datového centra (NDC). Může být zveřejněna do více prostředí současně a je zveřejněna na definovaných protokolech a portech.
		+
		+	Nejdříve je aplikace publikována do sítě CMS. Aplikaci jsou přiděleny privátní IP adresy z prostoru CMS (konsolidované IP adresy). Službu lze zveřejnit pro všechny ostatní Subjekty připojené do sítě CMS (služba s otevřeným přístupem), pro definované Subjekty či skupiny Subjektů (schvalovaná služba), nebo přístup z CMS zakázat. O přístup ke schvalované službě žádají přistupující Subjekty službou CMS2-03-1.
		+
		+	Při zveřejnění aplikace do sítě Internet jsou aplikaci přiděleny veřejné IP adresy z prostoru CMS. Přístup ke zveřejněné službě může být omezen na definované zdrojové IP adresy.
		+
		+	Při zveřejnění IPsec koncentrátoru Subjektu do sítě Internet je nad rámec standardního zveřejnění umožněn i provoz opačným směrem s využitím statického NATu.
		+
		+	Při zveřejnění aplikace do sítě TESTA-ng jsou aplikaci přiděleny IP adresy z prostoru pro ČR v síti TESTA-ng. Přístup je omezen na definované zdrojové IP adresy. Zveřejnění musí být provozováno v souladu s provozními a bezpečnostními požadavky EU pro síť TESTA-ng.
		+
		+	Při zveřejnění aplikace do Extranetu jsou aplikaci přiděleny privátní IP adresy z prostoru CMS (konsolidované IP adresy). Aplikační služba je zveřejněna do existujícího Extranetu, který vytváří správce CMS. Přístup k aplikaci v Extranetu mají všichni uživatelé s přístupem do daného Extranetu.

	=== Služba CMS2 – 03 – Přístup k aplikaci ===		=== Služba CMS2 – 03 – Přístup k aplikaci ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-03 \|		\| Kód služby \| CMS2-03 \|
	\| Název služby \| Přístup k aplikaci \|		\| Název služby \| Přístup k aplikaci \|
-	\| Popis služby \| Služba umožňuje zřizovat a rušit přístupy k aplikačním službám. Varianty služby se liší podle cílového prostředí:\ - 1. k aplikaci v síti CMS\ - 2. k aplikaci v síti TESTA-ng\ - 3. k aplikaci v síti Internet \|	+	\| Varianty a stav \| CMS2-03-1 k aplikaci v síti CMS – v provozu \\ CMS2-03-2 k aplikaci v síti TESTA-ng – v provozu \\ CMS2-03-3 k aplikaci v síti Internet – v provozu \|
		+	\| Popis služby \| Služba umožňuje zřizovat, měnit a rušit přístupy k aplikačním službám. Varianty se liší cílovým prostředím. \|

-	Přístup k aplikaci v síti CMS (CMS2-03-1) umožní Subjektu připojení k aplikační službě zveřejněné jiným Subjektem v síti CMS.	+	Jednou žádostí lze zřídit přístup právě k jedné aplikační službě. Připojení je povoleno z definovaných IP adres v síti Subjektu.

-	Přístup k aplikaci v síti TESTA-ng** (CMS2-03-2) umožní Subjektu připojení k aplikační službě zveřejněné jiným státem EU**.	+	Přístup k aplikaci v síti CMS** (CMS2-03-1) umožní Subjektu připojení k aplikační službě zveřejněné jiným Subjektem službou CMS2-02-1. Zřízení přístupu je podmíněno souhlasem vlastníka zveřejněné aplikační služby, který probíhá prostřednictvím Portálu CMS**.

-	Přístup k aplikaci v síti Internet (CMS2-03-3) umožní Subjektu připojení k aplikační službě zveřejněné v síti Internet.	+	Přístup k aplikaci v síti TESTA-ng (CMS2-03-2) umožní Subjektu připojení k aplikační službě zveřejněné jiným státem Evropské unie v síti TESTA-ng. Připojení je povoleno na definovaných protokolech a portech a musí být provozováno v souladu s provozními a bezpečnostními požadavky EU pro síť TESTA-ng.
		+
		+	Přístup k aplikaci v síti Internet (CMS2-03-3) umožní Subjektu připojení k aplikační službě zveřejněné v síti Internet na definovaných protokolech a portech. Cílovou aplikační službu je nutné definovat konkrétními IP adresami, protokoly a porty.

	=== Služba CMS2 – 04 – Publikace AIS na eGSB ===		=== Služba CMS2 – 04 – Publikace AIS na eGSB ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
-	\| Kód služby \| CMS2-04 Služba ukončena a nahrazena aplikací ISSS \|	+	\| Kód služby \| CMS2-04 \|
	\| Název služby \| Publikace AIS na eGSB \|		\| Název služby \| Publikace AIS na eGSB \|
-	\| Popis služby \| Služba zajišťuje zpřístupnění publikačního agendového informačního systému (AIS) v rámci CMS a povolení síťové komunikace s rozhraním eGON Service Bus (eGSB). \|	+	\| Varianty a stav \| CMS2-04-1 – ukončena k verzi katalogu 2.8.0 (11. 3. 2025), nahrazena [[nap:isss\|Informačním systémem sdílené služby (ISSS)]] \|
		+	\| Popis služby \| Služba zajišťovala zpřístupnění publikačního agendového informačního systému (AIS) v rámci CMS a povolení síťové komunikace s rozhraním eGON Service Bus (eGSB). \|
		+
		+	Služba zajišťovala provozovateli publikačního AIS síťovou konektivitu mezi eGSB a publikačním AIS na definovaných protokolech a portech; v rámci publikace byly přiděleny privátní IP adresy z prostoru CMS (konsolidované IP adresy). Ve výchozím stavu byla komunikace mezi eGSB a publikačním AIS synchronní, volitelně bylo možné zprovoznit komunikaci asynchronní.

	=== Služba CMS2 – 05 – Přenos elektronické pošty ===		=== Služba CMS2 – 05 – Přenos elektronické pošty ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-05 \|		\| Kód služby \| CMS2-05 \|
	\| Název služby \| Přenos elektronické pošty \|		\| Název služby \| Přenos elektronické pošty \|
-	\| Popis služby \| Služba MTA zajišťuje předávání zpráv elektronické pošty mezi Subjekty KIVS a sítí Internet. Varianty služby:\ - Odchozí SMTP Službu již není možné nově objednat\ - Příchozí SMTP Službu již není možné nově objednat\ - Server elektronické pošty \|	+	\| Varianty a stav \| CMS2-05-1 Odchozí SMTP provoz – v provozu \\ CMS2-05-2 Příchozí SMTP provoz – v provozu \\ CMS2-05-3 Server elektronické pošty – v provozu \|
		+	\| Popis služby \| Služba MTA zajišťuje předávání zpráv elektronické pošty jak mezi jednotlivými Subjekty KIVS, tak mezi Subjekty KIVS a uživateli sítě Internet. \|
		+
		+	V principu jde o službu Mail Transfer Agent (MTA) – zajišťuje předávání zpráv mezi mailovými servery a zároveň plní bezpečnostní funkce antiviru a antispamu. Varianta Odchozí SMTP provoz (CMS2-05-1) zajišťuje odesílání elektronické pošty ze serveru Subjektu, varianta Příchozí SMTP provoz (CMS2-05-2) přijímání elektronické pošty na server Subjektu; obě varianty lze objednat současně. Subjektu může být zřízena pouze jedna instance této služby.
		+
		+	Předávání elektronické pošty lze realizovat v rámci prostředí KIVS nebo do a z prostředí sítě Internet. Služba nezahrnuje poštovní schránky a není určena k přeposílání zpráv v rámci jednoho Subjektu.
		+
		+	Varianta Server elektronické pošty (CMS2-05-3) zajišťuje odesílání a přijímání zpráv v definovaných e-mailových doménách, nastavení e-mailových politik, zpracování zpráv ve frontě a směrování pošty v rámci e-mailových domén Subjektu i mimo ně. Hlavním cílem je odesílání elektronické pošty pro systémy a aplikace, které nedisponují vlastním e-mailovým serverem. Služba neumožňuje funkcionalitu e-mailových schránek.

	=== Služba CMS2 – 06 – DNS hosting ===		=== Služba CMS2 – 06 – DNS hosting ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-06 \|		\| Kód služby \| CMS2-06 \|
	\| Název služby \| DNS hosting \|		\| Název služby \| DNS hosting \|
-	\| Popis služby \| Služba zajišťuje vedení DNS záznamů na jmenných serverech CMS. Varianty:\ - Veřejná registrovaná doména\ - Veřejná doména CMS Služba ukončena****\ - Neveřejná doména\ - Distribuce domény do KIVS **Služba ukončena**\ - Hosting domény do KIVS **Služba ukončena \|**	+	\| Varianty a stav \| CMS2-06-1 Veřejná registrovaná doména do Internetu – v provozu \\ CMS2-06-2 Veřejná doména CMS – v provozu \\ CMS2-06-3 Neveřejná doména – v provozu \\ CMS2-06-4 Distribuce veřejně registrované domény do KIVS – ukončena \\ CMS2-06-5 Hosting veřejně registrované domény do KIVS – ukončena \|
		+	\| Popis služby \| Služba zajišťuje vedení DNS záznamů na jmenných serverech CMS. \|
		+
		+	Služba Veřejná registrovaná doména do Internetu (CMS2-06-1) zajišťuje poskytování jmenných služeb (DNS) do sítě Internet pro domény ve vlastnictví Subjektu, veřejně registrované v síti Internet. Subjekt musí zabezpečit nasměrování domény na jmenné servery CMS. Služba nezajišťuje vlastní registraci domény. Volitelně lze doménu zabezpečit pomocí DNSSEC.
		+
		+	Služba Veřejná doména CMS (CMS2-06-2) zajišťuje poskytování jmenných služeb (DNS) do sítě Internet pro domény vyššího řádu v doméně „gov.cz“.
		+
		+	Služba Neveřejná doména (CMS2-06-3) zajišťuje poskytování jmenných služeb (DNS) do sítě CMS pro záznamy v interní doméně sítě CMS „cms2.cz“.
		+
		+	Služby Distribuce veřejně registrované domény do KIVS (CMS2-06-4) a Hosting veřejně registrované domény do KIVS (CMS2-06-5) zajišťovaly poskytování jmenných služeb do prostředí KIVS/CMS pro veřejně registrované domény ve vlastnictví Subjektu. Obě služby jsou ukončeny.

	=== Služba CMS2 – 07 – Služby TESTA-ng ===		=== Služba CMS2 – 07 – Služby TESTA-ng ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-07 \|		\| Kód služby \| CMS2-07 \|
	\| Název služby \| Služby TESTA-ng \|		\| Název služby \| Služby TESTA-ng \|
		+	\| Varianty a stav \| CMS2-07-1 – v provozu, bez garance dostupnosti (SLA N/A) \|
	\| Popis služby \| Služba umožňuje nastavení doplňkových služeb v síti Evropské unie TESTA-ng. \|		\| Popis služby \| Služba umožňuje nastavení doplňkových služeb v síti Evropské unie TESTA-ng. \|
		+
		+	Jde především o správu DNS záznamů v zóně „cz.testa.eu“ či změnu nastavení směrování elektronické pošty v rámci sítě TESTA-ng. Požadavky Subjektu jsou zpracovány a následně uplatněny u provozovatele sítě TESTA-ng. Změna nastavení služeb musí být v souladu s provozními a bezpečnostními požadavky EU pro síť TESTA-ng.

	=== Služba CMS2 – 08 – Přístup do CMS ===		=== Služba CMS2 – 08 – Přístup do CMS ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-08 \|		\| Kód služby \| CMS2-08 \|
	\| Název služby \| Přístup do CMS \|		\| Název služby \| Přístup do CMS \|
-	\| Popis služby \| Služba je určena pro připojení počítačových sítí OVM k síti CMS. Varianty služby:\ - Přístup do CMS přes KIVS **již není možné nově objednat**\ - Přístup do CMS přes IPsec\ - Přístup do CMS přes SSL\ - Přístup do CMS z NDC\ - Přístup technických pracovníků přes SSL\ - Přístup do CMS přes KIVS (CMS2.5) \|	+	\| Varianty a stav \| CMS2-08-1 přes KIVS – v provozu \\ CMS2-08-2 přes IPsec – v provozu (SLA N/A) \\ CMS2-08-3 přes SSL – v provozu (SLA N/A) \\ CMS2-08-4 z NDC – v provozu \\ CMS2-08-5 přístup technických pracovníků přes SSL – v provozu (SLA N/A) \|
		+	\| Popis služby \| Služba je určena pro připojení počítačových sítí OVM k síti CMS a vytvoření tzv. připojovací sítě. \|
		+
		+	Přístup do CMS přes KIVS (CMS2-08-1) – připojení koncové lokality nebo více lokalit prostřednictvím MPLS sítě telekomunikačního operátora, a to jak prostřednictvím centrálních připojovacích míst, tak prostřednictvím krajských konektorů. Varianta je určena pro lokality, ve kterých sídlí řádově alespoň desítky uživatelů, resp. počítačů připojených k síti.
		+
		+	Přístup do CMS přes IPsec (CMS2-08-2) – připojení koncové lokality pomocí šifrovaného spojení přes síť Internet. K zabezpečení komunikace mohou být využívány certifikáty vydávané neveřejnou certifikační autoritou CMS. Varianta je vhodná pro lokality, ve kterých sídlí do 25 uživatelů, resp. počítačů připojených k síti. Služba je poskytována bez garance dostupnosti, viz upozornění v kapitole [[#ipsec_a_jeho_uskali\|IPsec a jeho úskalí]].
		+
		+	Přístup do CMS přes SSL (CMS2-08-3) – uživatelské připojení pomocí šifrovaného spojení přes síť Internet prostřednictvím VPN klienta instalovaného na každém připojovaném počítači. Varianta je určena pro připojení jednotlivých počítačů. Koncoví uživatelé se autentizují uživatelským účtem v JIP/KAAS.
		+
		+	Přístup do CMS z NDC (CMS2-08-4) – připojení infrastruktury umístěné v Národním datovém centru do sítě CMS. Připojení je realizováno přes hraniční prvky CMS umístěné v Národních datových centrech.
		+
		+	Přístup technických pracovníků do CMS přes SSL (CMS2-08-5) – uživatelské připojení pomocí šifrovaného SSL spojení přes síť Internet prostřednictvím VPN klienta instalovaného na každém připojovaném počítači. Varianta je určena pro technické pracovníky Subjektu nebo jeho externí dodavatele. Ověření uživatelů probíhá v interním adresáři CMS, jehož součástí je i rozhraní pro správu uživatelů.

	=== Služba CMS2 – 09 – Přístup do Internetu ===		=== Služba CMS2 – 09 – Přístup do Internetu ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-09 \|		\| Kód služby \| CMS2-09 \|
	\| Název služby \| Přístup do Internetu \|		\| Název služby \| Přístup do Internetu \|
-	\| Popis služby \| Služba zajistí přístup Subjektu do sítě Internet. Varianty:\ - Přímé připojení\ - Bezpečné připojení \|	+	\| Varianty a stav \| CMS2-09-1 Přímé připojení – v provozu \\ CMS2-09-2 Bezpečné připojení – v provozu \|
		+	\| Popis služby \| Služba zajistí přístup Subjektu do sítě Internet prostřednictvím zřízené přípojky do CMS. Varianty se liší požadovanou úrovní zabezpečení. Služba neslouží k zajištění přístupu ke službám CMS. \|
		+
		+	Ve variantě přímého připojení (CMS2-09-1) není mezi síť OVM a Internet vkládán jakýkoli bezpečnostní prvek. OVM je přidělena veřejná IP adresa z rozsahu CMS. Službu lze poskytnout prostřednictvím připojení KIVS operátora, krajských konektorů nebo připojení v NDC. Přípojku využívanou pro tuto variantu nelze využít v kombinaci s jinými službami CMS. Každý Subjekt může mít zřízenu maximálně jednu službu Přímého připojení u každého KIVS operátora a maximálně jednu v každém NDC.
		+
		+	Ve variantě Bezpečného připojení (CMS2-09-2) je síťový provoz kontrolován a překládán. Varianta umožňuje využít protokoly HTTP, HTTPS a FTPoHTTP. Služba neslouží k přístupu na zákaznické kamerové systémy a jiné jednoúčelové aplikace na nestandardních portech; k tomuto účelu slouží služba CMS2-03-3 Přístup k aplikaci v síti Internet.

	=== Služba CMS2 – 10 – Přístup k záznamům o provozu ===		=== Služba CMS2 – 10 – Přístup k záznamům o provozu ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-10 \|		\| Kód služby \| CMS2-10 \|
	\| Název služby \| Přístup k záznamům o provozu \|		\| Název služby \| Přístup k záznamům o provozu \|
		+	\| Varianty a stav \| CMS2-10-1 – nerealizovaná, službu není možné objednat \|
	\| Popis služby \| Přístup OVM k provozním statistikám jeho služeb včetně údajů o plnění SLA. \|		\| Popis služby \| Přístup OVM k provozním statistikám jeho služeb včetně údajů o plnění SLA. \|
		+
		+	Služba má zahrnovat přístup OVM k provozním statistikám a záznamům o provozu jím objednaných služeb včetně údajů o plnění SLA a výsledků monitoringu linek, na kterých jsou tyto služby provozovány. Přístup má být OVM umožněn přes Portál CMS. Dle katalogu služeb ve verzi 2.8.0 je služba ve stavu //nerealizovaná//.

	=== Služba CMS2 – 11 – Přístup k účtovacím informacím ===		=== Služba CMS2 – 11 – Přístup k účtovacím informacím ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-11 \|		\| Kód služby \| CMS2-11 \|
	\| Název služby \| Přístup k účtovacím informacím \|		\| Název služby \| Přístup k účtovacím informacím \|
-	\| Popis služby \| Přístup OVM k vlastním účtovacím informacím přes portál CMS. \|	+	\| Varianty a stav \| CMS2-11-1 – nerealizovaná, službu není možné objednat \|
		+	\| Popis služby \| Přístup OVM k vlastním účtovacím informacím přes Portál CMS. \|
		+
		+	Dle katalogu služeb ve verzi 2.8.0 je služba ve stavu //nerealizovaná//.

	=== Služba CMS2 – 12 – Propojovací bod ===		=== Služba CMS2 – 12 – Propojovací bod ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-12 \|		\| Kód služby \| CMS2-12 \|
	\| Název služby \| Propojovací bod \|		\| Název služby \| Propojovací bod \|
-	\| Popis služby \| Služba zajišťuje zřízení propojovacího bodu v infrastruktuře CMS (virtuální firewall). Varianty:\ - Propojovací bod Subjektu již není možné nově objednat****\ - Propojovací bod pro Extranet již není možné nově objednat****\ - Propojovací bod pro Extranet CMS2.5 \|	+	\| Varianty a stav \| CMS2-12-1 Propojovací bod Subjektu – v provozu \\ CMS2-12-2 Propojovací bod pro Extranet – v provozu (do provozu převeden verzí katalogu 2.8.0) \|
		+	\| Popis služby \| Služba zajišťuje zřízení propojovacího bodu v infrastruktuře CMS, technicky realizovaného jako virtuální firewall. Na tomto bodu jsou zakončeny jednotlivé přípojky a zveřejňovány služby. Bez propojovacího bodu není možné poskytovat některé další služby CMS. \|
		+
		+	V rámci služby Propojovací bod je automaticky zřízen přístup k následujícím službám:
		+
		+	* Portál CMS (pouze přes Propojovací bod Subjektu, CMS2-12-1)
		+	* DNS služba CMS
		+	* NTP služba CMS
		+	* Služby s otevřeným přístupem v prostředí CMS (pouze přes Propojovací bod Subjektu)
		+	* Čtenář eGON Service Bus (eGSB, ISSS)
		+
		+	Služba Propojovací bod Subjektu** (CMS2-12-1) zajišťuje zřízení virtuálního firewallu v infrastruktuře CMS pro jednotlivá OVM. Na tomto bodu jsou zakončovány jednotlivé VPN. V rámci zřízení služby je Subjektu vyhrazena část rozsahu privátních IP adres CMS (konsolidovaný adresní rozsah). Jde o překladové IP adresy, pod kterými Subjekt přistupuje k ostatním službám v CMS a které zároveň používá při publikaci svých služeb. Každý Subjekt může mít zřízenu maximálně jednu službu Propojovací bod Subjektu.**
		+
		+	Služba Propojovací bod pro Extranet (CMS2-12-2) slouží jako nástroj správce CMS k definici Extranetu. Správce CMS v Extranetu definuje Subjekty Extranetu na základě parametrů z RPP. Subjekty Extranetu žádají o přístup do Extranetu službou CMS2-01-2. Do Extranetu se publikují aplikační služby určené pro stejný okruh OVM a SPUÚ.
		+
		+	Přistupující Subjekt Extranetu může využívat služby nejvýše jednoho Extranetu. Subjekty Extranetu nemohou v Extranetu publikovat žádné aplikace. Služba Extranetu není určena pro Subjekty registrované v CMS službou CMS2-01-1. Zveřejnění aplikací do daného Extranetu probíhá na základě žádosti publikujících Subjektů prostřednictvím služby CMS2-02-1.
		+
		+	=== Služba CMS2 – 13 – Testovací procedury ===

-	=== Služba CMS2 – 13 – Testovací procedury ===
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-13 \|		\| Kód služby \| CMS2-13 \|
	\| Název služby \| Testovací procedury \|		\| Název služby \| Testovací procedury \|
-	\| Popis služby \| Služba zajišťuje možnost testování služeb CMS před uvedením do produkce. \|	+	\| Varianty a stav \| CMS2-13-1 Testování publikace aplikace – v provozu \\ CMS2-13-2 Testování distribuce veřejně registrované domény do KIVS – v provozu \\ CMS2-13-3 Testování hostingu veřejně registrované domény do KIVS – v provozu \|
		+	\| Popis služby \| Služba zajišťuje možnost testování jednotlivých služeb před uvedením do produkce. Bez otestování služby není možné poskytovat některé další služby CMS. \|
		+
		+	Služba Testování publikace aplikace (CMS2-13-1) umožní otestovat chování aplikace zveřejněné do CMS službou CMS2-02-1. Je určena pro Subjekt, který danou aplikaci do CMS zveřejňuje, a simuluje standardní přístup Subjektu ke zveřejněné aplikaci. Pro testovací rozhraní je použit vzdálený přístup ze sítě Internet přes SSL VPN zakončenou na virtuálním firewallu v CMS. Testeři se do testovací SSL VPN autentizují uživatelským účtem v JIP/KAAS.
		+
		+	Služba Testování distribuce veřejně registrované domény do KIVS (CMS2-13-2) zajišťuje otestování distribuce veřejně registrované domény Subjektu na testovací jmenné servery CMS a otestování funkčnosti v prostředí KIVS/CMS. Subjekt distribuuje doménu z vlastního DNS serveru na testovací jmenné servery CMS. Služba nezajišťuje vlastní registraci domény.
		+
		+	Služba Testování hostingu veřejně registrované domény do KIVS (CMS2-13-3) zajišťuje otestování hostingu veřejně registrované domény Subjektu na testovacích jmenných serverech CMS a otestování funkčnosti v prostředí KIVS/CMS. Doména je vedena na testovacích jmenných serverech CMS na základě podkladů od Subjektu. Služba nezajišťuje vlastní registraci domény.
		+
		+	Poznámka: služby CMS2-13-2 a CMS2-13-3 jsou v katalogu vedeny jako //v provozu//, přestože odpovídající produkční služby CMS2-06-4 a CMS2-06-5 jsou ukončeny. Stav je třeba ověřit u správce CMS.

	=== Služba CMS2 – 14 – Aktualizační služby ===		=== Služba CMS2 – 14 – Aktualizační služby ===
		+
	^ Název parametru ^ Vysvětlení ^		^ Název parametru ^ Vysvětlení ^
	\| Kód služby \| CMS2-14 \|		\| Kód služby \| CMS2-14 \|
	\| Název služby \| Aktualizační služby \|		\| Název služby \| Aktualizační služby \|
-	\| Popis služby \| Služba zajistí přístup Subjektu k aktualizačním službám CMS. \|	+	\| Varianty a stav \| CMS2-14-1 MS WSUS – Aktualizační služba WSUS – v provozu (SLA N/A) \|
		+	\| Popis služby \| Služba zajistí přístup Subjektu k aktualizačním službám CMS. Cílem služby je poskytovat aktualizace podporovaných produktů. \|
		+
		+	Služba MS WSUS (CMS2-14-1) zajistí přístup Subjektu k serveru Microsoft Windows Update ležícímu v CMS prostřednictvím zřízené přípojky do CMS. Jde zejména o produkty Windows, Office, Windows Server, SQL Server a System Center.
		+
		+	Služba neslouží jako přístup do internetu ani jako proxy server s bezpečným internetem. Lze ji využít pouze jako zdroj aktualizací pro vlastní WSUS server.
		+
		+	=== Závislosti služeb CMS 2.0 ===
		+
		+	Služby CMS na sebe navazují hierarchicky. Nejprve je nutné akceptovat provozní podmínky CMS službou CMS2-01-1; teprve poté lze objednávat další služby. Vždy musí být zřízena služba v hierarchii výše, která je nutnou podmínkou pro zřízení služeb závislých.
		+
		+	* CMS2-01-1 Akceptace provozních podmínek CMS – vstupní podmínka pro všechny ostatní služby
		+	* Zřízení připojovací sítě – alespoň jedna služba z rodiny CMS2-08 (KIVS, IPsec, SSL, NDC, přístup technických pracovníků)
		+	* CMS2-12-1 Propojovací bod Subjektu – podmínka pro zveřejňování a přístup k aplikacím
		+	* CMS2-02-1 Zveřejnění aplikace, na kterou navazuje CMS2-13-1 Testování publikace aplikace
		+	* CMS2-03-1 až CMS2-03-3 Přístup k aplikaci v sítích CMS, TESTA-ng a Internet
		+	* CMS2-05-1 až CMS2-05-3 Přenos elektronické pošty
		+	* CMS2-06-1 až CMS2-06-3 DNS hosting
		+	* CMS2-07-1 Služby TESTA-ng
		+	* CMS2-09-2 Bezpečný přístup do Internetu
		+	* CMS2-14-1 Aktualizační služby
		+	* CMS2-09-1 Přímý přístup do Internetu (samostatná přípojka, nelze kombinovat s jinými službami CMS)
		+	* CMS2-10-1 a CMS2-11-1 – podpůrné služby Portálu CMS (nerealizovány)
		+	* CMS2-12-2 Propojovací bod pro Extranet zřizuje správce CMS; Subjekty Extranetu žádají o přístup službou CMS2-01-2
		+
		+	Přístup k aplikaci v síti CMS (CMS2-03-1) je navíc podmíněn tím, že cílovou aplikaci zveřejnilo jiné OVM službou CMS2-02-1. Úplné schéma závislostí je v kapitole 4 dokumentu [[https://mv.gov.cz/soubor/prehled-sluzeb-cms.aspx\|Přehled služeb CMS]].
		+
		+	=== Výklad pojmů a zkratek ===
		+
		+	^ Pojem/zkratka ^ Popis ^
		+	\| AIS \| Agendový informační systém \|
		+	\| BE \| Doba obnovy je bezodkladně \|
		+	\| CMS \| Centrální místo služeb \|
		+	\| DNS \| Domain Name System \|
		+	\| eGSB \| eGON Service Bus \|
		+	\| IPsec \| Internet Protocol Security \|
		+	\| KIVS \| Komunikační infrastruktura veřejné správy \|
		+	\| N/A \| Dostupnost služby bez garance \|
		+	\| NDC \| Národní datové centrum \|
		+	\| OVM \| Orgán veřejné moci \|
		+	\| SMTP \| Simple Mail Transfer Protocol \|
		+	\| SPUÚ \| Soukromoprávní uživatel údajů \|
		+	\| SSL \| Secure Socket Layer \|
		+	\| TESTA-ng \| (Secure) Trans European Services for Telematics between Administrations – privátní síť propojující jednotlivé státy EU, dříve sTESTA \|
		+	\| VPN \| Virtual Private Network \|
		+
		+	=== Služby související s migrací do CMS2.5 ===
		+
		+	//Následující služby nejsou uvedeny v katalogu Přehled služeb CMS ve verzi 2.8.0. Jde o informace správce CMS nad rámec katalogu; před použitím doporučujeme ověřit u správce CMS. Doplnit zdroj a datum.//
		+
		+	Přístup do CMS přes KIVS – CMS2.5 (CMS2-08-6) vzniká jako náhrada služby CMS2-08-1 tak, aby Subjekty nemusely po přechodu do CMS2.5 měnit konfiguraci. Jde o připojení koncové lokality nebo více lokalit prostřednictvím MPLS sítě telekomunikačního operátora, jak prostřednictvím centrálních připojovacích míst, tak prostřednictvím krajských konektorů. Varianta je určena pro lokality, ve kterých sídlí řádově alespoň desítky uživatelů, resp. počítačů připojených k síti.
		+
		+	Propojovací bod pro Extranet CMS2.5 (CMS2-12-4) vznikl jako náhrada služby CMS2-12-2 z důvodu plánované migrace do CMS2.5, zejména aby se předešlo nutnosti změn v konfiguraci na straně Subjektů. Správce CMS v Extranetu definuje Subjekty Extranetu na základě parametrů z RPP. Subjekty Extranetu žádají o přístup do Extranetu CMS2.5 službou CMS2-01-1. Do Extranetu CMS2.5 se publikují aplikační služby určené pro stejný okruh OVM a SPUÚ. Přistupující Subjekt Extranetu CMS2.5 může využívat služby jako standardní Subjekt CMS. Služba Extranetu CMS2.5 je určena pro Subjekty registrované v CMS službou CMS2-01-1.

		+	//K ověření: číslování služby CMS2-12-4 přeskakuje neexistující kód CMS2-12-3. Dále je třeba doložit, od kdy a na základě čeho není možné nově objednat služby CMS2-08-1 a CMS2-12-1/CMS2-12-2, které katalog ve verzi 2.8.0 vede jako v provozu.//

	==== Právní aspekty ====		==== Právní aspekty ====

eGovernment cloud

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-09-18T13:16:31+00:00

2024/07/17 13:29		aktuální
Řádek 71:		Řádek 71:
	==== Katalog cloud computingu ====		==== Katalog cloud computingu ====

-	{{page>nap:katalog_cloud}}	+	{{page>reporty:katalog_cloud}}

	===== Pravidla eGovernment cloudu =====		===== Pravidla eGovernment cloudu =====
Řádek 105:		Řádek 105:
	==== Povinnosti komerčních poskytovatelů služeb eGC ====		==== Povinnosti komerčních poskytovatelů služeb eGC ====

-	Konkrétní povinnosti stanoví zákon o informačních systémech veřejné správy a na základě tohoto zákona pak vydané vyhlášky ministerstva a NÚKIB. Řídící orgán eGovernment Cloudu pak na základě zákona a vyhlášek připravuje a vydává metodické pokyny. Již nyní však platí pravidla pro nutnost připojení skrze infrastrukturu [[nap:komunikacni_infrastruktura_verejne_spravy\|CMS/KIVS]] a tím i respektování {{:dokumenty:katalogovy_list_sluzby_cms2-08-2_v2-0-5.pdf\|katalogového listu služby připojení přes IPSec}}	+	Konkrétní povinnosti stanoví zákon o informačních systémech veřejné správy a na základě tohoto zákona pak vydané vyhlášky ministerstva a NÚKIB. Řídící orgán eGovernment Cloudu pak na základě zákona a vyhlášek připravuje a vydává metodické pokyny. Již nyní však platí pravidla pro nutnost připojení skrze infrastrukturu [[nap:komunikacni_infrastruktura_verejne_spravy\|CMS/KIVS]] a tím i respektování katalogového listu služby připojení přes IPSec.

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

Identita fyzické osoby mimo registr obyvatel - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-09-18T12:31:21+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== Identita fyzické osoby mimo registr obyvatel ======
	+
	+	Tato stránka popisuje, jak se v propojeném datovém fondu (PPDF) pracuje s fyzickou osobou, která není vedena v registru obyvatel (ROB), a jaká pravidla z toho plynou pro architekty agendových informačních systémů — zejména pro resorty, které si zavádějí vlastní resortní identifikátor osoby, a pro čtenáře jejich údajů.
	+
	+	Stránka je psána jako popis stávajícího stavu a doporučených postupů. Kapitola „Uvažovaný směr řešení“ popisuje záměr, o kterém dosud nebylo rozhodnuto, a je jako záměr výslovně označena.
	+
	+	===== 1. Proč to řešit =====
	+
	+	Řada agend vede osoby, které nejsou a nebudou subjektem údajů registru obyvatel podle § 17 písm. a) až d) zákona č. 111/2009 Sb., o základních registrech — cizince bez pobytového statusu, přeshraniční pracovníky a jejich rodinné příslušníky, samoplátce nebo osoby ošetřené jednorázově. Zákon s nimi počítá v § 17 písm. e) („jiné fyzické osoby, u nichž to vyžaduje jiný právní předpis“), ale evidence jiných fyzických osob (EJFO) nebyla uvedena do provozu.
	+
	+	Takové osobě dnes nemá kdo vydat AIFO. Bez AIFO nefunguje nic z PPDF: ani čtení údajů přes ISSS, ani vyrozumívání o změnách, ani předávání údajů mezi agendami. Resort proto typicky sáhne po vlastním identifikátoru a k němu si postaví vlastní ztotožňovací a notifikační mechanismus.
	+
	+	Není to ojedinělá situace. Vlastní bezvýznamový identifikátor osoby zavádí:
	+
	+	* RID — resortní identifikátor pacienta v kmenovém registru pacientů podle zákona č. 325/2021 Sb., o elektronizaci zdravotnictví;
	+	* OIČ — osobní identifikační číslo podle zákona č. 323/2025 Sb., o jednotném měsíčním hlášení zaměstnavatele.
	+
	+	Struktura problému je v obou případech stejná a bude se opakovat u každého dalšího resortu, který povede osoby mimo ROB.
	+
	+	===== 2. Co konkrétně selže =====
	+
	+	^ Krok ^ Chování dnes ^
	+	\| Ztotožnění podle údajů (jméno, datum narození…) \| Je k dispozici pouze nad ROB a AISC (E278 robCtiPodleUdaju2, E174 aiscCtiPodleUdaju2). Nad publikovanými kontexty ISSS vyhledání podle údajů neexistuje — ISSS se dotazuje výhradně podle AIFO nebo IČO. \|
	+	\| Čtení údajů z cizího AIS (G1 gsbCtiData) \| Entity zadané na vstupu musí existovat, jinak je volání zamítnuto; ověření existence AIFO a překlad mezi agendami se navíc zaznamenávají v ROB jako využití údajů. Pro osobu bez záznamu v ROB tedy neprojde ani volání, ani jeho auditní zaznamenání. \|
	+	\| Vyrozumívání o změnách \| Bez AIFO nelze subjekt přihlásit k vyrozumívání v AISV (E315). \|
	+
	+	Praktickým důsledkem je bilaterální integrace: každý čtenář se s každým publikátorem domlouvá zvlášť, tedy //n × m// rozhraní místo //n + m//, a to opakovaně při každé změně.
	+
	+	===== 3. Co v PPDF s identitou mimo ROB funguje už dnes =====
	+
	+	Následující vlastnosti jsou ověřené a je vhodné je znát dřív, než si resort začne stavět vlastní řešení.
	+
	+	==== 3.1 ZIFO a první AIFO vznikají dříve než záznam v ROB ====
	+
	+	Vydání identifikátoru a zápis referenčních údajů jsou dva různé kroky. ZIFO a první AIFO vytváří ORG na žádost primárního editora službou E95 orgZalozAIFOPE; zápis záznamu do ROB je samostatný úkon editora podle § 19 zákona č. 111/2009 Sb. Vazba identifikátoru na registr obyvatel tedy není technicky nutná — je to důsledek toho, že dnešními žadateli jsou pouze editoři ROB.
	+
	+	Vstupem služby E95 je pouze kód agendy a kód AIS, výstupem AIFO. Služba nepředává žádný osobní údaj a ORG žádný osobní údaj nedostane ani nevede — to platí i pro identity bez vazby na registr obyvatel.
	+
	+	Tomu odpovídá i dikce zákona: podle § 9 odst. 1 zákona č. 111/2009 Sb. se AIFO přiřazuje //„záznamu o fyzické osobě v agendovém informačním systému, základním registru nebo soukromoprávním systému pro využívání údajů“//, nikoli osobě zapsané v registru obyvatel.
	+
	+	==== 3.2 ZIFO bez AIFO agendy A101 je legitimní stav ====
	+
	+	ORG nekontroluje, zda k vydanému AIFO existuje AIFO pro agendu registru obyvatel. Taková identita se neobjeví v žádné chybové sestavě ani úklidovém procesu a ostatní služby ORG nad ní pracují beze změny — E199, E78 orgCtiZmenyAifo, přihlášení AIFO, rodokmen i editační služby E68 orgZneplatniZIFO, E69 orgSpojZIFO a E70 orgRozdelZIFO.
	+
	+	==== 3.3 Předávání AIFO neexistujícího v ROB je podporováno od roku 2019 ====
	+
	+	Dvojice služeb E175 iszrUlozMapaAifo a E176 iszrPodejMapaAifo slouží k předávání nereferenčních údajů mezi dvěma AIS: zdrojový AIS uloží do ISZR dvojice svých a lokálních AIFO a předá cílovému AIS identifikátor úložky. Věcná pravidla služby rozlišují tři situace a AIFO, která nejsou v ORG evidována pro ROB nebo nejsou v ROB platná, se ukládají a cílovému AIS předávají — jen s příznakem. Toto chování zavedla verze V2 účinná od 27. 6. 2019.
	+
	+	Neexistence záznamu v ROB je tedy u této dvojice služeb příznak na výstupu, nikoli důvod k zamítnutí. Je to zároveň nejjednodušší dostupná cesta, jak se čtenář dostane k AIFO osoby v rámci procesu, který stejně probíhá.
	+
	+	==== 3.4 Oprávnění volat služby ORG vyhodnocuje ISZR, nikoli ORG ====
	+
	+	Pro pochopení toho, co je konfigurace a co vývoj, je podstatné, kde se oprávnění vyhodnocuje:
	+
	+	^ Vrstva ^ Co vyhodnocuje ^
	+	\| ISZR \| Nejprve obecné oprávnění na přístup k ISZR — dvojice agenda + role + OVM + AIS podle RPP (neexistuje-li k dané agendě volající AIS, ověří se agenda–AIS podle RAZR). Poté oprávnění volat konkrétní službu podle bezpečnostního profilu evidovaného v RAZR pro dvojici agenda × AIS. \|
	+	\| ORG \| Oprávnění volat službu nevyhodnocuje; nekontroluje ani, pro jakou agendu a AIS je služba volána. \|
	+
	+	Oprávnění se v RAZR eviduje po celých bezpečnostních profilech, ne po jednotlivých službách. Potřebuje-li agenda jen část služeb některého profilu, řeší se to založením nového profilu, nikoli výjimkou v kódu.
	+
	+	===== 4. Zásada: E199 je adresář, nikoli detektor =====
	+
	+	Služba E199 orgZjistiAis vydá seznam kombinací agenda / AIS, ve kterých v ORG existuje AIFO odpovídající vstupnímu AIFO. Odpověď obsahuje pouze prvky Agenda a AIS — žádné cizí AIFO ani osobní údaj.
	+
	+	Z toho plyne pravidlo, které se snadno přečte obráceně, a proto je uvedeno výslovně: implikace platí jen jedním směrem.
	+
	+	* //Nepřítomnost// agendy A101 v odpovědi je spolehlivá negace. Kdo je veden v ROB, musí mít AIFO pro agendu A101, protože na něm ROB své záznamy klíčuje.
	+	* //Přítomnost// agendy A101 neprokazuje, že záznam v ROB existuje nebo dosud trvá. ORG ví pouze to, že pro agendu A101 AIFO kdysi odvodil.
	+
	+	Že jde o dva různé stavy, není odvození: věcná pravidla služeb E175 / E176 je rozlišují explicitně a každý předávají s jiným příznakem — //„globální AIFO, která nejsou v ORG evidována pro ROB“// proti //„globální AIFO, která nejsou v ROB platná (v ROB neexistují)“//.
	+
	+	^ Otázka ^ Kdo na ni odpovídá autoritativně ^
	+	\| Existuje k tomuto AIFO záznam v ROB? \| ROB — E276 robCtiAifo2, hromadně O25 robOverHromadneAifo \|
	+	\| Ve které agendě a v jakém AIS je osoba vedena? \| ORG — E199 orgZjistiAis \|
	+	\| Je osoba mimo ROB? \| Negativně ORG (chybí-li A101, osoba v ROB není); pozitivní potvrzení „je v ROB“ dává jen ROB \|
	+
	+	E199 odpovídá na otázku „kde je osoba vedena“, ne na otázku „je osoba v ROB“.
	+
	+	===== 5. Doporučené pořadí dotazů čtenáře =====
	+
	+	Čtenář, který má AIFO osoby a neví, zda jde o osobu vedenou v ROB, se ptá nejdřív registru obyvatel a teprve po jeho záporné odpovědi volá E199, aby zjistil, která agenda je primární evidencí.
	+
	+	Důvody jsou tři:
	+
	+	- Většina osob v ROB je. Předřazení E199 by zatížilo ORG jedním voláním navíc pro celou populaci, aby se obsloužil zlomek. Obráceně stojí většinový případ jedno volání a menšinový dvě.
	+	- E199 se v menšinovém případě volá tak jako tak. Čtenář z něj nepotřebuje jen příznak „není v ROB“, ale hlavně adresu primární evidence, bez které se k údajům nedostane.
	+	- Odpověď ROB je autoritativní, odvození z ORG jen nepřímé (viz kapitola 4).
	+
	+	Volání E199 je přitom jednorázové na osobu, nikoli na transakci — zjištění, která agenda je primární evidencí, je stabilní údaj a čtenář si jej uloží ke svému záznamu spolu s AIFO.
	+
	+	==== 5.1 Záporná odpověď ROB má tři různé významy ====
	+
	+	^ Význam ^ Jak se rozliší ^ Co má čtenář udělat ^
	+	\| Osoba v ROB skutečně není \| E199 vrátí agendu primární evidence a nevrátí A101 \| číst údaje z publikovaného kontextu přes ISSS \|
	+	\| ROB je dočasně nedostupný \| E199 vrátí i A101 — záznam v ROB tedy existuje \| dotaz zopakovat, do resortní evidence nechodit \|
	+	\| Čtenář drží neplatné AIFO po sloučení identit \| E199 nevrátí nic použitelného, resp. vstupní AIFO neprojde \| zjistit nové AIFO službou E78 orgCtiZmenyAifo \|
	+
	+	Třetí řádek není okrajový jev — viz kapitola 6.
	+
	+	==== 5.2 Čím čtenář začíná ====
	+
	+	Scénář výše začíná ve chvíli, kdy čtenář AIFO osoby už má. To je jeho podstatný předpoklad a je nutné jej odlišit od otázky, kam se s AIFO obrátit:
	+
	+	^ Otázka čtenáře ^ Čím se řeší ^
	+	\| Je osoba vedena v ROB? \| Dotazem do ROB — E276 robCtiAifo2, hromadně O25 robOverHromadneAifo. Jediná autoritativní odpověď a první krok. \|
	+	\| Ve které agendě a v jakém AIS je osoba vedena? \| E199 orgZjistiAis, volaná až po záporné odpovědi ROB. \|
	+	\| Který kontext té agendy hledané údaje obsahuje a smím jej číst? \| Katalog ISSS zveřejňuje definice publikovaných kontextů a datových obsahů; oprávnění čtenáře vzniká ohlášením agendy v RPP a žádostí v RAZR. \|
	+	\| Jak získám AIFO osoby, o níž vím jen jméno a datum narození? \| Nijak — vyhledání podle údajů existuje pouze nad ROB a AISC. Viz kapitola 2. \|
	+
	+	Řetěz tedy vždy začíná tím, že se čtenář o osobě dozví jinak než vyhledáním podle údajů: předáním od protistrany v rámci procesu (E175 / E176), z vyrozumění v AISV, nebo z odpovědi publikačního AIS přes ISSS.
	+
	+	===== 6. Duplicitní identity =====
	+
	+	Duplicitám osoby vedené mimo ROB nelze předcházet, lze je jen detekovat a slučovat. Získá-li osoba pobytový status, editor ROB se nemá jak dozvědět, že už je vedena v resortní evidenci — musel by ji vyhledat podle údajů v resortních kontextech, a taková služba neexistuje. Vznikne tedy druhá identita a řeší se až zpětně. Totéž platí pro osobu vedenou u dvou resortů.
	+
	+	Z toho plyne několik věcí, které patří do metodiky každého dotčeného AIS:
	+
	+	* Sloučení identit mění AIFO ve všech agendách. Služba E69 orgSpojZIFO nahrazuje více ZIFO jedním novým, takže se generují nová AIFO i pro ostatní agendy. Čtenáři změnu zpracují službou E78 orgCtiZmenyAifo, která vrací dvojice původní / nové AIFO. Tvrzení „AIFO se nemění“ platí pro převzetí identity jiným editorem podle § 10 odst. 3, nikoli pro sloučení dvou identit.
	+	* Čtenář může o téže osobě vést dva záznamy až do okamžiku sloučení, protože jde o dvě různá AIFO.
	+	* Postup podle § 10 odst. 6 a 7 zákona č. 111/2009 Sb. směruje řešení nedostatků v přidělení AIFO na správce dotčeného AIS a následně na správce ROB. U osoby mimo ROB nemá správce ROB podle čeho rozhodnout — nevede o ní referenční údaje ani záznam. Je to jedna z mezer, které se řeší legislativně (kapitola 8).
	+	* Editační služby ORG jsou vyhrazeny primárním editorům. E68 orgZneplatniZIFO a E69 orgSpojZIFO smí volat jen AIS primárního editora a předpokládají, že volající už ví, která ZIFO se mají spojit. Kanál, kterým by šlo podezření na duplicitu nahlásit — od jiného orgánu veřejné moci nebo od subjektu údajů — dnes neexistuje; do jeho vzniku se duplicity řeší na podnět a část agendy zůstává ruční.
	+	* Duplicitě, které lze předejít, se předejít má. Očekává-li se u osoby zápis do registru obyvatel v dohledné době (typicky u novorozence, který se do ROB zapisuje do tří měsíců), identita mimo ROB se nezakládá — jinak vznikne duplicita zbytečně.
	+
	+	===== 7. Referenčnost, publikace údajů a vyrozumívání =====
	+
	+	==== 7.1 Údaje o osobě mimo ROB jsou nereferenční ====
	+
	+	Údaje o osobě, kterou nevede ROB, pocházejí z datového kontextu publikovaného resortem do ISSS. Jsou to údaje nereferenční a čtenáři to musí být zřejmé — z hlediska § 5 odst. 2 zákona č. 111/2009 Sb. (využívání údajů bez ověřování správnosti) je to rozdíl, který nesmí zaniknout. Publikační AIS proto označuje zdroj a referenčnost údaje ve svém datovém modelu.
	+
	+	U osob mimo ROB jde o víc než o formální označení: identifikační údaje pocházejí zpravidla z dokladů vydaných v jiném státě a mohou se v čase změnit, aniž se to česká evidence dozví.
	+
	+	==== 7.2 Stavy záznamu: „má AIFO“ přestává znamenat „je v ROB“ ====
	+
	+	Agendy, které vedou i osoby mimo ROB, potřebují ve svém datovém modelu tři stavy, nikoli dva:
	+
	+	^ Stav záznamu ^ AIFO ^ Zdroj identifikačních údajů ^ Referenčnost ^
	+	\| Ztotožněný \| ano, z ztotožnění proti ROB \| ROB \| referenční \|
	+	\| Ztotožněný mimo ROB \| ano \| kontext publikovaný do ISSS \| nereferenční \|
	+	\| Neztotožněný \| ne \| pouze vlastní evidence \| nereferenční \|
	+
	+	Stav „neztotožněný“ nezaniká — zůstává pro záznamy před vydáním identity a pro případy, kdy identita vydána nebude.
	+
	+	Z toho plyne kontrola, kterou je vhodné provést ve všech dotčených AIS i ve standardech a metodikách. Kdekoli je dnes podmínka formulovaná jako „má AIFO“ nebo „nemá AIFO“, je nutné ověřit, co se tím ve skutečnosti myslí. Pokud je to zkratka za „je vedený v registru obyvatel“, přestane platit v okamžiku, kdy AIFO dostanou i osoby mimo ROB, a pravidlo začne dělat něco jiného, než bylo zamýšleno. Typický příklad je pravidlo zakazující sloučit dva záznamy, které mají AIFO: má-li chránit záznamy navázané na ROB, zablokuje po zavedení identit mimo ROB právě ty případy, které se slučovat mají. Kritériem musí být vedení v ROB, nikoli přítomnost AIFO.
	+
	+	==== 7.3 Vyrozumívání běží přes AISV ====
	+
	+	Pro vyrozumívání o změnách se používá AISV (agendový informační systém vyrozumívací, v provozu od 1. 9. 2024, správcem je DIA):
	+
	+	^ Role ^ Služba ^ Funkce ^
	+	\| Publikační AIS (PAIS) \| E308 aisvEvidujZmenu \| eviduje změnu jím publikovaného údaje; PAIS musí být předem zaregistrován včetně číselníku změn údajů, který se kontroluje proti RPP \|
	+	\| Čtenářský AIS \| E315 aisvPrihlasId / E316 aisvOdhlasId \| přihlášení a odhlášení identifikátoru subjektu (AIFO nebo IČO) \|
	+	\| Čtenářský AIS \| E317 aisvCtiZmeny / E318 aisvCtiZmenyId \| čtení změn u přihlášených, resp. u zadaných subjektů \|
	+	\| Vybraný čtenářský AIS \| E319 aisvCtiZmenyZalozAifo \| identifikátory subjektů nově založených v daném PAIS; služba není veřejná, používání schvaluje DIA na žádost s odůvodněním \|
	+
	+	Dvě souvislosti, které je vhodné znát:
	+
	+	* E45 orgPrihlasAIFO a E46 orgOdhlasAIFO se k vyrozumívání už nepoužívají — nahrazují je E315 a E316. Ostatní služby ORG tím nezanikají; E78 orgCtiZmenyAifo pro změny samotných AIFO zůstává.
	+	* E07 robCtiZmeny a E28 rosCtiZmeny mají ukončenou podporu k 30. 6. 2026 a od 1. 1. 2027 je nebude možné používat. Každý čtenář tedy oblast vyrozumívání právě teď stejně předělává.
	+
	+	===== 8. Uvažovaný směr řešení =====
	+
	+	//Tato kapitola popisuje záměr, o kterém nebylo rozhodnuto. Je zde uvedena proto, aby resorty, které dnes stojí před stejným rozhodnutím, věděly, jaká cesta se zvažuje, a nezaváděly řešení, která by bylo nutné později reintegrovat.//
	+
	+	Uvažuje se, aby ORG vydal AIFO i subjektu, který není veden v ROB, na žádost primárního editora resortní evidence. Zdrojem identifikačních údajů o takové osobě by nebyl ROB, ale datový kontext publikovaný resortem do ISSS — stejným způsobem, jakým dnes údaje publikuje kterýkoli AIS. Resortní identifikátor (RID, OIČ) by přitom zůstal v resortu; do centra se neukládá.
	+
	+	Co by se tím dodalo i bez vzniku EJFO: celostátně jedinečná identita osoby, čtení jejích údajů přes ISSS, překlad identity mezi agendami, vyrozumívání o změnách přes AISV a nástroje na zrušení a sloučení identity.
	+
	+	Co zůstává otevřené až do vzniku EJFO: referenčnost údajů, ztotožňování podle údajů (a tím i prevence duplicit), arbitráž nad nedostatky v přidělení AIFO, vstupní ztotožnění pro čtenáře, který má jen údaje osoby, a stabilní identifikátor, kterým by se osoba prokázala napříč resorty.
	+
	+	Legislativní mezery, které je nutné řešit bez ohledu na technické provedení:
	+
	+	* § 11 — zákon svěřuje vytváření ZIFO a AIFO Úřadu, ale neupravuje, na čí žádost vzniká //nová// identita. Dnes to plyne implicitně z toho, že žádá editor ROB.
	+	* § 18 odst. 5 — záznam o využití údajů se vede v ROB. U osoby, která v ROB záznam nemá, není kam zapisovat a subjekt údajů nemá jak získat výpis o tom, kdo se na něj díval.
	+	* § 10 odst. 7 — nedostatky v přidělení AIFO řeší správce ROB, který u osoby mimo ROB nemá o čem rozhodovat.
	+
	+	Doporučení, které platí nezávisle na rozhodnutí: nezavádět v centru mapování AIFO na resortní identifikátor. § 9 zákona č. 111/2009 Sb. staví celý systém na tom, že z AIFO ani ZIFO nelze dovodit údaje o osobě; centrální tabulka „AIFO ↔ resortní identifikátor“ by tuto vlastnost porušila a stala by se nejcennější databází ve státě. Věcně navíc není potřeba — čtenář v PPDF pracuje s AIFO své agendy a překlad na AIFO publikátora provádí ISSS přes ORG. Kdo potřebuje resortní identifikátor, dostane jej jako údaj v publikovaném kontextu.
	+
	+	===== 9. Doporučení pro architekty =====
	+
	+	* Ověřte, zda vaše agenda vede osoby mimo ROB, a kolik jich je. Bez tohoto čísla nelze rozhodnout nic dalšího.
	+	* Nestavte vlastní vyrozumívací kanál pro externí čtenáře. Vlastní notifikační systém má smysl pro subjekty uvnitř resortu; pro OVM a soukromoprávní uživatele údajů se použije AISV a ISSS.
	+	* Publikujte údaje jako datový kontext do ISSS a označte je jako nereferenční.
	+	* Neodvozujte ztotožněnost osoby z toho, že pole AIFO je prázdné. Vede-li vaše agenda osoby mimo ROB, přestane být prázdné AIFO použitelným příznakem; veďte údaj o ztotožnění explicitně a rozlišujte tři stavy podle kapitoly 7.2.
	+	* Projděte všechna pravidla opřená o přítomnost AIFO — ve validacích, v pravidlech pro slučování záznamů, v reportech i v textu standardů a metodik. Kde je „má AIFO“ zkratkou za „je v ROB“, je nutné kritérium přeformulovat (kapitola 7.2).
	+	* Neodvozujte existenci záznamu v ROB z přítomnosti agendy A101 v odpovědi E199 (kapitola 4).
	+	* Počítejte se změnou AIFO po sloučení identit a zpracujte ji službou E78 (kapitola 6).
	+	* Ptejte se nejdřív ROB, E199 volejte až po jeho záporné odpovědi a výsledek si uložte k záznamu (kapitola 5).
	+
	+	===== 10. Související stránky =====
	+
	+	* [[znalostni_baze:ga_ppdf\|Globální architektura propojeného datového fondu]]
	+	* [[znalostni_baze:rc\|Identifikátory, rodná čísla a jejich vazby]]
	+	* [[znalostni_baze:ztotoznovani_spuu\|Metodické doporučení ke ztotožňování fyzických osob u SPUÚ]]
	+	* [[znalostni_baze:predavani_datoveho_fondu\|Předávání obsahu datového fondu]]
	+	* [[znalostni_baze:opravneni_udaje\|Využívání oprávnění na údaje jiných informačních systémů]]
	+	* [[znalostni_baze:evidence_udaju\|Evidence údajů v agendě]]
	+	* [[znalostni_baze:seznam_udaju_agend\|Seznam údajů agend veřejné správy]]
	+	* [[znalostni_baze:pravidla_ref_rozhrani\|Pravidla užívání služeb referenčního rozhraní]]
	+	* [[znalostni_baze:implementace_zopds\|Implementace povinností dle zákona o právu na digitální služby]]
	+	* [[znalostni_baze:klicove_zakony_eg\|Klíčové zákony týkající se eGovernmentu]]
	+	* [[znalostni_baze:souhlas_vyuziti_udaju\|Souhlas s využitím údajů uživatele služby]]
	+
	+	===== 11. Zdroje =====
	+
	+	* Zákon č. 111/2009 Sb., o základních registrech — zejména § 5 odst. 2, § 9, § 10, § 11, § 17, § 18 odst. 5, § 19.
	+	* Zákon č. 325/2021 Sb., o elektronizaci zdravotnictví, ve znění zákona č. 236/2025 Sb.
	+	* Zákon č. 323/2025 Sb., o jednotném měsíčním hlášení zaměstnavatele.
	+	* [[https://www.szrcr.cz/images/Katalog_eGON_sluzeb_15_3_verejny.pdf\|Katalog eGON služeb, v. 15.3, veřejná část]]
	+	* [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E199_orgZjistiAis.pdf\|Popis eGON služby E199 — orgZjistiAis]]
	+	* [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E175_iszrUlozMapaAifo.pdf\|Popis eGON služby E175 — iszrUlozMapaAifo]]
	+	* [[https://szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E176_iszrPodejMapaAifo.pdf\|Popis eGON služby E176 — iszrPodejMapaAifo]]
	+	* [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/AISV_prirucka_pro_pripojeni_externe_1_10.pdf\|Uživatelská příručka pro připojení k AISV, v. 1.10]]
	+	* [[https://ncez.mzcr.cz/sites/default/files/Attachment/EZ_SL01.03_Standard%20EZ%20Kmenov%C3%A9%20registry_v0.6.pdf\|Standard elektronického zdravotnictví — Kmenové registry, v. 0.6]]
	+	* [[https://www.uzis.cz/res/file/projekty/ehealth-optimalizace-postupu/metodika-kmenovy-registr-pacientu.pdf\|Metodika Kmenový registr pacientů, ÚZIS ČR]]
	+
	+	~~DISCUSSION~~

Jednotný informační systém sběru dat (JISSD) - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-09-02T08:47:32+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== Jednotný informační systém sběru dat (JISSD) ======

	+	===== Popis =====
	+
	+	Jednotný informační systém sběru dat (JISSD) přináší jednotné prostředí pro vytváření, distribuci a zpracování dotazníků, vyhodnocování získaných dat a sdílení již existujících informačních zdrojů. Díky tomu pomáhá zjednodušit sběr informací, omezovat duplicitní šetření a efektivněji využívat data veřejné správy i veřejné prostředky. Systém se skládá ze tří základních modulů, kterými jsou Dotazníkový nástroj, Analytický nástroj a Knihovna zdrojů. JISSD je dostupný na adrese [[https://sberdat.gov.cz/]]. Na tomto webu naleznete i další informace, návody a možnost přihlásit se na uživatelská školení.
	+
	+	{{ :nap:jissd.png?600 \|}}
	+
	+	===== Využití =====
	+
	+	Systém mohou aktivně využívat – realizovat v něm dotazníková šetření, analyzovat jejich výsledky či vkládat odkazy na zajímavé datové zdroje relevantní pro veřejnou správu – všichni úředníci státu i samospráv, kteří mají uživatelský účet v JIP/KAAS, integrace s CAAIS bude dostupná od Q4/2026.
	+
	+	Hlavní přínosy systému jsou následující:
	+
	+	* Data jsou ukládána a zpracovávána v bezpečném a důvěryhodném prostředí
	+	* Úspora nákladů na komerční nástroje
	+	* Podpora rozhodování založeného na datech
	+	* Eliminace duplicitních sběrů dat díky podpoře sdílení

Registr zastupování - [Popis Registru zastupování]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-08-17T06:05:56+00:00

2026/06/25 12:35		aktuální
Řádek 7:		Řádek 7:

	https://reza-ais.egon.gov.cz/		https://reza-ais.egon.gov.cz/
-
-	Na této stránce není k dispozici přehled udělených oprávnění.

	Testovací prostředí je k dispozici na adrese https://reza-ais-test.egon.gov.cz		Testovací prostředí je k dispozici na adrese https://reza-ais-test.egon.gov.cz
		+
		+	Na této stránce není k dispozici přehled udělených oprávnění. Přehled a možnost udělení oprávnění je na Portálu registru práv a povinností https://rpp.dia.gov.cz/
		+
		+

	</WRAP>		</WRAP>
Řádek 233:		Řádek 235:
	^ Kód služby ^ Název ^ Popis ^		^ Kód služby ^ Název ^ Popis ^
	\| E338 \| RppRezaPoskytniZastupovane \| Vrátí seznam zastupovaných subjektů (AIFO/IČO) pro danou osobu \|		\| E338 \| RppRezaPoskytniZastupovane \| Vrátí seznam zastupovaných subjektů (AIFO/IČO) pro danou osobu \|
-	\| A14633.1 \| Oprávnění k zastupování \| ZapisOKZ Zapiš oprávnění k zastupování AIS posílá data ze svého lokální REZA systému s požadavkem na zápis do AIS REZA. Služba je určena pro vložení nebo editaci oprávnění k zastupování \\	+	\| A14633.1 \| Oprávnění k zastupování \| ZapisOKZ Zapiš oprávnění k zastupování AIS posílá data ze svého lokální REZA systému s požadavkem na zápis do AIS REZA. Služba je určena pro vložení nebo editaci oprávnění k zastupování \\ UkonciOKZ Ukonči oprávnění k zastupování AIS posílá data ze svého lokální REZA systému s požadavkem na ukončení oprávnění k zastupování AIS REZA. Typické užití této služby je v případě chybně vytvořeného oprávnění k zastupování \\ CtiDetailOKZ Čti detail oprávnení k zastupování Vypiš detail aktuálního nebo historického oprávnění k zastupování. Služba může vrátit 0-n detailů Oprávnění k zastupování \\ CtiSeznamOKZ Čti seznam oprávnění k zastupování Vypiš seznam aktuálních nebo historických kódů oprávnění k zastupování. Služba může vrátit 0-n kódů Oprávnění k zastupování \\ ZapisReklamaciOKZ Zapiš reklamaci oprávnění k zastupování AIS posílá reklamaci s požadavek na zápis nového/chybějícího oprávnění k zastupování případně reklamaci k existujícímu OKZ \\ CtiReklamaciOKZ Vypiš reklamaci Vypiš detail k vytvořené reklamaci.\|
-	UkonciOKZ Ukonči oprávnění k zastupování AIS posílá data ze svého lokální REZA systému s požadavkem na ukončení oprávnění k zastupování AIS REZA. Typické užití této služby je v případě chybně vytvořeného oprávnění k zastupování \\	+
-	CtiDetailOKZ Čti detail oprávnení k zastupování Vypiš detail aktuálního nebo historického oprávnění k zastupování. Služba může vrátit 0-n detailů Oprávnění k zastupování \\	+
-	CtiSeznamOKZ Čti seznam oprávnění k zastupování Vypiš seznam aktuálních nebo historických kódů oprávnění k zastupování. Služba může vrátit 0-n kódů Oprávnění k zastupování \\	+
-	ZapisReklamaciOKZ Zapiš reklamaci oprávnění k zastupování AIS posílá reklamaci s požadavek na zápis nového/chybějícího oprávnění k zastupování případně reklamaci k existujícímu OKZ \\	+
-	CtiReklamaciOKZ Vypiš reklamaci Vypiš detail k vytvořené reklamaci.\|	+

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

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-07-27T05:53:59+00:00

2025/07/25 08:38		aktuální
Řádek 94:		Řádek 94:
	* Musí být schopen poskytnout úhradu poplatku pomocí platební brány		* Musí být schopen poskytnout úhradu poplatku pomocí platební brány
	* Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód		* Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód
-	* Musí splňovat bezpečnostní požadavky dle [[https://nukib.gov.cz/download/publikace/podpurne_materialy/minimalni-bezpecnostni-standard_v1.2.pdf\|minimálního bezpečnostního standardu]]	+	* Musí splňovat bezpečnostní požadavky dle [[https://e-sbirka.gov.cz/sb/2025/410?zalozka=text\|Vyhlášky o bezpečnostních opatřeních poskytovatele regulované služby v režimu nižších povinností]]. Původně požadovaný Minimální bezpečnostní standard vydávaný Národním úřadem pro kybernetickou a informační bezpečnost již není relevantní.
	* Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím [[nap:egovernment_cloud\|cloud computingu]], atd.)		* Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím [[nap:egovernment_cloud\|cloud computingu]], atd.)
	* Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb [[nap:komunikacni_infrastruktura_verejne_spravy\|KIVS/CMS]].		* Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb [[nap:komunikacni_infrastruktura_verejne_spravy\|KIVS/CMS]].

Kontext eGSB/ISSS - [Kontexty, datové obsahy a AIS dostupné na ISSS]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-07-10T07:25:10+00:00

2026/07/10 07:23		aktuální
Řádek 34:		Řádek 34:
	Detailní a aktuální seznam kontextů, datových obsahů a AIS je dostupný na adrese [[https://egsbkatalog.cms2.cz/]] a [[https://katalogisss.dia.cms2.cz]]. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.		Detailní a aktuální seznam kontextů, datových obsahů a AIS je dostupný na adrese [[https://egsbkatalog.cms2.cz/]] a [[https://katalogisss.dia.cms2.cz]]. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.

-	Zde uvedené informace jsou platné k 30.1.2026	+	Zde uvedené informace jsou platné k 10.7.2026
	</WRAP>		</WRAP>

Řádek 456:		Řádek 456:
	\|1025\|Registr silničních vozidel (RSV)\|		\|1025\|Registr silničních vozidel (RSV)\|
	\|1078\|Informační systém RBP\|		\|1078\|Informační systém RBP\|
-	\|1098\| Centrální registr zbraní\|	+	\|1098\|Centrální registr zbraní\|
	\|1507\|eAVA\|		\|1507\|eAVA\|
	\|2679\|KIS\|		\|2679\|KIS\|
Řádek 465:		Řádek 465:
	\|5304\|IS úřadu pro civilní letectví\|		\|5304\|IS úřadu pro civilní letectví\|
	\|5351\|CIS OZP\|		\|5351\|CIS OZP\|
-	\|5636\| Elektronické testy uchazečů o řidičská oprávnění (eTesty)\|	+	\|5636\|Elektronické testy uchazečů o řidičská oprávnění (eTesty)\|
	\|5838\|Informační systém technických prohlídek (IS TP)\|		\|5838\|Informační systém technických prohlídek (IS TP)\|
	\|5866\|Systém elektronického mýta (Mýto)\|		\|5866\|Systém elektronického mýta (Mýto)\|
-	\|6726\| Rejstřík podnikatelů v silniční dopravě (RPSD)\|	+	\|6726\|Rejstřík podnikatelů v silniční dopravě (RPSD)\|
	\|7199\|Informační systém Státní plavební správy\|		\|7199\|Informační systém Státní plavební správy\|
	\|7638\|Národní kontaktní místo pro elektronické zdravotnictví \|		\|7638\|Národní kontaktní místo pro elektronické zdravotnictví \|
	\|7874\|Centrální evidence přeplatků a nedoplatků\|		\|7874\|Centrální evidence přeplatků a nedoplatků\|
		+	\|8453\|Statistický informační systém (SIS)\|
	\|8456\|IS Digitální tachograf (ISDT)\|		\|8456\|IS Digitální tachograf (ISDT)\|
	\|8618\|IS Elektronická dálniční známka\|		\|8618\|IS Elektronická dálniční známka\|
	\|8657\|Monitorovací systém fondů EU 21+\|		\|8657\|Monitorovací systém fondů EU 21+\|
	\|8658\|Centrální registr pojištenců\|		\|8658\|Centrální registr pojištenců\|
		+	\|8659\|e-Sbírka a e-Legislativa\|
	\|8830\|IS eRecept\|		\|8830\|IS eRecept\|
	\|8929\|Portál dopravy\|		\|8929\|Portál dopravy\|
Řádek 481:		Řádek 483:
	\|9209\|Portál dopravy - stage\|		\|9209\|Portál dopravy - stage\|
	\|9616\|Informační systém vzdělávání eEdu\|		\|9616\|Informační systém vzdělávání eEdu\|
-	\|10357\| IS pro nadrozměrnou přepravu (IS NADR)\|	+	\|10357\|IS pro nadrozměrnou přepravu (IS NADR)\|
	\|14600\|Informační systém oprávnění k zastupování (REZA)\|		\|14600\|Informační systém oprávnění k zastupování (REZA)\|
	\|14835\|EUCARIS \|		\|14835\|EUCARIS \|
	\|15736\|Agendový informační systém pojištění odpovědnosti z provozu vozidla (AISPOV)\|		\|15736\|Agendový informační systém pojištění odpovědnosti z provozu vozidla (AISPOV)\|
-	\|17678\| Kmenový registr pacientů\|	+	\|16703\|Integrovaný informační systém Ministerstva práce a sociálních věcí\|
-	\|18776\| Správa PPP a zobrazení souhlasů\|	+	\|17678\|Kmenový registr pacientů\|
		+	\|18576\|Centrální evidence psů (CEP)\|
		+	\|18776\|Správa PPP a zobrazení souhlasů\|
	</datatables>		</datatables>

Agendový informační systém Vyrozumívací (AISV)

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-04-10T07:41:19+00:00

2026/04/10 07:26		aktuální
Řádek 58:		Řádek 58:
	* Změny hodnoty nebo stavu údaje subjektu údajů označené příslušným kódem údaje podle registrovaného číselníku změn údajů PAIS.		* Změny hodnoty nebo stavu údaje subjektu údajů označené příslušným kódem údaje podle registrovaného číselníku změn údajů PAIS.
	* Změny záznamu subjektu údajů vzniklé na základě události označené klíčovým slovem (vznik záznamu, zrušení záznamu, skartace záznamu, změna editora záznamu)		* Změny záznamu subjektu údajů vzniklé na základě události označené klíčovým slovem (vznik záznamu, zrušení záznamu, skartace záznamu, změna editora záznamu)
		+
		+	=== Seznam publikujících AIS na AIS-V ===
		+
		+	<WRAP center round important 60%>
		+	Informace zde jsou platné k 10.4.2026, aktuální informace jsou vždy dostupné na [[ https://szrcr.cz/cs/sluzby/spravci-a-vyvojari?view=article&id=407:agendov%C3%BD-informa%C4%8Dn%C3%AD-syst%C3%A9m-vyrozum%C3%ADvac%C3%AD&catid=18\|stránkách DIA]]
		+	</WRAP>
		+
		+	<datatable>
		+	^Název systému^Agenda^Pais^Seznam kódů publikovaných údajů^Poznámka^
		+	\|Registr obyvatel \|A101 \|1192 \|101-1-1 Příjmení \\ 101-1-2 Jméno, popř. jména \\ 101-1-3 Adresa místa pobytu \\ 101-1-4 Doručovací adresa \\ 101-1-5 Datum narození \\ 101-1-6 Místo a okres (stát) narození \\ 101-1-7 Datum úmrtí \\ 101-1-8 Datum nabytí právní moci rozhodnutí soudu o prohlášení za mrtvého \\ 101-1-9 Místo a okres (stát) úmrtí \\ 101-1-10 Státní občanství \\ 101-1-11 Čísla a druhy identifikačních dokladů a datum skončení jejich platnosti \\ 101-1-12 Záznam o zřízení datové schránky a identifikátor datové schránky \\ 101-1-13 Rodné příjmení \\ 101-1-14 Pohlaví \\ 101-1-15 Rodinný stav nebo registrované partnerství \\ 101-1-16 Omezení svéprávnosti \\ 101-1-17 Telefonní číslo \\ 101-1-18 Adresa elektronické pošty \\ 101-1-19 Kvalifikovaný certifikát pro elektronický podpis (sériové číslo, vydavatel a platnost) \|produkční prostředí\|
		+	\|Registr osob \|A102 \|163 \|102-1-1 IČO (Identifikační číslo osoby) \\ 102-1-2 Fyzická osoba podnikatele \\ 102-1-3 Obchodní jméno \\ 102-1-4 Datum vzniku \\ 102-1-5 Datum zániku \\ 102-1-6 Právní forma \\ 102-1-7 Právní stav \\ 102-1-8 Datová schránka \\ 102-1-9 Statutární orgán \\ 102-1-10 Likvidátor \\ 102-1-11 Opatrovník právnické osoby \\ 102-1-12 Insolvenční správce \\ 102-1-13 Nucený správce \\ 102-1-14 Sídlo \\ 102-1-16 Přerušení nebo pozastavení činnosti \\ 102-1-17 Provozovna \\ 102-1-18 Fyzická osoba zastupující právnickou osobu, která je členem statutárního orgánu jiné právnické osoby \\ 102-1-19 Kontaktní údaje \\ 102-1-20 Doručovací adresa osoby \\ 102-1-21 Doručovací adresa provozovny \|produkční prostředí\|
		+	\|Agendový informační systém systém evidence obyvatel \|A115 \|33 \|115-1-7 Rodné číslo \\ 115-1-139 Záznam o matce \\ 115-1-140 Záznam o otci \\ 115-1-141 Záznam o jiném zákonném zástupci \\ 115-1-143 Záznam o manželovi \\ 115-1-144 Záznam o partnerovi \\ 115-1-145 Záznam o dítěti \\ 115-1-146 Záznam o opatrovníkovi \\ 115-1-14 Datum ukončení trvalého pobytu \\ \|produkční prostředí\|
		+	\|Agendový informační systém cizinců \|A116 \|198 \|116-1-1 Jméno cizince \\ 116-1-10 Rodinný stav cizince \\ 116-1-11 Místo uzavření manžel/partner \\ 116-1-13 Stav osoby od - datum úmrtí \\ 116-1-14 Místo úmrtí (místo,okr.,stát) \\ 116-1-15 Typ pobytu \\ 116-1-16 Adresa pobytu cizince \\ 116-1-17 Skutečný pobyt \\ 116-1-18 Platnost povolení pobytu od do \\ 116-1-19 Způsobilost cizince \\ 116-1-2 Příjmení cizince \\ 116-1-20 Údaje o otci cizince \\ 116-1-21 Údaje o matce cizince \\ 116-1-22 Údaje o zákonném zástupci \\ 116-1-23 Základní údaje o partnerovi/ce \\ 116-1-24 Základní údaje o dětech \\ 116-1-25 Státní občanství otce a matky \\ 116-1-26 Manžel/partner - občanství \\ 116-1-27 Státní občanství dítěte \\ 116-1-28 Místo narození dítěte \\ 116-1-29 Předchozí jména cizince \\ 116-1-3 Rodné příjmení cizince \\ 116-1-30 Předchozí místa pobytu \\ 116-1-31 Změna manželství/partnerství \\ 116-1-33 Změna pohlaví- datum \\ 116-1-34 Předchozí rodná čísla cizince \\ 116-1-35 Údaje o osvojených dětech \\ 116-1-36 Údaje o osvojení cizince \\ 116-1-37 Správní nebo soudní vyhoštění \\ 116-1-38 Doručovací adresa cizince \\ 116-1-39 Cizinci dle písmene u) \\ 116-1-4 Ostatní jména \\ 116-1-41 Zápis do seznamu voličů \\ 116-1-42 Zaměstnání,zařazení,místo výkonu \\ 116-1-43 Osvojenec - Typ osvojení \\ 116-1-44 Osvojenec - Původní rodné číslo \\ 116-1-45 Osvojenec - Původní jméno \\ 116-1-46 Osvojenec - Původní rod.příjmení \\ 116-1-47 Datum NPM osvojení osvojitelkou \\ 116-1-48 Dat.NPM zrušení os.osvojitelkou \\ 116-1-49 Datum NPM osvojení osvojitelem \\ 116-1-5 Datum narození cizince \\ 116-1-50 Dat.NPM zrušení os. osvojitelem \\ 116-1-51 RČ původního otce \\ 116-1-52 Datum narození původního otce \\ 116-1-53 Jméno původního otce \\ 116-1-54 Příjmení původního otce \\ 116-1-55 Rodné příjmení původního otce \\ 116-1-56 AIFO původního otce \\ 116-1-57 RČ původní matky \\ 116-1-58 Datum narození původní matky \\ 116-1-59 Jméno původní matky \\ 116-1-6 Místo narození (místo,okr.,stát) \\ 116-1-60 Příjmení původní matky \\ 116-1-61 Rodné příjmení původní matky \\ 116-1-62 AIFO původní matky \\ 116-1-63 Dřívější rodná příjmení \\ 116-1-64 Nezvěstnost \\ 116-1-65 Územní zákaz pobytu \\ 116-1-66 Obrazový záznam \\ 116-1-7 Rodné číslo cizince \\ 116-1-8 Státní občanství \\ 116-1-9 Pohlaví cizince \|produkční prostředí\|
		+	\|Agendový informační systém evidence cestovních dokladů \|A118 \|31 \| 118-1-28 omezení spočívající v zákazu vycestování do zahraničí \|produkční prostředí\|
		+	\|Agendový informační systém registru zastupování \|A14633 \|14600 \|14633-3-2 Identifikátor certifikátu \|produkční prostředí\|
		+	\|Centrální registr pojištěnců \|A1341 \|8658 \|1341-15-1 Číslo pojištěnce \\ 1341-15-2 Jméno/jména \\ 1341-15-3 Příjmení \\ 1341-15-4 Rodné příjmení \\ 1341-15-5 Datum narození \\ 1341-15-6 Pohlaví \\ 1341-15-7 Datum úmrtí \\ 1341-15-8 Adresa pobytu \\ 1341-16-1 Registrace od \\ 1341-16-2 Registrace do \\ 1341-17-1 Kód zdravotní pojišťovny \\ 1341-18-1 Stav zdravotního pojištění od \\ 1341-18-2 Stav zdravotního pojištění do \\ 1341-19-1 Druh Pojištění \\ 1341-19-2 Kód stavu pojištění \\ 1341-20-1 Rozsah od \\ 1341-20-2 Rozsah do \\ 1341-21-1 Kód rozsahu \\ 1341-22-1 Stav účasti od \\ 1341-22-2 Stav účasti do \\ 1341-23-1 Kód účasti \\ 1341-24-1 Příslušnost od \\ 1341-24-2 Příslušnost do \\ 1341-25-1 Stát plátcem pojistného \\ 1341-25-2 Kód státní kategorie \\ 1341-26-1 Příslušnost od \\ 1341-26-2 Příslušnost do \\ 1341-27-1 Číslo pojištěnce živitele \\ 1341-28-1 Příslušnost nezaopatřeného rodinného příslušníka od \\ 1341-28-2 Příslušnost nezaopatřeného rodinného příslušníka do \\ 1341-29-1 Číslo pojištěnce \\ \|produkční prostředí\|
		+	\|Informační systém evidence přestupků \|A483 \|7209 \|483-2-1 Evidence osob, které byly pravomocně uznány vinnými spácháním přestupku \\ 483-2-17 Datum zápisu pravomocného rozhodnutí o přestupku \|produkční prostředí\|
		+	\|Informační systém rejstříku trestů \|A483 \|123 \|483-1-28 Evidence odsouzení \|produkční prostředí\|
		+	\|Agendový informační systém ZBRANĚ \|A419 \|1098 \|419-17-17 je držitelem \|produkční prostředí\|
		+	</datatable>

	==== Čtenářský agendový informační systém (AIS) ====		==== Čtenářský agendový informační systém (AIS) ====
Řádek 83:		Řádek 103:

	<WRAP center round important 60%>		<WRAP center round important 60%>
-	Současné notifikační služby ROB a ROS, tj. E07 robCtiZmeny a E28 rosCtiZmeny, budou do koncem roku 2026 vypnuty. \\	+	Současné notifikační služby ROB a ROS, tj. E07 robCtiZmeny a E28 rosCtiZmeny, budou koncem roku 2026 vypnuty. \\
	Informace zde jsou platné k 10.4.2026, aktuální informace jsou vždy dostupné na [[ https://szrcr.cz/cs/sluzby/spravci-a-vyvojari?view=article&id=407:agendov%C3%BD-informa%C4%8Dn%C3%AD-syst%C3%A9m-vyrozum%C3%ADvac%C3%AD&catid=18\|stránkách DIA]]		Informace zde jsou platné k 10.4.2026, aktuální informace jsou vždy dostupné na [[ https://szrcr.cz/cs/sluzby/spravci-a-vyvojari?view=article&id=407:agendov%C3%BD-informa%C4%8Dn%C3%AD-syst%C3%A9m-vyrozum%C3%ADvac%C3%AD&catid=18\|stránkách DIA]]
	</WRAP>		</WRAP>
Řádek 90:		Řádek 110:
	Správci AIS by měli postupně migrovat na nahrazující notifikační a čtecí služby, jak ukazuje následující tabulka:		Správci AIS by měli postupně migrovat na nahrazující notifikační a čtecí služby, jak ukazuje následující tabulka:

-	^Končící služba^Název končící služby^Nahrazující služba^Název nahrazující služby^	+	^Končící či utlumovaná služba^Název končící či utlumované služby^Nahrazující služba^Název nahrazující služby^
	\|E03 \|robCtiAifo \|E276 \|robCtiAifo2 \|		\|E03 \|robCtiAifo \|E276 \|robCtiAifo2 \|
	\|E05 \|robCtiPodleUdaju \|E278 \|robCtiPodleUdaju2 \|		\|E05 \|robCtiPodleUdaju \|E278 \|robCtiPodleUdaju2 \|
Řádek 99:		Řádek 119:
	\|E46 \|orgOdhlasAifo \|E316 \|aisvOdhlasID \|		\|E46 \|orgOdhlasAifo \|E316 \|aisvOdhlasID \|

-	==== Seznam publikujících AIS na AIS-V ====	+
-	<datatable>	+
-	^Název systému^Agenda^Pais^Seznam kódů publikovaných údajů^Poznámka^	+
-	\|Registr obyvatel \|A101 \|1192 \|101-1-1 Příjmení \\ 101-1-2 Jméno, popř. jména \\ 101-1-3 Adresa místa pobytu \\ 101-1-4 Doručovací adresa \\ 101-1-5 Datum narození \\ 101-1-6 Místo a okres (stát) narození \\ 101-1-7 Datum úmrtí \\ 101-1-8 Datum nabytí právní moci rozhodnutí soudu o prohlášení za mrtvého \\ 101-1-9 Místo a okres (stát) úmrtí \\ 101-1-10 Státní občanství \\ 101-1-11 Čísla a druhy identifikačních dokladů a datum skončení jejich platnosti \\ 101-1-12 Záznam o zřízení datové schránky a identifikátor datové schránky \\ 101-1-13 Rodné příjmení \\ 101-1-14 Pohlaví \\ 101-1-15 Rodinný stav nebo registrované partnerství \\ 101-1-16 Omezení svéprávnosti \\ 101-1-17 Telefonní číslo \\ 101-1-18 Adresa elektronické pošty \\ 101-1-19 Kvalifikovaný certifikát pro elektronický podpis (sériové číslo, vydavatel a platnost) \|produkční prostředí\|	+
-	\|Registr osob \|A102 \|163 \|102-1-1 IČO (Identifikační číslo osoby) \\ 102-1-2 Fyzická osoba podnikatele \\ 102-1-3 Obchodní jméno \\ 102-1-4 Datum vzniku \\ 102-1-5 Datum zániku \\ 102-1-6 Právní forma \\ 102-1-7 Právní stav \\ 102-1-8 Datová schránka \\ 102-1-9 Statutární orgán \\ 102-1-10 Likvidátor \\ 102-1-11 Opatrovník právnické osoby \\ 102-1-12 Insolvenční správce \\ 102-1-13 Nucený správce \\ 102-1-14 Sídlo \\ 102-1-16 Přerušení nebo pozastavení činnosti \\ 102-1-17 Provozovna \\ 102-1-18 Fyzická osoba zastupující právnickou osobu, která je členem statutárního orgánu jiné právnické osoby \\ 102-1-19 Kontaktní údaje \\ 102-1-20 Doručovací adresa osoby \\ 102-1-21 Doručovací adresa provozovny \|produkční prostředí\|	+
-	\|Agendový informační systém systém evidence obyvatel \|A115 \|33 \|115-1-7 Rodné číslo \\ 115-1-139 Záznam o matce \\ 115-1-140 Záznam o otci \\ 115-1-141 Záznam o jiném zákonném zástupci \\ 115-1-143 Záznam o manželovi \\ 115-1-144 Záznam o partnerovi \\ 115-1-145 Záznam o dítěti \\ 115-1-146 Záznam o opatrovníkovi \\ 115-1-14 Datum ukončení trvalého pobytu \\ \|produkční prostředí\|	+
-	\|Agendový informační systém cizinců \|A116 \|198 \|116-1-1 Jméno cizince \\ 116-1-10 Rodinný stav cizince \\ 116-1-11 Místo uzavření manžel/partner \\ 116-1-13 Stav osoby od - datum úmrtí \\ 116-1-14 Místo úmrtí (místo,okr.,stát) \\ 116-1-15 Typ pobytu \\ 116-1-16 Adresa pobytu cizince \\ 116-1-17 Skutečný pobyt \\ 116-1-18 Platnost povolení pobytu od do \\ 116-1-19 Způsobilost cizince \\ 116-1-2 Příjmení cizince \\ 116-1-20 Údaje o otci cizince \\ 116-1-21 Údaje o matce cizince \\ 116-1-22 Údaje o zákonném zástupci \\ 116-1-23 Základní údaje o partnerovi/ce \\ 116-1-24 Základní údaje o dětech \\ 116-1-25 Státní občanství otce a matky \\ 116-1-26 Manžel/partner - občanství \\ 116-1-27 Státní občanství dítěte \\ 116-1-28 Místo narození dítěte \\ 116-1-29 Předchozí jména cizince \\ 116-1-3 Rodné příjmení cizince \\ 116-1-30 Předchozí místa pobytu \\ 116-1-31 Změna manželství/partnerství \\ 116-1-33 Změna pohlaví- datum \\ 116-1-34 Předchozí rodná čísla cizince \\ 116-1-35 Údaje o osvojených dětech \\ 116-1-36 Údaje o osvojení cizince \\ 116-1-37 Správní nebo soudní vyhoštění \\ 116-1-38 Doručovací adresa cizince \\ 116-1-39 Cizinci dle písmene u) \\ 116-1-4 Ostatní jména \\ 116-1-41 Zápis do seznamu voličů \\ 116-1-42 Zaměstnání,zařazení,místo výkonu \\ 116-1-43 Osvojenec - Typ osvojení \\ 116-1-44 Osvojenec - Původní rodné číslo \\ 116-1-45 Osvojenec - Původní jméno \\ 116-1-46 Osvojenec - Původní rod.příjmení \\ 116-1-47 Datum NPM osvojení osvojitelkou \\ 116-1-48 Dat.NPM zrušení os.osvojitelkou \\ 116-1-49 Datum NPM osvojení osvojitelem \\ 116-1-5 Datum narození cizince \\ 116-1-50 Dat.NPM zrušení os. osvojitelem \\ 116-1-51 RČ původního otce \\ 116-1-52 Datum narození původního otce \\ 116-1-53 Jméno původního otce \\ 116-1-54 Příjmení původního otce \\ 116-1-55 Rodné příjmení původního otce \\ 116-1-56 AIFO původního otce \\ 116-1-57 RČ původní matky \\ 116-1-58 Datum narození původní matky \\ 116-1-59 Jméno původní matky \\ 116-1-6 Místo narození (místo,okr.,stát) \\ 116-1-60 Příjmení původní matky \\ 116-1-61 Rodné příjmení původní matky \\ 116-1-62 AIFO původní matky \\ 116-1-63 Dřívější rodná příjmení \\ 116-1-64 Nezvěstnost \\ 116-1-65 Územní zákaz pobytu \\ 116-1-66 Obrazový záznam \\ 116-1-7 Rodné číslo cizince \\ 116-1-8 Státní občanství \\ 116-1-9 Pohlaví cizince \|produkční prostředí\|	+
-	\|Agendový informační systém evidence cestovních dokladů \|A118 \|31 \| 118-1-28 omezení spočívající v zákazu vycestování do zahraničí \|produkční prostředí\|	+
-	\|Agendový informační systém registru zastupování \|A14633 \|14600 \|14633-3-2 Identifikátor certifikátu \|produkční prostředí\|	+
-	\|Centrální registr pojištěnců \|A1341 \|8658 \|1341-15-1 Číslo pojištěnce \\ 1341-15-2 Jméno/jména \\ 1341-15-3 Příjmení \\ 1341-15-4 Rodné příjmení \\ 1341-15-5 Datum narození \\ 1341-15-6 Pohlaví \\ 1341-15-7 Datum úmrtí \\ 1341-15-8 Adresa pobytu \\ 1341-16-1 Registrace od \\ 1341-16-2 Registrace do \\ 1341-17-1 Kód zdravotní pojišťovny \\ 1341-18-1 Stav zdravotního pojištění od \\ 1341-18-2 Stav zdravotního pojištění do \\ 1341-19-1 Druh Pojištění \\ 1341-19-2 Kód stavu pojištění \\ 1341-20-1 Rozsah od \\ 1341-20-2 Rozsah do \\ 1341-21-1 Kód rozsahu \\ 1341-22-1 Stav účasti od \\ 1341-22-2 Stav účasti do \\ 1341-23-1 Kód účasti \\ 1341-24-1 Příslušnost od \\ 1341-24-2 Příslušnost do \\ 1341-25-1 Stát plátcem pojistného \\ 1341-25-2 Kód státní kategorie \\ 1341-26-1 Příslušnost od \\ 1341-26-2 Příslušnost do \\ 1341-27-1 Číslo pojištěnce živitele \\ 1341-28-1 Příslušnost nezaopatřeného rodinného příslušníka od \\ 1341-28-2 Příslušnost nezaopatřeného rodinného příslušníka do \\ 1341-29-1 Číslo pojištěnce \\ \|produkční prostředí\|	+
-	\|Informační systém evidence přestupků \|A483 \|7209 \|483-2-1 Evidence osob, které byly pravomocně uznány vinnými spácháním přestupku \\ 483-2-17 Datum zápisu pravomocného rozhodnutí o přestupku \|produkční prostředí\|	+
-	\|Informační systém rejstříku trestů \|A483 \|123 \|483-1-28 Evidence odsouzení \|produkční prostředí\|	+
-	\|Agendový informační systém ZBRANĚ \|A419 \|1098 \|419-17-17 je držitelem \|produkční prostředí\|	+
-	</datatable>	+

	{{tag>AISV vyrozumívací notifikace vyrozumění}}		{{tag>AISV vyrozumívací notifikace vyrozumění}}

Centrální autentizační a autorizační systém (CAAIS)

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-02-20T14:08:58+00:00

2025/01/24 14:51		aktuální
Řádek 12:		Řádek 12:
	Na rozdíl od systému JIP/KAAS rozhoduje DIA o využívání bez licenčních omezení, což představuje finanční úsporu.		Na rozdíl od systému JIP/KAAS rozhoduje DIA o využívání bez licenčních omezení, což představuje finanční úsporu.

-	===== Současný stav =====	+	==== Současný stav ====

	Systém CAAIS se skládá ze dvou modulů:		Systém CAAIS se skládá ze dvou modulů:
Řádek 77:		Řádek 77:
	AIS při volání autentizačních služeb používá ověřovací certifikát pro autentizaci vůči CAAIS. Tento certifikát musí být typu komerční serverový a musí být zaregistrovaný v nastavení AIS a musí být vydaný podporovanou certifikační autoritou (I.CA, PostSignum, eIdentity, NCA). V konfiguraci AIS v CAAIS může být zaregistrován pouze jeden ověřovací certifikát pro JIP/KAAS legacy, právě jeden podpisový a právě jeden šifrovací pro SAML a více certifikátů pro OIDC.		AIS při volání autentizačních služeb používá ověřovací certifikát pro autentizaci vůči CAAIS. Tento certifikát musí být typu komerční serverový a musí být zaregistrovaný v nastavení AIS a musí být vydaný podporovanou certifikační autoritou (I.CA, PostSignum, eIdentity, NCA). V konfiguraci AIS v CAAIS může být zaregistrován pouze jeden ověřovací certifikát pro JIP/KAAS legacy, právě jeden podpisový a právě jeden šifrovací pro SAML a více certifikátů pro OIDC.

-	===== Budoucí stav =====	+	====Přístup dodavatelů do AIS====
		+
		+
		+	^ Situace ^ Ideální řešení ^ Funkční, ale nedoporučované řešení ^
		+	\|Správce AIS využívá CAAIS a potřebuje umožnit přístup i uživatelům z externích subjektů (dodavatelé, provozovatelé). \|Architektura AIS s tím počítala. Jsou definovány aplikační role pro dodavatele/provozovatele. Správce CAAIS zakládá subjekty dle IČO, určují se lokální administrátoři, ti zakládají uživatele a přidělují role. AIS správně rozpozná uživatele podle údajů z CAAIS a loguje jejich činnost jako činnost dodavatele/provozovatele. \|Design s tím nepředpokládal. Garant AIS požádá svého lokálního administrátora o zavedení uživatelů dodavatelů. Doporučuje se interní předpis upravující odpovědnosti za životní cyklus účtů. Existuje riziko, že externí uživatel může jednat i v jiných systémech správce. Doporučuje se formálně ošetřit závazek nepoužívat účet mimo vymezené systémy. \|
		+	\|Externí pracovníci potřebují pracovat na produkci se stejným rozsahem oprávnění jako interní uživatelé (např. pro testování). \|AIS má interní testovací účty vedené v interním IDM. Tyto účty jsou určeny omezenému okruhu lidí, jsou odlišitelné od reálných účtů, nejsou zahrnuty do statistik a neovlivňují reálné subjekty. AIS obsahuje izolovaný „paralelní vesmír“ pro testování. \|Viz předchozí řešení \|
		+	\|Správce pověřil výkonem některých činností externí subjekt, který má jednat „jako správce“, ale pod svou vlastní hlavičkou. \|AIS využívá služby Registru zastoupení (REZA). Správce AIS definuje šablonu zastoupení a povolí zastupování externím subjektům. Správce CAAIS založí subjekty, ti si určují administrátory a zakládají uživatele. AIS ověřuje oprávnění v REZA a loguje činnost jako jednání v zastoupení. \|AIS obsahuje vlastní matici pověření. Oprávnění uživatelé jednoho subjektu zapisují pověření pro druhý subjekt nebo konkrétní osoby. Externí uživatelé se přihlašují buď přes CAAIS pod svým subjektem, nebo interním účtem v IDM AIS. \|
		+
		+
		+
		+	==== Budoucí stav ====

	V budoucnu se očekává přechod všech současných systémů na CAAIS a v případě nově vznikajících, jejich přednostní implementace CAAIS. Rozšířením identitních prostředků se ulehčí práce úředníků.		V budoucnu se očekává přechod všech současných systémů na CAAIS a v případě nově vznikajících, jejich přednostní implementace CAAIS. Rozšířením identitních prostředků se ulehčí práce úředníků.
Řádek 85:		Řádek 95:
	Předpokládá se i úplné vypnutí systému JIP/KAAS, jakmile bude uveden do provozu systém Czech POINT 2.0 v rámci projektu „Generační́ obnova informačního systému Czech POINT“. Do té doby zůstává nadále v platnosti přihlašování výhradně pomocí JIP/KAAS u pracovníků kontaktních míst veřejné správy Czech POINT do rozhraní Czech POINT.		Předpokládá se i úplné vypnutí systému JIP/KAAS, jakmile bude uveden do provozu systém Czech POINT 2.0 v rámci projektu „Generační́ obnova informačního systému Czech POINT“. Do té doby zůstává nadále v platnosti přihlašování výhradně pomocí JIP/KAAS u pracovníků kontaktních míst veřejné správy Czech POINT do rozhraní Czech POINT.

		+	{{tag>caais jip kaas}}

Open source software v české státní správě - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-02-19T14:59:31+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== Open source software v české státní správě ======
	+
	+	===== ÚVOD =====
	+	Státní správa a politická reprezentace mnoha států demokratického světa si začíná více uvědomovat rizika plynoucí z přílišného spoléhání se na proprietární software pro výkon svých agend. Software s otevřeným zdrojovým kódem (dále také „open source software“ či „OSS“) se jeví jako možná cesta pro snížení závislosti na dodavatelích proprietárního software a eliminaci s tím spojených rizik. Tento text by v ideálním případě mohl posloužit k popisu možností využití otevřeného software ve státní správě.
	+
	+	V úvodní kapitole jsou identifikovány hlavní rozdíly mezi proprietárním a open source softwarem, jejich výhody a nevýhody. Dále je text zaměřen výhradně na OSS, jsou popsány možnosti jeho využití ve státní správě i příklady dobré praxe. Vzhledem k tomu, že se pohybujeme v českém kontextu, tak se další kapitola zaměřuje na legislativní rámec a omezení z něj plynoucí pro potenciální aplikaci OSS v české státní správě. Zároveň jsou představeny konkrétní projekty a iniciativy, které OSS v české státní správě využívají, případně podporují jeho využívání na různých úrovních správy. V následující kapitole je představen německý vládní projekt openDesk a poslední kapitoly jsou zaměřeny na možnosti jeho aplikace v jednotlivých úrovních české státní správy, vč. návrhu akčního plánu a potenciálních KPI.
	+
	+	===== OPEN SOURCE VS. PROPRIETÁRNÍ SOFTWARE =====
	+
	+	==== HLAVNÍ ROZDÍLY ====
	+	Zaprvé je nutné od sebe oddělit jednotlivé druhy software, vzhledem k zaměření této práce využijeme dělení dle stupně otevřenosti zdrojového kódu a z něho plynoucího možnost software upravovat. Na základě tohoto hlediska je možné identifikovat tyto druhy software:
	+
	+	* Software s otevřeným zdrojovým kódem (open source software)
	+	* Software s uzavřeným zdrojovým kódem (closed source software, proprietární software)
	+
	+	Kromě samotné otevřenosti software je poté důležitá i licenční politika se softwarem spojená. I v rámci otevřeného softwaru by tedy měly být dodrženy licenční podmínky stanovené autorem daného software. Open source projekty jsou obvykle licencovány pod svobodnými licencemi, jako je GPL, MIT nebo Apache, které uživatelům dávají právo software používat, měnit a sdílet. U proprietárního softwaru platí uživatel za licenci, která často omezuje použití softwaru pouze na určité účely, zařízení nebo časové období, a jakékoliv úpravy jsou zakázány.
	+
	+	Z hlediska vývoje a inovací je open source software často vyvíjen komunitou dobrovolníků i profesionálů z různých organizací. Tento přístup může urychlit inovace a zvyšovat bezpečnost díky tomu, že kód je veřejně přístupný a může být zkontrolován více lidmi. Proprietární software je vyvíjen interně danou firmou, která má plnou kontrolu nad vývojem i aktualizacemi, což může vést k větší stabilitě, ale i pomalejší reakci na chyby či nové požadavky.
	+
	+	Z pohledu podpory a záruk se open source může spoléhat na komunitní podporu, fóra a dokumentaci, zatímco proprietární software většinou nabízí oficiální technickou podporu, SLA (service level agreements) a pravidelné aktualizace, což může být výhodné zejména pro firmy s kriticky důležitými aplikacemi. Zároveň i open source software může být poskytová s placenou technickou podporou, pravidelnými aktualizacemi a zaručenými SLA. Uživatel však může do software libovolně zasahovat a upravovat si ho dle svých potřeb, pokud má potřebné technické znalosti.
	+
	+	==== MOŽNOSTI A RIZIKA OPEN SOURCE SOFTWARE ====
	+	Open source software nabízí řadu výhod, které z něj činí atraktivní volbu pro jednotlivce, firmy i veřejné instituce. Mezi hlavní možnosti patří především flexibilita a přizpůsobitelnost – díky otevřenému zdrojovému kódu lze software upravit podle vlastních potřeb, integrovat s jinými systémy nebo přidat specifické funkce. Další výhodou je nezávislost na jednom dodavateli (tzv. vendor lock-in), což uživatelům dává větší kontrolu nad tím, jak software používají a rozvíjejí.
	+
	+	Open source je také často bezplatný nebo výrazně levnější než proprietární řešení, což umožňuje ušetřit náklady na licence, zejména ve větších organizacích. Aktivní komunita okolo mnoha open source projektů zajišťuje rychlý vývoj, časté aktualizace a možnost získat podporu prostřednictvím fór, wiki stránek či přímého kontaktu s vývojáři. Díky transparentnosti může být open source software i bezpečnější – kód je veřejný a může být nezávisle auditován z hlediska bezpečnostních zranitelností.
	+
	+	Na druhé straně je třeba počítat i s určitými riziky. Ne každý open source projekt je aktivně udržován – některé mohou být opuštěné, zastaralé nebo s nedostatečnou dokumentací, což komplikuje nasazení a údržbu. Podpora není vždy zaručena a spoléhání se na komunitní pomoc může být v krizových situacích nedostatečné. Kromě toho vyžaduje používání a správa open source softwaru často vyšší technické znalosti in-house, zejména pokud jde o úpravy kódu nebo řešení problémů.
	+
	+	Z bezpečnostního hlediska může být open source výhodný i rizikový zároveň. I když je kód přístupný pro audit, zranitelnosti mohou zůstat dlouho neodhaleny, pokud absentuje dostatečně velká a aktivní komunita. Také neexistuje centrální zodpovědnost – pokud nastane problém, není vždy jasné, na koho se obrátit pro podporu. Organizace proto musí pečlivě zvažovat, jaký open source software nasazují, jakým způsobem jej spravují a jak zajistí jeho bezpečnost a dlouhodobou udržitelnost. Tyto nedostatky je možné do značné míry eliminovat správným definováním parametrů veřejné zakázky.
	+
	+	Celkově vzato, open source software představuje silný nástroj s velkým potenciálem, ale je důležité přistupovat k jeho využití strategicky a s vědomím možných omezení.
	+
	+	==== OPEN SOURCE VE STÁTNÍ SPRÁVĚ ====
	+	Aplikace open source softwaru ve státní správě nabízí řadu významných příležitostí, které mohou vést ke zvýšení efektivity, transparentnosti i hospodárnosti veřejné správy. Jednou z hlavních výhod je snížení závislosti na konkrétních dodavatelích softwaru – tzv. vendor lock-in –, což státním institucím umožňuje větší kontrolu nad vlastními IT systémy a lepší vyjednávací pozici při správě a rozvoji softwarových řešení. Díky otevřenému kódu je možné software upravovat na míru konkrétním potřebám úřadů, sdílet řešení mezi různými institucemi a znovu použít již existující nástroje bez nutnosti platit za nové licence.
	+
	+	Další významnou příležitostí je posílení transparentnosti a důvěry veřejnosti. Pokud státní správa využívá open source software, může být kód veřejně přístupný, což umožňuje nezávislé audity, zvyšuje bezpečnost a dává občanům možnost lépe porozumět digitálním nástrojům, které stát využívá. Open source také podporuje spolupráci a inovace – veřejné instituce mohou spolupracovat s univerzitami, vývojáři či neziskovým sektorem na vývoji společných řešení, čímž se zvyšuje efektivita investic do digitalizace.
	+
	+	Využití open source softwaru ve veřejném sektoru může taktéž přinést významné finanční benefity, především v oblasti úspor na licenčních poplatcích. Oproti proprietárnímu softwaru, kde je nutné platit za každou licenci, často opakovaně a vázaně na konkrétní zařízení nebo uživatele, je většina open source řešení dostupná zdarma. To umožňuje státním institucím efektivněji spravovat rozpočty a alokovat prostředky na další klíčové oblasti, například na vývoj vlastních funkcionalit, zajištění bezpečnosti nebo školení zaměstnanců. Další finanční výhodou je možnost sdílet jednou vyvinutá řešení mezi různými institucemi, čímž se snižuje duplicita výdajů. Navíc otevřený charakter softwaru podporuje konkurenci mezi dodavateli služeb, což může vést k nižším nákladům na implementaci, správu a rozvoj informačních systémů.
	+
	+	Na druhé straně existují i určitá rizika a výzvy, které je třeba pečlivě zvážit. Ne každý open source projekt je vhodný pro nasazení ve státní správě – některé mohou být nestabilní, nedostatečně dokumentované nebo bez dlouhodobé podpory. Správné vyhodnocení kvality a životaschopnosti open source řešení vyžaduje odborné kapacity a znalosti, které nemusí být v některých institucích dostupné. Také chybějící oficiální technická podpora může být problém v případě výpadků nebo bezpečnostních incidentů, zejména u kritických systémů.
	+
	+	Bezpečnost je dalším zásadním aspektem – ačkoli je transparentnost výhodou, veřejně dostupný kód může být zneužit, pokud není pravidelně auditován a aktualizován. Je tedy klíčové, aby instituce měly nastaveny procesy pro správu aktualizací, auditování kódu a zajištění kybernetické bezpečnosti. V neposlední řadě může být překážkou i kulturní či organizační odpor ke změně, protože přechod z proprietárních řešení na open source často vyžaduje nové dovednosti a změnu zaběhlých postupů.
	+
	+	Závěrem lze říci, že open source software představuje pro státní správu velkou příležitost ke zlepšení efektivity, transparentnosti a soběstačnosti. Úspěšné využití těchto výhod ale vyžaduje promyšlený přístup, odborné zázemí a strategii, která zohlední jak přínosy, tak možná rizika.
	+
	+	==== PŘÍKLADY DOBRÉ PRAXE ZE ZAHRANIČÍ ====
	+	Pojďme si nyní krátce představit konkrétní projekty ze zahraničí na národní a regionální úrovni, ve kterých se povedlo implementovat open source software ve státní správě.
	+
	+	Na národní úrovni stojí za zmínku například poměrně velký projekt GendBuntu. Konkrétně je GendBuntu verzí Ubuntu upravená na míru potřebám francouzského Národního četnictva (Gendarmerie Nationale), což je jedna z personálně nejpočetnějších státních institucí v rámci Francie. Začátek celého procesu přechodu četnictva k open source je možné datovat až do roku 2001, kdy byla identifikována potřeba větší modularity operačních systémů, kterou do té doby používaný MS Windows neumožňoval. Nicméně v té době ještě nebyly k dispozici uživatelsky přívětivé open source alternativy, které by byly v takto velké instituci implementovatelné bez negativních dopadů a rizik. V roce 2005 dochází k prvnímu hmatatelnému kroku, kdy je kancelářský balík MS Office v rámci četnictva postupně nahrazen balíkem OpenOffice. Následující rok dochází k nahrazení MS Outlook a Internetu Explorer Thunderbirdem, resp. Mozillou Firefox. V roce 2008 už byla situace příznivější a použitelnost/uživatelská přívětivost GNU/Linux distribucí postupně dorovnala úroveň MS Windows, padlo tedy rozhodnutí k migraci všech pracovních stanic četnictva na Ubuntu, které bylo i postupně realizováno.(( BIERHALS, Gregor. Towards the freedom of the operating system: The French Gendarmerie goes for Ubuntu. Online. 2012. Dostupné také z: https://interoperable-europe.ec.europa.eu/sites/default/files/document/2011-12/IDABC.OSOR.casestudy.Gendarmerie.10.pdf ))
	+
	+	Z hlediska koncového uživatele proběhla migrace velmi hladce, což bylo dáno jednak tím, že klíčové aplikace (prohlížeč, kancelářský software) zůstaly, díky dřívější migraci na open source, stejné a tím, že UI Ubuntu je uživatelsky přívětivé. Hladký průběh byl dán také vnějšími okolnostmi. Četnictvo je velmi centralizovaná instituce, což umožňuje velmi rychle přijmout a realizovat rozhodnutí napříč celou organizací. Zároveň nebylo potřeba realizovat nějaké zvláštní právní kroky, jelikož celý proces nevyžadoval žádné další investice nad rámec interních zdrojů organizace. Tato situace nastala až v momentu, kdy četnictvo realizovalo veřejnou zakázku na externí podporu od subjektu soukromého sektoru.(( Tamtéž. ))
	+
	+	Na regionální úrovni stojí za zmínku aktivita německé spolkové země Šlesvicko-Holštýnsko, ve které v dubnu 2024 došlo k rozhodnutí, že veřejná správa (30 000 zaměstnanců) bude migrovat svoje systémy na open source řešení. Open source budou jak operační systémy (Linux), tak software pro práci s dokumenty (Libre Office) a mailový klient (Thunderbird). Celý proces je podrobně popsán ve strategickém dokumentu Open Innovation and Open Source Strategy of Land Schleswig-Holstein, kterou si tato spolková země sama stanovila.(( Open Innovation and Open Source Strategy of Land Schleswig-Holstein. Online. 2024. Dostupné také z: https://www.schleswig-holstein.de/DE/landesregierung/themen/digitalisierung/linux-plus1/Service/Downloads/_dateien/open-source-strategy_EN.pdf?__blob=publicationFile&v=3 ))
	+
	+	Celý projekt digitálně suverénního IT pracovního prostředí stojí na 6 pilířích:
	+
	+	* Nahrazení OS MS Windows open source alternativou Linux
	+	* Nahrazení MS Office open source alternativou LibreOffice
	+	* Nahrazení MS Sharepoint a Exchange/Outlook open source alternativami Nextcloud, Open-Xchange / Thunderbird
	+	* Infrastruktura založená na kombinaci open source a proprietárních řešeních, nahrazení MS Active Directory open source adresářovým řešením
	+	* Specializované administrativní procedury nezávislé na platformě (ideálně přístupné skrze prohlížeč)
	+	* Nově vyvíjená IP telefonie založená na open source komunikační architektuře (OSKAR)(( Tamtéž. ))
	+
	+	Projekt je momentálně ve fázi realizace a probíhá v několika souběžně běžících etapách. Konkrétně pro oblast kancelářského software byl klíčový přechod na povinný formát ODF v rámci dokumentů státní správy, který platí od 1. srpna 2024. Zároveň minimálně do skončení podpory MS Office, tj. do konce října 2025 mohou úředníci paralelně využívat jak LibreOffice, tak MS Office. Zároveň pro specifické procesy (méně než 30 % use cases) mohou nadále vyžadovat využití MS Office.(( Schleswig-Holstein's Bold Open Source Leap: A Model for Digital Sovereignty? Online. In: Euro-stack.com. 2025. Dostupné také z: https://euro-stack.com/blog/2025/3/schleswig-holstein-open-source-digital-sovereignty ))
	+
	+	Ve Francii je realizován a rozvíjen projekt La Suite(( La Suite. Online. 2025. Dostupné také z: https://lasuite.numerique.gouv.fr/en )), který se velmi podobá projektu openDesk (viz dále). Jedná se o open source sadu nástrojů pro spolupráci ve veřejném sektoru, která by měla být propojená a dostupná po jediném ověření pomocí poskytovatele identity ProConnect.(( Suite numérique. Online. Beta.gouv.fr. 2025. Dostupné také z: https://beta.gouv.fr/startups/suite-numerique.html )) V současnosti jsou součástí této sady následující komponenty:
	+
	+	* Tchap – chatovací aplikace
	+	* France Transfert – přenos velkých souborů
	+	* Webinaire, Webconf a Audioconf – audio a video konference
	+	* Visio – rychlé videokonference
	+	* Resana – ukládání souborů
	+	* Grist – správa databází
	+	* Docs – společná úprava textových dokumentů
	+	* Messagerie – synchronizace emailů a kalendářů, s OpenExchange.
	+
	+	Obecně napříč Evropou probíhají v rámci veřejného sektoru různé projekty a iniciativy, které se snaží v menším či větším měřítku implementovat open source software a snížit tak míru závislosti na libovůli dodavatelů proprietárního software. Velmi často se jedná o využití open source kancelářských balíků, komunikačních nástrojů, případně operačních systémů. Stručný přehled konkrétních zemí a dalších projektů nabízí Wikipedie.(( Adoption of free and open-source software by public institutions. Online. In: Wikipedia: the free encyclopedia. San Francisco (CA): Wikimedia Foundation, 2001-2025. Dostupné také z: https://en.wikipedia.org/wiki/Adoption_of_free_and_open-source_software_by_public_institutions ))
	+
	+	===== OPEN SOURCE V ČESKÉ STÁTNÍ SPRÁVĚ =====
	+
	+	==== LEGISLATIVNÍ RÁMEC A OMEZENÍ ====
	+	Právní rámec využití open source v české státní správě není stanoven jedním konkrétním předpisem, nicméně existuje několik důležitých legislativních a strategických dokumentů, které pro tuto oblast nastavují alespoň obecná pravidla. Do budoucna je nicméně žádoucí a potřebné, aby využití open source ve státní správě bylo legislativně upraveno v rámci některého zákona (jako potenciální nosič se tematicky nabízí např. zákon č. 365/2000 Sb., o informačních systémech veřejné správy). Zejména by měla být stanovena zodpovědnost toho, kdo kód poskytuje k využití, konkrétně v případě zodpovědnosti za údržbu kódu (aktualizace, záplaty apod.).
	+
	+	V první řadě je důležitou normou zákon č. 365/2000 Sb., o informačních systémech veřejné správy(( Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů. In: E-sbirka.cz. Dostupné také z: https://www.e-sbirka.cz/sb/2000/365 )). Mj. dává orgánům veřejné správy povinnost provádět hodnocení ekonomické výhodnosti způsobu provozu jimi spravovaných systémů. Stanovuje také orgánům veřejné správy povinnost při pořízení nového informačního systému veřejné správy, příp. realizaci architektonické změny, zažádat o stanovisko Digitální a informační agenturu. Ta mimo jiné posuzuje i to, zda je systém v souladu s architektonickými principy stanovenými Informační koncepcí ČR, které podporují využití open source (viz princip 19 – Otevřená řešení(( Informační koncepce ČR: Obecné principy pro naplňování cílů Informační koncepce ČR. Online. In: Archi.gov.cz. 2024. Dostupné z: https://archi.gov.cz/ikcr#architektonicky_princip_cr_p22omezeni_budovani_monolitickych_systemu ))).
	+
	+	Dalším klíčovým předpisem je zákon č. 181/2014 Sb., o kybernetické bezpečnosti(( Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti). In: E-sbirka.cz. Dostupné také z: https://www.e-sbirka.cz/sb/2014/181/ )) a jeho prováděcí vyhláška č. 316/2014 Sb. Je nutné zmínit, že od 1. listopadu 2025 bude vcházet v účinnost nový zákon o kybernetické bezpečnosti (zákon č. 264/2025 Sb.)(( Zákon č. 264/2025 Sb., o kybernetické bezpečnosti. In: E-sbirka.cz. Dostupné také z: https://www.e-sbirka.cz/sb/2025/264 )), který nahradí ten stávající.
	+
	+	Obecný rámec zadávání veřejných zakázek stanovuje zákon č. 134/2016 Sb., o zadávání veřejných zakázek(( Zákon č. 134/2016 Sb., o zadávání veřejných zakázek. In: E-sbirka.cz. Dostupné také z: https://www.e-sbirka.cz/sb/2016/134/ )). Open source tedy lze pořídit pokud je v souladu s těmito zásadami, nesmí být automaticky preferován (zásada nediskriminace a rovného zacházení), nicméně v rámci samotné zakázky lze stanovit požadavky na otevřenost kódu, interoperabilitu či absenci licenčních poplatků.
	+
	+	Ke zveřejnění je možné využít státní GIT repozitář(( Dostupný zde: Explore projects · GitLab https://code.gov.cz/explore )). Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) ve spolupráci s Ministerstvem vnitra poté vydal metodický dokument „Bezpečnostní doporučení pro vývoj otevřeného software“(( NÚKIB a Ministerstvo vnitra vydaly bezpečnostní doporučení pro vývoj otevřeného softwaru. Online. In: Nukib.gov.cz. 2022. Dostupné také z: https://nukib.gov.cz/cs/infoservis/doporuceni/1827-nukib-a-ministerstvo-vnitra-vydaly-bezpecnostni-doporuceni-pro-vyvoj-otevreneho-softwaru/ )).
	+
	+	==== SOUČASNÝ STAV A PŘÍKLADY DOBRÉ PRAXE ====
	+	V České republice v současnosti existuje hned několik projektů, které jsou nějakým způsobem zaměřeny na open source software. Fungují zde minimálně dvě zastřešující organizace s celorepublikovou působností, které se zaměřují na zvyšování povědomí o možnostech využití open source software ve veřejné správě a poskytují i odbornou pomoc.
	+
	+	První z nich je nezisková organizace Otevřená města, resp. její iniciativa Česká programová kancelář Open Source (Czech OSPO), jejímž cílem je vytvořit „národní síť odborníků na Open Source, která umožní udržitelné využívání Open Source ve veřejném sektoru a na akademické půdě“.(( Czech National OSPO: Deklarace. Online. Otevrenamesta.cz. Dostupné z: https://otevrenamesta.cz/czech-ospo )) Tato kancelář navazuje na činnost komunity Česko.Digital, sdružující IT odborníky pomáhající státu s digitalizací, a doplňuje ji.(( Česko digital: Kdo jsme. Online. Cesko.digital. Dostupné z: https://www.cesko.digital/kdo-jsme )) Organizace Otevřená města pomáhá samosprávám s digitalizací a v současné době poskytuje i sedm otevřených a modulárních řešení, které mohou obce či kraje využít:(( Otevřená města: Projekty. Online. Otevrenamesta.cz. Dostupné také z: https://otevrenamesta.cz/projects ))
	+
	+	* Cityvizor – vizualizace rozpočtu obce s detailními daty, která jsou získávána přímo z účetních systémů
	+	* DSW2 – nástroj umožňující příjem, zpracování a správu žádostí o dotace pro obce, městské části, dotační úřady a další subjekty
	+	* Průběžné skenování zranitelnosti – software, který průběžně vyhledává bezpečnostní zranitelnosti a upozorňuje na tyto hrozby zapojené obce
	+	* Open Energoman – software pro evidenci budov, odběrných míst a smluv s dodavateli, který sbírá data o stavech energometrů a dále je přehledně vizualizuje
	+	* PAROZ – platforma pro participativní rozpočet, od sběru návrhů, prezentaci projektů až po hlasování
	+	* Platební portál – platební portál, který umožňuje občanům zaplatit za poplatky a služby v rámci jejich obce, kraje či regionu
	+	* CSGOV – systém pro jednoduchou tvorbu, správu a údržbu obecních webů
	+
	+	Druhou relevantní organizací je spolek BISON, jehož jedním z cílů je „vytvořit jednotnou, jasně definovanou platformu pro rozvoj a šíření open-source software projektů v rámci veřejné správy, a to za účelem podpory co nejkvalitnějšího výkonu veřejné správy a optimalizace zdrojů nutných pro další vývoj otevřených a sdílených softwarových řešení ve veřejné správě.“(( Memorandum: Principy fungování spolku BISON. Online. Spolek-bison.cz. Dostupné také z: https://www.spolek-bison.cz/memorandum )) Spolek je založen výhradně „na spolupráci veřejného sektoru za účelem maximálního využití zdrojů investovaných do vývoje SW využívaného primárně za účelem výkonu veřejné správy.“(( Tamtéž. )) V současnosti spolek nabízí k využití tyto nástroje:(( Projekty. Online. Spolek-bison.cz. Dostupné také z: https://www.spolek-bison.cz/projekty ))
	+
	+	* COBY – aplikace pro pedagogicko-psychologické poradny a speciálně pedagogická centra, umožňuje přehlednou správu informací o klientech, vč. diagnostiky a doporučení
	+	* Interní audit – aplikace pro automatizaci procesů interního auditu
	+	* Projektové řízení – nástroj pro řízení současných i budoucích rozvojových aktivity a projektů organizace, zaměřeno primárně na fáze plánování a realizace
	+	* TEDDY:TIME – aplikace pro vykazování činností a správu výkazů práce
	+	* Portál příspěvkových organizací – nástroj pro zajištění oboustranné komunikace a spolupráce mezi zřizovatelem a jeho příspěvkovými organizacemi
	+	* Výkazy sociálních služeb – nástroj pro kraje, který usnadňuje sledování a správu sociálních služeb a přispívá k efektivnímu využívaní prostředků (dotace, výkazy apod.)
	+	* Evidence smluv – nástroj pro správu smluvních vztahů (smlouvy připravované, uzavřené i jejich dodatky), umí pracovat s různými druhy smluv (kupní, nájemní, objednávky aj.)
	+	* Náhradní rodinná péče – nástroj pro on-line evidenci náhradní rodinné péče, evidence a sdílení dat mezi krajskými úřady a obcemi s rozšířenou působností v této oblasti
	+	* TECHNET – nástroj pro evidenci a správu IT aktiv, vč. aplikací, serverů, instancí a databází
	+	* AWAY – nástroj pro správu a vyúčtování nepřítomností zaměstnanců (pracovní cesty, dovolené, indispoziční volna, propustky k lékaři)
	+	* ALUŠKA - systém pro elektronické vedení školní matriky v mateřské škole.
	+
	+	===== OPENDESK =====
	+
	+	==== ZÁKLADNÍ INFORMACE ====
	+	OpenDesk je projekt německého vládního Centra pro digitální suverenitu (ZenDiS - Zentrum für Digitale Souveränität) spadajícího pod německé Spolkové ministerstvo vnitra. Historie ZenDiS sahá zhruba do roku 2019, kdy německá spolková vláda, konkrétně Spolkové ministerstvo vnitra, nechala zpracovat studii,(( HILLENIUS, Gijs. German government wants to reduce its IT vendor lock-in. Online. In: Interoperable-europe.ec.europa.eu. 24/09/2019. Dostupné také z: https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/towards-digital-sovereignty )) ze které vyplynula přílišná závislost vládního IT na komerčních (proprietárních) softwarových produktech od velmi úzkého množství dodavatelů. To sebou nese rizika podkopávající digitální suverenitu, která byla popsána i ve druhé kapitole tohoto textu (vendor lock-in, vysoké náklady, velmi nízká míra autonomie nad vývojem a podobou software, obavy ze zabezpečení dat atd.).(( PÄTSCH, Sivan. German government executes OSS-based vision of digital sovereignty. Online. In: Interoperable-europe.ec.europa.eu. 07/07/2021. Dostupné také z: https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/centre-digital-sovereignty )) Na základě této premisy v prosinci roku 2022 dochází ke vzniku ZenDiS, které by mělo být hlavním centrálním koordinačním orgánem pro podporu a zavádění open source software v rámci německé státní správy a zajištění digitální suverenity a autonomie.(( Tamtéž. ))
	+
	+	V současnosti jsou nejviditelnějšími projekty ZenDiS openCode a openDesk. OpenCode je repozitář open source software a projektů využívaných a využitelných v rámci (německé) státní správy, vč. potřebné dokumentace. V současnosti se zde nachází zhruba 3600 projektů, od malých podpůrných jednoúčelových programů po komplexní specializované aplikace.(( OpenCode. Online. Dostupné z: https://opencode.de/en ))
	+
	+	OpenDesk je poté komplexní balík open source web-based kancelářských a kolaborativních aplikací, který by měl nahradit většinu funkcionalit, které nabízí proprietární řešení typu Microsoft 365 a Teams, ale také Cofluence a Jira.(( FEILNER, Markus. ZenDIS, openDesk, and openCode: How Germany is transforming their public sector with open source. Online. In: Allthingsopen.org. January 30, 2025. Dostupné také z: https://allthingsopen.org/articles/zendis-opendesk-opencode-public-sector-open-source )) Jedná se v podstatě o materializaci konceptu „suverénního pracoviště“ (Sovereign Workplace), který definovalo německé Spolkové ministerstvo vnitra. Je využitelné na spolkové, státní i lokální úrovni, nezávislé na konkrétním poskytovateli a fungující v jakémkoli prohlížeči a na jakémkoliv zařízení.(( EU Open Source Solutions Catalogue: openDesk. Online. Interoperable-europe.ec.europa.eu. Dostupné také z: https://interoperable-europe.ec.europa.eu/eu-oss-catalogue/solutions/opendesk-0 ))
	+
	+	Provozní modely využití openDesk jsou následující:(( OpenDesk: Operating models. Online. Opendesk.eu. Dostupné také z: https://www.opendesk.eu/en/operating-models ))
	+
	+	Community Edition je nabízena zcela zdarma komukoliv, kdo má zájem a nabízí stejné funkcionality jako verze Enterprise. Může sloužit k prvotnímu vyzkoušení jednotlivých funkcionalit na svém vlastním hardware.
	+
	+	Enterprise verze je již placená, díky čemuž je zajištěn další rozvoj aplikací a je určena primárně pro velké organizace s více než 500 uživateli. V rámci této edice je dostupná profesionální podpora se smluvně zaručenými SLA (je možná až nepřetržitá podpora v režimu 24/7), unifikované uživatelské rozhraní a škálovatelnost. Uživatelé dostávají pravidelné aktualizace a profesionální podporu. V rámci této verze jsou dostupné tyto modely provozu:
	+
	+	* On premise – se zajištěním SLA a podpory
	+	* openDesk jako SaaS – funguje v rámci německého národního hyperscaleru
	+	* openDesk v rámci zabezpečeného důvěrného cloudu – primárně určeno pro organizace působící na mezinárodní úrovni, mezinárodní hyperscaler
	+
	+	==== KOMPONENTY ====
	+	OpenDesk v současnosti(( Výčet komponent není definitivní a v čase se může měnit, můžou přibývat nové komponenty, případně mohou být stávající komponenty nahrazovány jinou aplikací. )) obsahuje následující komponenty a aplikace, které je možné implementovat i samostatně dle potřeb konkrétního úřadu:
	+
	+	^ Komponenta ^ Aplikace ^
	+	\| Kalendář \| OX Calendar \|
	+	\| Chat \| Element \|
	+	\| Kontakty \| OX Contacts \|
	+	\| Správa dokumentů, kancelářský balík \| Collabora Online \|
	+	\| Email \| OX App Suite \|
	+	\| Úložiště souborů \| Nextcloud \|
	+	\| Správa přístupů a identit \| Nubus \|
	+	\| Poznámky \| openDesk Notes \|
	+	\| Projektový management \| OpenProject \|
	+	\| Videokonference \| Jitsi \|
	+	\| Wiki \| XWiki \|
	+
	+	==== PILOTNÍ PROJEKTY ====
	+	Vzhledem k tomu, že verze openDesk 1.0 byla oficiálně vydána v říjnu 2024, tak zatím nejsou k dispozici podrobnější případové studie implementace. Pilotní projekty byly v posledním roce spuštěny v rámci Insitutu Roberta Kocha (RKI) a BWI GmbH, což je poskytovatel IT služeb Bundeswehru, který je vlastněný německým Spolkovým ministerstvem obrany.(( OpenProject: openDesk. Online. Openproject.org. Dostupné také z: https://www.openproject.org/opendesk/ )) Do března 2025 ZenDiS obdržel zhruba 1500 dotazů na openDesk od úřadů a institucí z celého Německa.(( KREMPL, Stefan. Framework agreement: MS-365 alternative OpenDesk to conquer the Bundeswehr. Online. In: Heise.de. Apr 7, 2025. Dostupné z: https://www.heise.de/en/news/Framework-agreement-MS-365-alternative-OpenDesk-to-conquer-the-Bundeswehr-10342383.html ))
	+
	+	V případě RKI došlo k podpisu smlouvy v červnu 2025, openDesk by měl být integrován do komunikační platformy Agora veřejné zdravotní služby. Hlavním cílem by mělo být zlepšení digitální a meziresortní spolupráce v tomto sektoru mezi RKI, Spolkovým ministerstvem zdravotnictví a dalšími spolkovými úřady. OpenDesk bude k dispozici všem zaměstnancům jako hlavní pracovní prostředí, celkem se jedná o zhruba 7000 uživatelů. Zároveň Zendis speciálně pro potřeby RKI přidal komponentu diskusního fóra.(( KREMPL, Stefan. Sovereignty: Public health service increasingly relies on open source. Online. In: Heise.de. Jun 13, 2025. Dostupné také z: https://www.heise.de/en/news/Sovereignty-Public-health-service-increasingly-relies-on-open-source-10443654.html ))
	+
	+	V dubnu 2025 došlo k podpisu rámcové smlouvy mezi ZenDiS a BWI, na základě které bude BWI poskytován openDesk a bude realizován jeho další vývoj na míru potřeb německých ozbrojených sil po dobu 7 let. BWI bude využívat celou paletu nabízených komponent, dojde i k integraci BundesMessengeru (založený na platformě Matrix), který německé ozbrojené síly již v současnosti využívají k zasílání zpráv.(( KREMPL, Stefan. Framework agreement: MS-365 alternative OpenDesk to conquer the Bundeswehr. Online. In: Heise.de. Apr 7, 2025. Dostupné z: https://www.heise.de/en/news/Framework-agreement-MS-365-alternative-OpenDesk-to-conquer-the-Bundeswehr-10342383.html ))
	+
	+	===== MOŽNOSTI APLIKACE OPENDESK V ČESKÉ STÁTNÍ SPRÁVĚ =====
	+	Z předchozího textu poměrně jasně plyne, že trend implementace open source nástrojů ve státní správě má vzestupnou tendenci. Státy si velmi dobře začínají uvědomovat rizika plynoucí ze spoléhání se výhradně na proprietární software (primárně vendor lock-in) a objevují možnosti, které nabízí otevřený software. Pro Českou republiku by využitím openDesk, případně některých jeho komponent, mohla vzniknout konkurenční výhoda a svými potenciálními zkušenostmi z implementace bychom mohli přispět k dalšímu rozvoji open source software a povědomí o možnostech jeho aplikace ve státní správě celkově.
	+
	+	==== CELOSTÁTNÍ ÚROVEŇ ====
	+	Na celostátní úrovni, kam spadají ministerstva a jiné ústřední správní úřady s celostátní působností (potenciálně i bezpečnostní a záchranné složky a armáda), by openDesk mohl sloužit jako jednotný, nezávislý kancelářský balík pro orgány státní správy. Díky modulární architektuře a otevřeným standardům lze řešení nasadit postupně (po jednotlivých komponentách), zbavit se vendor lock-inu a integrovat je s národními systémy v prostředí provozovaném státem či jeho poskytovateli, včetně on-prem nebo státního cloudu. Pro vládu to vytváří prostor pro standardizaci pracovních nástrojů, společné katalogy služeb a podpory, snížení nákladů díky využití sdílené infrastruktury a rychlejší zavádění aplikací pro spolupráci napříč rezorty.
	+
	+	Největší výzvou je zajištění interoperability s již existujícími komplexními systémy státní správy a jejich často proprietárními řešeními, což by vyžadovalo náročné úpravy a integrace. Kritickým faktorem je i kybernetická bezpečnost – centralizovaná platforma představuje atraktivní cíl útoků a vyžaduje robustní ochranná opatření, auditní mechanismy a splnění požadavků zákona o kybernetické bezpečnosti. Problémem může být i odpor uživatelů vůči změně, potřeba rozsáhlého školení desítek tisíc státních zaměstnanců a nutnost vytvořit jednotnou podporu a servisní model napříč rezorty. Rizikem je také koordinace mezi ministerstvy, které mají odlišné procesy a priority, a legislativní omezení spojená s nakládáním s osobními a citlivými daty. V neposlední řadě je nutné zvážit finanční a časovou náročnost celostátní migrace, která by mohla vést k dočasnému zpomalení chodu úřadů.
	+
	+	==== KRAJSKÁ ÚROVEŇ ====
	+	Na krajské úrovni by openDesk mohl fungovat jako jednotná platforma pro interní komunikaci, sdílení a spolupráci mezi krajským úřadem, příspěvkovými organizacemi a samosprávnými orgány. Díky různým modulům openDesk by bylo možné vytvořit bezpečné prostředí, které nahradí roztříštěné komerční služby a zlepší efektivitu spolupráce mezi odbory, krajskými příspěvkovými organizacemi, ale i mezi krajem a obcemi. Propojení s krajskými informačními systémy (GIS, ekonomické systémy) přes otevřené standardy by potenciálně umožnilo snadnější správu dat a koordinaci služeb. Výhodou je také možnost hostování v krajském datovém centru nebo státním cloudu, čímž se posílí suverenita nad daty a zvýší se úroveň kybernetické bezpečnosti. OpenDesk by tak krajům umožnil vytvořit konzistentní digitální pracovní prostředí, které bude podporovat otevřenost, sdílení a jednotnou správu uživatelů napříč organizacemi.
	+
	+	Na krajské úrovni může implementace openDesk narážet na problémy zejména v rozdílné technické vybavenosti a připravenosti jednotlivých krajských úřadů i jejich příspěvkových organizací. Potíže mohou vzniknout při integraci s již používanými lokálními informačními systémy (např. ekonomickými či personálními), které často fungují na proprietárních platformách a nemusí být připravené na otevřené standardy. Výzvou je také zajištění dostatečných kapacit pro správu a bezpečnost – menší kraje nemusí mít vlastní odborníky a budou muset spoléhat na externí podporu, což může prodražit provoz. Rizikem je rovněž odlišná míra digitalizační vyspělosti mezi kraji, která může vést k nerovnoměrnému zavádění řešení a komplikovat sdílení dobré praxe. Neméně důležitým problémem je i management změn – přesvědčit stovky zaměstnanců, aby přešli na nové nástroje, vyžaduje čas, školení a stabilní podporu, jinak hrozí odpor k využívání platformy a návrat k paralelním nástrojům.
	+
	+	==== MÍSTNÍ/LOKÁLNÍ ÚROVEŇ ====
	+	Na místní/obecní úrovni by openDesk mohl poskytnout obcím a městům dostupné a bezpečné digitální pracovní prostředí, které by sjednotilo základní kancelářské nástroje bez nutnosti drahých proprietárních řešení. Menší úřady by mohly využívat Nextcloud pro sdílení dokumentů a bezpečnou výměnu souborů mezi úředníky a občany, Collabora Online pro přípravu a úpravy úředních dokumentů, Element (Matrix) pro interní i meziměstskou komunikaci či OpenProject pro řízení menších projektů, například v oblasti rozvoje obce nebo dotačních programů. Obzvláště využitím Collabora Online místo MS Office by mohlo dojít v malých obcích ke značné úspoře nákladů a implementace by nemusela být ani příliš složitá, uživatelské rozhraní obou aplikací je navíc velmi podobné a přechod by pro zaměstnance nebyl příliš náročný. Díky možnosti hostování v obecním datovém centru, společném regionálním cloudu nebo jako službu sdílenou mezi více obcemi by se snížily náklady na IT infrastrukturu a zároveň posílila kontrola nad daty. OpenDesk by tak obcím umožnil jednoduše digitalizovat běžnou agendu, zefektivnit spolupráci mezi odbory i s občany a zvýšit transparentnost místní samosprávy.
	+
	+	Na místní úrovni mohou implementaci openDesk komplikovat především omezené finanční a personální zdroje menších obcí, které často nemají vlastní IT oddělení ani odborníky schopné platformu samostatně spravovat. Problémem může být i nedostatečná technická infrastruktura, například zastaralé počítače, pomalé internetové připojení nebo chybějící zabezpečené servery, což by mohlo omezit spolehlivý provoz. Další výzvou je nízká digitální gramotnost části zaměstnanců obecních úřadů, která může zpomalit adaptaci na nové nástroje a vyžadovat rozsáhlé školení. U menších samospráv hrozí také riziko, že při zavedení openDesk budou i nadále využívat paralelní komerční nebo neformální nástroje (např. e-mailové služby zdarma), což by snižovalo efektivitu a bezpečnost celého řešení. V neposlední řadě může bránit hladkému zavedení i neochota měnit dlouhodobě zažité postupy, zvlášť v prostředí, kde digitalizace není vnímána jako priorita. I přes uvedená rizika se právě malé obce jeví jako subjekty, které by z openDesku mohly těžit nejvíce. Obzvláště to platí u modulu Collabora Online, kterým by mohly jednoduše nahradit v současnosti využívaný balík MS Office a pokud by se jim tento modul osvědčil, tak mohou postupně implementovat další části.
	+
	+	==== IMPLEMENTACE V RÁMCI OHA/DIA ====
	+	Jako pilotní projekt by mohlo sloužit, pokud by se v rámci omezeného prostoru buď DIA, případně pouze sekce Hlavního architekta, relevantní komponenty vyzkoušely v reálné praxi. Nabízí se například komponenta Element pro chat. V současnosti na DIA není využívána jedna konkrétní aplikace pro instant messaging a jeho funkci částečně supluje MS Teams, nicméně pro operativní domluvu s kolegy v rámci úřadu není MS Teams příliš praktický vzhledem k příliš širokému záběru (videokonference, sdílení dokumentů apod.) a poměrně nepřehlednému seskupování do týmů. V tomto ohledu se tedy Element jeví jako velmi zajímavá alternativa, kterou by bylo minimálně zajímavé otestovat, třeba i v rámci menšího týmu.
	+
	+	Za vyzkoušení by jistě stála i komponenta Collabora Online, díky které bychom mohli posoudit její reálnou využitelnost v praxi. V současnosti je v rámci DIA, ale troufám si říct i v drtivé většině české státní správy, využíván Microsoft Office, který nabízí poměrně širokou paletu možností v oblasti práce s textem, tvorbou prezentací a tabulek. Klíčovým prvkem je poté možnost online spolupráce v reálném čase na konkrétním dokumentu a s tím související průběžné ukládání rozdělané práce do cloudu. Jedná se o zásadní vlastnosti, které velmi usnadňují práci a rozhodně by bylo zajímavé zjistit, zda open source alternativa tyto funkcionality taktéž obsahuje a na kolik jsou spolehlivé. Z hlediska úředníka je kancelářský software hlavním pracovním nástrojem a jeho ergonomie a použitelnost je pro jeho produktivitu nesmírně důležitá.
	+
	+	Třetím klíčovým prvkem práce úředníka je e-mail. OpenDesk v této oblasti nabízí 3 komponenty, které by potenciálně mohly nahradit v současnosti zřejmě nejvíce využívaný Microsoft Outlook. Konkrétně se jedná o OX Calendar, OX Contacts a OX App Suite.
	+
	+	===== DOPORUČENÍ A POTENCIÁLNÍ KROKY DO BUDOUCNA =====
	+
	+	==== AKČNÍ PLÁN / ROADMAP NA DALŠÍ OBDOBÍ ====
	+	Na základě předchozí kapitoly nabízím návrh konkrétní roadmapy / akčního plánu aktivit, které by bylo možné realizovat v následujícím období.
	+
	+	Fáze 1 – Ověření v praxi (0 – 12 měsíců)
	+	Vybrat 1-2 komponenty k provedení pilotu (např. Element pro chat nebo Collabora Online pro dokumenty).
	+	Pilotně nasadit v malém rozsahu – např. v rámci jednoho odboru na DIA.
	+	Zajistit základní školení uživatelů a jednoduchý helpdesk pro řešení problémů.
	+	Sledovat základní metriky: počet aktivních uživatelů, spokojenost, technické problémy.
	+	Vyhodnotit, zda komponenty odpovídají potřebám úředníků.
	+
	+	Fáze 2 – Rozšíření pilotu (12 – 24 měsíců)
	+	Rozšířit testování na několik útvarů v rámci DIA + zapojit 1 ministerstvo či krajský úřad.
	+	Ověřit integrace s běžně využívanými systémy (e-mail, sdílení souborů, spisová služba).
	+	Připravit jednoduchou metodiku nasazení – krátký manuál s doporučeným postupem.
	+	Zajistit menší workshop pro další úřady, aby se sdílely zkušenosti.
	+
	+	Fáze 3 – Dobrovolné zapojování dalších institucí (24 – 36 měsíců)
	+	Umožnit dalším ministerstvům, ústředním správním úřadům, krajům a obcím, které mají zájem, připojit se a vyzkoušet vybrané komponenty.
	+	Stanovit a nabídnout centrální podporu hostingu (např. přes státní cloud nebo krajské datové centrum).
	+	Poskytnout školení správcům IT a vybraným uživatelům.
	+	Sledovat, jaké jsou úspory a kde se objevují hlavní bariéry.
	+
	+	Fáze 4 – Vyhodnocení a další rozhodnutí (36 a více měsíců)
	+	Vyhodnotit reálné přínosy (náklady, spokojenost, využívání).
	+	Rozhodnout, zda openDesk má smysl rozšiřovat systematicky, nebo ponechat jako doporučenou alternativu pro zájemce.
	+	Pokud se osvědčí: připravit postupný plán adopce na dalších ministerstvech a úřadech.
	+
	+	==== NAVRHOVANÉ KPI ====
	+	Pro jednotlivé fáze by bylo možné využít následující KPI, díky kterým by bylo možné sledovat a vyhodnocovat úspěšnost zavádění jednotlivých komponent a realizaci souvisejících aktivit.
	+
	+	Fáze 1 – cíl: Ověřit použitelnost vybraných komponent
	+
	+	^ KPI / metrika ^ Doporučená cílová hodnota ^ Komentář / zdroj dat ^
	+	\| Počet aktivních uživatelů v pilotu ( % ) \| ≥ 70 % pilotních uživatelů \| Pro zjištění, zda pilotní skupina skutečně platformu používá \|
	+	\| Počet dokumentů vytvořených/sdílených v Collabora Online \| min. 50 dokumentů / měsíc \| Umožňuje testovat reálnou využitelnost pro práci úředníků \|
	+	\| Počet chatových správ přes Element \| min. 20 zpráv / uživatel / měsíc \| Testování komunikace a přijetí nástroje \|
	+	\| Počet hlášených technických problémů / incidentů \| < 5 kritických incidentů \| Sledování stability platformy \|
	+	\| Spokojenost uživatelů (anketa škála 1-5 jako ve škole) \| Průměr škály max. 3 \| Vyhodnocení pozitivní první zkušenosti a základní akceptace \|
	+
	+	Fáze 2 – cíl: Testovat integrace a připravit metodiku
	+
	+	^ KPI / metrika ^ Doporučená cílová hodnota ^ Komentář / zdroj dat ^
	+	\| Počet zapojených útvarů / institucí \| ≥ 3–5 \| Rozšíření testu, ověření replikovatelnosti \|
	+	\| Počet úspěšných integrací s existujícími systémy \| ≥ 80 % plánovaných integrací \| Testování interoperability a kompatibility \|
	+	\| Podíl proškolených správců a uživatelů \| ≥ 80 % cílové skupiny \| Pro zajištění přijetí a podpory \|
	+	\| Průměrná doba řešení incidentů \| < 48 hodin \| Efektivní helpdesk pro nové nasazení \|
	+
	+	Fáze 3 – cíl: Umožnit dalším úřadům, krajům a obcím openDesk vyzkoušet
	+
	+	^ KPI / metrika ^ Doporučená cílová hodnota ^ Komentář / zdroj dat ^
	+	\| Počet úřadů/krajů/obcí, které aktivně používají openDesk \| ≥ 50 % zájemců \| Test širšího nasazení v reálných podmínkách \|
	+	\| Podíl zaměstnanců využívajících platformu (%) \| ≥ 60 % \| Aby bylo dosaženo kritické masy uživatelů \|
	+	\| Počet úspěšně nasazených modulů \| ≥ 90 % plánovaných modulů \| Kontrola úplnosti implementace \|
	+	\| Úspora nákladů na licencích a hostingu \| ≥ 20 % oproti původnímu řešení \| Měření ekonomického přínosu \|
	+
	+	Fáze 4 – cíl: Vyhodnotit přínosy a rozhodnout o dalším rozšíření
	+
	+	^ KPI / metrika ^ Doporučená cílová hodnota ^ Komentář / zdroj dat ^
	+	\| Celková spokojenost uživatelů \| ≥ 4,0 / 5 \| Dlouhodobá akceptace platformy \|
	+	\| Úspora nákladů oproti proprietárním řešením (%) \| ≥ 25 % \| Jasný ekonomický benefit pro státní správu \|
	+	\| Počet incidentů / kritických problémů \| < 2 / rok \| Stabilní a bezpečný provoz \|
	+	\| Počet institucí, které chtějí pokračovat v nasazení \| ≥ 70 % zapojených \| Ověření zájmu o další rozšíření a udržitelnost \|
	+
	+	===== ZÁVĚR =====
	+	Software s otevřeným zdrojovým kódem dnes nabízí daleko větší možnosti než v minulosti a úroveň jeho použitelnosti v rámci státní správy se v posledních letech značně zvyšuje. Státy si postupně uvědomují rizika plynoucí z přílišné závislosti na proprietárním software a jeho dodavatelích. Projekt openDesk by mohl být velmi dobře využitelný i v rámci české státní správy a aplikace ať už celého balíku, případně pouze některých komponent, by mohl mít pozitivní dopad jak na veřejné rozpočty, tak i na snížení závislosti na současných dodavatelích software. Česká státní správa by mohla být nezávislejší a zároveň by mohla být dobrým příkladem ostatním zemím v rámci EU. To by vedlo k rozšiřování komunity open source software, jejíž velikost je naprosto klíčová pro udržování softwaru při životě, jeho další rozvoj a poskytování zpětné vazby vývojářům.
	+
	+
	+	Některé kapitoly byly částečně zpracovány za využití ChatGPT.

AI / LLM v informačních systémech veřejné správy (ISVS) - vytvořeno

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-02-19T10:44:37+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== AI / LLM v informačních systémech veřejné správy (ISVS) ======

	+	{{tag>AI LLM ISVS AI_Act GDPR cloud kyberbezpecnost architektura metodika vzory}}
	+
	+	===== Účel stránky =====
	+	Tato stránka slouží jako:
	+	* obecný rámec: co je AI/LLM, kde dává smysl a kde je riziko,
	+	* metodika pro architekty a zadavatele: jak AI/LLM navrhovat a poptávat,
	+	* minimální pravidla: AI Act, ochrana osobních údajů, cloud a bezpečnost,
	+	* vzory architektur a příklady dobré/špatné praxe.
	+
	+	Cíl: Nebudovat „100× chatbot“, ale navrhovat AI jako architektonicky řízenou schopnost státu: znovupoužitelnou, auditovatelnou a právně obhajitelnou.
	+
	+	----
	+	===== Popis problematiky =====
	+
	+	==== Co je AI a co jsou LLM ====
	+	AI je soubor metod pro automatizované vyhodnocování, klasifikaci, predikci a generování výstupů.
	+	LLM (Large Language Models) jsou generativní modely pro práci s textem.
	+
	+	Důležité omezení LLM:
	+	* negarantují pravdivost (umí halucinovat),
	+	* bez řízení zdrojů mohou vyrábět „autoritu bez důkazů“,
	+	* bez správné architektury mohou ohrozit práva osob a důvěryhodnost úřadu.
	+
	+	==== Jak se AI/LLM používá ve veřejné správě (typické scénáře) ====
	+	* třídění a prioritizace e-mailů/podání,
	+	* návrhy odpovědí (asistence, ne autopilot),
	+	* chatbot/voicebot pro dotazy,
	+	* přepis hovoru do textu,
	+	* navigace napříč službami a znalostními bázemi.
	+	(Častý motiv: AI už není experiment, bez pravidel vzniká chaos a duplicity.)
	+
	+	==== Dva světy dat: veřejné informace vs registry/AIS ====
	+	Veřejné informace (zákony, metodiky, veřejné popisy služeb):
	+	* vhodné pro veřejné asistenty,
	+	* důraz na citace zdrojů a aktuálnost.
	+
	+	Registry a AIS (osobní a citlivá data, základní registry, agendové systémy):
	+	* vysoký bezpečnostní režim,
	+	* striktní role/oprávnění,
	+	* audit, logování, dohled,
	+	* vyžaduje jinou architekturu než „chatbot na webu“.
	+
	+	==== Kriticky: „Koupíme chatbota“ je často chyba ====
	+	Typické anti-patterny:
	+	* AI projekt vzniká dřív než je jasné: odkud bere data, na co navazuje, kdo odpovídá za výstup.
	+	* vzniká 100× chatbot a 100× znalostní báze, ale žádná znovupoužitelnost.
	+	* úřad utrácí za „rozhraní“, místo aby zpřístupnil služby a informace tak, aby byly použitelné i mimo jeho perimetr.
	+
	+	Poučení: Účelnější než kupovat vlastního chatbota je upravit informace a služby tak, aby byly:
	+	* dohledatelné (pro lidi i stroje),
	+	* strojově použitelné (standardizovaná rozhraní),
	+	* sdílené napříč veřejnou správou.
	+
	+	==== Obecný rámec: čtyři úrovně AI (od bezpečné po rizikovou) ====
	+	- Úroveň A: Informování a navigace nad veřejnými zdroji
	+	* nízké riziko, typicky veřejný asistent (RAG + citace).
	+	- Úroveň B: Asistence úředníkovi
	+	* střední riziko: návrhy, sumarizace, vyhledávání; člověk schvaluje.
	+	- Úroveň C: Asistence v transakci (formuláře, podání)
	+	* vyšší riziko: AI může připravit strukturovaná data, ale úkon provádí systém/uživatel podle pravidel.
	+	- Úroveň D: Ovlivnění rozhodování o právech/povinnostech
	+	* nejvyšší riziko: bez formálního řízení rizik, auditovatelnosti a lidského dohledu je to nepřijatelné.
	+
	+	==== Vzorové scénáře (co stavět a co raději nestavět) ====
	+	Doporučené scénáře (znovupoužitelné):
	+	* AI navigace v katalogu služeb / znalostní bázi státu (centrální nebo sdílená komponenta).
	+	* Interní asistent pro úředníky nad metodikami, spisy (s oddělením režimů).
	+	* Asistované vyplnění formulářů: AI převede přirozený jazyk na strukturu (např. JSON), ale validace a podání provede ISVS.
	+
	+	Nedoporučené scénáře (bez zásadního přebudování architektury):
	+	* chatbot napojený „ad-hoc“ na agendový systém bez brány oprávnění a auditů,
	+	* autopilot odpovědí občanům bez zdrojů,
	+	* posílání osobních údajů do veřejného LLM bez smluvní a technické kontroly.
	+
	+	----
	+	===== Pravidla pro využití AI/LLM v ISVS =====
	+
	+	==== Vymezení „využití AI/LLM v ISVS“ ====
	+	Za využití AI/LLM v ISVS se považuje zejména:
	+	* generování/sumarizace obsahu použitá v úřední komunikaci,
	+	* doporučení nebo návrh kroku v procesu,
	+	* automatizované třídění podání s dopadem na průběh řízení,
	+	* integrace AI do workflow ISVS (čtení/zápis, spouštění úkonů),
	+	* přístup AI k registrům/AIS.
	+
	+	Zásada: čím blíže k právům/povinnostem a registrům, tím přísnější režim.
	+
	+	==== AI Act – minimální rámec ====
	+	Povinnosti se odvíjí od rizikovosti:
	+	* zakázané praktiky (prohibited),
	+	* vysoce rizikové systémy (high-risk),
	+	* transparentnost (např. informovat, že komunikuji s AI),
	+	* požadavky na dokumentaci, řízení rizik, lidský dohled, kybernetickou bezpečnost.
	+
	+	Pravidlo pro veřejnou správu: Bez klasifikace use-case dle AI Act a bez řízení rizik projekt nepouštět do produkce.
	+
	+	==== Ochrana osobních údajů (GDPR) – minimální pravidla ====
	+	* definovat účel, zákonný titul a role (správce/zpracovatel),
	+	* minimalizovat data posílaná do AI; logy nejsou „odpad“ – jsou to data,
	+	* DPIA, pokud hrozí vysoké riziko,
	+	* zabránit tomu, aby se vstupy/výstupy používaly pro trénování mimo kontrolu úřadu,
	+	* řídit retenci, výmaz a práva subjektů údajů.
	+
	+	==== Využívání AI jako cloudové služby ====
	+
	+	Služba chatbota založeného na jazykovém modelu, stojící na vygenerování výstupu na základě vstupu od uživatele (promptu) je poskytována širokému okruhu uživatelů. Je tedy v zásadě multitenantní. Uživatelé sdílejí stejnou infrastrukturu, byť jejich konkrétní nastavení jazykového modelu (konkrétní verze, aplikace hlubokého myšlení, míra podrobnosti při odpovědi na otázku apod.) mohou být individuální.
	+
	+	Z hlediska zákona č. 365/2000 Sb., o informačních systémech veřejné správy (dále jen „zákon o ISVS“) je stěžejní, že takový model poskytování služby umělé inteligence v případě, že jí má být zajišťován provoz informačního systému veřejné správy nebo jeho část, lze podřadit pod definici uvedenou v § 2 odst. 2 písm. b) zákona o ISVS. Z pohledu zákona se tak jedná o cloud computing a poskytování služeb jazykového modelu je cloudovou službou.
	+
	+	Na využívání jazykových modelů v informačních systémech veřejné správy se tak vztahují všechna pravidla cloud computingu vyplývající z příslušných ustanovení právních předpisů.
	+
	+	Pakliže orgán veřejné správy hodlá pro zajištění provozu svého informačního systému nebo jeho části využívat služby jazykových modelů, je nutné, aby vybíral z poskytovatelů, jejichž nabídka je zapsána v katalogu cloud computingu [§ 6l odst. 1 písm. a) zákona o ISVS]. Informace, které jsou vedeny v katalogu cloud computingu stanoví § 6k zákona o ISVS.
	+
	+
	+	==== Bezpečnost a audit – zásady, bez kterých AI v ISVS nemá být ====
	+	* AI nesmí odpovídat „z hlavy“: odpovědi musí být opřené o ověřené zdroje (RAG + citace).
	+	* AI se nesmí „připojit kamkoliv“: integrace jen přes řízené rozhraní s minimálními oprávněními.
	+	* každá AI↔ISVS interakce musí být auditovatelná: logy, rekonstrukce promptu/zdrojů/verze modelu.
	+	* lidský dohled: kdo schvaluje výstup a kdy je povinný.
	+
	+	----
	+	==== Metodika pro architekty a zadavatele (životní cyklus) ====
	+
	+	=== Krok 0 – problém a přínos (ne „kupujeme AI“) ===
	+	* popsat službu/proces, který zlepšujeme, a přínos pro občana/úředníka,
	+	* definovat KPI (čas, chybovost, dostupnost informací, snížení zátěže),
	+	* ověřit, že existují a jsou kvalitní zdroje (dokumenty, katalogy, knowledge base).
	+
	+	=== Krok 1 – klasifikace dat a use-case ===
	+	* určit datové režimy: veřejné / interní / osobní / zvláštní kategorie,
	+	* určit, zda AI ovlivňuje práva a povinnosti (riziková osa),
	+	* určit roli úřadu: deployer + kdo je provider, kdo provozuje model.
	+
	+	Výstup: „karta use-case“ + návrh režimu A/B/C/D z kapitoly 1.5.
	+
	+	=== Krok 2 – rozhodnutí o provozním modelu (kde běží model a data) ===
	+	* preferovat provoz v režimu, který umožní splnit cloud a bezpečnostní požadavky,
	+	* oddělit režim veřejných informací od režimu registrů/AIS,
	+	* u osobních údajů požadovat smluvní a technické garance (logy, trénování, subdodavatelé, lokalita).
	+
	+	=== Krok 3 – návrh architektury (povinné stavební bloky) ===
	+	Povinné bloky pro generativní AI v ISVS:
	+	- AI Gateway / Orchestrátor:
	+	* centrální bod pro autentizaci, autorizaci, rate limiting, policy, audit.
	+	- Knowledge/RAG vrstva:
	+	* správa zdrojů, indexace, verze dokumentů, citace.
	+	- Konektory na ISVS:
	+	* jen přes standardizovaná API; žádné “screen scraping”.
	+	- Audit a observabilita:
	+	* logy promptů (bez citlivých dat), zdroje, verze modelu, rozhodnutí politik.
	+	- Bezpečnostní kontrolní body:
	+	* detekce PII v promptu, redakce, blokace nebezpečných dotazů, sandbox.
	+
	+	=== Krok 4 – testování a akceptace (co musí projít před produkcí) ===
	+	Minimální akceptační testy:
	+	* test halucinací na referenční sadě otázek (správnost + citace),
	+	* test PII leakage (nežádoucí vyzrazení údajů),
	+	* test prompt injection a data exfiltrace,
	+	* test robustnosti a dostupnosti (SLA),
	+	* test auditovatelnosti (rekonstrukce: z čeho vznikla odpověď).
	+
	+	=== Krok 5 – provoz a změny ===
	+	* monitoring kvality odpovědí (drift), incident management,
	+	* pravidla aktualizace znalostní báze a verzování,
	+	* pravidelné přezkumy rizik (AI Act/GDPR/bezpečnost),
	+	* governance: kdo je “owner” zdrojů, kdo schvaluje změny.
	+
	+	----
	+	==== Vzorové architektury (patterny) ====
	+
	+	=== Pattern: RAG asistent nad ověřenými zdroji (veřejné info / interní metodiky) ===
	+	<code>
	+	Uživatel
	+	\|
	+	v
	+	[UI / Portál]
	+	\|
	+	v
	+	[AI Gateway] --(policy, audit, PII redakce)--> [LLM]
	+	\|
	+	+--> [RAG/Knowledge Service] --> [Dokumenty + verze + citace]
	+	\|
	+	+--> [Logging/Monitoring]
	+	</code>
	+
	+	Vhodné pro úroveň A/B. Podmínka: správa zdrojů a verze dokumentů.
	+
	+	=== Pattern: AI asistované vyplnění formuláře (strukturovaný výstup) ===
	+	<code>
	+	Uživatel -> [UI]
	+	\|
	+	v
	+	[AI Gateway] -> [LLM] -> (JSON návrh)
	+	\| \|
	+	\| v
	+	+--> [Validace pravidly ISVS] -> [Formulář/Podání]
	+	</code>
	+
	+	Podmínka: AI nikdy neprovádí úkon sama; ISVS validuje.
	+
	+	=== Pattern: „No direct DB“ (AI nesmí přímo do registrů/AIS) ===
	+	Zásada: AI nemá přímý přístup do DB/registrů.
	+	Vždy přes:
	+	* API s minimálními oprávněními,
	+	* audit,
	+	* explicitní scope,
	+	* a ideálně human-in-the-loop pro citlivé operace.
	+
	+	----
	+	==== Požadavky do zadání / veřejné zakázky (minimální smluvní a technické klauzule) ====
	+	V zadání požadovat:
	+	* popis toku dat (vstupy, logy, trénování, subdodavatelé),
	+	* garance: zákaz použití dat pro trénování mimo účel,
	+	* lokalita a režim zpracování dat, šifrování, retention,
	+	* auditní práva a exportovatelnost (logy, knowledge base, konfigurace),
	+	* bezpečnostní testy: prompt injection, exfiltrace, PII leakage,
	+	* SLA + incident reporting,
	+	* přenositelnost a exit plan (vendor lock-in),
	+	* transparentnost vůči uživateli (označení AI, limity, citace zdrojů).
	+
	+	----
	+	==== Dobrá a špatná praxe (rychlý katalog) ====
	+
	+	=== Dobrá praxe ===
	+	* Nejprve „AI-ready informace a služby“ (nalezitelnost, strojová použitelnost), pak asistent.
	+	* Jedna sdílená znalostní báze pro společné oblasti (metodiky, služby), ne 100× kopie.
	+	* RAG s citacemi + verzování zdrojů.
	+	* AI Gateway: centrální policy, audit, PII redakce, throttling.
	+	* Human-in-the-loop tam, kde je dopad na práva/povinnosti.
	+	* Před produkcí red teaming a testy injection/exfiltrace.
	+
	+	=== Špatná praxe (anti-patterny) ===
	+	* „Koupíme chatbota“ bez analýzy zdrojů, návazností a odpovědnosti.
	+	* Odpovědi občanům bez citací zdrojů a bez přezkumu.
	+	* Přímé napojení AI na agendový systém bez brány oprávnění a auditů.
	+	* Sdílení osobních údajů s veřejnými LLM bez smluvních a technických garancí.
	+	* Ignorování regulace (AI Act, GDPR, cloud vyhlášky) – vznik compliance dluhu.
	+	* Vendor lock-in: nemožnost exportu znalostí, logů a konfigurace.
	+
	+	----
	+	===== Zdroje a související odkazy =====
	+	* AI Act (Regulation (EU) 2024/1689) – EUR-Lex
	+	* Transparency obligations (AI Act – čl. 50) – EU zdroj
	+	* Guidelines k zakázaným praktikám dle AI Act – Evropská komise
	+	* Generativní AI a ochrana osobních údajů – evropská guidance (EDPS/EDPB)
	+	* Regulace cloud computingu v ČR (ZoISVS/ZKB, bezpečnostní úrovně, katalog) – metodické materiály NÚKIB
	+	* Interní podklady OHA/DIA k AI ve veřejné správě (use-cases, rizika fragmentace)
	+
	+
	+

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

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2026-01-30T09:14:03+00:00

2026/01/30 08:55		aktuální
Řádek 66:		Řádek 66:
	^Kategorie ^Název služby ^		^Kategorie ^Název služby ^
	\| Služby založené na Registru obyvatel\| E03_robCtiAifo \|		\| Služby založené na Registru obyvatel\| E03_robCtiAifo \|
-	\| :::\| E04 - robAutentizace \|	+	\| Služby založené na Registru obyvatel\| E04 - robAutentizace \|
-	\| :::\| E05_robCtiPodleUdaju \|	+	\| Služby založené na Registru obyvatel\| E05_robCtiPodleUdaju \|
-	\| :::\| E06 - robVymazObyvatele \|	+	\| Služby založené na Registru obyvatel\| E06 - robVymazObyvatele \|
-	\| :::\| E07_robCtiZmeny \|	+	\| Služby založené na Registru obyvatel\| E07_robCtiZmeny \|
-	\| :::\| E08_robCtiHromadneAifo \|	+	\| Služby založené na Registru obyvatel\| E08_robCtiHromadneAifo \|
-	\| :::\| E15 - robCtiEditora \|	+	\| Služby založené na Registru obyvatel\| E15 - robCtiEditora \|
-	\| :::\| E103 - robCtiZmenyZaloz \|	+	\| Služby založené na Registru obyvatel\| E103 - robCtiZmenyZaloz \|
-	\| :::\| E154_robVypisVyuzitiPoskytnuti \|	+	\| Služby založené na Registru obyvatel\| E154_robVypisVyuzitiPoskytnuti \|
-	\| :::\| E274_robVlozObyvatele2 \|	+	\| Služby založené na Registru obyvatel\| E274_robVlozObyvatele2 \|
-	\| :::\| E275_robZmenObyvatele2 \|	+	\| Služby založené na Registru obyvatel\| E275_robZmenObyvatele2 \|
-	\| :::\| E276_robCtiAifo2 \|	+	\| Služby založené na Registru obyvatel\| E276_robCtiAifo2 \|
-	\| :::\| E277_robCtiHromadneAifo2 \|	+	\| Služby založené na Registru obyvatel\| E277_robCtiHromadneAifo2 \|
-	\| :::\| E278_robCtiPodleUdaju2_ \|	+	\| Služby založené na Registru obyvatel\| E278_robCtiPodleUdaju2_ \|
-	\| :::\| E279_robOverHromadneAifo2 \|	+	\| Služby založené na Registru obyvatel\| E279_robOverHromadneAifo2 \|
	\| Služby založené na Registru osob\| E16_rosPridelIco \|		\| Služby založené na Registru osob\| E16_rosPridelIco \|
-	\| :::\| E17 - rosPridelIcp \|	+	\| Služby založené na Registru osob\| E17 - rosPridelIcp \|
-	\| :::\| E23 - rosZapisDatovouSchranku \|	+	\| Služby založené na Registru osob \| E23 - rosZapisDatovouSchranku \|
-	\| :::\| E24 - rosVymazOsobu \|	+	\| Služby založené na Registru osob \| E24 - rosVymazOsobu \|
-	\| :::\| E25 - rosVlozProvozovnu \|	+	\| Služby založené na Registru osob \| E25 - rosVlozProvozovnu \|
-	\| :::\| E26_rosZmenProvozovnu \|	+	\| Služby založené na Registru osob \| E26_rosZmenProvozovnu \|
-	\| :::\| E27 - rosVymazProvozovnu \|	+	\| Služby založené na Registru osob \| E27 - rosVymazProvozovnu \|
-	\| :::\| E28 - rosCtiZmeny \|	+	\| Služby založené na Registru osob \| E28 - rosCtiZmeny \|
-	\| :::\| E31 - rosCtiSeznamEditoru \|	+	\| Služby založené na Registru osob \| E31 - rosCtiSeznamEditoru \|
-	\| :::\| E253 -_rosVlozOsobu2 \|	+	\| Služby založené na Registru osob \| E253 -_rosVlozOsobu2 \|
-	\| :::\| E254 - rosZmenOsobu2 \|	+	\| Služby založené na Registru osob \| E254 - rosZmenOsobu2 \|
-	\| :::\| E255 - rosZapisPravniStav2 \|	+	\| Služby založené na Registru osob \| E255 - rosZapisPravniStav2 \|
-	\| :::\| E256_rosCtiIco2 \|	+	\| Služby založené na Registru osob \| E256_rosCtiIco2 \|
-	\| :::\| E257_rosCtiAifo2 \|	+	\| Služby založené na Registru osob \| E257_rosCtiAifo2 \|
-	\| :::\| E258_rosCtiSeznamIco2 \|	+	\| Služby založené na Registru osob \| E258_rosCtiSeznamIco2 \|
-	\| :::\| E259_rosCtiPodleUdaju2 \|	+	\| Služby založené na Registru osob \| E259_rosCtiPodleUdaju2 \|
-	\| :::\| E273_rosZapisKontaktniUdaje \|	+	\| Služby založené na Registru osob \| E273_rosZapisKontaktniUdaje \|
	\| Služby založené na Registru územní identifikace, adres a nemovitostí\| E37 - ruianVyhledejAdresu \|		\| Služby založené na Registru územní identifikace, adres a nemovitostí\| E37 - ruianVyhledejAdresu \|
-	\| :::\| E38 - ruianCtiSeznamZmen \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E38 - ruianCtiSeznamZmen \|
-	\| :::\| E39 - ruianSouboryZmen \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E39 - ruianSouboryZmen \|
-	\| :::\| E40 - ruianSouboryDat \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E40 - ruianSouboryDat \|
-	\| :::\| E170 - ruianVyhledejSeznamAMVO \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E170 - ruianVyhledejSeznamAMVO \|
-	\| :::\| E184 - ruianCtiSeznamAdres \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E184 - ruianCtiSeznamAdres \|
-	\| :::\| E185 ruianCtiSeznamZmenAD \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E185 ruianCtiSeznamZmenAD \|
-	\| :::\| E249a_ruianVyhledejPrvekAdresniMisto2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249a_ruianVyhledejPrvekAdresniMisto2 \|
-	\| :::\| E249c_ruianVyhledejPrvekCastObce2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249c_ruianVyhledejPrvekCastObce2 \|
-	\| :::\| E249d_ruianVyhledejPrvekKatastralniUzemi2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249d_ruianVyhledejPrvekKatastralniUzemi2 \|
-	\| :::\| E249f_ruianVyhledejPrvekMomc2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249f_ruianVyhledejPrvekMomc2 \|
-	\| :::\| E249g_ruianVyhledejPrvekObvodPrahy2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249g_ruianVyhledejPrvekObvodPrahy2 \|
-	\| :::\| E249h_ruianVyhledejPrvekObec2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249h_ruianVyhledejPrvekObec2 \|
-	\| :::\| E249i_ruianVyhledejPrvekOkres2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249i_ruianVyhledejPrvekOkres2 \|
-	\| :::\| E249j_ruianVyhledejPrvekOrp2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249j_ruianVyhledejPrvekOrp2 \|
-	\| :::\| E249k_ruianVyhledejPrvekParcela2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249k_ruianVyhledejPrvekParcela2 \|
-	\| :::\| E249l_ruianVyhledejPrvekPou2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249l_ruianVyhledejPrvekPou2 \|
-	\| :::\| E249m_ruianVyhledejPrvekRegionSoudrznosti2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249m_ruianVyhledejPrvekRegionSoudrznosti2 \|
-	\| :::\| E249n_ruianVyhledejPrvekSpravniObvod2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249n_ruianVyhledejPrvekSpravniObvod2 \|
-	\| :::\| E249p_ruianVyhledejPrvekStavebniObjekt2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249p_ruianVyhledejPrvekStavebniObjekt2 \|
-	\| :::\| E249q_ruianVyhledejPrvekUlice2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249q_ruianVyhledejPrvekUlice2 \|
-	\| :::\| E249r_ruianVyhledejPrvekVusc2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249r_ruianVyhledejPrvekVusc2 \|
-	\| :::\| E249s_ruianVyhledejPrvekZsj2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249s_ruianVyhledejPrvekZsj2 \|
-	\| :::\| E249t_ruianVyhledejPrvekVolebniOkrsek2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E249t_ruianVyhledejPrvekVolebniOkrsek2 \|
-	\| :::\| E250a_ruianCtiPrvekAdresniMisto2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250a_ruianCtiPrvekAdresniMisto2 \|
-	\| :::\| E250c_ruianCtiPrvekCastObce2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250c_ruianCtiPrvekCastObce2 \|
-	\| :::\| E250d_ruianCtiPrvekKatastralniUzemi2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250d_ruianCtiPrvekKatastralniUzemi2 \|
-	\| :::\| E250f_ruianCtiPrvekMomc2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250f_ruianCtiPrvekMomc2 \|
-	\| :::\| E250g_ruianCtiPrvekObvodPrahy2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250g_ruianCtiPrvekObvodPrahy2 \|
-	\| :::\| E250h_ruianCtiPrvekObec2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250h_ruianCtiPrvekObec2 \|
-	\| :::\| E250i_ruianCtiPrvekOkres2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250i_ruianCtiPrvekOkres2 \|
-	\| :::\| E250j_ruianCtiPrvekOrp2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250j_ruianCtiPrvekOrp2 \|
-	\| :::\| E250k_ruianCtiPrvekParcela2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250k_ruianCtiPrvekParcela2 \|
-	\| :::\| E250l_ruianCtiPrvekPou2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250l_ruianCtiPrvekPou2 \|
-	\| :::\| E250m_ruianCtiPrvekRegionSoudrznosti2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250m_ruianCtiPrvekRegionSoudrznosti2 \|
-	\| :::\| E250n_ruianCtiPrvekSpravniObvod2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250n_ruianCtiPrvekSpravniObvod2 \|
-	\| :::\| E250o_ruianCtiPrvekStat2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250o_ruianCtiPrvekStat2 \|
-	\| :::\| E250p - ruianCtiPrvekStavebniObjekt2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250p - ruianCtiPrvekStavebniObjekt2 \|
-	\| :::\| E250q_ruianCtiPrvekUlice2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250q_ruianCtiPrvekUlice2 \|
-	\| :::\| E250r_ruianCtiPrvekVusc2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250r_ruianCtiPrvekVusc2 \|
-	\| :::\| E250s_ruianCtiPrvekZsj2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250s_ruianCtiPrvekZsj2 \|
-	\| :::\| E250t_ruianCtiPrvekVolebniOkrsek2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E250t_ruianCtiPrvekVolebniOkrsek2 \|
-	\| :::\| E251_ruianCtiAdresu2 \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E251_ruianCtiAdresu2 \|
-	\| :::\| E281_ruianVyhledejUup \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E281_ruianVyhledejUup \|
-	\| :::\| E282_ruianVyhledejUupEd \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E282_ruianVyhledejUupEd \|
-	\| :::\| E283_ruianCtiUup \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E283_ruianCtiUup \|
-	\| :::\| E284_ruianCtiUupEd \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E284_ruianCtiUupEd \|
-	\| :::\| E314_RuianCtiSeznamZmenNespravnost \|	+	\| Služby založené na Registru územní identifikace, adres a nemovitostí \| E314_RuianCtiSeznamZmenNespravnost \|
	\| Služby založené na ORG\| E45 - orgPrihlasAifo \|		\| Služby založené na ORG\| E45 - orgPrihlasAifo \|
-	\| :::\| E46 - orgOdhlasAifo \|	+	\| Služby založené na ORG \| E46 - orgOdhlasAifo \|
-	\| :::\| E69 - orgSpojZIFO \|	+	\| Služby založené na ORG \| E69 - orgSpojZIFO \|
-	\| :::\| E70 - orgRozdelZIFO \|	+	\| Služby založené na ORG \| E70 - orgRozdelZIFO \|
-	\| :::\| E71 - orgZkontrolujAIFO \|	+	\| Služby založené na ORG \| E71 - orgZkontrolujAIFO \|
-	\| :::\| E75 - orgCtiDavkuAIFO \|	+	\| Služby založené na ORG \| E75 - orgCtiDavkuAIFO \|
-	\| :::\| E76 - orgPredchudciAIFO \|	+	\| Služby založené na ORG \| E76 - orgPredchudciAIFO \|
-	\| :::\| E77 - orgRodokmenAIFO \|	+	\| Služby založené na ORG \| E77 - orgRodokmenAIFO \|
-	\| :::\| E78 - orgCtiZmenyAIFO \|	+	\| Služby založené na ORG \| E78 - orgCtiZmenyAIFO \|
-	\| :::\| E95 - orgZalozAIFOPE \|	+	\| Služby založené na ORG \| E95 - orgZalozAIFOPE \|
-	\| :::\| E199 - orgZjistiAis \|	+	\| Služby založené na ORG \| E199 - orgZjistiAis \|
	\| Služby založené na informačním systému základních registrů\| E62 - iszrReklamujUdajeRob \|		\| Služby založené na informačním systému základních registrů\| E62 - iszrReklamujUdajeRob \|
-	\| :::\| E97 - iszrCtiSeznamCiselniku \|	+	\| Služby založené na informačním systému základních registrů \| E97 - iszrCtiSeznamCiselniku \|
-	\| :::\| E99 - iszrAsyncVypisFronty \|	+	\| Služby založené na informačním systému základních registrů \| E99 - iszrAsyncVypisFronty \|
-	\| :::\| E100 - iszrAsyncOdpovedZFronty \|	+	\| Služby založené na informačním systému základních registrů \| E100 - iszrAsyncOdpovedZFronty \|
-	\| :::\| E101 - iszrAsyncSmazatFrontu \|	+	\| Služby založené na informačním systému základních registrů \| E101 - iszrAsyncSmazatFrontu \|
-	\| :::\| E164 - iszrProbe \|	+	\| Služby založené na informačním systému základních registrů \| E164 - iszrProbe \|
-	\| :::\| E166 - iszrAutentizaceAis \|	+	\| Služby založené na informačním systému základních registrů \| E166 - iszrAutentizaceAis \|
-	\| :::\| E175 - iszrUlozMapaAifo \|	+	\| Služby založené na informačním systému základních registrů \| E175 - iszrUlozMapaAifo \|
-	\| :::\| E176 - iszrPodejMapaAifo \|	+	\| Služby založené na informačním systému základních registrů \| E176 - iszrPodejMapaAifo \|
-	\| :::\| E177 - iszrCtiReklamaci \|	+	\| Služby založené na informačním systému základních registrů \| E177 - iszrCtiReklamaci \|
-	\| :::\| E227 - iszrVypisOpravneniPolozky \|	+	\| Služby založené na informačním systému základních registrů \| E227 - iszrVypisOpravneniPolozky \|
-	\| :::\| E311 – iszrReklamujUdajeRos2 \|	+	\| Služby založené na informačním systému základních registrů \| E311 – iszrReklamujUdajeRos2 \|
-	\| :::\| E344_iszrRobCtiPodleCertifikatu \|	+	\| Služby založené na informačním systému základních registrů \| E344_iszrRobCtiPodleCertifikatu \|
-	\| :::\| E345_iszrOverCertifikat \|	+	\| Služby založené na informačním systému základních registrů \| E345_iszrOverCertifikat \|
	\| Služby založené na Registru práv a povinností\| E105 - rppCtiZmeny \|		\| Služby založené na Registru práv a povinností\| E105 - rppCtiZmeny \|
-	\| :::\| E106 - rppVypisSeznamAgend \|	+	\| Služby založené na Registru práv a povinností \| E106 - rppVypisSeznamAgend \|
-	\| :::\| E115 - rppVlozRozhodnuti \|	+	\| Služby založené na Registru práv a povinností \| E115 - rppVlozRozhodnuti \|
-	\| :::\| E135 - rppVypisSeznamSluzeb \|	+	\| Služby založené na Registru práv a povinností \| E135 - rppVypisSeznamSluzeb \|
-	\| :::\| E136 - rppVypisSluzbu \|	+	\| Služby založené na Registru práv a povinností \| E136 - rppVypisSluzbu \|
-	\| :::\| E140 - rppVypisSeznamSLA \|	+	\| Služby založené na Registru práv a povinností \| E140 - rppVypisSeznamSLA \|
-	\| :::\| E207_rppVypisSeznamZmenOpravneni \|	+	\| Služby založené na Registru práv a povinností \| E207_rppVypisSeznamZmenOpravneni \|
-	\| :::\| E208_rppVypisOpravneniKonzumace \|	+	\| Služby založené na Registru práv a povinností \| E208_rppVypisOpravneniKonzumace \|
-	\| :::\| E209_rppVypisOpravneniPoskytovani \|	+	\| Služby založené na Registru práv a povinností \| E209_rppVypisOpravneniPoskytovani \|
-	\| :::\| E212_rppVlozOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E212_rppVlozOvmSpuu \|
-	\| :::\| E213_rppZmenOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E213_rppZmenOvmSpuu \|
-	\| :::\| E214_rppVypisSeznamKategoriiOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E214_rppVypisSeznamKategoriiOvmSpuu \|
-	\| :::\| E216_rppVlozKategoriiOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E216_rppVlozKategoriiOvmSpuu \|
-	\| :::\| E217_rppZmenKategoriiOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E217_rppZmenKategoriiOvmSpuu \|
-	\| :::\| E218_rppCtiZmenyOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E218_rppCtiZmenyOvmSpuu \|
-	\| :::\| E219 - rppCtiEditoraOvmSpuu \|	+	\| Služby založené na Registru práv a povinností \| E219 - rppCtiEditoraOvmSpuu \|
-	\| :::\| E220_rppZapisDatovouSchranku \|	+	\| Služby založené na Registru práv a povinností \| E220_rppZapisDatovouSchranku \|
-	\| :::\| E262_rppCtiZmenySluzebVs \|	+	\| Služby založené na Registru práv a povinností \| E262_rppCtiZmenySluzebVs \|
-	\| :::\| E264_rppVypisSeznamSluzebVs \|	+	\| Služby založené na Registru práv a povinností \| E264_rppVypisSeznamSluzebVs \|
-	\| :::\| E290 - rppCtiZmenyOpravneni \|	+	\| Služby založené na Registru práv a povinností \| E290 - rppCtiZmenyOpravneni \|
-	\| :::\| E291 - rppCtiZmenyAisAgenda \|	+	\| Služby založené na Registru práv a povinností \| E291 - rppCtiZmenyAisAgenda \|
-	\| :::\| E292_rppCtiZmenyUdajuAgendy \|	+	\| Služby založené na Registru práv a povinností \| E292_rppCtiZmenyUdajuAgendy \|
-	\| :::\| E293_rppVypisAgendu6_ \|	+	\| Služby založené na Registru práv a povinností \| E293_rppVypisAgendu6_ \|
-	\| :::\| E294_rppVypisKategoriiOvmSpuu2 \|	+	\| Služby založené na Registru práv a povinností \| E294_rppVypisKategoriiOvmSpuu2 \|
-	\| :::\| E295_rppVypisOpravneni2 \|	+	\| Služby založené na Registru práv a povinností \| E295_rppVypisOpravneni2 \|
-	\| :::\| E296_rppVypisOvmSpuu3 \|	+	\| Služby založené na Registru práv a povinností \| E296_rppVypisOvmSpuu3 \|
-	\| :::\| E297_rppVypisPusobnostOvm6 \|	+	\| Služby založené na Registru práv a povinností \| E297_rppVypisPusobnostOvm6 \|
-	\| :::\| E298_rppVypisSeznamPusobnostiOvm3 \|	+	\| Služby založené na Registru práv a povinností \| E298_rppVypisSeznamPusobnostiOvm3 \|
-	\| :::\| E299_rppVypisSeznamUdajuAgendy2 \|	+	\| Služby založené na Registru práv a povinností \| E299_rppVypisSeznamUdajuAgendy2 \|
-	\| :::\| E300_rppVypisSluzbuVs2 \|	+	\| Služby založené na Registru práv a povinností \| E300_rppVypisSluzbuVs2 \|
-	\| :::\| E301_rppVypisSeznamOpravneni \|	+	\| Služby založené na Registru práv a povinností \| E301_rppVypisSeznamOpravneni \|
-	\| :::\| E302_rppVypisUdajAgendy \|	+	\| Služby založené na Registru práv a povinností \| E302_rppVypisUdajAgendy \|
-	\| :::\| E303_rppVypisSeznamAisAgenda \|	+	\| Služby založené na Registru práv a povinností \| E303_rppVypisSeznamAisAgenda \|
-	\| :::\| E304_rppVypisSeznamOvmSpuu2 \|	+	\| Služby založené na Registru práv a povinností \| E304_rppVypisSeznamOvmSpuu2 \|
-	\| :::\| E305_rppVypisOpravneniRidici \|	+	\| Služby založené na Registru práv a povinností \| E305_rppVypisOpravneniRidici \|
-	\| :::\| E324_rppVypisAgendu7 \|	+	\| Služby založené na Registru práv a povinností \| E324_rppVypisAgendu7 \|
-	\| :::\| E325_rppVypisKategoriiOvmSpuu3 \|	+	\| Služby založené na Registru práv a povinností \| E325_rppVypisKategoriiOvmSpuu3 \|
-	\| :::\| E326_rppVypisOpravneni3 \|	+	\| Služby založené na Registru práv a povinností \| E326_rppVypisOpravneni3 \|
-	\| :::\| E327_rppVypisOvmSpuu4 \|	+	\| Služby založené na Registru práv a povinností \| E327_rppVypisOvmSpuu4 \|
-	\| :::\| E328_rppVypisSluzbuVs3 \|	+	\| Služby založené na Registru práv a povinností \| E328_rppVypisSluzbuVs3 \|
-	\| :::\| E329_rppVypisUdajAgendy2 \|	+	\| Služby založené na Registru práv a povinností \| E329_rppVypisUdajAgendy2 \|
-	\| :::\| E330_rppVypisOpravneniKonzumace2 \|	+	\| Služby založené na Registru práv a povinností \| E330_rppVypisOpravneniKonzumace2 \|
-	\| :::\| E331_rppVypisOpravneniPoskytovani2 \|	+	\| Služby založené na Registru práv a povinností \| E331_rppVypisOpravneniPoskytovani2 \|
-	\| :::\| E333_rppRezaVypisVyuzitiOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E333_rppRezaVypisVyuzitiOpravneniKZastupovani \|
-	\| :::\| E334_rppRezaVypisVedeneOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E334_rppRezaVypisVedeneOpravneniKZastupovani \|
-	\| :::\| E335_rppRezaOverOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E335_rppRezaOverOpravneniKZastupovani \|
-	\| :::\| E336_rppRezaCtiOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E336_rppRezaCtiOpravneniKZastupovani \|
-	\| :::\| E337_rppRezaPoskytniZastupujici \|	+	\| Služby založené na Registru práv a povinností \| E337_rppRezaPoskytniZastupujici \|
-	\| :::\| E338_rppRezaPoskytniZastupovane \|	+	\| Služby založené na Registru práv a povinností \| E338_rppRezaPoskytniZastupovane \|
-	\| :::\| E339_rppRezaCtiZmenyOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E339_rppRezaCtiZmenyOpravneniKZastupovani \|
-	\| :::\| E340_RppRezaCtiSeznamOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E340_RppRezaCtiSeznamOpravneniKZastupovani \|
-	\| :::\| E341_rppRezaCtiDetailOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E341_rppRezaCtiDetailOpravneniKZastupovani \|
-	\| :::\| E342_rppRezaZapisOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E342_rppRezaZapisOpravneniKZastupovani \|
-	\| :::\| E343_rppRezaUkonciOpravneniKZastupovani \|	+	\| Služby založené na Registru práv a povinností \| E343_rppRezaUkonciOpravneniKZastupovani \|
	\| Služby založené na Agendovém informačním systému evidence obyvatel\| E158 - aiseoZtotozneni \|		\| Služby založené na Agendovém informačním systému evidence obyvatel\| E158 - aiseoZtotozneni \|
-	\| :::\| E171 - aiseoCtiAifo2 \|	+	\| Služby založené na Agendovém informačním systému evidence obyvatel \| E171 - aiseoCtiAifo2 \|
-	\| :::\| E172_aiseoCtiPodleUdaju2 \|	+	\| Služby založené na Agendovém informačním systému evidence obyvatel \| E172_aiseoCtiPodleUdaju2 \|
	\| Služby založené na agendovém informačním systému cizinců\| E173 - aiscCtiAifo2 \|		\| Služby založené na agendovém informačním systému cizinců\| E173 - aiscCtiAifo2 \|
-	\| :::\| E174 - aiscCtiPodleUdaju2 \|	+	\| Služby založené na agendovém informačním systému cizinců \| E174 - aiscCtiPodleUdaju2 \|
	\| Služby založené na Agendovém informačním systému RPP Působnostní\| E237 – aispCtiZmenyIs \|		\| Služby založené na Agendovém informačním systému RPP Působnostní\| E237 – aispCtiZmenyIs \|
-	\| :::\| E265_aispVypisSeznamIsV2 \|	+	\| Služby založené na Agendovém informačním systému RPP Působnostní \| E265_aispVypisSeznamIsV2 \|
-	\| :::\| E312 – aispSeznamIsProIszr2 \|	+	\| Služby založené na Agendovém informačním systému RPP Působnostní \| E312 – aispSeznamIsProIszr2 \|
-	\| :::\| E266_aispVypisDetailIs2 \|	+	\| Služby založené na Agendovém informačním systému RPP Působnostní \| E266_aispVypisDetailIs2 \|
-	\| Služby založené na agenfovém informačním systému vyrozumívací\| E308_aisvEvidujZmenu \|	+	\| Služby založené na agendovém informačním systému vyrozumívací\| E308_aisvEvidujZmenu \|
-	\| :::\| E315_aisvPrihlasId \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E315_aisvPrihlasId \|
-	\| :::\| E316_aisvOdhlasId \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E316_aisvOdhlasId \|
-	\| :::\| E317_aisvCtiZmeny \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E317_aisvCtiZmeny \|
-	\| :::\| E318_aisvCtiZmenyId \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E318_aisvCtiZmenyId \|
-	\| :::\| E319_aisvCtiZmenyZalozAifo \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E319_aisvCtiZmenyZalozAifo \|
-	\| :::\| E320_aisvCtiZmenyZalozIco \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E320_aisvCtiZmenyZalozIco \|
-	\| :::\| E321_aisvCtiCiselnikUdaju \|	+	\| Služby založené na agendovém informačním systému vyrozumívací \| E321_aisvCtiCiselnikUdaju \|
	\| Služby založené na Evidenci občanských průkazů\| E188 - eopCtiAifo \|		\| Služby založené na Evidenci občanských průkazů\| E188 - eopCtiAifo \|
-	\| :::\| E191 - eopCtiHromadneAifo \|	+	\| Služby založené na Evidenci občanských průkazů \| E191 - eopCtiHromadneAifo \|
-	\| :::\| E194 - eopCtiPodleUdaju \|	+	\| Služby založené na Evidenci občanských průkazů \| E194 - eopCtiPodleUdaju \|
	\| Služby založené na Evidenci cestovních dokladů\| E189 - ecdCtiAifo \|		\| Služby založené na Evidenci cestovních dokladů\| E189 - ecdCtiAifo \|
-	\| :::\| E192 - ecdCtiHromadneAifo \|	+	\| Služby založené na Evidenci cestovních dokladů \| E192 - ecdCtiHromadneAifo \|
-	\| :::\| E195 - ecdCtiPodleUdaju \|	+	\| Služby založené na Evidenci cestovních dokladů \| E195 - ecdCtiPodleUdaju \|
	\| Služby Mediadata (fotografie a podpisy)\| E197 - agendaMediaDataCtiAifo \|		\| Služby Mediadata (fotografie a podpisy)\| E197 - agendaMediaDataCtiAifo \|
-	\| :::\| E198 - agendaMediaDataCtiPodleUdaju \|	+	\| Služby Mediadata (fotografie a podpisy) \| E198 - agendaMediaDataCtiPodleUdaju \|
	\| Služby založené na eIdentitě\| E226 - eidentitaCtiAifo \|		\| Služby založené na eIdentitě\| E226 - eidentitaCtiAifo \|
-	\| :::\| E306_eidentitaCtiProstredekAifo \|	+	\| Služby založené na eIdentitě \| E306_eidentitaCtiProstredekAifo \|
	\| Služby založené na Informačním systému katastru nemovitostí\| E94 - isknReklamujPrvek \|		\| Služby založené na Informačním systému katastru nemovitostí\| E94 - isknReklamujPrvek \|
-	\| :::\| E238 – isknCtiVlastniky2 \|	+	\| Služby založené na Informačním systému katastru nemovitostí \| E238 – isknCtiVlastniky2 \|
-	\| :::\| E242d – isknCtiPrvekKDatuKatastralniUzemi \|	+	\| Služby založené na Informačním systému katastru nemovitostí \| E242d – isknCtiPrvekKDatuKatastralniUzemi \|
-	\| :::\| E242k – isknCtiPrvekKDatuParcela \|	+	\| Služby založené na Informačním systému katastru nemovitostí \| E242k – isknCtiPrvekKDatuParcela \|
-	\| Služby založené na Infomračním systému územní identifikace\| E53 - isuiReklamujPrvek \|	+	\| Služby založené na Informačním systému územní identifikace\| E53 - isuiReklamujPrvek \|
-	\| :::\| E234_isuiVyhledejParceluGP \|	+	\| Služby založené na Informačním systému územní identifikace \| E234_isuiVyhledejParceluGP \|
-	\| :::\| E252a_isuiCtiPrvekAdresniMistoKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252a_isuiCtiPrvekAdresniMistoKDatu2 \|
-	\| :::\| E252c_isuiCtiPrvekCastObceKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252c_isuiCtiPrvekCastObceKDatu2 \|
-	\| :::\| E252f_isuiCtiPrvekMomcKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252f_isuiCtiPrvekMomcKDatu2 \|
-	\| :::\| E252g_isuiCtiPrvekObvodPrahyKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252g_isuiCtiPrvekObvodPrahyKDatu2 \|
-	\| :::\| E252h_isuiCtiPrvekObecKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252h_isuiCtiPrvekObecKDatu2 \|
-	\| :::\| E252i_isuiCtiPrvekOkresKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252i_isuiCtiPrvekOkresKDatu2 \|
-	\| :::\| E252j_isuiCtiPrvekOrpKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252j_isuiCtiPrvekOrpKDatu2 \|
-	\| :::\| E252l_isuiCtiPrvekPouKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252l_isuiCtiPrvekPouKDatu2 \|
-	\| :::\| E252m_isuiCtiPrvekRegionSoudrznostiKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252m_isuiCtiPrvekRegionSoudrznostiKDatu2 \|
-	\| :::\| E252n_isuiCtiPrvekSpravniObvodKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252n_isuiCtiPrvekSpravniObvodKDatu2 \|
-	\| :::\| E252o_isuiCtiPrvekStatKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252o_isuiCtiPrvekStatKDatu2 \|
-	\| :::\| E252p - isuiCtiPrvekStavebniObjektKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252p - isuiCtiPrvekStavebniObjektKDatu2 \|
-	\| :::\| E252q_isuiCtiPrvekUliceKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252q_isuiCtiPrvekUliceKDatu2 \|
-	\| :::\| E252r_isuiCtiPrvekVuscKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252r_isuiCtiPrvekVuscKDatu2 \|
-	\| :::\| E252s_isuiCtiPrvekZsjKDatu2 \|	+	\| Služby založené na Informačním systému územní identifikace \| E252s_isuiCtiPrvekZsjKDatu2 \|
-	\| :::\| E285_isuiCtiUupKDatu \|	+	\| Služby založené na Informačním systému územní identifikace \| E285_isuiCtiUupKDatu \|
-	\| :::\| E286_isuiCtiStavReklamace \|	+	\| Služby založené na Informačním systému územní identifikace \| E286_isuiCtiStavReklamace \|
-	\| :::\| E313_IsuiCtiHraniceZsj \|	+	\| Služby založené na Informačním systému územní identifikace \| E313_IsuiCtiHraniceZsj \|
-	\| :::\| E332 - IsknCtiVlastnictviSNemovitostmi \|	+	\| Služby založené na Informačním systému územní identifikace \| E332 - IsknCtiVlastnictviSNemovitostmi \|
-	\| :::\| E356_isuiCtiStavebniObjektCsu \|	+	\| Služby založené na Informačním systému územní identifikace \| E356_isuiCtiStavebniObjektCsu \|
-	</datateble>	+	</datatable>


	{{tag>ISZR "Informační systém základních registrů" "Propojený datový fond" "Referenční rozhraní" "Základní registry" "Funkční celek" "eGON" "eGON služby"}}		{{tag>ISZR "Informační systém základních registrů" "Propojený datový fond" "Referenční rozhraní" "Základní registry" "Funkční celek" "eGON" "eGON služby"}}

Registr obyvatel

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-12-12T16:08:46+00:00

2021/07/29 07:36		aktuální
Řádek 1:		Řádek 1:
	======Registr obyvatel======		======Registr obyvatel======

-	Registr obyvatel je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje referenční údaje o fyzických osobách. Správcem Registru obyvatel je Ministerstvo vnitra. Primárními editory jsou jednotlivé OVM prostřednictvím [[nap:iseo\|Informačního systému evidence obyvatel]] a [[nap:cis\|Agendového informačního systému cizinců]].	+	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 Digitální a informační agentura. Primárními editory jsou jednotlivé OVM prostřednictvím [[nap:iseo\|Informačního systému evidence obyvatel]] a [[nap:cis\|Agendového informačního systému cizinců]].

	Subjekty údajů vedených v registru obyvatel jsou		Subjekty údajů vedených v registru obyvatel jsou
Řádek 45:		Řádek 45:
	* U datových schránek je editorem Ministerstvo vnitra jako správce [[nap:elektronicke_ukony_a_dorucovani\|Informačního systému datových schránek]].		* U datových schránek je editorem Ministerstvo vnitra jako správce [[nap:elektronicke_ukony_a_dorucovani\|Informačního systému datových schránek]].
	* Editorem provozních údajů je Správa základních registrů prostřednictvím [[nap:iszr\|informačního systému základních registrů]]		* Editorem provozních údajů je Správa základních registrů prostřednictvím [[nap:iszr\|informačního systému základních registrů]]
		+
		+	===== Typy dokladů vedených v registru obyvatel =====
		+
		+	V registru obyvatel se vedou pouze doklady vydané v České republice:
		+
		+	^Zkratka dokladu^Název dokladu^
		+	\|ID \| občanský průkaz\|
		+	\|OP \| občanský průkaz bez strojově čitelných údajů\|
		+	\|P \| cestovní pas\|
		+	\|CA \| cestovní průkaz\|
		+	\|IR \| povolení k pobytu (plastová karta)\|
		+	\|VS \| vízový štítek\|
		+	\|PS \| pobytový štítek\|
		+	\|IX \| povolení k pobytu (knížka)\|
		+	\|IE \| potvrzení o přechodném pobytu/osvědčení o registraci\|
		+
		+	Doklady vydané jiným státem se v ROB nevedou. Na odkazu [[https://szrcr.cz/cs/sluzby/spravci-a-vyvojari/vyvojari-agendovych-informacnich-systemu\|Digitální a informační agentura - Vývojáři agendových informačních systémů]] je ke stažení soubor s XSD popisy datových typů.

	{{tag>ROB "Registr obyvatel" "Základní registry" "Funkční celek"}}		{{tag>ROB "Registr obyvatel" "Základní registry" "Funkční celek"}}

Oprávnění k zastupování v elektronické komunikaci - [Závěrečná společná pravidla pro oprávnění k zastupování v elektronické komunikaci]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-11-11T15:36:24+00:00

Identifikace klientů veřejné správy - [Elektronická identifikace]

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-11-11T15:36:16+00:00

2021/04/29 13:20		aktuální
Řádek 29:		Řádek 29:

	Podporu celého procesu elektronické identifikace prostřednictvím kvalifikovaného systému elektronické identifikace je vytvořena platforma Národní identitní autority (také jako NIA), která vykonává činnosti Národního bodu dle [[https://www.zakonyprolidi.cz/cs/2017-250#p20\|§ 20]] a následujících a národního uzlu eIDAS pro spolupráci s oznámenými systémy elektronické identifikace dle nařízení Evropské parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.		Podporu celého procesu elektronické identifikace prostřednictvím kvalifikovaného systému elektronické identifikace je vytvořena platforma Národní identitní autority (také jako NIA), která vykonává činnosti Národního bodu dle [[https://www.zakonyprolidi.cz/cs/2017-250#p20\|§ 20]] a následujících a národního uzlu eIDAS pro spolupráci s oznámenými systémy elektronické identifikace dle nařízení Evropské parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.
-
-	=== Mandáty, práva a role v elektronické identifikaci pro klienty veřejné správy ===
-
-	Kvalifikovaný poskytovatel elektronických služeb bude nadále zodpovědný za řízení oprávnění (autorizaci) fyzické osoby, která prokázala takto svoji totožnost. Nadále tedy musí provádět správu oprávnění na základě údajů o osobě, které získá z [[nap:propojeny_datovy_fond\|Propojeného datového fondu]] a vlastních údajů vedených v agendě.

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

-	=== Mandáty, role a práva v elektronické komunikaci ===	+	{{tag>NIA "Národní identitní prostor" "Identity provider" "Service provider" IdP "Tematická oblast" eop "občanský průkaz" "identifikační doklad" "cestovní pas"}}
-		+
-	Zajištění správné obsazení do role neboli autorizace, klienta využívajícího elektronické služby je jedním ze základních předpokladů jejího správného fungování. Různé role mají v rámci služby různá oprávnění a povinnosti a poskytovatel služby je povinen nabídnout klientovi veškeré role, do kterých se v rámci služby může pasovat, včetně rolí jako zástupce právnické osoby, zástupce nezletilého, registrující lékař pacienta a další. Tyto role s oprávněními vůči jiným klientům veřejné správy jsou mandáty. Aby proběhlo správné obsazení do role a zjištění mandátu, je pro poskytování elektronických služeb klientům veřejné správy nutné mít zajištěno několik základních náležitostí:	+
-		+
-	- Znalost typů mandátů při jednání s veřejnou správou	+
-	- Jednoznačnou identifikaci a autentizaci klienta veřejné správy	+
-	- Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu	+
-	- Vlastní zajištění autorizace klienta veřejné správy	+
-		+
-	== Mandáty pro jednání s veřejnou správou ==	+
-		+
-	Při výkonu veřejné správy a to zejména při jakékoliv interakci a komunikaci s klientem veřejné správy je nutné, aby veřejná správa respektovala mandáty k zastupování jedné osoby druhou na základě různých titulů. Zjednodušeně se dá rozdělit forma mandátu zastupování dle následující tabulky.	+
-		+
-	^ Typ subjektu ^ Mandát ^	+
-	\| Fyzická osoba \| Jednající sama svým jménem \|	+
-	\|::: \| Jednající jménem jiné fyzické osoby ze zákona: \\ - rodič dítěte,\\ - manžel/manželka,\\ - registrovaný partner/partnerka,\\ - opatrovník, osvojitel, poručík, pěstoun \\ - dědic, exekutor,\\ - zastupující osoba pro osoby neschopné jednat nebo nemající zákonného zástupce\|	+
-	\|::: \| Jednající jménem jiné fyzické osoby ze zmocnění: \\ - plná moc,\\ - advokát,\\ - zastupující FO,\\ - jiný druh zmocnění,\\ - na žádost bez zmocnění\|	+
-	\|::: \| Plná moc opravňující konkrétní osobu jednat jménem právnické osoby \|	+
-	\| Fyzická osoba jednající za právnickou osobu \|Jednatel právnické osoby \|	+
-	\|::: \|statutární zástupce právnické osoby (jedna FO) \|	+
-	\|::: \|Statutární orgán právnické osoby (více FO) \|	+
-	\|::: \|Insolvenční správce \|	+
-	\|::: \|Likvidátor \|	+
-	\|::: \|Jednající jménem zřizovatele právnické osoby \|	+
-	\|::: \|Pověřen k jednání za právnickou osobu: \\ - Veřejnoprávním titulem, \\ - Soukromoprávním titulem (smlouva, plná moc, společenská smlouva, apod.) \|	+
-	\|::: \| Pokud agendový předpis povoluje využívání přístupových údajů k systému datových schránek jako identifikačních prostředků je to dále: \\ a) Pro fyzické osoby – statutární zástupce oprávněné k přístupu do datové schránky právnické osoby ověřením oprávnění k datové schránce právnické osoby prostřednictvím Informačního systému datových schránek (ověření přístupových údajů a oprávnění). \\ b) Pro fyzické osoby - oprávněné statutárním zástupcem k přístupu do datové schránky právnické osoby ověřením oprávnění k datové schránce právnické osoby prostřednictvím Informačního systému datových schránek (ověření přístupových údajů a oprávnění). \\ c) Ověřením speciálního agendového oprávnění podle agendového předpisu, na jehož základě jsou poskytovány agendové digitální služby. \|	+
-		+
-	Příklady mandátů pro fyzické osoby vyplývající z některých vyhlášek a nařízení měst a obcí:	+
-	* Pro přihlášení k platbě poplatku za odvoz komunálního odpadu	+
-	* Pro přihlášení k platbě poplatku:	+
-	* ubytovacího,	+
-	* ze psa,	+
-	* za zábor a užívání veřejného prostranství.	+
-	* Pro převody, koupě, prodej, nabytí městského majetku, (provozovny v budovách v majetku města)	+
-	* Pro užívání, podnájem, zrušení užívání bytového fondu města	+
-	* Mandát pro jednání s knihovnou – výpůjčky registrovaného čtenáře	+
-		+
-	Jak je zdůrazněno níže, při výkonu veřejné správy je nutné, aby příslušný orgán konající nějakou činnost v rámci dané agendy věděl, pro jakou formu zastupování je mandát umožněný nebo dokonce nutný. Zcela jiným způsobem se orgán veřejné moci bude chovat k mandátu plynoucímu z veřejnoprávního titulu rodičovství a jinak k mandátu plynoucímu ze soukromoprávního titulu plné moci.	+
-		+
-	Je také vhodné rozlišovat účel mandátu, tedy typ úkonů, které prostřednictvím zastupované osoby klient veřejné správy dělá. Ty je možno rozdělit do následujících skupin:	+
-		+
-	* Nahlížení na údaje subjektů práva bez jakéhokoliv interaktivního využívání či zapisování údajů (informační účel).	+
-	* Přístup k údajům subjektů a jejich reklamace, nebo pokud je přímo umožněna editace klientům veřejné správy (transakční účel).	+
-	* Zmocnění k přístupu či využívání údajů subjektu práva pro třetí strany, nebo poskytnutí údajů z ISVS třetím stranám (zmocňovací účel).	+
-	* Činění podání a úkonů vůči orgánům veřejné správy (účel úkonu).	+
-	* Využívání elektronických klientských služeb jako je objednání se k úředníkovi.	+
-	* Zápis, úprava a zrušení mandátu.	+
-		+
-	== Jednoznačná identifikace a autentizace klienta veřejné správy ==	+
-		+
-	Všechny subjekty povinné dle [[https://www.zakonyprolidi.cz/cs/2017-250#p2\|zákona č. 250/2017 Sb., o elektronické identifikaci mají povinnost dle §2]] využívat k prokázání totožnosti při elektronickém kontaktu pouze kvalifikovaný systém, konkrétně:	+
-		+
-	„Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace.“	+
-		+
-	Kvalifikovaný systém spravuje kvalifikovaný správce (státní orgán nebo akreditovaná osoba) a splňuje technické normy i specifikace Evropské unie a především je propojen s národním bodem pro identifikaci a autentizaci – tzv. Národní identitní autorita ([[nap:nia\|NIA]]).	+
-		+
-	Identifikace a autentizace prostřednictvím NIA zajistí jen a pouze službu ověřené identity fyzické osoby, neboli každý systém čerpající služby [[nap:nia\|NIA]], se může spolehnout na to, že přihlášená fyzická osoba je skutečna ta, za kterou se vzdáleně a elektronicky vydává. Již se dále nezajišťují další služby typu autorizace.	+
-		+
-	== Systém veřejné správy schopný komunikovat a získávat údaje z propojeného datového fondu ==	+
-		+
-	Systém poskytující elektronické služby veřejné správy musí být schopen komunikovat a získávat údaje z [[nap:propojeny_datovy_fond\|propojeného datového fondu]]. K tomu musí systém odpovídat předpisům:	+
-		+
-	* [[https://www.zakonyprolidi.cz/cs/2000-365\|Zákon 365/2000 Sb.]], o informačních systémech veřejné správy. Systém klasifikovaný jako Informační systém veřejné správy (ISVS) využívající referenční rozhraní veřejné správy.	+
-	* [[https://www.zakonyprolidi.cz/cs/2009-111\|Zákon 111/2009 Sb.]], o základních registrech. Systém klasifikovaný jako agendový informační systém (AIS) využívající údaje základních registrů a editorů základních registrů dle svého agendového zákona.	+
-	* [[https://www.zakonyprolidi.cz/cs/2017-250\|Zákon 250/2014 Sb.]], o elektronické identifikaci. Systém, který vyžaduje ověření totožnosti	+
-	* Nařízení eIDAS	+
-		+
-	Více o využívání údajů propojeného datového fondu a infrastruktuře referenčního rozhraní je napsáno v kapitolách:	+
-		+
-	* [[:nap:egsb\|eGON Service Bus/Informační systém sdílené služby]]	+
-	* [[nap:komunikacni_infrastruktura_verejne_spravy\|Centrální místo služeb]]	+
-	* [[nap:propojeny_datovy_fond\|Propojenný datový fond]]	+
-		+
-	Centrální sdílené služby eGovernmentu dokáží zajistit následující mandáty pro fyzické osoby, které se prokázaly u poskytovatele služeb svou zaručenou elektronickou identitou:	+
-		+
-	* eGON služba [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/E22_-_rosCtiPodleUdaju_2_02.pdf\|rosCtiPodleUdaju]], [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/E20_-_rosCtiIco_2_02.pdf\|rosCtiIco]], [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/E21_-_rosCtiAifo_2_02.pdf\|rosCtiAifo]] (základní registr osob)	+
-	* pro zajištění ověření, zda je fyzická osoba statutárním zástupcem	+
-	* eGON služba [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E172_aiseoCtiPodleUdaju2_4_02_v03.pdf\|aiseoCtiPodleUdaju]], [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/E171_aiseoCtiAifo2.pdf\|aiseoCtiAifo]] (agendový informační systém evidence obyvatel)	+
-	* pro zajištění ověření, zda je fyzická osoba rodič nezletilého, který není svéprávný	+
-	* pro zajištění ověření, zda je fyzická osoba zákonným zástupcem jiné fyzické osoby	+
-	* pro zajištění ověření, zda je fyzická osoba opatrovníkem jiné fyzické osoby	+
-	* pro zajištění ověření, zda je fyzická osoba manžel/manželka	+
-	* eGON služba [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E238_isknCtiVlastniky2_v1_00_v01_r0.pdf\|isknCtiVlastniky]] (informační systém katastru nemovitostí)	+
-	* pro zajištění ověření, zda je fyzická osoba vlastníkem nemovitosti	+
-	* Služba ISDS	+
-	* Pro zajištění, zda je fyzická osoba pověřená k činění úkonů v ISDS vlastníkem datové schránky	+
-		+
-	Žádné další centrální služby ověření oprávnění/mandátů se v současné, ani dohledné době, neplánují. Proto je důležité, aby si každý poskytovatel elektronických služeb zajistit jiné typy mandátů sám.	+
-		+
-	== Vlastní zajištění autorizace klienta veřejné správy ==	+
-		+
-	Každá vykonávaná agenda (výkon veřejné správy) může pro svoji potřebu vyžadovat jiné mandáty. Například mandát podání daňového přiznání za jinou fyzickou osobu, mandát nahlížení na zdravotnickou dokumentaci jiné fyzické osoby, nakládání s majetkem právnické osoby, u které nejsem statutární zástupce, či například mandát k zastupování při dědickém řízení.	+
-		+
-	Všechny tyto mandáty se musí řešit v rámci dané agendy a jako ideální řešení navrhujeme:	+
-		+
-	* Zřídit buď v jednotlivých agendových informačních systémech, nebo v rámci centralizované správy subjektů mandátní registr.	+
-	* V rámci mandátního registru určit předem definované typy mandátů přípustné v dané agendě a způsob zápisu mandátů pro nahlížení a pro transakce ze strany klienta	+
-	* Povolit zapisovat všem klientům mandáty dle definovaných typů pod svou zaručenou elektronickou identitou.	+
-	* Umožnit klientům přidat mandát i offline, například na přepážce úřadu.	+
-	* Při každém přihlášení klienta kontrolovat kromě mandátů z centrálních sdílených služeb eGovernmentu i vlastní mandátní registr a dát vždy při přihlášení vybrat klientovi, v jaké roli a s jakým mandátem chce pracovat.	+
-		+
-	Je důležité zdůraznit, že veřejná správa nemá rozlišovat formu komunikace a jednání s klientem. Tedy mandát obecně platící pro osobní jednání s úředníkem, nebo pro fyzické prováděné úkony na přepážce, musí mít klient umožněn využívat i při elektronické komunikaci a naopak. Také proto je nutné vést mandáty standardizovanou formou na jednom místě a využívat jich i při elektronické komunikaci klienta.	+
-		+
-	Mandát plynoucí z veřejnoprávního nebo soukromoprávního titulu a to včetně plných mocí a dohod o zastupování při správním jednání s úřady patří mezi společné rozhodné skutečnosti, tak jak jsou zakotveny v souvisejících ustanoveních Správního řádu (zejména § 6 a § 50 a související). Proto je nanejvýš vhodné, aby příslušný orgán veřejné moci, pokud	+
-		+
-	* využívá a buduje centrální evidenci subjektů,	+
-	* centrální evidenci rozhodných skutečností,	+
-	* skutečnosti o zapsaném anebo z něčeho plynoucím mandátu k zastupování,	+
-	* je zahrnul do rozhodných skutečností.	+
-		+
-	Klient se totiž může odvolat na příslušná ustanovení správního řádu a neposkytovat zejména plné moci a další dokumenty, z nichž mandát plyne, úřadu opakovaně.	+
-		+
-		+
-	{{tag>NIA "Národní identitní prostor" "Identity provider" "Service provider" IdP "Tematická oblast" eop "občanský průkaz" "identifikační doklad" "cestovní pas" "mandáty" "mandáty v elektronické komunikaci" "zastupování" "oprávnění" "mandát"}}	+

Digitální dvojče veřejné správy

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-08-08T09:31:24+00:00

2026/11/07 09:10	aktuální
Řádek 1:	Řádek 1:
	+	====== Digitální dvojče veřejné správy ======

	+	Veřejná správa disponuje obrovským množstvím procesů, vazeb a povinností vyplývajících z legislativy. Digitální dvojče veřejné správy si můžeme představit jako komplexní datový model, který zrcadlí strukturu úřadů, agend, právních předpisů a toků dat v rámci státní správy. V českém prostředí se nabízí využít jako základ Registr práv a povinností (RPP), který transformuje “řeč zákonů” do řeči IT systémů – eviduje každou agendu veřejné správy, její zakládající zákon, příslušné orgány veřejné moci, prováděné činnosti a oprávnění k přístupu k údajům v základních registrech či agendových systémech. RPP de facto uchovává referenční model fungování veřejné správy: obsahuje údaje o působnostech úřadů, matice oprávnění k datům atd. Digitální dvojče veřejné správy by nad těmito daty vystavělo dynamický model vztahů a procesů – umožnilo by vizuálně prozkoumat, který úřad co dělá, na základě jakého zákona, jaké informační systémy přitom využívá a jaké údaje sdílí. Takový model by byl neocenitelný při analyzování dopadů změn: například při novelizaci zákona by okamžitě ukázal, jakých agend se změna týká, které úřady budou muset upravit postupy, nebo které informační systémy si budou muset nově vyměňovat data. V současnosti je navíc kladen důraz na standardizaci a konceptuální modelování dat ve veřejné správě – Digitální a informační agentura (DIA) vyžaduje, aby každá ohlašovaná agenda měla předem schválený konceptuální model údajů.
	+
	+	===== Úvod do konceptu digitálního dvojčete veřejné správy =====
	+	Digitální dvojče veřejné správy (DT VS) představuje ambiciózní koncept, jehož cílem je vytvořit datově řízený model fungování veřejné správy. Tento model umožňuje sledovat, simulovat a optimalizovat výkon agend, služeb, technologických komponent a územních dat. DT VS je navrženo jako nástroj pro efektivní řízení a plánování, který podporuje rozhodování na základě reálných dat a predikcí.
	+
	+	Základní oblasti, které DT VS pokrývá, zahrnují legislativu, agendový model veřejné správy, agendové informační systémy, služby veřejné správy a územní data. Dále se rozšiřuje o doménové modely v oblastech jako školství, zdravotnictví, energetika, finance, zemědělství a trh práce. Cílem je vytvořit jednotný rámec, který propojí jednotlivé subjekty veřejné správy a umožní jejich koordinaci.
	+
	+	===== Architektura digitálního dvojčete =====
	+	Architektura DT VS je navržena jako vícevrstvý systém, který zahrnuje business, aplikační, technologickou, územní, datovou, bezpečnostní a analytickou vrstvu. Každá z těchto vrstev má specifické funkce a komponenty, které dohromady tvoří komplexní ekosystém.
	+
	+	Business vrstva se zaměřuje na modelování agend, služeb, úkonů, klientů a klíčových ukazatelů výkonnosti (KPI). Aplikační vrstva zahrnuje DT Engine, integrační platformu, API Gateway a vizualizační nástroje. Technologická vrstva pracuje s IoT daty, GIS systémy a technologickými rozhraními. Územní vrstva je reprezentována 3D mapami obcí a adres. Datová vrstva uchovává historii, snapshoty a rollbacky dat. Bezpečnostní vrstva je založena na principech Zero Trust, IAM a SIEM. Analytická vrstva umožňuje ETL procesy, sandboxové analýzy, BI a simulace.
	+
	+	===== Příprava a budování modelu DT =====
	+	Před samotným návrhem DT je nutné vyjasnit jeho vizi a cíle. To zahrnuje definici účelu (např. monitoring výkonu agend, kapacitní plánování, simulace legislativních změn) a identifikaci klíčových stakeholderů. Dále je třeba popsat konkrétní scénáře využití, jako je sledování dostupnosti systémů AIS/ISVS nebo dopadů legislativních změn.
	+
	+	Budování modelu DT zahrnuje analýzu procesů a potřeb, analýzu datových zdrojů, návrh architektury, modelování objektů a vazeb, návrh bezpečnostních opatření a technickou dokumentaci. Každý krok je podpořen konkrétními nástroji a technologiemi, jako jsou ArchiMate, Azure Digital Twins, Event Grid, Data Lake nebo Power BI.
	+
	+	===== Portál DT a vizualizace =====
	+	Portál DT je klíčovým rozhraním pro uživatele, které poskytuje přehled o živém stavu objektů DT, interaktivní dashboardy, vizualizace vazeb mezi objekty, filtrování dat, sledování incidentů a simulace změn. Umožňuje také přístup k historickým datům a jejich analýze.
	+
	+	Technologicky je portál realizován jako webová aplikace (např. React, Angular) napojená na backend DT. Vizualizace jsou zajištěny pomocí Power BI Embedded, Grafana nebo D3.js. Autentizace probíhá přes NIA/SSO s definovanými rolemi (analytik, správce, OVM).
	+
	+	===== Zabezpečení a provozní komponenty =====
	+	Bezpečnostní komponenty DT zahrnují ochranu proti útokům pomocí WAF, detekci DDoS, penetrační testy, šifrování dat, auditní logy a správu certifikátů. Monitoring neobvyklého chování je zajištěn nástroji jako Security Center nebo Sentinel.
	+
	+	Další provozní komponenty zahrnují logovací systém ZRNG, testovací prostředí DT, notifikační systém, helpdesk, zálohování a disaster recovery plán, verzování modelů a API katalog. Tyto prvky zajišťují stabilitu, rozšiřitelnost a bezpečnost systému.
	+
	+	===== Shrnutí a nezbytné podmínky úspěchu =====
	+	Po dokončení projektu bude k dispozici plně funkční portál DT s živými daty, historizační úložiště s BI vrstvou, bezpečné prostředí s monitoringem, napojení na Event Grid a Data Lake a připravený systém pro ostrý provoz. Klíčovým faktorem úspěchu je součinnost všech zapojených subjektů – ohlašovatelů agend, OVM, MV/DIA, ISZR/NIA/ISDS, uživatelů a bezpečnostních týmů.

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

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-05-15T13:48:37+00:00

2023/06/05 08:58		aktuální
Řádek 1:		Řádek 1:
	======eGovernment On-Line Service Bus / Informační systém sdílené služby======		======eGovernment On-Line Service Bus / Informační systém sdílené služby======

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

	* Publikovat služby pro sdílení údajů týkajících se konkrétního subjektu nebo objektu práva		* Publikovat služby pro sdílení údajů týkajících se konkrétního subjektu nebo objektu práva
Řádek 10:		Řádek 10:
	* 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)		* Zajištění nezávislého auditu výměny údajů (ukládá informace identifikující dotaz a odpověď a technický kryptografický otisk zprávy – hash)

-	V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|G1:gsbCtiData}} a {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|G11:gsbZapisData}} pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že	+	V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G1:gsbCtiData}} a {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G11:gsbZapisData}} pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že
-	eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí [[nap:zakladni_registry\|ORG]] identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|G1:gsbCtiData}} či {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|G11:gsbZapisData}} zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.	+	eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí [[nap:zakladni_registry\|ORG]] identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G1:gsbCtiData}} či {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G11:gsbZapisData}} zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.

	Cílem je, aby klienti veřejné správy nebyli nuceni dokládat skutečnosti, o kterých veřejná správa již ví, či které vznikly dokonce na základě rozhodnutí veřejné správy. Většina skutečností potřebných pro rozhodování veřejné správy je již někde evidována, a to formou údajů v informačních systémech veřejné správy. Dále existují skutečnosti, které sice jsou na základě rozhodování veřejné správy, nicméně nejsou dosud vedeny v AIS jako údaje (příkladem je potvrzení o studiu, dohoda o chráněné dílně apod.). Zmapováním údajů v jednotlivých agendách, které probíhá nyní v rámci nových povinností ohlašovatelů vůči [[nap:rpp\|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		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 [[nap:rpp\|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
Řádek 39:		Řádek 39:
	- na základě zákonného zmocnění vedení údajů v agendě s označením čerpání v [[nap:rpp\|RPP]] (z moci úřední)		- na základě zákonného zmocnění vedení údajů v agendě s označením čerpání v [[nap:rpp\|RPP]] (z moci úřední)

-	Informace k informačnímu systému sdílení údajů jsou k dispozici na [[https://www.szrcr.cz/cs/isss-egsb\|stránkách SZR ČR]] včetně dokumentů:	+	Informace k informačnímu systému sdílení údajů jsou k dispozici na [[https://szrcr.cz/cs/isss-egsb\|stránkách SZR ČR]] včetně dokumentů:
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Publikace_AIS_na_ISSS_v1_06.pdf \|Publikace AIS na eGSB / ISSS}}	+	* {{ https://szrcr.cz/images/dokumenty/ISSS/Publikace_AIS_na_ISSS_v1_09_20231016.pdf \|Publikace AIS na eGSB / ISSS}}
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Pr%CC%8Cipojeni%CC%81_c%CC%8Ctena%CC%81r%CC%8Cske%CC%81ho_AISSSVU%CC%81_k_ISSS.pdf \|Připojení čtenářského AIS na eGSB / ISSS}}	+	* {{ https://szrcr.cz/images/dokumenty/ISSS/Vyuziti_sluzeb_ISSS_ctenarskymi_a_zdrojovymi_AIS_v1_07.pdf \|Využití služeb eGSB / ISSS čtenářskými a publikačními AIS}}
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Pr%CC%8Cipojeni%CC%81_publikac%CC%8Cni%CC%81ho_AISSSVU%CC%81_k_ISSS_.pdf \|Připojení publikačního AIS na eGSB / ISSS}}	+
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Vyuz%CC%8Citi%CC%81_sluz%CC%8Ceb_eGSB__ISSS_c%CC%8Ctena%CC%81r%CC%8Csky%CC%81mi_a_publikac%CC%8Cni%CC%81mi_AIS.pdf \|Využití služeb eGSB / ISSS čtenářskými a publikačními AIS}}	+

	===== Způsob komunikace mezi čtenáři a publikátory =====		===== Způsob komunikace mezi čtenáři a publikátory =====
Řádek 73:		Řádek 72:

	^Kód^Podrobný popis služby^Verze^		^Kód^Podrobný popis služby^Verze^
-	\|G1 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|gsbCtiData}} \|1.03 \|	+	\|G1 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiData}} \|1.03 \|
-	\|G2 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G2_gsbCtiZmeny_v1_01.pdf \|gsbCtiZmeny}} \|1.01 \|	+	\|G2 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiZmeny}} \|1.01 \|
-	\|G3 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G3_gsbVlozOdpoved_v1_02.pdf \|gsbVlozOdpoved}} \|1.02 \|	+	\|G3 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVlozOdpoved}} \|1.02 \|
-	\|G4 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G4_gsbVlozSoubor_v1_01.pdf \|gsbVlozSoubor}} \|1.04 \|	+	\|G4 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVlozSoubor}} \|1.04 \|
-	\|G5 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G5_gsbCtiSoubor_v1_01.pdf \|gsbCtiSoubor}} \|1.01 \|	+	\|G5 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiSoubor}} \|1.01 \|
-	\|G6 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G6_gsbVypisFronty_v1_01.pdf \|gsbVypisFronty}} \|1.01 \|	+	\|G6 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVypisFronty}} \|1.01 \|
-	\|G7 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G7_gsbOdpovedZFronty_v1_01.pdf \|gsbOdpovedZFronty}} \|1.01 \|	+	\|G7 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbOdpovedZFronty}} \|1.01 \|
-	\|G8 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G8_gsbSmazatFrontu_v1_01.pdf \|gsbSmazatFrontu}} \|1.01 \|	+	\|G8 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbSmazatFrontu}} \|1.01 \|
-	\|G9 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G9_gsbProbe_v1_01.pdf \|gsbProbe}} \|1.01 \|	+	\|G9 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbProbe}} \|1.01 \|
-	\|G10 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G10_gsbCtiKontexty_v1_01.pdf \|gsbCtiKontexty }} \|1.01 \|	+	\|G10 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiKontexty }} \|1.01 \|
-	\|G11 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|gsbZapisData}} \|1.04 \|	+	\|G11 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbZapisData}} \|1.04 \|
-	\|K1 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K1_katCtiSluzby_v1_01.pdf \|katCtiSluzby}} \|1.01 \|	+	\|K1 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiSluzby}} \|1.01 \|
-	\|K2 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K2_katCtiDetailSluzby_v1_01.pdf \|katCtiDetailSluzby}} \|1.01 \|	+	\|K2 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiDetailSluzby}} \|1.01 \|
-	\|K3 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K3_katCtiPrilohu_v1_01.pdf \|katCtiPrilohu}} \|1.01 \|	+	\|K3 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiPrilohu}} \|1.01 \|
-	\|K4 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K4_katCtiEndpoint_v1_01.pdf \|katCtiEndpoint}} \|1.01 \|	+	\|K4 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiEndpoint}} \|1.01 \|

Evropská peněženka digitální identity (EUDIW)

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-03-13T13:25:46+00:00

2025/03/13 13:25		aktuální
Řádek 28:		Řádek 28:
	* QEAA – qualified electronic attestation of attributes – kvalifikovaná elektronická potvrzení atributů		* QEAA – qualified electronic attestation of attributes – kvalifikovaná elektronická potvrzení atributů
	* PuB-EAA – public body authentic source electronic attestation of attributes – elektronická potvrzení atributů pocházejících z původních veřejných zdrojů		* PuB-EAA – public body authentic source electronic attestation of attributes – elektronická potvrzení atributů pocházejících z původních veřejných zdrojů
-	* EEA – electronic attestation of attributes – běžná nekvalifikovaná elektronická potvrzení atributů	+	* EAA – electronic attestation of attributes – běžná nekvalifikovaná elektronická potvrzení atributů

	==== Řešení EUDIW ====		==== Řešení EUDIW ====
Řádek 48:		Řádek 48:
	Zásadní dva termíny se týkají vydávání Peněženek a povinnosti jejich akceptace:		Zásadní dva termíny se týkají vydávání Peněženek a povinnosti jejich akceptace:

-	* 21. 11. 2026 (vztaženo k vydání prováděcích předpisů 21. 11. 2024 + 24 měsíců) – každý stát vydá alespoň jednu EDIW pro své občany	+	* 21. 11. 2026 (vztaženo k vydání prováděcích předpisů 21. 11. 2024 + 24 měsíců) – každý stát vydá alespoň jednu EUDIW pro své občany
	* 21. 11. 2027 (vztaženo k vydání prováděcích předpisů 21. 11. 2024 + 36 měsíců) – povinnost akceptace pro vybrané soukromoprávní subjekty		* 21. 11. 2027 (vztaženo k vydání prováděcích předpisů 21. 11. 2024 + 36 měsíců) – povinnost akceptace pro vybrané soukromoprávní subjekty

Rychlá navigace

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-02-10T08:31:05+00:00

2021/03/11 08:24		aktuální
Řádek 4:		Řádek 4:
	[[:start\|Národní architektura veřejné správy ČR]]		[[:start\|Národní architektura veřejné správy ČR]]

-	[[:ikcr\|1.Informační koncepce ČR]]	+	[[:uvod_dokumenty\|1.Architektonické dokumenty]]

-	[[:metody_dokument\|2.Metody řízení ICT VS ČR]]	+	[[:uvod_klicove_oblasti\|2.Klíčové oblasti architektury]]

-	[[:slovnik_egov\|3.Slovník pojmů eGovernmentu]]	+	*[[:uvod_klicove_oblasti#e\|Potřebnost informačních systémů a soulad s 3E]]
		+	[[:uvod_klicove_oblasti#strategie\|Koncepce a strategie úřad*ů]]
		+	*[[:uvod_klicove_oblasti#kanaly\|Obslužné kanály veřejné správy]]
		+	*[[:uvod_klicove_oblasti#dokumenty\|Elektronický oběh dokumentů]]
		+	*[[:uvod_klicove_oblasti#identifikace\|Identifikace v informačních systémech]]
		+	*[[:uvod_klicove_oblasti#data\|Strukturovaná data v ISVS, datové fondy a jejich sdílení]]
		+	*[[:uvod_klicove_oblasti#rozhrani\|Referenční rozhraní veřejné správy]]
		+	*[[:uvod_klicove_oblasti#ais\|Sdílené agendové a provozní informační systémy]]
		+	*[[:uvod_klicove_oblasti#kivs\|Komunikační infrastruktura veřejné správy]]
		+	*[[:uvod_klicove_oblasti#cloud\|Cloudové služby]]

-	[[:nar_dokument\|4.Národní architektonický rámec]]	+	[[:uvod_schvalovani\|3.Schvalování projektů a záměrů ICT]]

-	[[:nap_dokument\|5.Národní architektonický plán]]	+	[[:reporty\|4. Seznam reportů]]
-	* [[nap_dokument:uvod\|Úvod]]	+
-	* [[nap_dokument:architektonicka_vize_e_governmentu_cr\|Architektonická vize eGovernmentu ČR]]	+
-	* [[nap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu\|Architektura úřadu]]	+
-	* [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr\| Popis sdílených služeb, funkčních celků a tematických oblastí]]	+
-	* [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu\|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí]]	+
-	* [[nap_dokument:modely_nap_v_centralnim_ulozisti_a_v_ovs\|Modely NAP v centrálním úložišti a v OVS]]	+
-		+
-	[[:znalostni_baze\|6.Rozšiřující znalostní báze]]	+
-		+
-	[[:uvod_klicove_oblasti\|7.Klíčové oblasti architektury]]	+
-		+
-	[[:uvod_schvalovani\|8.Schvalování projektů a záměrů ICT]]	+

Editorské agendové informační systémy

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-02-07T19:37:43+00:00

2020/11/27 08:29		aktuální
Řádek 1:		Řádek 1:
-	<title>Editorské agendové informační systémy</title>	+	======Editorské agendové informační systémy======

	Systémy jejichž údaje jsou publikované kompozitními službami [[nap:iszr\|ISZR]]. Kompozitními službami se rozumí služby [[nap:iszr\|ISZR]], které poskytují údaje vedené v editorských systémech ZR s vazbou na referenční údaje vedené v ZR:		Systémy jejichž údaje jsou publikované kompozitními službami [[nap:iszr\|ISZR]]. Kompozitními službami se rozumí služby [[nap:iszr\|ISZR]], které poskytují údaje vedené v editorských systémech ZR s vazbou na referenční údaje vedené v ZR:
Řádek 15:		Řádek 15:
	Čtenář může čerpat nereferenční údaje formou tzv. kompozitních služeb. Jelikož v ZR se nacházejí pouze údaje k aktuálnímu stavu, které jsou správné a garantované státem (kromě údajů nereferenčních vedených v základních registrech), v rámci kompozitních služeb je možné získat z editačních systémů editorů ostatní nereferenční údaje (např. historické údaje o subjektu práva nebo další užitečné údaje, které se v ZR nenachází).		Čtenář může čerpat nereferenční údaje formou tzv. kompozitních služeb. Jelikož v ZR se nacházejí pouze údaje k aktuálnímu stavu, které jsou správné a garantované státem (kromě údajů nereferenčních vedených v základních registrech), v rámci kompozitních služeb je možné získat z editačních systémů editorů ostatní nereferenční údaje (např. historické údaje o subjektu práva nebo další užitečné údaje, které se v ZR nenachází).

-	Informace o kompozitních službách jsou k dispozici na [[http://www.szrcr.cz/vyvojari/kompozitni-sluzby-ais-eo\|stránkách SZR]].	+	Informace o kompozitních službách jsou k dispozici na [[https://szrcr.cz/cs/sluzby/spravci-a-vyvojari/kompozitn%C3%AD-slu%C5%BEby-aiseo,-aiseop,-aiscd-a-aisc\|stránkách SZR]].

	{{tag>"Funkční celek" "Editorské AIS" " editori "editori ZR" "kompozitni sluzby"}}		{{tag>"Funkční celek" "Editorské AIS" " editori "editori ZR" "kompozitni sluzby"}}

- ↷ Stránka přesunuta z 'nap:katalog_cloud' do 'reporty:katalog_cloud'

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-02-07T09:55:45+00:00

2024/06/21 10:02		aktuální

Registr územní identifikace adres a nemovitostí

Tomáš Šedivec (tomas.sedivec@undisclosed.example.com) — 2025-01-02T09:37:33+00:00

2024/03/21 13:12		aktuální
Řádek 49:		Řádek 49:
	ÚÚP by se do RUIAN měly zapisovat pouze v případě, že je jejich evidence účelná z důvodu užití u více orgánů veřejné správy a jejich procesech či agendách. Tento požadavek je nutné zohlednit při přípravě právních předpisů.		ÚÚP by se do RUIAN měly zapisovat pouze v případě, že je jejich evidence účelná z důvodu užití u více orgánů veřejné správy a jejich procesech či agendách. Tento požadavek je nutné zohlednit při přípravě právních předpisů.
	</wrap>		</wrap>
		+
		+	==== Aktuálně jsou v RÚIAN vedeny následující ÚÚP ====
		+	* Volební okrsky zavedené 1. 1. 2014 podle zákona č. 222/2012 Sb., kterým se mění volební zákony. Editorem je příslušný obecní úřad nebo úřad městské části/městského obvodu.
		+	* Dobývací prostory zavedené 1. 4. 2022 podle zákona č. 88/2021 Sb., kterým byl novelizován horní zákon. Editorem je ČBÚ.
		+	* Chráněná ložisková území zavedené 30. 11. 2022 podle zákona č. 88/2021 Sb., kterým byl novelizován horní zákon. Editorem je MŽP.
		+	* Značky bodů základních bodových polí a ochranná pásma značek bodů základních bodových polí zavedené 30. 6. 2023 podle zákona č. 88/2023 Sb., kterým byl novelizován zeměměřický zákon. Editorem je ZÚ.
		+	* Bonitované půdně ekologické jednotky zavedené 1. 5. 2024 v rámci zákona č. 229/2019 Sb., kterým byl novelizován zákon o Státním pozemkovém úřadu, referenčnost BPEJ v RÚIAN bude vyhlášena ve Sbírce zákonů k 1. 1. 2025. Editorem je SPÚ.
		+	==== Legislativně schválenými ÚÚP v RÚIAN jsou====
		+	* Prvky ochrany přírody a krajiny podle zákona č. 364/2021 Sb., kterým byl novelizován zákon o ochraně přírody a krajiny. Zápis prvků do RÚIAN bude proveden nejpozději do 1. 3. 2025. Editorem bude Agentura ochrany přírody a krajiny.
		+	* Senátní volební obvody podle zákona č. 89/2024 Sb., kterým se mění volební a některé další zákony v souvislosti s přijetím zákona o správě voleb. Zápis prvků do RÚIAN bude proveden nejpozději do 1. 1. 2027. Editorem bude ČÚZK na základě podkladů Ministerstva vnitra.
		+	* Památkové ochrany podle zákona č. 169/2024 Sb., kterým se mění zákon č. 20/1987 Sb., o státní památkové péči. Bude se jednat pouze o plošné ochrany (památkové rezervace, památkové zóny a ochranná pásma), Zápis prvků do RÚIAN bude proveden nejpozději do 1. 1. 2027. Editorem bude Národní památkový ústav.
		+	==== ÚÚP, které jsou navrženy v právních předpisech či jsou v jednáních ====
		+	* Lázeňské ochrany – mezi Ministerstvem zdravotnictví a ČÚZK je shoda na zavedení ÚÚP přírodní léčivé zdroje a zdroje přírodní minerální vody, ochranné pásmo I. stupně a vnitřní území lázeňského místa. Příslušné změny jsou předkladatelem navrženy v rámci novely zákona č. 164/2001 Sb., lázeňský zákon. Editorem bude Český inspektorát lázní a zřídel, respektive Ministerstvo zdravotnictví.
		+	* Školské obvody – k zavedení spádové oblasti (školské obvody) pro mateřské školky, první a druhý stupeň základních škol. Navrženo v zákoně č. 561/2004 Sb., o předškolním, základním, středním, vyšším odborném a jiném vzdělávání. Editory budou obce, městská část/městský obvod a kraje.
		+	* Chráněná území pro zvláštní zásahy do zemské kůry – řešeno v rámci připomínkového řízení k novele zákona o ochraně přírody a krajiny. Editorem bude Ministerstvo životního prostředí.
		+	* Zastavěné území a stavební uzávěry – v současnosti řešeno s Ministerstvem pro místní rozvoj, mělo by být zavedeno novelou stavebního zákona. Předpoklad v RÚIAN k 1. 1. 2027.
		+	* Soubor lesních typů a kategorie lesů – řešeno v rámci připomínkového řízení k novele zákona 289/1995 Sb., o lesích v meziresortním připomínkovém řízení, editorem by mělo být Ministerstvo zemědělství nebo Ústav pro hospodářskou úpravu lesů.
		+
		+	Nedílnou součástí vedení ÚÚP v RÚIAN je mít pro každý nový ÚÚP připravený systém dle vedení konkrétních údajů u jednotlivých ÚÚP, poskytovat metodickou a uživatelskou podporu při zavádění nových ÚÚP i při samotné evidenci a správě již existujících ÚÚP v RÚIAN.
		+
		+

	==== Příklad ÚÚP v zákoně o ochraně a využití nerostného bohatství (horní zákon) ====		==== Příklad ÚÚP v zákoně o ochraně a využití nerostného bohatství (horní zákon) ====
Řádek 91:		Řádek 112:
	* (3) Registr územní identifikace, adres a nemovitostí zprostředkovává z agendového informačního systému Českého báňského úřadu údaje o držiteli dobývacího prostoru pro účely plnění povinností podle § 62 odst. 1 věty první zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.		* (3) Registr územní identifikace, adres a nemovitostí zprostředkovává z agendového informačního systému Českého báňského úřadu údaje o držiteli dobývacího prostoru pro účely plnění povinností podle § 62 odst. 1 věty první zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.

		+	==== Registr bytů ====
		+	Vzhledem k neexistenci uceleného a komplexního datového zdroje za bytový fond byla vytvořena meziresortní pracovní skupina, která pracuje na vytvoření referenčního datového zdroje údajů o bytech. V současné době probíhá příprava nelegislativního materiálu do vlády. K zakotvení registru bytů v právní úpravě bude nezbytná novela ZZR a případných souvisejících předpisů.
		+
		+	Evidence bytů (a případně i nebytových prostor) v RÚIAN umožní vytvořit základní referenční zdroj pro možnost sdílení a vedení dalších atributů v rámci jiných agend orgánů veřejné správy.
		+
		+	S RÚIAN se počítá jako s informačním systémem pro registr bytů. Měla být definována nová evidenční jednotka „byt“ s vazbou na stavební objekt a adresní místo. Editace by měla probíhat prostřednictvím ISÚI, kde editorem budou stavební úřady, obce a případně další zákonem stanovení editoři.
		+
		+	V případě schválení záměru bude potřeba rozšířit stávající databázový model, aktualizovat editační a informační služby ISZR, rozšířit reklamační služby ISÚI, doplnit (příp. aktualizovat) výměnný formát RÚIAN, zohlednit nové prvky v aplikaci VDP a zejména upravit aplikační část ISÚI pro editaci těchto prvků. Následnou realizaci záměru bude nutné podpořit metodickou, technickou a uživatelskou podporou.

	{{tag>RUIAN "Registr územní identifikace, adres a nemovitostí" "Základní registry"}}		{{tag>RUIAN "Registr územní identifikace, adres a nemovitostí" "Základní registry"}}

2026/07/10 07:23		aktuální
Řádek 34:		Řádek 34:
	Detailní a aktuální seznam kontextů, datových obsahů a AIS je dostupný na adrese [[https://egsbkatalog.cms2.cz/]] a [[https://katalogisss.dia.cms2.cz]]. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.		Detailní a aktuální seznam kontextů, datových obsahů a AIS je dostupný na adrese [[https://egsbkatalog.cms2.cz/]] a [[https://katalogisss.dia.cms2.cz]]. Tento seznam je dostupný pouze ze sítě CMS/KIVS, ne z veřejného internetu.

-	Zde uvedené informace jsou platné k 30.1.2026	+	Zde uvedené informace jsou platné k 10.7.2026
	</WRAP>		</WRAP>

Řádek 456:		Řádek 456:
	\|1025\|Registr silničních vozidel (RSV)\|		\|1025\|Registr silničních vozidel (RSV)\|
	\|1078\|Informační systém RBP\|		\|1078\|Informační systém RBP\|
-	\|1098\| Centrální registr zbraní\|	+	\|1098\|Centrální registr zbraní\|
	\|1507\|eAVA\|		\|1507\|eAVA\|
	\|2679\|KIS\|		\|2679\|KIS\|
Řádek 465:		Řádek 465:
	\|5304\|IS úřadu pro civilní letectví\|		\|5304\|IS úřadu pro civilní letectví\|
	\|5351\|CIS OZP\|		\|5351\|CIS OZP\|
-	\|5636\| Elektronické testy uchazečů o řidičská oprávnění (eTesty)\|	+	\|5636\|Elektronické testy uchazečů o řidičská oprávnění (eTesty)\|
	\|5838\|Informační systém technických prohlídek (IS TP)\|		\|5838\|Informační systém technických prohlídek (IS TP)\|
	\|5866\|Systém elektronického mýta (Mýto)\|		\|5866\|Systém elektronického mýta (Mýto)\|
-	\|6726\| Rejstřík podnikatelů v silniční dopravě (RPSD)\|	+	\|6726\|Rejstřík podnikatelů v silniční dopravě (RPSD)\|
	\|7199\|Informační systém Státní plavební správy\|		\|7199\|Informační systém Státní plavební správy\|
	\|7638\|Národní kontaktní místo pro elektronické zdravotnictví \|		\|7638\|Národní kontaktní místo pro elektronické zdravotnictví \|
	\|7874\|Centrální evidence přeplatků a nedoplatků\|		\|7874\|Centrální evidence přeplatků a nedoplatků\|
		+	\|8453\|Statistický informační systém (SIS)\|
	\|8456\|IS Digitální tachograf (ISDT)\|		\|8456\|IS Digitální tachograf (ISDT)\|
	\|8618\|IS Elektronická dálniční známka\|		\|8618\|IS Elektronická dálniční známka\|
	\|8657\|Monitorovací systém fondů EU 21+\|		\|8657\|Monitorovací systém fondů EU 21+\|
	\|8658\|Centrální registr pojištenců\|		\|8658\|Centrální registr pojištenců\|
		+	\|8659\|e-Sbírka a e-Legislativa\|
	\|8830\|IS eRecept\|		\|8830\|IS eRecept\|
	\|8929\|Portál dopravy\|		\|8929\|Portál dopravy\|
Řádek 481:		Řádek 483:
	\|9209\|Portál dopravy - stage\|		\|9209\|Portál dopravy - stage\|
	\|9616\|Informační systém vzdělávání eEdu\|		\|9616\|Informační systém vzdělávání eEdu\|
-	\|10357\| IS pro nadrozměrnou přepravu (IS NADR)\|	+	\|10357\|IS pro nadrozměrnou přepravu (IS NADR)\|
	\|14600\|Informační systém oprávnění k zastupování (REZA)\|		\|14600\|Informační systém oprávnění k zastupování (REZA)\|
	\|14835\|EUCARIS \|		\|14835\|EUCARIS \|
	\|15736\|Agendový informační systém pojištění odpovědnosti z provozu vozidla (AISPOV)\|		\|15736\|Agendový informační systém pojištění odpovědnosti z provozu vozidla (AISPOV)\|
-	\|17678\| Kmenový registr pacientů\|	+	\|16703\|Integrovaný informační systém Ministerstva práce a sociálních věcí\|
-	\|18776\| Správa PPP a zobrazení souhlasů\|	+	\|17678\|Kmenový registr pacientů\|
		+	\|18576\|Centrální evidence psů (CEP)\|
		+	\|18776\|Správa PPP a zobrazení souhlasů\|
	</datatables>		</datatables>

2021/07/29 07:36		aktuální
Řádek 1:		Řádek 1:
	======Registr obyvatel======		======Registr obyvatel======

-	Registr obyvatel je základním registrem podle Zákona č. 111/2009 Sb., o základních registrech, který eviduje referenční údaje o fyzických osobách. Správcem Registru obyvatel je Ministerstvo vnitra. Primárními editory jsou jednotlivé OVM prostřednictvím [[nap:iseo\|Informačního systému evidence obyvatel]] a [[nap:cis\|Agendového informačního systému cizinců]].	+	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 Digitální a informační agentura. Primárními editory jsou jednotlivé OVM prostřednictvím [[nap:iseo\|Informačního systému evidence obyvatel]] a [[nap:cis\|Agendového informačního systému cizinců]].

	Subjekty údajů vedených v registru obyvatel jsou		Subjekty údajů vedených v registru obyvatel jsou
Řádek 45:		Řádek 45:
	* U datových schránek je editorem Ministerstvo vnitra jako správce [[nap:elektronicke_ukony_a_dorucovani\|Informačního systému datových schránek]].		* U datových schránek je editorem Ministerstvo vnitra jako správce [[nap:elektronicke_ukony_a_dorucovani\|Informačního systému datových schránek]].
	* Editorem provozních údajů je Správa základních registrů prostřednictvím [[nap:iszr\|informačního systému základních registrů]]		* Editorem provozních údajů je Správa základních registrů prostřednictvím [[nap:iszr\|informačního systému základních registrů]]
		+
		+	===== Typy dokladů vedených v registru obyvatel =====
		+
		+	V registru obyvatel se vedou pouze doklady vydané v České republice:
		+
		+	^Zkratka dokladu^Název dokladu^
		+	\|ID \| občanský průkaz\|
		+	\|OP \| občanský průkaz bez strojově čitelných údajů\|
		+	\|P \| cestovní pas\|
		+	\|CA \| cestovní průkaz\|
		+	\|IR \| povolení k pobytu (plastová karta)\|
		+	\|VS \| vízový štítek\|
		+	\|PS \| pobytový štítek\|
		+	\|IX \| povolení k pobytu (knížka)\|
		+	\|IE \| potvrzení o přechodném pobytu/osvědčení o registraci\|
		+
		+	Doklady vydané jiným státem se v ROB nevedou. Na odkazu [[https://szrcr.cz/cs/sluzby/spravci-a-vyvojari/vyvojari-agendovych-informacnich-systemu\|Digitální a informační agentura - Vývojáři agendových informačních systémů]] je ke stažení soubor s XSD popisy datových typů.

	{{tag>ROB "Registr obyvatel" "Základní registry" "Funkční celek"}}		{{tag>ROB "Registr obyvatel" "Základní registry" "Funkční celek"}}

2023/06/05 08:58		aktuální
Řádek 1:		Řádek 1:
	======eGovernment On-Line Service Bus / Informační systém sdílené služby======		======eGovernment On-Line Service Bus / Informační systém sdílené služby======

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

	* Publikovat služby pro sdílení údajů týkajících se konkrétního subjektu nebo objektu práva		* Publikovat služby pro sdílení údajů týkajících se konkrétního subjektu nebo objektu práva
Řádek 10:		Řádek 10:
	* 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)		* Zajištění nezávislého auditu výměny údajů (ukládá informace identifikující dotaz a odpověď a technický kryptografický otisk zprávy – hash)

-	V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|G1:gsbCtiData}} a {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|G11:gsbZapisData}} pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že	+	V eGSB/ISSS je oproti ISZR omezující podmínka pro použití elementu MapaAIFO. V tomto elementu může být při volání službami {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G1:gsbCtiData}} a {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G11:gsbZapisData}} pouze jediné AIFO. V odpovědi může být AIFO více. Důvodem je, že
-	eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí [[nap:zakladni_registry\|ORG]] identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|G1:gsbCtiData}} či {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|G11:gsbZapisData}} zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.	+	eGSB/ISSS je v principu multizdrojový systém. Jeden kontext může být publikován více publikátory/AIS a čtenář nemusí vědět, v kterém z nich se informace o fyzické osobě nachází. ISSS provádí logické vyhledání, kdy pomocí [[nap:zakladni_registry\|ORG]] identifikuje cílové AIS (vedou AIFO a publikují kontext) a na tyto publikátory následně posílá požadavek. Současně platí, že eGSB/ISSS nesmí jakkoli měnit payload zprávy, tedy ani nemůže „rozdělit“ a posílat po jednom na různé cíle. Výše zmíněné zatím platí pro všechny volání, avšak je v plánu tzv. metoda zúžení multizdrojového na jednozdrojový. Tedy pokud je jednoznačně určen cílový AIS, a tedy ho uživatel služby {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G1:gsbCtiData}} či {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|G11:gsbZapisData}} zná. Tímto by se dal odstranit požadavek na jedno AIFO pouze pro metodu zúžení na cílový AIS.

	Cílem je, aby klienti veřejné správy nebyli nuceni dokládat skutečnosti, o kterých veřejná správa již ví, či které vznikly dokonce na základě rozhodnutí veřejné správy. Většina skutečností potřebných pro rozhodování veřejné správy je již někde evidována, a to formou údajů v informačních systémech veřejné správy. Dále existují skutečnosti, které sice jsou na základě rozhodování veřejné správy, nicméně nejsou dosud vedeny v AIS jako údaje (příkladem je potvrzení o studiu, dohoda o chráněné dílně apod.). Zmapováním údajů v jednotlivých agendách, které probíhá nyní v rámci nových povinností ohlašovatelů vůči [[nap:rpp\|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		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 [[nap:rpp\|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
Řádek 39:		Řádek 39:
	- na základě zákonného zmocnění vedení údajů v agendě s označením čerpání v [[nap:rpp\|RPP]] (z moci úřední)		- na základě zákonného zmocnění vedení údajů v agendě s označením čerpání v [[nap:rpp\|RPP]] (z moci úřední)

-	Informace k informačnímu systému sdílení údajů jsou k dispozici na [[https://www.szrcr.cz/cs/isss-egsb\|stránkách SZR ČR]] včetně dokumentů:	+	Informace k informačnímu systému sdílení údajů jsou k dispozici na [[https://szrcr.cz/cs/isss-egsb\|stránkách SZR ČR]] včetně dokumentů:
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Publikace_AIS_na_ISSS_v1_06.pdf \|Publikace AIS na eGSB / ISSS}}	+	* {{ https://szrcr.cz/images/dokumenty/ISSS/Publikace_AIS_na_ISSS_v1_09_20231016.pdf \|Publikace AIS na eGSB / ISSS}}
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Pr%CC%8Cipojeni%CC%81_c%CC%8Ctena%CC%81r%CC%8Cske%CC%81ho_AISSSVU%CC%81_k_ISSS.pdf \|Připojení čtenářského AIS na eGSB / ISSS}}	+	* {{ https://szrcr.cz/images/dokumenty/ISSS/Vyuziti_sluzeb_ISSS_ctenarskymi_a_zdrojovymi_AIS_v1_07.pdf \|Využití služeb eGSB / ISSS čtenářskými a publikačními AIS}}
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Pr%CC%8Cipojeni%CC%81_publikac%CC%8Cni%CC%81ho_AISSSVU%CC%81_k_ISSS_.pdf \|Připojení publikačního AIS na eGSB / ISSS}}	+
-	* {{ https://www.szrcr.cz/images/dokumenty/ISSS/Vyuz%CC%8Citi%CC%81_sluz%CC%8Ceb_eGSB__ISSS_c%CC%8Ctena%CC%81r%CC%8Csky%CC%81mi_a_publikac%CC%8Cni%CC%81mi_AIS.pdf \|Využití služeb eGSB / ISSS čtenářskými a publikačními AIS}}	+

	===== Způsob komunikace mezi čtenáři a publikátory =====		===== Způsob komunikace mezi čtenáři a publikátory =====
Řádek 73:		Řádek 72:

	^Kód^Podrobný popis služby^Verze^		^Kód^Podrobný popis služby^Verze^
-	\|G1 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G1_gsbCtiData_v1_03.pdf \|gsbCtiData}} \|1.03 \|	+	\|G1 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiData}} \|1.03 \|
-	\|G2 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G2_gsbCtiZmeny_v1_01.pdf \|gsbCtiZmeny}} \|1.01 \|	+	\|G2 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiZmeny}} \|1.01 \|
-	\|G3 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G3_gsbVlozOdpoved_v1_02.pdf \|gsbVlozOdpoved}} \|1.02 \|	+	\|G3 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVlozOdpoved}} \|1.02 \|
-	\|G4 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G4_gsbVlozSoubor_v1_01.pdf \|gsbVlozSoubor}} \|1.04 \|	+	\|G4 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVlozSoubor}} \|1.04 \|
-	\|G5 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G5_gsbCtiSoubor_v1_01.pdf \|gsbCtiSoubor}} \|1.01 \|	+	\|G5 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiSoubor}} \|1.01 \|
-	\|G6 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G6_gsbVypisFronty_v1_01.pdf \|gsbVypisFronty}} \|1.01 \|	+	\|G6 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbVypisFronty}} \|1.01 \|
-	\|G7 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G7_gsbOdpovedZFronty_v1_01.pdf \|gsbOdpovedZFronty}} \|1.01 \|	+	\|G7 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbOdpovedZFronty}} \|1.01 \|
-	\|G8 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G8_gsbSmazatFrontu_v1_01.pdf \|gsbSmazatFrontu}} \|1.01 \|	+	\|G8 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbSmazatFrontu}} \|1.01 \|
-	\|G9 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G9_gsbProbe_v1_01.pdf \|gsbProbe}} \|1.01 \|	+	\|G9 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbProbe}} \|1.01 \|
-	\|G10 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G10_gsbCtiKontexty_v1_01.pdf \|gsbCtiKontexty }} \|1.01 \|	+	\|G10 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbCtiKontexty }} \|1.01 \|
-	\|G11 \|{{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_G11_gsbZapisData_v1_04.pdf \|gsbZapisData}} \|1.04 \|	+	\|G11 \|{{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|gsbZapisData}} \|1.04 \|
-	\|K1 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K1_katCtiSluzby_v1_01.pdf \|katCtiSluzby}} \|1.01 \|	+	\|K1 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiSluzby}} \|1.01 \|
-	\|K2 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K2_katCtiDetailSluzby_v1_01.pdf \|katCtiDetailSluzby}} \|1.01 \|	+	\|K2 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiDetailSluzby}} \|1.01 \|
-	\|K3 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K3_katCtiPrilohu_v1_01.pdf \|katCtiPrilohu}} \|1.01 \|	+	\|K3 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiPrilohu}} \|1.01 \|
-	\|K4 \| {{ https://www.szrcr.cz/images/dokumenty/ISSS/popis_slu%C5%BEeb_ISSS/Popis_sluzby_K4_katCtiEndpoint_v1_01.pdf \|katCtiEndpoint}} \|1.01 \|	+	\|K4 \| {{ https://www.szrcr.cz/cs/isss-egsb?view=article&id=316:popis-slu%C5%BEeb-isss-egsb&catid=25:isss \|katCtiEndpoint}} \|1.01 \|

2021/03/11 08:24		aktuální
Řádek 4:		Řádek 4:
	[[:start\|Národní architektura veřejné správy ČR]]		[[:start\|Národní architektura veřejné správy ČR]]

-	[[:ikcr\|1.Informační koncepce ČR]]	+	[[:uvod_dokumenty\|1.Architektonické dokumenty]]

-	[[:metody_dokument\|2.Metody řízení ICT VS ČR]]	+	[[:uvod_klicove_oblasti\|2.Klíčové oblasti architektury]]

-	[[:slovnik_egov\|3.Slovník pojmů eGovernmentu]]	+	*[[:uvod_klicove_oblasti#e\|Potřebnost informačních systémů a soulad s 3E]]
		+	[[:uvod_klicove_oblasti#strategie\|Koncepce a strategie úřad*ů]]
		+	*[[:uvod_klicove_oblasti#kanaly\|Obslužné kanály veřejné správy]]
		+	*[[:uvod_klicove_oblasti#dokumenty\|Elektronický oběh dokumentů]]
		+	*[[:uvod_klicove_oblasti#identifikace\|Identifikace v informačních systémech]]
		+	*[[:uvod_klicove_oblasti#data\|Strukturovaná data v ISVS, datové fondy a jejich sdílení]]
		+	*[[:uvod_klicove_oblasti#rozhrani\|Referenční rozhraní veřejné správy]]
		+	*[[:uvod_klicove_oblasti#ais\|Sdílené agendové a provozní informační systémy]]
		+	*[[:uvod_klicove_oblasti#kivs\|Komunikační infrastruktura veřejné správy]]
		+	*[[:uvod_klicove_oblasti#cloud\|Cloudové služby]]

-	[[:nar_dokument\|4.Národní architektonický rámec]]	+	[[:uvod_schvalovani\|3.Schvalování projektů a záměrů ICT]]

-	[[:nap_dokument\|5.Národní architektonický plán]]	+	[[:reporty\|4. Seznam reportů]]
-	* [[nap_dokument:uvod\|Úvod]]	+
-	* [[nap_dokument:architektonicka_vize_e_governmentu_cr\|Architektonická vize eGovernmentu ČR]]	+
-	* [[nap_dokument:pravidla_tvorby_a_udrzby_vlastni_ctyrvrstve_architektury_jednotlivych_uradu\|Architektura úřadu]]	+
-	* [[nap_dokument:architektura_a_sdilene_sluzby_verejne_spravy_cr\| Popis sdílených služeb, funkčních celků a tematických oblastí]]	+
-	* [[nap_dokument:pravidla_pro_funkcni_celky_architektury_jednotlivych_uradu\|Způsoby využívání sdílených služeb, funkčních celků a tematických oblastí]]	+
-	* [[nap_dokument:modely_nap_v_centralnim_ulozisti_a_v_ovs\|Modely NAP v centrálním úložišti a v OVS]]	+
-		+
-	[[:znalostni_baze\|6.Rozšiřující znalostní báze]]	+
-		+
-	[[:uvod_klicove_oblasti\|7.Klíčové oblasti architektury]]	+
-		+
-	[[:uvod_schvalovani\|8.Schvalování projektů a záměrů ICT]]	+

2021/04/30 09:06		aktuální
Řádek 5:		Řádek 5:

	Každý správce AIS, který eviduje subjekt, který není v [[nap:zakladni_registry\|základním registru]] má povinnost:		Každý správce AIS, který eviduje subjekt, který není v [[nap:zakladni_registry\|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.	+	-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.	+	-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.	+	-Zajisti aktualizaci údajů v Evidenci jiných fyzických osob, pokud o nich bude správce AIS informován.

	Výše popsaná situace však nefunguje, respektive z mnoha důvodů na všech zúčastněných stranách je nemožné ji tímto způsobem realizovat. Níže je tedy popsán budoucí stav, ke kterému je třeba dospět, aby se eliminovaly nežádoucí efekty plynoucí z toho, že jednotlivé evidence veřejné správy spravují subjekty, které nejsou v [[nap:zakladni_registry\|základních registrech]].		Výše popsaná situace však nefunguje, respektive z mnoha důvodů na všech zúčastněných stranách je nemožné ji tímto způsobem realizovat. Níže je tedy popsán budoucí stav, ke kterému je třeba dospět, aby se eliminovaly nežádoucí efekty plynoucí z toho, že jednotlivé evidence veřejné správy spravují subjekty, které nejsou v [[nap:zakladni_registry\|základních registrech]].
Řádek 35:		Řádek 35:
	*Bez propojení evidencí občanů EU či jiných třetích států nikdy nedosáhneme zaručené aktualizace údajů. Je proto nutné, aby agendy, které vedou jiné fyzické osoby měly zákonné zmocnění vyžadovat aktualizaci údajů od subjektu. Dokazování o existenci jedné identity je vždy v rukou subjektu, on musí prokázat, že i přechozí záznamy se týkají jeho – pokud se tak neprokáže, budou se nadále evidovat identity 2 nebo více – tento stav nebude horší než současný stav, může být pouze lepším nebo při nejhorším stejný		*Bez propojení evidencí občanů EU či jiných třetích států nikdy nedosáhneme zaručené aktualizace údajů. Je proto nutné, aby agendy, které vedou jiné fyzické osoby měly zákonné zmocnění vyžadovat aktualizaci údajů od subjektu. Dokazování o existenci jedné identity je vždy v rukou subjektu, on musí prokázat, že i přechozí záznamy se týkají jeho – pokud se tak neprokáže, budou se nadále evidovat identity 2 nebo více – tento stav nebude horší než současný stav, může být pouze lepším nebo při nejhorším stejný

-	==== Evidence jiných právnických osob ====	+	==== Přechodné řešení: AIFO pro osoby mimo registr obyvatel ====
		+
		+	Do doby, než evidence jiných fyzických osob vznikne, mohou AIS primárních editorů resortních evidencí získat AIFO i pro osoby, které nelze ztotožnit proti registru obyvatel, a publikovat o nich nereferenční identifikační údaje do ISSS. Identity založené tímto způsobem EJFO po svém vzniku převezme beze změny AIFO (§ 10 odst. 3 zákona č. 111/2009 Sb.). Podrobně viz [[nap:aifo_mimo_rob\|AIFO pro osoby, které nejsou vedeny v registru obyvatel]].
		+
		+	===== 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 [[nap:ros\|základním registru osob]]. V rámci rozvoje [[nap:zakladni_registry\|základních registrů]] a tím i celého [[nap:propojeny_datovy_fond\|PPDF]] se počítá s rozšířením o evidenci 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 [[nap:ros\|základním registru osob]]. V rámci rozvoje [[nap:zakladni_registry\|základních registrů]] a tím i celého [[nap:propojeny_datovy_fond\|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 [[nap:zakladni_registry\|základním registru]] má povinnost:		Každý správce AIS, který eviduje subjekt, který není v [[nap:zakladni_registry\|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ů.	+	-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.	+	-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.