praca dyplomowa - Politechnika Krakowska

Transkrypt

POLITECHNIKA KRAKOWSKA im. T. Ko ciuszki
Wydzia Mechaniczny
Instytut Informatyki Stosowanej
Kierunek studiów: Informatyka
Specjalno!"
: Informatyka Stosowana
STUDIA STACJONARNE
PRACA DYPLOMOWA
MAGISTERSKA
Rafa! Petryniak
Internetowy system wspomagaj#cy lekarza w diagnozowaniu
na podstawie obrazów medycznych.
Promotor:
Dr in$. Zbigniew Lata!a
Kraków, rok akad. 2005/2006
Praca dost%pna na licencji Creative Commons 2.5
(Uznanie autorstwa-U$ycie niekomercyjne-Na tych samych warunkach).
[Pe na tre!" licencji zosta a umieszczona w za #czniku C]
KARTA PRACY DYPLOMOWEJ
POLITECHNIKA KRAKOWSKA
WYDZIA" MECHANICZNY
INSTYTUT INFORMATYKI STOSOWANEJ
Zak!ad Komputerowej Analizy Obrazu M-74
Nr pracy:
Autor pracy:
Rafa! Petryniak
Promotor:
Dr in#. Zbigniew Lata!a
Temat:
Internetowy system wspomagaj$cy lekarza w diagnozowaniu na podstawie obrazów
medycznych.
……………………….
Podpis promotora
…………………………………….
Kierownika specjalno!ci
Uzgodniona ocena pracy: ……………………………………………………………………..
……………………….
Podpis promotora
.................................................
Podpis recenzenta
.......................................................
Dyrektora Instytutu
ds. Dydaktyki
Podzi%kowania
Serdeczne podzi%kowania za zaanga$owanie i pomoc udzielon# w trakcie pisania niniejszej
pracy chcia bym z &$'" Panu dr in$. Zbigniewowi Latale oraz Panu mgr in$. Dariuszowi
Karpiszowi.
Na koniec pragn% równie$ podzi%kowa" Kole$ance Magdalenie Lewickiej za ci#( e wsparcie
duchowe i merytoryczne.
WPROWADZENIE – CEL I ZAKRES PRACY ....................................................................................... 4
I.
CZ !" TEORETYCZNA....................................................................................................... 5
ROZDZIA# 1. TECHNIKI AKWIZYCJI OBRAZÓW MEDYCZNYCH ........................................................ 6
1.1. Radiografia konwencjonalna i cyfrowa ............................................................................... 6
1.2. Tomografia komputerowa transmisyjna............................................................................... 6
1.3. Spiralna tomografia komputerowa ...................................................................................... 7
1.4. Rezonans magnetyczny........................................................................................................ 8
1.5. Ultrasonografia .................................................................................................................. 8
1.6. Inne metody akwizycji obrazu.............................................................................................. 9
ROZDZIA# 2. ZARZ DZANIE OBRAZAMI MEDYCZNYMI .................................................................. 9
2.1. Zapis danych obrazowych - format DICOM .......................................................................10
2.1.1. Problemy zwi!zane ze stosowaniem formatu DICOM...............................................................10
2.1.2. Przegl!darki zdj"# w formacie DICOM.....................................................................................10
2.2. Organizacja sk adowania danych obrazowych - systemy PACS ..........................................11
2.2.1. Funkcje systemów PACS..........................................................................................................11
2.2.2. Budowa systemów PACS .........................................................................................................11
ROZDZIA# 3. REKONSTRUKCJA PRZESTRZENNA OBRAZÓW MEDYCZNYCH ....................................12
3.1. Rekonstrukcja obrazu z p askich przekrojów ......................................................................12
3.2. Modelowanie obj!to"ciowe ................................................................................................13
ROZDZIA# 4. INFORMATYZACJA SZPITALA ...................................................................................13
4.1. Charakterystyka szpitalnych systemów informatycznych.....................................................13
4.1.1. Modu$y centralne .....................................................................................................................14
4.1.2. Systemy peryferyjne.................................................................................................................14
4.2. Integracja systemów informatycznych (DICOM, HL7)........................................................14
ROZDZIA# 5. TELEMEDYCYNA .....................................................................................................15
5.1. Wymagania stawiane systemom telemedycznym .................................................................15
5.1.1. Dost"pno%# szybkich $!cz telekomunikacyjnych........................................................................15
5.1.2. Integracja nowoczesnych urz!dze& przeno%nych .......................................................................15
5.1.3. Ujednolicony format cyfrowej reprezentacji informacji medycznej............................................15
5.1.4. Zapewnienie transmisji obrazu w czasie rzeczywistym - wideokonferencje ...............................15
5.1.5. Bezpiecze&stwo przesy$u informacji medycznej........................................................................16
5.1.6. Integracja specjalistycznej aparatury z sieci! komputerow! .......................................................16
5.1.7. Automatyzacja i prze'roczysto%# ..............................................................................................16
5.2. Obszary zastosowa# telemedycyny .....................................................................................16
1
II.
CZ !" PRAKTYCZNA ........................................................................................................17
ROZDZIA# 6. KONCEPCJA SYSTEMU .............................................................................................17
ROZDZIA# 7. ANALIZA WYMAGA( ...............................................................................................18
7.1. S ownik..............................................................................................................................18
7.2. Modele systemu..................................................................................................................21
7.2.1. Model przep$ywu informacji.....................................................................................................21
7.2.2. Model architektury systemu......................................................................................................22
7.3. Analiza wymaga# funkcjonalnych ......................................................................................23
7.4. Analiza wymaga# niefunkcjonalnych..................................................................................28
7.4.1. Bezpiecze&stwo........................................................................................................................28
7.4.2. Wymagania sprz"towe..............................................................................................................28
7.4.3. Pozosta$e wymagania systemu ..................................................................................................29
ROZDZIA# 8. PROJEKT I WYKONANIE SYSTEMU ............................................................................30
8.1. Modelowanie zachowa# systemu........................................................................................30
8.2. Projekt bazy danych...........................................................................................................35
8.3. Projekt interfejsu u$ytkownika............................................................................................37
8.4. Iteracyjny proces budowania systemu ................................................................................38
8.5. Opis poszczególnych modu ów systemu ..............................................................................40
8.5.1. Szkielet systemu.......................................................................................................................41
8.5.2. Modu$ DICOM.........................................................................................................................51
8.5.3. Modu$ Wizualizacja .................................................................................................................54
8.5.4. Modu$ Komunikacja.................................................................................................................57
8.6. Opis instalacji i konfiguracji projektu. ...............................................................................59
8.6.1. Przygotowanie infrastruktury sprz"towej ..................................................................................59
8.6.2. Przygotowanie niezb"dnego oprogramowania...........................................................................59
8.6.3. Instalacja systemu InterMed .....................................................................................................60
8.6.4. Utrzymanie systemu .................................................................................................................60
ROZDZIA# 9. PRÓBA WIZUALIZACJI PRZESTRZENNEJ OBRAZU .......................................................61
9.1. Wybór internetowej technologii wizualizacji przestrzennej. ................................................61
9.1.1. Przegl!d i krótka charakterystyka narz"dzi wizualizacji w Internecie.........................................61
9.2. Przygotowanie danych .......................................................................................................62
9.2.1. Wyznaczanie konturów ............................................................................................................62
9.2.2. Wyznaczanie wspó$rz"dnych ....................................................................................................64
9.3. Wizualizacja VRML / X3D .................................................................................................66
9.3.1. Technologia VRML / X3D .......................................................................................................66
9.3.2. Wizualizacja punktowa.............................................................................................................67
9.3.3. Wizualizacja p$aszczyzny - napotkane problemy.......................................................................68
2
ROZDZIA# 10. PERSPEKTYWY ZASTOSOWANIA I ROZWOJU SYSTEMU ............................................69
10.1. Scenariusze u$ycia systemu ..............................................................................................69
10.1.1. System jako us$uga zewn"trzna...............................................................................................69
10.1.2. System u klienta .....................................................................................................................70
10.2. Perspektywy rozwoju i integracji systemu.........................................................................70
10.2.1. Obrazy pobierane z systemu PACS.........................................................................................70
10.2.2. Informacja o badaniu pobierana z systemu RIS / HIS ..............................................................71
10.2.3. Usprawnienie komunikacji poprzez wideo-konferencje ...........................................................72
11. ZAKO$CZENIE .......................................................................................................................73
11.1. Podsumowanie.................................................................................................................73
11.2. Prezentacja projektu ........................................................................................................74
11.3. Prowadzenie prac ............................................................................................................75
11.3.1. Portal projektowy ...................................................................................................................75
11.3.2. System kontroli wersji ............................................................................................................76
11.3.3. Format zapisu dokumentacji technicznej.................................................................................78
11.3.4. WIKI......................................................................................................................................79
12. WNIOSKI ................................................................................................................................81
13. LITERATURA ..........................................................................................................................82
Ksi%$ki .....................................................................................................................................82
Rozprawy doktorskie.................................................................................................................82
Artyku y....................................................................................................................................82
Adresy WWW............................................................................................................................83
DODATEK A. Z)* CZNIKI ............................................................................................................85
A.1. Struktura katalogów aplikacji WWW .................................................................................85
A.2. Skrypty tworz%ce schemat bazy danych ..............................................................................86
DODATEK B. Z)* CZNIKI W POSTACI CYFROWEJ .........................................................................87
DODATEK C. TRE+, I WARUNKI LICENCJI .....................................................................................88
SPIS RYSUNKÓW ...........................................................................................................................89
SPIS TABEL ...................................................................................................................................90
SPIS PRZYK*ADÓW........................................................................................................................90
3
Wprowadzenie – cel i zakres pracy
Ogromny rozwój i upowszechnienie si" w ostatnich latach nowoczesnych systemów
teleinformatycznych mia$o du-y wp$yw na popraw" funkcjonowania informatycznych
systemów szpitalnych. Ju- nie tylko integracja poszczególnych urz!dze& i aplikacji by$a
mo-liwa, ale pojawi$y si" równie- nowe formy %wiadczenia us$ug medycznych. Szerokie
zastosowania mog! znale'# rozwi!zania oferuj!ce wymian" opinii mi"dzy specjalistami,
z mo-liwo%ci! przesy$ania obu stronom ró-nego rodzaju potrzebnych informacji,
a w szczególno%ci diagnostycznych obrazów medycznych.
.$ównym celem niniejszej pracy jest realizacja systemu informatycznego opartego o sie%
Internet, który b&dzie wspiera' lekarza w diagnozowaniu na podstawie wykonanych
zdj&% medycznych. Zak$ada si", -e zakres mo-liwo%ci tego systemu b"dzie obejmowa$:
•
•
•
•
obs$ug" podstawowych funkcji kartoteki bada&:
o dodawanie nowego badania
o przegl!danie i edycja istniej!cych bada&
o wyszukiwanie bada& wg zadanych kryteriów
sk$adowanie zdj"# medycznych zapisanych w standardowych formatach w jednym
miejscu,
umo-liwienie komunikacji osób pracuj!cych nad danym badaniem i rozproszonych
geograficznie,
dostarczenie filtrów graficznych, umo-liwiaj!cych przetwarzanie obrazów w celu
wydobycia istotnych informacji dla osoby przegl!daj!cej zdj"cia.
W pierwszej cz"%ci pracy (cze ! teoretyczna) zosta$a poruszona tematyka wykorzystania
informatyki w problemach diagnostyki obrazowej, ze szczególnym uwzgl"dnieniem
mo-liwo%ci jakie oferuje sie# Internet.
W drugiej cz"%ci pracy (cz" ! praktyczna) przedstawiono dok$adn! charakterystyk"
wykonanego systemu, wskazuj!c nie tylko uzyskane wyniki, ale równie- napotkane problemy
i sposoby ich rozwi!zywania.
4
I. Cz&(% teoretyczna
Technologia komputerowa na prze$omie wieków XX i XXI by$a ju- obecna niemal we
wszystkich dziedzinach -ycia spo$ecznego. Szerokie zastosowanie komputerów nie omin"$o
tak-e medycyny.
Zastosowanie informatyki w medycynie si"ga lat 60, kiedy to w Stanach Zjednoczonych
zauwa-ono jakie mo-liwo%ci daje to wojsku. Kolejne lata przynios$y bardzo intensywny
rozwój bada& nad wykorzystaniem technologii informatycznych w ró-nych obszarach
ochrony zdrowia. W latach 70 pojawi$y si" pierwsze systemy administracyjne, ekspertowe
(Mycin), a tak-e obrazowe (tomografia komputerowa). Lata 80 to okres budowy systemów
klinicznych, wykorzystania baz danych oraz kolejne próby wykorzystania sztucznej
inteligencji. Lata 90 przynios$y natomiast rozwój telemedycyny, wizualizacji 3D, oraz
standaryzacj" danych medycznych (DICOM). Obecnie trudno sobie wyobrazi# prac" lekarzy
specjalistów bez wsparcia odpowiednich technologii informacyjnych.
Profesor W$odzis$aw Duch [19] wyró-nia kilka obszarów zastosowa& komputerów
w medycynie:
•
•
aparatura medyczna
mo-liwo%# przechowywania du-ych ilo%ci danych i szybkiego dost"pu do tych danych
np. komputeryzacja administracji placówek medycznych, bazy danych dotycz!ce
chorób
•
•
zdalny dost"p do danych medycznych i mo-liwo%# ich przesy$ania, konsultacje
ekspertów
teleobecno%# i wirtualna rzeczywisto%#
np. przeprowadzanie operacji na odleg$/%#
•
inteligentna analiza danych medycznych i wspomaganie podejmowania decyzji
5
Rozdzia' 1. Techniki akwizycji obrazów medycznych
Techniki obrazowania medycznego odgrywaj! bardzo wa-0! rol" we wspó$czesnej
medycynie. Szczególny wp$yw wywar$y na diagnostyk", gdzie mo-liwe sta$o si" wykrywanie
schorze& zanim zaczn! dawa# objawy, co znacznie zwi"ksza szans" pacjenta na szybki
powrót do zdrowia, a w wielu przypadkach ratuje mu -ycie [25].
1.1. Radiografia konwencjonalna i cyfrowa
Badania rentgenowskie ci!gle jeszcze stanowi! wi"kszo%# bada& obrazowych. Opieraj! si"
one na odkrytych przez wiede&skiego badacza K.W.Roentgena promieniach X, które
przechodz!c przez badane tkanki ulegaj! os$abieniu, w zale-no%ci od ich grubo%ci i sk$adu
chemicznego [16]. Badacz ten, zbudowa$ równie- pierwsz! lamp" wykorzystuj!1! odkryte
przez siebie promienie, nazwan! na jego cze%# rentgenowsk!.
W tradycyjnym badaniu radiograficznym obraz zapisywany jest na kliszy, która poddawana
jest obróbce chemicznej (podej%cie konwencjonalne). Jednak-e istniej! ju- systemy,
pozwalaj!ce przeprowadzi# ca$e badanie stosuj!c zapis cyfrowy (radiografia cyfrowa), co
wp$ywa na znaczne obni-enie kosztów samego badania, jak równie- umo-liwia $atwiejszy
dost"p do tych danych.
Rysunek 1.1. Zdj&cie rentgenowskie d'oni )ony Roentgena wykonane przez samego
K.W. Roentgena w 1896
1.2. Tomografia komputerowa transmisyjna
Tradycyjne badanie radiologiczne ma pewne ograniczenia. Obraz b"2!cy wynikiem tego
badania jest obrazem sumacyjnym, co znaczy, -e jest sum! cieni ró-nych narz!dów
nak$adaj!cych si" na siebie, je-eli le-3$y one jeden nad drugim na drodze promieniowania
rentgenowskiego [1].
6
Dla lekarza taka informacja cz"sto jest niewystarczaj!ca. Dopiero maj!c kilka obrazów,
wykonywanych z kilku ró-nych kierunków, jest on w stanie wyobrazi# sobie dok$adniej
budow" analizowanego narz!du.
W latach 70 Godfrey Newbold Hounsfield i Allan McLeod Cormack zbudowali tomograf
komputerowy, który na podstawie serii obrazów radiograficznych wykonywanych pod
ró-nymi k!tami i zastosowaniu odwrotnej transformaty Fouriera by$ w stanie zrekonstruowa#
przekrój badanego obiektu. Za swoje osi!gni"cia otrzymali w 1997 roku nagrod" Nobla
w dziedzinie medycyny.
Rysunek 1.2. Zdj&cie tomograficzne dziewi&cioletniej dziewczynki
W nowoczesnych tomografach komputerowych lampa emituj!ca wi!zk" promieni RTG
obraca si" wokó$ pacjenta w p$aszczy'nie osiowej o 360°. Os$abienie wi!zki promieni RTG
spowodowane ich przechodzeniem przez cia$o jest rejestrowane przez uk$ad detektorów
(komory jonizacyjne, kryszta$y scyntylacyjne, itp. ) i przetwarzane na sygna$y elektryczne.
Sygna$y te s! nast"pnie przekazywane do komputera, który w wyniku bardzo z$/-onych
algorytmów tworzy na ich podstawie obrazy reprezentuj!ce badane cz"%ci cia$a cz$owieka
[16].
1.3. Spiralna tomografia komputerowa
Obrazy uzyskane przy u-yciu tomografu komputerowego odzwierciedlaj! jeden przekrój
badanego obiektu. Jednak do pe$nego rozeznania anatomii badanej cz"%ci cia$a wskazane
by$oby wykonanie kilku obrazów na ró-nych wysoko%ciach. Problemem jaki w takiej sytuacji
si" pojawia jest du-a ilo%# promieniowania jakiemu poddawany jest pacjent oraz trudno%#
uzyskania równoleg$ych przekrojów (np. pacjent si" poruszy$). Rozwi!zaniem w takiej
sytuacji mo-e by# spiralna tomografia komputerowa [1], podczas której nie wykonuje si" serii
zdj"#, a jeden ci!4$y pomiar. W badaniu tym poza ruchem obrotowym lampy RTG
i detektorów - jak to ma miejsce w tradycyjnej Tomografii Komputerowej - przesuwa si" do
przodu $5-ko, na którym le-y pacjent.
7
Uzyskane w ten sposób dane mog! by# wykorzystywane do tworzenia przekrojów
w dowolnej p$aszczy'nie (X,Y,Z) i pod dowolnym k!tem, a z pomoc! specjalnych
programów komputerowych mo-na wygenerowa# nawet obraz przestrzenny (3D).
1.4. Rezonans magnetyczny
W badaniu tym pacjent umieszczony jest w komorze aparatu, w której wytwarzane jest sta$e
pole magnetyczne o wysokiej energii. W$asno%# ta powoduje, -e linie pola magnetycznego
6!der atomów w ciele cz$owieka ustawiaj! si" równolegle do kierunku pola magnetycznego.
Aparat dodatkowo emituje fale radiowe, które wzbudzaj! w tkankach pacjenta podobne fale
radiowe (zjawisko to nazywa si" rezonansem), a one rejestrowane s! przez aparat. W praktyce
jako 'rezonator' wykorzystuje si" j!dra atomu wodoru, których liczba w poszczególnych
tkankach jest inna. Wykorzystuj!c tan fakt komputer wbudowany w urz!dzenie po wykonaniu
skomplikowanych oblicze& przedstawia na ekranie monitora obraz badanych struktur
anatomicznych.
Rysunek 1.3. Zdj&cie przekrojowe g'owy cz'owieka wykonane w badaniu rezonansem
magnetycznym
1.5. Ultrasonografia
Ultrasonografia jest nieinwazyjn! metod! obrazowania narz!dów i tkanek cia$a ludzkiego,
w której wykorzystuje si" fale ultrad'wi"kowe. Fale te rozchodz!c si" w ciele badanego
pacjenta, ulegaj! odbiciu na granicy dwóch o%rodków o ró-nej g"sto%ci. Zamieniaj!c powsta$y
w ten sposób impuls akustyczny na impuls elektryczny i po wprowadzeniu skali szaro%ci
poprzez uk$ady elektroniczne w ultrasonografie, na ekranie monitora powstaje obraz wybranej
warstwy narz!du czy tkanki. Przesuwaj!c g$owic! aparatu, uzyskuje si" obraz ca$ego
badanego narz!du.
Wi"kszo%# stosowanych metod diagnostycznego obrazowania za pomoc! ultrad'wi"ków
oparta jest na technice impulsowo-echowej. Badania takie wykonuje si" za pomoc! aparatów
ultrasonograficznych, które pozwalaj! na uzyskiwanie obrazów USG w czasie rzeczywistym,
czyli zgodnie z ruchomo%ci! danego obrazu [17].
8
Obraz w ten sposób otrzymany mo-e zosta# utrwalony na kliszy fotograficznej, b!2' tezapisany w formie elektronicznej na dysku komputera i poddany bardziej szczegó$owej
analizie (odleg$/%ci dowolnych punktów, wielko%ci k!ta zawartego mi"dzy elementami
anatomicznymi).
Rysunek 1.4. Ultrasonografia czteromiesi&cznego p'odu
1.6. Inne metody akwizycji obrazu
Oprócz wy-ej wymienionych technik akwizycji obrazu istniej! m.in.:
•
•
•
tomografia komputerowa emisyjna:
o tomografia emisyjna pojedynczego fotonu - SPET
o tomografia emisyjna pozytronowa - PET
6!drowy rezonans magnetyczny
angiografia rezonansu magnetycznego
Szczegó$owe opisy mo-na znale'# w literaturze [2] [1].
Rozdzia' 2. Zarz*dzanie obrazami medycznymi
Nowoczesne systemy akwizycji obrazu zapisuj! wyniki w postaci plików graficznych. Jest to
metoda znacznie ta&sza od analogowych obrazów, jakimi s! klisze fotograficzne, a tak-e
umo-liwia korzystanie z tych samych wyników w jednym momencie z kilku miejsc. Jednak-e
potrzeba zachowania jak najlepszej jako%ci tych obrazów oraz fakt, -e wiele z nich
wykonywana jest seryjnie (np. ultrasonograf generuje 30 obrazków na sekund") powoduje
ogromny wzrost zapotrzebowania na pami"# dyskow! komputerów. Wa-0! kwesti! jest
zapewnienie bezpiecze&stwa tak sk$adowanych obrazów (archiwizacja, kopie
bezpiecze&stwa) oraz ich ochrona przed nieautoryzowanym dost"pem.
9
2.1. Zapis danych obrazowych - format DICOM
Pierwotnie ka-da firma produkuj!ca sprz"t wykorzystywany w radiologii (np. tomografy
komputerowe) stosowa$a w$asne formaty zapisu obrazu. Skutkiem tego by$a konieczno%#
zakupu wszystkich urz!dze& od jednej firmy, tak aby mog$y ze sob! wspó$pracowa#. Problem
pojawi$ si", kiedy firma, od której by$ zakupiony ca$y sprz"t nie posiada$a w swojej ofercie
kolejnych, potrzebnych urz!dze&, lub gdy konkurencja dysponowa$a takim samym o lepszych
parametrach i ni-szej cenie.
Pierwsze próby opracowania wspólnego standardu wymiany obrazów medycznych zosta$y
poczynione na pocz!tku lat 80 przez dwie instytucje: American College of Radiology [30]
i National Electrical Manufactures Association [31] (ACR-NEMA). G$ównym zadaniem by$o
rozwi!zanie dwóch problemów:
(1) standaryzacji formatu zapisu informacji
(2) transmisji informacji pomi"dzy ró-nymi jednostkami [2].
Ostatecznie opracowany standard - DICOM [32] - zosta$ zaakceptowany przez producentów
sprz"tu medycznego otwieraj!c w ten sposób drog" do pe$nej integracji modu$ów systemu
pochodz!cych od ró-nych dostawców.
2.1.1. Problemy zwi*zane ze stosowaniem formatu DICOM
Standard DICOM jest bardzo rozbudowany - liczy kilkaset stron. Z powodu jego z$/-ono%ci
pojawia si" wiele problemów z jego interpretacj! i nie zawsze dwa urz!dzenia, które
deklaruj! stosowanie tego standardu b"2! w stanie komunikowa# si" ze sob!.
Rozwi!zaniem tego problemu mo-e by# dokument "Stwierdzenie zgodno%ci ze standardem
DICOM", który powinien by# do$!czany do ka-dego urz!dzenia zgodnego z tym standardem.
Jego zadaniem nie jest potwierdzenie ka-dego szczegó$u ze standardem DICOM, a jedynie
wskazanie zgodno%ci z okre%lonym podzbiorem wymaga& i opisanie rozszerze&
umo-liwiaj!cych instytucji wdra-aj!cej urz!dzenie, po$!czenie go z innymi urz!dzeniami
DICOM-owymi [2]. Dopiero porównanie dwóch takich dokumentów i wskazanie, -e
wzajemnie spe$niaj! swoje wymagania daje przekonanie, -e ich wspó$praca powinna
odbywa# si" bez zak$óce&.
2.1.2. Przegl*darki zdj&% w formacie DICOM
Ka-dy zak$ad radiologii powinien dysponowa# co najmniej jedn! stacj! diagnostyczn!,
umo-liwiaj!1! dok$adn! analiz" wykonanego badania. Do przegl!dania archiwów obrazów
radiologicznych konieczne jest posiadanie specjalistycznego oprogramowania, które nie tylko
rozumie specyficzne formaty danych, ale równie- umo-liwia manipulowanie nimi [25].
Poza grup! drogich, komercyjnych rozwi!za& dost"pne s! dwie przegl!darki, oferowane za
darmo, bez -adnych op$at licencyjnych.
Pierwsza z nich o nazwie K-PACS [33] umo-liwia komunikacj" z serwerem PACS,
wi"kszo%# operacji graficznych na obrazach, eksport do innych formatów (m.in. JPEG, BMP)
oraz na p$yty CD [16].
10
Druga przegl!darka – OsiriX [34] – posiada podobne mo-liwo%ci do K-PACS-a. Udost"pnia
ona dodatkowo zaawansowane funkcje do generowania rekonstrukcji 3D. Dost"pna jest ona
jednak-e tylko na platform" Macintosh, co zaw"-a grono potencjalnych u-ytkowników.
2.2. Organizacja sk'adowania danych obrazowych - systemy PACS
Szybki rozwój technologiczny umo-liwiaj!cy zapis obrazów w postaci cyfrowej, zmieni$
sposób ich analizy oraz przyczyni$ si" do reorganizacji archiwizacji i dystrybucji [2].
W latach 80 powsta$y pierwsze systemy PACS (Picture Archiving and Communication
System), które pozwala$y na przechowywanie i zarz!dzanie danymi obrazowymi. Jednak-e
dopiero po wprowadzeniu standardu DICOM, systemy te w pe$ni realizuj! swoje funkcje i
pozwalaj! na pe$0! integracj" z innymi urz!dzeniami szpitala.
2.2.1. Funkcje systemów PACS
W drugim numerze Biuletynu Informatyki Medycznej [17] autorzy wyró-niaj! kilka funkcji,
które powinny spe$nia# systemy PACS:
•
•
•
•
•
•
archiwizacja obrazów - zapewnienie bezpiecze&stwa sk$adowania i udost"pniania
danych obrazowych.
bezpiecze+stwo sk'adowania danych - utrzymanie kopii ka-dego obrazu na innym
komputerze.
komunikacja z urz*dzeniami diagnostycznymi - automatyzacja przesy$u obrazów
z urz!dze& diagnostycznych do serwera PACS.
udost&pnianie danych obrazowych - umo-liwienie przegl!danie danych
sk$adowanych w systemie PACS ma stacjach diagnostycznych.
autorouting - automatyczne przesy$anie danych obrazowych na stacje diagnostyczne
w celu umo-liwienia ich oceny przez radiologa. System powinien umo-liwia#
definiowanie regu$ przesy$u danych (np. wybór komputera, godziny dostarczenia).
prefetching - automatyczne wyszukiwanie poprzednich bada& w celach
porównawczych.
2.2.2. Budowa systemów PACS
Systemy PACS sk$adaj! si" z czterech elementów:
•
•
•
•
urz!dzenia akwizycji obrazu (np. tomografy komputerowe)
stacji diagnostycznych
serwera
sieci Internet / Intranet
11
Rysunek 2.1. Budowa systemu PACS
Dzi"ki wykorzystaniu standardu DICOM istnieje mo-liwo%# ich integracji z innymi
systemami szpitala, takimi jak HIS, RIS.
Rozdzia' 3. Rekonstrukcja przestrzenna obrazów
medycznych
Obrazy p$askie - dotychczas analizowane przez lekarzy specjalistów / radiologów - nie s!
naturalne dla cz$owieka, który -yje w %wiecie o trzech wymiarach przestrzennych [26].
Dlatego twórcy nowoczesnych systemów obrazowania i prezentacji danych medycznych
staraj! si" coraz cz"%ciej wykorzystywa# mo-liwo%ci grafiki trójwymiarowej.
.$ównym problemem przy wizualizacji przestrzennej pozostaje brak standardów zapisu
obrazu 3D. Nawet ogólnie przyj"ty format jakim jest DICOM nie daje takiej mo-liwo%ci.
Dlatego w obecnej chwili ci!gle konieczny jest zapis danych w postaci serii zdj"#, a nast"pnie
ich rekonstrukcja w specjalistycznych programach. Optymistyczny mo-e wydawa# si" rozwój
nowoczesnych technologii, które umo-liwiaj! zapis wyników z badania w postaci danych
obj"to%ciowych1, co z kolei pozwala na $atwiejsze ich przetwarzanie.
3.1. Rekonstrukcja obrazu z p'askich przekrojów
Obecnie najcz"stsz! form! zapisu obrazów pozyskanych w trakcie bada& radiologicznych s!
pojedyncze pliki lub ich serie przedstawiaj!ce przekroje badanej cz"%ci cia$a.
W tym celu najcz"%ciej stosuje si" nast"puj!ce formaty:
•
•
•
DICOM
TIFF (umo-liwia zapis serii zdj"#)
BMP, ewentualnie JPG (kompresja stratna)
Aby wygenerowa# obiekt trójwymiarowy z takich danych, program musi wykona# szereg
skomplikowanych operacji. Najpierw ka-dy obraz jest poddawany analizie, podczas której
1
Poj"cie szerzej wyja%nione w rozdziale 3.2.
12
wydzielany jest zbiór punktów nale-!cych do kraw"dzi. Proces ten odbywa si"
z wykorzystaniem zaawansowanych filtrów wykrywania kraw"dzi. Nast"pnie wydzielone
zbiory punktów dla poszczególnych p$aszczyzn powinny zosta# przetransformowane do
przestrzeni trójwymiarowej. W ostatnim etapie stosuje si" morfing, który pozwala na
przybli-enie warstw po%rednich, co umo-liwia odwzorowanie pe$nego obiektu
przestrzennego. Metoda ta wymaga komputerów o du-ej mocy obliczeniowej i jest obarczona
7$"dami, które mog! pojawi# si" na dowolnym etapie rekonstrukcji (wydzielanie konturów,
morfing).
3.2. Modelowanie obj&to(ciowe
Nowoczesne metody akwizycji obrazu (np. spiralna tomografia komputerowa) dokonuj!
pomiaru ci!4$ego (zdj&cia obj&to(ciowe). Dane w ten sposób pozyskane nie musz! by#
aproksymowane (morfing) poniewa- jest ju- dost"pna pe$na informacja z badanego
przedzia$u. Dane te nie s! ju- tworami p$askimi, lecz nios! ze sob! trójwymiarow! informacj"
- dane o wewn"trznej strukturze obiektu [27]. Zapisywane s! one w plikach obj&to(ciowych
(ang. volume data set [3]), zwanych te- teksturami wolumetrycznymi (ang. volumetric
texture [4]), które za pomoc! specjalnego oprogramowania mog! by# przegl!dane
w dowolnym kierunku (X, Y, Z). Jednak-e to nie koniec mo-liwo%ci, jakie daje ten sposób
akwizycji danych. Powsta$y algorytmy modelowania obj&to(ciowego (ang. volume rendering
[3]), które na podstawie tych danych s! w stanie bardzo dok$adnie odwzorowa# badane
struktury anatomiczne. Umo-liwiaj! one dodatkowo usuwanie warstwa po warstwie
poszczególnych tkanek, co mo-e by# bardzo pomocne w szczegó$owej analizie
poszczególnych organów.
Rozdzia' 4. Informatyzacja szpitala
Wzrost ilo%ci informacji opisuj!cej stan zdrowia pacjenta oraz konieczno%# jej gromadzenia,
a w razie potrzeby natychmiastowego udost"pnienia do dalszej analizy powoduje, -e
tradycyjne metody zarz!dzania danymi w placówkach s$8-by zdrowia przestaj! by#
wystarczaj!ce. Konieczne staje si" informatyzowanie kolejnych obszarów dzia$alno%ci tych
jednostek. Wiele prób wprowadzenie nowych technologii zosta$o podj"tych ju- kilkadziesi!t
lat temu, jednak-e ówczesne ograniczenia technologiczne i nieumiej"tno%# wykorzystania
nowego narz"dzia dramatycznie ograniczy$y oczekiwane korzy%ci [15]. Od kilku lat trwa
kolejna faza komputeryzacji, w której dzi"ki do%wiadczeniu zdobytemu na przestrzeni lat
i ogromnemu post"powi technologicznemu, a tak-e wprowadzeniu norm i standardów
powstaj! rozwi!zania dla ka-dej strefy dzia$ania szpitala. Integracja tych rozwi!za& pozwala
na budow" kompleksowych szpitalnych systemów informatycznych.
4.1. Charakterystyka szpitalnych systemów informatycznych
Szpitalne systemy informatyczne (ang. Hospital Information System - HIS) sk$adaj! si"
z wielu modu$ów tworz!cych jeden zintegrowany system. Poni-sza charakterystyka zosta$a
oparta na klasyfikacji zaproponowanej przez Ew" Pi"tk" w ksi!-ce 'Zintegrowany system
informacyjny w pracy szpitala' [2].
13
4.1.1. Modu'y centralne
•
•
•
Modu' Ruchu Chorych pacjentów szpitalnych - umo-liwia obs$ug" ruchu pacjenta
od chwili przyj"cia na Izb" Przyj"# do momentu jego wypisu ze szpitala. Przechowuje
on nie tylko informacje o samym pacjencie (dane teleadresowe, lekarz lub jednostka
kieruj!ca), ale rejestruje równie- histori" jego pobytu w szpitalu (numer sal, w których
przebywa$, daty przepustek i inne).
Modu' Ruchu Chorych pacjentów ambulatoryjnych - pozwala wyznaczy# wizyt"
w danej poradni i u konkretnego lekarza, a po jej odbyciu rejestruje diagnoz" i list"
wykonanych procedur.
Modu' Zlece+ Medycznych - rejestruje zdarzenia w kolejnych etapach realizacji
procedury medycznej, od jej zlecenia do udost"pnienia wyniku na stacji klinicysty.
4.1.2. Systemy peryferyjne
•
•
•
•
Laboratoryjny System Informacyjny (ang. Laboratory Information System - LIS) modu$ ten wspomaga zarz!dzanie zleceniami na wykonanie analiz laboratoryjnych.
Farmaceutyczny System Informacyjny (ang. Pharmacy Information System - PIS) wspomaga on dzia$anie apteki w zakresie obrotu lekami sprowadzanymi z hurtowni,
7!2' produkowanymi we w$asnym zakresie.
Radiologiczny System Informacyjny (ang. Radiology Information System - RIS) zapewnia obs$ug" informatyczn! procedur realizowanych w ramach diagnostyki
obrazowej. Zlecenia mog! by# przesy$ane z ogólnoszpitalnego systemu
informatycznego (HIS), b!2' te- z rejestracji pacjentów ambulatoryjnych.
System Archiwizacji i Transmisji Obrazów (ang. Picture Archiving and
Communication System - PACS) - w odró-nieniu od wy-ej opisanych modu$ów,
system ten nie zarz!dza informacj! alfanumeryczn!, a danymi obrazowymi. Jego
4$ównym zadaniem jest gromadzenie obrazów pochodz!cych z bada& radiologicznych
i ich udost"pnianie na stacjach diagnostycznych.
4.2. Integracja systemów informatycznych (DICOM, HL7)
Wraz ze wzrostem stopnia skomplikowania szpitalnych systemów informatycznych pojawi$
si" problem $!czenia kolejnych jego modu$ów, szczególnie tych, obs$uguj!cych urz!dzenia
peryferyjne. Firmy informatyczne cz"sto wykorzystywa$y w$asne standardy, które nie
umo-liwia$y pod$!czenia oprogramowania / sprz"tu innych firm. Naciski u-ytkowników
i pojawiaj!ca si" frustracja firm informatycznych, które nie potrafi$y spe$ni# wszystkich
wymaga& swoich klientów, doprowadzi$y do powo$ania komitetów normalizacyjnych,
których zadaniem by$o opracowanie standardów wymiany informacji w systemach
medycznych.
Sposób transmisji i format zapisu danych obrazowych zosta$ zawarty w standardzie DICOM
opracowanym przez ACR-NEMA (format ten zosta$ dok$adnie opisany w rozdziale 'Zapis
danych obrazowych - format DICOM'). Natomiast format przesy$ania informacji tekstowej
w standardzie HL7 (Health Level 7) [35], którego rozwojowi patronuje Health Level Seven.
Normalizacja ta pozwoli$a na integracj" systemów pochodz!cych od ró-nych dostawców
i umo-liwi$a ich wzajemn! komunikacj" [20].
14
Rozdzia' 5. Telemedycyna
Ogromny rozwój i upowszechnienie si" w ostatnich latach nowoczesnych technologii
teleinformatycznych mia$o wp$yw na pojawienie si" nowych form %wiadczenia us$ug
medycznych, ogólnie zwanych telemedycyn!. Jest ona m.in. definiowana [1] jako kontakt
lekarza z pacjentem, znajduj!cym si" w innym miejscu. Pierwsze formy telemedycyny
pojawi$y si" ju- kilkadziesi!t lat temu z wykorzystaniem $!czno%ci telefonicznej i radiowej.
Obecny jej kszta$t natomiast w du-ym stopniu uzale-niony jest od post"pu w dziedzinie
informatyki i zaanga-owaniu rz!dów i instytucji medycznych w jej rozwój.
5.1. Wymagania stawiane systemom telemedycznym
Telemedycyna jest bardzo m$od! dyscyplin! zarówno w medycynie, jak i w informatyce.
Wiele istniej!cych systemów by$o tworzonych jako projekty badawcze obejmuj!ce swoim
zasi"giem jedn! lub kilka jednostek s$8-by zdrowia. Aby mog$y sprosta# oczekiwaniom i sta#
si" szeroko stosowane musz! spe$nia# okre%lone wymagania, które przedstawiono poni-ej.
5.1.1. Dost&pno(% szybkich '*cz telekomunikacyjnych
Warunek ten jest niezwykle wa-ny w celu zagwarantowania odpowiedniego czasu
oczekiwania na reakcj" systemu, która nie powinna przekracza# kilku sekund, a w wielu
sytuacjach (wideokonferencje, zagro-enie -ycia) powinna si" odbywa# w czasie
rzeczywistym. W tym przypadku zaleca si" stosowanie wydajnych sieci szerokopasmowych,
które b"2! w stanie sprosta# wi"kszo%ci wymaga&. Natomiast w przypadku transmisji obrazu
wysokiej rozdzielczo%ci ich parametry mog! okaza# si" niewystarczaj!ce, wówczas zaleca si"
stosowanie technik kompresji informacji, co mo-e przynie%# znaczn! popraw" przesy$ania
danych.
5.1.2. Integracja nowoczesnych urz*dze+ przeno(nych
Aby zapewni# dost"p do informacji medycznej w dowolnym czasie i z dowolnego miejsca
(np. z miejsca wypadku lub domu chorego) systemy teleinformatyczne integruje si"
z urz!dzeniami przeno%nymi klasy laptop i PDA [24]. Równie- tutaj jest wskazana dobra
$!czno%# telekomunikacyjna, w szczególno%ci sieci komórkowych (GPRS, UMTS).
5.1.3. Ujednolicony format cyfrowej reprezentacji informacji medycznej
Wymóg ten spe$nia format DICOM, który poza obrazami medycznymi, mo-e zawiera# ich
opis, dane pacjenta oraz parametry wykonanego badania.
5.1.4. Zapewnienie transmisji obrazu w czasie rzeczywistym - wideokonferencje
Nowoczesne systemy teleinformatyczne powinny umo-liwia# przeprowadzenie
telekonsultacji, podczas których specjali%ci ró-nych dziedzin w o%rodkach o wy-szym
poziomie referencyjnym mog! zdalnie konsultowa# kontrowersyjne przypadki u pacjentów
znajduj!cych si" w o%rodkach peryferyjnych czy szpitalach o ni-szym poziomie
referencyjnym [21]. Jest wskazane, aby taka komunikacja odbywa$a si" w czasie
rzeczywistym, z mo-liwo%ci! przesy$ania jednocze%nie d'wi"ku i obrazu wideo
(wideokonferencje).
15
5.1.5. Bezpiecze+stwo przesy'u informacji medycznej
Dla pe$nej akceptacji i wykorzystania rozwi!za& telemedycznych w praktyce wymagana jest
gwarancja bezpiecze&stwa przesy$anych informacji. Przez d$ugie lata takiej gwarancji nie
by$o i tworzone oprogramowanie telemedyczne mog$o mie# jedynie charakter badawczy.
Dopiero w momencie wprowadzenia zaawansowanych zabezpiecze& w systemach
finansowych, zmieni$ si" pogl!d na mo-liwo%# wykorzystania Internetu w medycynie, gdzie
poziom zabezpiecze& powinien by# równie wysoki [22].
5.1.6. Integracja specjalistycznej aparatury z sieci* komputerow*
Aby umo-liwi# wykrywanie chorób we wczesnych stadiach i automatyczne zawiadamianie
9$8-b medycznych, coraz cz"%ciej stosuje si" techniki komputerowe w zminiaturyzowanej
aparaturze medycznej przeznaczonej do domowego u-ytku [19].
5.1.7. Automatyzacja i prze,roczysto(%
System telemedyczny po wdro-eniu powinien funkcjonowa# w sposób automatyczny, a jego
dzia$anie nie mo-e by# uci!-liwe ani dla pacjenta, ani dla lekarza.
5.2. Obszary zastosowa+ telemedycyny
Telemedycyna jest coraz cz"%ciej wykorzystywana w placówkach s$8-by zdrowia,
szczególnie tam gdzie pozwala to w znacznym stopniu poprawi# jako%# us$ug medycznych,
zaoszcz"dzi# czas pracowników i zmniejszy# koszty procesu diagnostyczno-terapeutycznego
[23].
Do najcz"stszych obszarów wykorzystania telemedycyny nale-!:
•
•
•
•
•
konsultacje specjalistyczne - konsultacje przeprowadzane z lekarzem specjalist!
z innego szpitala
-'ugotrwa'e leczenie, okresowe przegl*dy - diagnozowanie i monitorowanie
zdrowia pacjenta w domu
asystowanie przy trudnych zabiegach chirurgicznych - lekarz z innego szpitala
mo-e wspomaga# lekarza przeprowadzaj!cego zabieg
medycyna powypadkowa - wyposa-enie karetek pogotowia w specjalistyczny sprz"t
informuj!cy personel szpitala o bie-!cym stanie zdrowia pacjenta
e-nauczanie - dodatkowa mo-liwo%# szkolenia lekarzy oraz personelu medycznego
16
II. Cz&(% praktyczna
W cz"%ci praktycznej zostanie przedstawiony autorski system wspomagaj!cego lekarza
w diagnozowaniu na podstawie dostarczonych zdj"# medycznych.
Rozdzia' 6. Koncepcja systemu
Lekarz za pomoc! komputera pod$!czonego do Internetu komunikuje si" z systemem
InterMed. Dzi"ki dostarczonemu przez system interfejsowi ma on mo-liwo%# przegl!dania
listy dost"pnych bada&, dodania nowego badania, i podgl!d konkretnego badania. Mo-e
równie- skonsultowa# wyniki badania z innym lekarzem (konsultantem, np: radiologiem),
który wyrazi swoj! opini" na podstawie obrazów medycznych do$!czonych do badania.
Dodatkowo lekarz mo-e poinformowa# pacjenta o wynikach za pomoc! wiadomo%ci e-mail.
Pacjent otrzymuje diagnoz" oraz ewentualn! propozycj" kolejnej wizyty. Ta forma
komunikacji mi"dzy pacjentem a lekarzem nie jest jednak wystarczaj!ca i powinna zosta#
potwierdzana telefonicznie.
Wszystkie dane w systemie przechowywane s! na serwerze. Znajduj! si" tam informacje
o badaniu oraz zdj"cia diagnostyczne.
Wspólnym medium komunikacyjnym jest Internet. To dzi"ki niemu realizowana jest
komunikacja pomi"dzy lekarzem i konsultantem, oraz pacjentem.
Rysunek 6.1. Koncepcja systemu
17
Rozdzia' 7. Analiza wymaga+
Okre%lenie tego, co oprogramowanie powinno oferowa# (czyli analiza wymaga&) jest jedn!
z najwa-niejszych cz"%ci procesu tworzenia systemu. Je%li twórca nie zna dok$adnie
problemu, który ma rozwi!za#, to jest ma$o prawdopodobne, -e znajdzie u-yteczne
rozwi!zanie. Je-eli klient, dla którego jest przeznaczone oprogramowanie, nie zostanie
wys$uchany i zrozumiany, to prawdopodobnie nie b"dzie zadowolony z wyniku [6].
Wynikiem analizy wymaga& powinna by# dokumentacja wymaga&, zapisana za pomoc!
prototypów, specyfikacji, jak równie- modeli formalnych.
7.1. S'ownik
W celu zapewnienia poprawnej komunikacji mi"dzy u-ytkownikami systemu, a jego twórc!,
zosta$ przygotowany s$ownik terminów projektu. Zawiera on wszystkie terminy i specyficzne
9$ownictwo u-ywane podczas dyskusji o wymaganiach systemu [5].
:$ownik terminów (terminów, akronimów, skrótów):
InterMed
Skrót od nazwy analizowanego systemu: InterMed - Internetowy system
wspomagaj!cy lekarza w diagnozowaniu na podstawie obrazów medycznych.
synonim: system
Dostawca
Dostarcza system InterMed (np. firma informatyczna).
Klient
Instytucja lub osoba, która zamawia system od dostawcy.
Lekarz
.$ówny u-ytkownik systemu, który mo-e korzysta# ze wszystkich jego funkcji.
Konsultant
Lekarz posiadaj!cy konto w systemie. Poproszony przez innego lekarza konsultuje
jego badanie.
Pacjent
Osoba, dla której zosta$o przeprowadzone badanie.
18
Administrator
Osoba dbaj!ca o poprawn! prac" systemu InterMed. Dodaje i uaktualnia list"
pacjentów i lekarzy.
synonim: operator
Ekran Logowania
Cz"%# systemu InterMed, umo-liwiaj!ca logowanie do systemu.
E-L
Skrót od Ekranu Logowania.
Ekran Badania
Cz"%# systemu InterMed, która umo-liwia przegl!danie badania i zdj"# do niego
do$!czonych.
E-B
Skrót od Ekranu Badania
Ekran Listy Bada#
Cz"%# systemu InterMed, która wy%wietla spis wszystkich bada&.
synonim: kartoteka bada&
E-LB
Skrót od Ekranu Listy Bada&.
Ekran Nowego Badania
Cz"%# systemu InterMed, która umo-liwia wprowadzenie kolejnego badania do
systemu.
synonim: Formularz Nowego Badania
E-NB
Skrót od Ekranu Nowego Badania.
Ekran Wyszukiwania
Cz"%# systemu InterMed, która pozwala na wyszukiwanie bada& wed$ug zadanych
kryteriów.
19
E-W
Skrót od Ekranu Wyszukiwania.
Ekran Konsultacji
Cz"%# systemu InterMed, która daje mo-liwo%# wymieniania komunikatów pomi"dzy
lekarzem, a konsultantem.
E-K
Skrót od Ekranu Konsultacji.
Formularz Dodawania Zdj"!
Formularz umo-liwiaj!cy lekarzowi za$adowanie zdj"# medycznych na serwer.
Panel Opcji
Cz"%# systemu InterMed, która wy%wietla dost"pne opcje.
P-O
Skrót od Panel Opcji.
Serwer
Komputer z dost"pem do Internetu, na którym jest wdro-ony system InterMed.
Klient internetowy
Program komunikuj!cy si" z serwerem WWW np. przegl!darka WWW.
synonim: klient WWW
Parametry badania
Cz"%# informacji dot. badania tj: numer badania, nazwa badania, data badania, pacjent
(imi" i nazwisko).
20
7.2. Modele systemu
Model jest to pewna koncepcja, pierwowzór systemu zapisany za pomoc! obiektów
graficznych, prostych kszta$tów oraz schematów blokowych. Dzi"ki temu mo-e by# on
analizowany nie tylko przez twórców systemu (firm" informatyczn!), ale równie- mo-e
9$8-;# do wyja%nienia klientowi budowy systemu i funkcji jakie b"dzie oferowa$.
7.2.1. Model przep'ywu informacji
Modele przep$ywu informacji obrazuj! za pomoc! diagramów, jakie zdarzenia zachodz!
w systemie, co powoduj!, jakie s! procesy, komponenty oraz dane wej%ciowe i wyj%ciowe.
Na poni-szym diagramie zosta$ zaprezentowany model przep$ywu informacji dla systemu
InterMed.
Rysunek 7.1. Model przep'ywu informacji
21
'Nowe
badanie' jest zdarzeniem, które zapocz!tkowuje proces 'Zapis informacji
o badaniu'. Proces ten jest wspomagany przez stron" WWW. Danymi wej%ciowymi dla tego
procesu s! zdj"cia DICOM oraz zdj"cia obj"to%ciowe. Cel jaki osi!gamy w wyniku tego
procesu, to wsparcie dla lekarza w procesie diagnozy. Danymi wyj%ciowymi z kolei s!:
zarejestrowane badanie, wys$ane wyniki do pacjenta oraz pro%ba o konsultacj" skierowana do
innego lekarza. 'Pro ba o konsultacj!' jest równocze%nie zdarzeniem wywo$uj!cym
nast"pny proces: 'Konsultowanie badania', który podobnie jak proces g$ówny ('Zapis
informacji o badaniu') jest wspomagana przez stron" WWW.
7.2.2. Model architektury systemu
Model architektury prezentuje nam sposób organizacji elementów tworz!cych system.
W przypadku InterMed mo-na wyró-ni# trzy obszary, w które zorganizowane s!
poszczególne cz"%ci systemu:
•
•
•
strefa klienta
obszar Internetu
serwerowa cz"%# systemu
Rysunek 7.2. Model architektury systemu
Strefa klienta to komputery u-ytkowników pod$!czone do sieci Internet.
Obszar Internetu obejmuje infrastruktur" sieciow! umo-liwiaj!1! kontakt klienta
z systemem.
22
Serwerowa cz&(% systemu InterMed b"dzie sk$ada# si" z czterech modu$ów:
•
•
•
Modu$ DICOM i Wizualizacja, które umo-liwi! sk$adowanie i przegl!danie zdj"#
medycznych.
Modu$ Komunikacja pozwoli na kontakt mi"dzy lekarzami oraz wysy$anie wyników
do pacjenta.
Szkielet systemu b"dzie obs$ugiwa$ kartotek" bada& (dodawanie, usuwanie,
przegl!danie bada&). Modu$ ten spaja wszystkie modu$y w jeden zintegrowany
system.
System zostanie zaprojektowany do przechowywania dwóch rodzajów danych:
•
•
dane tekstowe (informacje o badaniu, diagnoza)
grafika (obrazy medyczne)
7.3. Analiza wymaga+ funkcjonalnych
Wymagania funkcjonalne definiuj!, jakie us$ugi zaoferuje system oraz jak b"dzie si"
zachowywa$ w okre%lonych sytuacjach. Wynikaj! one g$ównie z potrzeb u-ytkownika, który
wskazuje konkretne udogodnienia oczekiwane od systemu.
W trakcie projektowania systemu InterMed skorzystano z j"zyka UML (ang. Unified
Modeling Language - Ujednolicony J"zyk Modelowania) [36]. Sk$adaj! si" na niego grupy
notacji graficznych, które s$8-! do opisywania i projektowania systemów oprogramowania,
w szczególno%ci systemów oprogramowania obiektowego [8]. Dzi"ki takiemu podej%ciu
(wysoki poziom abstrakcji) powsta$a dokumentacja projektowa jest zrozumia$a nie tylko dla
twórców systemu, ale równie- dla klienta.
Ca$y proces modelowania zosta$ wykonany przy pomocy narz"dzia IBM Rational Software
Architect.
IBM Rational Software Architect [37] jest zintegrowanym narz"dziem projektowym
i programistycznym, które umo-liwia wykorzystanie techniki programowania
modelowego w j"zyku UML do opracowywania dobrze zaprojektowanych aplikacji i
us$ug.
W przeprowadzonej analizie wymaga& zosta$ utworzony zestaw diagramów i schematów,
które opisuj! kluczowe funkcje systemu i sposób ich dzia$ania. W pierwszej kolejno%ci
okre%lono czego u-ytkownicy i klienci mog! oczekiwa# od systemu. W tym celu
wykorzystano nast"puj!ce techniki j"zyka UML:
•
•
Przypadki u)ycia systemu - opisuj! w jaki sposób konkretni Aktorzy (nazwa
8-ytkownika w notacji UML) komunikuj! si" z systemem. Prezentuj! one równiepodstawow! funkcjonalno%# systemu istotn! z punktu widzenia klienta/u-ytkownika.
Diagram czynno(ci - przedstawia przep$yw czynno%ci w trakcie korzystania
z systemu InterMed. Ukazuje on w jakie interakcje wchodz! dzia$ania u-ytkowników
i dzia$ania systemu. Dzi"ki temu diagramowi uwidoczniony zosta$ kontekst dla
przypadków u-ycia.
23
Podczas analizowania wymaga& zosta$ po$/-ony szczególny nacisk na interakcje pomi"dzy
konkretnymi osobami, a systemem. Pomi"dzy g$ównymi Aktorami systemu - Lekarzem
i Konsultantem - równie- zachodz! interakcje, co zosta$o przedstawione na poni-szym
diagramie:
Rysunek 7.3. Przegl*d aktorów systemu
W systemie InterMed ta interakcja oznacza, -e ka-dy lekarz mo-e konsultowa#
przeprowadzane przez siebie badanie z dowoln! ilo%ci! innych lekarzy - konsultantów.
Interakcje wyst"puj!ce pomi"dzy poszczególnymi Aktorami, a systemem w notacji UML,
oznacza si" za pomoc! przypadków u-ycia. Na poni-szym diagramie zosta$y przedstawione
kluczowe przypadki u-ycia zachodz!ce w systemie i pogrupowane wed$ug tzw. ekranów,
w których s! one dost"pne.
24
Rysunek 7.4. Kluczowe przypadki u)ycia
Na podstawie diagramów przypadków u-ycia widzimy, -e Lekarz ma mo-liwo%# mi"dzy
innymi: zalogowania si", dodania nowego badania, wys$ania pro%by o konsultacj" do innego
Lekarza itd. Natomiast Konsultant w sytuacji konsultowania badania innego Lekarza posiada
25
prawa odczytu dla tego badania (podgl!d zdj"# medycznych, odczyt diagnozy Lekarza) oraz
mo-liwo%# wys$ania odpowiedzi (swojej diagnozy).
Dla kluczowych przypadków u-ycia zosta$ zaprojektowany diagram czynno%ci. Pozwala on
zorientowa# si" jaka mo-e by# kolejno%# wykonywania operacji przez u-ytkownika podczas
pracy z systemem.
26
Rysunek 7.5. Diagram czynno(ci dla kluczowych funkcji systemu
27
7.4. Analiza wymaga+ niefunkcjonalnych
Wymagania niefunkcjonalne nie dotycz! bezpo%rednio konkretnych funkcji systemu.
Wprowadzaj! raczej ograniczenia na system oraz specyfikuj! warunki u-ytkowania
poszczególnych jego cz"%ci. Wynikaj! one z potrzeb u-ytkownika [7].
7.4.1. Bezpiecze+stwo
Ka-de oprogramowanie zarz!dzaj!ce danymi u-ytkownika wymaga zastosowania
szczególnych %rodków bezpiecze&stwa. Z jednej strony wymaga tego prawo o ochronie
danych osobowych, a z drugiej strony niepewny system nigdy nie zdob"dzie zaufania
8-ytkownika.
Poni-ej wypisano wymagania stawiane bezpiecze&stwu systemu InterMed.
CECHA
WERYFIKOWALNY WYMIAR
Bezpieczne przechowywanie hase$
Has$a
przechowywane
w
bazie
wy$!cznie w postaci zakodowanej
Bezpieczna transmisja danych klient-serwer-klient Szyfrowane po$!czenie klient-serwer
Tabela 7.1. Wymagania dot. bezpiecze+stwa systemu 3DVS
7.4.2. Wymagania sprz&towe
System InterMed do poprawnej pracy b"dzie wymaga$ dostarczenia odpowiedniego sprz"tu
oraz infrastruktury sieciowej. Najwa-niejsze z punktu widzenia u-ytkownika jest to, -e
wystarczy mu %redniej klasy komputer z dost"pem do Internetu oraz zainstalowanym
ogólnodost"pnym oprogramowaniem (przegl!darka WWW). Z punktu widzenia systemu
kluczow! rol" b"dzie mia$o zagwarantowanie du-ej przestrzeni dyskowej w bazie danych
oraz szybki Internet.
Rysunek 7.6. Wymagania sprz&towe
28
Szczegó$owo wymagania sprz"towe zosta$y zebrane w poni-szej tabeli:
CECHA
Serwer bazy danych
Umo-liwiaj!cy przechowywanie danych binarnych (zdj"cia)
Serwer aplikacji
Liczba
klientów
internetowych
komunikuj!ca
jednocze%nie z serwerem: nieograniczona
Urz!dzenia
wej%cia
Lekarza i Odbiorcy)
(dla
Urz!dzenia
wyj%cia
Lekarza i Odbiorcy)
(dla
si"
Klawiatura, mysz
Monitor, opcjonalnie drukarka
Tabela 7.2. Wymagania dot. sprz&tu
7.4.3. Pozosta'e wymagania systemu
Poni-ej zosta$y opisane pozosta$e wymagania niefunkcjonalne systemu. Znajduj! si" tutaj
wytyczne i warunki jakie powinny zosta# spe$nione w celu uzyskania optymalnej pracy
ca$ego oprogramowania. W miar" mo-liwo%ci zosta$y one zapisane ilo%ciowo, co pozwoli na
jednoznaczn! ich interpretacj" oraz umo-liwi przeprowadzenie testów wydajno%ciowych.
CECHA
Internet
Przegl!darka
WWW
Pr"dko%# transmisji danych po stronie klienta internetowego: (zalecane
min. 100 kB)
Przegl!darki preferowane: IE 5.0, Firefox 1.07- lub nowsze wersje
Format zdj"# (zbiór 1. Zdj"cia w formacie DICOM
wej%ciowy)
2. Zdj"cia obi"to%ciowe (format nieustandaryzowany)
Rozmiar
Wymagana pojemno%# dyskowa serwera bazy danych: 1TB
Liczba rekordów w bazie: nieograniczona
Wydajno%#
Czas odpowiedzi na -!danie zalogowania do systemu: 1sek
Czas odpowiedzi na otwarcie przegl!darki: czas przes$ania 1MB x
rozmiar pobieranych danych
Czas pobierania zdj"# medycznych na komputer klienta: czas
przesy$ania 1MB x rozmiar pobieranych danych
Przenaszalno%#
Platforma docelowa: system niezale-ny od platformy
% kodu zale-nego od platformy docelowej: - z punktu widzenia
Lekarza/Odbiorcy: 0% kodu zale-nego - z punktu widzenia
systemu/Administratora: 5% kodu zale-nego od bazy danych
*atwo%#
8-ytkowania
Czas niezb"dny do przeszkolenia Lekarza: 1-2 godziny
Czas niezb"dny do przeszkolenia Konsultanta: 0.5 godziny
Czas niezb"dny do przeszkolenia Administratora: 3godziny
Tabela 7.3. Pozosta'e wymagania dot. systemu 3DVS
29
Rozdzia' 8. Projekt i wykonanie systemu
8.1. Modelowanie zachowa+ systemu
Na etapie przygotowywania projektu równie- zosta$a wykorzystana notacja UML. Jednak
w tym wypadku powsta$e modele s! bardziej szczegó$owe od modeli wykonanych w trakcie
analizy wymaga&.
Rodzaje diagramów jakie zosta$y u-yte na tym etapie:
•
Diagramy klas.
Obrazuj! ogóln! struktur" systemu, pokazuj!c klasy i ich wzajemne relacje.
•
Diagramy sekwencji.
Modeluj! najwa-niejsze scenariusze wykonania poszczególnych przypadków u-ycia
systemu.
•
Diagramy komunikacji.
Pokazuj! po$!czenia i interakcje mi"dzy obiektami.
•
Diagramy pakietów,
Przedstawiaj! w ogólnym %wietle organizacj" oprogramowania. Diagramy pakietów
stanowi! dobr! logiczn! map" systemu.
•
Diagram wdro-enia.
Pokazuj! one fizyczn! konfiguracj" oprogramowania i sprz"tu.
Uwagi:
Poni-ej zosta$y przedstawione najwa-niejsze aspekty analizy zachowa& systemu.
Pe$na dokumentacja projektowa w postaci diagramów UML zosta$a umieszczona
w za$!cznikach w formie elektronicznej.
Przyk$adowy diagram klas odpowiadaj!cy przypadkowi u-ycia „Dodaj badanie” wygl!da
nast"puj!co:
30
Rysunek 8.1. Diagram klas dla przypadku u)ycia 'Dodaj badanie'
Lekarz uzupe$nia w przegl!darce internetowej formularz nowego badania (formularz badania
jest reprezentowany przez klas" ekranNowegoBadania). Z rozwijanej listy wybiera pacjenta
(odpowiedzialna jest za to metoda wyswietlListePacjentów() ). Po zatwierdzeniu nowego
badania (metoda dodajBadanie() ) informacje z formularza s! pobierane, sprawdzane
i zapisywane w bazie (ta cz"%# jest realizowana przez klas" noweBadanieCTR). Baza jest
reprezentowana przez klas" badanieDB.
Poni-szy diagram sekwencji szczegó$owo obrazuje kolejno%# przep$ywu komunikatów
w czasie dla przypadku u-ycia „Dodaj badanie”. Formularz wype$niony przez lekarza, po
sprawdzeniu (akcja: sprawdzFormularzNB) przez obiekt kontrolny noweBadanieCTR mo-e
okaza# si" b$"dnie uzupe$niony. Spowoduje to wys$anie informacji zwrotnej do lekarza
z pro%7! o podanie poprawnych danych (akcja: infoPoprawFormularz). Natomiast gdy
system nie b"dzie mia$ zastrze-<& nowe badanie zostanie zapisane w bazie danych (akcja:
dodajBadanie).
31
Rysunek 8.2. Diagram sekwencji dla przypadku u)ycia 'Dodaj badanie'
Na podstawie diagramu sekwencji zosta$ utworzony diagram komunikacji, który informuje
o interakcjach i po$!czeniach poszczególnych obiektów.
32
Rysunek 8.3. Diagram komunikacji dla przypadku u)ycia 'Dodaj badanie'
Zaprojektowany diagram pakietów dla systemu pokazuje powi!zania i logiczne przej%cia
pomi"dzy poszczególnymi ekranami. Pakiety reprezentuj! funkcje okre%lone dla ró-nych
obszarów w systemie. Po zalogowaniu mamy opcje dost"pne w Panelu Opcji, mo-emy np.
wybra# pakiet Ekran Nowego Badania (czyli przej%# do strony oferuj!cej formularz nowego
badania), nast"pnie przechodz!c do pakietu Ekran Badania mo-emy m.in. podgl!dn!#
badanie, obejrze# zdj"cia z badania. Ostatnim punktem tej %cie-ki jest Ekran Konsultacji,
który oferuje komunikacj" z innymi Lekarzami.
Oczywi%cie z ka-dego Ekranu mo-na bezpo%rednio powróci# do Panelu Opcji. Na
diagramie jednak nie zosta$y umieszczone te po$!czenia poniewa- rysunek straci$by wtedy
przejrzysto%#.
33
Rysunek 8.4. Diagram pakietów
W kolejnym etapie modelowania zachowa& systemu zosta$ przygotowany diagram wdro-enia.
34
Rysunek 8.5. Diagram wdro)enia
Przedstawia on w"=$y systemu (stacje robocze, serwery), na których s! wdro-one
poszczególne artefakty, czyli elementy aplikacji InterMed (baza danych, aplikacja
internetowa). Na serwerze (lub serwerach) s! zainstalowane i skonfigurowane: aplikacja oraz
baza danych. Administrator (bazy danych i systemu) przy pomocy stacji roboczej $!czy si"
z g$ównym serwerem s$8-!cym do zarz!dzania wdro-on! infrastruktur!. Lekarz natomiast
komunikuje si" z systemem poprzez komputer osobisty.
Diagramy UML s! bardzo cz"sto stosowane do dokumentowania wykonanego systemu. Ich
podstawow! zalet! jest to, -e pozwalaj! na ogólne zrozumienie oprogramowania bez potrzeby
analizowania kodu.
8.2. Projekt bazy danych
Zaprojektowanie poprawnej struktury danych jest jednym z najwa-niejszych czynników
decyduj!cych o powodzeniu przedsi"wzi"cia. To od niej w du-ej mierze zale-y
implementacja poszczególnych modu$ów systemu. Najpowszechniej stosowan! metod!
modelowania danych jest modelowanie encja - relacja - atrybut, która obejmuje encje,
zwi!zane z nimi atrybuty i relacje mi"dzy tymi encjami [7].
35
Istnieje wiele narz"dzi wspomagaj!cych ten proces. Jednym z nich jest DBDesigner,
rozwijany na licencji Open Source.
DBDesigner jest narz"dziem s$8-!cym do modelowania struktur bazy danych. Potrafi
on integrowa# si" z ró-nymi bazami danych (MySQL, Oracle) i dzi"ki intuicyjnemu
interfejsowi u-ytkownika mo-e by# wykorzystywany nie tylko przez profesjonalistów,
ale równie- przez osoby nie znaj!ce sk$adni j"zyka SQL.
Narz"dzie to zosta$o wykorzystane do zaprojektowania poni-szego diagramu. Dzi"ki niemu
zosta$ wygenerowany skrypt tworz!cy struktur" obiektów bazy danych.
Rysunek 8.6. Projekt bazy danych
Aby umo-liwi# przechowywanie danych w systemie zosta$y przygotowane cztery tabele.
Dwie z nich (lekarz, pacjent) b"2! zawiera$y dane o charakterze statycznym - wpisane raz,
z za$/-enia nie powinny ulega# zmianie (mo-e zdarzy# si" oczywi%cie konieczno%# ich
uaktualnienia, jednak-e system w podstawowej wersji nie b"dzie posiada$ takiej
funkcjonalno%ci). Kolejne dwie tabele: badanie i diagnoza, b"2! bardzo aktywnie u-ywane
przez system. To w$3%nie one zawieraj! wszystkie informacje o badaniu (tabela badanie)
oraz wystawionych diagnozach (tabela diagnoza).
36
W bazie danych nie b"2! przechowywane zdj"cia medyczne, zostan! one umieszczone na
dysku twardym serwera. W bazie znajd! si" jedynie informacje o ich lokalizacji.
Pomi"dzy tabelami zosta$y utworzone relacje wskazuj!ce zale-no%ci mi"dzy danymi:
•
•
•
jeden lekarz mo-e przeprowadzi# wiele bada&
jeden pacjent mo-e by# wielokrotnie badany
dla jednego badania mo-e istnie# wiele diagnoz (wystawionych przez wielu lekarzykonsultantów)
8.3. Projekt interfejsu u)ytkownika
Zadowolenie klienta jest jednym z najwa-niejszych czynników decyduj!cych o powodzeniu
systemu. Nawet najlepszy projekt informatyczny mo-e zako&czy# si" pora->!, je%li jego
8-ytkownicy nie b"2! chcieli z niego korzysta#. Wielu ludzi w zetkni"ciu z komputerem
doznaje takiego szoku, -e zaczynaj! unika# wszelkiego rodzaju systemów informatycznych
[9]. Dlatego ten w$3%nie etap tworzenia aplikacji powinien zosta# szczególnie dok$adnie
omówiony z u-ytkownikami systemu.
Podczas przygotowania projektu interfejsu u-ytkownika szczególny nacisk zosta$ po$/-ony na
prostot" i wygod" obs$ugi. U-ytkownicy bez do%wiadczenia z komputerami mog! nauczy# si"
jego u-ywania w ci!gu krótkiego szkolenia. Strona zosta$a podzielona na kilka sekcji (patrz
poni-ej), z których ka-da ma %ci%le okre%lon! funkcj".
Rysunek 8.7. Projekt interfejsu
37
LOGO
Logo systemu InterMed.
Dane u$ytkownika
Informacje o zalogowanym u-ytkowniku (m.in. imi", nazwisko).
Menu górne % podr"czne
Zawiera linki szybkiego wyboru (strona startowa, informacje o systemie).
Menu boczne
Zawiera linki do poszczególnych funkcji systemu.
Cz" ! dynamiczna
W tej cz"%ci wy%wietlane s! wszystkie informacje, jakich u-ytkownik sobie -yczy$,
korzystaj!c z menu bocznego
Pomoc kontekstowa
Pomoc dla bie-!cej akcji/operacji.
Stopka
Informacja o autorze systemu.
Projekt strony zosta$ wykonany z u-yciem technologii internetowych HTML, CSS,
JavaScript.
Szablon strony zosta$ przygotowany na podstawie szablonu Clean Look 1.5.0. [38]
Uwagi:
Szablon Clean Look 1.5.0 jest udost"pniany na licencji Creative Commons
Licenses 2.0. Je%li system InterMed b"dzie wykorzystywany komercyjnie nale-y
zmieni# szablon strony na inny.
8.4. Iteracyjny proces budowania systemu
Do realizacji systemu InterMed zosta$ wybrany iteracyjny model wytwarzania
oprogramowania. Ca$y projekt zosta$ podzielony na cztery modu$y ró-ni!ce si"
funkcjonalno%ci!: Szkielet Systemu, Modu" DICOM, Modu" Wizualizacja oraz
Komunikacja. Jeden cykl, podczas którego dla jednego modu$u zosta$y sprecyzowane
wymagania, powsta$ projekt i implementacja, a tak-e przeprowadzono testy stanowi$ iteracj!.
Pierwsz! czynno%ci! by$o zebranie wymaga& stawianych systemowi, po czym zosta$y one
poddane szczegó$owej analizie. Nast"pnie w pe$nym cyklu projektowania, kodowania
38
i testowania zosta$ przygotowany szkielet systemu, który poza tym, -e oferuje w$asne funkcje,
pozwala równie- na integracj" pozosta$ych modu$ów. W kolejnych iteracjach zosta$y
wykonane pozosta$e cz"%ci systemu, dodaj!c tym samym nowe mo-liwo%ci do juistniej!cego szkieletu. Warto zauwa-;#, -e po ka-dej sko&czonej iteracji aplikacja dzia$3$a
poprawnie i mo-e zosta# wst"pnie przekazana u-ytkownikowi do oceny.
Schemat zastosowanego procesu iteracyjnego przedstawiono poni-ej:
Rysunek 8.8. Iteracyjny proces budowania systemu
Podej%cie iteracyjne (inaczej przyrostowe) wymusza na projektancie/programi%cie gruntowne
przemy%lenie architektury oprogramowania. Powinna by# ona elastyczna i dawa# mo-liwo%#
do$!czania kolejnych funkcjonalno%ci. Poza tym, technika ta pozwala na wczesne wykrycie
zagro-<& (min. przekroczenie terminów i bud-etu, 'le zaprojektowane interfejsy modu$ów)
oraz uzyskanie lepszej kontroli nad budow! systemu.
W ka-dej iteracji w miar" mo-liwo%ci by$y przeprowadzane testy poprawno%ci dzia$ania
systemu. W tym wypadku zosta$ zastosowany model V wytwarzania oprogramowania, który
jest nakierowany na ci!4$! weryfikacj" i walidacj" wykonanych czynno%ci. System InterMed
jest z$/-ony z modu$ów, w sk$ad których wchodz! procedury i funkcje. Testowanie powinno
si" zatem odbywa# w wielu krokach, wraz z przyrastaj!cym kodem.
39
Rysunek 8.9. Proces V budowania i testowania poszczególnych modu'ów
Zalet! zastosowania procesu V jest to, -e $atwiej jest zlokalizowa# miejsce b$"du w kodzie lub
projekcie.
8.5. Opis poszczególnych modu'ów systemu
System InterMed zosta$ rozdzielony na kilka modu$ów, z których ka-dy realizuje %ci%le
okre%lone funkcje. Takie rozwi!zanie w znaczny sposób u$atwia jego instalacj" i dalsz!
rozbudow". W przypadku awarii jednego z modu$ów DICOM, Wizualizacja lub Komunikacja
system jest w stanie dalej spe$nia# swoje podstawowe funkcje. Zapewnia to Szkieletu
systemu, który jest niezb"dny do funkcjonowania aplikacji.
Rysunek 8.10. Dekompozycja systemu
40
Modu$owa budowa systemu i uzyskana w ten sposób du-a niezale-no%# poszczególnych
modu$ów jest równie- korzystna z punktu widzenia u-ytkownika, który mo-e sam
zdecydowa# z jakich funkcji systemu b"dzie korzysta$, a jakie mog! zosta# wy$!czone.
8.5.1. Szkielet systemu
8.5.1.1. Projekt techniczny
8.5.1.1.1. Modu' nawigacji
Poruszanie po witrynie u$atwia przygotowany system nawigacji, który narzuca struktur"
hierarchiczn! dla ca$ej witryny. Wraz z naci%ni"ciem danego linku przesy$any jest do niego
wcze%niej zdefiniowany skrót kategorii. Nast"pnie w cz"%ci dynamicznej witryny otwierana
jest -!dana strona.
Drzewo witryny:
+---|
+---|
+---|
+---|
+---|
+----
"home"
-> home.jsp
"new"
-> new.jsp
"badanie"
-> badanie.jsp
"lista"
-> lista.jsp
"search"
-> search.jsp
"konsultacje"
-> konsultacje.jsp
8.5.1.1.2. Logowanie do systemu i zarz dzanie sesj
Logowanie do systemu oraz mechanizm zarz dzania sesj
z zastosowaniem technologii JavaBeans („ziarenek Javy”).
zosta! zaimplementowany
W momencie próby zalogowania do systemu tworzone jest ziarenko Javy logbean, po czym
uruchamiana jest funkcja authenticate(), która jako parametry przyjmuje nazw"
#$ytkownika oraz has!o.
Je%li funkcja zwróci warto%& logiczn TRUE, wówczas pobierane s pozosta!e dane
#$ytkownika (patrz: lista ni$ej) oraz system przechodzi do spersonalizowanej witryny danego
lekarza. W przeciwnym wypadku system wy%wietla komunikat o braku uprawnie' do
systemu.
41
Lista w!(%ciwo%ci ziarenka logbean oraz odpowiadaj ce im w!(%ciwo%ci:
username
nazwisko
setUsername()
setNazwisko()
getUsername()
getNazwisko()
password
instytucja
setPassword()
setInstytucja
getPassword()
getInstytucja
imie
setImie()
getImie()
W trakcie wylogowywania z systemu ziarenko jest kasowane z pami"ci – usuwana jest sesja.
8.5.1.1.3. System pomocy
System pomocy umo$liwia wy%wietlanie pomocy kontekstowej w trakcie pracy z systemem
(dost"pny m.in. dla procesu: logowania, dodawania nowego badania).
Implementacja: funkcje JavaScript (help_window.js).
8.5.1.1.4. Kodowanie znaków
W projekcie jako system kodowania znaków wykorzystywany jest UTF-8.
<%@ page contentType="text/html;charset=UTF-8" %>
Aby rozwi za& problem przesy!ania polskich znaków za pomoc akcji GET lub POST, np.
g ówna ->(POST)-> g%C5%82%C3%B3wna
zosta!a zaimplementowana klasa narz"dziowa ogonki (plik ogonki.jsp)
8.5.1.1.5. Zarz dzanie po! czeniem z baz danych - pula po! cze"
Aby zoptymalizowa& wydajno%& zapyta' wysy!anych do bazy danych i nie otwiera&
po! czenia przy ka$dym zapytaniu zosta! zaimplementowany mechanizm puli po! cze".
Dzi"ki temu rozwi zaniu, pozwalaj cemu na korzystanie z otwartych uprzednio po! cze',
znacznie zmniejsza si" czas potrzebny na dost"p do bazy i mo$na równocze%nie obs!ugiwa&
kilka zapyta'.
42
Aby korzysta& z puli po! cze', zosta!y zdefiniowane dwie klasy: jedna z nich reprezentuje
po! czenie wchodz ce w sk!ad puli, a druga - sam pul".
1. Po! czenie wchodz ce w sk!ad puli.
Klasa PoolConnection zawiera obiekt klasy Connection oraz znacznik wskazuj cy,
czy dane po! czenie jest wykorzystywane.
2. Pula po! cze'.
Aby mo$na by!o korzysta& ze zdefiniowanych po! cze' wchodz cych w sk!ad puli
konieczny jest równie$ obiekt realizuj cy sam pul", który b"dzie zarz dza!
po! czeniami.
Wymagania jakie realizuje ten obiekt:
•
Przechowuje n otwartych po! cze'.
•
Monituje, które z po! cze' s wykorzystywane.
•
Je%li otwierane jest n+1 po! czenie, otwiera je i dodaje do puli.
•
Przy zamykaniu puli wszystkie po! czenia zostaj zamkni"te.
Uwagi:
Pula po! cze' zosta!a opracowana na podstawie: "Java Server Pages Podr"cznik z przyk!adami" [10]
8.5.1.2. Opis funkcjonalno#ci
8.5.1.2.1. Logowanie do systemu
Po wpisaniu odpowiedniego adresu w przegl darce WWW u$ytkownik widzi stron"
logowania. Aby uzyska& dost"p do systemu trzeba si" zalogowa&. Nale$y poda& przy tym
nazw" u$ytkownika oraz has!o.
43
Rysunek 8.11. Okienko logowania
8.5.1.2.2. Strona g!ówna systemu
Po pomy%lnym zalogowaniu u$ytkownika wita strona g!ówna, która umo$liwia mu dodanie
nowego badania, przegl danie istniej cej listy bada', a tak$e wyszukiwanie interesuj cych go
bada'. W prawym górny rogu ekranu znajduj si" informacje o aktualnie zalogowanym
#$ytkowniku (imi", nazwisko, jednostka).
Rysunek 8.12. Strona g!ówna (powitalna)
44
8.5.1.2.3. Formularz nowego badania
Za!)$my, $e u$ytkownik (lekarz) wybierze opcj" 'Nowe badanie'. Na ekranie pojawi si"
wtedy pusty formularz, w którym mo$na uzupe!ni& nast"puj ce informacje:
•
•
•
•
dat" badania
kod badania
pacjent (wskazanie z listy)
diagnoza
Rysunek 8.13. Nowe badanie
Lekarz mo$e skorzysta& z pomocy systemu klikaj c ikonk"
pomocy opisuj ce poszczególne pola formularza.
. Wyskakuje wówczas okno
45
Rysunek 8.14. Nowe badanie - pomoc
8.5.1.2.4. Podgl d badania
Po dodaniu badana system automatycznie przenosi lekarza na stron" 'Podgl!d badania'.
Znajduj si" tutaj wszystkie informacje o badaniu, które zosta!y wpisane w formularzu
nowego badania.
Na dole ekranu znajduje si" formularz umo$liwiaj
zarówno w formacie DICOM, jak równie$ zdj"cia
wskaza& odpowiednie pliki znajduj ce si" na dysku
i nacisn & przycisk 'Za aduj'. Po za!adowaniu
nast"puj ce operacje:
•
cy dodanie zdj"& z badania zapisanych
obj"to%ciowe. W tym celu lekarz musi
twardym komputera, z którego korzysta
zdj"& medycznych system umo$liwia
przegl danie
Przegl danie zdj"& odbywa si" dzi"ki wbudowanym w system przegl darkom DICOM
i Wizualizacja.
•
pobranie na dysk
*$ytkownik pobieraj c obrazy medyczne na swój komputer b"dzie móg! je przegl da&
bez ! czenia si" z systemem InterMed. Wymaga to instalacji dodatkowego
oprogramowania.
•
usuni"cie
Po usuni"ciu zdj"& medycznych wy%wietlany jest ponownie formularz dodawania
plików.
46
Rysunek 8.15. Wykonane badanie
Na stronie wy%wietlane s równie$ konsultacje dla badania - oczywi%cie pod warunkiem ich
uprzedniego przeprowadzenia. Znajduje si" tutaj równie$ przycisk
wysy!anie pro%by o konsultacje do innego lekarza.
pozwalaj cy na
W prawym górnym rogu ekranu zosta!y umieszczone przyciski umo$liwiaj ce edycj"
badania, usuni"cie badania oraz poinformowanie pacjenta o wynikach. Edytuj c badanie,
lekarz ma mo$liwo%& jedynie zmiany diagnozy - pozosta!e pola maj zablokowan mo$liwo%&
edycji. Usuni"cie badania natomiast wymaga dodatkowego potwierdzenia, które pozwoli
ustrzec u$ytkownika przed przypadkowym skasowaniem wa$nych danych (patrz rysunek
poni$ej).
47
Rysunek 8.16. Potwierdzenie usuni$cia badania
Wszystkie opcje i ich znaczenie zosta!y opisane w pomocy.
Rysunek 8.17. Wykonane badanie - pomoc
8.5.1.2.5. Widok listy bada"
Strona g!ówna, jak ju$ wcze%niej wspomniano, oferuje podgl d listy istniej cych bada'. Po
wybraniu tej opcji, na ekranie pojawi si" lista wszystkich bada' nale$ cych do zalogowanego
lekarza, z których ka$de mo$e by& przegl dane szczegó!owo, wyedytowane oraz usuni"te.
Dost"pna jest tak$e pomoc informuj ca o mo$liwych operacjach na wykonanym badaniu.
48
Rysunek 8.18. Widok listy bada"
8.5.1.2.6. Wyszukiwanie bada"
Je$eli lekarz wybra! opcj" 'Wyszukaj badanie', to pojawi si" na ekranie formularz
pozwalaj cy na szczegó!owe przeszukiwanie kartoteki bada'. Dost"pnymi kryteriami
wyszukiwania s : data, kod badania, dane pacjenta (imi", nazwisko, adres) oraz diagnoza.
Zaprojektowany podsystem wyszukiwania umo$liwia wpisywanie niepe!nej informacji,
a w przypadku gdy nie uzupe!niono jednego z pól, wówczas nie b"dzie ono uwzgl"dniane
w trakcie wyszukiwania.
49
Rysunek 8.19. Wyszukiwanie bada"
50
8.5.1.2.7. Informacja o systemie
Wybieraj c przycisk 'O systemie' u$ytkownik uzyskuje informacj" na temat systemu.
Rysunek 8.20. Informacja o systemie
8.5.2. Modu! DICOM
Modu! DICOM udost"pnia przegl dark" zdj"& zapisanych w formacie DICOM, które zosta!y
dodane przez lekarza podczas wpisywania nowego badania.
Modu! DICOM zosta! opracowany na podstawie projektu Open Source rozwijanego przez
Nagoya Institute of Technology, Iwata laboratory and Takahiro Katoji [39].
Do jego implementacji zosta!a wykorzystana technologia Java Applet [40], s!#$ ca przede
wszystkim do tworzenia aplikacji uruchamianych w oknie przegl darki.
Integracja modu!u DICOM ze Szkieletem Systemu InterMed zosta!a przeprowadzona
z wykorzystaniem znacznika <APPLET> dost"pnego w specyfikacji HTML. Dzi"ki
dodatkowym parametrom konfiguracyjnym tego znacznika, mo$na okre%li& sposób
wy%wietlania przegl darki DICOM i wybra& jakie dane zostan za!adowane.
51
Przyk!adowa konfiguracja zosta!a przedstawiona poni$ej:
<APPLET
CODE
NAME
WIDTH
HEIGHT
HSPACE
VSPACE
ALIGN
>
<PARAM
</APPLET>
=
=
=
=
=
=
=
"dicomviewer.Viewer.class"
"Viewer.java"
100%
100%
0
0
middle
NAME = "imgURL0" VALUE = "FX01556\badanieCT.dcm">
Po lewej stronie przegl darki znajduje si" panel opcji, który umo$liwia modyfikacj" zdj"&.
W oknie przegl darki mo$na przegl da& jedno zdj"cie, jak i seri" zdj"&. Jest te$ tutaj dost"pny
tryb filmu, dzi"ki któremu zdj"cia mog by& ogl dane klatka po klatce, co u!atwi analiz"
zachodz cych zmian.
Rysunek 8.21. Modu! DICOM
52
Pomocna równie$ mo$e okaza& si" opcja ZOOM, która powi"ksza wybrane fragmenty obrazu.
Rysunek 8.22. Modu! DICOM - opcja 'ZOOM'
Przegl darka dostarcza tak$e zestaw podstawowych filtrów do transformacji obrazu. Mo$emy
do nich zaliczy& kontrast, regulacj" jasno%ci oraz negatyw. Przyk!ady dzia!ania tych filtrów
zosta!y przedstawione poni$ej.
Rysunek 8.23. Modu! DICOM – filtry(1)
53
Rysunek 8.24. Modu! DICOM – filtry(2)
Zastosowanie filtrów dla obrazów medycznych mo$e znacznie wspomóc proces
diagnozowania. Z jednej strony s!#$ one do usuni"cia zb"dnych szczegó!ów, a z drugiej
strony pomagaj wzmocni& pewne elementy obrazu, które co prawda istniej , ale s s!abo
widoczne [15].
8.5.3. Modu! Wizualizacja
Modu! wizualizacja umo$liwia sk!adowanie i przegl danie zdj"& obj"to%ciowych.
Do opracowania modu!u Wizualizacja zosta! u$yty projekt JIV: A 3D Image Data
Visualization and Comparison Tool [41] dost"pny jako Open Source.
Modu! Wizualizacja, podobnie jak Modu! DICOM, zosta! wykonany w technologii Java
Applet [40]. Pozwala to na uruchamianie go bezpo%rednio w oknie przegl darki internetowej,
bez potrzeby instalacji dodatkowego oprogramowania.
Integracja tego modu!u z systemem InterMed odbywa si" poprzez odpowiednio
skonfigurowany znacznik <APPLET> w kodzie strony html. Przyk!adow konfiguracj"
przedstawiono poni$ej:
<APPLET
ARCHIVE
CODE
NAME
WIDTH
HEIGHT
>
<PARAM
</APPLET>
=
=
=
=
=
"jiv.jar"
"jiv/Main.class"
"jiv_demo_3"
400
50
NAME="config" value="configFile">
54
Za pomoc
parametrów tego znacznika mo$na nie tylko ustali& sposób wy%wietlania
przegl!darki Wizualizacja, ale równie$ wskaza& plik konfiguracyjny opisuj cy format
danych wej%ciowych.
Poni$ej
zosta!a
przedstawiona
zawarto%&
przyk!adowego
pliku
konfiguracyjnego
configFile:
jiv.panel.0
: colin27
colin27
: colin27.raw_byte.gz
colin27.header : colin27.header
Zdefiniowane w nim parametry wskazuj
plik z danymi wej%ciowymi
(colin27.raw_byte.gz) oraz plik nag!ówkowy opisuj cy te dane (colin27.header).
8.5.3.1.1. Uwagi do formatu plików dla zdj$% obj$to#ciowych
Modu! Wizualizacja otwiera i wy%wietla dane zapisane w postaci binarnej, do których
wymagany jest plik nag!ówkowy opisuj cy jego struktur" (m.in. d!ugo%&, szeroko%&, krok).
W odró$nieniu od formatu DICOM nie jest to format ustandaryzowany, tylko zaproponowany
przez Montréal Neurological Institute, McGill University [42]. Czynnik ten ogranicza
w du$ym stopniu system InterMed, czyni c z niego rozwi zanie o charakterze badawczym.
Przyk!adowy plik nag!ówkowy (colin27.header):
size
start
step
order
:
:
:
:
181
-90
1 1
z y
217 181
-126 -72
1
x
55
Przegl darka zdj"& obj"to%ciowych wy%wietla zdj"cia, dodane przez lekarza, w trzech
+!aszczyznach: X,Y,Z. U$ytkownik poruszaj c si" po jednej z tych p!aszczyzn, obserwuje
zmieniaj cy si" obraz na pozosta!ych dwóch.
Rysunek 8.25. Modu! Wizualizacja: okno g!ówne
56
Na zdj"ciach mo$na zastosowa& ró$ne filtry graficzne, co zosta!o przedstawione na
poni$szych rysunkach:
Zmiana koloru i nasycenia
Segmentacja obrazu
Tabela 8.1. Filtry graficzne
8.5.4. Modu! Komunikacja
Modu! Komunikacja zosta! wykonany w tej samej technologii co Szkielet Systemu i w du$ym
stopniu bazuje na nim. Korzysta on z tych samych tabel (Lekarz, Badanie, Pacjent,
Diagnoza), gdzie zapisywane s wyniki kolejnych konsultacji.
Wysy!anie wyników do pacjenta poprzez wiadomo%& email, zosta!o wykonane za pomoc
znacznika html <a>: mailto.
Przyk!ad 8.1. Sk!adnia znacznika mailto
mailto:[email protected]?subject=temat&body=tresc
Adresat, temat wiadomo%ci (subject) oraz tekst wiadomo%ci (body) zostaj automatycznie
uzupe!nione przez system.
57
Przyk!ad 8.2. Przyk!ad u&ycia znacznika mailto
mailto:[email protected]?subject=Wyniki%20bada%C5%84&body=tekst,%20tekst,%2
0tekst,%20tekst
8.5.4.2.1. Konsultacje z innymi lekarzami
Ka$de badanie zapisane w systemie InterMed mo$e zosta& skonsultowane z innymi
lekarzami. Lekarz przeprowadzaj cy badanie, po wpisaniu w!asnej diagnozy mo$e poprosi&
innego lekarza o opini". Uzupe!nia w tym celu dodatkowy formularz, w którym wybiera
lekarza z listy oraz wpisuje krótk informacj" do adresata wiadomo%ci.
Lekarz, który zosta! poproszony o konsultacj", po zalogowaniu do systemu InterMed jest
powiadamiany o tym fakcie w postaci informacji w prawym górnym rogu ekranu. Klikaj c
w link mo$e przeczyta&, kto jest nadawc oraz zapozna& si" z tre%ci wiadomo%ci. Na tej
stronie znajduje si" formularz odpowiedzi, gdzie lekarz mo$e wpisa& w!asn diagnoz", jak
równie$ przycisk umo$liwiaj cy obejrzenie badania.
Rysunek 8.26. Ekran konsultacji
58
8.5.4.2.2. Informacja dla pacjenta
Wyniki ka$dego badania mog zosta& wys!ane do pacjenta. Nale$y w tym celu klikn & ikon"
znajduj , si" w oknie badania, co spowoduje utworzenie nowej wiadomo%ci email
w domy%lnym kliencie pocztowym u$ytkownika. Automatycznie zostanie wpisany adresat
wiadomo%ci (adres email pacjenta) oraz uzupe!niona tre%& wiadomo%ci. Lekarz oczywi%cie
mo$e edytowa& te informacje lub dopisa& dodatkowy komentarz, np. propozycj" kolejnej
wizyty.
Zaleca si" aby przes!anie tej wiadomo%ci zosta!o równie$ potwierdzone drog telefoniczn .
8.6. Opis instalacji i konfiguracji projektu.
System InterMed zosta! wykonany przy u$yciu ogólno dost"pnych (Open Source) narz"dzi
i technologii, dzi"ki czemu koszty wdro$enia systemu b"- znacznie ni$sze.
8.6.1. Przygotowanie infrastruktury sprz$towej
Wymagania sprz"towe systemu InterMed, w przewa$aj cym stopniu, zale$ od liczby
#$ytkowników systemu. Jest to g!ówny wska.nik, który powinien by& brany pod uwag"
w trakcie wdro$enia. Istotnym czynnikiem jest tak$e sposób instalacji - mo$liwe warianty
zosta!y przedstawione w rozdziale 'Perspektywy zastosowania i rozwoju systemu'.
8.6.2. Przygotowanie niezb$dnego oprogramowania
Wszystkie dane w systemie InterMed s sk!adowane w bazie danych MySQL, a ca!/%&
obs!uguje serwer aplikacji Tomcat.
MySQL [43] jest jedn z najpopularniejszych baz danych dost"pnych na licencji Open
Source. Dzi"ki swojej wydajno%ci, szybko%ci dzia!ania i rozbudowanym
mechanizmom zabezpiecze' jest wykorzystywana w bardzo wielu zastosowaniach.
Szczególn popularno%& zdoby! w projektach opartych o sie& Internet.
Apache Tomcat [44] jest serwerem aplikacji rozwijanym w ramach Apache Software
Fundation. Umo$liwia uruchamianie aplikacji internetowych w technologiach Java
Servlets i JSP (Java Server Pages).
Sposób instalacji i konfiguracji powy$szych narz"dzi jest dost"pny na stronach domowych
tych projektów.
59
8.6.3. Instalacja systemu InterMed
8.6.3.1. Konfiguracja bazy danych
8.6.3.1.1. Konto dla administratora bazy danych systemu InterMed
Powinno istnie& konto u$ytkownika-administartora, który b"dzie mia! dost"p do serwera bazy
danych.
8.6.3.1.2. Tworzenie struktury tabel
W bazie danych tworzona jest struktura tabel, w których b"- przechowywane dane. Skrypt
tworz cy znajduje si" w za! czniku.
8.6.3.2. Konfiguracja serwera aplikacji
8.6.3.2.1. Utworzenie katalogu aplikacji
Trzeba za!/$0& nowy katalog dla systemu InterMed w katalogu aplikacji serwera Tomcat
(\Tomcat 5.5\webapps\).
8.6.3.2.2. Ustawienie parametrów po! czenia z baz danych
Nale$y
ustawi&
parametry
po! czenia
z
baza
danych
w
pliku
\Tomcat
5.5\webapps\InterMed\WEB-INF\classes\foo\Connection.properties.
Przyk!adowa konfiguracja zosta!a przedstawiona poni$ej:
HostName
SID
Port
UserName
Password
=
=
=
=
=
localhost
rpetryniak
3306
user
user
8.6.4. Utrzymanie systemu
Zaleca si" zatrudnienie administratora systemu, który po uprzednim przeszkoleniu b"dzie dba!
o poprawno%& pracy systemu. Do jego obowi zków nale$(!oby równie$ zak!adanie kont
nowym u$ytkownikow (lekarzom) oraz dodawanie pacjentów do kartoteki. Czynno%ci te
wykonywa!by przy pomocy specjalnie przygotowanych skryptów SQL.
60
Rozdzia! 9. Próba wizualizacji przestrzennej obrazu
Tematem tej pracy magisterskiej jest system informacyjny wspomagaj cy lekarza
w diagnozowaniu na podstawie obrazów medycznych. Pocz tkowo, nieodzowne wydawa!o
si" zrealizowanie podsystemu wizualizacji trójwymiarowej, który dla serii p!askich obrazów
medycznych tworzy!by obraz przestrzenny. Ca!y ten proces odbywa!by si" w sieci Internet.
9.1. Wybór internetowej technologii wizualizacji przestrzennej.
Zadaniem techniki wizualizacji przestrzennej (3D) jest takie przedstawienie obrazu na
+!askim ekranie monitora, aby sprawia! wra$enie trójwymiarowo%ci. Istnieje bardzo wiele
algorytmów oraz narz"dzi informatycznych, które pozwalaj osi gn & ten efekt. Niektóre
z nich przystosowane s tak$e do pracy w sieci Internet. Ju$ teraz znajduj one zastosowanie
m.in. w turystyce (interaktywne wycieczki), budownictwie (plany domów), biznesie (reklama,
marketing) i oczywi%cie rozrywce (gry).
9.1.1. Przegl d i krótka charakterystyka narz$dzi wizualizacji w Internecie.
Istnieje wiele technologii wizualizacji przestrzennej, ale tylko niektóre z nich s
przystosowane do uruchamiania w aplikacjach internetowych. Wybrane technologie oferuj ce
tak mo$liwo%& zosta!y opisane poni$ej.
Flash
Jest wykorzystywany g!ównie do animacji obiektów p!askich zapisanych w postaci
wektorowej. Dzi"ki bardzo !atwej integracji z j"zykiem HTML, sta! si" nieodzownym
elementem multimedialnych witryn WWW.
http://www.adobe.com/products/flash/
Java3D
Jest to rozszerzenie j"zyka Java, które pozwala na generowanie obiektów
trójwymiarowych. Bazuje na bibliotece OpenGL. Do uruchomienia wymaga
zainstalowanego %rodowiska Java.
http://java.sun.com/products/java-media/3D/
VRML/X3D
VRML (z ang. Virtual Reality Modeling Language) to j"zyk modelowania wirtualnej
rzeczywisto%ci trójwymiarowej [11].
Jego nast"pca X3D zosta! poddany standaryzacji przez konsorcjum ISO (International
Organization for Standardization).
http://www.web3d.org/
61
Technologi , jaka zosta!a wybrana do wizualizacji by! X3D. Ten niezalezny od platformy
format, dzi"ki ustandaryzowaniu przez organizacj" ISO daje pewno%&, $e oprogramowanie,
które zostanie stworzone nie b"dzie zale$ne od przyj"tych za!/$1'. Równie$ fakt zapisu
plików w formacie XML jest wielkim atutem, gdy$ mog one by& odczytywane przez wiele
programów i poddawane dodatkowej analizie.
9.2. Przygotowanie danych
Aby móc generowa& obiekt trójwymiarowy z p!askich przekrojów (np. ze zdj"& .jpg), nale$(!o
odpowiednio przygotowa& dane.
9.2.1. Wyznaczanie konturów
Pierwszym krokiem by!o wyodr"bnienie konturu.
Przeanalizowano grup" narz"dzi (bibliotek, programów), które daj mo$liwo%& wyznaczenia
konturów na analizowanym obrazie. Wi"kszo%& z nich jest ogólnie dost"pna (licencja Open
Source), jednak$e na przyk!adzie programu Corel PHOTO-PAINT zosta!a sprawdzona
funkcjonalno%& komercyjnych rozwi za'.
Analizowane narz$dzia:
ImageJ
http://rsb.info.nih.gov/ij/
JH Labs
http://www.jhlabs.com/
JIMI
http://java.sun.com/products/jimi/
Corel PHOTO-PAINT
http://www.corel.com/
Uwagi:
Analiza porównawcza mo liwo!ci powy szych narz"dzi w zakresie wykrywania
kraw"dzi zosta#a przedstawiona w za#$czniku w formie elektronicznej.
Proces wyodr"bnienia konturu z obrazu polega# na zastosowaniu kilku nast"puj$cych po sobie
filtrów graficznych. Ich w#%!ciwy wybór oraz kolejno!& stosowania pozwoli#y uzyska&
oczekiwany rezultat.
62
ImageJ
rys 0. Obraz wej!ciowy
rys 1. Negatyw
rys 2. Filtr: Binaryzacja (Threshold)
63
ImageJ
rys 3. Filtr: Szukanie kraw"dzi (Find
Edges)
rys 4. Negatyw
Tabela 9.1. Zdj cia z badania rezonansem magnetycznym
Uwagi:
W przypadku zdj"& s#abej jako!ci wyznaczenie konturów nie zawsze jest mo liwe.
Dlatego nale y do#' (& wszelkich stara), aby rejestrowanie obrazów odbywa#o si" z jak
najwi"ksz$ staranno!ci$.
9.2.2. Wyznaczanie wspó!rz dnych
Kolejnym krokiem by#o wyznaczenie wspó#rz"dnych konturu. Poniewa zazwyczaj ka da
seria obrazów ma inne wymiary (d#ugo!&, szeroko!&) dlatego konieczne by#o odpowiednie
przeskalowanie tych obrazów.
Poni ej zosta#a przedstawiona implementacja algorytmu wyznaczaj$cego po#' enie punktów
konturu i skaluj$cego obraz:
//zbiór punktów
Set spoint = new HashSet();
int xx,yy;
int width = bimage.getWidth( null );
int height = bimage.getHeight( null );
64
for( int x=0; x < width; x++ ) {
for( int y=0; y < height; y++ ) {
int pixel = bimage.getRGB(x, y);
//wyznaczenie sk adowych piksela
int apixel = 0xff & (pixel>>24);
int rpixel = 0xff & (pixel>>16);
int gpixel = 0xff & (pixel>>8);
int bpixel = 0xff & (pixel);
//okre!lenie, czy piksel nale"y do konturu
if ( (apixel > 200) && (rpixel<100)
(bpixel<100)) {
&&
(gpixel<100)
&&
//skalowanie (max: 100)
xx = (100 * x)/width;
yy = (100 * y)/height;
//zapis do zbioru punktów
spoint.add( new Point(xx,yy) );
}
}
}
Powy szy algorytm dla zadanego obrazu wej!ciowego generuje zbiór punktów, który
zapisywany jest do pliku.
Przyk!adowy wygenerowany zbiór wspó!rz dnych:
(48, 49), (62, 46), (53, 52), (59, 58), (54, 37), (62, 51), (55, 53), (52, 52), (60, 39), (61,
57), (60, 42), (60, 44), (49, 38), (52, 34), (63, 39), (47, 47), (62, 45), (50, 35), (58, 34),
(60, 41), (55, 37), (55, 34), (62, 44), (61, 36), (52, 55), (53, 33), (62, 41), (62, 50), (60,
48), (55, 58), (54, 33), (57, 59), (61, 56), (60, 35), (59, 39), (61, 55), (60, 49), (50, 38),
(60, 50), (60, 47), (48, 44), (56, 37), (53, 53), (62, 43), (60, 51), (59, 53), (46, 45), (52,
37), (63, 41), (47, 45), (60, 45), (48, 48), (54, 53), (49, 40), (56, 58), (53, 37), (46, 44),
(59, 52), (46, 38), (48, 43), (60, 52), (52, 54), (46, 43), (52, 53), (47, 46), (53, 34), (62,
38), (51, 51), (55, 54), (57, 37), (48, 40), (59, 59), (48, 45), (57, 34), (62, 52), (50, 50),
(49, 35), (60, 43), (49, 50), (48, 41), (54, 57), (56, 59), (60, 46), (58, 38), (63, 38), (62,
49), (46, 40), (59, 35), (62, 54), (50, 52), (49, 39), (48, 42), (62, 47), (47, 36), (53, 57),
(62, 36), (50, 34), (56, 53), (57, 38), (62, 37), (46, 42), (48, 35), (59, 54), (60, 57), (50,
51), (63, 40), (62, 55), (60, 58), (53, 55), (56, 34), (58, 54), (58, 59), (56, 54), (62, 42),
(46, 41), (53, 56), (60, 40), (51, 53), (49, 47), (49, 49), (49, 48), (46, 39), (50, 37), (57,
54), (60, 36), (50, 49), (59, 38), (51, 34), (51, 52), (54, 34), (55, 57), (46, 36), (62, 53),
(62, 48), (48, 46), (46, 37), (51, 37), (49, 46), (58, 35), (50, 39), (48, 47), (60, 59), (48,
36), ...
Mo na zauwa (&, e otrzymali!my bardzo du o danych dla jednego przekroju.
Przechowywanie ich wszystkich wydaje si" jednak konieczne, aby nie straci& dok#adno!ci
analizowanego obrazu podczas generowania wizualizacji.
65
9.3. Wizualizacja VRML / X3D
Maj$c ju przygotowany zbiór punktów reprezentuj$cych kontury dla poszczególnych zdj"&
przekrojowych, zostanie podj"ta próba ich wizualizacji w technologii VRML / X3D.
9.3.1. Technologia VRML / X3D
Technologia VRML / X3D umo liwia g#ównie modelowanie kszta#tów regularnych, które
mo na opisa& za pomoc$ wzorów. Posiada ona równie mechanizmy wizualizacji obiektów
o nieregularnym kszta#cie (sposób zapisu oraz uzyskane obrazy podano poni ej).
Przyk!ad 9.1. X3D: znacznik PointSet
<PointSet>
<Coordinate point="0.2138 0.2339 0.09065, 0.1078 0.2532 0.1026, ... "/>
<Color color=" "/>
</PointSet>
Przyk!ad 9.2. X3D: znacznik IndexedFaceSet
<IndexedFaceSet coordIndex=" 0 1 2 -1 3 4 1 -1 ... ">
<Coordinate point="0.2138 0.2339 0.09065, 0.1078 0.2532 0.1026, ... "/>
</IndexedFaceSet>
66
Przyk!ad 9.3. X3D: znacznik ElevationGrid
<ElevationGrid
height="0.0233242 0.0461275 0.0679003 ... "
solid="false"
xDimension="21" xSpacing="0.2" zDimension="21" zSpacing="0.15">
<Color color="1 0 0 1 0 0 1 0 0 1 ... "/>
</ElevationGrid>
9.3.2. Wizualizacja punktowa
Dla zastosowanych danych, które sk#ada#y si" z 80 obrazów przekrojowych otrzymano blisko
25 ty!. punktów. Aby utworzy& wizualizacj" dyskretn$ (punktow$) skorzystano ze znacznika
<PointSet>.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE
X3D
PUBLIC
"ISO//Web3D//DTD
"http://www.web3d.org/specifications/x3d-3.1.dtd">
X3D
3.1//EN"
<X3D
version="3.1" profile="Immersive"
xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d3.1.xsd" >
<Scene>
<Viewpoint
description="Front
View"
orientation="0
1
0
3.14"
position="0.5 0.5 -2"/>
<NavigationInfo type='"EXAMINE" "WALK" "FLY" "ANY"'/>
<Shape>
<Appearance>
<Material/>
</Appearance>
<PointSet>
<Coordinate point="0.1 0.89 0.01, 0.09 0.48 0.01, 0.08 0.45
0.01, 0.05 0.54 0.01, 0.21 0.56, "/>
<Color color="1 1 1 "/>
</PointSet>
</Shape>
</Scene>
</X3D>
67
Problemem okaza#o si" odtworzenie tych wizualizacji za pomoc$ dost"pnych przegl$darek
VRML/X3D.
Uwagi:
Opis i porównanie przegl$darek VRML/X3D zamieszczono w za#$czniku
w formie elektronicznej.
Tylko jedna z nich (Flux Player [57]) potrafi#a poradzi& sobie w miar" p#ynnie, kolejna
(Octaga Player [56]) potrzebowa#a sporo czasu aby za#adowa& dane, inne przegl$darki
(Cortona Player [55]) nie uruchamia#y si" dla tego przyk#adu.
Rysunek 9.1. Wizualizacja punktowa obrazów przekrojowych wygenerowana
w technologii X3D
9.3.3. Wizualizacja p!aszczyzny - napotkane problemy
Kolejnym etapem by#a wizualizacja powierzchni. Problemem, jaki pojawi# si" podczas próby
zastosowania wybranej technologii (X3D), by#a konieczno!& podania wszystkich wielok$tów
wype#niaj$cych t" powierzchni".
Aby zrealizowa& ten cel, nale %#oby wykona& nast"puj$ce czynno!ci:
•
•
•
•
wykazanie, które punkty nale $ do konturu
okre!lenie ilo!ci wyst"puj$cych p#aszczyzn (ich obszarów, przeci"&)
po#$czenie odpowiednich punktów z jednej p#aszczyzny z punktami p#aszczyzny
*$siaduj$cej
zastosowanie algorytmów morfingu
Po dok#adnej analizie tych zada) okaza#o si", e ich z#' ono!& wykracza poza zakres tej pracy
magisterskiej. Dlatego do opracowania modu u Wizualizacja wykorzystano gotowe
komponenty informatyczne, które oferowa#y oczekiwan$ funkcjonalno!&.
68
Rozdzia! 10. Perspektywy zastosowania i rozwoju systemu
Okazuje si", e istnieje kilka sposobów wdro enia systemu: mo e on funkcjonowa& zarówno
jako us#uga zewn"trzna udost"pniana/sprzedawana klientowi, jaki i zosta& bezpo!rednio
zainstalowany na komputerze klienta. Ka da z tych opcji ma swoje zalety i wady.
Wiadomo, e warto!& narz"dzia informatycznego wzrasta, gdy istnieje mo liwo!& jego
integracji z innymi narz"dziami informatycznymi. Architektura mojego systemu mo e
pozwoli& w przysz#'!ci na jego integracj" z innymi istniej$cymi systemami w szpitalach
(PACS, RIS, HIS).
10.1. Scenariusze u"ycia systemu
Dzi"ki temu, e system InterMed oparty jest o sie& Internet, jego instalacja odbywa si" na
jednym komputerze-serwerze. Jest to bardzo wygodne rozwi$zanie które pozwala na #atwe
zarz$dzanie i utrzymanie systemu. Daje ono równie swobod" dopasowania systemu do
specyfiki danego klienta.
10.1.1. System jako us!uga zewn trzna
Jedn$ z mo liwych opcji jest sprzeda klientowi nie rozwi$zania (systemu), tylko us#ugi
(dost"pu do systemu). Jest to nowoczesne podej!cie do zarz$dzania aplikacjami
informatycznymi, które pozwala klientowi skupi& si" na istocie problemu, przenosz$c
odpowiedzialno!& utrzymania systemu na dostawc .
Wady i zalety takiego podej!cia zestawiono poni ej.
Z punktu widzenia klienta
Z punktu widzenia dostawcy
Utrzymanie sytemu przez specjalistów tworz$cych
system, którzy najlepiej wiedz$ jak nim zarz$dza&
+ ytkownik nie ponosi kosztów zwi$zanych z
zakupem dodatkowego sprz"tu
Zalety
Zarz$dzanie danymi po stronie us#ugodawcy (np.
kopie bezpiecze)stwa)
Korzystanie z us#ugi wtedy kiedy jest rzeczywi!cie
potrzebna
Konieczno!&
posiadania
szybkiego
internetowego
Wady
Wi"ksze opó-nienie w dost"pie do danych
Mo liwo!& usprawnienia pracy
systemu bez wiedzy klienta
,atwo!& utrzymania sytemu
(instalacja w jednym miejscu)
Odpowiedzialno!& za dane wielu
klientów
#$cza
Du e wymagania sprz"towe
(sie&, dyski)
Potrzeba
zatrudnienia
osób
dbaj$cych o poprawn$ prac"
systemu
Tabela 10.1. System jako us!uga zewn trzna z punktu widzenia klienta i dostawcy –
porównanie
69
10.1.2. System u klienta
System mo e by& równie zainstalowany na sprz"cie klienta i w takim przypadku to w#%!nie
na nim spoczywa cze!& prac zwi$zanych z zapewnieniem jego poprawnego dzia#ania
(zatrudnienie administratora, zakup sprz"tu).
Tak e serwisowanie sprz"tu w przypadku awarii, b$.- te potrzeba dodania nowej
funkcjonalno!ci b".$ zwi$zane z dodatkowymi kosztami i opó-nieniami w pracy systemu.
W tabeli poni ej zebrano wady i zalety takiego podej!cia.
Z punktu widzenia klienta
Z punktu widzenia dostawcy
Zalety Szybki dost"p do danych
Zakup infrastruktury
Wady Potrzebna osoba dbaj$ca
system
Nie wymagana dodatkowa infrastruktura
o
Instalacja i serwis u wielu klientów w wielu
miejscach
Tabela 10.2. Instalacja systemu u klienta - porównanie zalet i wad
10.2. Perspektywy rozwoju i integracji systemu
System InterMed zosta# opracowany jako rozwi$zanie samodzielne, o architekturze
zamkni"tej. Nie #$czy si" on z innymi systemami szpitala (lub innej instytucji) w celu pobrana
z nich informacji lub zapisu wyników, co uniemo liwia wykorzystanie informacji w nim
zgromadzonych w innych systemach szpitalnych. Dlatego aktualna posta& systemu mo e
*#/ (& jako narz"dzie badawcze, b$.- te prototyp docelowego systemu.
Obecna architektura systemu zosta#a przedstawiona na diagramie architektury systemu.
W kolejnych punktach zostan$ opisane mo liwe sposoby rozwoju systemu w celu uczynienia
z niego narz"dzia znajduj$cego zastosowanie we wspó#czesnych systemach informatycznych
szpitala.
10.2.1. Obrazy pobierane z systemu PACS
W chwili obecnej operator za pomoc$ specjalnego formularza #aduje zdj"cia medyczne na
serwer, gdzie s$ umieszczane w strukturze katalogów. Czynno!& ta zwi$zana jest oczywi!cie
z dodatkow$ prac$ i jest podatna na ró ne b#"dy (brak / niekompletno!& danych). Sam fakt
przechowywania danych obrazowych pacjenta na serwerze dost"pnym w Internecie mo e
budzi& obawy zwi$zane z bezpiecze)stwem i równie wymaga dodatkowych zabiegów
administracyjnych.
Integracja systemu InterMed z systemem PACS szpitala pozwoli#aby zniwelowa& te problemy
i zwolni#aby z systemu obowi$zek archiwizacji danych medycznych. Integracja taka powinna
zosta& wykonana z zachowaniem istniej$cych standardów (DICOM), aby system InterMed
móg# wspó#dzia#%& z dowolnym systemem PACS.
Propozycja architektury systemu uwzgl"dniaj$cej opisane zmiany zosta#a zamieszczona na
poni szym diagramie.
70
Rysunek 10.1. Integracja z systemem PACS
10.2.2. Informacja o badaniu pobierana z systemu RIS / HIS
Brak integracji systemu InterMed z systemami HIS i RIS jest równie powa nym
ograniczeniem, które z jednej strony wymusza wprowadzenie wszystkich informacji
w systemie (np. dane pacjenta) i z drugiej strony nie pozwala na wykorzystanie tych
informacji poza systemem.
Dlatego po#$czenie systemu InterMed z innymi systemami informacyjnymi szpitala (HIS,
RIS) wydaje si" jak najbardziej s#uszne.
Model systemu po integracji:
Rysunek 10.2. Integracja z systemami RIS i HIS
71
10.2.3. Usprawnienie komunikacji poprzez wideo-konferencje
Modu# komunikacji zaprojektowany w systemie nie umo liwia interakcji mi"dzy
/ ytkownikami w czasie rzeczywistym. W sytuacji krytycznej, kiedy opinia innego lekarza
jest potrzebna natychmiast, takie rozwi$zanie nie spe#ni#oby na pewno swojej roli
(komunikacja) i wymaga#oby wsparcia np. poprzez sie& telefoniczn$.
Najlepszym sposobem usprawnienia komunikacji s$ wideokonferencje, które umo liwiaj$ nie
tylko prowadzenie dyskusji w czasie rzeczywistym, ale równie daj$ mo liwo!& wizualnego
przedstawienia rozwi$zania danego problemu.
Model systemu z uwzgl"dnieniem wideokonferencji przedstawiono poni ej.
Rysunek 10.3. Wsparcie poprzez wideokonferencje
Uwagi:
Powy szy model prezentuje wszystkie opisane wcze!niej usprawnienia
i integracje systemu InterMed.
72
11. Zako#czenie
11.1. Podsumowanie
System informatyczny zrealizowany w ramach tej pracy magisterskiej jest projektem
innowacyjnym. Dzi"ki zastosowaniu nowoczesnych technologii zwi$zanych z Internetem,
pozwala rozszerzy& obszar zastosowania szpitalnego systemu informacyjnego, przyczyniaj$c
si" tym samym do poprawy opieki nad pacjentem i redukcji kosztów operacyjnych. Aby
narz"dzie to nie pozosta#o tylko prac$ badawcz$ i zosta#o wdro one we wspó#czesnych
systemach musi spe#nia& okre!lone warunki. S$dz", e naj#atwiej b"dzie to stwierdzi&
odpowiadaj$c na par" zasadniczych pyta), z których najwa niejsze to:
Czy system wspomaga sk adowanie i przesy anie danych (w tym obrazów medycznych) na
odleg !"#?
Czy umo$liwia konsultacj% dwóch lekarzy oraz komunikacj% lekarza z pacjentem znajduj&cym
si% w innym miejscu?
Na te pytania mog odpowiedzie! twierdz"co, poniewa# zaprojektowany system posiada takie
mo#liwo$ci. System ten mo#na uzna! w pewnym sensie za rozwi"zanie kompletne, poniewa#
oferuje lekarzowi nie tylko mo#liwo$! zarz"dzania kartotek" bada% (opcja dodawania,
przegl"dania, usuwania, edycji bada%), ale równie# pozwala na zdalne konsultacje z innym
lekarzem i wysy&anie wyników do pacjenta.
Kolejnym wa#nym pytaniem jest:
Czy zaprojektowany system jest rozwi&zaniem dost%pnym ze wzgl%du na koszt wdro$enia
i utrzymania dla przeci%tnego szpitala?
Czynnik ten by& bardzo wa#ny w trakcie realizacji projektu i zosta& po&'#ony du#y nacisk na
mo#liwie niski koszt gotowego projektu. U#ycie darmowych narz dzi i aplikacji powoduje, #e
przewa#aj"ce wydatki przy wdro#eniu systemu b (" zwi"zane z zapewnieniem infrastruktury
sprz towej, a w przypadku dostatecznej komputeryzacji zainteresowanej placówki, koszty te
) (" sprowadza! si do zapewnienia stabilnej pracy wdro#onego systemu.
Warto równie# przeanalizowa! s&abe strony powsta&ego systemu. Na pewno problemem mo#e
by! wymaganie du#ej przestrzeni na dysku twardym komputera dla sk&adowanych danych
obrazowych, oraz dost p do szybkich &"cz internetowych w celu zminimalizowania czasu
oczekiwania. W obecnej chwili system InterMed nie umo#liwia integracji z innymi
systemami szpitala, co ogranicza obszar jego stosowania (propozycje rozwi"zania tego
problemu zosta&y przedstawione w rozdziale 'Perspektywy rozwoju i integracji systemu').
73
11.2. Prezentacja projektu
Projekt zrealizowany w ramach pracy magisterskiej zosta& zaprezentowany przez autora
podczas Mi dzynarodowej Konferencji Naukowej Studentów Uczelni Medycznych [45],
która odbywa&a si w dniach 6-8 kwietnia 2006 roku na Uniwersytecie Jagiello%skim.
Wyst"pienie mia&o miejsce w trakcie Sesji Telemedycyny i Biocybernetyki dnia 08.04.2006.
Rysunek 11.1. Certyfikat wyg oszenia pracy na konferencji
Prezentacja by&a jedn" z niewielu, na których przedstawiono nie tylko istot poruszanego
problemu (i mo#liwe sposoby jego rozwi"zania), ale równie# zaproponowano w&asne
rozwi"zanie informatyczne.
Udzia& w konferencji by& dla autora bardzo cennym do$wiadczeniem, poniewa# realizowany
temat pracy magisterskiej móg& zosta! skonfrontowany ze $rodowiskiem medycznym, dla
którego jest dedykowany.
74
11.3. Prowadzenie prac
Podczas realizacji pracy magisterskiej skorzystano z kilku technologii i rozwi"za%, które
bardzo u&atwi&y prowadzenie prac .
Przyczyni&y si one w du#ym stopniu do poprawy organizacji zada% na kolejnych etapach
pracy i pomog&y osi"gn"! zamierzony efekt. Poni#ej zosta&y pokrótce przedstawione niektóre
z nich.
11.3.1. Portal projektowy
Po wybraniu tematu pracy magisterskiej i dyskusji z promotorem na temat celu i zakresu jaki
mia&a by obejmowa!, autor postanowi& przygotowa! portal internetowy [54] po$wi cony jej
realizacji. Chciano w ten sposób publicznie poinformowa! co b dzie przedmiotem bada%
i jakie efekty uda&o si osi"gn"!.
Na portalu zosta&y wyró#nione trzy kategorie:
•
Informacje
Przedstawiono tutaj temat, cel oraz zakres projektu.
•
Dokumentacja
Jest to miejsce gdzie znajduj" si
realizacji projektu.
•
opracowania powsta&e na kolejnych etapach
Projekt
Tutaj natomiast zosta&y opisane techniczne aspekty realizacji tematu, tzn. u#yte
technologie, narz dzia programistyczne oraz zaprezentowano projekty interfejsu
*#ytkownika i struktur bazy danych.
Portal zosta& przygotowany z wykorzystaniem narz dzia Apache Forrest.
Forrest [47] jest narz dziem klasy Open Source opracowywanym pod patronatem
Apache Software Fundation [46]
Umo#liwia on transformowanie dokumentów z ro#nych formatów wej$ciowych
w jednolit" prezentacj w jednym lub wielu formatach wyj$ciowych. Wykorzystanie
XML i szablonów XSLT pozwala na ca&kowite oddzielenie struktury dokumentu od
warstwy prezentacji. Forrest mo#e generowa! statyczne dokumenty, albo zosta! u#yty
jako dynamiczny serwer umo#liwiaj"cy automatyczne publikowanie tre$ci
w Internecie.
75
Narz dzie to umo#liwi&o publikowanie dokumentów opracowanych w wybranym przez autora
standardzie dokumentacji technicznej DocBook.
Poni#ej przedstawiono stron g&ówn" portalu:
Rysunek 11.2. Portal projektowy
11.3.2. System kontroli wersji
Zgodnie z rad" Andrew Hunta i Devida Thomasa [5], autor zawsze stara si u#ywa! systemu
kontroli kodu +ród&owego - nie tylko podczas tworzenie oprogramowania, ale równie#
w trakcie edycji dokumentów. Systemy tego rodzaju s" cz sto wykorzystywane przez firmy
komputerowe, jednak#e zaleca si stosowanie ich wsz dzie tam gdzie wa#ne jest zarz"dzanie
tre$ci" [28].
Jednym z tego typu systemów jest Subversion.
Subversion (SVN) [48] jest zaawansowanym systemem kontroli wersji, który zosta&
opracowany jako nast pca bardzo popularnego narz dzia CVS (Concurrent Versions
System).
76
W repozytorium (miejscu sk&adowania dokumentów) zosta&y utworzone dwie struktury
katalogów, dla projektu i dla dokumentacji. Zosta&y one przedstawione na poni#szych
rysunkach:
Rysunek 11.3. Repozytorium: dokumentacja
Rysunek 11.4. Repozytorium: projekt
Cechy systemu, które by&y szczególne przydatne dla autora podczas realizacji pracy
magisterskiej:
1. Centralne sk&adowanie wszystkich dokumentów
Znacznie poprawi&o bezpiecze%stwo pracy, jednoczenie znosz"c obowi"zek ci",&ej
archiwizacji kolejnych wersji.
2. Dost p do ka#dej poprzedniej wersji
Umo#liwi&o podgl"d historii zmian, a tak#e w szczególnych przypadkach ich
anulowanie.
77
Dzi ki zaawansowanym mechanizmom porównywania plików mo#na by&o w ka#dej chwili
dowiedzie! si np. która zmiana spowodowa&a b&"d wy$wietlania fragmentu dokumentacji lub
jaka by&a poprzednia wersja danego tekstu.
Rysunek 11.5. Porównywanie wersji
11.3.3. Format zapisu dokumentacji technicznej
Ca&a dokumentacja projektu, jak równie# tre$! pracy magisterskiej, zosta&y opracowane
w ustandaryzowanym formacie dokumentacji technicznej DocBook.
DocBook [50] jest standardem dokumentacji technicznej, opracowywanym przez
organizacj OASIS (The Organization for the Advancement of Structured Information
Standards) [49], która równie# rozwija inne znane standardy takie jak np.
OpenDocument. Jest to j zyk $ci$le zdefiniowanych znaczników XML (dawniej
równie# SGML) opisuj"cych struktur dokumentu. Dzi ki dost pno$ci wielu
gotowych szablonów transformacji (XSLT) istnieje mo#liwo$! wygenerowania
dokumentów w ró#nych formatach i nadanie im po#"danego wygl"du.
Format ten zosta& wybrany, poniewa# pozwoli& on skupi! si na tre$ci dokumentu, a nie jego
wygl"dzie. Za pomoc" dost pnych znaczników XML zdefiniowano co dany tekst oznacza
i jaka jest jego funkcja w strukturze dokumentu.
78
Poni#szy przyk&ad przedstawia jak zosta& zapisany fragment definiuj"cy nazw systemu:
<para> !ownik terminów (terminów, akronimów, skrótów):</para>
<variablelist>
<varlistentry>
<term id="slownik_system">InterMed</term>
<listitem>
<para>
Skrót od nazwy analizowanego systemu: InterMed " Internetowy system
wspomagaj#cy lekarza w diagnozowaniu na podstawie obrazów medycznych.
</para>
<para>synonim: system</para>
</listitem>
</varlistentry>
</variablelist>
Wybieraj"c ten standard zosta&a osi"gni ta niezale#no$! si od systemu operacyjnego oraz
programu edycyjnego. W ka#dym momencie mo#na otworzy! dokument w dowolnym
edytorze tekstu i wprowadzi! poprawki. Cz sto korzystano jednak z ogólnodost pnego
programu XMLMind (XMLmind XML Editor Standard Edition) [51], który dba& o poprawne
korzystanie ze standardu Docbook i umo#liwia& wygodn" prac w trybie WYSIWYG.
Dzi ki temu, #e dokumenty s" zapisywane w postaci tekstowej mo#na nimi swobodnie
zarz"dza! przechowuj"c je w systemie zarz"dzania tre$ci". Umo#liwi&o to &atwy dost p do
poprzednich wersji i analiz ró#nic mi dzy nimi.
Dokumenty raz opracowane mo#na by&o przetwarza! do innych formatów wyj$ciowych lub
wy$wietla! je na portalu projektowym.
11.3.4. WIKI
Na etapie przygotowywania tre$ci pracy magisterskiej bardzo pomocne okaza&o si narz dzie
DokuWIKI. Umo#liwi&o ono gromadzenie i opracowywanie tre$ci w wygodny sposób
z dowolnego komputera pod&"czonego do sieci Internet.
DokuWIKI [53] jest narz dziem typu WIKI, które umo#liwia tworzenie i edytowanie
tre$ci przez wielu u#ytkowników bezpo$rednio z poziomu przegl"darki internetowej
(podobnie jak np. Wikipedia [52])
Narz dzie to przechowuje nie tylko aktualn" wersj" redagowanego tekstu, ale równie#
wszystkie poprzednie, umo#liwiaj"c w ten sposób analiz poczynionych zmian i
ewentualnie ich anulowanie.
Mo#liwa jest kontrola dost pu do systemu dzi ki zastosowaniu mechanizmów
autoryzacji.
79
Poni#ej przedstawiono sposób edycji spisu tre$ci:
Rysunek 11.6. WIKI: edycja strony
80
12. Wnioski
1) Przygotowany projekt, po etapie dok&adnej analizy, zosta& zaimplementowany i jest
gotowy do wdro#enia.
2) Dzi ki zastosowaniu darmowych narz dzi i ogólnie przyj tych standardów mo#e by!
on dalej rozwijany i dostosowywany do specyficznych wymaga% u#ytkowników.
3) Zrealizowany system jest rozwi"zaniem kompleksowym w zakresie, jaki obejmuje
(sk&adowanie i przegl"danie zdj !, komunikacja mi dzy lekarzami). Jednak#e
z powodu braku integracji z innymi modu&ami szpitalnego systemu informatycznego
mo#e by! on traktowany jedynie jako projekt badawczy.
4) Pomimo badawczego charakteru, w pe&ni realizuje on stawiane mu wymagania.
Zosta&a umo#liwiona komunikacja osób pracuj"cych nad danym badaniem, które
znajduj" si w ró#nych miejscach geograficznych. W trakcie tworzenia systemu,
uwzgl dniono potrzeb dostarczenia filtrów graficznych, pozwalaj"cych na
przetwarzanie obrazów w celu wydobycia istotnych informacji dla osoby
przegl"daj"cej zdj cia.
81
13. Literatura
Ksi!"ki
[1] Robert Rudowski. Copyright © 2003 Wydawnictwo naukowe PWN SA. 83-011-40569. Wydawnictwo naukowe PWN. Informatyka medyczna.
[2] Ewa Pi tka. Copyright © 2003 Wydawnictwo naukowe PWN SA. 83-011-4221-9.
Wydawnictwo naukowe PWN. Zintegrowany system informacyjny w pracy szpitala.
[3] Jayaram Udupa i Gabor Herman. Copyright © 2000 CRC Press. 08-493-3179-X. CRC
Press. 3D Imaging in Medicine.
[4] Nadia Magnenat-Thalmann i Daniel Thalmann. Copyright © 2004 John Wiley and Sons.
04-700-2316-3. John Wiley and Sons. Handbook of Virtual Humans.
[5] Andrew Hunt i David Thomas. 83-204-2672-3. WNT. 2000. Pragmatyczny programista. Od
czeladnika do mistrza..
[6] Dick Hamlet i Joe Maybee. 83-204-2844-0. WNT. 2003. Podstawy techniczne in$ynierii
oprogramowania.
[7] Sommerville Ian. 83-204-2795-9. WNT. 2003. In$ynieria oprogramowania.
[8] Martin Fowler i Kendall Scott. 83-725-5171-5. LTP. 2002. UML w kropelce.
[9] Shneiderman Ben. 0-321-26978-0. Addison Wesley. 2004. Designing the User Interface.
[10] Goodwill James. Helion. 83-7197-358-6. 2001. Java Server Pages - podr%cznik z przyk adami.
[11] D"bkowski Kamil. Mikom. 1998. VRML97. Trzeci wymiar Sieci.
[12] Wojnar Leszek i Miros&aw Majorek. Fotobit Design. 1994. Komputerowa analiza obrazu.
Rozprawy doktorskie
[13] Aneta G"dek. Wydzia& Mechaniczny Politechniki Krakowskiej. 2005. Komputerowa analiza
obrazu regeneratu kostnego w metodzie Lizarowa.
[14] Zbigniew Lata&a. Wydzia& Mechaniczny Politechniki Krakowskiej. 2002. Zastosowanie
komputerowej analizy obrazu ultrasonograficznego do badania serca.
Artyku y
[15] Biuletyn Informatyki Medycznej. UHC sp. z o.o.. 12 kwietnia 2005. „Szpitalny system
informatyczny #yj"cy organizm”. 3-6.
[16] Biuletyn Informatyki Medycznej. UHC sp. z o.o.. 12 czerwca 2005. „Nowe przegl"darki
DICOM”. 5.
82
[17] Biuletyn Informatyki Medycznej. UHC sp. z o.o.. 24 lutego 2006. „Cyfrowa radiologia Kilka wyja$nie% co do terminologii”. 5-6.
[18] Podstawowe problemy Informatyki Medycznej. Pawe& Miko&ajczak. Pracownia Technologii
Informatycznych, Instytut Fizyki, Uniwersytet M. Curie - Sk&odowskiej w Lublinie.
[19] Rewolucja informatyczna w medycynie.
Komputerowych, Uniwersytet Miko&aja Kopernika.
Prof..
W&odzis&aw
Duch.
Katedra
Metod
[20] Computerworld. IDG. 26 kwietnia 2004. „Zdrowie w normie”. Edward Byczy%ski i Marek
Weso&owski.
[21] Telemedycyna w praktyce - modele telekonsultacji medycznych oraz ich wykorzystywanie w
ramach Krakowskiego Centrum Telemedycyny. dr in#.. Aleksander Laurentowski, mgr in#.. Dominik
Radziszowski, i Adam Koprowski.
[22] Internet medyczny - wp yw nowych "rodków komunikacji na wspó czesne oblicze medycyny. Piotr
Kasztelowicz. Polskie Stowarzyszenie Internetu Medycznego, Odzia& Gru+licy i Chorób P&uc,
Wojewódzki Szpital im. Ludwika Rydygiera w Toruniu.
[23] Biuletyn NASK. NASK. 2003. 1509-3603. „Konsultacje medyczne za po$rednictwem
Internetu”. 12-13.
[24] Nowoczesne architektury systemów telemedycznych. -ukasz Czekierda, Joanna Kosi%ska, i Pawe&
Rzepa. Katedra Informatyki EAIiE, Akademia Górniczo-Hutnicza.
[25] Analiza obrazów Tomografii Komputerowej. Rafa& St gierski i Pawe& Miko&ajczak. Pracownia
Technologii Informatycznych, Instytut Fizyki, Uniwersytet M. Curie - Sk&odowskiej w Lublinie.
[26] Wykorzystanie technik wizualizacji danych w medycynie. Bo&dak Cezary. Politechnika
Bia&ostocka, Instytut Informatyki.
[27] Vogel Burda Communications. Chip. marzec 2005. „Sprz towe generowanie grafiki 3D”. Bie%kowski
Marcin.
[28] Gazeta IT. 19 pa dziernika 2005. „CVS – system nie tylko dla programistów”. Owsiak Micha&.
http://www.gazeta-it.pl/rozmaitosci/git39/cvs.html.
Adresy WWW
[29] http://creativecommons.org/licenses/by-nc-sa/2.5/pl/
[30] http://www.acr.org/
[31] http://www.nema.org/
[32] http://medical.nema.org/
[33] http://www.k-pacs.net/
[34] http://homepage.mac.com/rossetantoine/osirix/
[35] http://www.hl7.org/
83
[36] http://www.uml.org/
[37] http://www-306.ibm.com/software/awdtools/architect/swarchitect/
[38] http://pribadi.or.id/diary/2005/05/27/clean-look-theme-for-wordpress-15/
[39] http://mars.elcom.nitech.ac.jp/dicom/index-e.html
[40] http://java.sun.com/applets/
[41] http://www.bic.mni.mcgill.ca/users/crisco/jiv/
[42] http://www.bic.mni.mcgill.ca/
[43] http://www.mysql.com/
[44] http://tomcat.apache.org/
[45] http://www.stn.cm-uj.krakow.pl/conf2006/
[46] http://apache.org/
[47] http://forrest.apache.org/
[48] http://subversion.tigris.org/
[49] http://www.oasis-open.org/
[50] http://www.docbook.org/
[51] http://www.xmlmind.com/xmleditor/stdedition.html
[52] http://pl.wikipedia.org/
[53] http://wiki.splitbrain.org/wiki:dokuwiki
[54] http://saturn.mech.pk.edu.pl/usr/rpetryniak/work/praca_mgr/
[55] http://www.parallelgraphics.com/products/cortona/
[56] http://www.octaga.com/download_octaga.html
[57] http://www.mediamachines.com/playerproductpage.html
84
Dodatek A. Za !czniki
A.1. Struktura katalogów aplikacji WWW
\Apache Software Foundation\Tomcat 5.5\webapps\praca_mgr
|
about.html
|
badanie.jsp
|
badanieCTR.jsp
|
home.jsp
|
index.jsp
|
konsultacje.jsp
|
konsultacjeCTR.jsp
|
konsultacjeLista.jsp
|
lista.jsp
|
listaCTR.jsp
|
new.jsp
|
search.jsp
|
start.jsp
|
user.jsp
|
+---help
|
badanie.html
|
konsultacje.html
|
lista_badan.html
|
lista_konsultacji.html
|
logowanie.html
|
nowe_badanie.html
|
szukaj_badania.html
|
+---narzedzia
|
help_window.js
|
ogonki.jsp
|
utf8.txt
|
+---res
|
|
pomoc.gif
|
|
style.css
|
|
|
\---buttons
|
editperson.gif
|
mail.gif
|
newtopic.gif
|
trash.gif
|
\---WEB-INF
|
web.xml
|
\---classes
|
!readme.txt
|
+---dates
|
JspCalendar.class
|
\---foo
|
Connection.properties
|
logbean.class
|
logbean.java
|
\---polapol
ConnectionPool.class
ConnectionPool.java
PooledConnection.class
PooledConnection.java
85
A.2. Skrypty tworz!ce schemat bazy danych
-- ------------------------------------------------------------- Tabela zawiera informacje w danym badaniu.
-- -----------------------------------------------------------CREATE TABLE badanie (
kodbad
VARCHAR(20) NOT NULL,
pacjent_kodpac VARCHAR(20) NOT NULL,
lekarz_kodlek
databad
DATE NULL,
zdicom
VARCHAR(255) NULL,
zvolume
VARCHAR(255) NULL,
PRIMARY KEY(kodbad, pacjent_kodpac, lekarz_kodlek),
INDEX badanie_FK_lek(lekarz_kodlek),
INDEX badanie_FK_pac(pacjent_kodpac)
);
-----
-----------------------------------------------------------Tabela przechowuj ca opisy diagnoz wystawione przez poszczególnych lekarzy
(lekarza przeprowadzaj cego badanie i lekarzy konsultantów).
------------------------------------------------------------
CREATE TABLE diagnoza (
badanie_lekarz_kodlek
badanie_pacjent_kodpac
badanie_kodbad
diagnoza
konsultant
TINYTEXT NULL,
VARCHAR(20) NULL,
INDEX
diagnoza_FK_bad_pac_lek(badanie_kodbad,
badanie_lekarz_kodlek)
);
-----
badanie_pacjent_kodpac,
-----------------------------------------------------------Tabela z danymi lekarza, który przeprowadza badanie.
Tabela ta jest równie! tabel u!ytkowników systemu (kodlek + haslo)
------------------------------------------------------------
CREATE TABLE lekarz (
kodlek
haslo
VARCHAR(40) NULL,
imie
VARCHAR(20) NULL,
nazwisko
VARCHAR(30) NULL,
instytucja VARCHAR(100) NULL,
PRIMARY KEY(kodlek)
);
-- ------------------------------------------------------------- Tabela z danymi pacjenta, dla którego jest przeprowadzane badanie.
-- -----------------------------------------------------------CREATE TABLE pacjent (
kodpac
imie
VARCHAR(20) NULL,
nazwisko
VARCHAR(30) NULL,
adres
VARCHAR(100) NULL,
PRIMARY KEY(kodpac)
);
86
Dodatek B. Za !czniki w postaci cyfrowej
Spis za !czników w postaci cyfrowej:
Uwagi:
Wszystkie opisane poni"ej za !czniki znajduj! si# na CD do !czonym do pracy
oraz zosta y umieszczone na stronie WWW [54].
1. System InterMed
•
Prototyp systemu - posta$ statyczna systemu InterMed, w której poszczególne
strony zawieraj! zapisane na sta e, przyk adowe dane.
•
Schemat bazy danych - pe ny schemat bazy danych wraz z przyk adowymi
danymi (dost#pne tylko na CD do !czonym do pracy).
•
Kod "ród owy aplikacji - pe ny kod %ród owy systemu InterMed (dost#pne
tylko na CD do !czonym do pracy).
2. Analiza wymaga&
•
Architektura systemu - (IBM Rational Software Architekt) - wydzielone
diagramy UML, zapisane w osobnym pliku.
•
Architektura systemu - (IBM Rational Software Architect) - raport
szczegó owy wygenerowany automatycznie przez program.
3. Przegl!d narz#dzi wizualizacji medycznej
Uwagi:
W celu obejrzenia poni"szych za !czników wymagany jest dost#p do sieci Internet.
Ka"da z poni"szych stron prezentuje narz#dzia jakie by y u"ywane / analizowane podczas
reazlizacji tej pracy magisterskiej, zarówno w postaci oryginalnej, jak i zmodyfikowanej.
•
•
•
Przegl!darka DICOM - strona WWW, która prezentuje mo"liwo'ci modu u
DICOM.
•
Wizualizacja medyczna - strona WWW, która prezentuje mo"liwo'ci modu u
Wizualizacja.
•
The Visible Human Project - strona WWW, na której zosta a zainstalowana
aplikacja Visible Human Viewer.
4. Próba wizualizacji przestrzennej obrazu
•
Wyznaczanie konturów - analiza porównawcza wybranych narz#dzi
programistycznych do wykrywania konturu obrazu.
•
Wizualizacja zdj#$ tomograficznych - próba wizualizacji przestrzennej
obrazów przekrojowych w technologi X3D. Dane pochodz! z badania
tomografem komputerowym.
•
Test Przegl!darek VRML/X3D - analiza porównawcza najpopularniejszych
przegladarek VRML/X3D.
87
Dodatek C. Tre%$ i warunki licencji
Uznanie autorstwa-U ycie niekomercyjne-Na tych samych warunkach 2.5 Polska
Wolno:
•
kopiowa , rozpowszechnia , odtwarza i wykonywa utwór
•
tworzy utwory zale!ne
Na nast!puj"cych warunkach:
Uznanie autorstwa. Utwór nale!y oznaczy w sposób okre"lony przez
Twórc# lub Licencjodawc#
# ycie niekomercyjne. Nie wolno u!ywa tego utworu do celów
komercyjnych.
Na tych samych warunkach. Je"li zmienia si# lub przekszta$ca
niniejszy utwór, lub tworzy inny na jego podstawie, mo!na
rozpowszechnia powsta$y w ten sposób nowy utwór tylko na podstawie
takiej samej licencji.
•
W celu ponownego u!ycia utworu lub rozpowszechniania utworu nale!y wyja"ni innym
warunki licencji, na której udost#pnia si# utwór.
•
Ka!dy z tych warunków mo!e zosta uchylony, je"li uzyska si# zezwolenie w$%"ciciela
praw autorskich.
Powy sze postanowienia w aden sposób nie naruszaj" uprawnie$ wynikaj"cych z
dozwolonego u ytku ani adnych innych praw.
88
Spis rysunków
1.1. Zdj#cie rentgenowskie d oni "ony Roentgena wykonane przez samego K.W. Roentgena w 1896
1.2. Zdj#cie tomograficzne dziewi#cioletniej dziewczynki
1.3. Zdj#cie przekrojowe g owy cz owieka wykonane w badaniu rezonansem magnetycznym
1.4. Ultrasonografia czteromiesi#cznego p odu
2.1. Budowa systemu PACS
6.1. Koncepcja systemu
7.1. Model przep ywu informacji
7.2. Model architektury systemu
7.3. Przegl!d aktorów systemu
7.4. Kluczowe przypadki u"ycia
7.5. Diagram czynno'ci dla kluczowych funkcji systemu
7.6. Wymagania sprz#towe
8.1. Diagram klas dla przypadku u"ycia 'Dodaj badanie'
8.2. Diagram sekwencji dla przypadku u"ycia 'Dodaj badanie'
8.3. Diagram komunikacji dla przypadku u"ycia 'Dodaj badanie'
8.4. Diagram pakietów
8.5. Diagram wdro"enia
8.6. Projekt bazy danych
8.7. Projekt interfejsu
8.8. Iteracyjny proces budowania systemu
8.9. Proces V budowania i testowania poszczególnych modu ów
8.10. Dekompozycja systemu
8.11. Okienko logowania
8.12. Strona g ówna (powitalna)
8.13. Nowe badanie
8.14. Nowe badanie - pomoc
8.15. Wykonane badanie
8.16. Potwierdzenie usuni#cia badania
8.17. Wykonane badanie - pomoc
8.18. Widok listy bada&
8.19. Wyszukiwanie bada&
8.20. Informacja o systemie
8.21. Modu DICOM
8.22. Modu DICOM - opcja 'ZOOM'
8.23. Modu DICOM – filtry(1)
8.24. Modu DICOM – filtry(2)
8.25. Modu Wizualizacja: okno g ówne
8.26. Ekran konsultacji
9.1. Wizualizacja punktowa obrazów przekrojowych wygenerowana w technologii X3D
10.1. Integracja z systemem PACS
10.2. Integracja z systemami RIS i HIS
10.3. Wsparcie poprzez wideokonferencje
11.1. Certyfikat wyg oszenia pracy na konferencji
11.2. Portal projektowy
11.3. Repozytorium: dokumentacja
11.4. Repozytorium: projekt
11.5. Porównywanie wersji
11.6. WIKI: edycja strony
89
Spis tabel
7.1. Wymagania dot. bezpiecze&stwa systemu 3DVS
7.2. Wymagania dot. sprz#tu
7.3. Pozosta e wymagania dot. systemu 3DVS
8.1. Filtry graficzne
9.1. Zdj#cia z badania rezonansem magnetycznym
10.1. System jako us uga zewn#trzna z punktu widzenia klienta i dostawcy - porównanie
10.2. Instalacja systemu u klienta - porównanie zalet i wad
Spis przyk adów
8.1. Sk adnia znacznika mailto
8.2. Przyk ad u"ycia znacznika mailto
9.1. X3D: znacznik PointSet
9.2. X3D: znacznik IndexedFaceSet
9.3. X3D: znacznik ElevationGrid
90

praca dyplomowa - Politechnika Krakowska

Transkrypt

Podobne dokumenty

Zobacz film - Paco Cases