Metodický pokyn. k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3

Metodický pokyn k vyplnění žádosti o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ B3 Odbor Hlavního architekta egovernmentu MV Praha, září 2018 verze 6.0 Toto dílo podléhá licenci Creative Commons Uveďte původ 4.0 Mezinárodní Licence. 1

Obsah Úvodní informace a pokyny... 3 Způsob podání žádosti...3 Proces posuzování projektů je následující....3 Způsob vyplnění Formuláře žádosti....3 1 Základní podmínky projektu... 4 1.1 Úvodní informace o žadateli o stanovisko k projektu...4 1.2 Shrnutí charakteristik projektu...5 1.3 Popis, potřebnost a výstupy projektu...5 2 Architektonické informace k funkčnímu celku... 6 2.1 Dodržení architektonických principů NA VS ČR...6 2.2 Enterprise architektura projektu a její kontext...7 2.2.1 Strategie a směrování - Motivační architektura...7 2.2.2 Efektivita projektu Výkonnostní architektura...7 2.2.3 Poskytování veřejných služeb - Byznys architektura...8 2.2.4 Architektura informační systémů (aplikací a dat)... 12 2.2.5 Technologická architektura vrstva IT technologie (HW a SW)... 18 2.2.6 Technologická architektura vrstva komunikační infrastruktury... 19 2.2.7 Bezpečnostní architektura... 19 2.2.8 Shoda s pravidly, standardizace a dlouhodobá udržitelnost... 20 2.2.9 Přehled služeb čtyřvrstvé architektury... 21 2.3 Kontrola shody architektury řešení projektu se vzory sdílených služeb egovernmentu... 21 2.4 Plán projektu... 22 3 Další údaje o projektu... 23 3.1 Připravenost projektu k realizaci... 23 3.1.1 Majetkoprávní vztahy projektu (povinné jen pro projekty zakázkového vývoje SW)... 23 3.2 Ekonomické parametry funkčního celku... 23 3.2.1 Hodnota výdajů a ekonomická náročnost projektu.... 23 3.3 Plán údržby, dlouhodobá udržitelnost výstupů projektu... 25 4 Vyjádření k bezpečnostním aspektům... 26 5 Upozornění a doporučení... 26 6 Přílohy... 26 2

Ú V O D N Í I N F O R M A C E A P O K Y N Y Vzor žádosti, který dostáváte do rukou, vznikl na základě úkolu uloženého bodem 4. článku II. usnesení vlády České republiky ze dne 2. listopadu 2015, č. 889, k dalšímu rozvoji informačních a komunikačních technologií služeb veřejné správy, zajistit dodržování Základních zásad postupu při čerpání finančních prostředků na výdaje související s informačními a komunikačními technologiemi s hodnotou více než 6 mil. Kč ročně, jakož i na základě zmocnění obsaženého v 4, odst. 1 písm. e) a odst. 2 písm. b) a g) zákona 365/2000 Sb., o informačních systémech veřejné správy, v platném znění, dle nichž se Ministerstvo vnitra ČR vyjadřuje k návrhům dokumentací programů obsahujících pořízení nebo technické zhodnocení informačních systémů veřejné správy, k investičním záměrům akcí pořízení nebo technického zhodnocení informačních systémů veřejné správy a k projektům informačních systémů veřejné správy určených k výkonu státní správy, vždy pokud jejich předpokládaná hodnota přesahuje částku 6 mil. Kč bez DPH, resp. 30 mil. Kč bez DPH vynaložených za 5 let. Pro usnadnění zpracování žádosti o stanovisko vytvořil OHA dva samostatné dokumenty: a) Formulář žádosti o stanovisko Hlavního architekta egovernmentu, b) Metodický pokyn k vyplnění formuláře žádosti o stanovisko Hlavního architekta egovernmentu (tento dokument). Způsob podání žádosti Žádost podávejte Ministerstvu vnitra ČR, konkrétně odboru Hlavního architekta egovernmentu (dále jen OHA ) do datové schránky ID: 6bnaawp, a to ve formě volného dopisu obsahujícího text žádám o posouzení projektu dle usnesení vlády č. 889 ze dne 2. listopadu 2015 (případně dle zákona 365/2000 Sb., či obojího) na hlavičkovém papíře (v šabloně) organizace žadatele podepsaný osobou oprávněnou k podání žádosti jménem organizace. Přílohou takovéto Žádosti je vyplněný formulář žádosti o stanovisko OHA včetně všech případných příloh tohoto formuláře. Posuzování a finanční limit (6 mil. Kč ročně) se vztahuje na záměr vydat prostředky, bez ohledu na to, kolika projekty či soutěžemi bude realizace záměru provedena. Pokud se jednoho řešení týká více záměrů, je možno žádosti o stanovisko k těmto záměrům spojit do jediné žádosti. Plný formulář žádosti bez zjednodušení slouží pro nákup nových informačních systémů či jejich údržbu/rozvoj, respektive pro vybudování IT podpory nové nebo významně pozměněné agendy, její části nebo veřejné služby úřadu. Formulář žádosti je univerzálně použitelný a robustní tak, aby pokryl celé spektrum možných záměrů, na které se vztahuje schvalovací povinnost. Proces posuzování projektů je následující. Podatelna Ministerstva vnitra žádost zaeviduje a ve spisové službě přidělí OHA. Ten zkontroluje kompletnost žádosti, v případě nedostatků si vyžádá doplnění, a rozhodne o délce lhůty vyřízení: Základní projekty lhůta do 30 kalendářních dnů od zaevidování nebo Složité projekty lhůta do 60 kalendářních dnů od zaevidování. Lhůta na vyřízení začíná běžet převzetím kompletní žádosti. V průběhu posuzování je OHA oprávněn vyžádat doplnění nebo vysvětlení ze strany Žadatele. Po dobu od odeslání žádosti o doplnění až do doručení doplnění, na jehož základě je možné rozhodnout, je běh lhůty pozastaven. Stanovisko, které OHA vydá, zašle původnímu Žadateli zpět prostřednictvím Informačního systému Datových schránek. Pro urychlení procesu vyřízení, poskytuje OHA Žadateli možnost konzultovat projekt ještě před podáním žádosti. Způsob vyplnění Formuláře žádosti. Formulář žádosti obsahuje dva typy položek k vyplnění: tabulku, do které Žadatel požadované informace do příslušných buněk buď vepisuje, nebo je vybírá z předpřipravené nabídky variant (ve formuláři červeně ), prostor pro vložení diagramu, označený <zde vložte diagram (-y)>. 3

Formulář B3 slouží pro předání informací o architektuře celého funkčního celku na základě závazku z žádosti či žádostí typu B1. Funkční celek znamená řešení v celé jeho komplexitě, jak je v prostředí organizace/státu nasazeno. Příkladem budiž informační systém, ke kterému je realizován projekt na vytvoření nového modulu systému. Pak je projektem pouze nový modul, ke kterému je vyplněna žádost. Funkčním celkem je ovšem celý informační systém zahrnující všechny jeho moduly a rozhraní. Pro definici funkčního celku není relevantní, kolik je k němu uzavřeno smluv na podporu nebo kolik dodavatelů vytvářelo jeho jednotlivé části. Rozhodující je technologická provázanost (např. SOA) anebo logická souvislost. Příklady funkčních celků je ADIS (daňový systém), IIS ČSSZ (integrovaný informační systém správy soc. zabezpečení), datové centrum (pro případ rozšiřování o nové technologie) apod. Jeden formulář typu B3 může být splněním závazku ze všech předchozích žádostí typu B1. Důvodem je, že záměr dle B1 se může týkat jen jedné části celého funkčního celku. V případě, že některá část Formuláře není pro váš projekt nebo kontext projektu relevantní, uveďte zde: není relevantní, aby bylo zřejmé, že jste položku nevyplnili záměrně. V případě, že architektura projektu, popsaná ve formuláři žádosti, není v souladu s architektonickými principy Národní architektury VS, požadavky na soulad řešení s kontextem architektury úřadu, požadavky na soulad řešení s kontextem architektury egovernmentu, architektonickými vzory řešení sdílených služeb egovernmentu apod., ale přesto existuje objektivní důvod realizovat projekt požadovaným způsobem, uveďte / vyberte z rozbalovacího seznamu v příslušné části formuláře, že žádáte o výjimku, a pro každou takovou výjimku vyplňte žádost o udělení výjimky, uveďte ji do poslední kapitoly s názvem Přílohy a přiložte ji k žádosti o stanovisko. Vzor žádosti o udělení výjimky je ke stažení na webu OHA 1 1 Z Á K L A D N Í P O D M Í N K Y P R O J E K T U 1.1 Úvodní informace o žadateli o stanovisko k projektu Zde uveďte základní identifikační údaje o organizaci, která vystupuje jako žadatel o stanovisko. Na rozdíl od studie proveditelnosti Integrovaného regionálního operačního programu (IROP) je žadatel organizace, která bude vynakládat finanční prostředky na realizaci projektu, nejedná se tedy o toho, kdo zpracovával formulář. V tabulce 1: Úvodní informace o žadateli projektu, vyplňte: Organizace žadatele plný oficiální název organizace, adresu sídla a identifikační číslo (IČ) organizace, která žádost podává. Ředitel pro informatiku nebo Statutární zástupce jméno a příjmení, název zastávané funkce v organizaci žadatele, mailovou adresu a telefonní kontakt osoby, která svým podpisem stvrzuje podání žádosti o stanovisko OHA, a která je k tomu oprávněná podpisovým řádem organizace. Kontaktní osoba projektu jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, na níž se OHA může obrátit s případnými žádostmi a nejasnosti souvisejícími s žádostí o stanovisko. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace, jejímž je tato osoba pracovníkem. Architekt projektu jméno a příjmení, název zastávané funkce v organizaci, mailovou adresu a telefonní kontakt osoby, která při přípravě projektu působí v roli architekta. V případě, že se nejedná o interního zaměstnance organizace, uveďte k funkci rovněž název organizace, jejímž je tato osoba pracovníkem. Datum vypracování žádosti datum dokončení posledních úprav / konečné verze, formuláře žádosti o stanovisko. V případě podávání aktualizované žádosti toto pole nezapomeňte změnit. V tabulce 2: Druh žádosti, zvolte položku, která podle skutečnosti vystihuje, dle jakých předpisů je požadováno stanovisko OHA, tj. zda dle usnesení vlády ze dne 2. listopadu 2015, č. 889, nebo zákona 365/2000 Sb. 1 http://www.mvcr.cz/clanek/hlavni-architekt-egovernmentu.aspx 4

1.2 Shrnutí charakteristik projektu V tabulce 3: Shrnutí charakteristik projektu, vyplňte a zvolte skutečnosti odpovídající variantu: Název projektu srozumitelný název projektu, k němuž je podávána žádost o stanovisko. Nepoužívejte zkratky, které nejsou všeobecně známé v prostředí ICT nebo ve veřejné správě. Seznam předchozích žádostí B1 a B2 k funkčních celku: seznam předchozích žádostí, které tato žádost obsahuje. Předpokládaný počet let využívání výstupů projektu (počet let od začátku využívání do konce využívání) hrubý odhad počtu let od zahájení ostrého provozu do předpokládaného vyřazení z provozu. Vyřazením z provozu je myšleno nahrazení jiným projektem nebo ukončení bez náhrady. V případě, že je předpokládáno využívání (provoz) více než 5 let, pak je možné uvést jen Více než 5 Možnost zveřejnění formuláře z nabízených variant vyberte položku, zda a za jakých podmínek je možné formulář zveřejnit, resp. poskytnout podle předpisů upravujících svobodný přístup k informacím. Pokud formulář není možné plně bez úprav zveřejnit, resp. poskytnout, vysvětlete do volného pole důvod a změny, které je potřeba udělat, aby to bylo možné. Určení věcného správce, technického správce a provozovatele Věcný správce Věcný správce (gestor) je organizační útvar/složka, která je věcně odpovědná za výkon předmětné agendy, tj. rozhoduje o obsahu a pravidlech fungování služby. V této roli je zodpovědný za definici procesu, který službu dodává, definici funkcionality podpůrné ICT služby a dat, za shodu funkcionality aplikace s legislativou a za definici objemových a kvalitativních parametrů podpůrné ICT služby (počet uživatelů, doba provozu služby, dostupnost služby, doba odezvy atd.). Věcným správcem služby veřejné správci může být pouze orgán veřejné moci, tj. státní orgány a samosprávné celky). Každá agendová služba má vždy jen jednoho správce. Je jím orgán zodpovědný za službu (agendu). Provozní služba mívá obvykle více správců. Když služba má jednoho správce, jedná se o centralizovaně řízenou službu. Technický správce Technický správce je útvar nebo organizace, která rozhoduje o způsobu (jakým software, jakým hardware, odkud, apod.) a formě (v jakém režimu tj. zda interně, kombinovaně či externě) bude požadovaná služba zajišťována (realizována). Stanovuje podmínky realizace a produkční podmínky (včetně podpůrných ICT služeb) tak, aby služba byla poskytována v souladu s požadavky věcného správce. Technický správce je pro každou veřejnou službu jen jeden. V rámci organizace je určen organizačním řádem nebo vedoucím představitelem organizace, případně ho - na základě obecně platných pravidel, určuje věcný správce. Provozovatel Provozovatel (poskytovatel služby) je útvar nebo organizace, jenž službu provozuje a dodává zákazníkům. Provozovatelů služby může být více (viz např. výdej občanských průkazů, e-mail), mohou být jak interní (autentizovaní uživatelé), tak externí (klienti). Když služba má jednoho provozovatele, jedná se o centralizovaně provozovanou službu. 5-leté TCO (celkové náklady vlastnictví) v Kč bez DPH předběžný, kvalifikovaný odhad výše externích výdajů v českých korunách bez DPH na realizaci projektu a projekce externích výdajů na přesně 5-letý provoz (přepočet kvůli srovnatelnosti projektů s rozdílnou dobou udržitelnosti). Jedná se o součet hodnot uvedených ve sloupci 3 tabulky v kapitole 3.2.1. formuláře žádosti. 1.3 Popis, potřebnost a výstupy projektu V tabulce 4: Popis funkčního celku, vyplňte: Popis výchozí situace projektu (tzv. As-Is) popište výchozí stav, ze kterého projekt vychází. Příklad výchozí situace může být zastaralý informační systém, který již v průběhu příštího roku nebude odpovídat legislativě. Projekt bude navázán na určitý projektový okruh v rámci egovernmentu a bude odpovídat přijatým strategiím. Požadavky / kritéria zákazníka jsou určující pro stanovení toho, co je třeba změnit, co lze využít bez e změny a co vybudovat zcela nově. Východiskem proto vždy musí být objektivní analýza současného stavu ne jen technické infrastruktury, ale i organizační, tzn.: procesů, politik, personálního zabezpečení atd. Výstupem této analýzy by vždy měly být: 5

popis a architektura současného stavu obsahující uvedení nedostatků identifikovaných s využitím určených kritérií, konečný návrh byznys a technické architektury cílového řešení, návrh systému optimalizace současných a nových HW technologií, Jako součást prokázání optimálnosti zvolené varianty by každý projekt měl obsahovat prokazatelné doložení hospodárnosti, tj. jasně specifikovat, co z existující infrastruktury a organizačních pravidel: lze / bude využito beze změn, bude využitelné za jakých změn a co, nadále využitelné nebude, včetně zdůvodnění proč. návrh nezbytného rozsahu nové provozně-technické a bezpečnostní dokumentace V rámci Veřejné správy součástí popisu současného stavu musí být i: a) popis propojení (agendového) i sdílení (dat a podpůrných aktiv) s dalšími systémy, b) schéma začlenění předmětné služby / systému do Enterprise architektury předkládající organizace / OVM včetně případných vazeb na sdílené služby veřejné správy, c) popis začlenění nové služby / systému, do současného kybernetického prostředí / Enterprise architektury předkládající organizace / OVM. 2 A R C H I T E K T O N I C K É I N F O R M A C E K F U N K Č N Í M U C E L K U V této kapitole jsou uvedeny informace o všem, co ovlivňuje motivaci a obsah předkládaného projektu, zejména pak všechny aspekty struktury a chování části úřadu, zahrnuté do projektu. Dále pak kontext architektury úřadu ve vztahu ke sdíleným službám egovernmentu. Struktura architektonické části dokumentu vychází ze struktury domén obsahu Národní architektury VS ČR. 2.1 Dodržení architektonických principů NA VS ČR Architektonické principy jsou z cílů rozvoje egovernmentu odvozená pravidla, která slouží primárně k tomu, aby byla plně dodržena při návrzích cílové architektury veřejné správy (a jejích informačních systémů), které tak největší měrou naplní reformní cíle strategie veřejné správy. Definovanými architektonickými principy jsou: Název principu Dostupnost Znění principu Služby veřejné správy musí být všem dostupné především v elektronické podobě, v jakémkoliv čase, v jakékoliv lokalitě a musí být poskytovány nediskriminačním a 6

Název principu Použitelnost Důvěryhodnost Znění principu bezbariérovým způsobem. Služby veřejné správy musí být navrhovány s ohledem na potřeby klienta tak, aby mohl vždy vyřídit svoji životní situaci v úplnosti elektronickou službou. Elektronické služby veřejné správy musí být koncipovány takovým způsobem, aby klienti měli plnou důvěru k jejich využívání. Transparentnost Pořízení, rozvoj i provoz služeb veřejné správy musí být vždy zajištěn transparentním způsobem. Bezpečnost Spolupráce a sdílení Udržitelnost Technologická neutralita Elektronické služby musí zajistit adekvátní zabezpečení datového obsahu i přístupu k datům a službám samotným. Elektronické služby veřejné správy jsou navrhovány a budovány primárně na principu spolupráce a sdílení informací a zdrojů mezi úřady veřejné správy. Pořízení nových služeb veřejné správy musí být vždy opodstatněné a služby musí být navrhovány jako dlouhodobě využitelné. Služby veřejné správy musí být koncipovány jako technologicky a platformově nezávislé a nesmí být závislé na omezené skupině dodavatelů. 2.2 Enterprise architektura projektu a její kontext Obecně platí, že všechny prvky modelu architektury, zachycené v některém z katalogů, se musí objevit také v odpovídajících grafických diagramech a naopak. Katalogy jsou předpokladem úspěšné tvorby digramů. Diagramy nad rámec katalogů přinášejí informace o vzájemných vazbách mezi objekty uvnitř katalogů i mezi nimi. V tabulce 5: Vyplňte, jakým způsobem předáváte model Enterprise architektury řešení projektu v rámci žádosti o stanovisko. Případně vysvětlete, proč to z Vaší strany není možné. 2.2.1 Strategie a směrování - Motivační architektura V tabulce 6: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky) vysvětlete důvody, které vedly k potřebě realizace projektu a podstatné skutečnosti, které mají vliv na způsob realizace projektu. Popište, pro jakou změnu je projekt navržen, co změnu vyvolalo, kdo stojí o její realizaci a jak se pozná, že měl projekt požadovaný efekt do příslušných oblastí výkonu veřejné správy. 2.2.2 Efektivita projektu Výkonnostní architektura V tabulce 7: Vysvětlete dopad projektu na hospodárnost, účelnost, účinnost a kvalitu služeb v organizaci, objasněte, s jakými přínosy je projekt spojen, jaké ukazatele efektivity, výkonnosti a kvality jsou pro projekt relevantní, pokud nějaké a jak je možné je měřit. Rozdělení ukazatelů výkonnosti vychází z tzv. Logického modelu řízení výkonnosti a zodpovědnosti, viz následující schéma. Z něj je patrné, že strategické cíle (politiky) je možno naplňovat pouze konkrétními činnostmi (službami veřejné správy), které i díky podpoře ICT řešeními mohou být (měly by být) efektivnější než před projektem. Schéma ukazuje vzájemný vztah ukazatelů efektivity (3E), které jsou detailně vysvětleny pod čarou. 7

Dále uveďte vliv projektu na zvyšování úrovně a kvality předmětné služby, tj. hodnoty služby vnímané jejími spotřebiteli, klienty veřejné správy. V tabulce 8: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb, popište jednotlivé nové nebo měněné služby v rámci projektu a specifikujte jejich SLA neboli požadovanou úroveň služby: Název v rámci projektu nově zřizované nebo měněné služby: žadatelem definovaný název Specifikace SLA parametru služby: popis zda jde o dostupnost, čas potřebný k obnovení, čas potřebný k reakci na incident apod. Sjednaná mezní hodnota SLA parametru: mezní hodnota pro SLA parametr, např. pro dostupnost 99,9% Sjednaná metrika: sjednaný způsob měření a vyhodnocení parametru SLA. Pro každou službu může být definováno více SLA parametrů V tabulce 9: Popis klíčových měřitelných ukazatelů výkonnosti (KPI), popište jednotlivé nové nebo měněné služby v rámci projektu a specifikujte jejich KPI neboli klíčových ukazatelů výkonnosti: Název v rámci projektu nově zřizované nebo měněné služby: žadatelem definovaný název Kolik stojí každá ukončená transakce, kterou poskytujete - popište předpokládané náklady na transakci (celá služba od začátku do konce) v Kč bez DPH. Jaké procento uživatelů je spokojeno s poskytovanou službou: uveďte hodnoty jaké procento uživatelů je s elektronickou službou spokojeno. Jaké procento transakcí je úspěšně dokončeno / kolik procent ze započatých transakcí je dovedeno uživatelem do úspěšného konce. Jaké procento uživatelů si zvolí raději elektronickou formu služby než ne-elektronickou / kolik procent lidí preferuje elektronickou verzi služby oproti její asistované podobě. 2.2.3 Poskytování veřejných služeb - Byznys architektura Tato část architektury projektu objasňuje, kdo (aktéři), v jaké roli a kudy (komunikační kanály) se zapojuje do činností úřadu, zahrnutých do projektu. Cílem byznys architektury v této žádosti je poznat a pochopit, které funkce úřadu jsou vykonávány jako služba, kým, pro koho a kterým kanálem. V tabulce 10: Katalog organizačních jednotek, aktérů a rolí, vyplňte Aktér (organizace, organizační jednotky / úředníci, klienti veřejné správy) seznam orgánů veřejné moci a případně jejich organizačních útvarů či typových pracovníků a typových klientů veřejné správy (občanů i organizací) - všechny subjekty, jichž se řešení realizované projektem dotýká. Role aktérů při výkonu a příjmu služby seznam rolí, ve kterých vystupují aktéři uvedení v předchozím seznamu. Pro katalog aktérů a katalog rolí uveďte následující údaje: Název objektu název aktéra/role. 8

Počet uživatelů IS odhad počtu aktérů/rolí, kteří budou uživateli informačního systému, jenž je předmětem projektu. Pokud předmětem projektu není žádný informační systém, tak sloupec nevyplňujte. Celkový součet přes všechny kategorie je přirozeně větší, než celkový počet uživatelů, protože uživatelé mohou být rozepsáni současně do více kategorií. Jeden uživatel se započte současně do organizace, do role i do typického aktéra. Počty uživatelů celého IS uveďte alespoň jednou, v té kategorii, kde se Vám to podaří nejlépe odhadnout. Vysvětlení významu objektu bližší objasnění aktéra/role, tak aby bylo zcela zřejmé, oč se jedná, není-li dostatečný již sám název. V tabulce 11: Katalog funkcí a procesů veřejné správy a ve veřejné správě, vyplňte Agendové funkce (agendy dle RPP, dále neregistrované, podpůrné a provozní agendy nebo funkční oblasti) seznam funkcí organizace odpovídajících jednak agendám registrovaným nebo neregistrovaným působícím na vnějšek organizace (např. výkon kontrolní činnosti) a dále podpůrným a provozním funkcím působícím dovnitř organizace (např. účetnictví nebo personalistika). Uvádějte jen takové funkce, které jsou předmětem projektu zaváděny, měněny, podporovány či jinak dotčeny. Procesy v agendách nebo funkčních oblastech seznam procesů, které jsou vykonávány za účelem výkonu a naplňování funkcí uvedených v přechozím katalogu. Funkce (činnosti) řazené v procesu nebo samostatně existující na podporu agend / funkčních oblastí nepovinný seznam standardních činností vykonávaných v rámci procesů uvedených v předchozím katalogu nebo i činností, které nejsou řazeny v žádném procesu, ale jsou vykonávány v rámci funkce organizace uvedené v katalogu předcházejícím procesům. Pro katalog funkcí a procesů uveďte následující údaje: Název objektu název nebo označení funkce nebo procesu. Vysvětlení významu objektu bližší objasnění funkce nebo procesu, tak aby bylo zcela zřejmé, co je jeho obsahem a účelem, není-li dostatečný již sám název. V tabulce 12: katalog (interních a externích) služeb veřejné správy, pro jednotlivé služby vyplňte Interní služby veřejné správy seznam interních služeb veřejné správy (poskytované uvnitř veřejné správy jiným veřejným organizacím), které jsou předmětem projektu zaváděny, měněny nebo podporovány. Externí služby veřejné správy seznam externích služeb veřejné správy (poskytované směrem ke klientům veřejné správy, tj. občanům a organizacím), které jsou předmětem projektu zaváděny, měněny nebo podporovány. Pro katalog služeb uveďte následující údaje: Název služby název interní nebo externí služby. Kdo poskytuje službu označení poskytovatele služby (typicky role), tedy toho, kdo službu poskytuje (dodává, nabízí). Kdo je konzumentem služby označení typicky role, která službu využívá a přijímá její hodnotu. Konzumenty mohou být uživatelé z řad veřejné správy (interní i externí) i veřejnost (občané a komerční subjekty). Klíčovým prvkem rozdělení z hlediska poskytovaných funkcionalit je, zda jde o uživatele autentizované, nebo anonymní. Výčet použitých obslužných rozhraní služby seznam rozhraní (komunikačních a obslužných kanálů), přes které je služba poskytována konzumentům. Do pole uveďte výčet všech rozhraní oddělených středníkem nebo čárkou. V tabulce 13: Využití front-office rozhraní předmětem projektu, zvolte z nabízených variant a vyplňte Asistovaná přepážka uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem osobně na fyzické přepážce s využitím asistence vyškoleného pracovníka. Webový portál uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem prostřednictvím samoobslužného webového portálu. Datová zpráva (ISDS) uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem zasláním datové zprávy do datové schránky úřadu. Elektronicky podepsaný dokument do e-podatelny uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem zasláním elektronicky podepsaného dokumentu. 9

Listinnou cestou do podatelny uveďte, zda bude moci klient veřejné správy vykonat kontakt s úřadem listinným podáním poštou nebo osobně na podatelně úřadu. Pro katalog funkcí a procesů uveďte následující údaje: Využití vyberte skutečnosti odpovídající variantu, tj. zda je rozhraní (obslužný kanál) v projektu zahrnut (Ano) nebo není (Ne) či je pro konkrétní projekt takový kanál zcela Nerelevantní. Popis využití rozhraní v projektu bližší objasnění, tak aby bylo zcela zřejmé, k čemu bude obslužný kanál sloužit a v jakém rozsahu. V tabulce 14: Využití propojeného datového fondu, zvolte z nabízených variant a vyplňte Čtení referenčních údajů FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis nových FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů FO (ROB) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru obyvatel. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Čtení referenčních údajů PO (ROS) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis nových organizací (ROS) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů PO (ROS) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru osob. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Čtení referenčních údajů míst a adres (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, čerpat referenční údaje (číst) z Registru územní identifikace, adres a nemovitostí. Zápis nových územních id. (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat nové záznamy do Registru územní identifikace, adres a nemovitostí. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Editace referenčních údajů míst a adres (RÚIAN) uveďte, zda bude řešení, jež je předmětem projektu, editovat referenční nebo jiné údaje v Registru územní identifikace, adres a nemovitostí. Vyberte volbu Nerelevantní, pokud k tomu nemáte zákonné zmocnění. Zápis a využití práv a povinností při využívání údajů agend (RPP) uveďte, zda bude řešení, jež je předmětem projektu, využívat nebo zapisovat práva a povinnosti z Registru práv a povinností. Zápis rozhodnutí o změnách údajů agend dle 52 zák. 111/2009 Sb. (RPP) uveďte, zda bude řešení, jež je předmětem projektu, zapisovat rozhodnutí do Registru práv a povinností. Čerpání informací z agend jiných úřadů (Integrační platformy, egsb) uveďte, zda bude řešení, jež je předmětem projektu, využívat (čerpat) nějaká data prostřednictvím služeb egon Service Bus nebo jiných integračních platforem. Uveďte jaká data a od koho budou čerpána. Poskytování informací agendám jiných úřadů (Integrační platformy, egsb) uveďte, zda bude řešení, jež je předmětem projektu, publikovat nějaká data prostřednictvím služeb egon Service Bus nebo jiných integračních platforem. Uveďte jaká data a komu budou poskytována. Pro seznam využití propojeného datového fondu uveďte následující údaje: Použito výběr ze seznamu, zda je pro projekt prvek propojeného datového fondu Nerelevantní nebo zda je jeho použití plánováno (Ano). Jejich nepoužití, i když je relevantní, znamená nutnost požádat o výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. 10

Vysvětlení bližší objasnění rozsahu a způsobu využití prvku propojeného datového fondu. Případně, pokud to není zcela jasné, uveďte proč je použití nerelevantní. Zákonné zmocnění k přístupu uveďte právní předpis, který umožňuje v projektu využít prvek propojeného datového fondu, pokud je jeho využití plánováno. V tabulce 15: Využití dalších klíčových prvků egovernmentu v byznys architektuře projektu, zvolte z nabízených variant a vyplňte, informace o cílovém stavu, tj. využívání kterých prvků egovernmentu povinných k využití na byznys vrstvě je nebo není v rámci projektu plánováno. Identifikace, autentizace úředníka využití identity úředníka z JIP/KAAS (jednotný identitní prostor/katalog autentizačních a autorizačních služeb) pro identifikaci uživatelů informačního systému z řad pracovníků veřejné správy. Identifikace, autentizace klienta dodržení zákona č. 250/2017 Sb., o elektronické identifikaci pro identifikaci uživatelů informačního systému z řad veřejnosti. Doručování využití datových schránek pro účely doručování jiným veřejným institucím a soukromoprávním subjektům (organizacím a občanům) a příjem od jiných veřejných institucí. Dodávání využití datových schránek pro účely příjmu nebo odesílání mezi veřejnou institucí a soukromoprávním subjektem (organizace nebo občan), které není činěním úkonu vůči OVM (např. faktury). Provádění úkonů využití datových schránek pro účely příjmu úkonů učiněných soukromoprávním subjektem vůči OVM (např. podání od organizací nebo občanů). Pro seznam klíčových prvků egovernmentu uveďte následující údaje: Použito výběr ze seznamu, zda je pro projekt prvek národního egovernmentu Nerelevantní (pro službu povinnost neplatí nebo už naopak tuto povinnost splňuje, a tedy ji neřeší) nebo zda je jeho použití plánováno (Ano). Jejich nepoužití, v případě, že je pro danou službu relevantní, znamená nutnost požádat o výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, zde uveďte číslo příslušné žádosti o výjimku, které má v poslední kapitole Přílohy. V tabulce 16: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích, vyplňte vysvětlení, jak budou řešeny: identifikace, autentizace a autorizace uživatelů systému a to jak interních (úředníků), tak i externích klientů (občanů). Postupně popište: Služba využívající identifikaci, autentizaci a autorizaci: Název každé služby, které využívá pro své fungování identifikaci, autentizaci a autorizaci nebo např. jen identifikaci. Vysvětlení způsobů identifikace, autentizace a autorizace: Vysvětlete způsob ověření identity subjektů / uživatelů v jejich rolích pro službu a informační systém. Například využití NIA, interního IDM nástroje, apod. Druh autentizace: Popište konkrétní technický způsob autentizace, např. jméno+heslo; dvoufaktorová autentizace, Token kartička, apod. Dále zde uveďte: Model byznys architektury (výkonu veřejné správy) pohled činnostních funkcí požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: http://www.mvcr.cz/clanek/agenda-odboru-hlavniho-architekta-egovernmentu.aspx?q=y2hudw09na%3d%3d Model byznys architektury (výkonu veřejné správy) pohled služeb veřejné správy požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: http://www.mvcr.cz/clanek/agenda-odboru-hlavniho-architekta-egovernmentu.aspx?q=y2hudw09na%3d%3d V tabulce 17: Dodržení architektonických principů byznys vrstvy, pro jednotlivé principy, zvolte odpověď, která vyjadřuje, zda projekt je v souladu uvedenými požadavky, nebo ne, a v případech, kdy je požadavek pro projekt relevantní, ale není s ním v souladu a žádáte výjimku, zde uveďte číslo příslušné žádosti o výjimku, které má v poslední kapitole Přílohy. Pro seznam architektonických principů uveďte následující údaje: 11

Dodrženo výběr ze seznamu, zda je pro projekt požadavek Nerelevantní nebo zda je jeho naplnění plánováno (Ano). Nenaplnění, i když je relevantní, znamená většinou nutnost požádat o výjimku. Nepovinné jsou požadavky, které jsou ve sloupci Č. výjimky needitovatelné a šedě podbarvené. Č. žádosti o výjimku v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Pro nepovinné požadavky (šedě podbarvené) se nevyplňují nikdy. Způsob a míra naplnění vysvětlete jakým způsobem je projektem naplněn požadavek, případně vysvětlete, proč naplněn není nebo je nerelevantní. V tabulce 18: Vysvětlení v kontextu byznys architektury úřadu, tedy, vyplňte, jaké k projektu existují či jeho realizací vzniknou procesní / kompetenční / motivační duplicity a proč, a jaké jsou další souvislosti uveďte všechny duplicity, které se na byznys vrstvě vyskytují, jako je například více úzce specializovaných obslužných kanálů (např. webových portálů). Popište vztahy předmětu projektu ke všem obdobným řešením v úřadu, v resortu a v celém státu. Uveďte do kontextu všechny do projektu zahrnuté funkce (procesy či služby). Vysvětlete, jak případně tato služba souvisí (je sdílena, sdílí / vyměňují si data, ) s ostatními vykonávanými službami pracovišť rozšířeného řetězce. Vysvětlení byznys architektury projektu prostor pro vysvětlení všech dalších potřebných souvislostí a pro projekt důležitých informací, spojený s výše uvedenými architektonickými objekty, anebo je doplňující. 2.2.4 Architektura informační systémů (aplikací a dat) Vrstva architektury informačních systémů se dělí na dvě dílčí, na aplikační architekturu a datovou architekturu. 2.2.4.1 Architektura informační systémů část: Aplikační architektura Tato část architektury projektu objasňuje, které aplikační komponenty budou projektem zavedeny, změněny nebo zrušeny, jaká jsou jejich vzájemná a externí rozhraní a na podporu kterých byznys funkcí slouží. V tabulce 19: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí, zvolte odpovídající druh položky a vyplňte Komponenty, funkce a aplikační služby vytvářené nebo významně měněné v rámci záměru (žádosti) seznam aplikačních komponent, jejich funkcí a jimi poskytovaných služeb, jejichž vytvoření, úprava nebo rozšíření je předmětem projektu. Ostatní komponenty, funkce a aplikační služby integrované na výše uvedené nebo jinak podstatné pro žádost seznam aplikačních komponent, jejich funkcí a jimi poskytovaných služeb, které věcně či technicky souvisí s prvky uvedenými v předchozím katalogu prvků, jež jsou předmětem projektu. Pro katalog aplikačních komponent a funkcí uveďte následující údaje: Typ prvku určení, zda je položka katalogu komponenta, funkce nebo služba. Název prvku název nebo označení prvku. Vysvětlení významu aplikačních komponent, funkcí a služeb bližší objasnění obsahu a významu prvku, tak aby bylo zcela zřejmé, k čemu slouží a co zajišťuje, není-li dostatečný již sám název. V tabulce 20: Katalog aplikačních rozhraní, vyplňte Interní rozhraní seznam aplikačních rozhraní řešení mířených na další aplikace uvnitř úřadu, případně resortu, krajské korporace, apod. Externí rozhraní seznam aplikačních rozhraní řešení mířených na aplikace egovernmentu a jiných úřadů, případně jiná rozhraní. Pro katalog aplikačních rozhraní uveďte následující údaje: Název aplikačního rozhraní název nebo označení aplikačního rozhraní. Komponenta A v případě jednostranné komunikace uveďte volající aplikační komponentu, tedy tu, které je příjemcem informací. V případě oboustranné komunikace uveďte primárně interní komponentu. 12

Komponenta B v případě jednostranné komunikace uveďte odpovídající aplikační komponentu, tedy tu, které je poskytovatelem informací. V případě oboustranné komunikace uveďte primárně externí komponentu. Vysvětlení významu aplikačních komponent, funkcí a služeb bližší objasnění obsahu a četnosti komunikace vedené přes aplikační rozhraní. Uveďte aplikační rozhraní aplikačních komponent zahrnutých do projektu na ostatní s nimi integrované komponenty (mající na ně rozhraní, interní a externí z pohledu úřadu). V tabulce 21: Katalog aplikacemi podporovaných agend, vyplňte seznam do projektu zahrnutých informačních systémů, které jsou představovány výše uvedenými aplikačními komponentami projektu, a agend, které jsou s jejich pomocí vykonávány. Pro katalog aplikačních komponent a funkcí uveďte následující údaje: Realizovaný systém informační systém vytvářený, upravovaný, rozšiřovaný nebo podporovaný v rámci projektu. Používejte název nebo označení použité již v katalogu aplikačních komponent. Agenda agenda uvedená v katalogu agendových funkcí v kapitole 2.2.3, která je zajišťována či podporována informačním systémem. Modely aplikační architektury pohled struktury aplikací požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: http://www.mvcr.cz/clanek/agenda-odboru-hlavniho-architekta-egovernmentu.aspx?q=y2hudw09na%3d%3d Modely aplikační architektury pohled komunikace aplikací požadavky na diagram jsou popsány v dokument Definice pohledů dle formuláře žádosti o stanovisko typu A, který je ke stažení na webových stránkách odboru Hlavního architekta MV na adrese: http://www.mvcr.cz/clanek/agenda-odboru-hlavniho-architekta-egovernmentu.aspx?q=y2hudw09na%3d%3d V tabulce 22: Katalog komunikačních (obslužných) rozhraní, kanálů koncových klientů, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Asistovaná přepážka Přepážka úřadu možnost příjmu podání a poskytování výpisů na vlastní přepážce organizace za asistence k tomu kompetentního pracovníka. CzechPOINT (přepážka) povinné rozhraní pro poskytování výpisů a příjem podání prostřednictvím univerzálního kontaktního místa veřejné správy. Relevantní jen pro takové výpisy a podání, u kterých se předpokládá dostatečná četnost využívání. Call-centrum možnost příjmu podání a poskytování informací a konzultací prostřednictvím telefonního či jiného hlasového rozhraní. Webový portál Aplikace v portálu úřadu s autentizovaným klientem webový portál (lehký klient) pro příjem podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). Předpokladem je přímé provázání na příslušné agendové informační systémy. CzechPOINT@home povinné rozhraní pro poskytování výpisů a příjem podání prostřednictvím samoobslužného kontaktního místa veřejné správy. Relevantní jen pro takové výpisy a podání, u kterých se předpokládá dostatečná četnost využívání. Tlustý aplikační klient nainstalovaná počítačová aplikace (tlustý klient) pro činění podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). Mobilní aplikace nainstalovaná aplikace pro mobilní telefony určená pro činění podání, poskytování výpisů a zobrazování a správu personalizovaných informací (dat a žádostí přihlášeného klienta veřejné správy). CzechPOINT@office povinné rozhraní pro poskytování výpisů a příjem podání ve vztahu mezi jednotlivými orgány veřejné moci prostřednictvím rozšířeného back-office úředníka. V případě, že jsou pro tento účel navzájem propojeny veškeré relevantní agendové informační systémy všech dotčených organizací, tak jen toto rozhraní nerelevantní. Datová zpráva (ISDS) 13

Formulář v DS povinné rozhraní pro příjem podání ve formě strukturovaného formuláře doručovaného skrze Informační systém datových schránek. Předpokládá se schopnost vytěžení relevantních dat z formuláře do příslušných informačních systémů. Elektronicky podepsaný dokument do e-podatelny E-mail s elektronicky podepsaným formulářem rozhraní pro příjem podání ve formě strukturovaného formuláře opatřeného elektronickým podpisem doručovaného do mailové schránky podatelny organizace. Předpokládá se schopnost vytěžení relevantních dat z formuláře do příslušných informačních systémů a ověření podpisu. Webová aplikace pro zaslání elektronicky podepsaného dokumentu do e-podatelny webový portál (lehký klient) pro vyplnění a odeslání elektronického formuláře včetně jeho opatření elektronickým podpisem klienta. Předpokladem je přímé provázání na příslušné agendové informační systémy. Listinnou cestou do podatelny Formulář listinnou poštou strukturovaný formulář pro podání dostupný ke stažení a vytisknutí na webových stránkách úřadu nebo k vyzvednutí na pobočce úřadu, který je určen k vyplnění a zaslání prostřednictvím poštovních služeb. Formulář na listinnou podatelnu (osobně) strukturovaný formulář pro podání dostupný ke stažení a vytisknutí na webových stránkách úřadu nebo k vyzvednutí na pobočce úřadu, který je možné osobně doručit na podatelnu organizace. Jiné E-mail s formulářem bez elektronického podpisu rozhraní pro příjem podání ve formě strukturovaného formuláře nebo nestrukturované zprávy doručované do mailové schránky podatelny organizace. Případně poskytování notifikací klientům veřejné správy o vyřízení žádosti či vstupu do některé relevantní životní situace. Aplikace v portálu úřadu s neautentizovaným klientem webový portál (lehký klient) pro činění podání a poskytování výpisů pro anonymní či nepřihlášené klienty. Předpokladem je přímé provázání na příslušné agendové informační systémy. Aplikační rozhraní pro externí systémy aplikační rozhraní pro přímou komunikaci a výměnu dat mezi informačními systémy různých orgánů veřejné správy. Pro katalog komunikačních rozhraní a kanálů uveďte následující údaje: Využití výběr ze seznamu, zda je pro projekt rozhraní/kanál Nerelevantní nebo zda je jeho využití plánováno. Pro povinná rozhraní a kanály, jež jsou pro projekt relevantní, musí být v případě jejich nevyužití zvolena možnost Ne, žádáme výjimku. Č. žádosti o výjimku v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Počet uživatelských přístupů ročně odhad předpokládaného počtu klientů obsluhovaných skrze rozhraní/kanál ročně. Zohledněte rovněž předpoklad rostoucího zájmu o elektronické kanály v následujících letech. Popis využití rozhraní v projektu bližší objasnění účelu a způsobu využití rozhraní/kanálu, tak aby bylo na obecné úrovni zřejmé, jaké dokumenty a informace budou skrze rozhraní/kanál vyměňovány a jakým směrem. Případně, pokud to není zcela jasné, uveďte proč je využití nerelevantní. V tabulce 23: Dodržení architektonických principů aplikační vrstvy, zvolte skutečnosti odpovídající z nabízených variant, zda je projekt v souladu uvedenými požadavky jednotlivých principů. Pro seznam architektonických principů uveďte následující údaje: Dodrženo výběr ze seznamu, zda je pro projekt požadavek Nerelevantní nebo zda je jeho naplnění plánováno (Ano). Nenaplnění, i když je relevantní, znamená většinou nutnost požádat o výjimku. Nepovinné jsou požadavky, které jsou ve sloupci Č. výjimky needitovatelné a šedě podbarvené. Č. výjimky v případě, že je ve sloupci Dodrženo zvolena možnost Ne, žádáme výjimku, uveďte zde číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy. Pro nepovinné požadavky (šedě podbarvené) se nevyplňují nikdy. Způsob a míra naplnění vysvětlete jakým způsobem je projektem naplněn požadavek, případně vysvětlete, proč naplněn není nebo je nerelevantní. 14

V tabulce 24: Vysvětlení v kontextu aplikační architektury úřadu, tedy, vyplňte, jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti. Uveďte všechny duplicity, které se na aplikační vrstvě vyskytují. Například, jak souvisí navrhované komponenty s ostatními obdobnými komponentami úřadu (například zda a proč potřebuje nová agenda samostatnou spisovou službu nebo naopak, jak nová agendová aplikační komponenta využije stávající komponenty spisové služby a platebního nástroje úřadu). Popište vztahy předmětu projektu ke všem obdobným řešením v úřadu, resortu a celém státu. Vysvětlete, jak bude integrována centrální aplikační komponenta s existujícími nebo připravovanými lokálními aplikačními komponentami a funkcemi řešení na pracovištích rozšířeného řetězce dodávky této veřejné služby. Vysvětlení aplikační architektury projektu prostor pro vysvětlení všech dalších potřebných souvislostí a pro projekt důležitých informací, spojený s výše uvedenými architektonickými objekty, anebo je doplňující. 2.2.4.2 Architektura informačních systémů část: Datová architektura Tato část architektury projektu objasňuje, které základní objekty a subjekty reálného světa, ve světle jejich zahrnutí do právního prostředí české VS, budou předmětem evidence budovaného či měněného procesu veřejné služby a odpovídajícího informačního systému. V tabulce 25: Katalog základních datových entit projektu, zvolte skutečnosti odpovídající z nabízených variant a vyplňte, které důležité objekty a subjekty reality a práva jsou předmětem evidence navrhovaného informačního systému. Pro katalog datových entit uveďte následující údaje: Objekt reálného světa, který je předmětem evidence nejdůležitější objekty, které budou v řešení evidovány (např. řidiči, žádosti, správní řízení). Vysvětlení objektu bližší objasnění obsahu a předpokládaného počtu evidovaných objektů. Je objekt čerpán nebo poskytován jiným subjektům? vyberte, zda daný objekt čerpáte či poskytujete někomu jinému. V tabulce 26: Využití datového fondu základních registrů a dalších agend, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Základní registry Způsob vedení datového kmene uveďte, jakým způsobem bude veden datový kmen údajů ze Základních registrů. Standardní jsou dva způsoby: 1. Evidence referenčních údajů s notifikací změn ze ZR evidence referenčních údajů ve vlastní databázi za použití notifikace změn ze základních registrů. Výsledkem tedy je, že v agendovém informačním systému jsou uloženy údaje, jako jméno/název, adresa atd. spolu s agendovými údaji a při každé změně referenčních údajů v základních registrech jsou tyto v agendovém systému aktualizovány. 2. Evidence jen identifikátoru (pseudonymu) a při potřebě zobrazení aktuální podoby referenčních údajů ze ZR evidence jen unikátního identifikátoru (AIFO/IČ) v agendovém informačním systému s tím, že při potřebě čtení záznamů souvisejících se subjektem se provede dotaz na aktuální verzi referenčních údajů ze základních registrů, které jsou zobrazeny a následně opět smazány. 3. Nerelevantní vyberte, pokud předmět projektu nepovede datový kmen využívající referenční údaje ze základních registrů. 4. Jiný, popište tuto možnost zvolte v případě, že datový kmen bude vedený jiným než některým výše uvedeným způsobem. Je třeba podrobně popsat zvolený způsob do sloupce Vysvětlení. Evidujeme subjekty práva, které nejsou vedeny v ZR (např. zahraniční) uveďte, zda budou předmětem evidence subjekty práva, které nejsou vedeny v žádném ze základních registrů jako referenční údaje. Evidujeme fyzické osoby, které nejsou vedeny v ROB uveďte, zda budou předmětem evidence fyzické osoby, které nejsou vedeny v Registru obyvatel. Případně upřesněte míru užití Evidence jiných fyzických osob (EJFO) či jiný způsob naložení s těmito subjekty. Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů 15

Evidence obyvatel (ISEO) uveďte, zda a v jakém rozsahu plánujete využít kompozitní služby Informačního systému Evidence obyvatel. Cizinecký informační systém (CIS) uveďte, zda a v jakém rozsahu plánujete využít kompozitní služby Cizineckého informačního systému. egon Service Bus Čerpání dat přes egsb uveďte, zda bude součástí projektu použití egon Service Bus pro čerpání dat z jiných systémů nebo pro využití jiných služeb egsb. Uveďte jaká data a služby budou skrze egsb využívána. Publikování vlastních dat přes egsb uveďte, zda bude součástí projektu publikace dat prostřednictvím egon Service Bus pro jiné agendové informační systémy a jaká data budou publikována. Pro seznam využití datového fondu uveďte následující údaje: Použito vyberte ze seznamu možností způsob nakládání s datovým kmenem. Č. žádosti o výjimku v případě, že je ve sloupci Použito zvolena možnost Ne, žádáme výjimku, tak uveďte číslo příslušné žádosti o výjimku, jaké má v poslední kapitole Přílohy Vysvětlení bližší objasnění rozsahu a způsobu využití prvku. Případně, pokud to není zcela jasné, uveďte proč je použití nerelevantní. V tabulce 27: Způsob zajištění vedení dat s ohledem na otevřená data veřejné správy, zvolte skutečnosti odpovídající z nabízených variant a vyplňte Zajištění přístupu k datům Budete mít zajištěn přístup k veškerým datům vedeným v databázích dotčených předmětem projektu ve strojově čitelném a otevřeném formátu? - Uveďte Ano pouze v případě, že přístup k datům bude zajištěn prostřednictvím alespoň jedné z následujících možností: - API, které můžete kdykoliv využívat alespoň k tomu, abyste pomocí sady požadavků získali veškeré údaje ze všech databází dotčených předmětem projektu ve strojově čitelném a otevřeném formátu ve smyslu 3 odst. 7 a 8 zákona č. 106/1999 Sb., o svobodném přístupu k informacím. K API musíte mít k dispozici vždy aktuální a kompletní dokumentaci popisující syntaxi a sémantiku jeho datových struktur a syntaxi, sémantiku a způsob přístupu k operacím, které API nabízí. - Export kompletního obsahu databází dotčených předmětem projektu na požádání nebo v pravidelných intervalech ve strojově čitelném a otevřeném formátu ve smyslu 3 odst. 7 a 8 zákona č. 106/1999 Sb., o svobodném přístupu k informacím. Budete mít výše popsaný přístup k datům zajištěn bez dodatečných finančních nákladů? - Uveďte Ano pouze v případě, že přístup k datům popsaný v předchozí otázce budete moci využívat bez dodatečných nákladů. V případě odpovědi Ano nesmí být přístupy k API dodavatelem zpoplatňovány (jednotlivě ani paušálně) a stejně tak nesmí dodavatel žádat úplatu za provádění jednotlivých exportů obsahu databází. Úplatu může dodavatel žádat pouze za vytvoření a zajištění provozu a podpory API či za vytvoření a zajištění provozu a podpory exportního mechanismu. V této úplatě však nesmí být zahrnuty samotné přístupy k API či provádění exportů. Budete moci se zpřístupněnými daty libovolně nakládat? - Uveďte Ano, pokud nejste žádným způsobem, s výjimkou právních předpisů, omezení v nakládání se získanými daty. Jedná se zejména o ujednání ve smluvní dokumentaci omezující nakládání s daty. Publikace výstupů ve formátu otevřených dat Budou data vedená v databázích dotčených předmětem projektu zveřejňována jako otevřená data - Uveďte Ano, pokud budou data (vlastní obsah databáze a/nebo souhrnné statistiky) zveřejňována jako otevřená data dle zákona č. 106/1999 Sb., o svobodném přístupu k informacím a dle pokynů a dobré praxe popsané na portále otevřených dat https://data.gov.cz a budou katalogizována v Národním katalogu otevřených dat. Nerelevantní se použije výhradně tehdy, pokud není předmětem projektu dotčena žádná databáze nebo databáze obsahuje pouze data, která není možné publikovat ani v podobě souhrnných statistik. Jaké datové oblasti plánujete zveřejňovat jako otevřená data a kdy? - Uveďte rámcově oblasti dat, ve kterých předpokládáte publikaci datových sad jako otevřená data. Pro každou 16