Výsledky studie federace portálů veřejné správy

Tato studie se zaměřuje na federaci portálů veřejné správy (z pohledu uživatele/klienta, nikoli úředníka), jelikož veřejná správa vytváří řadu dílčích a z pohledu uživatele odlišných portálových řešení – agendové, územní a soukromé. Tyto portály následně poskytují služby klientům (fyzickým i právnickým osobám) za jednotlivé ústřední správní úřady a územní samosprávy – kraje a obce (agendové a územní portály). Nad těmito samostatnými portálovými řešeními jsou již existující zastřešující, federující, portálová řešení – Portál veřejné správy (PVS) a jeho transakční části Portál občana (PO) a připravovaný Portál podnikatele (PP).

Cílem federace portálů veřejné správy je zajistit uživatelům přívětivou a efektivní konzumaci digitálních služeb veřejné správy a umožnit jim pohyb mezi portály při zachování jednotného uživatelského zážitku.

Studie má několik cílů, které jsou rozepsány v jednotlivých, na sebe navazujících kapitolách, jež se zabývají tématy:

• Definice portálu a federace portálů, včetně obecných principů, rozdílů mezi federujícím a federovaným portálem a přínosů federace;
• Funkce, které musí federované a federující portály veřejné správy poskytovat, zpracované formou katalogu požadavků;
• Analýza dvou zahraničních vzorů dobré praxe, včetně popisu podpory byznys funkcí federujícími a federovanými portály;
• Popis cílového stavu včetně pravidel a podmínek pro federaci portálů veřejné správy;
• Popis současného stavu, GAP analýza mezi cílovým stavem Portálu veřejné správy, Portálu občana a vybranými agendovými a soukromoprávními portálovými řešeními.

Studie se zabývá převážně vizí, respektive budoucím chtěným stavem v oblasti portálů VS, a tak při jejím vzniku byly odhalovány a následně popisovány nové definice, některé již existující výchozí byly převzaty a mírně upraveny. V této souvislosti byly definovány například pojmy vztahující se k centrálním komponentám, které by měly být poskytovány a využívány jednotně. Funkce centrálních komponent jsou dostupné lokálním portálům ve formě sdílené komponenty, případně fragmentu řešení, které usnadní výstavbu portálového řešení.

Portál, pro účely této studie, představuje samoobslužný interaktivní digitální kanál veřejné správy, který primárně slouží jako jednotný přístupový bod či brána k digitálním službám orgánů veřejné moci. Takto definovaný portál vystupuje jako funkční celek, který realizuje všechny typy služeb, jež jsou definovány Informační koncepcí ČR.

Termínem federace je pak označeno sjednocení samostatných dílčích celků (portálů) do jednoho digitálního prostoru. Dílčí portály zprostředkovávají informace a data nadřazenému portálu a jedná se v prvé řadě o propojení obsahu a funkcionalit dílčích portálů včetně chování a interakce v nich samotných směrem nahoru. Je vytvořen ale také směr dolů, kdy uživatel (občan) využije jedno univerzální vstupní místo, které mu umožní mít celkový přehled nad službami veřejné správy. Z jednoho místa tak může uživatel formou aktivních kroků konat v tomto digitálním samoobslužném portále, a zároveň může být navigován odtud k digitálním službám a k digitálním úkonům do agendových portálů, portálů územní samosprávy či soukromoprávních portálů.

Jelikož cílem projektu je digitalizace služeb veřejné správy a usnadnění přístupu občanů k OVM, je nezbytné při jeho realizaci brát v potaz mimo právních nástrojů koncepčního typu, jakými je například Informační koncepce ČR, rovněž řadu různorodých právních předpisů (vč. všeobecně právně nezávazných). Zejména ve vztahu k technickému řešení projektu bude vhodné, a to i přestože tyto materiály nejsou přímo závazné (a jsou spíše interní povahy), reflektovat rovněž doprovodné dokumenty k Informační koncepci ČR, jako je metodika designu UX/UI.

Některá portálová řešení již mají přímou oporu (a omezení) v zákonech, jako Portál veřejné správy a Portál občana, jiné dosud explicitně definovány právními předpisy nejsou.

Klíčovým právním předpisem pro realizaci projektu je ZPDS, který zakotvil právo občanů na digitální služby a současně určil podmínky jejich realizace ze strany OVM, soulad s požadavky a obsahové naplnění ZPDS tak je jedním z klíčových bodů tohoto projektu.

Za účelem spolehlivosti a důvěryhodnosti systému federace portálů, bude uživateli služby umožněno provést svou identifikaci a autentizaci prostředkem pro elektronickou identifikaci dle jeho volby, a to za současného vyhovění požadavkům ZoEI ve vztahu k využívání údajů z ISVS. Vzhledem k tomu, že množství digitálních úkonů uživatelů služby VS bude vzájemně směřovat od uživatele vůči OVM (a opačně), je pro takové úkony na základě současné právní úpravy nezbytné zajistit soulad s požadavky na elektronický podpis nebo elektronický úkon.

Významnou skutečností, která se v rámci realizace projektu projeví rozličně v závislosti na jednotlivých federovaných portálech a ze své povahy se týká zejména, ovšem nikoliv výlučně, portálů provozovaných OVM, je naplnění požadavků na zákonné informační povinnosti.

Jelikož v souvislosti s realizací projektu federace portálů bude docházet k značnému množství personalizačních aktivit, jejichž cílem je uživatelům služeb práci s portály usnadnit, a k ukládání personalizačních dat na servery back-end komponent IS portálů,bude třeba zajistit soulad s požadavky předpisů na poli ochrany osobních údajů, včetně souvisejících technických opatření jako je např. nastavení cookies policy a caching policy.

Je nutno také uvést, že vzhledem k zamýšlené šíři projektu je nezbytně nutné vzít v potaz v současnosti existující legislativní rámec, jímž jsou zejména právní regulace portálu veřejné správy (a portálu občana jakožto jeho součásti) v podobě obsahových a funkčních náležitostí, jak tyto stanoví ZISVS. Současně je ale vhodné při realizaci projektu neopomenout ani skutečnost, že některé v projektu federace portálů dotčené oblasti v současnosti nejsou jakkoliv (závazně) regulovány a k jejich regulaci může zákonodárce teprve v budoucnu přistoupit.

Co se týče realizace jednotlivých částí projektu (např. federovaných portálů), tak ze strany veřejných zadavatelů (např. provozovatelů federovaných portálů, kteří jsou OVM) je třeba vzít potaz i otázku regulace ZZVZ. Zároveň při smluvním zajištění takové realizace nesmí být opomenuta ani otázka smluvního zajištění práv duševního vlastnictví, případného předání zdrojových kódů, a dalšího maintenance realizovaných částí projektu.

Informační architektura

Portálová řešení veřejné správy má uživatel služeb VS vnímat sjednoceně, a to zejména z pohledu informační architektury. Ovládací části, například menu, mají společné části funkcí a obsahu zobrazovat shodně a ideálně na stejných pozicích. Jazyk a pojmosloví portálových řešení musí být jednotné a uživatelům srozumitelné – je potřeba maximálně přiblížit „úřední jazyk“ běžnému uživateli, tj. přeformulovat úřední pojmy do jazyka klientů. V neposlední řadě by portálová řešení měla být shodná vzhledově. Je potřeba dokončit již rozpracovaný Design System (metodika designu UX/UI), dotáhnout jej do podoby plně využitelné libovolným portálovým řešením a spolu s tím definovat jednotnou informační architekturu.

Single Sign On (NIA)

Přestože zadání „zajistit občanům přívětivou a efektivní konzumaci digitálních služeb státu a umožnit jim pohyb mezi portály při zachování jednotného uživatelského zážitku“ platí přirozeně i pro anonymní, neautentizované uživatele, tak nejzásadnějším prvkem federovaného řešení je jednotné přihlášení (SSO) pomocí NIA a možnost přecházet mezi portály bez nutnosti opakované autentizace. Tento prvek je základem bezešvého přechodu v plném slova smyslu.

Vyhledávání informací

Pomocí portálových řešení musí být uživatelé schopni nalézt informace stejně dobře jako pomocí internetových vyhledávačů (Google, Seznam aj.). Vyhledávání a disciplíny s ním spojené, vyjmenujme nejméně SEO (optimalizace webových obsahů pro správné vyhledávání internetovými prohlížeči), představují náročný úkol. Je potřebné vytvořit tým na centrální úrovni, který pojme veškeré know-how a který bude schopen podporovat ideálně všechna ostatní portálová řešení a zajistit pro ně vyhledávání jako službu s využitím těch IT partnerů, jejichž služby poskytují potřebné technologie.

Centrálně spravované informační báze a komponenty

Portál veřejné správy jako centrální bod federace ujednotil pohled na služby veřejné správy a životní situace. „Číselníky“ těchto služeb představují dobrý základ, jejich použití napříč portálovými řešeními veřejné správy musí být jednotné, stejně jako nakládání s jejich obsahem. Musí být vyřešeno nakládání s lokálními životními situacemi a s tím souvisejícími novými a např. časově nebo místně omezenými službami. Mohou být nalezeny další oblasti vhodné k využití při naplňování strategie

Portál veřejné správy, dnes zatím především Portál občana, umožňuje uživatelům ovládání vlastního profilu, tj. uzpůsobení části vzhledu a funckionalit osobním potřebám a preferencím. Nejde jen o to, že ostatní portály by měly nabídnout stejnou možnost. Ve federaci portálů jde o to, aby nabízená řešení privátních sekcí všech portálů byla pro uživatele podobná z hlediska vzhledu a chování. Některé prvky sem náležící by měly představovat centrálně garantovaná řešení, ať již jako centrálně sdílené komponenty nebo centrálně dostupný sdílený kód (případně kombinace). Jako příklad takových komponent uveďme: Kalendář, Notifikace (upozorňující zprávy), Mandáty (zplnomocnění k zastupování), Přehled transakcí, Data realizovaná uživatelem (úložiště dat uživatele), Rezervace schůzek (fyzických nebo on-line), Sběr zpětné vazby atd.

Komponenty musí být zcela nebo částečně centrálně garantované, protože to jim dává důvěryhodnost a umožňuje jejich opakované využití. Komponenty musí být sdílené a hierarchicky řízené, protože uživatel u mnoha funkcionalit si nepřeje provádět stejné nastavení opakovaně podle počtu agendových a územních portálů, se kterými řeší své životní potřeby. Na druhou budou existovat komponenty, u kterých naopak bude nutné najít způsob pro souběžné fungování prezentace centrálního i lokálního obsahu a vyřešit problém priority.

Zpětná vazba, měření výkonnosti

Federace portálů představuje platformu pro spojení mnoha již hotových nebo vznikajících portálových řešení. V tomto prostoru musí být uživateli jasné, kam se má obrátit v případě dotazu nebo komu může sdělit svoji zpětnou vazbu. Hodnocení portálových řešení a sběr zpětné vazby od uživatelů představuje důležitý impuls pro investování do správných částí a zlepšování procesů, které by mohly fungovat ještě lépe. Jednotnost přístupu a vyhodnocování zpětné vazby přes celou veřejnou správou a díky federativnímu řešení také za mimo její hranice, je nezbytná funkcionalita, kterou není možné opomíjet.

Účelem dokumentu je vytýčit základní oblasti a upozornit na problémy, které bude potřeba ve federované organizaci portálů řešit. Oblasti k řešení v dokumentu adresují tzv. pravidla. Problémy, pokud je lze již nyní předvídat, jsou připomínány v textech patřičných kapitol pomocí názorných příkladů z praxe nebo doplněním popisů pravidel. V dalším textu je uveden stručný přehled zásadních pravidel federace portálů.

Řízení federace portálů

Zajištění výstavby a fungování federace portálů se neobejde bez vzniku týmu, který za celou problematiku ponese odpovědnost. Pouze z jednoho centra je možné efektivně rozvíjet a provozovat takto rozsáhlou technologickou strukturu zasahující stovky organizací. Vypůjčením definice z politologie, musí vzniknout „federální orgány“ vedle těch „lokálních“ – agendových, územněsprávních nebo jiných portálů. Federální, v dokumentu pojmenované jako federující orgány, řídí a rozvíjí celé řešení navenek (směrem k uživatelům) a pomáhají federovaným v mnoha pro ně nových oblastech. Do budoucna by nemělo jít nadále o konfederaci, tj. volné sdružení portálových řešení, ve kterém samostatná portálová řešení implementují požadavky jen dle vlastního, autonomního uvážení. Setrváním v tomto směru by nemuselo být vůbec dosaženo cíle vnímání digitálních služeb veřejné správy ze strany uživatele jako bezešvého jednotného řešení. Je plně v kompetenci MVČR, do jaké části organizační struktury federující centrum zařadí.

První zástupci takového týmu by měli být UX výzkumníci a UX designeři a první náplní jejich práce by měl být start výzkumů představ digitalizace uživatelů napříč dnešním stavem. Tým by začal zkoumat jak agendy v přímé podřízenosti MVČR, ta by se zaměřil na agendová řešení, které nejsou v kompetenci MVČR. Výsledky by byly předány odpovědným pracovníkům AIS. Ušetřilo by jim to vlastní průzkumy a umožnilo start spolupráce napříč budoucí federací portálů. Bude to zmíněno až v kapitole popisující nejbližší raodmapu budování federace portálů, ale na prvním místě by centrální tým měl především spojit všechny agendové „nadšence“, kteří o digitalizaci upřímně usilují a snaží se ji všemožně (někdy možná nesystémově) realizovat.

Základní pravidla

Z obecnějších pravidel pro jednotlivé portály platí podle NAP, že:

• musí být registrovaný jako informační systém veřejné správy v rejstříku informačních systémů veřejné správy,
• spravuje ho orgán veřejné správy, který vykonává jednu nebo více agend dle seznamu agend veřejné správy,
• musí být součástí federace portálů veřejné správy a poskytovat informace a služby do centrálních (federujících) portálů jako je např. Portálu občana,
• musí být součástí federace národního identitního schématu, tedy využívat služby Národní identitní autority a jeho správce musí být ohlášen jako kvalifikovaný poskytovatel služeb,
• musí k identifikovanému a autentizovanému uživateli být schopen propojit údaje své agendy a údaje z propojeného datového fondu a veřejného datového fondu,
• musí využívat datovou základnu Katalogu služeb a životních situací v RPP,
• musí být v souladu s grafickým manuálem MVČR https:%%//%%designsystem.gov.cz,
• musí být schopen poskytnout identifikovanému a autentizovanému uživateli možnost udělit mandát/oprávnění k zastupování pro jednotlivé služby, propsat do MR a nastavené mandáty zobrazovat, přijímat a rušit,
• musí umožnit učinit podání v úkonu a ke službě z katalogu služeb VS pomocí následujících kanálů:
  • ISDS
  • podaní s identitou z NIA
  • podepsaný dokument s elektronickým podpisem,
• musí být schopen poskytnout náhled na jednotlivá podání vůči úkonům a služeb identifikovanému a autentizovanému uživateli a to jak tomu, který podání učinil, tak tomu, který je k tomu zmocněn,
• musí být schopen poskytnout úhradu poplatku pomocí platební brány, a vedle toho podle autorů studie platí pro portály, že:
• splňují minimální bezpečnostní standard vydaný organizací NÚKIB; pro většinu agendových řešení veřejné správy to nebude problém – splňují vyšší standardy, ale federace předpokládá zapojené též soukromoprávních řešení,
• implementují předepsané centrální komponenty.

Federaci portálů veřejné správy, bude-li jako koncepce přijata, chápou autoři tohoto dokumentu jako součást naplňování cílů Informační koncepce České republiky za účelem dalšího posunutí digitalizace veřejné správy vpřed k plnému eGovernmentu. Klíčovým předpokladem naplnění cílů federace portálů bude koordinované řízení lokálních portálových řešení v oblastech:

• dostupnost a využití sdílených centrálních služeb a SW komponent
• realizace pravidel, resp. implementace funkcionalit popisovaných v přechozích dvou kapitolách,
• pomoci s budováním odborných kapacit a kompetencí,
• koordinace příprav legislativních změn na úrovni centrální nebo agendové (bude-li to nutné),
• údržba a využívání jednotných informací a znalostí.

Základní předpoklad proveditelnosti pravidel byl zmíněn již v přechozí kapitole požadavkem na vznik centra řídícího výstavbu a následně koordinovaný běh federované organizace, které musí zajistit další analytické rozpracování pravidel a z výstupů vyvodit, naplánovat a řídit další kroky.

Federujícímu centru musí být zajištěny potřebné kompetence a legislativní rámec.

Pro sestavení a částečnou validaci seznamu funkcí, které vstupují do vize federace portálů v rámci veřejné správy ČR, bylo využito poznatků z vybraných zemí, které mají digitalizaci VS na vysoké úrovni. Mezi vybrané země patří Dánsko, Finsko a Norsko. Všechny zmíněné země nicméně nedisponují federací, ale centralizací portálů. Množství dílčích portálů je v těchto zemích sníženo na minimum a jejich obsah je centralizován do hlavního portálu, případně do dalších podpůrných portálů (portál zdraví, portál pro podnikatele). V případě Norska je rodina portálů rozmanitější a je více podobná portálům v ČR, vyjma těch územních.

Veškerá data mezi portály jsou tedy přenášena na úrovni back-endu s využitím národní služby pro výměnu dat (service bus). Nejsou žádné výjimky, které by vynucovaly komunikaci mimo tuto službu, ani které by povolovaly přímé volání portálu a služeb bez jeho jejího využití. Zahraniční portály jsou ve větší míře provozovány v cloudu. Většina zdrojových kódů je pak uložena na platformě GitHub a celá řada repositářů je open source.

Finsko pak disponuje velice propracovaným systémem elektronických mandátů, které poskytují jak automaticky udělované mandáty, díky napojení na různé registry a agendové IS. Vedle toho je pak možné sestavit si unikátní mandát (pro zmocněnce i zmocnitele). Všechny mandáty jsou pak spravovány v registru mandátů.

Závěrem lze říci, že vybrané země jsou v oblasti digitalizace velice vyspělé, nicméně v jejich případě nelze hovořit o federaci portálů, ale o centralizaci informací, dat a funkcí, které jsou uživatelům nabízeny prostřednictvím několika málo portálů.

V rámci posouzení stávajícího stavu bylo vybráno celkem 12 agendových, územních a soukromoprávních portálů a 2 portály centrální. Se zástupci portálových řešení byl stávající stav a vize federace diskutována na cílených schůzkách. Informace ze schůzek byly dále doplněny o informace sbírané formou dotazníkového šetření. Zjištěné rozdíly oproti vizi (cílovému stavu) jsou nezanedbatelné, stejně je tomu tak i při porovnání portálů mezi sebou. Vývoj portálů aktuálně není jednotně řízen, ani nepodléhá z pohledu nabízených funkcí obecným pravidlům, která by sjednocovala přístup k vývoji. Existence designsystem.gov.cz, který by toto měl napravit, není mezi všemi zástupci portálů dostatečně známá a bylo pozitivně vnímáno jeho připomenutí. S podobou a také nabídkou služeb také souvisí zaměření portálu, zda se jedná o centrální, agendový, územní anebo soukromoprávní. Zásadní rozdíly jsou v oblasti bezpečnosti, kde je v tuto chvíli citelný rozdíl mezi většími portály veřejné správy (např. ČSSZ, Moje Daně, PVS/PO), které jsou obvykle identifikovány jako významné informační systémy (a zákonné bezpečnostní požadavky stanovené ZKB a VoKB splňují), a portály územními či soukromoprávními (s výjimkou bankovních portálů), které takto silně právně regulovány nejsou. Územním či některým soukromoprávním portálům chybí především znalosti a možnosti pro vytvoření či nasmlouvání bezpečnostního týmu se znalostí problematiky bezpečnosti portálů. Zde by pomohla prakticky orientovaná metodika bezpečné tvorby portálových řešení, a především centrálně dostupný sdílený kód, který by obsahoval připravená řešení dílčích částí portálů.

Roadmapa popisuje seznam oblastí, které je nutné v rámci cesty k federaci portálů zohlednit a detailně se jimi zabývat, aby byl cíl federace naplněn. Cesta k federaci portálů by měla být primárně opřena o téma NIA. NIA zajistí uživatelům „bezešvý“ přechod mezi portály, bez nutnosti se na každém portálu, při přechodu mezi nimi, přihlašovat. Pro to, aby uživatel služeb VS dále mohl efektivně a s uživatelským komfortem konzumovat digitální služby je nutné zajistit sjednocení informační architektury napříč portály. To znamená primárně vzhled, interakci s jednotlivými prvky, nebo strukturu obsahu. To vše výrazně přispívá k příjemnému uživatelskému zážitku a k snadné, a především stejné orientaci. Dalším významným bodem na roadmapě je vytvoření a implementace elektronického mandátu (zastoupení), které je již dnes ve velmi omezené podobě dostupné na některých agendových portálech. Absence registru mandátů a absence jeho legislativního ukotvení představuje výraznou brzdu v rozvoji digitalizace služeb VS a většina zástupců dotazovaných portálů to potvrzovala. V neposlední řadě je potřeba zmínit, že situace kolem nemoci COVID ukázala, že je potřeba zdigitalizovat řadu agend VS a umožnit uživatelům vyřídit úkony jednoznačně také v digitálním prostoru (zmíněný elektronický mandát). Zde je nutné zmínit realizaci možnosti virtuálních schůzek, jako tomu již je v soukromém sektoru nebo jak se situaci rychle muselo přizpůsobit školství všech stupňů.

Řešení životních potřeb a životních událostí digitálními postupy má v různých oblastech občanského života v ČR rozdílnou úroveň, protože impulsy vytváření digitálních služeb a akcelerátory jejich rozvoje jsou zcela rozdílné. Například oblast osobního bankovnictví je dnes běžnou součástí každodenního života nejenom osob v produktivním věku, ale také studentů (pro žáky ZŠ mají bankovní domy již také produkty) a občanů důchodového věku. Počet osob, které své „denní transakce” zajišťují platebními metodami a přijímají nebo odesílají platby pouze bezhotovostně, z roku na rok narůstá, jakkoliv nutnost vlastnit bankovní účet není v ČR ze zákona povinná.

V ČR po roce 2000 a později vyrůstá generace velmi spojená s digitálním světem, ať již si o tom ze sociologického nebo psychologického hlediska myslíme cokoliv. Třicátníkům z roku 1990 dnes zbývá k dosažení důchodového věku jen několik málo let. Jejich celý produktivní věk běžel ruku v ruce s rozvojem počítačové gramotnosti a nástupem rozvoje digitálního věku. Lze se těžko vymlouvat na fakt, že občané důchodového věku nezvládnou další rozvoj digitalizace. Jejich děti a vnuci zajistí, pokud ne univerzita třetího věku, jejich potřebný rozhled.

Motivem bank, pojišťoven, e-shopů a jiných moderních služeb je samozřejmě ekonomický zisk. Přímý, např. z prodeje produktů – více, rychleji, snadněji atd., a „nepřímý“ v podobě např. snížených nákladů – nižší na počty obsluhujících pracovníků na pobočkách, v obchodech apod. Samozřejmě mohou zde být také další motivy, jako povědomí o značce zajišťující kontinuální ekonomické výhody.

Tržní prostředí udává směr digitalizace, jako první ukazuje nové možnosti, dříve těžko představitelné ¬– vezměme si takové robotické rozpoznání textů nebo umělou inteligencí zajištěný simultánní překlad mezi jazyky. Tržní prostředí jako první zajišťuje edukaci svých klientů. Kvalitními digitálními realizacemi je neustále zvyšováno především očekávání uživatelů (občanů) co se týká možností digitálních služeb.

Veřejná správa je nepochybně součástí občanského života, ale akcelerátorem jejího digitálního rozvoje nebude zisk, přestože otázka nákladů veřejné správy je samozřejmě vděčné a důležité téma politického života. Veřejná správa v mnoha oblastech nemůže být tahounem digitálního rozvoje a nelze poměřovat investice veřejné správy v této oblasti s byznys sférou. Na druhou stranu, veřejná správa má v rukou celou řadu jedinečných informací, procesů nebo zdrojů, které jsou nebo mohou být pro byznys sféru zajímavé, je-li možné je využít pro koncové uživatele.

Má veřejná správa více spolupracovat s byznys světem za účelem zlepšení vlastní digitální úrovně? Odpověď v roce 2021 zní jednoznačně ano.

Využijme jako příklad několik měsíců starou mediální kauzu ohledně rozhodnutí ČÚZK znemožnit využívání dat katastru nemovitostí formou scrapingu (robotického čtení webového obsahu přímo ze stránek). Snaha o potlačení takto využívaných digitálních služeb pochopitelně vyvolala negativní reakce provozovatelů těchto nestandardních řešení, jakkoliv si o jejich „byznyse“ můžeme myslet cokoliv. Negativní reakce jsme ale zaznamenali také u koncových uživatelů těchto služeb, u občanů nebo organizací, kteří logicky vítají každou možnost jak snadněji, rychleji nebo lépe prodat nemovitost, získat hypotéku apod¹⁾. Pro tyto subjekty se situace jevila jako změna k horšímu, nezávisle na tom, zda v právu je ČÚZK nebo zaběhnutý stav. To je potřeba si uvědomit.

Podívejme se na jiný příklad. Ať již na stránkách České agentury pro standardizaci nebo přes internetové vyhledávače, lze dohledat jakoukoliv českou normu. Její plné znění lze ale pořídit jen za finanční poplatek, např. po přihlášení na web ČAS.

Opět nehodnoťme, zda je správné zpoplatňovat normy nebo je široce poskytovat. Jde o to, že uživatelé jsou připravení pochopit, že také služby veřejné správy mohou být zpoplatněny nad rámec placení daní, tj. nad rámec vnímání, že již jsem si požadované digitální služby jako poplatník daně předplatil. Domníváme se, že kdyby ČÚZK podobným způsobem zpoplatnil služby, které jsou dnes dostupné „parazitujícím“ způsobem, nepředstavovalo by to pro mnohé uživatele (zde občany a organizace) žádným problém. Provozovatelé scrapingových služeb by patrně protestovali stejně, ale koncovým uživatelům, kteří za služby těmto provozovatelům stejně platí, by změna přístupu ČÚZK nepřišla nelegitimní. Postup veřejné správy s dodatečným příjmem za digitální služby by podle názoru autorů dokumentu byl uživateli přijat.

Strategie digitalizace veřejné správy je velmi dobře popsána v mnoha dokumentech, které jsou veřejně přístupné. Je za tím mnoho práce a mnohá „státní značka“ je již veřejně mnohem více vnímaná. Autoři tohoto dokumentu v těchto zdrojích načerpali nejednu důležitou informaci, ale také pro ně bylo mnoho informací zcela nových.

Problémem je, že občané tyto dokumenty dobrovolně nestudují. A pravděpodobně ani poté, co při hledání řešení svých životních potřeb, na ně narazí. Pokud se o digitalizaci státní správy dozvídají, pak jedině z médií, tj. když téma zaujme novinářskou obec. A nutno přiznat, že popularizátory veřejné správy především zaujmou situace, které zavánějí problémem, tedy nejde o popularizaci v pozitivním smyslu slova. Na média a správnou interpretaci základních informací se nelze příliš spoléhat a je nutné zvýšit míru přímé propagace digitalizace veřejné správy a jejího přínosu pro uživatele. Aktivní propagace digitalizace státu by měla náležet ke strategickým úkolům VS. Samozřejmě nejvíce pomůže, budou-li navrhované služby natolik intuitivní a snadno dohledatelné, že se budou samy o sobě snadno "prodávat”.

Bylo uvedeno shora, že zisk nebude hlavním akcelerátorem rozvoje digitalizace veřejné správy, ale naproti tomu na příkladech ČÚZK a ČAS věříme, že téma oprávněného příjmu za digitální služby může mít v digitalizaci veřejné správy své místo.

Jedním z motivů digitalizace v tržním prostředí může být zajištění povědomí o značce. Tento motiv může být vhodně uchopen právě veřejnou správou. Ze zahraničních zkušeností uvedených v tomto dokumentu vyčnívá zejména finský příklad „Suomi“ je prostě dobrá značka z mnoha zcela nedigitálních důvodů.

Portál veřejné správy, resp. Portál občana představuje správný počin veřejné správy a zvýšená akcelerace využívání digitálních služeb (těch, co již byly připraveny) způsobená pandemickým obdobím trvajícím bez mála dva roky na tom nic nesnižuje. Ze setkání s týmem rozvíjejícím PO nicméně jasně vyplynulo, že založení elektronické identity je pro mnohé z těch občanů, kteří zde posledních 30 let zažívali počítačový rozvoj, prostě složité a neintuitivní. Aditivní funkce, například kalendáře, jsou uživateli PO nevyužívány.

Základním bodem ve strategii digitalizace veřejné správy by měl být uživatelský výzkum, tj. kontinuální ověřování scénářů, které je potřeba řešit jako první. Mimo jiné se tím získá mnoho podporovatelů – účastníků výzkumů. Nicméně je potřeba zdůraznit, že jakmile za výzkumem vznikne velká časová mezera bez reálné implementace (nezáleží na důvodech), ze stejných podporovatelů se stane jedna velká skupina výrazných kritiků. Toto je zmíněným byznys světem experimentálně ověřeno mnoha nešťastnými příklady.

Dalším bodem by mělo být zaměření na životní události, které řeší opakovaně největší počet občanů. Zaměření se na vylepšení nebo vytvoření procesů s největším možným dopadem.

Ze zahraničních zkušeností je vidět téma daní. Tématem české veřejné správy mohou být např. daně z příjmů a s nimi spojené odvody do zdravotního a důchodového pojištění. Již dávno mělo být zajištěno, že podáním daňového elektronického formuláře se automaticky data dostanou jak ke zdravotním pojišťovnám, tak k příslušné OSSZ.

V této oblasti další kroky digitalizace nemají zlepšit situaci jenom tak, aby se občan lépe (digitální cestou) dozvěděl, kdy má které podání (a kde) uskutečnit. To je také samozřejmé. Ale má se zajistit, aby vůbec nebylo potřeba, že občan na nějaké další podání bude musel myslet. A už vůbec ne, aby ho musel realizovat třikrát s podobnými daty.

Při přípravě tohoto dokumentu se autoři setkali s hlavními agendami veřejné správy. Z těchto setkání na prvním místě vystupuje nejednotnost přístupů k digitalizaci a rozdílná úroveň digitální maturity. Autoři se přesto nedomnívají, že by bylo možné v roce 2021 v ČR nastavit směr patrný ze zahraničních řešení, který je převážně centralistický. Federace v nich prakticky (vyjma federace identit) nemá místo. Vše je budováno na jediném portále (z pohledu uživatele). S uvedeným příkladem webových řešení ČÚZK by to znamenalo například implementaci vyhledávání v katastrálních datech na Portálu občana nebo zcela identický designový a funkční „kabát“ portálu katastru nemovitostí zařazený pod doménu PO.

První možnost představuje riziko, že by se z PO stalo velmi úzké hrdlo. Druhá možnost nemá legislativní podklad. V nejbližší budoucnosti tak bude nejtěžší rozhodnout, které služby do PVS přidávat a které ponechat na úrovni jednotlivých agend, resp. jak služby rozdělit na federující a federované části.

Druhým fenoménem, který vyplynul ze setkání s hlavními agendami veřejné správy, byla na jedné straně samostatná snaha „něco dodat“ občanům podle nejlepšího vědomí a nečekat na impulsy odjinud (shora), ale na druhé straně obrovské očekávání, že odbor eGovernmentu Ministerstva vnitra (dále také jen eGov) vyřeší a přinese na podnose konečně některá zásadní řešení. Například registr mandátů neboli zmocnění, kompletní design systém veřejné správy, řešení správných jazykových mutací apod.

Nebylo to explicitně vysloveno, ale bylo ze všech pracovních setkání cítit, že strategie digitalizace potřebuje centrální místo s většími pravomocemi, než má dnes eGov, který spíše vytváří definiční prostor na obecné úrovni. Je-li eGov tímto centrem, měl by mít pravomoci dohlížet minimálně nad tím, zda se řeší v jednotlivých agendách digitální procesy v duchu popsaném v předchozí podkapitole. Měl by mít dohled a pravomoci nad rozhodnutími enterprise a možná také solution architektů jednotlivých agend. Měl by mít možnost držet na jednom místě přehled o „roadmapách“ rozvoje jednotlivých agend a pravomoc do těchto „roadmap“ vstupovat a rozhodovat o nich. Není tím myšleno, že eGov má rozhodovat o všech aspektech ISVS nebo portálů, které mu dnes kompetenčně nepodléhají, ale potřebuje mít kontrolu nad těmi oblastmi těchto ISVS a jiných portálů, kterými se budou k federaci portálů připojovat a bez kterých nelze federované propojení rozumně provozovat a spravovat. A to v mnoha případech může znamenat také jistý náhled do strategie jejich vzniku nebo rozvoje.

Jinými slovy, by mělo by vzniknout jedno místo (oddělení) řešící federaci portálů veřejné správy. Jak bylo uvedeno výše, bude zde souběh federující vrstvy (PVS) a federovaných částí, což je řešení složitější, protože není jednoznačné. Žádná ze zahraničních zkušeností nejde přesně takovým směrem. Důvodem, proč autoři tohoto dokumentu podporují tuto složitější cestu, je stav, kdy je hodně uděláno v jednotlivých agendách a není vhodné digitalizaci zpomalit. Je potřeba ale tento vývoj začít lépe a cíleně řídit.

Tato kapitola popisuje pojmy portál a informační systém v prostředí veřejné správy ČR, jejich členění a funkce, jež nabízí svým klientům.

Portál v širším slova smyslu je zástupným pojmem veřejné správy ČR pro samoobslužný a interaktivní digitální obslužný kanál veřejné správy, přesněji je to přístupové místo či brána k elektronickým službám orgánů veřejné moci, které lze čerpat samoobslužným a interaktivním způsobem.

Portál je tedy v prostředí veřejné správy vnímán jako funkční celek, který se skládá z front-end a back-end částí a který realizuje všechny typy služeb dle Informační koncepce ČR – informační, interaktivní, transakční a integrované. Zároveň portál VS je nepersistentní (portál VS je nepersistentní vůči datům agendových systémů, s výjimkou případů, kdy je portál sám agendovým systémem, má svou agendu jako PVS/PO), jediná data, která si obvykle uchovává, jsou uživatelský profil, kalendář, kontaktní údaje, nastavení notifikací a další údaje pro asistenční podporu uživatelů.

Typy služeb realizovaných jednotlivým portálem jsou:

• Informační služby – portál v této kategorii služeb poskytuje uživatelům dostupné informace, včetně přehledu životních událostí a příslušných služeb veřejné správy;
• Interakční služby – portál v této kategorii služeb poskytuje klientům individualizované informace (vždy pro konkrétního klienta) v dialogu (interakci) s živým (Chat) nebo umělým (Chatbot) partnerem, přičemž je využíváno více informačních kanálů, interakce v rámci jeho konání v prostředí portálu, a to včetně historie;
• Transakční služby – portál v této kategorii služeb umožňuje klientům realizovat digitální úkon nebo konzumovat tzv. digitální službu, tj. podání všech typů, provedení platby či rezervaci termínu schůzky, získání potvrzení (např. stavební povolení), v zatím ojedinělých případech doručení rozhodnutí úřadu;

U portálu se předpokládá, že bude podporovat co nejvíce tzv. integrovaných on-line (samoobslužných) služeb veřejné správy, propojujících všechny tři předchozí skupiny on-line služeb více úřadů dohromady na jednom místě, zakrývajících tak pro uživatele portálu skutečnou složitost a komplexnost výkonu působnosti veřejné moci v ČR.

Z výše uvedeného vyplývá, že pokud to vyžaduje charakter služeb OVM, pak jejich portály musí být integrovány s informačními systémy v úřadu, tedy nemohou to být samostatné a nepropojené aplikace. Portály musí být integrovány především s agendovými informačními systémy, se spisovou službou, ale také například s ekonomickými systémy, a to z důvodu, že tyto systémy shromažďují údaje o poplatcích či platbách/výplatách dle jednotlivých klientů. Portál by měl být konstruován tak, aby dokázal poskytovat všechny typy výše jmenovaných služeb – jedná se o tzv. integrované on-line služby veřejné správy dle Informační koncepce ČR²⁾. Přestože, že jsou tyto integrace jsou nezbytné pro komfortní výkon služeb, směřujících ke kvalitě dle ÚEP³⁾, je potřeba, aby základní funkce portálů pro klienty byly dostupné i bez integrace těchto řešení – například navigace Katalogem služeb a off-line formuláře ke stažení a odeslání dostupnými způsoby.

Taktéž platí, že všechny služby, navržené pro použití po autentizaci, musí být dostupné ve zjednodušené podobě a bez komfortu předvyplnění, historie nebo osobního prostoru i pro anonymní uživatele. A naopak, služby, které z podstaty jsou dosud anonymní a nevyžadují autentizaci, musí být možno užívat i autentizovaně, bez nucení uživatele, aby se odhlásil. Také k tomu míří dále uvedená federační pravidla.

V dřívější době bylo primární úlohou portálu poskytovat informace (informační služby), publikovat otevřená (veřejná) data, statistiky a jiné veřejné výstupy – to vše pro efektivní jednosměrnou komunikaci mezi úřadem a klientem. Dnes je nutné, aby portál sloužil jako prostředek pro interaktivní a právně účinnou komunikaci klientů s úřady, pro získání údajů pro držitele se zaručenou identitou, pro podání, týkající se splnění zákonné povinnosti klienta nebo jeho zákonných nároků (např. podání daňového tvrzení, oznámení, žádosti - např. žádosti o výpisy, žádosti o bezdlužnost, žádosti o dávky v hmotné nouzi apod.) či různé notifikace. Uživateli portál dále poskytuje funkci „profil“ (individualizovanou část), kde portál publikuje základní údaje o klientovi, které zná některý z úřadů a zejména umožňuje ukládat údaje, které klient chce s veřejnou správou sdílet sám ze své vůle nad rámec o něm vedených údajů, příp. obdobné údaje dalších klientů – subjektů práva, k nimž má uživatel portálu příslušná oprávnění.

K tomu, aby portály byly pro klienty, tedy občany a zástupce organizací, a pro úředníky uživatelsky přívětivé a umožňovaly efektivní konzumaci digitálního obsahu, je nutné sjednotit jejich chování a interakce. To pak umožní velmi plynulý přechod mezi jednotlivými portály bez narušení uživatelského zážitku. Tato oblast funkcí a projevů portálů se nazývá User Interface (UI) a User Experience⁴⁾ (UX) a spadá do ní způsob interakce, grafická podoba, struktura rozvržení informací a zodpovědností mezi portály (zamezení vzniku duplicity), kontaktní údaje pro komunikační kanály, jazyk (forma, odbornost apod.) či zcela bez výjimky jednotné, celostátní způsoby identifikace klientů (uživatelů).

Pouze v případě, že není možné použít pro elektronickou identifikaci a autentizaci prostředky Národního bodu pro identifikaci a autentizaci (zkráceně NIA⁵⁾), včetně její mezinárodní brány⁶⁾, může mít lokální portál, ve výjimečné situaci (zejména pro zahraniční osoby mimo EU), proprietární náhradu – nicméně taková skupina uživatelů není cílovou skupinou federace portálů, nedokáže totiž využít všech jejích výhod.

Portálová řešení v rámci veřejné správy jsou vedle centrálních univerzálních portálů rozlišována na portály agendové, uzemní a soukromé. Tyto portály poskytují služby klientům za jednotlivé ústřední správní úřady a úřady územní samosprávy, tj. kraje a obce nebo soukromé organizace, spolupracující s veřejnou správou.

Centrální univerzální portál – portál, jehož účelem je poskytovat navigační služby vedoucí k jednotlivým službám dílčích, lokálních portálů, a na druhou stranu poskytovat agregační, souhrnné služby, představující uživateli údaje z více lokálních portálů a z jejich agendových informačních systémů.

Agendový portál, portál úřadu ústřední státní správy (i pro více agend) – jedná se o specifický portál, který je využíván k samoobslužnému poskytování digitálních služeb a digitálních úkonů služeb jedné agendy nebo více agend jednoho ústředního správního úřadu (ÚSÚ).

Územní portál (portál územní samosprávy) – jedná se o portál poskytující služby, jež spadají pod určité území ČR – typicky kraj, obec, město či městská část – tedy samosprávy. Portál může obsahovat kromě samosprávních služeb (např. správa místních poplatků) také služby státní správy v přenesené působnosti.

Soukromý portál – jedná se o portál soukromoprávního uživatele údajů, tj. portál není vlastněn orgánem veřejné moci. Typicky se tak jedná o portály soukromých pojišťoven, bank, poskytovatelů zdravotních služeb apod.

Federované portály se pro účel tohoto dokumentu omezují na webové stránky, které mohou být zobrazeny v běžném webovém prohlížeči a které takto mohou být využívány i na přenosných zařízeních např. s využitím responsivního zobrazení. Není zatím uvažováno s nativními (mobilními) aplikacemi, které jsou připravované pro různé platformy individuálně. Technické i bezpečnostní důsledky by v případě jejich využití mohly být odlišné.

Při návrhu pravidel federované organizace portálů lze předpovědět vznik tzv. centrálně garantovaných komponent, bez jejichž použití si lze stěží představit zajištění a provozování funkcionalit, které musí být z pohledu uživatele a z podstaty fungování celé federované skupiny portálů jednoznačné, tj. neupravitelné žádným způsobem nebo jen na úrovni vzhledu na lokální (federované) úrovni. Za příklad, který bude rozpracován v dalším textu, uveďme například komponentu prezentující katalog služeb veřejné správy, komponentu zajišťující notifikaci uživatele, nebo komponentu kalendáře událostí a termínů, na kterých má uživatel nebo státní správa zájem (např. termín podání dotační žádosti).

Centrálně garantované komponenty portálových řešení budou k dispozici jako centrálních sdílené komponenty nebo jako centrálně dostupný sdílený kód. Druhá z variant může být využita k okamžitému použití nebo po vývojové úpravě na případném lokálním portálovém řešení. Obě varianty musí doprovázet podrobná aktuální dokumentace. Podstatný rozdíl mezi oběma formami bude mnohdy spočívat v tom, že centrální sdílená služba bude disponovat i centrálním perzistentním registrem, kdežto distribuované uzavřené komponenty i sdílené zdrojové kódy budou vhodné jako součásti pro lokální řešení, propojené s centrálními funkcemi a daty.

Podstatný rozdíl mezi různými formami využití centrálně garantovaných komponent spočívá pro správce portálu také v jejich různém způsobu uplatnění ve veřejných zakázkách na portál a v různém financování jejich vývoje a provozu. Přitom centrální komponenty musí být neutrální vůči technologiím a frameworkům.

Centrálně garantované komponenty v obou formách, musí mít implementovány velmi detailní monitoring provozu a dostatečně dimenzované oddělení podpory pro odpovídání dotazů uživatelům, a též pracovníkům federovaných portálů, na něž se jejich uživatelé budou také zcela jistě obracet s dotazy. Při implementaci služby centrální garantované komponenty nelze lokálně zaručit správnou funkcionalitu v daný okamžik. Při implementaci centrálně dostupného sdíleného kódu může být situace komplikovanější. Také centrálně dostupný sdílený kód může mít centrálně implementován monitoring, ale vzhledem k možnosti kód upravovat lokálním vývojovým týmem je nutné detailní monitoring provozu zajistit především ve federovaném portále a případnému centru (autorovi otevřeného kódu) předávat detailní výstupy z něj. Může také existovat varianta centrálně dostupného sdíleného kódu, který není otevřený, a jehož úpravy nebudou žádoucí nebo budou zakázané. Takové řešení se zajišťuje vhodnou licenční politikou, která samozřejmě nezakazuje uživateli sdíleného

kódu aplikaci úprav, ale varuje ho, že tak např. činí na vlastní odpovědnost. Pro přiblížení, ve veřejné správě hojně využívaný portálový framework Liferay disponuje přesně podobnými principy – je možné upravovat funkcionality portálu pomocí tzv. hooks a extensions, přičemž druhé z nich jsou v Liferay na vlastní nebezpečí. Praxe ukáže různorodost všech možností a dle toho bude potřeba přizpůsobit podmínky provozu a umístění týmů podpory.

Celkově ovšem maximalizace řešení pomocí centrálně garantovaných komponent, zejména centrálních sdílených komponent, je stále efektivnější, jelikož eliminuje vytváření rozsáhlých oddělení podpory pro každý portál a pro implementaci podobných řešení vícenásobně.

Základem strategické vize obsluhy klientů VS ČR je, že klient si může volit, ve kterém z kanálů bude aktuální službu konzumovat nebo činit úkon. Jednotlivé obslužné kanály si nemusí být funkčně rovny ze 100 %, ale ve většině případů budou služby dostupné ve více než jednom obslužném kanálu, a musí v nich být tedy řešitelné obdobně a s jistotou vést ke stejnému výsledku.

Aby byly tyto kanály efektivní a aby byly pro klienta opravdovou podporou, musí v nich být stejné informace, stejné podpůrné funkce a kanály musí být vzájemně propojené, aby o sobě takříkajíc „věděly“. Pak je možné naplnit i strategické požadavky toho typu, že historie ze všech kanálů je dostupná v každém z nich kompletně nebo že práci na podání započatou v jednom kanálu (třeba samoobslužném) může klient dokončit v jiném (třeba v asistovaném).

Mají-li obslužné kanály takto klientům sloužit, směřují k tomu, že budou:

sdílet „Jednotnou informační, znalostní a funkční základnu“, tedy za front-endy obslužných kanálů bude back-end tzv. omnichannelu obslužných kanálů, něco jako kombinace řešení typu CRM (Citizen

Relationship Management) a KM (Knowledge Management)

ústřední komunikační kanály: samoobslužný (Portál veřejné správy) a asistované kanály (prezenční – KMVS Czech POINT a budoucí hlasový – CallCentrum) budou každý federujícím kanálem, tj.

federace portálů je předmětem tohoto materiálu; síť kontaktních míst má svoji centrálu a bude řešit svůj vztah k lokálním přepážkám agendových a územních úřadů; centrální Call-centrum musí být virtuálně rozšířeno (federováno, distribuováno) s lokálními call-centry alespoň nejvýznamnějších resortů.

Podstatné ale je říct, že centrální sdílené komponenty, identifikované v tomto materiálu jako významné pro fungování federace portálů (Katalogy služeb, událostí a rolí, Vyhledávač, Notifikační centrum, Registr zmocnění, Kalendáře, Pohledávky, Sdílené prostory a úložiště a další) musí být navrhovány a konstruovány tak, aby nesloužily výhradně jenom portálům ve federaci, ale aby vždy mohly nabídnout své funkce, služby a obsah i ostatním obslužným kanálům, na kterékoli úrovni jejich federace.

Jinými slovy řečeno, všechny takové centrální sdílené komponenty mohou prvotně vzniknout v kterémkoli kanálu (aktuálně v PVS/PO nebo v Czech POINTu), ale vždy budou přirozeně nedílnou součástí „Jednotné informační, znalostní a funkční základny“, byť taková ještě jako právní pojem neexistuje a nikdo za ni jako celek nemá zodpovědnost.

Prvním a důležitým příkladem SW produktu, vytvořeného jako vedlejší efekt tvorby centrální sdílené komponenty, v tomto případě Portálu občana, a určené ke znovupoužití v lokálních řešeních, je tzv. „Design Systém Gov.cz“⁸⁾. Jedná se jednotnou metodiku UI/UX, v pozdějších verzích produktu doprovázenou sadou prostředků, knihoven a on-line nástrojů.

Dalším příkladem centrálně dostupného sdíleného obsahu je přenositelný a okamžitě použitelný katalog služeb veřejné správy. Tento sdílený obsah je použitelný jak kompletně s design částí, tak pouze jako platný strukturovaný seznam služeb.

Předpokládáme, že v souvislosti s dalším rozvojem funkcí federujících portálů nebo záměrně přímo jako vzory a akcelerátory vývoje portálů federovaných budou vznikat další SW produkty, identifikované v této studii.

S rozvojem centrálních sdílených SW řešení bude nutné zpropagovat existenci úložiště zdrojových kódů – otevřená verze GitHub na Gov.cz již existuje. K úložišti se vážou pravidla přístupu a procesy umožňující předkládat požadavky na vylepšení komponenty nebo dokonce aktivní zapojení do jejího rozvoje.

Uložiště zdrojových kódů je dostupné všem potenciálním federovaným portálům a široké veřejnosti v případě open source řešení

Jsou definováni vlastníci jednotlivých řešení, a tedy

Technický důsledek platných sdílených zdrojových kódů. Jsou definovány procesy zpracování podnětů změn/rozšíření/oprav řešení a/nebo procesy řízení změn v rámci fungování úložiště

Zodpovědnost za kvalitu a bezpečnost, příjem

Právní důsledek hlášení chyb a navržených oprav.

Předpokládá se vznik dalších pravidel, která nyní nejsou známa, jakmile se začne s tvorbou dalších částí otevřeného kódu.

Tato kapitola popisuje a shrnuje klíčové oblasti právní úpravy, u nichž lze mít za to, že budou v souvislosti s realizací federace portálů (přímo) dotčeny. Za účelem přehlednosti jsou pak tyto oblasti shrnuty postupně, a to od obecné právní úpravy k té konkrétní.

S ohledem na skutečnost, že federace portálů má být sjednocujícím uživatelským prostředím, jehož realizace spadá do oblasti digitalizace služeb státu a mj. usnadňuje přístup občanů k OVM, lze za jeden z klíčových dokumentů s dopadem na realizaci zamýšleného projektu považovat Informační koncepci ČR ve smyslu usnesení vlády č. 644 ze dne 15. června 2020. Ta, na základě zmocnění dle ZISVS, stanovuje vůči povinným subjektům nejen požadavky na jejich rozvoj, ale rovněž i obecné cíle České republiky v oblasti eGovernmentu a jeho podpory, obecné architektonické principy pro návrh a rozvoj, jakož i řízení útvarů informatiky a životního cyklu příslušných ISVS.

Informační koncepce ČR tak klade na federaci portálů poměrně širokou škálu obecných požadavků, od požadavků na jednotnost přístupu k digitálním službám (viz princip P8-Jeden stát a dílčí cíl 1.3), přes napojení jednotlivých služeb na příslušné agendy a procesy (dílčí cíl 1.4), dále přes komplexní stanovení příslušných rolí (s ohledem na zodpovědnost za služby OVM, cíl 1.6), až po digitalizaci a archivaci digitálního obsahu (cíle 3.2 a 3.3). Bližší podrobnosti poté upravují Národní architektonický plán⁹⁾ a Národní architektonický rámec¹⁰⁾, které tvoří přílohu Informační koncepce ČR. V důsledku tak bude během realizace federace portálů rovněž nezbytné zohlednit navazující dokumenty (tj. jejich dopad na realizaci federace portálů), a to například Metody řízení ICT veřejné správy ČR, které stanovují specifická pravidla pro postupy a plán realizace ICT projektů. Formální zakotvení předmětných předpokladů je rovněž předmětem vyhlášky č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy), ve znění pozdějších předpisů. Aktuálně se připravuje pasivní derogace této právní normy zcela novou vyhláškou.

Jedním ze základních pilířů právní úpravy v oblasti digitalizace služeb státu je zákon č. 12/2020 Sb., o právu na digitální služby, ve znění pozdějších předpisů ZPDS, který stanovuje jak právo občanů na digitální služby (resp. činit digitální úkony), tak i podmínky jejich realizace ze strany OVM. ZPDS upravuje rovněž právo na využívání údajů OVM ze základních registrů nebo AIS, které jsou danému OVM pro výkon dané agendy zpřístupněné. S ohledem na povahu digitálních služeb a digitálních úkonů nelze vyloučit ani souvislost s úpravou zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů obsaženou ve správním řádu.

Klíčovou otázkou pro federaci portálů bude rovněž otázka doručování – s ohledem na platnou a účinnou právní úpravu je v tomto ohledu významná zejména úprava datových schránek obsažena v zákoně č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů ZoEÚ. Ve vztahu zejména k audiovizuálním souborům doručovaným nejen uživateli je pak třeba mít na paměti limitace právní (i technické povahy), např. maximální velikost datové zprávy zaslané prostřednictvím datové schránky je (50 MB).

Na základě ZPDS musí být uživateli služby umožněno provést svou identifikaci a autentizaci prostředkem pro elektronickou identifikaci podle své volby nejméně v úrovni značná (není-li zákonem stanoveno výslovně jinak). Do budoucna rovněž bude třeba splňovat požadavky zákona č. 261/2021, kterým se mění některé zákony v souvislosti s další elektronizací postupů orgánů veřejné moci DEPO a umožnit na žádost uživatele služby, který provedl autentizaci, vystavení potvrzení o autentizaci.

V rámci federace portálů bude třeba vyhovět požadavkům kladeným na elektronickou identifikaci, které stanovuje zákon č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů ZoEI, zejména poté určuje konkrétní národní prostředky elektronické identifikace a způsob jejich využívání (včetně vazby na využívání údajů z ISVS). Počítáno by mělo být rovněž s přístupem se zaručenou identitou ve smyslu § 2 ZISVS na základě zvláštního právního předpisu pro příslušnou státní agendu.

Ve vztahu k uživatelům služeb VS dále upozorňujeme, že vůči veřejnoprávní entitě ve smyslu § 5 zákona č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů ZSVD, jenž je implementací Nařízení EU č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES, jde-li o jednání související s její (veřejnoprávní, vrchnostenskou) působností, platí, že je vždy třeba vyšší míry záruky autenticity (podpisu) elektronického dokumentu (podání), kterou dle § 6 odst. 1 ZSVD splňuje pouze uznávaný elektronický podpis.

Ve vztahu k dokumentům, jejichž původcem je orgán veřejné moci, je poté třeba mít na paměti další povinnosti dle ZSVD, tj. elektronický dokument je možné podepsat pouze kvalifikovaným elektronickým podpisem, resp. opatřit kvalifikovanou elektronickou pečetí (nestanoví-li právní předpis jako náležitost úkonu nebo právního jednání obsaženého v dokumentu podpis nebo tato náležitost nevyplývá z povahy úkonu nebo právního jednání), a kvalifikovaným elektronickým časovým razítkem.

Závěrem dodáváme, že případný obousměrný bezešvý (Single Sign-on) přístup je možný pouze v případě, že federující i federovaný portál jsou kvalifikovanými poskytovateli služeb dle ZoEI.

ZISVS poté jednoznačně definuje tzv. informační systémy veřejné správy jako „funkční celky nebo jeho části zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy“, z čehož je zřejmé, že federace portálů bude přinejmenším z části (ve vztahu k portálům OVM) tuto definici samostatně naplňovat; jednotlivé federované portály poté v jednotlivých případech budou rovněž portály veřejné správy ve smyslu tohoto posledně uvedeného zákona.

Federace portálů v tomto ohledu musí zajistit (zejména, bude-li tyto činnosti zajišťovat) soulad s technickými požadavky v oblasti vydávání výpisů a ověřených výstupů z ISVS ve smyslu § 9 odst. 1 písm. b) ZPDS (např. na základě prostředku pro elektronickou identifikaci), především pak, že budou splněny povinnosti ověřujícího

(zajištění integrity výstupu). Pro úplnost dodáváme, že otázku rozsahu a evidence ISVS upravuje vyhláška č. 329/2020 Sb., o seznamu položek popisu informačního systému veřejné správy, ve znění pozdějších předpisů, přičemž tato stanovuje relevantní obsahové podmínky (včetně uvedení informací o zpracování osobních údajů v ISVS).

Nové požadavky klade na provozovatele ISVS rovněž DEPO, například v oblasti postupu při likvidaci kopií dat a provozních údajů daného ISVS.

Ze strany provozovatelů federovaných portálů je třeba dále splnit zákonné povinnosti (dodržet postupy) ve vztahu ke zveřejňovaným informacím na portálech a umožnit plnění příslušných funkcí (například komunikace prostřednictvím datových schránek) v souladu s § 6g ZISVS.

Provozovatelé federovaných portálů jsou rovněž povinni zajistit, že portál bude obsahovat veškeré legislativou stanovené povinné informace s vazbou na příslušný portál veřejné správy (v obecné rovině nicméně povinný subjekt bude muset dostát vždy přinejmenším požadavkům vyhlášky č. 515/2020 Sb., o struktuře informací zveřejňovaných o povinném subjektu a o osnově popisu úkonů vykonávaných v rámci agendy, ve znění pozdějších předpisů, a zveřejnit informace ve smyslu § 5 a § 5a zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů).

Vzhledem ke skutečnosti, jak federující portál, tak mnohé federované portály jsou povinnými subjekty ve smyslu

§ 3 zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně 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ů, ve znění pozdějších předpisů („ZoPISMA“), bude třeba zajistit naplnění povinností dle ZoPISMA, zejména požadavků na přístupnost (včetně zveřejnění prohlášení o přístupnosti), srozumitelnost a stabilitu.

Ve vztahu ke konkrétním portálům mohou být tyto obecné informační povinnosti dále konkretizovány, typicky se tyto povinnosti budou týkat portálů samosprávy (obcí), a to v oblasti zákona č. 183/2006 Sb., o územním plánování a stavebním řádu (stavební zákon)¹¹⁾, ve znění pozdějších předpisů (územně plánovací dokumentace); zákona č. 255/2012 Sb., o kontrole (kontrolní řád), ve znění pozdějších předpisů (výsledky kontrol); či Nařízení

EU 2016/679, o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (pro oblast ochrany osobních údajů, „GDPR“). V souvislosti s ochrannou osobních údajů je třeba uvést, že v případě personalizace výsledků a obsahu na portálech pro jednotlivé uživatele bude třeba zajistit soulad s požadavky předpisů na poli ochrany osobních údajů, včetně vhodného nastavení cookies policy (mj. povinnost informovat uživatele o typech portály využívaných cookies).

Co se týká portálů, která nespadají pod veřejnou správu, mohou se v individuálních případech i portálů zřizovaných těmito subjekty týkat speciální legislativní povinnosti ke zveřejnění informací (např. informace o činnosti pojišťoven dle § 82 zákona č. 277/2009 Sb., o pojišťovnictví, ve znění pozdějších předpisů).

Nad rámec výše uvedeného je poté třeba mít na paměti specifika platné a účinné zákonné úpravy v souvislosti s Portálem veřejné správy a Portálem občana, které jsou oproti ostatním portálům veřejné správy konkretizovány.

Portál veřejné správy a Portál občana (jako součást Portálu veřejné správy) tak musí v souladu s § 6g ZISVS zajišťovat přístup k informacím získaným na základě informační činnosti OVM, komunikaci s OVM prostřednictvím datových schránek, přístupu se zaručenou identitou do ISVS nebo elektronických aplikací spravovaných těmito OVM (případně prostřednictvím kontaktních míst veřejné správy). Dále musí zajišťovat přístup k informacím od jiných soukromých FO a PO, zejména poté k formulářům v elektronické podobě. Za zveřejnění informací soukromých subjektů v PVS může být vyžadována úplata. FO poté musí umožnit zápis dokladu, průkazu, osvědčení a dalších veřejných listin za účelem zasílání informací o končící platnosti takové veřejné listiny.

Referenční rozhraní veřejné správy, jakožto jednotné integrační prostředí informačních systémů veřejné správy je definováno v § 2 písm. i) ZISVS, ale pro potřeby jeho využívání je potřeba využívat práva a plnit povinnosti dle ZoZR. Jedná se především o možnosti využití systémů Informačního systému základních registrů (ISZR) a Informačního systému sdílené služby (ISSS), které svými službami poskytují údaje základních registrů, editorů základních registrů a ostatních agendových informačních systémů.

Portál samotný, který musí být ze své podstaty informačním systémem veřejné správy, může využívat služeb ISZR a ISSS následujícími způsoby:

1. Být přímo připojen na ISZR a ISSS, jako agendový informační systém, který přímo vyřizuje agendové služby
2. Komunikovat s AIS úřadu, který plní jednu nebo více agend s je připojen na ISZR a ISSS

Každý portál si musí být schopen pro potřeby plnění agendové služby veškerá dostupná data, která jsou pro subjekt vyřizující služby potřebná. Není preference mezi způsoby uvedenými výše.

Aktuální struktura portálů v rámci veřejné správy již je architekty eGovernmentu stavěna do hierarchické podoby, kdy zastřešujícím portálem je Portál veřejné správy (PVS), jako jediný původní nositel webové prezentace kompletního Katalogu služeb veřejné správy a kompletních popisů úkonů služeb veřejné správy.

Spuštění Portálu občana (PO) jako první instance transakční (autentizované) části Portálu veřejné správy (PVS) umocňuje oprávněný dojem, že jediným místem sdružujícím všechny digitální služby bude právě PVS, viz také princip P8 IKČR Informační koncepce ČR. P8 – jeden stát. Nahrává tomu fakt, že PO je postupně vybavován dalšími možnostmi a funkcemi, které jsou buď z podstaty centralizované (výstupy z registrů) nebo jde o agendy, jejichž služby jsou atraktivní a klienty žádané, ale které jejich příslušné úřady dosud nedokázaly implementovat ve vlastních řešeních, na něž by mohl PVS/PO odkázat. Není pochyb o tom, že PVS zvládne implementovat i složitější služby agendových nebo územních portálů nebo veřejnoprávních institucí (zdravotní pojišťovny, zdravotnická zařízení, školy apod.), ale není to žádoucí.

Cílem architektury portálů je, aby své služby v samoobslužném digitálním kanále (portálu, webovém aplikačním serveru) implementoval každý příslušný úřad a aby tyto jednotlivé služby byly dostupné odkazem z centrálního Katalogu služeb v PVS. Vedle toho si Portál občana a případně další specifické transakční části PVS ponechají pouze své přirozené (nativní) služby, které jiný portál v takové podobě poskytovat nemůže, typicky centrální navigační služby (katalog), centrální agregační služby (kalendář, seznam dokladů nebo seznam pohledávek) a centrální asistenční/personalizační služby (profil zmocnění apod.)

Do Portálu občana jsou odkazem v podobě dlaždice postupně připojovány některé agendové portály (ústřední správní úřady), územní portály (kraje, obce) a soukromé portály (školy, zdravotnická zařízení, …). Tento způsob propojování bude dále již utlumován, cílem je propojovat portály bezešvě, na úrovni informací a služeb, což ale do zavedení Katalogu služeb nebylo možné.

Portál Pražana, který je prezentován v roli digitálního úřadu pro občany hlavního města, podporuje jak služby samosprávy, tak služby státní správy v přenesené působnosti. Ty druhé nyní často volá do vlastních lokálních agendových systémů. Cílově bude i Praha pro agendy v přenesené působnosti využívat jejich celostátní řešení, spravovaná ohlašovateli agend, a Portál Pražana bude muset být redesignován do podoby čistého územního portálu.

Čistě centralistický přístup by bylo vhodné použít, pokud by u velkých agend státní správy neexistovaly již dnes provozované webové portály, ale pouze primární systémy patřičných agend (AIS). V takovém momentu by mělo smysl uvažovat o centralizaci služeb do jednoho místa – výstavbě jednoho portálu, resp. možná vícero portálů, které se pro uživatele jeví jako jeden. V takovém momentu by mělo smysl se tím zabývat z hlediska legislativy na prvním místě. Tomuto přístupu se některé zde popisované zahraniční zkušenosti velmi blíží.

Výchozí stav digitalizace služeb státní správy v ČR je jiný. Existují zde řešení, která jsou relativně daleko, současně s těmi, které mohou být zcela na startu. Absence některých centrálních prvků digitalizace způsobila, že mnohé z portálů a AIS, které jsou v digitální strategii dále než ostatní, byly nuceny vyřešit si některé podstatné prvky digitálních služeb lokálně v souladu se svými agendami. Bohužel a logicky často pouze v souladu s nimi bez možnosti zobecněného použití v jiných agendách. Jako příklad uveďme mandáty – registry plných mocí (digitálních), systémy notifikující uživatele nebo umožňující digitální podání bez ověřeného digitálního podpisu nebo datové schránky.

Obrázek 1: Aktuální hierarchie portálů VS

Právě pro tento stav je vhodné propojovat již provozované a teprve budované portály federativním způsobem na jedné úrovni s nadstavbou ve formě PVS jako centrálně známého bodu. Nadstavba má v tomto uspořádání z hlediska pohledu uživatele nadřízenou roli a struktura vypadá dvojúrovňová. Můžeme se na to ale podívat také tak, že PVS má roli odlišnou. PVS může využívat data z federovaných portálů, nejčastěji v agregované podobě, ale nemůže data nabízet, protože nevládne perzistencí dat, vyjma dat týkajících se profilu uživatele a jiných výjimek, plynoucích pro PVS ze zákona. Na druhou stranu se stává místem zastřešujícím některé centrální komponenty, které federované portály musí (některé mohou) implementovat ve shodě s PVS.

Máme zde tak plochou strukturu všech federovaných portálů a k nim jeden zastřešující federující portál, který bude federovat odkazy na služby, data a informace z agendových portálů, územních a soukromoprávních portálů. Samozřejmě, jak již bylo připomenuto, ne všechny. Jak je naznačeno na obrázku níže, federované portály (agendové, územní a soukromé), které jsou na stejné úrovni, se mohou navzájem federovat a díky tomu je umožněno řešit pro uživatele celou řadu požadavků a zajistit bezešvě přecházení mezi dílčími portály. V rámci kapitoly zabývající se federovanými portály v zahraniční zkoumáme přístup Norska, které využívá právě této ploché struktury portálů, kterou vnímáme jako přehlednější pro uživatele, ale také z pohledu údržby jako snadněji udržovatelnou.

Přestože je hierarchie federace portálů primárně navrhována jako plochá, dvoustupňová, mohou se stejná pravidla s výhodou uplatnit i na více úrovních. Například mohou vznikat portály ministerstev, které budou prezentovat digitální služby všech jejich organizačních složek státu (OSS) a dalších zřizovaných organizací jednotným způsobem (viz probíhající snahy MPSV a dalších), přestože tyto budou mít i nadále své lokální weby s digitálními službami. Takové portály ministerstev budou potom v některých aspektech portály federovanými, současně v jiných aspektech portály federujícími, poskytujícími agregační služby za svůj rezort.

PVS by měl být jak pro přihlášené, tak i nepřihlášené uživatele, přičemž pro přihlášeného uživatele by následně mělo dojít k personalizaci (k omezení rozsahu nabídky informací a služeb, případně přizpůsobení vzhledu a chování portálu) na základě volby uživatele pro typ právní subjektivity, kterou chce užít (fyzická osoba nebo organizace), respektive pro tomu odpovídající jednu z předdefinovaných souhrnných (zastřešujících) rolí subjektu práva a jim odpovídajících sekcí portálu, tj. zejména Portál Občana a Portál Podnikatele. Ty si můžeme představit jako „záložky“ na PVS, které taktéž obsahují filtry nad Katalogem služeb a dalším digitálním obsahem. Jinými slovy PVS bude pro nepřihlášeného uživatele zobrazovat veškeré dostupné informace, které budou rozděleny na ty, které jsou podnikatele či občana. V momentě přihlášení jsou osobní údaje doplněny o preference a dojde tak k zafiltrování veškerého obsahu.

Obrázek 2: Budoucí možná hierarchie portálů VS

Vedle povinné vertikální spolupráce federovaných a federujících portálů je samozřejmě přípustná i jejich dobrovolná horizontální spolupráce na bázi centrální znalostí a sdílených komponent, která ale není předmětem identifikace pravidel v tomto materiálu.

Všechny portály ve federaci, tj. federující i federované, musí být na sobě vzájemně nezávislé v meritu svých služeb. Tj. každý portál sám o sobě musí fungovat a poskytovat alespoň v základní podobě služby, pro něž je vytvořen, i když ostatní portály ve federaci, k jejichž službám je připojen, budou mimo provoz.

V užším slova smyslu to znamená, že všechny federované portály musí být konstruovány tak, aby mohly elektronické formy služeb veřejné správy poskytovat autonomně i při výpadku provozu Portálu veřejné správy, nebo jiného federujícího portálu.

Obráceně to znamená, že federující portál bude dále fungovat, i když některé jeho odkazy do dílčích portálů nebudou funkční. Poskytne o tom konkrétní a jednotné chybové hlášení a nabídne náhradní scénář vyřízení služby, tj. místo interaktivní služby nabídne odkaz na neinteraktivní vyplnění formuláře nebo prezenční návštěvu úřadu a zaregistruje požadavek a notifikuje uživatele, že služba je on-line, až tato on-line bude.

Dále to znamená obecně, že federující i federované portály musí dál (izolovaně) fungovat i při výpadku jiných centrálních sdílených služeb, včetně služby elektronické identifikace. A to pouze se ztrátou komfortu pro uživatele, směřující od podpory “úplného elektronického podání“ (ÚEP) k podpoře pouze obyčejného elektronického podání (EP), nebo dokonce k pouhé podpoře formulářů pro tradiční podání (P).

Praktické dopady jsou například takové, že katalogová část portálu nesmí být rozdělena na anonymní informační a autentizovanou transakční část. Katalog služeb musí být nedílnou součástí a středobodem každého portálu (eShopu se službami úřadu nebo celé VS) a musí být implementován tak, aby byl dostatečně funkční jak anonymně (v základní funkci aplikace, bez předvyplnění a podání “do portálu”), nebo autentizovaně (v komfortní funkčnosti, s předvyplněním, historií, osobními prostory a podáním do portálu nebo do integrované DS).

Pro návrh konstrukce lokálních, federovaných portálů z toho dále vyplývá ke zvážení, zda by neměly být ochráněny i před výpadkem centrálního API s Katalogem služeb VS tím, že budou mít svoji vlastní část Katalogu služeb synchronizovanou do vlastní DB nebo “kešovanou”.

Kapitola popisuje oblasti funkcí, na které je potřeba se při realizaci federace zaměřit. Tyto oblasti jsou určující pro zajištění vnímání ze strany uživatele, že:

• federovaná struktura funguje na stejných, minimálně velmi podobných principech,
• orientace ve struktuře je na různých místech podobná, ideálně shodná,
• rozličný vzhled portálů nezpůsobuje ztrátu orientace uživatele,
• názvosloví je ujednoceno do maximální míry.

Vyjmenované atributy napomáhají zvyšovat povědomí, že oblast služeb státní správy a samospráv je zvládnutelná pro, jakkoliv zkušeného uživatele a digitální přístup bez například nutnosti fyzické návštěvy úřadu je reálně možný. Federaci neubírá na úspěšnosti postupná aplikace jednotlivých zde popsaných oblastí nebo jejich funkcí na již běžící a rozvíjející se portály. Postupné připojování portálů do struktury se dá využít také k postupnému rozšiřování vzdělanosti uživatelů v možnostech digitálních služeb veřejné správy. Uživatelé ve většině případů chápou, že digitalizace se nestane najednou, na všech místech současně. Očekávají ale, že nebude působit roztříštěně.

Příklady z oblasti finančního sektoru a pojišťovnictví ukazují, že sjednocování přístupu má smysl a zákazníka si nelze získat ojedinělou, ale v praxi nepoužitelnou funkcionalitou nebo chováním. Většina aplikací tzv. mobilního bankovnictví se proto dnes liší pouze ve specifických funkcionalitách nebo rozsahu jejich nabídky, ale nikoliv v základních funkcích. Stejné je tomu u samoobslužných portálů například cestovního pojištění. Jde o zjednodušující příklady, ale díky nim velká část uživatelů služeb VS – občanů ČR má o těchto jednotných principech již vytvořenu představu a očekává standardní chování.

Jak bylo zmíněno v předchozí kapitole, vrstva federovaných portálů je převážně plochá. Na stejné úrovni se nacházejí odlišně složitá (z hlediska agendy, nabídky služeb a množství informací) řešení portálů nebo jiná webová řešení. Pro hlavní agendové portály veřejné správy jsou funkce popisované v jednotlivých oblastech prakticky povinné. Samozřejmě mohou existovat výjimky. Pro portály měst a obcí, mohou být vhodné nebo minimálně výhodné.

Na oblasti funkcí se lze zaměřit z hlediska technologického, bezpečnostního, procesního, legislativního, personálního apod. Ne u všech je potřeba řešit všechna hlediska. Popis také neobsahuje všechny oblasti, ale pouze ty podstatné, které je potřeba rozpracovat jako první. Ať již proto, že jsou složité, nebo proto, že je uživatelé již v jiných částech digitálního prostoru ve svých životních rolích a situacích aktivně používají, například viz zmíněné osobní bankovnictví. Některé oblasti k řešení se mohou vyjevit při práci s tímto dokumentem nebo jako iniciativy zapojujících se federovaných portálů.

Z pracovních setkání s velkými agendovými řešeními vyčnívalo silné držení se litery zákona, což je samozřejmě správné, ale omezuje to výrazně imaginace o dalších možných realizacích nových funkčností portálů pro koncového uživatele. Možná až příliš striktně rigidně se přemýšlí nad tím, co je a není možné realizovat jako službu, jak v režimu veřejného náhledu, tak v režimu autentizovaném. Například objednání na konkrétní čas je služba, která autentizaci z podstaty nevyžaduje, to ale nevylučuje, aby mohla být nabízena uživateli, který se autentizoval. Naopak, tato funkce se nemá po autentizaci uživatele vytratit z nabídky jeho možností.

Definice vyhledávání informací

Vyhledávání představuje jednu z nejsložitějších oblastí v rámci řešení federace portálů. V podstatě nejde o vyhledávání ve smyslu toho slova, ale o řízené nabízení relevantních výsledků. Standardní vyhledávání uživateli nabízí základní nebo rozsáhlejší možnosti vyhledávacího nástroje (příkazu) a uživatel je plně odpovědný za použití parametrů vyhledávání tak, aby se dobral nejlepšího výsledku.

Takto vyhledávače dnes již nepracují. Množina informací roste exponenciálně, proto si vyhledávače vypomáhají řadou dalších parametrů, o nichž uživatel nemusí mít tušení nebo minimálně v čase vyhledávání o nich nemusí přemýšlet. Jde například o geografickou polohu, data z marketingových cookies, které klient v různém časovém okamžiku potvrdil, dále jde o souhlasy, které konkrétnímu vyhledávači a konkrétním stránkám, na kterých se pohyboval, udělil. Vyhledávače samozřejmě upřednostňují na předních místech placené reklamní pozice, a to v případě federace portálů může představovat také použitelný případ – zdůraznění například zásadní informace nebo její změny, události, která si zaslouží být na prvním místě vyhledávání nad nějakou konkrétní oblastí zájmu.

Uživatel o těchto aspektech nepřemýšlí, ale očekává nalezení nejvíce relevantní informace, jakkoliv mohl zapsat formulovat velmi vágní zadání. Vedle těchto představitelných parametrů se stále více do vyhledávání zapojují samoučící se algoritmy, které mohou napomáhat vylepšování vyhledávání “za běhu” extrémně rychlým zpracování dat a okamžitou změnou parametrů v reakci na aktuální chování uživatelů. Možnosti umělé inteligence budou hrát ve vyhledávání v blízké budoucnosti stále větší roli.

Vyhledávání představuje funkci zásadně ovlivňující uživatelský zážitek. V rámci vyhledávání informací je žádoucí nabízet funkci našeptávání, která se musí rychlostí reakce blížit reálnému času. Není-li tomu tak, uživatelova důvěra ve věrohodnost vyhledávání prudce klesá a zážitek se stává negativním.

Anonymním uživatelům bude vyhledávač nabízet pouze výsledky tvořené výhradně veřejnými informacemi. V dalším kroku rozvoje svých funkcí bude vyhledavač poskytovat autentizovaným uživatelům i informace z údajů a dokumentů v jejich osobních prostorech, ke kterým jsou oprávněni přistupovat svým jménem a s nimi konat na vlastní účet. V cílovém stavu by měl vyhledávač spolupracovat i s tzv. „Mandátním registrem“ (viz kapitola Užívání portálů v zastoupení) a autentizovaným uživatelům zastupujícím při dotazování prokazatelně jiný subjekt práva (jednajícím cizím jménem na cizí účet) nabídnout i výsledky vyhledávání, k nimž je uživatel aktuálně oprávněn.

U výsledků vyhledávání se očekává, že nebude uživateli předkládat jen odkazy na příslušné stránky federovaných a federujících portálů, ale také konkrétní dokumenty, výsledky vyhledávání z často kladených dotazů apod.

Uživatel očekává moderní fungování vyhledávání, protože je zvyklý pracovat například s vyhledávačem Google a vyhledat prakticky jakoukoliv informaci přes celosvětově propojený web. To samozřejmě klade na realizaci vyhledávání mezi federovanými portály náročné požadavky.

Při popisu a realizaci oblasti vyhledávání je potřebné oddělit:

• vyhledávání a indexaci veřejných informací. Tedy strukturu portálů, poskytované služby, návody, šablony atd.;
• vyhledávání klientských dat z portálových, agendových a různých informačních zdrojů.

Zatímco implementace veřejné části vyhledávání je relativně jednoduchá a vice méně pouze technická, prohledávání klientských dat musí řešit zabezpečení přístupu, musí řešit obecný problém koncentrace dat na jednom místě (v indexu), což je v přímém rozporu s trendem oddělováním agendových dat a držením minimální množiny dat na jednom místě.

Centrální řízení vyhledávání informací

Pro federaci portálů představují tato očekávání především rozšíření vyhledávání o dnes nedostatečně zajištěné nebo neřešené oblasti.

Centrálně řízené vyhledávání sebou přináší celou sadu nových procesů a požadavků, které je zapotřebí odbavovat v rozumném čase, aby vyhledávání poskytovalo skutečnou přidanou hodnotu pro uživatele portálu. Pro funkční vyhledávání je zapotřebí udržovat a vyhodnocovat vyhledávané výrazy, měřit úspěšnost nabídnutých výsledků (např. jejich prokliky), budovat a udržovat slovník synonym atd. Jedná se o komplexní sadu znalostí a dovedností, které takto vybudovaný systém bude vyžadovat na denní bázi. Pro jejich zajištění je zcela nezbytné institucionálně zabezpečit kompetentní tým, který dále musí rozvíjet a optimalizovat vlastní technické řešení a dohlížet na jeho kompatibilitu s ostatními federujícími stranami.

Není ekonomicky výhodné budovat takovéto týmy pro jednotlivé portály, ale vybudovat jeden tým, který bude schopný podporovat potřeby jednotlivých portálů. Proto musí na prvním místě vzniknout oddělení zodpovědné za vyhledávání v prostoru federovaných portálů. Toto oddělení musí mít pravomoci řídit funkce vyhledávání přes celou oblast federujících a federovaných portálů. Musí mít finanční, technické a lidské zdroje pro zajištění tohoto rozsáhlého úkolu. Bude-li vyhledávání fungovat pro uživatele očekávatelně přes celou federovanou množinu, nebude potřeba (a snaha) na úrovni federovaných portálů řešit vyhledávání (obecných informací) separátně, nebo jenom v minimální očekávatelné míře. Pro zajištění správného fungování vyhledávání je nutné ustanovení sjednocujícího centra.

Na úrovni federovaných portálů, především těch se specifickou agendou, musí také vznikat samostatná oddělení starající se výhradně o problematiku uspořádání a vyhledávání informací. Podle pravidel a pokynů z centrální úrovně budou tato oddělení připravovat sady (stromy) stránek, sady dokumentů a jiných informačních zdrojů

(schémat, obrázků, mediálních dat) k zařazení do vyhledávací množiny. Vedle toho budou jistě řešit a řídit parametry vyhledávání vlastních agend, například v autentizovaných sekcích agendového portálu, k čemuž by mohla a měla využit shodné softwarové nástroje a procesy.

Podle pravidel z centrální úrovně budou připravovat množiny klíčových slov a zpracovávat zpětnou vazbu (výsledky) z vyhledávání zaměřeného na jejich oblast (agendu). Vyhledávání představuje nikdy nekončící proces zpětné vazby – vylepšování funkcionality vyhledávání pomocí aplikace výsledků z předchozích vyhledávání. A především z těch, které nevedly k nalezení očekávaného výsledku.

Vyhledávání informací pomocí komerčních internetových vyhledávačů

Uživatelé začínají proces vyhledání informací nejčastěji ve vyhledávači Google (případně v jiném, v ČR například Seznam.cz) a očekávají, že také zde naleznou odpovědi na své dotazy týkající se obecně státní správy. V tomto bodě je nutné zdůraznit ještě jeden důležitý aspekt, že při vyhledávání informací v internetovém vyhledávači se uživatel vůbec nemusí orientovat v oblastech státní správy a legislativně-procesním pojmosloví státního aparátu. Přesto jeho očekávání je, že veškeré potřebné informace nalezne. Chování uživatelů v tomto nelze změnit, takové očekávání a investice do změny chování by nebyly smysluplné. Je potřeba federované a federující portály přizpůsobit podmínkám vně této skupiny řešení a připravit data a procesy tak, aby vyhledávání pro uživatele fungovalo principiálně stejně. Také nelze srovnávat technologické možnosti státní správy a společnosti jako Google.

Aby mohlo být „globální“ vyhledávání spolehlivě zajištěno, musí se z jednoho místa řídit zveřejňování (a nezveřejňování) informací, které mají být dohledatelné internetovými vyhledávači. V podmínkách ČR na druhém místě především vyhledávačem Seznam, který například pracuje s odlišnými pravidly zobrazování relevantních výsledků – nutno zdůraznit, že internetové vyhledávače většinu pravidel utajují a odborná veřejnost se pravidla snaží uhodnout na základě chování a speciálního testování.

Indexace veřejně dostupných dat, právě proto, že budou pocházet z mnoha portálů a současně budou mít celou řadu průniků, musí být řízena z jednoho centra a jednotně definovaným přístupem. V opačném případě výsledky vyhledávání veřejných informací nebudou funkční a nebudou uživateli kladně přijímané.

Centrálního oddělení musí umět řešit otázky technologické povahy a pomáhat federovaným portálům (minimálně konzultačně) s technickými aspekty vystavování stránek. Vyhledávače penalizují stránky, jejichž rychlost a další dílčí vlastnosti (velikost stahovaných součástí: javascript; styl; html; komprese dat; využívání mezipaměti apod.) nesplňují vyhledávači očekávané parametry. Jsou penalizovány stránky, které nepoužívají šifrováním zabezpečený https protokol, obsahují odkazy na stránky, které ho nepoužívají, libovolně přepínají mezi stránkami, které jej používají a nepoužívají apod.

Veřejné vyhledávače jsou anonymní, a proto musejí dostávat a dodávat pouze informace pro anonymního uživatele nebo anonymizované (agregátní) údaje.

Problematika optimalizace SEO¹²⁾, která je popsaná v samostatné kapitole, patří jako další důležitá oblast na úroveň centrálního řízení. Jde o zachycení změn týkajících se těchto parametrů na straně vyhledávačů a ve vztahu k vyhledávání a s tím související vydávání informací a pokynů ke správné implementaci těchto parametrů u jednotlivých federovaných portálů. Celé propojené řešení v oblasti vyhledávání musí fungovat jako jeden portál.

Centrální správa HTTPS certifikátů jednotlivých portálů

V souvislosti s výše uvedenou problematikou penalizací vyhledávání ze strany vyhledávače Google těch webových řešení, které nevyužívají zabezpečený protokol https, může být další oblastí k řešení z centrálního místa jednotný přístup k využívání certifikátů od certifikačních autorit uznávaných výrobci internetových prohlížečů. S důrazem na posledně uvedené, situace ve státní správě v oblasti používání ověřených certifikátů se velmi zlepšila. Stále se ve veřejném prostoru nachází řada veřejnoprávních organizací (vnímaných uživateli jako součást státní správy), které pro své webové portály používají nesprávné certifikáty nebo dokonce nepoužívají žádné. Jde často například o veřejné školy. V čase přípravy tohoto dokumentu například webový portál Státního úřadu inspekce práce uvedený v seznamu hlavních organizací (webových portálů) Ministerstva práce a sociálních věcí a uvedený přímo na hlavní stránce webu mpsv.cz nemá žádný certifikát. To v roce 2021 nepůsobí profesionálně a v kontextu nalezení relevantních výsledků to bude vyhledávačem Google penalizováno.

Otázka řízení politiky certifikátů z jednoho centra může představovat příliš úzké hrdlo vzhledem k počtu webových řešení, které by musela podporovat. Nicméně tato služba může být prakticky plně automatizována (jako e-shop portál pro státní správu; s minimálním požadavkem na lidské zdroje) některým z poskytovatelů těchto služeb a z pohledu nákladového pro státní správu jednoznačně výhodná.

Technické aspekty vyhledávání informací

Federativní vyhledávání má zajistit uživatelům portálů dohledatelnost informace napříč jednotlivými portály a přecházení mezi nimi. Je to mimochodem i jeden z cílů Informační koncepce ČR. Tento princip vyžaduje integraci více datových zdrojů federovaných portálů do jednoho vyhledávacího rozhraní – centrální řízení sady vyhledávacích komponent. Integrace datových zdrojů zajistí uživatelům dohledat informace napříč jednotlivými portály a přecházet mezi nimi. Federované portály musí vedle vlastních struktur implementovat centrálně definovanou strukturu informací. Federující portály implementují do centrální struktury indexu data všech federovaných portálů. Pro integrované informace musí být definována jednoznačná množina metadat, která musí být implementována všemi portály.

Federované portály budou vytvářet lokální vyhledávací funkce ve svých agendách, pokud nebudou mít jinou alternativu, která by jim usnadnila řešení tohoto obsáhlého úkolu, jak bylo v několika bodech popsáno. Nabídne-

li centrální oddělení lokálním portálům platformu vyhledávání k využití jako službu (PaaS), federované portály ji zcela jistě využijí. Implementace správného a uživateli očekávatelného řešení vyhledávání je natolik komplexní a nákladná investice s dlouhodobým procesem správy, že využití rozsáhlé agendy a know-how centrálního řešení se pro takové sdílení přímo nabízí. Rozsáhlá investice státní správy by se vrátila v podobě jednotného způsobu vyhledávání informací a pozitivního vnímáni uživateli služeb na kterémkoliv portále ve federované soustavě. Největší část investice centrálního řešení se bude nacházet především v oblasti know-how a lidských zdrojů. Technologické zdroje budou tím nejmenším problémem a též nejméně nákladným prvkem zajištění vhodného vyhledávání informací.

Definice centrálně řízeného indexování vyhledávaných dat představuje funkci zásadně ovlivňující uživatelský zážitek. V rámci vyhledávání informací je žádoucí nabízet funkci našeptávání, která může generovat další požadavky na definice indexovaných dat pouze pro tuto funkci.

V případě vyhledávání informací na federujícím portálu, může funkcionalita uživateli snižovat nebo rozšiřovat množinu výsledků podle dalších relevantních proměnných a agend jednotlivých federovaných portálů. Například může být podstatná geografická poloha uživatele. Uživatel může specifikovat oblast hledání výběrem zájmových oblastí nebo také typem portálového řešení (agendový, územní nebo soukromoprávní portál). Naopak, i z dílčího portálu má po zavolání centrální služby možnost prohledávat „celý“ web a hledat tak v informacích, které jsou na ostatních federovaných portálech. V opačném případě, pokud uživatel bude vyhledávat na federovaném portále, výsledky mohou být relevantní pouze pro dílčí portál. Nebudou-li na dílčím portálu dostupné žádné výsledky, případně potencionální výsledky budou na jiném federovaném portále, bude žádoucí se uživatele dotázat, zda si přeje rozšířit oblast vyhledávání na další portály. V případě souhlasu bude přesměrován na federující portál, který relevantní množinu výsledků zobrazí.

Množina výsledků je uživateli prezentována jak ve formě konkrétních odkazů na aktuality, články či části jiných portálů, tak ale i ve formě kategorizovaných výsledků. Kategorizované výsledky představují výsledky dle skupiny životních událostí či životních rolí s konkrétním odkazem na službu v katalogu služeb.

Funkce nabídne uživateli portálu veřejně dostupné výsledky. Pokud je uživatel, tedy klient nebo zástupce klienta, autentizován, množina výsledků je rozšířena o ty, které jsou přístupné pouze přihlášeným uživatelům a o ty, které jsou přístupné pouze jemu vlastním jménem. Po převzetí role zastupovaného subjektu i jeho výsledky.

Funkcionalita bude využívat jednotného indexu, který bude automaticky škálován v závislosti na přibývajících položkách do indexu (cílem je indexovat pouze některé agendy či výsledky, nikoliv vše). Odkazování na cílový portál je realizováno, bez rozdílu, zda se jedná o federovaný či federující portál, tzv. deeplinkem, včetně přenosu identity.

Optimalizace pro vyhledávače (SEO)

Problematika SEO (Search Engine Optimization, česky Optimalizace pro vyhledávače) představuje v současnosti samostatnou disciplínu, která je v rámci příprav a následné internetové propagaci ve vyhledávačích důležitá součást vývoje webových řešení. Potřeba implementace v rámci procesu(ů) a vynaložení potřebného úsilí je zejména tam, kde chceme ve výsledcích vyhledávání dosáhnout organické dosažitelnosti správných informací o konkrétním webovém řešení. Pojem organická dosažitelnost zde znamená zjednodušeně bez dodatečných kroků, například bez dodatečné (placené) reklamy. Zjednodušeně, je-li potřebné řešit, které informace webového řešení a jakým způsobem mají být dohledatelné pomocí internetového vyhledávače, a které informace naopak dohledatelné být nemají, potom je důležité se SEO intenzivně věnovat.

Kde naopak optimalizace SEO smysl nedává, jsou typicky řešení, u kterých nemáme obsah, očekáváme malou nebo žádnou hledanost, jedná se o silně zavedenou značku nebo tam, kde jsou očekávatelné komplikace spojené s technickou realizací či časovými nebo finančním prostředky. Například webový portál Vlády české republiky může zjednodušeně představovat řešení, která bez zásadně propracovaného SEO mohou fungovat ve vyhledávačích správně. Důvodem bude odkazování se všech například mediálních webů na tento primární portál. Vyhledávače tímto množstvím odkazů (citací apod.) pochopí, že cokoliv týkající se vlády patří k tomuto portálu.

Mezi základní cíle SEO může patřit: zvýšení relevantní návštěvnosti, dosažení nízké okamžité míry opouštění stránky (tzn. bounce rate), konverze, posílení značky (brand) a reputace u vyhledávačů (SERM). Při plánování SEO pro konkrétní řešení musí být zodpovězeny otázky: přínosu, nákladů ve vztahu k přínosům, termíny a realizačního tým. SEO zahrnuje obecné principy, viz. další text o obsahovém a technickém SEO, které lze aplikovat na všechny řešení, ale také individuální přístup poplatný konkrétnímu webovému řešení.

Procesně je potřeba k SEO přistoupit jako ke strategii s následnou implementací a vyhodnocením. Pro získání požadovaných výsledků je třeba strategii kontinuálně ověřovat, korigovat a vylepšovat. Je důležité vzít v úvahu SEO expertízu již ve chvíli, kdy se připravuje nový produkt, resp. webové řešení s úmyslem vyhledávání jeho informací pomocí internetových vyhledávačů a připravit si odpovědi na otázky, jaké kategorie dat budeme chtít zpracovat, jaké filtrování, jakou navigaci, jaký typ obsahu obsah (jaké odkazy a kam, jaké obrázky a zda dohledatelné, jak rozsáhlé a detailní texty apod).

SEO optimalizaci lze rozdělit do dvou znalostních rovin:

• Obsahové SEO – Cílem obsahové a marketingové optimalizace pro vyhledávače je, aby webové řešení používalo ta klíčová slova, která používají a vyhledávají na internetu uživatelé. Do této optimalizace náleží zamyšlení nad realizací překladů mezi jazykem úředního světa a jazykem uživatelů. Analýzou klíčových slov se ověří, která slova uživatelé vyhledávají a tato slova je poté zapotřebí využívat při tvorbě obsahu.

Obsahové SEO klade na federující a federované portály úkol využívat vedle sebe oba zmíněné jazyky.

Realizace tohoto nemusí být snadná.

• Technické SEO – Pro zajištění základní kvality a korektní dostupnosti obsahových informací společně s ohledem na přístupnost, strukturovanost a srozumitelnost informací pro vyhledávače je potřeba řešit SEO také na technické úrovni webového řešení. Oblasti, kterým se v rámci technického SEO je potřeba věnovat jsou rozsáhlé a dohledatelné v odborné literatuře. Pro ilustraci několik příkladů k řešení: metadata, kanonická URL, pokyny pro roboty vyhledávačů (robots.txt), předložení struktury informací vyhledávačům (sitemap(s).xml) apod.

Vyhledávání dat vyžadujících autentizaci

Na základě diskusí, při setkáních s velkými agendovými portály, a z komentářů k textu dokumentu v průběhu jeho tvorby se ukázala malá představivost ohledně fungování vyhledávání v režimu autentizovaného uživatele, resp. nad jeho privátními daty. To je samozřejmě možné již dnes technologicky zajistit, aby se centrálně nebo lokálně indexovaly (průběžně) data z privátních částí uživatelů. Z hlediska bezpečnosti lze zajistit, že v indexu existují jen odkazy na privátní data, nikoliv data samotná.

Ilustrativním příkladem může být vyhledávání ČSN. Jak na webu ČAS, tak pomocí internetového vyhledávače lze pomocí i neúplného řetězce klíčových slov nalézt požadovanou normu, ale nikoliv její celé znění. To se získá až po uhrazení platby. Příklad ilustruje práci s indexem tak, aby stěžejní informace nebyla veřejně dostupná. Jak bylo navíc uvedeno, agendové portály mohou mít důvod používání lokálního indexu vyhledávání.

Druhý často skloňovaný problém při diskuzích o vyhledávání byl výkon, resp. rychlost. Jde o zbytečnou obavu. Současný technologický svět se rozvíjí směrem k asynchronnímu zpracování dat s ohromným výkonem. Existují již dnes řešení schopná zpracovávat 1mil zpráv za sekundu. Obavy o rychlost zpracování nejsou na místě.

Obrázek 3: Schéma centrálního vyhledávání na federujícím portálu

Jde o legislativně-procesní pravidlo, jehož technické důsledky spočívají ve vybavenosti oddělení

(složeného pravděpodobně z několika pododdělení)

Technický důsledek

patřičným know-how, procesy, pravomocemi a na neposledním místě sw nástroji pro zabezpečení všech vyjmenovaných bodů.

Bude třeba určení bezpečnostních rolí předvídaných

Právní důsledek VoKB, tj. zejména role manažera a architekta

kybernetické bezpečnosti

Vytvoření škálovatelných technických a procesních podmínek pro zajištění služeb vyhledávání pro libovolný počet federujících portálů, které projeví zájem o využití služby (PaaS).

Technický důsledek Vytvoření (využití) technologické platformy zajišťující

federovaným portálům jednotné hledání přes kompletní oblast VS a speciálních agend státní správy, ale také pro zajištění vyhledávání vlastních agend.

Přestože ve vztahu k OVM zakládá § 7 ZPDS oprávnění k čerpání údajů ze základních registrů a AIS, a mělo by tak být možné takové čerpání a vyhledávání v údajích hypoteticky uskutečnit, ve vztahu k federovaným portálům a pro případné mimo-agendové služby bude nadále třeba pro

Právní důsledek

umožnění takového využívání údajů a vyhledávání souhlas uživatele služby (či jiný zákonný důvod). U vyhledávání z pozice federovaných portálů na portálu federujícím bude třeba zajistit kontrolu oprávnění a rolí tak, aby nedocházelo k neoprávněnému přístupu (blíže viz § 12 VoKB).

Technický důsledek Definice struktury centrálně řízeného indexu

Výše uvedené je třeba provést tak, aby bylo zejména zajištěno řízení přístupu dle § 12 VoKB a přijmout opatření, která budou bránit zneužití údajů neoprávněnou osobou.

Využívání údajů ze základních registrů je možné pouze v případě, že příslušný OVM je oprávněn tyto

Právní důsledek

údaje využívat dle ZoZR nebo podle jiných právních předpisů. Pro úplnost upozorňujeme, že soukromoprávní užívání údajů je možné výhradně na základě zákonného zmocnění (prostřednictvím AIS či jiného informačního systému¹³⁾), které takové oprávnění údaje užívat založí.

Centrální (federační) tým vytváří technologické a procesní podmínky pro zajištění kontinuální aktualizace indexů daty federovaných portálů – spravuje seznam dostupných portálů s jejich popisem např. příslušnost k agendě. Dohlíží (a edukuje) v otázce důležitost updatování indexů ihned po vzniku nových dat v prostoru federovaného

Technický důsledek

portálu. Odpovídá za to, že existuje definice všech informačních překryvů (průniků) mezi agendami a že jsou vytvořeny (a federovaným známy) definiční matice umístění (dohledatelnosti) primárních dat. Centrální tým se stává rozhodčím ve sporech o definici primárního umístění dané informace u těchto průnikových procesů.

Současná právní úprava (ZoZR) předpokládá, že k synchronizaci dat mezi ISVS, základními registry a AIS dochází výlučně prostřednictvím referenčního, sdíleného a bezpečného rozhraní (eGSB/ISSS) – viz § 5 odst. 2 písm. d) ZISVS.

Právní důsledek Je třeba dále zajistit rovněž soulad např. s § 5 odst. 6

ZISVS, tedy veškerá činnost federujícího portálů nesmí ohrozit činnost zpravodajských služeb (dotazy s vazbou na evidenční chráněné údaje v režimu zákona č. 153/1994 Sb., o zpravodajských službách České republiky, ve znění pozdějších předpisů).

Federující portál je informován federovanými portály ohledně jejich obsahu, a to formou například statistikou výrazů, metadaty apod.

Ve vztahu k seznamu federovaných portálů bude vhodné vycházet zejména z údajů vedených dle vyhlášky č. 329/2020 Sb., o seznamu položek popisu

Právní důsledek

informačního systému veřejné správy, ve znění pozdějších předpisů, a rovněž zohlednit zápisy agend v katalogu služeb.

Definice pravidel pro prezentaci výsledku. Portál, v němž byla zavolána centrální dotazovací komponenta jako služba, obdrží výsledky na vyhledávací dotaz od jednotlivých federovaných portálů, musí pomocí této centrální komponenty umět seřadit výsledky do jednoho seznamu, který bude zobrazovat uživateli portálu.

Z předpokladu velkého množství federovaných portálů, a tím i velkého množství výsledků, musí být uživateli umožněno filtrovat si výsledky dle kategorií, štítků nebo portálů, které vrací výsledek.

Katalog služeb veřejné správy a příslušných úkonů

Jednotlivá portálová řešení jednotným způsobem zobrazují data z centrálního Katalogu služeb veřejné správy, to znamená, že je nevytvářejí, ale přebírají z federujícího portálu. Katalog služeb VS je na jednotlivých portálech reprezentován oblastmi, které obsahují služby a jejich úkony, které jsou v detailu popsány, viz portal.gov.cz.

Strukturování Katalogu služeb pro jeho prezentaci se ještě bude vyvíjet. Vedle zařazení služeb do kategorií, viz Obrázek 4, budou ještě služby klasifikovány pomocí životních událostí a rolí, aby i podle nich mohly být uspořádání pro prezentaci v portálu. Všechny tyto formy prezentace federované portály přebírají.

Obrázek 4: Příklad členění služeb veřejné správy na PVS

Každý místní (agendový, územní nebo soukromý), federovaný portál může zobrazovat pouze vybranou podmnožinu (relevantních) služeb, které je připraven nabídnout uživateli. Vedle toho nabídne uživateli i možnost prokliku na kompletní katalog služeb VS, který je na PVS. Každý federovaný portál musí prezentovat vybranou podmnožinu služeb jednotně, tak jak je tomu na PVS – toto souvisí s plynulým přechodem mezi portály a zachováním příjemného uživatelského zážitku, viz kapitola Informační architektura.

Úplný katalog služeb VS je (povinně) prezentován pouze na PVS. Ostatní dílčí, federované portály jej mohou prezentovat – je dostupný skrze API – ale také nemusí. Povinně na něj musí mít odkaz.

Pro všechny portály je k dispozici komponenta pro

Technický důsledek čtení a zobrazení katalogu služeb.

Při dodržení pravidel přístupu skrze eGSB/ISSS bez

Právní důsledek dalších právních důsledků.

Lokální služby popsané a dostupné v RPP mají příznak na odlišení od celostátních. Cílem je sjednotit strukturu a dohledatelnost služeb.

Komponenta na procházení služeb je k dispozici k volnému použití a disponuje volně dostupnou dokumentací, jak ji implementovat.

Pro zobrazení a interakce s katalogem služeb

Pravidlo využívají standardizovanou komponentu z Design

systému.

Technický důsledek Portály implementují volně dostupnou komponentu.

Právní důsledek Bez právních důsledků.

Vedle výše uvedeného jsou správci lokálních federovaných portálů oprávněni vybudovat a publikovat lokální katalog služeb vlastními prostředky, musí však být datově a uživatelsky kompatibilní s celostátním Katalogem služeb VS. Služby z obou katalogů je v lokálních portálech možno prezentovat odděleně nebo společně na jedné stránce, pak ale lokální služby musí být viditelně označeny/odlišeny.

Katalog životních rolí

Jedná se o role subjektu práva (fyzických osob a organizací), tj. každému subjektu práva náleží množina tzv. životních rolí, z nichž mnohé jsou relevantní i pro jeho vztah k veřejné správě, projevující se v užívání služeb veřejné správy. Svým životem, svou životní situací, vytvořenou řadou předchozích životních událostí, je subjekt práva disponován k působení v řadě rolí (občan, student, rodič, podnikatel, řidič, zaměstnanec, zaměstnavatel, pacient apod.). Principy zapojení subjektu do služeb VS předpokládají, že typicky na sebe subjekt pro jednotlivou interakci s veřejnou správou bere právě jednu z rolí, k nimž je svým životem disponován. V tomto okamžiku působení v roli říkáme také, že jde o roli výkonnou, tj. roli, v níž se vykonává interakce s veřejnou správou, ale je to přívlastek pomocný – podstatná je povaha role a podstata role jako takové. Vybrané role lze využít i pro zúžení množiny zastupovaných subjektů práva (jednatel, rodič, opatrovník apod.), jako tzv. role pro zastupování.

V cílovém stavu role jsou/mají být centrálně spravované v Katalogu životních rolí. Portál PVS, respektive AIS Katalogový je poskytuje/má poskytovat prostřednictvím API, stejně jako je tomu v případě katalogu služeb VS z RPP, viz kapitola Katalog služeb veřejné správy a příslušných úkonů, a jsou jednotně prezentovány a využívány na všech federovaných portálech.

Každý federovaný portál může (smí), v kontextu personalizace obsahu a nabízených funkcí, využívat pouze vybranou podmnožinu (relevantních) rolí, pro které je připraven nabídnout uživateli vlastní služby (na daném portálu). Vedle toho nabídne uživateli i možnost prokliku na kompletní katalog rolí, který je publikován na Portálu veřejné správy, a díky tomu také přístup ke všem službám. K jednotlivým životním událostem mohou být navázány služby napříč VS – federované portály prezentují vždy ty životní události, které obsahují alespoň jednu službu (kterou lze realizovat v daném portálu) a zobrazují tedy i příslušné role.

Úplný katalog rolí je (povinně) prezentován pouze na Portálu veřejné správy. Ostatní dílčí, federované portály jej mohou prezentovat – je dostupný skrze API, ale také nemusí.

Některé role jsou relevantní pro všechny subjekty práva, tj. fyzické osoby i organizace (např. podnikatel, likvidátor, opatrovník, zaměstnavatel, vlastník vozidla), jiné pak jen pro jednu ze skupin subjektů práva (např. role rodič či zaměstnanec jsou přípustné pouze pro fyzické osoby). Životní role lze pak využít pro různé účely zúžení nějaké množiny informací – zafiltrování digitálního obsahu, případně služeb, které se k dané životní roli váží.

Další možností je využití vybraných rolí pro rozčlenění obsahu portálů do sekcí, které by mohly mít odlišný obsah, vzhled a chování portálů (UI/UX), např. sekce “Občan” zahrnující informace a služby z pohledu nepodnikající fyzické osoby, nebo sekce “Podnikatel” zahrnující informace a služby z pohledu podnikající fyzické osoby a organizací (podnikajících i nepodnikajících). Některé informace a služby přitom mohou být relevantní pro obě sekce.

Systemizace rolí pro jednotlivé účely je velká úloha a je nezbytné ji vzít vážně, strukturovaně, průběžně ji řešit, a hlavně ji institucionálně podpořit adekvátním týmem kvalifikovaných odborníků.

Příklady životních rolí, které mohou být výkonnými rolemi pro VS, by měly být předmětem diskuzí, jelikož se jedná o oblast, která zasahuje nejen do personalizace digitálního obsahu, ale také do oblasti zastupování. Obdobně jako u služeb je i u rolí třeba zvážit, zda bude federovaným portálů povoleno přidávat na své stránky další (místní) role, typicky spojované výhradně s místními životními událostmi a místními službami.

Životní události (příp. typové životní situace) a příslušné služby VS

Stejně jako v případě katalogu služeb (viz kapitola Katalog služeb veřejné správy a příslušných úkonů) se i životní události zobrazují jednotně na příslušných portálech s tím, že další životní události, ověřeně odlišné od těch celostátních, mohou být vytvářeny dílčími portály dle předem definované struktury. Vzniká tak strukturovaný Katalog životních událostí, který je centralizovaný a je provázaný s Katalogem služeb (viz Katalog služeb veřejné správy a příslušných úkonů) a uživatel má možnost vyhledávat služby dle životních událostí.

Lokální portály a jejich správci obsahu mohou požadovat identifikaci a užívání dvou kategorií nových životních událostí subjektů práva (fyzických osob nebo organizací), respektive jejich typových životních situací, které nenalezli ve státním katalogu, a to:

• událostí, které mají obecnou platnost v životě subjektů práva a jsou relevantní pro služby více agend nebo více územních samospráv nebo více soukromých subjektů. Takové mají mít celostátní platnost a musí se prostřednictvím posouzení redakční radou či centrálním útvarem správce katalogu stát jeho součástí,
• událostí, které jsou zcela unikátní pro místo nebo soukromý subjekt, případně agendu, a nikdy se nesmí stát součástí státního katalogu. Takové události bude mít federovaný portál povinnost zasílat správci katalogu pro informaci, aby tento mohl posoudit a) unikátnost/duplicitu vůči centrálním událostem a

b) potenciál pro zařazení události jako centrální (např. při častém výskytu).

Uživatel federovaného i federujícího portálu má tak možnost vyhledávat služby VS dle životních událostí – federovaný portál zobrazuje vždy pouze ty životní události, které obsahují alespoň jednu službu, kterou lze v daném portálu realizovat, zároveň jsou uživateli zobrazeny všechny relevantní služby s prokliky do daných portálů. V případě federujícího portálu je uživateli k dispozici množina všech takových životních událostí. Federované portály mohou prezentovat pouze podmnožinu služeb relevantních pro daný portál, případně dle místní příslušnosti (nicméně klientovi jsou zobrazeny i služby, které nejsou daným portálem poskytovány – jsou jednoznačně odděleny). Zároveň musí poskytovat možnost prokliku na úplný katalog životních událostí, který je dostupný na portal.gov.cz.

Dosavadní přístup Portálu veřejné správy k životním událostem je výběrový, což odpovídá rozsahu projektu, v rámci, něhož vznikají k vybraným událostem tzv. „Průvodci“, viz Obrázek 5. To se musí změnit a musí vzniknout Katalog životních událostí (a k nim Katalog typových životních situací) pro klasifikaci služeb z Katalogu služeb VS, i takových událostí, které nemají a v dohledné době nebudou mít plnohodnotného Průvodce.

Obrázek 5: Příklad životních událostí z portálu PVS

Pro dlouhodobě udržitelné a správně řízené lokální životní události je vhodné, aby vzniklo centrální místo včetně metodiky, kde budou tyto události udržovány. Tím lze zabezpečit jednotnou formu a místo odkud budou životní události spravovány. Z absolvovaných diskuzí a workshopů se zástupci MV ČR, NAKIT atp., vyplývá, že by měly všechny portály využívat RPP (Katalog služeb) a Katalog životních událostí (předpokládáme, že bude součástí AIS katalogů). V případě, že se požadovaná životní událost v Katalogu životních událostí nenachází, je možné, aby si lokální portál vydefinoval vlastní lokální životní události, které jsou relevantní pouze pro daný portál, ale výhradně ve spolupráci s centrálním koordinátorem. Jinak by provozovatel federovaného portálu porušil podmínky federace. Lokální životní události mohou být publikovány do zvláštní části Katalogu služeb, stejně jako lokální služby (AIS katalogů), pokud k tomu bude k dispozici.

Životními událostmi se klienti dostávají do individuálních životních situací nebo životních období, ovlivněných i celou řadou předchozích událostí v jejich životě. Pro veřejnou správu není proveditelné připravit, spravovat a nabízet služby pro každou individuální životní situaci, protože je jich příliš mnoho.

Přesto je možné uvažovat o tom, že pro vyhledávání služeb budou v některých služeb vedle spouštějících životních událostí uvedený i „typické/typové“ životní události, které berou v úvahu vždy jenom vybraný další atribut nebo atributy klienta a jeho situace (zdraví, příjem, rodinný stav, věk apod.) a všechny ostatní atributy a s nimi spojenou variabilitu situací opomíjejí. Například k události „Narození dítěte“ se může u některých služeb zpřesňovat typovou situací „nezaměstnaná svobodná matka bez příjmů a bydliště“.

Z toho plyne požadavek na Katalog životních událostí, aby umožňoval k vybraným událostem vložit i jednu nebo více typových životních situací a jejich definičních atributů. K tomu musí jako součást aplikace existovat číselník těchto definičních atributů a jejich přípustných hodnot.

Pro Katalog služeb veřejné správy z toho plyne požadavek, že musí umožňovat klasifikaci jednotlivých služeb a jejich jednotlivých úkonů také jednou nebo více hodnotami z Katalogu životních událostí a k tomu jednou nebo více hodnotami z na něj se vážícího Katalogu typových životních situací.

Komunikace v digitálních obslužných a komunikačních kanálech (a nejen v digitálních) se dělí na korespondenční (asynchronní s dlouhou prodlevou) a interaktivní (synchronní, s téměř okamžitou reakcí). Dále se dělí na: • „úřední“ - mající právní přímé dopady (podání, doručení/převzetí);

• „neúřední“, či neformální.

Jednotlivé federované portály umožní zprostředkování komunikačních kanálů federujícímu portálu, a to tak, aby klient mohl využívat digitální služby VS bez narušení uživatelského zážitku. Jako komunikační kanály může klient s využitím elektronické identifikace NIA využít přímo portál (web), respektive za portálem skrytou službu AISu, anebo službu elektronického doporučeného doručování, tj. datovou zprávu prostřednictvím informačního systému datových schránek.

Na podávání/doručování prostřednictvím elektronické zprávy opatřené kvalifikovaným elektronickým podpisem nemají uvažované funkce portálů žádný vliv, nejsou jejich součástí.

Představitelem funkcí pro interaktivní neformální komunikaci v portálech je diskuse s živým operátorem (Chat) nebo s počítačem (Chatbot). Je otevřenou otázkou, zda pro tyto formy komunikace ve federovaných portálech existují nějaká regulující pravidla.

Podání či vyzvednutí s elektronickou identifikací, zprostředkované v portálu

Funkce poskytuje klientovi možnost učinit podání a využít při tom přehled o historii podání, a to jak těch realizovaných, tak i rozpracovaných včetně příznaku, zda podání bylo realizováno elektronicky (potom je možné, pokud je rozpracované, se k němu vrátit), či nikoliv.

Funkce je taktéž napojena na Katalog služeb, přičemž každý úkon v rámci služby má jasně definovaný obslužný kanál/kanály. V praxi to bude znamenat, že v samoobslužném kanálu po výběru služby z Katalogu služeb a výběru příslušného úkonu je uživatel přesměrován prostřednictvím odkazu na dané podání, tj. formulář nebo seznam dílčích formulářů k úkonu služby.

V případě podání dává samoobslužný komunikační kanál v souladu s § 4 ZPDS uživateli na výběr, jak bude podání odesláno, a to buď prostřednictvím:

• datové schránky;
• kontaktního místa veřejné správy učiněním digitálního úkonu, o němž tak stanoví prováděcí právní předpis (např. Czech POINT);
• sítě elektronických komunikací dokumentem podepsaným uznávaným elektronickým podpisem nebo opatřeným uznávanou elektronickou pečetí;
• ISVS umožňujícího prokázání totožnosti uživatele služby s využitím elektronické identifikace (přes NIA);
• jiného způsobu, pokud tak stanoví právní předpis.

Služba elektronického doporučeného doručování (Datová schránka)

Funkce datové schránky definuje způsob, jakým odesílat a přijímat zprávy z veřejné správy a digitálně tak komunikovat se státem. Pro federaci portálů a z důvodu rozmanitosti jednotlivých agend je žádoucí, aby jednotlivá portálová řešení umožňovala přístup k části nebo celému obsahu datové schránky uživatele v rámci federovaného portálu. Autoři dokumentu by rádi přesvědčili všechny, kdo jsou odpovědní za rozhodnutí tímto způsobem DS rozšířit, aby se dívali na věc z pohledu uživatele. Celá řada digitálních procesů je nyní limitována hranicemi jednotlivých AIS, resp. agendových portálů. Celá řada digitálních služeb ale tyto hranice ve skutečnosti překračuje, například placení daní a odvodů. A právě proto zde má federace své místo. Služba, která započala na jednom portále, dokonce například automaticky přechází do agendy portálu jiného. Tomu se říká úplná zákaznická cesta (customer journey) a při její realizaci není vhodné nutit uživatele, aby pro náhled na dokument z DS musel přejít na další portál. Je naopak vhodné aktuální zprávu, která se možná týká problému, který právě řeší přes několik portálů, mu zprostředkovat na místě, kde se právě nachází. Dnes má takto uživatel notifikaci o příchozím e-mailu jak v notebooku, tak v telefonu, ale díky němu třeba na hodinkách nebo náramku. Uživatel je zvyklý, že ho důležitá zpráva (pro něj) doprovází přes zařízení. Úkolem VS je umět to samé, ale bezpečně a efektivně.

K tomu, aby bylo možné využívat DS na federovaných portálech je nutná autentizace prostřednictvím přihlašovacích údajů DS, což je utlumované řešení, anebo NIA, respektive i do ISDS se uplatní bezešvý přechod s SSO pomocí NIA. Datová schránka, jako centrální komponenta, taktéž působí jak součást všech portálů, a to z důvodu, že každý uživatel bude využívat jiný portál jako ten „výchozí“, tzn. je potřeba, aby uživatel měl na všech portálech (na federujícím i federovaném portálu) tuto službu dostupnou a pracoval s ní s jako integrální komponentou.

Propojení datových schránek bude realizováno s využitím přístupového rozhraní ISDS.

Vytvoření metodiky jednotného použití UI řešení

Technický důsledek

datových schránek jako součást Design systému tak, aby uživatelská zkušenost na všech portálech byla stejná.

Propojení přihlášení na federujícím/federovaném portálu a do datové schránky může narážet na limity stanovené vyhláškou č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního

Právní důsledek systému datových schránek, zejména § 3¹⁴⁾, který

stanovuje technické podmínky pro přihlášení a bezpečnostní zásady a nelze tak zaručit, že nebude nezbytné samostatné přihlášení přístupovými údaji k datové schránce.

V rámci této oblasti je uživateli umožněno zobrazit si informace, které se klienta nějakým způsobem týkají, které jsou v registrech anebo které jsou v agendových informačních systémech či federovaných portálech.

Data poskytovaná informačními systémy

Funkce zajišťuje o klientovi – uživateli portálu přístup k o něm evidovaným údajům v různých agendových informačních systémech a registrech¹⁵⁾.

Funkce má tři varianty a stupně rozsahu:

• implicitní funkce, která přihlášenému uživateli dotahuje několik vybraných údajů pro jeho dashboard;
• rozšiřující funkce, která na vyžádání (zavolání služby) doplní k vybrané skupině ukazatelů větší detail;
• plná funkce, která na základě oprávnění ze zákona poskytne na vyžádání (zavolání takové služby) plný výpis o něm vedených údajů v AIS.

Jedná se Back-end integrace a de facto se nejedná o pravidla federace portálů. Lokální portál zobrazuje pouze lokální údaje napřímo, federující portál zobrazuje údaje všech systémů, které v něm přes eGSB/ISSS nabízejí tuto svou službu (měla by být jako agendová služba dle ZoZR nebo ZISVS nabízena i v katalogu služeb, ale může být v PVS „vytažena“ extra.

Agendový informační systém poskytuje data ve standardizovaném formátu a formě pro zobrazení na federujících portálech.

Portály si mezi sebou umožní pomocí deeplinku navigovat se ke konkrétní informaci na odkazovaném portále proklikem.

Portál implementuje pro tyto potřeby statické

Technický důsledek

(trvalé) adresy a dodržuje standardní SEO pravidla.

Bude třeba zajistit soulad s povinnostmi k řízení přístupu (k portálům) dle § 12 VoKB a správě a ověřování identit dle § 22 VoKB.

Upozorňujeme na požadavek § 4 odst. 1 písm. d)

ZPDS, jenž může být formálně vykládán tak, že

Právní důsledek digitální úkony lze činit pouze prostřednictvím ISVS,

umožňujícího prokázání totožnosti uživatele služby s využitím elektronické identifikace. Tedy, formálně vzato by skutečnost, že k takovému prokázání došlo v jiném ISVS mohla realizaci této funkcionality bránit.

Data realizovaná uživatelem portálu (v profilu uživatele)

Funkce poskytuje data, která nejsou v žádných agendových informačních systémech ani registrech. Jedná se zejména o data, která se rozhodl uživatel sdílet sám, ze své vlastní vůle – preference jazyka, alternativní komunikační kanál (např. sekundární emailová adresa), přizpůsobení dlaždic na portálu (viz kapitola Nástěnka – ústřední dashboard) nebo přidání vlastní události do kalendáře (viz kapitola Kalendář).

Ač je federující portál nepersistentní, tak se tato data o uživateli ukládají do portálu a součástí jsou i Nástěnka – ústřední dashboard a Osobní datové prostory uživatele versus prostory subjektu práva.

Ještě otevřenou otázkou je to, jaký má být vzájemný vztah mezi centrálními a lokálními profily. Tedy zda se něco z centrálního profilu smí/musí dědit do lokálních profilů (pokud to v nich není lokálně přepsáno jako preferované) a zda se naopak něco agreguje z lokálů „nahoru“.

Přehled (digitálních) úkonů

Přehled (digitálních) úkonů představuje pro klienta možnost zobrazit si přehled všech podání (minulých i nadcházejících). A to jak ve federujícím portálu, tak zejména v jednotlivých federovaných portálech, s následnou sumarizací informací v portálu federujícím.

• Zobrazení informace o učiněném digitálním úkonu

Federující portál ze zákona umožňuje zobrazovat informace o osvědčeních o realizovaných digitálních úkonech v PVS. Uživateli je zobrazena přehledová tabulka se všemi realizovanými úkony, ve kterých si může následně filtrovat realizované úkony své vlastní nebo dle zvoleného zastupovaného subjektu.

• Přehled všech podání klienta

Na federujícím portálu je zobrazován jeden ucelený přehled všech klientem učiněných i blížících se podáních formou přehledové tabulky, která disponuje možností filtrovat a vyhledávat v jednotlivých záznamech a řádcích tabulky. V rámci tohoto přehledu se klientovi indikuje, zda podání bylo realizováno prostřednictvím portálu, jiným digitálním nebo tradičním kanálem (např. osobně na přepážce).

Osobní datové prostory uživatele versus prostory subjektu práva

Funkce poskytuje klientovi spravovat osobní datový prostor, do kterého si může ukládat dokumenty spojené s vyřízením dané agendy, rozpracovaná podání, případně vytvořit sdílený prostor s vybraným úředníkem v rámci, kterého mohou společně pracovat. Tento prostor může sloužit jako „Osobní archiv“, nyní částečně implementovaný v Portálu občana.

• Osobní archiv

Jednotlivé portály mohou provozovat osobní pracovní prostor přihlášeného uživatele/klienta, kde se mu zobrazují veškeré dokumenty, ke kterým má právo přistupovat na základě zvolené role (subjektu práva) či pověření (mandátu). Klientovi je přidělen datový prostor s omezenou datovou kvótou. Tento prostor slouží klientovi k odkládání dokumentů, které potřeboval k vyřízení agendy nebo mu poskytl daný portál.

Vytvoření centrální komponenty osobního datového prostoru pro ukládání dokumentů.

Technický důsledek Je potřeba realizovat omezení uživatelských přístupů

k dokumentům a omezení maximální využitého prostoru.

Pravidlo může například umožnit naplnění § 5 ZPDS, tj. možnost uložení doručeného/zpřístupněného osvědčení digitálního úkonu (předpokládá se užití kvalifikované elektronické pečeti a razítka), nicméně s ohledem na předpokládaný rozsah typů dokumentů, tedy vztahující se mj. i na osobní připravované dokumenty, nelze zpracování těchto dokumentů a v nich obsažených údajů vztáhnout

Právní důsledek pod zákonnou licenci ke zpracování osobních údajů.

Bude tak nezbytné vymezit souhlas s takovým zpracováním, přičemž s ohledem na neomezené možnosti, co uživatel může nahrát může takový souhlas narážet na limity zásady minimalizace zpracování osobních údajů.

U federujícího portálu upozorňujeme, že na základě současné právní úpravy dle ZPDS k takové činnosti chybí právní titul, neboť ZPDS ukládá práva a

povinnosti výlučně OVM, nikoliv federujícímu portálu.

Je třeba opět zohlednit skutečnost, že povinnosti ukládá ZPDS v § 3 poskytovateli (OVM) digitální služby, nikoliv federaci portálů, respektive federujícímu portálu.

• Pracovní prostor – rozepsaná podání

Uživatel má možnost rozepsat si podání, připojit si dokumenty, aniž by tuto práci ztratil. Takto rozepsané podaní je pak dostupné na federujícím i federovaném portálu.

• Pracovní sdílený prostor s daným úředníkem

Dokumenty z tohoto úložiště je klient schopen sdílet s pracovníky příslušného úřadu. Poskytnutí přístupu k dokumentu nebo dokumentům je možné pouze explicitní akcí uživatele vlastníka.

Možnost sdílení zabezpečených odkazů odkazující na konkrétní dokument.

Technický důsledek V rámci implementace bude potřeba vyřešit

workflow v rámci daného úřadu/agendy pro předávání mezi úředníky.

S ohledem na to, že ani při extenzivním výkladu ZPDS nemusí být garantována existence zákonné licence, v konkrétním případě bude v tomto ohledu vhodné tuto funkcionalitu podmínit příslušným udělením souhlasu uživatele služby. Současně upozorňujeme, že takto nasdílený dokument nebude bez dalšího na základě současné

Právní důsledek právní úpravy správním podáním ve smyslu § 5odst.

4 SŘ a neuplatní se tak ani související právní úprava (například úředník nebude mít povinnost se s nasdíleným dokumentem vypořádat ani pomoci uživateli služby odstranit jeho vady).

Rovněž bude třeba zaručit soulad s povinnostmi k řízení přístupu (ke sdíleným dokumentům) dle § 12 VoKB a správě a ověřování identit dle § 22 VoKB.

U všech tří typů prostorů je dosud otevřenou otázkou, zda a jaký má být jejich vztah v rámci federace, a to obsahově i technologicky:

• Mají centrální prostory obsahovat jenom „náhled“ do souboru lokálních prostorů, volaný jako službu? Nebo si mají udržovat i index? Nebo mají existovat totožné centrální prostory a lokální prostory, přičemž ty centrální budou vedle vlastního obsahu ukazovat i náhled lokálního obsahu? A mají lokální prostory dědit něco z centrálního prostoru – opět formou náhledu a případného „dotažení“ dokumentu po zavolání služby? Jak by se tyto souborové služby mezi prostory realizovaly – přes eGSB/ISSS nebo jinak?
• Mají některé funkce, výpočetní výkon a úložný prostor komponenty pro centrální osobní prostory sloužit i jako centrální sdílená služba pro konstrukci lokální portálů, zejména pro ty malé?

Kalendář

Funkce kalendáře poskytuje klientovi přehled o všech již proběhlých, tak i nadcházejících událostech. Kalendář klientovi poskytuje přehled o blížících se předpisech/pohledávkách, termínech podání (veřejně i individuálně), termínech schůzek (smluvená schůzka na úřadě nebo přímo s úředníkem). Uživatel si do kalendáře může také zadat vlastní událost, případně si může přidat kalendář z různých institucí a portálů – např. kalendář daňových povinností (zdrojem je Finanční správa); sociálního pojištění (zdrojem je ČSSZ); zdravotního pojištění (zdrojem je pojišťovna); kalendář akcí hl. města Praha (zdrojem je portál Prahy) či kalendář národních dotací (zdrojem je MMR). Všechny události jsou tak dostupné v centrálním kalendáři klienta, který je dostupný pro federované i federující portály. Nebo, pokud se federovaný portál rozhodne používat lokální komponentu kalendáře, je nutné, aby událost poté propagoval do federujícího portálu.

Události jsou primárně zobrazovány vždy pro aktuálně zvolený subjekt práva (subjektem práva je sám uživatel – občan FO anebo jiné osoby – FO, PO i jiné organizace, uživatelem zastupované). V uživatelském profilu si uživatel může zvolit možnost, kdy mu budou zobrazeny všechny události ve formě agregované tabulky s informacemi, jež se týkají dané události, s možností exportovat událost do formátu iCal (jako jednorázový export, ale také jako link, na kterém je kalendář publikován), upravit a smazat událost a prokliknout se na detail události.

Jednotlivé události z kalendáře je následně možné provázat s upozorněními (viz kapitola Nástěnka – ústřední dashboard

Oblast nástěnka neboli přehledový ústřední dashboard umožňuje klientovi sestavit si rychlý přehled, známý např. z mobilního bankovnictví. V rámci tohoto přehledu si uživatel prostřednictvím různorodých pohledů může zvolit, jaké informace chce zobrazit na úvodní stránce. Nástěnku lze „sestavit“ jak na federujícím, tak i federovaném portálu. Uživateli poskytne přehled informací, které by ho mohly zajímat nebo jsou pro něj důležité. Tento přehled, respektive jeho části, si může uživatel definovat sám – obsah je prezentován různorodou formou interaktivních pohledů.

Na přehledovém dashboardu mohou uživateli být prezentovány informace, které se ho nějakým způsobem týkají – tzn. data poskytovaná agendovými IS (viz kapitola Informace o klientovi). Dále uživateli mohou být prezentovány data z jiných, jím zvolených portálů, např. portál finanční správy, portál některé ze zdravotních pojišťoven, různé aktuality a informace z úřední desky místního portálu (viz kapitola Zpřístupnění informací a zajištění notifikací podle zájmů klienta), seznam blížících se událostí (blížící se termíny plateb, místní události apod.).

Funkce poskytuje uživateli po přihlášení data a informace, které jsou zobrazena níže v diagramu. Jedná se o defaultní zobrazení jednotlivých sekcí, přičemž vyznačená část je neměnná, tzn. není možné ji uživatelem upravit – uživatel může upravit pouze pořadí jednotlivých sekcí.

Obrázek 7: Příklad defaultního zobrazení přehledu informací na úvodní stránce federujícího portálu po přihlášení

Personalizovat dashboard lze pouze v části portálu pro přihlášení. Pokud portál disponuje přehledovým dashboardem i ve veřejné sekci, tak je naplněn informacemi, které jsou například nejvíce hledané, doporučené správcem portálu apod.

a zpracování osobních údajů a bude třeba široce formulovaného souhlasu uživatele služeb. Takto formulovaný souhlas může narážet na limity zásady minimalizace zpracování osobních údajů. Upozorňujeme, že pseudonymizované údaje nejsou anonymizovanými údaji a vztahuje se tak na ně nařízení GDPR, a to se všemi odpovídajícími důsledky.

Obdobně bude třeba ve vztahu k datům čerpaným ze základních registrů třeba zajistit si právní titul k čerpání údajů ze základních registrů v souladu se ZoZR.

Portál po přihlášení umožní zobrazovat i veřejně dostupné informace, aby se uživatel nemusel odhlašovat pro jejich zobrazení.

Výše zmíněné je vhodné aplikovat i na funkce portálu po přihlášení, tak aby obecné informace byly doplněny o konkrétní informace o daném subjektu práva.

Federující portály zobrazují a odkazují na konkrétní agregované informace. Jejich primárním účelem je z jednoho centrálního bodu umožnit návštěvníkům zjistit stav informací o nich a v případě zájmu je navigovat na lokální (agendový, územní nebo soukromý) portál.

Federující portály nabízejí agregované a přehledové informace. V případě jejich nedostupnosti informují uživatele a odkazují ho přímo na agendový portál.

Technický důsledek

Výpadek libovolného portálu, který poskytuje agregovaná data, nesmí znemožnit funkčnost federujícího portálu.

Při dodržení pravidel přístupu skrze eGSB/ISSS a

Právní důsledek dostatečného právního titulu bez dalších právních důsledků.

Uživatel centrálního federujícího portálu se může nacházet ve dvou základních stavech – nepřihlášen nebo přihlášen. V případě prvního stavu je také možné si představit zobrazování nějakých agregovaných dat, ale necitlivého charakteru a na bázi například dříve uložených cookies. Můžeme si představit agregaci jeho zájmů (navštívených portálů stránek nebo posledních hledaných výrazů).

Naproti tomu ve stavu, kdy je uživatel centrálního federujícího portálu přihlášený, možnosti zobrazení agregovaných dat jsou mnohem širší a bylo by možné je filtrovat nebo řídit pomocí volby role. Zda bude nutné, aby si uživatel volil po přihlášení roli bude záviset na množství informací a ovládacích prvků, které se mu po přihlášení zobrazí. Postupným přidáváním funkcí do centrálního portálu by přehled možností a informací mohl být pro uživatele nepřehledný. Rozhodnutí o konečném řešení by mělo být podloženo uživatelským UX/UI výzkumem.

Příklady prezentovaných osobních informací, jejich agregací, nástrojů pro tuto agregaci a služeb, které může zobrazovat centrální portál pro přihlášeného uživatele:

• Agregovanou dlužnou částku přes všechny AIS
• Informativní výpočet důchodu a dobu, za kterou vzniká nárok na důchod (IDA)
• Očkovací průkaz (vakcinace a platnost testu – covid-19)
• Dostupné životní události/role (na základě dostupných informací o uživateli)
• Aktuality a úřední desky z federovaných portálů
• Vystavené předpisy plateb
• Sloučený kalendář z federovaných portálů
• Naposledy navštívené portály
• Naposledy hledané výrazy
• Přehledy učiněných a rozpracovaných podání
• Přehledy čerpání péče ze zdravotní pojišťovny
• Karta vedených údajů v registru obyvatel
• Přehled poplatků, které jsem povinen platit (z místních portálů; např. Pes, komunální odpad apod.)
• Přehled lokálních parkovací karty
• Přehled vydaných eReceptů
• Výpis vozidel z Registru vozidel vč. platnosti STK (propis do kalendáře)
• Seznam dostupných portálů (prioritizací dle informací o uživateli: bydliště, řidičské oprávnění, vlastník vozidla, další nemovitosti)
• Seznam státem vydávaných oprávnění, absolvovaných kurzů, bezpečnostní prověrka apod. • Moje dostupné role (např. občan, jednatel firmy atp.)

Sekce s podrobnějšími informacemi, ať už na aktuálním portálu nebo na portálu k němu federovaném, musí být pro přihlášeného uživatele dostupná bez omezení.

Uživatel může mít k dispozici katalog dostupných poskytovaných agregovaných informací, které chce zobrazovat na úvodní obrazovce.

Upozornění

), případně je možné si blížící se události nechat prezentovat na přehledovém dashboardu (viz kapitola Nástěnka – ústřední dashboard).

Obrázek 6: Příklad zobrazení kalendáře a detailu akce na Portálu Pražana

Federující portál jsou schopny si načítat data z

Technický důsledek federovaných portálů (kalendářů) a zobrazovat je

sloučené na jednom místě.

Za předpokladu naplnění zákonných požadavků ZKB,

Právní důsledek VoKB a předpisů upravujících ochranu osobních

údajů bez dalších právních dopadů

Je definována jedna struktura řešení kalendáře, ideálně podle platného standardu, např. ICalendar,

Technický důsledek

známý též pod názvem iCal je definován jako RFC 5545.

Za předpokladu naplnění zákonných požadavků ZKB,

Právní důsledek VoKB a předpisů upravujících ochranu osobních

údajů bez dalších právních dopadů

Sjednání schůzky

Klient, uživatel portálu, má možnost sjednat si schůzku s úředníkem, a to jak on-line, tak i fyzickou. Funkce nabízí uživateli na základě časových preferencí a místní příslušnost nejvhodnější lokalitu, kde potřebnou agendu lze vyřídit. Uživatel si taktéž může vybrat, zda bude schůzka realizována prostřednictvím on-line videohovoru či fyzicky. Pokud schůzka bude prostřednictvím videohovoru, klient i úředník obdrží odkaz na “místnost”, informace bude taktéž uživateli propsána do kalendáře (viz kapitola Kalendář), na úvodní dashboard (viz kapitola Nástěnka – ústřední dashboard) a bude také upozorněn na blížící se termín (viz kapitola Notifikace o blížícím se termínu).

Tato oblast funkcí poskytuje uživateli možnost sestavit si subskripce, respektive definovat z jakých dílčích portálů (agendových, místních či soukromoprávních) chce konzumovat informace, novinky a aktuality. Klient má možnost sestavit si na federujícím portále tzv. „můj úřad“, kde bude mít k dispozici vybrané informace ze všech úřadů, kde má klient nějaké zájmy – z jejich úředních desek, jejich kalendářů, případně z jejich aktualit. Pro tyto účely si klient definuje, jaké oblasti/témata chce sledovat vedle těch, které jsou mu standardně nabízeny.

Každý dílčí, federovaný portál poskytuje podle pravidel a standardů možnosti, jak výše zmíněná data bude poskytovat federujícímu portálu – formou RSS čtečky, čtečky pro automatický výběr kanálů či API.

Aktuality

Funkce poskytuje možnost konzumovat novinky z města, kraje, případně dalších dílčích portálů dle výběru klienta včetně informací z úřední desky. Jednotlivé úřady zveřejňují digitální formou dokumenty z úřední desky, novinky nebo aktuality. Následně jsou jednotlivé aktuality kategorizovány, tak aby si klient mohl zvolit pouze podmnožinu informací, která ho zajímá. V případě aktualit, které jsou z kalendářů dílčích portálů, se tyto informace propagují dále do centrálního kalendáře federujícího portálu, viz kapitola Kalendář. Klient si může také vybrat možnost zasílání novinek, aktualit a informací prostřednictvím emailu (uživatel si může zvolit, na jaký email mu mají být tyto informace zasílány). Informace, které jsou časově omezené, případně se vztahují k nějakému termínu, jsou klientovi poskytovány ve formě notifikací – standardně v notifikačním centru, případně dle preference klienta formou specifikovaných komunikačních kanálů – viz kapitola Nástěnka – ústřední dashboard.

Federující portály (a pouze ony) integrují a zobrazují aktuality z jiných portálů nebo webů. Tyto informace umožnují zobrazit a prokliknout se na detail zprávy v příslušného portálu nebo webové stránky.

Oblast nástěnka neboli přehledový ústřední dashboard umožňuje klientovi sestavit si rychlý přehled, známý např. z mobilního bankovnictví. V rámci tohoto přehledu si uživatel prostřednictvím různorodých pohledů může zvolit, jaké informace chce zobrazit na úvodní stránce. Nástěnku lze „sestavit“ jak na federujícím, tak i federovaném portálu. Uživateli poskytne přehled informací, které by ho mohly zajímat nebo jsou pro něj důležité. Tento přehled, respektive jeho části, si může uživatel definovat sám – obsah je prezentován různorodou formou interaktivních pohledů.

Na přehledovém dashboardu mohou uživateli být prezentovány informace, které se ho nějakým způsobem týkají – tzn. data poskytovaná agendovými IS (viz kapitola Informace o klientovi). Dále uživateli mohou být prezentovány data z jiných, jím zvolených portálů, např. portál finanční správy, portál některé ze zdravotních pojišťoven, různé aktuality a informace z úřední desky místního portálu (viz kapitola Zpřístupnění informací a zajištění notifikací podle zájmů klienta), seznam blížících se událostí (blížící se termíny plateb, místní události apod.).

Funkce poskytuje uživateli po přihlášení data a informace, které jsou zobrazena níže v diagramu. Jedná se o defaultní zobrazení jednotlivých sekcí, přičemž vyznačená část je neměnná, tzn. není možné ji uživatelem upravit – uživatel může upravit pouze pořadí jednotlivých sekcí.

Obrázek 7: Příklad defaultního zobrazení přehledu informací na úvodní stránce federujícího portálu po přihlášení

Personalizovat dashboard lze pouze v části portálu pro přihlášení. Pokud portál disponuje přehledovým dashboardem i ve veřejné sekci, tak je naplněn informacemi, které jsou například nejvíce hledané, doporučené správcem portálu apod.

Obdobně bude třeba ve vztahu k datům čerpaným ze základních registrů třeba zajistit si právní titul k čerpání údajů ze základních registrů v souladu se ZoZR.

Portál po přihlášení umožní zobrazovat i veřejně dostupné informace, aby se uživatel nemusel odhlašovat pro jejich zobrazení.

Výše zmíněné je vhodné aplikovat i na funkce portálu po přihlášení, tak aby obecné informace byly doplněny o konkrétní informace o daném subjektu práva.

Federující portály zobrazují a odkazují na konkrétní agregované informace. Jejich primárním účelem je z jednoho centrálního bodu umožnit návštěvníkům zjistit stav informací o nich a v případě zájmu je navigovat na lokální (agendový, územní nebo soukromý) portál.

Po přihlášení portál na úvodní obrazovce zobrazuje přehled volně dostupných informací a přehled

Pravidlo

informací vztažených ke konkrétnímu klientovi z dostupných napojených IS.

Federující portály nabízejí agregované a přehledové informace. V případě jejich nedostupnosti informují uživatele a odkazují ho přímo na agendový portál.

Technický důsledek

Výpadek libovolného portálu, který poskytuje agregovaná data, nesmí znemožnit funkčnost federujícího portálu.

Při dodržení pravidel přístupu skrze eGSB/ISSS a

Právní důsledek dostatečného právního titulu bez dalších právních důsledků.

Uživatel centrálního federujícího portálu se může nacházet ve dvou základních stavech – nepřihlášen nebo přihlášen. V případě prvního stavu je také možné si představit zobrazování nějakých agregovaných dat, ale necitlivého charakteru a na bázi například dříve uložených cookies. Můžeme si představit agregaci jeho zájmů (navštívených portálů stránek nebo posledních hledaných výrazů).

Naproti tomu ve stavu, kdy je uživatel centrálního federujícího portálu přihlášený, možnosti zobrazení agregovaných dat jsou mnohem širší a bylo by možné je filtrovat nebo řídit pomocí volby role. Zda bude nutné, aby si uživatel volil po přihlášení roli bude záviset na množství informací a ovládacích prvků, které se mu po přihlášení zobrazí. Postupným přidáváním funkcí do centrálního portálu by přehled možností a informací mohl být pro uživatele nepřehledný. Rozhodnutí o konečném řešení by mělo být podloženo uživatelským UX/UI výzkumem.

Příklady prezentovaných osobních informací, jejich agregací, nástrojů pro tuto agregaci a služeb, které může zobrazovat centrální portál pro přihlášeného uživatele:

• Agregovanou dlužnou částku přes všechny AIS
• Informativní výpočet důchodu a dobu, za kterou vzniká nárok na důchod (IDA)
• Očkovací průkaz (vakcinace a platnost testu – covid-19)
• Dostupné životní události/role (na základě dostupných informací o uživateli)
• Aktuality a úřední desky z federovaných portálů
• Vystavené předpisy plateb
• Sloučený kalendář z federovaných portálů
• Naposledy navštívené portály
• Naposledy hledané výrazy
• Přehledy učiněných a rozpracovaných podání
• Přehledy čerpání péče ze zdravotní pojišťovny
• Karta vedených údajů v registru obyvatel
• Přehled poplatků, které jsem povinen platit (z místních portálů; např. Pes, komunální odpad apod.)
• Přehled lokálních parkovací karty
• Přehled vydaných eReceptů
• Výpis vozidel z Registru vozidel vč. platnosti STK (propis do kalendáře)
• Seznam dostupných portálů (prioritizací dle informací o uživateli: bydliště, řidičské oprávnění, vlastník vozidla, další nemovitosti)
• Seznam státem vydávaných oprávnění, absolvovaných kurzů, bezpečnostní prověrka apod. • Moje dostupné role (např. občan, jednatel firmy atp.)

Sekce s podrobnějšími informacemi, ať už na aktuálním portálu nebo na portálu k němu federovaném, musí být pro přihlášeného uživatele dostupná bez omezení.

Uživatel může mít k dispozici katalog dostupných poskytovaných agregovaných informací, které chce zobrazovat na úvodní obrazovce.

Funkce upozornění (notifikace směrem k uživateli) představuje krátké informativní sdělení, oznámení, často generované automaticky na základě zvolených pravidel, změnou údajů nebo posunem kroku v nějakém procesu. Cílem notifikace je informovat uživatele, aby zaměřil pozornost na nějakou konkrétní událost na daném portále nebo v jiných obslužných kanálech podle kontextu (třeba k vyzvednutí na přepážce úřadu nebo na poště).

Komunikační kanály zajišťující doručení upozornění uživateli mohou být:

• SMS zpráva,
• e-mail,
• datová zpráva v Datové schránce,
• upozornění na portále.

Preferovanou formu a komunikační cestu definuje zpravidla uživatel. Nemusí tomu tak být ve všech případech. Formou se má na mysli například možnost zvolit zasílání souhrnného výpisu upozornění za definovaný časový úsek namísto okamžitého doručení notifikace v čase jejího vzniku.

Z hlediska vlivu rolí, ve kterých se uživatel může vyskytovat a z hlediska složitosti procesu zastupování jiných subjektů, nelze při nastavování a příjmu notifikací ve federovaném prostředí efektivně pracovat pouze s aktuálními údaji uloženými ve speciálních agendových portálech / jejich agendových IS. Tento přístup by nutil uživatele aktualizovat některá zmocnění (globální, generální) nebo vazby na ně na více místech. Stejně tak nepostačí pouhé využití části kontaktních údajů uložených v Registru obyvatel nebo Registru osob, které může uživatel fyzická osoba spravovat prostřednictvím portálu Národního bodu po své identifikaci a autentizaci. Je potřeba spojit tato základní data (kontaktní a preferenční údaje) se systémem zastupování (mandátů).

Uživatel si tak může nastavit zasílání notifikací týkajících se jak jeho osoby, tak jiných subjektů, které zastupuje (pokud k tomu má oprávnění). V případě zastupovaných subjektů je pak možné notifikaci zaslat jak zastupující osobě, tak samotnému subjektu. tj zastupované osobě. Pokud je zrušeno oprávnění, je automaticky zrušeno i zasílání notifikací za původně zastupovaný subjekt. Role výkonné a životní události nemají na uvedené vliv, ty jsou určeny pouze pro zúžení výběru služeb nabízených uživateli.

Další notifikace mohou být zasílány z AIS bez předchozího nastavení uživatelem přímo subjektu práva, případně oprávněné osobě za subjekt práva jednat (např. u PO).

Uveďme si příklady z praxe, které se týkají zastupování subjektů. Existují procesy, ve kterých mohou rodiče dítěte vystupovat samostatně, ale také ty, ve kterých musí být např. souhlas získán od obou rodičů. Notifikace nějakého procesu (úkonu) musí být tedy někdy doručena pouze jednomu z rodičů a jindy oběma. Dovršením 15 roku věku dítěte mohou být ty stejné notifikace doručovány přímo dítěti, za předpokladu, že je mu umožněno být součástí federovaného systému. Proto každá služba agendy, která chce notifikovat, musí vědět dříve, než požádá notifikační komponentu o službu zaslání upozornění, jaké jsou pro ni platné předpisy a koho, o čem a kdy notifikovat. Zná ve svém případě jak primární subjekt práva (dítě), tak jeho rodiče a ví, zda si objednat notifikaci obou nebo jednoho.

A uveďme si příklady z praxe, které se týkají zastupování subjektů. Manželé mohou jeden druhého zmocnit k podání u konkrétní služby, např. registraci motorového vozidla apod. Notifikace by měla být doručena jak zmocňujícímu, tak zmocněnému z osob, ale to musí stanovit příslušná agenda a služba. Nenotifikují portály, proto také nestanovují pravidla, pouze zprostředkovávají komunikaci.

Kontakty a preference uživatele pro předávání notifikací lze udržovat na více úrovních platnosti, tj. v základních registrech, v centrálním portálu, v agendových nebo územních portálech a současně v agendových systémech. Při nastavování notifikačních preferencí v profilech uživatelů a jimi zastupovaných subjektů platí hierarchie a dědičnost – i v lokálním systému/portálu platí globální kontakt preferovaného komunikačního kanálu pro upozornění, pokud není lokálně stanoveno jinak – to má pak přednost.

Komponenta zajišťující upozorňování uživatelů by měla být dostupná ve všech univerzálních, agendových i územních obslužných a komunikačních kanálech (samoobslužných i asistovaných). Notifikace jsou technicky předávány prostřednictvím PPDF¹⁶⁾ skrze eGSB/ISSS¹⁷⁾ v předem definovaném formátu, aby byla zajištěna kompatibilita napříč portály. Je žádoucí zajistit, aby notifikační komponenta tzv. následovala uživatele při jeho pohybu po jednotlivých federovaných portálech automaticky. Kdekoliv se uživatel pohybuje a je na tomto místě implementována notifikační komponenta, uživatel je doprovázen aktuálními informacemi a aktuálním nastavením. Portály využívají jednotné brány pro zasílání upozornění.

Notifikace mají obvykle několik kategorií z hlediska úrovně upozornění, například pomocí 3 úrovní: upozornění; varování; výzva. To neplatí plošně – notifikace mají takové úrovně, jako nastavují agendové zákony nebo lokální prováděcí předpisy. Pouze u nativních portálových služeb je možné úroveň notifikací nově nastavit. Tyto úrovně stanovují agendové zákony nebo lokální prováděcí předpisy. Pouze u nativních portálových služeb je možné úroveň notifikací nově nastavit v portálech. Kategorie slouží k odlišení naléhavosti sdělení a svým způsobem nesou v sobě informaci i prioritě zpracování informace. Úrovně upozornění by měly být případně odlišeny dalšími vizuálními prostředky, jako je barva, font, jeho síla a velikost apod.

Obecně platí, že:

• termín, obsah, úroveň, příjemce a někdy i kanál notifikací stanovuje objednatel (ten, kdo žádá, aby bylo notifikováno), což je někdy poskytovatel služby a jindy příjemce služby veřejné správy (u subskripce notifikace),
• kanál, kontakt a formu notifikací převážně nastavuje příjemce.

Ekosystém notifikací by měl fungovat maximálně spolehlivě, protože se dá předpokládat, že uživatel bude očekávat kvalitu garantovaného doručení a nebude rozdílnou garanci jednotlivých služeb VS rozlišovat. U služeb, kde

doručení zajišťuje třetí strana (například SMS), je potřeba získat od třetích stran dodatečné monitorovací nástroje nebo výstupy z nich za účelem doložení historie odesílání notifikací v případném sporu nebo řešení stížnosti. Zároveň je potřeba vytrvale edukovat uživatelskou obec, že notifikace negarantují, ale podporují informovanost uživatele. Žádoucí je o výpadcích doručování, které se reálně dějí, vědět a komunikaci případně automaticky opakovat. Dopad provozu ekosystému notifikací na současné výkonnostní parametry eGSB/ISSS je potřeba odhadnout a v dostatečném předstihu před zprovozněním zohlednit.

Interní systémy agend VS (AIS) a systémy obslužných kanálů (Omnichannel) potřebují vědět o notifikacích, které byly nebo budou doručeny uživateli (klientovi služby). Se zvyšujícím se podílem zajišťováním procesů (služeb) digitální formou namísto fyzického (a papírového) postupu se stává tato část komunikace důležitá a musí být automaticky součástí interních procesů a také být zohledňována při obsluze klientů a komunikaci s nimi. V mnoha případech na doručení upozornění může záviset další postup (úkon uživatele) v procesu, vyjma výzvy z úřadu, která musí být doručena zákonnými kanály (ta může být následně doprovázena notifikací). Notifikační ekosystém musí vystavit pro tyto případy rozhraní (API).

Federující portál je primárním konzumentem notifikační komponenty, federované mohou služby komponenty využívat též.

Technický důsledek

Technologické řešení ideálně umožňuje bezproblémové zasunutí do jakéhokoliv současného řešení webového portálu.

Doposud s výjimkou ustanovení § 11 odst. 2 ZPDS neexistuje žádná legislativní podpora. V oblasti elektronického doručování (a komunikace obecně) vychází současná právní úprava výlučně

Právní důsledek z institutu informačního systému datových schránek

a doručování jejich prostřednictvím. Zamýšlená notifikace tak nemá v oblasti doručování žádné právní dopady, s výjimkou práva na poskytnutí informace o končící platnosti občanského průkazu,

Notifikace o změně

Předchozí odstavce této kapitoly připomínají řešení pro upozornění, která jsou součástí definice a struktury nabízených služeb. Uživatel z takové definice chápe, že podal-li žádost o vydání např. cestovního dokladu, přijde mu upozornění v konkrétních milnících procesu zpracování. Například upozornění, že doklad již je vyhotoven (před zákonným termínem) a je možné si jej vyzvednout.

Mohou nastávat situace, kdy notifikaci potřebuje vynutit systém nebo úřední osoba zpracovávající daný proces. Například v případě, že termín objednané schůzky s úředníkem dané agendy je potřena změnit z důvodu jeho nepřítomnosti. Je jedno, zda se byla naplánována fyzická schůzka nebo schůzka v on-line režimu. Uživateli je potřeba s dostatečným předstihem dát na vědomí nestandardní situaci, odchylku od stavu, který je očekáván.

Předpokládá se rozpracování upozornění především u změn, které nevznikají na podnět klienta, ale i jako potvrzení provedení změny iniciované klientem. Notifikace o takové změně je uživateli zaslána komunikačním kanálem, který uživatel v notifikačním centru definoval jako základní (default) komunikační kanál nebo které má povahu základního kanálu automaticky (například telefon). A to tehdy, pokud klient nenastavil pro agendu nebo službu nebo úkon odchylné (lokální) preference doručování. Pokud jsou lokální preference nenastaveny, platí globální preference (dědičnost).

Nabídne-li řešení notifikační komponenty uživateli možnost odmítnout volby základního komunikačního kanálu a tím potlačení příjmu těchto zpráv, uživatel je notifikačním centrem upozorněn na možné důsledky z toho vyplývající.

Notifikace o blížícím se termínu

Skupina upozornění na události nebo změny, které vznikají nezávisle na vůli uživatele či úředníka jsou upozornění na termíny nebo úkony definované zákony, vyhláškami apod. Typickým příkladem mohou být termíny podání řádného přiznání daně z příjmu, uhrazení platby daně z nemovitosti apod. Jde o upozornění, která mohou být součástí jiných komponent popisovaných tímto dokumentem, například komponentou Kalendář. Ta může obsahovat tyto jasně definované milníky automaticky a záleží jen na uživateli, jak s kalendářem bude nakládat, viz. samostatná kapitola.

Upozornění patří do kategorie volitelných, tedy uživatel má možnost potlačit jejich příjem. Při definici funkcí notifikační komponenty je vhodné odlišit upozornění o blížících se termínech (ze zákona) od notifikací o termínech například dohodnutých schůzek, které by měly být řešeny v rámci standardních procesů, jako je například služba sjednání schůzky k dané věci.

Do kategorie upozornění popisované v této kapitole náleží například změna zákonného termínu podání přiznání z daní z příjmu z důvodu pandemické situace v zemi, tj zabezpečení automatického upozornění všem uživatelům federovaných portálů VS.

Jedná se o oblast funkcí, která umožňuje klientovi nahlížet na přehled již proběhlých platebních transakcí, které realizoval na dílčích portálech, v kterémkoli subjektu práva (viz kapitola Výběr subjektu práva). Dále klientovi poskytuje možnost nahlížet na seznam pohledávek k vyřízení v konsolidované podobě ze všech dílčích AISů , opět bez rozdílu subjektu práva. Klientovi tato oblast poskytuje centrální pohled do lokálních seznamů pohledávek před a po splatnosti, včetně historie.

Funkce vychází z myšlenky, že OVM – poskytovatelé služeb spojených s úhradou, chtějí klientům usnadnit proces této úhrady a mají z toho přínos v podobě zvýšení rychlosti a bezchybnosti výběru. Proto poskytovatelé služeb vytvoří a do obslužných kanálů, zejména portálu/webu, klientům poskytnou předpisy platby.

Klientovi je umožněno v této oblasti funkcí hradit poplatky za služby veřejné správy – např. ze psů, za komunální odpad, zdravotní a sociální pojištění, daně apod. Informace o platbách, respektive termíny plateb jsou propagovány do kalendáře (viz kapitola Kalendář) a notifikačního centra (viz kapitola Notifikace o blížícím se termínu) – pokud je tak zvoleno v uživatelském profilu klienta.

Údaje o pohledávkách a platbách jsou z federovaných agendových systémů technicky předávány do federujícího portálu přes PPDF skrze eGSB/ISSS v předem definovaném formátu, aby byla zajištěna kompatibilita napříč portály.

Klient bude přesměrován na platební bránu spojenou s předmětným předpisem, kde bude platba realizována, aniž by se musel pídit po tom, jaká a čí brána to je (obdobně jako v eShopech). Zároveň by v budoucnu tato platební brána měla klientovi umožnit uhradit jednou, souhrnnou platbou více pohledávek – jako hromadný příkaz v elektronickém bankovnictví. Mělo by být proveditelné, aby platební funkce portálu sestavila hromadný platební příkaz a aby platební brána přenesla tento příkaz do elektronického bankovnictví klienta k úhradě. Jiné formy jsou daleko od možné proveditelnosti.

Historie platebních transakcí

Portál poskytuje přehled všech předpisů, z nich vzniklých pohledávek a závazků, případně nedoplatků a přeplatků ve formě přehledové tabulky. V rámci tabulky jsou transakce rozlišeny na realizované; stornované; po splatnosti s označením, ke kterému subjektu práva patří.

Současně takový bezešvý (single-sign on postup) bude možný pouze v případě, že federující i federovaný portál jsou kvalifikovanými poskytovateli služeb dle ZoEI.

Seznam pohledávek před/po splatnosti

Federující portál poskytuje vedle historie již provedených transakcí přehledovou tabulku se seznamem tzv. otevřených pohledávek před/po splatnosti z ostatních federovaných portálových řešení s označením, vůči které instituci je potřeba závazek uhradit, včetně částky a data splatnosti. Po kliknutí na příslušný řádek s platbou v detailu je klient (FO či PO) přesměrován na příslušnou platební bránu¹⁸⁾ nebo jsou klientovi poskytnuty nezbytné platební údaje a QR kód pro provedení platby (klient si v uživatelském profilu zvolí preferenci).

Portál by přirozeně, jako elektronická bankovnictví, a dle volby klienta mohl zobrazovat vedle pohledávek i přehled závazků státu, jak již vypořádaných platbou (v historii), tak zejména těch otevřených, kde klient ještě může čekat úhradu, ví kolik, na který účet a s jakou splatností.

Zpětná vazba je oblast funkcí, která se nevynucuje jako podmíněný krok, ale je zaslána klientovi formou zdvořilého dotazu (pouze pokud není zaškrtnuto v profilu). Zpětnou vazbu klient poskytuje ve formě hodnocení (výběrem z nabídnutých možností nebo stupnice), volitelně potom může přidat i komentář. Hodnocení je anonymní (pokud si klient ale přeje uvést své kontaktní údaje, např. v případě stížnosti, musí se autentizovat) a jeho výsledky jsou navázány na katalog služeb.

Pro zpracování zpětné vazby jsou nezbytné dostatečné centrální nástroje a kapacity pro před-vyhodnocení a distribuci zpětných vazeb jednotlivým OVM jako podklady pro jejich zlepšování služeb.

Hodnocení poskytnutých informací

Tato zpětná vazba je umístěna na každé stránce, která poskytuje informace uživateli, např. popis služby, rozcestníky, kontakty apod. Jako otázky lze použít již implementované otázky na portal.gov.cz, které současně naplňují požadavky na zpětnou vazbu dle SDG. Sjednocením lze docílit snadného porovnání mezi portály a agregovatelnosti výsledků.

údaje, a nebude se tak jednat o anonymní údaje. Důsledkem tak je aplikovatelnost nařízení GDPR.

Hodnocení spokojenosti s poskytnutím služby

Dílčí portál poskytuje klientovi dotazník spokojenosti po obsloužení (po realizaci služby), a to na úrovni úřadu, služby veřejné správy nebo jejího úkonu.

Bude na správcích služeb jednotlivých agend, jestli nastaví v Katalogu služeb příznak pro sběr zpětné vazby pouze na úrovni služby (povinně) nebo i na úrovni úkonu (volitelně). Katalog bude muset být pro tento účel rozšířen.

Hodnocení spokojenosti s nástrojem

Dílčí portál poskytuje možnost zaslat zpětnou vazbu na strukturu nástroje (portálu), jeho obsah, přehlednost a uživatelskou přívětivost. Tato zpětná vazba je zaslána přímo správci nástroje – informačního systému.

Hodnocení úředníka

Základem zpětné vazby v obslužných kanálech je klientovo hodnocení spokojenosti s transakcí (úkonem a službou). Následně je na nástrojích IT a procesních nástrojích, aby hodnocení spojili s konkrétním referentem, bude-li o to v rámci řízení služeb úřadu zájem.

Vedle toho může existovat možnost (formulář), aby klient vychválil nebo pohaněl konkrétního člověka, pokud ho zná, ale je to spíše výjimečná možnost.

Dílčí portál tedy může poskytnout možnost ohodnotit úředníka, který realizoval službu pro klienta. Dotazník může nabývat různé realizační formy. Může “viset” jako poslední stránka nějakého uceleného procesu nebo může být klientem vyhledán a vyvolán v návaznosti na seznam historie jeho podání. V případě fyzické návštěvy úřadu za účelem realizovatelnosti hodnocení úředníka je nutné zajistit spárování úředníka s obslouženým klientem. K tomu může sloužit například QR kód na dveřích nebo stole úředníka nebo v přehledu kontaktů na

webu/portálu daného úřadu. Výčet možností není úplný, má sloužit pouze k ilustraci možného řešení, které musí být i v těchto případech především technicky jednoduché.

Přehled hodnocení

Dílčí portál umožňuje zobrazení hodnocení spokojenosti s jednotlivými úřady, službami nebo úkony. Hodnocení je dostupné na federujících i federovaných portálech.

Jednotné místo, kde jsou uchovávány výsledky, umožňuje různé pohledy přes strukturu portálů, přes agendy atd. Přístup ke detailní zpětné vazbě k agendě, službě nebo úkonu mají všechny subjekty, které do ní přispívají a vidí pouze svoje data a data svých podřízených součástí.

Oblast funkcí pro podporu zastoupení poskytuje uživateli primárně možnost vykonávat funkce a využívat služby veřejné správy jako zástupce jiného subjektu (fyzické osoby nebo organizace). Tato funkce je svým způsobem defaultní. Dále může uživatel delegovat svoje vlastní požadavky na jiný subjekt práva. Realizace zmocnění tak vychází jednak z existujících referenčních údajů o uživateli nebo na základě některé z forem záměrného zmocnění a znamená to tedy, že některá zmocnění budou přebírána ze základních registrů (např. pro roli jednatele společnosti) a z jednotlivých AIS (např. rodič z IS EO), případně z lokálních mandátních registrů jednotlivých AIS u zmocnění, která byla realizována před vznikem jednotného centrálního řešení. Nová zmocnění (delegovaná) budou realizována převážně novým centrálním způsobem.

Platná legislativa neomezuje subjekt práva v možnostech udělení plné moci. Lze udělit zmocnění „na všechny úkony a na neomezenou dobu (generální zmocnění) a učinit tak formou fyzickou (v listinné formě), která je stále významně zastoupena při kontaktu s veřejnou správou, a také formou „digitální“ (zmocnění jako digitální úkon, např. podepsaný elektronický dokument). Je žádoucí, aby obě formy mohl mít uživatel digitálních služeb k dispozici a ideálně do budoucna především ve vazbě na konkrétní digitální úkon, nikoliv pouze jako seznam transakcí. To zároveň předpokládá z počátku jisté omezení definice zplnomocnění, resp. přizpůsobení zmocnění pro konkrétní digitální úkony. Jakékoliv omezení v konečném důsledku ale více zpřístupní služby VS, proto se domníváme, že nebude uživateli přijímáno negativně. Samozřejmě je důležité, aby se jakékoliv řešení dle požadavků v rozvíjejícím se digitálním světě a dle zpětné vazby od uživatelů dále rozvíjelo.

Moderní (nákladově efektivní) způsob vývoje sw se děje v inkrementálních přírůstcích funkcionality s kontinuálním ověřování, předpokladů na reálných uživatelích. Zde se vzhledem k rozsahu celého řešení takový postup přímo nabízí. Nicméně je pouze málo kompatibilní nejenom se současným legislativním stavem, ale vůbec s možností legislativy definovat něco se dynamicky rozvíjejícího. Princip inkrementálního přidávání možností nějaké digitální funkce VS, zde typicky zastoupení, je nutné legislativně umožnit.

Proto je potřeba najít širokou odbornou shodu na prosazení legislativních změn, které umožní následně zpracovat zmocnění ve federaci portálů za vynaložení přiměřeného úsilí a přiměřených nákladů. Zmocnění představuje základ digitálních služeb a umožňuje zásadní zjednodušení uživatelovy kooperace s veřejnou správou. Zahraniční zkušenosti tento aspekt potvrzují, jejich řešení se neomezují na generální zmocnění.

Generální zmocnění je samozřejmě digitálně snadněji zpracovatelné, ale mělo by představovat pouze základní verzi jakéhokoliv řešení zmocnění. Zmocnění s individuálně definovanými parametry je naproti tomu jen velmi problematicky algoritmizovatelné a zpracovatelné v digitálních systémech. Ale tento problém je potřeba vyřešit.

Pro korektní fungování plných mocí je potřeba, stejně jako je tomu v ostatních zemích, jež implementovaly tuto službu (viz kapitola Zahraniční zkušenost), vytvořit digitální parametrizovatelný registr zastoupení. Tento registr by měl postupně umožňovat různé kombinace udělování plných mocí, tzv. digitálních mandátů, v souladu s konkrétními službami VS. Dá se předpokládat jeho silné provázání s katalogem služeb a úkonů, s katalogem životních událostí, případně s katalogem rolí (viz kapitola Katalog životních rolí) nebo s výběrem subjektu práva (viz kapitola Výběr subjektu práva a role). Půjde o rozsáhlý digitální systém, který bude hojně využívaný. Reálně definovaný registr digitálních mandátů bude pracovat s dalšími centrálními komponentami popisovanými v tomto dokumentu, jako je např. notifikace, kalendář, dashboard apod.

Dosavadní neexistence registru digitálních mandátů donutila některé AIS, resp. agendové portály problematiku podchytit a implementovat v rozsahu kompatibilním toliko s jejich vlastními službami. To rozhodně není na škodu věci, je tak možné začít v širším odborném kruhu a spolupracovat se skupinami, které mají již zkušenosti a vlastní reálné vstupy pro analýzu. Zároveň to představuje závazek, protože uživatelé těchto agendových služeb mohou být na nějakou formu digitálních mandátů uvyklí a budou očekávat při nové implementaci plynulý přechod. Všechny další aktivity, pokud někde v současné chvíli rozvíjejí možnosti výstavby lokálních řešení digitálních mandátů, je potřeba podchytit a propojit.

Přehled zastoupení

Přehled digitálních mandátů představuje jednu ze základních funkcí. Poskytuje přehledovou tabulku veškerých mandátů udělených uživatelem a mandátů uživatelem přijatých. Jak se řešení bude rozvíjet, resp. s postupným napojováním konkrétních požadovaných služeb jednotlivých AIS, může se taktéž přehled mandátů postupně plnit různými formami mandátů a funkcí k manipulaci s nimi. Například u funkcionality úpravy již vydaného mandátu se dnes nedá asi předjímat její reálné řešení. Z počátku také nemusí seznam umožňovat pohled na větší detail uděleného mandátu, postupně to bude jistě žádaná funkce. A tak podobně.

Z hlediska nákladového se asi nedá předpokládat, že součástí seznamu mandátů bude také přehled udělených mandátů (ve formě naskenované listinné podoby) před digitalizací nějaké konkrétní služby. Takový požadavek, ale může být uživateli vznesen a je potřeba na něj umět reagovat.

Mandáty vyplývající z rolí uživatelů (jednatel společnosti) budou prakticky uplatňovány pravděpodobně v základních částech ovládání konkrétního federujícího portálu – při volbě role uživatele nebo nějakém úkonu směřujícímu ke zúžení funkcí z důvodu konkrétní role uživatele. Z důvodu zachování přehledu mandátů ale také evidence těchto možností patří do této části.

Udělení a přijetí zastoupení

Funkce poskytuje možnost uživateli udělit či zažádat si o udělení zastoupení (mandátu). V obou případech bude možné postupně vytvářet sadu oprávnění, které mají být součástí mandátu, respektive vytvořit unikátní kombinaci oprávnění. Zároveň je možné vybrat již předdefinované oprávnění z registru.

Možné přístupy ke kontrole a delegaci zastoupení (oprávnění):

• Kontrola oprávnění k realizaci transakcí jménem jiných osob či organizací na základě údajů v registru. V tomto případě je delegace mandátu automatizována a vázána na údaje základních registrů, katalog životních rolí a roli subjektu práva, např. rodič má možnost jednat jménem vlastních dětí (údaj je dostupný v registru obyvatel) do dovršení věku 18 let, poté tento mandát automaticky zanikne.
• Vyžádání / vytvoření digitálního oprávnění a jejich následné uložení do registru zastoupení. Uživatel může buď vytvořit pověření, nebo požádat o pověření. Tato pověření si uživatel může nadefinovat a následně odeslat pověřenému uživateli ke schválení (v případě požádání o oprávnění). Typicky tam může uživatel, jakožto jednatel organizace pověřit jiného uživatele oprávněním jednat za danou organici – poskytnout mu plnou moc a jasně vydefinovat, které úkony pověřený uživatel může vykonávat jménem organizace.

Centralizace digitálních mandátů představuje náročný problém z hlediska řešení stavu omezení nebo nedostupnosti této centrální služby. Digitalizace VS musí obecně umožňovat nějakou formu náhradních (záložních, resp. původních) možností realizace dané služby. V případě digitálních mandátů je tento problém mnohem náročnější, než možná platí pro jiné centrální komponenty popsané v tomto dokumentu. Je těžko předvídatelné, jak bude problém vyřešen – obecně lze předpokládat, že v případě nedostupnosti centrální komponenty nebude možné mandáty nějakým náhradním způsobem použít (možná vyjma generálního mandátu, což je ale nechtěný stav).

Mezi podpůrné oblasti spojené s pravidly federace portálů patří tzv. informační architektura jako specializace zaměřená na strukturování a organizovaní informací a obsahu na webových stránkách, počítačových a mobilních aplikacích nebo sociálních sítích. Právě struktura nebo také rozvržení informací na webu ovlivňuje celkový zážitek uživatele a použitelnost webu. Informační architektura má za cíl uspořádat informace na webu tak, aby uživatel nalezl požadované informace bez velkého úsilí, a pomáhá v pochopení, kde se uživatel právě nachází, co vyhledal, jaké informace má k dispozici kolem sebe a kam se dále dostane.

Informační architektura je nezbytným předpokladem účelného návrhu uživatelského rozhraní (UI/UX), oba týmy musí úzce spolupracovat.

Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní

Jednotlivé typy portálových řešení – agendové portály, portály územní samosprávy, soukromoprávní portály – musí z pohledu uživatele používat jednotný vzhled a interakce – tedy vizuální interaktivní komponenty uživatelského rozhraní, které reprezentují informace a jak se tyto komponenty chovají. Tedy například kde se zobrazují chybové hlášky formulářů a kdy dochází k jejich validaci. Jakým způsobem funguje průchod procesem atp.

Jednotná struktura obsahu

Portály musí dodržovat jednotný organizační systém kategorizace a struktury informací, do kterého se celý obsah portálu zasadí. Struktura informací a jejich členění pak musí odpovídat i zvolenému subjektu práva, případně jeho roli (viz kapitola Výběr subjektu práva), přičemž v jakém pořadí je obsah prezentován je možné upravit v uživatelském profilu klienta.

Navigace

Jednotlivé typy portálových řešení musí dodržovat jednotný navigační systém, tj. jak uživatelé procházejí a posouvají se dál informacemi a obsahem. Vedle toho musí portálová řešení dodržovat jednotnou hierarchii navigace na portálu, např. portály měst musí disponovat ve vybraných částech totožnou stromovou strukturou navigace. Znamená to tedy, že struktura navigace se bude dělit na povinnou (regulovanou) část a volitelnou část – typicky pro řešení životních událostí, ty jsou lokalizovány např. pod sekcí „Potřebuji vyřídit“, nicméně obsah této sekce se může lišit (viz kapitola Katalog životních rolí Životní události (příp. typové životní situace) a příslušné služby VS).

Následující příklady ukazují stávající stav navigace vybraných územních portálů a rozdíly mezi nimi:

Obrázek 8: Struktura navigace na portálech města Plzně a Prahy

Jmenná konvence

Pro dodržení příjemného uživatelského zážitku je nutné, aby jednotlivé typy portálových řešení dodržovaly předepsanou jmennou konvenci v oblasti navigace. To uživateli pomůže se rychle zorientovat na různých portálech, např. při vyhledávání úředních hodin v různých městech nebo úřadech. Vedle toho je nutné dodržet jmennou konvenci v případě názvů portálů, zejména portálů územní samosprávy, a jejich URL adres.

Personalizace

Oblast personalizace se zabývá úpravou obsahu nebo vzhledem informací, stránek nebo komponent stránky bez explicitního zásahu uživatele. Tedy na straně portálu jsou definovány podmínky a pravidla, které při splnění modifikují šablonu specificky pro daného uživatele. Cílem takové modifikace má být zlepšení uživatelského zážitku. Personalizace je prováděna na základně dostupných informací kontextu uživatele.

Oblíbené

Uživatel má možnost přidávat si dostupný customizovatelný obsah do rychlého přehledu – dashboardu (viz kapitola Nástěnka – ústřední dashboard) a vytvářet si tak „seznam“ např. oblíbených odkazů do dílčích portálů (platí pro federující portály) nebo používaných služeb (platí pro federované i federující portály.

Customizace je definice pravidel explicitně definovaných uživatele. Jde o modifikace informací, stránky nebo komponent stránek na základě vůle uživatele. Zpravidla se jedná o úpravu vzhledu, uspořádání nebo filtr informací. Pro potřeby customizace musí existovat na daném řešení prostor, kde si daný uživatel může takové nastavení vytvořit a bude persistentní, tj. nebude si ho muset vytvářet při každé návštěvě portálu.

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů

Funkce poskytuje uživateli na úvodní straně federujícího portálu aktuality, aktuálně hledané články a nejpoužívanější služby, či nejvyužívanější životní události. Jedná se o tzv. „bestsellers“, které jsou dostupné bez nutnosti přihlášení uživatele.

Po přihlášení funkce uživateli nabízí na základě jeho aktuálního chování, na federovaném i federujícím portálu, nejpravděpodobnější související akce nebo služby s ohledem na chování ostatních klientů.

Dalším způsobem personalizace může být nabízení služeb nebo informací dle anonymního agregovaného chování ostatních uživatelů nebo dále lze pro personalizaci nabídky služeb využít obsah ze stejné kategorie nebo které jsou součástí stejné životní události.

Portály implementují do Front-End částí skripty

Technický důsledek zajišťující sběr dat pro analytický a rozhodovací SW.

V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) se uživatel služby na portálu choval, půjde pouze o pseudonymizované údaje, a nebude se tak jednat o anonymní údaje.

Důsledkem tak je aplikovatelnost nařízení GDPR.

Právní důsledek

S ohledem na personalizaci výsledků a obsahu tak bude třeba zajistit soulad s požadavky předpisů na poli ochrany osobních údajů, včetně vhodného nastavení cookies policy (mj. povinnost informovat uživatele o typech portály využívaných cookies).

Funkce umožňuje identifikovanému a autentizovanému uživateli portálů zvolit si, zda bude portál aktuálně užívat jako subjekt práva, tj. vlastním jménem a na vlastní účet, nebo zda bude portál užívat jako zástupce jiného subjektu práva, fyzické osoby nebo organizace, k němuž je zmocněn, tj. cizím jménem a na cizí účet, a takto realizovat digitální služby, viz také kapitola Užívání portálů v zastoupení.

Pro usnadnění výběru zastupovaného subjektu, zejména pokud je uživatel zmocněn zastupovat více či dokonce mnoho subjektů, pomůže předchozí výběr životní role pro zastupování, z níž jednotlivá zmocnění k zastupování vyplývají (rodič, statutární orgán, pověřený zaměstnanec, obecný zástupce apod.). Pro každou takovouto roli, opravňující k zastupování, zobrazí portály výběr subjektů, k nimž je uživatel v dané roli zmocněn. Tato funkce je volitelná, takže uživatel může vidět přímo úplný seznam zastupovaných subjektů, seskupený podle typu zmocnění k zastupování nebo podle role pro zastupování. Ve funkci se uplatní jenom takové role, relevantní pro zastupování, pod nimiž existuje alespoň jedno zmocnění.

Jako další krok v užívání portálu si uživatel musí vybrat právě jeden subjekt práva, jehož jménem a na jehož účet bude portál či federované portál užívat až do okamžiku návratu k užívání portálu vlastním jménem nebo dokonce k „odhlášení“ a k anonymnímu užívání portálu.

Pro usnadnění užívání portálů jménem vlastního nebo zastupovaného subjektu může uživatel využít případné funkce zúžení rozsahu nabízených informací a služeb prostřednictvím role výkonné (viz kapitola Katalog životních rolí), kterou si pro následné užívání/úkon vybere z těch, k nimž je u zvoleného subjektu práva oprávněn a pod kterou si uživatel přeje procházet portály a konzumovat tak relevantní obsah.

Předpokládáme, že pro působení jménem každého subjektu práva má uživatel vlastní uživatelský profil, v rámci, kterého má vlastní kalendář (Kalendář), úložiště (Osobní datové prostory uživatele versus prostory subjektu práva), nástěnku (sekce Nástěnka – ústřední dashboard), přičemž na úrovni federujícího portálu může vidět konsolidovaný přehled vybraných informací za všechny subjekty práva, k nimž má zmocnění. Nutno dořešit přesné hierarchické nebo maticové uspořádání profilů a osobních prostorů uživatele jak v rámci federace portálů, tak v rámci zastupovaných subjektů v každém z nich.

Federující Portál veřejné správy předpokládá další usnadnění práce s ním tím, že bude pro všechny anonymní i autentizované uživatele rozdělen do sekcí (záložek) s předdefinovaným, vybraným obsahem:

• Občan – v této sekci může uživatel vyřizovat záležitosti za vlastní osobu, případně fyzické osoby, jež mu udělily zmocnění (viz kapitola Užívání portálů v zastoupení) nebo ke kterým je zmocněn ze zákona.
• Podnikatel – tato sekce umožňuje uživateli dále vybrat mezi volbou Fyzická osoba – Podnikatel anebo Právnická osoba/organizace. Uživatel má možnost vyřídit všechny agendy podnikání se svojí elektronickou identifikací přímo, pokud je podnikatelem nebo v zastoupení právnických osob nebo jiných organizací nebo v zastoupení jiných fyzických osob podnikajících, k nimž je zmocněn, a to v rozsahu oprávnění konkrétního zmocnění (viz Užívání portálů v zastoupení).

Jednotlivé sekce portálů obsahují sadu přednastavených filtrů a uzpůsobení obsahu (nástěnka, události v kalendáři, nastavení upozornění apod.), který je relevantní pro každý typ subjektu práva, tj. pro fyzické osoby jako občany a pro fyzické osoby podnikající a organizace. Filtry mohou být následně ještě přizpůsobeny, zužovány v kombinaci s životní rolí (viz kapitola Katalog životních rolí). Aktuální vnímání obsahu jednotlivých sekcí je velmi orientační, intuitivní a předběžné – bude muset být teprve předmětem tzv. informační architektury.

Shrnutí: Povinnou funkcí každého portálu je, že musí umožnit přihlášenému uživateli a donutit ho k tomu, aby si vybral vždy právě jeden subjekt práva, jehož jménem a na jehož účet portál/-ly užívá. Doplňkovou a pomocnou funkcí pro usnadnění užívání obsahu a služeb portálu je využití volby role, a to jak jako pomoc pro výběr subjektu (role pro zastupování), tak jako pomoc pro nalezení a vykonání služby a jejího digitálního úkonu (role výkonná).

Po zavedení systému digitálních zmocnění a po jejich spojení s případnými oprávněními na užívání portálu pouze ve vybraných rolích, musí být portály schopny jednotně podporovat toto omezení, tj. jiné role než povolené a jim příslušný individuální obsah (profily, údaje z AIS, zprávy apod.) uživateli nezpřístupnit.

Vícejazyčnost

Portály by měly standardně nabízet vícejazyčné mutace obsahu k češtině například angličtina, němčina apod. Při přechodu mezi portály by si tyto měly jako další informaci předat i jazykové nastavení uživatele. Tedy aby, se nestávalo například, že z portálu s nastavenou anglickou verzí se proklikem dostane do portálu, kde bude nastaven implicitní jazyk čeština.

V případě, že federovaný portál nebude mít danou jazykovou mutaci, tak by o tom měl uživatele informovat a nabídnout mu automaticky alternativní jazykovou mutaci.

Rady (EU) 2018/1724 ze dne 2. října 2018, kterým se zřizuje jednotná digitální brána pro poskytování přístupu k informacím, postupům a k asistenčním službám a službám pro řešení problémů a kterým se mění nařízení (EU) č. 1024/2012.

Minimální požadavek pro vícejazyčnost jsou dvě jazykové sady, lokální, český jazyk a anglický jazyk s možností rozšířit jazykové mutace o další jazyky.

Funkce poskytuje možnost přenosu transakčního kontextu mezi jednotlivými portály (federovaný i federující portál) portály, zejména však informace o subjektu, respektive typu subjektu odpovídající souhrnné roli, kterou si uživatel pro užívání portálu zvolil (Občan, nebo Podnikatel), informace o autentizaci (viz kapitola Autentizace a Single Sign-On), oprávnění k jiným subjektům práva (identifikace subjektu práva a rozsah oprávnění), informace o službě, kterou si vybral či informace o aktuálně zvolené životní události, kterou uživatel řeší/řešil.

Kontextem může být i zvolený jazyk.

Pokud uživatel nepřestupuje do portálu s funkcemi ve stejné bezpečnostní zóně (např. nižší úroveň důvěry – LoA) je odkazovaným portálem vyžádána opětovná autentizace prostředkem požadované úrovně a po jejím provedení přenesení kontextu na cílový portál.

Portály nemusejí mít (a do budoucna nemají mít) autentizované části či zóny, ale mohou kdekoli připustit autentizaci uživatele, takže na místo dvou částí se v nich u jedné společné části jedná o dva způsoby užití – anonymní užití a autentizované užití. Klient/uživatel na základě své volby může kdykoli přecházet mezi oběma způsoby užití, byť za cenu ztráty komfortu a ztráty některých informací.

Jedná se pouze o kontext, který nezakládá pro federující portál povinnost přenášet tyto informace.

Tato oblast se zabývá bezpečnostními aspekty federace portálů. Při federaci portálů je třeba dbát zvýšený důraz na zabezpečení obou stran, tj. federovaného i federujícího portálu. V opačném případě může zranitelnost federujícího portálu znamenat přenesenou hrozbu pro federovaný portál a naopak. U federace se předpokládá federování portálů s různými technickými řešeními, a co nemusí být hrozbou pro federovaný portál, protože zvolené technické řešení není na daný typ zranitelnosti náchylné, může znamenat hrozbu pro federující portál, protože využívá jiné technické řešení a naopak.

Mezi federujícím a federovaným portálem vzniká vztah vzájemné důvěry. Federující portál plně důvěřuje obsahu federovaného portálu a zpřístupňuje ho svému uživateli jako by byl jeho vlastní. Federativní vztah je zajištěn pomocí provázání portálů, u kterého není vyžadována formální registrace federovaného a federujícího portálu (registr portálů) a mohou se federovat libovolné portály, která splňují pravidla pro federaci a jejich techničtí správci se dohodnou na federaci. Federovat se mohou jen portály, které jsou registrované jako kvalifikovaný poskytovatel služeb v Národní identitní autority (NIA).

Všichni registrovaní kvalifikovaní poskytovatelé z oblasti portálů jsou považování za okruh potenciálních federovaných portálů. Taxativní výčet vzájemných vztahů mezi portály není požadován a případná informace o tom, které portály jsou ve vzájemné federaci, se získává vytěžením statistických dat ze vzájemné komunikace.

Obsah federovaného portálu je z federujícího portálu odkazovaný pomocí deeplinků (viz kapitola Data poskytovaná informačními systémy) nebo zobrazovaný skrze centrální komponenty (viz kapitola Centrální komponenty). Za federaci se naopak nepovažuje prosté zobrazení federovaného portálu pomocí vložení do stránky (iframe) a takovéto řešení není povoleno. Vložení stránky pomocí iframe je náchylné ke kategorii útoků nazývaných Clickjacking. Proti těmto typům útoků je možné se částečně bránit vymezením povolených cílů vkládání s využitím direktivy Content-Security-Policy: frame-ancestors. V případě obecné federace portálů nicméně nejsou známé povolené adresy, do kterých může být federující portál “vložen” a tato direktiva nemůže být efektivně uplatněna. Alternativou by mohlo být zřízení registru federovaných portálů, včetně jejich adres a dynamické tvorby obsahu hlavičky Content-Security-Policy, kteréžto řešení nebylo dále zkoumáno.

Požadavky na zabezpečení

U portálů je požadavek na provedení technických i organizačních bezpečnostních opatření pro zajištění bezpečnosti informací odpovídající charakteru informací. Opatření jsou popsána Vyhlášce č. 82/2018 Sb. o kybernetické bezpečnosti.

Pro subjekty, které nespadají pod zákon č. 181/2014 Sb. o kybernetické bezpečnosti, a přesto mají zájem vystupovat jako federovaný portál je požadavek na splnění Minimálního bezpečnostního standardu²¹⁾, který nabízí zjednodušené principy, postupy a doporučení v oblasti kybernetické bezpečnosti právě pro subjekty, které nespadají pod zákon o kybernetické bezpečnosti. Zde je vhodné se zaměřit zejména (ale ne výhradně) na odstavce:

• 2.1 - Plán zavádění bezpečnostních opatření
• 8 - Audit kybernetické bezpečnosti
• 12 - Kybernetické bezpečnostní události a incidenty
• 13 - Požadavky v oblasti aplikační bezpečnosti
• 14 - Kryptografické prostředky
• 17 - Další požadavky

Pro podporu bezpečného vývoje napříč portály, by bylo vhodné, aby vznikla jednotná metodika tvorby bezpečného kódu pro, která bude respektovat mj. specifika řešení portálů a jejich federace.

Následně je zapotřebí aby tvorba portálových řešení tuto metodiku využívala v praxi.

O portálech v kontextu federace se uvažuje zejména jako o internetových stránkách (viz kapitola Co je to portál a jaké funkce jej definují) a je třeba důsledně dbát na specifické zranitelnosti internetových stránek. Nejde jen o ty nejčastější pravidelně uveřejňované v seznamu nejčastějších známých zranitelností v rámci Open Web Application Security Project (OWASP) známé také jako OWASP TOP 10, jako jsou injection útoky, neošetřená deserializace či útoky typu Cross-Site Scripting (XSS), ale také o zranitelnosti specifické a méně časté jako Cross Site Request Forgery (CSRF), Cross-origin resource sharing (CORS), Server-side request forgery (SSRF), zranitelnosti přenosových protokolů a šifrovacích algoritmů používané pro zabezpečení HTTPS komunikace atp.

Všechny části aplikace dodržují metodiky pro vývoj bezpečných webových aplikací (např. metodiky

Technický důsledek

OWASP) a součást vývojové linky je pravidelné testování na zranitelnosti webové části.

Pro zabránění útoku typu Man-in-the-Middle je vyžadováno zabezpečení komunikace webové části portálů pomocí protokolu HTTPS. Zde se předpokládá nejen nasazení šifrované komunikace, ale také především její správná konfigurace, použití certifikátu, který je označen jako důvěryhodný v majoritních prohlížečích a operačních systémech a provádění pravidelných bezpečnostních a penetračních testů. Zvláštní pozornost by měla být zaměřena testům zranitelností webových technologií, a to i na takové zranitelností, které přímo neohrožují technologii, ve které je vytvořen federovaný portál. Ohledně použití kryptografických prostředků je nutné řídit se doporučením NÚKIB²²⁾.

Pro snazší orientaci uživatelů v tom, zda je daný portál důvěryhodný, by bylo vhodné centrální řízení politiky vystavování certifikátů, které by dávalo jistotu, že se jedná opravdu o portál veřejné správy. Tento přístup má také další pozitivní důsledky s ohledem na výstupy indexování a vyhledávání veřejnými vyhledávači, jak je diskutováno v kapitole Centrální správa certifikátů.

Jako adresy portálů (jmenné konvence URL) musí být voleny takové internetové adresy, které jsou jednoznačně identifikující, nejsou vzájemně zaměnitelné a pro uživateli je zřejmé na jakém portálu se nachází a kdo je jeho provozovatelem.

Při zjištění bezpečnostního incidentu (eventuálně porušování této politiky, AP, či dalších pravidel závazných pro provoz sítě a služeb) musí veškeré dotčené subjekty zapojené do federace vyvinout maximální úsilí k odstranění problému, a to podle okolností v nejkratším možném čase. Porušení této zásady bude považováno za porušení politiky ze strany těchto subjektů. O všech bezpečnostních incidentech v rámci federace musí být neprodleně informován operátor federace. Dohled nad bezpečností portálů je zajišťována k tomu určenou centrální autoritou.

Pro potřeby analýzy, v případě zjištění bezpečnostního incidentu, je nutné vytvářet a udržovat nepopiratelnou auditní stopu obsahující veškeré informace, které jsou nápomocné při řešení incidentu. Pro identifikaci incidentu je vhodné implementovat centrální komponentu pro zaznamenávání událostí na portálech, které jsou předmětem federace nebo využívat jedinečné značky a časová razítka identifikující každý požadavek napříč celým federovaným prostorem.

Portál slouží jako průvodce nebo místo vstupu a jako takový není zdrojem zobrazovaných dat. Portály mohou ukládat pouze informace vztahující se k personalizaci portálu a dále data či metadata nutná k provozu portálu.

Pro ztížení identifikace konkrétní osoby portály při ukládání dat využívají principu pseudonymizace s využitím bezvýznamových identifikátorů. Pokud existují údaje uložené v centrální komponentě nebo ZR, jsou tato data využívána a nedochází k jejich duplikaci a ukládání trvalých kopií těchto dat v portálech.

Portály implementují ukládání dat v souladu se

Technický důsledek splněním tohoto požadavku.

Při výměně datových sad je využito stejných principů

Pro potřeby federací dohledu portál poskytuje informace o své dostupnosti.

Pro rychlou reakci v případě bezpečnostních incidentů každý portál, který je součástí federace zveřejňuje aktuální a dostupné administrativní kontakty, a to v Rejstříku ISVS a IS SPUU v RPP.

Výměna zpráv a souborů

Komunikace mezi portály probíhá, s výjimkou předávání kontextových informací (viz kapitola Přenos kontextu návštěvníka mezi portály) s využitím bezpečné a spolehlivé infrastruktury se službou bezpečného přístupu do internetu. Požadavky na bezpečný a spolehlivý přenos informací na komunikační splňuje např. KIVS/CMS.

Předávání datových zpráv a sdílení údajů mezi portály probíhá výhradně formou zabezpečené a šifrované komunikace a pomocí nástroje, který zajistí auditování datových zpráv, centrální dohled, detekci narušení a mechanismy ochrany proti útoku typu zahlcení. U této platformy se také předpokládá, že bude zajištěna dostupnost, důvěrnost a integrita na takové úrovni, aby nedošlo k ohrožení či omezení vzájemně federovaných portálů.

Pro různé typy zpráv se mohou používat různé nástroje. Pro výměny datových sad a souborů mezi federovanými portály se využívá komunikace s využitím eGSB / ISSS, PPDf. Výměna souborů je možná také skrze odkaz do centrální komponenty osobního archivu zajištěný pomocí unikátního přístupového tokenu.

Pro některé centrální komponenty může být systém datových zpráv nevyhovující. Příkladem je funkce federovaného vyhledávání (viz kapitola Technické aspekty vyhledávání informací), u které lze předpokládat, že stávající formát volání požadavek-odpověď ve formě XML pomocí eGSB nesplňuje funkční nebo výkonnostní požadavky a při návrhu centrálního řešení indexování dat pro funkce vyhledávání a nabízení relevantních výsledků vyhledávání přes všechny federující a federované portály, bude nutné definovat technicky jiný systém, stále však se zajištěním výše uvedených parametrů. Toto se netýká jen indexování, ale je možné toto očekávat také pro jiné centrální komponenty.

Autentizace a Single Sign-On

Tato oblast funkcí se zabývá způsobem identifikace a následné autentizace klienta na federujícím a federovaném portálu. Portály nemají mít potřebu vlastní registrace uživatele pro rezidenty České republiky evidované v ROB a pro rezidenty EU, přistupující přes mezinárodní bránu a musejí využívat existujícího mechanismu identifikace a autentizace klienta, jinak se u nich nemohou uplatnit prvky federace.

Identifikace a autentizace uživatele je řešena s využitím Národního bodu pro identifikaci a autentizaci (NIA) zřízeného ZoEI, který zároveň stanovuje pravidla pro účastníky procesu elektronické identifikace. Je doporučeno používání řešení vybudovaných na všeobecně užívaných standardech např. na SAML2 (akutálně využíváno NIA), či z rodiny OAuth/OpenID Connect (aktuálně využívá např. BankID).

V případě, že je uživatel již autentizovaný přes NIA na federujícím nebo federovaném portálu, tak v momentě přechodu mezi jednotlivými portály může plynule přecházet bez nutnosti opětovného přihlášení – to zajistí nerušený a příjemný uživatelský zážitek. Plynulý přechod je zajištěn využitím principu Single Sing-On (SSO). Pro usnadnění přenosu informace o přihlášení bude využito kontextu, viz kapitola Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta). Odkazovaný portál by s využitím NIA měl uživatele automaticky přihlásit – tzn., že by přechod mezi portály měl být pro uživatele bezešvý.

Je potřeba kontrolovat oprávnění k přístupu k informacím, zda nedošlo kompromitaci URL na FE. Portál musí validovat autenticitu každého požadavku přicházejícího pomocí deeplinku.

Portál musí validovat parametry/data přicházející

Technický důsledek

pomocí deeplinku a předpokládat, že mohou obsahovat škodlivá data.

Pokud není uživatel ve stejné bezpečnostní zóně (autorizace, LoA) je požadováno opětovné ověření a po jeho provedení přesměrování na cílový odkaz.

Přestože NIA nemusí být jedinou autentizační metodou portálů, je z důvodu efektivního využívání zdrojů vhodné, aby byla primární metodou autentizace. Minimálně po přechodnou dobu (pozn. existují také portály jejichž uživatelé nemohou být identifikováni a autentizováni pomocí NIA a pro tyto budou pravděpodobně vždy existovat další metody autentizace) může metod autentizace existovat více a NIA, přestože je jedinou podporovanou autentizační metodou v rámci federace, je jen jednou z nich.

vykládán tak, že digitální úkony lze činit pouze prostřednictvím ISVS, umožňujícího prokázání totožnosti uživatele služby s využitím elektronické identifikace. Tedy, formálně vzato by skutečnost, že k takovému prokázání došlo v jiném ISVS mohla realizaci této funkcionality bránit.

Pro překlenutí přechodného období, kdy nebude možné u některých federovaných portálů nastavit NIA jako primární autentizační metodu, je vhodné informovat odkazovaný portál, že uživatel již je autentizovaný pomocí NIA a ten tak má jako první autentizační metodu zvolit právě NIA.

Portály implementují řešení jednotného odhlášení Single-Logout (SLO). Při odhlášení z jednoho portálu dojde k automatickému ukončení sezení všech portálů (v závislosti na použité technologii, tj. pokud se jedná o portály stavové udržující si uživatelské sezení). Pokud není implementováno jednotné odhlášení (SLO) s využitím zadního kanálu, je vhodné, aby se každý další portál otevíral v novém panelu prohlížeč z toho důvodu, že je nutné implementovat hromadné odhlášení ze všech portálů. Aby se zamezilo situaci, kdy se uživatel odhlásí z jednoho portálu a na ostatních zůstane přihlášený.

Pokud je uživatel přihlášený a přechází mezi portály, je nutné respektovat LoA. NIA ověří, že se úroveň LoA vyhovuje předchozímu přihlášení. Pokud není možné využít principu Single Sing-On (tj. přihlášení bez opětovného zadání přihlašovacích údajů) a je nutnosti opětovného ověření (nejen z důvodu nedostatečné úrovně LoA) je třeba využít principu Same Sign-On skrze NIA a následně uživatele přesměrovat na původně odkazovaný obsah.

Obrázek 9: Graficky reprezentovaný rozdíl mezi principem Same Sign-On a Single Sign-On

Výše uvedený princip Single Sign-On funguje pouze v případě, že si uživatel nezakázal toto chování v osobním účtu na portálu NIA.

Tato kapitola se zabývá federací portálů v rámci vybraných zemí, které spadají do EU, ale i mimo ni. Mezi vybrané země, které byly součástí nabídky, patří Finsko a Dánsko a v průběhu realizace dokumentu k nim bylo přidáno i Norsko, jakožto zástupce mimo EU s velmi vyspělou digitální infrastrukturou. Se zástupci jednotlivých zemí, respektive zástupci “digitalizace” bylo realizována série workshopů, které byly podpořeny strukturovanými formuláři, jež byly cíleny na jednotlivé oblasti portálů a jejich míru digitalizace a federace.

Cílem workshopů bylo prodiskutování a následné zapracování popisů vzorů zahraniční praxe, které byly analyzovány za účelem porovnat stav v České republice a použít pak jejich vhodné části jako významný zdroj pro inspiraci při zpracování návrhu pravidel federace portálů v České republice.

Po diskuzích se zástupci z daných zemí se ukázalo, že umístění těchto zemí na vyšších příčkách v žebříčku DESI v sub dimenzi 5 (digitální veřejné služby z roku 2020 hodnoceny lépe než ČR) nemusí vždy znamenat, že v dané zemi existuje federovaná síť portálů v úlohách ústředních vstupních bodů pro samoobslužné služby, propojené s portály jednotlivých agendových úřadů, případně územních úřadů. Jinými slovy ne všechny státy, které jsou umístěny v žebříčku nad Českou republikou, jsou vhodnými zdroji pro přenos best practice.

V Dánsku je hlavním centrálním portálem pro občany portál „borger.dk“. Úlohou tohoto portálu je poskytnout občanům on-line nabídku služeb celé státní správy.

Na portálu jsou k dispozici základní informace o všech službách, grantech a povinnostech, které jsou pro občany relevantní. Součástí jsou také odkazy na doplňující informace na úrovni příslušných organizací, odkazy na příslušné předpisy a odkazy na příslušná digitální samoobslužná řešení.

Dánský model v současnosti nepředpokládá propojení řešení se službami soukromého sektoru.

Portál byl vyvinut a je udržován Agenturou pro digitalizaci jménem vlády a zajišťuje správu na úrovni státu, regionů a municipalit. Ze strany administrátora portálu je zajištěna pravidelná aktualizace informací poskytovaných na portálu a na zajištění podobného formátu informací. Borger.dk pojme přibližně 800 článků a odkazy na 2 000 digitálních služeb. Všechny články s informačními a digitálními službami jsou označeny klíčovými slovy, což usnadňuje jejich vyhledávání a porovnávání.

Struktura

Dánské řešení definuje jeden centrální přístup pro občany k digitálním službám a jednotný způsob, jak najít všechny informace o všech veřejných službách.

Jak bylo zmíněno výše, portál nabídky služeb se přizpůsobuje uživateli. A to jednak po jeho autentizaci, kde se uživateli zobrazí na přehledovém dashboardu (moje stránka) informace z jeho municipality, tak informace příslušící k jeho stavu, dětem nebo majetku. Personalizace funguje ale i bez autentizace třeba jen výběrem jazykové mutace stránek. Pokud je například vybrán jazyk angličtina, tak se nabídka přetvoří jako nabídka pro cizince. Základní struktura dánského systému je tvořena 3 pilíři, respektive portály. Borger – Hlavní portál, Portál občana

Obrázek 10: Úvodní stránka dánského portálu borger.dk

Borger.dk představuje jednotný bod, který shromažďuje veřejné informace a poskytuje samoobslužný portál, založený na životních událostech (ty jsou popsány v další kapitole).

Lifeindenmark.dk je součástí společného veřejného portálu v Dánsku s názvem borger.dk. Lifeindenmark.dk je anglický web pro obsah borger.dk. Má svou vlastní adresu URL, takže lze obsah nabízet přímo cílovým skupinám cizinců, kteří přijíždějí do Dánska pracovat. Texty na tomto webu jsou udržovány editory borger.dk a přispívá do nich i řada veřejných orgánů.

Jako součást borger.dk existuje „Moje stránka“, kde mají občané přístup k vybraným údajům o sobě. Virk – byznys portál

Obrázek 11: Byznys portál Virk.dk

Dánský byznys portál nabízí informace o obchodu a službách, uživatel se snadno a rychle dostane jak k informacím o DPH, tak aktuálním opatřením týkajících se například Covid-19, nebo ale také jak nahlásit transport nebezpečného nákladu.

Obsah je možno procházet jako nepřihlášený, tak jako přihlášený uživatel s tím, že se zobrazené informace budou uzpůsobovat automaticky preferencím přihlášeného uživatele. V tomto případě bude uživatelem zejména podnikatel, majitel společnosti nebo pověřený zaměstnanec.

Stěžejní na portálu je samoobsluha, která řadí služby podle oblíbenosti ve vrchní části stránky:

− Výroční zpráva, jak reportovat výroční zprávu společnosti digitálně

− Začít podnikat, jak začít s podnikáním a jak získat registrační číslo

− Formulář faktury, jak zasílat faktury a jaké náležitosti je třeba splnit

− Změna údajů společnost, jak zveřejnit informace o změnách ve společnosti

− NemRefund - nemocenské dávky, jak požádat o náhradu nemocenských dávek

− Ukončení podnikání, jak registrovat ukončení podnikatelské činnosti

− NemRefund - dotace na zaměstnance, jak požádat o dotaci na mzdy

− Výroba, jak vytvářet, upravovat nebo zavírat výrobní jednotky

− NemRefund - příspěvek v mateřství, jak požádat o mateřské dávky

− Nezisková organizace, jak zaregistrovat dobrovolnické sdružení

− Přihlášení k DPH

− Obnova podnikatelské činnosti, jak zažádat o obnovení podnikatelské činnosti

Pod samoobsluhou portál nabízí aktuální témata, jako v současnosti veškeré potřebné informace ke Covid-19, dále na stránce jsou témata – Obchod a služby, Životní prostředí, Personalistika, Bezpečnostní statistika, Doprava, Korporace a Ekonomika.

Sundhedsportal – portál zdraví

Je to portál jak pro občany, tak pro specialisty poskytující služby v této oblasti. Portál nabízí všechny informace relevantní v této oblasti, konkrétně pak lékařské záznamy, informace pro dárce, předepsané léky ale také výsledky testů na Covid-19. Pro rodiče pak portál nabízí zdravotní karty svých dětí mladších 15-ti let.

V Dánsku je zdravotnictví bezplatné podobně jako v ČR, odvody ale na něj jsou v rámci rozpočtů, občan na něj nepřispívá přímo jako v ČR.

Obrázek 12: Portál zdraví Sundhedsportal.dk

Dále existují stránky jednotlivých agendových úřadů, které poskytují další informace podobně jako v ČR.

Zajímavé jsou stránky municipalit, u kterých počet poklesl po reformě před 15 lety z 275 na 98. Každá municipalita v Dánsku má v rozmezí mezi 30 a 50 tisíci rezidenty. Stránky municipalit mají vlastní standardy, ale nejsou striktní. Existují pak soukromé subjekty, které municipalitám nabízejí správu těchto stránek. Tyto stránky po přihlášení dávají přehled svým rezidentům z oblasti bydlení, školství, zájmových kroužků, službám i k jejich platbách. Stránky jsou potom i přímo dostupné svým rezidentům v sekci moje stránka na hlavním portálu.

Obrázek 13: Náhled na portál dánské municipality

Popis řešení z pohledu funkcionalit

Seznam životních událostí

Volba v této kategorii je i zvolený jazyk, pokud bude vybraný jazyk angličtina, tak se nabídka uzpůsobí a je více orientovaná na cizince (expaty).

Dále jsou zde tři specifická témata (která ovšem platí nejen pro cizince), která jsou předvybrána pro cizince, a to Před stěhováním do Dánska, Příjezd do Dánska a Stěhování se z Dánska. Tyto jsou předřazené dalším, které jsou pak zobrazeny dále, jako 11 dalších životních tematických oblastí.

Bydlení a stěhování, uvedené dvěma životními událostní a to “Moje nové bydlení” a “Nákup nemovitosti", další jsou témata stěhování, nákup nemovitosti, poplatky za energie a služby, dánská příslušnost, pronájem, podpora bydlení, služby pro nově příchozí cizince do Dánska, praktické rady při stěhování do a z Dánska, případně stěhování v rámci Dánska Práce, uvedené dvěma životními událostní a to “Pracovní doba” a “Příspěvek na dovolenou", další jsou témata pracovní povolení, hledání práce, práva zaměstnance, rovnost v pracovním prostředí, bezpečnost práce, pendleři a lidé pracující na moři Rodina a děti, uvedené dvěma životními událostní a to “zařízení péče o děti” a “svatba v Dánsku", další jsou témata adopce, přeshraniční rodina, podpora rodiny, mít děti a adopce, zařízení péče o děti a páry IV) Ekonomika a daně, uvedené dvěma životními událostní a to “Jak funguje dánský daňový systém” a “Daňové záležitosti", další jsou témata sociální benefity, dánský daňový systém – pojištění

Škola a vzdělávání, uvedené dvěma životními událostní a to “Základní vzdělání” a “Vyšší vzdělání", další jsou témata Dánský vzdělávací systém a vzdělávání dospělých Zdravotnictví, uvedené dvěma životními událostní a to “Karta pojištěnce” a “Lékařská péče", další jsou témata Dánský systém zdravotní péče, Lékařské ošetření, Zdravotní pojištění, Domovy s pečovatelskou službou a péče o starší, Práva pacientů, Prevence zdraví, Úmrtí a pohřby, Předpisy na léky vydané v jiných zemích EU a EAA, Dánské národní kontaktní body a Lékařská pohotovost Cestování a doprava, uvedené dvěma životními událostní a to “Řidičský průkaz” a “Doprava v okolí", další jsou témata Práva cestujících, Doprava pro hendikepované, Motorová vozidla, Jak získat řidičský průkaz v Dánsku Důchod, uvedené dvěma životními událostní a to “Státní penze” a “Invalidní důchod", další jsou témata

Mezinárodní důchod, Senioři v Dánsku, ATP Livslang Systém, Flexibilní zaměstnání, Částečný důchod, Krytí zdravotního pojištění, když žijete v zahraničí jako důchodce, Daň z dánských a nedánských důchodů a Důchodový systém pro státní zaměstnance

Právní systém, uvedené dvěma životními událostní a to “Dvouletá záruka” a “Volby v Dánsku", další je téma Veřejný systém stížností spotřebitelů Volnočasové aktivity a zapojení se do komunity, uvedené dvěma životními událostní a to “Kulturní a společenské aktivity” a “Fakta o Dánsku", další jsou témata Výuka dánského jazyka a Top 25 Slovník oficiálních termínů Digitální služby, uvedené dvěma životními událostní a to “Digitální pošta” a “NemID", další je téma Váš bankovní účet, vybraný pro platby s veřejnou správou.

Rejstříky

Dánsko poskytuje veřejná data zdarma. Rest API a bulk data download umožňují přístupy k datům z registrům, nejen veřejným portálům, ale i soukromým subjektům. Výjimkou jsou data, které spadají pod ochranu GDPR, nebo specifická data, které jsou pak poskytována jen schváleným subjektům. Databázové registry jsou ve správě ministerstev, podle jejich agendy (katastr, adresy…).

Obrázek 14: Portál agregující dánské rejstříky

Federace služeb

Z pohledu federace má Dánsko několik elementů. Prvně je to single sign on (SSO), které přenáší identitu uživatele napříč zmíněnými portály. Dále je to federování obecných informací z municipalitních portálů/stránek do Portálu občana, a naopak podle trvalého bydliště uživatele. Toto bylo zmíněno v popisu struktury, stránky municipalit po přihlášení dávají přehled informací svým rezidentům z oblasti bydlení, školství, zájmových kroužků, službám i k jejich platbách. Stránky jsou potom i přímo dostupné svým rezidentům v sekci moje stránka na hlavním portálu borger.dk.

Autentizovaný přístup

Některé digitální služby jsou vizuálně integrovány do portálu prostřednictvím iFrames. Protože všechny dánské veřejné orgány jsou součástí národní infrastruktury jednotného přihlášení (NemLog-in), občané, kteří jsou přihlášeni k portálu, mají okamžitý přístup k digitálním službám integrovaným přímo do portálu nebo přístup prostřednictvím odkazů na jiných domovských stránkách poskytovatelů daných služeb.

Zejména se jedná o přístup k službě digitální pošty, informacím, které jsou o uživateli vedeny v rejstřících, elektronický mandát, daňové přiznání, komunitní a zdravotní služby jako předepsané léky, výsledku testů na Covid19.

Bez přihlášení je pak možno procházet životní události a vybrané situace, viz výše, obecné informace a služby spojené s přihlášeným uživatelem.

Obrázek 15: Dánsko: ukázka nástěnky přihlášeného uživatele

Autentizace

Autentizace probíhá přes NemLog-in stránku a systém přihlašování vznikl spolupráci mezi obcemi, regiony a státem. Jedná se o běžné řešení pro přihlášení, které umožňuje přístup k samoobslužným řešením veřejného orgánu. To znamená, že se uživatel přihlásí pouze jednou, aby se autentizoval u všech různých samoobslužných řešení veřejného orgánu. Po přihlášení na jiném zařízení je schopen pokračovat v započaté práci. Řešení spravuje Agentura pro digitalizaci. Pokud uživatel použije řešení z veřejných webů, jako je borger.dk nebo skat.dk, bude přesměrován na běžnou přihlašovací stránku (obrázek níže). Ověření uživatele je pomocí dvou faktorové autentizace. Po přihlášení se automaticky vrátí na domovskou stránku, ze které přišel. Přihlašuje se pomocí svého NemID nebo digitálního podpisu.

NemID vzniklo ve spolupráci státu s bankovním sektorem. NemID bylo v minulosti poskytováno na požádání, nyní je poskytováno každému občanu Dánska automaticky při překročení věkové hranice 15 let.

Typy identifikace:

• NemID pro občana – jedno NemID – číslo sociálního zabezpečení,
• Byznys ID, pro podnikatele a majitele společnosti,
• ID pro specialisty – specifické ID profesionály v oblasti zdraví registrované nemocnicemi,
• ID pro pověřené osoby společnosti, například zaměstnanec účtárny, který reportuje data společnosti měsíčně/kvartálně/ročně do registru.

Obrázek 16: Přihlašovací stránka do dánského portálu NemID

NemKonto

Pro konzumaci obsahu dánské skupiny portálů musí každý rezident v Dánsku disponovat alespoň jedním dánským bankovním účtem, aby získal NemKonto. NemKonto je účet, na který se přímo převádějí platby od veřejných orgánů. Tento základní účet lze označit jako NemKonto. NemKonto je běžný bankovní účet, na který lze přímo převádět platby od veřejných institucí (např. vrácení daní, dětské subvence, studentské půjčky a dávky v nezaměstnanosti).

NemKonto je možno snadno změnit, pokud rezident například změní banku. Běžný účet lze převést na NemKonto buď bankou, nebo přímo rezidentem – pokud má NemID.

Digitální pošta

Digitální komunikace s veřejnými orgány funguje pomocí stejného typu zpráv (struktura, obsah, náležitosti), který úřady poskytují v papírové podobě. Do digitální pošty spadají veškeré zprávy z nemocnice, výpisy z důchodů, informace o státní podpoře vzdělávání (SU), změny dávek v bydlení, odpovědi na žádosti o péči o děti, dopisy od dánské daňové a dopisy celní správy (SKAT) atd.

Obrázek 17: Schéma fungování dánské digitální pošty

Digitální pošta je přístupná na kterémkoli ze dvou zabezpečených webů. Jsou to borger.dk a e-Boks.dk. Digitální poštu od veřejných orgánů musí rezident kontrolovat alespoň na jednom z těchto dvou webů.

Elektronický mandát

Systém umožňuje uživateli dát jedné nebo více osobám pouze pro přístup ke čtení digitální pošty. Toto je možno nastavit po přihlášení k borger.dk nebo e-Boks.dk, kde je možno ostatním udělit práva ke čtení. Případně je možno osobně vyřídit v občanském servisním středisku (borgerservice). Pro autorizaci je nutno znát občanské registrační číslo osoby, které má být umožněn přístup, vybrat, který příspěvek má osoba číst a předat heslo osobě, které uživatel chce udělit přístup.

Daňové přiznání

Ministerstvo financí má na zodpovědnost mimo jiné daňové přiznání fyzických osob. Díky zákonu o přístupu k technickému schématu, má ministerstvo přístup do všem veřejným registrům, reportům od zaměstnavatelů, výpisy pojišťoven, bank a hypotečních ústavů.

Díky těmto možnostem je daňové přiznání každý rok automaticky připraveno ministerstvem a uživatel je na tuto skutečnost upozorněn jeho digitální poštou. Od upozornění má jeden měsíc na kontrolu a případné doplnění daňového přiznání. V praxi se nestává často, že by bylo něco v předpřipraveném daňovém přiznání potřeba upravit. U osob podnikajících je povinností se nahlásit. Pro tyto osoby ministerstvo vede daňový systém, který umožnuje komunikaci přímo s daňovým úřadem

Roadmapa do budoucna

V současné době, podobně jako další státy, Dánsko analyzuje problematiku SDG. To bude jedno z velmi komplexních témat k řešení, protože současné řešení je navrženo pouze pro dánské rezidenty.

Do budoucna musí veřejný sektor úzce spolupracovat s dánskou podnikatelskou komunitou, organizacemi zúčastněných stran atd., aby vytvořil základ pro flexibilní a adaptivní společnost připravenou na stále více digitalizovaný svět. Na vývoji se mohou podílet i samotní uživatelé a to jednoduše, že budou sdílet své postřehy a nápady s admin@borger.dk.

Závěry a doporučení pro ČR

Poučení pro ČR

• Registry poskytují data nejen portálům, ale i veřejnosti přes rest API.
• Portály by měly být přehledné svou strukturou (3 základní portály).
• Federace by měla v sobě zahrnovat i SDG, v případě Dánska je model zaměřen jen na rezidenty a přechod na SDG bude náročný.
• Automatické poskytování ID pro přístup do portálového systému.

Doporučení pro ČR

• Vytvoření obdoby Portálu Zdraví.
• Automatizované generování přístupových údajů do portálu občana po dovršení stanovené věkové hranice, při zachování osobního ztotožnění při převzetí identifikačního prostředku. (Máme v podobě eOP).
• Zaměření se na uživatele, hodnocení uživatelů Dánského systému je dle našich zahraničních expertů velice pozitivní, oceňují, že systém pracuje dobře, je velice dobře vyvážen a nikoho neznevýhodňuje.

Webová služba Suomi.fi (společný portál pro občany a společnosti) pomáhá a vede uživatele při řešení každodenních záležitostí s orgány veřejné správy a organizacemi obecného zájmu. Suomi.fi je katalog služeb poskytovaných úřady a službami obecného zájmu. Na webu Suomi.fi uživatel najde praktické pokyny pro různé způsoby využití služeb v každé lokalitě ve Finsku a požadované kontaktní údaje. Některé informace a služby jsou přístupné veřejnosti bez přihlášení, jiné vyžadují autentizaci.

Portál Suomi.fi zahrnuje základní informace a odkazy na všechny klíčové služby eGovernmentu v zemi (centrální, regionální i místní úroveň) s tím, že některé služby jsou poskytovány/nabízeny přímo v portálu a jiné jsou zprostředkovány poskytnutím odkazu na portál relevantní instituce, která je zodpovědná za danou službu. Portál poskytuje služby ve dvou jazycích, povinně finsky a švédsky, v některých případech anglicky.

Míra digitalizace služeb poskytovaných obcemi se výrazně liší. Ve velkých obcích, městech, například v Helsinkách, může uživatel přistupovat ke službám on-line pomocí Suomi.fi autentizace s tím, že služby obce jsou poskytovány na vlastním portálu služeb obce. V menších obcích je běžné, že neexistuje jasná integrace do portálu Suomi.fi, protože nemusí existovat konkrétní portál služeb, ale ke službám se přistupuje jinými prostředky.

Uživatel na portálu Suomi.fi minimálně získá informaci o tom, kdo danou službu poskytuje a relevantní kontakt.

Provozovatelem je Finská digitální agentura, která má na 800 zaměstnanců v 36 finských městech. Cílem je poskytovat digitální služby, zabezpečit dostupnost dat a nabízet uživatelům služby k řešení jejich životních událostí a vybraných situací. Platforma je postavena na Open source kódu a vývojové týmy, které jsou outsourcované od různých dodavatelů, pracují propojeně a používají DevOps model. Bezpečnost je pak dozorována nezávislou auditorskou společností. Hosting pak poskytuje státní ICT centrum Valtori.

Struktura

Suomi.fi poskytuje informace a e-služby, které je možno použít, pouze pokud se uživatel v Suomi.fi autentizuje pomocí svých osobních identifikačních tokenů. K těmto službám je možno se přihlásit buď na domovské stránce Suomi.fi, nebo prostřednictvím nabídky viditelné na každé stránce.

Portál poskytuje čtyři základní funkce: informace a služby, zprávy, elektronický mandát a registry, které jsou popsány níže.

Není uvažováno s nativními (mobilními) aplikacemi, které jsou připravované pro různé platformy individuálně

Obrázek 18: Úvodní stránka finského portálu suomi.fi

Portál Suomi.fi má v sobě rovněž přímo integrován portál obchodních (podnikatelských) služeb EnterpriseFinland.fi, který ještě v nedávné době fungoval samostatně.

Součástí digitální infrastruktury je platforma interoperability, která obsahuje různé způsoby, jak definovat interoperabilní datový obsah. Platforma se skládá ze slovníků, kodeků a datových modelů potřebných pro datové toky a další správu dat. Je k dispozici zdarma, a to pro orgány veřejné správy, tak i pro soukromý sektor.

Další podpůrné portály

Moderní blog suomidigi.fi spravovaný Finskou digitální agenturou o aktualitách veřejné správy je k dispozici přímo i jako mobilní aplikace.

Zdravotní portál omaolo.fi nabízí služby jako jsou periodické upozornění na zdravotní služby jako je prohlídka u obvodního lékaře, zubaře a zdravotních odborníků dle osobních problémů. Dále je k dispozici elektronická zdravotní prohlídka, programy koučování psychické pohody, kontrola COVID-19 a jiné digitální služby.

Elektronický mandát

V rámci aplikace pro autentizaci je možno zmocnit jinou stranu pomocí elektronického mandátu, aby jednala jménem uživatele, jeho společnosti nebo organizace. Lze například udělit zmocnění jiné osobě k vyzvednutí léků na předpis z lékárny nebo uživatelově účetní agentuře pro správu daňových záležitostí jeho společnosti.

Obrázek 19: Schéma fungování služby elektronického mandátu ve Finsku

Suomi.fi-elektronický mandát je služba pro správu a spolehlivé ověření oprávnění, mandátu nebo práva osoby nebo organizace používat digitální služby jménem jiné osoby nebo organizace bez ohledu na čas a místo.

Obrázek 20: Finsko: ukázka práce s mandáty v rámci služby elektronického mandátu

Služba přináší podstatné úspory času a nákladů pro občany, kdy není třeba vypisovat a spravovat mandáty papírově a ani je není třeba fyzicky vystavovat. Služba se ujala velice v soukromém sektoru, který tuto službu stále častěji využívá. Úspora nákladů odhadovaná pro organizace ve Finsku je 6–10 EUR za jednu transakci ve srovnání s papírovou verzí.

Obrázek 21: Schéma fungování elektronického mandátu v kontextu okolních registrů a podpůrných systémů

V číslech, elektronický mandát se používá se ve více než 130 různých digitálních službách ve Finsku. Všech více než 800 finských lékáren přijímá digitální mandáty také při fyzických transakcích přes přepážku. Měsíčně to dělá více než 5 milionů autorizačních dotazů. V současnosti (květen 2021) se monitoruje 20 milionů elektronických mandátů vytvořených občany a společnostmi na národním portálu Suomi.fi. Odhaduje se, že tato čísla během roku 2021 nadále porostou.

Obrázek 22: Ukázka udělení mandátu v rámci služby finského elektronického mandátu

Elektronický mandát se neustále vyvíjí. V tomto odstavci uvádíme plánované funkce. V dalších letech je plánováno rozšíření mandátu na sdružení, poskytovatele služeb, pro zahraniční společnosti a cizí občany (integrace do nové služby elektronické identity pro cizí občany) a v poslední řadě integrace nového registru, který umožní samoobslužnost pro daňové služby.

Rejstříky

Historie rejstříku ve Finsku sahá až do roku 1960. Od té doby se samozřejmě vyvinuly až do dnešní podoby. V rejstřících je možno kontrolovat, jaké informace o uživateli jsou zaznamenány v různých registrech orgánů. Tyto informace by měly být aktuální, pokud ne, uživatel může upozornit odpovídajícího úředníka.

Rejstříky poskytují přehled o následujících oblastech:

• Osobní údaje jako je třeba adresa, a odkazy na změnu adresy nebo jména
• Pozemkový informační systém, složený z informací v katastru nemovitostí a rejstříku titulů a hypoték pokrývajících celou zemi. Zobrazené údaje nelze použít k prokázání vlastnictví nemovitosti. K tomu je potřeba oficiální výpis a certifikát z Pozemkového informačního systému
• Finský obchodní registr, kompilace registrovaných rolí uživatele ve společnostech a organizacích. Role jako například soukromý podnikatel, člen představenstva, generální ředitel, partner, auditor anebo pracovník prokuratury
• Registr vozidel, kompilace klíčových údajů zadaných do registru o vozidle a řidiči.
• Registr řidiče, kategorie řidičského průkazu a stavu řidičského oprávnění
• Lodní registr, podrobnosti o všech plachetnicích a motorových člunech s délkou trupu nejméně 5,5 metru a o lodích s výkonem motoru nejméně 15 kW (více než 20 koňských sil) a o dalších motorových plavidlech, jako jsou vodní skútry, a také na plavidla ve vlastnictví státu a místních orgánů
• Důchodový registr, přehled odvodů na pensijní pojištění ze zaměstnání a nabídka služeb poskytovatelů služeb pensistům
• Registr vzdělání, právo na studium a přehled ukončených studiích
• Keski knihovna, regionální registr pro střední Finsko
• PIKI knihovna, regionální registr pro region Pirkanmaa

Federace služeb

Autentizovaný přístup

Autentizace pomocí různých identifikačních tokenů Suomi.fi autentizace umožňuje přihlásit se ke všem finským e-službám veřejné správy, jejichž použití vyžaduje silnou autentizaci. Jednorázové přihlášení umožňuje využívat všechny služby, které používají autentizaci Suomi.fi, aniž by se muselo přihlašovat jednotlivě pro každou službu.

Jedna relace přihlášení je platná po dobu 32 minut. Je možno se také odhlásit ze všech služeb současně. Jednorázové přihlášení není možné u identifikačních tokenů z jiných zemí ani u finského autentizační aplikace.

Podobně jako v Dánsku je možno přistoupit k výše a níže zmíněným službám digitální pošty, informacím, které jsou o uživateli vedeny v rejstřících, elektronickému mandátu, zdravotním službám a platbám.

• Uživatel po autentizaci na webu Suomi.fi může se stejnou autentizací přejít na služby jako MyTax nebo e-služby Kely přímo z webu Suomi.fi. Díky tomuto jednorázovému přihlášení se nemusíte zvlášť přihlašovat k těm e-službám, které používají autentizaci Suomi.fi.
• V zemi je stále možné se do agendových a územních portálů přihlásit napřímo, bez nutnosti využívat centrální portál Suomi.fi. Pro uživatele není rozdíl, jakým způsobem se přihlásí, vidí stejné služby. To se může lišit u jen úzce specifikovaných informací, jako například vystavení dokladů nebo při přístupu ke zdravotním údajům.

Obrázek 23: Finsko: ukázka nástěnky přihlášeného uživatele

Autentizace

Suomi.fi autentizace je sdílená identifikační služba e-služeb veřejné správy ve Finsku (SSO). Používá se v těch elektronických službách orgánů, ve kterých musí být uživatelé spolehlivě autentizováni. Každý občan ve Finsku má svůj vlastní účet Suomi.fi. Finsko používá národní ID, které nepodporuje v současnosti evropské. Logikou vývoje portálu Suomi.fi je připojení všech celostátních služeb k účtu Suomi.fi. Když se na webu/portálu Suomi.fi uživatel autentizuje, může se stejnou autentizací přejít např. na služby jako MyTax přímo z webu Suomi.fi. Díky tomuto jednorázovému přihlášení se uživatel nemusí zvlášť přihlašovat k těm e-službám, které používají autentizaci Suomi.fi.

Suomi.fi autentizace obsahuje seznam identifikačních tokenů, které lze vybrat (viz obrázek níže).

Obrázek 24: možnosti autentizačních metod ve Finsku

• Po provedení autentizace ze strany uživatele, probíhá používání e-služeb v zabezpečeném prostředí. Metody autentizace jsou finské kódy on-line bankovnictví, certifikát nebo mobilní certifikát. Cizinci mohou používat identifikační tokeny z jiných evropských zemí schválených pro přeshraniční identifikaci nebo aplikaci finské autentizace, pokud e-služba povolila jeho použití.

Bezpečnost

Bezpečnostní model portálu je založen na následujících pravidlech:

• Veškerá data mezi portály jsou přenášena na úrovni backendu s využitím národní služby pro výměnu dat (service bus) implementované pomocí řešení X-Road. Nejsou žádné výjimky, které by vynucovaly komunikaci mimo X-Road, ani které by povolovaly přímé volání portálu a služeb bez jeho využití.
• Národní službu pro výměnu dat mají federovanou s ekvivalentní estonskou službou a využívají federovaného bezpečnostního modelu.
• Nemají specifický bezpečnostní standard pro portály. Řídí se obecnými národními bezpečnostními standardy, jak na úrovni služeb, tak i infrastruktury.
• Stav bezpečnosti se kontroluje na různých úrovních např. při vývoji, portály jsou auditované a probíhají nad nimi penetrační testy (např. Na OWASP TOP 10 zranitelnosti). Bezpečnostní incidenty jsou analyzované z audit logů a pro zvýšení bezpečnosti provozují také veřejný bug bounty program. • Portál je připojen do národního dohledového centra

Zprávy

Funkce umožňuje upozornit orgány, že od nich uživatel chce dostávat jakoukoli poštu namísto papírové pošty. Na jeho e-mail bude zasíláno oznámení o nových zprávách. Zprávy je možno si přečíst přes Suomi.fi nebo v mobilní aplikaci Suomi.fi. Zprávy Suomi.fi představují spolehlivý způsob komunikace s úřady a dalšími organizacemi, které službu využívají.

• Organizace uživateli mohou zasílat oznámení o rozhodnutích a dalších dokumentech. Můžete také posílat zprávy a přílohy organizacím, které tuto službu přijaly. Je třeba upozornit, že všechny orgány tuto službu dosud nepřijaly. Používání zpráv probíhá v zabezpečené komunikaci, protože všechny zprávy a jejich přílohy jsou přenášeny v šifrované podobě.
• Zprávy Suomi.fi lze používat na počítači nebo mobilním zařízení s webovým prohlížečem a připojením k internetu. Je doporučeno používat nejběžnější prohlížeče a nejnovější verze prohlížečů. Pro mobilní zařízení lze také použít mobilní aplikace, které je možno stáhnout do zařízení Android a iOS. Zprávy jsou ukládány bez limitu velikosti dat a počtu zpráv. Uživatel nemá právo mazat. Zprávy se mažou po pěti letech, nebo podle požadavku vyplývajících z právní úpravy. Při mazání příloh dostává uživatel notifikaci.

Platby

V současnosti je tato tématika plateb obsažena na portále jednak jako návod pro uživatele a firmy, kde vysvětluje možnosti a specifika plateb a fakturace ve Finsku.

• Portálová část spravována Státní pokladnou pak umožňuje přístup občanům k předpřipravené formě daňového přiznání podobně jako v Dánsku.
• Platby za služby nejsou řešeny v rámci portálu, ale ve Finsku jdou tyto platby přímo adresovány do Internetového bankovnictví daných uživatelů.
• Do budoucna (cíl do roku 2023) se oblast plateb bude rozšiřovat, aby umožňovala i platby na portálu Suomi.fi.

Seznam životních událostí

Suomi.fi nabízí široké spektrum životních situací. Dělí je do devíti základních kategorii, které jsou odlišné pro občana a pro firmy a společnosti.

Životní tematické oblasti a vybrané situace občana:

Žít společně a mít rodinu, kde jsou další podkategorie jako Žít společně, Mít děti, Smrt blízkého člena rodiny, Vítejte v dospělosti! a Rozvod nebo Oddělení od partnera Sociální pojištění, kde jsou podkategorie jako Služby pro osoby se zdravotním postižením, Služby pro seniory, Podpora a Poručnictví Zdravotní a lékařská péče, kde jsou podkategorie jako Prevence, Onemocněl jsem, Výživa a jídlo,

Rehabilitace, Zneužívání návykových látek a Duševní zdraví a také Koronavirus

Výuka a vzdělávání, kde jsou podkategorie jako Předškolní vzdělávání a školní docházka, Studium, Živobytí a sociální pomoc studentům a Věda a výzkum Práce a nezaměstnanost, kde jsou podkategorie jako Uchazeč o zaměstnání a plánování kariéry,

Začínáte podnikat, Nezaměstnanost a Pravidla pracovního života

Bydlení a výstavba, kde jsou podkategorie jako Koupě domu, Výstavba a rekonstrukce a Stěhování v rámci Finska Práva a povinnosti, kde jsou podkategorie jako Základní práva a občanská činnost, Legislativa a právní ochrana, Soudní řízení a trestní záležitosti, Bezpečnost a veřejný pořádek a Digitální podpora a administrativní služby Osobní finance, kde jsou podkategorie jako Správa Vašich osobních financí, Důchod, Daně a veřejné finance a Ochrana zákazníka Stěhování a cestování, kde jsou podkategorie jako Stěhování do Finska, Stěhování z Finska a život v zahraničí a Cestování

Uživatel získá takto rozcestník, který pomůže najít cestu k odpovědím na jeho dotazy, případně jsou pak dostupné příručky na Suomi.fi v podobě praktických pokynů pro různé životní situace a různé fáze životního cyklu společnosti.

Pro firmy nebo společnosti portál nejprve ve vrchní části zobrazuje aktuální informace k dopadům pandemie Covid-19, přehled povolení a povinností pro firmy a společnosti a taky sekci s rychlými odkazy. Dále podobně jako u občana je následuje devět oblastí situací nebo rolí, v nichž se firma nebo společnost může ocitnout.

Založení živnosti, kde jsou další podkategorie jako Plánování obchodních aktivit, Formy podnikání. Založení živnosti, Živobytí podnikatele a Zahraniční podnikatelé Zaměstnavatel, kde jsou podkategorie jako Nábor zaměstnance, Odpovědnost zaměstnavatele, Pracovní prostředí a Změny v zaměstnání Změny a kritické situace, kde jsou podkategorie jako Změna vlastnictví a akvizice společnosti,

Ekonomické problémy, Ukončení podnikání, Informace o Covid19 pro firmy

Financování podniku a dotace, kde jsou podkategorie jako Finanční plánování, Půjčky a záruky, Financování s rizikovým kapitálem a Granty a dotace Finanční řízení a daně, kde jsou podkategorie jako Finanční řízení podniku a Zdanění podniků Odpovědnosti a povinnosti, kde jsou podkategorie jako Povolení a povinnosti, Balíčky schvalování,

Profesionální kvalifikace, Dohody, Odpovědnost společnosti k životnímu prostředí

Rozvoj podnikání, kde jsou podkategorie jako Řízení, Marketing a prodej, Rozvoj kompetencí a Řízení

jakosti

Návrh produktu a služby, kde jsou podkategorie jako Nápady a vynálezy, Vytvoření produktu a Komercializace Internacionalizace, kde jsou podkategorie jako Mezinárodní operace

Další zajímavé služby

Mapy

Na webu Suomi.fi je možno filtrovat služby, nebo hledat příslušné úřady na mapě a zobrazit požadované kontaktní údaje. Mapy jsou propojeny na Finský servisní katalog. Podobně jako Google Maps služba umožňuje uživateli i plánovat cestu k danému úřadu nebo službě díky propojení na národní routing service. Rovněž ukazuje místa, která můžete navštívit, abyste mohli služby využívat.

Obrázek 25: Ukázka finského zobrazení služeb na mapě včetně jednotlivých úřadů

Přeshraniční služby

Propojenost s ostatními státy EU ve standardu SDG Finsko v současné době analyzuje. Co v současné době funguje je datové propojení s Estonskem, které taktéž využívá architekturu x-road (Cross border data exchange).

Obrázek 26: Zaměření finské agendy přeshraničních služeb

Roadmapa do budoucna

V roce 2017 vláda vydala pro následujících 10 let program s cílem skokové produktivity ve veřejných službách a v soukromém sektoru pomocí digitalizace. Jeden z klíčových vstupů programu byl otevřený dopis předsedy vlády s žádostí o návrhy pro rozvoj digitalizace, na který bylo podáno více než 260 propracovaných návrhů od veřejné správy, podniků a nevládních organizací. Plán zahrnuje 112 klíčových služeb ministerstev, policie, dalších agentur veřejného i soukromého sektoru. Součástí programu je i strategie kybernetické bezpečnosti či strategie umělé inteligence v eGovernmentu. Na vypracování programu se podílelo převážně ministerstvo financí, pod které spadá řada ICT oddělení pro výzkum a vývoj.

Hlavní cíle

• Nadále jasně definovat a jednoduše zpřístupňovat dostupné reformy a služby.
• Být průkopníkem v oblasti technologického pokroku a inovativního zadávání veřejných zakázek.
• Zrušení zbytečných regulací a snížení byrokracie pomocí digitalizace.
• Generování snapshotů současného a budoucího stavu Finska pomocí AI pro BI.
• Odstranění administrativní zátěže, která se překrývá s potřebou rychlého zpracování schvalovacích procesů.
• Rychlejší a snazší zpracování povolení, funkcí nad různými registry a využití klíčových materiálů EU pro výzkum a vývoj.

Kroky k dosažení cílů

• Jeden portál veřejné správy dostupný na doméně Suomi.fi jak pro občany, tak pro firmy a organizace.
• 4 základní oblasti Informace a služby, Zprávy, Elektronický mandát a Registry.
• Informace a služby poskytují cestu pro řešení životních situací v podobě katalogu služeb.
• Zprávy fungují jako moderní e-mailové služby přímo v rámci portálu.
• Registry zobrazují informace o uživateli z různých registrů na jednom místě.
• Možnost zobrazit služby geograficky.

Závěry a doporučení pro ČR

Poučení pro ČR

• Investice do struktury řešení a implementace API přístupů umožňuje ve Finsku nyní rychlý rozvoj portálových řešení a služeb, které nabízí.
• Řada klíčových informací, včetně informací z registrů (a o registrech) by měla být přeložena do angličtiny.

Doporučení pro ČR

• Poskytnutí API přístupu k registrům, které umožňují další rychlý rozvoj portálového řešení a služeb.
• Implementace jednorázové autentizace – zejména pro cizince.
• Zapracovat funkci autorizace, která je ve Finsku pozitivně hodnocena a přináší úspory celé ekonomice.
• Otevřít další komunikační kanály v rámci portálu, ze zkušeností z Finska je velmi oblíbeným kanálem Chat.
• Implementace geografického zobrazení přístupu k službám – integrací map do portálu, umožňující uživatelům, plánovat cestu přímo na portálu bez nutnosti opouštět portál a hledat například v Google Maps.
• Využití výhod u metod interoperability k vytváření a udržování sémantické interoperability informací, tj. konzistentní práce s daty a metadaty pro digitální služby a datové toky.

Tato konstituční monarchie s parlamentním demokratickým systémem správy sice nepatří mezi členské země EU, ale je členem NATO a k jednotnému vnitřnímu trhu EU je velmi úzce přidružena prostřednictvím svého členství v Evropském hospodářském prostoru.

Dle průzkumů OSN v oblasti elektronické veřejné správy je Norsko společně s dalšími severskými zeměmi v předních příčkách oproti ostatním zemím Evropy. Rovněž se řadí mezi deset nejlepších zemí OECD v oblasti otevřených vládních údajů. Papírová byrokracie byla a je značné digitalizována.

Ministerstvo veřejné správy provedlo průzkum za účelem zjištění digitalizace veřejného sektoru z uživatelské perspektivy. Z vyhodnocení vyplývá, že 30 % populace si přeje zlepšit digitalizaci, 58 % je spokojeno se stávajícím stavem a 12 % má pocit, že digitalizace zašla příliš daleko.

Provozovatelem, realizátorem a správcem portálů je Norská digitalizační agentura DigDir (někdy známá pod názvem Difi), která je podřízena Ministerstvu místní správy a modernizace. Rovněž jsou zde podřízeni důležití aktéři jako Oddělení politiky ICT a reformy veřejného sektoru a Norská správa práce a sociálních věcí (NAV). Cílovými skupinami Norské agentury pro digitalizaci jsou ústřední a místní orgány státní správy, obchodní a dobrovolný sektor a široká veřejnost. V agentuře pracuje přes 300 zaměstnanců a má pobočky ve městech Oslo, Brønnøysund a Leikanger. Katalog služeb národních i místních vládních agentur je k dispozici na top-level portále norge.no. Nicméně Oslo nabízí přes portál státního guvernéra i služby, které nejsou zcela digitalizovány. V takovém případě je k dispozici vždy návod a interaktivní formuláře pro fyzické podání. Portály jsou ve větší míře provozovány pomocí cloudového řešení. Většina zdrojových kódů je uložena na platformě GitHub a celá řada repositářů je open source.

Veřejné on-line služby mají 4 úrovně zabezpečení, kde 1 je nejnižší a 4 nejvyšší, kde např. dvoufaktorové zabezpečení je úroveň 3 (př. MinID) a přístup k informacím o zdraví z centrální databáze DOFFIN vyžaduje úroveň 4 (př. BankID). Úroveň zabezpečení služby je zvolena vlastníkem služby.

Struktura

V roce 2019 byl definován ekosystém, který umožňuje vládním agenturám digitálně spolupracovat a poskytuje přístup k nezbytným společným funkcím a společným IT architekturám. Ekosystém je koordinovaně řízen a koordinován. Struktura zahrnuje standardy, principy, referenční architektury, klíčové komponenty a společné řešení z hlediska geografického i agendového.

Obrázek 27: Struktura komponent, funkcí a vládních agentur v Norsku

Ekosystém reprezentuje odpovědné agentury za portály a jaké jsou zdroje dat. Bohužel nebyl od r. 2019 zpracován nový přehled, a tudíž schéma nezahrnuje řadu klíčových portálů. Hlavní průvodce digitálními službami představuje již zmíněný portál norge.no. Tento portál rovněž zahrnuje informace o tom, jak veřejné orgány komunikují vzájemně i s občany. Portál norge.no je úzce integrován s ostatními portály veřejné správy, jako jsou portály ministerstev, policie, pošta, daňový úřad a jiné. Digitální služby zde lze najít pomocí vyhledávací funkce, tematického menu nebo přes definované životních událostí. Z top-down pohledu v hierarchii portálů přímo navazuje na norge.no portál veřejné správy regjeringen.no, portál daňového úřadu skatteetaten.no a portál zpravodajských služeb a komunikace altinn.no. Tyto portály jsou opět určitým způsobem dle případu užití provázány.

Portál veřejné správy

Veřejné informační služby jsou dostupné přes portál regjeringen.no a nabízí mimo jiné zejména následující služby:

• Informace orgánů veřejné správy vč novinek o vládě, obsazení, statistiky, strategie a plány.
• Hlavní oznámení dle sektorů jednotlivých odvětví jako je energetika, zdravotnictví apod.
• Klíčové oficiální dokumenty pro fyzické i právnické osoby jako je standardizovaná nájemní smlouva, smlouva o dílo apod.
• Evidence všech ministerstev vč. aktuálních kontaktů, jejich role, odpovědnosti a klíčové události v časové ose.

Obrázek 28: Úvodní obrazovka portálu veřejné správy v Norsku

Veřejné orgány, na které portál regjeringen.no odkazuje, nabízí obvyklé i nadstandardní služby. Ministerstvo zdravotnictví (portál arbeidstilsynet.no) občanům doporučuje především využívat národní systém Helfo pro registraci a rezervaci návštěv u osobních lékařů. Policie (portál politiet.no) zahrnuje bezpečnostní a jiné nařízení, reporting vandalismu, informace a aktuality o udržitelnosti jako je znečišťování, evidenci dokladů, bodový systém pro řidiče a jiné. Ministerstvo Zahraničí (portál norway.no) uvádí opatření a náležitosti pro jednotlivé země (Víza, studijní programy), ale nabízí i CMS na tvorbu portálů pro lokální i zahraniční ambasády. Poštovní portál posten.no nabízí rychlé a jednoduché řešení pro on-line registraci zásilek a následného odeslání na pobočce bez nutnosti přímé interakce s pracovníkem pobočky (výjimkou jsou zásilky s nutným ověřením BankID).

Portál daňového úřadu

Na portále daňového úřadu skatteetaten.no jsou dostupné obecné oznámení, nařízení, novinky a jiné informace související s daňovou správou. Systém je provázán s národním on-line registrem občanů a zahrnuje rezervační systém pro schůzky ohledně životních událostí a mnoho dalších služeb.

Obrázek 29: Ukázka z portálu daňového úřadu Norska

Požadavky se odesílají přes formuláře, které slouží k rutinní komunikaci se státem či konkrétními orgány. Pro firmy je portál úzce integrován se systémem Altinn (viz. níže). Portál skatteetaten.no zahrnuje personifikované zobrazení “Moje stránka” s editovatelnými základními údaji o přihlášené FO, FOP či PO, osobní oznámení a povinnosti, stanovení daní a evidence financí vč. majetku, bankovních účtů či dluhů. Některé služby portálu skatteetaten.no jsou v ČR k dispozici přes Portál občana, On-line finanční úřad, EPO či Datová schránka.

Obrázek 30: Norsko: ukázka nástěnky přihlášeného uživatele

Datová schránka Altinn

Altinn nabízí služby ke snížení zátěže na šíření informací uložené vládními agenturami pro širokou veřejnost. Jedná se o řešení pro vývoj a údržbu forem a pracovních procesů, společně s řešením pro reporting, které má usnadnit tok informací z podnikání do vlády i mezi jednotlivými subjekty.

Další podpůrné portály

• Portál nav.no pro vztah mezi zaměstnavatelem a zaměstnancem nabízí správu dovolené, nemocenské, penze a jiných aktivit, které je třeba evidovat k zamezení desinformace např. v případě přechodu zaměstnance do jiného zaměstnání. Tento portál je úzce provázán s portálem daňového úřadu.
• Pro cizince je k dispozici podpůrný portál sua.no, který poskytuje informace jako základní práva, postupy apod. Nově příchozí se musí zaregistrovat pomocí portálu udi.no, jež slouží rovněž pro žádosti o studium, práci, azyl či dlouhodobý odchod ze země.
• Informace o normách jsou zveřejněny na Standardizačním portále.
• Portál GeoNorge je národní portál pro geoprostorovou infrastrukturu Norway Digital a zobrazení geografických dat v digitálním formátu.
• Regelhjelp.no portál nabízí podnikům v soukromém sektoru aktuální informace o legislativních změnách, jako jsou regulace a shromažďuje požadavky agentur.

Rejstříky

Údaje občanů v registrech jsou z pravidla provázány s jejich elektronickými ID. Následně uvedené registry byly vybrány dle zajímavého případu užití ve srovnání s ČR.

• //Národní registr obyvatel// – účelem je, aby všichni občané dostávali informace od veřejných orgánů a ochrana práv a povinností. Jedná se o základ pro daňový registr, volební registr, norský registr příčin smrti, statistiku obyvatel a mnoho dalších. Registr obsahuje informace např. o životních událostech. Pro ostatní registry je přístupné otevřené standardizované API.
• Kontaktní a Rezervační registr – evidence kontaktních údajů pro digitální poštu, která je propojená s elektronickým ID občana, kterou spravuje Norská digitalizační agentura. Rezervační registr slouží pro rezervaci návštěv na úřadech.
• Registr právnických osob – zahrnují údaje o lidech na vedoucích pozicích a mimo jiné slouží k zasílání oznámení o zprávách doručených do systému Altinn.
• Registr finančního dohledu – obsahuje informace o všech společnostech, jejich společníků, datumu registrace, licence, oprávnění, geografické působení a jiné. Registr je aktualizován každou hodinu.
• Registr cestujících – informace o zahraniční pro Norské rezidenty a registrace příjezdu do Norska.
• Registry zdravotnictví – např. lékařský registr narození shromažďuje údaje o těhotenství a porodech pro výzkum a analýzu.

Federace služeb

Autentizace

Autentizace je realizována pomocí nástroje ID-porten, který umožňuje přihlášení elektronické ID jako je MinID pro nově příchozí imigranty či BankID pro rezidenty. BankID lze použít ve všech systémech, kde je nutná vyšší úroveň zabezpečení, jako jsou státní portály, banky, pojišťovny a jiné. Bez přihlášení do systému má občan k dispozici veškeré obecné informace o e-governmentu a jeho součástí, ale nemůže využít řadu služeb jako zaslání daňového přiznání a nemá svůj personifikovaný obsah. Pro pochopení použití elektronického ID vydala agentura Difi stránku Nápověda a návody pro společná řešení ICT.

Obrázek 31: Možné metody přihlášení do portálů v Norsku

Bezpečnost

• Komunikace mezi portály a registry je šifrovaná a probíhá skrze výměnu zpráv přes platformu postavené nad protokolem AQMP
• Portály jsou ve větší míře provozovány pomocí cloudového řešení.
• Většina zdrojových kódů je uložena na platformě GitHub a celá řada repositářů je open source, kde probíhají standardní procedury pro bezpečnostní ověřování.
• Data mezi portály jsou vyměňována skrze backend a je k tomu využíváno REST API s šifrováním na transportní vrstvě
• Aktuálně není implementován centrální dohledový systém, ale toto je naplánováno ve strategii dalšího rozvoje

Zprávy

Všechny veřejné agentury mohou komunikovat digitálně s občany bez nutnosti použití papírové pošty.

Komunikační kanály, které zlepšují prostředí a přesměrovávají veřejné výdaje, definuje Norský Parlament. Digitální pošta detekuje oficiální dokumenty od veřejných orgánů. Upozornění na zprávy se odesílají prostřednictvím SMS a emailu.

• Přístup do digitální pošty má pouze její vlastník a vyžaduje zápis kontaktních údajů v Kontaktních a Rezervačním registru a přihlášení s použitím elektronického ID. I když Norská digitalizační agentura doporučuje digitální komunikaci, tak umožňuje i papírovou formu. Nicméně následně odesílá řadu oznámení prostřednictvím emailu nebo SMS.
• Norské úřady nabízí občanům použití digitální pošty prostřednictvím uznávaných poštovních systémů e-Boks a Digipost, které si lze libovolně vybrat a vytvořit si pro ně samostatné účty. Digitální pošta firem je spravována pomocí portálu Altinn, která rovněž disponuje s řadou formulářů pro rychlejší zpracování častých žádostí. Na portále altinn.no lze požádat např. o změnu vlastnictví nemovitosti, univerzitní grant, registraci nové firmy, evidence daní u PO či odškodnění za karanténu skrz COVID-19. Většinu transakčních služeb je možno zprostředkovat pomocí jednoduchých formulářů, ale je možnost zasílat i libovolné zprávy.

Platby

Upřednostněna je elektronická forma. V zemi lze dlouhodobě žít zcela bez hotovosti, aniž by to občany nijak omezovalo. Transakce probíhají převážné pomocí standartní platby kartou. Nicméně v případě plateb pomocí chytrých zařízení dá přednost až 78 % uživatelů aplikaci Vipps v porovnání s PayPal, Google Pay či Apple Pay. Jedná se o řešení pro platby na pobočkách, e-commerce a fakturace. Předpokladem je mít BankID. V roce 2020 měla aplikace Vipps přes 100 tisíc aktivních uživatelů denně a 2,4 milionů odběratelů, tedy je téměř polovinu populace země.

• Aplikaci Vipps lze použít podobně jako Qerko přes QR kódy v restauracích či při on-line platbě. Může se jednat však i o následující případ užití. FO č. 1 bude chtít něco koupit od FO č. 2 přes nejpoužívanější on-line obchod finn.no. Následně se fyzicky potkají. FO č. 2 přes Vipps vygeneruje QR kód, FO č. 1 zaplatí a FO č. 2 instantně obdrží platbu.

Seznam životních událostí

Evidenci lze realizovat pomocí digitální komunikace se státem přes portály skatteetaten.no, altinn.no a jiné.

Hlavním rozcestníkem je zde norge.no.

Obrázek 32: Norsko: přehled životních událostí

Mezi digitalizované životní události a situace se řadí:

Stěhování – je třeba zaslat oznámení o změně adresy do Národního registru obyvatel přes Portál daňového úřadu (nejdříve 31 dní před stěhováním a nejpozději 8 dní po stěhování). Změna studia – rezidenti mohou požádat prostřednictvím norské přijímací služby pro vysoké školy (NUCAS). Zahraniční studenti se hlásí přímo na vysokou školu a míra digitalizace závisí na konkrétní univerzitě. Katalog služeb mimo jiné zahrnuje možnost požádat o studijní půjčku nebo grant z Norského státního fondu pro půjčky na vzdělání. Změna práce – v případě žádosti o dávku v nezaměstnanosti je třeba se registrovat jako uchazeč o zaměstnání u Norské správy práce a sociálních věcí (NAV) a následně o ni lze digitální cestou na témže portále požádat. Svatba – po obřadě musí svatební úředník zaslat dokumenty norskému daňovému úřadu, která zašle oddací list do doručené pošty v portálu Altinn. V případě, že občan není v tomto portále registrován, tak oddací list obdrží poštou. Na portále regjeringen.no je mezi standardizovanými smlouvami zahrnuta i předmanželská dohoda. Rozvod – doposud neexistuje čistě digitální cesta. Pro tuto službu je k dispozici portál společné správy hejtmanů hrabství skjema.fylkesmannen.no. Zde a v katalogu služeb je k nalezení formulář, který musí být ověřen právníkem či veřejným činitelem a následně legalizován či opatřen apostilem před podáním žádosti u místního hejtmana. Narození dítěte – informace o odpovědnosti a práv, poskytnutí digitálních služeb ohledně těhotenství jako je možnost zaslat notifikace ohledně kontroly těhotenství či žádost o rodičovský příspěvek. Smrt a dědictví – lékař či nemocniční úřad může vystavit úmrtní list elektronicky, což usnadňuje proces způsobem, že není třeba podávat oznámení okresnímu soudu. Po elektronickém vystavení je automaticky odesláno oznámení do Národního registru obyvatel. Migrace – Imigranti, kteří nově přichází do země, mohou udělat naprostou většinu aktivit digitálně. Nejprve musí zažádat na daňovém úřadě o D Number, kterým se následně identifikují pro studijní či pracovní smlouvy. Po příjezdu do země fyzicky žádají na základě D Number a platné smlouvy či potvrzení o studiu o schválení pobytu a o MinID, které mohou používat pro přístup do bankovních a jiných institucí. Přístup je do řady portálů značně omezen a je nutné používat fyzické autentizační tokeny s náhodně generovaným číslem. Po určité lhůtě lze přes soukromé banky získat BankID, které je následně ověřen daňovým úřadem, zpřístupní řadu služeb a velmi usnadňuje autentizaci a digitální komunikaci s veřejnou správou i soukromým sektorem. Odchod ze země stačí nahlásit digitálně.

Následující obrázek zobrazuje výsledky o povědomí občanů ohledně možnosti zaznamenat životní události digitálně. Agregovaná data jsou z průzkumu o veřejných digitálních službách od Ministerstva veřejné správy.

Obrázek 33: Statistika z průzkumu o veřejných digitálních službách v Norsku

Další zajímavé funkcionality

Aktuality je možno personifikovat. Občané se mohou účastnit a být informováni pomocí národního či obecního shromáždění stortinget.no, ale rovněž je velmi populární použití RSS čteček jako Aftenposten a Life in Norway. Svůj RSS kanál si mohou občané rovněž nastavit přímo na regjeringen.no.

Portály jsou integrované se službou bisnode, která přidělí každému občanovi známku, která zohledňuje finanční rizika. Příklad užití může být kontrola známky při žádosti o úvěr.

Elektromobilita je podpořena osvobozením od DPH pro vozidla s nulovými emisemi. Díky převážnému podílu na trhu akumulátorových elektrických vozidel lze zavést řadu služeb ze strany Ministerstva dopravy. Rovněž je zaveden měsíční reporting poplatků za placené úseky a pokut.

Roadmapa rozvoje

Pro veřejný sektor byla v roce 2016 stanovena strategie digitalizace na období 2019–2025, jejímž účelem je digitální transformace v jednotlivých agenturách a ve veřejném sektoru jako celku. Platí na obecné úrovni, udržuje celkovou perspektivu a poskytuje pokyny pro všechny odvětvové strategie.

Cíle

• Veřejný sektor bude digitalizován transparentním, inkluzivním a důvěryhodným způsobem.
• Více úkolů bude prováděno digitálně a jako bezproblémové služby.
• Všichni občané, podniky a dobrovolné organizace, které jsou toho schopny, komunikují digitálně s veřejným sektorem.
• Veřejný sektor využije potenciál sdílení a používání dat k vytváření uživatelsky přívětivých služeb a k podpoře tvorby hodnot v podnikatelském sektoru.
• Místní a ústřední vládní agentury rozvíjejí své služby založené na společném digitálním ekosystému pro spolupráci.
• Místní a ústřední vládní agentury budou systematicky využívat výhody digitalizace.

Obrázek 34: Cíle a oblasti zaměření v oblasti digitalizace VS v Norsku

Kroky k dosažení cílů

• Zaměření na uživatele pomocí vývoje plynulejších služeb založených na klíčových životních událostech.
• Veřejný sektor bude lépe spolupracovat na rozvoji digitálních služeb a jejich systematickém využívání.
• Efektivnější využívání zdrojů prostřednictvím lepší koordinace napříč správními úrovněmi a odvětvími.
• Údaje budou ve veřejném sektoru znovupoužitelné a ve větší míře sdíleny napříč portály.
• Otevřená data pro inovace a vytváření hodnoty v podnikatelském sektoru budou veřejná.
• Vnitrostátní digitální spolupráce a rozvoj služeb, společná řešení a společné architektury budou vytvořeny v hierarchicky řízeném a koordinovaném ekosystému.
• Bude posílena spolupráce se soukromým sektorem v oblasti digitalizace s cílem dosáhnout lepších a efektivnějších služeb a usnadnit inovace.

Závěry a doporučení pro ČR

Hierarchická struktura portálů není aktuálně sdílena nebo je obtížně dohledatelná. Pro představu Evropská komise vydala o Norském e-governmentu poslední článek v r. 2016, kde jsou portály popsány pouze jednotlivě. Na portále veřejné správy se pojednává o hierarchii naposledy v r. 2019, a to spíše z hlediska odpovědností a zdrojů. Uvedené informace o struktuře jsou tedy výsledkem tohoto průzkumu a průchodu dostupných portálů Norska. Tudíž lze předpokládat, že občané nemusí mít o některých portálech natož o jejich struktuře ucelenou představu.

Z průzkumu o kvantitě uživatelů občanů používajících katalog služeb je rovněž patrné, že portály jsou dobře dostupné. Důvodem může být například to, že po zadání konkrétního problému jako např. “získat vzor nájemní smlouvy” v norštině se adekvátní portál zobrazí v prvních žebříčcích v Google vyhledávači. Díky efektivnímu zpracování katalogu služeb jsou tyto služby dostupné v jednoduché a přirozené formě, což z uživatelského hlediska vede k rychlému řešení i těch komplexnějších problémů. Dle strategie ministerstva místní správy a modernizace je digitalizace služeb je prioritizována dle časové náročnosti procesů řešících specifické problémy. Systém s touto kombinací prvků vede ke zlepšení digitální gramotnosti občanů a značné úspoře klíčových nákladů.

Informativní obsah portálů v anglickém jazyce je kvantitativně a kvalitativně značně omezen, což může mít za následek, že cizinci snadno naleznou informaci dle personifikace, ale v mnoha případech nenajdou potřebné informace v jiném než v Norském jazyce. Portály do sebe nejsou zanořené pomocí iframes jako v případě Dánska, aby byla zachována responzivita stránek, jelikož většina uživatelů přistupuje z telefonu.

Poučení pro ČR

• Struktura portálů by neměla být obtížně definovatelná.
• Portály by měly být snadno udržitelné, resp. některé informace či služby by neměly být duplikované napříč některými portály (např. dva digitální poštovní systémy e-Boks a Digipost).
• Funkce portálů by měly být federované nebo integrované napříč portály (např. notifikace lze integrovat pouze pomocí SMS či přes email nebo vyhledávání bych musel použít přes vyhledávače nebo zvlášť u jednotlivých portálů).
• Řada klíčových informací jako jsou informace o národním registru by měla být přeložena do angličtiny.

Doporučení pro ČR

• Většina transakčních služeb dostupná přes krátké interaktivní formuláře.
• Vynucené použití autentizačního ID i pro některé soukromé podniky s potřebou vyššího zabezpečení jako jsou banky či pojišťovny.
• “Moje stránka” s informacemi na portálu občana funguje rovněž jako interaktivní formulář pro aktualizaci údajů.
• Daňové přiznání pro zaměstnance a OSVČ dostupné “na jedno kliknutí”.
• Možnost změnit velikost textu zejména pro starší občany.
• Zavést mediální kanál s návody k portálům (např. portál daňového úřadu má kanál s návody na YouTube a odkazuje se na ně ze zpravodajských stránek a sociálních sítí).
• Měření počtu uživatelů a jejich anonymní identifikace z pohledu geografického, časového a technického, kteří přistupují k portálům.
• Podpora responzivního rozhrání pro všechny frekventovaně používané portály.

Poznámka: V rámci mapování současného stavu byly po workshopech jednotlivým zástupcům portálů rozeslány dotazníky k doplnění. Před koncem studie nebyly obdrženy všechny dotazníky, a tak některé údaje nemusí být přesné, případně kompletní.

Kapitola se zabývá zmapováním a popisem současného stavu vybraných centrálních, agendových, územních a soukromých portálů. Do této aktivity bylo vybráno celkem 12 agendových a územních portálových řešení a 2 centrální portály. Analýza současného stavu vybraných řešení byla realizována kombinací cílených schůzek se zástupci vybraných portálů a dotazníkovým šetřením. Účelem analýzy je zhodnocení připravenosti portálů pro federaci a zjištění rozdílů vůči cílovému stavu.

Pro každý portál je sestaven úvodní popis doplněný o přehled služeb, které jsou dostupné na daném portálu. Dále je součástí popisu i přehledová tabulka mapující rozdíly mezi stávajícím stavem daného portálu a cílovým konceptem federace (kapitola 6). Přehledová tabulka popisuje, zda je daná funkce na portálu v současné době zastoupena či nikoli, a ještě doplněna o poznámku. Poznámka indikuje například důvod, proč daná funkce není na portálu zastoupena, že je funkce ve vývoji anebo je řešena pouze částečně.

Portál veřejné správy je ISVS, který zajišťuje občanům přístup k informacím veřejných orgánů a komunikaci s veřejnými orgány a byl spuštěn, ve své modernizované podobě, v březnu 2012. PVS poskytuje občanovi/uživateli informace o službách veřejné správy a životních událostech, formuláře, věstníky, seznam datových schránek, nepotřebný nemovitý majetek a další. Portál je primárně zaměřen na širokou veřejnost, státní správu a samosprávu, státní i soukromé organizace, včetně podnikatelů, živnostníků a cizinců.

Většina informací je na PVS dodávána samotnými úřady, Ministerstvo vnitra pak zajišťuje technický chod portálu.

Portál je určen pro:

• občany Česka,
• cizince žijící na našem území,
• podnikatele a živnostníky,
• orgány veřejné moci.

PVS slouží jako rozcestník a umožňuje přihlášení do Portálu občana prostřednictvím elektronické identity, případně bankovní identity. PVS dále poskytuje informační služby pro občany, formuláře i přístup k dalším službám, jako je eRecept nebo bodové hodnocení řidiče. Uživatel si může do portálu připojit datovou schránku a komunikovat tak s úřady.

Přehled funkcí – PVS/PO

Pro přihlášeného občana nabízí aktuálně portál sekce profil a la nástěnka, údaje, datové schránky, podání, dokumenty a kalendář. Portál dává občanovi přehled o jeho dokladech, informace z katastru nemovitostí, bodové hodnocení řidiče, náhled do registru obyvatel, náhled do registru živnostenského podnikání a zdravotnické dokumentace. Do portálu se občan může přihlásit prostřednictvím NIA anebo přes (v budoucnu nepodporovanou) datovou schránku.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Ano, z eGSB

PO umožňuje vkládat různé formáty dokumentů do úložiště.

PO umožňuje vkládat vlastní události.

Gov.cz - ano, web je hodně založen na informacích, článcích, obsahu pro uživatele. Zároveň poskytuje aktuality (covid, tornádo, volby atd.). Portál občana má jen krátké informace např. o výpadku apod.

SMS/e-mail; ano centrálně

SMS/e-mail; ano centrálně

Na Gov.cz je formulář pro zpětnou vazbu (sbírá se do interního adminu). Na Portálu občana je formulář pro nahlášení incidentu. Oba portály mají kontaktní e-mail, kam uživatelé často píšou zpětnou vazbu. Na Gov.cz na jednotlivých článcích je možnost hodnocení a poslání zpětné vazby.

Uvažuje se o implementaci, nicméně není znám technický koncept.

Ano, v Portálu občana si lze customizovat všechny dlaždice na Dashboardu.

Zatím ne, v Portálu občana by mělo jít o personalizaci dle údajů z ROB/ROS.

Ano, EN

Základní úroveň, aktuálně řešeno za pomoci Application Insights, Hotjar, Google Analytics, dále Cerebro pro marketing.

Jedná se o VIS

Jedná se o variantu Single-Sign-On

Portál Mojedaně.cz byl představen v červnu 2019 jako prioritní projekt moderního a jednoduchého řešení pro občany, a to v podobě on-line finančního úřadu, tedy způsobu, jak obsluhovat své daňové povinnosti, zejména pak vyplňování daňových přiznaní pro 8 milionu poplatníku v ČR, to vše dostupné na jednom místě z pohodlí domova nebo kanceláře.

Samotné technické realizaci portálu předcházela příprava legislativy, legislativní základ v novele daňové řádu, která je postavena na čtyřech pilířích novelizace tzv. daňové informační schránky, kde si poplatník zjistí, jak si stoji, zda nemá nedoplatky, termíny splatnosti, dalším pilířem je pak lety ověřený a používaný EPO interaktivní formulář, který pomáhá uživatelům předvyplnit daňové přiznání.

Řešení samotného portálu cílí na zjednodušení kontroly a vracení nesporné části daňového odpočtu. Smyslem projektu byla zásadní modernizace daňové informační schránky, která byla do té doby jen statická sloužící k prohlížení údajů. S portálem Moje daně je nastavena daňová informační schránka dynamicky, aby umožnila i komunikaci uživatele se správcem daně. Další předností je pak jednoduchost přihlášení poplatníka s existujícími identifikátory – E-občanka, Identita občana, datová schránka nebo elektronického bankovnictví, mobilní klíč eGovernmentu. Portál nabízí přehled stavu osobního daňového účtu, daňový kalendář šitý na míru poplatníka a notifikace poplatníka na jeho email, aby si mohl plnit své daňové povinnosti. Portál Moje daně byl spuštěn od prosince 2020.

Přehled funkcí - Mojedaně.cz

Portál dělí služby pro přihlášené a pro nepřihlášené uživatele. Veřejné služby poskytují informace o koeficientech pro podání dani z nemovitých věcí, elektronická podání pro daňovou správu včetně formulářů, dokumentace, které slouží jako nápověda k jednotlivým službám a registr DPH. Hlavní autentizované služby jsou pak čtyři, daňová informační schránka, náhled na všechny, na které má poplatník oprávnění, elektronická evidence služeb, Mini-one-stop-shop a vrácení DPH v rámci EU.

Pro přihlášeného poplatníka je pak na hlavní stránce možnost si vybrat přiřazenou roli a podle ní pak přistupovat k informacím. Jako osoba pak poplatník vidí stav svých závazků i poslední pohyby na daňových kontech. V sekci Moje formuláře je zpříjemněním automatického předvyplnění formulářů, kde se stále vyplňují stejná data. Počet takových formulářů bude postupně přibývat. Dalším usnadněním je možnost platby přes QR kód. Portál uživateli nabízí osobní jednoduchý a přehledný daňový kalendář, nebo při nevybrání role odkaz na obecný kalendář finanční správy. Existuje i možnost zadat pověření další osoby pro správu vybraných daňových povinností, a to lze buď za pomocí její identifikace 12 místným kódem nebo číslem občanského průkazu.

Obrázek 35: Udělení oprávnění na portálu Moje daně

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Je pouze Datová informační schránka

Pasivní individualizovaný kalendář, bez možnosti provázat například s osobním kalendářem, nebo modifikace

Možnost nastavení formou emailu

Ve stylu má dati/dal

Ve stylu má dati/dal

Kalendář, platby, historie

Jedná se o VIS

Autentizace portál je budována jako Single-Sign-On, ale v současné chvíli není podpora deeplinků při přechodu přes autentizaci.

ePortál ČSSZ nabízí klientům on-line služby, díky kterým mohou rychleji a snadněji komunikovat s Českou správou sociálního zabezpečení a okresními správami sociálního zabezpečení. Pomocí této on-line samoobsluhy získají klienti nejen rozšířený přístup ke službám ČSSZ, ale zároveň ušetří svůj čas a sníží svou administrativní zátěž při vyřizování potřebných dokumentů.

On-line služby ePortálu využívají zejména pojištěnci (zaměstnanci a důchodci), dále zaměstnavatelé a osoby samostatně výdělečně činné (OSVČ), kterým ePortál České správy sociálního zabezpečení umožňuje nahlížet na údaje evidované v databázích ČSSZ a zároveň mohou jednoduše využívat interaktivní tiskopisy.

Přehled funkcí – ePortál ČSSZ

Portál se soustředí na deset hlavních principů poskytovaných služeb.

1. Snadný přístup k údajům, které Česká správa sociálního zabezpečení ze zákona eviduje ve svých databázích.
2. Vzdálené (on-line) vyřizování většiny záležitostí.
3. Nonstop přístup.
4. Všechny formuláře a podání na jednom místě, který šetří čas.
5. Kontrola správnosti dat automaticky na portálu.
6. Elektronická korespondence šetřící náklady na cestování a poštovné.
7. Ochrana osobních údaje přes zabezpečené odesílání přes ePortál.
8. Více možností přihlášení například přes datovou schránku, elektronický podpis nebo přístup přes tzv.

NIA prostřednictvím portálu identitaobcana.cz.

Elektronické podání šetřící tisk, vyplňování a skenování. Rychlost komunikace s úřadem během okamžiku.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Ano, prostřednictvím emailu. Do budoucna se zvažuje převzetí notifikační komponenty z PO.

V rámci odpovědi na dotaz službou

V rámci odpovědi na dotaz službou

ČSSZ má vybudované Call centrum na elektronickou komunikaci, kde řešíme jak problémy klientů, tak sbíráme požadavky na další rozvoj a přívětivost

Uživatel (FO, PO) může udělit pověření na jinou osobu (FO, PO) u jednotlivých služeb. V případě přihlášení datovou schránkou typu pověřená osoba je pověření u PO automatické. V plánu je implementace automatického pověření jednatelů u uživatele typu PO. Pověření není evidováno na celou PO, ale na její mzdové účtárny.

Nevyužívá designsystem.gov.cz Zasmluvnění dodavatele ePortálu, vybrání částí ePortálu k překladům, zadání zakázky k předkladům ePortálu, koordinační činnosti zástupci IKT ČSSZ a další aktivity věcně příslušných útvarů s tímto projektem spojených.

Implementace dalších jazykových mutací: anglická verze pro potřeby SDG, je k úvaze, zda i verze německá a francouzská (analogicky jako webové stránky ČSSZ; nutno podotknout, že webové stránky nejsou v porovnání s českou verzí přesně totožné)

Implementován Google Analytics a Splunk pro sběr informací o návštěvnosti.

Jednodušší úpravy (textové) jsou řešeny pracovníky ČSSZ, složitější úpravy dodavatelem.

Jedná se o VIS

Jestliže je součástí odkazu na ePortál informaci o existujícím přihlášení přes NIA, je uživatel přihlášen automaticky bez interakce.

eRecept

Systém eRecept byl zřízen jako organizační součást Státního ústavu pro kontrolu léčiv podle zákona 378/2007 Sb. o léčivech. Je zřízen jako neveřejný informační systém veřejné správy dle zákona č. 365/2000 Sb. o informačních systémech veřejné správy. Centrální úložiště bylo zařazeno mezi kritické informační systémy dle zákona č. 181/2014 Sb. o kybernetické bezpečnosti.

Systém eRecept byl v České republice vytvořen k předepisování léků elektronickou formou (ePreskripce) už od roku 2011 a od ledna 2018 je tento způsob povinný. Centrální úložiště elektronických receptů (CÚER), jako součást Systému eRecept, je úložiště lékařských předpisů (receptů) vystavených v elektronické podobě.

Sdílený lékový záznam pacienta přináší lidem komplexní přehled o jimi užívaných lécích. Vyhýbá se tak prakticky situacím, kdy pacienti často neznají nebo si pletou léky, které berou a mají často zmatky v dávkování. Díky lékovému záznamu je možno se zorientovat v tom, jaké léky byly pacientovi lékaři jiných specializací předepsány a zda a jak je užívá. Díky tomu lékař dovede pacientům lépe pomoci.

Milníky, které lze vyzdvihnout:

• Listopad 2020 - Počet vystavených eReceptů překročil hranici 200 milionů.
• Duben 2021 - Podpora evropského formátu pro přeshraniční výměnu elektronických zdravotních záznamů (doporučení EK 2019/243).
• Květen 2021 - Od 26. května 2021 zákon dovoluje uživatelům (lékařům, farmaceutům a dalším) přistupovat do systému eRecept prostřednictvím národního bodu pro identifikaci a autentizaci. Dále zákon zřizuje centrální úložiště elektronických poukazů. Prostřednictvím tohoto úložiště mohou předepisující předepsat zdravotnický prostředek. Pokud prodejce přijímá elektronického poukazy, pak na základě elektronického poukazu prodejce vydá předepsaný zdravotnický prostředek

Přehled funkcí – eRecept

eRecept je recept vystavený v elektronické podobě. Lékařem vystavený eRecept je uložen do tzv. Centrálního úložiště elektronických receptů (CÚER). Každému eReceptu je přidělen unikátní identifikátor. V lékárně pak lékárník načte identifikátor eReceptu a pokud je eRecept v CÚER nalezen, vydá předepsaný lék pacientovi. Informace o výdeji léku se zároveň zapíše do CÚER.

Se systémem pak pracuji v různých rolí lékaři, lékárníci, pacienti, pojišťovny a dodavatelé lékařských a lékárenských software.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Aktuálně podporované role: lékař, lékárník, pacient, zdravotní pojišťovna, dodavatel.

Ano v relativně detailní formě.

Nutná digitalizace služeb.

Nicméně integrace DS je vnímána jako přínosná.

Nutná digitalizace služeb.

Nicméně funckionalita je vítána, je ale nutná podpora ze strany legislativy.

Portál sám o sobě poskytuje informace, nicméně není připraven (ani to není v plánu) na to, je zpřístupnit pro vzdálený odběr.

Vlastní způsob notifikací.

Nutná digitalizace služeb.

Nutná digitalizace služeb.

Plánuje se a to i z technického pohledu.

Základní měření počtu přístupů – analýza zájmu o skupiny informací a následný rozvoj oblastí, o které je zájem.

Aktuálně není potřeba autentizovaná sekce, ale o přípravě takové sekce se uvažuje. Technicky je NIA implementovatelná, je potřeba mít úroveň ověření alespoň Vysoká.

Portál ČÚZK

Český úřad zeměměřický a katastrální (dále jen "ČÚZK") je ústředním správním úřadem zeměměřictví a katastru nemovitostí České republiky se sídlem v Praze. ČÚZK byl zřízen zákonem č. 359/1992 Sb., o zeměměřických a katastrálních orgánech, s účinností od 1. 1. 1993.

ČÚZK poskytuje skrze své stránky přístup do několik portálů, Nahlížení do katastru nemovitostí (KN), Dálkový přístup k údajům katastru nemovitostí České republiky a také Geoportál.

Informační přístup do KN nevyžaduje žádnou registraci a je bezplatný. Pro zobrazení úplné sady informací je vyžadováno zadání CAPTCHA nebo přihlášení prostřednictvím Portálu národního bodu pro identifikaci a autentizaci - identitaobcana.cz (NIA) nebo zákaznického účtu Dálkového přístupu do katastru nemovitostí. Aplikace je určena výhradně pro interaktivní práci uživatelů, jakékoli získávání nebo vytěžování dat automatizovanými prostředky není dovoleno.

Geoportál ČÚZK (Geoportál) je komplexní internetové rozhraní pro přístup k prostorovým datům pořizovaným a aktualizovaným v resortu Českého úřadu zeměměřického a katastrálního (ČÚZK).

Geoportál umožňuje na jednom místě vyhledat informace (metadata) o prostorových datech resortu ČÚZK, dále umožňuje si tato data prohlédnout, případně objednat ve formě souborů či služeb.

Geoportál poskytuje služby a umožňuje sdílení dat dle zásad uvedených v prováděcích pravidlech směrnice INSPIRE, tj. zajišťuje zejména zpřístupnění souborů prostorových dat odpovídajících tématům uvedeným v příloze směrnice, zpřístupnění služeb založených na prostorových datech, zveřejňování metadat, služby elektronického obchodu, sdílení souborů prostorových dat ve veřejné správě a informování o využívání infrastruktury.

Přehled funkcí – ČÚZK

Aplikace náhled do katastru nemovitostí umožňuje získávat vybrané údaje o parcelách, stavbách, jednotkách (bytech nebo nebytových prostorech) a právech stavby, evidovaných v katastru nemovitostí a dále informace o stavu řízení pro účely zápisu vlastnických a jiných práv oprávněných subjektů k nemovitostem v České republice, nebo pro účely potvrzování geometrických plánů.

Obrázek 36: Služby pro přihlášené uživatele KN

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Profesní role zeměměřič. - Vyšší rozsah poskytovaných dat z dokumentace katastrálních úřadů. - Speciální služba - Žádost o potvrzení geodetického plánu - Speciální služba - Zkouška ÚOZI

Plánuje se.

DS považujeme za samostatný komunikační kanál. Jestliže bude fungovat portál, pak nemá smysl do něj integrovat DS. DS je prostě jiný typ kanálu a zákazník by měl mít možnost si vybrat. O autorizované podání se bude jednat už díky tomu, že se přihlásím přes NIA do portálu. Možná by propojení bylo vhodné v případě, že v portále bude notifikace o ukončení řízení na katastrálním úřadě a osoba pak přejde do DS, kde bude mít zaslaný dokument.

Notáři mají umožněno vkládat listiny pro zápis do KN prostřednictvím aplikace NV. Ostatní uživatelé zatím ne. Ukládání musí být pouze dočasné a kapacitně omezené. V nějakém obecném úložišti moc smysl nevidíme. Pokud ano, tak spíše jedno, centrální, třeba na PO.

NdKN, DP, DPN, SSZ, www.cuzk.cz ano v rámci "aktualit", se používá RSS kanály.

V sekci "Můj katastr".

Historie podání.

Služby eGSB jsou v přípravě a technicky realizovatelné.

Aktuálně Ministerstvo dopravy disponuje pouze informačními stránkami, kde není část pro přihlášené uživatele. Nicméně ministerstvo má mnoho jednotlivých samostatně stojících řešení jako mýtný systém, přehled tachometrů z STK, dálniční známky, dodává ze svých registrů informace do Portálu občana, jako expirace dokladů a bodové konto, dále existuje Portál, který zobrazuje pouze dvě agendy, Státní plavební správu a taxi. Stránky ministerstva pak slouží jako informační portál a rozcestník.

Ministerstvo aktuálně připravuje nový portál tak, aby umožnil i vyřízení některých agend on-line a vzorem mu proto je v tuto chvíli Portál občana, tak jak vyplynulo z rozhovorů s jeho zaměstnanci.

Přehled funkcí – MD

Ministerstvo dopravy nabízí v rámci svých agend mnoho řešení. Jedná se o agendy v úvodu zmíněné silniční dopravy, nákladní silniční doprava, železniční doprava, vodní doprava a letecká doprava. V poslední době ministerstvo spouští mnoho digitalizovaných řešení viz přehled v obrázku níže, to vše by pak měl završit nový portál Ministerstva dopravy, kde přibydou i další funkce, s jakými je možno se setkat na Portálu občana.

Obrázek 37: Přehled zdigitalizovaných služeb MD

Poznámka: Dotazník nebyl obdržen, jelikož portál je aktuálně ve vývoji, a tak nebylo možné zmapovat stávající funkce portálu.

Živnostenský rejstřík (původně Registr živnostenského podnikání) je jedním z informačních systémů veřejné správy, který spravuje odbor živností Ministerstva průmyslu a obchodu ČR. Tvůrci dat živnostenského rejstříku je 205 živnostenských úřadů obcí s rozšířenou působností a 22 živnostenských úřadů některých městských částí Hlavního města Prahy. Do živnostenského rejstříku se zapisují údaje související s provozováním živností. K poslednímu dni roku 2020 bylo v živnostenském rejstříku zapsáno cca 2 miliony fyzických osob s platným živnostenským oprávněním a cca 500 tisíc právnických osob s platným živnostenským oprávněním. Živnostenský rejstřík je spolu s obchodním rejstříkem hlavním dodavatelem údajů do základního registru osob (ROS).

Přehled funkcí – IS RŽP

V živnostenském rejstříku jsou údaje o podnikajících fyzických a právnických osobách, které vlastní nebo vlastnily živnostenské oprávnění. Jsou zde údaje nejen o tuzemských osobách, zahrnuje i data o zahraničních osobách podnikajících na území ČR. Živnostenský rejstřík obsahuje u jednotlivých subjektů hlavičkové údaje (jméno, příjmení, resp. název, datum narození, identifikační číslo osoby, adresa sídla, údaje o konkurzu) a dále údaje o jednotlivých živnostenských oprávněních (předmět podnikání, datum vzniku, provozovna, odpovědný zástupce, přerušení provozování živnosti, překážky provozování živnosti). Neveřejná část živnostenského rejstříku obsahuje i rodná čísla a trvalá bydliště fyzických osob a uložené pokuty. Ve veřejné části živnostenského rejstříku jsou nejen podnikatelé s platným živnostenským oprávněním, ale i ti podnikatelé, kterým zaniklo nebo bylo zrušeno poslední živnostenské oprávnění před méně než 4 lety. Do živnostenského rejstříku zapisují živnostenské úřady údaje do 5 dnů ode dne, kdy je podnikatel oznámil nebo kdy se je živnostenský úřad dozvěděl.

Přehled služeb:

• Nahlížení do ŽR – Vyhledání konkrétního podnikatelského subjektu se zobrazením jeho údajů z veřejné části živnostenského rejstříku.
• Elektronické podání – Elektronické podání prostřednictvím Jednotného registračního formuláře umožňuje vytvořit podání, pomocí kterého může podatel živnostenskému úřadu ohlásit nové živnosti, podat žádost o koncesi, ohlásit změny u již zapsaných skutečností apod.
• Statistické údaje – Jedná se o statistické údaje o podnikatelích a živnostenském podnikání v ČR, které jsou zveřejňovány na webových stránkách Ministerstva průmyslu a obchodu. Statistiky jsou tvořeny z údajů o podnikajících subjektech a jejich živnostenských oprávněních vedených v živnostenském rejstříku.
• Informace k živnostenské podnikání – Aktuální informace a legislativa k živnostenskému podnikání, včetně průvodce živnostenským podnikáním (stránky Ministerstva průmyslu a obchodu ČR).

Poznámka: Dotazník nebyl obdržen, a tak nebylo možné zmapovat stávající funkce portálu.

Portál businessinfo.cz je internetový portál, který vznikl díky spolupráci agentury CzechTrade a Ministerstva průmyslu a obchodu v roce 2001. Účelem portálu je poskytovat systém informací a služeb, které jsou určeny zejména podnikatelům a exportérům. Nabízí i informace o novelách norem z podnikatelského prostředí. Zvláštní důraz je kladen na oblast podpory a orientace v Exportu a Zahraničních příležitostí. Do portálu přispívá 32 státních a komerčních organizací s návštěvností v průměru 330000 návštěv měsíčně v roce 2020. V roce 2013 převzala správu nad obsahovou částí Mladá fronta, která v roce 2017 opět vyhrála tendr na redakční služby

Přehled funkcí – portál businessinfo.cz

Portál businessinfo.cz má hlavně informační roli, a to zejména v oblastech dotace a financování, legislativa a právo, zahraniční obchod, daně a účetnictví, ekonomika a trh v ČR, speciály, inovace a podnikání, poradna podnikatele, koronavirus, registr rodinných podniků, aplikace E-start (systém kurzové prevence odhadující kurzové riziko), videa a podcasty. I poradna je řešena formou článků, není možnost podat dotaz přes formulář či v diskuzi. Je možno se přihlásit o odběru newsletteru za danou oblast.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Portál má read-only přístup k AIS RPP + RPP AIS Editační skrz export těchto dat skrz rozhraní https:%%//%%rppopendata.egon.gov.cz/. Tyto data pravidelně indexuje, publikuje výsek z těchto dat (pouze data pro podnikatele) a doplňuje k nim další kontext z informací a návodů a postupů a článků připravovaných přímo pro portál.

Integrace DS je vítána.

Portál podporuje přihlášení uživatele a logicky zobrazování informací určených pouze pro daného uživatele je nativně už nyní realizováno. Doplnění o další systémy třetích stran by logicky nebyl problém.

S možností emailové notifikace na novinky.

BI.cz implementoval vlastní modul pro získávání a vyhodnocování zpětné vazby na základě nařízení EK k SDG.

EN, o dalších se neuvažuje. Zajištění indexace, SEO optimalizace a celkově naplnění stanovených cílů pro návštěvnost je součástí rutinní práce každého redaktora. Portál používá nástroj Google Analytics pro sběr informací o návštěvnících stránek (a sekundární přístupové logy aplikačních a CDN serverů). Informace jsou z tohoto nástroje přímo integrovány do CMS systému pro zlepšení práce redaktorů s obsahem a pochopitelně jsou využívány jako základní vstupní nástroj pro rozvoj kterékoliv z vertikál portálu. Bez těchto dat - tj. jak uživatelé portál využívají – by nebylo možné provádět kvalifikovaná rozhodnutí jak z hlediska rozvoje jednotlivých částí, tak vyhodnocování zrealizovaných změn.

Převážnou část požadavků portál splňuje – je to dáno použitou cloudovou platformou Google Cloud, požadavky na SLA ze smlouvy o provozu, požadavky na lidské zabezpečení atd.

V současné době neobsahuje portál informace, jejichž zpřístupnění by vyžadovalo takovéto ztotožnění uživatele.

Je to technicky zvládnutelné, v tuto chvíli nebyla potřeba využívat.

Je to technicky zvládnutelné, v tuto chvíli nebyla potřeba využívat.

Je to technicky zvládnutelné, v tuto chvíli nebyla potřeba využívat.

Stránky kraje Vysočina obsahují velké množství informací pro občany včetně aktuálního očkování proti Covid19 a aktualit z kraje. Stránky slouží jako centrální portál kraje a jsou rozcestníkem na další tematické stránky kraje jako například fondvysočiny.cz, který nabízí přehled o dotačních programech, v rámci různých oblasti a odvětví.

Stránky nemají sekci pro přihlášené, ani neumožňují tedy elektronické podání. Mají čistě informační charakter.

Přehled funkcí – portál kraje Vysočina

Stránky kraje nabízí klasický formát přístupu k informací, hlavní nabídku, přehled úřadů a kontaktů, tiskové zprávy, běžící projekty, poslední dokumenty. Stránky pro pomoc při navigaci nabízí mapu stránek nebo funkci vyhledávání na stránkách. Jak již bylo zmíněno, nabízí v rámci témat další odkazy na další tematické stránky kraje.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Mají i RSS kanály na specifické události. Na kalendář mají v ICS. Jen kategorizace (kalendářů) ne personalizace.

Např. nalezení přihlášení do autentizované sekce portálu není snadné.

Ano, ale pouze v privátní zóně.

Ano, funkcionalita překladu webu pomocí Google.

Pracují se SEO, které jim dělá webmaster. O problematice ví, jsou si vědomi její důležitosti. Sběr dat z a pomocí Google Analytics.

Měla by vzniknout otevřená implementace SeP s bezpečnostními doporučeními.

Správný přístup, je třeba zavést jednotné identifikátory pro hledání chyb a eGSB dále rozšiřovat, aby podporovalo snadnější výměnu dat.

Digitalizace patří mezi hlavní cíle vedení hlavního města Prahy. V září 2020 se rozběhl projekt Portál Pražana, který má obyvatelům hlavního města usnadnit komunikaci s magistrátem. Za necelý rok bylo na jeho fungování vynaloženo 24 milionu korun.

Cena portálu je výrazně ovlivněna složitostí organizace pražské samosprávy, kdy je nutné propojit systémy 57 městských částí, které nejsou vždy stejné, a tyto integrační vazby jsou finančně náročné. Cenu také ovlivnilo to, že je portál postavený na již existující platformě, a to konkrétně na Portálu Občana ministerstva vnitra.

Projekt od začátku bojoval s nízkými počty návštěvníků, ale to se mění, jak se Portál Pražana rozrůstá o další služby. Zatím je v rámci něj dostupný jen omezený počet služeb.

Portál Pražana funguje jen pro přihlášené uživatele. Pro nepřihlášené slouží stránky praha.eu, které slouží jako informační web a je spravován jinou organizací. Pro přihlášení a využívání Portálu Pražana je nutné mít zřízenou oficiální státní elektronickou identitu z webu www.identitaobcana.cz nebo bankovní identitu.

Od začátku června 2021 se zvýšil zájem návštěvníků s nově spuštěnou službou poplatku za komunální odpad prostřednictvím Portálu Pražana, která umožňuje přístup i k aktuálnímu náhledu daňového účtu k agendě komunálního odpadu, včetně možnosti vyřešit platbu přes on-line generovaný QR kód, případně vrácení přeplatku. Tato agenda se týká v Praze téměř 100 tisíc subjektů, které ho mají povinnost platit dvakrát do roka.

Správu a rozvoj Portálu Pražana zajišťuje městská společnost Operátor ICT. Operátor ICT buduje Portál Pražana jako centrum digitálních služeb nejen pro obyvatele metropole. Pro úřad i občany je Portál příležitostí pro digitalizaci a zefektivnění práce.

Portál Pražana vychází z Portálu Občana. Je hodně mladým portálem s velkými ambicemi a jsou na něj kladeny velké požadavky hlavně co se týče návštěvnosti a počtu podaných podání. S tím, jak přibývají služby, které nabízí, a vstupuje v platnost změna zákona o přístupu k informacím budou další služby lépe integrovány do řešení.

Výzvou je zastřešení všech částí Prahy a jejich služeb (například parkování) v rámci jednoho portálu.

Přehled funkcí – portál Pražana

Portál Pražana byl pilotně spuštěn 30.9. 2020 a od té doby neustále přibývají nové služby, poslední spuštěnou službou je Poplatek za komunální odpad.

Dále jsou na portálu dostupné služby jako Záštita primátora hlavního města Prahy pro poskytnutí podpory primátora hl. m. Prahy pro veřejnou akci, Oznámení veřejného shromáždění, žádost a přehled jaké informace Praha již zveřejnila na základě svobodného přístup k informacím, služby pro nájemníky magistrátních bytů jako elektronická žádost o prodloužení nájmu nebo o potvrzení platnosti nájemní smlouvy, rezervace termínu návštěvy úřadu k žádosti o vydání paměťové karty řidiče, rezervace termínu návštěvy úřadu k žádosti o vydání mezinárodního řidičského průkazu a vydání nebo výměny řidičského průkazu, rezervace termínu návštěvy úřadu k nahlášení změny v registru vozidel, přehled Moje PID Lítačka, informace a on-line vyřízení rezidentního parkování na zónách placeného stání, možností participace občana na jednání zastupitelstva hl. m. Prahy, rezervace termínu návštěvy úřadu na vybrané městské části pro agendu Cestovního pasu nebo Občanského průkazu, podání žádosti o dotaci v oblasti kultury použijte prosím portál systému IS FP.

Do konce roku 2021 jsou plánované služby jako například řešení zón placeného stání nebo o agendu psů ve vybraných městských částech. V další fázi by měly přibýt vybrané služby městských organizací, například Dopravního podniku hl. m. Prahy, Pražských služeb nebo Technické správy komunikací, ankety a granty.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

souborů), např. projektové dokumentace.

Události hl. m. Prahy, případně vlastní události.

Rezervace termínu na úřadu.

Jen aktuální stav konta u komunálního odpadu. Jen aktuální stav konta u komunálního odpadu. Relevantní nápady se dostávají do katalogu požadavků a jsou dále řešeny v rámci plánu rozvoje.

Relevantní nápady se dostávají do katalogu požadavků a jsou dále řešeny v rámci plánu rozvoje.

Ano, u některých formulářů lze formuláře podat jako FO za PO. O mandátním registru uvažujeme, byť jsme přesvědčeni, že by měl být zajištěn ze strany státu, a ne přenesen na jednotlivé OVM.

Pro FPO a PO, kteří se přihlásí datovou schránkou, zobrazujeme jen část relevantních služeb.

Při použití přechodu na portál občana nebo na agendu řidičského průkazu je nutno se znovu přihlásit.

Základní, je využit jak nástroj GA, tak nativní nástroje MS Azure. Informace o návštěvách a chování uživatelů, včetně informací, jaký způsob autentizace uživatelé využívají.

Formálně sice nesplňuje, ale řešení vychází z Portálu Občana.

Jedná se o variantu Single-Sign-On Portál Pražana je provozován v prostředí MS Azure

Portál občana města Říčany umožnuje občanům komunikovat s městským úřadem on-line přes internet a minimalizovat tak počet nutných návštěv občanů na městském úřadě při vyřizování jednotlivých agend. Tím se odlišuje od stávajících webových stránek města a rozšiřuje tak jejich možnosti.

Cílem portálu je užší a rychlejší komunikace občanů s úřadem při řešení různých záležitostí. Proto je portál integrovaný s interními informačními systémy úřadu. Občan je pak informován nejen o změnách na úřadě, o novinkách ve městě, ale především o vlastní komunikaci probíhající s úřadem, a to o jednotlivých podáních a stavu jejich řízení, o platbách, finančních závazcích. Vzhledem k důvěrné povaze těchto informací PO zajišťuje legislativně i právně jednoznačné „ztotožnění“ občana.

Portál se dělí na dvě části, na část veřejnou pro anonymní/nepřihlášené uživatele a privátní pro registrované uživatele. Ve veřejné části jsou soupisy životních situací s popisem a k tomu přiřazené elektronické formuláře a dále je zde zobrazení dynamického telefonního seznamu. Privátní část umožňuje využít výhod přihlášení, kde umožňuje dát k dispozici různá přednastavení a funkcionality pro přihlášeného občana oproti anonymnímu občanovi.

Přehled funkcí – portál města Říčany

Na portálu jsou k dispozici všechny důležité informace k elektronické komunikaci občana s městem v podobě stromu životních situací, které se dělí na kategorie, odbory, kategorie „řeším“ a seznam životních situací. Dále občan najde popisy životních situací, elektronické formuláře a důležité kontakty.

Přihlášený občan může navíc nalézt následující služby:

• Elektronická realizování podání založená na „inteligentních“ formulářích, jež jsou automaticky předvyplňovány.
• Přehled o aktuální informaci o stavu podání.
• Zobrazení výčtu poplatků.
• Realizování elektronické platby na základě předpisu získaného z úřadu (úhrada přes platební bránu)
• Náhled platební historii.
• Další funkce: Hlídací pes (platnost občanského průkazu, cestovního pasu, včetně uživatelsky definovaných událostí – STK, platba pojištění, datum očkování apod. s následnou notifikací přes email nebo SMS) a Informační služba (využití automatické e-mailové notifikace při změně stavu daného podání)

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Dle přihlášení, je rozlišen občan / podnikatel.

Občan a podnikatel / FO a PO. EN a DE.

Na úrovni menších obcí může být obtížně splnitelné.

Autentizace portál je budována jako Single-Sign-On, ale v současné chvíli není podpora deeplinků při přechodu přes autentizaci. Zatím taková potřeba nebyla

Zatím taková potřeba nebyla

VZP je největší zdravotní pojišťovna, která zabezpečuje veřejné zdravotní pojištění a je zřizována státem. Nabízí dva portály, aplikace Moje VZP a VZP Point. Aplikace Moje VZP je pro všechny VZP pojištěnce, kteří s chtějí komunikovat s VZP elektronicky.

VZP Point je určen pro zaměstnavatele, poskytovatele zdravotních služeb, instituce, soudní exekutory nebo i zdravotní pojišťovny – pro všechny partnery, kteří mají ze zákona povinnost komunikovat se zdravotní pojišťovnou.

Přehled funkcí – portál VZP

Moje VZP po registraci umožňuje mít pod kontrolou platby zdravotního pojištění, ověřit si nedoplatky na pojistném, nebo projít historii plátců pojistného. K dispozici je přehled vykázané péče, druh péče a za jakou částku lékař pojišťovně vykázal. Moje VZP slouží i ke komunikaci s VZP, hlášení změn, ztráty průkazu, podání přehledu OSVČ, anebo žádosti o příspěvek. Služby aplikace se neustále rozšiřují. Registrovat je možno celou rodinu a poté z jednoho účtu kontrolovat údaje všech jejích členů.

V aplikace Moje VZP lze využít i funkce zastupování, na základě rodného listu u děti, případně soudem stanoveného opatrovnictví anebo na základě úředně schválené plné moci.

VZP Point umožňuje přístup k jednotlivým službám rozděleným dle uživatelských rolí v takovém rozsahu, které VZP systém a zákon umožňuje:

• Poskytovatelům zdravotních služeb podání, stahování číselníků a další
• Zaměstnavatelům hlášení, kontrolu údajů, zasílání přehledů
• Osobám samostatně výdělečně činným přehledy a vyúčtování.
• Pojištěncům přehledy, žádosti o vykázané péči a reklamace vykázané péče
• Státním institucím podávat hromadná oznámení
• Exekutorům získat vyžádané údaje o plátcích pojistného

K uvedeným portálům je možno se přihlásit přes NIA, nebo přes registraci on-line, kde je nutno počkat na přístupy, které jsou zasílány Českou poštou a je dále možno se registrovat přímo na kamenné pobočce.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Není ani možnost přenosu přihlášeného uživatele.

Nebylo možno ověřit

Nebylo možno ověřit

Nebylo možno ověřit

Pražská Plynárenská dlouhodobě patří mezi nejvýznamnější tuzemské dodavatele energií. Plynem a elektřinou zásobuje více jak 425 tisíc odběrných míst. Historicky je sice nedílně spjata s Prahou, kde lze kořeny plynárenství vysledovat až do roku 1847, ale v současné době poskytuje zákazníkům své služby po celé České republice.

Zákaznický portál umožňuje pro registrované uživatele mít přístup ke svým datům, a hlavně mít svůj účet pod kontrolou on-line. Pro Pražskou Plynárenskou spravuje portál ISE. ISE je IT společnost působí v rámci koncernu Pražská plynárenská, a.s. Specializuje se na komplexní tvorbu infrastruktury informačních a komunikačních technologií, implementaci informačních systémů a zajištění jejich provozu.

Přehled funkcí – portál PPAS

Mezi hlavní priority patří zákaznického portálu je zajištění komfortního zákaznického servisu a nabídka širokého spektra nadstandardních služeb pro své klienty. Pro neregistrované uživatele slouží zejména stránky www.ppas.cz, které nabízí kontakty, formuláře, přehled služeb, informace k přechodu, cenám a například kotlíkovým dotacím. Stránky také uvádí příkladové životní situace, jako úprava plateb, stěhování, změny na odběrném místě a jak se stát zákazníkem. Pouze registrovaným uživatelům slouží zákaznický portál https:%%//%%moje.ppas.cz/, který poskytuje kompletní přehled účtu zákazníka s možností platební brány a další.

Následující přehledová tabulka obecně mapuje existující funkce portálu na oblasti a funkce popsané v kapitole Funkce, které federované portály veřejné správy musí podporovat, včetně doplnění ve formě poznámky u dané oblasti či funkce (např. zda je funkce plánována, realizována v menším rozsahu nebo proč není zastoupena).

Pracují na registraci pomocí BankId. Přihlašování přes BankId nebude využíváno, protože jsou náklady příliš vysoké. Single-Sign-On by se líbilo, ale řešení je pro tento portál náročné.

Technicky realizovatelné

GAP analýza shrnuje zásadní rozdíly mezi současným stavem a vizí, jež je popsána v kapitole 4. Vybrané portály, které byly předmětem analýzy již na první pohled vykazovaly velké rozdíly, a to zejména v oblasti vzhledu, ale také z pohledu nabízených funkcionalit, případně služeb. Je to dáno primárně tím, že každý portál má jinou cílovou skupinu a od toho se odvíjí pokrytí daných funkcionalit. Centrální a územní portály poskytují primárně informační služby a v některých případech i transakční a z pohledu uživatele (občana) se chovají odlišně. Oproti tomu soukromoprávní portály jsou napříč odvětvími sjednoceny z pohledu struktury obsahu, navigace, jmenné konvence a množiny nabízených služeb.

V zásadě je rozmanitost portálů dána jejich primárním zaměřením, ale jsou oblasti, kde portály již poskytují funkce popsané v kapitole 4, ale také jsou funkce, které na daném portálu uživateli nepřinesou žádnou přidanou hodnotu a z toho důvodu jimi portály nedisponují.

Tabulka na následující straně mapuje zastoupení jednotlivých funkcí (popsaných v kapitole 4) v rámci portálu.

Oblast vyhledávání informací je u dotazovaných portálových řešení pokryta převážně základním fulltextovým vyhledáváním, a uživatel má možnost prohledávat daný portál, v ojedinělých případech pak dostane výsledky namapované na životní událost nebo na katalog služeb VS. Většina územních portálů by uvítala, kdyby vyhledávání (federované) bylo realizováno jako služba, respektive jako centrální komponenta. Pokud se jedná o možnost vyhledávání informací různými vyhledávacími službami (Google, Seznam.cz apod.), tak optimalizace pro tyto vyhledávače je spíše podprůměrná, většina portálů nemá informace zaindexované na těchto vyhledávačích. Pro oblast katalogu služeb VS, většinou chybí digitalizace agend daných portálů, případně legislativní zakotvení, a tak je namapování služeb příslušných portálů na katalog služeb VS opět spíše podprůměrné. Životní události jsou oproti tomu zastoupeny na většině portálů (ve větší či menší míře) a jsou dostupné převážně hned na úvodní stránce portálu. V případě územních portálů je nabízeno uživateli relativně shodné spektrum životních událostí, ze kterých může vybírat.

Oblast komunikace, respektive možnosti podání či vyzvednutí v portálu je funkce, která je specifická, respektive nově akcentovaná, a proto je dostupná pouze na vybraných portálech, jako je například PO, ePortál ČSSZ nebo portál města Říčany. Integrace DS je naopak funkce, která by byla většinou zástupců portálových řešení vítána, nicméně v dnešní době zatím není pro občany povinná, a to by její přínos v dnešní době snižovalo.

Informace a data o uživateli jsou inherentně nabízeny na portálech, nicméně jejich možnost doplnění samotným uživatelem je omezená. V případě implementace archivu dokumentů, které by mohli být vkládány uživatelem se zástupci portálů shodli, že by tuto funkci uvítali, v ideálním případě opět jako centrální komponentu. Funkce kalendáře je aktuálně zastoupena ve větší míře na portálech, kde slouží primárně k informačním účelům o nadcházejících událostech, či chystaných akcích. Informace a data pak nejsou přenášeny na ústřední dashboard, touto funkcí nedisponuje téměř žádný agendový ani územní portál, naopak soukromé portály po přihlášení nabízí uživateli různé přehledy stylizované do dashboardu. Toto je oblast, která by měla být, v případě prvně jmenovaných portálů, zásadně vylepšena. Oblast notifikací je aktuálně nejlépe zastoupena na soukromoprávních portálech, zde má uživatel na výběr mnoho komunikačních kanálů. Krok s těmito portály drží PO, ostatní portálová řešení nedisponují tak propracovaným systémem notifikací a spíše by uvítali tuto funkci jako službu, tedy centrální komponentu, tak jak je popsána v kapitole 4.

Portály v dnešní době disponují, ve většině případů, možností hodnotit poskytnuté informace na portálu, případně zaslat podněty pro vylepšení portálu. V případě hodnocení poskytnuté služby se většina zástupců portálů přiklání k tomu, aby tato funkce byla poskytnuta centrálně (jako komponenta) a hodnocení bylo přímo navázáno na katalog služeb VS.

Oblast zastoupení neboli mandáty je funkce, kterou v dnešní době, v omezené míře poskytují vybrané portály – Mojedaně.cz či ePortál ČSSZ. Funkce by byla vítána u všech portálů, nicméně pro její realizaci je nutné legislativní zakotvení a digitalizace služeb a agend. Funkce by měla být, jako některé již výše zmíněné, nabízena jako centrální komponenta.

Z pohledu informační architektury mají jednotlivé typy portálů shodně organizovaný obsah a strukturu informací, nicméně v případě územních portálů jsou značné rozdíly v navigaci a také jmenné konvenci dílčích oblastí, a to může být pro uživatele matoucí. Ke smazání těchto rozdílů by mohl pomoci designsystem.gov.cz, nicméně mezi zástupci portálů (územní a agendové) není tak známý, ale přechod na něj je vítaný. Obdobu design systemu mají například v bankovnictví, klient se pak snáze orientuje na portálech bank, a to i díky shodné jmenné konvenci a strukturování obsahu. Z tohoto pohledu by portály VS měli následovat soukromoprávní portály, které mají tuto oblast velice propracovanou.

Personalizace portálů v dnešní době probíhá primárně u územních portálů, a to po přihlášení uživatele, kdy mu je nabízen relevantní digitální obsah. Automatizovaná nabídka služeb a informací na základě chování ostatních klientů je dostupná pouze na soukromoprávních portálech, nicméně touto funkcí by měly disponovat minimálně centrální a územní portály. Portály jsou dále v malé míře lokalizovány do cizích mutací, převažuje anglický jazyk. Překlady jsou realizovány prostřednictvím funkcionality Google překladače, u soukromých portálů se jedná o nativní překlady. Oblast SEO je centrálních, územních a agendových portálů oblast, která nyní není rozvinuta, využívá se pouze základních nástrojů a postupů. Nicméně zástupci portálů se shodují, že je to oblast, které je potřeba se věnovat, a to i z toho důvodu, aby informace z portálů byly dohledatelné prostřednictvím vyhledávačů, jak již bylo zmíněno v odstavci o vyhledávání informací.

Z pohledu úrovně zabezpečení je v tuto chvíli citelný rozdíl mezi většími portály veřejné správy (např. ČSSZ, Moje Daně, PVS/PO), které jsou obvykle identifikovány jako významný informační systém a zákonné bezpečnostní požadavky ZKB a VoKB splňují, a portály územními či soukromoprávními, které takto určeny nejsou. Jistou výjimku zde tvoří bankovní portály, které se chovají podle pravidel VIS, protože bezpečnost vnímají jako zcela zásadní pro vytvoření důvěry mezi uživatelem portálu a organizací.

Územním či některým soukromoprávním portálům chybí především znalosti a možnosti pro vytvoření či nasmlouvání bezpečnostního týmu se znalostí problematiky bezpečnosti portálů. Zde by pomohla prakticky orientovaná metodika bezpečné tvorby portálových řešení, a především centrálně dostupný sdílený kód, který by obsahoval připravená řešení dílčích částí portálů.

Portály, které obsahují autentizovanou sekci již obvykle využívají přihlášení pomocí NIA, někdy však pouze v režimu Same-Sign-On a často bez možnosti bezešvé navigace pomocí deeplinku na konkrétní informaci na odkazovaném portále. Bezešvý přechod do autentizované části soukromoprávních portálů bez zákonné povinnosti ztotožnění je technicky realizovatelný, za předpokladu, že oba portály využívají stejného kvalifikovaného správce (IdP) a portál takovou variantu bude podporovat.

Výměna dat mezi portály s využitím back-endových služeb, je u velkých portálů již implementovaná, nebo snadno implementovatelná, protože navrhovaná technická řešení již využívají, u menších portálů je naopak limitující rozsah požadavků a komplikovanost přistoupení.

Seznam oblastí, kterými je nutné se zabývat, aby bylo dosaženo cíle popisovaného v tomto dokumentu, je rozsáhlý a vyžaduje stanovení priorit, realistický výběr konkrétních problémů k řešení a odhad času řešení a v neposlední řadě nalezení široké podpory, což nebylo dosud zmiňováno v předchozích částech dokumentu. Rozdíly mezi současným stavem vybraných portálových řešení a cílovým představuje především kapitola Funkce, které federované portály veřejné správy musí podporovat. Text v kapitole se zaměřuje primárně na oblasti, které byly vnímány v rámci rozhovorů se zástupci vybraných portálových řešení jako ty důležité, případně “zajímavé” a usnadňující uživatelům VS práci s nástroji VS. Nikde v textu se ale nezdůrazňuje významný aspekt dosažení úspěchu – spolupráci se skupinami vybraných portálových řešení a jinými skupinami podporujícími digitalizaci.

Následující text vybírá hlavní funkční a nefunkční požadavky, na které je potřeba se zaměřit na prvním místě a s jejichž realizací není dobré příliš otálet. Text nemá úmysl rozepsat všechny úkony, na to by bylo potřeba vynaložit úsilí nad rámec tohoto dokumentu.

Na první místo do roadmapy aktivit patří nastolení úzké spolupráce minimálně se skupinami, které byly součástí dotazníkové části práce a seznámeni jako první s konceptem federace portálů. Předpokládáme, že zadavatel připojí k těmto skupinám další, které nebyli k práci zatím přizvány, ale o nichž zadavatel ví, že splňují definici a na digitalizaci služeb VS se patřičným způsobem podílejí.

Na první místo roadmapy patří tedy zaměření se na lidi stejného smýšlení z různých částí VS a vytvoření meziresortní skupiny nebo nastolení takových podmínek, aby skupina těchto „nadšenců“ měla neustále aktuální povědomí o roadmapě a jejím naplňování.

Tento bod lze spustit bez čekání na jiná rozhodnutí nebo vnější vlivy, protože již nyní evidentně ke komunikaci s vybranými agendami dochází a má se za to, že zadavatel má představu o současné situaci a taktéž široká skupina agentových a územněsprávních řešení má povědomí o úloze zadavatele v digitalizaci VS.

Funkcionalita digitálních služeb VS, která rezonovala celou skupinou vybraných agentových a portálových řešení, byla uživatelem udělovaná digitální plná moc k provedení digitálního úkonu v zastoupení. Stojí za připomenutí, že ta rezonance byla vesměs negativní – v důsledku dlouhodobého a nejasného stavu v dané věci. Zároveň informace, že MVČR vydalo pokyny k analýze problému a hledání realizovatelného obecného řešení, byla vnímána velmi pozitivně a vzbudila nové očekávání.

Na první místo roadmapy z hlediska široce využitelné funkce digitální VS doporučují autoři dokumentu umístit aktivity vedoucí k vytvoření jednoho řešení registru mandátů, viz. služba e-Authorizations nebo také eMandates provozované v dotazovaných zemích (Finsko, Norsko a Dánsko) ve velmi obdobném řešení z pohledu technologické a procesní realizace.

Je potřeba zanalyzovat veškeré aktivity a „prozatímní“ řešení různých agendových IS a provést výzkumná šetření s uživateli různého typu a z rozličných oblastí občanského a podnikatelského života.

Uživatelé neočekávají, že registr bude umět vše a najednou. Stejně tak neočekávají, že registr bude umět vyřešit obecnou plnou moc na vše. Je ale potřeba v souladu s přechozím bodem komunikovat také směrem k budoucí uživatelům informace o plánovaném zavedení a postupném rozvoji registru mandátů.

Registr mandátů by měl být uveden nejpozději do 2 let, ideálně do 1 roku na vybrané digitální služby, jakkoliv v prostředí ČR je asi primárně nutné uzpůsobit k tomuto legislativu. Do konce volebního období, které začne volbami do PS ČR v říjnu 2021, by měl být registr mandátů vnímán jako plně funkční součást digitálních služeb VS.

Náklady na vybudování registru mandátů se hrubě mohou pohybovat v hodnotách jako náklady na vybudování současně používaných registrů, například registru obyvatel. Autoři dokumentu předpokládají, že by mělo být možné maximálně využit zkušeností, know-how, technologických a infrastrukturních zdrojů, které dnes obhospodařují základní registry a tím patřičně snížit náklady na realizaci registru mandátů. Podklady pro detailnější odhady autoři dokumentu neměli v rámci tohoto úkolu k dispozici.

Primárním cílem federace portálů je umožnit uživatelům portálů efektivně a přívětivě konzumovat digitální obsah a digitální služby VS. Aby tento cíl mohl být naplněn, je potřeba, aby všechny relevantní portály, tvořící budoucí federaci portálů, disponovaly možností přihlásit se prostřednictvím NIA. Jde o nutnou podmínku zajištění jediné formy přihlášení a díky tomu zajištění přenosu kontextu návštěvníka mezi portály.

Autoři dokumentu neumístili tento bod roadmapy na její první místo před registr mandátů, protože proces informovanosti o portále národního bodu pro identifikaci a autentizaci s rozrůstajícími se možnostmi různých prostředků identifikace a ověření uživatele již běží a podmínky jeho využívání jsou dobře popsány.

NIA tedy patří do roadmapy jaksi defaultně bez nutnosti definice konkrétního termínu dodávky explicitně popsaného rozvoje. K připojení do federace portálů se ale uvažuje o portálech, které musí vedle implementace NIA splňovat také minimální bezpečnostní požadavky.

V průběhu analýzy současného stavu portálových řešení byly identifikovány podstatné rozdíly v oblasti bezpečnosti mezi většími portály veřejné správy (např. ČSSZ, Moje Daně, PVS/PO), které jsou obvykle identifikovány jako významný informační systém a zákonné bezpečnostní požadavky ZKB a VoKB splňují a portály územními či soukromoprávními, které takto určeny nejsou (např. PPAS, VZP, portál města Říčany). Roadmapa v otázce adopce pravidel pro zajištění federace portálů může být rozdělena do dvou skupin. Tímto rozdělením může být zjednodušena výstavba federace portálů minimálně v tom, že komunikace o povinnostech, podmínkách, know-how apod. s rozdílnými skupinami bude jiná. Stejně tak bude jiné prověřování správné realizace konkrétních bezpečnostních oblastí. To rozdělení je:

• Portály, které jsou identifikovány jako významný informační systém (VIS) a zákonné bezpečnostní požadavky ZKB a VoKB splňují většinu pravidel z oblasti bezpečnosti.
• Portály, které nejsou identifikovány jako VIS a mají nižší standardy zabezpečení

Dále je možné rozlišit skupinu portálů na ty, které mají autentizovanou sekci, a na ty, které mají všechny informace veřejně dostupné. U portálů, které nemají žádné přihlášení pro uživatele portálů, není nutné řešit kroky týkající se využívání NIA. Ostatní kroky však nutné řešit je, aby nedošlo ke snížení bezpečnosti federované organizace.

Z hlediska priority je důležité nejprve v roadmapě řešit portály identifikované jako VIS, do skupiny patří hlavní agendové portály, které jsou v digitalizaci nejdále a jsou silně vnímány uživateli VS. Je potřeba podporovat a pomoci těmto portálům s přechodem na NIA, pakliže využívají dnes jiné autentizační metody. Je potřeba jim dále pomoci s definicí a implementací seznamu pravidel federace pro danou skupinu, s implementací metodik tvorby bezpečného kódu, provádění bezpečnostních testů (penetrace, specifické zranitelnosti webových aplikací), bezpečných konfigurací např. https protokolu apod. Jinými slovy, pro zpřehlednění implementačních kroků je potřebné v roadmapě odzkoušet nejsložitější skupinu portálů a pro ně vytvořit například seznamy relevantních pravidel. Jak je již čtenáři asi jasné, rozdělení portálů naznačeného v textu této kapitoly rozděluje také implementaci pravidel uvedených v jednotlivých kapitolách tohoto dokumentu.

Z časového hlediska je potřeba úkoly týkající se bezpečnosti splnit do 1 roku od zahájení realizace federace, aby nedocházelo ke zpoždění zapojování těch portálů, které jsou již na celou řadu podmínek připraveny. Pro ostatní portály by měly být veškeré bezpečnostní podmínky, procesy a úkony připraveny do 2 let od zahájení realizace federace.

Prioritu na roadmapě má mít definice informační architektury a dokončení jednotného design systému pro celou digitální VS. Jedná se o podpůrnou oblast, ale téma má v současnosti největší vliv na tvorbu webových a mobilních aplikací. Jak stoupá množství digitálních úkonů, je potřeba adekvátně zvyšovat pozornost tomu, zda používání aplikace uživatele reálně psychicky a fyzicky zatěžuje a ovlivňuje tak míru jeho ochoty aplikaci použít opakovaně. Ve federaci portálů je potřeba na minimum eliminovat stav, aby se uživatel přecházející mezi portály musel znovu zorientovat v tom, co se kde nachází a jak se na portále pohybovat.

Mnoho bylo v praxi vyzkoušeno (designsystem.gov.cz, portál ČSSZ), existují příklady hodné následování (komponenta životních událostí na Portále občana). Jde o oblast s nižší investicí, než například implementace vyhledávání informací nebo registru mandátů, ale s ohromujícím odpadem na vnímání VS ze strany uživatelů.

Do 1 roku od zahájení realizace federace je potřeba dokončit jednotný design systém v plném slova smyslu, jak o tom hovoří patřičná kapitola, např. také s rozšířením přípravy komponent až po vývojový kód dnes nejvíce rozšířených front-endových technologií (React, Vue.js., apod.).

Definice společné informační architektury představuje složitější komunikační problém, který by měl být rozdělen na fáze a jedna z těchto prvních fází by měla určit základní společné prvky digitálních služeb VS, jako je umístění a obsluha přihlášení pomocí NIA, umístění a fungování (nebo odkazy) na základní centrální komponenty jako jsou notifikace, datové schránky, seznamy životních událostí a služeb apod.

První fáze definice informační architektury by neměla překročit 1 rok od zahájení realizace federace, další fáze bude zřejmě trvat déle, už jenom kvůli počtu a variabilitě agend, ale neměla překročit toto volební období.

Při diskuzích s NAKIT a se zástupci vybraných portálových řešení vyplynulo, že vyhledávání „nějak funguje”. Oblast byla rozsáhle popsána v samostatné kapitole, zde jen pro připomenutí hlavních cílů.

Ve skutečnosti lze z testů řešení potvrdit, že v implementaci vyhledávání je velký prostor ke zlepšení vnímání digitální VS. Vyhledávání u rozsáhlých agend představuje náročnou disciplínu, a o to více přes celou federovanou organizaci. Ve skutečnosti nehovoříme o vyhledávání, ale o nabízení výsledků, které uživatel pravděpodobně potřebuje najít. K tomu je nutné implementovat rozsáhlé procesní a technologické know-how.

Z důvodu této náročnosti je nutné vybudovat tým pro vyhledávání, který vytvoří centrální procesy, postupy a centrální komponenty a/nebo služby. Pokud to nebylo explicitně popsáno, tým vyhledávání navazuje na práci dalších týmů, jako je například UX/UI tým definující design systém, na procesy nebo týmy vyhodnocující zpětnou vazbu atd. Získané know-how tým vyhledávání nabízí bezplatně ostatním portálovým řešením, čímž posiluje spolupráci popsanou v první kapitole této části textu. Tým se musí zabývat také optimalizací vyhledávání informací prostřednictvím internetových vyhledávačů (Google, Seznam apod.) – nezanedbatelnou přidanou hodnotou je spolupráce celé federované organizace na problémech se správným fungováním SEO.

Vyhledávání představuje personálně, procesně, technologicky a finančně nejrozsáhlejší disciplínu. Do roadmapy patří její start na jednu z prvních pozic, protože její časová náročnost je rozsáhlá a nemusí se brzy dostavit měřitelné výsledky a vnímání na straně uživatelů. Dá se předpokládat možnost postupné a paralelně běžící realizace vůči ostatním částem roadmapy.

Z hlediska nějakých hrubých odhadů, na prvním místě nabrání patřičného počtu specialistů (odhadem 30+) přesáhne 1 rok, reálně bude úspěch dotáhnout nábor do plných počtů do 2 let. Je nezbytné k tomu zajistit podmínky co nejdříve: nákladově půjde o postupný náběh na hrubě odhadovanou částku až 70 mil. Kč ročně (vč. (techniky osobního a komunikačního charakteru), zadavatel si přidá náklady za prostory apod. Výše uvedený počet nerozlišuje mezi pracovníky MVČR a externími specialisty najímanými na konkrétní odborné práce.

Projekt výstavby infrastruktury a s tím souvisejících všech potřebných částí realizace vyhledávání by za předpokladu existence týmu specialistů bylo možné stihnout do 2 let od zahájení realizace federace. S náběhem náboru lze předpokládat prodloužení na více než 2 roky, ale realizace by neměla překročit volební období. Není zde nutná žádná zásadní legislativní úprava a výsledek může šetřit na jednotlivých agendových, jiných územněsprávních a jiných portálech.

Náklady na vybudování infrastruktury pro zajištění vyhledávání nelze stanovit přesně na základě tohoto dokumentu. Následující čísla odrážejí následující předpoklady:

• realizace pro největší agendové IS (jejich portály) + portály krajských úřadů a statutárních a krajských měst (do 50 ks portálů – vlastně těch největších);
• vytvoření a provoz infrastruktury zajišťující výpočetní výkon formou PaaS pro výše uvedený počet;
• procesy pomáhají s problematikou vyhledávání a SEO, help-desk procesy, knowledge base apod.;
• využití Private Cloud služeb pro vše výše vyjmenované od jednoho ze světových cloud dodavatelů (Google Cloud, Amazon AWS, Microsoft Azure);

Hrubé odhady nákladů:

• provoz infrastruktury (iniciální vytvoření): do 10 mil. Kč / ročně; postupný náběh;
• provoz podpůrných nástrojů, licenční požadavky: do 5 mil. Kč / ročně; další růst zanedbatelný;
• SW + konfigurace, implementace know-how vyhledávání: do 10 mil. Kč /1–2 roky; nad náklady na tým viz. výše;
• komunikace s federovanými portály, help-desk procesy, udržování knowledge base: do 5 mil. Kč / ročně; nad náklady na tým viz. výše.

Obrázek 38: Indikativní vizualizace roadmapy aktivit, respektive realizace jednotlivých výše popsaných oblastí.

Obrázek 39: Indikativní počet osob a vynaložených nákladů na následující období 5 let.