ATC kód rozdělen do jednotlivých podskupin (autor WHOCC 2018)

ATC podskupina Název skupiny a příklad

A Alimentary tract and metabolism (1. úroveň, anatomická hlavní skupina) A10 Drugs used in diabetes

(2, úroveň, terapeutická podskupina) A10B Blood glucose lowering drugs, excl. insulins

(3. úroveň, farmakologická podskupina) A10BA Biguanides

(4. úroveň, chemická podskupina) A10BA02 metformin

(5. úroveň, chemická substance)

1.4.2 Riziková oblast – Problematika spotřeby antiinfektiv

Antiinfektivum je taková látka, která brání vzniku, rozvoji či komplikacím z napadení lidského organismu nakažlivými patogeny. Mezi tyto patogeny řadíme bakterie, viry, kvasinky, plísně a parazity. Tyto látky můžeme najít pod písmen J v ATC skupinách (Vitalion 2020).

Mezi velkým problém nejen České republiky, ale celého světa patří vznik a následné šíření kmenů infekčních mikroorganismů, které jsou rezistentní vůči antiinfektivám. Proto vzniklo doporučení Rady EU (2002/77/ES) o obezřetném používání antimikrobních látek v lékařství a Doporučení Rady EU ze dne 9. června 2009 o bezpečnosti pacientů včetně prevence a kontroly infekcí spojených se zdravotní péčí (2009/C151/01) Ministerstvo zdravotnictví ČR na základě Usnesení vlády ČR č. 595/2009 vnikl Národní antibiotický program (dále NAP). NAP vytváří Seznam esenciálních antiinfektiv, které jsou nenahraditelné při léčbě infekcí. Jedním z problémů vedoucí ke vzniku rezistentních kmenů je špatně provedena diagnóza lékařem a následně předepsané antiinfektivum nebo nedostupnost daného antiinfektiva a následné nahrazení širokospektrálním antiinfektivem.

Druhý stav je řešen pomocí Seznamu esenciálních antiinfektiv (SÚKL 2019).

Graf 4 Spotřeba a struktura spotřeby antibiotik u vybraných evropských zemích (SÚKL 2019) Na grafu číslo 2 můžeme vidět spotřebu antibiotik ve vybraných zemích. Státy jižní Evropy mají velkou spotřebu antibiotik oproti Severní Evropě. Česká republika se nachází ve středu ve spotřebě antibiotik.

Graf 5 E.Coli rezistentní k florochinolonům v EU (SÚKL 2019)

Na grafu číslo 3 můžeme vidět výskyt rezistentní bakterie E.Coli. Tato bakterie má vyšší výskyt v jižní a východní části Evropské Unie.

Graf 6 Klebsiella pneumoniae rezistentní k florochinolonům, 3. generace cefalosporinům a aminoglykosidům v EU (SÚKL 2019)

Na grafu číslo 4 můžeme vidět rezistentní bakterie Klebsiella pneumoniae, které se zejména vyskytují v jižní a východní části EU. Česká republika se řadí mezi země s vyšším výskytem rezistentních kmenů bakterie.

Graf 7 Pseudomonas aeruginosa rezistentní k 3 a více antimikrobním skupinám léčiv (piperacilliny, tazobactamy, ceftazidimy, florochinolony, aminoglykosidy, karbapenemy) (SÚKL 2019)

Na grafu číslo 5 můžeme vidět multirezistentní bakterie Pseudmonas aeruginosa, které se zejména vyskytují v jižní a východní části EU. Česká republika se řadí mezi země s vyšším výskytem rezistentních kmenů bakterie.

Graf 8 Spotřeba antibiotik v ČR, náklady spojená se spotřebou antibiotik (Prokeš 2017)

Spotřeba antibiotik v rámci České republiky má vzrůstající trend, i když v posledních letech můžeme pozorovat výkyv směrem dolů. Náklady na léčbu mají klesající trend, který je způsoben regulační politikou na trhu SÚKLem. Lze konstatovat, že ČR nepatří mezi země s extrémně vysokými spotřebami ATB ani s nejhoršími výsledky indikátorů kvality spotřeb. Pozorujeme však řadu nepříznivých trendů, jako je například nadprůměrně vysoká spotřeba makrolidů, narůstající dominance chráněných penicilinů a nežádoucí vzestup spotřeby cefuroximu, což není odůvodněno změnami citlivosti mikrobů na ATB.

To v dlouhodobém horizontu přispěje k nárůstu rezistence mikrobů na ATB a ke zbytečně vysokých nákladů na ATB (Prokeš 2017).

Jednou z cest, jak snížit spotřebu antibiotik, je včasné vyhledání ohniska pacientů a zamezení šíření této nákazy. Na základě počtu anomálních pacientů u jednotlivých lékařů, mohlo by jít zjistit, zda není třeba další školení těchto odborníků, úpravě směrnic či zlepšení vzdělávání v rámci Programu pro zlepšování kvality používání antibiotik.

1.5 Principy architektury řešení

V této kapitole se čtenář seznámí s principy, na kterých staví nová architektura po aplikaci požadavků ze strany SÚKL a vybraných technologií. Nová architektura obsahuje nové principy: Low-Code programování, Machine Learning as a service (ML jako služba, dále MLaaS) a SSBI. Jedná se o kapitulu, která je jedním z východiskem pro stavbu budoucí architektury, která je blíže popsána v kapitole číslo 1.6.

2008 2009 2010 2011 2012 2013 2014 2015 2016 2017

DDD/1000 obyvatel/den

Miliony Kč /rok

Spotřeba ATB v DDD/TID a náklady na ATB

DDD/TID mil. Kč Linear (DDD/TID)

1.5.1 Low-Code programování

Termín Low-Code pochází z angličtiny a znamená málo kódu. Tento pojem vznikl před pár lety, ale nejedná se o nový koncept. Tento koncept staví na funkčních blocích, které nahrazují psaný kód. Tyto vizuální bloky můžeme chápat jako napsaný kód. Uživatel si může poskládat aplikaci pomocí bloků či doplnit nestandartní funkcionalitu pomocí kódu.

S těmito nástroji většinou pracují tzv. „Power User“ či „Citizen Developer“ jedná se o uživatele z řad ne programátorů, kteří rozumí byznysu a zároveň jsou analytičtěji/techničtěji zdatní a dokáží napsat kód. Tito lidé dříve využívali hlavně Microsoft Excel a Visual Basic for Aplication. Filozofií těchto platforem je využít technicky zdatného pracovníka a umožnit mu vytvořit si vlastní aplikaci bez nutnosti programování či s minimem kódu. V principu toto řešení má snížit náklady na IT, jelikož nebude potřeba tolik programátorů (Marvin 2018).

Na druhé straně máme profesionální vývojáře, pro které jsou tyto platformy též určeny.

Slouží zejména k urychlení práce na rutinních aplikací. Díky šablonám pro různé typy aplikací je možné rychle poskládat aplikaci pro uživatele a následně ji customizovat pomocí kódu dle požadavků zákazníka i koncového uživatele. Lze říci, že tyto platformy jsou určeny jak profesionálním vývojářům tak Power Userům (Marvin 2018).

Že se nejedná o okrajovou část IT trhu svědčí zainteresování takových hráčů jako je Microsoft s Power platformou nebo Oracle či Salesforce. V roce 2019 trh s Low-Code platformami představoval celosvětově 11,45 miliard Amerických dolarů. Do roku 2027 by to mělo být 86,92 miliardy Amerických dolarů, což představuje roční růst přes 22% (Grand View Research 2020).

Pokud se podíváme na obrázek 8, kde můžeme vidět porovnanou situaci na trhu firmou

Gartner. Mezi lídry trhu patří Microsoft, Salesforce, Appain, OutSystem a Mendix. Gartner stanovil jako kritéria porovnání pozici na podle schopnosti provést realizaci vize a mít vizi.

Dle časopisu PC MAG je jejich výběrem firma Microsoft. PC Mag testoval rozhraní, jak z pohledu Business uživatele, tak profesionála (Marvin 2018; Gartner 2020).

Obrázek 8 Magický kvadrant firmy Gartner poskytovatelů Low-Code Aplication platforem (autor:

Gartner 2020)

1.5.2 Machine Learning

Machine learning (dále ML) jako takový se zde vyskytuje již od 50.let minulého století, ale do popředí se dostává až dnes díky rozvoji infrastruktury IT. Strojové učení je proces použití matematických modelů dat, pomocí kterých se počítač učí bez přímých instrukcí. Považuje se za součást umělé inteligence. Strojové učení využívá algoritmy k identifikaci vzorů v datech a tyto vzory se pak používají k vytvoření datového modelu, který dokáže formulovat předpovědi. S větším množstvím dat a více zkušenostmi jsou výsledky strojového učení přesnější – stejně jako se lidé zlepšují díky větší praxi. Díky přizpůsobitelnosti je strojové učení skvělou volbou v situacích, kdy se data neustále mění, kdy se charakter požadavku nebo úlohy stále posouvá nebo kdy by naprogramování řešení nebylo efektivně možné (Microsoft 2020c).

ML využívá 3 technik: Učení s učitelem (z anglického Supervised learning), Učení bez učitele (z angl. Unsupervised learning) a kombinované učení (z angl. Semisupervised) a zpětnovazební učení (z angl. Reinforcement learning). Učení s učitelem funguje, tak že máme k dispozici množinu vstupů a k nim definovanou množinu správných výstupů. U regresivních algoritmů to bývá většinou hodnota či interval hodnot, u klasifikačních cílová třída, atd. Mezi nevýhody těchto typů algoritmů patří vysoké náklady a nízká flexibilita. U Učení bez učitele nemáme k dispozici množinu správných výstupů a není jasné, zda prováděná úloha má řešení. Tyto algoritmy popisují data, hledají v nich různé paterny, vztahy či je dávají do clusterů. Kombinované učení kombinuje 2 předchozí techniky.

Máme k dispozici pro omezenou část datasetu (cvičná) cílovou proměnnou, ale pro většinu datasetu není k dispozici. Algoritmus se naučí predikovat cílovou proměnnou na cvičné části, kde jí má k dispozici a na zbytku datasetu následně bude predikovat cílovou proměnnou. Této techniky se využívá například pro predikci, zda schválit úvěr či nikoliv.

Zpětnovazební učení se využívá zpětné vazby neboli výsledku předchozí akce.

Algoritmus se učí ze svých chyb. Každému historickému rozhodnutí je přidělen výsledek pozitivní, negativní nebo neutrální. Tento typ algoritmů se zlepšuje s historickými daty.

Tento princip se využívá například v autonomních systémech (Lacko 2019; Microsoft 2020a).

1.5.2.1 Machine Learning as a Service

Pod MLaaS se označuje řadu služeb, které poskytují nástroje jako součást cloud computingu, z čehož plyne, že MLaaS pomáhá klientům získat výhody ML bez souvisejících nákladů, mezi které spadá například správa a provoz infrastruktury, bezpečnosti řešení, personál důležitý proběh služby, atd. Jednou z výhod je možnost škálovatelnosti služby, dle jejího používání. Poskytovatelé služeb nabízejí nástroje jako je například prediktivní analýza a hluboké učení, API, vizualizace dat, zpracování přirozeného jazyka a další. S aspektem výpočtu se zabývají datová centra poskytovatele služeb (Biswas 2018b; Ribeiro et al. 2015).

Mezi poskytovatele těchto služeb můžeme řadit společnosti Microsoft, Amazon, Google, atd.

Na obrázku číslo 9 můžeme výsledky výzkumu firmy Gartner provedené v roce 2020. Na magickém kvadrantu zaměřeným na Cloud AI Developer services, kde je zobrazeno rozdělení jednotlivých poskytovatelů. Při detailním pohledu zjistíme, že mezi poskytovateli nejsou velké rozdíly mezi lídry trhu. Nejlepším poskytovatelem se jeví společnost Amazon Web Services. Mezi lídry patří též Microsoft, Google a IBM.

Obrázek 9 Magický kvadrant poskytovatelů Cloud AI Developer služeb 2020 firmy Gartner (Gartner 2020)

V roce 2021 byl proveden další výzkum na toto téma. Na obrázku číslo 10 můžeme pozorovat, že roli lídrů si udržela čtyřka velkých technologických firem – Microsoft, Google, IBM a Amazon. S tím, že Amazon se posunul na pomyslnou 4. příčku. Boj o 3.-.3 místo je vyrovnaný mezi IBM, Googlem a Microsoftem. Firma Microsoft bodovala těmi to produkty, rozdělených do dvou částí. U Azuru: Azure Cognitive Services, Azure Machine Learning a kontroverzní AI portfolio a pro Power Platformu: AI Builder a Power Virtual Agents. Dle Gartnera mezi její silné stránky patří produkty, znalost trhu a inovace.

Obrázek 10 Magický kvadrant poskytovatelů Cloud AI Developer služeb 2021 firmy Gartner (Gartner 2021b)

1.5.3 Self-Service Business Intelligence

Self-Service nástroje přináší možnosti tvorby analytickým řešení pro Power uživatele. SSBI nástroje se zaměřují na individuální potřeby uživatelů nebo úzkou skupinu uživatelů.

Základní principy BI a SSBI řešení jsou shodná. Nejnáročnější částí při zavádění těchto nástrojů je analýza dat. SSBI nástroje je chápat jako doplněk komplexních BI řešení. SSBI nástroje slouží k tvorbě a správě reportů a dashboardů (Pour et al. 2018).

Pokud se podíváme na postavení používání BI řešení ve firmách, tak se pohybuje okolo 30

% v roce 2017. Pokud se podíváme na trh před zavedením nástrojů SSBI, tak se pohybovalo okolo 15-17 %. Na obrázku číslo 11 můžeme vidět Magický kvadrant analytické a BI platformy. Dle společnosti Gartner je patrné, že Microsoft je lídrem tohoto trhu se

společností Qlik Sense a Tableau, která je jeho nejbližším konkurentem. Zbylé společnosti na rozdíl od ostatních na tomto trhu nedominují (Pour et al. 2018; Gartner 2021a).

Obrázek 11 Magický kvadrant firmy Gartner pro Analytickou a Business Inteligence platformu (Gartner 2021)

1.6 Architektura řešení

V této kapitole je popsán současný stav řešení a navrženy varianty budoucích řešení postavených na několika technologií Signalligence, Azure Machine Learning a Power BI.

1.6.1 Současný stav

Na níže přiloženém obrázku číslo 12 se můžeme podívat na současnou architekturu řešení, na kterou můžeme nahlížet několika pohledy. Prvním důležitým pohledem je účel

architektury. Dle účelu můžeme rozdělit část na aplikační a analytickou vrstvu. Aplikační vrstva slouží pro provoz eReceptu samotného. Skládá se z klientských aplikací pro lékaře, nemocniční zařízení, lékárny, pacienty a strany třetích stran a centrální databáze, kde jsou uloženy všechny recepty, a která slouží k propojení a udržení konzistence dat. Pro tuto databázi se využívá databáze firmy Oracle. Druhou vrstvou je analytická část, která se skládá z databáze Microsft SQL Server, která je propojena na neanonymizovanou databázi pomocí ETL, ke kterému se využívá služba, Microsoft SQL Server Integragion Services, samotné databáze. Neanonymizovaná databáze obsahuje pohledy (view), které vrací anonymizovaná data. Pomocí ETL dochází k transformacím a nahrazování hashů umělými klíči. Nad databází se nachází služba Azure Analysis Services, která je napojena pomocí Místní brány dat (Service Gateway). Tato služba slouží jako analytická databáze, která obsahuje tabulární model, ve kterém jsou vypočítány jednotlivé metriky pro účely reportingu. Struktura této analytické databáze slouží pro účely reportingu. Poslední částí jsou reporty, které slouží pro koncové uživatele v SÚKL, ale i pro širokou veřejnost. Dostupné reporty můžeme najít integrované na webu eReceptu. Výhodou Power BI je, že je nástrojem SSBI, kde má možnost si uživatel bez hlubších znalostí programování vytvořit vlastní reporty a dashboardy.

Dalším pohledem na tuto architekturu může být z pohledu umístění. První část se nachází na serverech instituce tzv. On premises, kam spadá část po neanonymizovanou databázi.

Méně citlivá data (anonymizovaná) jsou uložena již na Cloudu, který je výborným prostředkem i pro sdílení dat mezi institucemi např. pro účely Ústavu zdravotních informací a statistiky ČR (dále ÚZIS).

Obrázek 12 Současný stav architektury řešení eReceptu (autor: Miroslav Lutovský)

1.6.2 Budoucí stav

V této podkapitole je popsána budoucí architektura s využitím 3 scénářů: implementace v rámci algoritmů v Azure Machine Learning studiu, použitím pouze nástroje Power BI a poslední variantou je Signalligence.

1.6.2.1 Návrh s využitím Azure Machine Learning Studia

Na obrázku číslo 13 můžeme vidět návrh architektury. Nová architektura vychází z hlavního požadavku na zachování stávajícího řešení a doplnit ho o zpracování dat pomocí Machine Learningu. Stávající architektura je obohacena o Azure Machine Learning studio a Azure SQL. Výhoda aplikování Machine Learningu v cloudu představuje zejména v jednoduché škálovatelnosti, údržbě a nulových nákladů na infrastrukturu. A možnosti neinstalovat a nepřipravovat vývojové prostředí pro vývojáře, jelikož je obsaženo v samotném cloudu pomocí Azure Machine Learning Studia. Třetí databáze je aplikována pro ukládání výsledku z Azure Machine Learning Studia a následného napojení těchto výsledků do Power BI. Větev obsahující ML je napojena na současnou architekturu pomocí služby Integration Runtime Data Factory, v podstatě se jedná o Gateway, která umožňuje obousměrný přenos data mezi cloudem a on premises částí. Dále jsou data zpracována pomocí ML algoritmů díky Azure Machine Learning service vytvořené v Azure Machine Learning Studio. Azure Machine Learning service zpracovává dat v pravidelných intervalech definovaných ze strany SÚKL.

Výsledek je uložen do databáze Azure SQL. Následně je výsledek prezentován pomocí reportů vytvořených v Power BI desktop.

Obrázek 13 Návrh budoucího stavu architektury řešení eReceptu varianta s Azue Machine Learning (autor: Miroslav Lutovský)

Mezi hlavní kritéria výběru komponent pro budoucí architekturu bylo, že vybrané řešení je třeba integrovat do stávající architektury a musí být postaveno na Microsoft Azure (SÚKL již využívá tuto službu). Z kapitol 1.3.1, 1.3.2 a 1.3.3 vyplívá, že zvolené technologie se řadí mezi nadprůměrné ve svých kategorií. Lze vyzdvihnout Low-Code přístup, který se prolíná celou škálou použitých produktů. Tento přístup přinese do cílového řešení použitelnost pro Power-Usery a možnost rychlé implementace celého řešení.

1.6.2.2 Návrh s využitím Power BI

Nejednoduší implementace je v rámci Power BI, které již obsahuje detekci anomálií (momentálně se nachází v General Avaialable). Detekce anomálií funguje v rámci časových řad (chybí podpora hledání na úrovni týdnů). U vytvořených liniových grafů stačí v sekci

„analytics“ aktivovat „Find anomalies“. Tato varianta nemá vliv na současnou architekturu řešení. Hledání anomálií je dostupné v Power BI Pro či Premium (Philip 2020).

Obrázek 14 Návrh budoucího stavu architektury řešení eReceptu varianta pouze Power BI (autor:

Miroslav Lutovský)

1.6.2.3 Návrh s využitím Signalligence

Jedná se o startupový nástroj vyvíjený pod záštitou podnikatelského akcelerátoru Vysoké školy ekonomické v Praze xPORT. Tento nástroj je kompletně napsaný v jazyce Python.

Jeho implementace bude provedena v rámci Azure Machine Learning studia, kde nasazena v rámci pipeline. Jedná se o stejnou architekturu jako v případě prvního návrhu.

Obrázek 15 Návrh budoucího stavu architektury řešení eReceptu varianta se Signalligence (autor:

Miroslav Lutovský)

1.6.3 Shrnutí

Byly navrženy 3 řešení samotné Power BI, Machine Learning Studio a Signalligence.

Všechny 3 řešení byla konzultována se SÚKL a jsou jimi schválené jako proveditelná v jejich prostředí.

1.7 Příprava dat

Pro následné zpracování dat ML algoritmy bylo třeba provést přípravu dat. V rámci přípravy dat bylo třeba vybrat data odpovídající zadání (z pohledu geografického, časového, věku pacientů a pohlaví pacienta). Vybral jsem tabulky z databáze viz. Obrázek číslo 16. Data byla pročištěna pomocí scriptů v příloze A. Z 6 647 ATC skupin pro účely této diplomové práce bylo použito 460 ATC skupin uvedených v příloze B a C (jedná se o Antiinfektiva). Dataset se týká 2 483 léčivých přípravků předepisovaných 44 721 lékaři v České republice během fungování eReceptu.

1.7.1 Export dat z databáze

V rámci práce s databází jsem nejprve odstranil záznamy receptů neobsahující antiinfektiva. Následně jsem provedl export do CSV dle skriptu uvedeného příloze A. Pro ML algoritmy je nezbytná struktura ve tvaru tabulky, která bude obsahovat místo textového obsahu čísla, proto bylo nezbytné složit tabulku pro ML zpracování z následujících tabulek a sloupců (scripty na propojení dat do struktury tabulky jsou v příloze A).

Pro export jsem záměrně použil více sloupců, pokud bych při zpracování narazil na zajímavé objevy, tak abych mohl upravit případnou tvorbu modelu pro ML algoritmus.

Model databáze můžete vidět na obrázku číslo 16.

Obrázek 16 Výběr části databáze týkající se předpisu léčiv (autor: Miroslav Lutovský)

Pokud se podíváme blíže na obrázek číslo 16, tak zjistíme, že nemáme k dispozici všechny potřebné informace ke splnění zadání. Chybí zde věk pacientů, který bohužel není k dispozici v systému (zjištěno po komunikaci se SÚKL). Po domluvě se SÚKL bude hledání anomálií probíhat podle regionu předepsání receptu, datumu předepsání receptu a pohlaví pacienta.

Dále jsem narazil na zajímavý faktor, a to využívání eRceptu. Pokud se podíváme na níže

použitelná), jelikož obsahují nízké procento ze všech předepsaných receptů. Proto použiji pouze celý rok 2019, který mám k dispozici, který by neměl být ovlivněn průběhem koronavirové pandemie.

Graf 9 Počet vydaných digitálních receptů (data Bruthans 2019, vlastní zpracování)

Graf 10 Počet vydaných digitálních receptů z celkového množství receptů (data Bruthans 2019, vlastní zpracování)

0 1,000,000 2,000,000 3,000,000 4,000,000 5,000,000 6,000,000

Množství vydaných eReceptů

2013 2014 2015 2016 2017 2018

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Množství vydaných eReceptů v %

2013 2014 2015 2016 2017 2018

1.7.2 Exploratory Data Analysis

V této podkapitole si popíšeme, co je to Exploratory Data Analysis (dále EDA), co EDA obvykle zahrnuje, a poté popíšeme tři hlavní způsoby, jakými je EDA kritická pro úspěšné modelování a interpretaci jejích výsledků.

Zvenku se věda o datech často skládá výhradně z pokročilých statistických technik a technik strojového učení. Existuje však další klíčová součást jakéhokoli úsilí v oblasti vědy o datech, která je často podhodnocena nebo zapomenuta: průzkumná analýza dat (EDA). Na vysoké úrovni je EDA praxí používání vizuálních a kvantitativních metod k pochopení a shrnutí datové sady, aniž by byly vytvořeny jakékoli předpoklady o jejím obsahu. Je to zásadní krok, který je třeba podniknout před ponořením se do strojového učení nebo statistického modelování, protože poskytuje kontext potřebný pro vývoj vhodného modelu pro daný problém a pro správnou interpretaci jeho výsledků. S nárůstem nástrojů, které umožňují snadnou implementaci výkonných algoritmů strojového učení, může být lákavé přeskočit EDA. I když je pochopitelné, proč lidé využívají výhod těchto algoritmů, není vždy dobrý nápad jednoduše vkládat data do black box řešení. Dle Biswaše hodnotu, kterou EDA poskytuje všem typům problémů data science. EDA je pro vědce v oblasti dat cenná, aby se ujistili, že výsledky, které produkují, jsou platné, správně interpretované a použitelné v požadovaných business kontextech. Kromě zajištění poskytování technicky spolehlivých výsledků má EDA také přínos pro zúčastněné strany v podnikání tím, že potvrdí, že kladou správné otázky, a nebude ovlivňovat vyšetřování podle svých předpokladů, a také tím, že poskytne kontext problému, aby zajistila potenciální hodnotu lze maximalizovat výstup

In document Hlavní práce70001_lutm00.pdf, 4.1 MB Stáhnout (Stránka 36-66)