I-02 Projektový zámer (projektovy_zamer)

PROJEKTOVÝ ZÁMER

Vzor pre manažérsky výstup  I-02

 podľa vyhlášky MIRRI č. 401/2023 Z. z.  (účinnosť od 1.4.2025)

Schvaľovanie dokumentu

1. HISTÓRIA DOKUMENTU

2. ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

V súlade s vyhláškou MIRRI č. 401/2023 Z.z. v znení neskorších predpisov je tento výstup I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravnej a iniciačnej fázy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Projektový zámer obsahuje manažérske zhrnutie, rozsah, ciele a motiváciu na realizáciu projektu, zainteresované strany, návrh merateľných ukazovateľov a obsahuje aj

               1. detailný opis požadovaných projektových výstupov,

               2. detailný opis obmedzení, predpokladov, tolerancií a návrh organizačného zabezpečenia projektu,

               3. detailný opis rozpočtu projektu a jeho prínosov,

               4. harmonogram projektu,

5. vyhodnotenie rizík a závislostí,

               6. architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy a bezpečnostnej architektúry,

               7. vyhodnotenie alternatív riešenia projektu pre každú vrstvu architektúry riešenia,

               8. špecifikáciu a klasifikáciu údajov spracovaných v projekte,

               9. požiadavky na prevádzku a údržbu výstupov projektu,

               10. požiadavky na technologickú infraštruktúru a posúdenie alternatív prevádzky infraštruktúry cloud computingom,

               11. požiadavky na zdrojové kódy,

               12. opis implementácie projektu a preberania výstupov projektu.

Vyhotovené sú aj dokumenty I-04 Katalóg požiadaviek, M-05 Analýza nákladov a prínosov a M-06 Evidencia komponentov v MetaIS.

2.1 Použité skratky a pojmy

Tabuľka 1 Skratky a pojmy

2.2 Konvencie pre typy požiadaviek (príklady)

Zoznam požiadaviek vychádza z biznis požiadaviek Implementačných plánov všetkých životných situácií Počas implementácie projektu Prierezové oblasti ŽS sa rozlišujú biznis požiadavky na MMP (Minimal Marketable Product) – ktoré sú „must“ na dodanie implementácie celkovej životnej situácie a požiadavky, ktoré nie sú MMP a napĺňajú ciele programu životných situácií, ale patria do kategórie „should“ alebo „could“.  

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek I-04 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

2.3 Zoznam diagramov

Diagram 1: Náhľad celkovej architektúry ŽS v prostredí SP. 16

Diagram 2: Náhľad na Frontend životných situácií v prostredí SP. 17

Diagram 3: Strešný model biznis architektúry Frontendu - AS IS. 39

Diagram 4 : Strešný model architektúry Frontendu - TO BE. 41

Diagram 5: kľúčové prípady použitia mobilnej aplikácie a vzťah aplikácie k systémom, na ktoré sa integruje. 42

Diagram 6: Celková architektúra DI-7 (predvypĺňanie formulárov). 47

Diagram 7: Strešný pohľad na architektúru DI-8 (priama integrácia na NCZI). 48

Diagram 8: Biznis proces Podateľňa - Príjem zásielky. 48

Diagram 9:  Vytvorenie žiadostí a oznámení a ich podpísanie asistovane na pobočke TO BE. 55

Diagram 10: Najvýznamnejšie komponenty SP z pohľadu riešení a funkcionalít Frontendu – AS IS. 56

Diagram 11:  Aplikačná architektúra EKP - AS IS. 58

Diagram 12: Aplikačná architektúra Frontend - TO BE. 60

Diagram 13: Aplikačná  architektúra Frontendu - Moje dáta, Moje údaje, Moje dokumenty - TO BE. 61

Diagram 14: Aplkačná architektúra Frontend - Konštruktor podania – TO BE. 62

Diagram 15: Rezervačný systém TO BE. 64

Diagram 16: Služba zabezpečenej elektronickej komunikácie TO BE. 66

Diagram 17: Celková architektúra DI-2. 67

Diagram 18: Získavanie údajov z CSRÚ do MÚSP (MDM). 68

Diagram 19: Získavanie údajov z CSRÚ - sekvenčný diagram.. 69

Diagram 20: Publikovanie údajov do CSRÚ.. 70

Diagram 21: Publikovanie údajov do CSRÚ - sekvenčný diagram.. 70

Diagram 23: Publikovanie údajov do MDM (IS MÚSP). 71

Diagram 24: Publikovanie údajov do MDM (IS MÚSP) - sekvenčný diagram.. 72

Diagram 25: Získanie údajov SP - BATCH (MÚSP → IS SP). 74

Diagram 26: Získanie údajov SP - BATCH - sekvenčný diagram.. 74

Diagram 27: Celková architektúra DI-4. 76

Diagram 28: Publikovanie údajov do IS MÚSP/MDM... 79

Diagram 29: Publikovanie údajov do IS MÚSP/MDM - sekvenčný diagram.. 80

Diagram 30: Získanie údajov SP - BATCH (komponenty). 81

Diagram 31: Získanie údajov SP - BATCH - sekvenčný diagram.. 81

Diagram 32: Celková architektúra DI-5. 82

Diagram 33: Celková architektúra DI-6. 86

Diagram 34: Aplikačná architektúra DI-7. 90

2.4 Zoznam tabuliek

Tabuľka 1 Skratky a pojmy. 1

Tabuľka 2: Zoznam tém, do ktorých sa biznis požiadavky priraďovali 7

Tabuľka 3 Zainteresované strany (Stakeholderi) 8

Tabuľka 4 Ciele projektu. 8

Tabuľka 5 Merateľné ukazovatele (KPI) 8

Tabuľka 6 Prehľad najzávažnejších rizík a závislostí 10

Tabuľka 7 Sumarizácia nákladov a prínosov. 11

Tabuľka 8 Projektový tím.. 16

Tabuľka 9: Témy oblasti Frontend. 21

Tabuľka 10: Navigácia služieb podľa životnej situácie. 22

Tabuľka 11: Poskytnutie informácií o elektronickej službe podľa životnej situácie. 22

Tabuľka 12: Zoznam elektronických služieb, ku ktorým budú zobrazené informácie a návody na webe SP (www.socpoist.sk) 24

Tabuľka 13: Zoznam aktuálnych e-formulárov, ktoré budú premiestnené k novo-vytvoreným e-formulárom.. 25

Tabuľka 14: Zoznam BP pre redizajn verejného webu SP podľa životnej situácie. 27

Tabuľka 15: Zoznam BP pre redizajn špecializovaného portálu SP podľa životnej situácie. 28

Tabuľka 16: Zoznam BP, ktorých sa týka téma Odvolanie podľa životnej situácie. 29

Tabuľka 17: Témy oblasti Monitoring služieb. 36

Tabuľka 18: Dosah Rezervačného systému na komponenty SP. 48

Tabuľka 19: Prehľad koncových služieb, ktoré budú projektom upravené. 57

Tabuľka 20: Prehľad koncových služieb, ktoré budú projektom zrušené (napr. z dôvodu zlúčenia služieb) 58

Tabuľka 21: Prehľad nových koncových služieb. 58

Tabuľka 22: Prehľad datasetov a ich integračných vyťahov v DI-2. 75

Tabuľka 23 Rozsah informačných systémov - budúci stav (TO BE) 107

Tabuľka 24 Využívanie nadrezortných a spoločných ISVS – súčasný stav (AS IS) 108

Tabuľka 25 Prehľad plánovaných integrácií na spoločné moduly – budúci stav (TO BE) 108

Tabuľka 26 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE) 109

Tabuľka 27 Aplikačné služby pre Koncové služby – budúci stav (TO BE) 109

Tabuľka 28 Aplikačné služby na integráciu – budúci stav (TO BE)→.. 111

Tabuľka 29 Objekty evidencie. 116

Tabuľka 30 Návrh na vyhlásenie a zmeny referenčných údajov. 119

Tabuľka 31 Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE) 119

Tabuľka 32 Konzumovanie údajov z IS CPDI – budúci stav (TO BE) 120

Tabuľka 33 Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ) 122

Tabuľka 34 Zhodnotenie dátovej kvality objektov evidencie. 122

Tabuľka 35 Personálne zabezpečenie a roly pri riadení dátovej kvality. 122

Tabuľka 36 Objekty evidencie, ktoré budú sprístupnené ako otvorené údaje. 123

Tabuľka 37 Objekty evidencie, ktoré budú projektom pripravené pre analytické účely. 123

Tabuľka 38 Objekty evidencie, ktoré spadajú do kategórie Mojich údajov. 124

Tabuľka 39 Prehľad jednotlivých kategórií údajov. 124

Tabuľka 40 Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE) 127

Tabuľka 41 Využívanie služieb z katalógu služieb vládneho cloudu. 128

Tabuľka 42Predpokladané kapacity požadovaných výpočtových zdrojov (sizing) 128

Tabuľka 43 Predpokladané kapacity ďalších cloudových (infraštruktúrnych) služieb. 129

Tabuľka 44 Určenie zdrojov a obsahu minimálnych bezpečnostných opatrení 131

Tabuľka 45 Prehľad riešenia zabezpečenia podpory používateľov a prevádzky. 133

Tabuľka 46 Klasifikácia Naliehavosti incidentu. 135

Tabuľka 47 Klasifikácia Závažnosti incidentu. 135

Tabuľka 48 Určenie priority incidentu. 135

Tabuľka 49 Parametre služby Riešenia incidentov v prevádzke. 135

2.5 Zoznam obrázkov

Obrázok 1:Strategické zámery SP v kontexte budovania životných situácií 6

Obrázok 2: Odporúčané metriky pre monitoring spätnej väzby. 39

Obrázok 3 - Prehľad spracovania volania služby VyhladajZoznamPotrieb. 101

Obrázok 4 - Prehľad spracovania volania služby DajUdajePotreby. 102

3. DEFINOVANIE PROJEKTU

3.1 Manažérske zhrnutie

Projekt Prierezové oblasti ŽS je ďalším z projektov prioritných životných situácií identifikovaných MIRRI ako Investície 1 v rámci Plánu obnovy a odolnosti, Komponent 17. Realizovať životné situácie ako eGov služby je uvedené už NKIVS. Životné situácie sú definované ako rôzne udalosti, ktorými si občania prechádzajú v rámci svojho života.

Realizácia životných situácií je v súlade aj so strategickými zámermi SP v dokumente “Strategické zámery činnosti Sociálnej poisťovne na obdobie rokov 2024-2029"  schváleného NR SR, ktorý predstavuje základný riadiaci dokument rozvoja SP a venuje sa základným hodnotám a strategickej vízii SP. Dokument identifikuje poskytované elektronické služby SP a využívanie portálu SP ako silnú stránku, no vôľa realizovať rozvojové aktivity v rámci poisťovne je limitovaná slabými stránkami úzko spojenými s projektami životných situácií, najmä  zastaraný hardware, software, chýbajúca podpora, nízka flexibilita pri zmenách v IS SP, nedostatočná integrácia systémov a IT služieb a pretrvávajúca kultúra byrokracie. SP vidí príležitosť v realizácií životných situácií z Plánu obnovy a odolnosti najmä v implementácii aktuálnych trendov v elektronizácii, v zavádzaní proklientských a proaktívnych služieb a v zdieľaní referenčných dát s inštitúciami verejného sektora, ktoré by mali z časti odstrániť aj spomenuté slabé stránky.  

Dokument identifikuje hlavné princípy na obdobie 2024-2029, a to elektronický vývoj činnosti SP a proces kontinuálneho zlepšovania, ktoré sú v súlade s filozofiou e-Governmentu so zámerom poskytovať dostupné profesionálne služby klientom (Strategický zámer A). Tento zámer sa viaže nielen na elektronizáciu a digitalizáciu agendy, ale myslí aj na klientov, ktorí elektronické služby nemôžu z akéhokoľvek dôvodu využívať. Pre týchto klientov má SP poskytovať služby v moderných klientskych centrách, ktoré sa budú snažiť o čo najväčšiu mieru implementácie elektronizácie a digitalizácie pri scenári osobnej návštevy pobočky SP.  

Dokument poskytuje tzv. roadmapu pre spôsob implementácie budúcich aktivít SP a identifikuje niekoľko strategických cieľov, z ktorých nasledujúce sú priamo spojené s projektami životných situácií: 

• Strategický cieľ A.1: Zvyšovanie kvality koncových služieb (implementácia životných situácií a vytvorenie unifikovaného kontaktného miesta) 
• Strategický cieľ A.2: Plynulé zlepšovanie služieb (zbieranie spätnej väzby a vytvorenie Centra hodnotenia kvality a reklamácií) 
• Strategický cieľ A.3: Proaktívna komunikácia s klientom (prostredníctvom verejného mediálneho priestoru a vlastných komunikačných kanálov a notifikačného modulu v spolupráci s NASES) 

Obrázok 1:Strategické zámery SP v kontexte budovania životných situácií

V súlade s NKIVS, Strategickými zámermi SP a programom životných situácií bola Sociálna poisťovňa identifikovaná ako jeden z hlavných aktérov v životných situáciách, následne bola vyzvaná priamym vyzvaním MIRRI 17I01-04-023 a stala sa priamym prijímateľom prostriedkov mechanizmu podľa zmluvy 34406-1/2023-BA.

Jednotlivé životné situácie sa v prostredí SP plánujú realizovať dvomi projektami – Projekt ŽSX a projekt Prierezové oblasti ŽS. Tento dokument sa venuje Projektu Prierezové oblasti ŽS.

Projekt Prierezové oblasti ŽS v prostredí SP nadväzuje na dokumenty MIRRI k prioritným životným situáciám – Investičný plán a Implementačný plán. Projekt je postavený na zmenových požiadavkách existujúcich IS SP s dôrazom na dátové integrácie, biznis proces manažment, implementáciu zasielania notifikácií a frontendových úprav a úprav samotných koncových služieb, ktoré vychádzajú z identifikácie optimalizačných príležitostí a ktoré majú odstrániť alebo mitigovať nedostatky zistené v procese analýzy pre tvorbu Investičného plánu ŹS a majú prispieť k naplneniu cieľov programu Životných situácií. Navrhované riešenie dopĺňa riešenia v projektoch pre jednotlivé životné situácie a pokrýva prierezové témy a zmenové požiadavky, ktoré je potrebné vykonať vo všetkých životných situáciách (ako napr. Monitoring spätnej väzby  či notifikácie).

Jadrom projektu sú:

• úpravy formulárov koncových služieb - úprava existujúcich a tvorba nových
• Dátové integrácie - najmä na IS tretích strán
• Registratúra – pre správne spracovanie doručených žiadostí a ich zadelenie do agiend
• Notifikácie - pre proaktivitu SP

Cieľom implementácie Projektu je zjednodušiť zákaznícku cestu občanov/klientov SP prostredníctvom úpravy a pridanie nových koncových služieb s využitím princípu “jeden krát a dosť” a s ohľadom na multikanálový prístup k službám. Kľúčovým nástrojom pre dosiahnutie cieľa je optimalizovať integráciu IS SP a tretích strán (najmä MPSVaR a NCZI) tak, aby údaje, ktoré už štát o občanovi má, nepožadoval znovu.

Projekt predstavuje výhody pre koncových užívateľov:

1. 
   
   1. Občan
   2. Podnikateľ
   3. Pracovník SP
   4. Pracovník iných OVM

Zmenové požiadavky na informačné systémy, nové systémy aj zmeny systémov, ktoré sa budú vyvíjať internými kapacitami SP, budú financované z prostriedkov Plánu obnovy a odolnosti SR – Komponent 17. SP bude na základe uzatvorených zmlúv, ktoré určia celkovú alokáciu na budovanie životných situácií predkladať žiadosti o platbu, ktorých prílohou bude projektová dokumentácia.  

Celková hodnota projektu Prierezové oblasti ŽS je xxxxx bez DPH.

3.2 Motivácia a rozsah projektu

Analýzou vykonanou dotknutými OVM a MIRRI popísanou v Investičnom pláne bolo identifikovaných niekoľko oblastí, v ktorých sú témy pokryté v tomto projekte v rozpore s princípmi eGOV služieb alebo princípy aplikujú iba čiastočne. Ide o princípy:

1. Jednoduchosť
   1. Zrozumiteľnosť
   2. Prehľadnosť
   3. Personalizácia
   4. 1x a dosť
   5. Uniformita online
   6. Jednotný obslužný bod
2. Proaktivita
   1. Proaktívne ponuky, štát nečaká
3. Efektivita
   1. 1x a dosť
   2. Optimalizácia/Digital first
   3. Aktuálnosť
4. Informovanosť
   1. Prístup k mojim informáciám
   2. Podpora
   3. Predvídateľnosť
5. Participácia

Navrhovaný projekt je zároveň v súlade s cieľmi programu Životných situácií zadefinovaných v Investičnom pláne, ktoré vychádzajú aj z NKIVS (viac v podkapitole 3.4 a 3.5):

• zjednodušiť elektronickú komunikáciu občana so štátom – jasná a jednoduchá komunikácia
• 1x a dosť – prepájanie s registrami, databázami o digital first
• redukovať vstupy občana
• redukovať formuláre
• v akom stave je požiadavka
• overenie cez počítač, mobil
• Informácie na jednom mieste – hľadanie informácií aj vyriešenie
• promovať online vybavovanie – zvýšiť mieru online vybavovania
• proaktívnosť štátu – notifikácie, možnosť autorizácie, vybavenie úkonov
• minimalizovať úkony na strane občana
• poskytovať zrozumiteľné návody aj ich aktualizovanie
• občan má byť spokojnejší s online vybavovaním
• dostupná online podpora

V kontexte strategických cieľov SP, SP identifikovala výstupy a jednotlivé biznis nástroje potrebné na ich naplnenie (viď Obrázok 2), ktoré sú zladené aj s vyššie uvedenými cieľmi NKIVS a cieľmi programu životných situácií.  

Obrázok 2: Strategické zámery SP a ich napĺňanie

Základným kameňom programu Budovanie životných situácií je Centrálny katalóg požiadaviek, ktorý obsahuje:

• Všetky biznis požiadavky z implementačných plánov životných situácií
• Rozvetvenie biznis požiadavky na funkčné požiadavky
• Zaradenie požiadaviek do jednotlivých projektov a ucelených tém
• Priradenie dotknutých IS k jednotlivým témam

Projekt Prierezové oblasti ŽS bude dodaný prostredníctvom ucelených tém:

• Frontend (vrátane modernizácie mobilnej aplikácie a  eFromulárov)
• Dátové integrácie
• Notifikácie (Notifikačný modul SP)
• Registratúra
• Monitoring služieb a spätná väzba

Projekt Prierezové oblasti ŽS (v prostredí SP) sa primárne sústreďuje na spoločné oblasti vývoja a navrhovaných zmien. Jednotlivé zmeny a novovytvárané služby či procesy sú súčasťou jednotlivých životných situácií a je na ne odkazované v projektovej dokumentácii k daným životným situáciám. Prierezové oblasti tak dotvárajú celkový obraz TO BE stavu individuálnych životných situácií, ktoré realizuje SP.

Pri stanovení jednotlivých realizačných tém sa okrem motivácií vyplývajúcich z NKIVS či zo stratégie SP bralo ohľad na existujúcu legislatívu a povinnosti z nej plynúce a to najmä pri oblasti monitoring a spätná väzba.

Zber a vyhodnocovanie spätnej väzby od používateľov elektronických služieb je upravený o.i. aj vyhláškou č. 547/2021 Z. z., konkrétne § 11, ktorý ustanovuje povinnosť správcov špecializovaných portálov:

• zabezpečiť možnosť spätnej väzby po použití elektronickej služby,
• uchovávať a poskytovať tieto dáta orgánu vedenia (MIRRI) na vyžiadanie minimálne za obdobie 12 mesiacov,
• využiť zistenia zo spätnej väzby na zlepšenie služieb.

V zmysle § 13a zákona č. 95/2019 Z. z., v znení zákona č. 301/2023 Z. z., sa vyžaduje:

• priebežný zber spätnej väzby k prioritným životným situáciám,
• každoročné vyhodnotenie a jeho poskytnutie orgánu vedenia (MIRRI) najneskôr do 31. januára.

Orgán riadenia má zároveň podľa § 17 zákona č. 95/2019 Z. z. povinnosť monitorovať elektronické služby ako súčasť správy informačných technológií a poskytovať výsledky monitorovania MIRRI na účely analýz a hodnotenia.

Rozsah projektu bol definovaný priebežne – od tvorby investičného plánu, kde sa identifikovali nedostatky pri jednotlivých ŽS, cez implementačný plán, ktorý definoval rámcové biznis požiadavky až po katalóg požiadaviek, ktorý ďalej definuje špecifikuje rozsah jednotlivých biznis požiadaviek. Detailný popis plánovaných aktivít je potom popísaný v kapitole 5.

Tabuľka 2: Zoznam tém, do ktorých sa biznis požiadavky priraďovali

3.3 Zainteresované strany (Stakeholderi)

Tabuľka 3 Zainteresované strany (Stakeholderi)

3.4 Ciele projektu

Tabuľka 4 Ciele projektu

3.5 Merateľné ukazovatele (KPI)

Tabuľka 5 Merateľné ukazovatele (KPI)

3.6 Špecifikácia potrieb koncového používateľa

Primárnym koncovým používateľom a užívateľom výhod projektu je občan, sekundárnym koncovým používateľom a užívateľom výhod je pracovník SP a terciárnym pracovník iného OVM, ktorý bude užívať výhod vo forme zdieľaných údajov. Analýza potrieb koncového používateľa – najmä občana a pracovníka SP- prebehla pri tvorbe Investičného a Implementačného plánu ŽS, t.j. pri mapovaní súčasného procesu a identifikovaní nedostatkov a optimalizačných príležitostí. Vychádzalo sa zo štandardov používateľskej skúsenosti a prívtevosti elektronických služieb, pričom sa bral ohľad na prehľadnosť, počet krokov, ktoré musí používateľ v službe vykonať a množstvo údajov, ktoré musí vyplniť. Potreby koncového používateľa odrážajú aj princípy programu Budovanie životných situácií, napr. jeden krát a dosť, proaktívosť štátu a pod.  

3.7 Detailný opis obmedzení a predpokladov

Rozsah projektu je definovaný zoznamom biznis požiadaviek, ktoré pochádzajú z jednotlivých životných situácií a ich potrieb, avšak ich realizácia je spravidla nutná pre všetky životné situácie. Ako názov projektu napovedá, ide o prierezové oblasti – Monitoring služieb, zasielanie notifikácií a či úprava a predvypĺňanie e-formulárov.

Obmedzenia projektu spočívajú najmä v procesoch a aktivitách stanovenými či plnenými tretími stranami, napr. proces verejného obstarávania či úspešná realizácia a dokončenie projektov, na ktorých je projekt Prierezové oblasti ŽS v prostredí SP závislý (napr. na MIRRI či NCZI). Ďalším z obmedzení a zároveň potenciálnym rizikom je možný nedostatok odborných kapacít na strane dodávateľov, nakoľko SP je iba jedno z OVM, na ktorých sa ŽS realizujú.

Predpokladá sa, že všetky zúčastnené strany budú aktívne participovať na úspešnej realizácii predkladaného projektu a predpokladá sa, že potrebné verejné obstarávanie nebude musieť opakované, hoci sa počíta s miernym zdržaním.  

3.8 Vyhodnotenie rizík a závislostí

Riziká a závislosti sú detailizované v samostatnej prílohe 3 – Zoznam rizík a závislostí a sú vedené centrálne za celý program.

Tabuľka 6 Prehľad najzávažnejších rizík a závislostí

3.9 Detailný opis rozpočtu projektu a jeho prínosov

3.9.1 Sumarizácia nákladov a prínosov

S ohľadom na množstvo modulov, ktoré sa v projekte realizujú uvádzame len finálne čiastky. Rozpočet jednotlivých modulov je v prílohe M05..

Tabuľka 7 Sumarizácia nákladov a prínosov

3.9.2 Zdroj financovania

Zdroj financovania je Plán obnovy a odolnosti, Investícia 1. Prevádzka bude hradená v interných zdrojov SP.

3.9 Harmonogram projektu

^*1 Riziko ukončenia VO s možným dopadom na termíny.

3.11 Návrh organizačného zabezpečenia projektu (projektový tím)

Riadiace výbory rozhodujúce o prierezovom projekte budú dve, t.j. Riadiaci výbor k Frontendu a Spätnej väzbe a Riadiaci výbor k BPM, notifikačnému modulu a registratúre. Dátové integrácie a monitoring budú vždy súčasťou projektových RV k ŽS.

Členovia RV s hlasovacím právom sú spravidla biznis vlastníci jednotlivých oblastí prierezu a zástupcovia dodávateľov. Na každom RV sa zúčastňuje projektový manažér prierezových oblastí a programový manažér ŽS.

Rola predsedu RV, riaditeľa sekcie stratégií a informatiky čiastočne pokrýva rolu sponzora projektu a zástupcu za IT a prevádzku. Podľa vopred pripravenej agendy a potreby sú na zasadnutie prizývaní ad hoc členovia, napr. zástupca CX/UI dizajnér, zástupca architektonickej rady SP či zástupca prevádzky IT.

Tabuľka 8 Projektový tím

4. LEGISLATÍVA

4.1 Frontend

• Legislatívna zmena zákona č. 461/2003 Z.z. o sociálnom poistení
  •  závislosť na:

• Zákon č. 43/2004 Z. z. o starobnom dôchodkovom sporení a o zmene a doplnení niektorých zákonov
• Zákon č. 483/2001 Z. z. o bankách a o zmene a doplnení niektorých zákonov v znení neskorších predpisov
  • Plánované predložiť: 30.4.2025
  • Očakávaná platnosť: 1.10.2025
  • Navrhovaná účinnosť: 1.1.2026/1.4.2026

Hlavné legislatívne zmeny zákona č. 461/2003 Z.z. o sociálnom poistení, ktoré sa dotknú oblasti Frontendu:

Ďalšie zmeny sa týkajú úpravy zákona súvisiacich so zmenou ukončenia poskytovaných dávok (najmä tehotenské), oprávnenie na prístup k údajom pre posudkového lekára, ako poskytovaných údajov voči SP a od SP.

4.2 Registratúra

Zapojením kľúčového systému IS REG v prierezovom projekte sa neplánujú meniť kľúčové právne predpisy pre oblasť používania registratúry, v ktorej sa spracovávajú agendy Sociálnej poisťovne, ktorými sú:

• Zákon č. 395/2002 Z. z. o archívoch a registratúrach
  1. Tento zákon stanovuje pravidlá pre evidenciu, uchovávanie, ochranu a vyraďovanie písomností a dokumentov, vrátane registratúrnych záznamov, ktoré sú pre inštitúciu kľúčové.
• Vyhlášky Ministerstva vnútra SR (napr. č. 628/2002 Z. z. a novelizácie, ako vyhláška č. 251/2005 Z. z.)
  1. Tieto predpisy detailne špecifikujú postupy správy registratúry, vrátane evidencie, fyzického a elektronického uchovávania a vyraďovania dokumentov.

4.3 Monitoring služieb a spätná väzba

V súvislosti so zberom dát zo zdrojových systémov SP pre účely monitoringu služieb a spätnej väzby je potrebná legislatívna zmena zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov.

Hlavné legislatívne zmeny zákona č. 95/2019 Z.z. o ITVS, ktoré sa dotknú oblasti monitoringu služieb a spätnej väzby (KAV):

5. ARCHITEKTÚRA RIEŠENIA PROJEKTU

5.1 Stanovenie alternatív architektúry riešenia

5.1.1 Stanovenie alternatív v biznisovej vrstve architektúry

Stanovenie alternatív prebehlo pri práci na Investičnom a Implementačnom pláne ŽS. Biznis riešenie bolo stanovené s ohľadom na výsledky GAP analýzy v Prílohe č. 1- Investičnom pláne a s ohľadom na priorizáciu MMP.

High-level alternatívy:

Alternatíva 1 – Zachovanie súčasného stavu 

Alternatíva 2 – Úprava existujúceho riešenia, ktorá zabezpečí dosiahnutie MMP

Alternatíva 3 – Úprava existujúceho riešenia, ktorá zabezpečí MMP a rozšírené funkcionality

5.1.2 Stanovenie alternatív v aplikačnej vrstve architektúry

Stanovenie alternatív prebehlo čiastočne pri práci na Investičnom a Implementačnom pláne. V niektorých prípadoch sú popísané v kapitole 5 pri spracovaní jednotlivých tém projektu. Nakoľko ide vo veľkej miere o zmenové požiadavky v existujúcich IS, finálne riešenie sa stanoví s poskytovateľom servisnej zmluvy/vendorom v etape Analýza a dizajn.

5.1.3 Stanovenie alternatív v technologickej vrstve architektúry

Nakoľko ide vo veľkej miere o zmenové požiadavky v existujúcich IS, finálne riešenie sa stanoví s poskytovateľom servisnej zmluvy/vendorom v etape Analýza a dizajn.

5.2 Náhľad architektúry a popis budúceho cieľového produktu

Diagram 1: Náhľad celkovej architektúry ŽS v prostredí SP

5.2.1 Frontend

Architektúra riešenia oblasti Frontend je spracovaná v súlade s funkčnými a nefunkčnými požiadavkami, ktoré sú bližšie spracované v prílohe Katalóg požiadaviek, ktorý je tiež súčasťou BC/CBA. Architektúra riešenia Frontendu je ďalej rozpracovaná nižšie v samostatných častiach na úrovni biznis vrstvy, aplikačnej vrstvy, technologickej vrstvy a bezpečnostnej vrstvy.

Frontend Sociálnej poisťovne je rozdelený na verejný portál Sociálnej poisťovne a na Špecializovaný portál Sociálnej poisťovne.

Diagram 2: Náhľad na Frontend životných situácií v prostredí SP

Verejný portál Sociálnej poisťovne slúži ako vstupná brána pre širokú verejnosť. Používateľ má prístup k informáciám o službách SP bez potreby prihlásenia. Portál ponúka prehľadné poskytovanie informácií o dostupných službách, vrátane ich určenia, podmienok ich využitia, požadovaných dokumentov a lehôt na vybavenie a podobne.. Dôležitou funkcionalitou je navigácia na službu, ktorá používateľa vedie v kontexte jeho životnej situácie k správnej službe alebo formuláru.

Na verejnom portáli je možné stiahnuť formuláre vo formáte PDF. Tieto formuláre sú spravidla statické a určené na ručné vyplnenie, tlač a listinné doručenie.

Súčasťou portálu je aj vstupný bod na autentifikáciu používateľa – buď prostredníctvom občianskeho preukazu s čipom (eID), mobilného kľúča alebo iných elektronických identifikátorov podľa platných štandardov.

Špecializovaný portál je určený pre autentifikovaných používateľov ako aj neautentifikovaných používateľov a zahŕňa niekoľko samostatných častí:

• EÚP (Elektronický Účet Poistenca): Umožňuje poistencom (fyzickým osobám) prístup k ich osobným údajom, správu účtu, prístup k službám, možnosti realizovania elektronických podaní  a komunikáciu prostredníctvom elektronickej schránky klienta SP. Používateľ tu nájde informácie o svojich poistných obdobiach, výške odvodov a ďalších údajoch súvisiacich so sociálnym poistením a službami SP.
• EZU (Elektronické služby pre odvádzateľov poistného): Poskytuje služby pre odvádzateľov poistného, ako sú zamestnávatelia a samostatne zárobkovo činné osoby. Umožňuje správu ich povinností voči Sociálnej poisťovni, ako je podávanie mesačných výkazov a kontrola stavu platieb a podobne.

Cieľom oblasti Frontend je vytvorenie tzv. osobnej zóny klienta, čo predstavuje  integrovaný a prierezový kolaboračný systém slúžiaci pre správu a spracovanie vstupných a výstupných dokumentov týkajúcich sa klienta a jeho väzby na sociálne poistenie. Riešenie bude súčasťou podpory procesov sociálneho poistenia tým, že poskytne sumárny pohľad na údaje klienta v rámci rozhodovania a posudzovania a  funkcie na manipulácie s dokumentmi a ich poskytovanie pre ostatné systémy, čím sa zároveň podporí výkon v oblasti sociálneho poistenia.

Predmetom riešenia bude vytvorenie front-end systému, nie vytvorenie back-end prostredia systému.

Pri výkone svojich kompetencií je Sociálna poisťovňa neustále v interakcii so svojimi klientmi -  občanmi a podnikateľmi. V snahe inovovať svoje služby a tým zvyšovať spokojnosť klientov s využívaním týchto služieb, ako aj zvyšovať používanosť a kvalitu elektronických služieb štátu, realizuje SP predkladaný projekt, ktorého cieľom je dosiahnuť nasledovné vlastnosti služieb:

• multikanálový prístup k službám;
• služby v kontexte životných situácií;
• pro-klientsky prístup ku klientom je zabezpečený pro-klientsky orientovanými procesmi, službami a dátami, proaktívne služby;
• užívateľsky prívetivé služby, prehlaď o stave realizácie služby a služba „moje údaje“;
• nástroje pre spätnú väzbu od klientov, hodnotenie kvality služieb.

Projekt bude realizovaný prostredníctvom ucelených tém, podľa ktorých bude spracovaný aj tento dokument, jednotlivých tém sa dotýka aj popis biznis a aplikačnej architektúry.

Tabuľka 9: Témy oblasti Frontend

5.2.1.1 Navigácia na službu

Navigácia na službu SP bude zabezpečená na Verejnom webe SP pre neautentifikovaných ako aj autentifikovaných používateľov. Verejný web SP neposkytuje personalizované informácie.

Web sociálnej poisťovne (www.socpoist.sk) zabezpečí používateľskú navigáciu na elektronické služby.

V rámci realizácie projektu bude realizovaná migrácia (spojená s reimplementáciou vizualizácie pre vypĺňanie) vybraných elektronických  formulárov, ktoré sú v súčasnosti zverejnené na Portáli elektronických formulárov Sociálnej poisťovne.  

Tabuľka 10: Navigácia služieb podľa životnej situácie

5.2.1.2 Poskytnutie informácie o elektronickej službe

Web sociálnej poisťovne (www.socpoist.sk) zabezpečí zobrazenie informácií a návodov o elektronických službách.

V rámci realizácie projektu bude realizovaná migrácia (spojená s reimplementáciou vizualizácie pre vypĺňanie) vybraných elektronických  formulárov, ktoré sú v súčasnosti zverejnené na Portáli elektronických formulárov Sociálnej poisťovne. 

Tabuľka 11: Poskytnutie informácií o elektronickej službe podľa životnej situácie

5.2.1.3 Register ŽS/služieb

V rámci špecializovaného portálu bude vytvorený register ŽS/služieb. Tento komponent zabezpečuje centrálne uchovávanie a najmä poskytovanie údajov a metaúdajov iným informačným systémom. Register bude evidovať informácie:

• metaúdaje o životných situáciách a ich krokoch, ktoré súvisia so službami SP
• informácie o elektronických službách SP a ich priradenie na kroky ŽS
• informácie o požadovanej autentifikácii používateľa
• informácie o elektronickej službe (prílohy, spôsob podania)

Register služieb zabezpečí možnosť definovať ku každej službe SP ďalšie súvisiace služby. Tieto vzťahy budú využité pre realizáciu základnej proaktivity v module Moje služby/ŽS, kedy systém navrhne klientovi k prebiehajúcej, alebo ukončenej službe ďalšie súvisiace služby. Register poskytne tieto vzťahy prostredníctvom REST služby s parametrom identifikátora/rov služby/služieb.

Register služieb bude evidovať aj atribúty, ktoré sú využiteľné pre účely proaktívneho ponúkania služieb SP klientom SP. Ide o

• mapovanie súvisiacich služieb SP na službu – t.j. pre účely ponuky súvisiacich služieb SP pre napr. práve prebiehajúcu, alebo ukončenú službu
• mapovanie súvisiacich služieb na údaj – t.j. pre účely ponuky súvisiacich služieb SP s údajom, ktorý sa eviduje v EÚP o klientovi.
• mapovanie súvisiacich služieb na udalosť – t.j. pre účely ponuky súvisiacich služieb SP s udalosťou, ktorá sa eviduje v EÚP v súvislosti s klientom.

5.2.1.4 Register e-formulárov

V rámci špecializovaného portálu (esluzby.socpoist.sk) sa budú evidovať vzory e-formulárov, ktoré sú použité pre účely realizácie elektronického podania. Vzory e-formulárov ako aj službu pre ich aktualizáciu poskytne komponent Registratúra prostredníctvom dedikovanej služby. Alternatívne (ak nebude služba Registratúry k dispozícii) bude možné zoznam vzorov v evidencii špecializovaného portálu aktualizovať manuálne zásahom administrátora.

Tabuľka 12: Zoznam elektronických služieb, ku ktorým budú zobrazené informácie a návody na webe SP (www.socpoist.sk)

Zároveň budú tie formuláre, ktoré sú už v súčasnosti elektronické a vypublikované na podstránke stránke SP presunuté k novovytvoreným elektronickým formulárom, tak aby všetky formuláre SP našiel občan na jednom mieste. Aj tieto formuláre budú redizajnované v súlade s IDSK3.0 a jednotným návrhom grafiky, UX celého nového portálu. Občan bude mať unifikovanú skúsenosť naprieč rôznymi súčasťami portálu SP. Tým, že budú všetky formuláre SP na jednom mieste, zabezpečí sa zníženie komplexity architektúry s dopadom na zvýšenie spoľahlivosti, flexibility informačných systémov SP a zníženie nákladov na implementáciu zmien a prevádzku riešenia. 

Tabuľka 13: Zoznam aktuálnych e-formulárov, ktoré budú premiestnené k novo-vytvoreným e-formulárom

5.2.1.5 Konštruktor podania

V rámci špecializovaného portálu bude vytvorený Konštruktor podania - modul pre vytvorenie elektronického podania súvisiaceho so službami SP. Konštruktor podania zabezpečí používateľovi možnosť vyplnenia hlavného formulára podania, prípadne štruktúrovaných príloh, priloženie príloh k podaniu, autorizácie dokumentov, finálny náhľad na dokumenty tvoriace podanie a odoslania podania do schránky SP, do AIS SP alebo registratúry. Informácie o spôsobe autentifikácie, autorizácie podania, zoznamu príloh a cieľového systému do ktorého sa bude podanie zasielať budú čerpané z registra ŽS/Služieb a registra formulárov.

Po odoslaní podania sa používateľovi zobrazí modul Spätná väzba pre možnosť zanechania spätnej väzby ku kvalite poskytovanej služby (viac v oblasti Monitoring služieb).

Časť funkcionality konštruktora podania – vyplnenie elektronického formulára a jeho tlač - bude dostupná aj neautentifikovaným  používateľom.

5.2.1.6 Modul pre komunikáciu s klientom

V rámci EÚP bude vytvorený modul pre komunikáciu s klientom. Bude slúžiť na:

• evidenciu odoslaných správ klientom SP do el. schránky SP,
• evidenciu prijatých správ od SP
• evidenciu rozpracovaných správ

Evidované správy sú v podobe elektronických podaní, elektronických výstupov alebo notifikácií.

Vykonáva aj hromadné (dávkové) doručovanie notifikácií. V prípade, že súčasťou dávky je identita prijímateľa, ktorý nemá aktívnu komunikačnú schránku SP (účet v EÚP), je táto identita ignorovaná a k doručeniu notifikácie nedôjde.

Komunikačná schránka klienta SP je komponent, ktorý je určený pre autorizovaného klienta SP. Hlavným poslaním je evidovať a klientovi SP zobrazovať všetku komunikáciu, ktorá prebehla medzi nim a Sociálnou poisťovňou. Komunikácia prebieha prostredníctvom správ rôznych typov. Najčastejšie ide o elektronickú žiadosť, rozhodnutie a notifikáciu. Komunikácia z pohľadu klienta SP je rozdelená na prišlú a odošlú. Sú evidované atribúty ako je čas prijatia, čas odoslania, druh správy,  subjekt správy a telo správy. V prípade, že súčasťou komunikácie (správy) je elektronický dokument,  správa obsahuje URL linku na modul Moje dokumenty, kde si klient uvedený dokument zobrazí, prípadne vytlačí, alebo stiahne na lokálny disk, či iné médium.

Komunikačná schránka klienta SP je v podstate značne zjednodušený ekvivalent elektronickej schránky modulu ÚPVS eDesk bez funkcionality doručovania (úradného doručovania so všetkými náležitosťami ako je doručovanie do vlastných rúk, fikcie doručenia a pod.). Znamená to, že úradné rozhodnutia budú klientom SP aj naďalej doručované do elektronickej schránky ÚPVS avšak po ich doručení budú zobrazované aj v Komunikačnej schránke klienta.

Na rozdiel od modulu ÚPVS eDesk bude Komunikačná schránka klienta SP ponúkať:

• zobrazenie komunikácie len so Sociálnou poisťovňou,
• zjednodušené a intuitívnejšie používateľské rozhranie a
• bude integrované do jednotného používateľského prostredia spolu s modulmi Moje dáta, Môj účet, Moje dokumenty, čím klient získa benefit ponuky všetkých potrebných služieb a informácií na jednom mieste (tzv. one stop shop).

5.2.1.7 Zobrazenie údajov v EÚP/EKP (Moje údaje/Môj účet)

EÚP zobrazí štruktúrované údaje autentifikovanému klientovi SP.

Modul Moje údaje bude zobrazovať základné údaje o prihlásenom klientovi SP do EÚP, ktoré SP eviduje. Klient bude mať možnosť údaje upravovať, alebo nahlasovať ich chybnosť.

Medzi základné zobrazované údaje patrí:

• Identifikačné údaje klienta
  • meno, priezvisko, rč, dátum narodenia, adresa
• Kontaktné údaje klienta
  • doručovacia adresa
  • e-mail
  • telefónne číslo
• Preferovaný spôsob komunikácie

Modul môj účet zabezpečuje hlavnú funkcionalitu EÚP v zmysle Zákon č. 461/2003 Z. z. o sociálnom poistení (hlavný zákon) – zobrazenie relevantných informácií poistencovi, ktoré súvisia s jeho:

• platbami poistného,
• obdobiami dôchodkového poistenia, nemocenského, poistenia v nezamestnanosti atď.,
• vymeriavacími základmi,
• obdobiami dôchodkového poistenia v II. pilieri (ak je relevantné)

5.2.1.8 Personalizovaná kalkulačka pre predbežný výpočet DvN

Existujúci komponent Personalizovaná kalkulačka pre výpočet DvN bude zaintegrovaná do nového redizajnovaného používateľského rozhrania EÚP. Sociálna poisťovňa klientovi poskytne na výpočet predbežnej výšky dávky v nezamestnanosti personalizovanú kalkulačku. Tento výpočet bude vychádzať z aktuálnych údajov, ktoré má Sociálna poisťovňa k dispozícii. Prístup občana k personalizovanej kalkulačke zabezpečí EKP.

5.2.1.9 Grafický redizajn verejného webu SP (www.socpoist.sk)

V prípade grafického redizajnu verejného webu SP ide o súbor aktivít, ktoré vedú k naplneniu požiadaviek definovanými jednotlivými implementačnými plánmi a legislatívnymi štandardmi SR. Hlavné aktivity redizajnu sú:

• Analýza súčasného stavu štruktúry a obsahu v súvislosti so životnými situáciami SP
• Návrh novej štruktúry portálu pričom štruktúra súvisí aj s navigáciou na službu  (viď kapitola 8)
• Návrh nového dizajnu portálu v kontexte ID-SK 3.0
• Príprava obsahu pričom obsah súvisí aj s poskytovaním informácií o službe (viď kapitola 9)
• Implementácia zmeny, testovanie a nasadenie

Verejný portál SP (www.socpoist.sk) bude redizajnovaný v zmysle štandardu ID-SK 3.0, redizajn verejného portálu bude pre všetky BP všetkých životných situácií resp. všetky formuláre nakoľko sa jedná o komponent, pri ktorom nie je možné odčlenenie funkčností pre každú životnú situáciu separátne.

Tabuľka 14: Zoznam BP pre redizajn verejného webu SP podľa životnej situácie

5.2.1.10 Grafický redizajn špecializovaného portálu SP (www.eslužby.socpoist.sk)

Špecializovaný portál SP (www.eslužby.socpoist.sk) vrátane časti EÚP, SES (EZU) bude redizajnovaný v zmysle štandardu ID-SK 3.0.

Grafický redizajn EÚP zahŕňa úplnú zmenu štruktúry, navigácie a dizajnu. Budú implementované nové aplikačné moduly (moje údaje, moje ŽS/služby, správy a pod.), ktoré budú musieť byť integrované do jednotného prostredia portálu. Dizajn bude realizovaný v súlade s ID-SKO 3.0.

Grafický redizajn portálu EZU je postavený na:

• zmene dizajnu v súlade s ID-SK 3.0
• zmene dizajnu ohľadom zosúladenia portálu s ostatnými portálmi SP. Hlavným cieľom tejto zmeny je eliminovať používateľské rozdiely medzi Verejným portálom SP, EÚP a EZU. Vzhľadom na komplexnosť webu a elektronických formulárov EZU sa v tejto fáze predpokladá len základné, resp. principiálne zosúladenie

Redizajn verejného portálu bude pre všetky BP všetkých životných situácií resp. všetky formuláre nakoľko sa jedná o komponent, pri ktorom nie je možné odčlenenie funkčností pre každú životnú situáciu separátne.

Tabuľka 15: Zoznam BP pre redizajn špecializovaného portálu SP podľa životnej situácie

5.2.1.11 Elektronické formuláre a ich predvypĺňanie

V rámci projektu životných situácií budú implementované, alebo prerobené elektronické formuláre. Formuláre, ktoré budú doručované prostredníctvom elektronickej schránky SP budú registrované v spoločnom module ÚPVS MEF. Zoznam formulárov pre jednotlivé ŽS sú uvedené v Prílohe „Register elektronických formulárov ŽS.xlsx“.

V rámci tejto úlohy bude realizovaná migrácia (spojená s reimplementáciou vizualizácie pre vypĺňanie) elektronických  formulárov, ktoré sú v súčasnosti zverejnené na Portáli elektronických formulárov Sociálnej poisťovne. Tieto formuláre budú vyplniteľné na špecializovanom portáli SP modulom Konštruktor podania. Rovnako sú pre úplnosť zahrnuté v Prílohe 4.  

Súčasťou dodávaného informačného systému bude grafický interface na editáciu, customizáciu formulárov, aby mali priamo zamestnanci SP možnosť editovať a robiť menšie zmeny vo formulároch, bez potreby zmenových požiadaviek na dodávateľa.

Modul konštruktor podaní bude realizovať funkcionalitu predvyplnenia elektronických formulárov údajmi poskytnutými do EKP/EÚP. Príloha 4 obsahuje informáciu (stĺpec „J“), ktorá odkazuje pre každý formulár na samostatný súbor s definíciou atribútov a ich predvypĺňaním.

Na špecializovanom portáli bude dostupná funkcionalita pre používateľov služieb pre vyplnenie elektronického formulára. Táto funkcionalita je dostupná vo viacerých formách.

Poskytnutie elektronického formulára prostredníctvom súboru PDF

V tomto prípade bude elektronický formulár poskytnutý používateľovi služieb SP na stiahnutie vo formáte PDF. Tento formulár so používateľ vytlačí/prípadne vyplní prostrdeníctvom vlastných softvérových prostriedkov (napr. Adobe Acrobat reader), vytlačí a doručí na pobočku SP listinne. Táto služba je určená pre neautentifikovaných ako aj autentifikovaných používateľov a bude poskytnutá na Špecializovanom portáli SP.

Poskytnutie elektronického formulára prostredníctvom modulu Form filler

Táto služba je určená pre neautentifikovaných ako aj autentifikovaných používateľov. Elektronické formuláre SP, ktoré sú registrované v centrálnom module elektronických formulárov (ÚPVS MEF) budú dostupné pre používateľom služieb SP prostredníctvom modulu Form filler. V tomto prípade bude používateľovi služieb SP poskytnutá komfortná forma vyplnenia formuláru s možnosťou automatických kontrol. V prípade autentifikovaného používateľa bude aktívna funkcionalita predvypĺňania formulára údajmi z agendových systémov SP.

Táto funkcionalita bude poskytovaná pri dvoch scenároch:

1. Používateľ služieb SP chce využiť komfortné vyplnenie formulára a však doručovať podanie bude v listinnej forme.
2. Používateľ služieb SP chce využiť komfortné vyplnenie formulára a chce podanie odoslať elektronicky. V tomto prípade bude používateľ po vyplnení formulára presmerovaný do modulu Konštruktora podania, kde elektronické podanie zostaví, autorizuje a odošle.

5.2.1.12 Formulár Odvolanie a Obnova konania

Občan má možnosť voči rozhodnutiu podať odvolanie elektronicky. Pre tento účel bude implementovaný jednotný formulár, ktorý bude platiť pre všetky ŽS.

Odvolanie je špeciálny prípad elektronickej služby, ktorá je dostupná aj z komunikačnej schránky klienta.

V Komunikačnej schránke klienta sa pri položke v doručených správach zobrazí používateľovi tlačidlo „Odvolať“, čo otvorí pred vyplnený formulár na odvolanie v konštruktore podania. Následne používateľ podanie odvolania odošle do elektronickej schránky SP. Ďalej je podanie odvolania spracovávané štandardnou cestou v registratúre a v agendovom informačnom systéme, ktorý vytvorí odpoveď a registratúra ho doručí.

Komplementárnou funkciou k možnosti podania odvolania bude aj služba späťvzatie odvolania. Služba bude mať štandardnú navigáciu na webe socpoist.sk vrátane poskytnutia informácií o službe a zároveň bude dostupná aj v prostredí Komunikačnej schránky klienta.

Späť vzatie odvolania je vizuálne asociovaná v komunikačnej schránke pri odoslaných podaniach odvolania prostredníctvom tlačidla „Späťvziať odvolanie“. Otvorí predvyplnený formulár na späť vzatie odvolania v konštruktore podania. Následne používateľ podanie odvolania odošle do elektronickej schránky SP. Ďalej je podanie odvolania spracovávané štandardnou cestou v registratúre a v agendovom informačnom systéme, ktorý vytvorí odpoveď a registratúra ho doručí.

Tabuľka 16: Zoznam BP, ktorých sa týka téma Odvolanie podľa životnej situácie

5.2.1.13 Modul moje služby/ŽS

V rámci špecializovaného portálu SP bude realizovaný modul Moje služby/ Moje ŽS.

Tento modul zabezpečuje pre autentifikovaného používateľa nasledovné funkcie:

• Poskytovanie informácií o práve prebiehajúcich (alebo ukončených)  konaniach a životných situáciách – systém poskytne informáciu o prebiehajúcom, alebo ukončenom konaní za nastaviteľné časové obdobie s atribútmi:
  • Názov konania (názov elektronického formuláru)
  • Začiatok konania
  • Koniec konania
  • Stav konania

Uvedené procesné informácie budú poskytované z modulu BPM prostredníctvom REST služby, pričom vstupom bude identifikátor klienta (FO) a časové obdobie.

• Poskytovanie návrhu služieb súvisiacich s prebiehajúcimi a ukončenými konaniami – táto informácia bude poskytovaná z registra služieb.

5.2.1.14 Autentifikácia a autorizácia klienta SP  

Autentifikácia používateľov služieb SP bude realizovaná prostredníctvom:

• Mena a hesla (nízka úroveň bezpečnosti)
• Využitím ÚPVS IAM SSO (pokročilá úroveň, alebo vysoká úroveň)

Systém umožní autentifikáciu používateľov z internetu (klientov SP) prostredníctvom:

• eID karty Slovenskej republiky (zabezpečuje ÚPVS Web SSO)
• mobilnej aplikácie Slovensko v mobile (zabezpečuje ÚPVS Web SSO)
• iným prihlasovacím prostriedkom, ktorý je akceptovaný EIDAS uzlom pre zahraničných používateľov (zabezpečuje ÚPVS Web SSO)
• mena a hesla (zabezpečuje špecializovaný portál SP)

Je potrebné zabezpečiť Single sign-on pre prístup k službám SP čo znamená že identita autentifikovanej osoby sa bude prenášať medzi jednotlivými portálmi SP. V prípade, že používateľ služieb SP je autentifikovaný nízkou úrovňou bezpečnosti pričom služba, ktorú chce využiť vyžaduje pokročilú, alebo vysokú úroveň bezpečnosti tak je vyzvaný na autentifikáciu prostredníctvom ÚPVS IAM SSO.

Je potrebné implementovať mechanizmus stotožnenia prihlásenej osoby prostredníctvom ÚPVS IAM SSO s existujúcimi identitami klientov SP, ktoré sú evidované v IAM SP.

Autorizácia používateľov služieb SP je vyžadovaná pri realizácií elektronických formulárov, kedy sa elektronicky podpisujú jednotlivé elektronické dokumenty podania (formulár a podľa potreby prílohy), prikladajú sa časové pečiatky a vytvára sa podpisový kontajner (ASiC-E). Autorizácia dokumentov je realizovaná v rámci modulu Konštruktor podania. V rámci modulu Register služieb SP bude evidovaná a poskytovaná informácia o požadovanom stupni autorizácie elektronického podania pre každú službu SP. Znamená to, že konkrétne služby SP

• nemusia požadovať autorizáciu podania
• budú požadovať autorizáciu podania na úrovni pokročilá
• budú požadovať autorizáciu podania na úrovni vysoká.

Automatické zriadenie prístupu občana na portál elektronických služieb použitím eID karty

Systém zabezpečí automatické vytvorenie prístupu pre autentifikovaných používateľov prostredníctvom eID do modulov (EÚP)

• Moje údaje / môj účet
• Moje ŽS/služby
• Komunikačná schránka klienta

5.2.1.15 GUI pre službu Spätná väzba a integrácia na modul Odozva.sk 

V rámci špecializovaného portálu je potrebné vytvoriť samostatný frontendový komponent, ktorý je prístupná autentifikovaným, ako aj neautentifikovaným používateľom za účelom zberu spätnej väzby ku kvalite služieb SP.

Získané údaje prostredníctvom zverejneného frontendového komponentu  musia byť ďalej poskytnuté systému Odozva.sk.

5.2.1.16 Rezervačný systém a zobrazenie kalendára s voľnými a rezervovanými termínmi osobnej návštevy a online zabezpečenej komunikácie

SP zabezpečí nový rezervačný systém. Súčasný rezervačný systém sa využíva len na agendu dôchodkovej agendy, cieľový stav umožní využívanie rezervačného systému aj na ďalšie agendy a poskytované služby na pobočkách SP. Služba bude dostupná na webovom sídle a ŠP SP pre každého občana. Systém bude intuitívny pre klientov ako aj zamestnancov SP. Nové riešenie má spĺňať legislatívne požiadavky, má byť umožnený jeho jednoduchý rozvoj a upgrade.

Rezervačný systém Sociálnej poisťovne umožňuje rezervovať termín na osobnú návštevu alebo online stretnutie prostredníctvom webového sídla (pre neautentifikovaných používateľov) alebo špecializovaného portálu (pre autentifikovaných používateľov). Pri rezervácii si používateľ vyberá agendu, pobočku a termín, pričom systém vyžaduje overenie kontaktu cez SMS alebo email. Súčasťou procesu je potvrdenie spracúvania osobných údajov. Rezerváciu môže realizovať aj zamestnanec SP cez samostatné rozhranie, pričom klient musí potvrdiť termín. Systém umožňuje overenie a zrušenie rezervácie, pripomienky pred termínom, správu rezervácií a štatistiky. Je integrovaný na vyvolávací systém, web, portál aj zabezpečenú online komunikáciu a zabezpečuje synchronizáciu údajov na pobočkách.

5.2.1.17 Vytvorenie služby zabezpečenej komunikácie

SP v súčasnosti neposkytuje možnosť komunikovať s klientom prostredníctvom on-line nástrojov (zabezpečenou formou). Pri príprave na vyplnenie žiadosti o dôchodok je však potrebná častejšia komunikácia so zamestnancami SP za účelom prípadného dovysvetlenia a predovšetkým kompletizácie podkladov a dokumentov potrebných k predloženiu žiadosti o dôchodok alebo jej doplneniu.

Nová služba zabezpečenej komunikácie rozširuje kanály komunikácie s klientami SP, najmä žiadateľmi o dôchodok, ktorí pri príprave podkladov a podaní samotnej ŽoD pravidelne komunikujú s pracovníkmi SP.

Služby týkajúce sa rezervácie online schôdze budú dostupné na webovom sídle a špecializovanom portáli pre každého občana. Termín bude môcť rezervovať aj zamestnanec SP prostredníctvom samostatného GUI. Okrem rezervácie termínu bude umožnené vidieť potvrdený termín, zrušiť rezerváciu, priradiť iného zamestnanca k termínu.

Samotná online komunikácia bude prebiehať prostredníctvom webového prehliadača (riešenie zabezpečí vytvorenie schôdze – ID schôdze). Overený klient bude mať k dispozícií audio a video, prípadne textovú komunikáciu prostredníctvom služby na portáli SP.

Systém poskytne aj údaje o využívanie systému.

Výstupom bude funkčná a prevádzkovaná služba zabezpečenej komunikácie so všetkými implementovanými požiadavkami na systém. Systém bude dodaný a prevádzkovaný v tzv. režime „softvare-as-a-service“ a umožní komunikáciu z prostredia zamestnanca SP s klientom (využíva akýkoľvek webový prehliadač). 

Služba bude integrovaná s Rezervačným systémom.

5.2.1.18 Mobilná aplikácia  

V rámci implementácie POO bude zároveň modernizovaná mobilná aplikácia pre klientov SP - Odvádzateľov poistného, ktorá zjednodušuje a modernizuje správu služieb poistenca. Základné funkčné celky aplikácie tvorí predovšetkým registrácia, nástroje na výpočet výšky poistného pre SZČO a PUSH notifikácie pre aktuálne informovanie používateľov. Kľúčovým prvkom je aj intuitívna domovská stránka (obrazovka), ktorá slúži ako vstupná brána do aplikácie, podporená efektívnym onboarding procesom a dynamickým prepínačom služieb, čím sa zabezpečuje prispôsobenie obsahu individuálnym potrebám každého používateľa.

Mobilná aplikácia bude tiež umožňovať predbežnú registráciu, ktorá slúži Zamestnávateľovi na registrovanie firmy a zamestnancov do IS Sociálnej poisťovne. Novou funkcionalitou bude tiež sekcia nedoplatky, ktorá umožní používateľovi prehľad celkovej výšky nedoplatkov ako aj rozpad jednotlivých neuhradených platieb, z ktorých sa nedoplatok skladá. Aplikácia umožní tieto nedoplatky uhradiť

Mobilná aplikácia bude zároveň spĺňať všetky bezpečnostné štandardy, s cieľom zabezpečiť dôvernosť, integritu a dostupnosť údajov v každej vrstve systému, a zároveň garantovať, že aplikácia bude zrozumiteľná, použiteľná a dôveryhodná pre všetkých občanov. 

5.2.1.19 Modul platobný profil EUP  

Poistenec bude môcť prostredníctvom svojho používateľského rozhrania v EKP upraviť údaje o spôsobe výplaty dávky.

V rámci rozšírenia IS EKP bude vykonané nasledovné:

• Zrušenie možnosti evidovania spôsobu výplaty dávok pre ePN
• Bude vytvorená spoločná šablóna obrazovky pre správu spôsobu výplaty dávok pre dávky nemocenského poistenia a úrazový príplatok
• Do sekcie Nemocenské poistenia portálu EUP bude pridaná položka pre správu platobného profilu pre vyplácania dávok nemocenského poistenia s možnosťou jeho úpravy pomocou spoločnej šablóny obrazovky pre správy spôsobu výplaty dávok. Zmeny vykonané v rámci správy platobného profilu budú vykonané pre všetky aktuálne bežiace dávky nemocenského poistenia (implementačne riešené v rámci CR pre RLFO2)
• Na detaile existujúcej nemocenskej dávky bude možnosť úpravy spôsobu vyplácania dávky presmerovaním na možnosť správy platobného profilu pre nemocenské dávky
• Na detaile existujúcej úrazovej dávky typu Úrazový príplatok bude možnosť úpravy spôsobu vyplácania dávky. Výberom danej možnosti sa zobrazí spoločná šablóna obrazovky pre správy spôsobu výplaty dávok na ktorej bude možné upraviť spôsob výplaty daného úrazového príplatku.
• V rámci IS EKP budú vystavené nové rozhranie pre IS NPaLPČ a IS DAUP pre možnosť preberania informácií o zmene spôsobu vyplácania dávok. IS NPaLPČ a IS DAUP si bude rozhraním priebežne preberať správy s údajmi prijatými od poistenca z IS EKP

V rámci editácie spôsobu vyplácania dávok bude možné meniť nasledovné atribúty:

• Spôsob výplatu dávky – na účet / na adresu
• Na účet

• IBAN
• SWIFT – pre zahraničné účty

• Na adresu V SR a ČR

•  Ulica
•  Súpisné číslo
•  Orientačné číslo
•  PSČ
•  Obec
•  Štát SR alebo ČR

V EUP si občan bude môcť elektronicky nahlásiť zmenu bankového účtu vo svojom profile pre nemocenské aj úrazové dávky. Daná možnosť v portáli SP vyplynula z proaktívnosti vyplácania dávok a zmeny v zákone, ktorá je identifikovaná vyššie v časti leg. zmeny, kedy zamestnávateľ musí nahlásiť bankový účet zamestnanca do SP. Ak občan chce nahlásiť zmenu bankového účtu sám, vykoná zmenu elektronicky v EÚP, čim sa časovo aj administratívne odbremenení nielen občan aj zamestnávateľ. Zmena sa bude týkať aj nahlasovania bankového účtu v ePN. Nahlásený bankový účet bude môcť SP využiť aj pre iné agendy či služby ŽS, čim sa zabezpečí jednotnosť údajov, eliminácia duplicít, vyššia dátová kvalita, úspora času pri spracovaní, jednoduchšia integrácia, zníženie chybovosti, efektívnejšia správa údajov, lepšia interoperabilita medzi systémami či zníženie prevádzkových nákladov.

5.2.2 Dátové integrácie

V rámci dátových integrácií sa bude realizovať osem oblastí integrácií, ako v rámci interných systémov SP, tak i integrácií na tretie strany (najmä CSRÚ, MPSVaR a NCZI).

Dátové integrácie sú realizované nasledovne:

1. Potrebná úprava IS pre umožnenie integrácie a dátových synchronizácií je súčasťou projektov jednotlivých životných situácií
2. Samotné vybudovanie integračných rozhraní a nastavenie dátových tokov je súčasťou tohto predkladaného projektu.

Obrázok 3 Prehľad integrácií a integrovaných IS

5.2.2.1 DI-2 (pre ŽS1)

Téma dátových integrácií pre ŽS1 spočíva v internej výmene údajov potrebných pre zjednodušenie procesov žiadosti o zaradenie do evidencie uchádzačov o zamestnanie a žiadosti o dávku v nezamestnanosti, vrátane jej automatického zúčtovania. Oblasť sa realizuje v koordinácii s úpravou formulárou a umožnením ich predvyplnenia (DI-7).

Cieľom realizácie témy je:

• Nahradiť existujúci technicky nevyhovujúci dátový prenos koncepčným riešením s použitím funkcionality dátovej integrácie (DI) prostredníctvom MÚSP v súlade s architektúrou 2.0 IS SP
• Rozšíriť balík údajov poskytovaných pre MPSVaR podľa špecifikácie 
• Dostať pod správu Dátovej Základne (DZ) všetky datasety v rámci týchto prenosov, ktoré budú uložené v CDÚ MÚSP a poskytované z neho prostredníctvom nástrojov MÚSP, aby sa tak zachoval interný know-how v SP
• Vytvoriť funkčný scenár kompletnej integrácie tak, aby bol bez problémov rozšíriteľný a použiteľný pre súčasné potreby IS SP a zároveň pre ŽS1 a zároveň replikovane použiteľný pre akékoľvek ďalšie potreby integrácie v rámci architektúry IS SP

Spôsob realizácie týchto dátových integrácií je nastavený na využitie IS MÚSP, ktorý plní rolu dátovej platformy SP (MDM) - t.j. nevyužívajú sa priame integrácie IS.

DI-2 rieši:

1. Získanie údajov z CSRÚ (CSRÚ → MÚSP- MDM)
2. Publikovanie údajov do CSRÚ (MÚSP – MDM → CSRÚ)
3. Interná integrácia - publikovanie údajov do MÚSP - MDM (IS SP → MÚSP- MDM)

Interná integrácia - Získanie údaju SP  - BATCH (MÚSP- MDM → IS SP)

5.2.2.2 DI-4 (pre ŽS5)

Cieľom témy je:

• Nahradiť existujúci technicky nevyhovujúci dátový prenos koncepčným riešením s použitím funkcionality dátovej integrácie (DI) prostredníctvom MÚSP v súlade s architektúrou 2.0 IS SP.
• Rozšíriť balík údajov poskytovaných pre MPSVaR podľa špecifikácie.
• Dostať pod správu Dátovej Základne (DZ) všetky datasety v rámci týchto prenosov, ktoré budú uložené v CDÚ MÚSP a poskytované z neho prostredníctvom nástrojov MÚSP aby sa tak zachoval interný know-how v SP.
• Dosiahnuť dennú periodicitu prenosov tak, aby všetky dotknuté dáta boli dostupné a spracované počas 24 hodín end-to end.
• Vytvoriť funkčný scenár kompletnej integrácie tak, aby bol bez problémov rozšíriteľný a použiteľný pre súčasné potreby IS SP a zároveň pre ŽS5 POO a zároveň replikovane použiteľný pre akékoľvek ďalšie potreby integrácie v rámci architektúry IS SP.

DI-4 rieši:

1. Interná integrácia - publikovanie údajov do MÚSP/MDM (IS SP → IS MÚSP/MDM) 
2. Interná integrácia - Získanie údaju SP  - BATCH (MÚSP/MDM → IS SP) 

5.2.2.3 DI-5 (pre ŽS7 a ŽS8)

Cieľom témy je:

• Nahradiť existujúci technicky nevyhovujúci dátový prenos koncepčným riešením s použitím funkcionality dátovej integrácie (DI) prostredníctvom MÚSP v súlade s architektúrou 2.0 IS SP 
• Rozšíriť balík údajov poskytovaných pre MPSVaR podľa špecifikácie  
• Dostať pod správu Dátovej Základne (DZ) všetky datasety v rámci týchto prenosov, ktoré budú uložené v CDÚ MÚSP a poskytované z neho prostredníctvom nástrojov MÚSP aby sa tak zachoval interný know-how v SP 
• Vytvoriť funkčný scenár kompletnej integrácie tak, aby bol bez problémov rozšíriteľný a použiteľný pre súčasné potreby IS SP a zároveň pre ŽS7, ŽS8 POO a zároveň replikovane použiteľný pre akékoľvek ďalšie potreby integrácie v rámci architektúry IS SP 

DI-5 rieši:

1. Získanie údajov z CSRÚ (CSRÚ → IS MÚSP/MDM) 
2. Publikovanie údajov do CSRÚ (IS MÚSP/MDM → CSRÚ) 
3. Interná integrácia - publikovanie údajov do MDM (IS SP → IS MÚSP/MDM) 
4. Interná integrácia - Získanie údaju SP  - BATCH (IS MÚSP/MDM → IS SP) 

5.2.2.4 DI-6 (pre ŽS14)

Cieľom témy je:

1. Nahradiť aktuálnu dátovú integráciu medzi SP a ÚPSVaR spôsobom systém-systém prostredníctvom integrácie MUSP s IS CSRÚ; 

1. Doplniť dátovú výmenu medzi SP a ÚPSVaR prostredníctvom integrácie MUSP s IS CSRÚ o ďalšie relevantné údaje na základe detailnej analýzy; 

1. Dostať pod správu Dátovej Základne (DZ) všetky datasety v rámci prenosov ISVS_01; ktoré budú uložené v CDU MUSP a poskytované z neho prostredníctvom nástrojov MÚSP, aby sa tak zachoval interný know-how v SP.

DI-6 rieši:

• Získanie údajov z CSRÚ (CSRÚ -> MDM) 

• Publikovanie údajov do CSRÚ (MDM -> CSRÚ) 

• Interná integrácia - publikovanie údajov do MDM (IS SP -> MDM) 

• Interná integrácia - Získanie údaju SP  - BATCH (MDM -> IS SP) 

5.2.2.5 DI-7 (pre všetky ŽS)

Cieľom témy je:

1. Implementovať predvýplňanie formulárov pri komunikácii medzi klientom (poistenci, odvodové subjekty a inéi) a Sociálnou poisťovňou prostredníctvom komunikačného portálu.s využitím IS MÚSP
2. Skonsolidovať identifikované údaje tak, aby bolo možné implementovať predvýpĺňanie údajov
3. Umožniť zasielanie komunikácie s predvyplnenými formulármi prostredníctvom Registratúry SP a jej prepojeniami so systémami ÚPVS

DI-7 rieši:

• Modul eForm Filler (samotné predvypĺňanie formulárov dostupnými údajmi)
• prepojenie systému vypĺňania formulárov na Registratúru SP a jej prepojenia so systémami UPVS.

5.2.2.6 DI-8 (integrácia s NCZI pre potreby ŽS8)

Cieľom témy je:

1. Implementovať priamu integráciu s NCZI pre potreby spracovania agendy OČR (ošetrovné dlhodobé z dôvodu ošetrovania člena rodiny, ošetrovné krátkosobé z dôvodu uzatvorenia zariadenia, ošetrovné krátkododbé z dôvodu ošetrovania člena rodiny)

DI-8 rieši:

• Dátový model eOČR
• Register potrieb starostlivosti
• Integračné rozhrania

5.2.3 Notifikácie

Centrálny notifikačný modul SP bude slúžiť najmä pre notifikáciu o zmene stavu procesov volaný BPM komponentom a bude umožňovať zasielanie najmä nasledovných typov notifikácii:

• Email
• SMS
• PUSH notifikácia

Email notifikácie by mali byť zasielané používateľom na základe kombinácie nastavení v administračnej zóne a používateľského profilu prípadne z nastavení požiadavky. Pre zaslanie emailovej notifikácie je potrebné mať vyplnenú adresu v požiadavke pre notifikáciu.

SMS notifikácie by mali byť zasielané používateľom na základe kombinácie nastavení v administračnej zóne a používateľského profilu prípadne z nastavení požiadavky. Pre zaslanie SMS notifikácie je potrebné mať vyplnené telefónne číslo v požiadavke pre notifikáciu.

PUSH notifikácie by mali byť zasielané používateľom na základe kombinácie nastavení v administračnej zóne a používateľského profilu. Pre zaslanie PUSH notifikácie je nutný predpoklad mať nainštalovanú a aktivovanú mobilnú aplikáciu SP.

Modul by mal umožňovať definíciu textov pre jednotlivé typy notifikácií (SMS, Email, PUSH) a tiež definíciu textov pre jednotlivé druhy notifikácií (vytvorenie, zaevidovanie,...). Tieto texty budú viazané pre jednotlivé registrované služby.

Pre jednoduchšie nastavenie bude modul obsahovať základné texty pre jednotlivé typy a druhy notifikácii. Čo znamená, že pri zaregistrovaní novej služby a povolení zasielania typov notifikácii sa automaticky pred vyplní text pre jednotlivý typ a druh. Modul by mal umožňovať aj zaslanie špecifického textu, ktorý nie je definovaný v administrácii a je priamo zaslaný v požiadavke.

5.2.4 Registratúra

Vzhľadom na súčasný stav registratúrneho systému SP a jeho využitie je potrebné jeho rozšírenie o definované druhy elektronických formulárov, ktoré sú predmetom implementácie ŽS. Analýzou vstupných požiadaviek na Frontend vznikol návrh procesu pre prijatie a odoslanie správy pomocou všetkých foriem autentifikácie subjektov. Frontend umožní subjektu výber elektronickej služby, vyplnenie a odoslanie elektronického formuláru do elektronickej schránky (eDesk) ÚPVS. Dotknuté agendové systémy je potrebné rozšíriť o funkcionalitu spracovania žiadostí klientov. Služby na získavanie prijatých žiadostí a zasielanie odpovedí, či už vo forme vystavených formulárov alebo iných dokumentov, bude vystavovať registratúrny systém. Tieto služby budú slúžiť agendovým systémom na zabezpečenie elektronickej komunikácie s klientom. Bližšie je proces prijatia a odoslania správy popísaný nižšie v časti 5.3 Biznis vrstva.

Cieľom je analýza, návrh a rozšírenie registratúrneho systému (vrátane definovaných integrácií) pre SP v súlade s aktuálnymi legislatívnymi a procesnými požiadavkami a s ohľadom na efektívnu správu a archiváciu dokumentov a komunikácie s poistencami a tretími stranami.

• Hlavnými dôvodmi pre úpravu registratúry SP sú:
• Modernizácia zastaralých aplikačných nástrojov,
• Zabezpečenie legislatívnych požiadaviek na registratúrny systém,
• Konsolidácia agendových systémov pri práci s dokumentmi a komunikáciou s poistencami,
• Optimalizácia, zjednodušenie a zjednotenie procesov vrátane ich popísania,
• Digitalizácia papierovej agendy.
• Implementácia schvaľovacieho procesu

5.2.5 Monitoring služieb

Monitoring služieb a spätnej väzby je zdroj údajov pre Konsolidovanú analytickú vrstvu MIRRI (KAV), ktorá predstavuje zásadný krok k zlepšeniu možností a schopností analytických jednotiek vykonávať svoju činnosť a k vytvoreniu možností pre lepšiu podporu využitia analytických údajov v rozhodovacích procesoch celej verejnej správy.

Cieľom je:

• konsolidovať údaje o využívaní služieb a spätnej väzbe zo všetkých dotknutých systémov životných situácií a ich uloženie do MUSP,
• pravidelne publikovať konsolidované údaje do CSRÚ, kde bude vykonaná pseudonymizácia a následne ich KAV stiahne a spracuje,
• zadefinovať periodicitu publikovania dát do MÚSP/CSRÚ,
• zadefinovať zoznam všetkých sledovaných služieb pre všetky ŽS.

Oblasť Monitoring bude realizovaný prostredníctvom ucelených tém, pre ktoré je spoločne zadefinovaná aj biznis a aplikačná architektúra:

Tabuľka 17: Témy oblasti Monitoring služieb

5.2.5.1 Poskytovanie údajov z IS PvNGP do MÚSP

IS PvNGP zabezpečí pre účely monitoringu služieb životných situácií ŽS1 a čiastočne pre ŽS5 rozšírenie údajov poskytovaných do MÚSP o nasledovné objekty evidencie a atribúty:

• (ŽS1_BP_50) Informácie pre monitorovanie služby „Podávanie žiadosti o dávku v nezamestnanosti“:
  • Existujúci dataset s informáciami o dávke v nezamestnanosti publikovaný v MÚSP bude doplnený o požadované atribúty potrebné pre monitoring.
  • Celkový dataset dávky v nezamestnanosti je definovaný v prílohe „SP - PvNGP do MÚSP - štruktúra údajov.xlsx“ v záložke „Žiadosť o DvN“. Súbor obsahuje spoločnú generickú definíciu datasetu pre všetky účely vyžadujúce informácie o DvN v MÚSP (Napr. externé dátové integrácie medzi SP a inými OVM, alebo interné dátové integrácie medzi IS SP, či zobrazovanie na portáli SP). Atribúty požadované pre účely monitoringu sú v stĺpci „BP pre ŽS1 Monitoring“ označené číslom biznis požiadavky ŽS1_BP_50. Stĺpec „Existuje v MÚSP“ dodatočne určuje, či je atribút už publikovaný v MÚSP, alebo ho treba doplniť.
  • Rozširovanie prípadne úpravy odosielaného datasetu je potrebné koordinovať aj s požiadavkami ostatných vecných odborov a životných situácií využívajúcich informácie ohľadom toho istého objektu evidencie, čo je súčasťou detailnej dátovej analýzy a ocenenia tejto aktivity.
  • Vzhľadom na všeobecné využitie objektu evidencie (nie len monitoring), MÚSP obdrží v úvodnej fáze základný súbor údajov o všetkých existujúcich konaniach o DvN (nie len aktívne) a následne bude PvNGP poskytovať nové údaje a aktualizácie relevantných informácií pri každej zmene, či novom zázname, čím sa zabezpečí priebežná synchronizácia.
• (ŽS5_02_BP_11) Informácie pre monitorovanie služby „Potvrdenie o nedoplatkoch na sociálnom poistení“. Definícia celkového datasetu príp. rozšírenie existujúceho datasetu o atribúty tejto služby bude predmetom analýzy a dizajn.

5.2.5.2 Poskytovanie údajov z IS NPaLPČ (Sýrius) do MÚSP

IS NPaLPČ zabezpečí pre účely monitoringu služieb životných situácií ŽS7 a ŽS8 rozšírenie údajov poskytovaných do MÚSP o objekty evidencie a atribúty, ktoré budú stanovené vo fáze analýza a dizajn (dotknuté BPs ŽS7_BP_99 a ŽS8_BP_82).

5.2.5.3 Poskytovanie údajov z IS ÚP (DAUP) do MÚSP

IS ÚP zabezpečí pre účely monitoringu služieb životných situácií ŽS7 a ŽS8 rozšírenie údajov poskytovaných do MÚSP o objekty evidencie a atribúty, ktoré budú stanovené vo fáze analýza a dizajn (dotknuté BPs ŽS8_BP_82).

5.2.5.4 Poskytovanie údajov z IS DP do MÚSP

IS DP zabezpečí pre účely monitoringu služieb životných situácií ŽS14 a ŽS16 rozšírenie údajov poskytovaných do MÚSP o objekty evidencie a atribúty, ktoré budú stanovené vo fáze analýza a dizajn (dotknuté BPs ŽS14_BP_70).

5.2.5.5 Poskytovanie údajov z MÚSP do CSRÚ

MÚSP je povinný pre KAV poskytnúť do CSRÚ údaje potrebné na monitoring sledovaných oblastí a parametrov za všetky životné situácie a vyhodnocované služby. Tieto údaje pochádzajú z objektov evidencie prijatých od jednotlivých agendových systémov a uchovávaných v dátovom úložisku MÚSP (dotknuté BPs ŽS1_BP_50, ŽS5_02_BP_11, ŽS7_BP_99, ŽS8_BP_82, ŽS14_BP_70).

Nasledovný zoznam predstavuje aktuálne monitorované oblasti a parametre podľa Metodického usmernenia Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 8297/2021/oPOHIT zo dňa 10.2.2021 na monitorovanie využívania služieb verejnej správy, služieb vo verejnom záujme a verejných služieb v znení Dodatku č. 1 zo dňa 1.9.2022, ktorý zahŕňa údaje pochádzajúce z agendových systémov, a ktoré budú poskytované prostredníctvom MÚSP:

• Početnosť
  • 
    
    • 
      
      • Počet podaní (2.2)

Celkový počet podaní cez všetky komunikačné kanály (osobne, listinne, elektronicky...) za merané obdobie, pričom do celkového počtu podaní sa nezapočítava ostatná komunikácia vzťahujúca sa k podaniu. Agregovaná hodnota za všetky komunikačné kanály za merané obdobie.

• 
  
  • 
    
    • 
      
      • Počet elektronických podaní (2.3)

Celkový počet elektronických podaní za merané obdobie

• Funkčnosť
  • 
    
    • 
      
      • Priemerný čas potrebný na spracovanie elektronického podania (3.1)

Priemerný čas od dátumu podania žiadosti elektronicky po dátum vydania rozhodnutia /v dňoch zaokrúhlené na jedno desatinné číslo/

• 
  
  • 
    
    • 
      
      • Priemerný čas potrebný na spracovanie podania inými komunikačnými kanálmi ako elektronicky (3.2)

Pri podaniach spracovaných inak ako formou elektronického podania sa priemerný čas spracovania sleduje samostatne pre fázu od fyzického podania žiadosti po zadanie do registratúry a od zadania do registratúry po rozhodnutie

• 
  
  • 
    
    • 
      
      • Počet vydaných rozhodnutí podľa typu doručeného podania (3.4)

Počet vydaných rozhodnutí podľa typu doručeného podania (napr. počet vydaných rozhodnutí pre „Žiadosť o zaradenie do evidencie uchádzačov o zamestnanie“, počet vydaných rozhodnutí pre „Žiadosť o dávku v nezamestnanosti“, a pod.)

• 
  
  • 
    
    • 
      
      • Počet vydaných rozhodnutí podľa mesiaca doručenia podania (3.5)

Počet vydaných rozhodnutí podľa mesiaca podania príslušnej žiadosti.

Presný aktuálny zoznam sledovaných parametrov sa môže meniť podľa výsledkov projektovej fázy analýza a dizajn a dohody s MIRRI.

Cieľom je definovať štandardizovaný a univerzálny formát datasetu, ktorý budú do KAV publikovať všetky zainteresované OVM.

MÚSP zabezpečí poskytovanie tohto datasetu do CSRÚ za všetky sledované služby SP.

Aktuálny stav definície odosielaného datasetu sa nachádza v Prílohe 5 „SP - MÚSP do CSRÚ - Monitoring – Dataset.xlsx“

5.2.5.6 Zber technických a štatistických údajov na portáli SP

Portál SP zabezpečí zber všeobecných štatistických údajov prostredníctvom nástroja Google Analytics.

Nasledovný zoznam predstavuje aktuálne monitorované oblasti a parametre podľa Metodického usmernenia Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 8297/2021/oPOHIT zo dňa 10.2.2021 na monitorovanie využívania služieb verejnej správy, služieb vo verejnom záujme a verejných služieb v znení Dodatku č. 1 zo dňa 1.9.2022, ktorý zahŕňa údaje zbierané priamo na portáli SP prostredníctvom nástroja Google Analytics:

• Návštevnosť
  • 
    
    • 
      
      • Počet návštev relevantného obsahu koncových služieb súvisiacich so životnou situáciou, podľa jednotlivých míľnikov (1.1)

Pod relevantným obsahom chápeme míľniky, ktorými si zákazník na ceste životnou situáciou prechádza v rámci webovej stránky, a ktoré ho smerujú k realizácii koncovej služby typu podanie,  napr. návod k životnej situácii, video, článok, manuál, inštalačný súbor, návšteva informačného obsahu, formulár...

Sledujeme prechody míľnikmi v rámci životnej situácie, napr. míľnik_1: návšteva domovskej stránky, míľnik_2: zobrazenie návodu týkajúceho sa danej životnej situácie, míľnik_3: prejavený záujem o podanie žiadosti online /Návšteva informačného obsahu, resp. kliknutie na odkaz na formulár žiadosti.../, míľnik_4: stiahnutie inštalačných súborov pre eID, míľnik_5: podanie online žiadosti. V rámci internej analýzy vykonanej pred realizáciou monitoringu je potrebné definovať všetky kľúčové cesty zákazníka a jednotlivé míľniky a na základe výsledkov analýzy realizovať monitoring.

• 
  
  • 
    
    • 
      
      • Počet návštev webového sídla podľa typu zariadenia (desktop, mobil, tablet), prehliadača (IE, Edge, Chrome...) a operačného systému (Android, Windows, iOS...) (1.2)

Celkový počet jedinečných návštevníkov špecializovaného portálu, rozdelený podľa typu zariadenia (desktop, mobil, tablet), prehliadača (IE, Edge, Chrome...) a operačného systému (Android, Windows, iOS...)

• 
  
  • 
    
    • 
      
      • Počet návštev webového sídla podľa odkazujúceho zdroja /slovensko.sk, direct, generické vyhľadávanie, sociálne médiá, iné.../ (1.3)

Celkový počet jedinečných návštevníkov špecializovaného portálu podľa odkazujúceho zdroja /slovensko.sk, direct, generické vyhľadávanie, sociálne médiá, iné.../

• 
  
  • 
    
    • 
      
      • Počet návštev informačného obsahu koncovej služby (1.4) ... Celkový počet jedinečných návštevníkov,  ktorí navštívili URL informácie o koncovej službe z akéhokoľvek zariadenia
• Početnosť
  • 
    
    • 
      
      • Počet úspešných stiahnutí formulára (2.1)

Počet stiahnutí formulára umiesteného na stránke, ktoré neskončili chybovou hláškou

• Funkčnosť
  • 
    
    • 
      
      • Priemerný čas strávený vypĺňaním elektronického podania (3.3) ... Priemerný čas od začatia vypĺňania elektronického podania občanom/podnikateľom po jeho odoslanie.
• Chybovosť
  • 
    
    • 
      
      • Počet použití podporných komunikačných kanálov pri využití koncovej služby podľa kanála a kategórie podnetu (5.1) ... Počet podaných podnetov podľa typu komunikačného kanála. Kategorizácia podnetov detailnejšie popisuje charakter prijatého podnetu a/alebo oblasť, ktorého sa podnet týka /napr. konkrétna životná situácia/
      • Počet uzavretých podnetov prijatých z podporných komunikačných kanálov podľa mesiaca prijatia podnetu (5.2) ... Počet uzavretých podnetov prijatých z podporných komunikačných kanálov podľa mesiaca prijatia podnetu za sledované obdobie.

Presný aktuálny zoznam sledovaných parametrov sa môže meniť podľa výsledkov projektovej fázy analýza a dizajn a dohody s MIRRI.

Portál SP zabezpečí doručovanie údajov zozbieraných prostredníctvom Google Analytics priamo do KAV (dotknuté BPs ŽS1_BP_50, ŽS5_02_BP_11, ŽS7_BP_99, ŽS8_BP_82, ŽS14_BP_70).

Požadovaná perióda doručovania a vyhodnocovania štatistických údajov je 1 mesiac.

5.2.5.7 Zber a spracovanie spätnej väzby na portáli SP

Portál SP zabezpečí:

• Zber spätnej väzby od zákazníka podľa Metodického usmernenia Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 8297/2021/oPOHIT zo dňa 10.2.2021 na monitorovanie využívania služieb verejnej správy, služieb vo verejnom záujme a verejných služieb v znení Dodatku č. 1 zo dňa 1.9.2022 na vyjadrenie spokojnosti v súvislosti s využitou koncovou službou:
  • Spokojnosť:
    • Miera spokojnosti zákazníkov (CSAT) (4.1) ...

CSAT (angl.:Customer Satisfaction Score) sa sleduje pre podania prostredníctvom všetkých komunikačných kanálov, samostatne pre kanál elektronicky a samostatne pre ostatné kanály.

CSAT sa sleduje aj pri využití služieb informačného obsahu, a to v súlade s ID-SK.

Hodnota CSAT sa získa položením otázky občanovi/podnikateľovi s možnými odpoveďami v binárnom vyjadrení (Áno/Nie) alebo bodového hodnotenia od 1 do 5, kde 1 znamená najmenšiu spokojnosť, 5 najväčšiu spokojnosť (1 = Veľmi nespokojný, 2 = Nespokojný, 3 = Ani spokojný ani nespokojný, 4 = Spokojný a 5 =Veľmi spokojný). CSAT sa určuje ako počet spokojných zákazníkov/počet odpovedí*100 (pri odpovediach Áno/Nie) alebo ako priemer všetkých prijatých bodových hodnotení (pri bodovom hodnotení 1-5)

• Zadanie spätnej väzby - všeobecne na portáli
• Zadanie spätnej väzby - v rámci služby
• Ukladanie spätnej väzby
• Spätná väzba - export údajov
• Spätná väzba - správa incidentov

(Dotknuté BPs ŽS1_BP_50a, ŽS5_02_BP_11a, ŽS7_BP_110, ŽS8_BP_94, ŽS14_BP_70a).

5.3 Biznis vrstva

V tejto kapitole je detailnejšie rozpracovaná zvolená alternatíva riešenia v biznis vrstve architektúry. Uvádza sa prehľad e-Government komponentov – Koncových služieb, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré sú zaevidované v MetaIS v rámci výstupu M-06.

5.3.1 Návrh riešenia v biznis vrstve architektúry

5.3.1.1 Frontend

Popis AS IS stavu

V rámci životných situácií SP využíva nasledovné informačné systémy verejnej správy -

• IS Manažment údajov Sociálnej poisťovne (IS_MÚSP) - isvs_8729
• IS starobného dôchodkového sporenia (SDS) - isvs_555
• Systém elektronických služieb (SES) - isvs_551
• IS výberu poistného a príspevkov (VPP) - isvs_545
• IS úrazového poistenia (UP) - isvs_549
• IS poistenia v nezamestnanosti a garančného poistenia (PvN a GP) - isvs_550
• IS dôchodkového poistenia (DP) - isvs 546
• Informačný systém Jednotného výberu poistného (IS JVP)  - isvs_8213
• IS nemocenského poistenia a lekárskej posudkovej činnosti (IS NPaLPČ)  - isvs_547
• Informačný systém registratúra (IS REG)  - isvs_11264

V rámci celkovej biznis architektúry súčasného stavu sú identifikované fyzické osoby a právnické osoby, pričom môžu vystupovať vo viacerých rolách (biznis aktéri):

• Fyzické osoby:  
  • Občan SR;
  • Cudzinec;
  • Poistenec;
  • Splnomocnenec;
  • Notár;
  • Lekár;
  • Posudkový lekár SP;
  • Zamestnanec zamestnávateľa;
  • Zamestnanec SP. 
• Právnické osoby:
  • SP ústredie;
  • SP pobočka;
  • Zamestnávateľ;
  • Notársky úrad;
  • Dôchodcovská správcovská spoločnosť;
  • Finančná inštitúcia - banka;
  • Iné OVM (Ministerstvo vnútra SR, ÚPSVaR, ÚPDnZS, VÚC;, NCZI a ďalšie subjekty).

Informácie a služby sú poskytované nasledovnými prístupovými kanálmi: listinne, osobne, telefonicky a elektronicky, pričom elektronická forma je poskytovaná v menšej miere, najviac využívaný prístupový kanál je osobne. 

Z pohľadu číselníka úsekov a agend projekt rieši:

• U000139 Sociálne poistenie
• U000140 Starobné a dôchodkové sporenie
• A0001816 Výber poistného a príspevkov na starobné dôchodkové sporenie, správa a vymáhanie pohľadávok
• A0001817 Konanie o dávkach a výplata dávok dôchodkového poistenia, nemocenského poistenia, úrazového poistenia, poistenia v nezamestnanosti a garančného poistenia
• A0001818 Vykonávanie kontrolnej činnosti, konzultačnej a poradenskej činnosti vo veciach sociálneho poistenia
• A0001819 Vykonávanie lekárskej posudkovej činnosti
• A0001820 Postupovanie príspevkov sporiteľov na starobné dôchodkové sporenie

Dotknuté životné situácie:

• ŽS 107 – Dôchodok,
• ŽS 128 – Dôchodkové sporenie,
• ŽS 129 – Podpora v nezamestnanosti,
• ŽS 134 – Sociálne poistenie,
• ŽS 136 – Práceneschopnosť, materská, ošetrenie člena rodiny,
• ŽS 025 – Služby

Dotknutá životná situácia v rámci investičného plánu prioritných životných situácii:

• ŽS01 - Strata zamestnania
• ŽS05 - Administratívny chod podniku
• ŽS07 - Narodenie dieťaťa
• ŽS08 - Som chorý, mám chorého člena rodiny
• ŽS09 - Som odkázaný, mám odkázaného člena rodiny
• ŽS14 - Odchod do dôchodku
• ŽS16 - Úmrtie a dedičské konanie

Z pohľadu oblastí, ktorých sa projekt dotýka, SP realizuje základnú biznis funkciu (vychádza zo základných funkcií VS definovaných už v NKIVS), ktorou je Poskytovanie služieb SP v oblasti sociálneho poistenia. V rámci riešenia projektu  - integrovaný a prierezový kolaboračný systém slúžiaci pre správu a spracovanie vstupných a výstupných dokumentov týkajúcich sa klienta a jeho väzby na sociálne poistenie je zabezpečených viacero biznisových požiadaviek v rámci prioritných životných situácií 1, 5, 7, 8, 9, 14 a 16, ktoré sú v gescii Sociálnej poisťovne a ktoré vychádzajú z projektu Budovanie eGovernment riešení prioritných životných situácií financovaného z Plánu obnovy a odolnosti.

Predkladaná dokumentácia predstavuje celkový obraz architektúry, pričom v rámci biznisovej vrstvy je možné identifikovať nasledovné  agendy a aktérov podľa jednotlivých ŽS:

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 1 – Strata zamestnania:

• Vyplácanie dávok v nezamestnanosti
• Výkon evidencie vyplácaných dávok

Biznis aktéri:

Fyzické osoby - interné: 

• Zamestnanec SP

Fyzické osoby - externé: 

• Občan SR;
•  Poistene;
• Zamestnanec zamestnávateľa

Právnické osoby – externé

• OVM
• SUDEX
• Štátna pokladnica
• Ústredie práce, sociálnych veci a rodiny (ÚPSVaR Ústredie práce, sociálnych veci a rodiny (ÚPSVaR)
• zamestnávateľ
• MIRRI

Právnické osoby – interné

• SP ústredie
• SP pobočka

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 5 – Administratívny chod podniku:

• Výkon registračnej povinnosti
• Evidencia platených odvodov
• Výkon kontrolnej činnosti.

Biznis aktéri:

Fyzické osoby - externé: 

• Občan SR
• Zamestnanec zamestnávateľa

Právnické osoby – externé

• OVM
• SUDEX
• Štátna pokladnica
• Ústredie práce, sociálnych veci a rodiny (ÚPSVaR Ústredie práce, sociálnych veci a rodiny (ÚPSVaR)
• zamestnávateľ
• MIRRI

Fyzické osoby - interné: 

• Zamestnanec SP

Právnické osoby – interné

• SP ústredie
• SP pobočka

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 7 – Narodenie dieťaťa:

• Vyplácanie materskej - tehotnej žene
• Vyplácanie materskej – iná osoba
• Vyplácanie materskej – otcovské
• Vyplácanie tehotenskej
• Vyplácanie vyrovnávacej dávky

Biznis aktéri:

Fyzické osoby - externé: 

• 
  
  •  Občan SR
  •  Lekár
  •  Špecializovaný lekár
  •  Zamestnanec zamestnávateľa

Fyzické osoby – interné

• 
  
  •  Zamestnanec SP

Právnické osoby – externé

• 
  
  •  Slovenská pošta
  •  SUDEX
  •  Štátna pokladnica
  •  ÚPSVaR
  •  NCZI
  •  Zamestnávateľ
  •  OVM
  •  MIRRI

Právnické osoby – interné

• 
  
  •  SP ústredie
  •  SP pobočka

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 8 – Som chorý, mám chorého člena rodiny:

• Vyplácanie PN
• Vyplácanie Úrazového príplatku
• Vyplácanie úrazovej renty a jednorazového vyrovnania
• Vyplácanie ošetrovného (krátkodobé) z dôvodu ošetrovania člena rodiny
• Vyplácanie ošetrovného z dôvodu uzatvorenia zariadenia
• Vyplácanie ošetrovného (dlhodobé) z dôvodu ošetrovania člena rodiny.

Biznis aktéri:

 Fyzické osoby - externé: 

• 
  
  •  Občan SR
  •  Lekár
  •  Zamestnanec zamestnávateľa

Fyzické osoby – interné

• 
  
  •  Zamestnanec SP
  •  Posudkový lekár SP

Právnické osoby – externé

• 
  
  •  Slovenská pošta
  •  SUDEX
  •  Štátna pokladnica
  •  ÚPSVaR
  •  NCZI
  •  Zamestnávateľ
  •  OVM
  •  MIRRI
  •  ÚVZ
    • Špecializované pracovisko
  •  Klinika pracovného lekárstva
  •  Uzatvorené zariadenie

Právnické osoby – interné

• 
  
  •  SP ústredie
  •  SP pobočka

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 9 – Som odkázaný, mám odkázaného člena rodiny:

• Poskytovanie starostlivosti o člena rodiny/odkázaného

Biznis aktéri:

Fyzické osoby: 

• 
  
  • Občan;

Právnické osoby

• 
  
  • Sociálna poisťovňa ústredie;
  • Sociálna poisťovňa – pobočky;
  • Úrad práce, sociálnych vecí a rodiny.

Hlavné agendy, ktoré SP realizuje v rámci životnej situácie č. 14 – Odchod do dôchodku:

• Výkon dôchodkového poistenia
  • Starobný dôchodok
  • Predčasný starobný dôchodok
  • Invalidný dôchodok (súčasť ŽS9)
• Výkon dôchodkového sporenia
• Výkon správy dôchodku
• Dôchodková prognóza.

 Biznis aktéri:

 Fyzické osoby: 

• 
  
  • Občan;
  • Cudzinec;
  • Zamestnanec zamestnávateľa;
  • Zamestnanec SP;
  • Posudkový lekár SP;

Právnické osoby

• 
  
  • Zamestnávateľ/ bývalý zamestnávateľ;
  • Sociálna poisťovňa ústredie;
  • Sociálna poisťovňa – pobočky;
  • Finančná inštitúcia – banka;
  • Úrad práce, sociálnych vecí a rodiny;
  • Dôchodková správcovská spoločnosť;
  • Vyššie územné celky;
  • OVM.

Hlavná agenda, ktorú SP realizuje v rámci životnej situácie č. 16 – Úmrtie a dedičské konanie:

• výkon pozostalostných dávok sociálneho poistenia.

Biznis aktéri:

Fyzické osoby: 

• 
  
  • Občan;
  • Cudzinec;
  • Zamestnanec SP
  • Notár;

Právnické osoby

• 
  
  • Sociálna poisťovňa ústredie;
  • Sociálna poisťovňa – pobočky;
  • Ministerstvo vnútra SR;
  • Úrad pre dohľad nad zdravotnou starostlivosťou;
  • Notársky úrad;
  • Úrad práce, sociálnych vecí a rodiny;
  • Vyššie územné celky;
  • Dôchodková správcovská spoločnosť;
  • OVM.

Diagram 3: Strešný model biznis architektúry Frontendu - AS IS

Z pohľadu biznis funkcií, ktorých sa navrhovaný projekt týka, sú dôležité nasledovné oblasti:

• Výber poistného;
• Výkon poistenia v nezamestnanosti;
• Výkon dôchodkového poistenia;
• Výkon nemocenského poistenia;
• Výkon úrazového poistenia;
• Výkon garančného poistenia;
• Starobné dôchodkové sporenie;
• Lekárska posudková činnosť.

Popis TO BE stavu

Zmena na úrovni biznis aktérov v budúcom stave nenastane v ich priradenej role, ale  v spôsobe výmeny údajov a informácií medzi týmito aktérmi. Tam, kde to bude možné, pôjde o automatizované zasielanie údajov medzi jednotlivými aktérmi/rolami.

Biznis rozhrania:

Prístupové body, prostredníctvom ktorých sa bude pristupovať k biznis službám: elektronicky, listinne, osobne a telefonicky.

• Elektronicky: špecializovaný portál SP, ÚPVS, mÚPVS, email, intranet SP, webové sídlo
• Osobne: Ústredie SP, pobočky SP
• Telefonicky: Ústredie SP, pobočky SP
• Listinne: Ústredie SP, pobočky SP

Zmena na úrovni biznis vrstvy nastane zlepšením prístupových miest, ktoré sú elektronickým komunikačným kanálom a v prístupe k novej službe rezervačného systému SP. Služby budú naďalej poskytované aj komunikačnými kanálmi: listinne, osobne a telefonicky. Významnou zmenou bude jeden prístupový portál pre viacerých aktérov. Pri jednotlivých budúcich el. službách bude v prípade takých el. služieb, ktoré nie je možné realizovať plne elektronicky, práve možnosť vytvoriť podanie (žiadosť, oznámenie a podobne) v časti a dokončiť ho napr. osobnou návštevou s využitím rezervácie.

Súčasťou budúceho riešenia bude upravený špecializovaný portál SP, ktorý bude poskytovať naďalej funkcie Verejného obsahu (doplnené o relevantné informácie a možnosti v súvislosti s riešením konkrétnych ŽS). Zmena nastane aj v rámci Privátneho obsahu, resp. privátnej časti portálu, ktorá bude poskytovať:

• existujúce služby pre zamestnávateľov a SZČO – odvádzateľov poistného, poskytovateľov zdravotnej starostlivosti, inštitúcie, rezorty;
• upravené existujúce služby v rámci Elektronického účtu poistenca;
• nové el. služby pre FO a PO v kontexte ŽS.

Verejný obsah bude obsahovať:

• Statický obsah - umožní používateľovi portálu sledovať statické informácie ako novinky, informácie o dostupných službách SP, legislatívne zmeny, kontakty, informácie mimo detailov v kontexte ŽS, informácie týkajúce sa GDPR, informácie v sekcii Kariéra.
• Návody ŽS - budú uvedené statické informácie o ŽS ako popis ŽS, URL link na súvisiace ŽS, URL link na formuláre, vysvetľujúce zákony, miesta pre vybavenie ŽS.
• Statické formuláre “Na stiahnutie” - budú obsahovať formuláre na stiahnutie so zoznamom potrebných príloh, bez možnosti online vypĺňania.
• Rezerváciu termínov na pobočke SP.
• Identifikáciu a autentifikáciu - pre vstup klienta do Privátnej časti portálu.

V budúcom stave bude naďalej využitá aj aktuálna funkcionalita verejného obsahu z pohľadu navigácie k službám a informačnému obsahu, ktorá je v súčasnom stave veľmi dobre navrhnutá a udržiavaná. Samotná navigácia (a jej možnosti) k jednotlivým el. službám a formulárom bude využitá aj pri spracovaní navigačnej logiky relevantnej privátnej časti portálu (dizajnový návrh, resp. Iniciálny grafický návrh je súčasťou samostatného dokumentu).

Privátny obsah bude používateľovi sprístupnený po identifikácii a autentifikácii. Služby privátneho obsahu budú nasledovné:

• Všeobecné údaje poistenca - Moje údaje - bude obsahovať osobné údaje používateľa, osobné údaje rodinných príslušníkov, kontaktné údaje a prehľad zamestnávateľov a ďalšie údaje podľa typu používateľa (FO/PO).
• Individuálny účet klienta - Môj účet - prehľad o dátach poistenca a iné dáta podľa typu používateľa (zamestnanec, zamestnávateľ a podobne), usporiadané do viacerých sekcií (tzv. Saldokonto). Dáta budú obsahovať informácie z agendových systémov SP.
• Personalizovaný obsah ŽS - Moje ŽS  - zoznam ŽS prispôsobený možným životným situáciám používateľa, proaktívne služby, stav konaní, stav z pohľadu ŽS (vyššie spomenutá orchestrácia medzi OVM).
• Elektronické služby (podania pre FO/PO resp. žiadosti, oznámenia a podobne)- el. služby realizované buď ako el. formuláre a budú predvýpĺňané z dostupných údajov klienta s obsahom všeobecného popisu , zoznamom potrebných príloh, možnosťou pridať spätnú väzbu, alebo budú realizované aj ako „inteligentné“ formuláre, kde logika krokov, postupnosti a obsahu vypĺňania bude riadená nástrojmi „na pozadí“ tak, že od klienta budú požadované len relevantné údaje, prípadne potvrdenie dostupných vyplnených údajov a len relevantné kroky (podľa Detailného návrhu riešenia, ktorý bude adresovať v tom čase platný stav IS v správe SP a ich rozvoja). Nižšie v dokumente sa nachádza zoznam koncových služieb, ktoré budú riešením dotknuté (nové koncové služby, upravované služby, prípadne zrušené koncové služby);
• Vstupné a výstupné elektronické dokumenty klienta - Moje dokumenty  - bude obsahovať odoslané žiadosti aj prijaté dokumenty od SP a to aj v prípade, že podanie bude realizované inak, ako elektronicky (osobne/listinne) – dokumenty budú digitalizované a nahrávane do „Zložky klienta“ zo strany SP.
• História komunikácie o sociálnom poistení - Elektronická schránka SP - bude podporovať  doručovanie el. dokumentov, správ a notifikácií (v prípadoch, kedy je možné, resp. dovolené aj paralelné doručovanie okrem tzv. eGOV schránky na slovensko.sk).
• Rezervácie termínov na pobočke SP

Zavedenie inovovaných služieb pre používateľov prispeje k zvýšeniu kvality, štandardu a dostupnosti elektronických služieb pre klientov SP.

Diagram 4 : Strešný model architektúry Frontendu - TO BE

Mobilná aplikácia pre potreby ŽS5

Súčasťou oblasti Frontend je aj modernizácie aplikácie primárne slúžiaca pre ŽS5, teda pre klientov SP - Odvádzateľov poistného, ktorá zjednodušuje a modernizuje správu služieb poistenca. Základné funkčné celky aplikácie tvorí predovšetkým registrácia, nástroje na výpočet výšky poistného pre SZČO a PUSH notifikácie pre aktuálne informovanie používateľov. Kľúčovým prvkom je aj intuitívna domovská stránka (obrazovka), ktorá slúži ako vstupná brána do aplikácie, podporená efektívnym onboarding procesom a dynamickým prepínačom služieb, čím sa zabezpečuje prispôsobenie obsahu individuálnym potrebám každého používateľa. Mobilná aplikácia bude umožňovať predbežnú registráciu, ktorá slúži Zamestnávateľovi na registrovanie firmy a zamestnancov do IS Sociálnej poisťovne. Proces začína zadaním identifikačných údajov zamestnávateľa, následne po úspešnej autorizácii pomocou autorizačného kódu môže zamestnávateľ spravovať svoje firmy. Pre každú firmu následne môže samostatne evidovať zamestnancov. V aplikácii bude možné vykonať prihlásenie a odhlásenie zamestnanca, zamestnávateľovi bude poskytnutý prehľad všetkých predbežne prihlásených zamestnancov, ktorí sú evidovaní v rámci konkrétnej firmy.  

Novou funkcionalitou bude tiež sekcia nedoplatky, ktorá umožní používateľovi prehľad celkovej výšky nedoplatkov ako aj rozpad jednotlivých neuhradených platieb, z ktorých sa nedoplatok skladá. Tieto jednotlivé platby môže používateľ vybrať a následne je presmerovaný na platobnú bránu. Takisto môže vybrať možnosť zaplatiť všetko, vtedy nemusí prechádzať jednotlivé platby a na platobnú bránu je smerovaný so sumou všetkých nedoplatkov, ktoré takto budú jednou platbou uhradené. 

Poistenec bude zároveň informovaný o kľúčových udalostiach súvisiacich s jeho žiadosťami, platbami a nastaveniami v mobilnej aplikácii Sociálnej poisťovne prostredníctvom push notifikácií.  

Mobilná aplikácia bude zároveň spĺňať všetky bezpečnostné štandardy, s cieľom zabezpečiť dôvernosť, integritu a dostupnosť údajov v každej vrstve systému, a zároveň garantovať, že aplikácia bude zrozumiteľná, použiteľná a dôveryhodná pre všetkých občanov. 

Aplikácia je koncipovaná ako tenký klient, nie je priamo zodpovedná za dátovú reprezentáciu a úložisko – slúži prevažne iba na zobrazovanie/prezentáciu dát získaných z aplikačného backend REST API pre používateľa a umožňuje odosielanie žiadostí a volania na platobnú bránu ohľadom poistného atď.

Vysokoúrovňový prehľad biznis architektúry riešenia je zachytený na diagrame nižšie, zobrazuje vzťahy medzi kľúčovými komponentami riešenia a kľúčovou technickou funkcionalitou. Diagram zobrazuje vybrané kľúčové prípady použitia mobilnej aplikácie a vzťah aplikácie k systémom, na ktoré sa integruje. Napriek tomu, že diagram zobrazuje dvoch rôznych aktérov, ako bolo už uvedené vyššie, mobilná aplikácia ako taká v kontexte autentifikácie a autorizácie používateľa nerozlišuje rôzne používateľské role, obaja aktéri predstavujú používateľskú rolu „Poistenec“.

Architektúra je tvorená 2 základnými vrstvami:

• Prezentačná vrstva – predstavuje samotnú mobilnú aplikáciu ako rozhranie na zobrazenie údajov používateľmi a zber vstupov používateľa.
• Aplikačná vrstva – je reprezentovaná aplikačným backendom, ktorý tvorí rozhranie medzi mobilnou aplikáciou a ostatnými IS Sociálnej Poisťovne

Diagram 5: kľúčové prípady použitia mobilnej aplikácie a vzťah aplikácie k systémom, na ktoré sa integruje

Rezervačný systém

Súčasný rezervačný systém SP už nespĺňa požiadavky a nároky kladené na takýto systém Súčasný rezervačný systém je nasadený na e-službách, separátne od webu a je potrebné, aby bol súčasťou aj Špecializovaného portálu (EÚP).

Preto je súčasťou rozsahu predkladaného projektu aj rozvoj Rezervačného systému SP a jeho prispôsobenie k potrebám životných situácií..

Prípady použitia

a) Rezervácia termínu cez webové sídlo SP (neautentifikovaný používateľ)

Klient (neautentifikovaný používateľ) si bude môcť rezervovať termín prostredníctvom samostatnej sljhužby na webovom sídle SP. Po vyplnení údajov o svojej osobe (minimálne meno, priezvisko, dátum narodenia, email a telefónne číslo), údaje potvrdí ochranným prvkom Captcha. Systém overí, či používateľ si môže rezervovať termín na základe podmienok používania1 rezervačného systému. Systém odošle používateľovi kód, ktorý musí používateľ zadať do rezervačného systému, aby mohol pokračovať v rezervácií (kód slúži pre ďalšiu ochranu systému a zároveň pre overenie správnosti emailu, telefónneho čísla a prístupu k nim). Výber, kde bude posielaný overovací kód bude môcť byť nastavený v administrácií systému (zaslanie overovacieho kódu len formou SMS, alebo len emailom, prípadne na obidva kanály). Systém musí poskytnúť dostatočné informácie, aby používateľ vedel, prečo si nemôže rezervovať termín.

Po overení používateľ vyberie agendu a systém mu poskytne informačný obsah súvisiaci s náležitosťami potrebnými pre úspešné vybavenie svojej žiadosti (potrebné doklady, doplňujúce informácie – podľa zvolenej agendy – môže a nemusí byť definované).

V poslednom kroku si používateľ vyberie pobočku, ktorú chce navštíviť a systém mu ponúkne dostupné voľné termíny (v prípade definície súvisiacich resp. vysunutých pracovísk v administrácií systém používateľovi zobrazí aj voľné termíny na inej pobočke – tieto termíny musia byť jasne viditeľné, že sa týkajú iného pracoviska). Po výbere dňa prostredníctvom kalendára mu systém zobrazí dostupné termíny pre zvolený deň a používateľ si zvolí konkrétny čas. Používateľ musí pred odoslaním rezervácie termínu kliknúť na Súhlasím so spracovaním osobných údajov za účelom vybavenia požiadavky s možnosťou odkliku na informácie uvedené v súbore alebo webovej stránke (text súhlasu ako aj podmienky spracovania bude možné meniť podľa potreby).

Systém po potvrdení rezervácie odošle o rezervovanom termíne na emailovú adresu notifikáciu s udalosťou do kalendára, ktorú si môže používateľ importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o rezervovanom termíne formou SMS.

Proces:

1. Používateľ vyberie službu pre rezerváciu termínu a vyplní údaje o svojej osobe. 

1. Webový portál odošle informácie do rezervačného systému. 

1. Rezervačný systém overí či osoba môže vytvoriť rezerváciu a odošle tieto informácie webovému portálu. 

1. Webový portál zobrazí získané informácie: 

• V prípade zamietnutia si osoba nemôže rezervovať online termín a proces končí 

• V prípade potvrdenia vyberie osoba agendu a lokalitu a systém odošle tieto informácie do rezervačného systému 

1. Rezervačný systém odošle dostupné termíny pre rezerváciu danej agendy a lokality 

1. Webový portál zobrazí dostupné termíny 

1. Používateľ vyberie pre neho vhodný termín a zaškrtne súhlas so spracovaním osobných údajov a potvrdí tlačidlom. 

1. Webový portál odošle rezervovaný termín do rezervačného systému 

1. Rezervačný systém zablokuje termín a odošle používateľovi notifikácie 

b) Rezervácia termínu na špecializovanom portáli (autentifikovaný používateľ)

Klient (autentifikovaný používateľ – používateľ musí byť prihlásený) si bude môcť rezervovať termín prostredníctvom samostatnej služby na špecializovanom portáli. Systém v prípade autentifikovaného používateľa predvyplní údaje o používateľovi (meno, priezvisko, dátum narodenia) na špecializovanom portáli.  Používateľ doplní email a telefónne číslo (ak údaje nemá vyplnené v profile) a potvrdí správnosť údajov. Systém overí, či používateľ si môže rezervovať termín na základe podmienok používania rezervačného systému. Systém odošle používateľovi kód, ktorý musí používateľ zadať do rezervačného systému, aby mohol pokračovať v rezervácií (kód slúži pre ďalšiu ochranu systému a zároveň pre overenie správnosti emailu, telefónneho čísla a prístupu k nim). Výber, kde bude posielaný overovací kód bude môcť byť nastavený v administrácií systému (zaslanie overovacieho kódu len na formou SMS, alebo len emailom, prípadne na obidva kanály). Systém musí poskytnúť dostatočné informácie, aby používateľ vedel, prečo si nemôže rezervovať termín.

Po overení používateľ vyberie agendu a systém mu poskytne informačný obsah súvisiaci s náležitosťami potrebnými pre úspešné vybavenie svojej žiadosti (potrebné doklady, doplňujúce informácie – podľa zvolenej agendy – môže a nemusí byť definované).

V poslednom kroku systém priradí pobočku automaticky na základe miesta bydliska používateľa s možnosťou zmeny pobočky a systém mu ponúkne dostupné voľné termíny (v prípade definície súvisiacich resp. vysunutých pracovísk v administrácií systém používateľovi zobrazí aj voľné termíny na inej pobočke – tieto termíny musia byť jasne viditeľné, že sa týkajú iného pracoviska). Po výbere dňa prostredníctvom kalendára mu systém zobrazí dostupné termíny pre zvolený deň a používateľ si zvolí konkrétny čas. Používateľ musí pred odoslaním rezervácie termínu kliknúť na Súhlasím so spracovaním osobných údajov za účelom vybavenia požiadavky s možnosťou odkliku na informácie uvedené v súbore alebo webovej stránke (text súhlasu ako aj podmienky spracovania bude možné meniť podľa potreby).

Systém po potvrdení rezervácie odošle o rezervovanom termíne na emailovú adresu notifikáciu s udalosťou do kalendára, ktorú si môže používateľ importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o rezervovanom termíne formou SMS. Systém automaticky vloží rezervovaný termín do kalendára na špecializovanom portáli (v prípade existencie na špecializovanom portáli).

Aj autentifikovaný používateľ stále môže využiť služby neautentifikovaného používateľa.

Proces z pohľadu používateľa

1. Používateľ vyberie službu pre rezerváciu termínu 

1. Špecializovaný portál mu predvyplní informácie, ktoré má o ňom k dispozícií. 

1. Používateľ potvrdí vyplnené údaje o svojej osobe alebo ich môže zmeniť. 

1. Špecializovaný portál odošle informácie do rezervačného systému. 

1. Rezervačný systém overí či osoba môže vytvoriť rezerváciu a odošle tieto informácie špecializovanému portálu. 

1. Špecializovaný portál zobrazí získané informácie: 

• V prípade zamietnutia si osoba nemôže rezervovať online termín a proces končí 

• V prípade potvrdenia vyberie osoba agendu a lokalitu a systém odošle tieto informácie do rezervačného systému 

1. Rezervačný systém odošle dostupné termíny pre rezerváciu danej agendy a lokality 

1. Špecializovaný portál zobrazí dostupné termíny 

1. Používateľ vyberie pre neho vhodný termín a zaškrtne súhlas so spracovaním osobných údajov a potvrdí tlačidlom. 

1. Špecializovaný portál odošle rezervovaný termín do rezervačného systému 

1. Rezervačný systém zablokuje termín a odošle používateľovi notifikácie 

c)Rezervácia termínu zamestnancom SP (GUI pre zamestnanca SP)

Zamestnanec SP bude môcť vytvoriť samostatnú rezerváciu voľného termínu pre klienta prostredníctvom GUI rozhrania pre zamestnanca SP. Zamestnanec vyplní potrebné údaje o klientovi, vyberie vhodný deň a voľný termín. Systém overí, či klient si môže rezervovať termín na základe podmienok používania rezervačného systému.

Systém po potvrdení rezervácie odošle o rezervovanom termíne na emailovú adresu notifikáciu s udalosťou do kalendára, ktorú si môže klient importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o rezervovanom termíne formou SMS.

Ak zamestnanec SP vytvára rezerváciu telefonicky, informuje klienta o spracúvaní osobných údajov, ktoré za týmto účelom získal. Zamestnanec SP môže požiadať klienta o informácie o vygenerovanom kóde na telefón pre potvrdenie rezervácie prostredníctvom telefónu (systém vygeneruje na telefónne číslo automaticky na základe pokynu zamestnanca SP).

Klient prostredníctvom odoslanej rezervácie musí potvrdiť takto rezervovaný termín (napr. formou kliknutia na potvrdzovací link). Bez takéhoto potvrdenia je termín rezervovaný len určitý čas a ak termín nebude klientom potvrdený do určitého času, opätovne sa tento termín stane voľným. Zároveň bude v texte uvedené, že potvrdením zároveň súhlasí so spracovaním osobných údajov za účelom rezervácie termínu.

d) Zrušenie potvrdenej rezervácie 

Systém umožní klientovi zrušiť jeho rezervovaný termín v prípade potreby napr. kliknutím na linku v emailovej notifikácií o potvrdení termínu alebo zaslaním spätnej SMS v definovanom tvare, prípadne cez funkcionalitu zrušenia na špecializovanom portáli. Vygenerovaný odkaz/sms bude v sebe obsahovať informácie o konkrétnej rezervácií, ktorý zabezpečí zrušenie tohto termínu a jeho uvoľnenie. 

Proces z pohľadu používateľa:

1. a) Používateľ prostredníctvom emailového klienta klikne na email Potvrdenie rezervovaného termínu a klikne na odkaz Zrušenie termínu 

b) Používateľ v definovanom tvare odošle spätnú sms na telefónne číslo pre Zrušenie termínu.  

c) Používateľ na špecializovanom portáli klikne na existujúcu rezerváciu a klikne na tlačidlo Zrušiť rezerváciu termínu. 

1. Rezervačný systém po získaní informácie o Zrušení termínu zruší rezerváciu a uvoľní daný termín (v prípade splnenia podmienok) 

e) Dostavenie sa na rezervovaný termín (integrácia rezervačného IS a vyvolávacieho IS) 

Klient s rezervovaným termínom musí v rámci definovaného časového obdobia zadať PIN alebo prípadný QR kód do Kiosku vyvolávacieho systému, aby bol potvrdený následne rezervačným systémom potvrdený jeho rezervovaný termín a používateľ môže byť zaradený do poradia. Ak sa klient nedostaví včas nebude zaradený do poradia, prípadne bude zaradený na koniec zoznamu v daný deň (ak pracovník pobočky SP má voľnú kapacitu v daný deň a ak občan je ochotný vyčkať v tento deň).

f) Overenie rezervácie cez webové sídlo SP (neautentifikovaný používateľ)

Systém umožní overiť pre neautentifikovaného klienta platnú rezerváciu na webovej stránke po vyplnení potrebných informácií na webovej stránke Sociálnej poisťovne.

Proces:

1. Používateľ zadá informácie o rezervovanom termíne. 

1. Webový portál odošle vyplnené údaje do rezervačného systému. 

1. Rezervačný systém overí vyplnené údaje a odošle informáciu webovému portálu. 

1. Webový portál zobrazí potvrdenie resp. nepotvrdenie rezervovaného termínu. 

g) Overenie rezervácie na špecializovanom portáli (autentifikovaný používateľ)

Systém umožní vidieť rezervované termíny pre autentifikovaného používateľa na špecializovanom portáli. Aj autentifikovaný používateľ stále môže využiť služby neautentifikovaného používateľa.

Proces:

1. Špecializovaný portál (EKP/EUP)získa údaje o všetkých do budúcna platných rezerváciách používateľa a zobrazí mu ich na potrebnom mieste (v rámci informačného obsahu portálu). 

h) Štatistiky využívania systému (GUI pre zamestnanca SP) 

Systém musí ukladať všetky historické údaje o všetkých rezerváciách vrátane zrušených a poskytovať štatistické údaje o počte uskutočnených rezervácií podľa agendy a lokality v čase vrátane historických údajov, doby čakania, doby vybavenia, dôvod návštevy (parametrické vyhľadávanie všetkých uložených údajov – presný výraz, obsahuje, začína, končí; a; alebo; zoraďovanie; filtrovanie; exportovanie; tlačové zostavy). 

Systém poskytne údaje o všetkých budúcich rezerváciách pre konkrétne pobočky, agendové pracoviská pre účely plánovania. 

Systém zároveň poskytne aktuálne údaje vyťaženosti pobočiek, agendových pracovísk, údaje o priemernej dĺžke čakania, vybavenia. 

i) Administrácia systému (GUI pre administrátora) 

Administrátor alebo iná osoba (napr. vedúci pobočky) na základe pridelených práv bude môcť realizovať nastavenie a parametrizáciu rezervačného systému. Nastavenie bude možné nastaviť na celý rezervačný systém, ako aj konkrétnu lokalitu, prípadne agendu. Bude môcť vykonať minimálne nasledovné nastavenia:

• správa používateľov pre definovanie prístupových oprávnení; 

• správa a definovanie dostupných agend pre online rezerváciu; 

• správa a definovanie voľných termínov pre konkrétne agendy, definovanie dĺžky trvania úkonu, vybraných hodín; 

• generovanie kalendára voľných termínov na základe zadaných parametrov na určité obdobie (počet, dĺžka trvania, pracovné dni atď.); 

• úprava voľných termínov kalendára na základe potreby; 

• definovanie prepojenia súvisiacich pobočiek resp. vysunutých pracovísk pre zobrazovanie voľných termínov (umožní zobrazovať používateľovi aj voľné termíny na inej prepojenej / vysunutej pobočke); 

• definovanie počtu dní pre odoslanie pripomienky pre vybraným termínom; 

• nastavenie povinných polí v rezervačnom formulári (napr. pre vyžadovanie len emailu, alebo telefónne čísla, prípadne obidvoch informácií); 

• nastavenie overovania osoby (overenie cez email alebo telefónne číslo, prípadne obidve možnosti overenia osoby); 

• maximálna doba zadania PINu/QR kódu pred rezervovaným termínom a po rezervovanom termíne; 

• definovanie súvisiacich informácií o vybavení agendy; 

• definovanie Súhlasu so spracovaním osobných údajov s možnosťou prelinkovania na webovú adresu alebo externý súbor; 

• maximálny počet rezervácií na osobu pre jednu alebo viaceré pobočky, agendy počas x dní; 

• maximálna doba pre potvrdenie rezervácie vytvorenej zamestnancom SP; 

• maximálna dĺžka blokácie osoby; 

• parametre blokácie a ďalšie. 

Tabuľka 18: Dosah Rezervačného systému na komponenty SP

Vytvorenie služby zabezpečenej komunikácie

SP v súčasnosti neposkytuje možnosť komunikovať s klientom prostredníctvom on-line nástrojov (zabezpečenou formou). Pri príprave na vyplnenie žiadosti o dôchodok je však potrebná častejšia komunikácia so zamestnancami SP za účelom prípadného dovysvetlenia a predovšetkým kompletizácie podkladov a dokumentov potrebných k predloženiu žiadosti o dôchodok alebo jej doplneniu. Paralelne realizovaný projekt budovania nového Rezervačného systému a realizácia zmien Front-endu SP vrátane implementácie nových el. služieb. V tomto kontexte je vhodné implementovať a doplniť nové služby/riešenie aj o online zabezpečenú komunikáciu a podporiť tak procesy realizácie Životných situácií a umožniť komunikáciu aj prostredníctvom nového kanálu. 

Služba zabezpečenej elektronickej komunikácie bude slúžiť pre potreby ŽS14 z dôvodov potrebných konzultácií občanov/klientov SP pri podávaní ŽoD.

Biznis aktéri  

Fyzické osoby - interné:    

• Zamestnanec SP
• Administrátor

Fyzické osoby – externé

• Občan/klient

Právnické osoby – interné  

• SP ústredie  

• SP pobočka

Pokryté procesy

Vytvorenie online termínu cez webové sídlo SP (neautentifikovaný používateľ) 

1. Používateľ vyberie službu pre rezerváciu online termínu a vyplní údaje o svojej osobe. 

1. Webový portál odošle informácie službe zabezpečenej komunikácie. 

1. Služba zabezpečenej komunikácie overí či osoba môže vytvoriť online termín a odošle tieto informácie webovému portálu. 

1. Webový portál zobrazí získané informácie: 

• V prípade zamietnutia si osoba nemôže rezervovať online termín a proces končí 
• V prípade potvrdenia vyberie osoba agendu a lokalitu a systém odošle tieto informácie do systému zabezpečenej komunikácie 

1. Rezervačný systém odošle dostupné online termíny pre rezerváciu danej agendy a lokality 

1. Webový portál zobrazí dostupné online termíny 

1. Používateľ vyberie pre neho vhodný online termín a zaškrtne súhlas so spracovaním osobných údajov a potvrdí tlačidlom. 

1. Webový portál odošle rezervovaný online termín do systému zabezpečenej komunikácie 

1. Systém priradí link s ID schôdze (on-line schôdzka musí byť uskutočniteľná iba s využitím bežne rozšírených webových prehliadačov) 

1. Systém zabezpečenej komunikácie zablokuje online termín, priradí ID schôdze a odošle používateľovi notifikácie 

Vytvorenie online termínu (špecializovaný portál)

1. Používateľ vyberie službu pre rezerváciu online termínu 

1. Špecializovaný portál mu predvyplní informácie, ktoré má o ňom k dispozícií. 

1. Používateľ potvrdí vyplnené údaje o svojej osobe alebo ich môže zmeniť. 

1. Špecializovaný portál odošle informácie do služby zabezpečenej komunikácie. 

1. Systém zabezpečenej komunikácie overí či osoba môže vytvoriť online termín a odošle tieto informácie špecializovanému portálu. 

1. Špecializovaný portál zobrazí získané informácie: 

• V prípade zamietnutia si osoba nemôže rezervovať online termín a proces končí 
• V prípade potvrdenia vyberie osoba agendu a lokalitu a systém odošle tieto informácie do služby zabezpečenej komunikácie 

1. Systém zabezpečenej komunikácie odošle dostupné online termíny pre rezerváciu danej agendy a lokality 

1. Špecializovaný portál zobrazí dostupné online termíny 

1. Používateľ vyberie pre neho vhodný online termín a zaškrtne súhlas so spracovaním osobných údajov a potvrdí tlačidlom. 

1. Špecializovaný portál odošle rezervovaný online termín do služby zabezpečenej komunikácie 

1. Systém priradí link s ID schôdze (on-line schôdzka musí byť uskutočniteľná iba s využitím bežne rozšírených webových prehliadačov) 

1. Systém zabezpečenej komunikácie zablokuje online termín, priradí ID schôdze a odošle používateľovi notifikácie 

Overenie online termínu (webové sídlo SP)

1. Používateľ zadá informácie o rezervovanom online termíne. 

1. Webový portál odošle vyplnené údaje do služby zabezpečenej komunikácie. 

1. Systém zabezpečenej komunikácie overí vyplnené údaje a odošle informáciu webovému portálu. 

1. Webový portál zobrazí potvrdenie resp. nepotvrdenie rezervovaného online termínu. 

Overenie online termínu (špecializovaný portál) 

1. Špecializovaný portál získa údaje o všetkých do budúcna platných rezerváciách online termínovh používateľa a zobrazí mu ich na potrebnom mieste (v rámci informačného obsahu portálu). 

Zmena pracovníka/zamestnanca SP online termínu (užívateľské rozhranie SP) 

1. Užívateľské rozhranie musí umožniť Administrátorovi SP (vedúcemu zamestnancovi SP) preobsadiť už zarezervovanú schôdzku iným zamestnancom SP  

Zrušenie potvrdeného online termínu  

1. a) Používateľ prostredníctvom emailového klienta klikne na email Potvrdenie rezervovaného online termínu a klikne na odkaz Zrušenie online termínu 

b) Používateľ v definovanom tvare odošle spätnú sms na telefónne číslo pre Zrušenie online termínu.  

c) Používateľ na špecializovanom portáli klikne na existujúcu rezerváciu online termínu a klikne na tlačidlo Zrušiť rezerváciu online termínu. 

1. Systém zabezpečenej komunikácie po získaní informácie o Zrušení online termínu zruší online termín a uvoľní daný termín (v prípade splnenia podmienok) 

Účasť na online termíne 

1. Používateľ prostredníctvom ID schôdze zúčastní online termínu.  

5.3.1.2 Dátové integrácie

5.3.1.2.1  (pre ŽS1)

Z pohľadu biznis vrstvy architektúry je téma DI-2 postavená na ŽS1 – Strata a hľadanie zamestnania, pričom biznis logiku zabezpečuje proces popísaný v projekte ŽS1 prostredníctvom využitia IS MÚSP, ktorý bude zohrávať rolu centrálneho dátového úložika/centrálnej databázy údajov.

Ide o:

• rozširovanie poskytovaných údajov do CPDI (CSRÚ) (a následne do MPSVaR) o kandidátoch na zaradenie/vyradenie z evidencie UoZ
• rozširovanie poskytovaných údajov do CPDI (CSRÚ) o informácii o začatí konania pre účely poskytovania pomoci v hmotnej núdzi a rodičovských príspevkov
• rozšírenie konzumovaných dát z CPDI (CSRÚ) (pôvodom od ÚPSVaR) pre účely zúčtovania pomoci hmotnej núdzi a zastavenia vyplácanie dávky v nezamestnanosti z dôvodu poberania rodičovského príspevku.

Konkrétne objekty evidencie sú určené v kapitole 5.5 Dátová architektúra.

Pre naplnenie cieľov bude potrebné zabezpečiť služby

• na strane IS MÚSP – prijímanie údajov do MÚSP cez MÚSP ESB (integračnú platformu), kontroly na entitnú, referenčnú a sémentickú integritu a logovanie dátovených prenosov. Zároveň sa počíta s tým, že zodpovednosť za údržbu prenosových štruktúr bude zodpovedný rovnako IS MÚSP a jeho produktový tím/biznis vlastníci.
  1. Na strane agendových systémov - popísané v projekte ŽS1 (úprava/tvorba nových aplikačných funkcií, ktoré bude zabezpečovať ako nové dáta, tak i zmeny nad dátami)

5.3.1.2.2 DI-4 (pre ŽS5)

Z pohľadu biznis vrstvy architektúry je téma DI-4 postavená na ŽS5 – Administratívny chod podniku, pričom biznis logiku zabezpečuje proces popísaný v projekte ŽS5 prostredníctvom využitia IS MÚSP, ktorý bude zohrávať rolu centrálneho dátového úložika/centrálnej databázy údajov.

Ide o:

• Interná integrácia - publikovanie údajov do MÚSP/MDM (IS SP → IS MÚSP/MDM) 
• Interná integrácia - Získanie údaju SP  - BATCH (MÚSP/MDM → IS SP) 

Pre naplnenie cieľov bude potrebné zabezpečiť služby

• na strane IS MÚSP – prijímanie údajov do MÚSP cez MÚSP ESB (integračnú platformu), kontroly na entitnú, referenčnú a sémantickú integritu a logovanie dátových prenosov. Zároveň sa počíta s tým, že zodpovednosť za údržbu prenosových štruktúr bude zodpovedný rovnako IS MÚSP a jeho produktový tím/biznis vlastníci.
• Na strane agendových systémov - popísané v projekte ŽS5 (úprava/tvorba nových aplikačných funkcií, ktoré bude zabezpečovať ako nové dáta, tak i zmeny nad dátami).

5.3.1.2.3 DI-5 (pre ŽS7 a ŽS8)

Z pohľadu biznis vrstvy architektúry je téma DI-5 postavená na postavená na ŽS7 – Narodenie dieťaťa a ŽS8 - Som chorý, mám chorého člena rodiny, pričom biznis logika a proces je popísaný v projekte ŽS7+8 prostredníctvom využitia IS MÚSP, ktorý bude zohrávať rolu centrálneho dátového úložika/centrálnej databázy údajov.

Ide o:

1. Získanie údajov z CSRÚ (CSRÚ → IS MÚSP/MDM) 
2. Publikovanie údajov do CSRÚ (IS MÚSP/MDM → CSRÚ) 
3. Interná integrácia - publikovanie údajov do MDM (IS SP → IS MÚSP/MDM) 
4. Interná integrácia - Získanie údaju SP  - BATCH (IS MÚSP/MDM → IS SP)

Pre naplnenie cieľov bude potrebné zabezpečiť služby

• na strane IS MÚSP – prijímanie údajov do MÚSP cez MÚSP ESB (integračnú platformu), kontroly na entitnú, referenčnú a sémantickú integritu a logovanie dátových prenosov. Zároveň sa počíta s tým, že zodpovednosť za údržbu prenosových štruktúr bude zodpovedný rovnako IS MÚSP a jeho produktový tím/biznis vlastníci.
• Na strane agendových systémov - popísané v projekte ŽS7+8 (úprava/tvorba nových aplikačných funkcií, ktoré bude zabezpečovať ako nové dáta, tak i zmeny nad dátami).

5.3.1.2.4 DI-6 (pre ŽS14)

Z pohľadu biznis vrstvy architektúry je téma DI-6 postavená na postavená na ŽS14 – Odchod do dôchodku, pričom biznis logika a proces je popísaný v projekte ŽS14+16 prostredníctvom využitia IS MÚSP, ktorý bude zohrávať rolu centrálneho dátového úložiska/centrálnej databázy údajov.

Ide o:

1. Získanie údajov z CSRÚ (CSRÚ → IS MÚSP/MDM) 
2. Publikovanie údajov do CSRÚ (IS MÚSP/MDM → CSRÚ) 
3. Interná integrácia - publikovanie údajov do MDM (IS SP → IS MÚSP/MDM) 
4. Interná integrácia - Získanie údaju SP  - BATCH (IS MÚSP/MDM → IS SP)

Pre naplnenie cieľov bude potrebné zabezpečiť služby

• na strane IS MÚSP – prijímanie údajov do MÚSP cez MÚSP ESB (integračnú platformu), kontroly na entitnú, referenčnú a sémantickú integritu a logovanie dátových prenosov. Zároveň sa počíta s tým, že zodpovednosť za údržbu prenosových štruktúr bude zodpovedný rovnako IS MÚSP a jeho produktový tím/biznis vlastníci.
• Na strane agendových systémov - popísané v projekte ŽS7+8 (úprava/tvorba nových aplikačných funkcií, ktoré bude zabezpečovať ako nové dáta, tak i zmeny nad dátami).

5.3.1.2.5 DI-7 (pre všetky ŽS)

Z pohľadu biznis vrstvy architektúry je téma DI-7 prierezevou témou, ktorá umožní predvypĺňanie formulárov pre koncové služby naprieč realizovanými ŽS.

Klient/používateľ pristupuje k službám cez komunikačný portál SP (špecializovaný portál SP), pričom sa umožnia viaceré typy podaní – asistované podanie, samoobslužné či multikanálové.

Vstupnou bránou je autentifikácia, ktorá zabezpečuje prístup k službám cez prihlasovanie a získanie používateľského tokenu. Autentifikačný proces využíva IAM SP a Keycloak na vydávanie a validáciu tokenov.

Klient po autentifikácii vypĺňa elektronický formulár pomocou modulu eForm Filler, kde prebieha predvyplnenie údajov a tiež validácia vypĺňaných údajov formulára. Modul eForm Konštruktor (realizovaný v rámci témy Frontend) vytvorí samotné podanie a umožňuje pridávať prílohy, podpisovať dokumenty a následne ich odosielať.

Diagram 6: Celková architektúra DI-7 (predvypĺňanie formulárov)

5.3.1.2.6 DI-8 (integrácia s NCZI pre potreby ŽS8)

Z pohľadu biznis vrstvy architektúry je téma DI-8 postavená na postavená na ŽS8 – Som chorý, mám chorého člena rodiny, pričom biznis logika a proces je popísaný v projekte ŽS7+8. Jadrom témy je priama integrácia s NCZI, ktorý eviduje potrebné údaje (register potrieb starostlivosti) k riadnemu spracovaniu agendy „ošetrovné“ v SP a následnému vyplateniu korektrných dávok OČR.

Diagram 7: Strešný pohľad na architektúru DI-8 (priama integrácia na NCZI)

5.3.1.3 Notifikácie

Notifikačný modul SP je centrálnym komponentom SP, ktorý zabezpečuje funkcionalitu tvorby a doručovania notifikácií. Modul má nasledovné funkcionality: 

• 
  
  • Vytvára notifikácie v jednotnom a  štandardnom formáte, ktorý je použiteľný pre interné účely SP ako aj pre doručovanie prostredníctvom Centrálneho notifikačného modulu (ÚPVS NOTIFY)  
  • Podporuje tvorbu znenia textu notifikácie na základe substitúcie špeciálnych znakov v šablóne 
  • Podporuje funkcionalitu zasielania notifikácií do 
    • komunikačnej schránky klienta SP (Špecializovaný portál SP) 
    • elektronickej schránky občana  (eDESK slovensko.sk) 
    • mobilnej aplikácie SP (push notifikácie) 
  • Spravuje šablóny notifikácií 
  • Poskytuje API pre vytvorenie a zasielanie notifikácií 

Vstupným parametrom služby pre vytvorenie a zaslanie notifikácie je  

• 
  
  • identifikátor šablóny 
  • údajová štruktúra, ktorá je použitá pre substitúciu značiek šablóny 
  • identita adresáta, prípadne kontaktný údaj adresáta (e-mail, telefónne číslo) 
  • komunikačný kanál (nepovinné) 

V prípade, že bola volaná API služba pre vytvorenie a zaslanie sa spúšťa nasledovný proces: 

1. 
   
   1. Notifikačný modul vytvorí správu na základe spojenia šablóny a substitučných údajov 
   2. V prípade že bola do služby dodaná namiesto kontaktných údajov len identita adresáta, notifikačný modul sa pokúsi získať kontaktné údaje z profilu klienta, pričom získa informáciu o preferovaných spôsoboch (kanáloch) doručenia notifikácie. 
   3. Notifikačný modul doručí notifikáciu do Elektronickej schránky klienta na špecializovanom portáli SP 
   4. V prípade, že adresát má aktívnu elektronickú schránku (eDESK slovensko.sk), notifikácia bude doručená rovnako aj tam. 

Notifikačný modul musí podporovať aj hromadnú tvorbu notifikácií. Zároveň bude využívať pre komunikáciu s centrálnym komponentom ÚPVS NOTIFY komponent ÚPVS Proxy (dodaný v rámci REG).  

Pre účely poskytovania notifikácií budú realizované dve skupiny notifikácií: 

• 
  
  • Generické notifikácie pre notifikovanie klienta o stave konania – tieto notifikácie budú využívané pre všetky konania.  
  • Špecializované notifikácie pre účely jednotlivých agend životných situácií 

5.3.1.4 Registratúra

Popis AS IS stavu

Diagram nižšie popisuje proces spracovania podania v podateľni. Podprocesy detailnejšie zobrazujú procesy príjmu listinnej a elektronicky doručenej pošty do Sociálnej poisťovne. Spracovanie prijatých zásielok ďalej prebieha v agendových systémoch SP je špecifické pre konkrétny druh IS SP. Registratúrny systém je úzko prepojený s centrálnym riadením udalostí a stavov ŽS (BPM).

Diagram 8: Biznis proces Podateľňa - Príjem zásielky

Proces odoslania výstupných dokumentov prebieha poštou resp. do elektronickej schránky osoby. Elektronická schránka sa zriaďuje pre fyzické osoby, podnikateľov, právnické osoby, orgány verejnej moci a pre subjekty medzinárodného práva. Elektronické schránky sa zriaďujú na portáli Ústrednom portáli verejnej správy na adrese www.slovensko.sk

Fyzická osoba nie je povinná mať elektronickú schránku aktivovanú na doručovanie. Avšak v prípade, že si ju FO aktivuje na doručovanie, je orgán verejnej moci povinný do nej doručovať úradné rozhodnutie elektronicky. Takéto rozhodnutie je rovnocenné s listinnou formou.

Popis TO BE stavu

Z pohľadu biznis architektúry je zachytených niekoľko scenárov:

Prijímania podaní na strane Sociálnej poisťovne

výkon podnetov ex-offo na strane Sociálnej poisťovne

iný spôsob prijatia podnetu, napr. dátovou alebo procesnou integráciou

Scenár 1: Prijímanie podaní na strane Sociálnej poisťovne

1. 
   
   1. Občan odošle podanie SP (elektronicky alebo listinne).
   2. Elektronické podania odoslané zo špecializovaného portálu SP alebo ÚPVS sú smerované do eDesk schránky Sociálnej poisťovne. ÚPVS zabezpečuje proces doručovania vrátane doručenky pre klienta a uchovávania odoslaných správ.
   3. REG implementuje preberanie biznisových správ z eDesk schránky Sociálnej poisťovne
   4. REG implementuje preberanie technických informácii prislúchajúcich k správe (podpisy, informácie o doručení)
   5. Podanie je v REG zaevidované:
   6. V prípade elektronických podaní automaticky.
   7. V prípade listinných podaní manuálne (Používateľ sociálnej poisťovne spracuje podanie.)
   8. REG zavolá rozhranie BPM modulu pre spustenie hlavného procesu spracovania podania/prípadu
   9. REG spracuje podanie na základe pravidiel registratúrnej politiky a vytvorí registratúrny záznam.
   10. REG vykoná transformáciu obsahu do PDF a HTML na základe vizualizácii pre prijatý typ správy a uloží výsledné súbory k záznamu
   11. Ak bude definovaná logika pre automatické zaradenie záznamu do registratúrneho spisu tak registratúra vykoná tento krok (pre nové spisy alebo doplnenie existujúceho spisu na základe correlationID)
   12. Registratúra na základe typu vstupného formulára určí agendu na ďalšie spracovanie
   13. REG odovzdá informácie o podaní (metadáta + URI pre obsah + ID procesu) na agendové spracovanie

Alternatívy:

1. 
   
   1. REG zapíše správu do MQ, odkiaľ si ich preberá konzument
   2. REG volá webové služby BPM/API alebo agendových IS pre odoslanie prípadu

Agendové spracovanie:

Spracovanie pokračuje v agendovom IS, ktorý aktualizuje proces v BPM. Agendový IS zároveň integruje IS REG prostredníctvom generického API rozhrania v následných prípadoch:

1. Získanie metaúdajov o zázname
2. Získanie obsahu podania – registratúrneho záznamu (vrátane príloh, vizualizácii a informácii o podpisoch)
3. Vytvorenie registratúrneho záznamu
4. Vytvorenie registratúrneho spisu
5. Zaradenie záznamu do spisu
6. Preradenie záznamu medzi spismi
7. Zlúčenie spisov (ak bol nesprávne založený nový spis a už existuje predchádzajúci spis)
8. Zmena stavu spisu vrátane uzavretia spisu
9. Zmena priradenia spisu na spracovateľa
10. Zmena iných atribútov spisu (napr. lokalita, postúpenie a pod)
11. Vytvorenie doručovacej úlohy (predmetom zadania REG-2)
12. A iné podľa zákona o registratúre

Agendové IS v rámci spracovania integrujú IS BPM v nasledovných prípadoch:

• Získanie detailov procesu (na základe ID s registratúry)
• Získanie možných prechodov z aktuálneho stavu
• Zmena stavu procesu

Scenár 2: Výkon podnetov ex-offo na strane Sociálnej poisťovne

1. Pracovník SP vykonáva aktivity v agendovom IS
2. Dokumenty prípadu vznikajú v agendovom IS
3. Agendový IS spúšťa hlavný proces v BPM cez integračné rozhranie
4. Agendový IS vytvára registratúrny spis/záznam v IS REG cez integračné API (alternatívne pracovník SP vykonáva kroky manuálne v IS REG cez obrazovku)
5. Vybavenie prípadu je realizované v agendovom IS s priebežnou aktualizáciou BPM procesu a potrebných informácii v IS REG.

Scenár 3: Iný spôsob prijatia podnetu, napr. dátovou alebo procesnou integráciou

1. Podnet je prijatý v agendovom IS (prijatie môže prebiehať prostredníctvom ďalších IS ako napríklad MUSP pre CPDI integrácie alebo EESSI pre medzinárodnú komunikáciu)
2. Agendový IS spracuje prípad
3. Agendový IS spúšťa hlavný proces v BPM cez integračné rozhranie
4. Agendový IS v prípade potreby vytvára registratúrny spis/záznam v IS REG cez integračné API (alternatívne pracovník SP vykonáva kroky manuálne v IS REG cez obrazovku)
5. Vybavenie prípadu je realizované v agendovom IS s priebežnou aktualizáciou BPM procesu a potrebných informácii v IS REG.

Register elektronických formulárov

• ­­Systém IS REG bude udržiavať aktuálne verzie špecifikovaných elektronických formulárov publikovaných na slovensko.sk.
• Pokiaľ príde k aktualizácii sledovaných elektronických formulárov, REG odošle notifikáciu.
• Notifikácia bude konzumovaná agendovými systémami.

5.3.1.5 Monitoring služieb a spätná väzba

V prostredí SP v súčasnosti nedochádza k automatizovanému zberu dát zo zdrojových systémov SP a ich následné vyhodnocovanie a poskytovanie do KAV, v tejto časti sa preto budeme venovať popisu TO BE stavu.

Monitoring služieb pozostáva zo zberu údajov z informačných systémov SP a jeho exportu do centrálneho modulu KAV. Údaje sú zbierané z viacerých zdrojov:

• verejného portálu Sociálnej poisťovne pre zber údajov o návštevnosti
• z procesných aplikačných komponentov SP pre získanie informácií o využívaní elektronických služieb SP a riešení životných situácií
• z komponentu Spätná väzba, ktorý agreguje informácie týkajúcich spokojnosti so službami SP

5.3.2 Prehľad koncových služieb – budúci stav (TO BE):

Tabuľka 19: Prehľad koncových služieb, ktoré budú projektom upravené

Tabuľka 20: Prehľad koncových služieb, ktoré budú projektom zrušené (napr. z dôvodu zlúčenia služieb)

Tabuľka 21: Prehľad nových koncových služieb

5.3.3 Organizačné zmeny a Procesy dotknuté navrhovaným riešením

5.3.3.1 Frontend a Registratúra

Vytvorenie žiadostí a oznámení a ich podpísanie asistovane na pobočke

Z pohľadu Frontendu a Registratúry je v súčasnosti možné podať žiadosť listinne alebo elektronicky pre vybrané druhy služieb Sociálnej poisťovne. Hlavnou procesnou a organizačnou zmenou bude podanie asistovanej žiadosti, ktorá bude využívaná najmä pre službu Žiadosť o dôchodok. Súčasný stav neumožňuje vytvárať elektronické žiadosti na pobočke. 

Pokryté žiadosti:

• Žiadosti o dôchodky - predčasný dôchodok, starobný dôchodok, vdovský/vdovecký dôchodok, sirotský dôchodok, invalidný dôchodok 
• Žiadosti o zmenu a oznámenia - poukazovanie a ukončenie poukazovania dôchodkových dávok, zrušenie výplaty na účet, oznámenie / doplnenie údajov a zmeny údajov, žiadosti o zvýšenie a uvoľnenie výplaty, zmeny údajov klienta,
•  Iné žiadosti a oznámenia 
• Odvolanie 

V súčasnom stave sú žiadosti o dôchodok na pobočke realizované v rámci aplikácii ŽoD I a ŽoD II (AIS DP) a to manuálnym vypĺňaním zamestnancom pobočky SP. Klient SP, v ktorého mene je žiadosť pripravovaná, poskytuje údaje a podklady do žiadosti.  Spracovanie ŽoD môže trvať aj niekoľko dní, v závislosti od miery chýbajúcich informácii a potreby doplnenia a získania od klienta. Prípadné prílohy a ďalšie dokumenty sú poskytované len listinne a kopírované, žiadna forma digitalizácie sa nevykonáva. V prípade potreby preverenia údajov v rámci SP ich zamestnanec kontroluje pomocou iných modulov AIS DP a prípadne aj v IS JVP. Pre ŽoD II tvoria vstupy údaje z ďalších agendových  systémov.

Komplexné riešenie pokrýva proces žiadosti:

1. Identifikácia poistenca 
2. Obsahové vyplnenie žiadosti 
3. Digitalizácia papierových podkladov

1. Podpísanie žiadosti – predmetom predkladaného projektu ŽS14+16

1. Odoslanie žiadosti 

1. Spracovanie žiadosti 

Po spísaní žiadosti o dôchodok je táto vytlačená a podpísaná klientom. Zamestnanec pobočky SP ju spolu s prílohami odosiela poštou na ústredie SP na ďalšie spracovanie. V rámci aplikačnej architektúry je zároveň zo systémov ŽoD I a ŽoD II odoslaná dátová veta do IS DP na spracovanie, doručenie listinného podanie ide paralelne a nezávisle. 

Podpísanie žiadosti

Keďže žiadosť bude vytvorená a vyplnená v elektronickej forme, je nevyhnutné „vylúčiť“ jej tlač a následnú „opätovnú“ digitalizáciu. Podpísanie resp. autorizácia žiadosti bude realizovaná ako vlastnoručný podpis v digitalizovanej forme prostredníctvom HW zariadenia (tablet). Takýto podpis zabezpečí atribúty obyčajného vlastnoručného podpisu a celý proces vytvorenia, vyplnenia a autorizácie žiadosti bude reflektovať nevyhnutné podmienky pre platnosť takto realizovaného právneho úkonu (podanie žiadosti) a to: 

• Zachytenie obsahu právneho úkonu; 

• Zachytenie osoby, ktorá daný úkon urobila; 

• Podpis konajúcej osoby – spojený s dokumentom. 

Podmienkou teda je, aby bolo zariadenie (tablet) k dispozícii pre klienta, a zobrazovalo resp. vizualizovalo vytvorenú žiadosť/formulár ako celok. V spodnej časti žiadosti, v priestore pre podpisy, klient žiadosť podpíše špeciálnym perom priamo na obrazovku, pričom takto realizovaný vlastnoručný podpis bude spojený s daným dokumentom.

Nový formulár pre asistované vyplnenie žiadosti bude jediným používateľským rozhraním, ktorý sa bude v budúcom stave používať na pobočke pre vyplnenie žiadosti o dôchodok. Nový formulár nahradí stávajúce rozhranie aplikácie AIS DP(ŽOD I) aj rozhranie aplikácie AIS DP(ŽOD II). Nové rozhranie teda musí komplexne pokryť všetky oblasti, ktoré je treba vyplniť v žiadosti o dôchodok. 

Diagram 9:  Vytvorenie žiadostí a oznámení a ich podpísanie asistovane na pobočke TO BE

5.3.3.2 Monitoring služieb a spätná väzba

Z pohľadu monitoringu a spätnej väzby je nevyhnutné zabezpečiť integračné služby systému MUSP s agendovými systémami SP tak, že bude poskytovať nasledovné štandardné služby pre integráciu s agendovými systémami:

• DZ SP pripraví službu, ktorú vystaví na MÚSP ESB a ktorá prijme údaje z agendového systému v dohodnutej štruktúre. Na základe analýzy potrieb a záverečného návrhu riešenia bude určený typ služby a spôsob prenosu údajov.
• MÚSP údaje z databázy agendového systému zapíše do pripravených štruktúr CDÚ
• Dôležité: Je nevyhnutné, aby MÚSP spracovával prijaté údaje systematicky a štruktúrovane, nesmie sa sústrediť len na parciálne riešenie s ohľadom na aktuálnu požiadavku, ale aj s prihliadnutím na možnosť dlhodobého rozširovanie objektu evidencie pre rôzne účely a služby. Uložené údaje musia byť logicky štruktúrované tak, aby umožňovali efektívne vytváranie datasetov pre ďalšie požiadavky iných OVM alebo interných systémov SP teraz aj v budúcnosti.
• MÚSP vypracuje dokumentáciu podľa štandardov IT vo verejnej správe k prenosu vrátane popisu dát, dátových štruktúr, funkcií, schém architektúry a zdrojových kódov, vrátane dokumentácie zrealizovaných testov
• MÚSP vykoná základné automatické kontroly na entitnú, referenčnú a sémantickú integritu. Prípadné vady zapíše do špeciálnej štruktúry zistených vád a sprístupní pre agendový systém
• Samostatný údržbový job na strane MÚSP bude prenosové štruktúry udržiavať, t.j. expirované a spracované dáta budú periodicky odmazávané, predbežne navrhnutý na 10 mesačný retention interval
• Validácia dát a oprava / navrátenie dát pri zistených chybách v dátach.
• DZ SP pripraví služby, ktoré poskytnú údaje z CDÚ MÚSP v dohovorenej štruktúre podľa žiadaných parametrov
• Všetky dátové prenosy medzi systémami budú logované v štandardnom formáte (čas prenosu / volania, typ prenosu, veľkosť dát, úspešnosť spojenia, úspešnosť spracovania, zápis chybových hlásení, atď.) a ukladané.

Zároveň je nevyhnutná úprava na strane agendových systémov tak, aby každý z nich spĺňal nasledovné: 

• Agendový systém pripraví podklady (údaje) pre službu, ktorú vystaví MÚSP ESB v rozšírenej dátovej štruktúre
  • Existujúca dátová štruktúra ostáva zachovaná
  • Rozšíri údajovú štruktúru na základe definovaných požiadaviek
  • Zohľadniť cieľový stav Q1 2026
• Agendový systém upraví existujúce/prispôsobí/vytvorí nové aplikačné funkcie, ktoré budú zabezpečovať ako aj nové dáta, tak aj zmeny nad dátami
• Agendový systém dôkladne otestuje a odladí integráciu na svojej strane
• Agendový systém poskytne súčinnosť pri ladení služieb MÚSP
• Agendový systém vypracuje úplnú dokumentáciu podľa štandardov IT vo verejnej správe k prenosu vrátane popisu dát, dátových štruktúr, funkcií, schém architektúry a zdrojových kódov; vrátane dokumentácie zrealizovaných testov
• Agendový systém prijme a spracuje údaje zo zistených vád, overí ich, opraví a zašle ich v najbližšom volaní

Bližšie je proces znázornený v časti 5.4.1.5  Aplikačná vrstva – Monitoring.

5.3.4 Jazyková podpora lokalizácia

5.4 Aplikačná vrstva

5.4.1 Návrh riešenia v aplikačnej vrstve architektúry

5.4.1.1 Frontend

Popis AS IS stavu

Aplikačné riešenia prevádzkované v rámci IS SP svojimi funkciami podporujú prakticky všetky procesy súvisiace s výkonom sociálneho poistenia a vnútornou správou inštitúcie. Charakteristické je, že jednotlivé systémy vznikali v rôznych obdobiach a podmienkach (dodávateľské aplikácie „na kľúč“, prevzaté aplikácie delimitované z Národného úradu práce, vlastný aplikačný vývoj).

V rámci sociálneho poistenia a životných situácií SP využíva viaceré informačné systémy verejnej správy -

• IS Manažment údajov Sociálnej poisťovne (IS_MÚSP) - isvs_8729,
• IS starobného dôchodkového sporenia (SDS) - isvs_555,
• Systém elektronických služieb (SES) - isvs_551,
• IS výberu poistného a príspevkov (JVP) - isvs_545,
• IS úrazového poistenia (UP) - isvs_549,
• IS poistenia v nezamestnanosti a garančného poistenia (PvN a GP) - isvs_550,
• IS dôchodkového poistenia (DP) - isvs 546;
• Elektronický účet poistenca ako súčasť IS SES / EKP - isvs_551,
• Automatizovaný systém správy registratúry (ASSR) - isvs_8124,
• Ďalšie.

Diagram 10: Najvýznamnejšie komponenty SP z pohľadu riešení a funkcionalít Frontendu – AS IS

Elektronický účet poistenca ako súčasť IS SES / EKP je súčasná aplikácia SP, ktorá je identifikovaná ako kľúčový systém Frontendu SP:

Elektronický účet poistenca EÚP obsahuje

Prehľady v rámci agendy EÚP:

• Výber poistného

• Individuálny účet poistenca - Informácia o zmenách stavu individuálneho účtu poistenca (údaje o obdobiach poistenia, vymeriavacích základoch a osobných mzdových bodoch)
• Poistenie platené štátom - prehľad o poistení v prípade platenia štátom
• Prehľad poistení - Zobrazenie období, počas ktorých bol poistenec prihlásený na sociálne poistenie.
• Vylúčenia - obdobie, kedy sa poistenie neplatí
• Prerušenia - obdobie kedy sa sociálne poistenie prerušilo

• Dôchodkové poistenie

• Rodičovský dôchodok
• Informatívna suma dôchodku
• Príprava na dôchodok – Sprievodná informácia, Neevidované obdobia, Evidované obdobia, Prehľad zamestnávateľov
• Obdobia dôchodkového poistenia
• Určenie dôchodkového veku
• Prehľad vyplatených dôchodkových dávok

• Nemocenské poistenie

• Obdobia nemocenského poistenia
• ePN – Elektronická práceneschopnosť
  • 
    
    • prehľad o vystavenej ePN lekárom
    • stav konania o nároku na nemocenské pri ePN
    • spôsob výplaty nemocenského pri ePN – poistenec môže zaslať priamo k ePN  formulár „Spôsoby výplaty nemocenského pri ePN“
    • V prípade ePN z dôvodu úrazu môže poistenec zaslať priamo k ePN  formulár „Hlásenie úrazu“
• Prehľad vyplatených nemocenských dávok

• Úrazové poistenie

• Prehľad - konania o úrazových dávkach  a ich výplatách, formuláre pre agendu ÚP

• Účasť v II. pilieri

• Výpis z registra zmlúv DSS

• Poistenie v nezamestnanosti

• Obdobia poistenia v nezamestnanosti
• Prehľad – konanie o dávke v nezamestnanosti
  • 
    
    • žiadosť
    • priebeh konania
    • výsledok konania
    • stav žiadosti
• Prehľad o vyplatenej dávke v nezamestnanosti

• Výpis z EUP TLAČ

• Vytvorenie tlačovej zostavy výpisu EUP s možnosťou tlače
• Evidencia doručenia Výpisu z EUP

Na nasledujúcom obrázku je v základnom rozsahu schematicky zobrazená elektronická komunikácia voči ostatným informačným systémom a skupinám používateľov:

Diagram 11:  Aplikačná architektúra EKP - AS IS

Popis TO BE stavu

Rozvoj oblasti Frontend je zameraný na vybudovanie nových elektronických služieb orientovaných na pokrytie prioritných ŽS a vybudovanie privátnej časti portálu pre klienta SP. Cieľom projektu je eliminovať vysokú frekvenciu papierových podaní a ich spracovania, optimalizácia procesných činností, elektronická komunikácia s klientom SP, zobrazovanie základných a agendových údajov klienta na jednom mieste a zabezpečenie elektronického obehu dokumentov. Riešenia a funkcionality Frontendu sú súčasťou podpory procesov sociálneho poistenia tým, že poskytuje funkcie na manipuláciu s informáciami  a dokumentmi a ich poskytovanie zamestnancom SP a pre ostatné systémy SP. Sám teda nie je agendovým systémom, ale technickou platformou pre ostatné agendové systémy.

V rámci budúceho stavu aplikačnej architektúry sú definované aplikačné funkcie v dvoch oblastiach:

1. Aplikačné funkcie, ktoré realizujú služby pre externého používateľa – Klienta. Klient SP bude primárne pristupovať k službám z internetu prostredníctvom webového prehliadača. Pre mobilné zariadenia je podstatný responzívny dizajn.

1. Aplikačné funkcie určené pre podporu interných procesov rozhodovania pri vybavovaní agendy SP. Táto funkcionalita je určená pre interných zamestnancov SP a bude vystavená aj prostredníctvom API pre potreby integrácie frontendu s internými informačnými systémami SP.

Aplikačné funkcie budú realizované novými, alebo existujúcimi informačnými systémami SP. Nasledujúci zoznam definuje logické komponenty aplikačnej architektúry a rozdeľuje ich do funkčných domén.

•  Používateľské rozhranie
  •  Interný portál SP
  •  Verejný portál -
    • časť Verejný obsah
    • časť Privátny obsah
• Autentifikácia a autorizácia
  • Externé IAM
  • Interné IAM
  • Zastupovanie
• Integrácia
  • API Gateway
  • ESB
• Poskytovanie informácií, údajov a dokumentov
  • Content management system
  • DMS
  • Master data management
• Riadenie procesov ŽS / Služieb SP
  • Business process management
  • BRE (Business rule system)
  • Rezervačný systém
  • Register ŽS / Služieb SP
  • Schránka klienta
  • Konštruktor podaní
• Zložka / Profil klienta
  • Moje údaje
  • Moje dokumenty
  • Môj účet

Logické komponenty riešenia budú ďalej mapované na fyzické aplikačné komponenty.

Dôležitým komponentom riešenia je komponent Register životných situácií / Služieb SP. Ten je tvorený nasledovnými subkomponentmi:

• register životných situácií,
• register služieb SP a
• register e-formulárov (lokálny register eForm)

Register životných situácií

Register životných situácií je metainformačný register, ktorý definuje

• aké životné situácie sú aktívne a dostupné klientom SP a
• metaúdaje k ŽS:
  • identifikácia a definícia ŽS,
  • kroky ŽS, ktoré  zabezpečuje SP a akým spôsobom:
    • automatickým získaním objektu evidencie z MDM
    • elektronickou službou SP
    •  listinne

Register služieb SP je metainformačný register, ktorý definuje

• aké služby sú aktívne a dostupné klientom SP
• metaúdaje k službám:
  • identifikácia a definícia služby
  • možnosť elektronického podania
  • prílohy k e-formulárom služby
  • nutnosť autorizácie a pod.

Register e-formulárov zabezpečuje poskytovanie vzorov formulárov registrovaných v centrálnom module ÚPVS eFORM. Vzory e-formulárov sa poskytujú najmä za účelom získania definícií a vizualízácií e-formulárov.

Diagram 12: Aplikačná architektúra Frontend - TO BE

Aplikačné komponenty Moje údaje, Môj účet a Moje dokumenty realizujú biznisovú funkcionalitu frontendu:

• Všeobecné údaje poistenca (Moje údaje)
• Individuálny účet poistenca (Môj účet) a
• Vstupné a výstupné elektronické dokumenty poistenca (Moje dokumenty)

Tieto funkcionality sú dostupné pre autentifikovaného klienta SP z internetu, prostredníctvom webového prehliadača.

Aplikačná architektúra týchto komponentov je viacvrstvová, čo znamená, že je tvorená

• front-endovou vrstvou a
• back-endovou vrstvou

Front-endová vrstva reprezentuje grafické používateľské rozhranie, ktorá je zakomponovaná do komponentu Verejný portál – privátna časť. Znamená, to že k tejto funkcionalite má prístup len autentifikovaný a autorizovaný klient SP.

Back-endová vrstva zabezpečuje poskytovanie agregovaných údajov o klientovi. Tieto údaje sú získavané z komponentu Master data management.

Nasledovný obrázok predstavuje aplikačnú architektúry vrstvu komponentov Moje údaje, Môj účet a Moje dokumenty.

Diagram 13: Aplikačná  architektúra Frontendu - Moje dáta, Moje údaje, Moje dokumenty - TO BE

Aplikačný komponent Konštruktor podania realizuje biznisovú funkcionalitu Frontendu:

• Elektronické formuláre, žiadosti a sťažnosti (e-formuláre)

Funkcionalita komponentu je dostupná z internetu, prostredníctvom webového prehliadača v dvoch variantoch:

• čiastočná funkcionalita pre neautentifikovaného klienta SP pre možnosť vyplnenia elektronického formuláru a jeho následného vytlačenia do listinnej podoby pre účely listinného doručenia. a pre
• plná funkcionalita pre autentifikovaného používateľa pre možnosť  vyplnenia elektronického formuláru, priloženia príloh k podaniu, autorizácie a odoslania podania.

Aplikačná architektúra týchto komponentov je viacvrstvová, čo znamená, že je tvorená

• front-endovou vrstvou a
• back-endovou vrstvou

Front-endová vrstva reprezentuje grafické používateľské rozhranie, ktoré je zakomponované do komponentu Verejný portál. Je potrebné zabezpečiť, aby uvedená funkcionalita bola dostupná pre anonymných ako aj autentifikovaných používateľov.

Back-endová vrstva zabezpečuje funkcionality:  vyplnenie elektronického formulára, pridanie príloh k e-formuláru, autorizácia podania, odoslanie podania.

Diagram 14: Aplkačná architektúra Frontend - Konštruktor podania – TO BE

Modernizácia mobilnej aplikácie SP pre potreby ŽS5

Z pohľadu aplikačnej architektúra zahŕňa Mobilná aplikácia dve kľúčové aplikačné integrácie. Jednotlivé časti systému sú medzi sebou prepojené integračnými rozhraniami:

Integračné REST API pre komunikáciu medzi mobilnou aplikáciou a administračným back-end systémom je predmetom samostatnej prílohy.

Z pohľadu technologickej vrstvy je mobilná aplikácia samostatne stojacim riešením, ktoré sa integruje na iné existujúce komponenty.

Rezervačný systém

Výstupom bude funkčný a prevádzkovaný rezervačný systém so všetkými implementovanými požiadavkami na systém. 

Rezervačný systém musí ukladať všetky historické údaje o všetkých vykonaných rezerváciách (pre sledovanie maximálneho možného počtu rezervácií, prípadne pre účely blokácie osoby na určité obdobie pri nedostavení sa na termín). 

Tiež je potrebné zabezpečiť integráciu medzi rezervačným a vyvolávacím systémom prostredníctvom vytvorených služieb vyvolávacieho systému. Predpokladom je, že v čase implementácie rezervačného systému je existencia vyvolávacieho systému. Vyvolávací systém je možné samostatne používať bez rezervačného systému. Rezervačný systém však bez prevádzky vyvolávacieho systému nie je vhodné prevádzkovať, lebo by rezervované termíny nemohli byť bez zvýšenej administratívnej záťaže zamestnancov SP vybavené. 

Systém zabezpečí a sleduje maximálny počet odoslaných rezervácií pre osobu na jednu lokalitu ako aj celkovo v priebehu určitého počtu kalendárnych dní (kontrola na meno, priezvisko, doklad totožnosti, telefónne číslo, email prípadne ich vzájomná kombinácia). Jedna osoba si nemôže v čase rezervovať viacero termínov. Jedna osoba nemôže v rámci definovaného obdobia rezervovať viacej ako je maximálny povolený počet rezervácií nastavených v administrácií systému. 

Systém umožní odosielať pripomienky pred termínom formou emailovej notifikácie / SMS o rezervovanom termíne x dní pred termínom (nastavenia v administrácií systému). 

Systém zabezpečí zbieranie poskytnutých súhlasov s poskytnutím osobných údajov a bude zabezpečovať automatickú kontrolu a mazanie údajov, ktorým uplynula platnosť. 

Dotknuté komponenty 

Rezervačný systém bude integrovaný na vyvolávací systém, webové sídlo SP a špecializovaný portál: 

• Rezervačný systém bude posielať údaje o dostupných termínoch pre vybranú agendu a lokalitu na webové sídlo Sociálnej poisťovne. Webové sídlo bude odosielať informácie o osobe, ktorá si chce rezervovať si termín, rezervačný systém následne odošle informácie o možnosti rezervácie alebo zamietnutí rezervácie s uvedením dôvodu. Webové sídlo v prípade dokončenej registrácie odošle rezervačnému systému údaje o vytvorenej rezervácií. 

• Rezervačný systém bude posielať údaje o dostupných termínoch pre vybranú agendu a lokalitu na špecializovaný portál. Špecializovaný portál bude odosielať informácie o osobe, ktorá si chce rezervovať si termín, rezervačný systém následne odošle informácie o možnosti rezervácie alebo zamietnutí rezervácie s uvedením dôvodu. Špecializovaný portál v prípade dokončenej registrácie odošle rezervačnému systému údaje o vytvorenej rezervácií. 

• Webové sídlo bude odosielať rezervačnému systému na základe vyplnených údajoch žiadosť o overenie platnej rezervácie a rezervačný systém odošle na webové sídlo potvrdenie resp. zamietnutie platnej rezervácie. 

• Špecializovaný portál bude odosielať rezervačnému systému na základe vyplnených údajoch žiadosť o overenie platnej rezervácie a rezervačný systém odošle na špecializovaný portál potvrdenie resp. zamietnutie platnej rezervácie. 

Diagram 15: Rezervačný systém TO BE

Vytvorenie služby zabezpečenej komunikácie

Služby

Rezervácia online termínu cez webové sídlo SP (neautentifikovaný používateľ) 

Klient (neautentifikovaný používateľ) si bude môcť rezervovať online termín zabezpečenej komunikácie prostredníctvom samostatnej služby na webovom sídle SP. Po vyplnení údajov o svojej osobe (minimálne meno, priezvisko, dátum narodenia, email a telefónne číslo), údaje potvrdí ochranným prvkom (Captcha). Systém overí, či používateľ si môže rezervovať termín na základe podmienok používania¹ zabezpečenej komunikácie. Po výbere dňa prostredníctvom kalendára systém zobrazí dostupné termíny pre zvolený deň a používateľ si zvolí konkrétny čas. Používateľ musí pred odoslaním rezervácie online termínu kliknúť na Súhlasím so spracovaním osobných údajov za účelom vybavenia požiadavky s možnosťou odkliku na informácie uvedené v súbore alebo webovej stránke (text súhlasu ako aj podmienky spracovania bude možné meniť podľa potreby). 

Systém po potvrdení online termínu odošle o rezervovanom online termíne na emailovú adresu notifikáciu s udalosťou a s ID schôdze do kalendára, ktorú si môže používateľ importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o rezervovanom online termíne formou SMS. 

 Rezervácia online termínu na špecializovanom portáli (autentifikovaný používateľ) 

Klient (autentifikovaný používateľ – používateľ musí byť prihlásený) si bude môcť rezervovať online termín zabezpečenej komunikácie prostredníctvom samostatnej služby na špecializovanom portáli. Systém v prípade autentifikovaného používateľa predvyplní údaje o používateľovi (meno, priezvisko, dátum narodenia) na špecializovanom portáli.  Používateľ doplní email a telefónne číslo (ak údaje nemá vyplnené v profile) a potvrdí správnosť údajov. Systém overí, či používateľ si môže rezervovať online termín na základe podmienok používania zabezpečenej komunikácie. Po výbere dňa prostredníctvom kalendára systém zobrazí dostupné termíny pre zvolený deň a používateľ si zvolí konkrétny čas. Používateľ musí pred odoslaním rezervácie online termínu kliknúť na Súhlasím so spracovaním osobných údajov za účelom vybavenia požiadavky s možnosťou odkliku na informácie uvedené v súbore alebo webovej stránke (text súhlasu ako aj podmienky spracovania bude možné meniť podľa potreby). 

Systém po potvrdení rezervácie online termínu odošle o rezervovanom online termíne na emailovú adresu notifikáciu s udalosťou  a s ID schôdze do kalendára, ktorú si môže používateľ importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o rezervovanom online termíne formou SMS. Systém automaticky vloží rezervovaný online termín  s ID schôdze do kalendára na špecializovanom portáli (v prípade existencie na špecializovanom portáli). 

 Rezervácia online termínu zamestnancom SP (GUI pre zamestnanca SP) 

Zamestnanec SP bude môcť vytvoriť samostatnú online rezerváciu voľného termínu pre klienta prostredníctvom GUI rozhrania pre zamestnanca SP (rovnaké GUI ako pre rezervačný systém). Zamestnanec vyplní potrebné údaje o klientovi, vyberie vhodný deň a voľný termín. Systém overí, či klient si môže rezervovať online termín na základe podmienok používania online zabezpečenej komunikácie. 

Systém po potvrdení online rezervácie odošle údaje o rezervovanom online termíne na emailovú adresu notifikáciu s udalosťou do kalendára, ktorú si môže používateľ importovať do svojho kalendára a tiež na telefónne číslo klienta informácie o online rezervovanom termíne formou SMS. 

Klient prostredníctvom odoslanej online rezervácie musí potvrdiť takto online rezervovaný termín (napr. formou kliknutia na potvrdzovací link). Bez takéhoto potvrdenia je termín online rezervovaný len určitý čas a ak termín nebude klientom potvrdený do určitého času, opätovne sa tento termín stane voľným. Zároveň bude v texte uvedené, že potvrdením zároveň súhlasí so spracovaním osobných údajov za účelom online rezervácie termínu. 

 Overenie online rezervácie cez webové sídlo SP (neautentifikovaný používateľ) 

Systém umožní overiť pre neautentifikovaného klienta platnú online rezerváciu na webovej stránke po vyplnení potrebných informácií na webovej stránke Sociálnej poisťovne. 

 Overenie online rezervácie na špecializovanom portáli (autentifikovaný používateľ) 

Systém umožní vidieť online rezervované termíny pre autentifikovaného používateľa na špecializovanom portáli. Aj autentifikovaný používateľ stále môže využiť služby neautentifikovaného používateľa. 

 Zrušenie potvrdenej online rezervácie 

Systém umožní klientovi zrušiť jeho online rezervovaný termín v prípade potreby napr. kliknutím na linku v emailovej notifikácií o potvrdení online termínu alebo zaslaním spätnej SMS v definovanom tvare, prípadne cez funkcionalitu zrušenia na špecializovanom portáli. Vygenerovaný odkaz/sms bude v sebe obsahovať informácie o konkrétnej online rezervácií, ktorý zabezpečí zrušenie tohto termínu a jeho uvoľnenie. 

 Zmena zamestnanca SP potvrdenej online rezervácie 

Systém umožní administrátorovi (napr. vedúci pobočky) preobsadiť už zarezervovaný online termín iným zamestnancom SP (napr. v situácií, kedy systémom pôvodne na schôdzku zamestnancovi priradenú a zamestnanec ochorie). 

 Štatistiky využívania systému (GUI pre zamestnanca SP) 

Systém musí ukladať všetky historické údaje o všetkých online rezerváciách komunikačného prostredia vrátane zrušených a poskytovať štatistické údaje o počte uskutočnených rezervácií podľa agendy a lokality v čase vrátane historických údajov, doby čakania a doby vybavenia (parametrické vyhľadávanie všetkých uložených údajov – presný výraz, obsahuje, začína, končí; a; alebo; zoraďovanie; filtrovanie; exportovanie; tlačové zostavy). 

Systém poskytne údaje o všetkých budúcich online rezerváciách pre konkrétne pobočky, agendové pracoviská pre účely plánovania. 

Systém zároveň poskytne aktuálne údaje vyťaženosti pobočiek, agendových pracovísk, údaje o priemernej dĺžke čakania, vybavenia. 

 Administrácia systému (GUI pre administrátora) 

Administrátor alebo iná osoba (napr. vedúci pobočky) na základe pridelených práv bude môcť realizovať nastavenie a parametrizáciu online komunikačného prostredia. Nastavenie bude možné nastaviť na celú zabezpečenú komunikáciu online komunikačného prostredia, ako aj konkrétnu lokalitu, prípadne agendu. Bude môcť vykonať minimálne nasledovné nastavenia: 

• správa používateľov pre definovanie prístupových oprávnení; 

• správa a definovanie dostupných agend pre online komunikáciu; 

• správa a definovanie voľných termínov pre konkrétne agendy, definovanie dĺžky trvania úkonu, vybraných hodín; 

• generovanie kalendára voľných termínov na základe zadaných parametrov na určité obdobie (počet, dĺžka trvania, pracovné dni atď.); 

• správa a zmena (preobsadenie) zamestnanca SP v prípade jeho neprítomnosti; 

• úprava voľných termínov kalendára na základe potreby; 

• definovanie počtu dní pre odoslanie pripomienky pre vybraným termínom; 

• nastavenie overovania osoby (overenie cez email alebo telefónne číslo, prípadne obidve možnosti overenia osoby); 

• definovanie Súhlasu so spracovaním osobných údajov s možnosťou prelinkovania na webovú adresu alebo externý súbor; 

• maximálna doba pre potvrdenie rezervácie vytvorenej zamestnancom SP; 

• maximálna dĺžka blokácie osoby; 

• parametre blokácie a ďalšie. 

 Zabezpečená komunikácia 

Riešenie zabezpečí a sleduje maximálny počet odoslaných online termínov pre osobu na jednu lokalitu ako aj celkovo v priebehu určitého počtu kalendárnych dní (kontrola na meno, priezvisko, doklad totožnosti, telefónne číslo, email prípadne ich vzájomná kombinácia). Jedna osoba si nemôže v čase rezervovať viacero online termínov.  

Riešenie umožní odosielať pripomienky/notifikácie pred online  termínom formou emailovej notifikácie / SMS o rezervovanom online termíne x dní pred termínom (nastavenia v administrácií systému). 

Riešenie zabezpečí zbieranie poskytnutých súhlasov s poskytnutím osobných údajov a bude zabezpečovať automatickú kontrolu a mazanie údajov, ktorým uplynula platnosť. 

Pre platné rezervácie a vytvorené schôdze (ID schôdze vytvára služba zabezpečenej online komunikácie) riešenie umožní zrealizovať online zabezpečenú komunikáciu v danom čase -  pohodlnú a bezpečnú realizáciu vzdialených on-line schôdzok medzi klientom, ktorý je žiadateľ o dôchodok a zamestnancom SP (prípadne aj pre iné agendy).  

Overenie klienta môže prebehnúť na samotnej online schôdzi vyžiadaním si relevantných údajov klienta (spôsob a pravidlá overenia si stanoví SP). 

Dotknuté komponenty 

Online zabezpečená komunikácia (ako služba SaaS) bude komunikovať s AZURE tenante  SP a na samotné rezervácie bude využitý paralelne budovaný Rezervačný systém. Služby rezervácie budú realizované prostredníctvom webového sídla SP a špecializovaného portálu (EKP/EÚP): 

• Rezervačný systém bude posielať údaje o dostupných online termínoch pre vybranú agendu a lokalitu na webové sídlo Sociálnej poisťovne. Webové sídlo bude odosielať informácie o osobe, ktorá si chce rezervovať online termín, rezervačný systém následne odošle informácie o možnosti online rezervácie alebo zamietnutí online rezervácie s uvedením dôvodu. Webové sídlo v prípade dokončenej registrácie odošle rezervačnému systému údaje o vytvorenej online rezervácií. 

• Rezervačný systém bude posielať údaje o dostupných online termínoch pre vybranú agendu a lokalitu na špecializovaný portál. Špecializovaný portál bude odosielať informácie o osobe, ktorá si chce rezervovať online termín, rezervačný systém následne odošle informácie o možnosti online rezervácie alebo zamietnutí online rezervácie s uvedením dôvodu. Špecializovaný portál v prípade dokončenej registrácie odošle rezervačnému systému údaje o vytvorenej online rezervácií. 

• Webové sídlo bude odosielať rezervačnému systému na základe vyplnených údajoch žiadosť o overenie platnej online rezervácie a rezervačný systém odošle na webové sídlo potvrdenie resp. zamietnutie platnej online  rezervácie. 

• Špecializovaný portál bude odosielať rezervačnému systému na základe vyplnených údajoch žiadosť o overenie platnej online rezervácie a rezervačný systém odošle na špecializovaný portál potvrdenie resp. zamietnutie platnej online rezervácie. 

Údaje z online zabezpečenej komunikácie a z rezervačného systému sú na pobočkách a u klientoch synchronizované. 

Diagram 16: Služba zabezpečenej elektronickej komunikácie TO BE

5.4.1.2 Dátové integrácie

5.4.1.2.1 DI-2 (pre ŽS1)

​​​​​​​

DI-2 je zameraná na poskytovanie a konzumáciu údajov spojených s dávkou v nezamestnanosti a jej korektným vyplácaním berúc ohľad na iné dávky, ktoré môžu mať vplyv na vyplácanie dávky v nezamestnanosti (napr. dávka v hmotnej núdzi, rodičovský príspevok) – viď Tabuľka 16. samostatným datasetom, ktorý je nástrojom proaktivity zo strany SP a MPSVaR sú kandidáti na zaradenie/vyradenie z evidencie uchádzačov o zamestnanie.

Tabuľka 22: Prehľad datasetov a ich integračných vyťahov v DI-2

Diagram 17: Celková architektúra DI-2

Získanie údajov z CSRÚ (CSRÚ → IS MÚSP)

1. IS MÚSP zabezpečí rozšírenie získavaných dát z CSRÚ o nasledovné objekty evidencie:
   1. 
      
      1. (ŽS1_BP_61), (ŽS1_BP_41):
         1. (ŽS1_BP_61) Dataset „Zaradenie do evidencie UoZ spolu so žiadosťou o DvN“ z ÚPSVAR pre automatické začatie konania o nároku na dávku v nezamestnanosti (cca. 98% žiadostí)
         2. (ŽS1_BP_61) Dataset „Zaradenie do evidencie UoZ bez žiadosti o DvN“ z ÚPSVAR pre začatie konania o nároku na dávku v nezamestnanosti pri proaktívnej žiadosti o DvN od občana podanej v SP (cca. 2% žiadostí)
         3. (ŽS1_BP_61) Dataset „Vyradenie z evidencie UoZ“ z ÚPSVAR pre účely zastavenia vyplácania dávky nezamestnanosti, ako aj pre evidenciu v systéme JVP
         4. (ŽS1_BP_41) Dataset „Zmeny v evidencii UoZ“ z ÚPSVAR pre evidenciu v systéme JVP

• MÚSP bude konzumovať všetky datasety ohľadom evidencie UoZ publikované od MPSVR v CSRÚ.
• Všetky 4 spomenuté typy datasetov budú reprezentované jediným štandardným datasetom, ktorého použitie bude určené atribútom špecifikujúcim typ datasetu.
• Altrernatívne riešenie: Nerealizovať rozšírenie datasetu a ponechať existujúcu priamu integráciu prostredníctvom XML súborov prenášaných z CPDI (CSRÚ) → Úložisko SP → PvNGP, JVP

• 
  
  1. 
     
     1. (ŽS1_BP_61):
        1. Zúčtovanie dávky v hmotnej núdzi z ÚPSVaR pre účely zúčtovania dávky v nezamestnanosti s pomocou v hmotnej núdzi.
• MÚSP zabezpečí získavanie predmetného datasetu z CPDI a jeho poskytovanie pre agendové systémy SP.
  1. 
     
     1. 
        
        1. Rodičovský príspevok (Zmeny v rodičovskom príspevku) z ÚPSVaR pre účely zastavenia vyplácania dávky v nezamestnanosti z dôvodu poberania rodičovského príspevku.
• MÚSP bude konzumovať všetky datasety ohľadom RP publikované od MPSVaR v CSRÚ.
• Alternatívne riešenie: Nerealizovať rozšírenie datasetu a ponechať existujúcu priamu integráciu medzi ÚPSVaR a SP (prenos XML súborov medzi úložiskami (SSH) ÚPSVaR a SP a následne spracovanie do PvNGP. (TOKY A a C)

Diagram 18: Získavanie údajov z CSRÚ do MÚSP (MDM)

Diagram 19: Získavanie údajov z CSRÚ - sekvenčný diagram

Publikovanie údajov do CSRÚ (MDM -> CSRÚ)

MÚSP zabezpečí publikovanie nasledovných objektov evidencie / datasetov do CPDI (CSRÚ): 

1. Objekty evidencie za IS JVP definované v kapitolách „DI-2.4 Poskytovanie údajov z IS JVP do MÚSP“ a „DI-2.5 Poskytovanie údajov z IS EKP do MÚSP“  
   1. Pre evidenciu UoZ na ÚPSVaR: 

1. (ŽS1_BP_02b) Kandidáti na zaradenie do evidencie UoZ (Ukončenie pracovného pomeru / sociálneho poistenia) 

1. (ŽS1_BP_028a) Kandidáti na vyradenie z evidencie UoZ (Začiatok pracovného pomeru / sociálneho poistenia) 
   1. (ŽS1_BP_41) Dataset „Pracovno-právne vzťahy“ žiadaný od MPSVR SR 

• MÚSP na základe požiadavky prijatej od MPSVR cez CPDI (CSRÚ) pripraví z údajov poskytnutých z IS JVP výstupný dataset, ktorý obohatí o relevantné údaje poskytnuté z IS EKP a publikuje ho do CPDI (CSRÚ) v požadovanom formáte. Atribút na spárovanie údajov bude predmetom analýzy. 

1. (ŽS1_BP_60) Objekty evidencie za PvNGP založené na definícii v kapitole „DI-2.6 Poskytovanie údajov z IS PvNGP do MÚSP“ 

1. (ŽS1_BP_60) – Zoznam dávok v nezamestnanosti pre zúčtovanie Dávky v hmotnej núdzi 

• Zúčtovanie dávky v nezamestnanosti a dávky garančného poistenia s dávkou v hmotnej núdzi (DHN) poskytovanou ÚPSVaR je súčasťou prierezového konceptu zúčtovania DHN s dávkami Sociálnej poisťovne, ako je definovaný v prílohe „DI - Zúčtovanie DHN (SP-MPSVR).pdf“. Tento nový koncept by mal plne nahradiť a automatizovať existujúcu funkcionalitu, ktorá je v súčasnosti realizovaná priamou integráciou na MPSVR prostredníctvom dvojstranného dátového toku A1N / A2N podľa rámcovej dohody z roku 2009. Akékoľvek zmeny tohoto konceptu je potrebné úzko koordinovať aj s požiadavkami ostatných vecných odborov a životných situácií využívajúcich tento koncept. 
• Jednotlivé agendové systémy vrátane PvNGP budú do MÚSP poskytovať všetky informácie dôležité v súvislosti so zúčtovaním s DHN. 
• MÚSP na základe požiadavky z ÚPSVaR (Dataset „Zoznam dávok SP (Požiadavka)“) obsahujúcej zoznam skúmaných osôb v súvislosti s DHN vytvorí kompletný dataset všetkých dávok poskytovaných v SP pre všetky osoby, ktorých sa to týka, a to za všetky agendové systémy. V prípade, že skúmaná osoba o relevantné zúčtovacie dávky nikdy nepožiadala, tak pre ňu dataset „Zoznam dávok SP“ nebude vytvorený. Detaily procesu sú zachytené v spoločnom koncepte zúčtovania DHN „DI - Zúčtovanie DHN (SP-MPSVR).pdf“. 

Diagram 20: Publikovanie údajov do CSRÚ

Diagram 21: Publikovanie údajov do CSRÚ - sekvenčný diagram

Interná integrácia - publikovanie údajov do MDM (IS SP -> MDM)

Systém MÚSP bude poskytovať nasledovné štandardné služby pre integráciu s agendovými systémami:

• Dátová základňa SP (DZ SP) pripraví službu, ktorú vystaví na MÚSP ESB a ktorá prijme údaje z agendového systému v dohodnutej štruktúre. Na základe analýzy potrieb a záverečného návrhu riešenia bude určený typ služby a spôsob prenosu údajov.
• MÚSP údaje z databázy agendového systému zapíše do pripravených štruktúr CDÚ
• Dôležité: Je nevyhnutné, aby MÚSP spracovával prijaté údaje systematicky a štruktúrovane, nesmie sa sústrediť len na parciálne riešenie s ohľadom na aktuálnu požiadavku, ale aj s prihliadnutím na možnosť dlhodobého rozširovanie objektu evidencie pre rôzne účely a služby. Uložené údaje musia byť logicky štruktúrované tak, aby umožňovali efektívne vytváranie datasetov pre ďalšie požiadavky iných OVM alebo interných systémov SP teraz aj v budúcnosti.
• MÚSP vypracuje dokumentáciu podľa štandardov IT vo verejnej správe k prenosu vrátane popisu dát, dátových štruktúr, funkcií, schém architektúry a zdrojových kódov, vrátane dokumentácie zrealizovaných testov
• MÚSP vykoná základné automatické kontroly na entitnú, referenčnú a sémantickú integritu. Prípadné vady zapíše do špeciálnej štruktúry zistených vád a sprístupní pre agendový systém
• Samostatný údržbový job na strane MÚSP bude prenosové štruktúry udržiavať, t.j. expirované a spracované dáta budú periodicky odmazávané, predbežne navrhnutý na 10 mesačný retention interval
• Validácia dát a oprava / navrátenie dát pri zistených chybách v dátach.
• DZ SP pripraví služby, ktoré poskytnú údaje z CDÚ MÚSP v dohovorenej štruktúre podľa žiadaných parametrov
• Všetky dátové prenosy medzi systémami budú logované v štandardnom formáte (čas prenosu / volania, typ prenosu, veľkosť dát, úspešnosť spojenia, úspešnosť spracovania, zápis chybových hlásení, atď.) a ukladané.

Diagram 23: Publikovanie údajov do MDM (IS MÚSP)

Diagram 24: Publikovanie údajov do MDM (IS MÚSP) - sekvenčný diagram

Poskytovanie údajov z IS JVP do IS MÚSP

• 
  
  1. IS JVP zabezpečí poskytovanie údajov nasledovných objektov evidencie do MÚSP:
     1. Pre evidenciu UoZ na ÚPSVaR:
        1. (ŽS1_BP_02b) Kandidáti na zaradenie do evidencie UoZ (Ukončenie pracovného pomeru / sociálneho poistenia)
        2. (ŽS1_BP_028a) Kandidáti na vyradenie z evidencie UoZ (Začiatok pracovného pomeru / sociálneho poistenia)
• Centrálne komponenty MIRRI (CAMP) na základe zoznamu kandidátov na zaradenie do evidencie UoZ publikovaného v CPDI (CSRÚ) zabezpečia následne pre každého jedného z nich doručenie notifikácie o možnosti požiadať o zaradenie do evidencie UoZ. SP túto notifikáciu nezasiela.
• Spôsob identifikácie kandidátov na zaradenie do evidencie UoZ a vyradenie z evidencie UoZ popisuje projekt ŽS1
  1. 
     
     1. (ŽS1_BP_41) Poskytovanie dát pre MPSVR: 

1. Dataset „Pracovno-právne vzťahy“ žiadaný od MPSVR SR 

• JVP je povinný zabezpečiť publikovanie špecifikovaných atribútov do MÚSP. MÚSP následne tieto údaje doplní o prídavné atribúty z EKP a vytvorí kompletný dataset „Pracovno-právne vzťahy“, ktorý bude publikovaný do CPDI (CSRÚ) pre MPSVR. Je nevyhnutné vždy doručiť jednoznačnú identifikáciu objektu evidencie z JVP aj EKP, aby bolo možné publikované záznamy bezproblémovo spárovať. Bude potrebné synchronizovať poskytovanie údajov z oboch systémov tak, aby bolo vždy možné poskladať celý dataset PPV. 
• Definícia údajov doplňujúcich dataset PPV zo systému EKP sa nachádza v kapitole „DI-2.5 Poskytovanie údajov z IS EKP do MÚSP“ v podkapitole „DI-2.5. a. i. 1 Doplňujúce údaje pre dataset „Pracovno-právne vzťahy“ žiadaný od MPSVR SR“. 

MÚSP v úvodnej fáze získa základný súbor údajov o všetkých existujúcich pracovno-právnych vzťahoch. Následne bude JVP zasielať nové údaje a aktualizácie relevantných informácií pri každej zmene, či novom zázname, čím sa zabezpečí priebežná synchronizácia. 

• Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia ako: 
  • Využiť existujúcu WEB službu WS PV vystavenú na EKP a integrovať ju na MÚSP a následne na CPDI (CSRÚ). MÚSP by v tom prípade hral len úlohu sprostredkovateľa služby z EKP bez ukladania prenášaných údajov vo svojom úložisku. (PROXY). 
  • Keďže ako záverečný stav sa očakáva publikovanie predmetnej služby na CPDI (CSRÚ) z MÚSP, uprednostňuje sa primárne riešenie riešenie pred dočasnou integráciou WS PV priamo na CPDI (CSRÚ), a to aj napriek jeho nižšej efektívnosti, s cieľom eliminovať potrebu opätovného testovania zo strany CPDI (CSRÚ) v budúcnosti. 

Poskytovanie údajov z IS EKP do IS MÚSP

1. 
   
   1. IS EKP zabezpečí poskytovanie nasledovných údajov do MÚSP: 
2. (ŽS1_BP_41) Poskytovanie dát pre MPSVR: 

1. Doplňujúce údaje pre dataset „Pracovno-právne vzťahy“ žiadaný od MPSVR SR 

• Požadované prídavné atribúty: 
  • Icpv ... Identifikačné číslo pracovného vzťahu 
  • Miesto výkonu práce 
  • Počet hodín 
  • Úvazok ... Druh vykonávanej práce 
  • Pracovný čas ... Dohodnutý rozsah pracovného času 
• EKP je povinný zabezpečiť publikovanie určených prídavných atribútov do MÚSP, ktorý ich následne využije na obohatenie datasetu „Pracovno-právne vzťahy“ publikovaného do CPDI (CSRÚ) pre MPSVR. Je nevyhnutné vždy doručiť jednoznačnú identifikáciu objektu evidencie z JVP aj EKP, aby bolo možné publikované záznamy bezproblémovo spárovať. Bude potrebné synchronizovať poskytovanie údajov z oboch systémov tak, aby bolo vždy možné poskladať celý dataset PPV (Požiadavka na základný dataset PPV poskytovaný z JVP je špecifikovaná v kapitole Poskytovanie údajov z IS JVP do MÚSP).
• MÚSP v úvodnej fáze získa základný súbor údajov o všetkých existujúcich pracovno-právnych vzťahoch. Následne bude EKP zasielať nové údaje a aktualizácie relevantných informácií pri každej zmene, či novom zázname, čím sa zabezpečí priebežná synchronizácia. 
• Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia ako: 
  • Využiť existujúcu WEB službu WS PV vystavenú na EKP a integrovať ju na MÚSP a následne na CPDI (CSRÚ). MÚSP by v tom prípade hral len úlohu sprostredkovateľa služby z EKP bez ukladania prenášaných údajov vo svojom úložisku. (PROXY). 
  • Keďže ako záverečný stav sa očakáva publikovanie predmetnej služby na CPDI (CSRÚ) z MÚSP, uprednostňuje sa toto riešenie pred dočasnou integráciou WS PV priamo na CPDI (CSRÚ), a to aj napriek jeho nižšej efektívnosti, s cieľom eliminovať potrebu opätovného testovania zo strany CPDI (CSRÚ) v budúcnosti. 

Poskytovanie údajov z IS PvNGP do MÚSP 

Interná integrácia - Získanie údaju SP  - BATCH (MDM → IS SP)

Diagram 25: Získanie údajov SP - BATCH (MÚSP → IS SP)

Diagram 26: Získanie údajov SP - BATCH - sekvenčný diagram

Získanie údajov z IS MÚSP do IS PvNGP

1. Rozšíria sa konzumované údaje z IS MÚSP do IS PvNGP o:

1. ŽS1_BP_61

1. Dataset „Zaradenie do evidencie UoZ spolu so žiadosťou o DvN“ z ÚPSVAR pre automatické začatie konania o nároku na dávku v nezamestnanosti (cca. 98% žiadostí)
2. Dataset „Zaradenie do evidencie UoZ bez žiadosti o DvN“ z ÚPSVAR pre začatie konania o nároku na dávku v nezamestnanosti pri proaktívnej žiadosti o DvN od občana podanej v SP (osobne, listinne, elektronicky) (cca. 2% žiadostí)
3. Dataset „Vyradenie z evidencie UoZ“ z ÚPSVaR pre účely zastavenia vyplácania dávky nezamestnanosti.

• Všetky 3 spomenuté typy objektov evidencie budú v skutočnosti reprezentované jediným univerzálnym datasetom, ktorého obsah a účel bude určený obsiahnutým atribútom „Typ_zmeny“.
• PvNGP použije na uloženie získaných údajov už existujúce údajové štruktúry, v prípade potreby ich rozšíri o nové atribúty. PvNGP bude konzumovať kompletný set údajov doručených do MÚSP.
  1. Alternatívne riešenie: Nerealizovať rozšírenie datasetu a ponechať existujúcu priamu integráciu prostredníctvom XML súborov prenášaných z CPDI (CSRÚ) -> Úložisko SP -> PvNGP

1. ŽS_BP_61

1. Zúčtovanie dávky v hmotnej núdzi z ÚPSVaR pre účely zúčtovania dávky v nezamestnanosti s pomocou v hmotnej núdzi.

• Zúčtovanie dávky v nezamestnanosti s dávkou v hmotnej núdzi (DHN) poskytovanou ÚPSVaR je súčasťou prierezového konceptu zúčtovania DHN s dávkami Sociálnej poisťovne, ako je definovaný v prílohe „DI - Zúčtovanie DHN (SP-MPSVR).pdf“. Tento nový koncept by mal plne nahradiť a automatizovať existujúcu funkcionalitu, ktorá je v súčasnosti realizovaná priamou integráciou na MPSVR prostredníctvom dvojstranného dátového toku A1N / A2N podľa rámcovej dohody z roku 2009.
• Sociálna poisťovňa (SP) bude na dennej báze poskytovať Úradu práce, sociálnych vecí a rodiny (ÚPSVaR) údaje o jednotlivých konaniach a priebehu vyplácania dávok konkrétnym osobám na základe jeho požiadavky. ÚPSVaR sa bude dotazovať len na osoby skúmané v súvislosti s vyhodnocovaním nároku na DHN. Spôsob informovania ÚPSVaR o dávkach SP je popísaný v kapitole DI-2.7.a.i  (ŽS1_BP_60) – Zoznam dávok v nezamestnanosti pre zúčtovanie Dávky v hmotnej núdzi.
• SP nebude proaktívne informovať o spätne priznávaných dávkach žiadnym iným údajovým tokom, nakoľko ÚPSVaR bude mať na základe dennej informovanosti už všetky informácie k dispozícii.
• V prípade zistenia potreby zúčtovania, ÚPSVaR zašle do PvNGP prostredníctvom CPDI (CSRÚ) a MÚSP predmetný dataset, ktorý bude obsahovať:

• výšku zúčtovania
• mesiac dávky
• cieľový účet
• variabilný symbol a iné identifikačné údaje.

• Na základe tohto datasetu SP vykoná vyrovnanie a úhradu.
• SP nebude zasielať žiadne ďalšie potvrdenia o zúčtovaní.
• PvNGP použije na uloženie prijatých údajov existujúce údajové štruktúry, ktoré v prípade potreby rozšíri o nové atribúty a funkcionality.

1. Rodičovský príspevok (Zmeny v rodičovskom príspevku) z ÚPSVaR pre účely zastavenia vyplácania dávky v nezamestnanosti z dôvodu poberania rodičovského príspevku.

• V súčasnosti je tento dataset konzumovaný prostredníctvom priamej integrácie na MPSVR v jednosmernom dátovom toku C1 podľa rámcovej dohody s MPSVR z roku 2009. Bohužiaľ tento tok nie je v súlade s architektúrou 2.0 IS SP a ani nespĺňa všetky požiadavky na plne automatizovaný proces, nakoľko SP nedostáva informáciu o ukončení poberania rodičovského príspevku.
• ÚPSVaR doručuje informácie pre všetkých klientov poberajúcich rodičovský príspevok bez zasielania akejkoľvek požiadavky so zoznamom záujmových osôb zo strany SP a tak tomu bude aj v budúcnosti. Rozdielom bude rozšírenie konzumovaných informácií aj o dátum ukončenia poberania rodičovského príspevku, čo je vo vzťahu k vyhodnocovaniu nároku na DvN dôležitá informácia. SP na to využije nový dátový tok prostredníctvom CPDI (CSRÚ) a MÚSP.
• PvNGP využije na spracovanie získaných údajov už existujúce údajové štruktúry, ktoré v prípade potreby rozšíri o nové atribúty. Do budúcnosti bude postačovať, ak PvNGP bude z informačného systému MÚSP získavať iba údaje týkajúce sa záujmových osôb. Konkrétny spôsob implementácie bude určený v rámci fázy detailnej analýzy.
  1. Alternatívne riešenie: Nerealizovať rozšírenie datasetu a ponechať existujúcu priamu integráciu medzi ÚPSVaR a SP (prenos XML súborov medzi úložiskami (SSH) ÚPSVaR a SP a následne spracovanie do PvNGP. (TOKY A a C)

1. IS PvNGP volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSP, IS PvNGP volanie opakuje

Získanie údajov z IS MÚSP do IS JVP

• 
  
  1. IS JVP zabezpečí:
     1. (ŽS1_BP_41) Rozšírenie získavaných dát z MÚSP o nasledovné objekty evidencie:
        1. Dataset „Evidencia UoZ“ doručený z ÚPSVaR.
• Univerzálny dataset evidencie UoZ, v ktorom druh zmeny bude určený atribútom „Typ_zmeny“.
• JVP konzumuje primárne záznamy z evidencie UoZ ohľadom vyradenia uchádzača o zamestnanie z evidencie. Logika výberu a spracovania relevantných údajov bude zachovaná ako v aktuálnom stave.
• JVP použije na získané údaje už existujúce údajové štruktúry, v prípade potreby ich rozšíri o nové atribúty.
  1. Alternatívne riešenie: Nerealizovať rozšírenie datasetu a ponechať existujúcu priamu integráciu prostredníctvom XML súborov prenášaných z CPDI (CSRÚ) -> Úložisko SP -> JVP

1. 
   
   1. IS JVP volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSP, IS JVP volanie opakuje

5.4.1.2.2 DI-4 (pre ŽS5)

Diagram 27: Celková architektúra DI-4

Získanie údajov z RFO/RPO/RA do interných registrov SP/MÚSP

Interné systémy SP (JVP, EKP, PvNGP) využijú existujúce integračné väzby na referenčné registre RFO, RPO a RA v nasledujúcom rozsahu volaní služieb: 

RPO →

1. CSRU_WS_RPO_RPOPresentDataService:

1. CSRU_WS_RPO_RPOChangedSubjectsService: 

RA→ 

Získanie údajov z MÚSP do IS PvNGP (ŽS5_02_BP_19) – Primárny tok integrácie IS PvNGP)

Predpokladom uvedenej integrácie je vybudovanie MÚSP ako centrálneho bodu pre poskytovanie údajov. Integračná väzba bude nahrádzať aktuálne existujúce integračné väzby jednotlivých systémov na interné centrálne registre RFO SP a RPO SP, prípadne iné zdroje údajov v prípade overovania spracúvaných údajov.  

• Aktivity:

1. IS PvNGP zabezpečí rozšírenie získavaných dát prostredníctvom WS z MÚSP o nasledovné objekty evidencie: 

1. Zamestnávateľ 
2. Zamestnanec 
3. Sídlo 
4. Adresa 
5. A iné, ktoré budú definované v detailnej analýze integračnej väzby 

1. Dosiahnuť pravidelnú online periodicitu prenosov - Z MÚSP do IS PvNGP 
2. IS PvNGP volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSP, IS PvNGP volanie opakuje; 
3. IS PvNGP pripraví interné štruktúry a funkcie na prijatie a spracovanie údajov z MÚSP; 
4. IS PvNGP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane 
5. IS PvNGP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane v prípade spracovania odvolania 

• Alternatívne riešenie: V prípade, že služby MÚSP nebudú v požadovanom rozsahu v čase testovania dostupné, budú využité implementované integračné väzby na MÚSP ako aj ostatné zdrojové systémy SP. Konkrétny návrh riešenia vyplynie z fázy Analýzy a dizajn, ktorá bude obsahovať multikriteriálnu analýzu implementácie s využitím IS MÚSP na jednej strane a využitím iných existujúcich riešení na strane druhej.

Získanie údajov z MÚSP do IS JVP (ŽS5_02_BP_01, ŽS5_02_BP_05, ŽS5_02_BP_12, ŽS5_02_BP_13, ŽS5_02_BP_14) - Primárny tok integrácie do IS JVP

Predpokladom uvedenej integrácie je vybudovanie MÚSP ako centrálneho bodu pre poskytovanie údajov. Integračná väzba bude nahrádzať aktuálne existujúce integračné väzby jednotlivých systémov na interné centrálne registre RFO SP a RPO SP prípadne iné zdroje údajov v prípade overovania spracúvaných údajov.  

• Aktivity:

1. IS JVP zabezpečí rozšírenie získavaných dát z MÚSP o nasledovné objekty evidencie: 

1. Zamestnávateľ 
2. Zamestnanec 
3. Sídlo 
4. Adresa 
5. A iné, ktoré budú definované v detailnej analýze integračnej väzby 

1. Dosiahnuť pravidelnú online periodicitu prenosov - Z MÚSP do IS JVP 
2. IS JVP volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSPe, IS JVP volanie opakuje; 
3. IS JVP pripraví interné štruktúry a funkcie na prijatie a spracovanie údajov z MÚSP; 
4. IS JVP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane 
5. IS JVP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane v prípade spracovania odvolania 

• Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia. Konkrétny návrh riešenia vyplynie z fázy Analýzy a dizajn, ktorá bude obsahovať multikriteriálnu analýzu implementácie s využitím IS MUSP na jednej strane a využitím iných existujúcich riešení na strane druhej.  

Získanie údajov z MÚSP do CSRU (ŽS5_02_BP_01, ŽS5_02_BP_05, ŽS5_02_BP_12, ŽS5_02_BP_13, ŽS5_02_BP_14) - Primárny tok integrácie do IS JVP

Predpokladom uvedenej integrácie je vybudovanie MÚSP ako centrálneho bodu pre poskytovanie údajov. Integračná väzba bude nahrádzať aktuálne existujúce integračné väzby jednotlivých systémov na interné centrálne registre RFO SP a RPO SP prípadne iné zdroje údajov v prípade overovania spracúvaných údajov.  

• Aktivity:

1. MÚSP zabezpečí rozšírenie poskytovaných dát z prostredia sociálnej poisťovne minimálne v rozsahu nasledujúcich objektov evidencie: 

1. Zamestnávateľ 

1. Zamestnanec 

1. Sídlo 

1. Adresa 

1. A iné, ktoré budú definované v detailnej analýze integračnej väzby 

1. Dosiahnuť pravidelnú online periodicitu prenosov - Z MÚSP do CSRÚ 
2. MÚSP volá vystavené WS CSRÚ s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy; 
3. MÚSP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane 

• Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia. Konkrétny návrh riešenia vyplynie z fázy Analýzy a dizajn, ktorá bude obsahovať multikriteriálnu analýzu implementácie s využitím IS MUSP na jednej strane a využitím iných existujúcich riešení na strane druhej.

Získanie údajov z CSRÚ do IS MÚSP (ŽS5_02_BP_01, ŽS5_02_BP_05, ŽS5_02_BP_12, ŽS5_02_BP_13, ŽS5_02_BP_14) - Primárny tok integrácie do MÚSP

Integračná väzba bude využívaná pre prijímanie podaní/správ/údajov z CSRÚ do MÚSP, kde CSRÚ bude v roli vstupnej brány a prostredníctvom neho budú doručované oznámenia o vzniku platobnej neschopnosti a ostatné relevantné vstupné údaje. Kontext využívania  integrácie na CSRÚ pre automatizované prijímanie podaní zo slovensko.sk prípadne iného zdroja. 

Podanie z uvedeného kanálu bude v prvom kroku doručené do registratúry SP odkiaľ sa následne prostredníctvom integračných väzieb vyberie na spracovanie do MÚSP či už priamou integráciou alebo prostredníctvom na to určeného komponentu napr. BPM.  

• Aktivity:

1. MÚSP zabezpečí rozšírenie získavaných dát prostredníctvom WS z CSRU o nasledovné objekty evidencie: 

1. Zamestnávateľ 
2. Zamestnanec 
3. Sídlo 
4. Adresa 
5. Údaje všeobecného formulára odvolania 
6. A iné, ktoré budú definované v detailnej analýze integračnej väzby 

1. Dosiahnuť pravidelnú online periodicitu prenosov - Z CSRU do MÚSP 
2. MÚSP volá vystavené WS CSRU s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z CSRU (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v CSRU, MÚSP volanie opakuje; 
3. MÚSP pripraví interné štruktúry a funkcie na prijatie a spracovanie údajov z CSRU; 
4. MÚSP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane

• Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia. Konkrétny návrh riešenia vyplynie z fázy Analýzy a dizajn, ktorá bude obsahovať multikriteriálnu analýzu implementácie s využitím IS MUSP na jednej strane a využitím iných existujúcich riešení na strane druhej.

Poskytovanie údajov z IS PvNGP do MÚSP (ŽS5_02_BP_19) - Primárny tok integrácie z IS PvNGP

Integračná väzba bude využívaná pre odosielanie relevantných údajov do MÚSP.  

• Aktivity

1. IS PvN GP zabezpečí poskytovanie údajov nasledovných objektov evidencie do MÚSP: 
   1. Údaje, ktoré budú zasielané do MÚSP budú detailne identifikované vo fáze analýzy 
2. IS PVN GP pripraví podklady (údaje) pre WS, ktorú vystaví MÚSP ESB; v rozšírenej dátovej štruktúre; 
   1. Rozšíri údajovú štruktúru  
   2. Zohľadniť cieľový stav Q1 2026  
3. IS PVN GP upraví existujúce/prispôsobí/vytvorí nové aplikačné funkcie, ktoré budú online volať webservis metódou PUT, ktorý vystaví MUSP a cez ktorý budú posielane dávkovo ako aj nové dáta, tak aj zmeny nad dátami; 
4. IS PVN GP dôkladne otestuje a odladí integráciu na svojej strane; 
5. IS PVN GP poskytne súčinnosť pri ladení WS MÚSP ESB 
6. IS PVN GP vypracuje úplnú dokumentáciu podľa štandardov IT vo verejnej správe k prenosu vrátane popisu dát, dátových štruktúr, funkcií, schém architektúry a zdrojových kódov; vrátane dokumentácie zrealizovaných testov 
7. IS PVN GP prijme a spracuje údaje zo zistených vád, zvaliduje ich, opraví a zašle ich v najbližšom volaní; 

• Alternatívne riešenie: V prípade, že služby MÚSP nebudú v požadovanom rozsahu dostupné, budú využité aktuálne implementované integračné väzby na MÚSP ako aj ostatné zdrojové systému SP (RPO SP).  

Poskytovanie údajov z IS JVP do IS MÚSP (ŽS5_02_BP_01, ŽS5_02_BP_05, ŽS5_02_BP_12, ŽS5_02_BP_13, ŽS5_02_BP_14) – Alternatívny tok k DI-4.11.

Integračná väzba bude využívaná pre odosielanie relevantných údajov do MÚSP.  

1. IS JVP zabezpečí poskytovanie údajov nasledovných objektov evidencie do MÚSP: 
   1. Doba trvania poistenia 
   2. Údaje o zamestnávateľoch 
   3. Údaje o zamestnaniach 
2. IS JVP pripraví podklady (údaje) pre WS, ktorú vystaví MÚSP; v rozšírenej dátovej štruktúre; 
   1. Rozšíri údajovú štruktúru 
   2. Zohľadniť cieľový stav Q1 2026  
3. IS JVP upraví existujúce/prispôsobí/vytvorí nové aplikačné funkcie, ktoré budú pravidelne online volať webservis metódou PUT, ktorý vystaví MÚSP a cez ktorý budú posielane dávkovo ako aj nové dáta, tak aj zmeny nad dátami; 

Diagram 28: Publikovanie údajov do IS MÚSP/MDM

Diagram 29: Publikovanie údajov do IS MÚSP/MDM - sekvenčný diagram

Diagram 30: Získanie údajov SP - BATCH (komponenty)

Diagram 31: Získanie údajov SP - BATCH - sekvenčný diagram

5.4.1.2.3 DI-5 (pre ŽS7 a ŽS8)

Diagram 32: Celková architektúra DI-5

Získanie údajov z CSRÚ do IS MÚSP

1. MÚSP zabezpečí rozšírenie získavaných dát z CSRÚ o nasledovné objekty evidencie / datasety: 
   1. Dávka v hmotnej núdzi z ÚPSVaR pre účely zúčtovania dávok sociálneho poistenia pre ŽS7 a ŽS8 s dávkou v hmotnej núdzi. 

               Relevantné dávky:  

1. (ŽS7_BP_36) Vyrovnávacia dávka 

1. (ŽS7_BP_41) Materské – tehotná žena 

1. (ŽS7_BP_59) Materské – iný poistenec 

1. (ŽS7_BP_70) Materské – otcovské  

1. (ŽS8_BP_17) Nemocenské (ePN) 

1. (ŽS8_BP_27) Úrazový príplatok (ePN) 

1. (ŽS8_BP_30) Úrazová renta / jednorazové vyrovnanie 

1. (ŽS8_BP_41) Ošetrovné (krátkodobé) z dôvodu ošetrovania člena rodiny 

1. (ŽS8_BP_60) Ošetrovné (krátkodobé) z dôvodu uzatvorenia zariadenia 

1. (ŽS8_BP_72) Ošetrovné (dlhodobé) z dôvodu ošetrovania člena rodiny

1. 
   
   1. (ŽS7_BP_46) Vzdelanie z RIS pre účel overovania informácií o dosiahnutom vzdelaní a dobe štúdia v ŽS7 pri žiadosti o materské – iný poistenec 
   2.  (ŽS8_BP_24) Hlásenie o registrovanom pracovnom úraze z NIP pre účel poskytovania úrazových dávok v ŽS8 
   3.  (ŽS8_BP_58) Informácia o návšteve zariadenia z RIS pre účely overenia či ošetrované dieťa je žiakom, či navštevuje konkrétne zariadenie a či je zariadenie uzatvorené, pre účely  poskytovania dávky Ošetrovné (krátkodobé) z dôvodu uzatvorenia zariadenia v ŽS8

Presný spôsob integrácie medzi systémami CSRÚ a MÚSP bude zadefinovaný v rámci detailnej analýzy pre túto aktivitu. 

Publikovanie údajov do CSRÚ (IS MÚSP/MDM → CSRÚ)

Poskytovanie údajov z MÚSP do CSRÚ

MÚSP zabezpečí publikovanie nasledovných objektov evidencie / datasetov do CSRÚ: 

1. Objekty evidencie definované v kapitole „DI-5.1 Poskytovanie údajov z IS NPaLPČ (Syrius) do MÚSP“ a v kapitole „DI-5.2 Poskytovanie údajov z IS DAÚP do MÚSP“. 
   1. Požiadavka na doručenie informácie pre zúčtovanie Dávky v hmotnej núdzi 

1. 
   
   1. (ŽS1_BP_41) Dataset „Materské“ žiadaný od MPSVR SR

 Presný spôsob integrácie medzi systémami CSRÚ a MÚSP bude zadefinovaný v rámci detailnej analýzy pre túto aktivitu. 

Interná integrácia - publikovanie údajov do MDM (IS SP → IS MÚSP/MDM)

Poskytovanie údajov z IS NPaLPČ (Syrius) do IS MÚSP

IS NPaLPČ zabezpečí poskytovanie nasledovných údajov do MÚSP:

1. 
   
   1. Požiadavka na doručenie informácie pre zúčtovanie Dávky v hmotnej núdzi

Požiadavka bude okrem iného obsahovať minimálne nasledovné dôležité informácie: 

1. 
   
   1. 
      
      1. Dátum začiatku nároku na dávku ... (Obdobie Od)  
      2. Dátum ukončenia nároku na dávku ... (Obdobie Do) 
      3. Druh dávky ... Druh sociálnej dávky 
      4. Výška vyplácanej dávky ... Výška dávky na vyplatenie, ktorú SP priznala klientovi za záujmové obdobie

Relevantné dávky: 

1. (ŽS7_BP_27) Vyrovnávacia dávka
2. (ŽS7_BP_38) Materské – tehotná žena
3. (ŽS7_BP_56) Materské – iný poistenec 
4. (ŽS7_BP_67) Materské – otcovské 
5. (ŽS8_BP_08) Nemocenské (ePN) 
6. (ŽS8_BP_42) Ošetrovné (krátkodobé) z dôvodu ošetrovania člena rodiny 
7. (ŽS8_BP_61) Ošetrovné (krátkodobé) z dôvodu uzatvorenia zariadenia 
8. (ŽS8_BP_73) Ošetrovné (dlhodobé) z dôvodu ošetrovania člena rodiny

IS NPaLPČ zabezpečí zasielanie požiadavky so zoznamom klientov (záujmové osoby), ktorým bola priznaná príslušná dávka, za aké obdobie a v akej výške. Na základe tohto zoznamu ÚPSVaR následne spätne doručí požadované informácie pre zúčtovanie dávky v hmotnej núdzi. 

1. 
   
   1. (ŽS1_BP_41) Dataset „Materské“ žiadaný od MPSVR SR: 

NPaLPČ je povinný zabezpečiť publikovanie požadovaných atribútov daného objektu evidencie do MÚSP. MÚSP vytvorí z relevantných atribútov objektu evidencie kompletný dataset „Materské“, ktorý bude publikovať do CSRÚ pre MPSVR prípadne iné OVM. 

Detailný popis integračných vzťahov, formátu dopytu o poskytnutie údajov a očakávanej odpovede vo forme datasetu sa nachádza v prílohe „MPSVR SR - SP - štruktúra údajov - Materske.xlsx“. 

MÚSP v úvodnej fáze získa z NPaLPČ základný súbor údajov o všetkých existujúcich materských (kmeňové dáta). Následne bude NPaLPČ zasielať nové údaje a aktualizácie relevantných informácií pri každej zmene, či novom zázname, čím sa zabezpečí priebežná synchronizácia. 

Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenie, napr. využiť existujúcu WEB službu WS MAT a integrovať ju na MÚSP a následne na CSRÚ. MÚSP by v tom prípade hral len úlohu sprostredkovateľa služby bez ukladania prenášaných údajov vo svojom úložisku. (PROXY). V rámci detailnej analýzy treba určiť či je potrebné rozšíriť doručovaný dataset o ďalšie atribúty, prípadne upraviť formát doručeného datasetu. Keďže ako záverečný stav sa očakáva publikovanie predmetnej služby na CSRÚ z MÚSP, uprednostňuje sa toto riešenie pred dočasnou integráciou WS MAT priamo na CSRÚ a to aj napriek jeho nižšej efektívnosti, s cieľom eliminovať potrebu opätovného testovania zo strany CSRÚ v budúcnosti. 

Presný spôsob integrácie medzi agendovými systémami a MÚSP bude zadefinovaný v rámci detailnej analýzy pre túto aktivitu. 

Poskytovanie údajov z IS DAÚP do MÚSP

IS DAÚP zabezpečí poskytovanie nasledovných údajov do MÚSP: 

1. 
   
   1. Požiadavka na doručenie informácie pre zúčtovanie Dávky v hmotnej núdzi 

Relevantné dávky:  

1. (ŽS8_BP_27a) Úrazový príplatok (ePN) 

1. (ŽS8_BP_31) Úrazová renta / jednorazové vyrovnanie 

Detailná definícia požadovaných aktivít je obdobná ako v kapitole „Poskytovanie údajov z IS NPaLPČ (Syrius) do MÚSP“.

Interná integrácia - Získanie údaju SP  - BATCH (IS MÚSP/MDM → IS SP)

Získanie údajov z MÚSP do IS NPaLPČ (Syrius)

1. IS NPaLPČ zabezpečí rozšírenie získavaných dát z MÚSP o nasledovné objekty evidencie / datasety: 
   1. Dávka v hmotnej núdzi z ÚPSVaR pre účely zúčtovania dávok sociálneho poistenia pre ŽS7 a ŽS8 s dávkou v hmotnej núdzi 

Relevantné dávky:  

1. (ŽS7_BP_36) Vyrovnávacia dávka 

1. (ŽS7_BP_41) Materské – tehotná žena 

1. (ŽS7_BP_59) Materské – iný poistenec 

1. (ŽS7_BP_70) Materské – otcovské  

1. (ŽS8_BP_17) Nemocenské (ePN) 

1. (ŽS8_BP_41) Ošetrovné (krátkodobé) z dôvodu ošetrovania člena rodiny 

1. (ŽS8_BP_60) Ošetrovné (krátkodobé) z dôvodu uzatvorenia zariadenia 

1. (ŽS8_BP_72) Ošetrovné (dlhodobé) z dôvodu ošetrovania člena rodiny 

ÚPSVaR zašle informáciu, či klient poberal v záujmovom období DHN a ak áno, tak podľa výšky oznámenej dávky sociálneho poistenia určí sumu na zúčtovanie, cieľový účet a variabilný symbol pod ktorým treba platbu uskutočniť. 

Ak klient DHN nepoberal, alebo výška dávky sociálneho poistenia je v rámci povoleného limitu, tak zúčtovanie neprebehne (vyhodnotí ÚPSVaR). 

V rámci detailnej analýzy je potrebné, aby analytický tím dodávateľa vyriešil, či je potrebné v novej implementácii doručovať informáciu o poberateľovi DHN v dvoch krokoch (1. Potvrdenie poberania DHN, 2. Detaily zúčtovania), alebo je možné pre poberateľov DHN poslať detaily pre zúčtovanie hneď v prvom kroku. Legislatívne otázne je, či je možné hneď v prvom kroku zo SP zasielať detaily o dávke sociálneho poistenia aj napriek tomu, že ešte nie je známe, či klient poberal v záujmovom období DHN. 

NPaLPČ použije na uloženie získaných údajov už existujúce údajové štruktúry, v prípade potreby ich rozšíri o nové atribúty. NPaLPČ bude konzumovať kompletný set údajov doručených do MÚSP, nakoľko tam budú obsiahnuté len záujmové osoby. 

1. 
   
   1. (ŽS7_BP_46) Vzdelanie z RIS pre účel overovania informácií o dosiahnutom vzdelaní a dobe štúdia v ŽS7 pri žiadosti o materské – tehotná žena 
   2. (ŽS8_BP_24) Hlásenie o registrovanom pracovnom úraze z NIP pre účel poskytovania úrazových dávok v ŽS8 
   3. (ŽS8_BP_58) Informácia o návšteve zariadenia z RIS pre účely overenia či ošetrované dieťa je žiakom, či navštevuje konkrétne zariadenie a či je zariadenie uzatvorené, pre účely  poskytovania dávky Ošetrovné (krátkodobé) z dôvodu uzatvorenia zariadenia v ŽS8

1. IS NPaLPČ volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSP, IS NPaLPČ volanie opakuje 
2. IS NPaLPČ pripraví interné štruktúry a funkcie na prijatie a spracovanie údajov z MÚSP 
3. IS NPaLPČ implementuje procesy

Získanie údajov z MÚSP do IS DAÚP

1. IS DAÚP zabezpečí rozšírenie získavaných dát z MÚSP o nasledovné objekty evidencie / datasety: 
   1. Dávka v hmotnej núdzi z ÚPSVaR pre účely zúčtovania dávok sociálneho poistenia pre ŽS8 s dávkou v hmotnej núdzi 

Relevantné dávky: 

1. (ŽS8_BP_27) Úrazový príplatok (ePN) 

1. (ŽS8_BP_30) Úrazová renta / jednorazové vyrovnanie 

1. IS DAÚP volá vystavený WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v MÚSP, IS DAÚP volanie opakuje 
2. IS DAÚP pripraví interné štruktúry a funkcie na prijatie a spracovanie údajov z MÚSP 
3. IS DAÚP implementuje procesy, aplikačné funkcie a zmeny v spracovaní dát na svojej strane 

5.4.1.2.4 DI-6 (pre ŽS14)

Diagram 33: Celková architektúra DI-6

Získanie údajov z CSRÚ (CSRÚ → IS MÚSP/MDM) – údaje z MPSVaR

Predmetom dátovej výmeny sú objekty evidencie súvisiace s agendou dôchodkov (údaje z ÚPSVaR) v rozsahu definovanom v kapitole dátová architektúra.

MÚSP zabezpečí integráciu a získavanie údajov z CSRÚ minimálne pre nasledovné objekty evidencie súvisiace s agendou dôchodkov (údaje z ÚPSVaR): 

• Register sociálnych služieb
  • ProviderCType - Zložený dátový typ 
    • Názov PO 
    • Priezvisko osoby 
    • Meno osoby 
    • Zoznam identifikátorov (Zložený dátový typ – IdentiferCType) 
    • Typ poskytovateľa služby (Zložený dátový typ – CodeTableValueCType) 
    • Zoznam poskytovaných sociálnych služieb (Zložený dátový typ - SocialServiceCType) 
    • Adresa poskytovateľa sociálnej služby (Zložený dátový typ – AddressCType) 
    • Štatutárny zástupca 
  • AddressCType- Zložený dátový typ 
    • Ulica miesta poskytovania služby 
    • Číslo miesta poskytovania služby 
    • PSČ miesta poskytovania služby 
    • Obec miesta poskytovania služby 
    • Adresa miesta poskytovania v textovej podobe 
• Evidencia ŤZP - osobná asistencia
  • Zložený dátový typ - PhysicalPersonCType: 
    • Meno 
    • Priezvisko 
    • DatumNarodenia 
    • Identifikator (Zložený dátový typ – IdentifierCType) 
  • Zložený dátový typ – AssistanceContractCType 
    • DatumOd (Začiatok platnosti zmluvy) 
    • DatumDo (Koniec platnosti zmluvy) 
    • HodinyZaMesiac (Mesačný rozsah osobnej asistencie - počet celých hodín) 
  • Zložený dátový typ – AssistanceFulfillmentCType 
    • Mesiac (Mesiac výkonu osobnej asistencie) 
    • Hodiny (Počet hodín vykonanej asistencie v daný mesiac) 
    • Minúty (Počet minút vykonanej asistencie v daný mesiac) 
    • Výkon osobnej asistencie v hodinách 
    • Počet listinných výkazov osobnej asistencie 
• Evidencia poberateľov DHN
  • Zložený dátový typ - physicalPersonType: 
    • Zoznam identifikátorov osoby (Zložený dátový typ - IdentifikatorType, opakovateľný prvok) 
    • Meno osoby 
    • Priezvisko osoby 
    • Dátum narodenia osoby vo formáte "yyyy-MM-dd" 
    • Dátum zmeny dát 
    • Zoznam identifikátorov osoby (Zložený dátový typ - periodType, opakovateľný prvok) 
  • Zložený dátovy typ - periodType: 
    • Mesiac poberania DHN od 
    • Mesiac poberania DHN do 
    • Identifikácia žiadosti, ktorej sa obdobie týka (Zložený dátový typ applicationType) 
    • Rola osoby na žiadosti o sociálnu dávku, kód číselníkovej položky z rezortného číselníka. 
    • Stav poskytovania sociálnej dávky, kód číselníkovej položky z rezortného číselníka. 
• Rodičovský príspevok
  • Zložený dátový typ – PhysicalPersonCType 
    • Meno 
    • Priezvisko 
    • DatumNarodenia 
    • Identifikator 
  • BenefitPeriodCType - zložený dátový typ 
    • Začiatok poberania RP 
    • Koniec poberania RP 
    • Stav poskytovania sociálnej dávky. Podľa hodnoty tohto elementu je možné finálne určiť, či osobe bola alebo nebola poskytnutá v danom období dávka/príspevok 
    • Identifikácia žiadosti, ktorá sa týka daného obdobia 
    • Deti, ktorých sa dávka/príspevok v danom období týka 
    • Informácie o žiadosti klienta o odňatie dávky/príspevku
• Evidencia uchádzačov o zamestnanie (EuoZ)
  • Zložený dátový typ – UdajeOsobaCType 
    • údaje o osobe (identifikátor, meno, priezvisko atď) 
  • Zložený dátový typ - EvidenciaCType, ZiadatelDavkyNezam: 
    • Identifikátor role v ISSZ 
    • Číslo okresu 
    • Dátum podania žiadosti 
    • Dátum zaradenia do evidencie UoZ 
    • Dátum právoplatnosti zaradenia 
    • Dátum vyradenia z evidencie 
    • Dátum právoplatnosti vyradenia z evidencie UoZ 
    • Od kedy do kedy bola vyplácaná podpora v nezamestnanosti v období od 1.1.2001 do 31.12.2003  
    • Dôvod vyradenia a nezaradenia z evidencie UoZ 
    • Číselník stavu role 
    • Dlhodobo evidovaný 
    • Dlhodobo evidovaný od 
    • Posledná zmena v evidencie UoZ (zaradenie, vyradenie, zmeny, ...) 
    • Dôvod poslednej zmeny v evidencie 
    • Dátum poslednej zmeny v evidencie 
    • Údaje o zamestnávateľovi 
    • Enumerácia, či je klient evidovaný ako dlhodobo nezamestnaný v najmenej rozvinutom okrese 
    • Údaje o prerušeniach 
    • ZiadatelDavkyNezam (UoZ je súčasne aj žiadateľom o uplatnenie nároku na dávku v nezamestnanosti v Sociálnej poisťovni  (A/N) ) 
    • Údaj o výkone zamestnania v inom členskom štáte EU v posledných 4 rokoch pred zaradením do evidencie UoZ 
    • Údaje o dôchodkoch v iných členských štátov EU 
    • Je/nie je poberateľom dávky v hmotnej núdzi a príspevkov k dávke v hmotnej núdzi (A/N) 
    • Spôsob zaslania výplaty: hotovosť, okresný okruh, poštový poukaz na výplatu, účet 
    • Výplata na ktorú adresu mý byť zaslaná výplata. Vyplní sa ak Vyplata=1 
    • Číslo účtu pre výplatu dávky v nezamestnanosti. Vyplní sa ak Vyplata=1

Prostredníctvom tejto integrácie (prostredníctvom CSRÚ) bude prebiehať získavanie objektov evidencie v rámci súčasnej integrácie (SP-ÚPSVaR) a na základe detailnej analýzy budú doplnené ďalšie relevantné objekty evidencie.

Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia, ako je realizácia integrácie bez MUSP - integrácia z CSRÚ -> Úložisko SP -> cieľový IS SP 

Publikovanie údajov do CSRÚ (IS MÚSP/MDM → CSRÚ)

1. Predmetom dátovej výmeny sú objekty evidencie súvisiace s agendou dôchodkov (údaje pre MPSVR) minimálne v tomto rozsahu: 
   1. Univerzálny dataset pre „Dôchodky“ zasielaný na požiadavku od MPSVR, ktorý slúži na kontrolu príjmu z dávok dôchodkového poistenia pri poberateľoch dávky v hmotnej núdzi a príspevkov k dávke, peňažných príspevkov na opatrovanie, náhradného výživného a dotácií na stravu. 

Aktuálny stav definície datasetu a príslušnej požiadavky je v prílohe „MPSVR SR - SP - štruktúra údajov – Dôchodky.xlsx“. 

1. Predmetom dátovej výmeny sú objekty evidencie súvisiace s agendou dôchodkov (údaje pre DEUS) minimálne v tomto rozsahu: 

• zložený dátový typ  - PersonNameType: 
  • GivenName, FamilyName, Affix 
•  zložený dátový typ  - PhysicalPersonType: 
  • Birth 
• zložený dátový typ  - ResultType: 
  • ConfirmationDate (dátum potvrdenia), PensionBenefitsInfo (typ dôchodku), Total (Suma dôchodku) 
• zložený dátový typ  - PensionBenefitsItem: 
  • dátum začatia poberania dôchodku 
  • dátum ukončenia poberania dôchodku
  • Typ dôchodku 

 Detailizovanie alebo doplnenie objektov evidencie bude spracované v rámci detailnej analýzy a komunikácie s konzumentom údajov

Interná integrácia - publikovanie údajov do MDM (IS SP → IS MÚSP/MDM)

1. 
   
   1. Údaje z MPSVaR

Cieľový IS SP zabezpečí prijatie a spracovanie objektov evidencie získaných z MÚSP. 

Prostredníctvom tejto integrácie (prostredníctvom CSRÚ) bude prebiehať získavanie objektov evidencie v rámci súčasnej integrácie a na základe detailnej analýzy budú doplnené ďalšie relevantné objekty evidencie. 

V rámci cieľového IS SP bude zabezpečené: 

• Implementácia volania vystaveného WS MÚSP s parametrami požadovaného rozsahu dát, ktorým zapíše dáta z MÚSP (import) do vlastnej databázy. V prípade chyby alebo nepripravenosti dát v IS MÚSP, IS volanie opakuje; 
• príprava internej štruktúry a funkcie na prijatie a spracovanie údajov z MÚSP; 
• implementácia procesov, aplikačnej funkcie a zmien v spracovaní dát na svojej strane.

Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia, ako je realizácia integrácie bez MUSP - integrácia z CSRÚ -> Úložisko SP -> cieľový IS SP. 

1. 
   
   1. Údaje pre DEUS

IS SP (ako poskytovateľ údajov v SP) zabezpečí spracovanie datasetov, ich zaslanie do MÚSP. 

V rámci IS SP – poskytovateľa údajov bude zabezpečené: 

• príprava podkladov (údaje) pre WS, ktorú vystaví MUSP ESB; 
• úprava existujúcich/ prispôsobenie/ vytvorenie nových aplikačných funkcií, ktoré budú pravidelne raz za 24 hodín volať webservis metódou PUT, ktorý vystaví MUSP a cez ktorý budú posielané dávkovo ako aj nové dáta, tak aj zmeny nad dátami; 

Alternatívne riešenie: V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia, ako je realizácia integrácie bez MUSP - integrácia z CSRÚ -> Úložisko SP -> cieľový IS SP. 

Interná integrácia - Získanie údaju SP  - BATCH (MDM → IS SP)

1. 
   
   1. Údaje z MPSVaR

MÚSP zabezpečí publikovanie objektov evidencie získaných z CSRÚ do cieľových IS SP: 

• IS SP 
• IS SP

Prostredníctvom tejto integrácie (prostredníctvom CSRÚ) bude prebiehať získavanie objektov evidencie v rámci súčasnej integrácie a na základe detailnej analýzy budú doplnené ďalšie relevantné objekty evidencie. 

Alternatívne riešenie:V závislosti na prácnosti a možnom časovom oneskorení môžu prísť do úvahy aj dočasné kompromisné riešenia, ako je realizácia integrácie bez MUSP - integrácia z CSRÚ -> Úložisko SP -> cieľový IS SP. 

1. 
   
   1. Údaje pre DEUS

5.4.1.2.5 DI-7 (pre všetky ŽS)

Za účelom predvypĺňania očakávame vystavenie atomických REST API služieb (integračná vrstva), ktoré budú volané z príslušných sekcii eFormulára a zabezpečia oddelenie frontend logiky formulára od backend údajov SP a tiež umožnia multikanálové použitie eFormulára. Jednotlivé API budú zabezpečené používateľským tokenom. Obsah API rozhraní bude definovaný v detailnej analýze.

Pre evidenciu osôb a údajov o poistení slúžia konektory ako Osoba - základné údaje, Číselníky, Obdobia poistenia, Výpočet nárokov a Overenie poistenia v 2. pilieri a ďalšie.

API rozhrania na predvypĺňnanie budú vystavené v rámci Enterprise application integration v APC SP, ktorá bude alokovaná v DMZ zóne a prístupná pre frontendové aplikácie.

Zdrojovými systémami pre údaje do eFormulárov sú predovšetkým Lokálne RFO SP, ZIUP, JVP, CIPS a ďalšie a ich údaje pre API vrstvu môžu a nemusia byť vystavené prostredníctvom systému IS MÚSP. Rozhodovacím faktorom je kvalita údajov zdrojového systému a prípadné nutné korelácie medzi systémami navzájom, resp. umiestnenie tzv. „golden record“, t.j. najsprávnejšej verzie záznamu.

Na technologickej vrstve synchronizáciu údajov do MUSP zabezpečuje MDM TALEND, ktoré pracuje s ETL nástrojmi a ESB (Enterprise Service Bus).

Aplikačné integrácie po (pred)vyplnení formulára:

Dokumenty, ktoré tvoria súčasť podania sa ukladajú do dočasného DMS v DMZ,  reprezentovaného na technologickej vrstve ako FILENET. Databáza ORACLE DB zabezpečuje fyzickú realizáciu pre ZIUP a EUP.

Komunikácia Špecializovaného portálu SP s integračnými rozhraniami ÚPVS bude prebiehať prostredníctvom UPVS proxy rozhraniami vystavenými v rámci projektu IS Registratúra, ktorý zabezpečuje jednotný integračný bod na ÚPVS. Z pohľadu portálu pri odosielaní vyplneného eFormuláru sa predpokladá komunikácia s UPVS a jeho modulmi UPVS G2G (odoslanie podania) a UPVS eDesk (zápis správy do rozpísaných, resp. odoslaných správ používateľa). Doručenie podania je do eDesk schránky SP,  na strane SP   zrealizuje IS Registratúra evidenciu a príjem podaní , čo je koncová fáza procesu.

Diagram 34: Aplikačná architektúra DI-7

5.4.1.2.6 DI-8 (Integrácia s NCZI pre potreby ŽS8)

Z pohľadu aplikačnej a dátovej architektúry je jadrom tejto témy Register potrieb starostlivosti, ktorý bude zabezpečovať funkčnosti spojené so synchronizáciou potrieb starostlivosti prijatých z IS eZdravie. Register bude zabezpečovať funkčnosti:

• Založenie novej potreby starostlivosti
• Aktualizácia potreby starostlivosti so zabezpečením historizácie zmien v hodnotách atribútov potreby starostlivosti
• Stornovanie potreby starostlivosti so zabezpečením historizácie zmien v hodnotách atribútov potreby starostlivosti
• Správu subjektov s označeným príznakom „záujmová“ pre danú potrebu starostlivosti

Register bude zabezpečovať pomocou vystavených služieb poskytovanie evidovaných údajov o potrebách starostlivosti interným systémov v rámci Sociálnej poisťovne. Zoznam poskytovaných služieb bude popísaný v rámci kapitoly integračných rozhraní.

Diagram 35: Diagram tried pre register potrieb starostlivosti (DI-8)

Podľa integračného manuálu NCZI je navrhnutá integrácia uvedených údajov (Príloha X) a diagramu tried.

Pre výmenu údajov o potrebách starostlivosti medzi jednotlivými informačnými systémami bude použitých viacero rozhraní. Z pohľadu SP pôjde o externé rozhrania na informačné systémy prevádzkované iným subjektom, ako aj interné rozhrania medzi informačnými systémami SP.

Na strane SP bude spracovanie potrieb ošetrovania realizované v IS EKP a následne budú informácie odovzdané do IS NPaLPČ.

Zoznam externých a interných rozhraní:

• R1 je rozhranie pre prenos údajov z eZdravie prostredníctvom IS EKP do IS NPaLPČ, ktoré sa v súčasnosti využíva na prenos údajov o ePN. V rámci fázy prípravy DNR bude rozhodnuté, či sa rozšíria aktuálne rozhrania o prenos údajov o potrebách starostlivosti alebo budú vytvorené nová rozhrania. V súčasnosti má rozhranie R1 dve časti:
  • R1A je externé rozhranie, ktorého účelom je integrácia IS EKP a IS eZdravie a cez ktoré sú do SP doručované údaje o vystavených PN a rovnakou alternatívou by boli doručované informácie o potrebách starostlivosti.
  • R1B je interné rozhranie, ktorého účelom je integrácia IS EKP a IS NPaLPČ a cez ktoré sú v rámci SP odovzdávané údaje o vystavených PN z IS EKP do IS NPaLPČ na základe volania WS z IS NP a LPČ. S rozšírením danej služby sa pre potreby poskytovania informácii o potrebách starostlivosti nepočíta.
• Nové rozhranie pre overenie existencie potreby starostlivosti pre požadovanú fyzickú osobu. Služba na základe prijatých údajov o fyzickej osobe (RČ, IFO) vráti zoznam evidovaných potrieb starostlivosti v registri potrieb starostlivosti
• Nové rozhranie pre poskytovanie informácií prijatí aktualizácie pre potreby starostlivosti označené pre daného konzumenta služby ako záujmové

Údaje daných rozhraní budú obsahovať identifikáciu ošetrovanej osoby, trvanie OČR a hospitalizácie danej osoby.

R1A – Rozhranie pre prenos údajov z IS eZdravie do IS EKP

Modul SP_Facade IS eZdravie bude pre získavanie údajov o potrebách starostlivosti poskytovať nasledovné služby:

Procesy komunikácie  IS EKP voči eZdravie

IS EKP bude v dohodnutých intervaloch (špecifikácia v rámci DNR) volať služby IS eZdravie pre získanie informácii o potrebách starostlivosti uložených v IS eZdravie. Vystavené služby je potrebné volať v poradí:

1. VyhladajZoznamPotrieb – pomocu ktorého bude okrem iného získaný identifikátor Potreby

Obrázok 3 - Prehľad spracovania volania služby VyhladajZoznamPotrieb

1. DajUdajePotreby – pomocou identifikátora Potreby na vstupe budú získané údaje o Potrebe aj s celou jej históriu

Obrázok 4 - Prehľad spracovania volania služby DajUdajePotreby

• Následne budú údaje získané zo služieb eZdravie uložené v registri potrieb starostlivosti, pričom v rámci prijatých údajov je možné spracovávať nasledovné scenáre rovnakým princípom ako pri spracovaní ePN:
• Prijatá nová potreba starostlivosti – potreba založenie potreby v registri potrieb starostlivosti
• Prijatá aktualizácia potreby starostlivosti – potreba aktualizácie atribútov potreby v registri potrieb starostlivosti, so zabezpečením histórie zmien pre danú potrebu starostlivosti
• Prijaté storno potreby starostlivosti – potreba zmenu stavy potreby ošetrovania v registri potrieb ošetrovania, so zabezpečením histórie zmien pre danú potrebu starostlivosti

Rozhranie pre poskytnutie potreby starostlivosti z registra potrieb starostlivosti

Interné rozhranie SP, ktorého účelom je integrácia IS EKP a IS NPaLPČ. EKP sprístupní pre IS NPaLČ

 web službu REST, pomocou ktorej si IS NPaLČ bude overovať informácie o existencii potreby starostlivosti.   

Celkový počet publikovaných koncových bodov budú 5

• Prvý bude služíť pre stiahnutie potrebných údajov o potrebách starostlivosti z IS EKP do IS NPaLPČ.
• Druhý bude slúžiť pre technické potvrdenie prijatia údajov v systéme IS NPaLPČ.
• Tretí bude slúžiť na označenie poskytnutej potreby starostlivosti ako záujmovej
• Štvrtý bude slúžiť na zrušenie označenia záujmovej potreby starostlivosti pre daného konzumenta služby
• Piaty bude slúžiť na stiahnutie aktualizácií, resp. storna potreby starostlivosti pre záujmové potreby starostlivosti pre daného konzumenta služby

Poskytnutie potrieb starostlivosti

Služba na základe vstupných atribútov (RČ,IFO) overí existenciu potreby starostlivosti v registri potrieb starostlivosti.

Služba na výstupe vráti aktuálne informácie(tj aktuálnu verziu) evidované pre potreby starostlivosti spĺňajúce vstupné parametre

Technické potvrdenie prijatia údajov

Služba na základe ktorej konzument služby potvrdenie poskytnutia potrieb starostlivosti potvrdí prijatie údajov.

Označenie potreby starostlivosti ako záujmovej

Služba na základe ktorej je možné označiť danú potrebu starostlivosti v registri potrieb starostlivosti ako záujmovú a tým pádom bude možné získavať zmeny pre danú potrebu starostlivosti.

Vstupnými parametrami danej služby bude identifikácia potreby ošetrovania a identifikácia konzumenta služby(na základe hlavičky requestu)

 Zrušenie označenia potreby starostlivosti ako záujmovej

Služba na základe ktorej je možné zrušiť označenie potreby starostlivosti v registri potrieb starostlivosti ako záujmovej.

Vstupnými parametrami danej služby bude identifikácia potreby ošetrovania a identifikácia konzumenta služby(na základe hlavičky requestu)

Poskytnutie aktualizovaných potrieb starostlivosti

Služba na základe ktorej je možné získať všetky aktualizované potreby starostlivosti z registra potrieb starostlivosti podľa subjektu konzumenta služby

Vstupnými parametrami danej služby bude dátum od ktorého aktualizácie potrieb starostlivosti majú byť poskytnuté a identifikácia konzumenta služby (na základe hlavičky requestu)

5.4.1.3 Notifikácie

Diagram 36: Aplikačná vrstva - Centrálny notifikačný modul

5.4.1.4Registratúra

Diagram 37: Aplikačná architektúra pre Podania realizované klientom

Rozdielová analýza voči DNR pre Vybudovanie elektronického informačného systému na správu registratúry (IS REG) identifikovala nasledovné potencionálne chýbajúce komponenty / funkcie IS REG voči požiadavkám POO: 

• ÚPVS Proxy rozhranie 

• Integrácia na BPM 

• Označenie a manuálne spracovanie prípadu, ak nie je možné určiť agendu automaticky 

Diagram 38: Aplikačná architektúra pre Prípady iniciované ex-offo alebo externe z iného OVM

* Časť relevantná pre riešenie IS Registratúra je v zelenom rámčeku, konkrétne komponenty: 

• IS Registratúra 
• Modul Podateľňa 
• Modul ÚPVSProxy (integračné proxy rozhranie na služby ÚPVS) 

5.4.1.5 Monitoring služieb

Nižšie je znázornená a definovaná architektúra riešenia pre:

• Publikovanie údajov do CSRÚ (MDM -> CSRÚ)

• Interná integrácia - publikovanie údajov do MDM (IS SP -> MDM)

​​​​​​​

​​​​​​​

Diagram 41: Monitoring služieb - Publikovanie údajov v MDM (interné integrácie)

5.4.2 Rozsah informačných systémov – budúci stav (TO BE)

Tabuľka 23 Rozsah informačných systémov - budúci stav (TO BE)

5.4.3 Využívanie nadrezortných a spoločných ISVS – AS IS

Tabuľka 24 Využívanie nadrezortných a spoločných ISVS – súčasný stav (AS IS)

5.4.4 Prehľad plánovaných integrácií na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 Z.z. o  e-Governmente – budúci stav (TO BE)

Tabuľka 25 Prehľad plánovaných integrácií na spoločné moduly – budúci stav (TO BE)

5.4.5 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

Tabuľka 26 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

*

5.4.6 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

Tabuľka 27 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

5.4.7 Aplikačné služby na integráciu – budúci stav (TO BE)

Z potrebných aplikačných služieb na integráciu sú už realizované služby

Tabuľka 28 Aplikačné služby na integráciu – budúci stav (TO BE)→

5.5 Dátová architektúra

Jednou z kľúčových oblastí realizácie predkladaného projektu sú dátové integrácie s cieľom:

• Integrácie agendových systémov na EÚP pre sprístupnenie údajov pre klientov SP (poistenec a zamestnávateľ)
• Sprístupnenie údajov medzi agendovými IS SP potrebnými na realizáciu ŽS, primárne s využitím integračnej platformy SP (ESB) a IS MÚSP (ako dátovej platformy pre ďalšiu integráciu s CPDI)
• Priamej integrácie na NCZI pre potreby ŽS8

Datasety potrebné pre realizáciu jednotlivých požiadaviek životných situácií sú evidované v Prílohe 5 tohto zámeru.

Tento zoznam sa môže vo fáze Analýza a dizajn ešte spresniť/upraviť.

5.5.1 Objekty evidencie

​​​​​​​Frontend

​​​​​​​

Riešenie Frontendu je z pohľadu dátovej architektúry tvorená nasledujúcimi časťami:

• Moje údaje
• Môj účet
• Moje dokumenty.

Bližšie objekty evidencie a údaje k nim, ktoré Sociálna poisťovňa eviduje sú predmetom samostatnej prílohy s názvom „Katalóg dátových prvkov a dátových integrácií“.

Diagram 42: Prehľad objektov evidencie - Frontend (TO BE)

1. 
   
   1. 
      
      1. 
         
         1. Registratúra

Dátová vrstva a dátový rozsah je definovaná Výnosom 525/2011 Ministerstva vnútra SR o štandardoch pre elektronické informačné systémy na správu registratúry v znení opatrenia MV SR č. 203/2021 Z. z., ktorý je vykonávacím predpisom pre zákon č. 395/2002 Z.z. o archívoch a registratúrach a o doplnení niektorých zákonov v znení neskorších predpisov a to paragrafom § 3 Štandardy pre elektronický systém správy registratúry.

Model vzťahov medzi entitami predstavuje všeobecný model vzťahov medzi jednotlivými entitami

• vecná skupina,
• spis,
• záznam,
• komponent

Metadátové štruktúry  budú rozdelené do nasledujúcich skupín:

1. Prvky metadát vecnej skupiny
2. Prvky metadát spisu
3. Prvky metadát registratúrneho záznamu
4. Prvky metadát používateľov elektronického systému správy registratúry

Rozsah metadát môže byť počas realizácie analytickej fázy projektu doplnený. Vyššie uvedené dáta sú základným setom dát, ktoré budú evidované pre jednotlivé entity.

Základné vzťahy medzi entitami registratúry umožňujú v rámci registratúry pôvodcu zaraďovanie registratúrnych záznamov spolu s ich prílohami do spisov a zaraďovanie spisov do vecných skupín. Súbor entít môže mať v závislosti od pôvodcu registratúry rôznu štruktúru členenia.

Diagram 43: Model vzťahov medzi entitami

Diagram 44: Možnosti vetvenia registratúrneho plánu

1. 
   
   1. 
      
      1. 
         
         1. Monitoring

Proces publikovania údajov do Master data Management, Správy tzv. zlatých údajov, je znázornený nižšie:

Diagram 45: Proces publikovania údajov do IS MÚSP/MDM, Správy tzv. zlatých údajpv

Tabuľka 29 Objekty evidencie

Detailnejší prehľad datasetov napárovaných na jednotlivé požiadavky na dátové integrácie je dostupný v Prílohe 5.

5.5.2 Referenčné údaje

V rámci predkladaného projektu sa neplánujete vyhlásenie údajov za referenčné, avšak aj tento projekt prispieva k efektívnemu využívaniu údajov vo verejnej správe a k zvyšovaniu kvality a vytvoreniu podmienok pre komplexný data manažment.

5.5.3 Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

5.5.4 Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

Tabuľka  Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

5.5.5 Identifikácia údajov a subjektov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

Tabuľka  Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

5.5.6 Kvalita a čistenie údajov

Zhodnotenie OE bude prebiehať vo fáze Analýza a Dizajn.

Dátovú kvalitu zabezpečuje projekt MUSP a správcovia IS MÚSP.   

Tabuľka  Personálne zabezpečenie a roly pri riadení dátovej kvality

5.5.7 Otvorené údaje

Projektom nie sú plánované žiadne nové údaje, ktoré je možné vyhlásiť za otvorené. 

5.5.7 Analytické údaje

V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie :

5.5.8 Moje údaje

Moje údaje spadajúce pod dátové integrácie sú pokryté v projektových dokumentáciách ŽS1, ŽS5, ŽS7+8 a ŽS14+16. Detailnejšie budú Moje údaje predmetom etapy Analýza a dizajn, zároveň ide o údaje z datasetov, definovaných v prílohe 5.

5.5.9 Prehľad jednotlivých kategórií údajov

Spresnenie jednotlivých kategórií bude predmetom etapy Analýza a dizajn.

5.6 Technologická architektúra

Technologická architektúra SP je znázornená v diagrame nižšie:

Diagram 46: Technologická architektúra SP

Tabuľka 33 Popis komponentov technologickej architektúry

Súčasťou technologickej architektúry je tiež návrh riešenia APC platformy, ktorá je postavená na technológii Red Hat Openshift Container Platform (OCP). Návrh architektúry je realizovaný v jazyku ArchiMate, ktorý je štandardom na modelovanie architektúry. Linka na úplnú špecifikáciu ArchiMate: Introduction: ArchiMate® 3.2 Specification (opengroup.org)

Návrh predstavuje logický pohľad na aplikačnú a technologickú architektúru. V tomto pohľade nie sú zobrazené inštancie a prostredia. Návrh slúži na objasnenie celkového konceptu APC platformy a ponúkaných služieb.

V diagrame sa používajú hlavne 2 typy relácií - realizácia a serving - príklad je uvedený nižšie na obrázku. Interpretácia týchto relácií je nasledovná: Na databázovom serveri App DB je nasadená technológia Oracle a implementuje službu Databáza (uzavretá šípka znamená implementáciu) a táto služba servuje/obsluhuje aplikáciu App (otvorená šípka predstavuje serving reláciu).

Serving relácia nehovorí o smere toku dát  ani o smere requestov. Definuje iba vzťah typu poskytovateľ služby/konzument služby.

Okrem týchto relácií je v diagrame použitá flow relácia, ktorá predstavuje napríklad tok informácií medzi komponentami.

V diagrame využívame flow na HL modelovanie vzťahov medzi komponentami.