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

Výstup do viacerých jazykov nie je potrebný.

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

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)

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

• Na informáciu sú v nasledujúcich diagramoch vzory modelovania integrácie na nadrezortné a spoločné moduly podľa § 10 zákona 305/2013 Zz podľa usmernenia v Používateľskej príručke MetaIS. Vo vašom finálnom dokumente tieto vzory vymažte a nahraďte svojím diagramom ilustrujúcim plánované integrácie:
  
  Obrázok 5 Integrácie na spoločné moduly ÚPVS – ref. príklad
  
  Obrázok 6 Integrácie na IS CAMP- referenčný príklad
  
  Obrázok 7 Integrácie na IS CSRÚ – ref. príklad
  
   

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ú

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.2Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Pre budované informačné systémy vytvorte tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom.

• Úlohou doménového modelu je vizuálne znázorniť rozsah predmetných údajov daného projektu, pričom je možné abstrahovať od nepodstatných detailov. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk),
• V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
• Doménový model by mal byť v súlade s existujúcim Centrálnym modelom údajov verejnej správy (viac informácií na: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/interoperabilita/ a https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.).
• Pre modelovanie doménového modelu je potrebné stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v novom modeli použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML (pre zjednodušený doménový model môžete použiť aj jazyk ArchiMate).
• V prípade, že sa používa dátový prvok z Centrálneho dátového modelu je nutné použiť skrátenú formu URI identifikátora daného prvku, napr. pper:PhysicalPerson je skrátený tvar https://data.gov.sk/def/ontology/physical-person/PhysicalPerson

4.3.3Referenčné údaje

V národnej koncepcii informatizácie verejnej správy bol zadefinovaný princíp „jedenkrát a dosť“, ku ktorému boli ďalej detailnejšie rozpracované úlohy v dokumente Strategická priorita Manažment údajov. Cieľom je dosiahnutie stavu, kedy orgány verejnej moci pri poskytovaní svojich služieb odstránia povinnosti občanov alebo podnikateľských subjektov predkladať údaje vo forme rôznych výpisov, odpisov, potvrdení, atď., ktorými už disponuje verejná správa v rámci svojich registrov.
Za účelom dosiahnutia TO BE stavu, z ktorého bude benefitovať občan / podnikateľský subjekt úsporou svojho času a prostriedkov, je potrebné popísať viacero nasledujúcich krokov na úrovni participujúcich subjektov verejnej správy:

• Popísať, aká je aktuálna kvalita údajov v zdrojových registroch,
• Uviesť dôvod vyhlásenia referenčných údajov (údaje musia byť k subjektu evidencie jedinečné a k týmto údajom je podľa osobitných predpisov uvedená domnienka správnosti),
• Uviesť poskytovateľov a konzumentov (vlastníkov) údajov do centrálnej platformy dátovej integrácie (modulu procesnej integrácie a integrácie údajov slúžiacim pre výmenu údajov pri výkone verejnej moci elektronicky),
• Popísať legislatívu a procesy vo verejnej správe (konkrétnej životnej situácie), pre konkrétne údaje identifikované v projekte (odstránenie legislatívnych povinností predkladať úradom výpisy a potvrdenia a automatizácia procesov viažucich sa k životným situáciám a interakcie s občanom / podnikateľským subjektom).

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

V tejto časti dokumentu je potrebné definovať/popísať rozsah a štruktúru na úrovni registrov / objektov evidencie / údajov, ktoré sa navrhujú vyhlásiť za referenčné v naviazanosti na ich zrealizovateľné vzájomné zdieľanie medzi subjektami verejnej správy a dodržanie pravidla, že za referenčné údaje/atribúty sú vyhlasované také údaje/atribúty, ktoré sú k subjektu evidencie jedinečné a práve tie, ktoré využívajú subjekty verejnej správy pri realizácii princípu „1 x a dosť“.

• Popísať a zdôvodniť navrhované objekty evidencie k vyhláseniu za referenčné z pohľadu ich dátovej kvality v zmysle podkapitoly venujúce sa kvalite a čisteniu údajov,
• Popísať, ako bude zabezpečená dostupnosť poskytovania navrhovaných objektov evidencie za referenčné (t.j. v rámci nich údaje/atribúty) cez Modul procesnej integrácie a integrácie údajov, t.j. integráciou cez jeho dátovú časť - IS CSRÚ,
• Uviesť časový harmonogram procesu vyhlasovania a zmeny referenčných údajov. Informácie o procese vyhlasovania a zmeny referenčných údajov sú uvedené v metodickom usmernení MIRRI o postupe zaraďovania referenčných údajov do zoznamu referenčných údajov vo väzbe na referenčné registre a vykonávania postupov pri referencovaní: https://metais.vicepremier.gov.sk/confluence/download/attachments/2621442/Metodicke_usmernenie_UPVII_3639_2019_oDK_1_FINAL.pdf?version=1&modificationDate=1554714761337&api=v2
• V nasledujúcej tabuľke uveďte návrh na vyhlásenie a zmeny referenčných údajov, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

Identifikujte a uveďte v nasledujúcej tabuľke potenciálnych konzumentov objektov evidencie, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu, vrátane ich oprávnenosti/nároku na konzumovanie v zmysle konkrétnych ustanovení osobitných právnych predpisov na strane konzumenta, prípadne aj na strane poskytovateľa. V nadväznosti na uvedené identifikujte osobitné právne predpisy (až na úroveň konkrétneho ustanovenia), ktoré je nutné novelizovať v záujme dosiahnutia TO BE stavu využitia údajov a jeho bezproblémovej aplikovateľnosti.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:
Poznámka: Pre úspešné napojenie ISVS na IS CSRÚ v roli konzumenta údajov je nutné postupovať podľa integračného manuálu IS CSRÚ.

4.3.4Kvalita a čistenie údajov

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

Zhodnoťte objekty evidencie so zameraním sa na významnosť kvality údajov pre biznis procesy (možné riziká v dôsledku dátovej nekvality), t.j. ak bude údaj nepresný, bude mať nesprávnu hodnotu, formát, nebude vyplnený, alebo stotožnený voči referenčnému registru, ako významne to ovplyvní príslušnú agendu:

• uveďte, či a ako bude zapracovaná možnosť overenia hodnoty údaja,
• uveďte, či bude zapracované pri zadávaní údajov obmedzenie hodnôt, napríklad formou číselníka, alebo podmienok,
• uveďte, či budú dáta migrované z iného ISVS.
  V nasledujúcej tabuľke vyhodnoťte významnosť a citlivosť kvality údajov a prioritu (poradie dôležitosti) pre meranie dátovej kvality objektov evidencií – t.j. poradie, v akom bude správca ISVS približne realizovať meranie dátovej kvality a čistiť údaje. Prvé 2 záznamy sú vyplnené ako príklad. Vymažte, resp. prepíšte ich vlastnými údajmi. Riadky v tabuľke doplňte podľa potreby.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

V nasledujúcej tabuľke definujte potrebné kapacity pre zabezpečenie riadenia dátovej kvality – napr. dátový kurátor, data steward, dátový špecialista pre dátovú kvalitu, databázový špecialista, projektový manažér a pod. (informácie k téme: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/datova-kvalita/ )

4.3.5Otvorené údaje

V nasledujúcej tabuľke doplňte objekty evidencie, ktoré budú realizáciou projektu sprístupnené ako otvorené údaje. Uveďte názov objektu evidencie (identifikované v kapitole dátový rozsah projektu) pre kategóriu otvorených údajov a stanoviť úroveň požadovanej kvality (interoperability) otvorených údajov. Pravidlá pre úroveň interoperability verejných otvorených údajov sú stanovené v https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=23986518.
Požadovaná kvalita:

• Automatizované publikovanie otvorených údajov v kvalite 3★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk). Formát CSV, XML, ODS, JSON
• Automatizované publikovanie otvorených údajov v kvalite 4★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON
• Automatizované publikovanie otvorených údajov v kvalite 5★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.6Analytické údaje

Analytické údaje predstavujú obrovskú skupinu dát získavaných vysokou rýchlosťou z vysokého počtu rôznych typov zdrojov. V priestore verejnej správy sa jedná o dátové zdroje, ktoré sú vytvárané a spravované jednotlivými organizáciami za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Tieto údaje môžeme okrem uvedenej primárnej funkcie využiť aj na analytické spracovanie, tak aby verejná správa dokázala využívať svoje údaje pre potreby prípravy analýz, na podporu rozhodovania, riadenia a lepší návrh politík. Podmienkou pre plné využitie potenciálu údajov vo verejnej správe je ich poznanie (informácie o dátových zdrojoch, ich obsahu a atribútoch) a zabezpečenie prístupu k analytickým údajom pre analytické jednotky.  
V nasledujúcej tabuľke uveďte, ktoré objekty evidencie budú projektom pripravené na analytické účely a sprístupňované pre analytické jednotky (napr. pre systém Konsolidovaná Analytická Vrstva – KAV: https://data.gov.sk/id/egov/isvs/9655 ).
Informácie k sprístupneniu dátových zdrojov organizácie na analytické účely: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/analyticke-udaje/

4.3.7Moje údaje

V tejto časti je potrebné uviesť informácie súvisiace s údajmi, ktoré spadajú do kategórie mojich údajov, z pohľadu budúceho TO BE stavu projektu. Za moje údaje sa považujú najmä: 

• množina údajov o konaní, ktoré sa týkajú fyzickej osoby alebo právnickej osoby 
• množina údajov, vrátane osobných údajov, viažucich sa k fyzickej osobe alebo právnickej osobe ako ku subjektu evidencie, ktoré sú predmetom evidovania povinným subjektom, 
• množina údajov obsiahnutých v návrhu na začatie konania, žalobe, rozhodnutí, žiadosti, sťažnosti, vyjadrení, stanovisku a ohlásení alebo inom dokumente, ktorý vydáva v konaní povinný subjekt, viažuci sa ku konkrétnej fyzickej osobe alebo právnickej osobe.
  Relevantné údaje budú sprístupnené prostredníctvom modulu procesnej integrácie a integrácie údajov - modul Manažmentu osobných údajov pre dotknuté osoby (občanov a podnikateľov) na základe preukázania elektronickej identity osoby. Podmienkou je zabezpečiť, aby údaje identifikované pre službu moje údaje boli prístupné elektronicky v strojovo-spracovateľnom formáte automatizovaným spôsobom cez aplikačné programovacie rozhranie, alebo prostredníctvom modulu procesnej integrácie a integrácie údajov.
  Informácie k sprístupneniu dátových zdrojov organizácie pre službu moje údaje:
  https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/moje-udaje/ .
  Minimálny rozsah pre vyhlásenie dátových prvkov za moje údaje, ktoré musí žiadateľ v projekte zabezpečiť: 
• označenie povinného subjektu, 
• názov ISVS v ktorom je dátový prvok obsiahnutý, 
• kód informačného systému, v ktorom je dátový prvok obsiahnutý, podľa centrálneho metainformačného systému, 
• označenie dátového prvku, 
• strojovo-spracovateľný formát dátového prvku, 
• technickú špecifikáciu aplikačného programovacieho rozhrania, 
• ďalšie doplňujúce informácie. 
• transparentný pohľad na prístup k údajom subjektu, k logom (kto pristupoval k údajom, za akým účelom a kedy). 
  V prípade, že predkladateľ projektu disponuje údajmi, ktoré spadajú do kategórie mojich údajov, je potrebné vyplniť nasledovnú tabuľku. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

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

Vyplňte nasledujúcu súhrnnú tabuľku pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

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

Doplniť požiadavky na projektové personálne zabezpečenie (projektové role a ich obsadenie).
Doplniť rámcové požiadavky na obsadenie TO BE procesu.
Doplniť požiadavky potrebných školení a certifikátov.

9.Implementácia a preberanie výstupov projektu

Posúďte a doplňte spôsoby realizácie projektu a ich dopad na harmonogram projektu a preberanie výstupov pripravovaného projektu.
V zmysle Vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou waterfall, metódou agile alebo metódou waterfall s prvkami metódy agile.
V zmysle vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

• Inkrement musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenia do produkcie. Je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu a každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu, alebo pokračovať ďalším inkrementom.
• Ak realizačná fáza veľkých projektov pozostáva z dodania jedného funkčného celku alebo dodania výlučne technických prostriedkov, objednávateľ v produkte PI-03 Prístup k projektu a v M-05 Analýza nákladov a prínosov - BC/CBA, posúdi a vyhodnotí aj alternatívy rozdelenia na inkrementy na preukázanie ekonomickej nevýhodnosti alebo technických obmedzení rozdeliť projekt na inkrementy.

10.Prílohy

V prípade potreby doplňte zoznam príloh 
Poznámka: odporúčame, aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom súbore formátu EXCEL – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.
Inštrukcie k verejnému pripomienkovaniu:

• Podľa §4 ods. 10 vyhlášky č. 401/2023 Z.z je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou, zaevidovať a vyhodnotiť pripomienky odbornej verejnosti.
• Oznámenie o začatí verejného pripomienkovania zverejniť v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia.
• Dať na schválenie riadiacemu výboru výstupy po zverejnení vyhodnotenia pripomienok.
• Vyhodnotenie zverejniť na webovom sídle objednávateľa (do projektového adresára).
  1 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ť.
  2 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 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0
  4 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  5 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  6 Správca ISVS je povinný zaviesť v organizácii systém riadenia informačnej (a kybernetickej) bezpečnosti a vypracovať bezpečnostný projekt pre ISVS podľa vyhlášky Ú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)
  Strana 23/23