Smlouva o poskytování služeb
č.j. 23041/2020-UVCR-37
ev. č. 20/039-0
Smlouva o poskytování služeb
„Programátorské práce – Jednotný informační systém pro adiktologické služby“
uzavřená dle zákona č. 89/2012 sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“), a dle zákona č. 121/2000 sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů (dále jen „autorský zákon“)
Česká republika - Úřad vlády České republiky
kterou zastupuje: Xxx. Xxxxxxx Xxxxxxxxx, ředitelka Odboru protidrogové politiky, na základě vnitřního předpisu
se sídlem: nábř. X. Xxxxxx 000/0, 000 00 Xxxxx 0 – Xxxx Strana IČO: 00006599
DIČ: CZ00006599
bankovní spojení: ČNB Praha, účet č.: XXXXXXXXXXXXXXX kontaktní osoba: Xxx. Xxxxxx Xxxxxxxx – ve věcech smluvních,
email: XXXXXXXXXX, tel.: XXXXXXXXXXX
kontaktní osoba: Xxx. Xxxxxxx Xxxxxxxxxx – ve věcech smluvního plnění,
email: XXXXXXXXXX, tel.: XXXXXXXXXXX
(dále jen „objednatel“) a
ALTAIR SOFTWARE s.r.o.
kterou zastupuje: Xx. Xxxxx Xxxxx, jednatel
se sídlem: Xxxxxxxxx 00/0, 000 00 Xxxxxxx
IČO: 28350511
DIČ: CZ28350511
bankovní spojení: Raiffeisenbank CZ a.s., účet č.: XXXXXXXXXXX kontaktní osoba: Xx. Xxxxx Xxxxx, jednatel – ve věcech smluvních
email: XXXXXXXXXX, tel. XXXXXXXXXXXX
kontaktní osoba: p. Xxxxxxxx Xxxxxxxxx – ve věcech smluvního plnění,
email: XXXXXXXXXX, tel. XXXXXXXXXXXX
zapsaná v obchodním rejstříku Krajského soudu v Ostravě, spisová značka oddíl C, vložka 61771 (dále jen „poskytovatel“)
Smluvní strany uzavírají níže uvedeného dne, měsíce a roku v souladu s nabídkou poskytovatele a rozhodnutím objednatele jako zadavatele o výběru nejvýhodnější nabídky ve výběrovém řízení veřejné zakázky vedené pod sp. zn. 23041/2020-UVCR, s názvem „Programátorské práce – Jednotný informační systém pro adiktologické služby“ tuto smlouvu (dále jen „smlouva“).
Veřejná zakázka, na jejímž základě je uzavírána tato smlouva, je realizována jako součást projektu
„Systémová podpora rozvoje adiktologických služeb v rámci integrované protidrogové politiky“, reg. č.: CZ.03.2.63/0.0/0.0/15_030/0003035.
Stránka 1 (celkem 68)
Plnění této smlouvy je veřejnou zakázkou malého rozsahu dle § 27 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“).
Článek I. Předmět a účel smlouvy
1. Předmětem této smlouvy je závazek poskytovatele vytvořit pro objednatele jednotný informační systém pro adiktologické služby jako webovou databázovou aplikaci. Plnění dle této smlouvy bude rozděleno do tří dílčích fází:
1. fáze plnění – vývoj webové databázové aplikace v rozsahu dle přílohy č. 1 této smlouvy;
2. fáze plnění - testování webové databázové aplikace a
3. fáze plnění – provedení změn a vylepšení informačního systému.
2. Dále je předmětem této smlouvy závazek objednatele za řádně a včas poskytnuté služby zaplatit poskytovateli cenu dle čl. III této smlouvy.
3. Podrobný popis předmětu plnění této smlouvy je uveden v příloze č. 1 této smlouvy.
4. Účelem této smlouvy je vytvořit informační systém, který bude sloužit k:
a) Evidenci všech procesů spjatých s poskytováním adiktologických služeb jednotlivých poskytovatelů těchto služeb.
b) Vyhodnocování výkonosti a nákladovosti pro potřeby jednotlivých donátorů – poskytovatelů dotací.
c) Exportům dat do dalších agend.
Článek II.
Doba, místo plnění a akceptace plnění
1. Předmět plnění dle čl. I této smlouvy bude poskytovatelem poskytnut v termínech uvedených v tomto článku smlouvy a v příloze č. 1 této smlouvy.
2. Místem plnění předmětu této smlouvy se rozumí místo předání všech výstupů plnění objednateli a zároveň místo, kde bude probíhat testování a komunikace mezi objednatelem a poskytovatelem. Místem plnění této smlouvy je sídlo objednatele.
3. První fázi plnění - vývoj webové databázové aplikace v rozsahu dle přílohy č. 1 této smlouvy, předá poskytovatel objednateli do 24 týdnů ode dne nabytí účinnosti smlouvy. O předání první fáze plnění bude sepsán předávací protokol č. 1, který bude potvrzen podpisy oprávněného zástupce objednatele a poskytovatele. Návrh předávacího protokolu připraví poskytovatel a bude sepsán ve 2 vyhotoveních, z nichž každá smluvní strana obdrží po 1 vyhotovení.
4. Druhá fáze - testování webové databázové aplikace, bude probíhat 4 týdny ode dne předání webové databázové aplikace, resp. po dokončení první fáze plnění a po podpisu předávacího protokolu č. 1 dle předchozího odstavce tohoto článku. V této fázi budou prováděny následující činnosti:
a) testování aplikace betatestery, kteří budou reportovat chyby a závady, které budou sdělovány dodavateli (připomínky a požadavky na opravu nebo doplnění předané aplikace). Poskytovatel tyto vady opraví v termínu určeném objednatelem s ohledem na povahu a charakter těchto vad. Po zapracování připomínek a odstranění požadovaných vad aplikace podepíše objednatel akceptační protokol č. 1. Návrh dílčího akceptačního protokolu č. 1 připraví poskytovatel ve 2 vyhotoveních, která podepíší oprávnění zástupci obou smluvních stran, přičemž každá smluvní strana obdrží po 1 vyhotovení.
b) uplatňování požadavků objednatele na vylepšení a dílčí změny aplikace. Tyto požadavky na vylepšení a změny budou zpracovány interním týmem objednatele, budou jim přidělené priority a budou přesně popsány pro účely zadání pro třetí fázi. Požadavky na vylepšení
a změny budou zpracovány v rozsahu schváleném oběma smluvními stranami do akceptačního protokolu č. 2. Návrh dílčího akceptačního protokolu č. 2 připraví poskytovatel ve 2 vyhotoveních, která podepíší oprávnění zástupci obou smluvních stran, přičemž každá smluvní strana obdrží po 1 vyhotovení.
5. Třetí fáze, provedení změn a vylepšení informačního systému, bude probíhat 8 týdnů po skončení testovací fáze, tj. po schválení rozsahu změn a vylepšení a po podpisu akceptačního protokolu č. 2 dle odstavce 4 písm. b) tohoto článku. O předání dílčího plnění v rámci třetí fáze poskytovatelem objednateli bude sepsán předávací protokol č. 2, který bude potvrzen podpisy oprávněného zástupce objednatele a poskytovatele. Návrh předávacího protokolu č. 2 připraví poskytovatel a bude sepsán ve 2 vyhotoveních, z nichž každá smluvní strana obdrží po 1 vyhotovení. Objednatel si vyhrazuje právo uplatnit připomínky do 30 dnů od odevzdání finálního informačního systému v rámci třetí fáze plnění. Poskytovatel je povinen připomínky vypořádat do 15 dnů, pokud s ohledem na charakter připomínek nebude dohodnuta jiná lhůta. Objednatel neposkytne delší lhůtu k odstranění vad plnění v případě, že v průběhu plnění poskytovatele v rámci svých připomínek na tyto vady poskytovatele již upozornil. Po vypořádání připomínek v souladu s požadavky objednatele podepíše objednatel akceptační protokol č. 3. Návrh dílčího akceptačního protokolu č. 3 připraví poskytovatel ve 2 vyhotoveních, která podepíší oprávnění zástupci obou smluvních stran, přičemž každá smluvní strana obdrží po 1 vyhotovení. Objednatel akceptuje podpisem akceptačního protokolu č. 3 pouze plnění bez vad a nedodělků.
6. Objednatel i poskytovatel jsou oprávněni provádění plnění přerušit nastane-li nějaká z okolností uvedená v čl. XIII této smlouvy a po dobu přerušení plnění, během níž trvají okolnosti uvedené v čl. XIII se prodlužuje se lhůta ke splnění smluvních povinností.
Článek III.
Cena a platební podmínky
1. Cena za plnění předmětu této smlouvy činí 1.806.268,39 Kč bez DPH, tj. 2.185.584,76 Kč včetně DPH. Cena za plnění předmětu této smlouvy se skládá z těchto částí:
a) částky ve výši 1.506.268,39 tj. bez DPH, tj. 1.822.584,76 Kč včetně DPH, kterou je poskytovatel oprávněn fakturovat objednateli po zapracování chyb vzešlých z testování v druhé fázi a po podpisu akceptačního protokolu č. 1.
b) částky ve výši 300.000,00 Kč bez DPH, tj. 363.000,00 Kč včetně DPH, kterou je poskytovatel oprávněn fakturovat objednateli po předání kompletního předmětu plnění, včetně kompletních zdrojových kódů a dokumentace po ukončení fáze 3 a po podpisu akceptačního protokolu č. 2 a 3.
dále jen „dílčí cena předmětu plnění“.
2. Cena dle odst. 1 tohoto článku odpovídá rozsahu plnění dle této smlouvy a nabídce poskytovatele a zahrnuje veškeré náklady a poplatky poskytovatele nutné nebo související s řádným plněním předmětu této smlouvy, zejména odměny za poskytnutí práv duševního vlastnictví včetně zdrojového kódu dle čl. V této smlouvy a náklady za zpracování osobních údajů a nakládání s nimi, dopravu do místa plnění, režijní náklady poskytovatele atd.
3. Cena dle odst. 1 tohoto článku je stanovena jako nejvýše přípustná a nepřekročitelná, s výjimkou změny sazby DPH; v takovém případě není třeba uzavírat dodatek k této smlouvě, ale bude aplikována sazba DPH vždy v aktuální výši dle platných právních předpisů. Poskytovatel bude fakturovat cenu s DPH dle sazby DPH platné v době uskutečnění zdanitelného plnění.
4. Faktura poskytovatele musí obsahovat náležitosti obchodní listiny dle § 435 občanského zákoníku a daňového dokladu dle zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů a dle zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „ZDPH“). Na faktuře musí být uvedeno „Systémová podpora rozvoje adiktologických služeb v rámci integrované protidrogové politiky“, reg. č.:CZ.03.2.63/0.0/0.0/15_030/0003035 a evidenční číslo této smlouvy uvedené v záhlaví této smlouvy a číslo objednávky vystavené
objednatelem v Integrovaném informačním systému státní pokladny. Přílohou faktury dle odstavce 1 písmeno a) tohoto článku smlouvy musí být kopie objednatelem podepsaného akceptačního protokolu č. 1 dle čl. II odst. 4 písm. a) této smlouvy. Přílohou faktury dle odstavce 1 písmeno b) tohoto článku smlouvy musí být kopie objednatelem podepsaného akceptačního protokolu č. 2 dle čl. II odst. 4 písm. b) této smlouvy a zároveň akceptačního protokolu č. 3 dle čl. II odst. 5 této smlouvy.
5. V případě, že úhrada dílčí ceny předmětu plnění má být provedena zcela nebo zčásti bezhotovostním převodem na účet vedený poskytovatelem platebních služeb mimo tuzemsko ve smyslu § 109 odst. 2 písm. b) ZDPH, nebo číslo bankovního účtu poskytovatele uvedené v této smlouvě nebo na daňovém dokladu vystaveném poskytovatelem nebude uveřejněno způsobem umožňujícím dálkový přístup ve smyslu § 109 odst. 2 písm. c) ZDPH a nebo stane-li se poskytovatel nespolehlivým plátcem ve smyslu § 106a ZDPH, je objednatel oprávněn uhradit poskytovateli pouze tu část peněžitého závazku vyplývajícího z daňového dokladu, jež odpovídá výši základu daně, a zbylou část pak ve smyslu § 109a ZDPH uhradit přímo správci daně s tím, že se má za to, že úhrada daňového dokladu (faktury) bez DPH je provedena ve správné výši.
6. V případě, že faktura nebude mít stanovené náležitosti nebo bude obsahovat chybné údaje, je objednatel oprávněn tuto fakturu ve lhůtě její splatnosti vrátit poskytovateli, aniž by se tím objednatel dostal do prodlení s úhradou faktury. Nová lhůta splatnosti počíná běžet dnem obdržení opravené nebo nově vystavené faktury. Důvod případného vrácení faktury musí být objednatelem jednoznačně vymezen.
7. Objednatel uhradí fakturu bezhotovostně převodem na účet poskytovatele do 21 dnů ode dne obdržení faktury. Zaplacením se rozumí odepsání finanční částky z účtu objednatele ve prospěch účtu poskytovatele.
9. Změnu účtu, na který je objednatel povinen hradit platbu, je poskytovatel oprávněn provést jednostranným písemným oznámením objednateli.
Článek IV.
Odpovědnost za vady a náhrada škody
1. Poskytovatel odpovídá za to, že předmět plnění má vlastnosti stanovené touto smlouvou a zejména přílohou č. 1, tj. zejména byl zpracován způsobem, který odpovídá účelu této smlouvy v odpovídající odborné kvalitě. Poskytovatel poskytuje objednateli na výstupy předmětu plnění záruku po dobu 24 měsíců od podpisu akceptačního protokolu č. 3 objednatelem dle čl. II odst. 5 této smlouvy.
2. V případě, že objednatel zjistí vady předmětu plnění v záruční době, je poskytovatel povinen tyto vady odstranit nejpozději do 5 dnů ode dne oznámení vad objednatelem poskytovateli. S ohledem na charakter zjištěných vad je objednatel oprávněn stanovit poskytovateli lhůtu delší.
3. O dobu odstraňování vady se prodlužuje záruční doba.
4. Reklamaci lze uplatnit nejpozději do posledního dne záruční doby, přičemž reklamace odeslaná objednatelem v poslední den záruční doby se považuje za včas uplatněnou.
5. Poskytovatel odstraní v záruční době reklamované vady na svůj náklad. Odmítne-li poskytovatel odstranit reklamované vady, případně neodstraní-li je do 15 dnů od písemného nahlášení či objednatelem stanoveného termínu, je objednatel oprávněn odstranit vady sám nebo prostřednictvím jiné osoby a náklady s tím spojené vyúčtovat poskytovateli.
6. Poskytovatel odpovídá za škody, které svou činností způsobí objednateli nebo třetím osobám, a to zejména v důsledku neplnění podmínek vyplývajících z právních předpisů nebo z této
smlouvy. Jakoukoliv škodu takto vzniklou je poskytovatel povinen bezodkladně odstranit a není- li to možné, pak finančně nahradit v plné výši.
7. Uplatněním odpovědnosti za vady nejsou dotčeny nároky na náhradu škody nebo na uplatnění smluvní pokuty.
8. V případě sporu o oprávněnost reklamace budou smluvní strany respektovat vyjádření a konečné stanovisko soudního znalce vybraného objednatelem. Náklady na vypracování znaleckého posudku nese v plné výši smluvní strana, která nebude ve sporu o oprávněnost reklamace úspěšná.
9. Každá smluvní strana je povinna nahradit způsobenou škodu v rámci platných právních předpisů a této smlouvy. Obě smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod.
10. Žádná ze stran neodpovídá za škodu, která vznikla v důsledku věcně nesprávného nebo jinak chybného zadání, které obdržela od druhé smluvní strany. V případě, že jedna ze smluvních stran poskytla druhé smluvní straně chybné zadání a příslušná smluvní strana s ohledem na svoji povinnost poskytovat plnění s odbornou péčí mohla a měla chybnost takového zadání zjistit, smí se ustanovení předchozí věty domáhat pouze v případě, že na chybné zadání příslušná smluvní strana druhou smluvní stranu písemně upozornila a druhá smluvní strana trvala na původním zadání.
11. Případná náhrada škody bude nahrazena uvedením do původního stavu a v případě nemožnosti uvedení v původní stav bude uhrazena v měně platné na území České republiky, přičemž pro propočet na tuto měnu je rozhodný kurz České národní banky ke dni vzniku škody.
Článek V.
Práva duševního vlastnictví
1. Poskytovatel se zavazuje, že při zhotovování díla resp. částí díla neporuší práva třetích osob, která těmto osobám mohou plynout z práv k duševnímu vlastnictví, zejména z autorských práv a práv průmyslového vlastnictví, že je plně oprávněn disponovat s právy, která touto smlouvou postupuje na objednatele, nebo k jejichž užití poskytuje Objednateli dle této smlouvy licenci, a zavazuje se za tímto účelem zajistit řádné a nerušené užívání plnění, resp. částí plnění objednatelem, včetně případného zajištění dalších souhlasů a licencí od autorů děl v souladu s autorským zákonem popř. od nositelů jiných práv duševního vlastnictví v souladu s právními předpisy. Poskytovatel se zavazuje, že objednateli uhradí veškeré náklady, výdaje, škody a majetkovou i nemajetkovou újmu, které objednateli vzniknou v důsledku porušení povinností dle předchozí věty.
2. Je-li výsledkem činnosti poskytovatele dle této smlouvy anebo součástí předaného plnění výtvor, který je předmětem práv autorských, práv souvisejících či předmětem práv pořizovatele k jím pořízené databázi, a nejde přitom o dílo anebo jeho části vytvořené jako zaměstnanecké dílo (dále pro účely tohoto článku souhrnně jen „předměty ochrany podle autorského zákona“), náleží od okamžiku předání plnění, resp. částí plnění dle této smlouvy objednateli pro území celého světa včetně České republiky výhradní neomezené právo k užití těchto předmětů ochrany podle autorského zákona, a to na dobu trvání práva k předmětům ochrany podle autorského zákona, resp. na zákonnou dobu ochrany. Poskytovatel touto smlouvou poskytuje objednateli oprávnění k výkonu uvedeného výhradního práva k užití předmětů ochrany podle autorského zákona (licence) bez časového, územního a množstevního omezení a pro všechny způsoby užití. Objednatel je oprávněn předměty ochrany podle autorského zákona užít v původní nebo jiné zpracované či jinak změněné podobě, samostatně nebo v souboru anebo ve spojení s jiným dílem či prvky. Oprávnění k užití předmětů ochrany podle autorského zákona získává objednatel jako převoditelná s právem podlicence a dále postupitelná. Postoupení licence nebo její části na třetí osobu nevyžaduje souhlas poskytovatele a objednatel není povinen postoupení licence nebo její části na třetí osobu poskytovateli oznamovat. Toto právo objednatele k předmětům ochrany podle autorského zákona se automaticky vztahuje i na všechny nové verze, úpravy a překlady předmětů ochrany podle autorského zákona dodané poskytovatelem. Objednatel není povinen výše uvedenou licenci využít. Poskytovatel dále poskytuje objednateli právo upravovat a/nebo překládat předměty ochrany
podle autorského zákona, včetně práva objednatele zadat provedení těchto úprav a/nebo překladů třetím osobám. Dohodou smluvních stran se stanoví, že cena za užití předmětů ochrany podle autorského zákona dle tohoto odstavce je součástí ceny plnění dle čl. III odst. 1 této smlouvy.
3. Je-li výsledkem činnosti poskytovatele dle této smlouvy anebo součástí předaného plnění výtvor, který je předmětem práv průmyslového vlastnictví, avšak dosud nebyl k ochraně nebo na základě přihlášky zapsán či udělen anebo se jeho zápis nevyžaduje, zejména vynález, užitný vzor či průmyslový vzor (dále pro účely tohoto článku souhrnně jen „nezapsané předměty průmyslových práv“), převádí poskytovatel na objednatele od okamžiku předání díla dle této smlouvy veškerá práva na nezapsané předměty průmyslových práv, zejména pak právo na patent, právo na užitný vzor a právo na průmyslový vzor. Objednatel je oprávněn zejména nezapsané předměty průmyslových práv přihlásit k ochraně na území České republiky a jiných teritoriích a neomezeně je i po jejich zápisu využívat na území celého světa včetně České republiky. Toto právo objednatele k nezapsaným předmětům průmyslových práv se automaticky vztahuje i na všechny nové verze a úpravy nezapsaných předmětů průmyslových práv dodaných poskytovatelem na základě této smlouvy. Poskytovatel je o takovémto výtvoru povinen objednatele neprodleně informovat. Dohodou smluvních stran se stanoví, že cena za převod práv k nezapsaným předmětům průmyslových práv je součástí ceny plnění dle čl. III odst. 1 této smlouvy.
4. Je-li výsledkem činnosti poskytovatele dle této smlouvy anebo součástí předaného plnění výtvor, který je již chráněn zapsaným či uděleným právem z průmyslového vlastnictví, zejména udělený či zapsaný vynález, užitný vzor či průmyslový vzor (dále pro účely tohoto článku souhrnně jen „zapsané předměty průmyslových práv“), náleží objednateli od okamžiku předání plnění, resp. části plnění podle této smlouvy k zapsaným předmětům průmyslových práv výhradní neomezené právo k užití těchto zapsaných předmětů průmyslových práv, a to pro území celého světa včetně České republiky. Poskytovatel touto smlouvou opravňuje objednatele k výkonu uvedených výhradních práv k zapsaným předmětům průmyslových práv, a to bez časového, územního a množstevního omezení a pro všechny způsoby užití. Oprávnění k užití zapsaných předmětů průmyslových práv získává objednatel jako převoditelná s právem podlicence a dále postupitelná. Toto právo objednatele k zapsaným předmětům průmyslových práv se automaticky vztahuje i na všechny nové verze a úpravy zapsaných předmětů průmyslových práv dodaných poskytovatelem, ať již budou přihlášeny k ochraně či nikoliv. Poskytovatel je o takovémto výtvoru povinen objednatele neprodleně informovat. Poskytovatel je dále povinen učinit veškeré nezbytné úkony a poskytnout objednateli veškerou nezbytnou součinnost směřující k zápisu uvedené licence k zapsaným předmětům průmyslových práv do příslušných rejstříků. Poskytovatel rovněž poskytuje objednateli právo upravovat a modifikovat zapsané předměty průmyslových práv, včetně práva objednatele zadat vývoj a provedení těchto úprav a modifikací třetím osobám. Dohodou smluvních stran se stanoví, že cena za převod práv k zapsaným předmětům průmyslových práv je součástí ceny plnění dle čl. III odst. 1 této smlouvy.
5. Je-li výsledkem činnosti poskytovatele dle této smlouvy anebo součástí předaného plnění výtvor, který může být předmětem majetkových práv, vyjma v předchozích odstavcích uvedených předmětů chráněných podle autorského zákona a předmětů průmyslového vlastnictví požívajících zvláštní ochrany, přičemž jde zejména o know-how či nezapsaná označení (dále pro účely tohoto článku souhrnně jen „ostatní předměty duševního vlastnictví“), převádí poskytovatel na objednatele od okamžiku předání plnění, resp. části plnění veškerá práva k ostatním předmětům duševního vlastnictví. Objednatel je oprávněn zejména ostatní předměty duševního vlastnictví neomezeně využívat na území celého světa včetně České republiky. Toto právo objednatele k ostatním předmětům duševního vlastnictví se automaticky vztahuje i na všechny nové verze a úpravy ostatních předmětů duševního vlastnictví dodaných poskytovatelem. Poskytovatel je o takovémto výtvoru povinen objednatele neprodleně informovat. Poskytovatel rovněž poskytuje objednateli právo upravovat a modifikovat ostatní předměty duševního vlastnictví, včetně práva objednatele zadat vývoj a provedení těchto úprav a modifikací třetím osobám. Dohodou smluvních stran se stanoví, že cena za užití ostatních předmětů duševního vlastnictví dle tohoto odstavce je součástí ceny plnění dle čl. III odst. 1 této smlouvy.
6. Je-li výsledkem nebo součástí plnění resp. částí plnění i zaměstnanecké či kolektivní dílo, které je předmětem autorských práv, práv souvisejících s právem autorským či práv pořizovatele k jím pořízené databázi, poskytovatel jako zaměstnavatel či osoba, z jejíhož podnětu apod., jejímž vedením je dílo vytvářeno a pod jejímž jménem je dílo uváděno na veřejnost, ke dni předání plnění resp. části plnění dle této smlouvy postupuje právo výkonu majetkových práv k dílu na objednatele, přičemž výše odměny za postoupení je již zahrnuta v ceně plnění dle čl. III odst. 1 této smlouvy. Objednatel se tím stává ve vztahu ke všem částem plnění i plnění jako celku vykonavatelem autorských práv majetkových v pozici zaměstnavatele se všemi souvislostmi včetně oprávnění vyplývajících z omezení osobnostních práv původních autorů v plném rozsahu dle § 58 autorského zákona, přičemž právo výkonu majetkových práv autorských získává objednatel jako dále postupitelné. Objednatel je tak především oprávněn plnění i jeho části bez dalšího sám jakýmkoli způsobem užít v původní, zpracované či jinak změněné podobě a udělit třetím osobám oprávnění (licenci) k výkonu práva plnění a jeho části užít. Objednatel je dále oprávněn nehotové anebo nedostatečně podrobné části plnění dokončit, a to bez ohledu na podmínky podle ustanovení § 58 odst. 5 autorského zákona. Poskytovateli ani původním autorům nenáleží nárok na přiměřenou dodatečnou odměnu podle ustanovení § 58 odst. 6 autorského zákona. Objednatel je oprávněn plnění anebo jeho části zveřejnit, upravovat, zpracovávat včetně překladu, spojit s jiným dílem, zařadit do díla souborného a uvádět je na veřejnost pod vlastním jménem, včetně oprávnění objednatele zadat vývoj a provedení těchto úprav a modifikací třetím osobám.
Článek VI. Realizační tým
1. Poskytovatel prohlašuje, že plnění předmětu této smlouvy bude realizovat členy realizačního týmu, které uvedl v nabídce a kteří splnili kritéria technické kvalifikace minimálně v rozsahu požadovaném zadavatelem v čl. 4.3.2 výzvy k podání nabídky a v případě, že se bude jednat o odnoceného člena realizačního týmu i zkušenosti minimálně v rozsahu hodnocení dle čl. 6.3.2 výzvy k podání nabídky.
2. Složení realizačního týmu podle odstavce 1 tohoto článku, které bylo předloženo v nabídce poskytovatele podané ve výběrovém řízení, je pro poskytovatele závazné, stejně jako požadavky na jednotlivé členy realizačního týmu uvedené ve výzvě k podání nabídek.
3. Členové realizačního týmu uvedení v nabídce poskytovatele jako účastníka výběrového řízení se musejí aktivně podílet na plnění předmětu této smlouvy. V případě potřeby změny člena realizačního týmu uvedeného v nabídce poskytovatele je změna možná pouze se souhlasem objednatele. Objednatel tento souhlas neudělí v případě, že by po takové změně realizační tým nesplňoval požadavky objednatele na realizační tým dle výzvy k podání nabídky. Objednatel tento souhlas neudělí také v případě, že by po takové změně nový člen realizačního týmu nesplňoval veškeré požadavky objednatele pro danou pozici člena realizačního týmu, uvedené jako kritéria technické kvalifikace ve výzvě k podání nabídek.
4. V případě potřeby změny člena realizačního týmu poskytovatel písemně požádá o souhlas objednatele s touto změnou minimálně 14 dní před touto změnou. Výjimkou je situace, kdy poskytovatel jednoznačně prokáže, že lhůtu dle předchozí věty nemohl dodržet z důvodu nespočívajícího na jeho straně (např. pracovní neschopnost člena realizačního týmu, či úmrtí člena realizačního týmu), v takovém případě je povinen požádat o souhlas bezodkladně po zjištění těchto důvodů. Součástí žádosti o souhlas se změnou člena realizačního týmu musejí být doklady prokazující splnění podmínek kvalifikace nahrazovaného člena realizačního týmu.
5. Změna člena realizačního týmu bez souhlasu objednatele se považuje za podstatné porušení smlouvy, a to bez ohledu na to, zda se jedná o člena vyhovujícího požadavkům dle zadávacích podmínek a této smlouvy či nikoliv.
Článek VII.
Využití poddodavatelů
1. Poskytovatel v nabídce uvedl, že poskytnutí plnění zajistí bez poddodavatele, tudíž se jejich využití nepředpokládá.
Článek VIII. Ochrana informací
1. Smluvní strany jsou si vědomy toho, že v rámci plnění závazků z této smlouvy
a) si mohou vzájemně vědomě nebo opomenutím poskytnout informace, které budou považovány za důvěrné (dále jen „důvěrné informace“),
b) mohou jejich zaměstnanci či osoby v obdobném postavení získat vědomou činností druhé smluvní strany nebo i jejím opomenutím přístup k důvěrným informacím druhé smluvní strany.
2. Smluvní strany se zavazují, že žádná z nich nezpřístupní třetí osobě důvěrné informace (bez ohledu na formu jejich zachycení), které získaly během jednání vedoucích k uzavření této smlouvy nebo během plnění závazků z této smlouvy. Tím není dotčeno oprávnění smluvních stran sdělovat tyto údaje svým advokátům, daňovým poradcům, auditorům nebo jiným osobám vázaným na základě zvláštního právního předpisu povinností mlčenlivosti. Tyto osoby musí být na důvěrnost údajů upozorněny.
3. Za třetí osoby dle odst. 2 tohoto článku se nepovažují:
a) zaměstnanci smluvních stran a osoby v obdobném postavení,
b) orgány smluvních stran a jejich členové,
c) ve vztahu k důvěrným informacím objednatele subdodavatelé poskytovatele,
d) ve vztahu k důvěrným informacím poskytovatele externí poskytovatelé objednatele, a to i potenciální,
za předpokladu, že se podílejí na plnění této smlouvy nebo plnění spojeném s plněním dle této smlouvy, důvěrné informace jsou jim zpřístupněny výhradně za tímto účelem a zpřístupnění důvěrných informací je v rozsahu nezbytně nutném pro naplnění jeho účelu a za stejných podmínek, jaké jsou stanoveny smluvním stranám v této smlouvě.
4. Smluvní strany se zavazují v plném rozsahu zachovávat povinnost mlčenlivosti a povinnost chránit důvěrné informace vyplývající z této smlouvy a z příslušných právním předpisů, zejména povinnosti vyplývající z 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 (dále jen „obecné nařízení“).
5. Smluvní strany se zavazují poučit veškeré osoby, které se na jejich straně budou podílet na plnění této smlouvy, o výše uvedených povinnostech mlčenlivosti a ochrany informací a dále se zavazují vhodným způsobem zajistit dodržování těchto povinností všemi osobami podílejícími se na plnění této smlouvy.
6. Budou-li informace poskytnuté objednatelem, poskytovatelem nebo třetími stranami, které jsou nezbytné pro plnění dle této smlouvy, obsahovat data podléhající režimu zvláštní ochrany dle obecného nařízení, zavazují se smluvní strany plnit všechny povinnosti, které obecné nařízení vyžaduje, a obstarat předepsané souhlasy subjektů osobních údajů předaných ke zpracování.
7. Veškeré důvěrné informace zůstávají výhradním vlastnictvím předávající strany a příjímací strana vyvine pro zachování jejich důvěrnosti a pro jejich ochranu stejné úsilí, jako by se jednalo o její vlastní důvěrné informace. S výjimkou rozsahu, který je nezbytný pro plnění této smlouvy, se smluvní strany zavazují nepublikovat žádným způsobem důvěrné informace druhé strany, nepředávat je třetí straně ani svým vlastním zaměstnancům a zástupcům s výjimkou těch, kteří s nimi potřebují být seznámeni, aby mohli plnit tuto smlouvu. Obě smluvní strany se zároveň zavazují nepoužít důvěrné informace druhé smluvní strany jinak, než za účelem plnění této smlouvy.
8. Nedohodnou-li se smluvní strany výslovně písemnou formou jinak, považují se za důvěrné implicitně všechny informace, které jsou anebo by mohly být součástí obchodního tajemství, tj. například, ale nejenom, popisy nebo části popisů technologických procesů a vzorců, technických vzorců a technického know-how, informace o provozních metodách, procedurách a provozních postupech, obchodní nebo marketingové plány, koncepce a strategie nebo jejich
části, nabídky, kontakty, smlouvy, dohody nebo jiná ujednání s třetími stranami, informace
o výsledcích hospodaření, o vztazích s obchodními partnery, o pracovních otázkách a všechny další informace, jejichž zveřejnění přijímající stranou by předávající straně mohlo způsobit škodu.
9. Pokud jsou důvěrné informace poskytovány v písemné podobě anebo ve formě textových souborů na elektronických nosičích dat (médiích), je předávající strana povinna upozornit přijímající stranu na důvěrnost takového materiálu jejím vyznačením alespoň na titulní stránce nebo přední straně média. Absence takového upozornění však nezpůsobuje zánik povinnosti ochrany takto poskytnutých informací.
10. Bez ohledu na výše uvedená ustanovení se za důvěrné nepovažují informace, které:
a) se staly veřejně známými, aniž by jejich zveřejněním došlo k porušení závazků přijímající smluvní strany či právních předpisů,
b) měla přijímající strana prokazatelně legálně k dispozici před uzavřením této smlouvy, pokud takové informace nebyly předmětem jiné, dříve mezi smluvními stranami uzavřené smlouvy o ochraně informací,
c) jsou výsledkem postupu, při kterém k nim přijímající strana dospěje nezávisle, a to je schopna doložit svými záznamy nebo informacemi, včetně důvěrných, třetí strany,
d) po podpisu této smlouvy poskytne přijímající straně třetí osoba, jež není omezena v takovém nakládání s informacemi,
e) mají být zpřístupněny na základě zákona či jiného právního předpisu včetně práva EU nebo závazného rozhodnutí oprávněného orgánu veřejné moci,
f) jsou obsažené v této smlouvě a jsou zveřejněné dle § 219 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“) nebo dle zákona č. 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, ve znění pozdějších předpisů (dále jen „zákon o registru smluv“).
11. Každá smluvní strana se zavazuje přijmout technická a organizační vnitřní opatření nezbytná k ochraně důvěrných informací. Poskytovatel je povinen poučit své zaměstnance a členy svých orgánů o povinnosti zachovávat mlčenlivost podle této smlouvy a je povinen zachování mlčenlivosti z jejich strany řádně kontrolovat. Zaměstnanci poskytovatele nesmí důvěrné skutečnosti, které se dozvěděli v souvislosti s touto smlouvou, sdělovat ani jiným zaměstnancům dodavatele nebo členům orgánů dodavatele, není-li to nezbytné k plnění jejich pracovních úkolů nebo z hlediska funkčního zařazení.
12. Poskytovatel je povinen zavázat povinností mlčenlivosti a ochrany důvěrných informací dle tohoto článku rovněž všechny poddodavatele, kteří se budou podílet na plnění předmětu veřejné zakázky dle této smlouvy.
13. Za porušení povinnosti mlčenlivosti osobami, které se budou podílet na plnění předmětu smlouvy, odpovídá poskytovatel, jako by povinnost porušil sám.
14. Ukončení účinnosti této smlouvy z jakéhokoliv důvodu se nedotkne ustanovení tohoto článku a jeho účinnost přetrvá i po ukončení účinnosti této smlouvy.
Článek IX.
Sleva z plnění, smluvní pokuta, úrok z prodlení
1. V případě prodlení s předáním jednotlivého výstupu předmětu plnění ve lhůtě stanovené v čl. II odst. 3 a 4 této smlouvy nebo v příloze č. 1 této smlouvy je poskytovatel povinen poskytnout objednateli slevu z ceny plnění včetně DPH dle čl. III odst. 1 písm. a) této smlouvy ve výši 1 % za každý den prodlení. V případě prodlení s předáním jednotlivého výstupu předmětu plnění ve lhůtě stanovené v čl. II odst. 5 této smlouvy nebo v příloze č. 1 této smlouvy je poskytovatel povinen poskytnout objednateli slevu z ceny plnění včetně DPH dle čl. III odst. 1 písm. b) této smlouvy ve výši 0,5 % za každý den prodlení.
2. Poskytovatel je povinen uhradit objednateli příslušné smluvní pokuty v případě
a) neodstranění vad předmětu plnění ve lhůtách stanovených dle čl. II odst. 4 nebo 5 této smlouvy ve výši 200 Kč za každý započatý den prodlení;
b) neodstranění vad předmětu plnění ve lhůtě stanovené v čl. IV odst. 2 této smlouvy, ve výši 200 Kč za každý započatý den prodlení;
c) že objednatel řádně uplatní u poskytovatele své požadavky nebo připomínky v průběhu plnění předmětu této smlouvy a poskytovatel je bez vážného důvodu neakceptje nebo podle nich nepostupuje ve výši 500 Kč za každý jednotlivý případ;
d) porušení povinností dle čl. V této smlouvy ve výši 5.000 Kč za každý jednotlivý případ;
e) že poskytovatel nebude v rozporu s čl. VI této smlouvy poskytovat služby osobami, které jsou uvedeny v seznamu členů realizačního týmu, je objednatel oprávněn účtovat poskytovateli smluvní pokutu ve výši 2.000 Kč. Případná změna složení ve členech týmu musí být vždy dopředu písemně odsouhlasena objednatelem, dle podmínek této smlouvy.
f) jakéhokoliv porušení povinností uvedených v čl. VIII této smlouvy ve výši 5.000 Kč za každý takový případ.
3. Poskytovatel se zavazuje řádně a včas plnit své povinnosti vztahující se ke správě DPH po dobu trvání této smlouvy, zejména tuto daň řádně a včas zaplatit. Pokud v důsledku porušení tohoto závazku příslušný finanční úřad vyzve objednatele k zaplacení DPH z důvodu jeho ručení, zavazuje se poskytovatel zaplatit objednateli jednorázovou smluvní pokutu ve výši DPH vztahující se k porušení závazku poskytovatele řádně a včas zaplatit DPH (včetně příslušenství), s níž je spojeno ručení objednatele.
4. V případě prodlení objednatele se zaplacením faktury poskytovatele je poskytovatel oprávněn požadovat úroky z prodlení v zákonné výši z dlužné částky za každý den prodlení.
5. Celková výše smluvních pokut je omezena limitem do výše 50 % ceny plnění včetně DPH uvedené v čl. IV odst. 1 této smlouvy. Smluvní pokuty mohou být kombinovány (tzn., že uplatnění jedné smluvní pokuty nevylučuje souběžné uplatnění jakékoliv jiné smluvní pokuty).
6. Smluvní pokuta, či úroky z prodlení jsou splatné do 21 dnů ode dne doručení oznámení
o uložení smluvní pokuty objednatelem poskytovateli nebo oznámení o započetí s účtováním úroků z prodlení poskytovatelem objednateli. Pro případ pochybností o doručení oznámení
o uložení smluvní pokuty nebo oznámení o započetí s účtováním úroků z prodlení se sjednává, že se oznámení považuje za doručené druhé straně třetím dnem od podání zásilky k poštovní přepravě.
7. Zaplacením smluvní pokuty nebo slevy z plnění není jakkoliv dotčen nárok objednatele na náhradu škody a nemajetkové újmy; nárok na náhradu škody a nemajetkové újmy je objednatel oprávněn uplatnit vedle smluvní pokuty nebo slevy z plnění v plné výši. Zaplacením smluvní pokuty není dotčeno splnění povinnosti, která je prostřednictvím smluvní pokuty zajištěna.
Článek X. Ukončení smlouvy
1. Smluvní vztah vzniklý na základě této smlouvy lze ukončit těmito způsoby:
a) odstoupením od smlouvy:
i) za podmínek uvedených v občanském zákoníku,
ii) v případech, které si smluvní strany ujednaly dále v tomto článku smlouvy,
b) dohodou smluvních stran.
2. Objednatel je oprávněn odstoupit od smlouvy v případě:
a) prodlení s poskytnutím kteréhokoliv dílčího plnění nebo části dílčího plnění proti lhůtám uvedeným v čl. II anebo v příloze č. 1 této smlouvy delšího než 30 dnů;
b) že objednatel řádně uplatní u poskytovatele své požadavky nebo připomínky v průběhu plnění předmětu této smlouvy a poskytovatel je opakovaně (více než 2x) bez vážného důvodu neakceptuje nebo podle nich nepostupuje;
c) prodlení s odstraněním vad předmětu plnění dle čl. II odst. 4 nebo 5 nebo IV odst. 2 delšího než 30 dnů;
d) závažného porušení povinností dle čl. V anebo čl. VIII této smlouvy (opakované porušení – více než 2x nebo hrubé porušení);
e) opakovaného (více než 2x) porušení povinností souvisejících s realizačním týmem dle čl. VI této smlouvy.
Objednatel je oprávněn odstoupit z výše uvedených důvodů i jen pro budoucí plnění.
3. Účinky odstoupení od smlouvy nastávají okamžikem doručení písemného projevu vůle odstoupit od této smlouvy druhé smluvní straně.
4. Poskytovatel není oprávněn odstoupit od smlouvy z důvodů uvedených § 2382 občanského zákoníku.
5. Odstoupením od smlouvy není dotčen případný nárok na náhradu škody.
6. Práva a povinnosti smluvních stran dle čl. V nebo VIII této smlouvy, případně další, z jejichž povahy je zřejmé, že mají být zachovány i po skončení účinnosti této smlouvy, zůstávají zachovány i po ukončení této smlouvy.
Článek XI
Povinnost uchovávat doklady a umožnit kontrolu
Poskytovatel je povinen umožnit osobám oprávněným k výkonu kontroly projektu (zejm. objednateli, MPSV, MF, NKÚ, EK, Evropskému účetnímu dvoru), z něhož je zakázka hrazena, provést kontrolu dokladů souvisejících s plněním veřejné zakázky, a to po dobu danou právními předpisy ČR k jejich archivaci (zákon č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů, a ZDPH) a Pravidly OPZ (Obecné části pravidel pro žadatele a příjemce v rámci Operačního programu Zaměstnanost, verze 12), tj. minimálně do roku 2034.
Článek XII
Ochrana osobních údajů fyzických osob
1. Poskytovatel je povinen dle obecného nařízení od všech fyzických osob jako subjektu osobních údajů zajistit souhlasy se zpracováním těchto osobních údajů objednatelem pro účely kontroly zadávacího řízení řídícím orgánem, interními orgány zadavatele a dozorovými a kontrolními orgány.
2. Poskytovatel je povinen vyžádat si souhlas fyzických osob se zpracováním jejich osobních údajů pro danou oblast vědeckého výzkumu. Takto udělený souhlas musí být dán svobodně, být informovaný, vyjádřen zjevným potvrzením a být konkrétní pro daný předmět výzkumu.
3. Poskytovatel je povinen při plnění smlouvy dodržovat etické a metodické normy platné pro dané odvětví a to včetně ochrany osobní integrity fyzických osob.
Článek XIII. Vyšší moc
1. Smluvní strany jsou zproštěny odpovědnosti za částečné nebo úplné neplnění smluvních závazků, jestliže k němu došlo v důsledku vyšší moci. Za vyšší moc se pro účel smlouvy považují mimořádné události nebo okolnosti, které nemohla žádná ze smluvních stran před uzavřením této smlouvy předvídat ani jí předejít přijetím preventivního opatření, která je mimo jakoukoliv kontrolu kterékoliv smluvní strany a která podstatným způsobem ztěžuje nebo znemožňuje plnění povinností dle této smlouvy kteroukoliv ze smluvních stran.
2. Za vyšší moc se dále považují zejména válka, nepřátelské vojenské akce, teroristické útoky, povstání, občanské nepokoje, vzpoury, vyhlášení nouzového stavu, omezení pohybu osob, přítomnost ionizujícího nebo radioaktivního záření, požár, výbuch, záplava a jiné živelné nebo přírodní katastrofy.
3. Pro účely této smlouvy se za vyšší moc dále považuje i situace, které na základě rozhodnutí objednatele znemožní poskytovateli přístup do prostor objednatele.
4. Výslovně se stanovuje, že vyšší mocí není stávka zaměstnanců poskytovatele nebo jeho poddodavatelů, ani hospodářské poměry smluvních stran.
5. V případě, že nastane vyšší moc, prodlužuje se lhůta ke splnění smluvních povinností o dobu, během níž vyšší moc trvá a neuplatní se sankce dle čl. IX odst. 1 a 2 písm. a) a b) této smlouvy.
6. V případě, že některá smluvní strana nebude schopna plnit své závazky ze smlouvy v důsledku vyšší moci, bude povinna neprodleně a písemně o této skutečnosti vyrozumět druhou smluvní stranu. Obdobně poté, co účinky vyšší moci pominou, bude smluvní strana, jež byla vyšší mocí dotčena, povinna neprodleně a písemně vyrozumět druhou smluvní stranu o této skutečnosti.
Článek XIV.
Závěrečná ustanovení
1. Tuto smlouvu lze měnit nebo doplňovat pouze formou vzestupně číslovaných písemných dodatků, podepsaných oprávněnými zástupci smluvních stran na jedné listině.
2. Obě smluvní strany podpisem této smlouvy vylučují, aby nad rámec jejích výslovných ustanovení a ustanovení jejích příloh byla jakákoliv jejich práva či povinnosti dovozovány z dosavadní či budoucí praxe zavedené mezi smluvními stranami.
3. Poskytovatel převzal na sebe nebezpečí změny okolností po uzavření této smlouvy, a proto mu nepřísluší domáhat se práv uvedených v § 1765 odst. 1 občanského zákoníku.
4. Objednatel je povinným subjektem ve smyslu zákona o registru smluv. Poskytovatel souhlasí se zveřejněním této smlouvy, včetně všech jejích případných dodatků, především na profilu zadavatele a v Registru smluv. Splnění této zákonné povinnosti není porušením důvěrnosti informací. Poskytovatel výslovně souhlasí s tím, že uveřejněno bude úplné znění této smlouvy, včetně všech identifikačních a kontaktních údajů osob, které poskytovatel uvedl v textu této smlouvy. Je-li podle obecného nařízení k uveřejnění těchto údajů potřebný souhlas dotčených osob, poskytovatel výslovně prohlašuje, že takový souhlas všech dotčených osob zajistil. Smluvní strany se dohodly, že smlouvu zašle správci Registru smluv k uveřejnění objednatel a bude poskytovatele písemně informovat o uveřejnění smlouvy v Registru smluv. Poskytovatel je povinen zkontrolovat, že smlouva byla v Registru smluv řádně uveřejněna. V případě, že poskytovatel zjistí jakékoliv nepřesnosti či nedostatky, je povinen bez zbytečného odkladu o nich objednatele informovat. Objednatel je dále v souladu se ZZVZ povinen na profilu zadavatele uveřejnit skutečně uhrazenou cenu.
5. Tato smlouva nabývá platnosti dnem jejího podpisu smluvními stranami a účinnosti dnem jejího uveřejnění v Registru smluv.
6. Poskytovatel tímto dává objednateli výslovný souhlas se zpracováním a uchováváním, popř. uveřejněním (pokud takové uveřejní zvláštní právní předpisy vyžadují) osobních údajů dle obecného nařízení, a to v rozsahu, v jakém poskytovatel poskytl tyto údaje objednateli v rámci výběrového řízení (zejména doklady o kvalifikaci poskytovatele, jména a kontaktní údaje osob zastupujících poskytovatele a kontaktních osob, jména skutečných vlastníků právnických osob, údajů, jejichž předložení si objednatel vyhradil jako podmínku uzavření smlouvy atd.) a v rozsahu, v jakém jsou nezbytně nutné pro plnění zákonných povinností ze strany objednatele vztahujících se k výběrovému řízení a plnění předmětu veřejné zakázky a plnění smluvních povinností ze strany poskytovatele.
7. Nastanou-li u některé ze smluvních stran skutečnosti bránící řádnému plnění této smlouvy, je tato smluvní strana povinna to ihned bez zbytečného odkladu oznámit druhé straně a vyvolat jednání zástupců objednatele a poskytovatele.
8. Jednotlivá ustanovení smlouvy jsou oddělitelná v tom smyslu, že neplatnost některého z nich nepůsobí neplatnost smlouvy jako celku. Pokud jakýkoli závazek dle smlouvy nebo kterékoli ustanovení smlouvy je nebo se stane neplatným či nevymahatelným, nebude to mít vliv na platnost a vymahatelnost ostatních závazků a ustanovení dle smlouvy a smluvní strany se zavazují takovýto neplatný nebo nevymahatelný závazek či ustanovení nahradit novým, platným a vymahatelným závazkem, nebo ustanovením, jehož předmět bude nejlépe odpovídat předmětu a ekonomickému účelu původního závazku či ustanovení.
9. Pokud by se v důsledku změny právní úpravy některé ustanovení smlouvy dostalo do rozporu s českým právním řádem (dále jen „kolizní ustanovení“) a předmětný rozpor by působil neplatnosti smlouvy jako takové, bude smlouva posuzována, jako by kolizní ustanovení nikdy neobsahovala a vztah smluvních stran se bude v této záležitosti řídit obecně závaznými právními
předpisy, pokud se smluvní strany nedohodnou na znění nového ustanovení, jež by nahradilo kolizní ustanovení tak, aby vystihovalo co nejpřesněji podstatu původního ujednání a aby co nejlépe odpovídalo duchu smlouvy.
10. Poskytovatel je povinen upozornit objednatele písemně na existující či hrozící střet zájmů bezodkladně poté, co střet zájmů vznikne nebo vyjde najevo, pokud poskytovatel i při vynaložení veškeré odborné péče nemohl střet zájmů zjistit před uzavřením této smlouvy.
11. Poskytovatel je podle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, ve znění pozdějších předpisů, osobou povinnou spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou poskytnutého plnění z veřejných výdajů.
12. Tato smlouva je v případě listinného podoby vyhotovena ve 4 vyhotoveních s platností originálu, z nichž obdrží 3 vyhotovení objednatel a 1 vyhotovení poskytovatel.
13. Součástí této smlouvy jsou následující přílohy: Příloha č. 1 – Podrobný popis předmětu plnění.
V Olomouci dne 12.10.2020 V Praze dne 12.10.2020
za ALTAIR SOFTWARE s.r.o. za Českou republiku
Úřad vlády České republiky
Xx. Xxxxx Xxxxx Xxx. Xxxxxxx Xxxxxxxxx
jednatel ředitelka Odboru protidrogové politiky
Příloha č. 1 smlouvy – Podrobný popis předmětu plnění
Podrobný popis předmětu plnění
Popis nabízeného řešení
Programátorské práce – Jednotný informační systém pro adiktologické služby
Sp.zn. zadavatele: 23041/2020 -UVCR-2
Zpracoval
ALTAIR SOFTWARE s. r. o.
Verze 1.0
V Olomouci dne 04. 08. 2020
Stránka 14 (celkem 68)
Předmět nabídky
1.1 Popis nabídky
Předmětem nabídky je návrh na zajištění časově a územně neomezené licence pro dodavatelem vytvořené webové aplikace pro zadavatele a zajištění její implementace (dále také jen „dílo“), dále zajištění správy, podpory a údržby a zajištění rozvoje díla na základě servisní smlouvy.
Implementací se rozumí činnosti, které povedou k funkčnímu zprovoznění díla – instalace, konfigurace, customizace, školení uživatelů, testovací provoz.
Správou, podporou a údržbou díla se rozumí činnosti, které vedou k udržení díla v plně provozuschopném stavu v souladu s platnou legislativou, a s požadavky vývoje technologických a technických komponent.
Nedílnou součástí nabídky je popis technik, metodik a přístupů použitých v analytické fázi přípravy a ve fázi tvorby díla (včetně technik, metodik a postupů programování), popis použitých technologií a technických prostředků, komunikačních protokolů a webových služeb, postupu v implementační fázi (zprovoznění) a výhledy rozvoje díla.
Jako základní zdroje informací ke zpracování nabídky byly použity
• Zadávací dokumentace (ZD) a její přílohy.
• Veřejně přístupné informační zdroje, na které odkazuje zadávací dokumentace včetně příloh.
a. Základní charakteristiky díla a proces dodání díla
• Dodavatel dodá dílo, které se bude skládat z webové aplikace, která bude postavena na míru s využitím XXX.XXX Core, konkrétně MVC Core.
• Aplikace bude optimalizována pro běžně využívané typy prohlížečů jako například Chrome, Safari, Firefox, Edge a Opera.
• Dílo bude dodáno jako cloudová aplikace (případně může být dodáno jako On-premise řešení, pokud to bude zadavatel vyžadovat).
• Součástí předání a zprovoznění díla bude dokumentace potřebná k provozování díla, která bude také zahrnovat uživatelský manuál pro správu části obsahu díla. Dodavatel zároveň poskytne plnou součinnost při akceptačním řízení.
• Webová aplikace bude dostupná výhradně na SSL protokolu, respektive TLS verze
1.2. nebo vyšší. Dodavatel obstará a bude spravovat příslušné certifikáty.
• Řešení umí pracovat s whitelisty a blacklisty URL, které umí řešit přístupy do konkrétních sekcí jen určité skupině uživatelů, anebo naopak zabránit přístupu z daných IP / URL apod. Řešení dodané dodavatelem tak umožní řešit např. „pushing- crowling“ apod.
• Dílo bude zabezpečeno proti neoprávněnému přístupu na úrovni doporučení Open Web Application Security Project (OWASP) v intencích Application Security Verification Standard s důrazem na seznam Top Ten. Aplikace bude zabezpečená proti aktuálně známým útokům, bude splňovat aktuální bezpečnostní standardy.
• Dodavatel bez časového, místního nebo jiného omezení poskytne zadavateli licenci k jím vytvořenému dílu pro všechny způsoby užití, respektive k těm složkám díla, ke kterým je licence potřeba. Případné omezení na dílčí část díla zadavatel
nepředpokládá a jediná situace kdy by k takovémuto omezení dojít mohlo, by byla vyslovená žádost zadavatele na implementaci systému třetí strany, na který je licence třeba. Dodavatel tedy předpokládá poskytnutí časově, místně nebo jakkoliv jinak neomezené licence.
• Dodavatel poskytne zadavateli servisní smlouvu, hotline, zálohování díla, konzultace, další rozvoj díla (tj. realizace požadavků zadavatele na nový vývoj), sledování vývoje použitých platforem a nutné úpravy díla dle aktuálních trendů, reakce na požadavky zadavatele ve stanovených parametrech (SLA), prioritní odstraňování incidentů a chyb, to vše dle SLA uzavřené mezi zadavatelem a dodavatelem.
• Vývoj aplikací ve společnosti ALTAIR SOFTWARE s.r.o. je řízen dle metodiky ITIL3.
• Nová aplikace bude tvořena dle standardu metodiky rozvoje aplikací ITIL, která popisuje komplexním způsobem životní cyklus aplikace od jejího plánování, samotného vzniku i budoucího rozvoje na popud nově vzniklých požadavků. Systém projektového řízení je ve společnosti ALTAIR SOFTWARE řízen dle metodiky PRINCE 2, která zajišťuje kontinuální přehled ve všech fázích projektu od jeho inicializace až po jeho následnou podporu. Projekt bude řízen pod dohledem certifikovaného projektového manažera ze strany dodavatele a přepokládá součinnost klíčových pracovníků zadavatele, kteří budou zodpovědní za definování funkčních a technických požadavků ze strany zákazníka, za proces akceptace předávaného díla a za proces změnového řízení s ohledem k původnímu zadání. Jako kolaborační platforma pro správu dokumentace bude dodavatel využívat systém Microsoft SharePoint, pro řízení jednotlivých etap, správu zdrojových kódů, release a merge management, projektu pak Visual Studio Team Services s GIT úložištěm.
Použité technologie a architektura řešení
Jednotný informační systém bude sloužit primárně k:
1. Evidenci všech procesů spjatých s poskytováním adiktologických služeb jednotlivých poskytovatelů těchto služeb.
2. Vyhodnocování výkonosti a nákladovosti pro potřeby jednotlivých donátorů – poskytovatelů dotací.
3. Exportům dat do dalších agend. donátoři, registry atd.
Informační systém bude vytvořen jako webová databázová aplikace splňující požadavky na zabezpečení práce s citlivými daty. Programátorské práce budou navazovat na stávající informační systém UniData Lite provozovaný RVKPP, z čehož vyplývají i následující požadované technické specifikace. Použité technologie pro vývoj a provoz systému: XXX.XXX (UniData Lite jsou naprogramované na technologii XXX.XXX - Web Forms. Vzhledem k aktuálnímu vývoji v oblasti XXX.XXX bude preferováno řešení na technologii MVC nebo MVC Core). Datová vrstva bude provozována na databázovém serveru MSSQL. Data nebudou ukládána serializovaná z důvodu dalších předpokládaných rozšiřování a nových požadavků na jednotlivé výstupy.
Z důvodu předpokládané velké zátěže aplikace, časté modifikaci dotazů atd. se nedoporučuje použití entity frameworku a je preferovaný spíše přístup XXX.XXX.
Autoři zadávací dokumentace si jsou vědomi velkého rozsahu požadavků. Jelikož je hlavním kritériem pro výběr dodavatele kvalita, jsou některé jednotlivé body zadávací dokumentace označené jako nepovinné. Viz následující Obecné požadavky na funkcionalitu. Tzn dodavatel tyto body nemusí do návrhu zapracovat, ale měl by počítat s tím, že budou později realizovány. Tzn systém musí být rozšiřitelný. Hodnotící kritéria jsou nastavená tak, aby body získané za nepovinné části návrhu, nepřekročili body udělené za kvalitu zpracování návrhu u povinné části, ale jsou samozřejmě bonifikovány.
Součástí návrhu jsou i jednotlivé číselníky. Zadavatel má vyhrazenu možnost číselníky v průběhu prací změnit. (pouze obsahově, nikoliv strukturálně).
Požadovaná součinnost zadavatele
V souladu s metodikou řízení podle dle Prince 2.
V rámci vývoje bude stanoven „Řídící výbor projektu“ (2 osoby ze strany dodavatele a minimálně 2 osoby ze strany zadavatele), který činí zásadní rozhodnutí v rámci projektu (posun projektu v čase, finance, rozsah scope projektu), rozhodnutí o směřování realizace projektu.
Kontaktní osoby v realizačním týmu za dodavatele jsou:
Xxxxx Xxxxx, x.xxxxx@xxxxxxxxxxxxxx.xx,
Xxxxxxxx Xxxxxxxxx, x.xxxxxxxxx@xxxxxxxxxxx.xx.
Tento řídící výbor se bude účastnit meetingů, pravidelně vždy jednou týdně v předem stanovený den v rozsahu až jedné hodiny. Z tohoto meetingu vznikne audia záznam a následně i zápis ve kterém budou uvedeny případně změny, posun ve vývoji, dotazy či připomínky.
Veškerá rozhodnutí řídícího výboru budou dokládána písemnou/elektronickou formou (zápisy, email). Pracovní komunikace v rámci předem stanoveného nástroje.
Dále zhotovitel požaduje součinnost alespoň jedné kompetentní osoby ze strany zadavatele při tvorbě podrobnější analýzy a následném testování projektu i během vývoje v rozsahu 3 pracovních dnů týdne.
Jako komunikační prostředí využíváme dohodnutý nástroj, ke kterým budou mít přístup všichni členové řídícího výboru. Zde budou shromážděny všechny potřebné dokumenty jako například.
• Přehled kontaktů, organizační struktura
• Harmonogram
• Sledování problémů – Issue log
• Přehled úkolů
• Zápisy z jednání Řídícího výboru
• Zápisy o projektu (reporty)
• Podklady pro realizaci analýzy a technického návrhu
• Výstupy z aktivit
Popis základních dodávaných funkcionalit a dalších vlastností díla
Obecné požadavky
Aplikace se bude skládat z několika základních částí.
1. Formuláře pro zadávání dat jednotlivých zařízení (poskytovatelů služeb).
2. Statistické přehledy a výstupy jednotlivých zařízení.
3. Exportní moduly jednotlivých zařízeních do dalších systémů. V první fází se bude jednat o export do zdravotnického registru UZIS – NRLUD.
4. Moduly pro souhrnné statistické přehledy a exporty – sumáře za jedno, ale i více zařízení. Tento modul bude sloužit primárně pro poskytovatele dotačních titulů (donátorů). (nepovinné)
5. Administrátorský modul pro kompletní správu přihlašovacích údajů a uživatelů s přehledy aktivit jednotlivých uživatelů (uživatelské jméno, e-mail, instituce, datum založení účtu, poslední přihlášení, aktivní, neaktivní uživatelů, seznam rolí)
6. Modul pro správu přihlašovacích údajů a uživatelů pro administrátory jednotlivých zařízení s přehledy aktivit jednotlivých uživatelů (uživatelské jméno, jméno a příjmení, datum založení účtu, poslední přihlášení, aktivní, neaktivní uživatel)
7. Datové úložiště (nepovinné)
8. Zálohování dat jednotlivých zařízení (nepovinné)
Návaznost jednotlivých modulů
Data do aplikace budou zadávat jednotliví poskytovatelé služeb. Tj. jednotlivé organizace. Každá organizace bude mít svého administrátora, který bude moci přidávat další uživatele dané organizace. Uživatelům může být také odepřeno přístup, což může učinit administrátor zařízení, případně globální administrátor. Uživatel ale nesmí být smazán!
Od samého začátku bude počítáno s dvouúrovňovým přístupem k organizaci. Každá organizace totiž může mít více programů. Programy jsou jakýmisi provozovnami a vychází z typologie adiktologických služeb. Pro lepší představu je možné použít příměr ze zdravotnictví. Poliklinika (organizace) provozuje několik typů lékařských služeb (program). Třeba stomatologii a pediatrii. Používají však společný informační systém, tj. pacient je v systému zaveden pouze jednou a každý lékař smí spravovat a vidět pouze úkony, které byly provedeny v jeho ordinaci (programu). Ovšem vedoucí lékař může nahlížet do celého obsahu poskytované péče. Specifikum v adiktologických službách může být v tom, že i jednotliví experti (ve zdravotnictví lékaři) se mohou podílet na poskytování služeb ve více programech. Tzn jeden expert může být členem více ordinací.
a. Formuláře pro zadávání dat jednotlivých zařízení (poskytovatelů služeb)
Z hlediska užité technologie bude formuláře, GUI a ovládací prvky stavět dodavatel na webových technologiích s důrazem na mobile-first a dobrou udržitelnost zdrojového kódu (HTML5, CSS3, JavaScript). Dodrženy budou i základy metodiky blindfriendly. Zobrazení frontendu bude optimalizováno pro standartní prohlížeče, jejichž celkové zastoupení mezi uživateli je v součtu alespoň 98% - Google Chrome, Mozilla Firefox, Microsoft EDGE a Safari.
Klientské formuláře tvoří ústřední část celé aplikace. Do těchto formulářů se vkládají veškeré informace o klientech a o práci s nimi. Informace, které by mohly vést k jednoznačné identifikaci klienta, jsou v databázi uložené zašifrované. Bude se jednat o pole – Jméno, Příjemní, Datum narození a pak také zápis dokumentace ve formuláři pro zápis výkonu.
Do této části mají přístup pouze uživatelé s rolemi admin organizace, admin programu a expert.
Klientské formuláře se dělí na různé typy klientů:
• Osoba – jedna fyzická osoba, na kterou jsou vázané výkony.
• Skupina – jeden stejný výkon je poskytnut většímu počtu osob. Osoby jsou zde konkrétně vyjmenovány a výkon se propíše ke každému z nich.
• Anonymní skupina – jeden stejný výkon je poskytnut většímu počtu osob, které nejsou uvedeny konkrétně. Může se například jednat o školní třídu.
• Agregovaný klient – jedná se o výkon, který byl proveden v časovém období několika klientům, které nelze konkrétně uvést. Například nálezy jehel.
Každý klientský formulář bude obsahovat odkaz na kontextovou nápovědu k formuláři. K jednomu formuláři bude vždy vázaná pouze jedna nápověda. Správa obsahu kontextové nápovědy bude tvořit samostatnou agendu pro administrátora aplikace – Super admina -, kde bude možné obsah editovat (online html editor, včetně obrázků a možností vkládání embedovaných videí).
Všechny karty klienta je nutné umět vzájemně propojit za účelem zmíněným v části věnované výkazům.
Do karty klienta se zavádí veškeré informace o klientovi, kterému jsou v zařízení poskytovány výkony. Karta klienta je sice zobrazována v jednotlivých programech, ale ve skutečnosti se nachází na úrovni organizace.
Základem formuláře k osobní kartě klienta jsou přidružené tabulky, které jsou volitelně zobrazitelné.
Tabulky automaticky zobrazené na stejné stránce:
• Základní údaje
• Související tabulky (agendy)
o Tabulka návykové chování
o Socioekonomické údaje
o Tabulka rizikového chování
Tabulky volitelně zobrazitelné, kdy jejich zobrazení bude možné nastavit v administraci programu. Také bude možné nastavit, zda se tabulky budou zobrazovat na stejné stránce nebo samostatně (s výjimkou karty potřeb):
o Hodnocení zdraví
o Anamnéza
o Historie léčby v zařízení
o Zkušenosti s abstinencí, léčbou a institucemi
o Odkazy zařízení
o Karty potřeb (budou vždy zobrazené jako samostatná tabulka.)
Základní údaje
• NRLUD: (povinné ano/ne – zaškrtávací pole) výchozí hodnota se bude řídit globálním nastavením. Respektive, pokud bude v globální volbě programu zvoleno, že program do NRLUD vykazovat nebude, tento volič se na kartě klienta vůbec nebude zobrazovat.
• Výchozí projekt: lokální číselník projektů
• Příjmení
• Kód - textové pole
Jedna z položek „Příjmení“ nebo „Kód“ je povinná. Musí být vyplněná alespoň jedna.
• Jméno klienta: (Povinné pouze pokud vykazuje do NRLUD) Textové pole
U položek „Příjmení“, „Kód“ a „Jméno“ si admin programu může nastavit, které z těchto položek se budou zobrazovat v přehledu klientů. Výchozí nastavení je zobrazovat vše.
• Důvod kontaktu:
• Titul před jménem:
• Titul za jménem:
• Pohlaví: (povinné), číselník pohlaví
• Datum narození: (povinné, pokud vykazuje do NRLUD)
• Země: (povinné) – globální číselník zemí
• Národnost: globální číselník národností
• Obec narození: (Povinné, pokud vykazuje do NRLUD) globální číselník obcí
• Obec trvalého bydliště: (povinné, pokud vykazuje do NRLUD) globální číselník obcí
• Ulice trvalého bydliště:
• PSČ trvalého bydliště:
• Tel:
• E-mail:
• Zaměstnání:
• Intervence při zahájení léčby: (povinné, pokud vykazuje do NRLUD) globální číselník intervencí.
• Poznámky: Pole pro textové poznámky.
• Další osoby a osoby blízké: Uživatelsky definovaný seznam, viz zde, který se naplní výchozími položkami při založení organizace, ale bude jej možné editovat a doplňovat o další položky. Volič ve formuláři bude umožňovat vícečetný výběr z tohoto seznamu max. 10 záznamů. Například matka, partner(ka), kurátor atd. Podstatné je, že každá osoba se bude ve výběru ve výkazu objevovat ve dvou variantách. A to ve variantě – za přítomnosti klienta a bez přítomnosti klienta. Například: Partnerka za přítomnosti klienta / partnerka bez přítomnosti klienta.
Může to být také povinný příznak k další osobě, pokud je vybraná. Podle tohoto příznaku bude pak nutné filtrovat – například zobrazit všechny výkazy, které proběhly bez přítomnosti klienta.
Pokud není definovaná blízká osoba, tuto možnost nezobrazovat. Matka s přítomností klienta / Matka bez přítomností klienta – lze vybrat pouze jednu z těchto možností.
• Spolupracuje: (Ano / ne – povinné) Při založení výchozí stav ano
• Program(y): Program(y), ve kterých je klient aktivní. Viz výše. Při založení automaticky předvolen program, ve kterém byl klient založen. Číselník programů s možností vícečetné volby.
• Stav léčby: Není editovatelné pole, nýbrž jen informace ze samostatné agendy Historie léčby v zařízení. Ta obsahuje krokové záznamy v čase, takže zde bude zobrazena informace o aktuálním stavu. Pokud nebude v agendě nic vyplněné, zobrazí se „Nevyplněno“ – Tato informace může být zobrazena v hlavičce formuláře.
• Doporučení: globální číselník doporučení.
• Přílohy: K této agendě půjdou nahrávat přílohy v libovolném formátu. (soubory musí být v úložišti šifrované. Dešifrují se až v průběhu stažení.)
• Typ vězeňské služby (výchozí): Pokud se jedná o program Adiktologické služby ve vězení, zobrazí se v kartě klienta globální číselník s typem vězeňské služby. Zvolený typ slouží jako výchozí typ při novém zápisu výkonu klienta. Bude to však pouze výchozí zápis, uživatel musí být schopen tento záznam změnit i přímo ve formuláři pro zápis výkonu klienta. Klient totiž může výjimečně čerpat službu z jiného programu, než který má nastavený jako výchozí.
• Garant: číselník expertů (zaměstnanců), nepovinné.
Nového klienta může vytvořit admin programu nebo admin organizace. V případě, že jej vytvoří admin programu, bude klient automaticky přiřazen k programu, ve kterém byl vytvořen. Ostatní programy si tohoto klienta mohou dohledat v samostatné skupině s názvem „Klienti ostatních programů“, kde budou ale dostupné pouze jeho osobní údaje, nikoliv záznamy z výkonů jiného
programu. V případě, že jej bude vytvářet admin organizace, musí klienta přiřadit k programu, které spadají do jeho organizace.
Klient může být v rámci jedné organizace přiřazen k několika programům najednou. K tomuto formuláři je možné nahrávat přílohy (docx, xlsx, PDF, jpg, png...).
Z karty klienta půjde vyexportovat tisková sestava se všemi vyplněnými hodnotami, a to včetně souvisejících formulářů.
U formuláře budou dostupné informace o uživateli, který klienta vytvořil a budou zde informace o posledních třech editacích (jméno uživatele, datum a čas editace). Nebudou k dispozici informace o tom, co uživatel editovat.
Pole, která budou povinná budou zvýrazněná. To samé platí pro povinná pole pro vykazování do NRLUD (národní registr léčby uživatelů drog), která budou zvýrazněná jinou barvou. Označování povinných polí pro NRLUD je také závislé na tom, zdali daný program bude do NRLUD vykazovat, což je informace, která bude nastavitelná v nastavení daného programu. Vykazovat do NRLUD – ano / ne.
Formuláře z této agendy (všechny a každý samostatně) ponesou informaci o uživateli, který ho založil a posledních tří uživatelích, kteří provedli úpravy. (vždy uživatel plus datum a čas editace) Tyto údaje budou na každém formuláři viditelné.
Tabulka návykového chování
Tento formulář je zásadní pro rozlišení typu klienta, které se používá ve výstupech. Toto rozlišení se týká klientů, kteří vstupují do statistik a dělí se na dvě základní skupiny. Tzv. klienty se závislostním / návykovým chováním a klienty bez závislostního / návykového chování. Tyto dvě skupiny se od sebe liší právě tím, jestli mají, nebo nemají, vyplněný formulář návykového chování.
Formulář obsahuje následující položky:
• Věk prvního užití: Textové pole – číslo
• Věk prvního injekčního užití: (povinné, pokud vykazuje do NRLUD). Zároveň je povinné, pokud je níže ve specifikacích uvedeno, že aplikuje injekčně. Textové pole – číslo
Tento formulář dále obsahuje dvě záložky. Jedna záložka slouží na zadání bližších specifikací o návykovém chování, kde je možné zadat i více záznamů a v druhé záložce se shromažďují závislosti, které klient měl, ale již skončili, je to takzvaná kariéra klienta. Jeden řádek značí vždy jeden záznam / jednu závislost. Řádky jsou řazené v následujícím pořadí: První je vždy záznam označený jako primární (primární závislost) a následně od nejnovějšího po nejstarší (pole data zápisu).
4.3.1. Aktuální specifikace návykového chování
Víceřádkový záznam, kde každý řádek záznamu je jedna závislost a obsahuje následující údaje položky:
• Datum zápisu: (povinné) Pole s kalendářem
• Látka / návykové chování: (povinné) – číselník Návykové chování. Pokud je závislostní chování typu patologické hráčství, je možné ještě zapsat typ gamblingu.
Ten vychází z číselníku patologického hráčství a zobrazí se po vybrání tohoto typu chování a umožňuje vícenásobný výběr hodnot.
• Aplikace: (povinné) – číselník Aplikace
• Způsob prvního užití: (povinné) – číselník Aplikace
V případě, že je užití injekční, je nutné vyplnit „Věk prvního injekčního užití“, viz výše.
• Četnost: (povinné) – číselník četnosti
• Věk první užití:
• Věk zahájení pravidelného užívání: (povinné, pokud NRLUD)
• Primární: ano / ne, výchozí ne. Podmíněné chování, viz. dále. Jedna ze závislostí musí být vždy primární.
• Polydrug: ano / ne, výchozí ne
• Konec platnosti: Pole s kalendářem
Tento formulář má několik typů podmínečného chování.
1. Pokud je v poli „Konec platnosti“ vyplněné datum, záznam z tohoto formuláře zmizí a přesune se do samostatné karty „Návyková kariéra klienta“. Ten je pouze přehledový, ale je možné v něm záznam vymazat, nebo smazat obsah pole Konec platnosti (tím se záznam vrátí do přechozího formuláře.
2. Pole primární: Jeden aktivní záznam, tj. záznam, ve kterém není vyplněný žádný datum v poli „Konec platnosti“, musí mít označení Primární = ano. Není možné označit jako primární více aktivních záznamů.
Součástí této specifikace je také formulář na zadání substituční léčby. Jeden řádek je vždycky jedna léčba. Řádky jsou řazené od aktivních (ty které již nejsou aktivní tak se řadí dle data ukončení od nejnovějšího po nejstarší). Nikdy by nemělo být aktivních více řádků. Ten formulář obsahuje následující položky:
• Datum zahájení: (povinné)
• Substituce: (povinné) – číselník Návykové chování
• Datum ukončení: Pole s kalendářem
4.3.2. Návyková karta klienta
Na této kartě budou k dispozici všechny záznamy návykového chování klienta, které již skončili, to znamená, že v poli „Konec platnosti“ mají vyplněný datum ukončení.
Budou se řadit od nejnovějšího po nejstarší a u záznamů bude možné editovat pouze konec platnosti, pomoci kterého je možné záznam vrátit zpět do seznamu aktivního návykového chování.
Socio-ekonomické údaje
Poskytuje podrobnější informace o socio-ekonomických údajů o klientovi a obsahuje následující položky:
• Rodinný stav: Číselník stavů
• Má děti?: Volič s jednou možnosti (radiobutton nebo dropdownlist) – Ano, ne, neznámo – výchozí natavení neznámo
• Žije s dětmi?: - stejné jako má děti
• Bydlení s kým: Číselník Bydlení s kým
• Bydlení charakter: (povinné pokud NRLUD) Číselník Bydlení charakter
• Bydlení s uživatelem: Ano, ne, neznámo
• Zaměstnání: Číselník zaměstnání
• Vzdělání: Číselník vzdělání
Tabulka rizikového chování
Tento formulář obsahuje vícečetné záznamy. Jednotlivé řádky obsahují tato pole.
• Datum: (povinné) – kalendář
• Rizikové chování: (povinné) obsahuje několik parametrů, ze kterých je nutné jeden vybrat:
o Injekční aplikace
o Sdílení jehel
o Sdílení náčiní
o Riziková aplikace
o Předávkování
o Nechráněný sex
o Zdravotní komplikace
• Četnost: (povinné) Číselník četnosti
Tyto tři výše uvedené tabulky „Tabulka návykového chování“, „Socio-ekonomické údaje“, a „Tabulka rizikového chování“ tvoří tzv. „Incomové tabulky“. Tyto tabulky nesmí obsahovat údaje starší než dva roky.
Je to tedy jedna ze základních validací před tvorbou výstupu. Údaje, které jsou starší než dva roky, do výstupů nevstupují a uživatel musí být na tuto skutečnost upozorněn. Tj. vždy musí existovat nějaká souhrnná sestava, která uživateli ukáže, která data do sestavy nevstoupila a proč.
Zároveň v agendě „Výstupy“, musí existovat souhrnná přehledná tabulka, jejíž základní filtr bude datum návštěvy klienta v zařízení od – do (datum návštěvy = poskytnutá služba, tj. vyplněný výkaz, viz dále), která ukáže u každého klienta datum poslední úpravy v každé z těchto tří tabulek. Pokud bude datum starší než dva roky, musí být nějak výrazně označen.
Hodnocení zdraví
Tento formulář obsahuje data, která jsou povinná, pokud je nastaveno vykazování do NRLUD. Odpovídá na šest otázek týkajících se situace klienta v oblastech.
1. Psychické zdraví (úzkost, deprese a obtíže s emocemi a city)
2. Fyzické zdraví (závažnost zdravotních obtíží a obavy z nemoci)
3. Sociální fungování (finance, zaměstnání, škola, problémy se zákonem, s úřady)
4. Vztahy k blízkým (bydlení, vztahy s dětmi, rodiči, příbuznými)
5. Konflikt se zákonem
6. Kvalita života
Každá odpověď na otázku se vybírá z číselníků Hodnocení zdraví. Tento číselník obsahuje položku 0 – neznámo, která slouží jako výchozí. Formulář se těmito výchozími položkami předvyplní automaticky při založení karty klienta.
Anamnéza
Tento formulář obsahuje dvě oblasti. Zdravotní anamnéza a anamnéza trestné činnosti. Zobrazování těchto záložek se nastavuje v globálním nastavení programu zvlášť. Tj. zvolí-li si uživatel, že nechce zobrazovat ani zdravotní, ani trestnou anamnézu, nezobrazí se odkaz v menu na formulář Xxxxxxxx vůbec. Vybere-li si pouze jednu z těchto možností, zobrazí se mu odkaz na formulář Xxxxxxxx, ale uvnitř pouze jeden z vybraných podformulářů. Pokud nechá zvolené oba, odkaz bude stále jeden, na formulář Xxxxxxxx, ale uvnitř se zobrazí obě v pořadí. 1. Zdravotní anamnéza 2. Anamnéza trestné činnosti.
4.3.3. Zdravotní anamnéza
• Diagnóza: Číselník diagnózy – možnost zvolit více položek
• Testy HIV, VHA, VHB a VHC: (povinné, pokud vykazuje do NRLUD) Každá z uvedených možností obsahuje tři kritéria. Datum, Selfreport s možností ano / ne a výběr z Číselníku testování infekčních nemocí
• Vyšetření infekčních nemocí: vícečetný záznam, všechny položky jsou povinné:
o Vyšetření infekčních nemocí: Číselník Vyšetření infekčních nemocí
o Výsledek: číselník výsledků vyšetření
o Datum vyšetření: pole s kalendářem
4.3.4. Anamnéza trestné činnosti
• Prvovězněný: číselník Obecné možnosti
• Věk první trestné činnosti: pole pro číslo věku
• Věk prvního výkonu tresu v: pole pro číslo věku
• Počet pobytů ve výkonu trestu: pole pro číslo
• Probíhá aktuální trestní řízení? číselník Obecné možnosti
• Bylo v minulosti porušeno podmíněné propuštění: číselník Obecné možnosti
• Délka současného trestu a kdy nastoupil: pole pro číslo a druhé pro datum (kalendář)
• Typ trestné činnosti: číselní trestních činností
• Spolupráce s PMS: číselník Obecné možnosti
• Nařízení ochranná léčba: Číselník nařízené ochranné léčby: Možnosti ambulantní ano / ne, ústavní ano / ne
• V jakém je typu věznice: číselník typů věznic (s ostrahou, se zvýšenou ostrahou)
• Jaký je stupeň zabezpečení: číselník typů zabezpečení (s nízkým stupněm zabezpečení, se středním stupněm zabezpečení, s vysokým stupněm zabezpečení)
Historie léčby v zařízení
Tento formulář obsahuje víceřádkové záznamy, který obsahuje následující informace.
• Zahájení – ukončení: Číselník o dvou položkách – Zahájení / ukončení. Povinné pole.
• Důvod ukončení. Povinné, pokud vykazuje do NRLUD a pokud je předchozí záznam zvolen jako Ukončení.
• Datum: Povinné pole
• Byla léčba úspěšná? Zaškrtávací pole ano / ne. Hodnota musí být vybrána, ale pouze v případě, že se jedná o ukončení.
Zkušenosti s abstinencí, léčbou a institucemi
Tento formulář obsahuje vícečetné záznamy, které obsahují následující informace.
• Typ léčby / instituce / abstinence: číselník zkušenosti s léčbou (povinné pole, pokud NRLUD)
• Počátek abstinence / léčby / pobytu v instituci: Pole s datem – kalendář
• Datum ukončení: Pole s datem – kalendář
• Důvod ukončení léčby / pobytu v instituci: číselník ukončení léčby
• Poznámka: Textové pole typu nVarchar(MAX) pro poznámku
• Instituce: Číselník institucí (lokální uživatelský číselník)
Odkazy do zařízení
Tento formulář obsahuje vícečetné záznamy, které obsahují následující informace.
• Datum: pole s datem, kalendář – povinné
• Odkaz: číselník odkazů
Karty potřeb
Tento formulář obsahuje vícečetné záznamy, které obsahují následující informace.
• Vznik potřeby: Pole s datem, kalendář – povinné pole
• Ukončení: Pole s datem, kalendář.
• Splněno: zaškrtávací pole ano / ne
• Potřeba: Povinné pole, číselník potřeb
Pole výše jsou viditelná v seznamu potřeb, kterých může být více. Po rozkliknutí podrobnosti potřeby přibydou další pole:
• Do kdy má být splněno: Pole s datem – kalendář
• Definovaný cíl: Pole typu nVarchar(MAX) pro delší textový zápis
• Jak poznám, že jsem toho dostáhla / dostáhl: Pole typu nVarchar(MAX) pro delší textový zápis
• Na co je třeba si dát pozor: Pole typu nVarchar(MAX) pro delší textový zápis
• Co udělám, když riziko nastane. Pole typu nVarchar(MAX) pro delší textový zápis Z karty potřeb klienta se tiskne tisková sestava Karta potřeb klienta.
Vykazování do NRLUD
Tento formulář je ve skutečnosti sdruženým formulářem, který nezahrnuje žádné nové položky, ale shrnuje položky z formulářů – „Karta klienta – osoba“ a jeho souvisejících formulářů (Soc. eko. Údaje, návykové chování a další).
Samotný formulář se bude zobrazovat / nezobrazovat na základě volby v nastavení programu
– „Vykazovat do NRLUD ano / ne“.
Položky, které se budou zobrazovat v tomto formuláři, budou vycházet z položek, které jsou povinné pro vykazování do NRLUD (tzv. minimální hlášení) a také z dalších položek, které se mohou, ale nemusí, do NRLUD vykazovat. Tzv. rozšířené hlášení do NRLUD.
Tato karta je nutná proto, aby měl uživatel jednoduchou možnost editovat a kontrolovat položky, které jsou jinak skryté v návazných agendách. Tzn., aby měl v jednom pohledu přehled o položkách, které jsou jinak součástí více různých formulářů.
Tento formulář bude také kontrolovat a validovat povinné položky, které jsou pro vykazování do NRLUD nutné a bude umožňovat záznam do registru přímo vyexportovat. Opět nejprve proběhne validace, dle dokumentace rozhraní pro import dávek NRLUD / UZIS . Samotný export je realizován zápisem do xml souboru. Jeho struktura je jasně zdokumentovaná. Tento soubor se pak přes webové rozhraní aplikace NRLUD importuje do registru.
Mimo možnost exportovat do registru jednotlivé záznamy, bude aplikace také disponovat hromadným exportem záznamů klientů, kteří mají být do NRLUD exportováni.
Karta klienta – skupina (seskupení osob)
Pole formuláře
1. Název skupiny – povinné textové pole
2. Výchozí projekt – číselník projektů
3. Datum založení skupiny – pole datum čas – kalendář, povinné pole
4. Datum zápisu – automatické pole datum čas. Jen pro čtení
5. Založil – jméno osoby, která skupinu založila. Automatické pole, jen pro čtení
6. Garant skupiny – výběrové pole aktivních pracovníků
7. Ukončena – pole ano / ne, výchozí hodnota ne
8. Osoby ve skupině – seznam osob ve skupině, tj. vícečetná výběrová pole s klienty Pole pro přidávání osob musí fungovat tak, že při zadávání klientů jsou ve výběrech zobrazování pouze klienti (osoby) ve spolupráci. Nicméně pokud je tato osoba v průběhu péče označena jako nespolupracující, musí být stále v seskupení viditelná, ale již nepůjde zobrazit
v kroku, ve kterém se zadává výkon. Tato informace se nachází v tabulce „Základní údaje“ o osobě.
K formuláři seskupení osob bude možné nahrávat přílohy.
Karta klienta – anonymní skupina (třída)
Jedná se o formulář pro speciální typ klienta. Tento klient nepředstavuje žádnou konkrétní osobu, ani seskupení konkrétních osob, nýbrž skupinu, která je definována pouze svým názvem a počtem lidí ve skupině (počet se skládá ze dvou částí, a to z počtu žen a mužů).
Typickým příkladem takovéto skupiny je školní třída. Tato anonymní skupina je dvojího typu. Vybraný typ pak určuje názvy některých polí – mohou se lišit – a také další proměnné, které se v závislosti na typu skupiny objeví. Dva základní typy anonymní skupiny jsou:
1) Obecná skupina
2) Třída, která se následně dělí na:
a. Základní škola
b. Střední škola
c. Vysoká škola
Názvy polí, která jsou ovlivněna výběrem skupiny.
Obecná skupina | Třída |
Počet mužů | Počet studentů |
Počet žen | Počet studentek |
Nadřízená instituce | Škola |
Nemá ekvivalent | Aktuální ročník |
Nemá ekvivalent | Školní rok |
Pokud je vybrán typ třída (jeden ze tří typů škol), název klienta je pak všude – Třída. Pole formuláře
1. Typ skupiny – výběr z typů (obecná skupiny / třída), povinné
2. Výchozí projekt – lokální číselník projektů
3. Název skupiny / třídy – povinné textové pole
4. Počet mužů / studentů – celé číslo, povinné
5. Počet žen / studentek – celé číslo, povinné
6. Aktuální ročník – číslo – povinné, pokud je v typu skupiny zvolena třída
7. Preferovaný typ pp (primární prevence) – povinné, pokud je zvolena třída, výběr z číselníku typů primární prevence
8. Školní rok – výběr z číselníku školních let, povinné, pokud třída a je ve spolupráci – viz. níže
9. Datum kontaktu – pole datum a čas – kalendář, povinné pole
10. Datum zápisu – automatické pole datum a čas. Jen pro čtení
11. Založil – automatické pole, jen pro čtení
12. Kontaktní osoba – textové pole
13. Telefon – textové pole
14. E-mail – textové pole
15. Poznámka – textové pole typu nVarchar(MAX)
16. Primární cílová skupina – ano / ne, povinné při založení ano
17. Spolupracuje – ano / ne – povinné, při založení ano
18. Nadřízená instituce / škola – výběr z číselníků institucí. Pokud třída tak povinné (každá třída musí být svázána se školou)
19. Typy rizikového chování – číselník rizikového chování primární prevence – možnost vícenásobného výběru. Zobrazí se pouze v případě programu primární prevence.
Anonymní skupina typu třída má specifické chování v rámci roku. Smlouvy se kontraktují maximálně na školní rok. Po ukončení školního roku se tedy smlouva automaticky ukončuje. Z tohoto důvodu se každý rok třídy zavádí znovu. Aby byla zaručena kontinuita záznamů, probíhá následující proces.
Po ukončení školního roku tj. 31.8. anebo dříve pomocí aktivní volby uživatele – administrátora programu – dojde k tzv. přerušení spolupráce. Což znamená, že se příznak v poli
„Spolupracuje“ změní na hodnotu Ne.
Zároveň dojde k vymazání některých záznamů, ale ty musí zůstat uložené v historii, aby bylo možné sledovat třídu v čase. Jedná se o záznamy.
1. Aktuální ročník
2. Aktuální školní rok
3. Počet studentů ve třídě
Uživatel pak na začátku každého roku patřičnou třídu, se kterou podepíší kontrakt, otevře a zaškrtne, že je třída znovu ve spolupráci. Tím se stanou pole aktuální ročník a aktuální školní rok povinné a je nutné je aktualizovat. Ve formuláři třídy musí být vždy vidět záznam pouze pro čtení, který informuje o tom, v jakých školních letech a v jakých ročnících už bylo v předchozích letech se třídou spolupracováno.
Výše uvedené chování se týká pouze tříd. Pokud se jedná o anonymní obecnou skupinu, tento automatický režim se neaplikuje.
K této kartě bude možné nahrávat přílohy.
Karta klienta – agregovaný klient
Speciální typ klienta, který je specifikován svým jedinečným názvem a nelze ho přesněji identifikovat.
Pole formuláře
1. Název klienta – textové pole, povinné
2. Aktivní – volič ano / ne při založení automaticky nastaven na ano.
3. Výchozí projekt – lokální číselník projektů
4. Založil – automatické pole jen pro čtení
5. Datum založení – automatické pole jen pro čtení
6. Poznámka – textové pole pro krátkou poznámku
Formuláře pro výpočet počtu klientů v zařízeních s výhradně agregovaným zadáváním
Toto je speciální agenda pouze pro vybraný typ zařízení. To, jestli může tuto agendu zařízení používat určuje pouze super admin. Při povolení zařízení bude proto existovat volič záznamů. Zařízení s výhradně agregovaným zadáváním, který bude ve výchozím stavu nastaven na false. Pokud super admin tento volič nastaví na true, bude moci zařízení tuto agendu používat.
Tato agenda umožní nastavit tzv. aktivní rok a do tohoto roku přidávat jednotlivé klienty. Jelikož tato zařízení nepracují s klienty v rámci výkonů – tzn. nezapisují konkrétním klientům konkrétní služby, ale záznam o provedených službách vedou tzv. agregovaně (zadáním počtu dané služby) není možné vypočítat počty klientů přímo z výkazů, ale tyto počty se budou počítat právě z této agendy. Jmenný seznam klientů umožní ke každému klientovi přidat vybraný rok s datem zápisu. Toto bude možné provádět opakovaně v každém roce. Tzn. jeden klient u sebe bude moci mít více aktivních let. Formuláře pro záznam výkonu
Ke všem typům klientů (osoba, skupina osob, anonymní skupina / třída, agregovaný klient) je možné zadat záznam o provedeném výkonu. Klient NRLUD není v tomto slova smyslu pokládán za klienta, jedná se pouze o jiný pohled na Klienta typu osoba.
Existuje ještě speciální typ výkonu (ve skutečnosti se nejedná o výkon, takže je lépe se bavit o záznamu, nebo úkonu) – Nálezy a sekundární výměna. Nevztahují se na něj následující požadavky a je obhospodařován samostatnou agendou.
Volba, komu má být, nebo byl, záznam o provedeném výkonu zaznamenán, se provádí ze seznamu klientů ve výchozím formuláři aplikace.
Podle typu klienta se otevře patřičný formulář o záznamu výkonu. Výchozí hodnoty záznamů mohou vycházet buď z globálních předvoleb, nebo z lokálních předvoleb, které se budou uskutečňovat ve výchozím formuláři aplikace. Tam se bude jednat o předvolby pracovníků u výkonu, datu a místa výkonu – viz dále. Tyto lokální předvolby slouží pouze přihlášenému uživateli, a to z důvodu zpětného hromadného vyplňování výkazů, kde by pokaždé musel některé volby ve formuláři opakovat.
Propojování výkazů
Výkazy – respektive klienty – je nutné spolu propojovat. Tzn, musí být vytvořena možnost, jak říct, že výkazy jednoho klienta jsou propojené s výkazem jiného klienta. A to u všech typů klientů a s možností vícenásobného propojení. Toto propojování slouží k tisku dokumentace, kdy je žádoucí v rámci jedné dokumentace o poskytnutých výkonech vidět dohromady například dokumentaci k rodině a následně i k jejím jednotlivým členům, které jsou ještě v péči individuálně. Týká se tedy přehledů o výkonech klienta, a to i v tiskové sestavě. Při zobrazení přehledu o výkonech a tisku, bude pracovník (v případě že existuje nějaké propojení mezi daným výkazem) dotázán, zdali chce zobrazit i výkazy propojených klientů. Tato spojení nemají žádný vliv na statistiky a slouží pouze k naplnění účelu zmíněného výše. Nastavení propojení bude realizováno v agendě karet klientů. Přehled i tisková sestava bude řazena chronologicky – tedy nikoliv podle jednotlivých klientů, kteří jsou propojení. Musí však být z každého řádku jasné, jakému konkrétnímu klientovi patří.
Výkon pro klienta typu osoba
1. Název / jméno klienta – pouze pro čtení, automaticky zobrazené jméno klienta ve formuláři (v databázi samozřejmě stačí pouze ID klienta)
2. Místo výkonu – výběr z číselníků míst. Výchozí hodnota je načtena z číselníku míst anebo z lokálních předvoleb, viz výše.
3. Projekt: povinné, výběrové pole z číselníku projektů. Výchozí hodnota, se řídí následujícím pravidlem. Pokud má klient v kartě klienta vyplněnou hodnotu – Výchozí projekt, zobrazí se tento. Pokud ne, zobrazí se Výchozí projekt nastavení v globální předvolbě programu. Viz číselníky
4. Založil – automatické pole jen pro čtení
5. Datum založení – automatické pole jen pro čtení
6. Datum výkonu – povinné pole datum, kalendář. Výchozí hodnota může být načtena z lokálních předvoleb, viz výše. Anebo obsahuje aktuální datum.
7. Způsob poskytnutí – číselník s hodnotami – face to face (výchozí hodnota), on-line, telefon, korespondenčně. Povinné pole předvyplněné výchozí hodnotou. Ta je možná v nastavení programu měnit. V budoucnu se mohou objevit zařízení, které budou mít primární hodnotu nastavenou všude na on-line. Toto nastavení proto bude u každého výkonu zvlášť.
8. Klient přítomen – povinné pole ano / ne. Výchozí hodnota ano
9. Dokumentace – textové pole typu nVarchar(MAX) umožňující formátovaný text. Zobrazení tohoto pole je nastavit v globálním nastavení aplikace.
10. Výkony – seznam všech výkonů, které jsou v administraci nastavení aplikace nastavené na zobrazovat ano. Vedle každého výkonu předvyplněné pole s časovou dotací zařízení. Viz. číselníky výkonů. Toto pole je editovatelné. Vedle každého výkonu pak zaškrtávací tlačítko ano / ne, s výchozí hodnotou ne. Viz dále část Záznam a validace při ukládání výkonu do databáze.
11. Pracovníci u výkonu – vícenásobné výběrové pole s pracovníky. První záznam je automaticky předvyplněný pracovníkem, který záznam zapisuje, nebo předvolenými uživateli z lokálních předvoleb. Minimálně jeden pracovník musí být vybrán.
12. Specifikace výkonů (dříve Podrobnosti výkonů) – viz číselník podrobnosti výkonů. Podformulář s volbami zápisu dané podrobnosti výkonů se zobrazí po kliknutí na daný výkon. (v samostatném popup okně, nebo rozevřením podrobnosti – závisí na návrhu) Jedinou výjimku tvoří podrobnost výkonu Distribuce HR materiálu. Pokud bude tento výkon navolen jako výkon, který se má zobrazovat, bude se tento podformulář zobrazovat přímo ve formuláři k zápisu, aby ho uživatel nemusel vždy rozklikávat.
13. Osoby blízké. Výběr ze seznamu blízkých osob, který se zadává v kartě klienta. Například matka, partner(ka), kurátor atd. Podstatné je, že každá osoba se bude ve výběru ve výkazu objevovat ve dvou variantách. A to ve variantě – za přítomnosti klienta a bez přítomnosti klienta. Může to být také povinný příznak k další osobě, pokud je vybraná. Podle tohoto příznaku bude pak nutné filtrovat – například zobrazit všechny výkazy, které proběhly bez přítomnosti klienta.
14. Typ služby ve vězení. V případě programu – Adiktologické služby ve vězení – číselník Typy služeb ve vězení – povinné. Výchozí hodnota vstupuje z karty klienta.
15. Typ primární prevence – v případě programu – Primární prevence – číselní typů primární prevence. Výchozí hodnota vstupuje z karty třídy.
Záznam a validace výkonu při ukládání do databáze.
Před uložením výkonu musí být provedena validace zadaných hodnot. Nejedná se však pouze o povinné položky, ale existují zde ještě dynamicky podmíněná pravidla.
Ukládají se pouze výkony, které jsou zaškrtnuté. U nich je vždy potřeba, aby byl vyplněný záznam o čase. Ten také musí být ve správném formátu. Pro uživatele se jako nejvýhodnější ukazuje formát hh:mm. Do databáze pak může být uložený v minutách. Podoba prezentační vrstvy pro zápis je zobrazená na obrázku níže. V zobrazeném případě se tedy uloží výkony – kontaktní práce v délce 60 minut a výkon Základní zdravotní ošetření v té samé délce.
Tyto výkony doporučujeme ukládat pomocí kvantitativní hodnoty. Tj. Kontaktní práce = 1 (výkon). A to z toho důvodu, že při agregovaném zápisu, viz dále, se počet daných výkonů skutečně ukládá kvantitativně. Zápis má pak třeba podobu – Kontaktní práce = 14 (výkonů).
Pokud jsou u výkony zvoleny i specifikace výkonu, je nutné je samozřejmě uložit také. Aplikace však nesmí uložit záznamy, u kterých by byly vyplněné podrobnosti, ale nebyl zaškrtnut samotný hlavní výkon.
Specifikace výkonů nejsou v naprosté většině povinné. Výjimku tvoří například výkon Distribuce harm-reduction materiálu. Jak již bylo řečeno výše, podformulář s podrobnostmi tohoto výkonu se zobrazuje přímo ve formuláři pro zápis výkonů (pokud je zobrazen i hlavní výkon). Pokud je Výkon distribuce HR materiálu zaškrtnut, je povinné vyplnit alespoň jednu hodnotu do podrobností tohoto výkonu. U podrobností tohoto výkonu se vždy jedná o záznam typu: Název materiálu – kvantitativní hodnota. Zde je opět změna funkcionality – viz podagendy výkonů!
Podobným výkonem pak může být třeba výkon – Testování /Testování infekčních nemocí. U tohoto výkonu se zase povinně zadávají výsledky testů.
Výkon pro klienta typu agregovaný klient
Záznam výkonu pro agregovaného klienta vypadá prakticky totožně, jen se výkony neobjevují s možností zaškrtnutí, ale je u nich možnost vyplnit kvantitativní údaj.
Oproti zadání výkonu pro klienta typu osoba nejsou přítomné údaje:
• Klient přítomen
• Další osoby
Naopak v hlavičce formuláře před údaji o místě a projektu přibydou následující údaje:
• Kontakty: dvě pole pro číslo. Celkem a Z toho žen. Pole celkem je povinné
• První kontakt z celku (z toho první kontakty): číslo
• Cizinci z celku (z toho cizinci): číslo
• Odmítnutí z důvodu kapacity: číslo
• Odmítnutí z důvodu cílové skupiny: číslo Vše ostatní zůstává stejné, až na jednu specialitu.
Součástí formuláře pro zadání výkonů agregovanému klientovi bude i podformulář agendy Nálezy a sekundární výměna. Položky tohoto podformuláře se ve skutečnosti neváží s výkazem, ale zapisují se do samostatné agendy – viz níže. Podformulář je zde pouze proto,
že zápis agregovaného výkazu probíhá velmi často pohromadě právě se zápisem Nálezů a sekundární výměny, a tak je pohodlnější údaje zapsat najednou.
Samostatná agenda obsahující následující údaje.
• Datum: povinné pole s datem. Kalendář. (pokud je do agendy zapsáno z formuláře zápisu výkonu pro agregovaného klienta – dále jen „agreg“ – tak sem vstupuje datum zápisu z agreg.
• Projekt: výběr z číselníku. pokud agreg, tak projekt z agreg
• Místo: výběr z číselníku. pokud agreg, tak místo z agreg
• Jehly In: číslo
• Jehly Out: číslo
• Nálezy: číslo
• Osoby: číslo
• Rozsah terénní práce: čas: hh:mm
• Poznámka. Textové pole typu nVarchar(MAX)
Uložení záznamu. Automaticky se ukládá, kdo formulář zapsal a kdy, a zároveň se před uložením kontroluje, zdali součet vyplněných hodnot v polích Jehly In, Jehly Out a Nálezy je větší než nula. Alespoň jedno z těchto polí musí mít hodnotu větší než nula.
Agenda samotná je ve výchozím zobrazení zobrazená jako seznam nálezů a sekundární výměny.
Výkon pro klienta typu skupina osob
Zápis pro tento typ klienta se skládá ze dvou kroků.
Pokud uživatel ve výchozím formuláři vyber klienta tohoto typu a zvolí možnost – Zapsat výkon, objeví se mu nejprve seznam všech osob, které do skupiny patří. Tento meziformulář se bude jmenovat – Klienti přítomní na skupině.
Vedle každého klienta bude checkbox, který bude ve výchozím nastavení zaškrtnutý. Bude obsahovat možnost hromadného odškrtnutí (skupiny mohou být větší a někdy je jednodušší spíše označovat pozitivně, než negativně)
V tomto formuláři tedy uživatel určí, jakým klientům ze skupiny se ve skutečnosti zápis provede. Pak uživatel zvolí tlačítkem druhý krok. Tlačítko se bude jmenovat: Zápis výkonu.
Tento zápis bude mít úplně stejnou podobu jako formulář pro zápis výkonu typu osoba. Lišit se budou pouze ve dvou kritériích.
1. Nebude možnost přidat další osoby
2. Ukládání dat bude realizováno úplně jinou logikou. Ta bude dvojí podle toho, jaká bude voličem typu radio button, zvolena možnost.
a. Skupinový výkon (bude vybráno ve výchozím nastavení)
b. Hromadný zápis výkonu
Pokud by se podařilo navrhnout prezentační vrstvu této agendy tak, aby zároveň zobrazovala formulář s klienty ve skupině a zároveň formulář pro zápis výkonů, není nutné realizovat zápis ve dvou oddělených krocích.
Uložení záznamu pro skupinový výkon
Zápis v obou případech funguje tak, že se ve skutečnosti výkazy rozkopírují ke všem vybraným členům skupiny. V případě a) je ale nutné, aby se ke každému výkazu doplnil příznak ID skupiny, a i ID konkrétního zápisu. Tzn. výkazy lze pak seskupovat jak podle vybrané skupiny, tak podle vybraného zápisu. Originál zápisu se uloží separátně do zvláštní tabulky, aby ho bylo možné dohledat. V tomto případě jde o to, že jednotlivé výkazy je možné následně normálně
samostatně editovat. Tzn. dopisovat třeba podrobnosti k dokumentaci atd. Takže je nutné, aby někde existoval originál záznamu. To, že jsou výkazy spojené, má pak vliv i na některé výpočty v agendě výstupů.
Uložení záznamu pro hromadný zápis výkon
V tomto případě se výkazy pouze rozkopírují všem vybraným členům skupiny. Zpětně již pak hromadně editovat nejdou a neukládá se originální záznam a ani žádný příznak toho, že byli výkony vyplněné hromadně (ID skupiny a ID konkrétního zápisu).
Výkon pro klienta typu anonymní skupina / třída
Formulář pro zadávání výkonů je úplně stejný jako v případě formuláře zadávání výkonu pro klienta typu osoba.
Jediný rozdíl tvoří dvě, v případě třídy tři, pole navíc. Počet mužů /žáků a počet žen / žákyň. Do těchto polí je po otevření formuláře načtena hodnota z karty klienta. Uživatel jí ale může upravit. Karta klienta v sobě drží údaj o počtu klientů ve skupině, ale u samotného výkonu nemusí být všichni.
V případě třídy je zde ještě pole – typ prevence. Do tohoto pole vstupuje výchozí typ prevence nastavený v kartě třídy a je možné jej změnit.
Posledním rozdílem je ještě název skupiny / třídy, namísto pole příjmení. V datové struktuře je toto pole však stejné, jen se jinak jmenuje ve formuláři. Pole jméno pak chybí.
Formuláře pro záznam denní agendy – žurnál
V této agendě vedou pracovníci provozní zápisy k jednotlivým dnům a událostem. Jde
o agendu, která je spjatá s každodenním provozem zařízení. Je primárně přístupná všem pracovníkům daného programu, ale je možné jednotlivé zápisy vidět a editovat i na úrovni zařízení, pokud tak pracovník povolí parametrem, který toto dovoluje. Tzn zápis si s sebou nese příznak, který říká, jestli je zápis přístupný pouze uvnitř programu, nebo v celém zařízení. Dále se ukládá datum (to je možné editovat), automatické a needitovatelné záznamy: datum a čas založení, jméno pracovníka, který záznam založil a jméno, datum a čas všech, kdo záznam editovali.
Zápis je možné opatřit pěti volitelnými štítky. Ty se nastavují v globálním nastavení. Podle nich je pak možné zápisy filtrovat. Štítky jsou příznaky – například: důležité, problém atd.
Základem zápisu je strukturovaný text s možností vložení přílohy.
Seznamy
Seznamy jsou formuláře s tabulkovými výčty libovolných záznamů. (klientů, výkonů atd.)
Hlavním seznamem je výchozí formulář aplikace, který zobrazuje aktivní klienty (klienty ve spolupráci)
Výchozí formulář aplikace – home obrazovka
Výchozí formulář aplikace zobrazuje všechny aktivní klienty. Tj. klienty, kteří mají volič záznamů – spolupracuje – nastavený na pravda.
Formulář v každém řádku zobrazuje:
1. Název (jméno) klienta. Ten je případě osoby sestaven ze jména a příjmení (kódu). V případě skupiny osob z názvu skupiny. V případě agregovaného klienta – Příjmení (kód). V případě třídy název plus ročník
2. Typ klienta (osoba, agregovaný, anonymní skupina, třída, seskupení osob)
3. Nadřízená organizace (tento sloupec může být podmíněný – pokud existuje aktivitní klient, který má nadřízenou organizaci. V mnoha zařízeních to tak být nemusí. Naopak,
pokud bude zvolen program primární prevence, bude toto polo zobrazené vždy, protože každá třída má nadřízenou organizaci – tedy školu.
Ve formuláři musí jít fulltextově vyhledávat, řadit a filtrovat podle jednotlivých sloupců. Počet řádků musí být také volitelný. V nastavení uživatele půjde měnit. Každý může mít jinak velký monitor a jiné preference. (počet zobrazených řádků bude pro všechny seznamy stejný) Z každého řádku bude možné otevřít několik dalších formulářů.
1. Kartu klienta
2. Založit klientovi nový záznam o výkonu
3. Zobrazit seznam provedených výkonů u klienta
Na obrazovce s výchozím formulářem aplikace se také uskutečňují a musí být viditelné předvolby pro další zápis výkonu. Tyto předvolby jsou nastavené pro každého uživatele samostatně. Jedná se o:
1. Místo
2. Datum
3. Experty
Pokud tyto předvolby nejsou vyplněné, zobrazují se v novém formuláři pro zápis výkonu výchozí hodnoty popsané výše. Z toho vyplývá, že předvolby musí jít smazat, nebo může být zvolena jen nějaká – například Datum.
Všechny další seznamy jsou přístupné z menu aplikace.
Seznam všech klientů Formulář zobrazuje:
1. Název (jméno) klienta. Ten je případě osoby sestaven ze jména a příjmení. V případě skupiny osob z názvu skupiny. V případě anonymní skupiny název skupiny. V případě třídy název plus ročník
2. Typ klienta (osoba, agregovaný, anonymní skupina, třída, seskupení osob)
3. Nadřízená organizace
4. Pole spolupracuje (true / false)
5. Datum posledního výkazu
Tento seznam zobrazuje všechny klienty. Xxxx i ty, kteří již ve spolupráci nejsou. Důležité je informační pole s datem posledního zápisu výkonu. Jediné pole, které lze editovat přímo ze seznamu, je pole Spolupracuje. Tzn pokud klient nespolupracuje, je možné ho zde znovu do spolupráce vrátit. Tím se zobrazí v hlavním formuláři – viz předchozí seznam, a následně je možné ho plně editovat.
Tento seznam musí obsahovat fultextové vyhledávání plus možnost řazení a filtrace podle všech dostupných polí. Ze seznamu je také nutné umět otevřít seznamy výkonů klienta a všechny jeho návazné tabulky. (kartu klienta, provedené výkony atd.) Vše pouze pro čtení.
Seznam expertů
Seznam expertů je ve skutečnosti seznamem uživatelů. Nicméně může nastat situace, kdy expert nebude mít přístup do aplikace, nebo ho nebude potřebovat, protože agendu povede někdo jiný, ale expert bude uváděn u jednotlivých výkonů.
Každý uživatel bude mít příznak – spolupracuje. Ten určuje, jestli se zobrazí v nabídkách nových záznamů. V této agendě bude vidět pouze jméno a příjmení, uživatelské jméno a příznak, jestli spolupracuje. Zároveň zde budou zobrazeni pouze uživatelé, kteří mají patřičnou roli příslušící k programu. Třeba expertPP – pro experty primární prevence. Jediné editovatelné pole zde bude – spolupracuje. V seznamu půjde fultextově vyhledávat, řadit a filtrovat.
Ze seznamu expertů se otevírá seznam výkonů experta.
Seznam výkonů experta Formulář obsahuje.
1. Datum výkonu
2. Název výkonu
3. Jméno klienta, kterému byl výkon poskytnut
4. Délku výkonu
Seznam musí umět řadit záznamy podle vybraného sloupce a také podle každého sloupce filtrovat. Filtr pole Datum výkonu musí umět filtrovat podle datum od – datum do. Z řádku půjde přímo otevřít patřičný záznam o výkonu a bude možné jej následně editovat.
Ve formuláři se ukazuje součet času a počet výkazů, na kterých byl expert přítomen. Filtr formuláře musí jít vytisknout v rámci tiskové sestavy. Tato sestava bude obdobná jako tisková sestava tisková sestava přehledu výkonů, ale je filtrována nikoliv podle vybraného klienta, ale právě podle experta.
Seznam výkonů klienta
Tento seznam půjde otevřít u vybraného klienta na hlavním formuláři, ze seznamu klientů, a i z dalších agend.
Formulář obsahuje:
1. Datum
2. Projekt
3. Místo
4. Název výkonu
5. Délku výkonu
6. Pokud se jedná o seznam výkonů klienta typu anonymní skupina / třída, musí ještě obsahovat sloupec nadřízené instituce a u třídy ročník.
Formulář musí umět řadit a filtrovat podle všech polí. V poli datum je nutné nastavit filtr od – do. Pole výkon musí být filtrovatelné i negativně. Tzn. vybrat výkony, které se zobrazit nemají.
Z každého řádku je také možné zobrazit přímo formulář daného zápisu výkonu. Formuláře výkonu jsou vyplněné formuláře záznamu výkonu.
Seznam výkonů klienta je u klienta typu – skupina osob – odlišný. Viz dále.
Seznam výkonů klienta typu skupina osob
Skupina osob ve skutečnosti nemá jeden společný výkaz, ale každý klient v této skupině má výkaz svůj vlastní. Viz zápis výkonu pro skupinu osob. Existuje však uložený záznam s datem a zápisem dokumentace – tj. originál, který je vzorem pro kopii k jednotlivým záznamům. Seznam výkonů se tedy stává ze dvou částí.
V první části je tvořen seznamem originálních zápisů – datum plus možnost otevřít originál dokumentace.
V druhé části se po zvolení položky ze seznamu části první, zobrazí seznam všech klientů, kteří byli danému výkonu přítomni, a z tohoto seznamu je pak možné otevřít přímo formulář pro záznam výkonu.
Pro lepší demonstraci je přiložen screenshot formuláře z aplikace UniData.
Dokumentaci výkonu (zápis) je možné otevřít a editovat. Pokud se editovaný záznam uloží, přepíše dokumentaci u všech klientů, kteří byli přítomni výkonu. Před uložením to musí uživatel explicitně potvrdit. Stejně tak lze otevřít přímo záznam o výkonu konkrétního klienta – pravá část obrazovky. Pokud se zde záznam edituje, ostatní záznamy klientů ve skupině se nemění!
Seznam je výchozím zobrazením agendy Nálezy a sekundární výměna. V seznamu je zobrazeno:
1. Datum nálezu
2. Projekt
3. Místo
4. Jehly In: číslo
5. Jehly Out: číslo
6. Nálezy: číslo
7. Osoby: číslo
Seznam musí umožňovat řazení podle všech sloupců a filtrování také podle všech sloupců. Filtr dle data musí být nastavitelný v rozmezí od – do.
Z vybraného filtru je pak nutné umět vytisknout tiskovou sestavu nálezů a sec. výměny.
Datové úložiště je speciální typ seznamu. Jedná se o agendu, kam jsou ukládané některé výstupy. Typicky závěrečné a průběžné zprávy. Viz výstupy, V průběhu let totiž dochází ke změnám ve struktuře těchto dokumentů a také ke změnám v algoritmech. Výstupy, které slouží jako podklad pro doložení činnosti organizace je tudíž nutné ukládat v podobě platné v daném roce. Formáty pro ukládání mohou být pdf. nebo xlsx. Agenda je tvořena seznamem těchto výstupů s možností stažení těchto dokumentů, jejich filtrováním podle typů a data.
Seznam obsahuje sloupce:
1. Datum uložení
2. Jméno uložitele
3. Typ dokumentu (závěrečné zprávy, sumář výkonů atd.)
4. Popisek (ten může uživatel vytvořit při ukládání)
5. Možnost otevřít složku se samotným dokumentem
V seznamu lze také mazat a editovat popisek. Automaticky to však může dělat pouze administrátor organizace. Ten může udělovat právo dalším uživatelům. O editaci i mazání musí být veden log. Co, kdy a kdo.
Statistické přehledy a výstupy jednotlivých zařízení
Statistické přehledy a výstupy budou nakonfigurovány v souladu se zadáním a požadavky zadávací dokumentace (Příloha H výzvy k podání nabídky – Požadavky zadavatele na informační systém adiktologických služeb). Jednotlivé grafy a statistické přehledy budou exportovatelné do standartních formátů jako PDF apod. Připraveny budou také tiskové sestavy dle požadavků definovaných v rámci analytické fáze.
Výstupy
Výstupy jsou tvořeny samostatnou agendou v menu. Jsou rozdělené na několik hlavních částí.
1. Závěrečné a průběžné zprávy
2. Globální statistiky
3. Provozní výstupy
Hodnoty s platností ukončenou v čase.
Pokud do výstupů vstupují hodnoty, které pozbývají platnosti v čase – například typ závislostního chování – obsahují vyplněné pole s datem – ukončeno. U těchto záznamů je nutné, aby byly platné ve sledovaném období. Příklad. Pokud klient navštívil zařízení v lednu 2018 a byla mu zapsána primární závislost – Alkohol – a do filtru statistik je zadáno leden–březen 2018, objeví se u klienta primární závislost alkohol ve výstupech. Pokud klient do zařízení dorazí i v dubnu a změní primární závislost na marihuanu – tj. bude mu uzavřena primární závislost na alkoholu a zapsána nová – tak ve statistikách za leden až duben 2018 bude figurovat pod primární závislosti marihuana. Tj. zobrazí se poslední platná hodnota záznamu. Avšak při filtru leden–březen, zůstane figurovat jako alkoholový klient.
Filtry výstupů – globální
Výstupy jsou vždy filtrovány podle volitelných kritérií. Základním kritériem je volba časového rozpětí. Tento filtr je povinný pro všechny výstupy. Další filtry se liší podle typu výstupů.
Závěrečné a průběžné zprávy
Jedná se o standardizované výstupy, které požadují poskytovatelé dotací jednotlivým zařízením. První etapa vývoje informačního systému předpokládá výstup pro závěrečnou a průběžnou zprávu pro RVKPP.
Tento výstup je pro všechny typu programů, s výjimkou primární prevence, stejný.
Filtry pro závěrečné a průběžné zprávy RVKPP:
2. Globální filtr od – do
3. Filtr dle místa (možnost vícenásobné volby)
4. Filtr dle krajů – jedná se vlastně o vícenásobný výběr obcí sdružených v jednom kraji. Možnost vícenásobného výběru.
5. Filtr dle projektu (možnost vícenásobné volby)
6. Filtr podle obce kontaktní adresy (možnost vícenásobné volby)
7. V případě primární prevence se objevuje i filtr podle škol (vícenásobný výběr)
8. V případě primární prevence, případně při zvoleném voliči záznamů Anonymní skupina
/ třída (viz. dále) se filtr – obec kontaktní adresy – nahradí filtrem obec nadřízené organizace anonymní skupiny / školy
Závěrečné zprávy pro RVKPP. Všechny programy s výjimkou Primární prevence Výstupem jsou dvě excelovské tabulky s pevně daným formátováním. Výsledné tabulky je možné uložit do Datového úložiště. Tyto dvě tabulky jsou: Výstup tabulky výkonů a výstup tabulky klientů. Viz dále.
Před samotným výstupem je nutné použít volič záznamů, který obsahuje dvě položky
1. Osoby
2. Anonymní skupina / třída
Mohou být zvolena obě kritéria. Výchozí jsou osoby. Tabulky pro anonymní skupiny jsou stejné, ale liší se algoritmem pro výpočet některých hodnot. A mění se také nabízený filtr. Viz. Filtry pro závěrečné zprávy RVKPP výše. Pokud jsou zvolené oba typy, není možné použít filtry dle obce a kraje.
Filtr dle obce nabízí číselník obcí, který se v případě osob rovná obcím trvalého bydliště osob, které jsou uvedeny v kartě klienta typu osoba. V případě anonymní skupiny / třídy se seznam změní podle institucí, se kterými jsou tyto skupiny spojené. Viz. klient typu anonymní skupina
Výstup tabulky výkonů.
Tabulka výkonů je součástí příloh k zadávací dokumentaci. Obsahuje vždy popis hodnoty a dva sloupečky. Jeden je počet osob, druhý počet výkonů. Obsahuje ještě první, statický sloupec, který popisuje hierarchickou strukturu. Vstupní data pro tuto část tvoří primárně záznamy vložené do formuláře pro záznam výkonu.
Příklad:
Výkon: Rodinné poradenství Počet osob: 30 Počet výkonů: 10
Výstup vychází z formulářů pro záznam výkonu. V případě klientů typu osoba je počtem osob skutečný počet osob. Pokud se jedná o záznamy pro klienta – agregovaný klient, tak do pole počtu osob vstupuje nula. Tzn pokud byl výkon Distribuce harm reduction materiálu poskytnut desetkrát pro agregovaného klienta a třikrát pro jednoho konkrétního klienta, bude výstup vypadat takto.
Výkon: Distribuce hr materiálu Počet osob: 1 Počet výkonů: 13
V případě klienta typu anonymní skupina / třída se počet osob rovná maximálního počtu uvedených u výkonů v jednotlivých skupinách. Maximálně však počtu uvedeném v kartě klienta typu anonymní skupina / třída součtu počtů osob ve skupinách. Celkový součet je pak roven sumě jednotlivých množství. Primárně se předpokládá, že skupiny neobsahují stejné osoby. Což je v případě tříd pravda vždy, ale v případě jiných anonymních skupin to tak nemusí být. Tato disproporce brána v potaz.
Příklad. Skupina obsahuje deset osob (7 žen a 3 muži). Když se zakládá výkaz / výkon pro tuto skupinu, formulář pro zápis výkonu obsahuje také počty osob (žen a mužů). Při založení je vyplněn právě čísly z karty klienta. Nicméně skutečný počet osob může být nižší. Zkrátka nedorazí všichni. Tzn je třeba najít výkaz s největším počtem klientů ve skupině, který spadá do daného filtru (čas od do, místo, projekt atd.) a toto číslo je právě počet osob, které vstoupí do pole Počet osob. V případě tříd se nehledá nejvyšší počet a jako relevantní je brán záznam o počtu žáků ve třídě v kartě klienta (třídy).
4.3.6. Výpočet osob, kontaktů a výkonů.
Pokud se v závěrečné zprávě a kdekoliv jinde počítá počet kontaktů, myslí se tím následující.
Kontakt – dle nové specifikace klientovýkon - je setkání s klientem, tedy vlastně vyplněný výkaz. V rámci jednoho setkání je možné zadat několik výkonů – tedy poskytnout několik služeb. Tzn Pokud jsou klientovi poskytnuty dva výkony v rámci jednoho sezení – třeba krizová intervence a výměna HR materiálu, vypadá sumář následovně.
Počet výkonů | Počet klientovýkonů –( kontaktů) | Počet osob |
2 | 1 | 1 |
Pokud se pracuje s klientem typu seskupení osob, nebo klientem typu anonymní skupiny / třída, je počet kontaktů roven počtu osob v dané skupině, kterým byl výkon poskytnut.
Ve finále je tedy výpočet klientovýkonu roven výsledku rovnice – zápis výkonu x počet klientů v zápisu.
Výkon
Situace je ještě malinko složitější, protože výpočet počtu Výkonů se ve skutečnosti počítá z časové jednotky. Viz číselník výkonů, Nicméně princip demonstrovaný na příkladu výše i níže zůstává stejný.
Důležitá je změna algoritmu u tzv. skupinového zápisu. Tedy u záznamu výkonu, který je poskytován skupině osob.
Příklad: Terapeutická skupina (seskupení osob) čítá pět členů. Na výkon dorazí tři. V rámci této skupiny je poskytnut výkon práce s rodinou.
Druhý den dorazí ti samí a je jim poskytnut opět stejný výkon. Sumář za oba dny pak bude vypadat následovně.
Počet výkonů práce s rodinou | Počet kontaktů | Počet osob |
2 | 6 | 3 |
Kdyby ti samí lidé přišli ve dvou dnech za sebou jako individuální klienti a byl jim všem postupně poskytnut stejný výkon, například Informační servis, tabulka by vypadala následovně.
Počet výkonů informační servis | Počet kontaktů | Počet osob |
6 | 6 | 3 |
Úkony nepřímé práce ve prospěch klienta
Tento typ výkonů tvoří úkony, které ve skutečnosti žádnými výkony nejsou. Tzn, že nevstupují do globálních statistik výkonů, ani do závěrečných zpráv. Nicméně ve výstupech mají speciální agendu. Neexistuje u nich přepočet na jednotku výkon – neexistuje žádná stanovená / doporučená časová dotace. Zařízení pouze zaznamená typ výkonu a čas, po který byl úkon pro klienta poskytován. Zařízení si ale může, v lokálním nastavení, nastavit výchozí časové hodnoty, jako u výkonů.
Výstup tabulky klientů
Tabulka klientů je součástí příloh k zadávací dokumentaci. Obsahuje vždy popis hodnoty a jeden sloupec s počtem klientů. Obsahem je ještě první, statický sloupec, který popisuje hierarchickou strukturu tabulky.
Tabulka zobrazuje počty klientů rozčleněných na dvě základní skupiny. Uživatelé a neuživatelé. Tedy klienti se závislostním chováním a bez závislostního chování.
Pozn. V případě klienta typu anonymní skupina / třída se počet osob rovná počtu uvedených v kartě klienta. Viz příklad výše. Klienti tohoto typu budou vždy v rámci závěrečných zpráv zařazeni do Ostatních klientů – neuživatelů. Tento typ klienta je tedy vždy klient bez závislostního chování! V hypotetickém případě, kdyby byla tabulka klientů tvořena pouze klienty typu anonymní skupina / třída, tak budou v tabulce závěrečných zpráv, v části klienti, vyplněny pouze následující dva řádky.
5.2. Celkem ostatních klientů (neuživatelé, rodinní příslušníci, blízcí osob se závislostním problémem)
A
5.3. Celkem všech klientů (uživatelů i neuživatelů) (pozn. součet 5.1 + 5.2)
Klienti se závislostním chováním jsou následně dělení podle typů primárního závislostního chování (užívané drogy ale i další nelátkové závislostí – gambling atd.) Členění je pak ještě rozdělené na muže a ženy a dále také na první kontakty – viz dále. Všechny tyto parametry jsou uváděny v kartě klienta a dalších návazných formulářů. Údaje o závislostním chování jsou před výstupem validovány na jejich stáří. Nesmí být starší než dva roky. Viz. Kontrola incomových tabulek. Na začátku – před samotným výstupem proběhne tedy kontrola, zdali mezi klienty není nějaký se starým záznamem. Pokud ano, zobrazí se varovná hláška s možností ukončení generování výstupů. Místo výstupu se zobrazí seznam klientů se starými údaji. Tento seznam se zobrazí, i pokud uživatel zvolí, že chce výstup vygenerovat. Pozor! Kontroluje se pouze stáří incomových tabulek, nikoliv to, jestli jsou, nebo nejsou vyplněné. Tabulka návykového chování vyplněná být nemusí – pak je klient označen jako klient bez závislostního chování. Pokud vyplněná je, kontrola proběhne.
První kontakt: Prvním kontaktem je označen takový klient, kterému byla v daném období poprvé poskytnuta nějaká služba. Tj. byl mu vyplněn záznam o poskytnutém výkonu. Příklad. Pokud je filtr výstupu nastaven na 1.7.2018 – 31.12.2018 a první výkaz klienta nalezený v databázi je s datem 30.6. 2018 (a samozřejmě minimálně jeden z dalších výkazů musí spadat do zadaného časového období) tak se o první kontakt nejedná. Naopak, byl-li by první nalezený výkaz až ve zvoleném období, pak by klient byl označen jako první kontakt.
Závěrečné a průběžné zprávy pro modul primární prevence
Závěrečné a průběžné zprávy pro modul primární prevence mají odlišnou podobu. Ta je určena jednak jinou cílovou skupinou, kterou je primárně třída, a také jinými typy výkonů. Výstupy závěrečných zpráv pro primární prevenci jsou tři, každá pro jeden typ primární prevence (VPP, SPP a IPP1) Je možné si je navolit – například pouze výstupy pro IPP a SPP. Pokud jsou výstupy realizovány z více typů primární prevence najednou, zobrazují se také souhrny za všechny zvolené PP. Tabulka je součástí příloh zadávací dokumentace.
Počty osob jsou počítány stejně jako v případě klientů typu anonymní skupiny / třída. Viz výše. Před samotným výstupem je nutné použít volič záznamů který obsahuje dvě položky
1. Osoby
2. Třída
Ve výchozím nastavení je pro modul primární prevence vybraná třída. Pokud jsou zvolené oba typy, není možné použít filtry dle místa, obce a kraje.
Globální statistiky
Filtry pro globální statistiky
Ve výstupech globálních statistik jsou využívány následující filtry
1. Globální filtr od – do
2. Filtr dle místa (možnost vícenásobné volby)
3. Filtr dle krajů – jedná se vlastně o hromadných výběr obcí sdružených v jednom kraji. Možnost vícenásobného výběru.
4. Filtr dle projektu (možnost vícenásobné volby)
1 Všeobecná primární prevence, specifická primární prevence a indikovaná primární prevence
5. Filtr podle obce kontaktní adresy (možnost vícenásobné volby)
6. V případě primární prevence se objevuje i filtr podle škol (vícenásobný výběr)
7. V případě primární prevence, případně při zvoleném voliči záznamů Anonymní skupina
/ třída (viz. dále) se filtr – obec kontaktní adresy – nahradí filtrem obec anonymní skupiny / školy
Pokud je výstupem globálních statistik tisková sestava, tak se vždy v záhlaví tiskové sestavy zobrazují zvolené filtry, aby ze sestavy bylo zřejmé, jaké vstupní filtry na ní byly použité.
Před samotným výstupem je nutné použít volič záznamů, který obsahuje dvě položky, z čehož minimálně jedna musí být vybraná.
2. Osoby
3. Anonymní skupiny /třída
Pro modul primární prevence je ve výchozím nastavení vybraná třída. Pokud uživatel vybere oba typy, není možné použít filtry dle místa, obce a kraje.
V sumářích výkonů v modulu primární prevence se navíc ještě zobrazuje počet škol, pro které byla PP v rámci výkonu realizována a také počet bloků PP. Tento údaj označuje počet setkání (tj. vyplněných výkazů) s klientem typu třída.
Pro ostatní moduly je sumář výkonů zobrazen následovně – viz přílohy zadávací dokumentace
U tohoto výstupu je přítomný ještě jeden volič, který určuje, zdali má být sestava zobrazena včetně podrobných výkonů – dle nové terminologie tzv Specifikace výkonů. Viz. Podrobnosti výkonů. Tento volič je ve výchozím nastavení nastaven na false. Tedy na zobrazení bez podrobností. Pokud ho uživatel zaškrtne, je třeba zobrazit výstup včetně podrobností. Viz přílohy – podrobnosti výkonů a viz číselník podrobnosti výkonů..
Výstupním formátem pro sumáře výkonů je pdf s tiskovou sestavou a tabulka ve formátu xlsx. Výstup nezahrnuje Úkony nepřímé práce ve prospěch klienta! Ten má vlastní výstup, viz dále.
Úkony nepřímé práce ve prospěch klienta
Bude se zobrazovat stejně jako sumáře výkonů výše, ale v samostatném výstupu.
Závěrečné a průběžné zprávy pro modul primární prevence
Pokud se uživatel nachází v modulu primární prevence, pak výstup Sumáře výkonů supluje i ýstup pro účely závěrečných a průběžných zpráv.
Počty setkání pro MPSV
Tento výstup pracuje s termínem setkání – podobně jako sumáře výkonů pro primární prevenci pracuje s počtem bloků PP – viz výše. Technicky je jedno setkání rovno jednomu zápisu výkonu (tj. vyplněnému výkazu). Ministerstvo práce a sociálních věcí sbírá údaje o počtu setkání seřazených do skupin podle délky trvání. Konkrétně se jedná o setkání do 15, 30, 60, 90, 120 a 180 minut. Tyto kategorie musí být variabilní. Tzn Každý program musí mít možnost změnit délku a počet těchto skupin v nastavení programu (výchozí nastavení je 6 skupin s výše uvedenými délkami setkání. Počítají se všechny výkony, bez ohledu na způsob provedení. (face to face, po internetu atd.)
Výstupním formátem pro sumáře výkonů je pdf s tiskovou sestavou a tabulka ve formátu xlsx.
Počty osob
Tento výstup je pouze pro klienty typu osoba. Má výchozí voliče:
1. Noví klienti
2. Stávající klienti
Ve výchozím nastavení jsou zvolené obě možnosti. Nový a stávající klient.
4.3.7. Nový a stávající klient
Kdekoliv ve výstupech, kde je třeba rozlišovat nové a stávající klienty, se rozumí následující.
Nový klient: je klient, který v daném časovém období navštívil zařízení poprvé. Tzn v rámci zvoleného časového období mu byl zapsán první výkaz (poskytnutá první služba)
Stávající klient: je klient, kterému v daném období byla poskytnuta služba (zapsán výkon), ale nepatří do kategorie nový klient. Tzn Služba mu byla poskytnuta v rámci zvoleného období, ale již také někdy v minulosti.
Tento výstup dále používá filtr dle závislostního chování. Výběr je vícenásobný a je volen z číselníku návykového chování. Zobrazeny jsou pouze chování, která byla někdy v minulosti u klientů použita (omezí se délka výběrového seznamu). Je přidána položka – bez závislostního chování! Ve výchozím nastavení jsou zvoleny všechny možnosti.
Výstup je pak strukturován následovně:
Počet ID klientů celkem: (je vyřazen anonymní kód) | 50 |
Počet ID klientů muži: | 25 |
Počet ID klientů ženy: | 25 |
Počet ID klientů muži do 14 let: | 2 |
Počet ID klientů ženy do 14 let: | 1 |
Počet ID klientů do 14 let: | 3 |
Počet ID klientů muži – není věk: | 7 |
Počet ID klientů ženy – není věk: | 3 |
Počet ID klientů – neví věk: | 10 |
Věkové kategorie lze v nastavení programu modifikovat jak do počtu, tak věkového rozmezí. Věkové kategorie mohou být použity i v dalších výstupech.
Výstupním formátem pro sumáře výkonů je pdf s tiskovou sestavou a tabulka ve formátu xlsx. V záhlaví tiskové sestavy se zobrazí všechny použité filtry.
Sumář testů a výsledky testů
V číselníku výkonů existuje výkon – testování infekčních nemocí. Zároveň v modulu Anamnéza klienta jsou uvedeny výsledky testů některých nemocí. Tyto dvě agendy jsou spolu jednosměrně provázané. Směr provázání výkony -> anamnéza.
Pokud jsou v agendě Anamnéza, vyplněné údaje o výsledcích testů, na úrovni výkonů se nic nestane. Pokud je však proveden zápis o výkonu s výkonem Testování infekčních nemocí a následně v podrobnosti výkonu zvolena jedna ze čtyř nemocí, které jsou sledovány v anamnestickém listu, provede se automatický zápis i do anamnestického listu s výsledkem a datem, který je totožný se zápisem výkonu. Zároveň v anamnestickém listu je u tohoto výkonu nastaven volič Selferport na false. (selfreport znamená, že informaci o výsledku testu přinesl pouze klient.)
Samotný výstup Sumář testů vypadá následovně.
Typ testu | Počet osob | Počet testů |
HIV | 2 | 1 |
Hepa A | 3 | 3 |
2 | 5 | 4 |
Pozor! Suma počtu osob nemusí být prostým součtem hodnot ve sloupci. Jedná se totiž
o unikátní osoby. Tzn V příkladu výše by spodní interval sumáře mohl být 3, protože dvě osoby mohly být stejné.
Výstup Výsledky testů vypadá následovně:
Typ testu | Hodnota | Počet | Počet osob |
HIV výsledek | Negativní | 2 | 2 |
HIV výsledek | Pozitivní | 1 | 1 |
HIV z čeho | Z plné krve | 1 | 1 |
Hepa A | Negativní | 3 | 2 |
Výstupním formátem pro sumáře výkonů je pdf s tiskovou sestavou a tabulka ve formátu xlsx.
Výměnný program, nálezy a sekundární výměna
Do tohoto výstupu vstupují data ze dvou agend. Z agendy – Nálezy a sekundární výměna a z agendy pro zápis výkonu. Výkon samotný se jmenuje – Distribuce harm reduction materiálu a v jeho podrobnostech se uvádí počty jehel vydaných a přijatých (jehly in a jehly out) a dále kvantifikovaný zápis dalšího výměnného materiálu.
Z agendy „Nálezy a sekundární výměna“ vstupují do výstupu počty nalezených jehel a dále počty jehel vydaných a přijatých v rámci sekundární výměny a také počty osob přítomných u sekundární výměny.
Jehly in a jehly out z obou agend jsou ještě sečtené. Výstup tedy vypadá následovně:
Materiál | Počet |
Jehly In | 20 |
Jehly in sec. | 10 |
Jehly in sum. | 30 |
Jehly out | 5 |
Jehly out sec. | 7 |
Jehly out sum. | 12 |
Osoby sec. | 11 |
Nálezy | 50 |
Sterilní voda | 5 |
Vitamíny | 2 |
Alobal | 1 |
Výstupním formátem pro sumáře výkonů je pdf s tiskovou sestavou a tabulka ve formátu xlsx.
Skladba klientů
Výstup zobrazí skladbu klientů dle závislostního chování.
Klienti se závislostním chováním jsou dále rozdělení podle typů primárního závislostního chování (užívané drogy, ale i další nelátkové závislostí – gambling atd.) Členění je pak ještě rozdělené na muže a ženy a dále také na první kontakty. Všechny tyto parametry jsou uváděny v kartě klienta a dalších návazných formulářů. Údaje o závislostním chování jsou před výstupem validovány na jejich stáří. Nesmí být starší než dva roky. Viz Kontrola incomových tabulek. Na začátku – před samotným výstupem proběhne tedy kontrola, zdali mezi klienty není nějaký se starým záznamem. Pokud nějaký takový existuje, zobrazí se varovná hláška s možností ukončení generování výstupů. Pokud je výstup uživatelem přerušen, zobrazí se sestava klientů se starými údaji. Tento seznam se zobrazí, i pokud uživatel zvolí, že chce výstup vygenerovat, protože klienti se starými údaji do výstupů nevstoupí. Uživatel tedy musí vědět, kteří klienti nejsou ve výstupu zobrazeni. Pozor! Kontroluje se pouze stáří incomových tabulek, nikoliv to, jestli jsou, nebo nejsou vyplněné. Tabulka návykového chování vyplněná být nemusí – pak je klient označen jako klient bez závislostního chování a do tohoto výstupu nepatří. Pokud vyplněná je, kontrola proběhne.
Výstup samotný je pak tiskovou sestavou. S údaji uvedenými v příkladu níže.
Součástí výstupu je i seznam polyvalentních uživatelů. Viz Ukázka níže. To, jestli se jedná o polyvaletního klienta je opět zapsáno v tabulce návykového chování.
Průběh léčby
Výstup průběh léčby je sumářem vycházejícím z počtu klientů, kteří ve zvoleném období ukončili léčbu. Informace vychází z návazné klientské tabulky – Zahájení a ukončení léčby v zařízení. Pro vstup do tohoto výstupy musí být léčba ve zvoleném období ukončená. V této agendě se k datu ukončení povinně vybírá způsob ukončení z číselníku možností ukončení, ve kterém je zároveň uvedeno, jestli se jedná o úspěšné, nebo neúspěšné ukončení.
Průměrné délky léčby se pak počítají z času od zahájení do ukončení. Výstup bude obsahovat volič true / false – do průměru zahrnout i jednodenní léčby. Ten bude ve výchozím nastavení nastaveno na true. Některá zařízení mají větší množství klientů, kde se v jednom dni zapíše zahájení i ukončení, a pak by byl výsledek zkreslený. Je tudíž nutné, mít možnost vybrat, že tyto jednodenní léčby nebudou do průměru vstupovat.
Samotný výstup pak vypadá následovně.
Indikátor | Počet osob / dní |
Úspěšná léčba | 30 osob |
Neúspěšná léčba | 10 osob |
Průměrná doba úspěšně ukončené léčby | 301 dnů |
Průměrná doba léčby | 214 dní |
Odkazy a doporučení
Výstup se skládá ze dvou částí – odkazy a doporučení. Každá z částí má dvě podoby – výčet a sumář.
Výčet odkazů v části výčtů obsahuje tři sloupce
Klient | Datum odkazu | Odkaz |
ADA25ADA54 | 13.7.2018 | Sociální služby |
LAK01LAK01 | 17.8.2018 | Léčebné zařízení |
Následuje tabulka doporučení
Klient | Doporučení |
ADA25ADA54 | Přes internet |
LAK01LAK01 | Ostatní zdravotnické služby |
Sumáře pak vypadají následovně:
Odkaz | Počet |
Zdravotní služby | 5 |
Léčebná zařízení | 4 |
Celkem | 9 |
Doporučení | Počet |
Rodina či blízké osoby | 5 |
Adiktologické služby | 4 |
Praktický lékař | 2 |
Celkem | 11 |
Typy gamblingu
Výstup se skládá ze dvou částí – odkazy a doporučení. Každá z částí má dvě podoby – výčet a sumář.
Výstup má opět podobu výčtu a sumáře. Zobrazení hodnot je podmíněno tím, že klient musí mít v tabulce návykového chování aktivní chování typu patologické hráčství. Tzn. neukončené. Pokud aktivní patologické hráčství neexistuje, hodnota do výstupu nevstupuje. Aktivní také znamená, že je platné ve sledovaném období. Statistické výstupy je možné zobrazovat za různá časová období a v nich musí být záznamy platné. Viz Hodnoty s ukončenou platnosti v čase.
Klient | Typ patologického hráčství |
ADA25ADA54 | automaty |
LAK01LAK01 | Elektromechanická ruleta v herně nebo v kasinu |
Typ patologického hráčství | Počet typu hráčství |
automaty | 2 |
Elektromechanická ruleta v herně nebo v kasinu | 3 |
Celkem | 5 |
Karta potřeb
Výstup karty potřeb se neřídí ve filtru časového rozmezí daty poskytnutí služby klientovi, nýbrž daty vzniku karet potřeb.
Výstup má podobu tiskové sestavy a přehledové tabulky, kterou je možné filtrovat podle sloupců a exportovat do formátu xlsx.
Tisková sestava a tabulka obsahuje řádky s následujícími ukazateli.
1. Klient
2. Oblast – číselník z karty potřeb
3. Téma – číselník z karty potřeb
4. Potřeba – číselník z karty potřeb
5. Datum vzniku potřeby
6. Datum ukončení potřeby
7. Příznak true/false Splněno.
V patičce tiskové sestavy jsou pak ještě sumarizační údaje.
1. Celkový počet započatých nebo ukončených potřeb klienta
2. Z toho splněných
Ukončení léčby
Výstupem je tabulka exportovatelná do xlsx s možností filtrování. Zahrnuje následující ukazatele.
Klient | Datum | Důvod | Úspěšné? |
AHA01AHA01 | 20.7.2018 | Vyloučen pro opakovanou absenci | Ne |
Provozní výstupy
Filtr pro provozní výstupy tvoří pouze časové rozmezí od-do. Jedná se totiž vždy o výčtové seznamy – nikoliv sumáře, a další filtrování se pak odehrává přímo uvnitř těchto vygenerovaných seznamů, a to podle všech sloupců, které to umožňují.
Stáří Incomových tabulek
Mezi kontrolované tzv. incomové tabulky patří tři tabulky z návazných klientských formulářů.
1. Formulář soci-ekonomické údaje
2. Formulář návykového chování
3. Formulář rizikového chování
V těchto tabulkách se kontroluje, jestli údaje v nich nejsou starší než dva roky.
Výstup samotný pak zobrazí všechny klienty, kteří ve vybraném časovém rozsahu navštívili zařízení – tj. byl jim proveden zápis o výkonu a vedle nich seznam těchto tří tabulek s příznakem, jestli jsou tabulky vyplněné a jestli jsou údaje validní – tedy ne starší než dva roky.
Ukázka přehledové tabulky:
Klienta | Návykové chování | Soc-eko. Údaje | Rizikové chování |
Aba27aba27 | 1.1.2018 | 1.1.2014 | 20.5.2017 |
Ila25ila25 | 30.5.2088 | 30.5.2018 |
Přehledová tabulka ukazuje u každé agendy datum poslední aktualizace a následně pomocí barevných příznaků označuje červeně ty, které nejsou vůbec vyplněné a žlutě ty záznamy, které jsou starší než dva roky. Xxxxxx je třeba zobrazit jako přehledovou tabulku s výstupem
exportovatelným do xlsx. Jednotlivé buňky jsou aktivní, tj. je z nich možné přímo otevřít daný formulář. A to i ty prázdné – tj. založit z nich nový záznam, pokud ještě neexistuje.
Přehledy výkonů
Přehled výkonů je důležitý přehled sloužící k detailní analýze zapsaných výkazů. Jeho základním filtrem je časové rozpětí zapsání výkazu – poskytnutí služby – klientovi a volič záznamů – včetně neproběhlých, který je ve výchozím nastavení nastaven na false. (Neproběhlý výkon znamená výkon, kdy klient nebyl přítomen)
Všechny ostatní filtry jsou pak realizované uvnitř výstupu samotného, podle jednotlivých sloupců. Výstupem je přehledová, dále filtrovatelná tabulka, která umožňuje daný výběr exportovat do formátu xlsx.
Výstup zobrazuje následující údaje:
1. Datum zápisu výkazu
2. Klient (jméno, příjmení, kód, název třídy či anonymní skupiny)
3. Typ klienta (osoba, anonymní skupina / třída, skupina (seskupení osob))
4. Název skupiny – pokud byl výkon klientovi poskytnut v rámci skupiny
5. Poskytnutý výkon
6. Délka výkonu
7. V případě programu primární prevence – typ primární prevence
8. V případě programu primární prevence – škola, pod kterou třída spadá
9. V případě programu – služby ve vězení – typ služby
10. V případě využívání výkonu – distribuce harm reduction materiálu – Jehly In, Jehly Out (sčítají je jehly i z modulu nálezy a sekundární výměna)
11. Experti – řádek s hodnotami oddělenými čárkou (Xxx Xxxxx, Xxxx Xxxxxxxx) – filtrovat je ale nutné podle jednotlivých expertů. Tzn, bude-li chtít uživatel vidět všechny výkony, kterých se účastnila Xxxx Xxxxxxxx, musí se zobrazit řádky, kde je Xxxx Xxxxxxxx uvedená samotná, ale i ty, kde je uvedená s někým dalším. Tento filtr také musí být vícenásobný
12. Projekt
13. Místo výkonu
14. Dokumentace k výkonu – hodnota true/false podle toho, jestli je dokumentace k výkonu vyplněná
Úkony pro zajištění nepřímé práce s klientem
Jednoduchý výstup filtrovaný dle času a projektů zobrazující sumář a přehled těchto úkonů.
Klienti ve více programech
Tabulka s výčtem klientů čerpajících služby z více programů.
Klient | Program | Počet výkazů |
AHA01AHA01 | Kontaktní a poradenské služby | 2 |
AHA01AHA01 | Adiktologické služby ve vězení | 3 |
AAA00AAA00 | Kontaktní a poradenské služby | 1 |
AAA00AAA00 | Adiktologické služby ve vězení | 0 |
Ukázka demonstruje i záznam, kdy je u klienta AAA00AAA00 uvedena v jednom z programů nula. Tato situace může nastat, pokud klient ve sledovaném časovém období skutečně využil pouze jeden z programů, ale mimo toto období figuruje i v jiném programu.
Klienti ve více projektech
Obdobná tabulka s výčtem klientů čerpajících služby z více projektů.
Klient | Projekt | Počet výkazů |
AHA01AHA01 | Re-Start | 2 |
AHA01AHA01 | EU – case management | 3 |
AAA00AAA00 | Re-Start | 1 |
AAA00AAA00 | Ulice | 0 |
Ukázka demonstruje i záznam, kdy je u klienta AAA00AAA00 uvedena v jednom z projektů nula. Tato situace může nastat, pokud klient ve sledovaném časovém období skutečně využil pouze jeden z projektů, ale mimo toto období figuruje i v jiném projektu.
Exportní moduly jednotlivých zařízení do dalších systémů. V první fází se bude jednat o export do zdravotnického registru UZIS – NRLUD
Datová komunikace s řešením třetích stran bude realizována prostřednictvím API, které dodá dodavatel v rámci řešení. Jednotlivé Endpointy budou sepsány s využitím Swageru (xxxxx://xxxxxxx.xx) což je moderní řešení pro sdílení dokumentace v rámci multi- dodavatelského řešení. Architektura API bude dodána v rámci analytické (úvodní) fáze projektu.
Export bude realizován jak pro jednotlivé klienty, tak v dávkách – za zvolené období. Před samotným exportem musí být provedena validace vybraných údajů (hlášení požaduje minimální rozsah povinných údajů). Export probíhá u všech klientů, kterým byla v daném časovém období poskytnuta služba (byl jim vyplněn záznam o výkonu), a mají nastavený příznak NRLUD v kartě klienta na true. Samotná možnost exportu se bude zobrazovat / nezobrazovat na základě volby v nastavení programu – Vykazovat do NRLUD ano / ne.
Export bude logován. U každého klienta se zobrazí datum posledního exportu.
Export do NRLUD (Národní registr léčby uživatelů drog)
Veškeré náležitosti včetně datového rozhraní pro import, jsou k nalezení zde. xxxxx://xxx.xxxx.xx/xxxxxxxx-xxxx/xxxxx
Export bude realizován jak pro jednotlivé klienty, tak v dávkách – za zvolené období. Před samotným exportem musí být provedena validace vybraných údajů (hlášení požaduje minimální rozsah povinných údajů). Export probíhá u všech klientů, kterým byla v daném časovém období poskytnuta služba (byl jim vyplněn záznam o výkonu), a mají nastavený příznak NRLUD v kartě klienta na true. Samotná možnost exportu se bude zobrazovat / nezobrazovat na základě volby v nastavení programu – Vykazovat do NRLUD ano / ne.
Export bude logován. U každého klienta se zobrazí datum posledního exportu.
Moduly pro souhrnné statistické přehledy a exporty – sumáře za jedno, ale i více zařízení. Tento modul bude sloužit primárně pro poskytovatele dotačních titulů (donátorů)
Realizace takových modulů bude řešena jako v předchozích případech s využitím existujících frontend komponent. Celá funkcionalita bude dodána v souladu se zadávací dokumentací (Příloha H výzvy k podání nabídky – Požadavky zadavatele na informační systém adiktologických služeb) a analytickou fází projektu.
Donátoři jsou uživatelé se speciálními právy, které jim umožňuje práci pouze v tomto modulu. Donátoři nemají přístup do modulů jednotlivých zařízení, ani do administračních modulů. Tento modul umožňuje pouze práci s agregovanými, sumarizovanými, anonymizovanými daty.
Modul zahrnuje dvě základní části. Výkonovou a klientskou.
Výkonová část – dělí se na vlastní výkony, výměnný program, další přehledy
Výkony
Tento modul je tvořen přehledovou tabulkou s filtry (možnost exportovat do formátu MS Excel), možností seskupování, filtrování a řazení.
Základním filtrem je filtr časového rozpětí od – do. Tento filtr zobrazí údaje o výkonech v jednotlivých zařízeních.
Další vstupní filtry jsou – kraj, obec, typ programu (primární prevence, ambulantní léčba a stacionární program atd.), konkrétní zařízení. Pokud tyto filtry nemají vybrané hodnoty, zobrazují se data bez těchto filtrů. Filtry kraj, obec, konkrétní zařízení fungují z leva doprava kaskádově (každá položka zvolená v kraji zužuje výběr v položce obec a zařízení atd.), nicméně mohou být voleny i z druhé strany (je možné si vybrat rovnou zařízení, nebo obec) tyto volby pak zužují výběry v dalších dvou filtrech.
Sloupce Kraj, obec a zařízení jsou také ve výchozím filtru volitelné. Tzn nemusí se ve výběru vůbec zobrazovat.
Výstupem jsou tabulky totožné s tabulkami sumářů výkonů, akorát hierarchicky zanořené do celků nadřazených programu zařízení. Tj. zařízení celé, obec a kraj. Sloupce kraj, obec, zařízení a název výkonu musí být seskupitelné. Tzn musí být umožněno podle jednotlivých sloupců data seskupovat. V jednom pohledu tedy uživatel může chtít data vidět podle jednotlivých výkonů a až v dalších sloupcích vidět jednotlivá zařízení, obce atd. v druhém pohledu chce seskupovat například primárně podle krajů a následně jednotlivých výkonů. Ostatní sloupce umožňují vždy řazení – vzestupné a sestupné. Sumáře jednotlivých sloupců se zobrazují jak podle vybrané skupiny pro seskupení, tak jako celkové sumáře.
Další přehledy
Další přehledy zobrazují výstupy dle stejných filtrů jako výše, se stejnými požadavky. Jedná se o výstupy pro sumáře odkazů a testů. Příklad níže zobrazuje ukázku Globálního výstupu, kde uživatel zvolil nezobrazovat pole kraj a zařízení a seskupil výstup podle obce.
Demonstrační obrázek naznačuje požadovanou strukturu všech požadovaných výstupů v modulu pro donátory. Jejich struktura je stejná, jako u výstupů pro jednotlivé programy, jen je hierarchicky začleněná do množiny měst, obcí a zařízení
Další přehledy obsahují výstupy:
• Sumáře testů
• Sumáře odkazů
Sumáře výměnného programu, nálezů a sekundární výměny.
Struktura těchto výstupů je stejná, jako u výstupů pro jednotlivé programy, jen je hierarchicky začleněná do množiny měst, obcí a zařízení
Klientská část
Základním filtrem pro klientskou část je opět časové rozpětí poskytnutí výkonu klientovi. Dalšími filtry jsou Kraj organizace, obec organizace, organizace, kraj narození, obec narození, kraj trvalého bydliště, obec trvalého bydliště. Všechny tyto sloupce jsou také volitelné – nemusí se tudíž zobrazovat.
Věkové kategorie si každý donátor může nastavit vlastní. Maximální počet - 5 Hodnoty ve výstupu
1. Kraj organizace
2. Obec organizace
3. Organizace
4. Kraj narození klienta
5. Obec narození klienta
6. Kraj trvalého bydliště klienta
7. Obec trvalého bydliště klienta
8. Pohlaví
9. Věková kategorie
10. Typ primárního závislostního chování
11. Primární závislostní chování
12. Rizikové sdílení jehel v současnosti (ano/ne)
13. Injekční užívání v současnosti (ano/ne)
Poslední dvě kritéria se mohou v čase změnit bez možnosti nalézt jejich historii. Tzn Pokud bude záznam v tabulce rizikového chování změněn až po sledovaném období, zobrazí se neznám.
Příklad: Záznam Injekční užívání byl v prosinci roku 2020 u klienta změněn na Injekční užívání v současnosti ne. Neznáme tedy, jaké byly hodnoty před tímto datem (mohly se vystřídat). Pokud tedy bude generován seznam pro leden až červen roku 2020 – zobrazí se u tohoto klienta u této hodnoty – neznámo. To vstoupí do sumářů.
Všechny výstupy je možné exportovat a ukládat do datového úložiště donátora.
Tiskové sestavy
Tiskové sestavy slouží k zobrazení a následnému tisku vybraných datových sad, přehledů, zápisů atd. Tiskové sestavy se generují ve formátu pdf. Nebo jsou do něj uložitelné. Tiskové sestavy náleží jednak k agendě výstupů, viz výše, ale někdy jsou součástí jednotlivých karet a přehledů.
Tato tisková sestava se tiskne z přehledu výkonů konkrétního klienta. Tisková sestava obsahuje.
1. Popis vybraného filtru – od – do, výkony atd.
2. Časy výkonů, včetně sumáře času za všechny vybrané výkony
Administrátorský modul pro kompletní správu přihlašovacích údajů a uživatelů
s přehledy aktivit jednotlivých uživatelů (uživatelské jméno, e-mail, instituce, datum založení účtu, poslední přihlášení, aktivní, neaktivní uživatelů, seznam rolí)
Dodavatel má v rámci výše popsaných technologií díky minulým projektům již hotové moduly, které se komplexně věnují správě uživatelů, jejich tvorbě, editaci uživatelských oprávnění a jejich přidělování organizacím. Všechny operace v rámci administrace budou logovány (uživatel, operace, časové razítko). Administrace bude umožňovat základní úrovně přístupů tak, jak jsou požadovány v rámci zadávací dokumentace Příloha H výzvy k podání nabídky – Požadavky zadavatele na informační systém adiktologických služeb).
Tento modul slouží pro správu uživatelů. Každý uživatel má přednastavená práva podle níže uvedených informací.
Součástí této agendy bude i přehled logů, který monitoruje všechny přihlášené uživatele. Záznam bude vždy následující: Jméno a příjmení uživatele – přihlášen (datum + hodina) – odhlášen (datum + hodina), úkon (nový, editace nebo smazání), příjmení / kód klienta a název formuláře, viz tabulka níže. Není třeba logovat co přesně změnil, postačí název formuláře (prohlížení bez editace se neloguje).
Ve skutečnosti v rámci jednoho přihlášení bude existovat více úkonů. Pozn: Z důvodu úspory místa by se mohly logy po roce smazat. To může být i manuální funkce pro Super admina, kde by si nastavil datum, ke kterému mají být logy smazány, a smazal by je.
Tabulka 1: Scháma logu přístupu uživatelů
User | Přihlášen | Odhlášen | Úkon | Klient | Formulář |
XxxxXxxxx | 1.8.2018 7:05 | 1.8.2018 7:55 | Editace | ALE00ALE00 | Karta klienta |
Všichni uživatelé budou identifikováni na základě jedinečného e-mailu, pomocí kterého se do administrace budou i přihlašovat.
Při tvorbě nového uživatele, se novému uživateli na uvedený jedinečný e-mail odešle automaticky vygenerované heslo a uživatel bude vyzván k neprodlené změně hesla. Pouze uživatel si může změnit své heslo.
Žádný uživatel také nelze smazat, lze pouze deaktivovat, kdy mu bude automaticky odepřen další přístup do aplikace a bude mu automaticky udělena role „Neaktivní uživatel“, více v sekci níže.
Uživatelé
Z výše uvedeného modelu vyplývá nastavení rolí a uživatelských přístup popsané dále. Všechny role níže mají práva k zápisu i ke čtení v rámci pravomocí vyplývajících z jejich role.
Super admin
Tato role je nejvyšší, je to tzv. admin celého systému a má následující možnosti:
• Schvalovat žádosti, podané organizací o používání aplikace, tyto organizace může následně editovat. V případě smazání bude organizace pouze deaktivována (nebude dostupná v administraci) ale nebude smazaná z databáze. Takto vytvořeným organizacím musí dále nastavit prostředí. Nemá přístup do jednotlivých programů organizace.
• Vytvářet administrátory organizace (vždy pouze jeden administrátor pro jednu organizaci). Tyto adminy může následně editovat a přiřazovat k organizacím. V případě smazání bude admin organizace pouze deaktivován, ale nebude smazán z databáze.
Současně mohou být pouze 2 aktivní uživatelé s rolí super admin. Super admina nelze deaktivovat, pokud neexistuje nový uživatel s touto rolí.
Modul pro správu přihlašovacích údajů a uživatelů pro administrátory jednotlivých zařízení s přehledy aktivit jednotlivých uživatelů (uživatelské jméno, jméno a příjmení, datum založení účtu, poslední přihlášení, aktivní, neaktivní uživatel)
Dodavatel má v rámci výše popsaných technologií díky minulým projektům již hotové moduly, které se komplexně věnují správě uživatelů, jejich tvorbě, editaci uživatelských oprávnění a jejich přidělování organizacím. Všechny operace v rámci administrace budou logovány (uživatel, operace, časové razítko). Administrace bude umožňovat základní úrovně přístupů tak, jak jsou požadovány v rámci zadávací dokumentace Příloha H výzvy k podání nabídky – Požadavky zadavatele na informační systém adiktologických služeb).
Tento modul slouží pro správu uživatelů. Každý uživatel má přednastavená práva podle níže uvedených informací.
Součástí této agendy bude i přehled logů, který monitoruje všechny přihlášené uživatele. Záznam bude vždy následující: Jméno a příjmení uživatele – přihlášen (datum + hodina) – odhlášen (datum + hodina), úkon (nový, editace nebo smazání), příjmení / kód klienta a název formuláře, viz tabulka níže. Není třeba logovat co přesně změnil, postačí název formuláře (prohlížení bez editace se neloguje).
Admin organizace
Admin celé organizace může provádět následující činnosti:
• Vytvářet a editovat programy, ke kterým je možné přiřazovat administrátory těchto programů nebo exportů. Programy nelze mazat.
• Vytvářet a editovat nové uživatele (administrátory programů nebo experty), těmto uživatelům může rušit jejich přístupy, ale není možné je smazat.
• Má plné přístupy do všech modulů všech programů v rámci své organizace.
Admin organizace může výše uvedené činnosti provádět pouze v rámci své organizace. Žádnou položku nemá možnost odstranit, může pouze uživatelům v jeho organizaci zakázat přístup.
Admina organizace není možné smazat i v případě, že nemá u sebe žádný záznam.
Admin programu
Admini daného programu může provádět následující činnosti:
• Vytvářet a editovat experty, které spadají do jeho programu nebo zařadit experta z jiného programu do svého. Může rušit přístupy expertů ze svého programu. Má plný přistup do všech modulů svého programu. Admin programu nemůže mazat experty, může pouze expertům, ze svého programu zakázat přístup.
Admin programu může být současně i admin organizace.
Řadový pracovník programu tzv. expert
Má přístup pouze do přiřazeného programu. Musí mít přiřazený alespoň jeden program. Počet programů, do kterých bude mít přístup, není omezen.
Donátor
Jedná se o roli pověřeného pracovník, který bude mít přístup do samotného statistického a informačního modulu. Nebude mít nikdy přístup ke konkrétním kartám klientů, respektive ke klientským datům vůbec, a ani do modulů jednotlivých organizací.
Neaktivní uživatel
Bude se jednat o seznam uživatelů, kteří budou neaktivní. V editaci každého uživatele bude možnost nastavit, zda je uživatel aktivní či nikoliv. Aktivní uživatelé budou mít jednu nebo více
výše uvedených rolí a deaktivovaný uživatel bude automaticky zbaven všech aktivních rolí a přístupu do aplikace a bude mu přiřazena právě tato role. Uživatel s touto rolí musí zůstat v aplikaci kvůli zachování jeho jména v záznamech s ním svázané.
Tohoto uživatele může opět aktivovat pouze super admin nebo uživatel, který ho deaktivoval, ale musí mu vybrat alespoň jednu z aktivních rolí.
Celý seznam neaktivních uživatelů uvidí pouze super admin. Admin organizace nebo admin programu uvidí pouze neaktivní uživatele, které sám deaktivoval.
Organizace
Novou organizaci může založit pouze super admin, následnou editaci může provádět již i admin organizace.
Tvorba nové organizace
Pokud chce organizace používat tuto aplikaci, musí vyplnit online žádost o používání aplikace s následujícími položkami:
1. Název organizace
2. Adresa organizace – PSČ, město, ulice + číslo popisné (obce budou vybírány z globálního číselníku obcí)
3. Kontaktní údaje – telefon, e-mail organizace
4. IČO (mohou se duplikovat)
5. Jméno a příjmení statutárního zástupce
6. Kontaktní údaje statutárního zástupce – telefon, e-mail
7. Typy poskytovaných programů (výběr ze seznamu „Číselník druhů programů“) s příznakem, zdali jsou služby certifikované. (pole certifikace do – datum)
8. Údaje administrátora organizace
a. Xxxxx a příjmení
b. Jedinečný e-mail
V rámci této žádosti bude k dispozici smlouva ve formátu .pdf jako příloha, kterou následně musí organizace fyzicky vyplnit a fyzicky odeslat na uvedenou adresu.
Ve webové administraci bude existovat seznam všech organizací, které aplikaci využívají, včetně nových žádostí. Pouze Super admin vidí přehled těchto žádostí, může je editovat a pouze on je může schválit. Super admin můžu tyto žádosti smazat, pokud jsou například duplicitní, není možné smazat žádost nebo organizaci, pokud má k sobě přiřazené jakékoliv záznamy. Po schválení se v číselníku organizací vytvoří nový záznam – číselníky atd.
Detail organizace
Právo pro tvorbu a editaci organizace má admin organizace a super admin.
Organizace jsou tvořeny údaji o ni a o jejich provozovaných programech. Po schválení žádosti organizace o užívání aplikace musí admin organizace doplnit následující údaje, které nejsou součástí žádostí o používání aplikace.
1. PČZ (alfanumerický údaj 5 znaků)
2. NUTS (alfanumerický údaj 20 znaků)
Detail každé organizace bude také obsahovat záznam o doručení smlouvy. V případě, že smlouva fyzicky dorazí na správnou adresu, tak pouze super admin nastaví v administraci datum doručení této smlouvy. Jedná se pouze o informaci, není třeba s tímto údajem dále pracovat.
Správa admin organizace
Tohoto uživatele nelze smazat, lze mu pouze zakázat přístup.
Pokud je třeba změnit administrátora organizace je nutné, aby nejprve stávající admin organizace nebo super admin vytvořil nového admina organizace. V tuto chvíli se zobrazí upozornění, že již jeden admin organizace existuje. Následně nový admin organizace nebo super admin může původního admina organizace deaktivovat (zakázat mu přístup).
Současně mohou být pouze 2 aktivní uživatelé s rolí admin organizace ve stejné organizaci. Admin organizace nelze deaktivovat, pokud neexistuje nový uživatel s touto rolí ve stejné organizaci.
Programy
Programy může vytvářet a editovat pouze admin organizace (Super admin sem již nemá přístup).
Při tvorbě nového programu musí admin organizace vybrat druh programu a vytvořit admina programu. Bez tohoto není možné program uložit. Adminem programu může být i sám admin organizace.
Druhy programů
1. Terénní programy (Tp)
2. Kontaktní a poradenské služby (Kc
3. Ambulantní a stacionární péče (As)
4. Rezidentní péče v terapeutických komunitách (Rp)
5. Doléčovací programy (Dp)
6. Substituční léčba (Sl)
7. Adiktologické služby ve vězení (Vs)
8. Programy primární prevence (Pp)
9. Detoxifikace (Ds)
10. Krátkodobá a střednědobá lůžkové léčba (Ll)
Správa admin programu a experta
Pod program lze vytvořit role jako admin programu nebo expert.
Žádného uživatele nelze s výše uvedenými rolemi smazat, pokud je k němu vázán, byť jen jediný záznam. Záznamem je myšleno „Záznam o poskytnuté službě“, podpis v kartách klientů, založení nějakého záznamu pod jeho jménem atd.
Při tvorbě admina programu nebo experta je nutné vyplnit následující pole:
1. Jedinečný e-mail
2. Xxxxx a příjmení
3. Role – „admin programu“ nebo „expert“
4. Program viz „Číselník programů“, dle tohoto programu se určí přístup
5. Aktivní / neaktivní
Admin programu smí vkládat nové experty programu a smí je i deaktivovat, tj. zakázat jim přístup. Může také vytvářet nového admina programu.
Admin programu může také nahlížet do logu uživatelských přístupů spadající pod jeho program.
Jeden program může mít několik expertů.
V rámci programu je nutné vybrat položky, které se budou vykazovat do NRLUD. Automaticky se vykazují všechny, je nutné pomocí zaškrtávátka zvolit ty, které se vykazovat nebudou.
• Nastavení zobrazování pole pro dokumentaci výkonu. Viz dále.
• Nastavení zobrazení položek číselníků ve výběrech. Viz číselníky.
Seznamy
V editaci programu je následně nutné vybrat ze seznamů „Výkon“ a „Specifikaci výkonu“. Tyto seznamy jsou společné pro celou aplikaci, viz přílohy. Tyto seznamy se dělí na „Globální“ a „Lokální“.
Globální seznam
Tyto globální seznamy může spravovat pouze super admin.
Organizace si zvolí pro každý svůj program druh výkonu a jeho specifikaci, které budou využívat. Automaticky jsou zobrazené všechny druhy i specifikace výkonu, takže je nutné odebrat ty, které aktuální organizace nebo program nevyužívá.
V případě tvorby nového druhu výkonu nebo jeho specifikace se automaticky takto nově vytvořené položky zobrazí ve všech organizacím i programech.
Lokální seznam
Lokálním seznamem je myšleno přizpůsobení si položky ze seznamu pro konkrétní organizaci nebo program.
Přizpůsobením je myšleno přidání parametrů, viz seznam níže, se kterými se dále pracuje v rámci celé organizace nebo programu.
• Projekty – jedná se o jeden z parametrů, pomoci kterého mohou filtrovat a třídit výkony. Aplikace sama automaticky založí pro každý program nový projekt s názvem „Výchozí projekt. Xxxxx projektu by si měl každý program upravit dle svého, není to ale nutností. Tento záznam musí vždy existovat a zároveň je nastaven na hodnotu výchozí. Uživatelé mohou vytvářet více projektů, ale jeden je vždy označený jako výchozí. Tuto položku si volí admin programu, ale musí vždy existovat. Záznam s příznakem – výchozí, nemůže být nastaven na nezobrazovat. Projekt můžeme chápat například jako dotační projekt, pod který program vkládá výkony, a následně je podle tohoto příznaku mohou vyfiltrovat a mohou vytvořit export.
• Místa výkonu – Stejný princip jako projekty. Opět jedno automaticky založené místo.
• Věkové kategorie - Věkové kategorie lze modifikovat jak do počtu, tak věkového rozmezí.
• Instituce
• Číselník školních let
• Číselníky dalších osob
Některé lokální číselníky jsou blíže rozepsané v příloze – lokální číselníky.
I lokální číselníky musí u jednotlivých parametrů obsahovat příznak Zobrazovat x nezobrazovat. Ty, co budou označené jako nezobrazovat, se pak neobjevují v nabídkách souvisejících formulářů. V případě, že je parametr již někde použit a následně je mu nastavený příznak „nezobrazovat“ musí být v tomto případě stále viditelný.
Parametry, které jsou označené jako výchozí, se pak do příslušných formulářů vypisují automaticky.
Seznam výkonů
Tento číselník je naprosto klíčový pro práci s klientem. Určuje, jaká služba byla klientovi poskytnuta, v jaké délce a její popis.
Délka poskytování výkonu se může mezi jednotlivými programy lišit, nebo se dokonce může lišit i v rámci jedné organizace, proto je správa číselníků vždy až na úrovni programu, nikoliv organizace.
Každý výkon má přednastavenou délku poskytovaného výkonu „Stanovená časová délka“, která je nastavená jako výchozí. Programy si mohou sami tuto délku výkonu nastavit na jinou než výchozí „Časová délka programu“. Tato stanovená délka poskytovaného výkonu je tedy ve skutečnosti jednotkou výkonu, na kterou je pak počet výkonů přepočítáván.
Tabulka 2: Globální a lokální parametry číselníku výkonů
Globální parametry | Lokální parametry – nastavení programů | Čas na administrativu | ||||
Název výkonu | Specifikace výkonu | Stanovená časová délka | Časová délka programu | Zobrazovat x nezobrazovat | Výchozí způsob poskytování | |
Příklad: Výkon „individuální poradenství“ má stanovenou časovou délku 30 minut. Program jí však poskytuje v délce 60 minut. Po přepočtu to znamená, že program poskytl dvě jednotky výkonu.
Samotný přepočet neprobíhá na základě stanovené časové délky programu, ale až na základě reálné délky, dle výkazu. Stanovená časová délka programu je v číselníku pouze z toho důvodu, aby uživatel pokaždé nemusel hodnotu ručně měnit v samotném výkazu. Ale vždy zůstává možnost změnit jí až na úrovni výkazu. Může proto nastat následující modelová situace.
Příklad: Stanovená časová délka výkonu: 30 minut. Časová délka programu: 60 minut. Skutečná délka výkonu ve výkazu: 45 minut. Toto se může stát třeba v případě, kdy se klient dostane do časové tísně a domluví se s expertem na kratší terapii atd.
4.3.8. Čas na administrativu
Jedná se o nepovinný údaj. Programy si zde mohou evidovat čas potřebný k administrativním úkonům spjatým s daným výkonem. Výchozí položkou u všech výkonů bude 0. Tato položka půjde nastavit stejně jako časová délka programu při tvorbě zápisu z výkonu.
K výkonu je také třeba zvolit jakým způsobem byl proveden, je nutné vybrat jednu z položek níže:
• Face to face,
• on-line,
• telefon,
• korespondenčně.
Super admin bude mít v administraci možnost zakázat zobrazování některých způsobů provedení výkonu. Následně si admin programu nastaví u každého výkonu výchozí způsob provedení s tím, že expert při realizaci toho výkonu může tento způsob provedení změnit, na ty které má k dispozici (pokud není super adminem zakázaný). Jelikož mohou existovat výkony, které například face to face výkon neumožní. Třeba písemné a internetové poradenství nemůže být provedeno face to face. Mohou také existovat výkony, které naopak umožní pouze face to face způsob provedení.
Pokud Super admin bude chtít zakázat zobrazování způsobu výkonu, kterou má některý program zvolený jako výchozí, nebude mu tento krok umožněn, dokud si tyto programy nezmění výchozí způsob provedení výkonu na jiný. Změnu může provést i super admin. Nemůže možnost zakázat, dokud ji některý z programů má nastavenou jako výchozí.
4.3.9. Číselník specifikací výkonů
Specifikace výkonů, viz přílohy, specifikují blíže a podrobněji daný výkon. Tyto podrobnosti jsou uživateli / programy využívány dle jejich uvážení a také na základě požadavků různých donátorů.
Tento seznam je čistě globální, bez jakýchkoliv úprav pro organizace nebo programy. Jejich editaci, stejně tak jako tvorbu nových, smí provádět pouze super admin. Některé specifikace výkonů mají pod sebou ještě podrobnější formuláře (podagendy) s bližší specifikací výkonu.
Příklad: Výkon může být „Testování“, jeho specifikace je „Analýza návykových látek“ a tuto specifikaci je dále nutné blíže rozepsat, což může být třeba „Testování infekčních nemocí“.
Číselníky jsou umístěné v příloze – globální číselníky. Jednotlivé podagendy jsou uvedené u číselníků.
Jediný super admin může vytvářet i editovat všechny tyto seznamy „Seznam výkonů“,
„Specifikace výkonů“ i „Podagendy“.
Datové úložiště
Pokud bude řešení umístěno v cloudu, doporučuje dodavatel využití prověřených a stabilních služeb, pokud je vyžadováno on-premise řešení, detailní požadavky navrhuje dodavatel vyjasnit v rámci analytické fáze projektu. Dodavatel dodá Zadavateli potřebnou součinnost v rámci přípravné analytické fáze projektu.
Zálohování dat jednotlivých zařízení
Aplikace se bude sama zálohovat dle navrženého plánu záloh (bude definován v rámci analytické projektu). Zálohy mohou být prováděny i několikrát denně, stejně jako údržba takových záloh a dat. Zálohy mohou být směřovány do cloudu, anebo na geograficky oddělené úložiště zadavatele.
Přemetem první analytické fáze projektu je tak navržení plánu záloh tak, aby systém účelně využíval prostředky Zadavatele, při zachování maximální možné dostupnosti služeb. Zvažovány tak budou varianty Databázového i Aplikačního serveru v režimech Always On i High Available. Nastavení plných a inkrementálních záloh databází pak bude také diskutováno se zadavatelem v přípravné fázi projetu.
Eventuální zálohování celého virtuálního serveru pak bude plánováno v souladu se zálohovací strategií Zadavatele
Časový harmonogram
1. První fázi plnění - vývoj webové databázové aplikace, předá dodavatel objednateli do 24 týdnů ode dne nabytí účinnosti smlouvy o dílo. O předání první fáze plnění bude sepsán předávací protokol č. 1, který bude potvrzen podpisy oprávněného zástupce objednatele a dodavatele.
2. Druhá fáze - testování webové databázové aplikace, bude probíhat 4 týdny ode dne předání webové databázové aplikace, resp. po dokončení první fáze plnění a po podpisu předávacího protokolu č. 1 dle předchozího odstavce tohoto článku. V této fázi budou prováděny následující činnosti:
a. testování aplikace betatestery, kteří budou reportovat chyby a závady, které budou sdělovány dodavateli (připomínky a požadavky na opravu nebo doplnění předané aplikace). Dodavatel tyto vady opraví v termínu určeném objednatelem s ohledem na povahu a charakter těchto vad. Po zapracování připomínek a odstranění požadovaných vad aplikace podepíše objednatel akceptační protokol č. 1.
b. uplatňování požadavků objednatele na vylepšení a dílčí změny aplikace. Tyto požadavky na vylepšení a změny budou zpracovány interním
týmem objednatele, budou jim přidělené priority a budou přesně popsány pro účely zadání pro třetí fázi. Požadavky na vylepšení a změny budou zpracovány v rozsahu schváleném
oběma smluvními stranami do akceptačního protokolu č. 2.
3. Třetí fáze, provedení změn a vylepšení informačního systému, bude probíhat 8 týdnů po skončení testovací fáze, tj. po schválení rozsahu změn a vylepšení a po podpisu akceptačního protokolu č. 2 viz. výše. O předání dílčího plnění v rámci třetí fáze dodavatelem objednateli bude sepsán předávací protokol č. 2, který bude potvrzen podpisy oprávněného zástupce objednatele a dodavatele. Objednatel si vyhrazuje právo uplatnit připomínky do 30 dnů od odevzdání finálního informačního systému v rámci třetí fáze plnění. Dodavatel je povinen připomínky vypořádat do 15 dnů, pokud s ohledem na charakter připomínek nebude dohodnuta jiná lhůta. Po vypořádání připomínek v souladu s požadavky objednatele podepíše objednatel akceptační protokol č. 3.
ANALYTICKÁ FÁZE IMPLEMENTACE INFORMAČNÍHO SYSTÉMU A POST- IMPLEMENTAČNÍ PROCES
Analytická fáze implementace informačního systému
• Dodavatel předpokládá řízení projektu pomocí PRINCE2 a dodávku dle ITIL 4.0. Obě metodologie definují standardní metody dodávky informační systémů ve všech fázích implementačního a post-implementačního procesu.
• Dodavatel tak předpokládá dodávku projektu v několika fázích.
o Fáze: Zahájení implementačního projektu. Této fázi bude předcházet veřejná soutěž, vybrání nejvhodnější nabídky, podepsání smlouvy mezi zadavatelem a dodavatelem. Po podpisu smlouvy o dílo sestaví obě zainteresované strany projektový tým, který bude zodpovědný za definování všech funkčních a nefunkčních požadavků na straně zadavatele a projektový tým zodpovědný za dodávku a realizaci na straně dodavatele.
o Po sestavení projektového týmu si definují členové projektového týmu kontrolní mechanismy, způsob předávání informací, formu a strukturu dokumentace.
o Fáze: Spuštění projektu: V této fázi si klíčové osoby na straně zákazníka a na straně dodavatele dohodnou způsoby dodávek a řízení projektu. Zejména se pak jedná o nastavení procesu řízení rizik, změnové řízení, proces řízení jakosti dodávaného díla, sestaví detailní projektový plán a připraví analytickou část projektu.
o Fáze: Dodávka řešení. V rámci této iterační fáze, která navazuje na druhou fázi, bude v několika předem dohodnutých iteracích dodána vždy příslušná část projektu, aktualizován risk log, change log, případně exception log a bude připravena navazující iterace. Zákazník provede kontrolu jakosti dodávaného částečného plnění a autorizuje dodavatele ke spuštění navazující iterace. Tento proces se bude opakovat v souladu s harmonogramem projektu až do jeho úspěšného předání.
o Fáze projektu je příprava ukončení projektu, předání dokumentace a produktů projektu zadavateli, spuštění, funkčních, bezpečnostních a zátěžových testů a příprava na produkční provoz.
• Po celou dobu trvání projektu monitorují obě smluvní strany cíle projektu a kontrolují jejich naplnění.
• V průběhu celého projektu bude kladen důraz na komunikaci mezi dodavatelem a zadavatelem.
• Rozsah a postup analytické fáze tvorby přístupy k nalézání kreativních řešení a efektivní komunikaci se zadavatelem, včetně využití nástrojů osobní (individuální i skupinové) a technologiemi podpořené komunikace si zadavatel a dodavatel dohodnou v rámci 1. Fáze projektu. Dohoda musí respektovat všechny interní předpisy a směrnice obou smluvních stran, kdy obě smluvní strany musí chránit důvěrné informace na straně jedné, na straně druhé pak musí nalézt nejefektivnější mechanizmy ke komunikaci obou zúčastněných stran. Dodavatel tak dodá zadavateli jak online komunikační platformu pro videokonference, tak dedikované dokumentové úložiště pro správu elektronické dokumentace. Dále dodá zadavatel do týmu osobu projektového manažera, business analytika a grafika, kteří se budou společně s klíčovými osobami zadavatele podílet na definici finální podoby díla. Četnost jak
online meetingů, tak osobních schůzek jak v sídle zadavatele, tak v sídle dodavatele bude definována dle nutnosti, s ohledem na co nejefektivnější dodávku předmětu díla.
• Součástí analytické fáze bude také testování UX a technologií včetně případných výzkumů a AB testů, jejichž rozsah, podobu a cíle dodavatel navrhne ve vstupní analýze.
• Grafická podoba návrhu celého díla bude dodána v interaktivní prezentaci Adobe XD, které umožňuje interaktivní práci s grafickými podklady. V praxi to znamená, že zadavatel dostane k dispozici prezentaci s proklikem na jednotlivé stránky už v rámci analytické části projektu a klíčoví uživatelé ze strany zadavatele si tak mohou vyzkoušet práci s funkčním prototypem grafické prezentace. Více se o Adobe XD dozví zadavatel na následujících stránkách: xxxxx://xxx.xxxxx.xxx/xx/xxxxxxxx/xx.xxxx Dále bude dodavatel při návrhu UX a volbě jednotlivých technologií vycházet z obecně platných standardů, zejména bude dbát na kompatibilitu s w3org, dbát na bezpečnost dodávaných technologií a volit grafickou podobu, která bude respektovat grafický manuál a logo manuál zadavatele s ohledem na jednotlivé cílové skupiny uživatelů.
• Zadavatel připouští, že na základě analýzy mohou být v ZD specifikované obsahy, funkce, metody, postupy a technologie informačního systému nejen upřesněny, ale i modifikovány podle potřeb vzešlých z analýzy a dodavatel předpokládá, že jednotlivé požadavky budou na základě analýzy zpřesněny a doplněny.
• Dodavatel ve své nabídce definuje předpokládaný rozsah a podobu materiálu, který bude výstupem z analýzy a podkladem pro implementaci informačního systému po jeho odsouhlasení zadavatelem. Dokument bude obsahovat seznam všech zadavatelem definovaných funkčních a nefunkčních požadavků zadavatele. Dodavatel na základě vlastních zkušeností z podobných projektů, na základě obecně závazných standardů a v neposlední řadě na základě diskuze mezi odpovědnými osobami za zadavatele a odpovědnými osobami na straně dodavatele navrhne ke každému požadavku nejoptimálnější řešení, které bude dostatečně popsáno v dokumentu, který bude výstupem analýzy. Tento dokument pak bude obsahovat popis technického řešení, jednotlivých funkcionalit pokrývajících požadavky zadavatele a také bude obsahovat odkaz na novou grafickou podobu portálu. Dokument nebude obsahovat ani uživatelskou příručku, ani administrátorskou příručku, které budou vznikat až v průběhu implementace, ale které také budou součástí dodávaného řešení.
Výstupy analytické fáze a následný post-implementační rozvoj díla
• V rámci analýzy díla mohou vzniknout nové skutečnosti, které nebyly v zadávací dokumentaci popsány, stejně tak jako mohou vzniknout nové požadavky na funkčnost dodávaného díla. Všechny takového skutečnosti budou diskutovány se zadavatelem a na základě jednání mezi oběma smluvními stranami.
• Za rozvoj informačního systému se považuje vývoj funkcionalit a zdokonalení informačního systému nebo na něj přímo navazujících služeb a funkcí po předání a spuštění informačního systému (díla).
• Dodavatel navrhne s ohledem na zadávací dokumentaci a svou expertízu vhodný rozvoj informačního systému po jeho předání zadavateli.
• Dospěje-li dodavatel v průběhu analytické fáze k závěru, že rozvoj informačního systému by měl být časově zařazen již do dřívější etapy než fáze po spuštění informačního systému, může zařadit tyto funkcionality do základní implementace informačního systému, což promítne i do ceny licence. V takovém případě popíše tyto funkcionality ve stejné úrovni detailu jako funkcionality poptávané zadavatelem, aby bylo možno posoudit jejich soulad s požadavky zadavatele na srovnatelné poptávané funkcionality ve všech oblastech hodnocení.
• Jednotlivé dílo rozvíjející informační systém vznikne na základě dílčí objednávky zadavatele, vzájemného odsouhlasení zadavatele (objednatele) a dodavatele (dodavatele) termínu dodání a počtu hodin potřebného ke zhotovení díla dodavatelem a v souladu s touto zadávací dokumentací tedy vzájemného potvrzení ceny díla. Počet hodin, termín dodání a cena díla mohou být v průběhu zhotovení díla měněny pouze dohodou zadavatele a dodavatele, nikoli jednostranně.
• Dodavatel má dostatečné kapacity pro následný post-implementační rozvoj, zahrnující součinnost a práce na změnách aplikace vč. grafiky, bannerů, obsahu a optimalizacích pro dobré umístění na předních pozicích vyhledávačů.