Příloha č. 1a smlouvy o dílo - Technická specifikace předmětu plnění

Obsah

1) Předmětem plnění této veřejné zakázky je dodávka a implementace informačních systémů IS OŘ a dalších navazujících technologií a služeb pro zajištění řádné realizace informačních systémů IS OŘ.

2) Základní části předmětu plnění jsou uvedeny v následující tabulce:

Ozn.	Položka	Doplňující popis	Ks
Sál pro operační řízení
OS-07	Stoly pro dispečery	Stůl zvedací s elektrickým ovládáním zvedání a rovnou plochou, manuálně otočný	12
Technologické zázemí
PR-02	Virtualizovaný desktop pro OŘ	Sdílená RAM 2GB, 4x grafická karta, 1 x zvuková karta, mirror, podíl na sdíleném serveru	12
PR-05	Operátorské pracoviště hybridní	3 LCD matné 24“ FHD s audio lištou, 1x dotykový, náhlavní handsfree-set	6
PR-07	Přepínač maticový pro ostatní pracoviště	přepínač audio, mix, repro, eliminace zpětné vazby, přepínač video, zesilovač, terminál VoIP	6
DC-05	Rackové skříně 19" 800*1000 (41 U)	Standard (bez chlazení), signalizace otevření, krytování a montáž do tzv. uličky pro zajištění společného chlazení, vč. montáže.	6
EN-02	UPS	30kVA, online včetně akumulátorů (30minut)	2
DC-07	Síťové prvky (mimo NSPTV)	Switche	2
EN-03	Dohledové systémy		1
Radiová síť PEGAS
DR-01	Integrace sítě PEGAS	LCT, zásuvné moduly, RCT, antény, konektory, SW, včetně integrace do IS OŘ	1
DR-03	Pevné radiostanice 3G	Vybavení jednoho pracoviště (každého stolu) bude obsahovat: 1 RCT, montážní sadu, zdroj, anténu, svod antény, konektory	12
DR-04	Vozidlová radiostanice 3G	Vozidlový terminál s montáží	19
DR-04b	Ruční radiostanice s kitem	Terminál s kitem pro montáž do vozidla. Vybavení vozidla buď vozidlový 33terminál nebo ruční+kit.	84
Telefonie
OB-01	Pobočková ústředna OŘ	Samostatná PBX nebo rozšíření NSPTV, VoIP, 4 ISDN, GSM brána, max. 128 vnitřních linek vč. SW	1
OB-02	Nahrávání (všechny kanály OŘ)	Nahrávání telefonů, radio digital, radio analog, hlasový příkaz, Včetně konektorů na jednotlivé linky. Řešeno jako xxxxxxx XX+SW jako investiční celek.	1
OB-03	Příčka – PBX OŘ objektová ústředna	Propojení ústředny pro OŘ s objektovou ústřednou.	1
Výjezdová stanoviště a vozidla
VT-01	Vozidlové GPS	GPS, jednotka pro datový přenos, příslušenství, přesnost status, licence	84
VT-02	Tablet posádky	12”, odolný, vč. OS a licence SW, tiskárna	56
VT-03	Interface k přístrojům	Docking station pro tablet, zástavba vzadu ve vozidle	84
VT-04	Vozidlová LAN s konektory	Vozidlová LAN	84
Informační systémy
IS-01	HW kompletně	Servery diskové pole, zdroje, chlazení	1
IS-02	Databáze, virtualizace, replikace SW	SW licence pro všechny servery	1

Ozn.	Položka	Doplňující popis	Ks
IS-03	Informační 4systém – vývoj a integrace – bez integrace s NIS IZS	IS pro OŘ, vývoj, nové funkčnosti, licence, včetně IS pro podporu tabletů	1
IS-05	Integrace telefonie – bez integrace s NIS IZS	Integrace telefonie	1
IS-04	Zálohování		1
IS-15	Jiné technologické doplnění IS	SW pro mobilní zadávání dat	1

Tabulka 1: Základní části předmětu plnění

3) Význačné parametry, které jsou v řešení ZZS JMK požadovány:

a) zajištění maximálně rychlého průchodu informací v systému od vzniku informace (např. tísňové volání) až po její výstup (např. informování posádky o nutnosti zásahu)

b) jednotná podpora procesů

c) zajištění vysoké míry dostupnosti a spolehlivosti systému

d) informační podpora pro poskytování přednemocniční neodkladné péče v terénu

e) respektování platné legislativy ČR a legislativních norem v době předání díla Xxxxxxxxxx.

4) Dostupnost a spolehlivost – kritické části systému musí být vysoce dostupné, tzn., že musí být zajištěna HW a SW prostředky jejich maximální odolnost proti výpadkům. Zadavatel požaduje zajistit níže uvedenou minimální požadovanou dostupnost a spolehlivost:

Subsystém	Provozní doba	Kritický subsystém
Operační řízení (SOŘ)	24x7 x 365 (nepřetržitý režim)	Ano
GIS klient	24x7 x 365 (nepřetržitý režim)	Ano
Systém sledování, provozu vozidel	24x7 x 365 (nepřetržitý režim)	Ano
Mobilní zadávání dat	24x7 x 365 (nepřetržitý režim)	Ano

Tabulka 2: Požadavky na dostupnost a spolehlivost

5) Uchazeč musí navrhnout dostatečně dostupnou a spolehlivou architekturu informačních systému IS OŘ s ohledem na:

a) Spolehlivost a stabilitu jednotlivých softwarových subsystémů/komponent.

b) Dobu určenou pro nutnou údržbu HW a SW subsystémů/komponent

c) Spolehlivost napájení jednotlivých hardwarových komponent

d) Spolehlivost jednotlivých hardwarových prvků a jejich komponent

e) Mechanismy zálohování dat

f) Požadovanou dostupnost serverových služeb 99,5%

6) Bezpečnost - IS OŘ musí zajistit vysokou bezpečnost, tj. každý uživatel musí mít přístup pouze k funkcionalitě a datům, která mu náležejí. Zároveň musí být systém navržen tak, aby jeho jednotlivé subsystémy měly vždy přístup pouze k té funkcionalitě a datům, které nutně potřebují.

a) Je požadováno zajištění odpovídající úrovně logování a auditu v souladu s platnou legislativou v době předání díla Xxxxxxxxxx.

b) Bezpečnostní politika IT prostředí ZZS JMK nedovoluje volný přístup do jiných datových sítí nebo na veřejný internet. Pokud některá část aplikace IS ZZS JMK bude požadovat datovou komunikaci s externí aplikací běžící mimo lokální síť, musí být pro ni vytvořen prostup. K definici tohoto prostupu

je nutné definovat IP adresu zdroje a cíle a číslo portu, prostřednictvím kterého bude aplikace komunikovat. Dodavatel řešení IS ZZS JMK musí respektovat tento způsob přístupu při návrhu komunikace IS ZZS JMK s externími aplikacemi.

7) Autonomnost - IS OŘ musí být navržen dostatečně autonomní. Systém musí zajistit funkcionality (byť omezené) i v případě nedostupnosti okolních systémů. Nelze připustit, že výpadek jednoho ze subsystémů znemožní použitelnost celého řešení.

8) Zálohování - Zadavatel požaduje, aby uchazeč navrhl způsob/strategii zálohování systému IS OŘ na úroveň jednotlivých subsystémů/modulů/komponent, tak aby v případě nutnosti bylo možno zprovoznit systém v co nejkratší době. Součástí zálohovací politiky je jak návrh odpovídajícího hardware, tak i metodika provádění záloh.

9) Xxxxxx s legislativou - je požadováno, aby předmět plnění byl v souladu s platnou legislativou ČR a souvisejícími normami, např. některé funkcionality dodávaného systému mají návaznost na ustanovení zákona č.101/2000 Sb. o ochraně osobních údajů a to v době předání Xxxx zadavateli.

10) Zajištění bezpečnosti předmětu díla - zadavatel požaduje zajištění bezpečnosti způsobem odpovídajícím předpokládanému užití a to minimálně v následujícím rozsahu:

c) Autorizace, autentifikace uživatelů a uživatelská oprávnění zajišťující přístup jen ke schváleným informacím a funkcím a to včetně návaznosti na ochranu osobních údajů.

d) Zabezpečení komunikace mezi moduly informačního systému, informačními systémy v rámci integrace a další výměně dat - preferovaná je integrace na principu webových služeb, které budou zabezpečeny protokolem SSL s použitím obousměrné autentizace.

e) Využití moderních principů ochrany a zabezpečení dat (principy zálohování) a provozu informačních systémů (redundance, FailOver a další).

11) Součástí předmětu plnění musí být i bezpečnostní dokumentace, která bude obsahovat detailní popis všech uvedených principů a to nejen ve vztahu k uživatelům, ale i ke správě informačního systému.

1.1.1 Stoly pro dispečery (OS-07)‌

1.1 Minimální požadavky na vybavení sálu pro operační řízení

Pracoviště dispečerů Zdravotnické záchranné služby Jihomoravského kraje bude situováno ve 3. nadzemním podlaží „nove budovy ZZS JMK v Brně Bohunicích. Zajištění prostor je předmětem „Stavby nové budovy ZZS JMK v Brně Bohunicích.

Dispečerská pracoviště budou řešena jako stolové desky, osazené na podnožích s motoricky měnitelnou výškou pracoviště pro práci ve stoje a sedě. Pracoviště budou variabilní tak, aby bylo možné vytvářet proměnné skupiny trvalých a záložních pracovišť.

Na pracovištích budou umístěny monitory, touchpad, klávesnice, audio komunikační zařízení, racková skříň a záložní vybavení v případě výpadku primárního systému (telefon, vysílačka, reproduktory). Pro instalaci technického vybavení budou sloužit dvě rackové skříně a instalační prostor podvěšený pod konstrukcí nesoucí pracovní desky. Ostatní technologická zařízení budou umístěna v navazující místnosti datového centra.

Pracovní prostředí prostor dispečinku bude zajištěn v rámci stavební připravenosti.

Dodávka musí zahrnovat 12 ks stolů pro dispečery zdravotnického operačního střediska a 1 manipulační vozík. Součástí dodávky bude výroby prototypu, který bude zadavateli předán k oponentuře.

1.1.1.1 Požadavky na technologické vybavení, konstrukční a materiálového řešení stolů pro dispečery

Pracoviště dispečerů je navrženo tak, aby poskytlo ochranu investovaných prostředků díky své dlouhé životnosti a snadné možnosti budoucího rozšíření nebo výměny poškozených částí. Řešení musí splňovat nejvyšší nároky na odolnost i ergonomii. Samotné pracovní stoly nebo řídicí konzoly musí splňovat nejvyšší

nároky na ergonomické řešení a současné evropské normy EN ISO 00000-0-0 (Ergonomické navrhování řídicích center) a EN 527 (kancelářský nábytek – pracovní stoly).

Pracoviště musí splňovat tyto vlastnosti:

a) Spojení vysoké funkčnosti a nadčasového designu.

b) Modulární koncepce musí umožnit snadnou budoucí změnu nebo výměnu některých dílů.

c) Dostatečně velké prostory pro zástavbu techniky do technického podstavce, do pracovní desky i nad pracovní desku. Snadný přístup přes odnímatelné panely.

d) Promyšlený svislý i horizontální kabelový management, prostupy pro vývod kabeláže z dvojité podlahy. Viditelné kabelové prostupy kryty kartáčovými průchodkami. Kabeláž mezi stolovou deskou s podvěšenými rackovými skříněmi a rozvody ve zdvojené podlaze bude vedena v navíjecím kabelovém řetězu.

e) Integrace s LCD monitory až ve třech úrovních nad sebou. Na stolech budou uchyceny 3x LCD 24“ a 1xdotykový LCD 19“-21“

f) Výška pracovní plochy pevná, manuálně stavitelná při montáži nebo motoricky nastavitelná pro změnu pracovní polohy vsedě – ve stoje (rozdíl výšek 500mm). Posun bude řešen dvojicí paralelně zapojených polohovacích sloupků s dvěma pohony s vertikálním zdvihem.

g) Sloupky musí umožnit snadné sestavení kompletního systému přidáním kontrolboxů a ovladačů. Ovladač bude umístěn pod hranou stolové desky. Rychlost posunu stolové desky 20mm/s.

h) Polohovací sloupek musí být navržen pro náročné provozy a zařízení zvedající velká zatížení - únosnost až 2500 N.

i) Pracovní plocha s odolným povrchem a s ergonomicky řešenou hranou. Povrch s malým odrazem od osvětlení a monitorů. Stolová deska je požadována z kompaktní laminátové desky tl. 20mm.

j) Možnost svázání jednotlivých stolů do rovné nebo obloukové řady

k) Tuhá základní konstrukce tvořená šroubovanými hliníkovými profily a ocelovými díly, povrchová úprava odolným práškovým lakem.

l) Korpus stolu - příprava pro umístění rackových skříní. Kompaktní laminát tl. 15 mm. Dvířka kompaktní laminát tl.10mm Dvířka do rackové skříně profrézována - ventilační štěrbiny š.10mm, osová vzdálenost 30mm, naložená na korpus, otvíravá, uzamykatelná. Všechny zámky 12-ti stolových pracovišť budou vybaveny jednotným klíčem. Korpus bude opláštěn (půda, bočnice dno).

m) Uchycení monitorů – uchycení monitorů na stojanech/držácích, které budou součástí dodávky stolů, musí splňovat VESA Standard

n) Součástí roznášecí podnože bude aretace stolu zajištěna rektifikačními šrouby

o) Zásuvkový kontejner - V.600MM/Š.400MM/HL.600MM, Korpus z kompozitního laminát 10 mm, horní deska přetažena přes horní zásuvku, pohledová záda, zásuvky výsuvné ocel s možnosti dělení, 1x tužkovník, čela zásuvek naložená, kompozitního laminát tl. 10mm, uzamykatelné, úchytky broušená nerez. Kolečka tvrdá, otočná, pouzdro kovové, min.únosnost 50kg/ks.

p) Manipulační vozík - V.600MM/Š.600MM/HL.755MM. Ocelová rámová konstrukce svařená z jäklu 60/40/4mmu. Transportní kolečka otočná s brzdou šroubována na roznášecí plech. dosedací plocha opatřena protiskluzným povrchem.

Zabudované vybavení stolů:
a) Racková skříň 600/600/500	2	ks
b) Výškový posuv stolu	2	ks
c) Kabelový řetěz	1	ks
d) Drátěný kabelový žlab	3	m
e) Retifikační šrouby	4	ks

Volné vybavení stolů:

a) LCD monitor + ergonomický úchyt	3	ks
b) Touchpad + ergonomický úchyt	1	Ks
c) Klávesnice	1	Ks
d) Sluchátka a mikrofon	1	Ks
e) Myš	1	Ks
f) Vysílačka + Reproduktory	1	Ks
g) Telefon	1	Ks
h) Kontejner	1	Ks

Bližší specifikace konstrukčního a materiálového řešení stolů pro dispečery je uvedena v příloze č. 1 tohoto dokumentu.

1.2.1 Virtualizovaný desktop pro OŘ (PR-02)‌

1.2 Minimální požadavky na technologické zázemí

Navržené řešení musí zahrnovat potřebnou dodávku HW a SW pro funkční realizaci virtualizovaných desktopů. Jednotlivá pracoviště musí umožňovat přihlášení daných uživatelů s načtením jejich individuálních nastavení. Virtualizované řešení zajistí absenci stolních PC v podobě towerů či minitowerů, uživatelé budou mít k dispozici pouze klávesnici, myš, 3 monitory a 1 touchscreen, drátové náhlavní sady a IP telefon (IP telefon není součástí dodávky, zajistí ZZS).

Celkový požadovaný počet pracovních stanic je 12. Dodaný HW musí být minimálně v následující konfiguraci:

a) operační systém – Originální Windows® Embedded Standard 7,

b) možnost připojení až 4 monitorů full HD (1920x1080) DVI,

c) podporovaný prohlížeč – Microsoft® Internet Explorer 8.0 a vyšší,

d) standardní velikost paměti – minimálně 2 GB DDR3 SDRAM,

e) velikost paměti ROM – minimálně 4 GB,

f) typ paměti ROM – Flash,

g) výrobcem podporované protokoly – Citrix ICA 12 (Citrix Online Plugin 12); Microsoft RDP 7; VMWare View Manager 4.5 a vyšší; HP Session Allocation Manager (dostupný volitelně),

h) síťové rozhraní - 10/100/1000 Gigabit Ethernet,

i) porty, 6 USB 2.0 (z toho min 2x USB 3.0), 4x DVI nebo HDMI, 1 RJ-45, 1 sluchátka, 1 vstup pro mikrofon, podpora dotykových obrazovek,

j) možnost volitelného rozšiřujícího modulu s jedním paralelním portem a druhým sériovým portem.

k) u dotykových monitorů podpora kurzoru nezávislého na kurzoru myši.

Dodavatel bude při implementaci spolupracovat s dodavatelem NIS IZS a poskytovat mu veškerou nezbytnou součinnost.

1.2.2 Operátorské pracoviště hybridní (PR-05)

Tato pracoviště umožní práci v režimu buď příjem tísňového volání (NSPTV), nebo v režimu operační řízení. Využití jednoho pracoviště souběžně pro příjem tísňového volání i operační řízení není možné. Přepojením pracoviště do režimu operační řízení je klient NSPTV neaktivní (nemůže mu být přidělen tísňový hovor) a opačně. Část NSPTV včetně přepínače bude zajištěna projektem NIS IZS tj. není součástí tohoto projektu, ale realizace v rámci této VZ musí být připravena na přepínání režimu pracoviště po dodávce části NSPTV.

Operátor bude mít k dispozici terminál, pomocí kterého se připojí k virtualizovanému desktopu, na kterém poběží všechny požadované služby a aplikace. Terminál musí podporovat připojení všech periferních zařízení (drátová náhlavní sada, atd.) a musí zcela nahradit funkci stolního PC nebo notebooku. Navržené řešení se musí skládat ze tří 24“ LCD monitorů s rozlišením minimálně 1920x1080, jednoho touchscreenu, klávesnice a myši, náhlavní soupravy, která bude umožňovat komunikaci operátorů prostřednictvím aplikace pro IP telefonii a

radiové komunikace. Celkový požadovaný počet hybridních operátorských pracovišť je 6 ks.

1) Požadovaná technická specifikace LCD monitoru s minimálními parametry:

a) Velikost panelu – 61cm(24")

b) Rozlišení 1920x1080

c) Technologie podsvícení LED

d) Pozorovací úhel (160° svisle / 170° vodorovně)

e) Konektivita – 1 konektor DVI-D s ochranou obsahu HDCP, 1 konektor VGA (Video Graphics Array)

f) 1 port USB 2.0 pro odesílání dat, 2 porty USB 2.0 pro periferní zařízení, napájecí kabel pro stejnosměrný proud pro zvukovou lištu.

g) Možnost uchycení na stojan - VESA 100mm

h) Součástí dodávky budou přídavné reproduktory - stereolišta pod monitory:

i) Celkový výkon: min 10 wattů

ii) Ovládání: zapnutí/vypnutí, hlasitost

iii) Výstup na sluchátka

iv) Napájení z monitoru

2) Požadovaná technická specifikace touchscreenu s minimálními parametry:

a) Typ panelu – IPS (aktivní matrice – TFT LCD)

b) Velikost panelu – 48,26cm (19")

c) Rozlišení 1440x900

d) Pozorovací úhel (160° svisle / 160° vodorovně)

e) Možnost uchycení VESA 100mm

3) Náhlavní soupravy – je požadováno dodat 70 ks drátových náhlavních souprav (nikoliv bezdrátových).

4) IP telefony – není součástí dodávky, dodá ZZS

Součástí dodávky operátorského pracoviště musí být i potřebná kabeláž a montážní doplňky pro instalaci v rámci operátorského pracoviště (stolu) tak aby bylo možné zapojit virtualizovaný desktop a propojit jej s požadovanými typy monitorů včetně touchscreenu, klávesnicí (USB) a myší (USB).

Dodavatel bude při implementaci spolupracovat s dodavatelem NIS IZS a poskytovat mu veškerou nezbytnou součinnost.

1.2.3 Přepínač maticový pro ostatní pracoviště (PR-07)

Přepínač maticový pro ostatní pracoviště (PR-07) - součástí dodávky technologického vybavení operačního střediska ZZS JMK je požadavek na přepínač maticový pro pracoviště operačního střediska ZZS JMK. Požadovaný počet zařízení je 6 ks.

Požadované vlastnosti:

a) přepínač audio

b) mix

c) repro

d) požadavek na používání jediného mikrofonu resp. jedné hovorové soupravy v kombinaci hlasitá/náhlavní pro všechny komunikační prvky (linkové i radiové terminály Pegas, telefon)

1.2.4 Rackové skříně 19" 800*1000 (41 U) (DC-05)

Dodávka Rackových skříní bude rozšířením stávajícího datového centra. Rozšíření instalace datového centra musí být technicky i vzhledově plně kompatibilní s již instalovanými technologiemi tak, aby byla umožněna rychlá a bezproblémová instalace, jednoduchá datová komunikace a úsporný provoz.

Dodávka musí zahrnovat 6 kusů rackových skříní (datových rozvaděčů), které budou k dispozici pro všechny dodávané technologie. Datové rozvaděče budou určeny pro montáž aktivních a pasivních IT zařízení v datovém centru. Racky musí splňovat minimálně následující požadavky: bezproblémová montáž IT zařízení, tuhost

konstrukce, nosnost a bezproblémový odvod tepla z půdorysu rozvaděče. Důležitým požadavkem je možnost instalace na již stávající systém a záruka budoucího snadného rozšíření instalace o další kusy rozvaděčů, které budou vyhovovat požadavkům na chlazení v systému uzavřené studené uličky.

1) Rackové skříně musí splňovat minimálně následující parametry:

a) požadované rozměry rozvaděčů 800x1000x2000 mm (41U) (šířka x hloubka x výška)

b) statické zatížení minimálně 500 kg

c) tuhý rozebíratelný rám z hliníkových profilů vybavený T-drážkou pro montáž vnitřní výbavy a příslušenství do libovolné polohy bez nutností vrtání montážních děr

d) 4 svislé profily pro 19“ montáž vybavené čtvercovými montážními děrami

e) ventilované přední a zadní dveře s perforací minimálně 83% a úhlem otevření 180°

f) víko s prostupy pro kabeláž připravené pro volitelnou instalaci ventilační jednotky a možností montáže až po natažení kabelů

g) doplnění již užívaných rozvaděčů v řadě tak, aby se krajní rozvaděče opět doplnily stávajícími uzamykatelnými bočními panely, střední rozvaděče jsou bez bočních panelů

h) nivelační nožky pro horizontální a vertikální ustavení rozvaděče

i) krycí vertikální a horizontální panely v úrovni předních 19“ profilů pro oddělení studené a teplé části rozvaděče pro zajištění vysoké efektivity chlazení

j) každý vertikální panel musí umožňovat instalovat minimálně 2 x 1U pozici, celkem minimálně 4U na rack

k) vodivé propojení všech dílů do jednoho bodu na uzemňovací šroub M8

l) barevné provedení rozvaděčů černošedá

2) Rozvaděče musí být vybaveny následujícím mechanickým příslušenstvím:

a) montážní sada pro spojení rozvaděčů do řady

b) kabelové žlaby pro montáž PDU bez nástrojů a pro vyvázání kabeláže

c) ocelové záslepné panely pro 19“ montáž, různé výšky panelů 1, 2, 3 a 6U, montáž bez nástrojů (pro oddělení studené a teplé části rozvaděče pro zajištění vysoké efektivity chlazení)

d) ocelová kabelová oka pro vertikální vedení kabeláže

e) spojovací materiál pro montáž do 19“ profilů

3) Rozvod napájení v rozvaděčích (PDU)

Datové rozvaděče budou vybaveny každý 2x inteligentní vertikální napájecí lištou (PDU) s dálkovým spínáním jednotlivých zásuvek a s měřením elektrických veličin až do úrovně jednotlivých zásuvek. V každém rozvaděči bude jedna PDU lišta připojena k napájecímu okruhu z UPS A a druhá PDU lišta k druhému napájecímu okruhu z UPS B. Důležitým požadavkem je kompatibilita se stávajícími PDU lištami a záruka budoucího snadného

rozšíření instalace o další kusy PDU se stejnými vlastnostmi včetně jednotné vzdálené komunikace.

PDU jsou ve vertikálním (0U) provedení. Montáž pomocí tzv. knoflíků ve standardní rozteči bez použití nástrojů. Jednofázový přívod 230V/32A pevně instalovaným kabelem s vidlicí dle IEC60309. Výstupní zásuvky 21 x

C13/10A a 3x C19/16A. Napájecí zásuvky jsou rozděleny do 3 sekcí, každá sekce je jištěna pojistkami 20A.

Komunikace přes displej, TCP/IP a RS232 rozhraní. Možnost kaskádování několika PDU přes sériový port a společné ovládání přes jedinou IP adresu. Možnost připojení až dvou čidel pro monitoring prostředí (teplota, vlhkost). Měření napětí, proudu, příkonu, spotřeby energie a účiníku až do úrovně jednotlivé zásuvky. Přístup přes web rozhraní. Možnost nastavení přístupových práv pro jednotlivé uživatele až do úrovně jednotlivé zásuvky. Možnost integrace do softwarové aplikace pro centrální správu IT zařízení.

4) Kabelové propoje

Dodávané RACKy budou propojeny strukturovanou kabeláží se stávajícími RACKy. Dodávka bude včetně montáže. Níže jsou uvedeny minimální požadované parametry:

a) každý RACK bude obsahovat kabelový propoj 24x FTP kat. 6A do stávajícího RACKU se strukturovanou kabeláží v budově

b) kabely v provedení LSOH

c) kabely ukončeny na obou koncích patchpanelem 24xRJ45 kat. 6A

d) dodávka a montáž vyvazovacího patchpanelu na každý konec propoje

e) délka propoje v průměru cca 15m v závislosti na vzájemném umístění RACKů

f) kabely vyvazovány ve stávajících trasách pod podlahou

g) měření dle ISO11801 včetně protokolu

Jakékoliv rozšíření instalace datového centra musí být technicky i vzhledově plně kompatibilní s již instalovanými technologiemi.

5) Zakrytování studené uličky (rozšíření)

Systém chlazení datového centra je navržen a bude realizován v systému uzavřené studené uličky. Pro zajištění efektivního chlazení je požadováno doplnění zakrytí studené uličky v návaznosti na již instalovaný systém

zakrytí studené uličky. V rámci instalace je požadováno přemístit stávající dveře do studené uličky na konec řady po dodání nových rozvaděčů. Dodané díly musí splňovat tyto požadavky:

a) boční díly plechové v odstínu černošedá napojené na již instalované díly do stejné výšky, každý prvek bude vybaven nastavitelným otvorem pro instalaci teplotního čidla klimatizačních jednotek

b) příčné plechové vyztužovací prvky pro držení plexiskla v barvě černošedá

c) stropní desky v šířce 800 mm s transparentního bezhalogenového plexiskla s malou hořlavostí a nízkou tvorbou kouře

d) těsnící pásky mezi a pod racky

1.2.5 UPS (EN-02)

Dodávka UPS bude rozšířením stávajícího datového centra. Rozšíření instalace datového centra musí být technicky i vzhledově plně kompatibilní s již instalovanými technologiemi tak, aby byla umožněna rychlá a bezproblémová instalace, jednoduchá datová komunikace a úsporný provoz

Součástí dodávky musí být 2 ks redundantně zapojených UPS 30kVA (online včetně akumulátorů 30min) pokrývajících potřeby provozu datového centra s těmito minimálními parametry:

a) výstupní výkon – 30 kW / 30 kVA

b) jmenovité výstupní napětí – 380/400/415 VAC, tři fáze

c) vstupní i výstupní power factor roven 1 (kVA = kW)

d) účinnost při plném zatížení – minimálně 93%

e) možnost paralelního zapojení minimálně 4 UPS

f) nastavitelný postupný náběh zatížení

g) součástí UPS interní baterie

h) UPS osazena ve standardním 19” Racku případně šasi šířky standardního 19“ racku

i) provoz při přetížení minimálně – 60 sekund při 120%, 30 sekund při 145%

j) nabíjení baterie s teplotní kompenzací

k) monitorování stavu pře LCD panel s podrobným a online přehledem aktuálních provozních parametrů

l) možnost vzdáleného monitorování a řízení prostřednictvím sítě ethernet (SNMP/Web)

m) UPS připravena pro spolupráci s motorgenerátorem

n) modulární UPS s možností škálovatelnosti výkony do 120kVA/120kW

o) výkonové i bateriové moduly vyměnitelné za chodu

1.2.6 Síťové prvky (mimo NSPTV) (DC-07)

Je požadováno dodat 2 ks centrálních switchů, které budou vytvářet centrum datové komunikace LAN sítě ZZS. Síťové prvky LAN infrastruktury musí splňovat následující minimální požadované vlastnosti na HW:

a) min. 2x 24 portů Gigabit Ethernet, 2x 2 TenGigabitEthernet (SFP+ porty)

b) propojení switchů do jednoho stacku (přepínače se chovají jako jeden z pohledu managementu i připojených zařízení – včetně automatického load balancingu) vysokorychlostním redundantním propojením (32/64Gbps)

c) neblokovaná architektura, propustnost min. 160 Gbit

d) podpora Jumbo Frames, min. 9 kb, routování VLAN na L3, podpora agregace portů (LACP) s využitím dvou switchů ve stacku (jedna agregace pře dva switche)

e) access listy (access control lists - ACL) aplikovatelné na IP L2 a L3 pro filtrování provozu; podpora globálních ACL, VLAN ACL, port ACL, a podpora IPv6 ACL

f) bezpečnost – port security a implementace 802.1X, automatické zařazování do VLAN 802.1x – RADIUS server

g) QoS (prioritizace služeb)

h) Voice VLAN: automatické zařazování do VLAN a nastavení priorit IP telefonů

i) redundantní napájení včetně možnosti sdílení napájení v rámci stacku

j) záruka 60 měsíců

1.2.7 Dohledové systémy (EN-03)

Jako dohledový systém IT infrastruktury se využívá systém WhatsUp firmy Ipswitch, Inc. Tento systém je provozován na jednom serveru a monitoruje stávající IT infrastrukturu včetně WAN sítě ZZS JMK.

Požadavkem na dohledové systémy v rámci této veřejné zakázky je zajištění zařazení nové IT infrastruktury do stávajícího dohledového systému. Důvodem zařazení nové infrastruktury do stávajícího dohledového systému je:

• Monitoring dostupnosti systémů a varování před kritickými stavy IT infrastruktury.

• Monitoring a vyhodnocení výkonnostních a funkčních parametrů a alertování nestandardních stavů.

• Reporting celkové dostupnosti infrastruktury OŘ a jednotlivých částí infrastruktury.

Pro napojení na stávající dohledový systém je možné využít následujícími protokoly/možnostmi systému:

a) SNMP monitoring

b) SYSLOG notifikace

c) ICMP monitoring

d) monitoring TCP služeb, ověření funkce v daném protokolu (odeslání definovaného stringu a čekání na definovanou odpověď)

e) monitoring Microsoft služeb/services, event logů atd.

f) WMI Monitoring

g) monitoring pomocí uživatelských scriptů (jscript a VB Script)

1.3.1 Integrace sítě PEGAS (DR-01)‌

1.3 Minimální požadavky na dodávky v oblasti radiové sítě PEGAS

S cílem optimalizovat práci dispečera operačního střediska je požadována maximálně možná integrace komunikačních radiových technologií. Integrace rádiové sítě musí zajistit, aby kterýkoli operátor mohl využívat kterýkoli instalovaný integrovaný terminál a poslouchat provoz na libovolných dalších terminálech. Požadavkem je distribuovaný systém řízený jednou ústřední aplikací, která zpracovává povely z dotykové obrazovky operátora ZOS.

Pro propojení operačního střediska se sítí PEGAS je nezbytné použití standardizovaných integračních rozhraní pro operační řízení podle zveřejněných specifikací výrobce systému PEGAS, zejména dodržení TETRAPOL Publicly Available Specifications. Dále je požadováno, aby Uchazeč ve své nabídce explicitně garantoval schopnost úpravy integrace na síť Pegas, pokud bude v rámci udržitelnosti projektu proveden upgrade této sítě.

1) Základní požadované funkce na integraci:

e) řízení adresace paketů digitálního audia do hlavních a příposlechových kanálů v hovorových soupravách

f) možnost krátkodobého záznamu audia formou uložení paketů na HDD

g) volba mezi hlasitou a xxxxxx xxxxxxxxx soupravou

h) otevřený i šifrovaný přenos s možností ztrátové komprese

2) Základní požadované funkce pro dispečera ZOS - integrace radiového systému PEGAS musí umožnit tyto funkce pro operátora ZOS prostřednictvím ovládání aplikace na dotykovém LCD pracoviště:

a) klíčování

b) připojení audiosignálů do propojovacího pole

c) výstupy pro nahrávání

d) zobrazení registračního stavu

e) seznam operačních skupin

f) indikace stavu terminálu

g) sestavení odchozího individuálního hovoru nebo vytáčené konference

h) přijetí příchozího individuálního hovoru vč. zobrazení adresy RFSI volajícího

i) předání probíhajícího individuálního volání na jiný terminál

j) tiché volání s prověrkou oprávnění operátora

k) ukončení individuálního hovoru operátorem nebo protistranou

l) zobrazení seznamu standardních otevřených kanálů, krizových otevřených kanálů a otevřených kanálů typu broadcast

m) zobrazení adresy RFSI terminálu hovořícího v otevřeném kanálu

n) zřízení otevřeného kanálu, vstup, opuštění a uzavření otevřeného kanálu

o) zřízení otevřeného kanálu typu broadcast, vstup, opuštění otevřeného kanálu typu broadcast

p) uzavření otevřeného kanálu typu broadcast ručně nebo automaticky

q) varování o nově otevřeném krizovém kanále

r) vstup do krizového otevřeného kanálu ručně nebo automaticky

s) opuštění a uzavření krizového otevřeného kanálu

t) přijetí statusu a adresovatelné odeslání statusu

u) přijetí SMS a adresovatelné odeslání SMS

v) skupinové odeslání SMS předem definované skupině

3) Rádiová síť PEGAS (DR-01) - požadované vazby na další subsystémy: je požadována integrace na subsystém pro operační řízení (SOŘ).

4) V rámci integrace sítě Pegas je požadováno dodat 6 ks LCT2G modulů včetně příslušné kabeláže, konektorů, instalace, otestování a zprovoznění a to s následujícími požadovanými parametry a funkcionalitami:

a) přenos hlasu a dat plně digitální

b) zabezpečená digitální komunikace v trunkovém režimu

c) šifrování hlasových i datových komunikací, šifrování konec-konec

d) přístup k veškerým funkcím sítě PEGAS

i) skupinové i individuální hovory

ii) tísňové volání, statusy

iii) datové přenosy, krátké datové zprávy

iv) řízení uživatelských priorit

e) vysoká kvalita hlasu

Součástí dodávky je požadováno dodat síťový switch 24 portů s možností vytvářet sepárátní sekce s managementem

a) L2 Switch s porty 24 Ethernet 10/100/1000 PoE+ a 4x GigabitEthernet SFP

b) software podporující CLI – SSH (podobný IOS), WEB a SNMP management

c) podpora VLAN (min. 255), Private VLANs

d) voice VLAN: automatické zařazování do VLAN a nastavení priorit IP telefonů

e) bezpečnost – port security a implementace 802.1X, automatické zařazování do VLAN 802.1x – RADIUS server

f) QoS (prioritizace služeb)

g) podpora další bezpečnostních/provozních funkcí jako např. DHCP Snooping, Dynamic ARP Inspection, IP source guard, MAC Address Notification apod.

h) podpora IPv4 a IPv6

1.3.2 Pevné radiostanice 3G (DR-03)

Pro potřeby ZZS JMK je třeba vybavit celkem 12 operátorských pracovišť pevnou radiostanicí 3G.

Pro každé pracoviště (každý stůl) je požadováno dodat: 1 RCT, montážní sadu, zdroj, anténu, svod antény a konektory. Zajištění montáží radiostanic ze strany Uchazeče není Zadavatelem požadováno. Zadavatel si zajistí montáže a instalace sám.

Požadované parametry pevných radiostanic 3G:

1) Požadavky na obecné vlastnosti:

a) konstrukční řešení vhodné do extrémních podmínek

b) barevný displej s vysokým rozlišením

c) klávesnice

d) intuitivní ovládání

e) funkčnost při teplotách -30˚C až 60 ˚C

f) ovládací jednotka s příslušnou montážní sadou.

2) Požadavky na stolní konfiguraci:

a) ovládací modul (k montáži na stůl)

b) mikrofon na ohebném rameni s klíčovacím tlačítkem PTT

c) reproduktor 15 W

d) lehká náhlavní souprava

e) skříňka k upevnění na zeď, včetně napájecího zdroje 220/12 V

3) Požadavky na normy:

a) radiové standardy ETSI č. EN 300 113-1 & -2

b) normy ETSI pro elektromagnetickou kompatibilitu EN 301 489-5 a -1

c) standard upravující problematiku elektrické bezpečnosti EN 60950-1: 2001

4) Požadavky na kmitočtová pásma:

a) 380 – 430 MHz s kanálovou roztečí 10 nebo 12,5 kHz

b) 440 – 490 MHZ s kanálovou roztečí 10 nebo 12,5 kHz

c) možnost půl kanálového ofsetu

d) další kmitočtová pásma na vyžádání

5) Požadavky na RF:

a) vysílače: 10 W

b) statická/dynamická citlivost lepší než -119 dBm/-111dBm

6) Požadavky na odolnost:

a) odolnost proti vodě a prachu dle klasifikace IP54

b) nárazy a vibrace dle ETS EN 300019-1-5 třída 5M3

c) odolnost proti vlhkosti dle ETS EN 300019-1-5 třída 5.2 až do 95 %

7) Požadavky na displej:

a) grafický displej minimálně TFT 2.2“ s vysokým rozlišením: 128×160 pixelů

8) Požadavky na klávesnici/ovládací prvky:

a) alfanumerická klávesnice

b) navigační klávesa

c) programovatelná klávesová zkratka

d) 2 volicí klávesy

e) vypínač, ovladač hlasitosti, tlačítko tísňového volání

f) tlačítko s dvojí funkcí umožňující ovládat hlasitost a/nebo volit kanály

9) Požadavky na typy volání:

a) individuální hovory

b) konferenční hovory

c) volání přes ústřednu do telefonní sítě

d) přesměrování hovorů

e) předávání hovoru

f) identifikace volajícího

10) Požadavky skupinové komunikace:

a) až 20 skupin

b) normální a trunkovaný režim

c) otevřené kanály, hovorové skupiny

d) dispečerské volání

e) tísňové volání

f) slučování skupin

g) scanování, vstup do již probíhající komunikace

h) identifikace volajícího

11) Požadavky na režim pokrytí:

a) rozšířené pokrytí v přímém režimu v pásmu 380-430 MHz nebo 440-490 MHz

b) tísňové volání

c) využití převaděčového režimu

d) identifikace volajícího

12) Požadavky na bezpečnost:

a) zabudovaný šifrovací komponent (ASIC)

b) vzájemné ověřování totožnosti

c) šifrování typu konec-konec u hlasových i datových přenosů

d) distribuce klíčů radiovou cestou

e) dálkové zablokování (paralyzování)

f) speciální šifrování (varianta)

1.3.3 Vozidlová radiostanice 3G (DR-04)

Pro potřeby ZZS JMK je třeba vybavit celkem 19 vozidel vozidlovou radiostanicí 3G bez montážní sady (kabeláž atd.). Zajištění montáží radiostanic ze strany Uchazeče není Zadavatelem požadováno. Zadavatel si zajistí montáže a instalace sám.

Požadované parametry vozidlových radiostanic 3G:

1) Požadavky na obecné vlastnosti:

a) konstrukční řešení vhodné do extrémních podmínek

b) barevný displej s vysokým rozlišením

c) klávesnice

d) intuitivní ovládání

e) funkčnost při teplotách -30˚C až 60 ˚C

f) ovládací jednotka s příslušnou montážní sadou.

2) Požadavky na vozidlovou konfiguraci:

a) ovládací modul (montáž na držák typu DIN nebo na přístrojovou desku)

b) samostatný mikrofon reproduktor s klíčovacím tlačítkem PTT

c) upevňovací zařízení umožňující montáž radiového modulu

d) souprava hands free

3) Požadavky na normy:

a) radiové standardy ETSI č. EN 300 113-1 & -2

b) normy ETSI pro elektromagnetickou kompatibilitu EN 301 489-5 a -1

c) standard upravující problematiku elektrické bezpečnosti EN 60950-1: 2001

4) Požadavky na kmitočtová pásma:

a) 380 – 430 MHz s kanálovou roztečí 10 nebo 12,5 kHz

b) 440 – 490 MHZ s kanálovou roztečí 10 nebo 12,5 kHz

c) možnost půlkanálového ofsetu

d) další kmitočtová pásma na vyžádání

5) Požadavky na RF:

a) vysílače: 10 W

b) statická/dynamická citlivost lepší než -119 dBm/-111dBm

6) Požadavky na odolnost:

a) odolnost proti vodě a prachu dle klasifikace IP54

b) nárazy a vibrace dle ETS EN 300019-1-5 třída 5M3

c) odolnost proti vlhkosti dle ETS EN 300019-1-5 třída 5.2 až do 95 %

7) Požadavky na displej:

a) grafický displej TFT 2.2“ s vysokým rozlišením: 128×160 pixelů

8) Požadavky na klávesnici/ovládací prvky:

a) alfanumerická klávesnice

b) navigační klávesa

c) programovatelná klávesová zkratka

d) 2 volicí klávesy

e) vypínač, ovladač hlasitosti, tlačítko tísňového volání

f) tlačítko s dvojí funkcí umožňující ovládat hlasitost a/nebo volit kanály

9) Požadavky na typy volání:

a) individuální hovory

b) konferenční hovory

c) volání přes ústřednu do telefonní sítě

d) přesměrování hovorů

e) předávání hovoru

f) identifikace volajícího

10) Požadavky skupinové komunikace:

a) až 20 skupin

b) normální a trunkovaný režim

c) otevřené kanály, hovorové skupiny

d) dispečerské volání

e) tísňové volání

f) slučování skupin

g) scanování, vstup do již probíhající komunikace

h) identifikace volajícího

11) Požadavky na režim pokrytí:

a) rozšířené pokrytí v přímém režimu v pásmu 380-430 MHz nebo 440-490 MHz

b) tísňové volání

c) využití převaděčového režimu

d) identifikace volajícího

12) Požadavky na zprávy:

a) statusové zprávy

b) textové zprávy a výměna dat PEGAS

13) Požadavky na bezpečnost:

a) zabudovaný šifrovací komponent (ASIC)

b) vzájemné ověřování totožnosti

c) šifrování typu konec-konec u hlasových i datových přenosů

d) distribuce klíčů radiovou cestou

e) dálkové zablokování (paralyzování)

f) speciální šifrování (varianta)

1.3.4 Ruční radiostanice s kitem (DR-04b)

Pro potřeby ZZS JMK je třeba vybavit celkem 84 vozidel ruční radiostanicí s kitem. Zajištění montáží radiostanic ze strany Uchazeče není Zadavatelem požadováno. Zadavatel si zajistí montáže a instalace sám.

Požadované parametry ruční radiostanice s kitem:

1) Požadavky na obecné vlastnosti:

a) současné napájení a nabíjení terminálů

b) snadné umísťování a vyjímání terminálů

c) kloubový čep

2) Požadavky na technické parametry:

a) vozidlová vidlice

b) mikrofon/reproduktor k vozidlové vidlici

c) 3G

1.4.1 Pobočková ústředna OŘ (OB-01)‌

1.4 Minimální požadavky na dodávky v oblasti telefonie

Je požadována dodávka a montáž pobočkové telefonní ústředny OŘ a jejich komunikačních zařízení, která bude integrována do celkové komunikační struktury ZZS se zajištěním klasické i IP telefonie a s integrací hlasových a datových služeb.

Stávající objektová ústředna je Siemens Hipath 3000 s rozhraním ISDN30 a IP. Ústředna pro dispečerské řízení musí splňovat jak plnohodnotné propojení se stávající objektovou ústřednou tak i nouzové přepojeni dispečerských pracovišť (a to i speciálních služeb propojených na PC) na objektovou ústřednu, která v případě výpadku ústředny OŘ převezme obsluhu dispečinku v nouzovém provozu, propojení musí zajistit přenos i informací nad rámec běžné signalizace a to zejména automatické uvolnění kanálu při zpětném přepojení hovoru přes příčku, dále třídu oprávnění , možnost tranzitu, přenos jména,čísla volaného a volajícího . Dále rozhraní pro aplikace CTI musí být také integrováno s propojením obou systémů. GSM VOIP brána také zajistí připojeni obou ústředen

Minimální parametry požadované konfigurace telefonní ústředny OŘ:

a) 2 x ISDN 30 (30 kanálů)

b) 1 x karta IP telefonie (možnost připojení až 500 IP TP )

c) 32 x hlasových kanálů pro VOIP rozhraní

d) 120 x licenci pro připojení IP přístrojů

e) 8 x analogových pobočkových linek s funkcí clip

f) 1 x SW pro správu systému

g) 8 x ISDN 2 pro připojení GSM bran, příček, modemů atd..

h) 12 x licence pro rozhraní TAPI

i) 1 x GSM VOIP 4xSIM

j) Instalace do RACKu

Součástí dodávky je montáž a zaškolení dodávané telefonní ústředny OŘ.

1.4.2 Nahrávání (všechny kanály OŘ) (OB-02)

Součástí požadované dodávky technologického vybavení Zdravotnického operačního střediska ZZS JMK je záznamové zařízení, které umožní nahrávání telefonů, radiokomunikace, hlasový příkaz. Součástí dodávky musí být i konektory na jednotlivé linky.

1) Nároky na nahrávací zařízení - vstupní kanály:

a) 1 ISDN 30 do ústředny

b) 12 stolních záložních radiostanic

c) 12 mobilních telefonů Jablotron – analogové nahrávání

d) 12 IP telefonů

e) 6 analogových vstupů pro integraci Pegas

2) Požadované vlastnosti a parametry na samostatné záznamové zařízení:

a) Umožnit připojení pro:

i) záznam digitálních pobočkových linek, které používají dispečeři s identifikací volajícího a volaného

ii) záznam IP telefonů s identifikací volajícího a volaného

iii) záznam digitálních radiostanic s identifikací volajícího a volaného

iv) stereo záznam s rozdělením směrů volaný a volající

b) zajištění ukládání dat

i) na dva paralelní HDD

ii) ukládání dat přímo na HDD bez použití file systému

iii) ukládání ve formátu, který odpovídá obecnému standardu a který umožní v budoucnu konverzi do jiných formátů pro zajištění dostupnosti záznamu po celou dobu požadované archivace. Uchazeč uvede formát, ve kterém bude záznam ukládán.

c) zajištění práce s hovory

i) přístup přes web rozhraní

ii) integrace záznamového zařízení s výjezdovými SW používaným na ZZS

iii) identifikace polohy volajícího z GSM telefonu

iv) po přechodnou dobu zachovat identifikaci polohy volajícího z pevné linky - Info 35. Tento systém není součástí dodávky v rámci tohoto projektu a bude následně nahrazen systémem NSPTV v rámci realizace NIS IZS.

d) přehrávání záznamů

i) možnost přehrávat odděleně oba směry

ii) možnost přeskakování ticha

iii) grafické zobrazování výskytu klíčových slov

e) umožnit hlasové analýzy

i) automatické vyhledávání klíčových slov, emocí, pořadí klíčových slov, dialog flow

1.4.3 Příčka – PBX OŘ objektová ústředna (OB-03)

Je požadováno propojení (příčka) telefonní ústředny OŘ se stávající objektovou ústřednou splňující následující minimální požadavky na propojení:

a) 1x propojení s objektovou telefonní ústřednou o kapacitě 16 souběžných hovorů.

b) Propojení musí zajistit přenos i informací nad rámec běžné signalizace a to zejména automatické uvolnění kanálu při zpětném přepojení hovoru přes příčku, dále třídu oprávnění, možnost tranzitu, přenos jména, čísla volaného a volajícího.

c) Součástí dodávky musí být montáž, konfigurace, integrace a zprovoznění požadovaného propojení.

1.5.1 Vozidlové GPS (VT-01)‌

1.5 Minimální požadavky na vybavení výjezdových stanovišť a vozidel

Zadavatel požaduje dodat vozidlové GPS s těmito vlastnostmi a parametry. Zajištění montáží vozidlových GPS ze strany Uchazeče není Zadavatelem požadováno. Zadavatel si zajistí montáže a instalace do vozidel sám.

1) Požadavky na vozidlovou jednotku - obecné vlastnosti jsou tyto:

a) kompaktní zařízení, u kterého není SIM karta uživatelsky přístupná

b) zařízení musí obsahovat GPS přijímač a GSM komunikátor s podporou komunikace GPRS

c) musí být monitorování napětí palubní sítě

d) je požadována národní nebo Evropská homologace

2) Požadavky na vozidlovou jednotku - ukládání záznamů jsou tyto:

a) ukládání záznamů do vnitřní paměti s kapacitou min. na 3 měsíce provozu

b) vnitřní paměť musí uchovat uložená data i při odpojení napájení

c) nastavitelná kritéria pro ukládání dat do vnitřní paměti (ujetá vzdálenost, čas a jejich kombinace)

d) ukládání všech provozních dat včetně stavů/režimů posádky (pokud se zadávají)

e) možnost změny intervalu ukládání (např. při jízdě s majákem)

f) funkce „černé skříňky“, tedy ukládání dat do vnitřní paměti s krokem 1 vteřina (trvale při provozu vozidla) s kapacitou min. na 1 týden provozu (pro případ analýzy havárie vozidla)

g) automatické a průběžné odesílání dat na dispečink

3) Požadavky na vozidlovou jednotku – update jsou tyto:

a) schopnost změny parametrů po kabelu a také „over air“

b) schopnost změny firmware po kabelu a také „over air“

4) Požadavky na vozidlovou jednotku – rozhraní jsou tyto:

a) binární vstupy pro připojení na vozidlo (zapalování, maják, dveře a další)

b) rozhraní pro připojení terminálu pro identifikaci řidiče

c) rozhraní pro připojení stávajícího externího navigačního zařízení Garmin, řady Nüvi 765

5) Požadavky na vozidlovou jednotku – řízení příkonu jsou tyto:

a) řízení příkonu podle stavu vozidla – přechod do režimu spánek při neaktivitě vozidla

b) možnost přechodu do aktivního stavu na základě externí události (např. otevření dveří)

6) Následující tabulka uvádí popis základních požadovaných funkcionalit vozidlové jednotky minimálně v rozsahu:

Poz.

Popis

Připojení navigace

Vozidlová jednotka musí umožnit připojení navigačního přístroje s funkcemi:

a) Zaslání cíle od dispečera do navigace

b) Příjem textové zprávy od dispečera

c) Odeslání textové zprávy dispečerovi

Připojení klávesnice v autě

Vozidlová jednotka musí umožnit připojení externí klávesnice v autě s možností identifikace řidiče, zadání stavu tachometru, zadání tankování, zadání režimu jízdy (výjezd, ošetření pacienta, převoz do

nemocnice apod. … min. 8 různých stavů)

Alarmy - funkce pro alarmové tlačítko a odeslání alarmové zprávy

Požadované služby

a) veškeré montáže musí probíhat na střediscích zadavatele

b) opravy a servisy budou probíhat na středisku zadavatele, který hlásí poruchu

Tabulka 3: Vozidlové jednotky - základní požadované funkcionality

7) Následující tabulka uvádí popis základních požadovaných funkcionalit periférií pro vozidlové jednotky minimálně v rozsahu:

Poz.

Popis

Periferie pro identifikaci řidiče – externí klávesnice

a) identifikace řidiče pomocí Dallas čipu

b) indikace nepřihlášeného řidiče

c) varianta s možností psaní a příjmu textových zpráv

d) v případě použití kontaktních čipů možnost jejich autorizace (ochrana proti výrobě duplikátů)

e) klávesnice s displejem, umožňující zadávání informací o tankování a stavu tachometru

f) rozlišení režimu jízdy (zadávání statusů)

Tabulka 4: Vozidlové jednotky (periférie) - základní požadované funkcionality

8) Následující tabulka uvádí popis základních požadovaných funkcionalit na komunikaci pro vozidlové jednotky minimálně v rozsahu:

Poz.

Popis

Typ komunikace

a) GSM v režimu minimálně GPRS

b) komunikace přes privátní APN, bez vazby na veřejný internet

Poz.

Popis

Požadavky na funkčnost

a) zajištění trvalé a obousměrné komunikace přes GPRS

b) schopnost bezobslužného a průběžného stahování dat bez zbytečné duplikace datového toku

c) zajištění přenesení 100 % dat z vozidlové jednotky na dispečink - odolnost proti dočasné ztrátě komunikace (požadujeme stručně popsat použitou metodu)

d) detekce přihlášení vozidlové jednotky do sítě zahraničních operátorů, možnost parametrizace (např. zakázat přihlášení a posílání zpráv na dispečink)

Tabulka 5: Vozidlové jednotky (komunikace) - základní požadované funkcionality

1.5.2 Tablet posádky (VT-02)

1.5.2.1 Požadavky na Tablet

Pro zajištění Mobilního zadávání dat o výjezdech/pacientech lékaři a zdravotníky v terénu je požadováno vybavit ZZS JMK přenosnými mobilními zařízeními (dále jen „Tablety“). Je požadováno dodat celkem 56 mobilních zařízení pro ZZS JMK včetně montáže Tabletů do vozidel.

Požadované parametry Tabletů:

a) dotykový displej o velikosti minimálně 10“

b) umožní ovládání prostřednictvím klávesnice – je možné provedení pevné i přídavné klávesnice

c) min. kapacita HDD 64GB požadována technologie SSD, min 2GB RAM

d) integrovaná GPS, Wifi a Bluetooth

e) modem /GPRS/UMTS/HSPDA

f) minimální doba provozu na baterie 6 hodin

g) maximální hmotnost 2,5kg

h) min 1x USB port

i) konektor pro dokovací stanici

j) OS 100% kompatibilní pro aplikace mobilního sběru dat EKP

k) pracovní teplota min od 5°C – 35°C

l) minimální požadované testy na odolnost přístroje:

i) krytí přístroje: min. IP52

ii) odolnost: MIL-STD 810G

1.5.2.2 Požadavky na tiskárnu

Pro tisk záznamů je požadováno zajistit ve vozidle inkoustovou tiskárnu, která musí být instalována dle platných předpisů a norem. Je požadováno dodat celkem 56 tiskáren do vozidel pro ZZS JMK včetně jejich montáže a servisní podporou na 3 roky (s možností výměny tiskárny kus za kus do následujícího dne)

Tiskárna musí splňovat následující parametry:

a) tisk ve formátu A4 (210 x 297 mm) a A5 (148 x 210 mm)

b) schopná provozu na 12-16V (součástí dodávky musí být autoadaptér)

c) zásobník papíru

d) mobilní – tj. kromě USB připojení kabelem nabízí i možnost bezdrátového připojení a obsahuje baterii pro provoz bez připojení ke zdroji el. energie

1.5.3 Interface k přístrojům (VT-03)

Pro zajištění přenosu informací ze zařízení Lifepak 12/15 (defibrilátory) do tabletů v rámci prováděných odborných úkonů při vyšetřování pacientů ve vozidle je požadováno zajistit interface pro jejich propojení celkem v počtu 84 ks.

Připojení přístroje Lifepak 12/15 je požadováno realizovat pomocí následujících komponent:

a) USB kabel – 84 ks

b) Softwarový interface, který umožňuje importovat data z monitoru/defibrilátoru – tento interface bude implementován ve všech tabletech využívaných ve vozidlech

1.5.4 Vozidlová LAN s konektory (VT – 04)

Pro používání tabletů, tiskáren ve vozidlech RZP a RLP ZZS JMK je požadováno vybavit 84 ks vozidel potřebnou kabeláží, konektory, úchyty, napájením z vozidla. Pojem vozidlová LAN není chápán jako datová kabeláž, ale jako obecný pojem pro dodávku nezbytných komponent pro zajištění provozu dodávaných zařízení ve vozidlech ZZS JMK.

Aktivní komponenty vozidlové LAN musí mít homologaci pro provoz ve vozidlech.

Je požadováno vytvoření funkčního prototypu zástavby ve vozidle pro ověření funkčnosti, optimální ergonometrie používaní tabletů a tiskáren a zajištění bezpečnosti.

Požadované položky a parametry vozidlové zástavby a kabeláže:

a) Kabeláž pro zajištění propojení tiskárny s Tabletem USB kabelem

b) Připojení k přístrojům a zařízením ve voze je požadováno zajistit pomocí dokovací stanice Tabletu a tiskárny nebo obdobného technologického zařízení. Toto musí být ve voze nainstalováno dle platných pravidel a norem a musí splňovat následující vlastnosti a parametry:

i) Nepřetržité napájení tabletu a tiskárny ve vozidle

ii) Konektor pro ethernetové připojení (RJ45)

iii) Rozšíření tabletu o min 1x sériový port a 2x USB port

1.6.1 HW kompletně (IS-01)‌

1.6 Minimální požadavky na informační systémy

V rámci realizace předmětu plnění uchazeč zajistí dodávku a implementaci technologické IT infrastruktury s odpovídající kapacitou včetně dostatečné rezervy, která zajistí zvýšení dostupnosti poskytovaných

služeb/aplikací a snížení (minimalizace) doby výpadku služeb/aplikací nového systému. Technologická IT infrastruktura musí zajistit funkci IS OŘ a virtualizovaných desktopů ZOS.

Dodávka musí zahrnovat tyto základní části infrastruktury:

• Servery pro virtualizační platformu

• Diskové úložiště

1.6.1.1 Servery pro virtualizační platformu

Dodávka bude obsahovat jeden server pro centralizované řízení a (min. 2) virtualizační servery, a to s následující konfigurací:

1) Server pro centralizované řízení (1 ks) v minimální požadované konfiguraci:

a) 2x CPU 6 core, min. 2GHz (nebo odpovídající 2x CPU s výkonem min. 8150 bodů v testu Passmark CPU Mark xxxx://xxx.xxxxxxxxxxxx.xxx)

b) 16 GB RAM (rozšířitelná na 196 GB),

c) L3 cache – min. 15MB

d) HDD 2x 146 GB s možností RAID1 nebo boot z SD karty (interní flash úložiště pro instalaci hypervizoru),

e) 2x 10Gb Ethernet

f) redundantní napájení (2 zdroje),

g) Výrobcem certifikovaná podpora pro XenServer, Hyper-V, VMware

h) Provedení – Rack 19“ včetně sady na uchycení do rozvaděče.

i) Záruka 60 měsíců

2) Virtualizační servery (min. 2 ks) v minimální požadované konfiguraci:

a) 2x CPU 6 core 2.5 GHz, 15M Cache, min. 7.2GT/s QPI, Turbo, min. DDR3-1333MHz nebo 1x 8 core 2.7 GHz 20M Cache, 8.0GT/s QPI, Turbo, DDR3-1600MHz (nebo odpovídající 2x CPU s výkonem min. 10000 bodů v testu Passmark CPU Mark ) nebo odpovídající 1x CPU s výkonem min. 14500 bodů v testu Passmark CPU Mark – odkaz na test xxxx://xxx.xxxxxxxxxxxx.xxx)

b) 64 GB RAM (rozšířitelná na 196 GB),

c) L3 cache – min. 15MB

d) HDD 2x 146 GB s možností RAID1 nebo boot z SD karty – min 2GB (interní flash úložiště pro instalaci hypervizoru),

e) 2x 10Gb Ethernet

f) redundantní napájení (2 zdroje),

g) Výrobcem certifikovaná podpora pro XenServer, Hyper-V, VMware

h) Provedení – Rack 19“ včetně sady na uchycení do rozvaděče.

i) Záruka 60 měsíců

1.6.1.2 Diskové úložiště

Diskové úložiště je požadováno dodat v konfiguraci s minimální kapacitou 4T (RAID10) iSCSI se dvěma storage procesory a dvěma zdroji napájení a připojení technologií 10GigabitEthernet.

Obecné požadavky jsou uvedeny níže:

Konfigurace	Specifikace – minimální požadavek zadavatele
Systém	Diskové pole typu IP SAN
Přenosová technologie, protokol	Ethernet, iSCSI
Front-End konektivita	Min. 2 Storage procesory
Front-End konektivita	Základní konektivita: min. 2 iSCSI porty min. 10GbE na každý Storage procesor s možností agregace
Cache	Min. 4 GB na každý Storage Procesor, zálohovaná baterií
Diskový subsystém	Osaditelnost min. 24 HDD na každý diskový box
Instalovaná disková kapacita	Min. 10 TB neformátované kapacity použitím HDD SAS 10k rpm
RAID	• Systém musí podporovat tyto RAID standardy RAID-5, RAID-6, RAID-10, RAID-50 • Podpora globálních hot-spares
Software - požadovaný v dodávce	• Software pro úplnou konfiguraci, management a monitorování • Software pro tvorbu snapshotů/snapklonů (podpora Hyper-V, SQL Server, Exchange, VMWare), min. 512 snapshotů/volume • Software pro on-line replikace • Software pro podporu Tiered Storage • Software pro zajištění Thin Provisioning • Software pro tvorbu Volume Groups
Zajištění vysoké dostupnosti	• Online migrace dat/svazků mezi storage pools • Online migrace dat/svazků mezi diskovými poli • Upgrade konektivity, storage procesorů, rozšíření kapacity nebo výměna HDD musí být proveditelná za chodu, bez výpadku pole a bez ztráty konektivity připojených serverů
Management	• GUI prostřednictvím web-browseru • Dedikovaný port pro management • CLI via SSH a Telnet
Certifikace	• VMware, Windows, Xen • Microsoft Simple SAN o HW WSS provider, HW VDS provider a MultiPath support v ceně o Možnost spravovat SAN pomocí Microsoft Storage Manager for SAN

Konfigurace	Specifikace – minimální požadavek zadavatele
Další požadované vlastnosti	Aktualizace firmware zdarma po dobu supportu
Záruka	Min. 60 měsíců. Nástup na servisní zásah nejpozději do 4 hodin po nahlášení závady v místě instalace, 24 hodin denně, 365 dní v roce.
Způsob provádění záručního servisu	Jediné kontaktní místo pro nahlášení poruch v celé ČR, servisní střediska pokrývající celé území ČR, možnost sledování servisních reportů prostřednictvím Internetu

Tabulka 6: Požadavky na diskové úložiště

1.6.2 Databáze, virtualizace, replikace SW (IS-02)

V této kapitole jsou definovány požadavky Zadavatele na tyto dvě oblasti:

a) Systémový software

b) SW pro virtualizaci desktopů

1.6.2.1 Požadavky na systémový software (SW)

Zadavatel požaduje dodat systémový SW minimálně s těmito vlastnostmi:

a) Systémový SW musí licenčně a funkčně zajišťovat kompletní jednotnou platformu pro provozování virtuálních serverů a desktopů, umožňující jejich efektivní centralizované vytváření, správu serverů, desktopů i aplikací v lokálních i WAN sítích.

b) Systémový SW musí obsahovat všechny potřebné databázové licence pokrývající s dostatečnou rezervou provoz informačního systému.

c) Systémový SW musí obsahovat veškeré potřebné licence serverových operačních systémů (min. 2 na každý virtualizační nod).

d) Software pro virtualizaci prostředí musí splňovat minimální pokrytí potřebného počtu fyzických serverů s 1-2 CPU v následující konfiguraci:

e) Podporující operační systémy – Windows, Linux

f) HA funkcionalita zajišťující vysokou dostupnost libovolné aplikaci provozované na virtuálním stroji. Chránící aplikace bez dalších řešení pro obnovu po selhání.

g) Automatická detekce selhání serveru.

h) Automatizované monitorování dostupnosti fyzických serverů

i) Detekce selhání serveru a iniciace restartování virtuálního stroje bez jakéhokoliv lidského zásahu.

j) Funkcionalita pro zálohování a obnovu virtuálních strojů, které využívá funkce ukládání záloh a doplňuje existující řešení ochrany dat v oblasti zálohování a archivace na pásky.

k) Podpora live migrace virtuálního stroje z jednoho fyzického serveru na jiný.

1.6.2.2 SW pro virtualizaci desktopů

Požadovaný SW virtualizaci desktopů musí splňovat následující vlastnosti:

a) 20 licencí pro virtuální desktopy

b) centralizovaná správa,

c) automatické vytváření a nasazování nových desktopů,

d) škálovatelnost a vysoká dostupnost,

e) integrovaná virtualizace a doručování aplikací,

f) podpora protokolu PC-over-IP v režimu umožňujícím uživateli zpřístupnění desktopu bez jakékoliv degradace výkonu a komfortu použití a to včetně multimediálního obsahu, grafických aplikací, tiskových operací apod.,

g) možnost použití virtuálních desktopů i ve stavu off-line,

1.6.3 Informační systém – vývoj a integrace (IS-03)

V následujících kapitolách jsou definovány požadavky na jednotlivé subsystémy IS OŘ.

1.6.3.1 Subsystém pro operační řízení (dále jen SOŘ)

1) Obecné požadované vlastnosti systému:

a) uživatelsky jednoduchá obsluha, jednotné uživatelské rozhraní

b) jednoznačný přehled o stavu jednotlivých výjezdových skupin

c) událostně orientovaný přístup, jasné zobrazení vazeb (událost, výjezdová skupina, pacient)

d) ergonomické zobrazení – vhodná velikost a barevné provedení uživatelského interface

e) on-line zálohování dat

f) FailOver architektura (odolná na výpadek serveru)

g) velká rychlost odezev systému

h) logování činností obsluhy včetně jejich změn

i) omezení důsledků lidské chyby - dodržení časových posloupností a zákonitostí vyplňování pro vyloučení nepravděpodobných nebo nemožných operací

2) Subsystém Operační Řízení - základní požadované vlastnosti – základní funkčnost subsystému IS OŘ musí podporovat alespoň následující:

a) příjem tísňové výzvy – pouze pro náhradní způsob příjmu tísňového volání, pro období odstávky nebo výpadku systému NSPTV v rámci projektu NIS IZS

b) předání informací o výzvě do seznamu čekajících výzev

c) předání výzvy vybrané výjezdové skupině prostřednictvím signalizace na mobilní telefony výjezdových skupin a zasláním výzvy do vozu, případně verbálně - vysílačkou, mobilem

d) sledování aktuálního průběhu řešení události prostřednictvím tzv. stavů výjezdové skupiny

e) online přístup do databáze uskutečněných událostí

f) vedení požadované evidence

g) generování základních rutinních sestav, tj. deníku dispečera, přehledu výjezdů apod.

h) událostně orientovaný přístup

i) sériový procesní režim

3) Popis funkcionalit – ZZS JMK využívá sériový procesní režim práce, což znamená, že existují oddělená pracoviště pro zajištění příjmu tísňové výzvy (call-taking/NSPTV) a pro operační řízení. Kvalifikace operátorů na pracovišti call-takingu (NSPTV) i dispečinku je

ovšem stejná, což umožňuje v případě potřeby dynamicky reagovat na kolísání zatížení na jednom či druhém úseku. To ovšem znamená, že jakékoliv pracoviště musí být vybaveno tak, aby na něm bylo možné bez nutnosti zásadních úprav nastavení vykonávat obě tyto role, vždy právě jen jednu z nich. Dispečeři ZZS JMK řídí provoz výjezdových skupin umístěných na výjezdových stanovištích rozprostřených na celém území Jihomoravského kraje. Výjezdová stanoviště jsou umístěna tak, aby zajistila včasné pokrytí celého území Jihomoravského kraje.

4) Následující tabulka uvádí popis základních požadovaných funkcionalit subsystému pro operační řízení (SOŘ) minimálně v rozsahu:

Popis

Příjem tísňové výzvy

Pouze pro náhradní způsob příjmu tísňového volání, pro období odstávky nebo výpadku systému NSPTV v rámci projektu NIS IZS.

Při příjmu tísňové výzvy musí SOŘ nabídnout operátorům podporu pro co nejefektivnější vyhodnocení události:

a) identifikaci volajícího (telefonní číslo, případně vlastníka telefonní stanice, pokud volá z pevné linky)

b) lokalizaci volajícího (ať volá z pevné linky nebo z mobilního telefonu)

c) lokalizaci události za podpory registru adresních bodů, databáze zájmových bodů a s možností lokalizovat událost přímo výběrem místa v mapě

Na základě případné korespondence telefonního čísla nebo adresy bude subsystém SOŘ informovat operátora při příjmu tísňové výzvy o případných předchozích událostech řešených s tímto volajícím (s možností přiřadit takovému kontaktu komentář dostupný při řešení budoucích výzev).

Operátor dále událost klasifikuje pomocí uživatelsky definovaných klasifikačních schémat a na základě přidělené klasifikace je automaticky nabídnuta indikace a priorita události. Ke každé události operátor uvede požadovaný počet prostředků a poté událost zařadí do seznamu čekajících událostí určených

k obsluze dispečery (sériový procesní model).

Kromě výzev na tísňovou linku ZOS musí SOŘ integrovat příjem tísňových SMS od zdravotně

postižených osob. Implementace SOŘ musí po přechodnou dobu zachovat již existující příjem událostí přicházejících formou datových vět ze systému TCTV 112. Tento systém bude následně nahrazen

systémem NSPTV v rámci realizace NIS IZS. Zadavatel nepředpokládá změny ve stávající integraci s TCTV112.

Operátoři ZOS kromě příjmu tísňových výzev evidují i objednávky sekundárních transportů.

Operační řízení

Dispečeři, kteří navazují na práci operátorů přijímajících tísňové výzvy, zajišťují zpracování událostí

čekajících v seznamu nevyřízených událostí tak, že dané události přidělí potřebné prostředky ZZS JMK. Při výzvě k výjezdu musí být výjezdová skupina automaticky informována prostřednictvím výzvy na mobilní telefony členů posádky (prozvonění) a současně je odesílán text výzvy i do vozu včetně

souřadnice místa zásahu (spolupráce se subsystémem sledování provozu vozidel. V průběhu výjezdu potom SOŘ musí zajišťovat příjem a zpracování statusů z vozů, a to jak z důvodu evidence průběhu výjezdu, tak pro potřebu přehledu dispečera o stavu řešení jednotlivých událostí.

Pro dokonalý přehled dispečerů musí SOŘ

a) přehled všech výjezdových skupin s rozlišením jejich stavu

b) přímý přehled o výjezdových skupinách spolupracujících v rámci jedné události v reálném čase

c) sledování a alertování anomálních stavů (např. překročení typické doby jednotlivých intervalů)

Popis

Událost je z pohledu operačního řízení považovaná za vyřešenou automaticky po ukončení posledního

výjezdu události.

Další oblasti

V reálném čase musí SOŘ nabízet možnost získat přehled o okamžitém zatížení systému a přehled o zatížení systému v dosavadním průběhu směny zobrazený měřitelnými veličinami (počet výjezdů jednotlivých výjezdových skupin, využitý čas apod.).

Pro možnost zpětné analýzy situace ZZS JMK v určitém čase je nutné generování takových podkladů, které situaci výjezdových skupin ve vybraném čase přehledně prezentují.

SOŘ musí umožňovat editaci výjezdových skupin, tedy složení posádek a přidělených vozů. Tato činnost je sice rutinně prováděna přímo posádkami výjezdových skupin, uživatelé však musí mít možnost v

případě potřeby složení výjezdových skupin upravit – jde především o možnost v případě potřeby

založit mimořádnou výjezdovou skupinu.

Požadované vazby SOŘ na další subsystémy

Systém sledování provozu vozidel:

Zadavatel požaduje takovou provázanost SOŘ se subsystémem sledování provozu vozidel, která zajistí:

a) odesílání souřadnic místa zásahu a textového popisu zásahu do vozů při výzvě k výjezdu včetně informace o „kvalitě“ souřadnic.

b) Kvalita souřadnic je chápána jako přesnost lokalizace místa zásahu, např. zda byla provedena lokalizace pomocí konkrétního adresního bodu, ulice, zájmových bodů, anebo přesných souřadnic GPS. Minimální rozsah (obsah) informace o kvalitě přenášených souřadnic navrhne Uchazeč ve své nabídce a dále rozpracuje v prováděcí dokumentaci.

c) možnost dalšího odeslání aktualizovaných informací v průběhu výjezdu

d) příjem statusů (informací o stavech výjezdu) z vozů do SOŘ

GIS klient

Zadavatel požaduje takovou integraci SOŘ a subsystému GIS klienta, která umožní:

a) zobrazení všech řešených událostí v GIS klientovi (a ve spolupráci se subsystémem sledování provozu vozidel i zobrazení polohy vozidel ZZS JMK v GIS klientovi)

b) možnost vyhledat v GIS klientovi konkrétní místo události zadávané v SOŘ

c) možnost vyhledat v GIS klientovi polohu volajícího vyhodnocenou subsystémem pro operační řízení

d) možnost upřesnit místo události v GIS klientovi a předat toto upřesnění do SOŘ (potažmo prostřednictvím subsystému SOŘ předat toto upřesnění do zasahujících vozů)

Požadované vazby SOŘ na systémy 3. Stran

RUIAN

Zadavatel požaduje, aby SOŘ využíval pro potřebu lokalizace událostí data registru RUIAN a aby byl zajištěn proces automatické aktualizace dat tohoto registru do lokální databáze adresních bodů subsystému pro operační řízení.

TCTV 112

Zadavatel požaduje po přechodnou dobu zachování existujícího systému příjmu datových vět

zasílaných operačním střediskem TCTV 112 a automatické zpětné odesílání stavů řešení události. Tento systém není součástí dodávky v rámci tohoto projektu a bude následně nahrazen systémem NSPTV v

rámci realizace NIS IZS.

Požadovaná integrace technologií

Telefonní ústředna pro operační řízení

Zadavatel požaduje takovou integraci, která umožní

a) zjištění čísla volajícího

b) po přechodnou dobu zachovat existující systém pro lokalizaci volajících z pevné linky i oblasti volání v případě mobilních volajících. Tento systém není součástí dodávky v rámci tohoto

Popis

projektu a bude následně nahrazen systémem NSPTV v rámci realizace NIS IZS.

Info35

Zadavatel požaduje zachovat existující integraci ZZS se službou Info35, která zajišťuje automatické zjišťování informací o vlastníku telefonní stanice pro příchozí tísňové výzvy z pevných linek.. Tento systém není součástí dodávky v rámci tohoto projektu a bude následně nahrazen systémem NSPTV v rámci realizace NIS IZS.

Záznamové zařízení

Zadavatel požaduje takové propojení SOŘ na hlasové záznamy systému pro zaznamenávání hovorů, které umožní provázání událostí s hlasovými záznamy telefonních tísňových výzev a následné

přehrávání relevantních hovorů přímo ze subsystému pro operační řízení.

Tabulka 7: Subsystém pro operační řízení (SOŘ) - popis základních požadovaných funkcionalit

5) Katalog požadavků na subsystém operačního řízení (SOŘ):

a) Katalog požadavků v oblasti podpory procesů ZOS

#	Oblast požadavků/požadavek	Podrobný popis požadavku
	Příjem tísňové výzvy
SOŘ.1	Podpora procesů ZOS	Informační systém musí podporovat všechny klíčové procesy zdravotnického operačního střediska.
SOŘ.2	Příjem tísňové výzvy	Zajistit podporu procesu přijetí tísňové výzvy pro potřeby náhradního příjmu tísňového volání, pro období odstávky nebo výpadku systému NSPTV v rámci projektu NIS IZS. Příjem tísňové výzvy zahrnuje lokalizaci události, klasifikaci události, indikaci. Výsledkem příjmu tísňové výzvy je vznik události.
SOŘ.3	Přidělení výzvy operátorovi	Možnost vyzvednutí výzvy (přijetí hovoru) libovolným operátorem.
SOŘ.4	Rozhodnutí o vzniku události - založení nové události	Rozhodnutí o vzniku události - založení nové události.
SOŘ.5	Využití historie dat	Nabídka informací o událostech, které generovalo stejné číslo volajícího, resp. které se udály na stejné adrese, možnost zobrazení a editace uživatelsky definované informace (comment).
SOŘ.6	Lokalizace události	Zajistit lokalizaci volajícího bez ohledu na způsob příjmu tísňové výzvy a využitý typ komunikačního prostředku (pevná linka, mobilní telefon, veřejná telefonní stanice). Zobrazení lokalizace události v GIS klientovi včetně okolních prostředků ZZS JMK.
SOŘ.7	Klasifikace události	Možnost klasifikace (popisu charakteru události) za pomoci číselníku resp. grafického schématu s možností víceúrovňového větvení.
SOŘ.8	Indikace	Možnost stanovení typu a počtu výjezdových skupin požadovaných k události.
SOŘ.9	Naléhavost	Stanovení naléhavosti události - požadováno rozdělení do 3 skupin naléhavosti + "standby" (odložená) událost + plánovaná událost (=v praxi zpravidla sekundární transport).
SOŘ.10	Další atributy události - typ "vyřídit - spolupráce"	Možnost zaznamenat nutnost předat informace jinam (typicky PČR, HZS, MP, nemocnice, krizový štáb, SMS systém, centrum DI apod.) - bude zobrazeno u události, bude se připomínat a po vyřízení bude zaznamenáno, kdo a kdy vyřídil.
SOŘ.11	Další atributy události - typ "sledovaná skupina"	Možnost zařadit událost do "sledované skupiny", které by bylo možné později využít pro odfiltrování výzev. Tyto skupiny by měly být jednak dopředu a standardně definované (např.

#	Oblast požadavků/požadavek	Podrobný popis požadavku
		"zařadit do hlášení") a jednak ad hoc. definovatelné (např. "dnes chceme sledovat počet osob, které spadly na náledí"). Pro supervizora možnost udržovat kompletní nabídku skupin, vedoucí dispečer z ní nastaví aktuální nabídku několika "sledovaných skupin" pro editaci událostí.
SOŘ.12	Předání informace o výzvě do seznamu čekajících výzev	Ukončení zpracování = odeslání do seznamu výzev = okamžik "přijetí výzvy".
SOŘ.13	Specifická rozšíření při příjmu tísňové výzvy od neslyšících	SMS kanál pro příjem tísňové výzvy.
SOŘ.14	Management přiřazení hovorů a událostí	Automatické přiřazení tísňového hovoru k události, upozornění na předchozí volání z téhož telefonního čísla
SOŘ.15	Zrušený záznam o události	Existence mechanismu pro uchování záznamu o události, u které byl založen záznam, ale nakonec nedošlo ke vzniku události (přijímání bylo přerušeno, ukázalo se, že nejde o událost).
SOŘ.16	Sekundární transport	Zpracování objednávky sekundárního transportu.
	Operační řízení
SOŘ.17	Zobrazení seznamu čekajících výzev	Seznam čekajících výzev je dále zpracováván dispečery řídícími nasazování VS. Existuje zvláštní seznam výzev neřešených, "standby", plánovaných, vyřešených.
SOŘ.18	Zobrazení přehledu mobilních prostředků	Kompletní přehled prostředků, ať již zasahujících nebo připravených.
SOŘ.19	Přiřazení výzvy výjezdové skupině (skupinám)	Alokace konkrétní výjezdové skupiny ke konkrétní události.
SOŘ.20	Předání výzvy výjezdové skupině ZZS JMK	Předání výzvy vybrané výjezdové skupině.
SOŘ.21	Podpora koordinace spolupráce mezi výjezdovými skupinami	Do vozidlových jednotek odchází informace o VS přiřazených k události / odebraných z události.
SOŘ.22	Editace vlastností události	Možnost editace všech informací vztahujících se k události, tj. zejména druhu a počtu požadovaných VS, požadavek na spolupráce, přiřazení/zrušení "sledování události". Změna priority, označení jako "standby".
SOŘ.23	Zobrazení VS pro událost	Zobrazení výjezdových skupin jak požadovaných, ale ještě nealokovaných, tak VS již alokovaných k události a to vhodnou, přehlednou formou.
SOŘ.24	Zobrazení stavu VS v návaznosti na událost	VS zasahující zobrazované v rámci události budou odlišeny podle stavu VS.
SOŘ.25	Zobrazení místa události	Zobrazení místa a na žádost i zobrazení přiřazení VS k dané události - propojením čarami, které za cca 3 sekundy samy zmizí.
SOŘ.26	Přiřazení pacienta k výjezdové skupině	Ke každé výjezdové skupině je možné přiřadit 1 až N pacientů. Existuje mechanismus, kterým je možné přiřadit pacienta k události, a pacient se automaticky přiřadí ke všem zasahujícím výjezdovým skupinám.
SOŘ.27	Editace údajů o pacientovi	Je nutné mít možnost zaznamenat údaje v rozsahu: příjmení, jméno, ročník / rok narození (volný text), způsob ukončení péče o pacienta - komu byl pacient předán - bližší informace kam byl předán - poznámka.
SOŘ.28	Sdružování a rozdělování událost	Možnost sloučit dvě události do jedné (s řízeným převzetím atributů - jedna z nich bude dominantní a druhá převezme její atributy), a naopak, možnost rozdělení jedné události na dvě s řízeným rozdělením případně již přidělených VS.

#	Oblast požadavků/požadavek	Podrobný popis požadavku
SOŘ.29	Sledování řešení události	Stav řešení události podle stavu přiřazených VS, tj. událost ještě neřešená, událost částečně řešená (není alokováno ještě vše, co je požadováno), zcela řešená, vyřešená (poslední alokovaná VS předala pacienta). Dále STANDBY a PLÁNOVANÁ.
SOŘ.30	Zobrazení stavů jednotlivých výjezdových skupin	Včetně příjmu stavových hlášení z mobilních prostředků.
SOŘ.31	Dočasné zachování stávající možnosti předání stavové informace o události systému TCTV 112	Dočasné zachování existujícího, automatického předávání stavů řešení událostí převzatých z TCTV 112 zpět do TCTV 112. Tento systém není součástí dodávky v rámci tohoto projektu a bude následně nahrazen systémem NSPTV v rámci realizace NIS IZS.
SOŘ.32	Informační a komunikační podpora výjezdových skupin	Přenos dat do vozidlových jednotek, včetně souřadnic místa události
SOŘ.33	Podpora procesů supervizora	Správa databází, tvorba sestav, statistik vyšší úrovně.
SOŘ.34	Monitorování práce dispečerů	Počty zpracovaných volání, přihlášení do systému apod.
SOŘ.35	Možnost převzetí práce dispečera	Možnost předání rozpracovaných dat o příjmu výzvy na pracoviště jiného operátora v rámci operačního střediska ZZS JMK.
SOŘ.36	On-line přístup do databáze událostí	Hledání podle parametrů - čas, místo, pacienti, zasahující VS, klasifikace, místo předání.
SOŘ.37	Vedení předepsané evidence	Včetně tisku deníku dispečera 1x za 24 hodin.
SOŘ.38	Generování sestav a statistik	Přehled dojezdů nad stanovenou dobu + měsíční statistiky - počty, dojezdové doby, časové intervaly, zatížení výjezdových skupin, atd.
SOŘ.39	Rozlišení role call-taker (operátor NSPTV) a dispečer	Call-taker řeší náběr tísňových výzev. Oddělit od role dispečer - řídí provoz a řešení nabraných tísňových výzev (oddělení nemusí být nutně striktní, pokud systém umožní plnit obě role v jedné konfiguraci).
SOŘ.40	Možnost rychlé změny role operátora	Umožnit výměnu rolí dispečerů a calltakerů v rámci hybridního pracoviště.
SOŘ.41	Rychlý a efektivní přístup k informacím	Zachování přístupu k informacím pro obě role bez nutnosti blokovat přístup pro ostatní uživatele, pokud nejsou informace uživatelem modifikovány.
SOŘ.42	Podpora objektového a procesního konceptu výzva - událost - pacient	Rozlišování těchto entit a udržování vazeb mezi nimi.
SOŘ.43	Podpora archivace a vyhledání komplexní informace o událostech včetně multimediálních příloh	Tj. data + záznamy hovorů.
	Ostatní požadavky v oblasti podpory procesů činnosti ZOS
SOŘ.44	Editace obsazení VS	Udržování přehledu o VS ve službě včetně obsazení konkrétním vozidlem a personálem.
SOŘ.45	Automatická aktualizace obsazení VS	Automatická aktualizace obsazení VS ve spolupráci se sw. pro plánování směn.
SOŘ.46	Možnost uživatelské definice bodů zájmu	Včetně možnosti importu z obecného formátu (csv).
SOŘ.47	Uživatelská definice klasifikačních schémat	Ve formě bitmapového obrázku včetně nastavení parametrů pro automatizaci navazujících akcí, tj. 1. stanovení indikace události 2. návrhu indikovaných činností.
SOŘ.48	Jednoduchý export dat ve vhodném formátu pro další zpracování a analýzu	Umožnit exportovat data ze systému ve formátech (XLS, CSV, XML)

#	Oblast požadavků/požadavek	Podrobný popis požadavku
SOŘ.49	Fulltextové vyhledávání v databázích zájmových objektů a adresných bodů	Oddělení hledání v databázi adresních bodů a zájmových bodů včetně možnosti definice spádového ZZ k danému katastru.
SOŘ.50	Lokalizace na základě RUIAN, provázání s mapou	Zadání adresy a následné zobrazení na mapě v GIS klientovi.
SOŘ.51	Lokalizaci události přímým výběrem místa či oblastí z mapy	Výběr místa na mapě a přenesení do SOŘ.
SOŘ.52	Zobrazení všech aktivních řešených událostí v mapě	Podpora zpracování nových výzev, aby při lokaci přijímající call-taker viděl, zda v daném místě již není přijata událost na jiném pracovišti.
SOŘ.53	Třídění událostí podle jejich vlastností a/nebo stavu zpracování	Pro snadnou orientaci v řešených událostech.
SOŘ.54	Sledování a alertování anomálních stavů	Např. překročení typické doby jednotlivých intervalů zpracování tísňové výzvy, časy aktivace výjezdové skupiny).
SOŘ.55	Přímá vazba na rádiový a telefonní komunikační systém, VS lze kontaktovat přímo z prostředí dispečerského systému.	Možnost ovládání a využívání telefonních a radiových technologií přímo z rozhraní informačního systém operátora.
SOŘ.56	Automatické alertování zájmových osob v případě výskytu události určitých vlastností.	Upozornění tiskového mluvčího, aktivováno dispečerem.
SOŘ.57	Podpora „nativního“ záznamů a zpracování „netypických“ stavů výjezdových skupin – např. údržby, poruchy, asistence.	Řešit analogicky jako tísňové výzvy + možnost označit VS jako konající asistenci.
SOŘ.58	Vazba na podklady o obsazení výjezdových skupin	Integrace s modulem pro plánování směn.
SOŘ.59	Podpora analýzy a vyhledávání dat – podpora pro zpětnou analýzu stavu systému v určitém čase.	Vytvoření přehledu o situaci VS pro zpětnou analýzu situace v určitém zadaném čase.
SOŘ.60	Vyhledávání v událostech a záznamech výjezdů	Vyhledávání v událostech pomocí nejrůznějších omezujících podmínek. Hledání mezi záznamy o výjezdech pomocí výjezdové skupiny, oblasti, data, SPZ, doktora, pacienta apod.
SOŘ.61	Podpora předávání všeobecných informací mezi dispečery.	"Chat" mezi dispečery + možnost předat informaci cílené osobě po přihlášení do systému.
SOŘ.62	Zajištění aktuálnosti RUIAN	Přímý import z RUIAN, včetně podpory při aktualizačních procesech této databáze.

b) Katalog požadavků na integraci SOŘ s externími systémy a technologiemi

#	Oblast požadavků/požadavek	Podrobný popis požadavku
	Integrace SOŘ s GIS klienta
SOŘ.63	Výběr adresních bodů	Na základě číselníku adresních bodů.
SOŘ.64	Zobrazení místa události	Zobrazení na mapě místa události zadaného v dispečerském systému.
SOŘ.65	Zobrazení přehledu mobilních prostředků	Přehled aktuální polohy prostředků ZZS JMK.
SOŘ.66	Navigace mobilních prostředků	Navigace jako taková není požadována, pouze posílání souřadnic do navigace Garmin, spojené s GPS jednotkou ve vozidle.
	Integrace SOŘ s telefonní ústřednou
SOŘ.67	Načtení čísla volající stanice	Identifikace telefonního čísla volajícího.

#	Oblast požadavků/požadavek	Podrobný popis požadavku
SOŘ.68	Hromadné obvolávání	Hromadné hlasové obvolávání, předpokládá se integrace se stávajícím systémem hlasového svolávání v ZZS JMK.
SOŘ.69	Lokalizace volajícího	Lokalizace volajícího z pevné linky nebo mobilního volajícího (po přechodnou dobu do spuštění NSPTV).
SOŘ.70	Logování stavů a průběhů hovorů	Ukládání informací o hovorech.
SOŘ.71	Poskytování informací o hovoru	Načtení signalizace a informací z aplikačního serveru záznamového zařízení.
SOŘ.72	Typizace volajícího čísla	Rozlišení typu telefonního čísla.
	Integrace SOŘ s Info 35
SOŘ.73	Lokalizační informace pevných linek	Zjištění údajů o telefonní stanici na základě telefonního čísla.
SOŘ.74	Lokalizační informace mobilních operátorů	Umožnění přibližné lokalizace volajícího a zprostředkovat následné zobrazení v GIS klientovi.
	Integrace SOŘ s TCTV 112
SOŘ.75	Příjem, zobrazení a využití datové věty	Zobrazení více posledních příchozích vět se zřetelným označením jednoznačné identifikace (číslo volajícího), možnost procházet historii, převzít data ze starší věty.
SOŘ.76	Předání stavu řešení události	Dočasné zachování existujícího průběžného automatického poskytování stavu řešení události zpět do TCTV 112. Tento systém není součástí dodávky v rámci tohoto projektu a bude následně nahrazen systémem NSPTV v rámci realizace NIS IZS.
	GPS mobilních prostředků
SOŘ.77	Sledování polohy mobilních prostředků.	Prostřednictvím integrace na systém sledování polohy vozidel a GIS klienta.
	Integrace SOŘ se záznamovým zařízením
SOŘ.78	Záznam hovorů	Možnost připojení nahrávaných telefonních a radiových relací k záznamu o události
SOŘ.79	Integrace s mobilními telefony výjezdových skupin	Předání výzvy k výjezdu na mobilní telefon VS
	Integrace SOŘ s vozidlovou jednotkou
SOŘ.80	Vozidlová jednotka	Přenos dat do vozidlové jednotky, včetně souřadnic místa události

c) Katalog požadavků na obecné vlastnosti SOŘ

#	Oblast požadavků/požadavek	Podrobný popis požadavku
	Kapacita, výkon
SOŘ.81	Snadná obsluha	Jednoduchá, uživatelsky vstřícná obsluha.
SOŘ.82	Vlastnosti GUI	Vhodná velikost a barevné provedení GUI.
SOŘ.83	Stabilní databázový systém	Stabilní a robustní databázové prostředí s možností zajištění vysoké dostupnosti systému.
SOŘ.84	Vysoká rychlost odezvy	Vysoká rychlost odezvy systému při všech klíčových aktivitách.
SOŘ.85	Dostatečná kapacita VS	Kapacita systému, musí umožňovat obsluhu více jak 70 skupin ve službě.
	Bezpečnost
SOŘ.86	Fail-over	Fail-over řešení zajišťující dostupnost klíčových systémů 24x7.
SOŘ.87	Automatické obnovení funkce systému	Automatické obnovení funkce systému při jakékoliv poruše libovolných komponent systému v určeném časovém limitu.
SOŘ.88	Zabezpečení komunikace	Zabezpečení komunikace citlivých údajů.
SOŘ.89	On-line zálohování systému	On-line zálohování systému bez vlivu na kvalitu služeb poskytovaných systémem.

#	Oblast požadavků/požadavek	Podrobný popis požadavku
SOŘ.90	Systém řízení přístupových práv k záznamům	Na úrovni dispečer - vedoucí dispečer – supervizor.
SOŘ.91	Logování změn	Systém logování provedených změn v záznamech.
SOŘ.92	Validace vstupních dat	Validace vstupních dat, kontrola rozsahu vstupních údajů jakož i logických a časových vazeb.
SOŘ.93	3 oddělené obrazovky s informacemi	GIS klient přehled událostí a prostředků *komunikační panel

Tabulka 8: Subsystém operačního řízení (SOŘ) - katalog požadavků

1.6.3.2 Subsystém IS pro zadávání dat na výjezdových stanovištíc – Elektronická karta pacienta (dále jen

„EKP“)

Základní požadavky na subsystém EKP:

1) příjem výzev k výjezdu na výjezdovém stanovišti

2) možnost editace dat výjezdů a pacientů potřebných pro účtování a pro statistické výstupy

3) možnost zadat data o pacientovy ve stejném rozsahu jako v mobilní klientovy, vyjma dat z externích zařízení

4) evidence výkonů a podaných léků

5) Tento typ zadávání dat je funkčně identický s MZD, vyjma napojení na externí zařízení a import dat z těchto zařízení (monitor/defibrilátor LP12/15).

6) Je preferováno rozhraní tenkého klienta pro použití na výjezdových stanovištích

7) Katalog požadavků na EKP:

#	Požadavek	Podrobný popis požadavku
EKP. 1	Standardizace pořízené zdravotní dokumentace	Aplikace musí informovat uživatele o validitě zadaných dat. Zda splňují nepodkročitelné minimum požadovaných informací, které odpovídají definovaným kritériím závažnosti postižení pacienta (např. NACA skóre)
EKP. 2	Umožnit tisk Záznamu o výjezdu ZZS	Možnost tisku zadaných dat do formátu PDF.
EKP. 3	Ergonomické uživatelské rozhraní	Snadné zadání informací, maximální podpora funkcionality v uživatelském rozhraní. UI aplikace přizpůsobené workflow výjezdové skupiny (RLP, RZP). ▪ Logický postup zadávání dat ▪ Grafické rozhraní musí odpovídat logickému postupu vyplňování ▪ Důraz na ergonomii zadávání dat
EKP. 4	Příjem výzev ze SOŘ	Aplikace musí obdržet nejpozději do 3 min od přijetí výzvy posádkou vybrané informace o výzvě ze SOŘ

#	Požadavek	Podrobný popis požadavku
EKP. 5	Příjem informací o výjezdu z mobilních terminálů do centrálního systému	V případě uzavření záznamu o výjezdu ze strany uživatele musí být centrální systém aktualizován nejpozději do 3 min.
EKP. 6	Podpora událostního modelu založeného operátorem ZOS	Musí být možno sdílet informace např. o pacientech v rámci jedné události.
EKP. 7	Zobrazení informací o ošetřovaném pacientovi z interního registru pacientů ZZS	Po zadání identifikačních údajů pacienta do aplikace, může uživatel vznést dotaz na historii pacienta z interního registru ošetřených pacientů ZZS. Aplikace musí umožnit posádce zobrazení vybraných informací o minulých intervencích ZZS.
EKP. 8	Zobrazení emergentních informací o ošetřovaném pacientovi z externích EHR registrů (CZ)	Po zadání identifikačních údajů pacienta do aplikace, pokud je pacient identifikován v externím EHR registru. Tyto registry budou specifikovány uživatelem a podmínkou je smluvní dostupnost těchto registrů
EKP. 9	Zobrazení emergentních informací o ošetřovaném pacientovi z externích EHR registrů (EU)	Po zadání identifikačních údajů pacienta - cizince (EHIC) do aplikace, pokud je pacient identifikován v externím EHR registru, musí mobilní terminál umožnit posádce zobrazit jeho emergentní dataset jako podporu rozhodování. Podmínkou je smluvní dostupnost tohoto registru.
EKP. 10	Zobrazení informací o ošetřovaném pacientovi z dalších možných externích EHR registrů (CZ)	Získání dalších informací o pacientovi z nově zprovozněných registrů např. (Lékový profil - datové úložiště ÚZIS, specializované registry - diabetes, kardiovaskulární). Podmínkou je smluvní dostupnost tohoto registru.
EKP.11	Požadavky na celkové řešení	Snadná obsluha a ergonomie,
EKP.12	Obecné požadavky na SW	velké zobrazení, intuitivní funkce, možnost vstupu kdekoliv v průběhu zapisování, rychlé zkopírování známých dat z jiných databází (např. SOŘ) automaticky, možnost porovnání s databází (zda již stejného pacienta neobsahuje), fulltextové vyhledávání.
EKP. 13	Technologie pro autentikaci	Xxxxx a heslo
EKP. 14	Verifikace potřebných dokladů k následnému vyúčtování	Řešení musí obsahovat nástroj na verifikaci poskytnutých dokladů pacienta tak, aby mohlo proběhnout následné vyúčtování

Tabulka 9: Subsystém Elektronická karta pacienta (EKP) – katalog požadavků

1.6.3.3 GIS klient

1) GIS klient bude nasazen současně s IS OŘ, proto musí splňovat požadavky kladené na systém ZZS JMK jako celek. GIS klient bude v cílovém řešení napojen na GIS realizovaný v rámci NIS IZS a bude z tohoto systému čerpat data. Dočasně, do doby realizace NIS IZS, bude GIS klient využívat lokální GIS data. Na GIS klienta jsou kladeny následující obecné požadavky:

a) velká rychlost odezev systému

b) stabilita systému a FailOver architektura (odolná na výpadek serveru)

c) dostatečná výkonnostní rezerva

d) uživatelsky jednoduchá obsluha, stálé uživatelské rozhraní

e) ergonomické zobrazení – vhodná velikost a barevné provedení uživatelského interface

f) logování činností obsluhy včetně jejich změn

g) detailní mapové podklady pro celé území ČR

h) uživatelská definice zájmových bodů

i) kompatibilita se standardními GIS technologiemi a základními mapovými formáty pro výměny geografických dat (shapefile, jpg, gif)

j) úzká integrace se SOŘ, která umožní efektivní využívání obou subsystémů na jedné virtuální pracovní stanici s využitím separátních monitorů pro každý subsystém

2) Základní požadované funkce GIS klienta:

a) lokalizace místa události na základě předané polohy ze subsystému OŘ

b) lokalizace volání z pevných linek na základě předané polohy volajícího ze subsystému OŘ

c) lokalizaci oblasti volání z mobilního telefonu na základě předané polohy volajícího ze subsystému OŘ

d) lokalizaci události přímým výběrem místa či oblastí z mapy

e) zobrazení všech aktivních řešených událostí v mapě (v GIS klientovi), pro to, aby při lokaci přijímající call-taker viděl, zda v daném místě již není přijata událost na jiném pracovišti

f) poskytnutí přímého přehledu o výjezdových skupinách spolupracujících v rámci jedné události v reálném čase (vizualizace vztahu výjezdové skupiny – události)

g) podpora stavů výjezdových skupin – např. údržby, poruchy, asistence.

h) zobrazení stavu a typu výjezdové skupiny, při změně obsazení v průběhu směny (RLP x RZP) vizualizace této změny.

i) rychlé fulltextové vyhledávání s přímým náhledem v mapě v adresách, místopisu i zájmových bodech

j) dynamická vizualizace výjezdových skupin v mapě, která pomocí shlukování eliminuje vzájemné překryvy symbolů a zvyšuje přehlednost zobrazení

k) snadná editace bodů zájmu včetně možnosti připojení libovolných dokumentů. Podpora workflow, které umožňuje administrátorovi sledování a validaci změn.

l) body zájmu editované v GIS klientovi jsou použity zároveň v SOŘ pro jeden ze zdrojů lokalizace události.

m) možnost zobrazení situační mapy s aktuální situací na velkoplošném zobrazovacím zařízení

n) možnost zobrazení (menší) přehledové mapy s vymezením území zobrazeného v hlavním mapovém okně

o) GIS klient neustále zobrazuje informace popisující umístění kurzoru v mapě (název obce, název KÚ apod.)

p) nástroj administrátora, který umožňuje:

q) nastavení zobrazení/vizualizace mapy

r) nastavení databázových připojení

s) nastavení databází pro fulltextové vyhledávání

3) Následující tabulka uvádí popis základních požadovaných funkcionalit GIS klienta minimálně v rozsahu:

Popis

Příjem tísňové výzvy (pouze pro náhradní způsob příjmu tísňového volání, pro období odstávky nebo výpadku systému NSPTV v rámci projektu NIS IZS)

a) fulltextové vyhledávání v databázích zájmových objektů a adresných bodů

b) lokalizace na základě RUIAN, provázání s mapou

c) po přechodnou dobu zachovat podporu služby INFO35 (lokalizace volání z pevných linek na základě předané polohy volajícího ze subsystému OŘ). Bude nahrazeno systémem NSPTV.

d) po přechodnou dobu zachovat lokalizaci oblasti volání z mobilního telefonu na základě předané polohy volajícího ze subsystému OŘ. Bude nahrazeno systémem NSPTV.

e) lokalizaci události přímým výběrem místa či oblastí z mapy

f) zobrazení všech aktivních řešených událostí v mapě (v GIS klientovi), pro to, aby při lokaci přijímající call-taker viděl, zda v daném místě již není přijata událost na jiném pracovišti

g) zobrazení dalších zájmových vrstev mapy (např. rozmístění AED, stanoviště ZZS, zdravotnická zařízení, uzavírky apod.).

Operační řízení

a) poskytnutí přímého přehledu o výjezdových skupinách spolupracujících v rámci jedné události v reálném čase

b) kapacita systému, musí umožňovat obsluhu více jak 60 skupin ve službě

Datové požadavky

a) přímý import z RUIAN, včetně podpory při aktualizačních procesech této databáze

b) Orthofoto mapy využívané a spravované krajem

Správa a administrace dat

a) centrální správa dat

b) omezení možných duplicit v datech

c) zálohování dat

Vazba na SOŘ

Významnou podmínkou zajištění požadované funkčnosti je integrace se SOŘ:

a) zobrazení všech řešených událostí v mapě

b) lokalizace konkrétního místa události zadávané v SOŘ

c) možnost vyhledat v GIS klientovi polohu volajícího vyhodnocenou SOŘ

d) zpřesnění polohy události v mapě a předání tohoto upřesnění do SOŘ a pomocí následně do vozů

e) vizualizace vazby mezi událostí a přidělenými zasahujícími prostředky ZZS JMK

f) přiřazování prostředků k jednotlivým událostem tím způsobem že uživatel v mapě vybere výjezdovou skupinu a přímo v mapě ji přiřadí k události (může následovat dialog upřesňující tohoto přiřazení)

g) stavy SOŘ a GIS klientovi musí být sladěné (například výběr události v GIS klientovi vybere tutéž událost i v SOŘ)

Vazba na subsystém sledování provozu vozidel

Další požadovaná integrace je se subsystémem sledování provozu vozidel. Tato integrace zajišťuje

průběžné a spolehlivé předávání informací pro GIS klienta:

Popis

a) příjem souřadnic poloh jednotlivých výjezdových posádek

b) příjem statusů - informací o stavech posádky a vozidel

Požadovaná integrace technologií

GIS klient vyžaduje integraci s těmito subsystémy a technologiemi:

a) Systém pro operační řízení (SOŘ)

b) Systém sledování provozu vozidel

Soulad s budoucím Národním systémem příjmu tísňového volání.

GIS klient musí být svým technologickým řešením připraven na integraci s budoucím Národním

systémem příjmu tísňového volání (NSPTV). GIS klient proto musí odpovídat standardům pro webové mapové a geoprocessingové služby a musí být připraven na integraci pomocí webových služeb typu

SOAP a REST v rámci architektury SOA.

Tabulka 10: GIS klient - požadavky na základní funkcionality

(1) Katalog požadavků na GIS klienta:

#	Požadavek	Podrobný popis požadavku
GIS.1	Obecné požadavky na IS ZZS JMK	GIS klient nasazený na operačním středisku musí splňovat obecné požadavky, kladené na celý systém.
GIS.2	Stabilita	GIS klienti musí být stabilní. Nesmí docházet k častým výpadkům v jejich funkčnosti.
GIS.3	Jednoduchá správa	Je požadováno, aby tematické vrstvy ZZS v GIS klientovi byly snadno upravovatelné a lehce nasaditelné.
GIS.4	Vysoká rychlost odezvy	Základním požadavkem je vysoká rychlost odezev GIS klienta a rychlé překreslování zobrazovaných mapových podkladů.
GIS.5	Ergonomické zobrazení, jednoduchá obsluha	GIS klient musí být snadno obsluhovatelný a přehledný. Mělo by být použito takové grafické uživatelské rozhraní, aby se uživatel snadno v aplikaci orientoval.
GIS.6	Uživatelská definice zájmových bodů	Požadavek zadávání a editace databáze zájmových bodů ZZS JMK, sloužící pro lokalizaci míst událostí, vybranými pracovníky ZOS. Právo modifikovat databázi zájmový bodů bude mít role supervizora (vystupuje také jako správce, administrátor GIS). Naopak upravovat definici zájmových bodů nebude přístupné pro běžné pracovníky ZOS (call-taker i dispečer) či vedoucího dispečinku.
GIS.7	Detailní mapové pokrytí území ČR	GIS klient musí zobrazovat mapové podklady za celou Českou republiku a nejen za území Jihomoravského kraje.
GIS.8	Oddělení grafického uživatelského rozhraní pro dispečera a další zodpovědné osoby	Požadavek na rozdílné uživatelské rozhraní pro dispečera a další zodpovědné osoby (např. editace tematických vrstev ZZS), které provádí odlišné operace. Je potřeba, aby všechna pracoviště ZOS byla vybavena GIS klientem stejného GUI a stejné vizualizace pro dispečery.
GIS.11	Datové požadavky	GIS klient musí zobrazovat mapové podklady v přiměřeném obsahovém rozsahu za území celé ČR v přehledné vizualizaci s rychlým vykreslováním.
GIS.14	IS OŘ může využívat další dostupná tematická data ZZS jako např. vlastní data či data jiných organizací	IS OŘ bude využívat další prostorová data (tematické vrstvy ZZS) jako vlastní (rozmístění AED = databáze defibrilátorů, stanoviště ZZS JMK, zdravotnická zařízení), která buď již existují, nebo budou vznikat a budou pod správou ZZS JMK.
GIS.15	Kompatibilita se službami OGC	GIS klient musí odpovídat otevřeným mezinárodním standardům (OGC) tak aby mohl být klientem odpovídajících

#	Požadavek	Podrobný popis požadavku
		mapových a geoprocesingových služeb.
GIS.16	Funkce GIS klienta	GIS klient nasaditelný na ZOS musí být podporou pro rozhodování pracovníka dispečinku a musí předně poskytovat informace o rozmístění mobilních jednotek a přehled všech aktuálně řešených událostí.
GIS.17	Zobrazení všech míst událostí v mapě	GIS klient musí zobrazovat v mapě všechny aktuálně řešené události.
GIS.18	Zobrazení polohy všech mobilních jednotek v mapě	Požadavek na zobrazení všech vozů v mapě a jejich aktuální polohy včetně stavu vozidla (zda se jedná o RLP či RZP) a stavu posádky.
GIS.19	Zobrazení aktuální dopravní situace v mapě	GIS klient by měl zobrazovat v mapě především uzavírky, případně nehody a hustotu provozu.
GIS.20	Lokalizace místa událostí	Požadavek lokalizace místa události v mapě z dispečerské aplikace pomocí RUIAN kódu či pomocí souřadnic XY.
GIS.21	Lokalizace místa události zadáním konkrétních souřadnic	Požadavek lokalizace místa události v mapě zadáním souřadnic XY události v GIS klientovi. Informace následně bude předána dispečerské aplikaci.
GIS.22	Lokalizace místa události přímým výběrem místa z mapy či oblasti z mapy	Požadavek lokalizace místa události klikem do mapy či výběrem oblasti. Informace následně bude předána dispečerské aplikaci.
GIS.23	Lokalizace místa volajícího na základě předané polohy volajícího ze subsystému OŘ	Požadavek automatické lokalizace volání v mapě ať už z pevné linky či mobilního telefonu.
GIS.24	Logování činností obsluhy	Prováděné operace v GIS klientovi je třeba logovat. Je zaznamenána identita obsluhy a čas prováděných operací.
GIS.25	Stabilita geografického uživatelského rozhraní	GIS klient se musí vyznačovat neměnností uživatelského rozhraní.
GIS.26	Fulltextové vyhledávání v databázích zájmových objektů a adresních bodů	Fulltextové vyhledávání bude primárně řešeno v dispečerské aplikaci SOŘ a sekundárně i v rámci GIS klienta (zde včetně rychlého náhledu v mapě).
GIS.27	Možnost změnit polohu vozu v mapě	Požadavek na určení polohy vozu v mapě jeho uchopením myší a přetažením (např. v případě, že došlo ke ztrátě signálu GPS).
GIS.28	Přehledová mapa	GIS klient by měl obsahovat přehledovou mapu podávající náhled na celou zájmovou oblast. Nepředpokládá se změna měřítka přehledové mapy.
GIS.29	Vizualizace vazby událost - posádka (vůz) v mapě	Aplikace ukáže na mapě spojnici mezi bodem události a aktuální polohou přiděleného vozidla na výjezdu.
GIS.30	Modifikace přiřazení posádek k události	V mapě umožnit úpravu přiřazení posádek k události pomocí metody "drag & drop". Změnu předat do dispečerské aplikace.
GIS.31	Zobrazení dodatečných informací o objektech	Zobrazení dodatečných informací po kliku na objekty specifických vrstev v mapě např. zobrazení havarijního nebo krizového plánu.
GIS.32	Správa sdílení dat a proces aktualizace	GIS klient musí řešit způsob správy a aktualizace tematických vrstev ZZS a vizualizačního projektu.
GIS.33	Centrální správa dat	Správa a aktualizace tematických dat ZZS by měla být řešena centrálním způsobem na úrovni kraje.
GIS.34	Omezení možných duplicit v datech	Systém správy a aktualizace tematických dat ZZS by měl být vytvořen tak, aby co nejvíce omezil možné duplicity v datech.
GIS.35	Zálohování dat	Systém správy a aktualizace tematických dat ZZS musí řešit zálohování dat proti výpadku centrálního úložiště.

#	Požadavek	Podrobný popis požadavku
GIS.36	Naplnění a aktualizace vyhledávacích databází, tj. databáze adres	GIS klient i SOŘ budou využívat automaticky aktualizovaná data.
GIS.37	RUIAN a databáze zájmových bodů	GIS klient i SOŘ budou využívat databázi adresních bodů a společnou databázi zájmových bodů v rámci kraje.
GIS.38	Způsob předávání a aktualizace vyhledávacích databáze, tj. databáze adres RUIAN a zájmových bodů	IS OŘ musí řešit způsob předávání databáze určené pro vyhledávání RUIAN databáze a databáze zájmových bodů) a proces její aktualizace.
GIS.40	Editace tematických dat ZZS	Požadavek editace tematických dat ZZS vybranými pracovníky ZOS. Právo modifikovat data určená pro GIS klienta bude mít role supervizora (vystupuje také jako správce, administrátor GIS). Mělo by se jednat o úpravy jak geometrické, tak popisné složky tematických dat ZZS.
GIS.43	Umožnit k jednotlivým POI evidovat libovolné další dokumenty formou jakési přílohy (obrázky, schémata, dokumenty)	Správa zájmových bodů ZZS bude poskytovat možnost evidence elektronických příloh k jednotlivým bodům zájmu. Elektronická příloha bude libovolný soubor (fotografie, textový dokument, apod.). Každá příloha bude mít svůj název, popis a vlastníka.
GIS.44	Podporovat v GIS klientovi další uživatelskou roli "Prohlížeč událostí"	Uživatel v této roli pracuje pouze s GIS klientem. Není aktivní vazba do SOŘ. Uživatel může pouze prohlížet a hledat v mapě. Uživatel si přímo v GIS klientovi může nechat zobrazit seznam Událostí a VS, může v nich vyhledávat, zobrazovat o nich podrobnější informace a nechat si je zobrazovat v mapě. Primárně má sloužit pro náhled na aktuální události a práci VS. Omezená další funkcionalita (bude specifikováno během analýzy a návrhu).
GIS.46	Řešení kolizí při zobrazování značek v mapě reprezentujících události a VS (tzn., že značky se musí při vizualizaci od sebe "rozestoupit" tak, aby nedošlo k překryvům).	Řeší situaci, kdy se v mapě překrývají symboly událostí nebo výjezdních skupin, pokud je jich více na jednom místě nebo jsou blízko sebe a mapa je v malém měřítku. Tato situace znesnadňuje výběr události nebo VS. Při najetí kurzoru myši na místo, kde je více událostí nebo VS na sobě, se jejich symboly "rozestoupí", aby se jejich symboly nepřekrývaly, a umožní tak uživateli snazší přístup ke konkrétní události nebo VS a volbě nějaké funkce.
GIS.48	Pevná přehledová mapka v samostatném okně.	Systém umožní v samostatném okně zobrazení pracovní vybrané části mapy v kontextu celého území kraje
GIS.49	Umožnit zobrazovat ve stavové liště informace o souřadnicích a lokalitě místa, na které ukazuje kurzor myši	Informace o souřadnicích a lokalitě místa v místě, kde se nachází kurzor, se zobrazují ve stavové liště, která je neustále uživateli viditelná.
GIS.50	Konfigurace fontů a ikon	Umožnit konfiguraci použitých fontů a ikon.
GIS.51	Zahájit změnu polohy události v mapě výběrem položky pomocí kontextového menu a/nebo pomocí klávesové zkratky.	Přesun události v mapě se provede výběrem události a následným kliknutím pravým tlačítkem do místa, kam má být událost nově přesunuta. Mezi výběrem a kliknutím je možné provádět navigaci v mapě (zoom, posun). Přesun je do SOŘ automaticky potvrzen.
GIS.52	Výběr události v mapě pouze přes pravé tlačítko	Výběr události přes levé tlačítko myši si uživatel musí pamatovat, umístěním této funkce do kontextového menu, si uživatel může přečíst, co všechno lze dělat s událostí, na kterou klikl pravým tlačítkem myši.
GIS.53	Přehledová mapa území	Přehledová mapa, zobrazující ve stálém měřítku zájmové území dispečera s vyznačenou oblastí, která je zobrazena v

#	Požadavek	Podrobný popis požadavku
		hlavním mapovém okně.

Tabulka 11: GIS klient – katalog požadavků

1.6.3.4 Doplňující moduly IS OŘ

1) Doplňující moduly – požadavky na obecné vlastnosti:

a) uživatelsky jednoduchá obsluha, stálé uživatelské rozhraní

b) on-line zálohování dat

c) FailOver architektura (odolná na výpadek serveru)

d) velká rychlost odezev systému

e) automatická distribuce nových verzí aplikace na stanice

f) instalační program pro snadnou instalaci aplikace na stanici

g) centrální správa systému, centrální nastavování vlastností jednotlivých stanic

2) Doplňující moduly a jejich funkčnost je nezbytná jak pro zajištění následného zpracování dat (kompletace dat výjezdů a pacientů, kontrola dokladů a účtování, vytváření statistických výstupů), tak z pohledu zajištění provozu ZOS samotného (evidence směn poskytující SOŘ data o výjezdových skupinách, signalizace výzev k výjezdům na výjezdových stanovištích).

3) Doplňující moduly budou provozovány kromě ústředí ZZS JMK i na jednotlivých výjezdových stanovištích rozprostřených na celém území Jihomoravského kraje, což - kromě jiného - klade technické požadavky na IT infrastrukturu organizace.

Zadavatel poskytne odpovídající konektivitu těchto výjezdových stanovišť a centrály.

V následujících odstavcích jsou popsány požadavky na úrovni jednotlivých doplňujících modulů.

1.6.3.4.1 Modul Pojišťovna

1) Modul Pojišťovna musí implementovat alespoň následující požadované funkce:

a) provádění kontroly úplnosti dokladů pacientů před jejich vyúčtováním

b) datové předávání dokladů pojišťovnám v souladu se standardy VZP

c) údržba potřebných číselníků VZP, importy číselníků

2) Následující tabulka uvádí popis základních požadovaných funkcionalit modulu Pojišťovna minimálně v rozsahu:

Popis

Kontrola dokladů

Systém musí umožnit provádění kontroly kompletnosti dokladů pacientů z pohledu možnosti jejich dalšího předávání pojišťovnám. Výsledkem kontroly je označení úspěšně zkontrolovaných dokladů pro jejich následné předávání pojišťovnám.

Pro zamezení zbytečně chybnému předávání dat umožní systém provést předběžnou kontrolu příslušnosti pacientů jednotlivým zdravotním pojišťovnám pomocí portálu VZP.

V rámci provozovaného systému je požadována možnost interní komunikace mezi kontrolním

pracovištěm a pracovišti na výjezdových stanovištích, pomocí níž budou řešeny problematické doklady (dotazy a výzvy k doplnění dat ze strany kontrolního pracoviště, následné doplnění dat a zpětné odpovědi do kontrolního pracoviště).

Popis

Účtování dokladů

Pro vlastní předávání dat pojišťovnám musí systém splňovat všechny potřebné standardy VZP. Data pacientů budou pojišťovnám předávány v dávkách dokladů, které bude systém generovat. Aplikace musí následně umožnit opravovat chybné doklady a vytvářet opravné dávky – pokud je doklad pojišťovnou odmítnut, uživatel označí doklad jako nepřijatý a po následné opravě tohoto dokladu zařadí doklad pro následné generování opravných dávek.

Aplikace automaticky musí vytvářet průvodní listy k dávkám v souladu se standardy VZP.

Pro správné účtování musí být systém vybaven aktuálními číselníky pojišťoven, pro zpětné účtování musí mít k dispozici i historické informace o stavu těchto číselníků. Kromě přímé údržby číselníků musí být systém vybaven možností importu číselníků VZP, především číselníků léků a zdravotnického

materiálu.

Kromě hromadného účtování dokladů pojišťovnám musí být systém vybaven i možností jednotlivého

účtování dokladů, a to formou vytváření podkladů pro faktury jednotlivým pacientům.

Tabulka 12: Modul Pojišťovna - požadavky na základní funkcionality

3) Katalog požadavků na modul Pojišťovna:

#	Požadavek	Podrobný popis požadavku
POJ.1	Kontrola dokladů	Možnost provedení kontroly dokladů pacientů.
POJ.2	Kontrola pomocí portálu VZP	Možnost provést předběžnou kontrolu příslušnosti pacientů jednotlivým zdravotním pojišťovnám pomocí portálu VZP.
POJ.3	Účtování dokladů zdravotním pojišťovnám	Možnost vygenerovat dávky dokladů pro zdravotní pojišťovny, a to jak původní dávky, tak opravné dávky.
POJ.4	Xxxxxx s metodikou VZP	Tvorba dávek musí být v souladu se standardy a metodikami VZP.
POJ.5	Opravné dávky	Aplikace musí umožnit opravovat chybné doklady a vytvářet opravné dávky.
POJ.6	Členění dávek	Možnost konfigurace členění dávek pro pojišťovnu takovým způsobem, aby dávky odpovídaly podle potřeby okresům, výjezdovým stanovištím, typům výjezdů nebo kombinacím uvedeného.
POJ.7	Doklady z výjezdů RV	Korektní zpracování dokladů z výjezdů randez-vous systému.
POJ.8	Více pacientů ve výjezdu	Účtování v případech, kdy při jednom výjezdu bylo ošetřeno více pacientů (rozdělení výkonů mezi pacienty).
POJ.9	Průvodní listy	Aplikace automaticky musí vytvářet průvodní listy k dávkám v souladu se standardy VZP.
POJ.10	Přegenerování dávek	Možnost přegenerování existující připravené dávky po provedení potřebných změny obsahu souvisejících číselníků.
POJ.11	Sdružování dávek	Možnost libovolného sdružování dávek do "disket" pro následné předání zdravotním pojišťovnám.
POJ.12	Automatické sdružování dávek	Možnost automatického vytváření "disket" z dávek, které ještě nebyly zařazeny na diskety, a to podle volitelných kritérií (období, druh pojištění atd.)
POJ.13	Rozpis obsahu dávek	Vytvoření statistického rozpisu obsahu diskety podle definovaných nákladových středisek.
POJ.14	Označování nepřijatých dokladů	Možnost označit doklad jako nepřijatý pojišťovnou, pokud je daný doklad pojišťovnou odmítnut a po následné opravě tohoto dokladu možnost doklad opět zařadit pro generování opravných dávek (nebo v případě potřeby pro generování původních dávek).

#	Požadavek	Podrobný popis požadavku
POJ.15	Správa číselníků pro účtování	Konfigurace ceny bodu s udržovaným historickým vývojem pro správné vykazování dokladů z určitého data.
POJ.16	Konfigurace léků a materiálu	Konfigurace ohodnocení nasmlouvaných léků a materiálu s udržovaným historickým vývojem pro správné vykazování dokladů z určitého data.
POJ.17	Konfigurace výkonů	Konfigurace ohodnocení nasmlouvaných výkonů s udržovaným historickým vývojem pro správné vykazování dokladů z určitého data.
POJ.18	Rozlišení konfigurací podle pojišťoven	Možnost výše uvedených konfigurací individuálně pro jednotlivé pojišťovny.
POJ.19	Import číselníků VZP	IS musí podporovat import číselníků VZP, především číselník léků a zdravotnického materiálu.

Tabulka 13: Modul Pojišťovna - katalog požadavků

1.6.3.4.2 Modul Kniha jízd

1) Modul Kniha jízd (dále KJ) musí implementovat alespoň následující požadované funkce:

a) automaticky vytvářet záznamy do KJ s přebíráním počtu km

b) umožnit editaci spotřeby

c) datové předávání dokladů pojišťovnám v souladu se standardy VZP

d) vytvářet potřebné sestavy

e) údržba potřebných číselníků VZP, importy číselníků

2) Následující tabulka uvádí popis základních požadovaných funkcionalit modulu Kniha jízd minimálně v rozsahu:

Popis

Záznamy KJ

Do Knihy jízd budou pořizovány záznamy o jízdách, počtu najetých km a o spotřebě. Záznamy KJ

včetně počtu najetých km budou v KJ vytvářeny automaticky. Informace o spotřebě budou doplňovány uživateli,

Potřebné tiskové sestavy

Modul Kniha jízd umožní vytváření běžných výstupních sestav - tisk knihy jízd souhrnně nebo pro

jednotlivé vozy, tiskové přehledy o výkonech odvedených jednotlivými vozy, přehledy spotřeby,

Tabulka 14: Modul Kniha jízd - požadavky na základní funkcionality

3) Katalog požadavků na modul Kniha jízd:

#	Požadavek	Podrobný popis požadavku
KJ.1	Automatické přebírání počtu km	Záznamy KJ jsou vytvářeny automaticky, počty km jsou přebírány do KJ automaticky
KJ.2	Údaje o tankování	Do KJ možnost doplnit údaje o tankování
KJ.3	Tiskové přehledy	Tisk KJ souhrnně nebo pro jednotlivé vozy, tiskové přehledy o výkonech odvedených jednotlivými vozy, přehledy spotřeby,

Tabulka 15: Modul Kniha jízd - katalog požadavků

1.6.3.4.3 Modul Skladová evidence

1) Modul Skladová evidence musí implementovat alespoň následující požadované funkce:

a) podporovat potřebné skladové operace na úrovni centrálního skladu i jednotlivých meziskladu

b) umožňovat vytváření inventurních soupisů centrálního skladu i meziskladů s dopočtem stavu ke konkrétnímu zadanému dni

2) Následující tabulka uvádí popis základních požadovaných funkcionalit modulu Skladová evidence minimálně v rozsahu:

Popis

Centrální sklad, mezisklady

V rámci ZZS JMK je provozován jeden centrální sklad léků a zdravotnického materiálu, ze kterého jsou léky a materiál distribuovány do meziskladů umístěných v rámci celého území Jihomoravského kraje, Skladová evidence musí podporovat běžné skladové pohyby na úrovni centrálního skladu (příjem, výdej, opravy) včetně sledování ceny a skladového stavu jednotlivých skladových položek.

Na úrovni jednotlivých meziskladů musí Skladová evidence umožňovat příjem zboží z centrálního skladu, a to na základě objednávek meziskladů do centrálního skladu. Součástí Skladové evidence je

tvorba těchto objednávek i jejich zpracování v centrálním skladu.

Inventurní soupisy

Součástí Skladové evidence musí být možnost tvorby inventurních soupisů centrálního skladu i meziskladů s dopočtem stavu ke konkrétnímu zadanému dni

Tabulka 16: Modul Skladová evidence - požadavky na základní funkcionality

3) Katalog požadavků na modul Skladová evidence:

#	Požadavek	Popis požadavku
SKL.1	Příjem léků do centrálního skladu	Léky a materiál je do centrálního skladu přijímán po baleních, je třeba zadat počet a cenu
SKL.2	Výdej léků z centrálního skladu	Výdej léků z centrálního skladu do meziskladů
SKL.3	Opravné položky	Možnost tvorby opravných položek v centrálním skladu i meziskladech – exspirace, odpisy, vrácení do centrálního skladu
SKL.4	Inventurní soupisy	Možnost tvorby inventurních soupisů centrálního skladu i meziskladů s dopočtem stavu ke konkrétnímu zadanému dni
SKL.5	Automatické odpisy léků a materiálu z příslušného skladu při spotřebě během zásahu	Možnost automatických odpisů léků a materiálu příslušného skladu při spotřebě během zásahu
SKL.6	Podpora tvorby objednávek z VS do centrálního skladu	Objednávky do centrálního skladu – jejich tvorba v závislosti na stavech meziskladů a následné zpracování objednávek v centrálním skladu

Tabulka 17: Modul Skladová evidence - katalog požadavků

1.6.3.4.4 Modul Plánování směn

1) Modul Plánováni směn musí implementovat alespoň následující požadované funkce:

a) podporovat základní evidenci směn pro potřebu operačního řízení a provozu výjezdových skupin

b) podporovat rozšířenou evidenci směn pro potřebu vytváření úplných výkazů mzdových nároků

2) Následující tabulka uvádí popis základních požadovaných funkcionalit modulu Plánování směn minimálně v rozsahu:

Popis

Základní evidence směn pro potřebu operačního řízení

Základní funkcionalita umožňující evidenci plánovaného obsazení výjezdových skupin pro potřebu operačního řízení.

Rozšířená evidence směn

Rozšířená evidence směn zahrnuje evidenci dalších potřebných podkladů pro potřebu vytváření úplných výkazů mzdových nároků – dovolené, nemocenské, OČR, částečné úvazky atd.

Tabulka 18: Modul Plánování směn - požadavky na základní funkcionality

3) Katalog požadavků na modul Plánování směn:

#	Požadavek	Popis požadavku
SMN.1	Základní evidence směn	Základní funkcionalita umožňující evidenci plánovaného obsazení výjezdových skupin pro potřebu operačního řízení.
SMN.2	Plánování směn na výjezdovém stanovišti	Aplikace na výjezdovém stanovišti musí umožnit plánovat posádky do směn VS přímo pracovníky výjezdového stanoviště.
SMN.3	Obsah plánu pro výjezdovou skupinu	Plán musí obsahovat všechny potřebné podklady k tomu, aby mohlo být v okamžiku nástupu do služby provedeno přihlášení výjezdové skupiny.
SMN.4	Přihlašování, odhlašování VS	Možnost přihlášení, odhlášení výjezdové skupiny, možnost změny obsazení VS a výměna vozu přímo z výjezdového stanoviště.
SMN.5	Dávkové importy směn	Umožnit importovat připravené plány směn ze souborů.
SMN.6	Podpora dlouhodobých plánů směn	Xxxxxxx dlouhodobých plánů směn pomocí konfigurovaných period směn
SMN.7	Rozšířená evidence směn	Evidence dalších potřebných podkladů pro výkazy mzdových nároků – dovolené, nemocenské, OČR, částečné úvazky atd.
SMN.8	Průběžné ukazatele	Pro každého zaměstnance sledování průběžných ukazatelů, jako zůstatek dovolené, průběžné plnění ročního harmonogramu
SMN.9	Výkaz mzdových nároků	Tisk výkazů mzdových nároků zaměstnanců pro potřebu mzdové účtárny
SMN.10	Integrace se software používaným výjezdovými skupinami	Přihlašování, odhlašování VS primo posádkami

Tabulka 19: Modul Plánování směn - katalog požadavků

1.6.3.4.5 Modul Základna

1) Modul Základna musí implementovat alespoň následující požadované funkce:

a) příjem výzev k výjezdu na výjezdovém stanovišti

b) možnost přihlášení, odhlášení a změny vlastností výjezdové skupiny přímo z výjezdového stanoviště

2) Následující tabulka uvádí popis základních požadovaných funkcionalit modulu Základna minimálně v rozsahu:

Popis

Příjem výzev k výjezdu na výjezdových stanovištích

Na výjezdovém stanovišti budou výzvy k výjezdům pro výjezdové skupiny signalizovány v aplikaci na stanici k tomu určené. Příjem výzvy k výjezdu bude aplikací zpracován následujícím způsobem:

(a) na obrazovce se objeví výzva, jejíž přijetí uživatel potvrdí z aplikace zpět dispečinku

(b) výzvu provází zvuková signalizace pro konkrétní výjezdovou skupinu (ideálně hlasová signalizace)

Výzva k výjezdu bude obsahovat: pořadové číslo výzvy, klasifikaci události, identifikaci postižených osob, identifikaci místa zásahu, identifikaci a složení posádky, případné další doplňující informace nasbírané dispečerem ZOS.

Je nezbytné, aby aplikace zamezila rušivé signalizaci výzev k výjezdům na výjezdovém stanovišti pro výjezdové skupiny pohybující se mimo výjezdové stanoviště (tyto výjezdové skupiny obdrží výzvu

k dalšímu výjezdu pouze pomocí mobilních způsobů předávání výzvy).

Tabulka 20: Modul Základna - požadavky na základní funkcionality

3) Katalog požadavků na modul Základna:

#	Požadavek	Popis požadavku
ZAK.1	Příjem výzev k výjezdu	Příjem výzev k výjezdu na výjezdovém stanovišti.
ZAK.2	Přihlašování VS ze stanoviště do služby	Přihlašování výjezdových skupin do služby, odhlašování výjezdových skupin
ZAK.3	Zvuková signalizace	Zvuková signalizace výzvy pro konkrétní výjezdovou skupinu.
ZAK.4	Zobrazení výzvy	Výzva na obrazovce výjezdového stanoviště (jejíž přijetí uživatel potvrzuje z aplikace zpět dispečinku).
ZAK.5	Tisk výzvy	Automaticky tisknout výzvu k výjezdu na připojené tiskárně.
ZAK.6	Zamezení signalizace pro VS mimo výjezdové stanoviště	Zamezení signalizace výzev k výjezdům na výjezdovém stanovišti pro výjezdové skupiny pohybující se mimo výjezdové stanoviště.
ZAK.7	Obsah výzvy	Výzva k výjezdu bude obsahovat: pořadové číslo výzvy, klasifikaci události, identifikaci postižených osob, identifikaci místa zásahu, identifikaci a složení posádky, případné další doplňující informace nasbírané dispečerem ZOS.

Tabulka 21: Modul Základna - katalog požadavků

1.6.3.5 Sledování vozidel

Sledování vozidel je specifickou funkcionalitou GIS klienta pro SOŘ. Následující tabulka uvádí popis základních požadovaných specifikací minimálně v rozsahu:

Popis

Pohled na aktuální data

a) sledování vozidel v reálném čase s možností zobrazení trajektorie (průběhu jízdy) dle nastavené časové hloubky

b) schopnost současného zobrazování všech vozidel nad mapovým podkladem v reálném čase

c) různé módy zobrazení (ukotvení pohledu, centrování na vozidlo, udržení vybraných vozidel na mapě)

d) sledování a vizualizace nepolohových informací (např. jízda s majákem, otevření dveří, napětí

Popis

palubní sítě apod.)

e) funkce pro odeslání a příjem textových zpráv do/z vozidla

Pohled na historii

a) zpětné prohlížení projeté trasy

b) schopnost slučování dat z vozidla do logických celků – jízdy (na základě běhu motoru – jen pro vozidlové jednotky)

c) možnost zpětného prohlížení projeté trasy bezprostředně po ukončení jízdy (podmínkou do 3 minut od ukončení jízdy)

d) tvorba specifických tiskových sestav

e) využití filtrů pro výběr jízd a tvorbu tiskových sestav (dle lokality, rychlosti, ujeté vzdálenosti, stavových informací)

Uživatelské oblasti

a) tvorba uživatelských oblastí s vlastním popisem uživatele, kruhových a tvaru polygonu, pro vyhledávání jízd dle vlastnosti vjezdu či opuštění oblasti

b) řazení uživatelských oblastí dle stromové struktury, slučování oblastí

c) práce s oblastmi dle přihlášeného uživatele

d) neomezený počet vytvořených uživatelských oblastí

e) systém musí umožňovat dotazy typu:

i) čas vjezdu do uživatelské oblasti

ii) čas opuštění oblasti

iii) celková doba stání v oblasti

iv) celkový počet ujetých kilometrů v oblasti

Tabulka 22: Sledování vozidel - požadavky na základní funkcionality

1.6.4 Integrace telefonie (IS-05)

V oblasti integrace telefonie je požadováno zajistit následující:

1) Obecné požadované vlastnosti systému - je požadováno zajistit maximální efektivní integraci telefonních systémů (pobočkové ústředny a IP telefonů) do IS OŘ. Cílem integrace je umožnit operátorovi ovládání systémů přímo z:

a) rozhraní aplikace pro operační řízení

b) dotykové obrazovky operátora ZOS prostřednictvím rozhraní pro ovládání všech typů komunikací včetně radiových systémů

2) Základní požadované funkce:

a) připojení každého pracoviště operátora ZOS jednou telefonní linkou v režimu multiline

b) indikace aktuálního stavu každé linky zabarvením příslušného pole na dotykové obrazovce dispečera

c) sestavení odchozího hovoru ze seznamu nebo ad hoc

d) přijetí příchozího hovoru se zobrazením telefonního čísla volajícího

e) zavěšení hovoru operátorem nebo protistranou

f) převzetí vyzvánějícího hovoru z jiné linky

g) přidržení hovoru

h) přepínání mezi aktivním a přidrženým hovorem

i) přepojení hovoru

j) třístranná konference

k) dočasně zachovat lokalizaci volajícího – viz požadavky na IS OŘ.

3) Požadované vazby na další subsystémy:

a) Subsystém operačního řízení (SOŘ)

b) Telefonní pobočková IP ústředna určená pro operační řízení ZZS JMK

1.6.5 Zálohování (IS-04)

Zálohování bude sloužit na zálohování důležitých dat ZZS. Jedná se především o následující data a jejich dobu uchování:

Data	Doba uchovávání dat
dispečerské – události, výjezdy a pacienti	10 let
lékařské dokumentace pacientů	10 let
sledování vozů – prostředků ZZS	10 let
nahrávání telefonních hovorů	15 let

Tabulka 23: Zálohování - data a doba jejich uchování

Přičemž předpokládaný objem zálohovaných dat bude záležet na nabízeném řešení. Zde uvádíme pouze několik podkladů umožňujících dodavateli odhadnout velikost dat určených k zálohování (případně archivaci).

V posledních letech eviduje ZZS JMK ročně: Událostí < 100 000

Pacientů < 100 000

Výjezdů < 100 000

125GB nahrávaných hovorů za poslední rok ve formátu MP3 2 500 000 km naježděných celkem za rok (80-100vozů)

Předpokládaný systém zálohování/archivace předpokládá minimálně následující schéma:

Jednotlivé roky, v aktuálním roce poslední tři měsíce, v aktuálním měsíci týdny a v aktuálním týdnu dny

(inc.).

Datové úložiště pro ukládání záloh dle uvedených požadavků musí splňovat následující minimální vlastnosti na HW:

a. Podpora zálohování a navrženého zálohovacího software

b. NAS funkcionalita (min. CIFS, NFS), iSCSI target (podpora VMware, Citrix and Hyper-V ready)

c. Min. 12 HDD, podpora RAID5, 6, 10, hotspare

d. Konektivita min. 2x Gigabit Ethernet (rozšiřitelnost na 10Gigabit/s) – podpora agregace portů

– load balancing (EtherChannel, LACP) a FailOver , podpora IPv6

e. Schopnost řízení UPS

f. Podpora SNMP a e-mailová notifikace chyb a varování

x. Xxxxxxxx zápisu > 80 MB/s

h. Záruka 24 měsíců

1.6.6 Jiné technologické doplnění IS (IS-15)

Modul IS pro mobilní zadávání dat v terénu (MZD)

V rámci této oblasti předmětu plnění je požadováno implementovat informační systém pro podporu zadávání dat o pacientech, získaných v rámci výjezdu k řešeným událostem včetně integrace na další subsystémy celého IS OŘ. Tento informační systém jako součást

komplexního řešení IS OŘ musí zajistit možnost jak mobilního zadávání dat lékaři a záchranáři v terénu (mobilní klient na tabletech - MZD).

Zásadním přínosem systému pro mobilní zadávání dat o pacientech je odstranění nutnosti ručního přepisování dat, nečitelnosti parere, zajištění kompletní administrativy již v rámci výjezdu, kvalita a úplnost zadávaných dat (aplikací kontrolních mechanismů).

1) Informační systém pro mobilní zadávání dat v terénu (MZD) - obecné požadované vlastnosti systému:

a) uživatelsky jednoduchá obsluha, jednotné uživatelské rozhraní

b) ergonomické zobrazení – vhodná velikost a barevné provedení uživatelského interface

c) velká rychlost odezev systému

d) omezení důsledků lidské chyby - dodržení časových posloupností a zákonitostí vyplňování pro vyloučení nepravděpodobných nebo nemožných operací

e) oddělení způsobu (rozsahu zadávaných dat) pro lékaře a pro záchranáře

f) propojení se systémem operačního řízení

g) jednotnost dat v rámci celého IS OŘ, předávání dat tak, by docházelo k maximálnímu vytěžení dat mezi systémy v rámci IS OŘ.

h) tisk parere (z důvodu dokladování a archivace musí být tento kompletní záznam vytištěn a dlouhodobě uložen, tj. nejedná se o plnohodnotnou elektronizaci celého procesu)

i) Zabezpečení systému nejen prostředky pro zabránění neoprávněného čtení a manipulaci s daty

j) Lokální ukládání dat na pevný disk mobilního zařízení (tabletu) nebo paměťové médium musí být chráněno proti neoprávněnému přístupu k datům pacienta.

2) Požadavky na základní funkcionality:

a) Převzetí a potvrzení výzvy – výzva vzniká v SOŘ zadáním dispečera a MZD musí tuto výzvu včetně základních atributů převzít a zobrazit posádce

b) Vyplnění a tisk a záznamu o výjezdu - z uživatelského pohledu musí MZD zabezpečit co nejkomfortnější podporu pro vyplnění záznamu o výjezdu na vhodném mobilním zařízení a na stacionárním PC na výjezdovém stanovišti. Výstupem je vytištěný papírový formulář a centrálně uložená data v IS OŘ pro další využití.

c) Uložení a poskytování dat o výjezdu - všechna zadaná data musí být k dispozici k pozdějšímu nahlížení (ne editaci) a k exportu do systému EKP (elektronická karta pacienta), který zajišťuje jejich další zpracování a tvorbu pokladů například dávek pro pojišťovny. Stacionární zadávání dat musí umožnit úpravu dat v rozsahu tak, aby nebylo možné rozporovat předanou a vytištěnou kartu pacienta. V systému EKP bude možné provádět další zpracování a vyhodnocování dat o výjezdech včetně exportu.

d) Hlavní vstup dat do systému je výzva převzatá z SOŘ a ruční vstup pomocí mobilních klientských stanic.

3) Katalog požadavků na mobilní zadávání dat v terénu o pacientech a výjezdech MZD:

#	Požadavek	Podrobný popis požadavku
MZD.1	Kompatibilní datový model se systémem stacionárního sběru dat - EKP	Mobilní zadávání dat musí umožňovat plnohodnotný vstup dat kompatibilních s EKP.

#	Požadavek	Podrobný popis požadavku
MZD.2	Standardizace pořízené zdravotní dokumentace	Aplikace musí informovat uživatele o validitě zadaných dat. Zda splňují nepodkročitelné minimum požadovaných informací, které odpovídají definovaným kritériím závažnosti postižení pacienta (např. NACA skóre)
MZD.3	Umožnit tisk Záznamu o výjezdu ZZS na mobilní tiskárně v terénu	Možnost tisku zadaných dat v terénu v podobě tzv. parere prostřednictvím mobilní tiskárny přímo propojené s počítačem v rámci zástavby případně s využitím bezdrátové bluetooth technologie.
MZD.4	Jako mobilní HW použít konvertibilní notebook či Tablet PC se zvýšenou odolností.	Zařízení bude vystaveno náročným podmínkám v provozu ZZS JMK. Je třeba používat zařízení s krytím minimálně IP52 a zvýšenou odolností vůči mechanickému poškození. Požadavky na zařízení jsou uvedeny v kapitole Tablet posádky (VT-02) .
MZD.5	Mobilní tisk ve vozidlech ZZS	Umožnit tisk kabelem.
MZD.6	Instalace do vozidel	Mobilní terminál a tiskárna musí být bezpečně umístěny ve vozidlech ZZS. Musí být možnost vzít mobilní terminál a využívat jej i mimo vozidlo ZZS.
MZD.7	Ergonomické uživatelské rozhraní s podporou Tablet PC funkčností	Snadné zadání informací, maximální podpora Tablet PC funkcionality v uživatelském rozhraní. UI aplikace přizpůsobené workflow výjezdové skupiny (RLP, RZP). ▪ Ovládání pomocí dotykového displeje a klávesnice ▪ Dostatečná velikost fontů ▪ Logický postup zadávání dat ▪ Grafické rozhraní musí odpovídat logickému postupu vyplňování ▪ Důraz na ergonomii zadávání ve ztížených podmínkách
MZD.8	Zabezpečená komunikace klienta se serverem	Komunikace klienta s aplikačním serverem po zabezpečeném kanálu s využitím klientských certifikátů pro autentifikaci přistupujících mobilních klientů.
MZD.9	Aplikace nezávislá na dostupnosti mobilního internetu	Aplikace musí umožňovat zadání informací v terénu nezávisle na dostupnosti připojení s centrálním systémem. V případě výpadku připojení musí být možnost dále zadat informace o výjezdu a pořídit výjezdovou kartu.
MZD.10	Příjem výzev ze systému SOŘ.	Aplikace musí obdržet nejpozději do 3 min od přijetí výzvy posádkou vybrané informace o výzvě ze systému SOŘ podmínkou je dostupný mobilní internet).
MZD.11	Příjem informací o výjezdu z mobilních terminálů do centrálního systému	V případě uzavření záznamu o výjezdu ze strany uživatele musí být centrální systém aktualizován nejpozději do 3 min. (podmínkou je dostupný mobilní internet)

#	Požadavek	Podrobný popis požadavku
MZD.12	Podpora událostního modelu založeného operátorem ZOS	Musí být možno sdílet informace např. o pacientech mezi mobilními terminály posádek ZZS v rámci jedné události.
MZD.13	Správa číselníků mobilních terminálů	Aplikace musí umožňovat za provozu synchronizaci číselníku v terénu se serverovými verzemi. Pokud je k dispozici mobilní internet, pak po změně serverové verze číselníků se musí změny promítnout nejpozději do 12 hod do všech používaných mobilních terminál (podmínkou je, že budou v online módu).
MZD.14	Automatické aktualizace	Aplikační SW mobilních terminálů musí umožňovat aktualizaci sebe sama.
MZD.15	Zobrazení informací o ošetřovaném pacientovi z interního registru pacientů ZZS	Po zadání identifikačních údajů pacienta do aplikace, může uživatel vznést dotaz na historii pacienta z interního registru ošetřených pacientů ZZS. Aplikace musí umožnit posádce zobrazení vybraných informací o minulých intervencích ZZS (předpoklad je mobilní internet).
MZD.16	Zobrazení emergentních informací o ošetřovaném pacientovi z externích EHR registrů (CZ)	Po zadání identifikačních údajů pacienta do aplikace, pokud je pacient identifikován v externím EHR registru. Tyto registry budou specifikovány uživatelem a podmínkou je smluvní dostupnost těchto registrů
MZD.17	Možnost vzdáleného smazání dat	Aplikace musí umožňovat vzdálené smazání veškerých citlivých dat. (podmínkou je dostupný mobilní internet)
MZD.18	Jednoúčelový embeded systém	Mobilní terminál společně s aplikací by měl být uzavřený jednoúčelový systém. Nejlépe uzamčený typ operačního systému.
MZD.19	Využití dat z monitorovacích zdravotnických přístrojů ve vozidlech ZZS	Posádky RLP mají k dispozici multifunkční defibrilátory. Požadavek na import dat z monitorovací techniky do aplikace a přidání těchto dat k pořízeným záznamům o pacientovi – v případě monitoru/defibrilátoru LP12 a LP15
MZD.20	Zobrazení emergentních informací o ošetřovaném pacientovi z externích EHR registrů (EU)	Po zadání identifikačních údajů pacienta - cizince (EHIC) do aplikace, pokud je pacient identifikován v externím EHR registru, musí mobilní terminál umožnit posádce zobrazit jeho emergentní dataset jako podporu rozhodování. Pokud je přístupný internet. Podmínkou je smluvní dostupnost tohoto registru.
MZD.21	Zobrazení informací o ošetřovaném pacientovi z dalších možných externích EHR registrů (CZ)	Získání dalších informací o pacientovi z nově zprovozněných registrů např. (Lékový profil - datové úložiště ÚZIS, specializované registry - diabetes, kardiovaskulární). Podmínkou je smluvní dostupnost tohoto registru.
MZD.22	Dohled a správa mobilního klientského aplikačního SW	Systém musí umožnit vzdálený přístup do log souborů jednotlivých tabletů a tyto logy vzdáleně importovat na server pro další vyhodnocení.

#	Požadavek	Podrobný popis požadavku
MZD.23	Předání informací o ošetřovaném pacientovi do cílového zdravotnického zařízení	Systém umožní předání vybraných informací o aktuálně ošetřovaném pacientovi do cílového zdravotnického zařízení.
MZD.24	Požadavky na HW a celkové řešení	Snadná obsluha, bezpečná montáž a ergonomie, veškeré komponenty musí být vyjímatelné pro práci mimo vůz. Provoz - eliminace „padání systému“ při hlášení se z jednoho převaděče na druhý
MZD.25	Obecné požadavky na SW	velké zobrazení, intuitivní funkce, možnost vstupu kdekoliv v průběhu zapisování, rychlé zkopírování známých dat z jiných databází (např. SOŘ) automaticky, možnost porovnání s databází (zda již stejného pacienta neobsahuje), fulltextové vyhledávání.
MZD.26	Technologie pro autentizace	Jméno a heslo
MZD.27	Zabezpečení provozní správy a konfiguračního řízení	Aktualizace SW jednotně a pravidelně na všech pracovištích, zajištění průkazného systému aktualizace a údržby SW

Tabulka 24: Mobilní zadávání dat (MZD) - katalog požadavků

1.7.1 Realizace předmětu plnění ‌

1.7 Požadavky na služby

Součástí předmětu plnění je zajištění služeb souvisejících s realizací předmětu plnění minimálně v následujícím rozsahu:

1) Prostudování projektové dokumentace nově budovaného objektu ZZS v aktuální verzi a součinnost s ostatními dodavateli. Projektová dokumentace bude poskytnuta Uchazeči do 10 pracovních dní po podpisu smlouvy o dílo.

2) Zadavatel požaduje před zahájením implementačních prací zpracování Prováděcí dokumentace, která bude zahrnovat informace pro všechny aktivity potřebné pro řádné zajištění implementace předmětu plnění. Prováděcí dokumentace musí být před zahájením prací schválena zadavatelem. Prováděcí dokumentace musí zohlednit podmínky stávajícího stavu, požadavky cílového stavu a musí obsahovat minimálně tyto části:

a) Předimplementační analýza – zjištění týkající se prostředí zadavatele, bude obsahovat alespoň následující:

i) Seznam technologií

ii) Identifikace zdrojů dat

iii) Seznam uživatelů včetně jejich kategorizace

iv) Výstupy z analýzy procesů

v) Evaluace bezpečnosti systému a rizikových faktorů

vi) Detailní specifikace požadavků

vii) Výstupy z analýzy okolí – sběr a analýza informací týkajících se subjektů, které budou do dodávky vstupovat nebo se jí účastnit, nezbytné součinnosti třetích stran

b) Detailní popis cílového stavu včetně funkcionalit jednotlivých částí systému. Popis bude obsahovat alespoň:

i) Rozpracování návrhu řešení z nabídky Uchazeče dle informací z předimplementační analýzy

ii) Specifikace rozhraní pro integraci na IS a technologie třetích stran

c) Způsob zajištění potřebných dodávek včetně zajištění technické podpory

d) Způsob zajištění projektového řízení na straně uchazeče pro realizaci předmětu plnění

e) Detailní návrh a popis postupu implementace předmětu plnění

f) Detailní popis zajištění bezpečnosti informací

g) Detailní harmonogram projektu včetně uvedení kritických milníků. Kritické milníky jsou termíny dosažení určitých fází projektu, které jsou pro naplnění cílů projektu klíčové. Kritické milníky budou obsahovat minimálně tyto aktivity s uvedením konkrétních termínů, uchazeč vhodným způsobem rozšíří kritické milníky o další aktivity, které mohou být pro projekt klíčové. Jedná se o tyto aktivity:

i) Zahájení projektu

ii) Provedení předimplementační analýzy

iii) Předání prováděcí dokumentace

iv) Zahájení realizace předmětu plnění

v) Školení

vi) Zahájení zkušebního provozu

vii) Akceptační testy

viii) Zahájení plného provozu

h) Detailní popis navrhovaných školení

i) Detailní popis údržby systémů

j) Obsah systémové a provozní dokumentace

3) Zajištění projektového vedení realizace předmětu plnění ze strany Uchazeče a jeho případných subdodavatelů.

4) Vývoj, implementace a nastavení informačních a komunikačních technologií odpovídající schválenému návrhu řešení uvedenému v Prováděcí dokumentaci a příprava pro ověření ze strany Zadavatele, alespoň v následujícím rozsahu:

a) Vývoj na straně Uchazeče – vývoj jednotlivých subsystémů, úpravy existujících produktů, jejich parametrizace a nastavení, vývoj a ověřování integračních rozhraní, součinnost se třetími stranami v souvisejících oblastech.

b) Instalace do prostředí Zadavatele v testovacím režimu.

c) Interní ověření na straně Uchazeče a příprava podkladů pro ověření na straně Zadavatele (dokumentace, organizace testování a další).

d) Příprava a naplnění základních dat – z integračních úloh, číselníky, uživatelé a další.

Provedením těchto činností bude zajištěna připravenost IS ZZS pro ověření ze strany Zadavatele.

5) Dodávka předmětu plnění do lokalit v rámci Jihomoravského kraje určené Zadavatelem při podpisu smlouvy. Součástí dodávky musí být instalace, upgrade a sestavení předmětu zakázky včetně:

a) Instalace, upgrade a zahoření HW na místě včetně propojení a nastavení hlavních serverů a diskového pole

b) Instalace a nastavení HW a SW budou provedeny kvalifikovanými osobami pro dané typy zařízení

c) Nastavení virtuálních strojů, migrace dat a aplikací.

6) Zajištění instalace všech součástí dodávky v určených lokalitách a prostorách Zadavatele na území Jihomoravského kraje.

7) Zajištění instalace a připojení k zařízením a technickým prostředkům zajištěným Zadavatelem.

8) Převedení systémů do zkušebního provozu a plná podpora uživatelů v rámci zkušebního provozu v délce minimálně 4 týdnů včetně technické podpory. V této etapě budou realizována požadovaná školení.

9) Zpracování systémové a provozní dokumentace - součástí předmětu plnění je zajištění systémové a provozní dokumentace související s realizací předmětu plnění minimálně v následujícím rozsahu:

Název

Popis

Uživatelská dokumentace

Xxxx popisovat konkrétní funkčnost z pohledu uživatele tak, aby byl uživatel schopen práce s informačním systémem a pochopil význam jednotlivých subsystémů a vazeb mezi nimi. V uživatelské příručce bude popisován způsob práce s jednotlivými subsystémy, vazby mezi nimi včetně popisu součástí subsystémů. K usnadnění práce bude sloužit popis jednotlivých obrazovek, ovládacích prvků na obrazovkách a jejich

významů, který bude uveden v rámci uživatelské dokumentace.

Systémová

dokumentace

Obsahuje popis informačního systému (rozhraní a služby) včetně popisu správy

informačního systému, definování uživatelů, jejich oprávnění a povinností.

Bezpečnostní

dokumentace

Účelem bezpečnostní dokumentace je definovat závazná pravidla pro zajištění

informační bezpečnosti včetně stanovení bezpečnostních opatření.

Plány zálohování a

obnovy

Plán a způsob provádění zálohy a případného způsobu obnovy. Dokument bude

vytvářen v součinnosti se Zadavatelem.

Projektová

dokumentace

Smluvní dokumentace, harmonogram realizace projektu, analýzy a prováděcí projekty,

zápisy z jednání, protokoly (předávací, akceptační)

Tabulka 25: Systémová a provozní dokumentace - požadavky na zpracování

Dokumentace bude v souladu se zákonem č. 365/2000 Sb. o informačních systémech veřejné správy a vyhláška 529/2006, Sb.

Dokumenty budou zpracovávány v následujících programech elektronicky a uloženy v následujících formátech:

• MS Office 2007 (MS Word 2007, MS Excel 2007, MS PowerPoint 2007)

• MS Project 2007

• WinZip (formát .zip)

• Portable Document Format (formát .pdf).

Preferovaná forma předávaných dokumentů, které nebudou vyžadovat podpisy konkrétních osob je

elektronicky a to na elektronických nosičích (CD, DVD, flash disk, atp.). K předávání a k archivaci souborů se používají média s možností pouze zápisu, nikoliv přepisovatelná.

Veškerá dokumentace bude podléhat schvalování (akceptaci) při převzetí ze strany Zadavatele.

Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích v elektronické formě ve standartních formátech (např. MS Office, Open Office, PDF) používaných zadavatelem na datovém nosiči a 1x kopii v papírové formě.

10) Provedení akceptačních testů. Uchazeč je povinen kompletně připravit podklady pro akceptaci dodaného řešení. Součástí akceptace bude akceptační protokol a kompletní předávací dokumentace.

11) Uvedení systému do produktivního provozu, zajištění potřebných nastavení a přístupů pro všechny pracovníky Zadavatele, minimalizace dopadů na provoz Zadavatele při přechodu a zvýšená podpora bezprostředně po přechodu do produktivního provozu.

12) Xxxxxxx dle svého uvážení doplní v nabídce další služby, které jsou dle jeho názoru nezbytné pro úspěšnou realizaci zakázky.

13) Veškeré náklady na zajištění služeb souvisejících s realizací předmětu plnění musí být zahrnuty v ceně odpovídající části předmětu díla.

1.7.2 Školení

1) Uchazeč zajistí školení pracovníků Zadavatele na všechny typy dodaných zařízení a problematiku jejich provozu. Školení musí zahrnovat alespoň následující témata v dostatečném detailu pro porozumění činnosti zařízení a způsobu provozu:

a) Základní produktové seznámení s jednotlivými dílčími technologickými celky.

b) Zaškolení do celkového schématu součinnosti jednotlivých zařízení a jejich návaznosti.

c) Zaškolení na použitá nastavení zařízení, detailnější rozbor použitých konfigurací.

d) Základní kroky správy, diagnostiky a elementární postupy pro řešení problémů.

2) Školení zajistí seznámení pracovníků Zadavatele se všemi podstatnými částmi díla v rozsahu potřebném pro provoz, údržbu a identifikaci nestandartních stavů systému a jejich příčin. Pracovníků bude vystaveno osvědčení o školení.

3) Školení musí zahrnovat alespoň následující témata v dostatečném detailu pro porozumění činnosti zařízení a způsobu provozu a v následujícím minimálním rozsahu:

Školení	Účastníci	Min. rozsah	Poznámka
Školení správců	3 správci	1 den	Správa systému a datového skladu.
Operační řízení	10 klíčových uživatelů	4x 1 den	Školení zaměřené na činnosti operačního řízení – operátoři. Požadovaný rozsah – 4x jednodenní školení.
Operační řízení	10 klíčových uživatelů	4x 1 den	Školení zaměřené na činnost se speciálním oprávněním vedoucího dispečera nebo supervizora. Požadovaný rozsah – 1x jednodenní školení.
Ostatní agendy	5 uživatelů	Individuálně	Předmětem je proškolení uživatelů ostatních částí informačního systému mimo OŘ.
Obsluha telefonie a radiofonie na dispečinku	10 klíčových uživatelů	1 den	Bude provedeno v rámci školení Operačního řízení.

Školení

Účastníci

Min. rozsah

Poznámka

Práce s vozidlovými

terminály

6 klíčových

uživatelů

1 den

Zaškolení školitelů obsluhy vozidlových

terminálů

Tabulka 26: Požadavky na školení

4) Školení bude probíhat v prostorách Zadavatele s využitím vybavení dodaného v rámci této veřejné zakázky, případně zajištěné ze strany Zadavatele.

5) Konkrétní termíny školení určí Zadavatel dle postupu v rámci realizace projektu a dostupnosti školených osob.

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

1.8 Záruky

1) Zadavatel požaduje záruku na veškeré dodané technologie včetně nezbytných provozních a servisních služeb v délce trvání minimálně:

a) 60 měsíců na informační systém (y), aplikace a služby spojené s realizací projektu

b) 24 měsíců – u HW, systémového SW a technických zařízení

c) 12 měsíců na spotřební materiál, případně drobné vybavení podléhající rychlému opotřebení (např. náhlavní soupravy). Případný spotřební materiál musí být explicitně označen v nabídce a smlouvě a musí být prokázáno, že splňuje tento charakter.

V případě konkrétní technologie, případně části VZ je možné požadovat odlišnou záruku s tím, že uvedení u konkrétní technologie má přednost před těmito obecnými ustanoveními.

Záruka začíná běžet od okamžiku předání do ostrého provozu. Veškeré opravy po dobu záruky budou bez dalších nákladů pro provozovatele. Veškeré komponenty, náhradní díly a práce budou poskytnuty bezplatně v rámci záruky. Uchazeč ve své nabídce výslovně uvede všechny podmínky záruk.

2) Po dobu záruky na části Díla musí dodavatel nebo výrobce všech zařízení garantovat běžnou dostupnost náhradních komponentů a dostupnost servisu.

3) Uchazeč prokáže způsob zajištění shody dodávaných systémů s platnou legislativou.

4) Uchazeč uvede provozní a servisní služby požadovaného předmětu plnění veřejné zakázky včetně parametrů, které budou předmětem dodávek v rámci záruky systému a v rámci poskytování servisních služeb.

1.8.1 Servisní podmínky po dobu udržitelnosti

V této kapitole jsou detailně popsány požadavky a parametry servisních služeb požadované poskytovat ze strany poskytovatele servisních služeb min. po dobu udržitelnosti projektu.

Pro potřeby dalšího textu budou používány následující pojmy:

Pojem

Význam

Incident

(požadavek)

Indikovaný problém technologie, případně části IS, který není v souladu s dokumentovaným

stavem akceptovaného řešení. Kategorizace incidentů je uvedena dále v textu.

Doba

nahlášení

Doba nahlášení incidentu prostřednictvím smluvního kanálu (viz podmínky dle smlouvy –

hotline, email, kontaktní telefon).

Reakční doba

(Reakce)

Doba potvrzení přijetí incidentu poskytovatelem služby na email Objednatele a potvrzení zahájení incidentu řešení Poskytovatelem.

Pojem	Význam
Doba vyřešení (Vyřešení)	Doba vyřešení incidentu a předání Objednateli k ověření vyřešení. Doba potřebná na ověření vyřešení ze strany Objedantele není započítávána do Doby vyřešení. Vyřešením je chápáno i snížení úrovně incidentu v daném čase a tím prodloužení doby pro řešení v souladu s nižší úrovní incidentu.
SLA	Konkrétní smluvní parametry pro poskytování služeb v daných kategoriích servisních služeb.
NBD	Následující pracovní den od doby nahlášení incidentu.

Tabulka 27: Pojmy

1.8.1.1 Kategorizace incidentů

V následující tabulce jsou uvedeny základní kategorie incidentů, které jsou následně využity pro potřeby stanovení kategorií servisních služeb:

Kategorie	Popis
A	Situace, kdy IS nebo část IS není zcela funkční, neumožňuje práci uživatelů se systémem a nelze používat pro podporu procesů ZZS JMK. Vztahuje se na případy, kdy je systém zcela nefunkční z důvodů na straně IS nebo jeho části, na niž je poskytovatel povinen poskytovat servisní služby.
B	Situace, kdy IS nebo část IS je částečně funkční, umožňuje částečné poskytování služeb, po přechodnou dobu se sníženým komfortem uživatelů, případně provizorním způsobem z důvodů na straně IS nebo jeho části, na niž je poskytovatel povinen poskytovat servisní služby.
C	Nedostatky a vady drobného rozsahu, které nebrání užívání IS nebo jeho části, nicméně nejsou v souladu s předaným a dokumentovaným stavem IS nebo jeho části.
REQ	Požadavek na služby, které nejsou chápány jako vada IS nebo jeho části.

Tabulka 28: Kategorie incidentů

1.8.1.2 Parametry záruky

V následující tabulce jsou definovány základní parametry záruky:

Kategorie	A		B		C
Kategorie	Reakce	Vyřešení	Reakce	Vyřešení	Reakce	Vyřešení
Záruka	3 prac. dny	10 prac. dnů	10 prac. dnů	30 prac. dnů	15 prac. dnů	Po dohodě

Tabulka 29: Parametry servisních služeb

Pro kategorii REQ nejsou stanovena SLA, konkrétní lhůty jsou předmětem dohody mezi smluvními stranami.

1.8.1.3 Doplňující požadavky na záruční služby

Zadavatel má následující doplňující požadavky na záruční služby:

• Poskytovatel služeb zajistí jednotný systém hotline

o s elektronickým přístupem přes síť internet

o s kontaktním telefonním číslem

o poskytující informace o změnách v incidentech/požadavcích Objednateli emailem V rámci přípravy nabídky Uchazeč poskytne popis způsobu poskytování služeb záruky.

2 Doplňující informace k zadávacímu řízení

Zadavatel zajistí prohlídku těchto míst plnění:

1) Zdravotnické operační středisko (budova, technologické zázemí, dispečerský sál) na adrese: ZZS JMK, Kamenice 798/1d, 625 00 Brno.

Prohlídka bude uskutečněna v termínu 21.5.2013. Sraz účastníků v 9:00 hod v budově operačního střediska.

2) Výjezdová stanoviště na území Jihomoravského kraje (seznam uveden v kapitole Popis stávajícího stavu).

Prohlídka bude uskutečněna v termínu 21.5.2013 Sraz účastníků v 15:00 hod před budovou ZZS JMK, nám. 28. října 23, 602 00 Brno.

3) Sídlo Policie ČR Krajského ředitelství Jihomoravského kraje - instalace části technologie pro zajištění integrace radiového systému Pegas.

Prohlídka bude uskutečněna v termínu 21.5.2013. Sraz účastníků v 13:00 hod v budově Policie ČR Krajského ředitelství Jihomoravského kraje, Kounicova 24, 611 32 Brno.

4) Vozidla ZZS JMK – zajištění prohlídek typových vozidel. ZZS JMK zajistí přistavení vozidel k objektu ZOS ZZS JMK tak, aby Uchazeč získal informace o konkrétních vozidlech (stávající zástavby, zapojení, rozměry vozidel,...) dle jednotlivých typů vozidel.

Prohlídka bude uskutečněna v termínu 21.5.2013. Sraz účastníků v 10:30 hod v budově ZZS JMK, Kamenice 798/1d, 625 00 Brno.

3 Seznam zkratek a pojmů

Zkratka/pojem	Význam
ACL	Způsob definice přístupových práv (access control lists)
API	Rozhraní informačního systému nebo technologie používané pro integrace (Application Programming Interface)
APN	Access Point Name
CPU	Procesor (Central Processing Unit)
CSV	Formát souboru pro výměnu dat s oddělovačem čárkou (Comma-separated values)
EKP	Elektronická karta pacienta
ETSI	Standardizační autorita pro oblast telekomunikací (European Telecommunications Standards Institute)
gif	Formát obrázků (Graphics Interchange Format)
GIS	Geografický informační systém
GPRS	Komunikační protokol pro mobilní zařízení/telefony (General Packet Radio Service).
GPS	Systém určování polohy (Global Positioning Systém), často označuje systém pro sledování vozidel.
GSM	Globální Systém pro Mobilní komunikaci
HDD	Pevný disk v počítači (Hard Disk Drive)
HW	Hardware
HZS ČR	Hasičský záchranný sbor České republiky
ICMP	Internet Control Message Protocol
ICT	Informační a komunikační technologie
IOP	Integrovaný operační program
IS	Informační systém
ISDN	Integrated Services Digital Network (Digitální síť integrovaných služeb)
IZS	Integrovaný záchranný systém
JMK	Jihomoravský kraj
jpg	Formát obrázku
KSP	Krajský standardizovaný projekt
KÚ, KrÚ	Krajský úřad
LAN	Local Area Network (lokální síť)
LCD	Liquid crystal display, druh displeje u PC
LCT	Line connected terminal (linkový terminál pro zajištění komunikace pomocí radiostanic)
LZS	Letecká záchranná služba
MATRA/Pegas	Radiokomunikační systém složek IZS
MP	Městská policie
MU	Mimořádná událost
MZD	Mobilní zadávání dat
NIS IZS	Národní informační systém integrovaného záchranného systému
NSPTV	Národní systém příjmu tísňového volání
OŘ	Operační řízení
OS	Operační středisko
PBX OŘ	Pobočková ústředna sloužící pro operační řízení
PCM	Pulse-code modulation, technologie v rámci komunikační infrastruktury
PČR	Policie České republiky
PDF	Portable Document Format, formát dokumentu

Zkratka/pojem	Význam
PNP	Přednemocniční neodkladná péče
RAID	Způsob ukládání dat na diskových polích (Redundant array of inexpensive disks)
RCT	Radio connected terminal (vysílačka)
RLP	Rychlá lékařská pomoc
RV	Rendez-vous – způsob řízení výjezdů mezi s využitím lékaře (RLP) i záchranářů (RZP)
RZS	Rychlá zdravotnická pomoc
SaP	Síly a prostředky
Shapefile	Mapový formát
SIM karta	Subscriber identity module, karta pro zajištění mobilní komunikace v zařízení
SNMP	Simple Network Management Protocol
SOŘ	Systém pro operační řízení
SPZ	Státní poznávací značka
SW	Software
TCTV	Telefonní centrum tísňového volání
RUIAN	Registr územní identifikace, adres a nemovitostí
UPS	Záložní zdroj elektrické energie pro případ výpadků dodávek el. Energie (Uninterruptible Power Supply/Source)
VLAN	Virtuální lokální síť
VS	Výjezdová skupina
WAN/VPN	Počítačová síť
Wi-Fi	Bezdrátová komunikace v počítačových sítích – wireless fidelity
WMI	Windows Management Instrumentation
XLS	Formát souboru MS Excel
XML	Standard pro popis a výměnu dat (Extensible Markup Language)
ZOS	Zdravotnické operační středisko
ZZS	Zdravotnická záchranná služba
ZZS JMK	Zdravotnická záchranná služba Jihomoravského kraje

Document Metadata

Table of Contents

Příloha č. 1a smlouvy o dílo - Technická specifikace předmětu plnění

Document Metadata

Příloha č. 1a smlouvy o dílo - Technická specifikace předmětu plnění

Tabulka 1: Základní části předmětu plnění

Tabulka 2: Požadavky na dostupnost a spolehlivost

Pracoviště musí splňovat tyto vlastnosti:

Volné vybavení stolů:

3) Rozvod napájení v rozvaděčích (PDU)

4) Kabelové propoje

Tabulka 3: Vozidlové jednotky - základní požadované funkcionality

Tabulka 4: Vozidlové jednotky (periférie) - základní požadované funkcionality

Tabulka 5: Vozidlové jednotky (komunikace) - základní požadované funkcionality

Tabulka 6: Požadavky na diskové úložiště

Tabulka 7: Subsystém pro operační řízení (SOŘ) - popis základních požadovaných funkcionalit

Tabulka 8: Subsystém operačního řízení (SOŘ) - katalog požadavků

Tabulka 9: Subsystém Elektronická karta pacienta (EKP) – katalog požadavků

Tabulka 10: GIS klient - požadavky na základní funkcionality

Tabulka 11: GIS klient – katalog požadavků

Tabulka 12: Modul Pojišťovna - požadavky na základní funkcionality

Tabulka 13: Modul Pojišťovna - katalog požadavků

Tabulka 14: Modul Kniha jízd - požadavky na základní funkcionality

Tabulka 15: Modul Kniha jízd - katalog požadavků

Tabulka 16: Modul Skladová evidence - požadavky na základní funkcionality

Tabulka 17: Modul Skladová evidence - katalog požadavků

Tabulka 18: Modul Plánování směn - požadavky na základní funkcionality

Tabulka 19: Modul Plánování směn - katalog požadavků

Tabulka 20: Modul Základna - požadavky na základní funkcionality

Tabulka 21: Modul Základna - katalog požadavků

Tabulka 22: Sledování vozidel - požadavky na základní funkcionality

Tabulka 23: Zálohování - data a doba jejich uchování

Modul IS pro mobilní zadávání dat v terénu (MZD)

Tabulka 24: Mobilní zadávání dat (MZD) - katalog požadavků

Tabulka 25: Systémová a provozní dokumentace - požadavky na zpracování

Tabulka 26: Požadavky na školení

Tabulka 27: Pojmy

Tabulka 28: Kategorie incidentů

Tabulka 29: Parametry servisních služeb

Tabulka 30: Seznam zkratek a pojmů

Document Metadata