PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03
podľa vyhlášky MIRRI č. 401/2023 Z. z.

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.
 

2.1Použité skratky a pojmy

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

3.Popis navrhovaného riešenia

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.

Hlavné prínosy riešenia
• Zabezpečenie kontinuity prevádzky po ukončení podpory Xanta.
• Zvýšenie efektivity v oblasti zdravotnej dokumentácie, výkazníctva a liečby.
• Zníženie rizika výpadkov a nesúladu s legislatívou.
• Lepšia dostupnosť a kvalita dát pre lekárov, manažment aj NCZI.
• Zníženie záťaže zdravotníckeho personálu vďaka intuitívnemu rozhraniu.

4.Architektúra riešenia projektu

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ť)

4.1Biznis vrstva

4.1.2Jazyková podpora a lokalizácia

Požaduje sa prevedenie v slovenskom jazyku 

4.2Aplikačná vrstva

• 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.

Moduly NIS:

• 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

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

Uveďte dotknuté ISVS a ich moduly AS IS:

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

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

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

Uveďte informácie o využívaných, resp. nevyužívaných nadrezortných ISVS (Spoločných ISVS a spoločných blokov SaaS) – AS IS stav. Všetky realizované integrácie na nadrezortné ISVS v AS IS stave musia byť evidované v MetaIS.

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

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

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

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

Uveďte v nasledujúcej tabuľke prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb inf. systémov tretích strán v TO BE stave.
Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS .

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

Uveďte v nasledujúcej tabuľke budované aplikačné služby, realizáciu koncových služieb aplikačnou službou, koncová služba by mala byť realizovaná aspoň jednou aplikačnou službou (KS môžu realizovať aj viaceré aplikačné služby). Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS.

4.2.7Aplikačné služby na integráciu – TO BE

V rámci projektu sa nebudujú aplikačné služby na integrácie
 

4.2.8Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

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

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Uveďte v nasledujúcej 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Ú.

4.3Dátová vrstva

Dátová vrstva predstavuje základnú infraštruktúru pre uchovávanie, správu a výmenu dát v rámci nemocničného informačného systému. Je navrhnutá tak, aby zabezpečovala spoľahlivé, bezpečné a rýchle spracovanie zdravotníckych a administratívnych údajov.

Kľúčové charakteristiky dátovej vrstvy:

• Centralizované úložisko pacientskych údajov – všetky informácie o pacientoch, ich zdravotnom stave, vyšetreniach a hospitalizáciách sú uložené v centralizovanej databáze.
• Štruktúrované aj neštruktúrované dáta – systém pracuje s formulármi, číselníkmi a šablónami (napr. anamnézy, správy), ako aj s dokumentmi vo formáte PDF či obrazovými prílohami (napr. snímky z PACS).
• Podpora dátovej integrity a verziovania – každá úprava záznamu je auditovaná, verzovaná a spätne dohľadateľná v súlade s požiadavkami ZKB a GDPR.
• Prepojenie s externými systémami – výmena dát prebieha cez štandardizované rozhrania (napr. HL7, DASTA, CDA) s laboratórnymi systémami (LIS), zobrazovacími systémami (PACS), systémom eZdravie a účtovnými/ekonomickými IS.
• Bezpečnosť a zálohovanie – prístup k dátam je riadený na úrovni rolí, údajové toky sú šifrované a zálohy sa vykonávajú podľa plánovanej stratégie obnovy.

Dátová vrstva systému je navrhnutá s dôrazom na legislatívnu zhodu, výkonnosť, škálovateľnosť a bezpečnosť, pričom je úzko previazaná s aplikačnými komponentmi, ktoré ju napĺňajú a čítajú. Vytvára spoľahlivý základ pre rozhodovanie, prevádzku aj externú komunikáciu so štátom a partnermi.

4.3.1 Údaje v správe organizácie

Údaje, ktoré organizácia spravuje sú definované v súlade s zákonom:

• Zákon č. 576/2004 Z. z. o zdravotnej starostlivosti § 19 a nasl. – Zdravotná dokumentácia:
  • definuje, čo všetko má obsahovať zdravotná dokumentácia pacienta,
  • určuje, kto ju vedie, v akom rozsahu a v akej forme (elektronicky/písomne),
  • stanovuje povinnosť uchovávať údaje o diagnózach, vyšetreniach, liekoch, výkonných záznamoch, prepúšťacích správach atď.
• Zákon č. 578/2004 Z. z. o poskytovateľoch zdravotnej starostlivosti
  • Upravuje povinnosti poskytovateľov pri vedení zdravotnej dokumentácie.
  • Záväzok nemocnice mať systém, ktorý umožňuje prístup, spracovanie a archiváciu zdravotných údajov.
• Zákon č. 153/2013 Z. z. o Národnom zdravotníckom informačnom systéme (NZIS)
  • Upravuje obsah a rozsah dát, ktoré sa majú odosielať do eZdravia a NCZI.
  • Zavádza povinnosť uchovávať a poskytovať údaje ako:
    • eRecepty,

• • • eŽiadanky,
    • výkony (HD dávky),
    • hospitalizačné prípady,
    • štatistické prehľady.
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov (GDPR)
  • Vymedzuje osobné a citlivé zdravotné údaje ako osobitnú kategóriu.
  • Stanovuje:
    • zásady uchovávania údajov,
    • časové obmedzenia uchovávania,
    • práva pacientov (prístup, oprava, výmaz),
    • povinnosti nemocnice ako prevádzkovateľa dát.
• Vyhláška MZ SR č. 98/2011 Z. z. o vedení zdravotnej dokumentácie
  • Presne špecifikuje obsah jednotlivých typov zdravotných záznamov:
    • ambulantný záznam, prepúšťacia správa, konzílium, chirurgický záznam, pôrodný list, laboratórny výsledok atď.
  • Uvádza minimálny rozsah údajov, ktoré musia byť v dokumentácii vedené.
• Zákon č. 395/2002 Z. z. o archívoch a registratúrach
  • Stanovuje archivačné lehoty zdravotnej dokumentácie:
    • napr. prepúšťacie správy: 20 rokov, laboratórne výsledky: 10 rokov, RTG: 10 rokov.
  • Určuje, akým spôsobom sa má zdravotná dokumentácia ukladať a likvidovať.

4.3.2 Dátový rozsah projektu

V nasledujúcej tabuľke sú uvedené údaje, ktoré sú predmetom projektu:

Tabuľka č.11 Prehľad objektov evidencie v jednotlivých ISVS/registroch  súvisiace s projektom – budúci stav

Na nasledujúcej schéme je zobrazený dátový model:

       Obrázok 6 Zjednodušený doménový model - príklad

4.3.3 Kvalita a čistenie údajov

4.3.3.1 Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Tabuľka č.12 Kategorizácia objektov evidencie z pohľadu dátovej kvality – budúci stav

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

Projekt predpokladá nasledovné činnosti pri zabezpečovaní kvality údajov

Tabuľka č.13 Prehľad rolí a personálneho zabezpečenia pre riadenie dátovej kvality 

4.3.4 Referenčné údaje

Projekt nevytvára referenčné údaje

4.3.5 Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

Projekt nevytvára referenčné údaje

Tabuľka č.14 Prehľad identifikovaných referenčných údajov – budúci stav

4.3.6 Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU

Projekt neposkytuje ani nekonzumuje údaje z IS CSRU

Tabuľka č.15 Prehľad konzumovaných/poskytovaných referenčných údajov – budúci stav

4.3.7 Otvorené údaje

Projekt neprodukuje otvorené údaje

Tabuľka č.16 Prehľad otvorených údajov – budúci stav

4.3.8 Analytické údaje

Projekt negeneruje analytické údaje pre verejnosť, len pre interné účely

Tabuľka č.17 Prehľad sprístupnených dátových zdrojov určených na analytické účely – budúci stav

4.3.9 Moje údaje

Projekt negeneruje údaje pre platformu Moje údaje. Údaje sú posielané do NZIS

Tabuľka č.18 Prehľad údajov identifikovaných pre službu „moje údaje“ – budúci stav

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

Irelevantné

Tabuľka č.19 Kategorizácia údajov z pohľadu ich využiteľnosti (účelu)  - budúci stav

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

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

4.4.2Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Doplňte pre TO BE stav do nasledujúcej tabuľky 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, …).

4.4.3Návrh riešenia technologickej architektúry

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

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

• Vývojové – určené pre vývoj systému
• Testovacie – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgrade‑ov (nie pre záťažové testovanie).
• Produkčné – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie
  Poznámky:
  Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.
  V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.
  V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

4.5Bezpečnostná architektúra

Navrhované riešenie musí byť v súlade s dotknutými právnymi normami 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á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
• 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
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
legialtí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.
Keďže v projekte dôjde k spracovaniu osobných údajov, bude posúdený vplyv spracovateľských operácii na
ochranu osobných údajov (DPIA (Data Protection Impact Assessment) ešte pred začatím spracúvania osobných
údajov.
Pričom bude posúdený kontext v zmysle nasledovných právnych predpisov:
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri
spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES
(všeobecné nariadenie o ochrane údajov),
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov,
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri
posudzovaní vplyvu na ochranu osobných údajov

5.Závislosti na ostatné ISVS / projekty

Uveďte sumárny prehľad všetkých projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá.
Uveďte ako záujmové osoby (stakeholder) organizačné jednotky verejnej správy zodpovedné za poskytnutie potrebnej súčinnosti pre pripravovaný projekt.

6.Zdrojové kódy

Súčasťou dodávky budú aj zdrojové kódy k vytvorenému riešeniu resp. dielo bude dodané pod verejnou open
source softvérovou licenciou Európskej únie (EUPL, pokiaľ to nevylučujú licenčné podmienky tretích osôb vo
vzťahu k štandardným Softvérovým produktom, s komentármi a technickým popisom, a to pre prevádzkové a
testovacie verzie počítačových programov, a práva na ich zverejnenie v centrálnom repozitári zdrojových kódov
podľa § 15 ods. 2 písm. d) Zákona o informačných technológiách vo verejnej správe a § 31 vyhlášky Úradu
podpredsedu vlády Slovenskej republiky pre investície a informatizáciu o štandardoch pre informačné technológie
verejnej správy č. 78/2020 Z. z., a iného predpisu, ktorý môže v budúcnosti vyhlášku č. 78/2020 Z. z. nahradiť
alebo doplniť.
V prípade údajov vygenerovaných prostredníctvom učenia umelej inteligencie budú tieto údaje vo OPEN formáte
a budú mať licenciu EULP. Vlastníkom údajov bude prevádzkovateľ systémov v zdravotníctve.7.Prevádzka a údržba

Prevádzka riešenia bude zabezpečené v dvoch základných oblastiach:
• Prevádzka infraštruktúry
• Prevádzka SW riešenia
Pričom tieto prevádzkované oblasti musia mať zabezpečené také SLA aby bolo možné splniť nasledovné
komplexné požiadavky na prevádzku systému ako celku.

7.1Prevádzkové požiadavky

1. Dodávateľ je povinný poskytovať objednávateľovi komplexnú servisnú podporu na dielo  v minimálnom rozsahu stanovenom touto zmluvou a v rozsahu servisnej podpory, ktorá je pre daný typ diela obvyklá, a to vrátane aktualizácii, upgradu, konzultácií, odstraňovania a riešenia chýb, havarijných stavov, porúch a incidentov tak, aby bol zabezpečený spoľahlivý chod nemocničného systému.
2. Za poruchy, havárie, chyby a incidenty sa rozumejú najmä také skutočnosti, ktoré znemožňujú, obmedzujú, komplikujú alebo iným spôsobom negatívne ovplyvňujú prevádzku diela.
3. Dodávateľ sa zaväzuje poskytovať objednávateľovi servisnú podporu po dobu 4 rokov odo dňa protokolárneho prevzatia a odovzdania diela bez vád.
4. V rámci servisnej podpory dodávateľ garantuje objednávateľovi najmä:
5. riešenie a odstránenie chýb, porúch a havarijných stavov, incidentov,
6. servis a podporu programového vybavenia,
7. aktualizáciu a modernizáciu diela a jeho udržiavanie v súlade s právnymi predpismi, vyhláškami, nariadeniami alebo príkazmi zo strany MZ SR, ÚDZS alebo NCZI,
8. aktualizácie zahŕňajúce dodávku nových verzií programov, ktorých potreba vznikne na základe legislatívnych zmien právnych predpisov, vyhlášok, nariadení alebo príkazov zo strany MZ SR, ÚDZS alebo NCZI;
9. aktualizáciu, resp. dodávku nových verzií programov, ktorých potreba vznikne na základe požiadaviek zdravotných poisťovní, bez splnenia ktorých by objednávateľ neobdržal úhradu od niektorej zo zdravotných poisťovní, ku každej aktualizovanej aj dielčej verzii programového vybavenia (update) dodá aj dokumentáciu, ktorá obsahuje technický aj užívateľský popis zmien;
10. v prípade prechodu na vyššiu verziu programového vybavenia (upgrade) obdrží Objednávateľ úplnú užívateľskú dokumentáciu programového vybavenia tvoriaceho novú verziu. Ak bola užívateľská dokumentácia prepracovaná, je Objednávateľovi odovzdaná aktualizácia príslušných príručiek;
11. služby technickej a systémovej integrácie,
12. konzultácie a poskytovanie podpory k prevádzkovým programom,
13. poskytovanie ďalších služieb a tovarov, ktoré súvisia s údržbou, rozvojom, rozšírením, prevádzkou diela alebo ďalším spracovaním dát diela sa uskutoční na základe písomnej objednávky Objednávateľa..

7.1.1Úrovne podpory používateľov

Help Desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

• 1. Stupeň- Havarijný: kritické a akútne komplikácie, ktoré znemožňujú alebo významne obmedzujú používanie diela, ovplyvňujú celú prevádzku a systémy objednávateľa, dielo nie je použiteľné vo svojich základných funkciách. Pri takýchto problémoch objednávateľ nemôže využívať dielo, neexistuje postup pre náhradné riešenie problému použitím bežných postupov v kompetencii objednávateľa. Tieto komplikácie je dodávateľ povinný riešiť ihneď (prioritne) po ich nahlásení objednávateľom, maximálne však s reakčnou dobou do 4 hodín a s dobou odstránenia havarijného stavu maximálne do 24 hodín;
• 2. Stupeň- Urgentný: prevádzkové komplikácie, ktoré komplikujú postupy pri práci v rámci diela avšak nie sú kritické, významné alebo akútne, prejavujú sa v nezhode ovládania či výstupov, činnosť diela je degradovaná. Tieto komplikácie je dodávateľ povinný riešiť po ich nahlásení objednávateľom v lehote s reakčnou dobou do 24 hodín a s dobou odstránenia urgentného stavu maximálne do 48 hodín.
• 3. Stupeň- Štandardné: požiadavka o informáciu alebo konzultáciu a pod., ktoré je dodávateľ povinný riešiť po ich nahlásení v lehote s reakčnou dobou do 5 dní a s dobou vyriešenia do 10 dní.

7.1.2Rieš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:

• 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.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (Availability)

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

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd
  Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:
• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective) - aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove
  Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:
• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok
  V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa. Potom je potrebné mať vhodným spôsobom ošetrenú úroveň dostupnosti, ktorú musí dodávateľ dodržať. Zvyčajne je dostupnosť súčasťou dohody o úrovni poskytovaných služieb (SLA).

7.2.2RTO (Recovery Time Objective)

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.
Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút
• Synchrónny replikácie dát - nulový výpadok

7.2.3RPO (Recovery Point Objective)

Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.
Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút, strata sa blíži k nule
• Synchrónny replikácie dát - nulová strata

8.Požiadavky na personál

Uvedené v rámci Projktového zámeru

9.Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov bude v súlade s vyhláškou 401/2023 a bude definovaný v rámci zmluvy o dodávke diela

10.Prílohy

N/A