říloha č. 1a Smlouvy o dílo: Technická specifikace Díla – Technická specifikace předmětu plnění



P



říloha č. 1a Smlouvy o dílo: Technická specifikace Díla – Technická specifikace předmětu plnění

Obsah

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

1 Předmět plnění veřejné zakázky 3

2 Stávající stav informační podpory činnosti ZZS PK 4

2.1 Oblast informačního systému pro operační řízení 4

2.1.1 Přehled použitých technologií a produktů 4

2.1.2 Fyzická architektura subsystému ZOS 5

2.2 Oblast výkaznictví (pojišťovna) 6

2.3 Oblast mobilního zadávání dat 6

2.3.1 IS pro mobilní zadávání dat v terénu 7

2.4 Oblast „knihy jízd“ 7

2.5 Oblast geografického informačního sytému (GIS klient) 8

2.6 Oblast vybavení vozidel 10

2.7 Oblast telefonie 10

2.8 Oblast nahrávání 10

2.9 Oblast integrace telefonie 11

2.10 Oblast integrace radiové sítě PEGAS 12

2.10.1 Základní funkce pro dispečera ZOS 12

2.11 HW vybavení 13

2.12 Místo plnění 13

3 Popis cílového (požadovaného) stavu a specifikace předmětu plnění 14

3.1 Integrace sítě PEGAS (DR-01) 15

3.2 Zálohování (IS-04) 16

3.2.1 Replikace IS pro OŘ s možností přepnutí na záložní datové centrum. 16

3.2.2 HW pro replikaci IS pro OŘ 17

3.3 Jiné specifické úpravy IS pro OŘ (IS-14) 19

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

3.5 Požadavky na služby 21

3.5.1 Realizace předmětu plnění 21

3.5.2 Školení 23

4 Záruky a servisní podmínky po dobu udržitelnosti 25

4.1 Záruky 25

4.2 Servisní podmínky po dobu udržitelnosti 25

4.2.1 Kategorizace incidentů 26

4.2.2 Kategorizace servisních služeb 26

4.2.3 Úroveň služeb pro jednotlivé dílčí části IS OŘ 27

4.3 Doplňující požadavky na záruční a servisní služby 27

5 Seznam zkratek a pojmů 29

Konec dokumentu 31





1Předmět plnění veřejné zakázky


Cílem veřejné zakázky je rozvoj a doplnění informační podpory procesů Zdravotnického operačního střediska (dále jen KZOS) Zdravotnické záchranné služby Plzeňského kraje (dále jen ZZS PK), ale i dalších organizačních útvarů, které bezprostředně navazují na činnost KZOS.

Předmětem plnění je dodávka a implementace informačních systémů a technologií pro operačního řízení (dále jen IS OŘ) včetně služeb minimálně v tomto rozsahu:


Ozn.

Položka

Radiová síť PEGAS

DR-01

Integrace sítě PEGAS

Informační systémy

IS-04

Zálohování

IS-14

Jiné specifické úpravy IS pro OŘ

IS-15

Jiné technologické doplnění IS

Tabulka 1: Předmět plnění


Detailní popis uvedených dílčích částí tj. jejich stávajícího stavu a požadovaného cílového stavu je uveden dále v tomto dokumentu.

Realizace předmětu plnění musí být uskutečněna nejpozději do 3 měsíců od podpisu smlouvy nebo nejpozději do 15. 11. 2015.

2Stávající stav informační podpory činnosti ZZS PK


Detailní popis stávajících informačních systémů a technologií implementovaných v rámci 1. etapy Krajského standardizovaného projektu Zdravotnické záchranné služby Plzeňského kraje je uveden v příloze č. 9 Zadávací dokumentace – Technické řešení.


2.1Oblast informačního systému pro operační řízení


Jádrem IS pro OŘ jsou moduly informačního systému S.O.S., což je informační systém operačního střediska provozovaný společností PER4MANCE v záchranných službách. K tomuto jádru jsou napojeny spolupracující moduly dalších subsystémů, které dohromady v komplexním řešení uspokojují požadavky kladené na řešení IS ZOS ZZS PK.

Informační systém S.O.S. je postaven na databázové architektuře klient-server, klientem je aplikace vytvořená v prostředí Oracle Developer (Forms & Reports), na straně serveru je využíván databázový systém Oracle.

V IS pro OŘ jsou využity:

    • objektový model aplikace – systém S.O.S. důsledně odlišuje entity Událost, Výjezd a Pacient a umožňuje práci s relacemi mezi těmito entitami v korespondenci s realitou řešených událostí. Pro IS pro OŘ v ZZS PK je uživatelské GUI zpracováno tak, aby se tyto vazby mezi uvedenými entitami prezentovaly dispečerům maximálně přehledným způsobem

    • integrace s GIS – modul Dispečer systému S.O.S. je plně integrován se systémy GIS. V rámci implementace pro potřebu ZZS PK je integraci s konkrétním produktem (GIS od firmy RADIUM).

    • Integrace s vozidlovými jednotkami - modul Dispečer systému S.O.S. je již provozován v integraci se systémy, které jsou obdobou CarPC. V rámci implementace pro potřebu ZZS PK je integraci s konkrétním produktem (systémem pro sledování vozidel firmy RADIUM).

2.1.1Přehled použitých technologií a produktů


Architektura pro provoz aplikace

Databázová architektura a prostředí:

  • databázový systém Oracle na serveru

  • Oracle Forms & Reports na klientech

Využití webových služeb

Pro integraci s dalšími systémy a technologiemi zákazníka je využita především datová výměna uskutečňovaná pomocí webových služeb. Na straně subsystému ZOS je komunikace webovými službami zajištěna pomocí těchto prostředků:

    • klientský přístup k webovým službám třetích stran je zajištěn přímým voláním webových služeb z databázového serveru IS pro OŘ (s využitím možností poskytovaných databázovým systémem)

    • poskytování webových služeb IS pro OŘ je realizováno prostřednictvím produktu Tomcat, který je provozován na databázovém serveru subsystému ZOS a je zprostředkovávat výměnu dat s databází

Zajištění radiové komunikace

Pro zajištění radiové komunikace je použito řešení pro integraci sítě PEGAS od firmy KOMCENTRA, mimo radiová spojení umožňuje i rozesílání SMS zpráv určeným posádkám VS a osobám. Se systémem IS pro OŘ je řešení integrace sítě PEGAS schopné komunikovat prostřednictvím sdílení interface tabulek v databázi IS pro OŘ.

Zajištění komunikace s TCTV 112

Datová komunikace s TCTV 112 je realizována prostřednictvím produktu „Lehký klient TCTV 112“. Datová výměna mezi IS pro OŘ a produktem „Lehký klient TCTV 112“ probíhá prostřednictvím vyhrazených interface tabulek databáze IS pro OŘ.

2.1.2Fyzická architektura subsystému ZOS

Na následujícím obrázku je uvedena fyzická architektura řešení.

Obrázek 1: Fyzická architektura IS pro OŘ

Ve výše uvedeném schematickém obrázku je znázorněna fyzická architektura IS pro OŘ, zde je vysvětlení jednotlivých vazeb:

  • Server systému IS pro OŘ slouží současně jako databázový server a aplikační server

  • Komunikační server pro rádiovou komunikaci s posádkami VS a jinými subjekty je osazen řešením od firmy KOMCENTRA, přes které lze ovládat i hlasová pojítka přímo z IS pro OŘ.

  • aplikační server záznamového systému ReDat odesílá do IS pro OŘ data eventů hovorů (HW aplikačního serveru ReDat je současně využit i pro provoz SW „Lehký klient TCTV 112“, kterým je zajištěna komunikace s TCTV 112

  • komunikace s aplikačními servery ZZS PK je nutná pro zajištění integrace IS pro OŘ se systémem sledování vozidel

  • interní aplikační servery ZZS PK slouží pro komunikaci s VS – server pro distribuci zpráv do vozidlových jednotek

  • Server EKP + MZD odpovídá za komunikaci s klienty EKP /MZD (statická PC nebo tablety ve vozidlových jednotkách) a zajišťuje předávání dat mezi serverem ZOS a koncovými uživateli modulů MZD a EKP

  • externí aplikační servery, se kterými server IS pro OŘ komunikuje, jsou aplikační servery tísňové linky 112 TCTV a server pro aktualizace registru RÚIAN

2.2Oblast výkaznictví (pojišťovna)

Modul Pojišťovna poskytuje následující funkce:

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

Modul Pojišťovna provádí kontrolu úplnosti dokladů jednak v průběhu importu dat uzavřeného výjezdu z EKP tj. při tvorbě účetního dokladu a dále pak při jakékoli editaci dat dokladu. Kontrolovány jsou položky, z kterých jsou tvořeny předávané doklady dle Xxxxxxxx pro pořizování a předávání dokladů VZP ČR. Dále je na základě čísla pojištěnce kontrolována pojišťovna, u které je pacient registrován. Doklady, kde byly zjištěny nedostatky v povinných položkách, případně byl zjištěn nesoulad v nahlášené a registrované pojišťovně, jsou označeny stavem „Neúčtovatelný – neúplná data“. Takové doklady není možné hromadně zaúčtovat a jsou určeny pro následnou revizi ze strany zaměstnanců oddělení zdravotních pojišťoven.

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

Doklady generované v rámci modulu Pojišťovna jsou plně v souladu s aktuální Metodikou pro pořizování a předávání dokladů VZP ČR. Elektronická reprezentace jednotlivých dokladů je v souladu s Datovým rozhraním VZP ČR.

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

Modul Pojišťovna disponuje administrativním rozhraním, v rámci kterého je možné konfigurovat jednotlivé číselníky. V rámci tohoto rozhraní je i implementována možnost importu číselníků VZP v elektronické podobě, ve které jsou distribuovány.

2.3Oblast mobilního zadávání dat

V současné době je na ZZS PK provozována informační podpora zadávání dat o výjezdech a pacientech v terénu v rámci aplikace v tabletu posádky výjezdové skupiny.

Pro Mobilní sběr dat bylo zakoupeno a je využíváno 40 ks tabletů Panasonic FZ-G1 10“, který je předurčen pro práci v náročném prostředí. Svými vlastnostmi splňuje vojenský standard MIL-STD-810G, který definuje širokou škálu odolností pro: vystavení vysokým a nízkým teplotám a teplotním šokům, dešti, vlhkosti, plísni, solné mlze, rzi, vystavení písčitému a prašnému prostředí, rázům a vibracím. Výdrž vlastní baterie tabletu je až 7 hod, v závislosti na zatížení.

Pro zajištění tiskových úloh v rámci mobilního sběru dat je ZZS PK vybavena 40 ks tiskáren HP Officejet 100. Jedná se je kompaktní a důmyslně navrženou tiskárnu s plným přizpůsobením pro práci v terénu. Tiskárna je vybavena Xx-Xxx baterií s výdrží až 3 hodiny.

55 vozidel ZZS PK je vybaveno příslušnou zástavbou, kabeláží a konektory - pro provoz mobilních zařízení (tablet a tiskárna) k zajištění Mobilního zadávání dat posádkami výjezdových skupin.

2.3.1IS pro mobilní zadávání dat v terénu

Na ZZS PK je využit 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Ř zajišťuje možnost mobilní zadávání dat lékaři a záchranáři v terénu.

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ů).

Obecné požadované vlastnosti systému:

    1. 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. oddělení způsobu (rozsahu zadávaných dat) pro lékaře a pro záchranáře

    3. propojení se systémem operačního řízení

    4. jednotnost dat v rámci celého IS OŘ, předávání dat

    5. 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)

    6. 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

    7. převzetí a potvrzení výzvy – výzva vzniká v IS pro OŘ zadáním dispečera a MZD umožňuje tuto výzvu včetně základních atributů převzít a zobrazit posádce

    8. vyplnění a tisk a záznamu o výjezdu

    9. uložení a poskytování dat o výjezdu - všechna zadaná data jsou 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.

2.4Oblast „knihy jízd“

Modul Kniha jízd (dále KJ) umožňuje následující funkce:

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

  • Z každého výjezdu jsou automaticky na základě obdržených dat z IS SOS a statusů vozidlových jednotek vytvářeny záznamy v knize jízd.

  • Do knihy jízd se automaticky přenáší údaje o jednotlivých výjezdech k událostem ZZS. Režijní jízdy bez vazby na výjezd jsou zadávány ručně.

    1. umožnit editaci spotřeby

  • Pro jednotlivé knihy jízd je možno doplnit v případě tankování do vozidla údaje s tankováním související:

    • objem paliva

    • cena paliva

  • Kromě toho je možné evidovat stav nádrže na konci směny.

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

  • Předávání dopravních výkonů pojišťovnám navrhujeme provádět společně s předáváním zdravotnických výkonů pomocí modulu Pojišťovna, který řeší veškerou agendu související s předávání dat pojišťovnám v souladu se standardy VZP.

    1. vytvářet potřebné sestavy

  • V modulu Kniha jízd je dostupná sestava Tisk knihy jízd pro výpis jízd dané směny. Kromě toho je k dispozici řada nejrůznějších přehledů sumarizujících výkony a spotřebu jednotlivých vozidel jak podle nákladových středisek, tak celkově.

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

  • Nastavení číselníků pro vykazování do VZP a importy dat do nich jsou prováděny v modulu Pojišťovna.

2.5Oblast geografického informačního sytému (GIS klient)

GIS klient je nasazen  současně s IS pro OŘ, proto musí splňovat požadavky kladené na systém ZZS PK 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 integrace s NIS IZS, využívá GIS klient lokální GIS data.

Obecné vlastnosti GIS klienta:

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

  • Konkrétní poloha, načtená nebo vygenerovaná v rámci IS pro OŘ, je automaticky lokalizována v mapě GIS klienta pomocí odpovídajících souřadnic.

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

  • Předanou polohu volajícího zobrazuje GIS klient v podobě dočasné ikony v mapě (při dokončení editace události ikona zmizí).

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

  • Předanou polohu volajícího zobrazuje GIS klient v podobě dočasné ikony v mapě (při dokončení editace události ikona zmizí).

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

  • Událost lze lokalizovat kliknutím do mapy nebo vyhledáním pomocí vyhledání adresy či bodu zájmu.

    1. 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

  • Uživatel si může (nebo dle potřeby nemusí) v mapě vizualizovat všechny řešené události.

    1. 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)

  • Vozidla (neboli výjezdové skupiny) jsou spojena s událostí, ke které jsou přiřazeny, spojnicí (úsečkou), která po třech sekundách zmizí. Tím je zajištěn přehled o výjezdových skupinách spolupracujících v rámci jedné události.

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

  • Objekty (výjezdové skupiny) se mohou identifikovat pomocí vozidlové klávesnice nejen v rámci zásahu (statusy/režimy typu výjezd, na místě…) ale také tzv. režijními statusy/režimy. Tyto lze vybírat z menu na displeji klávesnice a zvolený režim se také zobrazí u vozidla v mapě (GIS klient).

    1. 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.

  • GIS klient zobrazuje stavy výjezdových skupin. Informace o obsazení výjezdové skupiny (RLP x RZP) je získávána z vozidla (zadána na klávesnici) a následně zobrazena v mapě.

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

  • Fulltextové vyhledávání v adresách a zájmových bodech je součástí GIS klienta.

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

  • Při největším přiblížením mapy v případě překryvů ikon dochází ke shlukování (vozidel a událostí) se znázorněním objektů, které se v rámci jednoho shluku nachází.

    1. 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.

  • Body zájmu lze vytvářet a editovat na základě přidělených uživatelských práv. V rámci editace je možné bodům zájmu připojit libovolné dokumenty. V rámci jednotlivých bodů zájmu, vytvořených v GIS klientovi, je možné sledovat změny, které byly v GIS klientovi provedeny.

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

  • Body zájmu editované v GIS klientovi můžou být použity jako zdroj lokalizace události v GIS klientovi (poloha je následně předána do systému pro OŘ). Propojení databází bodů zájmů editovaných v IS pro OŘ a GIS bude realizována v rámci projektu NIS IZS.

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

  • Velkoplošné zobrazovací zařízení je vnímáno jako další klientské pracoviště a nastavit pro zobrazení situační mapy je tudíž standardně možné.

2.6Oblast vybavení vozidel

Všechna vozidla jsou vybavena GPS jednotkou s klávesnicí pro zadávání statusů od společnosti RADIUM s.r.o. a navigačním přístrojem Garmin. Propojení GPS jednotky s navigací je řešeno proprietárním kabelem.

Vybavení vozidel zajišťuje/podporuje tyto hlavní služby - procesy:

  • Sledování vozidel ze KZOS

  • Příjem příkazů k výjezdu (dále jen PkV) a informace o místě zásahu včetně zobrazení na mapě

  • Sledování stavu výjezdu, polohu vozidla, statusy apod.

  • Datová komunikace s kontaktním místem v nemocnici (viz stávající stav eHealth)

Součástí výbavy vozidel jsou i zařízení monitor/defibrilátor Lifepak.

2.7Oblast telefonie

Požadavky na zajištění telefonie jsou řešeny využitím pobočkové telefonní ústředny Cisco Call Manager (Cisco Business Edition 6000, UCSC-C220-M3SBE) a jejich komunikačních zařízení (dále používán pojem „ústředna OŘ“), která je integrována do celkové komunikační struktury ZZS PK se zajištěním klasické (ISDN) i IP telefonie a s integrací hlasových a datových služeb.

Objektová ústředna organizace AVAYA CM – Definity s rozhraním ISDN30 a je propojena s ústřednou pro OŘ.

Parametry konfigurace telefonní ústředny OŘ:

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

  • 33x IP telefon (Cisco UC Phone 7821)

  • 2 x ISDN 2

  • JTAPI/CTI rozhranní pro integraci

2.8Oblast nahrávání

Stávající nahrávací systém - Záznamová jednotka ReDat 3 umožňuje nahrávání:

a) 1 ISDN 30 do ústředny,

Pro záznam jednoho trunku ISDN 30 je využita speciální PCM karta (1x).

b) Integrace Pegas (8 LCT, 2 RCT),

Pro záznam digitálních radiostanic je využita speciální karta UDR (2x), podporující nahrávání digitálních poboček a radiostanic. Realizované řešení dále využívá integraci s terminály Tetrapol – RCT modul, včetně použitého konvertoru I2C-RS pro připojení terminálů RCT radiostanic systému TETRAPOL.

c) 9 IP telefonů,

Pro záznam IP telefonů je použito Ethernet rozhraní (Ethernet karta, 1x). Vlastní hovory jsou replikovány na ethernet port technologií SPAN/RSPAN.

d) analogové RDST 80 MHz.

Pro záznam analogových radiostanic je využita speciální karta APC, podporující nahrávání
a analogových poboček a radiostanic.


Takto zaznamenané hovory a další údaje (včetně identifikace volajícího a volaného) jsou po nahrání uloženy záznamového zařízení ReDat®3 Záznamová Jednotka, z které jsou replikovány do databáze a archivu aplikační nadstavby ReDat® Aplikačního Serveru.

2.9Oblast integrace telefonie

V oblasti telefonie je integrována telefonní ústředna pro operační řízení Cisco Call Manager se zajištěním klasické i IP telefonie a s integrací hlasových a datových služeb.

Je zajištěna maximální efektivní integrace telefonních systémů (pobočkové ústředny a IP telefonů) do systému integrace komunikací a IS OŘ.

  1. Integrace telefonie zajišťuje ovládání komunikačních systémů přímo z:

      1. rozhraní aplikace pro operační řízení

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

      3. v případě výpadku je komunikace zajištěna prostřednictvím systémových IP telefonů telefonní ústředny

  1. Integrace telefonie je realizována ve vazbě na následující technologie a systémy:

      1. Subsystém operačního řízení (IS pro OŘ)

      2. Záznamové zařízení Redat 3

      3. Telefonní pobočková IP ústředna určená pro operační řízení Cisco Call Manager

      4. Digitální radiokomunikační sítě PEGAS

  1. Základní vlastnosti integrace telefonie:

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

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

      3. možnost sestavení odchozího hovoru ze seznamu nebo ad hoc

      4. přijetí příchozího hovoru se zobrazením telefonního čísla volajícího

      5. zavěšení hovoru operátorem nebo protistranou

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

      7. přidržení hovoru

      8. přepínání mezi aktivním a přidrženým hovorem

      9. přepojení hovoru

      10. třístranná konference

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

      12. vstup do hovoru

      13. vedení podrobných protokolů o činnosti

      14. zajištění příposlechu

      15. krátkodobý záznam

      16. databáze volajících s možností vložení poznámky k telefonnímu číslu operátorem KZOS, zobrazení informací z databáze o volajícím čísle v případě příchozího hovoru již při vyzvánění

      17. zobrazení historie příchozích hovorů s možností filtrace příchozích hovorů z linek tísňového volání atd.

      18. Systém musí umožňovat automatizované zálohování dat.

Systém integrace musí zabezpečit optickou informaci o obsazenosti operátora hovorem prostřednictvím světelného optického zařízení umístěného na dispečerském stole každého jednotlivého operátora

2.10Oblast integrace radiové sítě PEGAS

S cílem optimalizovat práci dispečera operačního střediska je zajištěna maximálně možná integrace komunikačních radiových technologií. Integrace rádiové sítě zajišťuje, aby kterýkoli operátor mohl využívat kterýkoli instalovaný integrovaný terminál a poslouchat provoz na libovolných dalších terminálech. Implementován byl 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 jsou použita standardizovaná integrační rozhraní pro operační řízení podle zveřejněných specifikací výrobce systému PEGAS, zejména dodržení TETRAPOL Publicly Available Specifications.

2.10.1Základní funkce pro dispečera ZOS

integrace radiového systému PEGAS umožňuje tyto funkce pro operátora ZOS prostřednictvím ovládání aplikace na dotykovém LCD pracoviště:

    1. Klíčování

    2. připojení audiosignálů do propojovacího pole

    3. výstupy pro nahrávání

    4. zobrazení registračního stavu. Na dotykové obrazovce se zobrazuje registrační stav každé z radiostanic.

    5. seznam operačních skupin

    6. indikace stavu terminálu

    7. sestavení odchozího individuálního hovoru nebo vytáčené konference

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

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

    10. tiché volání s prověrkou oprávnění operátora

    11. ukončení individuálního hovoru operátorem nebo protistranou

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

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

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

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

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

    17. varování o nově otevřeném krizovém kanále

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

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

    20. přijetí statusu a adresovatelné odeslání statusu

    21. přijetí SMS a adresovatelné odeslání SMS

SMS je možno odesílat z dotykové obrazovky nebo prostřednictvím aplikačního můstku ze subsystému SOŘ.

    1. skupinové odeslání SMS předem definované skupině

2.11HW vybavení

Detailní popis využívaných technologií, jejich architektura a další nezbytné informace o HW infrastruktuře jsou uvedeny v příloze č. 9 Zadávací dokumentace – Technické řešení.

2.12Místo plnění

Místem plnění je budova – sídlo ZZS PK na adrese: Klatovská tř. 2960/200i, 301 00 Plzeň. Pořizované technologie, vybavení a informační systémy v rámci této veřejné zakázky budou dodány a implementovány v  sídle ZZS PK.

3Popis cílového (požadovaného) stavu a specifikace předmětu plnění

  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

Radiová síť PEGAS

DR-01

Integrace sítě PEGAS

LCT Rack pro LCT2G Terminály, včetně instalace

1

Informační systémy

IS-04

Zálohování

Doplnění HW a SW pro zajištění zálohování IS pro OŘ

1

IS-14

Jiné specifické úpravy IS pro OŘ

Vývoj, implementace funkcionalit IS pro OŘ dle požadavků.

1

IS-15

Jiné technologické doplnění IS

SW pro mobilní zadávání dat – rozšíření funkcionalit dle požadavků

1

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

  1. Význačné parametry, které jsou v řešení ZZS PK požadovány:

    1. 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)

    2. jednotná podpora procesů

    3. zajištění vysoké míry dostupnosti a spolehlivosti systému

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

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

  1. 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

IS pro OŘ

24x7 x 365 (nepřetržitý režim)

Ano

Nahrávání

24x7 x 365 (nepřetržitý režim)

Ano

Integrace sítě PEGAS

24x7 x 365 (nepřetržitý režim)

Ano

Tabulka 3: Požadavky na dostupnost a spolehlivost

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

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

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

    3. Spolehlivost napájení jednotlivých hardwarových komponent

    4. Spolehlivost jednotlivých hardwarových prvků a jejich komponent

    5. Mechanismy zálohování dat

    6. Požadovanou dostupnost serverových služeb 99,5%

  1. 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í.

    1. 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.

    2. Bezpečnostní politika IT prostředí ZZS PK nedovoluje volný přístup do jiných datových sítí nebo na veřejný internet. Pokud některá část aplikace IS ZZS PK 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 PK musí respektovat tento způsob přístupu při návrhu komunikace IS ZZS PK s externími aplikacemi.

  1. 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í.

  2. 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.

  3. 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í Díla zadavateli.

  4. 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:

    1. 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ů.

    2. 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.

    3. 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ší).

  1. 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.

3.1Integrace sítě PEGAS (DR-01)


V rámci 1. etapy Krajského standardizovaného projektu Zdravotnické záchranné služby Plzeňského kraje byla implementována integrace sítě PEGAS. V rámci této dodávky má ZZS PK k dispozici má nyní 8ks LCT2G terminálů nainstalovaných v lokalitě PČR. Terminály jsou v současné době nainstalovány do LCT Racku, který je ve vlastnictví PČR. Volná kapacita LCT Racku byla pro tyto účely ze strany PČR zapůjčena a je na něm provozován současný systém ZZS.

Předmětem požadované dodávky technologického vybavení v projektu „Dodávky technologie projektu 2 Zdravotnické záchranné služby Plzeňského kraje“ je dodávka LCT Racku pro LCT2G terminály a jeho instalace.

Dodavatel musí garantovat plnou kompatibilitu se stávajícím řešení.

Funkční požadavky:

  • Je požadován 1ks LCT Rack jednotky umožňující připojit až 12 linkových terminálů (LCT2G) používaných nyní v rámci integrace sítě PEGAS.

  • LCT Rak je požadován v konfiguraci pro instalaci do 19“ stojanu. LCT Rak musí být plně kompatibilní se stávajícím řešení.

  • Součástí dodávky je i instalace, konfigurace a přepojení ze stávajícího LCT Racku PČR včetně ověření funkčnosti integrace sítě PEGAS.

  • Je požadována záruka 24 měsíců na dodané technologie.

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

3.2.1Replikace IS pro OŘ s možností přepnutí na záložní datové centrum.

Požadavky na zálohovací a replikační systém (ZRS)

Zadavatel požaduje dodat zálohovací a replikační systém minimálně s těmito vlastnostmi:

  1. Popis funkcionality - systém zálohování a replikace serveru IS pro OŘ musí řešit především automatické zálohování Oracle DB, na jejíž správné činnosti je celý IS pro OŘ závislý, kontrolu její správné funkčnosti a její replikaci do jiné lokality. Celý systém musí fungovat jako celek, automaticky, pouze případně s volbou ručního spuštění některých vybraných operací (jako např. failover, failback) na základě předem daných Disaster recovery pravidel a postupů. Replikační systém musí zajistit kontinuální chod replikace produkční DB do cílové lokality s co nejmenším časovým posunem, řádově několika sekund, maximálně několika minut. Nesmí nijak výrazně zatěžovat celou infrastrukturu, hlavně chod samotného IS pro OŘ.

ZRS tak musí díky požadovaným vlastnostem umožnit provoz záložního datového centra IS pro OŘ (bez nutnosti všech integračních vazeb). Požadované řešení musí zajistit, aby data z primární lokality dostupná při přepnutí klientů na záložní řešení nebyla starší než 10 minut (zpoždění replikace postupných odesíláním dat). Vzhledem k možným scénářům ztráty primární lokality a doby a způsobu náběhu činnosti KZOS v záložní lokalitě je toto zpoždění přípustné. 

Realizace těchto požadavků musí umožnit replikaci dat do záložní lokality KZOS ZZS PK a provoz IS pro OŘ na hybridních operátorských pracovištích KZOS v lokalitě Klatovská tř. 2960/200i, 301 00 Plzeň ve dvou variantách:

•     Proti primárnímu DB serveru v lokalitě Klatovská tř. 2960/200i, 301 00 Plzeň

•     Proti replice DB serveru v záložní lokalitě

  1. Požadované vlastnosti systému zálohování a replikace DB:

    1. ZRS musí plně fungovat se stávajícími používanými technologiemi (OS Linux, DB Oracle Standard Edition One), které nejsou součástí dodávky a budou poskytnuty ZZS PK.

    2. uživatelsky jednoduchá obsluha

    3. možnost plné automatizace celého systému replikace

    4. asynchronní replikace

    5. replikace na logické úrovni DB, ne na úrovni filesystemu - zamezení přenesení corrupted data block do cílové lokality

    6. možnost replikace v LAN i WAN sítích, do geograficky vzdálené lokality

    7. co nejmenší požadavky na propustnost sítě mezi lokalitami

    8. možnost regulace zatížení sítě během replikace

    9. neustálé vyhodnocování stavu replikace, doby zpoždění systému v záložní lokalitě oproti produkci, alerting v případě většího časového posunu

    10. alerting v případě výpadku replikace

    11. automatické obnovení replikace v případě výpadku síťového propojení lokalit případně celé zdrojové nebo cílové lokality

    12. každodenní ověřování konzistence a použitelnosti repliky

    13. automatické klonování repliky pro testovací a školící účely

    14. možnost rychlého automatického přepnutí provozu aplikací ze zdrojové do cílové lokality

    15. v případě přepnutí do cílové lokality možnost nastavení zpětné replikace do původní produkční lokality (zajištění nejen dopředné, ale i zpětné replikace)

    16. přenos dat mezi hlavním a záložním databázovým serverem bude zabezpečen šifrovaným přenosem a přenášená data mohou být komprimována tak, aby požadavek na propustnost datového propojení hlavní a záložní lokality nepřesáhl 10 Mbps.

    17. logování činnosti systému

  2. Požadavek na klienta IS pro OŘ:

Klientský software na hybridních operátorských pracovištích musí zajistit, aby v případě výpadku hlavního databázového serveru po následném přepnutí provozu na záložní databázový stroj nebyla nutná žádná rekonfigurace pracovních stanic. 

Po přepnutí provozu na záložní server si na stanicích aplikace po spuštění automaticky samy najdou běžící databázi na záložním serveru.

3.2.2HW pro replikaci IS pro OŘ


V rámci realizace předmětu plnění využije uchazeč stávající fyzický server pro replikaci v záložní lokalitě (1xCPU, 4GB RAM, 2x300GB HD). V případě, že konfigurace serveru není vyhovující pro nabízený zálohovací a replikační systém bude součástí dodávky uchazeče i server.

V rámci realizace předmětu plnění uchazeč zajistí dodávku a implementaci technologické IT infrastruktury v rozsahu dodávky dvou switchů L3 pro záložní lokalitu. Ostatní části infrastruktury (SERVER, RACK, WAN apod.) nejsou součástí poptávky.

Zadavatel si sám v době realizace určí, v které lokalitě na území PK bude záložní server umístěn.

Dodávka musí tak zahrnovat dva kusy L3 switche s těmito minimálními parametry:

  • gigabitový ethernetový spravovatelný přepínač vrstvy 3

  • min. 4x 10Gb ethernet portů SFP+ a min. 48x 10/100/1000Mbs portů

  • 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 loadbalancingu) vysokorychlostním redundantním propojením – propustnost stacku 480 Gbps,

  • neblokovaná architektura, propustnost min. 170 Gbit,

  • software podporující CLI (Telnet/SSH/RS232), WEB a SNMP management, včetně omezení přístupu na management z definovaných adres a subnetů,

  • podpora Jumbo Frames, min. 9 kB, podpora agregace portů (LACP) s využitím dvou switchů ve stacku (jedna agregace pře dva switche),

  • 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,

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

  • podpora DHCP snooping, Dynamic ARP Inspection, IP Source Guard

  • podpora QoS (prioritizace služeb),

    • min. 8 výstupních front

    • podpora prioritní fronty na výstupu

    • klasifikace na základě 802.1p, DSCP a ACL

  • podpora Application Visibility (NetFlow, sFlow) bez nutnosti HW rozšíření

  • podpora VLAN (min. 1000 aktivních VLAN),

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

  • Podpora L3 směrování - statické, RIPv2, OSPF, EIGRP, BGP, IS-IS, PBR,

  • možnost oddělených směrovacích kontextů

  • podpora směrování multicastu, PIM sparse a source-specific multicast (SSM),

  • podpora technologií jako je IP SLA,

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

  • podpora IPv4 a IPv6,

  • podpora IPv6 FHS (First Hop Security) v rozsahu min. RA Guard, source guard a binding integrity guard

  • podpora SFP+ modulů typu SR a LR se zakončením LC,

  • potřebná optická kabeláž a SFP+ moduly pro připojení všech nabízených vizualizačních serverů,

  • záruka minimálně 60 měsíců


3.3Jiné specifické úpravy IS pro OŘ (IS-14)

Operační řízení je základním subsystémem celého systému. Subsystém slouží zejména předávání tísňových výzev, alokaci a řízení SaP a sledování aktuálního stavu řešených mimořádných událostí. V případě výpadku systému NSPTV slouží subsystém Operační řízení také pro příjem a evidenci tísňových výzev. Tísňové výzvy přijímají a zpracovávají operátoři. Na základě tísňových jsou v systému vytvářeny Události, na základě kterých dispečeři řídí prostředky SaP. Systém také zajistí distribuci a příjem výzev na výjezdových stanovištích SaP.

V rámci této oblasti předmětu plnění je požadováno implementovat specifické úpravy IS pro OŘ pro zajištění vyšší efektivity, komfortu práce a informovanosti operátorů KZOS.

Jedná se o požadavky rozšiřující stávající řešení realizované v rámci standardizovaného projektu – dodávka technologií. Dodavatel zajišťuje plnou kompatibilitu a integraci požadavků do jednotného GUI tak, aby se pro operátora a uživatele požadované vlastnosti jevili jako integrální rozšíření stávajícího systému.

Tyto úpravy musí zajistit ve vztahu k celkovým cílům projektu především:

  • Zkrácení reakční doby při zásazích

  • Zvýšit přehled o operační situaci

  1. obecné požadované vlastnosti:

    1. uživatelsky jednoduchá obsluha, jednotné uživatelské rozhraní

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

    3. velká rychlost odezev systému

    4. plná kompatibilita a integrace se stávajícím systémem

  2. Katalog požadavků na specifické úpravy IS pro OŘ:


Automatická podpora využívání AED:

Jde o komplex funkcionalit, jejichž cílem je v co nejefektivněji využívat AED, která jsou k dispozici v místech událostí, k záchraně životů v době před příjezdem prostředků ZZS. Funkcionalita musí splňovat následující požadavky:

  • Automatické upozornění operátora na existenci AED dostupných k místu události

  • Otevření přehledu dostupných AED s jejich přehlednou kategorizací vzhledem ke vzdálenosti k místu události

  • Pro vybraný AED možnost automatického telefonního spojení pro aktivaci (First Responder)

  • Možnost vyžádání spolupráce dalšího operátora, kdy první operátor pokračuje v náběru události a druhý operátor zajišťuje pro tutéž událost aktivaci (First Responder]

  • Automatické notifikace aktivace AED pomocí SMS na konfigurované kontakty ZZS

  • Registrace údajů o způsobu použití AED k jednotlivým aktivacím

  • Správa registru AED se základními informacemi, kontakty, polohami a okruhem použití (volitelně je zadán akční rádius nebo seznam obcí nebo ulic obsluhovaných daným AED)

  • Možnost přepnutí AED do servisního režimu (dočasně nedostupný), možnost konfigurovat časová okna provozních hodin AED (obchodní centra apod.)

  • Možnost filtrovat události ZZS podle využívání AED, přehled všech aktivací AED, statistiky

Efektivní svolávání při HN:

Existující svolávací systém umožňuje nejrůznější varianty svolávání, kdy je možné pružně zadávat nejrůznější vlastnosti svolávání a je možné nejrůznějšími způsoby vytvářet seznamy svolávaných osob. V případě výskytu mimořádné hromadné události je však třeba, aby bylo naopak uživatelské rozhraní přizpůsobeno pro takovou jednoúčelovou záležitost s ohledem na stres a kritičnost takové situace – proto musí uživatelské prostředí uživatele co nejintuitivněji provést zvládnutím takového úkolu. Druhou věcí je potom samotná efektivita (rychlost) svolávání a přehledné vyhodnocování zpětných reakcí svolávaných osob.

Požadované nové vlastnosti svolávání proto zahrnují:

  • Nové intuitivní samonaváděcí předkonfigurované GUI pro hromadného svolávání zaměstnanců při HN, kdy operátor bude vybírat z předkonfigurovaných variant svolávání pro různé předkonfigurované stupně mimořádných událostí

  • Přechod na nový interface pro rychlé rozesílání SMS (především pro potřebu HN)

Simulace historické stavu OŘ:

Nové řešení umožní takové zaznamenání dat průběhu změn operační situace a doplnění funkcionality pro jejich reprodukci zpětně, že bude možné v dispečerské obrazovce zpětně nasimulovat stav a průběh řešení dané situace:

A. staticky - stav obrazovky operátora k vybranému časovému okamžiku

B. dynamicky - umožnit přehrát průběh změn operátorské obrazovky od zadaného času směrem k současnosti.

Rozšíření GUI Dispečerského systému o data pacientů z EKP (MZD).

Je požadováno rozšíření uživatelského rozhraní IS pro OŘ o data pořizovaná během výjezdu posádkami výjezdových skupin v systému Mobilního zadávání dat. (MZD)

Uživatelská modifikovatelnost dat RUIAN v SOŘ:

V určitých speciálních situacích nejsou oficiální data RUIAN zcela přesná nebo chybí. Je požadováno zajistit zadávání uživatelům přesnější informace do systému návazně na data RUIAN (modifikace informací RUIAN k konkrétní adrese/lokalitě nebo přidání nové lokality/adresy). Díky tomu bude činnost operátorů při využití nových uživatelských dat o polohách při opakovaném výskytu události na těchto adresách efektivnější a rychlejší.


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


Pro současný systému MZD je požadováno rozšíření o funkci vyhledávání v RÚIAN (Registr územní identifikace, adres a nemovitostí). Implementace musí zahrnovat fulltextové vyhledávání v datech RÚIAN a jejich import do systému MZD. Dodavatel musí garantovat plnou kompatibility se stávajícím systémem.

Požadované rozšiřující funkce pro systém MZD:

    1. Implementace fulltextového vyhledávání v datech RÚIAN (Registr územní identifikace, adres a nemovitostí).

    2. Uživatel bude mít možnost pomocí jednotného datového pole vyhledávat v registru, kdy výstupem bude automatické vyplnění všech položek adresy daného záznamu (město, ulice a PSČ)

    3. Data pro vyhledávání musí být pro zrychlení a zefektivnění procesu částečně uložena v paměti tabletu s MZD

    4. Vyhledávání musí probíhat nad celou strukturou adresy (ulice, část obce, město).

    5. Funkce vyhledávání v RUIAN musí být dostupná ve všech částech systému MZD, ve kterých se vyskytuje požadavek na zadání adresy.

    6. Plná kompatibilita a integrace se stávajícím systémem.


Pro současný systému MZD je požadováno rozšíření o tiskové formuláře ZZS. Systém musí umožnit plnohodnotné vyplnění a tisk níže uvedených formulářů v terénu. Aplikace MZD musí být rozšířena o nezbytná datová pole tak, aby bylo možné všechny níže uvedené formuláře vyplnit a vytisknout. Pokud jsou již některé položky/datové pole vyplňovány v rámci současného záznamu o výjezdu systém je musí automaticky převzít/kopírovat i pro tyto tiskové sestavy.

Požadované formuláře k implementaci jsou tyto:

    1. Potvrzení o nároku cizího pojištěnce z členské země EU a EHP na čerpání lékařsky nezbytné péče po dobu přechodného pobytu v ČR

    2. Negativní revers

    3. Průvodní list k pitvě na soudním lékařství

    4. Příkaz ke zdravotnímu transportu

    5. Vyúčtování výkonů ve zdravotnické záchranné službě

    6. Uznání závazku, Declaration of debt, schuldenanerkennung (ve třech jazycích)

    7. Plná kompatibilita a integrace se stávajícím systémem.


Jednotlivé položky formulářů plně odpovídají stávajícím používaným papírovým formulářům (viz příloha ZD). Rozvržení a umístění jednotlivých položek a to jak při elektronickém vyplňování tak při tisku bude specifikováno zadavatelem v průběhu implementace. V implementovaných formulářích musí být možné využít funkci vyhledávání v RUIAN dle předcházejícího funkčního požadavku

3.5Požadavky na služby

3.5.1Realizace předmětu plnění

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. 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:

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

      1. Rozpracování návrhu řešení z nabídky Uchazeče dle informací z předimplementační analýzy

      2. Specifikace rozhraní pro integraci na IS a technologie třetích stran

    2. Způsob zajištění potřebných dodávek včetně zajištění technické podpory

    3. Detailní návrh a popis postupu implementace předmětu plnění

    4. 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:

      1. Zahájení projektu

      2. Provedení předimplementační analýzy

      3. Předání prováděcí dokumentace

      4. Zahájení realizace předmětu plnění

      5. Školení

      6. Zahájení zkušebního provozu

      7. Akceptační testy

      8. Zahájení plného provozu

  2. Zajištění projektového vedení realizace předmětu plnění ze strany Uchazeče a jeho případných subdodavatelů.

  3. 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:

    1. 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

    2. Instalace do prostředí Zadavatele v testovacím režimu

    3. Interní ověření na straně Uchazeče a příprava podkladů pro ověření na straně Zadavatele (dokumentace, organizace testování a další)

    4. 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.

  1. Dodávka předmětu plnění do lokalit v rámci Plzeňské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ě:

  2. Zajištění instalace všech součástí dodávky v určených lokalitách a prostorách Zadavatele na území Plzeňského kraje.

  3. Zajištění instalace a připojení k zařízením a technickým prostředkům zajištěným Zadavatelem.

  4. 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í.

  5. Aktualizace stávající systémové a provozní dokumentace - součástí předmětu plnění je aktualizace systémové a provozní dokumentace související s realizací předmětu

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ě.

  1. 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.

  2. 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.

  3. 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.

3.5.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:

    1. Základní produktové seznámení s jednotlivými dílčími technologickými celky.

    2. Zaškolení do celkového schématu součinnosti jednotlivých zařízení a jejich návaznosti.

    3. Zaškolení na použitá nastavení zařízení, detailnější rozbor použitých konfigurací.

    4. 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ů

2 správci

1 den

Správa systému, zálohování a replikace dat IS pro OŘ. nahrávání a audit nahrávání obrazovek.

IS pro OŘ

10 klíčových uživatelů

Individuálně

Školení zaměřené na nové funkcionality IS pro operační řízení – operátoři.

Školení zaměřené na činnost se speciálním oprávněním vedoucího dispečera nebo supervizora.

Tabulka 4: Požadavky na školení

  1. Š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.

  2. Konkrétní termíny školení určí Zadavatel dle postupu v rámci realizace projektu a dostupnosti školených osob.

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

4Záruky a servisní podmínky po dobu udržitelnosti

V této kapitole jsou uvedeny požadavky na záruky Díla jako celku, případně specificky dílčích částí Díla. Dále jsou zde uvedeny požadavky, parametry a podmínky servisních služeb poskytovaných po min. po dobu udržitelnosti projektu, která je 5 let od účinnosti servisní smlouvy, která nastává okamžikem závěrečného předání a převzetí díla dle Xxxxxxx od dílo.

4.1Zá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ě:

    1. 60 měsíců na informační systém (y), aplikace a služby spojené s realizací projektu

    2. 24 měsíců – u HW, systémového SW a technických zařízení

    3. 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.

  1. 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.

  2. Uchazeč prokáže způsob zajištění shody dodávaných systémů s platnou legislativou.

  3. 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.

4.2Servisní 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.

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 Objednatele 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 5: Pojmy

4.2.1Kategorizace 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 PK. 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 6: Kategorie incidentů

4.2.2Kategorizace servisních služeb

V následující tabulce je uvedena kategorizace servisních služeb, služby jsou vzestupně kumulativní:

Kategorie

Popis

Záruka

Jsou poskytovány služby v rámci záruky v rozsahu, který je specifikován v záručních podmínkách, případně ve specifikaci dílčí části IS OŘ.

Nejedná se o služby nad rámec dodávky a běžné záruky tj. poskytování těchto služeb je součástí ceny dodávky technologií OŘ.

Maintenance

Poskytování služeb maintenance nad rámec běžné záruky tj. přístup k opravným balíčkům, legislativním změnám, apod.

24 hod

Poskytování služeb technické podpory nad rámec běžné záruky tj. poskytování hotline, kontaktního místa, garance reakční doby a doby odstranění závady (nebo snížení závady na nižší úroveň v daném časovém limitu).

Tabulka 7: Kategorie servisních služeb

Upozornění: Nevztahuje se na případy, kdy důvody nefunkčnosti jsou způsobené Objednatelem, nebo třetí stranou, případně jsou způsobeny částí dodávky, na které se nevztahuje příslušné SLA.

V následující tabulce jsou pro jednotlivé kategorie servisních služeb definovány základní parametry:

Kategorie

A

B

C

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ě

Maintenance

2 prac. dny

4 prac. dny

4 prac. dny

15 prac. dnů

15 prac. dnů

Po dohodě

24 hod

24 hod

2 kal. dny

Následující prac. den

4 prac. dny

2 prac. dny

Po dohodě

Tabulka 8: Parametry servisních služeb

Údaje v závorkách platí pro mimopracovní dobu, pracovní doba je v pracovní dny od 8:00 do 18:00.

Pro kategorii REQ nejsou stanovena SLA, konkrétní lhůty jsou předmětem dohody mezi smluvními stranami.

4.2.3Úroveň služeb pro jednotlivé dílčí části IS OŘ

V následující tabulce jsou stanoveny základní úrovně služeb pro dílčí části dodávaného řešení:

Ozn.

Položka

Kategorie služeb

Radiová síť PEGAS

DR-01

Integrace sítě PEGAS

Záruka

Informační systémy

IS-04

Zálohování

24 hod

IS-14

Jiné specifické úpravy IS pro OŘ

24 hod

IS-15

Jiné technologické doplnění IS

24 hod

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

4.3Doplňující požadavky na záruční a servisní služby

Zadavatel má následující doplňující požadavky na záruční a servisní služby:

  • Poskytovatel služeb zajistí jednotný systém hotline

    • s elektronickým přístupem přes síť internet

    • s kontaktním telefonním číslem

    • poskytující informace o změnách v incidentech/požadavcích Objednateli emailem

  • Servisní služby budou vykazovány měsíčně (za uplynulý kalendářní měsíc) a to včetně přehledu plnění SLA

  • Servisní služby budou účtovány čtvrtletně na základě podepsaných (akceptovaných) měsíčních výkazů za dané uplynulé čtvrtletí.

V rámci přípravy nabídky Uchazeč poskytne popis způsobu poskytování servisních služeb.


5Seznam zkratek a pojmů


Zkratka/pojem

Význam

API

Application Programming Interface (rozhraní informačního systému nebo technologie používané pro integrace)

CD

Datový nosič

CPU

Central Processing Unit (procesor)

ČR

Česká republika

DB

Databáze

DVD

Datový nosič

EKP

Elektronická karta pacienta

GIS

Geografický informační systém

GPS

Global Positioning Systém (systém určování polohy; často označuje systém pro sledování vozidel)

GSM

Globální Systém pro Mobilní komunikaci

GUI

Grafické uživatelské rozhraní

HDD

Hard Disk Drive (pevný disk v počítači)

HW

Hardware

HZS ČR

Hasičský záchranný sbor České republiky

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)

IT

Informační technologie

IZS

Integrovaný záchranný systém

PK

Plzeňský kraj

KSP

Krajský standardizovaný projekt

KÚPK, KrÚ

Krajský úřad Plzeňského kraje

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

MS

Microsoft

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 nebo operační systém, dle kontextu

PCM

Pulse-code Modulation (technologie v rámci komunikační infrastruktury)

PDF (.pdf)

Portable Document Format, formát dokumentu

PkV

Příkaz k výjezdu

RCT

Radio Connected Terminal (vysílačka)

RLP

Rychlá lékařská pomoc

RUIAN

Registr územní identifikace, adres a nemovitostí

RV

Rendez-vous – způsob řízení výjezdů mezi s využitím lékaře (RLP) i záchranářů (RZP)

RZP

Rychlá zdravotnická pomoc

SaP

Síly a prostředky

SIM (karta)

Subscriber Identity Module (karta pro zajištění mobilní komunikace v zařízení)

SLA

Úroveň servisních služeb

SOŘ

Systém pro operační řízení

SW

Software

TCTV

Telefonní centrum tísňového volání

TV

Tísňová výzva

VS

Výjezdová skupina

VZP ČR

Všeobecmá zdravotní pojišťovna České republiky

WAN/VPN

Počítačová síť

KZOS

Krajské zdravotnické operační středisko

.zip

Typ archivního souboru

ZOS

Zdravotnické operační středisko

ZZS

Zdravotnická záchranná služba

ZZS PK

Zdravotnická záchranná služba Plzeňského kraje

Tabulka 20: Seznam zkratek a pojmů


Konec dokumentu

Projekt je spolufinancován Evropským fondem pro regionální rozvoj prostřednictvím Integrovaného operačního programu a státním rozpočtem České republiky

Strana 31 z 31

Document Metadata

Filed: March 18th, 2023