Soutěž o návrh Hospodárné a funkční elektronické zdravotnictví

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obsah 1

Shrnutí ................................................................................................................................................................... 6

2

Mapování stávajícího stavu systémů vycházejících z principů elektronizace zdravotnictví ................................. 7 2.1

Představení systému zdravotnictví s ohledem na využití ICT technologií .................................................. 7

2.1.1

Pacienti .................................................................................................................................................... 7

2.1.2

Zdravotničtí pracovníci ......................................................................................................................... 10

2.1.3

Poskytovatelé zdravotních služeb ......................................................................................................... 10

2.1.4

Zdravotní pojišťovny ............................................................................................................................. 13

2.1.5

Státní správa .......................................................................................................................................... 14

2.1.6

Krajská a obecní samospráva ................................................................................................................ 36

2.1.7

Vzdělávací a výzkumné instituce .......................................................................................................... 37

2.1.8

Výrobci a distributoři zboží a poskytovatelé služeb pro zdravotnická zařízení .................................... 37

2.2

Mapování stávajícího stavu systému zdravotnictví ČR ............................................................................. 37

2.2.1

Systém zdravotnictví ČR a hlavní aktéři ............................................................................................... 37

2.2.2

Základní data zdravotnického systému v ČR a mezinárodní kontext .................................................... 43

2.3 Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky ................................................................................................ 47 2.3.1

Technické a komunikační standardy ..................................................................................................... 47

2.3.2

Nomenklatury a klasifikace ................................................................................................................... 58

2.4

Analýza způsobu využití historických a současných dat ve zdravotnických systémech ........................... 64

2.4.1

Klinické IS poskytovatelů zdravotních služeb ...................................................................................... 64

2.4.2

Základní IS zdravotních pojišťoven ...................................................................................................... 66

2.4.3

Národní registry ÚZIS/KSRZIS ............................................................................................................ 67

2.4.4

Centrální úložiště na SÚKL .................................................................................................................. 67

2.4.5

Seznamy členů profesních komor a IS vzdělávacích institucí ............................................................... 68

2.5 Finanční a ekonomická analýza stávajícího systému zdravotnictví ČR s ohledem na budoucí elektronizace zdravotnictví ..................................................................................................................................... 68

3

2.5.1

Struktura financování zdravotnictví a celkové náklady......................................................................... 68

2.5.2

Struktura nákladů na zdravotnictví, hospodaření zdravotních pojišťoven ............................................ 70

Návrh budoucího stavu elektronizace zdravotnictví v České republice .............................................................. 71 3.1

Globální popis navrhovaného řešení ......................................................................................................... 71

3.1.1

Definování vize a mise projektu ............................................................................................................ 71

3.1.2

Zhodnocení dopadu navrhovaných změn na českou legislativu ............................................................ 72

3.1.3

Návrh způsobu řešení zpřístupnění informací uživatelům budovaného systému .................................. 73

3.1.4

Analýza možností a předpokladů využití principů prediktivní analytiky na nově vybudovaném systému 73

3.1.5

Návrh způsobu napojení nového systému na již existující základní registry veřejné správy ................ 73

3.1.6 Návrh způsobu napojení nového systému na již existující registry vymezené legislativou (Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování) .......................................................... 73

2 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 3.1.7 Sběr, analýza a vyhodnocení potřeb budoucích uživatelů (zdravotničtí pracovníci, lékárníci, pacienti) budovaného systému ........................................................................................................................................... 74 3.1.8

Cost-benefit analýza navrhovaných změn celého elektronického zdravotnictví ................................... 74

3.1.9

Zpracování analýzy proveditelnosti navrhovaných změn celého elektronického zdravotnictví ........... 75

3.2

Shrnutí hlavních přínosů celkového návrhu řešení dle cílových skupin .................................................... 75

3.2.1

Pacienti .................................................................................................................................................. 75

3.2.2

Zdravotničtí pracovníci ......................................................................................................................... 75

3.2.3

Poskytovatelé zdravotních služeb ......................................................................................................... 76

3.2.4

Zdravotní pojišťovny ............................................................................................................................. 76

3.2.5

Státní správa .......................................................................................................................................... 76

3.2.6

Krajská a obecní samospráva ................................................................................................................ 76

3.2.7

Vzdělávací a výzkumné instituce .......................................................................................................... 76

3.2.8

Výrobci a distributoři zboží a poskytovatelé služeb pro zdravotnická zařízení .................................... 76

3.3

Rizika navrhovaného řešení ....................................................................................................................... 77

3.4

SWOT analýza navrhovaného řešení ......................................................................................................... 78

3.4.1

Silné stránky .......................................................................................................................................... 78

3.4.2

Příležitosti ............................................................................................................................................. 78

3.4.3

Slabé stránky ......................................................................................................................................... 78

3.4.4

Hrozby ................................................................................................................................................... 78

3.5

Odpovědi na základní otázky..................................................................................................................... 79

3.5.1 Jaké jsou potřeby zdravotnických pracovníků v ČR a jaké jsou jejich očekávání od elektronizace zdravotnictví? Identifikujte přínosy elektronizace pro jednotlivé cílové skupiny. .............................................. 79 3.5.2 Navrhněte typy výstupů, které je vhodné veřejně publikovat. Identifikujte relevantní informační zdroje. 79 3.5.3 Jaké jsou přínosy a dopady případné implementace projektu epSOS, respektive využití jeho principů na národní úrovni? Jak by měla být navržena problematika dostupnosti základního datasetu? .......................... 80 3.5.4 Jaké mezinárodně uznávané standardy a nomenklatury doporučujete v ČR zavést a proč? Jaký doporučujete další postup s národním standardem DASTA? .............................................................................. 80 4

Návrh implementace změn v českém zdravotnictví ............................................................................................ 82 4.1

Procesně organizační a legislativní model ................................................................................................. 83

4.1.1

Popis současného stavu a jeho zhodnocení ........................................................................................... 83

4.1.2

Návrh úpravy organizace a procesů ...................................................................................................... 84

4.1.3

Případné dopady na stávající legislativu a návrh řešení ........................................................................ 87

4.1.4

Přínosy navrhovaného řešení................................................................................................................. 90

4.2

Ekonomický a statistický model ................................................................................................................ 90

4.2.1

Globální popis návrhu ekonomického modelu ...................................................................................... 91

4.2.2

Přínosy navrhovaného řešení................................................................................................................. 91

4.2.3 Identifikace a zhodnocení dopadů navrhovaného řešení elektronizace zdravotnictví na stávající stav z ekonomického hlediska ....................................................................................................................................... 92 4.2.4

Analýza možností a předpokladů využití principů prediktivní analytiky na nově vybudovaném systému 92

3 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 4.2.5 Návrh modelu zpracování dat pro účely statistiky a vyhodnocování funkčnosti a ekonomiky elektronického zdravotnictví ............................................................................................................................... 93 4.3

5

4.3.1

Globální koncept architektury elektronického zdravotnictví ................................................................ 94

4.3.2

Oblast standardizace .............................................................................................................................. 99

4.3.3

Systémy identifikace ........................................................................................................................... 101

4.3.4

Výměna elektronické zdravotnické dokumentace pacienta ................................................................. 108

4.3.5

Úprava elektronická preskripce ........................................................................................................... 114

4.3.6

Zpracování informací o radiační zátěži pacienta ................................................................................. 116

4.3.7

Manažerský informační systém ........................................................................................................... 117

4.3.8

Portálová řešení ................................................................................................................................... 120

4.3.9

Další řešení dle uvážení uchazeče ....................................................................................................... 124

4.3.10

Interoperabilita s okolními informačními systémy ......................................................................... 124

4.3.11

Vazba na základní registry .............................................................................................................. 125

Návrh organizace zavádění elektronického zdravotnictví v ČR ....................................................................... 127 5.1

Metodika řízení projektu ..................................................................................................................... 127

5.1.2

Vybrané procesy řízení projektu ......................................................................................................... 130

5.1.3

Řídící struktura projektu...................................................................................................................... 135

5.1.4

Komunikace v rámci projektu ............................................................................................................. 137

5.1.5

Projektové role .................................................................................................................................... 140

5.1.6

Metodika vývoje SW ........................................................................................................................... 144

5.1.7

Návrh realizačního projektu ................................................................................................................ 147 Návrh systému Quality Assurance přístupu při implementaci projektu .................................................. 148

5.2.1

Kategorie testů .................................................................................................................................... 148

5.2.2

Procesní model .................................................................................................................................... 149

5.2.3

Testovací tým ...................................................................................................................................... 159

5.2.4

Dokumentace....................................................................................................................................... 161

5.2.5

Testovací prostředí .............................................................................................................................. 161

5.3

Návrh systému hodnocení rizik projektu ................................................................................................. 162

Komunikační strategie a PR aktivity projektu .................................................................................................. 163 6.1

Návrh způsobu komunikace s klíčovými hráči odvětví ........................................................................... 163

6.1.1

Lékaři .................................................................................................................................................. 163

6.1.2

Pojišťovny ........................................................................................................................................... 164

6.1.3

Pacienti ................................................................................................................................................ 164

6.1.4

Odborná veřejnost ............................................................................................................................... 164

6.1.5

Laická veřejnost .................................................................................................................................. 165

6.2 7

Definice základních principů řízení projektu ........................................................................................... 127

5.1.1

5.2

6

Technický model ....................................................................................................................................... 94

Návrh dlouhodobé koncepce komunikace včetně vymezení klíčových komunikačních kanálů koncepce 165

Rejstříky a seznamy .......................................................................................................................................... 166

4 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 7.1 8

Seznam klíčových zkratek ....................................................................................................................... 166

Přílohy ............................................................................................................................................................... 167

5 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

1

Shrnutí

Tento návrh je zaměřen na hospodárné vytvoření funkčního systému eHealth, který je schopen přinášet hmatatelné benefity. Navrhované řešení vychází z podrobné znalosti a posouzení stávajícího stavu a obsahuje konkrétní instrukce pro zajištění jeho realizace. Tyto instrukce jsou jak v rovině nutných změn legislativy tak i změny organizace a procesních postupů. Navržené řešení se věnuje všem složkám komplexního sociotechnického systému eHealth – technické, sociální i ekonomické. Návrh je postaven na intenzivním využití dat v informačních systémech zdravotních pojišťoven a nevyžaduje žádnou tvorbu nové národní databáze, obsahující osobní údaje. Uvažované řešení tak maximálně využívá stávající systémy. I funkce registru radiační zátěže je navržena formou doplnění údajů o radiační zátěži do informačních systémů zdravotních pojišťoven. Návrh tak není citlivý na verdikt Ústavního soudu ve věci osobních údajů shromažďovaných v Národních zdravotních registrech. Klíčovým aktérem v navrhovaném systému eHealth je pacient, který může stanovovat přístupová oprávnění ke své dokumentaci (s výjimkou emergentního datasetu). Na pacienta je cíleno také opatření spočívající v zavedení infrastruktury čipových karet, čteček a kvalifikovaných časových razítek, které má za cíl zvýšit právní validitu záznamů v elektronické zdravotnické dokumentaci. Jiný postup není v zájmu pacienta. Pacientům je dále dána do rukou možnost dálkově nahlížet na veškerou svou zdravotnickou dokumentaci, na kterou mají nárok podle zákona. Veškeré grafické uživatelské rozhraní jsou soustředěny do Portálu pacienta, zdravotnických pracovníků a poskytovatelů. Je doporučeno zavést systém federované identity na principu Single Sign-On, tak aby se omezila potřeba vytváření nových a nových databází registrovaných uživatelů a opětovného přihlašování v státním, komerčním i neziskovém sektoru. Portál obsahuje pro každou skupinu uživatelů část obecnou i personalizovanou. Návrh odpovídá principům eGovernmentu a využívá intenzivně jeho služeb – zejména Základních registrů, datových schránek, občanských průkazů s bezpečnostním osobním kódem. Díky návrhu realizace národního kontaktního místa v projektu epSOS pomocí již existujícího EESSI Access Pointu Centra mezistátních úhrad, lze využít stávajícího napojení na informační systémy zdravotních pojišťoven. Z jejich dat lze snadno zajistit konstrukci klíčových částí Souhrnných informací o pacientech v systému epSOS za minimální náklady. Návrh nastavuje směr k sémanticky interoperabilnímu eHealth. Pro řešení sdílení na národní úrovni navrhuje využít stejných postupů jako pro přeshraniční sdílení a tak ušetřit na potřebě údržby dvou duplicitních rozhraní. Pro nově vytvářená rozhraní jsou navrženy mezinárodně akceptované technické standardy a nomenklatury. Díly využití normy openEHR lze vrátit kontrolu nad strukturou zdravotnické dokumentace do rukou zdravotníků. Dlouhodobým cílem je možnost využívat data z běžných zdravotních záznamů pro analytické a statistické postupy. Na závěr návrhu jsou uvedeny doporučení k postupům projektového řízení, zajištění kvality a PR aktivitám, které jsou klíčové pro zajištění hladké implementace, zprovoznění a široké akceptace systému eHealth.

6 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2

Mapování stávajícího stavu systémů vycházejících z principů elektronizace zdravotnictví

2.1

Představení systému zdravotnictví s ohledem na využití ICT technologií

Systém zdravotnictví v každém státě je velmi komplexní. Česká republika používá ve svém zdravotnictví koncept zdravotních pojišťoven a zdravotnictví tak není řešeno formou Národní zdravotní služby jako je tomu například ve Velké Británii či skandinávských zemích. To má své výhody i nevýhody. Mezi hlavní nevýhody systému zdravotnictví založeného na zdravotních pojišťovnách patří v rovině zavádění ICT technologií zejména obtížné prosazení direktivních kroků jiným způsoben než jejich zákonným stanovení. Prakticky každý významnější proces prochází přes několik aktérů s různými zájmy a motivacemi a s rozdílnou úrovní ICT podpory daného procesu. Z tohoto důvodu, je vhodné dívat se z hlediska využití ICT technologií na jednotlivé hlavní skupiny aktérů samostatně.

2.1.1

Pacienti

Jedním z klíčových aktérů systému zdravotnictví je pacient jakožto konečný spotřebitel a v roli plátce daně a zdravotního pojištění či samoplátce také i definitivní zákazník a plátce všech složek systému. V konečném důsledku bude i z jeho daní financován přímo či nepřímo vlastní národní systém eHealth. Žádný systém elektronického zdravotnictví proto nemůže pacienty ignorovat, ale všechny služby by v konečném důsledku měly sloužit k jeho prospěchu. Tento benefit může být jednak finanční anebo i nefinanční v podobě zvýšené kvality a bezpečnosti poskytovaných služeb. O využití ICT prostředků touto skupinou aktérů nám podává podrobný přehled Český statistický úřad, z nichž uvádíme stručný výběr.

Graf 1 Vybavenost domácností počítačem (počet PC na 100 domácností) - ČSÚ, Statistiky rodinných účtů

Graf 2 Vybavenost domácností telefonem (% z celkového počtu domácností) - ČSÚ, Statistiky rodinných účtů

7 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Tabulka 1 Procento jednotlivců používající mobilní telefon - ČSÚ

Tabulka 2 Jednotlivci používající internet k vyhledávání vybraných informací (%), 2. čtvrtletí 2009 – ČSÚ

Jak je vidět z výše uvedených ukazatelů, je vybavenost ICT technologiemi poměrně vysoká. V roce 2009 mělo osobní počítat 72% domácností a mobilní telefon měl ve věkové skupině od 16 do 54 let prakticky každý. Naproti tomu však internet používalo k vyhledání informací o zdraví 48% žen a pouze 20% mužů z celkových uživatelů internetu. Z hlediska vybavenosti PC byly české domácnosti v rámci 27 zemí EU v roce 2009 podprůměrné, z hlediska počtu aktivních SIM karet bylo však ČR nad průměrem EU27. Od zahájení provozu začátkem července 2009 do konce března 2012 bylo v ISDS zřízeno celkem 461.693 datových schránek a z toho 5% (24.452) na nepodnikající fyzické osoby a další 3% (15.577) na podnikající fyzické osoby. Certifikační autorita České pošty PostSignum v roce 2011 vydala celkem 130.272 kvalifikovaných digitálních certifikátů dle zákona č. 227/2000 Sb., o elektronickém podpisu. Zbylé dvě akreditované certifikační autority I.CA a eIdentity nepublikují počty vydaných certifikátů v jednotlivých letech, nicméně lze odhadovat celkový počet platných kvalifikovaných digitálních certifikátů mezi 300 a 400 tisíci. Z hlediska nové legislativy má dále každý občan ČR, bez ohledu na datum vydání svého občanského průkazu, možnost si zvolit ke svému občanskému průkazu bezpečnostní osobní kód (BOK), se kterým se v koncepci eGovernmentu počítá jako s obdobou PIN u platebních karet.

8 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Graf 3 Vybavenost počítačem v domácnostech Evropské unie (% z celkového počtu domácností v dané zemi) – Eurostat

Graf 4 Počet aktivních SIM karet (na 100 obyvatel dané země) - ITU (International Telecommunication Union)

9 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Kromě jednotlivých pacientů lze do této skupiny aktérů zařadit i jejich sdružení, založená obvykle na určité „diagnóze“ (diabetes, bechtěrevova choroba, atd. ) a média. Tato sdružení v dnešní době obvykle nedisponují nějakými významnými vlastními datovými zdroji či „registry“ a při své činnosti tak mohou vycházet pouze z veřejně dostupných informačních zdrojů či informací, které jim ostatní aktéři na vyžádání poskytnou.

2.1.2

Zdravotničtí pracovníci

Počítačovou gramotnost u zdravotnických pracovníků lze odvodit jako obdobnou u celkové populace se zohledněním specifik každé věkové skupiny. Prevalující názor o apriori odmítavém postoji zdravotníků je dán dvěma hlavními důvody. Prvním je ten že jej obvykle vyslovují lidé, kteří mají k výpočetní technice blízko, a proto zdravotníky vidí vždy jako relativně méně angažované v oblasti ICT. Druhým důvodem je ten, že práce většiny zdravotníků v klinické oblasti je zaměřená na konkrétní úkony na samotném pacientovi a administrativu vnímají spíše jako nutné zlo. Většina komerčně dostupných řešení až do nedávné doby ale neumožňovala dostatečně ergonomické využití ICT přímo při klinické práci zdravotníka, protože její povaha je odlišná od běžné „kancelářské“ administrativy. Způsob informační podpory klinických procesů v uplynulém desetiletí vycházejí z tehdy dostupných možností tak nutně vedl k určité skepsi k ICT řešením z pohledu zdravotníků. Lze očekávat, že rozvoj mobilních a specificky zaměřených zdravotnických informačních technologií tyto postoje změní. Kromě jednotlivých zdravotníků jsou významnými aktéry systému zdravotnictví odborná sdružení a profesní komory. Stomatologická, lékařská i lékárnická komora jsou zřízeny ze zákona, podle kterého mají za povinnost vést i seznamy svých členů, kteří jsou tak oprávnění praktikovat v ČR. Všechny tři komory na svých webových stránkách umožňují vyhledávání v seznamech svých členů a stomatologická a lékárnická komora také publikuje i vazbu svých členů na konkrétní poskytovatele zdravotních služeb (stomatologické ordinace a lékárny). Dle aktuální legislativy formulované zákonem č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, mají nově komory povinnost komunikovat seznamy svých členů do NZIS. Odborná sdružení lékařů i nelékařů reprezentovaná zejména Českou lékařskou společností Jana Evangelisty Purkyně (ČLS JEP) a Českou asociací sester (ČAS) disponují kromě neveřejných seznamů svých členů zejména specializovanými registry, obvykle zaměřenými na konkrétní odborný problém. ČAS tak vede „registr pádů“, Transfuziologická společnost ČLS JEP shromažďuje hlášení činností z transfuzních stanic a podobně. Tyto datové zdroje však obvykle neobsahují osobní informace pacienta, protože získávání jeho informovaného souhlasu s takovýmto zpracováním by bylo často velmi obtížné. Při své činnosti tak musí tato sdružení své interní datové zdroje doplnit veřejně dostupnými informačními zdroji a informační technologie využívají zejména pro publikaci svých výstupů.

2.1.3

Poskytovatelé zdravotních služeb

Poskytovatelé péče jsou relativně heterogenní skupinou, a proto jsou níže samostatně uvedeni z hlediska elektronizace zdravotnictví nejvýznamnější skupiny poskytovatelů zdravotních služeb.

2.1.3.1 Samostatné ordinace Historickým vývojem vznikl v ČR vysoký počet samostatných ordinací, kde zdravotní služby v oblasti zejména praktického lékařství (pro dospělé či děti a dorost) či jiných specializovaných odborností poskytuje jeden lékař a jeho sestra. Dle údajů ÚZIS jich bylo v ČR v roce 2011 celkem 20.121. Tento model není na západ od nás tak běžný a má mnohé dopady v různých oblastech organizace zdravotnictví.

10 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Graf 5 Procento ordinací lékařů používajících počítač pro vedení zdravotnické dokumentace - ÚZIS

Dle údajů ÚZIS z roku 2010 jsou samostatné ordinace vybaveny počítači v 97% a internetem v 79%. Ne vždy je však počítač používán pro vedení zdravotnické dokumentace a ta tak nemusí být vždy dostupná v elektronické podobě. V oblasti informačních systémů samostatných ambulancí vznikl postupnými akvizicemi praktický monopol jednoho výrobce, jehož několik produktových řad dohromady tvoří více než dvě třetiny všech softwarových instalací ambulantního informačního software v tomto segmentu. Ambulantní informační software používají samostatné ordinace pro vedení zdravotnické dokumentace jejíž součástí je i vystavování receptů, žádanek, poukazů a podobně. Významnou agendou je také vykazování zdravotním pojišťovnám a tyto výkazy jsou následně osobně, korespondenčně nebo přes internet předávány v obvykle měsíčních dávkách ve formátu stanoveného datového rozhraní na zdravotní pojišťovnu. V případě použití portálů zdravotních pojišťoven je pro předání dávek obvykle nutný elektronický podpis. Nově je možné podávat dávky také přes datovou schránku, ale tento způsob komunikace aktuálně nenabízí srovnatelné funkce, jako je například online kontrola dávky. Elektronický podpis dle zákona č. 227/2000 Sb., o elektronickém podpisu, je legislativou vyžadován také pro vedení čistě elektronické formy záznamů ve zdravotnické dokumentaci. Vedení zdravotnické dokumentace v čistě elektronické formě není však pravidlem ani u lékařů vlastnících elektronický podpis a všechny záznamy se tak v ordinaci musí obvykle tisknout a zakládat do papírové kartotéky.

2.1.3.2 Nemocnice, odborné léčebné ústavy a lázně Dle údajů ÚZIS bylo v roce 2011 v ČR celkem 189 nemocnic s 60.336 lůžky, 160 odborných léčebných ústavů (LDN, psychiatrické léčebny, rehabilitační ústavy, hospice a další) s 21.672 lůžky a 88 lázní s 26.835 lůžky. Ve většině těchto zdravotnických zařízení je dnes již zaveden klinický informační systém (KIS) nazývaný někdy také nemocniční informační systém (NIS). Klinický informační systém obvykle obsahuje minimálně agendy vedení registru pacientů, administrace lůžek, lékařské zdravotnické dokumentace, předávání žádanek a výsledků konzilií a vykazování zdravotním pojišťovnám. Tento systém může obsahovat i další součásti (objednávací systém, dopravní zdravotní službu, apod.), nicméně dříve běžný monolitický NIS, obsahující všechny agendy nemocnice včetně neklinických, dnes již v ČR nalézt nelze. Poskytovatelé v tomto segmentu nyní provozují obvykle více specializovaných informačních systémů. Samostatné jsou obvykle informační systémy pro ekonomiku, personalistiku, skladové hospodářství či stravování a různé intranetové informační služby. Specializované informační systémy pro komplement a lékárnu jsou také obvykle samostatné (viz níže). Není však výjimkou ani stav, kdy jedna nemocnice používá na různých svých odděleních různý informační systém pro základní klinické agendy a tyto oddělení pak spolu elektronicky nejsou propojeny. Nebývá úplným pravidlem ani jiná integrace se specializovanými informačními systémy uvnitř nemocnice, jako je například elektronická komunikace žádanek a výsledků s nemocniční laboratoří. Ve výsledku se pak mnoho klinických procesů neobejde bez papírového zpracování. Papír je nezbytný i v případě, že poskytovatel nevede čistě elektronickou zdravotnickou dokumentaci a je tedy nutné všechny záznamy tisknout a zakládat do papírové dokumentace. Velké rezervy mají lůžková zdravotnická zařízení v elektronizaci ošetřovatelské dokumentace, která

11 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ je většinou vedena primárně papírově. Ošetřovatelské procesy však představují v některých oborech až 80% úkonů na pacientovi a elektronizací této oblasti by tak bylo možné přinést významné pozitivní efekty. V tomto segmentu patří k nejvýznamnějším 8 informačních systémů od 6 výrobců. Některé nemocnice si však zajišťují vývoj a provoz KIS zcela ve vlastní režii. Trh v oblasti informačních systémů pro psychiatrické léčebny je prakticky monopolizován jediným výrobcem pokrývajícím 90% softwarových instalací v těchto léčebnách. V lázeňství lze nalézt 3 významné dodavatele informačních systémů. Níže je v tabulce uveden souhrn závěrů studie „ICT ve velkých nemocnicích“, kterou publikoval v roce 2010 časopis CIO Business World. Tato studie byla realizována již potřetí na obdobném vzorku jako v roce 2001 a 2005. Do studie zahrnuto 11 nemocnic přímo řízených Ministerstvem zdravotnictví, Městská nemocnice Ostrava (největší tuzemskou městská nemocnice), severočeská Krajská zdravotní (jež se zrodila z fúze nemocnic v Děčíně, Chomutově, Mostě, Teplicích a Ústí nad Labem), a v neposlední řadě též skupina Agel, která v ČR provozuje síť více než dvaceti nemocnic a poliklinik. Indikátor Počet pracovníků Počet koncových stanic Počet tiskových periferií Počet lůžek Celkové náklady na ICT Celkový obrat Počet koncových stanic na jednoho pracovníka Počet tiskových periferií na jednoho pracovníka Průměrné náklady na ICT na jednoho pracovníka Průměrné náklady na ICT na jednu koncovou stanici Průměrné náklady na jedno lůžko Podíl nákladů na ICT na obratu Obrat přepočtený na jednoho pracovníka

Hodnota 66 000 38 600 25 700 neuvedeno 1 000 000 000 Kč 77 000 000 000 Kč 0,58 0,39 15 152 Kč 25 907 Kč neuvedeno 1,30% 1 166 667 Kč

Tabulka 3 ICT ve velkých nemocnicích - CIO Business World (2010)

2.1.3.3 Lékárny V ČR bylo dle údajů ÚZIS v roce 2011 celkem 2.670 lékáren a 338 výdejen zdravotnických prostředků. Vzhledem ke komplexnosti legislativy v oblasti stanovení ceny léčiv a obratu zboží si již lékárnu bez informačního systému prakticky nelze představit. Zavedení internetu do lékáren pro veřejnost si pak definitivně vynutila aplikace pokynu SÚKLu LEK-13 o hlášení výdeje léčiva na papírový recept. Online spojení je rovněž nezbytné pro komunikaci s Centrálním úložištěm elektronických receptů, do kterého je dle údajů SÚKLu zapojeno 1.588 lékárníků v 652 lékárnách. Největší distributoři léčiv poskytují i dodací listy v elektronické podobě a elektronicky lze předat i výkazy pro zdravotní pojišťovnu. Tato oblast sortimentu v lékárnách pro veřejnost tedy již dnes umožňuje prakticky kompletní bezpapírové vyřízení dále podpořené čárovými kódy na obalech léčiv. V oblasti lékáren pro veřejnost dominuje 5 informačních systémů od 3 výrobců, které jsou funkčně prakticky ekvivalentní a tvoří cca 90% softwarových instalací v tomto segmentu. Poněkud komplikovanější situace je u ústavních lékáren, poskytujících léky na žádanky do příručních skladů klinickým oddělením. Dle studie provedené Sekcí nemocničních lékárníků, která je odbornou sekcí České farmaceutické společnosti ČLS JEP, není možné v 19% nemocničních lékáren vyřídit žádanku jinak než papírově. Tyto lékárny často poskytují také specializované služby, jako je příprava cytostatik, které mohou být řešeny samostatným SW. Oligopol tří největších výrobců není u ústavních lékáren tak výrazný, protože dohromady mají dle výše uvedené studie cca polovinu trhu.

12 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2.1.3.4 Laboratoře Provoz klinických laboratoří je v dnešní době vysoce automatizován a jeho řízení proto vyžaduje implementaci informačního systému. Žádanku i výsledek lze efektivně komunikovat prostřednictví Datového standardu Ministerstva zdravotnictví (DASTA), nicméně jeho použití není někde realizováno ani pro předávání údajů v rámci jedné nemocnice. V rámci laboratoří se dále používají čárové kódy pro identifikaci vzorků, nicméně obvykle jsou jimi vzorky opatřeny až na příjmu materiálu v laboratoři. Použití tzv. transportních čárových kódů, kterými by byl vzorek opatřen již od okamžiku odběru na klinickém oddělení, je v ČR realizována na několika málo pracovištích. Segmentu laboratoří dominují v ČR 4 výrobci informačních systémů.

2.1.3.5 Pracoviště zobrazovacích modalit (RTG, CT, NMR, …) Zpracování žádanky na zobrazovací vyšetření a případně i kalendář objednacího systému je obvykle v nemocnicích součástí základního klinického informačního systému. Systém pro archivaci snímků (PACS) však obvykle bývá oddělen a jeho služby jsou dostupné pomocí standardního rozhraní DICOM. Nezřídka je proto i odlišný dodavatel DICOM prohlížeče snímků a vlastního PACS. Kromě PACS v dané nemocnici lze získat snímek také z PACS jiné nemocnice pomocí jednoho ze zavedených systémů pro výměnu obrazové dokumentace. Jde o systémy ePACS (centrální uzel ve Všeobecné fakultní nemocnici v Praze) a ReDiMed (centrální uzel v Masarykově univerzitě v Brně). Oba jsou funkčně přibližně ekvivalentní, nicméně technologicky odlišné a v každém je zapojeno cca 200 pracovišť. Segmentu PACS dominují v ČR 4 výrobci.

2.1.3.6 Záchranná služba Informační systémy záchranných služeb jsou zaměřeny na služby telefonického dispečinku, plánování směn a vykazování pojišťoven. Telefonický dispečink obvykle využívá služby geografického informačního systému (GIS) pro zajištění co nejkratší dojezdové doby. V některých krajích se používá v terénu mobilní náhled na emergentní informace o pacientovi nebo záznam dokumentace o výjezdu v elektronické podobě. Předávání dokumentace v elektronické podobě do klinického informačního systému nemocnice však není dosud v ČR implementováno. V segmentu záchranných služeb lze najít pouze jednoho významnějšího dodavatele informačního systému ve formě hotového produktu, jinak jde o zakázková řešení.

2.1.4

Zdravotní pojišťovny

Zdravotní pojišťovnu bez informačního systému v ČR provozovat nelze. V poslední době probíhá v řadě pojišťoven (například VZP, OZP a VoZP) radikální modernizace jejich základního informačního systému. I tato modernizace je však poplatná stávajícím metodickým postupům vykazování poskytnutých zdravotních služeb, které je zavedeno obvykle na měsíčním dávkovém principu s většinovou poskytovatelů už od počátku 90tých let. Technická realizace předávání dat je však dnes již pokročilejší a portály zdravotních pojišťoven poskytují B2B služby pro výkaznictví i další oblasti. Některé zdravotní pojišťovny se rozhodly zpřístupnit svým pojištěncům a smluvním poskytovatelům zdravotních služeb data o výkazech ze svých systémů. Tyto systémy (například Karta Života ZPMVČR a ČPZP nebo VitaKarta OZP) jsou založeny na webových portálech, které zobrazují oprávněnému uživateli informace odvozené z dříve předaných výkazů o poskytnuté zdravotní péči. Z těchto výkazů je tak možné získat data o lécích vydaných na recept, realizovaných výkonech, diagnózách, navštívených poskytovatelích, očkování. Dále jsou v systémech zdravotních pojišťoven obsaženy identifikační údaje pojištěnce a informace o zaměstnavateli či zaplaceném zdravotním pojistném, které vypovídají i o socioekonomickém stavu pojištěnce. Některé zdravotní pojišťovny dále realizují nad svými daty analýzy pro interní potřebu, z nichž některé zpřístupňují dále poskytovatelům zdravotních služeb, kteří jsou původci daných dat. Jde zejména o analýzy interakcí léčiv dle vydaných léčiv na recept anebo tzv. klinicko-ekonomické profily. Vedle těchto inciativ existuje ještě systém elektronických zdravotních knížek, který pro VZP dodává společnost IZIP. Tento systém je zaměřen primárně na předávání výpisů ze zdravotnické dokumentace pacientovi a sdílení těchto záznamů mezi lékaři je pouze vedlejším efektem. Sdílené záznamy v rámci EZK by sice měly být i plnotextové, obsahující klinickou informaci, ale nemají právní závaznost a navíc jsou díky volné textové formě

13 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ nejsou sémanticky interoperabilní. Technicky je systém založen na dobrovolném předávání záznamů ošetřujícími lékaři ve formátu DASTA do centrální databáze a jejich následném zpřístupnění pacientovi a jím určeným zdravotnickým pracovníkům přes webové grafické uživatelské rozhraní. Kromě toho EZK obsahuje i funkce předávání výpisu z osobního účtu pojištěnce tak jako je tomu u jiných obdobných projektů zdravotních pojišťoven. Pro komunikaci s okolím dále zdravotní pojišťovny využívají své portály. Menší zdravotní pojišťovny využívají služeb Portálu ZP. Tento portál je určen primárně pro offline podání s využitím elektronického podpisu pro dokumenty typu výkazů, žádostí o výpis z účtu či dalších podkladů od zaměstnavatelů a OSVČ. Vzhledem k možnosti realizace offline podání v systému datových schránek je pravděpodobné, že význam Portálu ZP bude v budoucnu klesat. Již dnes si navíc pojišťovny vytvářejí vlastní portály zaměřené na online komunikaci. Při posuzování zdravotních pojišťoven jako skupiny aktérů nelze opomenout z hlediska zdravotnické informatiky dvě významné instituce, které fungují na právním základě sdružení právních osob a jejichž provoz zdravotní pojišťovny významně ovlivňují. Jedná se o Centrum mezistátních úhrad a Národní referenční centrum. Centrum mezistátních úhrad (CMÚ) nyní dokončuje implementaci svého Access Pointu pro evropskou síť výměny informací o sociálním zabezpečení (EESSI). Tento Access Point umožní nahradit stávající formuláře pro mezistátní přeúčtování se členskými státy EU (a případně dalšími státy na základě bilaterálních dohod) poskytnutých zdravotních služeb a související dokumenty a nárokové doklady jejich elektronickými ekvivalenty. Tyto strukturované elektronické dokumenty budou přenášet relevantní informace ve formě umožňující jejich strojové zpracování. Národní referenční centrum (NRC) provádí v ČR zejména kultivaci systému DRG ke které využívá anonymizovaná data předávaná jednotlivými zdravotními pojišťovnami i data přímo od poskytovatelů zdravotních služeb. Kromě toho NRC realizuje i další činnosti, mezi něž patří zejména provoz clearingového centra pravidelného očkování, sledování dekubitů, údržba národní sady ukazatelů kvality a národní sady standardů zdravotních služeb, systemizace přístrojové techniky, údržba registru referenčních hodnot a jiné projekty. Z hlediska plateb pojistného byl zákonem č. 458/2011 od 1.1.2015 naplánován přechod na tzv. jednotné inkasní místo, přičemž je možné že účinnost bude ještě upravena na 1.1.2014. Jednotné inkasní místo přenáší kompetence k výběru pojistného na sociální a zdravotní pojištění na finanční úřady. Vymáhací procesy však budou muset zůstat ve zdravotních pojišťovnách nadále v běhu například pro tzv. regresy, tedy situace kdy při poškození zdraví třetí osobou vymáhá zdravotní škoda náklady na léčení po viníkovi (např. dopravní nehody).

2.1.5

Státní správa

Státní správa určuje nejen celkové směřování systému pomocí zákonů a vyhlášek, ale významným způsobem může ovlivňovat i velkou část zdravotních pojišťoven a poskytovatelů zdravotních služeb. Ministerstvo zdravotnictví a další centrální orgány jsou zřizovateli celkem 24 nemocnic, které tvoří 30% celkového lůžkového fondu všech nemocnic ČR. Kromě toho je Ministerstvo zřizovatelem 14 psychiatrických léčeben, které provozují 96% psychiatrických lůžek a spolu s dalšími centrálními orgány je zřizovatelem dalších 156 zdravotnických zařízení. Dále řídí síť orgánů ochrany veřejného zdraví. Státními orgány jsou dále řízeny celkem tři zdravotní pojišťovny, konkrétně VZP, VoZP a ZPMVČR, které jsou dohromady plátci zdravotních služeb za cca 80% pojištěnců v ČR. Ministerstvo zdravotnictví dále řídí Státní ústav pro kontrolu léčiv, který provádí zejména registrace a stanovení úhrad léčiv ze zdravotního pojištění a provozuje centrální úložiště elektronických receptů a realizuje i další sběr dat od regulovaných subjektů v oblasti trhu s léčivy, krevními přípravky a zdravotnickými prostředky. Dalšími významnými přímo řízenými organizacemi Ministerstva zdravotnictví jsou vzdělávací instituce - Národní centrum ošetřovatelství a nelékařských zdravotnických oborů a Institut postgraduálního vzdělávání ve zdravotnictví. Nejvýznamnější roli v oblasti zdravotnické informatiky na celonárodní úrovni hraje Národní zdravotnický informační systém (NZIS), jehož úloha je definována v zákoně č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) v § 70 odst. 1. NZIS je jednotný celostátní informační systém, určený: 



ke zpracování údajů o zdravotním stavu obyvatelstva, o činnosti poskytovatelů a jejich ekonomice, o zdravotnických pracovnících a jiných odborných pracovnících ve zdravotnictví za účelem získání informací o rozsahu a kvalitě poskytovaných zdravotních služeb, pro řízení zdravotnictví a tvorbu zdravotní politiky, k vedení Národních zdravotních registrů a zpracování údajů v nich vedených,

14 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“    

k vedení Národního registru poskytovatelů a Národního registru zdravotnických pracovníků a zpracování údajů v nich vedených, k realizaci a zpracování výběrových šetření o zdravotním stavu obyvatel, o determinantách zdraví, o potřebě a spotřebě zdravotních služeb a spokojenosti s nimi a o výdajích na zdravotní služby, pro potřeby vědy a výzkumu v oblasti zdravotnictví, a ke zpracování údajů uvedených výše pro statistické účely a k poskytování údajů a statistických informací v rozsahu určeném tímto nebo jinými právními předpisy, včetně poskytování informací pro mezinárodní instituce.

Správou NZIS byl na základě pověření MZ pověřen Ústav zdravotnických informací a statistiky ČR (ÚZIS ČR) v souladu se základním účelem a předmětem jeho činnosti vyplývajícím ze Statutu ÚZIS ČR. Rozsah pověření je vymezen § 72 odst. 1, písm. a) až d) a f) zákona č. 372/2011 Sb., o zdravotních službách. ÚZIS ČR je též součástí státní statistické služby a tuto činnost vykonává podle zákona č. 89/1995 Sb., o státní statistické službě, ve znění pozdějších předpisů. ÚZIS ČR při nakládání s osobními údaji NZIS zajišťuje úkoly v souladu se zákonem č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších předpisů. Provoz a správu centrálních registrů tak zajišťuje Ústav zdravotnické informatiky a statistiky (ÚZIS) a Koordinační středisko pro resortní zdravotnické informační systémy (KSRZIS), přičemž obvyklé rozdělení kompetencí je takové, že KSRZIS řeší víceméně technickou stránku věci a je technickým provozovatelem a z hlediska terminologie zákona na ochranu osobních údajů vystupuje v roli zpracovatele osobních údajů. Věcným uživatelem dat těchto registrů a správcem osobních údajů je pak ÚZIS. Kromě těchto registrů dále ÚZIS provozuje informační systémy plněné daty z Českého statistického ústavu (porodnost, úmrtnost, bilance obyvatel) a České správy sociálního zabezpečení (pracovní neschopnosti). Další registry související s transplantačním programem ČR vede Koordinační středisko transplantací a do surveillance infekčních chorob a antibiotické rezistence provádí Státní zdravotní ústav pomocí svých informačních systémů, respektive registrů orgánů ochrany veřejného zdraví. Níže uvedené popisy registrů jsou převzaty z webu ww.uzis.cz.

2.1.5.1 Národní zdravotní registry Do roku 2002 byla individuální hlášení zařazena do Programu statistických zjišťování Ministerstva zdravotnictví, který je součástí Programu statistických zjišťování vyhlašovaného Českým statistickým úřadem. V roce 2002 zřídilo Ministerstvo zdravotnictví ČR Národní zdravotní registry na základě zmocnění v zákoně č. 20/1966 Sb., o péči o zdraví lidu, v platném znění. U vyhlášených registrů byly uveřejněny informace o účelu a jejich zdůvodnění, o výkonných orgánech registru a jejich kompetenci a o Radě registru. V roce 2004 vstoupila v platnost novela tohoto zákona, která konkrétně uvedla třináct Národních zdravotních registrů a vymezila osobní a další údaje, které lze bez souhlasu subjektu údajů v registrech zpracovávat. V roce 2006 byl další novelou zákona rozšířen počet registrů o Národní registr asistované reprodukce. Národní zdravotní registry vznikly převážně z iniciativy odborných lékařských společností, které stanovily odbornou náplň. O každý národní zdravotní registr se stará určená státní instituce, tzv. správce registru, který garantuje metodickou a obsahovou jednotu registru a jeho účel. Poradním orgánem správce registru je Rada registru složená z reprezentantů navržených příslušnou odbornou lékařskou společností, zástupců MZ, pracovníků správce a případného zpracovatele. Příslušná odborná lékařská společnost je odborným garantem registru. Řada registrů má již dlouholetou tradici např. onkologický registr vznikl již v roce 1976 a registr hospitalizovaných v roce 1960. Účelem registrů je sledovat vývoj, příčiny a důsledky nejenom závažných onemocnění, a to včetně důsledků ekonomických, a jejich dopady do sociální sféry a ekonomiky sociálního systému, evidence a sledování pacientů, včetně zemřelých, s vybranými společensky závažnými nemocemi, sledování výskytu, vývoje, příčin a důsledků těchto nemocí a návaznosti další péče, a evidence a sledování pacientů s úrazy, a dále statistická a vědecká zpracování dat registrů zaměřená zejména na analýzy zdravotního stavu obyvatel a kvalitu a využívání zdravotní péče s cílem zlepšovat zdraví populace.

15 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Význam zdravotních registrů mimo jiné také spočívá v jejich možnosti monitorovat současné trendy v kvalitě poskytování zdravotní péče v celé ČR v porovnání s ostatními evropskými státy. Informace z registrů slouží pro databáze zdravotnických ukazatelů Eurostatu, Světové zdravotnické organizace (WHO), Organizace pro Evropskou spolupráci a rozvoj (OECD) a pro další mezinárodní srovnání. Dle nového zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách), který nahrazuje dosud platný zákon č. 20/1966 Sb. byl v oblasti Národních zdravotních registrů kodifikován de-facto stávající stav, a byly upřesněny podmínky provozování těchto registrů. Oproti zákonu č. 20/1966 Sb., je v novém zákonu uvedeno deset Národních zdravotních registrů. V zákonu č. 372/2011 Sb. byly některé registry zrušeny, některé sloučeny a jiné nově zavedeny. Nově zaváděné Národní zdravotní registry jsou Národní registr úrazů, Národní registr osob trvale vyloučených z dárcovství krve a Národní registr pitev a toxikologických vyšetření prováděných na oddělení soudního lékařství. Zrušen byl například Registr cévní chirurgie z důvodu nízké zpravodajské aktivity pracovišť, ve kterých byly provedeny cévní rekonstrukční operace. Níže je uveden aktuálně platný přehled Národních zdravotních registrů. :          

Národní onkologický registr (registr novelizován) Národní registr hospitalizovaných (registr beze změny) Národní registr reprodukčního zdraví (slučující dřívější registry rodiček, novorozenců, vrozených vad, potratů a asistované reprodukce) Národní registr kardiovaskulárních operací a intervencí (slučující Národní kardiochirurgický registr a Národní registr kardiovaskulárních intervencí) Národní registr kloubních náhrad (registr beze změny) Národní registr nemocí z povolání (registr beze změny) Národní registr léčby uživatelů drog (slučující Národní registr uživatelů lékařsky indikovaných substitučních látek a Registr žádostí o léčbu) Národní registr úrazů (nový registr) Národní registr osob trvale vyloučených z dárcovství krve (nový registr) Národní registr pitev a toxikologických vyšetření prováděných na oddělení soudního lékařství (nový registr)

Pro sběr dat do Národního registru hospitalizovaných a Národního registru reprodukčního zdraví se používá datový portál ÚZIS ČR, nazývaný „Centrální úložiště povinných hlášení“ zajišťující automatizovaný sběr elektronických dat ve formátu xml přímo do centrální databáze určené pro Národní zdravotní registry NZIS. Dále ÚZIS využívá pro předávání dat od zpravodajských jednotek Centrální úložiště výkazů a Registr ekonomických výkazů.

2.1.5.1.1 Národní onkologický registr (NOR) Statistickou jednotkou jsou všechna onemocnění ze skupiny diagnóz zhoubné novotvary (C00 - C97), novotvary in situ (D00 - D09), novotvary nejistého nebo neznámého chování (D37 - D48) a některé nemoci postihující lymforetikulární tkáň a retikulohistiocytární systém (D76.0) zjištěná u osob, bez ohledu na pohlaví a věk, se státním občanstvím ČR a u cizinců s povolením trvalého pobytu; zjištěná klinicky (i případy histologicky nebo cytologicky neověřené) nebo zjištěná při úmrtí. Zpravodajskou jednotkou jsou všechna zdravotnická zařízení, ve kterých bylo nádorové onemocnění diagnostikováno, léčeno (tiskopis „ Incidence a léčba zhoubného novotvaru) a dispenzarizováno (tiskopis „Kontrolní hlášení novotvaru“). Provoz registru je řízen následujícími závaznými předpisy a metodikou:     

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdější pozdějších předpisů NOR byl vyhlášen ve Věstníku MZ, částka 14, Ročník 2001 Výnos MZSV ČSR č. 3/1989 Věstníku MZSV ČSR (reg. ve Sbírce zákonů částka 19/1988) - Dispenzární péče o nemocné s přednádorovými stavy a novotvary a povinné hlášení novotvarů

16 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  

Závazné pokyny NZIS - Pokyny k obsahu datové struktury Datový standard MZ

Účelem Národního onkologického registru (dále jen NOR) je registrace onkologických onemocnění a periodické sledování jejich dalšího vývoje, tj. shromažďování dat, jejich verifikace, ukládání, ochrana a zpracování. NOR poskytuje souhrnné údaje pro statistické přehledy jak na národní, tak i mezinárodní úrovni, dále pro epidemiologické studie a zdravotnický výzkum. Údaje NOR slouží také k podpoře včasné diagnostiky a léčby novotvarů a přednádorových stavů, ke sledování trendů jejich výskytu, příčinných faktorů a společenských důsledků. Souhrnná data jsou podkladem pro tvorbu, realizaci a vyhodnocování preventivních zdravotnických programů a pro odhady potřebných finančních nákladů na zabezpečení komplexní onkologické péče. Anonymní individuální data mohou být poskytnuta pro epidemiologické studie a zdravotnický výzkum jen v souladu s platnými zákony a se souhlasem Rady NOR. NOR je členem IACR (Mezinárodní asociace onkologických registrů) v Lyonu, spolupracuje s Evropskou sítí onkologických registrů (ENCR) a udržuje kontakt s registry v zahraničí. NOR je nedílnou součástí komplexní onkologické péče. NOR je celoplošným populačním registrem, který navazuje na registr provozovaný v ÚZIS ČR od roku 1976. Od 1. ledna 2006 nastaly v organizaci sběru dat do Národního onkologického registru (NOR) významné změny. Změnil se obsah datové struktury pro NOR, včetně podkladu pro sběr a pořizování dat, kterým je nově upravené hlášení „Incidence a léčba zhoubného novotvaru“. Současně došlo i k významné změně v definici subjektu, který hlášení novotvaru vyplňuje. Na vyplňování hlášení se nyní budou podílet dvě zdravotnická pracoviště:  

zdravotnická pracoviště, která stanoví diagnózu (vyplní a předá do 1 měsíce od stanovení diagnózy) zdravotnická pracoviště, zodpovědná za léčbu (vyplní a předá do 8 měsíců od stanovení diagnózy)

Toto rozdělení umožňuje získat rychlý operativní přehled o incidenci novotvarů v České republice a na druhé straně získat úplnější a přesnější přehled o léčbě těchto novotvarů. NOR je provozován jako webová aplikace s centrální databází. Spádová pracoviště NOR vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce registru. V registru se evidují následující údaje:   1. 2. 3. 4.

Údaje související se zdravotním stavem pacienta ve vztahu k jeho onemocnění a léčbě Údaje o sledovaném onemocnění

Údaje o způsobu léčby onemocnění Údaje o úmrtí pacienta Informace o dalším sledování pacienta Informace o zdravotnických zařízeních podílejících se na léčbě

2.1.5.1.2 Národní registr kloubních náhrad (NRKN) Statistickou jednotkou je provedená operace s užitím umělé kloubní náhrady. Zpravodajskou jednotkou je každé zdravotnické zařízení, ve kterém byla pacientovi provedena implantace umělé kloubní náhrady. Provoz registru je řízen následujícími závaznými předpisy:  

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému

17 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  

Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů NRKN byl vyhlášen ve Věstníku MZ, částka 6, Ročník 2002

Účelem zjišťování požadovaných údajů je registrace údajů o pacientech léčených formou operace s užitím endoprotézy a specifických informací blíže upřesňujících tuto léčbu (např. typ, velikost, specifikace povrchu endoprotézy, použití cementu, výskyt komplikací). Národní registr kloubních náhrad (dále jen NRKN) poskytuje souhrnné údaje pro statistické přehledy jak na národní úrovni, tak i pro mezinárodní srovnávání, pro epidemiologické studie a zdravotnický výzkum. Poskytuje také informace o vlastnostech použitých implantačních materiálů především z hlediska jejich životnosti a nákladů na tyto materiály. Souhrnná data jsou podkladem pro tvorbu, realizaci a vyhodnocování preventivních zdravotnických programů a pro odhady potřebných finančních nákladů na zabezpečení komplexní ortopedické péče. Anonymizovaná data mohou být poskytnuta pro epidemiologické studie a zdravotnický výzkum. Od konce roku 2003 je NRKN provozován jako webová aplikace s centrální databází. Pověřená zdravotnická pracoviště NRKN vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce registru. V registru se evidují následující údaje:  

Údaje o provedené operaci Údaje o reoperacích

2.1.5.1.3 Národní registr hospitalizovaných (NRHOSP) Statistickou jednotkou podléhající povinnému hlášení je ukončená hospitalizace pacienta (včetně cizinců) na jednom lůžkovém oddělení zdravotnického zařízení bez ohledu na způsob přijetí a ukončení (propuštění, překlad, úmrtí). Do NRHOSP nepatří jednodenní péče (jednodenní chirurgie) – to je ambulantní péče. Zpravodajskou jednotkou je každé zdravotnické zařízení ústavní péče s výjimkou lázeňských léčeben a ozdravoven, ve kterém došlo k ukončení poskytování ústavní péče pacientovi. Provoz registru je řízen následujícími závaznými předpisy a metodikou:      

 

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů. NRHOSP byl vyhlášen ve Věstníku MZ, částka 14, Ročník 2001 Mezinárodní statistická klasifikace nemocí a přidružených zdravotních problémů- desátá revize - zkráceně označovaná jako MKN-10. Klasifikace hospitalizovaných pacientů IR-DRG (International Refined Diagnosis Related Groups Mezinárodní zpřesněné skupiny vztažené k diagnóze), s účinností od 1. 1. 2006 (Sdělení ČSÚ č. 323/2010 Sb., o aktualizaci Klasifikace hospitalizovaných pacientů (IR-DRG), každý rok je IR-DRG aktualizováno a ČSÚ vydává nově aktualizované Sdělení) Závazné pokyny NZIS - Pokyny k obsahu datové struktury - Národní registr hospitalizovaných Datový standard MZ

Účelem zjišťování požadovaných údajů je získání zdroje informací o zdravotním stavu populace. Národní registr hospitalizovaných současně poskytuje podklady pro kvalitativní a kvantitativní hodnocení činnosti jednotlivých lůžkových zařízení a jejich oddělení.

18 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Data z NRHOSP jsou důležitým nástrojem pro řízení zdravotnictví a stanovení koncepce a realizace zdravotní politiky státu, potřebné k definování optimální sítě lůžkových zdravotnických zařízení. Výsledné informace z NRHOSP se předávají do databáze Světové zdravotnické organizace (WHO) a dalším mezinárodním organizacím podle smluvních závazků. NRHOSP je celoplošným populačním registrem, který navazuje na Informační systém Hospitalizace provozovaný v ÚZIS ČR od roku 1960. V NRHOSP jsou evidovány osoby, které byly hospitalizované na lůžkových odděleních a jejichž hospitalizace byla ve sledovaném období ukončena. Sběr za všechna oddělení lůžkových zařízení proběhl poprvé v roce 1981 a následně v roce 1986. Data jsou každoročně zpracovávána od roku 1992 a od roku 1994 nahradila v evidenci základních hospitalizačních diagnóz devátou revizi Mezinárodní klasifikace nemocí MKN-10. Do roku 1997 byla sbírána data za lůžková zařízení bez zdravotnických zařízení ostatních centrálních orgánů (dopravy, obrany a spravedlnosti), která do té doby data neposkytovala. V registru se evidují následující údaje:   

Údaje o lůžkovém zdravotnickém zařízení (zpravodajské jednotce) Údaje o pacientovi Údaje týkající se přijetí a pobytu pacienta v zařízení ústavní péče

2.1.5.1.4 Národní registr nemocí z povolání (NRNP) Statistickou jednotkou je každé zjištěné nově vzniklé a uznané onemocnění z povolání u osob v pracovním poměru k zaměstnavateli se sídlem na území České republiky. Případy nemocí z povolání jsou zařazovány dle evidenčních kódů seznamu nemocí z povolání. Aktualizovaný seznam evidenčních kódů je uveden v příloze publikace, kterou vydává od roku 2009 SZÚ. Hlášení o uznání nemoci z povolání/ohrožení nemocí z povolání zasílá do NRNP středisko nemocí z povolání podle vyhlášky č. 342/1997 Sb., ve znění pozdějších předpisů. Aktuální seznam středisek je součástí závazných pokynů k NRNP. Provoz registru je řízen následujícími závaznými předpisy a metodikou:              

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů Vyhláška č. 342/1997 Sb., kterou se stanoví postup při uznávání nemocí z povolání a vydává seznam zdravotnických zařízení, která tyto nemoci uznávají, ve znění pozdějších předpisů Nařízení vlády č. 290/1995 Sb., kterým se stanoví seznam nemocí povolání (konec účinnosti k 31. 12. 2012) Zákon č. 266/2006 Sb., o úrazovém pojištění zaměstnanců, Příloha č. 1, Seznam nemocí z povolání (účinnost od 1. 1. 2013) Zákon č. 258/2000 Sb., o ochraně veřejného zdraví a o změně některých souvisejících zákonů, ve znění pozdějších předpisů Vyhláška č. 432/2003 Sb., kterou se stanoví podmínky pro zařazování prací do kategorií, limitní hodnoty ukazatelů biologických expozičních testů, podmínky odběru biologického materiálu pro provádění biologických expozičních testů a náležitosti hlášení prací s azbestem a biologickými činiteli Nařízení vlády č. 361/2007 Sb., kterým se stanoví podmínky ochrany zdraví zaměstnanců při práci, ve znění pozdějších předpisů. Metodický návod č. 5/2008 Věstníku MZ, k zajištění jednotného postupu při ověřování podmínek vzniku onemocnění pro účely posuzování nemocí z povolání a ohrožení nemocí z povolání Směrnice Rady č. 89/391/EHS ze dne 12. června 1989 o zavádění opatření pro zlepšení bezpečnosti a ochrany zdraví zaměstnanců při práci, ve znění pozdějších předpisů Usnesení Evropského parlamentu č. 2009/C 41 E/03 ze dne 15. ledna 2008 o strategii Společenství pro bezpečnost a ochranu zdraví při práci na období 2007-2012 (2007/2146(INI)) Nařízení č. 1338/2008 Evropského parlamentu a Rady z 16. prosince 2008 o statistice Společenství v oblasti veřejného zdraví a ochrany zdraví a bezpečnosti při práci Závazné pokyny NZIS - Pokyny k obsahu datové struktury

19 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Účelem zjišťování požadovaných údajů je získávání informací o nemocech z povolání jako podklad pro tvorbu národní zdravotní politiky, pro analýzy problémů v oblasti ochrany zdraví při práci, pro vědecký výzkum, pro vzdělávání v oboru a k mezinárodnímu srovnávání. V rámci mezinárodní spolupráce se informace o nemocech z povolání a ohrožení nemocí z povolání hlášených v ČR předávají do systému European Occupational Diseases Statistics (dále EODS) Statistického úřadu Evropské Unie (dále také EUROSTAT), dále do WHO a ILO. NRNP monitoruje vývoj výskytu a struktury nemocí z povolání, resp. ohrožení nemocí z povolání, včetně data ukončení těchto onemocnění. NRNP je kontinuálním pokračováním dlouhodobého statistického sledování od r. 1973 prostřednictvím výkazů. Od založení roku 1991 byl veden Centrem pracovního lékařství Státního zdravotního ústavu v Praze jako Centrální registr nemocí z povolání. Zákonem č. 156/2004 Sb. byl pod současným názvem zařazen mezi 13 zdravotních registrů, které tvoří Národní zdravotnický informační systém (NZIS). Po vstupu České republiky do Evropské Unie byl v roce 2003 NRNP napojen na statistický systém EUROSTATu o nemocech z povolání, zvaný EODS (European Occupational Diseases Statistics). V registru se evidují následující údaje:   

Údaje o pacientovi Údaje o místě výkonu práce a expozici Údaje k onemocnění

2.1.5.1.5 Národní registr reprodukčního zdraví - asistovaná reprodukce (NRAR) Statistickou jednotkou registru je léčba nebo sledování ženy s cílem o umělé oplodnění. Zpravodajskou jednotkou je každé zdravotnické zařízení provádějící postupy a metody asistované reprodukce. Provoz registru je řízen následujícími závaznými předpisy:      

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 227/2006 Sb., o výzkumu na lidských embryonálních buňkách a souvisejících činnostech a o změně některých souvisejících zákonů Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů Zákon č. 296/2008 Sb., o zajištění jakosti a bezpečnosti lidských tkání a buněk určených k použití u člověka a o změně souvisejících zákonů Závazné pokyny NZIS - Pokyny k obsahu datové struktury

Účelem registru je evidence všech žen, u kterých byla zahájena ovariální stimulace nebo bylo zahájeno monitorování za účelem léčby sterility (sterility vlastní nebo sterility jiné ženy v případě darování oocytů) metodou mimotělního oplodnění (IVF) nebo příbuznými technikami. Sledování IVF cyklů zajišťuje nezbytné informace o způsobu, průběhu, výsledcích a případných komplikacích pro potřeby odborných zdravotnických pracovníků, Ministerstva zdravotnictví ČR, zdravotních pojišťoven i pro mezinárodní vykazování údajů. Získané informace umožňují hodnocení léčebných postupů a jsou využívány pro řízení a zkvalitňování péče o neplodné páry a pro realizaci státní politiky v oblasti asistované reprodukce a léčby sterility. Národní registr asistované reprodukce (NRAR) je celoplošným populačním registrem. Od roku 2007 je NRAR provozován jako webová aplikace s centrální databází. Centra asistované reprodukce vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce registru. V registru se evidují následující údaje: 

Identifikace cyklu

20 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“           

Identifikace ženy Výchozí zdravotní údaje Průběh cyklu Odběr oocytů z ovarií Oplození a vývoj Komplikace PGD Shrnutí a uzavření cyklu Výsledek cyklu Výsledek gravidity Dodatečné údaje

2.1.5.1.6 Národní registr reprodukčního zdraví – novorozenci (NRNAR) Statistkou jednotkou jsou informace o novorozenci a matce, průběhu porodu, porodní a poporodní terapii a stavu novorozence. Zpravodajskou jednotkou jsou novorozenecké úseky dětských a ženských oddělení a novorozenecká oddělení lůžkových zdravotnických zařízení (bez ohledu na zřizovatele) a dále lůžková zařízení, kde bylo dítě (nepřetržitě ode dne svého narození) hospitalizováno do 3 měsíců svého života. Provoz registru je řízen následujícími závaznými předpisy:       

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů. NRNAR byl vyhlášen ve Věstníku MZ, částka 14, Ročník 2001 Zaváděcí dopis MZ ČR č.j. LP/5-251-20.2.1991 ze dne 13.3.1991 Závazné pokyny NZIS - Pokyny k obsahu datové struktury - Národní registr novorozenců Datový standard MZ

Účelem zjišťování požadovaných údajů je zajištění nezbytných informací z oblasti perinatální péče jak pro potřeby odborných zdravotnických pracovníků, Ministerstva zdravotnictví, tak pro mezinárodní vykazování údajů. Získané informace jsou důležitým zdrojem hodnocení zdravotního stavu novorozenců a využívají se pro řízení, hodnocení a zlepšování péče o novorozence. Národní registr novorozenců (dále jen NRNAR) obsahuje základní údaje o okamžitém stavu novorozence po porodu, jeho další zdravotní stav, komplikace, léčbu. Získané informace slouží pro databáze Světové zdravotnické organizace (WHO) a Organizace pro evropskou spolupráci a rozvoj (OECD). NRNAR je celoplošným populačním registrem, který navazuje na Informační systém o novorozenci, provozovaný ÚZIS ČR od roku 1991. V NRNAR jsou evidováni všichni novorozenci včetně mrtvě narozených. V registru jsou evidovány následující údaje:    

Údaje o novorozenci Údaje z porodního sálu Údaje z oddělení Informace o propuštění dítěte

21 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2.1.5.1.7 Národní registr reprodukčního zdraví - potraty (NRPOT) Statistickou jednotkou je ukončení těhotenství (včetně mimoděložního). Zpravodajskou jednotkou jsou gynekologická oddělení lůžkových zdravotnických zařízení bez ohledu na zřizovatele. Došlo-li k potratu mimo lůžkové zařízení, podá hlášení lékař, který byl potratu přítomen nebo ženu dodatečně ošetřil. Provoz registru je řízen následujícími závaznými předpisy:        

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon ČNR č. 66/1986 Sb., o umělém přerušení těhotenství Vyhláška MZ ČSR č. 75/1986 Sb., kterou se provádí zákon ČNR č.66/1986 Sb., o umělém přerušení těhotenství Vyhláška MZ ČSR č. 11/1988 Sb., o povinném hlášení ukončení těhotenství, úmrtí dítěte a úmrtí matky Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů. Závazné pokyny NZIS - Pokyny k obsahu datové struktury Datový standard MZ

Účelem zjišťování požadovaných údajů je zajištění údajů pro posouzení kvality péče o reprodukční zdraví. Sběr údajů týkajících se potratů v České republice se stal dlouholetou tradicí a nezbytnou součástí demografických a perinatologických informací o české populaci. Anonymizované údaje jsou v měsíční periodicitě předávány Českému statistickému úřadu pro potřeby demografické statistiky. Analýza dat poskytuje řadu mezinárodně uznávaných kritérií kvality péče a kvality zdraví a poskytuje nezbytný komplement k ostatním perinatologickým údajům, bez kterého není možné komplexně posoudit kvalitu péče o reprodukční zdraví. Národní registr potratů je celoplošným populačním registrem, který navazuje na Informační systém Potraty, který byl provozovaný v ÚZIS ČR od roku 1960. V souboru jsou zahrnuty všechny druhy potratů, a to samovolné, miniinterrupce, umělá přerušení těhotenství (do 12 týdnů těhotenství) a ostatní potraty vč. případů mimoděložního těhotenství, provedené na gynekologických odděleních ve zdravotnických zařízeních ČR. V registru jsou evidovány následující údaje:  

Údaje o pacientce Údaje o potratu

2.1.5.1.8 Národní registr reprodukčního zdraví - rodičky (NRROD) Statistickou jednotkou jsou informace o rodičce, těhotenství, porodu a dítěti získané při hospitalizaci rodičky v souvislosti s porodem nebo šestinedělím. Zpravodajskou jednotkou jsou gynekologicko-porodnická oddělení lůžkových zdravotnických zařízení (bez ohledu na zřizovatele), která provádí porod popřípadě provedou poporodní ošetření rodičky a novorozence a dále lůžková zdravotnická zařízení, kde byla žena po porodu hospitalizována (v termínu do posledního dne šestinedělí). V případě porodu mimo zdravotnické zařízení (porod doma, v dopravním prostředku, ve veřejných prostorách apod.) má oznamovací povinnost zdravotnický pracovník, který byl při porodu nebo provedl první poporodní ošetření rodičky a první poporodní ošetření novorozence. Provoz registru je řízen následujícími závaznými předpisy:  

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému

22 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“     

Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů NRROD byl vyhlášen ve Věstníku MZ, částka 14, Ročník 2001 Zaváděcí dopis MZ ČR č.j. LP/5-251-20.2.1991 ze dne 13.3.1991 Závazné pokyny NZIS - Pokyny k obsahu datové struktury - Národní registr rodiček Datový standard MZ

Účelem zjišťování požadovaných údajů je zajištění základních údajů o reprodukční anamnéze ženy, o průběhu jejího těhotenství, porodu a o novorozenci. Sledování rodiček slouží k hodnocení zdravotního stavu rodičky z pohledu kvality péče. Získané informace jsou cenným zdrojem informací pro gynekologicko-porodnickou péči a jsou důležitým nástrojem pro zlepšování péče o těhotné a rodičky. Informace registru se využívají pro stanovení koncepce a realizace státní zdravotní politiky v oblasti gynekologicko-porodnické péče a zároveň se využívají pro databáze Světové zdravotnické organizace (WHO) a Organizace pro evropskou spolupráci a rozvoj (OECD). Zároveň se poskytují dalším mezinárodním organizacím podle smluvních závazků. Národní registr rodiček je celoplošným populačním registrem, který navazuje na Informační systém o rodičce provozovaný v ÚZIS ČR od roku 1991. V NRROD jsou evidovány všechny rodičky podléhající hlásící povinnosti. V registru jsou evidovány následující údaje:    

Údaje o rodičce Údaje o těhotenství Údaje o porodu Údaje o dítěti

2.1.5.1.9 Národní registr reprodukčního zdraví - vrozené vady (NRVV) Statistickou jednotkou je diagnostikovaná vrozená vada (dále jen VV) u plodů, kdy se VV zjistila při prenatální diagnostice a u samovolných potratů nad 500 gramů, u dětí do dokončeného 15. roku života a u mrtvě narozených dětí. Zpravodajskou jednotkou jsou genetická, ženská, gynekologicko-porodnická, novorozenecká, dětská, kardiologická, ortopedická nebo jiná odborná oddělení zdravotnických zařízení (bez ohledu na zřizovatele), kde byla vrozená vada diagnostikována. Provoz registru je řízen následujícími závaznými předpisy:      

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů. NRVV byl vyhlášen ve Věstníku MZ, částka 14, Ročník 2001 Závazné pokyny NZIS - Pokyny k obsahu datové struktury - Národní registr vrozených vad Datový standard MZ

Účelem zjišťování požadovaných údajů je registrace prenatálně a postnatálně diagnostikovaných vrozených vad v populaci, která je v současné době jedním ze základních faktorů potřebných pro hodnocení zdravotního stavu populace a je nedílnou součástí hodnocení prenatální, perinatální a postnatální péče. Sledování výskytu vrozených vad slouží k vyhodnocování včasného záchytu vrozených vad. Získané informace se využívají k hodnocení zdravotního stavu a kvality nové populace. Informace se využívají jako podklad k tvorbě koncepce státní zdravotní politiky v této oblasti. Využívají se při prezentaci sledovaných údajů v zahraničí. Informace slouží pro databáze Světové zdravotnické organizace (WHO) a Organizace pro evropskou spolupráci a rozvoj (OECD).

23 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Národní registr vrozených vad je celoplošným populačním registrem, který navazuje na Informační systém Vrozené vady, provozovaný v ÚZIS ČR od roku 1965. V NRVV jsou evidovány všechny vrozené vady zjištěné u dětí do 15ti let a vady plodu zjištěné v průběhu těhotenství a dále u mrtvě narozených dětí. V registru jsou evidovány následující údaje:   

Údaje k plodu Údaje k dítěti Další společné údaje k plodu a dítěti

2.1.5.1.10 Národní registr léčby uživatelů drog (NRLUD) Statistickou jednotkou je osoba s problémy způsobenými užíváním návykových látek nebo osoba na nich závislá, která vstoupila nebo byla zařazena do programu zaměřeného na poradenství a léčbu závislosti prováděného léčebnými a poradenskými zařízeními. Zpravodajskou jednotkou je každý poskytovatel zdravotních služeb poskytující odbornou péči osobám užívajícím návykové látky a osobám na těchto látkách závislým podle zákona upravujícího opatření k ochraně před škodami působenými tabákovými výrobky, alkoholem a jinými návykovými látkami. Zpravodajskou jednotkou je také každý poskytovatel sociálních služeb poskytující odbornou péči osobám užívajícím návykové látky a osobám na těchto látkách závislým podle zákona upravujícího opatření k ochraně před škodami působenými tabákovými výrobky, alkoholem a jinými návykovými látkami, formou služeb sociální péče, sociální prevence a programů sociálního poradenství. Provoz registru je řízen následujícími závaznými předpisy:       

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů Usnesení vlády č. 111/1998 ke Koncepci a programu protidrogové politiky vlády Zákon č. 379/2005 Sb., o opatřeních k ochraně před škodami způsobenými tabákovými výrobky, alkoholem a jinými návykovými látkami Standard substituční léčby (částka 3/2008 Věstník MZ) Uživatelská příručka pro aplikaci, Pokyny pro vyplňování hlášení, formuláře a další informace

Národní registr léčby uživatelů drog je registrem zaměřeným na shromažďování údajů o pacientech při vstupu do a výstupu z léčby závislosti včetně kontaktních, poradenských a resocializačních programů pro uživatele drog, tj. shromažďování dat, jejich verifikace, ukládání, ochrana a zpracování. Tento registr poskytuje souhrnné údaje pro statistické přehledy jak na národní, tak i mezinárodní úrovni, dále pro epidemiologické studie a zdravotnický výzkum. Údaje budou použity při tvorbě protidrogové politiky a strategie ČR a v mezinárodním kontextu i v EU. Indikátor žádosti o léčbu je jedním z pěti klíčových indikátorů drogové epidemiologie stanovených Evropským monitorovacím centrem pro drogy a drogovou závislost (dále EMCDDA), jejichž sběr je členským státům EU uložen v článku 5 Nařízení Evropského parlamentu a Rady (ES) č. 1920/2006 ze dne 12. prosince 2006. Sledování žádostí o léčbu je součástí Drogového informačního systému, jehož realizaci předpokládá řada usnesení vlády k národním strategiím protidrogové politiky a jejich akčním plánům, aktuálně k Národní strategii protidrogové politiky na období 2010-2018 a akčního plánu na období 2010-2012. Léčba spolu se sociální reintegrací a harm reduction, čili snížení negativních důsledků užívání drog, jsou dva ze čtyř pilířů české protidrogové strategie. Bez sledování vývoje v poskytování léčby a specializovaných služeb uživatelům drog nelze vývoj v těchto oblastech protidrogové politiky sledovat a hodnotit. Základním cílem zjišťování požadovaných údajů o substitučních látkách je možnost zdravotnických zařízení poskytujících substituční léčbu ověřit si před zahájením léčby, zda pacientovi již není poskytována substituční terapie v jiném zdravotnickém zařízení. Tím by se mělo zabránit vícenásobné preskripci a úniku substitučních látek

24 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ na nelegální trh. Účelem zjišťování požadovaných údajů je shromažďování dat o pacientech při vstupu a výstupu ze substitučního programu, jejich verifikace, ukládání a zpracování. Tento registr poskytuje souhrnné údaje pro statistické přehledy, epidemiologické studie a zdravotnický výzkum. Souhrnná data jsou podkladem pro tvorbu, realizaci a vyhodnocování preventivních zdravotnických programů a pro odhady potřebných finančních nákladů na zajištění substituční léčby. Údaje jsou použity při tvorbě protidrogové politiky a strategie ČR a v mezinárodním kontextu i v EU. Tento registr je celoplošným populačním registrem, který navazuje na informační systém provozovaný v ÚZIS ČR od roku 2000. V registru jsou evidovány následující údaje:   

Informace o pacientovi Informace k léčbě Informace o ukončení a změně substituční léčby

2.1.5.1.11 Národní registr úrazů (NRU) Statistickou jednotkou bude každý hospitalizovaný pacient s úrazem. Zpravodajskou jednotkou bude každý poskytovatel lůžkové zdravotní péče, který hospitalizoval pacienta s úrazem. Provoz registru bude řízen následujícími závaznými předpisy:   

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů

Účelem zjišťování požadovaných údajů je registrace údajů týkající se úrazů ošetřených při hospitalizaci, údajů související se zdravotním stavem pacienta ve vztahu k úrazu a jeho diagnostice a léčbě, okolností, za kterých se úraz stal, jeho příčiny, podrobný popis místa a času úrazu, rychlost zásahu poskytovatele zdravotnické záchranné služby, údajů o primárním transportu, podrobný záznam o péči na urgentním příjmu a následném poskytování zdravotních služeb, a údajů potřebné pro identifikaci poskytovatele lůžkové zdravotní péče, v jehož zdravotnickém zařízení byl pacient hospitalizován. Data shromažďována v rámci Národního registru úrazů budou využívána především pro dosažení vyšší kvality zdravotních služeb v případě úrazů, jejich lepších výsledků, stanovení optimálních a efektivních léčebných postupů a pro identifikaci rizik vzniku jednotlivých úrazů a stanovení preventivních opatření, to je opatření, vedoucích k jejich předcházení. Každý úraz bude zaznamenán jednotlivě, z hlediska příčin jeho vzniku a vývoje, charakteru postižení, postupu léčení, výsledků léčby i možných zdravotních komplikací případně ve vazbě na jiné zdravotní problémy nositele. Zaznamenávány budou závažnější úrazy, které si vyžádají hospitalizaci pacienta. Sledovaná data budou odpovídat standardům formulovaným v rámci Evropské unie a budou splňovat nároky na kompatibilitu. Důvodem je potřeba výměny příslušných dat mezi jednotlivými státy. Evropská unie má již k dispozici dlouhodobá historická fakta o sledování úrazů na chirurgických ambulancích. Zároveň vytvořila databázi úrazů EU včetně systému jejich zaznamenávání (IDB). Ten slouží ke standardizaci sledování úrazů a nehod v Evropské unii a je zároveň základem pro porovnávání situace v jednotlivých členských zemích.

2.1.5.1.12 Národní registr osob trvale vyloučených z dárcovství krve (NROVDK) Statistickou jednotkou bude každá osoba trvale vyloučená z dárcovství krve, a to bezprostředně po ověření pozitivního výsledku konfirmačního vyšetření dané osoby na zjištění trvalého vyloučení z dárcovství krve. Zpravodajskou jednotkou bude každý poskytovatel transfuzní služby, který identifikoval osobu trvale vyloučenou z dárcovství krve. Provoz registru bude řízen následujícími závaznými předpisy:

25 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“   

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů

Účelem zjišťování požadovaných údajů je registrace osob, u kterých jsou z definovaných důvodů, obvykle pro nosičství závažné krví přenosné infekce, z dárcovství trvale vyloučeny (jde např. o osoby s hepatitidou B a C, HIV ev. jinými infekcemi). Cílem registrace je zvýšit bezpečnost transfuzních přípravků určených k léčbě nemocných v ČR a snížit riziko přenosu závažných infekcí. Vzhledem k závažnosti případného přenosu infekce krevní transfuzí je nutné evidovat osoby vyřazené z dárcovství krve i bez jejich souhlasu. Vyřazené osoby je nutné dohledat jmenovitě, registr nelze anonymizovat (s výjimkou statistických výstupů). Registr musí být provozován v elektronické verzi tak, aby potenciálního „rizikového“ dárce bylo možné identifikovat včas, tj. hned při příchodu do zařízení transfuzní služby a dříve, než krev či její složku daruje.

2.1.5.1.13 Národní registr kardiovaskulárních operací a intervencí – kardiochirurgie (NKCHR) Statistickou jednotkou je provedená srdeční operace. Zpravodajskými jednotkami jsou zdravotnická zařízení, ve kterých byly kardiochirurgické výkony provedeny. Provoz registru je řízen následujícími závaznými předpisy:    

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů NKCHR byl vyhlášen ve Věstníku MZ, částka 6, Ročník 2002

Účelem zjišťování požadovaných údajů je vytvoření národní centrálně vedené zdravotnické dokumentace osob se závažnými srdečními chorobami, u kterých byla provedena kardiochirurgická operace. NKCHR je pokračováním Národního registru kardiovaskulárních intervencí, který byl provozován od roku 1997 Střediskem MEDICON - IKEM. NKCHR vznikl v roce 2002 z potřeby všech zúčastněných kardiochirurgických pracovišť získat informace o počtu srdečních operací v jednotlivých centrech a umožnit přesnější hodnocení a analýzu kvality výkonů včetně mortality, doby hospitalizace a stratifikace rizikových faktorů. V registru jsou zpracovávány osobní údaje potřebné pro identifikaci pacienta, údaje související se zdravotním stavem pacienta ve vztahu k onemocnění - předoperační informace (kardiální anamnéza, předchozí intervence, rizikové změny pro rozvoj ICHS, srdeční vyšetření a předoperační stav a podpora vč. důvodu současné operace), operační informace (datum operace, věk v době operace, identifikace operatéra, odborné údaje o provedené operaci) a pooperační informace (odborné údaje o pobytu na jednotce intenzivní péče zdravotnického zařízení, o pooperačních komplikacích, o propuštění ze zdravotnického zařízení, popřípadě o úmrtí pacienta.) Registr taktéž obsahuje údaje potřebné k identifikaci zdravotnického zařízení, ve kterém byly provedeny kardiochirurgické operace. Od konce roku 2003 je NKCHR provozován jako webová aplikace s centrální databází. Pověřená zdravotnická pracoviště NKCHR vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce registru. V registru jsou evidovány následující údaje: 

Předoperační informace o Identifikace pracoviště o Osobní data pacienta

26 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“





o Příjem k hospitalizaci o Kardiální anamnéze o Předchozí intervence o Rizikové změny pro rozvoj ICHS o Srdeční vyšetření o Předoperační stav a podpora Operační informace o Zahájení operace o Aortokoronární bypass o Výkony na chlopních o Jiné provedené intervence o Mimotělní oběh a ochrana myokardu Pooperační informace o Pobyt na JIP o Pooperační komplikace o Propuštění/exitus

2.1.5.1.14 Národní registr kardiovaskulárních operací a intervencí – intervence (NRKI) Statistickou jednotkou je provedená kardiovaskulární intervence. Zpravodajskou jednotkou je každé zdravotnické zařízení, ve kterém byla pacientovi provedena kardiovaskulární intervence. Provoz registru je řízen následujícími závaznými předpisy:   

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů

Účelem zjišťování požadovaných údajů je vytvořit národní centrálně vedenou zdravotnickou dokumentaci osob se společensky závažným onemocněním ischemickou chorobou srdeční, u kterých byla provedena kardiovaskulární intervence (katetrizace, angioplastika). V registru jsou zpracovávány údaje potřebné pro identifikaci případu a pacienta; údaje související se zdravotním stavem pacienta ve vztahu k onemocnění a provedení kardiovaskulární intervence koronárních cév katetrizací (indikace, průběh obtíží, osobní anamnéza, výsledky angiografie, popis výkonu včetně procedur, přidružených výkonů a status), údaje o případných nekoronárních cévních intervencích (končetin) a údaje potřebné pro identifikaci zdravotnického zařízení, ve kterém byla intervence provedena. Registr napomáhá k hodnocení vývoje nemocnosti a kvality poskytované péče v oblasti kardiovaskulárních intervencí. V akutních případech umožňuje zjistit informace o předchozí léčbě pacienta. Od konce roku 2003 je NRKI provozován jako webová aplikace s centrální databází. Pověřená zdravotnická pracoviště NRKI vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce registru. V registru jsou evidovány následující údaje:    

Pracoviště Identifikace případu Pacient Intervence

27 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2.1.5.1.15 Národní registr pitev a toxikologických vyšetření prováděných na oddělení soudního lékařství (NRPTV) Statistickou jednotkou bude každá provedená pitva včetně výsledků toxikologických vyšetření získaných při pitvě. Zpravodajskou jednotkou bude každé pracoviště soudního lékařství, ve kterém byla provedena pitva a toxikologická vyšetření. Provoz registru bude řízen následujícími závaznými předpisy:   

Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů

Účelem zjišťování požadovaných údajů je registrace údajů získaných z pitev a jejich toxikologických vyšetření na soudnělékařských odděleních. Registr má být zdrojem informací jak o podrobnostech a okolnostech náhlých a násilných úmrtí, tak o jejich příčinách. Registr bude zároveň zdrojem informací o tzv. drogových úmrtích, tj. úmrtích na předávkování návykovými látkami a úmrtích z jiných příčin za jejich přítomnosti. Souhrnná data budou podpůrným zdrojem při přípravě a předávání údajů o úmrtnosti a jejích příčinách do mezinárodních institucí, jako jsou zejména Světová zdravotnická organizace, Evropská komise a Organizace pro hospodářskou spolupráci a rozvoj.

2.1.5.2 Registry hygienické služby V České republice je provozováno několik registrů týkajících se agend orgánů ochrany veřejného zdraví, jejichž popis by byl nad rámec tohoto dokumentu. Níže je proto uveden seznam registrů, které mají přímý vztah ke klinické problematice:   

Informační systém infekční nemoci (IS IN) Registr pohlavních nemocí (RPN) Registr tuberkulózy (RTBC)

2.1.5.2.1 Informační systém infekční nemoci (IS IN) Statistickou jednotkou je vybraná infekční nemoc. Hlásí se potvrzené onemocnění, podezření z onemocnění, nosičství, úmrtí. Jednotlivé případy jsou statisticky sledovány dle MKN-10. Předmětem hlášení nejsou některá závažná infekční onemocnění sledovaná jinými samostatnými informačními systémy a registry. Jedná se o onemocnění tuberkulózou (dg. A15–A19), infekce přenášené převážně sexuálním stykem (dg. A50–A64) a onemocnění virem lidské imunodeficience HIV (dg. B20–B24). Samostatný informační systém mají také akutní respirační infekce (ARI) a chřipce podobná onemocnění (ILI). Zcela samostatnou problematiku tvoří Registr nosokomiálních infekcí, který nicméně není aktuálně prakticky využit. V informačním systému EPIDAT jsou dále sledována některá onemocnění uvedená v jiných kapitolách IV., X. a XX. MKN-10, která s infekčními nemocemi souvisí. Zpravodajskou jednotkou je každý lékař (zdravotnické zařízení), který zjistil infekční/parazitární onemocnění podléhající hlášení. Provoz registru je řízen následujícími závaznými předpisy:   

Zákon č. 258/2000 Sb., o ochraně veřejného zdraví, ve znění pozdějších předpisů Vyhláška č. 195/2005 Sb., kterou se upravují podmínky předcházení vzniku a šíření infekčních onemocnění a hygienické požadavky na provoz zdravotnických zařízení a ústavů sociální péče Vyhláška č. 473/2008 Sb., o systému epidemiologické bdělosti pro vybrané infekce ve znění pozdějších předpisů (Vyhláška č. 275/2010 Sb.)

28 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Účelem zjišťování je získávání informací o výskytu infekčních onemocněních k posouzení vývoje epidemiologické situace na území ČR, ke sledování zdravotního stavu obyvatelstva a k řízení poskytovaní zdravotní péče. K zajištění povinného hlášení, evidence a analýzy výskytu infekcí byl v roce 1991 vypracován program EPIDAT, který navazuje na ISPO (Informační systém přenosných onemocnění). Od roku 1993 je EPIDAT celostátně používán na všech hygienických stanicích jako základ místní, regionální a národní surveillance infekčních chorob.

2.1.5.2.2 Registr pohlavních nemocí (RPN) Statistickou jednotkou je každé zjištěné onemocnění pohlavní nemocí, která podléhá hlášení, včetně reinfekcí. Registr zahrnuje všechna epidemiologická hlášení o pohlavní nemoci, o úmrtí s pohlavní nemocí, podezření z onemocnění nebo nákazy pohlavní nemocí a označené zdroje nákazy pohlavní nemocí včetně případů zjištěných u cizinců. Povinnému hlášení pohlavní nemocí podléhají tyto nemoci: Vrozená syfilis (A50), časná syfilis (A51), pozdní syfilis (A52), jiná a neurčená syfilis (A53), gonokoková infekce (A54), lymphopogranuloma venereum (A55), chancroid-ulcus molle (A57). Zdravotnické pracoviště, které onemocnění pohlavní nemocí diagnostikovalo (zpravidla dermatovenerologické) bez ohledu na zřizovatele. Provoz registru je řízen následujícími závaznými předpisy:    

Zákon č. 258/2000 Sb., o ochraně veřejného zdraví, ve znění pozdějších předpisů Zákon č. 471/2005 Sb., úplné znění zákona o ochraně veřejného zdraví Vyhláška č. 195/2005 Sb., kterou se upravují podmínky předcházení vzniku a šíření infekčních onemocnění a hygienické požadavky na provoz zdravotnických zařízení a ústavů sociální péče Směrnice č. 30/1968 Věstníku MZ, částka 51/1968, o opatřeních proti pohlavním nemocem

Účelem zjišťování je zajištění informací o vybraných pohlavních onemocněních k posouzení vývoje epidemiologické situace na území ČR, ke sledování zdravotního stavu obyvatelstva a k řízení poskytované zdravotní péče. Výsledky se předávají Světové zdravotnické organizaci a ECDC. RPN je kontinuálním pokračováním dlouhodobého statistického sledování (od r.1959) v ÚZIS ČR. Od roku 2003 je RPN provozován jako webová aplikace s centrální databází. Krajské hygienické stanice vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce. RPN - jeho internetová část - je zřízen Ministerstvem zdravotnictví České republiky a je součástí informačního systému hygienické služby.

2.1.5.2.3 Registr tuberkulózy (RTBC) Statistickou jednotkou je zjištěná aktivní tuberkulóza nebo jiná mykobakterióza a každý mikrobiologicky pozitivní laboratorní nález. Zpravodajskou jednotkou jsou odborné ordinace lékařů oboru pneumologie a ftizeologie ve zdravotnických zařízeních (ambulantních i lůžkových) bez ohledu na zřizovatele a každá laboratoř provádějící mykobakteriologická vyšetření bez ohledu na zřizovatele. Provoz registru je řízen následujícími závaznými předpisy:    

Zákon č. 258/2000 Sb., o ochraně veřejného zdraví a o změně některých souvisejících zákonů, ve znění pozdějších předpisů Vyhláška MZ ČR č. 195/2005 Sb., kterou se upravují podmínky předcházení vzniku a šíření infekčních onemocnění a hygienické požadavky na provoz zdravotnických zařízení a ústavů sociální péče Vyhláška MZ ČR č. 473/2008 Sb., o systému epidemiologické bdělosti pro vybrané infekce Instrukce MZ ČSR, FMNO, FMV, MV ČSR a MS ČSR o klasifikaci tuberkulózy a jiných mykobakterióz a o poskytování dispenzární péče v oboru tuberkulózy a respiračních nemocí (publikováno pod č. 1/1986 Věstníku vlády ČSR pro NV a ve Věstníku MZ částka 8-12 Ročník 1986).

Účelem zjišťování je zajištění dohledu nad TBC v ČR a přípravy programů k omezení výskytu TBC.

29 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ V registru tuberkulózy jsou sledovány všechny osoby, u kterých byla na území České republiky zjištěna aktivní tuberkulóza nebo jiná mykobakterióza a osoby dispenzarizované ve skupinách aktivní i inaktivní tuberkulózy nebo jiné mykobakteriózy. V České republice existuje od padesátých let 20. století zákonná povinnost pro všechny lékaře, kteří diagnostikují u nemocných nové onemocnění nebo recidivu tuberkulózy, jakož i úmrtí na tuberkulózu, hlásit je jako nemocné s infekčním onemocněním. Údaje o všech oznámených výskytech se monitorují v centrálním registru TBC. Registr TBC nahrazuje lokální zpracování části zabývající se shromažďováním dat z formulářů, a tím napomáhá při tvorbě a údržbě kvalitní, aktuální a proti zneužití osobních dat zabezpečené datové základny v oblasti výskytu onemocnění TBC v rámci ČR. Od roku 2003 je RTBC součástí Informačního systému orgánů ochrany veřejného zdraví a je provozován jako webová aplikace s centrální databází. Krajské hygienické stanice vkládají data do registru prostřednictvím internetového připojení přes zabezpečený protokol https. Přístup do registru a přidělení uživatelské role schvaluje správce. Nedílnou součástí RTBC se stala databáze Informačního systému bacilární tuberkulózy (ISBT). ISBT je systém hlášení pozitivních výsledků mykobakteriologických vyšetření. Každá laboratoř, provádějící detekci TBC, je povinna hlásit pozitivní nálezy. Provázanost RTBC a ISBT přispívá ke kontrole úplnosti a validity dat o TBC. V současné době zajišťuje provoz ISBT Národní jednotka dohledu nad TBC FN Na Bulovce.

2.1.5.3 Další klíčové registry 2.1.5.4 Transplantační registry Registry související s transplantačním programem ČR vede Koordinační středisko transplantací vyjma Národního registr osob nesouhlasících s posmrtným odběrem tkání a orgánů. Jedná se tedy o následující registry:    

Národní registr osob čekajících na transplantaci orgánů, Národní registr dárců tkání a orgánů, Národní registr provedených transplantací tkání a orgánů, Národní registr osob nesouhlasících s posmrtným odběrem tkání a orgánů.

Podrobný popis je níže uveden pouze pro Národní registr osob nesouhlasících s posmrtným odběrem tkání a orgánů.

2.1.5.4.1 Národní registr osob nesouhlasících s posmrtným odběrem tkání a orgánů (NROD) Statistickou jednotkou je každý zjištěný evidovaný nesouhlas s posmrtným odběrem tkání a orgánů na území České republiky. Občané, kteří vyslovili nesouhlas s posmrtným odběrem tkání a orgánů na území České republiky. Provoz registru je řízen následujícími závaznými předpisy:    

Zákon č. 285/2002 Sb., o darování, odběrech a transplantacích tkání a orgánů a o změně některých zákonů (transplantační zákon) Vyhláška č. 434/2004 Sb., o podrobnostech rozsahu a obsahu povinně uváděných dat do Národního registru osob nesouhlasících s posmrtným odběrem tkání a orgánů Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů Věstník MZ č. 10/2004

Účelem registrace je evidence osob, které nesouhlasí s darováním tkání a orgánů tak, aby nemohlo dojít k neodpovídající manipulaci s jejich tělem po smrti – tzv. „odmítačů“. Dárcovství orgánů a tkání je vysoce humánním rozhodnutím. Darované orgány a tkáně zachraňují v akutních případech životy mnoha lidem a dalším umožňují prodloužení spokojeného života o mnoho let. To se týká zejména pacientů s onemocněním ledvin, srdce, plic a jater.

30 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Každý člověk má rovněž možnost za svého života vyjádřit nesouhlas s tím, aby po jeho smrti byly ze zemřelého těla odebrány tkáně a orgány vhodné k transplantaci. Aby bylo možné eventuelní nesouhlasy evidovat nebo následně zjišťovat, nebyl-li takový nesouhlas vysloven, zřídilo MZ Národní registr osob nesouhlasících s posmrtným odběrem tkání a orgánů. Vyjadřovaný nesouhlas musí podle zákona č. 285/2002 Sb. o darování, odběrech a transplantacích tkání a orgánů (transplantační zákon) obsahovat některé nezbytné náležitosti a zákonem dané údaje. Zřízený registr naplňuje úkoly vyplývající ze zákona č. 285/2002 Sb. a umožňuje vyjít vstříc zásadním odpůrcům darování orgánů či tkání tak, aby nemohlo dojít k neodpovídající manipulaci s jejich tělem po smrti. Podle tohoto zákona dále zůstává předpokládaný souhlas dárce s tím rozdílem, že musí být zkoumáno, zda není v registru záznam o nesouhlasu občana s odebráním jeho orgánů či tkání.

2.1.5.5 Státní ústav pro kontrolu léčiv Státní ústav pro kontrolu léčiv (SÚKL) zřizuje dle § 81 zákona č. 378/2007 Sb., o léčivech, Centrální úložiště elektronických receptů. Evidovanou jednotkou je elektronický recept. Organizacemi předávajícími data jsou předepisující lékaři a vydávající lékárny. Dále mají do Centrálního úložiště přístup také zdravotní pojišťovny. Provoz Centrálního úložiště je řízen následujícími závaznými předpisy:    

Zákonem č. 378/2007 Sb., o léčivech, Centrální úložiště elektronických receptů Vyhláškou č. 54/2008 Sb., o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů¨ Vyhláškou č. 84/2008 Sb., o správné lékárenské praxi, bližších podmínkách zacházení s léčivy v lékárnách, zdravotnických zařízeních a u dalších provozovatelů a zařízení vydávajících léčivé přípravky Pokyny SÚKL ERP-1 a ERP-2

Účelem Centrálního úložiště je sloužit pro předávání elektronických receptů od předepisujících lékařů k vydávajícím lékárnám. Dále SÚKL provádí oddělený sběr dat hlášení o vydaných léčivých přípravcích dle § 82 odst. (3) písm. d) zákona č. 378/2007 Sb., o léčivech. Tato hlášení jsou zasílána na SÚKL od provozovatelů oprávněných k výdeji léčivých přípravků v rámci tzv. agendy LEK-13 a neobsahují osobní údaje pacientů.

2.1.5.6 Základní registry státní správy Základní registry jsou jedním ze základních pilířů eGovernmentu (elektronické veřejné správy). Hlavním cílem je ulehčit občanům, firmám a dalším subjektům styk s veřejnou správou, tj. minimalizovat počet návštěv na úřadech a využít možností technologií 21. století pro on-line přístupy odkudkoli a kdykoli. Současně musí veřejná správa zajistit bezpečnou, efektivní a transparentní výměnu přesných a aktuálních (tzv. referenčních) údajů. Ke spuštění projektu do ostrého provozu došlo 1. července 2012. Referenční údaj je údaj vedený v základním registru, který zákon upravující vedení příslušného registru jako referenční údaj označuje – v případě registru obyvatel jde například o příjmení, jméno, odkaz do registru územní identifikace na adresu místa pobytu, datum narození a úmrtí, odkaz do registru územní identifikace na místo a okres narození a úmrtí a státní občanství.

Provoz Základních registrů je řízen následujícími závaznými předpisy:     

Zákon 111/2009 Sb., o základních registrech v aktuálním znění Nařízení vlády č. 161/2011 Sb., o stanovení harmonogramu a technického způsobu provedení opatření podle § 64 až 68 zákona o základních registrech Zákon č. 100/2010 Sb., kterým se mění zákon č.111/2009 Sb., o základních registrech Zákon č.167/2012 Sb., kterým se mění zákon č.111/2009 Sb. o základních registrech Zákon č. 101/2010 Sb., kterým se mění zákon č.227/2000 Sb. o elektronickém podpisu a o změně některých dalších zákonů a zákon č.227/2009 Sb.

31 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  



Zákon č. 227/2009 Sb., kterým se mění některé zákony v souvislosti s přijetím zákona o základních registrech Vyhláška č. 528/2006 Sb., o formě a technických náležitostech předávání údajů do informačního systému, který obsahuje základní informace o dostupnosti a obsahu zpřístupněných informačních systémů veřejné správy (vyhláška o informačním systému o informačních systémech veřejné správy) Zákon č. 365/2000 Sb., o informačních systémech veřejné správy

Obrázek 1 Schéma Základních registrů a napojení agendových informačních systémů

Základní registry jsou celkem čtyři:  

 

Registr obyvatel (ROB) - obsahující základní údaje o občanech a cizincích s povolením k pobytu, mezi tyto údaje patří: jméno a příjmení, datum a místo narození a úmrtí a státní občanství. Registr práv a povinností (RPP) - obsahující referenční údaje o působnosti orgánů veřejné moci, mj. oprávnění k přístupu do k jednotlivým údajům, informace o změnách provedených v těchto údajích apod. Slouží jako garance bezpečné správy dat občanů a subjektů vedených v jednotlivých registrech. Registr osob (ROS) - obsahující údaje o právnických osobách, podnikajících fyzických osobách, orgánech veřejné moci i o nekomerčních subjektech, jako jsou občanská sdružení a církve. Registr územní identifikace, adres a nemovitostí (RUIAN) - spravující údaje o základních územních a správních prvcích.

Všechny čtyři základní registry fungují v rámci Informačního systému základních registrů, tzv. ISZR, jehož správu bude mít na starosti nově vzniklý státní úřad (Správa základních registrů). Technologickou platformu informačního systému budou zajišťovat další součásti eGONa – Komunikační infrastruktura veřejné správy (KIVS) a Centrální místo služeb (CMS). Důležitým prvkem systému je dále převodník identifikátorů fyzických osob - tzv. ORG, jež bude v gesci Úřadu pro ochranu osobních údajů. Činnost ORG je pro ochranu osobních údajů v celém systému základních registrů zcela klíčová. ORG bude jedinou institucí, která dokáže přepočítávat agendové identifikátory z jednoho registru pro druhý. Už tedy nebude možné díky znalosti rodného čísla získat o tomto obyvateli informace prakticky z každého informačního systému veřejné správy, jako to lze nyní. Smysl a účel základních registrů:

32 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

















Poskytovat bezpečně vybrané právně závazné referenční údaje o definovaných subjektech Referenční údaje obsažené v základních registrech jsou považovány za správné pro všechny orgány veřejné moci, dokud je editor – orgán veřejné moci zmocněný zákonem ke změně referenčního údaje - neoznačí jako nesprávné, a to na základě podnětu jiného úřadu, osoby, které se údaj týká anebo vlastního zjištění editora. Vzniká tak „samočistící efekt“ - každý dotaz na referenční údaje v základních registrech je zároveň jejich ověřením. Propagovat změny v těchto údajích provedené oprávněnými editory do celé veřejné správy Referenční údaje edituje jejich editor na základě pravidel (ověření správnosti), která definuje správce registru, a to v prostředí, které provozuje správce. Editorem je subjekt, který má právo na rozhodnutí o editaci referenčních údajů pouze jím pořízených. Editoři jsou zodpovědni za správnost jimi pořízených referenčních údajů, nikoliv správce. Změna referenčních údajů vedených v základních registrech je zadána jen jednou a projeví se ve všech agendových informačních systémech (AIS) automaticky díky „samočistícímu efektu”, protože agendové informační systémy mají povinnost se zeptat na aktuální stav referenčních údajů. O aktuálním stavu referenčních údajů se agendové informační systémy dovídají prostřednictvím notifikací (upozornění) systémem základních registrů o změnách v referenčních údajích vedených subjektů. Propagovat změny v těchto údajích provedené oprávněnými editory vybraným soukromoprávním subjektům na základě zmocnění od subjektu údajů - Na základě žádosti občana zajistí Informační systém základních registrů (ISZR) informování komerčních subjektů o změně referenčních údajů občana odesláním zprávy do datové schránky komerčního subjektu. Umožnit bezpečné a transparentní poskytování údajů i z dalších informačních systémů (IS) ve veřejné správě - Základní registry umožní prostřednictvím svého vnějšího rozhraní publikovat nereferenční údaje z ostatních agendových informačních systémů veřejné správy doplněné o referenční údaje základních registrů. Zavést kontrolu subjektů údajů nad údaji o nich vedených - Všechny referenční údaje vedené v základních registrech jsou vždy dostupné pro subjekt, o kterém jsou vedeny. Fyzická osoba je oprávněna k získání informací z Informačního systému základních registrů (na základě logu – tj. záznamu o změnách a přístupech k údajům), jaké jiné subjekty zjišťovaly o ní informace. Zásadně zjednodušit ohlašovací povinnost - Propagace změn provedených zákonem definovanými editory znamená současně výrazné zjednodušení ohlašovací povinnosti o změně referenčních údajů týkajících se jednotlivých právnických a fyzických osob. Vytvořit předpoklady pro optimalizaci a sjednocení procesů veřejné správy - V registru práv a povinností vzniká základní mapa orgánů veřejné moci, jejich kompetencí a činností využívaných pro plnění těchto zákonných kompetencí. Mapa agend a agendových rolí orgánů veřejné moci je hlavním předpokladem pro zahájení procesní optimalizace veřejné správy. Zavést násobnou digitální identitu v agendových systémech veřejné správy - Základní registry zavádí oddělené agendové identifikátory fyzických osob (AIFO) jako jednoznačné bezvýznamové identifikátory, které jsou navzájem převoditelné pouze prostřednictvím základních registrů. Nevytvořit Velkého Bratra

Jedním z principů zavedení Základních registrů je „anonymizace“ osobních dat uložených v informačních systémech veřejné správy. Základní registry obsahují referenční osobní údaje, které jsou odkazovány bezvýznamovými identifikátory z jednotlivých informačních systémů a postupně tak bude možné, aby jednotlivé informační systémy obsahovaly pouze anonymizované údaje. Základní registry používají pro identifikaci občana bezvýznamový identifikátor, navíc ještě odlišný v různých agendách. Vícenásobná digitální identita znemožní nekontrolované křížové identifikace v jednotlivých agendových informačních systémech a postupně vytěsní z veřejné správy celoplošné využívání rodného čísla. Toto doplňuje princip využití převodníků identifikátorů fyzických osob (ORG) jako jediného způsobu, jak sdružit informace o fyzické osobě z více základních registrů, potažmo agendových informačních systémů. Převodník identifikátorů přitom komunikuje výhradně s Informačním systémem základních registrů a neobsahuje žádná osobní data, pouze bezvýznamové identifikátory. Občan může již nyní požádat o poskytnutí údajů třetí osobě (neziskovému či komerčnímu subjektu jako je banka, dodavatel elektřiny nebo poskytovatel zdravotních služeb) nebo tento souhlas posléze odvolat. Na základě žádosti

33 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ budou referenční údaje v žadatelem vymezeném rozsahu poskytnuty jiné fyzické nebo právnické osobě do datové schránky této osoby. Tento způsob však není obecně zástupci těchto třetích osob považován za správný, zejména z toho důvodu, že není dostatečně škálovatelný a předaná data v nestrukturované formě je obtížné automatizovaně zpracovávat. V případě Registru obyvatel existuje možnost přístupu pro zdravotní pojišťovny a pro poskytovatele zdravotních služeb existuje výjimka povolující přístup v případě realizace očkování. Přímý přístup v jiných případech není dosud povolen, přestože mnoho zákonů klade na různé instituce požadavky, při kterých je přístup do Základních registrů téměř nezbytný (například jednoznačné identifikace klienta banky vyplývající ze zákona č.253/2008 Sb., o některých opatřeních proti legalizaci výnosů z trestné činnosti a financování terorismu). Aktuální stav legislativy umožňuje v oblasti zdravotnictví napojení na základní registry následujícím subjektům:   

Orgány veřejné moci v oblasti svých agendových informačních systémů Zdravotní pojišťovny v oblasti provádění zdravotního pojištění Poskytovatelé zdravotních služeb v oblasti provádění očkování

Uvažuje se o zpřístupnění služeb Základních registrů řízeným způsobem pro ostatní subjekty a situace pro neziskový či komerční sektor. Možností realizace takového přístupu jsou v zásadě dvě:  

umožnit informačním systémům privátních subjektů přímé napojení na vnější rozhraní informačního systému základních registrů (tzv. EGON rozhraní) a využívání jeho služeb (tzv. EGON služeb). napojení privátních informačních systémů na nový agendový informační systém, který by tak fungoval jako zprostředkovatel veškerého přístupu k obsahu a službám základních registrů (proxy k základním registrům).

Toto zpřístupnění by však vyžadovalo zavedení nového principu, podle kterého mohou získat přístup k obsahu a službám základních registrů i ty privátní subjekty, kterým zákon ukládá konkrétní povinnosti, splnitelné jen s přístupem k obsahu základních registrů, či dává právo přístupu k obsahu základních registrů. A to se zachováním analogických principů, podmínek a postupů, jaké platí pro orgány veřejné moci a jejich agendové informační systémy, včetně ohlašování vykonávaných agend, resp. činností, registrace informačních systémů, jednoznačné identifikace a autentizace všech uživatelů či logování všech aktivit. Jelikož jde o změnu principu, který je sám zakotven v legislativě, bylo by nutné tuto změnu realizovat novelou zákona č. 111/2009 Sb., o základních registrech. K Základním registrům je komplementární legislativa týkající s nových občanských průkazů, které jsou tzv. elektronické (eOP). Nově se zavádí princip, podle kterého se část osobních údajů (zejména těch, které se mohou měnit častěji) odstraňuje z fyzického nosiče (občanského průkazu) a přesouvá se do základních registrů. Konkrétně do základního registru obyvatel (ROB). Právě tímto krokem (resp. v tomto smyslu) se občanský průkaz stává elektronickým (eOP). Současně s tím se stává fakticky dvoudílným: 



jedním dílem elektronického občanského průkazu je samotný fyzický nosič (realizovaný jako plastová kartička se strojově čitelnými údaji), na kterém jsou uvedeny jen nejzákladnější údaje (včetně fotografie fyzické osoby). Ve viditelné podobě se jedná o jméno, příjmení, datum a místo narození, státní příslušnost a sériové číslo dokladu a dále dočasně o adresu trvalého pobytu, rodné číslo a volitelně rodinný stav. druhým dílem elektronického občanského průkazu je datový záznam, umístěný v základním registru obyvatel a obsahující ostatní údaje o subjektu (fyzické osobě).

34 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 2 Schéma elektronického občanského průkazu

Pro potřeby autentizace se počítá s využitím tzv. bezpečnostního osobního kódu (BOKu), představujícího analogii PINu u bankovních karet. Jde o číselný údaj, který bude logicky sdružen s konkrétním eOP a je uložen v jednom ze základních registrů (konkrétně v registru obyvatel). Takovýto BOK je možné vydávat i držitelům stávajících občanských průkazů (ještě neelektronických). Předpokládaný princip využití bezpečnostního osobního kódu (BOKu) – a to jak u elektronických občanských průkazů, tak i u těch neelektronických – je následující: konkrétní fyzická osoba se identifikuje 9místným sériovým číslem svého eOP (resp.číslem svého neelektronického občanského průkazu). Následně se autentizuje zadáním svého BOKu.

2.1.5.7 Sociální karta (sKarta) Ačkoliv se Sociální karta nyní zdravotnictví přímo netýká, jedná se však o nástroj, jehož využití v rámci zdravotnictví je diskutováno a proto je zde uveden její popis, ze kterého se dále vychází v následujícím textu. Nepojistné sociální dávky a dávky z oblasti státní sociální politiky zaměstnanosti, které jsou dosud vypláceny třemi různými platebními způsoby (hotovostně, poštovní poukázkou a bezhotovostně), začnou být postupně vypláceny prostřednictvím Karty sociálních systémů neboli tzv. sKarty. Vydává se ve dvou variantách: základní a speciální, která bude zároveň sloužit jako průkaz TP, ZTP či ZTP/ P. sKarty jsou vyráběny v souladu s mezinárodně uznávanými předpisy, které se vztahují na bankovní karty, budou tedy obsahovat stejné ochranné prvky. Podobný

35 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ systém zavedla a využívá již řada evropských zemí, například Itálie, Velká Británie, Finsko a další, mimo EU třeba také USA.

Obrázek 3 Náhled na sKartu

sKarta je určena příjemcům následujících nepojistných sociálních dávek a dávek z oblasti státní politiky zaměstnanosti, které se vyplácejí buď jednorázově, nebo pravidelně. Karta není určena pro výplaty důchodů a nemocenské. sKarta obsahuje běžné identifikační údaje, které jsou obvyklé pro bankovní kartu, tudíž i ochrana bude podléhat stejným parametrům a principům. U osob zdravotně postižených bude sKarta obsahovat také fotografii a informaci o stupni mimořádných výhod. Rodné číslo na sKartě uvedeno není. sKarta má plnit tři funkce: identifikační, autentizační a platební.   

Identifikační funkce by měla být používána zejména na úřadě. U osob se zdravotním postižením bude plnit funkci průkazky TP, ZTP a ZTP/P se všemi jejími výhodami. Autentizační funkce umožní z domova realizovat činnosti spojené s veřejnou správou. Příjemce bude mít prostřednictvím internetu přehled o čerpaných sociálních dávkách. Platební funkce umožní příjemci sKartou platit v obchodech nebo vybírat hotovost z bankomatů České spořitelny i všech dalších bank. Prostředky je možné si bezplatně převést na svůj vlastní účet.

Technicky v tuto chvíli funguje sKarta jako platební karta typu Maestro. sKartu vydává česká spořitelna. Ke kartě existuje určitá forma „elektronického bankovnictví“ na adrese www.skontakt.cz. Přihlášení je realizováno pomocí identifikačního čísla na zadní straně karty (pod podpisovou zónou) a bezpečnostního hesla, které je distribuováno ve stejné zásilce jako PIN k platební funkci sKarty.

2.1.6

Krajská a obecní samospráva

Kraje a obce jsou významnými vlastníky poskytovatelů zdravotních služeb – zejména nemocnic krajské a okresní úrovně a léčeben dlouhodobě nemocných. Za účelem jejich regionální koordinace některé kraje vytvořily různé právní formy centralizace jejich správy, zahrnující holdingy, pronájmy, společné správní rady a podobně. Většina krajů se soustředí v dnešní době zejména na ekonomickou stránku krajského zdravotnictví – centrální nákupy, jednotná účetní osnova či srovnání nemocnici dle ekonomických ukazatelů. V některých krajích zavádějí koncept jednotného finančně-provozního informačního systému (ERP) pro všechny své nemocnice. Některé kraje však

36 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ centrálně řeší i sledování ukazatelů kvality na bázi elektronických hlášení (dekubity v Kraji Vysočina, nežádoucí události v Pardubickém kraji) či elektronickou výměnu zdravotnické dokumentace (Kraj Vysočina).

2.1.7

Vzdělávací a výzkumné instituce

Pregraduální vzdělávání ve zdravotnictví zajišťují střední zdravotní školy a lékařské fakulty, či jiné fakulty obdobného zaměření. Situace v postgraduálním vzdělávání je poněkud komplexnější. Specializační vzdělávání koordinují lékařské fakulty a dále Národní centrum ošetřovatelství a nelékařských zdravotnických oborů (NCO NZO), Institut postgraduálního vzdělávání ve zdravotnictví (IPVZ), které jsou tzv. pověřenými organizacemi. Vlastní specializační vzdělávání probíhá u akreditovaných poskytovatelů zdravotních služeb. Celoživotní vzdělávání pak probíhá ve spolupráci různých subjektů s profesními komorami a Českou asociací sester. Tyto vzdělávací instituce vedou elektronicky seznamy svých školenců a absolventů, snad jen s výjimkou samotných akreditovaných poskytovatelů zdravotních služeb. Dle aktuální legislativy formulované zákonem č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování mají nově vzdělávací instituce povinnost komunikovat data o vzdělání zdravotnických pracovníků do NZIS. Výše uvedené instituce také různou měrou využívají při svých aktivitách možnosti eLearningu. eLearning je i součástí vzdělávacích projektů lékařů a nelékařů aktuálně realizovaných IPVZ, financovaných z fondů EU.

2.1.8

Výrobci a distributoři zboží a poskytovatelé služeb pro zdravotnická zařízení

Jedno z nejpokročilejších skupin v této oblasti jsou distributoři léčiv. V této oblasti lze využít i tzv. PDK, což je sjednocený číselník jejich sortimentu. Úroveň rozvoje elektronizace dodavatelského řetězce v oblasti léčiv odpovídá skutečnosti, že všechny lékárny (snad s výjimkou některých odloučených výdejen) mají vlastní informační systém a jsou napojeny na internet. Rovněž po samotných distributorech jsou SÚKLem vyžadovány různá hlášení v elektronické formě (tzv. DIS-13). Žádosti o registraci léčivého přípravku pak mají svůj mezinárodní standardizovaný formát eCTD.

Mapování stávajícího stavu systému zdravotnictví ČR

2.2 2.2.1

Systém zdravotnictví ČR a hlavní aktéři

Systém zdravotnictví v ČR se řadí mezi tzv. systémy veřejného zdravotního pojištění (Bismarckovský systém), kdy občan je plátcem zdravotního pojištění, které je odvozeno od výše příjmu (detailně viz bod 2.5 Finanční a ekonomická analýza stávajícího systému zdravotnictví ČR s ohledem na budoucí elektronizace zdravotnictví). Příjemci zdravotního pojištění jsou zdravotní pojišťovny, které hradí výdaje na zdravotní péči za své pojištěnce. Systém rovněž ve velmi malém ale zvyšujícím se rozsahu zahrnuje prvky přímých plateb, které na jedné straně slouží k regulaci čerpané péče (tzv. regulační poplatky) a na druhé straně k úhradě zdravotních či souvisejících služeb, které nejsou hrazeny ze zdravotního pojištění (některé zdravotní výkony a nadstandardní služby). Asi nejvhodnější způsob popisu zdravotního systému ČR je identifikace jeho hlavních zájmových skupin, jejich role a motivace, která je uvedena v následujících bodech.

2.2.1.1 Nadnárodní organizace ČR historicky patří do určitého geopolitického a kulturního prostoru, který má významný vliv na jeho fungování, a to zejména v následujících oblastech:   

Regulace nadnárodní legislativou (zejména EU); Formulace doporučení v oblasti řízení a správy zdravotních systémů (zejména EU, Evropská komise, WHO, OECD a další); Mezinárodní spolupráce (WHO, EU), výměna dat a zkušeností (WHO, OECD), případně společné plnění některých konkrétních úkolů (např. NATO).

Mezi organizace, jejichž vliv na fungování zdravotního systému ČR lze považovat za zásadní, patří: 

Evropská unie: přestože národní zdravotní systémy jsou vyňaty z přímé legislativní regulace EU, existuje mnoho oblastí, které regulovány EU jsou a které se zdravotnictvím souvisejí, např.: o Volný pohyb osob, pracovní síly, zboží a finančních prostředků;

37 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Regulace pracovních podmínek (BOZP, limity fyzikálních vlivů apod.); Regulace v oblasti zemědělství, potravinářství průmyslu a dalších odvětvích, které mají dopady na zdravotní stav obyvatelstva; Světová zdravotnická organizace (WHO): působí zejména v oblasti sběru dat a mezinárodního srovnávání systémů a zdravotnických informací, formulací doporučení pro řízení a správu zdravotních systémů, definuje základní problémy a navrhuje jejich řešení formou programů, které do určité míry mají závazný charakter (např. Zdraví 21 a jeho podprojekty Zdravé město, Zdravá škola, Zdravá nemocnice atd.). Organizace pro ekonomickou spolupráci a rozvoj (OECD): zejména slouží jako platforma pro výměnu dat a formulaci doporučení pro státní exekutivu. o o





Na roli mezinárodních organizací zejména s ohledem na potřebu výměny strukturovaných informací (ukazatelů, exekutivních dat a dalších) se nesmí zapomínat při plánování elektronizace zdravotnictví, neboť právě mezinárodní výměna dat je často motorem některých změn, projektů či reforem.

2.2.1.2 Státní správa Státní správa je ve zdravotnictví prezentována zejména ministerstvem zdravotnictví a jeho přímo řízenými organizacemi (ÚZIS, SÚKL, Státní hygienik a další), ale též dalšími rezorty, jako jsou ministerstvo práce a sociálních věcí (poskytovatelé sociální péče jsou často zároveň poskytovateli zdravotní péče a naopak), ministerstvo financí (významný regulátor na poli financování zdravotnictví) a další resorty, které mají vliv zejména na oblast prevence, ochrany a posilování zdraví. Státní správa plní ve zdravotnictví následující funkce:     

 

Je zásadním partnerem pro mezinárodní spolupráci, výměnu dat a zkušeností; Zajišťuje základní legislativní nastavení systému zdravotní péče (viz např. nově platný zákon č. 372/2011, jeho prováděcí předpisy a další související "speciální" zákony ve zdravotnictví); Nastavuje základní rámec financování a úhrady zdravotní péče (tzv. úhradová vyhláška); Podílí se na řízení nebo jinak ovlivňuje fungování zdravotních pojišťoven; Je zřizovatelem některých poskytovatelů zdravotní péče (tzv. přímo řízených organizací - fakultní nemocnice, psychiatrické léčebny a další poskytovatelé akutní i lůžkové zdravotní péče, ale též péče sociální); Je zřizovatelem organizací, které mají regulační, kontrolní či informační roli ve zdravotnictví (SÚKL, ÚZIS, hygienické stanice atd.) Dohlíží a kontroluje některé prvky fungování zdravotnictví (hygienické normy, stavební normy, požární a další legislativou stanovené požadavky na fungování poskytovatelů zdravotní péče);

Informační potřeby státní správy jako "vrcholu pyramidy" v řízení, správě, legislativní regulaci a mezinárodní spolupráci jsou obrovské a státní správa je zásadním článkem v elektronizaci zdravotnictví.

2.2.1.3 Regionální a komunální samospráva Role regionů (krajů) a měst je následující: 

 

Kraje a města jsou významným vlastníkem poskytovatelů zdravotních služeb, neboť zřizují často páteřní zdravotnická zařízení (nemocnice, poskytovatele následné péče, ambulantních služeb, sociální péče a další); Jako zřizovatelé jsou důležitým partnerem pro pojišťovny, centrálním zákazníkem pro nákupy léků, zdravotnického materiály, zdravotnických prostředků a dalších. Kraje jsou autory tzv. krajských zdravotních plánů, kde se na regionální úrovni prolíná analýza zdravotního stavu a potřeb obyvatelstva s jejich následným zajištěním.

Regionální a komunální samospráva je potenciálním uživatelem elektronických informačních systémů, a to jak jako původce mnoha důležitých dat, tak jejich koncovým uživatelem.

2.2.1.4 Zdravotní pojišťovny (plátci zdravotní péče) Zdravotní pojišťovny v kontextu systému veřejného zdravotního pojištění plní zejména následující funkce: 

Nábor pojištěnců a výběr pojistného;

38 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  

Zajištění kvalitní, dostupné a ekonomicky efektivní zdravotní péče pro své pojištěnce skrze smlouvy s jednotlivými poskytovateli; Pojišťovny jsou také zásadními shromažďovateli dat o zdravotním stavu (diagnózy,demografické údaje pojištěnců), provedených zdravotních výkonech a zejména aktuální dostupnosti, kvalitě a ceně zdravotní péče;

Základní nevýhodou systému veřejného zdravotního pojištění je jakási dvojkolejnost rozhodovacích kompetencí při jeho financování, kdy základní finanční rámec stanovuje MZ vyhláškou, ale samotná realizace je potom na zdravotních pojišťovnách, kdy diskutabilní je už samotný princip plánování prostředků na úhradu zdravotní péče, který z definice není možný, neboť potřeby pojištěnců nelze plánovat. Zdravotní pojišťovny jsou často kritizovány za to, že se zabývají tzv. vnitřní efektivitou systému (jaký objem zdravotní péče poskytujeme za kolik peněz) na úkor efektivity externí (jaký vliv mají vynaložené prostředky na samotný zdravotní stav, kvalitu života, nemocnost, pracovní neschopnost, délku dožití a další ukazatele, které reflektují samotný účel zdravotní péče). To samozřejmě souvisí s informačním managementem a s kvalitou zpracování a používání agregovaných dat, ke kterým přispívá elektronizace zdravotnictví.

2.2.1.5 Poskytovatelé zdravotních služeb Poskytovatele služeb lze rozdělit dle (toto dělení má svou validitu i při analýze informačních potřeb těchto poskytovatelů):      

Naléhavosti zdravotní péče: neodkladná, akutní, nezbytná, plánovaná; Dle účelu zdravotní péče: preventivní, diagnostická, dispenzární, léčebná, posudková, léčebně rehabilitační, ošetřovatelská, paliativní, lékárenská; Dle formy zdravotní péče: ambulantní, jednodenní, lůžková, "domácí"; Dle právní subjektivity: příspěvkové organizace, akciové společnosti, společnosti s ručením omezeným, OSVČ (u poskytovatelů - fyzických osob) a další; Dle ziskovosti: ziskové, neziskové; Dle zřizovatele/majitele: veřejné, soukromé.

Poskytovatelů zdravotních služeb je v ČR v současné době přibližně 28 000, z čehož drtivá většina jsou ambulantní zařízení (praktičtí lékaři a další registrující lékaři, ambulantní specialisté), dalších přibližně 180 akutních lůžkových zařízení (nemocnic), 450 zařízení následné lůžkové péče, dále lékárny, záchranné služby a další (např. domácí péče).

39 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Tabulka 4 Přehled všech poskytovatelů zdravotní péče - ÚZIS (2011)

Poskytovatele zdravotních služeb mají v podstatě jediný zájem a úkol, a tím poskytovat zdravotní péči za ekonomicky přijatelných podmínek, tedy hospodařit s vyrovnaným nebo dokonce ziskovým rozpočtem. Již z tohoto je patrné, že zájmy poskytovatelů se liší od zájmu státní správy, která na tento fakt musí reagovat příslušnou legislativou, aby se za stávajících podmínek motivace poskytovatelů překrývala se zájmem státní správy. Právě v tomto se projevuje výše zmíněná dvojkolejnost řízení zdravotnictví, tedy role státní správy a pojišťoven. V ideálním případě by totiž větší poskytovatelé měli například fungovat jako veřejná místa pro ochranu a posilování zdraví (viz projekt WHO Zdravá nemocnice) a všichni poskytovatelé by měli být motivováni k větší kvalitě a efektivitě, např. skrze různá motivační schémata (pay-per-performance, kvalitativní data navázaná na DRG apod.). Jistě netřeba zdůrazňovat, že kvalitní informační nástroje mohou tento motivační rozpor pomoci účinně řešit.

2.2.1.6 Zdravotníci Zdravotničtí pracovníci jsou velmi důležitým hráčem v resortu zdravotnictví, a to z následujících důvodů:  

Jsou často jako OSVČ přímo poskytovateli zdravotních služeb a tudíž partnerem pro jednání s pojišťovnami, servisními firmami atd.; Jsou nositeli zdravotních výkonů, pro něž je zásadní úroveň vzdělání, kvalifikace, erudice, kontinuální vzdělávání atd.;

40 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  

Jsou primárním zdrojem veškerých informací o demografických datech pacientů, provedených výkonech, nákladové efektivitě atd., z čehož plyne obrovský informační (ale též dezinformační) potenciál; Mají vliv na fungování zdravotnictví skrze profesní skupiny (ČLK, ČAS, LOK atd.) a odborné společnosti.

2.2.1.7 Pacienti Pacienti, jako primární "klienti" zdravotní péče ale také plátci zdravotního pojištění, prezentují ve zdravotnickém systému zejména nárok (do značné míry Ústavou zajištěný) na zdravotní péči, a to v co největším objemu, kvalitě a při snadné dostupnosti zdravotních služeb (regionální i časové). Zároveň jsou ale všichni občané odpovědní za vlastní zdraví a tudíž objektem potenciálních informačních kampaní v rámci ochrany a posilování zdraví, motivačních či represivních kroků ze strany státní správy, jejichž účelem je ovlivňovat jejich chování směrem k lepšímu zdraví. U pacientů je důležité znát hlavní zdroje informací, které přímo či nepřímo ovlivňují jejich zdravotní stav či aktivní spolupráci při diagnostice a léčbě. Jsou jimi:    

Informace poskytnuté přímo zdravotníkem či zařízením (ústní, písemné, elektronické); Informace pasívně přijímané ze sdělovacích prostředků; Informace aktivně vyhledávané v tištěných či elektronických mediích, internetu; Cílené informace od některých skupin pacientů (např. handicapovaných, sdružení pacientů s konkrétním zdravotním problémem)

Právě pacientské organizace jsou jednou z forem aktivního vstupu pacientů do ovlivňování zdravotnictví, a to jak směrem k pacientům, tak směrem k dalším hráčům ve zdravotnictví. Právě různé pacientské organizace mohou být jak přispěvovateli, tak koncovými uživateli některých konkrétních informačních technologií. Subjektivní potřeby pacientů se zdaleka nekryjí s jejich potřebami objektivními a tato "šedá zóna" se neustále rozšiřuje s měnící s demografickou strukturou pacientů (viz níže).

Graf 6 srovnání věkové struktury obyvatel ČR v roce 2000 a předpokládané struktura v roce 2030 - ČSÚ (2008).

41 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 4 Pohled na nemoc a stonání.

Zatímco zdravotnictví poměrně efektivně funguje v průniku všech tří množin pohledů na nemoc a stonání (subjektivně vnímaná, diagnostikovaná a „skutečná“), jeho možnosti jsou omezené v případech reprezentovaných okrajovými oblastmi. Zatímco v minulosti zdravotnictví sloužilo zejména ke kurativním účelům, roste jeho význam jako poskytovatele chronické, paliativní, rehabilitační péče, neboť počet obyvatel, kteří trpí chronickým onemocněním či jiným zdravotním omezením neustále roste. Přestože se prodlužuje očekávaná délka života a tedy i počet seniorů, prodlužuje se také doba, po kterou lidé žijí s chronickým onemocněním či handicapem. Z toho důvodu se také nutně mění charakter zdravotní péče z kurativní na podpůrnou.

Graf 7 Redukce ztracených let života v čase v zemích OECD - OECD Health at a Glance (2011)

Z grafu výše vyplývá, že ve statistice ztracených let života dochází k velkému poklesu. Lidé neumírají předčasně na infekční onemocnění či úrazy, jako tomu bylo dříve. Na druhou stranu roste počet obyvatel, jejichž kvalita života je snížená chronickým onemocněním či handicapem. Ekonomicky je takový stav udržitelný pouze v případě, že pacient a jeho blízcí do značné míry převezmou odpovědnost za starost o své zdraví. K tomu je však základní podmínkou vybavit tuto cílovou skupinu dostupnými a validními informacemi o této problematice. Schéma níže popisuje navíc, jakou reálnou roli hraje zdravotní péče jako determinanta zdraví. Na následujícím obrázku síla šipky odpovídá reálnému vlivu na výsledné zdraví (délku, kvalitu života apod.). Zásadní vliv má životní styl (dle literatury až 60%), přičemž zdravotní péče sama o sobě ovlivňuje zdraví pouze asi z 15-20%.

42 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 5 Determinanty zdraví

Prevence, posilování a ochrana zdraví jsou z výše uvedených důvodů hlavní prostředek, jak dosáhnout vyšší úrovně zdraví a kvality života obyvatel. Tato potřeba je přirozeně spojena se specifickými informačními potřebami obyvatel ČR.

2.2.2

Základní data zdravotnického systému v ČR a mezinárodní kontext

Některá data již byla uvedena v předchozím textu (demografické údaje) a další jsou uvedena v souvislosti s ekonomickou analýzou zdravotnického systému. Níže v této kapitole jsou uvedena zejména základní data zdravotního systému ČR související s předmětem návrhu projektu, data poukazující na potenciální problémy a data zaměřená na mezinárodní srovnání zdravotního systému ČR.

43 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 6 Síť nemocnic ČR - ÚZIS (2011)

Graf 8 Struktura lékařů podle druhu zařízení - ÚZIS (2011)

44 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Graf 9 Srovnání počtu lékařů v rámci OECD v roce 2009 - OECD Health at a Glance (2011)

Počet lékařů na počet obyvatel v ČR je nad průměrem OECD a navíc neustále roste. Na druhou stranu ale, vyjádřeno počtem návštěv na lékaře (níže), ČR výrazně převyšuje většinu zemí v OECD ve vytíženosti. Poukazuje to na vysokou míru využívání (zneužívání) zdravotní péče.

Graf 10 Srovnání vytíženosti lékařů v roce 2007 a 2009 (před a po zavedení regulačních poplatků) - OECD Health at a Glance (2009 a 2011)

Dle grafů výše se navíc zdá, že morální hazard není hlavním důvodem zneužívání zdravotní péče v ČR. Jako jeden z důvodů se nabízí právě informační "negramotnost" systému (jak pacientů, tak zdravotníků), kteří uskuteční mnoho návštěv u lékaře, než naleznou odborníka, který jim pomůže. Ze zahraničních zkušeností to lze vysvětlit právě nedostatečnou přehledností systému pro pacienty (pacient neví, kde hledat pomoc, tedy uskuteční mnoho zbytečných návštěv) a také nedostatečnou orientací samotných zdravotníků (neumí pacientovi poradit, kde hledat pomoc). Významnou roli v této informační "karenci" hrají též zdravotní pojišťovny, které by primárně měli sloužit pro pacienty jako jejich "průvodci" systémem. Nezastupitelnou roli mají též primární lékaři, kteří představují známý

45 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ "gate-keeping" mechanismus. Jejich počet v poměru k ostatním lékařům je hrubým ukazatelem gatekeepingu. V mezinárodním srovnání je ČR pod průměrem OECD.

Graf 11 Poměr lékařů k celkovému počtu dle typu v rámci OECD v roce 2009 - OECD Health at a Glance (2011)

OECD provedla i studii zaměřenou přímo na gatekeeping, ze kterého ČR vyšla jako země bez reálných regulačních mechanizmů co do přístupu pacienta ke specializované péči.

Obrázek 7 Systém poskytování péče v zemích OECD v kontextu gatekeepingu - OECD (2010)

Tento stav má však také pozitivní stránky, a to zejména tam, kde rychlý a zbytečnými bariérami nekomplikovaný přístup pacienta k terciární péči ovlivňuje výsledek (tedy parametr včasnosti je zásadní), tedy v urgentní péči o pacienty například s infarktem myokardu a cévní mozkovou příhodou.

46 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Graf 12 Mortalita na infarkt myokardu po přijetí do nemocnice - OECD (2011)

Na tomto místě by bylo možné prezentovat rozsáhlé statistiky o zdravotním stavu obyvatelstva či další ukazatele. Ty však souvisí s elektronizací zdravotnictví pouze okrajově nebo vůbec.

2.3

2.3.1

Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky Technické a komunikační standardy

2.3.1.1 Datový standard Ministerstva zdravotnictví (DASTA) Datový standard MZ ČR verze 3 a verze 4 (dále v textu zkráceně DS3 nebo DS4 nebo obecně DASTA) slouží k předávání dat mezi zdravotnickými informačními systémy. Je využíván v každodenní praxi již více jak deset let a je zabudován do všech významných zdravotnických informačních systémů, používaných v České republice. Datový standard MZ ČR je používán od roku 1997 a ve své historii byl několikrát významně inovován. Přestože po uvolnění verze DS4 bylo deklarováno, že další rozvoj DS3 bude utlumen, praxe si vynucuje i nadále paralelní udržování linie DS3 i DS4. Zavádění DS4 do praxe je totiž i nadále relativně pomalé. Poslední větší změna ve stávajících blocích byla provedena v roce 2010, kdy byla významně upravena koncepce přenosu laboratorních výsledků. Základní změna mezi datovým standardem DS3 a DS4 spočívá v precizaci konceptu tzv. klinické události. S tímto pojmem se pracovalo v DASTA od počátku, nicméně od DS4 došlo ke změně identifikace klinické události, která byla v DS3 definována v podstatě pouze provádějícím subjektem a časem provedení. Nový koncept přiřazuje každé klinické události jedinečný identifikátor a formální označení typu události. Tento koncept umožňuje především jedinečnou identifikaci konkrétní události tak, aby při výměně informací mezi různými informačními systémy nemohlo docházet k duplicitnímu ukládání jedné události nebo naopak k přepisu události jinou nesouvisející informací a dále umožňuje snadnější vyhledávání konkrétních událostí a jejich správné zařazování v informačním systému příjemce. Koncept také umožňuje realizaci oprav i storna. Formální typologie událostí má dnes v DASTA 80 různých typů a je otevřena dalšímu rozšiřování. V terénu jsou však u různých systémů dostupné různé verze DASTA a v některých případech jde ještě o non-XML verzi.

47 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Formálním garantem DASTA je Ministerstvo zdravotnictví ČR, které prostřednictvím svého odboru informatiky objednává činnosti nutné k rozvoji DASTA od různých subdodavatelů. Organizační struktura DASTA je tedy velmi volná. V průběhu historie DASTA se několikrát zvažovaly různé možnosti formalizace (založení obecně prospěšné společnosti, začlenění DASTA pod jinou instituci) vždy však nakonec dosud převážila pragmatická úvaha neměnit systém, který přes veškeré nedostatky po léta poměrně stabilně funguje. Reálně totiž DASTA stojí dnes především na neformální spolupráci odborníků z různých firem, působících v oblasti zdravotnické informatiky a navzájem si konkurujících a vedle toho samozřejmě na aktivitě několika mála nezávislých odborníků, kteří se podílejí na koordinaci aktivit a jejich vlastní realizaci. Celkové náklady na údržbu datového standardu jsou poměrně nízké – v roce 2010 zaplatilo MZ ČR náklady na veškeré expertní služby (DS3, DS4, NČLP, aj.) zhruba ve výši 260 tisíc. K tomu je třeba připočítat jen náklady na provoz webové služby DASTA. Využívání DASTA i webové služby dodavateli i provozovateli informačních systémů je bezplatné. DASTA v současnosti definuje komunikační standard pro tyto okruhy komunikace mezi informačními systémy: 



 

Údaje o pacientovi o Výměna klinických údajů o pacientech mezi různými zdravotnickými informačními systémy o Výměna žádanek na vyšetření mezi různými zdravotnickými informačními systémy Zasílání výkazů a hlášení do Národního zdravotnického informačního systému (NZIS) do Ústavu zdravotnických informací a statistiky (vybraná část výkazů) o Národní pacientské registry – hospitalizace, porody, novorozenci aj. o Roční a pololetní výkazy o činnosti Podávání hlášení pracovní neschopnosti na Českou správu sociálního zabezpečení Speciální oblasti o Hlášení vyšetření pitné a užitkové vody (na podkladě DASTA, šířeno nezávisle)

Největší a nejtypičtější využití je v oblasti pacientských dat. DASTA umožňuje výměnu zdravotnických informací o pacientovi zhruba v následující struktuře a rozsahu: 



            

Obecné informace datové zprávy o Informace o odesílateli dat o Informace o časech (žádosti, vyšetření, odeslání apod.) o Klasifikace urgentnosti zprávy o Typy přenášených dat Identifikátory o Identifikační data pacienta o Identifikace případu (číslo chorobopisu apod.) o Identifikátor události Základní administrativní informace o pacientovi Platební vztahy, pojišťovny Základní fyziologické údaje (hmotnost, výška) Urgentní klinické informace – diagnózy, alergie, krevní skupina Anamnéza Léky Očkování Diagnózy trvalé a aktuální Léky vydané lékárnou Žádanky a objednávky na vyšetření, včetně žádanek laboratorních Dokumentace vyšetření pacienta (výsledky, zprávy - formalizované, textové, obrazové) Provedené výkony vykazované pojišťovně nebo fakturované jinému plátci Další datové bloky

Vzhledem k tomu, že nejvýznamnějším důvodem vzniku DASTA byla potřeba komunikace s laboratorními informačními systémy, byl rozvoj DASTA vždy významně spojen s údržbou a koncepcí Národního číselníku laboratorních položek, který je garantován několika odbornými společnostmi z oblasti laboratorní medicíny. Tato

48 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ vazba je i nadále velmi významná a pro řešení komunikace s LIS zcela nezbytná. Národní číselník je však de-facto nezávislým datovým slovníkem, který by stejně tak dobře mohl fungovat s jakýmkoliv jiným komunikačním standardem, včetně HL7. Mezi další významné obecné rysy DASTA je dnes třeba řadit především následující: XML formát datové zprávy, možnost předávání kódovaného textu (RTF, HTML) při zachování povinnosti předání prostého nekódovaného textu zprávy, možnost předávání příloh, otevřenost dalšímu rozšiřování definice např. pomocí tzv. firemních bloků. Datový standard je dnes zabudován do většiny zdravotnických informačních systémů v ČR, především nemocničních, laboratorních, radiologických, ambulantních. Přehled firem, které DASTA respektují a implementují, lze nalézt na stránkách České společnosti zdravotnické informatiky a vědeckých informací, v podstatě ale lze říci, že v českém prostředí nemůže být dnes plnohodnotně provozován klinický, ambulantní nebo laboratorní informační systém, který by rozhraní DASTA neměl implementováno. Tato věc je někdy kriticky komentována ze strany dodavatelů zahraničních informačních systémů a je vnímána jako bariéra vstupu na český trh. Ve skutečnosti ovšem implementace národního rezortního rozhraní tvoří pouze velmi malou část z celkového rozsahu nezbytné implementace národního legislativního prostředí. DASTA a NČLP nejsou vždy implementovány zcela korektně, objevují se různé méně či více významné problémy při implementaci DASTA do praxe jako je zejména:        

Nekorektní realizace na straně odesílatele nebo příjemce. Zásadní chyby. Nelze však zde rozebírat podrobně. Vědomé nekorektní individuální úpravy DASTA pro vlastní potřeby konkrétní firmy. Na straně odesílatele je využívána vyšší verze DASTA nebo číselníků než na straně příjemce. Jiný výklad obsahu položek či pokynů v DS. V tomto případě je na vině často nedostatečně přesná nebo záměrně volnější specifikace standardu. Chyby v DASTA – vyskytují se vzhledem k rozsahu standardu zcela přirozeně - například rozpory mezi standardem a zněním metodiky NZIS. Nerespektování DTD – k popisu standardu se v mnoha systémech přistupuje stále tradiční formou, aniž by se využívaly nástroje, které umožňuje XML. Nekorektní užívání Národního číselníku laboratorních položek Chybné sledování položek v časové řadě - frakcionované clearance, OGTT atd.

Standard DASTA je využíván i při komunikaci zdravotnických informačních systémů se systémem IZIP i NZIS. Centrální úložiště na SÚKLu v žádné ze svých agend DASTA nevyužívá. Zhodnocení využitelnosti DASTA v podmínkách České republiky je tedy takové, že tento standard je již dnes v ČR široce využíván. Na jeho další rozvoj jsou u odborné veřejnosti velmi rozdílné názory. Jako nejvhodnější je jeví transfer obecných i národně specifických znalostí získaných jeho údržbou do standardu HL7 a archetypů openEHR. Dále by mělo dojít k oddělení Národního číselníku laboratorních položek (NČLP) ze standardu DASTA – podrobnosti k NČLP jsou uveden v samostatném bodě 2.3.2.4 NČLP. Není vhodné ani účelné snažit se povinně konvertovat systémy, které dnes DASTA využívají na HL7 či jiný formát. Vzhledem k požadavku přeshraničního sdílení by však lpění na DASTA v rámci nově zaváděného eHealth vedlo k tomu, že by bylo nutné udržovat komunikační rozhraní pro DASTA i HL7 variantu. V konečném důsledku by šlo pouze o odlišný formát XML zpráv obsahující identický datový obsah, čili jedna varianta rozhraní by měla být dostatečná a tou by měla být významně doplněná HL7.

2.3.1.2 Health Level 7 (HL7) Standard HL7 byl vyvinut v USA a nyní je oficiálním ANSI standardem. Historie vývoje standardu HL7 sahá do roku 1987, kdy na základě poptávky po dokonalejší komunikaci mezi informačními systémy ve zdravotnictví byla založena u příležitosti konference ve Stanford University Hospital, v Palo Alto, USA, pracovní skupina, jejímž cílem byla příprava formátů a protokolů pro výměnu dat mezi počítačovými systémy ve zdravotnictví. Mezitím byla založena nezisková organizace "Health Level Seven", zkratkou "HL7", která zastřešuje a koordinuje vývoj HL7 a publikuje standard. V České republice je přístup ke standardu HL7 zprostředkován sdružením HL7 Česká republika

49 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ na základě licence, která je k dispozici členům sdružení na základě ročního poplatku ve výši 8.000 Kč pro firemní členy.

Obrázek 8 Historie HL7 – Sdružení HL7 ČR

Komunikační standard HL7 byl vyvinut speciálně pro prostředí zdravotnické péče a zaměřuje se na komunikaci mezi nejrůznějšími institucemi v různých oblastech zdravotních služeb. Ve vrstvovém modelu OSI/ISO komunikace mezi otevřenými systémy je tato úroveň sedmou vrstvou, což vedlo k názvu HL7.

Obrázek 9 Model OSI - Sdružení HL7 ČR

Nejnižší běžně používanou verzí standardu je verze 2.3, která byla schválena jako ANSI standard v roce 1997. Verze 2.6 je zatím poslední z řady standardu verze 2, která byla schválena jako ANSI standard v roce 2007, protože ANSI standardizace 2.7 zatím není dokončena. Poslední verzí HL7 je verze 2.8 vydaná v září 2011. Přestože existuje iniciativa „v2.xml“ je zaměřena na převod komunikačního formátu HL7 2.X do XML, tak původním a oficiálním formátem HL7 2.X nadále zůstává EDI formát založený na definovaných oddělovačích (& | ^ ~) jednotlivých bloků a polí hodnot. Úspěch HL7 verze 2 v 90. letech minulého století spočíval ve vyřešení třech hlavních oblastí:   

Pomocí tzv. „de-facto LLP standardu“ definoval jednou cestu přenosu HL7 zpráv přes TCP/IP Díky EDI formátu HL7 bylo možné přenášené zprávy zapisovat a číst jednotným způsobem Byla stanovena rámcová struktura dat, která byla zároveň velmi flexibilní

Verze 3 HL7 byla pak významným posunem od obvyklého způsobu práce se standardem HL7. Původní proces definování zpráv ve verzi 2 byl stanoven v roce 1987 a fungoval dobře, zprávy série V2.X byly velmi úspěšné a

50 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ široce implementované díky velké volitelnosti a tím i flexibilitě. Tyto zprávy byly vyvinuty během řady let přístupem "zdola-nahoru", který řešil jednotlivé potřeby s užitím ad-hoc metodologie. Díky tomu není ani konzistentní pohled na data přenášená HL7 ani na vztah těchto dat k jiným datům. Obsahuje mnoho volitelných datových elementů a datových segmentů, což způsobuje, že jej lze adaptovat do téměř jakéhokoli prostředí. Tím, že poskytuje velkou flexibilitu, volitelnost řady částí způsobuje, že je nemožné provádět spolehlivé testy na shodu se standardem pro jakoukoli implementaci a nutí implementátory trávit více času analýzou a plánováním svých rozhraní, aby zajistili, že obě strany budou používat stejné volitelné rysy. Verze 3 řeší tyto a další problémy tím, že používá dobře definovanou metodologii, založenou na referenčním informačním (tj. datovém) modelu. Jedná se o dosud nejpřesnější standard v této oblasti. Důsledným používáním přesné analytické techniky a techniky pro tvorbu zpráv a zařazením více spouštěcích událostí a formátů zpráv s minimální volitelností, je primárním cílem HL7 ve verzi 3 nabídnout standard, který bude jednoznačný a testovatelný a bude poskytovat možnosti ověřit shodu dodavatele (resp. jeho řešení) se standardem HL7. Verze 3 využívá objektově orientované metodologie a Referenčního informačního modelu (RIM) pro tvorbu zpráv. Dle vyjádření organizace HL7, bude podporována nadále aktuální verze řady 2 i 3, tak aby byla udržena kontinuita stávajících systémů. Každopádně pro novou implementace eHealth na národní úrovni připadá v úvahu jedině řada verze 3. Řada 2 byla orientována více na řešení problémů v rámci IS jednoho poskytovatele zdravotních služeb, kteří si je díky flexibilitě zpráv mohli přizpůsobit dle svých potřeb. Tato flexibilita je na národní úrovni nežádoucí, respektive by bylo potřeba stejně stanovit mnoho doplňujících pravidel, které by ji omezily. Obecně lze také říci, že zatímco HL7 2.X se soustředí na to jak data přenášet mezi systémy, tak HL7 3.X se soustředí na strukturu dat samu o sobě. Dalším výhodou je nativní XML formát HL7 verze 3. Dále je blíže popsán postupný proces „zhora-dolů“ kterým se postupuje při implementaci HL7 do praxe.

RIM

D-MIM

R-MIM

HMDs

Obrázek 10 Schéma metody tvorby zpráv "shora-dolů" v HL7 verze 3

RIM (Referenční informační model - Reference Information Model) je všeobjímající informační model, který je zdrojem struktury všech zpráv HL7. RIM je záměrně abstraktní, takže umožňuje reprezentovat rozmanitost informací, sdílených v rámci zdravotního systému. RIM operuje s pojmy jako Entita (které reprezentují Organizace, Osoba, Materiál, Místo, …), Role (Pacient, Pracovník, …), Akce (Výkon, Pozorování, Návštěva pacienta, Finanční transakce, …) a Participace. RIM je udržován v procesu spolupráce a shody všech technických komisí a skupin zvláštního zájmu (Special interest group – SIG). Tento proces, nazývaný harmonizace modelu, používá standardních procedur pro připomínkování, diskuse, vylepšování a zpracování změnových návrhů, zaslaných technickými komisemi.

51 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 11 Základní HL7 RIM diagram

D-MIM (Doménový informační model zpráv - Domain Message Information Model) je zpřesněnou podmnožinou RIM, obsahující množinu odvozených tříd, atributů a vztahů, které mohou být použity při tvorbě zpráv pro určitou doménu (určitou oblast zájmu v rámci zdravotnictví). Domény z oblasti administrativy jsou například Vykazování a proplácení, Plánování nebo Účetnictví. Doménami z klinické oblasti jsou například Očkování, Kardiologie, Laboratorní výsledky, Lékárna a podobně. Zjednodušeně si lze postup odvození D-MIM z RIM představit takto:    

Z RIM se vyberou třídy podstatné pro danou doménu – může se stát, že některé třída (například Pracovník) bude potřeba vícekrát Zvolí se odpovídající vazby mezi jednotlivými třídami, tak aby výsledek neodporoval RIM U každé třídy se vyberou atributy podstatné pro danou doménu – lze vybírat pouze z atributů obsažených v RIM Pro atributy se zvolí datové typy a slovníky (číselníky), tak aby výsledek neodporoval RIM

D-MIM se používá jako společný základ, na kterém jsou vystavěny všechny R-MIM (zpřesněné informační modely zpráv) v rámci domény. Speciálním typem R-MIM jsou tzv. CMET (Common Message Element Types). Tyto reprezentují často používané „stavební bloky“, které se opakují ve více D-MIM (jako třeba Laboratorní vzorek, nebo Informovaný souhlas). Zjednodušeně si lze postup odvození R-MIM z D-MIM představit takto:  

  

Z D-MIM se vyberou třídy podstatné pro danou doménu – může se stát, že některé třída bude potřeba vícekrát Třídy se pojmenují specializovanými názvy. Pokud je nějaká třída potřeba vícekrát, použije se různý název. (například u třídy Osoba klonovanou pro hypotetickou doménu „Konzilia“ by to byl třeba Žádající lékař, Konziliář a Primář a pro třídu dokument by to byla Žádanka a Zpráva, a dále se pojmenují vazby - Žádající lékař „posílá“ Žádanku, Primář „vysílá“ Konziliáře, Konziliář „je autorem“ Zprávy) Odstraní se přebytečné třídy bez atributů a vazeb U vazeb se nastaví jejich násobnost (například „0 – N“ nebo „přesně jedna“) Upřesní se datové typy a slovníky

52 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Z R-MIM se následně vytvoří jednotlivé HMD (Hierarchické definice zpráv - Hierarchical Message Definition). Zjednodušeně si lze postup odvození HMD z R-MIM představit takto:     

Vybere se třída, která bude sloužit jako kořenový bod serializace Postupně se procházejí třídy a vazby mezi třídami a přebírají se atributy Pro každý atribut se definuje jeho násobnost, povinnost či podmíněnost Deklarují se další omezení související například s výběrem hodnoty z číselníku Každý atribut se pojmenuje odpovídajícím srozumitelným názvem

HMD se pak převede do konkrétní technologie pomocí ITS (Implementovatelná technologická specifikace Implementable Technology Specification). Obvykle se HMD převádí do XSD pro použití s XML zprávami nesoucí vlastní datový obsah. Tím se převede dvoudimenzionální R-MIM do jednodimenzionálního datového proudu. HL7 verze 3 definuje na základě RIM v zásadě dvě hlavní možnosti jak nakládat s datovým obsahem: 



Jako se zprávou, kterou generuje nějaký systém za účelem oznámení nějaké události (propuštění pacienta z oddělení) dalším systémům či požadavku na data od jiného systému (například z centrálního registru pacientů) Jako s dokumentem, který představuje nějakou archivovatelnou informaci ve struktuře CDA (Clinical Document Architecture)

Například na procesy elektronické preskripce se pak lze dívat buď jako na předávání dokumentu „recept“ mezi jednotlivými aktéry anebo jako na předávání zpráv typu „požadavek na předepsání léčiva“ a „odpověď na žádost o proplacení receptu“. Přestože je pohled „přes dokumenty“ modernější, má určitá rizika, která jsou dobře patrná například z diplomové práce s názvem „Integrace aplikací v oblasti zdravotnictví - Elektronická preskripce v ČR s využitím datového standardu HL7“ (Slavětínský) popisující možnost konverze rozhraní Centrálního úložiště na SÚKLu do formátu HL7. Vedlejším efektem je totiž významné zvětšení objemu dat, protože dokumentu musí obsahovat zároveň strojově i lidsky čitelnou podobu nesené informace. Dalším problémem odkrytým touto diplomovou prací je skutečnost, že by bylo nutné doplnit do HL7 specifika vyžadovaná českou legislativou, což je běžný postup i v jiných zemích kde se HL7 implementuje na národní úrovni. Dalšími součástmi HL7, kromě RIM a odvozených D-MIM, R-MIM, HMD, ITS, CMET, CDA a souvisejích metodik jsou například:  



Scénáře (Storyboards) – konkrétní případy užití pro zprávy HL7 popisující standardizovaným způsobem výměnu zpráv mezi odesílatelem a příjemcem v závislosti na okolních událostech Funkční specifikace EHR/PHR – jde v podstatě o seznamy požadavků na zdravotnické systémy zabývajíc se evidencí elektronických zdravotních záznamů, proti kterým lze testovat ověření jejich splnění. Jde o obdobu certifikačního schématu ProREC/EuroREC. Komunikační protokol MLLP – vzhledem k běžnému použití jiných komunikačních protokolů není jeho použití v nových systémech příliš aktuální

Aktuálně se v ČR používá HL7 v různých verzích v oblasti nemocniční informatiky zejména v rámci komunikace v oblasti radiologie, protože některé modality tuto technologii vyžadují pro plnou kompatibilitu s NIS. Dotazníkovým šetřením mezi uživateli DASTA bylo v roce 2010 zjištěno 6 takových výrobců. Obecně lze říci, že zahraniční nemocniční informační systémy obvykle disponují určitou formou generátoru ADT (Admission, Discharge, Transfer – Příjem, propuštění, Překlad) zpráv, které zachycují základní práci s pacientem, nicméně tyto jsou v ČR implementovány jen naprosto výjimečně. Nutno poznamenat, že HL7 je v zahraničí někdy kritizováno pro své nedostatky, které vyplývají z jeho koncepce. Především jde o snahu vytvořit jeden všeobjímající informační model (RIM), který bude zároveň dostatečně obecný a zároveň bude umožňovat dostatečnou konkretizaci pro reálné problémy. Dalšími často zmiňovanými problémemy jsou otázky identifikátorů, strmá křivka učení a občasná neurčitost dokumentace i samotných modelových konceptů.

53 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Zhodnocení využitelnosti HL7 v podmínkách České republiky je tedy takové, že tento standard je použitelný ve zdravotnické informatice v rámci ČR. V případě, že by měl standard HL7 nahradit DASTA například v oblasti laboratorních žádanek, nebo předávání dat do NZIS a nebo vůbec obecně použit v rámci ČR, musel by být významně doplněn proti aktuální verzi na obecné i národně specifické úrovni. Například Národní číselník laboratorních položek by musel být začleněn do HL7 jako datový slovník, definován identifikátor pacienta používaný v ČR, a podobně. Tato aktivita by musela být financována přímo státem v rámci rozvoje národního eHealth podobně jako byl dříve financován rozvoj DASTA. Dále vzhledem k pomalé adopci nových verzí DASTA u stávajících dodavatelů zdravotnických IS nelze očekávat, že by v například v oblasti laboratorních žádanek HL7 v blízké době vytěsnil standard DATSA. Nová komunikační rozhraní v rámci eHealth zaměřeného na sdílení dokumentace by však bylo možné založit na takto doplněném standardu HL7. Dlužno poznamenat, že využití části CDA ze standardu HL7 bude nutné přinejmenším pro přeshraniční sdílení, protože v rámci projektu epSOS se nyní využívá HL7 CDA a bylo by zjevně nehospodárné implementovat principiálně shodné služby ve dvou rozhraních (jedno pro národní a druhé pro mezinárodní sdílení). Dle dotazníkových šetření v roce 2010 se většina vývojářů využívající DASTA stavěla k náhradě DASTA standardem HL7 většinou negativně, nicméně tento fakt lze přičíst také nízké edukaci o principech HL7 mezi informatiky v ČR – v konečném důsledku jde pouze o změnu struktury XML.

2.3.1.3 Digital Imaging and Communications in Medicine – standard pro výměnu obrazových informací (DICOM) DICOM ( Digital Imaging and Communications in Medicine) je standard pro manipulaci, skladování, tisk a předávání informací ze zobrazovacích vyšetření ve zdravotnictví. Zahrnuje dvě základní součásti: definici souborového formátu a síťový komunikační protokol. Komunikační protokol je aplikačním protokolem, který používá TCP/IP pro komunikaci dvěma mezi systémy. DICOM soubory mohou být vyměňovány mezi dvěma subjekty, které jsou schopny přijímat obrazová data a data pacienta ve formátu DICOM. Standard DICOM tak umožňuje integraci skenerů, serverů, pracovních stanic, tiskáren a síťového hardwaru od různých výrobců do Systému pro archivaci a komunikaci zobrazovacích vyšetření (PACS). Autorská práva na tuto normu vlastní National Electrical Manufacturers Association (NEMA). DICOM je známý jako NEMA PS3, a je také ISO standardem 12052:2006 "Health informatics -- Digital imaging and communication in medicine (DICOM) including workflow and data management". Standard DICOM rozeznává několik základních služeb, které jsou využívány v rámci PACS:     

Store a Store commitment – ukládání pořízených či donesených snímků a potvrzování uložení Query/Retrieve – získání seznamu snímků či studií a získání konkrétního snímu či studie Modality worklist – tato služba umožňuje určité modalitě (např CT přístroji) získat seznam objednaných vyšetření a eliminovat tak chyby při ručním přepisování dat obsluhou Modality performed procedure step – notifikace o provedeném vyšetření, která může obsahovat informaci o radiační zátěži Printing – tisk snímků a studií na specializovaných tiskárnách

Zhodnocení využitelnosti DICOM v podmínkách České republiky je tedy takové, že tento standard již se běžně v rámci ČR využívá. Je široce podporován zobrazovacími modalitami (přístroji) a rovněž každý PACS prodávaný v ČR obsahuje podporu DICOM. Existují i zdarma dostupné prohlížeče DICOM soborů a tedy jde o formát využitelný i laickou veřejností (pacienty) při exportu výsledku zobrazovacích vyšetření DICOM. Diskutabilní je však v ČR podpora služby „Modality performed procedure step“, která umožňuje automatický přenos informací o radiační zátěži a tyto údaje tak někdy nejsou dostupné přímo v digitální strukturované formě. Informaci o radiační zátěži je tak nutné někdy ručně přepisovat.

2.3.1.4 Integrating the Healthcare Enterprise (IHE) IHE je inciativou vzniklou primárně na popud odborníků z oblasti radiologie. IHE zajišťuje interoperabilitu systémů ve zdravotnictví a využívá HL7 a DICOM jako stavební bloky jednotlivých procesů. Sdružení IHE je mezinárodní organizací, která se zaměřuje na vývoj globálních Integračních profilů IHE a na regionální implementaci interoperabilních produktů. Sdružení IHE také organizuje setkání nazývané Connectathon, na kterých se setkávají

54 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ výrobci, kteří testují vzájemnou interoperabilitu svých produktů. Produkty jsou pak vybaveny tzv. IHE Integration Statements, což je dokument s uvedením kompatibilních Integračních profilů IHE. V dnešní době se již IHE nezaměřuje pouze na radiologii, ale vytváří integrační profily pro následující odbornosti a oblasti:           

Patologie Kardiologie Oční lékařství IT infrastruktura Laboratoře Koordinace péče o pacienta Medicínské technologie (např. řízení infuzních pump, komunikace s kardiostimulátory, apod.) Lékárna Kvalita, výzkum a veřejné zdravotnictví Radiační onkologie Radiologie

Příkladem IHE profilu je Plánované vyšetření (Scheduled Workflow).

registrace pacienta NIS

Pracovní stanice popisovny

IS radiologie

PACS

snímek

Modalita

Obrázek 12 Workflow v rámci IHE Profilu Scheduled Worflow

Zhodnocení využitelnosti IHE v podmínkách České republiky je tedy takové, že tento standard již se běžně v rámci ČR využívá. Je široce podporován zejména zobrazovacími modalitami (přístroji) a rovněž každý PACS prodávaný v ČR obsahuje podporu alespoň některých profilů IHE. Podpora mimo oblast radiologie v rámci CŘ je však prakticky nulová. Dlužno poznamenat, že využití IHE bude pravděpodobně nutné přinejmenším pro přeshraniční sdílení zdravotnické dokumentace, protože v rámci projektu epSOS se nyní IHE využívá konkrétně ve formě rozšíření integračních a obsahových IHE profilů XCPD, XUA, XDR, XDS-SD, ATNA, BPPC a zejména XCA (Cross Community Access). Bylo by vhodné proto standard IHE v ČR institucionalizovat, podobně jako tomu je u Rakouska, Francie, Německa, Itálie, Španělska, Švýcarska, Nizozemí, Turecka a Velké Británie. Jednou z možností institucionalizace je svěření do péče sdružení HL7 Česká republika, vzhledem k těsnému vztahu HL7 a IHE.

55 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2.3.1.5 openEHR a EN13606 Standard openEHR je otevřenou specifikací v oblasti zdravotnické informatiky, zaměřená na správu, ukládání, čtení a výměnu údajů o zdraví v rámci EHR. Jejím cílem je zajištění sémanticky interoperabilní výměny EHR. V rámci openEHR jsou všechny zdravotní údaje uložena v celoživotním EHR orientovaném na pacienta, který je nezávislý na konkrétním dodavateli. Specifikace openEHR byla poprvé vydána v roce 2006 a je udržována neziskovou organizací openEHR Foundation. Norma CEN/ISO EN13606 Health informatics - Electronic Health Record Communication obsahuje podmnožinu kompletní openEHR specifikace. Je nutné zdůraznit že norma EN13606 je specifikací pro výměnu extraktů z EHR, nikoliv pro celý EHR systém, který má mnoho dalších nutných vlastností, jako je verzování, workflow, rozhraní na další systémy a podobně. Specifikace openEHR používán duální architektonický model, ve kterém jsou odděleny informace a znalosti. Informace jsou strukturovány pomocí Referenčního modelu, který obsahuje základní entity pro zachycení jakékoliv informace v rámci EHR. Znalosti jsou pak reprezentovány pomocí tzv. Archetypů, což jsou formalizované definice klinických konceptů využívající entity Referenčního modelu. Ve srovnání s HL7 RIM lze říci, že openEHR se spíše než modelováním veškeré reality ve zdravotnictví zaměřuje na modelování samotné zdravotnické dokumentace, což je pro klinické zdravotníky obvykle pochopitelnější přístup. Archetypy mohou být v rámci openEHR celkem 4 typů: 

 



Kompozice – reprezentuje obvykle totéž, co v papírové podobě reprezentuje jeden formulář zakládaný následně do dokumentace. Příkladem je například Záznam o předoperačním vyšetření anesteziologem či Mikrobiologické konzilium. Dalo by se říci, že openEHR Kompozice odpovídají zhruba HL7 CDA. Sekce – reprezentuje obvykle totéž co určitá část formuláře s vlastním nadpisem a napomáhá orientaci v záznamu. Příkladem je závěr nebo vyšetření. Záznamy – nejběžnější druh stavebního bloku EHR, obsahující vlastní klinické informace. Může být celkem 4 druhů: o Pozorování – jde o záznamy zahrnující anamnézu, nálezy při vyšetření, laboratorní výsledky, měření a jiné pozorovatelné skutečnosti. Příklady zahrnují například krevní tlak, Apgar scóre či hmotnost. o Hodnocení – jde o klinické interpretace nálezů, kdy klinický pracovník vychází s informací zachycených v Pozorování a dochází k určitému závěru, například diagnóze, posouzení rizika, identifikaci nežádoucí události o Instrukce – jedná se o žádanky či doporučení k dalšímu průběhu péče, kterými se zahajuje nějaké další workflow péče, jako například podání medikace či překlad o Akce – používají se pro záznam toho, jak byly Instrukce provedeny, například že výkon byl naplánován či proveden, léčivo bylo předepsáno, vydáno a podáno. Akce může zachycovat stav Instrukce, jako například „aktivní“, „dokončeno“ nebo „zrušeno“. Klastry – jde o znovupoužitelné fragmenty klinické informace, které představují stavební bloky, které lze opětovně využít v rámci Záznamů, jako je například anatomická lokace nebo vzorek

Dalším základní součástí openEHR jsou Šablony (Templates). Šablona definuje vlastní vzhled formuláře na obrazovce, tiskové sestavy či zprávy a sdružuje výběr použitých archetypů, klasifikací, terminologií, jazyků a dalších podrobností. Šablona také omezuje jinak poměrně univerzální Archetypy, které vlastně určují strukturu databáze pro uložení dat, pro konkrétní případ užití. Příkladem Šablony je pak například překladová zpráva, nebo recept. Výhoda tohoto přístupu je v tom, že modely archetypů se udržují samostatně od informačních systémů a mohou je udržovat i sami zdravotníci, kteří jsou odpovídajícím způsobem vyškoleni. Archetypy jsou definovány pomocí Archetype Definition Language (ADL) a díky své jazykové nezávislosti mohou být sdíleny i mezinárodně a lokalizovány do podmínek konkrétní země. V globální knihovně se nachází několik set hotových Archetypů. Vlastní EHR se pak dle standardu openEHR skládá z následujících částí:    

Základní informace – identifikátor EHR, datum a čas vytvoření EHR, identifikátor EHR systému Pravidla zabezpečení – jaké skupiny uživatelů mají přístup ke kterým částem EHR Stav – identifikace pacienta a stavu EHR (aktivní / neaktivní) a další informace společné pro celý EHR Kompozice – oblast nesoucí vlastní datový obsah EHR, přičemž nové zápisy se ukládají vedle původních, které se nemažou, čímž se dodržují běžná pravidla vyžadovaná legislativou

56 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

Kartotéka – volitelná součást, obsahujíc hierarchickou strukturu Složek, které obsahují odkazy na jednotlivé Kompozice. Na jednu kompozici může odkazovat více složek. Složky můžou být následujících typů: o Subjekt – odkazy na kompozice obsahující klinicky relevantní demografická data pacienta o Perszistentní – odkazy na kompozice obsahující informace platné z dlouhodobého hlediska o Událost – odkazy na kompozice obsahující informace platné pouze krátkodobě po uložení o Epizoda_XYZ – spíše než používání jedné složky Událost může být vhodnější seskupovat odkazy na kompozice do jednotlivých epizod (časových intervalů ve kterých byla poskytována péče týkající se jednoho nebo více identifikovaných problémů) nebo dle jiných kritérií

Obrázek 13 Příklad openEHR Šablony pro formulář se záznamem o rodičce v australském státě Severní teritorium

57 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Zhodnocení využitelnosti openEHR v podmínkách České republiky je tedy takové, že tento standard se dosud v rámci ČR nevyužívá. Není ale důvod se tomuto standardu vyhýbat. Výhodou openEHR je totiž skutečnost, že zdravotníci díky modelování archetypů získávají plnou kontrolu nad strukturou zdravotnické dokumentace. To znamená, že pokud by NIS v rámci ČR byly kompatibilní s openEHR, mohla by například odborná společnost vydat jako součást svého doporučeného postupu i schémata pro dokumentaci dle openEHR a jejich implementace v NIS byla prakticky okamžitá. Standard openEHR by proto měl být v ČR institucionalizován a měla by být provedena edukace zdravotnických informatiků a následně i odborné veřejnosti o tomto nástroji a jeho praktických výhodách. Měl by být pak realizován pilotní projekt zaměřený na jednu konkrétní odbornost, kdy by dokumentace určitého procesu byla podpořena vydáním jejího openEHR schématu. Podobně byl proces zavádění openEHR realizován například v NHS ve Velké Británii, kde byly vydány openEHR šablony pro deset nejčastějších problémů na oddělení Emergency zahrnující bolest na hrudi, dechovou nedostatečnost a bezvědomí. Normu EN13606 využívá i dokumentace projektu epSOS pro definici EHR extraktů, používaných v rámci přeshraniční výměny dat.

2.3.2

Nomenklatury a klasifikace

2.3.2.1 Klasifikační schémata WHO, ÚZIS a zdravotních pojišťoven v ČR Mezi základní nomenklatury s mezinárodní platností, využívané běžně v rámci zdravotnictví ČR patří zejména základní klasifikační schémata WHO:  

Mezinárodní klasifikace nemocí – 10. revize (MKN-10 / ICD-10) Anatomicko-terapeuticko-chemická klasifikace léčiv (ATC skupiny)

Použití těchto standardů v ČR je žádoucí a je na vysoké úrovni. Je však nutné si uvědomit, že ačkoliv se mezinárodní přenositelnost například u MKN-10 jeví jako implicitní, některé jiné státy dosud pracují například s předchozí revizí MKN-9. V rámci určitých odborností a zdravotnických agend v ČR se používají i další nomenklatury WHO a dalších organizací, které lze považovat za mezinárodně přenosné:     

Mezinárodní klasifikace funkčních schopností, disability a zdraví (MKF / ICF) Mezinárodní klasifikace pro bezpečnost pacientů (ICPS) TNM - Klasifikace zhoubných novotvarů, 7. vydání Grading konkrétních chorob (CCS a NYHA v kardiologii) Různé skórovací systémy (ASA v intenzivní péči, Norton v ošetřovatelství)

Kromě mezinárodně platných standardů je používána také celá řada národních nomenklatur, která garantuje přenositelnost mezi jednotlivými aktéry systému zdravotnictví v ČR.   

Číselníky vydávané SÚKL (zejména KLK a Seznam hrazených přípravků) Číselník PDK vydávaný společností PharmData – klasifikace lékárenského sortimentu (včetně zdravotnických prostředků) Číselníky VZP vydávané pro účely vykázání péče (kromě výše uvedených)

Zhodnocení využitelnosti těchto standardů v podmínkách České republiky je takové, že tyto standardy jsou již dnes v ČR široce využívány. V jejich využívání není potřeba zásadních změn, nicméně bylo by vhodné se zaměřit na edukaci odborné veřejnosti v oblasti postupů kódování, které v některých případech není konzistentní. U číselníků SÚKL přebíraných VZP je problematická konzistentnost jeho datového obsahu pro využití v některých oblastech zdravotnické informatiky. Vzhledem k tomu, že identický lék s jinou zemí výroby má přidělen jiný kód a že pole SÍLA a BALENÍ nemá kodifikovaný formát a v mnoha případech tyto pole nejsou vyplněna, je v některých případech obtížné automatizovaně vyhodnotit „shodnost“ léčiva. Pole ATC je pro tento účel nedostačující a to nejen u fixních kombinací účinných látek, které mohou být v rámci jedné ATC skupiny přítomny v různém poměru.

2.3.2.2 Seznam zdravotních výkonů s bodovými hodnotami a jeho alternativy Aktuálně platný Seznam zdravotních výkonů s bodovými hodnotami je platný ve znění daném vyhláškou č. 411/2011 Sb., kterou se mění vyhláška Ministerstva zdravotnictví č. 134/1998 Sb., kterou se vydává seznam zdravotních výkonů s bodovými hodnotami, ve znění pozdějších předpisů.

58 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Jde o seznam výkonů, které by měli používat poskytovatelé zdravotních služeb k vykazování péče poskytnuté pacientům, respektive pojištěncům zdravotní pojišťovny. Na základě těchto výkazů by měly být poskytovatelům propláceny jejich výkony a to buď v systému „fee-for-service“ obvyklém v ambulantním sektoru, nebo jsou následně na jejich základě nejprve sestavovány DRG případy. V praxi nicméně dochází k doplňování tohoto seznamu jednotlivými pojišťovnami o další kódy. Zhodnocení využitelnosti tohoto standard v podmínkách České republiky je takové, že představuje v současné podobě významný problém z hlediska budoucí přeshraniční interoperability i další využití výkazů pro zdravotní pojišťovny pro jiné účely jako je výzkum či hodnocení kvality a efektivity péče. Tento číselník je obtížně mapovatelný do jiných mezinárodních schémat pro svou historickou nekoncepčnost. V praxi se na jeho nedostatky naráží i v systému DRG, kdy bylo nutné jej doplnit tzv. signálními kódy pro reprezentaci skutečností, nezachycených v základních kódech. Tyto skutečnosti motivovaly v letech 2010 a 2011 Národní referenční centrum k realizaci projektu „Výběr Klasifikačního systému Procedur (KSP) pro Českou republiku - Pilotní testování“, ve kterém byly zkoumány alternativní systémy pro tento účel. Cílem bylo vyhodnocení KSP „jako takových“ a nikoliv vyhodnocení legislativních, organizačních a finančních aspektů navrhovaných změn. V rámci tohoto projektu byly zkoumány tyto alternativy: 







ACHI (australský systém) - Velmi kvalitní klasifikace, jejíž předností je přehlednost, vyváženost a solidní instrukce ke kódování. Je koncipována jako klasifikace procedur a do jisté míry i služeb, ovšem neobsahuje dostatečně služby konzultačního povahy. CCAM (francouzský systém) - Velmi kvalitní klasifikace, poněkud podrobnější a komplikovaněji koncipovaná (než australská), což je vyváženo velmi dobrým potenciálem pro analytické užívání.Je koncipována jako klasifikace procedur a služeb, ovšem neobsahuje služby konzultačního povahy. ICD-10 - PCS (systém USA, o němž bylo rozhodnuto, že bude zaveden v roce 2013) - Velmi podrobná a v mnoha ohledech zatím nedostižná klasifikace s ohromným potenciálem pro analytické využití (např. v oblasti registrů, státní statistiky). Těchto předností je dosaženo za cenu vzdálení se od obvyklé klinické terminologie a někdy i od obvyklého klinického pohledu. Klasifikace je koncipována jako klasifikace procedur a nikoliv jako klasifikace služeb a proto se jeví jako „nesamostatná“ (mohla by popisovat obsah služeb, ale nemůže popisovat „celek“ služeb). Seznam zdravotních výkonů s bodovými hodnotami - Klasifikace spíše služeb než procedur, trpící řadou nedostatků historicky podmíněných (obdobných jako většina prvních národních klasifikací). Významnými rysy jsou podřízenost oborovému pohledu, časté agregace značně rozdílných procedur pod jednu položku), chybění hierarchie, pomalé doplňování nových postupů do systému. Seznam výkonů byl ve většině vyhodnocovaných parametrů hodnocen hůře, než zbylé testované KSP.

Z celkového hodnocení vyšla jako nejlepší alternativa francouzský systém CCAM, nicméně v tomto zkoumání nebyl mimo jiné zohledněn požadavek na přeshraniční interoperabilitu. Dalšími doporučeními bylo také vést číselník laboratorních výkonů odděleně od seznamu ostatních výkonů a zajistit koordinaci tvorby klinických číselníků a pravidel kódování (procedur, diagnóz, DRG) svěřením těchto činností jedinému subjektu.

2.3.2.3 NANDA Klasifikace NANDA (North American Nursing Diagnosis Association - Severoamerická asociace pro sesterské diagnózy) je nomenklatura a taxonomie sesterských diagnóz. Je udržována stejnojmennou organizací, která je profesionální organizací sester pro standardizaci sesterské terminologie, založenou v roce 1982. V roce 2002 se NANDA změnila na NANDA International reagujíc tak na rozšiřující se členskou základnu. Jiné mezinárodní asociace jsou AENTDE (španělsky), AFEDI (francouzsky) a ACENDIO (Evropa). Současná struktura sesterských diagnóz NANDA se označuje jako Taxonomie II a má 3 úrovně: 13 domén, 47 tříd a 172 diagnóz. Zhodnocení využitelnosti NANDA v podmínkách České republiky je takové, že pokusy o použití tohoto standardu v praxi v ČR naráží na jeho nadměrnou košatost a obtížnou aplikovatelnost některých konceptů v praxi české sestry. Problémy jsou způsobeny i metodickým neujasněním postupů dokumentace ošetřovatelského procesu. Pro potřeby výzkumu v oblasti ošetřovatelství však v konečném důsledku bude nutné nějakou klasifikaci ošetřovatelských

59 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ diagnóz používat. Měla by proto být vytvořena pracovní skupina pro zhodnocení možnosti koncepčního zavedení NANDA nebo některé její mezinárodní alternativy do praxe v ČR.

2.3.2.4 NČLP NČLP (Národní číselník laboratorních položek) je obsáhlým číselníkem používaným v ČR pro identifikace laboratorních vyšetření. NČLP je součástí DASTA a byl zavedený do praxe metodickým návodem MZ ČR v roce 1997. NČLP je průběžně doplňován a rozšiřován ve vzájemné spolupráci předních společností klinických oborů s laboratorní složkou ČLS, České společnosti zdravotnické informatiky a vědeckých informací ČLS a MZ ČR. NČLP obsahuje přes 18 tisíc unikátních definic položek z oblasti biochemie, hematologie, transfúzní medicíny, imunologie, sérologie, mikrobiologie, nukleární medicíny, informatiky atd. Jednotlivé laboratorní položky v číselníku obsahují následující pole:     

Systém - ohraničené uspořádání množiny elementů a množiny vztahů mezi těmito elementy. Jedná se o předmět laboratorního vyšetření (biologický materiál; například plazmu). Komponenta - definovatelná část systému. Jedná se o vlastní měřenou veličinu (složku; například glukózu). Druh veličiny - vlastnost komponenty (předmětu), která může být kvalitativně odlišena a kvantitativně určena (látkové množství, délka, barva). Jednotka je určitá veličina, přijatá konvencí pro kvantitativní porovnávání veličin stejného druhu. Je úzce svázána s druhem veličiny. Procedura je laboratorní vyšetřovací postup, sloužící k získávání vlastností komponent a jejich případnému kvantitativnímu posouzení.

Každé laboratorní položce je přiřazen jednoznačný pětiznakový identifikátor (kladné celé číslo), jednoznačný. Příklad konstrukce položky NČLP s kódem 12352 je tedy následující: „Glukóza (P; látková konc. [mmol/l] abs. spektrofotometrie)“ a znamená „Glukóza měřená v plazmě stanovovaná jako látková koncentrace v jednotkách mmol/l metodou absorpční spektrofotometrie (metod, čili procedur je definováno více)“. Základní definice laboratorní položky je doplňována dalšími údaji, potřebnými pro informační systémy, datový standard, standardy efektivní lékařské péče a standardy managementu kvality klinických laboratoří. Jedná se zejména o název laboratorní položky, třídu komponenty, gesci, typ z hlediska dialogu, vznik, formát hodnoty a další údaje. Ke každé položce jsou k dispozici odkazy na další povinné nebo fakultativní informace. Zhodnocení využitelnosti NČLP v podmínkách České republiky je tedy takové, že tento standard je již dnes v ČR široce využíván. NČLP by měl být oddělen od standardu DASTA tak, aby se usnadnilo jeho využití v rámci budoucích doplnění HL7. Tento číselník je obdobou LOINC, který využívá HL7 jako preferovaný datový slovník pro laboratorní vyšetření a je vhodným základem pro eventuální mapování identifikace laboratorního vyšetření do jiné klasifikace, například SNOMED CT. Není vhodné ani účelné snažit se povinně konvertovat systémy, které dnes NČLP využívají na LOINC či jiný číselník. Měla by však být prozkoumána možnost mapování NČLP na LOINC a SNOMED CT a zpět. Tím by bylo možné zajistit sémantickou přeshraniční interoperabilitu při zachování funkčnosti stávajících systémů.

2.3.2.5 LOINC LOINC (Logical Observation Identifiers Names and Codes) je číselníkem a univerzálním standardem používaným v zahraničí pro identifikaci laboratorních vyšetření. Byl vytvořen americkou neziskovou organizací Regenstrief Institute v roce 1994. LOINC je veřejné dostupný zdarma. Od roku 1999 je LOINC v rámci HL7 považovaný za doporučený datový slovník pro reprezentaci laboratorních vyšetření. LOINC má vzrůstající mezinárodní komunitu – existují již překlady do zjednodušené čínštiny, němčiny a španělštiny. Číselník aktuálně zahrnuje cca 60.000 položek. Každé laboratorní vyšetření má v systému LOINC unikátní 6ti dílný název a každá z položek obsahuje 6 částí:  

Komponenta – co se měří, vyhodnocuje či pozoruje (např. Urea) Druh veličiny – charakteristika komponenty, jako je například délka, hmotnost, objem, čas a podobně

60 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“    

Časové hledisko – časový interval, ve kterém bylo vyšetření provedeno Systém – kontext nebo typ vzorku, ve kterém je vyšetření prováděno (např. krev, moč, …) Typ škály – škála, na které je měření prováděno (např. kvantitativní, ordinální, textový popis) Procedura – metoda použitá k měření či pozorování

Každá položka má přidělen kód o délce 3-7 znaků, přičemž poslední znak tvoří kontrolní součet. Další pole obsahují synonyma, příbuzné termíny, informace o látce (např. molární hmotnost), druhy odpovědí pro nominální škály, překlady a podobně. Nejzásadnější věcný rozdíl LOINC od NČLP spočívá v tom, že součástí položky v číselníku LOINC není jednotka. Ta se proto musí předávat jako samostatné pole laboratorního výsledku (vedle jeho hodnoty). Autory NČLP je tento přístup spatřován jako nekoncepční. Zhodnocení využitelnosti LOINC v podmínkách České republiky je tedy takové, že tento standard se dosud v ČR nevyužívá. Měla by však být prozkoumána možnost mapování NČLP na LOINC a zpět. Tím by bylo možné zajistit sémantickou přeshraniční interoperabilitu při zachování funkčnosti stávajících systémů.

2.3.2.6 SNOMED CT SNOMED CT (Sytematizovaná zdravotnická nomenklatura – Klinické termíny / Systematized Nomenclature of Medicine - Clinical Terms), byl vytvořen v roce spojením a úpravou referenční terminologie SNOMED RT (autorem College of American Pathologists) a Clinical Terms (autorem britská National Health Service). SNOMED CT je nyní udržován organizací The International Health Terminology Standards Development Organisation (IHTSDO) se sídlem v dánské Kodani, která dosud nemá národní zastoupení v ČR. SNOMED CT je systematicky organizovaná a strojově zpracovatelná množina zdravotnických termínů. Obsahuje kódy, termíny, synonyma a definice pokrývající nemoci, nálezy, výkony, infekční agens, účinné látky, a podobně. Umožňuje konzistentním způsobem ukládat, číst, indexovat a agregovat klinická data napříč jednotlivými odbornostmi tak, aby různé formulace významově stejných skutečnosti byly považovány za ekvivalentní. Pomáhá také při organizaci záznamů, omezuje variabilitu zápisu údajů. Primárním účelem SNOMED CT je podpořit efektivní záznam strukturovaných klinických dat. Tento soubor klinických termínů, které jsou používány mezinárodně pro záznam klinické informace, může být kódována pro pozdější strojové zpracování. Přestože kódování není povinné, reálně si použití SNOMED CT bez odpovídajícího software nelze představit. Pro použití v rámci určité země je obvykle nutný překlad do daného jazyka – díky použití jednotných kódů je pak možná přeshraniční interoperabilita i strojová srozumitelnost informace zapsané v EHT. SNOMED CT je dostupný v jazykových mutacích americké a britské angličtiny a španělštiny a probíhají překlady do dalších jazyků, například francouzštiny, holandštiny, dánštiny a švédštiny Národní edice založená na překladu do konkrétního jazyka může i obsahovat určitá národní rozšíření standardu. SNOMED CT je považován za jednu z nejrozsáhlejších vícejazyčných klinických terminologií na světě. Lze jej používat k záznamu lékařské zprávy konkrétního pacienta a podpoře pokročilých softwarových aplikací, jako je například podpora rozhodování, klinické cesty a znalostní báze. Existují mapovací tabulky pro konverzi mezi SNOMED CT a ICD-9-CM, ICD-O3, ICD-10, laboratorní LOINC a OPCS-4, nicméně z důvodu odlišného zaměření jednotlivých klasifikačních schémat obvykle není možné provést mapování 1:1. SNOMED CT podporuje ANSI, DICOM, HL7, and ISO standardy a pro reprezentaci SNOMED CT se používá jazyk OWL (Web Ontology Language), který je standardem konsorcia W3C. Základní jednotkou systému SNOMED CT jsou tzv. koncepty, což jsou určité myšlenkové konstrukce, které mohou mít v běžném jazyce několik názvů. Například výrazy „infarkt myokardu“, infarkt srdečního svalu“, „srdeční záchvat“ a konec konců i „infarkt“ je myšlen tentýž koncept, popisující situaci, kdy dojde k ischémii buněk srdečního svalu. SNOMED CT obsahuje více než 350.000 takovýchto konceptů, které mají každý unikátní identifikátor SCTID, které mají definovanou až 18ti cifernou syntax (například Infarkt myokardu má SCTID 22298006). Každý koncept má unikátní plný název („Infarkt myokardu – choroba“), doporučený název („Infarkt myokardu“) a případně sadu synonym. Celkový počet klinických termínů v rámci dosahuje 1 milionu. Význam použití konceptu je však závislý na jeho kontextu – podle toho, kde je použit ve zdravotní dokumentaci, může koncept „Infarkt myokardu“ znamenat: 

Pacient má nyní Infarkt myokardu

61 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“    

Hlavní diagnóza pacienta je Infarkt myokardu Pacient prodělal v anamnéze Infarkt myokardu U pacienta je podezření na Infarkt myokardu a podobně …

Kontext konceptu lze vyjádřit pomocí:   

pre-koordinace, kdy je využit předdefinovaný koncept v rámci základního SNOMED CT – například 160303001 Diabetes melitus v rodinné anamnéze post-koordinace, kdy je využito možnosti kombinace několika předdefinovaných konceptů – například 57177077+(246090004=73211009) Rodinná anamnéza + (vedlejší diagnóza = Diabetes mellitus) jinými nástroji – např. HL7 RIM atribut moodCode nebo třídou ActRelationship

Koncepty jsou v rámci SNOMED CT organizovány do vzájemných acyklických hierarchií pomocí „vztahů“, kterých existuje již kolem 1.500.000. Tyto vztahy mohou být v rámci SNOMED CT několika druhů:  

Vztah „něco JE něco“ - například Virová pneumonie JE Infekční pneumonie, která JE Pneumonie, což JE Choroba plic. Vztah „atribut – hodnota“ – například Virus „je kauzální příčinou“ Virové pneumonie, Zranění hlavy „má místo nálezu v oblasti“ Hlava a Virová pneumonie „má patologický podklad v“ Infekčním procesu.

Díky těmto vztahům je možné zajistit strojovou zpracovatelnost zaznamenané informace, které obvykle v textové podobě není možná. Například v případě „Pyogenního granulomu“ by se mohlo zdát, že význam tohoto slova bude souviset s pyogennitou (vytváření hnisu) a granulomem (shluk zánětlivých buněk určitého typu), ale ve skutečnosti jde o benigní nádor kůže, který nemá s hnisem ani zánětem nic společného.

Virová pneumonie

Virus

Infekční pneumonie

Infekční agens

Pneumonie

Infekční choroba

Choroba plic Obrázek 14 Schéma vztahů "JE" (is-a) v systému SNOMED CT

62 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Virová pneumonie

Kauzální příčina

Infekční agens

Infekční pneumonie

Pneumonie

Virus

Infekční choroba

Choroba plic Obrázek 15 Schéma vztahů "atribut - hodnota" v systému SNOMED CT

Při vlastním zadávání SNOMED CT kódů se používají specializované nástroje, poskytující seřazený seznam SNOMED CT položek, které jsou obvykle vyladěné pro jednu konkrétní odbornost. Takovéto nástroje musí zohledňovat skutečnost, že v rámci dané odbornosti není potřeba obvykle pracovat s plnou hierarchií všech položek, protože ta je velmi složitá.

Obrázek 16 Náhled na definici Infekce horních cest dýchacích v prohlížeči SNOMED

Mezi problémy praktické použitelnosti SNOMED CT se někdy uvádějí následující skutečnosti:  

Extrémní rozsah obtížně uchopitelný pro běžné pracovníky ve zdravotnictví Příliš mnoho úrovní hierarchie – například koncept Akutní apendicitida má 36 nadřazených taxonomických úrovní,

63 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“    

Více možností pro označení téhož – například pro popáleniny hlavy je možné najít celkem 350 různých konceptů Epistemická intruze – snaha o zachycení kontextu (například. „podezření na“ určitou diganózu) v rámci terminologických konceptů, které je vhodnější reprezentovat jinými nástroji Nesoulad mezi vztahy zachycenými ve SNOMED CT a současným stavem vědeckého poznání Potřeba konverze klasifikace SNOMED CT do skutečné ontologie

Zhodnocení využitelnosti SNOMED CT v podmínkách České republiky je tedy takové, že tento standard se dosud v ČR nevyužívá. Primárním problémem je neexistence českého překladu terminologie. Sekundárním problémem je absence aktuální poptávky po jeho použití, která plyne do značné míry z neinformovanosti možných klinických uživatelů i zdravotnických informatiků. SNOMED CT má přes své nedostatky i v aktuální podobě jednoznačně potenciál významně posunout způsob vědecké práce v biomedicíně, podpořit aplikovaný výzkum a zvýšit sémantickou interoperabilitu sdílených zdravotních záznamů zejména při přeshraničním sdílení. Z klinických záznamů pak lze případně i odvozovat automaticky kódy pro výkazy zdravotní pojišťovně, což může kompenzovat vyšší obtížnost záznamu klinické informace v rámci SNOMED CT namísto prostého či semi-strukturovaného textu. Cesta k zavedení SNOMED CT v rámci ČR by měla začít jeho institucionalizací v rámci ČR, následovanou vlastní lokalizací klasifikace (českým překladem). Adopci SNOMED CT na Slovensku oficiálně koordinuje Národné centrum zdravotníckych informácií – přímo řízená organizace MZ SR vzniklá sloučením slovenské obdoby ÚZIS a Národní lékařské knihovny. Podobný postup si lze představit i u nás, protože ÚZIS ČR dnes zajišťuje i překlad klasifikací MKN-10 i MKF.

Analýza způsobu využití historických a současných dat ve zdravotnických systémech

2.4

Vzhledem k potřebě zaměření eHealth na konkrétní pacienty, je níže uvedená analýza primárně zaměřena na data, které obsahují identifikace konkrétních pacientů. Data jsou analyzována primárně z hlediska možnosti sémantické interoperability, protože u dat existujících již v elektronické podobě je technická interoperabilita řešitelná vždy. Kromě těchto dat mají k dispozici všechny instituce zejména svá účetní data či skladové evidence a řadu další dat v jiných informačních systémech. Těmi se však tato analýza hlouběji nezabývá.

2.4.1

Klinické IS poskytovatelů zdravotních služeb

2.4.1.1 IS samostatných ordinací, nemocnic, odborných léčebných ústavů a lázní a záchranné služby Přestože zdravotnické dokumentace v ČR není většinou vedena ve výhradně elektronické formě, lze říci, že většina lékařské dokumentace (zprávy, epikrízy, žádanky, konzilia, dekurzy) vzniká primárně v elektronické nestrukturované podobě a tiskne se pouze pro potřeby splnění legislativních podmínek. Ošetřovatelská dokumentace je obvykle vedena primárně v papírové podobě. Strukturovány jsou pak obvykle pouze údaje vykazované do zdravotních pojišťoven, tedy:        

identifikace zdravotní pojišťovny, identifikace pacientů, časové vymezení (datum), diagnózy, odbornosti, kódy výkonů (diagnostické, intervence, očkování, …) kódy zvlášť účtovaných léčivých přípravků a materiálu, u vyžádaných vyšetření identifikace žadatele.

Pomocí DRG grouperu je pak obvykle možné dle těchto údajů zařadit hospitalizační případ do DRG skupiny, která by měla tvořit nejen ekonomicky, ale i klinicky homogenní skupinu. V případě, že probíhá komunikace žádanek a výsledků s laboratoří elektronicky, pak jsou v IS strukturovaně uložena i tato data. V některých případech je uložena strukturovaně i ordinace léčiv (na recept i bez receptu) či infůzí a diet (komunikovaných dále do dalších IS).

64 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR lze tedy využít nestrukturovaná i strukturovaná data. Pro přeshraniční sdílení lze využít pouze strukturované údaje, ale i tyto představují významné množství prakticky použitelných informací.

2.4.1.2 IS lékáren K léčivům vydaným na recept proplácený zdravotní pojišťovnou jsou v informačním systému lékáren uloženy následující informace:   

identifikace pacienta pomocí rodného čísla / čísla pojištěnce, časové vymezení výdeje, identifikace předepisujícího poskytovatele zdravotních služeb.

U záznamů o výdeji hromadně vyráběných léčiv jsou dále v systémech lékáren obsaženy tato data:   

kód léčiva dle číselníku SÚKL přebíraného VZP, cena pro koncového spotřebitele, cena původce, cena distributora, šarže a expirace léčiva.

U léčiv na recept pokud nejsou propláceny zdravotní pojišťovnou, tak v některých případech není do informačního systému zadávána identifikace pacienta. U léčiv vydávaných bez receptu není identifikace pacienta evidována. U elektronických receptů jsou dostupné v elektronické podobě i další údaje, jako například datum vystavení receptu či předepsaném dávkování. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR lze tedy tato data využít. Pro přeshraniční sdílení nelze využít kód číselníku SÚKL či VZP, ale lze jej konvertovat pomocí těchto číselníků do mezinárodně akceptovaných ATC kódů. Může však nastat problém s množstvím účinné látky, která není v číselníku vždy uvedena a v případech fixních kombinací účinných látek není v číselníku standardizován způsob jejich zápisu. Pro přeshraniční sdílení dále nelze využít informaci o předepsaném dávkování léčiva, která je i u elektronických receptů k dispozici ve volném textu či ve formě „1-0-1“, kterou nelze považovat za mezinárodní standard. Přesto i data obsahující identifikaci léčiva pouze ATC kódem představují významnou prakticky použitelnou informaci. U poukazů na zdravotnické prostředky je situace v zásadě obdobná jako u receptů na léčiva a záznamy tak u pojišťovnou proplácených prostředků obsahují identifikaci pacienta a kódové označení zdravotnického prostředku.

2.4.1.3 IS laboratoří Téměř všechny informace jsou v elektronické podobě dostupné v oblasti laboratorní medicíny bez ohledu na způsob komunikace žádanek a výsledků se subjekty požadujícími laboratorní vyšetření. K dispozici je obvykle ke každému laboratornímu výsledku:     

identifikace pacienta pomocí jména, příjmení a rodného čísla / čísla pojištěnce, datum narození a pohlaví pacienta, časové vymezení (datum) žádanky a výsledku, kód laboratorního vyšetření dle Národního číselníku laboratorních položek a jeho hodnota (číselná nebo textová v určitých oborech, jako je mikrobiologie či patologie), referenční rozmezí hodnot pro číselné výsledky, identifikace žadatele.

V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR lze tedy využít tato nestrukturovaná i strukturovaná data. Pro přeshraniční sdílení lze využít pouze strukturované údaje, nicméně je zde problém s překladem kódu laboratorního vyšetřeni do mezinárodně srozumitelného formátu.

2.4.1.4 IS pracovišť zobrazovacích modalit (RTG, CT, NMR, …) Údaje administrativního charakteru jsou blíže popsány výše v kapitole o klinických IS obecných poskytovatelů péče. Pokud se zaměříme na specifika této oblasti, pak jde zejména o elektronickou podobu vlastního zobrazovacího vyšetření. Lze konstatovat, že v dnešní době jsou již prakticky všechny nově pořizovaná RTG, CT a NMR vyšetření

65 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ dostupná v digitální podobě. Jsou buď přímo pořízena v digitální podobě, nebo jsou ex-post digitalizována. Snímek či studie je pak k dispozici ve vazbě na identifikátor pacienta ve standardizovaném formátu DICOM. Digitalizace záznamu je obvykle dostupná i u ultrazvukových nebo endoskopických vyšetření či laparoskopických intervencí, ale dynamická povaha těchto vyšetření vede obvykle k preferenci sdílení textového popisu závěru před grafickou podobou vyšetření. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR lze tedy využít tyto grafické podoby zobrazovacích vyšetření. Tato data lze využít i pro přeshraniční sdílení, přestože textový popis vyšetření je pouze v češtině.

2.4.2

Základní IS zdravotních pojišťoven

Základní IS zdravotních pojišťoven lze běžně rozdělit na část příjmovou, část výdajovou a registry. Pomocí propojení s EESSI Access Pointem Centra mezistátních úhrad se údaje v nich obsažené komunikují obousměrně se zahraničními kompetentními institucemi prostřednictvím sítě EESSI. Údaje výdajové části se dále předávají do Národního referenčního centra. Tímto způsobem se tedy již data v dnešní době sdílí na národní i přeshraniční úrovni.

2.4.2.1 Registry zdravotních pojišťoven Registry zdravotních pojišťoven obsahují informace o aktuálních a bývalých pojištěncích, plátcích pojistného, smluvních poskytovatelích zdravotních služeb a dalších subjektech, které využívají agendy příjmové a výdajové části. O jednotlivých pojištěncích se evidují obvykle zejména následující strukturované údaje:        

Identifikace pojištěnce (jméno, příjmení, rodné číslo, číslo pojištěnce) Datum narození Pohlaví Registrace pojištěnce k registrujícímu poskytovateli zdravotních služeb (v oborech praktický lékař pro dospělé či děti a dorost, gynekolog a stomatolog) Vzájemný vztah dvou pojištěnců (vyživovaná osoba) Kontaktní adresy a státní příslušnost Zaměstnavatel či jiný plátce Participaci na zdravotních programech dané pojišťovny (např. různé preventivní programy)

V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení lze tedy využít tato strukturovaná data. Pro přeshraniční sdílení se tato data vlastně začnou využívat ihned po ostrém spuštění EESSI Access Pointu Centra mezistátních úhrad, který bude některá EESSI workflow (týkající se například dotazu na pojistná období pojištěnce) vyřizovat automatizovaně online. Tento systém bude uveden do provozu na přelomu roku 2012/2013 a pro všechny členské státy EU bude povinný od poloviny roku 2014.

2.4.2.2 Příjmová část Část příjmová obsahuje obvykle zejména následující údaje:   

vazbu na identifikaci pojištěnce v registrech zdravotní pojišťovny evidenci předepsaného pojistného evidenci zaplaceného pojistného či nedoplatků

Příjmová část IS zdravotních pojišťoven bude od 1.1.2015 (v případě novelizace již od 1.1.2014) potlačena zavedením jednotného inkasního místa. Data z příjmové části nejsou přímo využitelná pro klinické účely. Reálně je možné uvažovat jedině o statistické analýze dat z výdajové části v návaznosti na socioekonomický status pojištěnce zachycený v příjmové části.

2.4.2.3 Výdajová část Výdajová část každé zdravotní pojišťovny obsahuje miliony záznamů o péči poskytnuté pojištěncům a proplacené poskytovatelům zdravotních služeb. Tyto záznamy obsahují zejména následující údaje: 

identifikace poskytovatele zdravotních služeb,

66 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“       

identifikace pacientů, časové vymezení (datum), diagnózy, odbornosti, kódy výkonů (diagnostické, intervence, očkování, …) kódy zvlášť účtovaných léčivých přípravků a materiálu, u vyžádaných vyšetření identifikace žadatele.

Kromě finančně oceněných výkonů jsou zdravotním pojišťovnám vykazovány i některé tzv. signální výkony. Tyto nenesou samy o sobě finanční hodnotu, ale slouží k indikaci nějaké skutečnosti pro potřeby výběru regulačních poplatků, DRG a podobně. Tato data se již dnes sdílí u některých zdravotních pojišťoven rámci ČR (například projekty Karta Života ZPMVČR nebo VitaKarta OZP) a nepochybně by nebyl technický problém zajistit jejich sdílení u všech pojišťoven. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení lze tedy využít tato strukturovaná data. Hlavní problém při sdílení těchto dat však spočívá v tom, že data jsou v systémech zdravotních pojišťoven ukládána s určitým zpožděním a v závislosti na konkrétním řešení v daném IS může jít i o několikaměsíční prodlevu. Část doby je dána měsíčním cyklem předávání výkazů zdravotní pojišťovně. Další čas uběhne při kontrole předaných záznamů před jejich uložením do provozní databáze. A dále je zde prodleva daná někdy publikací dat do oddělené databáze, která teprve záznamy zpřístupňuje.

2.4.3

Národní registry ÚZIS/KSRZIS

Vzhledem k dlouhodobé tradici NZIS v českém zdravotnictví, představují národní registry NZIS cenný zdroj údajů o zdravotním stavu pacienta. Údaje evidované v jednotlivých registrech jsou podrobně uvedeny u jednotlivých registrů v kapitole popisující stávající stav systému zdravotnictví v bodě 2.1.5 Státní správa. Klíčové záznamy v registrech obsahují identifikaci pacienta (pomocí rodného čísla) a jsou strukturovány. Jen samotný Národní registr kardiovaskulárních operací a intervencí a Národní onkologický registr pokrývají svým obsahem zhruba polovinu závažných chronických stavů, u kterých je významné zajištění kontinuity péče mezi poskytovateli. V kombinaci s Národním registrem hospitalizovaných jsou pokryty i všechny ostatní stavy, které byly někdy ve svém průběhu natolik závažné, že u nich byla nutná hospitalizace. Data do národních registrů se centrálně sbírají již několik desítek let. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení lze tedy využít tato strukturovaná data. Je zde však opět podobně jako u IS zdravotních pojišťoven otázka aktuálnosti těchto dat, respektive prodlevy mezi sledovanou skutečností a jejím nahlášením do registru. Situace kolem národních registrů NZIS však je nyní zkomplikována rozporováním smyslu, účelu a rozsahu sbíraných dat v NZIS u Ústavního soudu ČR. Nelze vyloučit, že verdikt soudu bude vyžadovat znehodnocení veškerých shromážděných dat v NZIS anonymizací. V takovém případě by byla data pro sdílení v rámci eHealth nepoužitelná. Nelze však ani vyloučit verdikt soudu ve smyslu požadavku na nahrazení rodného čísla subjektu jeho agendovým identifikátorem fyzické osoby (AIFO) ve smyslu Základních registrů. Tím by nebyla možnost využití těchto dat zásadně narušena, byť by byla technicky a organizačně složitější.

2.4.4

Centrální úložiště na SÚKL

Centrální úložiště elektronických receptů obsahovalo k 30.9.2012 celkem 210.942 eReceptů. Z těchto však byla realizována a v lékárně vydána pouze přibližně polovina, tedy 99.847 výdejů. Centrální úložiště elektronických receptů obsahuje kompletní elektronickou podobu receptu, protože vyhláška č. 54/2008, o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů, nerozlišuje aktuálně mezi obsahem papírového a elektronického receptu. Jde zejména o tyto údaje:

67 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“    

identifikace pacienta pomocí rodného čísla / čísla pojištěnce, jméno a příjmení pacienta časové vymezení předepsání a výdeje, identifikace předepisujícího lékaře a vydávajícího lékárníka.

U záznamů o výdeji hromadně vyráběných léčiv jsou dále v systému obsažena tato data:   

kód léčiva dle číselníku SÚKL přebíraného VZP, cena původce, šarže a exspirace léčiva.

V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení lze tedy využít tato strukturovaná data o elektronických receptech. Kromě elektronických receptů původně sbíral SÚKL do Centrálního úložiště také údaje o výdejích na papírový recept (tzv. agenda LEK-13) v prakticky shodné struktuře a rozsahu. Rozhodnutím Úřadu pro ochranu osobních údajů byl však donucen tento sběr dat rozdělit a záznamy o papírových receptech byly anonymizovány. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení by tedy bylo možné využít tato strukturovaná data pouze v případě, že by změna legislativy (zákona č. 378/2007 Sb., o léčivech) umožnila opět sbírat data o papírových receptech včetně identifikace pacienta. Nadále by však šlo o podmnožinu dat, která jsou dostupná v elektronické podobě u elektronického receptu.

2.4.5

Seznamy členů profesních komor a IS vzdělávacích institucí

Profesní komory vedou seznamy svých členů ve strukturované elektronické formě, nicméně rozsah evidovaných údajů je různý. Například lékařská komora neeviduje u svých členů na rozdíl od stomatologické a lékárnické komory rodné číslo. Tím se poněkud ztěžuje možnost využití těchto údajů. Na druhou stranu lékařská komora eviduje další údaje (jméno, příjmení, datum narození, pracoviště, a podobně), které jsou postačující pro jednoznačnou identifikaci dané osoby. V případě že bude realizován Národní registr zdravotnických pracovníků v rozsahu stanoveném aktuálním zněním zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, pak budou profesní komory předávat údaje ze svých seznamů do tohoto registru. Obdobná situace je u lékařských fakult a pověřených organizací, kterými jsou Národní centrum ošetřovatelství a nelékařských zdravotnických oborů v Brně (NCO NZO) a Institut postgraduálního vzdělávání ve zdravotnictví v Praze (IPVZ). Tyto instituce rovněž vedou údaje o školencích a absolventech v elektronické podobě a rovněž je budou předávat do Národního registru zdravotnických pracovníků. Akreditovaná zařízení, kde vlastní vzdělávání probíhá, sice obvykle nemají sofistikovanou elektronickou evidenci. Vzhledem k tomu, že klíčový je ale pouze celkový výsledek, tak průběžná data o vzdělání nejsou příliš podstatná z hlediska eHealth zaměřeného na výměnu zdravotnické dokumentace. V rámci eHealth zaměřeného na výměnu zdravotnické dokumentace v ČR i pro přeshraniční sdílení lze tedy využít tato strukturovaná data o vzdělání nejlépe cestou Národního registru zdravotnických pracovníků.

2.5

2.5.1

Finanční a ekonomická analýza stávajícího systému zdravotnictví ČR s ohledem na budoucí elektronizace zdravotnictví Struktura financování zdravotnictví a celkové náklady

Zdravotnictví je financováno primárně ze tří zdrojů, veřejného zdravotního pojištění, regionálních rozpočtů a soukromých zdrojů (přímé platby pacientů). Výše zdravotního pojištění se stanovuje z výše mzdy u výdělečně činných obyvatel, a to 13,5% z hrubé mzdy (4,5% zaměstnanec, 9% zaměstnavatel), OSVČ hradí 13,5% z poloviny zisku, minimálně však 1 697 Kč měsíčně. Za osoby, které nejsou výdělečně činné, hradí pojištění stát (tzv. státní pojištěnci), a to ve výši 723 Kč za měsíc.

68 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Graf 13 Výdaje na zdravotní péči v procentech podle zdroje financování - ÚZIS (2010)

Z výše uvedeného grafu je zřejmé, že podíl přímých plateb ve zdravotnictví roste, avšak zejména na úkor regionálních rozpočtů, přičemž relativní objem prostředků ze zdravotního pojištění se zásadně v průběhu minulých let nezměnil. Celkové výdaje na zdravotnictví v ČR se v posledních letech pohybují kolem 9% HDP, v absolutních číslech se jedná o téměř 300 miliard Kč, v přepočtu na obyvatele asi 30 000 Kč. Tato statistika činí české zdravotnictví relativně "levné" v porovnání s ostatními ekonomicky vyspělými zeměmi. Náklady na zdravotnictví však neustále narůstají. Nejlepší mezinárodní srovnání pokud jde o cenu zdravotní péče pravděpodobně nabízí relativní vztah mezi HDP na hlavu a výdaji na zdravotnictví na hlavu (níže).

Graf 14 Nárůst výdajů na zdravotnictví v první dekádě 21. století a srovnání výdajů na zdravotnictví vs. HDP na hlavu v zemích OECD - OECD (2011)

69 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

2.5.2

Struktura nákladů na zdravotnictví, hospodaření zdravotních pojišťoven

Náklady na zdravotní péči lze rozdělit dle typu (lidské zdroje, provozní náklady, materiál a léky, investiční náklady apod.), či dle segmentu péče, která je z daných prostředků hrazena.

Tabulka 5 Celkové příjmy a výdaje zdravotních pojišťoven v roce 2010 - ÚZIS (2011)

Tabulka 6 Struktura výdajů zdravotních pojišťoven na zdravotní péči v roce 2010 - ÚZIS (2011)

70 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

3

Návrh budoucího stavu elektronizace zdravotnictví v České republice Globální popis navrhovaného řešení

3.1

Elektronické zdravotnictví je aplikace informačních a komunikačních technologií napříč celým spektrem procesů a funkčnosti mající dopad na kvalitu a efektivnost zdravotních služeb a tím ovlivňující zdravotní stav populace. Soubor informačních a komunikačních technologií v rámci elektronického zdravotnictví propojuje jednotlivé zdroje informací a doplňuje je v rámci celorepublikového systému. Hlavním smyslem implementace těchto technologií je efektivní podpora procesů v rámci zdravotních služeb, které nejsou v současnosti podporovány vůbec nebo nedostatečně. Jedná se především o nástroje pro zdravotnickou správu, zdravotnická zařízení, zdravotní profesionály všech skupin stejně jako samosprávu, veřejné i personalizované zdravotní informační systémy pro pacienty a občany a plátce zdravotního pojištění. Formální rámec eGovernment, a tedy i elektronického zdravotnictví, byl dán Usnesením vlády ČR Č. 536/2008 ze 14. května 2008 o strategických projektových záměrech pro čerpání prostředků ze strukturálních fondů EU v rámci Smart Administration — příloha ke strategii Efektivní veřejná správa a přátelské veřejné služby. Dále je vhodné zmínit dokument A Digital Agenda for Europe, který publikovala Evropská komise v druhé polovině května roku 2010. Jde o první ze sedmi dokumentů, které rozpracovávají strategii rozvoje EU mezi lety 2010 a 2010. V Digitální agendě nalezneme celou řadu témat, která se vztahují ke zdravotnictví, ale i k veřejné správě. Téma interoperability se prolíná celým dokumentem, stejně jako téma vzdělávání a získávání praktických zkušeností ve využívání ICT. Ohledně zdravotnictví najdeme v Digitální agendě pět úkolů:     

umožnit občanům členských států EU do roku 2015 bezpečný online přístup k jejich zdravotním informacím, dosáhnout do roku 2020 širokého rozšíření služeb telemedicíny, připravit do roku 2012 doporučení definující rozsah minimálního společného obsahu zdravotních informací pacienta, která budou elektronicky přístupná mezi jednotlivými zeměmi, prosadit evropské standardy pro interoperabilitu, testování a certifikaci zdravotních informačních systémů do roku 2015, podporovat prostřednictvím programu Ambient Assisted Living nezávislý a aktivní život seniorů a zdravotně postižených ve společnosti.

Ve Směrnici o uplatňování práv pacientů při přeshraniční zdravotní péči, schválené Evropským parlamentem spolu s Evropskou radou v roce 2010, je stanoveno právo na vzdálený přístup občanů k informacím o organizaci a pravidlech čerpání zdravotní péče v zahraničí. Je definováno také právo pacienta, který odchází vyhledat péči do zahraničí, mít přístup ke svým zdravotním informacím, stejně jako právo na informace o péči v zahraničí poskytnuté. V oblasti předepisování léků požaduje směrnice interoperabilitu elektronických předpisů a možnost spojení mezi předepisujícím lékařem a vydávajícím lékárníkem. V samotné kapitole eHealth (jde o první výskyt eHealth v evropské legislativě) najdeme mimo jiné pravidla pro vytváření standardů pro elektronické sdílení zdravotních informací a pro elektronickou identifikaci osob.

3.1.1

Definování vize a mise projektu

Misí projektu eHealth je zajištění individualizované, ekonomicky efektivní, kvalitní, bezpečné péče spolu pro občany České republiky spolu s jejich adekvátní informovaností. Vize eHealth lze popsat základními jejími základními tezemi, které lze shrnout následovně: 



Zdravotní záznamy bude možné v zabezpečeném prostředí sdílet mezi různými poskytovateli zdravotních služeb, podílejícími se na longitudinální péči o pacienta. Toto sdílení nebude omezeno hranicemi České republiky. Eliminací duplicitní či kontraindikované péče, včas rozeznané díky sdílené dokumentaci, bude možné docílit vyšší efektivitu poskytované péče v ekonomické i kvalitativní rovině.

71 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 







Větší míra strukturovanosti zdravotních záznamů umožní jejich okamžité statistické vytěžování, sémantickou interoperabilitu zdravotních záznamů a podporu klinického rozhodování při poskytování zdravotních služeb. Informace pro účelné směřování zdrojů veřejného zdravotního pojištění bude možné snáze zajistit díky měřitelnosti kvality a bezpečnosti poskytovaných zdravotních služeb bez další administrativní zátěže poskytovatelů zdravotních služeb. Elektronické zdravotnictví bude těsně integrováno se systému eGovernmentu tak, aby tyto systémy přinášely co největší přidanou hodnotu s využitím postupů a datových zdrojů zavedených v rámci eGovernmentu. Zvýší se dostupnost personalizovaných informací pro pacienty, kterým se tak usnadní orientace v systému zdravotnictví.

Jako vhodnou strategii k dosažení tohoto cíle rozpracovává tento návrh teze, založené na požadavku efektivního a hospodárného zajištění technické a sémantické interoperability zdravotních záznamů na národní i mezinárodní úrovni. Technickou interoperabilitu lze popsat jako možnost propojení systémů na technické úrovni, a této oblasti se věnují technické standardy jako například IHE nebo HL7. Technicky interoperabilní systémy navzájem rozumí předávaných datům a jsou schopné je interpretovat jako informace. Sémantická interoperabilita je naproti definována jako jednotné chápání významu předávaných informací. Této oblasti dominují nomenklatury a klasifikace, jako je například MKN-10 anebo SNOMED CT. Sémanticky interoperabilní systémy navzájem chápou předávané informace a jsou schopné je používat jako znalosti. Strategie dosažení výše uvedené vize je podorbně rozpracována v kapitole 4 Návrh implementace změn v českém zdravotnictví. Významným výchozím předpokladem tohoto návrhu je skutečnost, že bude minimalizována tvorba nových systémů a databází obsahujících osobní údaje. Tento přístup je motivován snahou o ekonomickou hospodárnost v rovině investiční i provozní a eliminaci odporu proti změnám ve zdravotnictví, postavených na strašení zneužitelností osobních údajů. Základním axiomem toho návrhu je také to, že eHealth bude povinné pro poskytovatele a dobrovolné sdílení pro pacienty na principu opt-out s možností více úrovní omezení přístupu. Návrh však z možnosti opt-out vyjímá tzv. emergentní dataset, který bude dostupný pro oprávněné zdravotnické pracovníky v nezbytných případech u všech pacientů. Povinnost sdílení dokumentace je navržena jako primárně limitovaná na zdravotní služby placené ze zdravotního pojištění. Dokumentaci služeb placených jiným způsobem lze sdílet shodnými způsoby jako u služeb placených z veřejných zdrojů, nicméně je doporučeno jejich sdílení na dobrovolné bázi a to opět pro eliminaci odporu zaleženém na obavách ze zneužití osobních údajů. Tento přístup nevylučuje, že v budoucnu bude možné rozšířit povinnost sdílení i na zdravotní služby placené mimo systém veřejného zdravotního pojištění.

3.1.2

Zhodnocení dopadu navrhovaných změn na českou legislativu

Podrobně jsou změny legislativy vynucené navrhovaným řešením popsány v bodě 4.1.3 Případné dopady na stávající legislativu a návrh řešení. Obecně lze konstatovat, že navrhované změny nevynucují zcela změnit koncepci české legislativy v rovině nahlížení a předávání zdravotnické dokumentace, nicméně budou vyžadovány významné změny a novelizace zejména těchto zákonů a vyhlášek:         

Zákon č. 111/2009 Sb., o základních registrech v aktuálním znění Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování (zákon o zdravotních službách) Vyhláška č. 92/2012 Sb., o požadavcích na minimální technické a věcné vybavení zdravotnických zařízení Vyhláška č. 98/2012 Sb., o zdravotnické dokumentaci Vyhláška č. 116/2012 Sb., o předávání údajů do Národního zdravotnického informačního systému Zákon č. 378/2007 Sb., o léčivech, Centrální úložiště elektronických receptů Vyhláška č. 54/2008 Sb., o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů¨ Vyhláška č. 84/2008 Sb., o správné lékárenské praxi, bližších podmínkách zacházení s léčivy v lékárnách, zdravotnických zařízeních a u dalších provozovatelů a zařízení vydávajících léčivé přípravky připravovaný zákon o zdravotních pojišťovnách (dosud nepublikováno ve sbírce)

72 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

3.1.3

Návrh způsobu řešení zpřístupnění informací uživatelům budovaného systému

Tento návrh je založen na využití jednotného grafického uživatelského rozhraní k většině služeb eHealth pro pracovníky, pacienty i poskytovatele. Tímto rozhraním je webový Portál obsahující pro každou skupinu uživatelů obecnou i personalizovanou část. Je však pravděpodobně, že zdravotničtí pracovníci budou využívat v některých případech spíše funkce svých stávajících informačních systémů, které jim tyto služby zpřístupní. Podrobný popis funkcí Portálu je uveden v bodě 4.3.8 Portálová řešení.

3.1.4

Analýza možností a předpokladů využití principů prediktivní analytiky na nově vybudovaném systému

Využití principů prediktivní analytiky v bodě 4.2.4 Analýza možností a předpokladů využití principů prediktivní analytiky na nově vybudovaném systému. Navržené řešení počítá se standardizací formy elektronické dokumentace a jejího obsahu pomocí standardu openEHR a nomenklatury SNOMED CT. Podrobnosti k těmto nástrojům jsou uvedeny v bodě 2.3 Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky. Tato standardizace by měla zlepšit procesy systematického sběru dat s prediktivní informační hodnotou. Nové možnosti prediktivní analytiky pro Národní zdravotní registry přinese zejména projekt „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy“, jejímž zadavatelem je KSRZIS a který je součástí tzv. eREG, tedy modernizace resortních registrů. Tento projekt zahrnuje vytvoření moderního reportingu založeném na datovém skladu a transformačních procesech datových pump. Takto pojatý reporting odpovídá současným trendům Business Intelligence a bude mít významné pozitivní přínosy v rovině prediktivní analytika. Jeho benefity však nelze přičítat tomuto návrhu, protože jde o už existující projekt.

3.1.5

Návrh způsobu napojení nového systému na již existující základní registry veřejné správy

Návrh způsobu napojení na Základní registry je popsán v bodě 4.3.11 Vazba na základní registry. Návrh řešení doporučuje umožnit napojení na Základní registry i pro všechny poskytovatel zdravotních služeb. Již nyní mají možnost poskytovatelé využít služeb základních registrů pro potřeby očkování, nicméně v klinické praxi není obvykle možné oddělit používání nějakého údaje pro očkování od používání v jiných klinických agendách. Navrhované řešení obsahuje i doporučení k eliminaci rodného čísla z Národních zdravotních registrů pomocí jejich propojení se Základními registry, což je v souladu s koncepcí eGovernmentu. V rámci návrhu není budován žádný nový systém a napojení stávajících systémů, jako například informačních systémů zdravotních pojišťoven na Základní registry, zůstává beze změny.

3.1.6

Návrh způsobu napojení nového systému na již existující registry vymezené legislativou (Zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování)

Tento návrh je založen na využití informačních systémů zdravotních pojišťoven pro potřebu vytváření „indexů“ umístění zdravotnické dokumentace v místě vzniku. Nevyužívá proto „odborné“ zdravotní registry (jako například registr hospitalizovaných) ale pro účely zabezpečení je založen intenzivně na službách Národního registru zdravotnických pracovníků a Národního registru poskytovatelů. Další informace k využití registrů v rámci identifikace zdravotnických pracovníků jsou uvedeny v bodě 4.3.3.2 Identifikace zdravotnického pracovníka. Kromě toho je navržena možnost prostřednictvím Portálu nahlížet na data evidovaná o pacientovi v Národních zdravotních registrech. Podrobný popis funkcí portálu je uveden v bodě 4.3.8 Portálová řešení.

73 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

3.1.7

Sběr, analýza a vyhodnocení potřeb budoucích uživatelů (zdravotničtí pracovníci, lékárníci, pacienti) budovaného systému

Primární sběr požadavků na konkrétní vlastnosti a funkce systému eHealth pro jeho budoucí uživatele by měl probíhat primárně cestou zavedených autorit v této oblasti. U zdravotnických pracovníků a lékárníků jsou to tedy odborná sdružení (ČLS JEP a další), profesní komory, výzkumné instituce případně zájmová sdružení poskytovatelů ambulantních služeb. V případě pacientů lze využít jako partnery k věcné diskuzi o budoucí podobě eHealth zavedené sdružení věnující se této oblasti, jako je například Koalice pro zdraví, Platforma zdravotních pojištěnců či sdružení Reforma zdravotnictví – forum.cz. Analýza a vyhodnocení vznesených požadavků by mělo probíhat veřejnou a transparentní formou. Z takto získaných požadavků převedených do konsolidované formy by měl být sestaven seznam a ten by měl být předložen k „veřejné oponentuře“. Tato by měla probíhat formou „preferenčních hlasů“ pro určité vlastnosti pomocí internetové aplikace (obdoba internetového hlasování pro otázky na hosta v pořadu Hyde Park ČT24). Tento způsob by měl přinést další pohled na preference veřejnosti, pro jejíž potřebu je systém primárně určen a která jej v konečném důsledku zaplatí ze svých daní. Tento návrh vychází z následujících požadavků uvedených skupin uživatelů: 



Pacienti o o o o o o o o

Možnost náhledu na zdravotnickou dokumentaci z domova Garance nezměnitelnosti záznamů ve zdravotnické dokumentaci Možnost řízení přístupu ke své zdravotnické dokumentaci Lepší orientace v systému cen léčiv i systému zdravotnictví Zajištění bezpečnosti osobních údajů Snížit čekací doby Přehled o kvalitě poskytovaných služeb Omezení dotazů na skutečnosti, které již byly v rámci poskytování zdravotních služeb dříve sděleny jinému zdravotnickému pracovníkovi o Lepší informovanost o povaze plánovaných diagnostických a terapeutických výkonů o Dostupné informace o finančním aspektu poskytnuté péče Zdravotničtí pracovníci (vč. lékárníků) o Odstranit zbytečnou administrativu o Možnost uživatelsky jednoduchého sdílení zdravotnické dokumentace o Zjednodušení realizace sběru dat pro klinický výzkum o Nezávazné a důvěrné srovnání kvality práce

Další informace o PR aktivitách projektu je možné najít v kapitole 6 Komunikační strategie a PR aktivity projektu.

3.1.8

Cost-benefit analýza navrhovaných změn celého elektronického zdravotnictví

Přestože lze najít mnoho studií zaměřených na ekonomické benefity systémů eHealth, a systémy elektronizace zdravotnictví dokážou generovat významné úspory, nelze se na implementaci systémů eHealth dívat čistým porovnáním nákladů a úspor. V tomto konkrétním návrhu je například doporučena finančně náročná implementace zaručených elektronických podpisů a kvalifikovaných časových razítek pro vedení elektronické dokumentace v pouze elektronické formě. Tento krok nemá žádné kvantifikovatelné ekonomické přínosy, protože čistě elektronickou dokumentaci by bylo bezpochyby možné si představit i bez těchto technologií. Jde však o právní garanci neměnitelnosti zdravotnické dokumentace jejím „správcem“, což je zcela klíčové pro pacienta a tuto garanci bez těchto technologií prostě dosáhnout nelze. Soudní spory vedené v poslední době v oblasti pochybení zdravotníků potvrzují nutnost tohoto způsobu řešení. Na druhou stranu Národní ekonomická rada vlády (NERV) doporučila elektronizaci zdravotnictví jako jednu z deseti prioritních oblastí pro ekonomickou stabilizaci zdravotnictví. Zkušenosti z evropských států tento názor podporují. Na úrovni evropské unie je tento trend zachycen v dokumentu A Digital Agenda for Europe, který publikovala Evropská komise v druhé polovině května roku 2010.

74 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Vzhledem k provázání státu a správců zdravotní daně (zdravotních pojišťoven) nelze posuzovat dopady na tyto aktéry izolovaně. V případě velkého schodku ve zdravotním pojištění byl stát historicky nucen zvýšit platbu za tzv. státní pojištěnce a nedostatečný výnos z jedné daně (zdravotní pojištění) tak dorovnat z výnosů jiné daně. Naopak při kladné bilanci systému zdravotního pojištění bylo možné ponechat platbu za státního pojištěnce na stávající úrovni bez zohlednění inflace. V konečném důsledku je vždy plátcem daňový poplatník. Konečná bilance v zavádění eHealth na straně státu a zdravotních pojišťoven lze tak ve střednědobém odhadovat jako „kladnou nulu“. Zde se jedná spíše o to, že bez elektronizace by pravděpodobně systém zdravotnictví skončil ve významném propadu, do kterého se začíná dostávat již nyní. Bilance na straně poskytovatelů při realizaci tohoto řešení vychází z dlouhodobého hlediska jako spíše kladná, protože eliminací papírové formy dokumentace lze generovat nemalé přímé úspory.

3.1.9

Zpracování analýzy proveditelnosti navrhovaných změn celého elektronického zdravotnictví

Pro reálné provedení analýzy proveditelnosti z technického hlediska u takto komplexního návrhu by bylo nutné implementovat minimálně proof-of-concept pro základní služby zamýšleného systému. Analýza proveditelnosti z technického hlediska tedy nebyla reálně proveditelná v rámci tohoto návrhu. Zpracování analýzy proveditelnosti z technického hlediska je doporučeno provést před rozhodnutím o větších investicích. Z technického hlediska je nicméně největším rizikem pro eHealth schopnost správné implementace principů sdílení dokumentace na straně dodavatelů informačních systémů zdravotních pojišťoven a poskytovatelů zdravotních služeb, kterou stát nemůže a dle zadání ani nechce mít pod kontrolou. Analýza proveditelnosti z ekonomického hlediska vychází ze srovnání uvedeného v bodě 4.2.3 Identifikace a zhodnocení dopadů navrhovaného řešení elektronizace zdravotnictví na stávající stav z ekonomického hlediska a z odhadovaných cen částí řešení uvedených v bodě 4.3 Technický model. Při srovnání výše celkových nákladů a deklarací Ministerstva zdravotnictví o plánované výši investic do eHealth lze konstatovat, že z ekonomického hlediska návrh splňuje očekávané parametry a je tedy proveditelný. Samostatnou otázkou je však potřeba udržitelnosti výstupů, která bude nejvíce záviset na akceptaci systému širokou odbornou i laickou veřejností. V tomto kontextu je nutné si uvědomit, že podíl nákladů na PR a edukaci v rámci celého projektu elektronizace zdravotnictví lze odhadovat jako přibližně poloviční z celkových nákladů. Analýza proveditelnosti z hlediska organizačně-procesního vychází z konkrétního návrhu změn procesů a legislativy. Vzhledem ke klíčové roli změn zákonů, bez které nelze systém eHealth realizovat, je zásadní otázkou proveditelnosti z tohoto hlediska zajištění parlamentní většiny. Legislativní změny tedy nutně musí předcházet ostatním krokům v rámci projektu, které jsou na nich závislé. Určitých benefitů lze nicméně dosáhnout i v rámci stávajícího legislativního stavu.

3.2 3.2.1

Shrnutí hlavních přínosů celkového návrhu řešení dle cílových skupin Pacienti

Hlavním přímým přínosem řešení dle uvedeného návrhu pro pacienty by byla lepší orientace v komplikovaném systému zdravotnictví. Tato orientace by se projevila jak v obecném povědomí o způsobu poskytování služeb, jejich dostupnosti, nabídce na trhu s léčivy a právech pacientů, tak i rovině informací o zdravotním stavu konkrétního jedince. Na pacienta jsou nicméně v konečném důsledku zaměřeny i nepřímé přínosy, které jsou primárně směřovány na ostatní aktéry systému zdravotnictví v ČR.

3.2.2

Zdravotničtí pracovníci

Hlavním přínosem řešení dle uvedeného návrhu pro zdravotnické pracovníky by byla možnost eliminace některé zbytečné administrativy či opakovaného zjišťování informací (anamnézy, lékové historie, klinická vyšetření), čímž by došlo k uvolnění jejich kapacity pro vlastní klinické úkony u pacienta. Zavedení standardu openEHR také přináší zdravotníkům možnost přímé kontroly struktury zdravotnické dokumentace i bez znalostí technických podrobností zdravotnické informatiky. Při zvýšení efektivity poskytování zdravotních služeb by pak bylo možné ušetřené

75 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ prostředky investovat znovu do pracovníků ve zdravotnictví a to jak ve formě přímých odměn, tak i vzdělávacích aktivit.

3.2.3

Poskytovatelé zdravotních služeb

Hlavním přínosem řešení dle uvedeného návrhu pro poskytovatele zdravotních služeb je možnost vyšší měřitelnosti kvality a efektivity poskytované péče. Efektivní implementací informačních technologií pak mohou tyto organizace uspořit značné finanční prostředky a ty použít pro generování disponibilních finančních zdrojů, které lze použít opět na zvýšení úrovně poskytované péče či investovat do svých pracovníků. Díky využití standardů HL7, IHE a openEHR se sníží míra závislosti na aktuálních dodavatelích v oblasti zdravotnické informatiky a změna informačního systému pak bude podstatně jednodušší.

3.2.4

Zdravotní pojišťovny

Hlavním přínosem řešení dle uvedeného návrhu pro zdravotní pojišťovny je možnost vyšší měřitelnosti kvality a efektivity poskytované péče a eliminace duplicitních, zbytečných či kontraindikovaných vyšetření. Při využití těchto postupů pak mohou za prostředky veřejného zdravotního pojištění, nakoupit více klinicky efektivní a bezpečné zdravotní péče pro své pojištěnce. Další přínosy může přinést přechod na online vykazování péče z měsíčního dávkového systému. Tímto způsobem lze zajistit téměř online přehled o poskytnutých zdravotních službách a možnost úspory nákladů na prostředky výpočetní techniky (zejména výkonný HW), které vyžaduje měsíční dávkové zpracování výkazů.

3.2.5

Státní správa

Hlavním přínosem řešení dle uvedeného návrhu pro státní správu je zlepšení přehledu o systému zdravotnictví díky analýze dat strukturovaných dat. Úspory na straně zdravotních pojišťoven mohou zpomalit potřebu zvyšování podílu plateb státu do systému veřejného zdravotního pojištění. Řešení je navrženo tak, aby implicitně obsahovalo i možnost zapojení pojištěnců všech zdravotních pojišťoven do projektu epSOS a maximálně se usnadnilo budoucí přeshraniční sdílení zdravotních záznamů, ke kterému směřuje legislativa EU. Důraz je kladen na těsnou integraci se systémy eGovernmentu, jako jsou datové schránky, elektronické občanské průkazy s čipem i bez a Základní registry. Návrh je veden snahou o nízké investiční a provozní náklady při generování co nejvyšší přidané hodnoty pro všechny aktéry systému zdravotnictví. Jako významný přínos pro státní správu lze hodnotit také očekávanou vyšší celkovou spokojenost klientů systému zdravotnictví (pacientů). Navrhované řešení také není závislé na rozhodnutí Ústavního soudu ve věci shromažďování osobních údajů v rámci NZIS. Pro státní správu jakožto zřizovatele mnoha poskytovatelů zdravotních služeb jsou také platné přínosy uvedené níže v bodě 3.2.6 Krajská a obecní samospráva.

3.2.6

Krajská a obecní samospráva

Hlavním přínosem řešení dle uvedeného návrhu pro krajskou a obecní samosprávu, jakožto významného zřizovatele řady poskytovatelů lůžkových i jiných zdravotních služeb, je ekonomicky efektivnější fungování těchto poskytovatelů, jejichž provoz by pak nebylo potřeba dotovat z jiných zdrojů. Další přínosy spočívají ve zlepšení komunikace mezi jednotlivými poskytovateli a zvýšení měřitelnosti kvality a bezpečnosti poskytované péče. Pro kraje a obecní samosprávu nenese řešení dle uvedeného návrhu žádné přímé náklady. Jako významný přínos lze hodnotit také očekávanou vyšší celkovou spokojenost klientů systému zdravotnictví (pacientů).

3.2.7

Vzdělávací a výzkumné instituce

Hlavním přínosem řešení dle uvedeného návrhu pro vzdělávací a výzkumné instituce, je rozšíření možností výzkumných činností, které pak mohou vycházet přímo z běžných strukturovaných zdravotních záznamů. To vede k významnému zjednodušení možnosti předběžného testování hypotéz i vlastního klinického výzkumu.

3.2.8

Výrobci a distributoři zboží a poskytovatelé služeb pro zdravotnická zařízení

Hlavní přínosy řešení dle uvedeného návrhu pro výrobce a poskytovatele služeb pro zdravotnická zařízení pocítí zejména dodavatelé v oblasti zdravotnické informatiky. Využití mezinárodních standardů zvýší

76 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ konkurenceschopnost českých informačních systémů na světovém trhu. Díky využití openEHR lze nabídnout klinickým pracovníkům mnohem vyšší úroveň kontroly nad strukturou zdravotnické dokumentace.

3.3

Rizika navrhovaného řešení

Níže jsou uvedena hlavní rizika úspěšné implementace tohoto návrhu eHealth Název rizika

Popis rizika

Pravděpodobnost

Nízká motivace

Možný nezájem o eHealth, neboli otázka zabezpečení motivace a informovanosti jednotlivých aktérů v rámci zdravotnictví.

50%

Míra negativního dopadu Vysoká

Legislativní problémy

Navržené řešení je závislé na změnách legislativy, což může být problém především procesní, schvalování úprav bude jistě spojené s dalšími tématy, která se stanou předmětem politických tahanic a celý legislativní proces tím může být značně oddálen nebo dokonce zmařen. Rovněž je nutné brát do úvahy, že jednotlivé čísti návrhu jsou spolu úzce provázány a veškeré legislativní úpravy potřebné pro zavádění eHealth bude nutné připravovat a časovat jednotně. Jedním z vážných rizik je špatná ekonomická situace ve zdravotnictví a to jako zdravotních pojišťoven, tak i poskytovatelů péče. Pokud se dnes vůbec nějaké investice realizují, pak jsou preferovány investice do oblastí, které přinášejí okamžité úspory. Ochota investice do nástrojů, jejichž přínosy se projeví za delší období a zpočátku přinášejí řadu komplikací, se blíží nule. Navržené řešení představuje velice komplexní integrační projekt, který propojuje mnoho různých informačních systémů. Jako takový je jeho úspěch velice citlivý na správnou koordinaci a vedení projektu. Vzhledem k decentralizované povaze navrženého systému je jeho implementace velmi závislá na dovednostech a schopnostech dodavatelů stáváních systémů a jejich orientaci v moderních technologiích a mezinárodních standardech zdravotnické informatiky.

70%

Vysoká

80%

Vysoká

Postupné iterativní změny s prioritním zaměřením na vysokou přidanou hodnotu.

20%

Střední

Výběr dostatečně kvalifikovaného (certifikovaného) projektového manažera či obecně poskytovatele služeb projektové kanceláře.

30%

Střední

Vytvoření referenční implementace a dostatečná edukace o možnostech jejího využití.

Nedostatek financí

Řízení projektu

Schopnosti dodavatelů stávajících systémů

Strategie pro zmírnění rizika Nutné řešit zejména a zásadně vhodným působením na jednotlivé cílové skupiny projektu prostředky Public Relations. Již samotné zafinancování těchto PR aktivit je však samozřejmě jedním z rizik. Získání celospolečenské shody na změnách a jejich způsobu mezi všemi aktéry systému.

77 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

SWOT analýza navrhovaného řešení

3.4

Níže je uvedena SWOT analýza řešení vycházející z jeho návrhu a ze SWOT analýzy elektronického zdravotnictví v ČR, uvedené v soutěžních podmínkách.

3.4.1       

3.4.2  

        

3.4.3   

3.4.4          

Silné stránky Nízká finanční náročnost řešení Absence budování nové celonárodní databáze obsahující osobní údaje Okamžitá funkčnost po zprovoznění díky využití historické báze dat v informačních systémech zdravotních pojišťoven Využívání principu Single Sign-On pro zvýšení komfortu uživatele Intenzivní zapojení zdravotních pojišťoven do budovaného eHealth Intenzivní využití stávajících systémů (např. EESSI Access Point Centra mezistátních úhrad) Nezávislost na rozhodnutí Ústavního soudu ve věci shromažďování osobních údajů v NZIS

Příležitosti Realizace registru radiační zátěže doplněním informačního systému zdravotních pojišťoven Koncepční řešení zaručených elektronických podpisů a kvalifikovaných časových razítek pro nepopiratelnost autorství a doby vzniku záznamu ve zdravotnické dokumentaci vedené v elektronické formě Využití nástrojů eGovernmentu – základní registry, bezpečnostní osobní kód k občanskému průkazu, datové schránky Intenzivní využití mezinárodních technických standardů a nomenklatur Možnost využití požadavků široké veřejnosti pro úpravu funkční specifikace řešení Možnost rozvoje elektronické preskripce Využití Portálu jako významného komunikačního prostředku v rezortu zdravotnictví Využití reportingu v rámci eREG pro potřeby jiných organizací v rámci zdravotnictví (SÚKL, SZÚ, …) Možnost využít identity uživatele ověřené na Portálu i v rámci jiných informačních zdrojů ze státní, komerční či neziskové sféry Směřování situace k přeshraničnímu sdílení zdravotnické dokumentace Dobrá vybavenost některých poskytovatelů služeb výpočetní technikou

Slabé stránky Velké prodleva předávání dat u poskytovatelů bez non-stop provozovaného informačního systému Relativně dlouhá doba návratnosti investice Vyšší finanční náročnost ve srovnání se systémy nevyužívajícími zaručený elektronický podpis a kvalifikovaná časová razítka

Hrozby Závislost funkce celku na kvalitě implementace v podání jednotlivých dodavatelů informačních systémů pro poskytovatele zdravotních služeb Velká technická složitost postupů korektního využití digitálních certifikátů Chybné pochopení záměrů systému odbornou či laickou veřejností podporované negativně naladěnými zájmovými skupinami Nezájem laické i odborné veřejnosti o služby eHealth Prakticky monopolizovaný trh v oblasti ambulantních software Dehumanizace zdravotní péče Zneužití systému, postaveném na principu opt-out s možností dodatečné kontroly přístupů k zabezpečeným informacím (na rozdíl od systému opt-in) Přetrvávání špatné ekonomické situace ve zdravotnictví Závislost na potřebě legislativních změn Dlouhodobá absence jasně artikulované státní politiky elektronického zdravotnictví

78 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

3.5 3.5.1

Odpovědi na základní otázky Jaké jsou potřeby zdravotnických pracovníků v ČR a jaké jsou jejich očekávání od elektronizace zdravotnictví? Identifikujte přínosy elektronizace pro jednotlivé cílové skupiny.

Základní potřebou zdravotnických pracovníků v odborné rovině je dobře se postarat o svého pacienta a být za to adekvátně zaplacen. Z toho vyplývají také jejich požadavky na informační systémy ve zdravotnictví. Z těchto požadavků může řešení postavené na uvedeném návrhu uspokojit zejména potřebu dostupnosti zdravotnické dokumentace od jiných poskytovatelů. S postupujícím externím hodnocením kvality poskytovatelů zdravotních služeb stoupá i potřeba získání vyšší kontroly nad strukturou zdravotnické dokumentace, kterou lze účinně splnit zavedení standardu openEHR. Nelze však očekávat přímý dopad elektronizace zdravotnictví na národní úrovni do komfortu běžné práce uživatele s informačními systémy jednotlivých poskytovatelů, která bohužel ovlivňuje názor zdravotníků na elektronizaci zdravotnictví asi nejvíce. Vzhledem k tomu, že dosavadní komerčně dostupné technologie byly stavěné spíše na běžnou kancelářskou práci, od které se práce klinického zdravotníka obvykle velmi liší, výsledky elektronizace zdravotnictví někdy nesplnili jejich požadavky. Očekávání zdravotnických pracovníků od elektronizace zdravotnictví lze charakterizovat především jako „obavu“. Hlavním zdrojem obav je představa rizika zvýšení objemu administrativních činností a u soukromých poskytovatelů v samostatných ordinacích je to dále obava ze ztráty kontroly nad zdravotnickou dokumentací, kterou považují za „svou“ a od které odvozují svůj obchodní potenciál. Tyto obavy bude potřeba rozptýlit důkladnou edukací o smyslu a povaze plánovaných změn. Klíčová je pro zdravotnické pracovníky také právní povaha informací, které budou získány pomocí elektronického sdílení. Pravidla v této oblasti bude muset definovat legislativa. V této rovině je vhodné také zdůraznit, že díky ekonomické efektivitě uvedeného návrhu nebude implementace takovéhoto řešení zbytečně odsávat finanční zdroje, které jsou využitelné i v jiných oblastech zdravotnictví. Podrobný popis přínosů elektronizace je uveden bodě 3.2 Shrnutí hlavních přínosů celkového návrhu řešení dle cílových skupin.

3.5.2

Navrhněte typy výstupů, které je vhodné veřejně publikovat. Identifikujte relevantní informační zdroje.

Vzhledem k stávajícímu stavu společnosti v České republice není vhodné v tuto chvíli publikovat data zaměřená na měření kvality poskytované péče. S těmito daty by měli pracovat primárně odborníci ve zdravotních pojišťovnách a u samotných poskytovatelů a nikoliv média. Je vcelku zbytečné uvažovat i o zveřejnění dat o financování poskytovatelů z veřejných prostředků zdravotního pojištění, protože po plném zavedení DRG bude toto financování již dostatečně transparentní. Stávající podoba výstupů publikovaná ÚZIS pro veřejnost o poskytovatelích zdravotních služeb je tedy v zásadě dostatečná, přestože by bylo možné doporučit některá doplnění. (rozlišení poskytovatelů vlastněných soukromými společnosti a krajskými holdingy a podobně). Bylo by však vhodné pravidelně zveřejňovat více dat o zdravotních pojišťovnách a to jednak o struktuře jejich kmene pojištěnců v jednotlivých zdravotních pojišťovnách, ale i dat o přerozdělení výběru zdravotních pojišťoven či jejich nákladů na jednotlivé věkové skupiny dle přerozdělení a podobně. Dostupná jsou obvykle pouze sumární data za všechny zdravotní pojišťovny nebo případně data v rámci výročních zpráv pojišťoven, které však nemají jednotnou strukturu a někdy tyto informace ani neobsahují. Informačními zdroji pro tyto informace jsou jednoznačně informační systémy jednotlivých zdravotních pojišťoven.

79 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

3.5.3

Jaké jsou přínosy a dopady případné implementace projektu epSOS, respektive využití jeho principů na národní úrovni? Jak by měla být navržena problematika dostupnosti základního datasetu?

Hlavním přínosem projektu epSOS, respektive jeho principů na národní úrovni, je tlak na zavedení procesů pro sdílení zdravotnické dokumentace dle mezinárodních standardů. Přestože je tento projekt zaměřen na přeshraniční sdílení, lze tyto procesy a standardy aplikovat i na sdílení zdravotnické dokumentace na národní úrovni. Projekt ověřuje organizační a technickou proveditelnost tohoto sdílení. V předpokládaném cílovém stavu by měl projekt epSOS přinést možnost přeshraničního sdílení Pacientských souhrnů a ePresripce. Sdílení Pacientských souhrnů na národní i mezinárodní úrovni může významným způsobem přispět k efektivitě poskytované péče. Problematika obsahu základního datasetu je nyní řešena na evropské úrovni v rámci Digitální agendy (dokument A Digital Agenda for Europe, který publikovala Evropská komise v druhé polovině května roku 2010), která ukládá do roku 2012 připravit doporučení definující rozsah minimálního společného obsahu zdravotních informací pacienta, která budou elektronicky přístupná mezi jednotlivými zeměmi. Není příliš pravděpodobné, že by rozsah těchto údajů byl větší než rozsah Pacientského souhrnu realizovaného v rámci projektu epSOS. Tento návrh řešení eHealth je založen mimo jiné na využití dat shromážděných v systémech zdravotních pojišťoven a Pacientský souhrn definovaného epSOS je možné prakticky celý vytvořit z dat v nich uložených. Díky tomu je dostupnost základního datasetu dle tohoto návrhu zajištěna implicitně i bez získávání další zdravotnické dokumentace, uložené v místě jejich vzniku. Lze předpokládat, že tento základní dataset bude možné obsahově využít i jako tzv. emergentní dataset, dostupný u všech pacientů pro oprávněné zdravotnické pracovníky v nezbytných případech.

3.5.4

Jaké mezinárodně uznávané standardy a nomenklatury doporučujete v ČR zavést a proč? Jaký doporučujete další postup s národním standardem DASTA?

Z mezinárodně uznávaných standardů doporučujeme zavést do rutinního užívaní zejména IHE, HL7, openEHR a SNOMED CT. 





IHE a HL7 – tyto standardy jsou intenzivně využívány v rámci projektu epSOS zaměřeného na přeshraniční sdílení zdravotnické dokumentace a není důvod proč je nevyužít i v rámci sdílení na národní úrovni. Odstranila by se tím nehospodárná potřeba udržovat rozhraní dle dvou různých technických standardů. openEHR – tento standard přináší významnou přidanou hodnotu pro zdravotníky, kterým vrací možnost plné kontroly nad strukturou elektronické zdravotnické dokumentace. Pro poskytovatele zdravotních služeb je tento standard výhodný v tom, že snižuje jejich závislost na konkrétních dodavatelích informačních systémů. SNOMED CT – tento standard přináší možnost sémanticky interoperabilních zdravotních záznamů, které jsou pak také strojově srozumitelné a využitelné v pokročilých aplikacích zdravotnické informatiky, jako je podpora rozhodování nebo znalostní báze. Z klinických záznamů pak lze případně i odvozovat automaticky kódy pro výkazy zdravotní pojišťovně, což může kompenzovat vyšší obtížnost záznamu klinické informace v rámci SNOMED CT namísto prostého či semi-strukturovaného textu.

Dále by měla být zvážena možnost náhrady Seznamu zdravotních výkonů z bodovými hodnotami jinou srovnatelnou mezinárodní klasifikací. Srovnání alternativ provedené dříve v rámci projektu NRC je uvedeno v kapitole 2.3.2.2 Seznam zdravotních výkonů s bodovými hodnotami a jeho alternativy. Další postup se standardem DASTA by měl být zahájen oddělením Národního číselníku laboratorních položek ze standardu DASTA. Tento číselník lze využít jako datový slovník v rámci HL7 i openEHR a měla by být prozkoumána možnost jeho mapování na klasifikaci LOINC. Vlastní technická část DASTA, popisující strukturu přenášených dat, by měla být nadále udržována, dokud bude významný počet výrobců tento standard podporovat. Nelze očekávat, že ze dne na den bude realizován přechod výrobců IS od DASTA na HL7 . Nový rozvoj by se však měl soustředit na implementaci sdílení dat ve zdravotnictví pomocí standardu HL7 s využitím IHE, pomocí kterého by mělo být řešeno i rozhraní pro sdílení zdravotnické dokumentace uložené v místě vzniku. Aby bylo toto použít HL7 možné, je však nejprve nutné provést transfer znalostí a specifik České republiky do lokalizace HL7, tak jako tomu bylo v jiných státech.

80 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Podrobný popis a zhodnocení těchto standardů a postup jejich zavedení je uveden v bodě 2.3 Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky.

81 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4

Návrh implementace změn v českém zdravotnictví

Základním předpokladem tvorby návrhů účastníků této soutěže o návrh na tvorbu a implementaci systému elektronického zdravotnictví je maximální využití infrastruktury a služby eGoverment, zejména propojení elektronického zdravotnictví na Základní registry veřejné správy, Registry resortu zdravotnictví (eREG) a Jednotnou technologickou platformu resortu zdravotnictví (JTP), maximální zohlednění datových standardů definovaných na národní, evropské i světové úrovni, identifikátoru pacienta a zdravotnického pracovníka obecně používaného v EU a dále maximální využití potenciálu již existujících dat poskytovatelů zdravotní péče a zkušeností z mezinárodních projektů (epSOS apod.). Základní princip elektronického zdravotnictví (eHealth) v ČR byl definováno jako: „Sdílení dat nezbytných k poskytování péče pomocí informačních a komunikačních technologií ve zdravotnictví (v nutných případech)“. Pro úspěšnou implementaci musí systém eHealth musí zahrnovat elektronizaci agend v celém sektoru zdravotnictví s cílem podstatného zvýšení role pacienta. V souladu se závěry dokumentu „Doporučení pro strategii elektronického zdravotnictví (eHealth) pro Českou republiku“, zpracovaného pod patronací WHO, je nutné se dívat na eHealth jako na socio-technický systém. Jeho součástí je sice technická realizace, ale ta tvoří pouze část systému elektronického zdravotnictví. Významné je i organizačně-legislativní prostředí, ve kterém má být systém provozován a také ekonomické aspekty toho systému. Tyto skutečnosti shrnuje koncept e3Health, který je popsán v publikaci E-Health Systems Quality and Reliability v kapitole s názvem e3Health: Three Main Features of Modern Healthcare (Zvárová, Zvára). V následujícím textu jsou tyto komponenty blíže rozvedeny v jednotlivých kapitolách ekonomického, organizačně-legislativního a technického modelu.

Electronic technické aspekty

e3Health

Economic ekonomické faktory

Environment organizačně-legislativní prostředí

Obrázek 17 Schéma konceptu e3Health

Je nutné si uvědomit, že komplexní projekt typu zavádění eHealth na národní úrovni v ČR vyžaduje striktní aplikaci principů projektového řízení. Tyto principy jsou blíže popsány v kapitole 5 Návrh organizace zavádění elektronického zdravotnictví v ČR.

82 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.1 4.1.1

Procesně organizační a legislativní model Popis současného stavu a jeho zhodnocení

4.1.1.1 Organizační a procesní postupy Pro uvedený návrh je ze všech procesů používaných v rámci zdravotnictví nejzásadnější aktuální způsob předávání výkazů poskytnuté péče od poskytovatelů zdravotním pojišťovnám. Ten je aktuálně realizován v měsíčních dávkách. Přijaté soubory jsou následně ve zdravotních pojišťovnách zpracovávány, vzhledem k nárazovým špičkám v objemu dat na začátku měsíce, obvykle při nočním zpracování. V dnešní době prakticky při každé návštěvě ve zdravotnickém zařízení je vykázán zdravotní pojišťovně nějaký kód – minimálně signální kód regulačních poplatků o jejich zaplacení či nezaplacení. Tento způsob je zaveden i u praktických lékařů s kombinovanou kapitačněvýkonovou platbou. Procesy vyúčtování přeshraniční péče s jinými členskými státy EU či některými dalšími zeměmi jsou realizovány prostřednictvím Centra mezistátních úhrad (CMÚ), které realizuje tzv. hromadné přeúčtování. Při něm jsou rozděleny a následně opět sdruženy domácí pohledávky, předané dávkově od jednotlivých zdravotních pojišťoven v rámci ČR, do skupin dle jednotlivých států. Naopak pohledávky ze zahraničí, předané dávkově jednotlivými státy, jsou rozděleny a opět sdruženy podle jednotlivých pojišťoven v rámci České republiky. Kromě toho realizuje CMÚ řadu dalších procesů, týkajících se vymáhání či určení aplikované legislativy (např. kde má být pojištěna osoby pracující v Německu a bydlící v ČR). Pro tyto procesy se dříve používaly tzv. E-formuláře, což byly papírové formuláře určené pro evropské procesy ve zdravotně sociální oblasti. Tyto E-formuláře nyní nahradí tzv. strukturované elektronické dokumenty (SED), což jsou elektronické dokumenty ve formátu XML vyměňované prostřednictvím sítě Evropské sítě pro výměnu informací o sociálním pojištění (EESSI). Pro zajištění komunikace v rámci této sítě zřizuje CMÚ tzv. EESSI Access Point CMÚ, který funguje jako centrální router a vstupní bod z/do sítě EESSI pro dokumenty tykající se zdravotnictví v ČR. Pro potřeby automatizace těchto procesů má CMÚ propojen informační systém Access Point CMÚ s informačními systémy jednotlivých zdravotních pojišťoven. Díky tomu lze některé SED vyřizovat i v plně online bezobslužném režimu a u tzv. „offline SED“ využívat velkou míru automatizace. Tento postup významně zrychlí procesy přeshraničního poskytování péče.

4.1.1.2 Legislativní pravidla V rámci reformy zdravotnictví byly nedávno realizovány zásadní úpravy legislativy. Zejména se jedná o zákon č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, který nově upravuje řadu skutečností významných z hlediska sdílení a nahlížení do zdravotnické dokumentace. Předávání zdravotnické dokumentace je upraveno ustanoveními § 45 odstavci (2). Poskytovatel je tak povinen předat zprávu o poskytnutých zdravotních službách registrujícímu poskytovateli v oboru všeobecné praktické lékařství nebo v oboru praktické lékařství pro děti a dorost, je-li mu tento poskytovatel znám, a na vyžádání též poskytovateli zdravotnické záchranné služby nebo pacientovi; registrující poskytovatel v oboru zubní lékařství nebo v oboru gynekologie a porodnictví má povinnost předat zprávu jen v případě, kdy poskytnutí zdravotních služeb indikoval registrující poskytovatel v oboru všeobecné praktické lékařství nebo v oboru praktické lékařství pro děti a dorost. Poskytovatel zdravotních služeb musí dále předat jiným poskytovatelům zdravotních služeb nebo poskytovatelům sociálních služeb potřebné informace o zdravotním stavu pacienta nezbytné k zajištění návaznosti dalších zdravotních a sociálních služeb poskytovaných pacientovi. Podrobnosti k možnosti vedení zdravotnické dokumentace pouze v elektronické podobě uvádí § 54 odstavec (3) a § 55. Každý záznam v elektronické podobě musí být opatřen identifikátorem záznamu; samotný zápis musí obsahovat nezměnitelné, nezpochybnitelné a ověřitelné údaje, kterými jsou datum provedení zápisu a identifikační údaje zdravotnického pracovníka nebo jiného odborného pracovníka, který záznam provedl. Kromě nezbytného zálohování dat je nutné zejména zajistit, aby technické prostředky použité k uložení záznamů v elektronické podobě zaručily, že údaje v provedených záznamech nelze dodatečně modifikovat; technickými prostředky jsou organizačně-technická opatření, informační systémy, technické zařízení a vybrané pracovní postupy. Dále je nutné splnit požadavek, aby informační systém, ve kterém je vedena zdravotnická dokumentace v elektronické podobě, evidoval seznam identifikátorů záznamů v elektronické dokumentaci pacientů vedené poskytovatelem a umožňoval jeho poskytování dálkovým přístupem. Dokumenty v listinné podobě, které jsou součástí zdravotnické dokumentace a které vyžadují podpis osoby, jež není zdravotnickým pracovníkem nebo jiným odborným pracovníkem, musí být

83 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ převedeny do elektronické podoby, která se opatří zaručeným elektronickým podpisem osoby, která převod provedla; dokument v listinné podobě se pak ale stejně musí uchovávat. Informační systém, ve kterém je vedena zdravotnická dokumentace, musí umožňovat vytvoření speciální kopie uložené zdravotnické dokumentace ve formátu čitelném a zpracovatelném i v jiném informačním systému (je však otázka stanovení tohoto formátu). Pro pacienta a jeho zákonného zástupce je obsaženo právo nahlížet do své zdravotnické dokumentace v ustanovení § 65. Poskytovatel přitom nemůže nijak pacienta omezovat v tom, do které části dokumentace nahlížet může a do které ne. Výjimky tvoří informace o týrání či zneužívání svěřené osoby nebo ohrožování jejího zdravého vývoje. U záznamů autorizovaných psychologických metod a popisu léčby psychoterapeutickými prostředky může pacient nebo zákonný zástupce pacienta nahlížet nebo si pořizovat výpisy nebo kopie pouze v rozsahu záznamu popisu příznaků onemocnění, diagnózy, popisu terapeutického přístupu a interpretace výsledků testů. V případě vedení zdravotnické dokumentace pouze v elektronické podobě má dokonce dle § 66 odstavce (4) pacient možnost nahlížet dálkovým přístupem. Dle ustanovení zákona č. 280/1992 Sb., o resortních, oborových, podnikových a dalších zdravotních pojišťovnách § 21 odstavce (3) je zaměstnanecká pojišťovna povinna ze svého informačního systému podávat na základě písemné žádosti registrujícího poskytovatele ambulantní péče v oboru všeobecné praktické lékařství nebo v oboru praktické lékařství pro děti a dorost informace o hrazených službách, které byly poskytnuty jejím pojištěncům, kteří jsou u takového poskytovatele registrováni, jinými poskytovateli včetně předpisu léčivých přípravků a zdravotnických prostředků; tyto informace zaměstnanecká pojišťovna poskytuje bezplatně. Totéž ustanovení je obsaženo analogicky i v zákoně č. 551/1991 Sb., o Všeobecné zdravotní pojišťovně České republiky, konkrétně v jeho § 24 odstavci (3). Lze tedy konstatovat, že v rámci legislativy je aktuálně podchycena povinnost poskytovatele zdravotních služeb předávat jiným poskytovatelům zdravotních služeb informace o zdravotním stavu pacienta, tak kde je to potřeba. Rovněž pacient má téměř neomezený přístup ke své vlastní dokumentaci. Již dnes tak tedy nelze uvažovat o informacích obsažených ve zdravotnické dokumentaci jako o výhradním majetku konkrétního poskytovatele. Zdravotní pojišťovny mají dále povinnost předávat praktickým lékařům informace o péči poskytnuté jejich pojištěncům, nicméně zákon vyžaduje splnění písemné podoby žádosti a na interpretaci elektronické formy jako písemné formy jsou různé právní názory. Díky ustanovení, že pro vedení zdravotnická dokumentace pouze v elektronické formě není nutné elektronické podpis, ale stačí jen blíže neupřesněná „organizačně-technická opatření, informační systémy, technické zařízení a vybrané pracovní postupy“ – zabezpečení elektronické dokumentace proti dodatečným změnám v případě pochybení zdravotníků je tak zhruba srovnatelná s papírovou formou.

4.1.2

Návrh úpravy organizace a procesů

Zavedení elektronického zdravotnictví nutně přinese mnohé změny v organizaci a zavedených procesech.

4.1.2.1 Vykazování péče zdravotním pojišťovnám Nejvíce viditelnou změnou, kterou zahrnuje tento návrh je patrně přechod na „online“ způsob vykazování poskytnuté zdravotní péče pro zdravotní péče. Tento nový způsob by spočíval ve vykázání každého případu poskytnutí zdravotních služeb (lůžkové epizody nebo ambulantní návštěvy) do určitého časového limitu. Tento limit by se měl pohybovat v řádu jednotek dnů a měl by být stanoven na úrovni vyhlášky. Tato změna sice není absolutně nezbytná, nicméně bez ní by docházelo k až měsíčnímu zpoždění indexace záznamů o zdravotnické dokumentaci, uložené v místě vzniku. Přestože i takovýto systém by přinášel významné benefity, není racionální důvodu proč neopustit dávkový systém předávání dat, zavedený v 90tých letech minulého století, kdy dostupnost internetu byla v ČR prakticky nulová. V souladu s kodifikací role informačních systémů zdravotních pojišťoven jakožto indexů zdravotní dokumentace by měly mít zdravotní pojišťovny povinnost evidence i výkony odmítnuté z finančních důvodů, protože nesou možnou informaci umístnění dokumentace. Na toto předávání dat by mohlo navázat předávání informací o vydaných léčivech ze SÚKLu okamžitě přímo do zdravotní pojišťovny a tak by odpadnul přenos těchto informací od lékáren do zdravotních pojišťoven. Vzhledem k nové roli zdravotních pojišťoven, jakožto správců indexů zdravotnické dokumentace uložené v místě vzniku, by musely zdravotní pojišťovny akceptovat i určitou kontrolní roli. Ta by spočívala v doplnění běžných

84 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ kontrol vykázané péče o část, spočívající v kontrole oprávněnosti požadavku na poskytnutí indexu v případě že k danému datu nebyla nakonec žádná péče poskytovatelem vykázána. V případě systematického zneužívání nástrojů pro elektronické sdílení dokumentace by pak musela zdravotní pojišťovna předat podnět Úřadu pro ochranu osobních údajů. Do výkazů pro zdravotní pojišťovny by v případě radiologických vyšetření a radioterapeutických intervencí měly být přidány informace o radiační zátěži. Toto rozšíření datového rozhraní je z technického hlediska pouze malou změnou a mnohem více se jedná o změny procesní. Tato změna se projeví zejména tam, kde informační systémy neimplementují DICOM službu Modality performed procedure step (MPPS), která předává notifikaci o provedeném vyšetření do NIS a která může obsahovat i informaci o radiační zátěži. Osoby nepojištěné v rámci ČR by měli mít možnost si zvolit „výpomocnou“ zdravotní pojišťovnu, která by evidovala jejich index zdravotnické dokumentace obdobně, jako si teď volí výpomocnou zdravotní pojišťovnu pojištěnci z jiného členského státu EU. Tento návrh však vychází z předpokladu, že není důvod nutit samoplátce či pojištěnce z jiného státu EU ke sdílení jejich zdravotních záznamů, vzhledem k tomu, že efektivita této péče neovlivňuje veřejné zdravotní pojištění České republiky. Z tohoto důvodu je návrh založen na principu opt-in pro tyto osoby a ty musí proto explicitně vyjádřit vůli ke sdílení těchto zdravotních záznamů.

4.1.2.2 Nahlížení do zdravotnické dokumentace a její předávání Ke změně dojde i v procesu předávání dokumentace pro zajištění kontinuity poskytovaných zdravotních služeb. V tuto chvíli probíhá vyžadování dokumentace písemně pomocí papírových požadavků. Navrhované řešení tento proces mění na elektronický a navíc dává pacientovi možnost jej řídit pomocí nastavení oprávnění pro jednotlivé poskytovatele zdravotních služeb a to až na úroveň konkrétních zdravotnických pracovníků. Elektronizován by byl podle tohoto řešení i proces nahlížení pacienta či jeho zákonného zástupce do elektronické zdravotnické dokumentace. V tomto případě jde skutečně o pouze procesní změnu, protože dle platné legislativy již nyní má pacient téměř plný přístup ke své zdravotnické dokumentaci. Aktuálně je také diskutován rozsah emergentního datasetu, nicméně lze předpokládat, že emergentní dataset bude přibližně obsahově shodný se základním datasetem, který pravděpodobně nepřesáhne rozsah pacientských souhrnů v rámci epSOS.

4.1.2.3 Projekt epSOS Pro vlastní realizaci technické stránky projektu epSOS a systému přeshraničního sdílení, který bude pravděpodobně navazovat na projekt epSOS je navrženo využití systému EESSI Access Point, který dnes provozuje Centrum mezistátních úhrad (AP CMÚ) a v budoucnu by mohl být provozován v rámci Úřadu pro dohled nad zdravotním pojištěním. V rámci evropské sítě pro výměnu informací o sociálním pojištění (EESSI) jsou přes tento Access Point předávány zabezpečeným způsobem informace mezi informačními systémy zdravotních pojišťoven v rámci ČR a kompetentními institucemi v rámci jiných členských států EU. K tomuto předávání se v síti EESSI využívá systém tzv. Access Pointů, přičemž každý stát musí mít aspoň jeden, který slouží jako národní brána do této sítě. Obdobný princip využívá síť epSOS, která však svou národní bránu nazývá Národním kontaktním místem (National Contact Point – NCP). Aktuální procesy EESSI, zaměřené na vyúčtování poskytované péče, již dnes pracují s řadou údajů, které by měly být součástí Souhrnů informací o pacientovi. Technická realizaci epSOS v rámci AP CMÚ je blíže popsána v bodě 4.3.4 Výměna elektronické zdravotnické dokumentace pacienta. Pro realizaci projektu epSOS tímto způsobem mluví i fakt, že lze v případě institucionalizace projektu epSOS v oficiální struktuře orgánů EU očekávat začlenění procesů přeshraničního sdílení zdravotnické dokumentace do stávající sítě EESSI, používané v rámci zdravotně-sociální problematiky. K rozvoji služeb EESSI určených pro poskytovatele zdravotnické dokumentace ostatně směřuje i projekt NewS4EESSI realizovaný v ČR sdružením Medtel o.p.s. Lze očekávat, že agenda CMÚ v budoucnu přejde pod nově zřízený Úřad dohledu nad zdravotními pojišťovnami, kam by následně spadal i systém, realizující přeshraniční výměny zdravotnické dokumentace po vzoru projektu epSOS.

85 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.1.2.4 Institucionalizace standardů a nomenklatur U nově zaváděných technických standardů a nomenklatur by mělo dojít jejich institucionalizaci. U stávajících číselníků (SÚKL KLK, Seznam zdravotních výkonů s jejich bodovými hodnotami, NČLP, a podobně) by mělo dojít v první řadě k jejich konsolidaci. Institucionalizace v rámci tohoto návrhu zahrnuje tyto standardy a nomenklatury: 

 

 

HL7 – již institucionalizováno v rámci sdružení HL7 Česká republika, nicméně rozvoj národní lokalizace by měl být finančně podpořen v rámci definice technických standardů pro výměnu zdravotnické dokumentace IHE – vzhledem k těsné vazbě na HL7 lze uvažovat o institucionalizace v rámci sdružení HL7 Česká republika nebo případně v rámci ÚZIS SNOMED CT – vzhledem primární potřebě překladu této nomenklatury pro použití v rámci ČR by měla být tato nomenklatura svěřena do správy ÚZIS, který realizoval i překlad jiných mezinárodních nomenklatur (MKN-10 a další) openEHR – institucionalizaci by bylo vhodné zajistit formou vhodného neziskového subjektu Seznam zdravotních výkonů s jejich bodovými hodnotami či jeho náhrada v budoucnu – údržba tohoto číselníku by měla být svěřena NRC, vzhledem k jeho klíčovému využití v rámci údržby DRG (lze očekávat převod agendy NRC pod nově zřízený Úřad dohledu nad zdravotními pojišťovnami)

Náhrada Seznam výkonů jinou vhodnou interoperabilní klasifikací, jak je popisováno v bodě 2.3.2.2 Seznam zdravotních výkonů s bodovými hodnotami a jeho alternativy, je mnohem více změnou organizační než legislativní, přestože je tento seznam v konečném důsledku vydáván vyhláškou.

4.1.2.5 Využití identity pacienta a pracovníka ověřené na Portále Informační zdroje ve zdravotnictví, provozované ve státním, neziskovém i komerčním sektoru, zaměřené na zdravotnické pracovníky nebo pacienty, by mohly souhlasem daného uživatele po zprovoznění Portálu využít identity pacienta či zdravotnického pracovníka ověřenou na Portále. Tento systém tzv. Single Sign-On by omezil potřebu obtížné realizace ověřených registrací pacientů a zdravotnických pracovníků pro každý informační zdroj zvlášť. Rovněž by bylo eliminováno přihlašování uživatelů, kteří jsou již přihlášeni na portále.

4.1.2.6 Využití SSL přístupu v rámci ePreskripce Poskytovatelům zapojeným do elektronické preskripce by bylo vhodné umožnit přístup formou SSL pomocí HTTPS a nebo softwarové VPN. Tím by se efektivně eliminovala potřeba distribuce routerů Cisco do lékáren či k jiným poskytovatelům zdravotních služeb. Požadavky na router v lékárně jsou dány pokyny SÚKLu a nejde tedy o změnu legislativy.

4.1.2.7 Realizace úložišť pro sdílení dokumentace samostatných ambulancí Referenční implementace, vytvořená v rámci projektu pro zajištění sdílení zdravotnické dokumentace bude moci po instalaci na odpovídající HW být provozována prakticky libovolným subjektem, který pak může nabídnout služby tohoto úložiště na běžném komerčním principu. Těmito subjekty mohou být kraje, krajské nemocnice, stávající výrobci ambulantních SW, sdružení poskytovatelů ambulantních služeb a podobně. Je nutné se na takovéto úložiště dokumentace dívat primárně jako na online zálohu zdravotnické dokumentace, která prakticky eliminuje riziko ztráty dat zdravotnické dokumentace při poruše PC v ordinaci. Možnost online sdílení elektronické zdravotnické dokumentace je v zásadě vedlejším efektem. Tento návrh nepočítá s provozem instance referenční implementace v rámci centrálních orgánů, i když by její využití mělo být pro poskytovatele zdravotních služeb dobrovolné. Tento fakt by totiž mohl být zneužit zájmovými skupinami pro tvrzení, že v rámci eHealth budou centrálně shromažďovány nové osobní údaje, což není záměrem tohoto návrhu.

4.1.2.8 Centrální objednávání pacientů V případě zprovoznění služby pro objednávání pacientů pomocí Portálu by musely být změněny procesy poskytovatelů zdravotních služeb tak, aby byl tento způsob objednání akceptován jako rovnocenný s osobním či telefonickým objednáváním. Centrální objednávání prostřednictvím zdravotních portálů je přitom stávající nebo

86 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ plánovanou funkčností snad všech národních eHealth programů v rámci EU. Portál by měl umožňovat i vyhledání poskytovatele dle kritérií časové a místní dostupnosti a smlouvy s konkrétní zdravotní pojišťovnou.

4.1.3

Případné dopady na stávající legislativu a návrh řešení

Tento návrh je založen na premise, že není vhodné vymýšlet pro postupy, běžné v jiných segmentech lidské činnosti, specifickou legislativu v rámci zdravotnictví. Tento fakt dokazuje i situace kolem souhlasu mladistvých ve věku 15 – 18 s poskytování zdravotních služeb. Specifická úprava v zákoně č. č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, se ukázala jako problematicky aplikovatelná v praxi a je proto plánována její novelizace. Přestože tedy tento návrh má možnost navrhnout legislativní změny, a pro zavedení eHealth jsou tyto změny nutné, je veden snahou o změny pouze tam, kde je to účelné. Z těchto důvodů je i maximálně využíváno ustanovení legislativy kolem eGovernmentu.

4.1.3.1 Elektronická preskripce 4.1.3.1.1 Elektronická preskripce by měla být zavedena jako povinná pro všechny pacienty i lékaře. Výjimky by měly být povoleny pouze v odůvodněných případech (neodkladná péče a podobně). Po provedení změn v systému elektronické preskripce navržených v bodě 4.3.4.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:          



Rozhodnutí o realizaci systému pro výměnu elektronické zdravotnické dokumentace pacienta Příprava technické a funkční specifikace a provedení výběrových řízení Definice standardů pro rozhraní pro sdílení zdravotnické dokumentace na národní úrovni Implementace VPN koncentrátoru Realizace poskytovatele identity založeného na Národním registru zdravotnických pracovníků a Národním registru poskytovatelů Realizace interní resortní certifikační autority vydávající kvalifikovaná časová razítka Úpravy AP CMÚ pro realizaci NCP v rámci epSOS Vytvoření referenční implementace pro poskytovatele zdravotních služeb a zdravotní pojišťovny Úprava ePACS a ReDiMed pro začlenění referenční implementace pro poskytovatele zdravotních služeb Začlenění referenční implementace do informačních systémů zdravotních pojišťoven a přechod na „online“ systém předávání výkazů o poskytnuté péči Začlenění referenční implementace do informačních systémů poskytovatelů zdravotních služeb

4.1.3.1.2 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:           

Rozhodnutí Příprava Definice rozhraní Realizace VPN Zabezpečení přístupu Zajištění kvalifikovaných časových razítek Realizace přeshraničního sdílení Vytvoření referenční implementace Realizace výměny obrazové dokumentace Využití referenční implementace na straně zdravotních pojišťoven Využití referenční implementace na straně poskytovatelů zdravotních služeb

Úprava elektronická preskripce, již nebudou existovat technické bariéry jeho akceptace.

87 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Dále by mělo být upravena ve vyhlášce č. 54/2008, o způsobu předepisování léčivých přípravků, údajích uváděných na lékařském předpisu a o pravidlech používání lékařských předpisů, možnost předepisovat na elektronický recept více přípravků než jen dva jako na papírový, což by mohlo motivovat pacienty, kteří by v lékárně pak platili pouze jeden regulační poplatek. Takováto motivace je vhodná pro urychlení adopce elektronické preskripce v době do přijetí odpovídajících úprav zákona. Samostatně bez úprav zákona je tato „měkká“ motivace jednotlivých aktérů nedostatečná. Dále by měla být v legislativě provedeny další změny pro zajištění možnosti technické realizace navrhovaných změn:      

možnost náhledu lékaře a lékárníka na lékovou historii a interakce léků u daného pacienta, dle nastavení matice přístupů a oprávnění tímto pacientem na Portále možnost dohledání receptů v centrálním úložišti pod číslem EHIC či občanského průkazu eliminace potřeby použít zaručený elektronický podpis založený na kvalifikovaném digitální certifikátu a jeho náhrada systémem „jméno – heslo“ znovuzavedení povinnosti kontroly počtu vydaných balení v Centrálním úložišti při výdeji OTC s omezením data o papírových receptech, nyní sbíraná samostatně a odděleně od Centrálního úložiště elektronických receptů by měla být opět přidána do Centrálního úložiště provázání Centrálního úložiště se Základními registry

V případě, že by se ukázalo shromažďování dat SÚKLem v povinné ePreskripci jako problematické z hlediska ochrany osobních údajů, lze uvažovat o decentralizaci provozu Centrálního úložiště do jednotlivých pojišťoven a na SÚKLu ponechat pouze recepty bez uvedené pojišťovny. Pro tuto změnu by mluvila i skutečnost, že v konečném důsledku většina receptů ve zdravotní pojišťovně nakonec skončí a potřeba jejich shromažďování v rámci zdravotní pojišťovny je v tomto případě neoddiskutovatelná. V takovém případě by bylo možné dále zjednodušit procesy vykazování, protože při povinné ePreskripci a s úložištěm ve zdravotní pojišťovně, již téměř odpadá potřeba předávání výkazů o realizovaných receptech dávkou či jiným způsobem. Také by se zjednodušila v budoucnu možnost zdravotních pojišťoven využít takovéto „Centrální úložiště“ pro informaci o výši úhrady léčiva v případě rozdílných pojistných plánů pro jednotlivé pojištěnce.

4.1.3.2 Zdravotní pojišťovny Aktuální ustanovení zákona č. 280/1992 Sb., o resortních, oborových, podnikových a dalších zdravotních pojišťovnách, § 21 odstavce (3) a zákona č. 551/1991 Sb., o Všeobecné zdravotní pojišťovně České republiky, § 24 odstavce (3) stanovující povinnost pojišťovny poskytovat „index“ míst, kde byl pacient ošetřen na účet veřejného zdravotního pojištění, by měl být upraven. Úprava by měla stanovovat tuto povinnost i v případě dálkového přístupu a pro všechny ošetřující lékaře daného pacienta. Explicitně upravena by měla být možnost pacienta pro vlastní přístup k „indexu“ a také jeho právo nastavovat přístup ke své sdílené dokumentaci na principu opt-out. Agendy Centra mezistátní úhrad, Národního referenčního centra a Centrálního registru pojištěnců by měly být sdruženy pod budoucí Úřad pro dohled nad zdravotními pojišťovnami.

4.1.3.3 Registry státní správy a datové schránky Mezi údaje evidované v Národním registru poskytovatelů zdravotních služeb by měla být doplněna informace o síťové adrese serveru jejich úložiště sdílené dokumentace. Tato informace by měla být následně dostupná informačním systémů jiných poskytovatelů, kteří budou vyžadovat předání sdílené dokumentace. Procesy ukládání dat v Národních zdravotních registrech by měly být upravena tak, aby nebylo ukládáno rodné číslo pacienta. Tyto registry by jakožto informační systém veřejné správy měly být napojeny na systém Základních registrů a po ztotožnění identity pacienta dle základních registrů by měla být uchovávána jeho identifikace pouze pomocí AIFO. Tato změna by bohužel vyžadovala změnu legislativy, protože v zákoně č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, je v § 70 odstavci (2) se mluví pouze o „předávání“ rodných čísel či čísel pojištěnce a tyto identifikátory Základní registry neobsahují.

88 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Je také nezbytná úprava legislativy pro využití Základních registrů i poskytovateli zdravotních služeb a to zejména formou novely zákona č. 111/2009 Sb., o základních registrech. Podrobně jsou důvody této změny popsány v bodě 4.3.11 Vazba na základní registry. Pro smysluplné využití informačního systému datových schránek (ISDS) pro předávání strukturovaných dat ve zdravotnictví (i ve všech ostatních resortech) by bylo nutné doplnit datové schránky o již dříve široce diskutovanou možnost podání ve formě strukturovaných dat a označení hlaviček těchto zpráv nějakým způsobem tak, aby mohly být u příjemce směřovány přímo k automatickému zpracování a nikoliv k lidskému operátoru podatelny.

4.1.3.4 Zdravotnická dokumentace Zásadní z hlediska eHealth je vyjasnění právní povahy informací ze zdravotnické dokumentace získané pomocí systému její elektronické výměny. Nejvhodnější se jeví považovat tyto informace za rovnocenné informacím zjištěným při poskytování péče samotným poskytovatelem (příjemcem), avšak k datu záznamu těchto informací u původního zdroje. To bude znamenat, že informace (například anamnéza) budou muset být ověřeny, protože se od doby jejich posledního uložení mohly změnit. Pro autentizaci zdravotnických pracovníků v rámci zdravotnické dokumentace vedené pouze v elektronické podobě by se měl používat elektronický podpis založený na kvalifikovaném certifikátu. Tato povinnost by měla být explicitně stanovena zákonem namísto technicko-organizačních opatření. Podrobné zdůvodnění těchto změn je uvedeno v bodě 4.3.3.2 Identifikace zdravotnického pracovníka. Vzhledem k absolutní nezbytnosti právní garance vymezení vytvoření či úpravy záznamů v elektronické zdravotnické dokumentaci je nezbytné opatřovat tyto záznamy kvalifikovaným časovým razítkem dle zákona č. 227/2000 Sb., o elektronickém podpisu. Tento způsob je z technického hlediska jediný, který může zabránit riziku přepisů zdravotnické dokumentace s antedatováním těchto záznamů či jejich oprav. Jiné způsoby (jako například omezení přístupu k záznamům na úrovni uživatelského rozhraní) jsou sice technicky snáze realizovatelné, nicméně nejsou v zájmu pacientů, na které by měl být systém eHealth primárně orientován. Tyto jiné způsoby totiž v zásadě vždy umožňují nějaký způsob přímého a nedohledatelného zásahu do dat jejich technickým administrátorem. Vývoj v oblasti soudních sporů vedených v oblasti medicínských pochybení potvrzuje tuto potřebu jako nutnost. Zajištění služeb certifikační autority pro výdej kvalifikovaných časových razítek by mělo být realizováno formou provozu interní resortní certifikační autority, jejíž služby by byly poskytovatelům pro účely vedení zdravotnické dokumentace dostupné zdarma. Povinnost označení záznamů ve zdravotnické dokumentaci vedené pouze v elektronické formě kvalifikovaným časovým razítkem by měla být stanovena přímo zákonem. Úprava zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, by měla zahrnovat i požadavek na primární identifikaci fyzických osob (zejména pacientů ale i zdravotnických pracovníků) v rámci zdravotnické dokumentace pomocí jejich AIFO ze Základních registrů. Použité technické standardy a postupy pro výměnu zdravotnické dokumentace by pak neměly být stanoveny zákonem ani vyhláškou, ale jiným způsobem na úrovni například Věstníku Ministerstva zdravotnictví. Na úrovni vyhlášky by měl být stanoven pouze obsah zdravotnické dokumentace, který je v principu u listinné i elektronické formy shodný. Ve vyhlášce o zdravotnické dokumentaci by však měl být stanoven rozsah emergentního datasetu a rozsah dat sdílených v rámci přeshraničního sdílení. Na úrovni vyhlášky by také měly být nicméně stanoveny ještě limity, do kterých má být vyžádaná zdravotnická dokumentace být poskytnuta od okamžiku žádosti (vymezení dostupnosti zdravotnické dokumentace). Návrh těchto limitů dle formy poskytované péče, u kterého je dokumentace uložena, jsou uvedeny níže: Forma poskytované zdravotní péče Poskytovatel lůžkové a jednodenní péče (i pokud poskytuje i jinou péči) Poskytovatel ambulantní péče Poskytovatel péče ve vlastním sociálním prostředí klienta

Limit odeslání požadované zdravotnické dokumentace od požadavku ihned – online 3 pracovní dny 3 pracovní dny

89 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Dalšími limity stanovenými na úrovni vyhlášky by měly být limity pro vykázání případu poskytnutí zdravotních služeb zdravotní pojišťovně při přechodu na „online“ způsob vykazování poskytnuté zdravotní péče. Tyto limity by se měly pohybovat v rovině jednotek dnů. Jako vhodný limit pro start systému se jeví interval 3 pracovních dnů od ukončení daného případu (odchodu pacienta z ordinace či propuštění z lůžka). Vzhledem k tomu, že přibližně čtvrtina samostatných ambulancí nepoužívá dosud PC pro vedení zdravotnické dokumentace, měla by dále být stanovena povinnost vybavení ordinace internetem a výpočetní technikou formou novely vyhlášky č. 92/2012 Sb., o požadavcích na minimální technické a věcné vybavení zdravotnických zařízení. Tento návrh nepředpokládá okamžité zavedení povinné výhradně elektronické formy zdravotnické dokumentace, nicméně lze předpokládat, že mandatorní povinnost vést dokumentaci ve výhradně elektronické podobě by měla být stanovena v dlouhodobém horizontu, rámcově od roku 2020.

4.1.4

Přínosy navrhovaného řešení

Navržené řešení nezakládá na prakticky žádaný nárůst administrativy. Naopak lze očekávat, že nějaká administrativa ubyde. Mírné riziko navýšení administrativních úkonů nicméně představuje potřeba předávat informace o radiační zátěži pacientů. Ve všechny modality jsou schopny tyto informace poskytnout a v případě radioterapeutických intervencí je bude nutné zadávat ručně prakticky vždy. V rámci přechodu na „online“ způsob vykazování se zlepší aktuálnost přehledu zdravotních pojišťoven o poskytované péči. Indexy založené na datech zdravotních pojišťoven povedou k okamžitému a intenzivnímu zapojení zdravotních pojišťoven do systému eHealth. Tento návrh není citlivý ke změnám, které může vyvolat verdikt Ústavního soudu ve věci národních zdravotních registrů. Požadavek na anonymizaci údajů v těchto registrech se jej nedotkne. Naopak obsahuje doporučení k využití Základních registrů pro odstranění rodného čísla z Národních zdravotních registrů. Návrh také intenzivně využívá další stávající systémy eGovernmentu, jako jsou bezpečností osobní kódy vázané na občanské průkazy, datové schránky. Návrh řeší velmi dále hospodárným způsobem zapojení všech pacientů České republiky do projektu epSOS. Navrhované řešení obsahuje možnost využití identity zdravotníka či pacienta zjištěné na Portále s jeho souhlasem v rámci dalších informačních zdrojů, provozovaných státní, komerční či neziskovou sférou. Tento postup, který již dnes běžně využívá Facebook nebo Google+ či Seznam.cz, eliminuje potřebu vytváření vždy nových databází s registrací uživatelů. Změny v oblasti ePreskripce umožní její povinné zavedení a tak zajistí realizaci očekávání, které stály u zrodu toho systému. Zejména tedy zprůhlednění trhu s léčivy i vyšší komfrot pro všechny aktéry. Využití zaručených elektronických podpisů a kvalifikovaných časových razítek povede k zlepšení právních garancí zdravotnické dokumentace, což je v zájmu pacientů. Centrální objednávání Pacientů pomocí portálu by přineslo vyšší komfort pro pacienty a v konečném důsledku i sníženi administrativy pro poskytovatele zdravotních služeb. Návrh také obsahuje doporučení ke konsolidaci, systematickému a institucionálnímu udržování a transparentnímu financování jednotlivých částí systému. Tímto je podmíněna dlouhodobá systémová i finanční udržitelnost.

4.2

Ekonomický a statistický model

Při budování eHealth systému je nutné se uvědomit význam motivace jednotlivých aktérů, která nemusí být čistě ekonomická. Obecně lze říci, že ve zdravotnictví funguje vlastně jen to, co je nařízeno a má nějaký benefit pro toho, na koho spadá dotyčná povinnost. Příkladem takovýchto situací jsou například regulační poplatky, Národní onkologicky registr či Systém hlášení nežádoucích událostí. Pouhá nařízení či doporučení (ePreskripce) nebo pouhá finanční motivace (elektronické zdravotní knížky IZIP) v podstatě v praxi nefungují. Podmínkou je celonárodní „úplnost“ řešení daná zákonnou povinností vést a plnit danou databázi pro všechny zákonem určené aktéry.

90 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Dalším významným prvkem v rámci ekonomického modelu je skutečnost, že při zavádění eHealth málokdy spadají benefity a povinnosti systému na stejnou osobu. Příkladem toho je opět elektronická preskripce, kdy ve stávajícím nastavení spadá většina benefitů na zdravotní pojišťovny a lékárny, nicméně povinnosti zůstaly na lékařích a pacientech. Protože na pacientech a lékařích byla ponechána také rozhodovací pravomoc, je reálná akceptace elektronické preskripce v současném nastavení relativně nízká.

4.2.1

Globální popis návrhu ekonomického modelu

Tento návrh je založen na utilizaci stávajících systémů. Rozvoj těchto systémů musí principiálně zajistit jejich stávající vlastníci, ačkoliv stát jim může pomoci vhodnými nástroji. Hlavní tíži investičních nákladů ponese stát, který bude muset zajistit zejména:    

Institucionalizaci a překlad standardů Řešení identifikace a bezpečnosti (čipové karty, čtečky a služby certifikačních autorit) Portál pacientů, zdravotnických pracovníků a poskytovatelů Tvorbu referenční implementace (pro snadné začlenění systému eHealth do stávajících systémů)

Druhým hlavním plátcem změn, nutných pro realizaci tohoto návrhu jsou zdravotní pojišťovny, které musí financovat zejména následující aktivity:  

Tvorbu indexů umístnění dokumentace a Souhrnů informací o pacientovi dle dat ze svých informačních systémů Přeshraniční sdílení informací v projektu epSOS pomocí EESSI Access Point Centra mezistátních úhrad (v případě přechodu agendy pod Úřad pro dohled nad zdravotními pojišťovnami by zřejmě bylo možné přímé financování státem)

Další náklady budou alokovány na straně poskytovatelů zdravotních služeb:  

4.2.2

Doplnění rozhraní na straně klinických informačních systémů poskytovatelů zdravotních služeb Implementace vedení elektronické zdravotnické dokumentace pouze v elektronické formě

Přínosy navrhovaného řešení

Očekávané ekonomické benefity v případě systému elektronického zdravotnictví by měly plynout zejména z procesu sdílení zdravotnické dokumentace a upravené elektronické preskripce. Tyto benefity by měly ležet na straně plátců zdravotních služeb, tedy zdravotních pojišťoven. Nepřímo tak benefity získává stát, který nemusí dorovnávat schodek zdravotního pojištění formou platby za státní pojištěnce a v přeneseném slova smyslu tedy vydělá daňový poplatník. Úspory by mělo generovat zejména eliminace duplicitních či jinak zbytných vyšetření a eliminace duplicitních či kontraindikovaných vydaných léčiv. Uvádí se, že procento závažných interakcí léčiv u nejvýznamnějších lékových skupin se pohybuje při běžné preskripci kolem 10%. Podíl zbytných vyšetření se dle některých zahraničních studií dosahuje až neuvěřitelných 30%. Přestože tyto studie vychází například ze systému zdravotnictví v USA, v kterých je „overtreatment“ rozšířeným problém z více důvodů, nepochybně i u nás lze očekávat nemalé procento vyšetření, které nebylo nutné opakovat. Je však obtížné vyčíslit přesnou výši těchto úspor, nicméně historicky byly zástupci SÚKLu při plném zavedení elektronické preskripce v ČR odhadovány roční úspory v oblasti léčiv na úrovni 4 miliard Kč. Za další přímý ekonomický benefit lze považovat v případě poskytovatelů zdravotních služeb možnost eliminace papírové zdravotnické dokumentace. Její listinná forma v žádaném případě není ekonomicky nenáročná. Do nákladů je nutné započítat cenu papíru, investice do tiskáren, spotřební materiál tiskáren a jejich servis a dlouhodobou archivaci dokumentů. Skutečnost že papírová forma je dražší než elektronická potvrzuje i trend oblasti elektronizace běžných kancelářských dokumentů napříč všemi odvětvími průmyslu. Výši těchto benefitů je složité odhadnout, nicméně je možné očekávat, že z dlouhodobého hlediska by měly vyrovnat náklady, které budou muset poskytovatelé investovat do změn svých informačních systémů výsledkem by měl být čistý zisk. Mezi ekonomické přínosy lze počítat i skutečnost, že tento návrh vychází z existujících systémů, které dále rozvíjí a není primárně založen na budování nové celonárodní databáze. Díky tomu je řešení velmi hospodárné.

91 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Poslední ekonomický přínos má potenciál se projevit v dlouhodobém horizontu a je spojen s analýzou a využitím dat získaných díky strukturované zdravotnické dokumentaci z běžných záznamů. Tento přínos však je založen na změnách, které se projeví až za nějaký čas. Z neekonomických benefitů je nutné dále zmínit vyšší právní garanci zpětné neměnitelnosti zdravotnické dokumentace, která je velmi významná pro pacienta. Dalším benefitem v této rovině je vyšší komfort pacienta i zdravotnických pracovníků, daný standardizací, konsolidací, přehledností a rychlou dostupností informací. Ve výčtu benefitů je dále nutné zmínit dlouhodobá udržitelnost s jasně definovanými odpovědnostmi za správu systému.

4.2.3

Identifikace a zhodnocení dopadů navrhovaného řešení elektronizace zdravotnictví na stávající stav z ekonomického hlediska

Přestože lze najít mnoho studií zaměřených na ekonomické benefity systémů eHealth, a systémy elektronizace zdravotnictví dokážou generovat významné úspory, nelze se na implementaci systémů eHealth dívat čistým porovnáním nákladů a úspor. V tomto konkrétním návrhu je například doporučena finančně náročná implementace zaručených elektronických podpisů a kvalifikovaných časových razítek pro vedení elektronické dokumentace v pouze elektronické formě. Tento krok nemá žádné kvantifikovatelné ekonomické přínosy, protože čistě elektronickou dokumentaci by bylo bezpochyby možné si představit i bez těchto technologií. Jde však o právní garanci neměnitelnosti zdravotnické dokumentace jejím „správcem“, což je zcela klíčové pro pacienta a tuto garanci bez těchto technologií prostě dosáhnout nelze. Soudní spory vedené v poslední době v oblasti pochybení zdravotníků potvrzují nutnost tohoto způsobu řešení. Na druhou stranu Národní ekonomická rada vlády (NERV) doporučila elektronizaci zdravotnictví jako jednu z deseti prioritních oblastí pro ekonomickou stabilizaci zdravotnictví. Zkušenosti z evropských států tento názor podporují. Na úrovni evropské unie je tento trend zachycen v dokumentu A Digital Agenda for Europe, který publikovala Evropská komise v druhé polovině května roku 2010. Vzhledem k provázání státu a správců zdravotní daně (zdravotních pojišťoven) nelze posuzovat dopady na tyto aktéry izolovaně. V případě velkého schodku ve zdravotním pojištění byl stát historicky nucen zvýšit platbu za tzv. státní pojištěnce a nedostatečný výnos z jedné daně (zdravotní pojištění) tak dorovnat z výnosů jiné daně. Naopak při kladné bilanci systému zdravotního pojištění bylo možné ponechat platbu za státního pojištěnce na stávající úrovni bez zohlednění inflace. V konečném důsledku je vždy plátcem daňový poplatník. Konečná bilance v zavádění eHealth na straně státu a zdravotních pojišťoven lze tak ve střednědobém odhadovat jako „kladnou nulu“. Zde se jedná spíše o to, že bez elektronizace by pravděpodobně systém zdravotnictví skončil ve významném propadu, do kterého se začíná dostávat již nyní. Bilance na straně poskytovatelů při realizaci tohoto řešení vychází z dlouhodobého hlediska jako spíše kladná, protože eliminací papírové formy dokumentace lze generovat nemalé přímé úspory.

4.2.4

Analýza možností a předpokladů využití principů prediktivní analytiky na nově vybudovaném systému

Navržené řešení počítá se standardizací formy elektronické dokumentace a jejího obsahu pomocí standardu openEHR a nomenklatury SNOMED CT. Podrobnosti k těmto nástrojům jsou uvedeny v bodě 2.3 Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky. Tato standardizace by měla zlepšit procesy systematického sběru dat s prediktivní informační hodnotou. Zlepšení by se mělo odrazit zejména v rovině nižší pracnosti takovéhoto sběru, protože data v běžných záznamech by v konečném důsledku měla být uložena ve strukturované (a tedy analyticky zpracovatelné) formě. To je však dlouhodobým cílem, protože zavedení strukturované zdravotnické dokumentace bude vyžadovat poměrně hodně úsilí a času. Základním předpokladem implementace strukturované zdravotnické dokumentace je tedy důkladná edukace zdravotnických pracovníků o smyslu a účelu této aktivity. Tato edukace musí obsahovat vysvětlení, v čem spočívají přínosy tohoto postupu pro zdravotnické pracovníky. Je nutné si uvědomit, že spolu s tímto bude nutné

92 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ edukovat v této rovině i tvůrce klinických systémů (programátory a analytiky) o účelné implementaci openEHR a SNOMED CT do jejich informačních systémů. Vzhledem k tomu, že návrh není založen na budování nějaké nové centrální databáze a naopak maximálně utilizuje stávající zdroje a distribuované úložiště, bude primárně nutné pro statistickou analýzu nadále využívat standardní a legislativou zavedené postupy vyhodnocení dat předávaných do Národních zdravotních registrů. U těchto registrů je narženo využít možností eliminace rodného čísla pomocí přidělení AIFO ze Základních registrů. Díky srovnání AIFO bude možné sestavit z jednotlivých hlášení kompletní případ, tak jak je to nezbytné například u Národního onkologického registru. Nové možnosti prediktivní analytiky pro Národní zdravotní registry přinese zejména projekt „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy“, jejímž zadavatelem je KSRZIS a který je součástí tzv. eREG, tedy modernizace resortních registrů. Tento projekt zahrnuje vytvoření moderního reportingu založeném na datovém skladu a transformačních procesech datových pump. Takto pojatý reporting odpovídá současným trendům Business Intelligence a bude mít významné pozitivní přínosy v rovině prediktivní analytika. Jeho benefity však nelze přičítat tomuto návrhu, protože jde o už existující projekt. Bylo by dále vhodné zrychlit proces předávání dat z pojišťoven do NRC tak, aby se celkový proces od poskytnutí péče do jejího zaznamenání v NRC zkrátil na řádově týdny. Dle tohoto návrhu je možné v rámci statistiky pracovat i s předběžnými daty, pokud je definován proces jejich aktualizace i finalizace a vlastní interpretace výsledků s těmito skutečnostmi počítá. Není tedy nutné čekat s předáním dat až na kompletní uzavření běžného roku.

4.2.5

Návrh modelu zpracování dat pro účely statistiky a vyhodnocování funkčnosti a ekonomiky elektronického zdravotnictví

Projekt elektronizace zdravotnictví musí nutně zahrnovat měřící procesy, které budou schopné informovat o smysluplnosti vynaložených investic. Z neekonomických benefitů je možné objektivně měřit pouze využívání Portálu formou měření návštěvnosti. Očekávané ekonomické benefity v případě systému elektronického zdravotnictví by měly plynout zejména z procesu sdílení zdravotnické dokumentace a upravené elektronické preskripce, měly by se měřené indikátory zaměřit na tyto oblasti. Klíčovými hypotézami, které by měly být testovány v rámci tohoto měření, jsou následující tvrzení:  

sdílení zdravotnické dokumentace vede k eliminaci duplicitních či jinak zbytných vyšetření využití elektronická preskripce vede k eliminaci duplicitních či kontraindikovaných léčiv

Je tedy navrženo měření zejména následující indikátorů:    

Počet Souhrnných informací o pacientech získaných ze systémů zdravotních pojišťoven Počet náhledů do lékové historie pacienta provedených na Centrálním úložišti Změny v objemu vykázané péče Změny počtu interakcí vyšších tříd u léčiv předepsaných jednomu pacientovi různými poskytovateli

Pro měření neekonomických benefitů navrženého systému je klíčové měření následujících indikátorů:      

Počet náhledů pacienta na vlastní Souhrn informací o pacientovi přes Portál Počet náhledů pacienta na vlastní dokumentaci přes Portál Počet provedených nastavení schémat zabezpečení pacientem přes Portál (změna výchozího nastavení) Počet náhledů pacientů na seznam poskytovatelů přistupujících k Souhrnům informací o pacientovi tohoto pacienta Počet objednání pacienta k poskytovateli realizovaný přes Portál Počet náhledů na výpis čerpání z osobního účtu realizovaný přes Portál

Uvedená data bude následně nutné interpretovat v jejich kontextu. Zejména půjde o historický kontext změn v objemech péče vyvolaných regulací a změny počtu interakcí vyvolaných osvětou realizovanou v rámci projektů zdravotních pojišťoven.

93 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3 4.3.1

Technický model Globální koncept architektury elektronického zdravotnictví

4.3.1.1 Východiska návrhu řešení architektury Základní východisko návrhu je definováno jako požadavek podmínek soutěže o návrh a je jím uložení zdravotnické dokumentace v místě jejího primárního vzniku. Od tohoto požadavku jsou odvozeny další východiska návrhu řešení architektury. Další východiska návrhu řešení architektury jsou popsána v následujících bodech.

4.3.1.1.1 Využití dat o poskytnuté péči z výkazů pro zdravotní pojišťovny Pro efektivní vyhledávání místa vzniku zdravotnické dokumentace je navrženo využití dat uložených ve výdajových částech informačních systémů zdravotních pojišťoven. Tyto data pokrývají i historické případy. IS zdravotní pojišťovny by stačilo doplnit pouze o konektor, který bude schopen poskytovat na vyžádání seznam kontaktů pacienta s poskytovateli zdravotních služeb ve strojově čitelné formě. Tento seznam bude doplněn i informacemi tzv. základního datasetu, tedy informacemi o výkonech, diagnózách, léčivech, očkování a dalších skutečnostech, uložených ve formě vykázaných kódů v IS zdravotní pojišťovny. Tyto informace lze doplnit případně informacemi shromážděnými o pacientovi v NZIS, nicméně tento postup je závislý na verdiktu Ústavního soudu ve věci shromažďování osobních údajů v rámci NZIS.

4.3.1.1.2 Omezení nově vytvářených systémů Požadavek na hospodárnost je zmíněn přímo v názvu soutěže. Z tohoto důvodu je návrh založen primárně na rozvoji existujících elektronických systémů namísto budování nových systémů a databází. Jako jediná zcela nová součást je navržen Portál. Registr radiační zátěže je navrženo realizovat formou doplnění odpovídajících polí do výkazů zdravotních pojišťoven. Pro přeshraniční zprostředkování sdílených údajů v rámci epSOS či návazných systémů je navrženo využití EESSI Access Pointu Centra mezistátních úhrad (CMÚ). CMÚ již má zavedenou infrastrukturu pro komunikaci se zdravotními pojišťovnami a část údajů přenášených v rámci epSOS již s IS zdravotních pojišťoven komunikuje pro účely evropské sítě EESSI.

4.3.1.1.3 Shoda rozhraní pro národní a mezinárodní sdílení Návrh vychází z předpokladu, že pro přeshraniční sdílení by se měly používat shodné mechanismy jako pro národní sdílení. V ideálním případě se jedná o shodné technologie, standardy, ale i procesní postupy. Tímto způsobem by mělo dojít k úsporám na prostředcích, které by jinak bylo nutné vynaložit na dvojí rozhraní, které by bylo samostatné pro národní a přeshraniční sdílení. Technická realizace výměny dokumentace předpokládá vytvoření závazného technického popisu rozhraní, které budou muset implementovat stávající výrobci IS pro poskytovatele zdravotních služeb a zdravotní pojišťovny. Tento popis rozhraní bude specifikovat jednak služby, používané v rámci výměny dokumentace (jako například „Seznam kontaktů pacienta s poskytovateli“ nebo „Získání dokumentace s hospitalizační epizodě“), ale i samotný formát vyměňované elektronické dokumentace. Takto strukturované elektronické dokumenty by mělo být možné po vzoru DASTA či DICOM ukládat i na offline média.

4.3.1.1.4 Single Sign-On a federace identity Pro autentikaci a autorizaci by mělo být využito pokročilých metod single-sign-on a federace identity tak, jak jsou použity již dnes v akademické sféře například na Karlově Univerzitě v Praze. Tyto postupy zajistí otevřenost pro využití mechanismů autentikace a autorizace i v jiných systémech státu i neziskové a komerční sféry. Z koncepčního hlediska jde o obdobu již dnes běžného přihlašování k veřejným informačním zdrojům pomocí účtu na Facebooku, Google+ nebo Seznam.cz. Cílem je aby si uživatelé systému (zdravotníci i pacienti) nemuseli pamatovat několik různých hesel, či neustále zadávat totéž heslo do stejných systémů a provozovatelům informačních zdrojů nevznikaly další náklady na budování stále nových a nových databází registrovaných a ověřených uživatelů.

4.3.1.1.5 Propojení s eGovernment Systém eHealth je navržen jako těsně propojený s existujícími i plánovanými aktivitami eGovernmentu v ČR. Tato integrace je navržena zejména v rovině propojení se Základními registry, kde je v dlouhodobém horizontu navrženo vybudování resortní brány (proxy) pro řízené využívání informací ze Základních registrů i jinými organizacemi než pouze orgány veřejné moci. Tento způsob je plánován i v jiných resortech, například Ministerstva financí, kde by

94 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ banky a komerční pojišťovny mohly se svolením svého klienta využívat služeb Základních registrů dle stanovených podmínek. Další rovinu integrace s eGovernment představuje možnost využití Bezpečnostního osobního kódu (BOK), který se přiděluje každému nově vydanému občanskému průkazu bez ohledu na to, zdali obsahuje elektronický čip pro uložení digitálních certifikátů či ne. Také ke dříve vydaným občanským průkazům je možné BOK vydat. Tento BIK reprezentuje PIN či heslo občana, které lze využít při poskytování různých online služeb, jako je například přístup na Portál. Systém eHealth bude dále propojen v rovině datových schránek, které lze využít pro různé offline služby systému – například pro doručení vyžádané zdravotní dokumentace.

4.3.1.1.6 Použití mezinárodních standardů a otevřenost k rozvoji Koncept architektury je postaven na využití otevřených standardů. Tyto standardy jsou jednak obecného technického charakteru, jako jsou například webové služby s pomocí XML, HTTP, SSL a SOAP. Je však navrženo i intenzivní využití mezinárodně akceptovaných standardů, jako je HL7, IHE, openEHR, DICOM, SNOMED CT a další.

4.3.1.1.7 Servisně orientovaná architektura Architektura je dále založena na tzv. servisně orientovaném přístupu (SOA – Service Oriented Architecture). Tento přístup je založen na tom, že nějaký systém nabízí a poskytuje jiným systémům určité služby, obvykle definované jako „požadavek-odpověď“. S těmito službami pak jejich konzument pracují tím způsobem, že posílá zprávu (obvykle ve formátu XML) obsahující data požadavku a shodným či jiným komunikačním kanálem mu poskytovatel služby vrací odpověď na jeho požadavek.

4.3.1.2 Návrh architektury elektronického zdravotnictví 4.3.1.2.1 Služby a komunikační schéma Návrh architektury vychází z katalogu služeb, nezbytných pro správnou funkci navrženého řešení: 











Informační systém zdravotní pojišťovny o Služba poskytování Souhrnu informací o pacientech a indexů zdravotnické dokumentace uložených v místě vzniku o Služba poskytování Seznamu historie přístupů k Souhrnu informací o pacientech a indexům zdravotnické dokumentace uložených v místě vzniku Národní registr poskytovatelů zdravotních služeb o Služba pro vyhledání poskytovatele dle kritérií o Služba poskytování informací o konkrétním poskytovateli služeb na základě identifikátoru Národní registr zdravotnických pracovníků o Služba pro vyhledání zdravotnické pracovníka dle kritérií o Služba poskytování informací o konkrétním poskytovateli služeb na základě identifikátoru Centrální úložiště elektronických receptů o Služba poskytování výpisu z lékové historie o Služby Založení, Změny, Zrušení a Získání eReceptu o Služby Založení, Změny, Zrušení a Získání výdeje na eRecept o Služby Založení, Změny, Zrušení a Získání záznamu o výdeji na papírový recept EESSI Access Ponit Centra mezistátních úhrad (v roli epSOS National Contact Point) o Služba poskytování Souhrnu informací o pacientech u cizinců z EU o Služba ePreskripce u cizinců z EU Informační systém poskytovatele zdravotních služeb (či „krajské úložiště“ například založené na referenční implementaci) o Služba poskytování textové zdravotnické dokumentace uložené v místě vzniku o Služba poskytování obrazové zdravotnické dokumentace uložené v místě vzniku

95 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ o

Služba poskytování Seznamu historie přístupů ke sdílené zdravotnické dokumentaci uložené v místě vzniku

Využití integrační platformy na principu ESB (Podniková sběrnice služeb) není považována dle tohoto návrhu za nebytnou, protože komunikujících systémů sice bude více, ale specifikovaných rozhraní, poskytujících služby jiným systémům, bude jen omezený počet. Centralizovaná integrační platforma na principu ESB by tak pouze vytvářela nové možné místo selhání systému a představovala by i bezpečnostní riziko.

Národní zdravotní registry (NOR, hospitalizovaní, reprodukční zdraví, kardio, a podobně)

Portál pro pacienty, zdravotnické pracovníky a poskytovatele

EESSI Access Point Centra mezistátních úhrad v roli epSOS National Contact Point

Národní registry zdravotnických pracovníků a poskytovatelů zdravotních služeb

Informační systém Informační systém zdravotní Informační systém zdravotní pojišťovny zdravotní pojišťovny pojišťovny

Centrální úložiště elektronických receptů

Informační systém poskytovatele zdravotních služeb lůžkové péče A

Informační systém poskytovatele zdravotních služeb lůžkové péče B

„Krajské úložiště“ (provozováno např. dodavatelem software pro ambulance)

Informační systém poskytovatele zdravotních služeb v rámci samostatné ambulanceB

Na výše uvedeném schématu nejsou pro přehlednost uvedeny tyto komponenty:     

VPN síť – pokrývá celou výše uvedenou komunikaci Systémy ePACS a ReDiMed – jsou považovány za součást Informačního systém poskytovatele zdravotních služeb Infrastruktura čipových karet a čteček Infrastruktura eGovernementu – Základní registry a datové schránky Infrastruktura bezpečnosti zajištující ověření oprávněnosti požadavku na sdílenou zdravotnickou dokumentaci

96 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Schéma komunikace je následující: 







Portál získává následující informace: o Od IS zdravotních pojišťoven - Souhrny pacientských informací a indexy umístění zdravotnické dokumentace, uložené v místě vzniku o Od IS zdravotních pojišťoven - Seznamy historie přístupů k Souhrnu informací o pacientech a indexům zdravotnické dokumentace uložených v místě vzniku o Od Centrálního úložiště elektronických receptů - Náhled na lékový záznam pacienta o Od Národního registru zdravotnických pracovníků a poskytovatelů - Informace o zdravotnických pracovnících a poskytovatelích o Od Národních zdravotních registrů (odborných) - Informace o konkrétním pacientovi o Od IS Poskytovatele zdravotních služeb (či „krajského úložiště“) – textový a obrazový obsah zdravotnické dokumentace uložené v místě vzniku o Od IS Poskytovatele zdravotních služeb (či „krajského úložiště“) – Seznam historie přístupů ke sdílené zdravotnické dokumentaci uložené v místě vzniku EESSI Access Point Centra mezistátních úhrad (v roli epSOS National Contact Point) získává následující informace: o Od IS zdravotních pojišťoven - Souhrny pacientských informací a indexy umístění zdravotnické dokumentace, uložené v místě vzniku o Od Centrálního úložiště elektronických receptů - Náhled na lékový záznam pacienta Informační systém poskytovatele zdravotních služeb lůžkových zdravotních služeb získává následující informace: o Od IS zdravotních pojišťoven - Souhrny pacientských informací a indexy umístění zdravotnické dokumentace, uložené v místě vzniku o Od Centrálního úložiště elektronických receptů - Náhled na lékový záznam pacienta o Od Národního registru zdravotnických pracovníků a poskytovatelů - Informace o zdravotnických pracovnících a poskytovatelích o Od IS Poskytovatele zdravotních služeb (či „krajského úložiště“) – textový a obrazový obsah zdravotnické dokumentace uložené v místě vzniku „krajské úložiště“ žádné informace samo o sobě nezískává (vyjma komunikace s Národním registrem zdravotnických pracovníků a poskytovatelů pro ověření autorizace) , vystupuje pouze v roli poskytovatele informací

4.3.1.2.2 Sigle-Sign On pomocí SAML Security Assertion Markup Language (SAML) je standard založený na XML poskytující mechanismus pro výměnu autentizačních a autorizačních dat mezi zúčastněnými stranami, tj. poskytovatelem služeb a poskytovatelem identity. Je vyvíjen organizací OASIS. Funguje na principu „prosazení“ důvěry, tedy aplikace může prosadit, že jde o určitého uživatele a ten má určitá privilegia. V praxi řeší SAML problém jednotného přihlašování na více webů - Single Sign-On ( SSO ). Nějaký portál autentizuje uživatele. Uživatel se připojí k jinému portálu a ten si vyžádá informace z předcházejícího portálu. Pokud dostane správné a ověřené informace, dojde k již zmíněnému prosazení důvěry i na tento portál a uživatel bude i zde automaticky autentizován. Je tedy vhodné rozdělení na poskytovatele identity a poskytovatele služeb. Pokud chce uživatel přistupovat ke zdrojům poskytovatele služeb, pak jeho identitu zkontroluje jeho poskytovatel identity a ten posílá informace poskytovateli služeb, u kterého uživatel žádá o poskytnutí služby. Tímto se odpovědnost za ověření identity přesunuje vždy na poskytovatele identity. Tato koncepce vede k ustanovení tzv. federací, které si mohou navzájem vyměňovat informace o autentizaci subjektu. SAML poskytuje pouze distribuci samotné informace mezi zúčastněnými stranami, a proto nezáleží na jejím počtu. Standard nespecifikuje konkrétní implementaci samotného ověřování identity u poskytovatele identity. V rámci návrhu je uvažováno využití SAML pro realizaci konceptu Single Sign-On.

97 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3.1.2.3 Datová centra V rámci tohoto návrhu není nutné budovat nová datová centra na centrální úrovni. Na centrální úrovni se závádí pouze koncentrátor VPN a Portál. Centrální uzel VPN sítě by měl být ve správě KSRZIS a měl by být umístěn do jeho datového centra. Správa VPN vytvořené pro potřeby elektronické preskripce by měla rovněž přejít ze SÚKLu na KSRZIS a být sloučena s novou VPN pro potřeby celého eHealth. Portál by měl být rovněž umístěn do stávajícího datového centra KSRZIS. V případě budování tzv. krajských úložišť nelze plně předjímat řešení jejich správy. Bude záležet vlastně na jednotlivých poskytovatelích ambulantních služeb, koho si zvolí. Vzhledem k tomu, že bude vytvořena referenční implementace, může „krajské úložiště“ provozovat prakticky kdokoliv, kdo bude disponovat vhodným HW a poskytovatelé ambulantních služeb mu budou ochotni svěřit svá data. Primárně uvažovanými skupinami jsou kraje, krajské nemocnice, sdružení poskytovatelů, stávající výrobci informačních systémů pro poskytovatele zdravotních služeb.

Na následujícím schématu je uveden celkový pohled na návrh architektury elektronického zdravotnictví.

4.3.1.3 Přínosy navrhovaného řešení architektury elektronického zdravotnictví 4.3.1.3.1 Eliminace problémů s obavami o ochranu osobních údajů Díky tomu, že obsahem návrhu není vybudování žádané nové databáze osobních údajů, není ani prostor pro obavy veřejnosti o ochranu těchto údajů. Žádná zájmová skupina proto nemůže tuto skutečnost zneužít pro diskreditaci celého záměru elektronizace zdravotnictví. Nově by měl být vytvořen pouze Portál, což má z hlediska ochrany osobních údajů také pozitivní přínos, protože jeho uživatelé získají okamžitý přehled o osobních údajích, kterých jsou o nich v rámci eHealth evidovány.

4.3.1.3.2 Eliminace velkých investic a provozních nákladů Vzhledem k maximálnímu omezení nově vytvářených systémů (nově je navrženo vybudovat pouze Portál) nejsou nutné velké investice a je omezeno i navýšení provozních výdajů. Pro další snížení nákladů je navrženo racionální sjednocení rozhraní pro národní a přeshraniční sdílení dat. Žádná zájmová skupina proto nemůže použít argument finanční náročnosti pro diskreditaci celého záměru elektronizace zdravotnictví.

4.3.1.3.3 Eliminace obav poskytovatelů ze ztráty kontroly nad jejich dokumentací Jednou z významných obav poskytovatelů zdravotních služeb z nově plánovaného eHealth, zejména ze segmentu samostatných ambulancí je založena na strachu z možnosti „vytunelování“ jejich kartotéky. Tito poskytovatelé považují svou zdravotnickou dokumentaci za svůj majetek a za kapitál určující jejich obchodní potenciál. Nová legislativa sice obsahuje pravidla pro předávání a nahlížení do zdravotnické dokumentace, nicméně je možné, že některá zájmová skupina by se mohla snažit tyto obavy využít ve svůj prospěch. Návrh je proto počítá s tím, že tzv. krajská úložiště, která by umožnila online výměnu zdravotnické dokumentace vzniklé v samostatných ordinacích, by měli vytvářet pro poskytovatele zdravotních služeb jejich stávající dodavatelé IS nebo i jiné subjekty, které si poskytovatelé sami zvolí. Tyto úložiště bude moci provozovat prakticky kdokoliv (kraj, krajské nemocnice výrobci SW, sdružení samotných lékařů), kdo bude disponovat kapacitně dostatečným hardware, protože referenční implementace, tedy software který realizuje jejich služby, bude volně dostupná. Bude tedy záležet na samotných poskytovatelích ambulantních služeb, koho si zvolí. Tyto úložiště by měly být koncipovány primárně jako „bezpečné úložiště automaticky vytvářených záloh zdravotnické dokumentace“ a právně řešeny běžným komerčním vztahem ve standardním režimu „správce - zpracovatel“ dle zákona o Ochraně osobních údajů.

98 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3.1.3.4 Shoda s aktuálním směřováním přeshraničního sdílení údajů ve zdravotnictví Návrh architektury předpokládá ve střednědobém horizontu převod služeb vyvinutých v rámci projektu epSOS do rutinního provozu v rámci sítě Electronic Exchange of Social Security Information (Elektronická výměna informací o sociálním zabezpečení - EESSI). Tato síť je využívána členskými státy EU pro výměnu informací ve zdravotněsociální oblasti. Konkrétně v oblasti zdravotnictví je používána pro výměnu informací v rámci mezinárodního přeúčtování přeshraniční péče. Tato síť je zpřístupněna kompetentním institucím v rámci ČR přes EESSI Access Point, který aktuálně provozuje Centrum mezistátních úhrad. Směrem rozšíření služeb EESSI pro poskytovatele zdravotních služeb jde i projekt NewS4EESSI, který v rámci ČR realizuje Medtel o.p.s. Lze očekávat, že síť EESSI bude využita i pro institucionalizované služby, nyní poskytované v rámci projektu epSOS, tak jako byly stávající resortní sítě využity i při rozšiřování jiných agend EU (například při řešení agendy spotřebních daní byla využita stávající síť používaná pro celní problematiku, protože tyto agendy byly ve většině států řešeny v rámci jednoho resortu).

4.3.1.3.5 Striktní vynucení bezpečnosti a evidence přístupů Navržená architektura umožňuje přesnou evidenci přístupů subjektů požadujících informace. První evidenci je nutné realizovat na úrovni informačního systému zdravotní pojišťovny, který poskytuje seznam míst, kde se může dokumentace pacienta nacházet. Druhá evidence přístupů musí být realizována na úrovni zdrojového systému, ve kterém je uložena požadovaná dokumentace. Evidenci přístupů k údajům konkrétního pacienta je pak možné zobrazit v rámci Portálu. Zdravotní pojišťovny by následně měly zavést mechanismy zpětné kontroly vykázání nějakého výkonu u poskytovatelů, kteří požadovali přístup k seznamu míst uložení dokumentace pacienta a v případě nevykázání prověřovat tuto podezřelou aktivitu v rámci svých běžných kontrol.

4.3.1.3.6 Zapojení zdravotních pojišťoven do budovaného eHealth Návrh architektury intenzivně vtahuje zdravotní pojišťovny do eHealth řešení a dává jim klíčovou roli v celém systému elektronického zdravotnictví. Využívá databázi nezpochybnitelně nezbytných osobních údajů v rámci výkazů zdravotních pojišťoven. Tuto databázi navíc rozšiřuje o informaci o radiační zátěži, která je významná pro hodnocení kvality poskytnuté péče, kterou by se zdravotní pojišťovny měli zabývat.

4.3.1.3.7 Návaznost na eGovernment Díky propojení se Základními registry a možnosti poskytovatelů zdravotních služeb využít Základní registry prostřednictvím resortní brány (proxy), lze garantovat konzistentnost informací v rámci celého eHealth. Využití Bezpečnostního osobního kódu (BOK) a datových schránek odstraňuje z resortu zdravotnictví břímě nutnosti budování vlastní databáze ověřených uživatelů s potřebou bezpečné distribuce hesel.

4.3.1.3.8 Otevřenost k dalšímu rozvoji Díky využití technických i odborných standardů je systém otevřený k dalšímu rozvoji. Architektura budovaná dle principu SOA je flexibilní k dalšímu rozšíření systému a omezuje problém závislosti na stávajícím dodavateli konkrétního informačního systému.

4.3.2

Oblast standardizace

Níže jsou uvedeny mezinárodní standardy a „de-facto standardy“ a nomenklatury či klasifikace, které tento návrh doporučuje zavést v ČR, včetně postupu a harmonogramu zavádění.

4.3.2.1 HL7, DICOM a IHE HL7 musí být pro použití v rámci ČR významně doplněn proti aktuální verzi na obecné i národně specifické úrovni. Z IHE bude nutné vybrat vhodné profily a ověřit jejich aplikovatelnost pro prostředí ČR. DICOM je v ČR již zavedeným standardem a není potřeba jej explicitně zavádět. U některých systémů v ČR bude nicméně vyžadována implementace DICOM podpory pro službu „Modality performed procedure step“, respektive její rozšíření o předávání informací o radiační zátěži. Postup aplikace HL7, DICOM a IHE pro potřeby sdílení dokumentace na národní úrovni shrnuje následující tabulka. Harmonogram v měsících

Popis kroku

99 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ T T+1 T+6

T + 10 T + 12 T + 13

Rozhodnutí o využití HL7, DICOM a IHE pro sdílení zdravotnické dokumentace na národní úrovni a zajištění financování tohoto postupu Ustanovení pracovní skupiny ze zástupců sdružení HL7 Česká republika a výrobců dotčených IS poskytovatelů zdravotních služeb a zdravotních pojišťoven Vytvoření specifikace, prototypů a případné národní extenze HL7, DICOM a IHE pro použití v oblasti sdílení dokumentace na národní úrovni (včetně začlenění DASTA NČLP do HL7 jako datového slovníku) a evidence radiační zátěže Návrh edukačních programů pro vývojáře relevantních systémů v oblasti využití HL7, DICOM a IHE Vytvoření referenční implementace ve zvolené technologii pro sdílení dat na národní úrovni pro IS poskytovatelů zdravotních služeb a zdravotních pojišťoven pomocí HL7, DICOM a IHE Realizace edukačních programů pro vývojáře relevantních systémů v oblasti využití HL7, DICOM a IHE

Tabulka 7 Postup aplikace HL7, DICOM a IHE pro potřeby sdílení dokumentace na národní úrovni

Podrobný popis a zhodnocení HL7, DICOM a IHE pro použití v rámci ČR je uveden v bodě 2.3.1 Technické a komunikační standardy.

4.3.2.2 openEHR a EN13606 Standardy openEHR a EN13606 by měly být cíleně zavedeny do ČR pro snížení závislosti poskytovatelů zdravotní péče na jejich dodavatelích informačních systémů a pro možnost přímého ovlivnění struktury zdravotní dokumentace jejími primárními uživateli – zdravotníky. Postup aplikace openEHR a EN13606 pro potřeby eHealth v rámci ČR shrnuje následující tabulka. Harmonogram v měsících T T+1

T+2 T+3 T+8 T + 12

Popis kroku Rozhodnutí o využití openEHR a EN13606 v rámci národního eHealth a financování této aktivity Institucionalizace openEHR a EN13606 v rámci ČR buď přímo v rámci struktur MZ/ÚZIS/KSRZIS a nebo vhodné neziskové organizace (po vzoru sdružení HL7 Česká republika) Návrh edukačních programů pro zdravotníky a informatiky v oblasti využití openEHR a EN13606 Realizace edukačních programů pro zdravotníky a informatiky v oblasti využití openEHR a EN13606 Vytvoření popisu EHR extraktu pro sdílení dokumentace na národní úrovni dle normy EN13606 Vytvoření pilotního doporučení pro klinickou praxi jedné zvolené odbornosti obsahujícího šablonu dokumentace ve formátu openEHR

Tabulka 8 Postup aplikace openEHR a EN13606 pro potřeby eHealth v rámci ČR

Podrobný popis a zhodnocení openEHR a EN13606 pro použití v rámci ČR je uveden v bodě 2.3.1.5 openEHR a EN13606.

4.3.2.3 SNOMED CT Nomenklaturu SNOMED CT je nutné pro použití v rámci ČR nejprve přeložit. Zavedením této nomenklatury do ČR lze podpořit strukturování zdravotních záznamů, které lze dále použít v pokročilých aplikacích zdravotnické informatiky. Postup aplikace SNOMED CT pro potřeby eHealth v rámci ČR shrnuje následující tabulka. Harmonogram v měsících T T+1 T + 24 T + 25 T + 26

Popis kroku Rozhodnutí o využití SNOMED CT v rámci národního eHealth a financování této aktivity Institucionalizace SNOMED CT v rámci ÚZIS Vytvoření překladu a národní lokalizace SNOMED CT Návrh edukačních programů pro zdravotníky a informatiky v oblasti využití SNOMED CT Realizace edukačních programů pro zdravotníky a informatiky v oblasti využití SNOMED CT

Tabulka 9 Postup aplikace SNOMED CT pro potřeby eHealth v rámci ČR

100 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Podrobný popis a zhodnocení SNOMED CT pro použití v rámci ČR je uveden v bodě 2.3.2.6 SNOMED CT.

4.3.3

Systémy identifikace

V oblasti identifikace je uživatelů v rámci jakéhokoliv elektronického systému je nutné zásadně rozlišovat dva odlišné procesy, které však na sebe obvykle navazují:  

Autentizace - proces ověření proklamované identity subjektu Autorizace - proces získávání povolení s provedením nějaké operace či přístupem k určitým datům

Proces Autentizace je obvykle realizován s pomocí kombinace uživatelského jména a hesla či PIN. Lze však použít i například digitální certifikát, přičemž znalostí jeho privátního klíče je ověřena identita uživatele. Situace kdy se v rámci tohoto procesu nepoužívá pouze znalost určitého jména a hesla, ale i vlastnictví nějaké zařízení, například čipové karty, tokenu, kalkulátoru či generátoru unikátních čísel, se nazývá třífaktorová autentizace. Sem spadá i využití kódu zasílaného v SMS na nějaké telefonní číslo. Tímto procesem se ověřuje, zdali dotyčná osoba je skutečně tím, kým tvrdí že je. V případě použití hesla či PIN (tzv. sdílená tajemství neboli klíč) je nutné aby si obě komunikující strany nejprve vyměnili po jiném ověřeném kanálu (například doporučený dopis do vlastní rukou) toto heslo či PIN. V tom spočívá jádro tzv. problému distribuce klíčů. Řešení tohoto problému je obvykle velmi nákladnou položkou v implementaci celonárodních systémů. Navíc při samostatném řešení tohoto problému pro každý systém vzniká pro uživatele nepřehledná situace s mnoha hesly k různým systémům řešící třeba i obdobné agendy. Tento problém lze efektivně řešit více způsoby: 





pomocí digitálních certifikátů - problém distribuce klíčů přenáší z provozovatele systému na jeho uživatele a důvěryhodnou třetí stranu - certifikační autoritu. Nevýhodou je technická složitost a finanční náročnost přenášená obvykle na uživatele, který si platí služby certifikační autority (vydání certifikátu pro elektronický podpis). pomocí již existující databáze hesel či PIN – lze využít hesla či PIN, které již někdo jiný vydal potenciálním uživatelům systému a požadovat jejich zadání a následně ověřovat zadané heslo v existující databázi. Nevýhodou je nutnost opakovaného zadávání téhož hesla do různých systémů, které může tvůrce dotyčného systému případně zneužít. pomocí tzv. jednotného přihlašování (Single Sign-On) – je nastaven proces důvěry s třetí stranou, tzv. poskytovatelem identity, který zajišťuje online ověření uživatele určitým způsobem (obvykle pomocí uživatelského jména a hesla) a vydává pak uživateli nějaký bezvýznamový kód. Tento kód pak uživatel (respektive jeho webový prohlížeč) prezentuje dalším systémům, který zpětně ověřují jeho platnost u původního vydavatele identity. V praxi je rozdíl proti předchozímu způsobu využívání sdílené databáze hesel takový, že uživatel musí svoje heslo zadat pouze jednou u poskytovatele identity a další systémy jeho identitu rozpoznají automaticky. Tento způsob dnes již využívá mnoho webových informačních zdrojů, které umožňují přihlášení například pomocí účtu na Facebooku, Google+ či Seznam.cz.

Na proces Autentizace navazuje obvykle proces Autorizace, která je obvykle řešena pomocí nějakého registru, ve kterém jsou evidovány atributy dané osoby (pracovní funkce, zařazení do určité organizační jednotky), ze kterých jsou pak odvozována oprávnění uživatele v systému. Pro autentizaci k online zdrojům je v rámci eGovernmentu v ČR navržen koncept využití tzv. bezpečnostního osobního kódu (BOK), což je 4 až 10ti ciferné číslo, které si nyní volí povinně každý občan při převzetí nového občanského průkazu. Tento BOK by mělo být možné využívat v různých systémech eGovernmentu a tím pádem i eHealth. Používání přístupových kódů k datovým schránkám je nyní koncepčně rezervováno pro přístup k datovým schránkám. Systém identifikace pacientů a zdravotnických pracovníků by měl být otevřený pro možnosti řízeného využití Single-Sign On i dalšími informačními zdroji v oblasti zdravotnictví. To se vztahuje na státní, neziskový i komerční sektor ve smyslu poskytovatelů zdravotních služeb i dalších organizací, poskytující nějaké datové zdroje v oblasti zdravotnictví. Je nutné zásadně rozlišovat mezi následujícími pojmy, které mohou být myšleny pojmem identifikátor:

101 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 





identifikační kód osoby – jde o kód, který jednoznačně identifikuje osobu mezi jinými osobami. Aktuálně je nejrozšířenějším identifikátorem osoby v ČR rodné číslo. Základní registry s rodným číslem nepracují a použití rodného čísla bude zcela znemožněno od roku 2020. Identifikátorem osoby v jednotlivých agendách by měly být AIFO a případně dotyčná instituce může vydat vlastní identifikátor osoby – například číslo pojištěnce, které však bude muset být bezvýznamovým identifikátorem. identifikační doklad osoby – v našich podmínkách obvykle občanský průkaz či cestovní pas (eventuálně řidičský průkaz), přičemž proces Autentizace osoby v neelektronickém světě se provádí pomocí porovnání fotografie s vzhledem dotyčné osoby. Pokud bychom hledali protějšek identifikačního dokladu v elektronickém světě, byl by to nejspíš digitální certifikát vydaný certifikační autoritou, kdy proces Autentizace se provádí pomocí prokázání vlastnictví privátního klíče k certifikátu danou osobou. nástroj pro identifikaci osoby při vzdáleném přístupu k elektronickým systémům – v podmínkách eGovernmentu ČR jde o výše zmiňovaný BOK, pro datové schránky se používá jiný identifikační nástroj (vlastní uživatelské jméno a heslo)

4.3.3.1 Identifikace pacienta 4.3.3.1.1 Shrnutí navrhovaného řešení Identifikaci pacienta je vhodné řešit pomocí nyní dostupných prostředků, kterými jsou EHIC, občanský průkaz s bezpečnostním osobním kódem (BOK) a elektronický podpis dle legislativních pravidel. Jako unikátní veřejný kód pacienta by mělo být nadále prosazováno používání číslo pojištěnce, přestože už nebude moci být odvozeno od rodného čísla. Jako primární neveřejný identifikátor pacienta v případě občanů ČR je nutné v rámci eHealth používat jeho AIFO ze Základních registrů tak jako v rámci celého eGovernmentu. Toto řešení nenese pro eHealth prakticky žádné náklady.

4.3.3.1.2 Detailní návrh řešení Jako identifikátor pacienta ve smyslu identifikačního kódu, lze používat v systému elektronického zdravotnictví v určitých situacích číslo Evropského průkazu zdravotního pojištění (European Health Insurance Card nebo EHIC). Číslo průkazu (nejen EHIC, ale i jakéhokoliv jiného průkazu obecně) má však řadu vlastností, která jej činí nevhodným pro určité specifické případy užití. Především jde o číslo plastikové kartičky a nikoliv o číslo osoby, a není tedy možné jej využívat tak jako rodné číslo, které je po dobu života dané osoby neměnné. Osoba může v průběhu svého života při každé návštěvě poskytovatele zdravotních služeb prezentovat jiný průkaz EHIC, protože předchozí ztratí nebo mu skončí platnost. Záznamy však musejí znít na téhož pacienta.

Obrázek 18 Náhled na EHIC

Z tohoto důvodu je nutné jako primární neveřejný identifikátor pacienta v případě občanů ČR používat jeho AIFO ze Základních registrů. Jako veřejný identifikátor pro dohledání AIFO je možné používat číslo EHIC, číslo občanského průkazu, číslo pojištěnce (po zrušení rodných čísel bude zřejmě změněn jeho formát, nicméně měla by být zachována jeho neměnnost při přechodu mezi zdravotními pojišťovnami). V případech cizinců či nepojištěných

102 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ osob je nutné používat alternativní dostupné identifikátory – například číslo občanského průkazu či cestovního pasu. V určitých případech, jako například pro vyhledání eReceptu v rámci upraveného Centrálního úložiště na SÚKL, bude tedy možné číslo EHIC použít jako „identifikátor pacienta“ v procesu předepisování či výdeje léčiv. Nicméně v Centrálním úložišti musí být eRecept evidován na konkrétní AIFO pacienta, které může být při předepsání i výdeji dohledáváno v Základních registrech dle čísla EHIC, čísla pojištěnce, čísla občanského průkazu nebo kombinace jména, příjmení, data narození a trvalého bydliště. Samotný průkaz EHIC pak není identifikátorem ve smyslu identifikačního dokladu, neboť nemá fotografii osoby a samotným vlastnictvím dokladu identitu prokazovat principiálně nejde. Průkaz EHIC je v terminologii EU „nárokovým dokladem“ – reprezentuje tedy pouze nárok pacienta na ošetření z prostředků veřejného zdravotního pojištění za daných podmínek. Jako identifikační doklad je tedy již dnes používán ve zdravotnictví ČR občanský průkaz (či cestovní pas), který předkládá pacient například při nové registraci u poskytovatele zdravotních služeb spolu s EHIC. Dle zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování, mají dle § 41 odst. (3) mají pacienti povinnost se na žádost zdravotnického pracovníka tímto dokladem prokázat. Jako identifikační nástroj pro vzdálený přístup k elektronickým systémům připadá pro pacienty v úvahu především BOK vázaný na jejich občanský průkaz anebo případně digitální certifikát vydaný akreditovanou certifikační autoritou. Přestože úroveň bezpečnosti je u digitálních certifikátů nepochybně vyšší, tyto možnosti jsou pro potřeby eHealth věcně rovnocenné a systém eHealth by je měl považovat za rovnocenné způsoby prokázání digitální identity. Pro osoby nevlastnící občanský průkaz připadá jako jediná možnost v úvahu digitální certifikát. V případě požadavku na autorizaci výkazu péče pacientem u poskytovatele zdravotních služeb (v ordinaci lékaře) by měl být rovněž používán BOK. V takovémto případě by měly být nicméně zpracována postupy pro případy ošetření pacienta v bezvědomí a podobné situace, kdy BOK není možné vyžadovat. Zadávání BOK u poskytovatele by také vyžadovalo vybavení ordinací chráněnou numerickou klávesnicí (PinPad), protože při zadávání na běžné klávesnici by mohlo dojít k odchycení zadávaného BOK škodlivým software. Využití sKarty v rámci agendy zdravotního pojištění je problematické. V první řadě jde o platební kartu Maestro, která musí odpovídat zavedeným standardům asociace MasterCard, kladeným na její vzhled z obou stran. Na přední straně musí být logo Maestro a identifikační údaje ve striktně definovaném formátu a na zadní straně pak musí být místo pro podpis, CCV kód a holografický ochranný prvek. Přestože je jistá volnost v grafickém zpracování karty a je tedy možné na kartu umístit i další údaje, není příliš reálné celou jednu stranu sKarty využít pro potřeby EHIC. Dalším problémem je odlišný životní cyklus platnosti obou karet. Není proto reálné ve stávající podobě sKartu využívat v agendách zdravotnictví. Sloučení EHIC s občanským průkazem není možné realizovat dříve, než dojde k plné eliminaci dočasně uváděných údajů na občanském průkazu, jako je rodné číslo a trvalý pobyt. Rovněž by muselo dojít eliminaci zóny tzv. strojově čitelných údajů na zadní straně (text napsaný fontem vhodným pro strojové čtení). Důvodem je nedostatek prostoru na plastikové kartě, která musí odpovídat rozměru 85,6 x 54 mm, který určuje mezinárodní norma ISO 3554. Do té doby je však reálnější na národní úrovni uplatnění „dvojdílnosti“ občanského průkazu a zpřístupňovat informace nezbytné k provádění agend zdravotního pojištění pomocí systému Základních registrů, se kterým budou moci zdravotníci pracovat. Tento návrh odpovídá i skutečnosti, že reálnou platnost EHIC je stejně vhodné před použitím ověřovat online. Ohledně případného slučování více karet do jedné by bylo vhodné také vyčkat aktivity EU v této oblasti, neboť je diskutována i evropská podoba elektronického EHIC (e-EHIC), která by obsahovala elektronický čip.

4.3.3.1.3 Indikativní rozpočet realizace Využití EHIC a BOK či digitálních certifikátů pro identifikaci pacientů či nepředstavuje pro systém eHealth žádnou dodatečnou finanční zátěž. Financování výdeje certifikátů pro pacienty z prostředků eHealth tento návrh nedoporučuje. Začlenění BOK a digitálních certifikátů jako rovnocenných možností přihlášení k Portálu pacienta je součástí indikativního rozpočtu pro Portál pacienta.

4.3.3.1.3.1 Návrh harmonogramu v časové ose

103 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Vydávání EHIC, BOK a digitálních certifikátů probíhá nezávisle na inciativě eHealth a tento proces není třeba z pozice eHealth nijak ovlivňovat. Začlenění BOK a digitálních certifikátů jako rovnocenných možností přihlášení k Portálu pacienta je součástí celkového harmonogramu pro Portál pacienta.

4.3.3.1.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou dány dle plánu zavádění eGovernment.

4.3.3.1.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace jsou dány dle plánu zavádění eGovernment.

4.3.3.2 Identifikace zdravotnického pracovníka 4.3.3.2.1 Shrnutí navrhovaného řešení Identifikaci zdravotnického pracovníka je vhodné řešit pomocí již nyní dostupných prostředků, kterými jsou občanský průkaz s bezpečnostním osobním kódem (BOK) a elektronický podpis dle legislativních pravidel. Vzhledem k mandatorní potřebě elektronického podpisu pro vedení zdravotnické dokumentace nezpochybnitelné při případných sporech je nutné vybudovat v rámci zdravotnictví ČR infrastrukturu, zahrnující čtečky čipových karet s PIN klávesnicí. Je nutné prozkoumat v rámci samostatné studie vhodnost využití čipu občanském průkazu pro uložení digitálního certifikátu pro běžné použití v klinické praxi zdravotníka ve srovnání s vydáváním dedikované čipové karty pro zdravotnické pracovníky. Jako unikátní veřejný kód zdravotnického pracovníka by mělo být prosazováno používání čísla zdravotnického pracovníka přiděleného Národním registrem zdravotnických pracovníků. Jako primární neveřejný identifikátor pacienta v případě občanů ČR je nutné v rámci eHealth používat jeho AIFO ze Základních registrů tak jako v rámci celého eGovernmentu. Řízení oprávnění přístupu k indexům a zdravotnické dokumentaci uložené v místě vzniku by měla být v rukou pacienta a nastavována prostřednictví Portálu pacienta na principu opt-out. Výchozí nastavení by tedy umožňovalo přístup všem ověřeným zdravotnickým pracovníkům k dokumentaci všech pacientů, která je pro ně relevantní dle matice práv a rolí.

4.3.3.2.2 Detailní návrh řešení Jako identifikátor zdravotnického pracovníka ve smyslu identifikačního kódu, je nutné v rámci eHealth v kontextu Základních registrů používat AIFO. Jako veřejný identifikátor je pak vhodné používat unikátní kód, který bude zdravotnickému pracovníkovi přidělen při jeho zadání do Národního registru zdravotních pracovníků. Není úplně ideální pro tento účel využívat ani číslo občanského průkazu, neboť jde primárně o číslo plastikové kartičky. Zdravotnický pracovník tak může činit v průběhu času úkony nejprve pod jedním číslem průkazu a pak po skončení jeho platnosti a vydání nového by používal číslo jiné, což není žádoucí. Aktuálně neexistuje žádný oficiální standard v rámci EU pro identifikátor zdravotnického pracovníka ve smyslu identifikačního dokladu. Není účelné celonárodně vydávat speciálně pro zdravotníky plastové karty s čipem, na kterém by byla rigidní datová struktura pro uložení dat, protože by se musela pravděpodobně brzy měnit a tato změna by byla velmi nákladná. Není ani účelné vydávat zdravotníkům specializované čipové karty se standardizovaným prostorem na umístění digitálního certifikátu, protože legislativně podložený identifikační doklad s čipem pro uložení certifikátu už existuje v podobě „elektronického občanského průkazu s čipem“. Tento způsob je v souladu s koncepcí eGovernmentu a je univerzální pro všechny občany ČR. V propojení se Základní registry tak pak možné všechny údaje, které nejsou uvedeny na plastikové kartě (například členství v České lékařské komoře či oprávněnost poskytovat zdravotní péči jménem určitého poskytovatele) snadno získat v aktuálně platné podobě online dotazem do Základních registrů. Není vhodné nyní zavádět specifický národní průkaz zdravotnického profesionála ani z důvodu nejasností okolo dalšího postup EU v této otázce. Evropský projekt HPRO (http://www.hprocard.eu) navrhnul podobu standardního evropského průkazu zdravotnického profesionála již v roce 2009 a dosud nebylo přijato žádné oficiální směrodatné stanovisko v tomto ohledu.

104 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ V rámci ČR je dlouhodobě diskutována otázka potřeby elektronického podpisu zdravotnického pracovníka pro potřeby plně elektronické zdravotnické dokumentace. Jako alternativa je obvykle uváděna možnost autentizace záznamu v elektronické zdravotnické dokumentaci pomocí přihlašovacího jména a hesla ke klinickému informačnímu systému, který tuto dokumentaci ukládá. Níže jsou proto shrnuty výhody a nevýhody obou přístupů ve srovnání s běžným podpisem na papíře:

Technická složitost

Nepopiratelnost autorství

Finanční náročnost

Bezpečnost

Elektronický podpis založený na kvalifikovaném certifikátu od akreditovaného poskytovatele certifikačních služeb Vysoká (vede často k nekorektní implementaci na straně klinického IS, která někdy i porušuje zákon) Vysoká (z právního i technologického hlediska jde při dodržení legislativních pravidel o skutečně nepopiratelný projev vůle) Vysoká (je nutné zaplatit nejen služby certifikační autority ale při korektní implementaci i karty a čtečky s PIN klávesnicí)

Vysoká (při korektní implementaci je vytvoření podpisu chráněno PINem a je vyžadována čipová karta či token a navíc se zvyšuje i obecné zabezpečení přístupu k dokumentaci při využití čipových karet pro přihlášení)

Přihlašovací jméno a heslo ověřované vůči interní databázi uživatelských účtů Nízká (koncept uživatelského jména a hesla je široce rozšířen od počátků výpočetní techniky) Nízká (přímým zásahem do databáze lze vždy provést libovolnou změnu) Nízká (zahrnuta v každém stávajícím KIS)

Nízká (hesla jsou často sdílena mezi více uživateli)

Běžný ruční podpis na papírové dokumentaci Nízká (běžně používáno ve všech oblastech lidské činnosti) Střední (grafologické postupy mají omezenou spolehlivost, nicméně případy rozporování podpisu jsou výjimečné) Vysoká (pro možnost ručního podpisu je nutné zajistit tisk dokumentu včetně tiskáren a spotřebního materiálu a následně řešit odpovídajícím způsobem archivaci a manuální skartaci) Nízká (ve zdravotnictví je běžně podpis lékaře realizován jeho sestrou)

Obrázek 19 Srovnání různých způsobů autentizace záznamu ve zdravotnické dokumentaci zdravotnickým pracovníkem

Ze srovnání tedy vyplývá, že přestože je prostá autentizace záznamu pomocí jména a hesla prosazována z důvodů technické jednoduchosti a finanční náročnosti, koncepčně je z dlouhodobého hlediska nutné přejít na elektronický podpis založený na kvalifikovaném certifikátu od akreditovaného poskytovatele certifikačních služeb. Pro korektní implementaci dodržující legislativní pravidla (možnost udržení kontroly držitele certifikátu nad privátním klíčem) je však nutné vybudovat pro tento účel infrastrukturu zahrnující čtečky čipových karet s PINovou klávesnicí. Pro vlastní uložení digitálního certifikátu se nabízí z výše uvedených důvodů využití „elektronického občanského průkazu s čipem“, nicméně tato možnost má řadu socio-technických rizik, které je nutné prověřit samostatnou studií. Tato studie by měla zahrnovat jak technické faktory (například trvanlivost plastu občanského průkazu pro intenzivní používání) tak i sociální faktory (akceptaci takovéhoto způsobu využití občanského průkazu zdravotníky). V případě, že by se elektronické záznamy pro zdravotní dokumentaci před uložením předávaly do nějakého úložiště důvěryhodné třetí strany, která by je mohla označovat elektronickou značkou obdobnou elektronickému podpisu, je možné uvažovat o náhradě digitálních certifikátů určitým druhem uživatelského jména a hesla k tomuto úložišti důvěryhodné třetí strany. To je případ například Centrálního úložiště elektronických receptů, kde je legislativou vyžadováno, aby byl recept okamžitě po předepsání uložen do Centrálního úložiště elektronických receptů, které může vracet zpět serverem elektronicky podepsanou (verifikovanou) kopii eReceptu k uložení do zdravotnické dokumentace poskytovatele zdravotních služeb. V tomto případě, kdy je účelné uložení uživatelského jména a hesla zdravotníka pro přístup k Centrálnímu úložišti do uživatelského účtu v rámci informačního systému poskytovatele zdravotních služeb, není vhodné využívat pro online autentizaci přímo číslo občanského průkazu a BOK. Tuto situaci je vhodné řešit možností generování speciálního přístupového jména a hesla na Portálu zdravotnického pracovníka po přihlášení zdravotníka k portálu pomocí jeho číslo občanského průkazu a BOK. Rovnocennou

105 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ možností je předávání těchto přístupových údajů do datové schránky zdravotnického pracovníka po jejich vyžádání (obdobně jako je tomu například při vyžádání výpisu ze Základních registrů). Návrh je založen na řízení oprávnění pro přístup k indexům míst uložení zdravotnické dokumentace a zdravotnické dokumentaci uložené v místě vzniku samotným pacientem. Výchozí nastavení by mělo odpovídat principu opt-out, a umožňovalo by tedy přístup všem ověřeným zdravotnickým pracovníkům k dokumentaci všech pacientů, která je pro ně relevantní dle výchozí matice práv a rolí. Tento princip odpovídá i zkušenostem z jiných projektů (například IZIP), kde pacienti ve zhruba dvou třetinách případů nastavují tento stupeň důvěry s volným přístupem pro všechny autentizované zdravotnické profesionály. Pacient by však měl možnost pomocí srozumitelného rozhraní nastavit jiné schéma oprávnění. Primárně by nicméně bylo dáno systémem omezení pro přístup ke sdílení dokumentace dle profese lékaře, stomatologa či farmaceuta, které by bylo následující:   

Lékař – bez ohledu na odbornost přístup k veškeré sdílené dokumentaci Stomatolog – přístup pouze k dokumentaci od poskytovatelů v oboru stomatologie Farmaceut – přístup pouze k lékové historii v Centrálním úložišti SÚKLu

Odděleně od běžných nastavení přístupu bude mít dispečink a lékař záchranné služby vždy přístup k emergentnímu datasetu a tento přístup nebude mít možnost pacient omezit svým nastavením. V budoucnu by v souladu se změnami kompetencí sester mohl být umožněn přístup i sestrám či jiným nelékařským pracovníkům do relevantních částí sdílené dokumentace. To by nicméně vyžadovalo primární existenci ošetřovatelské zdravotnické dokumentace v elektronické formě. Schéma nastavení matice oprávnění by mělo zahrnovat nastavení pro různé skupiny zdravotnických pracovníků:   

 

všechny zdravotnické pracovníky v zahraničí (při sdílení dokumentace v rámci projektu epSOS či jeho pokračování) všechny lékaře, stomatology a farmaceuty v rámci ČR všechny lékaře, stomatology a farmaceuty u registrujícího poskytovatele: o registrující praktický lékař o registrující gynekolog o registrující stomatolog všechny lékaře, stomatology a farmaceuty a u vybraných poskytovatelů vybrané lékaře, stomatology a farmaceuty

Informace o vazbě mezi konkrétním zdravotnickým pracovníkem a poskytovatelem zdravotních služeb bude přebírána z Národního registru zdravotnických pracovníků a Národního registru poskytovatelů zdravotních služeb, které by měly tuto vazbu již nyní dle stávající legislativy obsahovat. Úrovně zabezpečení by měly být tyto:   

Povolen přístup pro přihlášeného zdravotnické pracovníka bez dalšího omezení Povolen přístup pro přihlášeného zdravotnického pracovníka na základě zadání hesla zvoleného pacientem na klávesnici u poskytovatele Nepovolen žádaný přístup, ani pro přihlášeného zdravotnického pracovníka

Tímto způsobem by měl pacient možnost nastavit si prakticky libovolné schéma oprávnění pro přístup ke své dokumentaci. Pro zjednodušení by nicméně musely být na výběr předdefinovaná schémata pro nejčastější použití – například „Pro praktického lékaře volný přístup a pro všechny ostatní pouze po zadání mého hesla“.

4.3.3.2.3 Indikativní rozpočet realizace Tento návrh počítá s centrálním financováním infrastruktury čteček a čipových karet státem. Ceny certifikátů jsou odvozeny z aktuální tržní nabídky – nelze očekávat, že při budování sítě registračních míst interní certifikační autority by vydávání kvalifikovaných certifikátů bylo výrazně levnější (bez ohledu na akreditaci interní certifikační autority dle zákona č. 227/2000 Sb., o elektronickém podpisu).

106 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Položka Vybavení čipovými kartami pro cca 40.000 lékařů

Vybavení čipovými kartami pro cca 7.500 stomatologů Vybavení čipovými kartami pro cca 7.000 farmaceutů Čtečky čipových karet s PINovou klávesnicí pro cca 47.500 míst (kalkulováno jako 1:1 dle počtu lékařů a zubních lékařů) Informační podpora pro držitele karet

Celkem Digitální certifikáty pro 47.500 osob na jeden rok

Předpokládaná cena 5– 20 mil. Kč. (horní hranice dle ceny 500 Kč/karta odvozenou od ceny čipu pro občanský průkaz, dolní hranice dle reálné ceny samotné čipové karty s potiskem a middleware pro elektronický podpis cca 5 EUR) 1 – 4 mil. Kč. Není potřeba – klinické výkony jsou navázány na záznam do Centrálního úložiště SÚKLu (jinak 1. – 4. mil Kč). V rámci nelékárenských zdravotnických zařízení pracuje minimum klinických farmaceutů. 47,5 mil. Kč. (cena odhadována ve výši 1000 Kč/čtečka) Mělo by být zajištěno certifikační autoritou v rámci jejích služeb a dále pomocí služeb Portálu v jeho části pro zdravotnické pracovníky. 58,5 – 87,5 mil. Kč. bez DPH 5 – 16 mil. Kč. ročně (horní hranice dle nejnižší veřejné nabídky 330 Kč, dolní hranice dle reálné ceny při velkoodběru či využití vlastní autority cca 100 Kč)

4.3.3.2.3.1 Návrh harmonogramu v časové ose Harmonogram počítá s využití služeb existující certifikační autority a její sítě registračních míst v ČR. V případě budování vlastní certifikační autority či registračních míst by se harmonogram musel odpovídajícím způsobem prodloužit. Priorita

Fáze implementace, činnost

Klíčový milník, aktivita

1

Rozhodnutí

2

Studie proveditelnosti

3

Příprava

4

Distribuce čteček

5

Distribuce čipových karet

6

Vydávání digitálních certifikátů

Rozhodnutí o využití digitálních certifikátů pro autentizaci zdravotnických pracovníků Provedení studie pro ověření socio-technických aspektů Příprava technické specifikace a provedení výběrových řízení Dokončení distribuce čteček čipových karet Dokončení distribuce čipových karet Dokončení prvotní distribuce digitálních certifikátů

Časové vymezení v měsících T

T+6 T + 12 T + 13 T + 14 T + 15

4.3.3.2.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:      

Rozhodnutí o využití digitálních certifikátů pro autentizaci zdravotnických pracovníků Provedení studie pro ověření socio-technických aspektů Příprava technické specifikace a provedení výběrových řízení Dokončení distribuce čteček čipových karet Dokončení distribuce čipových karet Dokončení prvotní distribuce digitálních certifikátů

4.3.3.2.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:

107 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“      

4.3.4

Rozhodnutí Studie proveditelnosti Příprava Distribuce čteček Distribuce čipových karet Vydávání digitálních certifikátů

Výměna elektronické zdravotnické dokumentace pacienta

4.3.4.1 Shrnutí navrhovaného řešení Tento návrh je založen na realizaci služeb eHealth pomocí sdílení zdravotnické dokumentace, uložené v místě vzniku. Jako nezbytné indexy, obsahující konsolidovaný seznam lokalit umístění zdravotnické dokumentace jsou použity informační systémy zdravotních pojišťoven. Tento přístup je doporučen z důvodu jeho hospodárnosti a bezpečnosti osobních údajů, protože nevzniká žádná nová celonárodní databáze s osobními údaji. Navíc systém začne být funkčním prakticky okamžitě po jeho zprovoznění, protože již bude naplněn daty. Vedlejším efektem je pak nutnost přechodu vykazování poskytnutých služeb mezi poskytovateli a zdravotními pojišťovnami na online režim. Zdravotnický pracovník bude moci pro nahlížení na sdílenou dokumentaci využívat buď rozhraní Portálu anebo přímo svého vlastního klinického IS, pokud jeho výrobce implementuje toto nahlížení do sdílené dokumentace. Rozhraní použité pro sdílení dokumentace mezi poskytovateli zdravotních služeb by dále mělo být použito pro možnost nahlížení pacienta do zdravotnické dokumentace dle pravidel stanovených zákonem č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování. Pacient by měl možnost nahlížet na dokumentaci prostřednictvím Portálu. Je dále navrženo racionální sloučení rozhraní pro národní a přeshraniční sdílení informací tak, aby nebylo nutné udržovat paralelně dvě rozdílná rozhraní. Tato nově budovaná rozhraní by měla být založena na mezinárodních standardech typu HL7 a IHE. Lze očekávat, že rozhraní pro přeshraniční sdílení (pilotně ověřované v rámci projektu epSOS) bude podmnožinou rozhraní pro národní sdílení, které bude obsahovat více služeb a funkcí. Pro vlastní sdílení je tento návrh počítá se začleněním a rozvojem existujících komunikačních nástrojů. V rámci výměny obrazové dokumentace jsou to zavedené systémy ePACS a ReDiMed. Dokumentace vytvořená skenováním je považována v tomto kontextu za obrazovou dokumentaci, přestože její primární úložiště v ČR nebývá v PACS a bude sdílena v rámci dokumentace poskytované z klinického informačního systému (NIS). V rovině zprostředkování komunikace pro přeshraniční sdílení je to EESSI Access Point Centra mezistátních úhrad. V rovině autentizace zdravotnických pracovníků, pro zdravotnickou dokumentaci vedenou ve výhradně elektronické formě, počítá tento návrh s řešením založeném na elektronickém podpisu dle zákona č. 227/2000 Sb., o elektronickém podpisu. K zajištění právní jistoty data času vzniku záznamu ve zdravotnické dokumentaci je navrženo využití časového razítka dle téhož zákona. Dlouhodobým cílem by měla být sémantická interoperabilita sdílené zdravotnické dokumentace na národní i přeshraniční úrovni. Za tímto účelem je doporučena adopce nomenklatury SNOMED CT a technického standardu openEHR.

4.3.4.2 Detailní návrh řešení Tento návrh vychází z potřeby intenzivního zapojení zdravotních pojišťoven do vlastního eHealth. Tyto instituce disponují ohromným objemem prakticky využitelných dat, jejichž potřeba shromažďování je z nezpochybnitelná. Informační systémy zdravotních pojišťoven proto staví do pozice indexů, obsahujících informaci o tom, kde byly pacientovi poskytnuty zdravotní služby a tedy zároveň i informaci o tom na kterém místě se nachází jeho zdravotnická dokumentace uložená v místě vzniku. Pro vlastní sdílení je tedy navržen následující postup, ve kterém je informační systém požadující sdílenou zdravotnickou dokumentaci označen jako „Žádající IS“ a systém obsahující zdravotnickou dokumentaci, uloženou v místě vzniku je označen jako „Poskytující IS“:

108 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“       

  

   



Žádající IS získá z Centrálního registru pojištěnců informaci o historickém průběhu pojištění dané osoby. Žádající IS předá aktuální i předchozím zdravotním pojišťovnám požadavek na předání Souhrn informací o pacientovi vytvořený z dat výkazů i poskytnutých zdravotních službách IS zdravotních pojišťoven ověří autentičnost a oprávněnost požadavku Žádajícího IS od daného zdravotnického pracovníka dle matice nastavené pacientem na Portále IS zdravotních pojišťoven vytvoří odpověď na požadavek na Souhrn informací o pacientovi k předání žádajícímu IS a zaevidují tento přístup do svého auditního záznamu Zdravotnický pracovník rozhodne o potřebě získání dalších dat nebo dostatečnosti informací v rámci získaného souhrnu – v takovém případě se postup ukončí Zdravotnický pracovník zvolí v seznamu historicky poskytnuté péče případ, ke kterému by chtěl získat obsah sdílené zdravotnické dokumentace Žádající IS získá z Národního registru poskytovatelů zdravotních služeb technické informace (IP adresy a podobně) nezbytné pro kontaktování serverů Poskytujícího IS, udržujících požadovanou zdravotnickou a obrazovou dokumentaci Žádající IS přímo kontaktuje Poskytující IS a předá mu data požadavku pro předání zdravotnické dokumentace ve stanoveném technickém formátu Poskytující IS ověří autentičnost a oprávněnost požadavku Žádajícího IS od daného zdravotnického pracovníka dle matice nastavené pacientem na Portále Poskytující IS vytvoří odpověď na požadavek od Žádajícího IS ve stanoveném technickém formátu, obsahující požadovanou zdravotnickou dokumentaci a seznam položek dostupné obrazové dokumentace a zaeviduje tento přístup do svého auditního záznamu Zdravotnický pracovník rozhodne o potřebě získání obrazové dokumentace nebo dostatečnosti informací v rámci získané zdravotnické dokumentace – v takovém případě se postup ukončí Zdravotnický pracovník zvolí v seznamu dostupné obrazové dokumentace studii, ke které by chtěl získat obsah obrazové dokumentace Žádající IS přímo kontaktuje Poskytující IS a předá mu data požadavku pro předání obrazové dokumentace ve stanoveném technickém formátu Poskytující IS ověří autentičnost a oprávněnost požadavku Žádajícího IS od daného zdravotnického pracovníka dle matice nastavené pacientem na Portále a zaeviduje tento přístup do svého auditního záznamu Poskytující IS vytvoří odpověď na požadavek od Žádajícího IS obsahující požadovanou obrazovou dokumentaci ve stanoveném technickém formátu

V případě nedoručitelnosti požadavku Poskytujícímu IS by mělo být možné změnit způsob komunikace na offline, tedy například uložit požadavek na sdílenou dokumentaci do datové schránky poskytovatele. Poskytující IS by pak odpověď obsahující požadovanou dokumentaci rovněž předal do datové schránky poskytovatele požadujícího sdílenou dokumentaci. Nepojištěné osoby mají možnost si dobrovolně zvolit pro potřeby sdílení zdravotnické dokumentace „výpomocnou zdravotní pojišťovnu“ obdobným postupem jako je tomu u v případě proplácení zdravotní péče pro cizince – pojištěnce v jiném členském státě EU. Tato pojišťovna je pak u dané osoby vedena v Centrálním registru pojištěnců a udržuje index zdravotnické dokumentace této osoby. Této zdravotní pojišťovně jsou pak zasílány „výkazy“ péče poskytnuté poskytovatelem, které nicméně nejsou propláceny, ale pouze ukládány pro potřeby sdílení. Tento postup bude vyžadovat přechod způsobu vykazování zdravotní péče mezi poskytovatele zdravotních služeb a zdravotní pojišťovnou na „online“ režim ze stávajícího dávkového režimu. Výkazy tedy by již neměli být předávány jen jednou měsíčně (či jednou za 14 dní ve specifických případech) ale kontinuálně do určité doby po uzavření případu (ukončení hospitalizace či ambulantní návštěvy). Tato změna je sice vynucena koncepcí návrhu, avšak má pozitivní přínos z více hledisek. Měsíční předávání dávek bylo zavedeno v 90tých letech minulého století, kdy nebyl internet běžnou formou komunikace, a bylo nutné posílat diskety se soubory poštou. V dnešní době je již tento systém obsoletní a reálně není technický ani metodický důvod proč na něm trvat. Měsíční předávání výkazů přináší problémy i samotným zdravotním pojišťovnám, které jednak nemají plně online přehled o poskytnuté péči a za druhé díky nemožnosti průběžného zpracování je pak nutné mít dostatečný hardware pro rychlé zpracování dat ve

109 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ špičkách (první dny každého měsíce). Při kontinuálním zpracování dat by tyto problémy odpadly, přestože vlastní účtování a fakturace by zůstala zachováno v měsíčním režimu. Při této příležitosti by bylo možné přejít na modernější technický formát výkazů ze strukturovaných textových souborů například na XML. Pro emergentní dataset by měly být relevantní informace dostupné již v rámci Souhrnu informací o pacientovi, vytvářeného z výkazů poskytnuté péče pro zdravotní pojišťovnu. Pro případy samostatných ambulancí, jejichž informační systém není v provozu non-stop, počítá tento návrh s vytvořením online úložiště, v němž bude zdravotnická dokumentace dostupná non-stop. Centrálně by měla být vytvořena tzv. referenční implementace takovéhoto úložiště, která bude volně dostupná ve formě zdrojového kódu a bude mít následující části:   

Rozhraní pro sdílení dle stanovených technických standardů (navrženo HL7 a IHE) Modul pro ověření přístupu dle matice oprávnění uložené na Portále a evidenci přístupů dle legislativních pravidel Úložiště zdravotnické dokumentace s rozhraním pro ukládání zdravotnické dokumentace

Tato referenční implementace bude mít za účel sloužit zejména jako demonstrace „best practice“ pro úpravy stávajících klinických IS k doplnění možnosti sdílení zdravotnické dokumentace. Vývojáři stávajících IS použijí pouze první výše uvedené dvě komponenty referenční implementace, které budou plnit funkci elektronického převodního můstku, který převede relevantní informace z klinického informačního systému do definované struktury dle stanoveného standardu. Tato referenční implementace však bude i samostatně funkční a bude moci po instalaci na odpovídající HW být provozována prakticky libovolným subjektem, který pak může nabídnout služby tohoto úložiště na běžném komerčním principu. Těmito subjekty mohou být kraje, krajské nemocnice, stávající výrobci ambulantních SW, sdružení poskytovatelů ambulantních služeb a podobně. Tyto subjekty pak při instalaci využijí všechny části referenční implementace a do IS poskytovatelů ambulantních služeb bude nutné doplnit pouze předávání dokumentace do tohoto úložiště. Je nutné se na takovéto úložiště dokumentace dívat primárně jako na online zálohu zdravotnické dokumentace, která prakticky eliminuje riziko ztráty dat zdravotnické dokumentace při poruše PC v ordinaci. Možnost online sdílení elektronické zdravotnické dokumentace je v zásadě vedlejším efektem. Tento návrh nepočítá s provozem instance referenční implementace v rámci centrálních orgánů, i když by její využití mělo být pro poskytovatele zdravotních služeb dobrovolné. Tento fakt by totiž mohl být zneužit zájmovými skupinami pro tvrzení, že v rámci eHealth budou centrálně shromažďovány nové osobní údaje, což není záměrem tohoto návrhu. Tento návrh nepočítá s vytvořením samostatného systému, který by sloužil jako proxy k informačním systémům zdravotních pojišťoven či poskytovatelů zdravotních služeb na úrovni národního sdílení zdravotnické dokumentace (pro mezinárodní sdílení je nicméně do takováto proxy navrhována – viz níže). Přestože včlenění proxy komponenty do systému sdílení má své výhody, má i podstatné nevýhody. Zejména vytváří další centrální místo, ve kterém může dojít k chybě a tak k zastavení celého systému. Dalším problémem je že ačkoliv by se zde předávaná data neměla ukládat, představovala by proxy i bezpečnostní riziko, protože procházející data by bylo možné zde odchytnout. V neposlední řadě je navrhovaný systém bez této komponenty podstatně levnější, protože není nutné investovat do jejího vytvoření a provozu. Vzhledem k absenci centrální proxy by měla být vytvořena obdobná referenční implementace jako pro poskytovatele zdravotních služeb i pro systémy zdravotních pojišťoven. Tato referenční implementace by měla být opět volně dostupná ve formě zdrojového kódu a měla by mít následující části:  

Rozhraní pro poskytování dat dle stanovených technických standardů (navrženo HL7 a IHE) Modul pro ověření přístupu dle matice oprávnění uložené na Portále a evidenci přístupů dle legislativních pravidel

U této referenční implementace pro informační systém zdravotních pojišťoven se na rozdíl od referenční implementace pro poskytovatele zdravotních služeb nepředpokládá její samostatná funkce, ale očekává se její začlenění do B2B služeb dané zdravotní pojišťovny.

110 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Vzhledem k decentralizované podobě navrženého systému sdílení zdravotnické dokumentace je naprosto klíčová přesná definice rozhraní a workflow pro sdílení zdravotnické dokumentace. Zde je možné vycházet z již existujících mezinárodně akceptovaných standardů HL7 a IHE. Tyto standardy se používají také v rámci projektu epSOS, který pilotuje přeshraniční sdílení zdravotnické dokumentace. Vzhledem k tomu, že systém epSOS je zaměřen na výměnu Souhrnů informací o pacientech a ePreskripci, je možné tyto rozhraní používat i v rámci národního sdílení a doplnit je dalšími službami specifickými pro národní sdílení zdravotnické dokumentace, jako je výměna obrazové dokumentace či výměna obsahů zdravotnické dokumentace uložené v místě vzniku. Pro výměnu multimediálních informací z PACS by měly být doplněny stávající systémy sdílení ePACS a ReDiMed rozhraními odpovídajícími mezinárodním standardům (například HL7 a IHE). Sdílení této dokumentace může nicméně dle volby konkrétního poskytovatele zdravotních služeb probíhat také přes rozhraní exponované jeho NIS, které bude poskytovat stejné služby ve stejném technickém formátu. Dokumentace vytvořená skenováním je považována v tomto kontextu za obrazovou dokumentaci, přestože její primární úložiště v ČR nebývá v PACS a bude sdílena v rámci dokumentace poskytované z klinického informačního systému (NIS). Dlouhodobým cílem by měla být sémantická interoperabilita sdílené zdravotnické dokumentace na národní i přeshraniční úrovni. Za tímto účelem je doporučena adopce nomenklatury SNOMED CT a technického standardu openEHR. Podrobné zdůvodnění využití standardů HL7, IHE, DICOM, openEHR a SNOMED CT je popsáno v rámci bodu 2.3 Zhodnocení základních principů SNOMED, IHE, HL7, DASTA a ostatních standardů a nomenklatur a jejich využitelnosti v podmínkách České republiky. Zabezpečení by mělo být řešeno formou federace identity a Single-Sign-On. Pro tyto účely je vhodné využít běžné technologické postupy, využívající standardní formát SAML. Tento způsob je již zcela běžný i v rámci IS vzdělávacích a výzkumných institucí, jako je například Univerzita Karlova v Praze či jiné vysoké školy. Poskytovatelem identity v rámci tohoto konceptu by měl být Registr zdravotnických pracovníků a Registr zdravotnických zařízení s možností federace této identity. Tyto registry by měly udržovat sady přístupových údajů, číselných identifikátorů a vazeb na digitální certifikáty. Poskytující IS i informační systém zdravotní pojišťovny bude také muset evidovat všechny přístupy ke sdíleným informacím (indexu i obsahu zdravotnické dokumentace), což ostatně odpovídá i pravidlům stanoveným zákonem č. 101/2000 Sb., o ochraně osobních údajů. Pro garanci časového rozměru provedení záznamu by mělo používat kvalifikované časové razítko. Zdůvodnění tohoto požadavku je obsaženo v bodě 4.3.3 Systémy identifikace. Zajištění služeb certifikační autority pro výdej kvalifikovaných časových razítek by mělo být realizováno formou provozu interní resortní certifikační autority, jejíž služby by byly poskytovatelům pro účely vedení zdravotnické dokumentace dostupné zdarma. Předávaná zdravotnická dokumentace by měla být dále opatřena elektronickou značkou (podpisem) Poskytujícího IS, dle zákona č. 227/2000 Sb., o elektronickém podpisu, který je nezbytný pro zajištění reálné právní průkaznosti původu dokumentace. Pro vlastní realizaci technické stránky projektu epSOS a systému přeshraničního sdílení, který bude pravděpodobně navazovat na projekt epSOS je navrženo využití systému EESSI Access Point, který dnes provozuje Centrum mezistátních úhrad (AP CMÚ) a v budoucnu by mohl být provozován v rámci Úřadu pro dohled nad zdravotním pojištěním. V rámci evropské sítě pro výměnu informací o sociálním pojištění (EESSI) jsou přes tento Access Point předávány zabezpečeným způsobem informace mezi informačními systémy zdravotních pojišťoven v rámci ČR a kompetentními institucemi v rámci jiných členských států EU. K tomuto předávání se v síti EESSI využívá systém tzv. Access Pointů, přičemž každý stát musí mít aspoň jeden, který slouží jako národní brána do této sítě. Obdobný princip využívá síť epSOS, která však národní bránu nazývá Národním kontaktním místem (National Contact Point – NCP). Aktuální procesy EESSI, zaměřené na vyúčtování poskytované péče, již dnes pracují s řadou údajů, které by měly být součástí Souhrnů informací o pacientovi. Pro technickou realizaci epSOS v rámci AP CMÚ stačí tedy realizovat následující kroky:   

Doplnit rozhraní existující mezi IS zdravotních pojišťoven a AP CMÚ o několik dalších údajů, nutných pro sestavení Souhrnu informací o pacientovi Vytvořit rozhraní mezi AP CMÚ a Centrálním úložištěm elektronické preskripce na SÚKL Doplnit AP CMÚ o rozhraní pro sdílení Pacientských souhrnů a ePreskripce na základě HL7 a IHE

111 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Pro technickou realizaci epSOS tímto způsobem mluví i fakt, že lze v případě institucionalizace projektu epSOS v oficiální struktuře orgánů EU očekávat začlenění procesů přeshraničního sdílení zdravotnické dokumentace do stávající sítě EESSI, používané v rámci zdravotně-sociální problematiky. K rozvoji služeb EESSI určených pro poskytovatele zdravotnické dokumentace ostatně směřuje i projekt NewS4EESSI realizovaný v ČR sdružením Medtel o.p.s.

4.3.4.3 Indikativní rozpočet realizace Položka Definice standardů pro rozhraní pro sdílení zdravotnické dokumentace na národní úrovni Implementace VPN koncentrátoru Vytvoření referenční implementace pro poskytovatele zdravotních služeb a zdravotní pojišťovny Začlenění referenční implementace do informačních systémů poskytovatelů zdravotních služeb Začlenění referenční implementace do informačních systémů zdravotních pojišťoven a přechod na „online“ systém předávání výkazů o poskytnuté péči Realizace interní resortní certifikační autority vydávající kvalifikovaná časová razítka Úpravy AP CMÚ pro realizaci NCP v rámci epSOS Úprava ePACS a ReDiMed pro začlenění referenční implementace pro poskytovatele zdravotních služeb Realizace poskytovatele identity založeného na Národním registru zdravotnických pracovníků a Národním registru poskytovatelů Celkem Roční provoz systému pro výměnu elektronické zdravotnické dokumentace pacienta

Předpokládaná cena 3 mil. Kč. 2 mil. Kč. 8 mil. Kč. Závisí na způsobu začlenění a není příliš reálné centrální financování této položky 4 mil Kč pro každou pojišťovnu 10 mil Kč. (zahrnuje i akreditaci u Úřadu pro ochranu osobních údajů dle zákona č. 227/2000 Sb., o elektronickém podpisu a odpovídající HW) 5 mil. Kč. 5 mil. Kč. 2 mil. Kč. 39 mil. Kč. bez DPH 8 mil. Kč. bez DPH ročně

4.3.4.3.1 Návrh harmonogramu v časové ose Priorita

Fáze implementace, činnost

Klíčový milník, aktivita

1

Rozhodnutí

2

Příprava

3

Definice rozhraní

4

Realizace VPN

5

Zabezpečení přístupu

6

Zajištění kvalifikovaných časových razítek

7

Realizace přeshraničního sdílení

Rozhodnutí o realizaci systému pro výměnu elektronické zdravotnické dokumentace pacienta Příprava technické a funkční specifikace a provedení výběrových řízení Definice standardů pro rozhraní pro sdílení zdravotnické dokumentace na národní úrovni Implementace VPN koncentrátoru Realizace poskytovatele identity založeného na Národním registru zdravotnických pracovníků a Národním registru poskytovatelů Realizace interní resortní certifikační autority vydávající kvalifikovaná časová razítka Úpravy AP CMÚ pro realizaci NCP v rámci epSOS

Časové vymezení v měsících T

T+2

T+6

T+6 T + 12

T + 12

T + 12

112 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 8

Vytvoření referenční implementace

9

Realizace výměny obrazové dokumentace

10

Využití referenční implementace na straně zdravotních pojišťoven

11

Využití referenční implementace na straně poskytovatelů zdravotních služeb

Vytvoření referenční implementace pro poskytovatele zdravotních služeb a zdravotní pojišťovny Úprava ePACS a ReDiMed pro začlenění referenční implementace pro poskytovatele zdravotních služeb Začlenění referenční implementace do informačních systémů zdravotních pojišťoven a přechod na „online“ systém předávání výkazů o poskytnuté péči Začlenění referenční implementace do informačních systémů poskytovatelů zdravotních služeb

T + 18

T + 18

T + 24

T + 24

4.3.4.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:          



Rozhodnutí o realizaci systému pro výměnu elektronické zdravotnické dokumentace pacienta Příprava technické a funkční specifikace a provedení výběrových řízení Definice standardů pro rozhraní pro sdílení zdravotnické dokumentace na národní úrovni Implementace VPN koncentrátoru Realizace poskytovatele identity založeného na Národním registru zdravotnických pracovníků a Národním registru poskytovatelů Realizace interní resortní certifikační autority vydávající kvalifikovaná časová razítka Úpravy AP CMÚ pro realizaci NCP v rámci epSOS Vytvoření referenční implementace pro poskytovatele zdravotních služeb a zdravotní pojišťovny Úprava ePACS a ReDiMed pro začlenění referenční implementace pro poskytovatele zdravotních služeb Začlenění referenční implementace do informačních systémů zdravotních pojišťoven a přechod na „online“ systém předávání výkazů o poskytnuté péči Začlenění referenční implementace do informačních systémů poskytovatelů zdravotních služeb

4.3.4.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:           

Rozhodnutí Příprava Definice rozhraní Realizace VPN Zabezpečení přístupu Zajištění kvalifikovaných časových razítek Realizace přeshraničního sdílení Vytvoření referenční implementace Realizace výměny obrazové dokumentace Využití referenční implementace na straně zdravotních pojišťoven Využití referenční implementace na straně poskytovatelů zdravotních služeb

113 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3.5

Úprava elektronická preskripce

4.3.5.1 Shrnutí navrhovaného řešení Návrh řešení směřuje k vyšší akceptaci systému elektronické preskripce odbornou veřejností i pacienty. Kromě dřívějších doporučení k úpravě ePreskripce (které se objevily i v rámci podmínek této soutěže o návrh) předpokládá, že data o papírových receptech, nyní sbíraná samostatně a odděleně od Centrálního úložiště elektronických receptů by měla být po odpovídající legislativní úpravě opět přidána do Centrálního úložiště. Tímto způsobem bude možné jednak ušetřit na provozu celkového systému a hlavně bude pak dostupná skutečně kompletní léková historie pacienta i pro léčiva neproplácená pojišťovnou. Obdobně by měla být provedena legislativní úprava pro znovuzavedení povinnosti kontroly počtu vydaných balení v Centrálním úložišti při výdeji OTC s omezením a zprovozněno technické řešení pro tuto kontrolu. Vzhledem k rozsahu změn bude nutná zřejmě kompletní reimplementace aplikační úrovně Centrálního úložiště. Této příležitosti by proto mělo být využito pro rekonstrukci rozhraní Centrálního úložiště s využitím HL7.

4.3.5.2 Detailní návrh řešení Kromě identifikace elektronického receptu pomocí čárového kódu na papírové kopii elektronického receptu by měly mít lékárny možnost i vydat léčivý přípravek pacientovi, který se identifikuje pomocí předloženého EHIC či občanského průkazu. Oprávnění vyhledávat dosud plně nevydané recepty v centrálním úložišti by mělo být odděleno od oprávnění na náhled na plnou lékovou historii pacienta. Oprávnění zdravotničtí pracovníci by měli mít možnost nahlédnout na kompletní lékovou historii pacienta v Centrálním úložišti. Měla by být doplněna také automatická kontrola interakcí a duplicit v okamžiku předepisování elektronického receptu a výdeje na papírový i elektronický recept. Tato kontrola by měla probíhat bez ohledu na oprávnění pro nahlížení do lékové historie. Podrobné informace o matici oprávnění jsou uvedeny v bodě 4.3.3.2 Identifikace zdravotnického pracovníka. Vzhledem k tomu, že Centrální úložiště elektronických receptů musí být v době předepisování i výdeje dostupné předepisujícímu lékaři a vydávajícímu lékárníkovi online, vytrácí se smysl použití elektronického podpisu. Tento způsob autentizace, který navíc v dnešní době lze jen obtížně navázat na odpovídající autorizaci, lze proto nahradit pomocí běžného jména a hesla. Toto jméno a heslo by měl mít zdravotnický pracovník možnost si vygenerovat na Portálu zdravotnického pracovníka nebo si jej nechat poslat do své Datové schránky. Přímé využití hesla k datové schránce není v souladu s koncepcí eGovernmentu, protože má být použito pouze pro „neinteraktivní služby“. Není vhodné využívat ani přímo bezpečnostní osobní kód (BOK) k občanskému průkazu zdravotnického pracovníka, protože je zde velké riziko nekorektní implementace ze strany dodavatelů informačních systémů do zdravotnictví, kteří by pravděpodobně umožňovali velmi rizikové uložení BOK do SW pro předepisování či výdej elektronických receptů, tak jako nyní nezřídka nutí zdravotnické pracovníky nahrát svůj digitální certifikát s privátním klíčem na server, čímž zdravotník ztrácí výhradní kontrolu nad svým privátním klíčem a tím pádem není splněn požadavek zákona č. 227/2000 Sb., o elektronickém podpisu. Pro založení eReceptu či záznamu o výdeji na eRecept do elektronické zdravotnické dokumentace by však bylo nutné, aby Centrální úložiště vracelo také kompletní opis eReceptu či záznamu o výdeji označený elektronickou značkou (podpisem) Centrálního úložiště SÚKLu – v tuto chvíli vrací pouze identifikátor eReceptu či záznamu o výdeji. Centrální úložiště by mělo být více provázáno se systémy eGovernmentu, a to zejména se Základními registry. Jako primární identifikátor pacienta by mělo být v rámci Centrálního úložiště používáno AIFO. Datové schrány lze využít pro doručování výpisů z lékové historie pro pacienta anebo pro doručování přístupových kódů pro zdravotnické pracovníky. Data o papírových receptech, nyní sbíraná samostatně a odděleně od Centrálního úložiště elektronických receptů by měla být po odpovídající legislativní úpravě opět přidána do Centrálního úložiště. Tímto způsobem bude možné jednak ušetřit na provozu celkového systému a hlavně bude pak dostupná skutečně kompletní léková historie pacienta i pro léčiva neproplácená pojišťovnou. Obdobně by měla být provedena legislativní úprava pro znovuzavedení povinnosti kontroly počtu vydaných balení v Centrálním úložišti při výdeji OTC s omezením a zprovozněno technické řešení pro tuto kontrolu. V dnešní době je již možné aby předepisující lékaři přistupovali k centrálnímu úložišti bez routeru určeného SÚKLem, nicméně bylo by vhodné stanovit tuto možnost i pro vydávající lékárny.

114 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Vzhledem k extrémnímu rozsahu změn i logiky zpracování by mělo být zváženo, zdali nezměnit i rozhraní pro komunikaci s Centrálním úložištěm dle standardu HL7 obdobně jako je tomu v zahraničních systémech ePreskripce. Tento postup by dále usnadnil integraci Centrálního úložiště do procesů přeshraničního sdílení dat. Aktuálně nabízí Centrální úložiště dvě technologie pro přístup ke svým službám. První jsou standardní webové služby, které jsou intenzivně využívány a druhé rozhraní tvoří konektor JMS, který v oblasti elektronické preskripce není prakticky využíván. V rámci této změny by mělo být redukováno rozhraní Centrálního úložiště na pouze jednu technologii a tím ušetřit na výsledném provozu systému.

4.3.5.3 Indikativní rozpočet realizace Vzhledem k tomu, že rozsah úprav včetně navržené změny rozhraní na HL7 je takový, že bude znamenat prakticky kompletní reimplementaci aplikační úrovně Centrálního úložiště, je odhadován rozpočet této změny na hodnotu uváděnou SÚKLem jako cenu vynaloženou na aplikační komponentu. Položka Reimplementace aplikační úrovně centrálního úložiště Nákup hardware

Předpokládaná cena 28 mil. Kč. bez DPH

Roční provoz aplikační úrovně centrální ho úložiště

Vzhledem k tomu, že upravené řešení by mělo běžet namísto stávajícího, nebude zřejmě potřeba investovat do nového hardware 2 mil. Kč bez DPH ročně

4.3.5.3.1 Návrh harmonogramu v časové ose Priorita

Fáze implementace, činnost

Klíčový milník, aktivita

1

Rozhodnutí

2

Příprava

3

Implementace úprav na straně SÚKLu

4

Implementace úprav na straně poskytovatelů zdravotních služeb

Rozhodnutí o změnách ePreskripce Příprava technické a funkční specifikace a provedení výběrových řízení Dokončení reimplementace aplikační úrovně elektronické preskripce Dokončení reimplementace nového rozhraní elektronické preskripce

Časové vymezení v měsících T T+2

T+6

T+9

4.3.5.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:    

Rozhodnutí o změnách ePreskripce Příprava technické a funkční specifikace a provedení výběrových řízení Dokončení reimplementace aplikační úrovně elektronické preskripce Dokončení reimplementace nového rozhraní elektronické preskripce

4.3.5.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:    

Rozhodnutí Příprava Implementace úprav na straně SÚKLu Implementace úprav na straně poskytovatelů zdravotních služeb

115 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3.6

Zpracování informací o radiační zátěži pacienta

4.3.6.1 Shrnutí navrhovaného řešení Tento návrh je proto založen na předávání informací o radiační zátěži v případě vykazování radiologických vyšetření či radioterapeutických intervencí do zdravotních pojišťoven jako součásti výkazů pro zdravotní pojišťovny. Registr radiační zátěže by tak byla realizován vlastně v rámci informačních systému jednotlivých zdravotních pojišťoven. Systém vykazování poskytnuté péče tento návrh doporučuje změnit z aktuálního dávkového systému na „online“ systém, kdy by každý případ musel být vykázán zdravotní pojišťovně do určitého časového limitu odvislého od typu vyšetření. Výhodou tohoto postupu je také to, že tím zdravotní pojišťovna získá přehled o radiační zátěži pacienta, kterou lze použít v rámci měření kvality a efektivity poskytované péče. Doplnění nezbytných polí do stávajících výkazů a systémů je nepochybně mnohem hospodárnější než vytvářet samostatný systém pro tuto agendu.

4.3.6.2 Detailní návrh řešení Pro evidenci informací o radiační zátěži není účelné budovat nový informační systém. Takováto nová databáze by jen vzbuzovala zbytečné obavy o ochraně osobních údajů a vůbec o potřebě jejich shromažďování, což by mohlo vést ke zneužití této skutečnosti některou zájmovou skupinou k diskreditaci celého záměru elektronického zdravotnictví. Navíc by takovýto registr obsahoval částečně duplicitní informace s výkazy výkonů v informačních systémech zdravotních pojišťoven a mohly by vznikat problémy v důsledku nesouladu dat v těchto dvou systémech. Rozšíření datového rozhraní pro vykazování poskytnuté zdravotní péče o pole pro evidenci radiační zátěže je z technického hlediska pouze malou změnou a mnohem více se jedná o změny procesní. Tato změna se projeví zejména tam, kde informační systémy neimplementují DICOM službu Modality performed procedure step (MPPS), která předává notifikaci o provedeném vyšetření do NIS a která může obsahovat i informaci o radiační zátěži.

4.3.6.3 Indikativní rozpočet realizace Přidání polí pro evidenci radiační zátěže do Metodiky pro pořizování a předávání dokladů a Datového rozhraní a implementace těchto změn v informačních systémech zdravotní pojišťovny a poskytovatelů péče je považováno vzhledem k požadavku tohoto návrhu na přechod k online předávání výkazů za drobnou změnu a tím pádem jsou její náklady v tomto kontextu zanedbatelné. Náklady na přechod na online předávání výkazů jsou vyčísleny v bodě 4.3.4 Výměna elektronické zdravotnické dokumentace pacienta.

4.3.6.3.1 Návrh harmonogramu v časové ose Priorita

Fáze implementace, činnost

Klíčový milník, aktivita

1

Rozhodnutí

2

Metodické změny

3

Implementace úprav na straně zdravotních pojišťoven

4

Implementace úprav na straně poskytovatelů zdravotních služeb

Rozhodnutí o zajištění zpracování informací o radiační zátěži Provedení změn v metodice a datovém rozhraní Dokončení implementace změn v metodice a datovém rozhraní v systémech zdravotních pojišťoven Dokončení implementace změn v metodice a datovém rozhraní v systémech poskytovatelů zdravotních služeb

Časové vymezení v měsících T

T+1 T+6

T+9

4.3.6.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:   

Rozhodnutí o zajištění zpracování informací o radiační zátěži Provedení změn v metodice a datovém rozhraní Dokončení implementace změn v metodice a datovém rozhraní v systémech zdravotních pojišťoven

116 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“



Dokončení implementace změn v metodice a datovém rozhraní v systémech poskytovatelů zdravotních služeb

4.3.6.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:    

4.3.7

Rozhodnutí Metodické změny Implementace úprav na straně zdravotních pojišťoven Implementace úprav na straně poskytovatelů zdravotních služeb

Manažerský informační systém

4.3.7.1 Shrnutí navrhovaného řešení Požadavek na vytvoření manažerského informačního systému je formulován již v rámci existující zadávací dokumentace k zakázce „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy“, jejímž zadavatelem je KSRZIS a která je součástí tzv. eREG, tedy modernizace resortních registrů. Tento projekt zatím sice není zrealizován, nicméně v rámci projektu KSRZIS požaduje od dodavatele zmapovat veškeré stávající i do budoucna požadované reporty, zajistit potřebnou kvalitu dat pro jejich získání a vytvořit pokud možno automatizované procesy pro jejich generování. V rámci dodávky Jednotné technologické platformy (JTP) pak KSRZIS požaduje vypracovat detailní návrh řešení a dodávku platformy reportingu a vytěžování dat. Návrh a dodávka řešení musí zohledňovat již stávající provozované řešení s možností jeho využitelnosti. Požadavky na reporting v rámci JTP formulované v rámci výše uvedeného projektu odpovídají modernímu pojetí reportingu. Jejich základem je datový sklad, plněný daty z provozních systémů pomocí transformačních mechanismů. Na tento datový sklad pak navazuje analytická a prezentační vrstva, která má být schopná poskytovat informace správcům registrů a odborné i laické veřejnosti. Takto vytvořený manažerský informační systém bude možné použít i pro analýzu dalších dat, které budou shromážděny v rámci národního eHealth, jako jsou například informace o radiační zátěži pacientů. Tento návrh je proto založen na využití reportingu, plánovaného v rámci eREG. V rámci analýzy manažerského informačního systému by měly být zohledněny principy finálního konceptu eHealth. Kromě předpokládaných uživatelů by měl být umožněno využití manažerského informačního systému vybudovaného na národní úrovni i pro potřeby poskytovatelů zdravotních služeb. Jednotliví poskytovatelé by měly mít pomocí tohoto reportingu možnost přístupu ke svým vlastním datům a jejich srovnání s průměrnými daty skupiny obdobných poskytovatelů. Tento princip by měl být obecně aplikován pokud možno na všechny indikátory, které budou v rámci reportingu realizovány. Návrh předpokládá, že reporting v rámci eREG by bylo vhodné využít i pro účely reportingu ze systémů provozovaných v rámci resortu jinými organizacemi – například pro analýzu dat z elektronické preskripce a sběru dat o papírových receptech v rámci SÚKL. Z hlediska obsahu manažerského infomačního systému by měly být kromě aktuálně poskytovaných reportů nalezeny vhodné indikátory pro měření kvality, bezpečnosti a efektivity poskytovaných zdravotních služeb. Při konstrukci těchto indikátorů, které by měly být mezinárodně srovnatelné, je možné vyjít například ze sady OECD Health Data, nebo z jiného obdobného zdroje.

4.3.7.2 Detailní návrh řešení Vytvoření platformy pro vytěžování dat a reporting je jedním z klíčových cílů projektu „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy“. Díky centralizaci datové základny do jednotné technologické vrstvy bude možné současné možnosti vytěžování podstatně rozšířit a získávat relevantní data. V současné době KSRZIS používá Microsoft SQL Server Analysis Services a Microsoft SQL Server Reporting Services. KSRZIS předpokládá, že v

117 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ rámci dodávky JTP bude provedena analýza stávajícího stavu, která zhodnotí využitelnost stávajících technologií a systémů tak, aby byly v maximální možné míře stávající technologie pro JTP využitelné. Architektura reportingu je v rámci výše uvedeného projektu požadována v následujícím členění: 







Vrstva transformačních mechanismů: Datové pumpy načítají ve stanovených intervalech data do vrstvy, kde se ukládají v původní kvalitě. Následně jsou na data aplikovány čistící, validační i kontrolní mechanismy tak, aby byla zajištěna jejich správnost a jednotný formát. Důležitým znakem je jejich univerzálnost na vstupu, kde je možno zpracovávat téměř jakýkoliv formát vstupních strukturovaných dat. V rámci této vrstvy musí být zajištěny následující funkcionality: o Profilace dat - Zahrnuje zkoumání principiálního obsahu jednotlivých datových zdrojů, zjišťování závislostí a překryvů mezi jednotlivými datovými zdroji o Datový audit - Umožňuje definovat i poměrně komplexní kritéria na data v datových zdrojích. Nedodržení těchto kritérií se pak příslušným způsobem reportuje o Datová kvalita - Umožňuje identifikovat duplicitní záznamy odpovídající jedné entitě v rámci jednoho systému či párovat záznamy odpovídající jedné entitě mezi různými systémy o Extrakce dat - Základní prvek datové integrace reprezentující řešení pro extrakci dat ze zdrojových systémů, jejich transformaci a jejich následné ukládání do cílového úložiště. o Správa metadat - Řešení pro správu metadat by mělo umožňovat spravovat:  Terminologii, která se vyskytuje v reportech a analýzách. Správa zahrnuje definici jednotlivých pojmů, jejich závislostí, sledování změn, osoby zodpovědné za jejich správu a celou řadu dalších aspektů. Spravovat metadata – tj. jednotlivé datové zdroje, databáze, tabulky, sloupce, soubory, procesy, atd.  Vazby mezi metadaty a jednotlivými pojmy. Díky tomu je možné výrazně zefektivnit komunikaci mezi koncovými uživateli, kteří jsou „konzumenty“ reportů, které je zodpovědné za technickou realizaci a za dodání podkladových dat pro koncové řešení.  Integraci s integrační platformou Datový sklad: Datové zdroje jsou klíčovým aspektem celého řešení. V rámci předmětu plnění předpokládáme, že datové tržiště budou jednotlivé registry a další podpůrné systémy. o Tržiště Metadat o Tržiště jednotlivých Registrů o Tržiště podpůrných systémů/subsystémů Analytická vrstva: Konsolidovaná data z „nulté“ vrstvy se ukládají do „první“ vrstvy, která je základem pro všechny typy výstupů. Nejčastěji jsou zde data uložena v tzv. multidimenzionálních objektech (či na obdobně fungujícím způsobu ukládání dat), které umožňují rychlou analýzu dat, tvorbu multidimenzionálních dotazů, různé pohledy na data a především rapidní zrychlení jak analytické práce s daty, tak běžné rutinní práce např. s tabulkovým kalkulátorem. Tato vrstva je základem pro „prezentační vrstvu“ a veškeré analytické nástroje v ní obsažené. Analytická vrstva zajišťuje následující funkce: o Před agregovaná data o OLAP Server o Data mining server o Řízení přístupu datům podle předefinovaných rolí o Konsolidace různých datových zdrojů o Integrace s Active Directory Prezentační vrstva a nástroje Business Inteligence: Představuje z hlediska uživatelů nejdůležitější prvek celého řešení a jde o souhrn analytických, reportovacích, vizualizačních a interaktivních nástrojů pro analýzu, vizualizaci a reportování dat. Na výstupu může datový sklad poskytovat data pro další (i provozní) aplikace, kooperující datové sklady či interaktivní webové prezentace dat (včetně dávkového předání dat či webové služby). Předpokládáme, že prezentační vrstva zajistí funkce v následujících oblastech: o Reporting  přístup k reportům přes webové rozhraní (portál)  parametrizace reportů  využití Windows integrované bezpečnosti, kdy uživatel je jednou ověřen Active Directory a reportovaní rozhraní přebírá role uživatele

118 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

o

o

o

o o

 export reportů do různých formátů (xls, pdf, obrázek, text, xml …)  automatická distribuce reportů (například emailem)  musí umožňovat generování reportů z více datových oblastí  pokročilé řízení přístupu uživatelů k reportům i vlastnímu obsahu reportů Multidimenzionální analýza  pokročilá analýza za pomoci klientských nástrojů přístupu (webový portál, speciální aplikace)  integrace s Active Directory  integrace s Microsoft Office  uložení vytvořeného pohledu na data a jeho exportu do dalších formátů Ostatní analýzy  pokročilá analýza za pomoci klientských nástrojů přístupu (webový portál, speciální aplikace)  What-if analýzy  Data mining úlohy (plánování, učení, předpovídání, segmentace, klasifikace, modelování závislostí)  uložení vytvořeného pohledu na data a jeho exportu do dalších formátů Časová analýza  Možnost vytváření časových analýz nad daty na základě uzávěrek pořizovaných dat v daných časových úsecích  Možnost vytváření rozdílových analýz dat pořízených do uzávěrky a po uzávěrce  Možnost vytváření obrazu pořízených v konkrétním čase. Katalog webových služeb datového skladu  Definice a správa webových služeb datového skladu Ostatní  personalizovaný prostor pro konkrétní skupiny uživatelů s různými potřebami

Požadavky na agregovaná data jsou velmi široké, v současné době jsou poskytovány různým stranám stovky různých reportů. V rámci výše uvedeného projektu budou zmapovány veškeré stávající i do budoucna požadované reporty, zajištěna potřebná kvalita dat pro jejich získání a budou vytvořeny pokud možno automatizované procesy pro jejich generování. Konkrétní požadavky na reporty a OLAP kostky budou definovány v analýze. Vzhledem k počtu zájmových stran se jedná o rozsáhlou problematiku. KSRZIS požaduje v rámci dodávky JTP vypracovat detailní návrh řešení a dodávku platformy reportingu a vytěžování dat. Návrh a dodávka řešení musí zohledňovat již stávající provozované řešení s možností jeho využitelnosti. Součástí dodávky JTP v rámci výše uvedeného projektu je i zajištění implementace jednotné technologické platformy s využitím stávajících technologií 602XML Form Server a 602XML formulářového rozhraní. Je požadováno, aby řešení v maximální míře využilo stávající technologickou základnu pro vytěžování dat z elektronických formulářů a zajistilo migraci dat ze stávající technologie na technologii zamýšlenou. Dodaná technologie musí zajistit zavedení procesního serveru, který je schopen zabezpečit:       

sběr dat a jejich export do stávajících systémů organizace jednotný centrálně spravovaný systém elektronických formulářů jednotný centrálně spravovaný systém vlastních uživatelských účtů, včetně jejich oprávnění do úrovně jednotlivých formulářů podepisování a parciální podepisování elektronických formulářů elektronickým podpisem orážení elektronických formulářů elektronickým časovým razítkem automatické ověření platnosti elektronických podpisů a razítka s učiněním záznamu o ověření formou xml metadat podle zákona č. 227/2000 Sb., o elektronickém podpisu v platném znění archivaci elektronických formulářů

Součástí této části projektu je i vytvoření elektronických formulářů, které umožňují vyplňování v režimu offline i online, v režimu offline musí umožňovat průběžné ukládání souboru a odeslání dat až po připojení k síti.

119 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Elektronické formuláře musí být vybaveny kontextovou nápovědou a kontrolou dat již při jejich vyplňování. Kontrolou se rozumí zejména kontrola povinně vyplněných polí, matematické výpočty či kontrola pravopisu. Formuláře musí umět pracovat s dynamickými číselníky. Technologie musí poskytnout možnost převodu do PDF formátu, tisk samostatných prázdných formulářů a tisk vyplněných formulářů na tiskárnu. Reporting v rámci eREG by bylo vhodné zpřístupnit pro využití i jiným organizacím v rámci resortu – například pro analýzu dat z elektronické preskripce a sběru dat o papírových receptech v rámci SÚKL. Tyto informace by tak byly okamžitě dostupné všem uživatelům v rámci Ministerstva zdravotnictví, SÚKLu a případně i veřejnosti.

4.3.7.3 Indikativní rozpočet realizace Realizace manažerského informačního systému je již součástí veřejné zakázky „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy“, jejíž předpokládaná hodnota je dle zadávací dokumentace 99.250.000 Kč,- bez DPH. Není vyloučeno, že cena bude v konečném důsledku nižší.

4.3.7.3.1 Návrh harmonogramu v časové ose KSRZIS předpokládal v zadávací dokumentaci uzavření smlouvy na realizace veřejné zakázky „Vytvoření a implementace základu jednotné technologické platformy včetně identity managementu, platformy pro vytěžování dat a napojení na základní registry veřejné správy.“ k 31. 1. 2012. KSRZIS požadoval, aby plnění bylo ukončeno do 31. 12. 2012 (ukončením milníku Ověřování JTP, nasazení registrů do JTP, migrace provozu registrů). Vzhledem k tomu, že je pravděpodobné že tento termín není reálný, lze očekávat posun termínů o rok, tedy dokončení k 31.12.2013.

4.3.7.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky pro reporting jsou vymezeny v rámci projektu eREG.

4.3.7.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace pro reporting jsou vymezeny v rámci projektu eREG.

4.3.8

Portálová řešení

4.3.8.1 Shrnutí navrhovaného řešení Portálové řešení bude tvořit jednotné grafické uživatelské rozhraní k různým systémům provozovaným v rámci elektronického zdravotnictví. Poskytované informace budou rozděleny dle druhu uživatele a podle toho zdali jde o přihlášeného či nepřihlášeného uživatele. Portál pak může sloužit nejen jako rozcestník a prohlížeč informací shromážděných o pacientech v oblasti eHealth, ale i jako zabezpečený komunikační kanál pro předávání informací mezi pacientem a poskytovatelem zdravotních služeb, například pro využití služeb Telemedicíny. Vybrané služby Portálu by měly být dostupné pro občany na kontaktních místech systému CzechPoint. Součástí projektu portálu by dále mělo být zpracování evropských standardů pro publikaci zdravotnických dokumentů na internetu a zhodnocení jejich aplikovatelnosti české prostředí. Měla by být vytvořena pravidla hodnocení kvality informačních zdrojů z oblasti zdravotnictví na internetu, které by přispěly ke korekci možných nepříznivých dopadů současného stavu.

4.3.8.2 Detailní návrh řešení U portálového řešení v rámci eHealth je předpokládáno využití standardních webových technologií. Informace by měly být dostupné v českém jazyce a případně i dalších jazycích. Obecné informace pro občany by měly být dostupné ve formě srozumitelné pro absolventy základní školy. Informace by měly být dostupné i pro osoby zdravotně postižené dle zásad přístupnosti například podle metodiky Blind Friendly Web i WCAG 1.0 a Pravidel tvorby přístupného webu připravených pro účely novely zákona č. 365/2000 Sb., informačních systémech veřejné správy. Vybrané služby portálu by měly být dostupné i na mobilních zařízeních s využitím specifických vlastností mobilních zařízen. Například může jít o miniaplikaci, která by po vyfocení čárového kódu léčiva vyhledala jeho generické alternativy včetně orientačních cenových údajů.

120 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Řešení bezpečnosti Portálu je podrobně popsáno v bodě 4.3.3 Systémy identifikace. Vzhledem k tomu, že půjde o informační systém veřejné správy poskytující interaktivní služby, bude možné se přihlašovat pomocí bezpečnostního osobního kódu anebo digitálního certifikátu. Po přihlášení by měl být systém schopen se souhlasem uživatele poskytovat jeho identitu dále řízeným způsobem pro další informační zdroje z oblasti státní či neziskové i komerční sféry. Není nezbytně nutné, aby se všechny informační zdroje staly integrovanou součástí Portálu. Například prohledávání databáze léčiv může být řešeno pouhým odkazem na relevantní informační zdroj na stránkách SÚKLu. V případě zdrojů dostupných po přihlášení, by však měl odkazovaný informační zdroj přebírat identity již přihlášeného uživatele portálu a nenutit jej znovu k přihlašování. Například po přihlášení k Portálu s identitou poskytovatele zdravotních služeb by měl být možný proklik na personalizovaná data reportingu Manažerského informačního systému již bez dalšího přihlašování (stejnými či jinými přístupovými údaji). Pro portál je vhodné využití některou existující otevřenou specifikaci, která umožní následně tvorbu vizuálních částí portálu (tzv. portletů) různými dodavateli při dodržení jednotné grafické úpravy. Takovouto specifikací je například Java Portlet Specfication (JSR 168). Vlastní Portál by se pak měl skládat z redakčního systému, prostředí pro běh jednotlivých portletů a vlastních portletů. Portál by měl obsahovat následující informace a aplikace: 

Obecná část pro pacienty - veřejná o Informace o systému zdravotních služeb o Informace o léčivech a zdravotnických prostředcích včetně možností generické substituce a cenových aspektů. Cenových podklady mohou vycházet z:  Sběru dat prováděných SÚKL od lékáren (aktuálně neprováděno z důvodu rizika velkého odporu poskytovatelů lékárenských služeb)  Sběr dat prováděných SÚKLem od distributorů (lze získat pouze přibližné cenové údaje, které by však pro tento účel mohly být postačující)  Sběr dat prováděný jinými subjekty od lékáren (jsou dostupná na komerčním principu) o Dostupnost služeb  legislativní kritéria dostupnosti  vyhledání poskytovatele dle kritérií pro smlouvu s určitou zdravotní pojišťovnou a místní a časové dostupnosti pro konkrétní výkon o Databáze standardních textů informovaných souhlasů s konkrétními úkony o Systém pojišťoven a jejich programy  co je standardní a co nadstandardní péče v jejich programech  příklady nákladů pojišťoven na léčbu různých diagnóz o Bezpečnost a kvalita služeb  Jak může pacient přispět k bezpečnějšímu zdravotnictví  Interní hodnocení kvality  Externí hodnocení kvality  Bezpečnost léčiv o Informace o průzkumech spokojenosti pacientů o Financování zdravotní péče (způsob úhrady: hrazená z veřejného z pojištění, nehrazená z veřejného zdravotního pojištění, doplatky) o Práva a povinnosti pacientů o Informace o možnosti podání stížnosti na zdravotní personál nebo na poskytovatele zdravotních služeb a jejích procesování na základě zákona o Veřejné zdraví  systém ochrany veřejného zdraví v ČR  podpora a ochrana zdraví  očkování, péče o pracující, zdravý životní styl  prevence chorob o Specifické oblasti

121 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“







 péče o matku a dítě  péče o seniory o Cestování a zdravotní péče v zahraničí o Principy sdílení zdravotnické dokumentace na národní a přeshraniční úrovni o Informace o principech identifikace a zabezpečení systému eHealth o Přístup k veřejné části reportingu v rámci manažerského informačního systému o Možnost podání hlášení v rámci farmakovigilance či hemovigilance či jiné nežádoucí události o Encyklopedické informace a znalosti, slovníky Personalizovaná část pro pacienty – pro přihlášené o Náhled na lékovou historii pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Náhled na výpis vykázané péče od poskytovatelů pro zdravotní pojišťovnu včetně finančních informací pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Náhled na seznam zdravotnické dokumentace, umístěné v místě vzniku, pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Náhled na obsah zdravotnických registrů pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Možnost získání náhledu na zdravotnickou dokumentaci, umístěnou v místě vzniku, pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Řízení oprávnění pro přístup zdravotnických pracovníků ke zdravotnické dokumentaci pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Možnost náhledu na seznam osoby přistupujících k seznamu či obsahu zdravotnické dokumentace, uložené v místě vzniku, pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Možnost podání stížnosti na poskytovatele či zdravotnického pracovníka o Možnost objednání na určitý výkon k poskytovateli pro sebe či osoby, pro něž je dotyčný zákonným zástupcem o Možnost využít služeb Telemedicíny:  Distanční monitorování pacientů – předávání dat z monitorování životních funkcí včetně případného vyvolání potřebných akcí v případě ohrožení zdraví a života, pomoc bloudícím osobám, apod.  Interaktivní komunikační systém – vzájemné propojení pacienta a lékaře, členů rodiny, ošetřovatelů, případně dalších poskytovatelů zdravotnických služeb včetně záchranné služby o Možnost uložení předem vysloveného přání („living will“) Obecná část pro zdravotnické pracovníky - veřejná o Informace k systému postgraduálního vzdělávání o Práva a povinnosti zdravotnických pracovníků o Seznam odborných informačních zdrojů s odkazy o Informace o léčivech a zdravotnických prostředcích včetně cenových aspektů o Principy sdílení zdravotnické dokumentace na národní a přeshraniční úrovni o Informace o principech identifikace a zabezpečení systému eHealth o Přístup k veřejné části reportingu v rámci manažerského informačního systému o Klinické doporučené postupy – návaznost na Národní sadu klinických standardů (NSKS) a Národní sadu ukazatelů kvality (NSUK) o Ověření platnosti EHIC o Možnost podání hlášení v rámci farmakovigilance či hemovigilance či jiné nežádoucí události Personalizovaná část pro zdravotnické pacienty – pro přihlášené o Možnost přihlásit se k aktivitám postgraduálního vzdělávání odkaz na jejich realizaci v eLearingové formě o Náhled na obsah Národního registru zdravotnických pracovníků o Možnost požádat o změnu v obsahu Národního registru zdravotnických pracovníků o Náhled na lékovou historii zadaného pacienta o Náhled na seznam zdravotnické dokumentace zadaného pacienta, umístěné v místě vzniku o Náhled na obsah zdravotnických registrů u zadaného pacienta

122 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Náhled na předem vyslovené přání zadaného pacienta Možnost využití služeb Telemedicíny:  Distanční hodnocení výsledků – hodnocení obrazových informací ve zdravotnictví – umožní efektivněji využívat personální vysoce kvalifikované kapacity  Druhý názor – distanční konzultaci druhým odborníkem  Distanční monitorování pacientů – prohlížení dat z monitorování životních funkcí včetně případného vyvolání potřebných akcí v případě ohrožení zdraví a života, pomoc bloudícím osobám, apod.  Interaktivní komunikační systém – vzájemné propojení pacienta a lékaře, členů rodiny, ošetřovatelů, případně dalších poskytovatelů zdravotnických služeb včetně záchranné služby o Generování přístupových údajů pro ePreskripci či jiné služby eHealth Obecná část pro poskytovatele o Práva a povinnosti poskytovatele o Přehled povinností hlášení do NZIS Personalizovaná část pro poskytovatele – pro přihlášené o Náhled na obsah Národního registru poskytovatelů zdravotních služeb o Možnost požádat o změnu v obsahu Národního registru poskytovatelů zdravotních služeb o Možnost splnění povinností hlášení do NZIS o Generování přístupových údajů pro ePreskripci či jiné služby eHealth o Přístup k neveřejné benchmarkingové části reportingu v rámci manažerského informačního systému o Informace o svých úhradách zdravotních služeb od zdravotních pojišťoven o o





Součástí projektu portálu by dále mělo být zpracování evropských standardů pro publikaci zdravotnických dokumentů na internetu a zhodnocení jejich aplikovatelnosti české prostředí. Měla by být vytvořena pravidla hodnocení kvality informačních zdrojů z oblasti zdravotnictví na internetu, které by přispěly ke korekci možných nepříznivých dopadů současného stavu.

4.3.8.3 Indikativní rozpočet realizace Odhadovaná výše nákladů na Portál je cca 58 mil. Kč bez DPH a náklady na roční provoz ve výši 10 mil. Kč. Tento rozpočet předpokládá, že ne všechny informační služby budou vtěleny přímo do portálu ve formě portletů, ale že na některé již existující služby (vyhledávání v databázi léčiv na SÚKL) bude možné pouze odkazovat. Položka Dodávka Portálu pacienta, poskytovatele a zdravotnických pracovníků – přihlašování, redakční systém a grafické zpracování Dodávka Portálu pacienta, poskytovatele a zdravotnických pracovníků – běhové prostředí pro jednotlivé portlety, komunikační rozhraní na systém výměny zdravotnické dokumentace, uložiště matice oprávnění Naplnění redakčního systému obsahem pro obecné části Portálu pro pacienta, zdravotnického pracovníka, poskytovatele zdravotních služeb Dodávka personalizované části Portálu pro pacienta Dodávka personalizované části Portálu pro zdravotnického pracovníka Dodávka personalizované části Portálu pro poskytovatele zdravotních služeb Celkem Roční provoz Portálu

Předpokládaná cena 3 mil. Kč. bez DPH 15 mil Kč. bez DPH

10 mil Kč. bez DPH 10 mil Kč. bez DPH 10 mil Kč. bez DPH 10 mil Kč. bez DPH 58 mil. Kč bez DPH 10 mil. Kč bez DPH ročně

123 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

4.3.8.3.1 Návrh harmonogramu v časové ose Priorita

Fáze implementace, činnost

Klíčový milník, aktivita

1 2

Rozhodnutí Příprava

3

Implementace Portálu

Rozhodnutí o realizaci portálu Příprava technické a funkční specifikace a provedení výběrových řízení Dokončení implementace Portálu pacienta, pracovníka a poskytovatele zdravotních služeb

Časové vymezení v měsících T T+2

T + 24

4.3.8.3.2 Vymezení klíčových milníků, aktivit Klíčové milníky jsou tyto:   

Rozhodnutí o realizaci portálu Příprava technické a funkční specifikace a provedení výběrových řízení Dokončení implementace Portálu pacienta, pracovníka a poskytovatele zdravotních služeb

4.3.8.3.3 Činnosti, vymezení jednotlivých fází implementaci a jejich prioritizace Jednotlivé fáze implementace dle priority jsou tyto:   

4.3.9

Rozhodnutí Příprava Implementace Portálu

Další řešení dle uvážení uchazeče

Pro účely národního sdílení by měla být vytvořena virtuální privátní síť (VPN). Přestože její realizace není nezbytná, tato další ochranná bariéra by významným způsobem zvýšila bezpečnost systému výměny zdravotnické dokumentace. Do této sítě by měli přístup pouze registrovaní poskytovatelé zdravotních služeb ve smyslu zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování. Centrální uzel VPN sítě (koncentrátor) by měl být institucionalizován v rámci KSRZIS. Zdrojem pro ověření přístupových údajů pro VPN síť by měl být Národní registr poskytovatelů zdravotních služeb. Správa VPN vytvořené pro potřeby elektronické preskripce by měla rovněž přejít ze SÚKLu na KSRZIS a být sloučena s novou VPN pro potřeby celého eHealth.

4.3.10 Interoperabilita s okolními informačními systémy (identifikace typů spolupracujících informačních systémů a návrh řešení jejich napojení) Systém eHealth je v rámci tohoto návrhu uvažován jako integrovaný celek následujících informačních systémů:   

  

Základní registry – propojení standardním způsobem dle legislativních pravidel a souvisejících technických dokumentů katalog služeb a podobně) Národní zdravotní registry – využití pouze pro čerpání informací a to pouze jako doplňkový zdroj. Informace z registrů o konkrétním pacientovi bude možné zobrazovat na Portálu Národní registr zdravotnických pracovníků a Národní registr poskytovatelů zdravotních služeb – využití pro autentizaci a autorizaci jako poskytovatele identity a zdroj informací pro přidělování oprávnění a zjišťování adres informačních systémů poskytovatelů Informační systémy zdravotních pojišťoven – poskytovatel „indexů“ umístění zdravotnické dokumentace a Souhrnu informací o pacientech ve stanoveném technickém formátu Centrální úložiště elektronických receptů – poskytovatel služeb elektronické preskripce a údajů pro náklad do lékové historie pacienta Informační systémy poskytovatelů zdravotních služeb – poskytovatel sdílené zdravotnické dokumentace ve ve stanoveném technickém formátu

124 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

  

epSOS – funkci národního kontaktního místa (NPC) implementuje EESSI Access Point Centra mezistátních úhrad dle stanoveného technického formátu (HL7 a IHE) a údaje získává z informačních systémů zdravotních pojišťoven a Centrálního úložiště elektronických receptů ePACS a ReDiMed – využití dle stávajícího způsobu pro výměnu obrazové dokumentace Reporting budovaný v rámci eREG – slouží jako datový sklad pro předávání informací k analytickému vyhodnocení z ostatních informačních systémů Portál – čerpá z ostatních informačních systémů údaje pomocí rozhraní těchto systémů

Jako primární způsob propojení informačních systémů jsou navrženy webové služby na základě technologie „SOAP over HTTPS“. Výjimka je pouze v případě využití standardu DICOM. Schéma propojení těchto systémů je uvedeno v bodě 4.3.1.2 Návrh architektury elektronického zdravotnictví.

4.3.11 Vazba na základní registry (návrh rozsahu propojení elektronického zdravotnictví se základními registry včetně zdůvodnění) Příklad workflow, jak si systém ukládá data pod AIFO a ověřuje si referenční údaje Na základní registry by měli být napojeny všechny klíčové systémy eHealth:        

IS zdravotních pojišťoven Národní zdravotní registry Registry hygienické služby Transplantační registry Centrální úložiště elektronických receptů IS vzdělávacích institucí IS poskytovatelů zdravotních služeb IS profesních komor

Napojení většiny z výše uvedených systémů vyplývá z aktuálně platné legislativy. Výjimku tvoří IS profesních komor v oblasti zdravotnictví, které dosud nefigurují na seznamu agendových informačních systémů registrovaných k přístupu do Základních registrů. Vzhledem k tomu, že například Česká advokátní komora má svůj IS dle seznamu agendových IS na Základní registry napojen, nejde tedy zřejmě o legislativní problém. Napojení těchto institucí tedy tento návrh nezdůvodňuje, protože už napojeny na Základní registry jsou nebo by být napojeny mohly a měly být. Specifická situace je u poskytovatelů zdravotních služeb, kteří aktuálně mohou využívat referenční údaje ze základních registrů pouze pro účely očkování. Není zde reálný důvod omezovat využití Základních registrů pouze pro účely prevence infekčních onemocnění na úkor neinfekčních. Referenční údaje by mohly být využívány i pro potřeby screeningů například nádorových onemocnění. Další důvod pro plné zapojení poskytovatelů zdravotních služeb do Základních registrů spočívá v možnosti budoucí reálné aplikace ustanovení § 41 odst. (3) zákona č. 372/2011 Sb., o zdravotních službách a podmínkách jejich poskytování. Podle tohoto ustanovení mají pacienti povinnost se na žádost zdravotnického pracovníka se prokázat občanským průkazem. Pokud však bude pokračovat přesun údajů z materiální podoby občanského průkazu do Základních registrů, nebude samotný občanský průkaz obsahovat údaje potřebné k ověření nezbytných skutečností. Již dnes přináší problémy praktická realizace ověření vztahu zákonného zástupce u dětí a mladistvých v bezvědomí či vztahu osoby blízké v obdobných případech. V případě odstranění místa trvalého bydliště z plastové podoby občanského průkazu, které je plánováno volitelně na rok 2017, se tato situace dále ztíží. Problematická by také byla praktická realizace požadavku „využití referenčních údajů pouze v rámci agendy očkování“, protože zdravotnická zařízení vedou obvykle pouze jeden seznam pacientů a agendu očkování řeší ve stejném informačním systému jako ostatní agendy. Nelze tedy vyloučit, že referenční údaje, ověřené pro účely očkování, se budou využívat i při jiných úkonech. Dvojí údaje pacienta (například příjmení) samozřejmě nelze mít ve zdravotnické dokumentaci v žádném případě, protože by se jednalo o vysoké rizika pro bezpečnost poskytovaných služeb.

125 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Je nutné si uvědomit, že z hlediska Základních registrů nezpracovávají všechny výše uvedené informační systémy jednu všeobjímající „agendu zdravotnictví“, ale několik samostatných agend, které jsou řízeny dle samostatných zákonů. Těmito samostatnými agendami jsou například:   

Agenda zdravotního pojištění Agenda registrace zdravotnických pracovníků Agenda statistické služby

Každá z agend bude identifikovat fyzické osoby pomocí jiného AIFO a nebude možné tato data snadno a bez vědomí dotyčné fyzické osoby propojovat. Dále je nutné počítat s tím, že Základní registry nepracují s rodným číslem a použití rodného čísla bude zcela znemožněno od roku 2020. Ztotožnění fyzické osoby se Základními registry tedy probíhá buď pomocí čísla občanského průkazu anebo kombinací jména, příjmení, data narození a místa trvalého pobytu. Výhradním identifikátorem osoby v jednotlivých agendách by měly být AIFO, ale případně dotyčná instituce může vydat vlastní identifikátor osoby – například číslo pojištěnce, které však bude muset být bezvýznamovým identifikátorem.

126 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

5

Návrh organizace zavádění elektronického zdravotnictví v ČR

Realizaci rozsáhlých implementačních projektů je vhodné rozdělit jednak na samostatně funkční celky, ale tyto celky je vodné rozdělit ještě do dvou částí. V první části by měla proběhnout analýza, ideálně procesně orientovaná, v rámci určitého minimalizovaného rozpočtu. Tím se získá podrobný a přesný přehled o tom, co se má přesně implementovat. Následně se ze závěrů analýzy vytvoří zadávací dokumentace pro vlastní implementační projekt. V obou případech pak může být jediným hodnotícím kritériem výběrového řízení cena. Doporučené rozdělení celkového projektu na části odpovídá jednotlivým položkám v indikativních rozpočtech jednotlivých částí technického modelu. Zcela zásadní je dostatečná institucionalizace projektu. Návrh předpokládá následující matici zodpovědností:     

Zodpovědnost za projekt elektronického zdravotnictví - KSRZIS Zodpovědností za správu rizik projektu - KSRZIS Zodpovědností za komunikaci projektu – Ministerstvo zdravotnictví Zodpovědnosti za udržitelnost systému elektronického zdravotnictví – Ministerstvo zdravotnictví Zodpovědností za správu systému elektronického zdravotnictví – KSRZIS

Zásadním prvkem organizace zavádění elektronického zdravotnictví v rámci ČR bude edukace a PR aktivita. Lze očekávat, že tyto činnosti budou konzumovat až 50% celkového rozpočtu projektu.

Definice základních principů řízení projektu

5.1

Při řízení takto rozsáhlého projektu, jaký je navrhován, je vhodné uplatňovat metodiku vycházející z mezinárodních norem (ČSN ISO 10006:2004 Systémy managementu jakosti – Směrnice pro management jakosti projektů) a doporučení mezinárodního standardu PMBOK (Project Management Body of Knowledge) a kompetenčního modelu IPMA (IPMA Competence Baseline) s možností přizpůsobení organizační struktuře Zadavatele a jeho systému řízení. Níže je uveden příklad takovéto metodiky. Ať bude nakonec v rámci buddování ehElath použita jakákoliv metodika, měl by být projektový manažer na tuto metodiku certifikován, a to na úrovni odpovídající rozsahu projektu.

5.1.1 Metodika řízení projektu Metodika definuje procesy projektového řízení, které jsou zařazené do následujících skupin (kategorií) dílčích procesů probíhajících v jednotlivých fázích projektu.     

Procesy zahájení - oficiální autorizované potvrzení projektu. Procesy plánování - definování a redefinování cílů a výběr nejlepšího z alternativních postupů činností k jejich dosažení. Procesy provedení - řízení zdrojů a koordinace projektových prací k provedení plánu. Procesy kontroly – monitorování postupu projektu, identifikace odchylek od původních plánů, přijetí nápravných opatření, přezkoumání, že projektové cíle byly naplněny. Procesy uzavření - formální akceptace projektu a dovedení jej do řádného konce.

127 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ BPMN Procesy proj ektu

Zaháj ení

Plánov ání

Prov edení (řízení a koordinace prací)

Monitorov ání a kontrola proj ektu

Uzav ření

Obrázek 20: Závislosti mezi skupinami procesů projektového řízení

Úroveň aktivity

Většina dílčích procesů a činností probíhajících v jednotlivých procesních skupinách je iterativních. V různé míře se mohou v rámci životního cyklu projektu překrývat, mohou být vztaženy k celému projektu, ale i k jeho etapě nebo fázi.

Provedení

Plánování

Zahájení

Start projektu

Uzavření Monitorování a kontrola

Čas

Konec projektu

Obrázek 21: Procesy projektového řízení v průběhu ŽC projektu

Životní cyklus (ŽC) projektu se skládá z fází. Konkrétní fáze závisí na povaze projektu (věcném předmětu projektu) a jeho rozsahu, v případě softwarového projektu např. Globální analýza a návrh, Detailní analýza a návrh, implementace a zavedení jednotlivých modulů do používání, atp.

5.1.1.1 Procesy zahájení Činnosti zahájení projektu, předpokládané aplikovat v rámci tohoto projektu jsou následující:   

Zahájení komunikace se zástupci Zadavatele. Zpracování souhrnné definice projektu (návrh realizačního projektu), její prezentace Zadavateli a společné odsouhlasení. Sestavení týmu pro zahájení projektu

128 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“   

Zorganizování zahajovacího (kick-off) mítinku projektu - prezentace návrhu realizačního projektu, odborných a technologických schopností Zadavateli, získání podpory zástupců Zadavatele pro projekt. Stanovení organizační struktury projektu a obsazení řídících rolí projektu. Vytvoření plánu řízení projektové dokumentace a nastavení plánu komunikace. Součástí zahájení je založení projektové knihovny.

5.1.1.2 Procesy plánování Cílem plánování je zpřesnění výstupů z předchozí fáze – strukturování globálního cíle do dílčích položek a konkrétních výstupů, rozdělení pracovních produktů do dílčích částí, definice vnitřních rozhraní subsystémů, příprava metodik a inventarizace potřebných znalostí a dovedností, identifikace potřebných zdrojů a definice rizik a předpokladů omezení jejich dopadů. Proces plánování projektových prací je sestaven z následujících činností:  vytvoření podrobného rozpisu prací (WBS),  vytvoření časového harmonogramu,  plánování a alokace zdrojů. Mimo výše uvedené procesy plánování zahrnují vytvoření ostatních částí plánu projektu, jako jsou: plán řízení kvality a plánu řízení rizik.

5.1.1.3 Procesy provedení Procesy provedení závisejí na povaze předmětu projektu. V případě navrženého řešení jde také o vývoj SW nebo o služby s vývojem SW související (služby softwarového inženýrství, podpora a údržba softwarových produktů), které se řídí se metodikou vývoje aplikačního software. Primárně v případě vývoje SW se jedná o činnosti:  globální analýza a návrh (GAN),  detailní analýza a návrh (DAN),  programování (implementace),  testování,  zavedení do používání. Dílčí činnosti podrobně popisuje Metodika vývoje aplikačního SW popsaná blíže v bodě 5.1.6 Metodika vývoje SW. Úzce souvisejícími procesy jsou dále:   

Release Management Change Management Incident Management (Řešení provozních incidentů)

5.1.1.4 Procesy kontroly Monitorování a kontrola projektu se soustředí na zjišťování skutečného postupu projektu vůči jeho plánu a přijímání veškerých nezbytných opatření pro včasnou nápravu. Proces monitorování a kontroly projektu začíná již v okamžiku, kdy je projekt zahájen a kdy jsou čerpány jeho náklady. Úplná kontrola je však prováděna až po schválení plánu a započetí realizačních prací. Obsahem monitorování a kontroly projektu je sbírání poznatků a stavu projektu a měření jeho postupu vzhledem k původnímu plánu a následná distribuce souvisejících informací všem zainteresovaným stranám projektu, pokud je to pro projekt nezbytné. Důležitou součástí procesu je řízení změn, jako reakce na změnové požadavky, které mohou v průběhu projektu přicházet od různých Dodavatelů projektu (zástupců zainteresovaných stran) – vazba na procesy provedení.

129 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Další důležitou součástí, rovněž s vazbou na procesy provedení, jsou činností související s přípravou a zajištěním akceptace výstupů projektu Zadavatelem. Proces kontroly projektu se sestává z následujících činností:    

monitorování postupu projektu a plnění provozních parametrů, podávání zpráv o stavu projektu, řízení změn v projektu, zajištění akceptace výstupů projektu.

5.1.1.5 Procesy uzavření Uzavření projektu probíhá organizovaným a řízeným způsobem. Jsou archivovány informace ze sledování projektu a veškerá projektová dokumentace a výstupy projektu. Jsou přezkoumány a uzavřeny všechny smluvní vztahy a identifikovány zbylé otevřené problémy, včetně návrhu jejich řešení. Součástí uzavření projektu je jeho vyhodnocení, jehož součástí je přezkoumání spokojenosti Zadavatele s realizací projektu. Činnosti v rámci uzavření projektu budou:          

Uzavření plánu projektu a jeho vyhodnocení Přezkoumání spokojenosti Zadavatele s realizací projektu - Hodnotí se spokojenost pracovníků Zadavatele s přístupem pracovníků Dodavatele a to, do jaké míry byly naplněny stanovené cíle projektu. Uzavření smluvních vztahů: identifikace zbylých otevřených problémů (formou přezkoumání kontraktu a seznamu problémů a jejich řešení), uzavření seznamu problémů a jejich řešení, získání finální akceptace projektu, iniciace finálních plateb (fakturace), uzavření finančních procedur. Uzavření plánu komunikace – organizace závěrečného mítinku projektu, za účasti zástupců všech zainteresovaných stran. Vydání oznámení o ukončení projektu. Archivace projektové dokumentace.

5.1.2 Vybrané procesy řízení projektu 5.1.2.1 Monitorování postupu projektu V rámci monitorování postupu projektu je prováděno měření (zjištěných stavových hodnot projektu), hodnocení (jakou měrou skutečné hodnoty naplňují plánované hodnoty) a korekce (opatření pro korekci případných odchylek). Důraz je kladen na kontrolu tří dimenzí trojimperativu (předmětu projektu, časového harmonogramu a rozpočtu). Součástí monitoringu projektu je rovněž kontrola kvality a monitorování a kontrola rizik. Základní dílčí činnosti monitorování postupu projektu jsou:    

aktualizace stavu plnění úkolů jednotlivými členy týmu, sledování plnění projektu k stanovenému datu - tj. na ukončené (příp. dodané) výstupy úkolů, analýza odchylek proti plánu (v rámci kontrolních schůzek), plánování alternativ a přizpůsobení, návrhy kompenzačních opatření (v rámci kontrolních schůzek - vazba na řízení rizik a řízení změn). Nedílnou součástí monitorování postupu projektu je kontrola předmětu projektu. Tato kontrola probíhá v rámci tematických kontrolních schůzek (schůzky a prezentace vztahující se k věcnému plnění předmětu projektu). Kontrola naplňování předmětu je důležitou aktivitou z pohledu postupného plnění dílčích cílů projektu.

130 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Kontrola časového harmonogramu podává informace o tom, zda se realizační proces projektu pohybuje v souladu s časovým harmonogramem. Na základě zjištěných odchylek probíhá rozhodování o variantách budoucího vývoje a případně jsou spuštěny příslušné mechanismy procesu řízení rizik. Důležitým předpokladem pro uvedené činnosti je vytvoření efektivního systému podávání zpráv.

5.1.2.2 Podávání zpráv o stavu projektu Podávání zpráv o stavu projektu se musí řídit plánem komunikace, který je součástí celkového plánu projektu. V rámci projektového reportingu Dodavatel průběžně informuje Zadavatele o stavu a průběhu projektu, o realizovaných a plánovaných činnostech, o problémech a rizicích na příslušné řídící úrovni projektu. Kromě operativního informování vedoucí projektu Dodavatele předkládá Zadavateli a ostatním zainteresovaným stranám každý měsíc strukturovanou Zprávu o stavu projektu, po ukončení projektu pak Závěrečnou zprávu. Zpráva obsahuje popis a shrnutí průběhu realizace projektu za příslušné období, stav plnění harmonogramu a plán činností na další období. Zprávy předkládá vedoucí projektu Dodavatele na VVP:  u Zprávy o stavu projektu do 10. dne následujícího měsíce,  u Závěrečné zprávy do 30 dnů od předání a akceptace posledního plnění zakázky. Struktura měsíční Zprávy o stavu projektu je následující:  textový popis/komentář k celé zprávě,  dosažené výsledky uplynulého období,  plánované činnosti a očekávané výsledky nadcházejícího období,  stav plnění hlavních časových milníků – plán, skutečnost/předpoklad, komentář,  stav plnění výstupů projektu – odchylky, komentář,  eskalované problémy (odkaz na seznam problémů),  eskalovaná rizika (odkaz na seznam rizik). Závěrečná zpráva obsahuje průběh realizace celé zakázky.

5.1.2.3 Řízení změn v projektu Řízení změn probíhá ve všech fázích projektu od jeho iniciace po fázi uzavření, jeho výstupy jsou schválené změnové požadavky, které jsou pokynem ke změnám souvisejících oblastí a spouštějí nové cykly plánovacích procesů. Klasifikace změn: 

Změny 1. třídy – mají dopad do smluvních vztahů – mohou změnit cíle projektu, jeho rozsah, harmonogram, rozpočet nebo jiné charakteristické vlastnosti projektu, které jsou specifikovány ve smlouvě.  Změny 2. třídy – změny, které neovlivňují základní charakteristiky projektu – je nutné je ale předložit, vyhodnotit a posoudit, aby nebyly opomenuty možné vlivy na ostatní části projektu. Proces řízení změny: 

 

Požadavky na změny identifikují jednotlivé projektové týmy. Za Dodavatele přijímá požadavek na změnu vedoucí projektu, hlavní architekt nebo hlavní analytik. Požadavky na změnu musí být formulovány písemně, musí obsahovat specifikaci návrhu změny, zdůvodnění a posouzení vztahů a souvislostí k zadaným cílům projektu nebo k výstupům projektu. Vedoucí projektu Dodavatele požadavky eviduje (na projektovém portálu nebo v zápisech z VVP). Vedoucí projektu Dodavatele ověří, zda požadavek na změnu: o není nad rámec smlouvy nebo schválené dokumentace projektu,

131 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“



 

o je realizovatelný – stanoví náročnost realizace, o nemá dopad na harmonogram, případně neohrozí konečný termín předání díla; VVP projednává jednotlivé požadavky následujícím způsobem: o rozhoduje o schválení nebo zamítnutí požadavku na změnu, o rozhoduje o termínu realizace (prioritách), o rozhoduje o způsobu realizace (kdy a jak bude změna aplikována, nasazena), o rozhoduje o změně harmonogramu dílčích činností v souvislosti s požadavkem na změnu, o rozhoduje o způsobu krytí případných více-prací v souvislosti s požadavkem na změnu na projektové úrovni (pracovní tým, řídící tým projektu, řídící komise projektu). Pokud požadavek na změnu není na projektové úrovni schválen, požadavek je odmítnut nebo odložen nebo v případě rozporu mezi oběma stranami je eskalován na ŘVP. Výsledek projednání se zaznamená do zápisu z jednání VVP. Projednávání souhrnných informací o požadavcích na změnu tvoří jeden z bodů pravidelných jednání VVP.

5.1.2.4 Řízení rizik Pravidelným bodem jednání VVP je přezkoumání identifikovaných rizik, a to především proto, aby si pracovníci projektových týmů na straně Zadavatele i Dodavatele byli vědomi identifikovaných rizik a zohlednili je při práci na projektu.  

Riziko může identifikovat libovolný člen projektového týmu ze strany Zadavatele i Dodavatele. Identifikovaná rizika se pravidelně projednávají na úrovni VVP a jsou evidována na projektovém portálu nebo v zápisech z jednání VVP.  V případě rizik s velkou závažností projednává rizika ŘVP. Proces řízení rizik sestává z následujících kroků:      

identifikace rizik, analýza rizik a stanovení priorit, plánování rizik, monitorování rizik a podávání zpráv, kontrola rizik, poučení se z rizik.

analysis Řízení rizik

Identifikace rizik

Plánov ání rizik

Kontrola rizik Konec p rocesu

Analýza rizik a stanov ení priorit

Monitorov ání rizik a podáv ání zpráv

Poučení se z rizik

Začátek procesu

Obrázek 22: Řízení rizik

Identifikace rizik dovoluje týmu a ostatním zainteresovaným stranám objevit riziko dříve než by mohlo nepříznivě ovlivnit projekt. Analýza rizik transformuje odhady dat týkající se konkrétních projektových rizik získaných v průběhu identifikace do podoby, kterou tým může použít pro rozhodování ohledně nastavení priorit. Nastavení priorit umožňuje týmu vyčlenit projektové zdroje pro řízení nejdůležitějších rizik.

132 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Plánování rizik přebírá informace z analýzy rizik a používá je k tvorbě strategie, plánů a opatření, které jsou začleněny do standardních denních činností projektového řízení jako součást standardních úkolů týmů. Plánování rizik se stává součástí plánování projektu. Monitorování rizik sleduje stav konkrétních rizik a postup v plánech a opatřeních k jejich zmírnění. Zahrnuje rovněž monitorování pravděpodobnosti, dopadu a ostatních parametrů rizika, které se mohou měnit a které ovlivňují prioritu rizika a související plány. Podávání zpráv zprostředkovává týmu a ostatním zainteresovaným stranám informace o stavu rizik a jejich řízení. Kontrola rizik je činnost, v rámci které se provádějí opatření nouzového plánu a podávají se o stavu provádění těchto opatření zprávy. Kontrola rizik rovněž může iniciovat žádosti o změnu v projektu, v případě, že opatření nouzového plánu mají dopad na rozsah, zdroje nebo časový harmonogram. Poučení se z rizik – formalizuje a zaznamenává nabyté zkušenosti z řešení rizik pro opětovné využití.

5.1.2.5 Řízení kvality Základním nástrojem pro řízení kvality výstupů projektu je akceptační řízení. Smyslem akceptačního řízení je ověřit, zda výsledný výstup odpovídá zadání jak z hlediska naplnění funkčních požadavků tak dosažení zamýšlených cílů a účelu. V rámci tohoto procesu Zadavatel akceptuje správnost výstupu. V případě, že je konkrétní výstup v podobě dokumentu, má akceptace podobu připomínkového řízení (oponentury). Při předávání samotného systému nebo jeho části má proces podobu akceptačního testování. Připomínkové řízení k předávaným dokumentům (oponentura) O připomínkování předávaných projektových dokumentů rozhoduje VVP. Termín předání dokumentů Zadavateli k připomínkám a dobu potřebnou pro oponenturu primárně stanoví detailní harmonogram příslušné etapy projektu. Detailní úpravu připomínkového řízení stanoví VVP). Odpovědný pracovník za stranu Zadavatele předává připomínky souhrnně za Zadavatele v samostatném dokumentu (pokud není stanoveno jinak). Připomínky jsou směřovány ke konkrétním částem (odstavcům, větám) dokumentu. Obecné připomínky bez jednoznačné vazby na konkrétní část (text) dokumentu není Dodavatel povinen vypořádat. Dodavatel musí zapracovat všechny připomínky. Zapracováním se rozumí akceptace připomínky, vysvětlení nebo jiné zpracování připomínky se souhlasem odpovědného pracovníka za připomínkování, zamítnutí připomínky se souhlasem garanta, VVP nebo ŘVP. Dodavatel musí po zapracování odeslat novou verzi dokumentů ke kontrole. Opakovaně předávané dokumenty Zadavateli jsou verzovány. V rámci kontroly odpovědný pracovník za stranu Zadavatele kontroluje správnost zapracování připomínek. Další (nové) připomínky (k částem, ke kterým připomínky nebyly) není Dodavatel povinen akceptovat. Předávaný dokument se považuje za akceptovaný bez výhrad, pokud byly vypořádány všechny připomínky, nebo pokud nebyly v termínu předány žádné připomínky. Předávaný dokument se považuje za akceptovaný s výhradami, pokud po zapracování zůstaly nevypořádané připomínky, které nebrání pokračování v dalších etapách projektu. Tyto připomínky se zaznamenají do akceptačního protokolu. O jejich časovém plánu, způsobu a podmínkách vypořádání rozhoduje VVP. Aktuální verze dokumentů, které jsou předmětem připomínkového řízení, jsou publikovány na projektovém portálu. Akceptační testování systému Předmětem akceptačních testů je systém nebo část systému (přírůstek, modul). Akceptační testy se plánují vždy na konci fáze projektu, ve které je předáván Zadavateli systém/část systému.

133 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Termíny akceptačních testů jsou primárně stanoveny detailním harmonogramem příslušné etapy projektu Organizace akceptačních testů je v kompetenci rozhodnutí VVP. VVP stanovuje konkrétní složení akceptačního týmu, předání připomínek za stranu Zadavatele a odpovědného pracovníka za provedení akceptačních testů na straně Zadavatele (typicky akceptační tým pro vedením garanta příslušné věcné oblasti). Odpovědný pracovník za stranu Zadavatele předává připomínky souhrnně za Zadavatele. Odpovědný pracovník se společně s hlavním analytikem Dodavatele dohodnou na klasifikaci závad. Ve sporných případech rozhoduje o klasifikaci VVP.

Obrázek 23: Postup akceptačního řízení

Akceptační kritéria Systém nebo část systému (přírůstek) je akceptovatelný, pokud je splněna alespoň jedna z následujících podmínek: 





Všechny připomínky byly projednány a odpovědný pracovník za akceptační testy a Dodavatel se dohodli na klasifikaci a způsobu vypořádání připomínek, které dosud nebyly odstraněny, a na tom, že připomínky nebrání akceptaci systému nebo jeho části. Všechny připomínky byly projednány a klasifikovány. V rámci akceptace byly odstraněny všechny případné chyby kategorie A a neodstraněny zůstaly maximálně 3 případné chyby kategorie B. U všech případných chyb kategorie B a C bylo naplánováno jejich vypořádání. Ve sporných případech rozhoduje VVP. V rámci akceptačních testů nebyly ve stanoveném termínu předány žádné připomínky.

Kategorizace vad v průběhu akceptace

134 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Každá z nalezených vad, chyb a připomínek je zaznamenaná do evidence problémů a chyb s tím, že je současně přiřazena do jedné z následujících kategorií: 

Havárie (kategorie A): aplikace nebo jednotlivý modul jako celek je mimo provoz nebo je převážná část jeho funkcí nedostupná. Jedná se o kritickou vadu/chybu, znemožňující užití dodaného systému. Tedy vadu, která způsobuje tak závažné problémy, že Zadavatel nemůže aplikační systém používat v jeho základních funkcích nebo nijak ovládat, a tedy další vývoj ani dodržení předpokládaného časového plánu akceptace není možný, dokud chyba nebude odstraněna.  Problém (kategorie B): důležité funkce aplikace jsou nedostupné a nelze je vyvolat jiným způsobem nebo je nelze jednoduchým způsobem nahradit organizačním opatřením. Jedná se o závažnou vadu/chybu, vážně ohrožující užití dodaného systému. Tedy taková vada, kdy funkčnost dodaného systému je ve svých funkcích degradována tak, že tento stav omezuje běžný provoz Zadavatele a vada by neopravením ohrozila další pokračování akceptace nebo další provoz dalších částí systému.  Vada (kategorie C): funkční chyby drobnějšího charakteru, výpadky funkcí, které lze vyvolat jiným způsobem. Jedná se o vadu/chybu neohrožující další provoz a užití systému. Jedná se o vadu, která způsobí pouze částečný neúspěch akceptace nebo která se projeví pouze občas. Za provozních podmínek by nebyla ztracena žádná závažná data, ani znemožněno vykonávání žádné závažné funkce systému, nebo by bylo možné nalézt za ní vhodnou alternativu. Tyto závady by neohrozily další provoz systému s ostrými provozními daty.  Změna: požadavek nad rámec zadání, řídí se dále dle procesu řízení změn. Kategorii vady navrhuje Zadavatel, Dodavatel má právo kategorii po vzájemné diskusi a schválení vedoucím projektu Zadavatele změnit.

5.1.3 Řídící struktura projektu Řídící struktury projektu jsou definovány za účelem efektivního rozložení organizačních, řídících a výkonných činností mezi jednotlivé členy projektového týmu na straně Zadavatele i Dodavatele. Řídící a organizační strukturu projektu tvoří:    

Řídící výbor projektu – zahajuje projekt, ukončuje projekt, řeší eskalované otázky z nižších úrovní řízení především z úrovně výkonného výboru projektu, Výkonný výbor projektu – hlavní platforma pro řídící činnosti v rámci projektu, Pracovní týmy – týmy (libovolný počet) specificky zaměřené na řešenou problematiku (věcnou oblast, proces, technologie atd.), Akceptační týmy – odpovědný za připomínkování a akceptaci výstupů z projektu a za akceptační testování.

Řídící výbor projektu Zástupci vedení Zadavatele Zástupci vedení Dodavatele Výkonný výbor projektu vedení projektu Zadavatele vedení projektu Dodavatele

Pracovní týmy tým projektu Zadavatele tým projektu Dodavatele

Specialisté a konzultanti

Tým pro kvalitu a bezpečnost

Akceptační tým

Tým pro provoz, školení a podporu

Pracovní týmy tým projektu Zadavatele tým projektu Dodavatele

Pracovní týmy tým projektu Zadavatele tým projektu Dodavatele

Pracovnítýmy tým projektu Zadavatele tým projektu Dodavatele

135 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Obrázek 24: Návrh organizační struktury projektu

5.1.3.1 Řídící výbor projektu (ŘVP) Řídící výbor projektu je tvořen zástupci jmenovanými vrcholovým vedením Zadavatele a Dodavatele. Má minimálně 4 stálé členy:  Ředitel projektu za stranu Zadavatele  Ředitel projektu za stranu Dodavatele  Vedoucí projektu Dodavatele  Vedoucí projektu Zadavatele ŘVP zajišťuje nejvyšší strategickou úroveň rozhodování, rozhoduje o případech eskalovaných z úrovně výkonného výboru projektu, které se nepodařilo vyřešit na nižších úrovních. Rozhoduje na základě podkladů vypracovaných ostatními týmy projektu. Řeší zásadní otázky týkající se splnění či nesplnění hlavních záměrů projektu jako celku. Řídí rozpočet projektu. ŘVP akceptuje dílo jako celek dle rozsahu smlouvy. ŘVP schvaluje změny smluvních ustanovení, především schvaluje změny v projektu, které mají dopad na časový (dílčí etapy), finanční anebo věcný rozsah plnění dle smlouvy. Přijímá opatření a definuje další postup v případě krizových stavů projektu. Jednání ŘVP může být iniciováno řediteli a vedoucími projektu (na straně Zadavatele i Dodavatele). Jednání ŘVP nejsou pravidelná.

5.1.3.2 Výkonný výbor projektu (VVP) Výkonný výbor projektu je základní řídící strukturou projektu, která má za úkol zajistit soulad postupu prací na projektu se schváleným věcným a časovým plánem. VVP má minimálně následující členy:  Vedoucí projektu Dodavatele  Vedoucí projektu Zadavatele VVP ověřuje výstupy jednotlivých fází projektu a akceptuje dílčí etapy projektu. Vyhodnocuje harmonogram a postup prací. Přijímá potřebná opatření pro splnění cílů projektu a řídí poskytování součinnosti Zadavatele. Projednává a schvaluje změny v projektu v rámci platné smlouvy. Změny smluvních podmínek předkládá ke schválení řídícímu výboru projektu. VVP jedná na pravidelných schůzkách 1x týdně, není-li na úrovni VVP stanoveno jinak. Konkrétní termíny, místo jednání a další pravidla jsou předmětem prvního jednání VVP. Jednání VVP se mohou účastnit podle potřeby i další zástupci Zadavatele, a to pravidelně či pouze pro potřeby projednání specifického tématu, avšak vždy se souhlasem vedoucího projektu Zadavatele. Jednání VVP se mohou účastnit podle potřeby i další zástupci Dodavatele, a to pravidelně či pouze pro potřeby projednání specifického tématu, avšak vždy se souhlasem vedoucího projektu Dodavatele. Minimální agenda pravidelného jednání VVP:      

Projednání stavu plnění harmonogramu (zhodnocení realizovaných prací, plán na následující období) Kontrola plnění úkolů – za období od předchozího jednání Kontrola plnění provozních parametrů v rámci pilotního provozu Odsouhlasení dokumentů/návrhů připravených pracovními týmy Řízení změn - průběžné vyhodnocování změn a ostatních připomínek k rozsahu. Výstupem je specifikace (zpřesnění) zadání nebo specifikace nových požadavků nad rámec zadání, Projednání Zprávy o stavu projektu, Zprávy o splnění jednotlivých požadavků a Závěrečné zprávy

136 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

5.1.3.3 Specialisté a konzultanti Specialisté a konzultanti jsou pracovníci Zadavatele nebo Dodavatele, kteří poskytují pro účely projektu potřebné know-how pro konkrétní specifické potřeby. Specialisté a konzultanti mohou být po dohodě Zadavatele a Dodavatele přizváni k jednání pracovních týmů nebo VVP.

5.1.3.4 Tým pro kvalitu a bezpečnost Tým složený z kompetentních zástupců Zadavatele a Dodavatele, jehož účelem je posuzování bezpečnostních aspektů průběhu projektu a zajištění požadované kvality

5.1.3.5 Pracovní týmy Pracovní tým je dočasná či trvalá struktura projektu s jasně přiděleným rozsahem úkolů nebo řešení vymezené věcné oblasti. Pracovní tým je definován na úrovni VVP. Složení týmu se může v různých fázích projektu dle potřeby obměňovat. O změně složení pracovního týmu rozhoduje VVP. Pracovní tým je složen minimálně z garanta věcné oblasti na straně Zadavatele a analytika (či jiné projektové role) ze strany Dodavatele. Dále se pracovní tým skládá z klíčových uživatelů definovaných garantem.

5.1.3.6 Akceptační tým Akceptační tým je dočasná projektová struktura tvořena:      

Garanty věcné oblasti (garant se účastní akceptace jemu příslušné věcné oblasti) Další klíčoví uživatelé systému (tito pracovníci Zadavatele mohou být specializováni na jednotlivé věcné oblasti) Analytikem (hlavním analytikem) za příslušnou věcnou oblast za stranu Dodavatele Akceptační tým odpovídá za: Připomínkování dokumentů předávaných v rámci systému Testování a akceptační testování systému v různém stádiu vývoje (testování prototypu, funkční testování, akceptační testování)

5.1.3.7 Tým pro provoz, školení a podporu Tým pro školení a podporu provádí školení a podporu nasazených přírůstků a celého řešení. Tým je složen primárně ze zástupců Dodavatele, úzce spolupracuje s IT pracovníky Zadavatele.

5.1.4 Komunikace v rámci projektu Komunikace v rámci projektu se řídí například následujícím plánem komunikace, který je dále upřesněn, zejména pokud jde o konkrétní termíny a časy schůzek.

5.1.4.1 Komunikační rozhraní Komunikační rozhraní v projektu vychází z principu jednotných komunikačních a kontaktních míst (single point of contact). Za projektový tým Dodavatele jej primárně představuje Vedoucí projektu Dodavatele. Za stranu Zadavatele je to Vedoucí projektu Zadavatele. Na komunikaci se, s pověřením výše uvedených rolí, podílejí pracovníci zastávající vedoucí role v týmu Dodavatele a za stranu Zadavatele pracovníci, kteří byli ustanoveni do VVP. Přiřazení rolí jednotlivým pracovníkům a jejich vzájemné představení proběhne oficiálně při příležitosti zahajovacího (kick-off) mítinku projektu.

5.1.4.2 Frekvence schůzek Jednání ŘVP:

operativně, dle potřeby, minimálně jedenkrát za tři měsíce.

137 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Jednání VVP:

1 x týdně.

Jednání projektových týmů: zpravidla 1 x týdně, vždy dle předem dané dohody.

138 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

5.1.4.3 Komunikační položky Položka komunikace

Popis

Účel

Seznam úkolů a jejich řešení

Dle šablony – datum, popis, přiděleno, stav, cílové datum

Souhrnný přehled úkolů a nevyřešených problémů v projektu

Zpráva o stavu projektu

Identifikace, rozbor změn, dopady na plán, problémy a jejich řešení, přehled o výsledcích a schopnostech, přehled změnových požadavků, stav plnění výstupů

Pro účely monitorování projektu – včasná identifikace případných problémů a rizik

Frekvence

Určeno komu

Odpovědnost

VVP, ŘVP Týdně

Měsíčně

Zápis z porady ŘVP

Řešení eskalovaných problémů a rizik

Vrcholová rozhodnutí v projektu

Zápis z porady VVP

Úkoly (předpoklady, omezení, rizika a změny spojené s plněním projektových prací), další informace

Pro účely návazných jednání VVP a řízení projektu

Týdně

Zápis z porady projektového týmu

Diskutování úkolů (přetrvávající úkoly, splněné úkoly, nové úkoly), další informace, datum příští porady

Pro účely návazných porad projektového týmu

Zápis z konzultace

Dodávané výstupy

Operativně dle potřeby

Umístěno na projektovém portálu

ŘVP + ostatní zainteresované strany Umístěno na projektovém portálu

ŘVP + ostatní zainteresované strany Umístěno na projektovém portálu

Vedoucí projektu Dodavatele

Vedoucí projektu Dodavatele

Vedoucí projektu Dodavatele

VVP, ŘVP Umístěno na projektovém portálu

Vedoucí projektu Dodavatele

Týdně

Pracovníci projektového týmu

Vedoucí projektu Dodavatele

Obsah konzultací s pracovníky

Zaznamenání a vzájemné potvrzení informací jako podklad pro řešení projektových úkolů

Operativně dle potřeby

VVP, Pracovníci projektových týmů

Předem určený pracovník (řídící konzultaci)

Obsah projektových prací

Plnění specifikací, monitorování projektu

Dle časového HMG

VVP, ŘVP Umístěno na projektovém portálu

Pracovníci projektového týmu (dle charakteru výstupu)

139 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Položka komunikace

Předávací protokol

Popis

Účel

Frekvence

Určeno komu

Odpovědnost

VVP, ŘVP

Dle šablony

Předání výstupů projektových prací

Dle časového HMG

Dle šablony

Akceptace projektových prací

Dle časového HMG

Dle šablony

Získání zpětné vazby

Na konci projektu

Umístěno na projektovém portálu

Vedoucí projektu Dodavatele

VVP, ŘVP Protokol o akceptaci

Dotazník spokojenosti zákazníka

Umístěno na projektovém portálu

Vedoucí projektu Dodavatele

VVP, ŘVP Umístěno na projektovém portálu

Vedoucí projektu Dodavatele

5.1.5 Projektové role 5.1.5.1 Ředitel projektu za Zadavatele Ředitel projektu Zadavatele je zodpovědný zejména za vrcholové řízení projektu na straně Zadavatele. V rámci své kompetence odpovídá především za řešení eskalovaných problémů z nižších úrovní řízení v rámci řídícího výboru projektu. Ředitel projektu za Zadavatele je oprávněn podepisovat předávací a akceptační protokoly pro celkovou akceptaci díla za Zadavatele.

5.1.5.2 Ředitel projektu za Dodavatele Ředitel projektu Dodavatele je zodpovědný zejména za vrcholové řízení projektu na straně Dodavatele. Odpovídá především za řešení eskalovaných problémů z nižších úrovní řízení v rámci řídícího výboru projektu. Ředitel projektu za Dodavatele je oprávněn podepisovat předávací a akceptační protokoly pro celkovou akceptaci díla za Dodavatele.

5.1.5.3 Vedoucí projektu za Zadavatele Vedoucí projektu Zadavatele je zodpovědný zejména za:          

Řízení a koordinaci projektu ze strany Zadavatele Plánování a koordinace činnosti pracovních týmů (garantů věcných oblastí) Kontrola přidělených úkolů, odpovědnost za jejich splnění v termínu Koordinace časových možností garantů (řešení časových kolizí s jinými pracovními úkoly) Definování (změna) garantů Součinnost ze strany pracovníků Zadavatele, především garantů (jejich přípravu na schůzky pracovních týmů a za splnění úkolů definovaných schůzkami pracovních týmů). Zajištění nezbytné součinnosti třetích stran, obzvláště dodavatelů stávajících informačních systémů a externích subjektů, s jejichž systémy má být realizováno rozhraní. Zastřešení věcného obsahu a koncepce (business, funkční a ostatní požadavky) systému za Zadavatele. Má kompetencí určovat jednotlivé věcné oblasti, jejich náplň, rozsah, výstupy a vztahy. Předávání podkladů a poskytování součinnosti ze strany Zadavatele. Realizaci přidělených úkolů na úrovni VVP.

140 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

Koordinaci požadavků na vyvíjený systém z jednotlivých pracovních týmů a oblastí, řešení případných nekonzistencí v požadavcích na systém, rozhodování o náročnosti a prioritách.  Koordinaci oponentury jednotlivých výstupů garanty oblasti (připomínkování, testování, akceptační testování, školení, workshopy).  Formální schvalování a potvrzování dílčích výstupů projektu.  Informování o stavu a postupu projektu směrem k zainteresovaným stranám. Vedoucí projektu je oprávněn podepisovat předávací a akceptační protokoly k jednotlivým dílčím plněním.

5.1.5.4 Vedoucí projektu za Dodavatele Vedoucí projektu Dodavatele (projektový manažer) je zodpovědný zejména za taktické řízení projektu:              

Definování a změnu projektového týmu Dodavatele. Plánování projektu a jeho etap. Realizaci přidělených úkolů na úrovni VVP. Přípravu agendy jednání VVP a zpracování zápisů z jednání VVP. Aplikaci rozhodnutí VVP a ŘVP a schválených řídících dokumentů (smlouvy, harmonogramu projektu) při realizaci projektu. Předložení Zprávy o stavu projektu, Zprávy o splnění jednotlivých požadavků etapy (přírůstku) a Závěrečné zprávy a jejich předkládání na VVP. Dále odpovídá za operativní řízení a koordinaci projektu ze strany Dodavatele. Zpracování podkladů pro plánování prací a koordinace činnosti projektového týmu Dodavatele v souladu s plánem a harmonogramem. Kontrola přidělených úkolů, odpovědnost za jejich splnění v termínu. Koordinace kapacit Dodavatele (řešení časových kolizí s jinými pracovními úkoly). Koordinace činností a výstupů pracovních týmů v rámci projektu. Zpracování podkladů pro Zprávy o stavu projektu a Závěrečné zprávy projektu a jejich předkládání na VVP. Identifikace rizik a uplatnění přijatých nápravných opatření. Součinnost ze strany pracovníků Dodavatele (jejich přípravu na schůzky pracovních týmů a splnění úkolů definovaných schůzkami pracovních týmů).

5.1.5.5 Manažer kvality Manažer kvality odpovídá za návrh a dodržení standardů kvality při realizaci a provozu podle obecně platných norem a požadavků Zadavatele.      

Zajišťuje, že procesy systému managementu kvality jsou na projektu vytvářeny, uplatňovány a udržovány. Připravuje ve spolupráci s VP plán kvality projektu. Navrhuje kritéria kvality, ve spolupráci s VVP stanovuje jejich akceptovatelné meze a dohlíží na jejich dodržování. Provádí nebo organizuje interní audity dodržování stanovených projektových standardů kvality. Schvaluje návrh akceptačních testů a dohlíží na jejich provedení. Podporuje vědomí závažnosti požadavků Zadavatele v rámci projektového týmu.

5.1.5.6 Garant věcné oblasti Garant věcné oblasti je vedoucím pracovního týmu za stranu Zadavatele. 

Garant zná řešenou věcnou oblast, příslušnou legislativu, interní předpisy, pravidla, postupy, současnou praxi i její aplikační podporu, její úzká místa a problémy. Garantuje přenos všech pro systém relevantních informací na pracovníky Dodavatele v rámci schůzek pracovního týmu a předávaných podkladů a jejich jednoznačný výklad (interpretaci, vysvětlení).

141 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

Garant odpovídá zejména za definici a schválení cílů řešení souvisejících s garantovanou oblastí a za definici a schválení funkčních požadavků na vyvíjený systém včetně jejich doplňujících vlastností.  Garant odpovídá za přípravu a provedení funkčních a akceptačních testů systému nebo jeho části v rozsahu vymezené věcné oblasti.  Účastní se všech schůzek daného pracovního týmu. Na schůzku si může přizvat potřebný počet spolupracovníků v dané oblasti. Stále je ale jedinou odpovědnou osobou za domluvené závěry. Garant schvaluje zápisy z jednání pracovního týmu.  Garant oblasti odpovídá za splnění úkolů v domluveném rozsahu a čase definovaných na schůzce pracovního týmu, které směřují na Zadavatele.  Garant je odpovědný za přípravu potřebných podkladů a znalostí na schůzku (tj. je připraven na jednání dle avizované agendy schůzky pracovního týmu).  Garant oblasti odpovídá za přenos rozhodnutí o způsobu řešení požadavků jednak na akceptační tým a na klíčové uživatele, jednak na všechny koncové uživatele příslušné části systému (příprava na zkušební a rutinní provoz).  Účastní se školení klíčových a koncových uživatelů. Garant věcné oblasti musí mít dostatečnou pravomoc rozhodovat o funkcionalitě systému pro danou oblast a dostatečnou pravomoc prosadit akceptovaný systém do užívání. Garant věcné oblasti je členem akceptačního týmu Zadavatele.

5.1.5.7 Klíčoví uživatelé Klíčoví uživatelé jsou garantem věcné oblasti nebo vedoucím projektu Zadavatele vybraní budoucí koncoví uživatelé, kteří jsou pro své znalosti věcné problematiky a zkušenosti s příslušnými oblastmi řešení zapojeni do projektu:    

Jako členové pracovních týmů se účastní analýzy systému a na testování v různých fázích projektu. Jako členové akceptačního týmu se účastní akceptace předávaných dokumentů a akceptačního testování. Vybraní klíčoví uživatelé jako interní školitelé/lektoři. Klíčoví uživatelé mohou být i zástupci dodavatelů interních IS Zadavatele

5.1.5.8 Specialista pro bezpečnost Specialista pro bezpečnost je role Dodavatele. Jedná se o specialistu pro oblast bezpečnosti informačních systémů a odpovídá za ověření, zda návrh systému z hlediska bezpečnostních aspektů splňuje bezpečnostní normy a předpisy definované Zadavatelem. Má dohled nad implementací bezpečnostních prvků systému. Specialista pro bezpečnost je dle potřeby členem různých pracovních týmů projektu.

5.1.5.9 Architekt/analytik řešení Architekt/analytik řešení je odpovědná role Dodavatele. Navrhuje věcnou koncepci budoucího systému, koordinuje práci analytického týmu a tvorbu analytických výstupů, analyzuje a následně formalizuje požadavky Zadavatele. Odpovídá primárně za globální analýzu požadavků a aplikaci jejích závěrů do funkční specifikace, návrhu a implementace. Garantuje odbornou znalost a připravenost jednotlivých analytiků účastnících se jednání jednotlivých pracovních týmů. Podílí se na návrhu architektury systému v návaznosti na koncepci a funkční specifikaci. Navrhuje agendy schůzek pracovních týmů, jejich souslednost a specifickou součinnost členů těchto týmů.

5.1.5.10

Specialista – technolog IT

Specialista – technolog IT je role týmu Dodavatele, odpovědná za technologickou architekturu řešení, za detailní návrh a za dohled na implementaci systému. Může být dle potřeby členem pracovních týmů.

142 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Specialista – technolog IT odpovídá za návrh systému na základě požadavků Zadavatele. Při návrhu architektury detailně spolupracuje zejména s vedením IT Zadavatele, garanty věcné oblasti a s technickými pracovníky odpovědnými za oblast provozu a bezpečnosti IT za Zadavatele. Specialista – technolog IT odpovídá za koordinaci práce konzultanta pro bezpečnost a programátorů a řídí vývojové práce.

5.1.5.11

Specialista pro rozhraní na externí IS

Specialista pro rozhraní na externí IS je role týmu Dodavatele, odpovědná za analýzu, návrh struktury a formy, za dohled nad realizací a testování externích rozhraní. Aktivně spolupracuje zejména s vedením IT Zadavatele, garanty věcné oblasti a s technickými pracovníky odpovědnými za oblast provozu a bezpečnosti IT a hlavně se zástupci externích subjektů, s jejichž aplikacemi bude systém komunikovat. Může být dle potřeby členem pracovních týmů.

5.1.5.12

Školící expert

Školící expert je odpovědná role Dodavatele. Je odpovědný za přípravu a realizaci školení pro uživatele systému (administrátory a obsluhu) a pro vedoucí pracovníky Zadavatele, pracujícími s reporty a statistickými výstupy. Zpracovává připomínky z jednotlivých školení jako zpětnou vazbu pro rozvoj aplikace. Dle potřeby se účastní funkčního a akceptačního testování systému.

5.1.5.13

Analytik

Analytik je odpovědná role Dodavatele. Je vedoucím nebo členem pracovních týmů za stranu Dodavatele. Je odpovědný zejména za přípravu a koordinaci schůzek pracovních týmů (z pohledu Dodavatele) a zapracování závěrů a výsledků analýzy do výstupů projektu. Zpracovává zápisy z jednání pracovních týmů, které také za Dodavatele následně potvrzuje. Zpracovává připomínky z oponentury jednotlivých výstupů.

5.1.5.14

Programátor (implementátor řešení)

Programátor odpovídá za realizaci (implementaci) řešení v jednotlivých vrstvách aplikace, za jeho unit testy a za nasazení do testovacího a provozního prostředí. Je dle potřeby členem různých pracovních týmů projektu.

5.1.5.15

Tester

Tester odpovídá za interní testování na straně Dodavatele. Je dle potřeby členem různých pracovních týmů projektu.

5.1.5.16

Specialista Zákaznické podpory (Help-Desk)

Specialista zákaznické podpory odpovídá za poskytování služby zákaznické podpory (Help-Desk).     

Provádí zákaznickou podporu (Help-Desk) pro Zadavatele. Spolupracuje na optimalizaci provozu služby Help-Desk. Navrhuje a podle schváleného návrhu provádí nastavení a konfiguraci SW pro Help-Desk Provádí pravidelné reporty ze SW nástroje zákaznické podpory (přehled incidentů a změn) Monitoruje průběh řešení požadavků na podporu.

5.1.5.17

Administrátor serverové infrastruktury

Administrátor serverové infrastruktury je role týmu Dodavatele, odpovědná provoz serverové infrastruktury, za její profylaktické kontroly a dohled nad výkonnostními parametry serverové infrastruktury. Na základě požadavků z helpdesku řeší případné problémy, které nejsou řešitelné na úrovni Specialisty Zákaznické podpory.

143 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Jednotlivé projektové role může zastávat 1 konkrétní pracovník, některé role naopak zastává více pracovníků.

5.1.6 Metodika vývoje SW Metodika vývoje software řídí životní cyklus vývoje systému. Níže je uveden příklad takovéto metodiky pro vývoj aplikačního software. Metodika je založena na principech definovaných standardem ISO/IEC 12207. Uvedený standard definuje tři skupiny procesů, které probíhají v rámci životního cyklu informačního systému: základní, pomocné a organizační. Pro dodávku jsou podstatné především základní procesy vývoje. Etapy realizace systému jsou znázorněny na následujícím schématu. Globální analýza a návrh probíhá pro celý systém, další etapy vždy pro jednotlivá plnění Projektu (moduly/přírůstky).

Obrázek 25: Etapy životního cyklu vývoje SW

Zároveň budou systémy vyvíjeny tak, aby výsledné produkty byly principiálně založené na SOA. Metodika vývoje je proto rozšířená o SOA principy vycházející z metodiky IBM RUP/SOMA© , jejíž schéma je uvedeno na následujícím obrázku.

144 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

Obrázek 26: RUP/SOMA framework ©

Pro zajištění kvality metodika zahrnuje použití V-modelu. Na levé straně schématu ve směru shora dolů jsou popsány aktivity, jejichž pomocí je upřesňováno zadání. Na pravé straně jsou pak ve směru zdola nahoru uvedeny příslušné úrovně testování, které mají ověřit, zda požadavky pro danou úroveň jsou splněny. Dno písmene pak reprezentuje vývoj dodávky. Množiny vstupních a výstupních požadavků spolu se závěrečnou revizí zajišťují, že výsledná dodávka splňuje požadavky zadání a Zadavatele tak, jak byly dohodnuty a zakotveny při analýze systému.

Obrázek 27: V-model při vývoji SW

V následujícím textu je stručně popsán obsah etap vývoje systému.

5.1.6.1 Globální analýza a návrh Hlavním cílem globální analýzy a návrhu (GAN) je specifikace, zakotvení a pochopení hlavních požadavků na systém. Účelem fáze je pak popsat systém na základě požadavků do takové podrobnosti, aby bylo možné potvrdit technologickou a aplikační architekturu budoucího SW systému, potvrdit případně upravit návrh realizačních částí

145 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ (modulů, přírůstků) jako samostatně realizovatelných částí a specifikovat poskytované služby a to jak služby samotného systému, tak služby pro integraci do prostředí IS/ICT Zadavatele. Hlavními výstupy GAN jsou zejména:   

Analýza stávajícího stavu IS/ICT prostředí, do kterého bude systém implementován; Přehled procesů souvisejících s předmětem zadání a jejich aktérů (odpovědných rolí); Definice funkčních a nefunkčních (kvalitativních) požadavků (resp. vyjasnění a upřesnění požadavků ze zadávací dokumentace) na systém a definice základních omezení požadovaného systému, určení jejich priorit a zpřesnění odhadu náročnosti realizace – katalog požadavků;  Dopracování návrhu koncepce a architektury systému (revize návrhu z nabídky);  Návrhu zajištění bezpečnosti systému;  Identifikace služeb, jejich seznam, stručný popis a hierarchie;  Požadavky na organizační a technické zajištění systému na straně Zadavatele;  Vymezení realizačních přírůstků a jejich vazeb;  Potvrzení anebo upřesnění parametrů potřebných technologií;  Plán testů. Klíčovým výstupem globální analýzy je katalog požadavků na systém, na jehož zpracování se budou aktivně podílet jednotlivé pracovní týmy dle svého zaměření. Katalog požadavků je ověřen a schválen v připomínkovém řízení. Za schválení požadavků pro jednotlivé věcné oblasti a za schválení specifikace požadavků příslušné věcné oblasti odpovídá garant věcné oblasti, pokud není na úrovni VVP stanoveno jinak. Katalog požadavků daný funkční specifikací je jednoznačným a úplným zadáním pro následné vývojové etapy projektu. Změny v požadavcích budou podléhat procesu změnového řízení.

5.1.6.2 Detailní analýza a návrh Cílem fáze Detailní analýza a návrh (DAN) je detailně specifikovat modul/přírůstek dodávaného aplikačního SW, a to do takové úrovně podrobnosti, kdy je možné kvalifikovaně naplánovat a zahájit jeho implementaci. Provádí se pro každý modul/přírůstek definovaný v GAN. Výsledkem detailní analýzy je podrobný model a specifikace požadovaného systému. Zahrnuje:   

Podrobnou specifikaci případů užití (use case) a nefunkčních požadavků na SW systém (webový portál); Vymezení aktérů (uživatelů, aplikačních rolí) pro jednotlivé případy užití; Specifikace služeb zahrnující: o Výběr služeb, které budou implementovány o Zdokumentování vzájemných závislostí služeb o Návrh kompozitních služeb (včetně vnitřní logiky zpracování)  Detailní logický datový model systému;  Detailní specifikaci podmínek a pravidel zpracování;  Specifikace návrhu testů a testovacích scénářů. V detailním návrhu se vytváří detailní popis řešení systému. Popis řešení obsahuje především:    

Detailní návrh softwarových komponent, logického a fyzického datového modelu a datových struktur; Definici jednotlivých technických částí a mapování SW na fyzická zařízení; Detailní návrh rozhraní mezi jednotlivými částmi systému a popis externích rozhraní Detailní návrh jednotlivých služeb o Nefunkční požadavky na jednotlivé služby o Návrh zpráv používaných danou službou o Případně návrh stavového chování služby

5.1.6.3 Vývoj systému, implementace, nasazení Implementace probíhá iterativně spolu resp. těsně s detailním návrhem a tvorbou prototypu a jeho částí. V průběhu implementace se konfigurují předpřipravené komponenty aplikace, generují a konfigurují části SW, programují se jednotlivé navržené metody a rozhraní. Navržený datový model se implementuje formou skriptů či jiných

146 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ výkonných struktur tak, aby bylo zaručeno jeho opakovatelné znovuvytvoření. V případě potřeby se zároveň vytvářejí pomocné implementační části sloužící k vytvoření testovacího prostředí. Současně se implementují testovací data a implementují automatizované testy. S migrací historických dat řešení nepočítá.

5.1.6.4 Testování a pilotní provoz Příprava na testování systému a dodávaných modulů probíhá paralelně s tvorbou vlastního aplikačního SW, služeb a rozhraní na interní systémy Zadavatele. Součástí GAN je vytvoření plánu testů, součástí DAN je specifikace testů a testovacích scénářů, součástí fáze programování je implementace testů (včetně přípravy testovacích dat). Obsahem fáze testování je provádění testovacích kampaní a následně pilotní provoz. Vyhodnocení testovací kampaně je podkladem pro akceptační testování. Splnění akceptačních kritérií je podkladem pro akceptaci systému Zadavatelem a impulsem pro zahájení dvouměsíčního pilotního provozu. Vyhodnocení pilotního provozu včetně kontroly odstranění zjištěných incidentů a splnění akceptačních kritérií je Zadavatelem potvrzen závěrečný akceptační protokol. Hlavní výstupy týkající se testování systému jsou:          

Aktualizovaný plán testů; Testovací případy (návrh testů – funkčních, výkonnostních, zátěžových, akceptačních); Testovací data; Přehled zjištěných vad; Otestovaný ASW; Protokol testovací procedury; Protokol testovací kampaně; Akceptační protokol před zahájením pilotního provozu Protokol o vyhodnocení průběhu pilotního provozu Závěrečný akceptační protokol.

5.1.6.5 Školení Pro bezproblémové a efektivní využívání systému je nutné provést prezenční školení klíčových uživatelů (budoucích školitelů ostatních uživatelů) a administrátorů. Současně je vhodné vytvořit e-learningový kurs pro potřeby koncových uživatelů portálu. Následující školicí a konzultační služby jsou provedeny v rámci zaškolení při implementaci a zavedení systému. Jako cílové skupiny pro školení jsou obvykle identifikovány tyto skupiny:  Klíčoví uživatelé, budoucí školitelé;  Administrátoři/správci systému;  Administrátoři/správci připojených externích systémů. Je doporučeno provádět průběžné doškolování školitelů a konzultace v průběhu užívání systému.

5.1.7 Návrh realizačního projektu Pro návrh realizačního projektu je vhodné použít Metodu logického rámce (Logical Framework Method), běžně využívanou při přípravě projektů v rámci EU. Logický rámec shrnuje informace týkající se základních parametrů projektu: 

Cíl – obecnější PROČ? Cíl vyššího stupně, k jehož dosažení je projekt jen jednou z předběžných podmínek.



Účel/dílčí cíle – PROČ? Čeho hodláme projektem dosáhnout, „opravdový či zásadní“ motiv a vliv projektu.



Výstupy – CO? Specifické výstupy, dosažené řízením jednotlivých částí. Co se skutečně zrealizovalo.



Aktivity – JAK?

147 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Činnosti patřící k jednotlivým výstupům, které mají být vykonány spolu se zdroji, které musí být dostupné pro vytvoření těchto výstupů.

5.2

Návrh systému Quality Assurance přístupu při implementaci projektu

Tento návrh předpokládá zajištění Quality Assurance formou využití systému testování při implementovaného software. I v případě že se nejedná o dodávku software, měly by být procesy analogicky aplikovány i na dodávky například hardware či jiných služeb. Základ systému testování tvoří Metodika testování aplikačního software (ASW), protože popisuje základní prvky a postupy systému testování jako jednoho ze základních prostředků pro zajištění kvality ASW. Níže je uveden příklad obsahu takovéto metodiky.

5.2.1 Kategorie testů Jedná se o výčet kategorií, které jsou v rámci Systému testování použity bez ohledu na jejich charakter. Slouží ke sjednocení používaných pojmů. Nejedná se o výlučné kategorie, například Akceptační testování se typicky skládá z funkčních systémových testů, integračních testů případně i dalších testů podle potřeby.

5.2.1.1 Druhy testů podle rozsahu 5.2.1.1.1 Unit testování Jedná se o testování funkčně ohraničených elementárních jednotek (unit) programového kódu. Touto jednotkou (unitou) je funkce, procedura, a nebo třída. Unit testování představuje testování ASW na nejnižší úrovni a je prováděno ve dvou fázích:  ověření technické správnosti podle specifikace – prováděno programátorem.  ověření věcné správnosti podle specifikace – prováděno testerem. Odpovědnost za správnost implementace podle specifikace má programátor, tester provádí pouze ověření.

5.2.1.1.2 Systémové testování Představuje testování celého systému. Systémem rozumíme předmět obchodního případu, tedy dodávaný informační systém. Ten může obsahovat pouze ASW (aplikaci), případně i technologickou infrastrukturu.

5.2.1.1.3 Testování sestavení Je součástí systémového testování a slouží k testování sestavení jednotlivých jednotek (unit) do větších celků. Podstatou testování sestavení je prokázání funkčnosti při vzájemné komunikaci mezi jednotkami. Testy jsou prováděny ihned po testování jednotek. Testování sestavení se zpravidla provádí jako inkrementální, kdy dochází k postupnému začlenění nových jednotek do testů.

5.2.1.1.4 Integrační testování Otestování zasazení ASW do okolního prostředí v reálném provozu. Integrační testy se dělí na testy kompatibility aplikací mezi sebou a testy kompatibility ASW s operačními systémy a ostatními částmi technologické infrastruktury. Integrační testy se zpravidla provádějí v rámci akceptačních testů v prostředí Zadavatele. Důvodem je technologická obtížnost simulace prostředí Zadavatele u Dodavatele a dále, že potřebné informace jsou mnohdy nedostupné z bezpečnostního hlediska. Pokud to podmínky projektu umožňují, měly by integrační testy být prováděny i v předakceptačních fázích testování v prostředí Zadavatele nebo v odpovídajícím simulovaném. Integrační testy mohou mít vazbu na zátěžové testy - současná zátěž databázového engine atd….

148 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

5.2.1.2 Druhy testů podle testované oblasti 5.2.1.2.1 Funkční testování Je testování funkčnosti, která je od aplikace požadována. Hledají se rozdíly aktuální funkcionality aplikace proti funkční specifikaci v analytické a návrhové dokumentaci.

5.2.1.2.2 Zátěžové testování Je založeno na testování, při kterém je testovaná aplikace postupně zatěžována až do doby, kdy dojde k její eventuální havárii, případně zátěž dosáhne předem určené maximální hodnoty. Cílem testů je zjistit chování testované aplikace v krizových situacích a nalézt její teoretické limity nebo ověřit maximální předpokládanou propustnost. Při tomto typu testování je důležité zajistit dostatečnou diagnostickou podporu pro snadnější odhalení příčiny možného pádu testované aplikace.

5.2.1.2.3 Testování bezpečnosti Představuje testování databázových a síťových aplikací, kdy je testováno zabezpečení dat proti případnému zneužití. To může být jak náhodné, provedené zásahem uživatele, tak cílené, provedené úmyslně za účelem zneužití takto získaných informací. Testuje se autentifikace, autorizace, penetrace, zneužití apod.

5.2.1.2.4 Testy ergonomie Testuje se přívětivost uživatelského rozhraní, vhodnost rozložení ovládacích prvků, konzistence UI a dostatečně rychlá odezva na uživatele.

5.2.1.3 Druhy testů podle účelu 5.2.1.3.1 Akceptační testování Cílem akceptačních testů je ověření funkcí vlastností ASW garantovaných Zadavateli. Účelem akceptačních testů není tedy oprava chyb nýbrž konstatování způsobilosti k předání Zadavateli. Podle V-modelu (viz kap. 5.2.2) se při akceptačních testech vychází z katalogu uživatelských požadavků (KUP) a požadavků specifikovaných v analytických a návrhových výstupech projektu. Celkový rámec případně i konkrétní obsah testů je určen zvláštní specifikací, která vychází z případů užití, odvozených z evidence požadavků v KUP, a je předmětem ujednání mezi Dodavatelem a Zadavatelem. Model případu užití nebo jeho analytická obdoba je úplným přehledem funkčnosti. Akceptační testy se obvykle provádějí v prostředí Zadavatele a ve spolupráci s ním. Skladba konkrétních testů podmiňujících převzetí systému by měla vytvářet odpovídající obraz o funkcích systému a umožňovat tak jeho reálné převzetí.

5.2.1.3.2 Regresní testování Regresní testování je používáno pro ověření, zdali se při opravě chyb nepoškodilo něco jiného, co již předtím fungovalo. Je vhodné pro kontrolu, zda nebyla úpravou kódu ovlivněna stávající funkčnost testované aplikace. Principem regresního testování je provést úplnou sadu testů, které byly v minulosti na příslušném modulu nebo funkci v ASW prováděny. Do regresního testování lze zapojit nejenom funkční testování, ale i ostatní druhy testů. Regresní testování je nutné proto, aby se nezapomínalo na skutečnost, že zejména u složitých řešení změna v části kódu většinou generuje změny i „jinde“ – zejména ve stresových situacích takto vznikají velké problémy.

5.2.2 Procesní model Principy testování u Dodavatele se budou odvíjet od základního modelu testování softwaru, který představuje tzv. „V-model“. Uvedený model schématicky popisuje základní souvislosti mezi vývojovými aktivitami na straně jedné a testovacími aktivitami na straně druhé. Procesní model obsahuje dvě větve, které společně vytvářejí symbol ve tvaru písmene „V“. Levá popisuje vývojové aktivity a je řazena chronologicky shora dolů. Pravá popisuje testovací aktivity s chronologickým řazením zdola nahoru. Vodorovné šipky ukazují, která vývojová aktivita je podkladem pro kterou testovací aktivitu. Model je třeba vnímat jako pomůcku; neznázorňuje kauzální vztahy – jedná se o orientační znázornění vztahu mezi vývojovými a testovacími pracemi.

149 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Vývojová větev začíná definováním požadavků na vyvíjený software v rámci Globální analýzy a návrhu (GAN), Detailní analýzy a návrhu (DAN). Všechny uvedené dokumenty vycházejí z interní metodiky. Posledním krokem vývojové části procesního modelu je implementace zdrojového kódu. Testovací aktivity jsou v uvedeném procesním modelu rozčleněny do čtyř základních úrovní. Jsou jimi Unit testování, Systémové testování, Integrační testování a Akceptační testování. Použití tohoto přístupu přináší řadu výhod. Není nutné s přípravou testů čekat až na dokončení implementace zdrojového kódu. Ty fáze testování, které nejsou závislé na implementaci kódu, je možné navrhovat již v úvodních etapách samotného vývoje softwaru. Tím, že lze specifikovat jednotlivé testovací případy již během návrhu aplikace, je možné včas odhalit potenciální problémy s podkladovou dokumentací. Předpokladem pro úspěšnost tohoto postupu je, že v rámci každé analyticko/vývojové fáze bude vždy specifikováno provádění příslušných testů. Např.: v rámci specifikace požadavků bude zároveň jasně uvedeno, jakým způsobem bude provedeno jejich ověření a jaká jsou akceptační kritéria.

custom V-model Požadavky

Akceptační testy

Globální analýza a návrh

Integrační testy

Detailní analýza a návrh

Implementace

Systémové testy

Unit testy

Obrázek 28 - V-model

5.2.2.1 Procesy Systému testování Procesy systému testování jsou odvozeny od činností vykonávaných v průběhu životního cyklu každého obchodního případu a v průběhu životního cyklu ASW. Na následujícím schématu je zobrazena vazba procesů testování na jednotlivé činnosti v rámci přípravy a realizace projektu tvorby ASW.

150 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ act Procesy systému testov ání

Definice proj ektu

Tv orba nabídky

Plánov ání proj ektu

Jednání o smlouv ě

Uzav ření proj ektu

Realizace proj ektu

Úv odní studie

«proces» Tv orba Konceptu testů

GAN

DAN

«proces» Tv orba Plánu testů

«proces» Specifikace Náv rhu testů

«proces» Implementace testů

Implementace

Akceptace

Prov oz a údržba

«Krok procesu» Prov ádění testov ací kampaně

«proces» Vyhodnocení testov ací kampaně

«proces» Implementace testů

Obrázek 29 - Procesy Systému testování

5.2.2.1.1 Fáze životního cyklu ASW V souladu s metodikou vývoje ASW jsou definovány následující fáze životního cyklu realizace ASW:      

Úvodní studie - Posouzení realizovatelnost příslušné části IS, stanovení koncepce a přístupu k vývoji. Globální analýza a návrh ASW (GAN) Detailní analýza a návrh ASW (DAN) Implementace (programování a interní testování) ASW Akceptace Zadavatelem Provoz a údržba - nasazení do provozu u Zadavatele

Od těchto fází, resp. procesů se odvíjí vlastní procesy systému testování. Ty jsou uvedeny v obdélnících s oblými rohy a jsou dále rozpracovány v následujících kapitolách. Shora uvedený diagram je schématickým zobrazením, které postihuje typické závislosti ASW a jeho testování. V reálné situaci lze testovat přírůstky nebo moduly ASW jako samostatné ASW. Každý takto definovaný ASW může mít vlastní plán a implementaci testů. Samostatným ASW v tomto smyslu může být i fáze Provoz a údržba. Testování ASW se již tedy připravuje paralelně s tvorbou vlastního ASW, ač se na první pohled zdá, že testování je vždy až na konci. Během všech fází životního cyklu je třeba myslet na testovatelnost vyvíjené aplikace, je na to třeba dbát hlavně ve fázi implementace.

5.2.2.2 Tvorba Konceptu testů Koncept testů je úvodním dokumentem při provádění testovacích prací. Jeho tvorba spadá do fáze předprojektové přípravy. Tvorba konceptu testů se skládá z následujících činností:    

Specifikace předpokládaných požadavků na testovací práce Posouzení schopnosti splnit dané požadavky Stanovení požadované úrovně kvality Vytvoření konceptu návrhu testovacího prostředí (viz Kapitola 5.2.5)

151 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ sd Kontext tv orby konceptu testů

Vedoucí tester

«Vytváří»

«dokument» Věcná specifikace řešení (Poptáv ka, nabídka)

«proces» Tv orba Konceptu testů

«dokument» Koncept testů

«dokument» Metodika testov ání

Obrázek 30 - Proces Tvorba Konceptu testů

5.2.2.2.1 Koncept testů Dokument specifikuje, jaké testy ASW budou v rámci realizace nabízeného projektu prováděny a v jakém rámcovém rozsahu. Slouží jako podklad pro stanovení požadavků na zdroje pro testování ASW v rámci projektu. Dokument je dále revidován v průběhu smluvních jednání. Na základě jejich výsledků je upřesněn rozsah testovacích kapacit a případně revidován rozsah a skladba plánovaných testů. Samostatný dokument není povinný; může mít podobu úpravy textů ve smluvní specifikaci.

5.2.2.3 Tvorba plánu testů Cílem plánování testovacích prací je zjistit jejich organizaci, opakovatelnost, sledovatelnost a prokazatelnost. Na základě uzavřené smlouvy a Konceptu testů jsou prováděny následující činnosti:  Studium katalogu požadavků, smlouvy, analytických dokumentů  Stanovení projektových standardů  Určení typů prováděných testů  Stanovení konečného rozsahu testů  Sestavení testovacího týmu  Stanovení sledovaných parametrů kvality a způsobu vyhodnocení  Návrh způsobu evidence a řešení chyb  Tvorba časového plánu provádění testů  Přezkoumání plánu testů V rámci Stanovení projektových standardů je nezbytné definovat zejména:    

Postupy v rámci provádění testovacích prací Projektové role a jejich přiřazení Nástroje, používané pro testovací práce Návrh testovacího prostředí (viz Příloha č. 1)

152 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  Typy dokumentů, jejich strukturu a formu (výstupy z logů, MS Word apod.) Tyto projektové standardy budou postupně nahrazeny standardy celofiremními.

sd Koncept tv orby plánu testů

Vedoucí tester

Vedoucí proj ektu

«Vytváří»

«schvaluje»

Vedoucí programátor «schvaluje»

«dokument» Koncept testů «proces» Tv orba Plánu testů

«dokument» Plán testů

«dokument» Smlouv a «dokument» Metodika testov ání

Obrázek 31 - Proces Tvorba Plánu testů

5.2.2.3.1 Předpoklady pro vytváření plánu testů Tvorba plánu testů vyžaduje následující předpoklady, které jsou uvedeny ve Smlouvě nebo Konceptu testů:    

znalost požadavků na aplikaci znalost rizik znalost použité technologie práce s daty přidělení zdrojů pro provádění testů (čas, lidé, technika)

5.2.2.3.2 Přezkoumání plánu testů Po sestavení plánu je nutno validovat jeho znění:    

Schválení vypracovaného plánu VP a vedoucím programátorem. U akceptačních testů schválení na straně Zadavatele. Případná úprava plánu testů Potvrzení rozsahu a pokrytí požadavků testy Ověření zajištění zdrojů

5.2.2.3.3 Plán testů Šablona plánu testů určuje strukturu a popis náplně jednotlivých kapitol. Plán testů tvoří základní dokument implementace testování do projektu vývoje ASW. Jedná se o povinný dokument, pokud není v koncepci testů výslovně uvedeno, že se plán testů nebude vytvářet. Obsah plánu testů: 1. 2.

požadavky na lidské zdroje pro testování požadavky na materiální zdroje pro testování (HW, SW, testovací pracoviště, nástroje...)

153 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 3. organizační struktura testování 4. definice odpovědností a pravomocí účastníků testování 5. časový plán testování (harmonogram)povinně obsahuje milníky, navazující na plán projektu) 6. sledované klíčové atributy ASW 7. typy prováděných testů 8. rozpracován do testovacích případů 9. způsob vedení testovací dokumentace 10. způsob sledování a řešení chyb Podklady pro plán testů: 1. katalog uživatelských požadavků 2. katalog systémových požadavků 3. popis aplikace Z plánu testů musí plynout: 1. jaké části aplikace se budou testovat (co?) 2. jaké typy testů se budou provádět 3. testovací případy K čemu přihlížet: 1. k ověření klíčových požadavků na systém 2. ke kritickým částem aplikace podle analýzy rizik 3. stupeň pokrytí uživatelských požadavků testy 4. provádět "negativní" testy .... data mimo povolený rozsah 5. komplexnější testy .... větší šance odhalit chyby aplikace

5.2.2.4 Specifikace Návrhu testů Návrh testů obsahuje množinu testovacích případů pro daný ASW. Jeho příprava se skládá z následujících činností:        

Studium Plánu testů a DAN Upřesnění postupu testů Identifikace jednotlivých funkcí / případů užití (UC) a určení testů s nimi spojených Návrh příslušných testovacích případů Stanovení kritérií pro splnění / nesplnění testů Zapracování evidence a řešení chyb do testovacích případů Vyřešení dodání testovacích dat či jejich tvorba Návrh testů pro ostatní požadované vlastnosti systému (nejen pro funkce/UC), které jsou součástí zadání

154 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ sd Kontext specifikace Náv rhu testů

Vedoucí analytik

Náv rhář testů «Vytváří»

«schvaluje» «dokument» Náv rh testů

«dokument» Plán testů «proces» Specifikace Náv rhu testů

«dokument» DAN

«sestava» Testov ací data

«dokument» Metodika testov ání

Obrázek 32 - Proces Specifikace Návrhu testů

5.2.2.4.1 Návrh testů Dokument Návrh testů upřesňuje postup testů, identifikovaný v Plánu testů, identifikuje jednotlivé funkce, popsané v návrhu, a určuje s nimi spojené testy. Dále identifikuje testovací případy a testovací scénáře, které jsou pro zajištění testů potřeba, a stanovuje kritéria pro splnění a nesplnění testů (ANSI/IEEE 829). Dokument rozpracovává plán testů projektu a zaměřuje se více na věcný obsah provádění testů. Dokument je povinný pokud není v koncepci nebo plánu testů výslovně uvedeno, že se nebude vytvářet.

Obsah Návrhu testů 1. 2. 3. 4. 5. 6. 7.

identifikátor Návrhu testů testované funkce ASW popis obecného postupu při testování funkcí identifikace testových případů upřesnění způsobu dokumentace testů kritéria pro splnění/nesplnění upřesnění sledování a řešení chyb

5.2.2.4.2 Zásady pro testovací případy   

testy musí být opakovatelné všechny údaje musí být jednoznačné tester musí být schopen po každém provedeném kroku rozhodnout, zda byl úspěšný, nebo nikoliv

5.2.2.4.3 Testovací scénář Testovací scénář popisuje veškeré kroky, nezbytné pro ovládání systému a pro vykonání určených Testových případů v rámci realizace příslušného návrhu testů (ANSI/IEEE 829).

155 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ Soubor testovacích případů včetně určení jejich pořadí. Vytváří se pro daný typ testů (funkční, systémové, zátěžové) a určuje jaké testy a v jakém pořadí budou vykonávány. Dokument není povinný. Obsah testovacího scénáře: 1. 2. 3. 4.

Identifikátor Účel Zvláštní požadavky Kroky testovacího scénáře a) Příprava b) Zahájení a zahájení c) Provedení d) Měření výsledků e) Vyhodnocení a ukončení (úklid)

5.2.2.4.4 Testovací případ Předpis provedení jednoho testu, který slouží zpravidla k ověření jednoho případu užití. Obsahuje postup provádění testu, vstupní data a očekávané výstupy. Jeden TP může obsahovat více variant vstupních dat a jim odpovídajících očekávaných výsledků. Testovací případ dokumentuje skutečné hodnoty vstupů spolu s očekávanými výsledky. Testovací případ popisuje také veškerá případná omezení testovacího scénáře, které vyplývají z tohoto konkrétního testovacího případu. (ANSI/IEEE 829) Povinný dokument. Obsah testovacího případu: 1. 2. 3. 4. 5. 6.

Identifikátor – jednoznačné označení TP Testovaná položka (funkce, modul, jednotka) Specifikace vstupů Specifikace výstupů Požadavky na prostředí Vzájemné závislosti testovacích případů

5.2.2.4.5 Testovací procedura Podrobný popis kroků, které tester musí provést, aby provedl testovací případ. Jedná se o rozpracování testovacího případu do podoby „kuchařky“. Dokument je nepovinný

5.2.2.4.6 Testovací data Soubor údajů nezbytných pro provádění testů. Tvoří je veškeré vstupy nutné pro vykonání testovacího případu, například mezní hodnoty testovaných atributů. U hodnotových vstupů je zde uvedena přímo hodnota (případně i tolerance). Ostatní vstupy, jako jsou např. soubory, jsou identifikovány jejich jménem. Pro provádění testovací procedury se používá sada testovacích dat.

5.2.2.5 Provádění testovacího scénáře Při provádění testů jsou prováděny pro každý test následující činnosti:   

Průchod testovacím scénářem Zaznamenávání výsledků testu Kontrola oprav zjištěných chyb

156 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 

Dokumentování průběhu testu

sd Kontext provádění testů

«dokument» Testovaný ASW

Tester

Vedoucí Programátor Vedoucí tester programátor «Spolupracuje na» «Spolupracuje na» «provádí»

«dokument» Návrh testů

«dokument» Otestovaný ASW

«Odpovídá za»

«Krok procesu» Provádění testovací procedury

«sestava» Testovací data

«dokument» Protokol testovací procedury

«sestava» Log zjištěných vad «dokument» Metodika testování

Nástroje

Obrázek 33 - Proces Provádění testovacího scénáře

Konkrétní skladba zúčastněných rolí se může lišit podle typu testu a bude uvedena v Plánu testů. Např. u Akceptačních testů je přítomen zástupce Zadavatele.

5.2.2.5.1 Způsob provádění testů  

manuálně – provádí tester bez použití testovacího nástroje. automatizovaně - provádí tester s použitím testovacího nástroje.

5.2.2.5.2 Log zjištěných chyb Soupis zjištěných chyb včetně sledování jejich životního cyklu. Zpravidla udržován v příslušném programovém prostředí.

5.2.2.5.3 Protokol testovacího scénáře Popisuje celkový průběh provádění jednoho testovacího případu. Zaznamenává historii jeho provádění včetně výsledků. Určení povinnosti vytvořit dokument bude uvedeno v Návrhu testů z kterého vyplyne zda je prostor a důvod jej vytvářet. Obsah protokolu: 1. 2. 3. 4. 5. 6.

Identifikace testu Testovací postup Specifikace vstupů Specifikace výstupů Výsledek Datum běhu testu

157 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ 7.

Kdo test provedl

5.2.2.5.4 Sledování a řešení chyb Chyba je zjištěná neshoda mezi skutečným stavem ASW a jeho specifikací. Procesy tvorby ASW jsou složité a náročné, takže potřebnou úroveň kvality výsledného produktu dosáhneme pouze komplexním zapojením všech členů projektového týmu.

5.2.2.5.5 Definice klasifikace chyb Chyby ASW jsou klasifikovány podle závažnosti dopadu na funkčnost, spolehlivost, výkonnost a bezpečnost ASW. Při klasifikaci chyb je směrodatná smluvní specifikace, případě jiná specifikace, dohodnutá s objednatelem. Obecným standardem je následující klasifikace: 1. 2. 3. 4. 5.

chyba typu A: aplikace nebo jednotlivý modul jako celek je mimo provoz nebo je převážná část jeho funkcí nedostupná, chyba typu B: důležité funkce aplikace jsou nedostupné a nelze je vyvolat jiným způsobem nebo je nelze jednoduchým způsobem nahradit organizačním opatřením, chyba typu C: funkční chyby drobnějšího charakteru, výpadky funkcí, které lze vyvolat jiným způsobem. chyba typu D: kosmetické chyby, které nemají vliv na funkčnost ASW, ale pouze na vzhled a ergonomii ASW požadavek na změnu: nejedná se o chybu, ale o změnu v zadání ASW. V Metodice je tato kategorie uvedena z toho důvodu, že klasifikace domnělé chyby může v některých případech, kdy je vytýkané chování vlastností nikoliv chybou, přejít na Požadavek na změnu. Touto kategorií se Metodika dále nezabývá.

5.2.2.5.6 Vliv klasifikace chyb na proces testování Klasifikace chyb také ovlivňuje vlastní testovací proces. Chyby typu „A“ nebo velký počet chyb typu „B“ zastavují v daném okamžiku testovací proces. V plánu testů musí existovat kritéria, podle kterých se dá rozhodnout, kdy se dá v testování dané verze ASW pokračovat, nebo kdy je nutno testování zastavit a vrátit vývoji k opravě nalezených chyb. Je-li v dané verzi "nadkritické" množství chyb, které znemožňuje další efektivní provádění testů, je testování buildu ukončeno. Toto rozhodování má ekonomické dopady.

5.2.2.6 Vyhodnocení testovací kampaně Vyhodnocení testů je prováděno na závěr jednoho testovacího cyklu, ve kterém je proveden celý testovací scénář, tedy provedeny veškeré testovací případy. Jsou při ní prováděny tyto činnosti:    

Zpracování výsledků, tvorba podkladů pro vyhodnocení Vyhodnocení výsledků Sestavení statistik podle stanovených metrik Stanovení závěru testování.

158 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“ sd Vyhodnocení testů

Vedoucí tester

«Odpovídá za» «dokument» Otestov aný ASW

«sestava» Log zj ištěných v ad

«proces» Vyhodnocení testov ací kampaně

«dokument» Protokol testov ací kampaně

«dokument» Protokol testov ací procedury «dokument» Metodika testov ání

Obrázek 34 - Proces Vyhodnocení testů

5.2.2.6.1 Vyhodnocení výsledků      

Způsob vyhodnocení musí odpovídat konkrétním cílům testu, stanoveným v Plánu testů Proces zahrnuje rekapitulaci a souhrnné hodnocení výsledku testů všech provedených testů na základě Protokolů o průběhu testu, případně na základě logu zjištěných vad. Výstupem je Protokol o výsledku testů, viz kapitola 5.2.4. Při vyhodnocení výsledku se používá klasifikace chyb, viz kapitola 5.2.2.5.45.2.2.5.5. Možné metriky a další hlediska vyhodnocení testů jsou uvedeny v Příloze č. 3. Při akceptačních testech protokol testovací kampaně schvaluje Zadavatel (jeho vedoucí projektu)

5.2.2.6.2 Protokol testovací kampaně Závěrečný protokol, soustřeďující informace o výsledku všech prováděných testů a výsledku, s jakým byly provedeny. Protokol je povinný. Obsah protokolu: 1. 2.

3.

sumarizace výsledků testů informace o: a) provedených testech b) výsledcích - neshodách, chybách (testy s chybou v řešení, neproběhly testy, probíhají testy, testy proběhly bez chyb, testy proběhly s vadou nebránící nasazení) c) průběhu oprav d) datu testování hodnocení testů

5.2.3 Testovací tým Účelem testovacího týmu je poskytovat testovací služby pro konkrétní ASW. Služby jsou poskytovány v těchto oblastech:

159 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  Příprava testů  Vlastní provádění testů  Řízení testovacích procesů  Vyhodnocování výsledků testů  Metodická podpora a rozvoj Testovací tým má k dispozici pro zajištění těchto služeb odpovídající testovací a podpůrné nástroje. V následujících kapitolách je uveden popis jednotlivých rolí z hlediska jejich činností, odpovědností a pravomocí. Projektová role určuje využití v daném projektu. V každém projektu musí být definován alespoň vedoucí tester.

5.2.3.1 Vedoucí tester Činnosti:  Soustřeďuje analytické a implementační požadavky pro daný projekt  Vypracovává Plán testů,  Vytváří Protokol testovací kampaně.  Účastní se projektových schůzek,  Komunikuje s ostatními rolemi, skupinami a týmy v rámci projektu,  Podílí se na vykonávání testů. Odpovědnosti:  Je zodpovědný za uplatnění Metodiky testování ASW v projektu.  Je odpovědný VP za správné a účinné provádění testů v projektu  Odpovídá za tvorbu Plánu testů Pravomoci:  Řídí testy přiděleného projektu na základě Metodiky testování ASW.  Za testery schvaluje Protokol o výsledku testů.  Definuje vhodné metriky a statistiky pro vyhodnocení výsledků testů  Úkoluje jednotlivé členy testovacího týmu. Je podřízen: Vedoucímu projektu

5.2.3.2 Návrhář testů Činnosti:  Vypracovává Návrh testů,  Vypracovává testovací scénáře a případy.  Podílí se na přípravě testovacích dat  Podílí se na vykonávání testů. Odpovědnosti:  Zodpovídá za analýzu a Návrh testů ASW v daném projektu. Pravomoci:  Schvaluje Návrh testů. Je podřízen: Vedoucímu testerovi

5.2.3.3 Tester Činnosti:  Vykonává automatické testy a provádí kontrolu jejich výsledků.  Podílí se nebo vykonává ruční testy  Provádí vyhodnocení výsledků ručních testů.  Komunikuje s programátory a analytiky Odpovědnosti:   

Je zodpovědný za implementaci automatických testů ASW podle příslušné dokumentace testů. Je odpovědný za inicializaci testovacích dat pro test. Je odpovědný za provádění testů

160 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  Odpovídá za kontrolu opravy nalezených chyb Pravomoci:  Stanovuje priority prováděných testů  Provádí klasifikaci chyb podle Metodiky Je podřízen: Vedoucímu testerovi

5.2.4 Dokumentace Dokumentace Systému testování se skládá z vlastní Metodiky (tento dokument) a z dokumentů, které jsou popsány dále včetně doporučených osnov. K dokumentům budou k dispozici šablony. Dokumentace je tříděna do tří kategorií: podklady pro provádění testů, dokumentace výsledků testů a metodické pokyny a předpisy, které doplňují tuto Metodiku. Dokumentace, tvořící podklady pro testy a výsledky testů je vytvářena v rámci daného projektu. Je odpovědností VP, aby zajistil vznik a potřebný obsah daných dokumentů.

5.2.4.1 Podklady pro testy 1. 2. 3. 4.

Koncept testů (viz. 5.2.2.2.1) Plán testů (viz. 5.2.2.3.3) Návrh testů (viz. 5.2.2.4.1) Testovací data (viz. 5.2.2.4.6)

5.2.4.2 Výsledky testů 1. 2. 3.

Log zjištěných chyb (viz. 5.2.2.5.2) Protokol testovacího scénáře (viz. 5.2.2.5.3) Protokol testovací kampaně (viz. 5.2.2.6.2)

5.2.5 Testovací prostředí Testovací prostředí slouží k testování ASW před nasazením do provozního prostředí. Musí proto splnit zejména následující nároky: 

co největší podobnost produkčnímu prostředí,



bezpečnost (i testovací prostředí může být na internetu a může se na něm pracovat s kopií ostrých dat).

 s vyváženým poměrem cena / požadovaná podobnost (musíme také pamatovat na ekonomické aspekty) Požadavky na testovací prostředí jsou stanoveny v průběhu tvorby a revize Konceptu testů a upřesněny v Plánu testů. U rozsáhlých projektů by to měl být samostatný dokument – zejména jakmile se rozroste co do obsahu. Za testovací prostředí je zodpovědný vedoucí tester, jeho přípravu může delegovat na provozáře, pokud je taková role v projektu definována.

5.2.5.1 Obecné požadavky a parametry testovacího prostředí Při přípravě testovacích scénářů a dalších činnostech souvisejících s přípravou a prováděním testů je třeba: 1.

2. 3. 4. 5.

individuálně rozhodovat o způsobu využití prostředků testovacího prostředí a) co lze / nelze testovat s využitím VM technologií b) kde je třeba mít prostředí „ušité“ na míru c) kde naopak postačí přibližná podobnost testovacího a cílového prostředí určit (nebo alespoň odhadnout) míru rizika, pokud se z jakýchkoli důvodů testy musí provést na odlišném, nevyhovujícím nebo nedokonalém testovacím prostředí oddělit testovací prostředí od Vývojového prostředí. stanovit náklady na vytvoření testovacího prostředí průběžně sledovat kvalitu a výkonnost testovacího prostředí a plánovat z pohledu budoucího rozvoje

161 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

5.2.5.2 Skladba testovacího prostředí Testovací prostředí musí maximálně odpovídat provoznímu prostředí Zadavatele, t.j.: 1. 2.

3.

5.3

HW část (servery, pracovní stanice, komunikační technologie, periferní zařízení) SW část (záměrně zde není uveden vlastní testovaný ASW) a) Operační systémy a další SW který je součástí prostředí (DB server...) b) Virtualizační SW simulující více počítačů – přitom však využívá společný HW c) SW pro sledování změnového řízení a správu verzí testovaných ASW d) SW pro automatizaci testování (simulátory uživatele, generátory dat...) e) SW pro záznam a vyhodnocení výsledků testů (evidence chyb i úspěšných testů) Podklady pro testování a popis vstupního nastavení a) Verze veškerého SW (operační systém, db server, aplikační server, klienti...) b) Výchozí stav (systémové proměnné, bezpečnostní politiky, adresáře...) c) Vstupní data pro testovanou aplikaci d) Počáteční stav testovaného ASW (konfigurace, stav databáze...)

Návrh systému hodnocení rizik projektu

Systém hodnocení rizik by se měl soustředit nejen na technická rizika, ale i na identifikaci bariér a rizik v rovině technické, sociální, politické a finanční. V případě eHealth se jedná o sociotechnických systém a vzhledem k tomu je nutné při jeho řízení zohledňovat i další aspekty, nejen technický. Návrh systému řízení rizik je podrobně popsán kontextu ostatních aktivit projektu v bodě 5.1.2.4 Řízení rizik.

162 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

6

Komunikační strategie a PR aktivity projektu

Propagace eHealth je pro úspěch celého projektu nesmírně zásadní zejména pro získání obecného povědomí o tom, co to je eHealth a co může přinést jednotlivým aktérům. Jednotlivé aktivity by měly vést k vysvětlení významu eHealth všem zainteresovaným skupinám, každé zvlášť. Cílem je také odbourání obav z negativních vlivů, zejména v oblasti bezpečnosti, ztráty soukromí a všemocného kontrolního nástroje. U seniorů je důležitá nutnost naučit se ovládat běžný počítač s klávesnicí a myší. Vhodným se také jeví vytvoření loga eHealth. Komunikace by měla probíhat pokud možno všemi dostupnými prostředky pro danou zájmovou skupinu. Podrobnosti jsou uvedeny u jednotlivých skupin. Média vhodná pro PR aktivity jsou uvedena u jednotlivých zájmových skupin. Měla by být dále vytvořena Rada projektu, jejíž členové by měli pocházet z různých zájmových skupin napříč zdravotnictvím, včetně zastoupení pacientů. Členům této Rady projektu by měl být pravidelně prezentován aktuální stav projektu. Tento postup by měl vést k zapojení všech klíčových aktérů do procesu budování eHealth a omezit riziko, že tato činnost bude považována za výhradní problém Ministerstva zdravotnictví, který lze využít pro získávání „politických“ bodů. Mělo by vzniknout stav, ve kterém bude eHealth „záležitostí všech“. To samozřejmě nijak nesmí zasahovat do procesů projektového řízení eHealth, které musejí být prováděny dle striktně dané metodiky.

Návrh způsobu komunikace s klíčovými hráči odvětví

6.1 6.1.1

Lékaři

Způsob komunikace s touto konzervativní skupinou by měl maximálně využívat zavedené metody komunikace, které používají například farmaceutické firmy. Při PR činnostech by mělo být aktivně spolupracováno s odbornými společnostmi a jinými sdruženími lékařů. Je nezbytné získat na svou stranu opinion-makery dané skupiny. Návrh vhodných způsobů komunikace:     

Využití odborných konferencí – ideálně na každé větší konferenci by měla být prezentace v rámci hlavního bloku zástupcem Ministerstva Zdravotnictví neb KSRZIS Přímá aktivita „obchodních zástupců“ – přímý kontakt po vzoru farmaceutických firem Vlastní semináře u větších poskytovatelů Využití odborných médií – Zdravotnické noviny, Medical tribune, Tempus medicorum (časopis lékařské komory), konkrétní periodika zaměřená na určitou odbornost Využití odborných online médií a portálů

V písemné podobě lze uvažovat o následujících způsoby propagace:   

Jednoduché příběhy pro jednotlivé hráče Praktické příběhy z doby po eHealth Příběhy presentované důvěryhodnými osobami z řad opinion-makerů dané zájmové skupiny

Klíčová komunikovaná témata by měla být tato:   

Jde pouze o elektronické řešení předávání dokumentace, na kterou už má stejně dle zákona nárok jak jiný ošetřující lékař, tak i samotný pacient Pacient má nárok (až na malé výjimky) na kompletní dokumentaci bez možnosti omezení přístupu lékařem Kartotéku samostatných ordinací nikdo nevytuneluje – každý přístup je logován a za porušení ochrany osobních údajů lze dostat pokutu až 10 mil Kč a trest odnětí svobody 3 roky nepodmíněně

163 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

6.1.2

Pojišťovny

Vzhledem k tomu, že návrh počítá s intenzivním zapojením zdravotních pojišťoven do systému eHealth, měly by zástupci zdravotních pojišťoven hrát významnou úlohu ve výše uvedené Radě projektu. Pro komunikaci pojišťovnami pro potřeby projektu na operativní bázi by měla být využita metoda dvojích pracovních skupin:  

Pracovní skupina odborná - pro společné setkání pracovníků orientovaných na věcnou problematiku, jako je obsah dat Pracovní skupina technická – pro společné setkání pracovníků orientovaných na samotnou technickou stránku věci

Tyto skupiny by měly být složeny ze zástupců všech zdravotních pojišťoven a zástupce Zadavatele, tedy KSRZIS.

6.1.3

Pacienti

Pacienti, tedy skupina osoby, čerpající zdravotní služby, by měly být oslovováni tématem eHealth v ordinacích a čekárnách svých lékařů. To však předpokládá především vysokou motivaci Lékařů, které lze dosáhnout pouze smysluplnými službami, které jim bude eHealth poskytovat. Návrh vhodných způsobů komunikace:    

Letáky do čekáren a lékáren Využití obrazovek v čekárnách a lékárnách, vysílajících reklamu Využití stávajících struktur sdružení pacientů dle diagnózy (diabetici, bechtěrevici, roztroušená skleróza, etc…) Využití komunikačních prostředků pojišťoven, kterými se obracejí na své pojištěnce (časopisy, dopisy, weby, ….)

V písemné podobě lze uvažovat o následujících způsoby propagace:   

Jednoduché příběhy pro jednotlivé hráče Praktické příběhy z doby po eHealth Příběhy presentované důvěryhodnými osobami zejména z řad populárních osobností

Klíčová komunikovaná témata by měla být tato:     

6.1.4

Jakým způsobem pomůže eHealth v léčbě konkrétní nemoci eHealth zajistí omezení lékových interakcí u vašich léků Informace o systému zdravotnictví a vašich zdravotních problémech najdete na Portále Informace o čerpání vašeho zdravotního účtu najdete na Portále Zdravotnická dokumentace je zabezpečena opatřeními na úrovni elektronického bankovnictví

Odborná veřejnost

Aktivity cílené na zástupce nelékařských povolání, zejména na sestry, by měly být stejně intenzivní jako aktivity cílené na lékaře. Způsob komunikace s touto skupinou by měl využívat zavedené metody komunikace, které používají například dodavatelé zdravotnických prostředků. Při PR činnostech by mělo být aktivně spolupracováno s odbornými společnostmi a jinými sdruženími nelékařských pracovníků. Je nezbytné získat na svou stranu opinionmakery dané skupiny. Návrh vhodných způsobů komunikace:   

Využití odborných konferencí – ideálně na každé větší konferenci by měla být prezentace v rámci hlavního bloku zástupcem Ministerstva Zdravotnictví neb KSRZIS Přímá aktivita „obchodních zástupců“ – přímý kontakt po vzoru farmaceutických firem Vlastní semináře u větších poskytovatelů

164 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“  

Využití odborných médií – Zdravotnické noviny, Medical tribune, Sestra, konkrétní periodika zaměřená na určitou odbornost Využití odborných online médií a portálů

V písemné podobě lze uvažovat o následujících způsoby propagace:   

Jednoduché příběhy pro jednotlivé hráče Praktické příběhy z doby po eHealth Příběhy presentované důvěryhodnými osobami zejména z řad odborné veřejnosti

Klíčová komunikovaná témata by měla být tato:  

6.1.5

Sdílení dokumentace pomůže v léčebném procesu snížit administrativu Zdravotnická dokumentace je zabezpečena opatřeními na úrovni elektronického bankovnictví

Laická veřejnost

PR aktivity by se měli zaměřit i na tu část veřejnosti, která je momentálně v produktivním věku a nemá obvykle výrazné zdravotní problémy. Tato skupina obvykle nemá problémy s obsluhou PC a lze na ni působit moderními komunikačními médii typu Facebook či jiné sociální sítě. Významná je tato skupina i z toho důvodu že jde také primárně o daňové poplatníky, kteří v konečném důsledku celý eHealth financují. Návrh vhodných způsobů komunikace:     

Běžná masová média (rozhlas, televize, tisk) Billboardy Online portály typu seznam.cz, centrum.cz a další Sociální sítě Mobilní aplikace zdarma (hry, užitečné nástroje, …)

Klíčová komunikovaná témata by měla být tato:    

6.2

Informace o systému zdravotnictví a vašich zdravotních problémech najdete na Portále Informace o čerpání vašeho zdravotního účtu najdete na Portále Sdílení dokumentace sníží náklady na zdravotní služby Zabezpečení přístupu máte plně ve svých rukou

Návrh dlouhodobé koncepce komunikace včetně vymezení klíčových komunikačních kanálů koncepce

Na všechny skupiny tuto skupinu je nutné po spuštění eHealth Portálu zaměřit PR aktivitu realizovanou přímo na samotném portálu formou online reklamy (bannery, splashscreen, …). Vzhledem k tomu, že je uvažováno v tomto návrhu o Portálu jako o webovém serveru i s redakčním systémem, je určitě jeho využití na místě a na tuto roli by měl být připraven od počátku. Z dlouhodobého hlediska by se měla přesouvat komunikace z masově vedené Ministerstvem zdravotnictví do cílené komunikace vedené zdravotními pojišťovnami, které budou schopné PR aktivity cíli na konkrétní pojištěnce dle jejich profilu. Tyto aktivity by měly být vedeny již dnes běžnými kanály, které používají zdravotní pojišťovny v rámci své komunikace s pojištěnci, například v rámci preventivních programů.

165 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

7 7.1

Rejstříky a seznamy Seznam klíčových zkratek

Zkratka ASW CMÚ ČR HTTP IS KSRZIS MZ NRC NZIS PC SAML SOAP SSL SÚKL ÚOOÚ ÚZIS v.z.p. VZP XML ZP ZZ

Plný text Aplikační software Centrum mezistátních úhrad Česká republika Hypertext Transfer Protocol Informační systém Koordinační středisko pro resortní zdravotnické informační systémy Ministerstvo zdravotnictví Národní referenční centrum Národní zdravotnický informační systém Personal computer (Osobní počítač) Security Assertion Markup Language Simple Object Access Protocol Secure Sockets Layer Státní ústav pro kontrolu léčiv Úřad pro ochranu osobních údajů Ústav zdravotnických informací a statistiky ČR Veřejné zdravotní pojištění Všeobecná zdravotní pojišťovna Extensible Markup Language (Rozšiřitelný značkovací jazyk) Zdravotní pojišťovna Zdravotnické zařízení

166 z 167

Soutěž o návrh „Hospodárné a funkční elektronické zdravotnictví“

8

Přílohy

K tomuto návrhu nejsou žádné přílohy.

167 z 167