SMLOUVA O DÍLO
uzavřená v souladu s § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „OZ“)
mezi stranami:
Česká republika – Státní ústav pro kontrolu léčiv, organizační složka státu IČ: 00023817
se sídlem: Xxxxxxxxx 00, 000 00 Xxxxx 00 zastoupena: Mgr. Xxxxxx Xxxxxxxx, MHA, ředitelkou bankovní spojení, č.ú.: 623101/0710
(dále jen "Objednatel") a
PHYSTER TECHNOLOGY, a.s.
IČ: 27091937
DIČ: CZ27091937
se sídlem: Xxxxxxxxxxx 000/00, Xxxxx 0 – Xxxxx, 142 00
zastoupen: XXX
bankovní spojení, č.ú.: XXX
(dále jen „Zhotovitel“)
(Objednatel a Zhotovitel dále společně také jen jako „smluvní strany“)
Preambule
Objednatel vyhlásil jako zadavatel veřejné zakázky zadávací řízení č. VZ05/2022 „Vývoj a zajištění podpory Informačního systému pro vedení a zpracování správních řízení“, v němž byla nabídka podaná Zhotovitelem vyhodnocena jako nejvýhodnější, a proto Objednatel se Zhotovitelem jako vybraným dodavatelem uzavírá tuto smlouvu o dílo (dále jen „Smlouva“):
Článek 1.
Předmět a účel Smlouvy
1.1 Zhotovitel se zavazuje, že pro Objednatele na svůj náklad a nebezpečí vytvoří Informační systém pro vedení a zpracování správních řízení (dále také jen jako „dílo“, v užším slova smyslu zahrnujícím informační systém jen „Systém“). Toto dílo provede v souladu se specifikací a za podmínek stanovených touto Smlouvou. Objednatel se zavazuje dílo včas a řádně dokončené v souladu s touto Smlouvou převzít a zaplatit za něj Zhotoviteli dle podmínek této Smlouvy cenu stanovenou článkem 6.
1.2 Dílo tvoří následující části:
a) zpracování prováděcího projektu díla, kterým se bude řídit postup provádění částí díla uvedených v odst. 1.2 písm. b) až i). Prováděcí projekt musí zahrnovat harmonogram provádění, požadovanou součinnost pracovníků Objednatele a další náležitosti definované v části 5.2 Přílohy č. 1 této Smlouvy. Prováděcí projekt bude předán v elektronické formě ve formátu MS Word a formátu PDF;
b) návrh, vývoj a dodání Systému dle specifikací uvedených v Příloze č. 1 této Smlouvy v prováděcím projektu díla podle xxxxxxx a), vč. veškerých zdrojových kódů, nezbytných pro jeho údržbu, úpravy/změny, aktualizace, případné modernizace a další činnosti, ke kterým je Objednatel oprávněn na základě Článku 10. Součástí bude i vytvoření vývojového prostředí na straně Zhotovitele;
c) implementace Systému v testovacím prostředí Objednatele, tj. instalace a integrace dodaného Systému s ostatními systémy Objednatele dle specifikací v části 3.1.2 Přílohy č. 1 této Smlouvy;
d) dodání technické a uživatelské dokumentace v rozsahu a formátu specifikovaném v části
4.1 Přílohy č. 1 této Smlouvy;
e) vyškolení uživatelů v rozsahu specifikovaném v části 4.2 Přílohy č. 1 této Smlouvy;
f) provedení testu migrace dat ze stávajícího informačního systému Objednatele do
testovacího prostředí Systému dle specifikace v části 5.5 Přílohy č. 1 této Smlouvy;
g) provedení funkčních, integračních, bezpečnostních, výkonových a zátěžových testů Systému na testovacím prostředí,
h) podpora uživatelských akceptačních testů Objednatele.
i) nasazení Systému do produkčního prostředí v rozsahu dle specifikace a postupu uvedeného v části 5.7 Přílohy č. 1 této Smlouvy, včetně provedení migrace dat ze stávajících informačních systémů a podpory pilotního provozu Systému.
1.3 Při zpracování prováděcího projektu díla podle odst. 1.2 písm. a), je Zhotovitel povinen v části týkající se řešení přehledné nástěnky (dashboardu) pro roli Manažer vycházet z návrhu, který předložil jako účastník řízení v rámci zadávacího řízení veřejné zakázky č. VZ05/2022 „Vývoj a zajištění podpory Informačního systému pro vedení a zpracování správních řízení“. Návrh Zhotovitele podle věty první tvoří Přílohu č. 2 této Smlouvy.
1.4 Podrobná specifikace díla a jeho jednotlivých částí je obsažena v Příloze č. 1, která je nedílnou součástí této Smlouvy. Podrobná specifikace částí díla dle odst. 1.2 písm. b) až i) bude dále specifikována v řádně akceptovaném prováděcím projektu vytvořeném Zhotovitelem dle odst. 1.2 písm. a). V případě rozporu specifikace díla uvedené v této Smlouvě nebo jejích přílohách a specifikace díla uvedené v řádně akceptovaném prováděcím projektu vytvořeném Zhotovitelem dle odst. 1.2 písm. a), má přednost specifikace díla uvedená v akceptovaném prováděcím projektu.
1.5 Rozsah a kvalita díla musí být v souladu především:
a) s podmínkami stanovenými touto Smlouvou;
b) s příslušnými normami a technickými předpisy platnými v době provádění díla;
c) s právními předpisy;
d) se zadávací dokumentací veřejné zakázky č. VZ05/2022 „Vývoj a zajištění podpory Informačního systému pro vedení a zpracování správních řízení“ a jejími přílohami;
e) s příkazy Objednatele vydanými v souladu s touto Smlouvou.
1.6 Zhotovitel potvrzuje, že se v plném rozsahu seznámil s rozsahem a povahou díla, že jsou mu známy a rozumí veškerým dostupným technickým, kvalitativním a jiným podmínkám nezbytným k realizaci díla a že disponuje takovými kapacitami a odbornými znalostmi, které jsou k provedení díla nezbytné.
1.7 Účelem této Smlouvy je zajištění plnění úkolů vyplývajících z kompetencí vymezených Objednateli platnými právními předpisy, zejména zákon č. 48/1997 Sb., o veřejném zdravotním pojištění a o změně a doplnění některých souvisejících zákonů, ve znění pozdějších předpisů, prostřednictvím vhodných SW systémů.
1.8 Objednatel v souladu s § 4a odst. 1 zákona č. 181/2014 Sb., o kybernetické bezpečnosti a
o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZoKB“) informuje Zhotovitele, že Systém, který je v rámci Díla vytvářen, bude významným informačním systémem ve smyslu § 2 písm. d) ZoKB a Objednatel bude ve smyslu § 2 písm. e) ZoKB správcem tohoto systému, přičemž Zhotovitel bere toto na vědomí. V tomto smyslu se Zhotovitel stává významným dodavatelem dle § 2 písm. n) vyhlášky č. 82/2018 Sb. a při plnění této Smlouvy je povinen plnit Bezpečnostní pravidla pro významné dodavatele, které tvoří Přílohu č. 4 této Smlouvy. V případě rozporu mezi ustanovením Smlouvy a ustanovením Přílohy č. 4 je rozhodující ustanovení Smlouvy. V případě rozporu mezi ustanovením Přílohy č. 1 a ustanovením Přílohy č. 4 je rozhodující ustanovení Přílohy č. 1.
Článek 2. Změny díla
2.1 Pokud v průběhu provádění díla vyvstane nutnost pozměnit sjednané dílo, resp. jeho rozsah (dále také jako „změna díla“), zavazuje se Xxxxxxxxxx tyto změny díla v rozsahu požadovaném Objednatelem provést.
2.2 Veškeré požadované změny díla budou před jejich provedením specifikovány v zápise. Zápis potvrzený podpisem oprávněných osob Objednatele a Zhotovitele bude podkladem pro uzavření případného dodatku k této Smlouvě. Smluvní strany jsou si vědomy, že uzavření jakéhokoliv dodatku k této Smlouvě je možné, jen pokud budou splněny podmínky vyplývající z platných právních předpisů (např. ze zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů). V případě rozporu stran ohledně sjednané specifikace změny díla (její určitosti) je rozhodující výklad specifikace Objednatelem.
2.3 Pokud navržené změny díla budou mít vliv na cenu (její zvýšení či snížení) a lhůty provedení a dokončení díla, Zhotovitel bez zbytečného odkladu (nejpozději však do 10 dnů od obdržení specifikace změn díla nebo potvrzení doručení Zhotovitelem navrhovaných změn díla Objednateli) předloží Objednateli strukturovanou a detailní kalkulaci ceny těchto změn díla a jejich vlivu na celkovou cenu díla (její zvýšení či snížení), a návrh na případnou úpravu termínů plnění. Zhotovitel se zavazuje na výzvu Objednatele doplnit a upřesnit svou kalkulaci dle požadavků Objednatele, a to bez zbytečného odkladu po obdržení takové žádosti. Zhotovitel předloží takovou kalkulaci včetně popisu vlivu nákladů na tyto změny díla na celkovou cenu a návrhu úpravy termínů plnění formou návrhu dodatku ke Smlouvě. Objednatel bez zbytečného odkladu (nejpozději však do 10 pracovních dnů ode dne
předložení návrhu dodatku) tento návrh buď potvrdí, nebo předloží nový návrh dodatku (protinávrh). Pokud nedojde k dohodě ani po předložení tohoto protinávrhu, bude dílo provedeno v původním rozsahu.
2.4 Zjistí-xx Xxxxxxxxxx, že by s ohledem na navrhovanou změnu díla hrozilo nebezpečí nehospodárného, resp. zbytečného provádění některých prací, je Xxxxxxxxxx povinen na to neprodleně písemně upozornit Objednatele.
Článek 3.
Práva a povinnosti Zhotovitele
3.1 Zhotovitel zabezpečí provádění díla tak, aby v souvislosti s prováděním díla nedošlo k nežádoucímu dotčení oprávněných zájmů Objednatele, zejména ke zranění osob a škodám na majetku a zejména ke ztrátě, poškození či úniku dat z databází Objednatele nebo předmětu díla. Případné škody způsobené Zhotovitelem v souvislosti s plněním této Smlouvy uhradí na svůj náklad Zhotovitel.
3.2 Po celou dobu provádění díla Xxxxxxxxxxxx na základě této Smlouvy se Zhotovitel zavazuje Objednateli poskytovat plnění nejvyšší kvality. Při poskytování plnění a provádění prací podle této Xxxxxxx je Xxxxxxxxxx povinen postupovat s odbornou péčí a s přihlédnutím k zájmům Objednatele.
3.3 Zhotovitel je povinen zajistit, aby provádění díla dle této Xxxxxxx bylo na příslušných pozicích prováděno členy realizačního týmu, kteří byli hodnoceni v rámci nabídky Zhotovitele v průběhu zadávacího řízení na veřejnou zakázku č. VZ05/2022 „Vývoj a zajištění podpory Informačního systému pro vedení a zpracování správních řízení“, na jejímž základě byla uzavřena tato Smlouva (dále jen „Realizační tým“). Seznam členů Realizačního týmu vč. uvedení jejich pozic při provádění díla podle této Xxxxxxx, stanoví Příloha č. 3 této Smlouvy.
3.4 Záměna osoby na pozici v Realizačním týmu je možná pouze po předchozím písemném souhlasu ze strany Objednatele. Zhotovitel je pro udělení souhlasu povinen předložit podrobné informace o důvodu záměny a o praxi a zkušenostech osoby, která se má stát členem Realizačního týmu (dále jen „Nový člen“). Objednatel udělí souhlas se záměnou v případě, že ze Zhotovitelem předložených informací jednoznačně vyplývá, že Nový člen má prokazatelně stejnou nebo delší praxi a stejný nebo vyšší počet zkušeností v porovnání s praxí a zkušenostmi, které Zhotovitel doložil v rámci své nabídky v zadávacím řízení u osoby na pozici, na které má být provedena záměna osob. Objednatel může udělit souhlas se záměnou rovněž v případě, když ze Xxxxxxxxxxxx předložených informací vyplývá dostatečná záruka, že Nový člen bude na dané pozici provádět dílo na stejné nebo vyšší úrovni kvality ve srovnání s členem Realizačního týmu, který má být nahrazen.
3.5 Zhotovitel se zavazuje provést dílo podle této Xxxxxxx na svůj náklad a nebezpečí a bude poskytovat všechny ekonomické, materiální a lidské prvky tak, aby byl naplněn účel této Smlouvy. Pokud Zhotovitel použije k provedení díla dle této Xxxxxxx díla třetích stran chráněná zákonem č. 121/2000 Sb., autorským zákonem, ve znění pozdějších předpisů, je povinen zajistit, aby jejich využitím nebylo ohroženo naplnění účelu a předmětu této Smlouvy.
3.6 Zhotovitel je povinen dbát příkazů Objednatele ohledně způsobu provádění díla. Zhotovitel je povinen bez zbytečného odkladu oznámit Objednateli všechny okolnosti, které zjistí při své činnosti, a které mohou mít vliv na vydání příkazů Objednatele či jejich změnu. Zhotovitel vždy upozorní Objednatele na případnou nevhodnost jeho příkazů; v případě, že Objednatel přes upozornění Zhotovitele na splnění svých příkazů trvá, je Xxxxxxxxxx v odpovídajícím rozsahu zproštěn odpovědnosti za případné vady díla vzniklé prokazatelně v důsledku provedení takových nevhodných příkazů.
3.7 Zhotovitel je povinen neprodleně po uzavření této Smlouvy předat Objednateli písemný seznam osob, které se budou podílet na poskytování plnění podle této Smlouvy, a to jak svých pracovníků, tak i pracovníků případného poddodavatele. Seznam bude vyhotoven pro účely zajištění přístupu do objektu Objednatele. Tento seznam je Zhotovitel povinen pravidelně aktualizovat a případné změny v osobách oprávněných k přístupu do objektu Objednatele písemně hlásit Objednateli bez zbytečného odkladu. V seznamu budou osoby označeny jménem a příjmením a bude u nich uvedeno označení jejich zaměstnavatele (popř. kontraktora, pokud se nejedná o pracovněprávní vztah). Zhotovitel je povinen předat tento seznam osob Objednateli s výslovným písemným souhlasem těchto osob se zpracováním jejich osobních údajů Objednatelem pro účely zajištění jejich přístupu do objektu Objednatele a k příslušným částem informačních systémů Objednatele. Při porušení této povinnosti nese Zhotovitel plnou odpovědnost právních předpisů týkajících se ochrany osobních údajů. Objednatel se zavazuje, že bude zpracovávat tyto osobní údaje pouze pro potřeby realizace díla a v souladu s platnými právními předpisy, a to až do odvolání souhlasu písemnou formou. Určení konkrétní pracovní doby a doby pohybu osob provádějících dílo v prostorách Objednatele je Xxxxxxxxxx povinen předem domluvit s Objednatelem, o čemž bude pořízen zápis stvrzený podpisy oprávněných osob uvedených v čl. 18. Seznam osob je Xxxxxxxxxx povinen v případech jakýchkoliv personálních změn neprodleně aktualizovaný předat Objednateli.
3.8 V případě, že pro plnění předmětu díla bude Xxxxxxxxxx požadovat pro své zaměstnance, nebo zaměstnance svého poddodavatele přístupová oprávnění k informačním systémům Objednatele, zavazuje se Zhotovitel neprodleně po vzniku takové potřeby předat Objednateli vyplněnou a podepsanou žádost o přístup do informačního systému Objednatele pro osoby, které se budou podílet na plnění této Smlouvy, a to jak svých pracovníků, tak i pracovníků případného poddodavatele. V případě, že v průběhu plnění této Smlouvy bude Zhotovitel požadovat změnu v osobách přistupujících k informačním systémům Objednatele, je vždy povinen nejprve podat žádost o ukončení přístupu do informačního systému pro osobu/osoby, jejichž oprávnění má být zrušeno, a současně podat novou žádost o přístup do informačního systému pro osobu/osoby, které mají přístupová oprávnění nově nabýt. Zhotovitel je povinen podávat žádosti o přístup/ukončení přístupu do informačního systému Objednatele na formuláři, který je Přílohou č. 5 této Smlouvy. Žádost bude ze strany Objednatele posouzena nejpozději do dvou pracovních dnů následujících po dni jejího doručení. Objednatel si může při procesu posuzování žádosti vyžádat další informace o účelu vydání žádosti. Kopii schválené nebo zamítnuté žádosti předá Objednatel Zhotoviteli.
3.9 V souvislosti s přístupy do informačního systému Objednatele je Zhotovitel dále povinen dodržovat následující povinnosti:
- Zhotovitel je povinen zajistit a odpovídá po celou dobu plnění této Smlouvy Objednateli za to, že do příslušných částí informačního systému Objednatele budou přistupovat pouze osoby, pro něž byla podána žádost o přístup do informačního systému a tato žádost byla schválena manažerem bezpečnosti informací Objednatele (dále jen
„MBI“). Objednatel je kdykoli v průběhu plnění této Smlouvy oprávněn kontrolovat, které osoby skutečně přistupují do příslušné části jeho informačního systému, a Zhotovitel je v takovém případě vždy povinen tuto informaci Objednateli poskytnout a doložit. Porušení této povinnosti Zhotovitelem je považováno za porušení smluvních povinností Zhotovitele podstatným způsobem.
- Přidělená oprávnění smí využívat pouze osoba, pro niž byla žádost schválena ze strany MBI. Tato osoba nesmí přidělená oprávnění předat žádné jiné osobě. Porušení této povinnosti je považováno za porušení smluvních povinností Zhotovitele podstatným způsobem.
- Při ukončení pracovního poměru osoby, která měla udělena přístupová práva,
k Xxxxxxxxxxx či jeho poddodavateli, je Zhotovitel povinen podat žádost o ukončení
přístupu této osoby do informačního systému Objednatele, a to nejpozději do dvou pracovních dnů od okamžiku, kdy rozhodná skutečnost nastane. Stejně je Zhotovitel povinen postupovat v případech, kdy pomine důvod nebo potřeba přístupu příslušné osoby Zhotovitele či jeho poddodavatele do informačního systému Objednatele. Porušení této povinnosti je považováno za porušení smluvních povinností Zhotovitele podstatným způsobem.
3.10 Zhotovitel je povinen získat na své náklady veškeré potřebné vývozní či dovozní licence pro jednotlivé části díla, pokud jsou taková povolení třeba.
3.11 Zhotovitel je povinen účastnit se jednání svolaných Objednatelem, která se týkají provádění díla. Pokud není specifikováno jinak, účastní se za Zhotovitele takového jednání vždy osoba oprávněná jednat za Zhotovitele ve věcech plnění této Smlouvy dle odst. 18.1.
3.12 Zhotovitel se zavazuje při plnění předmětu Xxxxxxx spolupracovat s jakýmikoliv odborníky, které určí Objednatel, tak aby bylo dosaženo naplnění účelu této Smlouvy.
3.13 Zhotovitel je povinen přizpůsobit práce (včetně režimu jejich provádění) potřebám Objednatele. Při provádění vlastních prací musí být dodržována veškerá bezpečnostní opatření vyplývající zejména z vnitřních předpisů Objednatele a Zhotovitele. Zhotovitel se zavazuje postupovat tak, aby nebyla narušena činnost Objednatele. Vnitřní předpisy Objednatele jsou Zhotoviteli k dispozici k nahlédnutí u Objednatele, a to kdykoli na požádání jeho oprávněné osoby uvedené v čl. 18.
3.14 Zhotovitel potvrzuje, že ke dni podpisu této Smlouvy má uzavřenu pojistnou smlouvu na pojištění odpovědnosti za škodu způsobenou při výkonu své podnikatelské činnosti na minimální částku 10.000.000,- Kč (slovy deset miliónů korun českých) se spoluúčastí nejvýše 10 %, a že tuto pojistnou smlouvu bude udržovat účinnou po dobu trvání této Smlouvy a dále nejméně 6 měsíců po ukončení činnosti podle této Smlouvy. Na žádost Objednatele je Xxxxxxxxxx povinen neprodleně předložit pojistnou smlouvu či pojistný certifikát příslušné pojišťovny.
3.15 Zhotovitel se zavazuje do 10 pracovních dnů od data uzavření této Smlouvy zaslat Objednateli písemné oznámení, zda je zaměstnavatelem zaměstnávajícím více než 50 % zaměstnanců na zřízených nebo vymezených chráněných pracovních místech (viz § 75 zákona č. 435/2004 Sb., o zaměstnanosti, ve znění pozdějších předpisů), kteří jsou osobami se zdravotním postižením, nebo zda je osobou se zdravotním postižením a zároveň osobou samostatně výdělečně činnou, která nemá žádné zaměstnance. Zhotovitel je povinen zaslat Objednateli toto oznámení i v případě, že podmínky dle předchozí věty nesplňuje (v takovém případě zašle negativní oznámení). Dojde-li během platnosti této Smlouvy k jakékoli změně oznámeného stavu, je Zhotovitel povinen do 10 pracovních dnů ode dne, kdy tato skutečnost prokazatelně nastala, zaslat Objednateli písemné ohlášení této změny.
Článek 4.
Práva a povinnosti Objednatele
4.1 Objednatel je povinen předat včas Zhotoviteli úplné, pravdivé a přehledné informace, jež jsou nezbytně nutné k provádění díla dle této Smlouvy, pokud z jejich povahy nevyplývá, že je má zajistit Xxxxxxxxxx sám v rámci plnění předmětu Smlouvy.
4.2 Objednatel je povinen vytvořit řádné podmínky pro provádění díla dle této Smlouvy Xxxxxxxxxxxx a poskytovat mu po dobu trvání této Smlouvy nezbytnou součinnost, pokud si tuto součinnost Zhotovitel důvodně vyžádá. Jedná se zejména o předání dokumentů a jiných informací nezbytně nutných k provádění díla, umožnění přístupu do prostor Objednatele. Požadavek Zhotovitele na poskytnutí součinnosti musí být písemný, adresovaný oprávněné osobě Objednatele. Požadavek musí být předložen v takovém předstihu, aby bylo, vzhledem
k provozní době Objednatele a rozsahu požadované součinnosti (např. rozsahu požadované dokumentace nebo činnosti), možné poskytnutí požadované součinnosti v daném čase vůbec rozumně/reálně očekávat.
Článek 5.
Místo, doba plnění, akceptace a předání díla
5.1 Smluvní strany se dohodly, že místem realizace díla je sídlo Objednatele a sídlo Zhotovitele či jeho poddodavatelů.
5.2 Část díla dle odst. 1.2 písm. a) je Zhotovitel povinen předat Objednateli k akceptaci ve lhůtě do 90 kalendářních dnů od data účinnosti této Smlouvy. Pokud Zhotovitel nepředá tuto část Díla Objednateli k akceptaci ve lhůtě dle předchozí věty, vzniká Objednateli nárok na slevu z ceny Díla podle Článku 12.
5.3 Části díla dle odst. 1.2 písm. b) až h) je Zhotovitel povinen předat Objednateli k akceptaci ve lhůtě do 160 kalendářních dnů od data podpisu akceptačního a předávacího protokolu k části díla dle odst. 1.2 písm. a). Pokud Zhotovitel nepředá tyto části Díla Objednateli k akceptaci ve lhůtě dle předchozí věty, vzniká Objednateli nárok na slevu z ceny Díla podle Článku 12.
5.4 Část díla dle odst. 1.2 písm. i) je Zhotovitel povinen předat Objednateli k akceptaci ve lhůtě do 65 kalendářních dnů od data podpisu akceptačního a předávacího protokolu k částem díla dle odst. 1.2 písm. b) až h). Pokud Zhotovitel nepředá tuto část Díla Objednateli k akceptaci ve lhůtě dle předchozí věty, vzniká Objednateli nárok na slevu z ceny Díla podle Článku 12.
5.5 Dílo bude prováděno v souladu s harmonogramem uvedeným v Příloze č. 1 Smlouvy a
předáváno k akceptaci postupně po částech dle následujícího odstavce.
5.6 Akceptace a převzetí části díla dle odst. 1.2 písm. a), částí díla dle odst. 1.2 písm. b) až h) a
částí díla dle odst. 1.2 písm. i) bude probíhat následujícím způsobem:
a) Akceptace části díla dle odst. 1.2 písm. a):
i. Uvedená část díla včetně veškeré dokumentace a výstupů musí být Xxxxxxxxxxxx předána k akceptaci Objednateli ve lhůtě uvedené v odst. 5.2 této Smlouvy. O této skutečnosti bude mezi smluvními stranami vyhotoven písemný datovaný zápis
o předání této části díla k akceptaci, podepsaný oprávněnými osobami smluvních
stran.
ii. Po předání části díla k akceptaci bude provedeno akceptační řízení, ve kterém provede Objednatel posouzení, zda byla tato část díla zhotovena v souladu s touto Smlouvou a bez zbytečného odkladu vznese připomínky a vytkne vady, které zjistí. Zhotovitel je v rámci akceptačního řízení povinen zapracovat připomínky, jsou-li v souladu se Smlouvou, a odstranit vytčené vady.
iii. Délka akceptačního řízení podle bodu ii. je stanovena na 45 kalendářních dnů od předání části díla k akceptaci dle bodu i., přičemž Xxxxxxxxxx je povinen v této lhůtě zapracovat všechny vznesené připomínky a odstranit všechny vytčené vady. Objednatel je povinen vznést připomínku nebo vytknout vadu nejpozději 5 pracovních dní před tím, než uplyne lhůta podle věty první, to však neplatí v případě, že připomínka nebo vada je zapříčiněna úpravou části díla, kterou Xxxxxxxxxx provedl až v rámci akceptačního řízení. Lhůtu podle věty první je možné prodloužit po vzájemné dohodě v případě, že zapracování vznesené připomínky nebo odstranění vytčené vady vyžaduje rozsáhlou a časově náročnou součinnosti pracovníků Objednatele.
iv. Po skončení akceptačního řízení bude mezi smluvními stranami vyhotoven písemný datovaný akceptační a předávací protokol, podepsaný oprávněnými osobami smluvních stran, kterým bude konstatována akceptace části díla bez výhrad, nebo
rozhodnutí Objednatele o akceptování části díla s výhradami, a potvrzeno její převzetí
Objednatelem.
v. Pokud Zhotovitel nezapracuje připomínky Objednatele do této části díla, či neodstraní vytknuté vady této části díla, do skončení akceptačního řízení ve lhůtě podle bodu iii., vzniká Objednateli nárok na slevu z ceny díla podle Xxxxxx 12. Nárok na slevu z ceny díla nevznikne, jedná-li se o vadu, kterou Objednatel akceptoval akceptačním a předávacím protokolem, kterým byla část díla Objednatelem převzata s výhradami, přičemž taková vada byla v protokolu výslovně uvedena.
b) Akceptace částí díla dle odst. 1.2 písm. b) až h):
i. Uvedené části díla včetně veškeré dokumentace a výstupů musí být Xxxxxxxxxxxx předány k akceptaci Objednateli ve lhůtě uvedené v odst. 5.3 této Smlouvy. O této skutečnosti bude mezi smluvními stranami vyhotoven písemný datovaný zápis o předání těchto částí díla k akceptaci, podepsaný oprávněnými osobami smluvních stran.
ii. Po předání částí díla k akceptaci bude provedeno akceptační řízení, ve kterém provede Objednatel posouzení, zda byly tyto části díla zhotoveny v souladu s touto Smlouvou a bez zbytečného odkladu vytkne vady, které zjistí. Zhotovitel je v rámci akceptačního řízení povinen odstranit vytčené vady.
iii. Délka akceptačního řízení podle bodu II. je stanovena na 70 kalendářních dnů od předání částí díla k akceptaci dle xxxx X., přičemž Xxxxxxxxxx je povinen v této lhůtě odstranit všechny vytčené vady. Objednatel je povinen vytknout vadu nejpozději 5 pracovních dní před tím, než uplyne lhůta podle věty první, to však neplatí v případě, že vada je způsobena úpravou části díla, kterou Xxxxxxxxxx provedl až v rámci akceptačního řízení. Lhůtu podle věty první je možné prodloužit po vzájemné dohodě v případě, že odstranění vytčené vady vyžaduje rozsáhlou a časově náročnou součinnosti pracovníků Objednatele.
iv. Po skončení akceptačního řízení bude mezi smluvními stranami vyhotoven písemný datovaný akceptační a předávací protokol, podepsaný oprávněnými osobami smluvních stran, kterým bude konstatována akceptace částí díla bez výhrad, nebo rozhodnutí Objednatele o akceptování částí díla s výhradami, a potvrzeno jejich převzetí Objednatelem.
v. Pokud Zhotovitel neodstraní vytknuté vady těchto částí díla do skončení akceptačního řízení ve lhůtě podle bodu iii., vzniká Objednateli nárok na slevu z ceny díla podle Xxxxxx 12. Nárok na slevu z ceny díla nevznikne, jedná-li se o vadu, kterou Objednatel akceptoval akceptačním a předávacím protokolem, kterým byly části díla Objednatelem převzaty s výhradami, přičemž taková vada byla v protokolu výslovně uvedena.
c) Akceptace části díla dle odst. 1.2 písm. i):
i. Uvedená část díla včetně veškeré dokumentace a výstupů musí být Xxxxxxxxxxxx předána k akceptaci Objednateli ve lhůtě uvedené v odst. 5.4 této Smlouvy. O této skutečnosti bude mezi smluvními stranami vyhotoven písemný datovaný zápis
o předání této části díla k akceptaci, podepsaný oprávněnými osobami smluvních
stran.
ii. Po předání části díla k akceptaci bude provedeno akceptační řízení, ve kterém provede Objednatel posouzení, zda byla tato část díla zhotovena v souladu s touto Smlouvou a bez zbytečného odkladu vytkne vady, které zjistí. Zhotovitel je v rámci akceptačního řízení povinen odstranit vytčené vady.
iii. Délka akceptačního řízení podle bodu II. je stanovena na 30 kalendářních dnů od předání části díla k akceptaci dle xxxx X., přičemž Xxxxxxxxxx je povinen v této lhůtě odstranit všechny vytčené vady. Objednatel je povinen vytknout vadu nejpozději
5 pracovních dní před tím, než uplyne lhůta podle věty první, to však neplatí v případě, že vada je způsobena úpravou části díla, kterou Xxxxxxxxxx provedl až v rámci akceptačního řízení. Lhůtu podle věty první je možné prodloužit po vzájemné dohodě v případě, že odstranění vytčené vady vyžaduje rozsáhlou a časově náročnou součinnosti pracovníků Objednatele.
iv. Po skončení akceptačního řízení bude mezi smluvními stranami vyhotoven písemný datovaný akceptační a předávací protokol, podepsaný oprávněnými osobami smluvních stran, kterým bude konstatována akceptace části díla bez výhrad, nebo rozhodnutí Objednatele o akceptování části díla s výhradami, a potvrzeno její převzetí Objednatelem.
v. Pokud Zhotovitel neodstraní vytknuté vady této části díla, do skončení akceptačního řízení ve lhůtě podle bodu iii., vzniká Objednateli nárok na slevu z ceny díla podle Článku 12. Nárok na slevu z ceny díla nevznikne, jedná-li se o vadu, kterou Objednatel akceptoval akceptačním a předávacím protokolem, kterým byla část díla Objednatelem převzata s výhradami, přičemž taková vada byla v protokolu výslovně uvedena.
5.7 Po akceptaci a předání všech částí díla dle odst. 1.2 písm. a) až i) v souladu s odst. 5.6 a jejich převzetí Objednatelem, bude mezi smluvními stranami vyhotoven písemný datovaný závěrečný předávací protokol, který bude konstatovat převzetí díla jako celku, zhotoveného v souladu s touto Smlouvou. Tento předávací protokol bude podepsán oprávněnými osobami obou smluvních stran. Jeho přílohou budou kopie všech podepsaných akceptačních a předávacích protokolů dle předchozího odstavce, tj. akceptačního a předávacího protokolu části díla dle odst. 1.2 písm. a), akceptačního a předávacího protokolu částí díla dle odst. 1.2 písm. b) až h) a akceptačního a předávacího protokolu části díla dle odst. 1.2 písm. i). Závěrečný předávací protokol bude vyhotoven do 5 pracovních dnů po podpisu akceptačního a předávacího protokolu části díla dle odst. 1.2 písm. i).
Článek 6.
Cena
6.1 Smluvní strany se dohodly, že za dílo provedené v souladu s touto Smlouvou uhradí Objednatel Zhotoviteli celkovou cenu ve výši:
bez DPH 11 008 027,50 Kč
DPH 2 311 685,78 Kč odpovídající sazbě 21 %
celkem 13 319 713,28 Kč vč. DPH
6.2 Smluvní strany se dohodly, že odměna za poskytnutí veškerých licenčních oprávnění
v souladu s čl. 10 této Xxxxxxx je zahrnuta v ceně díla dle odst. 6.1.
6.3 Smluvní strany tímto výslovně sjednávají, že uvedená smluvní cena je nejvyšší přípustná a že tedy nedojde k žádným jejím dalším úpravám, ledaže je výslovně v této Smlouvě, popř. jejích dodatcích dohodnuto jinak. Pro případ, že v době platnosti této Smlouvy (tj. po jejím uzavření) dojde ke změně sazby DPH (tj. k jejímu zvýšení či snížení), je Zhotovitel povinen tuto změnu zohlednit při vyúčtování (fakturaci) ceny díla, tj. cenu snížit či zvýšit o výši změny DPH.
6.4 Cena zahrnuje všechny náklady Zhotovitele spojené s realizací díla dle této Smlouvy.
6.5 Cena bude Zhotoviteli hrazena po částech, dílčími platbami po dokončení, akceptaci a převzetí části/částí díla Objednatelem akceptačním a předávací protokolem k příslušné části/částem díla, a to v rozsahu níže uvedeném:
a) 5 % z celkové ceny díla dle odst. 6.1, tj. 550 401,38 Kč bez DPH a 665 985,66 Kč vč. DPH po akceptaci a předání částí díla dle odst. 5.6 písm. a);
b) 65 % z celkové ceny díla dle odst. 6.1, tj. 7 155 217,88 Kč bez DPH a 8 657 813,63 Kč vč.
DPH po akceptaci a předání částí díla dle odst. 5.6 písm. b);
c) 30 % z celkové ceny díla dle odst. 6.1, tj. 3 302 408,25 Kč bez DPH a 3 995 913,98 Kč vč. DPH po akceptaci a předání části díla dle odst. 5.6 písm. c);
6.6 Objednatel má za podmínek uvedených v Článku 12 nárok na uplatnění slevy z ceny díla uvedené v odst. 6.1, přičemž tato sleva bude uplatněna vůči té části ceny díla uvedené v odst. 6.5, které se týká prodlení Zhotovitele, jenž způsobí vznik nároku na uplatnění slevy z ceny.
6.7 Zhotovitel tímto výslovně prohlašuje, že disponuje dostatečnými finančními prostředky na úhradu všech svých závazků vyplývajících z této Smlouvy nebo s ní souvisejících, které lze rozumně očekávat či předpokládat.
Článek 7.
Fakturace a platební podmínky
7.1 Objednatel uhradí Zhotoviteli jednotlivé části ceny díla stanovené v odst. 6.5 po odečtení případných slev podle odst. 6.6 na základě faktur vystavených Zhotovitelem. Zhotovitel je oprávněn fakturovat až po uskutečnění plnění, tj. po dokončení, akceptaci a převzetí příslušné části nebo částí díla Objednatelem v souladu s odst. 5.6. Faktura musí obsahovat veškeré náležitosti daňového a účetního dokladu stanovené zákonem č. 235/2004 Sb., o dani z přidané hodnoty, a zákonem č. 563/1991 Sb., o účetnictví, ve znění jejich pozdějších změn. Součástí faktury musí být kopie akceptačního a předávacího protokolu dle odst. 5.6 osvědčujícího akceptaci, předání a převzetí fakturované části (částí) díla dle podmínek této Smlouvy. V případě, že předložená faktura neobsahuje předepsané náležitosti, Objednatel je oprávněn ji ve lhůtě splatnosti vrátit Zhotoviteli. V takovém případě začíná běžet nová splatnost ode dne vystavení opravené faktury.
7.2 Splatnost každé faktury činí 30 dní ode dne vystavení, přičemž Zhotovitel je povinen doručit fakturu Objednateli nejpozději do 3 pracovních dnů od data vystavení. Smluvní strany se dohodly, že závazek k úhradě faktury je splněn dnem, kdy byla příslušná částka odepsána z účtu Objednatele ve prospěch účtu Zhotovitele.
7.3 Objednatel prohlašuje, že dílo je pořizováno pro potřeby související výlučně s činností Objednatele při výkonu veřejné správy, při níž se nepovažuje za osobu povinnou k dani z přidané hodnoty (§ 5 odst. 3 zákona č. 235/2004 Sb.). Z toho důvodu nebude u plnění uplatněn režim přenesení daňové povinnosti.
7.4 Zhotovitel si je vědom vlastních finančních nákladů spojených s plněním předmětu Smlouvy a nebude žádat jakékoliv finanční plnění v průběhu provádění díla nad rámec sjednaných podmínek úhrady ceny.
7.5 Je-li Objednatel v prodlení s úhradou plateb podle této Smlouvy, je Xxxxxxxxxx oprávněn požadovat od Objednatele úrok z prodlení z neuhrazené dlužné částky ve výši stanovené příslušnými právními předpisy.
Článek 8.
Poddodávky Zhotovitele
8.1 Zhotovitel je povinen provádět veškeré práce při provádění díla podle této Xxxxxxx výhradně prostřednictvím vlastních zaměstnanců a poddodavatelů uvedených v Příloze č. 6 této Smlouvy. V případě nemožnosti použití takového poddodavatele z objektivních důvodů je Zhotovitel povinen vyžádat si předem písemně souhlas Objednatele s nahrazením takového poddodavatele. Objednatel není povinen souhlas udělit v případě, kdy se nebude dle jeho názoru jednat o objektivní důvody nemožnosti použití poddodavatele. Xxxxxxxxxx je povinen zajistit a financovat veškeré poddodavatelské práce a nese za ně záruku v plném rozsahu dle této Smlouvy.
8.2 Výlučná odpovědnost Zhotovitele vůči Objednateli za koordinaci prací a řádné provedení díla není poddodávkami dotčena.
8.3 Použití (jiného) poddodavatele v rozporu s touto Smlouvou je porušením této Smlouvy podstatným způsobem.
8.4 Zhotovitel se zavazuje zajistit, aby poddodavatel byl vůči Zhotoviteli vždy zavázán nejméně stejnými podmínkami a v rozsahu, jak jsou obsaženy ve smluvním vztahu mezi Zhotovitelem a Objednatelem, a to nejpozději ode dne zahájení činnosti poddodavatele pro Zhotovitele a v rozsahu odpovídajícím rozsahu činností, které má plnit k provedení díla, tedy včetně časového harmonogramu, dle kterého má být dílo provedeno.
8.5 Zhotovitel se nemůže zprostit odpovědnosti za plnění dle této Smlouvy poukazem na plnění díla poddodavatelem.
Článek 9.
Ochrana důvěrných informací a osobních údajů
9.1 Zhotovitel je povinen zachovávat mlčenlivost o všech skutečnostech, o kterých se dozví při plnění této Smlouvy, a které nejsou právním předpisem určeny ke zveřejnění nebo nejsou obecně známé. Zhotovitel se také zavazuje neumožnit žádné osobě, aby mohla zpřístupnit důvěrné informace neoprávněným třetím osobám, pokud tato Xxxxxxx nestanoví jinak. S informacemi poskytnutými Objednatelem Zhotoviteli, popř. získanými Xxxxxxxxxxxx v souvislosti s plněním jeho závazků dle této Xxxxxxx, je povinen Zhotovitel nakládat jako s důvěrnými informacemi.
9.2 Za důvěrné informace se pro účely této Smlouvy nepovažují:
9.2.1 informace, které se staly veřejně přístupnými veřejnosti jinak než následkem jejich zpřístupnění Zhotovitelem;
9.2.2 informace, které Zhotovitel získá z jiného zdroje než od Objednatele, které jsou jejich poskytovatelem označené za veřejné.
9.3 Zhotovitel se zavazuje použít důvěrné informace výhradně za účelem splnění svých závazků vyplývajících z této Smlouvy. Xxxxxxxxxx se dále zavazuje, že on ani jiná osoba, která bude Zhotovitelem seznámena s důvěrnými informacemi v souladu s touto Smlouvou, je nezpřístupní žádné třetí osobě vyjma případů, kdy:
9.3.1 jde o zpřístupnění důvěrných informací osobám, pro které je přístup k těmto informacím nezbytný za účelem splnění závazků Zhotovitele vyplývajících z této Smlouvy (poddodavatelům);
9.3.2 jde o zpřístupnění důvěrných informací s předchozím písemným souhlasem
Objednatele;
9.3.3 tak stanoví obecně závazný právní předpis nebo je dána taková povinnost pravomocným a zákonným rozhodnutím příslušného orgánu vydaným na základě jeho
zákonného zmocnění. Takovou skutečnost je Zhotovitel povinen na výzvu Objednateli bez zbytečného odkladu prokázat.
9.4 Zhotovitel se dále zavazuje zajistit i ochranu důvěrných informací proti jejich neoprávněnému získání třetími osobami. V případě, že Zhotovitel bude mít důvodné podezření, že došlo k neoprávněnému zpřístupnění (získání) důvěrných materiálů, je povinen neprodleně o této skutečnosti informovat Objednatele.
9.5 Zhotovitel je povinen předat bez zbytečného odkladu Objednateli veškeré materiály a věci, které od něho či jeho jménem převzal při plnění této Smlouvy, a to bez zbytečného odkladu po ukončení této Smlouvy. Důvěrné informace uložené v elektronické podobě je Zhotovitel povinen odstranit, a to nejpozději po uplynutí doby jejich povinné archivace, pokud se na něj tato zákonná povinnost vztahuje.
9.6 Závazek ochrany důvěrných informací zůstává v platnosti i po ukončení této Smlouvy.
9.7 Zhotovitel se zavazuje bez zbytečného odkladu zavázat povinností mlčenlivosti ve stejném rozsahu, jako je vázán touto Smlouvou sám, i všechny své pracovníky podílející se se souhlasem Objednatele na poskytování díla pro Objednatele.
9.8 Objednatel je oprávněn kdykoliv po dobu účinnosti této Smlouvy i po skončení její účinnosti uveřejnit tuto Smlouvu nebo její část i informace vztahující se k jejímu plnění, což Zhotovitel bere na vědomí, resp. s tím souhlasí.
9.9 Objednatel je správcem osobních údajů obsažených v Systému. Pokud Zhotovitel pro plnění smluvního vztahu nezbytně potřebuje zpracovávat osobní údaje obsažené v Systému, pak se pro účel této Smlouvy stává zpracovatelem osobních údajů.
9.10 Objednatel zpracovává osobní údaje v Systému na základě povinností uložených mu zejména (nikoli však výlučně) zákonem č. 48/1997 Sb., o veřejném zdravotním pojištění a o změně a doplnění některých souvisejících zákonů, ve znění pozdějších předpisů.
9.11 Zhotovitel není oprávněn ke zpracování osobních údajů obsažených v Systému, ledaže by takové zpracování bylo nezbytně nutné pro naplnění účelu smluvního vztahu s Objednatelem. V případě, že jde o zpracování nezbytné pro naplnění účelu smluvního vztahu s Objednatelem, je Zhotovitel oprávněn zpracovávat osobní údaje obsažené v Systému pouze na základě předchozího písemného pověření Objednatele (dále jen „písemné pověření“). Písemné pověření musí obsahovat bližší určení typu zpracovávaných osobních údajů, kategorií subjektů údajů, doby trvání zpracování a povahy a účelu zpracování.
9.12 Zhotovitel není oprávněn zapojit do zpracování žádný další subjekt bez předchozího výslovného písemného povolení Objednatele.
9.13 Zhotovitel je v případě, kdy je Objednatelem písemně pověřen zpracovávat osobní údaje obsažené v Systému, povinen postupovat v souladu s právními předpisy týkajícími se ochrany osobních údajů a účinnými v době zpracování, zejména:
a) zpracovávat osobní údaje pouze na základě doložených pokynů Objednatele;
b) zajišťovat, aby se osoby oprávněné zpracovávat osobní údaje zavázaly k mlčenlivosti nebo aby se na ně vztahovala zákonná povinnost mlčenlivosti; tato povinnost platí i po ukončení této Smlouvy;
c) přijmout taková technická a organizační opatření, která zajistí úroveň zabezpečení osobních údajů, zejména:
• integritu osobních údajů zaručující jejich pravost a nenarušenost, tj. opatření vedoucí k tomu, že během zpracování nedojde k úmyslnému nebo náhodnému pozměnění osobních údajů,
• důvěrnost osobních údajů, tj. přijmout taková opatření, která přispívají ke zvýšení
zabezpečení osobních údajů a zachování důvěrnosti zpracování, jako je
pseudonymizace, šifrování a správa přístupových práv tak, aby zaměstnanci
Zhotovitele měli přístup pouze k osobním údajům nezbytným pro výkon své činnosti,
• transparentnost zpracování osobních údajů, tj. přijmout taková technická a organizační opatření, která jsou ze strany Zhotovitele doložitelná a pro Objednatele přezkoumatelná, Zhotovitel tudíž musí Objednatele seznámit s tím, jaké technické a organizační opatření k ochraně osobních údajů přijal,
• izolovanost zpracování osobních údajů, tj. přijatá opatření musí zajistit, že v případě zpracování osobních údajů více správců osobních údajů nedojde k jejich sloučení nebo záměně,
• dostupnost osobních údajů – tj. řešení naplňující požadavek dostupnosti osobních údajů minimálně dle dostupnosti stanovené pro Systém,
• odolnost technických prostředků a úložišť osobních údajů zajišťující tam uložené osobní údaje před poškozením, ztrátou, zneužitím, kompromitací, náhodným i cíleným nežádoucím pozměněním;
d) dodržovat podmínky zapojení dalšího zpracovatele stanovené touto Smlouvou a v případě zapojení dalšího zpracovatele po písemném povolení Objednatele zajistit, aby se další zpracovatel smluvně zavázal dodržovat ve stejné míře všechny povinnosti k ochraně osobních údajů vyplývající pro Zhotovitele z této Smlouvy;
e) při zpracování zohledňovat povahu zpracování a být Objednateli nápomocen pro splnění Objednatelovy povinnosti reagovat na žádosti o výkon práv subjektu údajů vyplývající z platných právních předpisů.
f) s ohledem na Zhotovitelem zpracovávané osobní údaje poskytovat Objednateli veškerou součinnost, vyžádanou Objednatelem v souvislosti s:
• prováděním vhodných technických a organizačních opatření pro zajištění odpovídající úrovně zabezpečení zpracovávaných osobních údajů,
• ohlašováním případů porušení zabezpečení osobních údajů dozorovému úřadu či subjektu údajů,
• posuzováním vlivu na ochranu osobních údajů,
• konzultacemi s dozorovým úřadem ohledně zpracování osobních údajů;
g) ohlásit Objednateli bez zbytečného odkladu zjištěné porušení zabezpečení zpracovávaných osobních údajů;
h) na výzvu Objednatele všechny osobní údaje buď vymazat, nebo vrátit Objednateli po ukončení poskytování Služeb dle této Smlouvy, a vymazat všechny existující kopie, pokud mu platné právní předpisy neukládají uložení daných osobních údajů;
i) poskytnout Objednateli veškeré informace potřebné k doložení toho, že Zhotovitel splnil veškeré povinnosti týkající se ochrany osobních údajů dle tohoto článku a umožnit audity, včetně inspekcí, prováděné Objednatelem nebo jiným auditorem, kterého Objednatel pověřil, a k těmto auditům přispět svou plnou součinností;
j) informovat neprodleně Objednatele v případě, že dle názoru Xxxxxxxxxxx určitý pokyn Objednatele porušuje platné právní předpisy týkající se ochrany osobních údajů.
9.14 Zhotovitel je povinen vést záznamy o činnostech zpracování osobních údajů prováděných pro Objednatele podle příslušných právních předpisů a rovněž vést registr rizik, týkající se možnosti narušení důvěrnosti a integrity zpracovávaných osobních údajů, který obsahuje klasifikace jednotlivých rizik, datum jejich identifikace, vlastníka jednotlivých rizik a popis preventivních opatření přijatých k jejich minimalizaci. Zhotovitel je povinen umožnit Objednateli kdykoliv nahlédnout do vedených záznamů o činnostech zpracování a do obsahu registru rizik a učinit si z nich opis, či výpis.
9.15 Zhotovitel prohlašuje, že disponuje veškerým potřebným personálním i technickým zázemím, které poskytuje dostatečné záruky k tomu, že jím prováděné zpracování osobních údajů bude
splňovat všechny požadavky platných právních předpisů i této Smlouvy, a je tak schopen zajistit náležitou ochranu práv subjektu údajů.
Článek 10.
Autorská práva
10.1 Definování používaných pojmů
Smluvní strany se dohodly, že kdekoliv tato Smlouva používá níže uvedené pojmy, pak se jimi rozumí níže uvedený význam
a) „Autorským zákonem“ se rozumí zákon č.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ů,
b) „Autorským dílem“ se rozumí dílo ve smyslu § 2 Autorského zákona, zejména Software, databáze, dokumentace či jakékoliv výstupy Zhotovitele předávané Objednateli na základě této Smlouvy, které splňují podmínky stanovené § 2 Autorského zákona,
c) „Databází“ se rozumí databáze ve smyslu § 88 Autorského zákona.
10.2 Licence k autorským dílům a databázím vytvořeným na zakázku
10.2.1 Udělení licence Zhotovitelem
a) Zhotovitel Objednateli poskytuje výhradní oprávnění (licenci, resp. podlicenci) k výkonu práva užít Autorská díla a k výkonu práva vytěžovat a zužitkovat Databáze vytvořené na zakázku pro Objednatele v rámci plnění této Smlouvy, a to v územně a množstevně neomezeném rozsahu a všemi známými způsoby užití, a to na celou dobu trvání majetkových práv autora, a k postoupení nebo poskytnutí oprávnění tvořících součást této licence (podlicenci) zcela nebo zčásti jakékoliv třetí osobě, a to včetně svolení Autorská díla a Databáze (zcela i z části) měnit, spojovat, upravovat, rozdělovat, spojovat s jinými díly, zařazovat je do děl souborných, dopracovat, vše zcela samostatně či prostřednictvím třetí osoby. Odměna za poskytnutí licence dle předchozí věty je zahrnuta v ceně dle odst. 6.1. Smluvní strany tímto pro vyloučení případných pochybností výslovně prohlašují, že veškerá finanční vyrovnání za užívání Autorského díla jsou zahrnuta v ceně dle odst. 6.1. Licence zahrnuje aktualizace Autorských děl a Databází vytvořených Zhotovitelem během trvání této Smlouvy a servisní smlouvy k dílu.
b) Zhotovitel prohlašuje, že s ohledem na povahu výnosů z licence nemohou vzniknout podmínky pro uplatnění ustanovení § 2374 OZ, tedy, že odměna za udělení licence k jednotlivým Autorským dílům nemůže být ve zřejmém nepoměru k zisku z využití licence a významu příslušného Autorského díla pro dosažení takového zisku.
c) Zhotovitel Objednateli poskytuje výhradní oprávnění (licenci, resp. podlicenci) užít zdrojové kódy k veškerým Autorským dílům vytvořeným v rámci Díla na zakázku pro Objednatele za podmínek dle této Smlouvy.
d) Zhotovitel je povinen předat Objednateli zdrojové kódy počítačového programu, a to ve formě zdrojových souborů připravených ke kompilaci nebo přeložení do spustitelné formy programu, a to včetně dokumentace, programovacího prostředí potřebného k úpravám zdrojových kódů programu včetně možnosti rozvoje programu (a to včetně potřebných licencí, komponent, knihoven, compileru, debuggeru k tomuto
programovacímu prostředí) a popis instalačního postupu programovacího prostředí
programu, a to nejpozději v den předání a převzetí příslušného Autorského díla.
e) Zhotovitel bude uchovávat a aktualizovat zdrojový kód a další materiály po dobu trvání
Smlouvy a servisní smlouvy k dílu. Zhotovitel bude dále informovat Objednatele
o postupech takové aktualizace a též vždy, když bude aktualizace provedena, neprodleně dodá aktualizované verze zdrojových kódů a souvisejících materiálů dle tohoto odst. 10.02.1 Objednateli.
10.2.2 Udělení licence třetí osobou
Pro všechny případy, ve kterých nemůže Zhotovitel z objektivních důvodů sám udělit Objednateli oprávnění dle odst. 10.2.1 k Autorskému dílu či Databázi vytvořeným na zakázku pro Objednatele v rámci plnění této Smlouvy, Xxxxxxxxxx zajistí, že třetí osoba, jež vykonává majetková práva k příslušnému Autorskému dílu, resp. práva pořizovatele Databáze, udělí Objednateli bezúplatně výhradní oprávnění (licenci) Autorské dílo užít, resp. právo vytěžovat a zužitkovat Databázi v rozsahu a za podmínek dle odst. 10.2.1, a dále výhradní oprávnění (licenci) užít zdrojové kódy k tomuto Autorskému dílu v rozsahu a za podmínek dle odst.
10.2.1 a to tak, že příslušné oprávnění bude Objednateli uděleno v písemné formě nejpozději v den předání příslušného Autorského díla či Databáze. Nebude-li Objednateli v den předání příslušného Autorského díla či Databáze předloženo v písemné formě udělení oprávnění třetí osobou dle předchozí věty, znamená to, že příslušná oprávnění udělil objednateli Xxxxxxxxxx dle odst. 10.2.1. Poruší-li Zhotovitel jakoukoli povinnost dle tohoto odst. 10.2.2 a v důsledku tohoto porušení vznikne Objednateli jakákoli újma, je Zhotovitel povinen nahradit Objednateli tuto újmu v plném rozsahu.
10.3. Licence ke standardním autorským dílům a databázím
10.3.1 Udělení licence Zhotovitelem
a) Pro všechny případy, ve kterých je součástí Díla dle této Smlouvy Autorské dílo nebo Databáze, které nebudou vytvořeny na zakázku pro Objednatele, a nebude se jednat
o standardní Autorské dílo a Databáze uvedené v části 3.2.3 Přílohy č. 1 této Smlouvy, Zhotovitel poskytuje Objednateli nevýhradní oprávnění k výkonu práva užít (licenci, resp. podlicenci) veškerá taková Autorská díla a k výkonu práva vytěžovat a zužitkovat Databáze vytvořené na zakázku pro Objednatele v rámci plnění této Smlouvy, a to v územně a množstevně neomezeném rozsahu a všemi známými způsoby užití, a to na celou dobu trvání majetkových práv autora, a k postoupení nebo poskytnutí oprávnění tvořících součást této licence (podlicenci) zcela nebo zčásti jakékoliv třetí osobě, a to včetně svolení Autorská díla a k výkonu práva vytěžovat a zužitkovat, (zcela i z části) měnit, spojovat, upravovat, rozdělovat, spojovat s jinými díly, zařazovat je do děl souborných, dopracovat, vše zcela samostatně či prostřednictvím třetí osoby. Databáze, a to v územně neomezeném rozsahu a všemi způsoby odpovídajícími účelu, pro který je takové Autorské dílo, resp. Databáze, určeno, a to na celou dobu trvání majetkových práv autora, a v potřebném množstevním rozsahu odpovídajícím účelu, pro který je takové Autorské dílo, resp. Databáze, určeno, a dále souhlas k postoupení nebo poskytnutí oprávnění tvořících součást této licence (podlicenci) zcela nebo zčásti jakékoliv třetí osobě. Odměna za poskytnutí licence dle předchozí věty je zahrnuta v ceně dle odst. 6.1. Smluvní strany tímto pro vyloučení případných pochybností výslovně prohlašují, že veškerá finanční vyrovnání za užívání Autorského díla jsou zahrnuta v ceně dle odst. 6.1.
b) Licenci dle předchozího písm. a) není Objednatel povinen využít.
c) Zhotovitel prohlašuje, že s ohledem na povahu výnosů z licence k Autorským dílům nemohou vzniknout podmínky pro uplatnění ustanovení § 2374 OZ, tedy, že odměna za udělení licence k jednotlivým Autorským dílům nemůže být ve zřejmém nepoměru
k zisku z využití licence a významu příslušného Autorského díla pro dosažení takového
zisku.
10.3.2 Udělení licence třetí osobou
Pro všechny případy, ve kterých nemůže Zhotovitel z objektivních důvodů sám udělit Objednateli oprávnění ke standardním Autorským dílům a Databázím dle odst. 10.3.1. této Smlouvy, Xxxxxxxxxx zajistí, že třetí osoba, která má užívací práva k Autorskému dílu, resp. Databázi, Objednateli poskytne bezúplatně oprávnění (licenci) k užití Autorského díla, resp. právo vytěžovat a zužitkovat Databázi za podmínek dle odst. 10.3.1., a to nejpozději v den předání příslušného Autorského díla či Databáze. Nebude-li Objednateli v den předání příslušného Autorského díla či Databáze předloženo v písemné formě udělení oprávnění třetí osobou dle předchozí věty, znamená to, že příslušná oprávnění udělil Objednateli Zhotovitel dle odst. 10.3.1. Poruší-li Zhotovitel jakoukoli povinnost dle tohoto odst. 10.3.2 a v důsledku tohoto porušení vznikne Objednateli jakákoli újma, je Zhotovitel povinen nahradit Objednateli tuto újmu v plném rozsahu.
Článek 11.
Záruka, odpovědnost za újmu
11.1 Zhotovitel prohlašuje, že systém bude mít požadované vlastnosti a bude způsobilý k používání dle této Smlouvy a právních předpisů po dobu 12 měsíců ode dne převzetí díla Objednatelem závěrečným předávacím protokolem dle odst. 5.7 této Smlouvy (tímto prohlášením Zhotovitel přebírá záruku za jakost ve smyslu § 1919 odst. 1 OZ). Zhotovitel se zavazuje po dobu trvání záruky odstranit na své náklady veškeré vady a případné nedodělky, které se na díle objeví či zjistí během trvání záruční doby. Vadou, na niž se vztahuje záruka, se pro účely této Smlouvy rozumí odchylka v kvalitě nebo parametrech Systému, stanovených touto Smlouvou nebo v dokumentech vypracovaných v souvislosti s touto Smlouvou, a pokud nejsou výslovně stanoveny, je určující kvalita nebo parametry obvyklé pro takovýto druh plnění (tj. související s plněním úkolů orgánů státní správy). Za vadu není považována funkčnost systému, jejíž popis není v dokumentaci uveden, a která negativně neovlivňuje funkčnost systému. Za vadu systému, na níž se vztahuje záruka, se dále považuje skutečnost, že při používání systému se vyskytne některý (nebo i současně) z dále uvedených případů: (i) nefunkčnost některé v Příloze č. 1 až č. 2 uvedené funkcionality, a (ii) případ, kdy systém poskytuje výstupy odchylné od očekávaných hodnot daných požadovanými algoritmy či postupy zpracování požadovanými procesy.
11.2 Smluvní strany se dohodly, že v případě, že Zhotovitel z jakéhokoliv důvodu nedokončí dílo (dohoda smluvních stran, odstoupení jedné smluvní strany od této Smlouvy, vyšší moc apod.), pak tato záruka za jakost platí pro jednotlivé části díla, které budou řádně provedené a předané. Tyto provedené části díla budou specificky uvedené v protokolu o převzetí části díla (úplného či neúplného), který bude podepsán smluvními stranami. Lhůta záruky počíná běžet od data tohoto protokolu o převzetí nedokončeného díla.
11.3 Zhotovitel prohlašuje, že záruka uvedená v odst. 11.1 se vztahuje i na jednotlivé části díla, které neprovedl či nedodal sám Xxxxxxxxxx, ale provedl ho některý z poddodavatelů. Z tohoto důvodu je Xxxxxxxxxx povinen smluvně zavázat své poddodavatele takovým způsobem, aby práva z jimi poskytovaných záruk za jakost byla minimálně stejná jako u záruky za jakost Xxxxxxxxxxx, a aby tato práva bez dalšího náležela i Objednateli a jeho právním nástupcům (zejména bez potřeby dalšího souhlasu příslušného poddodavatele). Xxxxxxxxxx je povinen kdykoliv na požádání Objednatele, nejpozději však při předání a převzetí díla, předat mu záruční listy na jednotlivé jeho části podle určení Objednatele a potvrdit mu písemně i záruční práva vůči všem příslušným poddodavatelům, popř. na něj převést práva z těchto záruk. Deklarují-li záruční listy předané dle předchozí věty kratší záruční dobu, než je stanovena v odst. 11.1, platí záruční doba dle odst.11.1.
11.4 Po dobu, po kterou Objednatel nemůže užívat dílo pro vady, na které se vztahuje záruka, záruční doba neběží.
11.5 Zhotovitel neodpovídá za škodu vzniklou dodržením příkazů Objednatele v případě, kdy Zhotovitel bezodkladně písemně sdělil nevhodnost příkazů a upozornil Objednatele na možná rizika, a Objednatel přesto písemně trval na postupu podle takových příkazů.
11.6 Zhotovitel i po uplynutí záruční doby dle této Xxxxxxx odpovídá za případné vady díla, pokud dílo tyto vady mělo v době dokončení díla, a to zejména pokud byly způsobeny porušením smluvních povinností Xxxxxxxxxxx při provádění díla.
11.7 Smluvní strany se dohodly, že pokud Objednatel bude uplatňovat nárok ze záruky za jakost díla, bude tak činit písemně (za což je považována i forma e-mailu) či prostřednictvím helpdeskové aplikace Objednatele. V oznámení o vadě (vadách) díla uvede popis vady (vad) díla, jak se tato vada projevuje a navrhne způsob řešení vzniklé situace, pokud ho vzhledem k okolnostem může znát.
11.8 O průběhu každého reklamačního řízení je Zhotovitel povinen vést průběžně a chronologicky označené řádné záznamy, přičemž závěrem každého takového řízení bude zápis s uvedením, jakým způsobem a kdy byla reklamace vyřízena (např. jak byla vada odstraněna).
11.9 Zhotovitel je povinen započít s odstraňováním vady neprodleně po oznámení vady tak, aby nedocházelo zejména k omezování běžné činnosti Objednatele, popř. ke zbytečnému prodlužování trvání této vady či ke vzniku škod na straně Objednatele. Vady je Zhotovitel povinen odstranit nejpozději do 5 pracovních dnů od oznámení vady Objednatelem. Zhotovitel je povinen odstraňovat záruční vady bezplatně.
11.10 V případě, že Zhotovitel neodstraní vadu či jinak neposkytne plnění podle oznámení o vadě či nebude jednat s Objednatelem o odstranění vady, a to nejdéle do 10 dnů od doručení oznámení o vadě, je Objednatel oprávněn zajistit odstranění vady sám a vyúčtovat Zhotoviteli veškeré náklady spojené s odstraněním takové vady. Zhotovitel je povinen proplatit tyto uplatněné náklady oproti předložení dokladů prokazujících jejich výši.
11.11Zhotovitel odpovídá za veškerou újmu, způsobenou v důsledku porušení ustanovení této Smlouvy či platných právních předpisů na majetku Objednatele či na majetku třetích osob v průběhu realizace Xxxx a v příčinné souvislosti s jeho prováděním. Újma dle předchozí věty zahrnuje nemajetkovou újmu i majetkovou škodu, vyjádřenou v penězích.
Článek 12.
Sleva z ceny
12.1 Objednatel má za podmínek stanových tímto článkem právo na uplatnění slevy z ceny díla uvedené v odst. 6.1, přičemž Zhotovitel má v případě vzniku nároku na slevu z ceny povinnost při vystavování faktury zohlednit výši případné slevy.
12.2 V případě, že je Xxxxxxxxxx v prodlení s předáním části díla podle odst. 1.2 písm. a) k akceptaci, tj. nepředá-li uvedenou část díla k akceptaci v termínu uvedeném v odst. 5.2, vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,5 % z části ceny díla uvedené v odst. 6.5 písm. a) za každý započatý kalendářní den prodlení.
12.3 V případě, že je Xxxxxxxxxx v prodlení s předáním částí díla podle odst. 1.2 písm. b) až h) k akceptaci, tj. nepředá-li všechny uvedené části díla k akceptaci v termínu uvedeném v odst. 5.3, vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,05 % z části ceny díla uvedené v odst. 6.5 písm. b) za každý započatý kalendářní den prodlení.
12.4 V případě, že je Xxxxxxxxxx v prodlení s předáním části díla podle odst. 1.2 písm. i) k akceptaci, tj. nepředá-li uvedenou část díla k akceptaci v termínu uvedeném v odst. 5.4, vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,1 % z části ceny díla uvedené v odst. 6.5 písm. c) za každý započatý kalendářní den prodlení.
12.5 Pokud Zhotovitel nezapracuje připomínku či připomínky Objednatele, resp. neodstraní Objednatelem vytknutou vadu či vady v rámci akceptace části díla dle odst. 1.2 písm. a) do uplynutí lhůty pro akceptační řízení stanovené v odst. 5.6 písm. a) bod iii., vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,5 % z části ceny díla uvedené v odst. 6.5 písm. a) za každý započatý kalendářní den prodlení se splněním této povinnosti.
12.6 Pokud Zhotovitel neodstraní Objednatelem vytknutou vadu či vady v rámci akceptace kterékoli části díla dle odst. 1.2 písm. b) až h) do uplynutí lhůty pro akceptační řízení stanovené v odst. 5.6 písm. b) bod iii., vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,05 % z části ceny díla uvedené v odst. 6.5 písm. b) za každý započatý kalendářní den prodlení se splněním této povinnosti.
12.7 Pokud Zhotovitel neodstraní Objednatelem vytknutou vadu či vady v rámci akceptace části díla dle odst. 1.2 písm. i) do uplynutí lhůty pro akceptační řízení stanovené v odst. 5.6 písm.
c) bod iii., vzniká Objednateli nárok na slevu z ceny díla uvedené v odst. 6.1 ve výši 0,1 % z části ceny díla uvedené v odst. 6.5 písm. c) za každý započatý kalendářní den prodlení se splněním této povinnosti.
12.8 Je-li úhrn výše slev vypočtených podle odst. 12.2 a 12.5 vyšší než část ceny díla uvedená v odst. 6.5 písm. a) vzniká Objednateli nárok na slevu ve výši části ceny díla uvedené v odst. 6.5 písm. a). Tato skutečnost je považována za porušení smlouvy podstatným způsobem ze strany Zhotovitele.
12.9 Je-li úhrn výše slev vypočtených podle odst. 12.3 a 12.6 vyšší než část ceny díla uvedená v odst. 6.5 písm. b) vzniká Objednateli nárok na slevu ve výši části ceny díla uvedené v odst. 6.5 písm. b). Tato skutečnost je považována za porušení smlouvy podstatným způsobem ze strany Zhotovitele.
12.10 Je-li úhrn výše slev vypočtených podle odst. 12.4 a 12.7 vyšší než část ceny díla uvedená v odst. 6.5 písm. c) vzniká Objednateli nárok na slevu ve výši části ceny díla uvedené v odst. 6.5 písm. c). Tato skutečnost je považována za porušení smlouvy podstatným způsobem ze strany Zhotovitele.
12.11 Nárok Objednatele na slevu z ceny se nedotýká závazku Zhotovitele splnit povinnost, se kterou je v prodlení, ani nároku Objednatele na případnou smluvní pokutu či odpovědnosti Xxxxxxxxxxx za újmu způsobenou tímto prodlením.
Článek 13.
Smluvní pokuty
13.1 V případě porušení jakékoli povinnosti stanovené v čl. 9 této Smlouvy je Xxxxxxxxxx povinen
uhradit Objednateli smluvní pokutu ve výši 1.000.000,- Kč za každé jednotlivé porušení.
13.2 V případě porušení jakékoli povinnosti stanovené v čl. 8 je Zhotovitel povinen uhradit
Objednateli smluvní pokutu ve výši 500.000,- Kč za každé jednotlivé porušení.
13.3 Při porušení každé jednotlivé povinnosti stanovené v odst. 3.8 či 3.9 uhradí Zhotovitel Objednateli smluvní pokutu ve výši 20.000,- Kč za každé jednotlivé porušení.
13.4 Poruší-li Zhotovitel jakoukoli povinnost dle odst. 3.15, je povinen uhradit Objednateli smluvní pokutu ve výši 1.000,- Kč za každý započatý kalendářní den prodlení se splněním této
povinnosti. V případě opakovaného porušení je Zhotovitel povinen hradit tuto smluvní
pokutu Objednateli opakovaně.
13.5 Úhradou smluvní pokuty se Zhotovitel nezbavuje povinnosti poskytnout Objednateli sjednané plnění ze Smlouvy. Zaplacení smluvní pokuty Objednateli nezbavuje Xxxxxxxxxxx povinnosti zaplatit Objednateli veškeré škody a prokázané náklady, které mu vznikly v souvislosti s porušením povinnosti, k níž se smluvní pokuta vztahuje.
Článek 14.
Trvání Smlouvy
14.1 Tato Xxxxxxx se uzavírá na dobu určitou do doby splnění předmětu Xxxxxxx.
14.2 Smluvní strany se dohodly, že tato Xxxxxxx pozbývá platnosti před uplynutím doby dle předchozího odstavce z těchto důvodů:
a) Výpovědí.
b) Ztrátou oprávnění Zhotovitele k výkonu činnosti, které je zapotřebí pro provedení díla.
c) Písemnou dohodou smluvních stran.
14.3 V případě ukončení Smlouvy zůstávají i po jejím skončení v platnosti a účinnosti veškerá ujednání smluvních stran ohledně odpovědnosti Zhotovitele za škodu, nároku na smluvní pokutu a ochrany důvěrných informací.
Článek 15.
Výpověď a odstoupení od Xxxxxxx
15.1 Objednatel je oprávněn tuto Smlouvu zcela či zčásti vypovědět, a to i bez uvedení důvodu. Výpověď musí být písemná a musí být prokazatelně doručena Zhotoviteli. Výpovědní doba je 3 měsíce a počíná běžet prvním dnem měsíce bezprostředně následujícího po měsíci prokazatelného doručení výpovědi Zhotoviteli. Zhotovitel je oprávněn tuto Smlouvu vypovědět pouze z důvodu prokazatelného neposkytnutí součinnosti Objednatele v souladu s odst. 4.2. Výpověď musí být písemná a musí být prokazatelně doručena Objednateli. Výpovědní doba je 3 měsíce a počíná běžet prvním dnem měsíce bezprostředně následujícího po měsíci prokazatelného doručení výpovědi Objednateli. Za řádné doručení výpovědi se považuje její doručení prostřednictvím poskytovatele poštovních služeb, kurýra nebo její doručení do datové schránky druhé smluvní strany.
15.2 Objednatel je dále oprávněn vypovědět tuto Smlouvu ve lhůtě 10 kalendářních dnů od podpisu akceptačního a předávacího protokolu části díla dle odst. 1.2 písm. a). Výpověď musí být písemná a musí být prokazatelně doručena Zhotoviteli. Výpovědní doba činí v tomto případě 7 kalendářních dnů a počíná běžet dnem bezprostředně následujícím po dni prokazatelného doručení výpovědi Zhotoviteli. Za řádné doručení výpovědi se považuje její doručení prostřednictvím poskytovatele poštovních služeb, kurýra nebo její doručení do datové schránky Zhotovitele. Smluvní strany pro vyloučení pochybností shodně prohlašují, že vypovězení Smlouvy Objednatelem dle tohoto odstavce není porušením Smlouvy a neopravňuje Zhotovitele k uplatnění jakýchkoli náhrad škod, kompenzací či jiných obdobných sankcí vůči Objednateli.
15.3 Po obdržení výpovědi je Xxxxxxxxxx povinen pokračovat v provádění díla až do uplynutí výpovědní doby, pokud jej Objednatel písemně nevyzve k zastavení prací na díle; takovou výzvu je Xxxxxxxxxx povinen bezodkladně respektovat. Zároveň je povinen Objednatele upozornit na opatření potřebná k tomu, aby se zabránilo vzniku škody bezprostředně hrozící Objednateli nedokončením určité činnosti.
15.4 V případě ukončení Smlouvy výpovědí je Xxxxxxxxxx povinen předat Objednateli dosavadní výsledek své činnosti ke dni ukončení. Zhotovitel má v takovém případě nárok pouze na úhradu ceny díla odpovídající rozsahu jeho splnění, pokud došlo k akceptaci a převzetí příslušné části díla Objednatelem (tj. k oboustrannému podpisu akceptačního a předávacího protokolu takové části díla v souladu s odst. 5.7).
15.5 Smluvní strana je oprávněna bez zbytečného odkladu odstoupit od této Smlouvy v případech stanovených touto Smlouvou či v případě, že druhá smluvní strana poruší tuto Smlouvu podstatným způsobem ve smyslu § 2002 OZ.
15.6 Odstoupení od smlouvy je smluvní strana povinna sdělit druhé smluvní straně formou písemného oznámení o odstoupení. Z oznámení musí být zřejmé, v čem odstupující smluvní strana spatřuje podstatné porušení Smlouvy včetně odkazu na konkrétní porušenou smluvní povinnost.
15.7 Odstoupení od Xxxxxxx je účinné doručením písemného oznámení o odstoupení druhé smluvní straně, pokud z obsahu odstoupení nevyplývá pozdější účinek odstoupení. Za řádné doručení oznámení o odstoupení od Xxxxxxx se považuje jeho doručení prostřednictvím poskytovatele poštovních služeb, kurýra nebo jeho doručení do datové schránky druhé smluvní strany.
15.8 Pro případ odstoupení od Smlouvy kteroukoliv ze smluvní stran se smluvní strany dohodly na následujícím způsobu vypořádání:
a) Objednatel si ponechá všechny řádně akceptované a Zhotovitelem předané části díla;
b) Zhotovitel si ponechá všechna Objednatelem poskytnutá peněžitá plnění za každou část díla, kterou si Objednatel ponechá dle písm. a) tohoto odstavce;
c) všechna ostatní vzájemná plnění dle této Smlouvy neuvedená v písm. a) nebo b) tohoto odstavce, mezi sebou smluvní strany vypořádají dle ustanovení § 2991 a násl. OZ upravujících bezdůvodné obohacení.
15.9 Odstoupením od Smlouvy nejsou dotčena ustanovení týkající se ochrany informací, řešení sporů, zajištění pohledávky kterékoliv ze Smluvních stran, náhrady škody a ustanovení týkajících se těch práv a povinností, z jejichž povahy vyplývá, že mají trvat i po odstoupení od Smlouvy (zejména jde o povinnost poskytnout peněžitá plnění za plnění poskytnutá před účinností odstoupení od Smlouvy). V případě odstoupení ze strany Objednatele je tento oprávněn určit, zda si již akceptovaná a plnění ponechá nebo budou vrácena Zhotoviteli a vzájemně vypořádána.
Článek 16. Vyšší moc
16.1 Smluvní strany nejsou odpovědné za částečné nebo úplné neplnění smluvních závazků následkem vyšší moci. Za vyšší moc se považují okolnosti, vzniklé po podepsání této smlouvy jako následek nevyhnutelných událostí mimořádné povahy, které mají přímý vliv na plnění předmětu Smlouvy a které smluvní strana uplatňující existenci vlivu (působení) vyšší moci, nemohla předpokládat před uzavřením této Smlouvy, a které nemůže tato dotčená smluvní strana ovlivnit při vynaložení veškerého svého úsilí.
16.2 Vyskytne-li se působení vyšší moci, lhůty ke splnění smluvních závazků se prodlouží o dobu
jejího působení.
16.3 Smluvní strana postižená vyšší mocí je povinna druhou smluvní stranu uvědomit písemně
o zahájení působení vyšší moci neprodleně nejpozději však do 15 kalendářních dnů a totéž
se týká konce působení. Pokud tak neučiní, nemůže se smluvní strana účinně dovolávat působení vyšší moci.
16.4 Pokud by působení vyšší moci mělo za následek pozastavení plnění smluvních závazků na dobu delší než 2 měsíce, popř. je zřejmé, že působení vyšší moci bude bránit v plnění po dobu delší než 2 měsíce, smluvní strany se zavazují nechat provést znalecké posouzení dosavadního provedeného díla a na jeho základě se dohodnout na podmínkách dalšího pokračování nebo ukončení této Smlouvy.
Článek 17.
Salvatorní ustanovení
17.1 Je-li nebo stane-li se některé ustanovení této Smlouvy neplatné, neúčinné či nevymahatelné, zůstávají ostatní ustanovení této Smlouvy platná a účinná. Namísto neplatného, neúčinného nebo nevymahatelného ustanovení se použijí ustanovení obecně závazných právních předpisů upravujících otázku vzájemného vztahu smluvních stran. Strany se pak zavazují upravit svůj vztah přijetím jiného ustanovení, které svým výsledkem nejlépe odpovídá záměru ustanovení neplatného, resp. neúčinného či nevymahatelného. Pokud bude v této Smlouvě chybět jakékoli ustanovení, jež by jinak bylo přiměřené z hlediska úplnosti úpravy práv a povinností, vynaloží Strany maximální úsilí k doplnění takového ustanovení do této Smlouvy.
Článek 18.
Závěrečná ustanovení
18.1 Oprávněnými osobami smluvních stran pro jednání ve věcech plnění této Smlouvy jsou tyto osoby (kterákoli z uvedených):
Za Objednatele:
XXX XXX XXX XXX XXX XXX XXX
Za Zhotovitele:
XXX XXX
Telefonní číslo Zhotovitele pro hlášení závad: XXX
E-mail Zhotovitele pro hlášení závad: xxxxxxx@xxxxxxx.xxx
Zhotovitel se zavazuje neprodleně po uzavření této Smlouvy informovat své oprávněné osoby pro jednání ve věcech plnění této Smlouvy o zpracování jejich osobních údajů v rozsahu tohoto odstavce Objednatelem, a to po dobu platnosti této Smlouvy pro účely plnění této Smlouvy.
18.2 Nedílnou součástí této Smlouvy jsou přílohy: Příloha č. 1 – Specifikace předmětu díla
Příloha č. 2 – Návrh řešení přehledné nástěnky (dashboardu) pro roli Xxxxxxx Xxxxxxx č. 3 – Seznam členů Realizačního týmu
Příloha č. 4 – Bezpečnostní pravidla pro významné dodavatele
Příloha č. 5 – Formulář žádosti o přístup k informačním systémům (např. serverům)
Objednatele
Příloha č. 6 – Seznam oprávněných poddodavatelů
18.3 Zhotovitel není oprávněn postoupit jakákoli svá práva a převádět povinnosti z této Smlouvy na třetí osobu bez předchozího písemného souhlasu Objednatele, a to ani částečně.
18.4 Smluvní strany se dohodly, že Zhotovitel a Objednatel nejsou oprávněni započíst si
vzájemně své pohledávky z této Smlouvy.
18.5 Zhotovitel, jako Smluvní strana, vůči níž se práva z této Smlouvy promlčují, tímto výslovným prohlášením ve smyslu § 630 odst. 1 OZ prodlužuje délku promlčecí doby práv Objednatele vyplývajících z této Smlouvy na dobu 15 let.
18.6 Tuto Smlouvu lze měnit pouze písemným, číslovaným a oboustranně potvrzeným ujednáním, výslovně nazvaným dodatek ke smlouvě. Jiné zápisy, protokoly apod. se za změnu smlouvy nepovažují.
18.7 Nastanou-li u některé ze smluvních stran skutečnosti bránící řádnému plnění této Smlouvy, je povinna to neprodleně oznámit druhé smluvní straně.
18.8 Smluvní strany se dohodly, že veškeré spory, které případně z této Smlouvy vzniknou, budou řešeny smírnou cestou a teprve nedojde-li ke smíru, bude přistoupeno k soudnímu jednání.
18.9 Tato Smlouva je vyhotovena ve 2 stejnopisech, z nichž každá smluvní strana obdrží po
1 vyhotovení.
18.10 Smluvní strany prohlašují, že si Xxxxxxx pozorně přečetly a že je jim její obsah jasný a srozumitelný. Prohlašují, že tato Smlouva nebyla sjednána ani v tísni, ani za jinak jednostranně nevýhodných podmínek.
18.11 Ve všech případech, které neřeší ujednání obsažená v této Smlouvě, platí příslušná ustanovení OZ, případně dalších předpisů platného práva České republiky.
18.12 Zhotovitel bere na vědomí povinnost zveřejnit Xxxxxxx v registru smluv (dále jen „registr smluv“) v souladu se zákonem č. 340/2015 Sb., o registru smluv, a podpisem této Smlouvy vyslovuje souhlas se zveřejněním všech údajů uvedených ve Smlouvě Objednatelem v registru smluv zřízeném uvedeným zákonem, vyjma osobních údajů. Zhotovitel výslovně prohlašuje, že žádný údaj uvedený v této Smlouvě a jejích přílohách není obchodním tajemstvím ve smyslu § 504 OZ.
18.13 Tato Xxxxxxx vyjma Článku 10 nabývá platnosti dnem podpisu oběma smluvními stranami a účinnosti dnem uveřejnění v registru smluv. Článek 10 nabývá účinnosti dnem převzetí příslušného Autorského díla Objednatelem.
Na důkaz toho, že celý obsah Smlouvy je projevem jejich pravé, vážné a svobodné vůle, připojují osoby oprávněné za smluvní strany uzavřít tuto Smlouvu své vlastnoruční podpisy.
V Praze dne ………………………. V Praze dne ……………………….
Objednatel: Zhotovitel:
6.3.2023 14.2.2023
……………………………………… ……………………………….
Xxx. Xxxxx Xxxxxxx, MHA XXX
ředitelka Státního ústavu pro kontrolu léčiv
Příloha č. 1
ke Smlouvě o dílo –
SPECIFIKACE PŘEDMĚTU DÍLA
Obsah
2.1 Stávající systém pro vedení správních řízení 6
2.2 Obsah a rozsah stávajícího systému 7
3 Specifikace předmětu dodávky 8
3.1.1 Uživatelské požadavky na vedení správních řízení (SŘ) 9
3.1.2 Provázanost na systémy SÚKL 22
3.1.3 Přechod ze současné verze na nové SŘDLP 25
3.2 Požadavky Objednatele na technické řešení 25
3.2.1 Obecné technické požadavky na předmět dodávky 25
3.2.2 Využití aktuálních technologických standardů 26
3.2.3 Využití stávajících zdrojů Objednatele 26
3.2.4 Parametry stanic interních uživatelů 27
3.3.6 Administrátorské účty 32
3.3.8 Vzhled uživatelského webového rozhraní 32
3.3.9 Uživatelské rozhraní pro správu parametrů SŘDLP 33
3.3.10 Uživatelské rozhraní pro správu číselníků 33
3.3.11 Integrace s klientskými IS 33
4.1.3 Administrátorská příručka 35
4.1.4 Uživatelská dokumentace 35
4.1.5 Systémová dokumentace 35
4.1.6 Bezpečnostní dokumentace 35
5.5 Migrace ze stávajícího systému 39
5.5.1 Parametry současného stavu 39
5.6 Implementace do testovacího a produkčního prostředí 40
5.7 Nasazení SŘDLP do produkčního prostředí 40
6 Xxxxxx s právními předpisy 41
1 SEZNAM ZKRATEK
Zkratka | Popis |
AD | Active Directory |
API | Application Programming Interface, rozhraní pro programování aplikací |
ATC | Anatomicko - terapeuticko - chemická skupina |
AthenA | Spisová služba |
CAU | Sekce cenové a úhradové regulace |
CMS | Centrální místo služeb |
CSV | Comma-separated values, jednoduchý souborový formát určený pro výměnu tabulkových dat |
CVE | Common Vulnerabilities and Exposures (obecné zranitelnosti a ohrožení), seznam standardizovaných názvů pro zranitelnosti a další ohrožení informační bezpečnosti |
č.j. | Číslo jednací |
DB | Databáze |
DIS13 | Existující systém Objednatele, evidence distribuovaných objemů LP |
DLP | Databáze léčivých přípravků |
eHealth | Elektronické zdravotnictví. Strategické kroky určuje „Národní plán rozvoje eHealth“ stanovený Českým národním fórem pro eHealth a ICT Unií |
eIDAS | Zkratka pro nařízení Evropského parlamentu a Rady(EU) č. 910/2014, o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu. |
EU | Evropská unie |
FEA | Oddělení farmakoekonomických analýz |
HA | High availability (vysoká dostupnost), pojem vyjadřující spolehlivost systémů a služeb obvykle v oboru výpočetní techniky |
HOD | Hodnotitel |
HW | Hardware |
HZ | Hodnotící zpráva |
ICT Unie | Spolek, profesní organizace ICT průmyslu podporující směřování k evropské informační společnosti a modernímu výkonu státní a veřejné správy pracující efektivně pro občany i podnikatelský sektor |
JIP | Jednotný identitní prostor - zabezpečený adresář orgánů veřejné moci a uživatelských účtů úředníků |
JSON | JavaScript Object Notation, datový formát nezávislý na počítačové platformě |
XXXX | Katalog autentizačních a autorizačních služeb - rozhraní webových služeb umožňující autentizaci uživatelů přistupujících do AIS či ISVS pomocí přihlašovacích údajů v JIP a umožňující editaci údajů subjektů a uživatelských účtů v JIP |
KIVS | Komunikační infrastruktura veřejné správy |
KPIs | Klíčové ukazatele výkonnosti (key performance indicators) |
KSŘ | Oddělení koordinace správních řízení |
LDAP | Lightweight Directory Access Protocol je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru |
XX | Xxxxxx látka |
LP | Léčivý přípravek |
MAH | Držitel rozhodnutí o registraci |
MZ ČR | Ministerstvo zdravotnictví České republiky |
NIA | Národní bod pro identifikaci a autentizaci - systém pro bezpečné a zaručené vzdálené ověřování totožnosti uživatelů |
NRPZS | Národní registr poskytovatelů zdravotních služeb |
NRZP | Národní registr zdravotnických pracovníků |
OHL | Oddělení hodnocení léčiv |
OOP | Opatření obecné povahy |
OpenData | Otevřená data |
OS | Operační systém |
OS | Odborná společnost |
OT | Obchodní tajemství |
Portable Document Format, souborový formát vyvinutý firmou Adobe pro ukládání dokumentů nezávisle na softwaru i hardwaru, na kterém byly pořízeny | |
PZLÚ | Potravina pro zvláštní lékařské účely |
REST | Representational State Transfer, architektura rozhraní, navržená pro distribuované prostředí |
ROB | Registr obyvatel |
ROS | Registr osob |
RS | Referenční skupina |
SCAU | Seznam cen a úhrad LP/PZLÚ |
SCUP | Seznam LP/PZLÚ používaných pouze při ústavní péči |
SIEM | Kompletní systém, zajišťující sběr, centrální ukládání a vyhodnocení bezpečnostních událostí ze sítě, serverů a dalších zdrojů. V rámci SÚKL je implementován produkt IBM Security QRadar SIEM. |
sp. zn. | Spisová značka, alfanumerický kód identifikující spis příslušného správního řízení ve spisové službě, jedná se o jednoznačný identifikátor správního řízení |
SpLP | Specifický léčebný program |
SŘ | Správní řízení |
SŘDLP | Pracovní název pro novou aplikaci, která je předmětem dodávky této veřejné zakázky |
SSL | Secure Sockets Layer, protokol, resp. vrstva vložená mezi vrstvu transportní (např. TCP/IP) a aplikační (např. HTTP), která poskytuje zabezpečení komunikace šifrováním a autentizaci komunikujících stran |
SÚKL | Státní ústav pro kontrolu léčiv |
SW | Software |
TLS | Transport Layer Security, kryptografický protokol poskytující možnost zabezpečené komunikace |
VMware | Software pro virtualizaci prostředí na počítači nebo serveru |
VTS | Oddělení vybraných typů správních řízení |
VZ | Veřejná zakázka |
WS | Webová služba |
XML | eXtensible Markup Language, tedy „rozšířitelný značkovací jazyk“, jazyk pro snadný přenos dat a komunikaci nezávislou na konkrétní aplikaci či platformě |
ZR | Základní registry |
2 POPIS STÁVAJÍCÍHO STAVU
2.1 Stávající systém pro vedení správních řízení
Stávající systém Objednatele pro vedení správních řízení slouží pro podporu administrativních a odborných činností spojených s vyřizováním správních řízení pro stanovování maximálních cen a úhrad LP/PZLÚ ze zdravotního pojištění.
Jedná se především o následující agendy a činnosti:
- Vedení dokumentace jednotlivých správních řízení
- Sledování průběhů, harmonogramů a etap jednotlivých řízení
- Sledování dodržování zákonných lhůt jednotlivých řízení
- Podpora tvorby dokumentů řízení (poloautomatické vyplňování formulářů, tvorba PDF, elektronické podepisování a elektronické odesílání do spisové služby)
- Podpora odborných evidencí spojených s agendou správních řízení (evidence zařazení LP do referenčních skupin, vedení číselníku referenčních skupin), číselníky organizací a osob
- Tvorba přehledů a manažerských výstupů potřebných pro provoz
- Komunikace s DLP
- Příprava a odesílání podkladů na web o správních řízeních
Stávající systém je třívrstvá aplikace složená z aplikace, databáze a webových služeb, komunikujících prostřednictvím XML. Je těsně napojena na databázi DLP, ve které SÚKL vede informace o držitelích rozhodnutí o registraci léčivých přípravků, informace o léčivých přípravcích, obsažených léčivých látkách, o vazbách a souvislostech mezi nimi, další parametry LP a informace o schválených a dostupných baleních v ČR. Aplikace má dále těsnou vazbu na spisovou službu AthenA a příslušné spisy související se SŘ, do spisu ukládané oficiální písemnosti a v nich obsažené dokumenty pro SŘ, oficiální informační kanál pro komunikaci s účastníky SŘ a vydání rozhodnutí o výsledku SŘ. Dalšími zapojenými systémy jsou LDAP pro správu uživatelů a oprávnění, oficiální webové stránky SÚKL včetně úřední desky pro publikaci informací o SŘ. Dokumenty jsou ukládány do síťové sdílené složky.
2.2 Obsah a rozsah stávajícího systému
Stávající systém obsahuje informace a podklady ke správním řízením vedeným od roku 2008.
Celkový počet uložených správních řízení ve stávajícím systému je přibližně 17 700 ks
za období od r. 2008 do ledna 2022
Obvyklý počet příloh (dokumentů) uložených u správního řízení je 10 až 150 ks
aplikace není limitována počty příloh ve SŘ
Odhad náročnosti na kapacitu všech dokumentů k jednomu SŘ včetně jejich jednotlivých verzí je
10 MB u jednoduchých SŘ, 250 MB u komplikovaných SŘ, v průměru cca 100 MB
aplikace není limitována ani typem řízení, ani počtem souborů, ani verzí dokumentů
Počet uživatelů ve stávající aplikaci je cca 55.
Aktuální počet předpřipravených šablon pro vytváření dokumentů ve Wordu je 32 (nástroj BIRT
Eclipse).
Účastníků SŘ jsou řádově desítky u jednoho SŘ, minimální počet je 8. Externích uživatelů nahlížejících na SŘ jsou řádově tisíce.
Jedna osoba obvykle pracuje na 30 – 40 případech (řízeních).
Počet výstupů na web a úřední desku je cca 20 – 30 (výjimečně možno i 100) písemností denně, v průběhu jednoho SŘ jde o desítky publikací, odkaz na úřední desku: xxxxx://xxx.xxxx.xx/xxxxxxx/xxxxxxxx/
3 SPECIFIKACE PŘEDMĚTU DODÁVKY
Předmětem plnění bude dodávka, instalace a provozování informačního systému pro evidenci, vedení
a zpracování správních řízení s větším počtem účastníků, která Objednatel vede:
- o stanovení /změně /zrušení maximální ceny a výše a podmínek úhrady LP/PZLÚ dle § 39g odst. 7 zákona č. 48/1997,
- o stanovení /změně výše a podmínek úhrady individuálně připravovaných léčivých přípravků (nejedná se o správní řízení, ale o proces dle části VI. správního řádu - ustanovení § 15 odst. 5 zákona o veřejném zdravotním pojištění) úhrady individuálně připravovaným léčivým přípravkům se stanovují opatřením obecné povahy, nikoliv správním řízením. Opatření obecné povahy pak upravuje část VI správního řádu (ustanovení § 171 až 174). S ohledem na tyto úpravy lze konstatovat, že procesní příprava opatření obecné povahy mívá jednodušší průběh, než jaký bývá u správního řízení),
- o přestupcích (nevede se dle ustanovení Zákon č. 500/2004 Sb., par. 144).
Předmět plnění bude zahrnovat:
• Vývoj, instalaci a implementaci informačního systému, včetně napojení všech konektorů, rozhraní a datových úložišť, zejména na databázi DLP, spisovou službu AthenA a další systémy Objednatele,
• napojení na systém JIP/XXXX, CMS a systém Základních registrů a případné budoucí napojení na informační systémy resortu Ministerstva zdravotnictví (NRPZS, NRZP apod.), soulad se směrnicí EIDAS a s národní strategií eHealth (po převzetí díla Objednatelem úpravy formou změnového požadavku),
• převedení (migrace) všech dat stávajícího systému vedení správních řízení do nového systému,
• vytvoření a provozování vývojového, testovacího a produkčního prostředí,
• zkušební provoz dodaného systému a ověření úplnosti a správnosti migrace dat,
• zaškolení uživatelů a administrátorů a poskytnutí školicí a uživatelské dokumentace,
• předání oprávnění (licenci) dodané aplikace pro Objednatele,
• předání zdrojových kódů včetně technické dokumentace, architektury systému a datového modelu systému,
• zajištění auditu bezpečnosti systému v rozsahu aktuálních požadavků legislativy a norem,
• zajištění údržby, podpory (včetně zapracování nově vzniklých požadavků na systém v návaznosti na legislativní změny a potřeby Objednatele) a provozování systému na dobu neurčitou včetně aktualizace veškeré dokumentace na základě samostatné smlouvy,
• úhradu všech licenčních poplatků za Objednatele po dobu 4 let včetně poplatků za licence produktů třetích stran, které budou součástí dodávky. Úhradu všech nákladů spojených s údržbou těchto licencí (maintenance). Do této kategorie nejsou zařazeny produkty, které jsou vyjmenovány v čl. 3.2.3.
Dále budeme v tomto dokumentu nazývat informační systém pro vedení správních řízení, který je předmětem této dodávky, zkratkou SŘDLP.
V této kapitole popisujeme obecné vlastnosti/funkcionality (funkční a nefunkční požadavky), které má nové SŘDLP zejména splňovat. Zejména jde o změnu koncepce stávající aplikace SŘDLP tak, aby více podporovala management („procesní řízení“) průběhu správních řízení (SŘ). Dosud řada činností referentů i jejich vedoucích pracovníků (manažerů), týkajících se SŘ, probíhala separátně mimo SŘDLP (formou e-mailů, sledovacích tabulek v Excelu apod.).
Hlavní očekávané cíle a přínosy nového systému SŘDLP:
- přehledný manažerský pohled na všechna SŘ (dashboard) a jejich stav, snadné filtrování,
- přehledné zobrazení a efektivní práce s dokumenty „svých“ SŘ pro interní uživatele,
- nahrazení e-mailové komunikace a předávání dokumentů mezi interními uživateli výhradně
funkcionalitami a notifikacemi v novém systému,
- ukládání, editace a sdílení dokumentů mezi uživateli přímo v SŘDLP, verzování dokumentů,
- automatické ukládání dat z webových formulářů do systému,
- možnost poskytnutí údajů ze SŘDLP pro předvyplňování webových formulářů,
- zahrnutí činností a evidence informací nyní vedených mimo stávající systém SŘDLP,
- schvalování a podepisování písemností přímo v SŘDLP,
- evidence údajů o cenách a úhradách přímo v SŘDLP,
- umožnění generování pravidelných výstupů (zejména Seznamu cen a úhrad LP/PZLÚ),
- přímý přístup do SŘDLP pro externí uživatele a zpřístupnění definovaných dokumentů.
3.1.1 Uživatelské požadavky na vedení správních řízení (SŘ):
V SŘDLP by mělo probíhat veškeré zpracování SŘ, evidence podkladů a průběhu SŘ, příprava dokumentů dle šablon a parametrů konkrétního SŘ, jejich postupné zpracování (posuzování, ověřování a doplňování), manažerská kontrola a sledování průběhu jednotlivých SŘ v rámci agend vybraných útvarů SÚKL.
Jedná se o níže uvedené konkretizované funkce.
Současně platí, že průběh vyřizování SŘ a procesy, které bude zapotřebí sledovat, budou detailně specifikovány v rámci Etapy 1 (analýza a vytvoření prováděcího projektu).
Procesní řízení SŘ
• Grafická definice procesu (workflow), využití standardů Business Process Model and Notation (BPMN),
• vizualizace průběhu konkrétního řízení (zjednodušená časová osa) a zaznamenávání jednotlivých nadefinovaných etap SŘ („kontrolní body“ či „milníky“) včetně hlídání souvisejících nastavených lhůt interních či zákonných (kontrolním bodem se rozumí úkon, který je nutno vykonat/splnit),
• termíny, milníky, kontrolní body, etapy a stavy SŘ může nastavovat a měnit oprávněný uživatel kdykoliv v jeho průběhu, jednotlivá řízení budou interním uživatelům přiřazována ručně,
• v rámci hlídání termínů/lhůt zavedení notifikací (pro referenty i jejich nadřízené) v případě blížícího se konce lhůty (termín, kontrolní bod) resp. jejího promeškání/překročení,
• notifikace a upozornění primárně v rámci aplikace (zvýraznění na nástěnce), důrazné upozornění (varování) e-mailem uživateli i nadřízenému, s přímou vazbou na konkrétní SŘ, úkol a termín,
• integrace agend a procesů, které jsou nyní řešeny mimo aplikaci (e-mailové zadávání úkolů či e-mailové přeposílání písemností ke kontrole nebo revizi apod.), proto by v SŘDLP mělo probíhat veškeré zpracování SŘ, evidence podkladů a průběhu SŘ, příprava dokumentů dle šablon a parametrů konkrétního SŘ, jejich postupné zpracování (posuzování, ověřování a doplňování), manažerská kontrola a sledování průběhu jednotlivých SŘ v rámci agend vybraných útvarů SÚKL,
• předávání písemnosti mezi pracovníky (referenty) a schvalování písemnosti přímo v aplikaci,
na SŘ spolupracuje více pracovníků různých oddělení,
• schvalováním se rozumí, aby systém SŘDLP podporoval prosté odsouhlasení dané verze dokumentu všemi osobami, které v dané fázi mají dokument odsouhlasit (obvykle se jedná o dvoustupňové odsouhlasení – hodnotitelský tým (cca 1 až 5 osob) a kontrola (cca 1 až 5 osob)),
• individuální uživatelské nástěnky s přidělenými SŘ, úkoly s možností přechodu přímo k řešení úkolů,
• možnost doplnění poznámek či nastavení upozornění uživatelem či nadřízenými,
• přesné a detailní logování veškerých činností a úkonů uživatelů (např. evidence zpracování dokumentu, předání dokumentu jinému pracovníkovi, kontroly či schválení dokumentu od nadřízeného).
K upřesnění počtu a rozsahu procesů dojde v rámci Etapy 1. V tabulce níže je uveden výčet procesů, které Objednatel v dané oblasti vede. Je nutné na tomto místě upozornit, že pro mnohá řízení platí, že je jejich průběh (tj. sled možných kroků) stejný nebo podobný, liší se zejména lhůty pro vydání rozhodnutí. Z pohledu Objednatele bude tedy záležet na navrženém řešení (tj. zda bude nutné definovat 1 workflow pro 1 typ správního řízení, nebo zda bude možné využít 1 společný workflow pro „rodinu“ správních řízení, pro která platí stejná pravidla, a zohlednit v něm specifické lhůty).
Proces | Způsob zahájení a vedení | |
Z moci úřední | Na žádost | |
Hloubkové revize VaPÚ | X | |
Zkrácené revize MC | X | |
Zkrácené revize VaPÚ (např. úsporové, po vstupu 1. podobného LP) | X | X |
Stanovení MC+VaPÚ | X | X |
Řízení o ověření statutu VILP | X | |
Stanovení MC+VaPÚ (léčivý přípravek pro vzácné onemocnění) | X | |
Přehodnocení léčivého přípravku pro vzácné onemocnění | X | X |
Ověření statusu VILP, zrušení úhrady VILP | X | |
Stanovení/změna MC | X | X |
Stanovení/změna VaPÚ | X | X |
Zrušení MC/VaPÚ | X | X |
Stanovení MC/VaPÚ přes podobné přípravky | X | |
Přepis MC/VaPÚ | X | X |
Přestupková řízení | X | |
Opatření obecné povahy | X |
Stávající přehled typů správních řízení tak, jak je nastaven v současném systému, je uveden
v následující tabulce:
TYP_RIZENI | TYP_RIZENI | TYP_RIZENI | ||
0-Revize-VAPÚ | 5-Revize-VAPÚ | VAPÚ+MC | ||
0-Revize-VAPÚ-vráceno z MZ | 5-Revize-VAPÚ-zkrácené řízení | VAPÚ+MC (old) | ||
1-Revize-MC | MC(old) | VaPÚ+MC-hodnocení VILP-ex-offo | ||
1-Revize-VAPÚ | MC-ex offo | VAPÚ+MC–přehodnocení – LPVO §39da ex offo | ||
1-Revize-VAPÚ zkrácené řízení-vráceno z MZ | MC-stanovení | VAPÚ+MC-přehodnocení–LPVO §39da | ||
1-Revize-VAPÚ-vráceno z MZ | MC-výjimky | VAPÚ+MC-stanovení–LPVO §39da | ||
1-Revize-VAPÚ-zkrácené řízení | MC-změna | VAPÚ+MC-vráceno z MZ | ||
2-Revize-MC | MC-změna-vráceno z MZ | VAPÚ+MC-zrušení-ex offo | ||
2-Revize-VAPÚ | MC-zrušení | VAPÚ+MC-zrušení-ex-offo (old) | ||
2-Revize-VAPÚ zkrácené řízení-vráceno z MZ | MC-zrušení (old) | VAPÚ-ex-offo | ||
2-Revize-VAPÚ-vráceno z MZ | MC-zrušení-ex offo | VAPÚ-ex-offo (old) | ||
2-Revize-VAPÚ-zkrácené řízení | MC-zrušení-ex offo (old) | VaPÚ-hodnocení VILP-ex-offo | ||
3-Revize-MC | PP-snížení-MC-zkrácené řízení | VAPÚ–přehodnocení – LPVO §39da ex offo | ||
3-Revize-MC-vráceno z MZ | PP-stanovení-MC | VAPÚ–přehodnocení–LPVO §39da | ||
3-Revize-VAPÚ | PP-stanovení-VAPÚ | VAPÚ-stanovení-LPVO §39da | ||
3-Revize-VAPÚ-vráceno z MZ | PP-stanovení-VAPÚ-MC | VAPÚ-vráceno z MZ | ||
3-Revize-VAPÚ-zkrácené řízení | PP-stanovení-VAPÚ-MC-vráceno z MZ | VAPÚ-zrušení | ||
3-Revize-VAPÚ-zkrácené řízení-vráceno z MZ | PP-stanovení-VAPÚ-vráceno z MZ | VAPÚ-zrušení (old) | ||
4-Revize-MC | VAPÚ | VAPÚ-zrušení-ex offo | ||
4-Revize-VAPÚ | VAPÚ (old) | VAPÚ-zrušení-ex offo (old) | ||
4-Revize-VAPÚ-vráceno z MZ | VaPÚ+ MC-ex-offo | Zrušení-nemocniční--ex-offo | ||
4-Revize-VAPÚ-zkrácené řízení | VAPÚ+ MC-zrušení | Zrušení-podpůrné--ex-offo | ||
5-Revize-MC-zkrácené řízení | VAPÚ+ MC-zrušení (old) | |||
K náročnosti jednotlivých procesů Objednatel odkazuje na kapitolu 3.1.1 Přílohy č. 1, kde je podrobně rozepsán jeden z procesů. Dále Objednatel odkazuje na standardní postupy, které jsou veřejně dostupné na internetových stránkách SÚKL pod odkazem: xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx- stanoveni-cen-a-uhrad.
Některé typy správních řízení jsou svým průběhem (časová linka, procesní úkony) stejné a název typu tak slouží spíše pro potřebu evidence. Některé se liší ze své podstaty (na žádost vs. z moci úřední) nebo s ohledem na zákonnou úpravu, např. délka lhůt. Jako příklad lze uvést zkrácenou revizi VaPÚ, která může být dle § 39p zákona o veřejném zdravotním pojištění zahájena na žádost nebo z moci úřední a má specifickou délku pro vydání rozhodnutí.
Samotný průběh konkrétního správního řízení se může od jiného správního řízení stejného typu lišit v rámci zákonných kritérií (např. opakované vydání hodnotící zprávy, nebo vydání výzvy k součinnosti v některých případech).
Konkrétně pak zejména:
metodika | název | účinnost od |
Postup vyřizování žádosti o stanovení/ změnu maximální ceny a/nebo výše a podmínek úhrady léčivého přípravku / potraviny pro zvláštní lékařské účely | 17. 12. 2021 | |
Průběh správního řízení v rámci pravidelné revize systému maximálních cen | 22. 6. 2015 | |
Postup zrušení výše a podmínek úhrady a maximální ceny/výše a podmínek úhrady léčivého přípravku/potraviny pro zvláštní lékařské účely ex offo | 26. 1. 2018 | |
Postup vyřizování žádosti o zrušení maximální ceny a/nebo výše a podmínek úhrady léčivého přípravku / potraviny pro zvláštní lékařské účely | 27. 11. 2020 | |
Průběh správního řízení v rámci pravidelné revize systému úhrad ve věci změny výše a podmínek úhrady léčivých přípravků hrazených z prostředků veřejného zdravotního pojištění | 2. 1. 2019 | |
Průběh správního řízení v rámci zkrácené revize systému úhrad ve věci změny výše a podmínek úhrady léčivých přípravků hrazených z prostředků veřejného zdravotního pojištění | 16. 4. 2018 |
zdroj: xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx-xxxxxxxxx-xxx-x-xxxxx
SRDLP bude obsahovat aplikační podporu nejen pro Správní řízení v prvním stupni dle Správního řádu (Zákon č. 500/2004 Sb, § 44 - § 76), ale také pro instituty / typy správních řízení:
a) Nicotnost rozhodnutí (Zákon č. 500/2004 Sb., §77) ,
b) Náklady řízení (Zákon č. 500/2004 Sb., §79),
c.) Ochrana před nečinností (Zákon č. 500/2004 Sb., § 80),
d) Odvolací řízení (Zákon č. 500/2004 Sb., § 81 - § 93),
e) Přezkumné řízení (Zákon č. 500/2004 Sb., § 94 - § 99),
f) Obnova řízení a nové rozhodnutí (Zákon č. 500/2004 Sb., § 100 - § 102).
Nemusí se však jednat o komplexní úpravu jako pro správní řízení na prvním stupni, ale mělo by být zřejmé, že k takovému úkonu došlo či bylo takové řízení zahájeno, a bylo to možné přiřadit ke konkrétnímu řízení v prvním stupni. Rovněž by mělo SŘDLP evidovat možné úkony pro přezkumné řízení a obnovu řízení, tzn. aby v případě zahájení takového řízení mohl Objednatel s využitím SŘDLP zejména evidovat a podepisovat dokumenty. Procesní mapa jako u standardních řízení nutná není. Uživatel SŘDLP by měl mít po otevření konkrétního správního řízení možnost vidět, zda je s tímto řízením, respektive v něm vydaným rozhodnutím, spojen některý z institutů uvedených v bodech
a) až f) předchozího odstavce.
Informace o průběhu správních řízení jsou dostupné na adrese xxxxx://xxx.xxxx.xx/xxxx/xxxxxxxxx-x- prubehu-spravnich-rizeni.
Související Manažerské nástroje k řízení SŘ
Požadavky na řešení přehledné nástěnky (dashboardu) pro roli manažer
Manažer a stejně tak i pracovníci sekce používají samostatnou obrazovku monitoru na notebooku při práci mimo kancelář nebo dva monitory v kanceláři, kde mohou současně pracovat s více dokumenty
a databázemi v samostatných oknech. Dashboard určený pro interní uživatele Objednatele by tak měl být přehledný jak v zobrazení maximalizovaného okna nástěnky přes celou obrazovku („fullscreen“) na jednom menším displeji notebooku s případným vertikálním rozdělením okna pro zobrazení rozdílných informací (detailů), tak i pro zobrazení více oken s rozdílným obsahem současně na dvou monitorech. Detaily řízení by měly být snadno dostupné a mělo by být možné pracovat souběžně s nástěnkou i vícero „kartami“ či záložkami detailů správních řízení v jednotlivých oknech nebo mezi nimi snadno přecházet. Okna (záložky) by mělo být možné „vytáhnout“ mimo domovské okno, aby mohlo být zobrazeno na druhém z monitorů.
Manažer musí mít snadno dostupné souhrnné informace v podobě KPIs (viz níže) a podrobné informace o vybraném správním řízení, včetně pracovníků, kterým bylo řízení přiděleno, znázornění průběhu a plnění milníků řízení, datumů a názvů vydaných dokumentů, poznámek apod. Manažer musí mít jednoduše dostupné informace o jednotlivých přidělených SŘ konkrétnímu pracovníkovi.
Správní řízení jsou zahajována z moci úřední nebo na žádost. Na SÚKL jsou pak tato řízení vedena (koordinována) podle svého předmětu a obsahu, buďto na oddělení VTS nebo KSŘ. Jedno SŘ může zahrnovat více léčivých přípravků. Z povahy správního řízení je možné, že u některých kódů LP se bude stav řízení lišit, např. bylo-li rozhodnuto v části rozhodnutí nebo bylo-li pro některé kódy správní řízení zastaveno. Využití náhledů na obsah souborů Objednatel nepožaduje a předpokládá otevření dokumentu ve výchozím programu.
Oddělení VTS svá řízení vede po procesní i odborné stránce. Oddělení KSŘ vede odborně komplexnější správní řízení, na kterých spolupracují další oddělení, zejména oddělení OHL a FEA.
Manažerem se rozumí pracovník, který je nadřízený oběma vedoucím oddělení VTS a KSŘ.
Manažer nástěnku využívá pro manažerskou kontrolu při plnění lhůt (milníků) a napomáhá vedoucím při určování priorit v případě souběhu vysokého počtu řízení. Prioritou je myšlena důležitost jednotlivého správního řízení, kterou může manažer určit, ale pravidla pro prioritizaci nelze v tuto chvíli stanovit. V případě role Manažera se jedná o jednu osobu, případně zástupce této osoby. Způsob a intenzita práce využívání Dashboardu manažerem bude záviset zejména na stavu a průběhu jednotlivých SŘ a proto není možné činnosti manažera detailněji specifikovat nebo kategorizovat v čase. Má mít k dispozici:
- přehled hlavních KPIs, které zahrnují následující přehledy:
o souhrnně pro všechna probíhající řízení:
A) počet probíhajících řízení,
B) počet probíhajících řízení, která vyhovují časovému plánu (vč. dílčích milníků),
C) počet probíhajících řízení, která sice vyhovují celkovému časovému plánu (termín pro vydání rozhodnutí ještě neuplynul), avšak v dílčích milnících již časový harmonogram nebyl splněn a lze proto předpokládat, že bez zásahu (prioritního řešení) nebude splněn ani termín pro vydání rozhodnutí,
D) počet probíhajících řízení, která jsou již po termínu v celkovém čase,
E) plánovaná (teoretická) efektivita vs. skutečná efektivita, efektivita se počítá jako poměr (procento) Průběžné doby plánované a Průběžné doby skutečné (čas průběhu správního řízení od jeho počátku),
F) důvody prostojů (např. ve sloupcovém grafu), hlavní důvod vybírá zaměstnanec nebo manažer z nabídky přibližně sedmi položek číselníku důvodů prostojů a předpokládá se, že v daném okamžiku by byl „aktivní“ pouze jeden, který aktuálně
způsobil zpoždění, v případě změny důvodu (např. v další etapě) by se původní zaznamenal do historie a „aktivním“ pro zahrnutí do přehledu by se stal důvod nový,
o výše uvedená písmena souhrnně pro každý typ (každou “rodinu” ) probíhajících řízení i souhrnně za všechna probíhající správní řízení s jednoduchou volbou zahrnutých typů SŘ do přehledu.
- přehled správních řízení, ze kterého budou po grafické a obsahové stránce snadno identifikovatelné základní údaje o správním řízení (léčivý přípravek, datum zahájení, den běhu řízení), o pracovnících, kteří na daném řízení pracují (např. formou iniciál), etapy (stavu) řízení, atp. ,
- Seznam stavů se může s ohledem na průběh řízení podle zákona o veřejném zdravotním pojištění (ZoVZP) mezi typy správních řízení lišit. Předmětem první fáze realizace by tedy mohlo také být vyhodnocení, zda využít jeden seznam pro všechny typy řízení s tím, že se všechny stavy nemusí u daného typu využít, nebo zda pro odlišné typy SŘ definovat specifické stavy. Příklady typů SŘ s odlišnými stavy mohou být správní řízení dle § 39g odst. 9 ZoVZP (tzv. fikce správního rozhodnutí), nebo SŘ dle § 39da ZoVZP,
- po rozkliknutí detailu konkrétního správního řízení má vidět podrobnější údaje o léčivém přípravku (kromě názvu, např. SUKL kód, zařazení do referenční skupiny, přidělené zaměstnance (1 až 3 osoby), podrobný průběh daného řízení (tj. budou zobrazeny chronologicky odkazy na příslušné dokumenty, které již byly ve správním řízení vydány a příslušné etapy),
- snadno dostupné je také zobrazení již dokončených správní řízení, resp. všech správních řízeních s možností filtrovat mezi nimi.
Předpokládáme, že se po zastavení kurzoru nad nějakou částí (objektem) dashboardu nebo po kliknutí na daný KPI ukazatel manažerovi zobrazí podrobnější přehled s danou skupinou správních řízení (např. podrobnější přehled s těmito řízeními se zobrazí v případě, že manažer najede myší na počet probíhajících řízení, která nevyhovují časovému plánu). Manažer by tedy měl mít také přehled o všech správních řízeních, možnost využít řazení ve sloupcích nebo nastavit filtry, např.:
- pro zobrazení řízení v požadované fázi (např. před vydáním hodnotící zprávy, před rozhodnutím, s vydanou výzvou k součinnosti),
- pro zobrazení řízení, u kterých se blíží některý z výše uvedených termínů,
- pro zobrazení řízení, u kterých je překročen některý z výše uvedených termínů,
- pro zobrazení řízení přidělených konkrétnímu oddělení, pracovníkovi apod.
Řízení, která se blíží k termínu a zatím není splněn příslušný úkon, nebo řízení, která jsou již po splnění uvedeného termínu, by měla být v přehledu jednotlivých řízení na první pohled odlišitelná.
Podrobná analýza průběhu jednotlivých typů řízení a možných stavů se předpokládá v rámci Etapy 1 plnění této veřejné zakázky. Pro ilustraci uvádíme stěžejní milníky některých typů řízení vedených na oddělení KSŘ, kdy jsou milníky následující (viz také dále procesní schéma). Po zahájení řízení na žádost probíhá krátká validační fáze (cca 2-3 dny), během níž je zkontrolována úplnost žádosti a splnění minimálních požadavků na předložení dokumentace a uhrazení správního poplatku. Následuje předání spisu na oddělení KSŘ a přidělení hodnotitele OHL (viz schémata níže) – milník 10. den. Během řízení jsou dalšími hlavními milníky kalendářní dny běhu správního řízení: den 60 („strategická schůzka“), den 75 („vydání výzvy k součinnosti“), den 120 („vydání hodnotící zprávy“) a den 165 („vydání rozhodnutí“). Milníky jsou nastaveny předem automaticky, nicméně dané úkony je možné realizovat dříve (dřívější
splnění) i později (překročení lhůty). Řízení může být v průběhu přerušeno na určitou dobu, během níž se nepočítají lhůty.
Správní řízení lze označit za dokončené v čase „vydání rozhodnutí“ – milník 165. den, kdy je vyvěšeno na úřední desce.
Manažer sleduje průběh a stavy až jednoho tisíce běžících správních řízení. Počet souběžně řešených správních řízení jednoho koordinátora (VTS nebo KSŘ) se standardně pohybuje v řádu desítek. Celkem jsou ročně vedeny stovky správních řízení (počty se mohou pohybovat až kolem 1500 za rok). Pro představu o počtu a struktuře řešených správních řízení je možné využít přehled reálně vedených správních řízení z roku 2020 a části roku 2021 v anonymizované podobě, který tvoří přílohu č. 5 „SŘDLP
– Přehled správních řízení.xlsx“ této zadávací dokumentace. Tento přehled může dodavatel rovněž využít jako datový podklad pro vytvoření požadované vizuální prezentace navrhovaného řešení. Soubor obsahuje tyto sloupce s fiktivními hodnotami založenými na skutečných datech:
- rok zahájení správního řízení,
- fiktivní spisovou značku,
- fiktivní název léčivého přípravku (soubor může obsahovat více správních řízení s jedním léčivým přípravkem),
- typ správního řízení,
- oddělení, kterému bylo řízení přiděleno,
- koordinátor oddělení VTS nebo KSŘ (jedna osoba) (soubor může obsahovat více správních řízení přidělených jedné osobě),
- hodnotitel 1 a hodnotitel 2 spolupracujících oddělení OHL a FEA (soubor může obsahovat více správních řízení přidělených jedné osobě), přitom není striktní provázanost mezi jmény koordinátora a hodnotitelů.
Následující schémata zobrazují proces zpracování správních řízení:
Zjednodušené schéma správního řízení vedeného na oddělení KSŘ, jak bylo popsáno výše
Vydání
rozhodnutí
Příprava rozhodnutí
Zahájení SŘ
Předání spisu na KSŘ a přidělení hodnotitele OHL
Postup dle schématu uvedeného níže. Schéma se může opakovat v případě, že je třeba vydat novou hodnotící zprávu.
Procesní schéma přípravy hodnotící zprávy (odpovídá prostřednímu obdélníku zjednodušeného schématu viz výše)
Výše uvedený popis průběhu typu správního řízení a schéma jednotlivých etap platí pro výše uvedený typ správního řízení a nemusí být shodný s průběhy jiných typů správních řízení. Některé jiné typy správních řízení mají odlišný průběh, jiné požadavky na součinnost a rozsah zapojených útvarů, a také jiný počet fází i jiné množství a termíny jednotlivých milníků. Splněné úkoly lze chápat jako události, které automaticky inicializují přechod SŘ do další definované fáze SŘ, v rámci přípravy hodnotící zprávy
se jedná o přesun úkolů na další oddělení. Pořadí oddělení pracujících na hodnotící zprávě však není fixní ani chronologický.
Doplňující podrobnosti k uživatelským požadavkům
(pozn. specifikaci detailů, zejména prostředí koncových uživatelů, Objednatel předpokládá v rámci
Etapy 1)
• Možnost přidělení úkolu v rámci konkrétního SŘ podřízenému, možnost změny prioritizace zadaného úkolu, řešení situací jako zástup pracovníků či rozdělení jednoho úkolu více pracovníkům,
• plocha pro rychlý přehled přidělených úkolů/SŘ jednotlivých uživatelů – obdoba manažerského dashboardu s odlišným výchozím nastavením zobrazených přidělených SŘ pro konkrétního pracovníka,
• možnost uživatele utvořit vazby mezi různými SŘ dle definovaných kritérií (např. dle předmětu, tj. dotčených léčiv nebo účastníků apod.) a umožnit tak snadný přístup „proklik“ pro uživatele k minulým či běžícím souvisejícím SŘ (a v nich obsaženým dokumentům),
• možnost uživatele ke každému SŘ přidávat strukturované poznámky, např. informace o jiných probíhajících řízeních vedených mimo SÚKL. Jedná se např. o řízení odvolací na ministerstvu či řízení soudní, která na konkrétní SŘ navazuje či s ním souvisí,
• umožnit tvorbu nových číselníků v SŘDLP, např. typy správních řízení (lišící se dle předmětu a způsobu vedení dle zákona o veřejném zdravotním pojištění), spojování přípravků do referenčních skupin (které jsou pak předmětem společných SŘ s více přípravky), vazba přípravků na odbornosti (specializace) lékařů,
• vytvořit evidenci předkladatelů, dovozců, tuzemských výrobců, navrhovatelů specifických léčebných programů a jejich vazeb na LP, vazba na dokument o schválení ze strany MZ ČR, apod.,
• evidovat a upozorňovat na změny v systému DLP v registraci LP zpracovávaných v běžících SŘ (změna/ukončení registrace, změna držitele, zmocněnce atd.), provést kontrolu na pokyn v průběhu SŘ,
• aktuálnost dat o subjektech (účastnících řízení) ověřovat v Základních registrech (ZR), aby informace o nich byla při vydání rozhodnutí nebo při některých úkonech aktuální a platná, na základě notifikací ze ZR upozorňovat na změny a historii těchto změn ukládat,
• ve stávajícím systému nejsou žádné subjekty automaticky ověřovány vůči ZR,
• identifikace zahraničních subjektů je ověřována pouze porovnáním údajů uvedených daným subjektem ve formuláři žádosti vůči údajům evidovaným v systémech DLP (SŘDLP) nebo údajům v zahraničních obchodních rejstřících – tento postup bude v novém systému SŘDLP zachován obdobným způsobem do doby nasazení CESub (viz dále)
• v rámci migrace dat Objednatel požaduje ztotožnění subjektů vůči Základním registrům,
• možnost pružně zareagovat na změnu legislativy celkovou úpravou procesu (workflow), např. při legislativní změně lhůt, či přidání nového procesu (nového typu správního řízení) a šablon pro dokumenty (uživatelsky případně Zhotovitelem na základě požadavku na změnu),
• možnost některých uživatelů (dle přiřazených práv) ad hoc modifikovat i konkrétní proces SŘ (workflow) ve smyslu časové osy, když se SŘ svým průběhem např. dostane mimo standardní workflow, např. obvyklé (definované) zákonné lhůty, SŘ je dlouho přerušeno apod.,
• možnost kontroly předmětů řízení (přípravků) a účastníků (či jejich zmocněnců) SŘ před vypravením každého dokumentu (písemnosti), tedy ověřovat aktuální stav registrace daného LP v DLP a přiřazení do referenčních skupin, aktuální stav účastníků a zmocněnců v ROB, ROS, evidovat historii změn,
• respektovat verze formulářů (šablon) ke konkrétnímu datu při jejich změně a platnosti od konkrétního data (změna legislativy – nové SŘ s novou verzí, uživatelská změna),
• využívat pro SŘ data z existujících webových formulářů a přílohy k podání pomocí webových služeb ze spisové služby AthenA, získaná data ukládat do SŘDLP (odkaz na stávající formuláře pro představu o struktuře a rozsahu těchto dat a pokyny pro jejich použití: xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxxx-xxx-xxxxxx-xxxxxxx),
• webové formuláře budou řešeny (případně upraveny pro nové řešení) ve stávajícím formulářovém řešení webu SÚKL; editaci formulářů a jejich podporu zajišťuje Objednatel, nový systém SŘDLP bude data přebírat ze spisové služby případně z databáze,
• vytvořit nový samostatný modul pro PZLÚ se strukturovanými údaji využívaných v SŘ CAU (doplnění současné evidence v DLP o další informace, evidence údajů o dovozci, parametry a složení), kdy je k PZLÚ narozdíl od LP vedených v DLP potřeba vést další specifické parametry a informace ve strukturované podobě v novém SŘDLP a umožnit tak internímu uživateli uložení těchto informací a jejich správu,
• nově zahrnout do SŘDLP vedení připomínkových řízení Opatření obecné povahy (OOP) (xxxxx://xxx.xxxx.xx/xxxx/xxxxxxxx-xxxxxx-xxxxxx), včetně návrhů OOP (xxxxx://xxx.xxxx.xx/xxxx/xxxxxx-xxxxxxxxx-xxxx-x-xxxxxxxxxxxxxx), včetně publikace na úřední desce,
• kroky před publikací by měly proběhnout co možná nejvíce automatizovaně bez nutnosti posílat informační e-maily o předání/popisu dokumentu aj., nicméně finální odeslání k publikaci by mělo být ruční. Nejedná se tedy o plně automatizované zveřejňování, ale se znázorněním stavu a jaké kroky ještě zbývají. Číslo jednací přidělí spisová služba AthenA před odesláním dokumentu k podpisu, po vložení č.j. a podepsání již nelze do podepsaného PDF souboru zasahovat.
Práce s dokumenty
• Tvorba právních a odborných dokumentů s využitím připravených formulářů (šablon) ve výsledném formátu DOCX (formát Word editovatelný v Office 365), s následným převodem do PDF (komponenta pro převod do aktuální verze PDF/A pro archivaci bude součástí dodávaného řešení) a elektronickým podepsáním v SŘDLP a vyznačením data nabytí právní moci,
• dokumenty by měly být primárně uloženy v SŘDLP (nicméně stáhnutelné na disk pro případ offline práce apod.) a editovatelné v MS Office,
• obsah a rozsah sestavených dokumentů pro konkrétní SŘ je variabilní a bude se generovat na základě zvolených parametrů, např. typu správního řízení, účelu dokumentu, fáze SŘ, předmětu řízení atd.,
• při sestavování dokumentu pomocí šablon budou do dokumentu automaticky načteny aktuální informace z metadat správního řízení a z databáze DLP (účastníci řízení, držitel rozhodnutí o registraci, zmocněnci, stav registrace, referenční skupina, LP/PZLÚ, léčivé látky, typ SŘ, sp. zn., kontakt na vyřizující osobu a další údaje a hodnoty z číselníků vedených v SŘDLP),
• tvorba / vyplňování formulářů (validační protokoly, kde se prochází seznam otázek a zaškrtává
„splněno“ / „nesplněno“ / aj.) na základě předem připravených šablon,
• import podkladů a příloh k SŘ a do dokumentů je obvykle ve formátech DOCX, XLSX, TXT, PDF, JPG, XML apod.,
• integrace s MS Office 365 na stanicích uživatelů pro přímou editaci dokumentů v editorech (po sestavení dokumentu dle šablony uložení dokumentu ve formátu DOCX a editace v MS Office 365), rozpracované i finální dokumenty jsou sdíleny mezi uživateli a zpřístupněny přes SŘDLP,
• možnost převodu obrazové dokumentace na text (konkrétně naskenované údaje z etiket PZLÚ uložené v databázi Objednatele DLP (Oracle, uloženo jako PDF, pole typu Blob, dostupné formou pohledů, příklady etiket jsou v přílohách č. 6-8 zadávací dokumentace), nutno převést do textové podoby a uložit v SŘDLP a umožnit další zpracování tohoto textu v české jazykové sadě), nástroj pro převod bude součástí dodávaného řešení,
• Objednatel s ohledem na velkou variabilitu grafických podob a rozsahů informací na etiketách předpokládá, že uživatel vyznačí myší oblast na etiketě a po převodu na text jej vloží do příslušného pole systému SŘDLP jako text nebo hodnotu konkrétního parametru přípravku (např. energetická hodnota, obsah tuku, obsah cukru). Objednatel dále předpokládá, že bude s převedeným textem pracovat také ve formátu .docx. Ukázky etiket jsou přílohou zadávací dokumentace. Zadavatel bude převádět primárně české texty a dále parametry a složení přípravku.
• pro převod grafických podkladů (etiket) na text bude postačovat jedna plovoucí licence, pokud bude tato licence potřeba; funkcionalitu převodu na text bude využívat v jeden okamžik nanejvýš jeden interní uživatel Objednatele.
• možnost přesouvat/mazat/kopírovat více dokumentů nebo složek zároveň mezi jednotlivými SŘ v rámci nového systému SŘDLP,
• umožnit označení dokumentů parametrem pro další třídění nebo zpracování (například typ dokumentu, dokument obsahuje obchodní tajemství, osobní údaje apod.),
• dokumenty přístupné veřejnosti, které jsou označené parametrem „obchodní tajemství“ –
inkriminované části dokumentu nejsou čitelné (začerněné),
• dokumenty označené parametrem „předmět obchodního tajemství“ jsou dostupné a čitelné pouze pro zaměstnance CAU, účastníkům jsou dostupné pouze po schválení předchozí žádosti při osobním fyzickém nahlížení do spisu v prostorách Ústavu,
• případnou anonymizaci dokumentů (podkladů k SŘ) zajišťuje Objednatel,
• s jedním dokumentem pracuje (edituje ho) v jeden okamžik pouze jeden uživatel (exklusivní přístup),
• opatření finálního schváleného dokumentu ve formátu PDF uznávaným elektronickým
podpisem.
Požadavky na vedení informací o cenách a podmínkách úhrady
• Součástí SŘDLP bude vedení informací o stanovených cenách a podmínkách úhrady LP/PZLÚ (tzn. výsledky rozhodnutí SŘ), včetně historie,
• migrace dat a údaje z předchozích rozhodnutí o cenách a podmínkách úhrady budou součástí nového SŘDLP včetně celé historie,
• SŘDLP bude zajišťovat generování požadovaných výstupů,
• přehled stávajících zveřejňovaných výstupů:
xxxxx://xxx.xxxx.xx/xxxx/xxxxxxxx-xxx-x-xxxxx-xxxxx.
Požadavky na statistiky a výstupy
• Zpracování předdefinovaných statistik a přehledů ze SŘDLP dle předem stanovených pravidel
a kritérií,
• periodicky nebo na vyžádání generovat a publikovat výstupy dle předem stanovených pravidel,
• u služeb poskytovaných mimo úřad zajistí Zhotovitel publikaci a podporu služeb prostřednictvím CMS, CMS (Centrální místo služeb) je součást Komunikační infrastruktury veřejné správy a jako takové není předmětem plnění této VZ, ale Objednatel uvádí toto
rozhraní s ohledem na požadavky Útvaru hlavního architekta Ministerstva vnitra na využívání CMS pro řízené a evidované propojení informačních systémů subjektů státní správy a má souvislost i s přístupem k Základním registrům a systému JIP/XXXX (informace jsou dostupné na webu Ministerstva vnitra), Integrace AD/LDAP s JIP/XXXX pro interní uživatele (úředníky) není součástí tohoto projektu,
• možnost generovat grafické a tabulkové výstupy (exporty) do Věstníku, Výročních zpráv SÚKL a měsíčně vydávaného seznamu cen a úhrad LP/PZLÚ dle předem definovaných pravidel a s možností volby některých parametrů; výstupy v podobě tabulek nebo grafů na obrazovku nebo do souboru (JPG, BMP, XLSX, DOCX), nebo datového výstupu (TXT, CSV, XLSX). Příklady výstupů uvádíme níže. Je třeba zdůraznit, že se jedná pouze o příklady, nikoliv vyčerpávající ani jinak závazný přehled, neboť nelze vyloučit, že by se publikované výstupy nemohly změnit, což bude předmětem analýzy během Etapy 1.
o Věstník (1x měsíčně), cen a úhrad se týká informace na straně 23: xxxxx://xxx.xxxx.xx/xxxx/xxxxxxx-xxxx-00- 2019?highlightWords=v%C4%9Bstn%C3%ADk+2019.
o Výroční zpráva (1x ročně), cen a úhrad se týká informace od strany 33: xxxxx://xxx.xxxx.xx/xxxx/xxxxxxx-xxxxxx-xxxx-0000- 1?highlightWords=v%C3%BDro%C4%8Dn%C3%AD+zpr%C3%A1va+2018.
o Přehledy cen a úhrad léčiv (obvykle 1x měsíčně, někdy častěji):
xxxxx://xxx.xxxx.xx/xxxxxxxx-xxx-x-xxxxx-xxxxx.
o Databáze léků (jednou týdně), záložka Ceny a úhrady: např. LP Avastin:
xxxxx://xxx.xxxx.xx/xxxxxxx/xxxxxxxxxx/xxxxxx.xxx?xxxxx0000000&xxxxxxxxxx.
o Přehled správních řízení (online vyhledávací formulář, xls, txt):
xxxxx://xxx.xxxx.xx/xxxx/xxxxxxx-xxxxxxxxx-xxxxxx.
Další generované přehledy ze stávajícího systému SŘDLP a jejich rozsah
Níže Objednatel uvádí odhad objemu dat, který bude pravděpodobně nutné „namapovat“ při migraci dat. Je třeba mít na paměti, že nejde o vyčerpávající seznam, nicméně by měly být obsaženy hlavní informace. Dalším podkladem pro odhad rozsahu stávajícího systému je příloha č. 10 této ZD.
Název generovaného přehledu | Typ přehledu | Počet řádků | Počet sloupců |
SŘ (správní řízení) | proměnná v čase | 18 141 | 55 |
Předmět ve SŘ (zda v SŘ jde o maximální cenu, úhradu, atp.) | číselník | 8 | |
LP (léčivé přípravky) – zdrojem je systém DLP | proměnná v čase | 91 502 | 53 |
Bratrské kódy – zdrojem je systém DLP | proměnná v čase | 8 582 | 59 |
Referenční skupiny a léčivé látky | číselník | 2 265 | 12 |
Typy řízení (viz upozornění dále – nejde vždy v pravém smyslu slova o odlišné typy) | číselník | 68 | 12 |
Osoby (účastníci řízení, zaměstnanci, aj.) | proměnná v čase | 1 500 | 19 |
Paragrafy | číselník | 34 | |
úložiště formulářů – bude řešeno novým systémem v rámci Etapy 1 | úložiště všech verzí šablon formulářů | 300 |
Poznámka: Jedná se o nejdůležitější uživatelské přehledy. Uvedený rozsah a množství údajů v přehledech neznamená, že se ve zdrojových datech stávajícího nebo budoucího systému jedná vždy o jednu tabulku.
Požadavky na přístup, vyhledávání a zálohy Interní uživatelé (zaměstnanci Objednatele)
• Interní uživatelé (referenti, vedoucí pracovníci) budou mít přístup ke všem SŘ,
• interní uživatelé budou mít dostupné části SŘDLP dle svých rolí a přidělených SŘ,
• rozhraní pro přístup interních uživatelů bude v českém jazyce,
• počet interních uživatelů očekáváme okolo 70 díky novým funkcionalitám,
• autentizace a autorizace interních uživatelů pomocí AD/LDAP/JIP/XXXX.
Externí uživatelé – žadatelé
• Žadatelé o SŘ (externí uživatelé) budou mít přístup ke všem svým správním řízením přímo
v aplikaci po přihlášení s přehledem svých řízení,
• dále budou mít přístup ke všem ostatním řízením jako veřejnost, s možností filtrování a
vyhledávání,
• po výběru SŘ bude uživatel moci zobrazit informace o průběhu SŘ a zpřístupnit detaily a
dokumenty (kromě dokumentů s parametrem „předmět obchodního tajemství“),
• rozhraní pro přístup externích uživatelů - žadatelů bude v českém a anglickém jazyce,
• autentizace a autorizace externích uživatelů pomocí NIA nebo Externí identity,
• možnost nastavit si zasílání upozornění pro případ nové písemnosti ve spise.
Externí uživatelé – účastníci řízení
• Účastníci SŘ (externí uživatelé) budou mít přístup ke všem svým správním řízením přímo
v aplikaci po přihlášení dle nastavených oprávnění s přehledem svých řízení,
• dále budou mít přístup ke všem ostatním řízením jako veřejnost, s možností filtrování,
• po výběru SŘ bude uživatel moci zobrazit informace o průběhu SŘ a zpřístupnit detaily a
dokumenty dle nastavených oprávnění,
• rozhraní pro přístup externích uživatelů – účastníků řízení bude v českém a anglickém jazyce,
• autentizace a autorizace externích uživatelů pomocí NIA nebo Externí identity,
• možnost nastavit si zasílání upozornění pro případ nové písemnosti ve spise.
Externí uživatelé – obecná veřejnost
• Externí uživatelé - obecná veřejnost - budou mít přístup ke všem správním řízením a spisové
dokumentaci ve stanoveném rozsahu,
• bez nutnosti prokazovat svou identitu, ale s vynuceným využitím ověření Captcha,
• uživatel přihlášený prostřednictvím Národního bodu pro identifikaci a autentizaci (NIA) nebo
Externích identit nebude ověření Captcha využívat,
• rozhraní pro přístup externích uživatelů – účastníků řízení bude v českém a anglickém jazyce.
Poznámka: Rozdíl mezi přístupem označeným „Externí uživatelé – účastníci řízení„ a přístupem
„Externí uživatelé – obecná veřejnost“ není v rozsahu zpřístupněných dokumentů, který je téměř stejný, ale v komfortu při vyhledávání a zobrazování informací a dokumentů. Při využití přístupu označeného „Externí uživatelé – účastníci řízení„ jsou identifikováni přihlášení uživatelé (NIA, EI) a
mají možnost předvýběru „svých SŘ“, notifikací a další nastavení ve svém profilu. Při využití přístupu označeného „Externí uživatelé – obecná veřejnost“ nejsou uživatelé identifikováni a musí opakovaně zadávat ověření Captcha před vstupem do SŘDLP a každou další iterací se systémem nebo se zvoleným dokumentem. Nástěnka pro interní uživatele nebude externím uživatelům přístupná, Zadavatel to nepožadoval. Zadavatel předpokládá, že pro externí účastníky řízení bude dostupné rozhraní s omezenými možnosti i omezenou množinou poskytovaných informací s jednoduchým filtrováním a vyhledáváním SŘ. Dashboard nebude dostupný pro externí uživatele. Zobrazování dashboardu ani rozhraní pro přístup do SŘDLP na mobilních zařízeních Objednatel nepožaduje.
Další požadavky:
• správa a ověřování identit uživatelů, administrátorů a aplikací musí odpovídat požadavkům vyhlášky č. 82/2018 Sb., o kybernetické bezpečnosti,
• možnost vyhledávání souvislostí mezi SŘ a dokumenty, např. dle referenčních skupin přípravků, zahrnutých přípravků, účastníků apod.,
• možnosti filtrování SŘ dle definovaných parametrů i kombinací parametrů (např. typu SŘ, zdali jde o řízení na žádost či z moci úřední, předmětu SŘ, nebo účastníka SŘ apod.), fulltextové vyhledávání v SŘ a jeho dokumentech/přílohách (dle jejich obsahu, přes celou bázi dat systému),
• fulltextové vyhledávání bude primárně využíváno pro prohledávání všech nebo vybraných typů souborů, např. soubory .PDF a bude vyhledáváno ve vybraných typech dokumentů, např. pouze v rozhodnutích, pouze v žádostech, ...),
• vyhledávání bude umožněno též na úrovni metadat SŘ (např. v poli „Poznámka“, v metadatech SŘ nebo v poli „Referenční skupina“ např. vyhledáním dle části řetězce (hvězdičková konvence),
• fulltextové vyhledávání bude umožňovat vyhledání i variant hledaných slov v jiných pádech (skloňování), vyhledávání jednotlivých slov i frází a výsledky vyhledávání třídit dle relevance.
• specifikovat požadavky na zálohování, jaká data a v jaké frekvenci zálohovat, definovat pravidla pro celkovou nebo dílčí obnovu dat ze záloh v příslušné dokumentaci (vlastní zálohování realizuje Objednatel svými prostředky dle návrhu (zálohovacího plánu) Zhotovitele).
3.1.2 Provázanost na systémy SÚKL
Základní charakteristika systémů a rozhraní Objednatele nezbytných pro SŘDLP. Dokumentace ke stávajícím systémům Objednatele bude poskytnuta v rámci analýzy včetně zajištění součinnosti stávajících dodavatelů.
AD/LDAP (existující systém Objednatele)
- Integrace SŘDLP s vnitřním identity managementem Objednatele,
- identifikace a autentizace interních uživatelů musí být v souladu a s využitím JIP/XXXX.
DLP (existující systém Objednatele, databáze Oracle)
- Referenční zdroj dat o registrovaných LP/PZLÚ/neregistrovaných LP ve specifickém léčebném
programu.
- DLP obsahuje informace o registrovaných léčivých přípravcích a jejich registraci, složení LP, držitel registrace, výrobce, pověřený zástupce, obal LP, příbalový leták, specifikace LP, vazby
mezi LP (LP se shodnými definovanými parametry, které jsou spojené do paralelní skupiny), ohlašované ceny původce, ATC skupina, informace o cenách a úhradách.
- Slouží jako zdroj dat pro číselníky LP/PZLÚ, držitelů registrací, webovou databázi léků, informativního přehledu změn úhrad na webu, pro čtení dat z DLP je možno využít pohledy,
- SŘDLP sleduje a eviduje veškeré změny DLP i po skončení SŘ.
Systém DIS13 (existující systém Objednatele)
- Evidence objemu distribuovaných léčivých přípravků.
- Zjištění spotřeby LP (např. identifikace LP, které mají být na trhu, ale nejsou).
AthenA (existující systém Objednatele)
- AthenA je spisová služba Objednatele,
- poskytuje webové služby pro načtení spisů, písemností a vložených příloh. Další služby poskytuje pro vytvoření spisu ve spisové službě, vytvoření obálky písemnosti, vložení příloh a vložení písemnosti do spisu,
- písemnost ve spisové službě obsahuje data z formulářů žádostí ve strukturovaném formátu
- SŘDLP eviduje přidělená ID spisů a písemností,
- SŘDLP hlídá změny ve spisové službě a provádí automatizovaně aktualizace dat a dokumentů při změně písemností ve spisu. Notifikuje provedené změny,
- SŘDLP vytváří a předává spisy, písemnosti a parametry jejich obálky včetně přiložených dokumentů do spisové služby pomocí existujících webových služeb AthenA,
- systém spisové služby AthenA je instalován s jednou organizační strukturou,
- spisová služba AthenA splňuje Národní standard pro elektronické systémy spisové služby.
Externí identity (EI) (existující systém Objednatele)
- Stávající systém pro evidenci identity externích subjektů,
- autentizace a autorizace zahraničních externích uživatelů,
- napojení SŘDLP k EI bude realizováno prostřednictvím REST API, které bude Objednatelem upraveno v EI na míru konkrétního nového systému SŘDLP, cílové řešení úpravy EI bude záviset na navrženém řešení Dodavatele pro nové SŘDLP,
- formalizované postupy pro registraci subjektů v novém systému SŘDLP, včetně požadavků na ověření v EI, navrhne Dodavatel (ve spolupráci s objednatelem) v rámci Etapy 1.
Web SÚKL a úřední deska (existující systém Objednatele)
- SŘDLP publikuje povinně zveřejňované informace na web na elektronickou úřední desku SÚKL
s využitím WS spisové služby AthenA,
- SŘDLP eviduje termíny publikace a termíny stažení, garantuje publikaci dle platné legislativy,
- AthenA publikuje na úřední desce písemnosti, další informace k písemnosti (účastníci řízení, zařazené LP atd.) publikuje do přehledu SŘ systém SŘDLP,
- SŘDLP pomocí WS předává písemnost spisové službě pro publikaci na úřední desce,
- SŘDLP generuje přehled SŘ na web SÚKL (xxxxx://xxx.xxxx.xx/xxxx/xxxxxxx-xxxxxxxxx-xxxxxx),
- SŘDLP ukládá vybraná metadata SŘ pro vyhledávací aplikaci na webu SÚKL.
OpenData SÚKL (funkcionalita pro zpracování dat a publikaci je součástí dodávky)
- Publikovat data o stanovených cenách a podmínkách úhrad jako otevřená data dle požadavků
na xxxxxxxx.xxxx.xx, požadavky budou upřesněny v rámci Etapy 1,
- publikovat opendata dle požadavků a pravidel nastavených Ministerstvem vnitra na xxxxx://xxxxxxxx.xxx.xx/,
- generovat a publikovat metadata všech SŘ jako otevřená data (požadavky budou upřesněny
v rámci Etapy 1),
- systém musí umožňovat případné další rozšiřování rozsahu publikovaných výstupů dat (v rámci dalšího rozvoje systému).
Aplikační rozhraní pro externí systémy pro přístup k dokumentaci SŘ (rozhraní a funkcionalita je součástí dodávky)
- Rozhraní zpřístupňuje dokumentaci správních řízení CaU, probíhajících i ukončených SŘ,
- s možností přístupu na písemnost (bez písemného požadavku na nahlížení), obálku, dokument
a obsah dokumentu (pouze dokumenty bez parametru „předmět obchodního tajemství“),
- rozhraní neobsahuje UI pro uživatelský přístup, pouze interface pro aplikace,
- přístup zahrnuje autentizaci, autorizaci a logování,
- rozhraní předává notifikace o SŘ, ve kterých došlo ke změnám.
Poplatky (stávající systém objednatele)
- Systém pro správu poplatků,
- ověření uhrazených poplatků.
Dohledové systémy Objednatele (stávající systémy objednatele)
- Zabbix – dohledový systém pro IZ infrastruktur,
- SIEM – systém pro sběr a analýzu událostí.
Další připravované interní systémy Objednatele
Objednatel požaduje, aby SŘDLP bylo navrženo tak, aby v budoucnu mohlo být s minimálními dopady
na SŘDLP a s minimální pracností napojeno na připravované nové systémy Objednatele:
- CESub (Centrální evidence subjektů) – nový budoucí systém - primární systém pro evidenci a
správu externích subjektů, napojen na základní registry ČR,
- EPM (Centrální evidence plných mocí) – nový budoucí systém - primární systém pro evidenci plných mocí, napojen na Centrální evidenci subjektů,
- MIS (Manažerská nadstavba),
- Hlídač lhůt a zaplacení pokut pro správní řízení o přestupku,
- PES (Portál externích subjektů) – nový budoucí systém - jednotný přístupový bod externích subjektů, který umožní subjektům elektronickou komunikaci s Ústavem. Součástí bude i
platební portál,
- DLP - nová budoucí verze,
- Úřední deska (elektronická) – nové řešení a nové rozhraní,
- Webové portály – nové webové portály Ústavu.
Jde o připravované nebo plánované systémy, které budou zdrojem dat pro SŘDLP (CESub, EPM, PES,
nové DLP) nebo které budou data ze SŘDLP převážně získávat (MIS, Hlídač lhůt, Úřední deska).
Webové formuláře žádostí (vytvoření formulářů není součástí dodávky)
- Data z formulářů žádostí bude SŘDLP přebírat jako základní informace pro nové SŘ,
- rozsah a struktura dat ze stávajících webových formulářů a pokyny pro jejich použití je k dispozici na: xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxxx-xxx-xxxxxx-xxxxxxx (viz také požadavek na str. 16 tohoto dokumentu),
- SŘDLP bude přijímat data z formulářů žádostí ze spisové služby AthenA s využitím jejích webových služeb, včetně všech dokumentů přiložených k žádosti,
- typově se jedná o tyto žádosti: 9 žádostí o stanovení + 9 žádostí o změnu + 1 žádost o zrušení
+ 1 žádost o kvalifikaci do úhradové soutěže + 1 žádost o přepis,
- umožnit poskytnutí dat vedených v SŘDLP pro předvyplnění webových formulářů při vyplňování žádosti žadatelem.
CMS, NIA (využití těchto rozhraní a služeb je součástí dodávky)
- Využití těchto rozhraní a služeb pro identifikaci a autorizaci externích uživatelů a využívání služeb OVM.
3.1.3 Přechod ze současné verze na nové SŘDLP:
- „hladká“ migrace dat, ideálně k jednomu momentu,
- ověření úplnosti a správnosti migrace před spuštěním produkčního provozu,
- během odlaďování migrace se budou probíhající SŘ měnit,
- Objednatel zajistí součinnost dodavatele stávajícího řešení během analýzy a migrace dat,
- dokumentace a datový model stávajícího řešení budou poskytnuty při zahájení Etapy 1
vybranému uchazeči,
- migrována musí být v jeden okamžik i rozpracovaná SŘ, nově vznikající dokumenty běžícího SŘ po migraci budou vytvářeny již dle nových šablon v novém systému
- po akceptované migraci do produkčního prostředí budou SŘ již vedena v novém SŘDLP bez omezení a včetně veškeré historie.
3.2 Požadavky Objednatele na technické řešení:
3.2.1 Obecné technické požadavky na předmět dodávky:
- dodávaný systém SŘDLP musí být provozuschopný na HW a SW infrastruktuře Objednatele,
- zabezpečený přístup do aplikace na základě přímé integrace na AD Objednatele a systém
JIP/XXXX,
- správu uživatelů vede Objednatel ve standardním LDAP a AD (Microsoft) včetně organizační
struktury,
- identifikace, autentizace a autorizace externích uživatelů v jejich rolích osob (uživatelů) vstupujících do procesu nahlížení průběh svých SŘ bude řešena s využitím NIA,
- možný budoucí provoz v cloudovém prostředí, umožnit budoucí přesun do cloudu bez rozsáhlých úprav aplikace (nezbytné úpravy např. ve vztahu k AD budou řešeny formou změnového požadavku) s ohledem na možné budoucí využití eGovernment Cloudu (plán Ministerstva vnitra ČR),
- soulad s požadavky EU směrnice eIDAS (ověřování podpisu),
- automatické vytváření logů, jejich ukládání do systému SIEM Objednatele,
- verzování všech zpracovávaných a uložených dokumentů,
- logování obsahu dat správního řízení a jeho změn v čase,
- aktualizace SŘDLP a implementace změn bez dopadu na stanice uživatelů,
- adaptabilní grafický design,
- databázový SW pro dodávanou aplikaci SŘDLP bude součástí dodávky,
- požadavek Objednatele je použít databázi PostgreSQL nebo MS SQL,
- zajištění provozu SŘDLP na úrovni HA Cluster v rámci jednoho datového skladu v režimu
Active-Passive,
- pro provoz systému využívat vždy stávající platformu Objednatele VMware,
- požadovaný operační systém pro serverové prostředí je Linux Red Hat 8 nebo vyšší, popř.
Windows Server 2016 nebo vyšší. Na stanicích interních uživatelů je to Windows 10,
- Objednatel vylučuje použití řešení zahrnující technologii Java Oracle s ohledem na zpoplatnění licencí a zvolit řešení bez licenčních nároků.
3.2.2 Využití aktuálních technologických standardů:
- vícevrstevnost (třívrstvá architektura),
- škálovatelnost,
- preference open-source technologií bez vazby na konkrétního dodavatele,
- integrační rozhraní pomocí REST API.
3.2.3 Využití stávajících zdrojů Objednatele
Součástí této VZ nebude dodávka hardware, softwarových licencí na virtualizační prostředí a níže specifikované operační systémy, HW, některé licence a potřebnou infrastrukturu datového centra tak poskytne Objednatel ze svých stávajících zdrojů. Pro umístění a instalaci předmětu dodávky této VZ tak Objednatel poskytne:
- standardní serverové prostředí a zdroje ve svých datových centrech,
- datová centra jsou vybavena standardním hardware a potřebnou infrastrukturou,
- pro umístění a provoz nového systému SŘDLP jsou k dispozici dvě ekvivalentní oddělená datová centra Objednatele,
- servery jsou osazeny procesory Intel (HP, Dell),
- virtualizační prostředí založené na platformě VMware,
- přípravu virtuálních prostředí dle požadavků Zhotovitele,
- operační systémy Microsoft Windows Server 2016 a novější, včetně licencí, instalace a základní nastavení,
- Linux Red Hat 8 a vyšší, včetně licencí, instalace a základní nastavení,
- instalaci a správu uvedených operačních systémů zajišťuje Objednatel,
- odpovídající diskový prostor dle výstupů z analýzy, disky SSD a SAS 15000 rpm (Dell),
- zajištění zálohování dle zálohovacího plánu Zhotovitele,
- Objednatel vylučuje použít řešení zahrnující technologii Java Oracle s ohledem na zpoplatnění licencí,
- osobní kvalifikované certifikáty uživatelů pro podepisování,
- služby kvalifikovaného časového razítka a kvalifikované pečetě.
3.2.4 Parametry stanic interních uživatelů
Popis stanic uživatelů, kteří budou využívat SŘDLP:
- operační systém Microsoft Windows 10 (32 bit nebo 64 bit),
- RAM 4 GB nebo více,
- procesor Intel i5 nebo i7, 1,8 GHz nebo více,
- zobrazovací zařízení s rozlišením minimálně 1650:1080 (monitor) nebo 1920:1080 (notebook),
- správa účtů ve standardním LDAP a AD (Microsoft), s využitím systému JIP/XXXX,
- software: Microsoft Office 365, prohlížeč Chrome, Microsoft Edge, případně Firefox nebo
Opera v nejnovějších verzích,
- případné úpravy na stanicích uživatelů zajistí Objednatel (např. instalace patch apod.).
SŘDLP bude provozován v následujících prostředích:
3.2.5.1 Vývojové prostředí (umístěné u Zhotovitele)
Toto prostředí bude plně ve správě Zhotovitele a primárně bude sloužit k přípravě, odladění a funkčnímu otestování SW komponent a napojení na systémy Objednatele. Odladěné a otestované řešení bude následně dle dohodnutého procesu Zhotovitelem instalováno (implementováno) do testovacího prostředí.
3.2.5.2 Testovací prostředí (umístěné u Objednatele)
Toto prostředí bude sloužit primárně k ověření/otestování funkcionalit dodaného SW řešení (SŘDLP) a k provádění školení nad testovacími daty. V dalších fázích životního cyklu SW bude testovací prostředí sloužit k primárnímu otestování nově dodaných nebo změněných funkcionalit SŘDLP a k otestování chování SŘDLP při změnách hodnot parametrů nebo číselníků. Testovací prostředí bude sloužit jak pro testy Zhotovitele, tak i pro testy Objednatele. Otestované řešení bude následně dle dohodnutého schvalovacího procesu Zhotovitelem nebo Objednatelem a dle schválených implementačních postupů instalováno (implementováno) do produkčního prostředí.
3.2.5.3 Produkční prostředí (umístěné u Objednatele)
V tomto prostředí budou pracovat uživatelé při reálném (ostrém) používání SŘDLP. Bude obsahovat všechny otestované a schválené funkcionality a všechna aktuální (ostrá) data, včetně všech historických dat ze stávajícího systému.
V SŘDLP budou v maximální možné míře využívané číselníky a parametry tak, aby nebylo nutné v maximálně možné míře při změně legislativy, souvisejících předpisů nebo procesů přepisovat kód SŘDLP. Funkcionality SŘDLP budou naprogramované tak, aby přebíraly hodnoty z číselníků a parametrů. Na základě načtených hodnot bude SŘDLP vykonávat požadované operace.
Obsah číselníků i hodnoty parametrů bude mít právo měnit (spravovat) uživatel s příslušnými právy
v SŘDLP.
Parametry SŘDLP budou určovat některé konkrétní vlastnosti SŘDLP a budou mít vliv na výsledky algoritmů, které SŘDLP ve svých funkcionalitách bude využívat. U každého z parametrů bude zaznamenána jak samotná hodnota parametru, tak i rozsah dat platnosti hodnoty parametru v SŘDLP. V některých případech pak budou v jednom okamžiku platit dvě hodnoty parametru (např. v závislosti na čase provedení některých úkonů v SŘDLP).
Číselníky SŘDLP budou buď vlastní – tedy takové, které budou definované a používané jen v rámci SŘDLP, nebo převzaté – tedy takové, které bude SŘDLP přebírat z jiných IS (jiných datových zdrojů, např. DLP).
Funkcionality pro správu číselníků budou pověřeným uživatelům dostupné v administrátorském
modulu nebo v samostatném modulu SŘDLP.
Převzaté číselníky bude SŘDLP schopen integrovat pomocí připojení na WS nebo využitím pohledů. Zároveň SŘDLP bude umožňovat import číselníků z formátu CSV.
Příklady číselníků:
o druh správního řízení (vazba na workflow),
o postupy,
o seznam účastníků řízení (osoby, organizace),
o číselník referenčních skupin,
o databáze léčivých přípravků,
o číselník potravin pro zvláštní lékařské účely,
o číselník paragrafů,
o vykazovací limit,
o specializace lékaře,
o referenční země (1, 2, 3),
o Generikum,
o generikum (závazek),
o podobný přípravek,
o číselník svátků,
o terapeutické skupiny.
U každého záznamu číselníku budou evidované jak příslušné hodnoty pro aplikaci v SŘDLP, tak i data
platnosti konkrétního záznamu (datum platnosti od, datum platnosti do).
Specifikace použitých technologií a doporučení v tomto dokumentu vycházejí ze standardů SÚKL ve snaze zajistit jednotnou technologickou platformu pro efektivnější správu (a provoz) a maximálně využít již zakoupený hardware a licence uvedených technologií. Přehled hardware a software poskytnutých pro SŘDLP ze zdrojů Objednatele je uveden v kapitole 3.2.3 tohoto dokumentu.
Klientskou část SŘDLP Objednatel doporučuje jako webové rozhraní splňující následující požadavky:
- Základní klientská část SŘDLP bude ve formě webového klienta (webového rozhraní, preference webových aplikací). V případě využití MS WORD apod. lze připustit instalaci v modelu On-Premise.
- Webová aplikace (webové rozhraní) bude pro interní uživatele dostupná v českém jazyce, rozhraní pro externí uživatele bude dostupné v českém a anglickém jazyce.
- Stránky webového rozhraní budou zpracované za dodržení HTML5 (nebo XHTML) standardů a doporučení W3C s využitím kaskádových stylů v kódování UTF-8 a především splňující požadavky v souladu se zákonem č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací.
- Stránky budou optimalizovány tak, aby byla zajištěna 100% kompatibilita u následujících prohlížečův aktuální verzi:
o Google Chrome,
o Microsoft Edge,
o Firefox,
o Opera.
- Klientská část SŘDLP musí být provozovatelná na operačních systémech: Windows 10 nebo
novějších, 32bit/64bit.
SŘDLP bude v oblasti bezpečnosti splňovat minimálně tuto specifikaci:
- SŘDLP bude chránit soukromé informace v souladu s příslušnými právními předpisy (zejména zákonem č. 110/2019 Sb., o zpracování osobních údajů a zákonem č. 181/2014 Sb., o kybernetické bezpečnosti), ve znění pozdějších předpisů a bezpečnostní politikou SÚKL,
- SŘDLP musí být plně kompatibilní s Nařízením 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ů) a se zákonem č. 110/2019 Sb., o zpracování osobních údajů,
- Každý uživatel bude systémem SŘDLP jednoznačně identifikován, autentizován a autorizován,
- SŘDLP bude umožňovat audit uživatelem provedených operací (včetně pokusů o
neautorizované operace),
- SŘDLP bude zajišťovat šifrovanou komunikaci pro webové služby, certifikáty zajistí Objednatel,
- Zhotovitel dodá bezpečnostní dokumentaci dle kapitoly 4.1.6
- Objednatel v souladu s § 4a odst. 1 zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZoKB“) informuje v odst.
1.8 smlouvy o dílo dodavatele, že systém, který je v rámci díla vytvářen, bude významným informačním systémem ve smyslu § 2 písm. d) ZoKB a dodavatel bude ve smyslu § 2 písm. e) ZoKB správcem tohoto systému. V tomto smyslu se Dodavatel stává významným dodavatelem dle § 2 písm. n) vyhlášky č. 82/2018 Sb. (díle jen „VoKB“) a při plnění smlouvy je povinen plnit bezpečnostní pravidla pro významné dodavatele, které tvoří přílohu č. 4 smlouvy o dílo.
3.3.5.1 Důvěrnost
SŘDLP bude zajišťovat důvěrnost dat následujícím postupem:
- Řízení přístupu
o Identifikaci a autentizaci uživatele – proces identifikace a následné ověření identity uživatele;
o Autorizaci uživatele – proces ověření, zda je uživatel oprávněn k přístupu k SŘDLP a
jeho funkcím.
- Šifrování citlivých dat – veškerá citlivá data budou během přenosu a jejich uložení bezpečně zašifrována, aby byl vyloučen neautorizovaný přístup.
- Auditovatelnost – ke všem provedeným autorizovaným operacím i k pokusům o neautorizované operace bude udržována auditní stopa. Auditní log bude ukládán v samostatné databázi a předáván do centrálního systému bezpečnostního monitoringu.
3.3.5.2 Řízení přístupu
Zhotovitel zahrne do svého řešení bezpečnostní opatření zejména v oblasti autentizace řešící ověření identity a autorizace zaměřené na umožnění přístupu dle přidělené role a dále řízení vytvořeného sezení (session).
Pokud budou v rámci SŘDLP, jeho komponent nebo podpůrných systémů existovat lokální účty, budou
se řídit politikou hesel pro privilegované účty.
Pro všechny typy účtů (uživatelské, administrátorské, servisní) bude vždy uplatněno pravidlo „least- privilege“, tedy pravidlo minimálních oprávnění – každý účet bude mít nastavena pouze taková oprávnění, která opravdu využívá. Pro servisní účty bude uplatněno pravidlo „privilege separation“, na základě kterého každá komponenta (funkční část) bude využívat oddělená oprávnění (tedy různé účty).
3.3.5.3 Šifrování
Veškerá citlivá data budou adekvátním způsobem zabezpečena kryptografickými metodami, které zajistí pouze autorizovaný přístup. Ochrana dat bude zaručena během celého jejich životního cyklu, tedy jak při jejich přenosu, tak jejich uchovávání. Kryptografické prostředky budou využity v souladu s vyhláškou č. 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).
Je preferováno použití následujících komunikačních protokolů:
- SSL/TLS
o verze protokolu minimálně TLS 1.2, musí být korektně konfigurováno tak, aby bylo vyloučeno zneužití známých zranitelností (viz databáze zranitelností CVE);
o TLS 1.3 nebo novější, pokud je to možné, tyto protokoly by měly podporovat obě
strany SSL/TLS komunikace;
o nepovolovat verzi protokolu SSL 3.0, ani nižší, ani TLS 1.0 a TLS 1.1;
o nepoužívat NULL encryption;
o nepoužívat anonymní dohadování klíčů;
o nepoužívat „Client-Initiated Renegotiation“;
o v případě použití klientských certifikátů musí server akceptovat certifikáty jen od těch CA, u kterých se vydávají klientské certifikáty pro danou aplikaci/službu (tj. neposílat celý systémový trust list).
o Používat pouze bezpečné cipher suites, tedy:
▪ šifry, které budou v souladu vyhláškou č. 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);
▪ pro výměnu klíčů preferovat cipher suites s podporou „Perfect Forward Secrecy“;
▪ další doporučení k nastavení SSL/TLS je možné nalézt na stránkách
xxxxxxx.xxx;
- SSH verze 2;
- IPSec
o používat kontrolu integrity (MAC);
o nepoužívat NULL encryption;
o používat symetrické šifrovací algoritmy s minimální efektivní délkou klíče 128 bitů;
o pro dohadování klíčů používat DH groups dlouhé minimálně 2048 bitů (MODP) popř. 256 bitů (ECP);
o nepoužívat anonymní dohadování klíčů nebo dohadování klíčů spoléhající na nezabezpečenou DNS;
- HTTPS (SSL/TLS).
3.3.5.4 Auditovatelnost
SŘDLP bude zajišťovat auditovatelnost dat i procesů v aplikaci, tedy zakomponování této funkcionality při návrhu a vývoji SŘDLP. Jedná se zejména o přístupy k datům a jejich změny pro jednotlivé objekty a uživatele. Auditní log bude ukládán v samostatné databázi a integrován s centrálním řešením pro správu a vyhodnocování logů SIEM.
Přístup k auditním záznamům bude bezpečně chráněn a bude zabráněno možnosti jeho zneužití nebo ohrožení. SŘDLP bude umožňovat nastavení přístupových práv k auditním záznamům tak, aby mohly být auditovány samostatnou rolí.
Pokud vyhodnocování záznamů aplikace nebo její části bude provádět Zhotovitel, bude povinen případný bezpečnostní incident zjištěný z analýzy těchto záznamů hlásit odpovídajícím způsobem Objednateli.
3.3.5.5 Integrita
Cílem je zaručení a udržení konzistence a správnosti dat během celého jejich životního cyklu. Bude tedy potřeba zajistit, aby data nemohla být neautorizovaně modifikována a aby každá autorizovaná i neautorizovaná modifikace dat byla detekována. Spolu s integritou bude nutné zajistit také nepopiratelnost, tedy vyloučení možnosti popřít provedení libovolné operace nad daty. Integrita dat bude zajištěna pomocí vhodného řízení přístupu k datům (autorizace) a auditovatelnosti (logování a následná detekce přístupu k datům). Integrita kritických dat bude zajištěna implementací dodatečných kontrol – např. počítání kontrolních otisků dat a jejich pravidelná kontrola.
Každý vstup do aplikace (externí systém, uživatel, mezi komponentami) bude vždy kontrolován na validitu, čímž může být detekováno poškození dat nebo případný pokus o útok.
3.3.5.6 Disaster recovery plan
Zhotovitel řešení navrhne postupy pro vypnutí a zapnutí SŘDLP, včetně posloupnosti jednotlivých kroků, především s ohledem na bezpečné obnovení systému při jeho selhání – tj. vytvoření plánů obnovy aplikace. Dále bude povinen spolupracovat na jeho ověření v rámci testování obecných plánů obnovy provozu systémů Objednatele.
Účty administrátorů na všech podpůrných systémech a komponentách (OS, DB atp.) budou výhradně osobní. Použití sdílených administrátorských účtů musí být řádně odůvodněno a předem konzultováno s Objednatelem.
Servisní účty, tedy účty, pod kterými běží SŘDLP nebo prostřednictvím kterých SŘDLP přistupuje k ostatním komponentám nebo externím systémům budou uvedeny v odevzdané dokumentaci k SŘDLP. U každého účtu musí být uveden jeho účel a způsob jakým je možné účtu změnit heslo, včetně identifikace všech míst, kde je heslo uloženo (DB tabulka, konfigurační soubor, atp.). Hesla k servisním účtům budou bezpečným způsobem předány Objednateli ve formě, kterou určí Objednatel.
3.3.8 Vzhled uživatelského webového rozhraní
Uživatelské rozhraní, kontextová nápověda a dokumentace bude zpracována v českém jazyce (s
výjimkou pro přístup externích uživatelů, je uvedeno dále v této kapitole).
Uživatelské rozhraní bude respektovat současný moderní vzhled aplikací postavený na bázi operačního systému Windows 10 a vyšší. Ovládání SŘDLP bude intuitivní pro běžného uživatele zvyklého pracovat v prostředí OS Windows (levé a pravé tlačítko myši, dvojklik pro zobrazení detailu atp.). Uživatel bude ovládat SŘDLP primárně s pomocí myši nebo podobného zařízení (trackball, touchpad, …). SŘDLP bude poskytovat možnost ovládání s pomocí klávesnice - preferuje se, aby funkcionality byly dostupné buď ovládáním kurzorovými klávesami, nebo pomocí klávesových zkratek.
Pracovní obrazovka uživatele bude navržena tak, aby splňovala požadavky na moderní systém a bylo možné pracovat na všech typech zařízení (responzivní design) a aby umožňovala práci i uživatelům dle zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací. Veškeré funkcionality budou dostupné buď přímo z pracovní plochy uživatelského rozhraní, nebo z rozbalovacího menu.
Zhotovitel zajistí, aby uživatelé měli v rozhraní dostupnou plnou kontextovou nápovědu a návod, jak
s rozhraním a jeho funkcionalitami pracovat.
Rozhraní pro přístup externích uživatelů bude mít možnost volby jazyka (CZ/EN), stejně tak
i dokumentace pro uživatele a nápověda k této části systému bude dostupná také v angličtině.
3.3.9 Uživatelské rozhraní pro správu parametrů SŘDLP
Uživatelské rozhraní pro administrátora SŘDLP bude mít funkcionality potřebné pro správu
(nastavování) hodnot všech parametrů SŘDLP.
3.3.10 Uživatelské rozhraní pro správu číselníků
Uživatelské rozhraní pro správce číselníku bude mít funkcionality potřebné pro správu/nastavování obsahu vlastních číselníků SŘDLP (například číselníku referenčních skupin, vazba odbornosti lékaře na LP, míru podobnosti a zaměnitelnosti LP a LL, doplňující informace k PZLÚ s vazbou na DLP). U záznamů číselníků bude SŘDLP umožňovat nastavení data platnosti záznamu – platný/aktivní od xx.xx.xxxx do yy.yy.yyyy. Při nevyplnění koncového data platnosti bude záznam stále platný/aktivní. Uživatelům při práci s číselníky v nově vytvářených záznamech bude SŘDLP nabízet pouze platné/aktivní záznamy.
3.3.11 Integrace s klientskými IS
Integrace s interními systémy Objednatele bude zajištěna výhradně prostřednictvím webových služeb. Podmínky a možnosti budou upřesněny v rámci plnění Etapy 1.
Vytvořené webové služby – REST (výjimečně SOAP pro integraci se staršími systémy Uživatele) – budou součástí dodaného řešení. Objednatel nepožaduje dodání a využívání integrační platformy (ESB). V případě dodání ESB jsou licenční poplatky na jeho dodání a údržbu, v souladu s článkem 3 přílohy 1 Smlouvy o dílo, započteny do celkové ceny dodávky.
4 DOKUMENTACE A ŠKOLENÍ
Součástí dodávky SŘDLP bude i dokumentace, která bude obsahovat minimálně níže uvedené dokumenty. Dokumentace bude zpracována v českém jazyce (kromě dokumentace pro externí uživatele, která bude zpracována v českém i anglickém jazyce) a bude předána ve formátech MS Office; případné modely (datový model, use case diagramy, procesní modely apod.) ve formátu Enterprise Architect (optimálně BPMN 2.0).
Obsah dokumentace bude realizován dle požadavku zákona č. 365/2000 Sb., o informačních systémech veřejné správy a změně některých zákonů, ve znění pozdějších předpisů a vyhlášky č. 529/2006 Sb.,
o požadavcích na strukturu a obsah informační koncepce a provozní dokumentaci a o požadavcích na řízení bezpečnosti a kvality IS veřejné správy.
Instalační příručka bude popisovat jednotlivé kroky instalace, konfigurace a zprovoznění SŘDLP. Příručka bude zahrnovat všechny nezbytné instalační kroky pro instalaci operačního systému, dále bude zahrnovat výčet všech nezbytných komponent včetně verzí, služeb, které mají být spuštěné či zastavené, licencí a konfigurací, a to včetně operačního systému, DB a frameworků.
Instalační příručka bude obsahovat část popisující způsob nahrání aplikace z testovacího prostředí do produkčního prostředí včetně nástrojů k tomuto přesunu potřebných. Součástí popisu přechodu do produkčního prostředí budou i požadavky na minimální výkon produkčního prostředí.
Přílohou budou instalační média a instalační procedury.
Provozní dokumentace bude obsahovat vlastní popis provozu aplikace, uživatelskou dokumentaci a administrátorskou dokumentaci – příručky správce aplikace a dokumentace pro dodavatele externích systémů.
Provozní dokumentace bude obsahovat vymezení a popis funkcí, včetně bezpečnostních, které budou pro uživatele k dispozici, návod na jejich použití, vymezení oprávnění a povinností uživatelů. Provozní dokumentace bude složená z těchto hlavních bloků (které mohou být v různých samostatných dokumentech):
- popis funkcí, včetně bezpečnostních, které používá uživatel i administrátor pro svou činnost při využívání služeb, infrastruktury, aplikací nebo informačního systému a návod na použití těchto funkcí,
- podrobný popis služeb, infrastruktury, aplikací nebo informačního systému,
- popis jednotlivých činností vykonávaných při správě služeb, infrastruktury, aplikací nebo informačního systému veřejné správy.
4.1.3 Administrátorská příručka
Administrátorská příručka bude určena pro administrátory SŘDLP, aplikace či služby a bude obsahovat informace potřebné zejména pro správu služeb, detailní popis činností správce SŘDLP a popis služeb. Příručka bude založena na popisu základních funkcí a principů ovládání služeb, systému a aplikací pro správce.
Uživatelská dokumentace bude obsahovat popis všech funkcí, se kterými přijde uživatel do kontaktu. Součástí uživatelské dokumentace budou i školicí materiály.
Dokumentace bude obsahovat detailní popis architektury SŘDLP, struktury a chování jednotlivých komponent SŘDLP vytvořených nebo změněných za účelem implementace SŘDLP do prostředí Objednatele.
Dokumentace bude obsahovat popis a schémata všech v SŘDLP implementovaných procesů. Zhotovitel musí klást důraz na vysokou míru vizuálních prvků dokumentace. Doporučený vizualizační jazyk pro zobrazení chování a struktury systémů je UML 2.4 a BPMN 2.0.
Dokumentace bude dále obsahovat popis zdrojových souborů (např. Javadoc pro třídy). Z vývojové dokumentace musí být zřejmé veškeré prvky vhodné pro další uzpůsobení naprogramované části SŘDLP interními programátory. Zdrojové kódy vytvořené Zhotovitelem musí být opatřeny komentáři tak, aby bylo zřejmé, co je jejich účelem.
Dokumentace bude obsahovat podrobný popis datového modelu SŘDLP.
4.1.6 Bezpečnostní dokumentace
Bezpečnostní dokumentace bude obsahovat minimálně:
- Bezpečnostní politiku (popis bezpečnostních opatření, která SÚKL uplatnil při zajišťování bezpečnosti tohoto systému a která odpovídají požadavkům na bezpečnost stanoveným v Informační koncepci SÚKL, v Bezpečnostní politice SÚKL a v technické normě ČSN/ISO 27002:2014.
- Bezpečnostní směrnice pro činnost bezpečnostního správce systému (zaměstnanec nebo jiná fyzická osoba, která zajišťuje kontrolu bezpečnosti systému, zároveň definuje pro každou roli souhrn určených činností a potřebných oprávnění pro provádění těchto činností v SŘDLP), která obsahuje podrobný popis bezpečnostních funkcí, které bezpečnostní správce SŘDLP používá pro provádění určených činností v systému, a návod na použití těchto funkcí.
- Výsledky dynamického/fuzz testování webových služeb, ověření modelu hrozeb/možnosti útoku.
- Splnění požadavků technické normy ČSN ISO/IEC 27034 (vypracování analýzy rizik aplikace a ochrany soukromí, vytvoření knihovny bezpečnostních opatření aplikace, popis procesů týkajících se bezpečnosti aplikace, vytvoření normativního rámce aplikace).
- Referenční seznam odezev SŘDLP pro konkrétní scénáře.
Zhotovitel poskytne následující typy školení:
- Administrátorské školení - cílem školení je vyškolit pracovníky SÚKL (max. 8 IT pracovníků) v administraci SŘDLP. Školení bude zaměřené zejména na následující okruhy: architektura, principy správy SŘDLP, plán zálohování/obnovy, pravidelné činnosti, přepnutí provozu do druhé lokality, práce s prostředím (testovací, referenční, produkční), příprava prostředí, nasazování nových verzí, monitoring, vyhodnocování chyb.
- Uživatelské školení - pro každé aplikační řešení budou proškoleni vybraní uživatelé. Cílem školení bude vyškolit zástupce uživatelů, kteří následně budou školit ostatní uživatele. Předpokládáme, že pro školení každého aplikačního řešení bude vybráno maximálně 10 uživatelů.
Z každého školení bude zároveň pořízen audiovizuální záznam pro další použití Objednatelem.
5 POSTUP ZHOTOVENÍ DÍLA
Postup zhotovení díla bude Xxxxxxxxxxxx důsledně veden na principech projektového řízení a bude rozdělen na následující základní části (etapy), ke kterým se budou vázat platební milníky:
Etapa | Aktivity | % z ceny za dílo | Termín dokončení |
Etapa 1 | analýza a vytvoření prováděcího projektu | T1* + 90 dnů | |
předání prováděcího projektu k akceptaci | T1* + 90 dnů | ||
akceptace prováděcího projektu - platební milník | 5 % | T1* + 135 dnů | |
Etapa 2 | vytvoření SŘDLP | T2** + 130 dnů | |
implementace SŘDLP na testovací prostředí | |||
provedení funkčních, integračních a bezpečnostních testů SŘDLP | T2** + 160 dnů | ||
provedení migrace dat | |||
provedení zátěžových a výkonových testů | |||
vytvoření dokumentace a provedení školení | |||
předání SŘDLP k akceptaci | T2** + 160 dnů | ||
akceptace SŘDLP - platební milník | 65 % | T2** + 230 dnů | |
Etapa 3 | implementace SŘDLP na produkční prostředí | T3*** + 20 dnů | |
provedení migrace dat | |||
provedení zátěžových a výkonových testů | |||
zahájení pilotního provozu | |||
podpora pilotního provozu v produkčním prostředí a zavedení do rutinního provozu, předání dokumentace pro produkční prostředí | T3*** + 65 dnů | ||
předání díla k akceptaci | T3*** + 65 dnů | ||
akceptace díla - platební milník | 30 % | T3*** + 95 dnů |
* T1 je datum účinnosti smlouvy o dílo
** T2 je datum akceptace Etapy 1
*** T3 je datum akceptace Etapy 2
Pro výpočet výše uvedených termínů platí kalendářní dny.
K předání a k akceptaci jednotlivých etap budou vázány finanční prostředky formou procent z ceny za
dílo (viz tabulka výše) a termíny dokončení.
Průběh (metodika) implementace bude zajišťovat maximální přenos know-how (znalostí o SŘDLP) ze Zhotovitele na Objednatele tak, aby po ukončení projektu implementace byl Objednatel schopen naimplementované řešení provozovat vlastními zdroji bez nadbytečné podpory Zhotovitele.
Prováděcí projekt bude výstupním dokumentem první etapy implementace SŘDLP. Dokument bude dodán v českém jazyce.
Dokument bude obsahovat minimálně následující:
- Katalog požadavků (výstup z fáze sběr a analýza požadavků).
- Funkční specifikace (detailní popis, jak má software fungovat, bez vazby na konkrétní technologii či detailní architekturu SŘDLP).
- Návrh technické specifikace (návrh architektury SŘDLP a jeho jednotlivých částí, volbu konkrétních technologií).
- Popis datové a aplikační architektury SŘDLP.
- Plán projektu (organizace, kompetence, komunikace, eskalace, rizika, řízení kvality, implementační plán, požadavky na součinnost, testovací scénáře a akceptační kritéria).
- Návrh technické infrastruktury.
- Detailní popis implementovaných funkcionalit SŘDLP včetně schémat procesů.
- Seznam klíčových služeb.
- Hodnoty průměrné denní odezvy pro každou klíčovou službu.
- Detailní popis vazeb SŘDLP na externí systémy.
- Popis migrace dat.
- Testovací scénáře (funkční, zátěžové/výkonnostní, bezpečnostní testy).
- Harmonogram a požadovanou součinnost pracovníků Objednatele.
- Detailní popis instalačních procedur do jednotlivých prostředí.
- Návrh zajištění kontinuity provozu, který bude obsahovat minimálně:
o návrh plánů řízení kontinuity,
o přehled všech klíčových komponent vyžadujících zálohování či jiné zabezpečení,
o návrh metod zabezpečení komponent,
o detailní plány zálohování všech klíčových komponent,
o návrh plánů a postupů pro obnovu řešení v případě havárie,
o návrh procesů a postupů pro testování plánů a postupů pro obnovu řešení včetně zálohování, obnovy záloh a testování záložních médií.
Zhotovitel bude mít formalizovanou Metodologii pro vývoj, programování a kódování aplikace zahrnující i požadavky na bezpečnost, včetně opatření na ochranu proti škodlivým programům. Metodologie bude též zahrnovat základní principy organizační bezpečnosti pro vývoj a testování aplikace. Zhotovitel doloží typ metodologie, který použil pro vývoj aplikace prostřednictvím čestného prohlášení a dodání popisu nebo dokumentace této metodologie.
Aplikace bude podporovat národní lokalizaci a více bajtové kódování (UTF). Aplikace bude rovněž podporovat řízení výjimek, kdy výjimkou se myslí libovolná chyba nebo neočekávané chování, které se vyskytne během vykonávání programu a bude následně zpracováno a zároveň nedojde k neřízenému selhání běhu. V neposlední řadě bude vyžadováno zavedení řízení konfigurace a změn, které představuje systematické vyhodnocování, koordinování a implementaci schválených změn včetně uchování předchozích verzí a testování verzí nových.
Zhotovitel bude povinen implementovat všechna požadovaná opatření. V případě, že Zhotovitel nebude schopen zajistit splnění některého požadavku, navrhne jiné kompenzační opatření.
Zhotovitel bude využívat helpdeskový systém Objednatele. Objednatel poskytne přístup k helpdeskovému systému k zadávání a řešení požadavků smluvních služeb a dalších požadavků. Podmínky pro využití helpdeskového systému Objednatele jsou popsány v Servisní smlouvě.
5.5 Migrace ze stávajícího systému
5.5.1 Parametry současného stavu
Základní informace o rozsahu současného systému jsou uvedeny v kapitole 2.2. tohoto dokumentu.
Podrobné informace budou poskytnuty v rámci analýzy (Etapa 1).
Zhotovitel provede migraci dat ze stávajících datových struktur do nových datových struktur – do
dodávané databáze SŘDLP.
Data budou převedena z aktuální kopie stávajícího systému nejprve do testovacího a v další etapě do produkčního prostředí SŘDLP. V průběhu přípravy a ladění migrace dat bude docházet ke změnám ve stávajícím systému u zpracovávaných správních řízení.
V rámci migrací Zhotovitel:
- Předloží Objednateli ke schválení „Plán migrace“ včetně plánu testů na ověření konzistence převedených dat (pro migraci do produkčního prostředí bude „Plán migrace“ obsahovat rizikový scénář pro nutnost vrácení do původního stavu).
- Migruje data ze stávajícího do nového systému SŘDLP.
- Vytvoří „Protokol o migraci“.
- Provede základní sadu testů migrovaných dat.
- Vytvoří „Protokol o testování migrovaných dat“.
- Předá Objednateli SŘDLP s migrovanými daty do užívání.
5.6 Implementace do testovacího a produkčního prostředí
Systém SŘDLP bude v prostředí Objednatele implementován Zhotovitelem, a to na základě příslušné části oboustranně odsouhlaseného prováděcího projektu.
Zhotovitel připraví a dodá testovací scénáře pro testy funkční, integrační, výkonové/zátěžové i bezpečnostní. Vlastní testování dle testovacích scénářů provede Objednatel.
Zhotovitel připraví a dodá testovací data, která umožní následné otestování SŘDLP dle Xxxxxxxxxxxx
dodaných a Objednatelem odsouhlasených testovacích scénářů.
Instalace do testovacího prostředí bude probíhat dle v prováděcím projektu uvedených a akceptovaných postupů – může být automatická i manuální.
Instalace do produkčního prostředí bude probíhat automaticky – spuštěním instalační SW komponenty. Objednatel předpokládá automatizovanou instalaci, kterou předtím Dodavatel odladí na testovacím prostředí, s cílem eliminovat možnost vzniku chyb a výpadků způsobených ručními zásahy do konfigurace a instalace nových verzí. Proto by neautomatizovatelné změny měly být minimalizovány.
Instalační postupy budou Zhotovitelem popsané v prováděcím projektu.
5.7 Nasazení SŘDLP do produkčního prostředí
Zavedení SŘDLP do rutinního provozu bude probíhat za podmínek stanovených na základě oboustranně odsouhlaseného prováděcího projektu.
Zavedení SŘDLP do rutinního provozu znamená minimálně následující:
- instalace do produkčního prostředí (automatická dle instalační procedury),
- migrace dat,
- provedení zátěžových a výkonnostních testů,
- provedení případné finální optimalizace SŘDLP na základě výsledků zátěžových a výkonnostních textů v produkčním prostředí,
- podpora pilotního provozu,
- zapojení externích systémů do provozu,
- ukončení pilotního provozu, akceptace, zahájení rutinního provozu.
6 SOULAD S PRÁVNÍMI PŘEDPISY
Níže uvedený výčet právních předpisů slouží pouze jako demonstrativní výčet stěžejních právních předpisů upravujících danou problematiku. Nelze tedy vyloučit, že bude třeba aplikovat i další právní předpisy zde neuvedené. Těmito právními předpisy jsou minimálně:
• Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů,
• Zákon č. 378/2007 Sb., o léčivech a o změnách některých souvisejících zákonů, ve znění pozdějších předpisů,
• Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění a o změně a doplnění některých souvisejících zákonů, ve znění pozdějších předpisů,
• Vyhláška MZ ČR č. 134/1998 Sb., kterou se vydává seznam zdravotních výkonů s bodovými hodnotami, ve znění pozdějších předpisů,
• Vyhláška č. 84/2008 Sb., o správné lékárenské praxi, bližších podmínkách zacházení s léčivy v lékárnách, zdravotnických zařízeních a u dalších provozovatelů a zařízení vydávajících léčivé přípravky, ve znění pozdějších předpisů,
• Vyhláška č. 376/2011 Sb., kterou se provádějí některá ustanovení zákona o veřejném
zdravotním pojištění, ve znění pozdějších předpisů,
• Vyhláška č. 384/2007 Sb., o seznamu referenčních skupin, ve znění pozdějších předpisů,
• Zákon č. 265/1991 Sb., o působnosti orgánů České republiky v oblasti cen, ve znění pozdějších předpisů,
• Zákon č. 526/1990 Sb., o cenách, ve znění pozdějších předpisů,
• Zákon č. 235/2004 Sb., o dani z přidané hodnoty (DPH), ve znění pozdějších předpisů,
• Zákon č. 110/1997 Sb., o potravinách a tabákových výrobcích a o změně a doplnění některých souvisejících zákonů, ve znění pozdějších předpisů,
• Cenový předpis Ministerstva zdravotnictví 1/2019/FAR ze dne 12.12.2018, o regulaci cen léčivých přípravků a potravin pro zvláštní lékařské účely,
• Cenové rozhodnutí Ministerstva zdravotnictví 1/19-FAR ze dne 12.12.2018, kterým se stanoví seznam ATC skupin, které v uvedené lékové formě nepodléhají cenové regulaci stanovením maximální ceny,
• Zákon č. 634/2004 Sb., o správních poplatcích, ve znění pozdějších předpisů,
• Zákon č. 110/2019 Sb., o zpracování osobních údajů,
• Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce,
• Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES,
• Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů,
• Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů,
• Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů,
• Vyhláška č. 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),
• Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů,
• Vyhláška č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy),
• Zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů,
• Zákon č. 250/2017 Sb., o elektronické identifikaci.
• Zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, ve znění pozdějších předpisů.
Návrh manažerského dashboardu
pro projekt
Vývoj a zajištění podpory Informačního systému pro vedení a zpracování správních řízení
1/23
PHYSTER TECHNOLOGY, a.s. Návrh manažerského dashboardu
Obsah
2.1 Práce s více obrazovkami 8
2.3 Definice a sledování KPI 8
3 Návrh řešení Manažerského dashboardu 13
3.2 Práce s více obrazovkami 14
3.1 Seznam správních řízení 15
3.2 Detail správního řízení 17
3.3 Definice a sledování KPI 18
1 Vstupní informace
Obsah a formální náležitosti dokumentu “Návrh řešení přehledné nástěnky (dashboardu) pro roli Manažer“
Dokument musí obsahovat vizuální prezentaci toho, jak se bude nástěnka při používání Systému zobrazovat manažerovi na monitoru. Vizuální prezentace každé obrazovky musí být dále doplněna o základní písemný popis jednotlivých zobrazovaných prvků, jejich funkcí a možností nastavení vlastností dashboardu a zobrazovaného obsahu. Musí být jasné vazby mezi vyznačenými aktivními prvky (menu, ikony, tlačítka apod.) a jednotlivými obrazovkami. Manažer, a stejně tak i pracovníci sekce, používají samostatnou obrazovku monitoru na notebooku při práci mimo kancelář nebo dva monitory v kanceláři, kde mohou současně pracovat s více dokumenty a databázemi v samostatných oknech. Vhodné proto bude představit vizuální prezentaci jak v zobrazení maximalizovaného okna nástěnky přes celou obrazovku („fullscreen“) na jednom menším displeji notebooku s případným vertikálním rozdělením okna pro zobrazení rozdílných informací (detailů), tak i pro zobrazení více oken s rozdílným obsahem současně na dvou monitorech. Detaily řízení by měly být snadno dostupné a mělo by být možné pracovat souběžně s nástěnkou i vícero „kartami“ či záložkami detailů správních řízení v jednotlivých oknech nebo mezi nimi snadno přecházet. Okna (záložky) by mělo být možné „vytáhnout“ mimo domovské okno, aby mohlo být zobrazeno na druhém z monitorů.
Manažer musí mít snadno dostupné souhrnné informace v podobě KPIs (Klíčové ukazatele výkonnosti / key performance indicators) a podrobné informace o vybraném správním řízení, včetně pracovníků, kterým bylo řízení přiděleno, znázornění průběhu a plnění milníků řízení, datumů a názvů vydaných dokumentů, poznámek apod. Manažer musí mít jednoduše dostupné informace o jednotlivých přidělených správních řízeních (dále také „SŘ“) konkrétnímu pracovníkovi.
Návrh řešení nástěnky je možno předložit také ve formě elektronické prezentace. Průvodní dokument s příslušným popisem zobrazovaných informací, funkcionalit, ovládání a možností uživatelských nastavení pro zobrazování nástěnky (předvolby, seskupování, filtrování, volba polí atd.) musí být předložen i v případě předložení elektronické prezentace, včetně specifikace všech souborů elektronické prezentace a doporučení pro ovládání elektronické prezentace. Elektronická podoba musí být snadno spustitelná a nesmí být spojena s nezbytnou asistencí ze strany IT podpory na straně zadavatele (oprávnění administrátora, instalace) ani vyžadovat speciální software nebo licence třetích stran. Veškeré součásti elektronické prezentace musejí být předány prostřednictvím Národního elektronického nástroje a prezentace musí být snadno spustitelná na stanici uživatele SŘDLP (popis stanic viz kapitola 3.2.4 Parametry stanic interních uživatelů v dokumentu SŘDLP – Návrh smlouvy o dílo - Příloha č. 1).
Zadavatel připouští i formu videoprezentace ve formátu spustitelném v operačním systému Windows 10.
Podklady pro „Návrh řešení přehledné nástěnky (dashboardu) pro roli Xxxxxxx“
Při zpracování zadání bude dodavatel vycházet zejména z požadavků zadavatele na předmět plnění uvedených v této zadávací dokumentaci a jejích přílohách a také z účinných právních předpisů aplikovatelných na vedení uvedených správních řízení.
Pro vyloučení pochybností zadavatel stanoví, že pro účely vyhodnocení tohoto dílčího kritéria hodnocení je rozhodný stav právního řádu ke dni zahájení zadávacího řízení.
Seznam zkratek použitých v této části zadávací dokumentace je uveden v příloze č. 1 návrhu smlouvy o dílo Specifikace předmětu díla.
Správní řízení jsou zahajována z moci úřední nebo na žádost. Zadavatelem jsou pak tato řízení vedena (koordinována) podle svého předmětu a obsahu buďto na oddělení VTS, nebo KSŘ.
Oddělení VTS svá řízení vede po procesní i odborné stránce. Oddělení KSŘ vede odborně komplexnější správní řízení, na kterých spolupracují další oddělení, zejména oddělení OHL a FEA.
Manažerem se rozumí pracovník, který je nadřízený oběma vedoucím oddělení VTS a KSŘ.
Manažer nástěnku využívá pro manažerskou kontrolu při plnění lhůt (milníků) a napomáhá vedoucím při určování priorit v případě souběhu vysokého počtu řízení. Má mít k dispozici:
• přehled hlavních KPIs, které zahrnují následující přehledy:
o souhrnně pro všechna probíhající řízení:
A) počet probíhajících řízení,
B) počet probíhajících řízení, která vyhovují časovému plánu (vč. dílčích milníků),
C) počet probíhajících řízení, která sice vyhovují celkovému časovému plánu (termín pro vydání rozhodnutí ještě neuplynul), avšak v dílčích milnících již časový harmonogram nebyl splněn a lze proto předpokládat, že bez zásahu (prioritního řešení) nebude splněn ani termín pro vydání rozhodnutí,
D) počet probíhajících řízení, která jsou již po termínu v celkovém čase,
E) plánovaná (teoretická) efektivita vs. skutečná efektivita, efektivita se počítá jako poměr (procento) Průběžné doby plánované a Průběžné doby skutečné (čas průběhu správního řízení od jeho počátku),
F) důvody prostojů (např. ve sloupcovém grafu), hlavní důvod vybírá zaměstnanec nebo manažer z nabídky přibližně sedmi položek číselníku důvodů prostojů a předpokládá se, že v daném okamžiku by byl „aktivní“ pouze jeden, který aktuálně způsobil zpoždění, v případě změny důvodu (např. v další etapě) by se původní zaznamenal do historie a
„aktivním“ pro zahrnutí do přehledu by se stal důvod nový,
o výše uvedená písmena souhrnně pro každý typ SŘ (příloha SŘDLP – Přehled správních řízení.xlsx – pole TYP_ŘÍZENÍ) probíhajících řízení i souhrnně za všechna probíhající správní řízení s jednoduchou volbou zahrnutých typů SŘ do přehledu;
• přehled správních řízení, ze kterého budou po grafické a obsahové stránce snadno identifikovatelné základní údaje o správním řízení (léčivý přípravek, datum zahájení, den běhu řízení), o pracovnících, kteří na daném řízení pracují (např. formou iniciál), etapy (stavu) řízení atp.;
• po rozkliknutí detailu konkrétního správního řízení má vidět podrobnější údaje o léčivém přípravku (kromě názvu, např. SUKL kód, zařazení do referenční skupiny, přidělené zaměstnance (1 až 3 osoby), podrobný průběh daného řízení (tj. budou zobrazeny chronologicky odkazy na příslušné dokumenty, které již byly ve správním řízení vydány a příslušné etapy);
• snadno dostupné je také zobrazení již dokončených správní řízení, resp. všech správních řízeních s možností filtrovat mezi nimi.
Předpokládáme, že se po zastavení kurzoru nad nějakou částí (objektem) dashboardu nebo po kliknutí na daný KPI ukazatel se manažerovi zobrazí podrobnější přehled s danou skupinou správních řízení (např. podrobnější přehled s těmito řízeními se zobrazí v případě, že manažer najede myší na počet probíhajících řízení, která nevyhovují časovému plánu). Manažer by tedy měl mít také přehled o všech správních řízeních, možnost využít řazení ve sloupcích nebo nastavit filtry, např.:
• pro zobrazení řízení v požadované fázi (např. před vydáním hodnotící zprávy, před rozhodnutím, s vydanou výzvou k součinnosti),
• pro zobrazení řízení, u kterých se blíží některý z výše uvedených termínů,
• pro zobrazení řízení, u kterých je překročen některý z výše uvedených termínů,
• pro zobrazení řízení přidělených konkrétnímu oddělení, pracovníkovi apod.
Řízení, která se blíží k termínu a zatím není splněn příslušný úkon, nebo řízení, která jsou již po splnění uvedeného termínu, by měla být v přehledu jednotlivých řízení na první pohled odlišitelná.
Podrobná analýza průběhu jednotlivých typů řízení a možných stavů bude dodavatelem zpracována v rámci etapy 1 plnění této veřejné zakázky. Pro potřeby hodnocení tohoto dílčího kritéria je možné návrh řešení dashboardu omezit na stěžejní milníky některých typů řízení vedených na oddělení KSŘ (odpovídá typu řízení MC+VaPÚ), kdy jsou milníky následující:
• Po zahájení řízení na žádost probíhá krátká validační fáze (cca 2-3 dny), během níž je zkontrolována úplnost žádosti a splnění minimálních požadavků na předložení dokumentace a uhrazení správního poplatku.
• Následuje předání spisu na oddělení KSŘ a přidělení hodnotitele OHL (viz schémata níže) – milník
10. den.
Během řízení jsou dalšími hlavními milníky kalendářní dny běhu správního řízení:
• den 60 („strategická schůzka“),
• den 75 („vydání výzvy k součinnosti“),
• den 120 („vydání hodnotící zprávy“) a
• den 165 („vydání rozhodnutí“).
Milníky jsou nastaveny předem automaticky, nicméně dané úkony je možné realizovat dříve (dřívější splnění) i později (překročení lhůty). Řízení může být v průběhu přerušeno na určitou dobu, během níž se nepočítají lhůty.
Správní řízení lze označit za dokončené v čase „vydání rozhodnutí“ – milník 165. den, kdy je vyvěšeno na úřední desce.
Manažer sleduje průběh a stavy až jednoho tisíce běžících správních řízení. Počet souběžně řešených správních řízení jednoho koordinátora (VTS nebo KSŘ) se standardně pohybuje v řádu desítek. Celkem jsou ročně vedeny stovky správních řízení (počty se mohou pohybovat až kolem 1500 za rok).
Pro představu o počtu a struktuře řešených správních řízení je vhodné využít přehled reálně vedených správních řízení z roku 2020 a části roku 2021 v anonymizované podobě, který tvoří přílohu č. 5 „SŘDLP – Přehled správních řízení.xlsx“ této zadávací dokumentace. Tento přehled může dodavatel rovněž využít jako datový základ pro vytvoření požadované vizuální prezentace navrhovaného řešení. Soubor obsahuje tyto sloupce s fiktivními hodnotami založenými na skutečných datech:
• rok zahájení správního řízení,
• fiktivní spisovou značku,
• fiktivní název léčivého přípravku (soubor může obsahovat více správních řízení s jedním léčivým přípravkem),
• typ správního řízení,
• oddělení, kterému bylo řízení přiděleno,
• koordinátor oddělení VTS nebo KSŘ (jedna osoba) (soubor může obsahovat více správních řízení přidělených jedné osobě),
• hodnotitel 1 a hodnotitel 2 spolupracujících oddělení OHL a FEA (soubor může obsahovat více správních řízení přidělených jedné osobě), přitom není striktní provázanost mezi jmény koordinátora a hodnotitelů.
Následující schémata zobrazují proces zpracování správních řízení:
Zjednodušené schéma správního řízení vedeného na oddělení KSŘ, jak bylo popsáno výše
Zahájení SŘ
Předání spisu na KSŘ a přidělení hodnotitele OHL
Postup dle schématu uvedeného níže. Schéma se může opakovat
v případě, že je třeba vydat novou hodnotící zprávu.
Procesní schéma přípravy hodnotící zprávy (odpovídá prostřednímu obdélníku zjednodušeného schématu viz výše)
Výše uvedený popis průběhu typu správního řízení a schéma jednotlivých etap platí pro výše uvedený typ správního řízení a nemusí být shodný s průběhy jiných typů správních řízení. Některé jiné typy správních řízení mají odlišný průběh, jiné požadavky na součinnost a rozsah zapojených útvarů, a také jiný počet fází i jiné množství a termíny jednotlivých milníků.
2 Identifikované požadavky
Dokument musí obsahovat vizuální prezentaci toho, jak se bude nástěnka při používání Systému zobrazovat manažerovi na monitoru. Vizuální prezentace každé obrazovky musí být dále doplněna o základní písemný popis jednotlivých zobrazovaných prvků, jejich funkcí a možností nastavení vlastností dashboardu a zobrazovaného obsahu. Musí být jasné vazby mezi vyznačenými aktivními prvky (menu, ikony, tlačítka apod.) a jednotlivými obrazovkami. Manažer, a stejně tak i pracovníci sekce, používají samostatnou obrazovku monitoru na notebooku při práci mimo kancelář nebo dva monitory v kanceláři, kde mohou současně pracovat s více dokumenty a databázemi v samostatných oknech. Vhodné proto bude představit vizuální prezentaci jak v zobrazení maximalizovaného okna nástěnky přes celou obrazovku („fullscreen“) na jednom menším displeji notebooku s případným vertikálním rozdělením okna pro zobrazení rozdílných informací (detailů), tak i pro zobrazení více oken s rozdílným obsahem současně na dvou monitorech. Detaily řízení by měly být snadno dostupné a mělo by být možné pracovat souběžně s nástěnkou i vícero „kartami“ či záložkami detailů správních řízení v jednotlivých oknech nebo mezi nimi snadno přecházet. Okna (záložky) by mělo být možné „vytáhnout“ mimo domovské okno, aby mohlo být zobrazeno na druhém z monitorů.
Manažer musí mít snadno dostupné souhrnné informace v podobě KPIs (Klíčové ukazatele výkonnosti / Key Performance Indicators) a podrobné informace o vybraném správním řízení, včetně pracovníků, kterým bylo řízení přiděleno, znázornění průběhu a plnění milníků řízení, datumů a názvů vydaných dokumentů, poznámek apod. Manažer musí mít jednoduše dostupné informace o jednotlivých přidělených správních řízeních (dále také „SŘ“) konkrétnímu pracovníkovi.
Manažer musí mít snadno dostupné souhrnné informace v podobě KPIs (Klíčové ukazatele výkonnosti / Key Performance Indicators) a podrobné informace o vybraném správním řízení, včetně pracovníků, kterým bylo řízení přiděleno, znázornění průběhu a plnění milníků řízení, datumů a názvů vydaných dokumentů, poznámek apod. Manažer musí mít jednoduše dostupné informace o jednotlivých přidělených správních řízeních (dále také „SŘ“) konkrétnímu pracovníkovi.
Manažer sleduje průběh a stavy až jednoho tisíce běžících správních řízení. Počet souběžně řešených správních řízení jednoho koordinátora (VTS nebo KSŘ) se standardně pohybuje v řádu desítek. Celkem jsou ročně vedeny stovky správních řízení (počty se mohou pohybovat až kolem 1500 za rok).
Správní řízení jsou zahajována z moci úřední nebo na žádost. Zadavatelem jsou pak tato řízení vedena (koordinována) podle svého předmětu a obsahu buďto na oddělení VTS, nebo KSŘ.
Oddělení VTS svá řízení vede po procesní i odborné stránce. Oddělení KSŘ vede odborně komplexnější správní řízení, na kterých spolupracují další oddělení, zejména oddělení OHL a FEA.
Manažerem se rozumí pracovník, který je nadřízený oběma vedoucím oddělení VTS a KSŘ. Následující schémata zobrazují proces zpracování správních řízení:
Zjednodušené schéma správního řízení vedeného na oddělení KSŘ, jak bylo popsáno výše
Předání spisu na KSŘ a přidělení hodnotitele OHL
Výše uvedený popis průběhu typu správního řízení a schéma jednotlivých etap platí pro výše uvedený typ správního řízení a nemusí být shodný s průběhy jiných typů správních řízení. Některé jiné typy správních řízení mají odlišný průběh, jiné požadavky na součinnost a rozsah zapojených útvarů, a také jiný počet fází i jiné množství a termíny jednotlivých milníků.
Podrobná analýza průběhu jednotlivých typů řízení a možných stavů bude dodavatelem zpracována v rámci etapy 1 plnění této veřejné zakázky. Pro potřeby hodnocení tohoto dílčího kritéria je možné návrh řešení dashboardu omezit na stěžejní milníky některých typů řízení vedených na oddělení KSŘ (odpovídá typu řízení MC+VaPÚ), kdy jsou milníky následující:
• Po zahájení řízení na žádost probíhá krátká validační fáze (cca 2-3 dny), během níž je zkontrolována úplnost žádosti a splnění minimálních požadavků na předložení dokumentace a uhrazení správního poplatku.
• Následuje předání spisu na oddělení KSŘ a přidělení hodnotitele OHL (viz schémata níže) – milník
10. den.
Během řízení jsou dalšími hlavními milníky kalendářní dny běhu správního řízení:
• den 60 („strategická schůzka“),
• den 75 („vydání výzvy k součinnosti“),
• den 120 („vydání hodnotící zprávy“) a
• den 165 („vydání rozhodnutí“).
Milníky jsou nastaveny předem automaticky, nicméně dané úkony je možné realizovat dříve (dřívější splnění) i později (překročení lhůty). Řízení může být v průběhu přerušeno na určitou dobu, během níž se nepočítají lhůty.
Správní řízení lze označit za dokončené v čase „vydání rozhodnutí“ – milník 165. den, kdy je vyvěšeno na úřední desce.
Manažer nástěnku využívá pro manažerskou kontrolu při plnění lhůt (milníků) a napomáhá vedoucím při určování priorit v případě souběhu vysokého počtu řízení. Má mít k dispozici:
• přehled hlavních KPIs, které zahrnují následující přehledy:
o souhrnně pro všechna probíhající řízení:
G) počet probíhajících řízení,
H) počet probíhajících řízení, která vyhovují časovému plánu (vč. dílčích milníků),
I) počet probíhajících řízení, která sice vyhovují celkovému časovému plánu (termín pro vydání rozhodnutí ještě neuplynul), avšak v dílčích milnících již časový harmonogram nebyl splněn a lze proto předpokládat, že bez zásahu (prioritního řešení) nebude splněn ani termín pro vydání rozhodnutí,
J) počet probíhajících řízení, která jsou již po termínu v celkovém čase,
K) plánovaná (teoretická) efektivita vs. skutečná efektivita, efektivita se počítá jako poměr (procento) Průběžné doby plánované a Průběžné doby skutečné (čas průběhu správního řízení od jeho počátku),
L) důvody prostojů (např. ve sloupcovém grafu), hlavní důvod vybírá zaměstnanec nebo manažer z nabídky přibližně sedmi položek číselníku důvodů prostojů a předpokládá se, že v daném okamžiku by byl „aktivní“ pouze jeden, který aktuálně způsobil zpoždění, v případě změny důvodu (např. v další etapě) by se původní zaznamenal do historie a
„aktivním“ pro zahrnutí do přehledu by se stal důvod nový,
o výše uvedená písmena souhrnně pro každý typ SŘ (příloha SŘDLP – Přehled správních řízení.xlsx – pole TYP_ŘÍZENÍ) probíhajících řízení i souhrnně za všechna probíhající správní řízení s jednoduchou volbou zahrnutých typů SŘ do přehledu;
• přehled správních řízení, ze kterého budou po grafické a obsahové stránce snadno identifikovatelné základní údaje o správním řízení (léčivý přípravek, datum zahájení, den běhu řízení), o pracovnících, kteří na daném řízení pracují (např. formou iniciál), etapy (stavu) řízení atp.;
• po rozkliknutí detailu konkrétního správního řízení má vidět podrobnější údaje o léčivém přípravku (kromě názvu, např. SUKL kód, zařazení do referenční skupiny, přidělené zaměstnance (1 až 3 osoby), podrobný průběh daného řízení (tj. budou zobrazeny chronologicky odkazy na příslušné dokumenty, které již byly ve správním řízení vydány a příslušné etapy);
• snadno dostupné je také zobrazení již dokončených správní řízení, resp. všech správních řízeních s možností filtrovat mezi nimi.
Předpokládáme, že se po zastavení kurzoru nad nějakou částí (objektem) dashboardu nebo po kliknutí na daný KPI ukazatel se manažerovi zobrazí podrobnější přehled s danou skupinou správních řízení (např. podrobnější přehled s těmito řízeními se zobrazí v případě, že manažer najede myší na počet probíhajících řízení, která nevyhovují časovému plánu). Manažer by tedy měl mít také přehled o všech správních řízeních, možnost využít řazení ve sloupcích nebo nastavit filtry, např.:
• pro zobrazení řízení v požadované fázi (např. před vydáním hodnotící zprávy, před rozhodnutím, s vydanou výzvou k součinnosti),
• pro zobrazení řízení, u kterých se blíží některý z výše uvedených termínů,
• pro zobrazení řízení, u kterých je překročen některý z výše uvedených termínů,
• pro zobrazení řízení přidělených konkrétnímu oddělení, pracovníkovi apod.
Řízení, která se blíží k termínu a zatím není splněn příslušný úkon, nebo řízení, která jsou již po splnění uvedeného termínu, by měla být v přehledu jednotlivých řízení na první pohled odlišitelná.
3 Návrh řešení Manažerského dashboardu
Aplikace má velmi pochopitelné uživatelské prostředí s rychlou učící křivkou, jak pro samotné uživatele, tak pro administrátory aplikace. Znalost různých programovacích jazyků není třeba, plně si postačí se základní znalostí IT prostředí, klávesnicí a myší. Je tedy možné velmi efektivně zajišťovat L2 podporu aplikace.
Důraz na ergonomii zpřístupňuje systém širokému okruhu uživatelů bez větších nákladů na zaškolení. Podpora všech nejpoužívanějších moderních prohlížečů zajišťuje vzájemnou komunikaci uživatelů z různých platforem (PC, Mac...) a centralizaci dat.
Pro zachováni plynulého toku procesů a jejích sledovatelnost, aplikace poskytuje integrovaný textový editor. Eliminace dodatečné komunikace prostřednictvím e-mailu nebo importem / exportem dokumentů je zárukou konzistence a udržitelnosti historie záznamů.
Produkt má velmi široké možnosti uživatelských úprav a nastavení přímo z uživatelského rozhraní (low code/no code. Pro funkce, které nelze vyřešit v uživatelském rozhraní je k dispozici plnohodnotný Javascript engine, umožňující vytvoření téměř libovolného rozšíření.
Aplikace podporuje práci s více okny, případně práci na více monitorech. Jednotliví řešitelé mohou využívat práci s okny v rámci aplikace. Na obrázku níže jsou zobrazeny dvě okna aplikace na jednom monitoru vedle sebe.
Podle velikosti pracovní plochy se obsah dynamicky přizpůsobuje (responzivní design).
Videoukázka v 0:23 - 0:56
Řízení lze zobrazit v přehledem tabulkovém pohledu, který lze uživatelsky upravit dle preferencí. Jedná se např. o jednotlivé zobrazené hodnoty (sloupce), jejich šířku nebo řazení. Data z tabulkového zobrazení lze snadno exportovat do souboru (XLSX, CSV nebo PDF).
Je možné využívat různého typu zobrazení (tabulka, graf, trend, aj.).
Filtrování:
Je možné filtrovat dle různých polí jako je název položky, žadatel, časového rozmezí, stav životního, aj. Filtry jdou ukládat pro další používání, případně je nasdílet jinému uživateli pro rychlejší komunikaci.
Seskupení požadavků:
Veškeré zobrazené požadavky lze následně seskupit podle různých kritérií (priorita, zadavatel, smluvní strana, aj.)
Vlastní (uživatelské) pohledy:
Uživatelský pohled kombinuje všechny předchozí možnosti (filtrování, seskupení nebo seřazení) v jeden pohled, který lze zapínat nebo vypínat dle aktuální potřeby daného uživatele.
Videoukázka v 1:51 – 3:02
Každé správní řízení lze zobrazit do samostatné obrazovky s více detaily. Obrazovka je rozdělena do několika částí, viz popis v obrázku.
Videoukázka v 0:58 – 1:49
Manažer má k dispozici souhrnné informace v podobě KPIs, včetně podrobného podhledu na jednotlivé správní řízení. Manažer má k dispozici sadu připravených filtrů, kde je možné sledovat:
• KPI – seznam správní řízení dle jednotlivých milníků
• Prostoj – správní řízení v prostoji s uvedením důvodu
• Pracovníci a oddělení – seskupení dle řešitelů a řešitelských oddělení
• Blížící se termín – řízení, kde hrozí překročení lhůty pro nějaký milník
• Termín vypršel – řízení, kde již vypršela celková lhůta pro řízení
• Dokončená řízení – všechna řízení, která byla zpracována. Definice jednotlivých milníků vychází z požadavků zadávací dokumentace
Definice předpisů připravených milníků.
Videoukázka v 1:01 – 1:48
V detailu správního řízení je připravený plán odbavení daného řízení dle požadavků zadávací dokumentace. Exekuční plán je možné připravit vzorově pro každý typ správního řízení v katalogu služeb (náběrový kanál pro start jednotlivých řízení).
V plánu exekuce jsou připraveny jednotlivé fáze procesu s definovanými vnitřními závislostmi, které říkají, zda stojí jednotlivé úkoly samostatně, zda čekají na splnění předchozích úkolů (předchůdci) nebo se zpracovávají paralelně s jinými úkoly.
Tento plán je vždy stejný pro daný typ řízení, ale koordinátor do něj může manuálně vstoupit a upravit jej aktuálním potřebám. Koordinátor má taktéž plnou kontrolu nad jeho průběhem, může provádět eskalační činnosti, reporting nebo manuální zásahy do již rozběhlých fází a úkolů
Videoukázka v 3:10 – 3:32
Manažerský dashboard slouží pro souhrnný přehled nad administrativou správních řízení. V rámci nabídky jsme připravili dashboard dle zadávací dokumentace, ale jeho možnosti jsou mnohem širší. Mezi jeho základní funkcionality patří:
• Definice rozložení jednotlivých grafů na obrazovce (matice lze libovolně vytvářet, až do té míry, kdy je ještě přehledný pro koncového uživatele)
• Lze vybírat typy grafů (sloupcový, spojnicový, trend, aj.)
• Pro jednotlivé metriky lze zvolit grafickou nebo tabulkovou reprezentaci
• Jednu metriku lze přidat vícekrát s různým zobrazením (např. jednou jako tabulku a podruhé jako trendový graf)
Z každé metriky se lze prokliknout do detailu a provést detailní analýzu nebo eskalaci
Jedná se o komplexní nástroj sledování dění, který v kombinaci s tabulkovými pohledy, dává ucelený a rychle získatelný přehled běžících řízení.
Videoukázka v 3:36 – 4:38
Vzhledem k tomu, že nabízíme řešení, které již existuje, jsme schopni pokrýt výrazně větší objem činností než požaduje zadání. Tyto funkcionality nejsou zahrnuty v ceně, ani nejsou nijak mandatorní pro splnění požadavků daných zadávací dokumentací. Uchazeč zde demonstruje možnosti a schopnosti jím nabízeného řešení.
Existuje široké portfolio již hotových modulů, které je možné okamžitě implementovat a začít využívat. A to bez nutnosti velkých a náročných analýz a schůzek. Moduly je možné konfiguračně upravovat dle potřeb zákazníka, případně aplikaci rozšiřovat o další funkcionality nebo i celé moduly.
FINANCE
• Budgeting a Forecasting
• Objednávky, faktury
• Nákupní košíky
HR AGENDY
• Nástupy, odchody
• Plánování směn
• Řízení zdojů
ŘÍZENÍ DOKUMENTŮ
• Aplikace pro Právní oddělení
• Dokument management system
WORKFLOW
• Práce s obecným Workflow
• Automatizační procesy
• Scriptování a paralelizace
IT AGENDA
• ServiceDesk
• Demand, Change, Test managmenet
• HW a SW Asset management
STAVBA
• Podpora a řízení výstavby
Moduly, které jsme schopni nabídnout a okamžitě začít podporovat:
• ServiceDesk
o Podporuje procesy Incident a Problem managementu
• Change management
o Proces změnových požadavků s předdefinovanými šablonami a různými fázemi procesu
o Možnost doplnit o výstavbové procesy
• Demand management
o Projektové řízení v Agilní a Waterfall verzi
o Podpora Release, Deploy managementu
• Resource and Porfolio management
o Nadstavba projektového řízení podporující využívání kapacit a zdrojů jak v IT, tak mimo něj
• Quality / Test management
o Řízený proces testování dodávek SW
• Konfigurační databáze a Asset management
o Komplexní správa zařízení a služeb, včetně skladového hospodářství a pokročilých automatizací
• CRM
o Komplexní správa zákazníků a vztahů se zákazníky
o Řízení životního cyklu smluv a objednávek s vazbou na poskytování podpory Podpůrné procesy:
• Znalostní báze
o Evidence a udržování znalostí v rámci společnosti
• Úkoly
o Řízení úkolů napříč moduly i samostatně
• Řízení zpracování dokumentů s podporou životních cyklů (Dokument management system)
o Podpora MS Office dokumentů
o Řízení rolí, viditelnosti a oprávnění
4 Přílohy
Přílohou tohoto dokumentu je videoprezentace, kde ve funkčním systému demonstrujeme splnění požadavků zadání.
Příloha č. 3 smlouvy o dílo – Seznam členů Realizačního týmu
Xxxxx a příjmení | Role | Telefon | |
XXX | XXX | XXX | XXX |
XXX | XXX | XXX | XXX |
XXX | XXX | XXX | XXX |
XXX | XXX | XXX | XXX |
XXX | XXX | XXX | XXX |
XXX | XXX | XXX | XXX |
BEZPEČNOSTNÍ PRAVIDLA PRO VÝZNAMNÉ DODAVATELE dle ZÁKONA O KYBERNETICKÉ BEZPEČNOSTI (č. 181/2014 Sb.) a
VYHLÁŠKY č. 82/2018 Sb.
1 PERSONÁLNÍ BEZPEČNOST
1.1 Smluvní partner Státního ústavu pro kontrolu léčiv (dále jen „SÚKL“) a jeho případní subdodavatelé (smluvní partner a subdodavatelé dále jen souhrnně „dodavatel“) mají povinnost ve svých interních procesech realizovat tato opatření:
a) mít stanoven vlastní plán rozvoje bezpečnostního povědomí, jehož cílem je zajistit odpovídající
vzdělávání a zlepšování bezpečnostního povědomí a který obsahuje formu, obsah a rozsah:
i. poučení uživatelů, administrátorů, osob zastávajících bezpečnostní role a dodavatelů o jejich povinnostech a o bezpečnostní politice;
ii. potřebných teoretických i praktických školení uživatelů, administrátorů a osob zastávajících
bezpečnostní role, nebo zajišťujících podporu provozu informačního systému SÚKL;
b) mít určeny osoby odpovědné za realizaci jednotlivých činností, které jsou v plánu uvedeny;
c) v souladu s plánem rozvoje bezpečnostního povědomí zajišťovat poučení uživatelů, administrátorů, osob zastávajících bezpečnostní role a dodavatelů o jejich povinnostech a o bezpečnostní politice formou vstupních a pravidelných školení;
d) pro osoby zastávající bezpečnostní role v souladu s plánem rozvoje bezpečnostního povědomí zajišťovat pravidelná odborná školení, přičemž vychází z aktuálních potřeb v oblasti kybernetické bezpečnosti;
e) v souladu s plánem rozvoje bezpečnostního povědomí zajišťovat pravidelné školení a ověřování bezpečnostního povědomí zaměstnanců v souladu s jejich pracovní náplní;
f) zajišťovat kontrolu dodržování bezpečnostní politiky ze strany uživatelů, administrátorů a osob zastávajících bezpečnostní role;
g) v případě ukončení smluvního vztahu s administrátory a osobami podílejících se na podpoře vývoje či provozu systému SÚKL či jakékoliv jeho infrastrukturní části, zajišťovat předání odpovědností, zrušení jejich přístupových účtů a informovat SÚKL o této skutečnosti;
h) stanovit interní pravidla a postupy pro řešení případů porušení stanovených bezpečnostních
pravidel ze strany administrátorů a osob zastávajících bezpečnostní role;
i) vést o provedených školeních přehledy, které obsahují předmět školení a seznam osob, které školení absolvovaly.
1.2 SÚKL si vyhrazuje právo vést záznamy a prověřovat činnosti dodavatele, vést záznamy o incidentech a nestandardních činnostech zaměstnanců a dalších osob působících ve prospěch dodavatele (dále jen „zaměstnanci dodavatele“). Na základě těchto záznamů má oprávnění vyhodnocovat důvěryhodnost a spolehlivost zaměstnanců dodavatele, zejména při situacích vzniklých bezpečnostních incidentů. V případě identifikovaného rizika oznámí SÚKL nesoulad dodavateli a obě strany vejdou v jednání pro řešení této situace.
1.3 Kvalifikace zaměstnanců dodavatele musí odpovídat vykonávané pracovní pozici (vykonávané práci a úrovni zabezpečení).
2 FYZICKÁ BEZPEČNOST, POŽÁRNÍ OCHRANA A BOZP
2.1 Dodavatel jako zaměstnavatel při provádění prací při plnění smlouvy odpovídá za dodržování předpisů BOZP a PO svými zaměstnanci v prostorách SÚKL, popř. dalšími fyzickými osobami vykonávajícími práci v jeho prospěch a odpovídá za dodržování podmínek vstupu osob a vjezdu vozidel do areálů, objektů a na pozemky SÚKL a bezpečnostního režimu pro ně stanoveného.
3 BEZPEČNOSTNÍ POVĚDOMÍ
3.1 Každý zaměstnanec dodavatele musí být prokazatelně proškolen a mít znalosti příslušných interních předpisů SÚKL souvisejících s předmětem plnění smlouvy. Za proškolení zaměstnanců dodavatele (v roli provozovatele) a za jejich prokazatelné seznámení s požadavky smlouvy a jejích příloh odpovídá dodavatel.
4 POSTUP VÝVOJE DÍLA
4.1 Dílo je vyvíjeno zásadně v odděleném vývojovém prostředí.
4.2 Před převedením do testovacího prostředí, nebo do pilotního provozu, je povinnost provést příslušné testy funkcionality a zaznamenat protokol o výsledku testu, co do rozsahu testovaných operací a průběhu testu.
4.3 Převedení díla do pilotního provozu nebo produkčního prostředí je podmíněno souhlasem
oprávněné osoby jednající ve věci smlouvy ze strany SÚKL.
5 IDENTIFIKACE
5.1 Každý zaměstnanec dodavatele podílející se na plnění smlouvy výpočetními prostředky dodavatele, musí mít v rámci své ICT infrastruktury evidován a veden svůj vlastní jedinečný uživatelský účet, kterému jsou v jednotlivých určených systémech, modulech nebo aplikacích přiřazeny specifické role. Každý zaměstnanec dodavatele musí být veden s platnými identifikačními a aktuálními kontaktními údaji. Na technická zařízení, se kterými zaměstnanci dodavatele přistupují do vymezených částí vnitřní infrastruktury SÚKL, se ze strany SÚKL pohlíží jako na BYOD a pro jejich konfiguraci se vyžaduje dodržování minima dle vnitřního předpisu SÚKL S-069, který je dodavateli předán.
5.2 Každý zaměstnanec dodavatele, pokud přistupuje k interním systémům SÚKL, má u SÚKL veden a evidován jedinečný uživatelský účet, kterému jsou v jednotlivých systémech, modulech nebo aplikacích přiřazeny specifické role související výhradně s plněním předmětu smlouvy.
6 AUTENTIZACE
6.1 Podmínky pro autentizaci při využití ICT infrastruktury SÚKL:
a) k jednoznačné identifikaci privilegovaných uživatelů určených systémů se preferovaně využívá vícefaktorová autentizace;
b) ověření heslem - pokud není možné použít jednoznačnou identifikaci privilegovaných uživatelů více faktory, je použita autentizace heslem o minimální délce 17 znaků, kdy mezi znaky musí být minimálně jedno velké písmeno, jedno malé písmeno, jedna číslice a jeden metaznak z možností: #, $, &, %, !, ?, +, - Heslo musí být měněno nejpozději po 12 / 18 měsících a nesmí se následně zopakovat v následných 12ti změnách.
6.2 Pro vzdálený přístup zaměstnanců dodavatele předkládá dodavatel podklady pro vyplnění žádosti o vzdálený přístup, podle které jsou poté nastavena oprávnění. Žádost podepisuje oprávněná osoba dodavatele jednat ve věcech plnění smlouvy.
6.3 Dodavatel odpovídá za činnosti svých zaměstnanců, popřípadě dalších fyzických osob vykonávajících práci v jeho prospěch, které musí být v souladu s pravidly, předanými ze strany SÚKL. Veškeré škody, které vzniknou porušením těchto pravidel zaměstnanci dodavatele nebo dalšími fyzickými osobami vykonávajícími práci v jeho prospěch, jdou k tíži dodavatele, který je povinen tyto škody v plném rozsahu SÚKL nahradit.
7 AUTORIZACE
7.1 Zaměstnanci dodavatele jsou povinni v ICT infrastruktuře SÚKL využívat privilegovaná oprávnění jen v přiměřené míře a jen po dobu nezbytně nutnou pro vykonání činností v souladu s plněním předmětu smlouvy. Uživatelé ani administrátoři nesmějí používat účty s privilegovanými oprávněními pro běžnou práci nesouvisející se správou určeného systému a v žádném případě nesmí umožnit pracovat pod tímto účtem jiným osobám.
7.2 Zaměstnanci dodavatele jsou informováni SÚKL, ke kterým chráněným informacím SÚKL mají při plnění smlouvy přístup a jak s nimi mohou nakládat. Tyto informace vyplývají ze smlouvy a dodavatel je oprávněn a povinen své zaměstnance s příslušnými částmi smlouvy prokazatelně seznámit. Jakékoliv manipulace a další operace s chráněnými informacemi SÚKL, které nebyly výslovně v instrukcích uvedeny, nemá dodavatel povoleny.
8 KONCOVÁ PRACOVNÍ STANICE
8.1 Pro přístup k systémům SÚKL jsou standardně použity vlastní prostředky dodavatele (HW, SW). Dodavatel odpovídá za to, že nejsou používány v rozporu s licenčními podmínkami produktů.
8.2 Přístup výpočetní techniky dodavatele (PC, notebooky) k chráněným interním informacím a k informačním a telekomunikačním systémům je podmíněn schválením příslušného pracoviště SÚKL a odpovědnou osobou systému.
8.3 Pracovní stanice dodavatele přistupující prostřednictvím VPN musí splňovat podmínky uvedené pro používání BYOD v interní směrnici SÚKL S-069.
9 UŽÍVÁNÍ KRYPTOGRAFICKÝCH PROSTŘEDKŮ
9.1 Je-li v rámci předmětu plnění vyžadováno použití kryptografických prostředků, technické podmínky jsou následující:
a) užití pouze kryptografických prostředků podle doporučení vydávaných a aktualizovaných NÚKIB
b) šifrování pomocí digitálních certifikátů vydaných obecně uznávanou CA nebo CA, které explicitně důvěřují obě strany;
c) pro webové servery prezentující data pocházející z určených informačních systémů mimo samotný systém používat HTTPS protokol;
d) pro webové servery prezentující data pocházející z určených systémů pro uživatele mimo SÚKL se používá certifikát obecně uznávané certifikační autority.
10 MONITORING
10.1 Přístup zaměstnanců dodavatele k vybraným chráněným interním informacím a k informačním a komunikačním systémům SÚKL může být nepřetržitě zaznamenáván, monitorován a vyhodnocován. Události v systémech jsou SÚKL zaznamenávány do logů.
10.2 Dodavatel je povinen průběžně monitorovat v rámci své ICT infrastruktury zveřejněné a známé bezpečnostní chyby, které mohou ovlivnit hladký a bezpečný provoz systémů souvisejících s jím poskytovanými službami. Jedná se například o zranitelnosti v operačních systémech, software třetích stran, webové komponenty atd.
10.3 V souladu s příslušnými ustanoveními smlouvy je dodavatel povinen neprodleně po zjištění
hlásit SÚKL každý nastalý bezpečnostní incident.
11 OCHRANA MÉDIÍ
11.1 Uložení chráněných informací SÚKL na přenosná média a případný transport médií mimo prostory SÚKL podléhá jeho schválení.
11.2 V případě ukládání chráněných informací SÚKL na přenosná média má dodavatel povinnost, pokud je to technicky možné, ukládat, případně vyžadovat uložení těchto dat v šifrované podobě a vést evidenci těchto médií.
11.3 Dodavatel je povinen zajistit likvidaci operativních dat obsahujících chráněné informace SÚKL ihned po pominutí účelu jejich zpracování a/nebo uložení způsobem dle právních předpisů či metodik vydaných NÚKIB, případně ÚOOÚ. Po likvidaci dat na elektronickém médiu nesmí být možné informaci obnovit. O provedení likvidace dat musí dodavatel vést protokol.
12 BEZPEČNOSTNÍ UDÁLOSTI / INCIDENTY
12.1 Dodavatel má za povinnost hlásit veškerá podezření na kybernetické bezpečnostní události:
a) odpovědné osobě SÚKL (osoba oprávněná jednat ve věcech plnění smlouvy a manager kybernetické bezpečnosti). Ohlášení provede mailem (případně telefonicky) v termínu bezprostředně (bez prodlení) po zjištění kybernetické bezpečnostní události / incidentu.
b) v ohlášení uvede:
i. datum a čas zjištění;
ii. povahu události / incidentu;
iii. zdroje události;
iv. cíle / oběti události;
v. okamžité i potencionální dopady;
vi. přijatá či navrhovaná opatření k omezení dopadů, případně eliminaci opakování.
13 AUDIT DODAVATELE (PRAVIDLA ZÁKAZNICKÉHO AUDITU)
13.1 OPRÁVNĚNÍ K PROVEDENÍ AUDITU DODAVATELE
a) SÚKL si v souladu s ustanovením smlouvy vyhrazuje právo provádět audity dodavatele.
b) SÚKL s dostatečným předstihem alespoň 5 pracovních dnů oznámí dodavateli záměr na provedení auditu. Obě strany si dohodnou obsah, potřebnou součinnost a časový plán auditu s tím, že SÚKL se zavazuje postupovat tak, aby nenarušil provozní potřeby dodavatele.
c) SÚKL si vyhrazuje právo v případě závažných důvodů (např. podezření na rizikové chování dodavatele) v souvislosti s plněním smlouvy provést neohlášený audit u dodavatele s přihlédnutím k provozní situaci dodavatele.
d) Dokumentace auditů prováděných SÚKL tvoří pro každý audit:
i. oznámení o auditu a plán auditu;
ii. dotazník k auditu (seznam otázek auditora, pokud auditor uzná za vhodné);
iii. zpráva z auditu;
iv. písemné, fotografické nebo jiné záznamy provozu, postupů nebo zařízení, které souvisí s auditem (pokud je nezbytné pro dokumentování nálezů);
v. záznam o zjištění (nápravných opatřeních a následné kontrole).
f) Auditovaná strana (dodavatel) obdrží k vyjádření závěrečnou zprávu auditu obsahující případná zjištění:
i. dodavatel navrhne na základě zjištění uvedených v závěrečné auditní zprávě návrh opatření a termíny řešení a předá jejich seznam SÚKL k odsouhlasení;
ii. SÚKL potvrdí souhlas s navrženými opatřeními. Souhlas vydává osoba oprávněná jednat ve
věcech smlouvy.
13.2 NÁPRAVNÁ OPATŘENÍ
a) Auditovaná strana (dodavatel) má za povinnost v určeném čase zajistit realizaci dohodnutých nápravných opatření;
b) Zprávu o realizovaných opatřeních dodavatel oznamuje a předává SÚKL cestou člena jeho auditního týmu.
14 PODMÍNKY PŘI UKONČENÍ SMLOUVY
14.1 V případě ukončení smluvního vztahu musí být ukončeny veškeré přístupy dodavatele a jeho zaměstnanců k aktivům společnosti (VPN, systémy, informace) nejpozději k termínu ukončení smluvního vztahu.
14.2 Pokud byla zaměstnancům dodavatele poskytnuta aktiva SÚKL, musí být tato aktiva vrácena
nejpozději k termínu ukončení smluvního vztahu.
14.3 Pokud byla dodavateli poskytnuta informační aktiva (data) SÚKL, musí být nejpozději k termínu ukončení smluvního vztahu vrácena a beze zbytku smazána způsobem určeným v právních předpisech o kybernetické bezpečnosti, či metodice NÚKIB, resp. ÚOOÚ, ze všech systémů dodavatele a nosičů dodavatele taková aktiva obsahujících. O smazání či předání takových aktiv musí být vypracován protokol, který je předán SÚKL.
14.4 V případě předčasného ukončení smluvního vztahu jiným způsobem než splněním závazku (např. výpovědí, odstoupením od smlouvy, dohodou o ukončení smlouvy apod.), mohou být přístupy dodavatele, pokud je to nutné, ze strany SÚKL ukončeny před uplynutím doby trvání smluvního vztahu.
…………………. IČ (dále jen „žadatel“) žádá o zavedení přidělení přístupu na servery SÚKL
Pro své následující zaměstnance : .........................................................................................
..........................................................................................
žádáme o přístupové oprávnění na servery:
Název serveru | IP adresa | |
za účelem plnění smlouvy .……………. ze dne ……. /objednávky .……………. ze dne …….
Přístupy k serverům lze použít pouze za uvedeným účelem. Žadatel a jeho zaměstnanci jsou povinni přístupová oprávnění chránit proti neoprávněnému použití či jakémukoliv zneužití. Současně se zavazují, že informace, se kterými se seznámí, použijí pouze k účelu, pro který jim byl přístup povolen, a nebudou je dále šířit.
Žadatel zpřístupní přístupová oprávnění pouze svým výše uvedeným zaměstnancům pověřeným prováděním činností v rámci plnění výše uvedené smlouvy / objednávky. Žadatel se zavazuje, že bude přistupovat pouze k serverům, o které požádal a pokud skončí potřeba přístupu, neprodleně o tomto SÚKL informuje. Žadatel je povinen SÚKL neprodleně informovat o skutečnosti, že zaměstnanec, kterému bylo přiděleno přístupové oprávnění, přestal pro žadatele vykonávat činnosti, pro něž mu byla přístupová oprávnění udělena. Převod přístupového oprávnění na jiného zaměstnance žadatele podléhá předchozímu schválení ze strany SÚKL, o nějž je žadatel povinen požádat novou žádostí.
Neoprávněné použití přístupových oprávnění žadatelem či jeho zaměstnancem je považováno za porušení uděleného povolení, které zakládá plnou odpovědnost za takové porušení dle platných právních předpisů.
Žadatel i jeho zaměstnanci přistupující k serverům SÚKL se zavazují k dodržování veškerých povinností vyžadovaných při ochraně osobních údajů příslušnými platnými právními předpisy, zejména Obecným Nařízením 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ů) a zákonem č. 127/2005 Sb. o elektronických komunikacích a neumožní žádné jiné osobě získat a zpracovávat takovéto údaje. V případě porušení ochrany osobních údajů je žadatel povinen neprodleně informovat písemně SÚKL odesláním informace o incidentu na adresu xxxxx@xxxx.xx. Podpisem této žádosti žadatel osvědčuje, že jeho zaměstnanci jsou plně obeznámeni s povinnostmi stanovenými v právních předpisech dle předchozí věty a že získal souhlas uvedených zaměstnanců k tomu, aby jejich zde uvedené osobní údaje byly předány SUKL a jím evidovány/zpracovávány pro účely plnění smlouvy/objednávky.
Žadatel odpovídá SÚKL za veškeré škody, způsobené porušením povinností stanovených v této žádosti či v platných právních předpisech ze strany žadatele či jeho zaměstnance. Každou takovou škodu je žadatel povinen nahradit SÚKL v plné výši.
Datum: ……………………. ……………………….……………………
Podpis
Schválil manažer bezpečnosti informací SUKL
Datum: ……………………. ……………………….……………………
Podpis
Příloha č. 6 smlouvy o dílo
Seznam oprávněných poddodavatelů
1. poddodavatel
XXX
Druh poddodávky: Služby architektury, business analýzy, kybernetické bezpečnosti, testování a dokumentace
2. poddodavatel
XXX
Druh poddodávky: Služby systémové architektury a řízení testování, případně přípravy testovacích scénářů
S-002/Příloha č. 8/str. 1 z 3/