Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie. Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI

Transkrypt

1 Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI PRACA MAGISTERSKA SEBASTIAN PISARSKI TWORZENIE STRUKTURALNYCH RAPORTÓW MEDYCZNYCH ZGODNYCH ZE STANDARDEM DICOM SR NA POTRZEBY APLIKACJI KONSULTACYJNYCH PROMOTOR: dr inż. Łukasz Czekierda Kraków 2012

2 OŚWIADCZENIE AUTORA PRACY OŚWIADCZAM, ŚWIADOMY ODPOWIEDZIALNOŚCI KARNEJ ZA POŚWIAD- CZENIE NIEPRAWDY, ŻE NINIEJSZA PRACE DYPLOMOWA WYKONAŁEM OSOBIŚCIE I SAMODZIELNIE, I NIE KORZYSTAŁEM ZE ŹRÓDEŁ INNYCH NIŻ WYMIENIONE W PRACY PODPIS

3 Serdecznie dziękuję Panu dr. inż. Łukaszowi Czekierdzie za okazaną życzliwość, zrozumienie, pomoc oraz cenne uwagi przekazywane w trakcie przygotowywania niniejszej pracy. Panu dr. hab. n. med. Andrzejowi Gackowskiemu za poświęcony czas oraz cenne uwagi odnośnie projektowanej aplikacji. Projektowi IT-SOA nr POIG /08 za dofinansowanie prowadzonych prac.

4 Spis treści 1. Wstęp Raporty w medycynie Obecnie używane raporty w medycynie Charakterystyka DICOM SR Budowa dokumentu Typy węzłów drzewa DICOM SR Typy relacji w drzewie DICOM SR Zarządzanie raportami DICOM SR Podsumowanie Przeglad dziedziny Przebieg konsultacji Rodzaje telekonsultacji Tworzenie telekonsultacji medycznej Tworzenie raportu medycznego DICOM SR Wymagania funkcjonalne i niefunkcjonalne Wymagania niefunkcjonalne Aktorzy Wymagania funkcjonalne Struktura przetwarzania Wzorce dokumentów Podsumowanie Wybrane aspekty realizacji Użyte technologie i biblioteki Prototyp Wzorce dokumentów DICOM SR w formacie xml Panel administracyjny Reguły do tworzenia automatycznej diagnozy Plik wynikowy

5 SPIS TREŚCI Panel lekarza Podsumowanie Weryfikacja Opracowanie prostego wzorca raportu echokardigraficznego Utworzenie nowego raportu echokardigraficznego z diagnozą Dodanie wzorca do eksportu zawartości raportu do dokumentu Microsoft Word Zarządzanie cyklem życia dokumentu Koncepcja użycia zaimplementowanego rozwiązania w aplikacjach telekonsultacyjnych Podsumowanie Podsumowanie Załaczniki A. Format xml wzorców DICOM SR B. Schemat XML dla wzorców dokumentów medycznych (TID) C. Przykładowy wzorzec - TID 300 Measurements... 84

6 1. Wstęp W ciągu ostatnich lat można zaobserwować postępującą informatyzację różnego rodzaju instytucji. Wśród nich pojawiły się również jednostki medyczne. W ich przypadku proces ten spowodował, że większość informacji, które były zapisywane w formie papierowych dokumentów, jest teraz przechowywana w postaci cyfrowej. Taka reprezentacja niesie ze sobą wiele zalet. Istnieje możliwość efektywnego przechowywania wyników badań, oraz danych pacjenta w specjalnie do tego celu przystosowanych systemach [1], które zapewniają odpowiedni poziom bezpieczeństwa danych pod względem zarówno ich trwałości (archiwa), jak również ochrony przed niepowołanym dostępem. Pracownicy służby zdrowia mają możliwość wyszukiwania różnych informacji statystycznych, jak np. ilość wykonanych badań danego typu w konkretnym miesiącu (dane można wykorzystać przy rozliczeniach). Dodatkowo cyfrowa reprezentacja naturalnie umożliwia przesyłanie danych między placówkami. Może to mieć duże znaczenie w przypadku, gdy pacjent trafia do innego ośrodka, gdzie potrzebna jest jego historia choroby, lub podczas konsultacji medycznych. Oprócz tego jakość zapisywanych danych obrazowych jest nieporównywalnie większa, od ich drukowanych odpowiedników. Często istnieje konieczność przeprowadzenia konsultacji medycznych, w których postawienie diagnozy wymaga zaangażowania lekarzy z wielu specjalności. Jako że obecnie nie używa się (na szeroką skalę) żadnych standardów dotyczących opisów schorzeń, to różni lekarze mogą je sporządzać na wiele sposobów. Takie podejście powoduje, że opis może być niepełny (brakuje informacji ważnych z punktu widzenia innej specjalności) lub zawiera zbędne informacje (ich wpisanie zabiera czas). Dodatkowo jeśli diagnoza jest czytana przez innego lekarza, to najpierw musi on znaleźć interesujące go dane, które w zależności od tego, kto ją sporządzał, mogą znajdować się w różnych miejscach i być przedstawione w różnej formie. Należy również zwrócić uwagę na to, że diagnoza powstaje na podstawie badań, których wynikiem często są różnego rodzaju obrazy medyczne, lub sekwencje filmowe. Niestety zazwyczaj nie istnieje powiązanie z tymi danymi, które pozwalałoby na automatyczną ich prezentację wraz z diagnozą (użytkownik musi wyszukać je ręcznie, bazując na jej treści). Ponad 10 lat temu wspomniane wyżej problemy zostały zauważone przez grupę specjalistów, którzy stworzyli standard DICOM SR (Digital Imaging and Communications in Medicine Structured Reporting). Jego celem było wprowadzenie strukturalnych raportów medycznych. DICOM Structured Reporting stanowi rozszerzenie standardu DICOM. Oprócz danych klinicznych (wyników badań) obejmuje on również dane o pacjencie. Dodatkowo wprowadza możliwość łączenia diagnozy z obrazami medycznymi, na podstawie których została ona stworzona, zmusza lekarza do przestrzegania określonych proce- 7

7 8 dur związanych z tworzeniem raportów, jak również ułatwia weryfikację diagnozy przez innego specjalistę. Własności standardu dobrze wpasowują się w wymagania konsultacji medycznych, ze względu na występowanie ustalonej struktury dokumentów, co znacznie przyspiesza odszukanie ważnych dla lekarza informacji. Oprócz tego, istnieje możliwość przeglądania historii modyfikacji raportów, co może być przydatne w sytuacji, gdy podczas konsultacji ten sam dokument jest modyfikowany przez wielu lekarzy jednocześnie. Ze względu na istnienie możliwości weryfikacji treści tego typu dokumentów, dobrze nadają się one do nauki młodych lekarzy, których praca może być sprawdzana przez doświadczonych pracowników. Mimo widocznych zalet, istnieje niewiele aplikacji, które wykorzystują standard DICOM SR. Ponadto istniejące rozwiązania są raczej nastawione na wyświetlaniu zawartości dokumentów, a nie na ich tworzeniu (wypełnianiu danymi). Wiele z tych rozwiązań ma również szereg wad. Celem niniejszej pracy jest sprawdzenie możliwości wykorzystania standardu DICOM SR do tworzenia strukturalnych raportów medycznych, które mogłyby być wykorzystywane w aplikacjach telekonsultacyjnych (jak np. TeleDICOM [2]). Proces ten składałby się zarówno z zaprojektowania struktury, w zgodzie z ogólnie przyjętymi wzorcami, wypełniania utworzonego szablonu danymi, jak również zarządzania istniejącymi dokumentami. Poszczególne rozdziały niniejszej pracy przedstawiają kolejne etapy dążenia do osiągnięcia postawionego wyżej celu. W pierwszym rozdziale poruszony jest ogólnie problem raportów w medycynie, pokazane są różne ich rodzaje oraz wskazane są możliwości standardu DICOM SR w tym kontekście. Kolejny rozdział zawiera analizę wymagań aplikacji ze względu na używanie jej w szpitalu, jak również w rozproszonych konsultacjach medycznych. Ponadto znajduje się tam opis wzorców dokumentów. Po analizie wymagań, praca zawiera opis wybranych aspektów realizacji, czyli powstałych w trakcie jej tworzenia artefaktów. W finalnej części znajduje się opis metod weryfikacji poprawności działania programu, jak również jej rezultaty. Pracę kończy podsumowanie. Najważniejszymi dokonaniami niniejszej pracy jest pokazanie, jak można wykorzystać standard DI- COM SR w praktyce, w taki sposób, żeby mógł być używany w różnych dziedzinach medycyny, w sposób przejrzysty i prosty dla użytkownika. Ponadto zaimplementowana aplikacja może poprawić jakość usług oferowanych przez służbę zdrowia, w sensie przyspieszenia pracy lekarzy specjalistów (wiele pól w raporcie może być wypełniane automatycznie), ułatwienia ich wzajemnych konsultacji (zawsze pracują na takich samych strukturach) i ogólnie uporządkowania treści raportów medycznych. Oprócz tego, użycie ustandaryzowanych raportów zmniejsza prawdopodobieństwo (a w niektórych przypadkach wyklucza) pomyłek przy tworzeniu dokumentów (np. pilnowanie czy pola wymagalne są uzupełnione). Praktyczne stosowanie raportów DICOM SR umożliwia również wprowadzenie automatycznego lekarza, który mógłby rozumieć zawarte tam dane i próbować stawiać diagnozę automatycznie na podstawie wiedzy, którą posiada.

8 2. Raporty w medycynie Niniejszy rozdział składa się z dwóch części. W pierwszej są opisane różnego rodzaju raporty obecnie używane w medycynie. Główny nacisk jest położony na sposób przechowywania, oraz tworzenia diagnozy. Kolejny rozdział zawiera opis standardu DICOM SR, bazujący na książce DICOM Structured Reporting [3]. Nacisk, jest położony bardziej na stronę funkcjonalną, oraz proces tworzenia tego typu dokumentów, niż aspekty techniczne. Poszczególne elementy są opisywane w kontekście potencjalnego wykorzystania w przetwarzaniu szpitalnym Obecnie używane raporty w medycynie Postępująca informatyzacja służby zdrowia sprawiła, że w większości przypadków lekarz wypełnia dokumenty przy użyciu komputera. Takie podejście posiada wiele zalet. Jedną z nich jest zwiększenie czytelności tych dokumentów. Inną jest możliwość przechowywania danych również w postaci cyfrowej, co zwiększa ich bezpieczeństwo przed utratą, jak również umożliwia usprawnienie działania różnych instytucji służby zdrowia (automatyczne uzupełnianie danych pacjenta, szybkie przesyłanie dokumentów, lepsze wyszukiwanie, itd.). Niestety są to w znacznej części dokumenty pozbawione struktury. Chodzi tutaj o strukturę w rozumieniu globalnym. W ramach tej samej jednostki podobne dokumenty wyglądają praktycznie jednakowo (dane są tak samo rozmieszczone). Niestety nie ma żadnych regulacji prawnych dotyczących wyglądu wielu dokumentów medycznych (jak wypis ze szpitala) w skali kraju. Wspomniane wytyczne dotyczą jedynie treści, która musi się tam pojawić, natomiast sposób jej rozmieszczenia jest w zasadzie dowolny (oczywiście problem nie dotyczy dokumentów które mają ściśle określony format, takich jak recepty). Oprócz tego często duża część raportów medycznych zawiera elementy, gdzie lekarz musi opisać stan pacjenta lub sposób leczenia. W tym wypadku powstaje kolejny problem, jakim jest własność języka naturalnego do wyrażania podobnych myśli na wiele różnych sposobów. W konsekwencji te same informacje mogą zostać przekazane w małej lub bardzo dużej liczbie słów. Dodatkowo zawsze istnieje niebezpieczeństwo, że lekarz zapomni wpisać jakiejś ważnej informacji, co może w najlepszym przypadku zmusić pacjenta do ponownej wizyty, a w skrajnym nawet przyczynić się do utraty zdrowia lub życia. Z uwagi na to, że najczęściej konsultacje medyczne dotyczą przypadków szpitalnych, poniżej przedstawiona jest analiza przykładowego wypisu ze szpitala (rysunek 2.1). Wybór tego dokumentu uzasad- 9

9 2.1. Obecnie używane raporty w medycynie 10 Rysunek 2.1: Przykładowa karta informacyjna leczenia szpitalnego

10 2.2. Charakterystyka DICOM SR 11 niony jest faktem, że musi on zawierać wszystkie niezbędne informacje opisujące pacjenta. Każdy wypis powinien zawierać: nazwę jednostki medycznej - ten element w ramach danej jednostki jest niezmienny. Najczęściej oprócz nazwy, adresu i oddziału dodawane jest logo. dane pacjenta - obejmują podstawowe dane takie jak imię i nazwisko oraz PESEL. wyniki badań - prezentacja wyników badań najbardziej różnicuje poszczególne jednostki medyczne oraz dziedziny medycyny. W większości przypadków lekarze starają się, żeby wszystkie dane zmieściły się na jednej stronie, dlatego w zależności od dziedziny można różnie rozmieścić dane (niektóre dziedziny wymagają wykonania większej liczby badań). Najczęściej wyniki są prezentowane tak jak na rysunku 2.1, lub w postaci różnych tabel. diagnoza - informacje o stwierdzonym schorzeniu. Może być to również interpretacja wyników badań. Przykładowo lekarz może stwierdzić, że dana wielkość jest w normie. podpis - podpis pełni dwie bardzo ważne funkcje. Może identyfikować autora raportu, lub oznaczać, że ktoś zatwierdza dokument (po zweryfikowaniu jego treści). Są to dane, które występują w większości dokumentów medycznych. Informacje te mogą być przechowywane w ustrukturalizowanej postaci. Przykładowo zawsze należy podać te same dane pacjenta w określonej formie (formacie). Elementami, które naturalnie posiadają (lub mogą posiadać) strukturę są: dane pacjenta, wyniki badań, dane dotyczące podpisów oraz weryfikacji raportu, jak również informacje o jednostce gdzie wykonano badania. Do zapisu tego typu danych bardzo dobrze nadaje się standard DICOM SR (w tym celu został stworzony). Oprócz wyżej wymienionych elementów, raport może zawierać również dodatkowe informacje dotyczące zastosowanych metod leczenia, lub dalszych zaleceń. Niestety tego typu dane (wraz z diagnozą) najczęściej mają bardzo luźną strukturę oraz mogą zawierać złożoną treść (trudno przewidzieć wszystkie możliwości). W konsekwencji tego typu dane najczęściej są zapisywane jako pola tekstowe w dokumentach DICOM SR Charakterystyka DICOM SR Standard DICOM SR (DICOM Structured Reporting) został stworzony w celu ujednolicenia sposobu zapamiętywania obserwacji klinicznych. Został on zaprojektowany z myślą o wypełnieniu luki między medycznymi systemami raportowymi, które są odpowiedzialne za przechowywanie danych o pacjentach i ich badaniach, a systemami obsługującymi obrazy medyczne, na podstawie których powstają diagnozy. Ponadto jednym z ważniejszych cech dokumentów DICOM SR, jest fakt, że są łatwe w przetwarzaniu. Podstawowymi własnościami, które oferuje standard są: obecność list i relacji hierarchicznych, możliwość wykorzystywania wartości kodowych, lub numerycznych oprócz zwykłego tekstu,

11 2.2. Charakterystyka DICOM SR 12 relacje pomiędzy pojęciami, wbudowane referencje do obrazów medycznych, jak również ich składowych (przykładowo obrysów). DICOM SR podejmuje problematykę reprezentacji danych w odpowiedniej strukturze. Standard w żaden sposób nie definiuje, w jaki sposób informacje powinny być prezentowane. Pod tym względem może być porównany do języka XML (extensible Markup Language), w przeciwieństwie do języka HTML (HyperText Markup Language). HTML zawiera odpowiednie znaczniki, odpowiedzialne za formatowanie, które jednak nie mają żadnego znaczenia w sensie informacyjnym. Natomiast każdy element języka XML ma swoje unikalne znaczenie. Z tego też powodu do prezentacji zawartych tam danych najczęściej potrzebujemy zewnętrznego narzędzia (jednocześnie zyskując pewną elastyczność, co do prezentacji) Budowa dokumentu Rysunek 2.2: Przykładowy raport echokardiograficzny - dane dotyczące pacjenta i badania (fragment prezentowany przez przeglądarkę SR Browser [4]) Każdy dokument DICOM SR można podzielić na dwie części: 1. kontekst dokumentu - w tej części zawarte są dane ogólne o pacjencie, które najczęściej są przechowywane w systemach (HIS - Hospital Information Systems [1]) (rys. 2.2) imię i nazwisko, data urodzenia, identyfikator pacjenta, płeć.

12 2.2. Charakterystyka DICOM SR 13 oraz dane dotyczące badania: data badania, identyfikator badania, numer dostępu (accession number), imię i nazwisko osoby wykonującej pomiary. 2. drzewo dokumentu - zawiera szczegółowe dane dotyczące zarówno pacjenta, jak i badania (rys. 2.3 i 2.4) Rysunek 2.3: Fragment drzewa raportu echokardiograficznego Głównym elementem dokumentu DICOM SR jest drzewo (SR Document Tree). Zapewnia ono dużą elastyczność struktury raportów. Węzłami drzewa są elementy treści (Content Items), z których każdy jest parą klucz-wartość. Kluczem jest tutaj Concept Name, w którego skład wchodzi: Code Value - kod zrozumiały dla maszyny. Umożliwia proste wyszukiwanie, oraz indeksowanie. Code Scheme Designator - nazwa/kod organizacji, która ustaliła postać kodu umieszczonego w Code Value. Code Meaning - opis zrozumiały dla człowieka. Code Scheme Version (opcjonalnie) - określa wersję kodu jaka jest wykorzystywana.

13 2.2. Charakterystyka DICOM SR 14 Rysunek 2.4: Przykładowy raport echokardiograficzny - wyniki pomiarów (fragment prezentowany przez przeglądarkę SR Browser [4])

14 2.2. Charakterystyka DICOM SR 15 Najczęściej Concept Name zapisuje się jako trójka, w postaci ( Code Value, Code Scheme Designator, CodeMeaning ). Przykładowo ("121070", "DCM", "Findings") - Concept Name używany między innymi w raporcie echokardiograficznym, w celu oznaczenia rozdziału dokumentu, gdzie są umieszczane wnioski/pomiary badania. Wartości są opcjonalne (może istnieć węzeł, który ma tylko nazwę). Mogą być nimi różne typy takie jak: tekst, kody, liczby, referencje do obrazów (miejsc na obrazie), lub innych dokumentów, oraz wiele innych. Korzeń drzewa nosi nazwę Root Content Item i zawsze jest typu Container. Dodatkowo jego Concept Name zawiera w sobie nazwę całego raportu. Przykładowo dla raportu echokardiograficznego jest to ( , DCM, Adult Echocardiography Procedure Report ) Połącznia między poszczególnymi węzłami również mają swoje typy, co pozwala na tworzenie różnego rodzaju relacji. Drzewo zbudowane jest poprzez łączenie poszczególnych Content Item z korzeniem, lub z innymi elementami Concept Item, odpowiednimi typami relacji, które pozwalają wyrazić znaczenie połączenia. Rysunek 2.4 przedstawia fragment zawartości raportu echokardiograficznego utworzonego przez echokardiograf. Wyświetlane etykiety (pogrubiona czcionka) są wartościami Code Meaning, natomiast po nich występuje wartość węzła, odpowiednio przetworzona na tekst. Poszczególne wcięcia reprezentują kolejne podrozdziały raportu, grupują treść. Oczywiście jest to reprezentacja zaproponowana w aplikacji SR Browser, dlatego może różnić się między różnymi przeglądarkami raportów DICOM SR. Warto również zwrócić uwagę, że schemat drzewa przedstawiony na rysunku 2.3 odpowiada zawartości generowanej przez echokardiograf. Kolejne elementy przedstawiają: Findings - grupuje wyniki pomiarów w obrębie pojedynczego regionu. Finding Site - przechowuje nazwę regionu, do którego odnosi się Findings. Measurement Group - grupa pomiarowa. Te same wartości mogą być mierzone w obrębie pojedynczej grupy pomiarowej (np. różnymi metodami), oraz w kilku grupach. Wiele grup pomiarowych może występować np. w sytuacji, gdy lekarz chce dla pewności powtórzyć jakieś pomiary, lub w przypadku, gdy pomiary dotyczą różnych obrazów. Image Mode - węzeł opcjonalny. Określa na jakim typie obrazu były wykonywane pomiary. pozostałe wartości opisują nazwy mierzonych wielkości, wraz z wynikami, jak również zawierają dodatkowe dane odnośnie pomiarów. Oczywiście raport echokardiograficzny może zawierać dużo więcej informacji, których tutaj nie zamieszczono. Ponadto, wielkość raportu (ilość węzłów, mierzonych wartości) zależy w znacznym stopniu od lekarza. W rzeczywistych zastosowaniach rzadko wykonuje się wszystkie badania (pomiary), ponieważ po wstępnych badaniach lekarz ma pewne podejrzenia co do diagnozy, którą chce potwierdzić badaniami.

15 2.2. Charakterystyka DICOM SR Typy węzłów drzewa DICOM SR CONTAINER - Container Content Item nie posiada wartości. Jak wskazuje nazwa służy on do grupowania innych elementów. Jeśli posiada wartość Concept Name, to jest traktowany jako rozdział dokumentu, jeśli nie, ma znaczenie jedynie grupujące. Węzłami tego typu są: Findings oraz Measurement Group TEXT - przechowuje wartość tekstową, przy czym nie ma ograniczenia na jej długość. Przechowywany tekst nie jest formatowany. Istnieje jednak możliwość zapisania kilku linii tekstu, posługując się odpowiednimi znacznikami: LF( \n ), oraz CR( \r ). Concept Item typu TEXT musi posiadać Concept Name, oraz musi posiadać wartość (tekst musi zawierać co najmniej jeden znak). Węzłów tego typu należy używać tylko w przypadku, gdy nie da się zastosować węzłów CODE lub NUM, których wartości lepiej nadają się do interpretacji przez maszynę. W raporcie echokardiograficznym w węźle typu TEXT można zapisać przykładowo nazwę szpitala w którym wykonane zostało badanie. CODE - wartość kodowa. Kod zapisywany jest sekwencją trzech wartości, która nosi nazwę Concept Code Sequence. Jest ona analogiczna jak w przypadku Concept Name (poszczególne elementy mają identyczne znaczenie), czyli wartość określana jest przez: Code Value, Code Scheme Designator, Code Meaning. Celem wprowadzenia tego typu węzłów jest możliwość użycia międzynarodowej terminologii medycznej, co ułatwia analizę raportów. Węzłami tego typu są: Finding Site, oraz większość własności pomiarów, takich jak Measurement Method NUM - służy do przechowywania wartości numerycznych, wraz z ich jednostką. Wartość jest zapisywana jako Measured Value Sequence, która składa się ze wspomnianych wcześniej elementów, przy czym jednostka jest określana za pomocą Measurement Units Code Sequence, a więc za pomocą trójki analogicznej do Concept Code Sequence węzła CODE. Nie ma możliwości wprowadzenia liczby, bez podania jej jednostki (chyba że jawnie określimy jednostkę jako no units ). Węzłami tego typu są na przykład węzły pomiarowe (np. Left Ventricular End Diastolic Volume). PNAME - typ przeznaczony do przechowywania imienia i nazwiska pacjenta. Wartość jest kodowana jako DICOM Person Name, gdzie należy pamiętać o zachowaniu właściwej kolejności poszczególnych elementów i używaniu znaki ^ jako separatora. Ograniczenia co do wartości i Concept Name, są takie same jak w przypadku węzła typu TEXT. Przykładową wartością może być: PISARSKI^SEBASTIAN DATE, TIME, DATETIME - węzły o tych typach reprezentują odpowiednio: datę określającą dany dzień (bez godziny), czas (godzinę), bez daty konkretnego dnia, czas w konkretnym dniu. UIDREF(Unique Identifier Reference) - text zawierający DICOM UID. Służy do wskazywania na pojedynczy element raportu. Przykładowo może to być numer instancji raportu medycznego.

16 2.2. Charakterystyka DICOM SR 17 COMPOSITE - pozwala na wskazywanie na obiekty złożone DICOM, jak inne raporty medyczne. Wartość jest zdefiniowana jako Referenced SOP Sequence, który zawiera dwie wartości: SOP Class UID, oraz SOP Instance UID obiektu którego dotyczy wskazanie. Za pomocą tego typu nie można wskazywać na węzły typu IMAGE oraz WAVEFORM IMAGE - wartością węzła tego typu jest pojedyncze wskazanie na obraz w formacie DICOM. IMAGE stanowi rozszerzenie COMPOSITE. Oprócz Referenced SOP Sequence można podać listę numerów ramek obrazu do których się odwołujemy, oraz referencję do obiektu reprezentującego stan prezentacji (Grayscale Softcopy Presentation Storage Object). Węzeł IMAGE może wystąpić na przykład w opisie danego pomiaru, w celu wskazania na którym obrazie został on wykonany. WAVEFORM - kolejny typ, który jest rozszerzeniem COMPOSITE. Pozwala na przechowywanie pojedynczej referencji do strumieniowego obiektu DICOM. Dodatkowym elementem jest Referenced Waveform Channels, gdzie można podać do jakich konkretnych kanałów obiektu strumieniowego się odnosimy. Podobnie jak węzeł IMAGE, WAVEFORM może wystąpić na przykład jako potomek węzła opisującego pomiar. SCOORD (Spatial Coordinates) - pozwala na wskazanie elementu na obrazie medycznym (np. obrysu wykonanego przez lekarza w trakcie badania). Wspomniane wskazanie jest realizowane poprzez podanie dwóch wartości: Graphic Data (lista punktów), oraz Graphic Type (określa rodzaj wskazywanego obiektu). Każdy węzeł SCOORD zawsze posiada co najmniej jeden węzeł potomny typu IMAGE, lub WAVEFORM (sama definicja obrysu nie ma sensu bez obrazu na którym się on znajduje). Jeśli węzeł posiada Concept Name, to jego wartość określa cel odwołania. Najczęściej węzeł występuje jako potomek węzła pomiarowego, w celu opisania krzywej, na podstawie której powstała wartość pomiaru (przykładowo pole powierzchni) Dostępne typy graficzne: POINT - pojedynczy punkt. MULTIPOINT - określa grupę niezależnych punktów. Rysunek 2.5: Współrzędne wskazujące na przestrzeń między-pikselową [3]

17 2.2. Charakterystyka DICOM SR 18 POLYLINE - zamknięty wielokąt, definiowany poprzez jego wierzchołki. CIRCLE - koło opisywane przez jego środek i punkt na obwodzie. ELLIPSE - elipsa, definiowana przez dłuższą i krótszą oś (4 punkty). Graphic Data jest listą wartości o parzystej liczbie elementów [y1,x1,y2,x2,...,yn,xn]. Przykładowo lista [1,2,3,4] opisuje dwa punkty (x=2, y=1) i (x=4, y=3). Oprócz tego każda wartość jest liczbą zmiennoprzecinkową. Oznacza to, że można wskazywać nawet na części pikseli na obrazie (np. punkt (0.5, 0.5) oznacza środek piksela w lewym górnym rogu obrazu), tak jak zostało to pokazane na rys TCOORD (Temporal Coordinates) - umożliwia wskazywanie na konkretny wycinek czasu w węzłach typu WAVEFORM, oraz IMAGE (jeśli obraz zawiera wiele ramek). Definicja wspomnianych przedziałów znajduje się w Temporal Range Type. Dostępne są następujące Range Type: POINT - pojedyncza klatka. MULTIPOINT - kilka niezależnych klatek. SEGMENT - ciągły zbiór klatek. MULTISEGMENT - zbiór SEGMENT ów. BEGIN - ciągły zbiór klatek od wybranego miejsca do końca. END - ciągły zbiór klatek od początku do wybranego miejsca. Rysunek 2.6: Wizualizacja przedziałów czasowych Temporal Range [3]

18 2.2. Charakterystyka DICOM SR Typy relacji w drzewie DICOM SR CONTAINS - relacja zawierania. Zawsze węzłem źródłowym tej relacji jest CONTAINER, ponadto węzeł docelowy i wszystkie jego węzły potomne są zawarte w węźle źródłowym. HAS PROPERTIES - oznacza, że węzeł źródłowy ma pewne określone cechy (jak wielkość lub kształt). Rodzaj i wartość takiej cechy jest określona przez węzeł docelowy. Zaleca się używania węzła typu CODE jako węzła docelowego, z uwagi na to, że można jednoznacznie określić (opisać) daną własność (nie jest to jednak wymagane) INFERRED FROM - relacja używana, w przypadku, kiedy węzeł źródłowy jest wnioskiem, wysnutym na podstawie informacji zawartych w węźle docelowym i jego potomkach. Przykładowym użyciem jest identyfikacja źródła pomiaru (obrysu na obrazie, z którego wyliczona została jakaś wartość). BY-REFERENCE - specyficzna relacja, która pozwala zmniejszyć nadmiarowość danych (rozmiar drzewa), poprzez umożliwienie dokonywania wskazań przez referencję. Takie podejście umożliwia używanie tych samych elementów drzewa w różnym kontekście, co zwiększa elastycznośc, przy tworzeniu dokumentów DICOM SR. SELECTED FROM - oznacza, że węzeł źródłowy zawiera zbiór koordynat wybranych z innego zbioru, obrazu medycznego, lub pliku strumieniowego. HAS OBSERVATION CONTEXT - pozwala rozszerzyć kontekst (który może być bardzo złożony) węzła źródłowego o dodatkowe informacje zawarte w węźle docelowym. HAS ACQUISITION CONTEXT - podobnie jak HAS OBSERVATION CONTEXT rozszerza kontekst węzła źródłowego. Różnica polega na tym, że dodatkowe informacje nie są propagowane na potomków węzła źródłowego. HAS CONCEPT MODIFIER - służy do modyfikacji znaczenia CONCEPT NAME węzła źródłowego. Dzięki użyciu tej relacji mamy możliwość: rozbicia złożonych CONCEPT NAME na zbiór prostszych, co znacząco ułatwia późniejsze wyszukiwanie w dokumencie, definiowania znaczenia (Code Meaning) dłuższego niż standardowy limit 64 znaków, dodawania tłumaczeń znaczeń w różnych językach Zarzadzanie raportami DICOM SR Oprócz tworzenia i kodowania treści, standard DICOM SR dostarcza kilku reguł dotyczących zarządzania, w celu zapewnienia kontroli nad przechowywaniem oraz dostępnością dokumentów. Wspo-

19 2.3. Podsumowanie 20 mniane informacje są przechowywane poza drzewem z zawartością, w oddzielnym module nazywanym SR Document General Module. Wartościami tam przechowywanymi są: identyfikacja dokumentu - każdy dokument DICOM SR ma unikalny identyfikator instancji (Instance UID). Standard zakłada, że twórca dokumentu, po każdej zmianie treści, zmieni identyfikator dokumentu. Nie powinno się zdarzyć, żeby istniały dwa dokumenty o tym samym identyfikatorze, a różnej treści. status dokumentu - stan jest określany poprzez ustawienie wartości flagi Completition Flag i określa w jakim etapie tworzenia znajduje się dokument. Flaga może przyjąć jedną z dwóch wartości: 1. PARTIAL - dokument jest w trakcie tworzenia. Możliwa jest edycja. 2. COMPLETE - oznacza wersję finalną dokumentu (nie można modyfikować treści). Jeśli raport posiada status COMPLETE jest możliwość jego weryfikacji, oraz podpisu cyfrowego. informacja o weryfikacji - jeśli dokument znajduje się w wersji finalnej można dokonać jego weryfikacji, czyli potwierdzenia poprawności jego zawartości. Lista weryfikacji jest przechowywana w Verifying Observer Sequence. Każda z nich zawiera następujące dane: data, imię i nazwisko osoby weryfikującej, nazwa organizacji do której ta osoba należy. Weryfikacja może być przeprowadzana wielokrotnie przez różne osoby. W przypadku, kiedy co najmniej jedna osoba dokonała weryfikacji, zmieniana jest wartość flagi Verification Flag z UNVERIFIED na VERIFIED. Zarządzanie stanem dokumentu w połączeniu z mechanizmem weryfikacji i podpisów elektronicznych może mieć bardzo istotne zastosowanie w co najmniej dwóch dziedzinach: 1. nauka młodych lekarzy - raport DICOM SR może zostać stworzony przez technika, lub młodego lekarza (który dopiero uczy się wykonywania pomiarów i wyciągania z nich wniosków), a następnie trafić do weryfikacji do doświadczonego specjalisty. Jeśli dokument pozytywnie przejdzie weryfikację, to wiadomo, że można przyjąć jego treść za poprawną, w przeciwnym wypadku należy go poprawić. 2. konsultacje medyczne z udziałem wielu specjalistów - jeśli w procesie formułowania diagnozy bierze udział wielu lekarzy (w tym również z różnych dziedzin), to proces weryfikacji oznacza, że każdy z nich zgadza się z jej zawartością. W praktyce może to być wyznacznikiem końca konsultacji (jeśli przykładowo co najmniej połowa lekarzy biorących udział w konsultacji dokona pozytywnej weryfikacji dokumentu) Podsumowanie Analiza wykorzystywanych obecnie dokumentów w jednostkach służby zdrowia umożliwiła autorowi pracy zapoznanie się z tematyką dotyczącą przechowywania i prezentacji danych medycznych. Pozwoliła zorientować się, które dane są istotne z punktu widzenia lekarzy oraz w jaki sposób są one prezentowane (zostało to później wykorzystane podczas ustalania koncepcji interfejsu wyświetlania raportów). Dodatkowo ułatwiła zbieranie wymagań opisanych w kolejnym rozdziale.

20 2.3. Podsumowanie 21 Przegląd standardu DICOM SR dostarczył niezbędnej wiedzy teoretycznej, która zostanie wykorzystana w dalszych etapach pracy. Najważniejszymi elementami standardu z punktu widzenia analizowanego problemu jest: sposób budowy drzewa (z podziałem na różnego typu węzły oraz powiązania między nimi) z zawartością dokumentu opisy dotyczące zarządzania cyklem życia dokumentu

21 3. Przeglad dziedziny Celem niniejszej pracy jest przeanalizowanie możliwości tworzenia strukturalnych raportów medycznych zgodnych ze standardem DICOM SR na potrzeby. Z tego też powodu pierwszy podrozdział opisuje przebieg konsultacji medycznej, ze szczególnym uwzględnieniem tworzenia raportu medycznego. Następnie przedstawione są wymagania funkcjonalne i niefunkcjonalne dla systemu, który ma implementować analizowane podejście. Na koniec przedstawione są wzorce dokumentów, ponieważ ich użycie jest podstawowym wymaganiem stawianym aplikacji. Bez niego nie można byłoby używać jej w praktyce. Głównym założeniem podczas projektowania, było dostosowanie do różnych typów raportów medycznych, oraz zapewnienie dużej elastyczności w interfejsie graficznym, używanym przez użytkownika końcowego. Analiza dotycząca dokumentów medycznych została wykonana w oparciu o raport echokardiograficzny. Stanowi on dobrą reprezentację, z uwagi na to, że posiada wszystkie typy danych, które mogą być użyte w DICOM SR. Ponadto jest bardzo mało aplikacji, przeznaczonych właśnie dla tej dziedziny medycyny, które stosują wykorzystywany w tej pracy standard. Dodatkowo planowane jest wdrożenie implementowanego rozwiązania w jednostkach służby zdrowia, poprzez integrację z systemem TeleDICOM [2]. Jest to zaawansowana platforma telemedyczna umożliwiająca współpracę lekarzy specjalistów w wirtualnej przestrzeni. Aplikacja jest przeznaczona dla lekarzy wykorzystujących w swojej pracy wyniki badań obrazowych. Stanowi unikalne połączenie przeglądarki dokumentów DICOM i zaawansowanego narzędzia pracy grupowej pozwalając użytkownikom na wspólne, interaktywne konsultowanie danych pacjentów. Część tworzonej aplikacji miałaby stanowić panel we wspomnianym oprogramowaniu, który odpowiadałby za tworzenie raportu na podstawie danych dostarczanych przez TeleDICOM (wykonywane pomiary) Przebieg konsultacji Niezaprzeczalnym atutem cyfrowej reprezentacji danych medycznych jest możliwość prowadzenia telekonsultacji. Dzięki wykorzystaniu odpowiedniego oprogramowania możliwa jest komunikacja między lekarzami znajdującymi się w różnych ośrodkach medycznych (nawet na osobnych kontynentach). Wykorzystanie cyfrowego zapisu obrazów medycznych pozwala w znaczącym stopniu uzupełnić informacje o konsultowanym przypadku, jak również ułatwia całą rozmowę, przez co konsultacja jest pełniejsza. To z kolei może znacząco zmniejszyć ilość przypadków, w których pacjent musi być fizycznie przenoszony do placówki referencyjnej. 22

22 3.1. Przebieg konsultacji 23 Telekonsultacje ułatwiają wymianę doświadczeń oraz lepsze wykorzystanie wiedzy ekspertów. W konsekwencji przyczynia się to do poprawy jakości opieki medycznej i obniżenia jej kosztów. Dodatkowo młodzi lekarze mogą uczyć się (pytać o radę) od swoich bardziej doświadczonych kolegów, co również ma pozytywny wpływ na ich edukację Rodzaje telekonsultacji Ze względu na sposób współpracy lekarza zlecającego z ekspertem można wyróżnić dwa sposoby prowadzenia telekonsultacji. Telekonsultacje nieinteraktywne - są to konsultacje, gdzie nie jest wymagana wymiana informacji między lekarzami na żywo". W tym modelu lekarz zlecający i ekspert pracują niezależnie od siebie. Konsultacja przebiega dwuetapowo: 1. lekarz zlecający konsultację przygotowuje zestaw badań pacjenta, po czym przesyła go do specjalisty, formułując przy tym żądanie, w którym specyfikuje, co ma zostać zrobione z przesyłanymi danymi. 2. ekspert w dowolnym dla siebie czasie analizuje otrzymane dane i odsyła swoją diagnozę. Jest to najprostszy model konsultacji. W skrajnym przypadku komunikacja mogłaby być zapewniona poprzez wykorzystanie poczty elektronicznej, gdyby zapewniała ona odpowiedni poziom zabezpieczeń, wymagany w zastosowaniach medycznych. Należy również zwrócić uwagę, że w telekonsultacji nieinteraktywnej biorą udział zawsze dwie osoby. Można wyobrazić sobie przypadek, w którym lekarz zleca konsultacje różnym ekspertom, ale nie zmienia to faktu, że prowadzą oni swoje analizy niezależnie od siebie, a w wyniku powstaje wiele różnych diagnoz. Zaletą takiego podejścia jest fakt, że nie wymaga ona zaangażowania obu stron na raz. Rysunek 3.1: Schemat telekonsultacji nieinteraktywnej

23 3.1. Przebieg konsultacji 24 Telekonsultacje interaktywne - cechą charakterystyczną tego modelu, jest wspólna sesja telekonsultacyjna. Z uwagi na to, że w konsultacji jednocześnie może brać udział od dwóch do większej liczby osób, istnieje konieczność zapewnienia interakcji między współpracującymi stronami. Dzięki temu ten model odzwierciedla działania tradycyjnego konsylium lekarskiego. Podstawowymi narzędziami dostępnymi w takich systemach są: interaktywny wskaźnik, który umożliwia wskazywanie przez uczestników obszarów zainteresowania - analogia do wskaźników laserowych używanych podczas prezentacji tworzenie różnego rodzaju obrysów (takich jak linie, elipsy, prostokąty), które służą oznaczaniu (wyróżnianiu) obszarów zainteresowania - mogą pełnić dwojaką funkcję: 1. wyróżniać obszar na temat którego w danej chwili prowadzona jest dyskusja 2. być częścią tworzonej diagnozy - przykładowo mogą oznaczać miejsce wystąpienia jakiś nieprawidłowości, lub służyć do wyliczenia pewnych wartości zamieszczanych w raporcie (takich jak długość, pole powierzchni) narzędzia do komunikacji interaktywnej: tekstowej (typu chat), głosowej, czy wideo Rysunek 3.2: Schemat przykładowej realizacji telekonsultacji interaktywnej

24 3.1. Przebieg konsultacji 25 W tego typu systemach bardzo istotną rolę pełni synchronizacja działań poszczególnych uczestników konsultacji. Przykładowo może ona być zrealizowana za pomocą serwera centralnego, który pośredniczy w wymianie komunikatów w trakcie tworzenia diagnozy. Jego głównym zadaniem jest zapewnienie, aby każdy uczestnik sesji widział taki sam stan wszystkich obiektów, które wchodzą w jej skład. Mimo, że ten model jest dużo bardziej skomplikowany od poprzedniego to daje znacznie większe możliwości. Dzięki zastosowaniu usługi synchronizacyjnej każdy z uczestników widzi na bieżąco wprowadzane zmiany. Przykładowo kiedy jeden lekarz wykona pomiar, przez dokonanie obrysu, pozostali eksperci widzą go i od razu mogą się do niego odnieść Tworzenie telekonsultacji medycznej Utworzenie telekonsultacji medycznej składa się z kilku etapów. Poniżej opisane są elementy, które muszą się pojawić przy konsultacjach interaktywnych: dobór i przygotowanie danych - na początku należy zebrać dane związane z tematem konsultacji, oraz odpowiednio je przygotować. Osoba przygotowująca konsultację powinna wybrać najważniejsze informacje z punktu widzenia tematu (celu) konsultacji, jak również może dokonać ich wstępnej obróbki (w najprostszym przypadku może np. zeskanować papierowe dokumenty). wybór uczestników konsultacji - wybór uczestników konsultacji jest bardzo ważny, gdyż ma bezpośredni wpływ na jej wyniki. Wybór konkretnego uczestnika konsultacji kończy się wysłaniem mu zaproszenia do konsultacji, które może zostać zaakceptowane, lub odrzucone (z podaniem powodu). Zaproszenie powinno zawierać krótki opis tematu konsultacji, oraz informację o jej terminie. wybranie terminu konsultacji - w praktyce jest to jeden z najtrudniejszych kroków, szczególnie jeśli w konsultacji ma brać udział wielu uczestników. Metoda stosowana przy doborze terminu zależy od konkretnej sytuacji. W zależności od potrzeb wybór terminu może być realizowany na co najmniej dwa sposoby: 1. ściśle określony termin - w przypadku konsultacji, które muszą odbyć się jak najszybciej, najlepiej jest ustalić odgórny termin i przesyłać go w zaproszeniu do konsultacji. Wtedy poszczególni uczestnicy przyjmując zaproszenie akceptują dany termin. 2. negocjacja terminu - takie podejście wymaga wspomagania przez odpowiednie oprogramowanie. Może być realizowane na kilka sposobów. Jednym z nich może być wybór części wspólnej spośród preferencji terminów wysyłanych w odpowiedzi na zaproszenie do konsultacji. przesłanie danych - ponieważ dane wykorzystywane w konsultacji mogą być bardzo obszerne (nawet w setkach MB) należy zadbać o wcześniejsze przygotowanie środowiska, poprzez przesłanie plików przed jej rozpoczęciem

25 3.1. Przebieg konsultacji Tworzenie raportu medycznego DICOM SR Wynikiem każdej konsultacji medycznej powinna być diagnoza, która może mieć postać odpowiednio sporządzonego raportu medycznego. Na rysunku 3.3 znajduje się uproszczony schemat powstawania raportu. Na początku lekarz zlecający konsultację musi wybrać odpowiedni szablon (wzorzec) dokumentu. Nawet ten sam raport medyczny (np. echokardiograficzny) może posiadać wiele różnych szablonów, które różnią się ilością informacji, którą można w nich zapisać. Wynika to z istnienia prostych i bardzo złożonych przypadków. W pierwszym przypadku zazwyczaj wystarczy wykonać kilka badań, dlatego też nie ma potrzeby stosować szablonu, który pozwala na wprowadzenie wszystkich możliwych wartości, ponieważ większość z nich nie będzie wprowadzana. Po wyborze odpowiedniego wzorca należy wprowadzić dane o pacjencie oraz samym badaniu. Lekarz ma do wyboru dwie możliwości. Jeśli badania zostały wcześniej wykonane na odpowiedniej maszynie, która w wyniku zwraca dokument DICOM SR, to istnieje możliwość importu jego zawartości do tworzonego raportu (np. z systemu typu PACS [1]). Podczas tej operacji najczęściej kopiowane są również dane pacjenta, oraz badania. Jeśli dokument nie zawiera tych danych, to postępowanie jest identyczne jak przy nowym dokumencie. W przypadku kiedy lekarz musi stworzyć raport od podstaw, dane pacjenta mogą być pobrane z systemu HIS, bądź są wpisywane ręcznie. Wprowadzenie danych pacjenta kończy etap przygotowania raportu do konsultacji i jest on udostępniany ekspertom do analizy (wraz ze wszystkimi badaniami). Eksperci mogą modyfikować zawartość raportu. Lekarz zlecający również może brać udział w tym procesie. Kiedy lekarze stwierdzą, że raport jest pełny, czyli zawiera wszystkie niezbędne dane, oraz poprawną diagnozę, jeden z nich (wybrany jako przewodniczący konsultacji) zmienia status dokumentu z PAR- TIAL na COMPLETE. Oznacza to, że praca z dokumentem została zakończona. Kolejnym krokiem jest zweryfikowanie zawartości dokumentu, oraz jego podpis elektroniczny w celu zagwarantowania niezmienności jego treści. Operacje te mogą być wykonywane zarówno przez twórców raportu, jak również przez inne osoby. Jest to szczególnie przydatne w co najmniej dwóch sytuacjach: podpis i weryfikacja raportu przez jego twórców zapewnia niewypieralność treści w przypadku edukacji młodych lekarzy weryfikacja raportu przez doświadczonego lekarza zwiększa zaufanie do jego treści Lekarz w każdym momencie, kiedy ma dostęp do raportu może usunąć swoją weryfikację i podpis. Dodatkowo istnieje możliwość zmiany treści raportu, który jest w stanie COMPLETE. W tym wypadku musi jednak zostać utworzony nowy dokument, który jest dokładną kopią pierwszego, z dokładnością do weryfikacji i podpisów. Podany schemat tworzenia raportu nie musi dotyczyć jedynie konsultacji medycznych. Wskazana procedura jest taka sama, gdy lekarz tworzy cały raport samodzielnie. W tym przypadku wszystkie kroki wykonuje sam.

26 3.1. Przebieg konsultacji 27 Rysunek 3.3: Uproszczony schemat tworzenia raportu DICOM SR

27 3.2. Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne i niefunkcjonalne Postawiony problem wymagał od autora dogłębnego przemyślenia tematyki tworzenia raportów medycznych oraz działania aplikacji telekonsultacyjnych. W zebraniu wymagań dotyczących aspektów medycznych pomogły liczne konsultacje z dr hab. Andrzejem Gackowskim, kardiologiem Krakowskiego Szpitala Specjalistycznego im. Jana Pawła II. W wyniku powstał zestaw wymagań funkcjonalnych i niefunkcjonalnych Wymagania niefunkcjonalne Podstawowym wymaganiem niefunkcjonalnym było użycie podczas implementacji standardu DI- COM SR, z uwagi na jego cechy, jak również istnienie wielu aplikacji przystosowanych do przechowywania plików DICOM (a więc również DICOM SR). Oprócz tego należy zauważyć, że duża ilość nowoczesnych urządzeń pomiarowych tworzy pliki zgodne z tym standardem, dlatego też tworzona aplikacja mogłaby z nimi współpracować w naturalny sposób (bez dedykowanych warstw pośrednich). Niestety zastosowanie samego standardu jest niewystarczające, żeby aplikacja mogła być praktycznie używana w medycynie. Niezbędne jest użycie wzorców dokumentów, z uwagi na zapewnienie kompatybilności z urządzeniami pomiarowymi, jak również innymi aplikacjami, które korzystają (lub będą w przyszłości) z raportów DICOM SR. Dodatkowo lekarze chcieli mieć możliwość wpływu na strukturę raportu. Chodziło o możliwość uszczegóławiania standardowych wzorców. Obecnie standardem w szpitalach jest wykorzystywanie systemów typu HIS (Hospital Information System), które przechowują dane administracyjne pacjentów. Takie oprogramowanie jest wykorzystywane między innymi w Krakowskim Szpitalu Specjalistycznym im. Jana Pawła II. Tworzona aplikacja powinna w prosty sposób umożliwić integrację z tego typu systemami, w celu przyspieszenia tworzenia raportu (automatyczne pobranie danych o pacjentach). Należy pamiętać, że użytkownikami końcowymi będą lekarze, którzy nie mają wykształcenia informatycznego. Z tego też względu aplikacja powinna cechować się: przeźroczystością - użytkownik końcowy powinien operować na interfejsie graficznym bardzo wysokiego poziomu. Wszystkie operacje przeprowadzane na plikach DICOM SR, powinny zostać przed nim ukryte. Lekarz powinien skupić się na wprowadzaniu niezbędnych danych, a nie na tym w jaki sposób te dane zapisać w raporcie. elastycznością - ponieważ medycyna ma wiele różnych dziedzin, aplikacja powinna zapewniać elastyczność, rozumianą dwojako. Z jednaj strony powinna istnieć możliwość użycia jej w dowolnej dziedzinie medycyny (dynamiczna, elastyczna konfiguracja). Z drugiej strony powinno dać się modyfikować sam interfejs użytkownika w zależności od potrzeb (preferencji) lekarza. Jest to o tyle istotne, że często interfejs jest bardzo rozbudowany, a lekarz przez sporą część swojej pracy wypełnia jedynie kilka pól. łatwością w obsłudze, intuicyjnością - aplikacja powinna być prosta w obsłudze i posiadać przyjazny dla użytkownika interfejs

28 3.2. Wymagania funkcjonalne i niefunkcjonalne 29 pomocą użytkownikowi - w miarę możliwości system powinien wspomagać lekarza. Przykładowo poprzez automatyzację wprowadzania danych pacjenta, podpowiedzi dotyczące diagnozy, tworzenie gotowych do druku raportów Biorąc pod uwagę, że aplikacja docelowo ma działać w środowisku szpitalnym, wymagana jest ochrona przed niechcianą modyfikacją treści dokumentów, oraz niepowołanym dostępem. Jest to wymuszone prawnie przez istnienie tajemnicy lekarskiej [5] oraz ustawę o ochronie danych osobowych [6]. Powinna istnieć możliwość weryfikacji treści dokumentu, oraz użycia podpisu elektronicznego. Jako, że aplikacja miałaby stanowić moduł systemu TeleDICOM [2], konieczne jest użycie środowiska uruchomieniowego.net oraz języka programowania C#. Dodatkowo interfejs użytkownika powinien zostać napisany z wykorzystaniem Windows Presentation Foundation (WPF). Docelowym systemem operacyjnym jest Microsoft Windows XP Aktorzy Dokument DICOM SR może zawierać znaczną ilość informacji (dotyczących pacjenta, szczegółów poszczególnych badań i wiele innych). Dlatego też istnieje konieczność opracowania podzbioru informacji jakie powinien zawierać. Warto zauważyć, że opracowanie takiego szczegółowego raportu wystarczy zrobić raz, a potem używać zdefiniowanego wzorca. W związku z tym można wyróżnić dwóch aktorów: Administrator - specjalista, który tworzy okrojony wzorzec raportu DICOM SR, używany później przez innych lekarzy. Administrator musi, oprócz wiedzy medycznej, znać podstawy standardu DICOM SR, ponieważ określenie wyglądu raportu wiąże się z odpowiednim wyborem podzbioru węzłów, które budują drzewo dokumentu. Lekarz - użytkownik, który używa wzorca stworzonego przez Administratora do tworzenia i wypełniania raportu danymi. Lekarz nie musi posiadać praktycznie żadnej wiedzy o standardzie DI- COM SR. Z uwagi na ich różne role została podjęta decyzja o stworzeniu dwóch współpracujących ze sobą aplikacji: 1. Panel administracyjny - aplikacja, która odpowiada za tworzenie wzorców (dokumentów, interfejsu użytkownika, diagnoz, itp.) dla panelu lekarza. Panel administracyjny byłby wykorzystywany przez Administratora jedynie na etapie wdrożenia aplikacji w szpitalu, w celu dostosowania jej do panujących tam warunków. 2. Panel lekarza - panel wykorzystywany przez Lekarza, jedynie do tworzenia raportu medycznego (wypełniania go danymi) Zależność między modułami jest taka, że wyjście generowane przez panel administracyjny jest wejściem dla panelu lekarza Wymagania funkcjonalne Wymagania funkcjonalne zostały podzielone na oba panele: administracyjny oraz lekarza

29 3.2. Wymagania funkcjonalne i niefunkcjonalne 30 Panel administracyjny Podstawowym wymaganiem funkcjonalnym stawianym tej aplikacji jest możliwość wczytywania różnych wzorców (dotyczących różnych dokumentów), takich jak: raport echokardiograficzny lub mammograficzny. Następnie użytkownik powinien móc wybrać podzbiór węzłów, które chce, żeby znalazły się w tworzonych później raportach. Używane wzorce są bardzo rozbudowane i potrafią mieć kilkaset, a nawet kilka tysięcy węzłów. Przykładowo raport echokardiograficzny ma ponad 1700 węzłów. Z tego też powodu tym bardziej powinno się skasować węzły, które nigdy nie będą użyte (przykładowo, jeśli szpital nie wykonuje jakiś badań, to można usunąć całe poddrzewo, które odpowiada za przechowywanie informacji o nich). Oczywiście nie ma tutaj całkowitej dowolności. Aplikacja powinna dbać o integralność całej struktury. Oznacza to, że przy każdej próbie dodania, bądź usunięcia węzła muszą być sprawdzane warunki dostarczane przez wzorzec, bowiem w niektórych przypadkach usuwanie nie jest możliwe (węzeł wymagalny), lub może się zdarzyć, że dodanie węzła wymusza zmianę wartości innego węzła, itd. Jak łatwo zauważyć takie podejście, gdzie administrator musi ustalić zawartość (strukturę) raportu, posiada dwie bardzo istotne wady: jest to bardzo pracochłonne - należy zaznaczyć dużą ilość węzłów należy dokładnie wiedzieć jakie węzły są używane przez maszyny pomiarowe - w celu zapewnienia kompatybilności Żeby uniknąć (lub zminimalizować) powyższych problemów aplikacja powinna pozwalać na importowanie struktury z istniejącego dokumentu danego rodzaju. Dokumenty medyczne często zawierają informacje o placówce w której zostały utworzone, lub inne zasadniczo niezmieniające się dane. Dlatego też powinna istnieć możliwość przypisania wartości domyślnych dla węzłów drzewa (przykładowo przypisanie na stałe nazwy szpitala). Dzięki temu lekarz nie musiałby podawać za każdym razem stałych wartości, przez co jego praca mogłaby być wykonywana sprawniej. Ponadto administrator powinien móc ustawiać alias węzła (wzorce dokumentów są w języku angielskim; użycie aliasów umożliwia podanie odpowiednika w innym języku), oraz specyficzne własności (takie jak: jednostka, precyzja, dopuszczalne kody, itp.) zależne od jego typu. Po licznych konsultacjach w szpitalu odnośnie interfejsu użytkownika powstały trzy różne koncepcje: 1. dynamiczne tworzenie interfejsu jako listy paneli 2. tworzenie dedykowanego interfejsu, przez aplikację kliencką 3. umożliwienie definiowania interfejsu końcowym użytkownikom Pierwsza koncepcja została odrzucona ze względu na to, że wygenerowany interfejs byłby mało czytelny oraz zajmowałby bardzo dużo miejsca. Druga możliwość powodowała z kolei małą elastyczność aplikacji, dlatego też ostatecznie została wybrana wersja ostatnia. Ma ona dużą przewagę nad dwiema pozostałymi, chociażby z tego powodu, że pozwala użytkownikowi końcowemu rozmieścić wszystkie

30 3.2. Wymagania funkcjonalne i niefunkcjonalne 31 elementy interfejsu zgodnie ze swoimi upodobaniami. W związku z tym, system musi umożliwiać proste i intuicyjne tworzenie interfejsu użytkownika administratorowi, z jednoczesnym zapewnieniem kompatybilności z zawartością dokumentu (np. aplikacja powinna dbać, by nie zaistniała sytuacja, w której interfejs użytkownika zawiera pola do wprowadzania wartości, które nie mają węzła w drzewie dokumentu, który mógłby je przechowywać). Podczas konsultacji w szpitalu okazało się, że jednym z ważniejszych wymagań, jest możliwość późniejszego eksportu zawartości raportu medycznego do formatu aplikacji Microsoft Word. Wymaganie to ma podłoże w procedurach szpitalnych. Mimo, że raport medyczny będzie zapisany w postaci elektronicznej, lekarz często musi móc go wydrukować w ściśle określonej formie. Dlatego też aplikacja powinna mieć możliwość definiowania wzorców dla Microsoft Word, które potem byłyby uzupełniane danymi z panelu lekarza. Oprócz pomiarów różnych wartości, elementem praktycznie każdego raportu medycznego jest diagnoza. Niestety nie istnieje żaden standard, który określałby jej postać. Mimo to system powinien dawać możliwość tworzenia własnych standardowych diagnoz, w formie predefiniowanych wyrażeń, takich jak: "Prawa komora serca prawidłowa". Mechanizm ten ma stanowić pewne rozszerzenie standardu DICOM SR, o standardowe teksty diagnozy. Kolejne wymaganie jest ściśle związane z poprzednim. Mianowicie mając zdefiniowany zbiór możliwych diagnoz, możemy pokusić się o stworzenie reguł, mówiących kiedy dana diagnoza jest prawdziwa. Dlatego też system powinien posiadać edytor pozwalający na proste definiowanie takich reguł. Jako, że tworzona aplikacja miałaby być wykorzystywana przez zewnętrzne aplikacje pojawiło się wymaganie dotyczące zapisu metadanych pozwalających na poprawną komunikację z panelem lekarza. Przykładowo mogą to być identyfikatory węzłów drzewa dokumentu, lub nazwy możliwych do wykonania pomiarów, które muszą być przesyłane razem z właściwymi danymi. pracy. Oczywistą rzeczą jest, że użytkownik powinien również móc zapisywać i odczytywać wyniki swojej Panel lekarza Panel lekarza korzysta z plików utworzonych przez panel administracyjny, dlatego też podstawowym wymaganiem, jest umiejętność odczytywania ich. Jako że głównym zadaniem tej aplikacji jest umożliwienie wprowadzania danych do raportu, powinna istnieć możliwość wprowadzania oraz modyfikacji danych o: pacjencie i badaniu prowadzonych pomiarach diagnozie Pomiar każdej wielkości może być wykonywany wielokrotnie (przez maszynę lub lekarza), dlatego system musi wyświetlać zagregowane w odpowiedni sposób wartości (sposób agregacji ustalony w panelu administracyjnym). Ponadto użytkownik musi mieć możliwość przeglądania szczegółów pomiaru, gdzie może:

31 3.2. Wymagania funkcjonalne i niefunkcjonalne 32 przeglądać poszczególne pomiary usuwać pomiary dodawać pomiary - czasem istnieją sytuacje, gdzie lekarz musi podać pewne wartości kierując się własną intuicją Oczywiście aplikacja musi zadbać dodatkowo o odpowiednią konwersję jednostek, żeby dane były spójne. Oprócz wprowadzania wartości do raportu (takich jak dane o pomiarach, wartości kodowe itp.) lekarz musi postawić jakąś diagnozę. System powinien mu w tym pomagać na dwa sposoby: 1. zapewnić edytor diagnoz z którego lekarz szybko mógłby wybrać interesujące go zwroty (pełne zdania), oraz w razie konieczności wpisać własny tekst 2. umożliwić skorzystanie z systemu regułowego, który sam (na podstawie dotychczas zmierzonych wartości) postara się dopasować odpowiednie zwroty tworzące diagnozę. Oczywiście użytkownik może je potem modyfikować Ważnym elementem jest zapewnienie odpowiedniego zarządzania dokumentem. Lekarz powinien móc: zmienić wartość flagi Completition Flag z PARTIAL na COMPLETE, kiedy stwierdzi, że dokument jest poprawny i nie będzie już modyfikowany zmienić wartość flagi Completition Flag z COMPLETE na PARTIAL, w przypadku gdy podczas weryfikacji okazało się, że należy zmodyfikować jakąś część raportu. W tym wypadku musi zostać utworzony fizycznie drugi plik, będący kopią pierwszego, z uwagi na to, że pierwszy z nich mógł zawierać weryfikacje i podpisy elektroniczne, które nie będą już aktualne podpisać dokument za pomocą swojego certyfikatu - certyfikat jest elektronicznym zaświadczeniem za pomocą którego dane służące do weryfikacji podpisu elektronicznego są przyporządkowywane do określonej osoby i potwierdzają tożsamość tej osoby [7]. Zawiera on wiele informacji, takich jak wystawca, ważność, podmiot dla którego został wydany, klucz publiczny, oraz podpis organu wydającego certyfikat. W każdym momencie można zweryfikować prawdziwość certyfikatu za pomocą klucza publicznego jego wystawcy (dobrze znany). Każdy użytkownik posiada swój własny klucz prywatny, który służy do podpisywania dokumentów oraz certyfikat, który potwierdza prawdziwość jego klucza publicznego (służącego do weryfikacji podpisu dokumentu). Zarówno klucz prywatny, jak i certyfikat są zapisywane w oddzielnych plikach (.pem), które są wykorzystywane przez bibliotekę DCMTK [8] dokonać weryfikacji, potwierdzonej podpisem elektronicznym - dane o osobie weryfikującej powinny być pobierane z certyfikatu usuwać swój podpis elektroniczny i weryfikację

32 3.2. Wymagania funkcjonalne i niefunkcjonalne 33 Z uwagi na to, że większość danych jest już zapisywana przez urządzenia pomiarowe musi istnieć możliwość eksportu tych informacji. Mechanizm powinien zapewnić pobieranie wszystkich danych, zarówno dotyczących pacjenta i badania, jak i samych pomiarów i diagnoz. W przypadku, kiedy używany wzorzec dokumentu, nie zawiera jakiś węzłów, które znajdują się w eksportowanym raporcie, powinny być one pomijane. Dodatkowo powinny być odczytywane wszystkie informacje odnośnie weryfikacji, oraz podpisów elektronicznych. Dodatkową funkcjonalnością, na którą duży nacisk kładli lekarze, jest możliwość eksportu zawartości raportu do pliku Microsoft Word, przy wykorzystaniu wzorca zdefiniowanego w panelu administracyjnym. Powinna istnieć możliwość eksportu wszystkich wyświetlanych informacji, czyli zarówno zagregowanych wartości pomiarowych, jak również danych pacjenta i badania. Oczywiście musi istnieć również możliwość zapisywania raportu w formacie DICOM SR Struktura przetwarzania W celu lepszego zrozumienia działania aplikacji, należy przeanalizować schemat przetwarzania, od momentu rozpoczęcia pracy nad uszczegółowionymi wzorcami do stworzenia kompletnego raportu zawierającego konkretną treść. Uproszczony schemat został przedstawiony na rys Rysunek 3.4: Uproszczony schemat sporządzania raportu

33 3.3. Wzorce dokumentów 34 Pracę należy rozpocząć oczywiście od stworzenia skonkretyzowanego wzorca, który będzie odpowiednio dopasowany do placówki, gdzie zostanie potem użyty (uwzględnienie wykonywanych zabiegów, danych dotyczących szpitala, itp.). W tym celu administrator musi wykorzystać panel administracyjny. Swoją pracę zaczyna od wczytania odpowiedniego wzorca ogólnego (inny wzorzec będzie dla raportu echokardiograficznego, a inny dla mammograficznego) zapisanego w pliku xml. W tym momencie można przystąpić do strojenia wzorca do konkretnego zastosowania. Dodatkowo istnieje możliwość importu struktury i niektórych własności z istniejącego dokumentu DICOM SR, w celu ułatwienia i przyspieszenia pracy. Użytkownik może również dołączyć wzorzec dokumentu w formacie aplikacji Microsoft Word, jeśli chce mieć możliwość późniejszego eksportu danych do tego formatu. Poszczególne pliki wynikowe są zapisywane (oraz w razie potrzeby odczytywane) w odpowiednim archiwum reprezentującym uszczegółowiony wzorzec. Dzięki temu użytkownicy końcowi nie muszą operować na wielu plikach. Zawartość archiwum jest dla nich nieistotna, a dodatkowo zapewnia to spójność i integralność danych (trudniej jest ręcznie podmienić poszczególne pliki, lub np. zapomnieć przenieść jednego z nich). Kiedy wzorzec jest gotowy, można zacząć używać panelu lekarza, który stanowi moduł aplikacji TeleDICOM [2]. Panel lekarza na początku swojej pracy musi wczytać przygotowany wcześniej wzorzec, żeby móc poprawnie działać. Od tego momentu możliwa jest interakcja z aplikacją. Z uwagi na to, że operujemy na fizycznych plikach DICOM SR oczywistą rzeczą jest, że można zarówno importować ich zawartość, jak również potem zapisywać utworzony raport. Tworzenie raportu może odbywać się dwojako. Użytkownik ma możliwość wprowadzania danych ręcznie z poziomu panelu lekarza, lub modyfikacje mogą być przeprowadzane z poziomu aplikacji TeleDICOM [2]. W drugim przypadku interakcje między aplikacjami odbywają się za pomocą zdarzeń (events) przesyłanych między nimi. Wyjściem aplikacji mogą być: plik DICOM SR utworzony zgodnie ze wzorcem - niektóre dane znajdujące się w pierwotnym pliku (jeśli został on wcześniej wczytany) mogą zostać pominięte, jeśli wzorzec nie przewidywał ich wystąpienia plik Microsoft Word, do którego budowy został wykorzystany wzorzec dołączony w panelu administratora 3.3. Wzorce dokumentów Jedną z zalet standardu DICOM SR jest jego elastyczność. Za jego pomocą twórca dokumentu może opisać drzewo informacji na bardzo wiele różnych sposobów. Niestety jest to również duża wada, z uwagi na to, że bez jakiś dodatkowych wskazówek, różni autorzy mogą stworzyć raporty o różnej strukturze w celu oddania tej samej treści. Jak łatwo zauważyć, może sprawiać to problem zarówno lekarzowi, który czyta raport (zawsze musi szukać interesujących go informacji w różnych miejscach), jak również dla aplikacji, które mają wyszukiwać, przetwarzać i prezentować raporty. Wzorce dokumentów są pewnego rodzaju zbiorem wskazówek, ograniczeń i warunków nakładanych na raporty DICOM SR, w celu uniknięcia problemów, o których była mowa wcześniej.

34 3.3. Wzorce dokumentów 35 Standard nie definiuje formatu wzorców. Może to być zwykły plik tekstowy, xml, lub dowolna inna reprezentacja. Niezależnie od formy zapisu, każdy wzorzec definiuje strukturę dokumentu, opisywaną poprzez: typy węzłów, które mogą wchodzić w skład dokumentu, oraz ich Concept Name sposób połączeń (relacje) między węzłami dopuszczalne wartości jakie mogą być używane i ich ograniczenia wymagalność wystąpienia węzła (warunki pod którymi może on wystąpić) liczność węzła Rysunek 3.5: Fragment wzorca raportu echokardiograficznego W niniejszej pracy zostały wykorzystane wzorce opisane w 16 części standardu DICOM Content Mapping Resource [9]. Ze względu na utrudniony dostęp (pdf), skorzystano z kopii definicji wzorców umieszczonej na stronie: Niestety w internecie brak jest jakichkolwiek gotowych do przetwarzania plików ze wspomnianymi definicjami (np. w formacie xml).

35 3.3. Wzorce dokumentów 36 Wzorce na stronie dabsoft zostały zamieszczone jako tabele HTML. Przykładowy wzorzec jest przedstawiony na rys Kolejne kolumny oznaczają: identyfikator węzła we wzorcu - używany głównie w warunkach wystąpień węzłów NL - wartością jest zero lub więcej znaków >. Kolumna określa stopień zagnieżdżenia w drzewie. Węzeł o liczbie znaków > równej n, jest dzieckiem węzła posiadającego n-1 znaków > Rel. with Parent - określa relację łączącą węzeł z jego rodzicem VT - typ węzła, lub wartość INCLUDE określająca, że w tym miejscu należy dołączyć inny wzorzec (jego dane znajdują się w kolumnie Concept Name) Concept Name - może mieć różne wartości (konkretna wartość, zbiór dopuszczalnych wartości, referencja do innego wzorca) VM - liczność (możliwa liczba wystąpień) Req. Type - może przyjąć jedną z wartości: M - węzeł musi być obecny U - węzeł jest opcjonalny MC - węzeł musi być obecny jeśli spełniony jest warunek z kolumny Condition UC - węzeł może być obecny pod warunkiem, że jest spełniony warunek z kolumny Condition Condition - warunek wystąpienia węzła. Warunki mogą być dość złożone i są pisane w języku naturalnym. Przykładowymi wartościami są: XOR Rows 2, 3 IFF Row 1 value = (121006,DCM, Person ) or Row 1 is absent May be present only if value of parent is not (111102, DCM, Non-lesion ) At least one of Rows 8, 9 and 10 shall be present i wiele innych... Value Set Constraint - kolejna kolumna, która może mieć dość złożoną zawartość, którą może być: ograniczenia dotyczące zawartości węzłów (np. zbiór dopuszczalnych wartości kodowych, lub maksymalna długość znaków) definicja zmiennych, które potem są używane w dołączanych wzorcach

36 3.4. Podsumowanie Podsumowanie W pierwszej części zostały opisane dwa podstawowe rodzaje konsultacji medycznych: interaktywna i nieinteraktywna. Jako że praca skupia się głównie na problematyce tworzenia raportów medycznych poprzez wykorzystanie aplikacji telekonsultacyjnych, szerzej została opisana konsultacja interaktywna (ponieważ jest częściej wykorzystywana w tego typu systemach). Opis zawiera następujące elementy: ogólny schemat realizacji konsultacji interaktywnej, schemat tworzenia konsultacji, opis tworzenia raportu DICOM SR w takich warunkach. Na podstawie analizy wymagań funkcjonalnych i niefunkcjonalnych wyodrębnieni zostali aktorzy korzystający z systemu, jak również została podjęta decyzja o utworzeniu dwóch aplikacji: panelu administratora oraz lekarza, których wzajemne zależności zostały pokazane na stosownym diagramie 3.4. Na koniec został opisany bardziej szczegółowo format wzorców raportów DICOM SR, który jest zdefiniowany w suplemencie do standardu DICOM [9], ponieważ informacje te będą wykorzystane w części implementacyjnej.

37 4. Wybrane aspekty realizacji Kolejne punkty tego rozdziału zawierają opis poszczególnych artefaktów, jakie powstały w trakcie tworzenia pracy. Najpierw przedstawione są użyte technologie z krótkim uzasadnieniem ich wyboru. Następny podrozdział jest poświęcony prototypowi tworzonej aplikacji, po czym zawarte są opisy właściwych wyników pracy, do których zaliczają się: wzorce dokumentów DICOM SR w formacie xml, które stanowią wkład autora pracy w ich rozwój - pozwalają na szersze ich stosowanie z racji zastosowania wygodnego w przetwarzaniu formatu, panel przeznaczony dla administratora, opis używanych formatów do tworzenia reguł automatycznej dedukcji diagnozy, jak również krótki opis plików wynikowych panelu administracyjnego, panel przeznaczony dla użytkownika końcowego, jakim jest lekarz tworzący raport DICOM SR na podstawie wyników badań pacjenta Użyte technologie i biblioteki Na rysunku 4.1 zostały przedstawione technologie i biblioteki użyte do implementacji aplikacji. Poniżej znajduje się opis każdej z nich. Office DCMTK toolkit [10] - jest to biblioteka napisana w języku C/C++, która pozwala na tworzenie, oraz odczyt binarnych plików DICOM SR. Jest ona bardzo rozbudowana i obsługa standardu DICOM SR jest jedynie jej niewielką częścią, dlatego implementowana aplikacja korzysta jedynie z kilku pakietów: dcmsr - zestaw klas reprezentujących raport DICOM SR, jak również drzewo jego zawartości i poszczególne typy węzłów, oraz połączeń między nimi. dcmdata - biblioteka pozwalająca na operowanie na binarnych plikach DICOM (a więc również DICOM SR). Podczas implementacji została użyta do zapisywania, odczytywania, oraz przetwarzania struktury raportów. dcmsign - zapewnia obsługę podpisu elektronicznego config, ofstd - biblioteki współdzielone przez wszystkie pakiety DCMTK. Zawierają między innymi definicje własnych typów. 38

38 4.1. Użyte technologie i biblioteki 39 Rysunek 4.1: Stos technologiczny prezentujący użyte technologie i biblioteki Na potrzeby tworzonej aplikacji wykonano kilka drobnych zmian w implementacji biblioteki. Przede wszystkim było to dopisanie niezbędnych elementów, które pozwalały na użycie części funkcjonalności z poziomu języka C#. W projekcie została użyta wersja DCMTK toolkit [8], która była skompilowana z użyciem Visual Studio 2010, oraz narzędzia CMake. W wyniku otrzymano bibliotekę łączoną dynamicznie (dll). W związku z tym powstało dodatkowe wymaganie odnośnie systemu operacyjnego na którym może być uruchamiana aplikacja. Musi być zainstalowany Visual C++ runtime DCMTK wrapper C# - z uwagi na to, że biblioteka DCMTK jest napisana w języku C/C++ powstała konieczność użycia odpowiedniego wrappera dla języka C#. Mimo użycia niewielkiego podzbioru pakietów DCMTK toolkit, ilość używanych klas była znaczna, dlatego ręczne pisanie wrappera byłoby bardzo czasochłonne. W związku z tym podjęta została decyzja o użyciu narzędzia SWIG (Simplified Wrapper and Interface Generator) [11] do jego automatycznej generacji. W tym procesie został użyty zestaw dyrektyw zaproponowany w załączniku do pracy magisterskiej Pawła Kupińskiego [12]. DICOM SR Library C# - niestety po stworzeniu aplikacji demonstracyjnej, która w całości wykorzystywała opisany wyżej wrapper, okazało się, że takie podejście jest bardzo niewydajne. Wiąże się to z koniecznością częstych odwołań przez warstwę pośrednią, co powodowało duży narzut na samo wywoływanie poszczególnych metod. W związku z tym została podjęta decyzja o stworzeniu własnej biblioteki do obsługi standardu DICOM SR. Zaimplementowana biblioteka dostarcza wszystkich niezbędnych metod, do tworzenia, oraz wyszukiwania w raportach DICOM SR. Oprócz tego zapewnia współpracę z formatem wzorców dokumentów opisanym w rozdziale 3.3. Biblioteka korzysta z DCMTK toolkit [8] jedynie w momencie wykonywania operacji na plikach binarnych DICOM SR. Spowodowało to znaczny wzrost szybkości aplikacji.

39 4.2. Prototyp Prototyp W celu sprawdzenia wybranych bibliotek, oraz ułatwienia zbierania wymagań powstał prototyp aplikacji. Stanowi on realizację modelu konsultacji synchronicznej opisanej w rozdziale Rysunek 4.2: Okno konsultacji Prototyp składał się z części serwerowej oraz klienckiej. Komunikacja między nimi była zapewniona, poprzez wykorzystanie warstwy middleware ICE (Internet Communication Engine) [13]. Realizował on podstawowe funkcjonalności takie jak: tworzenie konsultacji (dokumentu DICOM SR) na podstawie istniejącego pliku, lub specjalnie przygotowanego wzorca, możliwość przeglądania i dołączania się do istniejących konsultacji, tworzenie, oraz modyfikację struktury dokumentu, przeglądanie dołączonych danych obrazowych, kreślenie obrysów na obrazach, komunikację między lekarzami za pomocą prostego komunikatora tekstowego. Okno konsultacji (rys. 4.2) pozwalało na jednoczesną modyfikację poszczególnych wartości raportu przez wielu lekarzy. Każdy z nich miał przydzielony inny kolor czcionki (który każdy z uczestników mógł dowolnie modyfikować), żeby było wiadomo, kto wprowadził informacje w danym miejscu. Ponadto była możliwość komunikowania się w trakcie konsultacji za pomocą prostego komunikatora. Oprócz prostego wpisywania wartości, użytkownicy mogli modyfikować strukturę raportu, przez dodawanie bądź usuwanie dowolnych jego fragmentów. Podczas dodawania nowego węzła do drzewa

40 4.3. Wzorce dokumentów DICOM SR w formacie xml 41 raportu należało podać jego Concept Name, typ, oraz relację łączącą go z rodzicem. Wszelkie zmiany było od razu propagowane do wszystkich uczestników konsultacji (zarówno zmiany treści, jak również struktury). Dodatkowo istniała możliwość dodawania obrazów medycznych, zaznaczania na nich różnych obrysów, jak również wykonywania pomiarów. Narzędzie pomiarowe było dobierane automatycznie po kliknięciu w pole, gdzie miała znajdować się jego wartość. Do prezentacji obrazów DICOM, oraz tworzenia wspomnianych krzywych wykorzystana została biblioteka LEADTOOLS w wersji 17.5 [14]. Wszystkie operacje wykonywane przez uczestników konsultacji były wykonywane za pośrednictwem strony serwerowej, która pełniła rolę synchronizującą (tak jak zostało to pokazane na rysunku 3.2, w rozdziale 3.1.1). Wszystkie zmiany były najpierw zapisywane w fizycznym pliku DICOM SR, a następnie poszczególne akcje były delegowane do pozostałych uczestników konsultacji. Konsultacje mogły być tworzone na podstawie wzorców zapisanych w formacie xml. Ich struktura i zawartość nie opierały się w żadnym stopniu na istniejących dokumentach szpitalnych. Służyły sprawdzeniu, czy da się za ich pomocą opisać w sensowny i pełny (uwzględniający wszystkie niezbędne aspekty) sposób raport DICOM SR. Prototyp został wykorzystany głównie do sprawdzenia możliwości wykorzystania w praktyce biblioteki DCMTK [8]. Oprócz tego pełnił istotną rolę w dialogu, podczas doprecyzowywania wymagań aplikacji. Wnioski Stworzona aplikacja udowodniła, że da się wykorzystać standard DICOM SR w praktyce. Ponadto ujawniła bardzo istotne problemy wydajnościowe, co w konsekwencji spowodowało podjęcie decyzji o implementacji własnej biblioteki do operowania na dokumentach DICOM SR. Kolejną zaobserwowaną rzeczą, było podejście do implementacji interfejsu użytkownika. Okazało się, że: generowany interfejs nie wygląda dobrze, a informacje w nim prezentowane są bardzo rozproszone po dokumencie, co utrudnia ich odczyt umożliwienie lekarzom modyfikowania struktury dokumentu podczas wypełniania go danymi nie ma uzasadnienia praktycznego, ponieważ lekarz nie ma na to czasu podczas swojej codziennej pracy 4.3. Wzorce dokumentów DICOM SR w formacie xml Tworzona aplikacja miała wykorzystywać wzorce dokumentów, o których była mowa w rozdziale 3.3. Niestety pojawiło się kilka problemów z tym związanych: wszystkie wzorce są zdefiniowane jako tabele html - w związku z tym powstała konieczność stworzenia prostej aplikacji, która je pobierze i przygotuje do kolejnego przetwarzania format zaproponowany przez dabsoft jest trudny w przetwarzaniu - pojawiła się konieczność translacji do formatu xml

41 4.4. Panel administracyjny 42 Aplikacja, która realizuje wspomniane funkcjonalności została napisana w języku Python. Pobranie wzorców: Na początku należało pobrać wzorce TID (dotyczące struktury raportów), oraz CID (zawierające dopuszczalne wartości kodowe, wykorzystywane we wzorcach TID). Zadanie to było ułatwione biorąc pod uwagę strukturę strony dabsoft, skąd były one pobierane. Pod adresem znajduje się pełna lista odnośników do poszczególnych elementów standardu DICOM SR. Między innymi są tam linki dotyczące interesujących nas wzorców. Wykorzystując prostą zależność, że odnośnik do opisu wzorca, kończy się sekwencją TID_[numer wzorca] (CID_[numer wzorca]), można było wybrać podstrony, które należy dalej parsować. Każdy opis zawiera w sobie tabelę html. W związku z tym pobierane zostały wartości z poszczególnych wierszy i zapisywane w pliku tekstowym o nazwie odpowiadającej nazwie wzorca. Poszczególne wartości były oddzielane znakami tabulacji. Przetwarzanie pobranych wzorców do formatu xml: Kolejnym etapem było przetworzenie pobranych danych do formatu xml. Z uwagi na to, że zarówno warunki wystąpienia węzła, jak również ograniczenia na wprowadzane wartości były w znacznym stopniu pisane bez wykorzystania jakiejś ustalonej notacji, pojawiła się konieczność wykorzystania przetwarzania języka naturalnego. Została wykorzystana metoda zaproponowana przez Rogera Schanka o nazwie Conceptual Dependency [15]. Głównym założeniem w tym podejściu jest przyjęcie, że znaczenie danego zdania jest zawarte głównie w wyrazach które się tam znajdują a nie w strukturze zdania, lub w odmianach tych wyrazów. Przykładowo informację o chęci kupna kawy w sklepie można przedstawić na wiele różnych sposobów. Mimo to prawdopodobieństwo wystąpienia niektórych wyrazów jest większe niż innych (np. kawa, sklep, kupić). Bazując na tej obserwacji tworzone są tzw. skrypty, które służą do rozpoznawania znaczenia zdania. W niniejszej pracy nie było potrzeby wykorzystywania mechanizmu skryptów. Wykorzystano jednak podejście do analizowania znaczenia zdania na podstawie występowania wyrazów kluczowych, co okazało się być wystarczające do rozwiązania przedstawionego wyżej problemu Panel administracyjny Głównym celem aplikacji jest wspomaganie tworzenia szczegółowych wzorców raportów medycznych. Mimo, że istnieją ściśle ustalone wzorce ogólne, które opisują strukturę dokumentów, to często są one bardzo rozbudowane, a lekarze nie korzystają z dużej liczby pól, które są w nich przewidziane. Przykładowo szpital może nie wykonywać niektórych badań, więc z góry wiadomo, że niektóre elementy raportu nigdy się nie pojawią. W związku z tym należy stworzyć wzorzec szczegółowy, który będzie dopasowany do warunków panujących w danej jednostce. Głównymi funkcjonalnościami oferowanymi przez ten moduł są: wczytywanie ogólnie przyjętych wzorców dokumentów import struktury istniejącego dokumentu

42 4.4. Panel administracyjny 43 możliwość wyboru węzłów, które mogą znaleźć się w raporcie - automatyczne dbanie o zachowanie zgodności z wzorcem ogólnym (spełnienie warunków na wystąpienie danego węzła) ustawianie różnych własności węzłów tworzenie GUI, za pomocą odpowiedniego edytora tworzenie hierarchii diagnoz, przyspieszającej późniejsze jej tworzenie przez lekarza definiowanie reguł służących do automatycznego wstawiania diagnoz wspomaganie tworzenia wzorca w programie Microsoft Word zapis/odczyt wyników pracy do pojedynczego pliku Rozpoczęcie pracy - po uruchomieniu aplikacji użytkownik musi wybrać wzorzec dokumentu, dla którego chce stworzyć bardziej szczegółowy odpowiednik. Obecnie jest do wyboru tylko raport echokardiograficzny. Oprócz tego w tym miejscu można wczytać wcześniej zapisany plik z wynikami pracy. Rysunek 4.3: Okno wyboru wzorca Główne okno programu - wczytany wzorzec jest prezentowany w oknie pokazanym na rysunku 4.4. Po lewej stronie znajduje się drzewo dokumentu DICOM SR, którego węzły są odpowiednio oznaczone: * i pogrubiona nazwa oznaczają, że węzeł jest wymagany przez standard (nie da się go usunąć) nazwy rozpoczynające się od znaku # - są to węzły, których wystąpienie jest wymagalne przez standard, z tą różnicą, że mają one przypisany warunek wystąpienia. Często próba wstawienia, bądź usunięcia takiego węzła wymusza zmianę struktury dokumentu (przykładowo istnieje wykluczenie z innym węzłem). W takim wypadku użytkownik zostanie poinformowany o konsekwencjach wyboru węzła (tak jak to zostało pokazane na rysunku 4.4) węzły z niebieskim tłem są węzłami wielokrotnymi (ich poddrzewo może występować w raporcie końcowym wiele razy)

43 4.4. Panel administracyjny 44 Z prawej strony znajduje się panel z trzema zakładkami, które pozwalają na ustawianie własności węzłów, tworzenie interfejsu użytkownika, oraz wzorców dla programu Microsoft Word (poszczególne zakładki są opisane poniżej) Rysunek 4.4: Główne okno aplikacji AdminPanel Rysunek 4.5: Menu aplikacji AdminPanel Okno główne posiada menu, za którego pomocą można: utworzyć nowy wzorzec - należy wybrać dla jakiego dokumentu otworzyć istniejący wzorzec (wcześniej zapisany) zapisać zmiany w tworzonym wzorcu - wyniki pracy są zapisywane jako plik.med zapisać wzorzec do nowego pliku.med dokonać importu struktury dokumentu z istniejącego pliku DICOM SR - wtedy wszystkie węzły występujące w dokumencie zostaną zaznaczone. Procedura importu pobiera jedynie strukturę do-

44 4.4. Panel administracyjny 45 kumentu, nie są brane pod uwagę wartości węzłów. Przykładowo, jeśli dla raportu echokardiograficznego poddrzewo dla wyników pomiarów prawej i lewej komory różnią się jedynie wartością węzła Finding Site, to jeśli importowany plik zawiera jedynie pomiary dla lewej komory, to po imporcie zostaną zaznaczone również węzły związane z prawą komorą. Ustawianie własności węzłów - zakładka Properties zawiera listę własności, które można nadawać poszczególnym węzłom. Ich ilość zależy od typu węzła, którego dotyczą. Własności mogą być przypisywane jedynie węzłom, które mogą pojawić się w raporcie. Wszystkie węzły mają wspólny pole Alias. Z jego pomocą istnieje możliwość nadania nazwy węzła w innym języku niż angielski. W większości przypadków wartość tego pola będzie równoznaczna z etykietą panelu dodawanego do interfejsu użytkownika. Inne własności są intuicyjne, dlatego wszystkie możliwe zakładki nie będą tutaj opisywane. Na szczególną uwagę zasługują dwie z nich (dotyczące pomiarów i diagnoz), ze względu na ich złożoność. Własności węzła pomiarowego - węzeł pomiarowy jest najczęściej wykorzystywany w raporcie, z uwagi na charakter przechowywanych w nim informacji. Poniżej znajduje się lista własności, jakie można mu przypisać: nazwę agregującą wszystkie pomiary reprezentowane przez węzeł. Przykładowo dla węzła reprezentującego pomiary dla lewej komory wartość może być lewa komora". Podana wartość jest używana w dwóch miejscach: edytorze reguł do automatycznego wstawiania diagnoz pliku generowanym dla zewnętrznej aplikacji (TeleDICOM [2]), który służy do generacji menu kontekstowego dotyczącego pomiarów nazwę pomiaru dla którego definiowane są pozostałe własności. We wzorcu pojedynczy węzeł pomiarowy może reprezentować wiele różnych pomiarów, które mogą posiadać różne własności (np. jednostkę) identyfikator, oraz etykietę wstawianą do wzorca przygotowanego w aplikacji Microsoft Word alias dla konkretnego pomiaru jednostkę - użytkownik musi zadbać o wybór odpowiedniej jednostki. Podczas importu struktury istniejącego dokumentu jednostka również jest pobierana agregator dla wartości. Dana wielkość może być mierzona wielokrotnie, na wiele sposobów. Lekarza interesuje jednak jedna zagregowana wartość zaokrąglenie - dopuszczalne są wartości dodatnie i ujemne. Zasada zaokrąglania jest obrazowana na odpowiedniej etykiecie w zakładce. Podawana wartość oznacza przesunięcie od przecinka. Dodatnie wartości przesuwają w prawo, ujemne zaś w lewo. Przykładowo jeśli wartość początkowa wynosi 123,456 to zaokrąglenie o wartości 2 wynosi 123,46 natomiast jeśli wartość będzie zmieniona na -2, to w wyniku użytkownik zobaczy 100

45 4.4. Panel administracyjny 46 listę narzędzi pomiarowych, którymi dana wielkość może zostać zmierzona Własności węzła przechowujacego diagnozy - na wstępie należy wspomnieć, że węzeł przechowujący diagnozy został dodany do wzorca przez autora. Pierwotne wzorce nie zawierały węzłów, gdzie można byłoby przechowywać informacje o diagnozie. W związku z tym aplikacja zawsze dodaje jako ostatni węzeł drzewa każdego dokumentu węzeł do zapisu diagnozy. (a) Własności węzła przechowującego diagnozy (b) Edytor reguł służących do automatycznego wyboru diagnozy Rysunek 4.6: Elementy związane z węzłem przechowującym diagnozy Zakładka pozwala na: dodanie i usuwanie grup diagnoz. Grupa diagnoz zawiera definicje możliwych stwierdzeń dla jakiegoś regionu, przykładowo dla lewej komory. Podana w tym miejscu nazwa jest również wykorzystywana jako etykieta w GUI ustawienie identyfikatora, oraz etykiety wstawianej do wzorca przygotowanego w aplikacji Microsoft Word tworzenie możliwych elementów diagnozy, które potem mogą być wybierane przez lekarza podczas wypełniania raportu danymi. Stwierdzenia mogą być grupowane. Tworzona hierarchia jest wizualizowana w postaci drzewa. Każde stwierdzenie jest opisywane za pomocą skrótu (wartość wyświetlana użytkownikowi), oraz pełnego tekstu, który jest wstawiany do raportu jako element diagnozy. Użytkownik ma również możliwość definiowania wykluczeń między stwierdzeniami, poprzez proste przeciąganie odpowiednich węzłów do obszaru oznaczonego jako "Wykluczenia" Własności węzła przechowujacego diagnozy (definiowanie reguł) - oprócz wymienionych wyżej własności administrator może dla każdego stwierdzenia stworzyć listę reguł, które posłużą do automatycznego wstawiania ich do diagnozy. Z uwagi na to, że użytkownicy końcowi nie muszą posiadać wykształcenia informatycznego został stworzony prosty edytor do tworzenia wspomnianych reguł.

46 4.4. Panel administracyjny 47 Rysunek 4.7: Edytor do tworzenia graficznego interfejsu użytkownika aplikacji AdminPanel Tworzone reguły dotyczą jedynie wartości pomiarowych, które dodatkowo muszą posiadać odpowiadający im panel w interfejsie użytkownika. Sam proces definiowania reguł jest stosunkowo prosty i składa się z kilku etapów: 1. wybór grupy z której ma pochodzić pomiar którego dotyczy fragment tworzonej reguły - nazwa grupy jest pobierana z ustawionej własności węzła pomiarowego. Jeśli wartość ta nie jest ustawiona pomiary są grupowane pod wspólną etykietą "unspecified" 2. wybór nazwy mierzonej wielkości 3. ustawienie odpowiedniego operatora 4. wpisanie wartości referencyjnej Poszczególne elementy reguły są wyświetlane użytkownikowi i ma on możliwość ich usuwania oraz modyfikacji. Elementy reguły są łączone spójnikiem koniunkcji logicznej, natomiast poszczególne reguły dotyczące tego samego stwierdzenia są połączone za pomocą alternatywy. Edytor do tworzenia interfejsu użytkownika - Edytor GUI pozwala na tworzenie interfejsu użytkownika, który potem będzie wykorzystany w panelu lekarza. Edytor jest bardzo prosty, pozwala na wstawianie elementów grupujących (GroupBox) za pomocą menu kontekstowego, oraz paneli reprezentujących węzły raportu techniką drag and drop. Każdy komponent GUI posiada swoje własności, które można modyfikować w panelu po prawej stronie (sam panel można ukryć). Po przełączeniu się na

47 4.4. Panel administracyjny 48 zakładkę z edytorem GUI zmienia się również wygląd drzewa obrazującego strukturę dokumentu. Do GUI można wstawić tylko węzły, które są zaznaczone czarną czcionką. Węzeł może być wstawiony w przypadku, gdy: jest wybrany jako element wzorca żaden z jego przodków nie jest węzłem wielokrotnym (za wyjątkiem węzłów reprezentujących pomiary) w przypadku węzła przechowującego diagnozy musi być stworzona jakaś grupa diagnoz Panele odpowiadające poszczególnym węzłom są tworzone automatycznie, a ich postać zależy od typu węzła. W przypadku węzłów pomiarowego i diagnozy, wstawiany jest panel reprezentujący odpowiednio: wybraną aktualnie w zakładce "Properties nazwę mierzonej wielkości, oraz nazwę grupy diagnoz. Wszystkie elementy interfejsu można usuwać za pomocą menu kontekstowego. Tworzenie wzorców raportów za pomoca aplikacji Microsoft Word - utworzony raport medyczny musi zostać wydrukowany. Do tego celu należy stworzyć odpowiedni wzorzec, który po wypełnieniu będzie zawierać wszystkie informacje zawarte w dokumencie DICOM SR, w odpowiedniej formie. Definiowany wzorzec jest tworzony niezależnie od aplikacji, która jednak posiada pewne mechanizmy, które wspomagają ten proces. Może on zawierać dwa rodzaje danych: Rysunek 4.8: Panel do obsługi wzorców tworzonych przy pomocy aplikacji Microsoft Word

48 4.5. Reguły do tworzenia automatycznej diagnozy 49 dotyczące pacjenta i badania - należy je wybrać z listy w zakładce "Doc template editor" informacje zapisane w węzłach raportu - analogicznie jak w przypadku zakładki "GUI Editor", węzły które mogą być użyte są odpowiednio oznaczone Wstawienie wartości odbywa się techniką drag and drop. Po rozpoczęciu przeciągania okno panelu administratora jest automatycznie ukrywane, żeby ułatwić całą operację. W przypadku wstawiania danych pacjenta/badania w dokumencie zostanie wstawiony znacznik postaci <identyfikator>, natomiast przeciągając węzeł [etykieta <id_węzła>]. Jeśli chodzi o zastępowanie tagów pomiarów ich wartościami, to przyjęto następującą zasadę. Jeśli pomiar został wykonany, to wstawiana jest etykieta, pomiar, jednostka, znak tabulacji, w przeciwnym wypadku cały tag jest usuwany. Dodatkowo we wzorcu można na początku linii użyć która oznacza, że jeśli na etapie eksportu linia będzie pusta (np zawiera pomiary, z których żaden nie został wykonany), to linia jest usuwana. W przeciwnym wypadku usuwana jest z początku linii. Dzięki takiemu podejściu administrator może tworzyć nawet bardzo złożone wzorce, wykorzystując przy tym wygodne środowisko. Dodatkowym atutem użycia Microsoft Word jest możliwość wstawiania różnego rodzaju grafiki, oraz tabel, co pozwala podnieść walory estetyczne drukowanego raportu Reguły do tworzenia automatycznej diagnozy Jedną z podstawowych zalet standardu DICOM SR jest wprowadzana przez niego strukturalność do raportów medycznych. Dzięki temu możliwe jest automatyczne ich przetwarzanie, w tym również tworzenie diagnozy na podstawie ich zawartości. Ponieważ dokumenty posiadają ustaloną strukturę wiadomo jakie dane mogą zawierać i w którym miejscu są one zapisywane. Dzięki temu możliwe jest utworzenie szeregu reguł dotyczących wartości poszczególnych węzłów drzewa DICOM SR, które pozwolą na wnioskowanie diagnozy. W tworzonej aplikacji został wykorzystany silnik regułowy Drools [16]. Poszczególne reguły są generowane na podstawie definicji w edytorze węzła reprezentującego diagnozy. Generacja jest prowadzona w taki sposób, żeby zapewnić kompatybilność z nakładką Drools dla języka C# [17]. Poszczególne przesłanki są reprezentowane za pomocą klasy NodeValue, natomiast wnioski są zapisywane w klasie Result (obie klasy zostały zaimplementowane przez autora pracy). Sposób konwersji zostanie pokazany na przykładzie poniżej. Jeśli użytkownik zdefiniuje regułę postaci: [1_7_1_3_6_1 Left Ventricle Internal End Diastolic Dimension] > 0 && [1_7_1_3_6_1 Left Ventricle Internal Systolic Dimension] == 22 to zostanie ona zamieniona na definicję reguły: rule "<kolejny identyfikator reguły>" when NodeValues(Name=="1_7_1_3_6_1LeftVentricleInternalEndDiastolicDimension", Value>0) NodeValues(Name=="1_7_1_3_6_1LeftVentricleInternalSystolicDimension", Value==22) then

49 4.6. Plik wynikowy 50 end Drools.Result.add("<identyfikator diagnozy dla której zdefiniowano regułę>"); W obecnej wersji oprogramowania nie jest możliwe tworzenie bardziej złożonych reguł, które pozwalałyby na dodawanie nowych faktów. Przykładowo można wyobrazić sobie reguły, które operują nie tylko na wartościach pomiarów, ale biorą pod uwagę to co do tej pory zostało wywnioskowane. Niestety biblioteka Drools dla języka C# posiada wiele ograniczeń, dlatego wspomniane rozszerzone reguły nie są obsługiwane Plik wynikowy Z uwagi na to, że aplikacja korzysta z wielu plików pomocniczych konieczne stało się opakowanie ich w pliku archiwum (w ten sposób użytkownik zawsze operuje na pojedynczym pliku). Do tego celu został użyty format zip, ze zmienionym rozszerzeniem na med. Plik ten zawiera: chosenmeasurements.xml - plik pomocniczy generowany dla aplikacji TeleDICOM, na podstawie którego powinno zostać wygenerowane menu kontekstowe do wyboru narzędzia pomiarowego. Kolejne elementy xml odzwierciedlają poziomy menu: region - służy do rozróżnienia które menu powinno zostać wyświetlone, w zależności od tego na jakim regionie (obrazie) kliknie użytkownik (2D, dopler, mmode) group - grupuje pomiary dotyczące tego samego miejsca. Atrybut name odpowiada własności zawierającej zagregowaną nazwę mierzonych wielkości węzła pomiarowego. Jest to nazwa która powinna być wyświetlana użytkownikowi w menu. Dodatkowo atrybut nodeid, identyfikujący węzeł w drzewie DICOM SR, musi być przesyłany w zdarzeniu (event) informującym o nowym pomiarze cname - kolejne wielkości które mogą być zmierzone. Wartość value musi być również przesyłana w zdarzeniu. Dodatkowo w przyszłości pojawi się atrybut alias, który będzie zawierać nazwę którą będzie można wyświetlić użytkownikowi tool - identyfikator narzędzia pomiarowego (musi być przesyłany w zdarzeniu) gui.xml - zawiera dane potrzebne na odtworzenie GUI, zarówno w zakładce "GUI Editor w panelu administratora, jak również panelu z zawartością raportu w panelu lekarza rules.drl - plik z regułami opisanymi w poprzednim rozdziale. structure.xml - plik zawierający dane uszczegółowionego wzorca. Zawiera opis struktury, jak również ustawione własności węzłów template.doc - wzorzec wykorzystywany podczas eksportu zawartości raportu do formatu Microsoft Word dowolna liczba plików, wykorzystywanych jako tło w GUI

50 4.7. Panel lekarza Panel lekarza Panel lekarza służy do tworzenia raportów (wypełniania ich danymi). Z uwagi na to, że aplikacja musi komunikować się z zewnętrznym systemem (w którym docelowo ma być osadzona) dodatkowo powstał panel kontrolny, który pozwala na symulowanie działania zewnętrznego systemu. Głównymi funkcjonalnościami panelu lekarza są: wczytywanie wzorców utworzonych w panelu administratora import zawartości istniejących raportów DICOM SR wprowadzanie danych pacjenta i informacji dotyczących badania zarządzanie cyklem życia, weryfikacje, oraz podpis elektroniczny dokumentów dodawanie, usuwanie i modyfikacja zawartości węzłów raportu poprzez wysyłanie odpowiednich zdarzeń z zewnątrz, jak również z poziomu samej aplikacji automatyczna diagnoza, bazująca na regułach zdefiniowanych w panelu administratora ułatwienie tworzenia diagnozy, poprzez wyświetlanie zdefiniowanych wcześniej pełnych stwierdzeń, które mogą wchodzić w ich skład wyświetlanie zawartości dokumentu w przyjaznej dla użytkownika postaci - wykorzystanie standardu DICOM SR jest dla niego niezauważalne Wprowadzanie danych o pacjencie i informacji dotyczacej badania - aplikacja umożliwia podanie wspomnianych danych. Dodatkowo mogą być one pobrane z istniejącego dokumentu. Architektura aplikacji w pełni wspiera również import danych pacjenta z systemów HIS, natomiast taka funkcjonalność nie została zaimplementowana (istnieją natomiast niezbędne interfejsy). Zarzadzanie dokumentem - użytkownik ma do dyspozycji zakładkę, za pomocą której może zmieniać stan dokumentu: PARTIAL -> COMPLETE - w tym wypadku blokowana jest możliwość edycji dokumentu. Dodatkowo dokument musi być zapisany do fizycznego pliku, z uwagi na to, że zarówno operacja zmiany statusu, jak również późniejsze operacje dotyczące weryfikacji i podpisów elektronicznych, mogą być wykonane jedynie na pliku. COMPLETE -> PARTIAL - standard DICOM SR, oraz biblioteka DCMTK nie przewidują takiego przejścia. Mimo to, często zdarza się, że lekarz który ma zweryfikować raport znajdzie jakiś błąd (np. błędny fragment diagnozy). Bez możliwości ponownej edycji dokumentu trzeba by było tworzyć raport od początku, zamiast zmodyfikować jedną wartość. Podczas zmiany statusu z COMPLETE na PARTIAL tworzony jest automatycznie nowy dokument, który jest dokładną kopią pierwotnego raportu, z usuniętymi informacjami o weryfikacjach i podpisach elektronicznych

51 4.7. Panel lekarza 52 Rysunek 4.9: Zakładka pozwalająca na zarządzanie stanem raportu Ponadto lekarze mają możliwość dokonania weryfikacji i podpisu elektronicznego. Mogą również usuwać własne podpisy i weryfikacje. Wszystkie dane wykorzystywane podczas weryfikacji i podpisu są pobierane bezpośrednio z certyfikatu użytkownika. Dzięki temu podczas weryfikacji lekarz nie musi podawać swoich danych. Przegladanie i modyfikacja zawartości raportu - zawartość raportu jest wyświetlana w panelu, tworzonym dynamicznie zgodnie z definicją utworzoną w panelu administratora. Wyświetlane wartości pomiarów są w postaci zagregowanej i zaokrąglonej. Użytkownik ma możliwość podglądania szczegółów pomiarów za pomocą menu kontekstowego. W nowym oknie pojawia się tabela, która zawiera informacje o konkretnych pomiarach. U góry znajduje się tabela, której kolumny są generowane dynamicznie na podstawie definicji wzorca dokumentu. Zawsze pierwszą z nich jest Value, kolejne kolumny zawierają dane o węzłach, które są dziećmi węzła pomiarowego i zostały wybrane we wzorcu. Lekarz w każdym momencie może dodać ręcznie wartość pomiaru, lub ją usunąć. Podczas dodawania pomiaru dokonywana jest automatyczna konwersja jednostek. Ponadto względne różnice między poszczególnymi wartościami można obserwować na wykresie. Wartości pomiarowe mogą być dodawane, usuwane i modyfikowane również z zewnątrz, poprzez wysłanie odpowiedniego zdarzenia. W tym wypadku wartość wyświetlanych pomiarów aktualizuje się

52 4.7. Panel lekarza 53 (a) Okno z zakładką prezentującą zawartość raportu (b) Okno pokazujące szczegóły dotyczące wybranej mierzonej wielkości Rysunek 4.10: Panele do przeglądania i modyfikacji zawartości raportu

53 4.7. Panel lekarza 54 Rysunek 4.11: Okno do tworzenia diagnozy automatycznie. Dodatkowo w odpowiedzi przysyłany jest unikalny identyfikator, którym należy się posługiwać podczas usuwania i modyfikacji pomiaru. Tworzenie diagnozy - w celu przyspieszenia tworzenia diagnozy powstał pomysł na dostarczenie gotowych stwierdzeń (zdań), z których lekarz mógłby skomponować diagnozę. Lista dostępnych stwierdzeń jest definiowana w panelu administratora. Wybór jednego z nich odbywa się poprzez zaznaczenie odpowiedniej frazy, która następnie jest wstawiana do listy zawierającej diagnozę. Usuwanie poszczególnych jej elementów może nastąpić poprzez odznaczenie wcześniej zaznaczonego zdania, bądź przez usunięcie go z listy. Podczas wstawiania zwrotów z listy sprawdzane są ich wzajemne wykluczenia, przy czym zakłada się, że użytkownik zdaje sobie sprawę z ich występowania, dlatego nie jest proszony o potwierdzenie usuwania kolidujących stwierdzeń z aktualnie wybranym. Czasem zdarza się, że lekarz chce zamieścić własne stwierdzenie, którego może nie być w zbiorze wcześniej zdefiniowanych. W takiej sytuacji może dodać własny tekst, który jest traktowany jako niestandardowe stwierdzenie. Stwierdzenia standardowe i niestandardowe może dowolnie mieszać. Panel kontrolny - ponieważ panel lekarza został stworzony do współpracy z zewnętrzną aplikacją powstała konieczność zaimplementowania panelu, który będzie symulować jej zachowanie. Control Panel pozwala na: wczytanie wzorca stworzonego za pomocą panelu administratora

54 4.7. Panel lekarza 55 (a) Panel kontrolny (b) Okno do tworzenia nowych pomiarów Rysunek 4.12: Elementy panelu kontrolnego import zawartości istniejącego raportu DICOM SR zapis raportu do w formacie DICOM SR uruchomienie procedury automatycznego doboru diagnozy eksport zawartości dokumentu do formatu aplikacji Microsoft Word przy użyciu wcześniej zdefiniowanego wzorca wysłanie zdarzenia dotyczącego dodania, usunięcia, lub modyfikacji pomiaru oglądanie przesyłanych przez panel lekarza zdarzeń Elementy pozwalajace na integrację z zewnętrznymi systemami - jednym z założeń projektowych aplikacji była łatwość w integracji z zewnętrznymi systemami, dlatego też została podjęta decyzja o użyciu mechanizmu zdarzeń w komunikacji z nimi. Dzięki takiemu podejściu implementowane funkcjonalności mogą być niezależne od korzystających z nich komponentów. Integracja bazuje na spełnieniu odpowiedniego kontraktu. Aplikacja zewnętrzna musi produkować pewne ściśle określone zdarzenia informujące np. o wykonaniu pomiaru, oraz musi przechwytywać zdarzenia płynące do niej w celu poprawnego działania. Panel lekarza został stworzony jako panel aplikacji WPF, dlatego też użycie go wiąże się jedynie z osadzeniem w jakimś komponencie aplikacji zewnętrznej. Ponadto panel udostępnia na zewnątrz interfejs pozwalający na bezpośrednią manipulację zawartością raportu (operacje, takie jak wstawienie danych pacjenta, wczytanie dokumentu DICOM SR, itp.). W celu ułatwienia integracji został stworzony panel kontrolny (opisany wcześniej). Twórcy zewnętrznych aplikacji mogą użyć zaimplementowanych tam metod jako referencji w swoich projektach. W większości przypadków można skopiować poszczególne metody. Oprócz tego zakłada się, że aplikacja zewnętrzna będzie korzystać z pliku chosenmeasurements.xml opisanego w rozdziale 4.6 w celu wczytania odpowiednich identyfikatorów używanych podczas przesyłania zdarzeń związanych z pomiarami.

55 4.8. Podsumowanie Podsumowanie Jednym z wyników niniejszej pracy było powstanie w pełni funkcjonalnej aplikacji, która spełniła wszystkie założenia postawione w rozdziale 3. Na początku został stworzony prototyp, który pozwolił na doprecyzowanie wymagań, jak również sprawdzenie wybranych technologii. Następnie powstały dwie aplikacje: panel administratora - służący do tworzenia uszczegółowionego wzorca raportu medycznego panel lekarza - służący do tworzenia konkretnego raportu (wypełnienia wzorca danymi) Jako element łączący obie aplikacje został użyty plik archiwum zip, który zawiera wszystkie pliki pomocnicze, wykorzystywane przez oba panele. Dodatkowo z uwagi na to, że nie ma sformalizowanego opisu metadanych opisujących strukturę raportów DICOM SR, autor pracy utworzył zbiór łatwych do przetwarzania wzorców (w formacie xml), bazując na definicjach zawartych w 16 części standardu DICOM Content Mapping Resource [9].

56 5. Weryfikacja W niniejszym rozdziale, w celu przetestowania użyteczności zaimplementowanych aplikacji, zostaną sprawdzone najczęstsze przypadki jego użycia. Aplikacje zostaną ocenione głównie pod kątem spełnienia wymagań opisanych w rozdziale Opracowanie prostego wzorca raportu echokardigraficznego Przypadek użycia, opisujący poszczególne kroki wykonywane przez administratora w celu utworzenia prostego wzorca dokumentu. Użytkownik na początku wybiera odpowiedni wzorzec szczegółowy i zaznacza podzbiór jego węzłów. Kolejne kroki dotyczą ustawienia odpowiednich własności wybranych węzłów. Administrator projektuje interfejs użytkownika, który ma być potem prezentowany lekarzom. Wybór wzorca i ustawienie jego podstawowej struktury Jako wzorzec ogólny został wybrany raport echokardiograficzny opisany w suplemencie standardu DICOM [9] jako TID Poszczególne węzły zostały wyświetlone w postaci drzewa, co widać na rysunku 4.4. Wzorzec ogólny zawiera bardzo dużą ilość węzłów. W związku z tym skorzystano z opcji importu struktury dokumentu z istniejącego raportu. Jako raport referencyjny został wykorzystany przykładowy raport dostarczony przez Krakowski Szpital Specjalistyczny im. Jana Pawła II. W wyniku importu zostały zaznaczone wszystkie poddrzewa oznaczone jako TID 5202, które zawierają informacje o pomiarach echokardiograficznych. Przygotowywany wzorzec ma zawierać jedynie dane dotyczące lewej komory serca, dlatego pozostałe węzły zostały odznaczone (wystarczyło odznaczyć jedynie węzły na szczycie poddrzew). Po sprawdzeniu struktury zaznaczonych węzłów z zawartością importowanego raportu stwierdzono, że się one pokrywają (na rysunku 5.1a widać zaznaczone węzły Finding Site oraz Acquisition Protocol, których nie widać na rysunku 5.1b - węzeły pojawiają się w importowanym dokumencie, ale nie zmieścił się on w całości na rysunku). Dodatkowo poprawnie zostały ustawione jednostki dla wielkości, które znajdowały się w przykładowym raporcie. Z uwagi na to, że możliwych wartości jest bardzo dużo, nawet dla samej lewej komory serca, w celach testowych wybrano jedynie pięć z nich (gdyż wstawianie innych wartości niczym się nie różni). Dla wybranych pomiarów ustawione zostały różne własności, takie jak: alias nazwy zaokrąglenie - sprawdzono, czy pole podpowiedzi działa poprawnie 57

57 5.1. Opracowanie prostego wzorca raportu echokardigraficznego 58 narzędzia pomiarowe (a) Fragment drzewa DICOM SR po imporcie struktury (b) Fragment pliku z którego importowano strukturę Rysunek 5.1: Import struktury drzewa DICOM SR z istniejącego dokumentu Projekt interfejsu użytkownika Kolejnym krokiem jest utworzenie interfejsu użytkownika, który będzie prezentowany lekarzowi w kolejnej aplikacji. Stworzony interfejs zawierał pojedynczy GroupBox, któremu zmieniona została etykieta oraz rozmiar. Do jego wnętrza dodane zostały wybrane w poprzednim kroku węzły pomiarowe. Poszczególne panele były modyfikowane niezależnie. Ustawiane były różne czcionki, długości pól, widoczność jednostek. Dodatkowo sprawdzono, czy do interfejsu da się wstawić jedynie wybrane węzły, oraz czy odznaczenie węzła w drzewie powoduje usunięcie powiązanych z nim paneli. Wczytanie utworzonego wzorca oraz import zawartości istniejacego dokumentu Po utworzeniu wzorca został on wczytany przez panel lekarza. Jak widać na rysunku 5.2 interfejsy wyglądają prawie identycznie, mimo użycia dwóch różnych technologii (panel administratora został zaimplementowany przy użyciu Windows Forms, natomiast panel lekarza przy użyciu Windows Presentation Fundation). Sprawdzona również została poprawność wczytanych danych. Należy podkreślić, że dane zostały pobrane z innego dokumentu niż ten który był użyty w panelu administratora do automatycznego wybrania odpowiednich węzłów drzewa DICOM SR. Prezentowane na rysunku 5.2b wartości, są średnimi z wartości pobranych z istniejącego dokumentu. Po ręcznym sprawdzeniu otrzymanych wyników stwierdzone zostało poprawne działanie aplikacji.

58 5.1. Opracowanie prostego wzorca raportu echokardigraficznego 59 (a) Widok z poziomu edytora GUI panelu administratora (b) Fragment panelu zawartości panelu lekarza (po imporcie danych) Rysunek 5.2: Porównanie widoku interfejsu lekarza w panelu administratora i lekarza Zapisanie utworzonego dokumentu w formacie DICOM SR W zaimportowanym dokumencie dodano wartość Heart rate na dwa sposoby: ręcznie - za pomocą okienka przedstawiającego szczegóły pomiaru poprzez zewnętrzną aplikację - w tym celu został użyty panel kontrolny. Dzięki wykorzystaniu informacji zawartych w pliku chosenmeasurements.xml, większość wartości można było wybrać przy pomocy pól typu ComboBox. Wysłanie informacji o wykonaniu nowego pomiaru spowodowało aktualizację pola w interfejsie lekarza. Na liście pomiarów w oknie pokazującym szczegóły pomiaru pojawił się nowy wpis. Po wykonaniu wspomnianych modyfikacji dokonano zapisu dokumentu do pliku DICOM SR i sprawdzono, że dodane pomiary się w nim pojawiły przez wykorzystanie przeglądarki SR Browser [4]. Ponadto sprawdzono, że pozostałe wartości nie uległy zmianie.

59 5.2. Utworzenie nowego raportu echokardigraficznego z diagnozą Utworzenie nowego raportu echokardigraficznego z diagnoza W tym przypadku administrator oprócz czynności opisanych w poprzednim rozdziale, musi zdefiniować zbiór wyrażeń, które posłużą do postawienia diagnozy, jak również odpowiednich reguł, dzięki którym możliwe będzie automatyczny dobór zdefiniowanych wyrażeń. Następnie lekarz może w szybki sposób utworzyć diagnozę poprzez wybór zdań z listy, oraz poprzez zastosowanie automatycznego wnioskowania. Definicja elementów diagnozy Elementy diagnozy mogą być definiowane dowolnie. Na potrzeby testu użyto zestawu zwrotów utworzonych w Krakowskim Szpitalu Specjalistycznym im. Jana Pawła II. Część z nich widać na rysunku 4.6a. Powstała hierarchia wyrażeń jest bardzo istotna, gdyż decyduje o tym, jak szybko lekarz będzie mógł znaleźć interesujące go wyrażenie. Ogólnie zasada przyjęta podczas projektowaniu wyrażeń była taka, żeby agregować szczegółowe wyrażenia (które są wstawiane do raportu) w bardziej ogólne (które pozwalały szybko odszukać interesujący zbiór wyrażeń). Oprócz tego dodano również wykluczenia dla odpowiednich wyrażeń np. LK nieznacznie powiększona i LK umiarkowanie powiększona, ponieważ widać, że te dwie wartości nie mogą wystąpić jednocześnie. Tworzenie reguł wyboru diagnozy Z uwagi na to, że do poprawnego zdefiniowania reguł potrzebna jest wiedza eksperta, została podjęta decyzja o stworzeniu kilku reguł, które nie mają znaczenia medycznego (nie mają żadnego uzasadnienia w medycynie). Mają one służyć jedynie sprawdzeniu działania samego mechanizmu automatycznego dobierania diagnozy. W związku z tym zostało zdefiniowanych kilka prostych reguł, składających się co najwyżej z trzech członów. Podczas tworzenia zbioru reguł sprawdzono działanie mechanizmu edycji, dodawania, usuwania, oraz poprawności wyświetlania podglądu reguł. Dodatkowo sprawdzono, czy w edytorze dostępne są jedynie wartości, które zostały dodane do interfejsu użytkownika. Stworzenie reguł zakończono na dodaniu odpowiedniego panelu do interfejsu użytkownika utworzonego w poprzednim rozdziale. Tworzenie diagnozy Wzbogacony wzorzec został ponownie wczytany przez panel lekarza. Pierwszym krokiem było zbadanie działania mechanizmu automatycznego doboru diagnozy. Dlatego też do tego celu wybrana została bardzo prosta reguła, której definicja wyglądała następująco: [1_7_1_3_6_1 Heart Rate] > 0 Jak widać żeby zadziałała wystarczyło nadać jakąś nieujemną wartość dla Heart Rate. W tym przypadku było to 5 mm. Następnie został uruchomiony mechanizm doboru diagnozy. Po chwili panel z zawartością dokumentu został odświeżony i pojawiło się wyrażenie, do którego przypisana była wspomniana wyżej reguła. Na podobnej zasadzie sprawdzone zostało również działanie tego mechanizmu dla kilku reguł.

60 5.3. Dodanie wzorca do eksportu zawartości raportu do dokumentu Microsoft Word 61 Kolejnym krokiem w tworzeniu diagnozy był ręczny wybór oraz usuwanie odpowiednich wyrażeń. Przy okazji zostało sprawdzone działanie mechanizmu wykluczeń między poszczególnymi zdaniami. Oprócz tego dodano kilka zwrotów niestandardowych. Na koniec dokument został zapisany oraz wczytany ponownie. W odpowiednim panelu była poprawnie odtworzona treść diagnozy (zawierająca standardowe i niestandardowe wyrażenia) Dodanie wzorca do eksportu zawartości raportu do dokumentu Microsoft Word Bardzo istotnym przypadkiem użycia z punktu widzenia lekarzy jest eksport zawartości raportu medycznego do formatu Microsoft Word, skąd może ona zostać wydrukowana i przekazana np. pacjentowi. W celu jego realizacji administrator musi najpierw utworzyć wzorzec takiego dokumentu posługując się metadanymi, które potem będą zastępowane konkretnymi wartościami. Tworzenie wzorca dokumentu Microsoft Word Rysunek 5.3: Wzorzec dokumentu Microsoft Word

61 5.3. Dodanie wzorca do eksportu zawartości raportu do dokumentu Microsoft Word 62 Z pomocą panelu administratora został stworzony szablon pokazany na rysunku 5.3. Zawiera on informacje dotyczące lewej komory. Jak widać wzorzec może zawierać obrazki, jak np. logo danej jednostki. Jego definicja jest zgodna z opisem zamieszczonym w rozdziale 4.4. Eksport zawartości raportu do pliku Microsoft Word W celu sprawdzenia działania eksportu najpierw został wczytany wzorzec raportu wzbogacony o wzorzec dokumentu Microsoft Word przedstawiony w wyżej. Następnie dokonany został import danych z istniejącego dokumentu, po czym dodano kilka stwierdzeń w celu stworzenia diagnozy. Na koniec dokonano eksportu jego zawartości do dokumentu Microsoft Word. Wynik widać na rysunku 5.4. Rysunek 5.4: Dokument Microsoft Word po eksporcie Powstały dokument zawiera wszystkie informacje, które występowały w raporcie i które zostały uwzględnione we wzorcu dokumentu Word. Można zauważyć, że wartości które nie wystąpiły zostały pominięte, co zapewniło ładny wygląd dokumentu. Nie ma niepotrzebnych elementów w postaci pustych etykiet (bez wartości liczbowych).