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

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 DICOMSR NA POTRZEBY APLIKACJI KONSULTACYJNYCH PROMOTOR: dr inż. Łukasz Cziekierda Kraków 2012

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

Serdecznie dziękuję... tu ciąg dalszych podziękowań np. dla promotora, żony, sąsiada itp.

Spis treści 1. Wstęp... 7 2. Raporty w medycynie... 9 2.1. Obecnie używane raporty w medycynie... 9 2.2. Charakterystyka DicomSR... 9 2.2.1. Budowa dokumentu... 10 2.2.2. Typy węzłów drzewa DicomSR... 13 2.2.3. Typy relacji w drzewie DicomSR... 16 2.2.4. Zarządzanie raportami DicomSR... 17 2.3. Podsumowanie... 18 3. Analiza wymagań... 19 3.1. Przebieg konsultacji... 19 3.1.1. Rodzaje telekonsultacji... 20 3.1.2. Tworzenie telekonsultacji medycznej... 22 3.1.3. Tworzenie raportu medycznego DicomSR... 23 3.2. Wymagania funkcjonalne i niefunkcjonalne... 25 3.2.1. Wymagania niefunkcjonalne... 26 3.2.2. Aktorzy... 27 3.2.3. Wymagania funkcjonalne... 27 3.2.4. Struktura przetwarzania... 31 3.3. Wzorce dokumentów... 32 3.4. Podsumowanie... 34 4. Wybrane aspekty realizacji... 35 4.1. Użyte technologie i biblioteki... 35 4.2. Prototyp... 36 4.3. Przetwarzanie wzorców DicomSR... 38 4.4. Panel Administracyjny... 39 4.5. Plik wynikowy (*.med)... 46 4.6. Panel Lekarza... 47 5

SPIS TREŚCI 6 4.7. Podsumowanie... 52 5. Weryfikacja... 53 6. Podsumowanie... 54 Załaczniki... 59 A. Format xml wzorców Dicom SR... 60

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 na papierze, 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, z czym wiąże się wiele problemów. 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 problemy (i wiele innych) zostały zauważone przez grupę specjalistów, którzy stworzyli standard DICOM SR. 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 pewnych określonych procedur związanych z tworzeniem raportów, 7

8 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 pewnej 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, w jaki sposób można wykorzystać standard DICOM 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.

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. Opis dotyczy zarówno tradycyjnych, papierowych dokumentów, jak również wybranych systemów informatycznych, które w tym celu zostały stworzone. Kolejny rozdział zawiera opis standardu DicomSR, 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. Dodatkowo rozdział kończy się krótkim opisem struktury raportu echokardiograficznego, który służy jako referencja w kolejnych rozdziałach pracy. 2.1. Obecnie używane raporty w medycynie Rozdział jest poświęcony różnym raportom służącym do przechowywania opisów i diagnoz schorzeń. Dodatkowo kilka słów o systemach informatycznych, jakie są najczęściej wykorzystywane (żeby zaznaczyć środowisko w którym potencjalnie miałaby działać moja aplikacja) 2.2. Charakterystyka DicomSR Standard DicomSR (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 DicomSR, 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 relacje pomiędzy pojęciami wbudowane referencje do obrazów medycznych, jak również ich składowych (przykładowo obrysów) 9

2.2. Charakterystyka DicomSR 10 DicomSR 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). 2.2.1. Budowa dokumentu Rysunek 2.1: Przykładowy raport echokardiograficzny - dane dotyczące pacjenta i badania (fragment prezentowany przez przeglądarkę SR Browser [4]) Każdy dokument DicomSR 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.1) imię i nazwisko data urodzenia identyfikator pacjenta płeć oraz dane dotyczące badania: data badania identyfikator badania

2.2. Charakterystyka DicomSR 11 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.2 i 2.3) Rysunek 2.2: Fragment drzewa raportu echokardiograficznego Głównym elementem dokumentu DicomSR 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 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.

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

2.2. Charakterystyka DicomSR 13 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 ( 125200, 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.3 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 DicomSR. Warto również zwrócić uwagę, że schemat drzewa przedstawiony na rysunku 2.2 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. 2.2.2. Typy węzłów drzewa DicomSR 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

2.2. Charakterystyka DicomSR 14 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 nosząca nazwę Concept Code Sequence. Jest ona analogiczna jak w przypadku Concept Name (poszczególne elementy mają identyczne znaczenie), czyli wartośc 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) - zawiera text zawierający DICOM UID. Służy do wskazywania na pojedynczy element raportu. Przykładowo może to być numer instancji raportu medycznego. 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

2.2. Charakterystyka DicomSR 15 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ł wykonany dany pomiar. WAVEFORM - kolejny typ, który jest rozszerzeniem COMPOSITE. Pozwala na przechowywanie pojedynczej referencji do strumieniowego obiektu DICOM. Dodatkowym elementem jest Referenced veform 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 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. 2.4. 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

2.2. Charakterystyka DicomSR 16 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 2.2.3. Typy relacji w drzewie DicomSR 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 DicomSR. 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. Rysunek 2.4: Współrzędne wskazujące na przestrzeń między-pikselową [3]

2.2. Charakterystyka DicomSR 17 Rysunek 2.5: Wizualizacja przedziałów czasowych Temporal Range [3] 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 2.2.4. Zarzadzanie raportami DicomSR Oprócz tworzenia i kodowania treści, standard DicomSR dostarcza kilu reguł dotyczących zarządzania, w celu zapewnienia kontroli nad przechowywaniem, oraz dostępnością dokumentów. Wspomniane 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 DicomSR 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:

2.3. Podsumowanie 18 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 - w praktyce możemy mieć technika, lub młodego lekarza, który dopiero uczy się wykonywania pomiarów i wyciągania z nich wniosków. Raport DicomSR może zostać stworzony przez taką osobę i 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). 2.3. Podsumowanie

3. Analiza wymagań Celem niniejszej pracy jest przeanalizowanie możliwości tworzenia strukturalnych raportów medycznych zgodnych ze standardem Dicom SR na potrzeby aplikacji konsultacyjnych. 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 wykorzystują 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 aplikacja stworzona na Katedrze Informatyki AGH, która składa się z podsystemu dystrybucji danych oraz podsystemu komunikacji interaktywnej. Podsystem dystrybucji danych dostarcza pliki z badaniami pacjenta do wszystkich ośrodków biorących udział w sesji interaktywnej. Podsystem komunikacji interaktywnej pozwala na wykonywanie pomiarów za pomocą specjalistycznych narzędzi pomiarowych na potrzeby echokardiografii, jak również komunikację głosową i tekstową. 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). 3.1. 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). Obecnie w większości szpitali konsultacje są prowadzone głównie telefonicznie. Niestety często nie da się jednoznacznie opisać danego przypadku. Wykorzystanie cyfrowego zapisu obrazów medycznych pozwala w znaczącym stopniu uzupełnić informacje o konsultowanym przypadku, jak również 19

3.1. Przebieg konsultacji 20 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. Telekonsultacje ułatwiają wymianę doświadczeń, oraz lepsze wykorzystanie wiedzy ekspertów. W konsekwencji przyczynia się to do poprawy jakości opieki medycznej, oraz do obniżenia jej kosztów. Dodatkowo młodzi lekarze mogą uczyć się (pytać o radę) od swoich bardziej doświadczonych odpowiedników, co również ma pozytywny wpływ na ich edukację. Oprócz tego takie podejście ma jeszcze jedną zaletę. Często zdarzają się sytuacje, w których lekarz konsultant nie jest w danej chwili dostępny. Przy komunikacji telefonicznej trzeba dzwonić kilkukrotnie, przy czym nie ma pewności, że konsultant nie jest nadal zajęty. Telekonsultacja może być prowadzona etapami. Lekarz zlecający ma możliwość przesłania wszystkich danych o pacjencie, wraz ze swoimi wątpliwościami. Konsultant w wolnej chwili odbiera zlecenie konsultacji i odsyła swoje wnioski. Oczywiście tego typu podejście może być stosowane jedynie w przypadkach, które nie wymagają nagłej interwencji lekarzy (mimo to tego jest ich stosunkowo dużo). 3.1.1. Rodzaje telekonsultacji Ze względu na sposób współpracy lekarza zlecającego z ekspertem można wyróżnić dwa sposoby prowadzenia telekonsultacji. Telekonsultacje asynchroniczne - są to konsultacje, gdzie nie jest wymagana wymiana informacji między lekarzami ńa ż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 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 asynchronicznej 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. Rysunek 3.1: Schemat telekonsultacji asynchronicznej Telekonsultacje synchroniczne - cechą charakterystyczną tego modelu, jest wspólna sesja telekonsultacyjna. Z uwagi na to, że w konsultacji jednocześnie może brać udział wiele osób, istnieje

3.1. Przebieg konsultacji 21 konieczność zapewnienia interakcji między współpracującymi stronami. Dzięki temu ten model przypomina tradycyjne konsultacje ("burze mózgów"). Podstawowe narzędziami dostępnymi w takich systemach: 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 synchronicznej 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

3.1. Przebieg konsultacji 22 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. Nie tylko sama konsultacja przebiega w bardziej naturalny sposób, ale również pozwala na zajmowanie się najbardziej skomplikowanymi przypadkami, wykorzystując do utworzenia diagnozy wiedzę wielu doświadczonych ekspertów. Idea działania serwera synchronizacyjnego jest stosunkowo prosta. Jego zadaniem jest dbanie o to, żeby każdy uczestnik konsultacji widział taki sam jej stan (przykładowo wstawiony obrys musi być widoczny u wszystkich uczestników). Możliwe są co najmniej dwa schematy synchronizacji: oparty o rezerwację - w tym podejściu należy wyszczególnić jednostkowe elementy występujące w konsultacji, które mogą być modyfikowane przez poszczególnych uczestników (np. pola do wprowadzania danych, lub wirtualną tablicę). Przed rozpoczęciem jakichkolwiek zmian należy najpierw dokonać rezerwacji zasobu w serwerze synchronizacji, co zapewnia, że w danej chwili nikt inny nie może jednocześnie go modyfikować. Jest to bardzo proste podejście, a jednocześnie bardzo dobrze wpasowuje się w wymagania konsultacji medycznych, gdzie zazwyczaj nie ma sytuacji, gdzie istniałaby konieczność jednoczesnej modyfikacji zasobów. oparty o znaczniki czasowe - każda akcja wykonywana jest w określonym czasie. Model zakłada występowanie kolizji spowodowanych jednoczesną modyfikacją zasobu (np. dwóch uczestników konsultacji modyfikuje jednocześnie to samo pole tekstowe). W tym podejściu każda modyfikacja wiąże się z wysłaniem do serwera synchronizacji informacji o modyfikacji, wraz ze znacznikiem czasowym w którym została ona wykonana. Zadaniem serwera jest grupowanie poszczególnych akcji bazując na znacznikach czasowych i sekwencyjne ich wykonywanie, z jednoczesnym informowaniem wszystkich uczestników konsultacji o bieżącym stanie. Niestety takie podejście jest dużo wolniejsze w działaniu od poprzedniego (użytkownik zauważa narzuty synchronizacyjne) i dodatkowo wymagana jest synchronizacja zegarów wszystkich uczestników konsultacji, co jest dodatkowym problemem do rozwiązania. 3.1.2. 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 synchronicznych: dobór i przygotowanie danych - na początku należy zebrać dane, związane z tematem konsultacji. W większości przypadków rozważane są złożone problemy, dlatego niezbędne jest posługiwanie się informacjami, które dobrze je opisują. Oczywiście dane muszą być odpowiednio przygotowane. 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. Może wyróżnić dwie metody:

3.1. Przebieg konsultacji 23 1. bez wspomagania - należy samemu dobrać innych uczestników, bazując na własnej wiedzy, lub jakiś zewnętrznych źródłach 2. ze wspomaganiem - w tym przypadku można mieć dostępne specjalne oprogramowanie, które wspomaga dobór uczestników. Mogą być to profile z opisem poszczególnych osób (np. w jakich dziedzinach się specjalizują, ilość odbytych konsultacji, itp.), z dołączoną wyszukiwarką. Dzięki temu można szybko znaleźć osoby, z którymi można się skonsultować. Takie podejście ma również jeszcze jedną zaletę. Po każdej konsultacji można wprowadzić mechanizm oceny uczestników. Bazując na ocenach można wybierać specjalistów, którzy okazali się pomocni w przeszłości. 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. Czasem zdarza się, że konsultacja musi być przeprowadzona jak najszybciej, natomiast najczęściej może poczekać kilka dni. 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 nim może być wybór części wspólnej spośród preferencji terminów wysyłanych w odpowiedzi na zaproszenie do konsultacji. przygotowanie środowiska - ponieważ dane wykorzystywane w konsultacji mogą być bardzo obszerne (nawet w setkach MB) należy zadbać o wcześniejsze przygotowanie środowiska, poprzez np. przesłanie plików przed jej rozpoczęciem 3.1.3. Tworzenie raportu medycznego DicomSR 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 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

3.1. Przebieg konsultacji 24 Rysunek 3.3: Uproszczony schemat tworzenia raportu DicomSR

3.2. Wymagania funkcjonalne i niefunkcjonalne 25 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 DicomSR, 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 wedle uznania. 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. 3.2. Wymagania funkcjonalne i niefunkcjonalne Zarówno wymagania funkcjonalne, jak i niefunkcjonalne zostały zebrane po przeprowadzeniu wielu konsultacji z dr hab. Andrzejem Gackowskim, pracownikiem Szpitala im. Jana Pawła II w Krakowie. Dzięki jego licznym uwagom i spostrzeżeniom powstała lista niezbędnych funkcjonalności tworzonej aplikacji, jak również szeregu ograniczeń, które są związane z zastosowaniami w środowisku medycznym.

3.2. Wymagania funkcjonalne i niefunkcjonalne 26 3.2.1. Wymagania niefunkcjonalne Podstawowym wymaganiem niefunkcjonalnym było użycie podczas implementacji standardu DicomSR, z uwagi na jego cechy, jak również istnienie wielu aplikacji przystosowanych do przechowywania plików DICOM (a więc również DicomSR). 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 (lub będą w przyszłości) korzystają z raportów DicomSR. Dodatkowo lekarze chcieli mieć możliwość wpływu na strukturę raportu. Chodziło o możliwość uszczegóławiania standardowych wzorców. W szpitalu Jana Pawła II w Krakowie działa system typu HIS (Hospital Information System), który przechowuje dane pacjentów. Tworzona aplikacja powinna w prosty sposób umożliwić integrację z tego typu systemami, w celu przyspieszenia tworzenia raportu (automatyczne pobranie danych pacjenta). 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 DicomSR, 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ć stosunkowo prosta w obsłudze i posiadać przyjazny dla użytkownika interfejs 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ę środowisko w jakim ma działać aplikacja 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ęzyk programowania C#. Dodatkowo interfejs użytkown-

3.2. Wymagania funkcjonalne i niefunkcjonalne 27 ika powinien zostać napisany z wykorzystaniem Windows Presentation Foundation (WPF). Docelowym systemem operacyjnym jest Microsoft Windows XP. 3.2.2. Aktorzy Dokument DicomSR 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 DicomSR, używany później przez innych lekarzy. Administrator musi, oprócz wiedzy medycznej, znać podstawy standardu DicomSR, 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 DicomSR. Jak łatwo zauważyć, między niektórymi wymaganiami, podanymi w poprzednim rozdziale, powstała pewna sprzeczność (np. między przeźroczystością, a wpływem na wzorzec dokumentu). Z tego powodu została podjęta decyzja o stworzeniu dwóch współpracujących ze sobą aplikacji, które będą wykorzystywane przez wymienionych wyżej aktorów: 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. 3.2.3. Wymagania funkcjonalne Wymagania funkcjonalne zostały podzielone na oba panele: administracyjny oraz lekarza 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ż

3.2. Wymagania funkcjonalne i niefunkcjonalne 28 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 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ć).

3.2. Wymagania funkcjonalne i niefunkcjonalne 29 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 DicomSR, 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 TeleDICOM, pojawiło się wymaganie dotyczące zapisu informacji o wybranych pomiarach w języku xml. Dane zawarte w tym pliku mają być potem wykorzystywane w komunikacji pomiędzy aplikacjami TeleDICOM, a panelem lekarza. Generowany plik powinien zawierać niezbędne dane, potrzebne do komunikacji. Przykładowo mogą to być identyfikatory węzłów drzewa dokumentu, lub nazwy możliwych do wykonania pomiarów. Oczywistą rzeczą jest, że użytkownik powinien również móc zapisywać i odczytywać wyniki swojej pracy. 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: przeglądać poszczególne pomiary usuwać pomiary

3.2. Wymagania funkcjonalne i niefunkcjonalne 30 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ę 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,

3.2. Wymagania funkcjonalne i niefunkcjonalne 31 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 DicomSR. 3.2.4. 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. 3.4. Rysunek 3.4: Uproszczony schemat przetwarzania 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 admin-

3.3. Wzorce dokumentów 32 istracyjny. 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 DicomSR, 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 DicomSR 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 DicomSR 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 DicomSR 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 DicomSR, w celu uniknięcia problemów, o których była mowa wcześniej. 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

3.3. Wzorce dokumentów 33 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: http://www.dabsoft.ch/dicom/16/. Niestety w internecie brak jest jakichkolwiek gotowych do przetwarzania plików ze wspomnianymi definicjami (np. w formacie xml). Wzorce na stronie dabsoft zostały zamieszczone jako tabele HTML. Przykładowy wzorzec jest przedstawiony na rys. 3.5. Kolejne kolumny oznaczają: identyfikator węzła we wzorcu - używany głównie w warunkach wystąpień węzłów

3.4. Podsumowanie 34 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 3.4. Podsumowanie

4. Wybrane aspekty realizacji 4.1. Użyte technologie i biblioteki Rysunek 4.1: Stos technologiczny prezentujący 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 DicomSR. Jest ona bardzo rozbudowana i obsługa standardu DicomSR jest jedynie jej niewielką częścią, dlatego implementowana aplikacja korzysta jedynie z kilku pakietów: dcmsr - zestaw klas reprezentujących raport DicomSR, 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ż DicomSR). Podczas implementacji została użyta do zapisywania, odczytywania, oraz przetwarzania struktury raportów. dcmsign - zapewnia obsługę podpisu elektronicznego 35

4.2. Prototyp 36 config, ofstd - biblioteki współdzielone przez wszystkie pakiety DCMTK. Zawierają między innymi definicje własnych typów. 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 3.6.0 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]. DicomSR Library C# - niestety po stworzeniu aplikacji demonstracyjnej, która w całości wykorzystywała wygenerowany 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 DicomSR. Zaimplementowana biblioteka dostarcza wszystkich niezbędnych metod, do tworzenia, oraz wyszukiwania w raportach DicomSR. 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 DicomSR. Spowodowało to znaczny wzrost szybkości aplikacji. 4.2. Prototyp W celu sprawdzenia wybranych bibliotek, oraz ułatwienia zbierania wymagań powstał prototyp aplikacji. Stanowi on realizację modelu konsultacji synchronicznej opisanej w rozdziale 3.1.1. 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 DicomSR) 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

4.2. Prototyp 37 Rysunek 4.2: Okno konsultacji 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 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 DicomSR, 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 DicomSR.

4.3. Przetwarzanie wzorców DicomSR 38 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 DicomSR 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. Przetwarzanie wzorców DicomSR 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 Aplikacja, która realizuje wspomniane funkcjonalności została napisana w języku Python. Pobieranie wzorców z internetu: 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 http://www.dabsoft.ch/dicom/16/ znajduje się pełna lista odnośników do poszczególnych elementów standardu DicomSR. 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:

4.4. Panel Administracyjny 39 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. 4.4. 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 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.

4.4. Panel Administracyjny 40 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 dicomsr, 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) 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) 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 DicomSR - wtedy wszystkie węzły występujące w dokumencie zostaną zaznaczone. Procedura importu pobiera jedynie strukturę dokumentu, 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ą.

4.4. Panel Administracyjny 41 Rysunek 4.4: Główne okno aplikacji AdminPanel Rysunek 4.5: Menu aplikacji AdminPanel 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

4.4. Panel Administracyjny 42 reprezentującego pomiary dla lewej komory wartość może być łewa 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 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. 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

4.4. Panel Administracyjny 43 (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 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ł. 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 koniunkcją logiczną, 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

4.4. Panel Administracyjny 44 Rysunek 4.7: Edytor do tworzenia graficznego interfejsu użytkownika aplikacji AdminPanel 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 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ńazwę 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 DicomSR, w odpowiedniej formie. Defin-

4.4. Panel Administracyjny 45 Rysunek 4.8: Panel do obsługi wzorców tworzonych przy pomocy aplikacji Microsoft Word iowany 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: 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 AdminPanelu 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ć sekwencji @#$, 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 sekwencja @#$ 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.

4.5. Plik wynikowy (*.med) 46 4.5. Plik wynikowy (*.med) 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: choosenmeasurements.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 DicomSR, 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 panu administratora, jak również panelu z zawartością raportu w panelu lekarza rules.drl - plik z regułami Drools [16]. Jest generowany na podstawie reguł zdefiniowanych w edytorze węzła reprezentującego diagnozy, w taki sposób, żeby mogły być używane przez nakładkę Drools dla jęcyka C# [17]. Poszczególne przesłanki są reprezentowane za pomocą klasy Node- Value, 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 Drools.Result.add("<identyfikator diagnozy dla której zdefiniowano regułę>"); end

4.6. Panel Lekarza 47 structure.xml - plik zawierający dane uszczwegół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 4.6. 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 DicomSR 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 DicomSR 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.

4.6. Panel Lekarza 48 Rysunek 4.9: Zakładka pozwalająca na zarządzanie stanem raportu COMPLETE -> PARTIAL - standard DicomSR, 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 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.

4.6. Panel Lekarza 49 (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