Formulář žádosti


Formulář žádosti


o stanovisko Hlavního architekta eGovernmentu k plánované změně projektu v rámci smlouvy na provoz, podporu, údržbu, rozvoj a další uzavřené k existujícímu ICT řešení

(dle usnesení vlády ČR č. 86/2020 a/nebo zákona 365/2000 Sb.)


typ B2


Odbor Hlavního architekta eGovernmentu MV



Praha, březen 2021

verze 7.0



UPOZORNĚNÍ: Přestože je formulář zveřejněn ve formátu umožňujícím změny, žadatel není oprávněn měnit strukturu vybraných otázek či předepsaných odpovědí. Pokud se tak stane, Xxxxx Hlavního architekta eGovernmentu vyhodnotí takovou změnu jako porušení pravidel při schvalování a formulář bude vrácen bez vydání stanoviska. Tam, kde je to třeba pro uvedení dalších položek do tabulky, je žadatel oprávněn přidávat řádky pro tyto položky.

Metodický pokyn k vyplňování na adrese: xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxxx-xxxxx-x-xxxxxxx-x-xxxxxxxxxx-xxxx-x.xxxx


Toto dílo podléhá licenci Creative Commons Uveďte původ 4.0 Mezinárodní Licence


1. Z Á K L A D N Í I N F O R M A C E O P R O J E K T U

1.1. Úvodní informace o žadateli o stanovisko ke změně projektu


Tabulka 1: Úvodní informace o žadateli o stanovisko

Organizace žadatele

Ministerstvo vnitra

xxxxxxx Xxxxxx 0000/0, Xxxxx 4

00007064

Ředitel pro informatiku nebo Statutární zástupce

Xxx. Xxxxx Xxxx

ředitel odboru

eGovernmentu

xxxxx.xxxx@xxxx.xx

974 817 524

Kontaktní osoba projektu

Xxx. Xxx Xxxxxx

vedoucí oddělení optimalizace eGovernmentu, MV

xxx.xxxxxx@xxxx.xx

000 000 000

Architekt projektu

Xxx. Xxx Xxxxxx

vedoucí oddělení optimalizace eGovernmentu, MV

xxx.xxxxxx@xxxx.xx

000 000 000

Verze předkládaných / doplněných žádostí o stanovisko, data jejich předložení a jejich čísla jednací

Číslo předkládané verze:

Datum předložení:

Verze předložena pod Čj,:

1.0

15. 4. 2021

MV- 8339-3/EG-2021

2.0

7. 6. 2021

MV- 8339-4/EG-2021





Tabulka 2: Žádost o stanovisko dle (důvod žádosti)

Usnesení vlády č. 86, ze dne 27. ledna 2020 (U86)

Ano

Zákona č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů (ZoISVS)

Ano

Výzev v Integrovaném regionálním operačním programu (IROP), vypište číslo výzvy

Ne

Dobrovolná žádost o stanovisko

Ne

1.2. Shrnutí charakteristik změny projektu


Tabulka 3: Shrnutí charakteristik změny projektu

Název měněného projektu:

Rozvoj Portálu veřejné správy v roce 2021

Specifický cíl / účel projektu:

Předmětem projektu je navazující rozvoj Portálu veřejné správy (dále též „PVS“), informační a transakční části, konkrétně jeho rozšíření a úprava vybraných stávajících funkcionalit v návaznosti na platnou legislativu a záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (neboli Digitálního Česka). Cílem projektu je mj. zvýšení hospodárnosti a bezpečnosti dotčeného informačního systému.

Jedná se o realizaci dílčí změny řešení v souladu se závazkem z dříve schváleného formuláře žádosti typu B1 „Zajištění rozvoje, provozu a dostupnosti Portálu veřejné správy 2021+“ vč. návazností na legislativní a strategické rámce.

Seznam žádostí, které již byly v souvislosti s celkovými cíli a specifickým cílem / účelem projektu předány OHA:

Žádost typu B1 „Zajištění rozvoje, provozu a dostupnosti Portálu veřejné správy 2021+“, č. j. MV- 8339-1/EG-2021

Odkazy na agendy VS, kterých se projekt týká:

A344 Portál veřejné správy xxxxx://xxx- xxx.xxxx.xxx.xx/xxx/xxxxxx-xxxxxx/X000_00000000.xxxx

Seznam služeb veřejné správy a jejich úkonů z katalogu služeb veřejné správy, kterých se projekt týká:

S13564 - Zveřejnění metodických pokynů (xxxxx://xxx-

xxx.xxxx.xxx.xx/XXXX/xxxxxx/xxxxxx-xxxxxxxx-xxxxxx/0000)

• úkon U35056 - Zveřejnění informací

S13565 - Poskytnutí údajů a výstupů z informačních systémů


Tabulka 3: Shrnutí charakteristik změny projektu


veřejné správy (xxxxx://xxx-xxx.xxxx.xxx.xx/XXXX/xxxxxx/xxxxxx- ohlaseni-agendy/7750)

• úkon U35058 - Žádost o výstup z informačního systému veřejné správy

• úkon U35075 - Vydání výstupu z informačního systému veřejné správy

S13566 - Poskytnutí notifikace o končící platnosti dokladu, průkazu, osvědčení nebo jiné veřejné listiny (xxxxx://xxx- xxx.xxxx.xxx.xx/XXXX/xxxxxx/xxxxxx-xxxxxxxx-xxxxxx/0000)

• úkon U35059 - Zápis dokladu, průkazu, osvědčení nebo jiné veřejné listiny

• úkon U35060 - Poskytnutí notifikace

Odkazy na určené IS dle UV 86/2020 a zákona 365/2000 Sb., kterých se projekt týká:

Nebo informace, pokud ještě nebyl zaregistrován

3 – Portál veřejné správy

Názvy a odkazy na projekty v katalogu Digitálního Česka nebo jejich ID a názvy

Pokud má být projekt financován v souvislosti se strategií Digitální Česko

Financování tohoto projektu není zajištěno z Digitálního Česka, nýbrž z prostředků převedených z rozpočtu MPO koncem roku 2020 (9,5 mil. vč. DPH) a dále navýšených z vlastního rozpočtu MV v roce 2021 (5 mil. vč. DPH). Celkový maximální rozpočet projektu činí 14,5 mil. Kč vč. DPH.


Projekt zajišťuje plnění cílů Programu Portál veřejné správy 2.0 (Portál občana) a na něj navázaných záměrů pro rok 2021 (viz Propojené úlohy).

Termíny:


Zahájení realizace projektu:

Spuštění první služby do produkčního prostředí:

Ukončení provozní smlouvy plánované v tomto projektu:


1. 5. 2021

1. 6. 2021

Součástí projektu není provozní

smlouva, pouze rozvoj.

Výhrady ke zveřejnění formuláře:


Formulář obsahuje veřejné informace a předpokládá

se jeho zveřejnění. Pokud se zveřejněním nesouhlasíte, uveďte důvod, případně úpravy, které budou nutné, aby bylo zveřejnění možné:


Výjimky:


Žádáte výjimku/y vyplývající z nedodržení architektonických principů eGovernmentu nebo jiných skutečností?

Ne

Počet žádostí

o výjimku/y v přílohách:


Určení rolí věcného správce, technického správce, provozovatele a dodavatele (pokud je předmětem více IS, klasifikujte hlavní a ostatní vysvětlete v tabulce 8):


Věcný správce

Subjekt, který je investorem předmětu projektu

odbor eGovernmentu, MV

Technický správce

Subjekt, který zajišťuje technickou realizaci požadavků věcného správce k předmětu projektu

odbor eGovernmentu, MV

Provozovatel

Subjekt, který zajišťuje provoz HW a SW předmětu projektu

Národní agentura pro komunikační a informační technologie,

s. p.

Dodavatel

Subjekt, který dodává předmět projektu, pokud je znám v době přípravy projektu

Národní agentura pro komunikační a informační technologie,

s. p.

Realizační (implementační) výdaje v rámci projektu (součet hodnot ve sloupci ① tabulky 49)

11 983 471 Kč


Tabulka 3: Shrnutí charakteristik změny projektu

v Kč bez DPH:


Provozní výdaje plánované v rámci projektu (součet hodnot ve sloupci ② tabulky 49) v Kč bez DPH:

0 Kč


1.3. Popis, potřebnost a výstupy změny projektu


Tabulka 4: Popis změny projektu

Popis výchozí situace měněného projektu (tzv. As-Is, současný stav):

Stávající PVS, především jeho transakční část (Portál občana), představuje informační systém postavený na moderních trendech vývoje softwaru, jeho testování, nasazování a provozu, který pro svůj provoz využívá cloudovou platformu. Tato investice se netýká obměny ani pořízení nového majetku, nýbrž implementace nových funkcionalit a rozvoje stávajícího majetku.

PVS je provozován kompletně v cloudu na škálovatelné platformě (Microsoft Azure) a jedná se o modulární aplikaci, kde vedle sebe běží několik modulů (lze tedy jednoduše přidávat a ubírat jednotlivé služby). Sám PVS neukládá žádné osobní informace o uživatelích (vede pouze bezvýznamový identifikátor a to, co si sám uživatel uloží, např. přílohu datové zprávy nebo kontaktní údaje). Přímo je napojen na velmi omezený počet systémů, konkrétně:

• Informační systém datových schránek (přihlášení prostřednictvím autentizační služby datových schránek, připojení vlastní datové schránky k uživatelskému účtu v portálu pro odesílání formulářů a činění podání vůči veřejné správě),

• propojený datový fond (Informační systém základních registrů a eGon Service Bus či ISSS pro napojení na agendové

informační systémy),

• Národní bod pro identifikaci a autentizaci (přihlášení prostřednictvím identifikačního prostředku registrovaného na NIA),

• služby publikované v Centrálním místu služeb.


Tabulka 4: Popis změny projektu

Popis cílové situace po dosažení celkového cíle / cílů změny projektu (tzv. To-Be, budoucí stav):

Jedná se o rozvoj PVS, v jehož rámci se předpokládá realizace následujících částí:

• implementace elektronického podání žádosti o výměnu řidičského průkazu na Portálu občana vč. notifikací o stavu vyřizování žádosti;

• standardizace notifikací na Portálu občana: zavedení jednotného systému klientských notifikací a upozornění

pro přihlášeného uživatele;

• napojení registru silničních vozidel (RSV) na Portál občana: zpřístupnění údajů o vozidlech přihlášenému uživateli;

• napojení informačního systému technických prohlídek (ISTP) na Portál občana: zpřístupnění údajů o technických prohlídkách vlastněných či provozovaných vozidel přihlášenému uživateli;

• publikace formulářů pro sbírku předpisů územních samosprávných celků (ÚSC) na informační PVS: formuláře, prostřednictvím kterých budou obce a kraje publikovat, měnit či rušit právní předpisy ve sbírce právních předpisů ÚSC:

o cca 15 formulářů, které budou vyvěšeny na PVS – wireframy zde (mezi formuláři lze přepínat stiskem

a podržením tlačítka menu v levém horním rohu obrazovky);

o formuláře budou odesílány prostřednictvím datové schránky subjektu;

o vybraná pole se budou předvyplňovat údaji z veřejných číselníků (adresy, čísla předpisů) nebo webových služeb (volání webové služby pro předvyplnění některých údajů);

o vyplněné formuláře nebudou ukládány na PVS, pouze odesílány datovou schránkou;

• zpřístupnění certifikátu o provedeném očkování proti COVID-19 přihlášenému uživateli;

• napojení na systémy evidence občanských průkazů a cestovních dokladů za účelem zobrazení fotografií, údajů

o platnosti dokladů a digitalizovaných obrazů podpisů (scanů) na Portálu občana přihlášenému uživateli;

• úpravy Portálu občana a informační PVS v souvislosti s plánovaným rozvojem základního registru obyvatel (ROB)

a základního registru osob (ROS):

o nová funkce editace kontaktních údajů do ROB a ROS pro přihlášeného uživatele;

o nová funkce editace kvalifikovaného certifikátu do ROB pro přihlášeného uživatele;

o úprava stávajících výpisů a údajů vedených v Portálu občana, které mají vazbu na výše uvedené úpravy ROB a ROS (např. úprava žádosti o výpis údajů z registru obyvatel, úprava žádosti o změnu údajů v registru obyvatel (reklamace do ROB), úprava žádosti o změnu údajů v registru osob (reklamace do ROS), úprava žádosti o poskytnutí referenčních údajů z registru obyvatel jiné osobě (ZR10) – neboli služba správa souhlasů, dále rozšíření výčtu údajů z ROB v sekci Údaje, rozšíření výčtu údajů z ROS v sekci Údaje);

• zobrazení údajů z daňového kalendáře přihlášenému uživateli v prostředí Portálu občana, konkrétně napojení na informační systémy Ministerstva financí prostřednictvím eGon Service Bus (Informačního systému sdílené služby), zobrazení údajů z daňového kalendáře v kalendáři Portálu občana a napojení na notifikační službu Portálu občana (notifikace uživatelů zvolenými notifikačními kanály typu e-mail nebo SMS o nadcházejících daňových povinnostech);

• re-design a úprava uživatelského rozhraní v souladu s design systémem Xxx.xx: v rozsahu úprav vybraných designových komponent dle design systému xxx.xx (xxxxx://xxxxxxxxxxxx.xxx.xx/).


Využití a změny stávající aplikace a infrastruktury:

• V rámci rozvoje PVS dojde k širšímu využití služeb eGon Service Bus (Informačního systému sdílené služby), jejích komunikačních kontextů a protokolů.

• V rámci rozvoje PVS dojde k širšímu využití služeb Informačního systému základních registrů.

• I nadále se bude architektonicky stavět na konceptu mikro služeb provozovaných a orchestrovaných v kontejnerech nasazených na cloudové platformě.

• Nadále se využívá a rozvíjí design systém vyvinutý pro webové aplikace, portály a informační systémy MV (xxxxx://xxxxxxxxxxxx.xxx.xx/), s jehož použitím se počítá i v budoucnu a který v rámci projektu dozná dalších úprav a změn (např. v souvislosti se zákonem č. 99/2019, o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb.).

Popis změn, tzn. výsledků / výstupů změny projektu nezbytných k dosažení jeho specifického cíle / účelu:

Výstupem projektu bude upravený PVS ve výsledné podobě uživatelsky přívětivé a využívané digitální služby státu. Bude se jednat výhradně o programové vybavení provozované na cloudové platformě. Držitelem licence na programové vybavení bude MV. Jedná se o zhodnocení stávajícího majetku.


Tabulka 4: Popis změny projektu

Důvody realizace změny projektu (označte všechny relevantní):

Legislativní důvody

☒

Konec licencí

☐

Modernizace, optimalizace řešení (výsledky business analýz)

☒

Lepší nabídka trhu

☐

Požadavky zaměstnanců, uživatelů

☒

Konec podpory od dodavatele

☐

Konec podpory produktu, vynucené modernizace nižších vrstev

☐

Jiné (vysvětlete v tabulce 8)

☐

Hospodárnost

☐



Přehled zvažovaných alternativ řešení rozdílných od „Popisu změny projektu“ (tzv. To-Be) specifikovaného výše:

Nejsou relevantní alternativy – vychází a staví se na stávající architektuře PVS za využití již integrovaných centrálně sdílených nástrojů, za snahy o maximální dodržení ITIL v4 Guiding Principles a v souladu s platnou legislativou.


Pro úplnost uvádíme přehled alternativ:


Nulová varianta (vč. xxxxx vyplývajících z nerealizování investičního záměru):

• Uložené úkoly nebude možné bez vyžadovaného majetku plnit.

• Nebude-li v tomto případě majetek pořízen, poté:

o nedojde k rozšíření funkcionalit již existujícího Portálu veřejné správy;

o nedojde k naplnění povinností stanovených platnou legislativou;

o nedojde k naplnění vybraných záměrů Digitálního Česka, které jsou výslovně navázány na PVS.


Varianta vertikální spolupráce:

Zadavatel potřebuje pro svou činnost vyplývající z organizačního řádu MV výkon odborné činnosti, přičemž potřebné lidské zdroje s odpovídající kvalifikací nemá k dispozici mezi svými kmenovými zaměstnanci. NAKIT je připraven požadované služby poskytnout prostřednictvím vlastních kmenových zaměstnanců a poddodavatele, přičemž již nyní disponuje kapacitami zkušených odborníků v oboru ICT, kteří znají činnost a projekty zadavatele (bez nutností např. jejich zaškolení nebo proškolení).

Další rozvoj Portálu veřejné správy pod NAKIT byl vybrán z několika dalších konkrétních důvodů:

• NAKIT zajišťoval vývoj a následující rozvoj transakční části Portálu veřejné správy,

• jako jeden z mála dodavatelů má zkušenosti s nasazováním informačních systémů veřejné správy do prostředí cloudu

a zároveň disponuje vlastními zaměstnanci, kteří jsou toto schopni zajistit,

• provozuje a dále rozvíjí informační a komunikační infrastrukturu veřejné správy a datové sítě Ministerstva vnitra, na které je Portál veřejné správy napojen, a to včetně Centrálního místa služeb a Dohledového centra pro provoz ICT systémů a kybernetickou bezpečnost.


Další alternativní varianty:

• nutnost zaškolení nebo proškolení zaměstnanců dodavatele v oblasti PVS, ale i v dalších tématech, např. v oblasti bezpečnosti (PVS je součástí kritické informační infrastruktury veřejné správy);

• nutnost seznámení s napojenými informačními systémy a infrastrukturou, které PVS využívá;

• chybějící dohled ovládajícího veřejného zadavatele.


Tabulka 5: Přehled výstupů změny projektu

Označení výstupu

Množství a jednotka

Celková cena výstupu [Kč]

Plánovaná životnost výstupu [rok]

Vysvětlení výstupu

Rozšíření PVS

1 ks

11 983 471 Kč

bez DPH

2026

Zahrnuje rozšíření a změny uvedené v tabulce 4 (tzv. To-Be stav).

Na majetkové účtárně bude tento výstup evidován jako zhodnocení stávajícího majetku (PVS), stejně jako tomu bylo u předchozích projektů zhodnocujících PVS.

1.4. Právní klasifikace specifického cíle / účelu změny projektu


Tabulka 6: Klasifikace specifického cíle / účelu změny projektu dle legislativy eGovernmentu (pokud je v rámci projektu realizováno více IS, klasifikujte hlavní a ostatní vysvětlete)

Klasifikace

Vyberte

Druh informačního systému dle klasifikace zák. č. 365/2000 Sb., o informačních systémech VS

Informační systém veřejné správy

Je projektem dotčen (tj. realizován nebo na úrovni jeho procesní a aplikační architektonické vrstvy měněn) určený informační systém dle zák. č. 365/2000 Sb., o informačních systémech VS?

Ano - VYPLŇTE DLE JAKÉHO KRITÉRIA


1. Využívá služby referenčního rozhraní nebo poskytuje služby referenčnímu rozhraní


2. Má vazbu na systém dle bodu 1



3. Je určený k poskytování služby fyzickým nebo právnickým osobám s předpokládaným počtem uživatelů, kteří využívají přístup se zaručenou identitou, alespoň 5000 ročně

Je projektem dotčen agendový informační systém dle zákona č. 111/2009 Sb., o základních registrech?

Ano

Budou informačním systémem, který je projektem dotčen, přijímány a odesílány datové zprávy dle zák. č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů?

Ano

Druh informačního / komunikačního systému dle klasifikace stanovené zákonem č. 181/2014 Sb.,

o kybernetické bezpečnosti

Kritická informační infrastruktura

1.5. Přínosy (celkový cíl / cíle) změny projektu


Tabulka 7: Strukturovaný přehled přínosů (celkového cíle / cílů) změny projektu včetně uvedení objektivně ověřitelných ukazatelů jejich dosažení a zdrojů a prostředků jejich ověření

Přínosy na straně uživatelů (např. snížená časová nebo administrativní náročnost oproti vyřízení aktivity dosavadním způsobem, vyšší ochranu osobních dat aj.):

• dostupnost nových služeb v elektronické podobě (např. podání žádosti o vydání řidičského průkazu, přístup k údajům z Registru silničních vozidel, přístup k údajům z Informačního systému technických prohlídek aj.), jež se zároveň pojí se snížením časových a finančních nároků kladených na uživatele:

o objektivně časová úspora spojená s možností vzdáleného přístupu ke službě;

o objektivně finanční úspora spojená s možností získat zdarma přístup k údajům přímo ze zdrojových informačních systémů prostřednictvím propojeného datového fondu;


• ochrana osobních údajů v případě vzdáleného přístupu ke službě:

o potenciálně nedochází k nahlížení úředníka na osobní údaje, jelikož dochází k automatizovanému výdeji údajů ze zdrojových informačních systémů;


• zpřístupnění vybraných zdrojových kódů (design systém xxx.xx) zainteresovaným skupinám uživatelů (vývojáři, designéři či další zájemci z řad veřejnosti) za účelem zvýšení transparentnosti, zavedení systému kontroly a zpětné vazby ve veřejné správě.

Přínosy na straně věcného správce (zvýšení kvality jeho výstupů, snížení pracnosti na straně jeho úředníků aj.):

• využití elektronických komunikačních kanálů k propojení přímo s občany:

o objektivně zvýšení četnosti využívání elektronických komunikačních kanálů ze strany úředníků a tím zvýšení

gramotnosti v oblasti IT;


• úspora materiálových nákladů:

o objektivně úspora materiálů v případě úplných elektronických podání, kdy nedochází k výdeji rozhodnutí, výpisů atd. v listinné podobě;


• potenciální úspora veřejných zdrojů v případě implementace prostřednictvím PVS, který nabízí již hotové uživatelsky přívětivé rozhraní napojené na potřebné podpůrné systémy;


• zvýšení transparentnosti výkonu veřejné správy:

o část zdrojového kódu je veřejně přístupná, veškeré transakce jsou logovány, nedochází k nahlížení na osobní údaje ze strany správce systému, nedochází k duplikované evidenci údajů, smlouvy jsou zveřejňovány atd.;


• potenciálně zlepšení vnímání veřejné správy v případě úspěšné implementace uživatelsky přívětivých služeb.

Přínosy pro technického správce a provozovatele služby (snížení energetické náročnosti, zjednodušení a úspora pracnosti správy systému, snížení výdajů na provoz aj.):

• další zefektivnění procesů service desku, release managementu a task managementu prostřednictvím systému Azure DevOps, který je využíván k administraci systému;


• širší zapojení technického správce do výše uvedených procesů za účelem dohledu a kontroly dodavatele.


Tabulka 8: Vysvětlení k základním podmínkám dosažení přínosů (nutným předpokladům a rizikům dosažení celkového cíle / cílů) změny projektu

Za účelem dosažení uvedených přínosů bylo zajištěno následující:

• technické řešení je navrženo v přímé vazbě na požadované výstupy a cíle a s jasně definovanou funkčností;

• byly specifikovány požadované parametry na technické řešení;


Tabulka 8: Vysvětlení k základním podmínkám dosažení přínosů (nutným předpokladům a rizikům dosažení celkového cíle / cílů) změny projektu

• byla definována zákonná práva a povinnosti spojená s poskytováním potřebných dat pro PVS;

• byly definovány požadavky na rozhraní spolupracujících systémů veřejné správy;

• smluvně budou zavedena validační a schvalovací pravidla a jejich striktní dodržování;

• práce s datovou složkou probíhá již dnes pomocí zabezpečeného spojení, uživatelé prochází autentizačním procesem;

• datové uložiště je navrženo jako samostatný segment;

• jsou zavedeny pravidelné zálohy systému.

2. A R C H I T E K T O N I C K É I N F O R M A C E O Z M Ě N Ě P R O J E K T U

2.1. Dodržení architektonických principů NA VS ČR


Tabulka 9: Dodržení architektonických principů Národní architektury veřejné správy ČR

Klasifikace

Vyberte

Č.

žádosti o výjimku

Vysvětlete

Standardně digitalizované

Ano


Jedná se o jeden z hlavních principů PVS, který poskytuje plně elektronické služby.

Zásada „pouze jednou“

Ano


Napojení na propojený datový fond, kdy nedochází k duplikaci evidencí.

Podpora začlenění a přístupnost

Ano


Zajištěn soulad se zákonem č. 99/2019 Sb.,

o přístupnosti internetových stránek a mobilních aplikací subjektů veřejného sektoru, a zákonem č. 365/2000 Sb., o informačních systémech veřejné správy.

Otevřenost a transparentnost

Ano


PVS podporuje dotváření veřejného datového fondu formou veřejných evidencí a obrazů na informační PVS a publikací do NKOD.

Přeshraniční přístup jako standard

Ano


PVS zajišťuje přístup např. ke katalogu služeb Jednotné digitální brány jakožto hlavnímu informačnímu zdroji a standardu pro uživatele v rámci EU.

Interoperabilita jako standard

Ano


PVS z principu eliminuje místní příslušnost a další omezující faktory.

Důvěryhodnost a bezpečnost

Ano


Komunikace probíhá za využití pseudonymů / bezvýznamových identifikátorů; komunikace a data jsou šifrována; pro přístup k osobním údajům vyžadována autentizace.

Jeden stát

Ano


PVS je jedním z hlavních podporovatelů a propagátorů centrálně sdílených služeb a nástrojů – služeb NIA, CMS, ISDS, ISZR a dalších.

Sdílené služby veřejné správy

Ano


Služby jsou budovány se snahou o univerzálnost (např. nová notifikační služba, kde je využit ISSS a CMS a lze k ní přistupovat prakticky z jakéhokoli registrovaného AIS) a maximální využití stávajících nástrojů.

Připravenost na změny

Ano


Jedná se o modulární aplikaci založenou na bázi mikroslužeb a řízenou v souladu s ITIL v4.

eGovernment jako platforma

Ano


Služby jsou navrhovány s maximální snahou

o jednoduchost a uživatelskou přívětivost, kam až to legislativa a technické možnosti dovolují. Za tímto účelem byl i vyvinut design systém xxx.xx (od března 2021 ve verzi 3.0), který je součástí PVS.

Vnitřně pouze digitální

Ano


Procesy v rámci administrace PVS a komunikace s dalšími systémy / úřady probíhá plně digitálně. Po uživateli nejsou vyžadovány listinné či jiné analogové vstupy.

Otevřená data jako standard

Ano


PVS podporuje dotváření veřejného datového fondu formou veřejných evidencí a obrazů na informační PVS a publikací do NKOD.

Technologická neutralita

Ano


Přístup ke službám PVS není závislý na konkrétní


Tabulka 9: Dodržení architektonických principů Národní architektury veřejné správy ČR

Klasifikace

Vyberte

Č.

žádosti o výjimku

Vysvětlete




(předem určené) platformě či technologii.

Uživatelská přívětivost

Ano


Služby jsou navrhovány s maximální snahou

o jednoduchost a uživatelskou přívětivost, kam až to legislativa a technické možnosti dovolují. Za tímto účelem byl i vyvinut design systém gov.cz (od března 2021 ve verzi 3.0), který je součástí PVS.

Konsolidace a propojování

Ano


Služby jsou budovány se snahou o univerzálnost, maximální využití stávajících nástrojů a sdílení (zdrojový kód společně s know-how byl poskytnut několika partnerům z řad OVM).

Omezení budování monolitických systémů

Ano


Jedná se o modulární aplikaci založenou na bázi mikroslužeb a řízenou v souladu s ITIL v4.


2.2. Změna enterprise architektury projektu a její kontext


Tabulka 10: Architektonický model

V rámci Enterprise Architektury projektu přiložte jako přílohu model exportovaný ve standardizovaném výměnném formátu The Open Group ArchiMate Model Exchange File Format

Ano, model je přiložen jako příloha ve standardizovaném formátu

Případně vysvětlete, proč není model přiložen ve standardizovaném formátu či není přiložen vůbec.



2.2.1. Motivační architektura – strategie a směrování


Tabulka 11: Vysvětlete, proč změnu projektu 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é osoby, cíle, principy, podmínky, architektonické požadavky):

Motivátory:

• legislativní změny s účinností od roku 2020, především zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů;

• záměry a programy Strategie koordinované a komplexní digitalizace České republiky 2018+ (dále též „Digitální Česko“), např. program „Portál veřejné správy 2.0 (Portál občana)“;

• požadavky na bezpečnost a implementaci nových funkcionalit, potažmo služeb na PVS.


Cíle:

• zvýšení transparentnosti veřejné správy prostřednictvím nástrojů eGovernmentu;

• implementace základních principů eGovernmentu (zásada „pouze jednou“ atp.);

• zvýšení přístupnosti a uživatelské přívětivosti veřejné správy;

• dostupnost služeb z jednoho místa kontaktu s veřejnou správou.


Výsledek:

• Portál veřejné správy (upravený).


Posouzení:

• Portál Gov.cz (Vize a strategie rozvoje).


Tabulka 11: Vysvětlete, proč změnu projektu 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é osoby, cíle, principy, podmínky, architektonické požadavky):

Zainteresovaní:

• Ministerstvo vnitra;

• Dodavatel (NAKIT).


Tabulka 12: Katalog prvků motivační architektury

ID

Typ prvku

Jméno prvku

Popis prvku

{A1BEF29A-4D70-405c- 88F1-39445693BC40}

cíl

Cíle PVS

Souhrnný prvek.

{B93604B9-FDA1-4ce4- A827-DA9BB94D8C8F}

cíl

Dostupnost služeb z jednoho

místa

Dostupnost služeb z jednoho místa kontaktu

s veřejnou správou.

{5289594B-3DE4-4033- B0F2-0B2B7E3F9BCA}

cíl

Implementace základních principů eGovermmentu

Implementace základních principů eGovernmentu (zásada „pouze jednou“ atp.).

{2CFFC5C1-EDBE-4a45- B60A-BAFDBC809755}

cíl

Zvýšení přístupnosti a uživatelské přívětivosti veřejné správy

Zvýšení přístupnosti a uživatelské přívětivosti veřejné správy.

{A1357158-928C-4eea- BAA9-B30310504A76}

cíl

Zvýšení transparentnosti veřejné

správy

Zvýšení transparentnosti veřejné správy prostřednictvím nástrojů eGovernmentu.

{85692847-341E-48ca- 9188-AB96FC021FD5}

motivátor

Digitální Česko

Záměry a programy Strategie koordinované

a komplexní digitalizace České republiky 2018+ (dále též „Digitální Česko“), např. program

„Portál veřejné správy 2.0 (Portál občana)“.

{8FD67BDB-9180-45da- BD10-F57FC2A2BE66}

motivátor

Legislativní změny s účinností od roku 2020

Legislativní změny s účinností od roku 2020, především zákon č. 12/2020 Sb., o právu

na digitální služby a o změně některých zákonů.

{FE2E4BD3-878C-4aca- BAF7-E34BE15384AE}

motivátor

Sdružené motivátory

Souhrnný prvek.

{8DA8841B-F1B5-48c1- B491-6682DBC4B88B}

motivátor

Uživatelské a bezpečnostní požadavky

Požadavky na bezpečnost a implementaci

nových funkcionalit, potažmo služeb na PVS.

{CCF278F6-E346-4e55- 992B-F89534C24477}

posouzení

Portál Gov.cz (Vize a strategie rozvoje)

Analyticko-strategický dokument.

{2304CCE7-2899-48ed- BE27-456EED4865BE}

výsledek

PVS (upravený)

Výsledný produkt.

{9F74A5FC-0FBC-4d4e- 8626-DCA6F12DB819}

zainteresovaný

Ministerstvo vnitra

Ministerstvo vnitra

{6843A07A-F3EE-477c- B09F-31F2D157C357}

zainteresovaný

NAKIT, s. p.

NAKIT, s. p.


Diagram motivační architektury



2.2.2. Efektivita změny projektu – výkonnostní architektura

Portál veřejné správy představuje informační systém postavený na moderních trendech vývoje softwaru, jeho testování, nasazování a provozu, který pro svůj provoz využívá cloudovou platformu. Také v rámci rozvoje se pracuje s řešením odpovídajícím moderním trendům i ICT standardům, modularity návrhu řešení a efektivity v oblasti nákladů na provoz a následný rozvoj. Právě modularita systému a uplatnění ICT standardů tam, kde to je možné, zajistí efektivnější implementaci

Tabulka 13: Vysvětlete dopad změny projektu na hospodárnost, účelnost, účinnost, časovou a kvalifikační náročnost a na kvalitu služeb v organizaci (viz metodika TCO zveřejněná zde):


změn v rámci budoucích komplexů nových služeb a funkcí.

Rozvíjen a i nadále Portálem veřejné správy využíván bude také stávající design systém. Účelem design systému je a bylo vytvořit jednoduchá pravidla pro tvorbu webových stránek a aplikací, které budou konzistentní s webovými stránkami pod doménou gov.cz. V současné době design systém gov.cz přebírají další rezorty za účelem sjednocení designu také na svých webových stránkách. Dlouhodobým cílem je tento trend prohlubovat a rozšiřovat tak využívání design systému napříč webovými stránkami a aplikacemi celé veřejné správy, a to i v rámci intranetových aplikací pro úředníky. Využívání jednotného design systému má několik velkých výhod. Především splňuje nároky na uživatelskou přívětivost moderních webových stránek. Jednotný vzhled, jednotná funkcionalita ovládacích prvků a jednotná struktura informací vzbuzují v uživateli pocit jistoty, neboť ví, že je v interakci s veřejnou správou, ať se pohybuje na stránkách Ministerstva vnitra nebo jiné instituce, ví, co od stránek může očekávat a nemusí vynakládat velké úsilí na to, aby se na stránkách zorientoval.

Tabulka 13: Vysvětlete dopad změny projektu na hospodárnost, účelnost, účinnost, časovou a kvalifikační náročnost a na kvalitu služeb v organizaci (viz metodika TCO zveřejněná zde):


Tabulka 14: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb

Název v rámci projektu nově zřizované nebo měněné služby

Specifikace SLA parametru služby

Sjednaná mezní hodnota SLA parametru

Sjednaný způsob měření hodnoty SLA

Dostupnost všech služeb, rozhraní a integrací

v provozním (produkčním) prostředí

Technické komponenty budou dostupné pro konzumenty 24x7.

99,5 %, 24x7

Fault a Capacity Monitoring

v kombinaci s E2E testy

Dostupnost všech služeb, rozhraní a integrací

v předprodukčním (stage) prostředí

Technické komponenty budou dostupné pro konzumenty 10x5 od 8 do 18 hodin.

95 %, 10x5, 8 – 18 hodin

Fault a Capacity Monitoring

v kombinaci s E2E testy

Dostupnost všech služeb, rozhraní a integrací

v testovacím prostředí

Technické komponenty budou dostupné pro konzumenty 10x5 od 8 do 18 hodin.

90 %, 10x5, 8 – 18 hodin

Fault a Capacity Monitoring

v kombinaci s E2E testy

Podpora

Zákaznická podpora

24x7

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Kritická závada (nefunkční části systému, nedostupnost systému z URL ani z jiných zdrojů, systém nespolupracuje se systémy třetích stran atd.).

Zahájení do 2 hodin od nahlášení požadavku, vyřešení do 4 hodin

od nahlášení, 24x7

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Závada s vysokou prioritou (některá ze základních funkcí systému je nestabilní atp.).

Zahájení do 8 hodin od nahlášení požadavku, vyřešení do 24 hodin od nahlášení, 24x7

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Závada se střední prioritou (závada nemá vliv na funkčnost portálu, nedostatky nepodstatné povahy, např.

v podobě zvýšení doby odezvy

v běžném provozu).

Zahájení do 24 hodin od nahlášení požadavku, vyřešení do 96 hodin, 24x7

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Ostatní závady a požadavky na malé změny funkcionality portálu, které jsou řízeny procesy Request managementu.

Zahájení a vyřešení do jednoho měsíce nebo

v následující verzi (release), 24x7

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Závady detekované na testovacím prostředí

Zahájení do 8 hodin od nahlášení požadavku, vyřešení do 48 hodin od nahlášení, 10x5, 8 – 18 hodin

Měření na úrovni

ServiceDesku

Zahájení řešení požadavku –

odstranění závady

Závady detekované na předprodukčním (stage)

Zahájení do 8 hodin od

nahlášení požadavku,

Měření na úrovni

ServiceDesku


Tabulka 14: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb

Název v rámci projektu nově zřizované nebo měněné služby

Specifikace SLA parametru služby

Sjednaná mezní hodnota SLA parametru

Sjednaný způsob měření hodnoty SLA


prostředí.

vyřešení do 24 hodin od nahlášení, 10x5, 8 – 18 hodin


Zajištění služby HelpDesk a

monitoring služeb

Dostupnost služeb HelpDesk, kontaktní adresa elektronické pošty, kontaktní formulář a monitoring

Dostupnost a KPIs definována na úrovni služeb a rozhraní

Měření pomocí reportingu jednotlivých služeb

Činnost správy zranitelností

Periodické provedení a report

Pravidelný měsíční reporting

Vulnerability skenování, penetrační a bezpečnostní testování změn (předem definovaných), provozní deník

Kritické záplaty

Kritické záplaty

Instalovány během 12 hodin od vydání oznámení

Provozní deník


Tabulka 15: Popis povinných objektivně ověřitelných ukazatelů výkonnosti (příklad získání a výpočtu hodnot je uveden v metodice k tomuto formuláři; pokud nejsou zde uváděné objektivně ověřitelné ukazatele běžně dostupné, jako mohou být např. údaje o spokojenosti uživatelů nebo preferencích el. služby před neelektronickou, musí být jejich získání zahrnuto do změny projektu a zohledněno ve zdrojích nezbytných pro jeho realizaci a provoz)

Název nově zřizované nebo měněné služby

Předpokládaný počet transakcí za rok

Náklady na dokončenou transakci bez DPH? [Kč]

Jaké % uživatelů je spokojeno

s poskytovanou službou?

Jaké % transakcí je úspěšně dokončeno?

Jaké % uživatelů zvolí raději elektronickou formu služby než ne- elektronickou?

Počet učiněných podání

cca 25 000

0

95 %

99 %

100 %

Počet zobrazení/čtení údajů z AIS

cca 1 mil.

0

95 %

96 %

100 %


Tabulka 16: Popis volitelných objektivně ověřitelných ukazatelů výkonnosti

Název ukazatele

Předmět měření

Jednotka

Očekávaná hodnota od

Očekávaná hodnota do












2.2.3. Byznys architektura


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku

{86F2D207-4368-498e- B5AB-B257ACE2844C}

Byznys účastník

Autentizovaný uživatel

Uživatel, který je identifikován a autentizován s využitím NIA nebo autentizační služby ISDS.

{5934F4D5-29C7-428f- BED9-1ED1610DBC88}

Byznys účastník

Neautentizovaný uživatel

Uživatel, který nemusí absolvovat proces identifikace

a autentizace.

{BC4F9A89-2FF5-42b3- A4B2-DE7DC10A0A55}

Byznys účastník

OVM

Uživatel identifikovaný a autentizovaný z řad OVM.

{871DA0A2-9DC0-4d89- A777-3BD2F53CE2F5}

Byznys

role

Fyzická osoba

se záznamem v ROB

Role, ve které vystupuje vůči PVS autentizovaný uživatel. Podmínkou zasazení do role je evidence v ROB.

{59B67225-1F6A-4563- 8B95-D4AD6A22461B}

Byznys

role

Obecný uživatel

Role, ve které vystupuje vůči PVS neautentizovaný uživatel. Nejsou vyžadovány žádné podmínky pro zasazení do role.

{E7EC4B52-D5B8-4eed- B811-48EAEAD85C50}

Byznys

role

OVM

Role, ve které vystupuje vůči PVS zástupce OVM. Podmínkou je evidence v JIP/KAAS či ISDS.

{8EFFB6C7-3A68-459e-

Byznys

Informační PVS

Bod přístupu pro obecného uživatele či OVM.


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku

AC5A-FB8AF3DD01C8}

rozhraní



{D11CF7EC-E49D-47c9- 972D-CB33DA486F0B}

Byznys rozhraní

Mobilní aplikace

Bod přístupu pro fyzickou osobu se záznamem v ROB.

{3E9A86E8-5B4E-46ee- 8A6D-7C7B673BA895}

Byznys rozhraní

Portál občana

Bod přístupu pro fyzickou osobu se záznamem v ROB.

{E630CD9F-14E3-4bb7- BC00-14F8A113BD47}

Ohraničení (Boundary)

PVS

Perimetr informačního systému PVS.

{DE747F86-F56D-4af9- 991A-2B32B21466F0}

Byznys funkce

Agenda A344 - Portál

veřejné správy

Kolekce chování a kompetencí stanovená agendou RPP A344 – Portál veřejné správy.

{6F516384-B75C-4c63- B2DB-4A20ED3B9557}

Byznys funkce

CR47718 - Správa

portálu veřejné správy

Kolekce chování a kompetencí v rámci agendy A344 stanovená činnostní rolí Správa portálu veřejné správy. Zahrnuje v první řadě redakci informační PVS. Výkon na základě § 6g zák. č. 365/2000 Sb.

{59AB2B7D-7646-40fd- AC09-8D180D83F936}

Byznys funkce

CR51952 - Poskytnutí údajů a poskytnutí nebo obstarání výstupů z ISVS s využitím prostředku

pro elektronickou identifikaci umožňujícího přístup se zaručenou identitou

Kolekce chování a kompetencí v rámci agendy A344 stanovená činnostní rolí Poskytnutí údajů a poskytnutí nebo obstarání výstupů z ISVS s využitím prostředku

pro elektronickou identifikaci umožňujícího přístup se zaručenou identitou. Výkon na základě:

• zák. č. 365/2000 Sb., § 9 odst. 4 a 5;

• zák. č. 111/2009 Sb., § 5 odst. 5;

• zák. č. 110/2019 Sb., § 5.

{19034A5F-DE1C-4bb3- AA4C-D08F77FFE4F0}

Byznys funkce

CR79660 - Zveřejňování metodických pokynů

Kolekce chování a kompetencí v rámci agendy A344 stanovená činnostní rolí Zveřejňování metodických pokynů. Zahrnuje v první řadě zveřejňování věstníků a dalších zveřejňovaných informací. Výkon na základě § 4 odst. 2 písm. i zák. č. 365/2000 Sb.

{53BBA6D5-D67B-454a-

Byznys

CR79761 - Notifikace

Kolekce chování a kompetencí v rámci agendy A344

80B4-1E69D1D6DFBA}

funkce

o končící platnosti

stanovená činnostní rolí Notifikace o končící platnosti



dokladu, průkazu,

dokladu, průkazu, osvědčení nebo jiné veřejné listiny.



osvědčení nebo jiné

Zahrnuje notifikaci uživatele. Výkon na základě § 6g zák.



veřejné listiny

č. 365/2000 Sb.

{A93C159E-61C8-4784- 807C-515FF6DD94D4}

Byznys funkce

CRxxxxx - Nová činnost (Zápis údajů do základních registrů)

Kolekce chování a kompetencí v rámci agendy A344 stanovená činnostní rolí Zápis údajů do základních registrů. V tuto chvíli neexistuje, registrace proběhne v rámci tohoto projektu, až vstoupí v účinnost nové zákonné opatření.

{77AA1509-E9EC-4477- 8C56-48C87297CD02}

Byznys služba

Čtení údajů z AIS

Stávající služba rozšířená o:

• zpřístupnění údajů o vozidlech přihlášenému uživateli;

• zpřístupnění údajů o technických prohlídkách vlastněných či provozovaných vozidel přihlášenému uživateli;

• zpřístupnění certifikátu o provedeném očkování proti COVID-19 přihlášenému uživateli;

• zobrazení fotografií, údajů o platnosti dokladů

a digitalizovaných obrazů podpisů (scanů)

na Portálu občana přihlášenému uživateli;

• zobrazení daňového kalendáře přihlášenému uživateli.

{851EA2E3-AEA5-4c64- 8457-B17038F003D9}

Byznys

proces

Čtení údajů z AIS

Zpřístupnění údajů o vozidlech přihlášenému uživateli:




Výdej dat o vozidlech, u nichž je uživatel veden jako vlastník nebo provozovatel, a jejich zobrazení v Portálu občana.


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku




Z důvodů bezpečnosti (výdej dat pouze oprávněné osobě) je ze strany RSV umožněno vydávat údaje pouze pro subjekty ztotožněné se základními registry (ISZR) na základě AIFO. Tato podmínka je v Portálu občana splněna vzhledem k tomu, že jeho uživatelem může být občan, který se přihlásí jako fyzická osoba (FO) ověřená v registru obyvatel (ROB) nebo podnikající fyzická osoba (PFO) ověřená v registru osob (ROS).


Výdej dat o vozidlech v Portálu občana bude tedy dostupný pro fyzické osoby (FO) a podnikající fyzické osoby (PFO).


Účelem nové funkcionality je poskytnout občanovi – uživateli PO údaje o vlastněných nebo provozovaných vozidlech, a to jak v současnosti, tak i v minulosti. Tento požadavek může být splněn dvěma způsoby:


1. Zobrazení veškerých dostupných údajů z RSV, tzn. aktuálních i historických údajů.


2. Možnost výběru období (Datum od – Datum do), za které budou údaje zobrazeny. Pokud uživatel nezvolí žádné z datumů, budou zobrazeny pouze aktuální údaje. Zvolí-li uživatel pouze jedno z dat, doplní se druhé datum jako limitní takto:

• Chybí-li Datum od, zobrazí se údaje

od nejstarších,

• Chybí-li Datum do, zobrazí se údaje

do aktuálního data.


Zpřístupnění údajů o technických prohlídkách vlastněných či provozovaných vozidel přihlášenému uživateli:


Výdej dat o technických prohlídkách vlastněných či provozovaných vozidel, u nichž je uživatel veden jako vlastník nebo provozovatel, a jejich zobrazení v Portálu občana.


Z důvodů bezpečnosti (výdej dat pouze oprávněné osobě) je ze strany Informačního systému technických prohlídek (ISTP) umožněno vydávat údaje pouze pro subjekty ztotožněné se základními registry (ISZR) na základě AIFO. Tato podmínka je v Portálu občana splněna vzhledem k tomu, že jeho uživatelem může být občan, který se přihlásí jako fyzická osoba (FO) ověřená v registru obyvatel (ROB) nebo podnikající fyzická osoba (PFO) ověřená v registru osob (ROS).


Výdej dat o technických prohlídkách v Portálu občana bude tedy dostupný pro fyzické osoby (FO) a podnikající fyzické osoby (PFO).


Zpřístupnění certifikátu o provedeném očkování proti COVID-19 přihlášenému uživateli:


Výdej výstupu (certifikátu o provedeném očkování proti


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku




onemocnění COVID-19) uživatelům Portálu občana.


V Portálu občana je již vytvořen přímý odkaz na portál ÚZIS. Po kliknutí na tento odkaz dojde k převzetí autentizovaného uživatele, kdy proběhne uplatnění principu single sign-on. Následně je uživateli zobrazen jeho certifikát v prostředí ÚZIS. Stažení certifikátu na zařízení uživatele ve formátu PDF si uživatel může provést manuálně.


Dalším krokem je umožnění komunikace ISIN s Portálem občana prostřednictvím eGSB. Na Portálu občana bude vytvořena dlaždice služby, která umožní pouze stažení certifikátu do souboru ve formátu PDF, případně jeho uložení do úložiště dokumentů na Portálu občana.


Zobrazení fotografií, údajů o platnosti dokladů a digitalizovaných obrazů podpisů (scanů) na Portálu občana přihlášenému uživateli:


Zpřístupnění následujících údajů a jejich zobrazení

v Portálu občana:

• pro držitele občanského průkazu:

o digitální zpracování podoby občana;

o digitální zpracování podpisu občana;

o datum vydání občanského průkazu;

o datum skončení platnosti občanského průkazu;


• pro držitele cestovního dokladu:

o datum vydání cestovního dokladu;

o datum skončení platnosti cestovního dokladu;

o fotografie;

o podpis.


Z důvodů bezpečnosti (výdej dat pouze oprávněné osobě) je umožněno vydávat údaje pouze pro subjekty ztotožněné se základními registry (ISZR) na základě AIFO. Tato podmínka je v Portálu občana splněna vzhledem k tomu, že jeho uživatelem může být občan, který se přihlásí jako fyzická osoba (FO) vedená v ROB.


Fotografie a podpisy budou načítány pouze na vyžádání (akce ze strany uživatele) či pro specifické případy (učinění podání, kde je uvedené vyžadováno).


Zobrazení daňového kalendáře přihlášenému uživateli: Zpřístupnění daňového kalendáře přihlášenému uživateli

v prostředí Portálu občana, konkrétně napojení na informační systémy Ministerstva financí, zobrazení údajů z daňového kalendáře v Portálu občana a napojení na notifikační službu Portálu občana (notifikace uživatelů zvolenými notifikačními kanály typu e-mail nebo SMS o nadcházejících daňových povinnostech).


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku





Z důvodů bezpečnosti (výdej dat pouze oprávněné osobě) je umožněno vydávat údaje pouze pro subjekty ztotožněné se základními registry (ISZR) na základě AIFO. Tato podmínka je v Portálu občana splněna vzhledem k tomu, že jeho uživatelem může být občan, který se přihlásí jako fyzická osoba (FO) vedená v ROB.


Údaje z daňového kalendáře budou zobrazeny v komponentě kalendář na Portálu občana a tím i automaticky napojeny na notifikační službu.

{33CCE49C-39F1-4293- 8F3C-0F42744201C0}

Byznys služba

Prezentace a procházení design systému gov.cz

Stávající služba rozšířená o:

• nové komponenty design systému gov.cz.

{71EB32F3-6896-48fc- 8B28-43887EB8EF31}

Byznys

proces

Prezentace a procházení design systému gov.cz

Přístup k aktuální verzi design systému gov.cz (v době podání žádosti v 3.0.0) prostřednictvím:

• webu https://designsystem.gov.cz/#/;

• repozitáře git https://code.gov.cz/gov-cz/gov- design-system.


Design systém lze volně procházet, zdarma je dostupná dokumentace, nástroje, šablony a celý zdrojový kód. Design systém gov.cz je publikován pod veřejnou licencí EUPL v1.2.


Design systém bude obohacen o nové komponenty (v řádu jednotek) na základě požadavků nově implementovaných služeb na PVS.

{6FE17FF5-8081-4348- 8808-71A8E9E2F387}

Byznys služba

Učinění podání / odeslání formuláře

Stávající služba rozšířená o:

• elektronické podání žádosti o výměnu řidičského průkazu na Portálu občana;

• formuláře pro sbírku předpisů územních samosprávných celků (ÚSC) na informační PVS: formuláře, prostřednictvím kterých budou obce

a kraje publikovat, měnit či rušit právní předpisy

ve sbírce právních předpisů ÚSC.

{7AC35D7B-46B2-4ceb- 9E9E-17FA163285FB}

Byznys

proces

Učinění podání / odeslání formuláře

Elektronického podání žádosti o výměnu řidičského průkazu

na Portálu občana vč. notifikací o stavu vyřizování žádosti:


Implementace elektronického podání žádosti o výměnu řidičského průkazu na Portálu občana. Jedná se o realizaci první etapy řešení této funkcionality, tedy vydání nového řidičského průkazu pouze z důvodu konce platnosti předchozího dokladu, které není spojeno se správním poplatkem ani s dokládáním dalších dokumentů ze strany žadatele.


• Elektronické podání bude možné provést na Portálu občana s připojenou datovou schránkou FO, a to pouze v případě uplynutí platnosti nebo blížícího se konce platnosti ŘP (nikoliv při změně údajů na ŘP).

• Vyzvednutí vyrobeného ŘP (a vrácení starého ŘP) proběhne na žadatelem určené ORP.

• Žádost bude podléhat kontrole a schválení ze


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku




strany úředníka příslušné ORP, kterou si žadatel zvolil.

• Žadatel bude informován o vybraných změnách stavu žádosti pomocí notifikací z Portálu občana. Tyto notifikace ale nemají charakter rozhodnutí.


Odeslané žádosti budou na Portálu občana zobrazeny v sekci Podání / Moje podání. Zde bude k dispozici přehled všech žádostí uživatele (občana) podaných na CRŘ prostřednictvím ePodání. Přehled bude pro každou žádost obsahovat údaje:

• Datum podání žádosti;

• Důvod podání žádosti – v 1. etapě pouze „Žádost

o nový řidičský průkaz z důvodu konce platnosti“;

• K vyzvednutí / Vydáno – název ORP, která se žádostí zabývá;

• Stav žádosti – aktuální stav podané žádosti.


Žadatel ve spolupráci s OHA a OAS MV prověří i další možnosti činění elektronických podání, vč. možnosti využití jedné z datových schránek MV.


Detaily k žádosti v přiloženém zadání 3540.


Publikace formulářů pro sbírku předpisů územních samosprávných celků (ÚSC) na informační PVS:


Formuláře, prostřednictvím kterých budou obce a kraje publikovat, měnit či rušit právní předpisy ve sbírce právních předpisů ÚSC (obdobný princip jako u stávajících formulářů pro Registr smluv):

• cca 15 formulářů, které budou vyvěšeny na PVS – wireframy zde (mezi formuláři lze přepínat stiskem a podržením tlačítka menu v levém horním rohu obrazovky);

• formuláře budou odesílány prostřednictvím datové

schránky subjektu;

• vybraná pole se budou předvyplňovat údaji z veřejných číselníků (adresy, čísla předpisů) nebo webových služeb (volání webové služby pro předvyplnění některých údajů);

• vyplněné formuláře nebudou ukládány na PVS,

pouze odesílány datovou schránkou.

{0C62BCAD-A4A6-48b6- B663-C48AE2785A8F}

Byznys služba

Upozorňování na termíny a blížící se události

Nová standardizovaná notifikační služba na Portálu občana: zavedení jednotného systému klientských notifikací a upozornění pro přihlášeného uživatele.

{173EF4C9-BFA8-4a93- A263-052D7BDBE5F7}

Byznys

proces

Upozorňování na termíny a blížící se události

Proces popsán v přiloženém zadání 3367.

{5E8DBE52-EE4E-4f87- BE41-2AAF804AC150}

Byznys služba

Zápis údajů do AIS

Nová služba pro přihlášeného uživatele:

• nová funkce editace kontaktních údajů do ROB

a ROS pro přihlášeného uživatele;

• nová funkce editace kvalifikovaného certifikátu

do ROB pro přihlášeného uživatele.


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku

{8114F599-912C-4239- A07E-DEC2A75CC01F}

Byznys

proces

Zápis údajů do AIS

Editace kontaktních údajů v ROB a ROS:




Editační nástroj, který uživatelům Portálu občana umožní provádět zápis kontaktního údaje o telefonním čísle nebo adrese elektronické pošty do registru obyvatel (ROB) a registru osob (ROS).




Obsahem tohoto požadavku není funkcionalita editačního nástroje pro věcného správce (odbor správních činností MV).




K propsání změn kontaktních údajů do ROB/ROS bude využito volání příslušných eGON editačních služeb. V případě ROB bude pravděpodobně upravena stávající služba, pro ROS bude vytvořena nová služba pro sekundární editory. Datum změny (rozumí se zápis, změna i výmaz) každého z kontaktních údajů bude evidováno v provozních záznamech ROB/ROS, jakožto datum poslední změny tohoto údaje.




Kontaktní údaje nepatří mezi údaje referenční (jejich původcem je sám subjekt), nelze je označit za správné nebo nesprávné (jsou pouze informativní). Proto nebudou součástí stávajících formulářů pro zadání reklamace údajů v ROB/ROS.




Nová sekce kontaktních údajů bude zobrazovat:

• Telefonní číslo – obsahuje pro každý subjekt jedno číslo mobilní telefonní sítě (nikoliv číslo pevné linky) nebo prázdnou hodnotu. Lze využít číslo s předvolbou jakéhokoli členského státu Evropské unie (PVS pro notifikace disponuje tarifem pro celou EU).

• E-mailovou adresu – obsahuje pro každý subjekt jednu adresu elektronické pošty nebo prázdnou hodnotu.




Uživatel bude moci provádět zápis, změnu nebo výmaz příslušného kontaktního údaje.




V případě údajů v ROS bude u každé změny evidována také osoba, která změnu provedla a její role:

1. Podnikatel (podnikající fyzická osoba)

2. Statutární zástupce

3. Fyzická osoba zastupující právnickou osobu, která je členem statutárního orgánu jiné právnické osoby

4. Likvidátor

5. Opatrovník právnické osoby

6. Insolvenční správce

7. Nucený správce




Do Portálu občana nemají přístup statutární zástupci, kteří nejsou fyzické osoby. Pro tyto případy budou vytvořeny formuláře pro zadání změn kontaktních údajů v ROS na Portálu veřejné správy s možností jejich odeslání pomocí datové schránky.


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku




Editace kvalifikovaného certifikátu do ROB:


Editační nástroj, který uživatelům Portálu občana umožní provádět zápis údajů o kvalifikovaném certifikátu pro elektronický podpis do registru obyvatel (ROB).


Obsahem tohoto požadavku není funkcionalita editačního nástroje pro věcného správce (odbor správních činností MV).


K propsání změn údajů o kvalifikovaném certifikátu pro elektronický podpis do ROB bude pravděpodobně využito volání stávající upravené eGON editační služby. Datum změny (rozumí se zápis i výmaz) těchto údajů bude evidováno v provozních záznamech ROB, jakožto datum poslední změny tohoto údaje.


Údaje o kvalifikovaném certifikátu pro elektronický podpis nepatří mezi údaje referenční (jejich původcem je sám subjekt), nelze je označit za správné nebo nesprávné (jsou pouze informativní). Proto nebudou součástí stávajícího formuláře pro zadání reklamace údajů v ROB.


Uživateli budou nabídnuty možnosti:

• zobrazení sekce s údaji o kvalifikovaných certifikátech pro elektronický podpis;

• provést výmaz údajů o vybraném certifikátu;

• provést zápis údajů o novém certifikátu;

• zobrazení historie údajů o certifikátech (seznam expirovaných certifikátů).


Nová sekce bude zobrazovat přehled certifikátů evidovaných pro uživatele v rozsahu:

• sériové číslo – obsahuje sériové číslo certifikátu (v certifikátu je uvedeno v decimálním nebo hexadecimálním tvaru), navrhovaná maximální délka je 128 znaků;

• vydavatel – obsahuje název vydavatele certifikátu (řetězec uvedený v certifikátu obsahuje řadu údajů, jako název vydávající autority, obchodní název poskytovatele certifikátu, označení země, číselný identifikátor), navrhovaná maximální délka je 255 znaků;

• platnost – obsahuje datum konce platnosti certifikátu (v certifikátu je uvedeno ve formátu UTC).


Protože existuje možnost souběhu evidování více certifikátů uživatele v ROB, musí být údaje zobrazeny strukturovaně tak, aby bylo zřejmé, jak k sobě patří. Proto budou záznamy seskupeny podle údaje o vydavateli a v rámci této skupiny budou seřazeny vzestupně podle data platnosti (nejstarší nahoře). U již zapsaných certifikátů je nezbytné uživateli zobrazit všechny údaje vedené k evidovaným certifikátům tak, aby si mohl výběrem zvolit, se kterým certifikátem bude pracovat (uživatel může provést pouze výmaz údajů příslušného certifikátu).


Tabulka 17: Katalog prvků byznys architektury

ID

Typ prvku

Jméno prvku

Popis prvku




Datum platnosti certifikátu nemůže být zadáno do minulosti. Proto nelze zapsat údaje o již expirovaném certifikátu. Zapisované údaje o certifikátu se mohou týkat pouze kvalifikovaného certifikátu pro elektronický podpis. K tomu je nutné implementovat kontrolní mechanismus pro ověření certifikátu. Pro ověření, zda uživatelem předložený certifikát je kvalifikovaný nebo ne, bude využita opensource knihovna DSS.


Vždy ke dni následujícím po datu platnosti kvalifikovaného certifikátu pro elektronický podpis se údaje o tomto certifikátu z ROB automaticky vymažou (certifikát se stává neplatným a nejedná se tudíž o aktuálně evidované údaje). Z důvodu ověřování elektronického podpisu na dříve podepsaných dokumentech však přicházejí v úvahu i další varianty:

• Nemazat expirované certifikáty vůbec (tj. ponechat

je v ROB, dokud si je subjekt nesmaže).

• Mazat expirované certifikáty po stanovené době (např. 1 rok).


Rozhodnutí o zvolené variantě bude sděleno ze strany SRZ/ROB.


Tabulka 18: Využití front-office rozhraní předmětem změny projektu

Rozhraní

Využití

Popis využití rozhraní v projektu

Asistovaná přepážka


Umožnění asistovaného vyřízení podání či jiné služby v rámci projektu

Nerelevantní

Jedná se o plně elektronické samoobslužné služby.

Č. žádosti o výjimku:



Umožnění vyřízení služby na Kontaktním místě veřejné správy (Czech POINT)

Nerelevantní

Jedná se o plně elektronické samoobslužné služby. Kontaktní místa fungují paralelně vedle PVS.

Č. žádosti o výjimku:


Webový portál


Identifikace úředních osob vstupujících do procesu je řešena v souladu s JIP/KAAS

Ano, použito

Použito. Administrace a redakce PVS napojena

na JIP/KAAS.

Č. žádosti o výjimku:



Identifikace osob vstupujících do procesu je řešena v souladu se zákonem č. 250/2017 Sb.,

o elektronické identifikaci

Ano, použito

Použito na Portálu občana (transakční části PVS).

Č. žádosti o výjimku:



Portál poskytující služby klientům využívá design dle https://designsystem.gov.cz/

Ano, použito

PVS plně implementuje design systém gov.cz.

Č. žádosti o výjimku:


Datová zpráva (ISDS)


Využití Datových schránek pro účely doručování od OVM soukromoprávním subjektům a mezi OVM navzájem

Ano, použito

Použito na PVS v případě formulářů pro úředníky.

Č. žádosti o výjimku:



Tabulka 18: Využití front-office rozhraní předmětem změny projektu

Rozhraní

Využití

Popis využití rozhraní v projektu


Využití datových schránek pro účely dodávání mezi soukromoprávními subjekty navzájem

Ano, použito

Použito na Portálu občana.

Č. žádosti o výjimku:



Využití Informačního systému datových schránek pro účely příjmu úkonů učiněných soukromoprávním subjektem vůči OVM (např. podání)

Ano, použito

Použito na Portálu občana.

Č. žádosti o výjimku:


Elektronicky podepsaný dokument do e-Podatelny

Ne

PVS využívá jiné nástroje pro učinění podání

a odesílání formulářů (datová schránka, obstarání výpisu s přístupem se zaručenou identitou, přímé volání služeb ISZR).

Nepodepsaný dokument do e-Podatelny

Ne

PVS využívá jiné nástroje pro učinění podání

a odesílání formulářů (datová schránka, obstarání výpisu s přístupem se zaručenou identitou, přímé volání služeb ISZR).

Listinnou cestou do podatelny

Ne

Jedná se o plně elektronické samoobslužné služby.


Tabulka 19: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích

Služba využívající identifikaci, autentizaci a autorizaci

Vysvětlete způsob identifikace a autentizace do služby

Použitý prostředek (Pokud není určený LoA v NIA) a druh autentizace

Vysvětlete autorizaci ve službě (přidělení role, mandáty, zastupování, atd.)

Služby PVS – transakční části

Přístup s využitím jednoho z následujících způsobů (identifikaci a autentizaci upravuje § 6g odst. 3 zák. č. 365/2000 Sb.):

• kvalifikovaný systém elektronické identifikace dle zák. č. 250/2017 Sb. (NIA)

• autentizační služba ISDS (dle zák. č. 300/2008 Sb.)

V případě kvalifikovaného systému elektronické identifikace dle zák. č.

250/2017 Sb. (NIA) vyžadován prostředek na úrovni důvěry obecně nízká a vyšší

(na základě LoA konkrétní poskytované služby poté přístup je či není umožněn). Využívá občan (obecně fyzická osoba evidovaná v ROB).


V případě autentizační služby ISDS (dle zák. č. 300/2008 Sb.) přebírá PVS výchozí nastavení ISDS (připouští všechny prostředky). Využívá občan (obecně fyzická osoba evidovaná v ROB).

Autorizaci úkonů zajišťuje:

• PVS v podobě souhlasu s učiněním konkrétního úkonu (uchován např.

v podobě hash kódů)

• ISDS v případě vybraných úkonů realizovaných pomocí ISDS

Služby PVS – informační části

Přístup s využitím jednoho z následujících způsobů (identifikaci a autentizaci upravuje § 6g odst. 3 zák. č. 365/2000 Sb.):

• autentizační služba ISDS (dle zák. č. 300/2008 Sb.)

• autentizace pomocí služeb KAAS v rámci JIP/KAAS

V případě autentizační služby ISDS (dle zák. č. 300/2008 Sb.) přebírá PVS výchozí nastavení ISDS (připouští všechny prostředky). Využívá občan (obecně fyzická osoba evidovaná v ROB) nebo OVM.


V případě autentizace pomocí služeb KAAS v rámci JIP/KAAS umožněna pouze vícefaktorová autentizace. Využívá OVM.

Autorizaci úkonů zajišťuje:

• PVS v podobě souhlasu s učiněním konkrétního úkonu (uchován např. v podobě hash kódů)

• ISDS v případě úkonů realizovaných pomocí ISDS


Tabulka 19: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích

Služba využívající identifikaci, autentizaci a autorizaci

Vysvětlete způsob identifikace a autentizace do služby

Použitý prostředek (Pokud není určený LoA v NIA) a druh autentizace

Vysvětlete autorizaci ve službě (přidělení role, mandáty, zastupování, atd.)






Model byznys architektury (výkonu veřejné správy) – pohled činnostních funkcí


Model byznys architektury (výkonu veřejné správy) – pohled služeb veřejné správy


Tabulka 20: Vysvětlení v kontextu byznys architektury úřadu

a) jaké k záměru existují či vznikají duplicity a proč?

Cílem projektu je další rozvoj jednotného místa, jehož prostřednictvím může občan využívat elektronické služby státu. Projekt nenahrazuje již existující řešení vybudované v rámci jednotlivých institucí, které poskytují elektronické služby veřejné správy a umožňují elektronická podání. Cílem projektu je vytvoření prostředí, které zastřeší stávající řešení jednotlivých institucí a umožní snadno publikovat nové elektronické služby dostupné z jednoho místa. V případě již existujících elektronických služeb


Tabulka 20: Vysvětlení v kontextu byznys architektury úřadu

bude PVS odkazovat na existující formuláře spolu s předáním přihlášení (single sign-on) z NIA na web či aplikaci úřadu.

b) jsou využity všechny sdílené služby?

PVS je rozvíjen komplementárně s dalšími portály a webovými aplikacemi.

Vysvětlení změny byznys architektury měněného funkčního celku:

Kromě vlastní agendy lze prostřednictvím PVS přistoupit k dalším agendám veřejné správy – PVS je v tomto smyslu součástí federace portálů a webových aplikací.


2.2.4. Architektura informačních systémů (aplikací a dat)

2.2.4.1. Architektura informačních systémů – část: Aplikační architektura


Tabulka 21: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí

ID

Typ prvku

Jméno prvku

Popis prvku

{5157287B-CF18-41b8- ADA4-A4C94954880F}

Aplikační služba

Poskytované služby agendy A344

Chování aplikace definované agendou A344, resp. jejími činnostními rolemi, úkony a službami v mezích registrovaných agendových oprávnění.

{F680C645-BBA2-4e45- 94AA-20FFC4DB093E}

Ohraničení (Boundary)

ZR a přidružené zdrojové AIS

ISVS mimo perimetr PVS, které komunikují

s okolními systémy prostřednictvím ISZR.

{AC741D08-0C3D-4216-

Ohraničení

PVS

Perimetr informačního systému PVS.

81C7-7965F22F3BBD}

(Boundary)



{AAED1EC4-87B8-435b- 8D9F-4DB3481AB0A6}

Aplikační

spolupráce

Aplikace agendy A344

Agregace a spolupráce s dalšími ISVS za účelem výkonu agendy A344.

{E690B256-56D7-4bc9- A288-89A82C519D81}

Aplikační komponenta

AIS OVM

ISRT, RSV, CRŘ a další agendové IS.

{1CD25A01-8755-46ef- 96FD-F1BF8023BF7A}

Aplikační komponenta

AISCD

Agendový informační systém cestovních dokladů

{5A89A32F-458D-4363-

Aplikační

AISEO

Agendový informační systém evidence obyvatel

94DA-A1287F46009E}

komponenta



{3F8E198A-C7AA-417a- 9309-4075B94C4C1A}

Aplikační komponenta

AISEOP

Agendový informační systém občanských průkazů

{C13FB682-3725-4475- 834F-64CF9A2AB287}

Aplikační komponenta

eGSB a ISZR adaptér (rozšířený)

Adaptér bude rozšířen o nová volání a kontexty:

o služba pro zápis do ROB dle zákona č. 12/2020 Sb., § 10 odst. 2 (editace kontaktních údajů a údajů

o kvalifikovaném certifikátu)

o služba pro zápis do ROS dle zákona č. 12/2020 Sb., § 10 odst. 2 (editace kontaktních údajů)

o čtenářský kontext A1046.RidicUdaje

o čtenářský kontext A1046.RidicZadostPodani

o čtenářský kontext RSV

o čtenářský kontext ISTP

o publikační kontext A344.Notifikace

o služba E197 agendaMediaDataCtiAifo

o služba E188 eopCtiAifo

o služba E189 ecdCtiAifo

{F7650DD9-0E70-4de3- AD42-D753AB1F3225}

Aplikační komponenta

Formulářový server

Beze změny.




Centrální komponenta poskytující funkcionalitu chytrých interaktivních webových formulářů. Formuláře se dynamicky mění v průběhu vyplňování, poskytují průvodce, kontrolují a zobrazují výskyt chyb, provádí automatické


Tabulka 21: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí

ID

Typ prvku

Jméno prvku

Popis prvku




doplnění do dovození hodnot v jednotlivých polích, poskytují nápovědu, spouští akce a procesy a odesílají data či část dat do cílových systémů. Formulářový server bude zatím využit pouze pro vybrané, složitější formuláře, jež lze rozdělit na dílčí komponenty (především se jedná o formuláře, kde tělo formuláře lze rozpadnout do několika tematických částí).

{98BE45D9-B808-416e- B538-90CDA2A3847E}

Aplikační komponenta

ISDS

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

{5E0859D3-BC75-4a29- A9FA-CF5A106220D1}

Aplikační komponenta

Mobilní aplikace

Beze změny. Služby nově dostupné na Portálu občana budou automaticky zpřístupněny i zde.




Nejedná se o klasickou hybridní mobilní aplikaci, ale zabalení webové aplikace Portálu občana do podoby nativní mobilní aplikace, s využitím technologie application wrapping, tedy bez nutnosti provádění změn v podkladové webové aplikaci. Tím dostaneme tzv. progresivní webovou aplikaci (tento způsob tvorby webových aplikací razí především společnost Google).




Mobilní aplikace je vytvořena v souladu s požadavky a možnostmi dané platformy (Android, iOS), přitom je třeba vzít v úvahu, že uživatelé používají různé verze operačního systému. Aplikace využívá specifické vlastnosti mobilních zařízení, jako je dotykové ovládání, otáčení zobrazení aplikace, zjišťování polohy pomocí GPS, pořizování fotografií apod. Aby ji uživatelé mohli používat, musí si aplikaci stáhnout pomocí obchodu s aplikacemi (Google Play nebo App Store) a nainstalovat na své zařízení.




Způsob přihlášení bude upraven, jakmile proběhne úprava NIA v oblasti identifikace a autentizace pro mobilní aplikace (tzv. nevizuální přihlašování).

{0559130C-ADE5-4b3d- 8365-4FE3E9041A92}

Aplikační komponenta

NIA

Národní bod pro identifikaci a autentizaci

{B2A85771-16A3-47ca- 83CE-F522D8CAF6A7}

Aplikační komponenta

Notifikační služba

Komponenta spolu s procesem popsána v přiloženém zadání 3367.

{61B6B557-738C-42f3- B82F-72D1617BFBEA}

Aplikační komponenta

Portál informační části

Portál informační části integruje mj. moduly (komponenty) využívané informační částí PVS.

{79E32455-F793-4648- 9C27-0B91075D155F}

Aplikační komponenta

Portál transakční části

Portál transakční části integruje mj. moduly (komponenty) využívané transakční částí PVS (neboli Portálem občana).

{AC75FED1-A138-49b3- 93EF-3A69A665E9AF}

Aplikační komponenta

Základní registry

Zahrnuje ROB, ROS, RPP, RÚIAN a ORG.

{BF1FAA7D-5F29-4746-

Aplikační

Další služby CMS

Služby CMS zajišťující komunikaci s dalšími

901A-C44468AC7D7A}

rozhraní


systémy.

{D713A354-5C5E-48a0- B4FD-7838C6CE3564}

Aplikační rozhraní

ISSS

ISSS (Informační systém sdílené služby), dříve eGSB.


Tabulka 21: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí

ID

Typ prvku

Jméno prvku

Popis prvku

{2CC475D9-C122-409e- AF37-EEE6F0FDF384}

Aplikační rozhraní

ISZR

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

{49FB15D3-AD1A-4dae- A553-B240A075801A}

Aplikační rozhraní

REST a SOAP API sdílených mikroslužeb

Rozhraní mikroslužeb umožňující modulům portálu komunikovat s mikroslužbami a využívat jejich funkcionality.

{9C7755F5-AEE4-4cc7- 88A6-1E811574E4BD}

Aplikační rozhraní

REST API portálových služeb

Portálové aplikace zahrnují front-end část

a back-end část. Back-end část je tvořena REST API. REST API je voláno z webové aplikace či SPA (single page aplikace) portálu.

{6DAA9217-AAE8-4ee1- 9FDA-CF253E052A7C}

Aplikační rozhraní

SOAP/REST API integrační platformy

Formulářový server využívá integrační platformu pro přístup ke sdíleným službám

a mikroslužbám.

{DE00725F-A890-443f- 9438-7BBD702FE801}

Aplikační rozhraní

Webové HTTPS rozhraní

Uživatelské rozhraní.


Diagram aplikační architektury



Tabulka 22: Vysvětlení v kontextu aplikační architektury úřadu, tedy:

a) jaké k záměru existují či vznikají duplicity?

V rámci projektu jsou realizovány byznys požadavky vzniklé z legislativních či strategických potřeb – je tedy možné, že aplikační řešení, která jsou implementována, již na trhu v nějaké obdobě existují.

b) proč a jsou využity všechny sdílené služby?

N/A

Vysvětlení změny aplikační architektury měněného funkčního celku:

Architektonický koncept Portálu občana se opírá o současné hlavní trendy vývoje softwaru, jeho testování, nasazování a provozu, které je možné shrnout pod pojmy: Kontinuální integrace a kontinuální dodávky softwaru. Tyto progresivní metody nutně vyžadují nový pohled na provozní a vývojová oddělení, kde je žádoucí těsnější spolupráce a porozumění mezi členy provozu a vývoje. Tento pohled dostal označení DevOps (z anglických slov Developers, tedy vývojáři a Operations, tedy provoz). DevOps jako jedno slovo naznačuje, že vývojáři i provoz infrastruktury tvoří jeden tým, který se podílí na společném cíli, a tím je kvalitnější software s kratším intervalem dodání v bezpečnějším prostředí. DevOps, jakožto nová kultura IT společností, pak není cílem, ale cestou, která závisí na důvěře, učení a rozvoji. Základním konceptem pro vývoj jsou mikro služby provozované a zorchestrované v kontejnerech za kooperace „infrastruktury jako kódu“.


2.2.4.2. Architektura informačních systémů – část: Datová architektura


Tabulka 23: Katalog objektů a subjektů:

Objekt nebo subjekt, který je předmětem evidence

Vysvětlení objektu nebo subjektu

Označení objektu nebo subjektu dle Agend VS

Je objekt čerpán nebo poskytován jiným subjektům?

Fyzická osoba

Objekt je persistentně

Obyvatel 101-1 (základní podmínkou je evidence

v ROB).


V dalších agendách,

ke kterým PVS přistupuje a které mají zaregistrovanou strukturu údajů:


102-1 – Osoba

115-1 – Obyvatel

117-1 – Držitel občanského průkazu

118-1 – Držitel cestovního dokladu

1046-1 – Řidič

Je čerpán od jiného subjektu


evidován (uchováván) pouze



na úrovni referencí

do okolních systémů, tj. formou párů hodnot: cizí klíč

– systém. Z povahy návrhu PO jsou konkrétní atributy (jméno, příjmení, datum narození…), popř. další vázané objekty (řidičský

průkaz, list vlastnictví atp.):



• čerpány na základě zákonného oprávnění z dalších systémů,

• transientní.



Dotčený subjekt ovlivňuje či rozhoduje, komu / kdy / jak jsou předány, např. formou podání nebo jako identifikace do dalších systémů.





Zvolte položku.

Tabulka 24: Využití datového fondu základních registrů a dalších agend

Název

Použito

Vysvětlení

Základní registry

Způsob vedení datového kmene

Evidence jen identifikátoru (pseudonymu) a při potřebě zobrazení aktuální podoby referenčních údajů ze ZR



Tabulka 24: Využití datového fondu základních registrů a dalších agend

Název

Použito

Vysvětlení


Čtení údajů ROB

Ano

Zákon č. 111/2009 Sb., § 5 odst. 5. Všechny údaje.

Č. žádosti

o výjimku:



Editace údajů ROB

Ano

Zákon č. 12/2020 Sb., § 10 odst. 2. Editace kontaktních údajů a údajů o kvalifikovaném certifikátu.

Č. žádosti

o výjimku:



Čtení údajů ROS

Ano

Zákon č. 111/2009 Sb., § 5 odst. 5 a § 61 odst. 1. Všechny údaje.

Č. žádosti

o výjimku:



Editace údajů ROS

Ano

Zákon č. 12/2020 Sb., § 10 odst. 2. Editace kontaktních údajů.

Č. žádosti

o výjimku:



Čtení údajů RÚIAN

Ano

Zákon č. 111/2009 Sb., § 30 odst. 1 a § 62 odst. 1. Oprávnění na všechny údaje, přístup pouze k vybraným.

Č. žádosti

o výjimku:



Editace údajů RÚIAN

Nerelevantní

Není oprávněn k editaci.

Č. žádosti

o výjimku:



Čtení údajů RPP

Ano

Zákon č. 111/2009 Sb., § 51 odst. 11.

Č. žádosti

o výjimku:



Editace údajů RPP

Nerelevantní

Není oprávněn k editaci.

Č. žádosti

o výjimku:


Evidujeme subjekty nebo objekty, které nejsou v základních registrech

Ne

Evidovaným subjektem je fyzická osoba vedená v ROB.

Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů


Evidence obyvatel (ISEO)

Ano

Zákon č. 365/2000 Sb., § 9 odst. 4, a zákon č. 110/2019 Sb., § 5. Přístup k rodnému číslu (využíváno jako identifikátor vůči ISKN, očekáván přechod na AIFO dle možností ISKN).

Č. žádosti

o výjimku:



Cizinecký informační systém (CIS)

Nerelevantní

PVS v tuto chvíli nepotřebuje přístup k údajům z CIS.

Č. žádosti

o výjimku:



Evidence občanských průkazů (AISEOP)

Ano

Zákon č. 365/2000 Sb., § 9 odst. 4 a § 6g odst. 5. Přístup k datům platnosti dokladu, digitalizované podobě občana (fotografii) a digitalizovanému podpisu (scanu podpisu).

Č. žádosti

o výjimku:



Evidence cestovních dokladů (AISECD)

Ano

Zákon č. 365/2000 Sb., § 9 odst. 4 a § 6g odst. 5. Přístup k datům platnosti dokladu, digitalizované podobě občana (fotografii) a digitalizovanému podpisu (scanu podpisu).

Č. žádosti

o výjimku:


Informační systém sdílené služby (ISSS dříve jako eGSB)


Čerpání dat přes ISSS

Ano

Zákon č. 365/2000 Sb., § 9 odst. 4.


Kontexty:

• A1046.1 (Vlastník ŘP)

• A1046.RidicRozsirene (Řidič - rozšířené údaje)

Č. žádosti

o výjimku:



Tabulka 24: Využití datového fondu základních registrů a dalších agend

Název

Použito

Vysvětlení





• A1046.RidicZakladni (Řidič - základní údaje)

• A121.1 (Přehled o údajích autentizované osoby)

• A121.2 (Výpis údajů podnikatelského subjektu)

• A392.1 (Dlužník) – nasazený, ale nevyužívaný (z důvodu zamítnutí přístupu GŘC)

• A392.2 (ODU) – nasazený, ale nevyužívaný (z důvodu zamítnutí přístupu GŘC)

• A4003.1 (Poskytovatelé zdravotních služeb)

• A4003.2 (Zdravotnická dokumentace pacienta)

• A483.1 (Výpis údajů z Rejstříku trestů)


Publikování vlastních dat přes ISSS

Ano

A344.Notifikace:

• publikační kontext se službou ZapišData – agenda A344 (PVS) vystavuje uvedený kontext v ISSS, jehož prostřednictvím zapisují ostatní agendy notifikace do PVS.

Č. žádosti

o výjimku:


Komunikace mimo propojený datový fond


Využívání vlastních proprietárních rozhraní

Nerelevantní

Webová služba vzdáleného přístupu do ISKN (ČÚZK) vystavená v CMS (již dříve schváleno ze strany OHA do doby, než se ISKN napojí na ISSS).

Č. žádosti

o výjimku:



Tabulka 25: Způsob zajištění vedení datového kmene

Požadavek

Použito

Vysvětlení

Zajištění přístupu k datům pro správce předmětu projektu

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?

Ano


Č. žádosti o výjimku:


Budete mít výše popsaný přístup k datům zajištěn bez dodatečných finančních nákladů?

Ano


Č. žádosti o výjimku:


Budete moci se zpřístupněnými daty libovolně nakládat?

Ano


Č. žádosti o výjimku:


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?

Ano

Statistické údaje.

Č. žádosti o výjimku:


Jaké datové oblasti plánujete zveřejňovat jako otevřená data, kdy a na jakém stupni otevřenosti?

Statistické údaje.


Tabulka 26: Nakládání s osobními a citlivými údaji

Způsoby identifikace subjektů (FO, PO) v informačním systému (AIFO, IČO, klientský identifikátor, výjimečně rodné číslo nebo jiný identifikátor)

• AIFO

• ID datové schránky

• interní bezvýznamové identifikátory

Způsoby zavedení základních principů práce s osobními a citlivými údaji dle GDPR a zákona o zpracování osobních údajů

Zabezpečení zpracování:

Veškerá data vedoucí k identifikaci uživatele a jeho dokumenty jsou šifrovány.

Logování přístupů k osobním a citlivým údajům:

Veškeré aktivity jsou logovány. Věcný ani technický správce za běžných okolností nepřistupují k osobním a citlivým údajům uživatelů (pouze na vyžádání či se souhlasem klienta či v rámci uplatnění principů práce s osobními a citlivými údaji dle GDPR). Logy jsou vedeny v souladu se zákonem o kybernetické bezpečnosti a zasílány DC eGOV.

Používáte nakládání s osobními údaji na základě doloženého souhlasu subjektu údajů:

Ne, dle čl. 13 odst. 1 písm. c) GDPR představuje účel zpracování

„přístup k informacím veřejných orgánů a komunikaci s veřejnými orgány“, a to na základě zákona č. 365/2000 Sb., o informačních systémech veřejné správy, zákona č. 111/2009 Sb., o základních registrech, zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, zákona č. 250/2017 Sb.,

o elektronické identifikaci, zákona č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, zákona č. 106/1999 Sb., o svobodném přístupu k informacím).

Ostatní:

PVS se řídí principy práce s osobními a citlivými údaji dle GDPR.


Tabulka 27: Vysvětlení v kontextu datové architektury úřadu

a) jaké k projektu existují či vznikají duplicity?

Duplicity nevznikají.

b) jsou využity všechny sdílené služby?

Ano (viz tabulky 23 a 24).

Vysvětlení změny datové architektury měněného funkčního celku:

Nedochází ke změně datové architektury.


2.2.5. Technologická architektura – vrstva IT technologie (HW a SW)


Tabulka 28: Katalog uzlů a klíčových funkcí nebo služeb

ID

Typ prvku

Jméno prvku

Popis prvku

{3BE06F2B-1397-4571-

Technologická

Cloudová platforma

Technologická architektura vytvořená jiným subjektem.

8291-2C7446B25FE3}

služba











Diagram technologické architektury – pohled struktury IT technologické architektury


Tabulka 29: Využití sdílených IT technologických a platformních služeb

Název

Popis

Použito

PaaS

Pronájem technologií v datovém centru externího subjektu

Od třetí strany

eGC

Předpokládáte využití služeb eGovernment Cloudu v oblasti infrastruktury pomocí Dynamického nákupního systému?

Ano


Tabulka 30: Vysvětlení v kontextu technologické architektury úřadu

a) jaké k funkčnímu celku existují či vznikají duplicity?

Duplicity nevznikají. PVS se připravuje na využívání cloud computingu v souladu s hlavou VI zákona č. 365/2000 Sb., v tuto chvíli se však ještě nelze do informačního systému cloud computingu, jehož prostřednictvím bude zajištěn přechod na využívání cloud computingu pro orgány veřejné správy, zapsat, protože neexistuje, tedy podmínky zákona č. 365/2000 Sb. nejsou aktuálně splněny.

b) jsou využity všechny sdílené služby?

Ano.

Vysvětlení změny technologické architektury měněného funkčního celku:

Předmětem projektu není řešení technologické architektury, je využíváno prostředí vytvořené jiným subjektem (cloudová platforma), které je dimenzované pro provoz PVS.


Tabulka 30: Vysvětlení v kontextu technologické architektury úřadu

a) jaké k funkčnímu celku existují či vznikají duplicity?



2.2.6. Technologická architektura – vrstva komunikační infrastruktury


Tabulka 31: Katalog infrastrukturních komunikačních funkcí, sítí, cest a klíčových služeb

ID

Typ prvku

Jméno prvku

Popis prvku

{C88C9A05-4ECE-4e6a- 820C-C6CF622FB843}

Komunikační síť

IPSec

Kryptografické bezpečnostní služby pro ochranu komunikace prostřednictvím IP protokolu. Propojení cloudové platformy a perimetru CMS je zajištěno zabezpečeným způsobem, dle platných Provozních podmínek CMS a dokumentu Přehled služeb CMS.

{3453FE60-1683-4b9a- 96A0-1E613257A9D0}

Komunikační síť

Veřejný internet

Veřejný internet

{249E7D58-F5DE-455c- 8A99-F8B676E35411}

Lokace

Evropská unie

Lokalita datových center, kde je provozován PVS.

{923D86A9-A1D9-46f8- 9102-A0372DED4E37}

Uzel

Cloudová platforma

Technologické prostředí v podobě cloudové platformy využívané k vytváření, hostování a škálování webových aplikací skrze datová

centra.

{A36928CE-5CEE-4af6- 9D48-4655FC14F819}

Uzel

CMS

Centrální místo služeb. Je využito pro čerpání služeb eGSB (ISSS), DMZ, bezpečnostních služeb, přístupu k veřejnému internetu atd.

{0028466E-326B-4c43- 9177-A446AD285028}

Uzel

DC eGOV

Dohledové centrum eGovernmentu.


Diagram technologické architektury – pohled struktury komunikační infrastruktury



Tabulka 32: Využití sdílených služeb komunikační infrastruktury:

Název

Popis

Použito

Č. žádosti o výjimku

CMS

Pro publikaci služeb tohoto záměru je využito Centrální místo služeb

– aplikace jsou publikovány prostřednictvím CMS

Ano


KIVS

Využití komunikační infrastruktury veřejné správy, tj. fyzického propojení infrastruktury úřadů připojení k CMS

Ano


NDC

Umístění technologií do Národních datových center v perimetru CMS

Ne


Housing (IaaS)

Využití umístění vlastní HW infrastruktury do prostor datového centra

třetí strany

Ne



Tabulka 33: Vysvětlení v kontextu architektury komunikační infrastruktury úřadu, tedy:

a) jaké k záměru existují či vznikají duplicity a proč?

Duplicity nevznikají.

b) jsou využity všechny sdílené služby?

Ano.

Vysvětlení změny architektury komunikační infrastruktury měněného funkčního celku:

Nedochází ke změně.

2.2.7. Bezpečnostní architektura


Tabulka 34: Katalog bezpečnostní architektury funkčního celku

Dotčený nebo bezpečnostní prvek

Hrozba / riziko

Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury včetně technických a organizačních opatření

Firewall

Napadení ISVS,

nedostupnost

Správně nastavený a konfigurovaný FW zabrání hrubému útoku na aplikační a infrastrukturní komponenty.

Reverzní proxy

Nedostupnost, ochrana důvěrnosti datových toků, ochrana webových serverů

Rozkládání zátěže, další úroveň ochrany webových serverů.

Monitor integrity dat

Změna integrity dat

Změna datových souborů a konfigurací ISVS – narušení integrity – monitoring

odhalí, notifikuje a aktivně chrání.

WAF/Load balancer

Přetížení systému, ochrana před pokročilými hrozbami

Optimalizuje zatížení koncových obsluhovaných nodů.

SIEM Sentinel

Výskyt anomálií a kritických stavů

V rámci centrálního monitoringu je prováděno aktivní vyhodnocování generovaných logů a je prováděna proaktivní ochrana ISVS.

Antivirový systém

Napadení konfigurací systému a jeho dat, nedostupnost, cílená destrukce a zničení dat

Nasazením antivirového programu se sníží možnost nákazy.

Zálohovací SW

Ztráta dat, dlouhodobá

nedostupnost

Zálohováním se sníží riziko totální ztráty dat.

Monitoring zranitelností

Technologické zranitelnosti zneužitelné pro narušení dostupnosti, integrity a důvěrnosti ISVS

Stálým (periodickým) monitoringem je sníženo riziko neřízeného výskytu chyb ISVS, které může způsobit IS zranitelným.

PIM a session

recording

Kritické neautorizované zásahy privilegovaných uživatelů, a jejich neřízený, bezdůkazní přístup do ISVS

Řízení privilegovaných účtů a nahrávání pomocí komponenty SW řešení PIM a session recordingu.


Tabulka 35: Vysvětlení změny bezpečnostní architektury projektu

PVS je realizován a provozován v souladu se zákonem č. 181/2014 Sb. (zákon o kybernetické bezpečnosti) a vyhláškou č. 82/2018 Sb. (vyhláška o kybernetické bezpečnosti). Řešení zajišťuje odpovídající úroveň záruk pro elektronickou identifikaci, autentizaci a autorizaci uživatele včetně zajištění potvrzení projevu vůle k podání.

PVS je nasazen do dvou geograficky oddělených datových center za účelem zajištění vysoké dostupnosti (Amsterdam, Dublin). Obě lokality jsou provozovány v režimu „active-active“, tj. obě lokality jsou schopné vyřizovat klientské požadavky.

Fyzickou bezpečnost a bezpečnost síťové infrastruktury zajišťují správci datových center komerčního cloudu, ve kterých jsou provozovány technologické prvky.

Prováděné transakce pomocí formulářů a další činnosti jsou logovány. Je prováděno pravidelné zálohování databáze. Jako kryptografické prostředky jsou používány soukromé klíče a komerční certifikáty pro zajištění šifrované komunikace SSL/TLS s klientskými stanicemi a napojenými AIS/ISVS vydávajícími výpisy a údaje. Průběžně je updatována bezpečnostní politika a dokumentace PVS a havarijní plány.

2.2.8. Shoda s pravidly, standardizace a dlouhodobá udržitelnost


Tabulka 36: Uveďte, které licence standardizovaných SW produktů nebo HW produktů budete pořizovat formou centrálních rámcových smluv zajištěných Ministerstvem vnitra. Pokud tuto formu nevyužijete, vysvětlete proč:

Nerelevantní. PVS takové licence nevyužívá.


Tabulka 36: Uveďte, které licence standardizovaných SW produktů nebo HW produktů budete pořizovat formou centrálních rámcových smluv zajištěných Ministerstvem vnitra. Pokud tuto formu nevyužijete, vysvětlete proč:

Rámec

Odpověď

Vysvětlení důvodů nepoužití

Centrální nákup produktů Cisco Systems

Ne

Není zapotřebí.

Centrální nákup produktů IBM

Ne

Není zapotřebí.

Centrální nákup produktů Microsoft

Ne

Není zapotřebí.

Centrální nákup produktů Oracle

Ne

Není zapotřebí.

Centrální nákup produktů VMware

Ne

Není zapotřebí.

Centrální nákup ICT komodit

Ne

Není zapotřebí.

Centrální soutěžení KIVS

Ne

Není zapotřebí.


Tabulka 37: Shoda se strategickými dokumenty

Požadavek

Odpověď

Číslo žádosti

o výjimku

Vysvětlení

Je řešení v souladu

s Informační koncepcí úřadu?

Nerelevantní


Dle průběžných verzí ano, ale Informační koncepce MV není hotová. Nejsme

schopni posoudit soulad s finálním zněním.

Je řešení v souladu

s Informační koncepcí ČR a cíli či principy Digitálního Česka?

Ano


Řešení plní cíle programu Digitálního Česka Ministerstvo vnitra ČR / MVCR-4 [P] Program - Portál veřejné správy 2.0 (Portál občana).


V rámci Informační koncepce ČR plní cíl 1. Uživatelsky přívětivé a efektivní on-

line služby pro občany a firmy.

Je řešení

v souladu s NAP?

Ano


Více na https://archi.gov.cz/nap:popisy:popis_portaly_vs_spuu?s[]=port%C3%A1ly%2A


Tabulka 38: Legislativní update

Bude podpora zahrnovat rovněž udržování řešení v souladu s novými právními předpisy (tzv. legislativní update)?

Vysvětlete, v jakém rozsahu:

Jakým způsobem bude legislativní update hrazen?

Ano, vzhledem k rozsahu legislativních změn bude řešeno samostatnými objednávkami / změnovými požadavky v rámci smlouvy na rozvoj PVS, jmenovitě:

• zákon č. 35/2021 Sb., o Sbírce právních předpisů územních samosprávných celků a některých správních úřadů;

• změna zákona č. 111/2009 Sb., o základních registrech;

• změna zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů;

• zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů.

Změnové MD navíc


Tabulka 39: Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů změny projektu a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením (tzv. Exit strategie):

Transakční část PVS (Portál občana) se aktuálně nachází ve fázi udržitelnosti, která následuje po vstupní investiční fázi, jež skončila 30. 6. 2019. Fáze udržitelnosti dle pravidel IROP trvá po dobu 5 let (plánovaná životnost portálu je však delší), tedy do

roku 2024. Po tuto dobu bude zajištěna podpora provozu a případný rozvoj dle potřeb MV. MV má smluvně zajištěno


Tabulka 39: Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů změny projektu a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením (tzv. Exit strategie):

postoupení oprávnění k výkonu majetkových práv autorských k dílu a toto oprávnění je dále postupitelné. Je-li autorským dílem počítačový program, vztahuje se postoupení ve stejném rozsahu na autorské dílo ve strojovém i zdrojovém kódu, jakož i na koncepční přípravné materiály. MV je oprávněno autorská díla i jejich části bez dalšího samo jakýmkoli způsobem užít v původní, zpracované či jinak změněné podobě a udělit třetím osobám oprávnění (licenci) k výkonu práva autorská díla a/nebo jejich část užít. MV je dále oprávněno jakoukoliv nehotovou anebo nedostatečně podrobnou část autorského díla dokončit a díla anebo jejich části zveřejnit, upravovat, zpracovávat včetně překladu, spojit s jiným dílem, zařadit do díla souborného a uvádět je na veřejnost pod vlastním jménem.

MV v rámci VZ na rozvoj PVS získá zdrojový kód každé jednotlivé částí díla (SW), který musí být spustitelný v prostředí MV a zaručující možnost ověření, že je kompletní a ve správné verzi, tzn. umožňující kompilaci, instalaci, spuštění a ověření funkcionality. Toto platí jak pro implementaci díla, tak i pro záruční opravy a rozvoj.

Bude-li součástí díla proprietární SW, MV získá nevýhradní oprávnění užít jej jakýmkoli způsobem na území České republiky a v množstevním rozsahu, který je nezbytný pro pokrytí potřeb MV po dobu účinnosti smlouvy. Vždy musí být předána kompletní uživatelská, administrátorská a provozní dokumentace.

Bude-li součástí díla open source SW, je dodavatel povinen zajistit, aby se jednalo o open source software, který může být veřejnosti poskytován zdarma, včetně zdrojových kódů, úplné původní uživatelské, provozní a administrátorské dokumentace a práva takový software měnit.

Udělení veškerých práv výše uvedených nelze ze strany dodavatele vypovědět a na jejich udělení nemá vliv ukončení účinnosti Smlouvy.

Dodavatel odpovídá za jakoukoliv vadu díla či výstupů z plnění služeb rozvoje, jež se vyskytne v době trvání záruky, pokud není způsobena zaviněním MV z důvodu porušení jeho povinností. Dodavatel je odpovědný za to, že Servisní služby poskytne v souladu se Smlouvou a že po dobu trvání Smlouvy budou mít dohodnuté vlastnosti, úroveň a charakteristiky. V případě nedodržení těchto povinností (SLA v době provozu, termíny a kvalita v době dodání díla apod.) jsou stanoveny ve smlouvě smluvní pokuty. Odpovědnost dodavatele za škodu není limitována.

MV nepředpokládá po dobu provozu nákup jiných služeb než smluvně zajištěných, tedy od dodavatele PVS. Následně bude probíhat výběr dodavatele servisních služeb a dodávky rozvoje PVS pro další období dle platných zákonů.


Tabulka 40: Vysvětlení standardizace a udržitelnosti změny architektury měněného projektu

Ve stávajícím roce se nepředpokládá změna architektury měněného projektu, ani projekt dosavadní architekturu nemění. PVS je provozován kompletně v cloudu na škálovatelné platformě (Microsoft Azure) a jedná se o modulární aplikaci, kde vedle sebe běží několik modulů (lze tedy jednoduše přidávat a ubírat jednotlivé služby).


2.3. Kontrola shody změny architektury řešení funkčního celku s požadavky Národního architektonického plánu


Tabulka 41: Kontrola shody změny architektury řešení projektu se vzory sdílených služeb eGovernmentu

Název architektonického vzoru eGovernmentu

Byl dodržen vzor?

Č. žádosti o výjimku

Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu

Centrální místo služeb


Publikujete aplikační služby řešené tímto projektem do CMS druhé generace?

Ano


Ano, dojde k publikaci nové služby s využitím ISSS (publikace notifikačního kontextu).

Přistupujete ke službám jiných ISVS prostřednictvím CMS druhé generace?

Ano



Jakým způsobem přistupujete do CMS druhé generace?

IPSec



Využíváte vlastní připojení do veřejného internetu?

Ne


Ne, do veřejného internetu PVS přistupuje prostřednictvím CMS.

Univerzální kontaktní místo


Tabulka 41: Kontrola shody změny architektury řešení projektu se vzory sdílených služeb eGovernmentu

Název architektonického vzoru eGovernmentu

Byl dodržen vzor?

Č. žádosti o výjimku

Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu


Publikujete na CzechPOINT všechny své samoobslužné služby tak, aby mohly být přístupné i asistovaně?

Nereleva ntní


PVS využívá ke komunikaci centrální sdílené služby, jmenovitě CMS, ISSS, ISZR a ISDS, bez vlastních proprietárních řešení. Díky uvedenému může služby PVS využívat i Czech POINT, a to napojením na příslušnou centrální sdílenou službu (výpisy, poskytování údajů a dokumentů). Zde záleží na Czech POINTu, zda se rozhodne ke službám přistoupit.

Jste na centrálu CzechPOINT připojeni skrze systém CMS?

Nereleva ntní


PVS není přímo napojen na centrálu Czech POINT, komunikace probíhá pouze prostřednictvím ISDS.

Rozšířený backoffice úředníka


Máte služby CzechPOINT@office integrovány do svých systémů?

Nereleva ntní


PVS nevyužívá služby CzechPOINT@office.

Budou všechny interní aplikace dostupné z intranetu úřadu/resortu?

Ano


Ano, redakční systém PVS.

Bude využito principu

Single Sign-On?

Ano


PVS využívá systém JIP/KAAS.

ÚEP včetně eFakturace


Máte zajištěno předvyplňování formulářů ÚEP všemi státu známými údaji subjektu?

Ano


PVS přistupuje k údajům dostupným v rámci PPDF.

Máte zajištěn příjem a zpracování

elektronických faktur?

Nereleva ntní


PVS nezajišťuje uvedenou agendu.

Elektronický systém spisové služby


Je realizace propojení systému se spisovou službou vytvořena dle rozhraní definovaného v kapitole 9 Národního standardu?

Ano


PVS není z principu systémem pro správu dokumentů (ISSD). Hlavní komunikační kanál využívaný PVS, tedy všechny systémové datové schránky, je však napojen na eSSL v souladu se standardem.

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


Je prováděno automatické vytěžování přijatých formulářů do informačního systému?

Ano



Jakým způsobem je předmět projektu napojen na ISDS?

Přímo pomocí webovýc h služeb



Propojený datový fond


Jste ke službám PPDF připojeni skrze CMS?

Ano



Využíváte pro překlad identity mezi

Ano




Tabulka 41: Kontrola shody změny architektury řešení projektu se vzory sdílených služeb eGovernmentu

Název architektonického vzoru eGovernmentu

Byl dodržen vzor?

Č. žádosti o výjimku

Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu


agendami služby ISZR?




Využíváte pouze údaje, které máte explicitně uvedeny v daném zákoně?

Nereleva ntní


Zákon č. 365/2000 Sb., na základě kterého je PVS poskytována většina údajů, uvádí obecné oprávnění na údaje, nikoli taxativní výčet.

Odebíráte na údaje PPDF notifikace skrze služby ISZR?

Ano



Je veškerá výměna údajů mezi ISVS realizována pomocí referenčního rozhraní (ISZR, eGSB/ISSS)?

Ano



Elektronická identita


Využíváte služeb Národního bodu pro identifikaci a autentizaci?

Ano



Používáte pro překlad identifikátoru identity do své agendy (BSI na AIFO) služeb ISZR?

Ano



Využíváte při obsazení identifikované a autentizované osoby do role úředníka systém JIP/KAAS?

Ano



3. D A L Š Í Ú D A J E O Z M Ě N Ě P R O J E K T U

3.1. Majetkoprávní důsledky změny projektu


Tabulka 42: Majetkoprávní důsledky změny projektu

Podmínka

Odpověď

Poznámka (důvod)

Budou vám udělena výhradní práva k užívání k dodávanému produktu?


Ano

Bude řešeno nákupem autorských děl a licencí, včetně zdrojových kódů.

Budou vám udělena nevýhradní práva k užívání k dodávanému produktu?


Ne


Budou práva k autorskému dílu nějak omezena (IČO, konkrétní uživatel, převoditelnost a další šíření, úpravy produktu, parametry…)?


Ne


Budete mít přístup ke zdrojovému kódu pro čtení?

Ano

Ano – po dobu vývoje. Po předání s možností editace.

Bude vám či třetímu subjektu umožněno provádět údržbu, měnit produkt, upravovat jej či rozšiřovat bez souhlasu dodavatele?


Ano

Ano – vlastními silami i třetími stranami.

Budete mít přístup k aktuální technické dokumentaci produktu?


Ano

Ano – v rámci provozní smlouvy zajištěna pravidelná aktualizace dokumentace produktu ze strany dodavatele.

Obsahuje budoucí smlouva ujednání o vyloučení odpovědnosti za výpadky fungování?


Ano

Ano – zajišťuje provozní smlouva.

Budou externí nákupy veřejně soutěženy?


Ne

Realizovat bude NAKIT, s. p., v souladu se zákonem o zadávání veřejných zakázek jakožto zřizovaná organizace MV.

Bude celé nebo část řešení publikováno nebo bude využívat Open Source?


Ano

Ano – design systém gov.cz je a bude publikován pod veřejnou licencí EUPL 1.2 (veřejný git).


3.2. Finanční připravenost změny projektu


Tabulka 43: Finanční připravenost

Druh financování

Odpověď

Popis zajištění, získání financování

Financování pomocí ESIF1


Ne


Financování z vlastních zdrojů

Ano

Státní rozpočet

Financování pomocí jiných externích zdrojů


Ne




1 Evropské strukturální a investiční fondy

3.3. Metodická připravenost změny projektu


Tabulka 44: Metodická připravenost

Metodické zajištění

Odpověď

Popis

Řízení pomocí metodiky (uveďte název)

Ano

ITIL v4

Podpora od projektové kanceláře úřadu/resortu

Ne

Ne, zabezpečeno z vlastních personálních zdrojů.

Podpora od architektonické kanceláře úřadu/resortu

Ano

Ano, zajišťuje odbor Hlavního architekta eGovernmentu MV.

Bude tento formulář součástí zadávací dokumentace projektu?

Ano



3.4. Personální náročnost změny projektu


Tabulka 45: Vysvětlete personální náročnost změny projektu, jako odhady dopadu do počtu systemizovaných míst, či kapacitní náročnost realizace projektu dle FTE:

Navýšení o cca 1 FTE, zajištěno ze stávajících personálních zdrojů.


Ředitel projektu je zástupcem hlavního uživatele výstupu projektu a nositelem očekávaných přínosů projektu. Ředitel projektu může navrhnout do projektového týmu svého zástupce vybaveného věcnými znalostmi řešené oblasti a kompetentního pro provedení běžných věcných rozhodnutí.

Věcný a technický gestor je pro realizaci projektu hlavním zdrojem znalostí vstupů a výstupů projektu a navrhuje základní řešení projektu v souladu k cíli projektu. Je zástupcem uživatelů finálního produktu i všech, jimž budou výstupy projektu přínosem. V projektových strukturách zastupuje zájmy věcně příslušného liniového útvaru resortu. Je zároveň zástupcem budoucích uživatelů výstupů projektu.

Business analytik analyzuje a navrhuje analytické, plánovací a rozhodovací aktivity. Definuje jejich podporu prostřednictvím informačních systémů a informačních a komunikačních technologií (IS/ICT).


3.5. Harmonogram změny projektu


Tabulka 46: Harmonogram předložené změny projektu

Fáze / milník

Začátek

Konec

Základní náplň

Navazuje na

Investiční záměr projektu

02/2021

02/2021

Zpracování, odeslání a schválení investičního záměru


Oslovení potenciálního dodavatele a obdržení nabídky

02/2021

04/2021

Zpracování zadání pro potenciálního dodavatele, odeslání a obdržení indikativní nabídky

Zpracování, odeslání a schválení investičního záměru

Zpracování technického projektu / formuláře OHA

03/2021

04/2021

Zpracování, připomínkování a odeslání formuláře OHA

Zpracování, odeslání a

schválení investičního záměru

Znalecký posudek

03/2021

04/2021

Zpracování podkladů pro znalce, konzultace a obdržení posudku

Zpracování, odeslání a schválení investičního záměru

Obdržení kladného stanoviska PS pro transparentní veřejné zakázky

04/2021

05/2021

Zpracování informace pro PS MMR a obdržení stanoviska

Zpracování, odeslání a schválení investičního záměru


Tabulka 46: Harmonogram předložené změny projektu

Fáze / milník

Začátek

Konec

Základní náplň

Navazuje na

Zaslání informace na vládu

05/2021

05/2021

Zpracování a odeslání informace na vládu, vzetí na vědomí ze strany vlády

Zpracování informace pro PS

MMR a obdržení stanoviska

Podpis smlouvy s dodavatelem

05/2021

06/2021

Proces podpisu smlouvy

Zpracování a odeslání informace na vládu, vzetí na vědomí ze strany vlády

Zahájení vývojových prací

05/2021

06/2021

Zahájení vývoje, první jednání a stanovení reálného harmonogramu prací

Proces podpisu smlouvy

Průběžné analýzy, návrhy, vývoj, testování, implementace

06/2021

12/2021

Průběžné analýzy, návrhy, vývoj, testování, implementace

Zahájení vývoje, první jednání a stanovení reálného harmonogramu prací

Akceptace předmětu plnění

12/2021

12/2021

Akceptační procedura předmětu plnění smlouvy

Průběžné analýzy, návrhy, vývoj, testování, implementace


Tabulka 47: Související projekty (v rozvojovém programu, portfoliu úřadu)

Předchozí projekty

Popis návaznosti na předchozí projekty

Portál veřejné správy 2.0 – Portál občana (projekt IROP)

Projekt PVS 2.0 – PO představil poprvé transakční část Portálu veřejné správy (PVS) v podobě moderního personalizovaného samoobslužného místa pro přístup ke službám veřejné správy. PVS 2.0 – PO dnes nabízí možnost činit podání vůči vybraným orgánům veřejné moci (OVM) přímým způsobem, konkrétně prostřednictvím formulářů elektronického podání, a přístup k údajům z informačních systémů veřejné správy.

Rozvoj Portálu veřejné správy v roce 2020

Předmětem projektu byl navazující rozvoj Portálu veřejné správy, informační a transakční části, konkrétně jeho rozšíření a úprava vybraných stávajících funkcionalit v návaznosti na platnou legislativu a záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (neboli Digitálního Česka). Cílem projektu je mj. zvýšení hospodárnosti a bezpečnosti dotčeného informačního systému.

Souběžné projekty

Popis návaznosti na souběžné projekty

Czech Point 2.0

Implementace nového informačního systému veřejné správy Czech Point. Vybrané služby budou dostupné na obou platformách, PVS i Czech Point, a to např. jak v podobě asistovaného podání na kontaktním místě veřejné správy, tak v podobě elektronického podání na PVS.

Rozvoj Informačního systému datových schránek

PVS využívá řady služeb ISDS. Další rozvoj ISDS nabídne dostupnost nových služeb i prostřednictvím PVS či zvýšení uživatelské přívětivosti stávajících služeb.

Navazující projekty

Popis návaznosti na budoucí projekty

Czech Point 3.0

Faktické rozšíření předchozího projektu Czech Point 2.0. Zaměří se mj. na užší spolupráci a provázání Czech Point a PVS v oblasti služeb pro úřady a úředníky.




Tabulka 48: Vysvětlení dalších údajů o změně projektu



Tabulka 48: Vysvětlení dalších údajů o změně projektu



3.6. Ekonomické parametry změny projektu

Hrubý odhad hodnoty záměru nákupu služeb či investic (externích výdajů), souvisejících s informačními a komunikačními technologiemi (pořizovanými v rámci změny projektu - záměru).

Plán předpokládané ekonomické náročnosti záměru založené na metodologii 5 letých celkových nákladů vlastnictví

(tzv. Total Costs of Ownership) - účelové členění nákladů změny projektu (záměru).

Tabulka 49: Ekonomické parametry změny projektu

Souhrnná položka modelu TCO [Kč] bez DPH

① Výdaje na realizaci (výstavbu) projektu

② Výdaje na provoz a rozvoj (do konce aktuální smlouvy)

Vysvětlení k položce

Počet měsíců trvání fáze

8

0


A. Předběžné analýzy (vč. rizik), tvorba zadání, výběr řešení, výběr dodavatele – náklady nákupního procesu




B. Nákup SW a HW pro projekt (bez SaaS či PaaS)



<uveďte do tabulky 51 nebo samostatné přílohy rozpad výdajů, pokud výdaj přesahuje 10% celkové ceny projektu a současně přesahuje 1 mil. Kč>

C. Analýza, finální projekt, vývoj, implementace, školení uživatelů, zkušební provoz a testy, případně i migrace dat a akceptační audit

11 983 471


<při jakékoliv částce uveďte do tabulky 51 nebo samostatné přílohy seznam rolí s počtem člověkodnů a cenu za člověkoden>

D. Provoz a podpora řešení HW a

SW (bez SaaS či PaaS)



<uveďte do tabulky 51 nebo samostatné přílohy rozpad výdajů, pokud roční provoz a podpora přesahuje 20% celkové ceny řešení>

E. Hardware/Software údržba a průběžné úpravy (bez SaaS či PaaS)



<uveďte do tabulky 51 či samostatné přílohy rozpad výdajů, pokud roční údržba a průběžné úpravy přesahuje 20% celkové ceny řešení>

F. Projekty postupné inovace a zlepšování (plánované)




G. Projekty upgrade (pokud jsou plánovány)




H. Zvýšené náklady užívání řešení vč. nákladů na přechod

z předchozího řešení (pokud se vyskytnou)




I. Útlum, konzervace a ukončení řešení



<uveďte do tabulky 51 nebo samostatné přílohy rozpad výdajů, pokud útlum, konzervace a ukončení řešení přesahuje 10% celkové ceny řešení>

X. Licence, HW, provoz, podpora, údržba, průběžný rozvoj – vše

v subskripci (pouze SaaS a PaaS)



<uveďte do tabulky 51 nebo samostatné přílohy rozpad výdajů, pokud výdaj na SaaS a PaaS přesahuje 1 mil. Kč>

Z. Ostatní nerozlišené režijní náklady



<uveďte do tabulky 51 nebo samostatné přílohy rozpad výdajů, pokud výdaj na nerozlišenou režii přesahuje 0,5 mil. Kč>


Tabulka 49: Ekonomické parametry změny projektu

Souhrnná položka modelu TCO [Kč] bez DPH

① Výdaje na realizaci (výstavbu) projektu

② Výdaje na provoz a rozvoj (do konce aktuální smlouvy)

Vysvětlení k položce

Celkem

11 983 471




Tabulka 50: Popis funkčního celku, který je změnou projektu rozšiřován či upravován (pokud existuje)

Portál veřejné správy, především jeho informační a transakční část (Portál občana).

Plánované 5leté externí výdaje celého funkčního celku (mimo tento projekt) [tis. Kč]:

cca 140 000 tisíc Kč.


Tabulka 51: Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti změny projektu

Výše uvedené výdaje (11 983 471 Kč bez DPH) představují maximální možné výdaje v uvedeném kalendářním roce (2021).


Odbor eGovernmentu stále čeká na indikativní nabídku a znalecký posudek (obojí v procesu), od kterých se bude odvíjet upřesnění částky, na základě znaleckého posudku, č. 3453-45/2020 („Příloha č. 1 – Znalecký posudek“), a dosavadních zkušeností však odbor eGovernmentu dospěl k uvedené maximální možné částce.


4. V Y J Á D Ř E N Í K B E Z P E Č N O S T N Í M A S P E K T Ů M


Tabulka 52: Předkladatel prohlašuje, že předkládaná změna projektu bude realizován plně v souladu s níže uvedeným prohlášením

Text vyplňujte až na případnou výzvu OHA.

5. U P O Z O R N Ě N Í A D O P O R U Č E N Í


Tabulka 53:Upozornění a doporučení


6. P Ř Í L O H Y


Tabulka 54: Přílohy

Typ

Číslo a název přílohy

Upřesnění přílohy

Analýza

Příloha č. 1 – Znalecký posudek


Architektonický

model

Příloha č. 2 – Architektonický model


Analýza

Příloha č. 3 – Požadavek 3540 – Žádost o výměnu řidičského průkazu


Analýza

Příloha č. 4 – Požadavek 3367 – Notifikace o události prostřednictvím Portálu občana


Zvolte položku.



Celkový počet příloh:



Elektronický podpis - 7.6.2021 Certifikát autora podpisu :

Jméno : Ing. Roman Vrba

Vydal : PostSignum Qualified CA 4

Platnost do : 27.7.2021 10:57:24-000 +02:00

46

Document Metadata

Filed: June 7th, 2021