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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Informační architektura

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

Single Sign On (NIA)

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

Vyhledávání informací

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

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

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

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

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

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

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

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

Řízení federace portálů

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

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

Základní pravidla

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Relationship Management) a KM (Knowledge Management)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ 3 zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů („ZoPISMA“), bude třeba zajistit naplnění povinností dle ZoPISMA, zejména požadavků na přístupnost (včetně zveřejnění prohlášení o přístupnosti), srozumitelnost a stabilitu.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Definice vyhledávání informací

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Technické aspekty vyhledávání informací

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

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

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

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

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

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

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

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

Optimalizace pro vyhledávače (SEO)

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

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

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

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

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

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

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

Realizace tohoto nemusí být snadná.

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

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

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

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

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

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

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

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

Technický důsledek

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

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

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

kybernetické bezpečnosti

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

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

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

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

Právní důsledek

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

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

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

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

Právní důsledek

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

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

Technický důsledek

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

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

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

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

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

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

Právní důsledek

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pro zobrazení a interakce s katalogem služeb

Pravidlo využívají standardizovanou komponentu z Design

systému.

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

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

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

Katalog životních rolí

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Technický důsledek

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

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

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

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

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

Data poskytovaná informačními systémy

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

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

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

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

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

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

Portál implementuje pro tyto potřeby statické

Technický důsledek

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