Strategie rozvoje IKT ČSSZ do roku 2014

Transkript

1 Strategie rozvoje IKT ČSSZ do roku 2014 Verze:01 1

2 Obsah Strategie rozvoje IKT ČSSZ do roku Cíle strategického rozvoje Strategické cíle ČSSZ Dlouhodobé cíle IKT ČSSZ Prioritní úkoly ČSSZ pro rok Způsoby realizace a prostředky k dosažení cílů IKT Koncepce tvorby integrovaného informačního systému (IIS ČSSZ) Strategické principy vytváření IIS ČSSZ Princip centralizace Princip decentralizace obsluhy klientů Princip unifikace Princip architektury sluţeb Logická struktura IIS ČSSZ Procesní charakteristika IIS ČSSZ Charakteristika datové struktury IIS ČSSZ Struktura IIS ČSSZ a členění na subsystémy Logické oblasti a subsystémy IIS ČSSZ Schéma subsystémů IIS ČSSZ Architektura aplikační podpory IIS ČSSZ Zabezpečování centralizace dat a aplikací a klientského přístupu Popis vazeb IIS ČSSZ na jiné ISVS Forma komunikace IIS ČSSZ s okolím a klienty Koncepce rozvoje aplikační podpory jednotlivých oblastí IIS ČSSZ Oblast 1 - Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací Rozhraní pro komunikaci s klienty ČSSZ (Klientský portál) (subsystém 1.1) Aplikační podpora rozhraní pro zabezpečení komunikace IIS ČSSZ s klienty - subsystém DIS-subsystém jako základ subsystému IN (DIS_IN) pro zabezpečení vstupní oblasti IIS ČSSZ Řešení oblasti vstupu a ošetření informací projekt IN (DIS_IN) Řešení oblasti OUT Projekt el. podatelny, výpravny a spisové sluţby - subsystém 1.1 a Zajištění elektronické výměny dat mezi státy EU v současnosti Vybudování Access Points přístupových míst ČR do Evropské architektury Charakteristika Access Points ČSSZ Předávání informací mezi institucemi v ČR (CMU, ČSSZ, MPSV) Technické poţadavky Oblast 2 - Výběr pojistného Projekt - Výběr pojistného (POJ) (subsystém ISS 2.1) Rozvoj POJ - plánovaná centralizace aplikace OSVČ Projekt - Insolvenční řízení (INSRI) (subsystém ISS 2.2) Oblast 3 - Správa dávek důchodového a nemocenského pojištění Informační subsystém důchodových agend Aplikační podpora v oblasti správy dávek důchodového pojištění - platforma SQ100 BS Realizace Parametrických změn v zákoně č. 155/1995 Sb Aplikace Správa důchodových dávek (SDD) Integrace aplikací subsystémů modelu SQ Integrace aplikací UI42 a UI45 do IIS ČSSZ

3 3.3.2 Informační subsystém agend nemocenského pojištění Projekt - Nemocenské pojištění (NEM) (subsystém ISS 3.2) Další rozvoj aplikace Elektronická neschopenka Informační subsystém agend úrazového pojištění Oblast 4 - Výplaty dávek Výplata dávek (VYP) - průřezový pro všechny subsystémy (ISS 4.1) Projekt - Exekuce a konkurzy (EXK) (subsystém ISS 4.2) Oblast 5 - Správa údajové základny Projekt Důchodové pojištění (SDD) (subsystém ISS 5.1) Projekt - Nárokové podklady a dávky (NPD) (subsystém ISS 5.1) Projekt ELDP, POS a ONZ (zpracování nových formulářů) Novela zákona č. 582/1991 Sb. o organizaci a provádění sociálního zabezpečení (subsystém IIS 5.1) Projekt - Ţádosti o důchodové dávky (ZDD) (subsystém ISS 5.1) Registr pojištěnců průřezový projekt pro všechny agendy ČSSZ (subsystém ISS 5.2) Lékařská posudková sluţba (LPS)... Chyba! Záložka není definována. 3.6 Oblast 6 Ekonomické subsystémy Projekt - Další rozvoj ekonomického informačního systému (EKIS (subsystém ISS 6.1) Oblast 7 - Průřezové subsystémy Workflow Platforma pro řízení a kontrolu procesů a sluţeb (PŘKPS - Posunovač) - Subsystém ESS - Elektronická spisová sluţba Datová integrace DMS (subsystém IIS 7.3) Současný stav v aplikaci DMS Projekt MIGRACE DMS Elektronický zaručený archiv ZEA Plánovaná centralizace aplikace Kontrolní činnost (KOCIN) Elektronický spis jeho koncepce a implementace Oblast 8 - Subsystémy oblasti bezpečnosti Vybudování přístupového AAA portálu uţivatelů ČSSZ (subsystém IIS 8.1) Další rozvoj technické zhodnocení aplikací AAA Budoucí rozvoj aplikací oblasti bezpečnosti Rozšíření funkcionality AAA portálu pro správu klientů ČSSZ Bezpečnostní monitoring přístupu k aplikacím a datům ČSSZ Oblast 9 - Podpůrné subsystémy Koncepce technologické infrastruktury IIS ČSSZ Celkové uspořádání technické základny IIS ČSSZ Centralizované datové úložiště IIS ČSSZ Datová vrstva Centralizovaná aplikační vrstva Decentralizované (lokální) uzly IIS Presentační (uživatelská) vrstva Síťová architektura Rozvojové úkoly Rozvoj síťové infrastruktury pro vytvoření Rozhraní ČSSZ pro komunikaci s klienty Návrh řešení konceptu B2B kanálu Strategie zajištění provozu IIS ČSSZ Struktura IIS ČSSZ z hlediska provozovaného aplikačního zabezpečení Zavedení monitoringu se zaměřením na kvalitu a výkonnost řešení Rozvoj centrálního ServiceDesku

4 6 Strategie zabezpečení vývoje udržování IIS ČSSZ Strategie bezpečnosti IIS ČSSZ Organizace a řízení bezpečnosti v ČSSZ Řízení bezpečnosti s působností na celou ČSSZ Řízení a zajišťování bezpečnosti v rámci úseku IKT Financování Financování IKT a IIS ČSSZ Strategie financování rozvoje IIS ČSSZ Strukturální fondy EU Cíle projektů, které ČSSZ plánuje financovat ze Strukturálních fondů EU Projekty ČSSZ s vazbou na egovernment, které ČSSZ plánuje financovat ze Strukturálních fondů EU Závěr Seznam obrázků Obrázek 1 - Logická struktura procesů ČSSZ...12 Obrázek 2 - Základní datová struktura IIS ČSSZ...13 Obrázek 3 - Organizace procesů podle SOA principu...15 Obrázek 4 - Schéma struktury IIS ČSSZ...18 Obrázek 5 Základní vrstvy aplikační podpory ČSSZ...19 Obrázek 6 Model struktury základních aplikací...20 Obrázek 7 Schématické znázornění realizovaných vazeb mezi současnými aplikacemi...20 Obrázek 8 Řešení řízení procesu a komunikace mezi aplikacemi pomocí PŘKPS a Posunovače...21 Obrázek 9 - Vazby na registry egovernmentu...29 Obrázek 10 Účastníci komunikace s ČSSZ...30 Obrázek 11 - Komunikační vazby na okolní systémy - současný stav...31 Obrázek 12 - Sluţby poskytované klientským portálem...36 Obrázek 13 - Řešení VREP rozhraní...38 Obrázek 14 - Připojení k datovým schránkám...39 Obrázek 15 - Koncepce řešení oblasti IN...42 Obrázek 16 - DIS systém a jeho funkcionalita v současné době...43 Obrázek 17 - Architektura oblasti DIS_IN pro nejbliţší období (vize)...44 Obrázek 18 - Celková architektura subsystému elektronické spisové sluţby...46 Obrázek 19 Konceptuální schéma EESSI...48 Obrázek 20 - Schéma integrace EESSI s ČSSZ IN...50 Obrázek 21 - Vazby AP ČSSZ a vnitřní sítě ČSSZ...52 Obrázek 22 - Vztah AP ČSSZ a ostatních AP v ČR...53 Obrázek 23 - Interní systémy ČSSZ zapojené do komunikace prostřednictvím Access pointu ČSSZ...55 Obrázek 24 - I/O Picture POJ...57 Obrázek 25: INS + SPR a okolní aplikace...59 Obrázek 26 - Vstup nových ţádostí do subsystému...63 Obrázek 27 - Revitalizace modulu EDS aplikace SDD...65 Obrázek 28 Integrace aplikační oblasti UI42 do IIS...66 Obrázek 29 - I/O Picture NEM...67 Obrázek 30 - Koncepce komunikace lékař ČSSZ...68 Obrázek 31 - Dopady do stávajících systémů...69 Obrázek 32 - Oblast úrazového pojištění...70 Obrázek 33 - Výběr pojistného...71 Obrázek 34 - I/O Picture VYP...74 Obrázek 35 - I/O Picture EXK...72 Obrázek 36 - I/O Picture...76 Obrázek 37 - Procesní diagram stávajícího procesu včetně ELDP...76 Obrázek 38 - Procesní diagram stávajícího procesu včetně ONZ...77 Obrázek 39 - I/O Picture KE Obrázek 40 I/O Picture VZT Obrázek 41 Současný stav v řešení oblasti IN na principu PŘKPS

5 Obrázek 42 - Architektura PŘKPS...85 Obrázek 43 I/O Picture DMS...87 Obrázek 44- Rozšíření stávajícího DMS...90 Obrázek 45 Centralizace aplikace KOCIN (KOC)...92 Obrázek 46 Schéma nasazení centrální aplikace KOCIN (KOC)...92 Obrázek 47 EDS návrh rozvoje v roce Obrázek 48 - Portál ČSSZ a kontrola identit...96 Obrázek 49 - Bezpečnostní monitoring...97 Obrázek 50 HW struktura IKT ČSSZ Obrázek 51 Struktura centrálních pracovišť Obrázek 52 - Současné uspořádání datového úloţiště KP1/KP Obrázek 53 Síťová architektura IIS ČSSZ Obrázek 54 Blokové schéma moţného řešení síťové infrastruktury Obrázek 55 Varianta B2B Obrázek 56 - Předpokládaná budoucí infrastruktura

6 1 Cíle strategického rozvoje Dlouhodobá strategie rozvoje informačního systému ČSSZ byla zformulována v létech 2001 aţ 2003 v materiálech Informační systém pro řízení a správu ČSSZ (dále ISŘS). Tato strategie byla průběţně aktualizována v materiálech Koncepce restrukturalizace informační komunikační infrastruktury ČSSZ (2004), kde byly formulovány základní principy architektury IS ČSSZ, Cílová architektura ČSSZ a Koncepce bezpečnosti IKT ČSSZ, které rozpracovávají tyto materiály a dávají bezpečnostní rámec budovanému IS ČSSZ. Dále je to materiál Strategie rozvoje IKT ČSSZ do roku 2013 zpracovaná v roce 2008 a předloţená a schválená MPSV. Materiál Informační koncepce ČSSZ, zpracovaný v roce 2008 zastřešuje tyto materiály v souladu se zákonnými předpisy a byl předloţen jako podklad pro atestaci Integrovaného informačního systému ČSSZ, kterou IIS ČSSZ obdrţela v roce Hlavními cíli těchto konceptů je podpora strategických cílů ČSSZ a naplňování jejího poslání. Potvrzuje se realizovatelnost konceptu centralizace dat a aplikací s moţnostmi decentralizované obsluhy klientů dle unifikovaných procesů a postupů při splnění všech potřebných bezpečnostních a provozních parametrů. Vytvářený Integrovaný informační systém ČSSZ (dále IIS) vychází z legislativy platné pro vytváření ISVS a dále se řídí zejména těmito dokumenty: Informační koncepcí České správy sociálního zabezpečení. Organizačním řádem ČSSZ. Dokumentací programu reprodukce majetku Rozvoj a obnova materiálně technické základny ČSSZ. Interními směrnicemi ČSSZ a Standardy pro vytváření IIS. Bezpečnostní dokumentací (ISMS systémem řízení informační bezpečnosti). Projektovými dokumenty IKT projektů (pro projekty pořizované dodavatelsky) do doby akceptace a uvedení do provozu v IKT prostředí ČSSZ a dalšími platnými dokumenty: o Poslání a strategické cíle České správy sociálního zabezpečení pro období o Cílová architektura informační a komunikační infrastruktury IS ČSSZ a popis její funkcionality. o Koncepční návrh řešení bezpečnosti přístupu k datům a sluţbám v rámci ČSSZ. o Prioritní úkoly ČSSZ pro jednotlivá období. o Strategie rozvoje IKT ČSSZ do roku 2013 z roku o Akční plány ČSSZ. 1.1 Strategické cíle ČSSZ Strategické cíle ČSSZ pro léta 2008 aţ 2011, ze kterých koncepce rozvoje IKT vychází: Strategický cíl č. 1 - Pokračovat ve zdokonalování administrativy systému důchodového a nemocenského pojištění a výběru pojistného. Strategický cíl č. 2 - Centralizace informačního systému ČSSZ. Strategický cíl č. 3 - Příprava a realizace vnitrostátní a mezinárodní výměny dat. Strategický cíl č. 4 - Komplexní řešení bezpečnosti informací v ČSSZ dle BS ISO/IEC Při realizaci těchto strategických cílů má důleţitou roli oblast informačních a komunikačních technologií, zejména projekty zaměřené na podporu klíčových procesů ČSSZ. Strategické cíle jsou proto realizovány prostřednictvím prioritních úkolů a projektů v oblasti informačních a komunikačních technologií (IKT). 1.2 Dlouhodobé cíle IKT ČSSZ Dlouhodobé cíle, které vycházejí ze strategie ČSSZ, podporují klíčové procesy ČSSZ a umoţní v maximální moţné míře eliminovat moţná rizika. 6

7 Identifikovaná rizika vyplývají z důleţitých legislativních změn, které mají zásadní dopad do klíčových procesů ČSSZ a následně do realizace projektů informační podpory těchto procesů. Dalším zdrojem rizik jsou stále ještě migrační projekty převodu historických aplikací do prostředí cílové architektury ČSSZ a po náběhu aplikací do rutinního provozu selhání technické základny a síťové infrastruktury vedoucí k výpadku částí nebo celého systému. Cíle IKT na roky 2010 aţ 2014 jsou tyto: IKT cíl č. 1 - Dostatečná technologická podpora strategických cílů ČSSZ s prioritami: o Zajišťování podpory důchodové reformy. o Zajišťování inovace aplikační podpory procesů nemocenského pojištění. o Vytvoření aplikační podpory procesů úrazového pojištění. IKT cíl č. 2 - Zajišťování e-governmentu v rozsahu: o Výměny dat. o Vazby na základní registry a datové schránky. o Vazby na program zdokonalování administrativy ve veřejné správě cestou přechodem na její elektronickou formu. o Přístupu ke klientovi. IKT cíl č. 3 - Pružné reagování na plánované legislativní změny. IKT cíl č. 4 - Zajišťování postupného rozvoje a inovace technické základny IIS. IKT cíl č. 5 - Zajišťování odpovídající informační bezpečnosti IKT, aplikací a dat. IKT cíl č. 6 - Zajišťování potřebného zvyšování kvality zpracování dat a provozu IIS. 1.3 Prioritní úkoly ČSSZ pro rok 2010 Rozhodnutím ústřední ředitelky ČSSZ jsou pro rok 2010 aktivovány trvalé prioritní úkoly: Výběr pojistného a snižování pohledávek. Úroveň rozhodovací a kontrolní činnosti. Dále byly schváleny tyto prioritní úkoly: Zavedení změny účetnictví státu v rámci projektu MF Státní pokladna dílčí úkoly: o Pojistné, o účetnictví státu 2010 vyhláška 410/2010 Sb., o majetkové účetnictví. Stabilizace procesu provádění důchodového pojištění s ohledem na změny právních úprav. Implementace nových koordinačních nařízení. Stabilizace technologické podpory všech procesů ČSSZ. Stabilizace LPS se zaměřením na snižování počtu nevyřízených případů v zákonem stanovené lhůtě. Další klíčové oblastí, kterými se ČSSZ musí naléhavě zabývat: Portál ČSSZ (i jako perspektivní náhrada portálu veřejné správy). Elektronická spisová služba (komplexně řešící i problematiku datových schránek). Dokončení centralizace (centralizace dat a aplikací z lokálních systémů). 1.4 Způsoby realizace a prostředky k dosažení cílů IKT ČSSZ zajišťuje pořízení, správu a rozvoj informačního systému v souladu s platnými zákonnými povinnostmi, standardy a normami. Má zpracovanou Informační koncepci v souladu se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy resp. Vyhláškou č. 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) ČSSZ. V roce 2008 proběhl úspěšně proces atestace IIS ČSSZ v souladu s výše zmíněnými legislativními předpisy. 7

8 Nástroji a prostředky pro realizaci cílů IKT jsou technologické prostředky, standardizace, financování a projektové řízení. Technologické prostředky vycházejí z open technologií, předpokládají zejména vyuţití centrálních základních registrů, KIVS včetně jeho standardů, vyuţití platformy Intel, databázových strojů především Oracle, SESAM, INFORMIX a MS SQL Server, platformy operačních systémů Microsoft Windows případně Linux, vývojové platformy Microsoft.Net a platformy Java. V oblasti důchodového pojištění je i nadále vyuţíváno vývojové prostředí OSD BS2000. Tam, kde to je moţné a vhodné, vyuţívá ČSSZ standardní softwarové balíky jako např. SAP pro ekonomické agendy (EKIS) a obecná řešení pro veřejnou správu jako je Portál veřejné správy, IS datových schránek a předpokládá se napojení na centrální registry programu egovernmentu. Nedílnou součástí provozovaného aplikačního vybavení je také snaha vlastními silami ověřit, zda dodávané APV jak interním tak externím dodavatelem je z funkčního a zátěţového hlediska zcela v souladu se zadáními. Proto byly pro potřeby analytiků a garantů aplikací zajištěny nástroje pro funkční a zátěţové testování a pomocí těchto nástrojů se bude zabezpečovat testování a vývoj testů a testovacích scénářů pro ověřování věcné, funkční a zátěţové správnosti funkcí systémů u jimi řízených projektů. Jednotlivé etapy ţivotního cyklu informačního systému ČSSZ usměrňují platné interní směrnice a předpisy, které spolu se standardy pokrývají jednotlivé vrstvy ISO OSI referenčního modelu. Finanční prostředky na pořízení, implementaci, provoz a rozvoj jednotlivých komponent IIS ČSSZ jsou uvedeny ve zvláštní kapitole tohoto materiálu - Financování. Základní realizační sloţkou je projektový tým. Ve vedení projektového týmu je vedoucí projektu ze strany ČSSZ a vedoucí projektu ze strany řešitele. Dalšími členy projektového týmu je garant aplikace, garant dat a evidencí, garant metodiky, zástupce uţivatele aplikace a garant provozu (ve smyslu prováděcího pokynu VŘ úseku IKT č. 8/2008 O vývoji, provozu a údrţbě aplikačního software a informačních systémů ČSSZ ). Průběh projektů je kontrolován na pravidelných kontrolních poradách sloţených ze zástupců projektových týmů na straně ČSSZ i dodavatele, které z pověření VŘ 5 řídí vedoucí projektové kanceláře. Infrastrukturní projekty jsou plně řízeny v kompetenci pracovníků úseku IKT a aktivity v oblasti infrastruktury jsou koordinovány stálou Infrastrukturní poradou, kterou řídí z pověření VŘ 5 systémový integrátor ČSSZ. Pro rozsáhlé a finančně náročné inovační akce se pouţívají formy programového řízení. Program pak zahrnuje vţdy celou soustavu potřebných projektů, které je nutno synchronizovat a dovést k úspěšné implementaci. 8

9 2 Koncepce tvorby integrovaného informačního systému (IIS ČSSZ) ČSSZ pokračuje v budování integrovaného informačního systému na bázi dlouhodobé strategie. Za tímto účelem vytváří bezpečnou třívrstvou architekturu na bázi vývojové platformy Microsoft.Net a platformy Java. V oblasti důchodového pojištění zůstává i nadále vyuţíváno vývojové prostředí OSD BS2000. Dochází k propojování na celostátní registry a budování kmenových centrálních databází. Současný stav provozování je stále ještě charakterizován řadou různých technologií, technických prostředků, aplikací, datových úloţišť apod. tak, jak historicky vznikaly. Přechod na nový transformovaný systém probíhá v několika dimenzích. Mění se styl práce, metodika, organizace, technika, způsob komunikace, datová základna, aplikace. Změny musí probíhat ve všech těchto dimenzích v časové korelaci, jinak by došlo k zastavení celého postupu. Základní orientace nově koncipovaného integrovaného informačního systému ČSSZ (dále také IIS ČSSZ) je na automatizovanou podporu provádění procesů ČSSZ, poskytování sluţeb ČSSZ svým klientům při uplatnění moderních technologií. IIS ČSSZ byl vytvořen a dále se rozvíjí podle jednotlivých oblastí hlavních procesů a podpůrných procesů v nich realizovaných. V souvislosti s novou koncepcí IIS ČSSZ byly vytvořeny předpoklady (centralizace dat, decentralizace obsluhy klientů a unifikace obsluţných procesů) pro vyšší kvalitu sluţeb poskytovaných ze strany ČSSZ všem oprávněným subjektům a zároveň předpoklady pro efektivní výkon těchto sluţeb s vysokou podporou nebo substitucí těchto sluţeb elektronickými nástroji. V posledním období, v rámci elektronizace sluţeb veřejné správy, klade ČSSZ priority na integraci svých systémů s existujícími elektronickými kanály veřejné správy ČR a na zvýšení podílu elektronické komunikace se svými klienty. 2.1 Strategické principy vytváření IIS ČSSZ Budování třívrstvé architektury IIS ČSSZ probíhá v souladu s principem centralizace dat, decentralizace obsluhy klientů a unifikace procesů a principů architektury orientované na sluţby (SOA) Princip centralizace Princip centralizace je uplatněn v návrhu a realizaci datové vrstvy a aplikační vrstvy IKT, zatímco presentační vrstva je realizována dle principů decentralizace provádění agend a unifikace procesů. Centralizace je také základem budování SOA architektury. Koncepce nové infrastruktury IKT ČSSZ spočívá ve vytvoření a dalším rozvoji centrálních datových úloţišť (DÚ), která jsou základní součástí kaţdého z provozovaných datových, komunikačních a výpočetních center vybavených standardizovaným hardware a software s jejich následnou virtualizací a propojením do jednoho systému. Po realizaci inovace HW důchodového pojištění v druhé polovině roku 2009 dochází k postupné integraci systému Fujitsu SQ100 jako nedílné součásti IIS ČSSZ. Dále dochází k centralizaci a konsolidaci aplikační vrstvy na bázi výkonných centrálních serverových kapacit serverových farem s konsolidací serverů a vyuţitím principů virtualizace. Cílem centralizace a konsolidace dat a aplikační podpory je : Zabezpečení dostupnosti dat a sluţeb nezávisle na lokalitě. Sníţení nákladů na správu a administraci těchto systémů s vyuţitím moderních metod a postupů. Zvýšení bezpečnosti provozu aplikací i ukládání dat vhodnými metodami zálohování a recovery systémy a postupy Princip decentralizace obsluhy klientů Realizace principu decentralizace obsluhy klientů spočívá ve schopnosti IIS ČSSZ zabezpečit obsluhu klienta nezávisle na místě, kde se nachází a dotkne se výkonu všech procesů, které dnes tuto obsluhu zabezpečují. Základním předpokladem je centralizace dat a aplikací, jejich dostupnost z libovolného pracoviště ČSSZ a cílově z libovolného místa klienta vybaveného běţnou technologií. Dosavadní územní pracoviště budou vybavena i nadále potřebnou HW a SW podporou a vybavením, aby mohla zabezpečovat přímý kontakt s klientem. Vybavení technikou lze rozdělit do několika skupin - infrastrukturní servery, aplikační servery, pracovní stanice a tiskárny. Dalším předpokladem je 9

10 vybudování rozhraní pro elektronickou komunikaci s klienty zastřešenou portálovým řešením a orientací na poskytování sluţeb prostřednictvím tohoto řešení Princip unifikace Realizace principu unifikace je zaměřena zejména na unifikaci procesů, prostředí, aplikací a HW. Bude pokračovat spolu s realizací předchozích principů a bude zaměřena dále na oblast aplikačního vybavení, kde spolu se standardizací sehrává stále důleţitější roli vzhledem k rozsahu řešené problematiky a objemu vyvíjeného APV. Přitom je nutno brát zřetel na technologické poţadavky zvlášť klíčových prvků celého systému IKT (databázové servery, Biztalk servery atd.) Princip architektury služeb V současném IIS se na zpracování podnětů podílí řada procesů, které však nejsou přímo propojeny s klientem (pojištěncem) a procesy probíhají aţ na výjimky asynchronně off-line. V SOA architektuře se v rámci procesů definují sluţby, které se zabezpečují prostřednictvím platformy pro kontrolu a řízení sluţeb. Koncepce zabezpečuje, aby určitá sluţba, vykonávaná jedním procesem byla poskytována všem dalším procesům, které tuto sluţbu potřebují. Sluţby jsou publikovány jako externí (ve vztahu k okolí) a jako interní (ve vztahu k interním uţivatelům IS). Tento princip se promítá do celé filosofie konstrukce aplikační podpory a tedy i do návrhu a implementace aplikací v IIS. Podle tohoto principu jsou procesy uspořádány takovým způsobem, ţe na portále jsou nabízeny přehledy poskytovaných sluţeb pro pojištěnce a šablony pro jejich obsluhu a platforma pro řízení procesů a sluţeb zabezpečí jejich provedení v jednotlivých oblastech činnosti aţ včetně odpovědi uţivateli sluţby a zachycení výsledku vyřízení do příslušné databáze a dokumentace. V technologické oblasti aplikací např. všechny vstupní informace jsou zpracovány standardním postupem bez ohledu na to, který z následujících procesů data upotřebí. Sluţba nad archívem poskytne poţadované informace (image, datové věty, doprovodné informace) kaţdému procesu, který o ně poţádá. Oproti dnešnímu stavu se tím zjednoduší a standardizuje obsah programů, které si nemusí v tomto pojetí (kaţdý) samostatně řešit vstupy, výstupy, přístupy k datům apod. Kaţdý program se soustředí na svoji sluţbu a definici rozhraní, přes které přistupuje k nabízeným sluţbám, resp. sluţby nabízí. Přenos dat mezi jednotlivými sluţbami je zajišťován prostřednictvím datové sběrnice, komunikující se standardním rozhraním. Tato metoda odstraňuje přímou komunikaci mezi aplikacemi. Hlavními zásadami SOA architektury jsou: Sjednocení řízení procesů a jejich skládání z dílčích služeb (např. cílem je pruţnost architektury, usnadnění zavádění). Specializace služeb (např. rozčlenění na dobře fungující úzce specializované sluţby místo vícefunkčních monolitických (nedělitelných) bloků). Požadavky na funkce služeb dle stávajících procesů a dle problémů. Opakovatelně využitelné služby (např. kontrolní sluţba pro všechny, nikoliv kontrolní linka v procesu zpracování). Volně vázané služby (např. aplikace by se navzájem neměly znát a rozhodovat o dalším průběhu zpracování, měly by zpracovat a vrátit odpověď (výsledek), další řízení centralizované). Bezestavové služby (např. nezávislost následných volání jedné sluţby pro jeden případ). Služby sdílejí pouze popis rozhraní (např. nesdílí implementaci, pro volání není nezbytná další specifická dokumentace, vynucené ověřování na úrovni rozhraní (technologie toto podporuje, obcházení není přípustné)). Opakované procházení existujících procesů (např. dolaďování architektury tak, aby řešila známé běţné případy i výjimky) Zaměření na monitorování a řízení zpracování. Princip SOA je přístup k realizaci procesů v ČSSZ tak, aby byly orientovány na klienta, podporovaly jeho decentralizovanou obsluhu, podporovaly takový průběh procesů v ČSSZ, který dovoluje samoobsluţný způsob vyřizování zákonných poţadavků klienta vůči ČSSZ v souladu se strategickými cíli ČSSZ. 10

11 2.2 Logická struktura IIS ČSSZ Procesní charakteristika IIS ČSSZ Na vrcholové úrovni procesního modelu bylo v ISŘS definováno 5 skupin hlavních procesů a jejich příslušných cílů: Procesy výběru pojistného - cílem je zabezpečit dostatečné příjmy pro uspokojení zákonných nároků pojištěnců. Procesy správy dávek důchodového, nemocenského a uvaţovaného úrazového pojištění - cílem je na základě platné legislativy a za podpory vnitřních kontrolních mechanismů rozhodovat o přiznání a výši zákonných dávek pojištěnců. Procesy výplaty dávek - cílem je zabezpečit výplatu přiznaných dávek pojištěncům. Procesy správy datové základny - cílem je vytvářet a spravovat aktuální datovou základnu (registry), nezbytnou pro korektní (procesně i obsahově) průběh procesů z ostatních skupin. Procesy komunikace ČSSZ s vnějšími subjekty - cílem je zabezpečit komunikaci správy (tj. výměnu dat a informací) s externími subjekty při jakémkoliv jejich vzájemném vztahu a v jakékoliv jeho fázi. Tyto procesy se na základě zkušeností s implementací IIS doplňují o další skupiny procesů, a to o: Procesy ekonomické oblasti. Průřezové procesy. Podpůrné procesy. Tato dekompozice procesů je přijata jako základní procesní struktura ČSSZ a je znázorněna na následujícím obrázku. 11

12 Komunikace ČSSZ s vnějšími subjekty IN Příjem podání OUT Poskytování informací Výběr Platby dávek Výběr pojistného Insolvenční řízení, správní řízení Výplaty dávek Výkon agend Správa dávek nemocenské ho pojištění Exekuční řízení Ekonomické procesy EKIS Správa dávek důchodového pojištění Lékařská posudková služba Správa dávek úrazového pojištění Statistiky Správa dat Evidence nárokových podkladů Registr pojištěnců Kmenové evidence Správa pojistných vztahů VZT Elektronická spisová služba Průřezové procesy Bezpečnost Podpůrné procesy Platforma pro řízení a kontrolu procesů (PŘKPS) Správa uživatelských účtů a přístupů (AAA) Podpůrné subsystémy Call Desk, Help Desk Elektronický spis Dokument Management systém (DMS) Zaručený elektronický archiv Kontrolní činnost (KOC) Správa přístupu klientů a externích subjektů Průchozí subsystémy, docházkové subsystémy Subsystém auditu, Vývojové prostředí prostředky Námitkové řízení a Obrázek 1 - Logická struktura procesů ČSSZ 12

13 Z této struktury procesů byla odvozena i základní datová struktura IIS ČSSZ, kterou je moţno znázornit následujícím schématem Charakteristika datové struktury IIS ČSSZ Základní datová struktura respektuje uspořádání základních procesů a je organizována podle pravidla, ţe kaţdá oblast spravuje svá data. Potom tuto strukturu je moţno znázornit následujícím schématem. Data oblasti IN/OUT (DBZDV) Komunikace ČSSZ s vnějšími subjekty IN Příjem podání OUT Poskytován í informací Výběr Výběr Platby dávek Data oblasti POJ Výběr pojistného Insolvenční a správní řízení Výplaty Výplaty dávek dávek Data oblasti ekonom Data pro LPS Data oblasti NEM Data oblasti úrazového poj. Výkon agend Správa informací o Pracovní neschopnosti Správa dávek důchodovéh o pojištění Správa dávek nemocenské ho pojištění Správa dávek Lékařská úrazového posudková pojištění služba Správa dat Exekuční řízení Správa dávek úrazového pojištění Statistiky Ekonomické subsystémy EKIS Insolvence Statistiky Data o výplatách Statistická data Data oblasti nárokových podkladů. Evidence nárokových podkladů Registr pojištěnců Kmenové evidence Správa pojistných vztahů VZT Data oblasti důchodového pojištění Data oblasti oblasti registrů (KE2) Databáze spisové sluţby a ISDS) Databáze ES Průřezové procesy Bezpečnost Podpůrné procesy Elektronická Platforma Správa spisová pro řízení a uživatelských Podpůrné účtů a přístupů subsystémy služba kontrolu (AAA) procesů Call Desk, Help Desk (PŘKPS) Elektronický Data Kontrolní IN/OUT Správa spis (ES) činnost přístupu klientů Subsystém a externích externích (KOC) auditu, subjektů vývojové prostředí a prostředky Dokument Zaručený Průchozí Management elektronický subsystémy, Námitkové doscházkové systém archiv řízení subsystémy (DMS) Data oblasti (VZT) Databáze CD,HD Data oblasti auditu Data podpůrných subsystémů Data DMS Data PŘKPS Data oblasti AAA Data oblasti kontroly fyzického přístupu Obrázek 2 - Základní datová struktura IIS ČSSZ 13

14 V současném procesním pojetí IIS vstupují do systému data z okolí, provede se jejich uloţení do archívu,, odkud jsou přebírána aplikacemi (procesy), zpracovávána a ukládána do datového úloţiště. Aplikace symbolicky propojují archív s datovým úloţištěm. Procesy (zpracování) jsou zčásti řízeny workflow/manaţerem pro řízení procesů na pozadí aplikací. Jak archív, tak datové úloţiště se dále dělí na řadu částí podle účelu a pouţití. Doklady vstupují do systému z okolí a jejich zpracování začíná evidováním, skenováním, indexováním, archivováním. V archívech jsou uloţeny papírové formy, images a datové věty. Většina z nich je v rámci zpracování vstupů převedena nejprve do strukturovaného tvaru (stále ještě součást archivů) a poté do standardních vstupních datových vět (I/O data). V posledních létech stoupá podíl elektronicky zasílaných údajů prostřednictvím elektronických podání, kdyţ větší část se stále ještě typuje referentsky. Vstupní datové věty jsou zpracovány jednotlivými věcnými procesy, které ke zpracování vyuţívají kromě vstupů i kmenových údajů (oblast dat, které sdílí většina aplikací, např. registry osob, organizací apod.) a číselníků a mohou v případě potřeby libovolně nahlíţet do archivovaných informací (ne všechny vstupy budou digitalizovány aţ do tvaru datové věty, k řadě zpracování je nutná konfrontace s výsledky minulých zpracování). Kaţdá z věcných oblastí se stará o svou část aplikačního datového úloţiště, ve které si ukládá své pracovní záznamy. Oblasti si navzájem vyměňují potřebné informace (formou komunikace nikoliv přímým nahlíţením do databází). Tato komunikace je zčásti realizována na platformě BizTalk a většinou je řešena formou webových sluţeb. Společným základem pro všechny aplikace jsou kmenové údaje a číselníky. Zpracování končí vytvořením výstupních datových vět, které jsou zaznamenávány do databází a transformovány do výstupních sestav. Část výstupů je směrována ke klientovi, tyto výstupy jsou zpravidla také archivovány. Průběh zpracování podporovaný workflow, je na konci zpracování rovněţ archivován. Objem informací, které na ČSSZ oprávněně ze zákona poţadují její klienti stále narůstá a ČSSZ má ze zákona povinnost informace těmto osobám poskytnout. Pod tímto zorným úhlem se ČSSZ snaţí problematiku řešit a této oblasti je věnována prvořadá pozornost. V koncepci IIS se dostává do popředí klientský přístup a mění se výše uvedené pojetí průběhu procesů. To je patrné z následujícího obrázku. Do IIS je nutno promítnout moţnost přímé komunikace s klienty prostřednictvím rozhraní pro tuto komunikaci a portálovým řešením zabezpečování této komunikace. Obecně to znamená, ţe, klient komunikuje aţ na výjimky (osobní návštěva, telefon) nepřímo se zaměstnancem ČSSZ a ten s vyuţitím aplikační podpory vyřídí podnět a připraví odpověď klientovi, který ji zase obdrţí zprostředkovaně. Vlastní proces zůstává uzavřen v rámci ČSSZ (jejího IIS). Toto pojetí vylučuje účast klienta na procesu a klade vysoké nároky na pracovní síly a determinuje rychlost reakce ČSSZ. Toto modernímu pojetí administrace a zejména obsluhy klienta nevyhovuje a proto v rámci modernizace veřejné správy je nutno zabezpečit přechod na jiný princip komunikace, který spočívá v otevření procesů a zavedení samoobsluţnosti klienta prostřednictvím Internetových sluţeb. Klient komunikuje se systémem prostřednictvím komunikačního rozhraní s klientským portálem. Prostřednictvím tohoto rozhraní vstupují i ostatní data a dokumenty. Všechny tyto podněty jsou označeny identifikačním znakem a předány subsystému Platformy pro řízení a kontrolu procesů a SOA sluţeb (PŘKPS). Mohou být uloţeny v DMS ve tvaru, v jakém byly doručeny a jsou dále směrovány do odpovídajících aplikací. Elektronické podněty jsou rozděleny na: Strukturované informace - jsou zpracovány v oblasti IN s tím, ţe ke zpracování v aplikační oblasti jsou předána pouze správná data. Aplikační oblast data zpracuje a podle charakteru procesu výsledek uloţí případně zabezpečí přípravu odpovědi zcela automaticky nebo po ověření referentem a předá oblasti OUT. Nestrukturované informace jsou předány spisové sluţbě k dalšímu řízení. Výsledkem řízení je uloţení do datového úloţiště případně příprava odpovědi a předání oblasti OUT. V oblasti OUT proběhnou procesy zabezpečující evidenci, identifikaci a předání rozhraní pro expedici. Průběh vyřízení podnětu je řízen a monitorován platformou pro kontrolu a řízení procesů a sluţeb (PŘKPS). Stejně jako v současném modelu procesů doklady vstupují do systému z okolí a proběhne jejich zpracování do standardních vstupních datových vět. Předpokládá se i nadále vyuţívat technologií vytěţování a kontroly dat. Vstupní datové věty jsou zpracovány jednotlivými věcnými procesy, které ke zpracování vyuţívají kromě vstupů i kmenových údajů (oblast dat, které sdílí většina aplikací, např. registry osob, organizací apod.) a číselníků a mohou v případě potřeby libovolně nahlíţet do archivovaných informací (ne všechny vstupy budou digitalizovány aţ do tvaru datové věty, k řadě zpracování je nutná konfrontace s výsledky minulých zpracování). 14

15 I nadále se kaţdá z věcných oblastí stará o svou část aplikačního datového úloţiště, ve které si ukládá své pracovní záznamy. Oblasti si navzájem vyměňují potřebné informace (formou komunikace nikoliv přímým nahlíţením do databází). Společným základem pro všechny aplikace jsou kmenové údaje a číselníky. V rámci IS bude vytvořen metasystém elektronického spisu (ES), který zabezpečí přehled o všech informacích uloţených v IIS o klientovi a bude vybaven funkcionalitou pro jeho aktualizaci a rovněţ sem budou zaznamenávány informace o průběhu řízení. Zpracování dle charakteru končí předáním datové věty referentovi k dalšímu zpracování nebo automaticky vytvořením záznamů do databází a výstupních datových vět, které jsou transformovány do výstupních sestav. Část výstupů je však přímo směrována ke klientovi, tyto výstupy jsou zpravidla také archivovány. I zde je průběh zpracování řízen a monitorován PŘKPS. Změna pojetí se promítne do infrastruktury i aplikační oblasti. Toto pojetí průběhu procesů znázorňuje následující obrázek. rozhraní Přímá výměna dat Podání - Portál veřejné správy Podání mimo PVS Datové schránky Klienti fyzické osoby Oblast Rozhraní B2B DIS server VREP server DSS rozhraní (Datové schránky) Portál - rozhraní pro komunikaci s klienty Subsystém IN platforma pro řízení a kontrolu procesů a služeb (PŘKPS) Vazba na procesní aplikační podporu Rozhraní jednotlivýc h aplikací pro podporu sluţeb portálu Czech Point Czech Point Rozhraní Subsystém OUT Access Point Ostatní nespecifiko vaná podání Rozhraní pro komunikaci Access Point e-podatelna logické rozhraní pro přijetí podání Elektronická spisová služba (ESS) Zaměstnan ci ČSSZ e-výpravna logické rozhraní pro odeslání el. zásilek Vzdálený přístup Systém autentifikace klientů a ext. subjektů AAA Portál (zaměstnanci) Internet Webový portál ČSSZ (statické informace o ČSSZ) Obrázek 3 - Organizace procesů podle SOA principu 15

16 Z výše uvedené struktury procesů vychází i dekompozice IIS ČSSZ na jeho jednotlivé oblasti a v rámci těchto oblastí na jednotlivé subsystémy. Popis těchto oblastí a subsystémů je uveden v následující kapitole. V tomto pojetí dochází k otevření procesů aţ ke klientovi a s podporou automatizace je moţné uvaţovat o samoobsluţném principu, kdy značnou část úkonů můţe zabezpečit sám klient. Uvedená změna pojetí IIS vyžaduje vyřešit následující úkoly: Vytvořit standardní komunikační rozhraní pro jednotlivé oblasti komunikace (B2B, Czech POINT rozhraní, rozhraní B2C pro komunikaci fyzických osob,) jak v oblasti HW tak i v oblasti systémové podpory tohoto rozhraní a zaintegrovat sem stávající rozhraní (DIS subsystém rozšířený o vazbu na datové schránky ISDS). Portálové řešení pro bezpečnou komunikaci s pojištěnci, třetími stranami včetně poskytování specializovaných sluţeb (dále portál) v souladu s návody a scénáři (formuláři). Dále rozvíjet subsystém pro Podporu řízení a kontroly procesů a sluţeb (PŘKPS) tak, o aby byl napojen vhodnou vazbou na komunikační rozhraní a procesy IN/OUT a přebíral všechny vstupující podněty a tyto opatřil identifikačním znakem a případně je zaevidoval ve stavu v jakém do ČSSZ byly doručeny, o umoţnil třídit vstupní informace na strukturované a nestrukturované, strukturované řídil pomocí PKŘPS/workflow v návaznosti na publikované sluţby a řídil a monitoroval vyřízení v aplikacích aţ do ukončení procesu, o aby PŘKPS předával nestrukturované informace do subsystému spisové sluţby, o aby PŘKPS komunikoval se všemi oblastmi IIS a poskytoval moţnost řízení workflow a monitoring průřezově přes celý IIS. Dále zabezpečit rozvoj oblasti IN o registraci všech došlých podnětů ze všech komunikačních kanálů,o procesy validace a testování vstupních podnětů a zabezpečení čistých dat pro systém zpracování v aplikační vrstvě. Zajistit v rámci subsystému AAA portál subsystém Identity Access Management klientů a externích subjektů. Postupně rozšířit všechny aplikace o podporu sluţeb portálu, prioritně aplikace VYP, NEM, ZDD, POJ, KE, VZT, DMS, EXK, PSL, aplikace důchodové oblasti IKP,SRD a EKIS a podle tohoto principu je postupně modifikovat důsledně na SOA architekturu zejména odstranit horizontální komunikace mezi nimi. Vyřešit koncepčně oblast OUT, vymezit její funkce v návaznosti na HW platformu. HW platforma bude doplňována podle bezpečnostních pravidel platných pro architekturu v ČSSZ, zejména podle principů lokálně odděleného duplexu v návaznosti na současné trendy obnovy a rozšiřování této platformy. Současně s tím je nutno zabezpečit i SW podporu vhodnými SW produkty a licenční politikou. 2.3 Struktura IIS ČSSZ a členění na subsystémy Logické oblasti a subsystémy IIS ČSSZ Logické schéma architektury zahrnuje oblast IIS ČSSZ, která je v současné době rutinně provozována. IIS se člení na následující oblasti: Infrastrukturní oblasti: Centrální datová vrstva (datová úloţiště). Centralizovaná aplikační vrstva (Aplikační servery a systémy). Decentralizované (lokální) uzly IIS. Presentační (uţivatelská) vrstva. Síťová vrstva (komunikační infrastruktura). Aplikační oblasti: Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací atd. Výběr pojistného. Správa dávek důchodového a nemocenského pojištění. Výplaty dávek. Správa údajové základny. Ekonomické subsystémy. 16

17 Průřezové subsystémy. Subsystémy oblasti bezpečnosti. Podpůrné subsystémy Schéma subsystémů IIS ČSSZ 17

18 Infrastrukturní oblasti Aplikační oblasti Centrální datová vrstva (datová úloţiště) Centralizovaná aplikační vrstva (Aplikační servery a systémy) Decentralizované (lokální) uzly IIS Presentační vrstva (uživatelská vrstva) Síťová vrstva (komunikační infrastruktura) 1 Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací atd. ISS 1.1 Informační subsystém rozhraní pro zabezpečení komunikace IIS ČSSZ / Klientský portál ČSSZ B2B rozhraní DIS Server VREP veřejné DSS rozhraní Czech Point Access Point E-podatelna / PVS rozhraní rozhraní Internet, DAS, Rozhraní Rozhraní E-výpravna e-pod ISDS Server ISS 1.2 Data IN/Out subsystém (Subsystém DIS ) zabezpečující - příjem, evidence, rozšifrování, validace a předání posunovači - převzetí, zašifrování evidence a odeslání 2 Výběr pojistného ISS 2.1 Informační subsystém výběru pojistného, základní údaje pojištěného, stanovení výše pojistného na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti a informace o jeho úhradách. ISS 2.2 Insolvenční řízení. Správní řízení. 5 Správa údajové základny 3 Výkon agend ISS 3.1 Informační subsystém důchodových agend Evidence důchodů v rozsahu základních informací o druhu důchodu, výši, poţivateli, správa dávek důchodového pojištění ISS 3.2 Informační subsystém agend nemocenského pojištění informace v rozsahu výkonu činnosti orgánu sociálního zabezpečení, výběr pojistného a správa dávek nem. poj. ISS 5.1 Informační subsystém důchodových agend Evidence nárokových podkladů v rozsahu základních informací identifikujících občana, druh a délku jeho zaměstnání, dosaţených výdělků a základních informací o zaměstnavatelské organizaci, správa nárokových podkladů 7 Průřezové subsystémy ISS 7.1 Workflow -PŘKPS Platforma pro řízení a kontrolu procesů a sluţeb (PŘKPS - Posunovač) ISS 7.2 Elektronická spisová služba ESS ISS 7.4 Zaručený elektronický archiv ISS 7.3 Informační subsystém Document Management System (DMS) evidence, zpracování, vyhledávání a ukládání informací (dokumentů a dat), řízení jejich oběhu, datová integrace. ISS 7.5 Kontrolní činnost - KOC ISS 7.6 Elektronický spis ISS 3.3 Informační subsystém agend úrazového pojištění - v rozsahu výkonu činnosti orgánu sociálního zabezpečení, výběr pojistného a správa dávek úrazového poj ISS 3.4 Informační subsystém Lékařská posudková služba LPS ISS 3.5 Informační subsystém exekucí (exekuční sráţky) ISS 5.2 Informační subsystém Registr pojištěnců (Kmenové evidence) pojištěnců, plátců pojištění 8 Bezpečnostní subsystémy ISS 8.1 Správa uživatelských účtů a přístupů zaměstnaců ( AAA portál), PKI, Monitoring, Průchozí systémy, Docházkové systémy, Plánovaná Správa přístupu klientů a externích subjektů, Rozhraní pro vzdálený přístup zaměstnanců ČSSZ 4 Výplaty dávek ISS 4.1 Informační subsystém - o výplatách důchodových dávek - o výplatách nemocenských dávek - o výplatách úrazových dávek ISS 5.3 Informační subsystém Registr pojistných vztahu (VZT) 9 Podpůrné subsystémy ISS 9.1 Podpůrné subsystémy (např. HelpDesk,CallDesk, ASPI, atd ) ISS 9.2 subsystém v oddělené doméně pro zpracování auditních informací ISS 9.3 Námitkové řízení 6 Ekonomické subsystémy ISS 6.1 Informační subsystém ekonomických agend (EKIS) Evidence údajů správního účetnictví a dávek sociálního pojištění včetně detailní účetní informace ISS 6. 2 Podpůrné ekonomické subsystémy pro Zpracování statistik Obrázek 4 - Schéma struktury IIS ČSSZ 18

19 Podle tohoto členění na oblasti rozdělujeme i projekty na: Infrastrukturní K infrastrukturním projektům patří projekty rozvoje centrální datové vrstvy (datových úloţišť), centralizované aplikační vrstvy (aplikačních serverů a systémů),, decentralizovaných (lokálních) uzlů IIS, presentační (uţivatelské) vrstvy a projekty síťové vrstvy (komunikační infrastruktury). Tyto projekty budou zabezpečovat rozvoj těchto oblastí ve smyslu jak bude uvedeno u popisu jednotlivých vrstev architektury.. Aplikační (transformační) Realizace transformačních projektů v rámci programu ISŘS dosáhla stadia, kdy tyto projekty přešly z etapy vývoje do etapy provozování. Projekty nabyly charakteru rozvoje existujících provozovaných aplikací a úsilí je tedy zaměřeno na jejich rozvoj a stabilizaci jejich provozu. Vedle toho se objevují poţadavky na nové aplikace, v závislosti na řešení nových oblastí procesů, které dosud nebyly centralizovány nebo podporovány IKT nebo které vzešly z nové legislativy. 2.4 Architektura aplikační podpory IIS ČSSZ Dosavadní architektura aplikačního vybavení je znázorněna na následujícím obrázku. řízení dokumentů, analytické aplikace, nadstavby MIS Síť LAN uživatelé Prezentační vrstva Aplikační prostředí (servery,,, aplikace,vývoj,testy) Síť WAN Záloţní aplikační prostředí (servery, aplikace,vývoj,testy) Aplikační vrstva Centrální datové úloţiště KP0, KP1 SAN Záloţní datové úloţiště KP2 Datová vrstva Obrázek 5 Základní vrstvy aplikační podpory ČSSZ Výše uvedená struktura znázorňuje architekturu v rámci IIS a je postavena na třívrstvé architektuře, která dovoluje současně centralizaci kapacit a jejich konsolidaci (datová a aplikační vrstva) při dostatečné flexibilnosti prezentační vrstvy. Zaručuje dostatečnou bezpečnost dat a dovoluje aplikovat bezpečnostní principy řízení přístupu k aplikacím a datům. Vyhovuje i struktuře procesů ČSSZ a je vhodná pro strukturu aplikací IIS ČSSZ. Model aplikační architektury je k dispozici pro aplikace, které byly převedeny do rutinního provozování a je znázorněn na následujícím obrázku. Konstrukce aplikační podpory je tvořena podle tohoto modelu ze základních aplikací, které jsou ročleněny do oblastí. Tento model zatím platí pro aplikace, které jsou rutinně provozovány a můţeme rozlišit Oblast IN/OUT Agendové aplikace Centrální registry Infrastruktura aplikací AAA,BizTalk Průřezové aplikace. 19

20 IN Vstupy ZDV OUT STV INF KL Důchodová POJ VYP Nemocenská Centrální registry (CERE) VZT KE2 Datový katalog Číselníky Infrastruktura Legenda AAA BPM Oblast Průřezová oblast DMS Oblast v produkčním prostředí Oblast Obrázek 6 Model struktury základních aplikací K uvedenému schématu je nutno poznamenat, ţe v důsledku nevyřešení komunikace mezi aplikacemi navrhovaným systémem workflow (BizTalk systém) musely být konstruovány přímé vazby mezi aplikacemi, které jsou velmi komplikované (prakticky kaţdá aplikace komunikuje s kaţdou) a jsou vysokým rizikem pro budoucí provozuschopnost a udrţovatelnost aplikací v IIS. POJ DMS Datum aktualizace DIS KL NEM VYP ZDV VZT KE2 EXK Vazba Obrázek 7 Schématické znázornění realizovaných vazeb mezi současnými aplikacemi Základním principem tohoto uspořádání je stanovení pravidel pro komunikaci mezi vrstvami, které současně nastavují základní bezpečnost této komunikace pomocí nastavení principů a oprávnění komunikace mezi vrstvami. Tyto vazby jsou realizovány pomocí rozhraní na bázi webových sluţeb zčásti pomocí BizTalk. Cílem optimalizace bude především převedení těchto vazeb na platformu pro řízení a kontrolu procesů a sluţeb Posunovač, tak jak je popsáno v průřezové oblasti IIS. Řešení spočívá v přechodu na jinou strukturu, která je zaloţena na architektuře SOA. Řešení je zaloţeno na vyuţití vhodného nástroje platformy PŘKPS a datové sběrnice (Enterprise Bus). Komplexní vyřešení tohoto úkolu je základním technickým úkolem oblasti IKT, protoţe přepracování výše uvedené Oblast 20

21 struktury aplikací na SOA princip je základní nutností pro zachování funkčnosti IIS a zajištění jeho rozvoje do budoucnosti. Cílem bude přejít na architekturu podle následujícího modelu: Konstrukcí platformy pro kontrolu a řízení procesů a služeb (PŘKPS) řízení zpracování (přes oblast IN => Agendy => OUT), vytvořením stavového automatu, procesního monitoringu (dle poţadavků ČSSZ). Nasazením posunovače / ESB pro zabezpečení podpory procesů, předávání dat mezi aplikacemi, zpětné vazby do procesního monitoringu, voláním sluţeb připojených na sběrnici. Uzpůsobením agendových aplikací (nebo vytvořením podpůrných subsystémů), jejich vybavením vlastním workflow pro interní zpracování, předání zpracování jiné aplikaci zajistí PŘKPS. V současné době je tento princip vytvořen podle následujícího schématu: Obrázek 8 Řešení řízení procesu a komunikace mezi aplikacemi pomocí PŘKPS a Posunovače 2.5 Zabezpečování centralizace dat a aplikací a klientského přístupu Centralizace dat a aplikací je jedním ze strategických cílů ČSSZ. Jedná se o usnadnění přístupu k datům potřebnému počtu zaměstnanců (a v budoucnu i klientů) nezávisle na územním principu prostřednictvím centralizace aplikací. Centralizace dat a aplikací v praktické rovině znamená transformaci aplikací provozovaných na lokálních serverech na centrální kapacity kontrolních pracovišť (KP0 aţ KP2) pod správu nově vyvinutých aplikací na aplikačních serverových subsystémech a jejich uloţení na centrálním datovém úloţišti včetně posilování těchto centrálních kapacit a jejich konsolidaci do cílového stavu. Centralizace dat probíhala zejména v oblasti doplnění databází kmenových evidencí a pojistných vztahů. Pro náběh aplikace NEM v nemocenském pojištění bylo nutno provést koncem roku 2008 a počátkem roku 2009 centralizaci dat z OSSZ a tentýţ úkol proběhl i s daty pro oblast pojistného. Lokální databáze budou postupně vyuţívány jen z archivních důvodů a budou spolu s aplikacemi archivovány. Dalším okruhem dat, která byla centralizována, jsou data pro aplikaci PSL podpora lékařské posudkové sluţby. Centralizace dat je proces, který i nadále bude probíhat v návaznosti na centralizaci aplikací, dokud nebudou konsolidována všechna potřebná data z lokálních serverů. Půjde zejména o centralizaci v oblasti agend OSVČ, dobrovolného pojištění (DOPOJ) a kontrolní činnosti (KOCIN). Dále pokračovaly činnosti podporující automatizovanou kontrolu a konsolidaci dat. Automatizovaná konsolidace dat je realizována s ohledem na nutnost zajistit správnou a bezchybnou funkcionalitu centralizovaných agend. Všechna vstupující data jsou podrobena logickým kontrolám takovým způsobem, aby po jejich zápisu byla k dispozici pro další zpracování ve správném tvaru. Data, která logickým testům nevyhoví, jsou předána zpět nebo k referentskému došetření. V souvislosti s centralizací dat se objevuje závaţný problém co se starými daty evidovanými v lokálních databázích. Tato data nemohou být vymazána, ale musí být archivována tak, aby byla i nadále 21

22 dostupná, Nabízí se několik variant řešení, ale vyřešení tohoto problému bude vyţadovat vyčerpávající analýzu a samostatný projekt. Centralizace aplikací - současný stav v procesu centralizace lze dokumentovat následujícím přehledem aplikací. Tabulka 1 - Provozované aplikace v členění podle oblastí IIS k Oblast Název oblasti Počet Počet Procento Počet aplikací aplikací aplikací lokálních centrálních pro oblast lokálních aplikací 1. Komunikace s vnějšími subjekty Výběr pojistného Správa dávek ,46 4. Výplata dávek Správa údajové základny Ekonomické subsystémy ,33 7. Průřezové subsystémy Subsystémy oblasti bezpečnosti Podpůrné systémy ,22 Aplikace ČSSZ celkem ,82 Tabulka 2 - Detailní přehled aplikací v ČSSZ k Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 1. Komunikace s vnějšími subjekty Celkem RAUI/AAS Registrace e-podání 1 2 DIS server Provoz systému pro příjem a zpracování a e- podání na ČSSZ (součást řešení PVS/DMS) 1 3 DIS SystémDISview Provoz systému pro příjem a zpracování e-podání na ČSSZ 1 4 DIS View Kukátko do systému pro příjem a zpracování e- podání 1 5 UCZPR Účetní zpráva ČSSZ 1 2. Výběr pojistného Celkem DODEJKY Dodejky 1 7 DOPOJ Dobrovolné pojištění 1 8 DSKNT Předpis úhrady diskontního úroku 1 9 KONTA Konta plátců 1 10 NEDO Nedobytné pohledávky 1 11 OSVČ Pojistné OSVČ 1 12 POJ Centrální výběr pojistného 1 13 POKLADNA Příjem plateb v hotovosti 14 PREPL Evidence přeplatků 1 15 N_POJS Platby pojistného OSVČ (DP) 1 16 N_SANKCE Pořízení a evidence penále OSVČ 1 17 SANKCE Předpisy sankčních plateb 1 18 SPRIZ Správní řízení 1 19 VYKNE Výkazy nedoplatků 1 20 N_UCET Údaje pro účetnictví OSVČ 1 21 DP Příjmový účet, sborník pojistného 1 22 VYPL Výplata přeplatků pojist. Na DP 1 23 KOCIN 1 24 UCZPR 1 25 MALORG 1 3. Správa dávek Celkem

23 Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 26 DAVUC Dávková účtárna 1 27 ELDP Tisk listů DP 1 28 EPOZ Dlouhodobá neschopnost 1 29 EVDOB Evidence péče o dítě a osobu bezmocnou 1 30 EVZAD Evidence ţádostí o důchod, statistiky 1 31 KL Kontrolní linka (nárokové podklady důchodové) 1 32 NEM Nemocenské pojištění 1 33 NPD Nárokové podklady důchodového pojištění 1 D_STAT (včetně EVI, EDA, Statistický subsystém o přiznaných důchodových 34 1 klienta KWH) dávkách 35 SDD Správa dávek důchodového pojištění 1 36 VPO3 Ţádost a rozhodování o dávkách DP s mezinárodním prvkem 37 EPN Evidence práce neschopných 1 38 ZDD Ţádost o důchodovou dávku 1 39 N_HESLO Číselník referentů a jejich přístupů k aplikacím 1 40 N_MONS Nemocenské dávky zaměstnanců MO 1 41 N_NEMS Nemocenské dávky OSVČ 1 42 N_OSVČ Evidence OSVČ (přihl. K NP ) 1 43 N_PREDOS Data OSVČ mezi OSSZ 1 44 N_REFSIT Změny referentů 1 45 N_RODCIS Změna rodného čísla 1 46 N_SOCS Evidence dávek 1 47 N_STATMIN Statistiky pro MPSV 1 48 N_UCET Údaje pro účetnictví OSVČ 1 49 N_UDRZBA Pomocné programy pro údrţbu dat 1 Aplikace pro sledování výplat na účet, které jsou ABO - vyuţívána jiţ jen 50 ze zpracování ÚSP nebo ze zpracování SU13 a 1 archivně (od II/09) OBST 51 ARM Odškodnění podle zákona č.39/2000 Sb BDOPL Aplikace pro výplatu jednorázových doplatků do Bulharska 53 CIZDOPL Aplikace pro doplatky do Polska 1 54 ČNB 1 55 DIGI DOPOJ Data DOPOJ do nárok. podkladů DP 1 56 DIGI - OSOKR (OSVČ) Data OSVČ po nárok. podkl. DP 1 57 DIGI - Péče Data o Péči do nárok. podkladů DP 1 58 DIGI UI42 Modul pro čistý průběh DP 1 59 DIGI - UIP Nárokové podklady DP 1 60 DIGI UIW Wokk DIGI - UIW Work DIGI - UIW Work DIGI ÚP Data úřadu práce do nárok. podkladů 1 64 DIGI ZVS Data ZVS do nárok. podkladů DP 1 65 EVCZ-ÚČTY Zpětné výplaty deviz. cizoz. na účty v zahr EXEKUCE - KARTY Exekuce 1 67 INV1 Zastavování I důchodů 1 68 JHOD (důch. ES) Výpočet jednotkové hodnoty důch. pro Evropu 1 69 KALKULAČKA (DŮCH ES) Výpočet úroků důchodů ES (EUU) 1 70 KONTO PŘÍJEMCE Konto příjemce - výkaz výplat aj. z VYP 1 71 LEXIKON Číselník PSČ dle obcí i jejich částí 1 72 NARBOJ Odškodnění podle zák.č.261/2001 Sb ODVLEC Odškodnění podle zák.č.172/2002 Sb

24 Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 74 PECE Evidence péče o osobu blízkou 1 75 PERZ Odškodnění podle zák.č.217/1994 Sb PHV - vyuţívána jiţ jen archivně (od II/09) Aplikace pro sledování výplat na poštu 77 PVT APT pro tisk klasických rozhodnutí 1 78 PZ Informace o zemřelých 1 79 RISOP Urychlené telegrafické poukazy 1 80 SOP2 Opakované poukazy - poštovní poukázkou 1 81 SOUDNÍ2 Aplikace pro evidenci soudních spisů 1 82 SRD aplikace pro výpočet důchodů 1 83 SUC storna výplat na účty 1 84 SUP Storno výplat poukázkou 1 85 UI45-DIP jiţ neudrţována 1 86 UI45-INP Nárokové podklady DP 1 87 UIDV Digi 2P 1 88 USP Přestěhování z a do domova 1 89 USP ADR. ŠTÍTKY 1 90 VDOVY Vdovy 1 91 VELKOVIZÍR Umoţňuje náhled na NP DP 1 92 ZAHD Aplikace pro doplatky důchodů na účet v ČR důchodcům ţijícím v cizině 1 93 ZAHR Evidence zahraničních důchodů 1 94 ZAVY Zákazy výplaty - nds 1 95 ZR (zamítavá rozhodnutí odb42) Zamítavá rozhodnutí odboru ŢR Ţivnostenský registr 1 97 DD Opravy ve výplatách do ÚPS (úmrtí, změna ÚSP,..) 1 98 MED evidence důchodů 1 99 OBS práce na obstavených důchodech RDI registr důchodových informací DIGI - PDŮCH Data o I důchodech do nárok. podkladů DP SED důch. doklady OSVČ - 2.část konta CNB obraty důchodových účtů pro účtárnu CNBA obraty důchod. účtů pro účtárnu - archiv UIP2 (KL) Oprava datových vět KIC krácení částečných invalidních důchodů SLOVENSKO Slovensko WRC WebDRC 1 4. Výplata dávek Celkem Exekuce, evidence a realizace exekučních sráţek, 109 EXK 1 zajištění nároků a výplat oprávněným 110 PRIKAZ Zpracování převodních příkazů PRIKCS Příkazy z ČSSZ do ČNB PZV Procentní ztáta výdělku S357 Odškodnění účastníků odboje SLOZENKY Sloţenky (A) SPRIZ Správní řízení UDAVKY Dávkové programy UPAV Zpracování poštovních poukázek typu "A" VYP - DUCH (EKIS) Výplatní modul - důchodové dávky VYP - NEM (EKIS) Výplatní modul - nemocenské dávky UTM aplikace SRD, RDIL, MED, SO, VDOVY, (staré UTM aplikace) RRP Registr rodičovských příspěvků

25 Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 122 VYDAJE Výdajový účet OSSZ VYKNE Výkazy nedoplatků 1 5. Správa údajové základny Celkem MALORG Malé organizace CRP Celorepublikový rejstřík plátců EDS Elektronický dávkový spis ELDZ Přenos dat do centrál.evidence IDV Informace o dobách a výdělcích KE Kmenové evidence KE2 Kmenové evidence LPS Lékařská posudková sluţba PSL Aplikace Posudky pro LPS ORGAN Rejstřík organizací VPO1 Určování příslušnosti k právním předpisům o SZ DRC aktuální Rozhraní na KE DRC Proxy Rozhraní na KE OSSZService + KMEN (přenos pro VZT na okresy) SI2 Uţivatelské rozhraní KE Zápis data úmrtí Zápis data úmrtí do KE VZT Registr pojistných vztahů (PPV) IPK Interní podmět KE CRO15 15-letí z CRO do KE CRZ Změny z CRO do KE TCL KE2 tenký klient VPO Volný pohyb osob UI08 Zpracování odmítnutých dokladů na OSSZ UI42 DIGI 2P UI44 Správa Kmenových evidencí 1 6. Ekonomické subsystémy Celkem EKIS Informační subsystém ekonom. Agend INS Insolvenční řízení Podpůrné systémy pro zpracování statistik 1 7. Průřezové subsystémy Celkem ESS Elektronická spisová sluţba Workflow PŘKPS/WFS Řídící platforma/posunovač a prohlíţeč reportů 1 Informační subsystém - evidence, zpracování, 154 DMS vyhledávání a ukládání informací (dokumentů a dat), řízení jejich oběhu, datová integrace Zaručený elektronický archiv 1 8. Subsystémy oblasti bezpečnosti Celkem 156 AAA PKI 1 9. Podpůrné systémy Celkem DAK Datový katalog DIG Úpravy aplikací DIGI POSTY Číselník pošt WKOCIN Kontrolní činnost VO na notebooku ZPRAVA Účetní zpráva OSSZ, DP CIS číselníky DM Viewer Kukátko do DMS pro EXK ZDV Prohlíţeč XML datových vět v dbzdv 1

26 Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 166 APS Automatizovaná podpora školení ASPI Databáze právních informací BZD Prohlíţeč XML datových vět v dbzdv CC HiPath ProCenter Enterprise (Call centrum) Cominfo Docházkový systém - ústředí, obj. Sokolovská Cominfo Objekt OSSZ Zlín DBA správa databanky DocuLive Elektronický oběh dokumentů - ústředí Docházkové systémy pracovišť Rozšiřování Elektronické šablony pro průkazky 176 eltabule Informační tabule VS K. Vary HS Hotelový systém IVD Informativní výpočet důchodu JASU PC účetnictví JASU pro Windows K PAP Janotka (archivní) evidence majetku (Janotka)-ústředí PK Projektová kancelář (sdílený diskový prostor) Platový návrh(šablona) odb PortLink e-podání SDP- ústředí skenování na scaneru SDP- lokality (Quick Scan) Stacionární digitalizační pracoviště na scannerech Fujitsu a Kodak 187 SML Systém pro evidenci smluv LEPRAK Tisk samolepících štítků LIBS knihovny MIS Malý informační server MOS podpora K-Softu REK záznam o reklamacích při akcích RŢP Registr ţivnostenského podnikání Sodex Objednávky stravenek SPIS Systém pro správu organizačních směrnic ČSSZ STAT Statistika úspěšnosti výběru pojistného Století a starší (statistika) SYS správa systému Text_do_excelu různé vstupní soubory TV TV okruh K. Vary UNICOS (archivní) Mzdová agenda Webtransactions Komunikace s aplikacemi MF ZDV Browser kukátko do databáze zdrojových datových vět WFS Kukátko do sluţeb platformy pro řízení procesů a 205 PNP Prohlíţeč nárokových podkladů Nprijmy3 Přehled o příjmech - SSP Software - XML 602Filler pro RELDP,ELDP09, PRIHL, ONZ, OSVC_PRE, šablony formulářů PVPOJ, USRCERT 208 AKE3 (KE1160, KE119) CNS Modulární systém firmy CNS ECP přidělení evidenčního čísla pojištěnce EOD Elektronický oběh dokumentů PREV Převody plateb na příjmovém účtu PREVZ Převody zůstatků v kontech plátců MOD 3001 Komunikační modul SRD x DIGI aplikace

27 Číslo Oblast/zkratka Název aplikace Celkem Centralizov ané Lokální 215 OCR - ONZ, PO SEC Digi 2P SledSpisu - odb SO zpracování soudních sporů s důchodci SOP1 Opakované poukazy na účty + obstávky 1 Aplikace pro stornování plateb na účet v období 220 SUC "po úzavření" PC a VC a před samotným 1 zpracováním těchto výplat přes ČNB. Aplikace ČSSZ celkem Proces centralizace aplikací úspěšně pokračuje, coţ dokumentuje podíl centrálních aplikací na celkovém počtu aplikací, který činí 79 %. V současné době jsou vytvořeny podmínky pro jeho postupné dokončování. Mezi nejdůleţitější aplikace kandidáty na centralizaci jsou OSVČ, DOPOJ a KOCIN. Proces postoupil natolik, ţe jiţ bude moţné vytipovat, které aplikace nebudou centralizovány a zbytek bude zařazen do plánu změn. Hlavní Lokální aplikace, které je ještě nutné centralizovat KOCIN kontrolní činnost o Centralizace je v plánu investičních akcí na rok 2010 ale z důvodu nedostatečnosti finančních prostředků proběhne v roce 2010 pouze 1. etapa, která nahradí funkcionality lokální aplikace. o Data budou jednotná, konsolidované podle kmenových evidencí a dostupná kterémukoliv pracovišti bez lokalizačních omezení. o Od roku 2011 je nutné plánovat další rozvoj nové centrální aplikace. DOPOJ dobrovolné pojištění o Evidence osob, určení VZ, pořizování plateb, zúčtování, předání informací do oblasti nárokových podkladů DP, tisk ELDP. o Cílově bude součástí centrální aplikace POJ jako další modul a evidence pojistného vztahu musí být zajištěna ve VZT. PECE péče o osobu blízkou lokální aplikace EVDOB a centrální aplikace PÉČE o Nyní se na lokálních pracovištích pomocí aplikace EVDOB vydávají rozhodnutí, tato rozhodnutí jdou fyzicky do ČSSZ, kde jsou vkládána do centrální aplikace PÉČE ( kontrola na duplicity) odtud jsou relevantní informace předávány do oblasti nárokových podkladů důchodového pojištění. o Záměr je nahradit tyto 2 aplikace jedním modulem ve VZT (včetně předávání dat do nárokových podkladů). o Analyticky připraveno. OSVC důchodové pojištění o Nejrozsáhlejší agenda vedená na lokální úrovni pro evidenci a výběr pojistného na důchodové pojištění OSVČ + předávání informaci do oblasti nárokových podkladů důchodového pojištění. o Cílově plánováno zařazení do centrální úlohy POJ jako další z modulů. o Předpokladem je vytvoření centrální evidence OSVČ v KE a VZT ( nyní je v POJ vyuţíván registr CRP) a zajištění s tím souvisejících úprav oblasti VZT. o Pak je nutné zapracovat všechny potřebné funkcionality z lokálního zpracování N_OSVČ, N_SANKCE, N_POJS N_UCET ( pořizování přehledů o příjmech a výdajích, pravděpodobná výše pojistného, pořizování splátkových reţimů, nedobytné pohledávky, umísťování plateb atd.) o Zatím není analyticky řešeno. EVZAD evidence žádostí o dávky důchodového pojištění o Funkcionalita je částečně nahrazena vytvořením statistik a reportů ze ZDD od ledna o Zbývající funkcionality ( informace, zda je ţadatel OSVČ, zda ţádost byla vyřízena, evidence ţádostí o změnu stupně invalidity) musí být zajištěny v ZDD, poté je moţné tuto lokální aplikaci ukončit. SPRIZ aplikace pro správní řízení o V rámci projektu INS bude vytvořen nový centrální SPRIZ se všemi potřebnými funkcionalitami. o Řešení je analyticky připraveno, nutno zajistit finanční prostředky. 27

28 MALORG o Tato aplikace je zatím aktualizována daty z centra především pro potřeby lokální aplikace KOCIN a SPRIZ a pro dohledávání historických údajů agendy POJ (zpětné přehledy MO). o Po centralizaci agendy KOCIN a SPRIZ je moţné upustit od aktivní aktualizace, ale bude zřejmě nutné zachovat pasivní náhledy na data pro historii. o Dále ji nutno vyřešit jednu z funkcionalit evidence podání ELDP a to buď ve VZT nebo novou samostatnou centrální aplikací analýza problematiky je jiţ vypracována. Obecně je nutné koncepčně zajistit dlouhodobou archivaci historických lokálních dat včetně přístupů k nim. Dokončení centralizace agend je základním předpokladem realizace záměrů důchodové reformy a je snaha formulovat projekt na její konečné dořešení. 2.6 Popis vazeb IIS ČSSZ na jiné ISVS IIS ČSSZ ve smyslu zákona č.365/2000 Sb., a Vyhlášky č. 529/2006 Sb., nemá ţádné přímé externí vazby na informační systémy veřejné správy. Ze zákona č. 155/1995 Sb., o důchodovém pojištění, zákona č. 582/1991 Sb., o organizaci a provádění sociálního zabezpečení a zákona č. 48/1997 Sb., o veřejném zdravotním pojištění eviduje ČSSZ data a spravuje rozsáhlou datovou základnu o osobách převáţné části populace ČR, kterým poskytuje sluţby v těchto oblastech. Charakter činnosti ČSSZ vyţaduje, aby tato uchovávaná citlivá data (osobní údaje) byla průběţně aktualizována a věrohodná. Tyto informace jsou doplňujícími informacemi k základním registrům veřejné správy a dalším celostátním registrům a relevantním evidencím a ČSSZ má zákonnou povinnost tato data poskytovat oprávněným subjektům veřejné správy. Zároveň vyuţívá a spolupracuje zejména s evidencí obyvatel a vyuţívá data z obchodního rejstříku a v budoucnu plánuje vyuţívání dalších registrů programu e-government. Vazby na registry egovernmentu znázorňuje následující obrázek. Centrální místo sluţeb (CMS) IIS MPSV Datové schránky (ISDS) Portál veřejné správy (PVS) Jednotné inkasní místo (JIM).. IIS ČSSZ Informa ční systém základní ch registrů ISZR Registr osob (ROS) Registr obyvatel (ROB) Registr územní idetifikace adres a nemovitostí (RUIAN) Registr práv a povinností (RPP) 28

29 Česká pošta Obrázek 9 - Vazby na registry egovernmentu ČSSZ proto spolupracuje při zajišťování svých úkolů s ostatními orgány státní správy a organizacemi a dalšími subjekty, které se podílejí na provádění sociálního zabezpečení v České republice nebo vykonávají jiné činnosti s touto oblastí bezprostředně související. ČSSZ ve výše uvedených oblastech spolupracuje zejména s: Orgány sociálního zabezpečení Ministerstva obrany, Ministerstva vnitra a Ministerstva spravedlnosti, vzájemné předávání podkladových materiálů a výplat některých důchodů. Ministerstvem zdravotnictví (ve věcech lékařské posudkové sluţby), Všeobecnou zdravotní pojišťovnou (ve věcech lékařské posudkové sluţby, údaje o zániku nároku na některé druhy důchodů) a dalšími zdravotními pojišťovnami. Ministerstvem financí ve věcech rozpočtových prostředků, zřizování nových účtů. Peněţními ústavy (výplata důchodů na účty), především s Českou národní bankou, která vede účty ústředí ČSSZ a detašovaných pracovišť ČSSZ. Státním podnikem Česká pošta, který zajišťuje většinu hotovostních výplat důchodů. Zdravotnickými zařízeními při posuzování zdravotního stavu a zajišťování výplat důchodů do těchto zařízení. Ústavy sociální péče při zajišťování výplat důchodů do těchto zařízení. Fyzickými a právnickými osobami při plnění úkolů v oblasti sociálního zabezpečení a lékařské posudkové sluţby. V rámci legislativního procesu a přípravy koncepce sociálního zabezpečení spolupracuje ČSSZ se členy příslušných výborů Poslanecké sněmovny a Senátu Parlamentu ČR. Při mezirezortních připomínkových řízeních ČSSZ spolupracuje i s dalšími ústředními orgány státní správy ČR. Komunikace ČSSZ s tímto okolím má různé formy jak listinné tak i elektronické. Elektronická komunikace je rozvinutá na bázi elektronické pošty (spíše individuálního charakteru), je vyuţívána elektronická podatelna a různé formy výměny údajů na médiích i elektronicky výměnou souborů. Od roku 2004 je vyuţíváno pro elektronická podání Portálu veřejné správy a v souladu se zákonnými předpisy je vyuţíváno i Informačního systému datových schránek ISDS. Objemy elektronicky sbíraných a přenášených dat a poţadavky na další oblasti komunikace vyţadují, aby ČSSZ věnovala této oblasti prvořadou pozornost. Následující tabulka schématicky ukazuje strukturu účastníků komunikace s ČSSZ. 29

30 Obrázek 10 Účastníci komunikace s ČSSZ Komunikační vazby IIS ČSSZ na okolí znázorňuje následující schéma: 30

31 Obrázek 11 - Komunikační vazby na okolní systémy - současný stav Toto schéma znázorňuje současný stav v komunikaci ČSSZ s okolím. Dosud neřešené oblasti komunikace jsou vyznačeny bíle. S ohledem na výše uvedenou situaci byla navrţena koncepce řešení rozhraní pro komunikaci ČSSZ a vazby komunikačních a ostatních informačních systémů (na IIS ČSSZ a okolí) které je blíţe popsáno v oblasti Rozhraní pro komunikaci IN/OUT. 2.7 Forma komunikace IIS ČSSZ s okolím a klienty Komunikace s okolím a klienty má pro ČSSZ mimořádný význam. Základním trendem je snaha dosáhnout co nejvyššího podílu komunikace ve strukturované datové formě, kde výsledkem je automatizovaně zpracovatelná datová věta. Mimořádný význam hrají v této komunikaci elektronické formuláře, které dosáhly velkého rozšíření a bude jim do budoucna přikládán rozhodující význam. Prostřednictvím elektronických formulářů získává ČSSZ strukturované informace, které jsou dále zpracovávány v aplikacích IIS ČSSZ. Česká správa sociálního zabezpečení přijímá a zpracovává jiţ dlouhodobě souběţně formuláře jak v papírové podobě, tak v elektronické podobě. Kaţdý rok je stále větší nárůst formulářů zasílaných v elektronické podobě. I nadále bude nutno s tímto souběhem klasických a elektronických formulářů počítat. Formuláře, které se vytěţují, jsou navrţené a optimalizované pro OCR zpracování, tedy v drop out barvách, s pozičními, synchronizačními a identifikačními značkami, přehledně rozdělených do sekcí a na jednotlivá vyplnitelná datová pole. OCR linky pro vytěţování papírových formulářů a pořizovací linky (systémy pro typování dat z papírových dokladů) transformují papírové strukturované dokumenty (papír) na elektronická strukturovaná data (datové věty). Elektronické formuláře mají tu přednost, ţe nevyţadují konverzi do formy datových vět a nákladnou operaci konverze zabezpečuje sám původce formuláře (klient). V současné době se objevují nové technologie zpracování dat jako je technologie zaloţená na principu čárového kódu 2D. Technologie je zaloţena na standardu PDF417 pro 2D čárové kódy a umoţňuje 31

32 jednoduchým způsobem zpětně vytěţovat data z elektronických formulářů, které je potřeba podat na úřad v papírové podobě. Vlastní zpracování probíhá načtením dat z čtečky zpět z vytištěného formuláře do elektronického tak, aby se dalo, po odevzdání papírového originálu označeného 2D čárovým kódem, ihned pracovat s daty. S touto technologií bude nutno počítat tam, kde není dostupná technika pro nasazení elektronických formulářů. ČSSZ přechází na vývoj a návrh elektronických formulářů vlastními silami s cílem odstranit závislost na dodavatelích. 32

33 3 Koncepce rozvoje aplikační podpory jednotlivých oblastí IIS ČSSZ Rozvoj aplikační podpory jednotlivých oblastí je realizován prostřednictvím aplikačních projektů v rámci jednotlivých subsystémů IIS ČSSZ. Tyto projekty jsou zaměřeny na vývoj nových a technické zhodnocování provozovaných aplikací. Je však nutno zdůraznit, ţe po realizaci základních transformačních projektů a náběhu aplikací do rutiny se mění charakter projektů. Tyto projekty mají charakter technického rozvoje jiţ existujících a provozovaných aplikací o novou funkcionalitu s moţným vlivem na infrastrukturu, vývoje nových funkcionalit v návaznosti na dosud neautomatizované procesy nebo nové procesy vznikající na základě nových zákonných předpisů případně optimalizací průběhu dosavadních procesů, centralizace dosud lokálně provozovaných aplikací, modernizace starých podpůrných systémů o novou funkcionalitu a jejich integrace do IIS. Tyto procesy však často překračují hranice jednotlivých dosud logicky vymezených oblastí a na ně navazujících subsystémů IIS a tím je velmi obtíţné lokalizovat zejména průřezové projekty do jediné oblasti procesů. Tím se silně komplikuje popis oblastí a postupně bude nutno vybudovat matici vazeb projektů na oblasti. Objem informací, které na ČSSZ oprávněně ze zákona poţadují její klienti stále narůstá a ČSSZ má ze zákona povinnost informace těmto osobám poskytnout. Se záměrem přímé komunikace s klienty se výrazně mění i charakter oblasti OUT, která fyzicky pouţívá stejné infrastruktury jako oblast IN a vyţaduje systémové řešení jednak v rámci přípravy on-line reakce ČSSZ a jednak i v oblasti odpovědí prostřednictvím elektronických dokumentů. V této oblasti jsou realizovány dále uvedené záměry a projekty. I nadále je nutno počítat s tím ţe budou probíhat procesy spojené s produkcí a expedicí listinných dokumentů, které jsou téţ podporovány IKT technologiemi. Spolupráce na elektronizaci styku s veřejností v příslušných oblastech Aktivity v této oblasti byly zaměřeny směrem na komunikaci s organizacemi, která je velmi rozsáhlá a doznala značných systémových změn v oblasti nárokových podkladů. ČSSZ zahájila v rámci této komunikace příjem e-podání v prosinci roku 2004 prostřednictvím APV pro příjem a zpracování e-podání v tzv. DIS systému. Podání jsou přijímána zcela automatizovaně přes Portál veřejné správy, alternativou je nahrání elektronických dat referentem z diskety nebo CD (jen pro typy formulářů: RELDP, ELDP, PRIHL a ONZ). Kaţdé podání musí být digitálně podepsáno (od února 2006 výhradně zaručeným elektronickým podpisem) a kaţdé podání je z důvodu ochrany osobních dat klientů šifrováno šifrovacím certifikátem. Situace se zkomplikovala zákonným zavedením informačního systému datových schránek (ISDS) a povinnost orgánů veřejné moci jej vyuţívat. S ohledem na nezajištění provozu PVS po bylo uloţeno úseku IKT navrhnout řešení této situace. Uživatelská rozhraní jednotlivých aplikací Základním pilířem koncepce IIS ČSSZ je zajištění aplikační podpory klientského přístupu ve všech oblastech její aktivity. Slouţí k tomu jednak uţivatelská rozhraní jednotlivých aplikací, která dovolují vyřizovat i osobní návštěvy klientů. Dále jsou to centralizované aplikace a centralizovaně spravovaná data v databázích ČSSZ, které dovolí postupně opustit územní princip, protoţe jejich dostupnost nebude lokálně omezená. Mezi základní podporu klientského přístupu patří aplikace ZDD pro sepisování ţádostí o důchod, aplikace NEM, která dovoluje vyuţít data při osobní komunikaci s klienty a další aplikace, které podporují aktivity OSSZ při jednání s klienty. Na ţádost poskytuje ČSSZ i informace získané z nárokových podkladů. V současné době se zvyšuje i objem dat, které vyţadují ze zákona partnerské organizace ( třetí strany ). Realizace požadavků věcně příslušných odborů k podpoře klientského přístupu Styk s externími subjekty, do zbudování klientského portálu prostřednictvím B2B Vytvoření informačního a komunikačního rozhraní České správy sociálního zabezpečení za účelem poskytování informací klientům s cílem vytvořit takové komunikační rozhraní, které dovolí poskytovat sluţby občanům, pojištěným osobám, organizacím a ostatním subjektům (třetím stranám) je předmětem Projektu 159. Vzhledem k tomu, ţe jde o náročný projekt, který bude vyţadovat delší dobu realizace, bylo nutno reagovat na poţadavky oprávněných poţadujících data. Do doby, neţ bude realizován projekt 159 a vytvořeno komunikační rozhraní jsou připravovány níţe uvedené způsoby komunikace a elektronická 33

34 výměna dat prostřednictvím standardizovaného rozhraní a webových sluţeb (označované jako metody B2B respektive A2A, B2A). Přebírání dat z MPO ČR: Denní aktualizace databáze Rejstříku ţivnostenského podnikání a denní přebírání Jednotných registračních formulářů. Přebírání je realizováno prostřednictvím Portálu veřejné správy a DIS systému. Vyuţitím rozhraní PVS ČSSZ vyuţila jiţ vybudované přenosové cesty. Vyřizování dotazů exekutorů: Byla uvedena do provozního vyuţívání automatizovaná podpora vyřizování dotazů exekutorů na výši vyplácených dávek prostřednictvím nového typu e-podání EXI prostřednictvím APV dodaného ČSSZ jednotlivým exekutorským úřadům vyuţitím jiţ vybudovaného rozhraní PVS - DIS systém, odkud je dotaz automaticky předán do systému SAP a po obdrţení odpovědi stejnou cestou poslán zpět do APV exekutora. Kontrolní činnost a informační povinnost ČSSZ: Na základě odsouhlaseného katalogu poţadavků rozvoje byly realizovány úpravy aplikace TCL (Tenký klient KE) a souvisejících částí systému Kmenových evidencí, pro řešení problematiky sestav nad daty centrálních registrů KE a VZT pro účely kontrolní činnosti a informační povinnosti ČSSZ vůči soudům a Policii ČR. Vyřizování dotazů zdravotních pojišťoven: Ve fázi návrhu řešení a posouzení alternativ je příprava automatizovaného přebírání dotazů zdravotních pojišťoven a předávání odpovědí výměry dob ze zdravotního pojištění. Datové schránky: Vzhledem k tomu, ţe počet dodaných datových zpráv (DZ) do ústředí ČSSZ dlouhodobě dosahuje počtu 1500 DZ/den, bylo přijato řešení, které částečně automatizuje úkony operátorek odboru 16, které provádějí při příjmu, zpracování, evidenci a archivaci dodaných DZ. Obdobné řešení se připravuje pro zajištění expedice zpráv do datových schránek klientů, kteří vlastní datovou schránku. Řešení je popsáno v oblasti 1 IN/OUT dále. Elektronická neschopenka: Účast na přípravné fázi tohoto projektu, jehoţ cílem je vyřešit způsob vystavování a zpracování elektronické neschopenky v procesu průběhu neschopnosti pojištěného elektronickou cestou a odstranit v současné době problematický systém fungování papírové formy neschopenky. Pozornost byla soustředěna především na komunikaci lékařů s ČSSZ. Řešení je jiţ koncipováno s ohledem na plánované vybudování rozhraní pro komunikaci s klienty a je popsáno v oblasti NEM. Řešení problematiky Portálu veřejné správy ve vztahu k projektu ISDS Datové schránky - úkolem vedení 1-27/09 - Vytvořit harmonogram přípravy náhrady PVS komunikací prostřednictvím datových schránek po byly v roce 2009 zahájeny práce na řešení tohoto problému. Vytvoření veřejného rozhraní pro elektronická podání (rozhraní VREP) souvisí se snahou zachovat a převést dnešní komunikaci s organizacemi prostřednictvím PVS do podmínek a prostředí ČSSZ. 3.1 Oblast 1 - Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací Rozhraní pro komunikaci s klienty ČSSZ (Klientský portál) (subsystém 1.1) ČSSZ stanovila jako nezbytné řešení vytvoření vhodného uţivatelsky komfortního elektronického komunikačního kanálu a zvýšení podílu elektronizace při vyřizování těchto poţadavků. Je to jediný způsob, jak efektivně tyto sluţby zajistit. Řešení představuje propojení informačních sluţeb pro klienty ČSSZ a informační podpory pro poradenské sluţby poskytované zaměstnanci ČSSZ klientům v návaznosti na nabyté zkušenosti a vytvoření potřebných vazeb na procesy klíčových agend ČSSZ při zajištění maximální ochrany údajů a zabránit jejich zneuţití vyuţitím odpovídajících systémů zabezpečení. V době, kdy centrální systémy ČSSZ procházejí transformací a většina údajů je převáděna do elektronické podoby, je nezbytné na tento proces navázat i v oblasti komunikace s klienty a pomocí výše uvedené oblasti Rozhraní pro komunikaci umoţnit klientovi ČSSZ získávat oprávněné informace. Zároveň tím můţe ČSSZ dostát zákonným povinnostem i vůči jiným institucím veřejné správy. Pro řešení tohoto úkolu byl realizován v rámci programu Transition facility projekt pod názvem Klientský portál pro Českou správu sociálního zabezpečení. Projekt byl realizován v první polovině roku 2009 týmem odborníků ČSSZ spolu s řešitelem projektu za Spolkovou republiku Německo Německou správou důchodového pojištění pro Vestfálsko (DRV). Cílem tohoto twinningového projektu bylo vytvoření návrhu řešení klientského portálu, který by umoţnil klientům ČSSZ elektronický přístup k jejich datům, uloţeným v databázi. Výstupem projektu je závěrečná zpráva projektu, s přílohou technická zpráva ( Annex Technical Report), kde jsou shrnuty výsledky analýz a návrhy řešení výše uvedené problematiky včetně specifikace poţadavků. Počátkem roku 2010 byla zpracována a předloţena MV ČR k dalšímu jednání Studie proveditelnosti Projekt č Vytvoření informačního a komunikačního rozhraní ČSSZ za účelem poskytování informací klientům : 34

35 Cíle: Umoţnit kvalitnější, rychlejší a flexibilnější veřejné sluţby ČSSZ poskytované klientům elektronickou cestou, zvýšit jejich podíl na celkovém počtu objemu vyřizovaných poţadavků klientů a přispět k modernizaci veřejné správy České republiky. Zvýšit informační podporu pro činnosti vykonávané zaměstnanci ČSSZ a vytvořit podmínky pro informační podporu kontrolních činnosti u kontrolovaných subjektů s přímou podporou aplikačního vybavení IIS ČSSZ. Realizovat jednotné, integrované zabezpečené prostředí ČSSZ pro elektronickou komunikaci a výměnu dat s klienty umoţňující rychlou realizaci nových sluţeb a vznik odpovídající knowledge databáze vyřizovaných poţadavků klientů. Zajistit další rozvoj informačních a komunikačních technologií ČSSZ, a tím vytvořit podmínky pro zvýšení podílu automatizovaně realizovaných procesů v oblasti obsluhy klientů i z hlediska podpory výkonu činností zaměstnanců ČSSZ. Sníţit náklady na referentský způsob vyřizování poţadavků klientů, zejména v oblasti osobních nákladů, nákladů souvisejících se zpracováním papírových dokumentů a na poštovném. Vazby na egovernment: projekt integruje přístup ČSSZ k ZRVS, ISDS, CMS a dalším ISVS při zabezpečení osobních dat v IIS ČSSZ proti zneuţití Vazby na jiné projekty ČSSZ: Projekt je základem pro vybudování zabezpečeného přístupu klientů do IIS ČSSZ jako předpoklad pro náhled klientů na jejich osobní data. Bez tohoto rozhraní nebude moţné realizovat navrhované principy důchopdové reformy, tj. průběţného sledování individuálních důchodových kont klienty. Tento projekt umoţní ČSSZ poskytovat klientům stejný přístup do ČSSZ jako prostřednictvím PVS. Integrace rozhraní a vazby na IIS ČSSZ zobrazuje obrázek č. 3 - Organizace procesů podle SOA principu, protoţe současně dokumentuje nový přístup k organizaci procesů v ČSSZ. Uvedený návrh vyžaduje řešit následující oblasti IIS: Vytvořit: o standardní rozhraní B2B, Czech POINT Rozhraní, rozhraní B2C (pro komunikaci fyzických osob), o portálové řešení pro bezpečnou komunikaci s pojištěnci, třetími stranami včetně poskytování specializovaných sluţeb (dále portál). o Koncepčně vyřešit oblast OUT a vymezit role a funkce v IIS ČSSZ Rozšířit a zaintegrovat: o DIS subsystém o vazbu na DSS a zabezpečit přesměrování strukturované komunikace z dosavadního systému PVS na VREP rozhraní a vyuţít DIS subsystému o oblast PŘKPS o registraci všech došlých podnětů ze všech komunikačních kanálů, o oblast IN o procesy validace a testování vstupních podnětů a zabezpečení čistých dat pro systém, o subsystém AAA portál o Identity Access Management klientů a externích subjektů, o postupně všechny aplikace o podporu sluţeb portálu, prioritně aplikace VYP NEM, ZDD, POJ, KE, VZT, DMS, EXK, PSL, aplikace důchodové oblasti IKP,SRD a EKIS. Rozšířit nebo pořídit licence a nakupovaný SW: o o o ITIM/ITAM licence pro Identity management, licence portálového řešení, další licence pro monitorování, audit a dohled. Doplnit HW platformu v těchto oblastech: o síťovou infrastrukturu pro vytvoření komunikačních kanálů a HW rozhraní (přípojů), o integrační, testovací a produkční prostředí datového úloţiště o: kapacity datových serverů dimenzované na 7/24, kapacity diskových polí s plným duplexem v rozsahu 2x 40 TB pro ukládání (zálohování) vstupujících a odesílaných dat, o integrační, testovací a produkční prostředí aplikační vrstvy, a to: doplnění serverových farem o blade servery, a to pro oblast AAA (WebSealy)a další aplikace, které budou vyţadovat posílení (NEM,KE,BizTalk), 2x16 procesorů ro doplnění databázových serverů datového úloţiště doplnění Master Serverů v clusteru, aplikačních, databázových, business serverů, AAA/portálu o kapacity paměťových oblastí pro logování na DÚ 35

36 Síťové a doplňující komponenty včetně UPS. HW platforma bude doplňována podle bezpečnostních pravidel platných pro architekturu v ČSSZ, zejména podle principů lokálně odděleného duplexu. Funkcionalitu projektu č. 159 znázorňují následující obrázek.. Portál Statické informace Portálové aplikace Báze vlastních informačních zdrojů Číselníky a řízené slovníky SW nástroj pro vyhledávání Call centrum Zaslání dotazu Podpora klientů Virtuální schůzka Návody, scénáře Aplikace Poradenství Call desk Služby pro zodpovězení dotazu Služby pro vstup dat do procesu ČSSZ Nástroj pro management problémů Nástroj pro monitorování procesu informační podpory Elektronická výměna dat Vstup-rozhraní na oblast IN Programem zdarma Z aplikací třetích stran Z datové schránky Zpracování dat Ověření oprávnění přístupu Řízení kompletace dotazu, rozhraní s aplikacemi ČSSZ Logování transakcí Výstup rozhraní na oblast OUT Poštou na trvalou adresu Do datové schránky em SMS zprávou na mobilní telefon Nástroj pro monitorování transakcí Doplnění funkcionality aplikací Služby aplikací Komunikace zaměstnanců ČSSZ Vzdálený přístup k aplikacím Řízení přístupu k externím službám Služby pro zodpovězení dotazu Služby pro vstup dat do procesu ČSSZ Obrázek 12 - Služby poskytované klientským portálem Projekt předpokládá etapovité řešení a bude poskytovat: Služby pro vstup dat do procesu ČSSZ Sluţby, které na základě vstupních dat zahájí proces zpracování v příslušné agendě ČSSZ: Hlášení změn od pojištěnce. Rozšíření elektronické evidence dokumentů. Služby podpory klientů: Elektronická rezervace termínů (e-termín). Zadání dotazu do Call Desku asynchronní poradenství. Podpora činností pracovníků ČSSZ (pracovníků Call Desk). Virtuální schůzka aplikace pro synchronní poradenství. Nástroj pro monitorování procesu informační podpory. Implementace funkcionality Správa obsahu báze vlastních informačních zdrojů. Implementace funkcionality Návody a scénáře pro dynamické zpřístupnění informací z aplikací ČSSZ. Příprava a testování prostředí pro implementaci služeb v etapě 5. Další služby definované v 1.etapě (detailní technický projekt a implementační plán) pro 4.etapu. Služby pro on-line zodpovězení dotazu na aplikace ČSSZ Informativní osobní list důchodového pojištění. Potvrzení o výši pobíraného důchodu. Zaplacené pojistné a zálohy OSVČ. Náhled na seznam pracovních neschopností. Potvrzení o druhu a výši dávek. Náhled na stav a průběh vyřizování ţádosti o dávku. Náhled do evidence zaměstnanců a pracovních neschopností. Upozornění o pracovní neschopnosti zaměstnance. Potvrzení o stavu pohledávek. 36

37 3.1.2 Aplikační podpora rozhraní pro zabezpečení komunikace IIS ČSSZ s klienty - subsystém 1.1 Komunikační vstupní linky budou napojeny na oblast rozhraní, jejichţ funkcí bude tvořit styčný bod do vnějšího prostředí a budou pro aplikace adresou, na kterou bude aplikace PŘKPS vhodně navázána. Jde o následující rozhraní: B2B rozhraní Bude prezentováno na klientském portálu jako externí sluţba pro přijímání dávek dat a souborů. Základem je připravované řešení komunikace s MPSV, které je vytvářeno v současné době pro komunikaci s MPSV. Navrţené řešení bude realizováno jako minimální varianta komunikace B2B a cílové řešení a je uvedeno v kapitole Koncepce technologické infrastruktury IIS ČSSZ. Ošetření komunikace prostřednictvím B2B rozhraní musí být zabezpečeno v jednotlivých aplikacích jednak na straně ČSSZ a jednak na straně vnějšího partnera. Součástí ověřovacího procesu je i autentifikace oprávněnosti komunikace přes subsystém AAA. Zbývá dořešit funkcionalitu, aby informace staţené z B2B rozhraní byly přes PŘKPS ihned po staţení automatizovaně prostřednictvím systému PŘKPS sluţbami DISIN předány na DIS_IN subsystém a teprve po kontrole náleţitostí bude předán aplikaci případně přímo propojit aplikaci s aplikací. Kontrola průběhu procesu musí být zajištěna prostřednictví PŘKPS. Obdobou tohoto rozhraní je rozhraní pro přijímání médií na pracovištích ČSSZ, které je dnes součástí DIS systému. Toto rozhraní bude interním rozhraním pro podání médií (zakončení je na jednotlivých OSSZ). Zpráva na datovém nosiči (nejčastěji na disketě) se předá okresní správě. Zpráva se z datového nosiče načte pomocí programu DIS01 klient. Další zpracování je identické s postupem, kdyţ podání přijde z PVS. Jeho funkcionalita jiţ navazuje na PŘKPS. Rozhraní pro portál veřejné správy DIS Server Centrální sloţkou, která podání zpracuje, je tzv. DIS server. Přebírá doručené elektronické zprávy z portálu veřejné správy. Aplikační server přebírá elektronické zprávy ze serveru DIS, který je v prvním kroku zapisuje do databáze. Aplikační server zpracuje doručenou zprávu a pak postupně dodává doplňující informace, které v průběhu zpracování vznikají. Výsledek zpracování zprávy má dvě moţnosti: Zpráva byla přijata, bude poslána do následných subsystémů. Zpráva byla odmítnuta, zůstane v systému DIS a nezpracovává se. Podávající osoba se o výsledku dozví přímo ze svého programu, který byl pro elektronickou zprávu pouţit. Kromě toho dostane podle druhu podání jednu nebo několik ových zpráv s výsledkem zpracování. Veřejné rozhraní ČSSZ pro elektronická podání (VREP) Hlavním kanálem, kterým jsou do ČSSZ přijímána e-podání je Portál veřejné správy (PVS). Infrastruktura je zaběhnutá, rutinně vyuţívána, nicméně je nutné vzít v úvahu i nejistotu, která panuje ohledně dalšího provozování PVS na straně MV ČR, kdy MV ČR předpokládá v krátké budoucnosti ukončení provozu PVS (tč. Je to ). V tuto chvíli lze jiţ vyloučit moţnost, ţe by PVS mohl být provozován i v budoucnu jako doplněk sluţeb poskytovaných ISDS (má přece jen odlišnou funkci a zaměření neţ ISDS). Proto se jiţ nepovaţuje za rozumné vázat jakékoliv nové řešení na z pohledu ţivotnosti nejistou platformu. Pokud se do budoucna MV ČR přece jen rozhodne pokračovat v provozu PVS, bude v případě zájmu ze strany ČSSZ nebo podávajících moţné příjem e-formulářů (např. e-neschopenky) rozšířit s minimálními náklady i prostřednictvím tohoto kanálu. Proto při úvahách, jak nahradit sluţbu poskytovanou PVS a zabránit do jisté míry velmi riskantní moţnosti přechodu od plně elektronické komunikace zpět ke komunikaci k papírové (byť třeba zasílané jako PDF scan před ISDS), byly zvaţovány alternativy: Přesunu celého řešení PVS do infrastruktury ČSSZ. Převzetí části řešení (vyuţívanou funkcionalitu) a integrovat jej s interními systémy ČSSZ. První alternativa se v prostředí ČSSZ ukázala jako nerealizovatelná protoţe infrastruktura ČSSZ díky oddělení vrstev neumoţňuje instalaci PVS bez jeho zásadních změn a také proto, ţe PVS vyuţívá mechanismy, které nejsou pro ČSSZ nezbytné a jsou dány například poţadavky zákona nebo faktem, ţe PVS poskytuje sluţby většímu počtu resortů. Proto se navrhuje druhá alternativa spočívající v převzetí potřebné funkcionality PVS, které bude plně integrováno do prostředí ČSSZ a existujících systémů (PŘKPS, DIS Systém). Tuto variantu jsme nazvali Veřejné rozhraní pro elektronická podání (dále jen VREP,). 37

38 Charakteristika Veřejného rozhraní pro elektronická podání Z pohledu budoucího ukončení provozu PVS povaţuje ČSSZ za vhodné doplnění vstupní oblasti o veřejné rozhraní, které by umoţňovalo efektivním způsobem přijímat elektronická data (e-podání), která jsou dnes přijímána prostřednictvím PVS. Vybudování tohoto rozhraní, které by se do budoucna stalo součástí Klientského portálu ČSSZ, by umoţnilo zachovat většinu bezpečnostních prvků vyuţívaných při ochraně přenášených dat (přenášená data jsou chráněna proti zneuţití šifrováním a elektronickým podpisem), které jsou dnes standardně vyuţívány na PVS a nejsou zákonem vyţadovány v řešení ISDS. Existence VREP by v budoucnu zároveň umoţnila hladký přechod organizací zasílajících e-podání prostřednictvím PVS na řešení nezávislé na externím subjektu (MV ČR) s minimálními nutnými změnami na straně podávajících organizací a firem dodávajících software s podporou pro e-podání. VREP by nebylo náhradou napojení ČSSZ na ISDS (toto napojení je zcela nezbytné), nicméně bude rozšířením moţností příjmu elektronických dat (v souladu s konceptem Klientského portálu ČSSZ). Registrace podávajících bude plně v reţii ČSSZ a bude tedy schopna proces řídit a stanovit si podmínky registrace zcela nezávisle. Toto rozšíření funkčnosti DIS Systému zároveň umoţní zjednodušení stávajícího procesu registrace podávajících a nahradí současnou dvoustupňovou registraci (registrace na OSSZ a na PVS s vyuţitím registračních údajů z předchozího kroku) registrací jednostupňovou (registrace pouze na ČSSZ). Rozhraní VREP bude spuštěno a provozováno paralelně s PVS, aby přechod pro podávající byl co nejhladší. Interní systémy (PŘKPS, DIS_IN subsystém) budou pro tento souběh přizpůsobeny. Přepnutí všech podávajících z PVS na VREP v rámci velkého třesku je nereálné a způsobilo by velké problémy. Délka souběhu VREP a PVS je dána úspěšností kampaně a schopnosti dodavatelských firem upravit v software pro podávající adresu pro směrování podání. Varianty přenosu přes ISDS a příjem přes VREP se vzájemně doplňují a v rámci konceptu Klientského portálu je moţné je implementovat jako dva různé kanály Klientského portálu, pokrývají různé cesty předávání elektronických dat do ČSSZ. Obě varianty shodně vyuţívají jiţ existující subsystémy IS ČSSZ (DIS, PŘKPS), které jiţ mají napojení na aplikace pro zpracování a podpůrné systémy (DMS, ZDV). V obou případech se předpokládá zavádění minimálního mnoţství dalších komponent do IS ČSSZ, naopak vyuţívají v maximální moţné míře existující ověřené části IS ČSSZ. Ěšení vyhovuje i principu ochany investic. Technické řešení VREP Rozhraní pro podávající software a podávací a dotazovací protokol budou v maximální moţné míře kompatibilní s rozhraním PVS, takţe u vhodně napsaných aplikaci by mělo stačit změnit adresu a zajistit důvěryhodnost nových certifikátů. Vystavením rozhraní VREP tak ČSSZ výrazně omezí dopad změn na podávající jejich stávající software by fungoval beze změny, pouze by změnili cílovou adresu (místo stávající adresy by pouţili adresu novou, například Vzhledem k počtu podávajících a zejména počtu e-podání je toto hledisko zcela klíčové. Další výhodou této varianty je pouţití stávajících dokumentovaných postupů pro podávající. Na následujícím obrázku je naznačen způsob komunikace klienta s rozhraním VREP umístěným v DMZ ČSSZ. Vazbu na interní systémy ČSSZ v APP zajišťuje AAA portál. Pro názornost je zakreslena i současná situace s PVS. GovNet jiţ v rámci komunikace mezi PVS a ČSSZ není nadále vyuţíván. Klíčové je, ţe sluţby rozhraní VREP i napojení na ISDS (na obrázku reprezentováno rolí SDS (Server pro datové schránky)) budou moci běţet na stávajícím DIS serveru a také vyuţívat na něm nainstalovaný BizTalk Server a SQL Server. V první fázi DMZ vrstva není ve stávající konfiguraci propojená, jedná se o 2 nezávislé lokality. Později je pravděpodobná nutnost HW posílení včetně rozšíření licencí. Obrázek 13 - Řešení VREP rozhraní 38

39 DSS rozhraní pro připojení k informačnímu systému datových schránek ISDS Připojení pracovišť k datovým schránkám Komunikace s datovými schránkami je v současné době problém, který je postupně řešen. Byl navrţen systém, který je obdobou el. Podatelny, kdy jsou pro jednotlivá pracoviště ČSSZ a ústředí zřízeny samostatné poštovní schránky, pro které byla vyhraţena pracoviště, která tyto schránky spravují. Staţená data se ukládají do centrálního file systému. Tento systém však není koncepčně nastaven na hromadnou korespondenci prostřednictvím datových schránek jako je např. v ústředí. V dohledné době se převede na dále uvedený systém připojení. Prozatímní připojení ústředí ČSSZ k datovým schránkám Pro ústředí ČSSZ vytvořeno propojení prostřednictvím rozhraní aplikace, coţ je přizpůsobené rozhraní aplikace spisové sluţby ICZ (EDS). Toto prozatímní rozhraní zabezpečuje: Komunikaci oprávněných osob se subsystémem ISDS prostřednictvím rozhraní v demilitarizované zóně. Z demilitarizované zóny se přenášejí tyto zprávy do aplikace DAS s tím, ţe je spojení mezi rozhraním v DZ ověřeno subsystémem AAA. V rámci aplikace je nastavena autentizace uţivatele a jsou i nastaveny role, které můţe uţivatel pouţít. Zprávy se ukládají do centrální databáze v datovém úloţišti a současně jsou vytištěny a předány k dalšímu zpracování. Aplikace poskytuje i funkcionalitu pro prohlíţení zpráv. Obrázek 14 - Připojení k datovým schránkám Elektronická výpravna Tatáţ aplikace byla ověřena pro realizaci odesílání datových zpráv z ČSSZ elektronická výpravna. Princip spočívá v tom, ţe prostřednictvím klienta aplikace DAS bude moţno připravovat zprávy na příslušných pracovištích k expedici do datových schránek, tyto jsou uloţeny do databáze a operátorkou expedovány. Přitom jsou zabezpečeny příslušné informace o odeslání včetně doručenky. 39

40 Příjem elektronických podání prostřednictvím ISDS serveru Ač je systém ISDS pro předávání e-podání v současné době méně vhodný neţ PVS, lze nedostatky eliminovat definováním pravidel pro přenos datových zpráv s přílohou e-podání pomocí XSD schematu. Pro předávání e-podání budeme pouţívat dva formáty: jiţ zavedený GovTalk formát a holou XML větu formuláře. Klient si bude moci zvolit, kterému formátu dá přednost. GovTalk formát : umoţní podávajícímu zašifrovat, elektronicky podepsat a odeslat odpověď našeho DIS systému přes ISDS zpět do aplikace odesílatele, tzn. napárovat odpověď o zpracování na zaslané podání. Formát holého XML nevynucuje ani podpis, ani šifrování, a ČSSZ tak splní zákonné podmínky pro systém ISDS. Při zavedení e-podání přes ISDS lze předpokládat, ţe dojde k velkému nárůstu datových zpráv, které budou do ČSSZ přenášeny, a tím k zvýšení administrativní zátěţe referentů a moţné technické nedostatečnosti ISDS. K eliminování tohoto problému se navrhuje: zřídit samostatnou datovou schránku vyhrazenou pro e-podání, automatizovat při přebírání datových zpráv s přílohou e-podání nově vybudovanou komponentou SDS server, zprávy obsahující e-podání netisknout, ale ihned po staţení automatizovaně prostřednictvím systému PŘKPS předávat na DIS_IN subsystém (zachovat obdobný proces jako při zpracování e-podání přes PVS) posílit všechny komponenty IS. Zavedení e-podání výhradně přes systém ISDS povaţujeme za velmi problematický a bude mít dopad i na klienty vyuţívající dnes e-podání přes PVS. Klienti by museli obměnit svůj SW, prostřednictvím kterého zasílají e-podání ČSSZ. Tento SW podávající pořizují na své vlastní náklady. Tento program je ale vhodný pouze pro drobné podávající (pro jednotky zasílaných tiskopisů). Klienti budou hledat rychlou, pro ně nejjednodušší a nejlevnější náhradu, to nevylučuje zasílání tiskopisů ve formátech přípustných pro ISDS, ale nevhodných pro následné automatizované zpracování v IIS ČSSZ. Řešení se navrhuje následující: Připravit příjem e-podání přes ISDS. Zajistit legislativní podporu pro příjem určených dokumentů pouze formou e-podání přes ISDS. Vyţadovat zachování paralelního provozu systémů PVS a ISDS a při případném ukončování provozu PVS nechat minimálně roční přechodné období pro paralelní příjem e-podání oběma systémy, abychom veřejnosti poskytli dostatečný čas na přizpůsobení se nové situaci. Pro menší podávající připravit e-formuláře a komunikační program s funkčností zasílání e-podání přes ISDS. Marketingová kampaň za vyuţívání e-podání. Současný stav je tedy takový, ţe s datovými schránkami ČSSZ komunikuje: Prostřednictvím Internetu a individuálním přihlášením oprávněných osob k datovým schránkám. Prostřednictvím Internetového připojení aplikace DAS a této aplikace, která zajišťuje ošetření datových schránek. Prostřednictvím rozhraní DSS a subsystému DIS IN pro oblast e-podání s napojením na PŘKPS a subsystém elektronické spisové sluţby. První typ spojení se postupně převede na druhý typ propojení. Definitivně bude situace vyřešena v rámci Projektu integrovaného systému elektronické podatelny, elektronické výpravny a spisové sluţby prostřednictvím pořízení specializovaného software a hardware. Pokud se tato rozhraní osvědčí, můţe se jejich pouţívání stát trvalým řešením s tím, ţe princip e-podání přes ISDS Server můţe být kanálem pro strukturované informace a princip aplikace DAS pro nestrukturované datové zprávy. Czech Point Rozhraní Toto rozhraní dosud nebylo realizováno a bude realizováno v rámci projektu Rozhraní pro komunikaci s klienty ČSSZ. Zatím bylo uvaţováno s tímto rozhraním jako prostředkem pro autorizaci klientů pro komunikaci s ČSSZ, kdy je moţné vydat klientovi při osobní návštěvě po identifikaci s Občanským průkazem příslušné oprávnění pro komunikaci. Je také uvaţováno vyuţití pro vydávání odpovědi klientům. Rozhraní pro komunikaci Access Point Jde o značně komplikované rozhraní, které je koncipováno podle doporučeného řešení a je popsáno v části popisu Access Point řešení. 40

41 E-Podatelna/e-výpravna Toto rozhraní bude funkční jako v současné době do vyřešení Projektu integrovaného systému elektronické podatelny, elektronické výpravny a spisové sluţby prostřednictvím pořízení specializovaného software a hardware, kdy bude toto rozhraní do tohoto projektu integrováno. Vzdálený přístup zaměstnanců ČSSZ Toto rozhraní bude vytvořeno pro vzdálený přístup zaměstnanců ČSSZ ke svým aplikacím nejprve pro zaměstnance pracující v terénu a bude součástí řešení projektu 159. Shrnutí k problematice rozhraní V současné době je situace různorodá, rozhraní jsou řešena individuálně a situaci by měl vyřešit projekt Vytvoření informačního a komunikačního rozhraní České správy sociálního zabezpečení za účelem poskytování informací klientům. Součástí tohoto řešení bude integrace těchto rozhraní a jejich jednotné řešení a správa. Klientský portál bude zastřešovat tato rozhraní a plnit funkce, pro které je portálové řešení určeno DIS-subsystém jako základ subsystému IN (DIS_IN) pro zabezpečení vstupní oblasti IIS ČSSZ Je nutno rozlišovat dvě kategorie, a to DIS Server, který je rozhraním a DIS Subsystém, který je vybudován v ČSSZ nad rozhraním DIS Serveru a obsahuje aplikační nadstavbu ČSSZ nad DIS rozhraním pro zpracování e-podání. Vzhledem k tomu, ţe pojmenování DIS systém vzniklo jiţ na samém počátku napojení na PVS, je těţké jej dnes pojmenovávat jinak. Protoţe, jak se ukazuje dále je základem další nadstavbové funkcionality, je moţné jej chápat jako součást oblasti IN/OUT a proto dále o něm budeme pojednávat jako o DIS_IN subsystému. DIS systém byl původně koncipován jako bezpečné vstupní rozhraní pro příjem strukturovaných informací prostřednictvím PVS. V nynější době ČSSZ přes PVS přijímá následující typy e-podání: PRIHL Přihláška k nemocenskému a důchodovému pojištění zaměstnanců od roku ONZ oznámení o nástupu do zaměstnání od roku ELDP - sběr ročních evidenčních listů důchodového pojištění (za roky ) od prosince roku ELDP09 sběr ročních evidenčních listů důchodového pojištění po změně ZNP - od roku POS09 přehled o studiu (náhradních dobách pojištění z důvodu studia) od roku OSVČ pravidelný roční Přehled OSVČ podávaný po odevzdání daňového přiznání od roku RŢP a JRF výměna dat s MPO ČR, týkající se společného přihlašování ţivnostníků (OSVČ) od roku UserCert - Oznámení kvalifikovaného certifikátu - Hlášení změny kvalifikovaného certifikátu pověřeným pracovníkem - od července PVPOJ - Přehled o výši pojistného a vyplacených dávkách zaměstnavatelů od října EXI_DVK - Data pro exekutory dotazy a odpovědi na příjem pro potřeby členů Exekutorské komory od dubna NEM_PRI Příloha k ţádosti o dávku nemocenského pojištění od konce dubna ČSSZ připravuje nebo ještě plánuje jako nový typ e-podání - Data pro zdravotní pojišťovny dotazy a odpovědi pro zdravotní pojišťovny odhadovaná četnost 600 podání/měsíčně (od roku 2010) - denně je přenášeno podání, ve špičkách aţ podání denně. Jedno e-podání obsahuje data formulářů (průměrně 7 formulářů). V roce 2009 bylo přes PVS přijato téměř formulářů, z toho převáţný podíl tvoří formuláře ELDP (cca , coţ odpovídá 60% všech ELDP doručených na ČSSZ) a ONZ, resp. P/O (cca ). Dále jsou přes PVS doručovány Přehledy OSVČ (cca 600 formulářů v roce 2009), měsíční Přehledy o výši pojistného za zaměstnavatele (cca formulářů; příjem zahájen v říjnu 2009), Jednotný registrační formulář z MPO ČR (cca formulářů) a aktualizace Rejstříku ţivnostenského podnikání RŢP z MPO ČR (1 soubor kaţdý všední den) Řešení oblasti vstupu a ošetření informací projekt IN (DIS_IN) Je řešen jako systémové řešení přijetí podnětů a jejich ošetření a příprava na zpracování v aplikacích ČSSZ. 41

42 Konceptuální schéma oblasti IN Toto schéma je uvedeno na následujícím obrázku: Obrázek 15 - Koncepce řešení oblasti IN Hlavní koncepční doporučení oblasti IN je v maximálně moţné míře eliminovat příjem nestrukturovaných dat (například dopisů různými formami standardizovatelných ţádostí o změny/úpravy) pomocí formulářů, byť dobrovolných, které usnadní a zlevní jak zpracování v rámci ČSSZ, tak komunikaci klienta s ČSSZ. Architektura oblasti IN: Zavedení jednotného evidenčního čísla podání. Strategie sjednocení formálních, logických a kontextových kontrol pro celou oblast IN. Redesign dbzdv (optimalizace databázových struktur, verzování, rozšíření podpory metadat, příprava souvisejících metodik pro ukládání DV, podpora konceptu čistých dat). Koncept, který jiţ překročil oblast IN a stává se integračním konceptem pro celý IIS ČSSZ: Koncepce a implementace PŘKPS jako integrační platformy byla původně zvolena pouze pro oblast IN, ale tato koncepce se mění na integrační platformu pro celý IIS ČSSZ. Koncepce a implementace monitoringu pro sledování průběhu zpracování z pohledu uţivatele, provozovatele systému a správce dat rovněţ tento koncept bude realizován přes celý IIS ČSSZ. V této souvislosti poukazujeme na obrázky č. 5 nebo 10, které znázorňují architekturu IIS ČSSZ v současném období. Pozitivní přínos změny architektury oblasti IN se projeví pouze tehdy, budou-li výše uvedené prioritní oblasti řešeny společně. 42

43 DIS subsystém a jeho funkcionalita v současné době Klient (Zaměstnavatel OSVČ) MPO ČR Exekutorský úřad ISDS Vnější prostředí ELDP, POSTP ONZ /PRIHL OSVC_PRE PVPOJ Usrcert CD, disketa RŽP JRF EXI_DVK Odpověď EXI Klient PVS ELDP, ONZ /PRIHL DMZ DIS server SDS server Prezentační vrstva Referent Klient RŽP DISView RAUI Podatelna SDS RŽP RZP INP Nahrávání RZP AAS Správa podávajících SDS systém DS Aplikační a datová vrstva Mail systém pro odpovědi DB DIS Data Stavy DIS systém E-podání XML DV Posu nova č PŘK PS SPS Notifikace zápis do Malorg INP wsrkz ELDP, POSTP API DMS DMA PVPOJ Usrcert ONZ /PRIHL OSVC_PRE EXI_DVK SAP INP konto příjemce Odpověď EXI WS Notifikace POJ převzal ONZ/PRIHL pořízené klientem VZT BAM wszdv ZDV PVPOJ OSSZ BTS ONZ, PRIHL, OSVC_PRE Lokální INP DB Malorg OSVČ OSSZ Solaris DIS systém vnější systémy okolní systémy ČSSZ probíhá implementace napojení na DIS plánováno nová funkčnost POJ Obrázek 16 - DIS systém a jeho funkcionalita v současné době V současné době jde o homogenní aplikační nadstavbu nad DIS serverem v ČSSZ, které obsahuje funkcionalitu pro ošetření vstupujících formulářů. Bude základem řešení oblasti IN, která bude poskytovat sluţby na ošetření komunikace z jednotlivých rozhraní poté, co je vyvolá PŘKPS. Po provedení potřebných aplikací je datová věta předána do další oblasti zpracování a PŘKPS registruje změnu stavu. Dosavadní subsystém DIS_IN bude transformován podle zásad SOA architektury. Subsystém DIS - část pro strukturovaná data IIS ČSSZ ze subsystému PVS Data jsou přebírána z DIS rozhraní a dále zpracován funkcionalitou, která patří do oblasti IN. Ze schématu je patrné, ţe obsahuje důleţité procesy zabezpečení komunikace s oprávněnou osobou v systému RAUI. Oblast vlastního ošetření je velmi komplikovaná a vyţaduje transformaci. Subsystém DIS - část pro strukturovaná data IIS ČSSZ ze subsystému ISDS Po uvedení ISDS do provozu se jeví jako nevyhnutné, ţe část podání bude směrována do ČSSZ tímto kanálem. Přijímání strukturovaných datových zpráv prostřednictvím tohoto IS. Pro moţnost příjmu e- podání přes ISDS je nutné, aby ČSSZ definovala poţadované formáty příloh a komunikační protokol, tzn. jak se bude párovat odpověď na e-podání. Dále je nutno zajistit odlišení e-podání od zpráv určených pro ruční zpracování. Pro přenos bude pouţit formát XML, který z moţných formátů nabízí nejlepší moţnosti automatizovaného zpracování. Bude umoţněn příjem dvou formátů XML: GovTalk s nepovinným šifrováním a povinným elektronickým podpisem a holé XML bez podpisu a šifrování. Pro e-podání je navrţeno zřízení samostatné datové schránky ČSSZ na které navazuje rozhraní ISDS Server. To umoţní efektivně oddělit e-podání od ostatních zpráv: snadno vysvětlíme klientům, nebude nutné implementovat sloţitý a ne zcela spolehlivý automat na vytřídění zpráv s e-podáním od zpráv s přílohami v jiných formátech (zpráv s písemnostmi). Uváţena byla varianta třídění podle některé poloţky obecných informací datové zprávy (např. Věc:, K rukám: apod.) Vzhledem k tomu, ţe MV ČR nevydalo ţádné doporučení, jak by jednotlivé poloţky měly 43

44 být vyuţívány, panuje v této oblasti velká volnost a proto by bylo problematické přimět podávající k dodrţování stanoveného pravidla. Důsledkem by byla nemoţnost spolehlivě automaticky oddělit zprávy s e- podáním od ostatních a nutnost ručního dotřiďování. V jedné datové zprávě je navrţeno v případě e-podání přijímat právě jedno e-podání (Toto e-podání můţe mít u vybraných typů jako dnes více (aţ 1500) formulářů, zpráva můţe mít velikost max.10mb). Změny v IIS ČSSZ nutné pro zahájení příjmu a zpracování e-podání z ISDS - pro zabezpečení příjmu e-podání z ISDS je plánováno, tam, kde je to moţné, vyuţít a přizpůsobit stávající systémy. Jedná se především o systém DIS a PŘKPS. Pro komunikaci s ISDS a zajištění bezpečného prostupu do aplikační vrstvy (tj. mezi Internetem a vnitřní sítí ČSSZ) je třeba vybudovat nový modul SDS-server (server systému datových schránek). Jde o obdobu komponenty DIS serveru pro komunikaci s PVS. (Napojení se dotkne i dalších subsystémů ČSSZ: DMS, ZDV.) DIS subsystém a jeho transfomace na DIS_IN subsystém Subsystém DIS - část pro zpracování dotazů exekutorů Navrţené řešení vyuţití DIS_IN rozhraní pro zpracování dotazů exekutorů je prvním krokem k přestavbě subsystému DIS na DIS_IN subsystém. Tato trasa je vyznačena ţlutě a byla uvedena do provozu v současné době a vyuţívá funkcionality DIS_IN nadstavby pro zabezpečení této funkcionality. Jak jiţ bylo uvedeno, za základ řešení oblasti IN bude vzat DIS systém v následující podobě. V této oblasti je nutno realizovat příslušné změny, zejména konsolidaci datových oblastí, kam se ukládají data tj. dále prohloubit řešení podle konceptu oblasti IN. Komunikační kanály VREP server (část subsystému DIS) DIS server (část DIS subsystém) DSS server (část subsystému DS) Vrstva řízení přístupů AAA Prezentační vrstva Subsystém IN Elektronická podatelna INNP DIS View DMS podatelna DMS klienti ZDD VZT klient Podatelna SPS?... PŘKPS posunovač Vyhledávání a reporty Procesní aplikační podpora POJ VZT DMS app Aplikační vrstva SPS KL OCR SDP DIS systém Raui/AAS? SDS VREP Služby pro e-podání NEMWF POJINT IPKWF Události INS? NEM VZTWF INS DIS Stavová DB. Datová vrstva INP OA ZDV KL Monitorovací DB DMS (DMA) Plánováno? Vize Obrázek 17 - Architektura oblasti DIS_IN pro nejbližší období (vize) Nejedná se o cílové řešení, ale o další krok v realizaci nového konceptu této oblasti v rámci současných moţností. Pro tuto vizi je charakteristické přeorganizování stávajících aplikací, konsolidace datové oblasti, aniţ by bylo nutno zasahovat do aplikací. Nové uspořádání je zaloţeno na skutečnosti, ţe: 44

45 Ústřední roli hraje platforma pro řízení a kontrolu procesů PŘKPS, která v současné době spolupracuje pouze s některými aplikacemi, kde se postupně implementují řídící procesy sledující průběh zpracování. Opírá se o dvě databáze - stavovou a monitorovací. Aplikace jsou rozděleny do skupiny aplikací, které pokrývají procesy IN v zeleně orámované oblasti, které by se v budoucnu měly transformovat na sluţby IN. Jsou rozděleny na prezentační a aplikační vrstvy. V datové vrstvě jsou umístěny databáze oblasti IN s tím, ţe databáze DIS a KL zaniknou. Navrţené řešení zjednodušuje oblast IN a připravuje ji pro další stupeň modifikace do cílového řešení. Je otevřené pro doplňování o další sluţby a procesy v návaznosti na jejich implementaci Řešení oblasti OUT Systém dosud nezařazen do projektů ČSSZ s tím, ţe v rámci projektu Vytvoření informačního a komunikačního rozhraní České správy sociálního zabezpečení by měl být řešen za účelem poskytování informací klientům a bude zabezpečeno i výstupní rozhraní pro oblast OUT. Řešení oblasti OUT vyţaduje zpracovat obdobnou analýzu jako byla realizována pro oblast IN. Vyţaduje definovat Rozhraní mezi aplikační oblastí a oblastí OUT. Rozhraní mezi aplikacemi a expedicí datových zpráv prostřednictvím datových schránek. Rozhraní mezi aplikacemi a expedicí prostřednictvím spisové sluţby. Rozhraní mezi aplikacemi a tiskovým střediskem integrace stávajících procesů Projekt el. podatelny, výpravny a spisové služby - subsystém 1.1 a 7.2 V návaznosti na legislativní změny je v ČSSZ plánován další projekt s cílem získat dotaci ze strukturálních fondů EU, a to Projekt integrovaného systému elektronické podatelny, elektronické výpravny a spisové sluţby prostřednictvím pořízení specializovaného software a hardware. Realizace tohoto projektu umoţní ČSSZ dostát legislativním poţadavkům souvisejícím s přijetím zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů a s novelizací zákona č. 499/2004 Sb., o archivnictví a spisové sluţbě. Kromě tohoto hlavního cíle má realizace projektu zajistit integraci nového systému datových schránek s jiţ existujícím systémem pro správu dokumentů DMS, který slouţí na ČSSZ pro archivaci dokumentů v elektronické podobě. Nový systém musí být začleněn do stávajícího technologického prostředí provozovaného na síti ČSSZ. Hlavním cílem navrhovaného řešení je vyřešení evidence, zpracování a uchování elektronických dokumentů došlých a odesílaných systémem datových schránek. Kromě toho umoţní elektronická spisová sluţba i evidenci a zpracování listinných dokumentů a dokumentů přijatých em. Sjednocení práce s dokumenty přicházejících do ČSSZ různými komunikačními kanály (datové schránky, listinná podání, e- mail) a automatizace těchto prací povede postupně k celkovému sníţení nákladů na tuto činnost. Hlavním úkolem projektovaného systému je zajistit bezpečnou komunikaci s ISDS, zejména příjem a odesílání datových zpráv, jejich evidenci, zpracování a archivaci. Kromě toho bude elektronická spisová sluţba umoţňovat také evidenci a zpracování listinných dokumentů a elektronických dokumentů přijatých e- mailem. Navrhovaný systém sjednotí práci s různými druhy dokumentů přicházejících do ČSSZ rozdílnými komunikačními kanály (ISDS, listinná podání, ). Projektovaný systém bude také vyuţívat stávající informační systémy ČSSZ, z nichţ se zejména předpokládá: Poštovní servery pro příjem a odesílání datových zpráv em, ová elektronická podatelna a výpravna bude vyuţívat stávající infrastruktury; DMS/DMA vlastní elektronický obsah digitálních dokumentů bude ukládán do stávajícího datového úloţiště, resp. části vyhrazené pro zaručený elektronický archiv (ZEA). ES spolupráce se subsystémem elektronického spisu. KE kmenové evidence budou vyuţívány jako zdroj kontaktních údajů na subjekty, se kterými správa komunikuje. PŘKPS platforma pro řízení a kontrolu procesů a sluţeb bude se subsystémem spolupracovat a synchronizovat vyřizování podnětů, které budou tvořit nestrukturované podněty. AAA portál správa uţivatelů a rolí, autentifikace a autorizace. DIS_IN Subsystém, který bude poskytovat sluţby k ošetření vstupních podnětů. Nová architektura systému bude navrţena tak, aby v maximální moţné míře byly vyuţity stávající aplikační systémy i zachovány stávající postupy zpracování elektronických dokumentů včetně moţnosti postupného přechodu na plánovaný cílový stav. 45

46 DIS Systém E mail Česká pošta Elektronická Spisová Služba DSS Server E mail Česká pošta Elektronická Spisová Služba Archiv tiskových výstupů (CMoD) Navrhované řešení přidává ke stávajícím provozovaným aplikacím následující nové komponenty: Systém elektronické spisové sluţby (ESS) umoţňuje jednotnou evidenci příjmu i odeslání dokumentů v elektronické i listinné podobě a jejich uloţení v systému DMS. Dále zajišťuje příjem i odesílání elektronických dokumentů (mimo vybrané elektronické formuláře) prostřednictvím systému datových schránek i elektronické pošty a moţnost sledování interní výměny dokumentů mezi územními pracovišti ČSSZ. Podatelna a výpravna datových schránek zajišťuje komunikaci ESS se systémem datových schránek a obsahuje funkce elektronické podatelny (vyhláška č. 496/2004 Sb., o elektronických podatelnách) mimo funkcí které budou implementovány prostřednictvím komunikační platformy. E-podatelna a e-výpravna (elektronická podání zasílaná em) zavedení systému automatického zpracování elektronických podání bez nutnosti tisku dokumentů a jeho napojení na systém ESS. Subsystém bude řešen jako striktně centralizovaná aplikace. To znamená, ţe ESS a její související moduly budou provozovány v centrále pro všechna územní pracoviště (včetně ústředí). Uţivatelé budou k aplikaci ESS přistupovat po síti intranet prostřednictvím tenkého klienta zaloţeného na www technologii. Aplikace ESS, podatelna / výpravna DS a e-podatelna / výpravna, budou logicky rozděleny tak, aby kaţdé územní pracoviště mělo svou samostatnou spisovou sluţbu se společnou centrální databází). Takto koncipovaná architektura systému je znázorněna na následujícím obrázku. Osobní podání Papírové podání Pracovníci podatelny Papírové vypravení e-podatelna e-výpravna Referenti Odborné aplikace Komunikační platforma + cache podatelna DS výpravna DS Osobní podání Papírové podání Instance Ústředí interní výměna dokumentů Pracovníci podatelny KE ATN Papírové vypravení e-podatelna e-výpravna Referenti DMS (CM) podatelna DS výpravna DS Instance ÚP 1 Instance ÚP 2.. Instance ÚP XX Obrázek 18 - Celková architektura subsystému elektronické spisové služby Základní vlastností systému ESS je automatizace příjmu podání (elektronického nebo listinného), jeho evidence a další oběh za účelem konečného zpracování v rámci územní jednotky. Samozřejmě také musí zajistit, evidenci a výměnu dokumentů i mezi jednotlivými územními pracovišti. Tato funkcionalita je nezbytná například pro předání podání, které bylo odesilatelem chybně adresováno jinému pracovišti, nebo předávání spisů při změně bydliště klienta. Výměna dokumentů v listinné podobě bude probíhat mezi pracovišti stávajícím způsobem aţ na to, ţe ESS zajistí jejich evidenci jak na pracovišti odesílatele, tak na pracovišti příjemce. Systém elektronické spisové služby ESS bude umístěn v aplikační a datové vrstvě sítě. ESS bude vyuţívat vlastního datového úloţiště (relační databáze) pro evidenci dokumentů, spisů a řízení jejich zpracování. 46

47 Rozpracované (neuzavřené) elektronické dokumenty bude ESS ukládat ve svém operativním úloţišti. Uzavřené elektronické dokumenty budou ukládány (prostřednictvím stávajícího API rozhraní) do DMS. V DMS budou uloţeny stejným způsobem a se stejnými metadaty jako stávající dokumenty evidované přes klienta Evidence podání DMS. Subsystém bude navázán i na subsystém elektronického spisu (ES) Dokumenty uloţené v DMS ze spisové sluţby tak budou dostupné nejen přes spisovou sluţbu, ale také ze stávajících klientů DMS (Aktivní klient a Univerzální klient). Uţivatelské rozhraní ESS bude přístupné podstatné části uţivatelů IS ČSSZ. Pro správu uţivatelů a jejich autentikaci a autorizaci musí být vyuţito stávající řešení - AAA Portál. Uţivatelé budou z AAA Portálu importováni a synchronizováni do ESS. Z výše uvedeného také vyplývá potřeba posílení datového úloţiště, aplikačních serverů a nákup potřebných licencí Zajištění elektronické výměny dat mezi státy EU v současnosti V návaznosti na rozvoj IIS ČSSZ je připravováno zavedení elektronické výměny dat mezi státy EU/EHP na základě nařízení Rady a Evropského parlamentu č. 883/2004 a jeho prováděcího nařízení v rámci Evropské komise (EK) i ČR. Nová nařízení stanoví, ţe základním prostředkem komunikace mezi členskými státy a jejich institucemi budou elektronické komunikační prostředky a rovněţ popisují základní organizačně/legislativní parametry. ČSSZ provedla analýzu toku dat a na základě tohoto rozboru plánuje pro oblasti důchody, peněţité dávky v nemoci a mateřství a příslušnost k právním předpisům, vybudovat jeden přístupový bod, který bude komunikovat s mezinárodním centrálním uzlem EESSI a v rámci ČR s přístupovými body ostatních institucí (CMÚ a MPSV). Je prováděna analýza dat obsaţených ve strukturovaných elektronických dokumentech (SED), které jsou předmětem mezinárodní výměny dat. Byl prozkoumán charakter a druhy dat, které odpovídají novému nařízení. Bylo zjištěno, ţe některými poţadovanými daty ČSSZ nedisponuje. V současné době probíhá mapování zdrojů (pojišťovny, ministerstva), ze kterých by bylo moţné získat ta data, která nemá ČSSZ v současné době k dispozici. ČSSZ odevzdala komisi projektu EESSI první návrh údajů o svém AP pro Master Directory (dále MD), coţ je adresářová sluţba, která bude provozována jako jedna z klíčových sluţeb v rámci projektu EESSI. Bez této sluţby by nebylo moţné jednoznačně identifikovat instituce a zaručit tak bezchybné doručování strukturovaných zpráv SED. V současné době je připravována úprava databází a stávajících aplikací (VPO1 pro určování příslušnosti k právním předpisům podle ustanovení nových nařízení včetně pokrytí přechodného období). Probíhají přípravné práce pro vybudování přístupového bodu ČSSZ a napojení se na mezinárodní část systému EESSI. Pro fázi testování bylo nutno zajistit přístup ČSSZ do sítě stesta, ve které bude probíhat mezinárodní elektronická výměna dat. Současně je připravován projekt vybudování přístupového místa ČSSZ Vybudování Access Points přístupových míst ČR do Evropské architektury Projekt EESSI bude předmětem řešení projektu plánovaného v rámci financování z prostředků ze strukturálních fondů pod označením Projekt Vybudování Access Points přístupových míst ČR do Evropské architektury pro výměnu standardizovaných zpráv v oblasti sociálního zabezpečení migrujících osob který bude zabezpečován ve spolupráci s MPSV. Access Point je přístupovým místem do systému EESSI, který zabezpečuje elektronickou výměnu dat mezi jednotlivými členskými státy v rámci oblastí sociálního zabezpečení. AP funguje jako brána do speciální sítě stesta, která je určena pro veškerou komunikaci EESSI mezi Institucemi v rámci EU a i uvnitř členských zemí. Celá řada institucí na národní úrovni se připojuje k AP za účelem integrace do celkové infrastruktury EESSI. AP nejsou přímo vzájemně propojeny přenášejí všechny právy prostřednictvím CN. Konceptuální schéma řešení EESSI je znázorněno na následujícím obrázku. 47

48 Obrázek 19 Konceptuální schéma EESSI Studie EESSI definuje základní úkoly jednotlivých členských států, které je potřeba zajistit při tvorbě EESSI. Kaţdý členský stát je při budování svých AP zodpovědný za následující úkoly: pravidelně poskytovat zpětnou vazbu a schvalovat záleţitosti vyţadující schválení členských zemí, s relevantními institucemi připravovat implementaci EESSI na národních doménách a následně zajistit implementaci propojení relevantních institucí s jednotlivými AP, implementace AP - zajistit potřebnou IT infrastrukturu, zajistit potřebné experty z oblastí sociálního zabezpečení a oblasti IT, vytvořit a následně provozovat vhodný počet AP, coţ zahrnuje zejména výměny dat z oblasti sociálního zabezpečení mezi kompetentními institucemi a dále rozvíjet funkčnost AP dle rozvoje systému EESSI. Základním funkčním prvkem výměny elektronických dat v rámci EESSI je vyuţití strukturovaných elektronických dokumentů SED (Structured electronic document). SED jakoţto elektronický dokument s předdefinovanou strukturou hraje v rámci fungování EESSI stěţejní roli. SEDy budou nahrazovat v současnosti pouţívané papírové E-formuláře. Výměna jednotlivých SED probíhá na základě operačních předpisů, které definují jejich standardy pro výměnu dat mezi jednotlivými kompetentními institucemi a AP. Tyto předpisy definují následující aspekty: způsob, jakým kompetentní instituce iniciuje odeslání konkrétního SED adresátovi, procesní kroky AP při přenosu SED, způsob, jakým AP předává porušený nebo nesprávně formátovaný SED, způsob, ukončení operačního procesu přenosu daného SED. Důleţitou a zároveň základní částí systému EESSI je zevrubná definice formátu jednotlivých SED a jejich operační předpis. Studie EESSI jednoznačně preferuje tvorbu jednotlivých SED ve formátu XML, coţ není povinností, avšak veškeré SED v jiném formátu budou v budoucnu postupně stahovány a nahrazovány formátem XML. AP se skládá z mezinárodní (IPAP International Part of Access Point) a národní části (NPAP National Part of Access Point). Z důvodu snahy zjednodušení napojení jednotlivých AP do systému EESSI byl navrţen společný jednotný způsob připojení mezinárodní části (IPAP) do EESSI pomocí tzv. referenční implementace (dále jen RI). V případě projektu Vybudování Access Point bude vyuţito RI. Evropská komise zajišťuje v rámci RI veškerý vývoj, údrţbu a podporu. Pro jednotlivé členské státy RI představuje tzv. out-of-the-box implementaci mezinárodní části AP. RI tvoří následující základní rysy: podporované formáty SED SED ve formátu XML je povaţován jako výchozí formát EESSI, který je vhodné dodrţet, sluţby Access point - konverze elektronických dokumentů, adresáře, předávání zpráv, monitoring a záznam předávaných elektronických dat,bezpečnost. další sluţby - předávání elektronických informací včetně zásahu člověka tzv. Intelligent routing with Human intervention (není povinné), 48

49 rozhraní na národní část AP - systém souborů,databáze (RDBMS),webové sluţby,java Messaging Service JMS,Enterprise Java Beans EJB, rozhraní na národní on-line systémy - webové sluţby,java Messaging Service JMS,Enterprise Java Beans EJB atd Charakteristika Access Points ČSSZ Technické řešení AP ČSSZ AP ČSSZ vychází z následujících předpokladů: Pro vybudování AP ČSSZ bude vyuţita Referenční implementace apod. AP ČSSZ bude vytvořen tak, aby mohl v budoucnu slouţit také k připojení dalších kompetentních institucí CI. Národní část AP NPAP bude vytvořena tak, aby mohla předávat formuláře nejen formuláře SED, ale i další strukturované národní formuláře) jiným CI v ČR AP ČSSZ bude odolné proti výpadkům a snadno rozšiřitelné. Řešení se skládá ze dvou základních částí: AP IPAP NPAP AP je nezávislý na ČSSZ jako CI a umoţňuje připojení další CI. AP tedy provádí pouze formální zpracování SED. ČSSZ IN ČSSZ IN veškerá logika EESSI, která je specifická pouze pro ČSSZ, vyplňování dat do SED nebo zápis dat z SED apod., je umístěna v ČSSZ IN. IPAP je část AP, která bude přejata z RI a bude pouze konfigurována. Procesy v IPAP sem spadá např. šifrování/dešifrování SED, el.podpis SED, odeslání a příjem SED do/z CN apod. MTA Message Transfer Agent odpovídá za odesílání a příjem SED NPAP je část AP, která bude převzata pouze částečně a bude značně přepracována a značně přizpůsobena. ČSSZ IN Všechny procesy EESSI specifické pro ČSSZ budou zpracovávány v ČSSZ IN. Zde bude probíhat neformální validace SED, vyplňování SED, kontrola dat v SED, archivace atd. 49

50 ČSSZ VSTUPNĚ- VÝSTUPNÍ KANÁLY Access management ČSSZ IN/OUT Vnější služby fronty workflow fronty Webic www rozhraní I A M AAA DB CERTIFIKÁTY SPISOVÁ SLUŽBA DMS PLATFORMA AGENDY VPO Archivace NPD NEM POJ VYP Obrázek 20 - Schéma integrace EESSI s ČSSZ IN Aplikační část bude v ČSSZ nově vytvářena patří sem komunikace s AP, kontrola na vstupu Access Management, dále sem spadá tvorba vstupně-výstupních front a vnějších sluţeb. DMS a spisová sluţba registrace a archivace SED v ČSSZ. Webic webové rozhraní, přes které budou přistupovat zaměstnanci ČSSZ k EESSI. Jako základ bude pouţit Webic, který bude ale přizpůsoben a doprogramován na webové rozhraní pro přístup k EESSI a SED. Workflow workflow je proces, který odpovídá za zpracování SED za ţivotní cyklus SED. Tak jako na AP se stará workflow o formální procesy spojené se SED, v ČSSZ IN se workflow bude starat o neformální procesy zpracování SED. Patří sem určení metod volaných při automatickém zpracování, zápis do/z SED. Notifikace zaměstnanců odpovědných za data nebo validaci SED, finalizace SED atd. Automatické zpracování SED část umoţňující postupně co největší mnoţství dat předávat z/do SED. Základem je WebServices rozhraní a nadefinování metod nad aplikací VPO. Procesní architektura AP ČSSZ se navrhuje jako integrované řešení, které je tvořeno dílčími subsystémy zajišťujícími funkčnost výměny informací (předávání zpráv a odpovědí na ně) na mezinárodní úrovni (IPAP - International Part of Access Point) a na národní úrovni (NPAP National Part of Access Point). Funkčnost pro výměnu zpráv na mezinárodní úrovni zajišťuje Referenční implementace (RI), kterou vytváří dodavatel na úrovni EESSI. RI bude dodána jako kompletní SW vybavení AP, které bude potřeba instalovat a customizovat dle konkrétních podmínek AP ČSSZ. RI bude podporovat základní procesy potřebné pro výměnu zpráv mezi AP ČSSZ a zahraničními institucemi. Dílčí subsystém NPAP je z hlediska dodavatele RI volitelnou součástí konkrétního národního Access Pointu a potřeba NPAP závisí na rozhodnutí konkrétního Access Pointu. 50

51 V případě AP ČSSZ je NPAP nezbytným subsystémem, neboť podporuje ty procesy potřebné pro vytvoření zprávy určené pro odeslání do zahraničí nebo vytvoření odpovědi na zprávu přijatou ze zahraničí, které v rámci České republiky vyţadují součinnost dalších subjektů (kromě ČSSZ). Komponenty RI tedy poskytují všechny důleţité funkcionality nezbytné pro výměnu zpráv na mezinárodní úrovni a pro integraci RI s národní částí AP, tj.: Rozhraní na NPAP, Web aplikace, Přístup na adresářové sluţby, Messaging (EMS), Defaultní směrování a transformace zpráv konfigurovatelná pomocí šablon (EMD), Základní sada adaptérů konfigurovatelných pomocí šablon, Monitoring, logování a statistiky pro administrátory AP (MLS), Repository informací. Z hlediska dodavatele RI byly pro část EMD, tj. z pohledu AP ČSSZ subsystém NPAP, definovány následující minimální funkčnosti, které bude poskytovat RI: Routing (směrování), Conversion (základní konverze), Custom functions (základní přizpůsobení defaultních funkcí dodaných v rámci RI). Z poţadavků na podporu procesů národní části AP ČSSZ vyplývá, ţe standardně poskytované funkcionality RI nebudou pro potřeby řešení dostačující a bude potřebné vyvinout specifické komponenty NPAP integrované do EMD. Součástí RI bude také aplikace WEBIC, tj. web aplikace pro administraci a prohlíţení zpráv zpracovávaných v RI. Předpokládáme, ţe toto rozhraní bude určeno pro práci administrátora AP ČSSZ, nepovaţujeme za vhodné vyuţít toto rozhraní pro přístup koncových uţivatelů. Pro potřeby koncových uţivatelů v národní síti se doporučuje vytvořit samostatnou web aplikaci v NPAP, a to dle specifických potřeb uţivatelů a procesů národní části. V AP ČSSZ bude standardní referenční implementace v NPAP doplněna o části, které umoţňují: zasílání strukturovaných zpráv mezi CI v ČR, jiných neţ EESSI SED, kompletaci SED, které vyţadují doplnění dat jinou CI např. MPSV nebo CMÚ. Pokud bude moţné pro tyto činnosti vyuţít sluţby EMS, budou vyuţity. Datová architektura Datové entity jsou rozděleny do následujících skupin: Inicializační data. Registry a číselníky. Parametry procesu. Inicializační data musí být připravena před zahájením provozu systému. Aplikační data. Metadata o komunikaci. Vlastní obsah SED. Aplikační data vznikají provozováním systému. Provozní parametry pilotního a ostrého provozu Specifikace poţadavků na RI Z dodaných podkladů EESSI vyplývají následující poţadavky dodavatele RI na technické a technologické prostředí pro RI: Redhat Enterprise Linux bit, Sun Java 5/6, JBoss Application Server 5.1, JBoss Enterprise Service Bus 4.6, PostgreSQL database for Linux 8.3, Open LDAP Directory Services

52 stesta AP ČSSZ Ostatní české AP (národní komunikace) Firewall AP EMS EMD WEBIC Jiné organizace výužívající týž AP Adresářový server Lokání databáze Information Repository MLS Console Extranet Firewall ČSSZ Oblast IN Vrstva Acccess Managementu ČSSZ Vnitřní síť ČSSZ Aplikační vrstva PROCESY FRONTY Zaměstnanci ČSSZ SPISOVÁ SLUŽBA DMS AGENDY VPO NPD NEM POJ VYP Databázová vrstva Obrázek 21 - Vazby AP ČSSZ a vnitřní sítě ČSSZ Základní popis hlavních procesů a toků dat v AP ČSSZ Základní procesy předávání a zpracování SEDů z hlediska stanovení poţadavků na funkcionalitu softwarové aplikace NPAP AP ČSSZ obsahují konkrétní scénáře komunikace popisující zasílání jednotlivých typů SEDů v různých situacích vyţadujících komunikaci mezi AP ČSSZ a spolupracujícími subjekty na národní úrovni budou předmětem analýzy dodané řešitelem NPAP ČSSZ. Před tvorbou vlastních adaptérů budou vţdy nejdříve prověřeny ty, které poskytuje RI, pokud bude jejich funkčnost vyhovovat, budou pouţity. Procesy AP ČSSZ jsou typově rozděleny na: Zaslání SED české CI (ČSSZ) asynchronní zpracování. Zaslání SED zahraniční CI - asynchronní zpracování. Zaslání SED české CI (ČSSZ) synchronní zpracování. Zaslání SED zahraniční CI - synchronní zpracování. Komunikace mezi institucemi ČR (ČSSZ, ČSSZ, MPSV) Předávání informací mezi institucemi v ČR (CMU, ČSSZ, MPSV) Předávání informací mezi institucemi je analogií předchozího. Obě CI ČR budou mezi sebou komunikovat ve formě strukturovaných dokumentů. NPAP pak umoţní výměnu těchto dokumentů. Řešení nestandardních stavů formální a neformální validace SED. Řešení nestandardních stavů bude součástí projektu. Popis poţadavků na funkčnost a další podstatné vlastnosti řešení. Základní poţadavky na AP ČSSZ - AP ČSSZ bude umístěn mimo síť ČSSZ, coţ je nutná podmínka toho, aby mohly AP ČSSZ v budoucnosti vyuţívat i jiné CI jako svůj AP. Připojení AP ČSSZ na ostatní AP v ČR Tento poţadavek vychází z rozdělení evropsky vnímaného sektoru dávek v nemoci a mateřství v ČR na dvě části na oblast nemocenského a zdravotního pojištění a tím i na minimálně dva styčné orgány, ČSSZ a CMÚ. Z hlediska AP ČSSZ bude ČSSZ kompetentní institucí, MPSV a CMÚ budou institucemi spolupracujícími na národní úrovni. 52

53 CN AP CMÚ AP ČSSZ stesta AP MPSV fw IPAP IPAP IPAP NPAP F w NPAP F w NPAP stesta fw stesta stesta Portál ČSSZ Access Management AAA Data ČSSZ Obrázek 22 - Vztah AP ČSSZ a ostatních AP v ČR Z hlediska věcného obsahu se předpokládá, ţe v SED přijatých ze zahraničí a odesílaných do zahraničí prostřednictvím AP ČSSZ budou zdrojem informací i jiné instituce, neţ ČSSZ viz výše uvedený obrázek. Postup zpracování těchto typů SED a z něj plynoucí poţadavky na funkčnost AP ČSSZ je součástí analýzy Směrování SED v ČSSZ Směrování SED v ČSSZ bude podrobeno velmi pečlivé analýze. Na přesnosti směrování bude záviset ubývání ruční práce při vyřizování SED. SED bude vstupovat do ČSSZ přes spisovou sluţbu a DMS, kde bude, jako kaţdý formulář, registrován a dostane interní číslo. Dále bude podle typu SED vyvoláno workflow, které bude řešit kompletaci SED. Detaily směrování SED v rámci workflow budou vyčítány z hlavičky SED. Základní směrování SED bude určeno v Analýze. Proces směrování se během provozu bude postupně upřesňovat. Adresářové funkce AP ČSSZ bude mít dvě adresářové sluţby: DS_RI adresářová sluţba bude nastavena jako read-only a její obsah bude replikován z DS_CN. Obsah DS_RI bude zdrojem informací pro směrování v EESSI, certifikátů jednotlivých AP a dalších objektů, vzorů SED apod. AP ČSSZ tato data přejímá, ale nemůţe je měnit, mazat nebo doplňovat DS_CI adresářová sluţba specifická pro AP ČSSZ. Bude nastavena na read-write a bude obsahovat informace pro národní směrování, certifikátů CI ČR, vzorů národních formulářů. AP ČSSZ tato data spravuje, můţe je měnit, mazat nebo doplňovat Archivace dat a dokumentů Přístupový bod bude uchovávat záznamy o výměně dokumentů sociálního zabezpečení (např. SED, jiné elektronické soubory) spolu s kompetentními institucemi, kterým slouţí. Bude uchovávat záznamy o transakcích, datový obsah dokumentů výhradně v šifrované podobě. Na základě těchto záznamů vytvoří rovněţ statistické výkazy o výměně SED. 53

54 Zpracování dat pro statistické účely Na základě záznamů o výměně SED poskytne AP ČSSZ data pro vytvoření statistických výkazů. Pouţit bude nástroj Monitoring, Logging & Statistics (MLS). Patří sem nástroje pro monitoring AP, logování a všechny aktivity pro sběr statistických dat. Údrţba a konfigurace je povinností stanoveného správce AP. Zajištění bezpečnosti Bezpečnost je popsána v části Zabezpečení přístupu a dat. Monitorování Veškeré transakce výměny informací budou protokolovány pro budoucí vyuţití. Pouţit bude nástroj Monitoring, Logging & Statistics (MLS). Patří sem nástroje pro monitoring AP, logování a všechny aktivity pro sběr statistických dat. Údrţba a konfigurace je povinností stanoveného správce AP. Podpora workflow AP ČSSZ bude v NPAP části obsahovat workflow, které bude sledovat stav jednotlivých SED a bude SED finalizovat. V případě, ţe je nutné pro finalizaci SED doplnit data ještě od jiné CI, postará se workflow o zaslání SED NPAP jiné CI, příjem doplněné SED, její kompletaci a odeslání IPAP. Kromě workflow, které je součástí NPAP existuje také workflow v ČSSZ, které má za úkol doplnit SED daty a validovat. Toto workflow bude však součástí interních procesů a sluţeb v ČSSZ a není jiţ součástí AP ČSSZ. Požadavky na rozhraní s externími systémy Tato kapitola definuje poţadavky na okolní systémy, které musí vytvořit rozhraní s NPAP ČSSZ. Za tímto účelem bude v AP ČSSZ DS_CI udrţovány certifikáty ostatních CI ČR (např. CMÚ a MPSV). AP CMÚ CMÚ - zasílání SED - AP ČSSZ umoţní zasílat SED do AP CMÚ (včetně národních), které vyřizuje CMÚ v roli kompetentní nebo spolupracující instituce. CMÚ - příjem SED - AP ČSSZ umoţní přijímat SED z AP CMÚ (včetně národních), které vyřizuje CMÚ v roli kompetentní nebo spolupracující instituce. AP MPSV MPSV - zasílání SED - AP ČSSZ umoţní zasílat SED do AP MPSV (včetně národních), které vyřizuje MPSV v roli kompetentní nebo spolupracující instituce. MPSV - příjem SED - AP ČSSZ umoţní přijímat SED z AP MPSV (včetně národních), které vyřizuje MPSV v roli kompetentní nebo spolupracující instituce. Požadavky na rozhraní s interními systémy NPAP ČSSZ (RI) - NPAP ČSSZ bude komunikovat s kompetentními institucemi ČSSZ, případně v budoucnu s dalšími CI. Komunikace bude probíhat šifrovaně (tunel). NPAP ČSSZ bude komunikovat s NPAP částí dalších AP v ČR. Komunikace bude probíhat šifrovaně (tunel). Interní systémy ČSSZ zapojené do komunikace prostřednictvím AP ČSSZ 54

55 Interní systémy ČSSZ zapojené do komunikace prostřednictvím Access pointu ČSSZ Centrální registry Kmenové evidence VZT Důchodová oblast Nemocenské pojištění Výběr pojistného MainFrame NEM POJ EDS ZDD EXK DNP LPS EPN VPO W E B S E R V I C E S NPD Výplaty důchodových dávek VYP Výplaty nemocenských dávek INS Obrázek 23 - Interní systémy ČSSZ zapojené do komunikace prostřednictvím Access pointu ČSSZ Výše uvedené schéma zatím neobsahuje vazbu na platformu PŘKPS, která v rámci projektového řešení bude do této struktury zakomponována jako je tomu u oblasti IN, bude dořešena i role VPO. Pro výměnu dat EESSI budou vyuţívána centralizovaná data systémů ČSSZ. V roce 2009 došlo k centralizaci většiny agend nemocenského pojištění a výběru pojistného. V oblasti důchodové agendy bude moţno prostřednictvím systému EDS (Elektronický dávkový spis) poskytovat data současného systému MainFrame, kde se v současnosti nachází veškerá data o přiznaných důchodových dávkách. Agendou integrující data poţadovaná pro výměnu mezi dalšími evropskými subjekty sociálního zabezpečení bude systém VPO Volný pohyb osob. Základní informace které lze automatizovaně z IS ČSSZ získávat jsou: informace o pobíraných důchodových dávkách (EDS), informace o podaných ţádostech o důchodovou dávku (ZDD), informace o exekucích a konkursech důchodců (EXK), informace nárokových podkladů důchodových doby a výdělky (NPD), informace o vyplácených důchodových dávkách a vyplácených dávkách nemocenského pojištění (VYP), informace o přiznaných dávkách nemocenského pojištění (NEM), informace Lékařské posudkové sluţby (NEM), informace o pojistných vztazích (VZT), informace ČSSZ o přihláškách subjektů do insolvenčních řízeních a návrzích na insolvenční řízení (INS), informace o úhradách pojistného fyzickými osobami (POJ), kontaktní a jmenné informace (KE), další poţadované informace na základě analýzy projektu realizace AP ČSSZ. Subjekty budou ověřovány vůči systému centrálních registrů (KE), kdy bude zajištěna jednoznačná identifikace subjektů v systémech ČSSZ Technické požadavky Síťová infrastruktura Síťová infrastruktura bude zajišťovat následující funkčnost: 55

56 Propojení na mezinárodní část uzavřenou sítí na vyhrazené infrastruktuře stesta. Propojení s ostatními českými AP pro zajištění workflow vyţadující asistenci více institucí. Konektor do vnitřní sítě ČSSZ. Přístup zaměstnanců ČSSZ na WEBIC a adresářové sluţby AP ČSSZ. Musí zajistit bezpečné oddělení všech vzájemně komunikujících subjektů a zamezit případným útokům z jiných propojených sítí (např. z stesta) Musí umoţnit případné připojení dalších institucí, které by v budoucnu téţ vyuţívaly AP ČSSZ. Operační a aplikační systémy Tyto systémy musí vyhovovat poţadavkům. HW HW musí být dimenzován na výkonnost a spolehlivost. Přehled subsystémů, které budou řešeny v rámci oblasti IN/OUT: Oblast Subsystém Název Projekt 1 Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací atd. 1.1 Informační subsystém rozhraní pro zabezpečení komunikace IIS ČSSZ B2B rozhraní, DIS Server PVS rozhran,í VREP veř. Rozhraní e-podání DSS rozhraní Internet, DAS, ISDS Server, Czech Point Rozhraní, Access Point rozhraní pro ČSSZ, E-Podatelna/e-výpravna ( ), Rozhraní pro vzdálený přístup zaměstnanců ČSSZ Klientský portál ČSSZ 1.2 Řešení oblasti vstupu a ošetření informací projekt IN (DIS_IN) Strukt. Fondy Č. 157, Řešení oblasti OUT vyţaduje zpracovat obdobnou analýzu jako byla realizována pro oblast IN. Vyţaduje definovat Rozhraní mezi aplikační oblastí a oblastí OUT. Rozhraní mezi aplikacemi a expedicí datových zpráv prostřednictvím datových schránek. Rozhraní mezi aplikacemi a expedicí prostřednictvím spisové sluţby. Rozhraní mezi aplikacemi a tiskovým střediskem integrace stávajících procesů. 3.2 Oblast 2 - Výběr pojistného Úlohou této oblasti procesů je zabezpečit výběr pojistného pro důchodové pojištění, nemocenské pojištění a příspěvku na podporu v nezaměstnanosti. Pokud bude schválen zákon o úrazovém pojištění tak i pro výběr pojistného na úrazové pojištění. Jde o velmi významnou oblast činnosti ČSSZ, neboť zabezpečuje výběr prostředků v objemu cca 370 mld. Kč, coţ představuje cca 1/3 příjmů státního rozpočtu. V legislativních záměrech je začlenění úrazového pojištění do ČSSZ. Tato skutečnost bude vyţadovat vytvoření samostatného subsystémů. 56

57 Centralizace dat a aplikační podpory dosud nebyla zcela dokončena a proto v této oblasti jsou provozovány centrální a lokální aplikace. V této oblasti je vyvíjena, implementována a provozována aplikační podpora v rámci následujících aplikací a subsystémů Projekt - Výběr pojistného (POJ) (subsystém ISS 2.1) Aplikační podpora POJ je provozována od počátku roku Cílem projektu bylo vytvoření nového aplikačního programového vybavení pro podporu oblasti výběru pojistného na sociální zabezpečení a příspěvek na státní politiku zaměstnanosti. Odsunutí účinnosti nového zákona o nemocenském pojištění a s tím souvisejících novel zákonů mělo na oblast IKT zásadní dopady. APV POJ nebylo moţno v připravené podobě nasadit a práce na projektu byly přerušeny. V prvním pololetí roku 2008 proběhla adaptace na schválené změny (aplikace, data, infrastruktura a metodiky). Koncem roku 2009 byla akceptována finální verze aplikace POJ Šlo fakticky o plnění z roku 2008 a 2009, které bylo z důvodu čerpání prostředků rozděleno i do roku Předmětem tohoto plnění bylo dodání Finální verze APV POJ, která není zaměřena na zapracování nových poţadavků vedoucích k rozvoji APV POJ, ale jde o optimalizaci, odladění a zlepšení fungování systému. Od verze ( ) byly dokončeny práce na Přírůstku II POJ08. Zároveň v průběhu roku probíhaly práce na tzv. Přírůstku III POJ09 s podstatným rozšířením funkčnosti v oblasti optimalizace mechanismů vymáhání titulů, umisťování plateb v rámci konkurzu, manuální vyvolání změny místní příslušnosti, zjištění všech registrací plátce a další. Tento subsystém je zaměřen na centrální podporu této oblasti a bude nahrazovat dosavadní decentralizované aplikace. Aplikační programové vybavení POJ zajišťuje centrální výběr pojistného dle poţadavků ČSSZ, za agendy nemocenského pojištění a agendu zaměstnavatelů. Cílem projektu je úprava APV pro oblast výběru pojistného zaměřená na centralizaci dat, decentralizované uţivatelské prostředí a komunikaci s kmenovými registry. I/OPicture POJ Datum poslední aktualizace Datum vytvoření KLIENT POJ klient /tenký klient/ Pořadové číslo (verze) Stav v produkci 1 od AAA APLIKAČNÍ ČÁST NEM VZT KE2 (SI2) DMS ZDV NP SPOL ZAME AAA proxy Legenda Klient SAP MIS Okresní aplikace Aplikační část Serverová část aplikace Aplikační rozhraní DATA INP1 pojweb pojcore pojnp pojsdk pojzame DB schema Databáze Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis do/čtení z DB Obrázek 24 - I/O Picture POJ V APV POJ jsou především nutné změny a rozšíření vyplývající z legislativních změn, úpravy související s posunem nasazení APV, úpravy související s poţadavky, které dosud nebyly realizovány a s problematikou transformace zůstatků kont plátců z okresních aplikací do centrálního POJ a řešení nejzávaţnějších připomínek uţivatelů k ergonomii ovládání aplikace. Dále se provádí optimalizace některých kritických algoritmů Rozvoj POJ - plánovaná centralizace aplikace OSVČ Nejrozsáhlejší agenda vedená na lokální úrovni pro evidenci a výběr pojistného na důchodové pojištění OSVČ + předávání informaci do oblasti nárokových podkladů důchodového pojištění. Cílově plánováno zařazení do centrální úlohy POJ jako další z modulů. Předpokladem je vytvoření centrální evidence OSVČ v KE a VZT ( nyní je v POJ vyuţíván registr CRP) a zajištění s tím souvisejících úprav oblasti VZT. 57

58 Pak je nutné zapracovat všechny potřebné funkcionality z lokálního zpracování N_OSVČ, N_SANKCE, N_POJS N_UCET ( pořizování přehledů o příjmech a výdajích, pravděpodobná výše pojistného, pořizování splátkových reţimů, nedobytné pohledávky, umísťování plateb atd.) Zatím není analyticky řešeno Projekt - Insolvenční řízení (INSRI) (subsystém ISS 2.2) Projekt reaguje na přijetí zákona č.182/2006 Sb.: od je v provozu nový informační systém veřejné správy Insolvenční rejstřík (ISIR), jehoţ základní úlohou je zajistit informovanost o insolvenčních řízeních a umoţnit sledování jejich průběhů. Projekt obsahuje koncepční řešení oblasti vymáhaných pohledávek, tedy exekucí, úpadku, insolvence a konkurzu s vazbou na jiţ existující centralizovaná řešení s respektováním současných řešení ekonomického systému, centrálních registrů a navazujících aplikací. Základním cílem tohoto projektu je koncepční řešení oblasti vymáhaných pohledávek tak, aby nešlo o izolované řešení jedné agendy, ale o řešení, které nebude klást do budoucna překáţky pro případ poţadavku na vytvoření jednotného přehledu o vymáhaných pohledávkách napříč ČSSZ. Projekt byl rozdělen do tří etap. V roce 2009 byla z druhé etapy rozvoje projektu realizována jen ta část, která se přímo týká práce s insolvenčním rejstříkem a byla plánována pro tuto etapu. Mimo jiné došlo k zapracování změn, které nastaly v externí veřejné sluţbě insolventního rejstříku ISIR, dále došlo k zavedení nových funkcionalit: elektronické odesílání dokumentů, podpora hlasovacích lístků, rozšíření o proces podání Návrhu na zahájení insolvenčního řízení, vyuţití systému ATV (archiv tiskových výstupů), centrální uloţení (registr) informací o insolvenčním řízení pro ostatní aplikace IS ČSSZ a další. Uvedené změny byly připraveny v roce 2009 a nasazeny do provozu počátkem roku Aplikace SPR (správa vymáhaných pohledávek ) - centralizace lokální aplikace SPRIZ Poţadavky na náhradu lokální aplikace SPRIZ - Správní řízení. Aplikace bude nahrazena centrální aplikací, která je v tomto dokumentu označována zkratkou SPR. Obsahuje především : Poţadavky na evidencí řízení o výkonu rozhodnutí, Poţadavky na evidencí řízení o splátkách, Poţadavky na evidencí řízení o promíjení penále, Poţadavky na evidenci odvolání a námitek, Poţadavky na evidenci likvidace organizace, Poţadavky na integraci s aplikací POJ, Poţadavky na integraci s oblastí důchodových a nemocenských přeplatků, Poţadavky na přenos dat z lokálních DP OSVČ. Schéma datový toků Zde je nastíněn budoucí stav bez ohledu na moţnost postupné realizace projektu. Cílem je upozornit na vzájemné souvislosti, proto následující popis můţe zobrazovat vazby, které zatím nebudou předmětem projektu realizace APV SPR nebo INS, ale mohou být odloţeny do dalších etap. V tom případě bude datový tok zajišťován organizačně (v papírové podobě) a APV umoţní ruční vstup přenášených údajů. 58

59 Náhled dlužník KE2 Příznak Insolvenčního řízení podle rejstříku (automaticky bez zásahu Pověřence) Příznak Likvidace organizace Postup Insolvenčního řízení Další aplikace SDD EXK INS Náhled - zajištění Přihlášení / uplatnění titulu do IŘ SPR Likvidace organizace Titul Změny úhrad Další údaje viz popis rozhraní Náhled - úhrady - splátky EDS Aplikace původu Vymáhaných pohledávek Postup vymáhání POJ Infrastruktura ATR DMS ATV Data pro statistiky Centrální Přeplatky Centrální Data DP OSVČ SPRIZ Lokální DP OSVČ Obrázek 25: INS + SPR a okolní aplikace Zdrojem vymáhaných pohledávek budou tyto aplikace: Typ vymáhaná/zajišťovan é pohledávky Pojistné IS kde pohledávka vzniká Nemocenské pojištění Důchodové pojištění Ostatní (správně provozní činnosti) OSVČ Organizace OSVČ Organizace (pokud neplatí tak POJ DP OSVČ POJ V projektu nebude není pojištěn) řešeno Penále POJ DP OSVČ POJ V projektu nebude řešeno Přiráţky k pojistnému POJ DP OSVČ POJ V projektu nebude řešeno Přeplatky Přeplatky Přeplatky V projektu nebude řešeno Pokuty správní V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno v oblasti zdravotnické V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno Regresy V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno V projektu nebude řešeno Poznámka: Aplikace Přeplatky nerozhoduje o vzniku pohledávky, je však aplikací, která přeplatky a jejich úhrady eviduje a zúčtovává. Centrální aplikace SPR převezme funkcionalitu lokálních aplikací SPRIZ. Řízení zahájená dříve ve SPRIZ budou nadále evidována ve SPRIZ. Do SPR budou evidována pouze nově zahajovaná řízení. Migrace 59

60 dat z lokálních SPRIZ do centrálního SPR nebude nutná. Aplikace SPR bude cílově komunikovat se zdrojovou aplikací pohledávek, kterou podle typu pohledávky je: POJ Pohledávky z pojistného, penále a pokuty na nemocenském a důchodovém pojištění (kromě důchodového pojištění OSVČ) a úhrady. DP OSVČ Pohledávky z pojistného, penále a pokuty na důchodové pojištění OSVČ. Přeplatky Pohledávky z přeplatků důchodových a nemocenských dávek. Pro automatickou komunikaci s okresními aplikacemi DP OSVČ bude nutné zajistit přenos dat z okresů do centrálního datového úloţiště. Zaúčtování pohledávek a jejich úhrad zajistí zdrojová aplikace. Zaúčtování na podkonta bude provedeno podle 10ti místného VS plátce a podle specifického symbolu, který určí o jaký exekuční titul se jedná (případně určí dohodnutý splátkový kalendář). Aplikace SPR bude poskytovat aplikaci INS všechny tituly předané k vymáhání pro přihlašování a uplatňování pohledávek do insolvenčního řízení INS s mezinárodním prvkem Stávající aplikace bude rozšířena o mezinárodní prvek dle Nařízení rady (ES) č. 1346/2000, ze dne 29. května 2000, o úpadkovém řízení. V tuto chvíli je třeba vycházet z toho, ţe návrhy řešení jsou na sobě nezávislé ve významu priorit a cílů, to ale neznamená popření vzájemných vazeb, včetně vazeb na jiţ realizovanou část projektu. Oblast Subsystém Název 2 Výběr pojistného Projekt 2.1 Informační subsystém výběru pojistného POJ. Obsahuje základní údaje o pojistném, charakter a ekonomické výsledky pojištěného, stanovení výše pojistného na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti a informace o jeho úhradách. Další rozvoj aplikace POJ: plánovaná centralizace aplikace OSVČ 2.2 INS Insolvenční a správní řízení SPR aplikace pro správní řízení - V rámci projektu INS bude vytvořen nový centrální SPR se všemi potřebnými funkcionalitami, Nahradí lokální aplikaci SPRIZ. Řešení je analyticky připraveno, nutno zajistit finanční prostředky INS s mezinárodním prvkem V rámci technického zhodnocení aplikací Částečně nasazeno do provozu 3.3 Oblast 3 - Správa dávek důchodového a nemocenského pojištění Procesy v této oblasti zabezpečují dva základní subsystémy činnosti ČSSZ a to správa dávek důchodového pojištění, správa dávek nemocenského pojištění a v záměrech se objevuje nová oblast procesů, a to správa dávek úrazového pojištění. 60

61 3.3.1 Informační subsystém důchodových agend Aplikační podpora v oblasti správy dávek důchodového pojištění - platforma SQ100 BS2000 Aplikační podporu tvoří relativně autonomní, centralizovaný, ale dosud do IIS ČSSZ zcela neintegrovaný informační subsystém důchodového pojištění, který byl přemigrován na moderní platformu business SQ100 firmy Fujitsu. Jde o historicky nejstarší subsystém automatizované podpory důchodových agend. Jeho vývoj započal v roce 1965 a v současné době je provozována druhá varianta uvedená do provozu v roce 1980, která je však průběţně udrţována rozvíjena a inovována. Funkční pojetí tohoto subsystému lze charakterizovat následovně: Žádost o dávku důchodového pojištění je sepsána na územním pracovišti pomocí APV ZDD (jedná se o centrální aplikaci s decentralizovanými přístupy)- ročně je sepsáno cca nových ţádostí, identita ţadatele je v okamţiku sepsání ţádosti konfrontována s KE, ţádost obsahuje potřebné údaje pro daný typ dávky + doloţení chybějících dob pojištění (referent OSSZ můţe při sepisování nahlíţet na nárokové podklady pojištěnce pomocí aplikace PNP ( Prohlíţeč nárokových podkladů), ţádat je moţné o tyto přímé dávky důchodového pojištění - starobní důchod, invalidní důchod (1.,2. a 3. stupně) a pozůstalostní dávky vdovský, vdovecký a sirotčí důchod ( buď po aktivním pojištěnci nebo po důchodci), do IS ČSSZ přichází nová ţádost datově ( pro účely dalšího zpracování), a zároveň fyzicky podepsaná ţadatelem ( pro účely zaloţení fyzického spisu) společně s doloţenými nárokovými podklady, zahraniční ţádosti jsou do ČSSZ doručovány klasicky na standardizovaných tiskopisech E- formulářích, které budou v rámci EESSI nahrazeny elektronickými formuláři SED. Datová věta žádosti je zpracována subsystémem - Avíza Toto zpracování zajistí kontrolu dat, nahrání relevantních dat do SRD ( soubor rozhodování o důchodových dávkách), roztřídění případů na ty, které lze zpracovat větví DIGI a ty, které je nutné zpracovat mimo ni. Rozdělení probíhá dle druhů důchodu DIGI dané zpracování buď neumí, nebo není vůbec třeba). Dále zajistí tisk produktů nutných pro zaloţení fyzického dávkového spisu a další zpracování. Pokud případ spadá do DIGI zpracování (tj. lze pracovat s nárokovými podklady v digitalizované podobě), sestaví se průběh dob pojištění (Osobní list důchodového pojištění) v aplikaci UI42, poté je případ připraven ke zpracování v SRD. Pokud případ není moţné zpracovat DIGI zpracováním, dotahují se doby pojištění buď z archivu SRD (pokud se zde s případem jiţ dříve pracovalo) nebo z UIP (pokud byl zpracován Informativní osobní list důchodového pojištění) nebo se musí ručně navkládat podle IMAGES nárokových podkladů z databáze nárokových podkladů (impulz pro tisk dává subsystém Avíza). Dále probíhá výpočet v SRD (Soubor rozhodování o důchodových dávkách) podle příslušných právních předpisů, SRD musí umět historické výpočty a srovnávací výpočty, - dále výpočty podle nařízení EU (5 typů) i bilaterálních smluv uzavřených mezi ČR a konkrétními státy (5 typů). V SRD se dále rozhoduje, zda další zpracování je moţné provést o plně automatizovaně, o poloautomatizovaně, o klasicky. Dále třídí případy na tuzemské a zahraniční SRD kromě zpracování nových ţádostí má i další funkce pro tzv. povyměřovací agendu, kdy dochází na základě ţádosti pojištěnce ke změně jiţ přiznaného a vypláceného důchodu. Další zpracování tuzemských případů: vstupy jsou připravovány interaktivně nebo pomocí zdrojových dokladů, které jsou součástí klasického důchodového spisu nebo kartotéky likvidačních listů (dokladové evidence o výplatách důchodu) a data jsou nabírána subsystémem pro pořizování dat DCPA, automatizované zpracování - případy, kde lze automatizovaně vytisknout rozhodnutí a spočítat doplatek jsou předány do pracovního cyklu, poloautomatizované zpracování - případy, kde je nutné vyhotovit rozhodnutí klasicky a doplatek zpracovat automatizovaně jsou předány k vytvoření klasického rozhodnutí, poté vstupují do pracovního cyklu, 61

62 klasické zpracování - případy které nelze vůbec zpracovat automatizovaně, jsou předány k vytvoření klasického rozhodnutí a poukázání klasicky vypočteného doplatku, poté vstupují do pracovního cyklu, na zpracování klasických rozhodnutí a klasických doplatků existuje speciální aplikační programové vybavení. Pracovní cyklus provede kontroly a příslušné procedury (rozhodnutí, doplatek) a poté zapíše případ do Evidence důchodů a RDIL (přehled jednotlivých stavů evidence důchodů - historie), zajišťuje další funkce pro provedení změn na základě vnějších podnětů vnější podněty vyvolají změnu ( jakýchkoliv údajů), zánik důchodu, pozastavení poţadavků na výplatu, poţadavky na výplaty doplatků jsou prostřednictvím dávkového rozhraní (soubor Předpis) předány k dalšímu zpracování do procesu Výplaty dávek. Matriční cyklus Je speciálním typem pracovního cyklu, který na základě opisů úmrtních listů nebo ţádostí o pozůstalostní důchod zastavuje výplatu dávek zemřelé osoby. Evidence důchodů slouţí jako základní soubor pro výplatu dávek v tuzemsku (eviduje cca důchodců). Výplatní cykly Aktuální stav poţadavků na výplaty pro daný výplatní měsíc připravují výplatní cykly ( jsou 4 pro jeden výplatní měsíc). Tyto cykly zároveň zajišťují změny z vnitřního podnětu ( např. zastavení poţadavků na výplaty u některých typů případů). Poţadavky na výplaty jsou prostřednictvím dávkového rozhraní (soubor Předpis) předány k dalšímu zpracování do procesu Výplaty dávek. Měsíční cyklus Po uzavření výplatního měsíce provádí kontroly nad Evidencí důchodů sleduje lhůty, vytváří kontrolní sestavy a zajišťuje vyslání kontrolních dotazníků. Další zpracování zahraničních případů Po zpracování v SRD jsou případy s bydlištěm v cizině zpracovávány klasicky (rozhodnutí, vyúčtování) a jsou vkládávány do EVCZ (Evidence cizina cca ,- případů). Jedná se o základní soubor pro výplaty těchto dávek. Poţadavky na výplaty jsou prostřednictvím dávkového rozhraní (soubor Předpis) předány k dalšímu zpracování do procesu Výplaty dávek. Pomocné subsystémy Existují různé pomocné subsystémy pro výplaty exekucí, doplatků spočtených klasicky, odškodnění a výplat dávek, které z různých důvodů nemohou být prováděny z Evidence důchodů tyto subsystémy rovněţ poskytují dávková rozhraní pro výplaty dávek. Dále existuje specializované APV pro různé specializované činnosti (zamítavá rozhodnutí, změna stupně invalidity, klasická rozhodnutí, storno poţadavků na výplaty). Výstupy některých z nich jsou zpracovávány pracovními cykly a následně promítány do Evidence důchodů. Hromadné úpravy důchodů V souladu s právnímu předpisy jsou v Evidenci důchodů, EVCZ a ostatních pomocných subsystémech prováděny hromadné přepočty dávek valorizace - se zajištěním poţadovaných výstupů. Je nutno k tomu poznamenat, ţe oblast nárokových podkladů a jejich předzpracování je předmětem oblasti 5 a výplata dávek je předmětem oblasti 4. 62

63 Obrázek 26 - Vstup nových žádostí do subsystému Realizace Parametrických změn v zákoně č. 155/1995 Sb. Příprava a zapracování parametrických změn do všech součástí důchodového systému byly prioritním a nejrozsáhlejším úkolem v roce V 1. a 2. čtvrtletí šlo o spoluúčast na přípravě a vytváření finální podoby materiálů-poţadavků k jednotlivým meritorním okruhům: pro zapracování do SRD a UI42 (zavedení nových druhů důchodů, změny v posuzování a výpočtu, rozsáhlé změny v automatizovaných i klasických rozhodnutí), obdobně bylo nutno toto zapracovat do aplikace IDV - informativní výpočet důchodu, vyuţívané na OSSZ, pro zpracování v Pracovním cyklu (rozsáhlé změny nebo rušení stávajících testů a zavádění testů nových v základních dokladech ZDO2, ZDO8, ZDO7, zpracování nových agend plynoucích z aplikace INV, úprava RDIL, pro zpracování ve Výplatním cyklu (úpravy ve stávajících agendách, zavedení nových agend,) pro zpracování v Měsíčním cyklu, pro přípravu nového programového zabezpečení (především nové aplikace INV pro zpracování změn stupňů invalidních důchodů), pro statistiky (provozní, stavová, pohybová) atd. Bylo prověřeno celé stávající zpracování důchodových agend a vyhodnocen moţný dopad parametrických změn (nds, ss13, PŘÍJMY a nové rozhraní pro PŘÍJMY na MPSV, Work, VYP-Konto příjemce, EKIS-předpisy, UIP-VDPE, DB-nárokové podklady atd.). Současně bylo započato s přípravou zadání včetně průběţného promítání dodatečných poţadavků a upřesňování. Zároveň probíhala ve 2. a 3. čtvrtletí příprava na provedení transformace (transformace plných a částečných invalidních důchodů na důchod SI při věku důchodce vyšším neţ 65 let, transformace plných invalidních důchodů na invalidní důchody 3. stupně a částečných invalidních důchodů na důchody 1. nebo 2. stupně, zavedení naplnění údaje Zpoplatnění) v evidencích důchodů EVID, EVCZ a SOP. Následně byla zahájena analytická a programová příprava, výsledky všech úprav byly podrobeny důkladnému ověřování, včetně pilotního zpracování transformace na celý evidenční soubor. Po ukončeném zpracování důchodových agend za měsíc prosinec byla v evidencích důchodů úspěšně provedena transformace T10/1, a to s vyuţitím údaje PZV (procentní ztráta výdělečné schopnosti poţivatelů částečných invalidních důchodů) získaného z databáze jiţ dříve připravené a vyuţívané aplikace PZV. Od 1. pracovního cyklu na výplatní leden 2010 byly zajištěny všechny nezbytné úpravy vyplývající z Parametrických změn. Projekt parametrických změn se dokončuje v roce 2010 a pak jiţ nebude mít pokračování završuje se tak první etapa důchodové reformy. Valorizace ZPD10/1 Ve 4. čtvrtletí 2009 bylo na základě nařízení vlády č. 340/2009 připraveno a ve čtyřech mimořádných cyklech (AC) realizováno zvýšení zvláštního příplatku k důchodu. Zvýšení bylo promítnuto do evidencí EVID a EVCZ, související úprava byla provedena v SRD, aplikaci JPP a do běţných agend. 63

64 Agenda SRD vedle parametrických změn zapracovány tyto změny: Nový způsob stanovení OVZ pro státy KOR a USA, výpočty EUB, EUC a EUD. Doloţky v Rozhodnutích - úprava textu stávajících a zapracování doloţek nových. Zapracování omezení výše vyměřovacího základu za rok 2009, nové přepočítací koeficienty. Dokončení aplikace SVK (zapracování Euro). Agenda výplat do ciziny EVCZ Vedle úprav souvisejících s parametrickými změnami (úprava obrazovky o nové údaje vyplývající z Transformace, zobrazení původní hodnoty PZV), byl rozšířen číselník STÁTY o celou skupinu dalších klíčů a zkratek, byla provedena aktualizace zdrojového dokladu. Výplatní modul VYP Jde o propojení důchodové oblasti s aplikací VYP na straně SQ serveru. V roce 2009 bylo: Vytvořeno nové rozhraní pro komunikaci mezi ČSSZ a MPSV při předávání informací o všech vyplacených dávkách nemocenského a důchodového pojištění. Zajištěn přechod na nový platební systém ABO-K internetového bankovnictví. Aplikace PNP Pro vyuţití na OSSZ by vytvořena a předána aplikace PNP Prohlíţeč nárokových podkladů, která je určena především pro regionální pracoviště a byla koncem roku 2009 připravena pro uvedení do provozu. Aplikace UIDV Byla rozšířena moţnost výběru nárokových podkladů Aplikace Správa důchodových dávek (SDD) Projekt SDD byl původně plánován jako jeden z prvních v rámci programu ISŘS pod označením Řízení migrace z mainframe na serverové farmy a datové úloţiště. Cílem projektu bylo vytvoření nové struktury procesů, nastavení funkcí a vytvoření dostatečných podmínek ke splnění úkolu převést zpracování informačního systému výpočtu a výplaty důchodů na serverovou platformu a autonomní centrální datové úloţiště. Procesní model byl rozčleněn na tři části: Správa dávek důchodového pojištění (SDD), Exekuce a konkurzy (EXK) Výplata dávek důchodového pojištění (VYP). Poslední dva subsystémy se staly samostatnými subsystémy a jsou popsány samostatně. Aplikace Správa dávek důchodového pojištění (SDD) byla plánována v rámci migrace APV na serverové farmy s přechodem na systém zpracování důchodové problematiky se zpracováním na elektronické bázi (tzn. bezpapírově) ať jiţ v ústředí nebo na územních pracovištích. Práce na projektu SDD probíhaly ve dvou základních rovinách: Rovina migrace dat Centrálního výpočetního systému (CVS): Byla ukončena pilotní migrace dat CVS (soubory RDIL, EVID,ASRD, NARBOJ, ODVLEC, ARMADA, EVCZ a SOP. Byla zajištěna realizace principu přírůstkové aktualizace migrovaných dat mainframe cílové úloţiště). Rovina vývoje aplikačního programového vybavení (APV) SDD: Projekt se skládá z modulů EDS - Elektronický dávkový spis, ROD - Rozhodování o dávce, AUV - Automatizovaný výpočet, HRP - Hromadné podněty, SLH - Sledování lhůt, ATR, nebo také SDD-STV - Automatizovaná tvorba rozhodnutí, STD - Statistika důchodů. Funkčnosti modulů SDD definované a realizované zejména v rámci IZ DUCH 2007 byly prvním krokem k vybudování komplexního informačního systému SDD. Některé části aplikace byly dovedeny aţ do ověřování v pilotním běhu, ale výsledky pilotního ověření nebylo moţno pouţít pro nasazení do rutinního provozu, protoţe vyţadovaly napojení na výsledky dalšího vývoje APV SDD, s vyšším rozsahem pokrytí důchodových případů. Pilotní provoz ověřil funkčnost v rozsahu vymezeném pro tuto fázi projektu. Strategie řešení důchodové oblasti vychází z toho, ţe převedení dosavadního systému na zcela nový databázový i aplikační systém je komplexní a sloţitou záleţitostí. Proto je nutné celý proces otestovat se všemi vzájemnými vazbami. Nedostatečné ověření funkčnosti nového systému a nedostatečný časový prostor pro proškolení několika set zaměstnanců by mohly mít za následek kolaps systému rozhodování i výplat důchodů. Byla proto posouzena strategie přechodu a s ohledem na extrémní rozsah a provázanost projektů, připravované legislativní změny a především nutná prevence přerušení kontinuity důchodového procesu se závěrem vedoucím k preferenci řešení postupného zavádění nového důchodového systému a opuštění původní varianty jednorázového převodu. Při vytváření nového systému bylo nutné zohlednit připravované parametrické změny zákona o důchodovém pojištění, které se svým rozsahem dotkly všech částí aplikační podpory procesu důchodového pojištění. Tyto okolnosti vyţadují přezkoumat technickou strategii přechodu a hledat cesty, jak zabezpečit postupný náběh systému nezávisle na technické platformě. Předpokladem bylo vytvoření podmínek pro paralelní souběh obou systémů. Toho bylo dosaţeno inovací mainframe systému serverem SQ100. V rámci toho je snaha vyuţít všech komponentů plánovaného systému pokud to jen bude moţné.. 64

65 Integrace aplikací subsystémů modelu SQ100 V souvislosti s vyuţitím aplikace EXK pro řešení situace v oblasti exekucí se ukázalo potřebné zpřístupnit data evidence důchodů aplikaci EXK ve formě, v jaké byla původně plánována. Jako řešení byla zvolena revitalizace modulu EDS. Původní koncept modulu EDS zobrazuje následující schéma: Obrázek 27 - Revitalizace modulu EDS aplikace SDD V této roli se vyuţívá zejména vnitřního datového úloţiště, kam jsou ukládána data z evidence důchodů, které vyuţívá aplikace EXK. Po posouzení tohoto konceptu se ukazuje, ţe právě vyuţití úloţiště pro soustřeďování a kopírování dat není vhodné a dále nebude tento koncept rozvíjen. Ukázalo se, ţe uvedený koncept lze upravit tak, aby tvořil metasystém, který bude obsahovat informace o všech dokumentech, které jsou k danému subjektu v ČSSZ k dispozici. V tomto smyslu pak tato koncepce patří do průřezových subsystémů a je v této oblasti popsána Integrace současného systému SQ100 do IIS a jeho inovace Základním úkolem pro tuto oblast a subsystém pro další období je jeho plné zaintegrování do oblasti IIS ČSSZ. Předpokládá se postupný proces této integrace s cílem nenarušit provozování ţádného ze subsystémů s maximálním vyuţitím myšlenek i rozpracovaných produktů historicky připravovaného projektu SDD, který byl pro jiné úkoly vyplývající ze zákonných změn zastaven. Principiálně budou úkoly řešeny podle zásad SOA architektury v těchto okruzích projektů: Nahradit stávající subsystém sběru a předzpracování dat označovaným jako DCPA, jeho navázání na KE a začlenění do oblasti IN. Realizovat vazbu na KE2 a jejich vyuţívání v této oblasti. Začlenit vazbu na subsystém PŘKPS a zabezpečit vstupy pro monitoring procesů provozované aplikace. Realizovat myšlenku EDS subsystému elektronického dávkového spisu ve smyslu uvedeného konceptu a integrovat jej do subsystému. Vypracovat nový datový model podle současných potřeb zpracování a provést konsolidaci dat systému do výkonné databázové struktury s mohutnou podporou pro poskytování sluţeb v souladu se SOA architekturou. Posoudit současné procedurální zpracování organizované do cyklů, posoudit jejich nezbytnost a přeorganizovat tak, aby dovolily vytvořit paralelní subsystém v kombinaci s dosavadní procedurální strukturou zabezpečující poskytování sluţeb klientům. Realizovat vazby na ostatní aplikace v souladu se SOA architekturou. V návaznosti na uvedené poţadavky dimenzovat technologickou základnu datového úloţiště a systému SQ Integrace aplikací UI42 a UI45 do IIS ČSSZ V návaznosti na záměry integrovat do IIS oblasti aplikací podporujících důchodovou oblast mimo aplikaci SDD se uvaţuje s uzpůsobením těchto aplikací tak, aby mohly komunikovat s dalšími aplikačními 65

66 oblastmi a aplikacemi. Současně je nutno do těchto aplikací zapracovat tzv. mezinárodní prvek podpora pro zahraniční agendy. Obrázek 28 Integrace aplikační oblasti UI42 do IIS Nejbliţší moţné etapy postupného rozvoje: Etapa 1 - Technické a technologické změny Nemají přímý dopad do práce uţivatelů Jsou nezbytné pro realizaci dalších etap Část změn je jiţ připravena a odzkoušena. Etapa 2 - Zprovoznění EDS (ve smyslu nového konceptu elektronického spisu) Vyuţití změn Etapy1 Uţivatelé dostávají nový nástroj Příprava na klientský portál (Pojištěnce) Přístup k datům na modelu SQ100. Oběh spisu bude sledován i mimo úsek 4. Etapa 3 - Postupné změny APV UIP, UI45_INP, UI42 vytvoření UI3001, Změny jiţ mají dopad na práci uţivatelů (GUI, způsob práce s aplikací) Logika, data, řízení zpracování zůstávají na SQ100. Postupné opuštění způsobu práce v SRD. Rozšíření workflow zpracování ve WORK aţ k výpočtu důchodové dávky v SRD. Příprava realizace mezinárodního prvku. rozvoj. Poţaduje se začlenění do oblasti řízení a napojení na PŘKPS a vytvoření předpokladů pro další jeho Informační subsystém agend nemocenského pojištění Projekt - Nemocenské pojištění (NEM) (subsystém ISS 3.2) Zajišťuje přechod z lokálního způsobu zpracování na centralizovaná data a decentralizované prostředí v oblasti nemocenského pojištění. Práce na projektu probíhaly od konce r Byla vytvořena zcela nová centrální aplikace, která prostřednictvím jednotlivých modulů zajišťuje komplexní evidenci pracovní neschopnosti a potřeby ošetřování/péče včetně potřebných statistických výstupů, kontrolu dodrţování léčebného reţimu, resp. reţimu dočasně práceneschopného pojištěnce, kontrolu posuzování dočasné pracovní neschopnosti a vlastní provádění nemocenského pojištění, tj. zpracování agendy dávek 66

67 nemocenského pojištění. Projekt byl ovlivněn odloţením účinnosti nového zákona o nemocenském pojištění. Zadání bylo koncem roku 2006 upraveno tak, aby byla aplikace pouţitelná alespoň v oblasti evidence pracovní neschopnosti (dále jen EPN), kontroly dodrţování léčebného reţimu (dále jen KLR) a pro lékařskou posudkovou sluţbu (dále jen LPS) ve stávajícím legislativním rámci. Práce na úpravách aplikace byly v roce 2007 dokončeny a od konce roku probíhaly práce v oblasti migrace dat. Od dubna 2008 proběhlo postupné uvádění částí aplikace (modulů EPN, KLR a LPS) do rutinního provozu. K byl dán do provozu další modul, a to modul Dávky. Největší pozornost byla dále věnována stabilizaci systému. Projektový tým v srpnu 2009 započal práce na nových modulech Exekuce a Náhradní výplaty s termínem nasazení do produkčního prostředí v lednu V souvislosti s legislativními změnami zákona č. 187/2006 Sb. o nemocenském pojištění byly zapracovány změny do aplikace NEM týkající se nových formulářů a výše dávek nemocenského pojištění a byl převeden decentralizovaný systém výplat dávek nemocenského pojištění na centrální systém výplat dávek, coţ znamená výraznou změnu v systému nemocenského pojištění za posledních padesát let. V současné době je aplikace v rutinním provozu v rámci celé ČSSZ a probíhá její dolaďování a optimalizace jako celku. I/OPicture NEM Datum poslední aktualizace Datum vytvoření KLIENT INNP /tenký klient/ NEM /tenký klient/ Pořadové číslo (verze) Stav v produkci 3 od AAA APLIKAČNÍ ČÁST DMS NEM POJ INNP DNP EPN VYP Local VZT ZDV KE2 (SI2) Legenda Klient Aplikační část DATA INP NEM Serverová část aplikace Aplikační rozhraní DB schema KEVDRC Databáze Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis/čtení do DB Obrázek 29 - I/O Picture NEM APV-NEM je systém specializovaný na podporu evidence zpracování a oběhu dat jak v klasické papírové podobě, tak v podobě elektronických dokumentů, za účelem správy agendy nemocenského pojištění ČSSZ. Aplikace APV-NEM sestává ze dvou oblastí: oblasti INNP a oblasti NEM. Aplikace NEM v současné době slouţí především ke zpracování evidence práce neschopných, kontrol léčebného reţimu, údajů o lékařské posudkové sluţby a evidenci a zpracování dávek NP. Funkcionalita aplikace vychází ze zákona č.187/2006 Sb. ve znění platném od Elektronická neschopenka Zavedení elektronické komunikace lékařů s ČSSZ úpravou stávajících subsystémů je moţno chápat jako další krok v zavedení systému Elektronické neschopenky (prvním krokem bude realizace elektronické přílohy ţádosti o dávku, její odesílání zaměstnavateli a další zpracování v ČSSZ). Cílem 0. etapy realizace el. neschopenky je zabezpečení elektronické komunikace lékařů s ČSSZ při zachování stávajícího legislativního rámce. Bezprostředně na 0. etapu můţe navazovat etapa 1., umoţňující elektronickou komunikaci zaměstnavatelů s ČSSZ. Komunikace ČSSZ s lékaři i zaměstnavateli předpokládá vyuţití datových schránek (ISDS), kterými disponují všechny právnické osoby. V 0. a 1. etapě se bude jednat o tisk neschopenky u lékaře, pro lékaře bez elektronické komunikace budou pouţity stávající tiskopisy neschopenky. V těchto etapách se bude jednat o elektronickou komunikaci pouze pro tiskopis dočasné pracovní neschopnosti a pro tiskopis Hlášení ošetřujícího lékaře. Zároveň předpokládá vybudování alternativních kanálů pro příjem e- podání tzv. VREP rozhraním, který bude doplněním a později náhradou PVS. Na nultou a první etapu realizace můţe navazovat etapa 2. směřující jiţ k cílovému řešení elektronické neschopence, včetně nutných legislativních změn, vyuţít Portál ČSSZ, změn tiskopisů 67

68 a doplnění dalších typů dokladů (OŠE, PPM). Zde jiţ dojde k plné elektronické komunikaci lékař-čssz, lékařzaměstnavatel, zaměstnavatel ČSSZ, s moţností aktivní či pasivní účasti pojištěnce komunikace prostřednictvím Portálu pojištěnce ČSSZ. Z hlediska papírového oběhu neschopenky bude zachován pouze jeden díl tiskopisu neschopenky, jako průkaz práce neschopného, kterým se můţe pojištěnec domáhat svých práv v případě, ţe by zaměstnavatel nezajistil doplnění elektronických údajů pro ČSSZ. Na cílové řešení Elektronické neschopenky mohou být čerpány finanční prostředky ze Strukturálních fondů Evropské unie. Cílové řešení, souvisí s projektem Klientského portálu ČSSZ rozhraní pro komunikaci s klienty, v jehoţ rámci bude vytvořeno komunikační rozhraní s klienty, orgány státní moci a dalšími subjekty, a do tohoto rozhraní budou integrovány i stávající komunikační kanály (např. sluţby Portálu veřejné správy, Datové schránky, ). Hlavní cíle realizace 0. etapy elektronické neschopenky lze definovat následovně: V co nejkratším čase vyřešit problém papírové korespondence lékař-čssz. Přispět k modernizaci veřejné správy České republiky poskytnutím sluţeb pro elektronickou komunikaci s ČSSZ. Sníţit náklady na poštovné neschopenek hrazené ČSSZ, případně poskytnutím moţnosti elektronické komunikace úplně zrušit hrazení poštovného ČSSZ. Zvýšit efektivitu práce lékařů a zjednodušit administrativu spojenou s vypsáním a zasíláním neschopenky. Zvýšit efektivitu zpracování neschopenek v ČSSZ pro elektronickou neschopenku nebude nutné v ČSSZ pořizovat data jako v případě současné papírové komunikace. Realizovat první krok v integraci dat lékařských SW vyuţívaných lékaři pro přiznávání dávek DPN s daty IS ČSSZ. Připravit lékaře na realizaci komplexního systému Elektronické neschopenky. Elektronické zasílání neschopenky do ČSSZ nesmí lékaře administrativně zatěţovat. V zájmu ČSSZ, která má hradit poštovné, je, aby pro lékaře bylo vyuţití elektronické komunikace jednodušší neţ administrativa spojená s odesíláním neschopenek poštou, protoţe poštovné uţ nebudou muset hradit. LÉKAŘI S UPRAVENÝM SW VREP ČSSZ PRAKTIK 4. 1 SPECIALISTA 3. 4 ISDS DATOVÉ SCHRÁNKY ČSSZ DIS EVIDENCE, REJSTŘÍKY ŘÍZENÍ ZPRACOVÁNÍ ČSSZ PORTÁL NEM Obrázek 30 - Koncepce komunikace lékař ČSSZ Dopady do stávajících systémů ČSSZ 68

69 Obrázek 31 - Dopady do stávajících systémů Elektronický způsob komunikace zaměstnavatelů s aplikací NEM bude jiţ pouţit při podávání elektronické přílohy k ţádosti o dávku V případě elektronické komunikace s lékařem a předáváním elektronické neschopenky se bude jednat o analogický postup, kdy prostřednictvím Datových schránek resp. VREP veřejným rozhraním (které v procesu nahradí PVS pouţitý pro přílohu k ţádosti o dávku) a systému DIS bude zapsána zdrojová datová věta neschopenky do DBZDV a DMS a bude do systému NEM zaslána událost, aby NEM neschopenku vyzvedl a zpracoval. Pokud bude neschopenka obsahovat chybné nebo nejasné údaje, bude předána ke zpracování v aplikaci INNP (vstup podkladů pro NEM), kde bude referentem došetřena. Dále bude rozšířeno NEMWF o funkčnosti zpracování elektronických předání stavu vyhledávání sestavy. Změna je v práci referentů, kteří dnes zpracovávají dokumenty, které fyzicky obdrţí. Jelikoţ jde o evidenční dokumenty, referenti došetří pouze ty dokumenty, které z jakýchkoli důvodů nebude moţno automaticky zpracovat. Samotné zpracování dokumentu referentem bude časově méně náročné, protoţe nebude muset opisovat informace z papírového dokumentu do aplikace Další rozvoj aplikace Další rozvoj aplikace pro rok 2010: Případná alokace finančních prostředků bude do těchto oblastí: Nový systém nemocenského pojištění dle změny zákona a jeho rozvoj. Vybudování kont příjemců a evidence příkazů k výplatě. Výměna informací nemocenského pojištění v rámci EU Informační subsystém agend úrazového pojištění Pokud vstoupí v platnost nový zákon o úrazovém pojištění bude nutné pro odpovídající zabezpečení tohoto zákona navýšit objem a výkonnost IT systémů, rozšířit stávající a pořídit nové specifické aplikační a programové vybavení vlastním vývojem případně dodavatelsky. Jedná se zejména o tyto oblasti: výběr pojistného na úrazové pojištění (dále jen ÚP) rozšíření o příslušné sluţby, sběr nárokových podkladů na ÚP začlenění do subsystému IN, správa a výpočet dávek ÚP nová aplikace subsystém 3.4, výplata dávky ÚP začlenění a napojení na subsystém VYP, statistiky ÚP začlenění do subsystému statistik, kontrolní činnost v oblasti ÚP. V oblasti infrastruktury je nutno počítat se: Zvýšením objemu a výkonnosti datového úloţiště. Zvýšením výkonu aplikačních serverů. Zabezpečení posílení výkonu komunikační infrastruktury. Zabezpečení 520-ti nových zaměstnanců výpočetní technikou. 69

70 Projekt se týká zabezpečení vytvoření a úpravu aplikací provozovaných v oblasti úrazového pojištění. Jedná se především o aplikace pro výběr pojistného na úrazové pojištění, aplikace pro sběr nárokových podkladů úrazového pojištění, aplikace pro výpočet dávky úrazového pojištění a tisk rozhodnutí úrazového pojištění, aplikace pro výplatu dávky úrazového pojištění, aplikace pro statistiky úrazového pojištění a aplikace pro kontrolní činnost v oblasti úrazového pojištění. ČSSZ předpokládá, ţe v rozvoji IS veřejné správy budou uplatňovány zásady nevyţadovat od klientů nadbytečné informace, minimalizovat jejich styk s veřejnou správou, efektivně vyuţívat informace vţdy a pouze tam, kde jsou oprávněně potřeba, zajistit bezpečnost informací a minimalizovat finanční náklady. Dále vychází z toho, ţe budoucí nový informační systém sociálního pojištění se bude rovněţ těmito principy řídit. Propojení s ostatními orgány státní správy by mělo za legislativní podpory splňovat tyto dvě funkce: - IS ČSSZ bude vyuţívat data ostatních vybraných registrů státní správy. - IS ČSSZ bude datovým zdrojem pro informační systémy státní správy. IN Doklady o platbě ÚP ÚRAZ Pojistná událost Výplata dávky VYP Statistika Kontrola LPS AAA portál Výběr pojistného Výpočet dávky OUT KE2 POJ PPV Obrázek 32 - Oblast úrazového pojištění Obrázek znázorňuje funkční celky odpovídající komponentám aplikačního softwaru oblasti úrazového pojištění včetně návazných oblastí. Tato oblast zajišťuje výběr pojistného na úrazové pojištění, sběr nárokových podkladů úrazového pojištění, výpočet dávky úrazového pojištění a tisk rozhodnutí úrazového pojištění, výplatu dávky úrazového pojištění, statistiky úrazového pojištění a kontrolní činnost v oblasti úrazového pojištění. Výběr pojistného na úrazové pojištění návaznosti na celkové okolí oblasti procesů: 70

71 Správa dokumentů Procesní workflow Poskytování informací Příjem podání Přehledy, žádosti... Přehledy, žádosti, výměry... Řídící informace Dotaz, žádost o informaci Požadované informace Výkazy. statistiky Správa tiskových výstupů Správa pojistných vztahů Pojistné vztahy plátce Údaje o platbách ÚP Výběr pojistného Platby pojistného úrazového pojištnění Prvotní doklady k zaúčtování Správa dávek úrazového pojištění Účtování o výběru pojistného Správa informací o účastnících pojištění Kmenové údaje plátců Požadavky, aktualizace Pohledávky platby Prominutí, nedobytnosti Podklady, podněty Platové výměry, Pokuty Potvrzení výplaty Žádost o výplatu Výplata dávek Správní řízení Kontrolní činnost Obrázek 33 - Výběr pojistného Schéma znázorňuje výběr pojistného a jeho umístění v rámci okolních procesů Lékařská posudková služba (LPS) Lékařská posudková sluţba (LPS) ČSSZ a LPS úřadů práce jsou od sloučeny a veškerá agenda posudkové sluţby úřadů práce je převedena na okresní správy sociálního zabezpečení (OSSZ). Změny jsou v souvislosti se změnou zákona č. 582/1991 Sb. o organizaci a provádění sociálního zabezpečení, zákona č. 435/2004 Sb. o zaměstnanosti a některých dalších zákonů. Lékaři posudkové sluţby České správy sociálního zabezpečení vypracovávají posudky pro systémy důchodového a nemocenského pojištění a od pro účely sociální péče, státní sociální podpory, sociálních sluţeb, hmotné nouze a zaměstnanosti. Pro účely nemocenského pojištění provádí kontrolu správnosti posuzování zdravotního stavu a dočasné pracovní neschopnosti a potřeby ošetřování ošetřujícími lékaři a posuzují pracovní schopnost dočasně práce neschopných pojištěnců po uplynutí podpůrčí doby. LPS ČSSZ provádí posudkovou činnost rovněţ pro oblast aplikace práva sociálního zabezpečení EU a bilaterálních smluv. Předmětem dalšího rozvoje je technické zhodnocení jiţ existujícího programového vybavení. V návaznosti na výše uvedené legislativní změny je pro posudkovou sluţbu ČSSZ nutné stále zdokonalovat programové vybavení, ve kterém referenti a lékaři zpracovávají všechny případy posudků o zdravotním stavu občanů. Program POSUDKY PSL je určen pro evidenci posuzovaných osob, vedení řízení s posuzovanými osobami a zápis výsledků jednání s posuzovanou osobou. Data o posuzovaných osobách jsou uloţena v centrální databázi, obsahující údaje z celé České republiky. V systému POSUDKY PSL je zaznamenáván celý postup řízení od vstupu poţadavku o vypracování posudku, vyţádání potřebné dokumentace, vyšetření, přidělení smluvnímu lékaři, vytvoření výstupů, statistické výstupy. Program automaticky přiděluje jednací čísla, jsou vytvořeny a centrálně udrţovány jednotné číselníky (předměty řízení, výsledky, seznamy lékařů, posudková zhodnocení, výroky a odůvodnění, záznamy o jednání, posudky, adresy). Systém je vybaven rozsáhlým tiskovým servisem jak pro lokální pracoviště, tak pro metodické centrum. <Doplnit napojení PSL na datové schránky> Případná alokace finančních prostředků bude do těchto oblastí: Vybavení posudkových lékařů. Rozvoj aplikační podpory. Komunikace s MPSV. 71

72 3.3.5 Projekt - Exekuce a konkurzy (EXK) (subsystém ISS 3.5) Projekt poskytuje programovou podporu pro zpracování agendy exekucí v důchodové oblasti. Cílem projektu EXK (jedná se o oblast rozhodování o exekučních sráţkách, které jsou sráţeny příjemci dávek a vypláceny oprávněnému, vnějšímu subjektu mimo ČSSZ) je dodávka APV pro podporu agendy exekucí a konkurzů, která prozatím neměla v rámci ČSSZ ţádnou aplikační podporu. V roce 2008 bylo rozhodnuto o transformaci projektu EXK, důvodem bylo nenasazení nového zpracování důchodové agendy do produkce v horizontu plánovaném pro projekt EXK. Současně byla vlastní realizace projektu EXK rozdělena do tří etap tzv. Přírůstků 1 aţ 3. Nasazení prvního přírůstku do produkčního prostředí bylo realizováno na počátku roku Obsahem přírůstku bylo zejména vytvoření elektronické databáze exekučních případů, evidence exekučních dokumentů, evidence lhůt pro zpracování exekučních případů a jejich kontrola a organizace práce exekučního oddělení přes aplikaci. Ve druhé polovině roku 2009 byl akceptován druhý a třetí přírůstek v souladu s plánem. Po zprovoznění P1 (přírůstek 1), tj. nástrojů pro evidenci jiţ doručených dokumentů, evidenci lhůt a kontrolu identity klienta vůči KE bylo provedeno postupné naplnění databáze EXK evidovanými případy a lhůtami. Do produkce byl nasazen rovněţ P2 výpočet exekučních sráţek,tvorba splátkového kalendáře, vytěţování evidovaných dokumentů, lokální tisky likvidačních listů atd. Byl zprovozněn Archiv výstupních tisků (ATR) pomocí ATR-DAP-DMV. Započata příprava P3, t.j napojení na VYP, EDS. Aktivace databáze EDS (údaje evidence důchodů pro EXK) - v rámci řešení projektu EXK bylo rozhodnuto vyuţít struktury databáze EDS definované v rámci projektu SDD. Po zpracování výsledků testování v průběhu 4. čtvrtletí proběhlo schvalování testovací a uţivatelské dokumentace, byla provedena aktualizace realizačního projektu, zátěţové testování v integračním prostředí a připraven plán náběhu do rutinního provozu. Aplikační programové vybavení Exekuce a konkurzy (APV EXK) má slouţit útvarům ČSSZ zabývajícím se exekucemi a konkurzy dostát své zákonné povinnosti provádět sráţky těm příjemcům důchodových dávek (povinným), na které je uvalen exekuční příkaz, anebo kde je jiný důvod k provádění sráţky z důchodu (např. dohoda o výţivném, obstávka mzdy jiţ při zavedení dávky, konkurzní sráţka) a vyplácet tyto sráţky oprávněným. I/OPicture EXK Datum poslední aktualizace Datum vytvoření Pořadové číslo (verze) 2 KLIENT EXK klient /tenký klient/ ATR klient /tlustý klient.net/ Stav v produkci od AAA APLIKAČNÍ ČÁST ZDV KE2 (SI2) EXK TSK EXK - ATR EDS_Codelist VST ADM OSV SUK DP PreS DaV Scheduler Service ATV Legenda Klient Aplikační část Serverová část aplikace Aplikační rozhraní DATA ADB EXK ADB ATREXK DB schema Databáze Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis do/čtení z DB Obrázek 34 - I/O Picture EXK Při řešení bylo vyuţito varianty EDS pro zajišťování dat o důchodových dávkách, ale tato cesta nebude dále rozvíjena. 72

73 Po realizaci P3 je počítáno s dalším rozvojem aplikace, vedle optimalizace, zkvalitnění a doplnění vlastních funkcí aplikace např. také v oblasti hromadných změn hromadná změna exekučních sráţek a druhů důchodů a úpravy rozhraní s VYP 2. fáze vratek. Oblast Subsystém Název Projekt 3 Správa dávek důchodového a nemocenského pojištění 3.1 Informační subsystém důchodových agend Evidence důchodů v rozsahu základních informací o druhu důchodu, výši, poţivateli; správa dávek důchodového pojištění. Další rozvoj aplikace pro rok 2010: Nový systém nemocenského pojištění dle změny zákona a jeho rozvoj. Vybudování kont příjemců a evidence příkazů k výplatě. Výměna informací nemocenského pojištění v rámci EU. byly všechny úpravy z Parametrických změn zajištěny nezbytné vyplývající Další rozvoj subsystému: řešení aplikace DCPA a její náhrada pro vkládání dat ze ZDO Integrace aplikací subsystémů modelu SQ100 Integrace aplikací UI42 a UI45 do IIS ČSSZ 3.2 Informační subsystém agend nemocenského pojištění Aplikace je informace v rozsahu výkonu činnosti orgánu sociálního v rutinním provozu zabezpečení, výběr pojistného a správa dávek nem. Pojištění. v rámci celé ČSSZ a probíhá její dolaďování a optimalizace Řešení elektronické neschopenky 0. Etapa 3.3 Informační subsystém agend úrazového pojištění informace v rozsahu výkonu činnosti orgánu sociálního zabezpečení, výběr pojistného a správa dávek úrazového pojištění. 3.4 Informační subsystém Lékařská posudková sluţba - Správa informací o pracovní neschopnosti posudková činnost v oblasti důchodového pojištění pro účely zjištění plné invalidity nebo částečné invalidity a dlouhodobě nepříznivého zdravotního stavu dítěte. Dále posudková činnost v oblasti nemocenské pro účely provádění kontroly posuzování dočasné pracovní neschopnosti ošetřujícími lékaři a dodrţování s tím souvisejících právních předpisů. Rozvoj aplikační podpory PSL Komunikace s MPSV Od Technické zhodnocení zdokonalování programového vybavení a 3.5 Informační subsystém exekucí dávek Provozováno rutinně. Po realizaci P3 je počítáno s dalším rozvojem aplikace, vedle optimalizace, zkvalitnění a doplnění vlastních funkcí aplikace např. také v oblasti hromadných změn hromadná změna exekučních sráţek a druhů důchodů a úpravy rozhraní s VYP 2. fáze vratek. 73

74 3.4 Oblast 4 - Výplaty dávek V této oblasti jsou procesy podporující správu poţadavků (z oblastí NEM, ZDD a důchodové oblasti, EXK) na výplatu veškerých dávek/sráţek, sestavení předpisu výplaty, sestavení výplatní dávky, vytvoření platebních souborů, konto příjemce a zpracování zpětných informací o provedených platbách. Bylo připraveno rozšíření rozhraní pro předávání dat k výplatám přes mainframe/ekis. Dále bylo uvedeno do provozu poukazování výplat dávek nemocenského pojištění Výplata dávek (VYP) - průřezový pro všechny subsystémy (ISS 4.1) Cílem projektu je správa poţadavků (z oblastí NEM, SDD, EXK) na výplatu veškerých dávek/sráţek, sestavení předpisu výplaty, sestavení výplatní dávky, vytvoření platebních souborů, konto příjemce a zpracování zpětných informací o provedených platbách. Projekt VYP byl zahájen v r Oproti původnímu zadání, které počítalo v oblasti centralizace výplat dávek nemocenského pojištění pouze s provedením studie proveditelnosti, bylo dosaţeno centralizace výplat z účtu ústředí ČSSZ přesto, ţe dávky nemocenského pojištění byly spravovány lokálními aplikacemi vyuţívanými na jednotlivých OSSZ. Po nasazení dávkového modulu aplikace NEM, tj. od účinnosti ZNP tj. od , jsou prostřednictvím tohoto aplikačního programového vybavení dávky vypláceny prostřednictvím centrálního účtu ČSSZ. V roce 2009 byly změněny výstupní formáty pro výplaty na účty na FS5 a byl zaveden nový způsob předávání informací do IS Státní sociální podpory a Hmotné nouze. Procesní oblast Výplaty dávek/sráţek je pojata jako výplatní stroj. Ve výplatách nejsou ţádné rozhodovací procesy na základě právních aspektů. Podstatné rozhodování o platbách/sráţkách, jejich destinaci a jejich následném chování řídí ostatní okolní subsystémy k tomuto oprávněné. VYP pouze zajišťuje platby, vede o nich evidenci, zpracovává informace z výplatních míst, které následně eviduje a nebo je předává dále ostatním subsystémům. I/OPicture VYP Datum poslední aktualizace Datum vytvoření KLIENT Klient SAP /tenký klient/ Klient SAP /tlustý klient/ Pořadové číslo (verze) Stav v produkci 1 nasazeno AAA APLIKAČNÍ ČÁST NEM VYP1 Převzetí požadavků na výplatu dávky VYP3 Zpracování zpětných informací VYP4 Poskytování informací KE2 (SI2) VYP2 Sestavení výplatní dávky Vytvoření platebního souboru (předpisu) VYP5 Změna parametrů výplaty Legenda Klient Aplikační část Serverová část aplikace Aplikační rozhraní DATA Nativní databáze SAPu DB schema Databáze Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis do/čtení z DB Další rozvoj aplikace pro rok 2010: Obrázek 35 - I/O Picture VYP Předpokládá se potřeba provozních finančních prostředků pro pronájem outsourcovaných sluţeb. Případné náklady bude nutno kalkulovat pro zabezpečení s aplikačním systémem jak po HW tak i po SW stránce. Oblast Subsystém Název 4 Výplaty dávek 4.1 Informační subsystém o výplatách důchodových dávek. nemocenských dávek dávek úrazového pojištění 74 Projekt Provozováno rutinně Od

75 3.5 Oblast 5 - Správa údajové základny Projekt Důchodové pojištění (SDD) (subsystém ISS 5.1) Aplikace SDD je popsána v oblasti 3 správa dávek důchodového, nemocenského a úrazového pojištění Projekt - Nárokové podklady a dávky (NPD) (subsystém ISS 5.1) Projekt byl zahájen v roce 2006 a jeho cílem je nově nastavit procesy zpracování nárokových podkladů tak, aby příchozí nárokové podklady ze všech zdrojů byly plynule zpracovány (evidenční listy, datové věty z elektronických podání, informace z úřadů práce, doby pojištění OSVČ, doby dobrovolného pojištění) a pro návazný projekt SDD byl co nejrychleji poskytnut hrubý průběh pojištění ve formě očekávané tímto projektem. Projekt NPD má úzkou vazbu na projekt SDD, proto je ze stejných důvodů po dobu realizace parametrických změn pozastaven. Výjimkou je pouze další rozvoj kontrolní linky. Tento proces zahrnuje vstupní zpracování přes pořizovací linku (dále PL), kontrolní linku (dále KL) a vyhodnocovací IDV linku (dále IDVL) aţ po uloţení zkontrolovaného přehledu dob a výdělků do centrálního datového úloţiště DB_IDV. Byly realizovány úpravy KL na základě poţadavků z provozu jako je řízení běhu KA, optimalizace s vyuţitím partition. KL doznala i dalších změn v souvislosti s implementací nových funkčních poţadavků (statistik KL, vyhodnocování a kontrola formátu polí formulářů). Nárokové podklady důchodového pojištění Sem patří: správa nárokových podkladů pro cca 5 milionů pojištěnců celkem je v ČSSZ uloţeno cca 120 milionů dokladů ( některé jako Image a datová věta, některé pouze jako datová věta) doby pojištění ( Evidenční listy, potvrzení o studiu, dobrovolné pojištění z lokálních evidencí ČSSZ, důchodové pojištění OSVČ - z lokálních evidencí ČSSZ), náhradní doby pojištění ( doby nezaměstnanosti z Úřadů práce, doby vojenské sluţby převzaté z Ministerstva obrany, Doby péče o osobu blízkou a Doby pobírání invalidního důchodu převzaté z centrálních evidencí ČSSZ) Aplikační podpora pro práci s nárokovými podklady: DIGI Aplikace UIP - prohlíţení a práce s nárokovými podklady před vlastním podáním ţádosti, umoţňuje vytvořit IOLDP Informativní osobní list důchodového pojištění. Ten se zpracovává na ţádost klienta za účelem informace o všech dobách pojištění a náhradních dobách pojištění evidovaných v ČSSZ včetně vyměřovacích základů (chybějící doby můţe doloţit a to nejpozději při podání ţádosti) UI42 v okamţiku výpočtu dávky vyuţívá data z UIP pro vytvoření Osobního listu důchodového pojištění ( pouze doby a vyměřovací základy relevantní pro výpočet důchodové dávky) PNP aplikace umoţňující náhled na nárokové podklady z lokálních pracovišť, Aplikace kontrolní linka - KL Kontrolní linka je soubor technických prostředků, který spolu s příslušnými procesy slouţí ke kontrole a následnému řešení zjištěných diferencí (chyb, sporných údajů) v jednotlivých datových větách. Prvotní impuls pro start procesu kontrolní linky (KL) je příchod notifikace z externí oblasti nebo přímo ze ZDV o tom, ţe v dbzdv je nová zdrojová datová věta určená k opravě. Tato notifikace přichází na rozhraní KLInterface, jeţ zároveň zajišťuje samotné převzetí datové věty (DV). Kontrolní linka poskytuje dvě základní funkcionality: Kontrola údajů uvedených v DV. Kontroly. Kontroly jsou prováděny v bloku, který je nazýván kontrolní automat (tvořen je aplikační logikou KA Service). Oprava, resp. řešení sporných údajů v návaznosti na provedené kontroly. Tato funkcionalita je poskytována prostřednictvím aplikace UIP2 jako činnost pověřených pracovníků ČSSZ. V rámci KL jsou automatické kontroly prováděny na úrovni aplikační logiky, která je oddělena od klienta UIP2, v němţ se kontroly a opravy provádějí ručně. KL a její aplikační část však není monolitická, ale skládá se z více logických celků jednak jde o jiţ výše zmíněný KA Service a dále KLInterface, UIP2Wrapper a KA Tray and WS. Součástí kontrolní linky je i sledování statistik. Jako zdroj dat slouţí databáze KL. Statistiky se vytváří z dat uloţených v databázi KL, pro tvorbu je vyuţit Engine MS SQL Serveru, vytvořené jsou na 75

76 základě šablon. Šablony reportů včetně definic SQL dotazů pro doplnění dat do reportu jsou uloţeny v MS Reporting serveru. Hotové statistiky jsou online přenášeny na klienta KL, statistiky nejsou ukládány. I/OPicture KL Datum poslední aktualizace Datum vytvoření Pořadové číslo (verze) 2 KLIENT KL Klient UIP2 /tlustý klient.net, C#/ Stav v produkci Nasazeno AAA APLIKAČNÍ ČÁST DMS Notifikace z externích oblastí KLInterface UIP2Wrapper KAService (instance A, B) KA Tray and WS VZT SI2 UI44 KE2 ZDV BAM Statistiky KL Report server MS SQL Server Legenda Klient Aplikační část Serverová část aplikace DATA INP1 KL Aplikační rozhraní DB schema Databáze Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis/čtení do DB Obrázek 36 - I/O Picture ELDP: Z databáze optického archivu aplikace DOCR přiřadí naskenovaný obrázek vyplněného formuláře ELDP OCR lince ke zpracování. Existují dvě OCR linky pro zpracování ELDP: linka T9 HW i SW linky T9 patří ČSSZ a je obsluhována zaměstnanci ústředí ČSSZ, linka T10 HW i SW linky T10 patří outsourcerovi a je obsluhována zaměstnanci outsourcera. Aplikace Cardiff TELEform, která je přes klientské stanice obsluhována pracovníky outsourcera na lince T10 a pracovníky ČSSZ na lince T9, vytěţí z formuláře text a vytvoří zdrojovou datovou větu. Aplikace ZOCR uloţí vytěţené datové věty do databází DB_ZDV a INP (optický archiv). Komponenta JDV01 pomocí logických testů vyhodnotí validitu informace. Pokud je věta validní, je uloţena jako JDV (jednotná datová věta) do databáze INP. Pokud věta validní není, JDV se neukládá. Procesní diagram stávajícího procesu včetně skenování papírových formulářů ELDP je znázorněn zde: Obrázek 37 - Procesní diagram stávajícího procesu včetně ELDP Legenda: (rč) prvotní rozpoznání rč (můţe být neúplné rč - statusy u*) 76

77 rč automaticky rozpoznané rodné číslo v rámci předindexace (statusy a*, u*, s*) RČ rodné číslo potvrzené a verifikované proti KE (statusy a*) DB IMG naskenované obrázky nárokových podkladů uloţené v databázi DB_ZDV (tabulka INP_IMG) DB ZDV zdrojové datové věty uloţené v databázi DB_ZDV (tabulka INP_ZDV) DB meta meta informace stavy a atributy ze zpracování nárokového podkladu ukládané v databázi DB_ZDV (tabulka INP_EL) databanky DNP Procesní diagram stávajícího procesu včetně skenování papírových formulářů ONZ je znázorněn zde: Obrázek 38 - Procesní diagram stávajícího procesu včetně ONZ Legenda: BT BizTalk BTS BizTalk Server DB_ZDV databáze zdrojových datových vět DMA dokument management archiv 77

78 IMG obrázek naskenovaného vyplněného formuláře KL kontrolní linka rč automaticky rozpoznané rodné číslo v rámci předindexace ZDV zdrojová datová věta K problematice nárokových podkladů a centralizace dat se vztahuje i Projekt 155 "Konsolidace kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na ROB a další základní registry VS". Projekt 155 byl schválen usnesením vlády č. 536 ze v rámci seznamu záměrů strategických projektů pro čerpání finančních prostředků ze strukturálních fondů Evropské unie v rámci Smart Administration. Byla vypracována Studie proveditelnosti Projektu 155,dopracována Projektová dokumentace rekonstrukce objektů v Olomouci, kde se budou činnosti uvedené v Projektu 155 zajišťovat. Následně byl Projekt předloţen ke schválení na OSF MV ČR a zaregistrován pod č. CZ.1.06/1.1.00/ Projekt nebyl zatím hodnotiteli MV ČR vyhodnocen. Předmětem projektu je vytěţování, kontrola a konsolidace dat, coţ významnou měrou přispěje k zapojení ČSSZ do adekvátního vyuţívání ICT na úrovni třetího tisíciletí a k zapojení ČSSZ do vytváření centrálních registrů veřejné správy tak, aby bylo moţné bezpečné sdílení dat orgány veřejné moci a zároveň byl občanům umoţněn oprávněný přístup k údajům vedeným v těchto registrech. Záměrem ČSSZ je realizovat proces vytěţování, kontroly a konsolidace dat vlastními pracovníky, prostřednictvím vlastního hardware a ve vlastních prostorách. Realizací projektu dojde k úspoře finančních prostředků, sníţení náročnosti smluvních vztahů, eliminaci nutnosti předávat citlivá osobní data mimo ČSSZ, rozvoji ICT technologií, zajištění rychlejší a flexibilnější odezvy na poţadavky zaměstnanců ČSSZ a s tím spojené časové úspoře. Projekt bude mít dopad na kvalitnější, rychlejší a flexibilnější veřejné sluţby ČSSZ vůči občanům respektive zaměstnavatelům pro potřeby příjímání, zpracování a pouţívání podaných Oznámení o nástupu do zaměstnání, Evidenčních listů důchodového pojištění a dalších datových informací vytěţených z nově vzniklých formulářů (např. el. neschopenka). Provozní pracoviště zabývající se vytěžováním textu z dokumentů a konsolidací dat s registry Vzhledem ke vstupům procesu SW pro vytěţování textu (dat) proces musí být schopný vytěţovat text z naskenovaných obrázků formulářů ONZ a ELDP. Obrázky naskenovaných formulářů ONZ jsou uloţeny ve formátu JPEG v DMS. Obrázky naskenovaných formulářů ELDP jsou uloţeny ve formátu TIFF Group 4 Multi-TIFF (soubory s příponou.tif) v optickém archivu. Formuláře musí být vyplněny strojově, tj. mohou být vyplněny na psacím stroji nebo vytištěny na všech dostupných druzích tiskáren (jehličkových, laserových, LED, ). Skenování se provádí na OSSZ nebo na ústředí ČSSZ skenery Kodak i260 a Kodak i620. Dále z důvodu univerzálnosti pracoviště v Olomouci musí technologie být schopná vytěţovat i další, v současné době zatím nedefinované formuláře vypsané ručně hůlkovým písmem do připravených setboxů. Množstevní požadavky na vytěţování textu (dat) v Olomouci jsou stanoveny takto: ročně naskenovaných obrázků ONZ podaných na papírovém formuláři, ročně 1,2 milionu naskenovaných obrázků ELDP podaných na papírovém formuláři. Datová architektura vstupních a výstupních databází a typy formulářů (včetně vzorů) jsou popsány v v materiálu Projektu 155. S ohledem na koncepci integrovaného informačního systému ČSSZ je poţadováno, aby datové úloţiště v Olomouci bylo kompatibilní s hlavním a záloţním datovým úloţištěm na technologii IBM Shark a databázích Oracle Projekt ELDP, POS a ONZ (zpracování nových formulářů) Cílem projektu v oblasti ELDP a POS bylo zavedení nových typů nárokových podkladů do procesu zpracování v souladu s poţadavky zákona o NP, platným k (ZNP). K dosaţení tohoto cíle bylo potřeba provést identifikací dotčených míst (správa číselníků, Pořizovací linka, OCR linka, věcná zpracování datových vět, indexace proti KE, ukládací procesy nárokových podkladů a umoţnění zpracování pomocí DIGI aplikací) provozovaného systému, navrţení konkrétních způsobů realizace jednotlivých změn, zajištění zapracování těchto změn, resp. realizace nových částí APV a následně pak ověření korektnosti celého procesu zpracování. Zpracování všech formulářů bylo uvedeno do provozu. Cílem implementace změn ve zpracování papírových formulářů a datových vět ONZ platných pro rok 2009 (jednalo se celkem o sedm nových formulářů ONZ) byla opět implementace úprav, poţadovaných ZNP. Proces zpracování těchto formulářů a datových vět vycházel ze stávajícího procesu tvorba datové věty P/O. Úpravy se týkaly oblastí digitalizační linky (OCR, ZDV), KL, VZT, KE-UI44, UI08, dále pak přebírání datových vět z DIS (e - Podání) a z XML Filleru. Poţadované úpravy v rámci celého procesu zpracování od příjmu nascannovaného formuláře na OSSZ prostřednictvím DMS přes kontrolu vstupní informace, tvorbu datové věty včetně řešení nekonzistencí přes její uloţení, zpracování v KL aţ po zpřístupnění informací navazujícím procesům 78

79 nemocenské agendy (VZT, UI44 a UI08). Nové formuláře ONZ se v informačním systému ČSSZ rutinně zpracovávají. Do této oblasti patří i subsystémy pro digitalizaci dokumentů digitalizace spisové evidence, digi evidencí OSSZ, digitalizace nově příchozích podnětů, digitalizace věcné spisovny, vytěţování datových vět a jejich kontrola komponentou JDV01, Resp. subsystémem Kontrolní linky Novela zákona č. 582/1991 Sb. o organizaci a provádění sociálního zabezpečení (subsystém IIS 5.1) V souvislosti se změnou zákona č. 435/2004 Sb., o zaměstnanosti musí být v ČSSZ vytvořen systém programového zabezpečení (aplikace, databáze, přenos dat), který bude schopen umoţnit předávání dat v elektronické podobě. Poţadované prostředky investičního charakteru budou potřeba na zajištění HW, systémového SW, APV a přípravu dat byly nárokovány Projekt - Žádosti o důchodové dávky (ZDD) (subsystém ISS 5.1) Účelem je zabezpečit pořizování ţádostí o důchod prostřednictvím nové aplikace, která by nahradila papírové vyplňování ţádostí, a následný přenos všech takto získaných údajů elektronicky z OSSZ do ústředí ČSSZ k dalšímu zpracování. Tento cíl byl splněn a zpracování nových ţádostí je rutinně provozováno od roku Není ovšem ještě dosaţeno komplexního řešení, které zahrnuje i pořizování ţádostí o důchod se zahraničním prvkem a návaznost na projekt SDD a NPD.V průběhu roku 2009 byly realizovány úpravy týkající se legislativně právních změn (parametrické změny), dále prioritní poţadavky vyplývající z rutinního provozu aplikace a nové řešení statistik prostřednictvím technologie SAP BW (SAP Business Information Warehouse) Registr pojištěnců průřezový projekt pro všechny agendy ČSSZ (subsystém ISS 5.2) Ze zákona č. 155/1995 Sb., o důchodovém pojištění, zákona č. 582/1991 Sb., o organizaci a provádění sociálního zabezpečení a zákona č. 48/1997 Sb., o veřejném zdravotním pojištění eviduje ČSSZ data a spravuje rozsáhlou datovou základnu o osobách převáţné části populace ČR, kterým poskytuje sluţby v těchto oblastech. Charakter činnosti ČSSZ vyţaduje, aby tato uchovávaná citlivá data a osobní údaje byly průběţně aktualizovány a věrohodné. Tyto informace jsou doplňujícími informacemi k základním registrům veřejné správy a dalším celostátním registrům a relevantním evidencím a ČSSZ má zákonnou povinnost tato data poskytovat oprávněným subjektům veřejné správy. Zároveň tyto evidence vyuţívá a spolupracuje zejména s evidencí obyvatel a vyuţívá data z ţivnostenského rejstříku a dalších registrů. Registr se skládá ze dvou autonomních částí a je proto realizován v rámci dvou samostatných projektů (Kmenové evidence 2 (KE2) a Pojistné vztahy (PPV, VZT)). Jedná se o jednu z nejpodstatnějších činností vedoucích k naplnění strategického cíle ČSSZ centralizace informačního systému. Data z registru jsou vyuţívána všemi novými centrálními aplikacemi. Jeho funkčnost, aktuálnost a úplnost je základní podmínkou pro jejich úspěšné fungování. V současné době jsou KE2 i VZT rutinně provozovány v celé ČSSZ. Cílem projektů je poskytnout datovou základnu pro provádění všech centralizovaných agend ČSSZ. Oba projekty běţí jiţ několik let a byly vyvolány poţadavky Transformačních projektů na obsah centrálních registrů. Jejich dlouhodobé cíle jsou zejména: přizpůsobení datového modelu novým poţadavkům, které kladou na centrální registry zejména nové centralizované aplikace (např. DMS, POJ, NEM, ZDD, EXK atd.) a zabezpečení jejich informačních potřeb, migrace, aktualizace a čištění dat, vytvoření poţadovaných rozhraní na spolupracující systémy, zajištění konzistence dat a výkonu, zajištění reportingu pro vedení ČSSZ a MPSV, zajištění přípravy pro migraci na JIM (Jednotné inkasní místo) a KIM (Kontrolní integrované místo), zajištění programové podpory pro pořizování přihlášek/odhlášek a pro správu pojistných vztahů. V oblasti Kmenových evidencí byly v roce 2009 realizovány následující činnosti. Do provozu byla nasazena nová aplikace ZSS pro správu zařízení sociálních sluţeb, které byly v rámci projektu MCÚ namigrovány do KE. Dále byla zprovozněna nová sluţba IPK (Interní podnět KE), která umoţňuje jakékoli aplikaci zaslat do aplikace opravu dat v KE (UI44) podnět pro aktualizaci identifikačních údajů osob. Tuto sluţbu zatím vyuţívá aplikace EXK. Aplikace TCL byla rozšířena o nové funkcionality vytváření reportů pro plnění informační povinnosti externím subjektům (zejm. soudům a Policii ČR), vytváření reportů pro 79

80 provádění kontrolní činnosti, specifickou funkcionalitu zpracování informací pro zdravotní pojišťovny a funkcionalitu vytváření statistických výstupů pro MPSV a ČSÚ. Byla realizována reimplementace aplikace CRO15 do aplikace CRZ pro zpracování přírůstkových souborů patnáctiletých získávaných z Centrálního registru obyvatel MVČR. V rámci podpory uţivatelů probíhaly rutinní úpravy a opravy aplikací KE - UI44, UI08, TCL, CRZ. Oblast Kmenových evidencí (KE2) jako součást centrálních registrů poskytuje údaje o účastnících sociálního pojištění (tj. základní identifikátory a atributy osob a organizací, údaje o spojeních, registracích apod.). Účastníky pojištění se rozumí zejména zaměstnavatelé, zaměstnanci a OSVČ. V souladu se schválenou architekturou IS ČSSZ ostatní věcné oblasti evidují účastníky pojištění pouze jako vazební klíče do KE. Kmenové evidence jsou tvořeny databázovým schématem, aplikačním rozhraním SI2 a DRCSI2 rozhraním. Rozhraní SI2 je základním komunikačním rozhraním KE a jeho prostřednictvím přistupují do databáze kmenových evidencí nové centrální aplikace.. Rozhraní DRCSI2 zabezpečuje přístup do KE starým aplikacím, zejména důchodových agend. RPL je aplikační část slouţící pro registr plátců a práci s variabilním symbolem. Kmenové evidence mají následující uţivatelské aplikace UI44 pro správu (editaci) dat KE specializovaným útvarem, TCL jako kukátko do KE (a VZT) pro široký okruh uţivatelů, CRZ pro zpracování souborů dat předávaných CRO MVČR a ZUM pro zpracování souborů z MAC a AMAC s daty o úmrtí. KLIENT APLIKAČNÍ ČÁST AAA proxy ZUM /tlustý klient.net/ AAA Okresní aplikace AKEO_OSVC CRZ /tlustý klient.net/ WRC /tenký klient / TCL Klient /tenký klient/ KL I/OPicture KE2 UI44 UI44 /tlustý klient.net/ BAM ZDV Legenda Datum poslední aktualizace Datum vytvoření Pořadové číslo (verze) Stav v produkci Nasazeno Přímé volání WS Vazba přes WF Přímý zápis/čtení do DB DMS POJ EXK VYP NEM ZDD AKE AKECT AKTUALIZEKE KE100 SI2 RPL DRC TC2 Staré aplikace (UI45-INP, ZOCR,OCR T23, T9, T4,T5,T10,T11,DIGI-UIP, UI42, WORK05, WORK09,ZVS,DOPOJ,DIGI- OSOKR,DIGI-UP, Pece, PDUCH, DRC01, INP02, INP03. UIW) 10.6 KE019 KE116 VZT08 VZT TC1 Staré aplikace (VZT-Malorg, KL, CRO15, VPO, K116, K1160, ZPO, ZPO-II) 10.6 Staré aplikace (pořizovací linka, DOCR) 10.6 Legenda IPA1 KEVAKT KEVDA INP1 Klient Aplikační část KEVDB KEVAPR DRC Aktualni Serverová část aplikace Aplikační rozhraní DB schema Databáze Vnější aplikace / oblasti Obrázek 39 - I/O Picture KE2 Oblast Správy pojistných vztahů (aplikace VZT) zahrnuje agendu zaměstnavatelů, zaměstnanců, NP OSVČ, zahraničních zaměstnanců. V lednu 2009 byla do provozu nasazena nová verze aplikace VZT, která obsahovala rozsáhlé úpravy pro novou legislativu platnou od V rámci těchto změn proběhla také migrace do nové datové struktury a přechod na desetimístný variabilní symbol (VS). V průběhu roku 2009 byly realizovány podstatné úpravy aplikace inicializované uţivateli na základě praktických zkušeností. Vedle toho probíhaly činnosti směřující ke zvýšení kvality dat. V rámci podpory uţivatelů probíhaly rutinní úpravy a opravy aplikace VZT. APV VZT poskytuje ČSSZ aplikační podporu pro centralizovanou správu pojistných vztahů. Od 01/2009 je v produkčním prostředí nasazeno APV VZT08, nahrazující předchozí APV VZT07. VZT08 v současné době obsahuje funkcionalitu těchto modulů : zaměstnavatel, zaměstnanec, zahraniční zaměstnanec, NP OSVČ a interní podnět fyzická osoba. 80

81 IS VZT je realizován ve vícevrstvé architektuře s daty uloţenými v centrálním datovém úloţišti a aplikační logikou na aplikačních serverech v centrální aplikační farmě. Komunikace mezi systémem a jeho okolím je zabezpečena pomocí webových sluţeb. Vazba na datovou vrstvu je realizována přímým zápisem/čtením do databáze DBVZT. Koncoví uţivatelé komunikují se serverem pomocí tlustého klienta, instalovaného na jednotlivých klientských počítačích uţivatelů. Toto připojení je realizováno z oblastních poboček ČSSZ anebo lokálně z centrálního pracoviště prostřednictvím protokolu HTTP/HTTPS. I/OPicture VZT08 Datum poslední aktualizace Datum vytvoření KLIENT VZT Klient /tlustý klient.net/ UI08 /tlustý klient.net/ Pořadové číslo (verze) Stav v produkci 2 od AAA APLIKAČNÍ ČÁST BAM KL NEM POJ DMS ZDV Winws WebServices ZM VZTInterface TC1 OSSZService KOCIN Legenda Klient KE2 RPL SI2 UI44 TC2 TCL Aplikační část Serverová část aplikace Aplikační rozhraní DATA IPA 1 DB schema Databáze VZT08 Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis/čtení do DB Obrázek 40 I/O Picture VZT08 Vzhledem ke svému charakteru se k registrům zařazuje i Projekt zavedení desetimístného variabilního symbolu. Začátkem roku 2009 bylo provedeno generování nových desetimístných variabilních symbolů (VS10) pro zaměstnavatele (dříve organizace a malé organizace) a jejich mzdové účtárny. Nové VS10 byly přiděleny na základě rozhodnutí PV č.114 z roku 2006 z důvodu vyloučení duplicit v identifikačních údajích plátců pojistného z důvodu centralizace dat a nasazení centrální aplikace POJ. Uvedená změna se promítla do nových centrálních aplikací a vyţádala si úpravu více neţ 20 aplikací stávajících. Další rozvoj KE bude zaměřen na následující oblasti: o Zvyšování kvality dat, jejich kontrola a konsolidace. o Redesign aplikace TCL. Vzhledem k četným změnám datových modelů KE i VZT neodráţí stávající podoba TCL skutečnost a potřeby uţivatelů. o Integrace a realizace vazeb na další subsystémy. Jedná se zejména o systém SQ100, na kterém je realizována IT podpora důchodových agend a která stále z větší části disponuje vlastní údajovou základnou. Dalším systémem je napojení podpory úrazového pojištění v případ její realizace. o Vytvoření vazby centrálních registrů ČSSZ na základní registry ve smyslu zákona č. 111/2009 Sb. a souvisejících právních předpisů. Další rozvoj VZT se předpokládá v následujících oblastech: o Optimalizace a zdokonalení aplikace VZT včetně zvyšování kvality dat, jejich kontroly a konsolidace. o Úpravy VZT vyvolané v souvislosti s centralizací agend důchodového pojištění OSVČ. Úpravy bude nutné sladit zejména s postupem úprav v oblasti výběru pojistného. o Vytvoření nové IT podpory evidence podání ELDP s napojením na centrální registry ČSSZ pro účely kontroly plnění zákonné povinnosti zaměstnavatelů. Jedná se o převedení funkcionality z lokální 81

82 o o o aplikace s vyuţitím centralizovaných dat o všech zaměstnancích a zaměstnavatelích, která nemohou být z historických důvodů v lokálních aplikacích zabezpečena. Úpravy VZT vyvolané v souvislosti s centralizací agendy posuzování dob péče o osobu blízkou. Úpravy VZT vyvolané v souvislosti s centralizací agend DOPOJ (dobrovolná účast na důchodovém pojištění). Úpravy bude nutné sladit zejména s postupem úprav v oblasti výběru pojistného. Vytvoření vazby centrálních registrů ČSSZ na základní registry ve smyslu zákona č. 111/2009 Sb. a souvisejících právních předpisů. Další rozvoj aplikace VPO1 (aplikace pro správu agendy určování příslušnosti k právním předpisům) se předpokládá zejména v úpravách vyvolaných napojením na systém EESSI a v souvislosti s přípravou a zahájením elektronické výměny dat mezi evropskými nositeli sociálního zabezpečení podle Nařízení (ES) 883/2004 a jeho prováděcího nařízení. Případná alokace finančních prostředků bude do těchto oblastí: Kmenové evidence a pojistné vztahy Evidence volného pohybu osob. Ostatní centrální registry. Oblast Subsystém Název 5 Správa údajové základny Projekt 5.1 Informační subsystém důchodových agend Evidence nárokových podkladů v rozsahu základních informací identifikujících občana, druh a délku jeho zaměstnání, dosaţených výdělků a základních informací o zaměstnavatelské organizaci, správa nárokových podkladů. Subsystémy pro digitalizaci dokumentů digitalizace spisové evidence, digi evidencí OSSZ, digitalizace nově příchozích podnětů, digitalizace věcné spisovny, vytěţování datových vět a jejich kontrola komponentou JDV01, Resp. subsystémem Kontrolní linky. doba přechodu na nový systém činí 4 roky 5.2 Informační subsystém Registr pojištěnců (Kmenové evidence), plátců pojištění. rutinně provozováno 5.3 Informační subsystém Registr pojistných vztahů (VZT). rutinně provozováno 3.6 Oblast 6 Ekonomické subsystémy Projekt - Další rozvoj ekonomického informačního systému (EKIS - subsystém ISS 6.1) Přípravná fáze projektu byla zahájena v letech , kdy byl vytvořen návrh optimalizace organizačního uspořádání ČSSZ a návrh nového ekonomického informačního systému EKIS v rámci programu ISŘS - integrovaného systému řízení a správy. Cílem projektu EKIS bylo zajišťování ekonomických činností při přechodu na nové územní uspořádání, zefektivnění ekonomických procesů a úspora nákladů a centralizace finančního řízení. Významným přínosem EKIS byla definice jednotné struktury účetních dat. V oblasti programování účetnictví centrálního pojistného se v současné době dokončují vazby mezi programy POJ a SAP. Dále dochází k rozšíření funkcionality modulu evidence majetku, která se týká především dalšího vyuţití terminálů pro snímání čárového kódu a zahrnuje rozšíření funkcionality v oblasti inventarizace dlouhodobého majetku pomocí čárového kódu a v oblasti evidence dlouhodobého majetku. K dalšímu rozvoji projektu dojde v oblasti personalistiky a platů (HR). V následujících letech bude rozšiřována oblast vzdělávání, FKSP a penzijního připojištění. Počítá se s tím, ţe bude do modulu Controlling implementována metodika sledování nákladů na projekty IKT. Další rozvoj aplikace pro rok 2010: 82

83 Oblast ekonomicko správních agend: V této oblasti byly v průběhu roku 2009 zajišťovány následující úkoly: EKIS - v rámci implementace a provozování EKIS byla zabezpečena správa číselníků, uţivatelských účtů, přístupových oprávnění do systému a další potřebná součinnost v oblasti SLA. Zabezpečení komunikace s AAA portálem a dalšími navazujícími subsystémy IIS. Zabezpečení sběru a předávání dat pro subsystém o platech pro zaměstnance státní správy realizovaného na základě zákona č. 262/2006 Sb. Zákoníku práce. Návrh moţností v oblasti nastavení základních parametrů a procesů autorizace uţivatelů z hlediska bezpečnosti systému SAP R/3, který obsahuje chráněná majetková, finanční a osobní data a informace ČSSZ. Účast na přípravě studie a realizačního návrhu projektu výhledové integrace SAP do AAA. ASW pro objednávání stravenek (Sodexho Pass) - údrţba funkčnosti v podmínkách IS SAP. Mzdy UNICOS zabezpečení funkčnosti dosovské aplikace v podmínkách stanovených pro provoz aplikací v ČSSZ a současně i daným zákonným normativem - povinná archivace mzdových a personálních dat za období od roku 1993, bez technické a servisní podpory. Oblast Subsystém Název Projekt 6 Ekonomické subsystémy 6.1 Informační subsystém ekonomických agend (EKIS) Evidence údajů správního účetnictví a dávek sociálního pojištění včetně detailní účetní informace v členění podle účtů a rozpočtové skladby, s moţností podrobného účetního a manaţerského sledování. Dále je sem zahrnut modul Human Resources (HR) aplikace SAP. Rutinně provozován outsorsing, rozvoj. 6.2 Podpůrné subsystémy pro Zpracování statistik Rutinně provozováno rozvoj. 3.7 Oblast 7 - Průřezové subsystémy Workflow Platforma pro řízení a kontrolu procesů a služeb (PŘKPS - Posunovač) - Subsystém 7.1 Cílem tohoto subsystému je převést současný systém aplikačního vybavení na optimálnější a vhodnější pro přechod na architekturu sluţeb. Subsystém PŘKPS vychází z koncepce oblasti IN a ze zkušeností s platformou BizTalk v ČSSZ. Dosavadní (výchozí) stav lze znázornit následujícím obrázkem: 83

84 Obrázek 41 Současný stav v řešení oblasti IN na principu PŘKPS Zelená oblast znázorňuje vyuţití platformy BizTalk, a modrá oblast znázorňuje jiţ nasazení platformy PŘKPS. Tento model ukazuje, ţe je aplikovatelný na celý IIS, dovoluje jeho postupnou realizaci aţ po dosaţení stavu, který znázorňuje obrázek Jedním z identifikovaných problémů systému bylo minimální mnoţství sdílených komponent daných systémů oblasti IN, který vedl k opakovanému vývoji stejné funkcionality v rámci jednotlivých aplikací. Funkce, které jsou vyuţívány několika aplikacemi (zejména formální, logické a kontextové kontroly), by měly být naprogramovány jako samostatná komponenta s definovaným rozhraním volatelná přímo jednotlivými aplikacemi. Výchozí stav systémů na ČSSZ byl takový, ţe integrační logika je zahrnuta částečně v aplikacích (systém DMS posílá data do ZDV, ZDV připravuje export pro KL, DIS systém obsahuje předávací logiku pro přenos do okresních aplikací (MALORG) atd.). Bylo proto rozhodnuto vytvořit nástroj pro řízení a správu této komunikace a průběhu procesů. Řešení pomocí centrálního PŘKPS) přináší následující výhody: Aplikace specializované na vlastní zpracování, komunikační a procesní logika oddělená. Moţnost přepojovat zpracování, zapojovat nové aplikace, udrţitelná integrace. Moţnost paralelizace procesů zpracování a procesů monitorování. Je zaloţeno na dvou funkcionalitách: Platforma pro řízení a sledování komunikace mezi aplikacemi (stavový automat s databází) vyuţívá principy sběrnicové komunikace procesy předávání informací implementované na PŘKPS poskytují moţnosti pro řízení provozu (např. jen povolené přechody mezi stavy!) vyuţívá fronty pro poţadavky; umoţňují odstavit jednu aplikaci, ostatní mohou běţet odděluje komunikační hranice aplikací, zviditelňuje vazby a umoţňuje volnější závislosti mezi aplikacemi Detailní monitorování stavu zpracování (monitorovací DB) napojení mechanismů monitorování přechodů mezi stavy monitorovací část PŘKPS je moţné vyuţít i samostatně bez řídící části pro sledování stavu procesů, takţe zabudováním odesílání těchto informací do jednotlivých aplikací je moţné získat zviditelnění procesu a dále vyuţít hotové sady reportů PŘKPS reportovací část vyuţívá SSRS (MS SQL Server Reporting Services) a kukátko WFS. ISDS CSSZ KE2 DMS NEM DSS DSS Tečkovaně = vize -navržený systém Další aplikace v APP ZDV VYP INNP PŘKPS W FS Pr Reporting Services 84 Komunikační logika a business logika Služby stavové DSS databáze Řízení publikování a verzování služeb PŘKPS (MSE) Komunikační logika a business logika NEM Orchestrace POJ Orchestrace a WS a WS oh líž A A A ECD DIS Orchestrace a WS

85 Obrázek 42 - Architektura PŘKPS Platforma pro řízení a kontrolu procesů a SOA sluţeb - se tedy navrhuje jako optimální řešení předávání poloţek pomocí Platformy pro řízení a kontrolu procesů a SOA sluţeb (PŘKPS) oblasti IN, která je kromě této základní role schopna poskytovat aplikacím a sluţbám v oblasti IN řadu dalších doplňkových sluţeb usnadňujících zejména monitorování a vyhodnocování průběhu zpracování. Implementace PŘKPS zároveň umoţní reálné oddělení těsných vzájemných vazeb jednotlivých aplikací, které přesuny dat a předávání informací řeší i na bázi peer-to-peer komunikace. Tento způsob předávání informací byl identifikován jako jedna z klíčových příčin problémů oblasti IN. Moţnost iterativního vývoje sběrnice PŘKPS s postupným zapojováním dalších aplikací a systémů bez nutnosti nasazení celého systému najednou. - Aplikace budou nadále řešit specializované úkoly (evidence, ukládání, zpracování (OCR, rozšifrování), ale jejich vzájemná komunikace bude probíhat přes fronty a sběrnici. Zprávy zasílané přes sběrnici budou zprávy o výsledku zpracování v konkrétní aplikaci, nikoliv poţadavky na konkrétní aplikaci ( další v řadě ). PŘKPS bude řídit, v kterých případech tato zpráva vyţaduje změnu stavu (a v takovém případě sestaví zprávu pro rozhraní stavové DB a zašle ji). Procesy zpracování budou definovány jako procesy PŘKPS, které propojují specializované funkce aplikací. Kromě zpráv o výsledku zpracování mohou aplikace vyhazovat události zasílat na sběrnici informace o průchodu aplikačního zpracování definovanými body. PŘKPS bude tyto informace vyhodnocovat a rozhodovat o tom, zda tato zpráva vyţaduje změnu stavu, případně zda vyţaduje notifikaci dalšího systému či aplikace. (z jistého úhlu pohledu je výsledek zpracování také událost). Pro kaţdou takovou událost provede PŘKPS záznam do monitorovacího systému (kde budou sledovány časové informace), coţ umoţní vyhodnocování výkonu a efektivity jednotlivých procesů. Aplikace s jednoduchým či monolitickým zpracováním, či aplikace jiţ hotové, nebude nutné předělávat, pouze nebudou poskytovat podrobné informace o průběhu vnitřního zpracování. Tyto funkce do nich mohou být dodány v některé z dalších fází jejich vývoje. Komunikace přes sběrnici PŘKPS přináší moţnosti definování kontrolních bodů právě v průchodech touto sběrnicí, coţ by přineslo moţnosti definování a úprav monitorování procesů napříč aplikacemi, poţadované změny by v některých případech nevyţadovaly zásah do jednotlivých aplikací. Navrţené řešení je jiţ zčásti implementováno a prokazuje svoji schopnost dalšího rozvoje a počítá se s ním jako s nosným v projekteu Rozhraní pro komunikaci ČSSZ s klienty ESS - Elektronická spisová služba Principy správy dokumentů, které jsme si jiţ zvykli v praxi implementovat a pouţívat dostaly v roce 2009 nový a zásadní impulz. Nové zákony a novelizace existujících právních norem přinášejí nové povinnosti a nové moţnosti při správě dokumentů a vyuţívání elektronických dokumentů. Nejzásadnější změny jsou definovány následujícími zákonnými normami: Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů; Zákon č. 190/2009 Sb., kterým je novelizován zákon č. 499/2004 Sb., o archivnictví a spisové sluţbě; V souvislosti s výše uvedenou legislativou musí kaţdá organizace důvěryhodně ukládat elektronické dokumenty přijaté nebo odeslané přes systém datových schránek. Dále tato legislativa rovněţ ukládá povinnost vést spisovou sluţbu v elektronické podobě v elektronických systémech spisové sluţby. Tato zásadní změna si vyţádá revizi stávajících postupů práce s dokumenty. Jedním z důvodů této revize jsou nové povinnosti vyplývající ze zavedení informačního systému datových schránek (ISDS) pro komunikaci se státní správou a potřeba identifikovat dopady těchto změn na stávající systémy evidence a komunikace. Dalším důvodem je revize stávajících dokumentově orientovaných procesů z pohledu vyuţití nových technologií při pouţívání elektronických dokumentů. Novela zákona č. 499/2004 Sb., Zákon o archivnictví a spisové sluţbě, chápe zcela jinak pojem "spisová sluţba". Dříve se pod tímto pojmem chápalo pouhé vedení podacího deníku, kam se přidávaly informace o zpracování, přičemţ SW řešení nebylo podmínkou. 85

86 Dle nového pojetí spisová sluţba řídí procesy zpracování podání a vypravení bez ohledu na to, jakým kanálem podání došla či byla vypravena, resp. v jaké podobě tato podání jsou (listinná či elektronická). Vzhledem ke komplexnímu pojetí spisové sluţby (evidence metadat jak listinných, tak i elektronických dokumentů a navíc i dat elektronických dokumentů) je nutné, aby spisová sluţba byla realizována jako softwarové řešení s příslušnými interními a externími rozhraními. Proto takovou spisovou sluţbu nazýváme ESS. Hlavním cílem implementace navrhovaného řešení je tedy vyřešení evidence, zpracování a uchování elektronických dokumentů došlých a odesílaných systémem datových schránek. Kromě toho umoţní elektronická spisová sluţba i evidenci a zpracování listinných dokumentů a dokumentů přijatých em. Sjednocení práce s dokumenty přicházejících do ČSSZ různými komunikačními kanály (datové schránky, listinná podání, ) a automatizace těchto prací povede k celkovému sníţení nákladů na tuto činnost Datová integrace DMS (subsystém IIS 7.3) Současný stav v aplikaci DMS Systém správy dokumentů DMS (Document management system) je univerzální systém pro ukládání dokumentů a k nim příslušných metadat. Sluţby poskytuje ostatním aplikacím a systémům. V oblasti IN slouţí pro evidenci vstupujících dokladů podání respektive jejich součástí. Pro oblast IN a oblast zpracování poskytuje funkce pro uloţení, klasifikaci, vyhledání dokumentů, řízení přístupu k nim z pohledu výlučných úprav (check-out/check-in),přístupu na základě řízeného oprávnění, verzování (verzování image není v současné době v DMS zapnuto a zatím se o něm ani neuvaţuje, změny metadat jsou řešeny zápisem do historie) a další. Globálním cílem Projektu DMS je podpořit elektronizaci ČSSZ a přejít na práci s vyuţitím elektronických dokumentů namísto papírových, coţ umoţní sdílení dokumentů více pracovišti bez nutnosti vytvářet kopie a tím zefektivnění práce. Z aplikačního hlediska byla nad platformou DMS v rutinním provozu spuštěna aplikace ZDD pro ţádosti o důchodové pojištění, provedeno propojení se systémem VZT a zahájeno nahrávání hromadných seznamů z OSSZ (projekt DIG). V současné době je platforma DMS rozšířena na všechna pracoviště ČSSZ a je připravena pro postupné evidování vstupních dokumentů dalších agend. Dokončuje se transfer platformy do cílové architektury v aplikační vrstvě a byla realizována první etapa přesunu pod AAA portál a realizuje se druhá etapy integrace. Související projekt DIS - Tímto projektem bylo vybudováno rozhraní mezi PVS a ČSSZ. S dalšími vzrůstajícími nároky na počet zpracovávaných podání co do typu i počtu vzrůstají také nároky na HW základnu uvedeného systému - bylo rozhodnuto přesunout systém DIS na nově vybudovaný geocluster pro BizTalk systém, který svojí robustností podpoří provoz DISu. Tento přesun byl realizován. Některé aplikace ukládají data do DMS a poté přímo do úloţiště agendových aplikací. Tento způsob zpracování vynucuje proprietární monitorování procesu zpracování a proprietární vytváření statistik atd., proces je monolitický (proces není modulární, nelze jej snadno rozšiřovat nebo upravovat), integrace dalších existujících aplikací s takovým systémem je moţná pouze neudrţitelným způsobem kaţdý s kaţdým. Je nutné do budoucna řešit řízením zpracování přes sběrnici, coţ přinese řiditelnou integraci, modulární systém s lepšími moţnostmi zapojení dalších aplikací a s moţností omezení dopadu změn jedné aplikace. DMS (dokument management system) je systém, který zabezpečuje činnosti související s přijímáním, zpracováváním, vydáváním a ukládáním papírových a elektronických dokumentů včetně zabezpečení jejich oběhu, které mohou ostatní oblasti, resp. jejich uţivatelé, vyuţívat. Přitom ostatními oblastmi jsou míněny především odborné agendy v podobě aplikačních a datových systémů, které například spravují základní kmenová data pojištěnců a organizací, realizují výpočty a datové transakce atd. Kaţdý dokument je v DMS uloţen jako objekt s povinnou strukturovanou částí tzv. profilem (metadata) a vlastním souborem dokumentu (tělo dokumentu). Tělo dokumentu představuje obecně binární soubor v libovolném formátu (např.:.doc,.xls,.pdf,.dgw,.xml, html,.tif a další). Jeden dokument můţe obsahovat jedno nebo více těl. Kromě toho má kaţdý dokument svou historii, nastavení přístupových práv a další informace. Systém DMS má programové rozhraní, které umoţňuje propojení mezi ním a ostatními subsystémy a aplikacemi. Základní funkce tohoto rozhraní: vloţení dokumentu, včetně jeho metadat (profilu), vyhledání dokumentu/dokumentů podle hodnot atributů, získání dokumentu a jeho metadat pro jeho zobrazení, tisk, přehrání, (obecně prezentaci), změna metadat určitého dokumentu, změna souboru s dokumentem (těla dokumentu). V starších materiálech se lze setkat také s označením DMA (dokument management archiv), který lze z logického pohledu ztotoţnit s DMS. 86

87 ZDD (evidence a zpracování ţádosti o dávku důchodového pojištění) bývá v některých případech vyčleňováno jako samostatná aplikace, nicméně ve skutečnosti se jedná pouze o tenkého klienta DMS, který je funkčně rozsáhlejší. KLIENT Aktivní klient /tenký klient/ Univerzální klient /tenký klient/ I/OPicture DMS Podatelna /tenký klient/ ZDD /tenký klient/ Administrační klient DMS /tenký klient/ Datum poslední aktualizace Datum vytvoření Pořadové číslo (verze) Stav v produkci nasazeno AAA AAA APLIKAČNÍ ČÁST CSSZAdminClient KE2 CSSZPodatelna WebArchive API DMS ZDV NEM Staré aplikace (DIGI, OCR, T11) KE2 ZDD DMSViewer Image server ZDV CSSZActiveClient RM VZT POJ KL Legenda Klient Aplikační část Serverová část aplikace Aplikační rozhraní DATA DMA DMAP1 DMAP2 DB schema Databáze Vnější aplikace / oblasti SAN Diskové pole Přímé volání Vazba přes WF Přímý zápis do/čtení z DB Obrázek 43 I/O Picture DMS Projekt MIGRACE DMS Česká správa sociálního zabezpečení (ČSSZ) rutinně provozuje od roku 2006 systém Document Management Systém. Tento systém zabezpečuje ukládání a správu digitalizovaných dokumentů na ČSSZ. S nárůstem počtu agend, které do DMS ukládají, se zvyšují poţadavky na systém a počet uţivatelů. Tento vývoj si ţádá posílení a optimalizaci celého systému. Řešením této situace je migrace systému DMS na novou HW platformu. Hlavní důvody pro zahájení a realizaci migrace systému DMS: Ukončení podpory IBM Content Manager hlavní produkt DMS: Klíčový produkt, na kterém je postaveno řešení systému DMS na ČSSZ - IBM DB2 Content Manager Enterprise Edition, zajišťuje sluţby centrálního (Ústředí) a lokálního (ÚP) ukládání a vyhledávání dokumentů, práci s metadaty, řízení přístupu k dokumentům apod. Ukončení podpory verze 8.3 je plánováno na 30.září Po ukončení podpory produktu IBM Content Manager dojde k zastavení technické podpory produktu IBM CM verze 8.3 V případě problémů s Content Managerem nebo migrace CM na vyšší verzi, nebude mít DMS od 1.října 2010 řešitele. IBM bude podporovat pouze verzi 8.4. V tomto případě se jeví jako jediná moţnost povýšení verze IBM CM na verzi 8.4., a to s termínem do Sjednocení operačního systému pro databázové servery na ČSSZ Podstatnou výhodou přechodu na OS AIX je sjednocení operačních systémů na databázových serverech ČSSZ (DÚ). Tím se zjednoduší správa databázových serverů (obsluhu stačí mít proškolenu na méně OS). Sjednocený OS umoţní větší flexibilitu pro přesun různých databází mezi HW, který má či v budoucnu bude mít ČSSZ k dispozici. Např. vyuţívání starších a méně výkonných strojů vyřazovaných z PP na posílení TP a IP v různých kombinacích. Lepší moţnosti Oracle 10g 87

88 Oracle 10g poskytuje lepší moţnosti pro spravování této databáze neţ předchozí verze, a to zejména v oblasti logování systému, vyuţití RAC nebo reportů AWR + ADDM. Opět je výhodou, ţe stačí mít obsluhu proškolenu pouze na vyšší verzi systému Oracle. Ukončení podpory Oracle 9i databáze DMS Databáze DMS v současnosti vyuţívá produkt Oracle 9i s posledním patch-setem U tohoto produktu standardní podpora jiţ skončila 31.července 2007 (URL: Nyní vyuţíváme extra placenou rozšířenou podporu produktu Oracle 9i, zaplacenou do 30. července Premier Support Ends: do 31-července-2007 (standardní podpora). Extended Support Ends: do 30-července-2010 (extra placená rozšířená podpora). Standardní Oracle podpora uţ není přes 31 měsíců a poslední dostupný patch byl před 34 měsíci. V případě, ţe neproběhne migrace DMS na Oracle 10g, předpokládá se, ţe firma Oracle další extra placenou podporu ČSSZ neposkytne. Jedinou moţností v tomto případě je přechod na produkt Oracle 10g. Výkonnostní problémy stroje Sarcis 8: V současné době je databázová platforma DMS provozována na serverech Sarcis 7 a Sarcis 8. Sarcis 8, který slouţí pro ukládání image v DMS, ţádostí o důchod nebo ukládání agendy DIS, měl v poslední době problémy s výkonem. Tyto problémy však byly vyřešeny a provozování subsystému bylo stabilizováno. V případě, ţe nebude varianta migrace vybrána, je potřeba situaci s databázovými servery DMS vyřešit. Pro řešení migrace jsou dále uvaţovány tři varianty: Migrace DMS na nové datové úloţiště, vyuţití uvolňovaných serverů p570 (aix 01 a aix02). Přesun na nový server SQ (příliš inovativní). Posílení stávajících serverů Sarcis7,8. (Servery jsou poměrně staré, sloţitější údrţba neţ, kdyţ bude přesunuto na nové DÚ). Přesun aplikace na staré AIX servery a postupně připravit inovaci. Nejvýhodnější a zároveň koncepční je varianta 1, která zahrnuje následující změny systému DMS: změna HW prostředků ze stávajících serverů sarcis7 a sarcis8 na servery tvořící CDÚ (OS AIX), s tím související změna operačního systému, na kterém je DB vrstva DMS provozována (ze stávajícího SunOS na OS AIX), změna verze DB Oracle ze stávající verze na , změna verze produktu IBM DB2 Content Manager ze stávající verze 8.3 Fix Pack 10 na Další důvody pro zahájení migrace na platformu AIX Sjednocení zpracování v CDÚ na jednotnou platformu řady serverů IBM série P. DMS bude rozprostřeno po obou lokalitách, omezíme nutnost odstávky. Převodem na servery P570 bude moţno uvolnit a vyřadit z provozu servery sarcis 5 8., coţ nám uspoří provozní náklady a zároveň uvolní prostory pro eventuelní instalace nové techniky. Je připraven prostor pro eventuelní zvýšení výkonu, zamezíme zbytečnému vynakládání provozních prostředků, které jsou v současnosti silně omezené. V případě, ţe se vybere varianta 1, servery DMS poběţí na výkonnějších strojích na CDÚ. Zároveň budou vyřešeny podpory obou produktů Oracle i IBM Content Manager. V opačném případě, kdy DMS nebude moţné přesunout na nový HW, je pravděpodobné, ţe se budeme potýkat se značnými výkonnostními problémy a budeme provozovat systém bez podpory od firem IBM a Oracle. Migrace systému DMS se dotýká především jeho databázové vrstvy, a to konkrétně jejího přesunu na výkonnější a dlouhodobě stabilnější HW platformu. Dopady migrace databázové vrstvy nutně vyvolají změny v aplikační vrstvě DMS a také úpravy některých částí instalace systému na všech ÚP ČSSZ. Z toho vyplývá, ţe na migraci DMS se bude podílet několik skupin pracovníků a firem. Nevýhody migrace na servery p570: Při posuzování návrhu migrace byla vznesena připomínka, ţe přesun nebude proveden na nový HW. Při odhadované ţivotnosti HW, která je cca 5 6 let, lze předpokládat, ţe bude nutné systém DMS přesunout do cca 3 let na nový HW. Vzhledem k tomu, ţe pravděpodobně půjde rovněţ OS AIX bude moţné přesun uskutečnit během víkendové odstávky. 88

89 3.7.4 Elektronický zaručený archiv ZEA V současné době je v ČSSZ implementován systém DMS, který ukládá a spravuje digitalizované a elektronické dokumenty. V Document Management System je cca 25 miliónů záznamů-dokumentů. Papírové dokumenty jsou digitalizovány na více neţ 200 skenovacích pracovištích instalovaných na všech okresních a krajských správách (OSSZ, KSSZ, MSSZ Brno, PSSZ). Na jednotlivých správách jsou nainstalovány i dokumentové cache pro zrychlení přístupu lokálních uţivatelů k uloţeným dokumentům. Systém DMS se skládá ze dvou základních částí: Resource Manager spravuje uloţené dokumenty, zpřístupňuje je uţivatelům a zajišťuje replikace mezi ústředím ČSSZ a dokumentovými cache na OSSZ. Library Server centrálně spravuje všechna metadata uloţených dokumentů. Na skenovacích pracovištích je instalován skenovací SW Kodak Capture (ústředí ČSSZ) a QuickScan (ostatní správy). Naskenované dokumenty jsou v rámci skenovacího procesu opatřeny základními indexy (metadata dokumentu v samostatném XML souboru). Tyto soubory jsou přeneseny do centrálního úloţiště systému DMS. API rozhraní zajišťuje komunikaci systému DMS s okolními aplikacemi a zprostředkovává uţivatelům přístup k archivu DMS pomocí klientů Podatelna, Aktivní klient a Univerzální klient. Aby mohla ČSSZ dostát legislativním poţadavkům, musí si pořídit specializovaný software nutný pro zbudování zákonem vyţadované elektronické spisové sluţby včetně elektronické podatelny a výpravny a zaručeného elektronického archivu (ZEA). Vytvoření zaručeného elektronického archivu (ZEA) umoţní archivaci dokumentů v souladu se zákonem č. 190/2009 Sb. Vybudování ZEA by měl být jeden z prvořadých úkolů ČSSZ. V souvislosti s ukládáním dokumentů z DIS a Datových schránek do DMS se otevírá otázka zajištění důvěryhodnosti dokumentů po vypršení doby platnosti certifikátů el. podpisů a časových razítek. První takovýto případ nastane v 06/2012. Cíl navrhovaného řešení Cílem navrhovaného řešení je rozšířit stávající systém DMS v ČSSZ o prostředky, které zajistí dlouhodobou archivaci elektronických dokumentů (tj. rozšířit DMS o funkčnost Zaručeného archivu): jako prostředek dlouhodobé archivace dokumentů jsou vyuţita kvalifikovaná časová razítka, systém DMS je pro zajištění dlouhodobé archivace rozšířen o komponenty a prostředky PKI frameworku popsané obecně v kap.3, jejichţ implementace je popsána v této kapitole, elektronické dokumenty jsou po celou dobu archivace uchovávány ve validním stavu jak z pohledu dokumentů samotných, tak také z pohledu jejich elektronických podpisů/značek, jako nezpochybnitelný důkaz o autenticitě archivovaných dokumentů budou vydávány tzv. důkazní záznamy. Návrh řešení Základem navrhovaného řešení je rozšíření stávajícího systému DMS o následující funkčnost kryptografické knihovny a validační modul, které umoţní s elektronickými dokumenty a podpisy dále pracovat a zaručit jejich integritu a validitu, ukládání a správu elektronických podpisů dokumentů a časových razítek, správu certifikátů a CRL (Certificate Revocation List seznam odvolaných certifikátů), komunikace s certifikační autoritou časových razítek vytvoření a odeslání ţádosti o TS, přijetí a uloţení TS. 89

90 Obrázek 44- Rozšíření stávajícího DMS Produkt IBM Content Manager, na jehoţ bázi je stávající systém DMS zaloţený, neposkytuje pro účely dlouhodobé zaručené archivace příslušné prostředky. Proto bude nutné výše popsanou poţadovanou funkcionalitu do systému DMS doplnit. To se projeví následujícími úpravami: Rozšíření datového modelu DB, Vytvoření modulu pro ukládání a správu elektronických podpisů a časových razítek, Vytvoření modulu pro ukládání a správu certifikátů a CRL, Implementace kryptografické knihovny a validačního modulu, Vytvoření modulu pro generování důkazního záznamu. Modul pro správu elektronických podpisů a časových razítek Slouţí pro ukládání, popř. tvorbu elektronických podpisů a časových razítek a jejich dlouhodobou správu uvnitř DMS ve vazbě na příslušné uloţené dokumenty. Modul pro správu certifikátů a CRL Slouţí pro ukládání a správu certifikátů elektronických podpisů a časových razítek a kořenových certifikátů certifikačních autorit. Současně zajišťuje periodické stahování a ukládání CRL seznamů zneplatněných certifikátů od zadaných certifikačních autorit. Vyhodnocuje platnost certifikátů. Kryptografické knihovny a validační modul Pro komplexní podporu kryptografických operací v rámci systému ZEA a případně dalších návazných systémů budou implementovány speciální kryptografické knihovny zaloţené na frameworku openssl. Mezi jejich základní funkčnosti patří: vytváření a ověřování elektronicky podepsaných dokumentů, resp. elektronicky označovaných dokumentů, práce s kryptografickými zprávami, např. moţnost extrakce podpisového certifikátu ze struktury podpisu, vytvoření ţádostí o časová razítka k digitálním datům (elektronickým dokumentům, elektronicky podepsaným dokumentům), komunikace s autoritou časových razítek, ověření časového razítka ve vztahu k původním datům, která byla předmětem ţádosti, podpora pro kryptografický HW. Tyto knihovny jsou pak základem validačního modulu, který aplikuje uvedené funkce na dokumenty spravované v DMS. Důkazní záznam Důkazní záznam je soubor dat, která jsou pouţita k prokázání existence archivovaného datového objektu či skupiny archivovaných datových objektů v nezměněné formě v archivu v určitém časovém období, a u dokumentů, které jsou opatřeny externím elektronickým podpisem (tj. jiným elektronickým podpisem, neţ podpisem vytvořeným na centrálním serveru) i místo a způsob vzniku dokumentu, resp. jeho digitální formy. Důkazní záznam obsahuje archivní časová razítka generovaná během období archivace a dále další pouţitelná data pro validaci archivovaných dat, tj. příslušné certifikáty, CRL seznamy a odkazy na certifikační politiky, hashe atd. 90

91 Důkaz o existenci dokumentu v DMS v daném období bude zaloţen na důkazním záznamu, který (spolu s digitální formou pouţitých dat) umoţní soudnímu znalci ověřit deklarovaná tvrzení o existenci dokumentu v DMS po stanovené období. Dokumentace Zpracování relevantní dokumentace je nedílnou součástí implementace ZEA pro ukládání a správu digitálních dokumentů v České správě sociálního zabezpečení. Jde zejména o: Technickou dokumentaci. Bezpečnostní směrnice. Směrnice pro uţivatele certifikátů. Směrnice pro správu certifikátů a časových razítek. Objem dokumentů v DMS, který není zanedbatelným počtem, je nutné označit časovým razítkem a tím se zaručit za platnost uloţených dokumentů v archivu. Je nutné pečlivě zváţit moţnosti nabízené jednotlivými dodavateli firmami I.CA a Česká Pošta, s.p. Obecně existují dvě varianty přiřazování časových razítek pro dokumenty: Označovat časovým razítkem se budou všechny dokumenty, to znamená, kaţdý bude mít svoje vlastní časové razítko (u této varianty nabízí Česká Pošta výhodnou nabídku tzv. předplatného). Časovým razítkem se bude označovat celý seznam dokumentů. Bude označen celý seznam, který bude obsahovat např. dokumenty za celý den. Pro tento soupis dokumentů bude pouţito pouze jedno časové razítko. Pro zpracování seznamu dokumentů je potřeba vytvořit aplikaci, která nabízí potřebné funkčnosti, např.odesílání seznamu autoritě atd Plánovaná centralizace aplikace Kontrolní činnost (KOCIN) V souladu s naplňováním dlouhodobé koncepce budování IIS ČSSZ byl pro rok 2010 schválen záměr realizovat další etapu centralizace lokálních systémů OSSZ. Záměrem této etapy je centralizace APV pro podporu kontrolní činnosti OSSZ prováděné v souladu se zákony o sociálním zabezpečení a nemocenském pojištění u zaměstnavatelů. Základním předpisem pro provádění kontroly je zákon 552/1991 Sb., o státní kontrole, zvláštními zákony pak zákony o sociálním zabezpečení a nemocenském pojištění. Předmětem kontroly je ověření správnosti odvodu pojistného, plnění povinností zaměstnavatele v nemocenském pojištění a v důchodovém pojištění. Realizace bude spočívat v náhradě stávajícího APV lokálních systémů a datové i aplikační integraci agendy do centrálního IIS ČSSZ. Předmětem realizace bude datová a aplikační integrace agendy do centrálního IIS ČSSZ, tz. : Vytvoření APV pro řízení a podporu aktivit souvisejících s výkonem kontrolní činnosti OSSZ. Integrace s okolními souvisejícími subsystémy centrálního IS. Migrace dat z lokálních systémů, pouze v rozsahu informací nezbytných pro plánování a provedení prvních kontrol s podporou nového centrálního APV. Realizace bude probíhat ve dvou etapách: Etapa I pokrývá funkcionality stávající okresní aplikace a některá rozšíření. Etapa II v dalších letech pokrývá integrační části a některé poţadavky směřující ke komfortu uţivatelů. Nový centrální systém APV KOC bude poskytovat podporu v obdobném rozsahu jako stávající aplikace KOCIN lokálních systémů OSSZ. Navíc bude tento systém úzce integrován s centrálními systémy. Aplikace KOC bude plně integrována do infrastruktury informačního systému a vyuţije všechny její standardní komponenty jako AAA portál, centrální registry a rozhraní jednotlivých agend. Základní architektonický koncept je zobrazen na následujícím obrázku: 91

92 Notebook Klient WinForm Offline klient KOC Truecrypt Data Klient WinForm Offline klient Truecrypt Data Plán Příprava kontroly Asynchronní příprava kontroly Výsledky kontrol Okolní aplikace Statistiky a výstupy POJ... Vazba Plán Data Data pro kontrolu Výsledky kontrol Synchronizace offline dat Datový tok Obrázek 45 Centralizace aplikace KOCIN (KOC) Aplikace bude vytvořena na třívrstvé architektuře, kde v databázové vrstvě budou uloţena vlastní data aplikace na aplikační vrstvě bude uloţena business logika a na klientské stanici bude winform apliakace. Pro zajištění práce více kontrolorů v terénu aplikace zajistí synchronizaci připravených dat. Aplikace bude rozdělena do komponent, které budou nasazovány společně v jednom instalačním balíku na kaţdou z vrstev (klient, aplikační vrstva a databáze). Více je zřejmé z modelu nasazení, který popisuje jak rozmístění základních komponent, tak vazbu na okolní systémy. deployment Nasazení VZT KOC KLIENT Plán Kontrola Tisky KE2 «device» AAA AS KOC Kontrola Plán Příprava kontroly Provedení kontroly Zpracování výsledků Tisky INS DMS NPD POJ DB KOCDB KOC Obrázek 46 Schéma nasazení centrální aplikace KOCIN (KOC) Komponenta kontrola bude umoţňovat pro konkrétní funkcionality provádění a vyhodnocení kontroly umoţňovat práci buď v on-line reţimu (v síti ČSSZ) nebo v offline reţimu (při provádění kontroly u kontrolované organizace). Data pro offline reţim budou zabezpečena pomocí nástroje True Crypt dle Standardu PC. 92

93 3.7.6 Elektronický spis jeho koncepce a implementace Základní myšlenka elektronického dávkového spisu je zaloţena na koncepci metasystému, který k jednomu subjektu bude obsahovat informace, o všech datových větách a dokumentech uloţených v IIS ČSSZ a tyto informace bude poskytovat jako sluţbu pro aplikace, které s nimi budou pracovat. V tomto pojetí pak subsystém elektronický spis (ES) patří do oblasti průřezových subsystémů. V rámci tohoto konceptu se vyuţívá analogie k dávkovému spisu, která byla uvedena v návrhu implementace EDS. Klasický dávkový spis obsahuje spisový obal, kde se zaznamenává oběh spisu, spisovou vloţku, kde je uveden obsah spisu a jednotlivé dokumenty. Podobným způsobem byl koncipován při návrhu modulu EDS nerealizované aplikace SDD. První dvě funkcionality je vhodné vyuţít, ale data nemusí být nutně obsaţena v interním datovém úloţišti, nýbrţ mohou zůstat v databázích a v EDS mohou být pouze příslušné odkazy. V EDS tedy budou uchovávány údaje o: Subjektu, který je klientem ČSSZ. Informacích, které jsou k tomuto subjektu uloţeny v databázích ČSSZ. Záznamy o vyřizování případu a na základě jakých informací bylo rozhodnuto, uspořádané tak, ţe vţdy budou spolu s provedenou operací uloţeny i soubory odkazů na data, se kterými se pracovalo (tzv. kolekce). EDS bude koncipován tak, ţe bude umět evidovaná data v případě potřeby zobrazit a dát k dispozici odbornému pracovníkovi. Schéma ukazuje roli EDS jako koncentrátoru dat. Výše uvedený koncept bude koncipován jako obecný model pro práci v subsystému, kde je třeba mít soustředěny informace o subjektu. Proto se mavrhuje varianta, kdy bude koncipován metasystém Elektronický spis (ES) s obálkou, kde budou soustředěny kolekce EDS elektronický důchodový spis. ENS elektronický spis nemocenského pojištění. EUS elektronický spis úrazového pojištění. Elektronický dávkový spis (EDS) Vzhledem ke stupni rozpracovanosti v této oblasti se jeví jako rozumné začít s realizací konceptu s orientací právě na důchodovou oblast. EDS bude fungovat jako: nástroj sledování informací o zpracování případu, jako integrátor informací. Obrázek 47 EDS návrh rozvoje v roce

94 Oblast Subsystém Název 7 Průřezové subsystémy Projekt 7.1 Workflow PŘKPS (Posunovač) Základní část ověřována v rutinním provozu, plánuje se rozvoj 7.2 Elektronická spisová služba (ESS) Řeší projekt Elektronická podatelna a výpravna ČSSZ v návaznosti na systém datových schránek 7.3 Informační subsystém Document Management System (DMS) - evidence, zpracování, vyhledávání a ukládání informací (dokumentů a dat), řízení jejich oběhu, datová integrace. V rutinním vyuţívání, migrace na výkonnější platformu, rozvoj 7.4 Zaručený elektronický archiv V souvislosti s ukládáním dokumentů z DIS a Datových schránek do DMS se otevírá otázka zajištění důvěryhodnosti dokumentů po vypršení doby platnosti certifikátů el. podpisů a časových razítek. První takovýto případ nastane v 06/ Plánovaná centralizace aplikace Kontrolní činnost (KOCIN) Vytvoření nového centralizovaného subsystému. 7.6 Elektronický spis jeho koncepce a implementace Vytvoření nového subsystému. 3.8 Oblast 8 - Subsystémy oblasti bezpečnosti V souladu s bezpečnostní politikou ČSSZ a k zajištění bezpečnosti informací odborné útvary úseku IKT zajišťují bezpečnost provozu zařízení IKT a bezpečnost informací, přispívají k zajištění bezpečnostních cílů ČSSZ v oblasti provozu zařízení IKT a zpracování informací a stanovují rozsah a pouţití konkrétních bezpečnostních opatření ve své působnosti a odpovědnosti. V rámci těchto projektů byl zabezpečován rozvoj HW a SW platformy IKT. Mezi nejvýznamnější patří posílení centrálního datového úloţiště, posílení serverových farem, posílení zpracovatelských kapacit pro provozování BizTalk serverů, posílení platformy DMS. V rámci bezpečnostních projektů probíhal i nadále rozvoj AAA portálu zejména migrace ITIM na novou HW platformu a nové verze ITIM SW podpory byla ukončena uvedením do provozu počátkem listopadu. Tím je zajištěna spolehlivost tohoto systému pro další budoucnost. Záměr integrovat pod AAA aplikaci EKIS (SAP) musel být odsunut na později v důsledku nedostatku prostředků. V oblasti autentizace uţivatelů k informačním systémům byla vybudována infrastruktura veřejného klíče (PKI) včetně nasazení čipových karet, která zajišťuje bezpečné vícefaktorové ověření uţivatele pro přístup do informačních systémů i aplikací. Infrastruktura PKI je úzce vázána na doménovou infrastrukturu Active Directory, která zabezpečuje jednotný přístup do operačního systému Windows XP Proffesional, který je stanoven jako jednotná uţivatelská platforma. V rámci PKI ČSSZ je vybudováno několik centrálních certifikačních autorit dle účelu vystavovaných certifikátů (pro zaměstnance, pro hardware). Výdej a správu certifikátů pro zaměstnance zabezpečují personální útvary ústředí ČSSZ a KSSZ. Prostřednictvím tohoto systému je zajišťován přístup ke zdrojům v síti WAN a LAN a téţ přístupová oprávnění uţivatelů. Autorizace uţivatele je řešena v rámci jednotlivých systémů, zastřešena však je jednotným systémem přidělování rolí v rámci všech částí informačních systémů, tzv.přístupovým AAA portálem. Úkolem AAA portálu je na základě nástupu zaměstnance na systemizované místo spustit schvalovací proces, který zajistí přidělení rolí dle daného systemizovaného místa. 94

95 3.8.1 Vybudování přístupového AAA portálu uživatelů ČSSZ (subsystém IIS 8.1) ČSSZ má vytvořen systém správy uţivatelských účtů, který je od roku 2007 produkčně vyuţíván pro celou ČSSZ a dovoluje spravovat účty všech zaměstnanců ČSSZ (včetně externích zaměstnanců) a jejich přístupových oprávnění. Cílem projektu bylo vytvořit přístupové rozhraní AAA, které musí zajišťovat primárně řízený a sledovaný přístup uţivatelů k aplikacím napojeným na AAA prostředí na úrovni sluţeb AAA. Přístupový AAA portál tvoří jediný přístupový bod ke sluţbám a informacím poskytovaným ČSSZ v rámci AAA prostředí a jediné místo pro správu uţivatelských účtů pro přístup ke zdrojů v IIS ČSSZ. V současné době je zabezpečován jeho rozvoj, a to v oblasti zpřesňování funkcí a řešením dalších problémů, které vyplývají ze zkušeností s provozováním tohoto projektu. Související projekt Zabezpečení přístupů k aplikacím včetně autorizace přístupu k datům - jedná se o integraci aplikací do AAA prostředí v IS ČSSZ, a to integrace vyvíjených aplikací do AAA prostředí (zajištěno materiály pro oblast vývoje a podpůrnými materiály pro vývoj aplikací v.net platformě) integrace aplikací vyvíjených v rámci projektů programu realizace nového IS (byla realizována implementace autentizačních a autorizačních mechanizmů pro aplikace NEM, POJ, PPV, DIG, ZDD, IDV (individuální datová věta), KE (UI44 a UI08 aplikace na opravy dat v KE) DMS - aplikace byly či jsou úspěšně uváděny do rutinního zpracování a integrace stávajících aplikací - v návaznosti na řešení problému vyuţívání stávajících aplikací proběhlo jejich mapování a byly vytipovány ty, které budou začleněny pod AAA portál a ostatní, které se řešit nebudou. Řeší se i bezpečná komunikace tzv. okresních aplikací s centrem, komunikace s vnějšími subjekty a další problémy. Cílem navrhovaného dalšího rozvoje je v rámci technického zhodnocení stávajícího řešení AAA portálu rozšířit funkcionalitu o další následující oblasti: Další rozvoj technické zhodnocení aplikací AAA Správa všech účtů včetně technologických účtů produkčního prostředí Tím bude získána moţnost spravovat technologické účty na cílových systémech, provádět audit a reporting. Předpokládá se pokrytí cca jednoho tisíce technologických účtů s tím, ţe implementace bude probíhat v rámci nové architektury master serverů AAA portálu. V současné době je situace, kdy jsou spravovány účty na regionálních serverech, main frame systémech a technické účty v celé řadě samostatných serverů včetně main frame serveru, kterou je nutno co nejrychleji odstranit a vyřešit. Tento stav je dán historicky a konsolidaci této oblasti povaţujeme z hlediska potřeb zvyšovat bezpečnost systému za nezbytnou. Datová vrstva a její integrace pod AAA portál Integrace AAA portálu v rámci infrastruktury ČSSZ není zatím úplná. Vzhledem k tomu, ţe řešení integrace AAA portálu vyţaduje určitý čas a úsilí, je návrh rozdělen do tří časových fází. První fáze - odstranit anonymní přístup do databáze. Druhá fáze - omezení přístupových oprávnění uţivatelů v databázi. Třetí fáze - zjednodušení a zpřehlednění business logiky aplikací. Důvodem k nasazení Identity a Access Managementu na správu všech účtů je odstranění anonymity, soustředění přidělování a sledování přístupových oprávnění do jednoho místa a moţnost spravovat technologické účty na cílových systémech (včetně auditu a reportingu). Důvodem správy přístupu k datům v databázích je zvýšení bezpečnosti přístupu k datům, zejména nutnost zabezpečit odstranění anonymity přístupu a moţnosti ohroţení dat. Výsledkem bude zvýšení bezpečnosti přístupu k datům v duchu naplňování strategického cíle ČSSZ č. 4, kterým je Komplexní řešení bezpečnosti informací v ČSSZ dle BS ISO/IEC Budoucí rozvoj aplikací oblasti bezpečnosti Rozšíření funkcionality AAA portálu pro správu klientů ČSSZ Navrhuje se následující : Master ITIM a ITAM přibude zvláštní sekce uţivatelů s označením portáloví. Zároveň přibudou role související s těmito uţivateli. U rolí přibude označení viditelnost. Znamená to, ţe ne kaţdý portálový uţivatel bude moci mít přiřazenu kaţdou portálovou roli. Portáloví uţivatelé s parametrem např. exekutor bude mít přidělitelné pouze role, které budou mít parametr exekutor také přidělen. Klasifikace informací data a informace budou označeny klasifikací, která bude spojena s určitou rolí (rolemi). Tím se zajistí: o Přehlednost a rozčlenění dat 95

96 3 o Vyšší bezpečnost při přidělování rolí pro přístup k informacím pro portálové uţivatele. o Eliminace omylů o špatnou roli nebude moţné ani poţádat. ReadOnly replika ITIM/ITAM - Portál bude jako zdroj informací i uţivatelích a o rolích pouţívat výhradně ReadOnly repliku, kam nebude moţné zapsat. Data budou replice předávána výhradně z Master ITIM/ITAM, kteří jsou bezpečně uloţeny v management zóně ČSSZ. ReadOnly replika databázových informací tato vlastnost není pro funkčnost potálu nutná, zvyšovala by však bezpečnost, efektivnost a dobu odezvy. Logika je takováto: Na základě zaregistrovaných portálových uţivatelů, jim přidělených portálových rolí a jejich vazbě na klasifikaci dat by bylo moţné určit, která data je aktuálně moţné zobrazovat přes Portál. Ta data by se v pravidelných intervalech kopírovala do RO repliky databáze. Odezvy by byly rychlejší, bezpečnost vyšší. Průchod Portálem je vţdy kontrolován RO kopií ITIM/ITAM. ITAM bude zároveň zajišťovat poţadované způsoby autentizace portálových uţivatelů a také autentizaci komunikujících aplikací třetích stran. Zápis do ITIM/ITAM Mastera registrovaní portáloví uţivatelé, informace o nich, přidělené role ap.se z Portálu zapisují do ITIM/ITAM z tohoto pohledu je ITIM/ITAM podobný jiným aplikacím a komunikace probíhá přes rozhraní. Schvalování ţádostí probíhá obdobně jako u interních ţádostí. PVS, 3.strany, EESSI Telefonní komunikace Mailová komunikace Datové schránky Veřejnost, 3.strany Portál Elektronická DIS Call Centrum DSS Klientský portál Ruční vstupy podatelna Komunikační kanály AAA portál RO IAM Role, uživatelé, viditelnosti,klasifikace dat 4 DIS Platforma pro kontrolu a řízení procesů a SOA služeb v oblasi IN Evidence, transformace, konsolidace dat, systém front Rozhraní pro komunikaci s aplikacemi Aplikace Ruční zpracování Rozhraní a pomocné služby E-podatelna Spisová služba E-výpravna RO databáze Jádro portálu POJ NE. DMS Exchange Kmenové evidence Registry Databáze 1 0 Master IAM Role, uživatelé, viditelnosti, Klasifikace dat Obrázek 48 - Portál ČSSZ a kontrola identit Bezpečnostní monitoring přístupu k aplikacím a datům ČSSZ Účel a cíle projektu Hlavním účelem projektu je popsat aktuální stav monitorování přístupů k aplikacím v rámci ČSSZ (dále jen organizace ) a provést návrh a implementaci optimálního řešení pro identifikaci bezpečnostních 96

97 incidentů a jejich řešení či budoucí eliminaci formou následných opatření s cílem definovat a implementovat takové řešení, které nejlépe vyhovuje poţadavkům organizace a zároveň zohledňuje specifika jejího vnitřního prostředí. Uvedení projektu Provoz současného portfolia klíčových aplikací organizace generuje obrovské mnoţství aplikačních záznamů-logů. Implementovaný systém Identity Managementu (dále IM ), automatizovaně generuje provozní záznamy, které podrobně identifikují jednotlivé akce, jak koncových uţivatelů, tak i samotných aplikací. Veškeré logy IM jsou ukládány centrálně. V současné době není v organizaci aplikován efektivní postup a nástroj pro zpracování a vyhodnocení získaných dat z vygenerovaných záznamů, přestoţe tyto záznamy mohou poskytovat velmi cenné informace v rámci řízení bezpečnostních incidentů. Reporty aktuálně vytvořené nad generovanými záznamy poskytují pouze souhrnný statistický pohled, který nemá vyšší informační hodnotu. Cíl projektu Cílem projektu je v rámci bezpečnostní politiky organizace nasazení systému pro sběr a vyhodnocování záznamů v reţimu Proof of concept (dále jen PoC ) za účelem ověření realizovatelnosti a očekávaných přínosů navrţeného řešení a stanovení strategie a časového rámce pro jeho další rozšiřování v prostředí organizace. Popis klíčových aktivit projektu Následující schéma znázorňuje princip bezpečnostního vyhodnocování logů: Obrázek 49 - Bezpečnostní monitoring Projekt je veden v reţimu ověření vhodnosti zvolené koncepce vyhodnocování bezpečnostních incidentů (PoC). Aktivity v rámci projektu musí vést ke stanovení příslušných postupů, identifikaci zdrojových systémů pro odběr generovaných záznamů, implementaci ověřovacího řešení v rozsahu navrţeného PoC, analýzu potřeb pro další rozvoj řešení v rámci organizace a vyhodnocení realizovaného PoC včetně relevantních doporučení pro další kroky. Identifikace informačních zdrojů v prostředí ČSSZ Ve fázi analýzy informačních vstupů budou realizovány zejména následující aktivity: Určení všech systémů, které poskytují vyuţitelná data. Klasifikace důleţitosti jednotlivých systémů z pohledu bezpečnosti. Klasifikace typů dat pro jednotlivé datové záznamy z pohledu bezpečnosti. Kvantifikace celkového mnoţství záznamů. 97

98 Kvantifikace četnosti vzniku záznamů. Implementace řešení v rozsahu PoC V rámci fáze implementace jsou výstupy analýzy uvedené do provozu v následujících krocích: Implementace ověřovacího řešení (PoC) v navrţeném rozsahu Provedení interních testů funkčnosti řešení před předáním řešení k testům Cílem fáze testování je ověřit funkčnost a bezchybnost implementace navrţeného řešení pro vybraný vzorek zdrojových dat, resp. systémů dle odsouhlasené testovací strategie: Praktické testování logiky a proveditelnosti výše uvedených definic Opakované a řízené provádění testů s kapacitním předpokladem cca 1000 events/s s moţností připojení potřebného počtu zdrojových systémů. Vyhodnocení realizovaného PoC V rámci fáze vyhodnocení PoC je vhodné shrnout poznatky získané v předcházejících aktivitách a navrhnout postup pro další rozvoj řešení v rámci potřeb organizace. Vyhodnocení vhodnosti zvoleného postupu vyhodnocování bezpečnostních incidentů vůči potřebám organizace Kvantifikace praktických výstupů testovacího nasazení systému Návrhy pro další rozvoj řešení v rámci organizace (resp. plošné rozšíření sběru záznamů) Zpracování vize pro budoucí zasazení projektu a jeho dalších etap do kontextu správy IT a řízení informační bezpečnosti v rámci organizace. Výstupy projektu Výstupem projektu budou zpracované dokumenty s následujícím obsahem: vyhodnocení realizovatelnosti a poţadované funkčnosti aplikovaného postupu vyhodnocování bezpečnostních incidentů vůči aktuálním i budoucím potřebám organizace (na základě realizace PoC), kvantifikace konkrétních výstupů testovacího nasazení systému včetně posouzení a interpretace výsledků PoC, návrh na další rozvoj řešení v rámci organizace odpovídající výstupům provedené analýzy potřeb a poţadavků, zpracování vize pro budoucí zasazení projektu a jeho dalších etap do kontextu správy IT a řízení informační bezpečnosti, dokumentace předpokládaných netechnologických (provozních a procesních) náleţitostí plošného nasazení. Řízení rizik Součástí tohoto projektu bude také řízení rizik, coţ je průběţný proces, který je jednou z hlavních zodpovědností vedoucího projektu. Smyslem je předvídat moţné komplikace, které mohou na projektu nastat, snaţit se jim předcházet a v případě, ţe skutečně nastanou, mít připraven plán, jak jejich dopad eliminovat. Nedílnou součástí procesu řízení rizik je jejich komunikace a reportování, součástí finančního řízení pak kalkulace a vyčlenění příslušných rezerv, které lze v případě potřeby pouţít. Hlavní kroky řízení rizik: Identifikace rizik - vedoucí projektu identifikuje (nejlépe na základě checklistu) rizika, která lze identifikovat v daném stavu informovanosti o projektu. Součástí identifikace je i stanovení osoby zodpovědné za sledování kaţdého rizika Ohodnocení rizik - vedoucí projektu všechna identifikovaná rizika ohodnotí z pohledu nákladů, pravděpodobnosti, významnosti pro projekt a dopadů do harmonogramu projektu Stanovení moţností předcházení identifikovaným rizikům - vedoucí projektu stanoví moţný způsob předcházení jednotlivým identifikovaným rizikům. Tento krok musí zahrnovat i rozhodnutí, zda je výhodnější riziko podstoupit anebo takový plán realizovat. Tento krok lze modifikovat i tak, ţe výsledkem bude sníţení pravděpodobnosti výskytu rizika Vypracování plánu reakce na výskyt rizik - vedoucí projektu s klíčovými konzultanty navrhne vhodný postup, který se spustí v případě, ţe se riziko stane aktivním. Zároveň specifikuje i identifikátory, které jednoznačně určí, ţe riziko nastalo a je nutné připravený plán spustit Pravidelné sledování a vyhodnocování rizik - vedoucí projektu pravidelně vyhodnocuje stav rizik (spolu s osobou zodpovědnou za stranu organizace) a případně identifikuje rizika nová Komunikace rizik - Vedoucí projektu pravidelně reportuje o stavu rizik Unifikace a integrace docházkových a průchozích subsystémů Docházkové subsystémy ČSSZ - průběţná realizace projektu sjednocení docházkových systémů v rámci ČSSZ s vyuţitím zaměstnaneckých čipových karet, včetně rozhraní na navazující systémy a procesy v oblasti ekonomicko správní, kde je poţadována identifikace osoby pomocí bezkontaktního čipu a 98

99 komunikace dat docházkových systémů s centrálním serverem ústředí, včetně synchronizace dat s AAA portálem a PKI. Byl dořešen přístup jednotlivých uţivatelů bez nutností zadání vstupního hesla, tj. vytvoření jednotné autentizace uţivatele v rámci celého systému, autentizace bude zajištěna výhradně certifikátem uţivatele uloţeným na PKI čipové kartě - Single sign on. V současné době probíhají přípravné a projektové práce na propojení centrálního docházkového systému s IS HR-SAP pro přenos plánů pracovní doby, včetně nastavení datových a komunikačních rozhraní. Současně se připravuje pilotní provoz elektronické evidence docházky v ústředí a následně postupné rozšíření v rámci celé ČSSZ. Oblast Subsystém Název Projekt 8 Subsystémy oblasti bezpečnosti 8.1 Informační subsystémy oblasti bezpečnosti Správa uţivatelských účtů a přístupů AAA portál PKI, monitoring, průchozí systémy. Další rozvoj: Technické zhodnocení aplikací AAA (ostatní účty a přístup k datům). Integrace subsystému SAP - EKIS Plánovaná Správa přístupu klientů a externích subjektů. Bezpečnostní monitoring přístupu a risk analýza IIS ČSSZ Unifikace a integrace docházkových a průchozích subsystémů. technického zhodnocení stávajícího řešení AAA portálu rozšířit funkcionalitu 3.9 Oblast 9 - Podpůrné subsystémy ASW pro call centrum ústředí HiPath ProCenter - zabezpečení servisní podpory aplikace HiPath ProCenter Enterprise Kontaktního centra ČSSZ. Oblast e - Podání za zaměstnance ČSSZ - zabezpečení odesílání dat z IS HR-SAP za zaměstnance ČSSZ prostřednictvím PVS do informačních systémů ČSSZ. Aplikace firmy CNS - modulární řešení pro vyuţití datových zdrojů v oblasti informační podpory činností ČSSZ v oblasti školení, registrace účastníků a evidence souvisejících činností a sluţeb ve výukovém středisku ČSSZ v Karlových Varech. Systém byl v roce 2009 rozšířen o zámkový a zabezpečovací systém pro výuková střediska Karlovy Vary a Kroměříţ. Došlo k dalšímu vyuţití moţností zaměstnanecké čipové karty v bezkontaktní části. Současně bylo vybudováno datové rozhraní pro komunikaci s centrálním docházkovým systémem pro přebírání bezkontaktního čipu a rodného čísla karty. Doculive - jde o systém spisové sluţby ústředí, který je funkční a vyţaduje aktualizaci elektronického oběhu věcných spisů v návaznosti na prováděné organizační změny v ČSSZ a v rámci hierarchie řídící a rozhodovací činnosti v ústředí. Průběţně je prováděna analýza indexů, jejich vyuţívání a analýza optimalizace databáze pro předcházení zpomalení odpovědí k zajištění snadné dostupnosti dokumentů. Na základě těchto analýz byl zahájen proces pro provedení archivace dokumentů ve smyslu příslušných normativů. Námitkové řízení - Na základě institutu Námitkové řízení s účinností shodně s Parametrickými změnami od byla vytvořena aplikace ke sledování průběhu odvolacího řízení a získávání statistických údajů. 99

100 Oblast Subsystém Název Projekt 9 Podpůrné subsystémy 9.1 Podpůrné subsystémy Help Desk, Call Desk, Docházkové systémy, pilotní provoz Elektronické vzdělávání, Vývojové prostředky, Vyvolávací systémy a elektronické řada dalších jako např. personální aplikace ASP pro účely optimalizace evidence docházky a automatizace administrativních činností pořádání školení ve VS v ústředí a ČSSZ, podpora Call centra - aplikace HPPCE (HiPath Procenter následně postupné Enterprise), rozšíření v rámci ASPI. celé ČSSZ 9.2 Informační subsystém v oddělené doméně pro zpracování auditních v provozu informací. 9.3 Námitkové řízení v provozu 9.4 Vývojové prostředí a prostředky 100

101 4 Koncepce technologické infrastruktury IIS ČSSZ 4.1 Celkové uspořádání technické základny IIS ČSSZ Základní koncept budování HW architektury vychází z výše uvedených principů centralizace datové základny a decentralizace obsluhy klientů. Tato architektura předpokládá: Centralizované datové úloţiště s nezbytnou HW základnou. Centralizovanou aplikační vrstvu s nebytnou výpočetní kapacitou postačující pro zajišťování provozu IIS. Decentralizované (lokální) uzly IIS regionálně orientované na pokrytí všech pracovišť ČSSZ. Prezentační uţivatelskou vrstvu Všechny vrstvy musí být propojeny výkonnou komunikační sítí. Tato architektura pokrývá následující regionální strukturu pracovišť ČSSZ: Ústředí, které je lokalizováno v několika budovách Pracoviště PSSZ v Trojské a v budovách obvodních pracovišť v Praze. Sídla pracovišť v Brně. Sídla jednotlivých Pracovišť ČSSZ. Sídla jednotlivých Okresních správ sociálního zabezpečení (OSSZ). U některých okresních správ jsou zřízena odloučená pracoviště, které jsou zřízena v dalších územních jednotkách. Dále sem patří školící střediska ústředí ČSSZ, Kroměříţ a Karlovy Vary. HW strukturu ČSSZ lze znázornit následujícím schématem. Obrázek 50 HW struktura IKT ČSSZ 4.2 Centralizované datové úložiště IIS ČSSZ Centrální vrstva ČSSZ je lokalizována v Kříţové ulici 25 pracoviště KP0 (infrastrukturní vrstva a server SQ100), v Kříţové ulici 6 pracoviště KP1 (datové úloţiště DMS a optický archiv, datové úloţiště pro centrální aplikace 1. část, farmy aplikačních serverů 1.část a SQ100 server)) a pracoviště KP2 v Trojské ( datové úloţiště pro centrální aplikace 2.část, farmy aplikačních serverů 2.část a SQ100 server ). Rozmístění centrálních systémů znázorňuje následující schéma. 101