I-03 Prístup k projektu (pristup_k_projektu)

PRÍSTUP K PROJEKTU

manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z.

Schvaľovanie dokumentu

1. História dokumentu

2. Účel dokumentu

V súlade s vyhláškou č. 401/2023 Z. z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky obsahuje opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

2.1 Použité skratky a pojmy

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

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 požiadaviek sú kategorizované podľa oblastí označených v samostatnom stĺpci „Oblasť požiadavky“ pre každú požiadavku v nasledujúcich kategóriách:

1. Procesné,
2. Legislatívne,
3. Dátové,
4. Požiadavky na službu,
5. Architektonické,
6. Bezpečnostné,
7. Integračné,
8. Požiadavky na UI/UX,
9. Implementačné požiadavky.

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, sú 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).

3 Popis navrhovaného riešenie

Ministerstvo zdravotníctva Slovenskej republiky (ďalej len „MZ SR“) plánuje vytvorenie integračnej platformy, ktorá budú slúžiť na efektívne centrálne zbieranie a transfer dát z organizácií v pôsobnosti MZ SR v rámci projektu Integračná platforma (ďalej len „IP“). MZ SR má v súčasnosti v pôsobnosti takmer 104 podriadených organizácií. V zmysle Plánu obnovy a odolnosti (ďalej len “POO”) je predmetom projektu Centrálnej integračnej platformy MZ SR (ďalej len “CIP”) zber dát od 19 poskytovateľov zdravotnej starostlivosti (ďalej len “PZS”) v zriaďovateľskej a zakladateľskej pôsobnosti MZ SR s právnou formou príspevkových organizácií a akciových spoločností (viď. tabuľka nižšie, kapitola 3.3), ktoré sú zapojené do centralizácie riadenia. V budúcnosti je možné rozšírenie uplatnenia výstupov tohto projektu na všetky podriadené organizácie MZ SR.

Ide o integračnú platformu, ktorej cieľovým stavom implementácie riešenia tzv. „Master data management“ je zjednotenie údajov zdieľaných viacerými informačnými systémami v organizácií do databázy kmeňových údajov, ktoré sú presné, kompletné, jednoznačné, aktuálne, konzistentné a správne. Zavedenie systematického manažmentu údajov ponúka možnosť konsolidácie všetkých kmeňových údajov v organizácii. Kumuluje funkčnosti modulov pre dátovú integráciu, dátovú kvalitu a tvorbu integrácií aplikácií pre komplexné prepojenie dátových zdrojov a prostredníctvom funkčností dátového manažmentu vytvorenie kmeňových údajov, ktorá v ekosystéme funguje ako jednotný bod pravdy. Riešenie ponúka možnosť implementovať všetky najpoužívanejšie štýly riadenia kmeňových údajov v organizácii. Projekt CIP vytvára technologický a dátový základ pre cieľový stav implementácie riešenia tzv. „Master data management“ s dôrazom na naplnenie cieľov Plánu obnovy a odolnosti pre centrálne riadenie vybraných 19 nemocníc, podľa Reformy 3 a Investície 3. CIP možné postupne prostredníctvom ďalších aktivít a plánovaných projektov rozvíjať.

Prostredníctvom konsolidácie kmeňových údajov je možné identifikovať nadbytočné systémy a úložiská, ako aj zabezpečiť jednotné, presné a hlavne zdieľané dáta tam, kde sú potrebné, čo vedie k značnému znižovaniu prevádzkových nákladov a zvyšovaniu úžitkovej hodnoty z dát. Tento systém za istých okolností môžu využívať podriadené organizácie (napr. Nemocnice) ako už spomínaný zdroj jednotný zdroj pravdy, keďže CIP bude zabezpečovať aj dátovú integráciu, a to konkrétne konzumovaním referenčných registrov prostredníctvom integrácie na Informačný systém centrálnej správy referenčných údajov (ďalej ako IS CPDI), ktorý je v zmysle zákona č. 305/2013. Z. z. o e-Governmente súčasťou Modulu procesnej integrácie a integrácie údajov, ktorý zabezpečuje prostredie pre elektronickú komunikáciu medzi informačnými systémami verejnej správy v správe rôznych orgánov verejnej moci pri výkone verejnej moci elektronicky a pre elektronickú komunikáciu medzi informačnými systémami verejnej správy a inými informačnými systémami. Správcom modulu je MIRRI. Nemocnice v súčasnosti pôsobia do veľkej miery ako samostatné zariadenia s rôznou úrovňou systémov riadenia, ekonomického vykazovania a plánovania.

Cieľom projektu CIP je implementácia systému IP ako súčasť nosných prostriedkov pre zjednotenie a optimalizáciu dát PZS, ktoré umožní MZ SR ich centrálne riadiť, usmerňovať a zefektívňovať ich výkon. MZ SR bude tieto dáta využívať v rámci kontrolingových činností, benchmarkingu, ale aj k získaniu nových súvislostí a informácií, o ktoré sa bude možné oprieť pri operatívnych a strategických rozhodnutiach.

Na základe porovnania alternatív popísaných v Projektovom zámere CIP, sa javí ako vhodná Biznis alternatíva č.2. Táto alternatíva je založená na vytvorení CIP po plánovanej migrácii ERP systémov 19 nemocníc do CES (MF SR). Pre realizáciu tejto alternatívy boli identifikované nasledovné predpoklady návrhu riešenia:

1. Zabezpečenie odborných kapacít pre dátový manažment a realizáciu projektu: Predpokladom realizácie navrhovaných zmien rámci MZ SR je zabezpečiť a posilniť príslušné odborné kapacity v oblasti riadenia dát a to najmä v oblastiach metodiky, nastavení pravidiel, dátovej kvality, ktoré by boli jednotné v rámci rezortu MZ SR. Organizačným predpokladom na strane MZ SR je vytvorenie dostatočných odborných kapacít pre metodickú správu údajov a dátovej kvality v rezorte zdravotníctva vrátane odborníkov pre oblasť dátovej vedy, data stewardov, dátových analytikov, dátových architektov a dátových právmikov a organizačné nastavenie pravidiel dátového manažmentu.
2. Realizácia externých projektov: úspešná migrácia nemocníc do CES a realizácia projektu IS OPE (NCZI) – realizácia integrácií.

Z technického pohľadu by mala pre úspešnú realizáciu riešenia CIP byť vykonaná migrácia ERP nemocníc do CES (v rámci projektu CES MF SR) v rozsahu:

• migrácia 19 PZS v zriaďovateľskej/zakladateľskej pôsobnosti MZ SR do  IS CES v rámci projektu CES (pre dáta, ktoré sú potrebné pre kontroling a benchmarking)
• integrácia LIS nemocníc do IS CES

Pozn.: Podmienku migrácie 19 PZS do CES realizácie je potrebné naplniť z dôvodu, potreby zdrojových dát pre CIP MZ SR z namigrovaných modulov ERP nemocníc. Aktivity analýzy a návrhu oboch častí (CES a CIP) však môžu prebiehať paralelne.

V rámci projektu CIP sú navrhované:

• moduly CIP, koncové služby dátovej analýzy pre podporu riadenia a súvisiace moduly aplikačnej vrstvy v zmysle navrhovanej architektúry v tomto dokumente.

• integračná vrstva pre údaje z CES, NIS a OPE pre poskytovanie služieb pre prístup a analýzu údajov nemocníc používateľmi MZ SR a nemocníc.

Nenaplnenie kľúčových predpokladov uvedených vyššie môže mať negatívny dopad na časové trvanie, predpokladané náklady a dosiahnite cieľov projektu.

4 Architektúra riešenia projektu

V tejto časti sú popísané všetky vrstvy architektúry navrhovaného riešenia (biznis, aplikačná, technologická) v rozsahu súčasný stav (ďalej AS IS) architektúry aj s príslušným architektonickým modelom a budúci stav (ďalej TO BE) architektúry riešenia aj s príslušným architektonickým modelom.

Architektúra vychádza z požiadaviek MZ SR, ktoré boli identifikované v prípravnej fáze projektu CIP MZ SR, ktorý je predmetom Katalógu požiadaviek a ďalších kapitol tohto dokumentu.

Biznis vrstva obsahuje popis aktérov, procesov a koncových služieb, ktoré budú interagovať so systémom CIP. Aplikačná vrstva popisuje informačné systémy a moduly IS CIP, ktoré softvérovo zabezpečia realizáciu požiadaviek biznis vrstvy. Technologická vrstva obsahuje návrh technologických komponentov, ktoré sú potrebné na prevádzku aplikácií a modulov aplikačnej vrstvy.

Návrh riešenia IS CIP je postavený na cielenom využití údajov z IS nemocníc ako aj plánovaných a prebiehajúcich projektov, ktorých vlastníkmi sú MFSR – projekt CES a NCZI – projekt OPE. Požiadavky na riešenie CIP majú dopad na rozšírenie týchto projektov.

V IS CIP sa neplánuje spracovávať osobné ani citlivé údaje, akými sú napr. klinické údaje o pacientoch, mená a priezviská, rodné čísla, dátumy narodenia, adresy trvalého bydliska, identifikované diagnózy a pod.. V prípade použitia individuálnych údajov sa využijú údaje upravené anonymizáciou resp. pseudonymizáciou na zdrojoch v IS OPE resp. CES a agregované údaje z ktorých nebude možné identifikovať konkrétnu osobu. Príkladom využitia údajov o fyzických osobách v CIP budú základné údaje o štatutároch nemocníc vo verejne dostupnom rozsahu (napr. webové sídla nemocníc a MZ SR, Obchodný register Slovenskej republiky a pod.).

4.1 Biznis vrstva

4.1.1 Súčasný stav

Potreby, na základe ktorých vznikol návrh budúceho riešenia, sú zamerané predovšetkým na zlepšenie riadenia a hospodárenia nemocníc v pôsobnosti MZ SR ako ich zriaďovateľa resp. zakladateľa, prostredníctvom zlepšenia správy dát, ich centralizácie, odstránením duplicít zberu a zabezpečením poskytnutia relevantných dát pre účely riadenia a rozhodovania. Potreby na budúce riešenie boli popísané v kapitolách Motivácia a Ciele projektu Projektového zámeru.

Na základe dotazníkového zberu dát, ktorý sa uskutočnil vo februári 2024 medzi organizačnými útvarmi MZ SR, boli identifikovaní nasledujúci koncoví používatelia Centrálnej integračnej platformy, ďalej aj „konzumenti dát“: 

• Útvar centrálneho riadenia (plánovaný), 
• Sekcia financovania, predovšetkým Odbor finančného kontrolingu podriadených organizácií a Odbor poisťovníctva, 
• Odbor strategických investícií, Sekcie správy majetku štátu, zakladateľských práv a strategických investícií, 
• Inštitút zdravotných analýz, 
• Odbor klasifikácie a cenotvorby ústavnej starostlivosti, Inštitútu zdravotných analýz, 
• Odbor krízového manažmentu, Sekcie krízového riadenia, 
• Oddelenie pre kategorizáciu a cenotvorbu liekov, Sekcie farmácie a liekovej politiky, 
• Odbor špecifikácií a cenových máp, Sekcie verejného obstarávania,
• Sekcia centrálneho riadenia a koordinácie podriadených organizácií .

Počet konzumentov údajov môže byť upravený (t.j. počet sa môže zvýšiť), prípadnou identifikáciou projektového tímu MZ SR a budúceho dodávateľa projektu počas etapy Analýza a dizajn v realizačnej fáze projektu

 Tabuľka 1: Popis informačných potrieb konzumentov dát 

Zber dát v súčasnosti prebieha väčšinou elektronickou formou prostredníctvom výmeny súborov vo formáte .xlsx, .pdf, resp. v iných formátoch. Súčasne na viacerých organizačných útvaroch MZ SR (napr. na odbore strategických investícií) prebieha zber dát zasielaním elektronických dokumentov, prostredníctvom emailov, prípadne cez registratúru, kedy zamestnanci MZ SR musia odčítavať hodnoty zo zaslaných dokumentov a následne ich prácne manuálne prepisovať do .xlsx súborov. 

Zber dát od poskytovateľov zdravotnej starostlivosti pre odbor finančného kontrolingu podriadených organizácií má byť od apríla 2024 dočasne zabezpečený prostredníctvom samostatného modulu v systéme EMA.EVO, po ukončení prevádzky systému MyGide. Zber týchto dát má byť v cieľovom stave pokrytý v rámci Centrálnej integračnej platformy MZ SR. 

Vyššie identifikovaní konzumenti dát sú predpokladanými skupinami používateľov CIP, ktorí momentálne využívajú údaje z nemocníc pre výkon svojich aktivít. Po uvedení do prevádzky bude možné rozšíriť CIP, resp. ho ďalej prispôsobovať aj pre ďalšie relevantné útvary MZ SR. Z tohto dôvodu nebudú predmetom návrhu Centrálnej integračnej platformy MZ SR používatelia z nasledujúcich organizačných útvarov MZ SR, ktoré v rámci dotazníkového zberu údajov potvrdili, že nezbierajú informácie od podriadených organizácií, resp. ich informačné potreby sú pokryté agendovými informačnými systémami a nepožadujú dátové služby v rámci Centrálnej integračnej platformy MZ SR. Týmito organizačnými útvarmi MZ SR sú:

• Kancelária ministra, 
• Oddelenie nadrezortnej koordinácie, 
• Odbor medzinárodných vzťahov a záležitostí EÚ, 
• Odbor realizácie projektu Rázsochy, 
• Komunikačný odbor, 
• Útvar kontroly, dozoru a sťažností, 
• Útvar vnútorného auditu, 
• Inšpektorát kúpeľov žriediel, 
• Sekcia implementácie plánu obnovy a odolnosti a reforiem, 
• Sekcia zdravia, 
• Odbor verejného zdravia, skríningu a prevencie, 
• Odbor zdravotníckeho vzdelávania, 
• Odbor farmácie, Sekcie farmácie a liekovej politiky, 
• Oddelenie pre zaobchádzanie s liekmi a zdravotníckymi pomôckami, Sekcie farmácie a liekovej politiky, 
• Oddelenie pre omamné látky a psychotropné látky, Sekcie farmácie a liekovej politiky, 
• Odbor liekovej legislatívy a MEA, Sekcie farmácie a liekovej politiky, 
• Odbor koordinácie protidrogovej stratégie a monitorovania drog, 
• Inštitút výskumu a vývoja, 
• Odbor inovatívnych prístupov v zdravotníctve, 
• Kancelária generálneho tajomníka služobného úradu, 
• Odbor informačnej a kybernetickej bezpečnosti, 
• Odbor projektového riadenia, 
• Osobný úrad, 
• Odbor zadávania zákaziek, Sekcie verejného obstarávania, 
• Odbor posudzovania zákaziek, Sekcie verejného obstarávania, 
• Sekcia digitalizácie a informatiky, 
• Odbor správy majetku štátu a zakladateľských práv, Sekcie správy majetku štátu, zakladateľských práv a strategických investícií, 
• Sekcia európskych programov a projektov, 
• Sekcia legislatívy, práva a akcionárskych práv. 

Informačné potreby konzumentov dát sú v súčasnosti pokryté najmä prostredníctvom nasledujúcich poskytovateľov dát: 

• Poskytovatelia ústavnej zdravotnej starostlivosti v zriaďovateľskej pôsobnosti MZ SR (viď. tabuľka nižšie), 
• Národné centrum zdravotníckych informácií (NCZI), 
• Štátny ústav pre kontrolu liečiv (ŠUKL), 
• Úrad pre dohľad nad zdravotnou starostlivosťou (ÚDZS),
• Zdravotné poisťovne, 
• Dáta z medzinárodných a európskych inštitúcií (napr. Svetová banka, OECD, Eurostat, ILOSTAT, databázy EMA, WHO, Unicef a iné). 

V nasledujúcej tabuľke je uvedený zoznam poskytovateľov zdravotnej starostlivosti v zriaďovateľskej a zakladateľskej pôsobnosti MZ SR, ktorí budú primárnymi poskytovateľmi dát pre CIP, ako aj koncovými používateľmi CIP: 

Tabuľka 2: Zoznam poskytovateľov zdravotnej starostlivosti v zriaďovateľskej pôsobnosti MZ SR 

Uvedení poskytovatelia zdravotnej starostlivosti v zriaďovateľskej pôsobnosti MZ SR v súčasnosti poskytujú dáta jednotlivým útvarom MZ SR priamo, resp. prostredníctvom NCZI, ako aj ostatným orgánom verejnej moci (napr. iným ministerstvám, zdravotným poisťovniam, daňovým a colným orgánom, miestnej samospráve a pod.). 

Detailný popis súčasných dátových zdrojov pre informačné potreby konzumentov dát je uvedený v kapitole 4.3. tohto dokumentu. 

V podmienkach rezortu MZ SR v súčasnosti nie je zmapovaná detailná analýza dátových potrieb na úrovni dátových atribútov v rezorte zdravotníctva, a to v dôslednom rozdelení na poskytovateľov a konzumentov dát. Uvedená analýza by mala byť zrealizovaná v úvode realizačnej fázy projektu Centrálnej integračnej platformy MZ SR a jedným z jej výsledkov by malo byť vytvorenie dátového modelu. Následné udržiavanie a aktualizácia dátového modelu rezortu MZ SR je dôležitým aspektom z hľadiska udržateľnosti projektu. NCZI spravuje údajovú základňu a zdravotnícky informačný systém v zmysle Zákona č. 153/2013 Z. z. o národnom zdravotníckom informačnom systéme a kontraktami uzatvorenými medzi MZ SR a NCZI[2]. V rámci MZ SR, ako zriaďovateľa však v súčasnosti neexistuje organizačný útvar, ktorý by metodicky riadil a koordinoval zber, spracovanie údajov od podriadených organizácií, definoval kontroly dátovej kvality, zabezpečoval dátovú governance t.j. neexistuje systematické riadenie údajov v rámci celého rezortu zdravotníctva. Zriadenie takéhoto útvaru je nevyhnutným predpokladom pre realizáciu projektu Centrálnej integračnej platformy MZ SR a jej následnú udržateľnosť, či rozvoj. Metodika a správa údajov CIP by mala byť zabezpečená špecializovanými pracovníkmi pre dátový manažment na strane MZ SR, ktorí momentálne nie sú zastúpení v organizačnej štruktúre MZ SR, napr. dátový architekt, dátový kurátor alebo dátový právnik. Uvedené role by mali byť zastúpené práve na Sekcii centrálneho riadenia a koordinácie podriadených organizácií ako podporný team pre komplexné riadenie nemocníc v zakladateľskej /zriaďovateľskej pôsobnosti MZ SR.

Navrhovaný stav

Biznis architektúra obsahuje nasledovné používateľské skupiny a aktérov, ktorí sú identifikovaní ako užívatelia navrhovaného systému:

Aktéri - používatelia CIP:

1. Konzumenti údajov - vybrané útvary MZ SR a nemocnice, ktorí zároveň poskytujú zdrojové údaje, Sekcia centrálneho riadenia a koordinácie podriadených organizácií ako Útvar centrálneho riadenia nemocníc v zakladateľskej/zriaďovateľskej pôsobnosti MZSR.
2. Správcovia - dátoví a IT špecialisti, ktorí budú zabezpečovať správu CIP napr. prevádzku, IT podporu a bezpečnosť systému. Na strane MZ SR dátoví špecialisti v rámci Sekcie centrálneho riadenia a koordinácie podriadených organizácií, Odbor informatiky.

Koncové služby:

1. Služby dátovej analýzy – služby zamerané na koncového používateľa, ktoré zabezpečujú ciele projektu pre podporu centrálneho riadenia nemocníc, a to monitorovaním a vyhodnocovaním údajov, ktoré sú pripravované automatizovane a zobrazované nástrojmi “Biznis intelligencie” v prehľadnej forme tzv. “dashboardov”, a to grafov, tabuliek a predefinovaných pohľadov.
2. Služby riadenia a správy dát – služby riadenia dát sú skupinou služieb pre nastavenie pravidiel spracovania dát, napr. zmena dátového formátu a dátovej štruktúry, dátového slovníka, dátovej kvality pre zabezpečenie konzistencie, zamedzenia duplicít. Primárnymi používateľmi sú dátoví špecialisti - dátoví analytici, kurátori, architekti a špecialisti kontrolingu.

Biznis procesy - predstavujú postupnosť aktivít, ktoré dosahujú požadovaný výsledok, ako napr. definovaný súbor výstupov alebo biznis služieb. V prípade navrhovanej architektúry sú to:

1. Procesy dátovej analýzy - procesy automatizovaného získavania - extrakcie, transformácie, analýza a vizualizácie dát.
2. Procesy riadenia dátovej kvality - procesy pre definované sekvencie pre identifikáciu - Základná analýza dátovej kvality, Validácia voči objektom evidencie (OE), Asistované čistenie, Automatické stotožnenie ako aj Proces dátovej kvality podľa špecifických potrieb organizácie.

4.2.1 Prehľad koncových služieb - budúci stav:

Nižšie v tabuľke sú uvedené budúce koncové služby, ktoré budú vybudované v projekte.

Obrázok 1: Model biznis architektúry CIP MZ SR(aktéri-koncoví používatelia, koncové služby, procesy)

Popis obrázku na nachádza v ďalšom texte. Základný popis jednotlivých koncových služieb (budúci stav) je nasledovný:

4.1.3 Jazyková podpora a lokalizácia

IS CIP bude lokalizovaný do slovenského jazyka.

4.2 Aplikačná vrstva

Aplikačná architektúra obsahuje prvky aplikačnej vrstvy, ktorá popisuje štruktúru, správanie a interakciu navrhovaných aplikácií. Aplikácie sú zoskupené na základe funkčných celkov biznis architektúry a poskytujú funkcionalitu pre prevádzku aplikačných služieb. Aplikačné služby budú realizované softvérom s cieľom poskytnutia koncových služieb pre používateľov CIP.

Navrhovaná aplikačná architektúra je rámcová a dodávateľsky neutrálna, a preto je možné na jednotlivé komponenty namapovať softvérové riešenia rôznych dodávateľov tak, aby naplnili definované požiadavky a ciele. Aplikačná architektúra pomôže sledovať pokrytie navrhovaných funkcií modulov a služieb pri výbere a návrhu konkrétneho riešenia implementácie a tým odsledovať kompletnosť návrhu a realizácie systému.

4.2.1 Rozsah informačných systémov – AS IS

Hlavné systémy poskytujúce zdrojové dáta pre CIP sú v súčasnosti ERP jednotlivých PÚZS, ktoré poskytujú údaje potrebné pre centrálne riadenie hospodárenia dotknutých nemocníc. V súčasnom stave sú údaje zbierané individuálne pomocou požiadaviek MZ SR a nie sú realizované integračné väzby a ani jednotná metodika správy týchto dát.

IS CES ^[3] je systém mimo infraštruktúry MZ SR resp. NCZI, ktorý je realizovaný ako projekt MF SR a v rámci IS VS sa plánuje pripojenie MZ SR ako aj podriadených nemocníc. Systém IS CES je vyvíjaný ako centrálny ekonomický systém vo verejnej správe Slovenskej republiky a obsahuje nasledovné moduly^[4]:

• Personalistika,
• Mzdy,
• Organizačný manažment,
• Časový manažment,
• Talent manažment,
• Správa služobných ciest,
• Manažment vozového parku,
• Materiálový manažment,
• Predaj služieb,
• ZFK - Riadenie interného workflow,
• Rozpočet,
• Správa nehnuteľností,
• Konsolidácia,
• Finančné účtovníctvo,
• Nákladové účtovníctvo,
• Riadenie projektov,
• Evidencia zmlúv a zverejňovanie do CEZ,
• Evidencia majetku,
• Zmluvné účty,
• Reporting,
• Centrálne kmeňové dáta a číselníky,
• Údržba a opravy.

V súčasnom stave zatiaľ nie je realizovaná migrácia ani prepojenie MZ SR a nemocníc na CES. Podľa harmonogramu MF SR je plánované nasadenie systému pre MZSR a nemocnice do prevádzky v termíne 1Q 2026. V pláne obnovy a odolnosti SR je cieľ nasadenia integračnej platformy uvedený na Q4 2025.

Pozn.: Nemocnice typu akciová spoločnosť neevidujú svoje údaje v MetaIS.

Navrhovaný stav     

Navrhovaná aplikačná architektúra CIP sa skladá z nového informačného systému – Centrálna integračná platforma MZ SR, s nasledovnými modulmi, ktoré budú vyvinuté ako modulárny softvérový systém:

• Používateľské rozhranie – prístup používateľa do IS CIP MZ SR a využitie jeho funkcie,
• Modul kvality a čistenia údajov– funkcie riadenia dát, dátový slovník správa štandardov, nástroje dátovej kvality, formuláre a validácia
• Modul Biznis intelligence / analytika – spracovanie a vizualizácia výstupov dátovej analýzy a reportov, úložisko spracovávaných dát.
• Modul prístupy a administrácia – konfigurácia, monitorovanie, auditovanie, nastavenie prístupov,

• Integračný komponent – rozhrania pre získavanie údajov zo zdrojových externých systémov - nemocnice, registre a pod.
• Modul Rozhrania nemocníc – modul je určený pre vytvorenie rozhraní na strane nemocníc za účelom integrácie dát z IS príslušnej nemocnice pre CIP MZSR.

Na obrázku náhľadu aplikačnej architektúry sú zobrazené komponenty aplikácií, aplikačných služieb a funkcií v notácii Archimate. Oranžovou je zvýraznená integrácia na IS OPE, ktorá bude závisieť od harmonogramu realizácie projektu IS OPE (NZCI). Prostredníctvom tejto integrácie bude možne integrovať údaje z ďalších dátových zdrojov v rezorte zdravotníctva (ISZI, JÚRZ, ÚZDS). Intergácia na IS CPDI (Informačný systém Centrálna platforma dátovej integrácie v správe MIRRI SR) sa bude realizovať priamo na CIP

Obrázok 1: : Model aplikačnej architektúry CIP MZ SR

Popis modulov a rozhraní CIP MZ SR:

4.2.2 Rozsah informačných systémov - TO BE

Z dôvodu plánovanej migrácie ERP systémov nemocníc do CES je v nasledujúcej tabuľke uvedená aj klasifikácia systému z pohľadu plánovanej integrácie označené ako skupiny: ERP – ekonomické systémy, NIS – nemocničné informačné systémy, Lekárenský IS – systémy pre správu nemocničných lekární a OPE – systémy súvisiace s projektom Online procesy eZdravia. Rozsah informačných systémov – TO BE vychádza z rozsahu existujúcich informačných systémov – AS IS, uvedených v tabuľke vyššie s doplnením CIP MZ SR.

V nasledujúcej tabuľke nižšie sú kvôli podrobnejšiemu prehľadu doplnené stĺpce „Vlastník“ a „Skupina integrácie“.

Skupina integrácie systému indikuje spôsob integrácie v budúcom stave:

• ERP (nemocníc) – tieto IS budú migrované projektom CES a následne integrované rozhraním do CIP MZSR.
• NIS a Lekárenské IS (nemocníc) – tieto IS budú rozvinuté o integrácie a integrované do CIP MZSR.
• OPE – bude rozvinutý o integráciu a integrovaný s CIP MZSR.

4.2.3 Využívanie nadrezortných a spoločných ISVS - AS IS

Momentálne nie sú využívané nadrezortné spoločné ISVS pre účely centrálnej integrácie dát v rámci MZ SR.

4.2.4. Prehľad plánovaných integrácií ISVS na nadrezortné ISVS - spoločné moduly podľa zákona č. 305/2013 e-Governmente - TO BE 

V návrhu CIP sa predpokladá poskytovanie údajov z ISVS, keďže v rámci rezortu zdravotníctva sa predpokladá jednotné získavanie dát z IS CPDI

4.2.5 Prehľad plánovaného využívania iných ISVS (integrácie) - TO BE

Prehľad predpokladaných integrácií medzi CIP MZ SR a ekonomickými, mzdovými, účtovnými a personálnymi systémami nemocníc. Tieto systémy sú zväčša dodávané ako samostatné softvérové diela, rôznymi dodávateľmi. Po technickej, organizačnej stránke je preto potrebné navrhnúť integráciu pre každú nemocnicu samostatne.

Na základe dostupných údajov sa požaduje poskytnutie zdrojových údajov pre CIP z 2 až 3 informačných systémov každej nemocnice, ktorých prehľad je uvedený v tabuľke nižšie. Zoznam je indikatívny, keďže niektoré nemocnice plánujú výmenu systému, resp. používajú ďalšie doplnkové softvérové aplikácie, napr. na reporting alebo prenos údajov.

V nasledujúcej tabuľke je uvedený prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS alebo služieb inf. systémov tretích strán v TO BE stave.

Tabuľka 12: Prehľad predpokladaných integrácií, pri ktorých sa plánuje využívanie služieb iných ISVS alebo služieb inf. systémov tretích strán v TO BE stave.

4.2.6 Aplikačné služby pre realizáciu koncových služieb - TO BE

V tabuľke nižšie sa nachádza zoznam navrhovaných koncových a aplikačných služieb CIP, ich vzájomná previazanosť a poskytujúci modul ISVS, tomto prípade navrhovaný modul CIP.

Pozn.: Ak je v zozname aplikačná služba uvedená viacnásobne, podieľa sa na realizácií ďalších koncových služieb.

4.2.7 Aplikačné služby pre realizáciu koncových služieb - TO BE

V nasledujúcej tabuľke sú uvedené budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS 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//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.3.1 a kap. 2.1.3.3.2. Detailný popis služieb IS CPDI a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CPDI.
• 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 Gatewy).
• 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, kap. 2.1.3.

Poznámka k IS OPE: V čase písania tohto dokumentu je projekt IS OPE v začiatočnom štádiu realizácie, integrácia s CIP MZ SR bude možná až po realizácii IS OPE. Rozsah projektu IS OPE pôvodne nepredpokladal vytvorenie integračného rozhrania s CIP MZ SR a bude potrebné ho doplniť.

4.2.8 Poskytovanie údajov z ISVS do IS CPDI - TO BE

V návrhu CIP sa nepredpokladá poskytovanie údajov z ISVS na  IS CPDI.

4.2.9 Konzumovanie údajov - TO BE

V návrhu CIP MZSR sa predpokladá priame konzumovanie údajov z IS CPDI, ktoré bude zabezpečovať externé integrácie na referenčné registre a IS iných OVM. Rozsah integrácii z IS CPDI je uvedený v tabuľke nižšie.

4.3 Dátová vrstva

V súčasnosti na MZ SR neexistuje štandardizovaný proces riadenia dát. Jednotlivé organizačné útvary získavajú dáta z rôznych dátových zdrojov. Dáta sú získavané na pravidelnej báze, ktorá je vopred definovaná (mesačne, ročne,...), alebo podľa aktuálnej potreby, resp. na vyžiadanie. Medzi dátovými zdrojmi neexistuje žiadne prepojenie a tieto dáta sú ukladané na lokálnom disku používateľov, ktorí s dátami pracujú, prípadne na zdieľanom úložisku. Okrem dátových zdrojov typu databáza alebo informačný systém, existuje veľa dátových zdrojov, ktoré majú formu dokumentov ako napr. xlsx, csv, pdf,...).

Nad týmito dátovými zdrojmi neexistuje žiaden kontrolný mechanizmus. V súvislosti s veľkým množstvom neriadených, nekonsolidovaných dátových zdrojov v kombinácii s chýbajúcim dátovým manažmentom vzniká problém v dátovej kvalite, prehľadnosti, vznikajú duplicity a nekonzistentné dáta. S týmito problémami následne rastú náklady na údržbu dát, ale aj riziká týkajúce sa kyberbezpečnosti, či ochrany osobných údajov.

Keďže v súčasnosti neexistuje systém určený na integráciu a konsolidáciu potrebných zdrojov dát, väčšina dátových zdrojov je pripravovaná manuálnym spôsobom, čo zvyšuje pravdepodobnosť výskytu chyby. Napríklad 19 nemocníc dodá 19 separátnych dátových vstupov, ktoré sú vytvárané 19 rôznymi spôsobmi. Niektoré dátové zdroje majú štandardizovanú štruktúru (šablónu), ktorú dodávateľ dát musí pri zasielaní dát dodržať, iné túto štruktúru definovanú nemajú. Aj keď je táto štruktúra zadefinovaná a dodané dáta spĺňajú náležitosti šablóny, môžu sa vyskytovať chyby po obsahovej alebo technickej stránke. Tieto chyby musia byť momentálne identifikované manuálnym spôsobom používateľom. V rámci šablón neexistujú žiadne automatické kontrolné procesy. Výnimkou sú dátové zdroje, výkazy, získavané z NCZI, kde sú dáta zbierané a spracovávané do stanovenej štruktúry. Vzhľadom na to, že dáta prichádzajú z rôznych zdrojov, rôznym spôsobom a v jednotnej štruktúre alebo v rôznych štruktúrach, je potrebná konsolidačná vrstva, ktorá zabezpečí automatickú konsolidáciu týchto dát so zohľadnením kvality dát. Momentálne je táto aktivita vykonávaná manuálnym spôsobom, čo výrazným spôsobom ovplyvňuje úroveň kvality dát, neprimerane zvyšuje požiadavky na personálne kapacity, ale aj ďalšie finančné náklady pri spracúvaní takých to dát.

4.3.1 Údaje v správe organizácie

Nasledujúca tabuľka obsahuje zhrnutie poznatkov analýzy aktuálne využívaných dát oddeleniami MZ SR. Zdrojom týchto poznatkov je dotazník, ktorý bol vytvorený za účelom zberu informácií o aktuálne zbieraných a využívaných dátach v spojení s osobnými stretnutiami so zástupcami jednotlivých oddelení.

Na obrázku sú znázornené zdroje dát, podľa jednotlivých oddelení. Každý zdroj predstavuje jeden alebo viac dátových extraktov, ktoré sú pripravované rôznymi spôsobmi. Následne sú distribuované ku ich konzumentom rôznym spôsobom na pravidelnej, alebo nepravidelnej báze.

Obrázok 3 Aktuálne zdroje dát

Aktuálne zdroje dát:

• Manuálne pripravované dátové vstupy od PÚZS (z IS nemocníc)
• NCZI (pripravené extrakty, výkazy E, F,..)
• ÚDZS extrakty
• ŠÚKL extrakty
• NIHO extrakty
• Dáta od poisťovní
• EMA.EVO extrakty
• IS EPIS
• Dáta z webu (CRZ, ..)
• MF SR dáta
• Dali databáza
• eTool
• Josephine

Spôsob získavania dát

Dáta sú dodávané väčšinou elektronicky vo forme excel, csv, alebo v neštruktúrovanom formáte PDF pomocou emailu, alebo zdieľaného dátového úložiska. Niektoré dáta sú však dodávané fyzicky na USB kľúči, CD alebo listinne.

• Email (vo forme emailovej prílohy)
• Zdieľané úložisko
  • MS Teams
  • mzsr.sharefile.eu
  • úložisko IFP MF SR
• Exportom
• Fyzicky (CD, USB, listina,...)

Periodicita dodávania

• Vopred dohodnutá periodicita (ročne, mesačne, kvartálne, ...)
• Na vyžiadanie

Ak po dodaní dát sú na dáta aplikované dátové kontroly a je identifikovaný problém, proces vyžiadania, prípravy a dodania dát sa zopakuje.

Následne sú tieto dokumenty spracovávané používateľmi na základe ich skúseností. Proces spracovania dát nie je zadefinovaný a štandardizovaný. Chýba automatizované spracovanie dát, vo väčšine prípadov je proces spracovania dát založený na opakovanom manuálnom spracovaní, kde sa vykonáva napríklad konsolidácia 19 excelov v rôznej štruktúre do jednej finálnej a pod.

Všetky tieto dáta sú následne fyzicky ukladané v lokálnych počítačoch, zdieľaných úložiskách a pod. Neexistuje systém sledovania zmien dát a ukladania histórie dát. Momentálne neexistuje systém , kde by boli všetky dáta konsolidované a spracované a ukladané na jednom mieste a ani súvisiaci jednotný dátový model.

Dátový rozsah projektu - Prehľad objektov evidencie sa bude pravdepodobne meniť/rozširovať na základe výsledkov fázy Analýza a dizajn projektu.

Nasledujúci diagram znázorňuje konceptuálny pohľad na dátové domény a relácie medzi nimi. Taktiež obsahuje informáciu, ktoré oddelenie tieto dáta primárne využíva. Táto informácia je dostupná ako popis celku, ktorý zoskupuje viaceré dátové domény. Na základe tohto konceptu bude dodávateľ počas implementačnej fázy projektu navrhovať a vytvárať logický dátový model, ktorý bude slúžiť ako podklad pre tvorbu fyzického dátového modelu.

Obrázok 2: Pohľad na relevantné dátové domény budúceho stavu - zjednodušený

Obrázok 3: Pohľad na relevantné dátové domény budúceho stavu

Diagram obsahuje dátové domény, ktoré boli identifikované na základe rozdelenia šablón ako celku na menšie časti a na základe business potrieb.

Podstatou je fakt, že znázornená doména je objekt, ktorý konsoliduje dáta z viacerých zdrojov a období. Napríklad doména Hlavná kniha zastrešuje dáta od všetkých dodávateľov dát a z viacerých období (napríklad mesačné) na jednom mieste v rovnakej štruktúre, na rozdiel od niekoľkých desiatok vstupov vo forme Excelu a v rôznych štruktúrach.

Jedným z cieľov bolo identifikovať dátové domény, ktoré sú spoločné pre viaceré oddelenia a teda zistiť a určiť, ktoré oblasti dát by boli využiteľné viacerými oddeleniami súčasne. Analýzou sa identifikovali dátové domény spoločné pre všetky oddelenia a to Subjekt (napríklad konkrétna nemocnica), ktorý bude každej dátovej oblasti určovať pôvodného vlastníka dát, a Kalendárová (dátumová) dimenzia, ktorá bude každej oblasti určovať časový rámec.

Ďalej sa ako spoločná javí doména s názvom Lieky, ktorá je využívaná Oddelením pre kategorizáciu a cenotvorbu liekov a odborom špecifikácií a cenových máp.

Pre odbor strategických investícií boli identifikované dátové domény potrebné pre investičný plán a to Investície, Investície Detail, Predkladateľ a Typ Investície.

Pre odbor špecifikácií a cenových máp boli v súvislosti s príjmami liekov a zdravotného materiálu identifikované objekty evidencie pre Nákup, Nákup Detail, Tovar, ŠZM Typ a s tým súvisiaca Objednávka, Lekáreň a Typ Lekárne. Taktiež Lieky, Výrobca, ŠÚKL a ATC informácie.

Pre Oddelenie pre kategorizáciu a cenotvorbu liekov - sekcia farmácie sú hlavnými doménami Lieky, ich Výrobca a Štát výrobcu, Prevody držiteľov, Zoznam žiadateľov/držiteľov a zoznam ich Činností. Taktiež Výdaj lieku s informáciou o Poisťovni, Diagnóze, PÚZS, Type výdaja, Zdravotnom pracovníkovi, Pacientovi, Kategórii Pacienta, Podkategórii pacienta a Lieky uhradené z verejného ZP.

Odbor finančného kontrolingu bude konzumentov najväčšieho rozsahu dát. Medzi najhlavnejšie domény patrí Účtovníctvo/Hlavná kniha a zoznam Účtov, Skupín Účtov a zoznam Nákladových stredísk, Pohľadávky a záväzky s informáciou o Faktúre, Dodávateľoch a Odberateľoch. Taktiež Finančný Plán a Plán činností organizácie, Výnosy, Náklady, Tržby, Výkony a DRG dáta. Ďalšie podstatné sú Benchmarking a medicínske dáta, ktoré pokrývajú domény Personálne dáta, Prevádzkové dáta, Ambulancie, UZS DRG, UZS nonDRG, Stacionár, OMS, JZS, SVaLZ. V diagrame v časti medicínskych dát sú znázornené aj dáta, ktoré momentálne nie sú zbierané, ale sú do budúcna požadované. Tieto dáta sú priradené do skupiny “Požadované (nezbierané)”.

Ďalšie datasety nevyhnutné pre komplexný výkon činnosti Sekcie centrálneho riadenia a koordinácie podriadených organizácií v súlade s Míľnikom/cieľom C11-4 = Zriadenie ústredného riadiaceho orgánu nemocnice z organizačného, prevádzkového a ekonomického hľadiska v rámci opatrenia: Reforma 3 Centralizácia riadenia najväčších nemocníc POO budú identifikované v rámci fázy Analýzy a dizajnu projektu CIP dodávateľom tohto projektu.

Tabuľka č. 11 uvedená nižšie obsahuje identifikované Hlavné dátové objekty evidencie z obrázku 4. s priradenými aktuálnymi a budúcimi zdrojmi dát.

Tabuľka 11: Predpokladané hlavné dátové objekty evidencie – aktuálne a budúce zdroje dát

Pre referenčné údaje, základné číselníky a ďalšie údaje v súlade s princípom 1x a dosť mimo rezortu bude zdrojovým informačným systémom IS CPDI.

4.3.2 Referenčné údaje

Táto kapitola nie je relevantná pre projekt.

4.4 Kvalita a čistenie údajov

Aktuálny stav:

Aktuálne vyhodnocovanie dátovej kvality jednotlivých dátových vstupov je individuálne a môžeme ho rozdeliť do troch skupín:

1. Nevykonáva sa žiadna kontrola dátovej kvality,
2. Kontrola kvality dát prebieha na úrovni kombinácie úsudku a skúseností konkrétneho pracovníka,
3. Aplikujú sa konkrétne, vopred definované logické kontroly.

Analýzou sa zistilo, že väčšina dátových vstupov nemá definované dátové kontroly. Väčšina vykonávaných dátových kontrol je založená na osobnom úsudku a skúsenosti používateľa. Takéto kontroly sa nedajú logicky zadefinovať a teda sa nedajú zautomatizovať. Pri identifikácií chyby pracovníci kontaktujú poskytovateľa dát s informáciou o chybe a s požiadavkou o jej nápravu/vysvetlenie. Tento proces sa opakuje do momentu keď sú dáta správne. To znamená, že opakovaná výmena dokumentov/dát môže prebehnúť aj v niekoľkých iteráciách. Takýto prístup kontroly dát môže spôsobiť to, že pri opakovanom zbere dát v čase, nebudú na tie isté dáta aplikované všetky kontroly, resp. budú aplikované aj kontroly iné.

Existujú však kontroly, ktoré sa dajú logicky zadefinovať, sú opakovateľné a tieto kontroly sú vhodným adeptom pre automatizáciu kontrol. Zoznam takýchto kontrol bude definovaný v implementačnej fáze projektu na základe analýzy.

Budúci stav:

Na zabezpečenie a udržanie požadovanej kvality dát bude súčasťou architektúry Centrálnej Integračnej Platformy modul Dátovej kvality. Tento modul bude obsahovať kontroly, ktoré budú výsledkom detailnej analýzy existujúcich a požadovaných dátových kontrol. Modul bude zodpovedný za automatické vykonávanie zadefinovaných kontrol a za vyhodnocovanie kvality dát vo forme reportu pre koncového používateľa alebo systém.

Všetky kontroly budú zdokumentované a každá kontrola bude mať svojho vlastníka. V prípade, že kontrolou sa identifikuje problém, dostane vlastník informáciu o probléme, ktorý bude riešiť.

Vykonávanie kontrol:

• Po extrakcii dát zo zdrojových systémov
  • Kontroly budú aplikované ihneď po extrakcii dát a existujúce chyby budú identifikované a odchytené na začiatku procesu
• Po transformácii dát
  • Kontroly budú aplikované na dáta, ktoré boli zmenené transformačným procesom (ak budú definované)
• Počas importu dát z dokumentov
  • Počas importu dát z dokumentov dostane používateľ informáciu o chybných dátach a požiadavku na úpravu a opakovaný import správnych dát.
• Súčasť formulára
  • V prípade importu dát pomocou formulára bude tento formulár obsahovať kontroly nad jednotlivými hodnotami a používateľ bude na chybu upozornený v reálnom čase.

Dátové kontroly budú rozdelené do kategórií:

• Informačné
  • Poskytnú informáciu o neočakávanej resp. podozrivej hodnote. Tieto kontroly neovplyvnia ďalšie spracovanie dát, alebo procesy
• Kritické kontroly (KO)
  • Kontroly, ktoré pri identifikácií chyby informujú používateľa a zároveň zastavia ďalšie spracovanie dát, resp. nasledujúce procesy.

V tabuľke sú uvedené OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

Data Governance:

Základom CIP platformy a jej dátovej architektúry je definovanie jednotného dátového modelu – dátový model, ktorý bude konsolidovať dáta z rôznych zdrojov a ukladať tieto dáta v dátových štruktúrach.

Na základe definovaných oblastí dát vo finálnom dátovom modeli bude týmto oblastiam pridelený vlastník dát, ktorý bude zodpovedný za danú oblasť dát a za kontroly, ktoré budú nad týmito dátami vykonávané, t.j. bude dostávať notifikácie s informáciou o dátovej kvalite a v prípade potreby úpravy dát bude túto úpravu riešiť.

Potrebné vytvoriť dokumentáciu minimálne v rozsahu:

• Dátový slovník
  •  Dokument bude obsahovať zoznam a popis dimenzií a faktov, s popisom, priradeným vlastníkom, zadefinovanou logikou výpočtu / vyhodnocovania, lokáciu dát v dátovom sklade
• Business slovník
  •  Dokument bude obsahovať unikátny zoznam používaných pojmov a výrazov s ich definíciou a prepojením na dátový slovník
• Zoznam dátových kontrol
  •  Zoznam, ktorý bude obsahovať dátové kontroly, ich popis a logiku, previazanie na konkrétne objekty, vlastníka
• Maticu prístupových práv
  •  Matica bude obsahovať zoznam používateľov, ich rolu, typ používateľa a priradené oprávnenia

Rozsah predmetnej dokumentácie v predkladanom projekte bude kopírovať rozsah dát nevyhnutný pre centrálne riadenie nemocníc v zakladateľskej/zriaďovateľskej pôsobnosti MZSR.

Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality

V nasledujúcej tabuľke sú definované potrebné odborné kapacity pre zabezpečenie riadenia dát a dátovej kvality.

https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/datova-kvalita/

4.4.1 Otvorené údaje

V predkladanom projekte sa neplánuje publikovanie otvorených údajov.

4.4.2 Analytické údaje

IS CIP bude môcť poskytnúť vybrané ukazovatele o hospodárení štátnych nemocníc ako analytický údaj.

4.4.3 Moje údaje

Táto kapitola nie je relevantná pre projekt.

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

V nasledujúcej tabuľke je uvedený súhrn pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.

OE uvedené v dátovej vrstve nebudú v rámci predkladaného projektu sprístupňované ako moje, referenčné, otvorené, ani analytické údaje, avšak nie je vylúčené ich sekundárne využitie v rámci nadväzujúcich aktivít a plánovaných projektov MZ SR.

4.5 Technologická vrstva

Ministerstvo zdravotníctva SR (MZ SR) sa na základe analýzy dostupných alternatív technologickej architektúry rozhodlo nevyužívať cloudové prostredie poskytované Národným centrom zdravotníckych informácií (NCZI) ani Ministerstvom vnútra SR (MV SR) a uprednostniť vybudovanie vlastnej technologickej infraštruktúry. Toto rozhodnutie je podložené nasledujúcimi dôvodmi:

• Ministerstvo zdravotníctva považuje za kľúčové mať plnú kontrolu nad správou infraštruktúry a bezpečnostnými opatreniami, čo je možné len pri vlastnom (on-premise) riešení.
• Ochrana údajov (údaje o pacientoch, diagnózach a zrdravotných výkonoch) je pre MZ SR prioritou. Súčasné cloudové riešenia vo verejnej časti Vládneho cloudu nemajú certifikáciu pre spracovanie všetkých typov zdravotníckych informácií.
• Hoci NCZI je primárnym správcom zdravotníckej infraštruktúry (eZdravie, ISZI, JRUZ) a v prípade dostatočných kapacít by bolo preferovaným riešením, v súčasnosti nie sú splnené podmienky na rozšírenie dátového centra.
• MZ SR preferuje vybudovanie špecializovaného „zdravotníckeho cloudu”, ktorý bude plne pod kontrolou rezortu zdravotníctva a bude reflektovať špecifické požiadavky na ochranu zdravotníckych údajov.
• Zdieľaná infraštruktúra s MV SR alebo MF SR (napr. v rámci CES – Centrálna ekonomická správa) by znamenala závislosť na správcovi cudzej infraštruktúry, čím by sa znížila flexibilita a rýchlosť reakcie na zmeny v oblasti zdravotníckych informačných systémov.
• Integrácia do vládneho cloudu v správe MV SR alebo MF SR by vyžadovala komplexné úpravy bezpečnostných štandardov, čo by predĺžilo implementáciu projektu.
• MZ SR má záujem o budovanie vlastnej infraštruktúry ako strategického aktíva, ktoré umožní:
• Lepšiu kontrolu nad nákladmi v dlhodobom horizonte.
• Flexibilné rozširovanie kapacít podľa potrieb zdravotníckeho sektora.
• Prispôsobenie bezpečnostných opatrení špecifikám zdravotníckych údajov.

Ministerstvo zdravotníctva SR sa rozhodlo pre vlastné on-premise riešenie, pretože:
 - Zaručuje plnú kontrolu nad bezpečnosťou a citlivými údajmi.
 - Odstraňuje závislosť od externých poskytovateľov cloudových služieb.
 - Podporuje dlhodobú strategickú víziu digitalizácie zdravotníctva.
 - Rieši problém nedostatočných certifikácií verejného cloudu pre zdravotnícke údaje.

Ministerstvo zdravotníctva zároveň nevylučuje budúcu integráciu zdravotníckeho cloudu pod gesciou NCZI, avšak až po zabezpečení dostatočných kapacít a certifikovaných služieb pre spracovanie citlivých údajov.

4. 5. 1 Stratégia budovania robustného IT systému pre Ministerstvo zdravotníctva SR

Vzhľadom na narastajúce požiadavky na bezpečnosť, výkon a samostatnú správu IT infraštruktúry MZ SR je nevyhnutné vypracovať dvojfázový plán na vybudovanie moderného, spoľahlivého a výkonného IT riešenia. Tento plán sa skladá z dvoch hlavných etáp:

Prvá etapa: Vybudovanie onsite riešenia v správe MZ SR v rámci projektu CIP MZ (Centrálna integračná platforma MZ SR)

V prvej etape je prioritou vytvorenie robustného IT systému, ktorý bude plne v kompetencii a správe MZ SR, bez nutnosti využívania cloudových služieb poskytovaných externými organizáciami, ako sú Ministerstvo vnútra SR (MV SR) alebo Národné centrum zdravotníckych informácií (NCZI).

Tento prístup zahŕňa:

• Budovanie nezávislosti: Kompletné onsite riešenie eliminuje závislosť od externých cloudových služieb, čím sa zvyšuje kontrola nad dátami, zabezpečením a správou infraštruktúry.
• Zameranie na bezpečnosť: Onsite riešenie umožňuje implementovať pokročilé bezpečnostné opatrenia a ochranu údajov, ktoré sú nevyhnutné pre citlivé zdravotnícke dáta.
• Efektívna správa: Riešenie bude optimalizované pre potreby MZ SR, pričom sa zníži riziko výpadkov spôsobených koordináciou medzi viacerými externými subjektmi.
• Flexibilita: Onsite riešenie poskytuje lepšie možnosti škálovania výkonu a kapacity podľa potrieb ministerstva.

Cieľom tejto etapy je vytvoriť základnú infraštruktúru, ktorá zabezpečí stabilnú a bezpečnú prevádzku systémov ministerstva.

Druhá etapa: Rozšírenie infraštruktúry prostredníctvom dopytového projektu

Druhá etapa sa plánuje realizovať v rámci dopytového projektu zameraného na zlepšenie využívania údajov Ministerstva zdravotníctva SR. Tento projekt bude riešiť rozšírenie IT infraštruktúry o dodatočný výkon a kapacity, aby sa zabezpečila pripravenosť na rastúce nároky na spracovanie dát a poskytovanie nových digitálnych služieb.

Kľúčové kroky druhej etapy zahŕňajú:

• Rozšírenie hardvérových kapacít (výpočtová kapacita, úložisko):
  • Navýšenie výpočtového výkonu prostredníctvom dodatočných serverov, ktoré budú optimalizované na spracovanie veľkých objemov údajov.
  • Zavedenie nových úložísk s dostatočnou kapacitou a rýchlosťou pre ukladanie zdravotníckych dát.
  • Implementácia redundancie a zálohovacích mechanizmov na zvýšenie dostupnosti a spoľahlivosti údajov.
• Rozšírenie softvérových riešení:
  • Nasadenie pokročilých nástrojov pre analýzu a spracovanie údajov, ktoré umožnia efektívnejšie využívanie dostupných dát.
  • Implementácia softvérových riešení pre riadenie a monitorovanie infraštruktúry v reálnom čase.
  • Zavedenie technológií na podporu interoperability dátových systémov MZ SR a ďalších zdravotníckych inštitúcií.
• Optimalizácia procesov:
  • Automatizácia rutinných úloh a procesov, čím sa zníži záťaž na administratívny personál IT oddelení.
  • Integrácia dodatočných analytických nástrojov, ktoré podporia strategické rozhodovanie ministerstva na základe presných a aktuálnych dát.

Očakávané prínosy navrhovaného riešenia

1. Nezávislosť a kontrola: MZ SR bude plne kontrolovať všetky aspekty IT infraštruktúry, čím sa minimalizuje riziko závislosti od tretích strán.
2. Zvýšenie bezpečnosti: Onsite riešenie poskytne maximálnu úroveň ochrany (v prípade potreby aj citlivých)  údajov.
3. Zvýšený výkon a kapacita: Rozšírenie infraštruktúry zabezpečí pripravenosť na spracovanie veľkého množstva údajov a podporí ďalší rozvoj digitálnych služieb.
4. Efektívne využívanie údajov: Nasadenie moderných nástrojov na analýzu a správu dát podporí lepšie rozhodovanie a optimalizáciu procesov.
5. Škálovateľnosť a budúca pripravenosť: Riešenie bude navrhnuté tak, aby umožnilo jednoduché rozšírenie kapacít a funkcií podľa budúcich potrieb.

Tento dvojfázový plán vytvára silné základy pre modernizáciu IT infraštruktúry MZ SR a zabezpečuje, že ministerstvo bude schopné efektívne reagovať na budúce technologické výzvy a potreby v oblasti zdravotníctva.

4. 5. 2 Prehľad technologického stavu - AS IS

Predkladaný projekt je kľúčovou súčasťou modernizácie informačných technológií MZ SR, ktorá sa zameriava na rozvoj a konsolidáciu IT infraštruktúry. Tento projekt nadväzuje na sériu predchádzajúcich aktivít, ktoré MZ SR realizovalo v oblasti digitalizácie a modernizácie interných systémov, s cieľom zvýšiť efektivitu a bezpečnosť prevádzkových aplikácií a služieb.

Na základe analýzy cieľovej infraštruktúry MZ SR a zohľadnenia doterajších skúseností z prevádzky v iných projektoch MZ SR, boli identifikované nasledovné kľúčové poznatky:

• Význam kontajnerizácie pre budúce aplikácie: Kontajnerizácia ponúka výrazné výhody, vrátane flexibilného nasadzovania, škálovania a zvýšenej efektivity prevádzky. Umožňuje rýchlejší vývoj a nasadzovanie nových aplikácií (mobilných aj webových) a ich bezpečný prechod z vývoja do produkcie.
• Hybridná prevádzka ako prechodný model: Vzhľadom na komplexnosť dát a súčasných systémov je dôležité zachovať hybridnú prevádzku, ktorá umožní plynulý prechod medzi tradičnými virtualizovanými systémami a modernými kontajnerovými riešeniami.
• Automatizácia a DevSecOps: Automatizácia nasadzovania aplikácií prostredníctvom DevSecOps znižuje operačné náklady a skracuje čas potrebný na nasadenie zmien. DevSecOps prístup zároveň podporuje konzistenciu, opakovateľnosť a bezpečnosť procesov, čo vedie k zlepšeniu kvality softvérového vývoja a k zvýšeniu bezpečnosti softvérových riešení.
• Zelené dátové centrá a energetická účinnosť: Pokračovanie v optimalizácii dátových centier prostredníctvom energeticky efektívnych riešení (hyperkonvergovaná infraštruktúra, kontajnerizácia, SSD) prispieva k zníženiu uhlíkovej stopy a prevádzkových nákladov.

Tieto kľúčové princípy budú implementované do modernizovania infraštruktúry MZ SR. Predkladaný projekt vybuduje modernú IT infraštruktúru MZ SR, ktorá podporí bezpečnú, flexibilnú a energeticky efektívnu prevádzku aplikácií.

Cieľom tejto stratégie je zabezpečiť, aby IT infraštruktúra bola dostatočne flexibilná, škálovateľná a bezpečná, pričom musí umožniť efektívnu správu rastúceho objemu dát a aplikácií. Zároveň sa v rámci tejto stratégie kladie dôraz na postupné znižovanie nákladov a zvyšovanie udržateľnosti IT prevádzky, čím sa MZ SR aktívne zapája do širších iniciatív v oblasti „zelených dátových centier“ a energetickej efektívnosti.

V rámci cieľového návrhu architektúry je plánované vybudovanie hybridnej platformy, ktorá spája to najlepšie zo sveta RISC architektúry pre vysokovýkonné spracovanie dát a integráciu, s vysoko výkonnou kontajnerovou platformou pre scale-out BI scenáre, ktorá zároveň poskytne moderné prostredie pre beh kontajnerových aplikácií. Táto platforma bude súčasťou hybridnej infraštruktúry, ktorá zahŕňa:

• Nezávislé vývojové, testovacie, predprodukčné, produkčné prostredia – prostredia budú oddelené, čím sa zabezpečí testovanie, nasadzovanie a škálovanie aplikácií bez vplyvu na prevádzkovú stabilitu. V projekte je zabezpečený dostatočný počet procesorov na efektívne rozdelenie prostredia na jednotlivé fázy: vývojové, testovacie, predprodukčné a produkčné. Presné požiadavky na reálny workload budú definované až počas fázy analýzy a návrhu systému. Hlavnou výhodou implementovaného riešenia je využitie funkcionality dynamického prideľovania zdrojov. Táto funkcionalita poskytuje vysokú úroveň flexibility pri správe IT infraštruktúry, umožňujúc prerozdelenie výpočtových kapacít medzi jednotlivými prostrediami podľa aktuálnych potrieb. To znamená, že zdroje sa môžu operatívne alokovať tam, kde sú v danom čase najviac potrebné, čím sa optimalizuje výkon a znižuje celková záťaž systému. V prípade, že by sa počas etapy analýzy a dizajnu identifikovali špecifické potreby, riešenie bude možné upraviť tak, aby zohľadnilo nové požiadavky bez nutnosti zásadnej rekonfigurácie infraštruktúry.

Nasadenie kontajnerovej platformy je dôležitým krokom k zavádzaniu DevSecOps prístupu, ktorý umožní automatizáciu procesov, zrýchlenie nasadzovania aplikácií a flexibilnejšiu správu IT prostredia, s ohľadom na bezpečnosť infraštruktúry a aplikácií.

Hardvérovým základom cieľovej architektúry bude hybridná platforma, ktorá poskytuje spoľahlivé a výkonné riešenie pre virtualizované prostredie, aj pre kontajnerové aplikácie. MZ SR plánuje naďalej aj využívanie virtualizácie serverov, čím sa umožní prevádzka kritických aplikácií na stabilných a osvedčených technológiách.

Kľúčové prvky cieľovej infraštruktúry:

• Hyperkonvergovaná infraštruktúra: Hlavná platforma pre virtualizáciu a kontajnerizáciu.
• Cloud Native platforma: Moderná kontajnerová platforma pre nové a modernizované aplikácie, ktoré budú prevádzkované primárne v prostredí MZ SR. Cloud Native platforma, v prípade potreby enormného nárastu požiadaviek na dostupný výpočtový výkon alebo úložný priestor, umožňuje transparentný prechod medzi onsite prostredím MZ SR a poskytovateľmi cloudových služieb.
• Hybridný prístup: Umožnenie prevádzky existujúcich aplikácií na VM s možnosťou scale-out na kontajnerové riešenia.
• Zvýšenie flexibility a bezpečnosti: Prostredie musí podporovať bezpečnú a efektívnu správu aplikácií s možnosťou rýchlej relokácie zdrojov.

V rámci projektu sa kladie veľký dôraz na energetickú efektívnosť a znižovanie uhlíkovej stopy v súlade so stratégiou „zelených dátových centier“. Hybridná RISC platforma v kombinácii s hyperkonvergovanou infraštruktúrou a kontajnerizačnými technológiami umožňujú výrazne efektívnejšie využitie infraštruktúry prostredníctvom zdieľania zdrojov, čo vedie k zníženiu energetických nárokov a prevádzkových nákladov. Medzi konkrétne aktivity, ktoré podporujú tento cieľ, patria:

• Optimalizácia úložných riešení: Prechod na hybridné (SSD + HDD) alebo plne SSD úložiská
• Hyperkonvergovaná infraštruktúra: Vysoká miera využitia spoločných zdrojov cez virtualizované a kontajnerové prostredie znižuje potrebu ďalšieho hardvéru, čím sa znižujú aj prevádzkové náklady a uhlíková stopa.

Zavádzanie moderných workloadov: Podpora nových typov aplikácií, vrátane systémov s umelou inteligenciou (AI), kde jednotlivé komponenty môžu byť nasadené na RISC platformu a zároveň na hyperkonvergovanú infraštruktúru s vysokým výkonom, podľa výkonnostných potrieb daného komponentu.

• Energetická efektívnosť RISC platformy pri pomere výkonu na watt pri veľkom množstve integračných endpointov, a pri spracovaní veľkého množstva dát v rámci ETL, MDM procesov, pri procesoch dátovej kvality a dátového čistenia. A zároveň energetická efektívnosť pri prevádzke podporných aplikácii a BI v prostredí hyperkonvergovanej infraštruktúry.
• Dedikované úložisko zabezpečí dodatočný operatívny prístup k hot a cold dátam pre BI spracovania, zároveň ochráni dáta vďaka immutable technológii. Dedikované úložisko zabezpečí dostatočné škálovanie a možnosti rozširovania do budúcnosti pri zachovaní energetickej efektívnosti.

V rámci budovania infraštruktúry bude kľúčové sústrediť sa na:

• Optimalizáciu zdrojov: Postupná relokácia zdrojov medzi virtualizovaným a kontajnerovým prostredím na základe rastúceho dopytu po modernizovaných aplikáciách.
• Podporu pre nové workloady: Nasadenie systémov s umelou inteligenciou (AI) a ďalšie pokročilé aplikácie, ktoré vyžadujú špecifické typy infraštruktúry.
• Ekologické prístupy a znižovanie nákladov: Ďalšie znižovanie energetických nárokov prostredníctvom inovatívnych HW/SW infraštruktúrnych riešení.

Nasadenie hybridnej platformy a jej integrácia s existujúcimi virtualizovanými prostrediami s využitím RISC platformy a hyperkonvergovanej infraštruktúry umožní postupný prechod na moderné kontajnerované (cloud native) riešenia, čím sa zabezpečí dlhodobá udržateľnosť a zníženie prevádzkových nákladov rôznorodých aplikácii MZ SR.

V súčasnom stave je technologická infraštruktúra zabezpečená štandardnými prostriedkami a informačno-technickými zariadeniami MZ SR, akými sú pracovné stanice, notebooky, zdieľané serverové úložiská, počítačová sieť MZ SR a pod. Pre centralizované spracovanie veľkého počtu dát – integráciu, extrakciu, transformáciu a analýzu však nie je súčasná infraštruktúra postačujúca a je potrebné zabezpečiť rozvoj technickej infraštruktúry pre navrhované moduly CIP, akými sú hlavne výpočtový výkon a úložiská.  

4. 5. 3 Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

V nasledujúcej tabuľke sú predpokladané požiadavky na výkonnostné parametre, kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia, napr. počet interných používateľov, počet externých používateľov, počet spracovávaných procesov, dokumentov, komunikáciu medzi vrstvami architektúry IS, využívanie sieťovej infraštruktúry (Govnet, LAN, VPN, …). Uvedené predpoklady sú orientačné je potrebné spresniť počas fázy Analýza a Dizajn. 

Celková konfigurácia pre budúcu infraštruktúru MZ SR je rozdelená na dve etapy nasledovne:

Prvá etapa je vybudovanie robustného systému v správe a prevádzke MZ SR, bez nutnosti využívania cloudových riešení či už od MV SR , alebo NCZI. Ide o vybudovanie Onsite riešenia vyslovene v kompetencii MZ SR.

V druhej etape v podobe dopytového projektu na Lepšie využívanie údajov MZ SR bude riešené rozšírenie HW s SW časti o relevantný výkon a dodatočný počet serverov a úložnej kapacity.

Pre plánovanú implementáciu systému sa odporúča zabezpečiť vysokovýkonnú RISC platformu v kombinácii s HCI a dedikovaným úložiskom, čo splní náročné požiadavky na škálovateľnosť, spoľahlivosť a efektívne spracovanie veľkých objemov údajov. Navrhované preferované parametre pre budúci stav infraštruktúry sú nasledovné.

Odporúča sa vybrať hybridné riešenie, ktoré bude kombináciou RISC platformy a hyperkonvergovanej architektúry, čo zabezpečí vysokú škálovateľnosť a flexibilitu v prevádzke virtualizovaných a kontajnerových aplikácií. Umiestnenie servera v rackovej skrini bude štandardným riešením pre dátové centrum. Zároveň by mal server disponovať redundantným napájaním, čím sa zabezpečí nepretržitá prevádzka a minimalizuje riziko výpadkov.

[RISC Platforma] 

  │ 

  ├── (32Gbps FC) → [Dátové úložisko] → (datasety, MDM DB) 

  │ 

  └── (25GbE) → [HCI Cluster] → (ETL/Spark workloads, BI)

Výhoda navrhovanej architektúry je nasledovná, pretože spĺňa tieto požiadavky, aj z pohľadu udržateľnosti projektu:

• Vysoký výkon
  • RISC Platforma dokáže zabezpečiť MDM/RDBMS (nízka latencia).
  • HCI je možné škálovať pre ETL/Spark zaťaženia.
• Udržateľnosť
  • Podpora pre AI/ML scenáre.
  • Hybridné cloud riešenie.

Dodávateľ navrhne kompletnú serverovú infraštruktúru, dedikované úložisko, sieťové prvky a softvér pre prevádzku virtualizácie, DevSecOps, integrácií, data lake, dátovej platformy a business intelligence.

4. 5. 3.1  Požiadavky na výkonnostné parametre, kapacitné požiadavky – Integračný server

Server by mal dosahovať výkon pri 4 socketovom systéme podľa CPU 2017 benchmark v rámci SPECrate2017_int_peak minimálne 1580 bodov.

Odporúča sa, aby server disponoval minimálne 512 GB pamäte typu DDR5, pričom by mala byť dostupná možnosť rozšírenia až na 2 TB, aby bolo možné flexibilne reagovať na rastúce potreby systému. Ďalej sa odporúča podpora hardvérovej komprimácie pamäte, ktorá umožní efektívnejšie využívanie dostupnej kapacity.

Pre rýchly prístup k dátam by mal server obsahovať minimálne dva NVMe U.2 SSD disky s kapacitou aspoň 800 GB každý, čo zaistí vysokú rýchlosť čítania a zápisu a podporí plynulé spracovanie údajov.

Na zabezpečenie vysokej rýchlosti komunikácie s inými servermi sa odporúča vybaviť server minimálne štyrmi 10 Gbps Ethernet portami pre stabilnú a rýchlu komunikáciu s externými systémami. Na prístup k úložiskám dát by mal server disponovať minimálne štyrmi Fibre Channel portami s priepustnosťou 16 Gbps, čím sa zabezpečí dostatočný výkon pri prenose veľkých objemov dát.

V rámci podpory virtualizácie by server mal umožňovať definovanie minimálne 200 virtuálnych serverov, čím sa zvýši flexibilita a efektívne využitie dostupných zdrojov. Server by mal umožňovať nastavenie výkonových limitov pre skupiny virtuálnych serverov a dynamické prerozdelenie nevyužitého výkonu procesorov, čo optimalizuje zaťaženie. V prípade potreby by mal každý virtuálny server mať možnosť využiť celý výkon fyzického servera, pričom by mala byť zabezpečená funkcia presunu virtuálnych serverov medzi fyzickými servermi bez prerušenia prevádzky.

Preferovaný operačný systém pre server je Linux, ktorý by mal efektívne využívať celý dostupný výkon. Správa servera by mala byť možná na diaľku prostredníctvom vzdialeného prístupu, čo umožní efektívny monitoring a správu bez potreby fyzického prístupu.

Odporúča sa, aby server mal minimálnu záruku 3 roky, čím sa zabezpečí dlhodobá podpora a možnosť riešenia prípadných hardvérových problémov.

Navrhované parametre pre budúci stav servera zabezpečia výkonnú, škálovateľnú a flexibilnú infraštruktúru pre efektívnu prevádzku navrhovaného riešenia. Výkonná pamäť, vysokorýchlostná konektivita, vysoká efektivita výkonu na watt poskytnú základný kameň pre rýchle spracovanie veľkého objemu dát, s vysokým množstvom transakcií.

Tabuľka uvedená nižšie zobrazuje prehľad vybraných požiadaviek v budúcom stave pre serverovú časť pre Etapu 1.

Tabuľka 8: Sumárny prehľad vybraných požiadaviek v budúcom stave pre server

4. 5. 3.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – HCI

Hyperkonvergovaná infraštruktúra bude obsahovať 4 uzly, pričom 1 uzol bude koordinačný a 3 pracovné

4. 5. 3.3 Požiadavky na výkonnostné parametre, kapacitné požiadavky – Storage

Pre navrhovanú infraštruktúru úložiska sú preferované minimálne požiadavky na diskové mid-range pole, ktoré by malo zabezpečiť vysokú dostupnosť, efektívne ukladanie dát a vysoký výkon pre podnikové aplikácie.

Diskové pole by malo byť strednej kategórie s minimálne 256 GB cache pamäťou a redundantnými napájacími zdrojmi a kontrolérmi s podporou dátovej priepustnosti 256 Gb/s. Základný softvér pre správu diskového poľa musí zahŕňať funkcie internej virtualizácie, thin provisioningu, in-line kompresie a deduplikácie, synchrónnej a asynchrónnej replikácie, automatického tieringu, snapshotov a klonov LUN, nemeniteľných kópií LUN a multipath ovládačov. Softvérová a hardvérová podpora musí byť zabezpečená na obdobie minimálne 3 rokov.

Kapacita diskového poľa by mala dosahovať minimálne 34 TB RAW na NVMe SSD alebo Flash diskoch s efektívnou kapacitou 21 TiB bez kompresie a deduplikácie, so zapojením do RAID6 a HSP kapacitou distribuovanou cez všetky diskové moduly.

Diskové pole musí byť montovateľné do štandardnej 19-palcovej skrine, s redundantným jednofázovým napájaním do 250V. Všetky kľúčové komponenty musia byť redundantné, vymeniteľné a rozšíriteľné počas prevádzky bez nutnosti odstávky aplikácií. Požaduje sa aktívne riadenie end-to-end NVMe konektivity, podpora NVMe SSD s in-line kompresiou a kryptovaním dát bez zaťaženia CPU riadiacich jednotiek, podpora NVMe SCM a rotačných diskov. Diskové pole musí umožňovať mixovanie SCM a SSD modulov, ako aj detekciu ransomware hrozieb. Cache pamäť systému musí byť chránená batériami pre bezpečné uloženie dát pri výpadku napájania.

Diskové pole musí podporovať redundantnú Host/SAN konektivitu s celkovou dátovou priepustnosťou 256 Gb/s pre MM FC a 40 GbE TX iSCSI, s podporou 25 Gb/s iSCSI, 64 Gb/s a 32 Gb/s FC konektivity. Dedikované porty na manažment diskového poľa sú nevyhnutné.

Softvér diskového poľa musí podporovať štandardný aj thin provisioning, in-line kompresiu a deduplikáciu s časovo neobmedzeným licenčným pokrytím. Požaduje sa možnosť automatického vytvárania snapshotov, klonov LUN a nemeniteľných kópií v nastavených časoch. Riešenie musí zabezpečovať online výmenu kontrolérov, aktualizáciu softvéru a firmvéru diskových modulov bez prerušenia chodu aplikácií, vrátane podpory online zväčšenia LUN, riadenia QoS a klastrovania kontrolérov. Podpora kryptovania dát, monitoring záťaže a výkonu v reálnom čase sú takisto požadované.

Úložisko musí umožňovať vysokú dostupnosť dát v dvoch geograficky oddelených lokalitách s automatickým prepnutím IO operácií v prípade HW výpadku, pričom riešenie je transparentné voči pripojeným hostom. Systém musí tiež podporovať split-brain situácie pomocou SW arbitra.

Požadovaný manažment diskového poľa zahŕňa integráciu do MS HyperView, VMware VAAI a VASA, komerčné multipath ovládače pre OS zahrnuté v cene, manažment prostredníctvom GUI a CLI cez HTTPS a SSHv2, logovanie prístupov a udalostí, viacúrovňový manažment prístupových práv a integráciu do LDAP. Všetky potrebné komponenty vrátane kabeláže musia byť súčasťou pripojenia do SAN.

Diskové pole musí byť kompatibilné s operačnými systémami Linux, MS Windows, Unix a VMware. Základná záruka na diskové pole musí byť minimálne 3 roky, čo zabezpečí dlhodobú podporu a spoľahlivú prevádzku.

Tabuľka uvedená nižšie zobrazuje sumárny prehľad požiadaviek v budúcom stave pre úložisko pre Etapu 1.

Tabuľka 9: Sumárny prehľad požiadaviek v budúcom stave pre storage

4. 5. 3.4 Požiadavky na výkonnostné parametre, kapacitné požiadavky – Integračná platforma

Integračná platforma je navrhnutá na prepájanie a integráciu aplikácií bez ohľadu na formáty a protokoly, ktoré tieto aplikácie podporujú. Poskytuje funkciu Enterprise Service Bus (ESB), čím umožňuje centralizovanú a spoľahlivú správu komunikácie medzi systémami a aplikáciami. Platforma musí zabezpečovať integrácie s využitím princípov architektúry orientovanej na služby (SOA) a fungovať ako sprostredkujúca vrstva (middleware), ktorá umožní vzájomnú komunikáciu sád služieb. Podpora rôznych protokolov a konektorov je nevyhnutná, pričom systém musí umožňovať prácu minimálne s JMS, HTTP, HTTPS, webovými službami (SOAP, REST), súbormi, TCP/IP, Kafka, ODBC a JDBC.

Platforma musí zabezpečovať spoľahlivý prenos správ, pričom v prípade nedostupnosti príjemcu musí implementovať nástroje na opakované odoslanie správ. Je dôležité, aby žiadna správa nebola v rámci integračnej platformy stratená – správa musí byť buď doručená, alebo uložená a zaradená do zoznamu nedoručených správ. Súčasťou platformy musí byť konektivita na messaging systém, ktorý je licenčne súčasťou riešenia, a musí podporovať transakčný spôsob spracovania správ.

Platforma musí podporovať širokú škálu formátov, minimálne XML, JSON, priemyselné štandardy a vlastné formáty, aby zabezpečila flexibilitu pri práci s rôznymi dátovými štruktúrami. Integrované grafické prostredie poskytuje možnosti návrhu, testovania a ladenia integračných scenárov a integračnej logiky, pričom umožňuje vývoj integrácií bez potreby kódovania. Súčasťou grafického prostredia je aj možnosť vytvárania šablón pre opakované použitie, čo zjednodušuje a zrýchľuje tvorbu nových integračných riešení. Vývoj integrácií môže byť realizovaný oddelene od ich nasadenia.

Platforma musí podporovať rôzne operácie pre spracovávané správy, vrátane smerovania (routing), transformácie, filtrovania, obohacovania, monitorovania, distribúcie, zberu, korelácie a detekcie. Smerovanie aktivít musí byť možné na základe obsahu správ, a tiež musí byť zabezpečená transformácia správ do formátu vhodného pre jednotlivé pripojené systémy. Platforma musí umožňovať prácu s XML schémami (XSD) a webovými službami (WSDL), vrátane validácie správ voči definovaným schémam, pričom transformácie môžu byť definované pomocou grafického editora s podporou mapovania, Java, SQL a XSL.

Podporovaná musí byť aj tvorba modelov popisujúcich štruktúru správ a konektory pre možnú budúcu integráciu s cloudovými SaaS službami, v prípade nutnosti masívnej neočakávanej požiadavky na scale-out riešenia. Riešenie musí umožňovať nasadenie vo forme kontajnerov a podporovať vertikálnu aj horizontálnu škálovateľnosť. To zahŕňa možnosť behu ľubovoľného počtu integračných runtime s nasadením viacerých scenárov pre každý runtime. Runtime musí obsahovať grafické rozhranie s prístupom k štatistikám o jednotlivých integráciách, priepustnosti a počtoch spracovaných transakcií.

Administrácia a riadenie systému musí byť možné z príkazového riadku, grafickej konzoly, cez webové rozhranie alebo REST API, čím sa zabezpečuje flexibilné riadenie. Na zaistenie vysokej dostupnosti musí platforma pracovať v režime HA (High Availability) a podporovať vyvažovanie záťaže (Load Balancing), čím sa dosiahne nepretržitá prevádzka aj v prípade zlyhania niektorých komponentov.

Týmto spôsobom integračná platforma umožňuje efektívne prepojenie aplikácií a systémov, podporuje automatizáciu procesov, zlepšuje komunikáciu medzi službami a zabezpečuje vysokú dostupnosť a spoľahlivosť prevádzky.

4. 5. 3.5 Požiadavky na výkonnostné parametre, kapacitné požiadavky – Analytická platfroma

Architektúra riešenia bude integrovaná do navrhnutej arch. MZ SR a bude jej komplementárnym rozšírením o HW a SW, pre potreby dodatočných modulov na pre kvalitu údajov a my data komponent. Architektúra riešenia musí byť navrhnutá tak, aby oddeľovala vykonávací mechanizmus SQL od dátového skladu, čím sa zabezpečí nezávislosť týchto dvoch komponentov. Toto oddelenie umožní podporu viacerých typov vykonávacích engines SQL podľa typu spracovávanej úlohy, pričom príslušný vykonávací engine SQL sa bude môcť pripojiť k príslušnej databáze údajov. Riešenie musí umožňovať prístup k databáze prostredníctvom otvoreného tabuľkového formátu, pričom bude podporovaný distribuovaný SQL engine.

Riešenie musí tiež poskytovať konektory na pripojenie k existujúcim zdrojom údajov, vrátane relačných databáz a NoSQL databáz, prostredníctvom distribuovaného SQL engine. Zároveň musí ponúkať jednotný prístupový bod ku všetkým pripojeným zdrojom, čo zjednoduší prístup k rôznym typom údajov pre analytické platformy. V rámci správy prístupov musí systém umožniť používateľom prístup na základe pridelených rolí, pričom bude možné definovať prístupové pravidlá na úrovni vykonávacích engines a dátových spojení. Ďalej musí byť možné definovať politiky až na úroveň položiek tabuľky.

Riešenie musí obsahovať aj funkcionalitu na sledovanie historického prehľadu všetkých SQL operácií, pričom bude možné analyzovať plány vykonávania SQL s cieľom ich optimalizácie. Nasadenie riešenia musí byť možné na kontajnerovej platforme pre samostatnú inštaláciu spravovanú zákazníkom, ako aj na všetkých verejných cloudových platformách, musí sa jednať o cloud native rišenie. Riešenie musí podporovať prevádzku ako dodatočný komponent k existujúcemu systému. Minimálne funkčné požiadavky sú nasledovné:

• Integrovanie s rôznymi systémami a aplikáciami
• Musí byť k dispozícii jednotné webové používateľské prostredie s protokolom HTTPS
• Systém musí umožňovať správu prostredníctvom príkazového riadku
• Na jednotné spracovanie a optimalizáciu údajov z rôznych zdrojov údajov musí systém podporovať prevádzku viacerých typov exekučných mechanizmov
• Systém musí podporovať engine exekúcie na spracovanie úloh dátového skladu
• Architektúra systému musí byť navrhnutá tak, aby oddeľovala engine exekúcie a dátové sklady s možnosťou súčasného prístupu rôznych engine exekúcie k dátovému skladu
• Systém musí podporovať otvorený tabuľkový formát
• Systém musí podporovať rôzne otvorené formáty údajov vhodné pre prácu s veľkými objemami údajov, ako napríklad Parquet, Avro, ORC, Delta Lake, Apache Iceberg alebo ekvivalentné
• Konverzia dát do jednotného formátu (napr. CSV, JSON, XML)
• Systém musí podporovať metaúložisko ako úložisko metadát
• Riešenie musí umožňovať jednotné distribuované SQL spracovanie údajov z rôznych zdrojov údajov (štruktúrované, pološtruktúrované a neštruktúrované zdroje údajov).
• Pre transakčné spracovanie musia byť splnené podmienky ACID
• Systém má nástroje na optimalizáciu dotazov SQL
• Systém musí umožňovať prístup k existujúcim platformám relačných databáz OLTP a platformám dátových skladov
• Systém musí podporovať niektorú z databáz NoSQL
• Systém musí podporovať distribuovanú streamingovú platformu Apache Kafka alebo ekvivalent
• Systém musí poskytovať správu dátových tokov ( data linage )
• Systém musí poskytovať ochranu citlivých údajov
• Systém musí zabezpečiť, aby sa dátové procesy a údaje spravovali v súlade s účinnými právnymi predpismi (data governance)

4. 5. 4 Návrh riešenia technologickej architektúry

Centrálnu integračnú platformu bude tvoriť množina modulov, ktoré budú zodpovedné za získavanie dát, ich spracovanie a prezentáciu používateľovi. Podstatou je, že dáta sa nebudú pripravovať manuálnym spôsobom, ale platforma bude schopná pomocou vytvorených integrácií dáta extrahovať priamo zo zdrojového systému. Aj napriek viacerým zdrojom dát bude platforma zabezpečovať konsolidované dáta v jednotnej štruktúre. Správnosť a kvalita dát bude zabezpečovaná modulom dátovej kvality, ktorý bude priebežne vyhodnocovať správnosť dát. Spracované a skontrolované dáta budú slúžiť ako základ reportingu v reportingovom module, kde si používatelia budú môcť prezerať existujúce reporty, alebo si vyskladať report podľa potreby.  

Samotné používateľské rozhranie CIP bude webová aplikácia, ktorá bude dostupná z webového prehliadača. 

Navrhovaná Centrálna integračná platforma bude mať viac vrstvovú architektúru a bude poskytovať viaceré funkcie: 

• Integračný komponent

• Extrakčná funkcia 
• Funkcia dátového štandardu 

• Modul kvality a čistenia údajov 

• Funkcie dátovej kvality 

• Business Intelligence modul (reportingový modul) a Používateľské rozhranie 

• Analytické a zobrazovacie funkcie 

• Modul Rozhrania nemocníc 

• Rozhrania na strane NIS nemocníc, ktoré sú potrebné pre integráciu CIP 

Modul Integračný komponent

Na nasledujúcom obrázku je znázornená konceptuálna architektúra technického riešenia Centrálnej integračnej platformy – Modulu integrácia. 

Obrázok 5 Konceptuálna architektúra technického riešenia 

Integračná funkcia bude zodpovedná za realizáciu integrácií na zdrojové systémy. Bude realizovať pripojenie na dátový zdroj vo vopred dohodnutých časových intervaloch. Po pripojení a extrakcii dát sa systém ihneď ako to bude možné, odpojí od dátového zdroja, aby sa predišlo vyťaženiu a spomaleniu zdrojového systému. 

Predpokladané integrácie: 

Extrakčná funkcia bude slúžiť na samotnú extrakciu dát. Bude obsahovať samotné ETL procedúry na extrakciu dát a dátové štruktúry do ktorých budú tieto dáta ukladané. Tieto dáta budú zo zdrojového systému extrahované v surovom stave, to znamená že na nich počas procesu nebudú aplikované žiadne zmeny. Tieto dáta budú extrahované ako celkový extrakt, alebo ako inkrementálny extrakt. Typ extraktu, periodicita a rozsah dát budú definované po detailnej analýze. 

Dáta v extrakčnej vrstve budú dostupné po dobu definovanú potrebami, alebo dodávateľom. 

Funkcia zmeny dátového štandardu bude obsahovať transformačné procedúry zodpovedné za: 

• Zmena dátového štandardu, 

• Konsolidácia dát, 

• Agregácia dát, 

• Kalkulácia metrík, 

• Čistenie dát. 

Zdrojom dát pre túto vrstvu budú dáta získané extrakciou v extrakčnej vrstve. Procedúry na zmenu dátového štandardu budú navrhnuté a realizované na základe detailnej analýzy dodávateľom počas implementačnej fázy projektu.  

Modul kvality a čistenia údajov

Modul dátovej kvality bude obsahovať špecifické procedúry na vyhodnocovanie dátovej kvality. Tieto procedúry navrhne a vyvinie dodávateľ na základe detailnej analýzy počas implementačnej fázy. Kontroly budú automatizované a budú aplikovateľné v extrakčnej, transformačnej a prezentačnej vrstve. Výsledok dátovej kontroly bude zaslaný pridelenému vlastníkovi dátovej kontroly, prípadne zapísaný do metadát a neskôr zobrazený v reporte dátovej kvality. Na základe vážnosti problému s dátami modul rozhodne o zastavení ďalších ETL procesov, alebo len o informovaní vlastníka. 

Modul Business Intelligence / Reportingová vrstva

Táto vrstva ponúkne používateľovi možnosť vytvorenia reportov nad dátami dostupnými v prezentačnej vrstve. Dáta budú používateľom prezentované ako vizualizované reporty, prostredníctvom vizualizácií. Reporting bude dynamický a interaktívny. Vždy bude obsahovať aktuálne dáta, s reportom bude môcť používateľ pracovať a podľa potreby filtrovať, prehliadať, analyzovať dáta. 

Viditeľnosť dát bude ovplyvnená prístupovými právami pridelenými konkrétnemu používateľovi, resp. skupine používateľov. 

Prezentačná funkcia obsahuje samotný finálny konsolidovaný dátový model. Bude zodpovedná za napĺňanie finálneho dátového modelu dátami, teda fyzickej dátovej štruktúry a za ukladanie týchto dát vo fyzických dátových štruktúrach. Taktiež bude tieto dáta historizovať a uchovávať informácie o zmenách v dátach. 

Dáta tejto vrstvy budú dostupné pre konzumentov dát a budú zobrazované v používateľskom rozhraní platformy. 

Dodávateľ navrhne logický dátový model na základe detailnej analýzy používaných a požadovaných dát. Tento model po validácií a schválení MZ SR použije pre vytvorenie a implementáciu fyzického dátového modelu. 

Predmetom analýzy dodávateľa bude aj analýza uskutočniteľnosti tohto modelu a procesov s ním spojených. 

Používateľské rozhranie 

Je to priestor, v ktorom používateľ vie pracovať s CIP platformou, vie využívať jej funkcionality a vie pristupovať k dátam. Tento priestor by mal byť intuitívny a ľahký na pochopenie. 

Rámcová technologická architektúra vyplýva z vybranej alternatívy aplikačnej architektúry.. Súčasná infraštruktúra nie je kapacitne prispôsobená pre podmienky fungovania CIP a je preto potrebné vytvoriť prostredia, ktoré zabezpečia: vývoj, testovanie a prevádzku CIP ako aj zálohovanie údajov.  

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

V projekte sa nepredpokladá využívanie služieb vládneho cloudu.

4.6 Bezpečnostná architektúra

V súčasnom stave je bezpečnosť údajov riadená zmysle interných predpisov MZSR. Navrhovaný systém by mal spĺňať minimálne požiadavky v zmysle CSIRT - Metodiky pre systematické zabezpečenie organizácií verejnej správy v oblasti informačnej bezpečnosti. https://www.csirt.gov.sk/metodika-zabezpecenia-ikt.html?csrt=13813447150791197614

Navrhované riešenie musí byť v súlade s právnymi normami v oblasti kybernetickej bezpečnosti a ochrany údajov a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS, pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o zákony a vykonávacie predpisy:

• 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
• 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 v znení neskorších predpisov
• 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
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov

Vzhľadom k tomu, že sa jedná o informačný systém v oblasti zdravotníctva, musí byť v súlade so všetkými právnymi normami, ktoré sú požadované pre budovanie IS v oblasti zdravotníctva, ako aj pre budovanie IS vo verejnej a štátnej správe.

5 Závislosti na ostatné ISVS / projekty

Prehľad známych projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá.

V prehľade nie sú uvedené plánované zmeny v IS dotknutých PZS, napr. plánované výmeny nemocničných informačných systémov, predĺženie podpory IS v nemocniciach na dlhšie obdobia a pod. Plány pre obstarávania a objednávania zmien v IT sú evidované PZS priebežne do centrálneho systému, sledované a odsúhlasované na úrovni MZ SR.

6 Zdrojové kódy

Ustanovenia k zdrojovým kódom a licenciám budú uvedené v zmluve s dodávateľom v zmysle zákonnej právnej úpravy a  usmernenia pre oblasť zdrojových kódov:

• Zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov a jeho vykonávacie predpisy
• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/
• Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en
• Vyhláška č. 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, najmä Príloha č.2 tejto vyhlášky, časť J. Akvizícia, vývoj a údržba informačných technológií verejnej správy.

7 Prevádzka a údržba

Úroveň podpory používateľov bude v súlade s internými postupmi MZ SR v oblasti správy systémov a definovaná v rámci servisnej zmluvy resp. SLA.

7. 1 Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.

Označenie naliehavosti incidentu:

možný dopad:

 Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

Vysvetlivky k tabuľke

(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

(2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu úspešným uchádzačom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je úspešný uchádzač oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

(3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

(4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2 Požadovaná dostupnosť IS:

7.2.1 Dostupnosť (Availability)

Dostupnosť (Availability) je vyjadrená ako percento času v danom období, obvykle za rok. Predpokladá sa dostupnosť na úrovní 98% dostupnosť, čo znamená kumulatívny výpadok 7,30 dňa ročne resp. 14 hodín mesačne.

8 Požiadavky na personál

Požiadavky na personál sú uvedené v dokumente Projektový zámer v kapitole č. 9.

9 Prílohy

Príloha č.1: I_02_BC_CBA_PRILOHA_Projekt_CIP_MZSR_240415_NAVRH_v_1.5.xlsx (CBA a KATALÓG POŽIADAVIEK)

Príloha č. 2: Katalóg existujúcich výkazov CES

Koniec dokumentu

Príloha č. 2: Katalóg výkazov CES

Tabuľka nižšie obsahuje zoznam dostupných štandardných výkazov CES v zmysle publikovaného dokumentu MF SR - DSR2_CES_M27_Reportig.docx, zdroj:

https://ces.mfsr.sk/ces/specifikacia-modulov/m27-reporting.html

V tejto prílohe je uvedený sumárny prehľad výkazov. Tabuľka je zhrnutím výkazov identifikovaných a používaných v jednotlivých modulových a procesných dokumentoch v rámci Detailnej špecifikácie riešenia (DŠR).