Obsah

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

Manažerské shrnutí

Shrnutí cílů projektu a cílů federace a Shrnutí závěrů

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:

Shrnutí definic, zejména portálu a federace

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ů.

Shrnutí právních aspektů

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.

Shrnutí funkčních požadavků

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.

Shrnutí vybraných klíčových pravidel

Úč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:

Shrnutí nezbytných předpokladů proveditelnosti pravidel

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:

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.

Shrnutí zahraničních zkušeností

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ů.

Shrnutí posouzení stávajícího stavu vybraných 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ů.

Shrnutí Roadmapy – cesty k federaci 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ňů.

Společenské souvisloti projektu

Připravenost občanské společnosti na digitalizaci

Ř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.

Motivy digitalizace

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.

Vnímání veřejné správy

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 apod1). 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

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.

Největší dopad za nejmenšího úsilí

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.

Centralizace a decentralizace

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.

Postavení eGov ve strategii digitalizace veřejné správy

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.

Co je to portál a jaké funkce jej definují

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:

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 ČR2). Přestože, že jsou tyto integrace jsou nezbytné pro komfortní výkon služeb, směřujících ke kvalitě dle ÚEP3), 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 Experience4) (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ě NIA5)), včetně její mezinárodní brány6), 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é.

Centrálně garantované komponenty řešení

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.

Pravidlo Definice a zprovoznění katalogu centrálních komponent
Platí pro eGov (Federující portál)
Technický důsledek Budou vypracována metodická pravidla jednak pro vznik a provoz centrálních komponent v kontextu odpovídajícího technologického řešení, požadované úrovně bezpečnosti apod, a dále budou vytvořena metodická pravidla pro práci s centrálními komponentami, která budou zveřejněna pro implementátory např. na archi.gov.cz.
Bezpečnostní důsledek U každé komponenty jsou popsána pravidla a postupy pro její bezpečnou implementaci do federujícího portálu a implementace služeb sdílené komponenty do federovaného portálu7). Těmito jsou její uživatelé povinni se řídit.

Při vývoji komponenty je dodržena metodika tvorby bezpečného kódu pro státní správu.
Právní důsledek S ohledem na pravděpodobnou povahu federujícího portálu jako významného informačního systému, bude nezbytné splnit povinnosti vyplývající ze ZKB a jeho prováděcích právních předpisů (VoKB), zejména zavést a provádět bezpečnostní opatření, určit bezpečnostní role (manažera a architekta kybernetické bezpečnosti, garanta aktiv, ad.), vést bezpečnostní dokumentaci, detekovat a hlásit NÚKIB kybernetické bezpečnostní incidenty a případně provádět příslušná nápravná opatření.

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ě.

Pravidlo Centrální komponenty, resp. federující portály implementují podrobný monitoring činnosti a využívání
Platí pro Federující a federované portály.
Technický důsledek Technologická řešení centrálních komponent vytváří rozhraní pro napojení (interních) jiných systémů VS na výsledky monitoringu provozu, především komunikaci od/k uživateli nebo mezi portály obecně.
Bezpečnostní důsledekMonitoring může být v rozporu s GDPR. Monitoring nesmí být prováděn s využitím veřejných služeb typu Google Analytics.
Právní důsledek Zejména pro federující portál (a v závislosti na naplnění kritérií pro informační systémy v ojedinělých případech tomu tak může být i pro federované portály) bude třeba zavést detailní monitoring činností s ohledem na ZKB a VoKB, a to v rozsahu dle § 22 VoKB. Dále bude třeba zajistit zejména 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.

Centrální komponenty a Omnichannel obslužných kanálů

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.

Centrálně dostupné otevřené zdrojové kódy komponent portálů

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“8). 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.

Pravidlo Využívání oficiálního úložiště centrálně dostupných sdílených kódů (Source Safe), otevřených (nebo pod patřičnou licencí)
Platí proVšichni

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ě

Bezpečnostní důsledekDefinovat pravidla pro bezpečné použití zdrojových kódů.

Definovat adaptační pravidla pro využívání open source řešení.

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.

Relevantní právní úprava portálů v současnosti

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í.

Informační koncepce ČR

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án9) a Národní architektonický rámec10), 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.

Digitální (elektronické) služby, úkony a doručování

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).

Identifikace a autentizace

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.

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

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.

Informační a související povinnosti provozovatelů portálů

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)11), 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ů).

Zákonný účel Portálu veřejné správy a Portálu občana

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.

Využití referenčního rozhraní veřejné správy

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.

Hierarchická struktura federovaných portálů

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.

media_image132.jpg

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.

media_image133.jpg

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.

Ne-závislost portálů ve federaci

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”.

Pravidlo Nezávislost portálů ve federaci
Platí pro
Technický důsledek
Bezpečnostní důsledek
Právní důsledek Pravidlo reflektuje požadavky stanovené ZKB a VoKB a uplatní se zejména ve vztahu k sitauaci, naplní-li federující/federovaný portál definici významného informačního systému.

Současně pravidlo vychází z požadavků stanovených ZoPISMA.
Pravidlo Nezávislost portálů na centrálních sdílených službách
Platí pro
Technický důsledek
Bezpečnostní důsledek
Právní důsledek Pravidlo reflektuje požadavky stanovené ZKB a VoKB a uplatní se zejména ve vztahu k situaci, naplní-li federující/federovaný portál definici významného informačního systému.

Současně pravidlo vychází z požadavků stanovených ZoPISMA.

Funkce, které federované portály veřejné správy musí podporovat

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:

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í.

Vyhledávání

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:

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 SEO12), 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 klade na federující a federované portály úkol využívat vedle sebe oba zmíněné jazyky.

Realizace tohoto nemusí být snadná.

Pravidlo Definice a vytvoření zaměření nebo oddělení zaměřeného na problematiku SEO.
Platí pro Federující a federované portály
Technický důsledek Jde o legislativně-procesní pravidlo, jehož technické důsledky spočívají ve vybavenosti oddělení 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ů.
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků na činnost federujících a federovaných portálů.
Pravidlo Portály systematicky řeší jednotlivé principy technického SEO.
Platí pro Federující a federované portály
Technický důsledek Nutnost implementovat funkce, které řeší technické

SEO
Bezpečnostní důsledekImplementovat bezpečnostní principy, které ovlivňují technické SEO.
Právní důsledek Ve vztahu k federujícímu portálu za předpokladu naplnění povinností vyplývajících z předpisů zabývajících se ochranou osobních údajů, ZKB, a prováděcích právních předpisů bez dalších právních důsledků.
Pravidlo Portály si vypracují SEO obsahovou analýzu, aby se mohly v textu používat vyhledávaná slova.
Platí pro Federující a federované portály
Technický důsledek Úprava veřejně dostupných obsahů
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků na činnost federujících a federovaných portálů.

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ě.

media_image143.jpg

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

Pravidlo Definice a zprovoznění centrálního oddělení zodpovědného za komplexitu vyhledávání přes federující a federované portály
Platí proeGov (Federující portál)

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ů.

Bezpečnostní důsledekV rámci zprovoznění centrálního oddělení je třeba zvažovat nad všemi aspekty bezpečnosti a ochrany dat, která se v rámci vyhledávání budou zpracovávat.

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

Pravidlo Definice struktur parametrů v URL a Cookies
Platí pro Federující a federované portály
Technický důsledek Proměnné, které mají být využívány při přenosu transakčního kontextu (životní role, služby VS, role uživatele apod.), musí mít centrálně definovaný tvar pro přenos kontextu a jeho zpracování.

Proměnná, která není dnes definována jako známý číselník (role), musí být do-definována, aby její použití bylo jednoznačné.
Bezpečnostní důsledek-
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB, VoKB a předpisů upravujících ochranu osobních údajů bez dalších právních dopadů.

Pravděpodobně bude nutné „natvrdo“ zakázat jakékoliv významové údaje v URL, URI a cookies. Údaje budou muset být uloženy v důvěryhodném prostoru a předávány budou pouze bezvýznamové

„šatní lístky“.
Pravidlo Definice 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
Platí pro eGov (Federující portál)

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.

Bezpečnostní důsledekZajištění bezpečnosti nově budovaného centrálního řešení s ohledem na charakter a množství agregovaných dat, která v něm budou pro potřeby vyhledávání zpracovávaná.

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).

Ve vztahu ke zpracovávaným datům se s ohledem na postavení federujícího portálu jako významného informačního systému uplatní rovněž kritéria ZKB a VoKB, -především stanovení pravidel pro obnovení či likvidaci dat; s ohledem na možné komplexní vztahy s dodavateli systémů bude třeba pamatovat též na úpravu oprávnění data užívat (v rámci bezpečnostních opatření pro smluvní vztahy dle Přílohy č. 7 VoKB).
Pravidlo Všechny portály využívají centrálně definovanou strukturu indexu
Platí proFederující a federovaný portál

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

Bezpečnostní důsledekCentrální index musí rozlišovat, zda jsou indexovaná data veřejná, či z autentizované části portálu. Při tvorbě indexu autentizované části musí index respektovat úroveň záruky (dále jen Level of Assurance (LoA)).

Vyhodnocení výsledků vyhledávání provádí kontrolu na autorizaci uživatele a respektuje LoA (Level of Assurance).

Při vyhledávání jsou nabídnuty všechny výsledky, ale v případě, že se jedná o výsledek z autentizované části vyžadující vyšší úroveň LoA, nesmí být zobrazen náhled a musí být zobrazena informace o této skutečnosti.

Agregací indexovaných dat v autentizované části indexu nesmí dojít ke snížení úrovně zabezpečení osobních údajů.

Indexy mohou být ukládány nešifrované, pokud by toto mělo vliv na výkonnost vyhledávání.

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ému13)), které takové oprávnění údaje užívat založí.

Další právní důsledky jsou spojeny s personalizací výsledků vyhledávání uživatelů služeb (tyto aspekty řešíme níže).
Pravidlo Zajištění aktualizace dat centrálně definovaného indexu, resp. synchronizace dat mezi portály
Platí proFederující portál

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ů.

Bezpečnostní důsledekAktualizace (resp. synchronizace) dat musí probíhat bezpečným kanálem bez možnosti narušení. Je možné, že pro aktualizace indexu nebude dostačující stávající řešení eGSB / ISSS a bude nutné jej modifikovat na jiný princip než požadavek-odpověď.

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.

Pravidlo Vyhodnocení relevantnosti portálu pro vyhledávání
Platí pro Federující portál a federovaný portál
Technický důsledek Federující portál spravuje seznam dostupných portálů s jejich popisem např. příslušnost k agendě. Dle hledaného výrazu zvolí vhodné kandidáty, kterým zaslat dotaz hledaný výraz.
Bezpečnostní důsledek-

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.

Pravidlo Skórovací engine rozhodne o seřazení výsledků
Platí pro Federující portál (centrální komponenta a služba)
Technický důsledek Definice kritérií pro optimalizaci řazení výsledků, odebrání duplicitních a nerelevantních výsledků. Všechny výsledky jsou následně sloučeny do jednoho a prezentovány.
Bezpečnostní důsledekSkórovací engine pracuje s možností otrávení výsledků vyhledávání podvržením podvodného obsahu do výsledků vyhledávání.
Právní důsledek Za předpokladu naplnění povinností vyplývajících ze ZKB a prováděcích právních předpisů bez dalších právních důsledků.

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.

Pravidlo Stránka s výsledky umožní uživateli filtrovat seznam výsledků, aby si byl schopen zúžit seznam dostupných odpovědí.
Platí pro Federující portál (centrální komponenta a služba)
Technický důsledek Výsledky musí obsahovat kategorie, štítky, zdroj dat. Aplikace filtru se musí pamatovat a propagovat při průchodu stránkami výsledků.
Bezpečnostní důsledekFiltr seznamu je neperzistentní a je zahozen po provedení vyhledávání.
Právní důsledek S ohledem na personalizaci výsledků a obsahu 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).
Pravidlo Ve výsledcích vyhledávání se umožní uživateli obdržet výsledky sloučením výsledků z jeho privátní části (podléhající autorizací) centrálních komponent
Platí pro Federovaný portál
Technický důsledek Centrální komponenty poskytují službu pro vyhledávání, která vyhledává v privátních datech uživatele, tyto výsledky mohou být vřazeny do výsledků vyhledávání.
Bezpečnostní důsledekVyhledávání v oblasti dat podléhající autorizaci je delegováno na federovaný a mezivýsledky nejsou ukládány do centrálního indexu.
Právní důsledek Tato funkcionalita bude možná pouze po přihlášení skrze NIA a s ohledem na její prakticky neomezený rozsah bude nezbytná vhodná formulace souhlasu se zpracováním osobních údajů, neboť nebude možné spoléhat se výlučně na zákonné důvody. Vzhledem k možnému dosahu může takto formulovaný souhlas narážet na limity zásady minimalizace zpracování osobních údajů.

Současně bude třeba zajistit souhlas uživatelů služeb s poskytnutím jejich údajů ze základních registrů v souladu se ZoZR.

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í.

media_image145.jpg

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.

Pravidlo Všechny portály pro zobrazení katalogu služeb využívají API z RPP
Platí proFederující a federovaný portál

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

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

Bezpečnostní důsledekJsou splněna pravidla pro tvorbu bezpečného API, kde je možné využít relevantní části projektu

OWASP API Security a patřičných částí OWASP Cheat Sheet poplatných použitému protokolu (REST, SOAP atp.)

Volání API je realizováno s využitím šifrovaného přenosu.

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.

Pravidlo Lokální služby jsou publikovány do RPP (AIS katalogů)
Platí pro Federované portály
Technický důsledek Jednotlivé portály měly zobrazovat pouze pro ně relevantní filtrované služby.

Nutnost respektovat metodiku popisu dle MV ČR.
Bezpečnostní důsledek-
Právní důsledek Pouze upozorňujeme, že tato funkcionalita předpokládá řádné ohlášení agend OVM, tedy včetně správného vyhodnocení zákonného základu pro výkon určité agendy (a odpovídající zápis agendy v katalogu služeb).

Tedy včetně lokálních služeb samospráv, neupravených centrálně zákonem.

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.

Platí proFederující a federované portály

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

Bezpečnostní důsledekPři vývoji komponenty by měla vzniknout doporučení, jak bezpečně implementovat či integrovat komponentu (podle formy jakou je centrálně garantovaná komponenta distribuována) do portálu.

Při implementaci či integraci komponenty, jsou dodržena doporučení pro bezpečnou implementaci či integraci.

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:

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.

media_image148.jpg

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.

Pravidlo Životní události jsou popsány na jednom místě v AIS katalogů, kde se rovnou mohou odkazovat na

VS případně na služby samosprávy popsané v RPP.
Platí pro Federující a federované portály
Technický důsledek Komunikace s RPP probíhá skrze eGSB / ISSS
Bezpečnostní důsledek-
Právní důsledek K dané problematice neexistuje v plném rozsahu v současnosti příslušný právní základ.
Pravidlo V případě, že portál nezobrazuje úplný seznam služeb k dané životní události, tak je povinen zobrazit odkaz na přechod na úplný seznam služeb k uživatelově zobrazované životní události.
Platí pro Federující a federované portály
Technický důsledek Implementace deeplinku se zachováním kontextu.
Bezpečnostní důsledek-
Právní důsledek K dané problematice neexistuje v plném rozsahu v současnosti příslušný právní základ.

Ž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í.

Komunikační kanály klienta s veřejnou správu

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:

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.

Pravidlo Služba elektronického doporučeného doručování

(Datová schránka) bude dostupná i na federovaných portálech
Platí proFederované portály

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á.

Bezpečnostní důsledekPropojení datových schránek bude realizováno s využitím Přístupového rozhraní ISDS tak, aby se uživatel nemusel přihlašovat přístupovými údaji k datové schránce.

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 § 314), 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.

Informace o klientovi

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 registrech15).

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

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.

Pravidlo Orgán veřejné správy definuje sadu atributů týkajících se klientů, které zpřístupní federujícím portálům.
Platí pro Federované portály (inherentně pak i federujícímu portálu).
Technický důsledek Agendový informační systém se musí připojit na eGSB/ISSS.
Bezpečnostní důsledek-
Právní důsledek Takto zpřístupněné atributy klientů bude třeba limitovat výlučně tak, aby byly zpřístupňovány údaje, k nimž bude mít dotazující se portál příslušná oprávnění (zejména na základě zápisu příslušné agendy v katalogu služeb, zákona či souhlasu poskytnutého uživatelem služby).

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

Pravidlo Portál je schopen voláním URL zobrazit konkrétní stránku.
Platí proFederující a federované portály

Portál implementuje pro tyto potřeby statické

Technický důsledek

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

Bezpečnostní důsledekJe 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í 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.

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.

Pravidlo Persistence uživatelem definovaných základních parametrů chování centrálních komponent a jejich přenosu na federované portály (ovlivnění chování federovaných portálů dle těchto parametrů)
Platí pro Federované portály
Technický důsledek Federované portály přebírají z federujícího portálu informace/parametry ovlivňující chování federovaných portálů nebo jejich agend. (Pozn. Toto nemá vliv na funkčnost, pokud federující portál nefunguje).

Federované portály upouštějí od využívání (duplicity) svých lokálních řešení persistence podobných informací/parametrů, pokud je implementovaly před federovaným řešením.
Bezpečnostní důsledekVeškerá klientem vkládaná data a soubory musí být kontrolovány na přítomnost škodlivého kódu (antivirová kontrola).
Právní důsledek Vzhledem k tomu, že toto ukládání dat nebude v souvislosti s a na základě výkonu konkrétní zapsané agendy, bude nezbytné v tomto směru uživatele služeb dostatečně poučit o takovém zpracování osobních údajů. Vzhledem k možnému rozsahu může tato funkcionalita narážet na limity minimalizace zpracování osobních údajů.

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

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.

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.

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).

Pravidlo Federující portál zobrazuje přehled všech učiněných podání uživatele.
Platí pro Federující portály
Technický důsledek Vytvoření centrálního seznamu (centrální komponenty) učiněných podání, resp. úložiště metadat o učiněných podáních. Záznamy se do seznamu učiněných podání dostanou až v momentě, kdy je oficiální cestou podání doručeno (fyzicky nebo elektronicky).

Úložiště poskytuje zápisové rozhraní přes eGSB/ISSS.
Bezpečnostní důsledekKomponenta pracuje pouze s metadaty učiněných podání.
Právní důsledek Bude nezbytné zajistit naplnění § 5 ZPDS předpokládaných parametrů, tj. možnosti osvědčení digitálního úkonu a umožnění uživateli prokázání právní skutečnosti (tj. učinění podání) ve smyslu § 9 ZPDS a funkcionality by tak měla umožňovat rovněž výpis takového přehledu.

Současně upozorňujeme, že pro federující portál bude třeba pamatovat na zákonné povinnosti dle ZKB a VoKB, v tomto ohledu zejména v souvislosti s obnovením dat po kybernetickém bezpečnostním incidentu (viz § 15 VoKB).

Je třeba zohlednit skutečnost, že výše uvedené povinnosti ukládá ZPDS v § 3 poskytovateli (OVM) digitální služby, nikoliv federaci portálů, respektive federujícímu portálu.
Pravidlo Federované portály poskytují detail učiněných podaní daného uživatele.
Platí pro Federované portály
Technický důsledek Portály jsou připojené na eGSB/ISSS.

Portály při učinění podání notifikují centrální komponentu učiněných podání a zašlou metadata o učiněném podání.

Portály mají implementované fail-tolerance mechanismy, aby nedocházelo ke ztrátě informace o podání.
Bezpečnostní důsledekPortál splňuje požadavky na připojené na eGSB/ISSS
Právní důsledek V tuto chvíli neexistuje právní základ pro vytvoření centrálního úložiště učiněných podání. Bude nezbytné zajistit naplnění§ 5 ZPDS předpokládaných parametrů, tj. možnosti osvědčení digitálního úkonu a umožnění uživateli prokázání právní skutečnosti

(tj. učinění podání) ve smyslu § 9 ZPDS a funkcionality by tak měla umožňovat rovněž výpis takového přehledu.

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.

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.

Pravidlo Portál umožní uživateli uložit si u něj dokumenty.
Platí proFederující a federované portály

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.

Bezpečnostní důsledekOsobní prostor využívá technická opatření zamezující kompromitaci (ztrátě dostupnosti, důvěrnosti či integrity) dat z datového prostoru. Jako důkaz existence odeslaného dokumentu v daném čase je využito elektronické časové razítko. Jako záruka původu a integrity odeslaného dokumentu je využita elektronická pečeť.

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.

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.

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.

Pravidlo Portály by měly umožnit sdílet u nich uložený dokument s úředníkem.
Platí proFederovaný a federující portál

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.

Bezpečnostní důsledekGenerování zabezpečených odkazů (nelze poznat cestu k dokumentu, mají časovou platnost a lze jim omezit přístup na vybranou organizaci) využívá k tomu určené bezpečné metody.

U odkazů je možné definovat oprávnění přístupu kro konkrétní uživatele či pro všechny uživatele, kteří mají k dispozici odkaz.

Procházení zabezpečených odkazů je chráněno řešením pro detekci a prevenci útoků.

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:

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í.

media_image158.jpg

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.

Pravidlo Personalizovaná část dashboardu je přístupná pouze za přihlášením.
Platí pro Federující a federované portály.
Technický důsledek Portály implementují autentizovanou část a struktury potřebné pro sestavení dashboardu a jeho jednotlivých částí.
Bezpečnostní důsledekUložení personalizovaných dat je možné s dodržením principu pseudonymizace.
Právní důsledek S ohledem na rozsah možných údajů, na jejichž základě bude nabídka dashboardu personalizována, bude nemožné spoléhat na zákonné zmocnění k užití

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í.

Pravidlo Po přihlášení na úvodní obrazovce lze dále zobrazovat i přehled volně dostupných informací.
Platí pro Federující a federované portály.
Technický důsledek Implementace autentizované části nevylučuje pohyb po veřejné části portálu po dobu platnosti přihlášení.
Bezpečnostní důsledek-
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB a VoKB bez dalších právních dopadů.

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.

Pravidlo Po přihlášení portál na úvodní obrazovce zobrazuje přehled volně dostupných informací a přehled informací vztažených ke konkrétnímu subjektu práva z daného portálu a z dostupných napojených

IS.
Platí pro Federované portály.
Technický důsledek Implementace autentizované části nevylučuje použití veřejných dat a dat vztažených ke konkrétnímu subjektu práva a jeho roli.
Bezpečnostní důsledek-
Právní důsledek Vycházíme z předpokladu, že v rámci federovaných portálů tak budou čerpány údaje výlučně v souvislosti s výkonem příslušných agend, které OVM v rámci daného portálu vykonává, resp. na základě uděleného souhlasu (či jiného zákonného právního titulu).

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.

Pravidlo Po přihlášení portál na úvodní obrazovce zobrazuje přehled volně dostupných informací a přehled informací vztažených ke konkrétnímu klientovi z dostupných napojených IS.
Platí proFederující portály.

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.

Bezpečnostní důsledekPortály poskytující data musí být registrované v portálu zobrazujícím data.

Zobrazující portály musí ověřovat, že data pocházejí z portálu poskytujícího data.

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:

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í.

Pravidlo Pokud se zobrazuje pouze agregovaná informace, tak musí existovat stránka nebo stránky, kde si uživatel může dohled větší detail.
Platí pro Federující a federované portály.
Technický důsledek 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. Výpadek libovolného portálu, který poskytuje agregovaná data, nesmí znemožnit funkčnost federujícího portálu.
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků.

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

Pravidlo Portál může poskytnout sadu různých agregovaných informací v Dashboardu, které si může uživatel dle jeho zájmu zobrazovat na úvodní stránce.
Platí pro Federující a federované portály.
Technický důsledek Jednotlivé portály musí implementovat persistentní osobní nastavení uživatele ohledně zvolených zobrazovaných informací na úvodní obrazovce.
Bezpečnostní důsledekVolby obsahu úvodní obrazovky informace jsou ukládány pseudonymizovaně.
Právní důsledek Za předpokladu dodržení zákonných povinností pro nakládání a zpracování osobních údajů a vhodném nastavení cookies policy bez dalších právních důsledků.

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).

media_image159.jpg

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

Pravidlo Federované portály spravují a publikují své agendové nebo místně orientované kalendáře
Platí pro Federující a federované portály
Technický důsledek Je definována jedna struktura řešení kalendáře, ideálně podle platného standardu, např. ICalendar, známý též pod názvem iCal je definován jako RFC 5545. Je třeba doplnit i další typy integrovaných kalendářů, jinak nebude UX pro některé uživatele přijatelný.
Bezpečnostní důsledekSplnit bezpečnostní aspekty z RFC 5545 sekce 7.
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB, VoKB a předpisů upravujících ochranu osobních údajů bez dalších právních dopadů.
Pravidlo Federující portály si stahují data z federovaných portálů – kalendářů
Platí pro Federující a federované portály

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ě.

Bezpečnostní důsledekKalendáře z federovaných portálů nejsou ukládány v rámci federovaného portálu.

Sloučené kalendáře jsou uloženy v centrální komponentě kalendáře, zda jsou uložená data událostí, nebo metadata, je předmětem diskuse v rámci přípravy komponenty.

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ů

Pravidlo Federující portály publikují sloučené kalendáře uživateli jako jeden datový zdroj formou otevřeného API
Platí proFederující a federované portály

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.

Bezpečnostní důsledekSplnit bezpečnostní aspekty z RFC 5545 sekce 7. Tato data jsou dostupná bez autentizace a jsou chráněna unikátním přístupovým tokenem pro každého uživatele.

Data jsou dostupná z veřejného internetu a jejich zpřístupnění musí probíhat po kanálu odolném proti narušení (ztrátě dostupnosti, důvěrnosti, integrity). Procházení odkazů na tato data je chráněno řešením pro detekci a prevenci útoků hrubou silou.

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).

Pravidlo Metodika adopce technického řešení pro on-line schůzky
Platí pro Federující a federované portály
Technický důsledek Procesní pravidlo za účelem pomoci vysoutěžení dodavatele technologického řešení pro on-line schůzky (viz. soutěžení platebních brán). Technologický návod – zajištění výstupu kompatibilního s centrálními komponentami (notifikace, kalendář) – implementace API pro zápis do těchto komponent
Bezpečnostní důsledekDefinovat bezpečnostní podmínky technické i provozní pro technické řešení pro on-line schůzky.
Právní důsledek -

Zpřístupnění informací a zajištění notifikací podle zájmů klienta

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.

Pravidlo Zpřístupnění aktualit, oznámení, publikací pro automatizovaný odběr
Platí pro Federované portály
Technický důsledek Portály pro aktuality, důležitá oznámení apod. implementují možnost publikace těchto událostí
obecně platným standardem například formou RSS nebo jiným vhodným API.
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků pro vztahy mezi portály a uživateli služeb.

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.

Pravidlo Uživatel má možnost zobrazovat si informace z dílčích federovaných portálů, např. z územních i soukromoprávních portálů. Dále má možnost si tyto informace omezit pouze na určité kategorie.
Platí pro Federující portál
Technický důsledek Portál je schopný integrovat a prezentovat informace z různých obcí.
Bezpečnostní důsledekFederující portály musí ověřovat, že data pocházejí z federovaného portálu.

Komunikace probíhá skrze eGSB / ISSS.
Právní důsledek V rámci této funkcionality může zejména ve vztahu k soukromoprávním portálům vyvstat otázka odpovědnosti za případný protiprávní obsah (nedostatečné oprávnění k obsahu chráněnému například autorským zákonem), tuto otázku bude třeba řešit v rovině federující portál – federovaný portál, smluvně. -Při nakládání s příslušnými údaji je třeba zajistit si právní titul (zákonné zmocnění či souhlas).

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í.

media_image158.jpg

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.

Pravidlo Personalizovaná část dashboardu je přístupná pouze za přihlášením.
Platí pro Federující a federované portály.
Technický důsledek Portály implementují autentizovanou část a struktury potřebné pro sestavení dashboardu a jeho jednotlivých částí.
Bezpečnostní důsledekUložení personalizovaných dat je možné s dodržením principu pseudonymizace.
Právní důsledek S ohledem na rozsah možných údajů, na jejichž základě bude nabídka dashboardu personalizována, bude nemožné spoléhat na zákonné zmocnění k užití 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í.

Pravidlo Po přihlášení na úvodní obrazovce lze dále zobrazovat i přehled volně dostupných informací.
Platí pro Federující a federované portály.
Technický důsledek Implementace autentizované části nevylučuje pohyb po veřejné části portálu po dobu platnosti přihlášení.
Bezpečnostní důsledek-
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB a VoKB bez dalších právních dopadů.

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.

Pravidlo Po přihlášení portál na úvodní obrazovce zobrazuje přehled volně dostupných informací a přehled informací vztažených ke konkrétnímu subjektu práva z daného portálu a z dostupných napojených

IS.
Platí pro Federované portály.
Technický důsledek Implementace autentizované části nevylučuje použití veřejných dat a dat vztažených ke konkrétnímu subjektu práva a jeho roli.
Bezpečnostní důsledek-
Právní důsledek Vycházíme z předpokladu, že v rámci federovaných portálů tak budou čerpány údaje výlučně v souvislosti s výkonem příslušných agend, které OVM v rámci daného portálu vykonává, resp. na základě uděleného souhlasu (či jiného zákonného právního titulu).

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.

Platí proFederující portály.

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.

Bezpečnostní důsledekPortály poskytující data musí být registrované v portálu zobrazujícím data.

Zobrazující portály musí ověřovat, že data pocházejí z portálu poskytujícího data.

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:

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í.

Pravidlo Pokud se zobrazuje pouze agregovaná informace, tak musí existovat stránka nebo stránky, kde si uživatel může dohled větší detail.
Platí pro Federující a federované portály.
Technický důsledek 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. Výpadek libovolného portálu, který poskytuje agregovaná data, nesmí znemožnit funkčnost federujícího portálu.
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků.

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

Pravidlo Portál může poskytnout sadu různých agregovaných informací v Dashboardu, které si může uživatel dle jeho zájmu zobrazovat na úvodní stránce.
Platí pro Federující a federované portály.
Technický důsledek Jednotlivé portály musí implementovat persistentní osobní nastavení uživatele ohledně zvolených zobrazovaných informací na úvodní obrazovce.
Bezpečnostní důsledekVolby obsahu úvodní obrazovky informace jsou ukládány pseudonymizovaně.
Právní důsledek Za předpokladu dodržení zákonných povinností pro nakládání a zpracování osobních údajů a vhodném nastavení cookies policy bez dalších právních důsledků.

Upozornění

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:

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 PPDF16) skrze eGSB/ISSS17) 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:

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).

Pravidlo Je definována a vytvořena jednotná notifikační komponenta s definovaným umístěním, strukturou dat, legislativní podporou.
Platí proJedinou centrální komponentu

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.

Bezpečnostní důsledekPro centrální komponentu je vytvořena metodika bezpečného použití komponenty.

V rámci notifikací může docházet k předávaní dat do perimetru mimo kontrolu státní správy. V tomto případě je nutné zvažovat věcný obsah dat v notifikacích, z pohledu potenciálního úniku dat. Komunikace s notifikační komponentou je realizována výhradně s využitím šifrovaného přenosu dat.

Komunikační kanály jsou preferovaně využívány v šifrovaných variantách.

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,

cestovního dokladu nebo řidičského průkazu dle § 11 ZPDS.
Pravidlo Je definováno a vytvořeno napojení notifikační komponenty na oprávnění k zastupování.
Platí pro Federující portály
Technický důsledek Notifikační centrum potřebuje ke svému správnému fungování a pojetí všech variant životních událostí (služeb VS) vazbu na systémy řídící udělování zastoupení pro uživatele.
Bezpečnostní důsledek-
Právní důsledek Problematika zástupčího oprávnění je velmi komplexní a s ohledem na skutečnost, že v současnosti neexistuje žádný takový univerzální registr (mandátní registr) a oprávnění se může v průběhu času nejrůznějšími způsoby (tj. z různých právních důvodů) měnit či zanikat (udělení plné moci, rozhodnutí soudu o omezení svéprávnosti, rozhodnutí soudu o přiznání svéprávnosti mladistvému atp.), v důsledku tak může být praktické fungování této funkcionality v plném rozsahu nerealizovatelné.
Pravidlo Portály neimplementují vlastní systém na upozorňování, ale využívají sdíleného sytému poskytovaného centrální sdílenou komponentou.
Platí pro Federované portály
Technický důsledek Federované portál musí být napojen na eGSB.
Bezpečnostní důsledekFederované portál využívá bezpečnostních mechanismů propojení na eGSB.
Právní důsledek Při dodržení pravidel přístupu skrze eGSB/ISSS a dostatečného právního titulu bez dalších právních důsledků.
Pravidlo Uživatel portálu má možnost si nastavit preferované kanály na zasílání upozornění.
Platí pro Federující a federované portály
Technický důsledek Před odesláním notifikace portál zkontroluje nastavení preferovaných způsobů upozornění daného uživatele. Pokud se bude jednat o důvěrné informace, bude zasláno výzva k provedení akce uživatele na portálu.
Bezpečnostní důsledekPortál má uložené informace pouze o preferovaných způsobech upozornění. Informace o kontaktních údajích může z vůle klienta udržovat v profilu.
Právní důsledek S výhradou, že k případnému zpracování kontaktních údajů dojde výlučně na základě předchozího souhlasu uživatele služby (či jiného právního titulu),

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í.

Pravidlo Pro notifikační komponentu je vytvořena funkcionalita definice základního (default) komunikačního kanálu pro upozornění nestandardní povahy
Platí pro Federující a federované portály.
Technický důsledek Technické řešení notifikační komponenty pracuje s pojmem (nastavením) defaultní kanál a řeší případy užití tohoto nastavení
Bezpečnostní důsledekVolba základního kanálu musí být vždy potvrzena zasláním potvrzovacího odkazu na tento kanál.
Právní důsledek Bez právních důsledků.

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.

Pravidlo Notifikační komponenta je připravena na spolupráci s jinými komponentami a procesy, které mohou notifikovat uživatele
Platí pro Federující a federované portály.
Technický důsledek Existuje oddělení zodpovědné za aktualizaci sady upozornění spojených s konkrétnímu datumy na základně zákonných změn a jiných událostí.
Bezpečnostní důsledekPropojení s dalšími komponentami je implementováno bezpečným způsobem dle typu propojení.
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB, VoKB a právních předpisů týkajících se ochrany osobních údajů bez dalších právních dopadů. Opět upozorňujeme, že notifikace jako taková je bez právních dopadů, zejména nemá vliv na prokazatelnost doručení.

Pohledávky a platby

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ří.

Pravidlo Federující portál je schopen zobrazit přehled platebních transakcí uskutečněných na federovaných portálech, ale neposkytuje detail transakce. Pro ten je potřeba přejít na daný federovaný portál.
Platí pro Federující a federované portály
Technický důsledek Federované portály poskytují historii transakcí uživatele.

Federující portál je schopen si načíst historii platebních transakcí z federovaných portálů. Uživatel je schopen přejít bezešvě z federujícího portálu na federovaný, aby si zobrazil detail transakce
Bezpečnostní důsledekNačítání historie transakcí je prováděno skrze eGSB / ISSS.
Právní důsledek Přehledový seznam transakcí uživatele zpravidla nebude spadat pod konkrétní výkon agendy OVM a bude tak třeba za účelem umožnění této

funkcionality vyžádat si od uživatele služby souhlas, a to zvlášť s ohledem na skutečnost, že práva a povinnosti ukládá ZPDS OVM, nikoliv federujícímu portálu jakožto sdružující entitě.

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ánu18) nebo jsou klientovi poskytnuty nezbytné platební údaje a QR kód pro provedení platby (klient si v uživatelském profilu zvolí preferenci).

Pravidlo Federující portál je schopen zobrazit přehled pohledávek před nebo po splatnosti na federovaných portálech, ale neposkytuje detail pohledávky. Pro ten je potřeba přejít na daný federovaný portál.
Platí pro Federující a federované portály
Technický důsledek Federované portály poskytují seznam pohledávek uživatele.

Federující portál je schopen si načíst seznam pohledávek z federovaných portálů.

Uživatel je schopen přejít bezešvě z federujícího portálu na federovaný, aby si zobrazil detail pohledávky.
Bezpečnostní důsledek-
Právní důsledek Přehledový seznam pohledávek uživatele zpravidla nebude spadat pod konkrétní výkon agendy OVM a bude tak třeba za účelem umožnění této

funkcionality vyžádat si od uživatele služby souhlas, a to zvlášť s ohledem na skutečnost, že práva a povinnosti ukládá ZPDS OVM, nikoliv federujícímu portálu jakožto sdružující entitě.

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.
Pravidlo Portály umožnují platbu přes platební bránu.
Platí pro Federující a federovaný portál
Technický důsledek Portály musí umět otevřít a odeslat na platební bránu údaje nezbytné pro provedení platby platební kartou nebo převodem.
Portály musí umět přijmout následně stav po provedení/neprovedení platby.
Bezpečnostní důsledekPortály musí implementovat bezpečnostní požadavky provozovatele platební brány.
Právní důsledek Současný legislativní stav v § 6 zákona č. 634/2004 Sb., o správních poplatcích předpokládá (s výjimkou správních poplatků hrazených územním správním celkům) úhradu příslušnému OVM, tedy na zvláštní účet vedený u ČNB. Otázka odpovědnosti v případě chyby uskutečněné platby není v současném právním řádu ČR, s ohledem na dosavadní nepřizpůsobenost elektronickým platbám řešena, neboť výše uvedený zákon o správních poplatcích předpokládá, že poplatky vyměřuje, vybírá a vymáhá správní úřad příslušný k provedení úkonu (nikoliv třetí osoba – provozovatel platební brány). Rovněž bude třeba dostát požadavkům na řízení přístupů a předávání dat dle ZKB, zákonů týkajících se ochrany osobních údajů a prováděcích právních předpisů.
Pravidlo Portály umí vygenerovat QR kód pro platbu převodem
Platí pro Federující a federovaný portál
Technický důsledek Portály z platebního předpisu umí vygenerovat validní QR kód pro platbu např. ve formátu Short Payment Descriptor (SPAYD).
Bezpečnostní důsledekVytvořit podpůrnou metodiku pro bezpečné generování a užití QR kódů ve formátu Short Payment Descriptor (SPAYD).
Právní důsledek Generování a užití QR kódu bude nezbytné podrobit požadavkům přístupu dle ZKB a prováděcích právních předpisů.

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

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.

Pravidlo Zpětná vazba je odesílána na centrální místo. Ze záznamu zpětné vazby lze poznat co, kde a jakým způsobem bylo hodnoceno.

Veškerá zpětná vazba je anonymní (bez přiřazení konkrétní entitě – uživateli).
Platí pro Federující a federované portály
Technický důsledek Federované portál musí být napojen na eGSB.
Bezpečnostní důsledekHodnocení musí být anonymizováno. V případě autentizovaného uživatele musí být realizovány takové kroky, které ztíží zpětnou identifikaci entity.
Právní důsledek V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) k odeslání zpětné vazby došlo, půjde pouze o pseudonymizované údaje, a nebude se tak jednat o anonymní údaje.

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

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ů.

Otázka Možnosti Povinnost
Byly tyto informace užitečné? Škála jako ve škole 1 do 5.Ano
Byl pro vás text srozumitelný? Škála jako ve škole 1 do 5.Ano
Chcete nám ke stránce ještě něco napsat?Volný text do 2 000 znaků. Ne
Pravidlo Na každé stránce je umístěna zpětná vazba, která je přirozenou součástí stránky. Je pouze na vůli návštěvníka, jestli ji vyplní nebo ne.
Platí pro Federujicí a federované portály
Technický důsledek Musí vzniknout systém, který bude shromažďovat a zpřístupňovat data ze zpětné vazby.
Bezpečnostní důsledekZpětná vazba musí být anonymizována. V případě autentizovaného uživatele musí být realizovány takové kroky, které ztíží zpětnou identifikaci entity.
Právní důsledek V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) k odeslání zpětné vazby došlo, půjde pouze o pseudonymizované

ú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.

Pravidlo Katalog služeb VS uchovává nastavení parametrů pro záznam o zpětné vazbě.
Platí pro RPP
Technický důsledek Katalog služeb VS musí být rozšířen tak, aby mohl uchovávat nastavení parametrů pro řízení záznamů o zpětné vazbě, a to tak, aby s ním federované portály uměly pracovat.
Bezpečnostní důsledek-
Právní důsledek Může být nutné legislativně nebo metodicky upravit rozsah funkcí Katalogu služeb.
Pravidlo Katalog služeb VS uchovává záznamy o zpětné vazbě.
Platí pro RPP
Technický důsledek Katalog služeb VS musí být rozšířen tak, aby mohl uchovávat záznamy o zpětné vazbě a to tak, aby s ním federované portály uměly pracovat.
Bezpečnostní důsledekZpětná vazba musí být anonymizována. V případě autentizovaného uživatele musí být realizovány takové kroky, které ztíží zpětnou identifikaci entity.
Právní důsledek V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) k odeslání zpětné vazby došlo, půjde pouze o pseudonymizované údaje, a nebude se tak jednat o anonymní údaje.

Důsledkem tak je aplikovatelnost nařízení GDPR. Může být nutné legislativně nebo metodicky upravit rozsah funkcí Katalogu služeb.

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.

Otázka19)Možnosti Povinnost
Funkce [tohoto systému] splňují mé požadavky. Rozhodně nesouhlasím 1 2 3 4 5 6 7 Rozhodně souhlasímAno
Použití [tohoto systému] je frustrující zážitek Rozhodně nesouhlasím 1 2 3 4 5 6 7 Rozhodně souhlasímAno
[Tento systém] je snadno použitelný Rozhodně nesouhlasím 1 2 3 4 5 6 7 Rozhodně souhlasímAno
Musím strávit příliš mnoho času opravou věcí s [tímto systémem] Rozhodně nesouhlasím 1 2 3 4 5 6 7 Rozhodně souhlasímAno
Chcete nám ke stránce ještě něco napsat? Volný text do 2 000 znaků. Ne
Pravidlo Na každé stránce je umístěna zpětná vazba, která je přirozenou součástí stránky. Je pouze na vůli návštěvníka, jestli ji vyplní nebo ne.
Platí pro Federujicí a federované portály
Technický důsledek Musí vzniknout systém, který bude shromažďovat a zpřístupňovat data ze zpětné vazby.
Bezpečnostní důsledekZpětná vazba musí být anonymizována.
Právní důsledek V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) k odeslání zpětné vazby došlo, půjde pouze o pseudonymizované údaje, a nebude se tak jednat o anonymní údaje. Důsledkem tak je aplikovatelnost nařízení GDPR. Jakékoliv zpřístupnění dat ze zpětné vazby bude možné pouze na základě předchozího souhlasu uděleného uživatelem.

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é.

Pravidlo Existují řešení sběru zpětné vazby pro neelektronické způsoby komunikace úředníka a klienta
Platí pro Federované a federující portály.
Technický důsledek Technická řešení umožňující podání zpětné vazby na úředníka/pracovníka snadno a bezprostředně při nebo po jednání, využití identifikací v rezervačním systému a v systémech úřadu, QR kódu apod.
Bezpečnostní důsledek-
Právní důsledek V souladu s režimem předpokládaným ZPDS, absence pravidla by naopak byla v rozporu s principem (volby formy úkonu), který ZPDS zavádí. Jakékoliv zpřístupnění či předávání dat ze zpětné vazby bude možné pouze na základě předchozího souhlasu uděleného uživatelem.

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í.

Pravidlo Přístup ke svým datům má ten portál, který data poskytnul a ke svým podřízeným součástem.
Platí pro Federující a federované portály
Technický důsledek Existuje hierarchická struktura rolí
Bezpečnostní důsledekMusí vzniknout systém, který bude shromažďovat a zpřístupňovat data ze zpětné vazby.

Data ze zpětné vazby musí být anonymizovaná.
Právní důsledek V případě, že bude stále trasovatelné odkud a jakým způsobem (příp. z jakého zařízení) k odeslání zpětné vazby došlo, může jít ve vztahu k uživateli služby pouze o pseudonymizované údaje, a nebude se tak jednat o anonymní údaje. Důsledkem tak je aplikovatelnost nařízení GDPR.

Jakékoliv zpřístupnění či předávání dat ze zpětné vazby bude možné pouze na základě předchozího souhlasu uděleného uživatelem.

Užívání portálů v zastoupení

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.

Pravidlo Agendové IS spolupracují na rozvíjení řešení digitálních mandátů
Platí pro Federované portály
Technický důsledek Výstupy stavu jednotlivých lokálních řešení digitálních mandátů nebo jejich teprve rozpracované analýzy jsou předány a udržovány, dále rozvíjeny pouze na centrální úrovni.

Centrální úroveň vhodnými prostředky sdílené a kooperování od dohodnutého data informuje všechny zainteresované AIS o postupujících projektových pracích na digitálních mandátech.
Bezpečnostní důsledekN/A
Právní důsledek Bez právních důsledků.

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í):

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).

Pravidlo Federující portály implementují HA20) řešení digitálních mandátů
Platí pro Federující portály
Technický důsledekZ důvodů výše popsaných musí centrální úroveň zajistit u digitálních mandátů takovou úroveň redundance technického řešení na všech úrovních, že nebude možné, aby nastal výpadek, nebo jeho eliminace musí být v uživateli očekávaném čase. Musí být zajištěn stav, aby nedošlo k jakýmkoliv pochybnostem o nastavených parametrech digitálního mandátu uživatelem a realizací dané digitální služby.
Bezpečnostní důsledekN/A
Právní důsledek Jelikož doposud není v platnosti a účinnosti právní úprava tohoto institutu, bude zapotřebí tuto uzákonit a současně lze očekávat, že bude nezbytné související změny promítnout i do obecné právní úpravy (občanského zákoníku).
Pravidlo Agendové IS (portály) implementují připravenou funkcionalitu digitálních mandátů
Platí pro Federované portály
Technický důsledek Implementují-li od definovaného data federované portály pouze centrální komponentu evidence digitálních mandátů, nemohou realizovat vlastní „náhradní“ řešení v případě její nedostupnosti. Záložní řešení musí být řešeno na centrální úrovni jinými dostupnými prostředky.
Bezpečnostní důsledekN/A
Právní důsledek Jelikož doposud není v platnosti a účinnosti právní úprava tohoto institutu, bude zapotřebí tuto uzákonit a současně lze očekávat, že bude nezbytné související změny promítnout i do obecné právní úpravy (občanského zákoníku).

Informační architektura

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.

Pravidlo Informace z RPP a z nadřazeného federujícího portálů jsou prezentovány dle standardu federujícího portálu.
Platí pro Federovaný portál
Technický důsledek Implementace jednotné vizuální komponenty katalogu služeb dle designsystem.gov.cz a code.gov.cz
Bezpečnostní důsledek-
Právní důsledek Jednotný přístup a vzájemnou provázanost je třeba zajistit v souladu s nařízením Evropského parlamentu a 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.
Pravidlo Portály v maximální možné míře využívají interakční vzory jednotných vizuálních komponent (forma).
Platí pro Federující a federovaný portál
Technický důsledek Implementace jednotné vizuální komponenty katalogu služeb dle designsystem.gov.cz
Bezpečnostní důsledek-
Právní důsledek Bez právních důsledků.

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.

Pravidlo Informace společné pro OVM a OVS jsou pojmenovávány jednotným způsobem.
Platí pro Federovaný a federující portál
Technický důsledek Nutno popsat pravidla do formu designsystem.gov.cz a pro obsah například na archi.gov.cz
Bezpečnostní důsledek-
Právní důsledek Jednotný způsob pojmenování je předpokládán Informační koncepcí ČR a činěn závazným prostřednictvím § 5 ZISVS.
Pravidlo OVM a OVS používají společnou strukturu a uspořádání pro sdílené nebo přepoužívané informace.
Platí pro Federovaný a federující portál
Technický důsledek Nutno popsat pravidla do designsystem.gov.cz nebo archi.gov.cz
Bezpečnostní důsledek-
Právní důsledek Pravidlo je v souladu s Informační koncepcí ČR.

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:

media_image183.jpg

media_image184.jpg

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

Pravidlo Společné položky informační architektury mají jednotné pojmenování.
Platí pro Federované a federující portály.
Technický důsledek Pravidla pro pojmenování společných části jsou popsaná v designsystem.gov.cz nebo archi.gov.cz
Bezpečnostní důsledek-
Právní důsledek Jednotný způsob pojmenování je předpokládán Informační koncepcí ČR a činěn závazným prostřednictvím § 5 ZISVS.

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.

Pravidlo Portály mají jednotnou konvenci v používaných textech a pojmenovávání.
Platí pro Federované a federující portály.
Technický důsledek Pravidla pro pojmenování obsahu: designsystem.gov.cz archi.gov.cz mvcr.cz
Bezpečnostní důsledek-
Právní důsledek Jednotný způsob pojmenování je předpokládán Informační koncepcí ČR a činěn závazným prostřednictvím § 5 ZISVS.

Personalizace a customizace portálů

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.

Pravidlo Portál může zobrazovat uživateli pouze relevantní informace a služby dle jeho kontextu, případně dostupných dat (např. má LV na katastru).
Platí pro Federující a federované portály
Technický důsledek Portál si umí ověřit a zobrazit naplněnost datových bloků.
Bezpečnostní důsledek-
Právní důsledek Vzhledem k možnosti využívat údaje o uživateli pouze na základě zapsané agendy v katalogu služeb by jakýkoliv rozsah nad tento rámec vyžadoval zákonný důvod či souhlas uživatele služby. Takový souhlas by tak musel být dostatečně široce definován, nicméně takové pojetí může narážet na limity zásady minimalizace zpracování osobních údajů.

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 a zohlednit vazbu na evidenční ochranu údajů v režimu zákona č. 153/1994 Sb., o zpravodajských službách České republiky, ve znění pozdějších předpisů).

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.

Pravidlo Definice oblastí s možností vlastních úprav ze strany uživatele
Platí pro Federující a federované portály
Technický důsledek Portály umožňují ve veřejné a privátní části (za loginem) implementaci šablonového systému tak, aby uživatel mohl modifikovat základní funkčnosti zobrazování dat.
Bezpečnostní důsledek-
Právní důsledek Vzhledem k možnosti využívat údaje o uživateli pouze na základě zapsané agendy v katalogu služeb by jakýkoliv rozsah nad tento rámec vyžadoval zákonný důvod či souhlas uživatele služby. Takový souhlas by tak musel být dostatečně široce definován, nicméně takové pojetí může narážet na limity zásady minimalizace zpracování osobních údajů.

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 a zohlednit vazbu na evidenční ochranu údajů v režimu zákona č. 153/1994 Sb., o zpravodajských službách České republiky, ve znění pozdějších předpisů).

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.

Pravidlo Portál sbírá anonymně data o chování uživatelů.

* kde a jak se na portálu pohybuje,
* jaké informace si vyžaduje,na které portály odchází,
* odkud na portál přišel.
Platí proFederující a federované portály

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

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

Bezpečnostní důsledekData musí být anonymizována tak, aby nebylo možné identifikovat unikátního uživatele. V případě, že je chování je tak specifické, že by bylo možné jej využít k identifikace uživatele, nejsou data využívána ke zobrazení.

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:

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.

Pravidlo Při přechodu mezi portály se zachovává jazyková mutace webu, je-li k dispozici.
Platí pro Federující a federované portály
Technický důsledek Portál má implementováno vícero rovnocenných jazykových mutací.

Podle kontextu přicházejícího uživatele portál volí defaultní verzi jazyka.
Bezpečnostní důsledekPřenos informace o vybraném jazyce je součástí předávaného kontextu a je předávaný bezpečným způsobem.
Právní důsledek Rovnocenné jazykové mutace (alespoň do jednoho z nejužívanějších úředních jazyků EU) jsou předvídány nařízením Evropského parlamentu a 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.

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.

Pravidlo Pokud portál nemá uživatelem preferovanou jazykovou mutaci, tak mu v rámci přechodu nabídne možnost změny.
Platí pro Federující a federované portály
Technický důsledek Podle kontextu přicházejícího uživatele portál volí defaultní (uživatelem vybranou) verzi jazyka. Při příchodu na portál je potřeba vytvořit přechodovou stránku s výběrem jazyka.
Bezpečnostní důsledekStránka s výběrem jazyka je ošetřena na běžné zranitelnosti.
Právní důsledek Rovnocenné jazykové mutace (alespoň do jednoho z nejužívanějších úředních jazyků EU) jsou předvídány nařízením Evropského parlamentu a

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.

Pravidlo Podpora dvou základních jazykových mutací – čeština a angličtina.
Platí pro Federované portály
Technický důsledek Federovaný portál povinně publikuje jazykově závislé informace ve dvou jazykových mutacích. Všechny jazykově závislé části musí být řešeny samostatně tak, aby bylo možné počet jazyků variabilně rozšířit přidáním další jazykově závislé sady překladů.
Bezpečnostní důsledek-
Právní důsledek Anglická jazyková mutace se jeví jako nezbytná s ohledem principy definované nařízením

Evropského parlamentu a 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.
Pravidlo Zobrazení informací ve více jazycích.
Platí pro Federující a federované portály
Technický důsledek Pro zobrazení informací v různých jazycích budou tvořeny nové stránky (nebude se tedy jednat o nahrazení textů na stránkách texty v jiném jazyce) Důvodem je rozdílná délka překladů a vzhledem k možnosti rozšiřování jazykových sad není možné vytvořit obecné šablony, které by byly schopny bez problémů zobrazovat různé délky přeložených textů, aniž by to mělo dopad na kvalitu zobrazení dle standardů WCAG.
Bezpečnostní důsledek-
Právní důsledek Anglická jazyková mutace se jeví jako nezbytná s ohledem na principy definované nařízením Evropského parlamentu a 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

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.

Pravidlo Definice struktur parametrů v URL a Cookies
Platí pro Federující a federované portály
Technický důsledek Proměnné, které mají být využívány při přenosu transakčního kontextu (životní role, služby VS, role uživatele apod.), musí mít centrálně definovaný tvar pro přenos kontextu a jeho zpracování.

Proměnná, která není dnes definována jako známý číselník (role), musí být do-definována, aby její použití bylo jednoznačné.
Bezpečnostní důsledek-
Právní důsledek Za předpokladu naplnění zákonných požadavků ZKB, VoKB a předpisů upravujících ochranu osobních údajů bez dalších právních dopadů

Bezpečnost

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.

Pravidlo Správce portálu je registrovaný jako tzv.

kvalifikovaný poskytovatel služeb (SeP – Service Provider) v rámci NIA.
Platí pro Federující i federované portály
Technický důsledekImplementuje technické řešení a požadavky na SeP podle NIA dle Příručky k využití služeb národní identitní autority pro poskytovatele služeb veřejné správy
Právní důsledek Nezbytné naplnění povinností zejména dle § 18 ZoEl.

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 standardu21), 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:

Pravidlo Portál splňuje bezpečnostní požadavky alespoň na úrovni Minimálního bezpečnostního standardu.
Platí pro Federující i federované portály
Technický důsledekImplementovat technické požadavky popsané v dokumentu Minimální bezpečnostního standard
Právní důsledek Pro federující portál bude třeba rovněž splňovat požadavky kladené ZKB a VoKB, jelikož se bude jednat o významný informační systém.

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.

Pravidlo Portály jsou vyvíjeny dle metodiky tvorby bezpečného kódu pro státní správu.
Platí pro eGov
Technický důsledekBudou vypracována metodická pravidla pro tvorbu bezpečného kódu respektující specifika řešení portálů a jejich federace
Právní důsledek Bude třeba zajištění souladu s Metodami řízení ICT veřejné správy ČR (které tvoří závaznou přílohu Informační koncepce ČR), včetně určení

odpovědných osob. OVM mají rovněž povinnost vést informační koncepci dle § 5a odst. 2 ZISVS.

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

Pravidlo Portály jsou vyvíjeny dle metodiky tvorby bezpečného kódu pro státní správu.
Platí proFederující i federované portály
Technický důsledekVšechny části aplikace jsou vyvíjeny dle metodiky pro tvorbu bezpečného kódu.
Právní důsledek Bude třeba zajištění souladu s Metodami řízení ICT veřejné správy ČR (které tvoří závaznou přílohu Informační koncepce ČR), včetně určení odpovědných osob. OVM mají rovněž o povinnost vést informační koncepci dle § 5a odst. 2 ZISVS.

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.

Pravidlo Portály jsou vyvíjeny a testovány s ohledem na specifické zranitelnosti webových aplikací.
Platí proFederující i federované portály

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.

Právní důsledekU federujícího portálu se s ohledem na jeho charakter významného informačního systému uplatní rovněž specifika ZKB a VoKB, zejména poté povinnost řízení rizik dle § 5 a stanovení metodiky pro řízení rizik a zajištění organizační bezpečnosti dle § 6 VoKB, včetně přidělení určitých rolí v oblasti kybernetické bezpečnosti.

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ÚKIB22).

Pravidlo Portály jsou pravidelně podrobovány penetračním testům.
Platí pro Federující i federované portály
Technický důsledekPenetrační testování je zařazeno jako součást životního cyklu portálů.
Právní důsledek Pro federující portál s ohledem na jeho charakter významného informačního systému bude třeba naplnění rovněž povinností stanovených ZKB a VoKB (včetně povinnosti provést penetrační testování dle § 25 VoKB a uskutečnění povinného auditu).

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.

Pravidlo Portály jsou provozovány výhradně na správně nakonfigurovaném a zabezpečeném protokolu HTTPS a podporují aktuální verze protokolu TLS, kde doporučujeme se zde řídit standardem PCIDSS, který je v této oblasti využíván jako best practice i řadou organizací mimo svět platebních karet, a to po celou dobu životnosti portálu.
Platí pro Federující i federované portály
Technický důsledekPortály používají aktualizovaný webový server v podporovaných verzích s bezpečnými přenosovými protokoly (např. TLS 1.2 a 1.3) a bezpečnými šiframi. Bezpečnost přenosových protokolů je pravidelně testována.
Právní důsledek Pro federující portál s ohledem na jeho charakter významného informačního systému bude třeba naplnění rovněž povinností stanovených ZKB a VoKB, v daném případě tedy zejména provést a implementovat příslušná bezpečnostní opatření.

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.

Pravidlo Portál připojený do Bezpečnostního dohledu Národního centra kybernetické bezpečnosti.
Platí pro Federující portály
Technický důsledekPortály implementují požadavky kladené na připojení do bezpečnostního dohledu NCKB
Právní důsledek S ohledem na charakter federujícího portálu jako významného informačního systému bude třeba vyšší míra záruk – tedy naplnění povinností stanovených ZKB a VoKB.

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.

Pravidlo Portál zajišťuje nepřetržité zaznamenávání bezpečnostně relevantních událostí do auditních případně aplikačních záznamů a zabezpečení záznamů před neautorizovaným přístupem, zejména modifikací nebo zničením.
Platí pro Federující portály
Technický důsledekPortály mají implementováno dohledové centrum.
Právní důsledek Výše uvedené pravidlo vychází z povinností stanovených provozovatelům významných informačních systémů dle ZKB a VoKB a implicitně se pojí s přijetím relevantních bezpečnostních (technických) opatření ve smyslu § 4 ZKB.

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.

Pravidlo Portály neukládají žádné informace mimo personalizačních dat uživatele a metadat.
Platí pro Federující i federované portály
Technický důsledek-
Právní důsledek Bez právních důsledků při dodržení všech požadavků předpisů týkajících se ochrany osobních údajů, včetně vhodného nastavení cookies policy.

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.

Pravidlo Data uživatelského profilu portálu musí být ukládána s využitím bezvýznamového identifikátoru.
Platí proFederující i federované portály

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

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

Právní důsledekBude nezbytné dodržení všech požadavků předpisů týkajících se ochrany osobních údajů, včetně vhodného nastavení cookies policy a v souvislosti s možným využitím bezvýznamového identifikátoru rovněž konzultace a zohlednění požadavků metodik Ministerstva vnitra ČR – problematické může být zejména ve vztahu k soukromým federovaným portálům.

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

Pravidlo Výměna datových sad s údaji o subjektech probíhá s využitím pseudonymizovaných identifikátorů
Platí pro Federující a federované portály
Technický důsledekImplementovat překlad agendových identifikátorů fyzických osob prostřednictví Referenčního rozhraní, konkrétně ISZR a komponenty ORG.
Právní důsledek Bude nezbytné dodržení všech požadavků předpisů týkajících se ochrany osobních údajů, včetně vhodného nastavení cookies policy.

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

Pravidlo Portál poskytuje službu pro zjištění aktuální dostupnosti.
Platí pro Federované i federující portály
Technický důsledekImplementovat programové rozhraní, pomocí kterého je možné zjistit zdraví aplikace.
Právní důsledek S ohledem na charakter federujícího portálu jako významného informačního systému bude třeba naplnění povinností stanovených ZKB a VoKB.

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.

Pravidlo Portál zveřejní administrativní a bezpečnostní kontakty.
Platí pro Federující a federované portály
Technický důsledek-
Právní důsledek S ohledem na charakter federujícího portálu jako významného informačního systému bude třeba naplnění povinností stanovených ZKB a VoKB – v tomto případě bude nezbytná notifikace kontaktních údajů NÚKIB.

Splnění informační povinnosti o IS dle ZoZR.

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.

Pravidlo Portál je připojený s využitím KIVS / CMS
Platí pro Federující a federované portály
Technický důsledekNa zařízení, kde je portál provozovaný zajistit připojení prostřednictvím jedné z povolených variant pro připojení k CMS.
Právní důsledek Služby ISVS musí být s výjimkou provozních systémů poskytovány prostřednictvím CMS/KIVS v souladu s § 6h odst. 3 ZISVS.

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.

Pravidlo Portál je připojený na eGSB / ISSS
Platí pro Federující a federované portály
Technický důsledekImplementovat technické požadavky kladené na připojení publikačního a čtenářského AIS na eGSB /

ISSS
Právní důsledek eGSB/ISSS lze využívat pouze prostřednictvím CMS/KIVS.

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.

Pravidlo Udělat analýzu technických požadavků na komunikaci s centrálními komponentami. Při volbě řešení dbát na bezpečnostní parametry výměny dat jako u eGSB / ISSS.
Platí pro eGov
Technický důsledekV případě rozšíření eGCB/ISSS o metody vhodnější např. k přenosu s velkým množstvím malých požadavků (indexace) portály implementují tyto postupy.
Právní důsledek Bez právních důsledků.

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ý.

Pravidlo Při průchodu portály zůstává uživatel přihlášený a pokračuje na URL dle deeplinku.
Platí proFederující a federované portály

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.

Právní důsledekBezešvý (single-sign on postup) je možný pouze v případě, že federující i federovaný portál jsou kvalifikovanými poskytovateli služeb dle ZoEI a uživatel služby povolí v rámci NIA single-sign on funkci.

Nicméně upozorňujeme na požadavek § 4 odst. 1 písm. d) ZPDS, jenž může být formálně 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.

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.

Pravidlo Portály zapojené do federace podporující více autentizačních metod by měly mít jako primární metodu autentizace NIA
Platí pro Federující a federované portály
Technický důsledekPortál podporující více autentizačních metod využívají jako prvního autentizačního mechanizmu využít NIA.
Právní důsledek Bezešvý (single-sign on postup) je možný pouze v případě, že federující i federovaný portál jsou kvalifikovanými poskytovateli služeb dle ZoEI a uživatel služby povolí v rámci NIA single-sign on funkci. Nicméně upozorňujeme na požadavek § 4 odst. 1 písm. d) ZPDS, jenž může být formálně

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.

Pravidlo Při přechodu mezi portály je doporučeno odkazujícím portálem předávat kontextová informace o tom, zda je uživatel na portálu přihlášen pomocí NIA.
Platí pro Federující a federované portály
Technický důsledekOdkazovaný portál má informaci, že je uživatel přihlášen skrze NIA a může jako prvního autentizačního mechanizmu využít NIA.
Právní důsledek Pro úplnost uvádíme, že je třeba dostát požadavkům kladeným na kvalifikované poskytovatele služeb dle ZoEI. Dále upozorňujeme na požadavek § 4 odst. 1 písm. d) ZPDS, jenž může být formálně 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).

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ý.

Pravidlo Portál implementuje systém jednotného odhlášení.
Platí pro Federující a federované portály
Technický důsledek-
Právní důsledek Bez právních důsledků.

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.

media_image199.jpg

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.

Pravidlo Portál může požadovat jen informace z odpovídající či nižší úrovně záruky (LoA).
Platí pro Federující a federované portály
Technický důsledek-
Právní důsledek Je třeba vždy dodržet zákonné požadavky na výši záruky v souladu se ZoEI a nařízením eiDAS.

Zahraniční zkušenost

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.

Dánsko

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

media_image202.jpg

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.

media_image209.jpg

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:

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.

media_image211.jpg

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

Doporučení pro ČR

Finsko

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.

media_image216.jpg

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.

media_image217.jpg

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.

media_image218.jpg

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í.

media_image219.jpg

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.

media_image220.jpg

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:

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.

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).

media_image223.jpg

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

Bezpečnost

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

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í.

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.

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.

media_image225.jpg

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).

media_image226.jpg

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

Kroky k dosažení cílů

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

Poučení pro ČR

Doporučení pro ČR

Norsko

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.

media_image231.jpg

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:

media_image232.jpg

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.

media_image233.jpg

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.

media_image234.jpg

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

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.

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.

media_image236.jpg

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

Bezpečnost

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.

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ě.

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.

media_image237.jpg

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.

media_image238.jpg

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

media_image240.jpg

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

Kroky k dosažení cílů

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

Doporučení pro ČR

Popis současného stavu

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 (PVS)/Portál občana (PO)

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:

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).

Oblast Detail Zastoupeno Poznámka
VyhledáváníŘízení vyhledávání informací

Vyhledávání informací pomocí Google

Centrální správa certifikátů

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

Katalog životních rolí
Ano Ano, probíhá diskuze o jeho definici.

Aktuálně je vyhledávání je realizováno za pomoci MS Cognitive Search.

Z pohledu SEO se spíše řeší základní věci – titles, metadescriptions, headlines, přesměrování 301.

Gov.cz je primární zobrazovač katalogu, celá struktura je načítána prostřednictvím API. V přihlášené části PO katalog VS není.
Ne
Neexistuje
Ano
Ne
Životní události (příp. situace) a příslušné služby VS Ne Na Gov.cz je vytvářen dlouhodobě tzv. průvodce k vybraným několika životním událostem. Nyní i vlastní nový obsah ve smyslu návodů a častých dotazů. Jde o doplněk ke katalogu služeb a průvodcům. Zároveň informujeme o aktualitách (Covid, Tornádo).

Gov.cz: už nyní provozujeme formuláře s přihlášením a dokončením Datovkou. Na Portálu občana je Czech point @ home s využitím Datovek, nově výměna ŘP on-line
Komunikace Podání portálem či vyzvednutí v portálu Ano
Služba elektronického doporučeného doručování (Datová schránka) Ano
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano
Ne
Ano
Kalendář

Sjednání schůzky
Ano
Ne
Oprávněné zájmy

klienta
Aktuality Ano

Ano

Ano
Nástěnka Ústřední dashboard
Upozornění Notifikace o změně
Notifikace o blížícím se termínu Ano
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ne

Ne
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby
Ano
Ne
Přehled hodnocení Ne
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

Ne
Zastoupení Přehled zastoupení
Delegace zastoupení Ne
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Ano

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.

Jednotná struktura obsahu Ano
Navigace Ano
Jmenná konvence Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)
Ne

Ne

Ne

Ne
Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ne
Ano
Ne
Bezpečnost Splňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ano
Přihlášení s využitím NIA Ano
Připojen na KIVS/CMS Ano
Komunikace s pomocí eGSB/ISSS Ano

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

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.

media_image246.jpg

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).

Oblast Detail ZastoupenoPoznámka
VyhledáváníŘízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů
Ano

Ano
Neexistuje
Katalog služeb veřejné správy a příslušných úkonů Katalog životních rolí Ano
Ne
Životní události (příp. situace) a příslušné služby VS Ne
Komunikace Podání portálem či vyzvednutí

v portálu

Služba elektronického doporučeného doručování

(Datová schránka)
Ano
Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano
Ne
Ano
Kalendář

Sjednání schůzky
Ano
Ne
Oprávněné zájmy

klienta
Aktuality Ano

Ano
Nástěnka Ústřední dashboard
Upozornění Notifikace o změně

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

Ano Ano
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení
Ne

Ne

Ne
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne
Zastoupení Přehled zastoupení

Delegace zastoupení
Ano

Ano

Ano

Ano
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu
Navigace Ano
Jmenná konvence Ano

Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

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

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

Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost
Neexistuje
Ano
Ne
Optimalizace pro vyhledávače (SEO) Ne
BezpečnostSplňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ano
Přihlášení s využitím NIA Ano
Připojen na KIVS/CMS Ano
Komunikace s pomocí eGSB/ISSS Ano

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

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).

Oblast Detail Zastoupeno Poznámka
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí Google

Centrální správa certifikátů

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

Katalog životních rolí
Ano

Ano
Řešeno za pomoci ElasticSearch. Do budoucna se předpokládá využití expertízy z dodavatelských týmů pro implementaci centrální komponenty.

Je řešeno v rámci automatických nástrojů obsažených v technologii LifeRay a průběžně dodavateli.

Je plánováno vytvoření vazeb/mapováním mezi katalogem služeb a službami ČSSZ. Služby k agendě A1029 byly zaregistrovány až letos, tedy po spuštění ePortálu ČSSZ v roce 2013, nicméně je v přípravě vytvoření vazeb/mapováním mezi katalogem služeb a službami ČSSZ.

Portál nabízí příslušné služby dle role. Typy uživatelů: Pojištěnec, OSVČ, zaměstnavatel, lékař …
Neexistuje
Ne
Ano
Životní události (příp. situace) a příslušné služby VS Ano

Ano
Seskupovány jsou služby ePortálu ČSSZ i informace na webu ČSSZ, skupiny jsou doplněny popisy.

Elektronické podání je již mnoho let plně funkční a stále se rozšiřuje.

V současné době nevidíme žádný přínos. Pravděpodobně by dávalo větší smysl provést integraci na Portálu veřejné správy.

Ale technologicky je to možné.

Funkcionalita je v přípravě.

Je realizované u vybraných služeb, u některých služeb je k dispozici je pouze poslední dokument. Další rozvoj bude následovat.

RSS kanál
Komunikace Podání portálem či vyzvednutí v portálu

Služba elektronického doporučeného doručování

(Datová schránka)
Ne

Ne

Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého profilu

Federovaný přístup k informacím a datům

Kalendář

Sjednání schůzky
Ano
Ne
Ne
Oprávněné zájmy

klienta
Aktuality Ano
Nástěnka Ústřední dashboard Ne
Upozornění Notifikace o změně

Notifikace o blížícím se termínu
Ano
Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano

Ano

Ano
Zpětná vazba Hodnocení poskytnutých informací
Hodnocení spokojenosti s poskytnutím služby

Přehled hodnocení

Hodnocení spokojenosti s nástrojem

Hodnocení úředníka
Ano
Ne
Ano
Ne
Zastoupení Přehled zastoupení Ano
Delegace zastoupení Ano
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu Ne
Ano
Navigace Ano
Jmenná konvence Ano

Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva
Ne

Ne
Neexistuje
Ne

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.

Vícejazyčnost Ne
Optimalizace pro vyhledávače (SEO) Ne
BezpečnostSplňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ano
Přihlášení s využitím NIA Ano
Připojen na KIVS/CMS Ano
Komunikace s pomocí eGSB/ISSS Ano

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:

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).

Oblast Detail Zastoupeno Poznámka
VyhledáváníŘízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

Katalog služeb veřejné správy a příslušných úkonů
Ano Vlastní strukturovaný katalog obsahu. Zastoupeno týmem, který koordinuje realizaci obsahu.

Aktuálně v rozvoji, je nutné digitalizovat vybrané agendy. Jsou zde i vlastní služby například vyhledávání zdravotnického zařízení, přehled o dostupnosti zdravotních služeb (kvůli zkvalitnění služeb pro občany).

Aktuální překážkou jsou nedostatečné zdroje a legislativa.
Ne
Neexistuje
Ne
Katalog životních rolí Ano
Životní události (příp. situace) a příslušné služby VS Ano
Komunikace Podání portálem či vyzvednutí v portálu Ne
Služba elektronického doporučeného doručování (Datová schránka) Ne

Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO
identitou) vložil do svého profilu Ne
Federovaný přístup k informacím a datům Ne
Kalendář Ne
Sjednání schůzky Ne
Oprávněné zájmy

klienta
Aktuality Ano
Nástěnka Ústřední dashboard Ne
Upozornění Notifikace o změně

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

Ne

Ne

Ne

Ne

Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

Ne
Zastoupení Přehled zastoupení
Delegace zastoupení Ne

Ne
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní

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.

Jednotná struktura obsahu

Navigace
Ano
Ne
Jmenná konvence Ne

Ne

Ne

Ne

Ne
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)
Role subjektu práva Ne
Vícejazyčnost Ne
Optimalizace pro vyhledávače (SEO) Ne
Bezpečnost Splňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ne
Přihlášení s využitím NIA

Připojen na KIVS/CMS Komunikace s pomocí eGSB/ISSS
Ne
Ano
Ne

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ů.

media_image253.jpg

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).

Oblast Detail Zastoupeno Poznámka
VyhledáváníŘízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

Katalog služeb veřejné správy a příslušných úkonů
Ano Základní vyhledávání na portálu poskytované systémem KENTICO.

Katalog služeb byl za resort ČÚZK naplněn.

Předpokládáme průchod bude (už je) obráceně, z katalogu služeb se dostanu na portál. Plánuje se vybudování portálu naplňujícího služby katalogu.
Ne
Neexistuje
Ne
Katalog životních rolí Ne
Životní události (příp. situace) a příslušné služby VS Ne

Ne
Komunikace Podání portálem či vyzvednutí v portálu

Služba elektronického
doporučeného doručování (Datová schránka) Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého profilu
Ano
Ne
Federovaný přístup k informacím a datům Ne
Kalendář Ne
Sjednání schůzky Ne
Oprávněné zájmy

klienta
Aktuality Ano

Ano
Nástěnka Ústřední dashboard
Upozornění Notifikace o změně

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

Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano
Ne

Ne

Ne Ne
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

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í.

Zastoupení Přehled zastoupení

Delegace zastoupení
Ne

Ne
Kompletně nová funkcionalita. V DP vystupují fyzické osoby jménem právnické osoby (pouze pro účtování výstupů). V katastru nemovitostí obecně je nutné řešit vystupování FO jménem PO (např. oprávnění uzavírat smlouvy), ale to neřešíme na úrovni portálu.

Chybějící centrální mandátní registr situaci poměrně komplikuje.
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu Ano

Ano
Navigace Ano
Jmenná konvence Ano V NdKN, DPN a NV si neautentizovaný i autentizovaný uživatel může uložit své nastavení (práce s mapou, způsob přihlášení, zobrazení informačních hlášení atd.), ukládá se to do cookies nebo local storage. V DP si autentizovaný uživatel může uložit své nastavení (preferovaný typ výstupu), ukládá se do DB. V SSZ si autentizovaný uživatel nastavuje typ komunikačního kanálu (SMS, DS, email).
Personalizace a customizace portálůPersonalizace

Oblíbené
Ne

Ne
Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva
Ne
Neexistuje
Ne
Vícejazyčnost Ne
Optimalizace pro vyhledávače (SEO) Ne Základní, ve formě Google Analytics - zjišťování vytíženosti stránek a analýza pohybu uživatelů.

Aktuálně je ve v procesu implementace Single-Sign-On v rámci jednotlivých částí portálů. Vůči jiným portálům se jedná o SameSign-On.
Bezpečnost Splňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu Autentizovaná sekce

Přihlášení s využitím NIA
Ano
Neexistuje
Ano

Ano
Připojen na KIVS/CMS Ano
Komunikace s pomocí eGSB/ISSSNe

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

Portál MD

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.

media_image256.jpg

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.

IS RŽP

Ž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:

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

Portál businessinfo.cz

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).

Oblast Detail Zastoupeno Poznámka
VyhledáváníŘízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů
Ano

Ano
Ano portál využívá řešení postavené na technologii Elasticsearch provozované interně na dedikovaných instancích zejména z důvodů možností optimalizace konfigurace tohoto technického řešení. Vzhledem k množství publikovaných informací je vyhledávání (a související našeptávač) klíčovou komponentou pro navigaci uživatelů skrz portál. 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 (onpage faktory SEO). Sekundárně portál využívá nástrojů jako je Google Search Console a Google Analytics pro řešení / analýzu a další rozvoj technických aspektů přítomnosti a viditelnosti portálu v rámci search indexu Google.
Neexistuje
Katalog služeb veřejné správy a příslušných úkonů

Katalog životních rolí
Ano
Ne
Životní události (příp. situace) a příslušné služby VS Ne

Ne
Komunikace Podání portálem či vyzvednutí

v portálu

Služba elektronického
doporučeného doručování (Datová schránka) Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého profilu
Ano
Ne
Federovaný přístup k informacím a datům Ne
Kalendář Ne
Sjednání schůzky Ne
Oprávněné zájmy

klienta
Aktuality Ano
Nástěnka Ústřední dashboard Ne

Ne

Ne

Ne

Ne

Ne
Upozornění Notifikace o změně

Notifikace o blížícím se termínu
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Zpětná vazba Hodnocení poskytnutých informací
Hodnocení spokojenosti s poskytnutím služby Ne
Přehled hodnocení Ne
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

Ne

Ne
Zastoupení Přehled zastoupení

Delegace zastoupení
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Ano

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.

Jednotná struktura obsahu Ano
Navigace Ano
Personalizace a customizace portálůJmenná konvence Ano

Ano
Personalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ne

Ne

Ne
Ne
Ano
Ne

Ne
Bezpečnost Splňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Neexistuje
Ne
Přihlášení s využitím NIA Ne
Připojen na KIVS/CMS Ne
Komunikace s pomocí eGSB/ISSS Ne

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.

Portál kraje Vysočina

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).

Oblast Detail Zastoupeno Doplnění
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí Google

Centrální správa certifikátů

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

Ano
Vlastní technologií v kombinace s Google.

Vyhledávání pomocí Google využívají i jako hlavní vyhledávací engine stávajícího portálu. Fultextové vyhledávání pro jejich případy užití je podstatné.

Problematiku jednotné správy certifikátů řeší také s dodavateli.

Katalog služeb je vlastní (lokální). U centrální katalogu je třeba mít schopnost rychlé reakce

(přidávání/odebírání) služeb, jinak je možné to používat jen pro dlouhodobě platné služby. Vytváří vlastní služby na základě aktuálních potřeb, se kterými potřebují rychle pracovat.
Neexistuje
Ne
Katalog životních rolí

Životní události (příp. situace) a příslušné služby VS
Ne Nerozlišují služby, role, události.

Nerozlišují služby, role, události.

Nemá přidanou hodnotu.
Ne

Ne
Komunikace Podání portálem či vyzvednutí

v portálu

Služba elektronického
doporučeného doručování (Datová schránka) Ne Integrace DS je vítána.

Formou odkazů.
Informace o klientoviData poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano
Ne
Ano
Kalendář

Sjednání schůzky
Ne
Ne
Oprávněné zájmy

klienta
Aktuality Ano
Nástěnka Ústřední dashboard Ne

Ne

Ne

Ne

Ne

Ne

Ne

Ne
Upozornění Notifikace o změně

Notifikace o blížícím se termínu
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

Ne

Ne

Ne
Zastoupení Přehled zastoupení

Delegace zastoupení
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní
Jednotná struktura obsahu Ne
Navigace

Jmenná konvence
Ne
Ano

Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta) Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ne

Ne

Ne

Ne
Ano
Ne
Bezpečnost Splňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ano
Přihlášení s využitím NIA Ano
Připojen na KIVS/CMS Ano

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.

Komunikace s pomocí eGSB/ISSSAno

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.

Portál Pražana

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).

Oblast Detail Zastoupeno Poznámka
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

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

Katalog životních rolí

Životní události (příp. situace) a příslušné služby VS
Ano Stejné jako je na PO.

Připravuje se společně s veřejnou částí portálu.

Disponuje vlastními službami, což jsou agendy v samostatné působnosti HMP (poplatky za psy, odpady …).

Převedení služby do Katalogu služeb VS by znamenalo zpřístupnění pro samostatnou činnost OVM a přípravu popisu služeb pro jeho naplnění.

Jen je zmíněna role nájemníka.

V portálu se nyní udržuje "opis" uskutečněných podání s možností jejich zobrazení. Připravuje se nasazení funkcionality, která umožní podat podání opakovaně.
Ne
Neexistuje
Ne
Ne
Ano
Komunikace Podání portálem či vyzvednutí v portálu Ne
Služba elektronického doporučeného doručování (Datová schránka) Ne Přehled o dokladech.

Nyní na portálu řešíme odesílání (a tedy i dočasné ukládání velkých
Informace o klientoviData poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano
Ne
Ano
Kalendář Ano
Sjednání schůzky Ano
Oprávněné zájmy

klienta
Aktuality Ne
Nástěnka Ústřední dashboard Ano
Upozornění Notifikace o změně

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

Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano

Ano

Ano
Zpětná vazba Hodnocení poskytnutých informací
Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení Ne

Ne
Hodnocení spokojenosti s nástrojem

Hodnocení úředníka
Ano
Ne

Ne
Zastoupení Přehled zastoupení
Delegace zastoupení Ne

Ne
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu
Ano
Navigace

Jmenná konvence
Ano
Ne
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost
Ano
Ne

Ne

Ne
Ano
Ne
Optimalizace pro vyhledávače (SEO) Ne

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í.

BezpečnostSplňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Ano
Neexistuje
Ano
Přihlášení s využitím NIA Ano
Připojen na KIVS/CMS Ano
Komunikace s pomocí eGSB/ISSS Ano

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 města Říčany

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:

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).

Oblast Detail Zastoupeno Poznámka
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

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

Ano
Základní fulltextové vyhledávání.

Portál je indexován na Google.
Neexistuje
Ano
Katalog životních rolí Ano
Životní události (příp. situace) a příslušné služby VS Ano

Ano
Integrace DS je vítána.
Komunikace Podání portálem či vyzvednutí

v portálu

Služba elektronického doporučeného doručování

(Datová schránka)
Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano

Ano
Ano
Kalendář Ano
Sjednání schůzky Ano

Ano
SMS a email.

SMS a email.

Na úřadě formou dotykové obrazovky s výběrem přepážky.
Oprávněné zájmy

klienta
Aktuality
Nástěnka Ústřední dashboard Ne
Upozornění Notifikace o změně

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

Ano

Ano
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano
Zpětná vazba Hodnocení poskytnutých informací Ne
Hodnocení spokojenosti s poskytnutím služby Přehled hodnocení Ne

Ne
Hodnocení spokojenosti s nástrojem

Hodnocení úředníka
Ne
Ano
Zastoupení Přehled zastoupení

Delegace zastoupení
Ne

Ne
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Ne
Jednotná struktura obsahu

Navigace

Jmenná konvence
Ne
Ano
Ne
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ano
Ne
Ne
Neexistuje
Ano
Ano
Ne

Ne
Bezpečnost Splňuje Minimální bezpečnostní standard Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
Neexistuje
Ano
Přihlášení s využitím NIA

Připojen na KIVS/CMS
Ano
Ne
Komunikace s pomocí eGSB/ISSS Ne

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

Všeobecná zdravotní pojišťovna

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:

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).

Oblast Detail Zastoupeno Poznámka
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

Katalog služeb veřejné správy a příslušných úkonů Katalog životních rolí
Ano
Ne
Neexistuje
Ne
Ano
Životní události (příp. situace) a příslušné služby VS Ano

Ano
Pouze VZP
Komunikace Podání portálem či vyzvednutí v portálu

Služba elektronického doporučeného doručování

(Datová schránka)
Ne
Informace o klientovi Data poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano

Ano
Ne
Kalendář Ne
Sjednání schůzky Ne
Oprávněné zájmy

klienta
Aktuality Ano

Ano
Nástěnka Ústřední dashboard
Upozornění Notifikace o změně Ne
Notifikace o blížícím se termínu Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano
Ne

Ne

Ne
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby
Přehled hodnocení Ne
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne
Zastoupení Přehled zastoupení Ano
Delegace zastoupení Ano

Ano

Ano
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu
Navigace

Jmenná konvence
Ano
Ne

Ne

Ne

Ne

Ne
Personalizace a customizace portálůPersonalizace

Oblíbené

Automatizovaná nabídka služeb a informací na základě chování ostatních klientů Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ano
Ne
Ano
Bezpečnost Splňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce
?
Neexistuje
Ano
Přihlášení s využitím NIA

Připojen na KIVS/CMS
Ano
?
Komunikace s pomocí eGSB/ISSS ?

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á, a.s.

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).

Oblast Detail Zastoupeno Poznámka
Vyhledávání Řízení vyhledávání informací

Vyhledávání informací pomocí

Google

Centrální správa certifikátů

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

Ne

Ne
Katalog životních rolí

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

Ne
Komunikace Podání portálem či vyzvednutí v portálu
Služba elektronického doporučeného doručování (Datová schránka) Ne
Informace o klientoviData poskytovaná informačními systémy

Data, která uživatel portálu (FO identitou) vložil do svého

profilu

Federovaný přístup k informacím a datům
Ano
Ne

Ne
Kalendář Ne
Sjednání schůzky Ne
Oprávněné zájmy

klienta
Aktuality Ano

Ano
Nástěnka Ústřední dashboard
Upozornění Notifikace o změně

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

Ne
Pohledávky a platby Historie transakcí

Seznam pohledávek před/po splatnosti
Ano

Ano
Zpětná vazba Hodnocení poskytnutých informací

Hodnocení spokojenosti s poskytnutím služby
Ne

Ne
Přehled hodnocení Ne
Hodnocení spokojenosti s nástrojem Ne
Hodnocení úředníka Ne

Ne

Ne

Ne
Zastoupení Přehled zastoupení

Delegace zastoupení
Informační architektura Jednotný vzhled a interakce s vizuálními komponentami uživatelského rozhraní Jednotná struktura obsahu
Ano
Navigace Ano
Jmenná konvence Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

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

Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)
Ne

Ne

Ne
Ne
Role subjektu práva Ne
Vícejazyčnost Ne
Optimalizace pro vyhledávače (SEO) Ne

Ne
Bezpečnost Splňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu
Neexistuje
Autentizovaná sekce

Přihlášení s využitím NIA
Ano
Ne
Připojen na KIVS/CMS Ne
Komunikace s pomocí eGSB/ISSS Ne

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

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.

Přehled zastoupení Zastoupení Ne Ano Ne Ne x x Ne Ne Ne Ne Ano Ne
Delegace zastoupení Ne Ano Ne Ne x

x

x x x x x x

x x x x x x x x x x
x

x

x x x x x x

x x x x x x x x x x
Ne Ne Ne Ne Ano

Ano
Ne

Ne
Informační architektura Jednotný vzhled a interakce

s vizuálními komponentami uživatelského rozhraní

Jednotná struktura obsahu

Navigace

Jmenná konvence
Ano Ne Ne Ano Ano

Ano Ano
Ne Ne Ne
Ano Ano Ano Ano Ne

Ne
Ano Ne Ano Ano
Ano Ano

Ano Ano
Ne

Ne
Ano

Ano
Ano Ano Ano Ano
Ano Ano Ne Ne Ne Ano
Personalizace a customizace portálůPersonalizace

Oblíbené

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

Přenos kontextu návštěvníka mezi portály (na základě vlastního chování klienta)

Role subjektu práva

Vícejazyčnost

Optimalizace pro vyhledávače (SEO)
Ne Ano Ne Ne Ano Ano Ano Ano Ne Ne
Ne Ne Ne Ne

Ne Ne Ne Ne
Ne Ne Ne Ne Ne Ne

Ne Ne Ne Ne Ne Ne
Ne NeexistujeNe Neexistuje Ne Ne Ne Neexistuje Ne Ne
Ne Ne Ne Ne Ne Ne Ano Ano Ano Ne
Ano Ne Ne Ne Ano Ano Ne Ano Ne Ne
Ne Ne Ne Ne Ne Ne Ano Ne

Ne
Ano Ne

Ne
Bezpečnost Splňuje Minimální bezpečnostní standard

Vyvíjeno dle státní metodiky tvorby bezpečného kódu

Autentizovaná sekce

Přihlášení s využitím NIA

Připojen na KIVS/CMS

Komunikace s pomocí eGSB/ISSS
Ano Ano Ano Ano Ne Ano Ano ?
Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje Neexistuje
Ano Ano

Ano Ano
Ne

Ne
Ano

Ano
Ne Ne Ne Ne Ano Ano Ano Ano Ano
Ano Ano Ano Ano Ne Ne Ne
Ano Ano Ano Ano Ano Ano

Ano Ano
Ne

Ne
? ?
Ano Ano Ne Ne

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í.

Roadmapa aktivit k odstranění rozdílů

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.

Meziresortní spolupráce na federaci portálů

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.

Registr mandátů – digitální forma plné moci k úkonům

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.

NIA a bezešvý přechod mezi portály

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.

Oblast bezpečnosti

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:

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.

Jedná informační architektura, DesignSystem

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í.

Oblast vyhledávání a SEO

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.

Odhad časové náročnosti a nákladů

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:

Hrubé odhady nákladů:

media_image280.jpg

Obrázek 38: Indikativní vizualizace roadmapy aktivit, respektive realizace jednotlivých výše popsaných oblastí.

media_image281.jpg

Obrázek 39: Indikativní počet osob a vynaložených nákladů na následující období 5 let.

Další části roadmapy

Dokument předkládá celou další řadu funkčních a nefunkčních požadavků (a pravidel jejich potřeby nebo nutnosti realizace), které by autoři dokumentu rádi viděli jako součást kompletní federace portálů na základě zahraničních zkušeností a vyhodnocení současného stavu. Ponecháváme na zadavateli, zda a které z těchto částí zařadí do roadmapy a vykoná nad nimi detailnější analýzu. Těch několik základních uvedených v této kapitole má podle názoru autorů dokumentu největší prioritu z různých důvodů, ale především proto, že mají největší dopad na postavení základů federované organizace.

Máme-li vyjmenovat jeden další požadavek konkrétně, pak je to jistě analýza technologické a provozní způsobilosti eGSB/ISSS pro obsloužení zapojení ohromného poměrně rozsáhlého množství portálů, resp. nových datových toků, z nichž pro mnohé nejsou současné principy architektury eGSB/ISSS nejvhodnější. Nicméně jsou zatím použitelné.

Závěr studie

Vymezení studie se zaměřilo na federaci portálů v rámci veřejné správy. Cílem studie bylo definování oblasti a funkcí, které portály musí anebo volitelně mohou podporovat, a vypracování pravidel pro federaci portálů, včetně přiblížení možných technických, bezpečnostních a legislativních dopadů. Pro definici oblastí a specifikaci pravidel bylo využito poznatků ze zahraničí, kde byla ověřena úroveň digitalizace vybraných zemí a výsledky porovnány se stavem české veřejné správy, aby mohla být co nejlépe využita praxe ze zahraničí. Současně byly aplikovány poznatky získané v rámci České republiky, do studie bylo zahrnuto 12 agendových, územních a soukromoprávních portálových řešení a 2 centrální portály. Definovaná pravidla by měla představovat nezbytný rámec, který je potřeba aplikovat na různá portálová řešení bez rozdílu jejich velikosti nebo zaměření.

Cílem federace portálů veřejné správy je pak zajistit občanům přívětivou a efektivní konzumaci digitálních služeb státu a umožnit pohyb mezi portály při zachování jeho jednotného uživatelského zážitku. Pro naplnění tohoto cíle bylo nutné v první řade vydefinovat a ujasnit si pojem „federace portálů veřejné správy“. Federace jako taková označuje sjednocení samostatných dílčích celků do jednoho digitálního prostoru s využitím nadřazeného celku (PVS). V rámci VS to tedy znamená zprostředkování dat, informací, funkcionalit či chování do jednoho portálu, a to směrem nahoru, dolů, ale také mezi nimi samotnými.

Dalším krokem bylo nutné vydefinovat oblasti a funkce, které by měly a volitelně mohly být podporované federovanými portály veřejné správy. Mezi ty nejzásadnější oblasti lze zařadit oblast vyhledávání, která uživatelům umožní prohledávat všechny portály z jednoho místa, ale také možnost vyhledávat informace na portálech prostřednictvím vyhledávacích komponent. Další funkcí je pak elektronický mandát, který je dnes běžně využíván na území Finska a občan tak může zmocnit jinou osobu jednat jeho jménem, a to doslova na „pár“ kliknutí. Jedná se o funkci, která již ojediněle a s velmi omezenými možnostmi funguje na některých portálech, nicméně není ukotvena v legislativě ČR. V poslední řadě je potřeba zmínit oblast informační architektury, která velice ovlivňuje uživatelský zážitek občana na portálu. Je to oblast, která se aktuálně dostává do popředí.

V rámci realizace studie bylo nutné zjistit, jak je federace portálů podporována ve vybraných zahraničních zemích. V této souvislosti proběhlo několik on-line schůzek se zástupci digitálních agentur, které stojí za vývojem zahraničních portálů. Obecně lze říci, že portály v zahraničí nejsou federovány, nýbrž centralizovány do hlavních, specificky zaměřených, portálových řešení. Výjimkou je pak Norsko, které sice centralizuje data a informace, nicméně disponuje vyšším počtem portálů, než Finsko a Dánsko. Je nutné zmínit, že struktura portálů ve všech zmíněných zemích je oproti ČR více plochá a pro uživatele je proto značně přehlednější.

Posledním krokem v realizaci studie bylo zjistit současný stav vybraných portálových řešení a porovnat jej s definovanými oblastmi a funkcemi cílového stavu (vize). Analýza současného stavu probíhala formou cílených schůzek se zástupci portálových řešení. Informace a poznatky získané ze schůzek byly následně doplněny o informace získané z dotazníkového šetření. Ze získaných informací došlo k porovnání portálů na cílový stav, ale také mezi sebou. Portály se velice liší v jednotlivých oblastech a funkcích a je to pravděpodobně z toho důvodu, že každý portál má jinou cílovou skupinu uživatelů. V tomto světle je proto nutné zhodnotit relevantnost jednotlivých funkcí na dílčích portálech. Na základě rozhovorů s jednotlivými zástupci portálových řešení musíme objektivně konstatovat, že téma SDG pro ně v tuto chvíli není prioritní. SDG neboli Single Digital Gateway, byla spuštěna 12.12. 2020 a jedná se o standard na úrovni EU, který má významně napomoci k federaci portálů na úrovni EU. V průběhu vzniku této studie se nám nepodařilo získat žádné vstupy k tomuto tématu od jednotlivých zástupců portálových řešení a doporučujeme se na něj zaměřit po startu iniciálních aktivit, které byly popsány v roadmapě.

Závěrem lze říci, že federace portálů, respektive její realizace závisí na digitalizaci dílčích agend, zavedení nutnosti implementace NIA (pokud bude chtít být daný portál federován), realizace mandátního registru, a to jak z technického hlediska, tak i právního. Z uživatelského hlediska je to pak jednotná informační architektura a možnosti vyhledávání. Přínosem této studie je zmapování jednotlivých oblastí a aktivit, které jsou žádoucí pro úspěšnou realizaci federace portálů. Dalším přínosem je definice pravidel a předpokladů pro naplnění federace v prostředí veřejné správy ČR.

PricewaterhouseCoopers Česká republika, s.r.o., se sídlem Hvězdova 1734/2c, 140 00 Praha 4, IČ: 61063029, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 43246.

ã 2021 PricewaterhouseCoopers Česká republika, s.r.o. Všechna práva vyhrazena. “PwC” je značka, pod níž členské společnosti PricewaterhouseCoopers International Limited (PwCIL) podnikají a poskytují své služby. Společně tvoří světovou síť společností PwC. Každá společnost je samostatným právním subjektem a jednotlivé společnosti nezastupují síť PwCIL ani žádnou jinou členskou společnost. PwCIL neposkytuje žádné služby klientům. PwCIL neodpovídá za jednání či opomenutí jednotlivých společností sítě PwC, ani nemůže kontrolovat výkon jejich profesionální činnosti či je jakýmkoli způsobem ovlivňovat.

1)
Zpětná vazba sesbírána při provádění UX průzkumu systému Orkist (digitalizace procesů realitní spol. REMAX) vytvářeném pro společnost Changing.Legal a při UX/UI průzkumu vytváření nového plně digitálního hypotečního servisu společnosti MONETA Money Bank.
2)
Základní dokument, který stanovuje cíle ČR v oblasti informačních systémů veřejné správy a obecné principy pořizování, vytváření, správy a provozování informačních systémů veřejné správy v ČR na období 5 let.
4)
Jednotné UX. Digitální Česko [online]. 2018 [cit. 2021-6-10]. Dostupné z: https:%%//%%wiki.digitalnicesko.cz/wiki/Jednotn%C3%A9_UX
5)
Portál národního bodu pro identifikaci a autentizaci (NIA). Eidentita.cz [online]. 2020 [cit. 2021-6-16]. Dostupné z: https:%%//%%info.eidentita.cz/portal/
6)
International ID Gateway, viz: https://archi.gov.cz/nap:nia
7)
Pravidla a postupy upřesňují tzv. Architektonický vzor, spojený s centrální sdílenou komponentou a jejím použitím
9)
Národní architektonický plán je dostupný online z: https:%%//%%archi.gov.cz/nap_dokument
10)
Národní architektonický rámec je dostupný online z: https:%%//%%archi.gov.cz/nar_dokument
11)
Do budoucna bude třeba rovněž zvažovat dopady nového stavebního zákona, tedy zákona č. č. 283/2021 Sb., stavební zákon.
12)
SEO je zkratka anglického „search engine optimization”. V českém prostředí se používá „optimalizace pro vyhledávače” nebo někdy „optimalizace nalezitelnosti”. Jsou to metody, které vám pomohou se dostat na přední místa ve vyhledávačích a přivést z nich na svůj web organickou, tedy neplacenou návštěvnost.
13)
Jako příklad lze uvést informační systémy bank a pojišťoven, jejichž informačním systémům byla oprávnění přístupu založena zákonem č. 49/2020 Sb., kterým se mění zákon č. 21/1992 Sb., o bankách, ve znění pozdějších předpisů, a zákon č. 253/2008 Sb., o některých opatřeních proti legalizaci výnosů z trestné činnosti a financování terorismu, ve znění pozdějších předpisů, a některé další zákony.
14)
„Přihlašuje-li se osoba oprávněná k přístupu do datové schránky prostřednictvím elektronického prostředku podle § 2 odst. 1, správce informačního systému datových schránek neumožní přihlášení bez současného zadání uživatelského jména a bezpečnostního hesla podle § 1.“
15)
Registr osob (ROS), Registr obyvatel (ROB), Registr práv a povinností (RPP), Registr územní identifikace, adres a nemovitostí (RÚIAN), Informační systém základních registrů (ISZR), ORG – Převodník identifikátorů, Registr vozidel, Registr řidičů, Registr ekonomických subjektů (RES), Administrativní registr ekonomických subjektů (ARES), Obchodní rejstřík (OR), Insolvenční rejstřík (IR), Rejstřík živnostenského podnikání (RŽP), Rejstřík trestů
16)
Propojený datový fond
17)
eGovernment On-Line Service Bus / Informační systém sdílené služby
18)
Platební brána pro veřejnou správu. Platebnibrany.gov.cz [online]. 2017 [cit. 2021-6-16]. Dostupné z: https://platebnibrany.gov.cz/
19)
Doporučujeme využít standardizovaný dotazník k samoreportování vnímané použitelnosti. Finstad, Kraig. (2010). The Usability Metric for User Experience. Interacting with Computers. 22. 323-327. 10.1016/j.intcom.2010.04.004.
20)
Z angl. High Availability – vysoká dostupnost.
21)
Podpůrné materiály. Národní úřad pro kybernetickou a informační bezpečnost [online]. 2021 [cit. 2021-7-14]. Dostupné z: https://www.nukib.cz/cs/kyberneticka-bezpecnost/regulace-a-kontrola/podpurne-materialy/
22)
Podpůrné materiály. Národní úřad pro kybernetickou a informační bezpečnost [online]. 2021 [cit. 2021-7-14]. Dostupné z: https:%%//%%www.nukib.cz/cs/infoservis/doporuceni/1504-doporuceni-v-oblasti-kryptografickych-prostredku/