03.05.2010
Strategie rozvoje IKT ČSSZ do roku 2014
Verze:01
1
Obsah
Strategie rozvoje IKT ČSSZ do roku 2014 .............................................................. 1 1 Cíle strategického rozvoje................................................................................ 6 1.1 1.2 1.3 1.4
2
Strategické cíle ČSSZ ............................................................................................ 6 Dlouhodobé cíle IKT ČSSZ ...................................................................................... 6 Prioritní úkoly ČSSZ pro rok 2010 .......................................................................... 7 Způsoby realizace a prostředky k dosažení cílů IKT .............................................. 7
Koncepce tvorby integrovaného informačního systému (IIS ČSSZ) ................ 9 2.1 Strategické principy vytváření IIS ČSSZ ................................................................ 9 2.1.1 Princip centralizace .................................................................................................. 9 2.1.2 Princip decentralizace obsluhy klientů ....................................................................... 9 2.1.3 Princip unifikace .....................................................................................................10 2.1.4 Princip architektury sluţeb ......................................................................................10 2.2 Logická struktura IIS ČSSZ ................................................................................. 11 2.2.1 Procesní charakteristika IIS ČSSZ ............................................................................11 2.2.2 Charakteristika datové struktury IIS ČSSZ ...............................................................13 2.3 Struktura IIS ČSSZ a členění na subsystémy ....................................................... 16 2.3.1 Logické oblasti a subsystémy IIS ČSSZ ...................................................................16 2.3.2 Schéma subsystémů IIS ČSSZ .................................................................................17 2.4 Architektura aplikační podpory IIS ČSSZ ............................................................. 19 2.5 Zabezpečování centralizace dat a aplikací a klientského přístupu ..................... 21 2.6 Popis vazeb IIS ČSSZ na jiné ISVS ....................................................................... 28 2.7 Forma komunikace IIS ČSSZ s okolím a klienty ................................................... 31
3
Koncepce rozvoje aplikační podpory jednotlivých oblastí IIS ČSSZ ............... 33 3.1 Oblast 1 - Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací ......................................................................................................................... 34 3.1.1 Rozhraní pro komunikaci s klienty ČSSZ (Klientský portál) – (subsystém 1.1) .............34 3.1.2 Aplikační podpora rozhraní pro zabezpečení komunikace IIS ČSSZ s klienty subsystém 1.1 ......................................................................................................................37 3.1.3 DIS-subsystém jako základ subsystému IN (DIS_IN) pro zabezpečení vstupní oblasti IIS ČSSZ 41 3.1.3.1 Řešení oblasti vstupu a ošetření informací – projekt IN (DIS_IN) ........................................ 41 3.1.4 Řešení oblasti OUT .................................................................................................45 3.1.5 Projekt el. podatelny, výpravny a spisové sluţby - subsystém 1.1 a 7.2 ....................45 3.1.6 Zajištění elektronické výměny dat mezi státy EU v současnosti ..................................47 3.1.6.1 „Vybudování Access Points – přístupových míst ČR do Evropské architektury“ ...................... 47 3.1.6.2 Charakteristika Access Points ČSSZ .................................................................................. 49 3.1.6.3 Předávání informací mezi institucemi v ČR (CMU, ČSSZ, MPSV) .......................................... 52 3.1.6.4 Technické poţadavky ..................................................................................................... 55 3.2 Oblast 2 - Výběr pojistného .................................................................................. 56 3.2.1 Projekt - Výběr pojistného (POJ) – (subsystém ISS 2.1) ............................................57 3.2.1.1 Rozvoj POJ - plánovaná centralizace aplikace OSVČ .......................................................... 57 3.2.2 Projekt - Insolvenční řízení (INSRI) (subsystém ISS 2.2) ...........................................58 3.3 Oblast 3 - Správa dávek důchodového a nemocenského pojištění ...................... 60 3.3.1 Informační subsystém důchodových agend ..............................................................61 3.3.1.1 Aplikační podpora v oblasti správy dávek důchodového pojištění - platforma SQ100 – BS2000 61 3.3.1.2 Realizace Parametrických změn v zákoně č. 155/1995 Sb. ................................................. 63 3.3.1.3 Aplikace Správa důchodových dávek (SDD) ..................................................................... 64 3.3.1.4 Integrace aplikací subsystémů modelu SQ100 .................................................................. 65 3.3.1.5 Integrace aplikací UI42 a UI45 do IIS ČSSZ ..................................................................... 65 2
3.3.2 Informační subsystém agend nemocenského pojištění ..............................................66 3.3.2.1 Projekt - Nemocenské pojištění (NEM) – (subsystém ISS 3.2) ............................................ 66 3.3.2.2 Další rozvoj aplikace ....................................................................................................... 69 3.3.2.3 Elektronická neschopenka ............................................................................................... 67 3.3.3 Informační subsystém agend úrazového pojištění .....................................................69 3.4 Oblast 4 - Výplaty dávek ...................................................................................... 74 3.4.1 Výplata dávek (VYP) - průřezový pro všechny subsystémy (ISS 4.1) ........................74 3.4.2 Projekt - Exekuce a konkurzy (EXK) (subsystém ISS 4.2) ..........................................72 3.5 Oblast 5 - Správa údajové základny ..................................................................... 75 3.5.1 Projekt Důchodové pojištění (SDD) (subsystém ISS 5.1) ...........................................75 3.5.2 Projekt - Nárokové podklady a dávky (NPD) (subsystém ISS 5.1) .............................75 3.5.3 Projekt ELDP, POS a ONZ (zpracování nových formulářů) ..........................................78 3.5.4 Novela zákona č. 582/1991 Sb. o organizaci a provádění sociálního zabezpečení (subsystém IIS 5.1) ..............................................................................................................79 3.5.5 Projekt - Ţádosti o důchodové dávky (ZDD) (subsystém ISS 5.1) ..............................79 3.5.6 Registr pojištěnců – průřezový projekt pro všechny agendy ČSSZ (subsystém ISS 5.2) 79 3.5.7 Lékařská posudková sluţba (LPS) ......................... Chyba! Záložka není definována. 3.6 Oblast 6 Ekonomické subsystémy ........................................................................ 82 3.6.1 Projekt - Další rozvoj ekonomického informačního systému (EKIS (subsystém ISS 6.1) 82 3.7 Oblast 7 - Průřezové subsystémy ......................................................................... 83 3.7.1 Workflow – Platforma pro řízení a kontrolu procesů a sluţeb (PŘKPS - Posunovač) Subsystém 7.1 ......................................................................................................................83 3.7.2 ESS - Elektronická spisová sluţba ...........................................................................85 3.7.3 Datová integrace – DMS (subsystém IIS 7.3) ...........................................................86 3.7.3.1 Současný stav v aplikaci DMS .......................................................................................... 86 3.7.3.2 Projekt MIGRACE DMS .................................................................................................... 87 3.7.4 Elektronický zaručený archiv ZEA.............................................................................89 3.7.5 Plánovaná centralizace aplikace Kontrolní činnost (KOCIN) ........................................91 3.7.6 Elektronický spis – jeho koncepce a implementace ...................................................93 3.8 Oblast 8 - Subsystémy oblasti bezpečnosti ......................................................... 94 3.8.1 Vybudování přístupového AAA portálu uţivatelů ČSSZ (subsystém IIS 8.1) .................95 3.8.2 Další rozvoj – technické zhodnocení aplikací AAA ......................................................95 3.8.3 Budoucí rozvoj aplikací oblasti bezpečnosti ...............................................................95 3.8.3.1 Rozšíření funkcionality AAA portálu pro správu klientů ČSSZ ............................................... 95 3.8.3.2 Bezpečnostní monitoring přístupu k aplikacím a datům ČSSZ .............................................. 96 3.9 Oblast 9 - Podpůrné subsystémy .......................................................................... 99
4
Koncepce technologické infrastruktury IIS ČSSZ ........................................ 101 4.1 Celkové uspořádání technické základny IIS ČSSZ ............................................. 101 4.2 Centralizované datové úložiště IIS ČSSZ ........................................................... 101 4.2.1 Datová vrstva ....................................................................................................... 102 4.3 Centralizovaná aplikační vrstva ......................................................................... 104 4.4 Decentralizované (lokální) uzly IIS .................................................................... 105 4.5 Presentační (uživatelská) vrstva ........................................................................ 105 4.6 Síťová architektura ............................................................................................ 106 4.6.1 Rozvojové úkoly ................................................................................................... 107 4.6.1.1 Rozvoj síťové infrastruktury pro vytvoření Rozhraní ČSSZ pro komunikaci s klienty ............ 107 4.6.1.2 Návrh řešení konceptu B2B kanálu................................................................................. 108
5
Strategie zajištění provozu IIS ČSSZ .......................................................... 110 5.1 5.2 5.3
Struktura IIS ČSSZ z hlediska provozovaného aplikačního zabezpečení ......... 110 Zavedení monitoringu se zaměřením na kvalitu a výkonnost řešení ................. 112 Rozvoj centrálního ServiceDesku ....................................................................... 113 3
6 7
Strategie zabezpečení vývoje udržování IIS ČSSZ ....................................... 114 Strategie bezpečnosti IIS ČSSZ .................................................................. 115 7.1 Organizace a řízení bezpečnosti v ČSSZ ............................................................. 115 7.1.1 Řízení bezpečnosti s působností na celou ČSSZ ...................................................... 115 7.1.2 Řízení a zajišťování bezpečnosti v rámci úseku IKT ................................................. 115
8
Financování .................................................................................................. 117 8.1 Financování IKT a IIS ČSSZ ................................................................................ 117 8.2 Strategie financování rozvoje IIS ČSSZ ............................................................. 123 8.3 Strukturální fondy EU ......................................................................................... 124 8.3.1 Cíle projektů, které ČSSZ plánuje financovat ze Strukturálních fondů EU .................. 124 8.3.1.1 Projekty ČSSZ s vazbou na eGovernment, které ČSSZ plánuje financovat ze Strukturálních fondů EU 124
9
Závěr ............................................................................................................ 128
Seznam obrázků Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek
1 - Logická struktura procesů ČSSZ ..................................................................................12 2 - Základní datová struktura IIS ČSSZ .............................................................................13 3 - Organizace procesů podle SOA principu .......................................................................15 4 - Schéma struktury IIS ČSSZ .........................................................................................18 5 – Základní vrstvy aplikační podpory ČSSZ .......................................................................19 6 – Model struktury základních aplikací .............................................................................20 7 – Schématické znázornění realizovaných vazeb mezi současnými aplikacemi ....................20 8 – Řešení řízení procesu a komunikace mezi aplikacemi pomocí PŘKPS a Posunovače ........21 9 - Vazby na registry eGovernmentu................................................................................29 10 – Účastníci komunikace s ČSSZ ....................................................................................30 11 - Komunikační vazby na okolní systémy - současný stav ................................................31 12 - Sluţby poskytované klientským portálem ...................................................................36 13 - Řešení VREP rozhraní ...............................................................................................38 14 - Připojení k datovým schránkám .................................................................................39 15 - Koncepce řešení oblasti IN ........................................................................................42 16 - DIS systém a jeho funkcionalita v současné době .......................................................43 17 - Architektura oblasti DIS_IN pro nejbliţší období (vize) ................................................44 18 - Celková architektura subsystému elektronické spisové sluţby ......................................46 19 – Konceptuální schéma EESSI ....................................................................................48 20 - Schéma integrace EESSI s ČSSZ IN ...........................................................................50 21 - Vazby AP ČSSZ a vnitřní sítě ČSSZ ...........................................................................52 22 - Vztah AP ČSSZ a ostatních AP v ČR ...........................................................................53 23 - Interní systémy ČSSZ zapojené do komunikace prostřednictvím Access pointu ČSSZ.....55 24 - I/O Picture POJ ........................................................................................................57 25: INS + SPR a okolní aplikace .......................................................................................59 26 - Vstup nových ţádostí do subsystému .........................................................................63 27 - Revitalizace modulu EDS aplikace SDD ......................................................................65 28 – Integrace aplikační oblasti UI42 do IIS ......................................................................66 29 - I/O Picture NEM .......................................................................................................67 30 - Koncepce komunikace lékař ČSSZ ..............................................................................68 31 - Dopady do stávajících systémů ..................................................................................69 32 - Oblast úrazového pojištění ........................................................................................70 33 - Výběr pojistného ......................................................................................................71 34 - I/O Picture VYP ........................................................................................................74 35 - I/O Picture EXK ........................................................................................................72 36 - I/O Picture ...............................................................................................................76 37 - Procesní diagram stávajícího procesu včetně ELDP .....................................................76 38 - Procesní diagram stávajícího procesu včetně ONZ ......................................................77 39 - I/O Picture KE2 ........................................................................................................80 40 – I/O Picture VZT08 ....................................................................................................81 41 – Současný stav v řešení oblasti IN na principu PŘKPS ..................................................84 4
Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek Obrázek
42 - Architektura PŘKPS ..................................................................................................85 43 – I/O Picture DMS .......................................................................................................87 44- Rozšíření stávajícího DMS...........................................................................................90 45 – Centralizace aplikace KOCIN (KOC) ...........................................................................92 46 – Schéma nasazení centrální aplikace KOCIN (KOC) ......................................................92 47 – EDS – návrh rozvoje v roce 2010 ..............................................................................93 48 - Portál ČSSZ a kontrola identit ....................................................................................96 49 - Bezpečnostní monitoring ...........................................................................................97 50 – HW struktura IKT ČSSZ .......................................................................................... 101 51 – Struktura centrálních pracovišť ............................................................................... 102 52 - Současné uspořádání datového úloţiště KP1/KP2 .................................................... 103 53 – Síťová architektura IIS ČSSZ .................................................................................. 106 54 – Blokové schéma moţného řešení síťové infrastruktury ............................................. 107 55 – Varianta B2B ......................................................................................................... 108 56 - Předpokládaná budoucí infrastruktura ..................................................................... 109
5
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 2008. 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:
1.1
Informační koncepcí České správy sociálního zabezpečení. Organizačním řádem ČSSZ. Dokumentací programu reprodukce majetku 113 210 – 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í 2008 – 2011. 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 2008. o Akční plány ČSSZ.
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 17799.
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
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:
1.3
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.
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
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
2 Koncepce tvorby systému (IIS ČSSZ)
integrovaného
informačního
Č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).
2.1.1
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.
2.1.2
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
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í.
2.1.3
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.).
2.1.4
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
2.2
Logická struktura IIS ČSSZ
2.2.1
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ů:
to
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 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
Komunikace ČSSZ s vnějšími subjekty OUT Poskytování informací
IN Příjem podání
Výběr Výběr pojistného
Výkon agend
Platby dávek
Insolvenční řízení, správní řízení
Výplaty dávek
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
Průřezové procesy Elektronická spisová služba
Elektronický spis
Dokument Management systém (DMS)
Bezpečnost
Platforma pro řízení a kontrolu procesů (PŘKPS)
Správa uživatelských účtů a přístupů (AAA) Správa přístupu klientů a externích subjektů
Zaručený elektronický archiv
Průchozí subsystémy, docházkové subsystémy
Kontrolní činnost (KOC)
Obrázek 1 - Logická struktura procesů ČSSZ
12
Podpůrné procesy Podpůrné subsystémy Call Desk, Help Desk Subsystém auditu, Vývojové prostředí prostředky Námitkové řízení
a
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.
2.2.2
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í
Výběr
Data oblasti POJ
Data pro LPS
Data oblasti NEM
Výběr pojistného
Výkon agend Správa informací o Pracovní neschopnosti Správa dávek důchodovéh o pojištění
Data oblasti oblasti registrů (KE2)
Databáze spisové sluţby a ISDS)
Databáze ES
Výběr
Platby dávek
Insolvenční a správní řízení
Výplaty Výplaty dávek dávek
Exekuční řízení
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 dávek úrazového pojištění
Data oblasti
EKIS Insolvence
Správa dat Evidence nárokových podkladů
Registr pojištěnců Kmenové evidence
Správa pojistných vztahů VZT
Průřezové procesy Elektronická spisová služba
Bezpečnost
Platforma pro řízení a kontrolu procesů
Správa uživatelských účtů a přístupů (AAA)
(PŘKPS) Elektronický spis (ES)
Data IN/OUT Kontrolní činnost (KOC)
Správa přístupu klientů klientů
Dokument Management systém (DMS)
Zaručený elektronický archiv
Průchozí subsystémy, doscházkové subsystémy
a externích externích subjektů
ekonom
Ekonomické Statistiky subsystémy
Statistiky
Data oblasti úrazového poj.
Data oblasti nárokových podkladů.
OUT Poskytován í informací
Data o výplatách
Statistická data
Data oblasti důchodového pojištění
Podpůrné procesy
Data oblasti (VZT)
Podpůrné subsystémy
Call Desk, Help Desk Databáze CD,HD
Subsystém Subsystém auditu, auditu vývojové prostředí a
prostředky Námitkové řízení
Data oblasti auditu
Data podpůrných subsystémů Data DMS
Data PŘKPS
Data oblasti AAA
Obrázek 2 - Základní datová struktura IIS ČSSZ
13
Data oblasti kontroly fyzického přístupu
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
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.
Oblast rozhraní Přímá
výměna dat Podání - Portál veřejné správy Podání mimo PVS
Vazba na procesní aplikační podporu
DIS server
DSS rozhraní (Datové schránky)
–
Czech Point
Access Point
Ostatní nespecifiko vaná podání
Portál rozhraní pro komunikaci s klienty
Czech Point Rozhraní
Zaměstnan ci ČSSZ
platforma pro řízení a kontrolu procesů a služeb (PŘKPS)
Rozhraní jednotlivýc h aplikací pro podporu sluţeb portálu
Subsystém OUT
Rozhraní pro komunikaci Access Point
Elektronická spisová služba (ESS)
e-podatelna logické rozhraní pro přijetí podání e-výpravna logické rozhraní pro odeslání el. zásilek
Internet
Subsystém IN
VREP server
Datové schránky
Klienti fyzické osoby
Rozhraní B2B
Systém autentifikace klientů a ext. subjektů
AAA Portál (zaměstnanci)
Vzdálený přístup
Webový portál ČSSZ (statické informace o ČSSZ) Obrázek 3 - Organizace procesů podle SOA principu
15
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:
2.3
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.
Struktura IIS ČSSZ a členění na subsystémy
2.3.1
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
2.3.2
Průřezové subsystémy. Subsystémy oblasti bezpečnosti. Podpůrné subsystémy.
Schéma subsystémů IIS ČSSZ
17
Aplikační oblasti
Infrastrukturní oblasti
6 Ekonomické subsystémy
1 Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací atd. Centrální datová vrstva (datová úloţiště)
ISS 1.1 Informační subsystém rozhraní pro zabezpečení komunikace IIS ČSSZ / Klientský portál ČSSZ B2B rozhraní
DIS Server – PVS rozhraní
VREP – veřejné rozhraní e-pod
DSS rozhraní – Internet, DAS, ISDS Server
Czech Rozhraní
Point
Access Rozhraní
Point
E-podatelna / E-výpravna
Rozhraní pro vzdálený přístup zaměstnanců ČSSZ
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 Centralizovaná aplikační vrstva (Aplikační servery a systémy)
Decentralizované (lokální) uzly IIS
3 Výkon agend
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í .
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í
4 Výplaty dávek 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 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 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 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
5 Správa údajové základny
Presentační vrstva (uživatelská vrstva)
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č)
Síťová vrstva (komunikační infrastruktura)
ISS 5.2 Informační subsystém Registr pojištěnců (Kmenové evidence) pojištěnců, plátců pojištění
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 5.3 Informační subsystém Registr pojistných vztahu (VZT)
8 Bezpečnostní subsystémy
9 Podpůrné 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,
ISS 9.1 Podpůrné subsystémy (např. HelpDesk,CallDesk, ASPI, atd…) ISS 9.2
ISS 7.2 Elektronická spisová služba ESS
ISS 7.5 Kontrolní činnost - KOC
ISS 7.4 Zaručený elektronický archiv
ISS 7.6 Elektronický spis
Obrázek 4 - Schéma struktury IIS ČSSZ
18
Plánovaná Správa přístupu klientů a externích subjektů,
subsystém v oddělené doméně pro zpracování auditních informací
ISS 9.3 Námitkové řízení
ISS 6. 2 Podpůrné ekonomické subsystémy pro Zpracování statistik
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
Aplikační prostředí , , aplikace,vývoj,testy)
(servery,
Centrální datové úloţiště KP0, KP1
Síť LAN
uživatelé
Síť WAN
Záloţní aplikační prostředí (servery, aplikace,vývoj,testy)
Záloţní datové úloţiště KP2
SAN
Prezentační vrstva Aplikační vrstva
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
IN
OUT ZDV
Vstupy
STV
INF
KL Důchodová POJ
VYP Nemocenská
Centrální registry (CERE) VZT
Datový katalog
KE2
Číselníky
Infrastruktura
Legenda
AAA
BPM Oblast Oblast v produkčním prostředí
Průřezová oblast DMS
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. Datum aktualizace
DIS
ZDV
POJ
DMS
KL
NEM
VZT
28. 01. 2009
VYP
KE2 Vazba
EXK Oblast
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é 20
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í přístupu
centralizace dat a aplikací a klientského
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
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 31.3.2010 Oblast
1. 2. 3. 4. 5. 6. 7. 8. 9.
Název oblasti
Počet aplikací pro oblast
Komunikace s vnějšími subjekty Výběr pojistného Správa dávek Výplata dávek Správa údajové základny Ekonomické subsystémy Průřezové subsystémy Subsystémy oblasti bezpečnosti Podpůrné systémy
Aplikace ČSSZ celkem Tabulka 2 - Detailní přehled aplikací v ČSSZ k 31.3.2010
Číslo
Oblast/zkratka
Počet aplikací lokálních
Počet aplikací centrálních
5 20 83 15 25 3 4 2 63 220
Název aplikace
5 0 71 15 24 2 4 2 49 172
0 20 12 0 1 1 0 0 14 48
0 100 14,46 0 4 33,33 0 0 22,22 21,82
Centralizov ané
Celkem
1. Komunikace s vnějšími subjekty Celkem
Procento lokálních aplikací
5
5
Registrace e-podání Provoz systému pro příjem a zpracování a epodání na ČSSZ (součást řešení PVS/DMS) Provoz systému pro příjem a zpracování e-podání na ČSSZ Kukátko do systému pro příjem a zpracování epodání
1
UCZPR
Účetní zpráva ČSSZ
1
1
RAUI/AAS
2
DIS server
3
DIS SystémDISview
4
DIS View
5
Lokální
0
1 1 1 20
0
20
2. Výběr pojistného
Celkem
6
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
1
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 3. Správa dávek
1 83
Celkem
22
71
12
Číslo
Název aplikace
26
DAVUC
Dávková účtárna
1
27
ELDP
Tisk listů DP
1
28 29
EPOZ EVDOB
Dlouhodobá neschopnost
1
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
35
NPD Nárokové podklady důchodového pojištění D_STAT (včetně EVI, EDA, Statistický subsystém o přiznaných důchodových klienta KWH) dávkách SDD Správa dávek důchodového pojištění
36
VPO3
Ţádost a rozhodování 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
50
ABO - vyuţívána archivně (od II/09)
51
ARM
52
BDOPL
53
CIZDOPL
54
ČNB
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 04
1
61
DIGI - UIW Work 05
1
62
DIGI - UIW Work 09
63
DIGI – ÚP
Data úřadu práce do nárok. podkladů
1
64 65
DIGI – ZVS EVCZ-ÚČTY
Data ZVS do nárok. podkladů DP
1
Zpětné výplaty deviz. cizoz. na účty v zahr.
1
66
EXEKUCE - KARTY
Exekuce
1
67 68
INV1 JHOD (důch. ES)
Zastavování I důchodů
1
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.
1
73
ODVLEC
Odškodnění podle zák.č.172/2002 Sb.
1
34
jiţ
Celkem
Centralizov ané
Oblast/zkratka
o
dávkách
DP
s
1 1 1 1
1
Pomocné programy pro údrţbu dat Aplikace pro sledování výplat na účet, které jsou jen ze zpracování ÚSP nebo ze zpracování SU13 a OBST
1
Odškodnění podle zákona č.39/2000 Sb. Aplikace pro výplatu jednorázových doplatků do Bulharska
1
Aplikace pro doplatky do Polska
1
1 1
1
23
Lokální
Číslo
Název aplikace
74
PECE
Evidence péče o osobu blízkou
1
75
PERZ
Odškodnění podle zák.č.217/1994 Sb.
1
76
PHV - vyuţívána archivně (od II/09)
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 85
SUP UI45-DIP jiţ neudrţována
Storno výplat poukázkou
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
90
VDOVY
Vdovy
1
91
VELKOVIZÍR
1
92
ZAHD
Umoţňuje náhled na NP DP Aplikace pro doplatky důchodů na účet v ČR důchodcům ţijícím v cizině
93
ZAHR
Evidence zahraničních důchodů
1
94
ZAVY ZR (zamítavá odb42)
Zákazy výplaty - nDS
1
95
jiţ
Celkem
Centralizov ané
Oblast/zkratka
jen
1
Aplikace pro sledování výplat na poštu
1
1
rozhodnutí
1
1
Zamítavá rozhodnutí odboru 42 Ţivnostenský registr Opravy ve výplatách do ÚPS (úmrtí, změna ÚSP,..)
1
MED
evidence důchodů
1
OBS
práce na obstavených důchodech
1
100 101
RDI DIGI - PDŮCH
registr důchodových informací
1
Data o I důchodech do nárok. podkladů DP
1
102
SED
důch. doklady OSVČ - 2.část konta
1
103
CNB
obraty důchodových účtů pro účtárnu
1
104
CNBA
obraty důchod. účtů pro účtárnu - archiv
1
105
UIP2 (KL)
Oprava datových vět
1
106
KIC
krácení částečných invalidních důchodů
1
107
SLOVENSKO
Slovensko
1
108
WRC
WebDRC
96
ŢR
97
DD
98 99
4. Výplata dávek
1
1
Celkem Exekuce, evidence a realizace exekučních sráţek, zajištění nároků a výplat oprávněným
15
15
109
EXK
110 111
PRIKAZ
Zpracování převodních příkazů
1
PRIKCS
Příkazy z ČSSZ do ČNB
1
112
PZV
Procentní ztáta výdělku
1
113
S357
Odškodnění účastníků odboje
1
114
SLOZENKY
Sloţenky (A)
1
115
SPRIZ UDAVKY
Správní řízení
1
Dávkové programy
1
117 118
UPAV
Zpracování poštovních poukázek typu "A"
1
VYP - DUCH (EKIS)
Výplatní modul - důchodové dávky
1
119
VYP - NEM (EKIS)
1
120
UTM aplikace
Výplatní modul - nemocenské dávky SRD, RDIL, MED, SO, VDOVY, …(staré UTM aplikace)
121
RRP
Registr rodičovských příspěvků
1
116
Lokální
24
1
1
0
Číslo
Centralizov ané
Oblast/zkratka
Název aplikace
122
VYDAJE
Výdajový účet OSSZ
1
123
VYKNE 5. Správa údajové základny
Výkazy nedoplatků
1
124
MALORG
Malé organizace
125
CRP
Celorepublikový rejstřík plátců
1
126
EDS
Elektronický dávkový spis
1
127
ELDZ
Přenos dat do centrál.evidence
1
128
IDV
Informace o dobách a výdělcích
1
129
KE
Kmenové evidence
1
130
KE2
Kmenové evidence
1
131
LPS
Lékařská posudková sluţba
1
132
PSL
Aplikace Posudky pro LPS
1
133 134
ORGAN VPO1
Rejstřík organizací
1
Určování příslušnosti k právním předpisům o SZ
1
135
DRC aktuální
Rozhraní na KE2
1
136
DRC Proxy
Rozhraní na KE2
1
137
OSSZService + KMEN
(přenos pro VZT na okresy)
1
138
SI2
Uţivatelské rozhraní KE2
1
139
Zápis data úmrtí
Zápis data úmrtí do KE
1
140
VZT
Registr pojistných vztahů (PPV)
1
141
IPK
Interní podmět KE
1
142
CRO15
15-letí z CRO do KE2
1
143
CRZ
Změny z CRO do KE2
1
144
TCL
KE2 tenký klient
1
145 146
VPO UI08
Volný pohyb osob
1
Zpracování odmítnutých dokladů na OSSZ
1
147
UI42
DIGI 2P
1
148
UI44
Správa Kmenových evidencí
6. Ekonomické subsystémy
Celkem
25
Celkem
24
149
EKIS
150
INS
Insolvenční řízení
1 3
2
7. Průřezové subsystémy
1
Celkem Elektronická spisová sluţba
ESS
153
Workflow – PŘKPS/WFS
154
DMS
155
Zaručený elektronický archiv 8. Subsystémy oblasti bezpečnosti Celkem
1
1
Podpůrné systémy pro zpracování statistik
152
1 1
Celkem Informační subsystém ekonom. Agend
151
Lokální
1 4
4
0
1
Řídící platforma/Posunovač a prohlíţeč reportů Informační subsystém - evidence, zpracování, vyhledávání a ukládání informací (dokumentů a dat), řízení jejich oběhu, datová integrace.
1 1 1 2
2
0
156
AAA
1
157
PKI
1
158
9. Podpůrné systémy DAK
Celkem Datový katalog
159
DIG
Úpravy aplikací DIGI
1
160
POSTY
Číselník pošt
1
161
WKOCIN
Kontrolní činnost VO na notebooku
1
162
ZPRAVA
Účetní zpráva OSSZ, DP
1
163
CIS
číselníky
1
164
DM Viewer
Kukátko do DMS pro EXK
1
165
ZDV
Prohlíţeč XML datových vět v dbZDV
1
63
49
14
1
25
Číslo
Celkem
Centralizov ané
Oblast/zkratka
Název aplikace
166
APS
Automatizovaná podpora školení
1
167
ASPI
Databáze právních informací
1
168 169
BZD
Prohlíţeč XML datových vět v dbZDV
1
CC
HiPath ProCenter Enterprise (Call centrum)
1
170
Docházkový systém - ústředí, obj. Sokolovská
1
171
Cominfo Cominfo
Objekt OSSZ Zlín
1
172
DBA
správa databanky
1
173 174
DocuLive
Elektronický oběh dokumentů - ústředí
1 1
176
Docházkové systémy pracovišť Rozšiřování Elektronické šablony pro průkazky eltabule Informační tabule VS K. Vary
177
HS
Hotelový systém
1
178
IVD
Informativní výpočet důchodu
1
179
JASU
PC účetnictví JASU pro Windows
1
180
K080
181 182
PAP Janotka (archivní)
evidence majetku (Janotka)-ústředí
1
Projektová kancelář (sdílený diskový prostor)
1
184
PK Platový odb15 PortLink
185
SDP- ústředí
175
183
1 1
1
návrh(šablona)
–
1 e-Podání
1
skenování na scaneru
1
186
SDP- lokality (Quick Scan)
187
SML
Stacionární digitalizační pracoviště na scannerech Fujitsu a Kodak Systém pro evidenci smluv
188
LEPRAK
Tisk samolepících štítků
189
LIBS
knihovny
190
MIS
Malý informační server
191
MOS
podpora K-Softu
192
REK
záznam o reklamacích při akcích
193
RŢP
Registr ţivnostenského podnikání
194 195
Sodex
Objednávky stravenek
1
SPIS STAT
Systém pro správu organizačních směrnic ČSSZ
1
Statistika úspěšnosti výběru pojistného
1
196 197
Lokální
1 1 1 1 1 1 1 1
198
Století a starší (statistika) SYS
správa systému
1
199
Text_do_excelu
různé vstupní soubory
1
200
TV
TV okruh K. Vary
1
201
UNICOS (archivní)
Mzdová agenda
1
202 203
Webtransactions
Komunikace s aplikacemi MF
1
ZDV Browser
kukátko do databáze zdrojových datových vět
1
1
204
WFS
205
PNP
Kukátko do platformy pro řízení procesů a sluţeb Prohlíţeč nárokových podkladů
206
Nprijmy3
Přehled o příjmech - SSP
1 1 1
208
602 Software - XML 602Filler pro RELDP,ELDP09, PRIHL, ONZ, OSVC_PRE, + šablony formulářů PVPOJ, USRCERT AKE3 (KE1160, KE119)
209
CNS
Modulární systém firmy CNS
1
210
ECP
přidělení evidenčního čísla pojištěnce
1
211
EOD
Elektronický oběh dokumentů
1
212
PREV
Převody plateb na příjmovém účtu
1
213 214
PREVZ
Převody zůstatků v kontech plátců
MOD 3001
Komunikační modul SRD x DIGI aplikace
207
26
1 1
1 1
Číslo
215
Oblast/zkratka
Název aplikace
Celkem
OCR - ONZ, PO
Centralizov ané 1
216
SEC
217
SledSpisu - odb43
218
SO
zpracování soudních sporů s důchodci
1
SOP1
Opakované poukazy na účty + obstávky
1
SUC
Aplikace pro stornování plateb na účet v období "po úzavření" PC a VC a před samotným zpracováním těchto výplat přes ČNB.
1
219 220
Lokální
Digi 2P
1 1
Aplikace ČSSZ celkem
220
172
48
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 2010. 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
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
Informa ční systém základní ch registrů
IIS ČSSZ
(PVS)
Jednotné inkasní místo (JIM)
ISZR
Registr osob (ROS)
Registr obyvatel (ROB) Registr územní idetifikace adres a nemovitostí
(RUIAN) Registr povinností (RPP)
…..
28
práv
a
Č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
Obrázek 10 – Účastníci komunikace s ČSSZ
Komunikační vazby IIS ČSSZ na okolí znázorňuje následující schéma:
30
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
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
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 1.7.2011 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
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 31.12.2010 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í 3.1.1
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 č. 159 - Vytvoření informačního a komunikačního rozhraní ČSSZ za účelem poskytování informací klientům“: 34
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: 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. o
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 o
o
síťovou infrastrukturu pro vytvoření komunikačních kanálů a HW rozhraní (přípojů), 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, 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
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 Báze vlastních informačních zdrojů Číselníky a řízené slovníky
Elektronická výměna dat
Portálové aplikace
Vstup-rozhraní na oblast IN
Služby pro zodpovězení dotazu
Programem zdarma Z aplikací třetích stran
Služby pro vstup dat do procesu ČSSZ
SW nástroj pro vyhledávání
Z datové schránky
Ověření oprávnění přístupu
Podpora klientů
Řízení kompletace dotazu , rozhraní s aplikacemi ČSSZ
Nástroj pro management problémů
Zaslání dotazu Virtuální schůzka Aplikace Poradenství – Call desk
Poštou na trvalou adresu Do datové schránky E-mailem
Zpracování dat
Návody, scénáře
Call centrum
Výstup–rozhraní na oblast OUT
Logování transakcí
Nástroj pro monitorování procesu informační podpory
SMS zprávou na mobilní telefon
Nástroj pro monitorování transakcí
Doplnění funkcionality aplikací Služby aplikací Služby pro zodpovězení dotazu
Komunikace zaměstnanců ČSSZ Vzdálený přístup k aplikacím
Řízení přístupu k externím službám
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
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 e-mailový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 1.7.2011). 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
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 https://bezpecne.podani.gov.cz by pouţili adresu novou, například https://bezpecne.podani.cssz.cz). 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
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
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
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.
3.1.3 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 2005. ONZ – oznámení o nástupu do zaměstnání – od roku 2009. ELDP - sběr ročních evidenčních listů důchodového pojištění (za roky 2004-2008) – od prosince roku 2004. ELDP09 – sběr ročních evidenčních listů důchodového pojištění po změně ZNP - od roku 2009. POS09 – přehled o studiu (náhradních dobách pojištění z důvodu studia) – od roku 2009. OSVČ – pravidelný roční Přehled OSVČ podávaný po odevzdání daňového přiznání – od roku 2006. 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 2008. UserCert - Oznámení kvalifikovaného certifikátu - Hlášení změny kvalifikovaného certifikátu pověřeným pracovníkem - od července 2009. PVPOJ - Přehled o výši pojistného a vyplacených dávkách zaměstnavatelů – od října 2009. EXI_DVK - Data pro exekutory – dotazy a odpovědi na příjem pro potřeby členů Exekutorské komory od dubna 2010. NEM_PRI – Příloha k ţádosti o dávku nemocenského pojištění – od konce dubna 2010. Č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 3000 - 5000 podání, ve špičkách aţ 12 000 podání denně. Jedno e-podání obsahuje data 1 1500 formulářů (průměrně 7 formulářů). V roce 2009 bylo přes PVS přijato téměř 5 400 000 formulářů, z toho převáţný podíl tvoří formuláře ELDP (cca 3 400 000, coţ odpovídá 60% všech ELDP doručených na ČSSZ) a ONZ, resp. P/O (cca 1 900 000). 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 4 000 formulářů; příjem zahájen v říjnu 2009), Jednotný registrační formulář z MPO ČR (cca 200 000 formulářů) a aktualizace Rejstříku ţivnostenského podnikání RŢP z MPO ČR (1 soubor kaţdý všední den).
3.1.3.1
Ř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
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
DIS subsystém a jeho funkcionalita v současné době Exekutorský úřad
MPO ČR
VK
EL D ON P, P O OS Z /P STP VC RIH PV _PR L P Us OJ E rce rt
Od po v
Vnější prostředí PVS
Klient
ELDP,
ONZ /PR
DMZ
ěď
EX I_ D
RŽP JRF
CD, disketa
ISDS
EX I
Klient (Zaměstnavatel OSVČ)
DIS server
SDS server
IHL
Prezentační vrstva
DISView
Referent
RAUI Podatelna SDS
Klient RŽP
P RŽ
Nahrávání RZP
SDS systém DS AAS Správa podávajících
RZP INP
ní XM
L
DV
Aplikační a datová vrstva
E-mail
Epo dá
DIS systém Mail systém pro odpovědi
DB DIS Data Stavy
al
Odpověď EXI
PŘK PS
zápis
do M a
lorg
ONZ, PR IHL, OSVC_P RE
OSSZ Solaris
LokálníINP DB Malorg OSVČ wsZDV ZDV PVP OJ
SAP INP konto příjemce
ONZ/PR IHL pořízen é klien tem BAMVZT
převz POJ
WS…
API DMS
DMA
SPS
OSSZ BTS
kace Notifi
ON OS Z /P VC RIH PV _PR L Us POJ E rce rt
EL DP
wsRkz INP
K EXI_DV
,P OS TP
Noti fikac e
Posu nova č
DIS systém vnější systémy okolní systémy ČSSZ probíhá implementace napojení na DIS
POJ
plánováno nová funkčnost
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 epodá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
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 epodá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
DIS server (část DIS subsystém)
VREP server (část subsystému DIS)
Vrstva řízení přístupů
DSS server (část subsystému DS)
AAA
Prezentační vrstva
Subsystém IN
DIS View
DMS podatelna
DMS klienti
Elektronická podatelna
ZDD
VZT klient
Podatelna SPS
Procesní aplikační podpora VZT
Vyhledávání a reporty
?
INNP
PŘKPS posunovač
…...
POJ NEM
OCR DMS app
SDP SDS
NEMWF
VREP
POJINT
KL DIS systém
?
Aplikační vrstva
VZTWF
IPKWF Služby pro e-podání
Raui/AAS
?
SPS
INS
Události INS
DIS Stavová DB …….
INP Datová vrstva
ZDV
KL
OA
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
Ú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.
3.1.4
Ř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ů. 3.1.5
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 e-mailem. 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í, email) 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 emailem. 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í, e-mail). 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 e-mailem, e-mailová 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
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á e-mailem) – 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í
E mail
Papírové vypravení
e-podatelna e-výpravna
Pracovníci podatelny
Elektronická Spisová Služba
Česká pošta
Papírové podání
Referenti
Odborné aplikace
podatelna DS Instance Ústředí
Osobní podání
DIS Systém
E mail
Papírové vypravení
e-podatelna e-výpravna
ATN
Pracovníci podatelny
Referenti
DMS (CM)
podatelna DS
Archiv tiskových výstupů (CMoD)
Papírové podání
KE
interní výměna dokumentů
Elektronická Spisová Služba
Komunikační platforma + cache Česká pošta
DSS Server
výpravna 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
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í.
3.1.6
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. 3.1.6.1
„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 154 - „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
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
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.
3.1.6.2
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
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 – 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.
NPAP
Č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
ČSSZ
ČSSZ IN/OUT VSTUPNĚVÝSTUPNÍ KANÁLY
Access management
Vnější služby fronty
workflow
I A M
fronty Webic – www rozhraní
SPISOVÁ SLUŽBA
AAA DB CERTIFIKÁTY
AGENDY VPO
DMS PLATFORMA
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
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 5.2 64-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 2.3.
51
AP ČSSZ
sTESTA
Ostatní české AP (národní komunikace)
Jiné organizace výužívající týž AP
Firewall AP
EMS
EMD
WEBIC MLS Console
Adresářový server Lokání databáze
Information Repository
Extranet
Firewall ČSSZ
Vnitřní síť ČSSZ
Oblast IN Vrstva Acccess Managementu ČSSZ
Aplikační vrstva PROCESY FRONTY
Zaměstnanci ČSSZ SPISOVÁ SLUŽBA
AGENDY
VPO
DMS 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. 3.1.6.3
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
CN
sTESTA AP CMÚ
AP MPSV
AP ČSSZ fw IPAP
IPAP F w
NPAP
sTESTA
IPAP F w
NPAP
NPAP
sTESTA
fw
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
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
Interní systémy ČSSZ zapojené do komunikace prostřednictvím Access pointu ČSSZ
Centrální registry
Kmenové evidence
Důchodová oblast
VZT
Nemocenské pojištění
Výběr pojistného
NEM
POJ
MainFrame
EDS
DNP
LPS ZDD VPO
EPN EXK
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. 3.1.6.4
Technické požadavky
Síťová infrastruktura Síťová infrastruktura bude zajišťovat následující funkčnost: 55
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 1
Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací atd. 1.1
3.2
Projekt
Subsystém Název
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 (e-mail), 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)
1.3
Ř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ů.
Strukt. Fondy Č. 157,159.15 4
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
-
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ů.
3.2.1
Projekt - Výběr pojistného (POJ) – (subsystém ISS 2.1)
Aplikační podpora POJ je provozována od počátku roku 2009. 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 2008. Šlo fakticky o plnění z roku 2008 a 2009, které bylo z důvodu čerpání prostředků rozděleno i do roku 2010. 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 2.2.10 (31.7.2009) 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 POJ klient /tenký klient/
KLIENT
Datum poslední aktualizace
13. 8. 2008
Datum vytvoření
13. 8. 2008
Pořadové číslo (verze)
1
Stav v produkci
od 1. 1. 2009
AAA
NEM
KE2 (SI2)
VZT
APLIKAČNÍ ČÁST
DMS
NP
ZDV
ZAME SPOL
AAA proxy
Legenda Klient
SAP
MIS
Okresní aplikace
Aplikační část Serverová část aplikace Aplikační rozhraní DB schema
DATA
pojWeb
INP1
Databáze
pojCore
Vnější aplikace / oblasti
pojNP
Přímé volání WS
pojSdk
Vazba přes WF
pojZame
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ů. 3.2.1.1
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
3.2.2
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 1.1.2008 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 2010. 3.2.2.1 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
KE2 Náhled dlužník
Další aplikace Příznak Insolvenčního řízení podle rejstříku (automaticky bez zásahu Pověřence)
SDD
Příznak Likvidace organizace
Postup Insolvenčního řízení
EXK
Likvidace organizace
Náhled - zajištění
INS
EDS
Titul Změny úhrad Další údaje viz popis rozhraní
SPR Přihlášení / uplatnění titulu do IŘ
Aplikace původu Vymáhaných pohledávek
Náhled - úhrady - splátky
POJ
Postup vymáhání
Infrastruktura
Přeplatky ATR
DMS
ATV
Data pro statistiky
Centrální Data DP OSVČ
Centrální Lokální
SPRIZ
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
Nemocenské pojištění
OSVČ
Organizace POJ
OSVČ DP OSVČ
Organizace POJ
Ostatní (správně provozní činnosti)
správní
V projektu nebude řešeno
V projektu nebude řešeno
V projektu nebude řešeno
V projektu nebude řešeno
V projektu řešeno V projektu řešeno V projektu řešeno V projektu řešeno V projektu ř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 řešeno
nebude
V projektu nebude řešeno
V projektu nebude řešeno
V projektu nebude řešeno
V projektu nebude řešeno
V projektu řešeno
nebude
(pokud neplatí tak není pojištěn)
Pojistné Penále
POJ
Přiráţky k pojistnému Přeplatky Pokuty
IS kde pohledávka vzniká Důchodové pojištění
POJ Přeplatky
Regresy
DP OSVČ
POJ
DP OSVČ
POJ
Přeplatky
nebude nebude nebude nebude nebude
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
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í. 3.2.2.2 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
Projekt
Výběr pojistného 2.1
2.2
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Č 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
3.3.1
Informační subsystém důchodových agend
3.3.1.1 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 200 000 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 Eformuláří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
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 2 800 000 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 50 000,- 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
Obrázek 26 - Vstup nových žádostí do subsystému
3.3.1.2
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 2009. 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
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ů 3.3.1.3
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
3.3.1.4
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 SQ100. 3.3.1.5
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
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.
3.3.2 3.3.2.1
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. 2005. 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
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 1.1.2009 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 2010. 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 INNP
NEM
/tenký klient/
/tenký klient/
Datum poslední aktualizace
28. 1. 2009
Datum vytvoření
12. 5. 2008
Pořadové číslo (verze)
3
Stav v produkci
od 1. 1. 2009
KLIENT
AAA
DMS APLIKAČNÍ ČÁST
NEM INNP
DNP
POJ EPN
VYP
Local VZT
KE2 (SI2)
ZDV
Legenda Klient Aplikační část
DATA
Serverová část aplikace
INP
Aplikační rozhraní
NEM
DB schema Databáze
KEVDRC´
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 1. 1. 2010. 3.3.2.2
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 epodá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
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
ISDS SPECIALISTA
DATOVÉ SCHRÁNKY ČSSZ
3 .4
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
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. 3.3.2.3
Další rozvoj aplikace
Další rozvoj aplikace pro rok 2010: Případná alokace finančních prostředků bude do těchto oblastí:
3.3.3
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
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 Výplata dávky
VYP
Statistika
Kontrola
LPS
Výběr pojistného
Výpočet dávky
OUT
Pojistná událost
AAA portál
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
Správa dokumentů
Procesní workflow
Poskytování informací Správa tiskových výstupů
Příjem podání Přehledy, žádosti...
Správa pojistných vztahů
Správa informací o účastnících pojištění
Přehledy, žádosti, výměry...
Řídící informace
Dotaz, žádost o informaci
Požadované informace
Pojistné vztahy plátce Údaje o platbách ÚP
Výběr pojistného
Kmenové údaje plátců
Výkazy. statistiky
Platby pojistného úrazového pojištnění
Správa dávek úrazového pojištění
Prvotní doklady k zaúčtování
Účtování o výběru pojistného
Potvrzení výplaty Výplata dávek
Požadavky, aktualizace
Pohledávky platby
Prominutí, nedobytnosti
Podklady, podněty
Platové výměry, Pokuty
Žádost o výplatu
Kontrolní činnost
Správní řízení
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ů. 3.3.4
Lékařská posudková služba (LPS)
Lékařská posudková sluţba (LPS) ČSSZ a LPS úřadů práce jsou od 1. 7. 2009 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 1. 7. 2009 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.
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
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 2009. 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
KLIENT
EXK klient
ATR klient
/tenký klient/
/tlustý klient .NET/
Datum poslední aktualizace
28. 1. 2008
Datum vytvoření
24. 9. 2008
Pořadové číslo (verze)
2
Stav v produkci
od 1. 1. 2009
AAA
KE2 (SI2)
ZDV
APLIKAČNÍ ČÁST
EXK
EXK - ATR
TSK
EDS_Codelist
OSV
ADM
VST
DP
SUK
PreS
DaV
Legenda
Scheduler Service
Klient
ATV
Aplikační část Serverová část aplikace Aplikační rozhraní DB schema
DATA
ADB
ADB EXK
ATREXK
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
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 3
Projekt
Správa dávek důchodového a nemocenského pojištění
3.1
3.2
Informační subsystém důchodových agend – Evidence byly zajištěny důchodů v rozsahu základních informací o druhu důchodu, všechny nezbytné výši, poţivateli; správa dávek důchodového pojištění. úpravy vyplývající z Parametrických změn 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 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 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.
3.3
Informační subsystém agend úrazového pojištění – Od 1.1.2013 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ů.
3.5
Rozvoj aplikační podpory PSL
Komunikace s MPSV
Informační subsystém exekucí dávek
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
Technické zhodnocení zdokonalování programového vybavení
Provozováno rutinně.
a
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í.
3.4.1
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. 2006. 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 1.1.2009, 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 Klient SAP
Klient SAP
/tenký klient/
KLIENT
/tlustý klient/
Datum poslední aktualizace
24. 10. 2008
Datum vytvoření
24. 10. 2008
Pořadové číslo (verze)
1
Stav v produkci
nasazeno
AAA
APLIKAČNÍ ČÁST
NEM
VYP1 Převzetí požadavků na výplatu dávky
VYP4
VYP3 Zpracování zpětných informací
VYP2 Sestavení výplatní dávky (předpisu)
Poskytování informací
VYP5 Vytvoření platebního souboru
KE2 (SI2)
Legenda
Změna parametrů výplaty Klient Aplikační část Serverová část aplikace Aplikační rozhraní DB schema
DATA
Databáze
Nativní databáze SAPu
Vnější aplikace / oblasti Přímé volání WS Vazba přes WF Přímý zápis do/čtení z DB
Obrázek 35 - I/O Picture VYP
Další rozvoj aplikace pro rok 2010: 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
Projekt
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
Provozováno rutinně Od 1.1.2013
3.5 3.5.1
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í. 3.5.2
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
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
24. 9. 2008
Datum vytvoření
12. 5. 2008
Pořadové číslo (verze)
2
Stav v produkci
Nasazeno
KL Klient – UIP2 /tlustý klient .NET, C#/
KLIENT
AAA
VZT
KA Tray and WS
KAService (instance A, B)
Notifikace z externích oblastí
UIP2Wrapper
APLIKAČNÍ ČÁST
KLInterface
DMS
SI2 KE2 UI44
ZDV
BAM Statistiky KL Report server
Legenda
MS SQL Server
Klient Aplikační část Serverová část aplikace
DATA
Aplikační rozhraní
INP1
DB schema
KL
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
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
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 14. 5. 2008 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/03.06189. 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ě 750 000 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.
3.5.3
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 1. 1. 2009 (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
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. 3.5.4 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. 3.5.5
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 2007. 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). 3.5.6
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
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í. I/OPicture KE2 ZUM
CRZ
WRC
/tlustý klient .NET/
/tlustý klient .NET/
/tenký klient /
Klient
UI44
/tenký klient/
/tlustý klient .NET/
Datum poslední aktualizace
28. 1. 2009
Datum vytvoření
12. 5. 2008
Pořadové číslo (verze)
2
Stav v produkci
Nasazeno
KLIENT Legenda APLIKAČNÍ ČÁST
Přímé volání WS
AAA
Vazba přes WF
KL
BAM
ZDV
Přímý zápis/čtení do DB
Okresní aplikace AKEO_OSVC
TCL
AAA proxy
UI44
AKE AKECT
DRC AKTUALIZEKE
SI2
RPL
TC2
KE100
POJ
NEM
ZDD
EXK
VYP
Staré aplikace (UI45-INP, ZOCR,OCR T23, T9, T4,T5,T10,T11,DIGI-UIP, UI42, WORK05, WORK09,ZVS,DOPOJ,DIGIOSOKR,DIGI-UP, Pece, PDUCH, DRC01, INP02, INP03. UIW) 10.6 Staré aplikace (VZT-Malorg, KL, CRO15, VPO, K116, K1160, ZPO, ZPO-II) 10.6
KE019
VZT08
DMS
VZT
TC1 Staré aplikace (pořizovací linka, DOCR) 10.6
KE116
Legenda
IPA1
KEVAKT
INP1
KEVDA
Klient Aplikační část
DRC Aktualni
KEVAPR
Serverová část aplikace Aplikační rozhraní
KEVDB
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 1.1.2009. 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
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
KLIENT
VZT Klient
UI08
/tlustý klient .NET/
/tlustý klient .NET/
Datum poslední aktualizace
28. 1. 2009
Datum vytvoření
15. 12. 2008
Pořadové číslo (verze)
2
Stav v produkci
od 1. 1. 2009
AAA
BAM
KL
NEM
POJ
APLIKAČNÍ ČÁST
DMS OSSZService
WebServices Winws
VZTInterface
ZDV ZM
TC1
KOCIN
Legenda Klient
KE2 RPL
Aplikační část
SI2
UI44
TC2
TCL
Serverová část aplikace Aplikační rozhraní DB schema
IPA 1
DATA
Databáze Vnější aplikace / oblasti
VZT08
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 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ů.
variabilního symbolu. Začátkem
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
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
Projekt
Správa údajové základny 5.1
Informační subsystém důchodových agend – Evidence doba přechodu na nárokových podkladů v rozsahu základních informací systém činí 4 roky 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.
5.2
Informační subsystém Registr pojištěnců (Kmenové evidence), rutinně provozováno plátců pojištění.
5.3
Informační subsystém Registr pojistných vztahů (VZT).
3.6
rutinně provozováno
Oblast 6 Ekonomické subsystémy
3.6.1 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 2003 – 2004, 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
nový
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 6
Projekt
Ekonomické subsystémy 6.1
6.2
3.7
Informační subsystém ekonomických agend (EKIS) – Rutinně provozován Evidence údajů správního účetnictví a dávek sociálního pojištění outsorsing, rozvoj. 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. Podpůrné subsystémy pro Zpracování statistik Rutinně provozováno rozvoj.
Oblast 7 - Průřezové subsystémy
3.7.1 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
–
–
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
Tečkovaně = vize -navržený systém
DSS DSS
DMS
KE2
NEM
Další aplikace v APP VYP
ZDV
INNP
PŘKPS
W FS Pr oh líž
A A A
Řízení publikování a verzování služeb PŘKPS (MSE)
Reporting Services
84
Komunikační logika a business logika
Služby stavové databáze
Komunikační logika a business logika
DSS
NEM Orchestrace a WS
ECD
DIS Orchestrace a WS
POJ Orchestrace a WS
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
3.7.2
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
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 e-mailem. 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 k celkovému sníţení nákladů na tuto činnost.
3.7.3 3.7.3.1
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
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ší. I/OPicture DMS KLIENT
Aktivní klient
Univerzální klient
Podatelna
ZDD
/tenký klient/
/tenký klient/
/tenký klient/
/tenký klient/
Administrační klient DMS /tenký klient/
Datum poslední aktualizace
28. 1. 2009
Datum vytvoření
15. 12. 2008
Pořadové číslo (verze)
2
Stav v produkci
nasazeno
AAA
AAA
APLIKAČNÍ ČÁST
KE2
CSSZAdminClient
ZDV
WebArchive
Staré aplikace (DIGI, OCR, T11)
API DMS NEM
CSSZPodatelna DMSViewer
ZDV
Image server
ZDD
KE2
CSSZActiveClient
VZT
KL
Legenda Klient
RM
Aplikační část
POJ
Serverová část aplikace Aplikační rozhraní DB schema
DATA
DMA DMAP1
DMAP2
Databáze Vnější aplikace / oblasti Přímé volání
SAN Vazba přes WF
Diskové pole
Přímý zápis do/čtení z DB
Obrázek 43 – I/O Picture DMS
3.7.3.2
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áří 2010. 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 30.9.2010. 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
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 9.2.0.8 U tohoto produktu standardní podpora jiţ skončila 31.července 2007 (URL: http://www.oracle.com/database/index.html). Nyní vyuţíváme extra placenou rozšířenou podporu produktu Oracle 9i, zaplacenou do 30. července 2010.
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 9.2.0.7.0 na 10.2.0.4.0, změna verze produktu IBM DB2 Content Manager ze stávající verze 8.3 Fix Pack 10 na 8.4.2. 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
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
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
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.
3.7.5
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 - 2010 – 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
Klient
Notebook
KOC
Offline klient
WinForm
Truecrypt Data
Klient
WinForm
Offline klient
Truecrypt Data
Plán
Příprava kontroly
Okolní aplikace Statistiky a výstupy
Výsledky kontrol
...
POJ
Asynchronní příprava kontroly Vazba
Výsledky kontrol
Data
Plán
Synchronizace offline dat Datový tok
Data pro kontrolu
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í
KLIENT KOC VZT Plán
Kontrola
KE2
Tisky
«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
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 2010
93
Oblast Subsystém Název 7
Projekt
Průřezové subsystémy 7.1 7.2
7.3
7.4
7.5 7.6
3.8
Workflow – PŘKPS (Posunovač)
Základní část ověřována v rutinním provozu, plánuje se rozvoj Elektronická spisová služba (ESS) Řeší projekt 157 - Elektronická podatelna a výpravna ČSSZ v návaznosti na systém datových schránek Informační subsystém Document Management V rutinním vyuţívání, migrace na System (DMS) - evidence, zpracování, vyhledávání a výkonnější platformu, rozvoj ukládání informací (dokumentů a dat), řízení jejich oběhu, datová integrace. 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/2012. Plánovaná centralizace aplikace Kontrolní činnost (KOCIN) Vytvoření nového centralizovaného subsystému. Elektronický spis – jeho koncepce a implementace Vytvoření nového subsystému.
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
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:
3.8.2
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 17799.
3.8.3 3.8.3.1
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
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, Telefonní Datové Mailová 3.strany, komunikace komunikace schránky EESSI
Veřejnost, 3.strany
Portál
DIS
Call Centrum
Elektronická podatelna
DSS
Klientský portál
Komunikační kanály
Ruční vstupy
AAA portál – RO IAM
4
Role, uživatelé, viditelnosti,Klasifikace dat
Platforma pro kontrolu a řízení procesů a SOA služeb v oblasi IN
DIS
Evidence, transformace, konsolidace dat, systém front
pro komunikaci s aplikacemi
Ruční Aplikace zpracování
E-podatelna
E-výpravna
RO databáze
Spisová služba
2
Rozhraní a pomocné služby
3
Jádro portálu
5
Rozhraní
…...
POJ
NE.
DMS
1
Exchange Kmenové evidence Registry
Databáze
Master IAM Role, uživatelé, viditelnosti, Klasifikace dat
0
Obrázek 48 - Portál ČSSZ a kontrola identit
3.8.3.2 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
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
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. 3.8.3.3
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
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 8
Projekt
Subsystémy oblasti bezpečnosti
8.1
Informační subsystémy oblasti bezpečnosti – Správa technického zhodnocení uţivatelských účtů a přístupů AAA portál PKI, stávajícího řešení AAA portálu monitoring, průchozí systémy. rozšířit funkcionalitu Další rozvoj:
3.9
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ů.
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 1.1.2010 byla vytvořena aplikace ke sledování průběhu odvolacího řízení a získávání statistických údajů.
99
Oblast Subsystém Název 9
Projekt
Podpůrné subsystémy 9.1
9.3
Podpůrné subsystémy – Help Desk, Call Desk, Docházkové systémy, Elektronické vzdělávání, Vývojové prostředky, Vyvolávací systémy a řada dalších jako např. personální aplikace ASP pro účely optimalizace a automatizace administrativních činností pořádání školení ve VS ČSSZ, podpora Call centra - aplikace HPPCE (HiPath Procenter Enterprise), ASPI. Informační subsystém v oddělené doméně pro zpracování auditních informací. Námitkové řízení
9.4
Vývojové prostředí a prostředky
9.2
100
pilotní provoz elektronické evidence docházky v ústředí a následně postupné rozšíření v rámci celé ČSSZ v provozu v provozu
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
Obrázek 51 – Struktura centrálních pracovišť
4.2.1
Datová vrstva
V současné době jsou data ukládána na lokálně oddělených pracovištích označovaných KP0 aţ KP2, která jsou propojena výkonným síťovým propojením: V nově budovaných datových úloţištích v rámci datových a komunikačních center na dvou lokalitách (hlavní KP1 a záloţní KP2) jsou umístěny hlavní databáze ČSSZ jako jsou Individuální konta pojištěnců, Kmenové evidence a data o pojistných vztazích, a data pro podporu všech nově realizovaných centrálních aplikací jako je NEM, POJ, VYP atd. V datovém úloţišti „bussines server SQ100“ (dále SQ100) technologie vybudovaném při řešení úloh v důchodové oblasti s evidencí dat o výpočtu důchodu a jeho výplatě označované jako KP0. V datovém úloţišti vybudovaném na podporu digitalizace v ČSSZ, kde je spravován zejména optický archiv s cca 196 mil. obrázky dokumentů a data Dokument management systému (DMS) situovaném v KP1. V decentralizovaných datových serverech na regionálních pracovištích, kde jsou uloţena data pro tyto lokální agendy. V oblasti ekonomických dat (EKIS) v rámci outsourcovaných kapacit. Hlavním cílem v datové oblasti je zkonsolidovat, sjednotit a integrovat technologie datových úloţišť (dále DÚ) na bázi nově budovaného DÚ při dodrţení zásady ochrany jiţ vynaloţených investic, sjednocení zabezpečeného přístupu k datům a vytvoření podmínek pro jednotnou datovou základnu ČSSZ. Proto je orientace dalšího rozvoje zaměřena na rozvoj hlavního a záložního datového úložiště budovaného na technologii progresívních diskových polí v provenienci IBM. Tato byla navrţena jako funkční celek, kaţdé s formátovatelnou kapacitou 46 TB a jsou vybavena databázovými servery, kaţdý s kapacitou 10 procesorů (rozšiřitelnou aţ na 16 procesorů). V roce 2009 bylo rozhodnuto nepokračovat v rozšiřování výše uvedených technologií Shark a byla zaloţena nová řada technologických komplexů diskových polí a datových serverů. Počátkem roku 2010 byla obě úloţiště KP1 a KP2 posílena instalací nové řady diskových polí s kapacitou 36 TB a novou řadou serverů na bázi IBM Power 595-FHA s celkem 8 procesory. Tím byla kapacita diskového prostoru rozšířena na 82TB a servery s 10 + 8 procesory nové řady. Tato nová řada poskytuje moţnost plynulého rozšiřování do roku 2014. Bylo tím dosaţeno i záměru postupné inovace střídavou obměnou starší sady serverů a disků novou generací. V oblasti datových úloţišť jsou vybudována tři prostředí – integrační pro integraci aplikací a doladění jejich vazeb, školící a testovací pro účely ověření funkčnosti aplikací uţivateli a produkční prostředí. Tato prostředí jsou provozována odděleně s tím, ţe postup nasazování aplikací a jejich uvádění do rutiny musí probíhat v uvedené posloupnosti. V současné době jsou tato prostředí dostatečně pokryta HW prostředky. Rozšiřování kapacity centrálního DÚ a jeho naplnění se předpokládá postupně do roku 2014 s tím, ţe další zásadní technologická inovace se předpokládá po tomto roce v souladu s výše uvedenou strategií střídavé obměny technologických řad diskových polí a serverů.
102
Stará DÚ v oblasti SQ serveru, vyuţívaná na digitalizaci důchodových agend budou vyuţita do skončení ţivotnosti – pouze k archivaci a uloţení méně důleţitých dat. Je nutno počítat s perspektivním propojením SQ serveru s diskovými poli. Diskové kapacity na regionálních pracovištích překračují dobu ţivotnosti ale jejich údrţba a zachování je nutná do doby vyuţívání UNIX serverů (2014). V rámci datových úloţišť je při správě extrémních objemů dat nezbytná i zálohovací technika a technologie. Byla proto zpracována koncepce pro vytvoření centrálního zálohovacího systému pro všechna datová úloţiště, které je nutno vybudovat nejpozději v roce 2011.
Obrázek 52 - Současné uspořádání datového úložiště KP1/KP2 Rozvoj CDÚ
Rozvoj centrálního datového úloţiště bude probíhat zvyšováním výkonnostních a kapacitních parametrů stávajících DÚ v rozsahu asi 10% pořizovací ceny DÚ ročně. Na údrţbu DÚ bude nutné počítat s 10% pořizovací ceny. Současně se počítá s proporcionálním rozšiřováním kapacit v rámci rozvojových projektů ze strukturálních fondů. V souladu s dlouhodobým plánem jde o tyto akce, které zabezpečí patřičné sluţby aţ do plánované velké technologické inovace v letech 2014 – 2016.
upgrade databázových strojů a pořízení Midrange diskových polí - jiţ realizováno - leden 2010, upgrade Enterprise diskového pole v lokalitě KP1 – přelom 2010/2011, upgrade Enterprise diskového pole v lokalitě KP2 – přelom 2011/2012, zálohovací technologie optimalizace řešení – přelom 2011/2012.
Zároveň je nutné pracovat na přípravě velké technologické inovace, kde je třeba zohlednit zkušenosti 103
získané při prvním inovačním kroku v letech 2004/2005. Jde především o tyto aktivity :
4.3
Určit sluţby jednotlivých technologických vrstev CDÚ – zálohovací sluţby, databázové stroje, prostory Oracle, prostory MS SQL, fileservery, SAN a NAS. Určit okruhy na sobě nezávislých technologií, tak aby bylo moţno optimálně vyuţít institutu Veřejné zakázky pro pořízení technologií. Jiţ s předstihem ( nejpozději začátkem roku 2013 ) zadat studii na tuto inovaci zaměřenou především na ekonomickou část. Musí určit míry rizika, ekonomickou výhodnost různých variant a nedílnou součástí musí být téţ příprava Výběrových řízení.
Centralizovaná aplikační vrstva V současné době je zabezpečována
Centralizovaným systémem bussines serveru na bázi modelu SQ100 s procesory INTEL a výkonností 130 RPF. Servery zabezpečujícími zpracování nárokových podkladů a ukládání dokladů v optickém archivu a nově budovaném Document Management Systému. Nově budovanými 2 serverovými farmami, obsazené 308 + 2 aplikačních HP Blade serverů typových řad ProLiant DL360, HP BL20p, HP BL460c a HP BL 680c.. Na serverech jsou provozovány všechny nové aplikace v rutinním provozu jako je DMS, ZDD, KE, VZT, značná část AAA portálu, platforma BizTalk, NEM, část EKIS a dále probíhají přípravy přechodu do rutiny u aplikací POJ, EXK a na části serverů jsou provozovány aplikace „starší“ jako je KL a digitalizační procesy. Decentralizovanými Risc servery na jednotlivých regionálních pracovištích se svými lokálními databázemi. Outsourcovanými kapacitami v oblasti ekonomických dat (EKIS).
Orientace dalšího rozvoje je dále zaměřena na oblast serverových farem instalovaných v datových a komunikačních centrech s technologií špičkových serverů, které jsou na bázi plně fault-tolerantních systémů. Budou instalovány i nadále v hlavním a záloţním datovém centru. Další rozvoj bude zaměřen na redukci počtu těchto serverů ve prospěch zvyšování jejich výkonu s orientací na servery se špičkovým výkonem. Tyto systémy pak vytvářejí z hlediska ČSSZ virtuální vysoce škálovatelný systém, zajišťující vysoký výkon, který flexibilně vyuţívá jednotlivé servery v závislosti na poţadavcích aplikace a transakčního výkonu. Na této platformě bude i nadále vyvíjen, testován a provozován nově vytvářený aplikační software na principu SOA v souladu s cílovou architekturou. Dále bude vývoj orintován i na technologii SQ100 serverů platformy Linux a Windows .NET. Spolu s datovým úloţištěm umoţní obsluhu jednotlivých úloh dle stanovené priority. Servery serverových farem pracují na operačním systému Microsoft Windows 2003 server a v malém mnoţství na bázi Linux a cílově je připravován přechod na Windows 2008. Server SQ100 zatím pracuje na bázi operačního systému BS2000. V oblasti serverových farem jsou také adekvátně DÚ vybudována tři prostředí: integrační pro integraci aplikací a doladění jejich vazeb, školící a testovací pro účely ověření funkčnosti aplikací uţivateli a produkční s vazbou na datové úloţiště. Tato prostředí jsou provozována odděleně s tím, ţe postup nasazování aplikací a jejich uvádění do rutiny musí probíhat v uvedené posloupnosti. Produkční prostředí je vybaveno 188 ks serverů, školící a testovací prostředí, 47 ks integrační prostředí 61 ks, , rezerva 12 ks. Celkem tedy 308 ks serverů. Dosavadní zkušenosti s provozováním prostředí ukazují, ţe bude nutno realizovat ještě nejméně jedno prostředí. A to pro infrastrukturu, kde bude nutné ověřovat změny v průřezových aplikacích jako je AAA protál, DMS, a BizTalk, které je nutno, vzhledem k jejich charakteru, testovat odděleně od ostatních aplikací.
V současné době kapacitně zbývá 12 serverů, která je z pohledu zajištění provozu nově realizovaných agend a zpracování zcela nedostatečná. U důchodové agendy je nutno předpokládat přechodné období 4 roky, kdy bude muset být v provozu jak dosavadní systém provozovaný pod operačním systémem (pod BS 2000) tak i nový systém pod Windows. Tuto situaci řeší inovace provedená náhradou Mainframe SX serveru za SQ Server na bázi Intel, který umoţňuje provoz operačních systémů BS2000, 104
WINDOWS a Linux (po nezbytném doplnění těchto komplexů – v současné době je to pouze platforma BS2000), souběţně provozovat staré a postupně nasazovat nové aplikace a moduly, vyřešil ukončení Mainframe v plánovaném termínu tj, do konce roku 2009. Tento server výkonově dosahuje několikanásobného výkonu stávajícího Mainframe, sniţuje o 20% stávající finanční nároky na provozování Mainframe a řeší plynulý přechod mezi starým a novým systémem od roku 2014. Dále se plánuje přechod na cílový operační systém Windows 2008 R2 s 64 bitovou verzí. „Cílem je virtualizace serverů bladových farem, zvýšení výkonnosti a spolehlivosti při současném sníţení jejich počtu min. o cca 25%“ V oblasti blade farem:
obnova starých technologií, tj. serverů 200 ks HP BL20, později i 92 ks HP BL460 a jejich nahrazení výkonově silnějšími a hospodárnějšími stroji, zahájení procesu virtualizace aplikačních serverů a tím i absolutní sníţení jejich počtu s positivním dopadem na výši provozních nákladů, obměna UPS bladových farem, včetně jejich bateriových modulů, komunikačních prvků, obměna UPS obou datových úloţišť (SDÚ a CDÚ IBM) včetně jejich bateriových modulů, komunikačních prvků, obměna klimatizací ve všech lokalitách (mimo KP3), přechod aplikací na vyšší OS, obměna HW u OCR linek, jejich serverů a leaderů, obnova centrálního sběru dat DCPA. Rozvojové úkoly jsou zaměřeny na inovaci alokací finančních prostředků do těchto oblastí:
4.4
Technické zhodnocení aplikačních serverů náhradou nejstarších modelů špičkovými servery alokovatelnými do současných skříní (s předpokládaným vyuţitím principů virtualizace i moţností provozování více aplikací na jednom serveru). Licence software - technické zhodnocení, zaloţené zejména na zavedení operačního systému Windows 2008 64 bitové verze. Obnova ostatních aplikačních serverů současně s jejich konsolidací s cílem zmenšit jejich počet. Doménové servery, Proxy a SQL servery, Exchange servery – pokračovat v obnově kritické infrastruktury na bázi špičkové technologie. Bezpečnost, AAA portál – pokračovat v rozvoji technologické platformy jak pro oblast ITAM tak zejména oblast ITIM výkonnou a spolehlivou technikou. Integrace do struktur EU – zabezpečením přístupového bodu potřebnou serverovou technologií. Zabezpečit záměr vybudovat Rozhraní pro komunikaci ČSSZ se svými klienty a nadále podporovat SOA architekturu potřebnou pro další rozvoj centrálních aplikací.
Decentralizované (lokální) uzly IIS
HW a SW podpora a vybavení územních jednotek – je zaloţena na technice, kterou lze rozdělit do několika skupin - infrastrukturní servery, aplikační servery, pracovní stanice a tiskárny. <>Obrázek Kuchař Infrastrukturní servery slouţí k zajištění role podpory infrastruktury na regionálních pracovištích. Jedná se o doménové servery určené k autentizaci uţivatelů a zajištění dalších sluţeb infrastruktury, File servery, které umoţňují ukládání a efektivní sdílení dokumentů v rámci organizační jednotky, včetně zajištění jejich bezpečného zálohování a aplikační servery zabezpečující provoz lokálních aplikací. V organizačních jednotkách budou nadále funkční decentralizované aplikační a databázové servery na platformě Solaris, které s postupnou centralizací dat převezmou funkci cache serverů a umoţní tím sníţit zátěţ síťové infrastruktury. Mezi aplikační servery dále patří servery určené k řízení a zajišťování výměny strukturovaných dokumentů mezi jednotlivými informačními systémy.
4.5
Presentační (uživatelská) vrstva
V této oblasti je nasazeno přes 9000 desktopových a mobilních stanic. Všechny desktopové stanice byly povýšeny a pracují pod operačním systémem Windows XP Professional. Jejich obměna je řešena formou pronájmu na 4 roky. Tím je zajištěno rovnoměrné financování v jednotlivých letech. SW zabezpečení je řešeno v rámci smlouvy Enterprise Agreement v souladu s koncepcí MV ČR. 105
Základem prezentační vrstvy je tenký klient (tlustý klient pouze ve výjimečných případech), a tato má několik standardů. Jedním z nich je tenký klient (uţivatelský portál) pro koncové pracovníky ČSSZ. Dalšími standardními rozhraními jsou např. prezentační sluţby jako je portál veřejné správy, elektronická podatelna nebo pro některé aplikace speciální (tlustý) klient. Rozhraním mezi vrstvou aplikační a vrstvou prezentační je z hlediska technologických nástrojů vyuţití strukturovaného jazyka XML a protokolu SOAP. V současné době u více neţ 90 % stanic jiţ skončila prodlouţená garance a jejich správa musí být řešena podle potřeby objednávkami. Většina stanic nemá potřebnou úroveň pro nasazení bezpečnějších a výkonnějších systémových prostředků, které jsou k dispozici v rámci smlouvy Enterprise Agreement, ale nemohou být z důvodu nedostatečnosti těchto prostředků nasazeny. Technické povýšení těchto prostředků z hlediska vysokých nákladů a téţ proto, ţe nejsou ve vlastnictví ČSSZ, není moţné. Tento stav musí být v roce 2010/2011 vyřešen a tím minimalizováno riziko napadení a výpadků na pracovištích. Plán obnovy se zpracovává a jsou odstartovány potřebné přípravy. K 1.1.2010 bylo nutné zabezpečit nasazení systému SHA 2 a bylo nutno reagovat i na další změny vyplývající ze zákonných opatření (datové schránky, spisová sluţba apod.). Rozvojové úkoly Alokace finančních prostředků bude do těchto oblastí:
Obměna PC na úroveň umoţňující nasazení operačního systému Windows 7. Povýšení software pracovních stanic. Nasazení notebooků s variantou moţňující jejich vyuţití jak v roli mobilních tak i v roli stolních stanic. Tiskárny s orientací na vyuţití jejich pronájmu. Příslušenství k PC (USB, vypalovače, snímače, speciální tiskárny).
V návaznosti na rozvoj koncových systémů, které jsou prezentovány na trhu je nutno začlenit do rozvojových úkolů analýzu moţností nasazení takovýchto systémů v IIS ČSSZ spolu s návrhem rozhodnutí o jejich začlenění do technologií IK ČSSZ.
4.6
Síťová architektura
Vzhledem k významu komunikační oblasti je ji nutno zabezpečovat, udrţovat a rozšiřovat, a to v oblasti LAN, WAN A KIVS. Základní schéma síťové architektury IIS ČSSZ znázorňuje následující obrázek. Síťová architektura IIS ČSSZ
LAN (komunika ce, interní)
WAN LAN UOJ (komunika ce)
Externí sítě Govnet TESTA EU
Klientská vrstva Internet
Klientský portál
Komunikační a propojovací vrstva
AAA portál (Proxy vrstva) (autentizace, autorizace, audit)
Aplikační vrstva
Databázová vrstva Oracle,SQL
Diskova kapacita a zalohovani
Vrstva správy a administrace IS
AAA portál Autorizační část
Externí administrac e
Infrastruktu rní servery
Decentralizované aplikace (Unix, Windows) Aplikační vrstva Důchodové agendy (Server SQ100 BS2000,Unix)
Obrázek 53 – Síťová architektura IIS ČSSZ
V rámci rozvoje síťové struktury jsou definovány následující záměry: 106
Datová vrstva
V rámci dvou výpočetních datových a komunikačních center je zajištěn přístup všech organizačních jednotek ČSSZ jak k centralizovaným aplikacím, tak i přístup do externích sítí, jako je KIVS, GovNet, GovBone, Internet či sTESTA. Přes síť WAN jsou vytvořeny tunely na bázi technologie IPSEC zajišťující šifrování komunikace – zařízení k zajištění šifrování nadále jsou a zůstanou i do budoucna ve správě a vlastnictví ČSSZ. Z hlediska sítí WAN bude pokračovat úspěšná spolupráce s příslušnými orgány (v rámci KIVS) s tím, ţe v návaznosti na postup centralizace bude postupně docházet k navyšování výkonu linek s cílovým výhledem kapacity připojení OSSZ - 2 Mbps a připojení ústředí aţ na 1 Gbps sdílené kapacity pro WAN i přístup do externích sítí. Síť ústředí ČSSZ bude rozdělena dle účelu na několik subsítí tak, aby uţivatel měl přístup pouze na základě specifikované potřeby. V oblastí sítí LAN bude pokračovat proces přechodu na plně spínanou technologii, tedy náhrada zastaralých technologií na bázi HUBů novými technologiemi vzdáleně dohledovatelných Switchů. Na jednotlivých pracovištích jsou provozovány LAN sítě, všechna pracoviště ČSSZ jsou propojena VAN sítí do jedné strukturované sítě ČSSZ. V průběhu roku 2009 byl realizován záměr integrace sítě 10.6 se sítí 10.1, kterým byla výrazně zvýšena bezpečnost sítě provozovaného systému ČSSZ. Tímto záměrem byly integrovány provozované systémy s aplikační podporou pro nárokové podklady a digitalizační aplikace do jednotného systému centrálního pracoviště KP1 a KP2. Jsou rovněţ propojena všechna datová úloţiště SAN sítí, coţ rovněţ přispívá ke zvýšení spolehlivosti výše uvedených kontrolních pracovišť KP0 aţ KP2.
4.6.1 4.6.1.1
Rozvojové úkoly Rozvoj síťové infrastruktury pro vytvoření Rozhraní ČSSZ pro komunikaci s klienty
Budoucí síťová infrastruktur pro budoucí informační a komunikační rozhraní ČSSZ bude plně oddělena od stávající firewall soustavy, jenţ se pouţívá pro uţivatelský provoz z ČSSZ do I-netu, GovNetu atp... Navrţená komplexní infrastruktura se v budoucnu stane jednotným a jediným komunikačním bodem Z a DO ČSSZ. Celý systém bude napojen přes širokopásmové rozhraní v obou lokalitách do I-netu, CMS, GovNetu, KIVSu samostatnou linkou a zajistí následující funkcionality: Rozklad zátěţe mezi jednotlivými lokalitami (Trojská, Kříţová) Zakončení datového SSL toku včetně autentikace/autorizace Prověření klienta na základní zabezpečení – antivir, aktualizace atp... Prověření webového/datového obsahu proti známým chybám Paketový filtering Rozklad zátěţe uvnitř lokality na jednotlivé presentační portálové servery/rozhraní Prověření webového či XML datového toku proti známým útokům, chybám Kompletní přepínanou, směrovanou a NAT infrastrukturu Detailní logging a analýzu všech incidentů Vzdálenou správu včetně monitoringu Napojení na vnitřní sluţby – LDAP, CA, AAA portál, DNS atp... Celé prostředí bude škálovatelné a snadno rozšiřitelné. Návrh bude zpracován na moderních technologiích s jistotou dalšího rozvoje, správy a udrţby. KIVS
INTERNET
CMS
GOVNET
Přístupový koncentrátor
Přístupový koncentrátor
FW – 1
DMZ 1
SSL teminace, content filtering
VPN terminace
Aplikační web/xml FW
Virtual FW – 1
DMZ 1
DMZ 2
DMZ 4
Aplikační web/xml FW Virtual FW – 2
DMZ 3
DMZ 5 Load balancer
DNS, NAC
Farmy serverů portálu
SSL teminace, content filtering
VPN koncentrátor
FW – 2
DMZ 3
DMZ 2
DMZ 4
DMZ 5 Load balancer
Mgmt, Logging
DNS, NAC
Farmy serverů portálu
Mgmt, Logging
Záložní datové centrum
Primární datové centrum
Obrázek 54 – Blokové schéma možného řešení síťové infrastruktury
107
4.6.1.2
Návrh řešení konceptu B2B kanálu Projekt se navrhuje rozdělit do dvou částí:
Minimalistické varianty B2B kanálu pro pokrytí akutních potřeb komunikace ČSSZ o Definice a realizace infrastruktury bez vysoké dostupnosti. o Zpřístupnění komunikace přes základní B2B kanál pro synchronní sluţbu komunikace s Ministerstvem práce a sociálních věcí (MPSV). Cílový koncept budoucí předpokládané infrastruktury, jenţ řeší nejen předpokládaný rozvoj B2B kanálu, ale který pokryje potřeby komunikace ČSSZ B2B kanálem např. do cca 2 – 3 let.
Minimalistická varianta B2B kanálu pro pokrytí akutních potřeb komunikace ČSSZ Na následujícím obrázku je znázorněno navrhované řešení včetně popisu komunikace.
FW
SSL iniciace
SSL terminace
I-NET/GovNet
FW
XML
SSL
SSL DMZ
XML
FW
BackBone FW
Proxy vrstva
B2B GW
Aplikační vrstva
LB
HTTP
LB
HTTP
Platný XML
FW
PSL
Obrázek 55 – Varianta B2B
Komunkační tok můţeme rozdělit na příchozí poţadavek komunikace od MPSV přes veřejnou síť či GovNet a na odchozí poţadavek směrem od aplikace PSL do I-Netu či GovNetu. Příchozí poţadavek od MPSV či jiné organizace je zpracován nasledujícím způsobem: Ve vrstvě DMZ se zkontroluje zda se jedná o SSL příchozí provoz na B2B sluţbu publikovanou do I-netu či GovNetu skrz DMZ firewall. SSL je terminováno na SSL koncentrátoru a je zkontrolován příslušný certifikát, zda je podepsán známou autoritou a zda je platný (CRL). Pomocí dalších autorizačních mechanismů a informací z certifikátu lze dále škálovat přistupující organizace např. proti LDAP struktuře v AD. V DMZ je téţ zkontrolována struktura XML formátu, zda se nejedná o známý útok. Platný XML formát v http pouzdře projde přes BackBone FW a je zakončen na Loadbalanceru v aplikační vrstvě. LB předá http poţadavek na volný server dle stanovených pravidel. Komunikační kanál je navázán, je bezpečný, autentikovaný, autorizovaný. Dále je výměna dat na aplikační logice spojení. V případě potřeby navázání komunikace z aplikační vrstvy ven do I-netu či GovNetu směrem k externím subjektům, komunikace probíhá následovně. Aplikace naváţe http spojení směrem k Proxy vrstvě přes B2B gateway. Ta zkontroluje oprávněnost komunikace a zajistí směrování do DMZ vrstvy na SSL gateway. 108
SSL gateway v DMZ vrstvě je zodpovědná za SSL iniciaci směrem k externím subjektům včetně vybrání správného certifikátu, následné autentikace a zapouzdření celého komunikačního toku do SSL kanálu Po uzavření aplikačního spojení dojde i k uzavření SSL kanálu.
Cílový koncept budoucí předpokládané infrastruktury B2B kanálu Cílový koncept v rámci budoucího uvaţovaného řešení bude obsahovat předpokládané následné rozšíření z hlediska: předpokládaných partnerů předpokládaných publikovaných sluţeb (synchronní, asynchronní) objemu přenášených dat z předcházejících tří bodů také nároky na správu celého systému Bude také popisovat budoucí cílovou infrastrukturu ve vysoké dostupnosti, případně poţadavky na další škálování, budou-li třeba (vyplyne z analýzy předpokládaných partnerů a sluţeb). Hrubý náčrt této cílové architektury popisuje následující obrázek:
Internet
LB
Perimetr Technologická vrstva
DMZ Aplikační část B2B
Biztalk B2B
Interní síť DB Repository B2B
Routing
Integrační platforma
Integrace/aplikace
MsgDB ESSO TrDB
Obrázek 56 - Předpokládaná budoucí infrastruktura
Alokace finančních prostředků bude do těchto oblastí: Kryptografická ochrana přenosových cest. Dodávka a nasazení aktivních prvků a jejich průběţnou modernizaci. Rozšíření strukturované a optické kabeláţe. Bezpečnost (firewally, šifrátory). Antivir. Integrace do struktur EU.
109
5 Strategie zajištění provozu IIS ČSSZ Provozování IKT je zaměřeno na poskytování sluţeb pro podporu procesů ČSSZ. Centralizace a vyuţívání třívrstvé architektury, rozsah aplikační podpory,implementace prvků bezpečnosti, rozsah instalované a vyuţívané techniky mají dopad na způsob provozování. Jeho rozsah a zabezpečení přesahuje v současné době zavedené moţnosti stávajících provozních a dohledových kapacit. Proto musí být neprodleně věnována priorita
zavedení monitoringu celého systému se zaměřením na kvalitu a výkonnost dořešení servisu a administrace dalšímu zdokonalení funkčnosti HelpDesku.
5.1 Struktura IIS ČSSZ z hlediska provozovaného aplikačního zabezpečení Česká správa sociálního zabezpečení dle zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ISVS), spravuje a provozuje tedy jeden ISVS - Integrovaný informační systém České správy sociálního zabezpečení (IIS ČSSZ). Integrovaný informační systém ČSSZ zajišťuje podporu procesů, správu dat a technologické prostředky v rámci ČSSZ a vytváří otevřené vazby na e-Governement. Přestoţe je snaha vyuţívat SW balíky, procesy zajišťované ČSSZ jsou natolik jedinečné, ţe naprostá většina APV musí být vytvářena individuálním vývojem. 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, centralizaci dat a klientský přístup. Provozované aplikace jsou provozovány následujícím způsobem. Centrální aplikace - současné době je jich provozováno několik skupin, a to: Aplikace na nově budovaných pracovištích KP1 a KP2, kde byly jednak provozovány aplikace jiţ cent-ralizované, ale na starší HW základně (někdy označované jako síť 10.6…) a jednak aplikace, které k 1.1.2009 naběhly do rutinního provozu jako celek a jsou centralizovány na novém datovém úloţišti a serverových farmách. Po integraci sítě 10.6… do sítě ČSSZ (označované jako 10.1…) a po uvedení nových aplikací do rutiny, tvoří tyto aplikace cílové řešení IIS, které se bude nadále rozvíjet. Od počátku roku 2007 aţ do začátku roku 2009 byly postupně optimalizovány a uváděny do rutinního provozu nejdůleţitější aplikace (NEM, POJ, EXK, VZT, INS, VYP a v průběhu roku pak PSL). Byl doladěn provozovaný systém kmenových evidencí (KE2) v návaznosti na ostatní komunikující aplikace a doveden do současného spolehlivého provozování. Spolu s tímto systémem byl doladěn i systém PPV – v současné době provozovaný pod označením VZT. Kmenové evidence prokázaly vysokou spolehlivost a provozuschopnost i v podmínkách enormního zatíţení při náběhu aplikace NEM. Aplikací VZT bylo do konce roku 2009 zpracováno 2,9 mil změn. Systém BizTalk je vyuţíván pro sledování stavu a průběhu procesů, (tzv. workflow). Bylo dosaţeno pozitivních výsledků zejména pro aplikaci NEM, kde tato workflow podpora byla rozšířena aţ k předávání dat do systémů zabezpečování výplat (VYP) a DMS. Došlo k výraznému posílení HW platformy systému BizTalk a k odstranění závaţných problémů, které nasazení aplikací do rutinního provozu doprovázely. Tato platforma dává záruku funkčnosti do další etapy. Byl dokončen vývoj aplikace NEM o funkcionality, které vyţadovalo zavedení nového zákona o nemocenském pojištění k 1. 1. 2009 a aplikace byla nasazena do rutinního provozu. Byla dokončena centralizace dat pro nemocenské pojištění a několikafázovou migrací dat z OSSZ byla vytvářena centrální databáze, která je spolehlivě provozována. Vlastní aplikace NEM prošla extrémní zátěţí v prvním čtvrtletí a postupně byla doladěna natolik, ţe dnes lze říci, ţe je spolehlivě její funkčnost zabezpečována spolu se všemi provázanými aplikacemi, zejména kmenovými evidencemi a systémy VYP a DMS. Bylo zpracováno téměř 8 mil dokumentů a 1,6 mil. dávek a je poskytována podpora aţ pro 4500 současných uţivatelů. Lze konstatovat, ţe záměr centralizace výplat dávek nemocenského pojištění byl úspěšně provozně zvládnut. Byl postupně doladěn a do rutinního provozu nasazen systém POJ, který poskytuje podporu opět více neţ 1000 uţivatelů a v současné době pracuje spolehlivě. Byla nasazena aplikační podpora pro vyřizování exekucí (aplikace EXK), která pracuje spolehlivě. Byla zajištěna a integrována podpora pro oblast lékařské posudkové sluţby (aplikace PSL). Tato aplikace byla přenesena z dvouvrstvé architektury MPSV do třívrstvé architektury ČSSZ a je spolehlivě provozována. Na výše uvedené platformě je zabezpečován i provoz systému nastavování systémových oprávnění a přidělování přístupových práv k datům (ITIM a ITIM GUI). Vlastní proces identifikace a kontroly přístupu 110
k aplikacím a datům byl spolu s aplikacemi pro podporu PKI, čipových karet a ActiveDirectory provozován spolehlivě bez zvláštních problémů na serverových farmách a datovém úloţišti a systém prokázal dostatečnou výkonnost a funkčnost. Ke značným problémům docházelo při nastavování oprávnění v rámci workflow z důvodu nedostatečně výkonné HW platformy. Tyto problémy byly koncem roku 2009 migrací na novou verzi systému ITIM a nový výkonný HW vyřešeny. Způsob provozování těchto aplikací je v souladu s cílovou koncepcí centralizace datové a aplikační vrstvy a v následujícím období půjde o jejich stabilizaci a optimalizaci a v této koncepci se předpokládá dále pokračovat. Adekvátně je nutno zabezpečit výše uvedené komponenty technické základny pro zabezpečení tohoto provozu. Aplikace provozované na pracovišti KP0, reprezentované platformou se serverem Fujitsu SQ100 a jeho datovým úloţištěm a se svým okruhem aplikací pro podporu důchodového pojištění – důchodových agend. Byla realizována obměna tohoto systému na nové technologii business serveru SQ100 Fujitsu. Zpracování důchodových agend bylo po celé období nepřetrţitě zajišťováno v souladu s harmonogramem automatizovaného zpracování úloh, bez výpadku. Subsystém je vyvíjený na technologiích BS2000 a Unix, který obsahuje tři základní databáze a aplikace pro podporu důchodových agend. Obsahuje celkem 1982 aplikací – podrobný seznam je uveden v materiálu Seznam programu BS2000.doc který je v ČSSZ k dispozici. Způsob provozování těchto aplikací je v souladu s cílovou koncepcí centralizace datové a aplikační vrstvy a v následujícím období půjde o jejich integraci do cílového IIS ČSSZ. Adekvátně je nutno zabezpečit i komponenty této technické základny pro zabezpečení bezpečného provozu pokrývající stávající důchodovou oblast. Rozvojové úkoly v oblasti provozování centrálních aplikací :
Na základě stávajících zkušeností přehodnotit pravidla pro činnost v neprodukčním prostředí. Především vymezit zodpovědnost, vyjasnit otázky financování aktivit projektů, nároků na sluţby v těchto prostředích, plánování a vlastní provoz. Racionalizovat a rozvinout metodiku nasazování nových verzí do produkce. Iniciovat a vyţadovat od projektových týmů zavedení a důsledné dodrţování Change managementu na stávající platformě Peregrine. Zavést a provozovat SharePoint pro ukládání a výměnu informací mezi provozem a odbory připravující rozvoj Aplikačního software. Připravit a zavést do systému Peregrine Troubleshooting pro řešení problémových a krizových stavů dle doporučených standardů pro tuto oblast. Zhodnotit dosavadní zkušenosti s outsourcingem převáţné části sluţeb administrace, unifikovat systém hodnocení, zhodnotit a pokud moţno sjednotit pravidla pro SLA.
Způsob zajišťování provozu centrálních aplikací: I nadále se předpokládá účelová kombinace vyuţívání in-source a out-source podpory provozu. V příštích letech do r. 2014 se nepředpokládá ţádná zásadní změna v poměru zajištění potřebných sluţeb mezi ČSSZ a externími poskytovateli sluţeb. Ze strany ČSSZ bude uplatňován trvalý tlak na sniţování provozních nákladů. Rozvojové úkoly v oblasti pracoviště KP0 ( BS2000) :
Integrace celého subsystému SQ100 do síťové architektury centrálních aplikací Integrace zálohovacích systémů SQ100 s prostředky stávajícího CDÚ Revize a aktualizace disaster recovery plánů, sjednocení s reţimem platným pro CDÚ Začlenění aplikací provozovaných na této platformě pod bezpečnostní AAA Portál. Začlenění aplikací vyvíjených na této platformě do systému nových centrálních aplikací.
Aplikace provozované v rámci subsystému EKIS - moduly řešené dodavatelsky jsou také provozovány dodavatelsky. 111
Rozvojové úkoly: <doplní odbor ???> Ostatní centrálně provozované aplikace podpůrného charakteru Jsou to aplikace pro přebírání informací o nároku na rodičovský příspěvek ze SSP, Námitkové řízení – aplikace pro podporu činností nově vzniklého oddělení námitkového řízení , Ţivnostenský registr – aplikace na podporu správy agendy OSVČ, D_STAT – subsystém důchodové statistiky, Centralizace průchodových systémů a další. Rozvojové úkoly: <doplní odbor ???> O spolehlivost provozování centrálně provozovaných technologií svědčí skutečnost, ţe nedošlo k totálnímu výpadku systému a provozuschopnost pro jednotlivé oblasti aplikací se pohybuje mezi 97,9 aţ 99,9 %. Podmínkou plynulého fungování systémů je zajistit jejich obsluhu. V této souvislosti je nutno zdůraznit topologii sítě, její strukturu spolu s dohledem a udrţováním její výkonnosti a jejím rozvojem. Spolehlivost technologické podpory provozované síťové struktury dokumentuje skutečnost, ţe nedošlo k celkovému výpadku sítě a v průběhu roku se objevují pouze dílčí problémy. Po celý rok jsou smlouvy zajišťující provoz průběţně sledovány, aktualizovány a vyhodnocovány. Smlouvy, které neplnily zcela svůj účel byly vypovězeny. Bylo vybudováno a zahájena činnost dohledového centra ČSSZ, které bylo realizováno pro aplikační vrstvu a pro BizTalk. Jako celek je dohledové pracoviště dosud ve stadiu příprav a představuje velmi sloţitý a komplexní problém. Rozvojové úkoly: <doplní odbor ???> Lokální aplikace Byly v průběhu roku provozovány v plném rozsahu. Řada z nich bude postupně v produkčním provozu ukončována (s archivací historických dat) v souvislosti s centralizací agend NEM a POJ a přechodem souvisejících agend na centrální zpracování. Některé agendy (včetně všech souvisejících podpůrných aplikací) však stále zůstanou na lokální úrovni i v dalším období (některé nejméně do roku 2014) a budou postupně převáděny na nové centrální APV. V návaznosti na průběh procesu centralizace dat a aplikací je nutno zajistit i stabilní provoz lokálních technologií na OSSZ. V důsledku ukončení podpory bylo nutno přejít na novou verzi operačního systému Solaris 10 a současně přejít i na vyšší verze databázových Oracle modulů. Bylo nutno zabezpečit jejich migraci na vyšší verze. Tento proces proběhl na všech správách a pracovištích ČSSZ. Šlo o organizačně i technicky náročný úkol, který vyţadoval otestovat aplikace v tomto novém prostředí a zabezpečit jejich funkčnost.
5.2
Zavedení monitoringu se zaměřením na kvalitu a výkonnost řešení
Česká správa sociálního zabezpečení provozuje rozsáhlou oblast IKT řešení, která vyţaduje pravidelný monitoring jednotlivých aplikací ale i infrastruktury. Do roku 2012 by měl být vybudován komplexní monitorovací systém pro sledování stavu a výkonu aplikací. Tento systém by měl také poskytnout podklady pro evidenci a uplatňování SLA pro jednotlivé sluţby dodávané externími subjekty. Základem celého řešení musí být robustní infrastruktura zajišťující vysokou dostupnost a flexibilitu. Veškerá správa monitorovacího systému by měla být koncipována tak, aby potřebné servisní úkony na daném SW řešení byli schopni provádět přímo pracovníci IKT ČSSZ. Úkolem celého monitoringu ČSSZ je zajistit především následující funkce:
Sledovat a archivovat údaje o výpadcích centrálních aplikací a vytvářet statistiky včetně jejich pravidelné aktualizace tak, aby je bylo moţné poskytovat dále jako podklady pro rozhodování a plánování dalšího rozvoje infrastruktury IKT. Sledovat plnění smluvně nastavených SLA pro jednotlivé aplikace a poskytovat podklady pro uplatňování sankcí. Diagnostikovat výpadky centrálních aplikací, jejich četnost a případně poskytnout podklady k další analýze vzniklých problémů. Vytvářet vazbu na centrální ServiceDesk a zakládání automatizovaných tiketů na jednotlivé řešitelské skupiny v případě výskytu problémů. 112
5.3
Poskytovat výkonové statistiky důleţitých částí systému jako podklad pro budoucí plánování zdrojů IKT. Archivovat údaje o sledovaných aplikacích a jejich SLA. Sledovat end – to – end centrální aplikace. Sledovat výkonové statistiky aplikací i infrastruktury a poskytovat ucelený přehled pro vedení IKT při rozhodování o dalším rozvoji v oblasti HW/SW.
Rozvoj centrálního ServiceDesku
Především se jedná o rozvoj centrálního ServiceDesku jako hlavního rozhranní pro evidenci a správu jakýchkoliv problémů týkajících se HW, síťového, programového a aplikačního vybavení v rámci celé ČSSZ. ServiceDesk musí fungovat jako komunikační rozhraní mezi koncovými uţivateli (zadavateli) a interními či externími řešiteli. Vedení úseku IKT ČSSZ vystupuje zároveň jako nadřízená sloţka, adresát eskalací a reportů, tak i jako běţný koncový uţivatel. Základem celého rozvoje a zkvalitnění sluţeb je zavedení nového SW nástroje ( horizontu nejpozději do r. 2012), který by měl pokrývat především oblasti:
Incident and Problem Management Change Management Configuration Management
Z uţivatelského hlediska by měl poskytnout jednoduché plně lokalizované WEB base rozhraní pro zadávání incidentů, poţadavků na instalační změny a konfigurační změny. Cíle centrálního ServiceDesku:
Vykonávat centralizovaný sběr poţadavků koncových uţivatelů. Sledovat a vyhodnocovat poţadavky, které nebyly vyřešeny ve stanovené lhůtě, včetně návrhů opatření. Monitorovat dodavatele - kontrolovat, zda dodavatel dodrţuje smluvní a akceptační podmínky. Předávat poţadavky řešitelům v rámci ČSSZ i mimo ni. Reportovat vedení poţadavky nevyřízené v poţadované lhůtě. Provádět pravidelné urgence řešitelů. Evidovat a prezentovat známá řešení a odpovědi na standardní dotazy uţivatelů v rámci Frequently Asked Questions. Evidovat poţadavky na instalační a konfigurační práce externích dodavatelů i v rámci samotné ČSSZ. Informovat uţivatele o vyřešení jimi zadaných incidentů. Poskytovat podklady pro sledování SLA aplikací a spolupracovat plně s nástroji monitoringu.
Závěrem k problematice provozování aplikací v rámci IIS ČSSZ je nutno konstatovat, ţe přestoţe v současné době je vcelku spolehlivý provoz technologií zajištěn, nepodařilo se z důvodu nedostatku finančních prostředků zajistit potřebnou obnovu informačních technologií tak, aby riziko fatálního výpadku a ohroţení činnosti ČSSZ bylo minimální. S ohledem na předpokládaný nárůst spravovaných dat, provozovaných aplikací a rozvoj oblastí automatizace je nutno tento problém pro rok 2010 řešit, protoţe další odkládání můţe vést k výpadkům aţ k narušení činnosti ČSSZ. V této souvislosti je nutno zdůraznit i potřebu povýšení provozovaných operačních systémů a základních systémových produktů, které jsou podmínkou udrţení bezpečnosti provozovaných technologií a jejich odolnosti proti útokům zevnitř, ale zejména zvenčí, kterou je nezbytně nutné provést v roce 2010 spolu s pořízením HW stanic a serverů s potřebnou výkonností.
113
6 Strategie zabezpečení vývoje udržování IIS ČSSZ Vývoj IIS ČSSZ započal v roce 1965 v důchodové oblasti a probíhá nepřetrţitě s cílem zabezpečovat další rozvoj IIS a jeho udrţování v souladu s potřebami ČSSZ. Pro léta 2011 aţ 2014 je pro oblast vývoje prioritní zabezpečovat dlouhodobé i prioritní úkoly ČSSZ. Jedná se zejména o technologickou podporu strategických cílů ČSSZ zejména v oblasti zajišťování podpory důchodové reformy, inovace aplikační podpory v jednotlivých oblastech procesů ČSSZ, vytvoření aplikační podpory nových procesů (úrazové pojištění). Dále je to pruţné reagování na plánované legislativní změny, a cílů v oblasti e-Governmentu v rozsahu, výměny dat, vazby na základní registry a datové schránky a vazby na program zdokonalování administrativy ve veřejné správě cestou přechodem na její elektronickou formu a přístupu ke klientovi. Tyto úkoly v oblasti vývoje jsou usměrňovány zejména Směrnicí ……………………. , standardy pro oblast IKT a dalšími dokumenty platnými pro oblast IKT. V souladu s tím jsou úkoly v oblasti vývoje zabezpečovány jednak dodavatelsky a jednak vlastními vývojovými kapacitami. Aplikační podpora pořizovaná dodavatelsky je zabezpečována v souladu se zákonem o veřejných zakázkách a ve vazbě na financování oblasti IKT. Aplikační podpora pořizovaná vlastními silami je zabezpečována zejména v oblasti důchodového pojištění a …………..Nedílnou součástí provozovaného aplikačního vybavení je také snaha si vlastními silami ověřit, zda dodavané APV jak interním tak externím dodavatele 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í Rational Quality Functional Tester a Rational Quality Manager od firmy IBM Česká republika, spol. s r.o., které byly dodány v rámci uskutečněné veřejné zakázky „Vývojové prostředky – SW“. V současné době probíhá v ČSSZ implementace těchto nástrojů a následně dojde k proškolení vybraných pracovníků k pouţívání těchto nástrojů. Pracovníci budou připravovat testovací data a testovací scénáře a 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ů. V rámci projektu 155, kde hlavním věcným cílem je zefektivnění průběţného vytěţování nasnímaných dokumentů souvisejících s výkonem agend sociálního pojištění, výběru pojistného na sociální pojištění a příspěvku v nezaměstnanosti, kontroly vytěţených údajů a jejich konsolidace v návaznosti na centrální registry ČSSZ Kmenové evidence a Pojistné vztahy a základní registry veřejné správy ROB, ROS a RUIAN se uvádí, ţe pro plynulé zajištění plnění hlavního věcného cíle projektu je nutné:vybudovat vývojové pracoviště, které bude zajišťovat:
SW podporu provozního pracoviště pro vytěţování a konsolidaci kmenových evidencí pojištěnců a jejich individuálních kont. Vývoj nového aplikačního programového vybavení agend sociálního pojištění, zejména agend nemocenského a důchodového pojištění, s cílem přechodu vývoje ze stávajícího a jiţ nepodporovaného vývojového prostředí Cobol a HW platformy Mainframe na standardizované a směrnicemi deklarované technologie ve vývojové oblasti Microsoft .NET Framework s vyuţitím vývojového nástroje Visual Studio .NET, v databázové oblasti přechod na databáze Oracle 10g postavené na bázi farem aplikačních serverů s OS Microsoft Windows. Funkční testování vyvíjených aplikací realizovaných jak vlastním vývojem, tak i externím dodavatelem s ohledem na aktuální stav infrastruktury ČSSZ simulování zátěţe a testování výkonu aplikací realizovaných jak vlastním vývojem, tak i externím dodavatelem, umoţňujících zatíţit testované prostředí stovkami či tisíci souběţnými virtuálními uţivateli při minimálních hardwarových nárocích.
114
7 Strategie bezpečnosti IIS ČSSZ 7.1
Organizace a řízení bezpečnosti v ČSSZ
7.1.1 Řízení bezpečnosti s působností na celou ČSSZ Základním článkem řízení bezpečnosti v ČSSZ je odbor bezpečnostní politiky. Tento odbor je odborným útvarem, v jehoţ kompetenci je výkon činností spojených s koordinací a usměrňováním příprav ČSSZ na krizové situace, se zajištěním komplexní bezpečnosti ČSSZ. Odbor odpovídá za dodrţování zásad bezpečnosti zaměstnanců, poţární bezpečnosti, bezpečnosti prostředků informačních a komunikačních technologií (dále jen „IKT“), ochrany datových souborů, bezpečnosti personální, administrativní, objektové a technické. Odbor zabezpečuje úkoly z oblasti obrany, ochrany a bezpečnosti podle pokynů nadřízeného orgánu. Součástí odboru je oddělení bezpečnosti informačních a komunikačních technologií, které vykonává odborný dozor nad bezpečností informací přenášených a zpracovávaných v informačních a komunikačních systémech v působnosti ČSSZ, navrhuje řešení a organizaci ochrany utajovaných skutečností v souvislosti se zpracováním informací a provozem informačních a komunikačních systémů. Dále koordinuje vývoj, výstavbu a zavádění systémů s šifrovou ochranou informací, posuzuje návrhy tuzemských a zahraničních norem, zajišťuje výklad, distribuci a zavádění nově vydávaných norem a standardů. Rovněţ zpracovává návrhy závazných norem, kterými se řídí a zajišťuje výběr technických a programových prostředků, zpracovává návrhy systemizace a unifikace technických prostředků informační bezpečnosti. Organizuje a zabezpečuje sluţby certifikační autority, organizuje tvorbu klíčů, zajišťuje centrální výrobu heslových materiálů a jejich distribuci. V současné době také plní úkoly elektronické podatelny ústředí ČSSZ na elektronické adrese [email protected] dle zvláštních předpisů. Z uvedeného vyplývá, ţe roli bezpečnostního správce IIS na nejvyšší úrovni zajišťuje ředitel odboru bezpečnostní politiky a na výkonné úrovni vedoucí oddělení bezpečnosti informačních a komunikačních technologií. V jejich kompetenci je tedy správa a kontrolu bezpečnosti IIS ČSSZ na vrcholové úrovni. Jsou to útvary mimo působnost úseku IKT.
7.1.2 Řízení a zajišťování bezpečnosti v rámci úseku IKT V rámci úseku IKT jsou zabezpečovány následující úkoly: Odbor koncepcí a systémové integrace vytváří koncepci rozvoje a systémové integrace informačního systému ČSSZ (dále jen „IS“), zajišťuje procesy systémové integrace a spolupracuje při zajišťování procesu implementace bezpečnostní politiky a rozpočtu ČSSZ v oblasti procesů IKT. Zpracovává komplexní projekty vývoje informačních systémů, programového vybavení a informačních sluţeb. Koordinuje součinnost příslušných organizačních jednotek ČSSZ při realizaci projektů s celostátním nebo mezinárodním dopadem. Sleduje, vyhodnocuje a řídí zdroje IKT. V rámci odboru jsou tyto úkoly přeneseny na oddělení koncepcí, které definuje a kontroluje základní postupy řízení bezpečnosti IKT, rozpracovává bezpečnostní politiku do standardů a metodik, řídí aktualizaci bezpečnostních prvků. Odbor systémové, komunikační a technické podpory vykonává procesy zajišťování komunikační podpory, zajišťování HW prostředků a HW podpory, zajišťování systémové podpory, podpora koncových uţivatelů, vnitřní servisní sluţba – HelpDesk. Podílí se také na procesu systémové integrace. Mimo tyto procesy zajišťuje přípravu zadání veřejných zakázek a následných smluv ve své působnosti. V rámci těchto aktivit zabezpečuje v činnosti svých oddělení tyto úkoly:
Oddělení technické podpory správy sítí LAN a WAN v rámci své působnosti spravuje a buduje systémy pro kryptografickou ochranu sítě WAN v rámci všech územních organizačních jednotek ČSSZ a realizuje bezpečnostní prvky ve všech vyuţívaných IKT. Oddělení správy infrastrukturních serverů v rámci své působnosti vykonává celou řadu funkcí, které souvisí s realizací bezpečnostní politiky, vykonává správu a dohled systémů elektronické pošty, navrhuje změny související s jejím vývojem, zajišťuje součinnosti s aplikacemi ČSSZ, dohled nad bezpečností e-komunikace, týkající se zejména Internetu; provádí správu a dohled systémů komunikačních a aplikačních firewallů a konfigurace bezpečnostních politik těchto systémů; provádí správu doménové infrastruktury na platformě Windows 2003; nastavení globální bezpečnostní politiky; kontrolu replikací adresářových sluţeb Active Directory; realizuje bezpečnostní prvky ve všech vyuţívaných IKT. 115
Oddělení metodiky provozu výpočetní techniky metodicky zabezpečuje správu systémů aplikačních serverů a počítačů v rámci všech územních organizačních jednotek ČSSZ, správu operačních systémů, zabezpečuje distribuci SW v rámci celé ČSSZ, metodicky zabezpečuje výkon aplikace bezpečnostních funkcí na spravovaná zařízení, zpracovává nebo se podílí na zpracování vnitřních organizačních směrnic v oblasti IKT a sluţeb, zpracovává návrhy systematizace a unifikace technických prostředků v oblasti IKT a sluţeb a zpracovává podklady pro účetní a majetkovou evidenci. Referát metodiky provozu počítačů a aplikačních serverů platformy MS, začleněný v oddělení metodiky provozu výpočetní techniky metodicky zabezpečuje výkon aplikace bezpečnostních funkcí na spravovaná zařízení. Oddělení správy systémového a aplikačního vybavení v rámci své působnosti realizuje definovanou bezpečnostní politiku na spravovaná zařízení, vykonává aplikaci bezpečnostních funkcí na spravovaná zařízení, zajišťuje zpracování podkladů pro softwarový audit a předává je referátu softwarového auditu, realizuje bezpečnostní prvky v přístupech a práci s evidovanými daty a realizuje bezpečnostních prvky ve všech vyuţívaných IKT. Zabezpečuje další aktivity, které patří do oblasti realizace bezpečnostní politiky – viz Organizační řád ČSSZ) Odbor provozu centrálních informačních technologií zajišťuje provoz a správu centrálních informačních technologií, včetně záloţních výpočetních systémů na všech vrstvách, datových úloţišť a trezorových pracovišť a přípojných míst zapojených do centrálních informačních technologií pro ukládání a zpracování dat pro veškeré oblasti v rámci ČSSZ s celostátní působností. V rámci těchto aktivit zabezpečuje v činnosti svých oddělení tyto úkoly:
Oddělení správy a provozu datových úloţišť spolupracuje při výkonu aplikování bezpečnostní politiky tzn. jednotlivých funkcí vztahujících se na zařízení uţívaná v rámci zajišťování provozu centrálních výpočetních systémů, datových skladů, a to včetně správy uţivatelských účtů; předkládá návrhy vztahující se k objektové bezpečnosti. Referát správy a provozu datových úloţišť, začleněný v oddělení správy a provozu datových úloţišť pracovišť spolupracuje při výkonu aplikování bezpečnostní politiky, tzn. jednotlivých funkcí vztahujících se na zařízení uţívaná v rámci provozu datových úloţiště.
Referát správy trezorových pracovišť, začleněný v oddělení správy a
provozu datových úloţišť
vytváří podporu pro budování a rozvoj trezorových pracovišť v rámci bezpečnostní strategie; spolupracuje při výkonu aplikování bezpečnostní politiky, tzn. jednotlivých funkcí vztahujících se k zajišťování provozu trezorových pracovišť. Bezpečnostní směrnice pro činnost bezpečnostního správce IIS ČSSZ obsahuje podrobný popis bezpečnostních funkcí, které bezpečnostní správce pouţívá pro provádění určených činností, a návod na pouţití těchto funkcí. Pro řízení bezpečnosti ISVS je nutné stanovit dlouhodobé cíle bezpečnosti, ty transformovat do konkrétních poţadavků na bezpečnost a následně stanovit plán, jak má být těchto cílů resp. naplnění poţadavků dosaţeno. Plán řízení bezpečnosti obsahuje popis činností, které orgán veřejné správy vykonává pro naplnění stanovených cílů bezpečnosti a uplatnění konkrétních poţadavků na bezpečnost IS. Součástí je téţ předpokládaný časový harmonogram plnění cílů a poţadavků v oblasti bezpečnosti. Splnění dlouhodobých bezpečnostních cílů povede k zajištění poţadované bezpečnosti: dat, která jsou v ISVS zpracovávána, sluţeb, které jsou prostřednictvím ISVS poskytovány, technických a programových prostředků.
116
8 Financování 8.1
Financování IKT a IIS ČSSZ
ČSSZ, jako organizační sloţka státu, nemá vlastní rozpočtovou kapitolu, proto rozpočtuje kapitálové a věcné výdaje IKT v rámci rozpočtové kapitoly Ministerstva práce a sociálních věcí – č. 313. Zároveň se snaţí vyuţít mimorozpočtových zdrojů, konkrétně prostředky OSFA (v minulosti vyuţity především na realizaci digitalizace papírových nárokových podkladů a realizaci zákona 357/2006 Sb.), tak i prostředků Evropské unie (v minulosti vyuţity např. na pořízení digitalizačního pracoviště, aplikační podpory pro volný pohyb osob,pro statistiku důchodových agend). Zásady financování jsou v souladu s paragrafem 12 a 13 zákona č. 218/2000 Sb. o rozpočtových pravidlech, prováděcí vyhláškou Ministerstva financí č. 560/2006 Sb., o účasti státního rozpočtu na financování programů reprodukce majetku a v souladu s Příkazy ministra č. 1/2007 Zásady řídící kontroly v podmínkách Ministerstva práce a sociálních věcí a č. 36/2004 Zásady hospodaření s finančními prostředky státního rozpočtu pro upřesnění a koordinaci činností a stanovení kompetencí na tomto úseku. Následující tabulka uvádí přehled akcí, které je nutno v létech 2011 aţ 2014 realizovat. 2011
2012
2013
2014
Poznámka
Infrastrukturní oblasti Centrální datová vrstva (datové úložiště) 20,000 Rozvoj centrálního úloţiště 113,000
140,000
0,000
Obnova datového úloţiště 30,000 Bezpečnost (archivace, off - line zálohy)
20,000
Poţadavky na oč. rozvoj 0,000 Druhá etapa upgrade enterprise pole Řešení pronájmu zálohovacích zařízení
Centralizovaná aplikační vrstva (aplikační servery a systémy) Technické zhodnocení aplikačních serverů
10,000
10,000
20,000
20,000
Licence software - technické zhodnocení
16,000
16,000
16,000
16,000
Obnova aplikačních serverů
50,000
50,000
0,000
30,000
Doménové servery - obnova kritické infrastruktury;file servery;zálohování;
32,000
0,000
32,000
0,000 Tři servery v odd 551
11,300
Obnova Proxy a SQL serverů 9,000
Exchange servery
5,000 Bezpečnost ; AAA portál HW
Obnova Bladů
5,000
obměna 2007 obměna 2006 5,000 přechod autorit a RA na SHA-2 servery
Integrace do struktur EU (včetně komunikací) 15,000
2,000
2,000
15,000
2,000
2,000
1,000
0,000
1,000
Rozvoj a podpora servicedesku (HD)
Rozvoj a podpora monitoringu aplikací Hw pro potřeby monitoringu a HD Síťová vrstva (komunikační infrastruktura)
117
2,000 Nový systém HD, podpora, licence. 2,000 Nasazení a podpora end to end monitoringu, licence atd. 0,000 Servery odd.554
22,000 Kryptografická ochrana přenosových cest 16,950
22,500
16,950
Dodávka a nasazení aktivních prvků
šifrátory obměna 2004 22,500 postupná obnova switchů s přechodem na IPv6
Rozšíření strukturované a optické kabeláţe 12,000
Bezpečnost (firewally, šifrátory)
obnova 2007
20,000
Antivir
obnova 2009
Integrace do struktur EU Zálohování virtuálů Prezentační vrstva (Uživatelská platforma)
5,000
5,000
Personální počítače
??? …bude pronájem Co se tímto myslí ??? Win a Off je v EA …
SW pracovních stanic Notebooky
4,000
Tiskárny Příslušenství k PC(USB,vypalovače,snímače,speciální tiskárny) Scanery
??? ...bude outsourcing 40,000 2D čtečky 2,000
2,000
25,000
28,000
2,000
Decentralizované (lokální uzly) IIS Infrastrukturní servery pro územní jednotky - obnova kritické infrastruktury;file servery;zálohování;
FS - obměna 2005, 2006 15,000 Solaris 90 mil., obměna apl.serverů 15 mil. ??? ….bude pronájem ??? ….bude outsorcing
90,000 Aplikační servery pro úemní jednotky Pracovní stanice pro územní jednotky Tiskárny pro územní jednotky Centrální administrace PC, distribuční pointy Záloţní zdroje Celkem infrastrukturní oblasti
10,000
10,000
10,000
5,000
437,950
375,500
Aplikační oblasti 1. Rozhraní pro komunikaci IN/OUT - příjem podání a poskytování informací Klientský portál ČSSZ - Strukturální fondy Projekt 159 Strukturální fondy B2B rozhraní DIS Server PVS rozhraní VREP - veř. rozhraní e-pod. DSS rozhraní-Internet,DAS,ISDS Server Czech Point rozhraní Access point - rozhraní pro ČSSZ E-Podatelna/E-Výpravna
118
10,000
170,250
132,500
Rozhraní pro vzdálený přístup Access point ČSSZ Projekt 154 - Strukturální fondy Integrace do VPO (doplnění databáze apod). Subsystém DIS_IN/OUT Subsystém DIS_IN/OUT
12,000
5,000
5,000
5,000
12,000
3,000
3,000
3,000
Vybudování centralizovaného systému pro správu výběru pojistného - dokončení centralizace Centralizace OSVČ - důchodové pojištění
40,000
40,000
50,000
30,000
40,000
75,000
50,000
15,000
Centralizace dobrovolného pojištění
15,000
5,500
5,000
Centralizace SPRIZ
18,000
6,000
2,000
2,000
Insolveční řízení se zahraničním prvkem
30,000
10,000
5,000
2,000 Náklady nelze přesně odhadnou, chybí zkušenosti s komunikací mezi institucemi EU.
Úpravy subsystému důchodového pojištění dle změn zákonných předpisů Integrace současného systému SQ100 do IIS a jeho inovace (náhrada subsystému DCPA, vazba na KE a inovace cyklů, nový datový model pro důchodovou oblast) - odb.53 Integrace současného systému SQ100 do IIS a jeho inovace (náhrada subsystému DCPA, vazba na KE a inovace cyklů, nový datový model pro důchodovou oblast) - odb.54 Náhrada UI aplikací s vazbou na databáze SQ100, PŘKPS a další aplikace
20,000
20,000
20,000
20,000
50,000
40,000
30,000
20,000
5,000
5,000
5,000
5,000
30,000
20,000
20,000
10,000
Decentralizace rozhodovací činnosti - podpora sluţeb klientům Výměna informací důchodového pojištění v rámci EU
?
?
?
?
??
?
?
?
-
-
-
20,000
10,000
10,000
1,500
0,800
Rozšíření sluţeb IN a OUT pro jednotlivé oblasti IS ČSSZ Zabezpečení subsystému pro ukládání dat souvisejících s poskytováním sluţeb klientům - Datový sklad Business Inteligence – metadata datového úloţiště pro informační, rozhodovací, řídící a statistické účely Rozšíření služeb ZDV Subsystém OUT Analýza a návrh řešení oblasti OUT 2.Výběr pojistného Informační subsystém výběru pojistného
Insolvenční řízení
3. Výkon agend Informační subsystém agend důchodového pojištění
Talafúsová
Shrbený
Tvorba parametrické softwarové podpory - dokončení Důchodová statistická databáze - datový sklad ZDD - rozšíření funkcionalit a statistik Implementace UNICODE pro harmonizaci s EU
119
10,000
Fujitsu
Rozšíření SQ o další OS
2,500
Nákup licencí přes pro centralizovaný tisk
1,500
2,500
Fujitsu Printsoft
Informační subsystém agend nemocenského pojištění 20,000
20,000
20,000
40,000
40,000
40,000
??
??
??
4,000
4,000
4,000
20,000
10,000
10,000
15,000
5,000
5,000
Úpravy subsystému nemocenského pojištění dle změn zákonných předpisů
Elektronická neschopenka
20,000 předpoklad legislativních změn podle zkušenosti z minulých let a nové poţadavky odb. 32,33,24 40,000 další etapy elektonické nechopenky ??
Výměna informací nemocenského pojištění v rámci EU Integrace do VPO (doplnění databáze apod).
Informační subsystém Lékařská posudková služba Aplikační podpora posudkových lékařů
Rozvoj aplikační podpory PSL Komunikace s MPSV
4,000 předpokládané legislativní změny a nové poţadavky odb. 63 10,000 5,000
Informační subsystém agend úrazového pojištění Rozvoj centrálního datového úloţiště
32,000
infrastr.
Posílení komunikační infrastruktury
34,800
infrastr.
Rozvoj farmy serverů Blade
31,000 3,200
infrastr.
Rozšíření přípojných míst Aplikační a programové vybavení
infrastr.
99,000
4. Výplaty dávek Informační subsystém o výplatách důchodových,nemocenských, úrazových dávek
Jedná se o sluţbu
pozn. Talafúsová
Výplata důchodových dávek- další rozvoj a zdokonalení Výplata nemocenských dávek - další rozvoj a zdokonalení Výplata dávek úrazového pojištění rozšíření subsystému VYP
Informační subsystém exekucí (exekuční srážky) Exekuce a konkurzy další etapy rozvoje
20,000
120
20,000
15,000
10,000 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. 5. Správa údajové základny Evidence nárokových podkladů - Individuální konto pojištěnce IKP - další rozvoj a vazby na důchodovou oblast, rozšíření o podporu sluţeb klientům při podkytování informací o jejich nárocích
10,000
10,000
5,000
5,000
Skenery a software pro vytěţování ( odbor 44)
10,000
3,000
3,000
10,000
5,000
5,000
5,000
5,000
Úprava funkčnosti aplikace TCL (redesign)
15,000
5,000
Integrace a realizace vazeb na další subsystémy (SQ100 a úrazové pojištění)
10,000
10,000
10,000
10,000
10,000
10,000
10,000
5,000
5,000
5,000
5,000
Centralizace DP OSVČ
10,000
15,000
10,000
5,000
Evidence podání ELDP
15,000
5,000 10,000
10,000
Projekt 155 - Strukturální fondy Informační subsystém Registr pojištěnců(Kmenové evidence) Zvyšování kvality dat, kontrola a konsolidace
Rozšíření o vazby na základní registry Informační subsystém Registr pojistných vztahů Optimalizace a zdokonalení aplikace VZT včetně zvyšování kvality dat, jejich kontroly a konsolidace
Vazba na příslušné základní registry
10,000
Centralizace Péče
20,000
10,000
Centralizace Dopoj
15,000
5,000
5,000
5,000
Evidence volného pohybu osob
5,000
6. Ekonomické subsystémy Informační subsystém ekonomických agend (EKIS) Rozvoj EKIS o další moduly Centrální výplata dávek
Podpůrné subsystémy pro zpracování statistik D - STAT
5,000
7. Průřezové subsystémy Informační subsystém DMS
Migrace DMS na výkonnou HW platformu a vyšší verzi DB Oracle
15,000
121
Další rozšíření o potřebnou funkcionalitu ve vazbě na rozvoj IIS ČSSZ (např. elektronický spis)
5,000
5,000
5,000
5,000
Workflow – PŘKPS Rozvoj a integrace dalších oblastí IN, aplikací a oblasti OUT pro sledování realizace poskytování sluţeb klientům VZT do PŘKPS
3,000
Změny ve WF
5,000
5,000
5,000
5,000
Přepracování propojených APV na vyuţití řízení předávání pomocí PŘKPS
7,000
5,000
3,000
2,000
5,000
5,000
5,000
5,000
10,000
30,000
20,000
50,000
50,000
50,000
50,000
20,000
6,000
4,000
4,000
15,000
10,000
5,000
15,000
Bezpečnostní monitoring a risk analýza IIS ČSSZ
7,000
8,000
2,000
2,000
Integrace subsystému SAP - EKIS
5,000
2,000
4,500
5,000
7,500
0,400
0,200
0,400
Elektronická spisová služba Spisová sluţba Projekt 157 - SF Zaručený elektronický archiv Vytvoření aplikace ZEA a její integrace v rámci IIS Elektronický spis Rozpracování a realizace konceptu elektronického spisu (ES) s variantami pro důchodovou oblast, oblast nemocenského a úrazového pojištění Digitalizace evidencí OSSZ SW pro scanery Centralizace KOCIN - dokončení 8. Bezpečnostní subsystémy
3,000
Správa účtů a přístupů zaměstnanců (AAA,PKI,monitoring) Další rozvoj subsystému a integrace dalších oblastí pod správu účtů a přístupových oprávnění
Plánovaná správa přístupu klientů a externích sbujektů Projekt 159 - strukturální fondy Docházkové a průchozí systémy Unifikace a integrace docházkových a průchozích systému v rámci ČSSZ 9. Podpůrné subsystémy Podpůrné subsystémy Help Desk,Call Desk,ASPI
Subsystém v oddělené doméně pro zpracování informací Vyvolávací systémy Elektronické vzdělávání
122
0,200
ASPI
Vývojové prostředky Rozšíření licencí IBM Rational pro zátěţové a funkční testování Nástroje pro tvorbu formulářů
4,000 0,300
Námitkové řízení Další rozvoj subsystému Celkem aplikační oblasti
Celkem Směrné číslo ? Původně plánováno- v roce 2008 (šedivá tabulka z minulé strategie)
891,700
571,000
477,900
359,200
1 317,650
946,500
648,150
491,700
700,000
500,000
500,000
500,000
260,000
265,000
310,000
Vykazované finanční prostředky: v roce 2011 a 2014 vyjadřují potřeby Z uvedeného výčtu je patrné nerovnoměrné čerpání investičních prostředků v jednotlivých letech zapříčiněné zejména změnami výkazní činnosti a nutnými potřebami a zajišťováním procesu inovace a bezpečnosti vyuţívaných technologií. Čerpání věcných výdajů koresponduje se zajišťovaným rozsahem sluţeb rozšířeným o provádění vlastní digitalizace dokladů. Od roku 2005 celkové roční náklady úseku IKT oscilují mezi 2 aţ 2,5 promile nákladů z celkových ročních obratů agend ČSSZ. Poznámka: Vzhledem k tomu, ţe i přes výše uvedené skutečnosti se můţe zdát celkový objem prostředků na financování IKT v ČSSZ vysoký. Ale například pro srovnání, poplatky České poště a.s. za poskytování sluţeb v oblasti výplat důchodů, které v roce 2008 činí 386 mil. Kč, výše této částky dosahuje 28% proti nákladům za zajišťování technologií a sluţeb pro oblast důchodovou, nemocenskou, LPS a další.
8.2
Strategie financování rozvoje IIS ČSSZ
Prioritním úkolem financování úseku IKT je zajištění účelného, efektivního, hospodárného, plynulého a vyváţeného čerpání investic i věcných výdajů s podmínkou dosaţení efektivnosti a hospodárnosti a současně se zajištěním kontinuální inovace pouţívaných technologií. Za tím účelem jsou vyuţívány následující formy: nákup zařízení a sluţeb pronájem zařízení outsourcing sluţeb. Tyto formy jsou uplatňovány nerovnoměrně, neboť jejich výhodnost je v různých časech a v různých konstelacích rozdílná. Proto ČSSZ například v současné době nevlastní centrální počítač (mainframe), ale má pronajatý potřebný výkon na zajištění provozu důchodových agend; na základě studie proveditelnosti (výhodnosti) přistoupila na outsourcing tiskáren, naproti tomu pracovní stanice má v pronájmu apod. Dalším prioritním úkolem úseku IKT je minimalizace nákladů. Vzhledem k tomu, ţe minimalizaci nákladů přímo ovlivňuje: uplatňování nových technologií přímá závislost nákladů na následný provoz technologií ve vztahu k jejich pořizovací hodnotě zvyšování kvality a rozsahu sluţeb řešení bezpečnosti přechodné období, kdy jsou provozovány staré i nové technologie a další povaţuje úsek IKT vyrovnanost předpokládaných nákladů v následujících letech za výrazný klad. Posledním prioritním úkolem financování úseku IKT je vyuţívání dalších mimorozpočtových zdrojů, zejména strukturálních fondů EU.
123
8.3
Strukturální fondy EU
ČSSZ aktivně vyhledává moţnost mimorozpočtových zdrojů pro projekty mimořádného významu na mezinárodní i národní úrovni, především ze dvou operačních programů strukturálních fondů Evropské unie: „Integrovaný operační program (IOP)“ – v jeho rámci by se vyuţily osy Modernizace veřejné správy a Zavádění ICT v územní veřejné správě, konkrétně by byly financovány oblasti ACCESS POINT (přístupové místo k datům pojištěnců v EU), klientský portál, e-podání, digitalizace dokumentů potřebných pro provádění agendy sociálního pojištění; „Lidské zdroje a zaměstnanost (OP LZZ)“ – tento operační program by vyuţil osy Veřejná správa a veřejné sluţby, konkrétně by byly financovány oblasti Personální zajištění digitalizace agendy sociálního pojištění a Rozvoj lidských zdrojů ČSSZ.
8.3.1 8.3.1.1
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
Tyto projekty jsou součástí Usnesení vlády č. 536 ze 14.5.2008 a byly zařazeny do seznamu strategických projektů pro čerpání finančních prostředků ze Strukturálních fondů Evropské unie a zahrnuty do Strategie Efektivní veřejná správa a přátelské veřejné sluţby. Projekt IOP č.155 - „Konsolidace kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na ROB a další základní registry veřejné správy“: Cíle: Vytvořit hmotné základy (budova, HW, SW) procesů vytěţování informací pro vytváření a konsolidaci kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na základní registry veřejné správy Přispět k modernizaci veřejné správy České republiky, resp. přispět ke zvyšování efektivity fungování ČSSZ vůči svým klientům a jiným orgánům veřejné správy, Vazby na eGovernment: v budoucnu se plánuje vyuţít konsolidovaných evidencí pojištěnců ke zkvalitnění dat ZRVS, především ROS a ROB Vazby na jiné projekty ČSSZ: Tento projekt je základním předpokladem realizace projektu 156-2 a důchodové reformy. Projekt OP LZZ č.156 „Personální zajištění procesů vytěžení informací pro vytváření a konsolidaci kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na základní registry veřejné správy“: Cíle projektu 156-1: - zajistit realizaci procesu vytěţování a konsolidace dat v oblasti dávkových spisů LPS, - vzdělávání a proškolování zaměstnanců ve vazbě na implementaci legislativních změn do informačních systémů veřejné správy - v oblasti LPS. - výtisk a distribuce broţury pro cílové skupiny projektu. Vazby na eGovernment: Strategickým cílem projektu je přispět k posílení institucionální kapacity, kvality, efektivnosti a transparentnosti činností ČSSZ ve vztahu k evropskému eGovernmentu a výměně elektronických informací v rámci EESSI (evropský systém pro výměnu elektronických informací v oblasti sociálního pojištění). Cíle projektu 156-2: - procesní a personální zajištění pro vytěţování a konsolidace dat v rámci agend ČSSZ, které budou slouţit jako podklad agendových informačních systémů, z kterých se budou čerpat informace do soustavy základních registrů veřejné správy. Vazby na eGovernment: v budoucnu se plánuje vyuţít konsolidovaných evidencí pojištěnců ke zkvalitnění dat ZRVS, především ROS a ROB Vazby na jiné projekty ČSSZ: Projekt navazuje na projekt 155, ve kterém budou zajištěny technické podmínky pro tento projekt. Projekt je jedním z pilířů přípravy důchodové reformy. Projekt IOP č.157 „Elektronická podatelna a výpravna České správy sociálního zabezpečení v návaznosti na systém datových schránek“: Cíle: 124
Dostát legislativním poţadavkům a pořídit specializovaný software nutný pro zbudování zákonem vyţadované elektronické podatelny a elektronické výpravny v návaznosti na systém datových schránek, které budou integrovány se systémy spisové sluţby a Dokument management systému (DMS). Pořídit HW, na kterém bude systém provozován. Zajistit evidenci elektronických podání z el. podatelny a z el. pošty, která je vyţadována zákonem. Zmodernizovat celý systém integrovaný na spisovou sluţbu tak, aby bylo moţné kvalitněji a rychleji administrovat větší objem dokumentace a tím zvýšit kvalitu poskytovaných sluţeb klientům ze všech regionů ČR. Sníţit administrativní zátěţ na všech územních pracovištích ČSSZ a zkvalitnit zákonem povinně poskytované sluţby. Vazby na eGovernment: vazba na ISDS Vazby na jiné projekty ČSSZ: Projekt je předpokladem zavedení elektronické spisové sluţby v rámci celé ČSSZ a yvuţití ISDS jako datového vstupu. Projekt IOP č.159 „Projekt č. 159 - Vytvoření informačního a komunikačního rozhraní ČSSZ za účelem poskytování informací klientům“: 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. Cíle projektu „Vybudování Access point – přístupových míst ČR do Evropské architektury pro výměnu standardizovaných zpráv sociálního zabezpečení“: Cíle projektu jsou plně v souladu s jednou ze základních strategií EU, coţ je rozvoj informační společnosti, kam vybudování Access Point spadá. Základním cílem projektu je vybudování plně fungujících přístupových míst k datům pojištěnců v EU Access Point, které zajistí potřebnou interoperabilitu s ostatními zahraničními dotčenými orgány v rámci Evropské architektury pro výměnu standardizovaných zpráv sociálního zabezpečení (EESSI). Cíle projektu „Vytvoření klientského portálu České správy sociálního zabezpečení v souladu s Portálem veřejné správy a agendovými portály“:
Zefektivnění komunikace orgánů státní správy s občany (moţno identifikovat i další návaznosti na jiné systémy, např. portál veřejné správy) Modernizace veřejné správy České republiky Uplatnění systémového přístupu v řešení elektronické dostupnosti informací o individuálních kontech pojištěnce pro klienty ČSSZ pro zefektivnění sluţeb elektronické veřejné správy Elektronizace sluţby výpisu z Individuálního konta pojištěnce - umoţnění elektronického přístupu pojištěným a důchodcům k jejich osobním datům, které jsou uloţeny v databázích ČSSZ a to především 125
k informacím o důchodových nárocích vedoucí k rychlejšímu poskytování sluţeb a sníţení finančních nároků na chod administrativy Maximální zabezpečení poskytovaných dat tak, aby bylo minimalizováno riziko zneuţití neoprávněnou osobou
Cíle projektu „Elektronická podatelna a výpravna České správy sociálního zabezpečení v návaznosti na systém datových schránek“:
Dostát legislativním poţadavkům a pořídit specializovaný software nutný pro zbudování zákonem vyţadované elektronické podatelny a elektronické výpravny v návaznosti na systém datových schránek, které budou integrovány se systémy spisové sluţby a Dokument management systému (DMS). Pořídit HW, na kterém bude systém provozován. Zajistit evidenci elektronických podání z el. podatelny a z el. pošty, která je podmíněna zákonem. Zmodernizovat celý systém integrovaný na spisovou sluţbu tak, aby bylo moţné kvalitněji a rychleji administrovat větší objem dokumentace a tím zvýšit kvalitu poskytovaných sluţeb klientům ze všech regionů ČR. Sníţit administrativní zátěţ na všech územních pracovištích ČSSZ a zkvalitnit zákonem povinně poskytované sluţby.
Cíle projektu „Personální zajištění procesů vytěžení informací pro vytváření a konsolidaci kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na základní registry veřejné správy“: Hlavním strategickým cílem projektu je přispět k posílení institucionální kapacity, kvality, efektivnosti a transparentnosti činností ČSSZ, resp. k modernizaci veřejné správy České republiky, čili přispět ke zvyšování efektivity fungování ČSSZ vůči svým klientům a jiným orgánům veřejné správy. Jedná se o podporu aplikace nástrojů zvyšování kvality a efektivity veřejné správy ČSSZ. Věcným cílem projektu je zajištění vytěţení informací z dokumentů relevantních pro provádění sociálního pojištění, a to zejména: Průběţné doplňování centrálního registru pojištěnců, plátců pojistného a pojistných vztahů. Průběţná aktualizace centrální databáze nárokových podkladů. Podpora vytvoření elektronického dávkového spisu pro rozhodování o dávkách důchodového pojištění. Cíle projektu „Konsolidace kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na ROB a další základní registry veřejné správy“:
Vytvořit hmotné základy pro procesy vytěţování informací pro vytváření a konsolidaci kmenových evidencí pojištěnců a jejich individuálních kont v návaznosti na základní registry veřejné správy Přispět k modernizaci veřejné správy České republiky, resp. přispět ke zvyšování efektivity fungování ČSSZ vůči svým klientům a jiným orgánům veřejné správy Zavést takové informační a komunikační technologie, které povedou k optimalizaci činnosti ČSSZ a nabídnou klientům a ostatním orgánům veřejné správy rychlejší a méně komplikované sluţby.
Cíle projektu „Rozvoj lidských zdrojů v oblasti odborného vzdělávání, posílení výkonnosti a kvality služeb v rámci optimalizace systému řízení a zlepšení kvality veřejných služeb v ČR“: Posílit adaptabilitu pracovníků úřadu rozvojem jejich odborných a obecných znalostí a kompetencí, prohlubováním a rozšiřováním jejich kvalifikace a tím přispět k modernizaci veřejné správy prostřednictvím rozvoje lidských zdrojů. Jedná se především o: Specifické vzdělávání o školení v oblasti odborného zaměření zaměstnanců o sestavení moderních výukových modulů podle potřeb ČSSZ o vzdělávání zaměstnanců Call centra a informačních kanceláří v měkkých dovednostech o rozšíření nabídky odborných e-learningových modulů podporujících profesní vzdělávání Obecné vzdělávání zaměstnanců o jazykové vzdělávání, odborné jazykové vzdělávání v úrovni potřebné pro činnost s mezinárodním prvkem o vzdělávání tzv. soft-skill 126
o vzdělávání v oblasti informačních technologií – nákup kurzů, učebnic, CD, atp. o vzdělávání v základním IT prostředí Proškolení lektorů v konkrétní odbornosti v souvislosti s pěti předkládanými projekty do IOP Vzdělávání pro odborně příslušné zaměstnance v souvislosti s pěti předkládanými projekty do IOP Model funkčního centra pro eliminaci moţných rizik ohroţení zdraví zaměstnanců ČSSZ, tj. systému ochrany zdraví při celoţivotním výkonu práce na pracovišti Stáţe zaměstnanců v zahraničí a případně zahraničních expertů v Čechách Odborné semináře a mezinárodní konference Tématické analýzy Zpětná vazba s uţivateli veřejných sluţeb (např. analýzy, průzkumy, trendy) Publicita a propagace
127
9 Závěr Strategie rozvoje úseku IKT vychází z dokumentů zpracovaných po roce 2001. Základním cílem je realizace nové technologické platformy na podporu procesního zpracování činností ČSSZ do roku 2014. Ve strategii rozvoje nedochází k zásadním změnám, ale dochází k aktualizaci priorit, posloupností a aktualizaci časových úkolů. Základní strategie – vybudovat integrovaný informační systém na bázi třívrstvé architektury a principu centralizace dat a zpracování, decentralizace obsluhy klientů a maximálního vyuţití unifikace a moderních IK technologií se osvědčila. Je strategií otevřenou a dovoluje vyuţívat vazeb na ostatní subjekty veřejné správy a instituce a počítá s vyuţitím elektronických metod podpory spolupráce i na mezinárodní úrovni. Vzhledem k tomu, ţe vlastní realizace je dlouhodobým a náročným procesem trvajícím od roku 2001, nevyhnuly se tomuto procesu negativní externí i interní vlivy, jako např.: časté změny zákona o nemocenském pojištění časté změny zákona o důchodovém pojištění odloţení účinnosti zákona č. 187/2005 Sb., nutnost řešení mnoha změn v relativně krátkém časovém období, jejichţ častým rizikem byly termíny plnění nekorespondující s termíny plnění navazujících projektů administrativní procesy uvolňování finančních prostředků a zajišťování dodávek pro řešení uvedených mimořádných situací, podcenění rozsahu transformace důchodových agend v úvodních analýzách a zadáních realizačních projektů, jak ze strany ČSSZ, tak zejména ze strany externích dodavatelů (poskytovatelů), nutnost dlouhodobého souběhu starých technologií (Mainframe) a nově pořizovaných a implementovaných technologií a aplikací, omezené personální zdroje na straně ČSSZ v úseku IKT pro: o zajištění úprav a změn v běţících (starých) aplikacích, o na práci ve společných (s dodavateli) projektových týmech, zajištění plné funkčnosti a bezpečnosti provozu starých i nově vznikajících aplikací v centu ČSSZ i na regionech. Tempo rozvoje IIS ČSSZ je přímo závislé na objemu a struktuře finančních zdrojů. Finanční zdroje uvedené v kapitole 3.1 jsou nutné na zajištění údrţby a provozu stávajících agend a na zajištění postupného rozvoje transformačních projektů. V roce 2008 není dosud pokryto 112 mil. Kč, v roce 2009 je vykazováno z uvedené částky CELKEM IKT 644 097 mil. Kč v „nadpoţadavcích“, v roce 2010 je v Dokumentaci programu registrováno 746 mil. Kč a financování potřebného rozpočtu není zaručeno. Pro realizaci a rozvoj dalších projektů jsou uplatněny záměry na vyuţití jiných zdrojů. Prostředky ze strukturálních fondů EU zajistí realizaci projektů integračního charakteru (evropská architektura pro výměnu dat, e-Government, atd.), projekty na podporu elektronického styku s občany a organizacemi a projekty na zajištění tvorby SW aplikační podpory významných agend např. na úrovni valorizace důchodů. Ve financování prostředků na rozvoj IIS ČSSZ nelze předem nárokovat potřebné finanční krytí na tvorbu potřebné SW aplikační podpory vyplývající z nových změn zákonných předpisů, Proto i do budoucna je nutné kalkulovat s touto poloţkou jako součástí překladatelského návrhu příslušného návrhu zákona. Stávající zkušenosti s tvorbou aplikační podpory externími subjekty ukazují nezbytnost, aby klíčové role a činnosti – strategie, řízení, koordinace, kontrola, bezpečnost a tvorba důleţitých modulů aplikační softwarové podpory byly ve vlastnictví ČSSZ. Ostatní činnosti úseku IKT lze zajišťovat dodavatelsky. Nezajištění dostatečného financování nebo případné krácení plánovaných rozpočtů včetně necitlivého sniţování počtu pracovníků IKT můţe okamţitě nebo i určitým zpoţděním váţně ohrozit termíny a provoz IIS ČSSZ a ve svém důsledku ohrozit realizaci legislativních změn reforem.
128
