Překlady této stránky:

Toto je starší verze dokumentu!


Pravidla pro funkční celky architektury jednotlivých úřadů

Tato kapitola popisuje definované funkční celky v celé šíři (v celé architektuře) včetně pravidel, návodů a dobrých praktik k jejich správě a rozvoji. Jde o opačný přístup než v části Pravidla tvorby a údržby vlastní čtyřvrstvé architektury jednotlivých úřadů, kde se popisují jednotlivé vrstvy architektury úřadů.

Funkční celek je logická struktura obsahující všechny vrstvy architektury (primárně Byznys, Aplikace, Platformy, Komunikace), a který se nejčastěji tvoří kolem informačního systému veřejné správy. Typickým příkladem funkčního celku může být agendový informační systém typu spisová služba. Tento celek kromě samotného informačního systému obsahuje i procesy a služby v úřadu (skartační plán, příjem dokumentů atd.), potřebný HW a SW, komunikační propojení, bezpečnostní požadavky, standardy a pravidla a další.

**Portály veřejné správy a soukromoprávních uživatelů údajů**

Portál je vnímán jako celý funkční celek obsahující Front-end i Back-end realizující všechny typy služeb dle IKČR - Informační, Interakční, Integrační a Transakční. V oblasti informačních služeb poskytuje uživatelům přehled a veřejně dostupné informace z oblasti, kterou portál obsahuje včetně popisu životních situací. V informační části není potřeba řešit identifikaci, autentizaci a autorizaci uživatele. V oblasti interakčních služeb poskytuje uživatelům zpětnou vazbu mezi jeho konáním, a to včetně historie. Interakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele. V oblasti integračních služeb poskytuje uživatelům sloučené služby z několika zdrojů, například různých agend. Integrační služby vyžadují identifikaci, autentizaci a autorizaci uživatele. V oblasti transakčních služeb poskytuje uživatelům zaručené služby jako úkony a podání se schopností předvyplnění všemi státu známými údaji. Transakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele.

Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, který je integrován s informačními systémy v úřadu. Především s elektronickou spisovou službou, s agendovými informačními systémy, ale třeba i s ekonomickými systémy tam, kde se jejich prostřednictvím shromažďují údaje o výplatách či o poplatcích podle jednotlivých klientů. Portál má sloužit klientovi k získání informací, jako prostředek pro publikování otevřených dat, statistik a veřejných výstupů, pro elektronická podání a komunikaci klienta s úřadem apod. Nově musí portál sloužit i držitelům zaručené elektronické identifikace jako prostředek pro získání jejich údajů, pro různé notifikace, ale třeba i pro interaktivní podání žádostí, či podání žádostí o výpisy apod. Klientovi musí poskytnout též tzv. profil neboli personifikovanou část, kde si portál drží základní údaje o klientovi, které zná úřad a které chce klient sdělit sám.

Při provozování portálu je důležité zavést a změnit současné procesy orientované především na osobním kontaktu s klientem. Současné portály již musí disponovat funkcionalitou propojení se zaručenou identitou dle zákona 250/2017 Sb. a musí se umět přizpůsobit situaci, kdy klient veřejné správy bude komunikovat pouze elektronicky. Začíná se tedy samotným uživatelsky přívětivým prostředím, které musí být v souladu s grafickým manuálem MVČR. Dále je potřeba formulářový engine, který umožní nejen předvyplnit veškeré státu již známé údaje z propojeného datového fondu a elektronické identity poskytnuté národní identitní autoritou. V neposlední řadě je potřeba zajistit předávání všech podání učiněné v portálu do agendových informačních systémů, ve kterých se dle agendy podání řeší a zároveň do spisové služby úřadu. Při předávání podání z portálu je tak potřeba mít zajištěnou funkcionalitu, která z podání vytvoří "lidsky čitelný" a "strojově čitelný" formát v rámci jedné obálky, která je opečetěná a orazítkovaná portálem. Lidsky čitelný formát, typicky PDF, jde do spisové služby pro evidenci a strojově čitelný formát jde od agendového systému. Při provozu portálu nezáleží na technologiích, ani infrastruktuře. Není tedy preferované ani On Premise řešení, ani cloudové řešení, vše záleží na potřebách daného úřadu a možnostech, které technologie dokáží nabídnout. Je vždy potřeba myslet na rozložení zátěže, například daňové přiznání z příjmu fyzických osob se podává 1x ročně a není proto nutné klást na infrastrukturu celoroční nepřetržitý provoz. Každé řešení však musí podporovat přístup k centrálním službám eGovernmentu a dalším službám veřejné správy skrze zabezpečenou infrastrukturu referenčního rozhraní.

V případě Portálu občana v PVS stojí občan jako samoobslužný uživatel „vně" veřejné správy a portál mu poskytuje jedno univerzální vstupní místo dovnitř. Z toho důvodu jsou všechny věcné (agendové) a do budoucna i místní portály se svými službami federalizovány „pod" tímto ústředním portálem.

Portál občana pro svou funkcionalitu využívá služby propojeného datového fondu, stejně tak služby národní identitní autority. Z pohledu propojeného datového fondu je portál občana jedním ze čtenářských AIS, který má zmocnění dle agendy A344 zobrazovat subjektu údajů jeho informace, které o něm vede veřejná správa. Portál občana v tomto musí zajistit, aby agenda, dle které se řídí byla neustále aktualizovaná dle toho, jak se budou postupně rozšiřovat služby a portály poskytující údaje. Technicky je portál občana připojený jako čtenářský AIS na systém eGON Service Bus, skrze který čerpá autoritativní údaje pomocí publikovaných kontextů. V tomto musí portál občana pouze pravidelně aktualizovat čerpaný seznam kontextů jiných agend. Z pohledu národní identitní autority je portál občana poskytovatelem služeb čerpající zaručené služby identifikace a autentizace.

Agednovým portálem je myšlen portál poskytující služby logicky centralizovaného systému pro jiné orgány veřejné správy. Typicky jde tedy o portál agendy v přenesené působnosti poskytovaný správcem (ohlašovatelem) agendy. Takový portál musí splnit několik podmínek:

  • Musí být registrovaný jako informační systém veřejné správy v systému o informační systémech veřejné správy <yamdwe_nowiki>0</yamdwe_nowiki>
  • Musí být federovaný do portálu občana
  • Musí dle svého agendového zákona být schopný čerpat a poksytovat údaje skrze systém eGON Service Bus
  • Musí dle svého agendového zákona být schopný čerpat údaje z informačního systému základních registrů
  • Musí být ohlášen jako poskytovatel služeb <yamdwe_nowiki>1</yamdwe_nowiki>

V případě portálů samospráv se předpokládají dva trendy: a) jednak budou lokální portály samospráv obsahovat obrácený směr navigace do Portálu občana, kde bude moci klient vyřídit vše ostatní ze státní správy, co případně nenašel v místním portálu a b) lokální portály budou moci být v dlouhodobé perspektivě nahrazovány místně přizpůsobenými službami centrálního Portálu občana v PVS. Takový portál musí splnit několik podmínek:

  • Musí být registrovaný jako informační systém veřejné správy v systému o informační systémech veřejné správy <yamdwe_nowiki>2</yamdwe_nowiki>
  • Musí dle svého agendového zákona být schopný čerpat a poksytovat údaje skrze systém eGON Service Bus
  • Musí dle svého agendového zákona být schopný čerpat údaje z informačního systému základních registrů
  • Musí být ohlášen jako poskytovatel služeb <yamdwe_nowiki>3</yamdwe_nowiki>

V případě portálu soukromoprávního uživatele údajů (dále také jako SPUÚ) se jedná o situaci, kdy vlastník portálu není orgán veřejné moci, ale dle své povahy je podřízen zákonu 111/2009 Sb <yamdwe_nowiki>4</yamdwe_nowiki>. Může se jednat o portály poskytovatelů zdravotních služeb, soukromých pojišťoven, bank, státních podniků, apod. Takový portál a jeho vlastník musí splnit několik podmínek:

  • Musí mít zřízenou datovou schránku pro komunikaci s veřejnou správou
    • Právnické osoby mají datovou schránku zřízenou ze zákona
    • Zřídit datovou schránku je možné dle informací zde: <yamdwe_nowiki>5</yamdwe_nowiki> .
    • Datová schránka se může obsluhovat skrze webové rozhraní na adrese www.mojedatovaschranka.cz nebo mít funkcionality integrovány do vnitřních systémů organizace. Nejčastěji se jedná o elektronickou spisovou službu.
  • Musí být ohlášen v rejstříku SPUÚ v registru práv a povinností. Zde je možnost kontroly https://rpp-ais.egon.gov.cz/AISP/verejne/katalog-spuu.
    • SPUÚ je podnikající fyzická osoba nebo právnická osoba, která není orgánem veřejné moci a je podle jiného právního předpisu oprávněna využívat údaje ze základního registru nebo z agendového informačního systému
    • Ohlášení do rejstříku SPUÚ probíhá pomocí agendového informačního systému působnostního viz https://rpp-ais.egon.gov.cz/AISP/. Do tohoto systému má přistup každý ohlašovatel agendy. Pokud má ohlašovatel agendy zároveň i možnost editace rejstříku OVM a SPUÚ, může SPUÚ přidat.
      • Pokud tedy existuje agenda, v rámci které je SPUÚ oprávněn čerpat údaje ze základních registrů nebo z agendového informačního systému, je třeba kontaktovat správce agendy a požadovat zavedení do rejstříku SPUÚ.
      • Pokud není soukromoprávní uživatel údajů ohlášen v AISP a správce agendy, ani jiné OVM, jej ohlásit nechce, musí SPUÚ kontaktovat správce Registru práv a povinností (pavel.kajml@mvcr.cz) se žádostí o ohlášení do rejstříku SPUÚ s těmito údaji (Název organizace, adresa organizace, IČO, DIČ, zákon a paragraf opravňující k přístupu do základních registrů nebo agendovému informačnímu systému, kontaktní osoba)
  • Musí být ohlášen jako kvalifikovaný poskytovatel služeb online služeb (dále též Service Provider). Více také zde https://www.eidentita.cz/Home/Ovm. Ohlášení může proběhnout automatizovaně skrze formulář, pokud to umožňuje typ zřízení datové schránky (typ 10, 14, 15, 16). Pokud nemáte takový typ, je nutné kontaktovat Správu základních registrů skrze datovou schránku napřímo s požadavkem obsahujíc všechny údaje, jako v případě automatizovaného způsobu:
    • Uživatel jako zástupce organizace požaduje po NIA Portálu, který je Service Providerem, službu umožňující registraci dané organizace. Tato registrace umožní fungování dané organizace v NIA a vytváření jednotlivých Service Providerů. NIA Portál kontaktuje Národní identitní autoritu, která ověření zprostředkovává, s požadavkem na ověření dané osoby (uživatele).
    • Pro ověření uživatele pro registraci organizace či konfigurací jednotlivých Service Providerů je jako Identity Provider určen Informační systém datových schránek (ISDS). Národní identitní autorita provede přesměrování na přihlášení prostřednictvím datových schránek.
    • Uživatel provede ověření vlastní osoby přihlášením k datovým schránkám. Aby mohl uživatel registrovat organizaci či provést smazání již vytvořené registrace, musí být přihlášen prostřednictvím ISDS v roli Typ S - Oprávněná osoba se stavem datové schránky Stav schránky 1 - Přístupná a nesmí se jednat o datovou schránku fyzické osoby.
    • V případě, kdy je uživatel úspěšně ověřen, Informační systém datových schránek předá Národní identitní autoritě jako výsledek ověření autentizační token obsahující IČO a název subjektu, roli přihlašovaného uživatele a další atributy.
    • Národní identitní autorita provede sběr atributů v Informačním systému základních registrů (ISZR) na jehož základě následně provede kontrolu existence IČO.
    • Národní identitní autorita předává NIA Portálu potřebné atributy z Informačního systému základních registrů a atributy přijaté v autentizačním tokenu z Informačního systému datových schránek, které jsou nutné ke zpracování formuláře pro registraci.
    • Na základě úspěšného splnění předchozích kroků umožní NIA Portál uživateli službu registrace organizace (SeP) a zobrazí mu vyplněný formulář pro registraci.
    • Uživatel potvrdí správnost údajů a provedení registrace organizace (SeP).
    • NIA Portál zpracuje přijatý požadavek na registraci a po úspěšném zaregistrování umožní uživateli provést konfiguraci jednotlivých Service Providerů spadající pod danou organizaci.
    • Uživatel provede konfiguraci Service Providera
  • Musí umět přijímat a zpracovávat data pomocí standardů SAML2 nebo WS-Federation

Elektronický systém spisové služby

Otevřená data

Otevřená data jsou:

  1. Volně přístupná na webu jako datové soubory ke stažení ve strojově čitelném a otevřeném formátu - CSV, XML, JSON, RDF a další formáty s otevřenou specifikací
  2. Opatřená podmínkami užití neomezujícími jejich užití, viz návod na stanovení podmínek užití
  3. Evidovaná v Národním katalogu otevřených dat (NKOD) jako datové sady opatřené přímými odkazy na datové soubory, které je tvoří
  4. Úplný obsah databáze nebo agregovaná statistika
  5. Opatřená dokumentací
  6. Připravena s cílem co nejsnazšího strojového zpracování programátory apod.
  7. Opatřená kontaktem na kurátora pro zpětnou vazbu (chyby, žádost o rozšíření, apod.)
  8. Jsou publikovány dle otevřených formálních norem ve smyslu § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím.

Pokud vaše datová sada nesplňuje všechny uvedené podmínky, nejedná se o otevřená data české veřejné správy podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, který definuje otevřená data ve svém § 3 odst. 11.

Otevřenými daty zejména není:

  1. odkaz na vyhledávací formulář určený pro koncové uživatele
  2. odkaz na novou stránku s dalšími informacemi
  3. odkaz na veřejné mapové rozhraní GIS
  4. odkaz na API umožňující přístup k jednotlivým záznamům či vyhledávání záznamů, nikoliv export kompletních dat
  5. datový soubor ve formátu PDF
  6. datový soubor ve formátu XLS formátovaný pro tisk nebo obsahující výpočty
  7. datový soubor v pseudo-CSV formátu (např. jiný oddělovač než “,”)

Pro zajištění publikace otevřených dat z IS je třeba:

  1. Zajistit možnost získávání kompletních dat z IS v podobě datových souborů ve strojově čitelném a otevřeném formátu
  2. Zajistit publikaci datových souborů na webu organizace nebo v jejím lokálním katalogu otevřených dat
  3. Opatřit je lidsky čitelnou dokumentací a strojově čitelným schématem
  4. Opatřit je otevřenými podmínkami užití
  5. Zaregistrovat je v Národním katalogu otevřených dat (NKOD)

Zásadní je mít přístup k datům IS. Provozovaný IS tedy musí:

  1. umožňovat přístup k databázi nebo
  2. mít možnost stahovat volitelně strukturovaná data (tabulky) z reportingového modulu systému nebo
  3. nabídnout API, ze kterého se dají pravidelně získávat kompletní data v podobě datových souborů

Export dat nebo API v otevřeném formátu - preferované řešení

IS má rozhraní pro pravidelný export dat nebo neomezené API, které organizace může vytěžit a získat kompletní data v jednom z otevřených formátů.

  • Pro tabulková data je to CSV
  • Pro hierarchická data je to XML nebo JSON
  • Pro grafová data je to RDF
  • Pro geodata je to jeden z otevřených formátů pro geodata - GeoJSON, ESRI Shapefile, OGC GML, OGC GeoPackage.

Struktura dat je zdokumentována jednak lidsky čitelným dokumentem a jednak strojově čitelným schématem.

  • Pro CSV je to schéma CSV on the Web
  • Pro XML je to XML Schema
  • Pro JSON je to JSON schema
  • Pokud je použit vlastní slovník pro RDF, je popsán pomocí RDFS nebo OWL

V takovém případě jsou získaná kompletní data z IS připravena k publikaci formou otevřených dat.

Pokud se jedná o rozšíření existujícího IS, který neumožňuje export dat nebo nenabízí API ve strojově čitelném a otevřeném formátu a takovou úpravu nelze ve Vašem IS provést, využije se stávající export či API, které váš IS již umí (např. do MS Excel), a tento výstup se dále zpracuje do otevřeného formátu pomocí dalších nástrojů tak, aby bylo dosaženo stavu jako v případě přímého exportu do otevřeného formátu.

Data získaná z IS jedním z popsaných způsobů je následně třeba publikovat jako otevřená data. To znamená minimálně:

  1. V případě API zajistit jeho vytěžení pro získání kompletních dat k publikaci (tj. případná přímá publikace API nenaplňuje podmínky otevřených dat)
  2. Zajistit pravidelnou aktualizaci získaných dat (dle charakteru dat to může být ve frekvenci např. denně, měsíčně nebo ročně)
  3. Publikovat získaná data na web ke stažení a následně publikovat každou jejich aktualizaci
  4. Opatřit je dokumentací, podmínkami užití a kontaktem na kurátora
  5. Katalogizovat je v Národním katalogu otevřených dat (NKOD)

K tomu lze využít nástrojů pro přípravu, publikaci a katalogizaci otevřených dat, jako je třeba LinkedPipes ETL.

Publikace otevřených dat by měla být zajištěna koncepčně na úrovni celé organizace. Kompletní postupy jsou k dispozici na Portálu otevřených dat, naleznete zde rovněž informace o školeních a workshopech, které Ministerstvo vnitra k této problematice poskytuje.

Pro příklad vhodného způsobu zveřejnění datové sady v lokálním katalogu se lze podívat na katalog České správy sociálního zabezpečení (ČSSZ).

Pokud jsou předmětem evidence informačního systému osobní údaje ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů a nařízení (EU) č. 2016/679, Obecné nařízení o ochraně osobních údajů (GDPR), neznamená to, že nelze ze systému publikovat otevřená data. Ve formátu otevřených dat lze zveřejnit následující:

  1. Pakliže se jedná o veřejnou evidenci či rejstřík a zvláštní právní předpis nařizuje zveřejnění informací, lze zveřejnit osobní údaje v podobě otevřených dat.
  2. Anonymizace či Pseudonymizace. Z dat se odstraní osobní údaje a případně se nahradí bezvýznamovým umělým identifikátorem. Data bez osobních údajů se pak mohou zveřejnit v podobě otevřených dat. Ovšem pozor, v závislosti na charakteru dat je třeba zkontrolovat, zda data ve své kombinaci neumožňují identifikaci konkrétní osoby i po odstranění zjevných osobních údajů. Zejména se může jednat o kombinace jako město, věk a pohlaví nebo podobné.
  3. Agregace. Data, která není možné nebo vhodné zveřejnit dle předchozího bodu, lze zveřejnit v agregované podobě. Tedy v podobě statistik. V případě zveřejnění statistik je žádoucí použít co nejjemnější možné členění.Tedy například počet přijatých podání uvádět raději po měsících namísto jen po letech.

Více informací naleznete na stránce o ochraně osobních údajů a GDPR ve vztahu k otevřeným datům.

Legislativní rámec otevřených dat v České republice tvoří jejich úprava obsažená v Zákoně č. 106/1999 Sb., o svobodném přístupu k informacím a v Nařízení vlády č. 425/2016 Sb., o seznamu informací zveřejňovaných jako otevřená data, které stanovuje vybraným orgánům veřejné správy povinnost zveřejňovat data z konkrétních jimi spravovaných informačních systémů ve formě otevřených dat.

Více informací o strategických dokumentech, akčních plánech a souvisejících předpisech ČR i EU naleznete na stránce věnované legislativnímu prostředí otevřených dat.

Propojený datový fond

test

Univerzální kontaktní místo

Elektronická identita

Vložte svůj komentář: