Smlouva o DODÁVCE KOMPLEXNÍHO LÉKÁRENSKÉHO INFORMAČNÍHO SYSTÉMU uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, v platném znění (dále jen „občanský zákoník“), a dle zákona č. 121/2000 Sb., o právu autorském, o právech...
Číslo: O/…./2024/Ko
Smlouva o DODÁVCE KOMPLEXNÍHO LÉKÁRENSKÉHO INFORMAČNÍHO SYSTÉMU
uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, v platném znění (dále jen „občanský zákoník“), a dle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským, v platném znění (dále jen „autorský zákon“), mezi těmito smluvními stranami:
Apatyka servis s.r.o.
IČ: 48027821
se sídlem: ▇ ▇▇▇▇▇▇▇ ▇▇▇/▇, ▇▇▇ ▇▇ ▇▇▇▇▇ ▇▇
zastoupena: Ing. ▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇, jednatelem a Ing. ▇▇▇▇▇▇ ▇▇▇▇▇▇, prokuristou
bankovní spojení: Česká spořitelna
číslo účtu: 7671472/0800
zapsána v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C , vložka 14413,
jako poskytovatelem (dále jen „Poskytovatel“) na straně jedné
a
Fakultní nemocnice Brno
IČ: 65269705
DIČ: CZ65269705
se sídlem: ▇▇▇▇, ▇▇▇▇▇▇▇▇▇ ▇▇, PSČ 625 00
zastoupena: MUDr. ▇▇▇▇ Rovným, MBA, ředitelem
bankovní spojení: Česká národní banka
číslo bankovního účtu: 71234621/0710
FN Brno je státní příspěvková organizace zřízená rozhodnutím Ministerstva zdravotnictví. Nemá zákonnou povinnost zápisu do obchodního rejstříku, je zapsána v živnostenském rejstříku vedeném Živnostenským úřadem města Brna,
jako objednatelem (dále jen „Objednatel“) na straně druhé,
a to v následujícím znění:
Účelem této smlouvy je sjednání závazku Poskytovatele v prostředí Objednatele řádně a včas provést implementaci komplexního lékárenského informačního systému (tento informační systém včetně jeho klientských aplikací dále jen „Software“), Software v prostředí Objednatele instalovat, implementovat, konfigurovat, integrovat, zprovoznit, jakož i provést integraci Software se zařízeními specifikovanými v příloze č. 3 této smlouvy (tato zařízení dále jen „Zařízení“) a s informačními systémy třetích stran dle přílohy č. 2 této smlouvy, a Objednateli poskytnout nebo pro Objednatele zajistit práva užití k Software a poskytovat sjednané služby, to vše tak, aby Software a Zařízení tvořily jeden funkční celek zahrnující rovněž ostatní požadované integrace (tento funkční celek dále též pouze „Řešení“) a Objednatel mohl Řešení řádně a nerušeně užívat v souladu s jeho účelovým určením, touto smlouvou a zadávací dokumentací k veřejné zakázce s názvem „Komplexní lékárenský informační systém II“ (dále jen „Veřejná zakázka“ a „Zadávací dokumentace“).
Řešení je jednotou v Zadávací dokumentaci rozlišených dvou částí Řešení, a to nemocniční části Řešení (dále též jen „nemocniční část“) a veřejné části Řešení (dále též jen „veřejná část“).
Poskytovatel touto smlouvou garantuje Objednateli splnění zadání Veřejné zakázky a všech z toho vyplývajících podmínek a povinností podle Zadávací dokumentace, přičemž tato garance je nadřazena ostatním podmínkám a garancím uvedeným v této smlouvě. Ujednání této smlouvy budou vykládána tak, aby v co nejširší míře zohledňovala účel ▇▇▇▇▇▇▇ zakázky vyjádřený Zadávací dokumentací. V případě chybějících ujednání této smlouvy budou použita ustanovení Zadávací dokumentace.
Poskytnuté Řešení musí plně odpovídat Vzorku, jak je tento pojem definován v Zadávací dokumentaci, který byl součástí nabídky Poskytovatele, tj. Řešení zejména musí mít totožné funkční vlastnosti, které měl Vzorek a které byly předmětem hodnocení v rámci hodnoticích kritériích stanovených Zadávací dokumentací.
Poskytovatel je povinen poskytovat plnění sjednané v této smlouvě prostřednictvím osob, které uvedl v nabídce na Veřejnou zakázku za účelem prokázání své kvalifikace, a to na odpovídajících pozicích uvedených ve specifikaci kvalifikačních kritérií v Zadávací dokumentaci. Pro vyloučení pochybností se uvádí, že Poskytovatel je za podmínek této smlouvy oprávněn do poskytování plnění podle této smlouvy zapojit rovněž další osoby, avšak na odpovídajících pozicích musí být vždy zapojeny všechny osoby dle věty první. Poskytovatel je povinen plnění povinnosti dle tohoto odstavce Objednateli na jeho žádost kdykoli bez zbytečného odkladu prokázat. Poskytovatel je oprávněn osobu dle věty první nahradit jinou osobou, avšak vždy pouze s výslovným předchozím souhlasem Objednatele a pouze tehdy, jestliže taková osoba splňuje příslušné kritérium technické kvalifikace specifikované v Zadávací dokumentaci.
Poskytovatel bere na vědomí, že Objednatel je dle zákona č. 181/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů (dále jen „ZKB“), provozovatelem základní služby a že Objednatel identifikuje Software jako informační systém základní služby ve smyslu § 2 písm. j) ZKB. Poskytovatel v této souvislosti dále bere na vědomí, že s ohledem na jeho povinnosti sjednané touto smlouvou je v postavení provozovatele Software ve smyslu § 2 písm. g) ZKB a rovněž v postavení významného dodavatele ve smyslu § 2 písm. n) vyhlášky č. 82/2018 Sb., o kybernetické bezpečnosti (dále jen „VKB“). Poskytovatel tedy bere na vědomí, že je jakožto provozovatel Software, tj. informačního systému základní služby, povinen ve vztahu k tomuto systému plnit povinnosti vyplývající ze ZKB a VKB.
zpracovat písemný realizační projekt, který bude obsahovat v nezbytných podrobnostech zpracovanou analýzu požadavků, analýzu struktury dat, datových typů, vazeb a umístění dat ve stávajících informačních systémech Objednatele, která budou migrována do Řešení, analýzu relevantních procesů a organizační struktury Objednatele, to vše v rozsahu dle této smlouvy a dle Zadávací dokumentace a v rozsahu, ve kterém je to nezbytné pro naplnění účelu této smlouvy, a s ohledem na výsledek této analýzy detailní postup Implementace, s rozlišením nemocniční části a veřejné části a jejich vzájemných vazeb, včetně podrobného harmonogramu Implementace, požadavky na součinnost Objednatele, detailní postup Migrace, požadavky na stav testovacího a produkčního (ostrého) prostředí, harmonogram Výrobních výborů, postup a cíl konfigurace Řešení, postup a cíl Školení, postup a cíl integrace na Zařízení, jiné informační systémy Objednatele a na informační systémy třetích stran dle této smlouvy a Zadávací dokumentace, jakož i na další systémy, jejichž integrace s Řešením je pro řádné užívání Řešení v prostředí Objednatele nezbytná (vše v tomto písmeni dále jen „Realizační projekt“);
podle Realizačního projektu provést instalaci, implementaci, konfiguraci, integraci a zprovoznění Software v prostředí Objednatele tak, aby Software bylo v prostředí Objednatele plně funkční, provést integraci Software se Zařízeními, jinými informačními systémy Objednatele, informačními systémy třetích stran a dalšími systémy dle přílohy č. 2 této smlouvy tak, aby Software, Zařízení a ostatní integrované systémy tvořily jeden plně funkční celek, tj. Řešení, jakož i poskytnout veškerá další plnění nezbytná k tomu, aby Objednatel mohl i bez součinnosti Poskytovatele provádět migraci dle Exit plánu, zálohování dle Zálohovacího plánu a obnovu dle Plánu obnovy (veškeré tyto práce dále a výše jen „Implementace“);
podle Realizačního projektu provést migraci dat ze stávajících informačních systémů Objednatele do Řešení (dále a výše jen „Migrace“);
provést zápis veškerých nezbytných údajů, včetně údajů o Licenci, do příslušných informačních systémů výrobců položek Řešení a jiných třetích osob, případně včetně registrace Objednatele v takových informačních systémech, tak, aby Objednatel mohl řádně a nerušeně Software užívat a čerpat Služby (dále souhrnně jen „Registrace“);
v součinnosti s Objednatelem provést akceptační proces a úspěšné testování Software podle odst. IV.2 této smlouvy (dále též jen „Testování“);
podle Realizačního projektu zpracovat písemný migrační plán detailně popisující všechny nezbytné vlastnosti aplikačních dat zpracovávaných v Software včetně databází a konfigurací (dále souhrnně též pouze „Aplikační data“), jejich vazeb a struktury, jakož i veškeré kroky nezbytné pro export Aplikačních dat v otevřené formě a pro převedení Aplikačních dat do jiného řešení třetí strany tak, aby Objednatel mohl pomocí tohoto jiného řešení třetí strany pokračovat ve zpracovávání Aplikačních dat ve stejném rozsahu a za stejným účelem, jako tak činil pomocí Software, a to vše i bez součinnosti Poskytovatele (dále a výše jen „Exit plán“), přičemž součástí Exit plánu musí rovněž být syntaktický a sémantický popis použitých datových struktur včetně vzájemných vazeb tabulek a jiných prvků databází a ostatních datových struktur včetně popisu datových typů a kódování a detailní popis jednotlivých kroků nezbytných k provedení migrace včetně harmonogramu migrace, to vše v českém jazyce;
podle Realizačního projektu zpracovat písemný zálohovací plán, jehož účelem je v nezbytných podrobnostech popsat proces zálohování celého Software včetně Aplikačních dat s využitím zejména systému Objednatele Veeam, a to tak, aby Objednatel mohl v součinnosti s Poskytovatelem kdykoli (zejména v případě havárie) provést kompletní obnovu Software včetně Aplikačních dat (dále a výše jen „Zálohovací plán“), přičemž součástí Zálohovacího plánu musí být rovněž specifikace požadavků na kapacitu úložiště pro ukládání záloh;
podle Realizačního projektu zpracovat písemný plán kontinuity a obnovy činností (dále a výše jen „Plán obnovy“), který ve všech nezbytných podrobnostech popíše postup obnovení Řešení po jeho havárii, provozní události, kybernetické bezpečnostní události a po kybernetickém bezpečnostním incidentu a který bude dále obsahovat zejména kritéria pro aktivaci Plánu obnovy a způsob jejich vyhodnocení, seznam rolí osob, které musí být informovány v případě rozhodnutí o aktivaci Plánu obnovy, podrobný postup obnovy Řešení a jeho integračních vazeb do plného provozu včetně pořadí obnovy technologií, na kterých funkčnost a bezpečnost Řešení závisí, stanovení případných požadavků na podřízené plány obnovy, stanovení zdrojů nutných pro realizaci Plánu obnovy, jakož i stanovení postupu ověřování účinnosti Plánu obnovy;
na základě skutečného průběhu a výsledku Implementace zpracovat dokumentaci skutečného provedení Implementace Řešení, ve které bude v nezbytných podrobnostech popsán skutečný stav Řešení po provedení Implementace alespoň v rozsahu, ve kterém není popsán v Realizačním projektu (dále jen „Dokumentace skutečného provedení“), přičemž součástí Dokumentace skutečného provedení musí vždy být zpráva o průběhu Migrace (specifikující rozsah úspěšně migrovaných dat) a blokové komunikační schéma obsahující a názorně popisující a zobrazující strukturu Řešení, tj. minimálně všechny komponenty Software (minimálně v rozlišení komponent prezentačních, aplikačních a databázových) a jejich vazby, všechny integrační vazby Software na Zařízení, na informační systémy Objednatele a na informační systémy třetích stran, a to s uvedením všech relevantních parametrů těchto vazeb (podle jejich povahy komunikační protokol, port, adresa, způsob komunikace aj.), kdy výkresovou část Poskytovatel zpracuje ve vektorovém formátu PDF, VSDX, SVG nebo DRAWIO;
ve vztahu k Řešení podle Realizačního projektu provést školení administrátorů a uživatelů, a to v rozsahu minimálně 40 hodin a 5 pracovníků (dále a výše jen „Školení“).
Poskytovatel se zavazuje s odbornou péčí profesionála a za podmínek této smlouvy poskytovat Objednateli pro Řešení služby specifikované v příloze č. 4 této smlouvy (dále jen „Služby“; specifikace Služby uvedená v příloze č. 4 dále též jen „specifikace Služby“, případně dle povahy Služby „specifikace Paušální Služby“ nebo „specifikace Ad-hoc Služby“).
Poskytovatel poskytuje Objednateli k užívání veškerých součástí Řešení, které jsou autorskými díly, jakož i k dalším autorským dílům zhotoveným na základě této smlouvy nebo uvedeným v příloze č. 1 této smlouvy, nevýhradní a nevypověditelné oprávnění (licenci) je užívat všemi způsoby nezbytnými pro jejich řádné užívání dle jejich účelového určení, dle této smlouvy a Zadávací dokumentace a to, není-li v příloze č. 1 této smlouvy výslovně sjednáno jinak, bez jakéhokoli omezení, tj. zejména na celém území České republiky, bez omezení počtu užití, bez omezení počtu registrovaných uživatelů, bez omezení počtu CPU nebo jader, bez omezení počtu současně přihlášených uživatelů a na dobu trvání majetkových práv autorských (dále a výše souhrnně i jednotlivě jen „Licence“). Není-li v příloze č. 1 této smlouvy sjednáno jinak, vztahuje se Licence rovněž na veškeré nové verze (update i upgrade) součásti Řešení. Objednatel není povinen Licenci využít. Pokud jsou součástí Řešení počítačové programy třetích stran, vztahuje se Licence i na ně, a to alespoň v rozsahu, který Objednateli umožní užívat Řešení dle této smlouvy. Není-li Poskytovatel oprávněn poskytnout některou Licenci sám, je povinen ve lhůtě sjednané pro provedení Implementace Objednateli zprostředkovat uzavření licenční smlouvy o poskytnutí práv užití (licence) k příslušné součásti Řešení, a to ve stejném rozsahu a za stejných podmínek, jaké jsou v této smlouvě sjednány pro takovou Licenci (dále jen „Licenční smlouva“). Závazek Poskytovatele zprostředkovat uzavření Licenční smlouvy se považuje za splněný i uzavřením této smlouvy, je-li Poskytovatel oprávněn takto pro Objednatele zajistit uzavření Licenční smlouvy a Objednatel tím nabude práva v rozsahu odpovídající Licence. V rozsahu, ve kterém příloha č. 1 této smlouvy nestanovuje jinak, je licence poskytnutá na základě Licenční smlouvy poskytnuta ve stejném rozsahu a za stejných podmínek jako Licence k Software dle věty první. Poskytovatel je ve vztahu ke všem Licenčním smlouvám povinen hradit veškeré náklady objednatele z nich vyplývající. Počátek a doba účinnosti veškerých Licencí musí Objednateli umožňovat užívání Řešení v souladu s touto smlouvou.
Jestliže je v příloze č. 1 této smlouvy specifikována služba vztahující se k Licenci, k Software nebo k Řešení, je Poskytovatel povinen takovou službu Objednateli po dobu a za podmínek uvedených v příloze č. 1 této smlouvy poskytovat. Jestliže z povahy takové služby vyplývá, že ji poskytuje třetí osoba (např. výrobce počítačového programu), je Poskytovatel ve lhůtě sjednané pro nabytí účinnosti Licencí povinen Objednateli zprostředkovat uzavření smlouvy o poskytování takové služby v rozsahu a za podmínek vyplývajících z přílohy č. 1 této smlouvy (taková smlouva dále jen „Smlouva o poskytování služby“). Závazek Poskytovatele zprostředkovat uzavření Smlouvy o poskytování služby se považuje za splněný i uzavřením této smlouvy, pokud je Poskytovatel oprávněn takto pro Objednatele zajistit uzavření Smlouvy o poskytování Služby a Objednatel tím získá oprávnění takovou službu čerpat. Počátek a doba poskytování veškerých služeb podle tohoto odstavce musí Objednateli umožňovat užívání Řešení a čerpání těchto služeb v souladu s touto smlouvou. Pod pojmem Služby se rozumí rovněž veškeré služby podle tohoto odstavce.
Pokud jsou pro Registraci nebo oprávněné užívání kterékoli součásti Řešení nezbytný licenční/produktový klíč nebo obdobný kód (dále jen „Licenční klíč“), je Poskytovatel povinen Objednateli zpřístupnit Licenční klíč v podobě, která mu bude umožňovat časově neomezené opakované čtení Licenčního klíče v otevřené podobě, ledaže podmínky poskytnutí Licenčního klíče upravuje příslušná Licenční smlouva. Pokud je Licenční klíč uložen na hardwarovém prostředku, je Poskytovatel povinen tento prostředek s uloženým Licenčním klíčem Objednateli dodat ve lhůtě sjednané pro provedení Implementace, čímž Objednatel nabude vlastnické právo k takovému hardwarovému prostředku, ledaže je v této smlouvě nebo v odpovídající Licenční smlouvě sjednáno jinak (takový hardwarový prostředek dále jen „HW klíč“).
Veškeré Licence musí být poskytnuty nebo zajištěny v takovém rozsahu a za takových podmínek, aby Objednateli umožnily užívat Řešení dle Zadávací dokumentace a aby Objednateli umožnily Řešení implementovat a zprovoznit jak v produkčním prostředí, tak i v testovacím prostředí, které Objednateli umožní testovat prvotní implementaci i následné změny Řešení před jejich nasazením do produkčního prostředí.
Poskytovatel je k Řešení povinen Objednateli dodat veškeré návody a doklady, které se vztahují k Software, Licenci a Službám, zejména názornou uživatelskou a konfigurační dokumentaci, Dokumentaci skutečného provedení a dokumentaci požadovanou v Zadávací dokumentaci (tyto návody, doklady a dokumentace dále a výše jen „Dokumentace“). Pokud Poskytovatel provede jakoukoli změnu Řešení, včetně integračních vazeb, zejména při update, upgrade nebo úpravách provedených na základě této smlouvy, je povinen do 1 týdne od provedení takové změny, případně od její akceptace, jestliže změna akceptaci podle této smlouvy podléhá, předat Objednateli odpovídajícím způsobem aktualizovanou Dokumentaci, ledaže se smluvní strany dohodnou jinak.
Vždy, když je to pro řádný průběh Implementace nezbytné, požádá-li o to Objednatel nebo jestliže tak stanoví Realizační projekt, svolá Poskytovatel v součinnosti s Objednatelem jednání výrobního výboru, na kterém Poskytovatel seznámí Objednatele s průběhem Implementace, upřesňuje s Objednatelem Realizační projekt a umožní Objednateli udělení pokynů k dalšímu postupu při Implementaci (dále jen „Výrobní výbor“). Poskytovatel je povinen svolat nejméně jeden Výrobní výbor tak, aby se konal do 2 týdnů od nabytí účinnosti této smlouvy, přičemž součástí předmětu jednání tohoto Výrobního výboru bude obsah Realizačního projektu. Nedohodnou-li se smluvní strany jinak, probíhá Výrobní výbor vždy prezenčně na pracovišti Objednatele. Nejsou-li pokyny Objednatele udělené Poskytovateli na jednání Výrobního výboru v rozporu s touto smlouvou nebo Zadávací dokumentací, je Poskytovatel povinen se jimi řídit. Poskytovatel z každého jednání Výrobního výboru pořídí písemný zápis, který do 2 pracovních dnů od ukončení jednání předloží Objednateli k akceptaci dle této smlouvy.
Smluvní strany se na jednání Výrobního výboru mohou dohodnout na změnách již akceptovaného Realizačního projektu, které jsou pro smluvní strany závazné od okamžiku akceptace zápisu z jednání Výrobního výboru.
Jestliže je pro splnění určité povinnosti sjednané v této smlouvě nezbytná součinnost druhé smluvní strany, je tato druhá smluvní strana povinna takovou součinnost povinné smluvní straně poskytnout. V případě nedostatku této součinnosti se na dobu trvání tohoto nedostatku zastavuje běh lhůty sjednané nebo za podmínek této smlouvy stanovené pro splnění takové povinnosti, a to od okamžiku, kdy bylo druhé smluvní straně doručeno písemné oznámení povinné smluvní strany o tomto nedostatku součinnosti. Bez tohoto oznámení se běh příslušné lhůty nezastavuje. Součinnost třetích stran nezbytnou pro provedení integračních vazeb výslovně požadovaných Objednatelem touto smlouvou nebo Zadávací dokumentací je povinen zajistit Objednatel, ledaže je taková třetí strana součástí veřejné správy nebo je zdravotní pojišťovnou nebo se smluvní strany v konkrétním případě dohodnou jinak.
Po celou dobu plnění jsou smluvní strany povinny dodržovat zvláštní podmínky sjednané v příloze č. 6 této smlouvy.
Poskytovatel je povinen poskytovat Služby dle jejich specifikací uvedených v příloze č. 4 této smlouvy a za podmínek této smlouvy, a to buď jako:
paušální Služby, které je Poskytovatel povinen poskytovat průběžně bez výzvy Objednatele, ledaže je ve specifikaci Služby uvedeno, že Služba nebo její část se poskytuje na vyžádání (dále a výše jen „Paušální Služby“); nebo jako
Služby poskytované na základě požadavků Objednatele zadaných postupem dle této smlouvy (dále a výše jen „Ad-hoc Služby“).
Poskytovatel je povinen poskytovat Služby pro nemocniční část od okamžiku, kdy mu vznikne právo na vystavení faktury za fakturační milník A vymezený v Harmonogramu, do okamžiku, kdy Poskytovateli vznikne povinnost poskytovat Paušální Služby pro Řešení jako celek. Poskytovatel je povinen poskytovat Služby pro veřejnou část a pro Řešení jako celek (tj. rovněž pro nemocniční část) od okamžiku, kdy mu vznikne právo na vystavení faktury za fakturační milník B vymezený v Harmonogramu.
Pokud se na Službu dle její specifikace vztahují SLA (Service Level Agreement) parametry uvedené v příloze č. 5 této smlouvy, je Poskytovatel povinen tuto Službu poskytovat za podmínek těchto SLA parametrů. Veškerá ujednání obsažená ve specifikacích Služeb jakož i veškerá ujednání obsažená v příloze č. 5 této smlouvy jsou součástí této smlouvy.
Objednatel do 20 pracovních dnů od nabytí účinnosti této smlouvy formou dálkového přístupu zpřístupní Poskytovateli systém Helpdesk provozovaný Objednatelem na informační infrastruktuře Objednatele (dále jen „systém HelpDesk“ nebo „HelpDesk“) a Provozní deník provozovaný Objednatelem na informační infrastruktuře Objednatele, který může být součástí systému HelpDesk. Poskytovatel ve lhůtě uvedené ve větě první zpřístupní Objednateli e-mailovou adresu pro případ výpadku HelpDesku (dále též jen „náhradní e-mailová adresa“). Objednatel bude prostřednictvím Helpdesku, případně dle volby Objednatele odesláním na náhradní e‑mailovou adresu, zadávat požadavky na poskytnutí Služeb, tj. zejména Ad-hoc Služeb a Paušálních Služeb, které se poskytují na vyžádání (dále jen „Požadavky“), přičemž Požadavek se považuje za doručený Poskytovateli okamžikem jeho vložení do HelpDesku. V případě, že bude Požadavek zadán pouze odesláním na náhradní e-mailovou adresu, považuje se za doručený Poskytovateli okamžikem odeslání na náhradní e-mailovou adresu, ledaže důvody jeho nedojití Poskytovateli neleží na straně Poskytovatele. Ve lhůtě uvedené ve větě první Poskytovatel Objednateli předá rovněž telefonické číslo, jehož provoz zajišťuje Poskytovatel a které Objednateli u Služeb, které dle jejich specifikací mohou nebo mají být poskytovány po telefonu, umožní zadávat Požadavky. Telefonicky zadané Požadavky je Poskytovatel povinen bez zbytečného odkladu po jejich zadání potvrdit jejich vložením do HelpDesku.
Není-li ve specifikaci Služby uvedeno jinak, musí být řešení Požadavku zahájeno bez zbytečného odkladu. Není-li ve specifikaci Služby uvedeno jinak, musí být Požadavek vyřešen ve lhůtě bez zbytečného odkladu. Není-li ve specifikaci Služby uvedeno jinak, počínají lhůty pro zahájení řešení Požadavku a pro vyřešení Požadavku běžet okamžikem zadání Požadavku, tj. zejména zápisem Požadavku do Helpdesku.
Poskytovatel je počínaje splněním povinnosti Objednatele dle věty první odst. III.1 této smlouvy povinen s odbornou péčí průběžně a v elektronické podobě vést záznam o poskytování Služeb, do kterého zaznamenává veškeré skutečnosti významné z hlediska plnění této smlouvy a z hlediska řádného a bezpečného provozu Software, jakož i veškeré úkony prováděné v rámci poskytování Služeb včetně evidence Požadavků (dále a výše jen „Provozní deník“). Uvedené skutečnosti je Poskytovatel povinen do Provozního deníku zaznamenávat i tehdy, není-li to výslovně v této smlouvě uvedeno. Každý záznam v Provozním deníku musí být opatřen datem a časem jeho zápisu do Provozního deníku. U každého Požadavku musí být v Provozním deníku evidován alespoň jeho obsah, datum a čas jeho zadání, datum a čas zahájení řešení a datum, čas a způsob jeho vyřešení. Do Provozního deníku je Poskytovatel dále povinen průběžně a bez zbytečného odkladu zaznamenávat výskyt havarijních a nestandardních stavů Software v provozním prostředí Objednatele, vypnutí a restart Software a aktualizace Software v provozním prostředí. Pokud je Provozní deník databáze chráněná zvláštním právem pořizovatele databáze, považuje se Objednatel za jejího pořizovatele.
Není-li ve specifikaci Služby nebo v Požadavku uvedeno jinak, podléhá vyřešení Požadavku akceptaci Objednatele dle této smlouvy. Není-li sjednáno jinak, je vyřešení Požadavku akceptováno okamžikem podpisu písemného akceptačního protokolu, jiným písemným potvrzením Objednatele nebo schválením oprávněnou osobou Objednatele v systému Helpdesk. Má se za to, že ▇▇▇▇▇▇▇▇▇ je vyřešen v okamžiku jeho skutečného vyřešení, tj. do doby vyřešení Požadavku se nezapočítává doba mezi jeho skutečným vyřešením a akceptací tohoto vyřešení ze strany Objednatele.
Služby, jejichž poskytování spočívá v úpravách Software dle Požadavků Objednatele, které jsou technickým zhodnocením Software, se pro účely této smlouvy považují za služby.
Pokud při poskytování Služeb vznikne autorské dílo, poskytuje Poskytovatel Objednateli k takovému autorskému dílu oprávnění k užití, a to ve stejném rozsahu a za stejných podmínek, v jakém Poskytovatel poskytuje, případně zajišťuje, Objednateli dle této smlouvy Licenci. Pokud jsou ve specifikaci Služby stanoveny povinnosti smluvních stran, jsou smluvní stran povinny je plnit.
Objednatel na žádost Poskytovatele umožní on-line integraci systému HelpDesk Objednatele s obdobným systémem Poskytovatele pomocí REST API. Poskytovatel je povinen dodržet požadavky Objednatele na zajištění kybernetické bezpečnosti této integrace a nese veškeré náklady na tuto integraci. Pro plnění této smlouvy je rozhodné to, co je uvedeno v systému HelpDesk Objednatele.
Akceptace dokumentů, Realizačního projektu a jiných písemných plnění včetně databází. Veškeré dokumenty a jiná písemná plnění včetně databází (dále jen „dokument“ a „dokumenty“), která je Poskytovatel podle této smlouvy povinen zpracovat, doplnit či přepracovat, podléhají akceptaci Objednatele podle tohoto odstavce smlouvy, ledaže je výslovně sjednáno jinak. Bez této akceptace se dokument nepovažuje za řádně zpracovaný. Tato akceptace je sjednána takto:
Poskytovatel předloží dokument Objednateli. Jde-li o textový dokument a tato smlouva nebo Objednatel nepožadují listinnou formu, může mít dokument elektronickou formu. V rozsahu, ve kterém není v této smlouvě nebo v Zadávací dokumentaci stanoveno jinak nebo ve kterém se smluvní strany na základě této smlouvy nedohodly jinak, je Objednatel pro elektronické dokumenty oprávněn stanovit způsob doručení, míru detailu, kódování, strukturu, formát dokumentu a další jeho vlastnosti.
Objednatel k předloženému dokumentu písemnou formou buď vznese výhrady, nebo jej písemně akceptuje. V rámci těchto výhrad Objednatel specifikuje vady a nedodělky dokumentu. Jestliže je to k ověření správnosti a úplnosti dokumentu nezbytné, vždy však v případě Exit plánu a Zálohovacího plánu, ověří se jeho správnost a úplnost rovněž spuštěním příslušných funkcionalit Software, ledaže se smluvní strany dohodnou jinak.
Vznese-li Objednatel k dokumentu výhrady, je Poskytovatel povinen je v přiměřené lhůtě stanovené Objednatelem vypořádat, tj. vady a nedodělky odstranit, a dokument znovu předložit Objednateli, který je oprávněn vznášet výhrady i opakovaně. Při tomto novém předložení dokumentu se použije tento odstavec smlouvy obdobně. Počet těchto opakování není omezen.
Testování části Řešení po provedení Implementace, testování celého Řešení po provedení Implementace, akceptace změn Software včetně update a upgrade. Nestanoví-li tato smlouva nebo Objednatel písemně jinak, Řešení, část Řešení, jakékoli opravy nebo úpravy Řešení, které spočívají zejména v programátorských úpravách a doplněních a ke kterým došlo při plnění této smlouvy, včetně nových verzí Software, podléhají akceptaci, která je sjednána takto:
V rozsahu, ve kterém nejsou stanovena v Realizačním projektu, stanoví Objednatel písemně akceptační kritéria, k čemuž mu Poskytovatel poskytuje součinnost. Akceptační kritéria budou dle volby Objednatele obsahovat zejména postup provedení testu funkcionalit Software, ověření řádnosti provedení Implementace, ověření funkčnosti integračních vazeb včetně integrace na Zařízení a informační systémy třetích stran, ověření řádnosti provedení Migrace, postup provedení testu výkonnosti a stability Řešení, testu bezpečnosti Řešení případně včetně provedení bezpečnostních a penetračních testů, a metodiku vyhodnocení splnění akceptačních kritérií, ledaže Objednatel bude některé z těchto ověření s ohledem na účel konkrétního testování mít za nerelevantní. Nedohodnou-li se smluvní strany v konkrétním případě jinak, proběhne testování, tj. ověření splnění akceptačních kritérií, v testovacím prostředí. Vytvoření a provozování testovacího prostředí je součinností Objednatele, ledaže z této smlouvy nebo Zadávací dokumentace vyplývá, že za celé testovací prostředí nebo za jeho určité části odpovídá Poskytovatel. Objednatel provede za účelem prokázání splnění akceptačních kritérií testování, k čemuž mu Poskytovatel poskytuje nezbytnou součinnost. Testování je Objednatel oprávněn provádět i prostřednictvím třetích osob. Bude-li testování úspěšné, tj. bude-li prokázáno splnění všech akceptačních kritérií, provede Objednatel akceptaci podpisem písemného akceptačního protokolu nebo jiným písemným způsobem dle volby Objednatele. Nejde-li o testování celé části Řešení po provedení její Implementace ani celého Řešení po provedení Implementace poslední části, má se za to, že je úprava Řešení akceptována, pokud Objednatel neprovede testování do 1 měsíce od písemné výzvy Poskytovatele k provedení její akceptace a Objednatel v této lhůtě ani nestanoví akceptační kritéria dle věty první tohoto písmene. To neplatí, prokáže-li se, že implementace dotčené úpravy Řešení nebyla v okamžiku této výzvy byť i jen zčásti provedena.
Nebude-li testování úspěšné, tj. nebude-li prokázáno splnění všech akceptačních kritérií, je Poskytovatel povinen v přiměřené lhůtě stanovené Objednatelem odstranit veškeré vady, nedodělky a kybernetické bezpečnostní zranitelnosti zjištěné při testování a umožnit nové testování, při kterém se postupuje podle tohoto odstavce smlouvy obdobně. Počet těchto opakování není omezen. Za vady se považují i vady způsobené bezpečnostním nebo penetračním testováním, které bylo stanoveno jako součást akceptačních kritérií a provedeno za účelem ověření splnění těchto kritérií.
Poskytovatel může Objednateli písemně navrhnout, že do doby odstranění kybernetických bezpečnostních zranitelností zjištěných postupem podle tohoto odstavce zavede bezpečnostní opatření, která sníží pravděpodobnost zneužití těchto zranitelností na minimum, přičemž náklady na tato bezpečnostní opatření, nedohodnou-li se smluvní strany jinak, nese Poskytovatel. Pokud Objednatel tato bezpečnostní opatření písemně schválí, Poskytovatel je v přiměřené lhůtě stanové Objednatelem a v součinnosti s Objednatelem zavede, ověří jejich účinnost a podá o tom Objednateli písemnou zprávu. Jestliže Objednatel tato bezpečnostní opatření neschválí, je Poskytovatel povinen dotčené kybernetické bezpečnostní zranitelnosti odstranit postupem dle písm. b) tohoto odstavce. Kybernetické bezpečnostní zranitelnosti, jejichž mitigace je účelem Objednatelem schválených bezpečnostních opatření, se nadále nepovažují za důvod k neprovedení akceptace podle tohoto odstavce, avšak tyto zranitelnosti se považují za vady Řešení dle této smlouvy a vztahují se na ně povinnosti vyplývající z odst. VIII.11 této smlouvy podle lhůt sjednaných v odst. VII.3 této smlouvy; nevztahuje se na ně však ujednání odst. VIII.12 této smlouvy.
Nestanoví-li tato smlouva jinak, převede Poskytovatel příslušnou část Řešení, případně celé Řešení, z testovacího prostředí do produkčního prostředí do 1 týdne od provedení akceptace podle tohoto odstavce.
Akceptace výsledků služeb a ostatních plnění. Výsledky služeb a ostatních plnění, které je Poskytovatel povinen na základě této smlouvy poskytnout (dále v tomto odstavci smlouvy jen „plnění“), podléhají akceptaci Objednatele podle tohoto odstavce smlouvy, ledaže je výslovně v této smlouvě nebo v příslušné Smlouvě o poskytování Služby sjednáno jinak. Tato akceptace je sjednána takto:
Objednatel dle povahy plnění stanoví akceptační kritéria. Objednatel v součinnosti s Poskytovatelem ověří, zda plnění tato akceptační kritéria splňuje. Bude-li ověření úspěšné, tj. budou-li všechna akceptační kritéria splněna, Objednatel písemně plnění akceptuje.
Nebude-li ověření úspěšné, tj. bude-li některé akceptační kritérium nesplněno, je Poskytovatel povinen v přiměřené lhůtě stanovené Objednatelem odstranit veškeré vady a nedodělky a umožnit nové ověření, při kterém se postupuje podle tohoto odstavce smlouvy obdobně. Počet těchto opakování není omezen.
Místem plnění je Fakultní nemocnice Brno, Jihlavská 20, 625 00 Brno, případně i další pracoviště Objednatele dle jeho pokynů. Poskytovatel je povinen poskytovat plnění dálkovým přístupem, ledaže z této smlouvy, z Požadavku, ze zápisu z jednání Výrobního výboru nebo z povahy plnění vyplývá, že plnění má být poskytnuto osobně u Objednatele. Při poskytování plnění dálkovým přístupem je Poskytovatel povinen dodržovat podmínky stanovené Objednatelem.
Poskytovatel je povinen poskytnout sjednaná plnění dle harmonogramu, který je přílohou č. 7 této smlouvy (dále a výše jen „Harmonogram“), přičemž etapa Harmonogramu se považuje za řádně dokončenou v okamžiku, kdy Objednatel její řádné dokončení za podmínek této smlouvy akceptuje. Smluvní strany se mohou v dodatku k této smlouvě dohodnout, že konkrétní lhůta sjednaná v Harmonogramu bude delší, jestliže je to nezbytné pro řádné splnění této smlouvy.
Řádné splnění každé etapy Harmonogramu bude akceptováno písemným dílčím předávacím protokolem podepsaným oběma smluvními stranami (dále též jen „Dílčí předávací protokol“). Smluvní strany sepíšou o řádném splnění všech etap Harmonogramu písemný předávací protokol podepsaný oběma smluvními stranami (dále jen „Předávací protokol“), který se současně považuje za akceptaci splnění poslední etapy Harmonogramu. Řádným dokončením etapy Harmonogramu se rozumí řádné a bezvadné poskytnutí plnění této etapy prostého vad a nedodělků.
Není-li v Realizačním projektu uvedeno jinak, podléhá poskytnutí plnění uvedených v harmonogramu uvedeném v Realizačním projektu písemné akceptaci Objednatele. Řádným poskytnutím takového plnění se rozumí jeho řádné a bezvadné poskytnutí prostého vad a nedodělků.
Poskytovatel se zavazuje oznámit Objednateli konkrétní termín zahájení plnění dle této smlouvy pět pracovních dnů předem na Obchodní oddělení FN Brno XXXXX, tel: 532 23X XXX, a potvrdit tento termín písemně e-mailem na adresy ▇▇▇▇▇@▇▇▇▇▇▇.▇▇ a ▇▇▇▇▇@▇▇▇▇▇▇.▇▇. Totéž oznámení je Poskytovatel povinen učinit panu náměstkovi pro informatiku, XXXXX, tel: 532 23X XXX, a potvrdit písemně e-mailem na adresu ▇▇▇▇▇@▇▇▇▇▇▇.▇▇. Bez těchto oznámení není Objednatel povinen akceptovat žádné plnění.
Objednatel je povinen uhradit Poskytovateli cenu za splnění všech povinností Poskytovatele podle této smlouvy včetně odměn za poskytnutí všech Licencí (dále jen „Cena plnění“). Sjednaná Cena plnění však nezahrnuje cenu za poskytování Služeb. Sjednaná Cena plnění se sjednává jako cena pevná a konečná a činí:
-
Cena plnění bez DPH:
12 480 000 Kč
DPH [21] %:
2 620 800 Kč
Cena plnění včetně DPH:
15 100 800 Kč
v tom podle fakturačních milníků vymezených v Harmonogramu:
-
Cena plnění za fakturační milník A bez DPH:
7 909 000 Kč
DPH [21] %:
1 660 890 Kč
Cena plnění za fakturační milník A včetně DPH:
9 569 890 Kč
-
Cena plnění za fakturační milník B bez DPH:
3 330 000 Kč
DPH [21] %:
699 300 Kč
Cena plnění za fakturační milník B včetně DPH:
4 029 300 Kč
-
Cena plnění za fakturační milník C bez DPH:
1 241 000 Kč
DPH [21] %:
260 610 Kč
Cena plnění za fakturační milník C včetně DPH:
1 501 610 Kč
Cena za poskytování Paušálních Služeb pro nemocniční část se sjednává jako paušální cena za kalendářní měsíc poskytování Paušálních Služeb pro nemocniční část (dále jen „Cena za Paušální Služby pro nemocniční část“) a činí:
-
Cena za Paušální Služby pro nemocniční část bez DPH:
155 000 Kč
DPH [21] %:
32 550 Kč
Cena za Paušální Služby pro nemocniční část včetně DPH:
187 550 Kč
Pro vyloučení pochybností se uvádí, že Cenu za Paušální Služby pro nemocniční část je Poskytovatel povinen fakturovat a Objednatel povinen hradit za každý kalendářní měsíc, ve kterém je Poskytovatel povinen poskytovat Paušální Služby pro nemocniční část.
-
Cena za Paušální Služby pro celé Řešení bez DPH:
237 000 Kč
DPH [21] %:
49 770 Kč
Cena za Paušální Služby pro celé Řešení včetně DPH:
286 770 Kč
Pro vyloučení pochybností se uvádí, že ▇▇▇▇ za Paušální Služby pro celé Řešení je Poskytovatel povinen fakturovat a Objednatel povinen hradit za každý kalendářní měsíc, ve kterém je Poskytovatel povinen poskytovat Paušální Služby pro celé Řešení.
Cena za poskytování Ad-hoc Služeb, které je Poskytovatel povinen podle této smlouvy poskytovat, se hradí po jejich akceptaci, ledaže vyřešení Požadavku akceptaci podle této smlouvy nepodléhá, a určí se jako součin počtu člověkohodin skutečně spotřebovaných Poskytovatelem na vyřešení Požadavku a ceny za jednu člověkohodinu (takto spočtená cena za poskytnutí Ad-hoc Služby dále jen „Cena za Ad-hoc Službu“). Jednou člověkohodinou se rozumí práce jednoho pracovníka Poskytovatele po dobu jedné hodiny. Nejmenší účtovatelná jednotka je jedna polovina člověkohodiny. Cena za jednu člověkohodinu spotřebovanou na poskytování kterékoli Ad-hoc Služby (dále jen „Cena za člověkohodinu“) se sjednává takto:
-
Cena za člověkohodinu bez DPH:
2 990 Kč
DPH [21] %:
627,90 Kč
Cena za člověkohodinu včetně DPH:
3 617,90 Kč
Sjednaná Cena za Paušální Služby pro nemocniční část zahrnuje náklady Poskytovatele na splnění všech povinností, které mu vzniknou v souvislosti s poskytováním Paušálních Služeb pro nemocniční část, a to bez ohledu na počet zadaných Požadavků. Sjednaná Cena za Paušální Služby pro celé Řešení zahrnuje náklady Poskytovatele na splnění všech povinností, které mu vzniknou v souvislosti s poskytováním Paušálních Služeb pro celé Řešení, a to bez ohledu na počet zadaných Požadavků. Cena za Ad-hoc Služby zahrnuje náklady Poskytovatele na splnění všech povinností, které mu vzniknou v souvislosti s poskytováním Ad-hoc Služeb.
Pro vyloučení pochybností se uvádí, že všechny ceny sjednané touto smlouvou zahrnují rovněž náklady Poskytovatele spojené s opakováním akceptačních procesů bez ohledu na počet jejich opakování. Poskytovatel potvrzuje, že všechny ceny sjednané touto smlouvou zcela odpovídají nabídce Poskytovatele předložené Objednateli na základě Zadávací dokumentace. V případě rozporu mezi touto smlouvou a nabídkou Poskytovatele uhradí Objednatel ceny pro Objednatele výhodnější.
Změna kterékoli ceny sjednané v této smlouvě je možná pouze změnou této smlouvy.
O poskytování Ad-hoc Služeb a Paušálních Služeb, které se dle jejich specifikace poskytují na vyžádání, vyhotoví Poskytovatel za uplynulý kalendářní měsíc výpis z Provozního deníku, ze kterého musí být zřejmé, jaké Požadavky Objednatel v daném kalendářním měsíci zadal, kdy a jak byly vyřešeny, k jakým Službám se vztahují, jaký objem člověkohodin byl na jejich vyřešení spotřebován, ceny za jejich poskytnutí a rovněž to, zda bylo vyřešení Požadavků Objednatelem dle této smlouvy akceptováno (tento výpis dále jen „Přehled Požadavků“).
Objednatel se zavazuje hradit Cenu plnění ve třech splátkách podle fakturačních milníků A, B a C, které jsou podle jednotlivých etap specifikovány v Harmonogramu. Poskytovatel je oprávněn vystavit fakturu – daňový doklad za fakturační milník do 5 pracovních dnů po řádném splnění všech etap Harmonogramu zahrnutých do tohoto fakturačního milníku, tj. po podpisu posledního Dílčího předávacího protokolu spadajícího do tohoto fakturačního milníku oběma smluvními stranami. Poskytovatel není oprávněn vystavit tuto fakturu dříve. Splatnost faktur k fakturačním milníkům je vždy 60 dnů od data vystavení faktury. Poskytovatel doručí fakturu Objednateli bez zbytečného odkladu po jejím vystavení. Datum uskutečnění zdanitelného plnění je den podpisu posledního Dílčího předávacího protokolu oběma smluvními stranami. Faktura musí splňovat veškeré náležitosti daňového a účetního dokladu stanovené právními předpisy, zejména musí splňovat ustanovení zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „ZDPH“), a musí na ní být uvedena fakturovaná cena, rozpis fakturované ceny tak, aby byla zvlášť vyčíslena odměna za poskytnutí Licencí, je-li to relevantní, dále na faktuře musí být uvedeno označení této smlouvy a datum splatnosti v souladu s touto smlouvou. Chybí-li na faktuře kterákoli z uvedených náležitostí, je Objednatel oprávněn vrátit fakturu Poskytovateli k přepracování či doplnění. V takovém případě běží nová lhůta splatnosti ode dne doručení opravené faktury Objednateli.
Objednatel se zavazuje hradit Cenu za Paušální Služby pro nemocniční část na základě faktur – daňových dokladů vystavovaných Poskytovatelem vždy a pouze za uplynulý kalendářní měsíc, ve kterém byl Poskytovatel v souladu s touto smlouvou povinen Paušální Služby pro nemocniční část poskytovat. Poskytovatel je oprávněn vystavit fakturu nejdříve první den kalendářního měsíce následujícího po kalendářním měsíci, ke kterému se faktura vztahuje. Splatnost faktury je 60 dnů od data vystavení faktury. Poskytovatel doručí fakturu Objednateli bez zbytečného odkladu po jejím vystavení. Datum uskutečnění zdanitelného plnění je poslední den kalendářního měsíce, ke kterému se faktura vztahuje. Faktura musí splňovat veškeré náležitosti daňového a účetního dokladu stanovené právními předpisy, zejména musí splňovat ustanovení ZDPH a musí na ní být uvedena Cena za Paušální Služby pro nemocniční část, označení této smlouvy, datum splatnosti v souladu s touto smlouvou a její přílohou musí být kopie Přehledu Požadavků, jinak je Objednatel oprávněn vrátit fakturu Poskytovateli k přepracování či doplnění. V takovém případě běží nová lhůta splatnosti ode dne doručení opravené faktury Objednateli. Jestliže Poskytovatel poskytoval Paušální Služby pro nemocniční část pouze po část kalendářního měsíce, je oprávněn fakturovat pouze Cenu za Paušální Služby pro nemocniční část přiměřeně tomu sníženou.
Objednatel se zavazuje hradit Cenu za Paušální Služby pro celé Řešení na základě faktur – daňových dokladů vystavovaných Poskytovatelem vždy a pouze za uplynulý kalendářní měsíc, ve kterém byl Poskytovatel v souladu s touto smlouvou povinen Paušální Služby pro celé Řešení poskytovat. Poskytovatel je oprávněn vystavit fakturu nejdříve první den kalendářního měsíce následujícího po kalendářním měsíci, ke kterému se faktura vztahuje. Splatnost faktury je 60 dnů od data vystavení faktury. Poskytovatel doručí fakturu Objednateli bez zbytečného odkladu po jejím vystavení. Datum uskutečnění zdanitelného plnění je poslední den kalendářního měsíce, ke kterému se faktura vztahuje. Faktura musí splňovat veškeré náležitosti daňového a účetního dokladu stanovené právními předpisy, zejména musí splňovat ustanovení ZDPH a musí na ní být uvedena Cena za Paušální Služby pro celé Řešení, označení této smlouvy, datum splatnosti v souladu s touto smlouvou a její přílohou musí být kopie Přehledu Požadavků, jinak je Objednatel oprávněn vrátit fakturu Poskytovateli k přepracování či doplnění. V takovém případě běží nová lhůta splatnosti ode dne doručení opravené faktury Objednateli. Jestliže Poskytovatel poskytoval Paušální Služby pro celé Řešení pouze po část kalendářního měsíce, je oprávněn fakturovat pouze Cenu za Paušální Služby pro celé Řešení přiměřeně tomu sníženou.
Objednatel se zavazuje hradit Cenu za Ad-hoc Služby na základě faktur – daňových dokladů vystavovaných Poskytovatelem vždy za uplynulý kalendářní měsíc, ve kterém Poskytovatel v souladu s touto smlouvou Ad-hoc Služby skutečně poskytoval. Poskytovatel je oprávněn fakturovat pouze cenu za Požadavky, jejichž vyřešení bylo dle této smlouvy Objednatelem akceptováno, ledaže daný Požadavek akceptaci podle této smlouvy nepodléhá. Poskytovatel je oprávněn vystavit fakturu nejdříve první den kalendářního měsíce následujícího po kalendářním měsíci, ke kterému se faktura vztahuje. Splatnost faktury je 60 dnů od data vystavení faktury. Poskytovatel doručí fakturu Objednateli bez zbytečného odkladu po jejím vystavení. Datum uskutečnění zdanitelného plnění bude poslední den kalendářního měsíce, ke kterému se faktura vztahuje. Faktura musí splňovat veškeré náležitosti daňového a účetního dokladu stanovené právními předpisy, zejména musí splňovat ustanovení ZDPH, a musí na ní být uvedena Cena za Ad-hoc Služby včetně jejího rozepsání na jednotlivé Ad-hoc Služby (členění dle přílohy č. 4 této smlouvy), označení této smlouvy a datum splatnosti v souladu s touto smlouvou a její přílohou musí být kopie Přehledu Požadavků. Z faktury musí být zcela zřejmé, jaká cena, za jaké Ad-hoc Služby v členění dle přílohy č. 4 této smlouvy se účtuje. Jestliže se účtují Ad-hoc Služby, jejichž součástí jsou úpravy Software, které jsou technickým zhodnocením Software, musí být tato skutečnost u takových Ad-hoc Služeb na faktuře výslovně uvedena a musí být zřejmé, jaká cena za takové úpravy Software se účtuje. Pokud faktura nesplňuje kteroukoli náležitost sjednanou v tomto odstavci smlouvy, je Objednatel oprávněn vrátit fakturu Poskytovateli k přepracování či doplnění. V takovém případě běží nová lhůta splatnosti ode dne doručení opravené faktury Objednateli.
Poskytovatel může vystavit za poskytování Paušálních Služeb a Ad-hoc Služeb společnou fakturu vystavenou na souhrnnou částku, přičemž ujednání odst. VI.10, VI.11 a VI.12 této smlouvy se v takovém případě použijí obdobně. Taková společná faktura musí mít všechny náležitosti sjednané v odst. VI.12 této smlouvy a v odst. VI.10, nebo VI.11 této smlouvy, podle toho, zda se Paušální Služby fakturují pouze za nemocniční část, nebo za celé Řešení, přičemž všechny fakturované ceny na ní musí být řádně rozlišeny tak, jak jsou rozlišeny touto smlouvou, jinak je Objednatel oprávněn vrátit tuto fakturu Poskytovateli k přepracování či doplnění.
Všechny sjednané úhrady budou prováděny bezhotovostními převody z bankovního účtu Objednatele na bankovní účet Poskytovatele uvedený v záhlaví této smlouvy. Dnem úhrady se vždy rozumí den odepsání příslušné částky z bankovního účtu Objednatele.
V případě, že v okamžiku uskutečnění zdanitelného plnění bude Poskytovatel zapsán v registru plátců daně z přidané hodnoty jako nespolehlivý plátce, případně budou naplněny další podmínky § 109 ZDPH, má Objednatel právo uhradit za Poskytovatele DPH z tohoto zdanitelného plnění, aniž by byl vyzván jako ručitel správcem daně Poskytovatele, a to postupem dle § 109a ZDPH. Stejným způsobem bude postupováno, pokud Poskytovatel uvede ve smlouvě bankovní účet, který není uveden v registru plátců daně z přidané hodnoty nebo bude evidován jako nespolehlivá osoba.
Pokud Objednatel uhradí částku ve výši DPH na účet správce daně Poskytovatele a zbývající částku (tj. relevantní část bez DPH) Poskytovateli, považuje se jeho závazek uhradit cenu plnění za splněný.
Poskytovatel je oprávněn postoupit své peněžité pohledávky za Objednatelem výhradně po předchozím písemném souhlasu Objednatele, jinak je postoupení vůči Objednateli neúčinné. Poskytovatel je oprávněn započítat své peněžité pohledávky za Objednatelem výhradně na základě písemné dohody obou smluvních stran, jinak je započtení pohledávek neplatné.
Poskytovatel poskytuje Objednateli záruku za jakost zrealizovaných Požadavků a jejich výsledků, jestliže to jejich povaha dovoluje, a to po dobu platnosti smlouvy nejméně však na 12 měsíců od okamžiku jejich řádného poskytnutí (tato doba dále a výše jen „Záruční doba“). Obsahem této záruky za jakost je závazek Poskytovatele, že Služby a jejich výsledky, jejichž povaha poskytnutí záruky dovoluje, jsou způsobilé pro použití k obvyklému účelu a že si nejméně po tuto dobu zachovají své vlastnosti sjednané v této smlouvě, specifikované v jednotlivých Požadavcích a v Zadávací dokumentaci.
Objednatel je vedle práv z vadného plnění a práv vyplývajících ze sjednané nebo poskytnuté záruky za jakost oprávněn uplatňovat i jakékoliv jiné nároky související s dodáním vadného plnění (např. nárok na náhradu újmy).
Poskytovatel na vědomí, že Objednatel bude provádět testování (skenování) Řešení za účelem zjištění jeho kybernetických bezpečnostních zranitelností. Zjištěná kybernetická bezpečnostní zranitelnost se považuje za skrytou vadu Řešení, kterou je Poskytovatel povinen za podmínek této smlouvy bezplatně odstranit. Objednatel popíše zjištěnou kybernetickou bezpečnostní zranitelnost pomocí údajů z databáze CVE (Common Vulnerabilities and Exposures; dostupná z ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/), případně jiným vhodným způsobem. Závažnost takové vady Řešení (dále jen „severita“) bude ohodnocena dle standardu CVSS (Common Vulnerability Scoring System; dostupný z ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇/). Odstraněním vady dle tohoto odstavce se rozumí zejména provedení aktualizace Software nebo jiného programového vybavení nebo implementace bezpečnostního opatření, které zamezí možnosti využití zjištěné zranitelnosti, případně, nelze-li využití zjištěné zranitelnosti zcela zamezit, sníží pravděpodobnost využití zjištěné zranitelnosti na minimum. Lhůta pro zahájení prací na odstranění vady dle tohoto odstavce je 1 pracovní den od jejího oznámení Poskytovateli. Lhůta pro odstranění vady dle tohoto odstavce počíná běžet oznámením této vady Poskytovateli. Pokud je však pro odstranění takové vady nezbytná aktualizace proprietárního počítačového programu, který je součástí Řešení, vydaná výrobcem tohoto proprietárního počítačového programu, přičemž tento výrobce není totožný s osobou Poskytovatele ani není osobou ovládanou Poskytovatelem, počíná lhůta pro odstranění této vady běžet okamžikem vydání takové aktualizace. Poskytovatel je v takovém případě povinen ve lhůtě pro zahájení prací na odstranění vady zaslat tomuto výrobci písemný požadavek na vydání takové aktualizace a tento úkon ve stejné lhůtě písemně doložit Objednateli. Prodlení Poskytovatele se splněním jeho povinnosti dle věty předchozí se považuje za prodlení se zahájením prací na odstranění dotčené vady. Lhůty pro odstranění vady dle tohoto odstavce se sjednávají dle jejich severity následovně:
-
Úroveň zranitelnosti
Severita vady
Lhůta, ve které je Prodávající povinen vadu odstranit
Nízká
Menší než 4,0
2 měsíce
Střední
Větší nebo rovna 4,0 a menší než 7,0
1 měsíc
Vysoká
Větší nebo rovna 7,0 a menší než 9,0
10 pracovních dnů
Kritická
Větší nebo rovna 9,0
5 pracovních dnů
Poskytovatel se zavazuje nahradit Objednateli veškerou újmu, která mu vznikne v případě, kdy třetí osoba úspěšně uplatní autorskoprávní nebo jiný nárok vyplývající z právní vady kteréhokoli plnění, které je Poskytovatel povinen na základě této smlouvy poskytnout, včetně Licence. Pokud se prokáže, že kterékoli plnění poskytnuté Objednateli na základě této smlouvy má právní vady nebo pokud třetí osoba úspěšně vůči Poskytovateli uplatní autorskoprávní nárok ve vztahu k plnění poskytnutému na základě této smlouvy, jde o podstatné porušení této smlouvy a Poskytovatel je povinen Objednateli uhradit smluvní pokutu 500000,- (slovy: pětsettisíc korun českých) za každý takový případ.
Poskytovatel i Objednatel odpovídá dle věty první § 2950 občanského zákoníku za škodu způsobenou druhé smluvní straně neúplnou nebo nesprávnou informací, a to zejména tehdy, pokud takovou informaci poskytnul v kterémkoli dokumentu, který byl podle této smlouvy vytvořen.
Poskytovatel je povinen Objednateli uhradit jakékoli majetkové i nemajetkové újmy vzniklé v důsledku toho, že Objednatel z důvodů ležících byť i jen zčásti na straně Poskytovatele nemohl řádně a nerušeně užívat jakékoli plnění sjednané v této smlouvě.
V případě, že bude Poskytovatel v prodlení s řádným splněním kterékoli etapy Harmonogramu, je povinen uhradit Objednateli smluvní pokutu ve výši 3000,- Kč (slovy: třitisíce korun českých), a to za každý takový případ a za každý i započatý pracovní den prodlení.
V případě, že bude Poskytovatel v prodlení s řádným splněním kteréhokoli termínu harmonogramu uvedeného v akceptovaném Realizačním projektu, je povinen uhradit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých), a to za každý takový případ a za každý i započatý pracovní den prodlení.
V případě, že Řešení nebude mít veškeré funkcionality Vzorku, jejichž prostřednictvím byly splněny Modelové úlohy, jak jsou tyto pojmy definovány v Zadávací dokumentaci, předloženému v nabídce Poskytovatele v rámci zadávacího řízení na Veřejnou zakázku, nebo tyto funkcionality budou v Řešení odlišné od Vzorku, je Objednatel oprávněn požadovat po Poskytovateli smluvní pokutu ve výši 500000,- Kč (slovy: pětsettisíc korun českých). Bude-li Objednatel tuto smluvní pokutu podle věty předchozí požadovat, je Poskytovatel povinen ji Objednateli uhradit. Pro vyloučení pochybností se uvádí, že odlišnosti Řešení od Vzorku spočívající pouze ve vzhledu nebo uspořádání prvků uživatelského rozhraní ani odlišnosti Řešení od Vzorku vyplývající pouze z nutnosti zapracování Vzorku do Řešení, nezakládají samy o sobě právo Objednatele na smluvní pokutu podle věty první.
V případě, že bude Poskytovatel v prodlení se svoláním Výrobního výboru, je povinen uhradit Objednateli smluvní pokutu ve výši 3000,- Kč (slovy: třitisíce korun českých), a to za každý takový případ a za každý i započatý pracovní den prodlení.
Poruší-li některá smluvní strana povinnosti vyplývající z této smlouvy ohledně ochrany Důvěrných informací, je povinna zaplatit druhé smluvní straně smluvní pokutu ve výši 50000,‑ Kč (slovy: padesáttisíc korun českých) za každé takové porušení povinnosti.
V případě, že Poskytovatel bude zpracovávat Osobní údaje v rozporu s touto smlouvou, je povinen zaplatit Objednateli smluvní pokutu ve výši 50000,‑ Kč (slovy: padesáttisíc korun českých) za každé takové porušení povinnosti.
V případě, že bude Poskytovatel v prodlení s předáním informací dle odst. IX.5 této smlouvy, je povinen uhradit Objednateli smluvní pokutu ve výši 2000,- Kč (slovy: dvatisíce korun českých), a to za každý takový případ a za každý i započatý pracovní den prodlení.
V případě, že bude Poskytovatel v prodlení s odstraněním vad, nedodělků nebo kybernetických bezpečnostních zranitelností zjištěných během akceptačních procesů upravených v čl. IV této smlouvy, je povinen uhradit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých), a to za každý takový případ a za každý i započatý kalendářní den prodlení.
Poskytovatel se pro případ prodlení se zahájením prací na odstranění vady Řešení dle odst. VII.3 této smlouvy zavazuje uhradit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých), a to za každou takovou vadu a za každý i započatý kalendářní den prodlení. Poskytovatel se pro případ prodlení s odstraněním takové vady Řešení zavazuje uhradit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých), a to za každou takovou vadu a za každý i započatý kalendářní den prodlení.
Splatnost smluvních pokut je 21 dnů od doručení výzvy k jejich uhrazení.
Uplatněná či již uhrazená smluvní pokuta nemá vliv na uplatnění nároku smluvní strany na náhradu škody, kterou lze vymáhat samostatně vedle smluvní pokuty v celém rozsahu, tj. částka smluvní pokuty se do výše náhrady škody nezapočítává. Zaplacením smluvní pokuty není dotčena povinnost smluvní strany splnit závazky vyplývající z této smlouvy.
Objednatel se v případě prodlení s úhradou Ceny zavazuje uhradit Poskytovateli úroky z prodlení ve výši stanovené platnými právními předpisy.
Za podstatné porušení této smlouvy, které opravňuje Objednatele k odstoupení od této smlouvy, se považuje:
prodlení Poskytovatele se splněním kterékoli jeho povinnosti sjednané v této smlouvě delší než deset pracovních dnů po písemném vyzvání k nápravě;
jestliže Poskytovatel i jen dočasně poskytuje plnění podle této smlouvy v rozporu s ujednáním odst. I.5 této smlouvy;
je-li Poskytovatel v prodlení s předložením Realizačního projektu, Zálohovacího plán, Exit plánu nebo Plánu obnovy;
nebude-li Řešení splňovat kterýkoli požadavek uvedený v Zadávací dokumentaci;
nebude-li Řečení zcela odpovídat Vzorku, jak je tento pojem vymezen v Zadávací dokumentaci, předloženému pro účely hodnocení nabídky Poskytovatele v rámci zadávacího řízení na Veřejnou zakázku;
odmítne-li Objednatel akceptovat Realizační projekt, jestliže předtím již nejméně jedenkrát vznesl k předloženému Realizačnímu projektu výhrady;
odmítne-li Objednatel akceptovat Exit plán, jestliže předtím již nejméně jedenkrát vznesl k předloženému Exit plánu výhrady;
nedodržuje-li Poskytovatel některou ze zvláštních podmínek plnění smlouvy sjednaných v příloze č. 4 této smlouvy v souhrnu po dobu delší než deset dnů;
bude-li v insolvenčním řízení zjištěn úpadek Poskytovatele nebo insolvenční návrh bude zamítnut pro nedostatek majetku Poskytovatele nebo Poskytovatel vstoupí do likvidace;
Poskytovatel bude odsouzen dle zákona č. 418/2011 Sb., o trestní odpovědnosti právnických osob, ve znění pozdějších předpisů.
Odstoupí-li Objednatel od této smlouvy podle odst. VIII.16 této smlouvy, nemá Poskytovatel nárok na úhradu ani části Ceny plnění, ledaže se smluvní strany dohodnou jinak.
Odstoupení od této smlouvy ze strany Objednatele nesmí být spojeno s uložením jakékoli sankce jdoucí k tíži Objednatele.
Smluvní strany jsou si vědomy toho, že v rámci plnění závazků z této smlouvy:
si mohou vzájemně vědomě nebo opomenutím poskytnout informace, které budou poskytující stranou považovány za důvěrné (dále jen „Důvěrné informace“);
mohou jejich zaměstnanci a osoby v obdobném postavení, zejména osoby jednající z jejich pověření, získat vědomou činností druhé strany nebo i jejím opomenutím přístup k Důvěrným informacím druhé strany.
Za Důvěrné informace se vždy považují:
veškeré Osobní údaje;
informace, které jako důvěrné smluvní strana výslovně označí;
veškeré informace související se zabezpečením Důvěrných informací;
veškeré informace související s provozem a zabezpečením zdravotnických prostředků, přístrojů, počítačových programů a dalších systémů zpracovávajících Důvěrné informace; a
veškeré informace související s provozem a zabezpečením počítačových sítí a informační a komunikační infrastruktury Objednatele.
Smluvní strana, která přijala Důvěrné informace nebo které byly Důvěrné informace z jakéhokoli důvodu zpřístupněny, je povinna s odbornou péčí zachovávat jejich důvěrnost a k ochraně jejich důvěrnosti vyvíjet alespoň takové úsilí, jako by se jednalo o její vlastní důvěrné informace.
Smluvní strany se zavazují, že žádná z nich Důvěrné informace nezpřístupní třetí osobě, nezveřejní ani je neužije v rozporu s účelem této smlouvy, a to ani pro svůj vlastní prospěch. Za třetí osoby podle věty první se nepovažují zaměstnanci Objednatele. Za třetí osoby podle věty první se nepovažují poddodavatelé na straně Poskytovatele ani jiné osoby pověřené Poskytovatelem k poskytování plnění dle této smlouvy. Poskytovatel je však povinen tyto osoby zavázat k mlčenlivosti, zajišťování bezpečnosti informací a ochraně osobních údajů nejméně ve stejném rozsahu a za stejných podmínek, jako je k tomu sám zavázán podle této smlouvy. Poskytovatel je na písemnou výzvu Objednatele povinen Objednateli písemně prokázat existenci právního vztahu se třetí osobou splňujícího podmínky věty předchozí, a to do 5 pracovních dnů od doručení takové písemné výzvy s uvedením údajů nezbytných pro identifikaci této třetí osoby a pro posouzení, zda tento právní vztah splňuje podmínky této smlouvy, jakož i s uvedením zaměstnavatele takové třetí osoby, je-li to relevantní, včetně jejího jména, příjmení, pracovního zařazení, e-mailu a telefonního čísla. Poskytovatel je na písemnou výzvu Objednatele povinen Objednateli předložit seznam svých zaměstnanců s uvedením jména, příjmení, pracovního zařazení, e-mailu a telefonního čísla, kteří se podílejí na plnění této smlouvy, a to do 5 pracovních dnů od doručení takové písemné výzvy.
Smluvní strany se zavazují poučit veškeré osoby, které se na jejich straně podílejí nebo budou podílet na plnění této smlouvy, o povinnosti zachovávat mlčenlivost a chránit Důvěrné informace podle této smlouvy a právních předpisů.
Poskytovatel je povinen při poskytování plnění dle této smlouvy dodržovat zásady bezpečnosti informací a dat včetně osobních údajů, jakož i zásady ochrany osobních údajů stanovených nařízením Evropského parlamentu a Rady (EU) 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ů), včetně adaptačních právních předpisů tohoto nařízení (dále souhrnně jen „GDPR“), přičemž bezpečností informací se rozumí zajišťování důvěrnosti, integrity a dostupnosti informací.
V případě, že se strana této smlouvy dozvěděla, že došlo k narušení bezpečnosti Důvěrných informací druhé strany nebo je bezpečnost Důvěrných informací druhé strany vážně ohrožena, je povinna o takové skutečnosti druhou stranu bez zbytečného odkladu písemně uvědomit a přijmout veškerá smysluplná opatření na ochranu takových Důvěrných informací.
Žádným ustanovením této smlouvy nejsou dotčeny povinnosti Objednatele vyplývající z právních předpisů, zejména ze zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů, a ze zákona č. 340/2015 Sb., o registru smluv, ve znění pozdějších předpisů.
V případě události s dopadem na bezpečnost Osobních údajů je Poskytovatel povinen předat Objednateli bez zbytečného odkladu, nejpozději však do 12 hodin od okamžiku, kdy Poskytovatel takovou událost při poskytování plnění dle této smlouvy měl nebo mohl zjistit, veškeré Poskytovateli dostupné informace o takové bezpečnostní události.
Poskytovatel je v souvislosti s jeho povinnostmi dle této smluv povinen poskytovat Objednateli součinnost k zavádění, provádění, revidování a aktualizaci technických a organizačních opatření stanovených Objednatelem za účelem souladu zpracovávání Osobních údajů s GDPR. Jestliže vznikne v souvislosti s povinnostmi podle tohoto odstavce potřeba uzavřít dodatek k této smlouvě nebo zvláštní smlouvu, zavazuje se Poskytovatel poskytnout Objednateli veškerou součinnost nezbytnou k formulaci obsahu takového dodatku, resp. smlouvy, a k uzavření takového dodatku, resp. smlouvy v souladu se zákonem č. 134/2016 Sb., o zadávání veřejných zakázek, v platném znění (dále jen „ZZVZ“), a dalšími právními předpisy.
Jestliže ve vztahu k plněním podle této smlouvy vznikne v souvislosti se zavedením a prováděním bezpečnostních opatření podle ZKB a jeho prováděcích předpisů potřeba uzavřít dodatek k této smlouvě nebo zvláštní smlouvu, zavazuje se Poskytovatel poskytnout Objednateli veškerou součinnost nezbytnou k formulaci obsahu takového dodatku, resp. smlouvy. Poskytovatel se pro tento případ rovněž zavazuje poskytnout součinnost směřující k uzavření takového dodatku, resp. smlouvy v souladu se ZZVZ a dalšími předpisy, resp. ke své účasti v příslušném zadávacím řízení zahájeném Objednatelem.
Pokud Poskytovatel poruší svou povinnost podle tohoto čl. X smlouvy, nahradí Objednateli újmu způsobenou tímto porušením povinnosti Objednateli a újmu způsobenou tímto porušením povinnosti třetím osobám, pokud za ni Objednatel odpovídá. Pokud bude Objednateli v důsledku tohoto porušení povinnosti uložena jakákoli sankce, nahradí ji Poskytovatel Objednateli v plné výši.
Poskytovatel s ohledem na povinnosti Objednatele vyplývající zejména ze zákona č. 340/2015 Sb., zákon o registru smluv, ve znění pozdějších předpisů (dále jen „zákon o registru smluv“), souhlasí se zveřejněním veškerých informací týkajících se závazkového vztahu založeného mezi Poskytovatelem a Objednatelem touto smlouvou, zejména vlastního obsahu této smlouvy. Zveřejnění provede Objednatel. Ustanovení občanského zákoníku o obchodním tajemství se nepoužijí.
Tato smlouva nabývá účinnosti prvním dnem zveřejnění této smlouvy v registru smluv podle zákona o registru smluv. Tato smlouva se uzavírá na dobu neurčitou.
Smluvní strany jsou oprávněny tuto smlouvu kdykoli vypovědět, a to i bez udání důvodu. Výpovědní doba je 6 měsíců a počíná běžet prvním dnem kalendářního měsíce následujícího po kalendářním měsíci, ve kterém byla výpověď doručena druhé smluvní straně.
Ukončením účinnosti této smlouvy z jakéhokoli důvodu nejsou dotčena ujednání této smlouvy týkající se licencí, záruk, ochrany informací, nároků z odpovědnosti za vady, nároky z odpovědnosti za újmu a nároky ze smluvních pokut, ani další ustanovení a nároky, z jejichž povahy vyplývá, že mají trvat i po skončení účinnosti této smlouvy.
Osoby podepisující tuto smlouvu jménem Poskytovatele prohlašují, že podle stanov společnosti, společenské smlouvy nebo jiného obdobného organizačního předpisu jsou oprávněny tuto smlouvu podepsat a k platnosti této smlouvy není třeba podpisu jiné osoby.
Poskytovatel prohlašuje, že se nenachází v úpadku ve smyslu zákona
č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů, zejména není předlužen a je schopen plnit své splatné závazky, přičemž jeho hospodářská situace nevykazuje žádné známky hrozícího úpadku. Poskytovatel dále prohlašuje, že na jeho majetek nebyl prohlášen konkurs, ani mu nebyla povolena reorganizace, ani vůči němu není vedeno insolvenční řízení.
Poskytovatel prohlašuje, že vůči němu není vedena exekuce a ani nemá žádné dluhy po splatnosti, jejichž splnění by mohlo být vymáháno v exekuci podle zákona č. 120/2001 Sb., o soudních exekutorech a exekuční činnosti (exekuční řád) a o změně dalších zákonů, ve znění pozdějších předpisů, ani vůči němu není veden výkon rozhodnutí a ani nemá žádné dluhy po splatnosti, jejichž splnění by mohlo být vymáháno ve výkonu rozhodnutí podle zákona č. 99/1963 Sb., občanského soudního řádu, ve znění pozdějších předpisů, zákona č. 500/2004 Sb., správního řádu, ve znění pozdějších předpisů, či podle zákona č. 280/2009 Sb., daňového řádu, ve znění pozdějších předpisů.
Jakékoliv změny či doplňky této smlouvy lze činit pouze formou písemných číslovaných dodatků podepsaných oběma smluvními stranami. Odstoupení od této smlouvy lze provést pouze písemnou formou.
Tato smlouva je sepsána ve třech vyhotoveních stejné platnosti a závaznosti, přičemž Poskytovatel obdrží jedno vyhotovení a Objednatel obdrží dvě vyhotovení. Pokud je tato smlouva podepsána elektronicky uznávaným elektronickým podpisem, obdrží každá smluvní strana kopii elektronického originálu této smlouvy.
Nedílnou součástí této smlouvy jsou:
Příloha č. 1: Specifikace Řešení;
Příloha č. 2: Požadavky na integraci s informačními systémy třetích stran;
Příloha č. 3: Koncová zařízení
Příloha č. 4: Specifikace Služeb;
Příloha č. 5: SLA parametry některých Služeb;
Příloha č. 6: Zvláštní podmínky plnění;
Příloha č. 7: Harmonogram.
Smluvní strany prohlašují, že se důkladně seznámily s obsahem této smlouvy, kterému zcela rozumí a plně vyjadřuje jejich svobodnou a vážnou vůli.
-
V Praze dne
V Brně dne
Apatyka servis s.r.o.
▇▇▇. ▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇, jednatel
▇▇▇. ▇▇▇▇ ▇▇▇▇▇, prokurista
Fakultní nemocnice Brno
MUDr. ▇▇▇ ▇▇▇▇▇, MBA, ředitel
PŘÍLOHA Č. 1
Specifikace Řešení
Předmět veřejné zakázky
Předmětem zadávací dokumentace je dodání, implementace a servisní podpora softwarového řešení pro provoz komplexního lékárenského systému, který musí obsahovat funkcionalitu pro provoz jak lékárny pro veřejnost včetně distribučních skladů, tak funkcionalitu pro provoz nemocniční části lékárny (žádankový systém – objednávání po síti, laboratoře, příruční sklady, konsignační sklady, cytostatická příprava, parenterální výživa).
Zadavatel požaduje plnění veřejné zakázky ve 2 etapách. První etapou bude implementace nemocniční části (žádankový systém pro klinická pracoviště a lékárnu, laboratoře, příruční sklady, konsignační sklady, cytostatická příprava, parenterální výživa), druhou etapou bude implementace veřejné části.
Dodavatel potvrzuje výše uvedené a doplňuje, že nabízené řešení popisuje formou doplňujících komentářů do Technické specifikace Řešení, která byla přílohou Zadávací dokumentace. Exaktní popis Řešení dodavatel dodá v Realizačním projektu.
Obsah
I. Účel smlouvy a úvodní ustanovení 2
IV. Akceptační procesy a provádění změn 7
VI. Cena plnění a platební podmínky 9
VII. Kvalita a odpovědnost za vady 13
VIII. Sankce a odstoupení od smlouvy 14
X. Ochrana osobních údajů a kybernetická bezpečnost 17
1.1 Požadavky na dokumentaci 23
1.2 Obecné požadavky na dodávané řešení 24
1.4 Implementační a provozní požadavky 30
1.7 Školení uživatelů a administrátorů 37
2.1 Požadavky společné pro nemocniční a veřejnou část řešení 38
2.1.2 ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ a jiné vztahy 40
2.1.6 Příprava léčiv (příprava magistraliter) 45
2.1.7 Příprava podkladů pro fakturaci zdravotním pojišťovnám 47
2.1.8 Požadavky na integraci, údržbu a aktualizaci číselníků 48
2.1.9 Podklady pro účetnictví 49
2.1.11 Požadavky na další funkčnosti 53
2.2.4 Evidence podání léčiv a výkaznictví 66
2.3.2 Pokladna, pokladní deník 70
2.3.4 Požadavek na odesílání dat SÚKL 71
3.1 Zadavatel: ▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇▇ ▇▇
3.3 Informační systémy, infrastruktura a technologie 74
3.3.1 Současný stav informačních a komunikačních technologií dotčených projektem 74
3.3.2 Objemy zpracovávaných dat 75
3.3.3 Počet uživatelů, stanic 76
3.3.4 Datová centra, HW infrastruktura a technologie 76
Seznam tabulek
Tabulka 1: Seznam zkratek a pojmů 23
Tabulka 2: Současný stav informačních a komunikačních technologií 75
Seznam zkratek a pojmů
Zkratka/pojem |
Význam |
AD |
Active Directory |
AISLP |
Automatizovaný informační systém léčivých přípravků |
APA |
Jednotný systém číslování přípravků obchodovaných v síti lékáren (prostá číselná řada) |
ARES |
Administrativní registr ekonomických subjektů |
ATB |
Antibiotikum |
ATC |
Anatomicko-terapeuticko-chemická klasifikace léčiv |
AUC |
Area under curve |
B2B |
Umožňuje přímou komunikaci s informačním systémem VZP |
BMI/BSA |
Body mass index/Body surface area |
CD |
Compact Disc (kompaktní disk) |
CL |
Cytotoxická léčiva |
CSV |
Comma-separated values - formát souboru |
CT |
Cytotoxická terapie |
CÚeRp |
Centrální úložiště elektronických receptů |
CYTO |
Cytostatika |
DB |
Databáze |
DDHM |
Drobný dlouhodobý hmotný majetek |
DG |
Diagnóza |
DL |
Dodací list |
DLP |
Databáze léčivých přípravků |
DMZ |
Demilitarizovaná zóna datové sítě oddělená firewallem |
DPH |
Daň z přidané hodnoty |
DVD |
Digital Video Disc (formát digitálního optického datového nosiče) |
EAN |
European Article Number - číselné označení sloužící k jednoznačné identifikaci odběrného místa |
eIDAS
|
Evropský standard pro elektronickou komunikaci |
EMVS |
European Medicines Verification System |
ERP |
Enterprise Resource Planning (plánování podnikových zdrojů - podnikový informační systém) |
eRP |
Elektronický recept |
ESB |
Enterprise Service Bus výrobce InterSystems |
EU |
Evropská unie |
FDAVKA |
Faktura za dávku na pojišťovnu |
FEFO |
First Expired First Out - metoda řízení toku zásob |
FIFO |
First In First Out - metoda řízení toku zásob |
FMD |
Falsified Medicine Directive tzv. Protipadělková směrnice |
FN |
Fakultní nemocnice |
GDPR |
General Data Protection Regulation (obecné nařízení o ochraně osobních údajů) |
GTIN |
Global Trade Item Number |
HVLP |
Hromadně vyráběný léčivý přípravek |
HW |
Hardware |
IČP |
Identifikační kód pracoviště |
IČZ |
Identifikační kód zařízení |
IDM |
Identity Management na platformě InterSystems |
IPLP |
Individuálně připravované léčivé přípravky |
IS |
Informační systém |
ISDOC |
Information Systém Document (standard pro elektronickou fakturaci) |
IT |
Informační technologie (v kontextu též oddělení Informačních technologií) |
KDAVKA |
Dávka na pojišťovnu |
KIVS |
Komunikační infrastruktura veřejné správy, zajišťující bezpečný přenos dat |
KLK |
Seznam léčivých přípravků registrovaných v ČR, léčivých přípravků, pro něž byl schválen specifický léčebný program |
KS |
Konsignačnísklad |
LAN |
Local Area Network (lokální síť, místní síť) |
LeIS |
Lékárenský informační systém, tj. informační systém, jehož dodávka je předmětem této veřejné zakázky |
LP |
Léčivý přípravek |
MDR |
Medical Device Regulation (Nařízení o zdravotnických prostředcích) |
MF |
Ministerstvo financí |
MIS |
Manažerský informační systém výrobce ICZ a.s. |
MKN |
Mezinárodní klasifikace nemocí |
MPI |
Master pacient index |
MS |
Microsoft |
NIS |
Nemocniční informační systém AMIS*H a AMIS*HD výrobce ICZ a.s. |
NL |
Nemocniční lékárna |
NLEKY |
Databáze nemocničních léčivých přípravků |
NS |
Nákladové středisko |
NSOL |
Národní systém ověřování léčiv |
OaPL |
Omamná a psychotropní látka |
OS |
Operační systém |
OSEIS |
Oddělení správy ekonomických informačních systémů |
Portable Document Format - formát souboru |
|
PDK |
PharmData kód (jednotný systém číslování přípravků obchodovaných v síti lékáren s využitím čárového kódu) |
PDP |
Přenesená daňová povinnost |
PL |
Pozitivní list |
PLP |
Plán léčby pacienta |
PP |
Připravovaný přípravek |
PZT |
Prostředky zdravotické techniky |
RČ |
Rodné číslo |
RFID |
Radio Frequency Identification (identifikace zboží, navazující na systém čárových kódů) |
RCH |
Reverse charge |
RLPO |
Registr léčivých přípravků s omezením |
SCAU |
Seznam cen a úhrad léčivých přípravků |
SLA |
Service-level agreement (smlouva sjednaná mezi poskytovatelem služby a jejím uživatelem) |
SLO |
Single LogOut (mechanismus pro odhlášení uživatele) |
SMS |
Short message service (textová zpráva) |
SNMP |
Simple Management Protocol (sada programů pro správu sítě) |
SQL |
Structured Query Language - standardizovaný strukturovaný dotazovací jazyk |
SSO |
Single Sign-On (mechanismus pro jediné přihlášení) |
SÚKL |
Státní ústav pro kontrolu léčiv |
SW |
Software |
TIS |
Transfúzní informační systém |
TL |
Taxa laborum |
UDI |
Unique Device Identification |
UTM |
Univerzální transverzální Mercatorův systém souřadnic |
ÚZIS |
Ústav zdravotnických informací a statistiky ČR |
VŘ |
Výběrové řízení |
VZP |
Všeobecná zdravotní pojišťovna |
XLSX |
Soubor Microsoft Excel |
XML |
Extensible Markup Language (obecný značkovací jazyk) |
ZM |
Zdravotnický materiál |
ZP |
Zdravotní pojišťovna |
ZULP |
Zvlášť účtované léčivé přípravky |
ZUM |
Zvlášť účtovaný materiál |
Tabulka 1: Seznam zkratek a pojmů
Popis realizace integračních vazeb na IS a technologie třetích stran (aplikační software, databáze a technologie), tj. kompletní komunikační rozhraní dodávaného Řešení, přes Integrační platformu až k cílovému IS a to v obou směrech a to včetně vzorových příkladů.
Zadavatel požaduje zpracování dokumentace skutečného provedení, systémové a provozní dokumentace – součástí předmětu plnění je zajištění systémové a provozní dokumentace související s realizací předmětu plnění minimálně v následujícím rozsahu:
-
Název
Popis
Uživatelská dokumentace
Bude popisovat konkrétní funkčnost z pohledu uživatele tak, aby byl uživatel schopen práce s informačním systémem a pochopil význam jednotlivých částí systému a vazeb mezi nimi. V uživatelské příručce bude popisován způsob práce s jednotlivými částmi systému, vazby mezi nimi včetně popisu součástí jednotlivých částí systému. K usnadnění práce bude sloužit popis jednotlivých obrazovek, ovládacích prvků na obrazovkách a jejich významů, který bude uveden v rámci uživatelské dokumentace.
Dokumentace skutečného provedení a systémová/provozní dokumentace
Obsahuje popis informačního systému (rozhraní a služby) včetně popisu správy informačního systému (spuštění a ukončení chodu systému, instalace a konfigurace systému nebo jeho částí), včetně integračních vazeb, definování uživatelů, jejich oprávnění a povinností a detailní popis údržby systému. Dokumentace bude ve formě výčtu v textovém popisu, tak ve formě grafického diagramu (v MS Visio či jiných obdobných). Popisy budou obsahovat minimálně používané protokoly a čísla komunikačních portů na obou stranách.
Bezpečnostní dokumentace
Účelem bezpečnostní dokumentace je definovat závazná pravidla pro zajištění informační bezpečnosti včetně stanovení bezpečnostních opatření. Součástí této dokumentace bude seznam, který bude obsahovat seznam všech externích zdrojů, ke kterým se jednotlivé servery (součásti systému) připojují, včetně uvedení síťových protokolů, pomocí kterých se s daným externím zdrojem komunikuje. V případě, že na servery (součásti systému) existuje vzdálený přístup, musí být tento přístup jasně specifikován (vzdálené zařízení, síťový protokol) a popsáno zdůvodnění takovéhoto přístupu (dohled, správa DB atd.)
Dokumentace bude dodána v relevantním rozsahu na všechna místa plnění projektu.
Dokumentace bude v souladu se zákonem č. 365/2000 Sb. o informačních systémech veřejné správy a prováděcích právních předpisů, v platném znění.
Dokumenty budou zpracovávány v následujících programech elektronicky a uloženy v následujících formátech:
MS Office 2016 (MS Word 2016, MS Excel 2016)
Portable Document Format (formát .pdf).
K předávání
a
k archivaci souborů se používají média s možností
pouze zápisu, nikoliv přepisovatelná.
Veškerá dokumentace bude podléhat schvalování (akceptaci) při převzetí ze strany zadavatele.
Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích v elektronické formě ve standartních formátech (MS Office a PDF) používaných objednatelem na datovém nosiči a 1x kopii v papírové formě.
Vyjádření dodavatele: dodavatel souhlasí s výše uvedeným požadavkem zadavatele.
V této kapitole jsou uvedeny základní (minimální) požadavky na požadované řešení (dále též „systém“):
# |
Požadavek |
|
|
Řešení bude v souladu s platnou legislativou a legislativou uvedenou v části Výchozí stav – Legislativní rámec. IS Mediox (dále jen “IS” nebo “Mediox”) je udržován v souladu s platnou legislativou. |
|
|
Systém musí svojí architekturou splňovat obecné zásady informační bezpečnosti v míře, odpovídající charakteru užití a kategorii zpracovávaných dat (GDPR). IS splňuje zásady informační bezpečnosti v souladu s GDPR. |
|
|
Dodávaný systém musí být přehledný, logicky členěný a srozumitelný (user friendly). Systém musí obsahovat interaktivní nápovědu. IS je logicky členěný, srozumitelný včetně nápovědy. |
|
|
Systém musí obsahovat uživatelskou a administrátorskou příručku v elektronické podobě vždy v aktuální platné verzi s vazbou na aktuální verzi systému. IS má k dispozici manuály, aktuální změny jsou doplňovány. |
Moderní dlouhodobě perspektivní komerčně dostupný systém. |
|
|
|
Řešení musí být založené na současných obecně dostupných a moderních technologiích a standardech s perspektivou rozvoje a podpory min. 10 let. Systém tedy nesmí vyžadovat ke své funkci žádnou technologii (včetně softwarových), o které je v době podání nabídky známo, že již není podporována nebo že bude podporována již jen po dobu kratší než 10 let. |
|
|
V rozsahu, ve kterém Řešení používá technologii webového klienta, bude založené na principech responzivního designu pro optimální zobrazení na různých typech zařízení (PC, tablet, mobilní telefon). |
|
|
Řešení těžké klientské aplikace musí podporovat práci na zařízeních ve standardním prostředí MS Windows a práci s dotykovými zařízeními v těch částech Řešení, která jsou určena pro mobilní zařízení. |
|
|
Zaručená perspektiva rozvoje a podpory je minimálně po dobu dalších 10 let od uvedení do provozu v rámci celé FN Brno. P.5 - P.8 IS je dlouhodobě vyvíjen interním týmem od roku 2004 a je provozován několik let v podobných zařízeních viz reference. Jsou použity technologie, u kterých lze předpokládat další vývoj a podporu vývojových komponent po dobu delší, než je požadovaná. Základním prostředím pro těžkého klienta je MS Windows včetně podpory práce s dotykovou obrazovkou. Části aplikace běžící jako webový klient je možné provozovat na různých zařízeních s přizpůsobením pro tyto zařízení. |
|
|
Podpora ze strany dodavatele
|
Systémové požadavky |
|
|
|
Řešení musí mít aplikační rozhraní (API) pro integraci s informačními systémy zadavatele neuvedenými v této zadávací dokumentaci a s informačními systémy třetích stran neuvedenými v příloze č. 4 této zadávací dokumentace, přičemž součástí Dokumentace musí být úplný popis tohoto API v českém jazyce v podrobnosti, která zadavateli umožní tuto integraci. Pro citlivá data zadavatel požaduje protokol SOAP, pro ostaní data je možné použít protokol REST. Komunikace se systémy třetích stran po konkrétním zadání ze strany zadavatele jsme připraveni zpracovat technologií API buď SOAP nebo REST. Bude zařazeno do realizačního projektu. |
|
|
Komunikace mezi serverovou a klientskou vrstvou bude probíhat v šifrované podobě. ANO, HTTPS. |
|
|
Všechny části systému musí být modulárně koncipované a navzájem integrované. ANO, všechny části systému jsou navzájem provázané, konfigurovatelné, komunikují s uživatelem v českém jazyce. |
|
|
Musí disponovat plnohodnotným grafickým uživatelským rozhraním. ANO, disponuje grafickým uživatelským rozhraním. |
|
|
Musí být na klientské stanici bezinstalační, a to jak u těžkého, tak u tenkého klienta. Zadavatel tedy požaduje tzv. portable řešení těžkého klienta. ANO, těžký klient je pouze zástupce. Tenký klient odkaz na URL adresu. |
|
|
Distribuce, spuštění a aktualizace klienta, jak těžkého, tak I tenkého, na klientské stanici musí být plně automatická, bez zásahu obsluhy, a to i bez administrátorských práv do Windows. ANO, probíhá dle požadavku. |
|
|
Řešení musí zajistit zobrazení informací o provedené aktualizaci uživateli. ANO, uživatel je informován v tzv. Info kanálech IS. |
|
|
Musí umožňovat autentizace uživatele s využitím technologie Single Sign On (SSO). ANO, IS disponuje SSO. |
|
|
Musí umožňovat odhlášení uživatele s využitím technologie Single LogOut (SLO). Nutno naprogramovat jako novou funkčnost tak, aby uživatel při nečinnosti dle paramatru se musel opětovně přihlásit byť aplikace běží z důvodu konzistence rozpracované úlohy. |
|
|
Systém musí být schopen provádět úkony údržby (archivace dat, správa číselníků) za nepřetržitého provozu a v čase voleném zadavatelem. ANO, systém provádí aktualizaci číselníků a zálohy za nepřetržitého provozu. |
|
|
Nabízené Řešení musí umožňovat správcům systému na straně zadavatele přímý přístup k databázi za účelem získávání dat pomocí standardních nástrojů konkrétního databázového stroje (alespoň psaní vlastních SQL dotazů). ANO, lze provádět standardními nástroji k databázi. |
|
|
Uchazeč poskytne popis struktury databáze včetně popisu jednotlivých tabulek a vazeb mezi nimi. Součástí dokumentace v rámci realizace smlovy o dílo. |
|
|
Celé Řešení musí být za účelem zajištění konzistence dat a minimalizace časových prodlev postaveno nad jedním systémem řízení báze dat, tzv. databázovým strojem. Systém je postaven na databázové technologii MS SQL Server. Pro tenké klienty jsou cache informace zrcadlené v oddělené databázi MySQL. Účelem je odlehčení systému a podpora vícevrstvé architektury, při zpřístupnění řešení třetích stran (např. Integrace žádankových modulů jiných dodavatelů).
|
Uživatelské prostředí (Grafické prostředí) |
|
|
|
Uživatelské prostředí klienta (težký i tenký) musí být provozovatelné v prostředí Microsoft Windows. ANO, IS je provozován v prostředí Windows. |
|
|
Systém musí poskytovat jednotné uživatelské prostředí pro všechny uživatele těžkého klienta bez nutnosti přepínat mezi více informačními systémy. Systém musí poskytovat jednotné uživatelské prostředí pro všechny uživatele tenkého klienta bez nutnosti přepínat mezi více informačními systémy. ANO, IS splňuje dle požadavku. |
|
|
Možnost ovládání klientů pomocí klávesových zkratek, minimalizace nutnosti použití myši. U těžkého klienta musí být možné pomocí klávesových zkratek ovládat funkcionality označené za tímto účelem v Realizačním projektu. ANO, IS lze ovládat i pomocí klávesových zkratek. Zkratky jsou popsány v dokumentaci. |
|
|
Řešení musí umožňovat plnotextové vyhledávání napříč jednotlivými moduly a sklady, a to bez ohledu na diakritiku a s možností využití základních logických operátorů AND a OR. IS Mediox obsahuje rozsáhlý modul filtrů, které umožňují jak operace AND a OR tak i výběry seznamů, či negaci. Současně s tím je podporováno vyhledávání dle pravidel MS SQL Server. |
|
|
Možnost filtrování a řazení tabulek uložených v databázové vrstvě dle zvolených kritérií. IS disponuje nástrojem “filtr” kde je možné zadat kombinaci různých výběrových kritérií pro vyhledávání. Filtr je použit napříč moduly, kritéria jsou automaticky přizpůsobována kontextově dle daného modulu. |
|
|
Fulltextové vyhledávání ve všech částech Řešení, a to bez ohledu na diakritiku a s možností využití základních logických operátorů AND a OR. Viz P.26 |
|
|
Textový editor - používání uživatelem předdefinovaných textů s možností vkládání pomocí klávesových zkratek, tj. možnost ke každému předdefinovanému textu uživatelsky přiřadit klávesovou zkratku. V textovém editoru umožnit formátování textu (volba písma, podtržení, tučnost, kurzíva atd.). Možnost ukládání multimediálních dat, jako jsou obrázky, video, zvuk a jiné binární a multimediální přílohy tam, kde je to účelné (např. obrázky u sortimentních karet), minimálně však u číselníků sortimentu. IS obsahuje textový editor, který je využit v konkrétních modulech včetně možnosti předdefinovaných textů. Ukládání multimediálních dat je principiálně možné, nicméně v lékárenském provozu obvykle nevyužíváme. Nejčastěji jsou ukládány skenované dokumenty. |
|
|
Uživatelské prostředí umožní odlišná nastavení ovládacích prvků pro různé typy provozů. Všichni uživatelé se IS se pohybují v jednotném intuitivním prostředí bez ohledu na to, kterou část používají - lékárenskou, laboratorní, účetní atd., s tím, že je podporováno konfigurovatelné uživatelské prostředí, které může být vázáno na různé typy provozů. |
|
|
Uživatel musí mít možnost dostávat on-line notifikace o určitých událostech, případně dle uživatelského nastavení. Notifikace mohou být zasílány e-mailem nebo SMS zprávou (komunikační kanál směrem k uživatelům i od uživatelů žádankového systému směrem k pracovníkům NL). IS disponuje tzv. Informačními kanály kde je uživatel notifikován o určitých událostech. Pro notifikace pomocí SMS je třeba zpřístupnit rozhraní pro komunikaci s SMS bránou. V obou přípradech je třeba zajistit definici rozdělovníku, které informace jsou určeny kterým uživatelům. Současně s tím musí být kontaktní údaje součástí informací o uživatelích. |
|
|
Všechny části systému musí být dokumentovány (musí být dodán popis jejich fungování a obsluhy včetně návazností na jiné části) Dokumentace systému musí být obsažena i v samotném Řešení (nápověda). Vše v českém jazyce. Ke kompletaci dodávky IS náleží uživatelská a administrátorská dokumentace systému. |
|
|
Ve vstupních formulářích musí grafické uživatelské rozhraní rozlišovat údaje povinné a nepovinné. Povinné údaje, u kterých to nevyplývá z právních předpisů nebo z jejich povahy, označí jako povinné zadavatel v Realizačním projektu, přičemž povinnost konkrétního údaje může rovněž vyplývat z pravidla stanoveného zadavatelem v Realizačním projektu. Při zadávání vstupních údajů, kde je to možné a vyžaduje to logika vstupních dat je kontrolována existence resp. Správnost zadaných údajů. V případě chybného zadání dat obsluhou systém hlásí chybu většinou s doporučením dalšího postupu obsluhy, případně znemožní další pokračování zadávání dat do odstranění chyby. |
|
|
U vstupních údajů označených v Realizačním projektu (včetně případných pravidel), musí systém provádět kontrolu správnosti zápisu již při vkládání záznamu. Kontrolní mechanismy bude možno nastavit na úrovni jednotlivých polí i v rámci závislostí v celém formuláři. Viz P.33 |
|
|
Systém musí obsahovat kontextovou nápovědu pro obsluhu funkcí a zadávání vstupních údajů. Kontextovou nápovědu je možné vyvolat v IS napříč moduly funkční klávesou. |
|
|
Systém musí zajistit bezproblémovou komunikaci se systémovou schránkou Windows pro vkládání textů, bez nutnosti řešit kódování textu (problémy s diakritikou apod.). ANO |
|
|
Řešení musí umožňovat filtrovat v seznamech zobrazených formou tabulky dle všech sloupců, a to včetně kombinace podmínek současně v několika sloupcích. Viz P.26 |
Tiskové výstupy |
|
|
|
Tiskové výstupy musí být individuálně konfigurovatelné a přizpůsobitelné správcem. Musí umožňovat, aby zadavatel mohl tvořit vlastní tiskové sestavy, tj. Software musí mít funkcionalitu konfigurátoru pro grafický návrh obsahu tiskových sestav s přednastavenými funkčními bloky, šablonami a pohledy na části databáze. Musí být možné konfigurovat rovněž tyto přednastavené funkční bloky, šablony a pohledy. V rámci Implementace bude vytvořeno nejméně 15 tiskových sestav, které budou podrobně specifikovány v Realizačním projektu. Systém obsahuje nástroj na úpravy sestav, kde je možné nejen upravovat stávající (modifikací vzniká tzv. Uživatelská varianta, která je chráněna proti přepisu v případě instalace nové verze. |
|
|
Software musí umožnit před tiskem náhled na vzhled tištěného dokumentu. ANO, standardní funkčnost. |
|
|
Možnost tisku jak na tiskárnu, tak do PDF. ANO, standardní funkčnost. |
|
|
Řešení musí automaticky vybrat z více tiskáren u pracovní stanice v závislosti na tiskové úloze – dokumentace na primární tiskárnu, štítky na tiskárnu čárových kódů a další. Systém musí umožnit nastavení konkrétních tiskáren pro konkrétní účel a následně musí tisknout na určené tiskárny. ANO, standardní funkčnost. |
|
|
Řešení musí umožnit tisk jak na jehličkových tiskárnách, tak na standardních laserových tiskárnách. Drtivá většina sestav je optimalizovaná pro tisk na laserových tiskárnách. Tisk na jehličkových tiskárnách je také možný. |
Řízení přístupu k aplikaci (přihlášení) |
|
|
|
V Řešení musí být možné provádět správu uživatelských rolí (oprávnění k činnostem) a kompetencí (příslušnost k nákladovým střediskům a klinickým studiím). Musí být možné nastavovat obecnou granuli oprávnění a kompetencí a přidělovat ji k typovému pracovnímu místu, pracovnímu místu a k pracovnímu poměru. Řešení musí umožňovat škálovatelnost oprávnění rovněž podle dalších kritérií, a to např. dle skladů. Prvotní nastavení přístupů je součástí Implementace a bude specifikováno v Realizačním projektu. ANO, tato funkcionalita je podporována a obecně je počítáno s prvotní konfigurací a nastavením přístupů při implementaci. |
|
|
Ve všech modulech musí být rozčleněny uživatelské a administrátorské činnosti, ke kterým je možno nastavit uživatelská oprávnění. ANO, SW moduly disponují konfigurovatelným systémem úrovní oprávnění k výkonu jednotlivých činností systému. |
|
|
Automatické odhlášení nečinného uživatele. Doba nečinnosti musí být nastavitelný parametr. Viz P.18 |
|
|
Možnost změny hesla pro uživatele. ANO, standardní funkčnost. |
Jazyková mutace |
|
|
|
Uživatelské rozhraní musí komunikovat v českém jazyce, pro práci správců a administrátorů se u systémových komponent dodaných třetími stranami připouští komunikace v jazyce anglickém. ANO, standardní funkčnost - systém komunikuje v českém jazyce. Některé administrátorské nástroje jsou v angličtině. |
Ostatní obecné požadavky |
|
|
|
Součástí Software je implementace kvalifikovaného elektronického podpisu a kvalifikovaného elektronického časového razítka do všech schvalovacích procesů dle nařízení eIDAS. V tomto okamžiku neobsahuje systém schvalovací procesy, které vcyžadují časová razítka. V případě zavedení takovýchto procesů, je systém na implementaci připraven. |
|
|
Možnost čtení a tisku 1D i 2D čarových kódů včetně doplňujících informací (alespoň název, identifikační údaje, množství včetně jednotky) ANO, standardní funkčnost. |
|
|
Možnost pro správce zaslat a zobrazit notifikaci uživatelům o významných událostech/situacích (např. nefunkčnost eRecept apod.). Součástí tenkého klienta je k dispozici možnost zasílat uživatelům zprávy do informačních kanálů, které jsou pro uživatele dostupné. Zadávání do tlusrtého klienta bude třeba doplnit, kanály jsou zatím využívány pouze pro automatické zprávy a sdělení od společnosti Apatyka servis s.r.o.
|
|
|
Systém musí obsahovat tzv. nástěnku, na které budou zobrazována všechna obdržená upozornění a notifikace za posledních nejméně 5 dnů (tato doba musí být konfigurovatelná). ANO, standadní funkčnost - viz popis informačních kanálů. |
|
|
Požadováno je napojení a komunikace se systémem pro kontrolů padělků dle nařízení FMD – ověření jedinečného identifikátoru, případně vyřazení jedinečného identifikátoru z úložiště. Software musí plně podporovat nařízení MDR. ANO, FMD standardní funkčnost. MDR podporujeme současnou legislativní úpravu. |
V následující tabulce je seznam požadavků na tuto část dodávky:
# |
Požadavek |
|
|
Řešení musí být připraveno na změnu identifikace pacientů podle jiného identifikátoru, než je rodné číslo. Jakmile tato skutečnost bude legislativní nutností budeme připraveni. |
|
|
Všichni uživatelé zůstávají v Software i po ukončení platnosti jejich účtu bez přístupu k systému. Uchování neaktivního uživatele (zánik objektu v IDM) je pro potřeby uchování historie. ANO, standardní funkčnost. |
|
|
Možnost zastupitelnosti, tj. stanovit na definované období jiného uživatele, který zastupuje danou osobu s tím, že v rámci zastupitelnosti je možné dané osobě delegovat oprávnění zastupovaného uživatele. Pokud bude provedena delegace oprávnění, musí být zaznamenány všechny operace, které uživatel provedl v rámci rozšířených oprávnění. Dle zadání předpokládáme napojení na integrační platformu. Součástí podpory je přidělování odpovídající role dle nastavení v integrační platformě. |
|
|
Zajištění konfiguračního managementu a správy systému s eliminací rizika ovlivnění chodu systému změnou aplikací 3. stran (unifikace konfigurací pracovních stanic, notebooků, tabletů, řízený patch management). Systém je postaven na architektuře klient <-> server, kde veškerá komunikace s externími systémy probíhá z aplikačního serveru. V rámci konfigurace dodáme seznam nutných pravidel pro bezproblémový běh. |
|
|
Řešení bude umožňovat kontrolu a zobrazení platnosti certifikátů. Systém automaticky upozorní správce 30 dnů před expirací certifikátů. Řešení musí umožňovat funkcionalitu pro obnovu certifikátů. Řešení může využít certifikáty, kterými disponuje zadavatel. Certifikáty musí splňovat nařízení eIDAS. IS umožňuje práci s certifikáty a jejich aktualizaci v případě, že jsou systémem spravovány (např. LEK-13, ERP, Portál ZP). Aktuálně upozorňuje uživatele při přihlášení na blížící se expiraci certifikátu (počet dní, kdy začít upozorňovat je konfigurovatelný). Používané certifikáty splňují eIDAS. |
|
|
Evidence přístupů všech uživatelů do systému (logování) včetně časových údajů a identifikace místa přístupu (zařízení). Doba, po kterou budou tato data uchovávána, nesmí být omezena. Tyto logy budou chráněny proti neoprávněným změnám. ANO, standardní funkčnost. |
|
|
Evidence veškerých datových změn na úrovni DB položky (položky datasetu). Atributy: kdo, kdy, původní hodnota, nová hodnota. Doba, po kterou budou tato data uchovávána, nesmí být omezena. Evidujeme datové změny u kritických tabulek (příklad skladové pohyby, změny úhrad cen, stavy komunikace s externími partnery, erp, žádanky...). |
|
|
Dodané řešení bude obsahovat nezávislý auditní systém, který bude zajišťovat veškeré potřebné auditní služby. V rámci systému běží nezávislá služba “apamonitor”, která monitoruje stav systémů a reportuje do monitorovacího nástroje Apatyka servis s.r.o. Součástí řešení jsou integrace na různé systémy SIEM. |
V následující tabulce je seznam požadavků na tuto část dodávky:
# |
Požadavek |
|
|
Systém musí být připraven na provoz 24x7x365 (non-stop). ANO, standardní funkčnost. |
|
|
Možnost paralelního běhu ostré a testovací instance, tj. dodávka ostrého i testovacího systému. ANO, standardní funkčnost. |
|
|
Všechny součásti systému (OS, DB, IS, klientské aplikace) musí logovat svou činnost / provozní stavy do logů s možností nastavit úroveň logování pro potřeby diagnostiky. Bude zajištěna možnost připojení na centrální logovací systém. Systém musí být připraven k poskytování údajů a informací minimálně v rozsahu dle § 22 vyhlášky 82/2018 Sb. pro systém log managementu Objednavatele a musí mít připraveno rozhraní pro systém log managementu Objednavatele, jehož podrobná dokumentace bude součástí Dokumentace, jak je tento pojem vymezen ve smlouvě. ANO, standardní funkčnost, připravíme exporty do log managementu Objednatele na základě dodaného rozhraní. |
|
|
Software bude logovat veškeré provedené operace s ukládáním historie bez omezení počtu záznamů tak, aby byly naplněny legislativní požadavky. Software musí umožňovat uživatelsky nastavovat pravidla, která budou upravovat rozsah logovaných údajů. Vytvoření základního rozsahu těchto pravidel bude součástí implementace. ANO, IS má různé nastavitelné úrovně logování provedených operací, některé protokoly jsou ukládány do souborů. |
|
|
Dohled – systém musí předávat informace o svém stavu (stavu služeb apod.) na žádosti SNMP GET. Konkrétní specifikace bude součástí Realizačního projektu. Služba Apamonitor bude rozšířena o podporu SNMP GET v rámci realizačního projektu. |
|
|
Synchronizace času všech zařízení s time serverem zadavatelem (…). Čas systém načítá ze systému. Plně dostačuje synchronizace s time serverem na úrovni Windows. |
|
|
Klientská část Řešení (těžký i lehký klient) musí být schopna plnohodnotného fungování na pracovní stanici s následujcí konfigurací: Intel Core2 Duo E8400 @ 3.00GHz (1174 bodů na ▇▇▇.▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/), 4 GB DDR 3 RAM, 120 GB SSD, nebo na pracovní stanici s konfigurací lepší. Na všech pracovních stanicích má zadavatel implementován operační systém MS Windows 10 Pro 64 bit. ANO |
|
|
Řešení musí disponovat těžkým klientem i lehkým klientem. V obou těchto typech klientského rozhraní musí být k dispozici veškeré funkcionality Řešení a oba musí být plně lokalizovány v českém jazyce.
Těžkým klientem se rozumí lokální aplikace instalovaná v prostředí operačního systému klientské stanice. Těžký klient musí mít následující vlastnosti:
Lehkým klientem se rozumí klientské rozhraní Řešení dostupné uživatelům na klientských stanicích výhradně prostřednictvím webových prohlížečů, které nevyžaduje žádnou instalaci kromě samotného webového prohlížeče. ANO, IS je tvořen těžkým i lehkým klientem. Periferie zmíněné v zadávací dokumentaci jsme schopni integrovat. Jakékoliv nové periferie je nutno nejdříve otestovat a dohodnout další postup na základě analýzy. |
V následující tabulce je seznam požadavků na tuto část dodávky:
# |
Požadavek |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Integrační rozhraní |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Integrace s informačními systémy třetích stran budou realizovány přes ESB. Pokud však informační systém třetí strany integraci přes ESB neumožňuje, bude taková integrační vazba řešena zvlášť a bude popsána v Realizačním projektu. IS je schopen komunikovat se systémy třetích stran, cestou přes ESB tak i přímo s konkrétním systémem. Podmínkou je dodání podrobného zadání integrační vazby / komunikačního rozhraní s konkrétním systémem Zadavatelem. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém musí mít funkcionalitu pro export veškerých aplikačních dat včetně dat o uživatelích Řešení do souborů CSV, XML a XLSX, a to uživatelsky bez nutnosti jakékoli součinnosti dodavatele. Aktuálně IS umožňuje exporty do zmíněných formátů v rámci běžnných uživatelských úloh. Na další místa v systému můžeme doplnit. Nutno specifikovat podrobněji, neboť exporty kompletních dat jsou rozsáhlé a náročné. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Veškeré integrační vazby uvedené v příloze č. 4 této zadávací dokumentace musí splňovat požadavky uvedené v příloze č. 4 zadávací dokumentace. Všechny integrační vazby jsou řešené pomocí GW nebo budou implementovány pomocí ESB, kde to třetí strana umožňuje (nelze např. v případě proprietárních aplikací pro elektronické objednávání u dodavatelů). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IDM (Identity Management) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Přebírání údajů o uživatelích bude řešeno prostřednictvím IDM a ESB. Přebírání min. následujících údajů: osobní číslo, identifikace, jméno, příjmení, funkce, organizační struktura, funkční místo, nákladové středisko, začátek a konec pracovního poměru. Rozsah dalších údajů bude upřesněn v rámci Realizačního projektu. ANO, používáme data importovaná z IDM. Nutno naprogramovat rozhraní dle konkrétního zadání Zadavatele. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Řízení přístupů uživatelů bude automatické dle rolí (co dělá) a kompetencí (kde dělá). Konfigurace rolí je součástí IS, napojení kompetencí viz P.72 dle definice IDM. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Ověření oprávnění přístupu bude provedeno online v okamžiku přihlášení uživatele. Systém aktuálně podporuje autorizaci vůči LDAP/Active directory. Autorizaci vůči IDM budeme řešit v rámci bodu P.72 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OrgUnit (Organizační jednoty FN Brno) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Služba OrgUnit poskytuje informace o organizačních jednotkách zadavatele. Software bude integrován se službou OrgUnit prostřednictvím ESB. Org.UNIT poskytne prostředníctvím ESB organizační strukturu zadavatele. Přebírání dat od služby OrgUnit budeme implementovat na základě dodaných integračních vazeb této služby Zadavatele. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ERP (ekonomický systém) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém bude integrován s ERP prostřednictvím ESB. Export dat pro finanční účetnictví (skladové pohyby, finanční doklady (faktury, dobropisy - nákupní, prodejní), položky hotovosti) pro následný import do Microsoft SQL databáze a načtení do ERP. Import ekonomických dat z finančního účetnictví (nákladová struktura, rozpočty, dimenze). Rozsah dalších údajů bude upřesněn v rámci Realizačního projektu. Systém podporuje importy/exporty z/do různých účetních systémů. Implementace bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Zdravotní pojišťovny (ZP) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém musí podporovat komunikaci s pojišťovnami za podmínek a v rozsahu potřebném pro správné a úplné vykázání práce pojišťovnám, např. export/import k-dávek, přístup na portály pojišťoven, komunikaci s B2B službami včetně automatického stahování číselníků, kontrola identifikace pacienta (RČ/číslo pojištěnce). ANO, standardní funkčnost. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ÚZIS |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém musí zajistit maximálně automatizovanou komunikaci a předávání dat na ÚZIS, resp. do registrů NZIS, minimálně v rozsahu požadavků daných legislativou, včetně možnosti exportu dat pro ÚZIS. ANO, standardní funkčnost. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
U těch registrů, kde je ÚZISem povoleno dávkové zasílání dat, Systém zajistí dávkové vykazování do registrů. Na základě zadání v realizačním projektu bude podpora doplněna u služeb, které dosud nejsou podporovány. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SÚKL eRecept (elektronická preskripce) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém musí být integrován se systémy pro elektronickou preskripci SÚKL. ANO, standardní funkčnost. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Nemocniční informační systém (NIS) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Systém bude integrován s NIS. Systém musí v rámci integrace s NIS mimo jiné poskytovat data o vydaných LP na pacienta, a to za účelem kontroly vykazování zdravotní péče. Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Export informací o CL do karty pacienta. Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Řešení zajistí vytvoření webové služby, která bude poskytovat data pozitivních listů (ambulantní i hospitalizační) z aktuálního sortimentu LP a ZM včetně skladové zásoby pro účely preskripce a medikace v NIS. Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Řešení zajistí vytvoření webové služby, která zajistí import dat preskripce LP a ZM z NIS do Řešení pro potřeby srovnávání preskripce s vyzvednutím LP a ZM v lékárně FN Brno. Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Řešení musí být schopno přebírat certifikáty z IDM a jejich využití v Řešení pro elektronickou komunikaci. Bude součástí realizačního projektu. viz P.72. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Manažerský informační systém (MIS) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Řešení bude integrováno s MIS. Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Poskytování dat do MIS :
Analýza integrovaných dat bude definována v Realizačním projektu. Ve výchozím (současném) stavu jsou struktury následující, což vychází z logiky současného lékárenského IS:
* jde o SÚKL s vazbou do NIS (nastavení centrových LP)
(karty LP a ZM)
(pohyby LP a ZM) Bude součástí realizačního projektu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Stravovací provoz Řešení musí být integrováno se stravovacím informačním systémem zadavatele za účelem vzájemného naskladňování zboží. Přesná definice bude součástí Realizačního projektu. Bude součástí realizačního projektu.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Transfúzní informační systém Řešení musí být integrováno s transfúzním informačním systémem zadavatele za účelem vzájemného naskladňování LP a ZM. Přesná definice bude součástí Realizačního projektu. Bude součástí realizačního projektu.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Operační sály Řešení musí být integrováno s informačním systémem zadavatele pro operační sály za účelem veškerého použitého materiálu na operačních sálech (LP a ZM). Přesná definice bude součástí Realizačního projektu. Bude součástí realizačního projektu.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
V následující tabulce je seznam požadavků na tuto část dodávky:
# |
Požadavek |
|
|
Dodavatel zajistí migraci dat do odpovídajících položek datových struktur dodávaného systému ve strukturované podobě se zachováním informací Původního lékárenského systému. ANO, standardní součást implementace. |
|
|
Migrace dat a související přípravné práce budou probíhat následujícím způsobem.
Dodavatel poskytne zadavateli řádně dokumentované zdrojové kódy k migračním skriptům včetně práva do nich zasahovat. ANO, počítáme s tímto scénářem. |
|
|
Objednavatel požaduje migraci dat minimálně v následujícím rozsahu a časově minimálně od 1. ledna 2022: Veřejná i nemocniční část:
Veřejná část:
Nemocniční část:
Ano počítáme s migrací do separátní instance, pro přístup ke starším datům, aby nehrozilo duplicitní zpracování stejných dat v novém a původním systému. |
Součástí dodávky bude prezenční (ledaže zadavatel v konkrétním případě vysloví souhlas s on-line, případně hybridní formou) školení zaměstnanců určených zadavatelem. Školení bude realizováno ve více termínech dle požadavků zadavatele. Zadavatel, v rámci dodávky požaduje vypracovat a dodat, uživatelské návody v českém jazyce na nejběžnější a nejčastější úkony koncových uživatelů a oprávněných osob. Zadavatel volitelně připouští zpracování návodů formou videí.
Věcné zaměření školení |
Minimální počet školení |
Minimální hodinová dotace školení |
Celkem hodin |
Orientační počet účastníků školení |
Školení pro farmaceuty |
5 |
3 |
15 |
15 |
Školení pro farmaceutické asistenty |
10 |
3 |
30 |
15 |
Školení IPLP |
5 |
2 |
10 |
5 |
Školení CYTO modul – pracovníci NL |
5 |
3 |
15 |
5 |
Školení CYTO modul – zdravotničtí pracovníci |
15 |
3 |
45 |
10 |
Školení THP pracovníků ekonomického odboru a NL |
10 |
3 |
30 |
5 |
Školení modulu objednávání – zdravotničtí pracovníci |
10 |
2 |
20 |
50 |
Školení obsluhy konsignačních skladů |
10 |
2 |
20 |
5 |
Školení technických administrátorů |
1 |
6 |
6 |
5 |
Školení datových administrátorů včetně řízení přístupů (struktura db – tabulky, logika, reportingové nástroje, SQL dotazy, integrace) |
2 |
12 (rozloženo minimálně do dvou dnů) |
24 |
5 |
Školení pro pracovníky Ekonomického odboru (controlling, účtárna, vykazování pro zdravotní pojišťovny, nastavování centrových léčiv) |
3 |
2 |
6 |
5 |
Školení pro manažery |
2 |
2 |
4 |
5 |
|
|
Požadované řešení musí v souladu s platnými právními předpisy umožňovat:
Objednavatel požaduje ověřování a vyřazování LP dle FMD a ZM dle MDR, a to například prostřednictvím NSOL, přičemž Objednavatel akceptuje ověřování vůči obdobnému systému. ANO, standardní funkčnost IS. |
|
|
Požadavky na kontrolní mechanismy k FMD minimálně v rozsahu:
ANO, FMD - standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
|
|
Řešení musí zajistit zabezpečenou komunikaci s dodavateli na základě elektronické výměny dat. IS standardně komunikuje s vybranými dodavateli a tam kde dodavatel toto umožňuje komunikujeme přednostně zabezpečeným protokolem. |
|
|
Komunikace s dodavateli musí splňovat podmínky stanovené v příloze č. 4 této zadávací dokumentace. ANO, standardní funkčnost. Viz popis v příloze č. 4. |
|
|
Při komunikace s dodavatelem musí být využíván číselník PDK, k jehož užívání má Objednavatel pořízenou licenci. Součinnost autora číselníku PDK zajišťuje Objednavatel. ANO, standardní funkčnost. |
|
|
Požadavek na evidenci a kompletní historii objednávacího procesu, schvalovací postup objednávek dle zákona o finanční kontrole ANO, standardní funkčnost. |
|
|
Objednavatel požaduje, aby objednávkový modul disponoval variabilním systémem práce s návrhem objednávky i samotnými objednávkami, alespoň:
|
Požadavek na generování návrhu objednávky |
|
|
|
Ručně generovaná objednávka, a to alespoň: • Zadáváním položek dle uživatelsky definovaných pravidel do návrhu nebo zadávání skenerem. • Ručně (např. klávesovou zkratkou kdekoliv v systému) z položky. • Automatická objednávka položky v případě, že položka není skladem (na expedici). ANO, standardní funkčnost.
|
|
|
Automaticky generovaná objednávka, a to alespoň: • Dle výdejů specifikovaných typů položek od poslední objednávky. • Dle výdejů specifikovaných typů položek za dané období. • Dle uživatelsky definovaných norem zásob. • Dle uživatelsky definovaných norem zásob se zvoleným procentuálním určením naplnění normy. • Dle ekonomické výhodnosti dodavatele, jehož výhodnost se zkoumá za nastavené časové období. Řešení musí ekonomickou výhodnost dle věty předchozí samo posuzovat. ANO, standardní funkčnost. Podmínkou pro splnění ekonomické výhodnosti je nutné implementovat import tzv. Ceníků dodavatele. |
Stav objednávky po odeslání objednávky dodavateli |
|
|
|
Potvrzené objednávky s kontinuitou číselného označení musí přecházet do seznamu potvrzených objednávek, se kterými lze dále pracovat a provádět nad nimi kontroly. ANO, standardní funkčnost. |
|
|
Potvrzené objednávky musí tvořit evidenci a kompletní historii objednávacího procesu. ANO, standardní funkčnost. |
|
|
Možnost párování defektního listu s následnou příjemkou. ANO, standardní funkčnost. |
|
|
Možnost tisku a exportu ve zvoleném formátu. ANO, standardní funkčnost. |
Registr smluv |
|
|
|
Zveřejňování objednávek v registru smluv: U dodavatelem potvrzených objednávek pro registr smluv (pouze objednávky, jejichž souhrnná cena bez DPH překračuje hranici stanovenou zákonem o registru smluv), případně z dodacího listu nebo faktury: a/ automaticky (naplánovanou úlohou) generovat PDF dokumenty a k nim příslušné XML, a ukládat na zvolené uložiště Zadavatele. b/ prostřednictvím spisové služby Zadavatele. c/ přímé zveřejňování v Registru smluv dle platné legislativy. Požadována je funkčnost pro anonymizování údajů. Konkrétní specifikace bude součástí Realizačního projektu. ANO, standardní funkčnost dle bodu a/ a dle bodu b/, přímá komunikace není k dispozici, napojení na spisovou službu dle specifikace v realizačním projektu. |
|
|
V rámci automatického procesu využít příznak na kartě LP, ZM - uvedeno číslo smlouvy dle číselníku Objednavatele. ANO, standardní funkčnost. |
|
|
Možnost anonymizovat požadované údaje dle uživatelsky zadávané konfigurace. ANO, standardní funkčnost v rámci GDPR je možné procesy anonymizace nastavit. |
|
|
Možnost přístupu do skladu dodavatele LP nebo ZM, elektronický dodací list nestahovat z úložiště, ale přímo z IS dodavatele LP nebo ZM, kam jej vloží dodavatel LP nebo ZM a po potvrzení automaticky naskladnit (optimalizace logistických procesů a skladových zásob) do Řešení. Splnění tohoto požadavku provede dodavatel až na výzvu zadavatele. ANO, standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
|
|
Požadavek na agendu veřejných zakázek s integrací na databázi veřejných zakázek v rámci Objednavatele prostřednictvím ESB výrobce InterSystems. Bude součástí realizačního projektu. |
|
|
Požadavek na detailní sledování průběhu veřejných zakázek zadávaných s podporou řešení včetně sledování plnění dalších smluv a poptávek v lékárenském IS. ANO, standardní funkčnost. |
|
|
Smlouvy a poptávky musí být možné ve stromové struktuře sledovat v čase (platnost od-do), a to alespoň v členění primární smlouvy a dílčích dodatků, s vazbou na konkrétního dodavatele a periodu plnění. ANO, standardní funkčnost. |
|
|
Možnost provádět kontrolu ceny z výběrových řízení a poptávek. ANO, standardní funkčnost.
|
|
|
Požadavek na systém kontrol průběžného plnění dle periody plnění, počátku periody, termínu spuštění kontroly, periody opakování a způsobu kontroly – ručně a automaticky. V tomto okamžiku probíhají kontroly v rámci přijmu a objednávky. V případě dalších kontrol bude součástí realizačního projektu. |
Základní (minimální) požadavky na požadované řešení:
Dodací list |
|
|
|
Požadavek na příjem elektronického DL - „automatickým stažením“ souboru od dodavatele (formát PDK4-14 či jiný) na uložiště v lékárně (u Objednavatele). ANO, standardní funkčnost. |
|
|
Požadována realizace příjmu z datového media či e-mailu s následným automatickým párováním alespoň dle EAN, APA, kódu SÚKL, PDK, GTIN na sortiment lékárny. ANO, standardní funkčnost. |
|
|
Umožnit zadat na sortimentní kartu jednoho přípravku i více objednacích kódů různých dodavatelů. ANO, standardní funkčnost.
|
|
|
Pokud dodavatel vytvoří DL ve formátu PDK (kde místo kódu PDK je objednací kód dodavatele), možnost příjemku načíst i z tohoto souboru elektronicky. ANO, standardní funkčnost, ale je nutné párovat se sortimentem ručně. |
Příjemka |
|
|
|
Příjem zboží musí probíhat na kterémkoliv pracovišti v lékárně načtením položek staženého dodacího listu z úložiště, ručním vkládáním či skenováním položek. ANO, standardní funkčnost. |
|
|
Musí být založeny příslušné identifikace příjemky včetně podkladů pro sběrné faktury. ANO, standardní funkčnost.
|
|
|
Musí být možno rozpracovat libovolné množství příjemek. Z dalších funkčností požadujeme alespoň: • Nerozpoznané položky z DL označit a systémovou podporou ručně dopárovat. • Příjemku není nutné dopracovat najednou, ale lze ji nechat rozpracovanou s možností pozdějšího dokončení. • Možnost okamžitého naskladnění položky, ještě před dokončením celého dodacího listu s možností tuto položku ihned expedovat s následným automatickým dopárováním. • Upozorňovat na ohrožení exspirace naskladňovaného zboží (dle předem zadaných parametrů). • Automaticky vypočítávat prodejní ceny dle definovaných kritérií v souladu s platnou legislativou a nastavenou obchodní strategií lékárny (alespoň dle regulace, dle doporučené ceny dodavatele, zvolené obchodní přirážky u neregulovaných přípravků, dle ceny nastavené pro daný přípravek na skladové kartě – pevný doplatek, pevná cena, pevné procento). • Kontrola zda DL se stejným číslem již nebyl naskladněn. • Automatická kontrola, zda prodejní cena nepřekračuje maximální přirážku nebo maximální prodejní cenu, při zohlednění parametricky nastaveného doprodeje. • Vypočtenou cenu u konkrétní položky možnost ručně upravit. • Možnost nastavení „prodejní cena = nákupní cena“pro všechny příjmy na sklad určené pro oddělení nemocnice. • Možnost automatické kontroly nákupních cen sjednaných s dodavateli (veřejné zakázky, poptávky), automatické ukončení platnosti smluvního období. • Kontrola nedodaného množství oproti defektnímu listu. Možnost provázání objednávky, žádanky a příjemky. Tato možnost se musí týkat i elektronických objednávek. Doklad musí být možné částečně i celý převést do objednávky. Po úspěšném objednání se dále musí párovat defektní list s dodacím listem a zboží je naskladněno. • Při příjmu surovin možnost použít automatický přepočet, tzv. „cena za přijímané množství“, kdy se zadaná cena za přijímané množství přepočte automaticky na jednotkovou cenu. • Možnost dopracovaný DL v několika variantách tisknout, exportovat (alespoň cena výrobní, nákupní bez DPH, nákupní s DPH, prodejní bez DPH, prodejní s DPH, marže distributora, marže lékárny, úhrady a doplatku pro pacienta), včetně nabídky tisku cenovek s vlastním tiskem čárového kódu v různých módech. • Podpora řešení reklamací a vratek v souladu s legislativou.
(Jedná se o dopočet DPH do ceny zásob, a to tak, aby byl buď uplatněn nárok na odpočet DPH – v případě prodejů zboží ve veřejných lékárnách, nebo tak, aby nebyl uplatněn nárok na odpočet DPH u osvobozeného plnění (většina materiálu na kliniky), případně částečně uplatněného nároku na odpočet DPH. O tento režim se jedná nejvíce u dodávek z EU a ze zahraničí, ovšem předpokládá se, že by mohl být v budoucnu uplatněn i u tuzemských dodávek nad určitý cenový limit. Legislativa – zákon č. 235/2004 Sb.)D ANO, standardní funkčnost. Případná specifika zadavatele budou doplněna do realizačního projektu.
|
Základní (minimální) požadavky na požadované řešení:
|
|
Vedení více nezávislých skladů. ANO, standardní funkčnost. |
|
|
Převod mezi sklady s různým nárokem na odpočet DPH, tj. mezi sklady bez nároku na odpočet DPH, sklady s plným nárokem na odpočet DPH a sklady s kráceným nárokem na odpočet DPH. ANO, standardní funkčnost. |
|
|
Centrální číselníky zboží pro všechny sklady včetně Objednavatelem uživatelsky definovaných číselníků. ANO, standardní funkčnost. |
|
|
Centrální synchronizace číselníků SÚKL, VZP, PDK, DLP (KLK), NLEKY. ANO, standardní funkčnost. |
|
|
Upozornění na blížící se exspiraci zboží, možnost uživatelsky nastavit jednak ve smyslu zadání časového intervalu (počtu dní před exspirací) a dále pak kdy se má kontrola automaticky provádět a hlásit výsledky. Ohrožené položky exspirací možnost sledovat v sestavách. ANO, standardní funkčnost. |
|
|
Požadavek na pozitivní listy zvlášť pro recepty (veřejná část), zvlášť pro lůžka (nemocniční část). ANO, standardní funkčnost. |
Požadavky na standardní sklady |
|
|
|
Podporována kusová a cenová evidence položek skladu dle platné legislativy. ANO, standardní funkčnost. |
|
|
Skladové karty musí obsahovat obecné údaje k danému přípravku nezbytné pro správnou cenotvorbu, příjem a výdej. ANO, standardní funkčnost. |
|
|
Skladové karty kromě vnitřní unikátní identifikace musí obsahovat jednoznačnou identifikaci zboží včetně názvu, doplňku názvu, PDK kódu, pokud pro daný přípravek existuje, čárový kód EAN, dodavatelský kód zboží, kódy SÚKL, VZP, měrnou jednotku a další. ANO, standardní funkčnost.
|
|
|
Skladové karty musí být založeny a udržovány automaticky na základě PDK číselníku (včetně naplnění všech existujících polí), karty pro zboží, které PDK číselník neobsahuje, zakládá a edituje uživatel. ANO, standardní funkčnost. |
|
|
Aktualizace číselníků SÚKL, VZP, PDK musí probíhat automaticky za provozu, v případě potřeby musí být možnost sortimentní karty editovat uživatelem s příslušným oprávněním. ANO, standardní funkčnost. |
|
|
Výše úhrad přípravků s druhou (případě třetí úhradou) musí být uvedeny v cenovém řádku těchto karet. ANO, standardní funkčnost. |
|
|
Z každé karty musí mít uživatel možnost vidět kompletní historii úhrad. ANO, standardní funkčnost. |
|
|
Na kartách lze nastavit mimo dalších parametrů i preferovaného dodavatele, příznak pozitivního listu + další atributy (dodavatelské číslo zboží, ceny z výběrových řízení, informace o smluvních bonusech s návazností na příslušné interní číselníky). ANO, standardní funkčnost. Informace o smluvních bonusech bude třeba zapracovat do realizačního projektu v závislosti na poskytnutých číselnících z ESB. |
|
|
Převod přípravku z jedné skladové karty na druhou jedním krokem (úkonem). ANO, standardní funkčnost.
|
|
|
Při zakládání skladové karty upozornění na případnou duplicitu. ANO, standardní funkčnost - kontrola na duplicitu identifikátorů přípravku (PDK, APA, SUKL, EAN). |
|
|
Možnost definovat tzv. sortimentní skupiny skladových karet. Dle definovaných skupin možnost karty třídit, vyhledávat, hromadně upravovat a nastavovat, tisknout sestavy včetně alespoň možnosti výstupu do xlsx. ANO, standardní funkčnost.
|
|
|
Možnost zobrazit přehled všech pohybů na skladových kartách za zvolené období přímo v lékárenském IS napříč všemi sklady, typy pohybů, aktivní využívání filtrů a omezení záznamů. ANO, standardní funkčnost modulu “Výstupy”. |
|
|
Souhrnný přehled přes celou lékárnu položek skladem a filtr na jednotlivé sklady. ANO, standardní funkčnost modulu “Výstupy”. |
|
|
Nástroj pro vlastní definici sestav s možností uložení těchto výběrů pro pozdější použití. IS disponuje možností oblíbených často používaných sestav. Variantně lze generovat uživatelsky definované datové výstupy doprovozené včetně uložení pro další použití. |
|
|
Podpora kontroly skladu s ohledem na exspirace a zboží bez pohybu. ANO, standardní funkčnost. |
|
|
Možnost načítat – importovat různé seznamy sortimentu (uložené v souborech) a párovat dle kódu SÚKL nebo PDK na skladový sortiment, tedy i kontrolního seznamu SÚKL a jeho porovnání s aktuálním skladem. ANO, standardní funkčnost - import do sortimentní skupiny dle SUKL nebo PDK kódu. |
|
|
Možnost vložení textové poznámky na skladové kartě, která se zobrazí alespoň při objednávce a výdeji. ANO, standardní funkčnost. |
|
|
Podporováno automatické generování norem zásob ze zadaného období dle nastavitelných parametrů (alespoň minimální množství, maximální množství, jednotka pro objednání). ANO, standardní funkčnost. |
|
|
Možnost hromadného přecenění (všech, vybrané skupiny, jednotlivých položek). ANO, standardní funkčnost. |
|
|
Funkce pro kontroly prodejních cen vzhledem k překročení maximální přirážky, maximální ceny a doprodeje. ANO, standardní funkčnost. |
|
|
Parametrizace sortimentní karty s vazbou na definované kontrolní mechanismy Objednavatele. ANO, standardní funkčnost, nutno upřesnit konkrétní kontrolní mechanizmy. |
|
|
Možnost separátního uzavření jednotlivých materiálových skupin nebo skladů při uzavírání účetního období. Sklady lze separátně uzavírat. Materiálové skupiny budou součástí realizačního projektu po upřesnění zadání. |
Požadavky na inventarizaci |
|
|
|
Řešení inventur řádných i mimořádných dle platné legislativy. ANO, standardní funkčnost.
|
|
|
Provádění inventury všech skladů najednou s tím, že na každém skladu je potřeba inventuru zahájit a potom ukončit. ANO, standardní funkčnost. |
|
|
Inventovat jeden vybraný sklad, stejně tak jednu sortimentní skupinu či určitou vyfiltrovanou skupinu zboží dle zadaných kritérií. ANO, standardní funkčnost. |
|
|
V průběhu inventury možnost průběžně sledovat stav i inventurní rozdíly. ANO, standardní funkčnost. |
|
|
Možnost expedice v průběhu inventury. ANO, IS umožňuje, nicméně jde o nedoporučenou variantu. |
|
|
Odpisy ze skladu se mohou provádět dle uživatelsky nadefinovaného číselníku odpisových skupin (prošlá exspirace, znehodnocení). ANO, standardní funkčnost. |
|
|
Požadovány položkové či sumační výstupy dle odpisových skupin. ANO, standardní funkčnost. |
|
|
Možnost provádění celkových inventur nebo dílčích inventur (řádné a mimořádné) dle zadaných parametrů (dle skladů, lokací, pracovišť, fakturačních skupin, vybraných položek či jinak vytvořených skupin zásob). ANO, standardní funkčnost. |
|
|
Možnost separátní inventarizace poskytnutých záloh (řádné a mimořádné). Informační systém umožňuje evidenci přijatých záloh od zákazníků.
|
|
|
Tisk inventurních sestav, a to alespoň za všechny sklady, za skupinu zásob nebo za vybrané skladové karty, za všechny položky na skladu nebo jen za položky s nenulovým stavem, třídění podle skladu a materiálové skupiny a dále podle čísla nebo názvu materiálu, místa uložení a EAN kódu, GTIN kódu. ANO, standardní funkčnost. Kumulovanou sestavu za všechny sklady bude třeba zařadit do realizačního projektu. Aktuálně k dispozici pouze jako XLS export, nikoliv jako tištěná sestava. |
|
|
Zadávání údajů při provádění fyzické inventarizace – ručně anebo pomocí čtečky. ANO, standardní funkčnost. |
|
|
Možnost paralelní práce na více rozpracovaných inventurách. ANO, standardní funkčnost. |
|
|
Výstupy – alespoň inventarizačních rozdíly (záměny, manka, přebytky), archivace výsledků, prohlížení (v průběhu inventarizace, po ukončení inventarizace, archivované výsledky inventarizace). ANO, standardní funkčnost. |
|
|
Řešení inventarizačních rozdílů – záměny, manko, přebytky a jejich zpracování, včetně podkladů pro účetní systém. ANO, standardní funkčnost. |
|
|
Detailní a souhrnné náhledy na identifikované inventarizační rozdíly. ANO, standardní funkčnost. |
|
|
Pro vypořádání inventarizačních rozdílů a likvidaci exspirovaných, poškozených zásob musí být nastaven víceúrovňový schvalovací proces, přičemž vypořádání inventarizační rozdílů a likvidace exspirovaných, poškozených zásob a jeho uzavření musí být provedeno až na základě pokynu oprávněné osoby. V rámci modulu vyřazení je dvouúrovňový schvalovací proces k dispozici. |
|
|
Vypořádání inventarizačních rozdílů a likvidace exspirovaných, poškozených zásob musí být prováděno po uzavření dokladu ANO, standardní funkčnost. |
|
|
Identifikace zásob, které zásoby jsou likvidovány z důvodu exspirace, poškození, ztráty či jiného důvodu vyřazení (důvody vyřazení a jejich kategorizaci si stanový Objednavatel dle potřeb). ANO, standardní funkčnost. |
|
|
Vedení evidence položek u konsignačních skladů ANO, standardní funkčnost.
|
|
|
Možnost nastavení uzavírání a otevírání období příjmů a výdejů ze skladu V rámci realizačního projektu bude rozhodnuto, zda uzamčení proběhne v systému, nebo bude zasíláno z účetního systému. |
|
|
Změna hodnoty skladu u položek s kráceným nárokem na odpočet DPH při změně koeficientu v rámci ročního vyúčtování nároku na odpočet DPH, případnou další změnu koeficientu Bude řešeno v rámci realizačního projektu po konkrétní definici práce s cenami (systém jede v režimu FIFO/FEFO). |
|
|
Možnost vedení různých druhů skladů, kde budou odlišné nároky na odpočet DPH, možnost přeskladňování mezi těmito sklady ve vazbě na změnu odpočtu DPH, tj. možnost vést i sklady s kráceným nárokem na odpočet DPH ANO, standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
|
|
Expedici přípravků ze skladu nutno dle zvoleného parametru provádět alespoň pomocí čárového kódu výrobce, z vlastních etiket interním čárovým kódem, 2D kódu, GTIN kódu, RFID kódu, metodou FIFO nebo dle exspirace (FEFO). ANO, standardní funkčnost, RFID nutno ověřit periferie. |
Základní (minimální) požadavky na přípravu léčiv:
|
|
Příprava musí probíhat dle platné legislativy buď jako individuální pro konkrétního pacienta nebo hromadná včetně naskladnění, možnosti tisku signatur a možnosti zaznamenání technologického postupu. ANO, standardní funkčnost. |
|
|
Příprava musí být podpořena náležitou dokumentací, tedy alespoň protokolárním záznamem přípravy, výroby. ANO, standardní funkčnost. |
|
|
Podporován musí být klasický i několikastupňový (výroba z již lékárnou dříve připraveného IPLP) způsob přípravy, výroby dle nadefinovaných a uložených receptur v lékárenském IS a bez receptur. ANO, standardní funkčnost. |
|
|
Suroviny, obaly a další komponenty musí být vedeny položkově včetně aktualizace číselníku taxy laborum pro další průkaznou evidenci DPH a ostatních podkladů. ANO, standardní funkčnost. |
|
|
Pro připravený IPLP musí být vygenerována skladová karta. ANO, standardní funkčnost. |
|
|
Ředění ATB sirupů a kapek. ANO, standardní funkčnost. |
|
|
Přípravu, výrobu musí být možné realizovat jak přímo na expedičním místě, tak v laboratoři. ANO, standardní funkčnost. |
|
|
Konfigurovatelný způsob odpisu surovin, volitelný typ výpočtu taxy laborum. ANO, standardní funkčnost. |
Požadavky na standardní funkcionalitu |
|
|
|
Výdej surovin ze skladu, zadání TL za přípravu, výrobu a uložení výsledného produktu na sklad. ANO, standardní funkčnost. |
|
|
Možnost zvolit konkrétní šarži suroviny. ANO, standardní funkčnost. |
|
|
Základní jednotkou při přípravě je 1g. U surovin musí být volitelná i jiná hlavní měrná jednotka než 1 g. Na každé skladové kartě musí být možné nastavit i přepočet, minimálně 1 kg = 1000 g a 1 g = 1000 mg, kdy se potom při přípravě nabízí 2 vstupní okénka pro zadání množství v jednotce hlavní i vedlejší. V protokolu pro přípravu, výrobu automaticky respektovat tyto nastavené jednotky na skladových kartách. ANO, standardní funkčnost. |
|
|
Dodatečný tisk protokolu přípravy, výroby dle požadavků vyhlášky 84/2008 Sb. s možností dohledání jednotlivých šarží, certifikátů a exspirací použitých surovin, data a času přípravy, výroby identifikace připravujícího. Elektronická kontrola surovin. ANO, standardní funkčnost. |
|
|
Přednastavení více způsobů výpočtu celkové TL, existence filtru, sestava na evidenci TL. ANO, standardní funkčnost. |
|
|
Seznam receptur, kde jsou uloženy postupy a složení příprav, výrob léčiv. Možnost je editovat. Číselník magistraliter, kde si uživatel může připravit postupy pro přípravu, výrobu LP. ANO, standardní funkčnost. |
|
|
Příprava musí být individuální (pro konkrétního pacienta, na recept), hromadná (do zásoby, na žádanku), příprava meziproduktů použitelných pro další přípravu. ANO, standardní funkčnost. |
|
|
Automatické dopočítání poslední komponenty dle zadané gramáže v připravovaném IPLP. ANO, standardní funkčnost. |
|
|
Podpora tisku vyúčtování individuální přípravy na druhou stranu recepturního tiskopisu. ANO, standardní funkčnost. |
|
|
Podpora tisku štítků (signatur) ve volitelných velikostech pro hotové produkty. Údaje na signaturách musí odpovídat požadavkům vyhlášky 84/2008 Sb. Vzor signatury musí být možné vytvořit a uložit k dané receptuře z číselníku magistraliter. Signaturu musí být možné vytvořit pro IPLP ručně zadáním textu do obecné předlohy signatury. ANO, standardní funkčnost. |
|
|
Podpora tisku minimálně na štítky archové A4 běžné tiskárny, štítky pro speciální tiskárny Zebra (Objednavatel má již pořízeno), nastavení dle uživatelem definovaného souboru štítků u A4 tiskové sestavy. ANO, standardní funkčnost. |
|
|
Podpora tisku signatur na štítky na běžné laserové tiskárně, tzn. na list A4 s možností výběru formátu a umístění štítku na stránce. ANO, standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
|
|
Podpora více způsobů práce s recepty při výdeji na expedičním místě. ANO, standardní funkčnost. |
|
|
Nastavitelnost alespoň následujících způsobů třídění receptů do dávek ZP: ZP, čas, uživatel, stanice, počet receptů, a to včetně kombinací těchto způsobů třídění. ANO, standardní funkčnost. |
Požadavky na zpracování receptů a poukazů |
|
|
|
Průběžné vytváření dávek - po libovolně nastavitelném počtu receptů pro každou ZP. ANO, standardní funkčnost. |
|
|
Práce s dávkami – a to alespoň v rozsahu kontroly a výběru seznamu dokladů dle zvolených kritérií pro tvorbu dávek. ANO, standardní funkčnost. |
|
|
Volba způsobu řazení dokladů do dávky. ANO, standardní funkčnost. |
|
|
Fakturace dávek ZP. ANO, standardní funkčnost. |
|
|
Možnost odeslání dávek přímo z prostředí lékárenského IS na portály ZP. ANO, standardní funkčnost. |
|
|
Nastavení dalších parametrů chování programu při zpracování podkladů ZP - alespoň volba automatického uzavírání dokladů dle nastavených atributů (RČ, ICZ lékaře, DG) pro každou pojišťovnu zvlášť. Požaduje se možnost provádět kontrolu rodných čísel dle databáze pacientů nebo prostřednictvím webové služby poskytované integrační platformou Objednavatele (MPI). ANO, standardní funkčnost. Kontrola dle MPI - Nutno naprogramovat dle rozhraní Zadavatele. |
|
|
Systém musí mít vnitřní kontrolu správnosti vygenerovaných dávek receptů. ANO, standardní funkčnost. |
|
|
Vytvoření dávky pro pojišťovnu, kontrola dávky, vypořádání chybných dokladů a odeslání dávek i oprav ve zvláštních dávkách. ANO, standardní funkčnost. |
|
|
Vykazování kódu za ředění CL z nemocničního skladu – dávka z výpisů s kódy za přípravu CL. Kontrola, aby nebyl vykázán signální kód. ANO, standardní funkčnost. |
|
|
CL možnost vykazovat i příjmem a vykázáním „kdavky“z cytostatického modulu. ANO, standardní funkčnost, pokud je příprava realizována přes interní modul, v opačném případě bude součástí realizačního projektu (např. CATO). |
|
|
Kontrola na pojišťovnu v systému sledování vrácených dokladů dle typu a důvodu vratky od zdravotní pojišťovny. Po odeslání přes portál ZP –obdrží zadavatel odpověď o přijetí s výsledkem přijato, zpracováno a protokol o chybách. Schopnost načtení informací ze strukturovaného formátu z portálů zdravotních pojišťoven do nabízeného Řešení. Aktuálně nemáme informace o takové možnosti ze strany zdravotních pojišťoven. |
|
|
Vytvoření průvodních dokladů dávek pro pojišťovnu. ANO, standardní funkčnost. |
|
|
Vytvoření návrhu faktury. ANO, standardní funkčnost. |
|
|
Ze systému musí být možné získat statistické výstupy o odeslaných datech, vrácených datech, druzích chyb. Ano, v případě vrácených dokladů, je třeba důvody zadávat uživatelsky, protože strojově zpracovatelný protokol od zdravotních pojišťoven není dosud k dispozici.. |
Práce se všemi standardními číselníky a jejich správa:
|
|
Lékárenský systém musí zaručovat spolehlivou komunikaci s VZP, ostatními ZP, SÚKL, distributory LP i dalšími komerčními institucemi. ANO, standardní funkčnost. |
|
|
Bude používáno vždy platné rozhraní VZP včetně kontrolních mechanismů VZP zabudovaných přímo v systému. ANO, standardní funkčnost. |
|
|
Řešení musí zajistit aktualizaci, archivaci, uložení kompletní historie číselníků, možnost porovnávání číselníků, rozdílové výstupy. ANO, standardní funkčnost. |
|
|
Požadována je i kontrola položek bez vazeb na číselníky SÚKL, VZP, např. u nehrazených LP. Ano, kontrola je k dispozici u polí kritických pro práci systému (např. DPH, Regulace, Úhrada, …) |
|
|
Požadováno je vyhledávání v těchto číselnících s využitím všech dostupných polí, filtrování, export. ANO, standardní funkčnost. |
|
|
Lékárenský systém musí zajistit komunikaci s VZP, ostatními ZP, SÚKL, distributory LP i dalšími komerčními institucemi. Bude používáno vždy platné rozhraní VZP včetně kontrolních mechanismů VZP zabudovaných přímo v systému. ANO, standardní funkčnost. |
|
|
Řešení musí zajistit automatickou i ruční údržbu dostupných aktuálních číselníků (ve zvoleném čase) a to kontinuálně s běžným provozem bez potřeby odstávky systému. ANO, standardní funkčnost. |
|
|
Integrované číselníky je požadováno udržovat a aktualizovat automaticky při každé změně - (SCAU, SCAU-ZP, PDK, DLP). ANO, standardní funkčnost. |
|
|
Je požadováno udržovat I ostatní číselníky (SÚKL SCAU, Taxa laborum, ATC, Diagnózy, Odbornosti, lékaři, NLEKY). ANO, standardní funkčnost. |
|
|
Je požadována aktualizace - Kódy EAN, výrobci/držitelé reg. rozhodnutí, diagnózy – MKN-10. ANO, standardní funkčnost.
|
|
|
Důležité zprávy a údaje, týkající se číselníků, požadujeme zobrazovat v rámci informačních kanálů. ANO, standardní funkčnost. |
|
|
Kontroly, rozdílové sestavy verzí číselníků, změny úhrad, limitů atd., požadujeme prohlížet, tisknout. ANO, standardní funkčnost. |
|
|
Požadujeme udržovat historii číselníků. ANO, standardní funkčnost. |
|
|
Je požadována integrace na Registr pojištěnců, on-line kontrola B2B, lékové interakce Infopharm, AISLP. ANO, standardní funkčnost. Lékové interakce infopharm a AISLP jsou komerční databáze. IS je podporuje, podmínkou je zakoupení licencí ze strany Zadavatele. Není součástí dodávky. |
|
|
Požadavkem je update lékárenského systému automaticky bez zásahu obsluhy. ANO, standardní funkčnost. |
|
|
Aktuálnost verze i číselníků musí být automaticky při spuštění kontrolována na klientských stanicích. ANO, standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
|
|
Systém musí být programován a udržován aktuální v souladu s platnou legislativou, především pak s legislativou uvedenou v bodu - Legislativní rámec. ANO, standardní funkčnost.
|
|
|
Ekonomické operace musí být integrovány do ERP MS Navision NAV, a to dle platné legislativy. Integraci provedeme na základě zadání v Realizačním projektu. |
|
|
Na základě výstupů z lékárenského IS musí být zajištěno v ERP zachycení věrného a poctivého obrazu činností vykonávaných a evidovaných v rámci lékárenského IS. ANO, standardní funkčnost. |
|
|
Propojení lékárenského IS s ERP musí být automatizované Viz P.227 |
|
|
Veškeré operace a pohyby prováděné v rámci lékárenského IS, které mají vliv na správné zaúčtování pořizovací ceny, evidenci skladových zásob, evidenci spotřeby, nákladů atd., musí být součástí výstupu pro ERP (alespoň příjmy, vratky, výdeje, opravy, inventarizační rozdíly, exspirované a poškozené ZM – likvidace, převody, reklamace, naturální bonusy, zaokrouhlování, náklady na služby, změny odpočtu DPH, změna ocenění v rámci PDP a RCH, celní poplatky, dopravné a balné, které musí vstoupit do ceny materiálu a zboží). Dle vyhlášky 410/2009 Sb. § 57. Viz P.227 |
|
|
Veškeré operace v rámci lékárenského IS musí být prováděny v souladu se zákonem č. 235/2004 Sb. v platném znění - tzn. evidence DPH na vstupu, DPH na výstupu, možnost uplatnění či neuplatnění odpočtu DPH ve vztahu ke konkrétnímu příjmu a faktuře, možnost volby plného odpočtu vs. kráticího koeficientu při uplatnění odpočtu DPH (v případě kráceného nároku na odpočet možnost volby na úrovni skladové karty), přenesená daňová povinnost a řešení problematiky DPH a evidence hodnoty skladové zásoby v návaznosti na unijní obchod a obchod s dodavateli ze třetích zemí. Uplatnění odpočtu DPH musí být umožněno provádět bez nutnosti rozdělit skladové hospodářství na více samostatných skladů nebo zakládání více skladových karet pro totožné zboží, a to při zachování možnosti uživatelské volby uplatnění nebo neuplatnění odpočtu DPH ve vztahu ke konkrétnímu příjmu a faktuře. Viz P.227 |
|
|
Veškeré operace ovlivňující evidenci DPH, které jsou realizovány na straně lékárenského IS, musí být součástí integrační vazby s ERP. Prostřednictvím integrační vazby musí být zajištěno vedení jednotné centrální evidence DPH v ERP. V rámci LeIS musí být vedena i záznamní povinnost k DPH dle platné legislativy. Přenos dat bude součástí realizačního projektu |
|
|
Objednavatel požaduje, aby konečný a rozhodující uživatelský výběr možnosti uplatnění odpočtu DPH na vstupu, včetně jeho konkrétní podoby, byl až ve fázi odsouhlasení faktury s příjemkou, a to bez ovlivnění možnosti provedení příjmu a výdeje zboží ze skladu, či jiných skladových pohybů (s výjimkou externího prodeje). Příjem a výdej tohoto zboží musí být možné provádět dříve, než bude provedeno konečné odsouhlasení faktury. Do té doby musí být zboží evidováno pouze kusově, popř. v orientační hodnotě. V rámci konečného odsouhlasení faktury musí být schvalovatel schopen upravit i ceny, včetně určení, v jakém režimu bude z hlediska DPH a finanční hodnoty zboží evidováno a faktura likvidována. Možnost uplatnění dodatečného odpočtu DPH v Objednavatelem stanovených situacích u příjmů, kde odpočet DPH při příjmu původně uplatněn nebyl, a to při splnění časových podmínek platných pro možnost odpočtu DPH (možnost storna pohybů, odpočtu na základě generovaných sestav pro externí výdaje u zboží, u kterého nebyl v době příjmu uplatněn odpočet DPH na vstupu (uplatnění plného, žádného či kráceného nároku na odpočet DPH). V rámci systému podporujeme určení odpočtu DPH na základě místa výdeje (nemocnice, centrum, veřejná část). Individuální nastavování budeme řešit v rámci realizačního projektu. |
|
|
Automatizované rozpočítávání nákladů na pořízení do pořizovací ceny (např. poměrové rozpočítávání nákladů na pořízení ve vztahu k definované skupině příjmů v rámci faktury – např. náklady na dopravu, montáž, balné). V rámci systému je k dispozici zahrnutí nákladů jako položky faktury. Rozpočtení do pořizovací ceny budeme řešit v rámci realizačního projektu. |
|
|
Automatizované řešení problematiky zaokrouhlování, včetně přenosu s tím souvisejících dat do účetního systému – řešení problematiky rozdílu mezi fakturovanou cenou a cenou evidovaného příjmu způsobené např. zaokrouhlením dodavatele na faktuře. Viz P.227 |
|
|
Automatizované řešení problematiky účtování příjmu zboží a materiálu na sklad a zboží a materiál na cestě, a to zejména v situacích, kdy ke konkrétnímu daňovému dokladu budou příjmy materiálu a zboží spadat do dvou různých měsíců (období). Na základě výstupů z lékárenského IS musí být příjmy spadající do stejného měsíčního období účtovány ve stejném období (tzn. v závislosti na měsíci, v jakém byly příjmy vyhotoveny). Viz P.227 |
|
|
Možnost souběžného účtování do dvou měsíčních období. Viz P.227 |
|
|
Možnost při příjmu zadávat i jiné typy nákladů s generováním podkladů pro samostatný účetní záznam – náklady, které nevstupují do pořizovací ceny zboží. Viz. P234 |
|
|
Veškeré výpočty v systému musí být prováděny na 2 desetinná místa, popř. na jiný počet desetinných míst, a to tak, aby v rámci integrační vazby byla zajištěna mezi lékárenským IS a integrita dat (v obou systémech musí být data evidována ve shodné výši). ANO, standardní funkčnost.
|
|
|
Veškeré výstupy importované do ERP, týkající se pohybu zboží (alespoň příjem, výdej, spotřeba), musí být exportovatelné do ERP na úrovni pohybu jednotlivých položek (a to alespoň tak, že součástí integrační vazby s ERP musí být v oblasti přijatých faktur i věcné plnění po položkách – tj. až na úroveň konkrétních příjmů na skladové karty atd.). Propojení skladových pohybů do účetnictví musí býtpoložkovými účetními doklady s vazbou jednotlivých položek na číslopříjemky, výdejky atd. Viz P.227 |
|
|
Veškeré výstupy určené pro ERP musí být zpětně identifikovatelné a musí odpovídat záznamům v lékárenském IS. ANO |
|
|
Veškeré výstupy určené pro účetní záznamy musí být upraveny tak, aby bylo zachováno rozdělení evidence účetní hodnoty zásob, nákladů a výnosů dle nastavených analytických účtů a dalšího vnitřního členění (alespoň nákladová střediska, zdroje financování, druh nákladu atd.). Bude součástí zadaní v rámci realizačního projektu. |
|
|
V rámci lékárenského IS musí být řešena, s ohledem na datové výstupy pro ERP, problematika časového nesouladu mezi datem spotřeby a datem fakturace dodávky, a to v případech, kdy datum spotřeby bude dříve než datum fakturace (problematika zaokrouhlování faktur, faktura musí být v hodnotě, na kterou byla dodavatelem vystavena – nelze uzavřít faktura bez provedení zaokrouhlení na částku faktury). ANO, standardní funkčnost. |
|
|
Výstupy generované lékárenským IS pro ERP nesmí obsahovat zaznamenané pohyby duplicitně. ANO, standardní funkčnost. |
|
|
Veškeré výstupy z lékárenského IS musí být do ERP exportovány automatizovaně v čase a intervalu stanoveném Objednavatelem dle jeho potřeb (s ohledem na charakter výstupu budou konkrétní časové okamžiky upřesněny v rámci implementační analýzy). ANO, standardní funkčnost. Exporty se spouští pomocí naplánované úlohy, čas a frekvenci je možné definovat. Exporty lze (např. V uzávěrce) spustit i ručně. |
|
|
V rámci lékárenského IS musí být používány minimálně následující data: • V oblasti příjmu: datum fyzického příjmu na sklad, datum uskutečnění zdanitelného plnění, datum doručení nebo přijetí faktury, datum splatnosti faktury, datum uskutečnění zdanitelného plnění dodavatele,variabilní symbol a externí číslo dokladu (tato data musí být editovatelná) • Oblasti výdeje: datum vydání ze skladu, datum vystavení faktury, DUZP, datum splatnosti • Pro všechny pohyby: evidence pracovního a účetního data (s možností uživatelského nastavení na úrovni konkrétního uživatele libovolně zpětně – tj. možnost záznamu pracovního data a pořizování daných operací k jinému dni, měsíci a roku než aktuální datum). ANO, standardní funkčnost. |
|
|
U veškerých pohybů, změn, oprav atd., provedených v rámci lékárenského IS musí být evidován alespoň systémový datum a čas, ID osob provádějících daný úkon. ANO, standardní funkčnost. |
|
|
Účetní pohyb reklamace: při vrácení zajistit evidenci vůči původnímu dodavateli tak, aby nedošlo k ovlivnění skladové zásoby (ani kusy ani finance). Neúčetní evidenci reklamací vypořádat záměnou zboží. V případě dobropisu (vrácení finančních prostředků) musí být zajištěn odpovídající datový výstup do ERP. Informační systém podporuje evidenci vratek vůči dodavateli včetně jejich vypořádání ve sběrných fakturách a dobropisech. Dokud není vratka přiřazena k daňovému dokladu není součástí výstupů do účetnictví. |
|
|
Předkontace, konfigurace dokladů a atributů pro přenos do ERP. ANO, standardní funkčnost. V případě, kdy bude nutné rozšířit, bude zařazeno do realizačního projektu. |
|
|
Problematika pokladních operací - položkové přenosy vč. Záznamu o DPH do ERP, týká se i plateb kartou uskutečněných na pokladně. ANO, standardní funkčnost. V rámci realizačního projektu bude navázáno na rozhraní pro export do ERP. |
|
|
Rozlišení pohybů, které se týkají zboží či materiálu. ANO, standardní funkčnost. |
|
|
Problematika přenosů vystavených faktur. ANO, standardní funkčnost. |
|
|
Fakturace mimo ZP - možnost různých režimů zdanění, vystavení dobropisů či vrubopisů k daným plněním. V případě storna pak samostatný doklad, který musí být přenesen do ERP. Nelze provést přepis či opravu vystaveného dokladu. Možnost uvedení odlišného DUZP od data vystavení dokladu. ANO, standardní funkčnost. |
|
|
Vedení pokladen - vč. Jejich inventarizací a přesunů mezí pokladnami v rámci FN Brno - vč. Záznamů do ERP. ANO, standardní funkčnost. V rámci realizačního projektu bude navázáno na rozhraní pro export do ERP. |
|
|
Přenos údajů o veřejných zakázkách z faktur do ERP. ANO, standardní funkčnost. V rámci realizačního projektu bude navázáno na rozhraní pro export do ERP. |
|
|
Přenos vystavených faktur a dobropisů, a to jak do položek odběratele, tak i do položek účetnictví a DPH v ERP, stejně tak i pokladních dokladů a plateb kartou. V rámci realizačního projektu bude navázáno na rozhraní pro export do ERP.
|
Základní (minimální) požadavky na požadované řešení:
|
|
Konsolidace ekonomických dat a možnost tato data následně „rozkládat“. Nutno naprogramovat export do MIS dle zadání Zadavatele. |
|
|
Sloučení a následná analýza ekonomických dat týkajících se provozu jednotlivých skladů. Viz P.257 |
|
|
Požadavek na data pro ekonomické řízení – alespoň položkový přenos veškerých pohybů za uživatelsky definované období. Viz P.257 |
|
|
Správa číselníku centrových léčiv - LP, NS, ZP, DG, IČP, Platnost od, Platnost do, Název, Poznámka, kód VZP, ATC skupina, Uznáno od, Uznáno do, Kód Diagnostické skupiny, Typ (atribut možnosti centrového LP bez vazby na ZP a NS (paragraf 16, atp.) – tzn. odlišení centrových léčiv jako takových a paragrafu 16, včetně možnosti nastavení účtování na odlišná účetní konta).
Správa centrových léčiv se odvíjí od potřeby zajištění účtování nákladů na různá účetní konta dle nastavení centrových léčiv. Dle nastavení jednotlivých atributů (LP, NS, ZP, …) se vyhodnotí, zda jde pro dané NS o centrové léčivo (léčivo par. 16) či nikoliv a na jaké účetní konto se bude účtovat. Pokud jde o centrové léčivo (léčivo par. 16) nebude vstupovat do rozpočtu dané kliniky. V rámci správy je požadováno jak ruční vložení jednotlivých atributů, tak hromadný import těchto atributů v rámci předem definované struktury (minimálně z formátu xls, xlsx). Příklad:
ANO |
|
|
Vyhodnocování alespoň centrových léčiv, ZULP a ZUM, radiofarmak dle stanovených algoritmů. Bude řešeno v rámci realizačního projektu |
|
|
Možnost nastavení úrovně schvalování alespoň dle % čerpání a typu žádanky. Limity schvalování žádanek je standardní funkčnost, v rámci realizačního projektu bude třeba řešit případné úpravy eskalačního procesu. |
|
|
Možnost variantní blokace rozpočtu alespoň dle typu střediska, výjimky středisek (LP a ZM dohromady nebo LP a ZM zvlášť, % uzavření LP, % uzavření ZM), typ období (měsíc, kvartál)
Limity schvalování žádanek je standardní funkčnost, v rámci realizačního projektu bude třeba řešit případné úpravy eskalačního procesu. |
|
|
Možnost variantního odblokování rozpočtu – do konce období, pro každou žádanku zvlášť, do překročení určitého %. Limity schvalování žádanek je standardní funkčnost, v rámci realizačního projektu bude třeba řešit případné úpravy eskalačního procesu. |
|
|
Požadavek na výstupy ve formátu XLSX a CSV. ANO, standardní funkčnost. |
Základní (minimální) požadavky na požadované řešení:
# |
Požadavky na další funkčnosti |
Měrné ceny, cenovky |
|
|
|
Lékárenský systém musí tisknout cenovky jak na čistý papír A4, tak i na samolepící etikety (tiskárny čárových kódů). ANO, standardní funkčnost. |
|
|
U položek, kde je to legislativně či jinak vyžadováno, musí být uvedena i přepočtená měrná cena s nastavením vztažné jednotky (např. na 100 g). ANO, standardní funkčnost. |
|
|
Rozměry a texty na cenovce musí být nastavitelné v systému dle požadavku uživatelů. ANO, standardní funkčnost, po úpravě dodaného vzoru. |
|
|
Koeficienty přepočtu měrných cen systém použije z PDK číselníku, případně je uživatel může k danému přípravku zadat ručně. ANO, standardní funkčnost. |
Informace SÚKL o závadách v jakosti LP |
|
|
|
Lékárenský systém musí disponovat informačními kanály on-line napojenými na portál SÚKL. ANO, standardní funkčnost. |
|
|
Zprávy o závadách LP budou automaticky stahovány a musí být možné je dle konfigurace zobrazovat při spuštění počítačů na jednotlivých stanicích. ANO, standardní funkčnost. |
|
|
Zaslání zpětného potvrzení o přečtení na SÚKL. ANO, standardní funkčnost. |
Statistiky |
|
|
|
Podklady pro statistiku ÚZIS. Lékárenský IS musí generovat do sestavy dle požadavků ÚZIS a automaticky e-mailem odesílat na nastaveného adresáta dle stavu dohod s ÚZIS . ANO, standardní funkčnost. Způsob automatického odesílání mailem je třeba definovat. |
|
|
Vedení elektronické knihy omamných a psychotropních látek dle platné legislativy. Roční hlášení OaPL pro SÚKL, který musí být generováno ze všech skladů v požadované struktuře (název přípravku, kód SÚKL, celkový stav položky na skladu k 1.1.RRRR, příjem, výdej na recept nebo žádanku, vratky, odpis, celkový stav položky na skladu k 31.12.RRRR). Hlášení opiátů na SÚKL je standardní funkčnost, Elektronická evidence opiátů bude k dispozici v okamžiku nasazení. |
|
|
Jednotlivé příjmy, nákupy a výdeje opiátů dle jednotlivých lokací (skladů) automaticky propisovat do speciální datové tabulky, která bude zdrojem dat pro požadovaný výstup, alespoň ve formátu XLS (XLSX), a odesílat mailem na nastaveného adresáta. Elektronická evidence opiátů bude k dispozici v okamžiku nasazení. |
Základní (minimální) požadavky na požadované řešení:
|
|
Přístup k sestavám podle uživatelských rolí a kompetencí (alespoň příslušnost k NS, klinice). ANO, standardní funkčnost. |
|
|
Uživatelská definice reportů s možností jejich uložení pro další použití. ANO, standardní funkčnost. |
|
|
Vizuální úprava výstupů bude navržena dodavatelem a realizována buď systémem uživatelských šablon umožňující úpravy uživatelem, případně úpravy dodavatelem jako povinná součást provozní podpory. ANO, standardní funkčnost dle požadavku. |
|
|
Reporting musí být zajištěn jak nad daty živými, tak nad daty migrovanými. ANO, databázově budou oddělena data živá od dat migrovaných. |
|
|
Jednotlivé reporty budou definovány v rámci implementačního projektu. ANO, podrobněji bude v realizačním projektu.
|
|
|
Řešení umožní automatické spouštění plánovaných úloh pro tvorbu reportů s definovanými parametry ve zvoleném čase a bez nutnosti žásahu uživatele. ANO, u některých sestav možno nyní naskriptovat. |
Požadovány jsou reporty dvojího druhu: |
|
|
|
a/ statické výstupy v přesně definované grafické podobě (alespoň DOC, DOCX, PDF) ANO, standardní funkčnost. |
|
|
b/ obecný export dat, kde je možné zpracovat data z celé databáze na základě definovaných kritérií, včetně dat převedených při migraci z předchozích IS (historických dat). Možnost nastavení exportu získaného souboru do formátu alespoň XLS, XLSX, XML, CSV, TXT, PDF. Definice “obecného exportu” bude součástí realizačního projektu. |
Základní sada reportů: |
|
|
|
Sestavy pro uživatele žádankového systému (čerpání, rozpočet):
ANO, standardní funkčnost. Součástí realizačního projektu bude rozšíření sestav o údaje, které vyplynou ze algoritmů schvalovacího procesu. |
|
|
Sestavy pro účetní uzávěrku musí být k dispozici v tištěné I elektronické podobě a dodržen a naplněn princip zákona o účetnictví. Sestavy slouží jako kontrolní mechanismus k integracím do ERP, požadovány jsou alespoň v rozsahu alespoň:
ANO, standardní funkčnost. |
|
|
Sestavy pro management lékárny:
ANO, standardní funkčnost. Součástí realizačního projektu bude zpřesnění zadání těchto reportů. |
|
|
Z veřejné části:
ANO, standardní funkčnost. |
|
|
Z nemocniční části:
ANO, standardní funkčnost.
|
Napříč nemocniční částí lékárenského IS je v případě zadávání RČ požadováno řešení integrace s IP (MPI)si.
V rámci terminologie je žádanka vnímána jako objednávka z oddělení nemocnice. Po převzetí žádanky ze strany lékárny se stav žádanky mění na výdejku. Žádanka ve vztahu k výdejce může být 1:1 nebo M:N s odkazem na primární žádanku. Elektronické žádanky slouží k objednávání potřebného sortimentu z oddělení nemocnice. Primárně se žádanky dělí na žádanky na oddělení a žádanky na pacienta. Tvorba elektronické žádanky se předpokládá jak v běžném režimu, tak i v režimu Statim.
Základní (minimální) požadavky na požadované řešení:
|
|
Uživatelé na odděleních nemocnice musí mít možnost sortiment objednávat jak dle PL (pokud je potřeba, každé oddělení může mít i svůj PL), tak i dle svých úrovní oprávnění i mimo PL. ANO, standardní funkčnost. |
|
|
Potřeba nastavit kritérium pro položky, které má nebo nemá vidět jednotlivé oddělení nemocnice, tj. tzv. „viditelnost položek“. V tomto okamžiku je k dispozici možnost oddělit typ sortimentu dle typu žádanky (ATB, Běžná, Centrové léky, Cyto). Dále pak je k dispozici možnost řídit pozitivní list pro každé oddělení zvlášť. V případě, dalších podmínek, bude součástí realizačního projektu. |
|
|
Filtrace položek – zobrazování různých skupin položek. V rámci modulů je možné vyhledávat a filtrovat dle různých kritérií včetně konkrétního sortimentu, v případě dalších podmínek, bude součástí realizačního projektu. |
|
|
Pozitivní list bude tvořen pracovníky lékárny a musí být synchronizován směrem k uživatelům v rámci žádankového systému. ANO, standardní funkčnost.
|
|
|
Žádanku je požadováno vytvořit, schválit, odeslat na základě nastavení uživatelských práv.. ANO, standardní funkčnost.
|
|
|
Požadavkem je možnost tvořit žádanky: a/ dle jednotlivých typů (PL, ATB, LP speciální, Infuze a desinfekce, Labochemikálie, PP, Medicinální plyny, ZM, ZM speciální, DDM ZM, Krevní deriváty, Studie, Vaky) b/ tvořit jednu žádanku s rozpadem dle jednotlivých typů v lékárně, bude-li z provozního hlediska požadováno Ano, standardní funkčnost, kromě Vaků. Rozpad žádanek na straně lékárny dle různých kritérií (např. Skupina sortimentu, umístění, skladování, lednice, ...). |
|
|
Jednotlivé typy žádanek musí být konfigurovatelné správcem LeIS alespoň v rámci povinnosti vyplnění jednotlivých polí (RČ, jméno, DG, sériové číslo, číslo pacienta, číslo medikace) i v rámci workflow schvalovacího procesu. Ano, standardní funkčnost. |
|
|
Možnost nastavení vazby mezi LP a diagnózou (vybraná LP se mohou objednávat pouze k vybrané diagnóze, vazba M:N). Ano, splňuje. U některých typů žádanek potřeba provést přizpůsobení na základě konkrétních podmínek zadavatele. Bude popsáno v Realizačním projektu. |
|
|
Tvorba dokladů, jejich schvalování, editace či odeslání do lékárny musí být řízena systémem přidělení oprávnění jednotlivým uživatelům. ANO, standardní funkčnost. |
|
|
Možnost nastavení uživatelských oprávnění i k definovaným položkám či skupinám položek. Aktuálně je sortiment řízen pomocí pozitivních listů. Upřesnění algoritmu bude součástí realizačního projektu. |
|
|
Pro objednávání vázaných antibiotik musí být elektronická podpora procesu schvalování antibiotickým střediskem. ANO, standardní funkčnost. |
|
|
Pro objednávání centrových LP omezení pouze na centrová LP. ANO, standardní funkčnost. |
|
|
Primární nastavení centrových LP se musí odvíjet od příznaku na kartě LP (centrové LP A/N), dále pak od příznaku na nákladovém středisku. Ano, splňuje, jedná se o standardní funkčnost. Řešení předpokládá jedno nákladové středisko centrové léčby pro nemocnici. Podporu více nákladových středisek zrealizujeme dle přesného zadání zadavatele a bude popsáno v Realizačním projektu.
|
|
|
Sekundární nastavení pak musí vycházet z číselníku centrových LP, který je již komplexnější maticí LP, nákladového střediska, pojišťovny, ATC skupiny, diagnózy, typu (standard nebo pragraf 16), kódu diagnostické skupiny, IČP, případně rodného čísla, to vše s určením platnosti pro dané období a uznáním pojišťovny pro dané období. Bude zařazeno do realizačního projektu na základě poskytnuté matice. |
|
|
Cytostatické žádanky slouží k objednání jednotlivých žádanek cytostatických příprav pro konkrétního pacienta na základě zvoleného protokolu. ANO, standardní funkčnost. |
|
|
Požadována je integrace s NIS (proklik z NIS do lékárenského IS do modulu CT). ANO, standardní funkčnost. ▇▇▇▇▇▇ dokumentaci pro zadání dodavateli NIS. |
|
|
Žádanky budou generovány:
Bod a bude součástí realizačního projektu |
|
|
Objednávání DDHM je zvláštním typem žádanky pro drobný dlouhodobý hmotný majetek se specifickým schvalovacím procesem a s vazbou a nutností automatického přenosu dat do položek operativní evidence ERP. Bod a bude součástí realizačního projektu |
|
|
Žádanky konsignačních skladů zachycují spotřebu zboží odebraného z konsignačního skladu na konkrétního pacienta v aktuálním čase a v rámci UDI identifikace zdravotnických prostředků. Zadavatel požaduje, aby těžký i lehký klient umožňovaly načtení číselných a alfanumerických znaků (UDI, Barcode apod.) pomocí skeneru čárového kódu. ANO, standardní funkčnost. Podpora UDI v rámci prohlížeče záleží na zařízeních, která jsou k dispozici pro načtení, podpora je k dispozici v rámci mobilních zařízení pomocí 2D čtečky nebo kamery zařízení v rámci desktopu bude nutné ověření v případě využití zařízení pro načtení ve více systémech (např. NIS). Bude proto součástí realizačního projektu. |
|
|
Žádanky na medicinální plyny
Bod a bude součástí realizačního projektu |
Tvorba žádanky |
|
|
|
Tvorba žádanky bez vazby na pacienta bude vycházet z PL. ANO, standardní funkčnost. |
|
|
Tvorba žádanky na pacienta bude vycházet z konfigurace dle typu žádanky a podléhat dalším povinným atributům vyplnění. Žádanky na pacienta budou podléhat různým kritériím. ANO, standardní funkčnost. Aktuálně k dispozici u všech typů žádanek, v případě běžné žádanky je údaj na rozhodnutí objednatele. Upřesnění pravidel bude součástí realizačního projektu. |
|
|
Vyhodnocuje se, zda jde o vázané ATB, zda jde o centrové LP, zda jde o ZULP, zda je dané LP a ZM pro dané nákladové středisko v pozitivním listu. ANO, standardní funkčnost. V případě ZULP je třeba v rámci realizačního projektu implementovat matici zadavatele. |
|
|
V žádance musí být pole poznámka, která se zobrazí pracovníkům v lékárně, jak k hlavičce, tak i ke konkrétní položce. ANO, standardní funkčnost.
|
|
|
Objednavatel požaduje parametrizaci kontrolních mechanismů nad jednotlivými typy žádanek (povinnostní vyplnění definovaných polí a blokace v rámci rozpočtu). Definice bude součástí realizačního projektu. Viz. P.263, P.264, ... |
|
|
Požadavek na parametrizaci, schvalovací procesy (možnost víceúrovňového schvalování), notifikaci. Aktuálně je možné provést tří úrovňový schvalovací proces. Implementace dle algoritmu zadavatele bude součástí realizačního projektu. |
|
|
Možnost nastavení úrovní schvalování (alespoň vždy, při překročení rozpočtu, dle druhu žádanky). Viz. P.314 |
|
|
Sledování rozpočtu, blokace rozpočtu, schvalování i notifikace musí být parametrická za sledovaná účetní konta, nákladová střediska, skupiny nákladových středisek, typy žádanek, kategorie (LP a ZM). Viz. P.263, P.264. Customizace bude realizována v rámci realizačního projektu. |
|
|
Novou žádanku musí být možné vytvořit manuálním vstupem všech položek vybraných z pozitivního listu lékárny a kopírováním již v minulosti vytvořené žádanky včetně její editace. Výběr položek musí probíhat alespoň následujícími způsoby – SÚKL kód, název, řetězec (fulltext), EAN, GTIN. Ano, splňujeme. Jedná se o standardní funkčnost vyhledání dle názvu a SUKL kódu, EAN, ATC, skupiny sortimentu, GTIN, 2D data matrix, UDI. |
|
|
V okamžiku tvorby žádanky musí mít uživatel přehled o on-line stavu objednávaných položek. ANO, standardní funkčnost. |
|
|
Jednotlivá oddělení musí mít možnost online sledovat „své náklady“ z dosud realizovaných objednávek dle nastavených parametrů včetně nezaúčtovaných objednávek. ANO, standardní funkčnost. Úpravy dle P.263, P.264 budou součástí realizačního projektu. |
|
|
Požadavek na filtrování dle stavu žádanky – alespoň vytvořená, schválená, odeslaná, potvrzená – ve stavu již zaúčtované a převzaté výdejky. ANO, standardní funkčnost. |
|
|
Požadavek na potvrzování převzetí - jakmile je žádanka zaúčtovaná nemocniční lékárnou, potvrzuje elektronicky oddělení převzetí požadovaného LP a ZM. ANO, standardní funkčnost. |
Cytostatická léčba |
|
|
|
Modul přípravy CL musí obsahovat Protokoly léčby (režimy), Plány léčby, Žádankový systém, Výdejkový systém - Cytostatickou přípravu, Podání LP a integraci do Výkaznictví. Viz. P.305, Integrace budou součástí realizačního projektu. |
|
|
V rámci modulu CT musí být vytvářen plán léčby pacienta, ze kterého jsou generovány žádanky na CL. V rámci tohoto modulu musí mít ošetřující lékař možnost naplánovat celý PLP. Nesmí zadávat pouze jednotlivé žádanky. Viz. P.305 Bude součástí realizačního projektu. |
|
|
PLP se musí vytvářet z předdefinovaného číselníku protokolů léčby. Ano, standardní funkčnost. Funkčnost plánů léčby z bodu 305 bude součástí realizačního projektu. |
|
|
PLP při vytváření nabídne primárně protokoly léčby, které se vážou s dg uvedenou v PLP, s možností zrušení filtru a výběru z celého číselníku protokolů navázaných k danému pracovišti. Ano, standardní funkčnost. Funkčnost plánů léčby z bodu 305 bude součástí realizačního projektu. |
|
|
V rámci modulu musí být k dispozici databáze chemoterapeutických protokolů, které budou implementovány ze stávajícího systému a následně vytvářeny v novém lékárenském IS. Ano, počítáme s převodem dat protokolů/režimů léčby z původního systému. Bude součástí migrace P.93 |
|
|
Každý protokol musí mít možnost několika verzí. Ano, standardní funkčnost. |
|
|
Každý PLP musí mít možnost souběhu protokolů. Ano, standardní funkčnost. Funkčnost plánů léčby z bodu 305 bude součástí realizačního projektu.
|
|
|
Požadavek na funkčnosti ze strany oddělení:
Ano, stadardní funčknost. Je třeba v rámci realizačního projektu doplnit podporu pro hodnocení léčby, potvrzení podání a statistiku vyhodnocení CT. |
Konsignační sklad |
|
|
|
V rámci modulu žádanek konsignačního skladu je požadováno vytvoření hlavičky žádanky ke konkrétnímu skladu (lokaci) včetně RČ a jména a příjmení s jejich průpisem do jednotlivých řádků a v řádcích žádanky se musí nabídnou pouze položky daného konsignačního skladu. Konfigurace žádanek bude součástí realizačního projektu. |
|
|
Položky daného skladu (lokace) musí být svázány s GTIN, tudíž musí být možné jednotlivé UDI do žádanky načítat (např. nad hlavičkou žádanky) a UDI do jednotlivých řádků žádanky. ANO, standardní funkčnost. Podpora UDI v rámci prohlížeče záleží na zařízeních, která jsou k dispozici pro načtení, podpora je k dispozici v rámci mobilních zařízení pomocí 2D čtečky nebo kamery zařízení v rámci desktopu bude nutné ověření v případě využití zařízení pro načtení ve více systémech (např. NIS). Bude proto součástí realizačního projektu.
|
Zpracování odeslaných žádanek, resp. převzatých výdejek. |
||||||
|
|
Výdejkový proces prochází několika definovanými stavy (alespoň vytvořená, schválená, potvrzená, objednaná, vykrytá, zaúčtovaná), dle kterých musí být možno žádanky filtrovat, a dále s nimi pracovat. ANO, standardní funkčnost. |
|||||
|
|
Požadavek na grafické zobrazení položek v žádance z pohledu existence na skladu. ANO, standardní funkčnost. |
|||||
|
|
Vzhledem k tomu, že jedna žádanka může obsahovat různé typy LP, např. z pohledu sortimentních skupin – HVLP, IPLP, musí být možné systém nakonfigurovat tak, že dojde k automatickému „rozpadu“ jedné žádanky na dvě či více dle těchto skupin např. z důvodu zpracování na různých odděleních lékárny nebo i na různých skladech lékárny. ANO, standardní funkčnost po sort. Skupinách. Rozdělování žádanek nutno nadefinovat. |
|||||
|
|
Při vykrývání žádanek v lékárně možnost postupovat tzv. „překlopením“ do výdejek na oddělení ze sortimentu, který je skladem. ANO, standardní funkčnost. |
|||||
|
|
Sortiment, který není momentálně k dispozici - možnost rovnou objednat či přidat k již existující objednávce. ANO, standardní funkčnost. |
|||||
|
|
Při zpracování žádanek/výdejek DDHM, musí Lékárenský IS umožňovat zajištění výdeje DDHM s návazností na operativní evidenci v ERP systému – připravit data pro evidenci DDHM (alespoň číslo majetku, název majetku, nákladové středisko, inventární úsek, množství, částka, jednoznačný identifikátor položky, účtoskupina DDHM, kód dodavatele, výrobní číslo DDHM) Integrace na ERP bude součástí realizačního projektu včetně upřesnění dat o DDHM. |
|||||
|
|
DDHM je po vyskladnění dále evidován v evidenci dlouhodobého drobného majetku, musí být tedy generováno číslo DDHM (integrace na ERP). Viz. Bod 337 |
|||||
|
|
Požadavek na storno zaúčtovaného výdeje napříč všemi typy výdejek, a to tak, že budou stornovány všechny atributy primárního dokladu, s dopadem do nákladů kliniky (vazba na rozpočet), s dopadem do skladu (vrácení na sklad - 2D, ČK, šarže), s dopadem do účtu pacienta (výkaznictví). Ano, všechna storna jsou v rámci řešení prováděna jako nový doklad s vazbou na původní, který bude zveřejněn stejně jako v původní doklad. |
|||||
Cytostatická léčba |
||||||
|
|
Lékárenský IS musí zahrnovat aktivní podporu přípravy CL. ANO, standardní funkčnost. |
|||||
|
|
Lékárenský IS musí pracovat s aktuálním stavem LP, ZM vstupujících do přípravy CL, tj. se skutečným stavem zásob v daném čase, přičemž:
ANO, standardní funkčnost.
|
|||||
|
|
Protokoly jsou v současném výchozím stavu strukturovány na hlavičku, řádek a detailní řádek protokolu. Do hlavičky se zadávají údaje platné pro celý protokol, do řádku konkrétní údaje k danému dni léčby, do detailního řádku konkrétní léčivé přípravky s množstvím vztaženým k jednotce. Minimální datovou strukturu si Zadavatel určí v Realizačním projektu. ANO, standardní funkčnost. Dle popisu standardní funkčnost, datová struktura je již daná. Rozšíření struktury bude možné. |
|||||
|
|
Lékárenský IS musí umožňovat nastavení kontrolních mechanismů a to alespoň :
Část kontrol je již k dispozici, zatím nepodporované budou doplněny v rámci realizačního projektu. |
|||||
|
|
Lékárenský IS musí automaticky účtovat pomocný materiál (číselník příprav). Ano, standardní funkčnost, dle receptury. |
|||||
|
|
Lékárenský IS musí sledovat veškeré náklady na léčbu pacienta. Ano, standardní funkčnost pro realizované přípravy a výdeje. |
|||||
|
|
Protokoly léčby musí umožňovat kopii protokolu a kopii verze protokolu. Ano, standardní funkčnost, lze kopírovat i část. |
|||||
|
|
Všechny činnosti spojené s cytostatickou přípravou musí být logovány, aby bylo možné dohledat, kdo a kdy prováděl jakou činnost. Ano, všechny operace jsou logovány na úrovni databáze. |
|||||
|
|
Požadována je možnost dvojího použití režimu modulu přípravy CL:
Bez rozpadu na jednotlivá ředění Cytostatická žádanka, která dorazí z oddělení, projde kontrolou ze strany lékárníka. Pokud je v pořádku, potvrdí žádanku a je možné dále žádanku zpracovat. Pokud není v pořádku, může ji tlačítkem zamítnout a zaslat zpět na opravu na oddělení. Po dohodě s lékařem může žádanku v lékárně zeditovat a upravit chybné údaje. Dále musí být možné při kontrole přiřadit k zaslaným položkám na žádance sortiment vedený v lékárně a zaslat pro kontrolu lékaři na oddělní. Po úspěšné kontrole dojde k samotné přípravě, kdy jsou v rámci systému zadány, nebo naskenovány jednotlivé položky předepsané na žádance. Po uložení se vytvoří výdejka a také CL recepty pro jednotlivé účinné látky a vykázané taxy laborum. Systém musí umožňovat nastavení tisku etiket pro jednotlivé vaky a obaly.
Přípravna – k dispozici jednotlivá ředění pro pacienty Cytostatická žádanka, která dorazí z oddělení, projde kontrolou ze strany pracovníka lékárny. Pokud je v pořádku, potvrdí žádanku a je možné dále žádanku zpracovat. Pokud není v pořádku, má možnost ji zamítnout a zaslat zpět na opravu na oddělení, nebo po dohodě s lékařem žádanku lékárníkem zeditovat a upravit chybné údaje. Požadavek na nastavitelný Storno interval před převzetím žádanky do režimu výdejka. Po uložení kontroly Převzetí žádanky – požadavek na rozpad na jednotlivé výdejky, tj. rozpad na jednotlivé přípravy, kdy každá příprava je samostatná výdejka. Do výdejky je provedeno načtení konkrétního přípravku (alespoň 2D kód, čárový kód, RFID kód, ručně výběrem ze skladových položek), požadavek na automatické a ruční vytištění etiket dle jednotlivých příprav.
Ostatní požadavky Sortimentní karty musí mít parametricky nastavené přepočty, systém automaticky musí hlídat a odečítat zadané množství. Po uložení jednotlivé přípravy je možnost zaúčtování nebo přesun do menu Cytostatika – BOX. Cytostatika – BOX - zobrazení v ředícím BOXU. Po zvolení konkrétního pacienta nutno zobrazit jednotlivé přípravy, včetně předepsané složení. Zde nutná kontrola a potvrzení u jednotlivých položek použití (alespoň 2D kód, čárový kód, RFID kód, ručně výběrem ANO/NE). Cytostatika – kompletace - zobrazit jednotlivé přípravy, které prošly boxem i v různých laboratořích, a jsou připravené. Po uložení konkrétní přípravy dojde k uzavření výdejky. Po načtení všech příprav dojde ke kompletaci žádanky/výdejky a jejímu uzavření. Ano, splňuje. Lékař určuje jakou formou chce ředění realizovat. V případě, že o způsobu ředění má rozhodovat lékárna, bude přizpůsobeno dle přesného zadání zadavatele v rámci Realizačního projektu.
|
|||||
|
||||||
Konsignační sklady Konsignační sklad je definován položkami zboží, množstvím, cenou položky zboží, GTIN (pokud má), platností - počátečním datem platnosti, po ukončení konečným datem platnosti. Proces KS je dán - prvotním naskladněním konsignačního skladu, udržováním aktuálních dodatků smluv, žádankovým systémem, účtováním spotřeby, generováním výdejek, objednávek, fakturace a doplněním konsignačního skladu. Do celého procesu vstupuje rovněž problematika UDI (MDR). Ve finančním účetnictví (ERP) je nutno KS sledovat na oddělených účtech . Ve smluvních vztazích je definováno, na jakém konsignačním skladu se nachází jaké zboží konsignačního skladu, v jakém množství, v jaké smluvní ceně, případně s jakým sériovým číslem, to vše s určením platnosti pro dané období a daný smluvní vztah. Lékárenský IS musí pracovat s online stavem ZM na konsignačním skladu (a to až na sériové číslo). |
||||||
|
|
Prvotní naskladnění položek konsignačních skladů i veškeré dodatky musí podléhat systému kontrol a pravidel vzorového souboru pro uzavření smlouvy či jejího dodatku. Šablona obsahuje v definované struktuře:
Systém podporuje načítání elektronických dodacích listů v různých EDI formátech. Konkrétní formát pro import bude součástí realizačního projektu. |
|||||
|
|
Požadavek na doklady Zaúčtováním výdejky konsignačního skladu vznikají doklady:
Ano, standardní funčknost za předpokladu, že jsou k dispozici data o normách, minimálních množstvích. Konkrátní vzhled dokladů bude řešen v rámci realizačního projektu. |
|||||
|
|
Při účtování zboží pro lokace (označení skladu) daného typu musí být kromě standardního výdeje zboží z konsignačního skladu vytvořeno i tzv. doplnění konsignačního skladu. Doplnění je určeno pro zabezpečení předem dohodnutého stavu na lokaci mezi FN Brno a dodavatelem. Doplnění je vždy vytvořeno podle množství zboží vydaného ze skladu s ohledem na stav dle smlouvy. Vznikají tyto pohyby:
Ano splňuje. IS obsahuje všechny potřebné údaje, které je třeba předat do účetnictví, jen je nezbytné dle konkrétního zadání zadavatele popsat postup, doklady a pole do Realizačního projektu.
|
|||||
|
|
Zaúčtováním výdejky konsignačního skladu musí být vytvořena nákupní objednávka na vydaný ZM. Z takto vytvořené nákupní objednávky musí být účtován příjem zboží na sklad. V nákupní objednávce musí být automaticky doplněno:
Vytvoření dokladů je standardní funčknost, specifické údaje (např. Kód nákupčího, ...) budou součástí realizačního projektu. |
|||||
|
|
Takto vytvořená nákupní objednávka musí být dále zpracovávána standardním postupem pro účtování nákupních dokladů (alespoň s vytvořením elektronické objednávky a odesláním poštovním klientem s automaticky vygenerovanými přílohami ve zvoleném formátu, a to alespoň XLS, XLSX a PDF – Žádost o fakturaci, Žádost o doplnění, Výdejka). Ano, sestavy jsou k dispozici, bude třeba upravit vzhled na míru v rámci realizačního projektu. |
|||||
|
|
Zaúčtováním výdejky konsignačního skladu musí být v položkách zboží účtován výdej zboží. Číslo účtovaného výdeje v položkách zboží je shodné s číslem výdejky účtované v konsignačním skladu. Ano splňuje. IS obsahuje všechny potřebné údaje, které je třeba předat do účetnictví, jen je nezbytné dle konkrétního zadání zadavatele popsat postup, doklady a pole do Realizačního projektu.
|
|||||
|
|
Systém musí umožňovat alespoň dvojí množství – kusy a balení. Balení je prioritní – doklady se generují až při naplnění spotřeby celého balení. Balení musí mít definovaný počet ks, až se počet ks na žádankách rovná počtu v balení, vygeneruje se výdejka do NL a následně objednávka. Až se počet ks na výdejkách rovná balení, generuje se objednávka. Ano, standardní funkčnost. Objednávka vzniká v hlavní jednotce. |
|||||
Požadavky na příruční sklady |
||||||
|
|
Naskladnění výdeje z NL na požadující pracoviště do příručního skladu. ANO, standardní funkčnost.
|
|||||
|
|
Z NL musí být automaticky parametricky odesílány vybrané pohyby karet (výdeje) do příručního skladu kliniky. Aktuálně se posílají pouze pohyby související s přípručním skladem (příjem/reklamace/objednávky). V případě dalších typů, bude součástí realizačního projektu. |
|||||
|
|
Možnost odepisování položek, nastavení minimální a maximální zásoby u jednotlivých položek a možnost automatického a ručního vytváření požadavku (žádanky) na doplnění zásob z NL. ANO, standardní funkčnost.
|
|||||
|
|
Z příručního skladu musí být odepisovány uživatelem definované spotřebované položky pomocí čtečky nebo ručně. Položky mohou disponovat měrnou jednotkou pro každý příruční sklad odlišnou od měrné jednotky NL. Ano standardní fučnost, podpora čteček 2D kódů bude prověřena v rámci realizačního projektu. |
|||||
|
|
Možnost přeskladnění mezi příručními sklady. Pracoviště vydávající - založí výdejku s položkami, pracoviště požadující - odsouhlasí a dojde k automatickému přeúčtování, včetně vazby na rozpočet. Ano standardní funkčnost.
|
|||||
|
|
Efektivní nástroj pro elektronickou evidence podání léků. Součástí řešení je mobilní termínál, pro podání léků je však nutná integrace s NIS, bude tedy součástí realizačního projektu. |
|||||
Zpracování výdejek |
||||||
|
|
Na straně nemocniční lékárny probíhá zpracování odeslaných žádanek z oddělení. ANO, standardní funkčnost. |
|||||
|
|
Nad výdejkami požadována funkčnost – načítání ručně, ze čteček, parametrický systém kontrol, řazení dle ATC, spárování záměn, spárování požadovaného LP a ZM a načtených 2D kódů. ANO, standardní funkčnost. |
|||||
|
|
Požadována je funkčnost generování objednávek z výdejek na preferovaného partnera (dodavatele).
Ano splňuje. Konkrétní vzhled sestavy s výslednou objednávkou bude přizpůsoben zadání zadavatele a na základě podrobného zadání uveden v Realizačním projektu. |
|||||
|
|
Objednávka musí být generována pouze k řádkům výdejky, které nejsou plně vykryté. ANO, standardní funkčnost. |
|||||
|
|
Možnost automatického vložení objednávky do e-mailu. ANO, nutno mít nainstalován Outlook nebo obdobný nástroj. |
|||||
Základní (minimální) požadavky na požadované řešení:
|
|
Sledování výdeje konkrétních LP a ZM konkrétním pacientům s ukládáním historie bez omezení počtu záznamů. Ano standardní funčknost, pokud máme k dispozici identifikátor pacienta. |
|
|
Požadavek na export ve struktuře alespoň: NS, RČ, ZP, Datum podání (zúčtovací datum), skupina léku (LP, ZM), kód léku SÚKL (PZT), množství, cena za jednotku (nákupní, nákupní s DPH, MFC), cena za množství. Ano standardní funkčnost modulu výstupy. |
|
|
Integrace do NIS pro vykázání LP a ZM plátci. Implementace integrační vazby bude součástí realizačního projektu. |
|
|
Požadavek na parametrizaci podkladů pro vykazování LP a ZM - dle typu žádanky (PL, ATB, LP speciální, ...), dle stavu žádanky/výdejky (odeslaná žádanka, zaúčtovaná výdejka, potvrzené podání, ...), dle konkrétního nastavení na kartě LP, ZM. Analýza integrovaných dat a pravidla pro výkaznictví budou stanovena zadavatelem v Realizačním projektu. Uvedená data jsou k dispozici, formát bude součástí realizačního projektu |
|
|
Jednodávkový system – lékový řetězec od zdravotnického pracovníka až ke konkrétnímu pacientovi – (maximální eliminace možnosti záměny léčiva nebo chybného podání).
Zadavatel připravuje technické řešení pro jednodávkový systém. Splnění tohoto požadavku proto provede dodavatel až na výzvu zadavatele. Bude součástí realizačního projektu. |
Základní (minimální) požadavky na požadované řešení:
# |
Obecné požadavky na veřejnou část |
|
|
Lékárenský systém musí disponovat funkcionalitou pro použití eRP (elektronického receptu) včetně kvalifikovaného elektronického podpisu a funkcionalitou e-poukazu. ANO, standardní funkčnost. |
Obecné požadavky na expedici |
|
|
|
Výdejní místa koncipovat jako univerzální s možností snadného přepínání mezi jednotlivými typy výdeje (dotykem, klikem myši, klávesovou zkratkou). ANO, standardní funkčnost. |
|
|
Výdejní místo koncipovat tak, aby byl podpořen jak rychlý a plynulý přechod mezi recepty, poukazy a volným prodejem, tak i požadavek na zpětné úpravy v seanci pacienta. ANO, standardní funkčnost. |
|
|
Možnost použít i platbu na poukázku partnera. ANO, standardní funkčnost. |
|
|
Možnost kombinovat typy plateb. ANO, standardní funkčnost. |
|
|
Umožnit, aby jedna prodejní transakce obsahovala více druhů dokladů (recept, poukaz, volný prodej). ANO, standardní funkčnost. |
|
|
Možnost použít uživatelské texty, hlavičky pro tisk dokladů – paragonů. ANO, text na paragonu může modifikovat správce. |
|
|
Nastavitelný počet tištěných dokladů. ANO, standardní funkčnost. |
|
|
Možnost provedení dodatečného tisku přímo na výdejním místě včetně dohledání dokladu. ANO, standardní funkčnost. |
|
|
Na výdejních místech možnost podpory jak klasických počítačů, tak i moderních dotykových monitorů typu „All In One“ dle nastavení systému. ANO, standardní funkčnost. |
|
|
Zadávání položek pomocí scanneru (vlastní nebo oficiální EAN č. kód) nebo z klávesnice (pomocí rychlého vstupu možnost vybírat dle mnoha možností - název, řetězec - fulltext, PDK, číslo zboží, SÚKL, ATC, cena). ANO, standardní funkčnost. |
Výdej na recept - na recept klasický i elektronický eRP (včetně e-receptu s omezením). |
|
|
|
Lékárenský IS musí disponovat i tzv. E-receptem vnitřním, kdy po sejmutí spec. čárového kódu z receptu pořízeného v ambulancích lékařů načíte hlavičku receptu včetně položek přímo z NIS nemocnice. Lékárník pouze zkontroluje hlavičku a položky. Z této funkcionality požadavek na tzv. „záchyt receptů“ ve vlastní lékárně. ANO, standardní funkčnost. |
|
|
Požadavky na funkcionalitu pro výdej receptů: Automatické vyplnění hlavičky u dalšího typu dokladu (recepty, poukazy). ANO, standardní funkčnost. |
|
|
Zadání údajů požadovaných pojišťovnou (vykázat/nevykázat výkon, nezaměňovat, zvýšená úhrada, diagnóza při zvýšené úhradě, úhrada schválená revizním lékařem). ANO, standardní funkčnost. |
|
|
Automatickou on-line kontrolu B2B registru pacientů VZP. Kontrola B2B probíhá na pozadí expedice a uživatel je na případné chyby upozorněn při uložení expedice. Kontrola B2B je funkční i během retaxace. ANO, standardní funkčnost. |
|
|
Částečný výdej receptu, tzn., že je-li z receptu obsahujícího dvě položky k dispozici pouze jedna či podobné kombinace, potom po vydání první položky, kterou má lékárna na skladě, se vytiskne pokladní kupon s čárovým kódem, se kterým si zákazník přijde pro „dovydání“ druhé položky částečného receptu. Chybějící položka se může dle konfigurace automaticky přenést do plánu objednávky. ANO, standardní funkčnost. |
|
|
Vyhledání generických přípravků, které jsou skladem i které nejsou skladem (z číselníku SÚKL, PDK) dle ATC a lékové formy. ANO, standardní funkčnost. |
|
|
Možnost vybírat i tzv. lékové ekvivalenty, tj. kromě LP látky se vybírá i podle množství v balení. ANO, standardní funkčnost. |
|
|
Možnost ambulantního pozitivního listu, dále pak možnost automaticky generovat a zasílat ceník veřejné lékárny do NIS. ANO, standardní funkčnost. |
|
|
Rezervace a objednávky přípravků, jak na pacienta, tak i pro partnery lékárny. ANO, standardní funkčnost. |
|
|
Vedení klientských (zákaznických) karet včetně sledování historie výdejů pacientů. ANO, standardní funkčnost. |
|
|
Předvyplnění hlavičky při použití klientské karty. ANO, standardní funkčnost. |
|
|
Sledování a vyhodnocování interakcí vydávaného přípravku u konkrétního pacienta na expedičním místě. Možnost vyvolat přehled tržeb a přehled odebraného zboží za zvolené období pro vybraného pacienta. ANO, standardní funkčnost je napojení Iterakce infopharm, podmíněno zakoupením licence. Licence není součástí dodávky. |
|
|
Tisk výpisu z receptu, tisk opisu receptu. ANO, standardní funkčnost. |
|
|
Vyhledávání v historii receptů, dotisky účtenek atd… ANO, standardní funkčnost. |
|
|
Řešení případu, kdy přípravek hrazený pojišťovnou hradí pacient, protože nemá nárok na úhradu – vyznačením příznaku nehrazeno. ANO, standardní funkčnost. |
|
|
Upozornění k vydávanému přípravku:
ANO, standardní funkčnost. |
|
|
Upozornění na nutnost vyplnění diagnózy při zadání zvýšené úhrady. ANO, standardní funkčnost. |
|
|
Podpora veterinárního receptu (DPH). ANO, standardní funkčnost. |
|
|
Implementace komunikace s NSOL dle nařízení FMD – ověření jedinečného identifikátoru a vyřazení jedinečného identifikátoru z úložiště. ANO, standardní funkčnost. |
Výdej bez lékařského předpisu |
|
|
|
Možnost výdeje za nastavenou akční cenu. ANO, standardní funkčnost. |
|
|
Používání zákaznické slevové karty. ANO, standardní funkčnost. |
|
|
Při expedici přípravků, které jsou vázány na lékařský předpis, nebo spadají do kategorie výdeje bez předpisu s omezením, upozornění na tuto skutečnost. ANO, standardní funkčnost. |
|
|
V případě potřeby oprav umožnit jednak editaci dokladu a jednak storno dokladu (identifikace stornujícího). ANO, standardní funkčnost. |
Výdej na poukaz – klasický i elektronický |
|
|
|
Výdej na poukaz, možnost zadání diagnózy. ANO, standardní funkčnost. |
|
|
Při výdeji na recept a poukaz možnost on-line ověření IČZ, IČP a rodných čísel (B2B) z portálu VZP. ANO, standardní funkčnost. |
|
|
Výdej bez lékařského předpisu s omezením dle platné legislativy. ANO, standardní funkčnost. |
|
|
Výdej na e-poukaz. ANO, standardní funkčnost. |
Výdej partnerům – podpora výdeje externím odběratelům |
|
|
|
I ve výdeji na partnery nutná implementace komunikace s NSOL dle nařízení FMD – ověření jedinečného identifikátoru, případně vyřazení jedinečného identifikátoru z úložiště. Zde možnost určit, zda má dojít k vyřazení jedinečného identifikátoru z úložiště, či nikoliv. ANO, standardní funkčnost. |
|
|
Výdejový dodací list možnost vytisknout v uživatelsky definovatelných variantách. ANO, standardní funkčnost. |
|
|
Zadávání položek výdejky ručně askenerem. Možný import alespoň přímo z příjemky pro daného odběratele. ANO, standardní funkčnost. |
|
|
Položky výdeje možno dobropisovat. ANO, standardní funkčnost. |
|
|
Možnost pracovat se slevami, a to jednak na základě nastavení obchodních podmínek přímo na odběrateli v číselníku, nebo nastavit individuální slevu na položce dodacího listu, či na celý dodací list. ANO, standardní funkčnost. |
|
|
Výdejové dodací listy možnost vyfakturovat jednotlivěi souhrnně pro konkrétního odběratele za určité období. ANO, standardní funkčnost. |
|
|
Vytvoření podkladů pro následnou fakturaci DL partnerům, která může být vytištěna exportována na určené uložiště. ANO, standardní funkčnost. |
|
|
Faktury za dodací listy možno exportovat ve známých formátech (alespoň PDF, ISDOC, DOC, DOCX) a zasílat odběratelům. ANO, standardní funkčnost. |
|
|
Platba na žádanky – doplatky. ANO, standardní funkčnost. |
|
|
Možnost jednoduchého výdeje pro cizí odběratele z nemocniční části. ANO, standardní funkčnost. |
Obecné požadavky |
|
|
|
Možnost pracovat s off-line a on-line připojenými platebními terminály. ANO, standardní funkčnost, potřebujeme znát konkrétního poskytovatele. |
|
|
Možnost realizovat platby jak hotově (v korunách, případně i v jiné měně), tak i kartou (přímá komunikace s platebním terminálem), poukázkami a kombinací všech způsobů. ANO, standardní funkčnost. |
|
|
Další funkcionalita pokladny:
ANO, standardní funkčnost. |
|
|
Možnost na každém výdejním místě otevření pokladny (pokladní deník). ANO, standardní funkčnost. |
|
|
Možnost provést převody jednotlivých pokladen do pokladny hlavní, se kterou se dále může pracovat. Vše musí probíhat s identifikací a právy přihlášených uživatelů. ANO, standardní funkčnost. |
|
|
Do pokladny každého výdejního místa zaznamenávat požadované údaje, zejména počáteční stav, pohyby uzávěrkové (tj. tržba, drobné příjmy a výdaje) hotově i ostatních typů platidel a pohyby běžné – odvod do banky, platba faktury v hotovosti. ANO, standardní funkčnost. |
|
|
Pokladní deník možné vytisknout, k dispozici vhodné, uživatelsky definovatelné sestavy s možností tisku, exportu do různých formátů. Tyto sestavy pak podkladem k zaúčtování denních tržeb a DPH. ANO, standardní funkčnost. |
|
|
Možnost dotisku libovolné účtenky z daného dne i z historie. ANO, standardní funkčnost. |
|
|
Zajištění funkcionality - na oddělení nemocnice v modulu Elektronických žádanek uživatel otevře speciální formulář - obdoba klasické žádanky, s náležitostmi receptu, vyplní jej pro pacienta, případně se vyplní automaticky dle propojení na NIS (MPI) a odešle stejně jako klasická žádanka do lékárny, a pacientovi se vytiskne doklad s kódem. Po načtení pacientova dokladu v lékárně do lékárenského SW je pacientovi vydán požadovaný LP. Vše je dokumentované a zanesené do podkladů pro vyúčtování. Ano, standardní funkčnost centrové žádanky/fomácího receptu, kromě zanesení podkladů do vyúčtování, bude součástí realizačního projektu jako integrace.
|
Obecné požadavky |
|
|
|
Lékárenský IS musí podporovat retaxaci receptů alespoň v těchto atributech - kontrola, oprava, dopracování pořízených výdejových dokladů. ANO, standardní funkčnost. |
|
|
Při nalezení chyby možnost standardně provést běžné opravy včetně možnosti zrušení dokladu. ANO, standardní funkčnost. |
|
|
Podporována on-line kontrola IČZ a rodných čísel přes VZP B2B portál. ANO, standardní funkčnost. |
|
|
Podporována automatická kontrola, zda na poukazech datum vystavení není vyšší než aktuální. ANO, standardní funkčnost. |
|
|
Všechny uživatelské zásahy v retaxaci systémem musí být zaznamenány včetně identifikace retaxujícího. ANO, standardní funkčnost. |
|
|
Uživatelská práva možno nastavit i pro retaxaci stejně jako pro jiné části systému. ANO, standardní funkčnost. |
|
|
Dopracování vrácených receptů a poukazů a vytvoření resp. jejich zařazení do opravných dávek. Stejně jako v každé historii dokladů možnost využít rozsáhlé funkce filtru. ANO, standardní funkčnost. |
|
|
Možnost uzavření oprav k určitému datu s tím, že všechny doklady se uzavírají vystavením faktury. ANO, standardní funkčnost. |
Obecné požadavky |
|
|
|
Standardní funkcionalitou lékárenského IS dle platného pokynu SÚKL LEK-13 musí být nastavení automatického i manuálního odesílání retaxovaných dokladů do uložiště SÚKL. ANO, standardní funkčnost. |
|
|
Činnost nutno automaticky systémem monitorovat, běžný uživatel s příslušným právem musí mít možnost manuálně pomocí speciálního filtru zjistit odeslané/neodeslané položky za zvolený časový interval. ANO, standardní funkčnost. |
Zadavatel, tj. Fakultní nemocnice Brno (FN Brno), je státním zdravotnickým zařízením založeným Ministerstvem zdravotnictví České republiky (je zřizovatelem). Fakultní nemocnice Brno je páteřní spádové zdravotnické zařízení Ministerstva zdravotnictví České republiky, poskytující specializovanou zdravotní péči, lékárenskou péči a další služby nejen na Jihomoravského kraje, ale na území celé České republiky.
FN Brno poskytuje kvalitní komplexní zdravotní péči pacientům na pacientům nejen z Brna a Jihomoravského kraje, ale i z jiných regionů, kteří o ně projevují zájem. Důraz je kladen na kvalitu poskytované zdravotní péče a bezpečí pacientů. Kvalita zdravotní péče se zvyšuje např. vybavením moderními technologiemi, a to jak zdravotnickými, tak i jinými (např. informačními).
Mimo poskytování kvalitní zdravotní péče je prioritou produktivita a efektivita činností, které je třeba podpořit moderními nástroji, a to i v oblasti informačních a komunikačních technologií, jak pro personál, tak pro pacienty.
Řešení musí být v souladu s platnou legislativou ke dni uvedení lékárenského systému do provozu. Jedná se především o:
Ochrana osobních údajů:
Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů)
Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých dalších zákonů, ve znění pozdějších předpisů
Zákon č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv)
Legislativa specifická pro zdravotnická zařízení
Nařízení Komise v přenesené pravomoci (EU) 2016/161 ze dne 2. října 2015, kterým se doplňuje směrnice Evropského parlamentu a Rady 2001/83/ES stanovením podrobných pravidel pro ochranné prvky uvedené na obalu humánních léčivých přípravků.
Nařízení Evropského parlamentu a Rady 2017/745 ze dne 5. dubna 2017, o zdravotnických prostředcích
Směrnice Evropského parlamentu a Rady 2011/62/EU ze dne 8. června 2011, kterou se mění směrnice 2001/83ED, pokud jde o zabránění vstupu padělaných LP do legálního dodavatelského řetězce
Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, ve znění pozdějších předpisů
Zákon č. 378/2007 Sb. o léčivech, ve znění pozdějších předpisů
Prováděcí předpisy:
vyhláška č. 229/2008 Sb., o výrobě a distribuci léčiv, ve znění pozdějších předpisů
vyhláška č. 228/2008 Sb., o registraci léčivých přípravků, ve znění pozdějších předpisů
vyhláška č. 463/2021 Sb., o bližších podmínkách provádění klinických hodnocení humánních léčivých přípravků
vyhláška č. 329/2019 Sb., o předepisování léčivých přípravků při poskytování zdravotních služeb
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 č. 85/2008 Sb., o stanovení seznamu léčivých látek a pomocných látek, které lze použít pro přípravu léčivých přípravků, ve znění pozdějších předpisů
vyhláška č. 86/2008 Sb., o stanovení zásad správné laboratorní praxe v oblasti léčiv, ve znění pozdějších předpisů
vyhláška č. 236/2015 Sb., o stanovení podmínek pro předepisování, přípravu, distribuci, výdej a používání individuálně připravovaných léčivých přípravků s obsahem konopí pro léčebné účely, ve znění pozdějších předpisů
Zákon č. 167/1998 Sb., o návykových látkách a o změně některých dalších zákonů, ve znění pozdějších předpisů
Prováděcí předpisy:
• vyhláška č. 243/2009 Sb., o stanovení seznamu osob s uvedením jejich pracovišť, pro jejichž činnost se nevyžaduje povolení k zacházení s návykovými látkami a přípravky je obsahujícími, ve znění pozdějších předpisů
• vyhláška č. 53/2014 Sb., o tiskopisech formulářů podle zákona o návykových látkách
• vyhláška č. 123/2006 Sb., o evidenci a dokumentaci návykových látek a přípravků, ve znění pozdějších předpisů
• vyhláška č. 151/2005 Sb., kterou se stanoví vzory formulářů pro hlášení osob pěstujících mák setý nebo konopí a způsob vyplňování a nakládání s uvedenými formuláři
Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění, v platném znění
Vyhláška č. 54/2008 Sb., o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů, 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í a u dalších provozovatelů a zařízení vydávajících léčivé přípravky, v platném znění
Vyhláška č. 62/2015 Sb., o provedení některých ustanovení zákona o zdravotnických prostředcích, v platném znění
Vyhláška č. 98/2012 Sb., o zdravotnické dokumentaci, v platném znění
Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému, v platném znění
Zákon č. 89/2021 Sb.Zákon o zdravotnických prostředcích a o změně zákona č. 378/2007 Sb., o léčivech a o změnách některých souvisejících zákonů (zákon o léčivech), ve znění pozdějších předpisů
Zákon č. 268/2014 Sb.Zákon o diagnostických zdravotnických prostředcích in vitro
Ekonomika
Zákon o účetnictví, č. 563/1991 Sb., případně jeho nová verze v platném znění
Vyhláška 410/2009 Sb., kterou se provádějí některá ustanovení zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů, pro některé vybrané účetní jednotky, ve znění pozdějších předpisů
Vyhláška č. 270/2010 Sb., o inventarizaci majetku a závazků, ve znění pozdějších předpisů
Vyhláška č. 383/2009 Sb., o účetních záznamech v technické formě vybraných účetních jednotek a jejich předávání do centrálního systému účetních informací státu a o požadavcích na technické a smíšené formy účetních záznamů (technická vyhláška o účetních záznamech), ve znění pozdějších předpisů
České účetní standardy č. 701 až č. 710 pro některé vybrané účetní jednotky, které vedou účetnictví podle vyhlášky č. 410/2009 Sb.,
Zákon 235/2004 Sb., zákon o dani z přidané hodnoty, v platném znění
Zákon č. 586/1992 Sb., zákon o daních z příjmů, v platném znění
Zákon č. 320/2001 Sb., zákon o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), v platném znění
Zákon č. 218/2000 Sb., zákon o rozpočtových pravidlech a o změně některých souvisejících zákonů (rozpočtová pravidla)
Bezpečnost informací
Zákon č. 181/2014 Sb., o kybernetické bezpečnosti, v platném znění
Vyhláška č. 82/2018 Sb., o kybernetické bezpečnosti
Ostatní
Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce
Zákon č. 499/2008 Sb., o archivnictví a spisové službě, v platném znění
V této kapitole jsou uvedeny informační systémy, infrastruktura a technologie, které zadavatel využívá.
V této kapitole je uveden současný stav informačních a komunikačních technologií FN Brno:
Technologie |
Stav |
Původní lékárenský systém |
FN Brno provozuje dva samostatné lékárenské informační systémy. Pro veřejnou část je používán stávající lékárenský informační systém Farmis. Systém je stabilizovaný a udržovaný. Pro nemocniční část je používán stávající ekonomický informační systém MD NAV s objekty 3.01B (technologická verze 5.0), který je rovněž stabilizovaný a udržovaný, nicméně vyžaduje modernizaci a rozvoj. Realizace veřejné zakázky povede k modernizaci a konsolidaci všech procesů do jednoho lékárenského informačního systému. |
Integrační platforma FN Brno (ESB) |
Výrobce InterSystems. Integrační platforma FN Brno je centrální místo, kudy jsou vedeny komunikace v rámci interní infrastruktury informačních systému nemocnice i externích subjektů. Integrační platforma FN Brno posktytuje následující obecné služby. MPI (Master Patient Index) – služba zajišťuje bezvýznamový identifikátor pacienta EHR (Electronic Health Record) – služba zajišťuje centrální zdravotnický záznam pacienta napříč informačními systémy nemocnice Číselníky – služba zajišťuje rozhraní pro práci s číselníky přesahující hranice jednoho systému. OrgUnit (Organizační jednotky) – služba zajišťuje předávaní informací o jednotlivých organizačních jednotkách FN Brno |
Identity Management (IDM) |
FN Brno provozuje Identity management system, který slouží pro řízení oprávnení přístupu uživatelů do jednotlivých informačních systémů. IdM - platforma InterSystems Ensemble® (plánovaná aktualizace na verzi InterSystems IRIS®). |
Ekonomický informační system (ERP) |
Pro ekonomický informační systém je používán ekonomický informační systém MD NAV s objekty 3.01B (technologická verze 5.0), jehož součástí je nyní nemocniční část lékárny. Systém je stabilizovaný, udržovaný, nicméně vyžaduje modernizaci a rozvoj. Systém je dotčený stran vazeb na finanční účetnictví, rozpočtování, nákladovou strukturu, dodavatelsko-odběratelské vztahy. |
Klinický nemocniční informační systém (NIS) |
FN Brno provozuje klinický nemocniční informační system AMIS*H a AMIS*HD. Systémy jsou dotčeny zejména v oblasti vykazování spotřebovaných LP (součást NIS), cytostatické léčby, aktuálního sortimentu LP a ZM a preskripce. V současné době probíhá veřejná zakázka na modernizaci a upgrade NIS. |
Stravovací systém |
Pro normování stravy a objednávání pacientské stravy je používán ekonomický informační systém MD NAV s objekty 3.01B (technologická verze 5.0) Systém je dotčený stran LP používaných v části zajištění normování a výdeje Mléčné kuchyně. V současné době probíhá veřejná zakázka na konsolidaci stravovacího systému. |
Transfúzní informační systém (TIS) |
Pro transfúzní informační system je používán informační system TIS od společnosti TIS Brno. Systém je dotčený stran výdeje rekombinantních a plazmatických krevních derivátů. |
Operační sály |
V současné době probíhá veřejná zakázna na informační system pro operační sály. Systém je dotčený stran evidence a výkaznictví LP a ZM použitých na operačních sálech. |
Lotus Notes |
Pro schvalování žádanek na nestandardní material je používán vnitřní informační system Lotus Notes. |
Microsoft Office |
Zadavatel garantuje pro všechny klientské stanice licenci Microsoft v úrovni F3 O365. |
Manažerský informační systém (MIS) |
Základem manažerského informačního systému je datový sklad, kam jsou v pravidelných intervalech importovány veškeré pohyby LP a ZM dle kategorií zboží a typu, karet LP a ZM. Tento sklad je ve správě firmy ICZ a.s. Náhled na tyto data pak poskytuje aplikační vrstva, kde mohou uživatelé zadávat filtry pro zobrazení konkrétních položek, případně modifikovat strukturu výstupních sestav. Datový sklad je využíván pro potřeby manažerského informačního systému IBM Cognos Analytics. Systém je dotčený coby konzument veškerých dat. |
Datové centrum a infrastruktura |
FN Brno disponuje dvěmi datovými centry. Základ infrastruktury tvoří virtuální servery VMware ESXi a diskové pole HPE Primera Storage. S centralizovanou správou pomocí VMware vCenter Server 7. V současné době probíhají veřejné zakázky, které řeší infrastrukturní záležitosti. V době dodávky se může fyzická infrastruktura lišit, virtualizační prostředí zůstane zachováno, případně bude upgradováno na vyšší verzi. Část infrastruktury FN BRNO nabízí k využití pro dodávaný informační systém. |
Spisová služba WISPI |
Pro správu dokumentů je používána spisová služba WISPI od společnosti Bach systems s. r. o. Systém je dotčený stran zveřejňování Objednávek v Registru smluv. |
Tabulka 2: Současný stav informačních a komunikačních technologií
Lékárenský IS musí podporovat minimálně následující objemy (viz tabulka) při zachování odezev systému. Požadovaný stav musí Lékárenský IS splnit během ostrého provozu.
Parametr |
Požadovaný stav |
Počet žádanek/výdejek za měsíc |
20000 |
Počet cytostatických ředění za měsíc |
7000 |
Aktuální počet konsignačních skladů |
400 |
Aktuální počet položek konsignačních skladů |
20000 |
Parametr |
Požadovaný stav |
Počet uživatelů lékárny |
150 |
Počet uživatelů žádankového systému |
řádově stovky |
Počet stanic (počítačů) lékárny |
130 |
V této kapitole je uveden aktuální stav infrastruktury FN Brno, na kterou je požadováno implementovat poptávané Řešení.
Objednatel v datovém centru disponuje následující infrastrukturou a technologiemi:
Technologie |
Popis stavu |
Servery |
HP ProLiant DL380p Gen8 |
Datová úložiště |
Primera HP |
Virtualizační technologie |
VMware Standard – v rámci této technologie budou vytvořeny virtuální servery pro požadované Řešení. |
Konektivita |
LAN/WAN FN Brno – privátní datová síť, zajišťující interní síťové prostředí (spojení klientů s datovým centrem, LAN datového centra a integrace IS) Komunikace mezi diskovým polem a servery probíhá přes síť SAN. Konektivita k internetu (pro účely registrační autority, B2B portálu VZP, eHealth systému kraje a další externí komunikaci). |
Tabulka 3: Infrastruktura a technologie v datovém centru
Zadavatel požaduje splnění následujících požadavků na provoz nabízeného Řešení v prostředí zadavatele:
Oblast |
Technologie |
Požadavky zadavatele |
Pracovní a klientské stanice uživatelů |
MS Edge, Google Chrome |
Lehký klient nabízeného Řešení musí být plně provozuschopná na prohlížečích MS Edge, Google Chrome. |
Správa uživatelů |
MS Active Directory |
Nabízené Řešení musí při správě uživatelů využívat pro autentizaci MS Active Directory se stromovou i doménovou úrovní Windows Server. |
Zálohování a dostupnost |
Veeam
|
Zadavatel požaduje kompatibilitu nabízeného řešení s uvedeným SW. |
Operační systémy na klientech |
MS Windows 10 |
Zadavatel požaduje kompatibilitu nabízeného řešení s uvedeným OS. |
Virtualizační platforma |
VMware |
Zadavatel požaduje kompatibilitu nabízeného řešení s uvedeným SW, tj. aby serverová část nabízeného Řešení byla plně funkční na této virtualizační platformě. |
Vzdálený přístup |
VPN |
Vzdálený přístup pro management Řešení bude umožněn pomocí VPN zadavatele. |
Patch Management |
WSUS server |
Zadavatel požaduje kompatibilitu nabízeného řešení s uvedeným SW. Patch management je řešen ze strany interního WSUS serveru v aktuální verzi a provádí se s týdenním až dvoutýdenním zpožděním kvůli otestování případných problémů, které mohou způsobit hotfixy a bezpečnostní záplaty. |
FN Brno disponuje značným počtem pracovních stanic. Pracovní stanice s nejhorší konfigurací, na které musí klientská část Řešení (těžký i lehký klient) plnohodnotně fungovat, má následující konfiguraci: Intel Core2 Duo E8400 @ 3.00 GHz (1174 bodů na ▇▇▇.▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/), 4 GB DDR 3 RAM, 120 GB SSD. Na všech pracovních stanicích má zadavatel implementován operační systém MS Windows 10 Pro 64 bit.
Vyjádření dodavatele: dodavatel souhlasí s výše uvedenými požadavky zadavatele.
Zadavatel požaduje poskytnutí licence ke všem součástem Řešení, která bude umožňovat užívání Řešení v prostředí zadavatele s následujícími parametry:
počet registrovaných uživatelů: minimálně 3200;
celkový počet uživatelů pracujících s lehkým klientem: minimálně 3000;
počet současně přihlášených uživatelů pracujících s lehkým klientem: minimálně 2000;
celkový počet uživatelů pracujících s těžkým klientem: minimálně 150;
počet současně přihlášených uživatelů pracujících s těžkým klientem: minimálně 150.
V ostatních parametrech musí být licence ke všem součástem Řešení bez jakéhokoli omezení, tj. zejména pro celé území České republiky, bez omezení počtu užití, bez omezení počtu integrovaných koncových zařízení, bez omezení rozsahu databáze, bez omezení počtu CPU nebo jader serverové části a na dobu trvání majetkových práv autorských.
Licence se musí vztahovat i na nové verze software vydané během trvání smlouvy. Licence se musí bez omezení vztahovat na implementaci jak v produkčním, tak i v testovacím prostředí.
Vyjádření dodavatele: dodavatel souhlasí s výše uvedenými požadavky zadavatele a doplňuje přehled modulů, ze kterých se skládá nabízené Řešení:
IS Mediox3000
Elektronické žádanky
Cytostatické žádanky
ATB žádanky
Domácí recept
Sklady
Jménem společnosti Apatyka servis si dovoluji vyjádřit přesvědčení, že výše uvedené Řešení bude po technické i ekonomické stránce plně vyhovovat potřebám Vaší nemocnice a jeho realizace přispěje ke zkvalitnění prostředí a služeb, které poskytujete Vašim zákazníkům / pacientům.
Věřím současně, že náš výklad zadání, stejně tak jako know-how, technické i lidské zdroje, kterými naše společnost Apatyka servis disponuje, skýtají pro Vás záruku instalace Řešení v nejvyšší možné kvalitě a k Vaší plné spokojenosti.
PŘÍLOHA Č. 2
Požadavky na integraci s informačními systémy třetích stran
Komunikace # |
Část Řešení (nemocniční a/nebo veřejná) |
Název procesu |
Název úlohy |
Partner komunikace |
Další požadavky |
Typ komunikace* |
ZDROJ |
CÍL |
Protokol |
Poznámka |
||||
Název |
IP |
Port |
Název |
IP/URL, případně další vlastnosti komunikace |
Port |
|||||||||
K1 |
Nemocniční i veřejná |
|
Komunikace s národním (celoevropský) systémem pro ověřování pravosti léčiv dle protipadělkové směrnice FMD |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
|
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K3 |
Nemocniční i veřejná |
|
Komunikace mezi jednotlivými vrstvami LeIS |
Vrstvy aplikace |
Šifrovaná komunikace mezi jednotlivými vrstvami LeIS (vždy mezi aplikační a prezentační vrstvou, vždy mezi aplikační a databázovou vrstvou a vždy mezi servery) |
interní |
LeIS (popř. jeho podsystémy) |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
LeIS (popř. jeho podsystémy) |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
|
K4 |
Nemocniční |
|
Ověření identifikace pacienta včetně ZP v MPI |
ESB |
|
interní |
LeIS |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
ESB |
|
|
|
|
K5 |
Nemocniční i veřejná |
|
Ověření LP dle protipadělkové směrnice FMD |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K6 |
Nemocniční i veřejná |
|
Ověření ZP dle Nařízení o zdravotnických prostředcích (MDR) |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
po zprovoznění online systému ověřování |
po zprovoznění online systému ověřování |
po zprovoznění online systému ověřování |
po zprovoznění online systému ověřování |
po zprovoznění online systému ověřování |
po zprovoznění online systému ověřování MDR |
Zadavatel požaduje pouze připravenost LeIS na tuto komunikaci, přičemž technické požadavky na tuto komunikaci platí pouze v rozsahu, ve kterém jsou v době zahájení zadávacího řízení známy. |
K7 |
Nemocniční i veřejná |
Objednávky |
Vystavení objednávek a jejich doručení partnerům |
Dodavatelé |
Zabezpečená komunikace s dodavateli na základě elektronické výměny dat |
externí |
ESB, GW nebo proprietární software provozovaný Objednatelem (Xmit, C-link apod.) |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Požadována šifrovaná komunikace |
K8 |
Nemocniční i veřejná |
Objednávka - Příjem |
Automatický příjem |
Dodavatel |
„Automatické stažení“ souboru od dodavatele (formát PDK4-14 a vyšší) na úložiště specifikované v Realizačním projektu s následným automatickým párováním alespoň dle EAN, APA, kódu SÚKL, PDK, GTIN na sortiment lékárny. |
externí |
ESB, GW nebo proprietární software provozovaný Objednatelem (Xmit, C-link apod.) |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Požadována šifrovaná komunikace |
K9 |
Nemocniční i veřejná |
Objednávka - Příjem |
Ruční příjem z datového média, e-mailu |
Dodavatel |
Příjem z datového media či e-mailu (soubor) od dodavatele (formát PDK4-14 a vyšší) s následným automatickým párováním alespoň dle EAN, APA, kódu SÚKL, PDK, GTIN na sortiment lékárny. |
externí |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
LeIS musí umožnit upload souboru |
K10 |
Nemocniční i veřejná |
Sklady |
Centrální synchronizace číselníků SÚKL (KLK, DLP, …) |
SÚKL (KLK, DLP, …) |
|
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
SÚKL (KLK, DLP, …) |
Bude specifikováno v Realizačním projektu |
|
|
|
K11 |
Nemocniční i veřejná |
Sklady |
Centrální synchronizace číselníků VZP (LEKY, VYKONY, PZT, IVLP,…) |
VZP (LEKY, VYKONY, PZT, IVLP,…) |
|
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
VZP (LEKY, VYKONY, PZT, IVLP,…) |
Bude specifikováno v Realizačním projektu |
|
|
|
K12 |
Nemocniční i veřejná |
Sklady |
Centrální synchronizace číselníku PDK |
Pharmdata
s.r.o. |
|
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Pharmdata
s.r.o. |
|
|
|
|
K13 |
Nemocniční i veřejná |
Fakturace ZP |
Odeslání dávek na portály ZP |
Portály ZP |
Odeslání dávek z prostředí LeIS na portály jednotlivých ZP |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Portály ZP |
Bude specifikováno v Realizačním projektu |
|
|
Požadována šifrovaná komunikace |
K14 |
Nemocniční i veřejná |
Fakturace ZP |
On-line kontrola na pojišťovnu |
Portály ZP |
On-line kontrola na pojišťovnu v systému sledování vrácených dokladů z LeIS dle typu a důvodu vratky od zdravotní pojišťovny. |
externí |
ESB, GW nebo proprietární software provozovaný Objednatelem |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Portály ZP |
Bude specifikováno v Realizačním projektu |
|
|
Požadována šifrovaná komunikace |
K15 |
Nemocniční |
|
Integrace s NIS |
NIS |
Automatický přenos LP či ZM z LeIS do účtu pacienta v NIS |
interní |
LeIS server |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
NIS |
|
|
|
Požadována šifrovaná komunikace |
K16 |
Nemocniční i veřejná |
Statistiky |
Vygenerování statistiky pro ÚZIS |
ÚZIS |
IS musí generovat do sestavy dle požadavků ÚZIS a automaticky e-mailem odesílat na nastaveného adresáta dle stavu dohod s ÚZIS . |
externí |
LeIS server |
N/A |
N/A |
ÚZIS |
N/A |
N/A |
Zadavatel požaduje integraci na Microsoft Exchange server |
|
K17 |
Nemocniční i veřejná |
Statistiky |
Roční hlášení OaPL pro SÚKL |
SÚKL |
Vedení elektronické knihy omamných a psychotropních látek dle platné legislativy. Roční hlášení OaPL pro SÚKL |
externí |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
SÚKL |
N/A |
N/A |
|
|
K18 |
Nemocniční i veřejná |
Statistiky |
Příjmy, nákupy, výdeje opiátů |
"adresát" |
LeIS vygeneruje XLS nebo XLSX, který je možné odeslat e-mailem prostřednictvím automaticky vytvořené e-mailové zprávy (v Microsoft Outlook), jejíž přílohou bude vygenerovaný soubor, nebo uložit na lokální úložiště |
|
LeIS |
N/A |
N/A |
|
|
|
|
|
K19 |
Nemocniční i veřejná |
Reporty |
Účetní závěrka |
ERP |
Sestavy pro účetní závěrku - kontrolní mechanismus k integracím do ERP |
interní |
LeIS |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
ERP |
Bude specifikováno v Realizačním projektu |
|
|
|
K20 |
Nemocniční |
DDHM - Žádanky, výdejky |
Zpracování žádanek a výdejek DDHM a vyskladnění |
ERP |
|
interní |
LeIS |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
ERP |
Bude specifikováno v Realizačním projektu |
|
|
|
K21 |
Nemocniční |
Konsignační sklad - Nákupní objednávka |
Žádost o fakturaci, Žádost o doplnění, Výdejka |
Dodavatel |
vytvoření elektronické objednávky a odeslání poštovním klientem s automaticky vygenerovanými přílohami ve zvoleném formátu, alespoň XLS (XLSX) a PDF – Žádost o fakturaci, Žádost o doplnění, Výdejka |
externí |
poštovní klient |
N/A |
N/A |
Dodavatel (e-mailová adresa) |
N/A |
N/A |
|
|
K22 |
Nemocniční |
Výdej LP, ZM dle FMD a MDR na oddělení nemocnice |
Komunikace s národním (celoevropský) systémem pro ověřování pravosti léčiv dle protipadělkové směrnice FMD a dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Obdobně jako při výdeji na partnery - požadavek při výdeji na oddělení implementovat napojení dle nařízení FMD. |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
|
K23 |
Nemocniční |
Zpracování žádanek - výdejek na oddělení nemocnice |
Generování objednávek z výdejek na dodavatele, zaslání e-mailem |
Dodavatel |
Vygenerování objednávek z výdejek na preferovaného dodavatele, vložení objednávky do e-mailu, odeslání e-mailem |
externí |
poštovní klient |
N/A |
N/A |
Dodavatel (e-mailová adresa) |
N/A |
N/A |
|
|
K24 |
veřejná |
Výdej na recept |
Kontrola záznamu eReceptu |
Centrální úložiště elektronických receptů (SÚKL) - CÚER |
Kontrola existence eReceptu v CÚER |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
CÚeR SÚKL |
▇▇▇▇-▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
|
K25 |
veřejná |
Výdej na recept |
Záznam výdeje LP |
Centrální úložiště elektronických receptů (SÚKL) - CÚER |
Záznam výdeje LP do CÚER |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
CÚeR SÚKL |
▇▇▇▇-▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
|
K26 |
Veřejná |
Výdej na recept - vnitřní (vystaven v NIS) |
Načtení položek receptu včetně hlavičky z NIS |
NIS |
po sejmutí spec. čárového kódu z receptu pořízeného v ambulancích lékařů potom v lékárně načítat hlavičku receptu včetně položek přímo z NIS nemocnice |
interní |
LeIS |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
NIS (přes integrační platformu) |
|
|
|
|
K27 |
Veřejná |
Výdej na recept |
Online kontrola B2B registru pacientů VZP |
B2B VZP |
Automatickou on-line kontrolu B2B registru pacientů VZP. Kontrola B2B probíhá na pozadí expedice a uživatel je na případné chyby upozorněn při uložení expedice. Kontrola B2B je funkční i během retaxace. |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
B2B VZP |
|
šifrovaný 443 |
TCP |
|
K28 |
Veřejná |
Výdej na recept |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle protipadělkové směrnice FMD |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K29 |
Veřejná |
Výdej na recept |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle protipadělkové směrnice FMD |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Změna příznaků (vyřazení) jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K30 |
Veřejná |
Výdej bez lékařského předpisu |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K31 |
Veřejná |
Výdej bez lékařského předpisu |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Změna příznaků (vyřazení) jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K32 |
Veřejná |
Výdej na poukaz |
Online ověření IČZ/IČP, RČ (B2B) z portálu VZP |
B2B VZP |
Při výdeji na recept/poukaz možnost on-line ověření IČZ/IČP, rodných čísel (B2B) z portálu VZP |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
B2B VZP |
|
šifrovaný 443 |
TCP |
chráněno certifikátem |
K33 |
Veřejná |
Výdej na poukaz |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K34 |
Veřejná |
Výdej na poukaz |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Změna příznaků (vyřazení) jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K35 |
Veřejná |
Výdej na poukaz |
Kontrola záznamu ePoukazu |
Centrální úložiště elektronických receptů (SÚKL) - CÚER |
Kontrola existence ePoukazu v CÚER |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
CÚeR SÚKL |
▇▇▇▇-▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
|
K36 |
Veřejná |
Výdej na poukaz |
Záznam výdeje ZP |
Centrální úložiště elektronických receptů (SÚKL) - CÚER |
Záznam výdeje ZP do CÚER |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
CÚeR SÚKL |
▇▇▇▇-▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
|
K37 |
Veřejná |
Výdej partnerům |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Ověření jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K38 |
Veřejná |
Výdej partnerům |
Komunikace s Národním systémem pro ověřování pravosti léčiv dle Nařízení o zdravotnických prostředcích MDR |
Národní (celoevropský) systém pro ověřování pravosti léčiv |
Změna příznaků (vyřazení) jedinečného identifikátoru |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
Protipadělková DB |
▇▇▇-▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
tcp |
|
K39 |
Veřejná |
Retaxace dokladů |
Online ověření IČZ/IČP, RČ (B2B) z portálu VZP |
B2B VZP |
Při retaxaci dokladů možnost on-line ověření IČZ/IČP, rodných čísel (B2B) z portálu VZP |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
B2B VZP |
|
šifrovaný 443 |
TCP |
chráněno certifikátem |
K40 |
Veřejná |
Odesílání dat na SÚKL |
Odesílání retaxovaných dokladů do úložiště SÚKL dle LEK-13 |
úložiště SÚKL |
Standardní funkcionalitou lékárenského IS dle platného pokynu SÚKL LEK-13 musí být nastavení automatického i manuálního odesílání retaxovaných dokladů do uložiště SÚKL. |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
SÚKL |
▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
chráněno certifikátem |
K41 |
Veřejná |
Odesílání dat na SÚKL |
Odesílání retaxovaných dokladů do úložiště SÚKL dle LEK-13 |
úložiště SÚKL |
Standardní funkcionalitou lékárenského IS dle platného pokynu SÚKL LEK-13 musí být nastavení automatického i manuálního odesílání retaxovaných dokladů do uložiště SÚKL. |
externí |
ESB, nebo GW |
Bude specifikováno v Realizačním projektu |
Bude specifikováno v Realizačním projektu |
SÚKL |
▇▇▇▇.▇▇▇▇.▇▇ |
šifrovaný 443 |
TCP |
chráněno certifikátem |
K42 |
Nemocniční i veřejná |
Synchronizace času |
Synchronizace času řešení s time serverem FN Brno |
time server |
|
|
VLAN NL |
10.1.9.x; 10.2.18.x; 10.3.11.x; 10.64.0.x |
|
▇▇▇▇▇▇▇▇.▇▇▇▇▇▇.▇▇ |
N/A |
Bude specifikováno v Realizačním projektu |
UDP |
|
* externí - cíl komunikace je mimo infrastrukturu zadavatele; interní - cíl komunikace je uvnitř infrastruktury zadavatele
PŘÍLOHA Č. 3
Koncová zařízení
Typ koncového zařízení |
Maximální počet koncových zařízení |
Popis |
Typ rozhraní |
Výrobce |
Čtečky čipových karet |
40 |
|
USB |
Ingenico;ACER;Lenovo apod. |
Skenery čárových kódů |
70 |
|
USB |
Symbol DS9208;Zebra DS9308+DS2200+DS6708+MP7000;MC930B apod. |
Pokladní termotiskárny |
20 |
|
USB |
Epson TM-T88V;Star SP500 apod. |
Externí displej pro zobrazení ceny |
20 |
|
COM |
DSPxxx |
Platební terminály |
20 |
|
LAN |
YOMANI XT; poskytovatelé Komerční banka a ČSOB |
Pokladní zásuvky |
20 |
Pokladní zásuvka na hotovost |
RJ11 |
Virtuos -přes Epson tiskárnu |
Tiskárny sestav |
20 |
|
USB + LPT |
Epson Fx 890 II;Epson LX -350;Kyocera ECOSYS;HP 203;Borther HLL6450DW apod. |
Tiskárny štítků a etiket |
20 |
|
USB |
Zebra ZD421+Z4000+GX430t+ZT410 apod. |
Řešení musí umožňovat tisk na jehličkových tiskárnách.
PŘÍLOHA Č. 4
Specifikace Služeb
Význam pojmů:
Pracovní doba každodenní: každý kalendářní den od 7:00 do 21:00 hodin;
Pracovní doba standardní: v pracovních dnech od 7:00 do 16:00 hodin;
NONSTOP: 24 hodin denně, 7 dnů v týdnu, 365 dnů v roce.
Název Služby: |
Odstraňování vad |
Kód Služby: |
P01 |
|
Druh Služby (Paušální/Ad-hoc): |
Paušální |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ano |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
Na vyžádání |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Odstraňování vad Řešení, tj. odstraňování vad Software a jeho integračních vazeb na Zařízení a informační systémy třetích stran, a to včetně integračních vazeb na systém řízení báze dat (databázi).
Za vady Software a jeho integračních vazeb se považují rovněž veškeré rozpory s touto smlouvou, Zadávací dokumentací, Dokumentací, účelem Software, Požadavky Objednatele a stavem, ve kterém Software podle této smlouvy v daném časovém okamžiku má být.
Pokud je pro provozování Software nezbytné využívat internetový prohlížeč, považuje se za vadu Software rovněž nekompatibilita Software s posledními verzemi běžných internetových prohlížečů, kterými se rozumí alespoň prohlížeče společností Google a Microsoft. |
|||
Časový rozsah poskytování Služby: |
Dle SLA parametrů |
|||
Lhůta pro zahájení řešení Požadavku: |
Dle SLA parametrů |
|||
Lhůta pro vyřešení Požadavku: |
Dle SLA parametrů |
|||
Název Služby: |
Bezpečnostní aktualizace |
Kód Služby: |
P02 |
|
Druh Služby (Paušální/Ad-hoc): |
Paušální |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
Průběžně, v případě dále specifikovaných Požadavků na vyžádání |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Průběžné sledování vývoje bezpečnostní situace včetně identifikace kybernetických bezpečnostních hrozeb, které mohou využít zranitelností Software nebo komponenty třetí strany, kterou Software využívá a která byla Objednateli dodána na základě této smlouvy (dále v této specifikaci jen „Komponenty“), a/nebo mohou v souvislosti se Software jinak narušit kybernetickou bezpečnost Objednatele, identifikace potřeb změn Software a bezpečnostních opatření za účelem minimalizace z toho plynoucích rizik včetně provedení těchto změn a implementace těchto bezpečnostních opatření (dále jen „Bezpečnostní změny“).
Objednatel je oprávněn vznášet na Poskytovatele dotazy, které se považují za Požadavky, zda Software nebo Komponenta obsahují určitou zranitelnost, vykazují citlivost vůči určité taktice či technice útoku nebo mají jiný nedostatek snižující úroveň kybernetické bezpečnosti Objednatele. Pokud Poskytovatel zjistí nebo mohl zjistit, že existuje riziko narušení kybernetické bezpečnosti Objednatele dle takového Požadavku, je povinen provést odpovídající Bezpečnostní změnu. O výsledku svého zjištění podle věty předchozí Poskytovatel do 3 pracovních dnů od zadání Požadavku písemně informuje Objednatele.
Poskytovatel je povinen provést Bezpečnostní změnu bez zbytečného odkladu poté, co její potřebu zjistil nebo mohl zjistit. Závisí-li doba provedení Bezpečnostní změny na součinnosti třetí strany, která není osobou ovládanou Poskytovatelem, je Poskytovatel povinen informovat o tom Objednatele do 1 pracovního dne od vzniku jeho povinnosti provést Bezpečnostní změnu. Bezpečnostní změny nepodléhají akceptaci dle čl. IV této smlouvy, ledaže si to ve vztahu ke konkrétní Bezpečnostní změně Objednatel vymíní.
V případě prodlení s provedením Bezpečnostní změny, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den prodlení a za každý takový případ. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Název Služby: |
Maintenance Software |
Kód Služby: |
P03 |
|
Druh Služby (Paušální/Ad-hoc): |
Paušální |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
Průběžně |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Implementace nových verzí Software (update a upgrade), které vydá výrobce Software nebo Poskytovatel, je-li současně výrobcem Software, v prostředí Objednatele, a to včetně implementace nových verzí komponent třetích stran, které Software využívá a které byly Objednateli dodány na základě této smlouvy (dále v této specifikaci jen „Komponenty“). Veškeré náklady spojené s pořízením a implementací nových verzí Komponent nese Poskytovatel. Není-li výslovně v této specifikaci uvedeno jinak, rozumí se v této specifikaci dále pod pojmem „Software“ rovněž „Komponenty“.
Implementace nové verze Software podléhá akceptaci (Testování) dle čl. IV této smlouvy, ledaže se smluvní strany v konkrétním případě dohodnou jinak. Nedohodnou-li se smluvní strany jinak, nová verze Software nesmí znemožňovat využívání úprav Software provedených na základě této smlouvy, případně musí tyto úpravy Software zahrnovat. Věta předchozí se vztahuje rovněž na konfigurační úpravy.
Poskytovatel je povinen Objednatele o vydání nové verze Software písemně informovat do 5 pracovních dnů od jejího vydání. Součástí této informace musí být popis provedených změn v rozsahu nezbytném pro posouzení přípustnosti implementace nové verze Software. Implementaci nové verze Software je Poskytovatel oprávněn provést pouze s výslovným souhlasem Objednatele a pouze za podmínek sjednaných v této smlouvě. Pokud Objednatel s implementací nové verze Software vysloví souhlas, je Poskytovatel povinen ji provést do 1 měsíce od takového souhlasu Objednatele, ledaže se smluvní strany dohodnou na lhůtě jiné.
V případě prodlení s implementací nové verze Software je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 3000,- Kč (slovy: třitisíce korun českých) za každý pracovní den prodlení a za každý takový případ. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Název Služby: |
Profylaxe |
Kód Služby: |
P04 |
|
Druh Služby (Paušální/Ad-hoc): |
Paušální |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ano pro případ odstraňování zjištěných vad, jinak ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
Průběžně |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Provádění nepřetržitého preventivního monitoringu a profylaxe Software za účelem předcházení vadám Software, nestandardním stavům Software a nekonzistenci a narušení integrity databází využívaných Řešením. Služba zahrnuje také průběžné kontroly parametrů podstatných z hlediska provozu Software (zejména heartbeat služeb a monitoring komunikací) Software. Za vady Software se považují rovněž veškeré rozpory s touto smlouvou, Zadávací dokumentací, oprávněnými pokyny Objednatele a stavem, ve kterém Software podle této smlouvy v daném časovém okamžiku má být. Pro vyloučení pochybností se uvádí, že Poskytovatel není povinen poskytovat tuto Službu k systémům, které nejsou součástí dodávky, tj. nejsou součástí předmětu této smlouvy.
Poskytování této Služby nesmí způsobovat provozní omezení Software. O zjištěných vadách a o podstatných skutečnostech, a to zejména těch, které mají nebo mohou mít dopad na bezpečnost informací v Software nebo dostupnost Software, zjištěných při poskytování této Služby je Poskytovatel povinen bez zbytečného odkladu informovat prostřednictvím Provozního deníku Objednatele.
Veškeré vady Software zjištěné při poskytování této služby je Poskytovatel povinen odstranit ve lhůtách dle SLA parametrů uvedených v příloze č. 3 této smlouvy, které počínají běžet okamžikem, kdy Poskytovatel vadu zjistil nebo mohl zjistit. Pro vyloučení pochybností se uvádí, že se uplatní rovněž sankční ujednání uvedená v příloze č. 3 této smlouvy. O odstranění těchto vad učiní Poskytovatel záznam do Provozního deníku.
V případě prodlení se zasláním upozornění na provedení výše uvedených záznamů do Provozního deníku je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý den prodlení a za každý takový případ. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Lhůta pro zahájení řešení Požadavku: |
--- |
|||
Lhůta pro vyřešení Požadavku: |
--- |
|||
Název Služby: |
Podpora běhu |
Kód Služby: |
A01 |
|
Druh Služby (Paušální/Ad-hoc): |
Ad-hoc |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
--- |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Poskytování provozně-technické podpory běhu Software včetně:
Podporou běhu se rozumí rovněž provádění konfiguračních prací nezbytných pro zajištění dostupnosti Software nebo dostupnosti, integrity a důvěrnosti zpracovávaných dat. Pro vyloučení pochybností se uvádí, že součinnost třetích stran nezbytnou pro poskytnutí této Služby zajišťuje Objednatel.
V případě, že Poskytovatel je v prodlení se zahájením řešení Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení. V případě, že Poskytovatel je v prodlení s vyřešením Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní
|
|||
Lhůta pro zahájení řešení Požadavku: |
Bez zbytečného odkladu |
|||
Lhůta pro vyřešení Požadavku: |
Dle dohody |
|||
Název Služby: |
Úpravy a konfigurace |
Kód Služby: |
A02 |
|
Druh Služby (Paušální/Ad-hoc): |
Ad-hoc |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
--- |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Provádění úprav Software a jeho integračních vazeb, jakož i provádění úprav konfigurace.
V případě, že Poskytovatel je v prodlení se zahájením řešení Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení.
V případě, že Poskytovatel je v prodlení s vyřešením Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Lhůta pro zahájení řešení Požadavku: |
Bez zbytečného odkladu |
|||
Lhůta pro vyřešení Požadavku: |
Dle dohody |
|||
Název Služby: |
Připojení Zařízení |
Kód Služby: |
A03 |
|
Druh Služby (Paušální/Ad-hoc): |
Ad-hoc |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
--- |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Provedení integrace Zařízení specifikovaného v Požadavku na Software. Součinnost třetí strany nezbytnou pro provedení takové integrace je povinen zajistit Objednatel, ledaže je taková třetí strana součástí veřejné správy nebo je zdravotní pojišťovnou nebo se smluvní strany dohodly jinak.
V případě, že Poskytovatel je v prodlení se zahájením řešení Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení.
V případě, že Poskytovatel je v prodlení s vyřešením Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Lhůta pro zahájení řešení Požadavku: |
Bez zbytečného odkladu |
|||
Lhůta pro vyřešení Požadavku: |
Dle dohody |
|||
Název Služby: |
Integrace informačního systému |
Kód Služby: |
A04 |
|
Druh Služby (Paušální/Ad-hoc): |
Ad-hoc |
|||
Na poskytování Služby se vztahují SLA parametry uvedené v příloze č. 5? |
Ne |
|||
Jde-li o Paušální Službu, poskytuje se průběžně, nebo na vyžádání? |
--- |
|||
Vymezení Služby a dalších povinností Poskytovatele, včetně smluvních pokut: |
Provedení integrace Software na jiný informační systém provozovaný Objednatelem nebo na informační systém třetí strany. Součinnost třetí strany nezbytnou pro provedení takové integrace je povinen zajistit Objednatel, ledaže je taková třetí strana součástí veřejné správy nebo je zdravotní pojišťovnou nebo se smluvní strany dohodly jinak.
V případě, že Poskytovatel je v prodlení se zahájením řešení Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení.
V případě, že Poskytovatel je v prodlení s vyřešením Požadavku, je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 1000,- Kč (slovy: jedentisíc korun českých) za každý pracovní den takového prodlení. |
|||
Časový rozsah poskytování Služby: |
Pracovní doba standardní |
|||
Lhůta pro zahájení řešení Požadavku: |
Bez zbytečného odkladu |
|||
Lhůta pro vyřešení Požadavku: |
Dle dohody |
|||
PŘÍLOHA Č. 5
SLA parametry některých Služeb
Vady jsou kategorizovány podle závažnosti takto:
Není-li v Požadavku uvedena kategorie vady, má se za to, že jde o vadu kategorie C.
Závažnost vady |
Kategorie vady |
Popis vady |
Kritická |
A |
Vada se projevuje jedním z následujících způsobů:
|
Závažná |
B |
Vada se projevuje jedním z následujících způsobů:
|
Běžná |
C |
Vada se na příslušném serveru, na kterékoli pracovní stanici, na kterékoli klientské aplikaci, na jakékoli integrační vazbě nebo na jakémkoli mobilním zařízení projevuje omezeními, chybami nebo delšími odezvami, avšak Software lze přesto alespoň zčásti využívat. |
Lhůty a smluvní pokuty za jejich nedodržení jsou sjednány takto:
Není-li ve specifikaci Služby nebo ve smlouvě uvedeno jinak, počínají tyto lhůty běžet okamžikem zadání Požadavku, tj. zápisem Požadavku do systému Helpdesk a v případě nedostupnosti systému HelpDesk doručením Požadavku e-mailem na e-mailovou adresu Helpdesku. V případě, že bude Poskytovatel v prodlení se zahájením prací na odstranění vady nebo s odstraněním vady, je Objednatel oprávněn požadovat po Poskytovateli zaplacení smluvní pokuty sjednané v tabulce níže, a to za každou vadu zvlášť.
Kategorie vady |
Zahájení prací na odstranění vady |
Odstranění vady |
||
Lhůta pro zahájení prací na odstranění vady |
Smluvní pokuta za prodlení Poskytovatele, |
Lhůta pro odstranění vady |
Smluvní pokuta za prodlení Poskytovatele, |
|
A |
2 hodiny v rámci Pracovní doby standardní |
2000,- Kč (slovy: dvatisíce korun českých) za každou hodinu prodlení |
8 hodin v rámci Pracovní doby standardní |
2000,- Kč (slovy: dvatisíce korun českých) za každou hodinu prodlení |
B |
4 hodiny |
1000,- Kč (slovy: jedentisíc korun českých) za každou hodinu prodlení |
14 hodin |
1000,- Kč (slovy: jedentisíc korun českých) za každou hodinu prodlení |
C |
8 hodin |
500,- Kč (slovy: pětset korun českých) za každou hodinu prodlení |
24 hodin v rámci Pracovní doby standardní |
500,- Kč (slovy: pětset korun českých) za každou hodinu prodlení |
PŘÍLOHA Č. 6
Zvláštní podmínky plnění
Za účelem provádění údržby a řešení vad Software je Poskytovatel oprávněn provádět odstávky serverů, na kterých je provozován Software, pouze po dohodě s Objednatelem. Pokud důvodem této odstávky není potřeba odstranění vady Software, je Poskytovatel povinen potřebu odstávky oznámit Objednateli nejméně 7 pracovních dnů předem, přičemž tyto odstávky je Poskytovatel oprávněn provádět maximálně dvakrát za rok, ledaže se smluvní strany dohodnou jinak.
Za účelem trvalého udržování vysoké úrovně kybernetické bezpečnosti Řešení je Poskytovatel povinen:
zajistit pravidelné technické a bezpečnostní školení osob provádějící podporu Řešení na jeho straně, které jsou v rolích privilegovaných uživatelů, a to v rozsahu nezbytném a nad rámec Školení;
neprodleně dokumentovat změny přístupových oprávnění, které bude na své straně provádět, a to i dle pokynů Objednatele;
určit havarijní kontaktní údaje pro zvládání kybernetických bezpečnostních událostí a incidentů v režimu 7x24, které bez zbytečného odkladu po nabytí účinnosti této smlouvy poskytne Objednateli;
poskytovat Objednateli součinnost při testování havarijních plánů vztahujících se k Řešení;
poskytovat Objednateli součinnost při provádění bezpečnostních a penetračních testů a při testování kybernetických bezpečnostních zranitelností Řešení;
využívat jednotnou adresářovou službu v podobě MS Active Directory jako primární zdroj identit integrovaný s modulem IDM v Enterprise Service Bus výrobce InterSystems;
poskytovat součinnost při implementaci systému log managementu Poskytovatele, a to zejména v podobě správné identifikace všech zdrojů logů, jejich způsobu a rozsahu logování;
poskytovat součinnost při identifikaci a vyhodnocování potenciálních kybernetických bezpečnostních událostí v Řešení;
ve vztahu k Řešení zajistit a udržovat splnění požadavků § 25 odst. 2 VKB.
PŘÍLOHA Č. 7
Harmonogram
Etapa |
Popis plnění |
Počátek lhůty pro řádné dokončení či poskytnutí plnění se sjednává následovně, ledaže se smluvní strany dohodnou jinak; nedohodnou-li se smluvní strany jinak, Poskytovatel není oprávněn zahájit plnění dříve |
Délka lhůty pro řádné dokončení či poskytnutí plnění |
Fakturační milník |
I. |
Zpracování Realizačního projektu |
Nabytí účinnosti této smlouvy |
6 měsíců |
A |
II. |
Provedení Implementace nemocniční části Řešení, vyjma integrace na Zařízení, a Registrace pro nemocniční část Řešení |
Řádné dokončení I. etapy |
4 měsíce |
|
III. |
Provedení integrace nemocniční části Řešení na Zařízení |
Na výzvu Objednatele nebo po řádném dokončení II. etapy podle toho, co nastane dříve; Objednatel však není oprávněn vydat tuto výzvu před řádným dokončením I. etapy |
1 měsíc |
|
IV. |
Provedení Migrace do nemocniční části Řešení |
Řádné dokončení II. etapy |
1 měsíc |
|
V. |
Úspěšné provedení Testování nemocniční části Řešení |
Řádné dokončení II., III. a IV. etapy |
2 měsíce |
|
VI. |
Provedení Školení pro nemocniční část Řešení |
Řádné dokončení V. etapy |
1 měsíc |
|
VII. |
Provedení Implementace veřejné části Řešení, vyjma integrace na Zařízení, a Registrace pro veřejnou část Řešení |
Na výzvu Objednatele nebo po řádném dokončení VI. etapy podle toho, co nastane dříve; Objednatel však není oprávněn vydat tuto výzvu před řádným dokončením I. etapy |
2 měsíce |
B |
VIII. |
Provedení integrace veřejné části Řešení na Zařízení |
Na výzvu Objednatele nebo po řádném dokončení VII. etapy podle toho, co nastane dříve; Objednatel však není oprávněn vydat tuto výzvu před řádným dokončením I. etapy |
2 měsíce |
|
IX. |
Provedení Migrace do veřejné části Řešení |
Řádné dokončení VII. etapy |
1 měsíc |
|
X. |
Úspěšné provedení Testování veřejné části Řešení |
Řádné dokončení VII., VIII. a IX. etapy |
1 měsíc |
|
XI. |
Provedení Školení pro veřejnou část Řešení |
Řádné dokončení X. etapy |
1 měsíc |
|
XII. |
Zpracování Exit plánu, Zálohovacího plánu a Plánu obnovy |
Řádné dokončení VI. a XI. etapy |
1 měsíc |
C |
XIII. |
Zpracování Dokumentace skutečného provedení a předání Dokumentace |
Řádné dokončení XII. etapy |
2 měsíce |
Pojmy „nemocniční část“ a „veřejná část“ jsou vymezeny v příloze č. 2 Zadávací dokumentace.
78