zgoda
Ta strona używa plików cookie w celu usprawnienia i ułatwienia dostępu do serwisu, prowadzenia danych statystycznych, świadczenia usług multimedialnych oraz wsparcia usług społecznościowych. Dalsze korzystanie z tej witryny oznacza akceptację tego stanu rzeczy.
Możesz samodzielnie decydować o tym czy, jakie i przez jakie witryny pliki cookie mogą być zamieszczana na Twoim urządzeniu. Przeczytaj: jak wyłączyć pliki cookie. Szczgółowe informacje na temat wykorzystania plików cookie znajdziesz w >Polityce Cookie.

AKTUALNOŚCI



Czym jest openEHR i do czego służy?

Umieściłem w zeszłym tygodniu wpis o tym, że zostałem ambasadorem openEHR. Część z Was, pytała mnie czym jest openEHR i do czego służy. W kilku kolejnych wpisach postaram się podzielić wiedzą na temat openEHR.

openEHR jest jedną z prób odpowiedzi na zagadnienie niezwykle powszechne w świecie informatyki medycznej: w jaki sposób połączyć dwa systemy informatyczne, tak aby zminimalizować koszty integracji i jednocześnie zachować pełne znaczenie informacji przechowywanych i przetwarzanych po obu stronach.

Tradycyjny sposób konstrukcji systemu do przetwarzania danych medycznych

Jeśli zastanowimy się w jaki sposób utworzona jest większość systemów informatycznych w medycynie, to jasnym stanie się, że w przypadku ogólnym jest to zbiór formularzy, które za pomocą języka SQL zapisują dane w tabelach relacyjnej bazy danych. Ponieważ aplikacja i model danych tworzony jest przez jednego producenta, ma on swobodę kształtowania i rozwijania modelu danych. W podejściu tradycyjnym, kluczowym elementem jest aplikacja (interfejs użytkownika), gdyż to z niej korzystają użytkownicy. Model danych ma znaczenie wtórne, gdyż w scenariuszu najpopularniejszym nie sięga się do niego bezpośrednio, a tylko za pomocą aplikacji. Takie podejście jest wygodne, o ile nie mamy potrzeby podłączenia aplikacji (czy systemu informatycznego) innego producenta. Nowy producent nie może po prostu zapisywać danych do istniejącego modelu - nawet gdyby posiadał stosowną wiedzę, blokowałby w ten sposób możliwość modyfikacji modelu pierwotnemu twórcy, oraz przez nieumiejętny zapis danych mógłby wpłynąć na wydajność całego systemu. Musi za każdym razem uzgadniać dostęp do danych z pierwotnym producentem. Taka współpraca nie zawsze jest możliwa z poziomów biznesowych, gdyż wymaga bardzo głębokiej współpracy obu producentów (co jeśli są to firmy ze sobą konkurujące?), ale też przez komplikację procesów tworzenia aplikacji po obu stronach podnosi koszty. Poziom kosztów jest na tyle wysoki, że realny kształt bazy danych znany jest tylko producentowi aplikacji. W efekcie szpital, nie jest w stanie swobodnie korzystać (na poziomie odczytu i zapisu) z danych przez siebie zgromadzonych i w przypadku integracji aplikacji zdany jest na producenta.

Platforma danych

openEHR jest międzynarodową społecznością, działającą non profit, która proponuje odwrócenie sposobu myślenia o systemie informatycznym w szpitalu. Jeśli bowiem zdefiniujemy najpierw standardowy sposób w jaki będziemy zapisywać oraz odczytywać z serwera dane, a następnie pozwolimy twórcom aplikacji korzystać z tych danych, to znaczną część problemów mamy rozwiązaną. Stworzymy platformę danych z której korzystać będą mogły aplikacje różnych twórców: nie będziemy ponosili kosztów integracji, nie będziemy uzależnieni od jednego dostawcy rozwiązań, nie będziemy ponosili kosztów migracji danych. Przedstawione założenie jest oczywiście nieco idealistyczne, choć w tej formie funkcjonuje w wielu branżach. Medycyna jest jednak nie tylko bardzo złożoną domeną, ale także rozwija się niezwykle dynamicznie. Dlatego nie jest możliwe opracowanie jednego "wiecznego" modelu danych, konieczne było opracowanie sposobu tworzenia wielu modeli danych, opisujących poszczególne obszary dziedziny, które mogą być zapisywane i odczytywane w standardowy sposób. Specyfikacja i metodologia tworzenia reużywalnych modeli danych jest jednym z najważniejszych elementów dorobku openEHR i podstawą wymiany danych.

Archetypy i wzorce

Modele opisujące poszczególne pojęcia związane z medycyną, definiujące zakres i sposób zapisu poszczególnych punktów danych nazywane są w świecie openEHR archetypami. Archetypy te to podstawowy budulec pozwalający na składowanie i przesyłanie danych. Archetypy oparte są o dwie koncepcje - maksymalny zakres danych, oraz przechowywanie kontekstu pozyskania informacji. Definicja związana z maksymalnym zakresem danych pozwala na użycie tego samego archetypu (np. ciśnienie krwi), zarówno w przypadku aplikacji obsługującej gabinet lekarza rodzinnego, jak i aplikację wspierającą chirurga w czasie operacji na otwartym sercu. Do każdego przypadku użycia opracowywany jest odrębny wzorzec, który nie tylko ogranicza ilość pól danych do jakich ma dostęp użytkownik, ale też grupuje archetypy, które powinny być wypełnione w czasie pojedynczej wizyty (np. ciśnienie krwi, masa ciała, wzrost). Archetypy i wzorce konstruuje się przy użyciu terminów ściśle klinicznych, co sprawia, że modelowaniem mogą zająć się lekarze, w zupełnym oderwaniu od technicznych aspektów wprowadzania i zapisywania danych. Pozwala to na w pełni efektywne wykorzystanie zarówno klinicystów zaangażowanych w modelowanie, jak i inżynierów budujących aplikacje na bazie modelu. Co więcej, międzynarodowy charakter standardu pozwolił na upublicznienie opracowanych już archetypów - w sieci jest zasób, gdzie można pobrać (oraz samemu opublikować) modele opracowane przez innych użytkowników standardu, co bardzo przyśpiesza pracę nad własnymi aplikacjami, oraz zapewnia wymianę danych pomiędzy krajami.

Implementacja

Jako, że openEHR jest sposobem składowania danych, do praktycznej implementacji systemu opartego o openEHR niezbędny jest serwer openEHR pozwalający na zapisywanie zbiorów archetypów oraz wykonywanie na nich zapytań w języku AQL (archetype query language). Niezależnie od tego czy budujemy system dla jednego szpitala, czy też rozwiązanie regionalne integrujące kilka szpitali, uruchomienie takiego serwera jest pierwszym i niezbędnym krokiem. Na rynku jest kilka różnych serwerów openEHR, dostępnych komercyjnie jak też na zasadach open source. Wszystkie dane zapisane są w sposób standardowy, więc ewentualna wymiana serwera i przeniesienie danych na inny jest zagadnieniem trywialnym.

Po uruchomieniu serwera, wgrywamy na niego definicje archetypów związanych z danymi jakie mamy zamiar przetwarzać. Tak jak zaznaczyłem powyżej definicje archetypów można zarówno opracować samodzielnie, jak i pobrać z zasobów publicznych. Następny krok, to oczywiście wprowadzanie danych - oczywiście możemy napisać własną aplikację zapisującą i odczytującą dane poprzez API serwera (wysyłając obiekty typu JSON lub XML), ale niektóre serwery wyposażone są w edytory formularzy pozwalające na stworzenie funkcjonalnego prototypu aplikacji na podstawie wzorców. Analogicznie odczytuje się dane (poprzez API jako obiekty JSON lub XML). Oczywiście możemy też skorzystać z szeregu istniejących aplikacji dla poszczególnych etapów procesu klinicznego.

Korzyści

openEHR daje olbrzymią swobodę kształtowania przestrzeni danych klinicznych, przyśpiesza wytwarzanie dobrych jakościowo aplikacji, znosi koszty integracji i migracji. Nie do przecenienia jest także funkcja otwierania rynku globalnego dla mniejszych producentów. Jeśli bowiem wytworzymy aplikacje opierające się o standard, nic nie stoi na przeszkodzie, żeby uruchamiać je w innych krajach. Standard jest międzynarodowy i wielojęzyczny, a sposób pracy lekarzy poszczególnych specjalności różni się w poszczególnych krajach świata mniej niż specyfika pracy całego szpitala.

Następnym razem postaram się napisać króciutki poradnik w jaki sposób utworzyć aplikację openEHR - zaczniemy od rzeczywistego archetypu.

ER Sp. z o.o.
ul. Borowska 283 B
Wrocław 50-556
NIP 89 927 419 84

All rigts reserved © ER Sp. z o.o. 2015 - 2017