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

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

1. 
   

   1. Použité skratky a pojmy

Tabuľka 1 Skratky a pojmy

1. 
   

   1. Konvencie pre typy požiadaviek (príklady)

Zvoľte si konvenciu pre označovanie požiadaviek, súborov, atď. Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné (funkcionálne), nefunkčné (kvalitatívne, výkonové a pod.). Podskupiny v hlavných kategóriách je možné rozšíriť podľa potrieb projektu, napríklad:

Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:

FRxx

• F – funkcionálna alebo používateľská požiadavka
• R – označenie požiadavky
• xx – číslo požiadavky

Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:

NRxx

• N – nefukčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované Objednávateľom/PM.

1. DEFINOVANIE PROJEKTU

1. 
   

   1. Manažérske zhrnutie

Projekt „Budovanie životných situácií“ pre Národné centrum zdravotníckych informácií (NCZI) vychádza z iniciatívy financovanej cez Plán obnovy a odolnosti Slovenskej republiky. Jeho cieľom je zlepšiť elektronické služby štátu v oblasti zdravotníctva a zvýšiť spokojnosť občanov a podnikateľov s digitálnym ekosystémom verejnej správy.

Hlavné ciele a prístupy:

• Zníženie administratívnej záťaže lekárov – princíp „jedenkrát a dosť“.
• Zvýšenie štruktúrovanosti zdravotnej dokumentácie – umožní automatické generovanie štatistík a hlásení.
• Zlepšenie prepojenosti výkonov a zdravotnej dokumentácie.
• Zvýšenie kvality a dostupnosti elektronických služieb – zrozumiteľné, personalizované a efektívne služby pre občanov.
• Zvýšenie informovanosti a používania e-služieb.

V rámci tohto dokumentu je popísaný projektový zámer pre nasledovné životné situácie, ktoré sú plánované realizovaťv pôsobnosti NCZI. Tento dokument nepopisuje ŽS ako celok.

• ŽS7 Narodenie dieťaťa
• ŽS8 Som chorý, mám chorého člena rodiny
• ŽS11 Materská škola
• ŽS12 Základná škola
• ŽS13 Stredná škola

„Životná situácia 7 – Narodenie dieťaťa“ predstavuje významnú iniciatívu, ktorá má ambíciu zlepšiť a modernizovať spôsob, akým štát podporuje občanov v jednej z ich najdôležitejších a najcitlivejších životných etáp – pri očakávaní a narodení dieťaťa. Táto životná situácia, hoci je osobne radostná a emotívna, je zároveň často organizačne náročná a sprevádzaná vysokou administratívnou záťažou. Už dnes sa ukazuje, že občania čelia mnohým samostatným povinnostiam a procesom, ktoré musia absolvovať na rôznych úradoch a inštitúciách, pričom viackrát predkladajú tie isté údaje a riešia podobné agendy na rôznych miestach.

Súčasný stav zahŕňa kroky od zistenia tehotenstva, cez absolvovanie odborných vyšetrení, informovanie zamestnávateľa, vybavovanie žiadostí o rôzne dávky a príspevky, až po právne úkony ako určenie otcovstva, vybavenie rodného listu a výber pediatra. Tento fragmentovaný a byrokraticky zaťažený proces spôsobuje, že ženy v tehotenstve a mladé rodiny musia venovať veľa času a energie vybavovaniu formalít.

Projekt si kladie za cieľ vytvoriť budúci stav, ktorý zásadne transformuje spôsob poskytovania služieb štátu v tejto oblasti. Navrhované riešenie je postavené na princípe „jedenkrát a dosť“, čo znamená, že občan poskytne potrebné údaje len raz a štát ich ďalej využíva prostredníctvom automatizovanej výmeny medzi zapojenými rezortmi. Tento prístup si vyžaduje úzku spoluprácu medzi Ministerstvom zdravotníctva Slovenskej republiky, Ministerstvom práce, sociálnych vecí a rodiny, Národným centrom zdravotníckych informácií, Sociálnou poisťovňou a Ministerstvom vnútra.

Budúci stav počíta so zavedením viacerých inovatívnych riešení. Jedným z nich je poskytovanie proaktívnych služieb – napríklad automatické priznávanie tehotenskej a materskej dávky (zo Sociálnej poisťovne) a ochranný príspevok (z Úradu práce sociálnych vecí a rodiny). Služby budú doplnené o systém notifikácií, ktorý bude občanov priebežne informovať o stave vybavovania ich žiadostí či stave procesov. Ďalším kľúčovým prvkom je zjednotenie grafického používateľského rozhrania elektronických služieb a portálov, aby boli ľahšie prístupné a používateľsky prívetivé. Projekt zahŕňa aj návrh na zreťazenie jednotlivých atomických služieb do logických celkov, ktoré budú občanovi poskytované ako ucelené návody alebo balíky služieb, čím sa výrazne zlepší orientácia v dostupných možnostiach.

Súčasťou riešenia je aj zavedenie mechanizmov na získavanie spätnej väzby od používateľov, aby bolo možné priebežne vyhodnocovať kvalitu služieb a reagovať na potreby občanov. Významnú rolu zohráva aj optimalizácia legislatívneho a procesného rámca, ktorej cieľom je odstránenie nadbytočných administratívnych krokov a zjednodušenie procesov.

Implementácia projektu je rozdelená do viacerých fáz. Na začiatku bola vykonaná dôkladná analýza súčasného stavu, detailný návrh architektúry riešenia a príprava potrebných legislatívnych zmien. Následne sa plánuje technická realizácia, ktorá zahŕňa úpravy informačných systémov zapojených rezortov, testovanie a overovanie funkčnosti. Plná prevádzka vrátane poskytovania proaktívnych služieb a notifikácií je plánovaná na začiatok roka 2026.

Očakávané prínosy projektu sú významné. Pre občanov znamená zavedenie nového stavu výrazné zníženie administratívnej a časovej záťaže, elimináciu nutnosti opakovaného dokladovania tých istých údajov, lepšiu informovanosť o stave vybavovania a celkovo vyšší komfort pri interakcii so štátom. Pre štát prináša projekt vyššiu efektivitu, lepšie prepojenie rezortov a dátových systémov, rýchlejšie a spoľahlivejšie spracovanie údajov a lepšiu schopnosť pružne reagovať na potreby občanov a úspešnému uplatneniu princípu proaktívnych služieb orientovaných na životné situácie a významným krokom smerom k modernému, digitálne orientovanému štátu.

Životná situácia 8 Som chorý, mám chorého člena rodiny je vytvorená s cieľom

1. Optimalizáce procesu dočasnej práceneschopnosti na základe doterajšej aplikačnej praxe v rámci nasledujúcich oblastí:

• 
  
  • Rozšírenie prístupov k čítacím službám ePN pre zdravotné sestry a iných pracovníkov vymedzených legislatívou
  • Optimalizácia vystavenia odpisu ePN
  • Hromadné vyhľadávanie ePN
  • Ukončenie ePN po úmrtí osoby
  • Rozšírenie XSD štruktúry o informáciu o "lekárovi dohody"
  • Rozšírenie poskytovaných údajov o ePN ÚPSVaR (integrácia s ÚPSVaR)

1. Vybudovanie systému informovania o zaznamenaných potrebách ošetrovania pre nasledujúce oblasti:

• 
  
  • Služby pre IS PZS - Záznam „potreba ošetrovania“ (krátkodobá a dlhodobá eOČR)
  • Odpis OČR
  • Register potrieb ošetrovania v správe NCZI
  • Nové integračné služby pre zainteresované strany (SP, ÚPSVaR)

Pre naplnenie týchto požiadaviek sú popísané nasledovné oblasti:

Elektronizácia ošetrovania člena rodiny (OČR)

• Vytvorenie novej funkcionality pre evidenciu potrieb krátkodobého a dlhodobého ošetrovania
• Integrácia so Soc. Poisťovňou a UPSVAR za účelom výmeny informácií o existencii potreby ošetrovania
• Vytvorenie služieb pre Zdravotníckych pracovníkov pre evidenciu a správu potreby ošetrovania podobne ako pri eDPN.
• Automatická evidencia prerušení potrieb pri hospitalizácií pacienta s evidovanou potrebou ošetrovania na základe správy o príjme pacienta resp. lekárskej prepúšťacej správy
• Notifikovanie zapojených zdravotníckych pracovníkov pri zmenách v potrebe ošetrovania
• Vytvorenie služieb pre poskytnutie papierového odpisu potreby ošetrovania na vyžiadanie občanovi
• Integrácie so Sociálnou poisťovňou a ÚPSVaR

Rozšírenie údajov eDPN

• Údaje o lekárovi, s ktorým má pacient spísanu eDohodu
• Informácia o dátume úmrtia

Rozšírenie zasielania údajov eDPN na ÚPSVaR

• Integrácie s ÚPSVaR

Životné situácie 11, 12 a 13 poskytnú rozšírenia v oblastiach:

• Elektronizácia zdravotníckych potvrdení
• Integrácia s Ministerstvom školstva, vedy a výskumu, napr.:

1. 
   
   1. Ospravedlnenie neprítomnosti dieťaťa
   2. Iné potvrdenia súvisiace so zdravotným stavom (na žiadosť)

• Doplnenie služieb a rozšírenie rozsahu dát zapisovaných do eZdravia (ADL schém)

1. 
   
   1. Potvrdenie o zdravotnej spôsobilosti k žiadosti o prijatie na školu

• Register/evidencia žiadostí a prihlášok

1. 
   
   1. Register detí, žiakov a poslucháčov
       

Pre vyššie uvedené ŽS popisuje DNR funkčný a technický pohľad pre realizáciu súčastí systému, ktorý rozširuje NZIS o funkcie, aplikačné a technické komponenty, tak aby napĺňal ciele a požiadavky zadania.
 

1. 
   

   1. Motivácia a rozsah projektu

V rámci tohto dokumentu je popísaný projektový zámer pre nasledovné životné situácie, ktoré sú plánované realizovaťv pôsobnosti NCZI. Tento dokument nepopisuje ŽS ako celok.

• ŽS7 Narodenie dieťaťa
• ŽS8 Som chorý, mám chorého člena rodiny
• ŽS11 Materská škola
• ŽS12 Základná škola
• ŽS13 Stredná škola

Obrázok 1 Príklad vizualizácie motivácie pre realizáciu projektu

Obrázok 2 Motivácie pre realizáciu projektu v časti ŽS7_Narodenie dieťaťa

Obrázok 3 Motivácie pre realizáciu projektu v časti ŽS8_Som chorý - eDPN

Obrázok 4 Motivácie pre realizáciu projektu v časti ŽS8_Som chorý - eOČR

Obrázok 5 Motivácie pre realizáciu projektu v časti ŽS11, ŽS12, ŽS 13

1. 
   

   1. Zainteresované strany (Stakeholderi)

Tabuľka 2 Zainteresované strany (Stakeholderi)

1. 
   

   1. Ciele projektu

Tabuľka 3 Ciele projektu

1. 
   

   1. Merateľné ukazovatele (KPI)

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

1. 
   

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

Špecifikácia potrieb koncového používateľa je uvedená v katalógu požiadaviek, ktorá je súčasťou prílohy.

1. 
   

   1. Detailný opis obmedzení a predpokladov

Uveďte známe vymedzenie rozsahu projektu, dôvodov pre vymedzenie rozsahu projektu a predpokladov, ktoré by mali byť splnené pre úspešnú realizáciu projektu

1. 
   

   1. Vyhodnotenie rizík a závislostí

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

1. 
   

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

Detailný opis rozpočtu projektu a jeho prínosov je uvedený v prílohe dokumentu CBA.

1. 
   
   1. 
      

      1. Sumarizácia nákladov a prínosov

Uveďte prehľad nákladov a prínosov vychádzajúci z dokumentu M-05 Analýza nákladov a prínosov

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

1. 
   
   1. 
      

      1. Zdroj financovania

Plán obnovy a odolnosti SR, Komponent 17, Investícia 01 – Lepšie služby pre občanov a podnikateľov

1. 
   

   1. Harmonogram projektu

1. 
   

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

Projekt sa bude riadiť v súlade s platnou legislatívou v oblasti riadenia projektov IT. Pre potreby riadenia bude vytvorený riadiaci výbor projektu a budú menovaní členovia Riadiaceho výboru projektu (ďalej len „RV“), projektový manažér a členovia projektového tímu. Riadiaci výbor pre Budovanie životných situácií je spojený s projektom RISEZ. Riadenie projektu zo strany Objednávateľa bude zabezpečené prostredníctvom viacerých projektových manažérov pre RISEZ a projektového manažéra pre ŽS a bude trvať počas celej doby realizácie projektu.

Riadiaci výbor projektu tvorí:

• Predseda RV
• Podpredseda RV
• Zástupca vlastníkov procesov I.
• Zástupca vlastníkov procesov II.
• Zástupca kľúčových používateľov
• Zástupca MZ SR sekcia digitalizácie a informatiky
• Zástupca MZ SR sekcia zdravia
• Zástupca dodávateľa
• Projektový manažér príjamteľa

Pre návrh organizačného zabezpečenia vyplňte tabuľku zodpovedných osôb, ktoré budú participovať v projekte:

Tabuľka 7 Projektový tím

1. LEGISLATÍVA

Vzhľadom na Životnú situáciu 7 – Narodenie dieťaťa boli vypracované nasledovné návrhy zmien:

1) V kmeňovej legislatíve, t. j. v zákone č. 153/2013 Z. z. o národnom zdravotníckom informačnom systéme a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon č. 153/2013 Z. z.")

a) v § 2 sa dopĺňa definícia elektronickej tehotenskej knižky (ďalej len „ETK"),

b) v § 3a ods. 28 + v prílohe č. 2 doplnené ustanovenia súvisiace s oprávnením poskytovať elektronicky Sociálnej poisťovni údaje o tehotenstve na účely posúdenia ochrannej lehoty a posúdenia nároku na tehotenské a materské a poskytovať ÚPSVaR SR tie isté údaje na účely posúdenia splnenia podmienok nároku na pomoc v hmotnej núdzi,

c) v § 5a boli upravené reštrikčné záznamy v súvislosti s utajeným pôrodom, čo bolo potrebné pre elektronizáciu celého procesu,

d) v § 5b bol určený moment vytvorenia a obsah ETK,

e) v § 6 ods. 1 písm. i) bol rozšírený pacientsky sumár o ďalšie informácie o tehotenstve ženy.

2) V zákone č. 576/2004 Z. z. o zdravotnej starostlivosti, službách súvisiacich s poskytovaním zdravotnej starostlivosti a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon č. 576/2004 Z. z.")

a) V § 6b vykonané úpravy súvisiace s elektronizáciou procesu umelého prerušenia tehotenstva,

b) V § 11 ods. 11, § 18 ods. 4 a § 45 ods. 1 písm. p) úpravy týkajúce sa prideľovania fiktívnych identifikačných údajov žene, ktorá požiada o utajený pôrod, potrebné pre elektronizáciu procesu.

3) V zákone č. 73/1986 Zb. o umelom prerušení tehotenstva v znení zákona č. 419/1991 Zb. a zákona č. 363/2011 Z. z.

a) v § 4 upravená možnosť na podanie žiadosti o umelé prerušenie tehotenstva aj elektronicky prostredníctvom občianskeho preukazu.

Životná situácia 8 – Som chorý, mám chorého člena rodiny

1) V kmeňovej legislatíve – zákone č. 153/2013 Z. z.

a) v § 3a ods. 28 + v prílohe č. 2 doplnené ustanovenia súvisiace s oprávnením poskytovať elektronicky Sociálnej poisťovni údaje o starostlivosti v prirodzenom prostredí osoby na účely posúdenia splnenia podmienok nároku na ošetrovné a poskytovať ÚPSVaR SR tie isté údaje na účely posúdenia nespolupráce fyzickej osoby s úradom,

b) v § 6b bol vytvorený nový Register starostlivosti v prirodzenom prostredí osoby, ktorý elektronizoval procesy v rámci OČR a spravil celý proces bezpapierovým,

c) upravená príloha č. 1b týkajúca sa Registra poistných vzťahov, bližšie špecifikované údaje získavané od Sociálnej poisťovne, ÚPSVaRu a zdravotných poisťovní na účely posúdenia ochrannej lehoty a nároku na tehotenské a materské, poskytovanie údajov Ústrediu práce, sociálnych vecí a rodiny na účel posúdenia nároku na pomoc v hmotnej núdzi a nespolupráce fyzickej osoby s úradom práce, sociálnych vecí a rodiny, na účely kontroly poistných vzťahov zdravotníckych pracovníkov.

2) V zákone č. 576/2004 Z. z.

a) V § 12a bol nahradený odpis priamo elektronickým potvrdením,

b) bol doplnený nový § 12b upravujúci starostlivosť osoby v prirodzenom prostredí – OČR.

Životná situácia 11, 12 a 13 - Materská škola, Základná škola, Stredná škola

1) V kmeňovej legislatíve – zákone č. 153/2013 Z. z.

a) v § 3 ods. 2 písm. ac) a ad) bola rozšírená údajová základňa NCZI o údaje z centrálneho registra študentov a centrálneho registra žiakov,

b) v § 3a ods. 28 + v prílohe č. 2 doplnené ustanovenia súvisiace s oprávnením poskytovať elektronicky Ministerstvu školstva, výskumu, vývoja a mládeže Slovenskej republiky údaje pre účely situácií súvisiacich so zdravotným stavom dieťaťa, žiaka a študenta,

c) v § 6b bol vytvorený nový Register potvrdení, ktorý v ods. 1 až 6 elektronizoval procesy súvisiace so zdravotným stavom dieťaťa, žiaka a študenta.

2) V zákone č. 577/2004 Z. z. o rozsahu zdravotnej starostlivosti uhrádzanej na základe verejného zdravotného poistenia a o úhradách za služby súvisiace s poskytovaním zdravotnej starostlivosti v znení neskorších predpisov

a) v prílohe č. 2 určená povinnosť pri 10. a 11. preventívnej prehliadke zapísať elektronicky údaje do registra potvrdení na účely zdravotnej spôsobilosti dieťaťa pre prijatie na predprimárne vzdelávanie podľa osobitného predpisu, ak nebola zistená odchýlka vo fyziologickom vývine dieťaťa.

3) V zákone č. 578/2004 Z. z. o poskytovateľoch zdravotnej starostlivosti, zdravotníckych pracovníkoch, stavovských organizáciách v zdravotníctve a o zmene a doplnení niektorých zákonov v znení neskorších predpisov

a) v § 79 určenie povinnosti poskytovateľom zdravotnej starostlivosti poskytovať NCZI údaje do Registra potvrdení.

1. ARCHITEKTÚRA RIEŠENIA PROJEKTU

V rámci projektu životných situácii sa navrhuje rozšírenie architektúry projektu RISEZ tak aby reflektovali potreby občanov, poskytovateľov zdravotnej starostlivosti a štátnych inštitúcií. Zámerom je digitalizácia procesov, ktoré v súčasnosti prebiehajú výhradne papierovo alebo v neštandardizovanej forme. Prepdokladá sa s vytvorením nových modulov, ktoré pokryjú funkcionalitu eOČR a eTK a s optimalizáciou a rozšírením už existujúceho modulu eDPN. Taktiež sa prepdokladá rozšírenie integrácií s IS tretích strán ako sú CISMA/SP/ÚPSVaR a MINEDU.

Návrh rozšírenia súčasnej architektúry RISEZ o ŽS.

1. 
   

   1. Stanovenie alternatív architektúry riešenia

Výber alternatív architektúry riešenia prebieha v dvoch kolách. Prvé kolo predstavuje uplatnenie multikriteriálnej analýzy (ďalej len „MCA“) – výber relevantných alternatív. Druhé kolo predstavuje vypracovanie Analýzy nákladov M-05 BC/CBA. Do druhého kola vstupujú alternatívy ktoré splnili všetky vylučovacie kritéria stanovené v multikritériálnej analýze. Minimálny počet variant, je stanovený na 3:

• nulový variant, ktorý sa neposudzuje v MCA a je automaticky porovnávajúcim variantom v M-05 Analýza nákladov a prínosov,
• preferovaný variant, ktorý splnil všetky kritéria MCA,
• „minimalistický variant“, ktorý vychádza z rovnakého biznis variantu ako preferovaný variant, ale realizuje iba „nutné“ aplikačné moduly.

Ako alternatívu nepovažujeme porovnanie krabicových „off-the-shelf“ riešení (COTS) riešení s alternatívou vývoja aplikácií „na zelenej lúke“ a to z dôvodu toho, že žiadateľ pre zachovanie nediskriminačných podmienok vo verejnom obstarávaní nevie vopred určiť, či dostane ponuku od uchádzača k vývoju na zelenej lúke, alebo sa všetky ponuky od uchádzačov vo verejnom obstarávaní budú vzťahovať na COTS riešenie. Výnimka je v prípade, ak žiadateľ uvažuje použiť konkrétne COTS riešenie ako podmienku pre uchádzača v rámci procesu verejného obstarávania a to vzhľadom na ekonomické alebo iné dôvody preukázané v dokumente.

1. 
   
   1. 
      

      1. Stanovenie alternatív v biznisovej vrstve architektúry

Rozsah “problému” bol definovaný v rámci prípravy Prioritných životných situácií MIRRI, kde je NCZI jedna zo zainteresovaných strán v rámci riešenia pre nasledovné ŽS:

Životná situácia 7 - Narodenie dieťaťa | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Životná situácia 8 - Som chorý, mám chorého člena rodiny | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Životná situácia 11 - Materská škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Životná situácia 12 - Základná škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Životná situácia 13 - Stredná škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Rámec stanovenia biznis a procesnej vrstvy priamo vyplýva z vyššie uvedených rámcových návrhov. NCZI má v rámci životných situácií definované požiadavky na elektronizované poskytovanie dát a služieb v určitej časti “zákazníckej cesty”, preto zvažovanie iných čiastkových biznis alternatív, a multi-kritériálneho rozhodovania už nie je v tomto prípade relevantné.

KO Kritérium zvoleného návrhu riešenia je naplnenie požiadaviek v rámci stanoveného časového harmonogramu a v rámci poskytnutých finančných prostriedkov.

1. 
   
   1. 
      

      1. Stanovenie alternatív v aplikačnej vrstve architektúry

Alternatívy na úrovni aplikačnej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej biznis vrstvy, pričom vďaka uplatneniu nasledujúcich princípov aplikačná vrstva architektúry dopĺňa informácie k alternatívam stanoveným pomocou biznis architektúry.

Pre klasifikáciu alternatív za účelom ďalšieho porovnania aplikačnej vrstvy a architektúry je potrebné zadefinovať nasledovné požiadavky:

• Nutné – aplikačné moduly/funkcionality, ktoré sú nevyhnutné pre dosiahnutie cieľov
• Preferované – aplikačné moduly/funkcionality, ktoré rozvíjajú biznis alternatívu a vytvárajú dodatočné prínosy, započítané v Analýze nákladov a prínosov M-05 (BC/CBA povinná pre projekty nad 1 000 000,- EUR)
• Aplikačná vrstva by mala byť schopná rozdeliť moduly do skupín podľa koncových služieb/funkcionalít, ktoré plnia nutné a preferované požiadavky.

Obrázok 6 Znázornenie alternatív riešenia v aplikačnej vrstve

1. 
   
   1. 
      

      1. Stanovenie alternatív v technologickej vrstve architektúry

Alternatívy na úrovni technologickej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej aplikačnej vrstvy, pričom sa prioritne uvažuje o využití služieb vládneho cloudu (privátne aj verejné cloudové služby zverejnené v katalógu služieb vládneho cloudu, odkaz na katalóg služieb).

Pred výberom alternatív v technologickej vrstve je potrebné urobiť si klasifikáciu informačných systémov a samostatne nasadzovaných modulov, ktoré budú predmetom riešenia podľa výsledku analýzy alternatív v aplikačnej vrstve. Klasifikácia pomôže riešiteľovi pri výbere alternatív riešenia technologickej vrstvy architektúry a výbere vhodnej skupiny cloudových služieb pre samostatne nasaditeľné moduly riešenia a využití najvhodnejšej kombinácie hybridného cloudového riešenia.

Klasifikáciu urobte podľa Metodického usmernenia pre klasifikáciu ISVS  (023107/2023/oSBATA-1) (odkaz na usmernenie 023107/2023/oSBATA-1: https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/metodicke-usmernenia/)

Tabuľka 8 Klasifikácia budovaných informačných systémov

V prípadoch, kedy by nebolo ekonomicky výhodné využiť služby z katalógu služieb vládneho cloudu v plnom rozsahu projektu, je možné uvažovať aj o iných/ďalších alternatívach: hybridnej (časť aplikácií využíva privátny vládny cloud a časť vlastný HW žiadateľa, resp. časť aplikácii využíva služby komerčného poskytovateľa cloudových služieb), nasadenie v prostredí komerčného cloudu alebo v krajnom prípade sú všetky aplikácie nasadené v prostredí vlastného HW žiadateľa (prípady zohľadnenia bezpečnosti alebo iných povinností).

Ekonomická výhodnosť technologickej alternatívy je preukázaná nižšími nákladmi na TCO projektu. Spracovateľ projektového zámeru je povinný preukázať, že zvolené riešenie je ekonomicky výhodnejšie. V prípade, že z bezpečnostných alebo iných dôvodov nezvolil najvýhodnejšiu alternatívu (resp. neposudzoval viacero alternatív), spracovateľ doloží zdôvodnenie potreby daného technologického riešenia. V zdôvodnení sú uvedené konkrétne požiadavky a ich parametre, ktoré neumožnili zvoliť najvýhodnejšie riešenie alebo porovnať viacero alternatív.

Obrázok 7 Znázornenie alternatív riešenia v technologickej vrstve

1. 
   

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

1. 
   

   1. Biznis vrstva

V tejto kapitole urobte detailnejšie rozpracovanie zvolenej alternatívy riešenia v biznis vrstve architektúry. Uveďte 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.

1. 
   
   1. 
      

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

Obrázok 8 Príklad znázornenia biznis architektúry TO BE pre Epizódu

ŽS7 - eTK

V súčasnej architektúre systému RISEZ nie je implementovaný modul, ktorý by pokrýval funkcionalitu tehotenskej knižky. Celý proces súvisiaci so zdravotnou starostlivosťou o tehotnú ženu, ako aj s uplatnením nárokov na sociálne dávky, prebieha výhradne v papierovej forme.

Tehotenstvo potvrdzuje lekár gynekológ, ktorý stanovuje očakávaný termín pôrodu, zaznamenáva anamnézu a zabezpečuje pravidelné prenatálne kontroly. Údaje sú zaznamenávané do papierovej tehotenskej knižky, ktorá nie je plne štandardizovaná. Táto forma neumožňuje efektívne zdieľanie informácií medzi ošetrujúcimi lekármi, zvyšuje riziko straty alebo neaktuálnosti údajov a kladie administratívnu záťaž na pacientku.

Tehotná žena má počas gravidity nárok na sociálne dávky (napr. tehotenské, materské), ktoré vypláca Sociálna poisťovňa (SP). Na ich posúdenie je potrebné doručiť papierové potvrdenia od lekára. V prípade predčasného ukončenia tehotenstva má žena povinnosť nahlásiť túto skutočnosť SP kvôli ukončeniu výplaty dávky.

Rovnako ženy v domácnostiach v hmotnej núdzi majú nárok na tzv. ochranný príspevok, ktorý sa vypláca od 8. týždňa pred očakávaným dňom pôrodu. Aj v tomto prípade je potrebné predkladať papierovú žiadosť a potvrdenie od lekára.

V rámci riešenia Životnej situácie 7 bude implementovaný nový modul – elektronická tehotenská knižka (eTK). Modul bude komplexne pokrývať celú agendu týkajúcu sa konkrétneho tehotenstva – od jeho potvrdenia až po pôrod alebo jeho predčasné ukončenie (potrat, umelé prerušenie tehotenstva), vrátane evidencie komplikácií počas a po tehotenstve.

Hlavné funkcionality a prínosy modulu eTK:

• Elektronické vytvorenie eTK na základe štruktúrovaného záznamu z vyšetrenia tehotnej ženy, ktoré už systém RISEZ podporuje.
• Zdieľanie eTK medzi ošetrujúcimi lekármi – zabezpečenie kontinuity a kvality prenatálnej starostlivosti.
• Náhrada papierovej tehotenskej knižky, pričom v prípade potreby bude možnosť vystavenia papierového výpisu.
• Automatizovaný prenos údajov tretím stranám (napr. SP, ÚPSVaR), čím sa odstráni potreba predkladania potvrdení zo strany pacientky.
• Zvýšenie kvality údajov a podpora generovania povinných hlásení a štatistík pre poskytovateľov zdravotnej starostlivosti (PZS).
• Elektronizácia dohody o mene a priezvisku dieťaťa:
• Matka a otec budú môcť dohodu potvrdiť elektronicky prostredníctvom eID, dohoda bude elektronicky zaslaná do registra CISMA ako súčasť hlásenia o narodení.

Dopady a súvislosti:

• Riešenie prispeje k digitalizácii zdravotnej a sociálnej agendy súvisiacej s tehotenstvom.
• Zníži administratívnu záťaž pre ženy, lekárov, aj inštitúcie (SP, ÚPSVaR).
• Vyžaduje si integráciu s externými systémami (napr. CISMA, SP) a zosúladenie údajových štandardov.

ŽS 8 - eOČR

V aktuálnej architektúre systému nie je implementovaný modul, ktorý by podporoval elektronické spracovanie OČR. Celý proces prebieha výlučne manuálne, čo predstavuje vysokú administratívnu záťaž pre občanov, lekárov, zamestnávateľov a Sociálnu poisťovňu (SP).

Proces oČR začína žiadosťou občana o vystavenie potvrdenia o potrebe ošetrovania od ošetrujúceho lekára. Lekár vystaví a potvrdí papierové tlačivo, ktoré v prípade zamestnanca následne potvrdzuje aj zamestnávateľ. Zamestnanec doručuje žiadosť SP osobne alebo poštou. Ak ide o samostatne zárobkovo činnú osobu (SZČO) alebo dobrovoľne nemocensky poistenú osobu (DNPO), musí sama vyplniť potrebné údaje a zaslať žiadosť do SP. V prípade chýb alebo neúplných údajov SP iniciuje korešpondenčnú výzvu na doplnenie údajov.

Po skončení potreby ošetrovania vystavuje lekár tzv. II. diel tlačiva – potvrdenie o skončení potreby osobného a celodenného ošetrovania. Opätovne je potrebné doručenie dokumentu SP, prípadne jeho predchádzajúce potvrdenie zamestnávateľom. Pred samotným vyplatením dávky Sociálna poisťovňa zohľadňuje poberanie iných dávok, napr. v hmotnej núdzi, a občanovi vypláca len rozdiel.

Tento spôsob je náchylný na chyby, zdĺhavý a zaťažuje všetkých účastníkov procesu

Budúci stav – eOČR

V rámci projektu Životných situácií sa plánuje rozšírenie riešenia o nový modul eOČR, ktorý zabezpečí komplexnú elektronickú podporu procesu žiadosti o krátkodobé aj dlhodobé ošetrovné. Tento modul bude tvoriť integrálnu súčasť RISEZ ekosystému a významne zjednoduší celý proces.

Hlavné ciele a prínosy riešenia:

• Zavedenie novej elektronickej služby, prostredníctvom ktorej bude môcť občan iniciovať žiadosť o ošetrovné digitálne, bez potreby fyzického kontaktu so Sociálnou poisťovňou alebo zamestnávateľom.
• Zrušenie oznamovacích povinností občana voči zamestnávateľovi a ÚPSVaR, a to aj v prípade, že je poberateľom pomoci v hmotnej núdzi alebo je nezamestnaný.
• Rozšírenie a úprava dátových štruktúr, najmä:
  • záznamov z vyšetrenia v kontexte potreby ošetrovania,
  • doplnenie objektov evidencie potrebných pre výpočet a posúdenie nároku na dávku,
  • zosúladenie údajov poskytovaných Sociálnej poisťovni.
• Zabezpečenie dostupnosti a editovateľnosti informácie o potrebe ošetrovania ošetrujúcim lekárom vrátane možnosti jej aktualizácie alebo ukončenia.
• Automatizácia výmeny údajov medzi NCZI a SP, vrátane validácií a aplikačných kontrol, ktoré minimalizujú výskyt chýb a potrebu dodatočných korekcií.

Dopady a súvislosti:

• Podpora životnej situácie eOČR prispeje k celkovej digitalizácii verejnej správy a zefektívneniu interakcie medzi občanmi a štátom.
• Realizácia si vyžiada úpravy aj na strane SP a ÚPSVaR – predovšetkým vo forme prijímania a spracovania dát cez integračné rozhrania.
• Riešenie bude navrhnuté s dôrazom na bezpečnosť, ochranu osobných údajov a interoperabilitu so systémami tretích strán.

Návrh nových procesov, ktoré bude pokrývať novovzniknutý modul.

Návrh biznis architektúry nového modulu, ktorá bude zabezpečovať funkcionalitu eOČR.

ŽS 8 - eDPN

Modul eDPN v súčasnosti zabezpečuje elektronické vystavovanie potvrdení o dočasnej pracovnej neschopnosti, ktoré lekár odosiela priamo do Sociálnej poisťovne. Zavedením tohto riešenia sa eliminovala potreba fyzického vypĺňania a doručovania papierových tlačív. Modul zároveň automaticky informuje zamestnávateľa o vzniku pracovnej neschopnosti, čím sa celý proces výrazne urýchľuje, zefektívňuje a znižuje administratívnu záťaž pre všetky zúčastnené strany.

Funkcionalita modulu eDPN prispieva k zníženiu výskytu chýb pri vypĺňaní potvrdení, zabezpečuje bezpečný prenos údajov medzi lekárom, Sociálnou poisťovňou a zamestnávateľom, a posilňuje elektronizáciu zdravotníckych a sociálnych procesov v zmysle platnej legislatívy.

Budúci stav – optimalizácia a rozšírenie funkcionality

Na základe aplikačnej praxe, získaných prevádzkových skúseností a legislatívnych požiadaviek sa predpokladá rozsiahla optimalizácia procesu dočasnej pracovnej neschopnosti. Cieľom úprav je zefektívniť a stabilizovať riešenie, odstrániť zistené nedostatky a rozšíriť funkcionalitu tak, aby reflektovala aktuálne potreby praxe.

Medzi hlavné oblasti plánovanej optimalizácie patria:

• Revízia a rozšírenie existujúcich biznis pravidiel a kontrol s cieľom zvýšiť kvalitu a konzistenciu údajov.
• Úprava a rozšírenie existujúcich služieb a implementácia nových služieb, reflektujúcich požiadavky vyplývajúce zo zmien legislatívy a potrieb zainteresovaných strán.
• Rozšírenie dátových štruktúr s dôrazom na:
  • zosúladenie medzi ADL modelmi a XSD schémami
  • doplnenie chýbajúcich dátových typov
  • zaradenie nových údajov podľa potrieb Sociálnej poisťovne a ÚPSVaR
• Zvýšenie výkonu zápisových služieb, s dôrazom na spoľahlivé a rýchle odosielanie údajov tretím stranám, vrátane inštitúcií sociálneho zabezpečenia.
• Rozšírenie výstupných údajov o eDPN určených pre Úrad práce, sociálnych vecí a rodiny (ÚPSVaR), čím sa zabezpečí komplexnejšie využitie elektronických potvrdení v sociálnych agendách.

Cieľom plánovaných zmien je poskytnúť robustnejšiu a výkonnejšiu platformu pre evidenciu dočasnej pracovnej neschopnosti, ktorá bude schopná reagovať na nové legislatívne požiadavky, technologické výzvy aj potreby koncových používateľov.

Mapa procesov, ktoré pokrýva eDPN a o ktoré bude modul rozšírený.

Návrh biznis architektúry modulu eDPN.

V súčasnej architektúre sa nenachádza modul, ktorý by pokrýval funkcionalitu požadovanú funkcionalitu v rámci ŽS 11,12,13.

V rámci plánovaného rozvoja sa predpokladá vytvorenie nového modulu, ktorý zabezpečí obojsmernú elektronickú komunikáciu medzi NCZI a Ministerstvom školstva, vedy, výskumu a športu Slovenskej republiky MŠVVaM. Prostredníctvom tohto rozhrania bude možné na základe autorizovaného dopytu poskytnúť lekárske potvrdenie alebo ospravedlnenie zo zdravotných dôvodov pre konkrétneho žiaka alebo študenta, a to z centrálneho registra potvrdení vedeného NCZI.

Súčasťou tohto riešenia bude aj integrácia na CSRU, ktorá umožní automatizovaný prenos, synchronizáciu a replikáciu údajov z registra detí, žiakov a študentov. Synchronizácia bude realizovaná na dennej báze, s cieľom zabezpečiť aktuálnosť a úplnosť údajov potrebných pre vydávanie potvrdení.

Funkcionalita modulu bude poskytovať oprávneným zdravotníckym pracovníkom – lekárom – možnosť vystaviť potvrdenia a ospravedlnenia na základe žiadosti zákonného zástupcu žiaka alebo študenta, a to prostredníctvom elektronických služieb sprístupnených cez IS PZS.

Zároveň bude modul zabezpečovať správu a evidenciu žiadostí a prihlášok v súvislosti s vydávaním lekárskych potvrdení pre nasledovné účely:

• prijatie dieťaťa na predprimárne vzdelávanie,
• pokračovanie v povinnom predprimárnom vzdelávaní,
• prijatie na základné vzdelávanie dieťaťa, ktoré nedovŕšilo šiesty rok veku,
• vzdelávanie v strednej škole – pre vybrané učebné a študijné odbory, kde sa vyžaduje potvrdenie zdravotnej spôsobilosti.

1. 
   
   1. 
      

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

V nasledujúcej tabuľke uveďte prehľad budovaných a rozvíjaných Koncových služieb. Údaje o koncových službách treba zapísať do MetaIS ako súčasť výstupu M-06.

Tabuľka 9Prehľad koncových služieb - budúci stav (TO BE)

Požiadavky na realizáciu a zmenu Koncových služieb zapíšte aj do Katalógu požiadaviek.

1. 
   
   1. 
      

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

• Organizačné dopady nebudú priamo dotknuté týmto projektom.
• Dotknuté procesy sú uvedené v predchádzajúcej kapitole  Návrh riešenia v biznis vrstve architektúry
• Procesy vychádzajú z rámcových procesov definovaných v Projekte budovania prioritných životných situácií (link: Prioritné životné situácie | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR) pre nasledujúce životné situácie
• Životná situácia 7 - Narodenie dieťaťa | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
• Životná situácia 8 - Som chorý, mám chorého člena rodiny | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
• Životná situácia 11 - Materská škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
• Životná situácia 12 - Základná škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
• Životná situácia 13 - Stredná škola | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Procesné diagramy za časť NCZI, sú súčasťou Detailného návrhu riešenia predmetných Životných situácií.

1. 
   
   1. 
      

      1. Jazyková podpora lokalizácia

Jazyková podpora lokalizácie je slovenská

1. 
   

   1. Aplikačná vrstva

V súčasnom stave neposkytuje v aplikačnej architektúre NZIS, aplikačné a integračné komponenty pre poskytovanie požadovaných funkcií predmetných životných situácií. Je preto nevyhnutné vybudovať v rámci TO BE stavu takéto komponenty,

Zvolená alternatíva TO BE stavu predpokladá vybudovanie aplikačných komponentov eZdravia, ktoré sú nevyhnuté na zabezpečenia procesnej ako aj technologickej časti životných situácií.

V rámci projektu Projekt rozvoja IT, Budovanie životných situácií pre organizáciu NCZI v MetaIS sú definované navrhované aplikačné služby:

1. 
   
   1. 
      

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

Služby budú vybudované v rámci komponentov IS NZIS.

Návrh aplikačných komponentov pre jednotlivé ŽS pre búdúci stav:

Návrh aplikačnej architektúry eTK :

Návrh aplikačnej architektúry eOČR:

Návrh aplikačnej architektúry eDPN

1. 
   
   1. 
      

      1. Rozsah informačných systémov – budúci stav (TO BE)

Uveďte informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu – budúci stav (TO BE):

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

1. 
   
   1. 
      

      1. Využívanie nadrezortných a spoločných ISVS – AS IS

Informácie o využívaných, resp. nevyužívaných nadrezortných ISVS (Spoločných ISVS a spoločných blokov SaaS) – AS IS stav.

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

1. 
   
   1. 
      

      1. 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)

Uveďte plánované využívanie nadrezortných a spoločných ISVS v TO BE stave.

Povinnosť využívať nadrezortné ISVS ustanovuje najmä zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) a iné legislatívne predpisy. Prehľad a informácie o nadrezortných ISVS sú uvedené v prílohe P8 Zoznam nadrezortných blokov a podporných spoločných blokov Používateľskej príručky MetaIS.

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

1. 
   
   1. 
      

      1. Prehľad plánovaných integrácií na iné ISVS – budúci stav (TO BE)

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

1. 
   
   1. 
      

      1. Aplikačné služby pre Koncové služby – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke budované alebo rozvíjané aplikačné služby, ktoré sú potrebné pre poskytnutie Koncovej služby – vzťah „Aplikačná služba slúži Koncovej službe“. Koncovú službu by mala podporovať aspoň jedna aplikačná služba. Koncovú službu môže podporovať aj viac aplikačných služieb. Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS (vzťah „Aplikačná služba slúži Koncovej službe“).

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

1. 
   
   1. 
      

      1. Aplikačné služby na integráciu – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS (ako konzument) alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS):

• Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIS evidované všetky povinné atribúty a vzťahy,
• Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného alebo rozvíjaného ISVS na príslušné aplikačné služby spoločných modulov ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS. Detailný popis služieb spoločných modulov (IS CPDI, modulov ÚPVS) určených na integráciu je v aktuálnej verzii integračného manuáloch týchto ISVS.
• Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gateway).
• Budované aplikačné služby musia mať v MetaIS evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS.

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

• Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona č. 305/2013 Z. z. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:

1. 
   

   1. Dátová architektúra

Na diagramoch nižšie je zobrazený navrhovaný stav logického dátového modelu pre jednotlivé ŽS:

V rámci projektu ŽS bol vytvorený návrh logického dátového modelu pre ŽS7 eTK :

V rámci projektu ŽS bol vytvorený návrh logického dátového modelu pre ŽS8 eDPN :

V rámci projektu ŽS bol vytvorený návrh logického dátového modelu pre ŽS8 eOČR :

1. 
   
   1. 
      

      1. Objekty evidencie

Pre NCZI časť životných situácií nie sú relevantné Objekty Evidencie v zmysle ISVS nakoľko prenos údajov je navrhovaný v zmysle štandardov zdravotníckej informatiky - Štandardy zdravotníckej informatiky a priamych integrácií.

1. 
   
   1. 
      

      1. Referenčné údaje

V rámci projektu ŽS nie sú navrhované zmeny alebo doplnenia referenčných údajov.

1. 
   
   1. 
      

      1. Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

Pre NCZI časť životných nie sú relevantné Objekty Evidencie v zmysle ISVS nakoľko prenos údajov je navrhovaný v zmysle štandardov zdravotníckej informatiky - Štandardy zdravotníckej informatiky a priamych integrácií.

Uveďte

 

1. 
   
   1. 
      

      1. Kvalita a čistenie údajov

Pre NCZI časť životných nie sú relevantné metódy kvality a čistenia údajov v zmysle ISVS nakoľko manažment údajov je navrhovaný v zmysle štandardov zdravotníckej informatiky - Štandardy zdravotníckej informatiky a priamych integrácií.

1. 
   
   1. 
      

      1. Otvorené údaje

Pre NCZI časť životných nie sú relevantné otvorené údaje, NCZI publikuje Štatistické výstupy, ktorých vstupom môžu byť v budúcnosti aj čiastkové údaje zo životných situácií, avšak oblasť štatistík a vykazovania nie je predmetom projektu ŽS.

1. 
   
   1. 
      

      1. Analytické údaje

NCZI publikuje Štatistické výstupy, ktorých vstupom môžu byť v budúcnosti aj čiastkové údaje zo životných situácií, avšak oblasť analýzy údajov nie je predmetom projektu ŽS.

1. 
   
   1. 
      

      1. Moje údaje

Moje údaje v zmysle pristupovania prostredníctvom modulu procesnej integrácie a integrácie údajov (IS CPDI (CSRÚ)) pre modul Manažmentu osobných údajov nie sú predmetom riešenia ŽS v časti NCZI.

1. 
   
   1. 
      

      1. Prehľad jednotlivých kategórií údajov

Pre NCZI časť životných situácií nie je relevantná kategorizácia údajov v zmysle ISVS nakoľko prenos údajov je navrhovaný v zmysle štandardov zdravotníckej informatiky - Štandardy zdravotníckej informatiky a priamych integrácií.

1. 
   

   1. Technologická architektúra

1. 
   
   1. 
      

      1. Návrh riešenia technologickej architektúry

Technologická architektúra je v súlade s projektom RISEZ, ktorý zabezpečuje technologickú architektúru pre ŽS a nepredpokladajú sa žiadne zmeny. Technologická architektúra bude budované v rámci infraštruktúry NCZI ako paralelná aktivita a nie je predmetom tohto projektu.

1. 
   
   1. 
      

      1. Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

Informačný systém musí zvládnuť obslúžiť min. 2 000 súčasných používateľov v jednom okamihu s dobou odozvy do 5 sekúnd.

Odozva služieb pri testovaní záťaže systému: - 80% z meraných testovacích volaní v pomere zápis a čítanie 1:2 má odozvu kratšiu alebo rovnú 2 sekundy, - 15% z meraných testovacích volaní v pomere zápis a čítanie 1:2 má odozvu kratšiu alebo rovnú 5 sekúnd, - 5% z meraných testovacích volaní v pomere zápis a čítanie 1:2 má odozvu najviac 10 sekúnd,

Simulácia sa vykonáva podľa dát z reálnej prevádzky existujúcich služieb NZIS.

Počet volaní a interakcia s koncovými používateľmi a IS PZS je určená podľa špičiek v prevádzke Pondelok – Piatok, 07:00 – 13:00 prebehne 90% všetkých volaní služieb, z toho v pondelok prebehne 25% všetkých volaní.

IS bude nasadený do nasledovných prostredí:

1. 
   
   1. 
      

      1. Využívanie služieb z katalógu služieb vládneho cloudu

Zaevidujte v MetaIS využívanie infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS.

V nasledovnej tabuľku uveďte prehľad plánovaného využitia infraštruktúrnych - cloudových služieb pre navrhované ISVS. Pri výbere vhodných cloudových služieb okrem technologických požiadaviek zohľadnite klasifikáciu budovaných a rozvíjaných ISVS, ktorú ste urobili pri výbere vhodnej technologickej architektúry v

v časti 5.1.3 Stanovenie alternatív v technologickej vrstve architektúry. Zvolená infraštruktúrna služba by mala byť zaradená do rovnakej alebo vyššej klasifikačnej úrovne ako ISVS, ktorý ju bude využívať.

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

Uveďte parametre (kapacity) požadovaných výpočtových zdrojov (sizing) a využite služieb hybridného vládneho cloudu (uvedené v tabuľkách nižšie) pre jednotlivé prevádzkové prostredia:

• Vývojové – určené pre vývoj systému
• Testovacie – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgradeov (nie pre záťažové testovanie).
• Produkčné – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie

Poznámky:

Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.

V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.

V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách vládneho cloudu. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: Katalóg cloudových služieb (https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.)

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

Určite v štruktúrovanej podobe ďalšie potrebné infraštruktúrne alebo iné cloudové služby (PaaS, SaaS) potrebné na prevádzku projektu podľa katalógu cloudových služieb. Tabuľky si treba prispôsobiť, aby čo najlepšie odpovedali podmienkam návrhu riešenia a charakteristikám zvolených cloudových služieb:

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

Požiadavky na služby vládneho cloudu odporúčame mať ešte pred vyhlásením VO odkomunikované s prevádzkovateľom vládneho cloudu (napr. MV SR) v súlade s postupom zverejneným na webovom sídle https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/

1. 
   

   1. Bezpečnostná architektúra

Bezpečnostná architektúra je v súlade s projektom RISEZ, ktorý je základnou platformou pre rozšírenia komponentov ŽS, a ktorý implementuje základnú bezpečnostnú architektúru s nasledovnými požiadavkami: .

V rámci projektu RISEZ/ŽS bude využitá metodika DEVSECOPS, ktorá rozšíri SDL metodiku pre ezdravie a zachová bezpečný prechod od dizajnu cez vývoj až po overenie, že IS je navrhnutý v súlade s platnou legislatívou a je pripravené pre nasadenie do produkčnej prevádzky tak, aby funkčnosť bola použiteľná s cieľom dosiahnutia KPI.

V rámci implementácie bude vykonaný nezávislý bezpečnostný audit, vrátane auditu zdrojového kódu mobilných aplikácii a penetračných testov podľa metodiky Open Web Application Security Project (OWASP): - Vykonanie auditu a analýzu rizík a hrozieb komponentov, ktoré sú výstupom plnenia Diela.

- Štruktúrovaný popis nálezov auditu vo formáte XLS s prioritizáciou a návrhom riešenia.

- Overenie zapracovanie pripomienok a odstránenia nálezov brániacich riadnemu používaniu IS .

1. 
   
   1. 
      

      1. Návrh riešenia bezpečnosti

IS bude implementovaný v zmysle bezpečnostných požiadaviek a mechanizmov podľa Zákonov o Kybernetickej bezpečnosti, o ITVS a ich aktuálnych vyhlášok v čase pred a počas implementácie PZ. Zhotoviteľ dodá detailný výstup súladov s checklistom pre agendu IT a KYBERNETICKÚ BEZPEČNOSŤ pre kategóriu III., podľa Metodiky Riadenia kvality (QAMPR).

V rámci RISEZ bude vytvorená:

• Bezpečnostná architektúra, ktorá musí riešiť systém ochrany implementovaný technickými prostriedkami, t. j. dedikovanými bezpečnostnými prostriedkami ako aj prostriedkami tvoriacimi súčasť aplikačných komponentov a infraštruktúry a netechnickými prostriedkami pre manažment informačnej bezpečnosti
• Bezpečnostné testy Zhotoviteľom (Penetračné, Security Review, Riziková analýza)
• Bezpečnostné testy externým subjektom (audit)

1. 
   
   1. 
      

      1. Určenie obsahu bezpečnostných opatrení

²³

1. 
   
   1. 
      

      1. Legislatívne, právne, štatutárne, regulačné a zmluvné požiadavky,

Riešenie bude navrhované v súlade s legislatívou v oblasti zdravotníctva, zdravotníckej informatiky, informatizácie a bezpečnosti a to najmä:

• Zákonom o ITVS
• Zákonom o kybernetickej bezpečnosti
• Zákonom o eGovernment
• Zákonom o ochrane osobných údajov
• Relevantnými normami a vyhláškami o štandardoch
• Metodikou o riadení projektov MIRRI

Zoznam relevantných právnych noriem:

• Zákon č.153/2013 Z.z. o národnom zdravotníckom informačnom systéme a o zmene a doplnení niektorých zákonov
• Vyhláška Ministerstva zdravotníctva SR č. 431/2024 Z.z. ktorou sa mení vyhláška Ministerstva zdravotníctva Slovenskej republiky č. 107/2015 Z. z., ktorou sa ustanovujú štandardy zdravotníckej informatiky a lehoty poskytovania údajov v znení vyhlášky č. 34/2022 Z. z.
• Vyhláška Ministerstva zdravotníctva SR č. 34/2022 Z.z. ktorou sa mení vyhláška Ministerstva zdravotníctva Slovenskej republiky č. 107/2015 Z. z., ktorou sa ustanovujú štandardy zdravotníckej informatiky a lehoty poskytovania údajov

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Vyhláška 362/2018 Z. z. ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

1. 
   
   1. 
      

      1. Riešenie autentifikácie a prístupov používateľov

Požiadavky na riešenie bezpečnosti, správa používateľov, zabezpečenie prístupov k dátam a pod. sú zabezpečované riešením NZIS resp. jeho rozšírenia RISEZ

1. PREVÁDZKA A ÚDRŽBA VÝSTUPOV PROJEKTU

1. 
   

   1. Návrh riešenia prevádzky a údržby

Prevádzka a údržba je technologicky navrhnutá v rámci podpory NZIS resp. rozšírenia RIZES.

1. 
   

   1. Zabezpečenie podpory používateľov a prevádzky

Zabezpečovanie podpory používateľov a prevádzky.

Podpora prevádzky a používateľov buderealizovaná cez 3 úrovne podpory, s nasledujúcim označením a obsahom činnosti:

• Podpora L1 (podpora 1. stupňa - Level 1) - začiatočná úroveň podpory, ktorej základnou funkciou je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď. Je zabezpečovaná prostredníctvom pracoviska jednotného kontaktného miesta.

• Podpora L2 (podpora 2. stupňa – Level 2 - postúpenie požiadaviek od L1) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.

• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobtiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Typické zodpovednosti za realizáciu podpory sú:

• L1 (Level 1: priamy kontakt zákazníka) - jednotný kontaktný bod verejného obstarávateľa je zvyčajne zabezpečovaný pracoviskom v správe správcu informačného systému, ak nedeleguje túto činnosť na špecializovanú organizáciu v jeho zriaďovacej pôsobnosti ( NCZI Call centrum) .
• L2 (Level 2: postúpenie požiadaviek od L1) - riešiteľské tímy s hlbšou znalosťou prevádzkovaného systému sú zvyčajne tvorené pracovníkmi prevádzkovateľa informačného systému ( NCZI Helpdesk), pričom časť špecializovaných prác môže byť za definovaných podmienok prenesená aj na externého dodávateľa.
• L3 (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore inf. systému bude zabezpečovať externý dodávateľ.

Okrem zabezpečenia podpory používateľov a prevádzky je potrebné určiť spôsob a rozsah zabezpečenia podpory infraštruktúrnych služieb použitých pre prevádzku informačného systému (cloudové služby, komunikačné služby, servery a ich systémové programové vybavenie, sieťová infraštruktúra) a určiť zodpovednosti pri zabezpečení prevádzky technologickej infraštruktúry a spôsob komunikácie s poskytovateľom podpory infraštruktúrnych služieb.

V nasledovnej tabuľke uveďte prehľad očakávaného riešenia zabezpečenia podpory používateľov a prevádzky, hlavné zodpovednosti a očakávanú úroveň poskytovaných služieb:

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

Uveďte a tiež do Katalógu požiadaviek zapíšte špeciálne požiadavky týkajúce sa zabezpečenia jednotlivých úrovní podpory, predpokladané obmedzenia alebo rozšírenia služieb a zodpovednosti niektorej úrovne podpory, ktoré bude potrebné zohľadniť pri realizácii projektu a ktoré môžu mať vplyv na rozsah prác dodávateľa riešenia a cenu projektu.

1. 
   

   1. Riešenie incidentov v prevádzke - parametre úrovní služby

V nasledovnej kapitole sú uvedené očakávané úrovne poskytovania služieb, kategorizácia vád v prevádzke a lehoty ich vyriešenia.

Vada úrovne A (1): je kritická vada / havária, ktorá spôsobuje tak závažné problémy, že ďalší priebeh, ani dodržanie predpokladaného časového plánu akceptačných testov nie je možné; Používateľ nemôže Systém alebo iný informačný systém priamo integrovaný na Systém alebo ich časť používať alebo ovládať, resp. ide o vady jeho bezpečnosti; ďalšie akceptačné testy musia byť pozastavené, dokiaľ nie je vada odstránená; alebo ďalšie fungovanie SW Systému alebo iného naň integrovaného informačného systému nemôže byť rozumne zaručené. Vady prvej úrovne A by spôsobili veľkú stratu alebo úplné znemožnenie samotnej podstaty využitia Systému alebo iného naň integrovaného informačného systému alebo ich časti alebo by spôsobili, že by bolo použitie Systému/naň integrovaného informačného systému/ich časť nebezpečné, alebo že sa Systém alebo iné systémy Používateľa zastavia alebo poškodia. Vadou prvej úrovne A je aj to, že SW nie je schopný spracovať bežnú prevádzkovú záťaž

Vada úrovne B (2): je vážna vada/ porucha, ktorá, ak nie je opravená, by ohrozila ďalšie pokračovanie akceptačných testov, alebo by vážne ohrozovala ďalšiu prevádzku iných častí SW Systému alebo iného informačného systému priamo integrovaného na Systém. Vada druhej úrovne B by zapríčinila, že by neboli podporované niektoré časti funkcií softvérového vybavenia bez rozumnej náhrady. Takouto vadou je aj neschopnosť spracovať maximálnu možnú prevádzkovú záťaž

Vada úrovne C (3): je bežná vada, bežná porucha, ktorá nie je Vadou úrovne A (1) ani Vadou úrovne B (2), najmä vada, ktorá spôsobí čiastočný neúspech akceptačných testov, alebo ktorá sa prejaví iba niekedy. Za bežných podmienok by nebola stratená žiadna dôležitá funkcia Systému ani iného informačného systému priamo integrovaného na Systém alebo by bolo možné pre jej prekonanie nájsť rozumnú alternatívu. Táto vada by neohrozila Systém ani iný informačný systém Používateľa ľa priamo integrovaný na Systém s reálnymi dátami.

Lehoty na odstránenie Vád počas záručnej doby Lehoty na odstránenie Vád začínajú plynúť okamihom nahlásenia Vady Používateľom a rozdeľujú sa nasledovne: a) lehota reagovania na nahlásenú Vadu, b) lehota náhradného riešenia Vady, c) lehota trvalého vyriešenia Vady.

Lehota reagovania na nahlásenú Vadu je stanovený čas, do ktorého vykoná prevzatie, potvrdenie prevzatia a preverenie nahlásenej Vady a zaháji jej riešenie konkrétnym riešiteľom.

* Pozn.: pracovným časom je doba vymedzená počas pracovných dní v čase od 8:00 do 17:00 hod.

Úroveň poskytovania služieb sa riadi internými predpismi NCZI.

1. 
   

   1. Požadovaná dostupnosť informačného systému:

Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok.

1. 
   

   1. Požiadavky na ľudské zdroje potrebné pre zabezpečenie prevádzky

Uveďte požiadavky na personálne zabezpečenie prevádzky budovaného systému (TO BE) a súvisiacich prevádzkových procesov.

Uveďte požiadavky na zabezpečenie potrebných školení a certifikátov pre používateľov, pracovníkov podpory, prevádzky a správy budovaného systému.

1. 
   

   1. Požiadavky na zdrojové kódy

Spôsob zabezpečenia dodávky zdrojových kódov aplikačných častí riešenia a ich dokumentácie sa bude riadiť podľa § 15 ods. d) zákona č. 95/2019 Z.z. a zabezpečenia dispozičných práv (licencií) k zdrojovým kódom, ich dokumentácii a projektovým výstupom zhotovených dodávateľom.

Dodávateľ bude povinný dodať zdrojové kódy mini. podľa nasledovných požiadaviek:

• Zdrojové kódy s popisom v elektronickej forme na centrálny repozitár dokumentácie
• V rámci zmluvy o dielo bude dojednané dodanie aktuálnych a úplných zdrojových kódov,
• Zdrojový kód musí byť spustiteľný v prostredí NCZI a musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, tzn. umožňujúcej kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) takejto časti systému.
• Zároveň odovzdaný zdrojový kód musí byť pokrytý testami (aspoň na 90%), musí dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQL atď. (minimálne stupňa B). Zdrojový kód bude odovzdaný v súlade s metodikou DevSecOps na centrálny repozitár dokumentácie
• NCZI bude môcť zdrojový kód alebo jeho zmeny neobmedzene používať, rozširovať, upravovať zdrojový kód bez súhlasu dodávateľa a zdieľať s akýmikoľvek tretími osobami
• Vytvorený zdrojový kód vrátane dokumentácie zdrojového kódu bude môcť byť zverejnený na základe rozhodnutia NCZI podľa Vyhlášky o štandardoch pre ITVS
• Zdrojový kód a jeho časti budú spĺňať podmienky Zákona o ITVS

Ďalšie a podrobnejšie formulácie budú predmetom zmluvy o dielo s dodávateľom.

1. OPIS IMPLEMENTÁCIE PROJEKTU A PREBERANIA VÝSTUPOV PROJEKTU

Spôsob realizácie projektu, harmonogram projektu a ich dopad na preberanie výstupov pripravovaného projektu bude prebiehaťvzmysle vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou metódou waterfall s prvkami metódy agile.

Výstupy projektu:

R1 Realizačná fáza:

• R1- 01 Detailný návrh riešenia (DNR)
• R1-2 Plán a stratégia testovania

R3 Implementácia a testovanie

• R3-1 Vývoj, migrácia údajov a integrácia
• R3-2 Testovanie
• R3-3 Školenia personálu

R3-4 Dokumentácia

R4 NASADENIE a POSTIMPLEMENTAČNÁ PODPORA (PIP)

Dokončovacia fáza

M-02 Manažérske správy, plány:

Dokumenty budú vychádzať a nadväzovať na dokumentáciu projektu RISEZ, s ktorým zdieľa základné moduly pre rozšírenie ŽS.

V súlade s princípmi uvedenými v dokumente „Referenčná architektúra Informačného systému verejnej správy v cloude" je pre časti, ktoré sa majú nachádzať v cloude požadované realizovať ich formou natívnych cloudových aplikácii. Natívna cloudová architektúra zahŕňa sadu pravidiel a princípov, ktoré vedú k vyššej schopnosti absorbovať (pomocou jasného oddelenia unikátnej biznis logiky aplikácie od IT prostredia/zdrojov/infraštruktúry/zdieľaných modulov, či aplikácií prostredníctvom rozhraní) a lepšie využívať (napr. biznis logika je písaná tak, aby vedela v každom kroku spracovania využívať možnosť paralelizácie a bolo ju tak možné flexibilne škálovať) dynamicky sa meniace prostredie, v ktorom je daný ISVS prevádzkovaný.

Z pohľadu samotnej prevádzky je natívna cloudová architektúra postavená na filozofii štandardizácie (štandardizované prostredia, zjednotené prevádzkové postupy), vďaka ktorému zrýchľuje celý proces, znižuje riziko (výpadkov) nasadzovania nových verzií (tzv. kontinuálny vývoj), a v neposlednom rade optimalizuje (ľudské) zdroje potrebné na prevádzku ISVS (automatizáciou manažmentu kompletných prostredí).

Nasledujúce princípy odvodené od všeobecných moderných „best-practice" (https://12factor.net/), predstavujú požiadavky, ktoré musia byť pri návrhu, implementácii a prevádzke riešenia dodržané a zároveň tvoria kritéria kvality pre aplikačnú, technologickú a prevádzkovú časť riešenia. Jeden repozitár zdrojového kódu pre jednu „aplikáciu". Explicitná deklarácia a izolácia závislostí aplikácie. Konfigurácia (aplikácie) súčasťou prostredia, nie aplikácie. Nezávislosť aplikácie od konkrétneho poskytovateľa podpornej služby „back-endu“. Jasné oddeľovanie jednotlivých štádií transformácie zdrojového kódu na bežiacu aplikáciu. Spustená aplikácia beží ako jeden alebo viac bez-stavových procesov. Aplikácia je sama zodpovedná za publikáciu svojich komunikačných koncových bodov (portov). Jednoduché škálovanie výkonu pomocou spúšťania a zastavovania (paralelných) bez-stavových procesov. Okamžité reakcie procesov na požiadavky spustenia a zastavenia. Minimalizovať rozdiely medzi prostrediami (najmä vývojovým a produkčným). Aplikácia nikdy neriadi (a nespolieha sa na proprietárny) spôsob spracovania logov.

Podrobný popis návrhu aplikácie je predmetom výstupu R1- 01 Detailný návrh riešenia (DNR).

1. ODKAZY

1. PRÍLOHY

Koniec dokumentu

1 EUPL licencie: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf

2
 

3
 

Strana 58/58