Základní ustanovení

II.

Základní ustanovení

1. Tato smlouva je uzavřena v části B dle § 2586 a násl. a části C dle § 1746 odst. 2 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“); práva a povinnosti stran touto smlouvou neupravená se řídí příslušnými ustanoveními občanského zákoníku.

2. Smluvní strany prohlašují, že údaje uvedené v čl. I této smlouvy jsou v souladu se skutečností v době uzavření smlouvy. Smluvní strany se zavazují, že změny dotčených údajů oznámí bez prodlení písemně druhé smluvní straně. Při změně identifikačních údajů smluvních stran včetně změny účtu není nutné uzavírat ke smlouvě dodatek.

3. Je-li zhotovitel plátcem DPH, prohlašuje, že bankovní účet uvedený v čl. I odst. 2 této smlouvy je bankovním účtem zveřejněným ve smyslu zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „zákon o DPH“). V případě změny účtu zhotovitele je zhotovitel povinen doložit vlastnictví k novému účtu, a to kopií příslušné smlouvy nebo potvrzením peněžního ústavu; je-li zhotovitel plátcem DPH, musí být nový účet zveřejněným účtem ve smyslu předchozí věty.

4. Účelem této smlouvy je zajištění uceleného a vysoce spolehlivého řešení ukládání, řízení a správy dokumentů v rámci jednotlivých tenantů dle čl. III. odst. 2 této smlouvy, tj. zejm. nemocnic zřízených či založených objednatelem, se současnou centralizovanou správou v rámci multitenantního systému, a vytvoření podpory pro řešení potřeb jednotlivých zdravotnických zařízení u všech subjektů pod jednotným multitenantním dokument management systémem.

Cílem je zjednodušení stávající administrace a přístupu k dokumentům a zvýšení úrovně bezpečnosti informací při práci s dokumenty, včetně podpory řízení kybernetické bezpečnosti s postupným vytvořením „bezpapírové nemocnice“, při zajištění vysoké dostupnosti celého řešení a služeb technické podpory.

5. Smluvní strany prohlašují, že osoby podepisující tuto smlouvu jsou k tomuto jednání oprávněny.

6. Zhotovitel prohlašuje, že je odborně způsobilý k zajištění předmětu plnění podle této

smlouvy.

7. Zhotovitel dále prohlašuje, že jím poskytované plnění odpovídá všem požadavkům vyplývajícím z platných právních předpisů, které se na plnění vztahují.

8. Xxxxxxxxxx bere na vědomí, že objednatel, resp. uživatel, byl v souladu se zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících předpisů, ve znění pozdějších předpisů (dále jen „ZKB“), určen jako provozovatel informačního systému základní služby, anebo se předpokládá, že bude určen, proto se zhotovitel uzavřením smlouvy stane jeho významným dodavatelem dle § 2 písm. n) vyhlášky č. 82/2018 Sb.,

o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů (dále jen „VKB“). Objednatel je tudíž povinen dle VKB provádět pravidelnou analýzu rizik, identifikovat rizika a identifikovaná rizika řídit. Zhotovitel je při poskytování plnění rovněž povinen zohlednit analýzu bezpečnostních rizik ve smyslu ZKB. Pro všechny výstupy je dále požadována vysoká připravenost na novou legislativu, a to ve vazbě na směrnici Evropského parlamentu a Rady (EU) 2022/2555 o opatřeních k zajištění vysoké společné úrovně kybernetické bezpečnosti v Unii (směrnice NIS2). V případě, že v průběhu plnění této smlouvy nabude platnosti a účinnosti národní legislativa implementující směrnici NIS2, požaduje se plná shoda výstupů s novou legislativou.

9. Zhotovitel dále bere na vědomí, že uživatelé v rámci řízení změn v systému řízení kybernetické bezpečnosti budou přezkoumávat možné dopady změn a určovat významné změny dle VKB, a to dle následujících pravidel.

9.1. Všechny změny, které ovlivňují provoz dodávaných služeb a aplikací musí být řízeny a projednány s uživateli. uživatelé společně se zhotovitelem přezkoumávají možné dopady změn.

9.2. uživatelé určují, zdali se jedná o významnou změnu. uživatelé schvalují změny.

9.3. Před nasazením významných změn musí být provedena analýza rizik.

9.4. Nasazení významných změn je ze strany zhotovitele předem plánováno a tyto změny jsou před nasazením do produkčního prostředí otestovány zhotovitelem, pokud není s uživateli dohodnut jiný postup. Výsledek testu podléhá schválení Manažerem kybernetické bezpečnosti (dále jen „MKB“) a odpovědným zaměstnancem objednatele (zpravidla se jedná o správce HospitalCloud).

9.5. Před realizaci významné změny jsou zhotovitelem s touto změnou seznámeni všichni dotčení zaměstnanci uživatelů.

9.6. Před nasazením každé změny do infrastruktury poskytovaných služeb a aplikací jsou zhotovitelem vypracovány nouzové postupy:

- pro případ neúspěšných nasazení změn a nepředvídaných událostech;

- pro přerušení změn a obnovení po neúspěšných změnách a nepředvídaných událostech (navrácení do původního stavu).

9.7. Pokud se jedná o významnou změnu, je po její úspěšné implementaci provedeno penetrační testování, které zajistí objednatel prostřednictvím třetí osoby. Výsledky penetračních testů musí být vedeny jako dokumentovaná informace.

9.8. O všech změnách musí být zhotovitelem zpracován a uchován záznam, který obsahuje všechny důležité a relevantní informace.

ČÁST B SMLOUVA O DÍLO

III.

Předmět smlouvy

1. Zhotovitel se touto smlouvou zavazuje na své náklady a nebezpečí pro objednatele provést dílo spočívající v dodávce a implementaci jádra a aplikaci elektronických procesů jednotného multitenantního dokument management systému, včetně operačních systémů, databází a dalších licencí třetích stran, které systém bude využívat (dále také „DMS“) pro objednatele a uživatele uvedené v čl. III. odst. 2 této smlouvy, tj. dodání a instalaci příslušného softwarového vybavení (dále též „systém“).

2. Systém bude zajišťovat elektronizaci a rozvoj elektronického oběhu dokumentu ve všech jeho fázích dle požadavků specifikovaných v příloze č. 1 této smlouvy, u těchto subjektů:

a) Nemocnice Havířov, příspěvková organizace,

b) Nemocnice ve Frýdku-Místku, příspěvková organizace,

c) Nemocnice Karviná-Ráj, příspěvková organizace,

d) Sdružené zdravotnické zařízení Krnov, příspěvková organizace,

e) Slezská nemocnice v Opavě, příspěvková organizace,

f) Nemocnice Třinec, příspěvková organizace,

g) Bílovecká nemocnice, akciová společnost

h) Zdravotnická záchranná služba Moravskoslezského kraje, příspěvková organizace,

i) Moravskoslezské datové centrum, příspěvková organizace, dále také „MSDC“ (pro vybrané části)

(dále jen „uživatel“ či „uživatelé“, nebo „uživatelský tenant“)

3. Centrální část systému bude instalována a provozována na HW prostředcích umístěných v budově Integrovaného bezpečnostního centra Moravskoslezského kraje (dále jen „IBC MSK“) na adrese Xxxxxxxxxx 00, 000 00 Xxxxxxx a souvisejících systémových prostředcích.

4. Dílo bude realizováno v následujících fázích (částech):

Část 1 – Implementační projekt

Obsahem Implementačního projektu minimálně bude:

● Implementační analýza stávajícího prostředí uživatelů

● Detailní popis cílového stavu (instalační, implementační a konfigurační upřesnění návrhu řešení z nabídky)

● Projektové řízení s popisem projektové metodologie pro realizaci předmětu plnění ze strany zhotovitele a jeho případných podzhotovitelů (harmonogram, projektový tým, koordinační mechanismy apod.).

● Návrh zálohování a obnovy (disaster recovery plan) s využitím služby krajské korporace (blíže popsaná v příloze č.1 – Technická specifikace díla v části 2.1)

● Popis testovacích scénářů, a to zejména pro provedení následujících testů:

a) funkční testy,

b) zátěžové testy,

c) penetrační testy (penetrační testy však bude provádět třetí osoba mimo organizaci zhotovitele; zhotovitel bude povinen poskytovat součinnost a eliminovat zjištěné zranitelnosti),

s návrhem jednotlivých akceptačních protokolů.

● Exit plán – popis nutných kroků pro naplnění exit plánu, včetně popisu datových struktur (pro strojově čitelná data) související s migrací dat.

Část 2 – Dodávka SW, Implementace

● Multitenantní DMS, multilicence s licencí pro office online prostředí pro všechny uživatele (náhled) v prostředí online office včetně operačních systémů, databází a dalších licencí třetích stran

● Licence pro office online prostředí pro všechny editory (editaci dokumentů) (dle počtů uvedených v příloze č. 1 této smlouvy, tabulce č. 2)

● Instalace DMS – instalace SW do virtuálního prostředí, konfigurace, nastavení prostředí jednotlivých tenantů multitenantního jádra dokument management systému v požadované architektuře

● Integrace – se systémy:

a) Active Directory, LDAP (Třinec)

b) DESA, edice DEA (důvěryhodný archiv)

c) IDM – (AC Identita) - organizační struktury

d) Registr smluv

● API („Application Programming Interface“)- API pro komunikaci s ERP a API pro předávání dat ze systému OCR (nezbytnou součinnost třetích stran zajistí objednatel prostřednictvím uživatelů)

● Aplikace elektronických procesů I. etapa:

a) Řízená dokumentace organizací

b) Schválení žádanky o přepravu

c) Aplikace životního cyklu správy bezpečnostní dokumentace

d) Aplikace pro podporu řízení kybernetických rizik

● Migrace dat – Import stávající platné řídící a bezpečnostní dokumentace do DMS

● Testovací provoz – v rámci testovacího provozu budou probíhat školení, testování

Část 3 – Školení

Část 4 – Dokumentace

Dokumentace v relevantním rozsahu vyplývajícím z předmětu plnění v rozsahu:

● Dokumentace k centrálnímu DMS – vypracování a předání kompletní

dokumentace

● Dokumentace pro školení

● Architektonická dokumentace

Část 5 – Akceptační testy

Podrobná specifikace díla (jednotlivých jeho částí) je uvedena v příloze č. 1 této smlouvy. Po dokončení díla je zhotovitel povinen poskytovat služby technické podpory dle části C této smlouvy (odst. 4.6. přílohy č. 1 této smlouvy: část 6 – Technická podpora)

5. Součástí předmětu plnění dodávaného zhotovitelem je též poskytnutí všech dokladů a návodů v českém jazyce, které se k dodávanému software vztahují, a zajištění veškerých prací a služeb nezbytných pro řádné a úplné zprovoznění díla.

Autorská práva, licence

6. Součástí předmětu plnění je poskytnutí práva na užití veškerého software, který je součástí díla (licence), tak aby byla zajištěna 100% funkčnost a provozuschopnost systému dle podmínek stanovených touto smlouvou. Licencí se rozumí oprávnění objednatele (uživatelů) k výkonu práva duševního vlastnictví k software a užití software pro potřeby objednatele a uživatelů. Objednatel/uživatel je oprávněn na základě udělené licence software užít v územně neomezeném rozsahu po dobu trvání majetkových práv autora software. Odměna za poskytnutí licence je součástí ceny uvedené v čl. IV této smlouvy. Odpovědnost za neoprávněný zásah do autorských i jiných práv třetích osob nese výlučně dodavatel.

7. Z pohledu licenční politiky je požadováno, aby byl poskytnut pro DMS licenční model, který je označován jako „multilicence“, tedy bez dalšího dílčího licenčního omezení pro jednotlivé tenanty a případná licence pro office online prostředí, pokud nebude office online prostředí licencováno v rámci DMS, pro všechny editory pro editaci dokumentů a pro všechny uživatele pro náhled v prostředí online office včetně poskytované podpory.

8. Vzhledem k tomu, že součástí plnění dle této smlouvy je i plnění, které může naplňovat znaky autorského díla ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů (dále jen „autorský zákon“), je k těmto součástem plnění poskytována licence za podmínek sjednaných dále v tomto článku této smlouvy.

a) Objednatel je oprávněn veškeré součásti plnění považované za autorské dílo ve smyslu autorského zákona (dále jen „Autorské dílo“) užívat dle níže uvedených podmínek.

b) Objednatel je oprávněn Autorské dílo užívat dle níže uvedených licenčních podmínek (dále jen „Licence“), a to od okamžiku účinnosti poskytnutí Licence, přičemž zhotovitel poskytuje objednateli Licenci s účinností, která nastává okamžikem předání plnění či jeho části, jehož je Autorské dílo součástí.

c) Licence je udělena jako nevýhradní, neomezeně přenositelná k užití Autorského díla objednatelem k jakémukoliv účelu a v rozsahu, v jakém uzná za nezbytné, vhodné či přiměřené. Pro vyloučení všech pochybností to znamená, že:

- Licence je udělena jako neodvolatelná;

- Licence je dále udělena na dobu určitou, a to po celou dobu trvání majetkových práv autorských k Autorskému dílu, bez omezení územního rozsahu;

- jde-li o licenci k SW, je SW dodán jako opakovaně aktivovatelný, bez nutnosti jakékoli další úhrady;

- jde-li o licenci k SW, je objednatel v případě potřeby oprávněn sám a bezplatně provádět modifikaci konfigurace SW v plném rozsahu a jsou mu zpřístupněny všechny dostupné funkcionality;

- v případě SW, který je součástí plnění, se Licence vztahuje ve stejném rozsahu i na případné další verze tohoto SW upraveného na základě této smlouvy;

- Objednatel je bez potřeby jakéhokoliv dalšího svolení zhotovitele oprávněn udělit třetí osobě podlicenci k užití Autorského díla nebo svoje oprávnění k jejímu užití třetí osobě postoupit;

- Licenci není objednatel povinen využít, a to ani zčásti;

- Licence umožňující objednateli systém uživatelsky upravovat, pokud nebude nutné zasahovat do zdrojového kódu (tj. např. úprava formulářů, modifikace dle konkrétní činnosti/procesu apod.)

9. Současně zhotovitel uděluje objednateli souhlas ode dne účinnosti poskytnuté Licence dle

této smlouvy provádět jakékoliv modifikace, úpravy, změny Autorského díla a dle svého uvážení do něj zasahovat, zapracovávat jej do dalších autorských děl, zařazovat jej do děl souborných či do databází apod., a to i prostřednictvím třetích osob.

10. V souvislosti s poskytnutou Licencí je zhotovitel povinen, s výjimkami uvedenými v odst. 11 a 12 tohoto článku této smlouvy, nejpozději ke dni ukončení akceptace díla či jeho části předat objednateli zdrojový kód každé jednotlivé části Autorského díla, která je počítačovým programem, a která je objednateli poskytována na základě plnění dle této smlouvy jako customizované plnění, aby s ním mohl objednatel libovolně nakládat. Pro účely této smlouvy se customizovaným plněním rozumí veškerá řešení vč. jejich úpravy dle požadavků objednatele. Zdrojový kód musí být spustitelný v prostředí objednatele a zaručovat možnost ověření, že je kompletní a ve správné verzi, tzn. umožňující kompilaci, instalaci, spuštění a ověření funkcionality, a to včetně podrobné dokumentace zdrojového kódu. Zdrojový kód bude objednateli zhotovitelem předán na nepřepisovatelném technickém nosiči dat s viditelně označeným názvem „Zdrojový kód“ a označením počítačového programu či její části a jeho verze a dne předání zdrojového kódu. O předání technického nosiče dat bude oběma smluvními stranami sepsán a podepsán písemný předávací protokol.

11. Je-li součástí plnění tzv. proprietární software (dále jen „Proprietární software“), u kterého zhotovitel nemůže poskytnout objednateli oprávnění dle odst. 8 až 10 tohoto článku této smlouvy nebo to po něm nelze spravedlivě požadovat, postačí, aby objednatel nabyl k takovému software nevýhradní oprávnění užít jej jakýmkoli způsobem nejméně po dobu trvání této smlouvy, bez územního omezení a v množstevním rozsahu, který je nezbytný pro pokrytí potřeb objednatele ke dni uzavření smlouvy. Smluvní strany výslovně uvádějí, že součástí takového nevýhradního oprávnění není právo provádět jakékoliv modifikace, úpravy či změny Proprietárního software či dle svého uvážení do něj zasahovat, zapracovávat ho do dalších autorských děl, zařazovat ho do děl souborných či do databází apod., a to i prostřednictvím třetích osob, ani se u Proprietárního software nevyžaduje poskytnutí zdrojových kódů k takovému software.

12. Je-li součástí plnění tzv. open source software, u kterého zhotovitel nemůže poskytnout objednateli oprávnění dle odst. 8 až 10 tohoto článku této smlouvy nebo dle odst. 11 tohoto článku této smlouvy nebo to po něm nelze spravedlivě požadovat, je zhotovitel povinen zajistit, aby se jednalo o open source software, který je veřejnosti poskytován zdarma, včetně zdrojových kódů, úplné původní uživatelské, provozní a administrátorské dokumentace a práva takový software měnit a zároveň možnost užití takového software objednatelem k účelu sjednanému smlouvou dle podmínek této smlouvy.

13. Udělení veškerých práv uvedených v tomto článku této smlouvy nelze ze strany zhotovitele vypovědět a na jejich udělení nemá vliv ukončení účinnosti této smlouvy.

14. Zhotovitel prohlašuje, že veškeré jím dodané plnění podle této smlouvy bude prosté právních vad a zavazuje se odškodnit v plné výši objednatele v případě, že třetí osoba úspěšně uplatní autorskoprávní nebo jiný nárok plynoucí z právní vady poskytnutého plnění dle této smlouvy. V případě, že by nárok třetí osoby vzniklý v souvislosti s plněním zhotovitele podle této smlouvy, bez ohledu na jeho oprávněnost, vedl k dočasnému či trvalému soudnímu zákazu či omezení užívání systému či jeho části, zavazuje se zhotovitel zajistit náhradní řešení a minimalizovat dopady takovéto situace, a to bez dopadu na cenu plnění sjednanou podle této smlouvy, přičemž současně nebudou dotčeny ani nároky objednatele na náhradu škody.

15. S nositeli chráněných práv duševního vlastnictví vzniklých v souvislosti s realizací plnění dle

této smlouvy je zhotovitel povinen vždy smluvně zajistit možnost nakládání s těmito právy objednatelem v rozsahu definovaném tímto článkem smlouvy.

16. Zhotovitel podpisem smlouvy výslovně prohlašuje, že odměna za veškerá oprávnění poskytnutá objednateli dle tohoto článku smlouvy je již zahrnuta v ceně díla.

17. Zhotovitel je povinen objednateli uhradit jakékoli majetkové a nemajetkové újmy, vzniklé v důsledku toho, že objednatel nemohl DMS/systém užívat řádně a nerušeně. Jestliže se jakékoliv prohlášení zhotovitele v tomto článku ukáže nepravdivým nebo zhotovitel poruší jinou povinnost dle tohoto článku smlouvy, jde o podstatné porušení smlouvy a zhotovitel je povinen uhradit objednateli smluvní pokutu ve výši 50.000,- Kč za každé jednotlivé porušení povinnosti. Zaplacením smluvní pokuty není nijak dotčeno ani omezeno právo objednatele na náhradu škody, kterou lze vymáhat vedle smluvní pokuty v plné výši.

18. Objednatel se zavazuje od zhotovitele řádně provedené dílo převzít a zaplatit za ně

zhotoviteli dohodnutou cenu.

19. Zhotovitel poskytne objednateli na jeho písemnou žádost veškerou nezbytně nutnou součinnost pro změnu zhotovitele, a to před ukončením této smlouvy nebo její části, tj. v průběhu běhu výpovědní doby i po jejím ukončení, případně bezodkladně po obdržení písemné žádosti objednatele tak, aby byl zajištěn bezproblémový přechod k novému dodavateli (dále jen „Exit plán“). Nezbytně nutná součinnost v rámci Exit plánu bude zahrnovat zejména:

● aktivní spolupráci zhotovitele při migraci dat při přechodu na jiný systém, vč. zajištění exportu v dohodnutém či objednatelem určeném formátu dat,

● nebo pro změnu poskytovatele technické podpory poskytnutí úplné a aktuální provozní dokumentace ke službám technické podpory (dokumentace musí zahrnovat kompletní elektronickou kopii veškeré dokumentace, kterou zhotovitel vytvořil v rámci svého plnění s tím, že bude aktualizována tak, aby odrážela stav služeb podpory k datu ukončení smluvního plnění.

● prokazatelné odstranění případně užívaných dat na HW prostředcích

zhotovitele,

● poskytnout další konzultace objednateli a případnému novému dodavateli (nad rámec shora uvedených povinností) spojené zejména s přípravou nového dodavatele na poskytování technické podpory, a to v rozsahu do 25 člověkohodin; konzultace budou poskytovány na základě písemného vyžádání objednatele.

Objednatel má právo žádost o součinnost učinit kdykoliv po dobu platnosti a účinnosti této smlouvy a zhotovitel je povinen tuto součinnost poskytnout ještě 3 další měsíce po ukončení platnosti této smlouvy či její části. V souvislosti s poskytnutím součinnosti v rámci Exit plánu nenáleží zhotoviteli zvláštní smluvní odměna. Další specifikace Exit plánu ve vazbě na dodávaný systém bude předmětem Implementačního projektu.

IV.

Xxxx za dílo

1. Cena za dílo (části 1 až 5) je stanovena dohodou smluvních stran a činí bez DPH 11.968.340,- Kč (slovy: jedenáct milionů devět set šedesát osm tisíc tři sta čtyřicet korun českých), DPH ve výši 21% je 2.513.351,40 Kč a cena včetně DPH činí 14.481.691,40 Kč

(slovy: čtrnáct milionů čtyři sta osmdesát jedna tisíc šest set devadesát jedna koruna česká čtyřicet haléřů).

Podrobný rozpis ceny za dílo je uveden v příloze č. 2 této smlouvy.

2. Cena podle odst. 1 tohoto článku smlouvy zahrnuje veškeré náklady zhotovitele spojené se splněním jeho závazků vyplývajících z této smlouvy, včetně nákladů na poskytnuté licence a všech dalších souvisejících nákladů. Cena je stanovena jako nejvýše přípustná a není ji možno překročit.

3. Je-li zhotovitel plátcem DPH, odpovídá za to, že sazba daně z přidané hodnoty bude stanovena v souladu s platnými právními předpisy; v případě, že dojde ke změně zákonné sazby DPH, bude zhotovitel k ceně za plnění bez DPH povinen účtovat DPH v platné výši. Smluvní strany se dohodly, že v případě změny ceny za plnění v důsledku změny sazby DPH není nutno ke smlouvě uzavírat dodatek. V případě, že zhotovitel stanoví sazbu DPH či DPH v rozporu s platnými právními předpisy, je povinen uhradit objednateli veškerou škodu, která mu v souvislosti s tím vznikla.

Místo a doba plnění

1. Zhotovitel je povinen provést a odevzdat jednotlivé části díla v místech plnění, kterými jsou

pro:

a) Část 1 díla – Krajský úřad Moravskoslezského kraje, odbor zdravotnictví, 28. října 117,

702 18 Ostrava

b) Části 2, 3, 5 díla budou provedeny u jednotlivých uživatelů ve všech níže uvedených místech plnění:

● Budova IBC MSK, adresa: Xxxxxxxxxx 00, 000 00 Xxxxxxx,

● Nemocnice Havířov, p. o., adresa: Xxxxxxxx 0000/00, 000 00 Xxxxxxx,

● Nemocnice ve Frýdku-Místku, p. o., adresa: El. Krásnohorské 321, 738 01 Frýdek- Místek,

● Nemocnice Karviná-Ráj, p. o., adresa: Xxxxxxxxx 000/0, 000 00 Xxxxxxx,

● Sdružené zdravotnické zařízení Krnov, p. o., adresa: I. P. Pavlova 552/9, 794 01 Krnov,

● Slezská nemocnice v Opavě, p. o., adresa: Xxxxxxxxx 000/00, 000 00 Xxxxx,

● Nemocnice Třinec, p. o., adresa: Xxxxxxxxx 000, 000 00 Xxxxxx,

● Bílovecká nemocnice a.s., adresa: 17. listopadu 538, 743 01 Bílovec

● Zdravotnická záchranná služba Moravskoslezského kraje, příspěvková organizace, Xxxxxxxxxx 0000/00, 000 00 Xxxxxxx, Xxxxxx

● Moravskoslezské datové centrum, p. o., adresa: Xx Xxxxxxxx 0000/0, 000 00 Xxxxxxx

c) Dokumentace dodávaná v rámci části 4 díla bude dodána elektronicky způsobem dohodnutým s objednatelem, a to:

- Dokumentace k centrálnímu DMS a dokumentace pro školení bude dodána všem uživatelům a objednateli

- Architektonická dokumentace bude dodána pouze objednateli

2. Část poskytovaného plnění, jejíž rozsah bude předem písemně odsouhlasen objednatelem

s odkazem na jeho bezpečnostní politiku, může být poskytována dálkovou formou z prostor

zhotovitele.

3. Zhotovitel se zavazuje provést dílo na základě písemné výzvy k plnění objednatele (dále jen „výzva k plnění“). Výzva k plnění bude zaslána osobou oprávněnou jednat za objednatele dle čl. I odst. 1 této smlouvy (příp. xxxxx objednatelem určenou osobou), a to e-mailem na e-mailovou adresu osoby oprávněné jednat za zhotovitele, uvedenou v čl. I odst. 2 této smlouvy. Výzva k plnění bude zhotoviteli zaslána nejpozději do 4 měsíců od účinnosti této smlouvy.

4. Jednotlivé části díla plnění budou provedeny v těchto dílčích termínech:

● Část 1 – Implementační projekt do 1 měsíce ode dne zaslání písemné výzvy k plnění je zhotovitel povinen a předat objednateli Implementační projekt k připomínkám a následné akceptaci (blíže viz čl. VI této smlouvy a odst. 4.1. přílohy č. 1 této smlouvy),

● Část 2 – Dodávka SW, Implementace do 4 měsíců ode dne převzetí plnění dle části 1 objednatelem bez vad a nedodělků,

● Část 3 – Školení do 5 měsíců ode dne převzetí plnění dle části 1 objednatelem bez vad a nedodělků,

● Část 4 – Dokumentace do 5 měsíců ode dne převzetí plnění dle části 1 objednatelem bez vad a nedodělků,

● Část 5 – Akceptační testy do 6 měsíců ode dne převzetí plnění dle části 1 objednatelem bez vad a nedodělků.

5. Dílo je provedeno, je-li dokončeno a předáno objednateli. Smluvní strany se dohodly, že objednatel není povinen dílo převzít, pokud toto vykazuje vady či nedodělky, ledaže se jedná o drobné vady či nedodělky nebránící užívání díla.

Převzetí 1. části díla

VI.

Předání díla, nebezpečí škody

1. Část 1 díla (Implementační projekt) podléhá následující akceptační proceduře:

● před odevzdáním implementačního projektu objednateli k připomínkování proběhne prezentace obsahu návrhu implementačního projektu,

● po předání Implementačního projektu k připomínkování může objednatel zhotoviteli do

5 pracovních dnů, nedohodnou-li se smluvní strany jinak, zapracuje objednatelem uvedené nedostatky a připomínky, předat v písemné podobě své výhrady;

● zhotovitel neprodleně, nejpozději však do 5 pracovních dnů, nedohodnou-li se smluvní strany jinak, zapracuje objednatelem uvedené nedostatky a připomínky;

● proces akceptace lze opakovat, dokud zhotovitel nezapracuje veškeré výhrady vznesené objednatelem;

● doba, po kterou bude objednatel posuzovat odevzdaný návrh Implementačního projektu, se nezapočítává do lhůty plnění podle čl. V odst. 4 odrážka prvá této smlouvy;

● převzetím části 1 díla objednatelem bez vad a nedodělků začíná běžet lhůta plnění pro část 2 až 5 díla.

Převzetí díla

2. Objednatel převezme dílo jako celek, a to bez vad a nedodělků, s výjimkou drobných vad a nedodělků, které nebrání užívání díla, po dokončení akceptační procedury (akceptačních testů). Jednotliví uživatelé budou oprávnění přebírat části plnění za své organizace, a to na základě dílčích akceptačních protokolů. Plnění jako celek bude objednatelem převzato na základě finálního akceptačního protokolu. Součástí finálního akceptačního protokolu budou dílčí akceptační protokoly jednotlivých uživatelů.

3. Účelem finální akceptace je na základě akceptační procedury specifikované v příloze č. 1 této smlouvy ověření funkčnosti a bezchybného provozu systému a veškerého plnění jako celku.

4. Xxxx je provedeno, je-li dokončeno (tj. objednateli je předvedeno, že systém je plně funkční, bez vad a nedodělků, a je způsobilý sloužit svému účelu; proběhlo školení, bylo dodána příslušná dokumentace a došlo k akceptaci a protokolárnímu převzetí všemi uživateli) a předáno objednateli.

5. Ve finálním akceptačním protokolu a v dílčím akceptačním protokolu objednatel (uživatel) prohlásí, zda dílo (jeho příslušnou část) přejímá či nikoli.

6. Pokud dílo (příslušná část díla) nebude převzata, protože obsahuje vady či nedodělky bránící užívání díla, potvrdí tuto skutečnost objednatel (uživatel) v akceptačním protokolu, včetně specifikace vad či nedodělků. Objednatel nebo uživatel je povinen vznést své výhrady nebo připomínky do 5 pracovních dnů. Zhotovitel je povinen do 5 pracovních dnů provést veškeré potřebné úpravy dle výhrad a připomínek a předat příslušnou část plnění uživateli či objednateli k opětovné akceptaci.

7. Dílčí akceptační protokoly uživatelů a finální akceptační protokol budou obsahovat alespoň tyto náležitosti:

a) číslo příslušného akceptačního protokolu a datum jeho vyhotovení, místo vyhotovení,

b) číslo této smlouvy, číslo veřejné zakázky,

c) označení předmětu plnění (či jeho části) včetně označení příslušného uživatele,

d) označení objednatele a zhotovitele,

e) prohlášení objednatele či uživatele, že plnění či jeho část přejímá či nikoliv,

f) v případě, že je dílo přebíráno s drobnými vadami a nedodělky nebránícími řádnému užívání díla, uvedení seznamu drobných vad a nedodělků s uvedením lhůty pro jejich odstranění; nebude-li uvedeno jinak, musí být veškeré drobné vady či nedodělky odstraněny do 15 dnů od převzetí příslušné části díla; drobné vady a nedodělky mohou být na základě dohody stran převedeny do fáze poskytování služeb technické podpory, přičemž pro kategorizaci vad a stanovení lhůt pro jejich vypořádání se uplatní úprava dle části C této smlouvy,

g) jména a podpisy zástupců objednatele (uživatele) a zhotovitele, včetně kontaktních telefonů a e-mailů.

VII.

Platební podmínky

1. Úhrada ceny za dílo (části 1 až 5) bude provedena jednorázově po převzetí díla bez vad a nedodělků bránících jeho řádnému užívání dle čl. VI odst. 2 této smlouvy. Zálohové platby nebudou poskytovány.

2. Je-li zhotovitel plátcem DPH, podkladem pro úhradu ceny za dílo bude faktura, která bude mít náležitosti daňového dokladu dle zákona o DPH a náležitosti stanovené dalšími obecně závaznými právními předpisy. Není-li zhotovitel plátcem DPH, bude podkladem

pro úhradu ceny za dílo faktura, která bude mít náležitosti účetního dokladu dle zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů a náležitosti stanovené dalšími obecně závaznými právními předpisy. Faktura musí dále obsahovat:

a) číslo smlouvy objednatele, IČO objednatele, číslo veřejné zakázky (tj. 69/2023),

b) číslo a datum vystavení faktury,

c) předmět plnění a jeho přesnou specifikaci ve slovním vyjádření (nestačí pouze odkaz na číslo uzavřené smlouvy),

d) označení banky a čísla účtu, na který musí být zaplaceno (pokud je číslo účtu odlišné od čísla uvedeného v čl. I odst. 2, je zhotovitel povinen o této skutečnosti v souladu s čl. II odst. 2 a 3 této smlouvy informovat objednatele),

e) lhůtu splatnosti faktury,

f) označení odboru, který akci likviduje (odbor zdravotnictví),

g) jméno a vlastnoruční podpis osoby, která fakturu vystavila, včetně kontaktního

telefonu.

3. Lhůta splatnosti faktury činí 30 kalendářních dnů ode dne jejího doručení objednateli.

4. Doručení faktury se provede elektronicky prostřednictvím datové schránky 8x6bxsd nebo e-mailu na adresu xxxxx@xxx.xx, doručenkou prostřednictvím provozovatele poštovních služeb, případně osobně na podatelně Krajského úřadu Moravskoslezského kraje. Objednatel preferuje doručení faktury elektronicky. Zhotovitel je povinen doručit fakturu objednateli nejpozději 16. den následující po dni uskutečnění zdanitelného plnění. Nesplní- li zhotovitel tuto povinnost a objednateli v důsledku toho vznikne škoda (např. uhrazením sankcí uložených příslušným správcem daně v důsledku pozdní úhrady DPH objednatelem), bude zhotovitel povinen objednateli tuto škodu v plném rozsahu uhradit.

5. Povinnost zaplatit cenu za plnění je splněna dnem odepsání příslušné částky z účtu

objednatele.

6. Nebude-li faktura obsahovat některou povinnou nebo dohodnutou náležitost nebo bude-li chybně vyúčtována cena nebo DPH, je objednatel oprávněn fakturu před uplynutím lhůty splatnosti vrátit druhé smluvní straně k provedení opravy s vyznačením důvodu vrácení. Zhotovitel provede opravu faktury. Vrácením vadné faktury zhotoviteli přestává běžet původní lhůta splatnosti. Nová lhůta splatnosti běží ode dne doručení opravené faktury objednateli.

7. Je-li zhotovitel plátcem DPH, objednatel uplatní institut zvláštního způsobu zajištění daně dle § 109a zákona o DPH a hodnotu plnění odpovídající dani z přidané hodnoty uvedené na faktuře uhradí v termínu splatnosti této faktury stanoveném dle smlouvy přímo na osobní depozitní účet zhotovitele vedený u místně příslušného správce daně v případě, že

a) zhotovitel bude ke dni uskutečnění zdanitelného plnění zveřejněn v aplikaci „Registr plátců DPH“ jako nespolehlivý plátce, nebo

b) zhotovitel bude ke dni uskutečnění zdanitelného plnění v insolvenčním řízení, nebo

c) bankovní účet zhotovitele určený k úhradě plnění uvedený na faktuře nebude správcem daně zveřejněn v aplikaci „Registr plátců DPH“.

Objednatel nenese odpovědnost za případné penále a jiné postihy vyměřené či stanovené správcem daně zhotoviteli v souvislosti s potenciálně pozdní úhradou DPH, tj. po datu splatnosti této daně.

VIII.

Práva a povinnosti smluvních stran

1. Není-li stanoveno touto smlouvou výslovně jinak, řídí se vzájemná práva a povinnosti

smluvních stran přiměřeně ustanoveními § 2586 a následujícími občanského zákoníku.

2. Objednatel se zavazuje poskytnout zhotoviteli součinnost potřebnou pro realizaci plnění dle této smlouvy.

3. Zhotovitel je zejména povinen:

a) Provést plnění řádně a včas za použití postupů odpovídajících platným právním předpisům, technickým normám ČR a umožňovat užívání, k němuž bylo určeno.

b) Řídit se při provádění plnění pokyny objednatele, poskytnout mu požadované

informace.

c) Umožnit objednateli kontrolu provádění plnění, a to kdykoliv po dobu jeho realizace. Pokud objednatel zjistí, že zhotovitel nerealizuje plnění řádně či jinak porušuje svou povinnost, poskytne zhotoviteli lhůtu k nápravě; neučiní-li tak zhotovitel ve stanovené lhůtě, je objednatel oprávněn od smlouvy odstoupit.

d) Odstranit zjištěné vady a nedodělky plnění na své náklady.

e) Dbát při realizaci plnění dle této smlouvy na ochranu životního prostředí a dodržovat platné technické, bezpečnostní, zdravotní, hygienické a jiné předpisy, včetně předpisů týkajících se ochrany životního prostředí.

f) Postupovat při realizaci plnění s odbornou péčí.

g) Neprodleně písemně vyrozumět objednatele o případném ohrožení doby plnění a o všech skutečnostech, které mohou řádné a včasné plnění předmětu této smlouvy znemožnit, a to neprodleně od okamžiku, kdy se zhotovitel dozví o takové skutečnosti.

h) Alokovat na realizaci této smlouvy pracovní kapacitu osob realizačního týmu uvedeného v nabídce zhotovitele podané ve veřejné zakázce a k plnění této smlouvy využít výhradně osob, kterými byla prokazována kvalifikace v zadávacím řízení na veřejnou zakázku. Jakákoliv dodatečná změna osoby realizačního týmu musí být předem písemně schválena objednatelem. Zhotovitel se v takovém případě zavazuje nahradit osobu realizačního týmu takovou osobou, která disponuje alespoň požadovanými minimálními znalostmi a odbornou kvalifikací dle požadavků objednatele uvedených v zadávací dokumentaci veřejné zakázky. Zhotovitel i osoby podílející se na realizaci této smlouvy musí po celou dobu trvání této smlouvy splňovat kvalifikační kritéria stanovená v zadávací dokumentaci veřejné zakázky. Při porušení této podmínky má objednatel právo odstoupit od smlouvy.

i) Předat objednateli do 5 měsíců od nabytí účinnosti této smlouvy rozpis ceny za plnění s určením samostatných majetků, souborů majetků nebo samostatných funkčních celků za účelem evidence majetku a jeho odepisování dle zákona č. 586/1992 Sb., o daních z příjmů, ve znění pozdějších předpisů a zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů. U odepisování dlouhodobého hmotného a nehmotného majetku bude uveden klasifikační kód CZ-CPA za účelem odepisování dlouhodobého hmotného a nehmotného majetku.

j) Zajistit, aby mohl být systém provozován též jiným subjektem, než je objednatel či uživatelé, např. jiná příspěvková organizace zřízena objednatelem či jiný subjekt, jejímž členem je objednatel případně v něm má majetkovou účast.

k) Práce v budově IBC bude zhotovitel vykonávat po dohodě a v koordinaci s nepřetržitým provozem uživatele a správce této budovy, tj. Česká republika – Hasičský záchranný

IX.

Vlastnosti díla

Zhotovitel se zavazuje k tomu, že celkový souhrn vlastností provedeného díla bude dávat schopnost uspokojit stanovené potřeby, tj. využitelnost, bezpečnost, bezporuchovost, udržovatelnost, hospodárnost. Ty budou odpovídat platné právní úpravě, českým technickým normám, zadávací dokumentaci veřejné zakázky a této smlouvě.

Práva z vadného plnění

1. Dílo má vadu, jestliže neodpovídá požadavkům uvedeným v této smlouvě.

2. Objednatel má právo z vadného plnění z vad, které má dílo při převzetí zhotovitelem, byť se vada projeví až později. Objednatel má právo z vadného plnění také z vad vzniklých po převzetí díla objednatelem, pokud je zhotovitel způsobil porušením své povinnosti. Projeví-li se vada v průběhu 6 měsíců od převzetí díla objednatelem, má se zato, že dílo byla vadné již při převzetí, neprokáže-li zhotovitel opak.

3. Veškeré vady díla je objednatel povinen uplatnit u zhotovitele bez zbytečného odkladu poté, kdy vadu zjistil, a to za použití podmínek uvedených v čl. XIII v části C této smlouvy. K uplatňování vad jsou oprávněni kromě objednatele také uživatelé (každé takovéto nahlášení vady se považuje za řádné uplatnění vady objednatelem ve smyslu této smlouvy).

4. Objednatel má právo na odstranění vady dodáním nové věci nebo opravou; je-li vadné plnění podstatným porušením smlouvy, má také právo od smlouvy odstoupit. Právo volby plnění má objednatel.

5. Neodstraní-li zhotovitel ve stanovené lhůtě (viz čl. XIII odst. 3 této smlouvy) vadu sám, je objednatel oprávněn zajistit odstranění vady třetí osobou, přičemž náklady na odstranění takové vady nese zhotovitel. Ten je povinen uhradit náklady se lhůtou splatnosti 30 dnů po předložení vyúčtování objednatelem. Při výběru této třetí osoby bude objednatel postupovat přiměřeně s péčí řádného hospodáře a takovým způsobem, který je pro odstranění vady díla obvyklý a běžný.

XI.

Sankce

1. V případě prodlení zhotovitele s provedením části 1 díla je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 10.000 Kč, a to za každý započatý den prodlení.

2. V případě prodlení zhotovitele s provedením částí 2, 3, 4 nebo 5 díla je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 0,05 % z ceny za dílo v Kč bez DPH dle čl. IV odst. 1 této smlouvy, a to za každý započatý den prodlení (bez ohledu na to, zda je v prodlení s provedením jedné či více částí díla).

3. V případě prodlení zhotovitele s odstraněním vad či nedodělků předaného (akceptovaného) díla ve lhůtách dle čl. VI odst. 7 písm. f) této smlouvy je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 500 Kč, a to za každou jednotlivou vadu/nedodělek a každý započatý den prodlení. Pokud budou tyto vady a nedodělky převedeny do služeb technické podpory, uplatní se smluvní pokuta dle následujícího odstavce.

4. V případě prodlení zhotovitele s odstraněním vady ve lhůtách stanovených v čl. X odst. 3 této smlouvy je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši stanovené v čl. XVII této smlouvy.

5. V případě porušení jakékoliv povinnosti dle čl. VIII odst. 3 písm. h), l), m), n), o), p) této smlouvy je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 20.000 Kč, a to za každý jednotlivý případ porušení.

6. V případě neodstranění nedostatků či neshod, jejichž odstranění může být objednatelem požadováno v návaznosti na audit kybernetické bezpečnosti ve smyslu čl. VIII odst. 3 písm.

l) této smlouvy a přílohy č. 3 této smlouvy, je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 5.000 Kč, a to za každý započatý den prodlení s jejich odstraněním.

7. Pro případ prodlení se zaplacením ceny za dílo sjednávají smluvní strany úrok z prodlení ve výši stanovené občanskoprávními předpisy.

8. Smluvní pokuty se nezapočítávají na náhradu případně vzniklé škody, kterou lze vymáhat samostatně vedle smluvní pokuty, a to v plné výši.

ČÁST C TECHNICKÁ PODPORA

XII.

Technická podpora

1. Zhotovitel je povinen objednateli poskytovat služby technické podpory pro systém dodaný dle části B této smlouvy a veškerá související plnění a zajistit tak jejich bezproblémový provoz. Bližší specifikace technické podpory je uvedena v příloze č. 1 této smlouvy.

2. Technickou podporou se rozumí:

a) Odstraňování vad a provádění průběžných inovací díla. Výsledkem inovací díla budou nové verze díla, a to buď jako:

● update a upgrade, vzniklý samostatnou inovační činností zhotovitele,

● legislativní update a upgrade, vynucené změnou právních předpisů,

● technologický update a upgrade vzniklý samostatnou inovační činností zhotovitele, zahrnující provádění obecných změn díla v důsledku vývoje HW a SW prostředků, např. z důvodu aktualizace operačního systému, SW platformy, SW/HW komponent, které mají vliv na funkčnost díla aj.

● Poskytnutí součinnosti při identifikaci a hodnocení aktiva – DMS a jeho rizik. Odstranění nalezených „provozních rizik systému“ a to především v oblasti hardeningu systémů a dalších identifikovatelných bezpečnostních rizik.

● Zhotovitel bere na vědomí, že všechny nové verze díla (včetně veškerých nově zakomponovaných funkcionalit), které vznikly v důsledku průběžných inovací díla dle tohoto písmene smlouvy jsou update či upgrade díla. Veškeré náklady na vznik těchto nových verzí díla jsou zahrnuty v ceně technické podpory.

b) Implementace poskytnutých upgrade a update v produkčním prostředí objednatele, včetně upgrade rozhraní díla, je-li to potřebné pro jeho správnou funkčnost. Před provedením jednotlivých upgrade či update ze strany zhotovitele musí vždy proběhnout odsouhlasení ze strany objednatele. Objednatel má právo na odmítnutí upgrade a update. Zhotovitel je v takovém případě povinen písemně upozornit objednatele na veškerá případná rizika související s odmítnutím upgrade či update.

c) Distribuce inovovaných verzí díla objednateli za účelem legislativního update nebo upgrade, která bude provedena v dostatečném předstihu před termínem účinnosti změn příslušných právních předpisů.

d) Poskytnutí nových verzí SW, které jsou součástí díla a jejichž fungování je pro provoz díla nezbytné, v případě vypršení technické podpory jejich výrobce, a to v rámci technologického update a upgrade, který vznikl samostatnou inovační činností zhotovitele. Distribuce inovovaného díla s aktualizovanými verzemi HW a SW dle předchozí věty objednateli proběhne tak, aby byla provedena v dostatečném předstihu před ukončením technické podpory výrobce daného HW či SW.

e) Provádění změn díla za účelem zvyšování úrovně jeho bezpečnosti.

f) Provádění rozdílového seznámení s obsluhou pro uživatele díla, pokud bude potřeba

s ohledem na rozsah upgrade či update v rámci nových verzí díla.

g) Provádění pravidelné údržby díla, která mj. zahrnuje:

● kontrolu funkčnosti provozu všech částí díla (monitoring),

● instalaci a konfiguraci update/upgrade software dodaného v rámci díla,

● kontrolu a případnou úpravu nastavení (konfigurací) v souvislosti s úpravou či optimalizací provozu díla,

● přípravu (aktualizaci) plánu zálohování a obnovy díla v případě výpadku, havárie, či ztráty dat (v součinnosti s objednatelem).

h) V rámci technické podpory jsou zahrnuta také školení v sídle objednatele (pokud se smluvní strany nedohodnou jinak), která budou zaměřena zejména na ovládání a užívání díla v jeho nových verzích po upgrade či update. Smluvní strany prohlašují, že obsah a formu školení dle tohoto písmene si mohou smluvní strany sjednat.

3. Ke každé inovované verzi díla, včetně update, upgrade a legislativního update a upgrade, je zhotovitel povinen dodat seznam a popis změn a úprav (v elektronické formě), které byly provedeny v inovované verzi díla. Budou-li inovované verze díla obsahovat modifikovanou funkčnost oproti předchozí verzi díla, budou tyto verze distribuovány spolu s náležitou dokumentací a aktualizovanou uživatelskou příručkou v elektronické podobě.

4. Technická podpora bude poskytována v českém, nebo slovenském jazyce.

5. Na práva a povinnosti smluvních stran při poskytování technické podpory se přiměřeně použijí ustanovení čl. VIII této smlouvy.

6. Zhotovitel je povinen za každý kalendářní měsíc, ve kterém poskytoval technickou podporu, vyhotovit měsíční výkaz, ve kterém budou uvedeny činnosti provedené v rámci poskytnuté technické podpory, a zaslat jej objednateli k odsouhlasení, a to vždy do 5. dne následujícího kalendářního měsíce. Bez odsouhlasení měsíčního výkazu není zhotovitel oprávněn žádat po objednateli uhrazení ceny za poskytování technické podpory.

XIII.

Podmínky poskytování technické podpory

1. Technická podpora bude poskytována na základě požadavků objednatele či jednotlivých uživatelů. Povinností zhotovitele je sledovat vývoj software, který je předmětem plnění, a o této skutečnosti informovat objednatele a navrhnout objednateli potřebu provedení

update/upgrade. Plnění spočívající v update/upgrade bude poskytnuto po vzájemné dohodě mezi objednatelem a zhotovitelem.

2. Poskytnutí technické podpory bude objednatel či uživatel zadávat primárně prostřednictvím rozhraní Service Desk provozovaného objednatelem, do kterého bude zhotoviteli zřízen přístup. Bližší specifikace hlášení požadavků je uvedena v příloze č. 1 této smlouvy.

3. Technická podpora bude poskytována v režimu 24x7, tedy bude dostupná po 24 hodin 7 dní v týdnu, přičemž požadavky na provedení technické podpory budou zhotovitelem vyřešeny ve lhůtách a způsobem uvedených v čl. 4.7.1. přílohy č. 1 této smlouvy, nedohodnou-li se smluvní strany v konkrétním případě jinak. Požadavky na poskytnutí technické podpory tak budou zhotovitelem vyřízeny následovně:

a) pro požadavky kategorie (A) zahájení neprodleně, nejpozději do 4 hodin po oznámení chyby, odstraňování chyb bude prováděno v režimu 24x7, odstranění vady musí být provedeno do 24 hodin od oznámení této vady zhotoviteli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.

b) pro požadavky kategorie (B) zahájení do 24 hodin po oznámení chyby, odstraňování chyb bude prováděno v pracovní dny se zahájením řešení v režimu 24x7, odstranění vady musí být provedeno do 7 pracovních dní od oznámení této vady zhotoviteli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.

c) pro požadavky kategorie (C) zahájení do 120 hodin po oznámení chyby, odstraňování chyb bude prováděno v pracovní dny (tj. pondělí–pátek) v době od 07:00 do 16:00, odstranění vady musí být provedeno do 30 pracovních dní od oznámení této vady zhotoviteli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.

4. Pro kategorizaci vad dle odst. 3 tohoto článku platí následující pravidla:

Kategorie (A) - Chyba, která:

a) znemožňuje užívání SW systému jako celku.

b) nebo znemožňuje užívání části SW systému, přičemž nemožnost užívání takové části SW systému může mít významný vliv na řádné zabezpečení běžné činnosti objednatele a nelze jí schůdně překonat či obejít, nebo jí lze překonat či obejít pouze za cenu pro objednatele vážných obtíží.

Kategorie (B) - Chyba, která nebrání v užívání SW systému ani jeho dílčích částí, neboť jí lze schůdně překonat či obejít, aniž by tím vznikaly pro objednatele vážné obtíže.

Kategorie (C) - Chyba, která nebrání v užívání SW systému ani jeho dílčích částí a lze jí bez problémů překonat či obejít.

5. Technická podpora bude zhotovitelem poskytována tak, aby byla zajištěna bezchybná provozuschopnost systému dodaného dle části B této smlouvy.

6. Zhotovitel se zavazuje v případě uplatnění požadavku na technickou podporu objednatelem (uživatelem) bezodkladně písemně potvrdit objednateli přijetí oznámení o požadavku a zahájit bezodkladně práce na odstraňování vady. Pro vyloučení pochybností se písemným potvrzením rozumí i potvrzení elektronicky.

7. Provedenou opravu vady (vyřešení požadavku na technickou podporu) zhotovitel objednateli předá písemně.

8. V případě plánovaného zásahu zhotovitele na díle (tzv. servisní okna) bude prioritně využito pravidelného servisního okna, které je určeno každou první středu v měsíci v časech od 00:00 hod. do 2:00 hod. Pokud bude nutno z bezodkladných důvodů provést servisní zásah zhotovitelem v mimo pravidelné servisní okno musí být nahlášeny objednateli s alespoň

3 denním předstihem a je nutné je provádět, pokud možno mimo frekventované časy, tj. o víkendech a ve dnech pracovního volna, pokud se smluvní strany nedohodnou jinak.

XIV.

Místo a doba plnění

1. Technická podpora bude zhotovitelem prováděna dálkovou formou z prostor zhotovitele (dále jen „vzdálený přístup“); v případě nemožnosti realizace on-line bude poskytnuta formou servisního výjezdu u objednatele/uživatele.

2. Zhotovitel se zavazuje, že vzdálený přístup na základě této smlouvy bude využívat jen za účelem poskytování služeb uvedených v této smlouvě. Porušení této povinnosti bude považováno za podstatné porušení smlouvy.

3. Technická podpora bude poskytována ode dne akceptace systému (tj. od převzetí díla dle části B této smlouvy), a to po dobu neurčitou.

XV.

Cena za poskytování technické podpory

1. Cena za 1 rok poskytování technické podpory činí bez DPH 1.632.494,- Kč (slovy: jeden milion šest set třicet dva tisíc čtyři sta devadesát čtyři koruny české), DPH ve výši 21% je 342.823,74 Kč a cena včetně DPH činí 1.975.317,74 Kč (slovy: jeden milion devět set sedmdesát pět tisíc tři sta sedmnáct korun českých sedmdesát čtyři haléřů).

Podrobný rozpis ceny je uveden v příloze č. 2 této smlouvy.

2. Cena podle odst. 1 tohoto článku smlouvy zahrnuje veškeré náklady zhotovitele spojené se splněním jeho závazků vyplývajících z této smlouvy. Cena je stanovena jako nejvýše přípustná a není ji možno překročit.

XVI.

Platební a fakturační podmínky

1. Cena za technickou podporu bude hrazena zpětně vždy za 12 měsíců, ve kterých

byla technická podpora poskytována, a to na základě faktury vystavené zhotovitelem.

2. Cenu za technickou podporu lze v souvislosti s uplynutím druhého výročí poskytování služeb technické podpory upravit z důvodu inflace ponížené o 2 procentní body za podmínek dále uvedených:

a. Inflací se rozumí Průměrná roční míra inflace, kterou udává každým kalendářním rokem Český statistický úřad za rok předcházející vyjádřená v procentech.

b. Počínaje třetím rokem poskytování služeb technické podpory a dále do budoucna je zhotovitel oprávněn zvýšit cenu služeb technické podpory nejčastěji jednou ročně z důvodů inflace, a to o tolik procent, kolik procent činila Průměrná roční míra inflace za rok bezprostředně předcházející ponížená o 2 procentní body; součástí (např. přílohou) daňového dokladu bude vymezení údajů o inflaci dle smlouvy, přičemž objednatel je oprávněn tuto fakturu před uplynutím lhůty splatnosti vrátit, pokud inflace nebude vyjádřena správně (vrácením vadné faktury zhotoviteli přestává běžet původní lhůta splatnosti, nová lhůta splatnosti běží ode dne vystavení nové faktury).

c. Cena za technickou podporu upravená z důvodu inflace ponížené o 2 procentní body se považuje za sjednanou cenu, která nevyžaduje uzavření dodatku ke smlouvě. Pokud inflace za příslušný rok nepřekročí 2 %, nebude cena technické podpory upravena.

3. Pro další platební a fakturační podmínky se přiměřeně použije ustanovení platebních podmínek pro část B této smlouvy.

XVII.

Sankce

1. V případě prodlení zhotovitele se zahájením odstraňování vady ve lhůtách stanovených v čl. XIII odst. 3 této smlouvy je zhotovitel povinen objednateli uhradit smluvní pokutu ve výši 500 Kč za každou započatou hodinu prodlení.

2. V případě prodlení zhotovitele s odstraněním vady (vyřešením požadavku) ve lhůtách stanovených v čl. XIII odst. 3 této smlouvy je zhotovitel povinen objednateli uhradit smluvní pokutu:

a) u chyby kategorie (A) 5.000 Kč za každý započatý den prodlení,

b) u chyby kategorie (B) 3.000 Kč za každý započatý den prodlení,

c) u chyby kategorie (C) 500 Kč za každý započatý den prodlení.

3. Pro případ prodlení se zaplacením ceny za poskytování technické podpory sjednávají smluvní strany úrok z prodlení ve výši stanovené občanskoprávními předpisy.

4. Smluvní pokuty se nezapočítávají na náhradu případně vzniklé škody, kterou lze vymáhat samostatně vedle smluvní pokuty, a to v plné výši.

ČÁST D OSTATNÍ USTANOVENÍ

XVIII.

Odpovědnost za škodu

1. Zhotovitel bude povinen nahradit objednateli/uživatelům v plné výši škodu, která vznikla při realizaci díla či poskytování technické podpory z důvodů na straně zhotovitele nebo jako důsledek porušení povinností a závazků zhotovitele dle této smlouvy.

2. Zhotovitel prohlašuje, že po celou poskytování plnění dle této smlouvy bude mít na vlastní náklady sjednánu pojistnou smlouvu pro případ způsobení škody třetí osobě s limitním plněním na jednu pojistnou událost minimálně 50 mil. Kč, s maximální spoluúčastí 500.000

Kč. Pojištění musí obsahovat krytí škod způsobené na majetku, zdraví třetích osob včetně krytí odpovědnosti za finanční škody.

3. Zhotovitel předložil kopii pojistné smlouvy nebo pojistný certifikát ne starší 1 měsíce před uzavřením této smlouvy a dále je povinen předložit objednateli kdykoli na vyžádání kopii pojistné smlouvy včetně případných dodatků na požadované pojištění nebo certifikát příslušné pojišťovny ne starší jednoho měsíce prokazující existenci pojištění v rozsahu dle odst. 2 tohoto článku smlouvy (dobu trvání pojištění, jeho rozsah, pojištěná rizika, pojistné částky, roční limity a sublimity plnění a výši spoluúčasti), a to nejpozději do 10 dnů od obdržení příslušné žádosti. Náklady na pojištění nese zhotovitel a jsou zahrnuty ve sjednané odměně.

4. V případě, že při činnosti prováděné zhotovitelem dojde ke způsobení škody objednateli nebo třetím osobám, která nebude kryta pojištěním sjednaným ve smyslu odstavce 2 tohoto článku, bude zhotovitel povinen tyto škody uhradit z vlastních prostředků.

5. Zhotovitel je povinen učinit veškerá opatření potřebná k odvrácení škody nebo k jejímu zmírnění.

6. V případě porušení povinnosti zhotovitele dle odst. 2 a 3 tohoto článku smlouvy je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 100.000 Kč za každý i započatý měsíc, v němž nebude mít uzavřenou pojistnou smlouvu se stanovenými parametry. Smluvní pokuta se nezapočítává na náhradu případně vzniklé škody, kterou lze vymáhat samostatně vedle smluvní pokuty, a to v plné výši.

XIX.

Ochrana osobních údajů a důvěrných informací

1. Není-li stanoveno touto smlouvou či jejími přílohami výslovně jinak, je ustanoveními tohoto článku smlouvy mezi smluvními stranami upravena zejména bezpečnost informací, ochrana a zpracování osobních údajů a bezpečnostní procesy a postupy objednatele, které souvisejí s plněním této smlouvy.

2. Zhotovitel objednateli odpovídá za to, že dokumenty a soubory dat, které mu při plnění této smlouvy předá:

a) jsou kopiemi originálů příslušných dokumentů a souborů dat zhotovitele,

b) neobsahují žádné infiltrační prostředky,

c) že k nim má práva na jejich šíření, instalaci, konfiguraci a správu, která mu umožňují

s nimi nakládat a dále je poskytovat tak, jak je sjednáno v této smlouvě.

Veškeré skutečnosti obchodní, ekonomické a technické povahy související se smluvními stranami, které nejsou běžně dostupné v obchodních kruzích a se kterými se smluvní strany seznámí při realizaci předmětu smlouvy nebo v souvislosti s touto smlouvou, jsou považovány za neveřejné. V případě, že budou zhotoviteli zpřístupněny osobní údaje, jsou pro účely této smlouvy považovány za neveřejné.

3. Zhotovitel se zavazuje, že neveřejné informace jiným subjektům nesdělí, nezpřístupní, nezkopíruje a neumožní jejich zkopírování ani nevyužije pro sebe nebo pro jinou osobu. Zavazuje se zachovat je v přísné tajnosti a sdělit je výlučně těm svým zaměstnancům nebo podzhotovitelům, kteří jsou pověřeni plněním smlouvy a za tímto účelem jsou oprávněni se s těmito informacemi v nezbytném rozsahu seznámit. Zhotovitel se zavazuje zabezpečit, aby i tyto osoby považovaly uvedené informace za důvěrné a zachovávaly o nich mlčenlivost. Zhotovitel bere na vědomí, že v průběhu plnění bude nakládat s neveřejnými informacemi zdravotnických zařízení a bude povinen zajistit ochranu nejen z hlediska

důvěrnosti, ale také z hlediska integrity; požadavky na integritu a šifrování jsou obsaženy

v příloze č. 1 této smlouvy a pravidla vzdáleného přístupu v příloze č. 4 této smlouvy.

4. Povinnost plnit ustanovení tohoto článku smlouvy ohledně neveřejných informací

se nevztahuje na informace, které:

a) mohou být zveřejněny bez porušení této smlouvy,

b) byly písemným souhlasem obou smluvních stran zproštěny těchto omezení,

c) jsou známé nebo byly zveřejněny jinak než následkem porušení povinnosti jedné

ze smluvních stran,

d) příjemce je zná dříve, než je sdělí smluvní strana,

e) jsou vyžádány soudem, státním zastupitelstvím nebo příslušným správním orgánem

na základě zákona, popřípadě, jejichž uveřejnění je stanoveno zákonem,

f) smluvní strana sdělí osobě vázané zákonnou povinností mlčenlivosti (např. advokátovi nebo daňovému poradci) za účelem uplatňování svých práv.

6. Zhotovitel je povinen zlikvidovat veškeré neveřejné informace, které se dozvěděl v průběhu plnění této smlouvy poté, co bude plnění z této smlouvy ukončeno, ať už splněním anebo jiným způsobem zániku této smlouvy.

5. Zhotovitel je povinen přijmout veškerá potřebná opatření, která jsou nutná k zajištění plnění předmětu této smlouvy a která vyplývají z této smlouvy anebo z interních předpisů a postupů objednatele, se kterými bude zhotovitel seznámen.

6. Povinnost ochrany neveřejných informací trvá bez ohledu na ukončení účinnosti této smlouvy. Neveřejné informace jsou považovány za důvěrné údaje ve smyslu § 1730 odst. 2 občanského zákoníku.

7. Zhotovitel prohlašuje, že při plnění této smlouvy bude docházet ke zpracování osobních údajů (dále jen „zpracování“) ve smyslu zákona č. 110/2019 Sb., o zpracování osobních údajů a ve smyslu nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů) (dále jen „obecné nařízení“).

8. Smluvní strany prohlašují, že v při plnění této smlouvy není objednatel v pozici správce ani zpracovatele osobních údajů dle čl. 4 odst. 7 a 8 obecného nařízení.

9. Zhotovitel prohlašuje, že zajistí bezpečnost zpracování a naplnění veškerých požadavků, které se na zpracování zejména ve smyslu obecného nařízení vztahují. Xxxxxxxxxx si je vědom své odpovědnosti za dodržování veškerých zákonných povinností v souvislosti se zpracováním a rovněž si je vědom své odpovědnosti za škodu vzniklou v případě porušení těchto povinností. V případě potřeby je zhotovitel povinen uzavřít s objednatelem či jednotlivými uživateli smlouvu o zpracování osobních údajů, případně jinou smlouvu, která zajistí soulad prováděného zpracování s platnými právními předpisy.

10. V případě porušení povinnosti k ochraně osobních údajů a důvěrných informací dle tohoto článku je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 50.000 Kč za každý jednotlivý případ. Smluvní pokuty se nezapočítávají na náhradu případně vzniklé škody, kterou lze vymáhat samostatně vedle smluvní pokuty, a to v plné výši.

XX.

Sankce vůči Rusku a Bělorusku

1. Zhotovitel odpovídá za to, že platby poskytované objednatelem dle této smlouvy nebudou přímo nebo nepřímo ani jen zčásti zpřístupněny osobám, vůči kterým platí tzv. individuální finanční sankce ve smyslu čl. 2 odst. 2 Nařízení Rady (EU) č. 208/2014 ze dne 5. 3. 2014

o omezujících opatřeních vůči některým osobám, subjektům a orgánům vzhledem k situaci na Ukrajině a Nařízení Rady (ES) č. 765/2006 ze dne 18. 5. 2006 o omezujících opatřeních vůči prezidentu Xxxxxxxxxxx a některým představitelům Běloruska a které jsou uvedeny na tzv. sankčních seznamech (dle příloh č. 1 obou nařízení).

2. Bude-li kterékoliv z nařízení v budoucnu doplněno či nahrazeno jinou legislativou obdobného významu, uvedená povinnost se uplatní obdobně.

3. Zhotovitel odpovídá za to, že po dobu trvání smlouvy nejsou naplněny podmínky uvedené v nařízení Rady (EU) 2022/576 ze dne 8. dubna 2022, kterým se mění nařízení (EU) č. 833/2014 o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím situaci na Ukrajině, tedy zejména, že zhotovitel není:

● ruským státním příslušníkem, fyzickou nebo právnickou osobou se sídlem v Rusku,

● právnickou osobou, která je z více než 50 % přímo či nepřímo vlastněna některou z osob dle předešlé odrážky, nebo

● fyzickou nebo právnickou osobou, která jedná jménem nebo na pokyn některé z osob uvedených v předešlých odrážkách.

Zhotovitel odpovídá za to, že po dobu trvání smlouvy žádná z výše uvedených podmínek není naplněna ani u jeho poddodavatele (nebo jiné osoby prokazující za zhotovitele kvalifikaci), který se bude na plnění této smlouvy podílet z více jak 10 % hodnoty plnění.

4. Zhotovitel je povinen objednatele bezodkladně informovat o jakýchkoliv skutečnostech, které mohou mít vliv na odpovědnost zhotovitele dle odst. 1 nebo 3 tohoto článku smlouvy. Zhotovitel je současně povinen kdykoliv poskytnout objednateli bezodkladnou součinnost pro případné ověření pravdivosti těchto informací.

5. Dojde-li k porušení pravidel dle odst. 1 nebo 3 tohoto článku smlouvy, je objednatel oprávněn odstoupit od této smlouvy; odstoupení se však nedotýká povinností zhotovitele vyplývajících ze záruky za jakost, odpovědnosti za vady, povinnosti zaplatit smluvní pokutu, povinnosti nahradit škodu a povinnosti zachovat důvěrnost informací souvisejících s plněním dle této smlouvy.

6. Dojde-li k porušení pravidel dle odst. 1 nebo 3 tohoto článku smlouvy, je zhotovitel povinen zaplatit objednateli smluvní pokutu ve výši 250.000 Kč, a to za každý jednotlivý případ porušení. Smluvní pokuty se nezapočítávají na náhradu případně vzniklé škody, kterou lze vymáhat samostatně vedle smluvní pokuty, a to v plné výši.

XXI.

Zánik smlouvy

1. Smluvní strany se dohodly, že smlouva zaniká:

a) dohodou smluvních stran, která musí mít písemnou formu,

b) jednostranným odstoupením od smlouvy pro její podstatné porušení druhou smluvní stranou, přičemž podstatným porušením smlouvy se rozumí zejména:

● neprovedení díla v době plnění dle čl. V odst. 4 smlouvy, přičemž prodlení činí

alespoň 15 dnů,

● zhotovitel bude poskytovat plnění v rozporu s touto smlouvou, resp. její přílohou, platnými technickými normami, obecně závaznými předpisy, případně pokyny objednatele a nezjedná nápravu, ačkoliv byl zhotovitel na toto své chování nebo porušování povinností objednatelem písemně upozorněn a vyzván ke zjednání nápravy,

● nedojde k akceptaci Implementačního projektu ani v objednatelem dodatečně poskytnuté lhůtě, která nesmí být kratší než 15 dnů,

● opakované neposkytování technické podpory v souladu s touto smlouvou,

● neuhrazení ceny za dílo nebo za poskytování technické podpory objednatelem po druhé výzvě zhotovitele k uhrazení dlužné částky, přičemž druhá výzva nesmí následovat dříve než 30 dnů po doručení první výzvy.

c) V části C písemnou výpovědí objednatele s tříměsíční výpovědní dobou, která začíná běžet prvním dnem měsíce následujícího po doručení výpovědi zhotoviteli. Xxxxxxxxxx je oprávněn vypovědět tuto smlouvu v části C písemnou výpovědí s 12-měsíční výpovědní dobou, avšak zhotovitel je oprávněn tuto smlouvu vypovědět nejdříve po uplynutí 4 let účinnosti této smlouvy.

2. Objednatel je dále oprávněn od této smlouvy odstoupit v těchto případech:

a) bylo-li příslušným soudem rozhodnuto o tom, že zhotovitel je v úpadku ve smyslu zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů (a to bez ohledu na právní moc tohoto rozhodnutí);

b) podá-li zhotovitel sám na sebe insolvenční návrh;

c) dojde k významné změně kontroly nad dodavatelem nebo změně kontroly nad zásadními aktivy využívanými zhotovitelem k plnění dle této smlouvy ve smyslu písm.

n) přílohy č. 7 VKB.

3. Smluvní strana, která svým jednáním, zdržením nebo opomenutím zavdala příčinu pro odstoupení druhé smluvní strany od této smlouvy, je povinna uhradit této druhé smluvní straně náklady vzniklé z důvodů odstoupení od smlouvy. Tím není dotčeno právo odstupující smluvní strany na zaplacení případné smluvní pokuty, kterou je sankcionováno porušení povinnosti, které je důvodem pro odstoupení. Uvedené náklady jsou splatné bezhotovostně na účet oprávněné smluvní strany do 30 dnů ode dne, kdy je tato oprávněná smluvní strana povinné straně vyčíslí, nejpozději však do 2 let.

4. Odstoupením od smlouvy zůstávají nedotčena ustanovení této smlouvy o náhradě škody, smluvních pokutách, dále ustanovení o odpovědnosti zhotovitele za vady díla, o záruce a záruční době, o řešení sporů či jiná ustanovení, která podle projevené vůle smluvních stran nebo vzhledem ke své povaze mají trvat i po ukončení smlouvy.

5. V případě jakéhokoliv ukončení smlouvy se zhotovitel zavazuje splnit tyto povinnosti:

● poskytnutí požadovaných součinností v souvislosti s předáním podpory a poskytování služeb novému zhotoviteli nebo objednateli, a to v souladu s exit plánem specifikovaným v rámci implementačního projektu (náklady na vytvoření exit plánu a poskytování součinnosti při exitu jsou součástí ceny plnění),

● poskytnutí informací nezbytných k převzetí systému novým zhotovitelem nebo

objednatelem,

● poskytnutí veškeré relevantní dokumentace v aktuálním stavu, která byla vytvořena v rámci plnění předmětu této smlouvy.

O řádném splnění povinností zhotovitele dle tohoto odstavce bude sepsán akceptační

Příloha č. 1 - Technická specifikace díla

1. MOTIVACE POŽADAVKU

Zajištění uceleného a vysoce spolehlivého řešení ukládání, řízení a správy dokumentů v rámci jednotlivých uživatelských tenantů využívaných zdravotnickými zařízeními se současnou centralizovanou správou v rámci multitenantního systému. Požadavkem je zjednodušení stávající administrace a přístupu k dokumentům, postupné vytvoření „bezpapírové nemocnice“ a zvýšení úrovně bezpečnosti informací při práci s dokumenty.

Mezi očekávané přínosy patří:

● organizace dokumentů do přehledné struktury na úrovni jednotlivých uživatelských tenantů

● podpora týmové práce v každém kroku životního cyklu dokumentu

● automatická tvorba a řízení verzí a revizí dokumentů

● podpora práce více uživatelů s jedním dokumentem – funkce check in / check out

● efektivní vyhledávání dokumentů

● podpora vytváření standardizovaných dokumentů a inteligentních formulářů, přenos dat z/do dokumentu

● vytváření dynamických pohledů na dokumenty

● podpora elektronického schvalování a uvolňování dokumentů

● správa šablon dokumentů na úrovni jednotlivých uživatelských tenantů

● evidence historie práce s dokumenty

● publikace dokumentů do příslušných sekcí personifikovaného Dashboardu uživatele

● podpora převodu papírových dokumentů do elektronické podoby (skenování), vytěžení

● nastavení jasných přístupových práv k dokumentům a odpovědností v rámci workflow

● automatizace oběhu dokumentů s workflow

● zabezpečení proti ztrátě a zničení dokumentů, archivace dokumentů v úložišti dle požadované architektury

● možnost propojení pomocí API ERP, OCR systémy třetích stran

● rychlé a efektivní vyhledávání dokumentů

● připomínkování a schvalování dokumentů

● vlastní typy a kategorie dokumentů, šablony dokumentů

● řízení přístupů a řízené seznamování s dokumentem

● implementace požadovaných oblasti v rámci I. etapy (řízená dokumentace, elektronické schvalování žádanek, podpora pro řízení rizik)

● dodávka jádra DMS připraveného pro aplikaci elektronických procesů v jednotlivých zdravotnických zařízeních včetně aplikací I. Etapy (na základě této veřejné zakázky). V rámci následujících smluvních vztahů realizovaných na úrovni jednotlivých zdravotnických zařízení (dalších etap) realizace využití DMS pro implementaci dalších aplikací např. ukládání všech dokumentů, které v jednotlivých zdravotnických zařízeních vznikají, (objednávka, žádanka, smlouvy, podklady pro poptávky/nabídky, směrnice, dopisy klientům, informace pro web, projektová dokumentace apod.)

Požadavkem je vytvoření podpory pro řešení potřeb jednotlivých zdravotnických zařízení u všech uživatelů pod jednotný multitenantní dokument management systém (dále také „DMS“).

2. STÁVAJÍCÍ STAV

Jednotlivá zdravotnická zařízení řeší správu a ukládání dokumentů pomocí běžných kancelářských nástrojů a SW prostředků v rámci své infrastruktury, tj. sdílené složky, lokální ukládání dokumentace, tisk většiny dokumentace, fyzický oběh dokumentů v rámci workflow a schvalování.

Základní architektura infrastruktury uživatelů je založena na virtuálním prostředí a je provozována na platformě VMware, vyjma Bílovecké nemocnice a.s., kde je provozován Hyper-V.

Všichni uživatelé vyžívají autentizaci uživatelů pomocí MS AD, pouze Nemocnice Třinec, p. o. využívá autentizaci pomocí LDAP eDirectory (Microfocus Novell).

Slezská nemocnice v Opavě, p. o. – je již povinnou osobou dle zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti)1.

1 Zadavatel požaduje, aby ke všem zdravotnickým zařízením v rámci plnění veřejné zakázky bylo přistupováno, jako k povinným osobám v oblasti kybernetické bezpečnosti, a to i pokud tyto povinnosti plynoucí z platné a účinné legislativy nemají Národním úřadem pro kybernetickou a informační bezpečnost stanovené.

V Následující tabulce je uveden přehled ERP (Enterprise Resource Planning) a IDM systémů (Identity management) systémů jednotlivých zdravotnických zařízení.

Nemocnice

Třinec p. o.

Nemocnice ve Frýdku-Místku p. o.

Nemocnice

Havířov, p. o

Nemocnice

Karviná-Ráj,

p. o.

Slezská nemocnice v Opavě, p. o.

Sdružené zdravotnic-ké zařízení Krnov, p. o.

Bílovecká

nemocnice, a.s.

Zdravotnická záchranná služba MSK,

p. o.

ERP

LCS HELIOS

Nephrite

Business Central 365 - Cloud

Dynamics BC365

MS Dynamics BC365

VEMA

GINIS

IDM

AC Identita

Tabulka č. 1 Přehled ERP a IDM systémů jednotlivých zdravotnických zařízení

2.1. SLUŽBA KRAJSKÉ KORPORACE – ZÁLOHOVÁNÍ

Služba krajské korporace pro zálohování dat ze vzdálených pracovišť je zajišťována na HW a SW technologiích DELL EMC s využitím deduplikace. Technologicky jsou data ukládána na DataDomain DD6300 a proces zálohování a obnovy dat je řízen pomocí SW Avamar ve verzi 19.04.0-116.

Deduplikační zálohovací software Avamar této služby krajské korporace umožňuje rychlý, účinný backup díky integrované deduplikační technologii. Služba zálohování krajské korporace je optimalizovaná pro rychlé, každodenní zálohování fyzických i virtuálních prostředí (VMware), NAS serverů, korporátních aplikací, vzdálených lokalit (příspěvkových organizací) případně desktopů/laptopů. Služba je charakteristická tím, že díky principu ukládání pouze jednotlivých změn, které nastávají během dne, dochází k redukci zatížení storage pro zálohování i redukci zatížení sítě. Data jsou z bezpečnostních důvodů vždy šifrována i komprimována.

Služba postavená na technologii Avamar rozděluje data do různě dlouhých subsouborových segmentů, komprimuje je a během zálohovacího procesu využívá jedinečného hash identifikátoru pro každý segment. Avamar potom určí, zda byl již daný segment zálohován, a zálohuje pouze změněné segmenty. Poté touto službou řízenou Avamarem nikdy nejsou zálohovaná stejná data dvakrát.

3. POPIS POŽADOVANÉHO ŘEŠENÍ

DMS je ucelený nástroj pro správu dokumentů se zvýšenou potřebou kontroly jejich oběhu, zajišťující jednotnou evidenci a správu v jejich celém životním cyklu. V rámci něho bude v I. etapě možné rovněž využít připravených procesů pro řízenou dokumentaci v organizaci včetně podpory pro řízení rizik.

Centrální DMS bude zajišťovat podporu celého životního cyklu dokumentu v lokalitách těchto uvedených uživatelů2:

● Nemocnice Havířov, p. o.

● Nemocnice ve Frýdku-Místku, p. o.

● Nemocnice Karviná-Ráj, p. o.

● Sdružené zdravotnické zařízení Krnov, p. o.

● Slezská nemocnice v Opavě, p. o.

● Nemocnice Třinec, p. o.

● Bílovecká nemocnice, a.s.

● Zdravotnická záchranná služba Moravskoslezského kraje, p. o.

● Moravskoslezské datové centrum, p. o., dále také „MSDC“ (pro vybrané části)3

Požadované řešení DMS musí být dodáno v multitenantní architektuře. Z pohledu architektury je v rámci multitenantního modelu požadováno využití centrálního úložiště dokumentů na bázi file systému, DMS pak ukládá soubory do souborového systému a do centrální databáze se ukládají pouze metadata. Soubory v souborovém systémů jsou zašifrované pomocí symetrické kryptografie bezpečným algoritmem s dostatečnou délkou klíče a bez známé zranitelnosti.

Systém bude dostupný z webového rozhraní s responzivním designem bez nutnosti instalace klientské části pomocí protokolu HTTPS z mobilního prostředí.

Jednotlivé tenanty DMS systému budou využívat jednotlivá zdravotnická zařízení. Přístup k dokumentům v souborovém úložišti a jejich předání uživateli je řízeno aplikační logikou s kontrolou oprávnění a logováním přístupů, tj. dokumenty jsou přístupné přes webové rozhraní DMS.

2Pro tyto jednotlivé právní subjekty bude provozován v rámci multitenantního systému uživatelský tenant

3Vybraný částmi se zde rozumí vlastní podpora organizace v oblasti kybernetické bezpečnosti

Pro veškerou práci s DMS bude využíván personifikovaný Dashboard uživatele. Co se týče aplikací souvisejících s kybernetickou bezpečností, pak tyto budou publikovány prostřednictvím příslušné sekce v personifikovaném Dashboardu uživatele DMS. Sekce v rámci personifikovaného Dashboardu uživatele musí být rozšířitelné o další oblasti.

Centrální část multitenantní architektury bude implementována v budově Integrovaného bezpečnostního centra (IBC), kde je předpokládaným provozovatelem DMS MSDC. MSDC bude rovněž využívat DMS v oblasti řízení kybernetické bezpečnosti.

Základní vlastnosti DMS:

● multitenantní architektura s centralizovaným ukládáním dokumentů a s centrálním registrem nezdravotnické dokumentace pro ukládání

metadat

● správa uživatelů, skupin a rolí, jejich synchronizací s AD, LDAP jednotlivých uživatelských tenantech apod. a jejich organizační strukturou

● řízení přístupových oprávnění – každý uživatel vidí pouze ta data, která odpovídají jeho přístupovým právům

● elektronické workflow pro oběh dokumentů a dat v rámci jednotlivých uživatelských tenantů

● pokročilá aplikační podpora pro práci v týmu s dokumenty ve smyslu umožnění řízené revize, verzování, podpory práce více uživatelů / editorů, v DMS v rámci prezentační vrstvy on-line office prostředí

● hlídání lhůt pro jeho vyřízení, systém bude upozorňovat na konec lhůty, v případě nedodržení lhůty systém problém eskaluje (emailové avízo, zpráva, mobilní prostředí)

● v případě nepřítomnosti vyřizujícího zaměstnance (role) je možné automatické přidělení dokumentu zastupujícímu pracovníkovi

● bude umožňovat práci v týmech (v rámci řešení, ne pouze v týmech na úrovni jednotlivých uživatelských tenantů) pro zpracování bez ohledu na jejich konkrétní přidělení (uživatel si proces převezme a ostatní členové týmu vidí, že proces je již zpracováván jiným členem týmu na základě funkce check in / check out)

● poskytování statistik

● administrační činnosti, a to na úrovni multitenantní architektury a rovněž na úrovni jednotlivých uživatelských tenantů např. výměna pracovníků, nastavení schvalovacích pravidel procesu apod.

● výměny dat s okolními systémy (připravená API rozhraní a integrace na vyjmenované systémy)

● webové rozhraní systému umožňující personifikovaně prezentovat obsah

● ukládání a prezentace neřízené, tedy obecné dokumentace

Obecné požadavky a parametry:

● Veškeré dodávané SW produkty byly získány legálně a umožňují využití těchto produktů Zadavatelem, potažmo uživateli jako koncovými zákazníky, v souladu s distribučními a licenčními podmínkami výrobce zařízení.

● V případě dodání SW produktů Zadavateli, jako koncovému zákazníkovi, nebude Zadavatel nijak omezen ve svých nárocích vyplývajících ze záruky výrobce dodávaného zařízení a z produktové podpory, kterou tento výrobce k dodávaným SW produktům poskytuje. Uvedené musí zahrnovat i nárok Zadavatele na přístup k relevantním SW releases a novým verzím SW po celou dobu trvání podpory výrobce.

● Musí být umožněn přístup Zadavatele k dokumentaci výrobce SW a znalostní bázi, kterou výrobce v rámci své podpory poskytuje.

● Uživatel musí mít možnost eskalovat závady přímo k technické podpoře výrobce SW, včetně možnosti si sám a přímo otevřít požadavek na technickou podporu, provádět změny priority požadavků a případné eskalace pracovníky Zadavatele. A to po celou dobu požadované podpory.

● Dodavatel garantuje, že v případě dodání zboží Zadavateli, jako koncovému zákazníkovi, bude Dodavatelem poskytnuta k dodávanému zařízení záruka výrobce a produktová podpora v plném, výrobcem poskytovaném rozsahu.

● Součástí dodávky musí být poskytnutí práva užívat software (dále též „licence“).

● Zajištění dostupnosti, důvěrnosti a integrity.

Požadovaný rozsah dodávky je rozdělen do dvou částí:

● Multitenantní jádro dokument management systému

● Aplikace elektronických procesů - I. Etapa

Předpokladem je, že na základě dílčích smluvních vztahů v budoucnu dojde ze strany jednotlivých zdravotnických zařízení (uživatelských tenantů) k další aplikaci elektronických procesů spočívající v rozšíření systému o vytěžování faktur využitím API na lokální ERP systémy, rozšíření o vystavování a schvalování objednávek pro dodavatele apod.

V souvislosti s uvedeným je dodavatel povinen poskytnout v rámci technické podpory veškerou nezbytnou součinnost budoucímu dodavateli, který vyplyne z dílčích smluvních vztahů při aplikaci dalších elektronických procesů.

3.1. MULTITENANTNÍ JÁDRO DOKUMENT MANAGEMENT SYSTÉMU

Jádro DMS zajistí pokročilou aplikační podporu pro práci s dokumenty ve smyslu umožnění řízené revize, verzování, podpory práce více uživatelů

/ editorů, dále ve smyslu zajištění prezentační vrstvy, tj možnosti otevření dokumentu přímo v online prostředí DMS (nebo integrované komponenty třetí strany – Online Office) a to v internetovém prohlížeči pro současnou práci, více uživatelů na jednom dokumentů.

Toto uvedené Online office prostředí v rámci DMS musí podporovat formáty Microsoft Office Open XML (OOXML) a OASIS Open Document Format for Office Applications (ODF) minimálně pro textový dokument (DOCX, ODT), tabulkový dokument (XLSX, ODS) a prezentaci (PPTX, ODP), pro otevření, editaci a uložení těchto formátů a podporou pro revizi dokumentu – sledování změn a komentáře. Vzhled otevřeného dokumentu musí odpovídat původní definici formátování.

Dále je vyžadována podpora funkce check in / check out, včetně verzování, a to ve smyslu podpory workflow (notifikace uživatelů s požadovanou akcí vztahující se k dokumentu – přečtení, připomínkování, doplnění) a to v rozsahu všech autentizovaných uživatelů, DMS bude podporovat různé typy elektronických dokumentů, verzování, workflow, procesy, správu obsahu a elektronické formuláře, šablony apod.

Požadovaná řešení musí být v multitenantní architektuře. Aplikační a DB serverové řešení musí být virtualizováno pro centrální provoz na platformě VMware. Vlastní dokumenty budou ukládány do centrálního úložiště dokumentů na bázi file systému.

Cílem řešení DMS je sjednocení tvorby, připomínkování a schvalování dokumentů v rámci jednotlivých uživatelských tenantů. V důsledku tohoto sjednocení dojde k vytvoření centrálního repository, což přispěje k vyšší míře dohledatelnosti jednotlivých dokumentů a efektivnímu a bezpečnému nakládání s nimi. Předpokladem je, že vyhledávání v centrálním repository bude podmíněno samostatným administrovatelným oprávněním jak pro celek, tak pro jednotlivé uživatelské tenanty.

Systém bude podporovat tvorbu různých workflow z grafického prostředí spravovatelného administrátorem, a to na úrovni jednotlivých uživatelských tenantů, která budou moci být přizpůsobeny typovému dokumentu ve vazbě na aplikované workflow, který bude v dané aplikaci DMS řešen.

V rámci tvorby a spolupráce nad dokumentem bude možné sledovat termíny, ve kterých byly jednotlivé činnosti realizovány, stejně jako pro ně bude možné nastavit i lhůty. Dále bude možné v rámci integrace na MS AD/LDAP4. využít vazby na role a skupiny rolí uživatelů.

4 LDAP se zde rozumí, adresářové služby od firmy Microfocus eDirectory, které běží na Open Enterprise Server 2018 SP2

Mezi činnosti, které jádro DMS podporuje, musí být zanesena příprava dokumentu (z šablon dokumentů, inteligentních formulářů), jeho připomínkování, možnost vypořádání daných připomínek, schvalování, přečtení, zrušení, zneplatnění, nabytí platnosti a nabytí účinnosti, publikace včetně důsledného logování, ze kterých budou ve vhodné formě zpracovávány informace o splnění termínu a dále informace o přečtení (seznámení se) s povinným dokumentem apod.

Případně všechny dokumenty v systému bude možné provázat mezi sebou pomocí odkazů, např. vnitřní řídící dokumenty a legislativa, a to i

v oblasti podpory pro řízení rizik v oblasti kybernetické bezpečnosti.

Workflow DMS musí podporovat celou životní fází dokumentů, tedy zejména od doby jejich tvorby, připomínkování a schvalování, po vynucení jejich zobrazení ze strany uživatelů, upozornění na blížící se termíny ve vztahu k dokumentu, expirace dokumentu, nutnost revize atd.

Z pohledu licenční politiky je požadováno, aby byl poskytnut licenční model, který je také označován, jako „multilicence“. Tedy bez dalšího dílčího licenčního omezení pro jednotlivé uživatelské tenanty a licence pro použité office online prostředí pro všechny editory pro editaci dokumentů a pro všechny uživatele pro náhled v prostředí online office včetně dodávané podpory.

DMS

Multitenatní jádro

Hospital Cloud - Centrálně provozované informační

systémy

Registr smluv

Zákon o registru smluv

(340/2015 Sb.)

Podpůrné sdílené aplikační

služby korporace (Krajský úřad)

Interface

API/Interface

Interface

Aplikace procesů

Centrální Registr nezdravotnické dokumentace (metadata)

DESA (edice DEA)

Centrální archiv elektronické dokumentace včetně EZD

Centrální Repository

Webové rozhraní DMS

Slezská nemocnice v

Opavě

Nemocnice Karviná

Nemocnice Třinec

Nemocnice v Bílovci

Nemocnice Frýdek-Místek

LDAP

- OCR

- ERP

IDM

MS AD

- OCR

- ERP

IDM

MS AD

- OCR

- ERP

IDM

- OCR

- ERP

MS AD

IDM

- OCR

- ERP

MS AD

Služba

zálohování

Message Broker

3.2. POŽADAVKY NA ARCHITEKTURU DMS

Sdružené zdravotnické zařízení Krnov
	MS AD
	- OCR - ERP
	IDM

Nemocnice Havířov
	MS AD
	- OCR - ERP
	IDM

Zdravotnická záchranná služba MSK
	MS AD
	- OCR - ERP
	IDM

Moravskoslezské datové

centrum

MS AD

3.3. PODPORA ŽIVOTNÍHO CYKLU DOKUMENTU

DMS disponuje (již ve svém základu) procesy pro řízení životního cyklu dokumentace, jedná se o vznik, schválení až po distribuci, vydání včetně publikace. Tyto vlastnosti uvádíme především z důvodu požadavku dalšího rozvoje při aplikaci elektronických procesů, které budou realizovány jednotlivými zdravotnickými zařízeními v dalších etapách. Celý požadovaný životní cyklus je zaznamenán na následujícím schématu a bude v detailu rozpracován v rámci Implementačního projektu na úrovni jednotlivých implementovaných procesů.

Životní cyklus dokumentu a podpora v DMS

Seznam platné dokumentace

• Publikace v GUI DMS (v příslušném seznamu)

• Intranetu subjektu

• Bezpečnostním portálu

•

Zpracování návrhu

•

podpora

připomínkovacího

řízení doplnění již schváleného dokumentu

Schvalovací řízení

Schválení finální verze

dokumentu

•

vytvoření návrhu ze

šablon uložených v

DMS

• skenování, OCR,

vytěžení

(v rámci DMS probíhá

sekvenční nebo paralelní

proces)

•

Vydání dokumentu

označení finální verze

dokumentu

určení okruhu působnosti

distribuce

označení dokumentu skartačním znakem určení způsobu archivace

příslušnosti k publikačnímu

prostředí a seznamu

Seznámení s obsahem

• Seznámení určených pracovníků s obsahem dokumentu

• Průkazné vedení

historie

Revize/zrušení

•

rozhodnutí o revizi

zrušení

označení neplatnosti

Interface

Registr smluv

Zákon o registru smluv (340/ 2015 Sb.)

Archivace/Skartace

Podpora archivačního

procesu v DMS

Interface na důvěryhodný

archiv

Seznam neplatné

dokumentace

Publikace v GUI DMS (v příslušném seznamu a publikačním prostředí)

Připomínkové řízení

Interface

Důvěryhodný archiv

(Služba Hospital Cloudu)

Celý životní cyklus je pak složen z/ze:

● Vzniku dokumentů:

o připravených šablon a inteligentních formulářů

o scanem a OCR s vytěžením dokumentu s využitím API DMS pro případný přenos dat do ERP

● Připomínkového řízení

● Schvalovacího řízení – zde je požadavkem zadavatele zajistit při vydání automatizovaně konverzi do pdf formátu

● Aplikace elektronických procesů

● Vydání dokumentů – zde je požadavkem zadavatele zajistit při vydání automatizovaně konverzi do pdf formátu

● Průkazného seznámení s obsahem:

o dokument jsem četl a seznámil se s obsahem (souhlas je zobrazen až po „odrolování“ na dokumentu na jeho konec)

o skutečnost je zapsána do auditní stopy (výsledek prokazatelného seznámení).

o historie je trvale dostupná ve věci prokazatelného seznámení pracovníků s dokumentem (verze, datum a čas seznámení)

● Ukládání a vyhledávání

● Přezkoumání platnosti/neplatnosti

● Archivace a skartace

V následujícím schématu jsou detailněji vyjádřeny části – připomínkování, schvalovací řízení a vydání dokumentu.

DOKUMENT

Sekvenční proces

Paralelní proces

uživatel

PŘIPOMÍNKOVÉ

ŘÍZENÍ

uživatel

SCHVÁLENÍ

uživatel

VYDÁNÍ

uživatel

Seznámení se s obsahem

Pro seznámení se s obsahem dokumentu je nutné pracovat s aktuálně platným seznamem zaměstnanců pro jednotlivá střediska v rámci jednotlivých uživatelských tenantů, tj. napojením na adresářové služby a IDM AC Identita s požadovanou funkcionalitou.

Archivace, skartace

Předpokladem je, že do důvěryhodného archivu budou ukládány všechny dokumenty, které mají z pohledu legislativy určenou zákonnou skartační lhůtu podmiňující jejich dostupnost (např. dokumenty vztažené k účetnictví). Druhým předpokladem je, že na úrovni DMS budou archivovány všechny dokumenty, kde tato povinnost nevyplývá z legislativy (např. řízená dokumentace). Skartace čili trvalé odmazání dokumentů ze systému bude pořizováno s auditním záznamem o skartaci.

Publikace

V DMS bude k dispozici Dashboard uživatele. Jedná se o personifikované prostředí, ve kterém budou jednotlivým uživatelům publikovány dokumenty,

a to v těchto základních sekcích:

● Aktivní pracovní plocha

● Seznam úkolů plynoucích z jednotlivých workflow

● Publikované dokumenty v příslušných sekcích/oblastech:

o bezpečnostní portál pro oblast kybernetické bezpečnosti,

o řídící dokumentace zdravotnického zařízení

o a další konfigurovatelné sekce

Podpora mobilního prostředí

Zadavatel požaduje, aby bylo podporováno DMS mobilní prostředí. Zadavatel v této oblasti především požaduje, aby v této části byly podporovány funkce schvalovacího řízení, aktivní notifikace a seznámení se s obsahem v rámci workflow procesu, a to v ergonomicky přijatelném zobrazení. Při podpoře zde uvedených specifických stavů životního cyklu dokumentu budou prioritně nabízeny konvertované dokumenty do pdf formátu. Není však tímto vyloučeno využití v mobilním prostředí online editorů office DMS pro editaci dokumentů (viz kap. 3.1).

3.4. INTERFACE

Co se týče požadovaného interface na důvěryhodný archiv, jedná se o produkt DESA edice DEA od společnosti ICZ a.s. (stávající řešení).

Požadavkem je, aby dodavatel dodal API k DMS pro komunikaci se systémy třetích stran:

a) k OCR systémům (Optical Character Recognition),

b) s ERP systémy.

Zde je předpokladem, že budou předávána vytěžená data OCR metodou voláním API, a to v oblasti ekonomické agendy (faktury apod.) Po zpracování v příslušném workflow DMS bude možno voláním API předat data do jednotlivých ERP systémů. Obsah předávaných dat (specifikace API) bude předmětem Implementačního projektu a bude využíván v dalších etapách implementace ze strany jednotlivých uživatelů.

V rámci interface pro práci s identitami je požadována integrace na IDM AC Identita (Autocont) a Microsoft Active Directory v případě Třinecké nemocnice na LDAP eDirectory (Microfocus Novell). DMS musí pracovat s aktuálně platným seznamem zaměstnanců pro jednotlivá střediska v rámci jednotlivých uživatelských tenantů vedených v těchto datových zdrojích. Rozsah integrací bude upřesněn v návaznosti na konktrétně dodávaný DMS v rámci implementačního projektu.

DMS bude pro zasílání zpráv využívat službu krajské korporace „Message Broker“. Pro řešení této služby je využíván open source produkt Message broker RabbitMQ a ESB WSO2. V rámci této základní instalace je připraveno zasílání zpráv na SMTP server a SMS bránu. Message broker RabbitMQ aktuálně podporuje několik komunikačních protokolů, jako například AMQP, MQTT, STOMP aj.

Dalším požadovaným interface je vytvoření možnosti pro publikaci smluv v Registru smluv, který je zřízen na základě zákona „Zákon o registru smluv, č. 340/2015 Sb. ve znění pozdějších předpisů“

3.5. POŽADOVANÉ FUNKCIONALITY JÁDRA DMS

● Jádro DMS bude obsahovat centrální registr nezdravotnické dokumentace uchovávající metadata o uložených dokumentech. Centrální registr bude evidovat jednoznačný identifikátor dokumentů, bude poskytovat služby, jejichž obsahem budou registrovaná metadata dokumentů, na základě dotazů na tato metadata.

● DMS musí být schopen nativního začlenění do existujících MS domén nebo do eDirectory.

● DMS zajistí ukládání dokumentů s možností připojení příloh (např. podepsaný, naskenovaný dokument, vytěžená data OCR metodou).

● DMS zajistí řízení přístupu k dokumentaci – nastavení uživatelských oprávnění. Definování přístupových práv k dokumentům kombinací, kdo (uživatel, skupina, role) a jaká práva má k danému objektu (složka, dokument) a jak jsou vytvořena, s možností (a) zděděn, (b) explicitně definována/změněna.

● DMS umožní hlídání lhůt pro vybrané dokumenty – např. platnost dokumentu od, účinnost dokumentu do, včetně upozornění na blížící se konec lhůty nebo její uplynutí, skartační příznaky.

● DMS bude otevřené řešení a bude umožňovat následující:

o možné úpravy struktury v prezentační vrstvě,

o možného definování dalších workflow úloh z úrovně administrace v grafickém proces designeru využívající BPMN/BPEL,

o definice dalších skupin uživatelů, a to ze strany administrátorů na straně objednatele.

● DMS umožní automatické číslování typových řad dokumentů na úrovni uživatelského tenantu – vzestupnou řadou, možnost změny typu názvu dokumentu (definice typových řad bude předmětem editovatelných číselníků na úrovni jednotlivých uživatelských tenantů).

● DMS zajistí podporu pro práci v týmu s dokumenty ve smyslu umožnění řízené revize, verzování, podpory práce více uživatelů / editorů, v DMS

v rámci prezentační vrstvy on-line office prostředí

● DMS umožní změny názvu dokumentu.

● DMS umožní pokročilé vyhledávání dokumentů (formát souboru, datum, název, uživatel atd.).

● DMS zobrazí metadata souboru – historie verzí, kdo provedl změny, kdy atd.

● DMS zajistí notifikace v minimálně následujícím rozsahu:

o upozornění na založení nového dokumentu vyžadující vyjádření, potvrzení o přečtení atp.

o upozornění blížícího se termínu k vyjádření,

o informace, zda a kdo se k dokumentu vyjádřil,

o ve vazbě na dokument, např. před uplynutím lhůty platnosti dokumentu.

● DMS umožní vyjádření se k dokumentu (formou komentáře k dokumentu / možnost revize/editace dokumentu/ možnost zamknutí dokumentu).

● DMS umožní definovat skupiny, které se k dokumentu mají vyjádřit, včetně definice, zda je vyjádření povinné nebo nepovinné.

● DMS umožní nastavení termínů, kdy se musí oslovení vyjádřit.

● DMS zajistí možnost označit, zda proces vyžaduje potvrzení přečtení.

● DMS zajistí pro nového zaměstnance podle systemizovaného místa možnost předdefinovat, s jakými dokumenty se musí seznámit (např. příručka pro nové zaměstnance, organizační řád), jaké dokumenty musí následně podepsat atd.

● Online office prostředí v rámci DMS i offline (požadovány obě možnosti) editace souborů kompatibilních formátů s využitím office prostředí DMS nebo kancelářských SW v aktuálních podporovaných verzích.

● Verzování dokumentů, a to i při editaci souborů na síťovém disku nebo v offline módu.

● Automaticky přidělované evidenční číslo dokumentu v rámci uživatelského tenantu z předefinovaných číselných řad.

● Generování výsledných dokumentů ze šablon/vzorů, aktivních formulářů.

● Možnost omezení velikosti dokumentu.

● Synchronizace uživatelů a rolí s AD, LDAP, možnost vytváření nezávislých uživatelských účtů.

● Dashboard uživatele

● Notifikace pomocí emailové zprávy na řešitele s linkem k úkolu, eskalace při neplnění úkolu.

● Notifikace pomocí emailové zprávy na zadavatele o průběhu workflow.

● Notifikace do mobilního prostředí

● DMS bude umožňovat odesílání dokumentů do registru smluv

● Integrace se systémy třetích stran pomocí:

o API

o sledovaných složek

o URI

● Možnost automatizovaného vstupu dokumentu.

● Možnost automatizovaného předvyplnění hodnot v metadatech dokumentu z externího zdroje:

o XML

o CSV

o napojení na číselník umístěný v externí databázi

● API pro komunikaci systémů třetích stran – OCR vytěžování dat (minimální množství 1000 stran/měsíčně pro jeden uživatelský tenant)

s přenosem specifických dat pomocí API do ERP systémů jednotlivých zdravotnických zařízení.

● DMS musí podporovat práci minimálně s následujícím výčtem dokumentových formátů – XML, PDF, RTF, rodina Microsoft Office dokumentů (docx, xlsx,...), ODF, HTML, a prezentaci (PPTX, ODP), obrazové, zvukové a video formáty.

● DMS dále podpoří práci s digitalizovanými analogovými dokumenty – jedná se o všechny dokumenty vznikající mimo informační systém, příchozí strukturované i nestrukturované dokumenty (pošta, faktury atd.).

3.6. APLIKACE ELEKTRONICKÝCH PROCESŮ

V této části jsou popsány požadavky na aplikaci elektronických procesů, které jsou součástí I. etapy.

Uživatelské tenanty budou aplikaci elektronických procesů dále rozšiřovat DMS dle vlastních potřeb a požadavků. Předpokladem v dalších etapách je využití systému o vytěžování faktur a pomocí volání API DMS přenosu specifických dat do ERP, rozšíření o vystavování a schvalování objednávek pro dodavatele.

V I. etapě v rámci této technické specifikace je požadována následující aplikace elektronických procesů pro podporu všech uživatelských tenantů

v jednotném workflow, aplikovaném na jednotlivé uživatelské tenanty.

	Řízená dokumentace organizací (kap. 3.6.1)	Životní cyklus správy bezpečnostní dokumentace (kap. 3.6.2)	Schválení žádanky o přepravu (kap. 3.6.3)	Podpora pro řízení rizik – kybernetická bezpečnost (kap. 3.6.4)
Nemocnice Třinec p. o.	X	X	X	X
Nemocnice ve Frýdku-Místku p. o.	X	X	X	X
Nemocnice Xxxxxxx, p. o	X	X	X	X
Nemocnice Karviná-Ráj, p. o.	X	X	X	X
Slezská nemocnice v Opavě, p. o.	X	X	X	X
Sdružené zdravotnické zařízení Krnov, p. o.	X	X	X	X
Bílovecká nemocnice, a.s.	X	X	X	X
Zdravotnická záchranná služba Moravskoslezského kraje, p. o.	X	X	-	X

Tabulka č. 2 Přehled požadavků na aplikací procesů I. Etapy

3.6.1. ŘÍZENÁ DOKUMENTACE ORGANIZACÍ

V této aplikaci v DMS musí být možno vytvářet, revidovat, evidovat, uchovávat (ukládat) interní předpisy (Organizační řídící akty, Směrnice, Předpisy a Dokumentace) uživatelského tenantu, včetně zajištění procesu návrhu, připomínkování, tvorby verzí dokumentu, schvalování, vydání a archivaci (s naplněním celého životního cyklu dokumentu) se současným prokazatelným seznámením se s obsahem vydaného dokumentu.

a) Účel: slouží k podpoře řízené dokumentace jednotlivým uživatelům

o Podpora celého životního cyklu řízené dokumentace v jednotlivých uživatelských tenantech.

o Správa řízené dokumentace v jednotlivých uživatelských tenantech s publikací na personifikovaném portálu v sekci „Řízená dokumentace“

b) Podpora: šablony řízené dokumentace ve vizuálním stylu jednotlivých subjektů

o Bezpečné uložiště informací, řízení přístupových práv k jednotlivým Směrnicím, předpisům a dokumentům;

o Podpora elektronických podpisů dle platné legislativy;

o Možnost oddělit role odpovědné za přípravu Směrnice, předpisu nebo dokumentu (garant) od role odpovědné za publikaci a aktuálnost příslušných spravovaných dokumentů (správce);

o Zamezení přístupu administrátorů systému k obsahu dokumentů;

o Informování odpovědných osob notifikace e-mailem, notifikace v mobilním prostředí, kontrola seznámení se s předpisem formou úkolů;

o Možnost přidávání připomínek uživateli, které se následně mohou zapracovat v příštích verzích;

o Hlídaní platností a upozornění na blížící se datum příští revize, vytváření revizí nebo nových verzí (pomocí e-mailových upomínek) Podpora generování kalendářových plánovacích informací ve formátu iCAL dle RFC 5545.

o Záznam historie změn a schvalování na několika úrovních (historie položky, historie workflow a zjednodušený přehled na kartě dokumentu);

o Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;

o Doložitelnost historie pro interní i externí audity – kompletní evidence historie přípravy směrnice, předpisu nebo dokumentu včetně seznamování se s nimi.

o Zjednodušení procesu prokazatelného seznámení:

- hromadné spouštění procesu seznámení s novou směrnicí anebo její novou revizí na všechny povinné uživatele anebo vymezený počet povinných uživatelů (vybraná část linie stromu uživatelů, anebo kompetenční skupiny uživatelů – mimo liniovou organizační strukturu),

- jednoduché řízení procesu seznámení se všemi směrnicemi při nástupu nového zaměstnance, popř. zaměstnance, který změnil své pracovní zařazení;

o Reporting procesu prokazatelného seznámení:

- z hlediska jednotlivých dokumentů,

- z hlediska jednotlivých uživatelů,

- z hlediska skupin uživatelů;

o Reporting vztažený k veškeré dokumentaci v systému.

c) Workflow:

o Pokrytí procesu tvorby, připomínkování, schvalování a seznámení se s dokumenty s využitím sekvenčního a paralelního

procesu

o Automatizace procesu jejich přezkoumávání ke dni skončení platnosti

o Vícestupňový proces přípravy příslušného dokumentu, možnost paralelní práce připomínkujících nebo oponentů

o Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1

o Využití Workflow nástroje na řízení procesu přípravy i během účinnosti předpisu

o Definice worflow individuálně dle potřeb organizace na úrovni jednotlivých uživatelských tenantů5

d) Status: který nabývá dokument v jednotlivých krocích životního cyklu

o Šablona

o Zpracování návrhu

o Připomínkové řízení

o Schvalovací řízení

o Vydání dokumentu

o Seznámení s obsahem

o Revize platného dokumentu

o Zrušení dokumentu

o Archivace

3.6.2. ŽIVOTNÍ CYKLUS SPRÁVY BEZPEČNOSTNÍ DOKUMENTACE

V této aplikaci musí být možno v DMS vytvářet, revidovat, evidovat, klasifikovat, uchovávat (ukládat) bezpečnostní dokumentaci, a to centrálně na základě jednoho workflow procesu pro všechny uživatelské tenanty. Při této aplikaci bude podporován celý životní cyklus správy bezpečnostní dokumentace od procesu návrhu, připomínkování, tvorby verzí dokumentu, schvalování, vydání, publikaci a archivaci se současným prokazatelným seznámení se s obsahem vydaného dokumentu tak, aby byly naplněny minimálně legislativní požadavky spojené s provozem systémů základní služby.

Tato část aplikace v DMS bude disponovat aplikačním prostředím umožňující přístup uživatelů jednotlivých zdravotnických zařízení, MSDC a k vybraným informacím rovněž SOC6 (třetí strana – dodavatel služeb).

a) Účel – slouží k podpoře bezpečnostní dokumentace jednotlivým zdravotnickým zařízením, MSDC a dodavateli služeb SOC

5 Workflow bude upřesněno v rámci Implementačního projektu

6 Činnosti Security Operations Center (SOC) jsou dodávány formou služeb. Současným poskytovatelem těchto služeb je konsorcium VISITECH a.s. a DATASYS a.s.

o Podpora celého životního cyklu bezpečnostní dokumentace7 v jednotlivých uživatelských tenantech, MSDC a SOC

o Správa bezpečnostní dokumentace v jednotlivých s uživatelských tenantech, MSDC a SOC s publikací v příslušné sekci na personifikovaném bezpečnostním portálu MSK

b) Podpora – šablony řízené dokumentace ve vizuálním stylu MSDC a jednotlivých zdravotnických zařízení:

o Bezpečné uložiště informací, řízení přístupových práv k jednotlivým Směrnicím, předpisům a dokumentům z oblasti

kybernetické bezpečnosti

o Možnost oddělit role odpovědné za přípravu dokumentace (garant) od role odpovědné za vydání dokumentu (publikaci) a aktuálnost příslušných spravovaných dokumentů (správce)

o Informování odpovědných osob notifikací, kontrola seznámení se s předpisem formou úkolů

o Možnost přidávání připomínek uživateli, které se následně mohou zapracovat v příštích verzích

o Hlídání platnosti a upozornění na blížící se datum příští revize, vytváření revizí nebo nových verzí (pomocí notifikací)

o Záznam historie změn a schvalování na několika úrovních (historie položky, historie workflow a zjednodušený přehled na kartě dokumentu)

o Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;

o Doložitelnost historie pro interní i externí audity – kompletní evidence historie přípravy bezpečnostní dokumentace včetně seznamování se s nimi

o Zjednodušení procesu prokazatelného seznámení:

- jednoduché řízení procesu seznámení se všemi směrnicemi při nástupu nového zaměstnance, popř. zaměstnance, který změnil své pracovní zařazení;

o Reporting procesu prokazatelného seznámení:

- z hlediska jednotlivých dokumentů,

- z hlediska jednotlivých uživatelů,

- z hlediska skupin uživatelů;

o Reporting vztažený k veškeré bezpečnostní dokumentaci,

o Zajištění kompletního životního cyklu dokumentů v návaznosti na platnou legislativu kybernetické bezpečnosti (vznik/verzování, schválení, distribuci a archivaci) potřebných pro řízení kybernetické bezpečnosti – pro automatizaci a řízení procesů prostřednictvím nástrojů workflow.

7 dle VKB, příloha č. 5, 2. kapitola včetně doporučení.

o Zajištění veškerých standardních procesů v návaznosti na platnou legislativu kybernetické bezpečnosti:

- podpora publikace vzorové dokumentace pro KB

- podpora komunikace v rámci systémů KB mezi jednotlivými rolemi

- podpora bezpečnostních činností administrátorů a bezpečnostních rolí (např. řízení změn, kontrola opakovaných činností, provozní deník atd.)

- hlídání termínů pro splnění povinností dle nastaveného kalendáře pro povinné úkony

- distribuce úkolů jednotlivým rolím, včetně zajištění auditní stopy

- podpora práce řídícího výboru, vč. řízení úkolů, předání, jejich provedení, včetně zanechání auditní stopy

- podpora kontroly a auditu

c) Workflow:

o Zajištění veškerých standardních procesů v návaznosti na platnou legislativu kybernetické bezpečnosti:

- personifikovaná publikace vzorové dokumentace pro kybernetickou bezpečnost

- podpora komunikace v rámci systémů pro kybernetickou bezpečnost mezi jednotlivými rolemi

- hlídání termínů pro splnění povinností dle nastaveného kalendáře pro povinné úkony

- podpora práce řídícího výboru, vč. řízení úkolů, předání, jejich provedení, včetně zanechání auditní stopy

- podpora kontroly a auditu

o Hlídání termínů pro splnění povinností dle nastaveného kalendáře pro povinné úkony s podporou generování kalendářových plánovacích informací ve formátu iCAL dle RFC 5545

o Pokrytí procesu tvorby, připomínkování, schvalování a seznámení s dokumenty s využitím sekvenčního a paralelního procesu, distribuce úkolů jednotlivým rolím, včetně zajištění auditní stopy

o Automatizace procesu jejich přezkoumávání ke dni skončení platnosti

o Vícestupňový proces přípravy příslušného dokumentu, možnost paralelní práce připomínkujících nebo oponentů

o Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1

o Využití Workflow nástroje na řízení procesu přípravy i během účinnosti předpisu

d) Status – který nabývá v jednotlivých krocích životního cyklu:

o Šablona

o Zpracování návrhu

o Připomínkové řízení

o Schvalovací řízení

o Vydání dokumentu (publikace na bezpečnostním portálu MSK)

o Seznámení s obsahem

o Revize platného dokumentu

o Zrušení dokumentu

o Archivace

3.6.3. SCHVÁLENÍ ŽÁDANKY O PŘEPRAVU

V této aplikaci v DMS musí být možno na základě inteligentního formuláře – „žádanky o přepravu“ vytvářet, revidovat, evidovat, uchovávat (ukládat),

schvalovat s naplněním celého životního cyklu žádanky o přepravu.

a) Účel – slouží jako podklad pro objednání vozidla pro služební/pracovní cestu, přičemž může být:

o Jednorázová (služební cesta)

o Dlouhodobá (pro zajištění opakovaných pracovních činností): např. měsíční žádanka na nákup ND, převozy materiálu z bodu A do B

b) Podpora – elektronický interaktivní formulář žádanky ve formě šablony s údaji:

o Identifikace žadatele (jméno, příjmení, osobní číslo, název a číslo oddělení) – automatické předvyplnění dle login informací a zařazení osoby dle PAM

o Jména spolucestujících

o Datum, hodina a místo přistavení vozidla

o Start a cíl cesty

o Předpokládaná délka cesty (hodiny/dny/týden/měsíc)

o Požadavek na parkování vozidla před/po ukončení jízdy mimo zdravotnické zařízení (zpravidla v místě bydliště)

o Účel jízdy

o Údaje o řidiči:

- Jméno, příjmení (nemusí být žadatel, ale třeba osoba uvedená jako spolujezdec)

- Druh vozidla a SPZ (vyplňuje doprava)

c) WorkFlow:

o Žadatel vyplní žádanku (všechny povinné údaje) a odešle ke schválení

o Nadřízený pracovník schvaluje žádanku

o Pokud žádanka obsahuje požadavek na parkování vozidla před/po jízdě mimo zdravotnické zařízení (v místě bydliště), to zpravidla schvaluje ředitel nebo jiná zodpovědná osoba

o Referent/vedoucí dopravy přiřazuje vozidlo a potvrzuje vyřízení žádanky

o Před jízdou referent dopravy označí status žádanky – „vozidlo předáno“

o Při vrácení klíčů od vozidla referent dopravy označí status „vozidlo vráceno“

o Během workflow dojde každému účastníkovi notifikace v mailu a žadateli u všech kroků schvalování/zamítnutí

o Definice worflow individuálně dle potřeb organizace na úrovni jednotlivých uživatelských tenantů

d) Status:

e) Report:

o Nová žádanka

o Schválená žádanka

o Přiděleno vozidlo

o Předáno vozidlo

o Vozidlo vráceno

o Jízda nerealizována/storno žádanky

o Interaktivní report s možností označení filtrů pro všechny realizované žádanky se současným jejich statusem

o Možnost tisku výsledku (filtru) interaktivního reportu

o Možnost exportu výsledku (filtru) v csv formátu

3.6.4. PODPORA PRO ŘÍZENÍ RIZIK – KYBERNETICKÁ BEZPEČNOST

V této části požadovaného řešení je aplikace pro řízení rizik. V této aplikaci je předpokladem správa registru hrozeb, zranitelností a rizik s podporou identifikace a hodnocení rizik, jejich analýzy s následnou evidencí a správou opatření. Aplikace musí naplňovat požadavky platné legislativy a všech dalších bezpečnostních standardů.

a) Účel: vytvořit podporu uživatelským tenantům, aby si svá aktiva pojmenovala, zajistila společnou jmennou konvenci, uvědomila si jejich hodnotu a efektivně je ochránila před externími i interními hrozbami.

b) Podpora – jednotlivých uživatelských tenantů s centrálním pohledem pro MSDC/SOC:

o Systém obsahující databázi aktiv a rizik

o Proces řešení kybernetické bezpečnostní události/incidentu

o Aktiva uživatelských tenantů a jejich hodnot, s podporou jednotlivých uživatelských tenantů

o Vlastníků aktiv (péče o aktivum), Garantů aktiv (stav a bezpečnost aktiva)

o Evidence rizik s významem jednotlivých rizik, hrozeb a zranitelností s hodnocením dopadu

o Analýzy rizik, hodnocení rizik

o Řízení rizik – proces jehož cílem je chránit aktiva před působením hrozeb

o Zvládání rizik a opatření

o Konfigurační databáze (CMDB).

o Provozně technická dokumentace a architektura ICT.

o Možnost vytváření vlastních reportů.

c) Workflow:

o Zajištění veškerých standardních procesů v návaznosti na platnou legislativu kybernetické bezpečnosti:

- Identifikace aktiv a stanovení vlastníků aktiv

- Hodnocení aktiv a stanovení hodnoty

- Provedení analýzy rizik a rozhodnutí o zvládání jednotlivých rizik

- Realizace opatření k ošetření rizik

- Pravidelný monitoring rizika a přezkoumání systému

o Proces řešení kybernetické bezpečnostní události/incidentu (přes vytvořené workflow v rámci bezpečnostních politik)

o hlídání termínů pro splnění povinností dle nastaveného kalendáře pro povinné úkony s podporou generování kalendářových plánovacích informací ve formátu iCAL dle RFC 5545

o podpora práce řídícího výboru, vč. řízení úkolů, předání, jejich provedení, včetně zanechání auditní stopy

o podpora kontroly a auditu

3.7. OBECNÉ POŽADAVKY NA NABÍDKU DODAVATELE

● U všech vyvolaných požadavků plynoucích ze zvoleného řešení dodavatelem, zadavatel požaduje, aby součástí nabídky byl „virtual machine template“ v režimu vysoké dostupnosti High availability (dále také „HA“), pro všechny aplikační a databázové systémy a to, aby dodavatel mohl v rámci součinnosti připravit své virtualizační prostředí. Dodavatel specifikuje potřebný „virtual machine template“ pro centrální provoz DMS dle parametrů tabulky č. 3 (virtual machine bude poskytnut v rámci součinnosti objednatelem).

● Součástí nabídky musí být kompletní popis funkcionality nabízeného DMS, a to v rozsahu možnosti ověření požadavků stanovených touto Technickou specifikací.

● Součástí nabídky musí být operační systémy, databáze a další licence třetích stran, které systém bude využívat. Zadavatel uvádí, že uvedené zdroje ve „virtual machine template“ budou závazné pro dodavatele v rámci detailního rozpracování Implementačního projektu.

● Jednotlivé uživatelské tenanty budou mít v rámci svého tenantu přístup pouze ke svým dokumentům uložených v DMS.

● Dodavatel bere na vědomí, že se v souvislosti s platnou legislativou v oblasti kybernetické bezpečnosti stává „významným dodavatelem“.

Tabulka č. 3 Předpokládáný počet uživatelů8

Nemocnice

Třinec p.o.

Nemocnice

Havířov p.o.

Nemocnice SZZ Krnov p.o.

Nemocnice

Karviná p.o.

Slezská nemocnice Opava, p.o.

Nemocnice ve Frýdku-Místku p.o.

Bílovecká nemocnice, a.s.

Zdravotnická záchranná služba MSK,

p. o.

Moravskoslezské datové centrum p.o.

Předpokládaný počet klíčových uživatelů (editorů)

150

120

100

200

100

Předpokládaný počet všech uživatelů

1 200

1 000

900

1 200

1 300

1 700

260

1 300

8 zadavatel zde předpokládaný počet uživatelů uvádí z důvodů možné představy dodavatele o zatížení DMS, frekventantů školení a požadavků na licence pro office online prostředí pro všechny editory (editaci dokumentů) a pro všechny uživatele (náhled) v prostředí DMS naplňující požadavek na online office.

Tabulka č. 4 Požadavky na VM prostředí

Uživatelský tenant:
Název VM	Počet VM	vHDD (GB)	vCPU (jádra)	vRAM (GB)	vNIC	OS	SW
aplikační servery celkem SUM	5	2560	34	160	5	Linux Alma 9	v dockerech provozované DMS + online office

PROD aplikační server	1	128	6	16	1		verso3 + sso
PROD DMS server	1	1024	8	32	1		alfresco + cul
PROD DMS util server	1	128	8	32	1		pdf-api onlyoffice
PROD DB server	1	768	4	32	1		pg databaze
TEST aplikační server	1	512	8	48	1		all in one

Pro centrální řešení podporující všechny uvedené uživatelské tenanty. V požadavku na HA, bude vše 2x.

V rámci nabídky účastníka zadavatel požaduje doplnit „virtual machine template“ v rozsahu této tabulky pro centrální řešení podporující všechny uvedené uživatelské tenanty.

4. PŘEDMĚT PLNĚNÍ

Předmětem plnění veřejné zakázky je dodání Dokument management systému zajišťující elektronizaci a rozvoj elektronického oběhu dokumentu ve

všech jeho fázích v prostředí vlastněných nebo zřízených zdravotnických zařízení MSK, kterými jsou:

● Nemocnice Havířov, p. o.

● Nemocnice ve Frýdku-Místku, p. o.

● Nemocnice Karviná-Ráj, p. o.

● Sdružené zdravotnické zařízení Krnov, p. o.

● Slezská nemocnice v Opavě, p. o.

● Nemocnice Třinec, p. o.

● Bílovecká nemocnice, a.s.

● Zdravotnická záchranná služba MSK, p.o.

● Moravskoslezské datové centrum, p.o.

Předmět plnění je strukturován do následujících částí:

● Část 1 – Implementační projekt

● Část 2 – Dodávka SW, Implementace

● Část 3 – Školení

● Část 4 – Dokumentace

● Část 5 – Akceptační testy

● Část 6 – Technická podpora

4.1. ČÁST 1 – IMPLEMENTAČNÍ PROJEKT

Obsahem Implementačního projektu bude:

a. Implementační analýza stávajícího prostředí uživatelů – analýza prostředí, která bude obsahovat minimálně následující:

o identifikace zdrojů dat využitých pro dodávku,

o identifikace potřeb, vazeb a konfiguračních parametrů pro implementaci dílčích částí:

● implementační upřesnění specifikovaných požadavků,

● výstupy z analýzy okolí – sběr a analýza informací vztahujících se k dodávce, především ve vztahu k realizaci

požadovaných interface,

● analýza implementovaných procesů vzniku a oběhu dokumentů

o návrh jednotlivých workflow pro jednotlivé tenaty

o závazné požadavky na součinnosti,

b. Detailní popis cílového stavu (instalační, implementační a konfigurační upřesnění návrhu řešení z nabídky) s popisem alespoň těchto oblastí:

o rozpracování návrhu řešení z nabídky zhotovitele z pohledu implementace dle získaných závěrů z implementační analýzy

s detailem na:

▪ Soupis implementovaných procesů (workflow)

▪ Soupis rolí v rámci dotčených procesů

▪ Návrh úpravy procesů tak, aby byly po implementaci systému funkční

▪ Návrh dalších procesů, které jsou pro provoz systému technologie nezbytné

▪ Řešení oblasti včetně procesů kybernetické bezpečnostní události/incidentu v návaznosti na platnou legislativu kybernetické bezpečnosti

▪ Přiřazení rolí k jednotlivým procesním krokům

o upřesnění rozhraní pro integraci na IS a technologie třetích stran,

o upřesnění rozsahu předávaných dat pomocí API

o popis zajištění bezpečnosti systému a informací dle Obecného nařízení o ochraně osobních údajů (GDPR), ZoKB a příslušných vyhlášek

a dalších příslušejících částí k řešení DMS v prostředí jednotlivých uživatelských tenantů.

c. Projektové řízení s popisem projektové metodologie pro realizaci předmětu plnění ze strany dodavatele a jeho případných poddodavatelů (harmonogram, projektový tým, koordinační mechanismy apod.). Obsahem této části minimálně bude:

o projektový plán včetně uvedení kritických milníků. Kritické milníky jsou termíny dosažení určitých fází projektu, které jsou pro

naplnění cílů projektu klíčové. Kritické milníky budou obsahovat minimálně aktivity vedené ve smlouvě o dílo, s uvedením

konkrétních termínů, dodavatel vhodným způsobem může rozšířit kritické milníky o další aktivity, které mohou být pro projekt klíčové,

o návrh a popis postupu implementace, s časovým hlediskem a vazbami, (instalace, testování, akceptační procedura apod.).

d. Návrh zálohování a obnovy (disaster recovery plan) s využitím příslušné služby krajské korporace

e. Popis testovacích scénářů, a to zejména pro provedení následujících testů:

▪ funkční testy,

▪ zátěžové testy,

▪ penetrační testy,

s návrhem jednotlivých akceptačních protokolů.

f. Exit plán – popis nutných kroků pro naplnění exit plánu, včetně popisu datových struktur (pro strojově čitelná data) související s migrací dat.

Implementační projekt podléhá vlastní akceptační proceduře. Po předání Implementačního projektu může objednatel do 5 pracovních dnů předat v písemné podobě dodavateli své výhrady. Dodavatel neprodleně, nejpozději však do 5 pracovních dnů, nedohodnou-li se smluvní strany jinak, zapracuje objednatelem uvedené nedostatky a připomínky. Proces akceptace lze opakovat, dokud dodavatel nezapracuje veškeré výhrady vznesené objednatelem. Po akceptaci nápravy všech výhrad ze strany objednatele je Analýza považována za ukončenou a dodavatel tak může pokračovat v realizaci dodávky dle časového harmonogramu.

Zadavatel požaduje, aby před odevzdáním k připomínkování implementačního projektu proběhla prezentace obsahu návrhu implementačního projektu.

4.2. ČÁST 2 –– DODÁVKA SW, IMPLEMENTACE

Předmětem dodávky je:

a. Multitenantní DMS, multilicence s licencí pro office online prostředí pro všechny uživatele (náhled) v prostředí online office včetně operačních systémů, databází a dalších licencí třetích stran

b. Licence pro office online prostředí pro všechny editory (editaci dokumentů) (dle počtů uvedených v tabulce č. 2)

c. Instalace DMS – instalace SW do virtuálního prostředí, konfigurace, nastavení prostředí jednotlivých uživatelských tenantů multitenantního jádra dokument management systému v požadované architektuře

d. Integrace – se systémy:

o Active Directory, LDAP (Třinec)

o DESA, edice DEA (důvěryhodný archiv)

o AC Identita (identity managment)

o Registr smluv

e. API – pro komunikaci s ERP a API pro předávání dat ze systému OCR

f. Aplikace elektronických procesů I. etapa:

o Řízená dokumentace organizací

o Schválení žádanky o přepravu

o Aplikace životního cyklu správy bezpečnostní dokumentace

o Aplikace pro podporu řízení kybernetických rizik

g. Migrace dat – Import stávající platné řídící a bezpečnostní dokumentace do DMS

h. Testovací provoz – v rámci testovacího provozu budou probíhat činnosti – školení, testování

4.3. ČÁST 3 – ŠKOLENÍ

Školení bude v rozsahu nutném pro zvládnutí každodenní správy systému v minimálním rozsahu 16 hodin pro administrátory a klíčové uživatele z každého uživatelského tenantu, školení bude probíhat v prostorách uživatelského tenantu a v termínech stanovených po dohodě s jednotlivými uživatelskými tenanty. Podmínkou je, že bude připraveno školící prostředí v rámci DMS předaného do zkušebního provozu umožňující správu vlastního uživatelského tenanta ve vazbě na školený uživatelský tenant.

Školení uživatelů a administrátorů bude zajištěno dodavatelem v rámci testovacího provozu. Dodavatel zajistí následující školení v rozsahu:

▪ školení administrátorů systémů zdravotnických zařízení, MSDC, a to maximálně 5 osob z každého zapojeného uživatelského tenantu

v rozsahu minimálně 1 den

▪ školení editorů bude probíhat prezenčně v jednotlivých uživatelských tenantech, pro určený počet osob uvedených v Tabulce č.2 z každého zapojeného uživatelského tenantu v rozsahu minimálně 1 den.

▪ školení uživatelů je možno provést přípravou e-learningového kurzu.

Konkrétní termíny určí objednatel dle postupu v rámci realizace projektu a dostupnosti zainteresovaných osob.

Součástí přípravy pro školení je vyhotovení školící dokumentace, která bude obsahovat postupy jednotlivých činností potřebných pro každodenní práci administraci systému s ohledem na implementaci v prostředí uživatelských tenantů.

4.4. Část 4 – Dokumentace

Dokumentace bude dodána v relevantním rozsahu vyplývajícího z předmětu plnění na všechna místa plnění projektu v tomto rozsahu:

a. Dokumentace – vypracování a předání kompletní dokumentace k centrálnímu DMS (dokumentace skutečného provedení), návodů a postupů (například havarijních – v případě výpadku, zálohovacích plánu a plánu obnovy v případě havárie).

b. Dokumentace pro školení – bude připravena před zahájením školení

c. Architektonická dokumentace – která bude zahrnovat podrobný popis architektury informačního systému po implementaci v členění podle jeho jednotlivých komponent a sdílených prvků nutných pro provoz daného systému.

o Popis architektury informačního systému bude obsahovat úplný výčet všech součástí informačního systému a jeho vazeb i vazeb na okolí, všech dostupných funkcí a poskytovaných služeb.

o Architektonická dokumentace bude vypracována v modelu architektury MSK v souladu s metodickými pokyny MSK, Ministerstva vnitra České republiky, odboru Hlavního architekta eGovernmentu, především však s Národním architektonickým rámcem (dále také „NAR“) (viz: xxxxx://xxxxx.xxx.xx/xxx_xxxxxxxx).

o Architektonické pohledy budou zpracovány a předány v architektonickém modelu MSK (model zahrnuje systémy a služby provozované a využívané KÚ a PO MSK) a ve standardizovaném modelovacím jazyku ArchiMate.

o Předání schémat arch. modelů ve zdrojovém tvaru (např. Archi – Open Source ArchiMate Modelling,).

Pokud v průběhu realizace dojde k úpravě prováděcí dokumentace, dodavatel změny zapracuje do architektonického modelu MSK v rámci poskytované technické podpory.

Dokumenty budou zpracovávány v následujícím elektronickém prostředí a uloženy v následujících formátech:

- MS Office (MS Word, MS Excel, MS PowerPoint)

- WinZip (formát .zip)

- Portable Document Format (formát .pdf)

- Archimate

4.5. ČÁST 5 - AKCEPTAČNÍ TESTY

Dodavatel je povinen kompletně připravit podklady pro akceptaci dodaného řešení. Součástí akceptace bude akceptační protokol a kompletní předávací dokumentace. Akceptační testování bude probíhat dle zpracovaných akceptačních scénářů v rámci Implementačního projektu v těchto oblastech:

a. Funkční testy ověří, že implementované řešení poskytuje bezchybně všechny požadované funkcionality uvedené v této Technické specifikaci, a to včetně požadovaných integrací,

b. Zátěžovými testy bude simulována práce uživatelů při obvyklých činnostech. Tím dojde k prověření vlastností dílčích celků řešení na produkčních systémech s generovanou zátěží,

c. Penetračním testem dojde k ověření úrovně bezpečnosti řešení metodou "etického hackingu". Výsledkem testů budou jednak případná přesně popsaná zjištění a identifikované slabiny, ale také konkrétní doporučení pro eliminaci zjištěných zranitelností,

Akceptační testování bude vykonáno v rámci testovacího provozu, a to po ukončení instalace a zprovoznění zařízení dle detailního harmonogramu zpracovaného zhotovitelem, na základě připravených a objednatelem schválených testovacích scénářů.

Akceptační testování je ukončeno, pokud v rámci akceptačního protokolu, kde je vždy zaznamenám výsledný stav, již jeho součástí není případný seznam nalezených vad a nedodělků. Pokud tomu takto není, tak je proces akceptace opakován, dokud Dodavatel neodstraní veškeré výhrady.

4.6. ČÁST 6 – TECHNICKÁ PODPORA

4.6.1. TECHNICKÁ PODPORA Podmínky poskytování technické podpory

● Systém musí zahrnovat standardní záruční (servisní) podporu výrobce software a dodavatele systému po celou dobu účinnosti smluvního vztahu.

● Požadovaná úroveň podpory na celé řešení je 7x24 po celou dobu účinnosti smluvního vztahu.

ZÁKLADNÍ SERVISNÍ PODPORA provozu SW
Kategorie vad SW	Příjem hlášení	Servisní garance
Kategorie vad SW	Příjem hlášení	Zahájení řešení	Servisní výjezd	Odstranění vady
Havárie – A	HelpDesk, telefonicky – 24x7	Neprodleně, nejpozději do 4 hodin po oznámení chyby v režimu 24*7	v případě nemožnosti opravy řešení on-line	musí být provedeno do 24 hodin od oznámení této vady dodavateli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.
Významná závada – B	HelpDesk9	Do 24 hodin po oznámení chyby v režimu 24*7	v případě nemožnosti opravy řešení on-line	musí být provedeno do 7 pracovních dní od oznámení této vady dodavateli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.
Závada, chyba – C	HelpDesk9	Do 120 hodin po oznámení chyby v rámci pracovní doby tj. od 7:00 do 16:00	v případě nemožnosti opravy řešení on-line	musí být provedeno do 30 pracovních dní od oznámení této vady dodavateli, pokud se smluvní strany v konkrétním případě nedohodnou písemně jinak.

Pro kategorizaci vad SW či jakéhokoliv jiného software platí následující pravidla:

(A) Chyba, která:

9 HelpDesk je provozován zadavatelem

a) znemožňuje užívání SW systému jako celku.

b) nebo znemožňuje užívání části SW systému, přičemž nemožnost užívání takové části SW systému může mít významný vliv na řádné zabezpečení běžné činnosti Objednatele a nelze jí schůdně překonat či obejít, nebo jí lze překonat či obejít pouze za cenu pro Objednatele vážných obtíží.

(B) Chyba, která nebrání v užívání SW systému ani jeho dílčích částí, neboť jí lze schůdně překonat či obejít, aniž by tím vznikaly pro Objednatele

vážné obtíže.

Požadované parametry, funkce, vlastnosti

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
	Základní požadavky
1.	Multitenantní architektura jednotného DMS včetně operačních systémů, databází a dalších licencí třetích stran, které systém bude využívat s centralizovaným ukládáním dokumentů a centrálním registrem nezdravotnické dokumentace pro ukládání metadat	ANO	ANO	instalace na jednom serveru, která umožní uživatelům z různých organizací používat vlastní prostor dle přístupových práv.
2.	Multitenantní systém s jednotlivými tenanty pro využití jednotlivými uživatelskými tenanty	ANO	ANO	-
3.	Pro konfiguraci centrální části multitenantní architektury nesmí mít současně administrátor práva ke správě a dokumentům jednotlivých uživatelských tenantů (pokud mu je však administrátor uživatelského tenata neudělí)	ANO	ANO	řešeno přístupovými právy a rolemi.
4.	Architektura Klient – Server	ANO	ANO	-
5.	Systém je provozován jako unifikované řešení a sdílí stejné programové jádro DMS	ANO	ANO	-
6.	Uložení dokumentů:	ANO	ANO	Soubory jsou ukládány na filesystém, šifrovány. V centrální

DMS

Požadováno/hodnota

Shoda nabízeného

(Ano/Ne)

Nabízené řešení, včetně vysvětlení, jak je zadání naplněno

(instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)

● využití centrálního úložiště dokumentů na bázi file systému,

● soubory v souborovém systémů jsou zašifrované pomocí symetrické kryptografie bezpečným algoritmem s dostatečnou délkou klíče a bez známé zranitelnosti.

● DMS ukládá soubory do souborového systému a do centrální databáze se ukládají pouze metadata

● umožnění antivirové kontroly uložených dokumentů

systémy třetích stran

databázi jsou pouze metadata. Na vstupu je dokument podroben antivirové kontrole.

Aplikační a DB serverové řešení musí být virtualizováno na platformě VMware a případně lokálně na platformě VMware nebo Hyper-V a to, z důvodu kompatibility a ochrany stávajících

investic zadavatele.

ANO

Přístup do DMS systému je možné přes webové rozhraní pomocí podporovaného webového prohlížeče (Edge, Firefox, Chrome, z

důvodu kompatibility a ochrany stávajících investic zadavatele)

ANO

přístup prostřednictvím prohlížečů je standardně ověřován.

Webové rozhraní systému umožňující personifikovaně na

dashboardu prezentovat obsah DMS

ANO

DMS má dashboard, který je možný upravovat jak centrální

správou, tak uživatelem.

10.

Autentizace uživatelů pomocí MS Active Directory, LDAP

eDirectory (Microfocus Novell)

ANO

obojí je LDAP ověření, pokud zákazník nemá SSO, tak používáme pro danou vrstvu

keycloak.

11.

Správa uživatelů, skupin a rolí, jejich synchronizací s AD, LDAP jednotlivých uživatelských tenantů apod. a jejich organizační strukturou

ANO

pokud to je jde, tak jsou při implementaci nastaveny integrační úlohy.

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
12.	Řízení přístupových oprávnění – každý uživatel vidí pouze ta data, která odpovídají jeho přístupovým právům	ANO	ANO	standardní vlastnost
13.	Administrační činnosti, a to na úrovni multitenantní architektury a rovněž na úrovni jednotlivých uživatelských tenantů např. výměna pracovníků, nastavení schvalovacích pravidel procesu	ANO	ANO	standardní vlastnost
14.	Víceúrovňová práva přístupu, podpora paralelní práce více uživatelů	ANO	ANO	-
15.	Systém bude podporovat tvorbu různých workflow z grafického prostředí využívající BPMN/BPEL spravovatelného administrátorem, a to na úrovni jednotlivých uživatelských tenantů	ANO	ANO	standardní vlastnost
16.	Role-based access control (RBAC) - rozdílní uživatelé mají práva k rozdílným funkcionalitám	ANO	ANO	-
17.	Podpora SSL komunikace	ANO	ANO	-
18.	Systém je provozován jako multitenantní řešení a sdílí stejné programové jádro DMS	ANO	ANO	standardní vlastnost
19.	Oddělená prezentační vrstva s využitím jádra DMS	ANO	ANO	standardní vlastnost
20.	Publikace – v rámci DMS bude k dispozici Dashboard uživatele s personifikovaným prostředím, ve kterém budou jednotlivým uživatelům publikovány dokumenty v těchto základních sekcích: • Aktivní pracovní plocha • Seznam úkolů plynoucích z jednotlivých workflow • Publikované dokumenty v příslušných sekcích/oblastech: o bezpečnostní portál pro oblast kybernetické bezpečnosti	ANO	ANO	standardní vlastnost

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
	o řídící dokumentace zdravotnického zařízení o a další konfigurovatelné sekce
21.	Mobilní prostředí s podporou schvalovacího řízení, aktivní notifikace a seznámení se s obsahem v rámci workflow procesu	ANO	ANO	standardní vlastnost prostřednictvím elektronické podpisové knihy, kde uživatel má na jednom místě schvalování s náhledem obsahu.
22.	Webové rozhraní s responzivním designem bez nutnosti instalace klientské části pomocí protokolu HTTPS z mobilního prostředí.	ANO	ANO	standardní vlastnost
23.	Centrálně provozovaná část systému využívaná všemi uživatelskými tenanty	ANO	ANO	standardní vlastnost
24.	Auditní logy (journal log)	ANO	ANO	-
25.	Auditní logování s připraveným rozhraním pro přenos auditních logů do centrálního log managementu/SIEM	ANO	ANO	standardní vlastnost
26.	Centrální provoz multitenatního DMS on premise	ANO	ANO	standardní vlastnost
27.	Primární jazyk pro komunikaci – čeština	ANO	ANO	-
28.	Dokumentace bude dodána v českém jazyce	ANO	ANO	-
29.	DMS naplní všechny požadavky uvedené v této technické specifikaci	ANO	ANO	-
30.	DMS systém musí splňovat zákonné požadavky na zpracování a ochranu dat – dle legislativy z oblasti elektronických dokumentů a transakcí, účetních dokladů, archivnictví, GDPR a ZoKB		ANO	-
31.	Licenční model – multilicence	ANO	ANO	-
32.	Licence pro office online prostředí pro všechny editory (editaci dokumentů) a pro všechny uživatele (náhled) v prostředí online office v počtech uvedených v tabulce č.2	ANO	ANO	-

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
Interface
33.	důvěryhodný archiv DESA edice DEA.	ANO	ANO	bude implementován při dodávce
34.	API pro realizaci interface k OCR a ERP systémům třetích stran	ANO	ANO	standardní vlastnost, bude revidováno při dodávce
35.	IDM – podpora přenosu organizační struktury z IDM AC Identita (na úrovni jednotlivých uživatelských tenantů	ANO	ANO	bude implementován při dodávce
36.	Microsoft Active Directory/ LDAP eDirectory (Microfocus Novell)	ANO	ANO	konfigurační položka
37.	Message Broker	ANO	ANO	konfigurační položka prostřednictvím modulu EXT
38.	Registr smluv	ANO	ANO	implementace v modulu EXT, bude revidováno při dodávce
Funkcionalita jádra DMS
39.	DMS systém musí disponovat uživatelským prostředím na koncové stanici v OS Windows v českém jazyce	ANO	ANO	-
40.	Možnost uložení všech běžných typů dokumentů – PDF, Microsoft Office Open XML (OOXML) a OASIS Open Document Format for Office Applications (ODF) minimálně pro textový dokument (DOCX, ODT), tabulkový dokument (XLSX, ODS) a prezentaci (PPTX, ODP), obrazové formáty	ANO	ANO	-
41.	Náhledy běžných formátů – PDF, Office, obrazové formáty	ANO	ANO	-
42.	Možnost otevření dokumentu přímo v online prostředí DMS (nebo integrované komponenty třetí strany – online office) – internetovém prohlížeči pro současnou práci, více uživatelů na jednom dokumentů.	ANO	ANO	standardní vlastnost prostřednictvím komponenty ONLYOFFICE
43.	Online office prostředí v rámci jádra DMS musí podporovat formáty Microsoft Office Open XML (OOXML) a OASIS Open	ANO	ANO	standardní vlastnost

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
	Document Format for Office Applications (ODF) minimálně pro textový dokument (DOCX, ODT), tabulkový dokument (XLSX, ODS) a prezentaci (PPTX, ODP), pro otevření, editaci a uložení těchto formátů a podporou pro revizi dokumentu – sledování změn a komentáře. Vzhled otevřeného dokumentu musí odpovídat původní definici formátování.
44.	Podpora životního cyklu dokumentu (zpracování, připomínkování, schvalovací řízení, vydání, seznámení s obsahem, revize, zrušení archivace) a publikace v Registru smluv	ANO	ANO	standardní vlastnost
45.	Podpora pro možnost automatické konverze dokumentu do pdf formátu při životním cyklu „schvalovací řízení“ a „vydání“ dokumentu	ANO	ANO	standardní vlastnost, možnost rozšíření konverze do archivního PDF
46.	Podpora anonymizace – začerňování citlivých údajů podléhající zákonu o registru smluv (340/2015 Sb.) s možností automatického odesílání do registru smluv.	ANO	ANO	-
47.	Responsivní design	ANO	ANO	-
48.	Podpora týmové práce nad tvorbou jednotlivých dokumentů	ANO	ANO	standardní vlastnost
49.	Splnění povinných úkonů dle nastaveného kalendáře – správa termínů (stanovení, hlídání a notifikace) s podporou generování kalendářových plánovacích informací ve formátu iCAL dle RFC 5545	ANO	ANO	standardní vlastnost
50.	Možnost zapnutí komprese ukládaných dokumentů	ANO	ANO	-
51.	Nástroj pro tvorbu/úpravu formulářů metadat k jednotlivým třídám dokumentů na straně klíčových uživatelů	ANO	ANO	standardní vlastnost
52.	Nelimitovaný počet dokumentových tříd	ANO	ANO	standardní vlastnost

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
53.	Nelimitovaný počet klasifikátorů v rámci jedné dokumentové třídy	ANO	ANO	standardní vlastnost
54.	Automatické generování unikátního identifikátoru dokumentu podle masky (číselná řada) na úrovni jednotlivých tenantů	ANO	ANO	standardní vlastnost
55.	Možnost/povinnost definovat povinnost vyplnění hodnoty v metadatech při vkládání dokumentu do úložiště	ANO	ANO	standardní vlastnost
56.	Možnost definovat pole metadat pouze pro čtení bez možnosti změny hodnoty	ANO	ANO	standardní vlastnost
57.	Vložení prostřednictvím uživatelského rozhraní webové aplikace	ANO	ANO	standardní vlastnost
58.	Zaslání/vložení dokumentu ze skeneru	ANO	ANO	standardní vlastnost, např. nahráním do složky.
59.	Zaslání/vložení dokumentu prostřednictvím sběrného emailu/IMAP účtu	ANO	ANO	standardní vlastnost
60.	Vložení dokumentu prostřednictvím API	ANO	ANO	standardní vlastnost
61.	Podpora automatického verzování dokumentů	ANO	ANO	standardní vlastnost
62.	Automatické propojení souvisejících dokumentů na základě hodnot v metadatech dokumentů – pojmenovaná vazba	ANO	ANO	standardní vlastnost, ale musí být konfigurována v rámci implementace
63.	Vzájemné prolinkování souvisejících dokumentů	ANO	ANO	standardní vlastnost
64.	Možnost generování dokumentů ze šablon po doplnění hlavičkových hodnot do dokumentu po vyplnění formuláře	ANO	ANO	standardní vlastnost, docx šablony v dokument generátoru.

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
65.	Vytváření dokumentů ze statických šablon bez doplnění hodnot z formuláře.	ANO	ANO	standardní vlastnost
66.	Vytváření dokumentů z interaktivních formulářů	ANO	ANO	standardní vlastnost
67.	Uživatelské rozhraní s možností přístupu v klasické stromové struktuře	ANO	ANO	standardní vlastnost
68.	Vyhledání dokumentů full-textově	ANO	ANO	standardní vlastnost
69.	Vyhledání dokumentů dle metadat	ANO	ANO	standardní vlastnost
70.	Kombinace vyhledání fultextem a dle metadat	ANO	ANO	standardní vlastnost
71.	Možnost uložení filtrů pro budoucí rychlé použití – sdílené v týmu, privátní	ANO	ANO	standardní vlastnost
72.	Permanentní link na dokument, složku	ANO	ANO	standardní vlastnost
73.	Permanentní link na dokument pro veřejný přístup bez přihlášení	ANO	ANO	standardní vlastnost
74.	Podpora linku uvnitř dokumentu – přímý odkaz z dokumentu na jiný související dokument	ANO	ANO	standardní vlastnost
75.	Řízení přístupu k vybraným akcím dostupným pro daný dokument na základě role uživatele.	ANO	ANO	standardní vlastnost
76.	Možnost definice vlastních schémat pro procesy vlastními silami na straně zákazníka	ANO	ANO	standardní vlastnost
77.	Grafický proces designer využívající BPMN/BPEL	ANO	ANO	standardní vlastnost
78.	Automatické spouštění procesů – na základě data	ANO	ANO	standardní vlastnost
79.	Automatické spouštění procesů – na základě změny v hodnotách metadat	ANO	ANO	standardní vlastnost
80.	Automatické spouštění procesů – na základě vložení/změny dokumentů	ANO	ANO	standardní vlastnost

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
81.	Variantní průběh workflow na základě hodnot v metadatech konkrétního dokumentu	ANO	ANO	standardní vlastnost
82.	Vícekroková workflow – sekvenční schéma	ANO	ANO	standardní vlastnost
83.	Paralelní úkoly – všichni se vyjádří	ANO	ANO	-
84.	Paralelní úkoly – vyjádří se část ze skupiny	ANO	ANO	-
85.	Podpora sekvenčního procesu	ANO	ANO	standardní vlastnost
86.	Podpora paralelního procesu	ANO	ANO	standardní vlastnost
87.	Předání úkolu na jiného řešitele	ANO	ANO	-
88.	Dokumenty je možné klasifikovat dle uživatelského tenantu	ANO	ANO	-
89.	Dokumenty je možné klasifikovat dle jejich důvěrnosti	ANO	ANO	-
90.	Přístup k dokumentům je možné omezit pouze na určený rozsah uživatelských tenantů, uživatelů, či rolí	ANO	ANO	standardní vlastnost
91.	V předem definovaných intervalech řešení umožňuje synchronizovat vybrané číselníkové hodnoty, např. z IDM do prostředí číselníků DMS	ANO	ANO	standardní vlastnost
92.	Přehledová nástěnka se všemi relevantními dokumenty	ANO	ANO	standardní vlastnost
93.	Umožnění práce v týmech (ne pouze v týmech na úrovni jednotlivých uživatelských tenantů) pro zpracování bez ohledu na jejich konkrétní přidělení (uživatel si proces převezme a ostatní členové týmu vidí, že proces je již zpracováván jiným členem týmu na základě funkce check in / check out)	ANO	ANO	standardní vlastnost

DMS		Požadováno/hodnota	Shoda nabízeného (Ano/Ne)	Nabízené řešení, včetně vysvětlení, jak je zadání naplněno (instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)
94.	Možnost otevření dokumentu v DMS v prostředí Microsoft Office s využitím funkce check in / check out, včetně verzování	ANO	ANO	standardní vlastnost
95.	Podpora životního cyklu: ● Vzniku dokumentů: - z připravených šablon a inteligentních formulářů - scanem a OCR s vytěžením dokumentu (pro případný přenos dat do ERP) ● Připomínkového řízení ● Schvalovacího řízení ● Aplikace elektronických procesů ● Vydání dokumentů ● Průkazného seznámení s obsahem ● Ukládání a vyhledávání ● Přezkoumání platnosti/neplatnosti ● Archivace a skartace	ANO	ANO	standardní vlastnost
Aplikace elektronických procesů (dle v textu uvedených požadavků)
96.	Aplikace elektronických procesů pro řízenou dokumentaci v jednotlivých zdravotnických zařízeních (tenanti příslušných zdravotnických zařízení)	ANO	ANO	-
97.	Aplikace elektronických procesů bezpečnostní dokumentace (uživatelský tenant MSDC)	ANO	ANO	-
98.	Aplikace elektronických procesů žádanky o přepravu (tenanti příslušných zdravotnických zařízení)	ANO	ANO	-
99.	Podpora pro řízení rizik kybernetické bezpečnosti (tenant MSDC využívávaný jednotlivými ZZ)	ANO	ANO	-
	Záruka a podpora

DMS

Požadováno/hodnota

Shoda nabízeného

(Ano/Ne)

Nabízené řešení, včetně vysvětlení, jak je zadání naplněno

(instrukce [DOPLNÍ ÚČASTNÍK] je uvedena u položek, kde je popis relevantní)

100

Režim 24x7 viz odstavec 2. Servisní služby

Doba neurčitá (pro účely zpracování

nabídky a hodnocení bude naceněno 48 měsíců)

ANO

V případě nesplnění minimálních požadovaných parametrů, funkcí, vlastností, (i jednoho) viz tabulka výše, se jedná o nesplnění zadávacích podmínek

Příloha č. 2 - Položkový rozpočet

Část	Název položky	Počet jednote k	Počet licencí	Cena v Kč bez DPH za 1 jednotku	Celková cena v Kč bez DPH	DPH (%)	Výše DPH v Kč	Celková cena v Kč vč. DPH
A1	Implementační projekt (část 1.)	1	-	2 476 800 Kč	2 476 800 Kč	21%	520 128 Kč	2 996 928 Kč
A2	Dodávka DMS, Implementace (část 2.)
	- Multilicence DMS s licencí pro office online prostředí pro všechny uživatele (náhled) v prostředí online office	-	1	3 500 000 Kč	3 500 000 Kč	21%	735 000 Kč	4 235 000 Kč
	- Licence pro office online prostředí v rámci DMS - editoři	-	785	1 433 Kč	1 125 000 Kč	21%	236 250 Kč	1 361 250 Kč
	- Integrace:
	o Active Directory, LDAP (Třinec)	0	-	000 000 Kč	120 400 Kč	21%	25 284 Kč	145 684 Kč
	o VEMA – (organizační struktury)	0	-	000 000 Kč	150 000 Kč	21%	31 500 Kč	181 500 Kč
	o DESA, edice DEA (důvěryhodný archiv)	0	-	000 000 Kč	150 000 Kč	21%	31 500 Kč	181 500 Kč
	o Registr smluv	0	-	000 000 Kč	150 000 Kč	21%	31 500 Kč	181 500 Kč
	- API – pro komunikaci s ERP a API pro předávání dat ze systému OCR	0	-	000 000 Kč	100 000 Kč	21%	21 000 Kč	121 000 Kč
	- Aplikace elektronických procesů I. etapa:
	o Řízená dokumentace organizací	0	-	000 000 Kč	490 000 Kč	21%	102 900 Kč	592 900 Kč
	o Schválení žádanky o přepravu	0	-	000 000 Kč	495 340 Kč	21%	104 021 Kč	599 361 Kč
	o Aplikace životního cyklu správy bezpečnostní dokumentace	0	-	000 000 Kč	334 000 Kč	21%	70 140 Kč	404 140 Kč
	o Aplikace pro podporu řízení kybernetických rizik	0	-	000 000 Kč	400 000 Kč	21%	84 000 Kč	484 000 Kč
	o Migrace dat, testovací provoz	1	-	1 444 800 Kč	1 444 800 Kč	21%	303 408 Kč	1 748 208 Kč
A3	Dokumentace, Školení, Akceptační testy (část 3., 4., 5.)	1	-	1 032 000 Kč	1 032 000 Kč	21%	216 720 Kč	1 248 720 Kč
A4	Technická podpora (část 6.) po dobu 12 měsíců*	4	-	1 632 494 Kč	6 529 976 Kč	21%	1 371 295 Kč	7 901 271 Kč
	CENA DODÁVKY CELKEM	-		-	18 498 316 Kč		3 884 646 Kč	22 382 962 Kč

Pozn. * - Jedná se o model kalkulace nabídkové ceny (počet jednotek byl stanoven pro účely hodnocení). Zadavatel je oprávněn využívat technické podpory po dobu platnosti smluvního vztahu.

Příloha č.3 – Pravidla zákaznického auditu

1 ÚČEL

Účelem této přílohy je stanovit pravidla pro audit prováděný na straně dodavatele v rozsahu plnění Smlouvy na dodávku a implementaci jádra a aplikaci elektronických procesů jednotného multitenantního dokument management systému (dále jen „DMS“), která byla uzavřena v návaznosti na výsledek zadávacího řízení na veřejnou zakázku Dodávka a implementace jádra a aplikace elektronických procesů v Dokument management systému (dále jen „veřejná zakázka“ a „Smlouva“). Dodavatelem se rozumí zhotovitel dle Xxxxxxx a Zadavatelem se rozumí objednatel dle Xxxxxxx.

2 ROZSAH PLATNOSTI

Tento dokument je závazný pro všechny dodavatele a poddodavatele dle Smlouvy.

3 PRAVIDLA AUDITU

3.1 OBECNĚ

Dodavatel se bude v rozsahu předmětu plnění dle Smlouvy aktivně podílet na splnění povinností uvedených v § 8 a § 16 VKB, které musí splnit Zadavatel. Zejména se Dodavatel zavazuje v rozsahu předmětu plnění dle Xxxxxxx poskytnout adekvátní součinnost při výkonu kontroly Zadavatele ze strany Národního úřadu pro kybernetickou a informační bezpečnost dle § 23 ZKB.

Dodavatel umožní Zadavateli alespoň jednou ročně po dobu účinnosti Smlouvy provedení auditu kybernetické bezpečnosti u Dodavatele a jeho poddodavatelů.

Rozsah auditu bude ohraničen využíváním ICT prostředků Dodavatele pro potřeby plnění Smlouvy a uloženými či zpracovávanými daty a informacemi Zadavatele v ICT prostředí Dodavatele a jehož předmětem bude naplnění Kybernetických požadavků a vyhodnocení rizik dle bodu 3.4 tohoto dokumentu.

Zadavatel je oprávněn při auditu kybernetické bezpečnosti využít třetí stranu. V případě využití třetí strany bude Zadavatel odpovídat za třetí stranu, jako by audit kybernetické bezpečnosti prováděl sám, včetně odpovědnosti za způsobenou újmu.

Dodavatel umožní Zadavateli audit kybernetické bezpečnosti provedený prostředky Zadavatele nebo třetí strany, a to v lokalitě Dodavatele i vzdáleně, pokud to technické prostředky Dodavatele umožňují.

3.2 NEDOSTATKY A NESHODY

Dodavatel je povinen odstranit nedostatky zjištěné:

● na základě provedení hodnocení rizik bezpečnosti informací dle bodu 3.4 tohoto dokumentu, nebo

● v rámci auditu kybernetické bezpečnosti

Dodavatel je povinen odstranit nedostatky/neshody ve lhůtě určené v písemném oznámení Zadavatele, která nebude kratší než 20 pracovních dní od doručení oznámení. Nestanoví-li Zadavatel lhůtu v písemném oznámení, zavazují se Smluvní strany dohodnout na lhůtě pro odstranění nedostatku, která nepřevýší 90 dní od doručení oznámení. V případě, že i po této lhůtě nebudou nedostatky/neshody odstraněny, má Zadavatel možnost jednostranně odstoupit/vypovědět Smlouvu; současně má Zadavatel nárok na smluvní pokutu dle Smlouvy, a to za každý započatý den prodlení se splnění povinnosti odstranit nedostatky dle tohoto odstavce.

3.3 DALŠÍ POVINNOSTI

Dodavatel je dále povinen poskytnout na vyžádání Zadavateli dokumenty a obdobné vstupy, které budou prokazovat naplnění Kybernetických požadavků.

Na požádání se Zadavatelem konzultovat kdykoli v průběhu realizace plnění dle Smlouvy detailní nastavení bezpečnostních opatření k naplnění kybernetických požadavků a pro takovéto konzultace zajistit účast kvalifikovaných pracovníků.

Dodavatel je dále povinen neprodleně informovat Zadavatele o všech významných změnách v naplnění Kybernetických požadavků, které nastanou kdykoli v průběhu trvání Smlouvy.

Dále je dodavatel povinen bezodkladně a s vyvinutím nejlepšího úsilí zajistit náhradní způsob naplnění kybernetických požadavků, pokud stávající řešení přestalo být funkční a efektivní.

Dodavatel při výkonu své činnosti včas a prokazatelně upozorní Zadavatele na zřejmou nevhodnost jeho požadavků či doporučení vztahující se ke Kybernetickým požadavkům, jejichž následkem může vzniknout újma nebo nesoulad se zákony nebo jinými obecně závaznými právními předpisy.

3.4 ŘÍZENÍ RIZIK V ROZSAHU PLNĚNÍ VEŘEJNÉ ZAKÁZKY

Dodavatel se bude v rozsahu předmětu plnění veřejné zakázky aktivně podílet na splnění povinností uvedených v § 5 VKB, které musí splnit Zadavatel.

Minimálně se Dodavatel zavazuje v rozsahu předmětu plnění veřejné zakázky na své straně:

● Řídit vlastní rizika, která mohou ovlivnit poskytování předmětu plnění dle Smlouvy.

● V minimálním intervalu jednou ročně (nebo i v případě významných změn činností prováděných pro Zadavatele nebo změn při poskytování dodávky, implementace a zajištění provozu DMS vytvořit a bude- li to Zadavatel požadovat, předložit mu zprávu o hodnocení rizik, která bude minimálně pokrývat:

a) Vyhodnocení stavu kybernetické bezpečnosti za hodnocený rok;

b) Identifikaci a hodnocení rizik s vazbou na předmět plnění;

c) Realizovaná bezpečnostní opatření;

d) Nepokrytá bezpečnostní rizika a návrh opatření;

e) Vyhodnocení bezpečnostních událostí a incidentů;

f) Aktuální stav souladu Dodavatele s Kybernetickými požadavky včetně přehledu Kybernetických požadavků, které

o nebyly aplikovány, včetně odůvodnění, a

o byly aplikovány, včetně způsobu plnění.

Příloha č.4 – Pravidla vzdáleného přístupu

1 ÚČEL

Účelem této přílohy je stanovit pravidla pro vzdálený přístup dodavatele v rozsahu plnění Smlouvy na dodávku a implementaci jádra a aplikaci elektronických procesů jednotného multitenantního dokument management systému (dále „DMS“), která byla uzavřena v návaznosti na výsledek zadávacího řízení na veřejnou zakázku

„Dodávka a implementace jádra a aplikace elektronických procesů v Dokument management systému“ (dále jen

„veřejná zakázka“ nebo „Smlouva“). Dodavatelem se rozumí zhotovitel dle Xxxxxxx a Zadavatelem se rozumí

objednatel dle Smlouvy.

2 ROZSAH PLATNOSTI

Tato pravidla jsou závazná pro všechny dodavatele a poddodavatele dle Smlouvy.

3 ZKRATKY, POJMY A DEFINICE

Moravskoslezské datové centrum, příspěvková organizace	MSDC	subjekt na straně uživatelů, který bude mít systém ve správě
Zdravotnické zařízení	ZZ	Nemocnice Havířov, p. o., Nemocnice Karviná-Ráj, p. o., Sdružené zdravotnické zařízení Krnov, p. o., Nemocnice Třinec p. o., Slezská nemocnice v Opavě, p. o., Nemocnice ve Frýdku-Místku p. o. a Bílovecká nemocnice, a.s. (subjekty na straně uživatelů)
Information Security Management System	ISMS	Systém managementu bezpečnosti informací
Manažer kybernetické bezpečnosti	MKB	Odpovědný zaměstnanec MSDC za řízení a provádění provozních činností spojených s ISMS.
Odpovědný zaměstnanec	OZ	Zaměstnanec MSDC s delegovanou pravomocí za danou činnost nebo proces. Zpravidla se jedná o osobu odpovědnou za provoz Hospital Cloudu

4 OBECNĚ

Vzdálený přístup je nezbytným předpokladem včasného řešení požadavků Objednatele nebo uživatelů týkajících se problémů a chyb v dodávaných produktech nebo službách poskytovaných v rámci Smlouvy. Z důvodů zajištění informační a kybernetické bezpečnosti je nutné definovat pravidla a postupy pro vzdálený přístup. Jiné způsoby, které nejsou definovány těmito pravidly, jsou možné pouze ze závažných důvodů, které musí být schváleny MKB a OZ. O schválení v případě závažných důvodů musí být veden dokumentovaný záznam.

5 PRÁVA A POVINNOSTI

Vzdálený přístup k aplikacím a službám DMS je poskytován výhradně zaměstnancům Dodavatele, kteří jsou schválení MKB a OZ v rozsahu vyplývajícím ze smluvního vztahu a na dobu plnění povinností vyplývajících ze Smlouvy. Vzdálený přístup nelze bez výslovného souhlasu MKB a OZ převádět na jinou osobou. Je zakázáno vytvářet tzv. „společné účty“, a je zakázáno sdílení účtu mezi zaměstnanci Dodavatele. Každý jednotlivý zaměstnanec Dodavatele, který vyžaduje vzdálený přístup má svůj jedinečný účet.

Dodavatel nesmí měnit nastavení vzdáleného přístupu, které provedl OZ a neprovádět jiné neoprávněné zásahy, které mohou změnit, omezit, poškodit nebo znemožnit provoz aplikací a služeb. Pokud by v souvislosti s plněním smluvních povinností bylo nutné takový zásah uskutečnit, je to možné pouze po předchozí dohodě s OZ a MKB. Před uskutečněním takového zásahu musí být posouzena rizika, která s těmito zásahy souvisí, a pokud je to technicky možné, je třeba vypracovat plán pro navrácení do původního stavu v případě negativního výsledku zásahu. O tomto zásahu musí být veden dokumentovaný záznam.

Dodavatel je povinen vždy informovat OZ o uskutečnění vzdáleného přístupu. Pokud se jedná o plánovanou činnost, je Dodavatel povinen tuto skutečnost oznámit nejméně 3 dny dopředu OZ. Oznámení musí obsahovat minimálně informace, které jsou zmíněny níže v odrážkách.

Dodavatel je povinen prokazatelně evidovat veškeré vzdálené přístupy na dotčené technické prostředky uživatelů, a to minimálně v rozsahu:

● Začátek připojení

● Konec připojení

● Uživatelské jméno

● Xxxxx zaměstnance Dodavatele

● Cíl připojení

● Účel připojení

Dodavatel je povinen na vyžádání tuto evidenci poskytnout. Dodavatel bere na vědomí, že Objednatel nebo uživatel má právo veškerou činnost související se vzdáleným přístupem zaznamenávat a záznamy archivovat.

Dodavatel je povinen se řídit pravidly pro ochranu osobních údajů, dat a mlčenlivosti dle Xxxxxxx. OZ má právo kdykoliv Dodavateli jednostranně ukončit možnost vzdáleného přístupu.

Dodavatel je povinen v případě zániku pracovněprávního vztahu zaměstnance Dodavatele, který má na základě těchto pravidel zřízen vzdálený přístup k aplikacím a službám oznámit tuto skutečnost, a to ve lhůtě do zániku pracovněprávního vztahu zaměstnance Dodavatele.

5.1 OCHRANA OSOBNÍCH ÚDAJŮ

Dodavatel v souvislosti s plněním této Smlouvy předává OZ předem dohodnutým způsobem osobní údaje zaměstnance Dodavatele, který má přístupová práva k aplikacím a sužbám OZ připojeným přes vzdálený přístup v rozsahu Smlouvy. Dodavatel prohlašuje, že poskytnuté osobní údaje zaměstnance Dodavatele jsou přesné a úplné a zavazuje se OZ neprodleně informovat o veškerých jejich změnách (tj. opravách, omezeních či výmazech). OZ po přijetí těchto osobních údajů s nimi dále nakládá v postavení správce zpracovávajícího osobní údaje na

základě jeho oprávněného zájmu, a to za účelem řízení a kontroly přístupů externích uživatelů k aplikacím a zařízením datových sítí uživatelů a za účelem zajištění integrity zpracovávaných dat. Uživatel se zavazuje osobní údaje zaměstnance Xxxxxxxxxx zpracovávat pouze po dobu, po kterou bude Dodavateli poskytován vzdálený přístup dle této Smlouvy.

Smluvní strany se zavazují nakládat s osobními údaji zaměstnanců Dodavatele v souladu s právními předpisy, zejména podle nařízení Evropského parlamentu a Rady (EU) 679/2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (dále jen „obecné nařízení o ochraně osobních údajů“), a poskytovat si součinnost při plnění povinností vyplývajících z těchto právních předpisů v rámci zpracování osobních údajů zaměstnanců Dodavatele.

Objednatel se zavazuje zajistit vhodným způsobem bezpečnostní, technická a organizační opatření dle článku 32 obecného nařízení o ochraně osobních údajů tak, aby v souvislosti se shora uvedenou činností nemohlo na její straně dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití osobních údajů. Smluvní strany se zavazují, že si bez zbytečného odkladu sdělí jakékoliv podezření z nedostatečného zabezpečení osobních údajů zaměstnance Dodavatele nebo z porušení tohoto zabezpečení.

6 POŽADAVKY NA UŽIVATELE

6.1 ŽÁDOST O VZDÁLENÝ PŘÍSTUP

Každý zaměstnanec Dodavatele, který vyžaduje vzdálený přístup, je povinen zažádat o tento přístup OZ pomocí e-mailu. Žádost musí obsahovat jméno zaměstnance Dodavatele a účel pro vzdálený přístup. Následně OZ schválí nebo zamítne zřízení vzdáleného přístupu. MSDC vede o zaměstnancích Dodavatele, majících vzdálený přístup, evidenci. MSDC po založení vzdáleného přístupu informuje žadatele společně s popisem, jak vzdálený přístup uskutečnit.

6.2 POŽADAVKY NA ZAŘÍZENÍ, KTERÝM JE USKUTEČŇOVÁN VZDÁLENÝ PŘÍSTUP

Zařízení, kterým je uskutečňován vzdálený přístup, musí splňovat následující požadavky:

● Používání pouze podporovaného operačního systému

● Používání antivirové ochrany s aktuální databází škodlivého kódu

● Firewall, který je součástí OS, nesmí být vypnutý

● Provádění pravidelné a včasné aktualizace používaného operačního systému a SW aplikací (min 1x měsíčně u běžných aktualizací a nejpozději 24 hod. po vydání bezpečnostní aktualizace)

● Přístup k zařízení minimálně pomocí jména a silného hesla (pravidla pro silné heslo jsou zmíněny

v kapitole 6.2.1) nebo pomocí biometriky nebo dvoufázového ověření

● Nepoužívat zařízení „osobního charakteru“ tj. zařízení, které je ve vlastnictví uživatele a je používáno převážně k osobním účelům

Dodavatel bere na vědomí, že zařízení, kterými je uskutečňován vzdálený přístup mohou být součástí zákaznického auditu, a že požadavky viz výše mohou být vynucovány i technickými prostředky na straně MSDC.

6.2.1 ZÁSADY SILNÉHO HESLA

● Délka hesla alespoň 17 znaků

● Kombinace malých a velkých písmen, číslic a speciálních znaků

● Nesmí zde být souvislost mezi uživatelem a heslem, tj. celé jméno nebo příjmení, datum narození apod.

Příklady silného hesla:

● TohleJeSilneHeslo15.

● 33NechciBruteforceHesla#

● NaDelceHeslaZalezi@12

● {oKl87ghTsj#WrF22

Document Metadata

Table of Contents

Základní ustanovení

Document Metadata