I-03 Prístup k projektu (Nemocničný informačný systém)

Naposledy upravil Peter Ďuriš 2025/07/21 15:50

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

Povinná osobaFakultná nemocnica Nitra
Názov projektuNemocničný informačný systém
Zodpovedná osoba za projektVedenie FN Nitra
Realizátor projektuFakultná nemocnica Nitra
Vlastník projektu Fakultná nemocnica Nitra
Schvaľovanie dokumentu
PoložkaMeno a priezviskoOrganizáciaPracovná pozíciaDátum

Podpis
(alebo elektronický súhlas)

VypracovalIng.Martin JuhásFN NitraPrevádzkový námestník01.03.2025 

1.História dokumentu

VerziaDátumZmenyMeno
0.101.02.2025Pracovný návrh 
1.001.03.2025Zapracovanie súladu s vyhláškou č. 401/2023 Z. z. 
    
    

2.Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. o riadení projektov - je dokument Prístup k projektu pre prípravnú fázu určený na rozpracovanie informácií k projektu z pohľadu aktuálneho stavu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, alokovaní rozpočtu, ľudských zdrojov a prechode do iniciačnej fázy.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má o.i popisovať riešenie projektu v oblastiach:

  • Požiadaviek na architektúru  riešenia – biznis vrstva, aplikačná vrstva, technologická vrstva, ...
  • Požiadaviek na dátový model, dátové konverzie a migrácie
  • Požiadaviek na vládny cloud, prípadne zdôvodnenie jeho použitia
  • Kapacitných požiadaviek na HW, SW a licencie
  • Požiadaviek na bezpečnosť riešenia
  • Požiadaviek  na testovanie a akceptačné kritéria
  • Požiadaviek  na prevádzku, výkonnosť, dostupnosť a zálohovanie
  • Požiadaviek na integrácie, rozhrania a spoločné komponenty
  • Požiadaviek na dokumentáciu a školenia.

2.1Použité skratky a pojmy

SKRATKA/POJEMPOPIS
 FNFakultná nemocnica
 ZSZdravotná starostlivosť
 NISNemocničný informačný systém
 KBKybernetická bezpečnosť
 SWSoftware
 HWHardware
 MIRIMinisterstvo investícií, regionálneho rozvoja a informatizácie SR
 MZMinisterstvo zdravotníctva
 VOVerejné obstarávanie
  

 

3.Popis navrhovaného riešenia

Navrhované riešenie predstavuje moderný nemocničný informačný systém, ktorý nahradí pôvodný systém Xanta s ukončenou podporou k 31. 3. 2025. Systém bude implementovaný vo FN NT ako lokálne, rýchlo nasaditeľné a plnohodnotné riešenie, pričom bude koncipovaný tak, aby mohol byť neskôr začlenený do centrálneho systému nemocnice.

Technická a funkčná charakteristika riešenia

  • Prevádzka nemocničného informačného systému v bezpečnom cloudovom prostredí (IaaS/PaaS)
  • Modulárna aplikačná architektúra – systém bude pozostávať z kľúčových komponentov ako:
    • Pacient / registrácia
    • Zdravotná dokumentácia
    • Ošetrovateľská starostlivosť
    • ePreskripcia a eZdravie
    • Výkazníctvo a BI
    • Správa používateľov a prístupov
  • Podpora legislatívy – riešenie bude kompatibilné so systémami NCZI, eZdravie, DRG a ZKB.
  • Interoperabilita – integrácia s LIS, PACS a ekonomickým systémom nemocnice.

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.

Princípy návrhu riešenia

  • Rýchla implementácia (do 12 mesiacov).
  • Bezpečnosť a auditovateľnosť údajov v súlade s národnými štandardmi.
  • Zameranie na používateľa – ergonomické prostredie, školenia a podpora.

Väzba na biznis potreby

Systém priamo podporuje všetky hlavné biznis služby nemocnice – od ambulantnej a lôžkovej starostlivosti, cez výkazníctvo, až po manažérsky reporting. Je navrhnutý tak, aby reflektoval potreby koncových používateľov (lekárov, sestier, administratívy) a zároveň bol udržateľný z pohľadu IT správy a financovania.

Riešenie predstavuje strategický krok k stabilizácii a modernizácii nemocničnej IT infraštruktúry. Umožňuje nemocnici zvládnuť akútnu situáciu po ukončení podpory Xanta a zároveň vytvára predpoklady pre budúcu konsolidáciu informačných systémov v rámci celej nemocnice.

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

Na nasledujúcej schéme je koncepčná biznis architektúra navrhovaného riešenia.

1753103263562-690.png

4.1.2Jazyková podpora a lokalizácia

Požaduje sa prevedenie v slovenskom jazyku 

4.2Aplikačná vrstva

Na nasledujúcej schéme je rámcová aplikačná architektúra systému:

Realizácia kompletného diela je vyžadovaná do 12 mesiacov od účinnosti zmluvy.

Popis komponentov a požiadaviek na aplikačnú architektúru

  1. Migrácia dát a okolie
  • Požadujeme migráciu údajov z doterajšieho Nemocničného informačného systém XANTA minimálne v rozsahu kompletných medicínskych údajov o všetkých pacientoch;
  1. Systémové požiadavky
  • Požadujeme, aby centrálna serverová infraštruktúra bola  prevádzkovaná v cloudovom prostredí;
  • NIS musí byť multitenantný aby bola zabezpečená nezávislá prevádzka zariadení/pracovísk v rámci  clustera
  • Súčasťou dodávky sú aj všetky potrebné SW licencie pre centrálne produkčné prostredie (rutinná prevádzka), testovacie prostredie a zálohovací priestor;
  • NIS musí byť na klientovi prevádzkovaný v 32 resp. 64 bitovom operačnom systéme Windows v internetovom prehliadači ako webová aplikácia
  • Predpokladaný počet užívateľov dodávaného riešenia je minimálne ,
  • Objednávateľ požaduje aktívne školenie systému na PC s vyskúšaním všetkých potrebných funkčností v rozsahu používateľských činností pre oblasť činnosti — NIS (lôžka, ambulancie, COS a.i.)
  • Vstupné údaje pre zabezpečenie školení: Počet lekárov 350, požadovaný min. počet na zaškolenie 500, Počet sestier cca 800, požadovaný počet min. 60% (všetky vrchné sestry, staničné sestry, ambulantné sestry, case manažéri, sestry na oddeleniach), administratívni zamestnanci(odhadovaný počet 20). Správcovské školenie pre správu a nastavovanie parametrov systému - min. 6 pracovníkov
  • Požadujeme dodávku riešenia s dobou nábehu do rutinnej prevádzky do 9 mesiacov od podpisu zmluvy
  • Servisná podpora bude poskytovaná minimálne 48 mesiacov od začiatku prevádzky,
  • Dostupnosť NIS musí byť minimálne 99%
  • Servisná podpora pre aplikačné SW prvky musí obsahovať včasnú legislatívnu kompatibilitu riešenia a odstraňovanie chýb
  • NIS musí umožňovať prístup k dátam cez dátové rozhrania, ktoré umožňuje analytikovi nemocnice  pristupovať k dátam a následne ich analyzovať
  • Systém musí umožniť jedinečnosť prístupových kódov a hesiel s kryptovanými heslami;
  • Systém musí mať možnosť voliteľnej Windows autentifikácie cez active directory do NIS pre jednotlivých používateľov;
  • Súčasťou dodávky sú aj všetky potrebné licencie na prevádzku NIS a databáz a ostatné podporné aplikácie.
  1. Všeobecné požiadavky na NIS
  • NIS musí poskytovať intuitívne užívateľské rozhranie pre používateľov;
  • NIS musí centralizovať zdravotnú dokumentáciu v rámci nemocnice na pacienta
  • NIS musí vytvoriť každému pacientovi centrálnu "Kartu pacienta" a do nej ukladať všetky zdravotné záznamy. Chronologicky kumulovať prehľad o záznamoch v dokumentácií a realizovaných službách a aktivitách.
  • NIS musí ukladať výsledky diagnostiky v štruktúrovanej podobne v karte pacienta a zároveň sú doplnené v definovanom rozsahu podľa odbornosti do ambulantnej správy, prípadne dekurzu.
  • NIS musí umožniť zobrazovať pacientske dáta na časovej osi
  • NIS musí umožniť grafické zobrazenie dekurzu kontinuálne počas celého pobytu pacienta a vizualizácia jednotlivých súvislosti
  • NIS zápis musí umožniť čítať historické pacientske dáta aj zapisovať pacientske dáta na jednej obrazovke spolu s možnosťou ich jednoduchého prenosu
  • NIS musí umožniť zavedenie medzinárodných dátových štandardov
  • NIS umožniť prostredníctvom nástroja, podporu štruktúrovanej dokumentácie a zavedenie jednotnej semántiky pre klinické dáta napriek všetkými odbornosťami a podporu medzinárodných štandardov ako je SNOMED, LOINC atď.
  • Priradzovať relevantnú medicínsku techniku, z ktorej sa preberajú údaje do pacientskej dokumentácie (informácie o prevádzke, dávkach liekov, časoch, žiarení, ...).  V systéme bude definovaná väzba medzi výkonom a prístrojom potrebným na tento výkon.
  • NIS musí mať používateľské rozhranie v slovenskom jazyku
  • NIS musí na komunikáciu s eZdravie používať požadované funkcionality, služby a rozhrania minimálne v rozsahu eRecept, eVyšetrenie, eOčkovanie, eDPN, eID, HoN
  • 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,
  • NIS musí umožniť automatickú aktualizáciu aplikačných programov NIS pri 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ť 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 bude postavený na riešeniach od 1 autora pre moduly zahŕňajúce ambulantnú a lôžkovú starostlivosť, zobrazovacie metódy, Laboratóriá, sklady/medzisklady liekov a zdravotného materiálu na oddeleniach a vyúčtovania do zdravotných poisťovní, okrem modulov, ktoré odberateľ nechce meniť;
  • 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              
  • 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);
  • NIS musí umožniť priradenia/preddefinovania štruktúrovaných formulárov (prípadne šablón tlačív) pre jednotlivé úlohy v rámci workflow procesu;
  • NIS musí umožniť plánovať zdravotnú starostlivosť a služby súvisiace s poskytnutím zdravotnej starostlivosti plánovať ako celok cez štruktúrované šablóny dynamických formulárov. Pre formuláre je možné definovať pravidlá pre obmedzenie obsahu ako napríklad povinné polia, formát a rozsah údajov a ich početnosti ako napríklad kódy pacienta, zadávateľa, aktivít a požadovaných personálnych, materiálnych a priestorových zdrojov s predpokladanou kvantitou a časovou náročnosťou;
  • NIS musí umožniť generovať úlohy podľa definície aktivít služby pre určené zdroje;
  • NIS musí umožniť jednoduché potvrdenia realizácie aktivity/úlohy/intervencie;
  • NIS musí umožniť Zdravotníckym zamestnancom, najmä lekárom a sestrám je na základe plánu pracovných zmien vygenerovať osobný kalendár na všetky pracovné smeny v danom mesiaci. Na základe aktivít v medicínskom procese  je následne generovaný zoznam úloh ako sú sesterské intervencie napríklad podanie liekov vrátane záznamov do dokumentácie;
  1. Register pacientov
  • Vyhľadávanie (vyhľadanie pacienta podľa zadaných kritérií)
  • Registrácia pacienta (zavedenie nového pacienta do registra)
  • Úprava (editácia údajov pacientov)
  • Generovanie náhradného RČ (pokiaľ nie je známe rodné číslo)
  • Zlúčenie pacientov (napr. v prípade stotožnenia neznámeho pacienta)
  • Preloženie relevantnej časti údajov z jedného pacienta na druhého (v prípade nesprávnej identifikácie pacienta)
  • Overenie príslušnosti k ZP a platnosti poistenia pomocou webových služieb
  • Možnosť poslania ePN do Sociálnej poisťovne
  1. Požiadavky pre lôžkové oddelenia
  • NIS musí umožniť procesne riadiť prevádzku lôžkového oddelenia vzhľadom na odbornosť a výkon
  • NIS musí umožniť zobraziť stav jednotlivých hospitalizácií a umožniť prácu s hospitalizáciou podľa procesu;
  • NIS musí umožniť spracovanie kompletnej lekárskej a ošetrovateľskej dokumentácie pre oddelenia;
  • NIS musí umožniť odoslanie prepúšťacej správy do NZISu;
  • NIS musí umožniť spracovanie administratívnej agendy pre oddelenia;
  • NIS musí umožniť prístup do záznamov ambulantnej a hospitalizačnej starostlivosti pacienta zadaných v minulosti  pre sledovanie histórie liečby pacienta, podľa stupňa ich dôvernosti a prístupových práv používateľov;
  • Možnosť zdieľania zdravotnej dokumentácie pacientov medzi jednotlivými oddeleniami na základe nastavenia prístupových práv;
  • Možnosť príjmu pacienta na hospitalizáciu priamo na oddelení alebo v prijímacej kancelárii;
  • Príjem pacienta na hospitalizáciu musí obsahovať všetky údaje potrebné pre evidenciu v NIS a pre vytvorenie hospitalizačného prípadu v systéme DRG
  • Možnosť urgentného príjmu pacienta len so základnými údajmi o ňom s následnou možnosťou doplnenia údajov neskôr
  • Údaje zadané počas hospitalizácie musia obsiahnuť všetky potrebné údaje pre vykazovanie v režime DRG a pre štatistiku NCZI.
  • Možnosť časovo obmedzeného dopísania dokumentácie po preložení či prepustení pacienta;
  • Možnosť zablokovania úprav v dokumentácii po uzavretí prípadu kóderom
  • Možnosť vytvárania a používania preddefinovaných textov v zdravotnej dokumentácii;
  • Možnosť skopírovania lekárskych záznamov z predchádzajúcich hospitalizácií/návštev;
  • Možnosť automatického presunu RTG nálezu do prepúšťacej správy.
  • Možnosť zostavenia prijímacej správy z jednotlivých záznamov;
  • Podpora automatizovaného zostavenia záverečnej (prepúšťacej ) správy z jednotlivých zápisov a výsledkov (podľa vlastného výberu, vrátane SVaLZ výsledkov), s možnosťou ďalšieho formátovania textu
  • Možnosť vytvorenia predbežnej prepúšťacej správy
  • Možnosť zaslania elektronických žiadaniek na vyšetrenie (laboratórne, diagnostické, rehabilitačné, na patológiu, zobrazovacie metódy, na konziliárne vyšetrenie, a pod.) 
  • Možnosť prehliadania a ukladania výsledkov vyšetrení z iných ambulancií a oddelení do zdravotnej dokumentácie;
  • Možnosť zápisu výsledkov laboratórnych vyšetrení do zdravotnej dokumentácie;
  • Možnosť evidencie ordinácie diét;
  • Možnosť štruktúrovanej preskripcie liekov;
  • Možnosť zostavenia záznamu o terapii z preskripcie liekov počas hospitalizácie;
  • Možnosť prevziať zdravotnú dokumentáciu pri preklade pacienta na iné oddelenie;
  • Možnosť nastavenia stupňa dôvernosti ku konkrétnemu lekárskemu záznamu;
  • Možnosť vytvorenia lokálneho číselníka odosielajúcich lekárov pre jednotlivé oddelenia;
  • NIS musí umožniť plánovať hospitalizácie pacientov s väzbou na reálny príjem pacientov;
  • NIS musí umožniť evidovať schválenie hospitalizácie pacientov v poisťovni s väzbou na reálny príjem pacientov;
  • Prehľad plánovaných a schválených hospitalizácií;
  • NIS vyžaduje zadať diagnózu pri príjme pacienta kvôli eliminácii chýb vo vykazovaní;
  • NIS musí umožniť evidenciu ošetrovateľských záznamov jednoduchým spôsobom;
  • NIS obsahuje funkcionalitu Hospicomu, eHospik s automatickým vytváraním dávok pre odoslanie do ZP;
  • NIS umožňuje vytvárať čakacie listiny podľa metodiky MZ SR
  • NIS umožňuje prehľady hospitalizácií podľa rôznych kritérií;
  • NIS umožňuje kontroly dávok na oddeleniach pred odoslaním na centrálne spracovanie;
  • NIS musí umožniť preskripciu liekov a infúzií vrátane automatického prenosu nákupnej ceny do vykazovania pre poisťovne;
  • Prehľad dostatku liečiv na skladoch pre preskripciu;
  • Informácia pri preskripcii o množstve lieku na sklade;
  • Možnosť automatickej ponuky príbuzného lieku podľa ATC pre preskripciu v prípade nedostatku lieku na sklade;
  • NIS musí umožniť evidenciu a preskripciu liekov prinesených z domu;
  • NIS musí umožniť preskripciu liekov na jednorazové podanie;
  • NIS musí umožniť preskripciu liekov podľa potreby;
  • Prehľad požadovaných liekov na dodanie (lekár predpísal liek, ktorý nie je na sklade v zariadení a je ho potrebné objednať od distribútora)   
  • NIS musí umožniť automatický odpis liekov zo skladu po potvrdení podania liekov;
  • Potvrdenie podania liečiv a infúzií individuálne (bezpečné podanie) a hromadne
  • Špeciálny odpis kvapiek a mastí;
  • Možnosť stornovania odpisu liečiv zo skladu;
  • NIS musí umožniť sledovať spotrebu liekov a špeciálneho zdravotníckeho materiálu na pacienta s presnosťou na použitú mernú jednotku;
  • NIS musí obsahovať prevodník alternatívnych merných jednotiek
  • NIS musí umožniť zadefinovať pacientovi infúzie vrátane konkrétnych zložiek
  • NIS musí umožniť sledovať spotrebu liekov a špeciálneho zdravotníckeho materiálu na oddelení;
  • NIS musí umožniť stanovenie špeciálnych merných jednotiek pre lieky a ich prepočet na podanie pre detských pacientov
  • Rozpis podávaných liekov a infúzií podľa termínu podania;
  • Možnosť používať čiarový resp. 2D kód pri príjme a odpise lieku;
  • Možnosť vytvorenia viacerých skladov pre jedno oddelenie;
  • NIS musí umožniť evidenciu liekov a ŠZM v konsignačných skladoch; možnosť viacerých konsignačných skladov v zdravotníckom zariadení
  • Možnosť denného rozpisu cytostatickej liečby pre onkologických pacientov (priame prepojenie so systémom nemocničnej lekárne resp. s možnosťou exportu žiadanky do lekárenského systému) a následná evidencia spotreby v NIS resp. import výdajky na pacienta;
  • Denné prehľady prijatých, preložených, prepustených pacientov;
  • NIS musí umožniť grafické zobrazenie obsadenia izieb a lôžok;
  • Izby a lôžka majú svoje vlastnosti; využitie piktogramov pre jednotlivé vlastnosti izieb a lôžok; ich zobrazenie v celkovom pohľade na lôžkofond a jeho aktuálne obsadenie pacientami;
  • NIS musí umožniť priraďovanie voľných lôžok pacientom (plánovaných a aj neplánovaných z urgentu) s ohľadom na vlastnosti izby a lôžka (napr. nedovoliť umiestniť do ženskej izby muža);
  • NIS musí umožniť preklady pacienta v rámci lôžkofondu oddelenia a celej nemocnice; drag&drop aj klasické ovládanie;
  • NIS musí umožniť rýchle vyhľadanie voľného lôžka;
  • NIS musí umožniť sledovanie lôžkového fondu a obložnosti, vrátane prehľadov o počte hospitalizovaných na jednotlivých oddeleniach a dĺžke hospitalizácie;
  • NIS musí umožniť štruktúru lôžkových oddelení s izbami a posteľami klasicky (podľa oddelení), ako plávajúce lôžka (v štruktúre Klaster – Ošetrovacia jednotka- izba-posteľ) alebo kombinovane;
  • NIS musí umožniť vykazovanie DRG výkonov;
  • NIS musí mať možnosť vybrať pre hospitalizáciu správnu medicínsku službu;
  • Možnosť vytvorenia podmnožiny DRG výkonov pre jednotlivé oddelenia;
  • NIS musí umožniť integráciu existujúceho DRG groupera (toho času od spoločnosti Asseco Central Europe a.s.) do systému tak, aby boli podporované všetky jeho funkcionality;
  • NIS musí umožniť zlúčenie DRG prípadov (podľa metodického usmernenia);
  • NIS musí umožniť kumuláciu priebežných kumulatívnych DRG výkonov;
  • Možnosť „modelovania“ DRG klasifikácie;
  • NIS musí umožniť prehľad prípadov so zobrazením súčtu efektívnych relatívnych váh;
  • NIS musí zabrániť nastaveniu hlavnej diagnózy s nevhodnou etiológiou pre DRG prípad;
  • Možnosť úpravy diagnóz a výkonov v zmysle zvoleného variantu z DRG groupera;
  • NIS musí umožniť vykazovanie špeciálnych pripočítateľných položiek podľa požiadaviek poisťovní;
  • NIS musí umožniť vykazovanie domácich poistencov, bezdomovcov, poistencov EÚ a pacientov mimo EÚ, pacientov na vlastnú úhradu;
  • Možnosť vytvorenia dávky o hospitalizovaných pacientoch pre NCZI vrátane kontroly údajov;
  • Možnosť priebežného sledovania nákladovosti na pacienta;
  • Možnosť nastavenia hranice limitu pre MFNZS pre jednotlivé zdravotné poisťovne a nákladové strediská a upozornenie pri prekročení limitu;
  • Možnosť nastavenia hranice limitu pri objednávaní liekov a ŠZM pre jedno oddelenie a upozornenie pri prekročení limitu;
  • Možnosť zobrazenia aktuálnej celkovej ceny spotreby liekov a ŠZM na pacienta;
  • Možnosť zadefinovať preddefinované skupiny liekov pre danú diagnózu;
  • Možnosť tlačenia žiadanky na transfúziu s evidenciou krvnej skupiny;
  • NIS musí umožniť automatizovať Ošetrovateľský proces;
    • posúdenie zdravotného stavu pacienta (vstupné a prehodnocovacie)
    • vitálne funkcie, skóre včasného varovania
    • priradenie sesterských diagnóz
    • skórovacie škály (Apgarovej skóre, Maddonova škála, VAS NRS, Barthelovej test, RASS škála, Nortonovej škála, Nutrícia MNA, MFS - Morseova stupnica pádov, Aldreteho skórovací systém, GUSS test, MMSE – SMMSE, PAINAID, IADL, SHANNON, Humpty Dumpty škála, FLACC škála a iné)
    • automatické generovanie intervencií
    • úprava plánu intervencií, možnosť doplnenia vlastných intervencií
    • ošetrovateľský plán
    • denný ošetrovateľský proces
    • intervencie – potvrdenie vykonania/nevykonania
    • príprava a potvrdenie podania liekov a infúzií
    • sesterské záznamy (vizity, bilancia tekutín, poznámky k pacientovi)
    • zobrazenie ordinácií od lekára
    • kontrolný protokol bezpečného odovzdania pacienta
    • kontrolný protokol bezpečného prijatia pacienta
    • prehľady o ošetrovateľskom procese
    • vyhodnotenie výsledkov ošetrovateľskej starostlivosti
    • edukácia pacienta resp. jeho doprovodu
    • ošetrovateľská prepúšťacia správa
    • bilancia tekutín pacienta
  • Preklady – malý/veľký preklad;
  • Tlač chorobopisu (jednotlivých častí), tlač štítkov pacienta (rôzne formáty);
  • Priloženie multimediálneho súboru k dokumentácii pacienta;
  • Zobrazenie priloženého multimediálneho súboru v dokumentácii pacienta;
  • Vytvorenie, editácia a tlač Epikrízy pacienta;
  • Predpisovanie Diéty pacienta, evidencia zmien;
  • Prehľady diét, tlač;
  • Vytvorenie a odoslanie Hlásenia o nežiadúcej udalosti
  • Prehľad nežiadúcich udalostí
  • Vytvorenie Hlásenia o Nozokomiálnej nákaze
  • Prehľad hlásenia o Nozokomiálnych nákazách
  • Vytvorenie záznamu o Informovanom súhlase, tlač, prehľad
  • Evidencia použitia Umelej pľúcnej ventilácii
  • Procesný prístupu k niektorým činnostiam – vytvorenie workflowu, sled jednotlivých úloh
  • Zápis preskripcie liekov a infúzií pre hospitalizovaného pacienta lekárom, aj na X dní dopredu
  • Zmena preskripcie liekov a infúzií pre hospitalizovaného pacienta
  • Schválenie preskripcie liekov a infúzií
  • Kopírovanie  preskripcie liekov a infúzií pre pacienta na stanovený počet dní dopredu
  • Možnosť evidencie Liekovej anamnézy pacienta (štruktúrovane)
  • Možnosť vytvorenia preddefinovaného zloženia infúzií
  • Pripojenie dieťaťa k matke, resp. matky k dieťaťu/deťom
  • Novorodenec
  • SOR, SON
  • Hlásenie o narodení
  • Pôrodná kniha
  1. Požiadavky pre COS a operácie
  • NIS musí umožňovať procesné riadenie od plánovania operácií až po priebeh a ukončenie operácie;
  • NIS musí umožniť zobraziť stav jednotlivých operácií a umožniť prácu s operáciou podľa procesu;
  • NIS musí umožňovať plánovanie operácií, JZS a zákrokov na jednotlivých operačných a zákrokových sálach;
  • NIS musí umožňovať plánovanie resp. spustenie urgentných operácií;
  • NIS musí umožňovať plánovanie zdrojov potrebných k operáciám (personál, OP sety, ŠZM, prístroje);
  • NIS musí umožňovať plánovanie operačných výkonov na základe úzkeho číselníka výkonov pre danú odbornosť. Tento číselník má obsahovať predefinované parametre plánovania ako dĺžka trvania operácie, použité zdroje, nástup na hospitalizáciu atď;
  • NIS musí umožňovať súbežne plánovať operáciu s hospitalizáciou a potrebnými predoperačnými vyšetreniami
  • NIS musí umožňovať plánovať operáciu bez určenia operačnej sály
  • NIS musí umožňovať automatické objednávanie operačných setov v  v centrálnej sterilizácií;
  • NIS musí umožňovať automatické objednávanie ŠZM;
  • NIS musí umožňovať schvaľovanie operácii ako aj potrebných zdrojov;
  • NIS musí umožňovať jednoduché usporiadanie operačného programu(poradie operácií, sála dĺžka trvania atď)
  • NIS musí umožňovať viackrokové uzatváranie operačného programu podľa rolí používateľov;
  • NIS musí umožňovať vybraným rolám meniť operačný program po uzatvorení resp. umožniť program opäť otvoriť;
  • NIS musí umožňovať preplánovanie a zrušenie naplánovaných udalostí;
  • NIS musí umožňovať zohľadniť obmedzenie prístupnosti zdrojov (sál mimo prevádzku, nedostupnosť personálu, prístroja atď.)
  • NIS musí umožniť grafické zobrazenie operačného programu, rozlíšené farebne podľa odbornosti, na jednotlivé dni ako aj priebeh a stav operácií v deň ich konania;
  • NIS musí umožniť filtrovať v operačnom programe podľa rôznych kritérií
  • NIS musí umožniť riešenie konfliktov vznikajúcich pri plánovaní;
  • NIS musí umožniť jednoduché vytvorenie operačného a anestéziologického protokolu a ich vzájomnú previazanosť (aby nebolo potrebné do každého protokolu písať tie isté informácie);
  • NIS musí umožňovať zaznamenávať priebeh operácie počas operácie (časové pečiatky, podané lieky, WHO checklist, vitálne funkcie, anestézia, použitý materiál, sety, kontrolný checklist pri ukončení operácie atď);
  • NIS musí umožňovať automatické predvypĺňanie známych informácií;
  • NIS musí umožňovať prístup do dokumentácie pacienta počas operácie na operačnom sále
  • NIS musí mať možnosť evidovať skutočnú prítomnosť jednotlivých členov operačného tímu pri operácii;
  • NIS musí umožniť prenos záznamu o operácii do chorobopisu pacienta;
  • NIS musí umožniť prenos operačného výkonu do vykazovania pre zdravotné poisťovne a vykazovania pre DRG;
  • NIS musí umožniť variabilné prehľady z operačných a anestéziologických protokolov;
  • NIS musí umožniť evidenciu spotrebovaných liekov, ŠZM a zdravotníckeho materiálu na operačných sálach, odpisovať skutočne podanú dávku v merných jednotkách (nie iba celé balenia)
  • NIS musí umožniť preniesť vybrané časti operačného protokolu do prepúšťacej správy alebo ambulantného dekurzu.
  • NIS musí umožniť riadiť a zaznamenať pred anestetickú prípravu na OPPAS
  • NIS musí umožniť riadiť a zaznamenať pooperačná starostlivosť OPPAS
  • NIS musí umožniť tlačiť plán operácií, operačného programu
  • NIS musí umožniť tlačiť operačnú dokumentáciu
  • NIS musí umožniť užívateľom jednoduchý výber druhu operácie podľa stromovej štruktúry definovanej pre každé operačné oddelenie resp. JZS
  • NIS musí umožniť zobrazenie operačného programu na daný deň na obrazovke pred operačnou sálou.
  • NIS musí umožňovať odpis znehodnoteného lieku
  • NIS musí umožňovať priradenie prístroja k pacientovi alebo operačnej sále
  1. Požiadavky pre ambulancie
  • NIS musí umožniť procesne riadiť prevádzku ambulancie vzhľadom na odbornosť a výkon
  • NIS musí umožniť zobraziť stav jednotlivých návštev a umožniť prácu s návštevou podľa procesu;
  • NIS musí umožniť spracovávanie kompletnej lekárskej dokumentácie pre ambulancie; s možnosťou pripojenia multimediálneho súboru;
  • Možnosť zobrazenia aktuálnej ambulantnej správy a dokumentácie pacienta (napr. predchádzajúca návšteva) v rámci jednej pracovnej plochy, s možnosťou kopírovania údajov z dokumentácie pacienta.
  • Možnosť využívania preddefinovaných textov pri práci so zdravotnou dokumentáciou;
  • Možnosť nastavenia dôvernosti ku konkrétnemu lekárskemu záznamu;
  • NIS musí umožniť objednanie návštev pacientov, aj opakovaných a hromadných, na ambulancii aj medzi ambulanciami navzájom;
  • NIS musí umožniť objednanie pacienta na ambulantné vyšetrenie cez centrálne Infocentrum;
  • NIS musí umožniť vyhľadať voľný termín v kalendári podľa rôznych kritérií.
  • NIS musí umožniť spravovať jednotlivé návštevy v kalendári (doplnenie komentárov, preplánovanie návštevy štandardným spôsobom alebo pomocou „drag-and-drop“, zrušenie návštevy).
  • NIS musí umožniť zobraziť časový audit naplánovanej aj uskutočnenej návštevy
  • NIS musí umožniť zobraziť Kalendár s rôznou jemnosťou rastru (slotu) kalendára (po 10, 20, 30 a 60 minútach).
  • NIS musí umožniť listovať v kalendári po dni, týždni, mesiaci alebo presunom na konkrétny deň.
  • NIS musí umožniť filtrovať v kalendári.
  • Možnosť zaslania elektronických žiadaniek na vyšetrenie  (laboratórne, diagnostické, rehabilitačné, na patológiu, zobrazovacie metódy, na konziliárne vyšetrenie a pod.) 
  • Možnosť prehliadania a ukladania výsledkov vyšetrení z iných ambulancií a oddelení do zdrav. dokumentácie podľa nastavenia prístupových práv;
  • Možnosť automatického presunu RTG nálezu do ambulantnej správy.
  • Možnosť zápisu výsledkov laboratórnych vyšetrení do zdravotnej dokumentácie;
  • Možnosť štruktúrovanej preskripcie liekov na recept;
  • Možnosť vystavenia receptov pre opiáty;
  • Musí umožniť vystavenie zdravotnej pomôcky pacientovi;
  • Možnosť automatického vloženia záznamu o vystavení receptov, poukazov na zdrav. pomôcky do zdrav. dokumentácie;
  • NIS musí umožniť prehľad predpísaných liekov a zdravotníckych pomôcok na ambulancii;
  • Možnosť jednoduchého použitia histórie predpísaných liekov pre vystavenie receptu lieku a zdravotnej pomôcky;
  • Možnosť dispenzarizácie pacientov pre účely zdrav. poisťovní;
  • Možnosť dispenzarizácie pacientov pre vlastné účely;
  • Možnosť vykazovania preddefinovaných skupín výkonov vrátane pripočítateľných položiek;
  • Vyúčtovanie ambulantnej návštevy + tlač vyúčtovania s ambulantnou správou
  • Možnosť vykazovania DRG výkonov;
  • Možnosť zaradenia DRG výkonov do preddefinovaných makier výkonov;
  • Možnosť vytvorenia podmnožiny DRG výkonov pre jednotlivé ambulancie;
  • Možnosť priebežnej kontroly zadávaných údajov na duplicitu v rámci dňa;
  • Možnosť obmedziť doplnenie výkonov, za už zúčtované obdobie len pre oprávnené osoby;
  • Možnosť kontroly dávok v ambulanciách pred odoslaním na centrálne spracovanie;
  • Možnosť vytvorenia lokálneho číselníka odosielajúcich lekárov pre jednotlivé ambulancie;
  • Možnosť vykazovania výkonov do Sociálnej poisťovne;
  • NIS musí umožniť vykazovanie domácich poistencov, bezdomovcov, poistencov EÚ a poistencov mimo EÚ a pacientov na vlastnú úhradu;
  • Možnosť vytvorenia a aktualizácie číselníka výkonov pre priamu úhradu pacientami;
  • Možnosť vytvorenia alebo zadania cenníka služieb hotovostných platieb;
  • Možnosť centrálneho vyúčtovania hotovostných platieb pre pacienta z viacerých pracovísk
  • NIS musí umožniť plánovanie a objednávanie procedúr aj hromadné a opakované
  • Možnosť objednania pacienta na iné pracovisko;
  • Možnosť rozosielania notifikácií objednaným pacientom formou mailov a SMS správ;
  • Možnosť online prepojenia webovej aplikácie pre objednanie pacientov;
  • Možnosť webového rozhrania pre lekárov na objednávanie svojich pacientov.
  • Možnosť vystavenia elektronickej žiadanky pre laboratórne vyšetrenie v inom zdravotníckom zariadení (formát DASTA);
  • Možnosť prijať elektronický výsledok z iného ZZ (formát DASTA);
  • Podporiť selfcheck in pacienta po príchode do čakacej zóny. Môže napríklad oskenovať čiarový kód, ktorý dostal na centrálnej recepcii a je evidovaná jeho prítomnosť u prijímacieho pracoviska.
  • Možnosť zobraziť aktuálny stav návštev v ambulancii (žiadanky, plánované, čakáreň, prebiehajúce, ukončené zrušené atď.) v rámci jednej obrazovky s možnosťou tlače.
  • Možnosť zaradenia pacientov do čakárne
  • Možnosť elektronického vyvolania pacientov do ambulancie
  • Sledovať a zobrazovať čakaciu dobu + ďalšie orientačné údaje na vyvolávajúcej tabuli pred prijímajúcim pracoviskom (ambulancie, OT, nukleárna medicína, zobrazovacia diagnostika).
  • Možnosť stanovenia priority vyšetrení
  • Prehľady pre ambulancie o počte ošetrených pacientov, zoznam ošetrených pacientov či počtu ošetrených diagnóz.
  • Možnosť vytvorenia očkovacej schémy aj pre pediatriu
  1. Osobitné požiadavky na urgent             
  • NIS musí umožniť procesne riadiť prevádzku oddelenia urgentnej medicíny
  • NIS musí umožniť zobraziť stav jednotlivých návštev a umožniť prácu s návštevou podľa procesu;
  • NIS musí evidovať pracovisko triážne pracovisko s recepciou urgentného príjmu a ambulanciu vyšetrenia (urgent)
  • Rozdelenie pacientov na Recepcii urgentu a triážnom pracovisku na čakajúcich, vyšetrovaných  a ukončených
  • Pridelenie poradia došlým pacientom
  • NIS musí umožniť vyvolanie na triáž pomocou vyvolávacieho systému (obrazovka)
  • NIS musí obsahovať triážny formulár
  • NIS musí umožniť pridelenie triážneho stupňa pacientovi
  • NIS musí umožniť vyvolanie pacienta pomocou vyvolávacieho systému (obrazovka);
  • NIS musí umožniť poslať pacienta na doplňujúce SVALZové vyšetrenie
  • NIS musí umožniť poslať pacienta na expektačné lôžka v rámci urgentu
  • NIS musí umožniť následnú hospitalizáciu pacienta a presun pacienta na lôžkové oddelenie
  • NIS musí umožniť špeciálny režim „Hromadné nešťastie“ a „FAST TRACK“
  • Štatistické sledovanie časových pečiatok dĺžky čakania a vyšetrovania pacienta
  • NIS musí obsahovať prehľady ošetrených pacientov podľa rôznych filtrov
  1. Osobitné požiadavky pre FRO
  • NIS musí umožniť procesne riadiť prevádzku FRO
  • NIS musí umožniť zobraziť stav jednotlivých návštev/procedúr a umožniť prácu s návštevou/ procedúrou podľa procesu;
  • NIS musí umožniť plánovanie a objednávanie pacientov na procedúry; s možnosťou tlače zoznamu procedúr naplánovaných pre pacienta;
  • NIS musí umožniť plánovanie opakovaných procedúr, viacerých procedúr a hromadných procedúr (viac pacientov naraz v jednej procedúre)
  • NIS musí umožniť príjem pacienta – evidencia pacienta (register pacientov)
  • NIS musí umožniť vystavenie žiadanky na rehabilitáciu
  • NIS musí umožniť Evidenciu rehabilitačného prípadu ambulantného ako aj hospitalizovaného pacienta
  • NIS musí umožniť príjem pacienta do rehabilitačnej starostlivosti
  • NIS musí umožniť definíciu typu procedúr (1 pracovník na 1 pacienta, 1 pracovník pre skupinu pacientov, skupina pacientov muži/ženy/mix, podľa veku a pod.)
  • NIS musí umožniť evidovať záznam z jednotlivých procedúr
  • NIS musí umožniť ukončiť rehabilitačný prípad
  • NIS musí umožniť zobraziť prehľad o rehabilitačnom účte pacienta
  1. Požiadavky pre pracovisko zobrazovacích metód
  • NIS musí umožniť procesne riadiť prevádzku pracovísk zobrazovacích metód
  • NIS musí umožniť zobraziť stav jednotlivých návštev a umožniť prácu s návštevou podľa procesu;
  • NIS musí umožniť elektronickú komunikáciu pracoviska RTG s ostatnými oddeleniami, ambulanciami (príjem žiadaniek, odoslanie nálezov);
  • NIS musí umožniť aj manuálne zadanie žiadanky;
  • Možnosť poskytovať nálezy vo web prostredí registrovaným lekárom;
  • Možnosť popisu snímok s využitím preddefinovaných textov;
  • Nález v systéme musí mať príznak „predbežný“ alebo „konečný“
  • NIS musí umožniť zasielanie pracovných listov pre PACS, vytvoriť elektronickú žiadanku t.j pri prijatí žiadanky generovanie worklistu pre príslušnú modalitu;
  • Možnosť zasielania pracovných listov prostredníctvom štandardu HL7;
  • NIS musí umožniť evidenciu dávok ožiarenia;
  • Musí umožniť zobraziť históriu RTG vyšetrení pacienta;
  • Vyhľadávanie vo všetkých číselníkoch a databáze pacientov, podľa mena, rodného čísla, podľa kódu, podľa názvu;
  • Príjem elektronických žiadaniek na jednotlivé pracoviská podľa modalít;
  • Možnosť vytvoriť „podpracoviská“ ako súčasť oddelenia zobrazovacích metód (napr. RTG1, RTG2, ...)
  • Zabezpečiť rozlišovanie elektronických žiadaniek na žiadanky určené na objednanie a žiadanky na okamžité riešenie rutina – statim;
  • Žiadanka musí obsahovať nasledovné údaje pacienta: priezvisko, meno, rodné číslo, poisťovňu, parametre výšku a váhu, informáciu o žiadateľovi vyšetrenia – oddelenie, ambulancia, lekár, dátum ordinácie, stranové označenie vyšetrenia, názov vyšetrenia, ID hospitalizačného prípadu, Informácie o alergickej anamnéze pacienta, gravidite, laktácii, krátka anamnéza;
  • Žiadanku pri prijatí bude možné preniesť, kopírovať na iné pracovisko/podpracovisko, prípadne vrátiť do zoznamu žiadaniek;
  • Do žiadanky sa musia dať zapísať: kódy vyšetrení a kódy DRG, diagnóza podľa MKCH, nález pacienta, ekonomické údaje (použitý materiál, lieky);
  • Zo žiadanky musí byť prístup do prehľadu predchádzajúcich vyšetrení, nálezov, žurnál ako sa nález menil počas popisu (doplnky, zmeny opravy, časovo);
  • Priradenie žiadanky k určitému definovanému lekárovi, ktorý nález realizuje;
  • Zobrazenie informácie o dostupnosti obrazovej databázy pacienta v PACS systéme pri konkrétnom pacientovi;
  • V rámci IS musí byť integrovaný modul pre objednávanie pacientov,  podľa jednotlivých pracovísk a modalít s možnosťou vytvárať vlastné kalendáre termínov, vrátane definície jednotlivých časových parametrov a limitujúcich obmedzení s možnosťou preniesť pacienta z objednávacieho modulu do zoznamu realizovaných žiadaniek;
  • Štatistika – full textové vyhľadávanie v nálezoch a diagnózach, zostavovanie ekonomických štatistík vykonaných nálezov, požitých materiálov a liekov, vrátane štatistiky DRG výkonov za voliteľné časové obdobie s možnosťou tlače a exportu (*.csv; *.xls);
  • Štatistika ročného výkazu vykonaných vyšetrení podľa metodiky MZSR;
  • Štatistika počtu vyšetrených pacientov podľa jednotlivých pracovísk a poisťovní;
  • Online štatistika vykonaných a objednaných vyšetrení na kontrolu plnenia zmluvných limitov od jednotlivých poisťovní;
  • Online prepojenie so systémom nemocničnej lekárne alebo automatický import a následná aktualizácia materiálového a liekového číselníka z nemocničnej lekárne do RIS minimálne raz za 24hodín;
  • Vzájomné prepojenie RIS  s NIS a s lekárňou;
  • Tlač nálezu s hlavičkou a logom
  • Poskytovanie priebežného obrazu o činnosti personálu oddelenia,  formou štatistiky na zisťovanie vyťažiteľnosti jednotlivých pracovníkov;
  • Možnosť zobrazenia a tlače ambulantnej knihy podľa jednotlivých pracovísk s možnosťou tlače a exportu do (*.csv; *.xls);
  • Opravy dát pacientov v kartotéke,  napr.: zjednotenie pacientov (po identifikácii neznámeho pacienta...);
  •  
  • Kontrola podkladov pre ZP pred odoslaním dávok (kontrola rodných čísiel, duplicitných vyšetrení, pacientov (ak sa budú dávky pre ZP generovať samostatne);
  • Možnosť vykázania spotreby liekov a zdravotníckeho materiálu na pacienta a jeho odpis zo skladu pracoviska
  1. Požiadavky pre laboratórne vyšetrenia
  • NIS musí umožniť spracovanie vzoriek na vlastných analyzátoroch nemocnice;
  • Musí umožňovať vytvorenie elektronickej žiadanky z oddelení a ambulancií a jej prijatie v laboratóriu;
  • Žiadanka musí obsahovať minimálne tieto položky (Číslo žiadanky, Typ žiadanky /Rutina, Statim.../, Dátum príjmu, Čas príjmu, Dátum odberu, Dátum ordinácie, Čas ordinácie, Rodné číslo pacienta, Dátum narodenia, Meno, Priezvisko, Titul, Poisťovňa, Diagnóza, Pohlavie, Štátna príslušnosť, Poistenie, ID hosp. prípadu, Typ pacienta, Spôsob účtovania, Oddelenie, Telefón, Ordinoval, Kód lekára, Kód PZS, Poznámka – týka sa celej žiadanky – prechádza do NIS, Interná poznámka – slúži pre potreby laboratória – neprechádza do NIS, Poznámka z oddelenia – využívajú lekári na oddeleniach na informovanie lab. pracovníkov ohľadom odberu, liečby...,;
  • „Žurnál“ žiadanky – evidencia krokov s danou žiadankou (kto, čo, kedy robil so žiadankou z obsluhujúceho personálu, zmena akýchkoľvek údajov, pričom sa zachová aj info o pôvodnom údaji – čas a meno osoby);
  • Pri prijme žiadanky v laboratóriu upozorniť, že ordinujúci lekár nemá resp. už nemá úväzok na danej ambulancii;
  • Možnosť rušenia „starých“ žiadaniek , ktoré neboli z NIS prebrané (nedodaná vzorka, lekár vyšetrenie zrušil po tom ako žiadanku dopredu vytvoril, pacient už nie je hospitalizovaný, duplicita vytvorených žiadaniek, a.i.);
  • Možnosť prispôsobenia si „obrazovky“ – čo potrebujeme mať priamo zobrazené k výsledkom pacienta (metóda – skratka, názov, medze, jednotky, stav, príchod výsledkov z analyzátora, kto a kedy výsledky potvrdil a.i.);
  • Číselník výkonov, zdravotných poisťovní, diagnóz ( vrátane odborností, frekvencií...);
  • Možnosť nastavenia rôznych cien za bod pre jednotlivé  pracoviská a rôzne RNP. V prípade akýchkoľvek zmien zo strany RNP – aktualizovať v LISe;
  • Možnosť „blokovania“ žiadaniek v dennom súbore  (vyšetrenie vzorky je urobené, no výsledky sa nedajú podpísať (podľa potreby – do vyriešenia problému, nezhody – napr. chýbajú nejaké vstupné údaje pacienta a.i.), samozrejme, že v prípade nutnosti sa telefonicky nahlásia na dané oddelenie;
  • Možnosť doplnenia a doordinovania vyšetrení;
  • Možnosť opravy žiadaniek v archíve (rodné číslo, DGN, odosielateľ, a.i.) s dodržaním pravidiel NZIS eZdravie;
  • Možnosť preposlania výsledku z archívu pacienta na iné oddelenie  (ako bola pôvodne vystavená žiadanka);
  • Možnosť prezerania a jednoduchého vyhľadávania v archíve (podľa mena, rodného čísla), tlač výsledku z archívu;
  • Možnosť podpísať výsledky jednotlivo po metódach, ale aj naraz všetkých na danej žiadanke;
  • Možnosť „dobodovať- dovykazovať “ výkony na žiadanke (v prípade náročnejšieho vyšetrenia je potrebné niekedy dodatočne vykázať výkony na iný deň – vzhľadom na akceptovanú frekvenciu výkonov danej poisťovne);
  • Možnosť editovania výkonov (upraviť, zrušiť, pridať) v opravných dávkach;
  • Možnosť nastaviť rôzne výkony vykazovania pre jednotlivé vyšetrenia pre každú poisťovňu;
  • Možnosť zasielať upozornenie pre klinických lekárov pri indikovaní požadovaných vyšetrení, že prekračujú akceptovanú frekvenciu ordinovania výkonu príp. lekár s ich odbornosťou dané vyšetrenie nemôže ordinovať;
  • LIS musí mať výstup podľa požiadaviek štatistiky MZSR;
  • Možnosť štatistických výstupov – možnosť nastavovať tak, aby bolo možné vybrať obdobie, jednotlivé vyšetrenia, detaily (kódy vyšetrení z „bodovníka“), pre jednotlivé pracoviská;
  • Možnosť štatistických výstupov – štatistika po oddeleniach (tak aby sa dalo zistiť, aké vyšetrenia boli žiadané, za aké obdobie, v akom počte bodov, za akú cenu a pre ktorú ZP (aj pre externých žiadateľov);
  • Možnosť štatistických výstupov – zoznam vydaných krvných prípravkov v TU jednotkách, cene, na rodné číslo, oddelenie resp. ambulancia, a.i.;
  • LIS musí obsahovať a poverenému užívateľovi (správcovi LIS) umožniť nastaviť :
    • metódy
    • vstupné parametre metód
    • poradie metód pre tlač
    • poradie metód pre zobrazenie
    • definovať skupiny metód
    • definovať metódy podľa pracovísk
    • definovať metódy podľa skúmaviek
    • priradenie metód laboratória a NIS
    • štandardné (preddefinované) texty
    • nastavenie pre komunikáciu s prístrojmi
    • označenie jednotlivých staníc viditeľné na monitore (potrebné pre rýchlu orientáciu pri vyskytnutí sa problému na danej stanici)
    • monitorovanie staníc (kto, na ktorej stanici a od kedy je prihlásený)
    • info o aktualizácii - upgrade (dátum, čas) programu na jednotlivých staniciach
    • databáza pracovníkov s potrebou zadefinovania oprávnení (úrovne prístupu) do LIS;
  • Možnosť vyúčtovania pre zdravotné poisťovne – možnosť posielania cez sieť na centrálnu poisťovňu;
  • Možnosť posielania opravných dávok;
  • Musí obsahovať zoznam zariadení, z ktorých sa nakupujú krvné prípravky;
  • Možnosť evidovať paletu krvných skupín;
  • Možnosť definovať fenotypu (výberom alebo na základe čiarového kódu na prípravku);
  • Možnosť evidencie exspirácie prípravku;
  • Možnosť blokovania prípravku, ak je kontraindikovaný (nakrížený) pre určitého pacienta;
  • Možnosť evidovať počet transfúzií (koľko dostal pacient celkovo-sumár aj s tlačou);
  • Možnosť evidovať koľko krížových skúšok, alebo krvných skupín  sa robí za určité obdobie (deň, mesiac) pre určité oddelenie;
  • Možnosť evidovať koľko derivátov dostal pacient počas TX heparu aj s možnosťou tlače
  • Musí umožňovať tlač žiadaniek jednotlivo aj hromadne;
  • Musí umožňovať definovanie zoskupenia vyšetrení;
  • Možnosť identifikácie vzoriek pomocou čiarového kódu;
  • Možnosť zostavenia pracovných listov pre jednotlivé analyzátory, resp. ručné metódy;
  • NIS musí umožniť priradenie ID DRG prípadu ku žiadanke
  • Identifikácia vzorky cez čiarový kód;
  • Príjem žiadanky cez čiarový kód
  • Vyhľadanie žiadanky cez čiarový kód
  • Možnosť identifikácie vzoriek čiarovým kódom;
  • Možnosť zobrazenia histórie vyšetrenia;
  • Možnosť vytvorenia manuálneho pracovného listu;
  • Možnosť priradenia viacerých výkonov k jednej metóde;
  • Možnosť evidencie referenčných medzí s podmienkou (napr. týždeň gravidity)
  • Pripojenie analyzátorov pre pracovisko LAB:
  1. Centrálna prípravovňa liekov
  • Elektronická komunikácia NIS s pracoviskom centrálnej prípravovni liekov (CPL)
  • CPL  má vlastný sklad liekov
  • Rozdelenie preskripcie liekov na lieky pripravené v lokálnom sklade pracoviska a na lieky pripravené v CPL
  • Prehľad  Objednávok - Počet dávok podľa stavu  za deadline a pracovisko    
  • Manuálna príprava balíčka  -  cytostatiká, sterilné lieky, ostatné nesterilné lieky a individuálna príprava liekov
  • Hromadná príprava liekov
  • Predpríprava a možnosť prípravy balíčka v prístroji (robot) – nesterilné lieky (tbl, cps)      
  • Príprava liekov na oddelení
  • Využitie 1D alebo 2D kódov
  • Priradenie balíčkov k vozíku alebo inému prenosovému médiu  – vytvorenie zásielky
  • Priradenie k vozíku
  • Priradenie ku kontajneru vozíka
  • Priradenie ku kapsule  alebo inému prenosovému médiu 
  • Kontrola balíčkov v zásielke
  • Uzavretie zásielky  a odovzdanie na prepravu
  • Riešenie zmien a nezhôd
  1. Požiadavky pre sklady/medzisklady
  • Súčasťou NIS je informačný systém pre evidenciu liekov, ŠZM a zdrav. materiálu na skladoch ambulancií, oddelení, SVaLZ a operačných sál;
  • NIS musí umožniť vedenie skladov liekov, vrátane automatizovanej podpory (objednávanie z nemocničnej lekárne, odpisovanie pri výdaji, inventúry);
  • NIS musí umožniť vytvoriť viacero skladov liekov na pracovisku;
  • NIS musí umožniť evidenciu dátumu exspirácie liekov, šarže, minimálneho a maximálneho potrebného množstva na sklade, kódy ŠUKL, ATC, , ...);
  • Možnosť vygenerovať vlastný kód pre liek alebo zdravotnícky materiál;
  • NIS musí umožniť vytvoriť elektronickú žiadanku z nemocničnej lekárne a načítanie elektronických príjemiek z nemocničnej lekárne;
  • NIS musí umožniť vytvoriť žiadanku na lieky zo zoznamu liekov na sklade pod minimálnym množstvom;
  • Možnosť vystavenia žiadanky o lieky pre konkrétneho pacienta;
  • Možnosť evidovať minimálne a maximálne stavy položiek na jednotlivých skladoch/medziskladoch
  • Možnosť vytvoriť žiadanku na lieky, ŠZM a zdrav. materiálu do nemocničnej lekárne zo zoznamu liekov, ŠZM a zdrav. materiálu na sklade pod minimálnym množstvom
  • NIS musí umožniť evidovať výdajky priamo na pacientov, s automatickou evidenciou pre ZP a odpisom zo skladových zásob;
  • Možnosť prehľadu odpísaných liečiv, krvných prípravkov, infúzií na pacienta za celý pobyt v nemocnici;
  • NIS musí umožniť prevod liekov na iné pracovisko;
  • Možnosť vrátenia výdajok z nemocničnej lekárne
  • NIS musí umožniť vykonávanie inventúr na skladoch oddelení k určitému dňu;
  • NIS musí umožniť vykonávanie automatických inventúr na skladoch vo zvolenom termíne
  • Možnosť sledovania pohybu liekov, ŠZM a zdrav. materiálu na skladoch/medziskladoch
  • Možnosť nastaviť práva na podpisovanie žiadaniek o lieky;
  • Možnosť automatického priradenia čísla faktúr k spotrebovaným liekom a ŠZM;
  • Možnosť evidencie príjmu a výdaja centrálne nakupovaných liekov;
  • NIS musí umožniť sledovanie exspirácie – upozornenie, ktoré lieky budú exspirovať po určitej dobe;
  • Možnosť prehľadu položiek a pohybov podľa rôznych filtrov;
  • NIS musí umožniť nastaviť v skladovej karte hlavného dodávateľa a nákupnú cenu za mernú jednotku;
  • Možnosť vystavenia žiadanky pre externého dodávateľa
  • Možnosť prijatia el. dodacieho listu vo formáte PHARMNET aj priamo do skladu/medziskladu
  • Schválenie žiadanky lieku mimo nemocničný liekový formulár elektronicky

Požiadavky pre nemocničnú lekáreň

  • NIS musí byť integrovaný na informačný systém nemocničnej lekárne

Požiadavky pre centrálne spracovanie dávok

  • NIS musí umožniť spracovanie všetkých typov dávok pre zdravotné poisťovne a Sociálnu poisťovňu;
  • NIS musí umožniť spracovanie dávok pre domácich poistencov, bezdomovcov, poistencov EÚ a pacientov mimo EÚ;
  • NIS musí umožniť aj spracovanie dávok z pracovísk nezaradených do informačného systému;
  • NIS musí umožniť import textovej dávky do systému
  • NIS musí umožniť hromadné úpravy dávok (presuny, filtre a pod.) pred aj po ocenení dávok
  • Možnosť evidencie zmlúv, zmluvných cien a výnimiek podľa poisťovne a pracoviska, resp. odbornosti;
  • Možnosť vytvorenia zúčtovacích dokladov a faktúr za celé zdravotnícke zaradenie;
  • Možnosť exportu údajov do ekonomického systému;
  • Možnosť exportu údajov do manažérskeho systému;
  • Možnosť načítania chybových dávok z poisťovní;
  • Možnosť vytvorenia ročnej dávky DRG aj pre kalkulačné nemocnice;
  • Prehľad rozdelenia výnosov na prípad podľa zúčastnených pracovísk;
  • Prehľad súm za SVLZ výkony pre DRG relevantné oddelenia;
  • Možnosť zaevidovať a prepočítať DRG prípady rôznymi sadzbami;
  • Možnosť prepočítať údaje pomocou DRG groupera pre konkrétny riadok dávky (o ukončení prípadu);
  • Prehľad účtovaných pripočítateľných položiek;
  • Možnosť overenia poistného vzťahu;
  • Možnosť hromadnej opravy údajov;
  • Možnosť vytvárať aditívne a opravné dávky;
  • Možnosť zmeny identifikačných údajov poistenca (poistného vzťahu, rod. čísla alebo IČP);
  • Možnosť vytvorenia a doplnenia položky v číselníku výkonov a pripočítateľných položiek;
  • Možnosť vytvorenia podkladu k faktúre podľa štruktúry nákladových stredísk.
  • V zostavách smerom do NCZI alebo ZP možnosť rozdelenia hospitalizácie podľa malých prekladov
  1. Požiadavky pre manažérsku nadstavbu a reporting
  • Slúži pre manažment nemocnice na rozhodovanie a umožňuje rýchle a jednoduché pripojenie k viacerým zdrojom údajov, rýchlu analýzu údajov
  • Musí umožniť importovať všetky dáta z ostatných informačných systémov a aplikácií nemocnice (nemocničný informačný systém, vrátane jeho laboratórnej, rádiologickej, lekárenskej časti, ekonomický informačný systém, systém (modul) zúčtovania so zdravotnými poisťovňami, analytické DRG nástroje, personalistika), tzn. 1 dátový sklad pre všetky IS nemocnice
  • Importy z jednotlivých informačných systémov a aplikácií musia prebiehať na dennej báze a užívateľ musí dostávať pravidelnú informáciu (emailom) o úspešnom načítaní všetkých dát
  • Musí umožniť generovať výstupy bez obmedzenia kapacity riadkov (aj veľké databázy údajov) vo formáte .csv, resp. .xls + grafické znázornenie
  • Užívateľ (administrátor manažérskeho modulu) musí mať prístup k jednotlivým číselníkom v manažérskom module (napr. možnosť úpravy resp. aktualizácie číselníka NS)
  • Umožňuje pridelenie rôznych úrovní oprávnení pre prácu s modulom
  • Musí ponúkať možnosť zadefinovania vlastných zostáv podľa zvolených kritérií užívateľa
  • Na základe údajov z NIS musí poskytnúť údaje pre hodnotenie nákladov a výnosov za poskytnutú zdravotnú starostlivosť
  • Možnosť nastaviť limity určené zdravotnými poisťovňami kvôli kontrole priebežného plnenia, bez zásahu dodávateľa
  • Sledovanie priebežného stavu určených limitov zdravotných poisťovní a ich vyhodnotenie bez zásahu dodávateľa
  • Možnosť automatických exportov z databázy pre rôzne prehľady (podľa vopred definovaných požiadaviek užívateľom)
  • Priebežný prehľad stavu vykazovaných údajov za všetky ambulancie a oddelenia nemocnice
  • Možnosť automatického zasielania vybraných reportov online zvoleným užívateľom
  • Možnosť exportu údajov do iných systémov (napr. ekonomického informačného systému)
  • Má preddefinované reporty a umožňuje vytvárať vlastné reporty
  • Všetky reporty musia mať možnosť uloženia v csv resp. xls formáte
  • Možnosť vytvárať a exportovať reporty o ekonomických a finančných ukazovateľoch
  • Možnosť vytvárať a exportovať reporty o personálnych ukazovateľoch
  • Možnosť vytvárať a exportovať reporty o medicínskych ukazovateľoch
  • Možnosť spájať rôzne ukazovatele do jedného reportu
  • Možnosť sledovať ukazovatele na rôznych úrovniach, napr. na úrovni nemocnice, oddelenia, nákladového strediska, PZS, odbornosti, pacienta, zamestnanca
  • Možnosť vytvárať a exportovať reporty na základe rôznych kritérií, min. NS (požadujúce / vykonávajúce NS) odbornosť, typy NS, ZP(EU)samoplatca, PZS, aktuálny vek, pohlavie, kraj, okres, antropometrických údajov a základných vitálnych ukazovateľov, diagnóza, vedľajšia diagnóza, kritériá špecifické pre daný prehľad, napr. typ príjmu, opakovaná / nová návšteva ...)
  • Umožňuje automatické zasielanie notifikácií, reportov
  • Umožňuje vyhľadávanie údajov
  • Umožňuje variabilné zadanie zobrazovaných dát
  • Umožňuje porovnávanie údajov (preddefinované controllingové zostavy)
  • Sledovanie nákladov na pacienta (účet pacienta) - (musí obsahovať užívateľom definované položky, ako napr. dátum a čas príjmu, prepustenia, druh príjmu, druh prepustenia, dátum a čas prekladu na iné odd., vykázané lieky, počas hospitalizácie (suma v EUR, počet), vykázané ŠZM počas hospitalizácie (suma v EUR, počet), vykázané kategorizované ŠZM počas hospitalizácie (suma v EUR, počet), vykázané TRL počas hospitalizácie (suma v EUR, počet), DRG skupina, PCCL, prepustený áno/nie, diagnóza a iné)
  • Podpora tvorby plánu (plánov)
  • Možnosť tvorby finančného plánu, plánu nákladov a výnosov v podrobnosti definovaných zadávateľom
  • Možnosť tvorby plánu kľúčových ukazovateľov zdravotnej starostlivosti
  • Detail vytváraného plánu nemusí zodpovedať detailu skutočnosti - napr. plán nákladov nie je realizovaný podľa účtovej osnovy, ale na reportingovú účtovnú osnovu, obdobne u organizačnej štruktúry
  • Podpora tvorby variantov plánu, forecast (výhľadu)
  • Jadrom manažérskej nadstavby musí byť relačný dátový sklad (DWH) integrujúci dáta pre potreby sledovania nákladov DRG, NIS, HR a ďalších informačných systémov, modulov a aplikácii prevádzkovaných verejným obstarávateľom
  • Musí umožňovať rýchle a jednoduché pripojenie k viacerým zdrojom údajov
  • Musí umožniť importovať požadované dáta z ostatných informačných systémov a aplikácií prevádzkovaných verejným obstarávateľom, tzn. 1 dátový sklad pre všetky informačné systémy, moduly, aplikácie prevádzkované verejným obstarávateľom
  • Importy z jednotlivých informačných systémov, modulov a aplikácií musia prebiehať na dennej báze (automaticky) a používateľ musí dostávať pravidelnú informáciu (emailom) o úspešnom načítaní všetkých dát
  • Importy pre vybrané zdroje dát musí byť možné spustiť oprávneným používateľom
  • DWH musí byť koncipovaný ako modulárny a umožňujúci začlenenie nových zdrojov dát pri prípadnom rozvoji a dopĺňaní nových informačných systémov a aplikácii v prostredí verejného obstarávateľa
  • DWH musí poskytovať porovnateľné dáta naprieč systémovým prostredím verejného obstarávateľa, systému pre potreby sledovania nákladov DRG, NIS, HR a ďalších informačných systémov a aplikácii prevádzkovaných verejným obstarávateľom, dáta v DWH NIS musia byť detailné
  • Modul pre reporting musí poskytovať funkcionalitu plánovania, tvorbu variantov plánov a porovnania so skutočnosťou
  • Plánované údaje musia byť uložené v DWH spolu s auditlogom
  • Prístup k reportom, dátam, tvorbe plánov musia byť riadené prístupovými právami
  • Používateľ (administrátor manažérskej nadstavby) musí mať prístup k jednotlivým číselníkom, prevodovým mostíkom, tabuľkám (napr. Možnosť úpravy resp. Aktualizácie číselníka NS)
  • Má preddefinované reporty a umožňuje vytvárať vlastné reporty
  • Musí umožniť generovať výstupy + grafické znázornenie bez obmedzenia kapacity riadkov (aj veľké databázy)
  • Všetky reporty musia mať možnosť uloženia v csv resp. xls formáte
  • Musí ponúkať možnosť zadefinovania vlastných zostáv podľa zvolených kritérií používateľa
  • Poskytovať online vybrané reporty zvoleným používateľom
  • Export údajov do ekonomiky
  • Možnosť automatických exportov z databázy pre rôzne prehľady (podľa vopred definovaných požiadaviek užívateľom)
  • Možnosť spájať rôzne ukazovatele do jedného reportu
  • Musí umožňovať automatické zasielanie notifikácií, reportov
  • Musí umožňovať vyhľadávanie údajov na základe zadania údajov
  • Musí umožňovať variabilné zadanie zobrazovaných dát
  • Musí umožňovať porovnávanie údajov (preddefinované controllingové zostavy)
  • Musí umožňovať rozpad hodnôt až k detailu DWH
  • Tvorba plánu musí byť možná v agregovanej podobe s možnosťou rozpadu na požadovaný detail
  • Systém plánovania musí podporiť tvorbu plánu na základe skutočnosti, alebo iného variantu plánu
  • Systém musí umožniť porovnanie plánov so skutočnosťou a jeho vyhodnotenie, prípadne porovnanie variantov plánov
  • Systém musí vedieť evidovať uskutočnené zmeny plánovaných dát - mať logovanie
  • Zadávanie údajov musí byť riadené prístupovými právami – na úrovniach variantov, rokov, stredísk, oddelení
  • Zadávanie údajov musí prebiehať prostredníctvom predpripravených formulárov alebo zostáv, s používateľskou tvorbou zostáv
  • Dáta všetkých plánov a variantov musia byť uložené na jednom mieste – databáza
  • Systém musí umožňovať tvorbu plánov súčasne viacerými používateľmi
  • Zadanie údajov musí prebehnúť iba jedenkrát, pokiaľ sú rovnaké údaje (prípadne ich agregácie) potrebné v inej časti plánu/zostave, systém musí zabezpečiť ich prenos na pokyn oprávneného používateľa
  • Systém musí umožňovať formátovať dátum a čas (používať jednotný formát)
  • Systém musí umožňovať a zjednodušovať spoluprácu medzi používateľmi;
  • Systém musí byť intuitívny, musí mať k dispozícii personalizované pracovné prostredie a funkcie pre filtrovanie, otáčanie a vytváranie vizualizácií
  • Systém musí generovať všetky výstupy potrebné pre štatistické účely NCZI automaticky
  • Prehľad základných ekonomických ukazovateľov (ukazovatele likvidity, aktivity, rentability, zadlženosti)
  • Tvorba finančných plánov, plánov nákladov a výnosov podľa NS
  • Musí poskytovať možnosť vytvorenia plánu KPI pre poskytovanú zdravotnú starostlivosť
  • Modul pre reporting musí poskytovať údaje pre hodnotenie nákladov a výnosov za poskytnutú zdravotnú starostlivosť
  • Musí disponovať možnosťou nastavenia limitov určených zdravotnými poisťovňami kvôli kontrole priebežného plnenia, bez zásahu dodávateľa
  • Musí poskytovať možnosť sledovania priebežného stavu určených limitov zdravotných poisťovní a ich vyhodnotenie bez zásahu dodávateľa
  • Musí poskytovať priebežný prehľad stavu vykazovaných údajov za všetky ambulancie a oddelenia nemocnice
  • Musí poskytovať možnosť sledovania ukazovateľov na rôznych úrovniach, napr. na úrovni nemocnice, oddelenia, nákladového strediska, PZS, odbornosti, pacienta, zamestnanca;
  • Musí mať možnosť vytvárať a exportovať reporty na základe rôznych kritérií, min. NS (požadujúce / vykonávajúce NS), odbornosť, typy NS, ZP(EU)samoplatca, PZS, aktuálny vek, pohlavie, kraj, okres, antropometrických údajov a základných vitálnych ukazovateľov, diagnóza, vedľajšia diagnóza, kritériá špecifické pre daný prehľad, napr. typ príjmu, opakovaná / nová návšteva ...)
  • Musí umožňovať sledovanie nákladov na pacienta (účet pacienta) - (musí obsahovať užívateľom definované položky, ako napr. dátum a čas príjmu, prepustenia, druh príjmu, druh prepustenia, dátum a čas prekladu na iné odd., vykázané lieky počas hospitalizácie (suma v EUR, počet), vykázané ŠZM počas hospitalizácie (suma v EUR, počet), vykázané kategorizované ŠZM počas hospitalizácie (suma v EUR, počet), vykázané TRL počas hospitalizácie (suma v EUR, počet), DRG skupina, PCCL, prepustený áno/nie, diagnóza a iné).
  • Systém musí podporovať : spracovanie dátových zdrojov relačnej databázy, Excel, hadoop      
  • Systém musí mať možnosť automaticky spracovať dáta        
  • Systém musí umožniť riadenie prístupových práv    
  • Systém musí podporovať prechádzanie a rozklad indikátorov kvality v rámci nemocnice cez oddelenia
  • Systém musí podporovať SSO
  • Systém musí podporovať zobrazenie indikátorov v grafickej forme ako "budíkov"
  • Systém musí podporovať zobrazenie časového priebehu s trendovou krivkou
  • Systém musí podporovať export do excelu, pdf
  • Systém musí podporovať automatické posielanie reportov
  • Systém musí podporovať emailové alerty pri prekročení hraničných hodnôt indikátorov
  • Systém musí obsahovať mobilnú aplikáciu pre vyhodnocovanie KPI.
  • Systém musí podporovať obsahovať automatické filtre údajov na základe prihláseného používateľa
  • Systém musí podporovať možnosť úprav prehľadov/dashboardov na základe oprávnení
  1. Prehľady manažérskej nadstavby a reportingu
  • Prehľad nákladov na ukončené hospitalizácie
  • Prehľad nákladov na hospitalizácie (podrobne a aj sumárne po NS)
  • Prehľad ukončených hospitalizácií / lôžkodní
  • Prehľad hospitalizačných prípadov
  • Prehľad ošetrovacej doby
  • Prehľad návštev, obložnosti a stavu lôžok (od najnižšej možnej štruktúry až po NS, oddelenie)
  • Prehľad ukazovateľov využitia lôžkového fondu (počet lôžok, obsadené lôžka, voľné lôžka)
  • Prehľad prijatých pacientov
  • Prehľad denných príjmov, prepustení (podrobne a aj sumárne po NS)
  • Prehľad preložených pacientov (podrobne a aj sumárne po NS)
  • Prehľad prepustených pacientov (hospitalizačných prípadov) podľa jednotlivých oddelení, resp. nižších úrovní (aj podľa okresov, VÚC, vekovej štruktúry a pod) podrobne a aj sumárne po NS
  • Prehľad prepustených pacientov bez prekladov s udaním typu prepustenia, oddelenia
  • Prehľad prepustených (hospitalizačných prípadov) podľa diagnóz
  • Prehľad zomrelých pacientov
  • Prehľad pohybu pacientov, príjem, preklad, prepustenie)
  • Prehľad objednaných pacientov
  • Prehľad dispenzarizovaných pacientov
  • Prehľad plánovaných hospitalizácií (aj nezrealizovaných a stornovaných)
  • Prehľad cudzincov EÚ v zúčtovaní
  • Prehľad vykazovaných a iných výkonov pre hospitalizovaných pacientov (s možnosťou filtrovania vybraných výkonov)
  • Prehľad výkonov, ktoré neprešli do vyúčtovania so ZP (podrobne a aj sumárne po NS) - pre oddelenia, ambulancie a SVaLZ
  • Prehľad ambulantných bodov a výkonov podľa ambulancií a lekárov
  • Prehľad ambulantných návštev, bodov, výkonov, prvonávštev, diagnóz
  • Prehľad ambulantných návštev v podrobnom členení na pacienta (aj na okresy, VÚC, vekovú štruktúru a pod) a aj sumárne po NS
  • Prehľad ambulantných pacientov podľa diagnóz
  • Prehľad úväzkov ambulantných lekárov
  • Prehľad pacientov, ktorým bolo realizované SVaLZ vyšetrenie v podrobnej štruktúre podľa jednotlivých oddelení, resp. nižších úrovní (aj podľa okresov, VÚC, vekovej štruktúry a pod
  • Prehľad SVaLZ-ových bodov a výkonov spolu s NS, ktoré výkony požadovali (podrobne a aj sumárne po NS)
  • Prehľad konziliárnych vyšetrení
  • Prehľad operácií a operačných výkonov
  • Prehľad počtu podaných anestéz / typov anestézií
  • Prehľad diét
  • Prehľad predpísaných liekov a zdravotníckych pomôcok (podrobne a aj sumárne po NS)
  • Prehľad liekov podaných na ambulanciách (podrobne a aj sumárne po NS)
  • Prehľad vykazovaných liekov / krvi / ZM pre hospitalizovaných pacientov
  • Prehľad vykazovaných liekov / ZM na SVaLZ pracoviskách v detailnej štruktúre (po NS)
  • Prehľad inventúr na skladoch
  • Prehľad spotreby liekov podľa nákladových stredísk
  • Prehľad stavu skladov
  • Prehľad pohybov na skladoch a v lekárni (výdaj na NS, príjem a pod.)
  • Prehľad žiadaniek na lieky a ŠZM od jednotlivých NS (podrobne a aj sumárne po NS)
  • Prehľad prevodiek medzi nákladovými strediskami
  • Vyhľadanie liečiva (liekov / ZM) na skladoch
  • Prehľad vydaných a ešte neprijatých liečiv
  • Prehľad hotovostných výkonov, aj podľa výnosových účtov
  • Prehľad inkasovaných hotovostných príjmov do pokladnice
  • Prehľad aktuálnej celkovej ceny spotreby liekov a ŠZM na nákladové stredisko
  • Sledovanie priebežného stavu určených limitov zdravotných poisťovní a ich vyhodnotenie bez zásahu dodávateľa
  • Prehľad neuznaných výkonov (hospitalizačných prípadov, ambulantných pacientov a pod.)
  • Porovnávacia zostava — fakturované vs. vykázané (výkony, lieky)
  • Sledovanie ekonomických ukazovateľov - prehľad nákladov, výnosov, HV podľa jednotlivých syntetických a analytických účtov účtovnej osnovy a NS v detailnej štruktúre
  • Prehľad pohybov na účtoch účtovnej osnovy a NS
  • Prehľad poskytnutých nadštandardných služieb, aj podľa výnosových účtov
  • Prehľad hotovostných výkonov, aj podľa výnosových účtov
  • Prehľad inkasovaných hotovostných príjmov do pokladnice
  • Prehľad aktuálnej celkovej ceny spotreby liekov a ŠZM na nákladové stredisko
  • Prehľad základných ekonomických ukazovateľov (ukazovatele likvidity, aktivity, rentability, zadlženosti)
  • Reporty nad agendami:  Účtovnými  dokladmi, Pokladňa, Banka, Majetok, Fakturácia, Saldo
  • Profitabilita – alokácia režijných nákladov na sledované jednotky a hodnotenie ich profitability
  • Personálny plán podľa kategórií zamestnancov
  • Prehľad personálnych nákladov podľa kategórií zamestnancov
  • Zostava sledovaných personálnych ukazovateľov
  • Absencie, Prekážky, Čerpanie dovoleniek a zostatky dovoleniek, Stavy zamestnancov, Fluktuácia
  • Prehľad anestéziologických protokolov
  • Prehľad a možnosti nastavenia limitov určených poisťovňami kvôli kontrole priebežného plnenia, bez zásahu dodávateľa
  • Prehľad k sledovaniu priebežného stavu určených limitov zdravotných poisťovní a ich vyhodnotenie bez zásahu dodávateľa
  • Prehľad dávok odoslaných do zdravotných poisťovní  vo formáte csv, resp. xls

Prehľady k sledovaniu ekonomických ukazovateľov:

  • Prehľad nákladov, výnosov, HV podľa jednotlivých účtov účtovnej osnovy a NS v detailnej štruktúre;
  • Prehľad pohybov na účtoch účtovnej osnovy a NS;
  • Prehľad hotovostných výkonov, aj podľa výnosových účtov;
  • Prehľad inkasovaných hotovostných príjmov do pokladnice;
  • Prehľad aktuálnej celkovej ceny spotreby liekov a ŠZM na nákladové stredisko;
  • Prehľad základných ekonomických ukazovateľov (ukazovatele likvidity, aktivity, rentability, zadlženosti);
  • Prehľad o realizovaných nákladoch na zdravotníckej technike filtrovateľný podľa typu prístroja, oddelenia, obdobia, zodpovednej osoby, nákladového strediska a podobne;
  • Prehľad výkonov a ich nákladov rozdelený podľa dodávateľských firiem, typov zariadení a nastaviteľného obdobia;
  • Prehľad zdravotníckej techniky a prístrojov usporiadaný podľa jednotlivých oddelení, poschodí, priestorov, budov prípadne ďalších kľúčov;
  1. Systémové požiadavky  

Riešenie bude prednostne umiestnené a prevádzkované  vo vládnom cloude v rozsahu a v súlade so zákonom 305/2013 (zákon o e-Governmente);

  • Požadujeme stabilnú a dynamicky škálovateľnú platformu, ktorá musí byť schopná nasadiť a orchestrovať kontejnery (napr. Kubernetes), pričom NIS bude kontajnerizovaný;
  • Požadujeme najnovšiu dlhodobo podporovanú verziu verziu kontajnerizačnej platformy a OS na virtuálnych strojoch;
  • Riešenie musí byť flexibilne škálovateľné bez dramatických zmien do nástrojov, architektúry, alebo spôsobu vývoja;

Požiadavka na súlad so zákonmi a predpismi / Nariadeniami o bezpečnosti:

  • Smernica NIS 1 Smernica Európskeho parlamentu a Rady (EÚ) 2016/1148 z 6. júla 2016 o opatreniach na zabezpečenie vysokej spoločnej úrovne bezpečnosti sietí a informačných systémov v Únii;
  • Smernica NIS 2 Smernica Európskeho parlamentu a Rady (EÚ) 2022/2555 z 14. decembra 2022 o opatreniach na zabezpečenie vysokej spoločnej úrovne kybernetickej bezpečnosti v celej Únii a o zrušení smernice (EÚ) 2016/1148;
  • Odborné usmernenie č. 47/2009 o vedení zdravotnej dokumentácie;
  • vyhláška č. 362/2018 Z.z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení;
  • Zákon č. 69/2018 Z.z., o kybernetickej bezpečnosti;
  • Zákon č. 18/2018 Z.z. o ochrane osobných údajov;
  • Zákon č. 576/2004 Z.z. o zdravotnej starostlivosti;
  • Kritická infraštruktúra musí zabezpečiť ochranu pred neautorizovaným prístupom a fyzickými hrozbami;
  • Musí umožniť viacfaktorovú autentifikáciu (MFA) na overenie používateľov, ktorí pristupujú k NIS, a implementovať princíp najmenej oprávnenia, ktorý obmedzuje prístup len na nevyhnutné zdroje a dáta;
  • Riešenie je v súlade s ustanoveniami legislatívnych predpisov o ochrane osobných údajov;
  • Modulárna architektúra umožňujúca škálovateľnosť a rozšíriteľnosť systému v súlade s princípmi microservices;

Podpora OpenEHR štandardov na uchovávanie a výmenu zdravotných údajov;

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

Súčasný IS nie je evidovaný v META IS

Kód ISVS

(z MetaIS)

Názov ISVS

Modul ISVS

(zaškrtnite ak ISVS je modulom)

Stav ISVSTyp ISVS

Kód nadradeného ISVS

(v prípade zaškrtnutého checkboxu pre modul ISVS)

 NIS Xanta  Prevádzkovaný a neplánujem rozvoj  Agendový 
    Vyberte jednu z možností  Vyberte jednu z možností 
    Vyberte jednu z možností  Vyberte jednu z možností 

Tabuľka č.2 Prehľad dotknutých informačných systémov v projekte – súčasný stav

V rámci projektu bude budovaný nový ISVS

Kód ISVS (z MetaIS)Názov ISVS

Modul ISVS

(zaškrtnite ak ISVS je modulom)

Stav IS VSTyp IS VS

Kód nadradeného ISVS

(v prípade zaškrtnutého checkboxu pre modul ISVS)

isvs_15220Nemocničný informačný systém  Plánujem budovať  Agendový 
    Vyberte jednu z možností  Vyberte jednu z možností 
    Vyberte jednu z možností  Vyberte jednu z možností 

Tabuľka č. 3 Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav

Kód AS

(z MetaIS)

Názov  ASPoskytovaná na externú integráciu (zaškrtnite ak áno)

 

Typ cloudovej služby

SVS/modul ISVS

(kód z MetaIS)

Aplikačná služba realizuje KS

(kód KS z MetaIS)

as_67601Služba prístupu k pacientskému profilužiadnyisvs_15220 
as_67602Služba zápisu a čítania zdravotných údajovžiadnyisvs_15220 
as_67603Služba volania rozhraní eZdraviežiadnyisvs_15220 
as_67604Služba integrácie s LIS / PACSžiadnyisvs_15220 
as_67605Služba generovania a exportu výkazovžiadnyisvs_15220 
as_67606Autentifikačná a autorizačná služba (AD, karty, heslá)žiadnyisvs_15220 
as_67607Služba integrácie s externými ISVSžiadnyisvs_15220 
as_67608Služba zápisu údajov do eZdraviažiadnyisvs_15220 
as_67609Služba integrácie s ostatnými internými ISVSžiadnyisvs_15220 

Tabuľka č.4 Prehľad budovaných aplikačných služieb – budúci stav



      1. Využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS)

Projekt neplánuje s využívaním nadrezortných centrálnych blokov a podporných spoločných blokov

Kód ISVS

 (z MetaIS)

Názov ISVS

 

Spoločné moduly podľa zákona č. 305/2013  e-Governmente
  Vyberte jednu z možností.
  Vyberte jednu z možností.
  Vyberte jednu z možností.

Tabuľka č.5 Prehľad integrácii ISVS na nadrezortné centrálne bloky – súčasný stav



      1. Prehľad plánovaného využívania podporných spoločných blokov (SaaS)

Projekt neplánuje využívania podporných spoločných blokov

Kód ISVS

(z MetaIS)

Názov ISVS

 

Kód a názov podporného spoločného bloku (z MetaIS)
   
   
   

Tabuľka č.6 Prehľad integrácii ISVS na podporné spoločné bloky (SaaS) – budúci stav



      1. Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky – spoločné moduly

Projekt neplánuje integráciu na nadrezortné centrálne bloky

Kód ISVS

(z MetaIS)

Názov ISVS

 

Spoločné moduly podľa zákona č. 305/2013  e-Governmente
  Vyberte jednu z možností.
  Vyberte jednu z možností.
  Vyberte jednu z možností.

Tabuľka č.7 Prehľad integrácii ISVS na spoločné moduly – budúci stav



      1. Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky - modul procesnej integrácie a integrácie údajov  (IS CSRÚ)

Projekt neplánuje integráciu na IS CSRU

Kód ISVS (z MetaIS)Názov (integrovaného) ISVS na IS CSRÚ
  
  
  

Tabuľka č.8  Prehľad integračných väzieb medzi ISVS a IS CSRÚ – budúci stav



      1. Poskytovanie údajov z ISVS do IS CSRÚ

Projekt neplánuje poskytovanie údajov do IS CSRÚ

ID OENázov (poskytovaného) objektu evidencieKód ISVS poskytujúceho OENázov ISVS poskytujúceho OE
    
    
    

Tabuľka č.9 Prehľad ISVS a objektov evidencie poskytovaných do IS CSRÚ – budúci stav



      1. Konzumovanie údajov z IS CSRU

Projekt neplánuje konzumovanie údajov z IS CSRU

ID  OE

 

Názov (konzumovaného) objektu evidencie

 

Kód a názov ISVS konzumujúceho OE z IS CSRÚKód zdrojového ISVS v MetaIS
    
    
    

Tabuľka č. 10 Prehľad ISVS a objektov evidencie konzumovaných z IS CSRÚ – budúci stav


    1. Dátova 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.



      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ť.
      1. Dátový rozsah projektu

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

ID OEObjekt evidencie - názovObjekt evidencie - popis

Referencovateľný identifikátor URI dátového prvku (áno- uviesť URI/nie nemá)

 

OE_1Zdravotná dokumentáciaAnamnézy, vstupné a výstupné správy, konzília, operačné protokoly 
OE_2Údaje o pacientochMeno, RČ, poisťovňa, kontakty, zmluvné vzťahy 
OE_3Liekové záznamy a ordinácieeRecepty, výdajové záznamy, hospitalizačné liečby 
OE_4Výsledky vyšetreníLaboratórne a zobrazovacie dáta (integrované alebo ako odkazy/PACS ID) 
OE_5Výkony a hospitalizácieEvidencia vykonaných úkonov, trvanie hospitalizácie, klasifikácia DRG 
OE_6Výkazníctvo a štatistikyDávky pre NCZI, zdravotné poisťovne, štatistické prehľady 
OE_7Metaúdaje a logyAuditné záznamy, logy prístupov, schémy verzií dokumentov 

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:

1753104186253-522.png

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



      1. Kvalita a čistenie údajov
        1. Zhodnotenie objektov evidencie z pohľadu dátovej kvality
ID OE

Objekt evidencie

(uvádzať OE z tabuľky 11)

Významnosť kvality

1 (malá) až 5 (veľmi významná)

Citlivosť kvality

1 (malá) až 5 (veľmi významná)

Priorita – poradie dôležitosti

(začnite číslovať od najdôležitejšieho)

OE_1Zdravotná dokumentácia551.
OE_2Údaje o pacientoch551.
OE_3Liekové záznamy a ordinácie551.
OE_4Výsledky vyšetrení551.
OE_5Výkony a hospitalizácie551.
OE_6Výkazníctvo a štatistiky551.
OE_7Metaúdaje a logy551.

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




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

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

RolaČinnostiPozícia zodpovedná za danú činnosť (správca ISVS / dodávateľ)
Dátový kurátorEvidencia požiadaviek na dátovú kvalitu, monitoring a riadenie procesuDátový kurátor správcu IS
Data stewardČistenie a stotožňovanie voči referenčným údajomPracovník IT podpory
Databázový špecialistaAnalyzuje požiadavky na dáta, modeluje obsah procedúrDodávateľ
Dátový špecialista pre dátovú kvalituSpracovanie výstupov merania, interpretácie, zápis biznis pravidiel, hodnotiace správy z meraniaDátový špecialista pre dátovú kvalitu – nová interná pozícia v projekte
*Iná rola (doplniť)  

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


    1. Referenčné údaje

Projekt nevytvára referenčné údaje



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

Projekt nevytvára referenčné údaje

ID OE

Názov referenčného registra /objektu evidencie

(uvádzať OE z tabuľky 11)

Názov referenčného údajaIdentifikácia subjektu, ku ktorému sa viaže referenčný údajZdrojový register a registrátor zdrojového registra
1    
2    
3    

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



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

Projekt neposkytuje ani nekonzumuje údaje z IS CSRU

     ID

 

Názov referenčného údajaKonzumovanie / poskytovanieOsobitný právny predpis pre poskytovanie / konzumovanie údajov
1 Vyberte jednu z možností. 
2 Vyberte jednu z možností. 
3 Vyberte jednu z možností. 

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


    1. Otvorené údaje

Projekt neprodukuje otvorené údaje

Názov objektu evidencie / datasetu

(uvádzať OE z tabuľky 11)

 

Požadovaná interoperabilita 3★ - 5★

Periodicita publikovania

(týždenne, mesačne, polročne, ročne)

 Vyberte jednu z možností.Vyberte jednu z možností.
 Vyberte jednu z možností.Vyberte jednu z možností.
 Vyberte jednu z možností.Vyberte jednu z možností.
 Vyberte jednu z možností.Vyberte jednu z možností.
 Vyberte jednu z možností.Vyberte jednu z možností.

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


    1. Analytické údaje

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

IDNázov objektu evidencie pre analytické účelyZoznam atribútov objektu evidenciePopis a špecifiká objektu evidencie
1   
2   
3   

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


    1. Moje údaje

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

. ID

Názov registra / objektu evidencie

(uvádzať OE z tabuľky 11)

Atribút objektu evidenciePopis a špecifiká objektu evidencie
    
    
    
    

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


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

Irelevantné

ID

Register / Objekt evidencie

(uvádzať OE z tabuľky 11)

Referenčné údajeMoje údajeOtvorené údajeAnalytické údaje
1 
2 
3 
4 
5 
x 

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, …).

ParameterJednotkyPredpokladaná hodnotaPoznámka
Počet interných používateľovPočet1200 
Počet súčasne pracujúcich interných používateľov v špičkovom zaťaženíPočet350 
Počet externých používateľov (internet)PočetN/A 
Počet externých používateľov používajúcich systém v špičkovom zaťaženíPočetN/A 
Počet transakcií (podaní, požiadaviek) za obdobiePočet/obdobie500 000 
Objem údajov na transakciuObjem/transakcia0,5 MB 
Objem existujúcich kmeňových dátObjemcca 500 000 GB 
Ďalšie kapacitné a výkonové požiadavky ... 
- Dostupnosť 24/7 s max. výpadkom 2h/mesačne
  - Odozva systému do 2 sekúnd pre 95 % transakcií
  - Škálovateľnosť minimálne +30 % používateľov ročne
 

4.4.3Návrh riešenia technologickej architektúry

1749450452678-301.png

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

Parametre pre cloudove služby budú zadefinované po výbere riešenia s dodávateľom v rámci analýzy a dizajnu

Kód infraštruktúrnej služby
(z MetaIS)

Názov infraštruktúrnej služby

Kód využívajúceho ISVS
(z MetaIS)

Názov integrovaného ISVS
    
    
 
ID

Ďalšie služby potrebné na prevádzku projektu z katalógu služieb vládneho cloudu

(stručný popis / názov)

Hodnoty
1.Doplň názov a stručný popis 
2.Doplň názov a stručný popis 
3.Doplň názov a stručný popis 

5. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Projekt nemá externé závislosti

Stakeholder

Kód projektu

(z MetaIS)

Názov projektuTermín ukončenia projektuPopis závislosti
     

Tabuľka č. 23 Prehľad projektov, ktoré sú v štádiu vývoja a v korelácii s pripravovaným projektom

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.

Minimálne požiadavky na prevádzku systému:

  • Miera dostupnosti - 24x7, dostupnosť 99,99 %, doba odstránenia poruchy do 4 hodín
  • Forma podpory: telefonická, email, ServiceDesk, podpora priamo na mieste,
  • Riešenie redundancie technických prostriedkov: v závislosti od úrovne poskytovania služieb vládneho cloudu v čase nasadzovania projektu.

Spôsob prevádzky bude zabezpečený kombináciou viacerých zdrojov:

  • Určení zamestnanci FN NT, Prevádzkovateľ infraštruktúry, PZS
  • Prevádzku dátových centier zabezpečuje prevádzkovateľ infraštruktúry v spolupráci s vlastníkov infraštruktúry a dodávateľom HW riešenia
  • Zhotoviteľ diela

Účelom podpory je zabezpečenie služieb technickej podpory prevádzky, údržby a rozvoja Systému z dôvodu zabezpečenia jeho riadnej prevádzkyschopnosti a úprav funkcionalít tak, aby mohla byť zabezpečená interoperabilita so všetkými informačnými systémami, s ktorými bude IS integrovaný.

Zhotoviteľ sa zaväzuje poskytnúť VO v rozsahu a za podmienok tejto podpory zabezpečiť služby technickej podpory prevádzky a údržby v nasledovnom rozsahu:

  1. správa, posudzovanie, riešenie a odstraňovanie Incidentov a problémov v stanovených lehotách, ktoré zahŕňa:
    1. pravidelnú profylaktiku prostredia a kontrolu funkčnosti IS v stanovených lehotách
    2. priebežnú identifikáciu abnormálneho správania, t. j. monitoruje plánované / schedulované procesy pre spracovanie a publikovanie dát, sleduje výkonové parametre, vykonáva pravidelnú kontrolu nastavenia IS podľa posledného odsúhlaseného (schváleného) stavu konfigurácie systému,
    3. priebežné sledovanie, kontrolu a vyhodnocovanie záznamov z logov,
    4. aktívne upozorňovanie VO zhotoviteľom na možné zlepšenia a úpravy alebo zmeny IS
    5. aktívne upozorňovanie VO zhotoviteľom na vzniknuté incidenty, ako aj stavy systému, pri ktorých môže dôjsť, resp. ktoré môžu viesť k vzniku akýchkoľvek Incidentov alebo Bezpečnostných incidentov,
    6. realizáciu školení v priestoroch VO alebo prostredníctvom videokonferencie (v tomto prípade nesmú vyniknúť pre VO žiadne ďalšie náklady),
    7. aktualizáciu komplexnej dokumentácie k IS,
    8. podporu pri realizácii prevádzkových zásahov (podpora prevádzky IS);
  2. ďalšie dodávky, činnosti a práce nevyhnutné pre zachovanie funkčnosti a prevádzkyschopnosti IS, ktoré nie sú výslovne stanovené ako povinnosť Zhotoviteľa,

Zhotoviteľ sa zaväzuje na základe písomnej objednávky VO poskytnúť mu po potvrdení objednávky v dohodnutom čase a v súlade s podmienkami uvedenými v nasledujúcich bodoch „Objednávkové služby“.

7.1 Úrovne podpory používateľov:

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

  • prvú úroveň podpory (L1) bude zabezpečovať prevádzkovateľ infraštruktúry a prevádzkovateľ SW riešenia
  • podpora druhej úrovne (L2) bude zabezpečovaná dodávateľsky,
  • tretia úroveň podpory (L3), bude zabezpečovaná dodávateľsky,

Definícia podpory používateľov:

  • Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.
  • Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.
  • Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Samotná úroveň podpory je teda v 3 (troch) úrovniach s nasledovnými kompetenciami / úlohami:

  • L1 podpory Informačného systému (Level 1, priamy kontakt s koncovým užívateľom):
  • Prevádzka informačných systémov prevádzkovateľa infraštruktúry a prevádzkovateľa SW riešenia:
    • jednotný kontaktný bod Objednávateľa
    • identifikácia Incidentu/Problému, Vady, Defektu alebo výpadku Služby Systému alebo časti Služieb Systému
    • poskytovanie údajov Poskytovateľovi potrebných pre nahlásenie resp. riešenie Incidentu/Problému
    • súčinnosť s Poskytovateľom pri riešení Incidentu/Problému
    • riešenie základných uživateľských problémov, ktoré nesúvisia s funkčnosťou systému
    • forma podpory: Service Desk a pre vybrané skupiny koncových užívateľov cez telefón a e-mail
  • L2 podpory Informačného systému (Level 2, postúpenie požiadaviek od L1):
  • Poskytovateľ
    • riešenie Incidentu/Problému špecialistami
    • identifikácia Incidentu/Problému na technickej úrovni
    • kategorizácia Incidentu/Problému, Vady alebo Defektu (kritický resp. bezpečnostný, nekritický, bežný)
    • postúpenie na riešenie L3 v prípade, že L2 nevie poskytnúť riešenie
  • L3 podpory Informačného systému (Level 3, postúpenie požiadaviek od L2):
  • Poskytovateľ
    • riešenie Incidentu/Problému expertami v prípade potreby s výrobcom/vendorom
    • súčinnosť s L2 prípadne s Objednávateľom

Pre služby sú definované takéto SLA:

  • Help Desk je dostupný cez IS Solution manager a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v IS Solution manager,
  • Dostupnosť L2 a L3 podpory pre IS  - 24x7

7.2 Paušálne služby

Paušálne služby zahŕňajú zabezpečovanie bežnej servisnej podpory prevádzky IS, ako aj poskytovanie podpory pre zaistenie spoľahlivej, kontinuálnej a bezpečnej prevádzky v súlade s aktuálnymi platnými požiadavkami:

poskytnutie nových verzií so zapracovanými legislatívnymi zmenami, ktoré súvisia priamo s predmetom obstarania

poskytnutie nových verzií s optimalizovanými funkciami

poskytnutie nových verzií s rozšírenou funkcionalitou všeobecného charakteru

poskytnutie nových verzií IS v dôsledku zmien v informačných technológiách, alebo dôsledku riešenia problémov/incidentov

poskytovanie súčinnosti tretím stranám a/alebo SP pri implementácii iných agendových systémov objednávateľa

distribúciu nových verzií IS v zmysle predchádzajúcich bodov

upozorňuje na potrebu inštalácie nových verzií a zabezpečí aktualizáciu komponentov softvéru IS tak, aby nedošlo k výpadkom poskytovaných služieb v čase prevádzky (VO zabezpečí súčinnosť).

o poskytnutie odpovede cez telefónnu linku na otázky týkajúce sa problémových situácií vzniknutých pri používaní IS, tzn. k obsluhe IS, k problémovým stavom IS a k správaniu sa IS rozpore s opisom v používateľskej dokumentácii

správa, posudzovanie, riešenie a odstraňovanie incidentov a kybernetických bezpečnostných incidentov podľa Vyhlášky č. 165/2018 a problémov v stanovených lehotách

VO zabezpečí riadený a kontrolovaný prístup cez VPN pre zhotoviteľa. Zhotoviteľ musí plniť interné pravidlá pre používanie vpn v opačnom prípade mu môže byť prístup cez vpn odobraný aj počas trvania zmluvy bez nároku na úpravu finančného plnenia.

7.2.1 Správa, posudzovanie, riešenie a odstraňovanie incidentov a problémov v stanovených lehotách.

Prostredníctvom týchto služieb v súlade s účelom a predmetom plnenia zabezpečuje Zhotoviteľ VO proces riadenia a riešenie Objednávateľom označených Incidentov a Problémov, ktoré majú, resp. môžu mať, vplyv na dostupnosť a kvalitu prevádzky IS. Prostredníctvom týchto služieb zabezpečuje Zhotoviteľ aj pravidelnú profylaktiku prostredia na týždennej báze, ďalej vykonáva sledovanie logov jednotlivých komponentov, identifikuje abnormálne správanie, monitoruje plánované / schedulované procesy pre spracovanie a publikovanie dát, sleduje výkonové parametre, identifikuje incidenty a problémy. Spôsoby a procesy pre efektívne monitorovanie prevádzky Systému s cieľom čo najrýchlejšej identifikácie Incidentov a Problémov navrhne Zhotoviteľ počas realizácie plnenia, pričom musia byť v čo najväčšej miere využité nástroje ktorými disponuje VO.

V nasledovnom texte sú špecifikované príslušne detailné informácie, ktoré vymedzujú podmienky poskytovania služby

7.2.1.1 Spôsob elektronickej komunikácie pre riešenie Incidentov/Problémov:

  1. prostredníctvom nástroja, ktorý Zhotoviteľ zabezpečí pre VO na riadenie incidentov,
  2. zhotoviteľ zabezpečí možnosť online nahlasovania servisných udalostí s možnosťou sledovania ich stavu riešenia
  3. zabezpečí analýzu požiadavky a identifikáciu incidentu/problému
  4. zabezpečí riadenie servisných udalostí, požadovanú dobu odozvy od nahlásenia servisnej udalosti, návrh náhradného riešenia a riešenie servisnej udalosti v požadovanom hraničnom čase
  5. zabezpečí pre VO prístup k evidencii nahlásených servisných udalostí

Zoznam činností a podmienky nahlasovania Incidentov/Problémov sú uvedené v činnostiach pre tieto služby a VO si vyhradzuje ich upraviť podľa nastavených procesov prostredníctvom interného nástroja na riadenie ITSM, ktorý bude prispôsobovaný k efektívnemu riadeniu procesov podľa potrieb VO.

7.2.1.2 Kategorizácia Incidentov a Problémov:

Typ incidentuPopis
Incident/Problém úrovne A:Kritická vada / havária, ktorá spôsobuje nedostupnosť, alebo chybnú funkčnosť IS alebo jeho časti. Odstránenie Incidentu/Problému nie je možné dočasne zabezpečiť náhradným riešením Zhotoviteľa ani organizačným opatrením VO navrhnutého Zhotoviteľom. Odstránenie Incidentu/Problému môže mať negatívny vplyv na konzistenciu a integritu dát a výsledky ich spracovania v prostrediach VO.
Incident/Problém úrovne B:Vážna vada/ porucha, ktorá spôsobuje nedostupnosť, alebo chybnú funkčnosť IS alebo jeho časti. Odstránenie Incidentu/Problému je možné dočasne zabezpečiť náhradným riešením Zhotoviteľa alebo organizačným opatrením VO navrhnutého Zhotoviteľom, a to v lehote stanovenej pre náhradné riešenie. Odstránenie vady nesmie mať negatívny vplyv na konzistenciu a integritu dát a výsledky ich spracovania v prostrediach VO.
Incident/Problém úrovne C:bežná vada, bežná porucha, ktorá neobmedzuje prevádzku Systému alebo jeho časti a nemá dôsledky na využívanie a prevádzku IS. Odstránenie Incidentu/Problému nesmie mať negatívny vplyv na konzistenciu a integritu dát a výsledky ich spracovania v prostrediach VO.
Kybernetický bezpečnostný incident:podľa požiadaviek Vyhlášky č. 165/2018, s klasifikáciou incidentov v súlade s Prílohou č. 1. tejto vyhlášky.

7.2.1.3 Lehoty na odstránenie Incidentov a Problémov

Lehoty na odstránenie Incidentov/Problémov sa rozdeľujú nasledovne:

  1. okamžité potvrdenie nahlásenia Incidentu/Problému
  2. lehota reagovania na nahlásený Incident/Problém
  3. lehota náhradného riešenia Incidentu/Problému
  4. lehota trvalého vyriešenia Incidentu/Problému.
Typ lehotyPopis
Okamžité potvrdenie nahlásenia Incidentu/Problémuznamená že VO môže kedykoľvek prostredníctvom vopred dohodnutých elektronických prostriedkov nahlásiť Zhotoviteľovi incident/problém a obratom dostane potvrdenie o doručení hlásenia od Zhotoviteľa.
Lehota reagovania na nahlásený Incident/Problémje čas stanovený pre Zhotoviteľa, do ktorého vykoná prevzatie, potvrdenie prevzatia a preverenie nahláseného Incidentu/Problému a zaháji jeho riešenie konkrétnym riešiteľom a ktorý začína plynúť nahlásením Incidentu/Problému postupom podľa nižšie uvedenej Tabuľky.
Lehota náhradného riešenia Incidentu/Problémuje čas, do ktorého je Zhotoviteľ povinný zabezpečiť, resp. uplatniť náhradné riešenie do IS VO alebo VO vykonať procesné opatrenia navrhnuté Zhotoviteľom. Náhradným riešením sa rozumie vykonanie súboru opatrení Zhotoviteľom, ktoré do doby pre trvalé vyriešenie Incidentu/Problému sfunkčnia IS alebo jeho časť. Pokiaľ sa jedná o procesné opatrenia VO, Zhotoviteľ je povinný včas dodať VO zdokumentovaný proces opatrení tak, aby VO mohol s prihliadnutím na charakter opatrení vykonať Zhotoviteľom navrhnuté opatrenia v lehote náhradného riešenia, ktoré nesmie byť dlhšie ako 20 pracovných dní v produkcii.
Lehota trvalého vyriešenia Incidentu/Problémuje čas, do ktorého je Zhotoviteľ povinný zabezpečiť, resp. uplatniť trvalé odstránenie Incidentu/Problému IS alebo jeho časti tak, aby systém resp. funkčnosť jeho jednotlivých častí, bol plne obnovený.

V nasledujúcej tabuľke sú uvedené číselné hodnoty jednotlivých lehôt:

Úroveň incidentuLehota reagovania na nahlásený incidentLehota náhradného riešenia incidentuLehota trvalého vyriešenia incidentu
Incident úrovne Ado 1 hodinyZ titulu definície Incidentu úrovne A sa neuplatňujedo 24 hodín
Incident úrovne Bdo 4 hodinydo 24 hodíndo 48 hodín
Incident úrovne Cdo 24 hodín pracovného času*Z titulu definície Incidentu úrovne C sa neuplatňujedo 5 dní pracovného času*

V nasledujúcej tabuľke sú uvedené Lehoty na odstránenie Problémov pre jednotlivé úrovne Problémov

Úroveň problémuLehota reagovania na nahlásený ProblémLehota náhradného riešenia ProblémLehota trvalého vyriešenia Problém
Problém úrovne Ado 8 hodínZ titulu definície Incidentu úrovne A sa neuplatňujedo 48 hodín
Problém úrovne Bdo 18 hodíndo 48 hodíndo 72 hodín
Problém úrovne Cdo 24 hodín pracovného času*Z titulu definície Incidentu úrovne C sa neuplatňujedo 96 hodín pracovného času*

* Pozn.: pracovným časom sa rozumie doba vymedzená počas pracovných dní v čase od 0:00 do 0:00 hod.

Počítanie lehôt na odstraňovanie Incidentov/Problémov v rámci pracovného času sa uplatňuje výlučne pri Incidentoch/Problémoch úrovne C. Lehoty na odstraňovanie Incidentov/Problémov úrovne A a Incidentov/Problémov úrovne B plynú bez ohľadu na pracovný čas bez prerušenia (nonstop v režime 24/7).

7.2.1.4 Vykonanie pravidelnej profylaktiky na týždennej báze

Prostredníctvom tejto podpornej činnosti zabezpečuje Zhotoviteľ aj pravidelnú profylaktiku prostredí IS na týždennej báze. Ďalej vykonáva sledovanie logov jednotlivých komponentov, identifikuje abnormálne správanie, monitoruje plánované / schedulované procesy pre spracovanie a publikovanie dát, sleduje výkonové parametre, identifikuje Incidenty a Problémy. Spôsoby a procesy pre efektívne monitorovanie prevádzky s cieľom čo najrýchlejšej identifikácie Incidentov a Problémov navrhne Zhotoviteľ počas poskytovania služby, pričom musia byť v čo najväčšej miere využité interné nástroje VO.

Rozsah profylaktických činnosti a postupov pre jej vykonanie je určený v prevádzkovej dokumentácii k IS. Pozostáva najmä z týchto činností a výstupov:

Report: Zhotoviteľ je povinný pravidelne dodať k poslednému dňu kalendárneho mesiaca prostredníctvom nástroja na riadenie incidentov

Výstup: ako podklad pre zostavenie reportu z profylaktickej činnosti môže byť jeden alebo viac dokumentov. Výstup obsahuje minimálne tieto náležitosti:


    • osoby, ktoré vykonali profylaktiku
    • obdobie, na ktoré sa vzťahuje výkon profylaktiky
    • zoznam kontrolovaných častí IS vo forme checklistu, ktorý obsahuje minimálne:
      • názov kontrolovanej časti systému s identifikáciou prostredia VO
      • identifikátor prevádzkového postupu z prevádzkovej dokumentácie (Profylaktikou sa môže doplniť/upresniť prevádzkový postup, pokiaľ je zistený nesúlad)
      • forma vykonania činnosti (napr. TEST/Overenie prevádzkového postupu/Vizuálna kontrola/...)
      • zistený stav – je skutočný stav zmeraný/zistený a dostatočne popísaný kontrolovanej časti systému počas vykonania profylaktiky.
      • limitná hodnota – je maximálna prípustná hodnota/opísaný stav kontrolovanej časti správania sa IS, ktorá/ý umožňuje správnu prevádzku systému. Limitné hodnoty sú súčasťou aj prevádzkovej dokumentácie (Profylaktikou sa môžu doplniť/upresniť )
      • prekročené alebo kritické limitné stavy/správanie sa Systému budú farebne odlíšené.
      • označenie, či je alebo nie je vyhodnotené správanie sa časti IS za kritické
      • odkaz na zdroj (podklad pre vykonanie profylaktiky, napr. logy, výpis chybových hlásení z databázy, schedulované procesy, zdroj pre zmerané výkonnostné parametre ..)
      • sumarizáciu kontrolovanej časti IS , ktorý obsahuje najmä:
        • upozornenia na možné zlepšenia a úpravy alebo zmeny IS,
        • zoznam zaevidovaných incidentov do nástroja na riadenie incidentov Zhotoviteľa vzniknutých počas výkonu Profylaktiky,
        • identifikované abnormálne stavy alebo správanie sa častí, pri ktorých môže dôjsť, resp. ktoré môžu viesť k vzniku akýchkoľvek Incidentov alebo Bezpečnostných incidentov,
        • zoznam identifikátorov tých prevádzkových postupov z prevádzkovej dokumentácie, ktorých sa dotkla zmena počas výkonu Profylaktiky
        • zoznam doplnených nových prevádzkových postupov s identifikátorom ktoré boli doplnené počas výkonu Profylaktiky.

7.2.1.5 Základné činností poskytované v rámci služieb



      1. Klasifikácia – výstupom je:
        1. odsúhlasenie klasifikácie služby (Incident/Problém), resp.
        2. návrh na preklasifikovanie služby
        3. odsúhlasenie kategórie úrovne Incidentu/Problému, resp.
        4. návrh na preklasifikovanie kategórie
      2. Analýza – preskúmanie, diagnostika a návrh riešenia – výstupom je:
        1. návrh náhradného riešenia (úroveň B) a/alebo trvalého vyriešenia (úrovne A, B, C) s analýzou dopadov (kvalifikovaný odhad termínov)
        2. dodanie úspešných výsledkov testov k navrhovaným riešeniam, security review v zmysle metodiky SDL a potrebnej dokumentácie
        3. požiadavka na potrebu zásahu prostredníctvom vzdialeného prístupu Zhotoviteľa do IS VO
        4. rozsah požadovanej súčinnosti VO
      3. Vyriešenie Incidentu/Problému, resp. dočasná obnova prevádzky Systému (jeho časti) – výstupom je:
        1. dodanie a kontrola releasu (Fix, HotFix..)
        2. nasadenie releasu
        3. funkčný test a security review
        4. obnova, resp. dočasná obnova prevádzky
        5. trvalé vyriešenie Incidentu/Problému (úrovne A, B, C) alebo náhradné riešenie Incidentu/Problému (úroveň B)

V prípade, že pri vykonávaní funkčného testu a security review VO zistí, že Incident/Problém stále trvá, tak táto požiadavka na službu zo strany Objednávateľa bude klasifikovaná ako nevyriešená. Čas nahlásenia požiadavky na službu ostáva pôvodný a všetky časové termíny sa pripočítajú k času od doručenia oznámenia VO o trvaní Incidentu/Problému.

Školenie, zmenové príručky a dokumentácia

V prípade mimoriadnej opodstatnenej potreby priamo súvisiacej s riešením konkrétneho Incidentu/Problému Zhotoviteľ zabezpečí vyškolenie oprávnených zamestnancov VO na nové funkcionality v rámci vyriešenia Incidentu/Problému v adekvátnom časovom termíne. V tomto prípade sa osobitná odmena za školenie neposkytuje, je súčasťou ceny za Paušálne služby.

Ak pri odstraňovaní Incidentu alebo Problému dôjde ku modifikácii postupov správy, inštalácie alebo používania akejkoľvek časti funkcionality Systému, Zhotoviteľ spolu s dodaním riešenia je povinný zabezpečiť pri odovzdávaní riešenia aj dodanie aktualizovanej administrátorskej a prevádzkovej dokumentácie so zaznamenaním vykonaných zmien. Rovnako je povinný Zhotoviteľ udržiavať aktuálnu a poskytnúť VO komplexnú aktualizovanú dokumentáciu

Dokumentácia k jednotlivým plneniam sa odovzdáva priebežne do centrálneho repozitára dokumentácie (wiki) určeného Objednávateľom.

7.2.1.6 Report (výkaz) k poskytnutým službám

Minimálne obsahové náležitosti reportu pre službu riešenia Incidentov/Problémov:

  1. jednoznačný identifikátor Incidentu/Problému
  2. názov Incidentu/ Problému
  3. zoznam riešiteľov
  4. skutočné lehoty jednotlivých plnení

Minimálne obsahové náležitosti reportu pre službu profylaktiky:


    1. zoznam dokumentov z profylaktických činností s označením jedinečnej verzie
    2. obdobie, na ktoré sa vzťahuje výkon z profylaktickej činností
    3. autor dokumentu za Zhotoviteľa
    4. dátum akceptácie jednotlivých dokumentov
    5. vlastník dokumentu za VO, ktorý akceptoval príslušný dokument

Minimálne obsahové náležitosti reportu pre službu riešenia Kybernetických bezpečnostných incidentov (v zmysle požiadaviek Vyhlášky č. 165/2018, par. 2):

  1. jednoznačný identifikátor Incidentu
  2. názov Incidentu
  3. kontaktné údaje osoby ktorá incident nahlásila
  4. skutočné lehoty jednotlivých plnení
  5. časové údaje priebehu kybernetického bezpečnostného incidentu
  6. detailný opis priebehu kybernetického bezpečnostného incidentu
  7. rozsah vzniknutých škôd z dôvodu kybernetického bezpečnostného incidentu
  8. konkrétny popis všetkých zasiahnutých aktív
  9. vplyv kybernetického bezpečnostného incidentu na poskytovanú službu
  10. stav riešenia kybernetického bezpečnostného incidentu
  11. vykonané nápravné opatrenia
  12. popis následkov kybernetického bezpečnostného incidentu
  13. zoznam riešiteľov

7.3 Služby rozvoja / objednávkové služby

V rámci prevádzky IS bude možné realizovať aj jeho zmeny a to také, ktoré vyplynú z prevádzkových skutočností a neboli predmetom dodávky diela.

„Objednávkové služby“ sú Služby prostredníctvom, ktorých zabezpečuje Poskytovateľ na základe požiadaviek Objednávteľa rozvoj Informačného systému prostredníctvom zmien, pričom predmetom objednávkových služieb môžu byť práce na úprave alebo rozvoji dodaného Informačného systému, vrátane úpravy existujúcich integračných služieb a dopracovania integračných služieb, ktoré neboli predmetom prvotnej dodávky.

Nižšie uvedený zoznam činností si vyhradzuje VO upraviť podľa nastavených procesov prostredníctvom nástroja na riadenie Požiadaviek na zmenu, ktoré sú prispôsobované k efektívnemu riadeniu procesov podľa potrieb VO.

7.3.1 Zoznam činností, ktoré sú predmetom objednávkových služieb

  1. Na špecifikáciu a kategorizáciu Požiadaviek na zmenu bude používaný jednotný formulár, prostredníctvom ktorého VO špecifikuje rozsah zmien v ISVS.
  2. Na základe VO vyplneného a doručeného formulára pre Objednávkové služby Dodávateľ potvrdí VO oboznámenie sa s požiadavkami a navrhne časový harmonogram pre vypracovanie činnosti Vypracovanie Analýzy dopadov (vrátane posúdenia vplyvu na bezpečnosť) a cenovej ponuky. Dodávateľ má právo požiadať VO o doplnenie informácií slúžiacich k úplnému porozumeniu Požiadaviek na zmenu počas lehoty stanovenej pre činnosť č. 1. Lehota pre činnosť č. 1 Posúdenie špecifikácie a kategorizácie Požiadaviek na zmenu je 5 pracovných dní.
  3. Predpokladom pre zahájenie činnosti č. 2 je odsúhlasenie činnosti č. 1 VO.
  4. Vypracovanie a schválenie Analýzy dopadov a cenovej ponuky
    1. Na základe VO vyplneného a doručeného formulára pre Objednávkové služby Dodávateľ doplní formulár pre Objednávkové služby, ktorý Dodávateľ doručí podľa dohodnutého harmonogramu VO a ktorý bude obsahovať podrobný návrh riešenia vrátane analýzy dopadov, registra kvality,  cenovej ponuky a predpokladaného harmonogramu prác s uvedením navrhovanej doby poskytnutia Objednávkových služieb a plán ich realizácie. Súčasťou plánu realizácie Objednávkových služieb bude špecifikácia akceptačných testov a ostatných požadovaných vyplnení pre Dodávateľa.
    2. Po doručení formulára VO je tento povinný zapísať pripomienky do formulára a doručiť ich v lehote do 10 pracovných dní odo dňa doručenia formulára VO alebo v rovnakej lehote schváliť Analýzu dopadov a cenovú ponuku vyplývajúce z doručeného formuláru bez výhrad. V prípade márneho uplynutia uvedenej lehoty sa považuje Analýza dopadov a cenová ponuka za schválenú zo strany VO v plnom rozsahu a bez výhrad a slúži ako podklad pre rozhodnutie k objednaniu Objednávkových služieb.
    3. Dodávateľ je povinný do 10 pracovných dní pripomienky odborne posúdiť a upraviť Analýzu dopadov a cenovú ponuku v súlade so vznesenými pripomienkami. V prípade, ak nie je možné niektorú z pripomienok VO akceptovať, Dodávateľ túto skutočnosť bezodkladne písomne oznámi VO aj s príslušným odôvodnením, v ktorom náležite preukáže rozpor pripomienky s konkrétnou Požiadavkou na zmenu alebo inú relevantnú skutočnosť, ktorá odôvodňuje nezapracovanie pripomienky VO.
    4. VO je povinný do 7 pracovných dní od dodania Analýzy dopadov a cenovej ponuky po zapracovaní pripomienok preveriť spôsob zapracovania pripomienok a schváliť Analýzu dopadov a cenovú ponuku alebo v prípade nesúhlasu v uvedenej lehote zaslať svoje stanovisko Dodávateľovi; v prípade márneho uplynutia uvedenej lehoty sa považuje Analýza dopadov a cenová ponuka za schválenú zo strany VO a slúži ako podklad pre rozhodnutie k objednaniu Objednávkových služieb.
    5. Po schválení Analýzy dopadov a cenovej ponuky predloží Dodávateľ Analýzu dopadov a cenovú ponuku na schválenie VO.
    6. Ak nedôjde k schváleniu Analýzy dopadov a cenovej ponuky postupom podľa tohto bodu činnosti č. 2, o ďalšom postupe záväzne rozhodne VO.
  5. Objednanie realizácie Objednávkových služieb
    1. Objednávka realizácie Objednávkových služieb je možná len na základe predchádzajúceho rozhodnutia VO o schválení Analýzy dopadov a cenovej ponuky.
    2. VO je oprávnený doručiť Dodávateľovi písomnú záväznú objednávku najneskôr do 3 mesiacov odo dňa schválenia Analýzy dopadov a cenovej ponuky ak nebude dohodnuté inak.
  6. Realizácia Objednávkových služieb
    1. K začatiu realizácie Požiadavky na zmenu dôjde až po zaslaní písomnej objednávky VO.
    2. VO a Dodávateľ určia kontaktné osoby zodpovedné za realizáciu Požiadavky na zmenu.
    3. Dodávateľ navrhne detailný plán realizácie Požiadavky na zmenu s definovaním vlastníkov jednotlivých plnení, vrátane definovania požiadaviek na súčinnosť VO a s návrhom termínov plnení jednotlivých úloh vrátane plánu akceptačných testov. VO schvaľuje detailný plán realizácie.
    4. Dodávateľ pravidelne raz týždenne poskytuje odpočet plnenia realizácie zmeny podľa odsúhlaseného detailného plánu realizácie zmeny VO.
  7. Otestovanie zmeny Dodávateľom
    1. Dodávateľ sa zaväzuje otestovať implementovanú zmenu na vlastných vývojových prostriedkoch  a vykonať bezpečnostné posúdenie zmeny, vrátanie dodania security review podľa SDL metodiky rozsahu v odsúhlasenom VO pred vykonaním záverečných akceptačných testov
    2. Dodávateľ sa zaväzuje dodať výsledky testov a výsledky security review VO.
    3. Dodávateľ sa zaväzuje overiť dodržanie štandardov pre ISVS/ITVS
  8. Limity vád pre akceptáciu Objednávkovej služby
    1. Limity vád pre akceptáciu Objednávkovej služby:
Kategória VadyPopisPovolený počet defektov
KritickáVady s dopadom na základné funkcionality ISVS, ktorý by v prípade výskytu v produkčnom prostredí znemožnil prevádzku ISVS alebo jeho časti,  alebo spôsobil chybnú funkčnosť ISVS alebo jeho časti. V prípade výskytu sa zastavuje testovanie.0
NormálnaVady s nepodstatným dopadom na prevádzku ISVS, ktorý by v prípade výskytu v produkčnom prostredí nespôsobil chybnú funkčnosť ISVS alebo jeho časti.  Nemá dopad na testovanie.3
  1. Zmenové príručky a dokumentácia
    1. Ak pri realizácií Požiadavky na zmenu dôjde ku modifikácii postupov správy, inštalácie alebo používania akejkoľvek časti funkcionality ISVS, Dodávateľ spolu s dodaním riešenia je povinný zabezpečiť pri odovzdávaní riešenia aj dodanie aktualizovanej dokumentácie so zaznamenaním vykonaných zmien. Rovnako je povinný Dodávateľ udržiavať aktuálnu a poskytnúť VO aktualizovanú komplexnú dokumentáciu (vrátane zdrojových kódov (ak je relevantné), detailných dizajnov, dátového modelu a inej dokumentácie, ktoré sú neodmysliteľnou súčasťou ISVS).
    2. Dokumentácia k jednotlivým plneniam sa odovzdáva priebežne do centrálneho repozitára dokumentácie.
  2. Školenie

V prípade mimoriadnej opodstatnenej potreby priamo súvisiacej s riešením konkrétneho Incidentu/Problému Dodávateľ zabezpečí vyškolenie oprávnených zamestnancov VO na nové funkcionality v rámci vyriešenia Incidentu/Problému v adekvátnom časovom termíne. V tomto prípade sa osobitná odmena za školenie neposkytuje, je súčasťou ceny za Paušálne služby.


8.Požiadavky na personál

Uvedené v rámci Projektové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