PROJEKTOVÝ ZÁMER
Vzor pre manažérsky výstup I-02
podľa vyhlášky MIRRI č. 401/2023 Z. z.

1.História DOKUMENTU

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

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravy projektu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, pláne realizácie, alokovaní rozpočtu a ľudských zdrojov.

2.1Použité skratky a pojmy

2.2Konvencie pre typy požiadaviek

Konvencie pre definíciu požiadaviek sú využité v rámci Katalógu požiadaviek. Tento katalóg obsahuje funkčné, nefunkčné a technické požiadavky kladené na riešenie realizované v rámci projektu NIS.

Požiadavky sú rozdelené podľa jednotlivých modulov a inkrementu, pričom každá požiadavka zahŕňa analýzu, vývoj, testovanie a nasadenie.

Katalóg obsahuje nasledujúce kategórie požiadaviek:

• Funkčné požiadavky - týkajú sa konkrétnej funkcionality systému, ktorú je potrebné implementovať. V rámci Katalógu požiadaviek začínajú písmenom F.
• Ne-Funkčné požiadavky - zahŕňajú kvalitatívne a výkonové aspekty. V rámci Katalógu požiadaviek sú označené v stĺpci A skratkou NF.
• Technické požiadavky - týkajú sa technického aspektu koncového riešenia. V rámci Katalógu požiadaviek sú označené v stĺpci A písmenom T nasledovné číselným označením.

Oblasť požiadavky - popisuje kategóriu alebo doménu, do ktorej daná požiadavka patrí. Zahŕňa určitú ucelenú oblasť každého druhu požiadavky (Funkčné, Nefunkčné, Technické požiadavky).

Názov požiadavky - ide o jednoduchý názov požiadavky, ktorý determinuje o čom daná požiadavka je.

Detailný popis požiadavky - poskytuje podrobné informácie o konkrétnej požiadavke. Jej účelom je zabezpečiť jasné pochopenie, čo sa má implementovať, aké sú očakávania, a akým spôsobom sa má požiadavka realizovať, čo bude predmetom spresnenia v detailnom návrhu riešenia.

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Spoločnosť Asseco Centra) Europe listom z 21.3.2024 oznámila, skutočnosť že ku dňu 31.3.2025 ukončí podporu všetkých produktov a služieb v súvislosti s Nemocničným informačným systémom Xanta. To znamená, že po 31.3.2025 vzhľadom na závislosť procesov nemocnice aj na nemocničnom informačnom systéme, nastane problém s podporou systému, ktorá sa prejaví napríklad neschopnosťou pripojenia do eZdravia a vykázania výkonov zdravotným poisťovniam ako aj celkovú paralýzu komunikácie čo môže vo FN Nitra spôsobiť výrazné obmedzenie až zastavenie poskytovania zdravotnej starostlivosti pacientom s dopadom na finančný a personálny stav ako aj kredit nemocnice. Vyššie uvedené spôsobilo, že FN Nitra potrebuje obstarať nový IS, ktorého cieľom bude vyriešenie kritickej situácie hraničiacej s možnosťou neplnenia zákonných postupov až ohrozenia ekonomiky a poskytovania zdravotnej starostlivosti v súvislosti s predčasným ukončením podpory a rozvoja stávajúceho Nemocničného informačného systému vo FN Nitra. Zámerom projektu rozvoja (META IS: projekt_3325) je implementácia NIS, ktorý pokryje v plnej miere doterajší NIS, ako aj všetky potreby pacientsko-klinického procesu a tiež umožniť sledovať, hodnotiť a riadiť prevádzku organizácie v reálnom čase tak, aby poskytoval ucelený prehľad o stave organizácie.

Implementácia nového NIS je nevyhnutným krokom z pohľadu udržateľnosti a bezpečnosti poskytovania zdravotnej starostlivosti vo FN Nitra. Existujúci NIS nemá k dispozícii servisnú podporu a nie je do neho možné zapracovať akékoľvek nové legislatívne požiadavky.

Predpokladané financovanie

Projekt bude financovaný z kapitálových výdavkov FN Nitra, o ktoré požiadala Ministerstvo zdravotníctva SR.

Predpokladané výdavky boli stanovené na základe PHZ, pričom sa jedná o nasledovné:

013 Softvér 2 159 138 € s DPH
511 Opravy a udržiavanie + 013 Softvér (rozvoj) 826 560 s DPH

Predpokladaný rozvoj a podpora je plánovaná na 48 mesiacov

3.2Motivácia a rozsah projektu

• Vzhľadom na vypovedanie servisnej podpory na existujúci NIS Xanta je nevyhnutné tento zastaralý NIS nahradiť novým NIS spĺňajúcim všetky legislatívne a užívateľské požiadavky.

  Súčasný NIS vykazuje nasledujúce závažné nedostatky:

• Externý Audit bezpečnosti NIS Xanta, ako aj serverov poukazuje na viaceré kritické zraniteľnosti z aplikačného pohľadu, ako aj z pohľadu prevádzky systému aj jeho podpory
• Momentálne sa na NIS Xanta nachádza veľké množstvo kritických zraniteľností spôsobených prevádzkovaním neaktuálnych softvérových produktov bez možnosti ich aktualizácie.
• Klient XANTA používa UNIFACE 9.6 z roku 2012 s ukončenou podporou v roku 2017.
• Program XANTA používa zastaraný .NET Framework 3.5 z roku 2007
• Momentálne nie je možné vykonať kontrolu záloh systému a ak dôjde k poškodeniu hardvérového vybavenia, nie je možné vykonať migráciu dát.
• V programe XANTA absentuje možnosť prepojenia na digitálnu patológiu – súčasť projektu. Nedokážeme zabezpečiť udržateľnosť projektu.

•  

3.3Zainteresované strany/Stakeholderi

• Doplňte KTO (zoznam subjektov/osôb) sa zúčastňuje projektu a akú rolu zastáva

3.4Ciele projektu

Projekt svojou realizáciou napĺňa aj ciele NKIVS a to nasledovným spôsobom:

Z pohľadu cieľov projektu a väzieb na strategické ciele NKIVS je ich prepojenie nasledovné:

3.5Merateľné ukazovatele (KPI)

V nasledujúcej tabuľke sú uvedené základné merateľné ukazovatele (KPI), ktoré budú projektom dosiahnuté

Ukazovatele sú odborný kvalifikovaný odhad, pričom vychádzajú z:

• bežných štandardov a benchmarkov v zdravotníckych IS,
• praxe zo slovenských aj európskych nemocníc,
• skúseností z projektov digitalizácie a zavádzania NIS (vrátane EMRAM, HL7, eHealth)
• typických výkonnostných parametrov, ktoré si nemocnice sledujú.

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

Tento projekt nie je primárne určený pre užívateľov PO a FO a preto nie je predmetom ani používateľský prieskum. Zároveň však boli definované základné požiadavky koncových užívateľov, ktorými sú lekári, zdravotní pracovníci a manažment nemocnice:

• NIS musí poskytovať intuitívne užívateľské rozhranie pre používateľov;
• NIS musí mať používateľské rozhranie v slovenskom jazyku
• NIS musí spĺňať všetky zákonné požiadavky a je certifikovaný v plnom rozsahu povinných funkcionalít podľa platných integračných manuálov a procesných scenárov publikovaných NCZI. Certifikácia sa preukazuje uvedením na webovom sídle NCZI
• NIS musí na komunikáciu s eZdravie používať požadované funkcionality, služby a rozhrania
• NIS musí mať zabudovanú funkcionalitu na vykazovanie v rozsahu pre kalkulačnú nemocnicu;
• NIS musí mať zabudovanú funkcionalitu na pripojenie k službám Bezpečné lieky ZP Dôvera;
• NIS musí vyhovovať požiadavkám GDPR, musí mať možnosť logovania minimálne takých záznamov ako – užívateľ, čas, akcia (napr. ktorý užívateľ, kedy, pristupoval k údajom pacienta, či ich iba čítal alebo aj menil...);
• NIS musí mať možnosť evidenciu činností na užívateľa (aj zaznamenanie do log súboru);
• NIS musí poskytovať široké možnosti pre správu systému, aby nebola potrebná častá podpora dodávateľa pri prevádzke;
• Správca musí mať možnosť upravovať položky číselníkov bez nutnosti zásahu dodávateľa;
• Jednoduchá správa nastavení, ktoré si dokážu používatelia udržiavať samostatne, správca môže riadiť lokálne nastavenia;
• NIS musí byť pravidelne aktualizovaný v súlade s legislatívou SR a požiadavkami MZSR, NCZI, ZP, UDZS;
• NIS musí umožniť automatickú aktualizáciu aplikačných programov NISpri nasadení nových verzií  bez nutnosti manuálnej inštalácie na klientskych PC;
• Správca musí mať možnosť zaevidovať nových používateľov, definovať a meniť nastavenia pre ich prístupové práva;
• Správca môže obmedziť prácu používateľov iba na určené funkcie systému, s ktorými sú oprávnení pracovať (položky menu, ikony, tlačidlá);
• NIS musí mať možnosť globálnych nastavení pre celú nemocnicu alebo pre vybrané oddelenia;
• Možnosť nastavenia prístupových práv k zdravotným záznamom ambulancií, oddelení;
• NIS musí mať zabudovaný automatický audit zmien dôležitých údajov, správca môže vyhľadať pôvodcu neželaných zmien;
• NIS musí vykonávať validáciu údajov v momente ich zadávania do systému (kódy diagnóz, výkonov, liekov, lekárov, atď.) a to na úrovni masky danej položky a tiež prostredníctvom číselníkov/registrov;
• NIS musí umožniť prácu s jedným pacientom na viacerých oddeleniach viacerým používateľom súčasne ;
• NIS musí zobraziť pohyb pacienta v rámci celého zdravotníckeho zariadenie;
• Musí byť možnosť dopracovania špeciálnych tlačív a formulárov;
• Musí byť možnosť drobných úprav tlačív a formulárov správcom systému;
• Musí byť možnosť nastavenia loga a vlastnej hlavičky nemocnice v tlačivách a formulároch;            
• NIS musí upozorniť na prípadný výskyt duplicitných rodných čísel v centrálnom registri pacientov;
• NIS musí umožniť generovanie všetkých potrebných štatistických hlásení pre NCZI aj vo forme XML (ak je táto možnosť pre dané hlásenie poskytnutá), musí mať možnosť zadania všetkých sledovaných údajov do ucelených formulárov, ktoré by sa mali dať aj vytlačiť pre potreby archivácie v chorobopise pacienta
• NIS musí vedieť generovať ročné výkazy o činnosti poskytovateľov ZS podľa zoznamu platného pre vykazovaný rok, ktoré sú zverejnené na webovom sídle NCZI
• NIS musí vedieť generovať hlásenia pre Národné zdravotné registre, ktoré sú zverejnené na webovom sídle NCZI
• NIS musí mať možnosť vytvárania balíkov (makier) zostavených z položiek číselníkov zdravotníckych pomôcok a ŠZM, ktoré budú definované ako pripočítateľná položka k hospitalizácii alebo ambulantným výkonom;
• NIS musí umožňovať evidenciu antropometrických údajov a základných  vitálnych ukazovateľov (Tlak Krvi, Pulz, Výška, Hmotnosť, Povrch tela, BMI, Krvná skupina, ...);
• NIS musí umožniť výpočet povrchu tela  a BMI  na základe zadaných údajov hmotnosti a výšky;
• NIS musí mať možnosť vytvárania balíkov zostavených z položiek číselníkov zdravotníckych pomôcok a ŠZM, ktoré budú definované ako pripočítateľná položka k hospitalizácii alebo ambulantným výkonom;
• Automatizovaná pravidelná aktualizácia všetkých číselníkov vydávaných MZ SR, UDZS, NCZI, ZP ;
• Pravidelné aktualizácie kategorizačných zoznamov;
• NIS musí umožňovať export zostáv (reportov) do xls, xlsx resp. csv formátu;
• NIS musí podporovať vizity na lôžkových oddeleniach pomocou tabletov
• NIS podporuje integráciu na PACS systém cez štandardizovaný protokol HL-7
• NIS musí umožniť evidenciu hotovostných platieb s väzbou na elektronickú registračnú pokladnicu alebo fiškálnu tlačiareň;
• NIS musí mať možnosť automaticky urobiť dennú uzávierku (od prvého dňa v mesiaci — do aktuálneho dňa) pre ekonomické a štatistické sledovanie nákladovosti pacienta
• Registrácia a identifikácia pacienta na recepcii   
  • Tlač identifikačného náramku na recepcii            
  • Zaradenie ambulantného pacienta s identifikačným náramkom do čakárne       
• Registrácia a identifikácia pacienta na Urgentnom príjme   
  • Tlač urgentného identifikačného náramku - identifikovateľný pacient 
  • Tlač urgentného identifikačného náramku - neidentifikovateľný pacient             
  • Rýchla tlač identifikačného náramku tlačidlom „Neznámy“  
• Rozšírenie identifikácie pacienta          
  • Rozšírená evidencia a registrácia pacienta o ďalšie kontakty             
• Identifikácia pacienta cez náramok/lístok na ambulancii alebo na oddelení        
  • Identifikácia pacienta cez identifikačný náramok/lístok čítačkou         
• Webová predregistrácia a následná identifikácia pacienta  
  • Predregistrácia pacienta – telefonicky pracovníkom zdravotníckeho zariadenia
  • Predregistrácia pacienta - webové sídlo
  • Registrácia pacienta z predregistrácie 
• využitie piktogramov pre informácie o stave pacienta v ambulanciách a na oddeleniach
• NIS musí byť procesne orientovaný;
• NIS musí obsahovať nástroj na konfiguráciu a zmenu procesov (napr. proces schvaľovania operácii – jedno resp. dvojkrokový proces)

• 
  .

3.7Riziká a závislosti

3.8Stanovenie alternatív v biznisovej vrstve architektúry

3.9Multikriteriálna analýza

Výber alternatív prebieha na úrovni biznis vrstvy prostredníctvom MCA zostavenej na základe kapitoly Motivácia, ktorá obsahuje ciele stakeholderov, ich požiadavky a obmedzenia pre dosiahnutie uvedených cieľov.
Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť. Alternatívy, ktoré nesplnia všetky KO kritériá, môžu byť vylúčené z ďalšieho posudzovania. KO kritériá nesmú byť technologické (preferovať jednu formu technologickej implementácie voči druhej).
Príklad šablóny pre spracovanie MCA

Tabuľka - Vyhodnotenie MCA pre dotknuté alternatívy
Najvhodnejšia alternatíva na splnenie cieľov sa javí Alternatíva č. 3, pričom dôvodom odporúčania je teda rýchle a samostatné nasadenie nového NIS len pre Fakultnú Nemocnicu Nitra.

Toto riešenie:
• umožní prekonať kritický termín po ukončení podpory systému Xanta,
• je rýchlejšie, lacnejšie a organizačne zvládnuteľné,
• vytvára priestor na budúce rozšírenie alebo konsolidáciu, pričom rieši akútne potreby pracoviska.

Táto alternatíva sa odporúča ako krátkodobý, krízový a zároveň takticky rozumný krok pri zachovaní dlhodobého cieľa komplexného systému pre FN Nitra.

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

Navrhované riešenie nemocničného informačného systému predstavuje komplexný zásah do existujúceho technologického prostredia, a preto si vyžiadalo dôkladnú analýzu možných alternatív v rámci aplikačnej vrstvy architektúry. V zmysle princípov efektívneho riadenia projektov IT vo verejnej správe, ako aj v súlade s požiadavkami vyhlášky č. 401/2023 Z. z., boli zohľadnené viaceré architektonické varianty, ktoré zodpovedajú súčasným trendom v oblasti informačných technológií v zdravotníctve.

• Cieľom tejto analýzy bolo identifikovať takú architektonickú alternatívu, ktorá:
  • zabezpečí vysokú mieru dostupnosti a spoľahlivosti systému,
  • umožní flexibilné a efektívne riadenie klinických a podporných procesov,
  • bude podporovať škálovateľnosť riešenia s ohľadom na jeho dlhodobú udržateľnosť,
  • bude rešpektovať princípy otvorených štandardov a interoperability,
  • a zároveň umožní integráciu na národné a nadrezortné informačné systémy (napr. eZdravie, NCZI, zdravotné poisťovne).

Pri výbere riešenia bola osobitná pozornosť venovaná technologickým trendom, ako je modularita, cloudové technológie, mikroslužby, štandardizácia rozhraní (REST API, HL7, XML, a iné EHR štandardy) a využitie architektúr podporujúcich DevOps a CI/CD prístup.

Alternatívy boli hodnotené nielen z pohľadu technického riešenia, ale aj z hľadiska ich vplyvu na prevádzku, bezpečnosť, rozpočtové nároky, možnosť integrácie a súladu s legislatívou Slovenskej republiky. Výsledky tejto analýzy sú uvedené v nasledujúcich podkapitolách. Pri návrhu cieľového riešenia v aplikačnej vrstve boli zvažované nasledovné alternatívy, pričom každá z nich bola hodnotená z pohľadu flexibility, škálovateľnosti, interoperability, bezpečnosti a dlhodobej udržateľnosti:

Alternatíva A: Monolitický nemocničný informačný systém

• Charakteristika: Jednotný, centrálne inštalovaný systém so všetkými funkciami integrovanými do jedného aplikačného jadra.

• Výhody:
  • Nižšia náročnosť na integráciu komponentov.
  • Jednoduchší deployment a správa v malej inštalácii.

• Nevýhody:
  • Nízka flexibilita pri rozširovaní funkčnosti.
  • Riziko technologického dlhu – zmena jedného modulu môže vyžadovať zásahy do celého systému.
  • Obmedzené možnosti prevádzky v hybridnom alebo cloudovom prostredí.

• Záver: Nevhodná pre rozsah a požiadavky FN Nitra – nespĺňa princípy modularity, škálovateľnosti a procesnej flexibility.

Alternatíva B: Modularizovaný systém s lokálnou inštaláciou

• Charakteristika: Systém rozdelený do samostatných modulov, ktoré sú lokálne nasadené a prevádzkované v prostredí nemocnice.

• Výhody:
  • Vyššia flexibilita ako pri monolite.
  • Možnosť selektívneho nasadzovania a upgradovania jednotlivých modulov.

• Nevýhody:
  • Zložitá správa a koordinácia aktualizácií v prostredí s viacerými modulmi.
  • Vyššie náklady na prevádzku a správu infraštruktúry.
  • Riziká bezpečnosti a škálovania pri vysokom zaťažení.

• Záver: Čiastočne vhodná, ale limitovaná z pohľadu budúcnosti a cloudovej pripravenosti.

Alternatíva C (zvolená): Modulárna mikroslužbová architektúra s cloudovým modelom nasadenia

• Charakteristika: Systém pozostávajúci z autonómnych mikroslužieb, nasadený v prostredí, ktoré podporuje cloudovú prevádzku a škálovanie podľa potreby.

• Výhody:
  • Vysoká modularita – každý komponent môže byť samostatne vyvíjaný, testovaný, aktualizovaný a nasadzovaný.
  • Podpora škálovania na úrovni služby (napr. ambulantné plánovanie, urgent, EHR...).
  • Pripravenosť na hybridný cloud alebo full-cloud model.
  • Bezpečnostné a integračné štandardy (REST API, audit, šifrovanie).
  • Možnosť prevádzky ako multitenant riešenie.

• Nevýhody:
  • Vyššie nároky na návrh, DevOps a orchestráciu služieb (napr. Kubernetes, CI/CD).
  • Potreba komplexného monitoringu a logovania.

• Záver: Táto alternatíva bola zvolená ako najvhodnejšia, keďže najlepšie spĺňa požiadavky moderného zdravotníckeho prostredia. Plne reflektuje potrebu digitalizácie procesov, bezpečnosti a škálovateľnosti v rámci FN Nitra a jej dlhodobej stratégie.

Náhľad biznisovej architektúry preferovanej alternatívy:

3.11Stanovenie alternatív v technologickej vrstve architektúry

Súčasťou návrhu riešenia Nemocničného informačného systému (NIS) bola aj analýza alternatív v technologickej vrstve architektúry. Cieľom bolo stanoviť najvhodnejší technologický základ pre prevádzku nemocničného informačného systému s dôrazom na spoľahlivosť, škálovateľnosť, bezpečnosť, podporu vysokého výkonu a súlad s princípmi efektívneho verejného IT.

Technologická vrstva architektúry sa v tomto prípade týka:

• spôsobu prevádzky systému (on-premise vs. cloud),
• použitých databázových technológií,
• riešení vysokodostupnostnej infraštruktúry,
• komunikačných rozhraní a štandardov,
• monitoringu a zabezpečenia.

Boli posudzované nasledovné alternatívy:

Alternatíva A: On-premise infraštruktúra s centralizovaným HW

• Charakteristika: Prevádzka celého systému na fyzickej infraštruktúre nemocnice v serverovej miestnosti alebo vlastnom dátovom centre.

• Výhody:
  • Priama kontrola nad infraštruktúrou.
  • Nezávislosť od externého poskytovateľa cloudových služieb.

• Nevýhody:
  • Vysoké investičné náklady na nákup, rozšírenie, obnovu hardvéru a cyber security.
  • Náročná údržba a prevádzka (nutnosť IT personálu, patch management, zálohovanie).
  • Obmedzená škálovateľnosť a nižšia dostupnosť v prípade výpadkov.

• Záver: Nevhodná pre rozsiahle a kritické systémy s požiadavkami na 24/7 prevádzku a flexibilitu.

Alternatíva B: Hybridný model – on-premise + privátny cloud

• Charakteristika: Časť systému beží v lokálnom prostredí nemocnice (napr. vyrovnávacia cache, rýchle dátové toky), kým core komponenty nemocničného informačného systému sú prevádzkované v privátnom cloude.

• Výhody:
  • Možnosť optimalizácie výkonu a nákladov.
  • Väčšia bezpečnostná kontrola ako pri verejnom cloude.
  • Znížené investičné náklady v porovnaní s plným on-premise modelom.

• Nevýhody:
  • Vyššia komplexita architektúry (správa dvoch prostredí).
  • Potreba robustného sieťového prepojenia.

• Záver: Viabilná možnosť, najmä ak má nemocnica vlastné dátové kapacity a partnera pre prevádzku privátneho cloudu.

Alternatíva C (zvolená): Prevádzka nemocničného informačného systému v bezpečnom cloudovom prostredí (IaaS/PaaS)

• Charakteristika: Celý nemocničný informačný systém beží v cloudovom prostredí certifikovaného poskytovateľa s podporou prevádzky podľa legislatívnych požiadaviek verejnej správy.

• Výhody:
  • Vysoká dostupnosť a škálovateľnosť (auto-scaling, geo-redundancia).
  • Flexibilita pri rozvoji – nové moduly, aktualizácie a CI/CD procesy.
  • Bezpečnostné štandardy – šifrovanie dát, auditovateľnosť, podpora SLA.
  • Optimalizácia nákladov podľa reálneho výkonu (pay-as-you-go).
  • Podpora multitenant architektúry.

• Použité technológie:
  • Prevádzka kontajnerizovaných služieb (Docker, Kubernetes).
  • Databázy SQL aj NoSQL podľa potreby modulu.
  • Monitoring a logovanie (napr. Prometheus, Grafana, ELK).

• Nevýhody:
  • Potreba právneho a technického zabezpečenia prevádzky v zmysle GDPR a zákona č. 95/2019 Z. z.

• Záver: Táto alternatíva bola zvolená ako cieľová, pretože najviac reflektuje požiadavky projektu – škálovateľnosť, bezpečnosť, modernú architektúru a minimalizáciu prevádzkových rizík.

Náhľad technologickej architektúry preferovanej alternatívy:

4.POŽADOVANÉ VÝSTUPY (PRODUKT PROJEKTU)

• Manažment pacienta:
  • Centrálna databáza pacientov (MPI)
  • Identifikácia a evidencia pacienta
  • Ambulantné plánovanie, čakáreň, vyvolávací systém

•  

• Zdravotná starostlivosť:
  • Ambulantná a lôžková zdravotná starostlivosť
  • Podpora pre plávajúce lôžka (okrem štandardného modelu), plánovanie hospitalizácií
  • Intenzívna medicína a urgentná starostlivosť
  • Operačné sály, plánovanie operácií
  • Gynekológia a pôrodníctvo
  • Ošetrovateľská starostlivosť
  • Rehabilitácia
• Podporné a prevádzkové moduly:
  • Preskripcia, príprava a podanie liekov
  • Správa liekovej politiky
  • Integrácie na LIS, rádiológiu, krvnú banku
  • Sklady, žiadanky, súhlasy
  • Notifikácie a eZdravie

•  

• Administratíva a výkazníctvo:
  • Výkazy pre zdravotné poisťovne
  • Štatistiky, reporting

•  

  B. Architektúra a technologická platforma produktu

  Produkt bude realizovaný ako:

• Modulárne riešenie s mikroslužbovou architektúrou
• Cloud-native systém s podporou kontajnerizácie (Docker, Kubernetes)
• Štruktúrované dátové úložisko pacientskych dát (EHR)
• Moderné webové používateľské rozhranie s kontextovou navigáciou a UX prístupom

•  

  Zabezpečí sa interoperabilita s ostatnými systémami a infraštruktúrou nemocnice aj externými systémami:

• eZdravie (NCZI), zdravotné poisťovne
• Interné systémy nemocnice: laboratórium, ústavná lekáreň, krvná banka, rádiológia
• Zdravotnícke prístroje (napr. cez HL7, XML)

•  

  C. Bezpečnosť a súlad s legislatívou

  Produkt bude:

• V súlade s GDPR (zákon č. 18/2018 Z. z.), zákonom o kybernetickej bezpečnosti (č. 69/2018 Z. z.), zákonom o zdravotnej starostlivosti (č. 576/2004 Z. z.) a zákonom o IT vo verejnej správe (č. 95/2019 Z. z.).
• Obsahovať bezpečnostné opatrenia: audit, prístupové práva, šifrovanie dát.
• Podporovať vysokú dostupnosť, zálohovanie a obnovu prevádzky.

•  

  D. Prínosy a pridaná hodnota

  Požadovaný produkt umožní:

• Zabezpečiť neprerušené poskytovanie zdravotnej starostlivosti po ukončení podpory pôvodného systému.
• Zvýšiť efektivitu a znížiť administratívnu záťaž zdravotníckeho personálu vďaka procesne riadenému systému a automatizácii úloh.
• Zvýšiť bezpečnosť a kvalitu starostlivosti vďaka centralizovaným a aktuálnym údajom o pacientovi.
• Zabezpečiť štandardizáciu a štruktúrovanosť dokumentácie a tým podporiť interoperabilitu a sekundárne využitie údajov (napr. pre výskum, kontrolu kvality, projekt EHDS).

5.NÁHĽAD ARCHITEKTÚRY

• Navrhovaná architektúra riešenia predstavuje viacvrstvový, modulárny a škálovateľný systém, ktorý reflektuje moderné trendy v oblasti nemocničných informačných systémov (NIS) a plne zohľadňuje požiadavky na digitalizáciu zdravotníctva, interoperabilitu, bezpečnosť a súlad s národnými aj európskymi štandardmi.

  Architektúra je navrhnutá ako kombinácia mikroslužbovej aplikačnej vrstvy, dátovej vrstvy s podporou štruktúrovanej zdravotnej dokumentácie a infraštruktúrnej vrstvy postavenej na cloudovej platforme s vysokou dostupnosťou a škálovateľnosťou.

  A. Viacvrstvová architektúra riešenia

• Prezentačná vrstva (UI/UX)
  • Moderné webové používateľské rozhranie, prístupné z rôznych zariadení.
  • Kontextová navigácia podľa role používateľa (lekár, sestra, atď.)
  • Multiplatformová kompatibilita (desktop, tablet, mobil).

•  

• Aplikačná vrstva (mikroslužby / BPM)
  • Modularizované komponenty ako samostatné služby (napr. modul urgentu, plánovania, EHR, MPI atď.)
  • Orchestrácie a koordinácia cez BPM engine – modelovanie a vykonávanie klinických a podporných procesov.
  • Asynchrónna komunikácia medzi službami (napr. pomocou event bus / message broker).
  • API brána (API Gateway) s autentifikáciou, autorizáciou a routingom požiadaviek.

•  

• Dátová vrstva
  • Elektronická zdravotná dokumentácia (EHR) – štruktúrovaná, auditovateľná.
  • Podpora SQL aj NoSQL databáz, podľa charakteru uložených údajov.
  • Dôraz na štandardy HL7, HL7 FHIR, XML, DASTA a iné EHR štandardy pre interoperabilitu.

•  

• Integrácia a interoperabilita
  • Integračná platforma/nástroj umožňujúci napojenie na:
    • Národné systémy (eZdravie, zdravotné poisťovne),
    • Lokálne systémy nemocnice (laboratórium, rádiológia, ústavná lekáreň, krvná banka),
    • Zdravotnícke prístroje (napr. HL7-based integrácia).
  • Podpora štandardizovaných rozhraní (REST API, SOAP, HL7 v2/v3 FHIR).

•  

• Infraštruktúrna vrstva (cloud-native)
  • Prevádzka v bezpečnom cloude (privátny/štátny cloud).
  • Kontajnerizácia aplikácií pomocou Docker, orchestrácia cez Kubernetes.
  • Automatizácia nasadzovania a monitorovania (CI/CD, DevOps nástroje).
  • Monitoring (napr. Prometheus, Grafana), audit a logovanie (napr. ELK Stack).
  • Podpora vysokej dostupnosti a geo-redundancie.
  •  
  • B. Architektonické princípy riešenia
• Modularita – každý aplikačný komponent je samostatne nasaditeľný a rozšíriteľný.
• Škálovateľnosť – horizontálne aj vertikálne škálovanie podľa výkonových potrieb.
• Bezpečnosť – implementácia autentifikácie (napr. OAuth2, OpenID Connect), šifrovanie dát (napr. TLS, at-rest), auditovateľnosť prístupov.
• Multitenantná architektúra – možnosť logického oddelenia prevádzky (napr. medzi oddeleniami alebo organizačnými jednotkami).
• Procesne riadený systém (BPM) – všetky úlohy generované podľa definovaného procesu s podporou sledovania stavu a výstupov.

•  

  C. Podpora štandardov a kompatibility

  Architektúra je plne kompatibilná so štandardmi pre eHealth a podporuje:

• HL7, HL7 FHIR, XML, DASTA, a iné EHR štandardy
• ICD-10
• ISO 13606 pre štruktúrované záznamy
• GDPR a zákon č. 69/2018 Z. z. (kybernetická bezpečnosť)

D. Grafický náhľad

Grafický pohľad na architektúru riešenia:

Základný pohľad na proces poskytovania ambulantnej starostlivosti:

Základný pohľad na proces poskytovania lôžkovej starostlivosti

5.1Prehľad e-Government komponentov

Ak bude vytváraný aj výstup I-03 Prístup k projektu, môže byť táto kapitola z dokumentu I-02 Projektový zámer vypustená, pretože jej obsah bude spracovaný vo výstupe I-03 Prístup k projektu.
Obsah tejto kapitoly je prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs). Objednávateľ⁵ plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom centrálneho metainformačného systému verejnej správy (MetaIS) bezodkladne podľa § 12 ods. 1 písm. b) zákona 95/2019 Z.z.
V okamihu odovzdania výstupu I-02 Projektový zámer objednávateľ:

1. vytvorí náhľady architektúry v modelovacom nástroji, ktorý môže byť buď integrovaný na spoločný repozitár  architektonických modelov verejnej správy, alebo ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov,
2. uloží architektonické modely súčasnej a budúcej architektúry riešenia buď do repozitára architektonických modelov verejnej správy alebo do projektovej dokumentácie I-02 ako prílohu  vo výmennom formáte pre uloženie modelu, 
3. aktualizuje v MetaIS e-Government komponenty, ktoré budú realizované alebo menené projektom alebo veľkou zmenovou požiadavkou a to koncové služby, ISVS, ich moduly, aplikačné služby, atribúty a vzájomné vzťahy týchto e-Government komponentov a ich vzťahy (integrácie) na spoločné ISVS alebo ISVS iných správcov, ktoré budú využívať. 
   Objednávateľ v tejto kapitole uvedie prehľad nasledovných e-Government komponentov, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré evidoval v rámci výstupu M-06 v MetaIS:

5.1.1Prehľad koncových služieb – budúci stav:

5.1.2Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav:

5.1.3Prehľad budovaných aplikačných služieb – budúci stav:

5.1.5Aplikačné služby na integráciu

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 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 CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
• 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.

  AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)

5.1.6Poskytovanie údajov z ISVS do IS CSRÚ

Uveďte v tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

5.1.7Konzumovanie údajov z IS CSRÚ

Uveďte v tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

5.1.8Prehľad plánovaného využívania infraštruktúrnych služieb (cloudových služieb) – budúci stav:

Zaevidujte MetaIS využívanie cloudových 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, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

6.LEGISLATÍVA

Projekt nevyžaduje žiadne legislatívne zmeny ani úpravy

7.ROZPOČET A PRÍNOSY

Rozpočet bol stanovaný na základe CP predloženej na MZ SR. V nasledujúcej tabuľke sú uvedené súhrnné náklady v horizonte 10 rokov:

Z pohľadu samotnej implementácie sa jedná o nasledovné náklady:

• 013 SW - 2 159 138 € s DPH z čoho je:
  • SW a lincencie - 1 371 151 €
  • Implementačné práce - 787 987

Prevádzkové náklady boli stanovené na cca  263 664 € ročne z čoho sú:

• prevádzka NIS - 215 914 €
• cloud prevádzka - 36 000 €
• podpora pre nakúpený HW - 11 750 €

Kvantifikácia prínosov

Kvantifikovať prínosy projektu vo finančnom vyjadrení je irelevantné, nakoľko nemocničný IS je základným predpokladom fungovania nemocnice bez ktorého je v súčasnosti prevádzka nemocnice a zdravotná starostlivosť nerealizovateľná. Napriek tomu boli stanovené predpokladané prínosy vyplývajúce z implementácia nového NIS a to nasledovne:

Celkové prínosy predstavujú cca 570 tis. € ročne. V nasledujúcej tabuľke je vyhodnotenie nákladov a prínosov riešenia:

Definovanie kvalitatívnych prínosov

Preto definujeme hlavne kvalitatívne prínosy nového NIS:

• Zamedzenie ohrozenia poskytovania zdravotnej starostlivosti z dôvodu nefunkčnosti zastaraného IS s ukončenou podporou prevádzkovateľa
• Výrazné zlepšenie kvality riadenia procesov pri poskytovaní zdravotnej starostlivosti
• Zníženie duplicít v evidencii a spracovaní zdravotníckych dát
• Zníženie administrácie a chybovosti údajov
• Zlepšenie systému plánovania ZS, objednávania pacientov, preskripcie liekov
• Nový systém objednávania a výdaja liekov a zdravotníckeho materiálu s prepojením na IS lekárne

• Skvalitnenie výkazníctva pre zdravotné poisťovne a NCZI
• Prepojenie na eZdravie (v rozsahu eRecept, eVyšetrenie, eOčkovanie, eDPN, eID, HoN)
• Podpora štruktúrovanej dokumentácie a zavedenie jednotnej semántiky pre klinické dáta, podpora medzinárodných štandardov ako je SNOMED, LOINC atď.
• Možnosť automatických exportov z databázy pre rôzne prehľady, štatistiky, možnosť exportu údajov do iných systémov (napr. ekonomického informačného systému)
• Transparentné sledovanie nákladov, výnosov z hľadiska medicínskych výkonov a cash flow

• Modularita, škálovateľnosť, multitenantná architektúra, procesne riadený systém
• Zvýšenie kyberbezpečnosti - implementácia autentifikácie (napr. OAuth2, OpenID Connect), šifrovanie dát (napr. TLS, at-rest), auditovateľnosť prístupov
• Cloudové riešenie, ktoré umožní optimalizáciu nákladov na hardware
• Perspektíva dlhodobej udržateľnosti systému (predpoklad min. 15 rokov) a jeho rozvoj

8.HARMONOGRAM JEDNOTLIVÝCH FÁZ PROJEKTU a METÓDA JEHO RIADENIA

Projekt bude mať jeden Inkrement s predpokladaným termínom ukončenia do 12/2025 . Projekt bude riadený metódou Waterfall.

9.PROJEKTOVÝ TÍM

9.1 PRACOVNÉ NÁPLNE

10.ODKAZY

Doplniť odkazy na už existujúce produkty v maximálnej miere – vyhnúť sa duplikovaným informáciám.

11.PRÍLOHY

Príloha : Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html
Poznámka: Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti

• Podľa § 4 odsek 10 – Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné zrealizovať pripomienkovanie Projektového zámeru odbornou verejnosťou
• Odporúčame túto aktivitu formalizovať (do dokumentu)
• Odporúčame vyhodnotenie zverejniť na webové sídlo objednávateľa (do projektového adresára) – v súlade s Vyhláškou 401/2023 Zz. Oznámenie o začatí verejného pripomienkovania sa zverejní v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia. Na schválenie riadiacemu výboru v prípravnej a iniciačnej fáze sa tieto výstupy predkladajú až po zverejnení vyhodnotenia pripomienok.
  Koniec dokumentu
  1 Notácia ArchiMate: https://publications.opengroup.org/standards/archimate
  2 Aktuálny spoločný repozitár architektonických modelov verejnej správy je https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
  3 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  4 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  5 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
  6 Spoločné moduly podľa zákona č. 305/2013 e-Governmente
  7 EUPL licencie: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf