Konference: 2005 XXIX. Brněnské onkologické dny a XIX. Konference pro sestry a laboranty
Kategorie: Onkologická informatika
Téma: Parametrizace dat a onkologická informatika
Číslo abstraktu: 228
Autoři: RNDr. Daniel Klimeš, Ph.D.; Prof. RNDr. Ladislav Dušek, Ph.D.; Ing. Petr Brabec; P. Pavliš; Mgr. Jana Koptíková, Ph.D.; RNDr. Jan Mužík, Ph.D.; MUDr. Oldřich Coufal; Mgr. Adam Svobodník, Ph.D.
Úvod
Informace se v současnosti stává čím dál významnější a cennější komoditou prakticky ve všech oblastech lidského počínání. V komerční sféře se do získávání informací investují každoročně nemalé sumy. Taktéž pokrok v dnešní medicíně je neoddělitelně spjat se shromažďováním a analýzou informací. Informace je odborný termín a podle definice je nadřazen termínu data. Z tohoto vztahu také vyplývá, že pro získávání informací je nejprve nutné zajistit kvalitní zdroje primárních dat.
Primární data v klinické oblasti jsou v dnešní době pořizována buď z provozních důvodů v klinické instituci a nebo účelně s předem daným cílem. Do první kategorie náleží data akumulovaná v nemocničních a ambulantních informačních systémech (NIS, AIS), kde slouží pro provozní výměnu. Do druhé kategorie lze zařadit data klinických studií a registrů, která jsou pořizována za konkrétním úzce profilovaným účelem. Na kvalitu dat podstatně náročnější klinické studie jsou organizovány podle striktních předem daných pravidel, které určují nejen cíle a přesné parametrické schéma studie, ale vymezují také požadavky na počet a vlastnosti subjektů hodnocení. Klinické studie tak přináší sice vysoce kvalitní data obsahující velmi cenné informace pro podporu klinického rozhodování, nicméně legislativní náročnost a náklady spjaté s organizací klinické studie jsou velmi vysoké. Z těchto důvodů je proto vždy snaha omezit klinickou studii na minimální počet subjektů hodnocení. Tento počet je určen tak, aby bylo v závěru studie možno statisticky rozhodnout o platnosti zkoumané hypotézy. Oproti tomu klinické registry nemají obecně jediný primární cíl, jde především o průběžné sledování pacientů s vybranou diagnózou. Výstupem jsou pak jednak epidemiologické ukazatele, jednak lze data využít pro stanovení základních hypotéz, které lze následně ověřovat pomocí klinických studií.
S rostoucími požadavky na sběr dat a získávání informací rostou i investice do vývoje informačních technologií pro tuto oblast. V současnosti dovede informatika uspokojit prakticky libovolné nároky uživatele v podobě nejrůznějších technologických řešení. Příklad řešení pro oblast klinických registrů je prezentován v tomto příspěvku.
Životní cyklus klinického registru nejnázorněji popisuje Schéma 1. Startovním bodem je vydefinování oblasti zájmu, načež navazuje určení parametrické skladby budovaného registru. Pro jednotlivé nadefinované parametry je následně nutné vymezit jejich konkrétní pozici v zadávacím schématu. Tato fáze je vždy klinicko-expertní záležitost a informační technologie zde mohou hrát jen podpůrnou roli. Takto vytvořené podklady jsou použity jako klinická část zadání pro technologickou implementaci registru. Vyvinutou aplikaci je nutné důkladně otestovat a případné nedostatky opravit či doplnit. Po úspěšném otestování je možné spustit provozní fázi registru a zahájit rutinní sběr dat. Během této fáze je nutné kontinuálně dohlížet na kvalitu sbíraných dat a poskytovat zpětnou vazbu datovým managerům klinických pracovišť. Nad validovanými daty lze zbudovat automatický systém reportingu, který nabízí uživateli přímý pohled do sbíraných dat. Kvalitně udržovaný registr je navíc schopen kdykoliv poskytnout data k ad-hoc analýze.
Sběr klinických dat v elektronické podobě s sebou nese taktéž některé obecné požadavky, mezi něž patří především
• Bezpečnost dat
• Dostupnost dat
• Flexibilita struktury dat
Bezpečnost je nutno zajistit jednak ve smyslu ochrany dat před nechtěným zničením, jednak ve smyslu ochrany před přístupem neautorizovaných osob. Naproti tomu oprávněné osoby by měly mít přístup k datům co nejsnadnější. Optimálním médiem pro maximální dostupnost dat je celosvětová síť Internet. Flexibilitou struktury dat je myšlena schopnost systému pružně reagovat na požadavky na úpravu parametrické struktury běžícího registru, což je při déletrvajícím sběru dat plně legitimní požadavek.
Všechny zmíněné požadavky jsou již dnes řešitelné pomocí dostupných informačních technologií. Příkladem je existující systém, ve kterém jsou v současnosti provozovány tři celostátní registry a desítka lokálních studií.
Materiál a metody
Jádrem zde navrženého systému je špičkový databázový server ORACLE 9i, který zajišťuje bezpečné uchování sbíraných dat a poskytuje základní standardní prostředí pro práci s nimi. Nad tímto jádrem pracuje několik programových komponent, které zajišťují následující funkce registru:
• návrh a definice formuláře pro sběr dat
• generátor internetové verze formuláře
• internetová aplikace zprostředkovávající sběr dat
• administrace přístupových účtů
• monitoring aktivity registru a případných problémů při provozu
• validace úplnosti a konzistence sbíraných záznamů
• jednorázové exporty a importy dat
• uživatelská analýza dat
• automatická grafická prezentace informací
Celé řešení je založeno na on-line technologiích, konkrétně na trojvrstvé technologii tenký klient – webový server – databázový server. Tenkým klientem je standardní webový prohlížeč, jako webový sever je použit IIS platformy MS Server 2003 a databázový server je zmíněný Oracle 9i. Základní princip spočívá v tom, že data pořízená ve webovém prohlížeči jsou přenesena na webový server, kde jsou transformována a uložena v databázi. Toto základní schéma je rozšířeno o další moduly, jak je patrné ze
Datový model celého systému vychází z EAV (entity-attribute-value) datové reprezentace. Nad tímto modelem jsou vystaveny jednotlivé komponenty.
Po dokončení formálního návrhu parametrické struktury registru nastává fáze implementace, během které je parametrická struktura ve speciálním aplikačním modulu nadefinována do jádra systému. Proces je prováděn v uživatelsky standardním prostředí a může tak do něj zasahovat i klinicky orientovaný pracovník.
Po nadefinování struktury jsou pomocí generátoru automaticky vytvořeny zadávací webové formuláře s přímou vazbou na datové struktury v databázi. Ty jsou pak umístěny na webový server, kde se stanou součástí jednotné webové aplikace. Tato aplikace zprostředkovává přenos sbíraných dat od uživatele do centrální databáze. Přenos dat je veden v zašifrované podobě dle 128 bitové šifry SSL protokolu.
Přístup do systému je přidělován v modulu administrace systému, kde je možné jednotlivým osobám založit login a heslo, díky kterému je možné se do systému přes webového klienta přihlásit. Ke každému účtu je možné nadefinovat jednotlivá práva na práci s daty registru. Lze tak například odlišit uživatele s právem pouze pro čtení dat od uživatele s právem data modifikovat či odstraňovat.
Monitoring provozu registru lze provádět dvěmi základními postupy. Jedním je manuální přístup pomocí samostatné aplikace přímo do databáze a kontrola zvolených statistik, druhou možností jsou pravidelné provozní statistické reporty zasílané systémem zvoleným uživatelům prostřednictvím e-mailu.
Kvalita pořizovaných dat je zajišťována na dvou základních úrovních. Prvotní je kontrola zadávaných údajů již na vstupu, tedy při zápisu do webových formulářů. Zde je možné upozorňovat na chybějící či extrémní hodnoty u jednotlivých parametrů. Druhá kontrola kvality dat probíhá nad centrální databází, kdy jsou v pravidelných intervalech nad daty spouštěny sady validačních pravidel, které zachytí případné nedostatky v datech a ty pak prezentují v podobě reportu. Report je možné zasílat e-mailem nebo prohlížet přímo jako webové stránky.
Exportní modul umožňuje oprávněnému uživateli získat celý soubor dat v nadefinované podobě pro další například statistické zpracování. Export je primárně prováděn do prostředí MS ACCESS, odkud je však možné data převádět do prakticky libovolného datového formátu. Importní modul lze využít v momentě, kdy existuje digitální soubor dat ještě před spuštěním registru. V tomto případě je možné existující data prostřednictvím importního modulu jednorázově nahrát do databáze.
Všechny dosud zmíněné komponenty systému souvisí s primárním sběrem dat. Hlavním cílem registru je však získávat z dat potřebnou informaci. K tomuto účelu slouží nadstavbové komponenty systému vyvinuté pro zpracovávání, analýzu sbíraných dat a prezentaci získaných informací. Tyto moduly jsou zakomponovány v samostatné lokální aplikaci, která nabízí funkce v rozsahu od základního průzkumu obsahu registru přes agregaci a filtrování záznamů po možnost nadefinovat automaticky aktualizovatelnou grafickou prezentaci.
Výsledky
Popsaný systém byl úspěšně využit pro několik multicentrických i lokálních klinických registrů. Jako multicentrický registr je na této technologii v ČR provozován například registr pacientů s akutní leukémií a registr pacientů s hemofilií. Přestože klinicky jsou si tyto registry značně vzdáleny, byly oba vytvořeny stejným principem ve výše popsaném systému. Reálný vývoj a provozování multicentrického registru lze nejlépe demonstrovat právě na registru pacientů s akutní leukémií.
Projekt byl odstartován v létě 2003. V té době již existoval nasbíraný soubor dat v podobě souboru ve formátu MS Excel. Struktura tohoto souboru posloužila jako výchozí bod pro definici parametrické struktury vytvářeného registru. Tato struktura byla nakonec rozšířena o další doplňující parametry a došlo k celkové restrukturalizaci zadávacího schématu. Tato fáze byla relativně časově náročná, v řádu několika měsíců, neboť bylo třeba dosáhnout konsenzu mezi zástupci zúčastněných center. Vznikla tak papírová podoba formulářů, což byl základní podklad pro technickou realizaci registru. Jeho první verze vznikla v popisovaném systému během třech týdnů. Následovala fáze testování, během které se doladily parametrické i technické detaily registru. Odladěný registr začal být plněn existujícím souborem dat. Z důvodu značné nekonzistence parametrické struktury existujících dat a nově navrženého registru bylo nutné převod dat do systému provádět pod odborným dohledem. Přesto byla tato fáze dokončena během třech týdnů. Tím skončila vývojová fáze a registr byl ještě v roce 2003 uveden do reálného provozu. Vývojové práce pokračovaly návrhem analytického a prezentačního modulu, který by uživatelům nabídnul komfortní náhled do sbíraných dat. Návrh a implementace probíhaly během jara 2004, kdy byla také tato aplikace představena uživatelům. Jejich připomínky byly průběžně zapracovávány, nicméně do roka od zahájení projektu byl k dispozici funkční systém pro multicentrický registr klinických dar včetně uživatelských prezentačních komponent. Registr je v současnosti plně funkční, rozvíjí se nejen co do objemu dat, ale také se rozšiřuje jeho parametrická struktura. Toto průběžné doplňování parametrů však nijak neomezuje standardně nastavený provoz registru. Největší objem práce je nyní odváděn při vlastním pořizování dat a jednorázových statistických analýzách. Vše ostatní zajišťuje automaticky výpočetní technika.
Vývoj lokálních registrů probíhal výrazně rychleji, časově nejnáročnější je vždy fáze návrhu obsahu a struktury formulářů. Technická realizace je již rutinní záležitost. Expertních klinických znalostí je třeba kromě fáze návrhu struktury taktéž při návrhu analytického modulu. Ten je však volitelný, pro účely menších registrů je často vhodnější provádět v dohodnutých termínech ad-hoc statistické analýzy.
Diskuse
Vybudování on-line multicentrického registru již dnes není limitováno informačními technologiemi. Časová náročnost se přesunula od technických záležitostí směrem k expertní návrhové fázi. Největší překážkou zůstává náročnost manuálního sběru klinických parametrických dat. Současná parametrická struktura provozních nemocničních či ambulantních informačních systémů je v dnešní době stále silně heterogenní a převládají nestrukturované klinické zprávy, ze kterých je zatím nemožné získávat potřebné počítačově zpracovatelné údaje. Úspěšnost registru je tak silně závislá na motivaci a ochotě klinických uživatelů investovat čas do manuálního pořizování dat.
Objektivní technické problémy lze očekávat v případě fúzování starších existujících dat s daty pořízenými podle nově navrženého schématu. Tato situace vyžaduje připravit specifické datové přemostění, které si často vyžádá jistou míru manuálního zpracování.
K dalším problémům může dojít v případě zanedbání či podcenění návrhové fáze budovaného registru. Pokud totiž struktura registru neodpovídá klinické podstatě studovaného problému, můžou nastat problémy při vyhodnocování dat či v horším případě k dezinterpretaci dat.
Závěr
Na reálném příkladu lze demonstrovat využití současných informačních technologií pro vybudování platformy pro vývoj a provoz multicentrického, díky Internetu nijak geograficky nelimitovaného, klinického registru. Dnešní technologie mohou nabídnout kompletní zázemí a servis pro všechny fáze životního cyklu elektronického klinického registru. Limitujícím faktorem zůstává pracnost manuálního pořizování klinických dat.
Literatura
Informace se v současnosti stává čím dál významnější a cennější komoditou prakticky ve všech oblastech lidského počínání. V komerční sféře se do získávání informací investují každoročně nemalé sumy. Taktéž pokrok v dnešní medicíně je neoddělitelně spjat se shromažďováním a analýzou informací. Informace je odborný termín a podle definice je nadřazen termínu data. Z tohoto vztahu také vyplývá, že pro získávání informací je nejprve nutné zajistit kvalitní zdroje primárních dat.
Primární data v klinické oblasti jsou v dnešní době pořizována buď z provozních důvodů v klinické instituci a nebo účelně s předem daným cílem. Do první kategorie náleží data akumulovaná v nemocničních a ambulantních informačních systémech (NIS, AIS), kde slouží pro provozní výměnu. Do druhé kategorie lze zařadit data klinických studií a registrů, která jsou pořizována za konkrétním úzce profilovaným účelem. Na kvalitu dat podstatně náročnější klinické studie jsou organizovány podle striktních předem daných pravidel, které určují nejen cíle a přesné parametrické schéma studie, ale vymezují také požadavky na počet a vlastnosti subjektů hodnocení. Klinické studie tak přináší sice vysoce kvalitní data obsahující velmi cenné informace pro podporu klinického rozhodování, nicméně legislativní náročnost a náklady spjaté s organizací klinické studie jsou velmi vysoké. Z těchto důvodů je proto vždy snaha omezit klinickou studii na minimální počet subjektů hodnocení. Tento počet je určen tak, aby bylo v závěru studie možno statisticky rozhodnout o platnosti zkoumané hypotézy. Oproti tomu klinické registry nemají obecně jediný primární cíl, jde především o průběžné sledování pacientů s vybranou diagnózou. Výstupem jsou pak jednak epidemiologické ukazatele, jednak lze data využít pro stanovení základních hypotéz, které lze následně ověřovat pomocí klinických studií.
S rostoucími požadavky na sběr dat a získávání informací rostou i investice do vývoje informačních technologií pro tuto oblast. V současnosti dovede informatika uspokojit prakticky libovolné nároky uživatele v podobě nejrůznějších technologických řešení. Příklad řešení pro oblast klinických registrů je prezentován v tomto příspěvku.
Životní cyklus klinického registru nejnázorněji popisuje Schéma 1. Startovním bodem je vydefinování oblasti zájmu, načež navazuje určení parametrické skladby budovaného registru. Pro jednotlivé nadefinované parametry je následně nutné vymezit jejich konkrétní pozici v zadávacím schématu. Tato fáze je vždy klinicko-expertní záležitost a informační technologie zde mohou hrát jen podpůrnou roli. Takto vytvořené podklady jsou použity jako klinická část zadání pro technologickou implementaci registru. Vyvinutou aplikaci je nutné důkladně otestovat a případné nedostatky opravit či doplnit. Po úspěšném otestování je možné spustit provozní fázi registru a zahájit rutinní sběr dat. Během této fáze je nutné kontinuálně dohlížet na kvalitu sbíraných dat a poskytovat zpětnou vazbu datovým managerům klinických pracovišť. Nad validovanými daty lze zbudovat automatický systém reportingu, který nabízí uživateli přímý pohled do sbíraných dat. Kvalitně udržovaný registr je navíc schopen kdykoliv poskytnout data k ad-hoc analýze.
Sběr klinických dat v elektronické podobě s sebou nese taktéž některé obecné požadavky, mezi něž patří především
• Bezpečnost dat
• Dostupnost dat
• Flexibilita struktury dat
Bezpečnost je nutno zajistit jednak ve smyslu ochrany dat před nechtěným zničením, jednak ve smyslu ochrany před přístupem neautorizovaných osob. Naproti tomu oprávněné osoby by měly mít přístup k datům co nejsnadnější. Optimálním médiem pro maximální dostupnost dat je celosvětová síť Internet. Flexibilitou struktury dat je myšlena schopnost systému pružně reagovat na požadavky na úpravu parametrické struktury běžícího registru, což je při déletrvajícím sběru dat plně legitimní požadavek.
Všechny zmíněné požadavky jsou již dnes řešitelné pomocí dostupných informačních technologií. Příkladem je existující systém, ve kterém jsou v současnosti provozovány tři celostátní registry a desítka lokálních studií.
Materiál a metody
Jádrem zde navrženého systému je špičkový databázový server ORACLE 9i, který zajišťuje bezpečné uchování sbíraných dat a poskytuje základní standardní prostředí pro práci s nimi. Nad tímto jádrem pracuje několik programových komponent, které zajišťují následující funkce registru:
• návrh a definice formuláře pro sběr dat
• generátor internetové verze formuláře
• internetová aplikace zprostředkovávající sběr dat
• administrace přístupových účtů
• monitoring aktivity registru a případných problémů při provozu
• validace úplnosti a konzistence sbíraných záznamů
• jednorázové exporty a importy dat
• uživatelská analýza dat
• automatická grafická prezentace informací
Celé řešení je založeno na on-line technologiích, konkrétně na trojvrstvé technologii tenký klient – webový server – databázový server. Tenkým klientem je standardní webový prohlížeč, jako webový sever je použit IIS platformy MS Server 2003 a databázový server je zmíněný Oracle 9i. Základní princip spočívá v tom, že data pořízená ve webovém prohlížeči jsou přenesena na webový server, kde jsou transformována a uložena v databázi. Toto základní schéma je rozšířeno o další moduly, jak je patrné ze
Datový model celého systému vychází z EAV (entity-attribute-value) datové reprezentace. Nad tímto modelem jsou vystaveny jednotlivé komponenty.
Po dokončení formálního návrhu parametrické struktury registru nastává fáze implementace, během které je parametrická struktura ve speciálním aplikačním modulu nadefinována do jádra systému. Proces je prováděn v uživatelsky standardním prostředí a může tak do něj zasahovat i klinicky orientovaný pracovník.
Po nadefinování struktury jsou pomocí generátoru automaticky vytvořeny zadávací webové formuláře s přímou vazbou na datové struktury v databázi. Ty jsou pak umístěny na webový server, kde se stanou součástí jednotné webové aplikace. Tato aplikace zprostředkovává přenos sbíraných dat od uživatele do centrální databáze. Přenos dat je veden v zašifrované podobě dle 128 bitové šifry SSL protokolu.
Přístup do systému je přidělován v modulu administrace systému, kde je možné jednotlivým osobám založit login a heslo, díky kterému je možné se do systému přes webového klienta přihlásit. Ke každému účtu je možné nadefinovat jednotlivá práva na práci s daty registru. Lze tak například odlišit uživatele s právem pouze pro čtení dat od uživatele s právem data modifikovat či odstraňovat.
Monitoring provozu registru lze provádět dvěmi základními postupy. Jedním je manuální přístup pomocí samostatné aplikace přímo do databáze a kontrola zvolených statistik, druhou možností jsou pravidelné provozní statistické reporty zasílané systémem zvoleným uživatelům prostřednictvím e-mailu.
Kvalita pořizovaných dat je zajišťována na dvou základních úrovních. Prvotní je kontrola zadávaných údajů již na vstupu, tedy při zápisu do webových formulářů. Zde je možné upozorňovat na chybějící či extrémní hodnoty u jednotlivých parametrů. Druhá kontrola kvality dat probíhá nad centrální databází, kdy jsou v pravidelných intervalech nad daty spouštěny sady validačních pravidel, které zachytí případné nedostatky v datech a ty pak prezentují v podobě reportu. Report je možné zasílat e-mailem nebo prohlížet přímo jako webové stránky.
Exportní modul umožňuje oprávněnému uživateli získat celý soubor dat v nadefinované podobě pro další například statistické zpracování. Export je primárně prováděn do prostředí MS ACCESS, odkud je však možné data převádět do prakticky libovolného datového formátu. Importní modul lze využít v momentě, kdy existuje digitální soubor dat ještě před spuštěním registru. V tomto případě je možné existující data prostřednictvím importního modulu jednorázově nahrát do databáze.
Všechny dosud zmíněné komponenty systému souvisí s primárním sběrem dat. Hlavním cílem registru je však získávat z dat potřebnou informaci. K tomuto účelu slouží nadstavbové komponenty systému vyvinuté pro zpracovávání, analýzu sbíraných dat a prezentaci získaných informací. Tyto moduly jsou zakomponovány v samostatné lokální aplikaci, která nabízí funkce v rozsahu od základního průzkumu obsahu registru přes agregaci a filtrování záznamů po možnost nadefinovat automaticky aktualizovatelnou grafickou prezentaci.
Výsledky
Popsaný systém byl úspěšně využit pro několik multicentrických i lokálních klinických registrů. Jako multicentrický registr je na této technologii v ČR provozován například registr pacientů s akutní leukémií a registr pacientů s hemofilií. Přestože klinicky jsou si tyto registry značně vzdáleny, byly oba vytvořeny stejným principem ve výše popsaném systému. Reálný vývoj a provozování multicentrického registru lze nejlépe demonstrovat právě na registru pacientů s akutní leukémií.
Projekt byl odstartován v létě 2003. V té době již existoval nasbíraný soubor dat v podobě souboru ve formátu MS Excel. Struktura tohoto souboru posloužila jako výchozí bod pro definici parametrické struktury vytvářeného registru. Tato struktura byla nakonec rozšířena o další doplňující parametry a došlo k celkové restrukturalizaci zadávacího schématu. Tato fáze byla relativně časově náročná, v řádu několika měsíců, neboť bylo třeba dosáhnout konsenzu mezi zástupci zúčastněných center. Vznikla tak papírová podoba formulářů, což byl základní podklad pro technickou realizaci registru. Jeho první verze vznikla v popisovaném systému během třech týdnů. Následovala fáze testování, během které se doladily parametrické i technické detaily registru. Odladěný registr začal být plněn existujícím souborem dat. Z důvodu značné nekonzistence parametrické struktury existujících dat a nově navrženého registru bylo nutné převod dat do systému provádět pod odborným dohledem. Přesto byla tato fáze dokončena během třech týdnů. Tím skončila vývojová fáze a registr byl ještě v roce 2003 uveden do reálného provozu. Vývojové práce pokračovaly návrhem analytického a prezentačního modulu, který by uživatelům nabídnul komfortní náhled do sbíraných dat. Návrh a implementace probíhaly během jara 2004, kdy byla také tato aplikace představena uživatelům. Jejich připomínky byly průběžně zapracovávány, nicméně do roka od zahájení projektu byl k dispozici funkční systém pro multicentrický registr klinických dar včetně uživatelských prezentačních komponent. Registr je v současnosti plně funkční, rozvíjí se nejen co do objemu dat, ale také se rozšiřuje jeho parametrická struktura. Toto průběžné doplňování parametrů však nijak neomezuje standardně nastavený provoz registru. Největší objem práce je nyní odváděn při vlastním pořizování dat a jednorázových statistických analýzách. Vše ostatní zajišťuje automaticky výpočetní technika.
Vývoj lokálních registrů probíhal výrazně rychleji, časově nejnáročnější je vždy fáze návrhu obsahu a struktury formulářů. Technická realizace je již rutinní záležitost. Expertních klinických znalostí je třeba kromě fáze návrhu struktury taktéž při návrhu analytického modulu. Ten je však volitelný, pro účely menších registrů je často vhodnější provádět v dohodnutých termínech ad-hoc statistické analýzy.
Diskuse
Vybudování on-line multicentrického registru již dnes není limitováno informačními technologiemi. Časová náročnost se přesunula od technických záležitostí směrem k expertní návrhové fázi. Největší překážkou zůstává náročnost manuálního sběru klinických parametrických dat. Současná parametrická struktura provozních nemocničních či ambulantních informačních systémů je v dnešní době stále silně heterogenní a převládají nestrukturované klinické zprávy, ze kterých je zatím nemožné získávat potřebné počítačově zpracovatelné údaje. Úspěšnost registru je tak silně závislá na motivaci a ochotě klinických uživatelů investovat čas do manuálního pořizování dat.
Objektivní technické problémy lze očekávat v případě fúzování starších existujících dat s daty pořízenými podle nově navrženého schématu. Tato situace vyžaduje připravit specifické datové přemostění, které si často vyžádá jistou míru manuálního zpracování.
K dalším problémům může dojít v případě zanedbání či podcenění návrhové fáze budovaného registru. Pokud totiž struktura registru neodpovídá klinické podstatě studovaného problému, můžou nastat problémy při vyhodnocování dat či v horším případě k dezinterpretaci dat.
Závěr
Na reálném příkladu lze demonstrovat využití současných informačních technologií pro vybudování platformy pro vývoj a provoz multicentrického, díky Internetu nijak geograficky nelimitovaného, klinického registru. Dnešní technologie mohou nabídnout kompletní zázemí a servis pro všechny fáze životního cyklu elektronického klinického registru. Limitujícím faktorem zůstává pracnost manuálního pořizování klinických dat.
Literatura
- Nadkarni, P. M., L. Marenco, R. Chen, E. Skoufos, G. Shepherd, and P. Miller. 1999. Organization of heterogeneous scientific data using the EAV/CR representation. Journal of the American Medical Informatics Association: Jamia 6: 478-93.
Datum přednesení příspěvku: 27. 5. 2005
