Kupní smlouva

Číslo smlouvy prodávající: 688/2021

uzavřená podle ustanovení § 2079 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „smlouva“)

1. Smluvní strany

Kupující: Ostravská univerzita

sídlo: Xxxxxxxxx 0, 000 00 Xxxxxxx

zastoupená: doc. MUDr. Xxxxxxxxxxx Xxxxxxx, Ph.D., MBA, FRCPS.

děkanem Lékařské fakulty Ostravské univerzity Ostravské univerzity

IČ: 61988987

DIČ: CZ61988987

bankovní spojení: ČNB Ostrava

č. účtu: 931761/0710

(dále jen „kupující“ nebo „OU“ nebo „zadavatel“)

Prodávající: RCS Kladno, s.r.o.

sídlo: Kladno, Mánesova 1772, PSČ 27201 zapsaná v obchodním rejstříku Krajského soudu v Praze, C 79821 zastoupená: Ing. Xxxxxxxx Xxxxxxx, jednatelem

IČ: 63495295

DIČ: CZ63495295

bankovní spojení: Komerční banka a.s.

č. účtu: 2224360207/0100

(dále jen „prodávající“)

2.1. Tato smlouva je uzavřena na základě zadávacího řízení na veřejnou zakázku „Dispečerský systém pro LF OU“ v rámci projektu Operačního programu Výzkum, vývoj a vzdělávání (dále jen „OP VVV“) s názvem Simulační centrum "Cvičná nemocnice" s reg. č. CZ.02.2.67/0.0/0.0/18_057/0013366.

2.2. Smluvní strany prohlašují, že údaje v článku 1. této smlouvy a taktéž oprávnění k podnikání jsou v souladu s právní skutečností v době uzavření smlouvy. Smluvní strany se zavazují, že změny dotčených údajů oznámí bez prodlení druhé straně. Strany prohlašují, že osoby podepisující tuto smlouvu jsou k tomuto úkonu oprávněny.

3.1. Předmětem této smlouvy je dodávka dispečerského systému, tedy simulovaného prostředí sestávajícího z potřebného HW, informačního systému operačního řízení ZZS, integrovaných prostředků radiové komunikace, telefonního systému a vybavení posádky pro Lékařskou fakultu Ostravské univerzity dle technické specifikace uvedené v Příloze č. 1 této smlouvy v rámci projektu Operačního programu Výzkum, vývoj a vzdělávání (dále jen „OP VVV“) s názvem Simulační centrum "Cvičná nemocnice" s reg. č. CZ.02.2.67/0.0/0.0/18_057/0013366 (dále jen „předmět plnění“).

3.2. Prodávající se zavazuje odevzdat kupujícímu předmět plnění uvedený v čl. 3.1. a umožnit kupujícímu nabýt k předmětu plnění vlastnické právo. Kupující se zavazuje předmět plnění převzít a zaplatit prodávajícímu kupní cenu.

Prodávající předá kupujícímu veškerou dokumentaci vztahující se k zařízení v českém jazyce (v tištěné i elektronické podobě), která je potřebná pro nakládání s předmětem koupě a pro jeho provoz (návod k použití/obsluze, technická dokumentace, pokyny pro údržbu, prohlášení o shodě, protokoly o verifikaci a/nebo kalibraci technických parametrů předmětu, záruční listy apod.).

3.3. Jakost, provedení, vlastnosti a další specifikace předmětu plnění včetně jeho množství jsou uvedeny v Příloze č. 1 smlouvy.

3.4. Dodávkou předmětu plnění dle této smlouvy se rozumí dodávka všech požadovaných prvků, doprava systému na místo plnění vč. vykládky, manipulace, kompletní montáže a ustavení na místo určené kupujícím, uvedení zařízení a všech jeho součástí do plnohodnotného provozu, zaškolení pověřených pracovníků, popis funkčnosti zařízení a systémů z pohledu uživatele tak, aby byl uživatel schopen práce s předmětem plnění (pokud je předmět plnění integrován s jiným systémem, bude dokumentace obsahovat i popis napojení předmětu plnění na další systém v rozsahu nezbytném z hlediska práce uživatele), popis předmětu plnění z hlediska jeho zapojení do stávající infrastruktury a informačního systému (rozhraní a služby) včetně popisu jeho správy a údržby a popis administrativních úloh a možných nastavení systému.

3.5. Prodávající prohlašuje, že:

3.5.1. je výlučným vlastníkem předmětu plnění, které kupujícímu odevzdá,

3.5.2. předmět plnění je nový (tzn. nepoužitý, ani repasovaný),

3.5.3. předmět plnění má vlastnosti, které si smluvní strany ujednaly a není-li takového ujednání, takové vlastnosti, které prodávající nebo výrobce popsal nebo které kupující očekával s ohledem na povahu předmětu plnění,

3.5.4. předmět plnění se hodí k účelu, který vyplývá zejm. z této smlouvy,

3.5.5. předmět plnění vyhovuje požadavkům právních předpisů,

3.5.6. předmět plnění je bez jakýchkoli jiných vad, a to i právních.

3.6. Prodávající je při realizaci předmětu plnění veřejné zakázky povinen dodržet platné technické normy a ekologické požadavky a veškeré použité obaly budou šetrné k životnímu prostředí.

4. Lhůta, místo a způsob plnění

4.1. Prodávající je povinen odevzdat předmět plnění ve lhůtě do 18 týdnů od výzvy kupujícího k poskytnutí plnění.

4.2. Místem odevzdání předmětu plnění je Lékařská fakulta Ostravské univerzity, Syllabova 19, 703 00 Ostrava 3 (dále také „místo plnění“ nebo „místo dodání“).

4.3. Osobou oprávněnou za prodávajícího je Xxx. Xxxxxx Xxxxxxxxxx, e- mail: xxxxxx.xxxxxxxxxx@xxx-xxxxxx.xxx., tel.: 000 000 000.

4.4. Osobou odpovědnou za převzetí předmětu plnění je Xxx. Xxxxxx Xxxxxxxxxxx – biomedicínský technik – projekt Cvičná nemocnice, e-mail: xxxxxx.xxxxxxxxxxx@xxx.xx , tel. 000 000 000, mob. 000 000 000.

4.5. Odevzdání předmětu plnění bude potvrzeno podpisem oprávněných osob prodávajícího a kupujícího na protokolu o odevzdání předmětu plnění s uvedením data odevzdání předmětu plnění.

4.6. Kupující před převzetím předmětu plnění provede testovací provoz v délce 10 pracovních dnů.

4.7. Zjistí-li kupující při testovacím provozu, že předmět plnění má vady nebo nebude prokázána bezchybnost systému dle požadavků uvedených v Příloze č. 1, oznámí to neprodleně prodávajícímu. Má se za to, že dnem následujícím po uplynutí desetidenního testovacího provozu, aniž by kupující oznámil prodávajícímu existenci vad, kupující předmět plnění převzal.

4.8. Kupující není povinen převzít předmět plnění, který vykazuje vady, přestože by samy o sobě ani ve spojení s jinými nebránily řádnému užívání předmětu plnění nebo jeho užívání podstatným způsobem neomezovaly. Nepřevezme-li kupující předmět plnění z tohoto důvodu, hledí se na ně, jako by prodávajícím nebylo odevzdáno a prodávající je v prodlení oproti lhůtě dle čl.

4.1. smlouvy se všemi důsledky, které jsou s tím spojeny.

4.9. Pokud věc vykazuje vady, popř. pokud prodávající neodevzdal kupujícímu některou z více kusů jedné položky předmětu plnění ve smluvené lhůtě, přičemž mělo být na základě této smlouvy odevzdáno více kusů jedné položky předmětu plnění, a kupující se přesto rozhodne odevzdaný předmět plnění od prodávajícího převzít, má se za to, že prodávající splnil závazek odevzdat věc s vadami. Prodávající v takovém případě není v prodlení s odevzdáním věci. Při oznamování a odstraňování vad věci dle tohoto článku postupují smluvní strany přiměřeně v souladu s ustanoveními o reklamaci vad věci uvedenými v čl. 8 této smlouvy. Takto oznámené vady se prodávající zavazuje odstranit v souladu s uplatněným právem kupujícího bezodkladně, nejpozději však do 10 dnů ode dne jejich oznámení prodávajícímu.

5. Cena a platební podmínky

5.1. Celková kupní cena za předmět koupě dle čl. 3 této smlouvy byla dohodou smluvních stran stanovena ve výši:

bez DPH 3 466 278,00 Kč

DPH 727 918,38 Kč

s DPH 4 194 196,38 Kč

5.2. Sjednaná kupní cena je konečná a není možné ji překročit. Prodávající prohlašuje, že kupní cena obsahuje jeho veškeré nutné náklady spojené s řádným a včasným splněním závazků dle této smlouvy, zejm. s řádným odevzdáním předmětu plnění kupujícímu a souvisejícím plněním dle čl. 3.5. této smlouvy.

5.3. Platba bude uskutečněna na základě daňového dokladu vystaveného Prodávajícím po převzetí předmětu plnění Kupujícím se splatností do 30 dnů ode dne doručení daňového dokladu Kupujícímu. Každý daňový doklad (faktura) bude obsahovat náležitosti daňového a účetního dokladu podle zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů a zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a dále

údaj, že předmět plnění bude hrazen z projektu OP VVV Simulační centrum "Cvičná nemocnice" s reg. č. CZ.02.2.67/0.0/0.0/18_057/0013366. Daňový doklad nesplňující předepsané náležitosti bude kupujícím vrácen do dne splatnosti daňového dokladu k opravě, lhůta splatnosti počíná běžet znovu ode dne doručení opraveného či nově vystaveného daňového dokladu. K faktuře bude přiložen dodací list s uvedením názvu a ceny předmětu plnění.

5.4. Prodávající je povinen zasílat faktury elektronickými prostředky na adresu xxxxxxxx.xxxxxxx@xxx.xx.

5.5. Povinnost kupujícího uhradit fakturu je splněna dnem odepsání příslušné částky z účtu kupujícího.

5.6. Prodávající přebírá nebezpečí změny okolností ve smyslu § 1765 odst. 2 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“).

5.7. Kupující neposkytne prodávajícímu žádnou zálohu.

5.8. V případě využití poddodavatelů zajistí Prodávající řádné a včasné plnění finančních závazků svým poddodavatelům, kdy za řádné a včasné plnění se považuje plné uhrazení poddodavatelem vystavených faktur za plnění poskytnutá prodávajícím k provedení závazků vyplývajících ze smlouvy, a to vždy nejpozději do 15 dnů od obdržení platby ze strany objednatele za konkrétní plnění (pokud již splatnost poddodavatelem vystavené faktury nenastala dříve).

Prodávající se zavazuje přenést totožnou povinnost do dalších úrovní dodavatelského řetězce a zavázat své poddodavatele k plnění a šíření této povinnosti též do nižších úrovní dodavatelského řetězce.

Objednatel je oprávněn požadovat předložení dokladů o provedených platbách poddodavatelům a smlouvy uzavřené mezi prodávajícím a poddodavateli. Nesplnění povinností prodávajícího dle tohoto ujednání smlouvy se považuje za podstatné porušení smlouvy s možností odstoupení objednatele od této smlouvy. Odstoupení od této smlouvy je v takovém případě účinné doručením písemného oznámení o odstoupení od smlouvy druhé smluvní straně.

6. Smluvní pokuty

6.1. V případě prodlení prodávajícího s odevzdáním předmětu plnění kupujícímu oproti lhůtě stanovené v čl. 4.1. je kupující oprávněn požadovat na prodávajícím smluvní pokutu ve výši 0,1 % z kupní ceny nedodaného předmětu plnění (včetně DPH) za každý i započatý den prodlení

6.2. V případě prodlení prodávajícího s plněním povinností stanovených v čl. 8.12. této smlouvy je kupující oprávněn požadovat na prodávajícím smluvní pokutu ve výši 300 Kč za každý i započatý den prodlení.

6.3. V případě prodlení kupujícího s úhradou faktury proti sjednanému termínu je prodávající oprávněn požadovat na kupujícím smluvní pokutu ve výši 0,1 % z dlužné částky za každý i započatý den prodlení.

6.4. Uplatněním nároku na smluvní pokutu není dotčeno oprávnění kupujícího požadovat náhradu škody způsobenou porušením povinnosti ze

strany prodávajícího, které je zajištěno smluvní pokutou. To platí i tehdy, bude- li smluvní pokuta snížena rozhodnutím soudu.

7. Nebezpečí škody na předmětu plnění a přechod vlastnictví

7.1. Nebezpečí škody na předmětu plnění a vlastnické právo k předmětu plnění přechází na kupujícího v okamžiku jeho převzetí kupujícím.

8. Záruka za jakost, Práva z vadného plnění

8.1. Předmět plnění je vadný, neodpovídá-li této smlouvě.

8.2. Práva kupujícího z vadného plnění zakládá vada, kterou má předmět plnění v době jeho odevzdání, v době mezi odevzdáním předmětu plnění a počátkem běhu záruční doby nebo v záruční době.

8.3. Smluvní strany sjednávají, že předmět bude odpovídat této smlouvě i po smluvenou záruční dobu.

8.4. Prodávající se zavazuje poskytnout na předmět plnění záruku za jakost, přičemž záruční doba činí minimálně 60 kalendářních měsíců ode dne převzetí předmětu plnění, není-li v záručním listu nebo v jiném prohlášení o záruce stanovena záruční doba delší. Prodávající má povinnosti z vadného plnění nejméně v takovém rozsahu, v jakém trvají povinnosti z vadného plnění výrobce předmětu plnění.

8.5. Záruční doba začíná běžet ode dne převzetí předmětu plnění kupujícím. Je-li předmět plnění kupujícím převzato s alespoň jednou vadou, počíná záruční doba běžet až dnem odstranění poslední vady. Podobně byl-li předmět plněním kupujícím převzat i přesto, že prodávající neodevzdal některou z položek předmětu plnění ve smluvené lhůtě, počíná záruční doba běžet až dnem odevzdání chybějící položky předmětu plnění.

8.6. Záruční doba dle předchozího odstavce neběží po dobu, po kterou kupující nemůže předmět plnění užívat pro vady, za které odpovídá prodávající, tedy i z důvodu jejich řešení.

8.7. Má-li předmět plnění vadu (vady) má kupující právo:

8.7.1. na odstranění vady dodáním nového předmětu plnění bez vady

8.7.2. na odstranění vady dodáním chybějícího předmětu plnění,

8.7.3. na odstranění vady opravou předmětu (je-li vada opravou odstranitelná),

8.7.4. na přiměřenou slevu z kupní ceny, nebo

8.7.5. odstoupit od smlouvy.

Kupující je oprávněn si zvolit a uplatnit kterékoli z výše uvedených práv dle svého uvážení a s přihlédnutím k charakteru vady, příp. zvolit a uplatnit kombinaci těchto práv. Kupující sdělí prodávajícímu, jaké právo si zvolil zároveň s oznámením vady nebo bez zbytečného odkladu po oznámení vady.

8.8. Požadavek na odstranění vad kupující uplatní u prodávajícího nejpozději poslední den záruční doby, a to oznámením kontaktní osobě prodávajícího v písemné podobě nebo elektronicky na e-mail kontaktní osoby (dále také jen „reklamace“). I reklamace odeslaná kupujícím poslední den záruční doby se považuje za včas uplatněnou. V reklamaci kupující uvede

alespoň popis vady a/nebo informaci o tom, jak se vada projevuje, a způsob, jakým požaduje vadu odstranit.

8.9. Prodávající se zavazuje prověřit reklamaci a do 3 pracovních dnů ode dne jejího doručení oznámit kupujícímu, zda reklamaci uznává. Pokud tak prodávající v uvedené lhůtě neučiní, má se za to, že reklamaci uznává a že vadu odstraní v souladu s touto smlouvou.

8.10. I v případech, kdy prodávající reklamaci neuzná, je povinen vadu odstranit. V takovém případě prodávající kupujícího písemně upozorní, že se vzhledem k neuznání reklamace bude domáhat úhrady nákladů na odstranění vady od kupujícího.

8.11. Pokud prodávající reklamaci neuzná, může být její oprávněnost ověřena znaleckým posudkem, který obstará kupující. V případě, že reklamace bude tímto znaleckým posudkem označena jako oprávněná, ponese prodávající i náklady na vyhotovení znaleckého posudku. Právo kupujícího na bezplatné odstranění vady i v tomto případě vzniká dnem doručení reklamace prodávajícímu. Prokáže-li se, že kupující reklamoval neoprávněně, je povinen uhradit prodávajícímu prokazatelně a účelně vynaložené náklady na odstranění vady.

8.12. Reklamované vady se prodávající zavazuje odstranit v souladu s uplatněným právem kupujícího bezodkladně, nejpozději však do 48 hodin ode dne doručení reklamace z důvodu kompletní nefunkčnosti sytému a nejpozději do 14 dnů ode dne doručení reklamace z důvodu ostatních chyb, a to i v případě, že odstraňování vady provede prodávající třetí osobou, pokud nebude smluvními stranami písemně dohodnuto jinak. V případě opravy proběhne její zahájení nejpozději do 5 pracovních dní od nahlášení závady. Kupující umožní na vyžádání vzdálenou správu pro řešení reklamací a servisních zásahů.

8.13. Smluvní strany se zavazují poskytovat si navzájem při odstraňování vad předmětu plnění veškerou potřebnou součinnost tak, aby byly vady řádně a včas odstraněny. Prodávající je povinen zejm.:

8.13.1. v případě odstranění vady dodáním nového předmětu plnění dodat nové předmět plnění na tutéž adresu, kde bylo kupujícímu odevzdáno nahrazovaný předmět plnění, a

8.13.2. převzít předmět plnění, jehož vada má být odstraněna opravou, k opravě v místě, kde bylo kupujícímu odevzdáno, a po provedení opravy opravený předmět plnění opět v tomto místě předat kupujícímu.

Převzetí předmětu plnění k odstranění vad a následné předání předmětu plnění po odstranění vad proběhne vždy v pracovní dny v době od 9:00 do 16:00 hod., nebude-li mezi prodávajícím a kupujícím dohodnuto jinak.

8.14. V případě, že prodávající neodstraní vadu ve lhůtě dle čl. 8.12. smlouvy, nebo pokud prodávající odmítne vadu odstranit, je kupující oprávněn vadu odstranit na své náklady a prodávající je povinen kupujícímu uhradit náklady vynaložené na odstranění vady, a to do 10 dnů ode dne jejich písemného uplatnění u prodávajícího. V případech, kdy ze záručních podmínek vyplývá, že záruční opravy může provádět pouze autorizovaná osoba nebo kdy neautorizovaný zásah je spojen se ztrátou práv ze záruky, smí kupující vadu odstranit pouze využitím služeb autorizované osoby.

8.15. Uplatnění práv z vadného plnění kupujícím, jakož i plnění jim odpovídajících povinností prodávajícího není podmíněno ani jinak spojeno s poskytnutím jakékoli další úplaty kupujícího prodávajícímu, příp. jiné osobě.

9. Ostatní ujednání

9.1. Kupující je povinným subjektem dle zákona č. 340/2015 Sb., o registru smluv (dále jen “zákon o registru smluv“). Prodávající bere na vědomí a výslovně souhlasí s tím, že tato smlouva včetně všech jejích změn a dodatků podléhá uveřejnění v Registru smluv (informační systém veřejné správy, jehož správcem je Ministerstvo vnitra). Kupující se zavazuje, že provede uveřejnění této smlouvy dle příslušného zákona o registru smluv.

9.2. V souladu s ustanovením § 219 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, Kupující uveřejní na svém profilu zadavatele smlouvu včetně všech jejích změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.

9.3. Kupující zveřejní smlouvu včetně všech jejich změn a dodatků dle odstavce 9.1. a 9.2. tohoto článku v plném znění. V případě, že smlouva nebo dodatek obsahuje utajované informace, obchodní tajemství dle § 504 obč. zákoníku, osobní/citlivé údaje, práva duševního vlastnictví či jiné informace, které nelze poskytnout při postupu podle předpisů upravujících svobodný přístup k informacím (dále jen „chráněné informace“), je Prodávající povinen nejpozději v den uzavření smlouvy tuto skutečnost sdělit Kupujícímu, tyto informace přesně identifikovat a kvalifikovat právní důvod jejich ochrany. Tyto části smlouvy (chráněné informace) pak Kupujícím nebudou uveřejněny. V opačném případě je Prodávající seznámen se skutečností, že zveřejnění smlouvy v plném znění dle citovaných zákonů se nepovažuje za porušení obchodního tajemství a že smlouva neobsahuje ani jiné chráněné informace a Prodávající s jejím zveřejněním výslovně souhlasí.

9.4. Tato smlouva nabývá platnosti dnem jejího uzavření a účinnosti dnem uveřejnění smlouvy v Registru smluv. O této skutečnosti Kupující Prodávajícího uvědomí.

9.5. Prodávající je dle ustanovení § 2 písm. e) zákona č. 320/2001 Sb.,

o finanční kontrole ve veřejné správě, v platném znění, osobou povinnou spolupůsobit při výkonu finanční kontroly.

9.6. Prodávající se zavazuje zajistit v rámci plnění této smlouvy legální zaměstnávání osob a zajistí pracovníkům podílejícím se na plnění smlouvy férové a důstojné pracovní podmínky. Férovými a důstojnými pracovními podmínkami se rozumí takové pracovní podmínky, které splňují alespoň minimální standardy stanovené pracovněprávními a mzdovými předpisy. Prodávající je povinen zajistit splnění požadavků tohoto ustanovení smlouvy i u svých poddodavatelů. Nesplnění povinností prodávajícího dle tohoto ujednání smlouvy se považuje za podstatné porušení smlouvy s možností odstoupení objednatele od této smlouvy. Odstoupení od této smlouvy je v takovém případě účinné doručením písemného oznámení o odstoupení od smlouvy druhé smluvní straně.

9.7. Prodávající je povinen umožnit všem subjektům oprávněným k výkonu kontroly projektu, z jehož prostředků je dodávka hrazena, provést kontrolu

dokladů souvisejících s plněním zakázky, a to po dobu danou právními předpisy ČR k jejich archivaci (zákon č. 563/1991 Sb., o účetnictví, a zákon č. 235/2004 Sb., o dani z přidané hodnoty). Tyto doklady budou uchovávány způsobem stanoveným platnými právními předpisy. Subjekty oprávněné k výkonu kontroly mají právo přístupu i k těm částem nabídek, smluv a souvisejících dokumentů, které podléhají ochraně podle zvláštních právních předpisů (např. jako obchodní tajemství, utajované skutečnosti) za předpokladu, že budou splněny požadavky kladené právními předpisy (např. zákonem č. 255/2012 Sb., o kontrole (kontrolní řád), v platném znění). Oprávnění kontroly dle předchozí věty se vztahuje i na případné subdodavatele prodávajícího.

9.8. Ve věcech touto smlouvou výslovně neupravených se bude tento smluvní vztah řídit ustanoveními obecně závazných právních předpisů, zejména občanským zákoníkem a předpisy souvisejícími.

9.9. Smlouva je vyhotovena ve dvou stejnopisech s platností originálu a každá ze smluvních stran obdrží po jejich podpisu jedno vyhotovení, pokud je smlouva uzavřena v listinné podobě.

9.10. Tato smlouva může být měněna nebo doplňována pouze písemnými číslovanými dodatky podepsanými oprávněnými zástupci obou smluvních stran.

9.11. Kupující je oprávněn odstoupit od smlouvy anebo jen částečně odstoupit od smlouvy především v případě, že nebude uvolněna platba poskytovatele finančních prostředků (např. MŠMT) kupujícímu, nebo kupující nebude disponovat dostatečnými finančními prostředky, nebo že výdaje, které by kupujícímu na základě smlouvy měly vzniknout, budou kontrolním subjektem, označeny za nezpůsobilé. V takovém případě prodávající nebude uplatňovat nárok na náhradu škody a případné prodlení s placením daňových dokladů z tohoto důvodu.

9.12. Prodávající se zavazuje, že na fakturu uvede vždy takové bankovní spojení, které bude do tuzemské banky, a které bude mít v době vystavení a splatnosti faktury zveřejněno finančním úřadem na internetu, tak, jak to vyžaduje zákon č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „zákon o DPH“), aby se kupující nedostal do pozice ručitele za odvod DPH za prodávajícího z důvodu platby na nezveřejněný či na zahraniční bankovní účet.

9.13. Pokud se prodávající do data splatnosti faktury stane tzv. nespolehlivým plátcem DPH ve smyslu ustanoven § 106a zákona o DPH a kupující se tak dostane do pozice, kdy dle zákona o DPH ručí za odvod DPH ze strany prodávajícího, je prodávající povinen o této skutečnosti kupujícího bezodkladně informovat.

9.14. Pokud se kupující dostane do pozice, kdy ze zákona ručí za odvod DPH za prodávajícího (např. z důvodů popsaných v bodě 9.12. nebo 9.13. tohoto článku), je kupující oprávněn uhradit prodávajícímu hodnotu faktury pouze ve výši bez DPH a DPH odvést na účet místně příslušného finančního úřadu prodávajícího a prodávající s tímto postupem souhlasí. Dále v případě, že nastanou skutečnosti uvedené v bodě 9.12. tohoto článku, má kupující také právo pozastavit platbu celé částky závazku, a to do doby, než mu prodávající sdělí číslo takového bankovního účtu, který je veden v české bance a je

zveřejněn finančním úřadem. Závazek se tím v obou případech považuje za splněný řádně a včas a kupující se nedostává do prodlení s úhradou. Prodávající pro tento případ prohlašuje, že jeho místně příslušným finančním úřadem pro DPH je Finanční úřad pro Středočeský kraj - Územní pracoviště v Kladně, a že v případě změny místně příslušného finančního úřadu bude kupujícího o této skutečnosti neprodleně informovat, jinak prodávající ponese případné náklady plynoucí ze skutečnosti, že částka DPH nebyla včas poukázána správnému finančnímu úřadu.

9.15. Ustanovení 9.12. až 9.14. se týkají Prodávajícího, kterému je přiděleno české DIČ.

9.16. Prodávající je povinen kupujícímu uhradit veškerou škodu, která mu vznikne nedodržením povinností uvedených výše v tomto článku, a navíc je kupující oprávněn odstoupit od této smlouvy. Odstoupení se stává účinným dnem jeho doručení prodávajícímu.

9.17. Smluvní strany po přečtení smlouvy potvrzují, že obsahu smlouvy porozuměly, že smlouva vyjadřuje jejich pravou, svobodnou a vážnou vůli, nebyla uzavřena v tísni či za nápadně nevýhodných podmínek a na důkaz této skutečnosti ji podepisují.

Přílohy:

Příloha č. 1 – Technická specifikace předmětu plnění

Příloha č. 2 – Podrobná technická specifikace nabízeného předmětu plnění

Za Kupujícího dne ……….….

doc. MUDr. Digitálně podepsal xxx. XXXx. Xxxxxxxxx Xxxxx,

Xxxxxxxxx Xxxxx, Ph.D., MBA, FRCPS

Ph.D., MBA, FRCPS Datum: 2021. 12.06 11:01:57

+01'00'

Za Prodávajícího dne 23.11.2021

Ing. Xxxxxx Xxxxxxxxx podepsal

Xxx. Xxxxxx Xxxxx

Zdich Datum: 2021.11.23

11:55:43 +01'00'

xxx. XXXx. Xxxxxxxxx Xxxxx, Ph.D., MBA, FRCPS děkan Lékařské fakulty

Ostravské univerzity

Xxx. Xxxxxx Xxxxx (jednatel) RCS Kladno, s.r.o.

Příloha č.1 Technická specifikace veřejné zakázky

1. Definice pojmů a zkratek

Zadavatelem veřejné zakázky je Ostravská univerzita, Lékařská fakulta (dále jen Zadavatel nebo Uživatel).

Použité zkratky

FR First responder

HW Hardware

IZS Integrovaný záchranný systém

IS ZD ZZS Informační systém zdravotnické dokumentace ZZS

KZOS Krajské zdravotnické operační středisko

NIS IZS Národní informační systém IZS

OŘ Operační řízení

SaP Síly a prostředky ZZS

SW Software

ZD Zdravotnická dokumentace

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

ZZ Zdravotnické zařízení

MZD Mobilní zadávání dat – zpracování ZD na notebooku/tabletu ve vozidle

EKP Elektronická karta pacienta – zpracování ZD na stacionárním PC posádky

2. Předmět specifikace

Předmětem veřejné zakázky je dodávka simulovaného prostředí sestávající z potřebného HW, informačního systému operačního řízení ZZS, integrovaných prostředků radiové komunikace, telefonního systému a vybavení posádky. Cílem je vytvořit pracoviště co nejvěrněji simulující činnost operačního střediska, včetně navázaných technologií a spolupráce s posádkou ZZS v terénu, tedy také simulované „pracoviště“ posádky.

Dodaný systém OŘ musí odpovídat níže uvedené specifikaci a musí podporovat veškeré procesy operačního řízení ZZS, stejně jako by šlo o systém pro ostrý provoz ZZS, až na uvedené výjimky. Systém musí podporovat všechny typy činnosti ZZS, jako je příjem tísňových výzev a datových zpráv, podporu odborné přednemocniční neodkladné péče, setkávacího systému, PPNP, TANR, TAPP, systém First responder v simulovaném režimu apod.

3. Specifikace předmětu plnění

Architektura řešení

Předmětem dodávky je integrované řešení systému operačního řízení (dále jen OŘ) včetně prostředí GIS, tří dispečerských pracovišť (calltakera, dispečera a lektora), informačního systému pro zdravotnickou dokumentaci (dále jen ZD), složený z mobilního zadávání dat (dále jen MZD) a stacionárního zpracování zdravotnické dokumentace (elektronické karty pacienta), dále jen EKP.

Součástí dodávky bude také integrace jedné analogové radiostanice pro prostředí dotykové obrazovky, SW nebo HW telefonní ústředna s GSM bránou, telefonními přístroji bez integrace se záznamem hovorů a vybavení simulované posádky složené z ruční radiostanice, odolného notebooku s dotykovou obrazovkou a serverem pro běh serverových částí dodaných systémů.

Hardwarové komponenty systému

V rámci dodávky bude dodáno potřebné hardwarové vybavení, operačních systémů a všech nutných propojení tak, aby vznikl spolu se software funkční celek celého řešení. HW komponenty budou připojeny do existujících centrálních síťových prvků zadavatele, který také poskytne rozdělení provozu do příslušných VLAN v případě potřeby segmentace sítě. Minimálně dodané hardwarové komponenty jsou:

3.2.1 Server(y)

Serverová část bude provozována na jednom nebo více fyzických severech s potřebným počtem virtuálních serverů pro potřeby všech systémů, které bude třeba provozovat. Minimem je dodávka jednoho serveru o parametrech:

- celkový průměrný výkon všech CPU dohromady min. 25 000 bodů v Passmark CPU Mark

- 64 GB ECC operační paměti

- 4 HDD v RAID 5 o minimálním výkonu 200 IOPS

- v rackovém provedení o maximální výšce každého serveru 2U

Servery budou umístěny v technologické místnosti v rackové skříni zadavatele a připojeny redundantně metalickým kabelem o rychlostí 1Gbps k přepínači zadavatele.

Součástí dodávky musí být všechny potřebné operační systémy, virtualizační technologie a databázové servery nutné pro běh celého řešení včetně potřebného počtu klientských licencí. Licence musí být trvalá, přenositelná na jiný hardware, v licenčním režimu zadavatele, kdy je možné využít licence pro účely vzdělávání.

Navržené serverové řešení musí umožňovat dosažení odezvy a kapacity definované v kapitole „Odezva a kapacita systému“.

	Požadavek	Popis
HW 01	Dodávka serverového prostředí	Dodávka jednoho nebo více serverů dostatečného výkonu včetně virtualizační technologie, OS a databází

3.2.2 Pracovní stanice

Klientské pracovní stanice budou umístěny v dispečerských stolech simulovaného pracoviště calltakera, dispečera a lektora. Pracoviště calltakera a dispečera budou shodná PC v provedení microtower nebo SFF v minimální konfiguraci:

- 1 CPU o minimálním průměrném výkonu 10 000 bodů v Passmark CPU Mark

- 16GB RAM

- SSD HDD o minimální kapacitě 240GB

- dedikovaná grafická karta pro potřebný počet monitorů

- 3x min. 27“ monitor s rozlišením 4K

- min. 17“ dotyková obrazovka pro provoz integrovaných technologií

- operační systém vyžadovaný aplikacemi

- klávesnice, myš

PC lektora pak bude v konfiguraci:

- 1 CPU o minimálním průměrném výkonu 10 000 bodů v Passmark CPU Mark

- 16GB RAM

- SSD HDD o minimální kapacitě 500GB

- dedikovaná grafická karta pro potřebný počet monitorů

- 2x min. 27“ monitor s rozlišením 4K

- operační systém vyžadovaný aplikacemi

- klávesnice, myš

PC budou připojena v technologické místnosti do přepínače zadavatele pomocí strukturované kabeláže budovy a to metalickým kabelem o rychlosti 1Gbps (dodávka kabelů do 10m).

Požadavek

Popis

HW 02

Dodávka pracovních

stanic

Dodávka 3x pracovní stanic, 8x monitor, 2x touch screen, včetně OS.

3.2.3 Telefonie a záznam hovorů

V rámci dodávky bude dodána telefonní ústředna, ať už v HW provedení nebo jako SW licence provozována v serverovém prostředí. Na pracoviště calltakera, dispečera a lektora budou umístěny fyzické telefonní přístroje (3 ks) a náhlavní soupravy v drátovém provedení vhodném pro call centra a nepřetržité použití (3 ks). K náhlavní sadě musí být možné samostatně dokoupit spotřební materiál (min. náhradní ušní molitany).

Dále bude dodán přenosný telefon pro napojený na ústřednu (DECT nebo Wifi) pro práci simulované posádky.

Vstupním a výstupním bodem ústředny bude jedna nebo více GSM brán kompatibilních s ústřednou

s celkově dvěma komunikačními kanály (2x SIM). Dodávka SIM karet není předmětem dodávky.

Ústředna bude umístěna v technologické místnosti zadavatele a přístroje k ní budou napojeny přes strukturovanou kabeláž budovy (dodávka kabelů do 10m).

Veškeré hovory musí být nahrávány na záznamové zařízení s možností přehrání hovoru z prostředí systému operačního řízení nebo integrace telefonie na dotykové obrazovce. U nahrávání musí být nastavitelná možnost automatického odmazávání hovorů po definované době.

Telefonní ústředna bude integrována do prostředí dotykové obrazovky, kde bude umožněn minimálně příjem hovoru a vytočení čísla včetně vytočení ostatních poboček ústředny pomocí zkrácené volby. Dále bude umožněno zakládání události na základě hovoru a párování nahrávek k události, jak je popsáno v popisu systému OŘ.

Požadavek

Popis

HW 03

Dodávka telefonní ústředny

Telefonní ústředna se záznamem, integrací, 3x IP stolní telefon, 1x přenosný (IP nebo analogový s převodníkem), GSM brána, kabeláž.

Telefonní ústředna bude dodána jako SW licence IP ústředny pro potřebný počet připojených zařízení. Je-li softwarová licence vázaná na HW dodavatele licence, nebo není-li možné ústřednu provozovat v rámci virtualizace dodávaného serveru, musí být součástí dodávky také HW platforma dodavatele licence nebo samostatný server pro běh ústředny

v provedení do racku výšky max. 2U.

3.2.4 Simulovaný rádiový provoz a jeho integrace

Pro simulaci rádiového provozu bude dodána jedna vozidlová radiostanice integrovaná do prostředí touchscreenu pracovních stanic a dále jedna ruční radiostanice pro simulovanou posádku. Provoz bude veden na volně dostupných frekvencích v analogovém nebo digitálním režimu.

Pokud způsob integrace zvolené dodavatelem neumožní využít volných frekvencí, tedy např. provoz dodané technologie by byl v rozporu s legislativou, musí být součástí dodávky podklad pro žádost zadavatele na přidělení frekvence (zpracovaná žádost). Dodavatel pak provede dodávku integrované radiostanice spolu s anténou, kdy maximální vyzářený výkon ERP bude 3 W a předpokládaný kmitočet bude v rozsahu 136-174 MHz (VHF), což bude stav pro předání díla. Po přidělení frekvence pak v rámci záruky dodavatel provede naprogramování radiostanic na frekvenci, která bude zadavateli přidělena.

Integrace musí umožňovat přenos hlasu z a do radiostanice, zaklíčování, příjem a odeslání selektivní výzvy a volání ve skupině, a to z obou dispečerských stanic. Volání ve skupině bude směrováno na obě pracoviště (calltakera i dispečera).

Radioprovoz bude nahráván do záznamového zařízení, které bude shodné se zařízením pro záznam telefonie nebo samostatné. Přehrávání bude umožněno z prostředí systému operačního zařízení nebo samostatného klienta, který musí být dostupný na všech třech pracovištích.

Integrovaná radiostanice včetně prostředků integrace budou umístěny v technologické místnosti zadavatele.

	Požadavek	Popis
HW 04	Dodávka radiofonie	Dodávka integrované vozidlové a neintegrované ruční radiostanice, integrace do systému včetně záznamu

3.2.5 Audiopropojovací pole

Součástí dodávky HW nebo SW zařízení pro zajištění propojení všech potřebných audio výstupů a vstupů s náhlavní soupravou, reproduktorem a mikrofonem, které budou součástí dodávky pro pracoviště calltakera a dispečera.

Zařízení musí zajistit propojení výstupu telefonu, PC a případně integrované radiostanice (pokud zvuk nebude výstupem PC) a přenést tento zvuk volitelně do náhlavní soupravy nebo dodaného reproduktoru. Zpětně musí zajistit přenos ze vstupního mikrofonu (stolního a náhlavní soupravy) do PC, telefonu nebo radiostanice.

Pole musí mít konfigurovatelnou vstupně výstupní kombinaci s možností spojení (mixování) vstupních i výstupních zdrojů, a také ovladatelnou hlasitost volitelně pro jednotlivé vstupy i výstupy. Ovládání může být hardwarové nebo integrované do dotykové obrazovky pracovišť.

Na pracovišti lektora bude náhlavní souprava připojena k telefonnímu přístroji, systémové zvuky PC budou přehrávány přes dodané reproduktory a k PC bude také připojen samostatný mikrofon.

	Požadavek	Popis
HW 05	Audiopropojovací pole	Dodávka 2ks audiopropojovacích polí včetně ovládání nebo integrace

3.2.6 Vybavení simulované posádky

Posádka bude vybavena přenosným telefonem (viz. specifikace telefonie) a odolným notebookem

v minimální konfiguraci:

- zařízení 2 v 1 kategorie „fully rugged“ - notebook rozložitelný na tablet a klávesnici nebo notebook konvertibilní na tablet (překlopením, otočením) se zakrytím nebo vypnutím klávesnice v režimu tabletu

- požadováno je vytvoření pevného celku při spojení klávesnice a tabletu, aby vzniklo zařízení typu

„notebook/laptop“

- odolnost vůči vodě a prachu minimálně IP-65 podle normy MIL-STD-810G a IEC 60529

- odolnost vůči otřesům a volnému pádu podle normy MIL-STD-810G 516.6

- práce na baterie minimálně 7 hodin (i v rozloženém stavu)

- výkon procesoru musí umožňovat minimální průměrné skóre 3000 v benchmarku Passmark CPU Mark

- operační paměť minimálně 8GB

- pevný disk typu SSD minimálně velikosti 128GB

- podpora WIFI standardů 802.11 b/g/n

- hmotnost s bateriemi do 2.2 kg ve složeném stavu

- maximální tloušťka zavřeného notebooku nebo konvertibilního zařízení v režimu tablet 40mm

- 10-12.5" obrazovka MultiTouch (min. jas 800cd/m², min. rozlišení 1280x768)

- standardní HW klávesnice bez numerické části s českou lokalizací

- polohovací zařízení touchpad

- záruka pokrývající náhodné poškození zařízení

- operační systém kompatibilní s MZD a EKP

Na notebooku bude nahrána aplikace MZD i EKP a připojena na WIFI zadavatele a bude komunikovat se

serverovou částí.

	Požadavek	Popis
HW 06	Notebook posádky	Odolný notebook simulované posádky ve specifikované konfiguraci.

Obecné požadavky na SW řešení

3.3.1 Obecné požadavky

IS OŘ musí umožnit:

• zajištění podpory procesů OŘ,

• využití mapových a datových podkladů prostřednictvím volání služeb GIS,

• zjištění procesů posádky (MZD a EKP) včetně propojení s OŘ,

• integraci s dalšími systémy a technologiemi.

3.3.2 Společné požadavky na dodané systémy

• Veškeré sdílené číselníky všech systémů budou editovatelné v rámci aplikačního prostředí jednoho ze

systémů, samostatně editovatelné budou pouze číselníky specifické pro určitý ze systémů.

• Všechny aplikace, se kterými budou pracovat uživatelé, budou mít řešenu autentifikaci a to způsobem

kdy:

o autentifikace se bude provádět vůči jednotné vnitřní databázi uživatelů IS,

o systém musí umožnit autentifikaci vůči systému Active Directory zadavatele, pokud se zadavatel rozhodne v budoucnu systém do AD začlenit, a to ve všech aplikacích.

• Zabezpečení konkurenčního zpracování na všech úrovních (události, záznamy/výzvy, posádky apod.) – musí být implementováno zamykání položek, aby nedošlo k současné editaci několika uživateli.

• Odezvy systému na operace typu založení entity, předání posádce atd. musí být vykonány do max. 2

sekund od zahájení požadavku.

• Systém nebude napojen na národní systém příjmu tísňového volání, pouze budou simulovány datové vety tohoto systému, jak je specifikování v kapitole o simulovaném běhu.

Požadavky na systém OŘ ZZS

3.4.1 Licencování

Licence systému pro operační řízení musí pokrývat minimálně:

- instanci aplikačního serveru,

- minimálně 3 aktivní klienty operačního řízení všech druhů (klient OŘ, klient integrace radiostanic apod.),

- GIS serveru včetně mapových podkladů, minimálně 3 klienty GIS - licence GIS serveru není nutně vyžadována, pokud systém umožní veškeré funkcionality požadované v zadání provádět v prostředí klienta (ať už GIS nebo OŘ) a to nad sdílenými daty umístěnými na serveru s definovaným požadavkem na odezvu,

- licence na potřebné databáze a další přidružené systémy,

- licence musí být dodány jako přenositelné.

3.4.2 Systém operačního řízení a jeho integrace

• Systém musí umožnit simulovaný příjem tísňového volání:

- přijetí hovoru operátorem ve skupině aktuálně přihlášených call takerů

- založení události automaticky na „zvednutí sluchátka“ a její vytěžení,

- předání informací o výzvě k operačnímu řízení

• Operační řízení.

- rajonizace události a doporučení VS, která má výzvu řešit (systém nabízí náhled na výjezdové skupiny,

jejich stav)

(1) rajonizace na základě místopisu definované vazbou posádky na kódy místopisných prvků RUIAN

(2) s ohledem na vytížení jednotlivých VS v průběhu směny

- předání výzvy simulované výjezdové skupině

- monitoring řešení událostí pomocí systémů statusů do doby ukončení posledního výjezdu k události

- editace složení výjezdových skupin

Integrace na ostatní systémy v rámci IS ZZS

- GIS

- RÚIAN

- Simulovaná datová věta předávání událostí

- Telefonní ústředna

- Radiokomunikace

Požadavky na funkcionality systému operačního řízení

	Požadavek	Popis
	Příjem tísňové výzvy
OŘ 01	Příjem a zpracování TV, založení události	Systém umožní přijetí hovoru na jednom z dispečerských pracovišť podle zvolené role uživatele (role calltaker). Systém umožní přijmout TV z těchto zdrojů tísňového volání: • Přímý příjem hovorů tísňového volání přes dodanou ústřednu, možnost přepojení nebo konference • příjem tísňových SMS • příjem událostí přes datovou větu simulovaného prostředí NSPTV včetně vytěžení dat z datové věty a přenesení do události Zpracování telefonické výzvy v OŘ • Při příchodu tel. hovoru na pracoviště calltakera se zobrazí v dispečerské aplikaci informace o volajícím (telefonní číslo volajícího) • Bude rovněž k dispozici informace, zda z tohoto tel. čísla byly již nějaké události ohlášeny • Při vyzvednutí hovoru bude automaticky založena nová událost
OŘ 02	Zpracování datových vět	• Systém musí zajistit příjem datové věty (DV) ze systému simulujícího NIS IZS a vytěžení všech podstatných informací v rámci události. Seznam atributů, které systém přebírá ze systému NIS IZS je dán specifikací DV systému NIS IZS.

• K již existujícím událostem musí být možné vytěžit změnovou DV (ZDV) se zobrazením rozdílů, které DV obsahuje ve srovnání s informacemi již uloženými u události a s možností vybrat, která data ze ZDV zapracovat k události a která data si dispečer nepřeje přebrat.

• Přijetí DV z NIS IZS musí být dispečerovi neblokujícím, ale dostatečně výrazným upozorněním signalizováno, aby operátor nebyl nucen kvůli potvrzení příjmu DV přerušovat prováděnou činnost, ale aby nemohl příjem DV nebo ZDV přehlédnout. Tato notifikace musí být jednak vizuální v rámci grafického rozhraní dispečerské aplikace a dále akustická na základě administrátorem systému konfigurovatelné zvukové znělky.

• Při příjmu DV nebo ZDV musí být přijaté informace prezentovány v přidružené klientské GIS aplikaci

OŘ 03

Lokalizace události

Bude provedena lokalizace simulované události, pokud není možné určit přesné místo události, tak i popisem místa, jinak pomocí GIS klienta nebo výběrem z místopisného helperu v kombinaci s fulltext vyhledáváním:

• Možnost filtrů určitý místopisný okruh, např. na konkrétní kraj

• Je možné hledat různé kombinace např. "obec, ulice", jednotlivé výrazy se oddělují čárkou a postačí zadání jen jejich části např. "ost, cihe" najde ulici Cihelní v Ostravě

• Za název obce nebo ulice je možné mezerou oddělené zadat číslo popisné nebo orientační, např. "ost, cihe 14"najde číslo popisné 14 v ulici Cihelní v Ostravě

• Výsledky, které odpovídají hledanému řetězci, jsou zobrazeny v místopisném helperu, kde je možné jeden ze záznamů vybrat, zároveň jsou po označení vizualizovány i v GIS klientovi

• Hledání je vždy omezeno podle již vybrané úrovně adresy, např. pokud mám již vybránu obec Opava, veškeré hledání se mi omezí pouze na katastr této obce.

• Jednotlivé úrovně adresy je možné jedním kliknutím odstranit

• Je možné lokalizovat událost také zadáním souřadnic ve formátu

WGS-84

• Historie případů na této adrese - na základě dotazu na databázi uzavřených událostí indikuje vizuálně (například barevným zvýraznění, orámováním, doplňujícím textem) podle adresy, zda už na této adrese nějaké události byly nebo aktuálně jsou a případně umožní náhled na tyto události výběrem ze seznamu takových událostí

• Možnost vedení vlastní databáze POI včetně kategorií s přiřazenou adresou a souřadnicí. Tyto body budou nabízeny jak při standardním hledání přes vyhledání adresy, tak i fulltextovým hledáním názvu POI.

OŘ 04

Vytěžení události

Možnost evidovat k události tyto atributy:

• Číslo volajícího

• Jméno volajícího

• Telefonní číslo + překlad na jméno, pokud je v systému k dispozici

• Lokalita volajícího/události

- z DV z NSPTV

- další dostupné zdroje takové informace

události ohlášeny (nebo aktuálně probíhají) a případně

		umožní náhled na tyto události výběrem ze seznamu takových událostí - Možnost zadat "volání z 3. ruky" - tímto příznakem se aktivuje pole pro zadání druhého tel.čísla jako čísla na místo události. - Možnost přímo vytočit hovor jako "zpětné volání" na číslo volajícího • Klasifikace charakteru události • Popis události • Poznámka k události • Indikace - dvouúrovňová a vztahuje se k pacientovi - při nabírání případu se bude vytěžovat pouze jedna indikace a předpokládaný počet pacientů • Informace, zda byla poskytnuta telefonicky asistovaná resuscitace či telefonicky asistovaná první pomoc či jiné příznaky uživatelsky definovatelné • Spolupracující složky IZS: - Možnost zaznačit a předat systému ZD spolupracující složky IZS • Informace k pacientům události: - Jméno pacienta - Přibližný věk nebo ročník narození - Pohlaví - Stupeň naléhavosti z definovatelného číselníku naléhavostí • Navržený typ sil a prostředků z definovatelného číselníku SaP včetně příslušného počtu navržených posádek • Ochrana zadaných informací dle definovaných pravidel (zamezení pozdějších změn indikace, charakteru atp.
OŘ 05	Založení a předání záznamu k výjezdu	Z vytěžených informací o pacientovi bude automaticky při založení události založen záznam k výjezdu, který dispečer může zpracovat jako: • Vyřešený jinou cestou (viz. Ukončení výzev operátorem) • Předaný do fronty pro operační řízení Calltaker může založit případně další záznamy k výjezdu k dané události a opět je předat do fronty pro operační řízení.
OŘ 06	Objednávky sekundárních transportů	Příjem a zpracování objednávky sekundárních transportů. Vytěžení bude obdobné jako u tísňového volání.
	Operační řízení
OŘ 07	Vizualizace výzev ve frontě	Výzvy, které budou calltakerem předány k dalšímu řešení do systému OŘ, budou řazeny do fronty. Fronta záznamů k výjezdu bude řazena dle definovatelného řazení (např. stupně naléhavosti a času založení), stupeň naléhavosti bude odlišen ještě i vizuálně. Ve frontě je jasně viditelná lokalita události, naléhavost, indikace, charakter, informace o pacientovi (příjmení, jméno, věk) a další známé sledované hodnoty. Aplikace umožní náhled na výzvy v těchto frontách: • Výzvy urgentní • Plánované výzvy • Probíhající výzvy • Ukončené výzvy • Celkový přehled výzev Plánované výzvy - doplní se datum a čas, na kdy je případ plánován a vloží se do seznamu plánovaných případů. Ostatní dispečeři nemusí informaci o vzniku takové události nijak výrazně notifikovat, pouze ji musí

		být aplikace na ostatních pracovištích schopny dále zpracovávat (musí o ní tedy "vědět"). V čase, na který je výzva naplánována, dojde k upozornění operátora (ad popis níže). Výzvy urgentní - standardní postup, kdy se případ předá ke zpracování operátorem ZZS, operátor je okamžitě upozorněn. V obou případech, plánované výzvy i výzvy urgentní, musí dojít k výraznému, ale neblokujícímu upozornění, aby dispečer ZZS nebyl nucen kvůli potvrzení příjmu této informace přerušovat prováděnou činnost, ale aby nemohl tuto informaci přehlédnout. Tato notifikace musí být jednak vizuální v rámci grafického rozhraní dispečerské aplikace a dále akustická na základě administrátorem systému konfigurovatelné zvukové znělky a to tak dlouho, dokud není případ některým z operátorů převzat k následnému zpracování. Zajistit, aby v aktuální chvíli převzal k řešení čekající záznam pouze jediný dispečer a nemohlo dojít k zaslání více výzev nad jedním záznamem.
OŘ 08	Ukončení výzev operátorem	Simulovaně předat případ - předá se k řešení jiné složce IZS, ZZS v jiném kraji, LSPP apod. V dialogu se řeší, komu / jak byl případ předán. Předáním se případ uzavře (událost ukončí). Číselník cílových adresátů předání musí být volně konfigurovatelný. Stornovat případ – řešení záznamů ve frontě je možné bez řešení stornovat. V tom případě je však nutné vést přesný přehled o uživateli a důvodu této operace.
OŘ 09	Sekundární převozy pacientů	U těchto záznamů bude ve frontě viditelný čas a datum, na který je převoz požadován. Aktivní upozornění systémem na nutnost řešení čekajícího záznamu výjezdu. Číselník zařízení pro sekundární převozy bude spravován na straně IS ZD ZZS a stranou IS OŘ bude synchronizován, včetně jejich adres a souřadnic. Sekundární transporty, stejně jako primární podléhají rajonizaci, a to jak podle předdefinované rajoinzace, tak i podle nejbližší dostupné posádky.
OŘ 10	Vizualizace přihlášených posádek a jejich stavu	K přihlášeným posádkám bude dispečer mít dostupné informace k jejich typu (RLP, RZP, RV, LZS – typ posádky je v přehledu graficky odlišen), názvu, aktuálnímu statusu a vytížení v rámci směny dané posádky. Aplikace nabízí rovněž přehledový panel posádek s těmito vlastnostmi: • Jde o okno, které zobrazuje ve volitelných pozicích jednotlivé posádky a jejich aktuální stav. • Toto okno je plně uživatelsky (administrátorem systému) konfigurovatelné • Z okna je možné přímo kontaktovat posádku (telefon - přímé vytočení hovoru, rádio - zaklíčování na dotykovém panelu na správném kanálu, otevření příposlechu, odeslání vybrané sel. volby. • Je možné se proklikem rovnou dostat na událost, u které posádka zasahuje. • Dostupné jsou různé informace o posádce - aktuální stav posádky. • Ikony nebo jiné grafické odlišení pro jednotlivé stavy a pro jednotlivé posádky jsou konfigurovatelné administrátorem systému.

		• Je třeba, aby bylo možné změnit stav posádky na všechny dostupné stavy, které jsou v číselníku, při dodržení logických souvislostí (např. nelze nastavit stav "na cestě k události" bez vazby na událost, vazba na událost je v takových případech nezbytnou podmínkou)
OŘ 11	Rajonizace, výběr SaP	Systém bude umožňovat na základě vazeb místopisných entit na jednotlivá stanoviště (vazba přes kódy RÚIAN) z místopisu v záznamu navrhnout dispečerovi ve vazbě na navržený typ SaP vhodné výjezdové skupiny s deklarovanou prioritou. Systém umožňuje deklarovat rajonizaci pomocí kódů místopisných entit: • Ulice • Část obce • Obec a přiřadit k nim množinu výjezdových skupin s vazbou na typ dané skupiny, které jsou řazeny pomocí určené priority, volitelně s vazbou na jejich akceschopnost. Na základě adresy případu bude možné provést jednak určení místně příslušného stanoviště a podle předběžného počtu SaP z okna zadání nové události bude proveden automatický výběr posádek, které by měly být přednostně vyslány k případu, včetně vizualizace v GIS klientovi.
OŘ 12	Aktivace simulované posádky	Při aktivaci posádky dispečerem dojde k předání výzvy na pracoviště výjezdového stanoviště a provedení minimálně těchto akcí: • Telefonní výzva na primární telefon • Telefonní výzva na mobilní (sekundární) telefon • Selektivní volání na ruční analogovou radiostanici posádky • Předání záznamu systému zdravotnické dokumentace, který ji dále předá mobilnímu řešení Musí být možné zvolit si sadu akcí pro provedení při výzvě, kdy je posádka na stanovišti a kdy je na výjezdu ve vozidle. Výběr typu aktivace (zda do vozidla nebo na stanoviště) je na dispečerovi.
OŘ 13	Statusy posádek a polohy SaP	Systém bude umožňovat evidenci těchto stavů posádek: 0 - technická pauza 1 - výjezd 2 - příjezd na místo události 3 - odjezd z místa události 4 - příjezd ke zdrav. zařízení 5 - zahájení návratu 6 - příjezd na základnu 7 - konec akce 8 - mimo provoz 9 - stav nouze
OŘ 14	Změny statusů	Aktualizace stavů bude probíhat: • Datovou cestou z MZD • Cestou zpracování statusů z radiostanice posádky • Manuálním zásahem dispečera v rámci dispečerské aplikace Na základě změny stavu záznamu dojde ke změně stavu události.
OŘ 15	Stavy události	Rozlišovat tyto stavy událostí. 1. událost jiné složky bez schválení ZOS – příchozí událost jiné složky čekající na vyřízení, událost v takovém stavu je call takerovi signalizována 2. událost platná schválená – událost zpracovávaná nebo zpracovaná a čekající

		3. událost platná schválená s požadavkem – událost s alespoň jedním čekajícím záznamem/výzvou 4. událost předaná k řešení posádkám (po výzvě) - událost s alespoň jedním záznamem/výzvou po výzvě 5. událost posádka na místě – událost s alespoň jednou posádkou se statusem minimálně 2 6. událost vyřešená předáním – událost neřešena ZZS, pouze předala jiné složce 7. událost vyřešená – událost s ukončeným řešením 8. událost zrušená – událost neřešená Aplikace umožní náhled na události v těchto frontách: • Události čekající na zpracování • Události aktivně řešené • Události ukončené
OŘ 16	Správa posádek	Posádky bude možné deklarovat dispečerem v rámci dispečerského programu a zároveň bude složení posádek zasíláno systémem zdravotnické dokumentace přes dohodnuté rozhraní, kde složení deklarují posádky. Deklarace posádek bude sestávat z: • Výjezdové skupiny - s deklarovaným názvem - přiřazeným stanovištěm s určenou oblastí/okresem - telefonním číslem linky pro předávání výjezdů - telefonním číslem mobilního telefonu - volacím znakem analogové radiostanice • Vozidlem - s deklarovaným popisem - volacím znakem vozidlové analogové radiostanice • členů posádky ve složení - lékař - NLZP - Řidič - NZP/ostatní
OŘ 17	Správa číselníků	Správa sdílených číselníků bude prováděna v jednom ze systémů pro všechny systémy společně. Specifické číselníky budou spravovány v rámci určité aplikace. Veškerá správa číselníků musí být ošetřena přístupovými právy.
	Integrace
OŘ 18	Systém zdravotnické dokumentace	Oboustranné napojení na systém zdravotnické dokumentace. Seznam minimálního rozsahu přenášených položek je deklarován v Příloze 2. Kromě oboustranného přenosu informací o výjezdu, bude navíc přenášeno obousměrně složení posádek (na dotaz ZD je získáno aktuální složení, ZD zasílá složení nové) a také jednosměrně ZD bude zasílat statusy získané ze systému mobilního řešení.
OŘ 19	Simulovaný systém sledování provozu vozidel	Simulované zasílání souřadnic vozidel do systému u všech přihlášených posádek. Zobrazení vozidel včetně statusu
OŘ 20	GIS klient	• GIS klient -> OŘ:

		- Převzetí souřadnic a místopisu do systému OŘ na základě manuální lokalizace polohy událostí • OŘ-> GIS klient: - Zobrazení simulovaných poloh vozidel a jejich statusů - Zobrazení místa probíhajících událostí včetně grafického symbolu události - Zobrazení události a záznamu na základě požadavku dispečera - Provázání místopisu OŘ na GIS klienta
OŘ 21	RÚIAN	Lokalizace události bude využívat data registru adres RÚIAN
OŘ 22	Telefonní ústředna integrace telefonie	V rámci integrace telefonní ústředny bude zajištěno: • Předání informace o čísle volajícího systému OŘ • Vyvolání telefonu výjezdové skupiny definované pevnou linkou a mobilním číslem, a to jak při výzvě, tak kdykoliv zvolením definované posádky v přehledu a volbou typu telefonního spojení
OŘ 39	First responder	Simulovaný systémem First responderů v rozsahu: - automatický výběr událostí vhodných pro nasazení FR (na základě podmínek na bázi naléhavosti a indikace) - získání informace o oslovených FR simulovaného prostředí FR - získání informace o FR, kteří se do akce zapojili, včetně kontaktních údajů - vizualizace FR oslovených i zapojených v rámci GIS s definovanou anonymizací (skrytí identifikace nezúčastněných responderů)
OŘ 41	Urgentní výzva	Aplikace musí umožnit odeslání „Urgentní výzvy“, tedy „výzvy k výjezdu“ před získáním všech informací od volajícího a to na „jedno tlačítko“. Systém po nabrání adresy místa zásahu vygeneruje událost s předdefinovanou Indikací a Naléhavostí, která je okamžitě předána dispečerským pracovištím k vyslání posádky.
OŘ 42	Metronom	Za účelem korektního poskytování TANR, musí aplikace umožňovat spuštění vizuální a akustické podpory, kdy je v definované frekvenci znázorněn korektní interval pro provádění nepřímé masáže srdce.

3.4.3 Podpora výjezdových skupin

Informační systém musí zajistit na pracovištích výjezdových skupin minimálně tyto procesy:

• Příjem výzvy k výjezdu na výjezdovém stanovišti

Požadavek

Popis

VS 01

Předání výzvy

k výjezdu

Předání výzvy k výjezdu bude sestávat z následujících kroků:

• Předání výzvy do systému zdravotnické dokumentace a následně do systému mobilního řešení pro zpracování zdravotnické dokumentace, včetně její případné aktualizace

• Počet výjezdových skupin nebude omezen

3.4.4 Integrace telefonie a radiofonie

Klientská aplikace ovládání rádií bude:

• integrována do prostředí touchscreen, tedy musí splňovat integrační požadavek na běh aplikace v rámci prostředí touchscreenu

• musí umožnit jednoduché ovládání v prostředí dotykového monitoru, tedy veškeré ovládací prvky musí být dostatečně velké a logika ovládání musí zjednodušovat maximálně práci operátora (např. při zaklíčování

otevřít příposlech kanálu, signalizovat jasně příchozí volání včetně volacího znaku volajícího, kanálu na

kterém volá apod., možnost práce volitelně v otevřeném a uzavřeném režimu atp.)

• nabízet funkce pro integraci do IS tak, aby spolu s IS tvořil funkční celek a byly splněny všechny požadavky na funkčnost IS ve vztahu k radiostanicím

• zvukový výstup a vstup musí být realizován přes vstup a výstup audiopropojovacího pole

	Požadavek	Popis
INT 01	Analogová stanice	Integrace na systém OŘ musí umožnit selektivní volbu radiostanice posádky na základě výzvy posádce a také přes volbu na panelu posádek.
INT 02	Telefonie	Systém předávání hovorů musí zohlednit tyto stavy dispečera: • není přihlášen (není dostupný) • má hovor (nesmí mu být přepojen hovor, je ve stavu zaneprázdněn) • volný • aplikace IS OŘ je spuštěna, je možno zahájit příjem TV (zrušení stavu zaneprázdněn) • pracovník má aktuálně rozpracovanou událost, která ještě nebyla předána do IS OŘ, je tedy nutné pozdržet příjem dalšího volání (do předání události je pracovník ve stavu zaneprázdněn).
INT 03	Nahrávání telefonie	Integrace musí umožnit provázání události se záznamem a umožnit přehrání, nebo alespoň výběr přidruženého hovoru v externí aplikace přímo ze systému OŘ.

Požadavky na systém MZD a EKP ZZS

Je požadována dodávka systému mobilního zadávání dat simulované posádky na dodaném notebooku a dodávka elektronické karty pacienta pro stacionární zpracování dat. Obě aplikace budou pro zjednodušení provozovány na notebooku posádky, který je také předmětem dodávky.

3.5.1 Společné funkcionality EKP a MZD

- Přenos informací o výjezdu ze systému OŘ,

- využití společných číselníků s IS OŘ včetně společné autentizace, a to i vůči Active Directory,

- omezení přístupu k záznamům na výjezdy kde je přihlášený členem posádky,

- vygenerování a tisk dokumentace minimálně v rozsahu Přílohy 3,

- přenos dokumentace k dalšímu zpracování na server pro zpracování v rámci EKP a účely statistiky a předání zpět do OŘ,

- plnohodnotná licence serverové i klientské části minimálně pro dvě zařízení,

- generování a tisk podpůrné dokumentace výjezdu včetně zajištění přenosu jejich dat na server, minimálně:

• vyúčtování výjezdu,

• negativního reverzu,

• iktové karty,

• protokolu KPR.

	Požadavek	Popis
ZD 01	Dodávka MZD a EKP	Dodávka MZD a EKP

3.5.2 Specifické požadavky na MZD

- Možnost off-line zpracování bez datové konektivity po načtení informací k výjezdu,

- získání lokalizačních informací a mapy místa zásahu s vyznačením místa události,

- ovládání aplikace je řešeno jako maximálně přehledně a intuitivní za účelem co nejvyšší možné rychlosti zpracování,

- vygenerování dokumentace do PDF nebo libovolné tiskárny,

- klientskou aplikaci musí být možné provozovat i na libovolném jiném zařízení, než bude dodáno v rámci dodávky a musí být možné ji provozovat také na zařízení pouze s klávesnicí bez dotykového displaye, nebo na tabletu bez klávesnice.

	Požadavek	Popis
ZD 02	Požadavky na MZD	Specifické požadavky na mobilní zadávání dat

3.5.3 Specifické požadavky na EKP

Aplikace pro stacionární zpracování zdravotnické dokumentace a podpory posádek musí zpracovávat minimálně stejný rozsah jako MZD a musí s MZD úzce spolupracovat. Data pořízená v MZD musí být automaticky přenesena do EKP a dále do systému OŘ.

Krom modulu pro zpracování dokumentace musí být součástí dodávky také:

- modul pro sestavení posádky v rámci OŘ ze strany členů posádky (posádka na začátku směny zapíše do systému OŘ sestavení posádky včetně vozidla,

- modul přístrojů – simulované evidence přístrojové techniky s možností přiřazení posádce při přihlášení,

- modul pro správu číselníků a uživatelů s vazbou na OŘ,

- statistické výstupy pro simulovaný statistický výstup nad vloženými daty.

	Požadavek	Popis
ZD 03	Požadavky na EKP	Dodávka systému EKP včetně specifikovaných modulů.

Simulace prostředí operačního střediska

Jelikož simulované operační středisko nebude přijímat reálné hovory ani nebude napojeno na NIS IZS pro příjem reálných datových vět, je třeba vytvořit simulované prostředí, které bude vytvářet vstupní informace jako podklad pro rozhodování dispečerů. Ty budou buď vytvářeny lektorem, ať už telefonním hovorem na vstupní GSM bránu nebo vytvořením datové věty a zároveň je třeba vytvořit aplikace, které umožní ze zásobníku předat hovor nebo datovou větu xxxxxxxxxxxx ve výcviku.

Požadavek

Popis

SP 01

Hovor na vstupní GSM

bránu

Hovor na vstupní GSM bránu bude směrován na studenta přihlášeného v

režimu calltakera.

SP 02

Manuální odeslání datové věty

Lektor bude mít prostředek pro manuální vytvoření a odeslání

simulované datové věty, která bude calltakerům avizována jako nová událost, včetně možnosti následné aktualizace a odeslání datové věty změnové.

Datová věta může vzniknout v samostatném formuláři nebo založením události v prostředí systému OŘ a odesláním v režimu simulace příjmu „z

jiného dispečinku“.

SP 03

Předání zvukové nahrávky

Lektor bude mít k dispozici knihovnu nahrávek, které bude mít možnost zaslat na pracoviště calltakera. Optimální je přehrát nahrávku do

telefonního přístroje calltakera, povoleno je ale i řešení přehrání

zvukového souboru v počítači na kterém bude calltaker přihlášen. Oba režimy musí umožnit tento proces spustit lektorem vzdáleně v době požadavku lektora na spuštění.

SP 04

Předání datové věty z

knihovny

Lektor bude mít k dispozici knihovnu datových vět, které bude mít možnost zaslat na pracoviště calltakera v libovolném čase. Systém umožní také zaslání jiné datově věty z knihovny jako změnové k již

zaslané.

SP 05

Simulace režimu FR

Systém bude simulovat náhodně pohyb responderů a zobrazovat jejich pohyb v mapě. V případě, že se responder vyskytne v definovaném okolí události, bude automaticky do akce zapojen, pokud událost splní

podmínky pro zapojení responderů. Případný chat s responderem bude

veden na pult lektora.

Požadavky na testovací provoz, dokumentaci a rozsah školení

3.7.1 Dokumentace a testování

• Délka testovacího provozu bude 10 dní.

• Při převzetí bude dodána dokumentace systému v rozsahu:

o Popis funkčnosti zařízení a systémů z pohledu uživatele tak, aby byl uživatel schopen práce s předmětem plnění. Pokud je předmět plnění integrován s jiným systémem, dokumentace bude obsahovat i popis napojení předmětu plnění na další systém v rozsahu nezbytném z hlediska práce uživatele.

o Popis předmětu plnění z hlediska jeho zapojení do stávající infrastruktury a informačního systému (rozhraní a služby), včetně popisu jeho správy, údržby.

o Popis administrativních úloh a možných nastavení systému.

o Zápisy z jednání

3.7.2 Školení

Dodavatel zajistí školení pracovníků zadavatele. Cílem je, aby pracovníci uživatele byli seznámeni s jednotlivými částmi projektu a naučili se s nimi pracovat. Délku školení určí zadavatel po shlédnutí složitosti systému, maximální délky však budou:

školení uživatelů pro 5 účastníků v rozsahu max. 1 den

školení administrátorů v max. rozsahu 4 hod.

Veškeré náklady na zajištění školení musí být zahrnuty v ceně odpovídající části předmětu plnění.

Odezva a kapacita systému

Výkon dodaného hardware v kombinaci se softwarovým řešením musí zajišťovat dostatečnou odezvu systému, kdy reakce systému na základní operace (založení události, odeslání výzvy, uložení složení posádky atp.) nesmí přesáhnout 2 sekundy. Zároveň kapacita databáze musí vystačit na dobu udržitelnosti projektu při max. očekáváném počtu výjezdu 10 tis. ročně. Kapacita pro záznam hovorů musí být minimálně 500GB.

Záruční a servisní podmínky

Veškeré komponenty systému budou dodány se zárukou v délce udržitelnosti projektu, která je 5 let, která započne po finálním předání projektu, tedy ukončením zkušebního provozu.

Serverová část, telefonní ústředna, pracovní stanice a notebook posádky budou dodány se zárukou v režimu zahájení řešení následující pracovní den po nahlášení problému dodavateli. Ostatní HW komponenty (náhlavní soupravy, telefonní přístroje apod.) budou dodány v režimu opravy do 30ti dnů se zapůjčením náhradního zařízení obdobné konfigurace dodavatelem po dobu opravy. Notebook posádky bude dodán také se zárukou pokrývající náhodné rozbití.

Softwarové komponenty budou mít záruku ve dvou režimech:

- kompletní nefunkčnost, byť i některé komponenty systému zabraňující zcela práci všech uživatelů odstraní dodavatel nejpozději do 48 hodin od nahlášení problému,

- ostatní chyby a nesoulad se zadávací dokumentací odstraní zadavatel nejpozději do 14ti dnů od nahlášení dodavatelem.

Příloha č.2 – Podrobná technická specifikace nabízeného plnění

1. Definice pojmů a zkratek

Zadavatelem veřejné zakázky je Ostravská univerzita, Lékařská fakulta (dále jen Zadavatel nebo Uživatel).

1.1 Použité zkratky

FR First responder

HW Hardware

IZS Integrovaný záchranný systém

IS ZD ZZS Informační systém zdravotnické dokumentace ZZS

KZOS Krajské zdravotnické operační středisko

NIS IZS Národní informační systém IZS

OŘ Operační řízení

SaP Síly a prostředky ZZS

SW Software

ZD Zdravotnická dokumentace

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

ZZ Zdravotnické zařízení

MZD Mobilní zadávání dat – zpracování ZD na notebooku/tabletu ve vozidle

EKP Elektronická karta pacienta – zpracování ZD na stacionárním PC posádky

2. Předmět specifikace

Předmětem je dodávka simulovaného prostředí sestávající z potřebného HW, informačního systému

operačního řízení ZZS, integrovaných prostředků radiové komunikace, telefonního systému a vybavení posádky.

Cílem je vytvořit pracoviště co nejvěrněji simulující činnost operačního střediska, včetně navázaných technologií a spolupráce s posádkou ZZS v terénu, tedy také simulované „pracoviště“ posádky.

Součástí předmětu veřejné zakázky je doprava dispečerského systému na místo plnění vč. vykládky,

manipulace, kompletní montáže a ustavení na místo určené zadavatelem, uvedení zařízení a všech jeho

součástí do plnohodnotného provozu, zaškolení pověřených pracovníků, popis funkčnosti zařízení a systémů z pohledu uživatele tak, aby byl uživatel schopen práce s předmětem plnění (pokud je předmět plnění integrován s jiným systémem, bude dokumentace obsahovat i popis napojení předmětu plnění na další systém v rozsahu nezbytném z hlediska práce uživatele), popis předmětu plnění z hlediska jeho zapojení do stávající

infrastruktury a informačního systému (rozhraní a služby) včetně popisu jeho správy a údržby a popis administrativních úloh a možných nastavení systému. Všechny uvedené doklady budou v českém jazyce v tištěné nebo elektronické podobě.

Nabízený systém odpovídá níže uvedené specifikaci, platnému legislativnímu rámci a podporuje veškeré

procesy operačního řízení ZZS ve všech typech činností (je příjem tísňových výzev a datových zpráv, podporu odborné přednemocniční neodkladné péče, setkávacího systému, PPNP, TANR, TAPP, systém First responder v simulovaném režimu apod.). Aktuálně je pátým rokem provozován pro Zdravotnickou záchrannou službu Středočeského kraje a pro Zdravotnickou záchrannou službu Jihočeského kraje a od počátku roku 2021 i na ZZS Olomouckého kraje.

Uchazeč je autorem zdrojových kódů nabízeného systému a disponuje jimi. Je tedy schopen provádět support operačního systému, tzn. modifikovat zdrojový kód a dodávat nové verze systému po celou dobu podpory, ať už za účelem provádění oprav případných incidentů, doplnění nových vlastností z důvodu legislativních změn, nebo doplnění funkcí na základě objednávky Zadavatele.

Uchazeč je vlastníkem autorských práv nabízeného systému.

Uchazeč bere na vědomí, že stávající rozsah funkcionalit IS OŘ je nepodkročitelný.

3. Specifikace předmětu plnění

V případě nedostupnosti níže nabídnutých technologií zařízení či komponent, z důvodů ležících na straně výrobce, nebo distributora, si uchazeč vyhrazuje právo dodat obdobná zařízení, technologie či komponenty s minimálně stejnými vlastnostmi, jaké má nabídnuté řešení.

3.1 Architektura řešení

Předmětem dodávky je integrované řešení systému operačního řízení (dále jen OŘ) včetně prostředí GIS, tří

dispečerských pracovišť (calltakera, dispečera a lektora), informačního systému pro zdravotnickou dokumentaci (dále jen ZD), složený z mobilního zadávání dat (dále jen MZD) a stacionárního zpracování zdravotnické

dokumentace (elektronické karty pacienta), dále jen EKP.

3.2 Hardwarové komponenty systému

3.2.1 Server(y)

- Požadavek zadavatele

- celkový průměrný výkon všech CPU dohromady min. 25 000 bodů v Passmark CPU Mark

- 64 GB ECC operační paměti

- 4 HDD v RAID 5 o minimálním výkonu 200 IOPS

- v rackovém provedení o maximální výšce každého serveru 2U

Servery budou umístěny v technologické místnosti v rackové skříni zadavatele a připojeny redundantně metalickým kabelem o rychlostí 1Gbps k přepínači zadavatele.

Navržené serverové řešení musí umožňovat dosažení odezvy a kapacity definované v kapitole „Odezva a kapacita systému“.

Požadavek

Popis

HW 01

Dodávka serverového

prostředí

Dodávka jednoho nebo více serverů dostatečného výkonu

včetně

- Popis nabízeného ỉešení:

Jako server pro chod aplikací a SW nabízíme dodat HPE ProLiant DL380 Gen10 8SFF.

- Server HPE ProLiant DL380 Gen10 využívá špičkové technologie a tak nabízí zvýšenou flexibilitu a

výkon pro různé aplikace a použití, výkonný 2socketový Rack 2U server pro virtualizaci, databáze nebo vysoce výkonné výpočty v oblasti firemní sféry.

- Processor(s): 2x Intel Xeon-S 4215R (2.1GHz/16-core/100W). 16 core je součet core obou procesorů.

- Memory: 8x HPE 32GB (1x32GB) Dual Rank x4 DDR4-2933

- 6x HPE 1.2TB SAS 12G Mission Critical 10K SFF SC

- Controller: HPE Smart Array P408i-a SR Gen10 (8 Internal Lanes/2GB Cache) 12G SAS Modular Controller

- Power Supply: 2x HPE 800W Flex Slot Platinum Hot Plug Low Halogen Power Supply Kit.

Nabízený SW:

Popis/název	ks
Windows Server 2019 Datacenter Core - 16 Core License Pack	1
SQL Server 2019 Standard Core - 2 Core License Pack	4
Windows Server 2019 Client Access License - 1 Device CAL	5
Academic VMware vSphere 7 Essentials Kit for 3 hosts (Max 2 processors per host)	1

3.2.2 Pracovní stanice

- Požadavek zadavatele

Klientské pracovní stanice budou umístěny v dispečerských stolech simulovaného pracoviště calltakera,

dispečera a lektora. Pracoviště calltakera a dispečera budou shodná PC v provedení microtower nebo SFF v minimální konfiguraci:

- 1 CPU o minimálním průměrném výkonu 10 000 bodů v Passmark CPU Mark

- 16GB RAM

- SSD HDD o minimální kapacitě 240GB

- dedikovaná grafická karta pro potřebný počet monitorů

- 3x min. 27“ monitor s rozlišením 4K

- min. 17“ dotyková obrazovka pro provoz integrovaných technologií

- operační systém vyžadovaný aplikacemi

- klávesnice, myš

PC lektora pak bude v konfiguraci:

- 1 CPU o minimálním průměrném výkonu 10 000 bodů v Passmark CPU Mark

- 16GB RAM

- SSD HDD o minimální kapacitě 500GB

- dedikovaná grafická karta pro potřebný počet monitorů

- 2x min. 27“ monitor s rozlišením 4K

- operační systém vyžadovaný aplikacemi

- klávesnice, myš

PC budou připojena v technologické místnosti do přepínače zadavatele pomocí strukturované kabeláže budovy a to metalickým kabelem o rychlosti 1Gbps (dodávka kabelů do 10m).

Požadavek

Popis

HW 02

Dodávka pracovních stanic

Dodávka 3x pracovní stanic, 8x monitor, 2x touch screen,

včetně OS.

- Popis nabízeného ỉešení

1) Pracoviště calltakera a dispečera (celkem dvě shodná pracoviště)

PC: Jako PC nabízíme dodat 2 ks stanic HP ProDesk 600 G6 MT i5-10500/8GB/256SD/DVD/W10P 2xDisplayPort+VGA, HP 8GB DDR4-3200 DIMM SFF/ MT G6/ 7, HP AMD Radeon PRO WX 3200 4GB 4xmDP

+ 2x redukce na DP.

Tento model počítače HP ProDesk 600 G6 MT je vybaven 6jádrovým procesorem Intel Core i5-10500, který disponuje technologií HyperThreading pro plynulejší multitasking se schopností zpracovat až 2 procesy současně na jedno jádro a pracuje na frekvenci 3.1 GHz, nebo až 4.5 GHz v režimu turbo. Obrazový výstup zajistí grafická karta Intel UHD Graphics s výstupy 2x DisplayPort a HDMI. Integrována je zvuková karta a gigabitová síťová karta. Pro připojení externích periferií či jiných zařízení se nabízí dostatek USB portů (2x USB 2.0, 5x USB 3.0/3.1/3.2 Gen 1, 2x USB 3.1/3.2 Gen 2 a USB Type-C 3.1/3.2 Gen 2) a audio konektory. Počítač je dodáván s operačním systémem Windows 10 Pro. Balení obsahuje také USB klávesnici a myš.

Monitory 27“: Pro potřeby pracovišť nabízíme dodat 6 ks monitorů LG 27UL500-W - LED monitor 27" s následujícími parametry: 27“ monitor s rozlišením UHD (3840 x 2160 px). IPS displej. Technologie Radeon FreeSync, NVIDIA G-Sync, obnovovací frekvence 60 Hz a doba odezvy 5 ms. Omezení blikání monitoru, HDR10. Jas 300 cd/m2. Pozorovací úhly 178° horizontálně i vertikálně. Konektory HDMI, DP. VESA 100 x 100. Elegantní stojan.

Typ Monitoru	herní, kancelářské
Úhlopříčka v palcích	27 "
Typ panelu	IPS
Nativní rozlišení	3840x2160 (4K UHD)
Rozteč bodů	0.155 mm
Poměr stran	16:9
Reálný kontrast	1.000:1
Jas (cd / m²)	300
Pozorovací úhel	178 / 178

Doba odezvy	5 ms
Obnovovací frekvence	60 Hz
Funkce	freeSync, Blue Light Reduction, Flicker Reduction, HDR, připevnění na zeď
Vstupy	HDMI, DisplayPort
Barva	bílá
Šířka	62.2 cm
Výška	46 cm
Hloubka	20.9 cm
Hmotnost	5.1 kg
Příkon	32 W

Dotykový monitor: Pro potřeby pracovišť nabízíme dodat 2 ks dotykových monitorů all-in-one minimálně 19,8“

s následujícími parametry (dle dostupnost zařízení na trhu může být dodán i lepší typ s lepšími parametry).

Technické parametry

Typ displeje: IPS

Povrch displeje: antireflexní Úhlopříčka displeje ["]: 23,8

Rozlišení displeje: 1920 x 1080 (Full HD)

Jas [cd/m2]: 250

Barevná škála: NTSC 72% Poměr stran: 16:9

Druh grafické karty: Integrovaná

OS: Windows 10 Pro 64-bit

Dotykový monitor: Pro potřeby pracovišť nabízíme dodat 2 ks níže uvedeného řešení:

DISPLAY E24-9 TOUCH, EU E Line 60,5cm(23.8')wide Touch Display Ultra Narrow Border, LED, black DisplayPort,HDMI,VGA,USB

Fujitsu ESPRIMO Q7010 / Core i5-10400T / 8GB / 256GB SSD NVMe / WIFI / NO KB / USB mouse / Win10Pro 5 yer onsite 9x5

Fujitsu Stand Monitor Universal

Toto řešení splňuje požadavky Zadavatele a rovněž provozovaných aplikací.

2) Pracoviště lektora (celkem jedno pracoviště)

PC: Jako pracovní stanici pro lektora nabízíme dodat 1 ks HP ProDesk 600 G6 DM i5- 10500T/ 16GB/ 512SD/ WF/ W10P 2xDisplayPort+HDMI.

Monitory 27“: Pro lektorské pracoviště nabízíme dodat 2 ks stejných monitorů, jako pro potřeby pracovišť calltakera a dispečera, popis viz výše.

Shrnutí nabízených komponent pracovišť:

Komponenta	Zařízení	Účel
2 x pracovní stanice včetně OS	HP ProDesk 600 G6 MT i5- 10500/8GB/256SD/DVD/W10P 2xDisplayPort+VGA	Pracoviště calltakera a dispečera
1 x pracovní stanice včetně OS	HP ProDesk 600 G6 DM i5- 10500T/ 16GB/ 512SD/ WF/ W10P 2xDisplayPort+HDMI	Pracoviště lektora
8 x 27“ monitor	LG 27UL500-W - LED monitor 27"	Pracoviště lektora, dispečera a call takera
2 x dotykový monitor	Komplexní řešení: - Dotykový displej DISPLAY E24-9 TOUCH, EU E Line 60,5cm (23.8')wide Touch Display Ultra Narrow Border, LED, black DisplayPort,HDMI,VGA,USB - miniPC Fujitsu ESPRIMO Q7010 / Core i5-10400T / 8GB / 256GB SSD NVMe / WIFI / NO KB / USB mouse / Win10Pro polohovatelný stojan Fujitsu	Pracoviště calltakera a dispečera

3.2.3 Telefonie a záznam hovorů

- Požadavek zadavatele

náhlavní sadě musí být možné samostatně dokoupit spotřební materiál (min. náhradní ušní molitany).

Dále bude dodán přenosný telefon pro napojený na ústřednu (DECT nebo Wifi) pro práci simulované posádky. Vstupním a výstupním bodem ústředny bude jedna nebo více GSM brán kompatibilních s ústřednou s celkově dvěma komunikačními kanály (2x SIM). Dodávka SIM karet není předmětem dodávky.

Ústředna bude umístěna v technologické místnosti zadavatele a přístroje k ní budou napojeny přes strukturovanou kabeláž budovy (dodávka kabelů do 10m).

systému OŘ.

Komponenta

Zařízení

Účel

HW 03

Dodávka telefonní ústředny

Telefonní ústředna se záznamem, integrací, 3x IP stolní telefon, 1x přenosný (IP nebo analogový s převodníkem), GSM brána, kabeláž.

provedení do racku výšky max. 2U.

- Popis nabízeného ỉešení

Telefonie

V rámci dodávky bude dodán 1ks telefonní ústředny Alcatel-Lucent OXO Connect Evolution v konfiguraci do

19´´ Racku vč. příslušenství, potřebných licencí, konfigurace a školení uživatele.

Konfigurace PBX:

• Alcatel-Lucent OmniPCX Office v provedení instalace do 19´´ Racku

o 4x IP pobočka pro IP přístroje 8008

o 2x REX pobočka pro integraci GSM přístroje do PBX

o 4x SIP hlasový kanál pro připojení k JTS

o 2x SIP hlasový kanál pro připojení WebRTC GW (WebRTC GW je součástí PBX) pro hlasovou

integraci s Rinbow

o 1x Application interface Open pack (Tapi 2.1, CSTA desktop and server)

o 4x IP přístroj Alcatel-Lucent 8008 včetně zdroje

o 1x GSM Brána Alphatech – Blue Gate Single SIP s jedním SIP/GSM kanálem

Součástí dodávky budou 3ks drátových náhlavních souprav Jabra 2400. K náhlavní sadě je možné samostatně

dokupovat spotřební materiál. Náhlavní soupravy budou voleny ve stejných typech, které používají ZZS

provozované Uchazečem a budou tak splňovat náročné požadavky na nepřetržitý provoz operačního střediska a

kvalitu přenosu.

Integrace

Integrace telefonie i radiofonie bude zajištěna v rámci aplikace Panel 6, která bude provozována na dotykové obrazovce. V aplikaci bude možné minimálně příjem hovoru a vytočení čísla včetně vytočení ostatních poboček ústředny pomocí zkrácené volby, integrace na telefonní seznamy IS OŘ atd. Integrace bude zajištěna rovněž

v aplikaci pro operační řízení Dispečer ZZS, kde bude umožněno zakládání události na základě hovoru a párování nahrávek k události, vytočení hovoru na zobrazené telefonní číslo atd., jak je popsáno níže v popisu systému OŘ.

Záznam

Záznam bude realizován řešením používaným v rámci složek IZS (ZZS SčK, ZZS JčK, ZZS OL a HZS ČR) od společnosti ReDat. V rámci IS OŘ je zajištěna integrace záznamu do aplikace Dispečer ZZS, ve kterém lze záznamy vyhledávat a přehrávat. Aplikace rovněž disponuje logem přehrávání záznamů uživateli. Záznamy budou průběžně odmazávány dle požadavku Zadavatele.

Součástí dodávky telefonie je rovněž integrovaný GSM modem pro odesílání SMS. Bude dodán bez SIM karty.

3.2.4 Simulovaný rádiový provoz a jeho integrace

- Požadavek zadavatele

Pro simulaci rádiového provozu bude dodána jedna vozidlová radiostanice integrovaná do prostředí

touchscreenu pracovních stanic a dále jedna ruční radiostanice pro simulovanou posádku. Provoz bude veden na volně dostupných frekvencích v analogovém nebo digitálním režimu.

Integrovaná radiostanice včetně prostředků integrace budou umístěny v technologické místnosti zadavatele.

Komponenta

Zařízení

Účel

HW 04

Dodávka radiofonie

Dodávka integrované vozidlové a neintegrované ruční radiostanice, integrace do systému včetně

záznamu

- Popis nabízeného ỉešení

Pro zajištění všech výše uvedených požadavků Zadavatele bude dodáno:

• ErcLink [FIN] RDST rack mount PC, 8 timeslot, 8 Erc modulů, základní sestava bez zásuvných modulů

• Aplikační konektor pro MOTOTRBO™/I2C sběrnice včetně kabelu

• Zásuvný modul RDST, vstupní interface (1 timeslot / 1 Erc modul)

• Mototrbo integrovaná analogová část

• Typ radiostanic bude DM 4600

3.2.5 Audiopropojovací pole

- Požadavek zadavatele

Pole musí mít konfigurovatelnou vstupně výstupní kombinaci s možností spojení (mixování) vstupních i

výstupních zdrojů, a také ovladatelnou hlasitost volitelně pro jednotlivé vstupy i výstupy. Ovládání může být hardwarové nebo integrované do dotykové obrazovky pracovišť.

Požadavek

Popis

HW 05

Audiopropojovací pole

Dodávka 2ks audiopropojovacích polí včetně ovládání nebo

integrace.

- Popis nabízeného ỉešení

V rámci řešení budou dodány nové audio přepínače, které budou zabudovány na jednotlivých dispečerských pracovištích (ve vnitřním technologickém prostoru pracovního stolu).

Bude zajištěna kompatibilita s ostatními částmi systému.

Nabízený přepínač Turtle I (dále T I.). je vestavný, plně digitální převodník analogových signálů pro potřeby pracovišť složek IZS. Byl vyvinut na základě dlouhodobých zkušeností při příjmu, úpravách a reprodukci audio signálů, které je potřebné zpracovávat v místě pracoviště.

Vlastnosti:

• Kompaktní, mechanicky odolné provedení

• Plně digitální zpracování DSP procesorem s vlastním operačním systémem EROS

• Snadná výměna firmware po ethernetu

• Nemá žádné vnější nastavovací prvky

Mikrofonní vstup

Na nesymetrický mikrofonní vstup se konektorem jack 3.5 k modulu připojuje elektretový mikrofon pracoviště operátora. Tento vstup je vybaven šumovou bránou s limiterem. Pro potřeby napájení mikrofonu je na

konektoru vyvedeno napájení 3V.

• Vstup

o Impedance cca. 20 kΩ

o Limiter omezuje při UVST = 200 mV

Náhlavní souprava

Konektorem RJ 4/4 nebo jack 3.5 se k modulu připojuje náhlavní souprava. Vstup je vybaven šumovou bránou s limiterem a proudovým senzorem detekujícím aktivaci náhlavní soupravy.

• Vstup

o Parametry obdobné mikrofonnímu vstupu

• Výstup

o UMAX = 2,8 Vp-p

o Impedance cca. 600 Ω

Vstupy od telefonního přístroje*

Konektorem RJ 4/4 se k modulu připojuje sluchátková část telefonního přístroje, případně pomocí jack 3.5 vstup / výstup ze systémového konektoru pro náhlavní soupravu (pokud je telefonní přístroj takto vybaven).

V případě, že se použije konektor RJ 4/4 a průběžné připojení (přístroj i sluchátko do modulu), je uvnitř modulu zajištěno odpojení / připojeného sluchátka, aby nedocházelo k „míchání“ signálů z T I. a mikrotelefonu.

• Vstup / Výstup

o UMAX = 2,8 Vp-p

o Impedance cca. 600 Ω

o Galvanicky odděleno transformátorem

*tyto moduly lze v případě potřeby dle konkrétního připojeného hw. modifikovat tak, aby nebyl podkročen běžný komfort pracoviště operátora

Linkové vstupy a výstupy pro PC

Pro připojení k PC je použito dvojice linkových vstupů / výstupů. Všechny tyto signály jsou galvanicky odděleny.

• Vstup / Výstup

o UMAX = 2,8 Vp-p

o Impedance cca. 5 kΩ

o Galvanicky odděleno transformátorem

Koncový zesilovač a linkový výstup

Pro snadnou integraci v místě pracoviště je T I. vybavena nf. zesilovačem 2x5 W do zátěže 4Ω. Tento signál není na rozdíl od linkové úrovně tohoto výstupu galvanicky oddělen.

Digitální vstupy

T I. je vybavena trojicí galvanicky oddělených bipolárních vstupů, které mají jeden společný pól SX a jednotlivé

vstupy X0, X1, X2.

log. 0 na vstupu napětí X proti SX v rozmezí -2V ... +2V

log. 1 na vstupu napětí X proti SX menší než -10V nebo větší než +10V

maximální vstupní napětí 30V , -30V

odběr vstupu cca. 2 mA při 12V pevnost galvanického oddělení min. 1500V

Digitální výstupy

T I. je vybavena trojicí galvanicky oddělených tranzistorových výstupů, které mají jeden společný (kladný, společný kolektor) pól SY a jednotlivé výstupy Y0, Y1, Y2.

pracovní napětí (log. 0) max. 30V ( vypnutý výstup) úbytek napětí (log. 1) max. 2V ( sepnutý výstup)

spínaný proud max. 200mA

pevnost galvanického oddělení min. 1500V

Napájení modulu

T I. je vybavena interním spínaným zdrojem, napájecí napětí se pohybuje v rozsahu 10V – 15V, klidový odběr při 12V je cca. 300mA. Tento odběr se pochopitelně mění podle počtu vnitřně aktivně připojených periferií a

výkonu zesilovače.

Panely přístroje

Mikrofon a náhlavní souprava

Telefon 1

Telefon 2

Line1

IN / OUT

Line 2

IN / OUT

Přední a zadní panel:

•

Napájení modulu

Systémový konektor

konektivita

Konfigurační konektor

Výstup pro REPRO

Line out (REPRO)

•

3.2.6 Vybavení simulované posádky

- Požadavek zadavatele

Posádka bude vybavena přenosným telefonem (viz. specifikace telefonie) a odolným notebookem v minimální

konfiguraci:

- požadováno je vytvoření pevného celku při spojení klávesnice a tabletu, aby vzniklo zařízení typu

„notebook/laptop“

- odolnost vůči vodě a prachu minimálně IP-65 podle normy MIL-STD-810G a IEC 60529

- odolnost vůči otřesům a volnému pádu podle normy MIL-STD-810G 516.6

- práce na baterie minimálně 7 hodin (i v rozloženém stavu)

- výkon procesoru musí umožňovat minimální průměrné skóre 3000 v benchmarku Passmark CPU Mark

- operační paměť minimálně 8GB

- pevný disk typu SSD minimálně velikosti 128GB

- podpora WIFI standardů 802.11 b/g/n

- hmotnost s bateriemi do 2.2 kg ve složeném stavu

- maximální tloušťka zavřeného notebooku nebo konvertibilního zařízení v režimu tablet 40mm

- 10-12.5" obrazovka MultiTouch (min. jas 800cd/m², min. rozlišení 1280x768)

- standardní HW klávesnice bez numerické části s českou lokalizací

- polohovací zařízení touchpad

- záruka pokrývající náhodné poškození zařízení

- operační systém kompatibilní s MZD a EKP

Na notebooku bude nahrána aplikace MZD i EKP a připojena na WIFI zadavatele a bude komunikovat se serverovou částí.

Požadavek

Popis

HW 06

Notebook posádky

Odolný notebook simulované posádky ve specifikované

konfiguraci.

- Popis nabízeného ỉešení

Jako tablet pro MZD/EKP nabízíme zařízení Getac V110 s těmito parametry:

- jedná se o notebook rozložitelný na tablet a klávesnici (viz fotografie)

- dotyková multi-touch kapacitní obrazovka 11.6" IPS TFT LCD FHD (1920 x 1080) s LumiBond® 2.0, technologií, jas 800cd/m²

- odolnost vůči vodě a prachu IP-65 podle normy MIL-STD-810H a IEC 60529

- odolnost vůči otřesům a volnému pádu podle normy MIL-STD-810G 516.6, MIL-STD-461G

- práce na baterie minimálně 7 hodin (i v rozloženém stavu)

- procesor Intel® Core™ i5-10210U Processor 1.6GHz, 6MB Intel® Smart Cache, skore přes 6500 v

- benchmarku Passmark CPU Mark

- operační paměť 8GB DDR4

- pevný disk 256GB PCIe NVMe SSD

- komunikační rozhraní:

• 10/100/1000 base-T Ethernet

• Intel ® Wi-Fi 6 AX200, 802.11ax

• Bluetooth (v5.2)

- I/O rozhraní:

• Audio in/out combo x 1

• DC in Jack x 1

• USB 3.2 Gen 1 Type-A x 1

• USB 3.2 Gen 2 Type-A x 2

• LAN (RJ45) x 1

• HDMI x 1

• Serial port (9-pin; D-sub) x 1

• Docking connector x 1

- hmotnost s bateriemi 2,1 kg ve složeném stavu

- rozměry 313 x 238 x 39mm (12.32" x 9.37" x 1.53")

- standardní HW klávesnice bez numerické části s českou lokalizací

- polohovací zařízení touchpad

- záruka 5 let pokrývající náhodné poškození zařízení

- operační systém Windows 10 Pro kompatibilní s MZD a EKP

3.3 Obecné požadavky na SW řešení

3.3.1 Obecné požadavky

- Požadavek zadavatele

IS OŘ musí umožnit:

• zajištění podpory procesů OŘ,

• využití mapových a datových podkladů prostřednictvím volání služeb GIS,

• zjištění procesů posádky (MZD a EKP) včetně propojení s OŘ,

• integraci s dalšími systémy a technologiemi.

- Popis nabízeného ỉešení

Systém naplňuje požadavky na architekturu řešení IS ZZS specifikované ve Studii proveditelnosti. IS OŘ jako jeden ze systémů OŘ v heterogenním prostředí systémů OŘ celého IZS je vystavěn v architektuře SOA, která je průmyslovým standardem architektury pro softwarové aplikace.

Systém kompletně pokrývá procesy OŘ, je provozován na třech operačních střediscích v rámci ČR. Systém disponuje rozhraními na řadu externích systémů využívaných v rámci IS ZZS:

- GIS od společnosti T-Mapy

- MZD a EKP

- Telefonní ústředna

- Komunikační technologie – analogové a digitální radiostanice

- Systém sledování provozu vozidel

- RÚIAN

- Datová věta předávání událostí (NIS IZS)

- Záznam od společnosti Retia a Info 35

- AMDS

- Mobilní aplikace záchranka

- A další

3.3.2 Společné požadavky na dodané systémy

- Požadavek zadavatele

• Veškeré sdílené číselníky všech systémů budou editovatelné v rámci aplikačního prostředí jednoho ze systémů, samostatně editovatelné budou pouze číselníky specifické pro určitý ze systémů.

• Všechny aplikace, se kterými budou pracovat uživatelé, budou mít řešenu autentifikaci a to způsobem

kdy:

o o autentifikace se bude provádět vůči jednotné vnitřní databázi uživatelů IS,

o o systém musí umožnit autentifikaci vůči systému Active Directory zadavatele, pokud se zadavatel rozhodne v budoucnu systém do AD začlenit, a to ve všech aplikacích.

• Odezvy systému na operace typu založení entity, předání posádce atd. musí být vykonány do max. 2 sekund od zahájení požadavku.

• • Systém nebude napojen na národní systém příjmu tísňového volání, pouze budou simulovány datové

vety tohoto systému, jak je specifikování v kapitole o simulovaném běhu.

- Popis nabízeného ỉešení

Číselníky

Veškeré sdílené číselníky jsou editovatelné v rámci prostředí Zdravotnické dokumentace.

• Činnost

• Charakter

• Indikace (víceúrovňové)

• Naléhavost

• Oblast

• Uživatelé/osoby systému

• Pohlaví

• Radiostanice a jejich druh

• Součinnost

• Stanoviště

• Středisko

• Typ posádky

• Typ vozidla

• Typ zaměstnance

• Vozidla

• Výjezdová skupina

• Status

• Zařízení

• Oddělení

• Aplikace

• Skupina uživatele

• Stav události

Číselníky a konfigurace specifické pro dispečerský systém jsou editovány v aplikaci Admin ZZS. Jsou to

například:

• Automatické akce

• Příznaky

• Rajonizace

• First Respondeři a jiné spolupracující složky

Další infomace onine přenášené mezi systémy:

Statusy:

• Přenášení statusu ze strany zdravotnické dokumentace do OŘ

Události:

• Přenos události z OŘ do zdrav. dokumentace a zpět minimálně v rozsahu: o ID

o Datum založení

o Datum přijetí

o Místopis události

o Popis místa události pokud není místopis

o Telefon volajícího

o Jméno volajícího

o Popis události

o Poznámka k události

o Popis události převzatý od jiných složek IZS

o Charakter

o Indikace

o Naléhavost

o Notifikace JSDI

o Součinnosti

o Využití First respondera

Pacienti:

• Přenos pacienta z OŘ do zdrav. dokumentace a zpět minimálně v rozsahu:

o ID

o Pohlaví

o Zjištěný věk (případně ročník)

o Číslo pojištěnce

o Příjmení

o Jméno

o Cílové zařízení a oddělení

o Poskytnutí TANR/TAPP

o Dg

o Vazba na událost a výjezd

Výjezdy:

• Přenos výjezdu z OŘ do zdrav. dokumentace a zpět minimálně v rozsahu o Id

o Číslo výzvy

o Indikace dle ZOS

o Charakter dle ZOS

o Poznámka ZOS

o Lokalizace zásahu – místopis včetně souřadnice ve WGS

o Lokalizace zásahu – popis v případě že není místopis

o Čas převzetí

o Čas výzvy

o Čas výjezdu

o Čas příjezdu na místo

o Čas odjezdu z místa zásahu

o Čas příjezdu k zařízení

o Čas předání

o Čas odjezdu od zařízení

o Čas návratu na základnu

o Čas ukončení

o Vozidlo výjezdu

o Lékař vjezdu

o NLZP výjezdu

o Řidič výjezdu

o NZP/ostatní výjezdu

o Telefon pacienta

o Typ posádky

o Výjezdová skupina výjezdu

o Středisko výjezdu

o Stanoviště výjezdu

o Součinnosti při výjezdu

o Označení režimu RV

o ID párovaného RV záznamu

o ID rozepsaného záznamu

o Naléhavost

o Místo začátku a konce výjezdu

o Vazba na událost a pacienta

Všechny aplikace, se kterými budou pracovat uživatelé, budou mít řešenu autentifikaci a to způsobem kdy:

o o autentifikace se bude provádět vůči jednotné vnitřní databázi uživatelů IS,

o o systém umožní autentifikaci vůči systému Active Directory zadavatele, pokud se zadavatel rozhodne v budoucnu systém do AD začlenit, a to ve všech aplikacích.

Systém IS OŘ má zabezpečení konkurenčního zpracování na všech úrovních (události, záznamy/výzvy, posádky

apod.). Je implementováno zamykání položek, aby nedošlo k současné editaci několika uživateli. Uživatel je informován o tom, že je záznam uzamčen jiným uživatelem. Uživateli je umožněno např. událost převzít od původního uživatele, který ji měl pro sebe uzamčenu.

Odezvy systému na operace typu založení entity, předání posádce atd. budou vykonány do max. 2 sekund od zahájení požadavku.

Systém nebude napojen na národní systém příjmu tísňového volání, proto bude umožněno zasílání simulovaných datových vět.

3.4 Požadavky na systém OŘ ZZS

3.4.1 Licencování

- Požadavek zadavatele

Licence systému pro operační řízení musí pokrývat minimálně:

- instanci aplikačního serveru,

- minimálně 3 aktivní klienty operačního řízení všech druhů (klient OŘ, klient integrace radiostanic

apod.),

- GIS serveru včetně mapových podkladů, minimálně 3 klienty GIS,

- licence na potřebné databáze a další přidružené systémy,

- licence musí být dodány jako přenositelné.

- Popis nabízeného ỉešení

V rámci řešení budou dodány školní licence systému pro IS OŘ zahrnující licence:

• 1x aplikační server IS OŘ ZZS, licence pro 3 pracoviště

• 3x aktivní klient Dispečer ZZS

• 2x Panel 6 pro dotykovou obrazovku

• 3x aktivní klient Administrace ZZS

o IS ZZS v6, modul "Editace automatických akcí"

o IS ZZS v6, modul "Konfigurace systému"

o IS ZZS v6, modul "Rajonizace"

o IS ZZS v6, modul "Kontakty"

• 6x integrovaný GIS IZS operátor

• 1x IZS Admin pro GIS

• 1x mapová komponenta pro Zdravotnickou Dokumentaci

• aplikační a prezentační server DocServer

• mobilní zpracování dat MobileDoc

• 2x klientská část Zdravotnické dokumentace + Základna

• Microsoft SQL Server Standard edition

• Technologické moduly:

o NSERVER - komunikační jádro systému

o IS ZZS v6, modul "TOUCH klient kontejner" - licence na jedno pracoviště

o IS ZZS v6, modul "TOUCH klient radioprovozu" - licence na jedno pracoviště

o IS ZZS v6, modul "TOUCH klient radioprovozu PTT ID" - licence na jedno pracoviště

o IS ZZS v6, modul "TOUCH klient telefonní ústředny" - licence na jedno pracoviště

o IS ZZS v6, modul "TAPI server telefonní ústředny"

o ASERVER, modul "Audio klient"

o IS ZZS v6, modul "Simulátor 112"

o IS ZZS v6, modul "SvcSrv server C++ služeb"

o IS ZZS v6, modul "ACMgr - správce automatických akcí"

o IS ZZS v6, modul "ACMScript – generování scénářů akcí"

o IS ZZS v6, modul "CdrMgr – správce kódovaného radioprovozu"

o IS ZZS v6, modul "TelMgr – správce telefonie"

o IS ZZS v6, modul "IVRSrv – Interactive Voice Response server"

o IS ZZS v6, modul "GSMSrv – odesílání a příjem SMS zpráv"

o IS ZZS v6, modul "GSMSrv – port GSM modem"

Licence operačního SW jsou součástí dodávaného hardware viz kapitoly výše.

3.4.2 Systém operačního řízení a jeho integrace

- Požadavek zadavatele

• Systém musí umožnit simulovaný příjem tísňového volání:

- přijetí hovoru operátorem ve skupině aktuálně přihlášených call takerů

- založení události automaticky na „zvednutí sluchátka“ a její vytěžení,

- předání informací o výzvě k operačnímu řízení

• Operační řízení.

- rajonizace události a doporučení VS, která má výzvu řešit (systém nabízí náhled na výjezdové

skupiny, jejich stav)

(1) rajonizace na základě místopisu definované vazbou posádky na kódy místopisných prvků

RUIAN

(2) s ohledem na vytížení jednotlivých VS v průběhu směny

- - předání výzvy simulované výjezdové skupině

- - monitoring řešení událostí pomocí systémů statusů do doby ukončení posledního výjezdu k události

- - editace složení výjezdových skupin

Integrace na ostatní systémy v rámci IS ZZS

- GIS

- RÚIAN

- Simulovaná datová věta předávání událostí

- Telefonní ústředna

- Radiokomunikace

- Popis nabízeného ỉešení

Uchazečem nabízené řešení je standardizovaným řešením provozovaným na zdravotnických záchranných službách Středočeského kraje, Jihočeského kraje a Olomouckého kraje.

- Požadavky na funkcionality systému operačního ỉízení

	Požadavek Zadavatele	Popis Zadavatele	Vyjádření Uchazeče
	Příjem tísňové výzvy
OŘ 01	Příjem a zpracování TV, založení události	Systém umožní přijetí hovoru na jednom z dispečerských pracovišť podle zvolené role uživatele (role calltaker). Systém umožní přijmout TV z těchto zdrojů tísňového volání: • Přímý příjem hovorů tísňového volání přes dodanou ústřednu, možnost přepojení nebo konference • příjem tísňových SMS • příjem událostí přes datovou větu simulovaného prostředí NSPTV včetně vytěžení dat z datové věty a přenesení do události. Zpracování telefonické výzvy v OŘ • Při příchodu tel. hovoru na pracoviště calltakera se zobrazí v dispečerské aplikaci informace o volajícím (telefonní číslo volajícího) • Bude rovněž k dispozici informace, zda z tohoto tel. čísla byly již nějaké události ohlášeny • Při vyzvednutí hovoru bude automaticky založena nová událost	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 02	Zpracování datových vět	• Systém musí zajistit příjem datové věty (DV) ze systému simulujícího NIS IZS a vytěžení všech podstatných informací v rámci události. Seznam atributů, které systém přebírá ze systému NIS IZS je dán specifikací DV systému NIS IZS. • K již existujícím událostem musí být možné vytěžit změnovou DV (ZDV) se zobrazením rozdílů, které DV obsahuje ve srovnání s informacemi již uloženými u události a s možností vybrat, která data ze ZDV zapracovat k události a která data si dispečer nepřeje přebrat. • Přijetí DV z NIS IZS musí být dispečerovi neblokujícím, ale dostatečně výrazným upozorněním signalizováno, aby operátor nebyl nucen kvůli potvrzení příjmu DV přerušovat prováděnou činnost, ale aby nemohl příjem DV nebo ZDV přehlédnout. Tato notifikace musí být jednak vizuální v rámci grafického rozhraní dispečerské aplikace a dále akustická na základě administrátorem systému konfigurovatelné zvukové znělky. • Při příjmu DV nebo ZDV musí být přijaté informace prezentovány v přidružené klientské GIS aplikaci	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 03	Lokalizace události	• Bude provedena lokalizace simulované události, pokud není možné určit přesné místo události, tak i popisem místa, jinak	Řešení Uchazeče tuto funkcionalitu splňuje

pomocí GIS klienta nebo výběrem z místopisného helperu v

kombinaci s fulltext vyhledáváním:

• Možnost filtrů určitý místopisný okruh, např. na konkrétní kraj

• Je možné hledat různé kombinace např. "obec, ulice", jednotlivé výrazy se oddělují čárkou a postačí zadání jen jejich části např. "ost, cihe" najde ulici Cihelní v Ostravě

• Za název obce nebo ulice je možné mezerou oddělené zadat číslo popisné nebo orientační, např. "ost, cihe 14"najde číslo popisné 14 v ulici Cihelní v Ostravě

• Hledání je vždy omezeno podle již vybrané úrovně adresy, např. pokud mám již vybránu obec Opava, veškeré hledání se mi omezí pouze na katastr této obce.

• Jednotlivé úrovně adresy je možné jedním kliknutím

odstranit

• Je možné lokalizovat událost také zadáním souřadnic ve formátu WGS-84

hledáním názvu POI.

OŘ 04

Vytěžení události

Možnost evidovat k události tyto atributy:

• Číslo volajícího

• Jméno volajícího

• Telefonní číslo + překlad na jméno, pokud je v systému k

dispozici

• Lokalita volajícího/události

- z DV z NSPTV

- další dostupné zdroje takové informace

- Historie záznamů z tohoto tel.čísla - na základě dotazu na databázi uzavřených událostí indikuje podle telefonního čísla (například barevným zvýraznění, orámováním, doplňujícím textem) , zda už byly z tohoto tel.čísla nějaké události ohlášeny (nebo aktuálně probíhají) a případně umožní náhled na tyto události výběrem ze seznamu takových událostí

- Možnost zadat "volání z 3. ruky" - tímto příznakem se aktivuje pole pro zadání druhého tel.čísla jako čísla na místo události.

- Možnost přímo vytočit hovor jako "zpětné volání" na číslo volajícího

• Klasifikace charakteru události

• Popis události

• Poznámka k události

• Indikace - dvouúrovňová a vztahuje se k pacientovi - při nabírání případu se bude vytěžovat pouze jedna indikace a předpokládaný počet pacientů

• Informace, zda byla poskytnuta telefonicky asistovaná resuscitace či telefonicky asistovaná první pomoc či jiné příznaky uživatelsky definovatelné

• Spolupracující složky IZS:

- Možnost zaznačit a předat systému ZD spolupracující složky IZS

• Informace k pacientům události:

- Jméno pacienta

- Přibližný věk nebo ročník narození

- Pohlaví

- Stupeň naléhavosti z definovatelného číselníku naléhavostí

• Navržený typ sil a prostředků z definovatelného číselníku

SaP včetně příslušného počtu navržených posádek

Řešení Uchazeče tuto funkcionalitu splňuje

		• Ochrana zadaných informací dle definovaných pravidel (zamezení pozdějších změn indikace, charakteru atp.
OŘ 05	Založení a předání záznamu k výjezdu	Z vytěžených informací o pacientovi bude automaticky při založení události založen záznam k výjezdu, který dispečer může zpracovat jako: • • Vyřešený jinou cestou (viz. Ukončení výzev operátorem) • • Předaný do fronty pro operační řízení Calltaker může založit případně další záznamy k výjezdu k dané události a opět je předat do fronty pro operační řízení.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 06	Objednávky sekundárních transportů	Příjem a zpracování objednávky sekundárních transportů. Vytěžení bude obdobné jako u tísňového volání.	Řešení Uchazeče tuto funkcionalitu splňuje
Operační řízení
OŘ 07	Vizualizace výzev ve frontě	Výzvy, které budou calltakerem předány k dalšímu řešení do systému OŘ, budou řazeny do fronty. Fronta záznamů k výjezdu bude řazena dle definovatelného řazení (např. stupně naléhavosti a času založení), stupeň naléhavosti bude odlišen ještě i vizuálně. Ve frontě je jasně viditelná lokalita události, naléhavost, indikace, charakter, informace o pacientovi (příjmení, jméno, věk) a další známé sledované hodnoty. Aplikace umožní náhled na výzvy v těchto frontách: • Výzvy urgentní • Plánované výzvy • Probíhající výzvy • Ukončené výzvy • Celkový přehled výzev Plánované výzvy - doplní se datum a čas, na kdy je případ plánován a vloží se do seznamu plánovaných případů. Ostatní dispečeři nemusí informaci o vzniku takové události nijak výrazně notifikovat, pouze ji musí být aplikace na ostatních pracovištích schopny dále zpracovávat (musí o ní tedy "vědět"). V čase, na který je výzva naplánována, dojde k upozornění operátora (ad popis níže). Výzvy urgentní - standardní postup, kdy se případ předá ke zpracování operátorem ZZS, operátor je okamžitě upozorněn. V obou případech, plánované výzvy i výzvy urgentní, musí dojít k výraznému, ale neblokujícímu upozornění, aby dispečer ZZS nebyl nucen kvůli potvrzení příjmu této informace přerušovat prováděnou činnost, ale aby nemohl tuto informaci přehlédnout. Tato notifikace musí být jednak vizuální v rámci grafického rozhraní dispečerské aplikace a dále akustická na základě administrátorem systému konfigurovatelné zvukové znělky a to tak dlouho, dokud není případ některým z operátorů převzat k následnému zpracování. Zajistit, aby v aktuální chvíli převzal k řešení čekající záznam pouze jediný dispečer a nemohlo dojít k zaslání více výzev nad jedním záznamem.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 08	Ukončení výzev operátorem	Simulovaně předat případ - předá se k řešení jiné složce IZS, ZZS v jiném kraji, LSPP apod. V dialogu se řeší, komu / jak byl případ předán. Předáním se případ uzavře (událost ukončí). Číselník cílových adresátů předání musí být volně konfigurovatelný. Stornovat případ – řešení záznamů ve frontě je možné bez řešení stornovat. V tom případě je však nutné vést přesný přehled o uživateli a důvodu této operace.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 09	Sekundární převozy pacientů	U těchto záznamů bude ve frontě viditelný čas a datum, na který je převoz požadován. Aktivní upozornění systémem na nutnost řešení čekajícího záznamu výjezdu. Číselník zařízení pro sekundární převozy bude spravován na straně IS ZD ZZS a stranou IS OŘ bude synchronizován, včetně jejich adres a souřadnic. Sekundární transporty, stejně jako primární podléhají	Řešení Uchazeče tuto funkcionalitu splňuje

		rajonizaci, a to jak podle předdefinované rajoinzace, tak i podle nejbližší dostupné posádky.
OŘ 10	Vizualizace přihlášených posádek a jejich stavu	K přihlášeným posádkám bude dispečer mít dostupné informace k jejich typu (RLP, RZP, RV, LZS – typ posádky je v přehledu graficky odlišen), názvu, aktuálnímu statusu a vytížení v rámci směny dané posádky. Aplikace nabízí rovněž přehledový panel posádek s těmito vlastnostmi: • Jde o okno, které zobrazuje ve volitelných pozicích jednotlivé posádky a jejich aktuální stav. • Toto okno je plně uživatelsky (administrátorem systému) konfigurovatelné • Z okna je možné přímo kontaktovat posádku (telefon - přímé vytočení hovoru, rádio - zaklíčování na dotykovém panelu na správném kanálu, otevření příposlechu, odeslání vybrané sel. volby. • Je možné se proklikem rovnou dostat na událost, u které posádka zasahuje. • Dostupné jsou různé informace o posádce - aktuální stav posádky. • Ikony nebo jiné grafické odlišení pro jednotlivé stavy a pro jednotlivé posádky jsou konfigurovatelné administrátorem systému. • Je třeba, aby bylo možné změnit stav posádky na všechny dostupné stavy, které jsou v číselníku, při dodržení logických souvislostí (např. nelze nastavit stav "na cestě k události" bez vazby na událost, vazba na událost je v takových případech nezbytnou podmínkou)	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 11	Rajonizace, výběr SaP	Systém bude umožňovat na základě vazeb místopisných entit na jednotlivá stanoviště (vazba přes kódy RÚIAN) z místopisu v záznamu navrhnout dispečerovi ve vazbě na navržený typ SaP vhodné výjezdové skupiny s deklarovanou prioritou. Systém umožňuje deklarovat rajonizaci pomocí kódů místopisných entit: • Ulice • Část obce • Obec a přiřadit k nim množinu výjezdových skupin s vazbou na typ dané skupiny, které jsou řazeny pomocí určené priority, volitelně s vazbou na jejich akceschopnost. Na základě adresy případu bude možné provést jednak určení místně příslušného stanoviště a podle předběžného počtu SaP z okna zadání nové události bude proveden automatický výběr posádek, které by měly být přednostně vyslány k případu, včetně vizualizace v GIS klientovi	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 12	Aktivace simulované posádky	Při aktivaci posádky dispečerem dojde k předání výzvy na pracoviště výjezdového stanoviště a provedení minimálně těchto akcí: • Telefonní výzva na primární telefon • Telefonní výzva na mobilní (sekundární) telefon • Selektivní volání na ruční analogovou radiostanici posádky • Předání záznamu systému zdravotnické dokumentace, který ji dále předá mobilnímu řešení Musí být možné zvolit si sadu akcí pro provedení při výzvě, kdy je posádka na stanovišti a kdy je na výjezdu ve vozidle. Výběr typu aktivace (zda do vozidla nebo na stanoviště) je na dispečerovi.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 13	Statusy posádek a polohy SaP	Systém bude umožňovat evidenci těchto stavů posádek: 0 - technická pauza 1 - výjezd 2 - příjezd na místo události 3 - odjezd z místa události 4 - příjezd ke zdrav. zařízení 5 - zahájení návratu 6 - příjezd na základnu 7 - konec akce 8 - mimo provoz 9 - stav nouze	Řešení Uchazeče tuto funkcionalitu splňuje

OŘ 14	Změny statusů	Aktualizace stavů bude probíhat: • Datovou cestou z MZD • Cestou zpracování statusů z radiostanice posádky • Manuálním zásahem dispečera v rámci dispečerské aplikace Na základě změny stavu záznamu dojde ke změně stavu události.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 15	Stavy události	Rozlišovat tyto stavy událostí. 1. událost jiné složky bez schválení ZOS – příchozí událost jiné složky čekající na vyřízení, událost v takovém stavu je call takerovi signalizována 2. událost platná schválená – událost zpracovávaná nebo zpracovaná a čekající 3. událost platná schválená s požadavkem – událost s alespoň jedním čekajícím záznamem/výzvou 4. událost předaná k řešení posádkám (po výzvě) - událost s alespoň jedním záznamem/výzvou po výzvě 5. událost posádka na místě – událost s alespoň jednou posádkou se statusem minimálně 2 6. událost vyřešená předáním – událost neřešena ZZS, pouze předala jiné složce 7. událost vyřešená – událost s ukončeným řešením 8. událost zrušená – událost neřešená Aplikace umožní náhled na události v těchto frontách: • Události čekající na zpracování • Události aktivně řešené • Události ukončené	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 16	Správa posádek	Posádky bude možné deklarovat dispečerem v rámci dispečerského programu a zároveň bude složení posádek zasíláno systémem zdravotnické dokumentace přes dohodnuté rozhraní, kde složení deklarují posádky. Deklarace posádek bude sestávat z: • Výjezdové skupiny - s deklarovaným názvem - přiřazeným stanovištěm s určenou oblastí/okresem - telefonním číslem linky pro předávání výjezdů - telefonním číslem mobilního telefonu - volacím znakem analogové radiostanice • Vozidlem - s deklarovaným popisem - volacím znakem vozidlové analogové radiostanice • členů posádky ve složení - lékař - NLZP - Řidič - NZP/ostatní	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 17	Správa číselníků	Správa sdílených číselníků bude prováděna v jednom ze systémů pro všechny systémy společně. Specifické číselníky budou spravovány v rámci určité aplikace. Veškerá správa číselníků musí být ošetřena přístupovými právy.	Řešení Uchazeče tuto funkcionalitu splňuje
Integrace
OŘ 18	Systém zdravotnické dokumentace	Oboustranné napojení na stávající systém zdravotnické dokumentace. Seznam minimálního rozsahu přenášených položek je deklarován v Příloze 2. Kromě oboustranného přenosu informací o výjezdu, bude navíc přenášeno obousměrně složení posádek (na dotaz ZD je získáno aktuální složení, ZD zasílá složení nové) a také jednosměrně ZD bude zasílat statusy získané ze systému mobilního řešení.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 19	Simulovaný systém sledování provozu vozidel	Simulované zasílání souřadnic vozidel do systému u všech přihlášených posádek. Zobrazení vozidel včetně statusu	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 20	GIS klient	• GIS klient -> OŘ: - Převzetí souřadnic a místopisu do systému OŘ na základě manuální lokalizace polohy událostí • OŘ-> GIS klient: - Zobrazení simulovaných poloh vozidel a jejich statusů - Zobrazení místa probíhajících událostí včetně grafického symbolu události	Řešení Uchazeče tuto funkcionalitu splňuje

		- Zobrazení události a záznamu na základě požadavku dispečera - Provázání místopisu OŘ na GIS klienta
OŘ 21	RÚIAN	Lokalizace události bude využívat data registru adres RÚIAN	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 22	Telefonní ústředna integrace telefonie	V rámci integrace telefonní ústředny bude zajištěno: • Předání informace o čísle volajícího systému OŘ • Vyvolání telefonu výjezdové skupiny definované pevnou linkou a mobilním číslem, a to jak při výzvě, tak kdykoliv zvolením definované posádky v přehledu a volbou typu telefonního spojení	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 39	First responder	Simulovaný systémem First responderů v rozsahu: - automatický výběr událostí vhodných pro nasazení FR (na základě podmínek na bázi naléhavosti a indikace) - získání informace o oslovených FR simulovaného prostředí FR - získání informace o FR, kteří se do akce zapojili, včetně kontaktních údajů - vizualizace FR oslovených i zapojených v rámci GIS s definovanou anonymizací (skrytí identifikace nezúčastněných responderů)	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 41	Urgentní výzva	Aplikace musí umožnit odeslání „Urgentní výzvy“, tedy „výzvy k výjezdu“ před získáním všech informací od volajícího a to na „jedno tlačítko“. Systém po nabrání adresy místa zásahu vygeneruje událost s předdefinovanou Indikací a Naléhavostí, která je okamžitě předána dispečerským pracovištím k vyslání posádky.	Řešení Uchazeče tuto funkcionalitu splňuje
OŘ 42	Metronom	Za účelem korektního poskytování TANR, musí aplikace umožňovat spuštění vizuální a akustické podpory, kdy je v definované frekvenci znázorněn korektní interval pro provádění nepřímé masáže srdce.	Řešení Uchazeče tuto funkcionalitu splňuje

- Uživatelský interface IS Dispečer RCS

V této kapitole Xxxxxxx prezentuje Zadavateli náhled na grafický vzhled aplikace Dispečer RCS. Jde pouze o příklad, kompletní popis systému je rozsáhlý a bude Zadavateli dodán v rámci realizace.

Vzhled aplikace lze plně konfigurovat – umístění jednotlivých dokovatelných oken, umístění otevíracích oken, rozložení gridů, zobrazování sloupců v gridech a atp. Výsledné rozložení pak lze uložit jako defaultní pro celé

OŘ, nebo pro jednotlivé uživatelské role. Uživatel může mít nastaveno více rolí, mezi rolemi se pak lze přepínat online bez nutnosti odhlášení a opětovného přihlášení. Aplikace po změně role překreslí okna do příslušného

rozložení.

Ukázka rozložení obrazovky pro roli Dispečer:

<.. image(Počítačem generovaný alternativní text: I.-)l )flfl)IA — — —— ,,.._. — •. 1 ? 0 — c.__ ?t .. — — ‘— —— —— — F . .. — — — ..: : *.. .... — w ! —..—— . — ...—— —— •w JJi ,-,.. ..I .- Nfl. XS 4 .a. J .. I. pS. b.I 1 —— — •1 se ZmcaopfIpadu dEl iAZ _ -- . trn .L . . , . — — v___ W W JI — ——— — ‘— ‘C.. —a— 0) removed ..>

Ukázka rozložení obrazovky pro roli Call-taker

<.. image(Počítačem generovaný alternativní text: — _____ Q -O — ,.— ——— ..,__. —. .—. — e,,__ —— c’— — . c._ —‘ p,,. — -— *_ — — — — b... _.I — — — —. ,.. .. —.—. —‘— ———. $?d —‘ :- m——.,-- -— .4n_ X;r.4L , La.. —— — a j,.ea Ikazuch. 1O41:4 ?OO4 — a_. 4 O .. 0 ( — . wwrrzT I I II • 1) F” I I.—--I’- I——.-I 0I . • •1, .. .. .. --- - — • •9 i ; •&e — -- - — •, i&9 •1.,;;9 m - — SL •&•. ——‘ •i, • . ii. 9 •I- •1 I-IXII 0.1 •.Iq.. . — —) removed ..>

Ukázka okna s integrovaným GIS

Důležitá okna/panely aplikace jsou dokovatelné. Lze jej rozmístit na libovolný počet obrazovek a seskupit dle potřeby vedle sebe, pod sebe, nebo do záložek.

Příklady dokovatelných oken

• Aplikační zprávy

• Detail případu

• GIS

• Komunikátor

• Nástěnka

• Nejbližší výjezdové skupiny (návrh vhodných volných VS s nejkratším dojezdem)

• Panel avíz (panel ručně spouštěných konfigurovatelných akcí)

• Panel spolupráce – zahrnuje spolupráci s NIS, FR, ostatními složkami

• Panel tlačítek (tlačítka pro rychlé změny stavu vybrané VS)

• Přehledy případů

o Přehled nabíraných případů

o Přehled čekajících případů

o Přehled plánovaných případů

o Přehled právě řešených případů

o Přehled uzavřených případů

• Přehledový panel posádek (konfigurovatelný, vizualizace VS)

• Přehledový panel složek (konfigurovatelný, vizualizace složek včetně FR)

• Přehrávač záznamů

• Volná lůžka

• Vstupní fronta

• Zprávy k případu (příjem, potvrzování a odesílání zpráv s možností filtrace na subsystém)

o Ručně vkládané zprávy dispečinku

o SMS

o Systémové zprávy s vazbou na případ

o Zprávy na pager

o Zprávy z/do navigace

o Zprávy z/do NIS

o Zprávy z/do O2 SOS (FR)

Příklady otevíracích oken

• Kontakty (možnost dohledání kontaktu, odeslání SMS, emailu)

• Log přehrávání záznamů uživateli

• Log synchronizace do dokumentace

• Log vyrozumívacího systému

• Log datových vět z/na NIS

• Log zpráv z mobilní Záchranky

• Místopisný helper pro vyhledávání adres

• Návrhář posádek

• Okno pro editaci posádky

• Okno pro rychlou editaci pacienta

• Okno pro velkou editaci případu (vč. časů VS a pacientů)

• Okno pro založení nového případu

• Okno pro založení uzavřeného případu

• Přehled odstraněných případů

• Přehled zlomyslných hovorů

• Přijaté a odeslané SMS

• Seznam výjezdových skupin v systému

• Seznam First responderů v systému

• Seznam složek IZS v systému

• Seznam indikací

• Seznam charakterů případu

• Seznam příznaků případu

• Zprávy z mobilní aplikace

Příklady rychlých voleb kontextových menu

• Případ

o Telefonický hovor oznamovateli

o SMS oznamovateli

o Telefonický hovor 3. Ruka

o SMS 3. Ruce

o Zobrazení logu DV z/na NIS

o Zaměření v GIS

o Přeposlání případu do Zdravotnické dokumentace

• Pacient

o Generování žádanky o transport

o Odstranění pacienta

o Přeposlání do Dokumentace

o Vyřešení pacienta

• Výjezdová skupina

o Odeslání SMS

o Odvolání VS od případu

o Opětovný tisk PKV

o Přeposlání do Zdravotnické dokumentace

o Sledování auta v GIS

o Telefonický hovor výjezdové skupině

o Zrušení rendez-vous

o Zaměření v GIS

Výše uvedené seznamy nejsou kompletní, jde pouze o příklady. Podrobný a kompletní popis systému bude Zadavateli dodán v rámci realizace projektu.

- Integrovaný GIS

Nabízené řešení zahrnuje jak moduly vlastního operačního řízení, tak úzce integrované moduly GIS. GIS moduly tohoto komplexního IS OŘ splňují veškeré funkční i nefunkční požadavky uvedené v zadávací dokumentaci na

tuto veřejnou zakázku a požadovaný rozsah funkcionalit díky úzké vzájemné integraci operačního dispečinku a GIS dokonce překračují.

Řešení tedy bude dodáno včetně vlastních modulů a klienty GIS při splnění všech funkčních i nefunkčních požadavků uvedených v zadávací dokumentaci a pokrytí všech stávajících funkcionalit GIS zadavatele.

Po celou dobu podpory bude, kromě samotné servisní podpory software, zajištěno následující:

▪ Mapové podklady a objekty RUIAN budou přebírány ze stávajícího prostředí GIS nebo NIS IZS, v případě potřeby budou uchazečem zajištěny aktualizace mapových podkladů a prvků RUIAN v minimálně čtvrtletním intervalu.

▪ Bude zajištěn stávající rozsah zakládání událostí z GIS (vyhledávání místa události min. ve stávajícím

rozsahu, zobrazení událostí a jejich stavu v mapě dle stávajícího rozsahu, vizualizace spolupracujících First responderů, stávající rozsah POI, pomístních názvů apod.),

▪ GIS bude obsahovat rozhraní pro dynamické zobrazení ať už jednobodových objektů (např. místo volajícího z AML) s volitelnou grafikou zobrazení, vrstev s více body (např. polohy vozidel apod.) a

vrstev pro vyznačení oblastí (např. čas doletu LZS apod.), interface bude řešen cestou webových služeb (SOAP, REST) nebo sdílenou databází s umožněním zápisu ze strany Zadavatele.

▪ Budou implementovány funkcionality stávajícího propojení GIS, jako

o zobrazení lokalizace volání z dat získaných od mobilních operátorů,

o zobrazení lokalizace pevných linek získaných ze systému Info35,

o zobrazení statusů vozidel a jejich kombinace s polohou vozidla zaslanou přes rozhraní definované v předchozím bodě.

GIS moduly nabízeného řešení IS OŘ jsou postaveny na standardní technologii užívané v rámci IS OŘ na

celorepublikové úrovni Hasičským záchranným sborem ČR a také částí zdravotnických záchranných služeb.

Nabízené GIS moduly IS OŘ přinášejí uživateli maximální uživatelský komfort, možnost přizpůsobení pracovního prostoru individuálním potřebám, vysokou rychlost odezvy, stabilitu a bezpečnost aplikace i možnost jejího využití v off-line režimu. Moduly se s využitím Internetu samy instalují a aktualizují a spojují tak výhody webových i desktopových aplikací spolu se zajištěním všech nutně vysokých nároků na takto kritické systémy.

3.4.3 Podpora výjezdových skupin

- Požadavek zadavatele

Informační systém musí zajistit na pracovištích výjezdových skupin minimálně tyto procesy:

• Příjem výzvy k výjezdu na výjezdovém stanovišti

Požadavek

Popis

VS 01

Předání výzvy k výjezdu

Předání výzvy k výjezdu bude sestávat z následujících kroků:

• Předání výzvy do systému zdravotnické

dokumentace a následně do systému mobilního řešení pro zpracování zdravotnické dokumentace, včetně její případné aktualizace

• Počet výjezdových skupin nebude omezen

- Popis nabízeného ỉešení

Nabízené řešení umožní předání výzvy k výjezdu z Dispečerského systému a jeho příjem na simulovaném výjezdovém stanovišti. Předání probíhá v několika krocích:

• odeslání výzvy do systému zdravotnické dokumentace,

• příjem výzvy v systému zdravotnické dokumentace

• předání do mobilního řešení

Řešení je dále rozšiřitelné například o tisk výzvy k výjezdu na tiskárně, případně o další integrace. Mezi řešením pro výjezdovou skupinu (DocServer + MobileDoc) existuje plná obousměrná integrace, která zajišťuje online

komunikaci mezi mobilním řešením, zdravotnickou dokumentací a systémem pro operační řízení. Znamená to, že úpravy provedené u výjezdu v IS OŘ jsou online přenášeny směrem k výjezdové skupině a naopak. Typicky se jedná například o úpravu posádky, adresy události, dalších informací o události, informací o pacientovi, nebo

stavu výjezdu.

3.4.4 Integrace telefonie a radiofonie

- Požadavek zadavatele

Klientská aplikace ovládání rádií bude:

• integrována do prostředí touchscreen, tedy musí splňovat integrační požadavek na běh aplikace v rámci prostředí touchscreenu

otevřít příposlech kanálu, signalizovat jasně příchozí volání včetně volacího znaku volajícího, kanálu na kterém volá apod., možnost práce volitelně v otevřeném a uzavřeném režimu atp.)

• nabízet funkce pro integraci do IS tak, aby spolu s IS tvořil funkční celek a byly splněny všechny požadavky na funkčnost IS ve vztahu k radiostanicím

• zvukový výstup a vstup musí být realizován přes vstup a výstup audiopropojovacího pole

	Požadavek	Popis
INT 01	Analogová stanice	Integrace na systém OŘ musí umožnit selektivní volbu radiostanice posádky na základě výzvy posádce a také přes volbu na panelu posádek
INT 02	Telefonie	Systém předávání hovorů musí zohlednit tyto stavy dispečera: • není přihlášen (není dostupný) • má hovor (nesmí mu být přepojen hovor, je ve stavu zaneprázdněn) • volný • aplikace IS OŘ je spuštěna, je možno zahájit příjem TV (zrušení stavu zaneprázdněn) • pracovník má aktuálně rozpracovanou událost, která ještě nebyla předána do IS OŘ, je tedy nutné pozdržet příjem dalšího volání (do předání události je pracovník ve stavu zaneprázdněn).
INT 03	Nahrávání telefonie	Integrace musí umožnit provázání události se záznamem a umožnit přehrání, nebo alespoň výběr přidruženého hovoru v externí aplikace přímo ze systému OŘ.

- Popis nabízeného ỉešení

Integrace telefonie a radiofonie splňuje veškeré požadavky Zadavatele. Speciálně pro účely integrace bude nasazena aplikace Panel 6 pro dotykové obrazovky. Tato aplikace umožňuje jednoduché ovládání v prostředí dotykového monitoru. Veškeré prvky jsou konfigurovatelné co do velikosti a umístění a logika ovládání

maximálně usnadňuje práci operátora. Zvukový vstup a výstup je realizován přes vstup a výstup audiopropojovacího pole.

Některé ovládací prvky jsou integrovány i do dispečerské aplikace, tak aby operátor v okamžiku vizualizace

telefonního kontaktu byl schopen přímo z daného místa vyžádat vytočení telefonického hovoru, nebo odeslání

SMS. V dispečerské aplikaci lze rovněž přijmout příchozí hovor s převzetím telefonního čísla volajícího.

Integrace splňuje následující požadavky:

- selektivní volba radiostanice posádky na základě výzvy posádce

- indikace stavu telefonie a zohlednění stavu dispečera:

o není přihlášen (není dostupný)

o má hovor (nesmí mu být přepojen hovor, je ve stavu zaneprázdněn)

o volný

o aplikace IS OŘ je spuštěna, je možno zahájit příjem TV (zrušení stavu zaneprázdněn)

o pracovník má aktuálně rozpracovanou událost, která ještě nebyla předána do IS OŘ, je tedy nutné pozdržet příjem dalšího volání (do předání události je pracovník ve stavu

zaneprázdněn).

- provázání události se záznamem (probíhá primárně automaticky, lze i ručně)

- přehrání záznamu

3.5 Požadavky na systém MZD a EKP ZZS

3.5.1 Společné funkcionality EKP a MZD

- Požadavek zadavatele

• Přenos informací o výjezdu ze systému OŘ,

• využití společných číselníků s IS OŘ včetně společné autentizace, a to i vůči Active Directory,

• omezení přístupu k záznamům na výjezdy kde je přihlášený členem posádky,

• vygenerování a tisk dokumentace minimálně v rozsahu Přílohy 3,

• přenos dokumentace k dalšímu zpracování na server pro zpracování v rámci EKP a účely statistiky a předání zpět do OŘ,

• plnohodnotná licence serverové i klientské části minimálně pro dvě zařízení,

• generování a tisk podpůrné dokumentace výjezdu včetně zajištění přenosu jejich dat na server, minimálně:

- vyúčtování výjezdu,

- negativního reverzu,

- iktové karty,

- protokolu KPR.

	Požadavek	Popis
ZD 01	Dodávka MZD a EKP	Dodávka MZD a EKP

- Popis nabízeného ỉešení

Nabízené řešení EKP a MZD je plně obousměrně integrované na IS OŘ. Komunikuje na bázi společných číselníků

v online režimu. Změny jsou online propgovány z jednoho systému do druhého, takže jak posádka, tak

dispečink mají okamžitý přehled o aktuálním stavu události. Synchronizace číselníků rovněž probíhá okamžitě po změně.

Systém disponuje centrální administrací uživatelů s možností konfigurace uživatelských oprávnění k jednotlivým agendám. Uživatelské přístupy lze omezit pouze na záznamy o výjezdech, kde je přihlášený uživatel členem posádky.

Záznam o výjezdu bude implementován minimálně v rozsahu na obrázku níže:

Systém disponuje možností generování statistik a dokumentace pro další zpracování, nebo podpůrné

dokumentace k výjezdu např.:

- vyúčtování výjezdu,

- negativního reverzu,

- iktové karty,

- protokolu KPR

- roční statistika pro ÚZIS,

- obecné statistiky počtu výjezdů,

- statistika LZS

- apod.,.

Bude dodána plnohodnotná licence serverové i klientské části minimálně pro dvě zařízení.

3.5.2 Specifické požadavky na MZD

- Požadavek zadavatele

- Možnost off-line zpracování bez datové konektivity po načtení informací k výjezdu,

- získání lokalizačních informací a mapy místa zásahu s vyznačením místa události,

- ovládání aplikace je řešeno jako maximálně přehledně a intuitivní za účelem co nejvyšší možné rychlosti zpracování,

- vygenerování dokumentace do PDF nebo libovolné tiskárny,

	Požadavek	Popis
ZD 02	Požadavky na MZD	Specifické požadavky na mobilní zadávání dat

- Popis nabízeného ỉešení

Uchazeč splňuje všechny výše uvedené požadavky Zadavatele.

3.5.3 Specifické požadavky na EKP

- Požadavek zadavatele

Krom modulu pro zpracování dokumentace musí být součástí dodávky také:

- modul pro sestavení posádky v rámci OŘ ze strany členů posádky (posádka na začátku směny zapíše do systému OŘ sestavení posádky včetně vozidla,

- modul přístrojů – simulované evidence přístrojové techniky s možností přiřazení posádce při přihlášení,

- modul pro správu číselníků a uživatelů s vazbou na OŘ,

- statistické výstupy pro simulovaný statistický výstup nad vloženými daty.

	Požadavek	Popis
ZD 03	Požadavky na EKP	Dodávka systému EKP včetně specifikovaných modulů.

- Popis nabízeného ỉešení

Uchazeč splňuje všechny výše uvedené požadavky Zadavatele.

3.6 Simulace prostředí operačního střediska

- Požadavek zadavatele

Jelikož simulované operační středisko nebude přijímat reálné hovory ani nebude napojeno na NIS IZS pro

příjem reálných datových vět, je třeba vytvořit simulované prostředí, které bude vytvářet vstupní informace jako podklad pro rozhodování dispečerů. Ty budou buď vytvářeny lektorem, ať už telefonním hovorem na vstupní GSM bránu nebo vytvořením datové věty a zároveň je třeba vytvořit aplikace, které umožní ze zásobníku předat hovor nebo datovou větu xxxxxxxxxxxx ve výcviku.

Požadavek

Popis

SP 01

Hovor na vstupní GSM bránu

Hovor na vstupní GSM bránu bude směrován na studenta

přihlášeného v režimu calltakera.

SP 02	Manuální odeslání datové věty	Lektor bude mít prostředek pro manuální vytvoření a odeslání simulované datové věty, která bude calltakerům avizována jako nová událost, včetně možnosti následné aktualizace a odeslání datové věty změnové. Datová věta může vzniknout v samostatném formuláři nebo založením události v prostředí systému OŘ a odesláním v režimu simulace příjmu „z jiného dispečinku“.
SP 03	Předání zvukové nahrávky	Lektor bude mít k dispozici knihovnu nahrávek, které bude mít možnost zaslat na pracoviště calltakera. Optimální je přehrát nahrávku do telefonního přístroje calltakera, povoleno je ale i řešení přehrání zvukového souboru v počítači na kterém bude calltaker přihlášen. Oba režimy musí umožnit tento proces spustit lektorem vzdáleně v době požadavku lektora na spuštění.
SP 04	Předání datové věty z knihovny	Lektor bude mít k dispozici knihovnu datových vět, které bude mít možnost zaslat na pracoviště calltakera v libovolném čase. Systém umožní také zaslání jiné datově věty z knihovny jako změnové k již zaslané.
SP 05	Simulace režimu FR	Systém bude simulovat náhodně pohyb responderů a zobrazovat jejich pohyb v mapě. V případě, že se responder vyskytne v definovaném okolí události, bude automaticky do akce zapojen, pokud událost splní podmínky pro zapojení responderů.

- Popis nabízeného ỉešení

Samostatným simulátorem procesů ZZS aktuální verze IS OŘ nedisponuje. Bude však vyvinut dodatečně na

stejných principech a nástrojích jako samotný IS OŘ. Způsob provedení a integrace bude po zahájení projektu zkonzultován se Zadavatelem, tak aby práce se systémem pro něj byla jednoduchá a intuitivní. Lze volit

variantu samostatné aplikace, nebo rozšíření některé ze stávajících. Rovněž lze volit z možnosti vyvinout tlustého klienta v C++ a SOAP služeb, nebo tenkého klienta ve webových technologiích a REST služeb.

Předpokládáme, že stran samotné funkcionality bude mít uživatel následující možnosti:

• Přihlašování přes jednotnou databázi uživatelů

• Simulace příchozího hovoru na pracoviště call takera

• Odeslání nové události ze simulátoru (událost bude předem založena a bude možno její odeslání naplánovat v rámci scénáře, nebo vyvolat manuálně)

• Odeslání změnové datové věty k již založené události

• Veškeré datové věty (nové události i změnové) bude mít lektor možnost předem připravit a zsílat je manuálně, nebo bude mít možnost si připravit jejich sekvenci složenou v rámci pojmenovaného

scénáře. Tento scénář bude možno spustit, pozastavit, nebo zrušit.

• Systém bude simulovat pohyb responderů a bude jej vizualizovat v integrovaném GIS.

• V rámci simulátoru bude možno definovat podmínky pro automatické zapojení first respondera k události.

• Pro pokročilé uživatele se znalostí rozhraní na IS OŘ Uchazeč vyvine prvek, v rámci kterého bude možné odeslat do IS OŘ volání jakékoli metody rozhraní na IS OŘ. To umožní tvorbu pokročilých

scénářů, ve kterých bude možno např. změnit obsazení vybrané posádky, odeslat status výjezdové skupiny, odesílat různé typy zpráv pro uživatele apod.

Požadavky na testovací provoz, dokumentaci a rozsah školení

3.7.1 Dokumentace a testování

- Požadavek zadavatele

Délka testovacího provozu bude 10 dní.

Při převzetí bude dodána dokumentace systému v rozsahu:

• Popis funkčnosti zařízení a systémů z pohledu uživatele tak, aby byl uživatel schopen práce s

předmětem plnění. Pokud je předmět plnění integrován s jiným systémem, dokumentace bude

obsahovat i popis napojení předmětu plnění na další systém v rozsahu nezbytném z hlediska práce uživatele.

• Popis předmětu plnění z hlediska jeho zapojení do stávající infrastruktury a informačního systému (rozhraní a služby), včetně popisu jeho správy, údržby.

• Popis administrativních úloh a možných nastavení systému.

• Zápisy z jednání

- Popis nabízeného ỉešení

Délka testovacího provozu bude 10 dní.

Při převzetí bude dodána dokumentace systému v rozsahu:

• Uživatelské příručky k jednotlivým dodaným systémům - Popis funkčnosti zařízení a systémů z pohledu uživatele tak, aby byl uživatel schopen práce s předmětem plnění. Pokud je předmět plnění integrován s jiným systémem, dokumentace bude obsahovat i popis napojení předmětu plnění na další systém v rozsahu nezbytném z hlediska práce uživatele.

• Technickou dokumentaci systému - Popis předmětu plnění z hlediska jeho zapojení do stávající infrastruktury a informačního systému (rozhraní a služby), včetně popisu jeho správy, údržby.

• Příručky administrátora k jednotlivým dodaným systémům - Popis administrativních úloh a možných nastavení systému.

• Zápisy z jednání konaných během realizace projektu.

• Popis rozhraní IS OŘ – popis SOAP a REST rozhraní využitelný zejména pro pokročilé administrátory systému.

3.7.2 Školení

- Požadavek zadavatele

• školení uživatelů pro 5 účastníků v rozsahu max. 1 den

• školení administrátorů v max. rozsahu 4 hod.

Veškeré náklady na zajištění školení musí být zahrnuty v ceně odpovídající části předmětu plnění.

- Popis nabízeného ỉešení

Uchazeč zajistí proškolení pracovníků zadavatele v následujícím rozsahu:

• Školení 5 účastníků v max. rozsahu 1 den v místě u Zadavatele

• Školení administrátorů v max. rozsahu 4 hod. v místě u Zadavatele

• Doškolení pracovníků zadavatele v rozsahu dle potřeby prostřednictvím videokonference. Termín a obsah bude stanoven po dohodě mezi Zadavatelem a Uchazečem.

Veškeré náklady na školení jsou zahrnuty v ceně nabízeného předmětu plnění.

3.8 Odezva a kapacita systému

- Požadavek zadavatele

očekáváném počtu výjezdu 10 tis. ročně. Kapacita pro záznam hovorů musí být minimálně 500GB.

- Popis nabízeného ỉešení

Systém je navržen tak, aby v podmínkách Zadavatele během doby udržitelnosti byly jednak zachovány odezvy systému na základní operace do max. 2s a jednak, aby nejméně na dobu udržitelnosti nebyla překročena

kapacita databáze. 10 tis. Záznamů ročně je z pohledu řešení Zadavatele zanedbatelný objem dat. Databáze bude dimenzována tak, aby byly uchovány nejméně 3 měsíce veškeré auditní záznamy mapující práci uživatelů.

Další nezanedbatelnou položkou je databáze RUIAN obsahující veškerá adresní místa, stavební objekty a parcely v České republice.

3.9 Záruční a servisní podmínky

- Požadavek zadavatele

Veškeré komponenty systému budou dodány se zárukou v délce udržitelnosti projektu, která je 5 let, která započne po finálním předání projektu, tedy ukončením zkušebního provozu.

zařízení obdobné konfigurace dodavatelem po dobu opravy. Notebook posádky bude dodán také se zárukou pokrývající náhodné rozbití.

Softwarové komponenty budou mít záruku ve dvou režimech:

- kompletní nefunkčnost, byť i některé komponenty systému zabraňující zcela práci všech uživatelů odstraní dodavatel nejpozději do 48 hodin od nahlášení problému,

- ostatní chyby a nesoulad se zadávací dokumentací odstraní zadavatel nejpozději do 14ti dnů od nahlášení dodavatelem.

- Popis nabízeného ỉešení

Uchazeč respektuje požadavky na záruční a servisní podmínky Zadavatele uvedené výše v plném rozsahu.

Document Metadata

Table of Contents

Free Standard Templates

Kupní smlouva

Document Metadata

Free Standard Templates

Kupní smlouva

1. Smluvní strany

Kupující: Ostravská univerzita

Prodávající: RCS Kladno, s.r.o.

2. Základní ustanovení

3. Předmět koupě

3.2. Prodávající se zavazuje odevzdat kupujícímu předmět plnění uvedený v čl. 3.1. a umožnit kupujícímu nabýt k předmětu plnění vlastnické právo. Kupující se zavazuje předmět plnění převzít a zaplatit prodávajícímu kupní cenu.

3.3. Jakost, provedení, vlastnosti a další specifikace předmětu plnění včetně jeho množství jsou uvedeny v Příloze č. 1 smlouvy.

3.5. Prodávající prohlašuje, že:

3.6. Prodávající je při realizaci předmětu plnění veřejné zakázky povinen dodržet platné technické normy a ekologické požadavky a veškeré použité obaly budou šetrné k životnímu prostředí.

4. Lhůta, místo a způsob plnění

4.1. Prodávající je povinen odevzdat předmět plnění ve lhůtě do 18 týdnů od výzvy kupujícího k poskytnutí plnění.

4.2. Místem odevzdání předmětu plnění je Lékařská fakulta Ostravské univerzity, Syllabova 19, 703 00 Ostrava 3 (dále také „místo plnění“ nebo „místo dodání“).

4.3. Osobou oprávněnou za prodávajícího je Xxx. Xxxxxx Xxxxxxxxxx, e- mail: xxxxxx.xxxxxxxxxx@xxx-xxxxxx.xxx., tel.: 000 000 000.

4.4. Osobou odpovědnou za převzetí předmětu plnění je Xxx. Xxxxxx Xxxxxxxxxxx – biomedicínský technik – projekt Cvičná nemocnice, e-mail: xxxxxx.xxxxxxxxxxx@xxx.xx , tel. 000 000 000, mob. 000 000 000.

4.5. Odevzdání předmětu plnění bude potvrzeno podpisem oprávněných osob prodávajícího a kupujícího na protokolu o odevzdání předmětu plnění s uvedením data odevzdání předmětu plnění.

4.6. Kupující před převzetím předmětu plnění provede testovací provoz v délce 10 pracovních dnů.

5. Cena a platební podmínky

5.1. Celková kupní cena za předmět koupě dle čl. 3 této smlouvy byla dohodou smluvních stran stanovena ve výši:

bez DPH 3 466 278,00 Kč

DPH 727 918,38 Kč

s DPH 4 194 196,38 Kč

5.4. Prodávající je povinen zasílat faktury elektronickými prostředky na adresu xxxxxxxx.xxxxxxx@xxx.xx.

5.5. Povinnost kupujícího uhradit fakturu je splněna dnem odepsání příslušné částky z účtu kupujícího.

5.6. Prodávající přebírá nebezpečí změny okolností ve smyslu § 1765 odst. 2 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“).

5.7. Kupující neposkytne prodávajícímu žádnou zálohu.

6. Smluvní pokuty

6.2. V případě prodlení prodávajícího s plněním povinností stanovených v čl. 8.12. této smlouvy je kupující oprávněn požadovat na prodávajícím smluvní pokutu ve výši 300 Kč za každý i započatý den prodlení.

6.3. V případě prodlení kupujícího s úhradou faktury proti sjednanému termínu je prodávající oprávněn požadovat na kupujícím smluvní pokutu ve výši 0,1 % z dlužné částky za každý i započatý den prodlení.

6.4. Uplatněním nároku na smluvní pokutu není dotčeno oprávnění kupujícího požadovat náhradu škody způsobenou porušením povinnosti ze

7. Nebezpečí škody na předmětu plnění a přechod vlastnictví

7.1. Nebezpečí škody na předmětu plnění a vlastnické právo k předmětu plnění přechází na kupujícího v okamžiku jeho převzetí kupujícím.

8. Záruka za jakost, Práva z vadného plnění

8.1. Předmět plnění je vadný, neodpovídá-li této smlouvě.

8.2. Práva kupujícího z vadného plnění zakládá vada, kterou má předmět plnění v době jeho odevzdání, v době mezi odevzdáním předmětu plnění a počátkem běhu záruční doby nebo v záruční době.

8.3. Smluvní strany sjednávají, že předmět bude odpovídat této smlouvě i po smluvenou záruční dobu.

8.6. Záruční doba dle předchozího odstavce neběží po dobu, po kterou kupující nemůže předmět plnění užívat pro vady, za které odpovídá prodávající, tedy i z důvodu jejich řešení.

8.7. Má-li předmět plnění vadu (vady) má kupující právo:

8.9. Prodávající se zavazuje prověřit reklamaci a do 3 pracovních dnů ode dne jejího doručení oznámit kupujícímu, zda reklamaci uznává. Pokud tak prodávající v uvedené lhůtě neučiní, má se za to, že reklamaci uznává a že vadu odstraní v souladu s touto smlouvou.

8.10. I v případech, kdy prodávající reklamaci neuzná, je povinen vadu odstranit. V takovém případě prodávající kupujícího písemně upozorní, že se vzhledem k neuznání reklamace bude domáhat úhrady nákladů na odstranění vady od kupujícího.

8.13. Smluvní strany se zavazují poskytovat si navzájem při odstraňování vad předmětu plnění veškerou potřebnou součinnost tak, aby byly vady řádně a včas odstraněny. Prodávající je povinen zejm.:

8.15. Uplatnění práv z vadného plnění kupujícím, jakož i plnění jim odpovídajících povinností prodávajícího není podmíněno ani jinak spojeno s poskytnutím jakékoli další úplaty kupujícího prodávajícímu, příp. jiné osobě.

9. Ostatní ujednání

9.2. V souladu s ustanovením § 219 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, Kupující uveřejní na svém profilu zadavatele smlouvu včetně všech jejích změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.

9.4. Tato smlouva nabývá platnosti dnem jejího uzavření a účinnosti dnem uveřejnění smlouvy v Registru smluv. O této skutečnosti Kupující Prodávajícího uvědomí.

9.5. Prodávající je dle ustanovení § 2 písm. e) zákona č. 320/2001 Sb.,

9.7. Prodávající je povinen umožnit všem subjektům oprávněným k výkonu kontroly projektu, z jehož prostředků je dodávka hrazena, provést kontrolu

9.8. Ve věcech touto smlouvou výslovně neupravených se bude tento smluvní vztah řídit ustanoveními obecně závazných právních předpisů, zejména občanským zákoníkem a předpisy souvisejícími.

9.9. Smlouva je vyhotovena ve dvou stejnopisech s platností originálu a každá ze smluvních stran obdrží po jejich podpisu jedno vyhotovení, pokud je smlouva uzavřena v listinné podobě.

9.10. Tato smlouva může být měněna nebo doplňována pouze písemnými číslovanými dodatky podepsanými oprávněnými zástupci obou smluvních stran.

9.15. Ustanovení 9.12. až 9.14. se týkají Prodávajícího, kterému je přiděleno české DIČ.

9.16. Prodávající je povinen kupujícímu uhradit veškerou škodu, která mu vznikne nedodržením povinností uvedených výše v tomto článku, a navíc je kupující oprávněn odstoupit od této smlouvy. Odstoupení se stává účinným dnem jeho doručení prodávajícímu.

9.17. Smluvní strany po přečtení smlouvy potvrzují, že obsahu smlouvy porozuměly, že smlouva vyjadřuje jejich pravou, svobodnou a vážnou vůli, nebyla uzavřena v tísni či za nápadně nevýhodných podmínek a na důkaz této skutečnosti ji podepisují.

1. Definice pojmů a zkratek

Použité zkratky

2. Předmět specifikace

3. Specifikace předmětu plnění

Architektura řešení

Hardwarové komponenty systému

Obecné požadavky na SW řešení

Požadavky na systém OŘ ZZS

Požadavky na systém MZD a EKP ZZS

Simulace prostředí operačního střediska

Požadavky na testovací provoz, dokumentaci a rozsah školení

Odezva a kapacita systému

Záruční a servisní podmínky

Document Metadata

Related content

Similar Contract Types

Most Common Clauses in Kupní Smlouva