- Petr Onderka (gsvick (at) gmail (dot) com)
- Filip Řepka (repik (dot) x (at) seznam.cz)
- Ondra Heřmánek (ondra (dot) hermanek (at) gmail.com)
Lékař při každé návštěvě (nového) pacienta zjišťuje jeho anamnézu - zdravotní stav, předchozí nemoci, vyšetření, operace, rodinnou anamnézu a podobně. Pacient navíc nemusí všechny informace vědět, nebo může některé úmyslně zatajit. Navíc tento proces lékaři zabírá nemalé množství času.
Současný stav výměny dokumentace mezi lékaři je následující: pokud lékař posílá pacienta za jiným lékařem na nějaké vyšetření, vytiskne mu jeho kartu, kterou musí pacient s sebou donést zmíněnému lékaři. Karta tedy obsahuje jen informace od prvního lékaře. Po vyšetření by měl správně pacient kartu odevzdat svému obvodnímu lékaři, ale často se tak neděje a pacienti si kartu nechávají, ztrácí nebo vyhazují.
O řešení tohoto problému se již v minulosti snažil projekt IZIP, který neuspěl především z důvodu, že systém byl centralizovaný a v rukou pojišťoven, které kontrolovaly, zdali lékař provedli vše, co vykázali (což často kvůli přísným limitům lékaři v dobré víře a snaze pomoci lidem obcházeli)
Cílem tohoto projektu je navrhnout systém, který umožní lékařům získat celkovou dokumentaci pacienta a obohacovat ji. Systém bude o každém pacientu udržovat seznam všech jeho návštěv lékařů, popis vyšetření a výstupní zprávu. Tato dokumentace bude přístupná na vyžádání (při vyšetření, běhěm výjezdu sanitního vozu).
Všichni lékaři a zdravotnická zařízení vlastní telefon a počítač se zabezpečeným internetovým připojením, díky kterému budou moci pacientovu dokumentaci sdílet. Všichni lékaři se sdílením dokumentace souhlasí, všichni pacienti také.
Systém se bude skládat z Centalizovaných uzlů, které budou uchovávat zdravotnickou Dokumentaci a Zdravotnických IS, přes které budou lékaři pracovat se zdravoutnickou Dokumentaci. Centalizované uzly se budou nacházet ve všech nemocnicích a každý lékaž bude mít určený uzel, se kterým bude přes svůj IS komunikovat. Centralizované uzly budou komunikovat přes zabezpečené Web API (WebApi komponenta).
Každý požavek na centralizovaný uzel je před zpracováním verifikován - proběhne autorizace a autentizace zdravotnického systému, který požadavek vytovořil, zároveň proběhne kontrola proti zahlcení požadavky (TrafficControl komponenta).
Každý uzel bude uchovávat Dokumentaci od předem určených lékařů, a ostatním uzlům bude distribuovat pouze informace - Index - o tom, jakou Dokumentaci uchovává. Všechny uzly tedy ví, kde se nachází jaká Dokumentace.
Zdravotnický systém si může přes svůj určený uzel vyžádat Index se záznamy pacienta, ktérého zrovna léčí, nebo přímo zvolenou Dokumentaci. Tato Dokumentace se buď nachází přímo na tom (lokálním) uzlu, nebo na nějakém vzdáleném. V tomto případě si lokální uzel vyžádá dokumentaci od vzdáleného, zdravotnický systém komunikuje pouze s určeným (lokálním) uzlem.
Veškeré Dokumentace budou přístupné všem lékařům. Pro ochranu osobních údajů proti zneužití bude každá akce - vytvoření/úprava/mazání/vyžádání Dokumentace - zaznamenána. Bude tedy možné dohledat, který lékař přistoupil k jaké Dokumentaci.
Toto řešení bylo zvoleno, protože omezování přístupu lékařů k dokumentaci by vedlo k rozsáhlým komplikacím (lékař nemůže vyšetřit pacienta, protože mu omylem nebylo dáno právo přístupu k jeho dokumentaci). Na druhou stranu, do systému mají přístup jen autentizovaní lékaři, takže riziko zneužití není nepřiměřeně vysoké (ve srovnání se systémy, které jsou veřejně přístupné).
Každý lékař se zaregistruje do systému PDE, dostane pevný identifikátor a náhodně vygenerovaný token, pod kterým bude identifikován v rámci systému, rovněž mu bude přiřazen uzel, se kterým bude jeho zdravotnický informační systém komunikovat. Při registraci uvede rovněž telefonní číslo a další potřebné údaje.
Jako jeho identifikátor bude považována kombinace názvu jeho zdravotnického informačního systému a přihlašovacích údajů do jeho systému. Token mu bude vygenerován náhodně a bude sloužit k validaci požadavků vyslaných zdravotnickým informačním systémem lékaře.
Pro Index očekáváme řádově desítky milionů záznamů, proto bude kladen důraz na minimální velikost jednoho záznamu. Ideálně tedy:
pacientId | lekarId | datum | typVysetreni | uzelId | dokumentId
Jako ID pacienta by šlo použít jeho rodné číslo, to ale není unikátní, proto jako ID bude použijeme rodné číslo kombinované s celým jménem pacienta.
ID lékaře bude bráno jako kombinace názvu informačního systému, který používá, a přihlašovacího jména, kterým se přihlašuje. Tyto informační systémy si unikátnost přihlašovacích údajů řeší samy, tedy unikátnost takto vytvořených ID je zaručena. Případné kolize se dají řešit při registraci doktora do PDE systému.
- Žádost o Index:
pacientId - Odpověď Indexu:
dokumentId | uzelId | pacientId | lekarId | lekarTelefon | lekarInfo | typVysetreni | datumZmeny | pacientInfo - Žádost o dokumentaci:
uzelId | dokumentId - Odpověď s dokumentací:
vlastní Dokumentace - Vložení Dokumentace:
datumVytvoreni | datumAkce | lekarId | pacientId | typVysetreni | vlastni dokumentace - Aktualizace Dokumentace:
dokumentId | datumVytvoreni | datumAkce | lekarId | pacientId | typVysetreni | vlastni dokumentace - Smazání Dokumentace:
dokumentID - Synchronizace indexu:
datumVytvoreni | datumAkce | lekarId | pacientId | typVysetreni | dokumentaceId | pacientInfo - Aktualizace informací o pacientovi:
pacientID | pacientInfo - Aktualizace informací o lékaři:
lekarInfo - Žádost o informace o lékaři:
lekarId - Odpověď s informacemi o lékaři:
lekarInfo
Nejdůležitější výkonnostní požadavky na systém jsou:
- Přenesení dokumentace na uzel, který si ji vyžádal, by mělo trvat desítky sekund, maximálně jednu minutu.
- Synchronizace indexů by měla mít zpoždění do 30 minut.
Zdůvodnění: Předpokládá se, že lékaři budou ochotní na přenesení dokumentace počkat, ale ne příliš dlouho. U synchronizace indexů není kladen důraz na rychlost, protože se nepředpokládá, že by se pacient rychle přesouval mezi lékaři náležejícími pod různé nemocnice.
Největšími potenciálními problémy s výkonen systému by mohly být nároky přenášení dokumentů mezi nemocnicemi a synchronizace indexu na připojení nemocnic. Následuje velmi hrubý odhad těchto nároků:
Předpoklady výpočtu (mnohé velmi nereálné, ale pro rámcový výpočet by měly postačovat):
- za rok proběhne v ČR 140 milionů ambulantních ošetření (Zdravotnická ročenka ČR 2012: 135 786 630)
- každé ošetření bude vyžadovat přenesení jednoho dokumentu mezi nemocnicemi
- všechna ošetření probíhají během 8 pracovních hodin 250 pracovních dnů roku (simulace špičky)
- v ČR se nachází 200 nemocnic (Nemocnice v České republice v roce 2012: 188)
- nemocnice jsou rovnoměrně zatížené
- přenášené dokumenty mají velikost 1 MB
- záznam v indexu má 100 B
Z těchto předpokladů vychází, že v ČR probíhá 70 000 ošetření za hodinu = cca 20 ošetření za sekundu = cca 0,1 ošetření za sekundu v obvodu každé nemocnice. To znamená, že každá nemocnice bude potřebovat kapacitu 800 kb/s jak na upload, tak na download, což v dnešních podmínkách není sebemenší problém.
Vzhledem k velmi malé velikosti položek indexu bude potřeba k synchronizaci jedné nemocnice se všemi ostaními nemocnicemi cca 16 kb/s, což taktéž není problém.
Průběh zpracování požadavku na přenesení dokumentu, který není umístěný v lokální nemocnici:
- přenos požadavku do lokální nemocnice
- zpracování požadavku v lokální nemocnici
- přenos požadavku do vzdálené nemocnince
- zpracování požadavku ve vzdálené nemocnici
- přenos dokumentu ze vzdálené nemocnince
- zpracování dokumentu v lokální nemocnici
- přenos dokumentu z lokální nemocnince
Pokud předpokládáme, že na přenos tohoto dokumentu je k dispozici 1 Mb/s ve všech zúčastněných síťových uzlech, tak kroky 5 a 7 každý budou trvat 8 s. Všechny ostatní kroky by měly proběhnout rychle, předpokládejme do 1 s. Dohromady na celý proces dostáváme 21 s, což je v rámci požadavků.
Verifikační proces bude před každou akcí zavolanou přes Webové API kontrolovat, že ten, kdo akci volá, má správný login a token (pokud volající je zdravotnický IS) a nebo ověří, že volá jiný centrální uzel. Zároveň v rámci verifikace požadavku proběhne i kontrola před zahlcením. Prioritu budou mít požadavky, které přicházejí z adres, které komunikují méně, tedy minimálně zahlcují systém.
- na Index: vrátí Index se záznamy pacienta, který má u sebe uložen v lokální databázi
- na konkrétní záznam: se podle Indexu rozhodne, kde záznam vyzvednout
- buď je uložen v lokální databázi uzlu
- nebo je uložen v lokální cache uzlu (je potřeba ověřit, že není zastaralý)
- nebo ví, na jakém vzdáleném uzlu je uložena, tak si o záznam řekne
- požadavek na vzdáleném uzlu je verifikován stejným mechanizmem jako požadavek zdravotnického systému.
- poté, co obdrží záznam, si jej uloží do své cache
Centralizované uzly zároveň v daném intervalu synchronizují Index mezi ostatnímy uzly. Každý tento požadavek s novýmy/aktualizovanými záznamy je verifikován na uzlu, na který požadavek dorazí, stejným verifikačním procesem, jako ostatní (dříve zmíněné) požadavky.
Snaha bude minimalizovat dobu neplánovaných výpadku i jejich četnost. Počítá se s pravidlnými údržbami, které se budou provádět mimo špičku, ideálně po půlnoci, kdy se předpokládá minimální počet požadavků na systém.
- plánované výpadky
- hodina měsíčně na údržbu (kolem 1:00 ráno)
- neplnánované výpadky
- 30 minut měsíčně
MTBF = předpokládáme polovinu měsíce = 360 hodin
MTTR = předpokládáme 3/4 hodiny (1 hodina plánovaný výpadek(údržba), 0,5 hodiny neplánovaný výpadek; průměr = 0.75 hodiny) = 0.75 hodiny
Availability = MTBF / (MTBF + MTTR) = 360 / (360 + 0,75) = 0.9979
Tedy celková dostupnost systému bude činit zhruba 99,8% procent. Tímto se náš systém bude řadit do třídy spolehlivosti 2 - Managed (slidy RNDr. Jakuba Lokoče, Ph.D.).
K zajištění bezpečnosti je potřeba určit, proti jakým druhům útoků se budeme bránit. Předpokládané druhy útoků jsou:
- útočník bude předstírat, že je nemocnicí, při komunikaci s jinou nemocnicí nebo s lékařem
- utočník bude předstírat, že je lékařem, při komunikaci s nemocnicí
- útočník je lékař a bude přistupovat k datům, která nepotřebuje
Pro zabránění prvního případu budou všechny nemocnice vybaveny certifikátem, který se bude ověřovat při každé komunikaci s jinou nemocnicí nebo s lékařem. Všechny certifikáty nemocnic budou podepsány centrální autoritou. Bude také existovat revokační seznam, pro případ kompromitace privátního klíče nemocnice.
Pro ochranu před druhým případem se bude používat kombinace přihlašovacího jména a hesla lékaře. Toto heslo bude platné jenom v nemocnici, pod jejíž obvod lékař patří. Nemocnice budou používat standartní praktiky pro ukládání hesel (ukládá se jenom hash hesla, používá se salt).
Předpokládá se, že lékař se už přihlašuje do svého systému heslem, takže heslo pro komunikaci s nemocnicí může být uloženo na jeho disku zašifrované heslem pro přístup k jeho systému.
Lékař nikdy nebude přímo komunikovat se vzdálenými nemocnicemi, takže tento případ není potřeba řešit.
Veškerá komunikace bude zašifrovaná pomocí TLS, v případě nemocnice pomocí klíče z jejího certifikátu.
Případ, že útočník je lékař (případně někdo, kdo získal jeho heslo) se bude řešit jen logováním: každý přístup do systému se bude logovat, podezřelé přístupy se budou vyšetřovat. Pokud se tímto způsobem zjistí neoprávněný přístup k dokumentům, danému lékař se zakáže přistupovat do systému.
Tady se počítá s tím, že přístup k datům může být důležitý. To znamená, že jakékoliv omezování přístupu je nevhodné a že zvýšené riziko neoprávněného přístupu je akceptovatelné.
Od serverů v nemocnicích požadujeme:
- připojení k Internetu rychlostí alespoň 2 Mb/s v obou směrech (1Mb/s v obou směrech na komunikaci s ostatními ulzly, 1Mb/s v obou směrech na komunikaci s lékaři)
- místo na disku pro data 1 TB na každý rok (700 GB data, která patří tomuto uzlu; 14 GB index dat všech uzlů)
- 2 GHz CPU, 1 GB RAM (požadavky nejsou vysoké, protože sever nebude provádět složité výpočty)
- servery i disky zdvojené, pro zajištění vyšší spolehlivosti
Na počítače lékařů nejsou kladeny žádné zvláštní požadavky, stačí libovolný moderní desktop s 1 Mb/s přístupem k Internetu (tato rychlost je potřeba k dosažení požadované latence).
- Kvalitativní atributy
- Design Qualities
- Conceptual Integrity
- Takto robustní systém je potřeba dobře rozmyslet a navrhnout, ustanovit jednotný coding style, navrhnout základní postupy při vývoji, strategii a organizaci týmu, ...
- Maintainability
- Nebude snadné jednoduše provést aktualizaci distribuovaného systému, takže by se na možná rozšíření mělo myslet už při návrhu (například počítat s podporou obrázků v dokumentaci pacienta).
- Reusability
- Systém bude nabízet API pro komunikaci s ostatnímy systémy
- Conceptual Integrity
- RunTime Qualities
- Availability
- Měl by být kladen důraz na dostupnost API, která sbírají data od lékařů a ukládají je do nemocničních IS (99%).
- Dostupnost dokumentace z nemocničního IS už nemusí být tak ostře hlídána (95%). TODO: upřesnit,jak jsme došli k těm číslům
- Performance
- Distribuovaný systém vyžaduje režii na synchronizaci uzlů, proto je potřeba minimalizovat velikost a počet zpráv určených na synchronizaci Indexu. Na rychlost přenesení nových informací pomocí synchronizace není kladen zásadní důraz. Za rozumnou horní hranici potřebného času je považováno 30 minut.
- Od systému je požadováno, aby byl schopen v rozumném čase přenášet dokumentaci na uzel, který si ji vyžádá. V rozumném čase znaméná řádově desítky sekund, horní hranice je jedna minuta.
- Reliability
- Kladen větší důraz a dostupnost WEB API než na systém přednosu dokumentace.
- Interoperability
- Kladen důraz na jednoduchou změnu implementaci komunikace s centrálním WEB API u lékařských IS. Jednoduché zabezpečené API (https), jednoduché zprávy ve standardizovaném formátu (XML).
- Možnost parsovat interní formáty dokotrských IS na straně cenrálních IS.
- Security
- Systém bude manipulovat s citlivými daty a uchovávat je. Vymyslet způsob, jak se bránit DOS útokům, falešným zprávám, falešným lékařům, logovat přístupy pro ochranu osobních údajů.
- Scalability
- Už při návrhu je nutné počítat s velkým množstvím přenášených a uchovávaných dat. Velikost přenášených zpráv kolísat nebude, ale velikost ukládaných dat stále poroste.
- Tedy spíše horizontální škálování (úložné kapacity) než vertikální škálování (přenosové kapacity)
- Manageability
- Systém se principiálně jen úložiště citlivých dat, moc lidí by jej spravovat nemělo.
- Availability
- User Qualities
- Usability
- Uživatelé přijdou do styku se systémem pouze prostřednictvím svých IS, které nejsou součástí toho systému.
- Usability
- Design Qualities
Tento diagram znázorňuje tok dat při nahrání dokumentace
- Lékař vytvoří/upraví ve svém IS, ten se pošle přes Web API určeného centralizovaného uzlu, kde se verifikuje.
- Pokud verifikace proběhne úspěšně, záznam se uloží a aktualizuje se Index.
Tento diagram detailněji popisuje průběh vytvoření/aktualizace dokumentace pacienta.
Tento diagram ukazuje, jak probíhá získání dané dokumentace
- Lékař si nejprve vyžádá Index dokumentace o pacientovi
- Poté vybere konkrétní dokument, který ho zajímá, a centralizovaný uzel mu jej vyhledá a najde. Každý požadavek je verifikován.
Tento diagram detailněji popisuje průběh vyžádání dokumentace pacienta.
Tento diagram popisuje průběh synchronizace Indexu mezi všemy uzly.
- Každý uzel zjistí ze své lokální databáze, které záznamy přibyly/byly změněny od poslední synchronizace a tyto záznamy (jako Index) rozešle na všechny ostatní uzly
- Zároveň si kontroluje potvrzení, kterými mu ostatní uzly dávají vědět, že zpracovaly nový obsah Indexu. V případě nedodržení potvrzení je Index na daný uzel posílán opakovaně, dokud se operace nepodaří.
Zde je uveden význam používaných pojmů
- Centrální uzel - Uzel, kde se ukládá Dokumentace, Index a odkud se distribuují okolním uzlům a lékařům
- lokální - uzel, kam lékař nahrává Dokumentaci (myšleno v kontextu lékaře)
- vzdálený - ostatní uzly, kde se nachází dokumentace, lékař na něj dokumentaci nenahrává, pouze ji může získat (myšleno v kontextu lékaře)
- Dokumentace - Záznam o vyšetření pacienta
- DoS - Denial of Service - útok pomocí přehlcení požadavky
- Index - Záznam o tom, na kterém uzlu ze nachází jaká Dokumentace
- Login - přihlašovací jméno
- MTBF - Mean Time Between Failures - střední doba mezi selháními
- MTTR - Mean Time To Repair - střední doba nutná pro opravu
- TLS - Transport Layer Security - kryptografický protokol pro zabezpečení komunikace
- Token - slouží spolu s uživatelským přihlašovacím jménem a autorizaci a autentizaci požadavků
- Zdravotnický IS - informační systém lékaře pro správu pacientů