94
POLITECHNIKA KRAKOWSKA im. T. Kociuszki Wydzia Mechaniczny Instytut Informatyki Stosowanej Kierunek studiów: Informatyka Specjalno : Informatyka Stosowana STUDIA STACJONARNE PRACA DYPLOMOWA MAGISTERSKA Rafa Petryniak Internetowy system wspomagajcy lekarza w diagnozowaniu na podstawie obrazów medycznych. Promotor: Dr in. Zbigniew Lataa Kraków, rok akad. 2005/2006

Rafał Petryniak - Praca magisterska

Embed Size (px)

DESCRIPTION

Rafał Petryniak, PRACA DYPLOMOWA, MAGISTERSKA: "Internetowy system wspomagający lekarza w diagnozowaniu na podstawie obrazów medycznych" Promotor: Dr inż. Zbigniew Latała Kraków, rok akad. 2005/2006 POLITECHNIKA KRAKOWSKA im. T. Kościuszki Kierunek studiów: Informatyka Specjalność : Informatyka Stosowana Praca dostępna na licencji Creative Commons 2.5 (Uznanie autorstwa-użycie niekomercyjne-Na tych samych warunkach)

Citation preview

Page 1: Rafał Petryniak - Praca magisterska

POLITECHNIKA KRAKOWSKA im. T. Ko ciuszki

Wydzia MechanicznyInstytut Informatyki Stosowanej

Kierunek studiów: Informatyka

Specjalno!" : Informatyka Stosowana

STUDIA STACJONARNE

PRACA DYPLOMOWAMAGISTERSKA

Rafa! Petryniak

Internetowy system wspomagaj#cy lekarza w diagnozowaniuna podstawie obrazów medycznych.

Promotor:Dr in$. Zbigniew Lata!a

Kraków, rok akad. 2005/2006

Page 2: Rafał Petryniak - Praca magisterska

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]

Page 3: Rafał Petryniak - Praca magisterska

KARTA PRACY DYPLOMOWEJ

Nr pracy:POLITECHNIKA KRAKOWSKA

WYDZIA" MECHANICZNY

INSTYTUT INFORMATYKI STOSOWANEJ

Zak!ad Komputerowej Analizy Obrazu M-74

Promotor:

Dr in#. Zbigniew Lata!a

Autor pracy:

Rafa! Petryniak

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

Page 4: Rafał Petryniak - Praca magisterska

Podzi%kowania

Serdeczne podzi%kowania za zaanga$owanie i pomoc udzielon# w trakcie pisania niniejszejpracy chcia bym z &$'" Panu dr in$. Zbigniewowi Latale oraz Panu mgr in$. DariuszowiKarpiszowi.

Na koniec pragn% równie$ podzi%kowa" Kole$ance Magdalenie Lewickiej za ci#( e wsparcieduchowe i merytoryczne.

Page 5: Rafał Petryniak - Praca magisterska

1

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...............................................................102.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..........................................................................................................112.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 .....................................................................................................................144.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........................................................................155.1.2. Integracja nowoczesnych urz!dze& przeno%nych .......................................................................155.1.3. Ujednolicony format cyfrowej reprezentacji informacji medycznej............................................155.1.4. Zapewnienie transmisji obrazu w czasie rzeczywistym - wideokonferencje ...............................155.1.5. Bezpiecze&stwo przesy$u informacji medycznej........................................................................165.1.6. Integracja specjalistycznej aparatury z sieci! komputerow! .......................................................165.1.7. Automatyzacja i prze'roczysto%# ..............................................................................................16

5.2. Obszary zastosowa# telemedycyny .....................................................................................16

Page 6: Rafał Petryniak - Praca magisterska

2

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.....................................................................................................217.2.2. Model architektury systemu......................................................................................................22

7.3. Analiza wymaga# funkcjonalnych ......................................................................................23

7.4. Analiza wymaga# niefunkcjonalnych..................................................................................28

7.4.1. Bezpiecze&stwo........................................................................................................................287.4.2. Wymagania sprz"towe..............................................................................................................287.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.......................................................................................................................418.5.2. Modu$ DICOM.........................................................................................................................518.5.3. Modu$ Wizualizacja .................................................................................................................548.5.4. Modu$ Komunikacja.................................................................................................................57

8.6. Opis instalacji i konfiguracji projektu. ...............................................................................59

8.6.1. Przygotowanie infrastruktury sprz"towej ..................................................................................598.6.2. Przygotowanie niezb"dnego oprogramowania...........................................................................598.6.3. Instalacja systemu InterMed .....................................................................................................608.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 ............................................................................................................629.2.2. Wyznaczanie wspó$rz"dnych ....................................................................................................64

9.3. Wizualizacja VRML / X3D .................................................................................................66

9.3.1. Technologia VRML / X3D .......................................................................................................669.3.2. Wizualizacja punktowa.............................................................................................................679.3.3. Wizualizacja p$aszczyzny - napotkane problemy.......................................................................68

Page 7: Rafał Petryniak - Praca magisterska

3

ROZDZIA# 10. PERSPEKTYWY ZASTOSOWANIA I ROZWOJU SYSTEMU............................................69

10.1. Scenariusze u$ycia systemu ..............................................................................................69

10.1.1. System jako us$uga zewn"trzna...............................................................................................6910.1.2. System u klienta .....................................................................................................................70

10.2. Perspektywy rozwoju i integracji systemu.........................................................................70

10.2.1. Obrazy pobierane z systemu PACS.........................................................................................7010.2.2. Informacja o badaniu pobierana z systemu RIS / HIS ..............................................................7110.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 ...................................................................................................................7511.3.2. System kontroli wersji ............................................................................................................7611.3.3. Format zapisu dokumentacji technicznej .................................................................................7811.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 ...........................................................................................................................89SPIS TABEL ...................................................................................................................................90SPIS PRZYK*ADÓW........................................................................................................................90

Page 8: Rafał Petryniak - Praca magisterska

4

Wprowadzenie – cel i zakres pracy

Ogromny rozwój i upowszechnienie si" w ostatnich latach nowoczesnych systemówteleinformatycznych mia$o du-y wp$yw na popraw" funkcjonowania informatycznychsystemów szpitalnych. Ju- nie tylko integracja poszczególnych urz!dze& i aplikacji by$amo-liwa, ale pojawi$y si" równie- nowe formy %wiadczenia us$ug medycznych. Szerokiezastosowania 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 badaniao przegl!danie i edycja istniej!cych bada&o wyszukiwanie bada& wg zadanych kryteriów

• sk$adowanie zdj"# medycznych zapisanych w standardowych formatach w jednymmiejscu,

• umo-liwienie komunikacji osób pracuj!cych nad danym badaniem i rozproszonychgeograficznie,

• dostarczenie filtrów graficznych, umo-liwiaj!cych przetwarzanie obrazów w celuwydobycia istotnych informacji dla osoby przegl!daj!cej zdj"cia.

W pierwszej cz"%ci pracy (cze ! teoretyczna) zosta$a poruszona tematyka wykorzystaniainformatyki w problemach diagnostyki obrazowej, ze szczególnym uwzgl"dnieniemmo-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 problemyi sposoby ich rozwi!zywania.

Page 9: Rafał Petryniak - Praca magisterska

5

I. Cz&(% teoretyczna

Technologia komputerowa na prze$omie wieków XX i XXI by$a ju- obecna niemal wewszystkich dziedzinach -ycia spo$ecznego. Szerokie zastosowanie komputerów nie omin"$otak-e medycyny.

Zastosowanie informatyki w medycynie si"ga lat 60, kiedy to w Stanach Zjednoczonychzauwa-ono jakie mo-liwo%ci daje to wojsku. Kolejne lata przynios$y bardzo intensywnyrozwój bada& nad wykorzystaniem technologii informatycznych w ró-nych obszarachochrony zdrowia. W latach 70 pojawi$y si" pierwsze systemy administracyjne, ekspertowe(Mycin), a tak-e obrazowe (tomografia komputerowa). Lata 80 to okres budowy systemówklinicznych, wykorzystania baz danych oraz kolejne próby wykorzystania sztucznejinteligencji. Lata 90 przynios$y natomiast rozwój telemedycyny, wizualizacji 3D, orazstandaryzacj" danych medycznych (DICOM). Obecnie trudno sobie wyobrazi# prac" lekarzyspecjalistów bez wsparcia odpowiednich technologii informacyjnych.

Profesor W$odzis$aw Duch [19] wyró-nia kilka obszarów zastosowa& komputeróww 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!cechorób

• zdalny dost"p do danych medycznych i mo-liwo%# ich przesy$ania, konsultacjeekspertów

• teleobecno%# i wirtualna rzeczywisto%#

np. przeprowadzanie operacji na odleg$/%#

• inteligentna analiza danych medycznych i wspomaganie podejmowania decyzji

Page 10: Rafał Petryniak - Praca magisterska

6

Rozdzia' 1. Techniki akwizycji obrazów medycznych

Techniki obrazowania medycznego odgrywaj! bardzo wa-0! rol" we wspó$czesnejmedycynie. Szczególny wp$yw wywar$y na diagnostyk", gdzie mo-liwe sta$o si" wykrywanieschorze& zanim zaczn! dawa# objawy, co znacznie zwi"ksza szans" pacjenta na szybkipowró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óreprzechodz!c przez badane tkanki ulegaj! os$abieniu, w zale-no%ci od ich grubo%ci i sk$aduchemicznego [16]. Badacz ten, zbudowa$ równie- pierwsz! lamp" wykorzystuj!1! odkryteprzez siebie promienie, nazwan! na jego cze%# rentgenowsk!.

W tradycyjnym badaniu radiograficznym obraz zapisywany jest na kliszy, która poddawanajest obróbce chemicznej (podej%cie konwencjonalne). Jednak-e istniej! ju- systemy,pozwalaj!ce przeprowadzi# ca$e badanie stosuj!c zapis cyfrowy (radiografia cyfrowa), cowp$ywa na znaczne obni-enie kosztów samego badania, jak równie- umo-liwia $atwiejszydost"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 tegobadania jest obrazem sumacyjnym, co znaczy, -e jest sum! cieni ró-nych narz!dównak$adaj!cych si" na siebie, je-eli le-3$y one jeden nad drugim na drodze promieniowaniarentgenowskiego [1].

Page 11: Rafał Petryniak - Praca magisterska

7

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$adniejbudow" analizowanego narz!du.

W latach 70 Godfrey Newbold Hounsfield i Allan McLeod Cormack zbudowali tomografkomputerowy, który na podstawie serii obrazów radiograficznych wykonywanych podró-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" Noblaw dziedzinie medycyny.

Rysunek 1.2. Zdj&cie tomograficzne dziewi&cioletniej dziewczynki

W nowoczesnych tomografach komputerowych lampa emituj!ca wi!zk" promieni RTGobraca si" wokó$ pacjenta w p$aszczy'nie osiowej o 360°. Os$abienie wi!zki promieni RTGspowodowane 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$/-onychalgorytmó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ójbadanego obiektu. Jednak do pe$nego rozeznania anatomii badanej cz"%ci cia$a wskazaneby$oby wykonanie kilku obrazów na ró-nych wysoko%ciach. Problemem jaki w takiej sytuacjisi" 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 takiejsytuacji mo-e by# spiralna tomografia komputerowa [1], podczas której nie wykonuje si" seriizdj"#, a jeden ci!4$y pomiar. W badaniu tym poza ruchem obrotowym lampy RTGi detektorów - jak to ma miejsce w tradycyjnej Tomografii Komputerowej - przesuwa si" doprzodu $5-ko, na którym le-y pacjent.

Page 12: Rafał Petryniak - Praca magisterska

8

Uzyskane w ten sposób dane mog! by# wykorzystywane do tworzenia przekrojóww dowolnej p$aszczy'nie (X,Y,Z) i pod dowolnym k!tem, a z pomoc! specjalnychprogramó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$epole magnetyczne o wysokiej energii. W$asno%# ta powoduje, -e linie pola magnetycznego6!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 faleradiowe (zjawisko to nazywa si" rezonansem), a one rejestrowane s! przez aparat. W praktycejako 'rezonator' wykorzystuje si" j!dra atomu wodoru, których liczba w poszczególnychtkankach jest inna. Wykorzystuj!c tan fakt komputer wbudowany w urz!dzenie po wykonaniuskomplikowanych oblicze& przedstawia na ekranie monitora obraz badanych strukturanatomicznych.

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 badanegopacjenta, ulegaj! odbiciu na granicy dwóch o%rodków o ró-nej g"sto%ci. Zamieniaj!c powsta$yw ten sposób impuls akustyczny na impuls elektryczny i po wprowadzeniu skali szaro%cipoprzez uk$ady elektroniczne w ultrasonografie, na ekranie monitora powstaje obraz wybranejwarstwy narz!du czy tkanki. Przesuwaj!c g$owic! aparatu, uzyskuje si" obraz ca$egobadanego narz!du.

Wi"kszo%# stosowanych metod diagnostycznego obrazowania za pomoc! ultrad'wi"kówoparta jest na technice impulsowo-echowej. Badania takie wykonuje si" za pomoc! aparatówultrasonograficznych, które pozwalaj! na uzyskiwanie obrazów USG w czasie rzeczywistym,czyli zgodnie z ruchomo%ci! danego obrazu [17].

Page 13: Rafał Petryniak - Praca magisterska

9

Obraz w ten sposób otrzymany mo-e zosta# utrwalony na kliszy fotograficznej, b!2' te-zapisany w formie elektronicznej na dysku komputera i poddany bardziej szczegó$owejanalizie (odleg$/%ci dowolnych punktów, wielko%ci k!ta zawartego mi"dzy elementamianatomicznymi).

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 - SPETo 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 tometoda znacznie ta&sza od analogowych obrazów, jakimi s! klisze fotograficzne, a tak-eumo-liwia korzystanie z tych samych wyników w jednym momencie z kilku miejsc. Jednak-epotrzeba zachowania jak najlepszej jako%ci tych obrazów oraz fakt, -e wiele z nichwykonywana jest seryjnie (np. ultrasonograf generuje 30 obrazków na sekund") powodujeogromny wzrost zapotrzebowania na pami"# dyskow! komputerów. Wa-0! kwesti! jestzapewnienie bezpiecze&stwa tak sk$adowanych obrazów (archiwizacja, kopiebezpiecze&stwa) oraz ich ochrona przed nieautoryzowanym dost"pem.

Page 14: Rafał Petryniak - Praca magisterska

10

2.1. Zapis danych obrazowych - format DICOM

Pierwotnie ka-da firma produkuj!ca sprz"t wykorzystywany w radiologii (np. tomografykomputerowe) 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#. Problempojawi$ si", kiedy firma, od której by$ zakupiony ca$y sprz"t nie posiada$a w swojej oferciekolejnych, potrzebnych urz!dze&, lub gdy konkurencja dysponowa$a takim samym o lepszychparametrach i ni-szej cenie.

Pierwsze próby opracowania wspólnego standardu wymiany obrazów medycznych zosta$ypoczynione 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$orozwi!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ówsprz"tu medycznego otwieraj!c w ten sposób drog" do pe$nej integracji modu$ów systemupochodz!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%cipojawia si" wiele problemów z jego interpretacj! i nie zawsze dwa urz!dzenia, któredeklaruj! stosowanie tego standardu b"2! w stanie komunikowa# si" ze sob!.

Rozwi!zaniem tego problemu mo-e by# dokument "Stwierdzenie zgodno%ci ze standardemDICOM", 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 jedyniewskazanie 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!dzeniamiDICOM-owymi [2]. Dopiero porównanie dwóch takich dokumentów i wskazanie, -ewzajemnie spe$niaj! swoje wymagania daje przekonanie, -e ich wspó$praca powinnaodbywa# 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ówradiologicznych konieczne jest posiadanie specjalistycznego oprogramowania, które nie tylkorozumie specyficzne formaty danych, ale równie- umo-liwia manipulowanie nimi [25].

Poza grup! drogich, komercyjnych rozwi!za& dost"pne s! dwie przegl!darki, oferowane zadarmo, 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].

Page 15: Rafał Petryniak - Praca magisterska

11

Druga przegl!darka – OsiriX [34] – posiada podobne mo-liwo%ci do K-PACS-a. Udost"pniaona dodatkowo zaawansowane funkcje do generowania rekonstrukcji 3D. Dost"pna jest onajednak-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 CommunicationSystem), które pozwala$y na przechowywanie i zarz!dzanie danymi obrazowymi. Jednak-edopiero po wprowadzeniu standardu DICOM, systemy te w pe$ni realizuj! swoje funkcje ipozwalaj! 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"pnianiadanych obrazowych.

• bezpiecze+stwo sk'adowania danych - utrzymanie kopii ka-dego obrazu na innymkomputerze.

• komunikacja z urz*dzeniami diagnostycznymi - automatyzacja przesy$u obrazówz urz!dze& diagnostycznych do serwera PACS.

• udost&pnianie danych obrazowych - umo-liwienie przegl!danie danychsk$adowanych w systemie PACS ma stacjach diagnostycznych.

• autorouting - automatyczne przesy$anie danych obrazowych na stacje diagnostycznew 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 celachporó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

Page 16: Rafał Petryniak - Praca magisterska

12

Rysunek 2.1. Budowa systemu PACS

Dzi"ki wykorzystaniu standardu DICOM istnieje mo-liwo%# ich integracji z innymisystemami 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 medycznychstaraj! si" coraz cz"%ciej wykorzystywa# mo-liwo%ci grafiki trójwymiarowej.

.$ównym problemem przy wizualizacji przestrzennej pozostaje brak standardów zapisuobrazu 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"pnieich rekonstrukcja w specjalistycznych programach. Optymistyczny mo-e wydawa# si" rozwójnowoczesnych technologii, które umo-liwiaj! zapis wyników z badania w postaci danychobj"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# szeregskomplikowanych operacji. Najpierw ka-dy obraz jest poddawany analizie, podczas której

1 Poj"cie szerzej wyja%nione w rozdziale 3.2.

Page 17: Rafał Petryniak - Praca magisterska

13

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 wydzielonezbiory punktów dla poszczególnych p$aszczyzn powinny zosta# przetransformowane doprzestrzeni trójwymiarowej. W ostatnim etapie stosuje si" morfing, który pozwala naprzybli-enie warstw po%rednich, co umo-liwia odwzorowanie pe$nego obiektuprzestrzennego. Metoda ta wymaga komputerów o du-ej mocy obliczeniowej i jest obarczona7$"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 badanegoprzedzia$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. volumetrictexture [4]), które za pomoc! specjalnego oprogramowania mog! by# przegl!danew dowolnym kierunku (X, Y, Z). Jednak-e to nie koniec mo-liwo%ci, jakie daje ten sposóbakwizycji 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# badanestruktury anatomiczne. Umo-liwiaj! one dodatkowo usuwanie warstwa po warstwieposzczególnych tkanek, co mo-e by# bardzo pomocne w szczegó$owej analizieposzczegó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, -etradycyjne 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 tychjednostek. Wiele prób wprowadzenie nowych technologii zosta$o podj"tych ju- kilkadziesi!tlat temu, jednak-e ówczesne ograniczenia technologiczne i nieumiej"tno%# wykorzystanianowego narz"dzia dramatycznie ograniczy$y oczekiwane korzy%ci [15]. Od kilku lat trwakolejna faza komputeryzacji, w której dzi"ki do%wiadczeniu zdobytemu na przestrzeni lati ogromnemu post"powi technologicznemu, a tak-e wprowadzeniu norm i standardówpowstaj! rozwi!zania dla ka-dej strefy dzia$ania szpitala. Integracja tych rozwi!za& pozwalana 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$aoparta na klasyfikacji zaproponowanej przez Ew" Pi"tk" w ksi!-ce 'Zintegrowany systeminformacyjny w pracy szpitala' [2].

Page 18: Rafał Petryniak - Praca magisterska

14

4.1.1. Modu'y centralne

• Modu' Ruchu Chorych pacjentów szpitalnych - umo-liwia obs$ug" ruchu pacjentaod chwili przyj"cia na Izb" Przyj"# do momentu jego wypisu ze szpitala. Przechowujeon nie tylko informacje o samym pacjencie (dane teleadresowe, lekarz lub jednostkakieruj!ca), ale rejestruje równie- histori" jego pobytu w szpitalu (numer sal, w którychprzebywa$, 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 realizacjiprocedury 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 diagnostykiobrazowej. Zlecenia mog! by# przesy$ane z ogólnoszpitalnego systemuinformatycznego (HIS), b!2' te- z rejestracji pacjentów ambulatoryjnych.

• System Archiwizacji i Transmisji Obrazów (ang. Picture Archiving andCommunication System - PACS) - w odró-nieniu od wy-ej opisanych modu$ów,system ten nie zarz!dza informacj! alfanumeryczn!, a danymi obrazowymi. Jego4$ównym zadaniem jest gromadzenie obrazów pochodz!cych z bada& radiologicznychi 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!dzeniaperyferyjne. Firmy informatyczne cz"sto wykorzystywa$y w$asne standardy, które nieumo-liwia$y pod$!czenia oprogramowania / sprz"tu innych firm. Naciski u-ytkownikówi pojawiaj!ca si" frustracja firm informatycznych, które nie potrafi$y spe$ni# wszystkichwymaga& swoich klientów, doprowadzi$y do powo$ania komitetów normalizacyjnych,których zadaniem by$o opracowanie standardów wymiany informacji w systemachmedycznych.

Sposób transmisji i format zapisu danych obrazowych zosta$ zawarty w standardzie DICOMopracowanym przez ACR-NEMA (format ten zosta$ dok$adnie opisany w rozdziale 'Zapisdanych obrazowych - format DICOM'). Natomiast format przesy$ania informacji tekstowejw 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ówi umo-liwi$a ich wzajemn! komunikacj" [20].

Page 19: Rafał Petryniak - Praca magisterska

15

Rozdzia' 5. Telemedycyna

Ogromny rozwój i upowszechnienie si" w ostatnich latach nowoczesnych technologiiteleinformatycznych mia$o wp$yw na pojawienie si" nowych form %wiadczenia us$ugmedycznych, ogólnie zwanych telemedycyn!. Jest ona m.in. definiowana [1] jako kontaktlekarza z pacjentem, znajduj!cym si" w innym miejscu. Pierwsze formy telemedycynypojawi$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 dziedzinieinformatyki 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 swoimzasi"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 czasuoczekiwania na reakcj" systemu, która nie powinna przekracza# kilku sekund, a w wielusytuacjach (wideokonferencje, zagro-enie -ycia) powinna si" odbywa# w czasierzeczywistym. W tym przypadku zaleca si" stosowanie wydajnych sieci szerokopasmowych,które b"2! w stanie sprosta# wi"kszo%ci wymaga&. Natomiast w przypadku transmisji obrazuwysokiej rozdzielczo%ci ich parametry mog! okaza# si" niewystarczaj!ce, wówczas zaleca si"stosowanie technik kompresji informacji, co mo-e przynie%# znaczn! popraw" przesy$aniadanych.

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# ichopis, dane pacjenta oraz parametry wykonanego badania.

5.1.4. Zapewnienie transmisji obrazu w czasie rzeczywistym - wideokonferencje

Nowoczesne systemy teleinformatyczne powinny umo-liwia# przeprowadzenietelekonsultacji, podczas których specjali%ci ró-nych dziedzin w o%rodkach o wy-szympoziomie referencyjnym mog! zdalnie konsultowa# kontrowersyjne przypadki u pacjentówznajduj!cych si" w o%rodkach peryferyjnych czy szpitalach o ni-szym poziomiereferencyjnym [21]. Jest wskazane, aby taka komunikacja odbywa$a si" w czasierzeczywistym, z mo-liwo%ci! przesy$ania jednocze%nie d'wi"ku i obrazu wideo(wideokonferencje).

Page 20: Rafał Petryniak - Praca magisterska

16

5.1.5. Bezpiecze+stwo przesy'u informacji medycznej

Dla pe$nej akceptacji i wykorzystania rozwi!za& telemedycznych w praktyce wymagana jestgwarancja bezpiecze&stwa przesy$anych informacji. Przez d$ugie lata takiej gwarancji nieby$o i tworzone oprogramowanie telemedyczne mog$o mie# jedynie charakter badawczy.Dopiero w momencie wprowadzenia zaawansowanych zabezpiecze& w systemachfinansowych, zmieni$ si" pogl!d na mo-liwo%# wykorzystania Internetu w medycynie, gdziepoziom 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 zawiadamianie9$8-b medycznych, coraz cz"%ciej stosuje si" techniki komputerowe w zminiaturyzowanejaparaturze 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 jegodzia$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 monitorowaniezdrowia pacjenta w domu

• asystowanie przy trudnych zabiegach chirurgicznych - lekarz z innego szpitalamo-e wspomaga# lekarza przeprowadzaj!cego zabieg

• medycyna powypadkowa - wyposa-enie karetek pogotowia w specjalistyczny sprz"tinformuj!cy personel szpitala o bie-!cym stanie zdrowia pacjenta

• e-nauczanie - dodatkowa mo-liwo%# szkolenia lekarzy oraz personelu medycznego

Page 21: Rafał Petryniak - Praca magisterska

17

II. Cz&(% praktyczna

W cz"%ci praktycznej zostanie przedstawiony autorski system wspomagaj!cego lekarzaw diagnozowaniu na podstawie dostarczonych zdj"# medycznych.

Rozdzia' 6. Koncepcja systemu

Lekarz za pomoc! komputera pod$!czonego do Internetu komunikuje si" z systememInterMed. Dzi"ki dostarczonemu przez system interfejsowi ma on mo-liwo%# przegl!danialisty dost"pnych bada&, dodania nowego badania, i podgl!d konkretnego badania. Mo-eró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 formakomunikacji 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 informacjeo badaniu oraz zdj"cia diagnostyczne.

Wspólnym medium komunikacyjnym jest Internet. To dzi"ki niemu realizowana jestkomunikacja pomi"dzy lekarzem i konsultantem, oraz pacjentem.

Rysunek 6.1. Koncepcja systemu

Page 22: Rafał Petryniak - Praca magisterska

18

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$adnieproblemu, który ma rozwi!za#, to jest ma$o prawdopodobne, -e znajdzie u-ytecznerozwi!zanie. Je-eli klient, dla którego jest przeznaczone oprogramowanie, nie zostaniewys$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 specyficzne9$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 systemwspomagaj!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 konsultujejego badanie.

Pacjent

Osoba, dla której zosta$o przeprowadzone badanie.

Page 23: Rafał Petryniak - Praca magisterska

19

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 niegodo$!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 dosystemu.

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 zadanychkryteriów.

Page 24: Rafał Petryniak - Praca magisterska

20

E-W

Skrót od Ekranu Wyszukiwania.

Ekran Konsultacji

Cz"%# systemu InterMed, która daje mo-liwo%# wymieniania komunikatów pomi"dzylekarzem, 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).

Page 25: Rafał Petryniak - Praca magisterska

21

7.2. Modele systemu

Model jest to pewna koncepcja, pierwowzór systemu zapisany za pomoc! obiektówgraficznych, prostych kszta$tów oraz schematów blokowych. Dzi"ki temu mo-e by# onanalizowany nie tylko przez twórców systemu (firm" informatyczn!), ale równie- mo-e9$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 systemuInterMed.

Rysunek 7.1. Model przep'ywu informacji

Page 26: Rafał Petryniak - Praca magisterska

22

'Nowe badanie' jest zdarzeniem, które zapocz!tkowuje proces 'Zapis informacji

o badaniu'. Proces ten jest wspomagany przez stron" WWW. Danymi wej%ciowymi dla tegoprocesu s! zdj"cia DICOM oraz zdj"cia obj"to%ciowe. Cel jaki osi!gamy w wyniku tegoprocesu, 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 doinnego lekarza. 'Pro ba o konsultacj!' jest równocze%nie zdarzeniem wywo$uj!cymnast"pny proces: 'Konsultowanie badania', który podobnie jak proces g$ówny ('Zapisinformacji 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 klientaz systemem.

Page 27: Rafał Petryniak - Praca magisterska

23

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ówdo pacjenta.

• Szkielet systemu b"dzie obs$ugiwa$ kartotek" bada& (dodawanie, usuwanie,przegl!danie bada&). Modu$ ten spaja wszystkie modu$y w jeden zintegrowanysystem.

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órywskazuje konkretne udogodnienia oczekiwane od systemu.

W trakcie projektowania systemu InterMed skorzystano z j"zyka UML (ang. UnifiedModeling Language - Ujednolicony J"zyk Modelowania) [36]. Sk$adaj! si" na niego grupynotacji 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 dlatwórców systemu, ale równie- dla klienta.

Ca$y proces modelowania zosta$ wykonany przy pomocy narz"dzia IBM Rational SoftwareArchitect.

IBM Rational Software Architect [37] jest zintegrowanym narz"dziem projektowymi programistycznym, które umo-liwia wykorzystanie techniki programowaniamodelowego w j"zyku UML do opracowywania dobrze zaprojektowanych aplikacji ius$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%ciokre%lono czego u-ytkownicy i klienci mog! oczekiwa# od systemu. W tym celuwykorzystano nast"puj!ce techniki j"zyka UML:

• Przypadki u)ycia systemu - opisuj! w jaki sposób konkretni Aktorzy (nazwa8-ytkownika w notacji UML) komunikuj! si" z systemem. Prezentuj! one równie-podstawow! funkcjonalno%# systemu istotn! z punktu widzenia klienta/u-ytkownika.

• Diagram czynno(ci - przedstawia przep$yw czynno%ci w trakcie korzystaniaz systemu InterMed. Ukazuje on w jakie interakcje wchodz! dzia$ania u-ytkownikówi dzia$ania systemu. Dzi"ki temu diagramowi uwidoczniony zosta$ kontekst dlaprzypadków u-ycia.

Page 28: Rafał Petryniak - Praca magisterska

24

Podczas analizowania wymaga& zosta$ po$/-ony szczególny nacisk na interakcje pomi"dzykonkretnymi osobami, a systemem. Pomi"dzy g$ównymi Aktorami systemu - Lekarzem

i Konsultantem - równie- zachodz! interakcje, co zosta$o przedstawione na poni-szymdiagramie:

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 przedstawionekluczowe przypadki u-ycia zachodz!ce w systemie i pogrupowane wed$ug tzw. ekranów,w których s! one dost"pne.

Page 29: Rafał Petryniak - Praca magisterska

25

Rysunek 7.4. Kluczowe przypadki u)ycia

Na podstawie diagramów przypadków u-ycia widzimy, -e Lekarz ma mo-liwo%# mi"dzyinnymi: zalogowania si", dodania nowego badania, wys$ania pro%by o konsultacj" do innegoLekarza itd. Natomiast Konsultant w sytuacji konsultowania badania innego Lekarza posiada

Page 30: Rafał Petryniak - Praca magisterska

26

prawa odczytu dla tego badania (podgl!d zdj"# medycznych, odczyt diagnozy Lekarza) orazmo-liwo%# wys$ania odpowiedzi (swojej diagnozy).

Dla kluczowych przypadków u-ycia zosta$ zaprojektowany diagram czynno%ci. Pozwala onzorientowa# si" jaka mo-e by# kolejno%# wykonywania operacji przez u-ytkownika podczaspracy z systemem.

Page 31: Rafał Petryniak - Praca magisterska

27

Rysunek 7.5. Diagram czynno(ci dla kluczowych funkcji systemu

Page 32: Rafał Petryniak - Praca magisterska

28

7.4. Analiza wymaga+ niefunkcjonalnych

Wymagania niefunkcjonalne nie dotycz! bezpo%rednio konkretnych funkcji systemu.Wprowadzaj! raczej ograniczenia na system oraz specyfikuj! warunki u-ytkowaniaposzczegó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 zastosowaniaszczególnych %rodków bezpiecze&stwa. Z jednej strony wymaga tego prawo o ochroniedanych osobowych, a z drugiej strony niepewny system nigdy nie zdob"dzie zaufania8-ytkownika.

Poni-ej wypisano wymagania stawiane bezpiecze&stwu systemu InterMed.

CECHA WERYFIKOWALNY WYMIAR

Bezpieczne przechowywanie hase$Has$a przechowywane w baziewy$!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"tuoraz infrastruktury sieciowej. Najwa-niejsze z punktu widzenia u-ytkownika jest to, -ewystarczy mu %redniej klasy komputer z dost"pem do Internetu oraz zainstalowanymogólnodost"pnym oprogramowaniem (przegl!darka WWW). Z punktu widzenia systemukluczow! rol" b"dzie mia$o zagwarantowanie du-ej przestrzeni dyskowej w bazie danychoraz szybki Internet.

Rysunek 7.6. Wymagania sprz&towe

Page 33: Rafał Petryniak - Praca magisterska

29

Szczegó$owo wymagania sprz"towe zosta$y zebrane w poni-szej tabeli:

CECHA WERYFIKOWALNY WYMIAR

Serwer bazy danych Umo-liwiaj!cy przechowywanie danych binarnych (zdj"cia)

Serwer aplikacjiLiczba klientów internetowych komunikuj!ca si"jednocze%nie z serwerem: nieograniczona

Urz!dzenia wej%cia (dlaLekarza i Odbiorcy)

Klawiatura, mysz

Urz!dzenia wyj%cia (dlaLekarza i Odbiorcy)

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" tutajwytyczne i warunki jakie powinny zosta# spe$nione w celu uzyskania optymalnej pracyca$ego oprogramowania. W miar" mo-liwo%ci zosta$y one zapisane ilo%ciowo, co pozwoli najednoznaczn! ich interpretacj" oraz umo-liwi przeprowadzenie testów wydajno%ciowych.

CECHA WERYFIKOWALNY WYMIAR

InternetPr"dko%# transmisji danych po stronie klienta internetowego: (zalecanemin. 100 kB)

Przegl!darkaWWW

Przegl!darki preferowane: IE 5.0, Firefox 1.07- lub nowsze wersje

Format zdj"# (zbiórwej%ciowy)

1. Zdj"cia w formacie DICOM2. Zdj"cia obi"to%ciowe (format nieustandaryzowany)

RozmiarWymagana pojemno%# dyskowa serwera bazy danych: 1TBLiczba rekordów w bazie: nieograniczona

Wydajno%#

Czas odpowiedzi na -!danie zalogowania do systemu: 1sekCzas odpowiedzi na otwarcie przegl!darki: czas przes$ania 1MB xrozmiar pobieranych danychCzas pobierania zdj"# medycznych na komputer klienta: czasprzesy$ania 1MB x rozmiar pobieranych danych

Przenaszalno%#

Platforma docelowa: system niezale-ny od platformy% kodu zale-nego od platformy docelowej: - z punktu widzeniaLekarza/Odbiorcy: 0% kodu zale-nego - z punktu widzeniasystemu/Administratora: 5% kodu zale-nego od bazy danych

*atwo%#8-ytkowania

Czas niezb"dny do przeszkolenia Lekarza: 1-2 godzinyCzas niezb"dny do przeszkolenia Konsultanta: 0.5 godzinyCzas niezb"dny do przeszkolenia Administratora: 3godziny

Tabela 7.3. Pozosta'e wymagania dot. systemu 3DVS

Page 34: Rafał Petryniak - Praca magisterska

30

Rozdzia' 8. Projekt i wykonanie systemu

8.1. Modelowanie zachowa+ systemu

Na etapie przygotowywania projektu równie- zosta$a wykorzystana notacja UML. Jednakw tym wypadku powsta$e modele s! bardziej szczegó$owe od modeli wykonanych w trakcieanalizy 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-yciasystemu.

• Diagramy komunikacji.

Pokazuj! po$!czenia i interakcje mi"dzy obiektami.

• Diagramy pakietów,

Przedstawiaj! w ogólnym %wietle organizacj" oprogramowania. Diagramy pakietówstanowi! 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 umieszczonaw za$!cznikach w formie elektronicznej.

Przyk$adowy diagram klas odpowiadaj!cy przypadkowi u-ycia „Dodaj badanie” wygl!danast"puj!co:

Page 35: Rafał Petryniak - Praca magisterska

31

Rysunek 8.1. Diagram klas dla przypadku u)ycia 'Dodaj badanie'

Lekarz uzupe$nia w przegl!darce internetowej formularz nowego badania (formularz badaniajest reprezentowany przez klas" ekranNowegoBadania). Z rozwijanej listy wybiera pacjenta(odpowiedzialna jest za to metoda wyswietlListePacjentów() ). Po zatwierdzeniu nowegobadania (metoda dodajBadanie() ) informacje z formularza s! pobierane, sprawdzanei zapisywane w bazie (ta cz"%# jest realizowana przez klas" noweBadanieCTR). Baza jestreprezentowana przez klas" badanieDB.

Poni-szy diagram sekwencji szczegó$owo obrazuje kolejno%# przep$ywu komunikatóww czasie dla przypadku u-ycia „Dodaj badanie”. Formularz wype$niony przez lekarza, posprawdzeniu (akcja: sprawdzFormularzNB) przez obiekt kontrolny noweBadanieCTR mo-eokaza# si" b$"dnie uzupe$niony. Spowoduje to wys$anie informacji zwrotnej do lekarzaz pro%7! o podanie poprawnych danych (akcja: infoPoprawFormularz). Natomiast gdysystem nie b"dzie mia$ zastrze-<& nowe badanie zostanie zapisane w bazie danych (akcja:dodajBadanie).

Page 36: Rafał Petryniak - Praca magisterska

32

Rysunek 8.2. Diagram sekwencji dla przypadku u)ycia 'Dodaj badanie'

Na podstawie diagramu sekwencji zosta$ utworzony diagram komunikacji, który informujeo interakcjach i po$!czeniach poszczególnych obiektów.

Page 37: Rafał Petryniak - Praca magisterska

33

Rysunek 8.3. Diagram komunikacji dla przypadku u)ycia 'Dodaj badanie'

Zaprojektowany diagram pakietów dla systemu pokazuje powi!zania i logiczne przej%ciapomi"dzy poszczególnymi ekranami. Pakiety reprezentuj! funkcje okre%lone dla ró-nychobszaró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 nowegobadania), 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. Nadiagramie jednak nie zosta$y umieszczone te po$!czenia poniewa- rysunek straci$by wtedyprzejrzysto%#.

Page 38: Rafał Petryniak - Praca magisterska

34

Rysunek 8.4. Diagram pakietów

W kolejnym etapie modelowania zachowa& systemu zosta$ przygotowany diagram wdro-enia.

Page 39: Rafał Petryniak - Praca magisterska

35

Rysunek 8.5. Diagram wdro)enia

Przedstawia on w"=$y systemu (stacje robocze, serwery), na których s! wdro-oneposzczególne artefakty, czyli elementy aplikacji InterMed (baza danych, aplikacjainternetowa). Na serwerze (lub serwerach) s! zainstalowane i skonfigurowane: aplikacja orazbaza 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 natomiastkomunikuje si" z systemem poprzez komputer osobisty.

Diagramy UML s! bardzo cz"sto stosowane do dokumentowania wykonanego systemu. Ichpodstawow! zalet! jest to, -e pozwalaj! na ogólne zrozumienie oprogramowania bez potrzebyanalizowania kodu.

8.2. Projekt bazy danych

Zaprojektowanie poprawnej struktury danych jest jednym z najwa-niejszych czynnikówdecyduj!cych o powodzeniu przedsi"wzi"cia. To od niej w du-ej mierze zale-yimplementacja 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].

Page 40: Rafał Petryniak - Praca magisterska

36

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. Potrafion integrowa# si" z ró-nymi bazami danych (MySQL, Oracle) i dzi"ki intuicyjnemuinterfejsowi 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 niemuzosta$ 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%# ichuaktualnienia, jednak-e system w podstawowej wersji nie b"dzie posiada$ takiejfunkcjonalno%ci). Kolejne dwie tabele: badanie i diagnoza, b"2! bardzo aktywnie u-ywaneprzez system. To w$3%nie one zawieraj! wszystkie informacje o badaniu (tabela badanie)oraz wystawionych diagnozach (tabela diagnoza).

Page 41: Rafał Petryniak - Praca magisterska

37

W bazie danych nie b"2! przechowywane zdj"cia medyczne, zostan! one umieszczone nadysku 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 lekarzy-

konsultantów)

8.3. Projekt interfejsu u)ytkownika

Zadowolenie klienta jest jednym z najwa-niejszych czynników decyduj!cych o powodzeniusystemu. Nawet najlepszy projekt informatyczny mo-e zako&czy# si" pora->!, je%li jego8-ytkownicy nie b"2! chcieli z niego korzysta#. Wielu ludzi w zetkni"ciu z komputeremdoznaje takiego szoku, -e zaczynaj! unika# wszelkiego rodzaju systemów informatycznych[9]. Dlatego ten w$3%nie etap tworzenia aplikacji powinien zosta# szczególnie dok$adnieomówiony z u-ytkownikami systemu.

Podczas przygotowania projektu interfejsu u-ytkownika szczególny nacisk zosta$ po$/-ony naprostot" 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 (patrzponi-ej), z których ka-da ma %ci%le okre%lon! funkcj".

Rysunek 8.7. Projekt interfejsu

Page 42: Rafał Petryniak - Praca magisterska

38

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 CommonsLicenses 2.0. Je%li system InterMed b"dzie wykorzystywany komercyjnie nale-yzmieni# 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 orazKomunikacja. Jeden cykl, podczas którego dla jednego modu$u zosta$y sprecyzowanewymagania, powsta$ projekt i implementacja, a tak-e przeprowadzono testy stanowi$ iteracj!.

Pierwsz! czynno%ci! by$o zebranie wymaga& stawianych systemowi, po czym zosta$y onepoddane szczegó$owej analizie. Nast"pnie w pe$nym cyklu projektowania, kodowania

Page 43: Rafał Petryniak - Praca magisterska

39

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$ywykonane pozosta$e cz"%ci systemu, dodaj!c tym samym nowe mo-liwo%ci do ju-istniej!cego szkieletu. Warto zauwa-;#, -e po ka-dej sko&czonej iteracji aplikacja dzia$3$apoprawnie 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 gruntowneprzemy%lenie architektury oprogramowania. Powinna by# ona elastyczna i dawa# mo-liwo%#do$!czania kolejnych funkcjonalno%ci. Poza tym, technika ta pozwala na wczesne wykryciezagro-<& (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$aniasystemu. W tym wypadku zosta$ zastosowany model V wytwarzania oprogramowania, któryjest nakierowany na ci!4$! weryfikacj" i walidacj" wykonanych czynno%ci. System InterMedjest z$/-ony z modu$ów, w sk$ad których wchodz! procedury i funkcje. Testowanie powinnosi" zatem odbywa# w wielu krokach, wraz z przyrastaj!cym kodem.

Page 44: Rafał Petryniak - Praca magisterska

40

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 lubprojekcie.

8.5. Opis poszczególnych modu'ów systemu

System InterMed zosta$ rozdzielony na kilka modu$ów, z których ka-dy realizuje %ci%leokre%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 Komunikacjasystem jest w stanie dalej spe$nia# swoje podstawowe funkcje. Zapewnia to Szkieletusystemu, który jest niezb"dny do funkcjonowania aplikacji.

Rysunek 8.10. Dekompozycja systemu

Page 45: Rafał Petryniak - Praca magisterska

41

Modu$owa budowa systemu i uzyskana w ten sposób du-a niezale-no%# poszczególnychmodu$ów jest równie- korzystna z punktu widzenia u-ytkownika, który mo-e samzdecydowa# 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 niegowcze%niej zdefiniowany skrót kategorii. Nast"pnie w cz"%ci dynamicznej witryny otwieranajest -!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 zosta! zaimplementowanyz zastosowaniem technologii JavaBeans („ziarenek Javy”).

W momencie próby zalogowania do systemu tworzone jest ziarenko Javy logbean, po czymuruchamiana 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 danegolekarza. W przeciwnym wypadku system wy%wietla komunikat o braku uprawnie' dosystemu.

Page 46: Rafał Petryniak - Praca magisterska

42

Lista w!(%ciwo%ci ziarenka logbean oraz odpowiadaj ce im w!(%ciwo%ci:

username

setUsername()

getUsername()

password

setPassword()

getPassword()

imie

setImie()

getImie()

nazwisko

setNazwisko()

getNazwisko()

instytucja

setInstytucja

getInstytucja

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'.

Page 47: Rafał Petryniak - Praca magisterska

43

Aby korzysta& z puli po! cze', zosta!y zdefiniowane dwie klasy: jedna z nich reprezentujepo! 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 pulikonieczny 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 tymnazw" u$ytkownika oraz has!o.

Page 48: Rafał Petryniak - Praca magisterska

44

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 dodanienowego badania, przegl danie istniej cej listy bada', a tak$e wyszukiwanie interesuj cych gobada'. W prawym górny rogu ekranu znajduj si" informacje o aktualnie zalogowanym#$ytkowniku (imi", nazwisko, jednostka).

Rysunek 8.12. Strona g!ówna (powitalna)

Page 49: Rafał Petryniak - Praca magisterska

45

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" . Wyskakuje wówczas oknopomocy opisuj ce poszczególne pola formularza.

Page 50: Rafał Petryniak - Praca magisterska

46

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 formularzunowego badania.

Na dole ekranu znajduje si" formularz umo$liwiaj cy dodanie zdj"& z badania zapisanychzarówno w formacie DICOM, jak równie$ zdj"cia obj"to%ciowe. W tym celu lekarz musiwskaza& odpowiednie pliki znajduj ce si" na dysku twardym komputera, z którego korzystai nacisn & przycisk 'Za aduj'. Po za!adowaniu zdj"& medycznych system umo$liwianast"puj ce operacje:

• przegl danie

Przegl danie zdj"& odbywa si" dzi"ki wbudowanym w system przegl darkom DICOMi 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 dodatkowegooprogramowania.

• usuni"cie

Po usuni"ciu zdj"& medycznych wy%wietlany jest ponownie formularz dodawaniaplików.

Page 51: Rafał Petryniak - Praca magisterska

47

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 pozwalaj cy nawysy!anie pro%by o konsultacje do innego lekarza.

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 pozwoliustrzec u$ytkownika przed przypadkowym skasowaniem wa$nych danych (patrz rysunekponi$ej).

Page 52: Rafał Petryniak - Praca magisterska

48

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'. Powybraniu tej opcji, na ekranie pojawi si" lista wszystkich bada' nale$ cych do zalogowanegolekarza, 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.

Page 53: Rafał Petryniak - Praca magisterska

49

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 formularzpozwalaj cy na szczegó!owe przeszukiwanie kartoteki bada'. Dost"pnymi kryteriamiwyszukiwania 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"dnianew trakcie wyszukiwania.

Page 54: Rafał Petryniak - Praca magisterska

50

Rysunek 8.19. Wyszukiwanie bada"

Page 55: Rafał Petryniak - Praca magisterska

51

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!ydodane przez lekarza podczas wpisywania nowego badania.

8.5.2.1. Projekt techniczny

Modu! DICOM zosta! opracowany na podstawie projektu Open Source rozwijanego przezNagoya Institute of Technology, Iwata laboratory and Takahiro Katoji [39].

Do jego implementacji zosta!a wykorzystana technologia Java Applet [40], s!#$ ca przedewszystkim do tworzenia aplikacji uruchamianych w oknie przegl darki.

Integracja modu!u DICOM ze Szkieletem Systemu InterMed zosta!a przeprowadzonaz wykorzystaniem znacznika <APPLET> dost"pnego w specyfikacji HTML. Dzi"kidodatkowym parametrom konfiguracyjnym tego znacznika, mo$na okre%li& sposóbwy%wietlania przegl darki DICOM i wybra& jakie dane zostan za!adowane.

Page 56: Rafał Petryniak - Praca magisterska

52

Przyk!adowa konfiguracja zosta!a przedstawiona poni$ej:

<APPLET CODE = "dicomviewer.Viewer.class" NAME = "Viewer.java" WIDTH = 100% HEIGHT = 100% HSPACE = 0 VSPACE = 0 ALIGN = middle> <PARAM NAME = "imgURL0" VALUE = "FX01556\badanieCT.dcm"></APPLET>

8.5.2.2. Opis funkcjonalno#ci

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"pnytryb 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

Page 57: Rafał Petryniak - Praca magisterska

53

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$emydo nich zaliczy& kontrast, regulacj" jasno%ci oraz negatyw. Przyk!ady dzia!ania tych filtrówzosta!y przedstawione poni$ej.

Rysunek 8.23. Modu! DICOM – filtry(1)

Page 58: Rafał Petryniak - Praca magisterska

54

Rysunek 8.24. Modu! DICOM – filtry(2)

Zastosowanie filtrów dla obrazów medycznych mo$e znacznie wspomóc procesdiagnozowania. Z jednej strony s!#$ one do usuni"cia zb"dnych szczegó!ów, a z drugiejstrony pomagaj wzmocni& pewne elementy obrazu, które co prawda istniej , ale s s!abowidoczne [15].

8.5.3. Modu! Wizualizacja

Modu! wizualizacja umo$liwia sk!adowanie i przegl danie zdj"& obj"to%ciowych.

8.5.3.1. Projekt techniczny

Do opracowania modu!u Wizualizacja zosta! u$yty projekt JIV: A 3D Image DataVisualization and Comparison Tool [41] dost"pny jako Open Source.

Modu! Wizualizacja, podobnie jak Modu! DICOM, zosta! wykonany w technologii JavaApplet [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 odpowiednioskonfigurowany znacznik <APPLET> w kodzie strony html. Przyk!adow konfiguracj"przedstawiono poni$ej:

<APPLET ARCHIVE = "jiv.jar" CODE = "jiv/Main.class" NAME = "jiv_demo_3" WIDTH = 400 HEIGHT = 50> <PARAM NAME="config" value="configFile"></APPLET>

Page 59: Rafał Petryniak - Praca magisterska

55

Za pomoc parametrów tego znacznika mo$na nie tylko ustali& sposób wy%wietlaniaprzegl!darki Wizualizacja, ale równie$ wskaza& plik konfiguracyjny opisuj cy formatdanych wej%ciowych.

Poni$ej zosta!a przedstawiona zawarto%& przyk!adowego pliku konfiguracyjnegoconfigFile:

jiv.panel.0 : colin27

colin27 : colin27.raw_byte.gzcolin27.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órychwymagany 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 zaproponowanyprzez Montréal Neurological Institute, McGill University [42]. Czynnik ten ograniczaw du$ym stopniu system InterMed, czyni c z niego rozwi zanie o charakterze badawczym.

Przyk!adowy plik nag!ówkowy (colin27.header):

size : 181 217 181start : -90 -126 -72step : 1 1 1order : z y x

Page 60: Rafał Petryniak - Praca magisterska

56

8.5.3.2. Opis funkcjonalno#ci

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, obserwujezmieniaj cy si" obraz na pozosta!ych dwóch.

Rysunek 8.25. Modu! Wizualizacja: okno g!ówne

Page 61: Rafał Petryniak - Praca magisterska

57

Na zdj"ciach mo$na zastosowa& ró$ne filtry graficzne, co zosta!o przedstawione naponi$szych rysunkach:

Zmiana koloru i nasycenia Segmentacja obrazu

Tabela 8.1. Filtry graficzne

8.5.4. Modu! Komunikacja

8.5.4.1. Projekt techniczny

Modu! Komunikacja zosta! wykonany w tej samej technologii co Szkielet Systemu i w du$ymstopniu 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 automatycznieuzupe!nione przez system.

Page 62: Rafał Petryniak - Praca magisterska

58

Przyk!ad 8.2. Przyk!ad u&ycia znacznika mailto

mailto:[email protected]?subject=Wyniki%20bada%C5%84&amp;body=tekst,%20tekst,%20tekst,%20tekst

8.5.4.2. Opis funkcjonalno#ci

8.5.4.2.1. Konsultacje z innymi lekarzami

Ka$de badanie zapisane w systemie InterMed mo$e zosta& skonsultowane z innymilekarzami. 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 wybieralekarza z listy oraz wpisuje krótk informacj" do adresata wiadomo%ci.

Lekarz, który zosta! poproszony o konsultacj", po zalogowaniu do systemu InterMed jestpowiadamiany o tym fakcie w postaci informacji w prawym górnym rogu ekranu. Klikaj cw link mo$e przeczyta&, kto jest nadawc oraz zapozna& si" z tre%ci wiadomo%ci. Na tejstronie znajduje si" formularz odpowiedzi, gdzie lekarz mo$e wpisa& w!asn diagnoz", jakrównie$ przycisk umo$liwiaj cy obejrzenie badania.

Rysunek 8.26. Ekran konsultacji

Page 63: Rafał Petryniak - Praca magisterska

59

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 adresatwiadomo%ci (adres email pacjenta) oraz uzupe!niona tre%& wiadomo%ci. Lekarz oczywi%ciemo$e edytowa& te informacje lub dopisa& dodatkowy komentarz, np. propozycj" kolejnejwizyty.

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"dzii 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 wariantyzosta!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 OpenSource. Dzi"ki swojej wydajno%ci, szybko%ci dzia!ania i rozbudowanymmechanizmom 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 SoftwareFundation. Umo$liwia uruchamianie aplikacji internetowych w technologiach JavaServlets i JSP (Java Server Pages).

Sposób instalacji i konfiguracji powy$szych narz"dzi jest dost"pny na stronach domowychtych projektów.

Page 64: Rafał Petryniak - Praca magisterska

60

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 bazydanych.

8.6.3.1.2. Tworzenie struktury tabel

W bazie danych tworzona jest struktura tabel, w których b"- przechowywane dane. Skrypttworz 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 \Tomcat5.5\webapps\InterMed\WEB-INF\classes\foo\Connection.properties.

Przyk!adowa konfiguracja zosta!a przedstawiona poni$ej:

HostName = localhostSID = rpetryniakPort = 3306UserName = userPassword = 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 kontnowym u$ytkownikow (lekarzom) oraz dodawanie pacjentów do kartoteki. Czynno%ci tewykonywa!by przy pomocy specjalnie przygotowanych skryptów SQL.

Page 65: Rafał Petryniak - Praca magisterska

61

Rozdzia! 9. Próba wizualizacji przestrzennej obrazu

Tematem tej pracy magisterskiej jest system informacyjny wspomagaj cy lekarzaw diagnozowaniu na podstawie obrazów medycznych. Pocz tkowo, nieodzowne wydawa!osi" zrealizowanie podsystemu wizualizacji trójwymiarowej, który dla serii p!askich obrazówmedycznych 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 wielealgorytmów oraz narz"dzi informatycznych, które pozwalaj osi gn & ten efekt. Niektórez nich przystosowane s tak$e do pracy w sieci Internet. Ju$ teraz znajduj one zastosowaniem.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 cetak mo$liwo%& zosta!y opisane poni$ej.

Flash

Jest wykorzystywany g!ównie do animacji obiektów p!askich zapisanych w postaciwektorowej. Dzi"ki bardzo !atwej integracji z j"zykiem HTML, sta! si" nieodzownymelementem multimedialnych witryn WWW.

http://www.adobe.com/products/flash/

Java3D

Jest to rozszerzenie j"zyka Java, które pozwala na generowanie obiektówtrójwymiarowych. Bazuje na bibliotece OpenGL. Do uruchomienia wymagazainstalowanego %rodowiska Java.

http://java.sun.com/products/java-media/3D/

VRML/X3D

VRML (z ang. Virtual Reality Modeling Language) to j"zyk modelowania wirtualnejrzeczywisto%ci trójwymiarowej [11].

Jego nast"pca X3D zosta! poddany standaryzacji przez konsorcjum ISO (InternationalOrganization for Standardization).

http://www.web3d.org/

Page 66: Rafał Petryniak - Praca magisterska

62

Technologi , jaka zosta!a wybrana do wizualizacji by! X3D. Ten niezalezny od platformyformat, 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 zapisuplików w formacie XML jest wielkim atutem, gdy$ mog one by& odczytywane przez wieleprogramó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$(!oodpowiednio 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%& wyznaczeniakonturów na analizowanym obrazie. Wi"kszo%& z nich jest ogólnie dost"pna (licencja OpenSource), jednak$e na przyk!adzie programu Corel PHOTO-PAINT zosta!a sprawdzonafunkcjonalno%& 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 wykrywaniakraw"dzi zosta#a przedstawiona w za#$czniku w formie elektronicznej.

Proces wyodr"bnienia konturu z obrazu polega# na zastosowaniu kilku nast"puj$cych po sobiefiltrów graficznych. Ich w#%!ciwy wybór oraz kolejno!& stosowania pozwoli#y uzyska&oczekiwany rezultat.

Page 67: Rafał Petryniak - Praca magisterska

63

ImageJ

rys 0. Obraz wej!ciowy

rys 1. Negatyw

rys 2. Filtr: Binaryzacja (Threshold)

Page 68: Rafał Petryniak - Praca magisterska

64

ImageJ

rys 3. Filtr: Szukanie kraw"dzi (FindEdges)

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 jaknajwi"ksz$ staranno!ci$.

9.2.2. Wyznaczanie wspó!rz dnych

Kolejnym krokiem by#o wyznaczenie wspó#rz"dnych konturu. Poniewa zazwyczaj ka daseria obrazów ma inne wymiary (d#ugo!&, szeroko!&) dlatego konieczne by#o odpowiednieprzeskalowanie tych obrazów.

Poni ej zosta#a przedstawiona implementacja algorytmu wyznaczaj$cego po#' enie punktówkonturu i skaluj$cego obraz:

//zbiór punktówSet spoint = new HashSet();

int xx,yy;int width = bimage.getWidth( null );int height = bimage.getHeight( null );

Page 69: Rafał Petryniak - Praca magisterska

65

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) && (gpixel<100) &&(bpixel<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óryzapisywany 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!cianalizowanego obrazu podczas generowania wizualizacji.

Page 70: Rafał Petryniak - Praca magisterska

66

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óremo na opisa& za pomoc$ wzorów. Posiada ona równie mechanizmy wizualizacji obiektówo 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>

Page 71: Rafał Petryniak - Praca magisterska

67

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 blisko25 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 X3D 3.1//EN""http://www.web3d.org/specifications/x3d-3.1.dtd">

<X3D version="3.1" profile="Immersive" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.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.450.01, 0.05 0.54 0.01, 0.21 0.56, "/> <Color color="1 1 1 "/>

</PointSet> </Shape> </Scene></X3D>

Page 72: Rafał Petryniak - Praca magisterska

68

Problemem okaza#o si" odtworzenie tych wizualizacji za pomoc$ dost"pnych przegl$darekVRML/X3D.

Uwagi:

Opis i porównanie przegl$darek VRML/X3D zamieszczono w za#$cznikuw 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óbyzastosowania wybranej technologii (X3D), by#a konieczno!& podania wszystkich wielok$tówwype#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 pracymagisterskiej. Dlatego do opracowania modu u Wizualizacja wykorzystano gotowekomponenty informatyczne, które oferowa#y oczekiwan$ funkcjonalno!&.

Page 73: Rafał Petryniak - Praca magisterska

69

Rozdzia! 10. Perspektywy zastosowania i rozwoju systemu

Okazuje si", e istnieje kilka sposobów wdro enia systemu: mo e on funkcjonowa& zarównojako us#uga zewn"trzna udost"pniana/sprzedawana klientowi, jaki i zosta& bezpo!redniozainstalowany na komputerze klienta. Ka da z tych opcji ma swoje zalety i wady.

Wiadomo, e warto!& narz"dzia informatycznego wzrasta, gdy istnieje mo liwo!& jegointegracji z innymi narz"dziami informatycznymi. Architektura mojego systemu mo epozwoli& 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" najednym komputerze-serwerze. Jest to bardzo wygodne rozwi$zanie które pozwala na #atwezarz$dzanie i utrzymanie systemu. Daje ono równie swobod" dopasowania systemu dospecyfiki 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 aplikacjamiinformatycznymi, które pozwala klientowi skupi& si" na istocie problemu, przenosz$codpowiedzialno!& utrzymania systemu na dostawc .

Wady i zalety takiego podej!cia zestawiono poni ej.

Z punktu widzenia klienta Z punktu widzenia dostawcy

Zalety

Utrzymanie sytemu przez specjalistów tworz$cychsystem, którzy najlepiej wiedz$ jak nim zarz$dza&+ ytkownik nie ponosi kosztów zwi$zanych zzakupem dodatkowego sprz"tuZarz$dzanie danymi po stronie us#ugodawcy (np.kopie bezpiecze)stwa)Korzystanie z us#ugi wtedy kiedy jest rzeczywi!ciepotrzebna

Mo liwo!& usprawnienia pracysystemu bez wiedzy klienta

,atwo!& utrzymania sytemu(instalacja w jednym miejscu)

Wady

Konieczno!& posiadania szybkiego #$czainternetowegoWi"ksze opó-nienie w dost"pie do danych

Odpowiedzialno!& za dane wieluklientówDu e wymagania sprz"towe(sie&, dyski)Potrzeba zatrudnienia osóbdbaj$cych o poprawn$ prac"systemu

Tabela 10.1. System jako us!uga zewn trzna z punktu widzenia klienta i dostawcy –

porównanie

Page 74: Rafał Petryniak - Praca magisterska

70

10.1.2. System u klienta

System mo e by& równie zainstalowany na sprz"cie klienta i w takim przypadku to w#%!niena 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 nowejfunkcjonalno!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 Nie wymagana dodatkowa infrastruktura

Wady

Zakup infrastrukturyPotrzebna osoba dbaj$ca osystem

Instalacja i serwis u wielu klientów w wielumiejscach

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 architekturzezamkni"tej. Nie #$czy si" on z innymi systemami szpitala (lub innej instytucji) w celu pobranaz nich informacji lub zapisu wyników, co uniemo liwia wykorzystanie informacji w nimzgromadzonych 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 uczynieniaz niego narz"dzia znajduj$cego zastosowanie we wspó#czesnych systemach informatycznychszpitala.

10.2.1. Obrazy pobierane z systemu PACS

W chwili obecnej operator za pomoc$ specjalnego formularza #aduje zdj"cia medyczne naserwer, gdzie s$ umieszczane w strukturze katalogów. Czynno!& ta zwi$zana jest oczywi!ciez dodatkow$ prac$ i jest podatna na ró ne b#"dy (brak / niekompletno!& danych). Sam faktprzechowywania danych obrazowych pacjenta na serwerze dost"pnym w Internecie mo ebudzi& obawy zwi$zane z bezpiecze)stwem i równie wymaga dodatkowych zabiegówadministracyjnych.

Integracja systemu InterMed z systemem PACS szpitala pozwoli#aby zniwelowa& te problemyi zwolni#aby z systemu obowi$zek archiwizacji danych medycznych. Integracja taka powinnazosta& wykonana z zachowaniem istniej$cych standardów (DICOM), aby system InterMedmóg# wspó#dzia#%& z dowolnym systemem PACS.

Propozycja architektury systemu uwzgl"dniaj$cej opisane zmiany zosta#a zamieszczona naponi szym diagramie.

Page 75: Rafał Petryniak - Praca magisterska

71

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 nymograniczeniem, które z jednej strony wymusza wprowadzenie wszystkich informacjiw systemie (np. dane pacjenta) i z drugiej strony nie pozwala na wykorzystanie tychinformacji 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

Page 76: Rafał Petryniak - Praca magisterska

72

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 lekarzajest 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$ nietylko prowadzenie dyskusji w czasie rzeczywistym, ale równie daj$ mo liwo!& wizualnegoprzedstawienia 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 usprawnieniai integracje systemu InterMed.

Page 77: Rafał Petryniak - Praca magisterska

73

11. Zako#czenie

11.1. Podsumowanie

System informatyczny zrealizowany w ramach tej pracy magisterskiej jest projekteminnowacyjnym. Dzi"ki zastosowaniu nowoczesnych technologii zwi$zanych z Internetem,pozwala rozszerzy& obszar zastosowania szpitalnego systemu informacyjnego, przyczyniaj$csi" tym samym do poprawy opieki nad pacjentem i redukcji kosztów operacyjnych. Abynarz"dzie to nie pozosta#o tylko prac$ badawcz$ i zosta#o wdro one we wspó#czesnychsystemach 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&cymsi% w innym miejscu?

Na te pytania mog odpowiedzie! twierdz"co, poniewa# zaprojektowany system posiada takiemo#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 innymlekarzem 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$eniai utrzymania dla przeci%tnego szpitala?

Czynnik ten by& bardzo wa#ny w trakcie realizacji projektu i zosta& po&'#ony du#y nacisk namo#liwie niski koszt gotowego projektu. U#ycie darmowych narz dzi i aplikacji powoduje, #eprzewa#aj"ce wydatki przy wdro#eniu systemu b (" zwi"zane z zapewnieniem infrastrukturysprz 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#eby! wymaganie du#ej przestrzeni na dysku twardym komputera dla sk&adowanych danychobrazowych, oraz dost p do szybkich &"cz internetowych w celu zminimalizowania czasuoczekiwania. W obecnej chwili system InterMed nie umo#liwia integracji z innymisystemami szpitala, co ogranicza obszar jego stosowania (propozycje rozwi"zania tegoproblemu zosta&y przedstawione w rozdziale 'Perspektywy rozwoju i integracji systemu').

Page 78: Rafał Petryniak - Praca magisterska

74

11.2. Prezentacja projektu

Projekt zrealizowany w ramach pracy magisterskiej zosta& zaprezentowany przez autorapodczas 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 poruszanegoproblemu (i mo#liwe sposoby jego rozwi"zania), ale równie# zaproponowano w&asnerozwi"zanie informatyczne.

Udzia& w konferencji by& dla autora bardzo cennym do$wiadczeniem, poniewa# realizowanytemat pracy magisterskiej móg& zosta! skonfrontowany ze $rodowiskiem medycznym, dlaktórego jest dedykowany.

Page 79: Rafał Petryniak - Praca magisterska

75

11.3. Prowadzenie prac

Podczas realizacji pracy magisterskiej skorzystano z kilku technologii i rozwi"za%, którebardzo u&atwi&y prowadzenie prac .

Przyczyni&y si one w du#ym stopniu do poprawy organizacji zada% na kolejnych etapachpracy i pomog&y osi"gn"! zamierzony efekt. Poni#ej zosta&y pokrótce przedstawione niektórez nich.

11.3.1. Portal projektowy

Po wybraniu tematu pracy magisterskiej i dyskusji z promotorem na temat celu i zakresu jakimia&a by obejmowa!, autor postanowi& przygotowa! portal internetowy [54] po$wi cony jejrealizacji. 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 opracowania powsta&e na kolejnych etapachrealizacji projektu.

• Projekt

Tutaj natomiast zosta&y opisane techniczne aspekty realizacji tematu, tzn. u#ytetechnologie, 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 patronatemApache Software Fundation [46]

Umo#liwia on transformowanie dokumentów z ro#nych formatów wej$ciowychw jednolit" prezentacj w jednym lub wielu formatach wyj$ciowych. WykorzystanieXML i szablonów XSLT pozwala na ca&kowite oddzielenie struktury dokumentu odwarstwy prezentacji. Forrest mo#e generowa! statyczne dokumenty, albo zosta! u#ytyjako dynamiczny serwer umo#liwiaj"cy automatyczne publikowanie tre$ciw Internecie.

Page 80: Rafał Petryniak - Praca magisterska

76

Narz dzie to umo#liwi&o publikowanie dokumentów opracowanych w wybranym przez autorastandardzie 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! systemukontroli 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 firmykomputerowe, jednak#e zaleca si stosowanie ich wsz dzie tam gdzie wa#ne jest zarz"dzanietre$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 VersionsSystem).

Page 81: Rafał Petryniak - Praca magisterska

77

W repozytorium (miejscu sk&adowania dokumentów) zosta&y utworzone dwie strukturykatalogów, dla projektu i dla dokumentacji. Zosta&y one przedstawione na poni#szychrysunkach:

Rysunek 11.3. Repozytorium: dokumentacja

Rysunek 11.4. Repozytorium: projekt

Cechy systemu, które by&y szczególne przydatne dla autora podczas realizacji pracymagisterskiej:

1. Centralne sk&adowanie wszystkich dokumentów

Znacznie poprawi&o bezpiecze%stwo pracy, jednoczenie znosz"c obowi"zek ci",&ejarchiwizacji kolejnych wersji.

2. Dost p do ka#dej poprzedniej wersji

Umo#liwi&o podgl"d historii zmian, a tak#e w szczególnych przypadkach ichanulowanie.

Page 82: Rafał Petryniak - Praca magisterska

78

Dzi ki zaawansowanym mechanizmom porównywania plików mo#na by&o w ka#dej chwilidowiedzie! si np. która zmiana spowodowa&a b&"d wy$wietlania fragmentu dokumentacji lubjaka 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 opracowanew ustandaryzowanym formacie dokumentacji technicznej DocBook.

DocBook [50] jest standardem dokumentacji technicznej, opracowywanym przezorganizacj OASIS (The Organization for the Advancement of Structured InformationStandards) [49], która równie# rozwija inne znane standardy takie jak np.OpenDocument. Jest to j zyk $ci$le zdefiniowanych znaczników XML (dawniejrównie# SGML) opisuj"cych struktur dokumentu. Dzi ki dost pno$ci wielugotowych szablonów transformacji (XSLT) istnieje mo#liwo$! wygenerowaniadokumentó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 jegowygl"dzie. Za pomoc" dost pnych znaczników XML zdefiniowano co dany tekst oznaczai jaka jest jego funkcja w strukturze dokumentu.

Page 83: Rafał Petryniak - Praca magisterska

79

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 systemwspomagaj#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 orazprogramu edycyjnego. W ka#dym momencie mo#na otworzy! dokument w dowolnymedytorze tekstu i wprowadzi! poprawki. Cz sto korzystano jednak z ogólnodost pnegoprogramu XMLMind (XMLmind XML Editor Standard Edition) [51], który dba& o poprawnekorzystanie ze standardu Docbook i umo#liwia& wygodn" prac w trybie WYSIWYG.

Dzi ki temu, #e dokumenty s" zapisywane w postaci tekstowej mo#na nimi swobodniezarz"dza! przechowuj"c je w systemie zarz"dzania tre$ci". Umo#liwi&o to &atwy dost p dopoprzednich wersji i analiz ró#nic mi dzy nimi.

Dokumenty raz opracowane mo#na by&o przetwarza! do innych formatów wyj$ciowych lubwy$wietla! je na portalu projektowym.

11.3.4. WIKI

Na etapie przygotowywania tre$ci pracy magisterskiej bardzo pomocne okaza&o si narz dzieDokuWIKI. Umo#liwi&o ono gromadzenie i opracowywanie tre$ci w wygodny sposóbz dowolnego komputera pod&"czonego do sieci Internet.

DokuWIKI [53] jest narz dziem typu WIKI, które umo#liwia tworzenie i edytowanietre$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 iewentualnie ich anulowanie.

Mo#liwa jest kontrola dost pu do systemu dzi ki zastosowaniu mechanizmówautoryzacji.

Page 84: Rafał Petryniak - Praca magisterska

80

Poni#ej przedstawiono sposób edycji spisu tre$ci:

Rysunek 11.6. WIKI: edycja strony

Page 85: Rafał Petryniak - Praca magisterska

81

12. Wnioski

1) Przygotowany projekt, po etapie dok&adnej analizy, zosta& zaimplementowany i jestgotowy 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#ez powodu braku integracji z innymi modu&ami szpitalnego systemu informatycznegomo#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óreznajduj" si w ró#nych miejscach geograficznych. W trakcie tworzenia systemu,uwzgl dniono potrzeb dostarczenia filtrów graficznych, pozwalaj"cych naprzetwarzanie obrazów w celu wydobycia istotnych informacji dla osobyprzegl"daj"cej zdj cia.

Page 86: Rafał Petryniak - Praca magisterska

82

13. Literatura

Ksi!"ki

[1] Robert Rudowski. Copyright © 2003 Wydawnictwo naukowe PWN SA. 83-011-4056-9. 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. CRCPress. 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 systeminformatyczny #yj"cy organizm”. 3-6.

[16] Biuletyn Informatyki Medycznej. UHC sp. z o.o.. 12 czerwca 2005. „Nowe przegl"darkiDICOM”. 5.

Page 87: Rafał Petryniak - Praca magisterska

83

[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 TechnologiiInformatycznych, Instytut Fizyki, Uniwersytet M. Curie - Sk&odowskiej w Lublinie.

[19] Rewolucja informatyczna w medycynie. Prof.. W&odzis&aw Duch. Katedra MetodKomputerowych, Uniwersytet Miko&aja Kopernika.

[20] Computerworld. IDG. 26 kwietnia 2004. „Zdrowie w normie”. Edward Byczy%ski i MarekWeso&owski.

[21] Telemedycyna w praktyce - modele telekonsultacji medycznych oraz ich wykorzystywanie wramach Krakowskiego Centrum Telemedycyny. dr in#.. Aleksander Laurentowski, mgr in#.. DominikRadziszowski, i Adam Koprowski.

[22] Internet medyczny - wp yw nowych "rodków komunikacji na wspó czesne oblicze medycyny. PiotrKasztelowicz. 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$rednictwemInternetu”. 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. PracowniaTechnologii Informatycznych, Instytut Fizyki, Uniwersytet M. Curie - Sk&odowskiej w Lublinie.

[26] Wykorzystanie technik wizualizacji danych w medycynie. Bo&dak Cezary. PolitechnikaBia&ostocka, Instytut Informatyki.

[27] Vogel Burda Communications. Chip. marzec 2005. „Sprz towe generowanie grafiki 3D”. Bie%kowskiMarcin.

[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/

Page 88: Rafał Petryniak - Praca magisterska

84

[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

Page 89: Rafał Petryniak - Praca magisterska

85

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

Page 90: Rafał Petryniak - Praca magisterska

86

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 VARCHAR(20) NOT NULL, 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 VARCHAR(20) NOT NULL, badanie_pacjent_kodpac VARCHAR(20) NOT NULL, badanie_kodbad VARCHAR(20) NOT NULL, diagnoza TINYTEXT NULL, konsultant VARCHAR(20) NULL,

INDEX diagnoza_FK_bad_pac_lek(badanie_kodbad, badanie_pacjent_kodpac,badanie_lekarz_kodlek));

-- -------------------------------------------------------------- Tabela z danymi lekarza, który przeprowadza badanie.-- Tabela ta jest równie! tabel u!ytkowników systemu (kodlek + haslo)-- ------------------------------------------------------------

CREATE TABLE lekarz ( kodlek VARCHAR(20) NOT NULL, 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 VARCHAR(20) NOT NULL, imie VARCHAR(20) NULL, nazwisko VARCHAR(30) NULL, adres VARCHAR(100) NULL,

PRIMARY KEY(kodpac));

Page 91: Rafał Petryniak - Praca magisterska

87

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 pracyoraz zosta y umieszczone na stronie WWW [54].

1. System InterMed

• Prototyp systemu - posta$ statyczna systemu InterMed, w której poszczególnestrony zawieraj! zapisane na sta e, przyk adowe dane.

• Schemat bazy danych - pe ny schemat bazy danych wraz z przyk adowymidanymi (dost#pne tylko na CD do !czonym do pracy).

• Kod "ród owy aplikacji - pe ny kod %ród owy systemu InterMed (dost#pnetylko na CD do !czonym do pracy).

2. Analiza wymaga&

• Architektura systemu - (IBM Rational Software Architekt) - wydzielonediagramy UML, zapisane w osobnym pliku.

• Architektura systemu - (IBM Rational Software Architect) - raportszczegó 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 uDICOM.

• Wizualizacja medyczna - strona WWW, która prezentuje mo"liwo'ci modu uWizualizacja.

• The Visible Human Project - strona WWW, na której zosta a zainstalowanaaplikacja Visible Human Viewer.

4. Próba wizualizacji przestrzennej obrazu

• Wyznaczanie konturów - analiza porównawcza wybranych narz#dziprogramistycznych do wykrywania konturu obrazu.

• Wizualizacja zdj#$ tomograficznych - próba wizualizacji przestrzennejobrazów przekrojowych w technologi X3D. Dane pochodz! z badaniatomografem komputerowym.

• Test Przegl!darek VRML/X3D - analiza porównawcza najpopularniejszychprzegladarek VRML/X3D.

Page 92: Rafał Petryniak - Praca magisterska

88

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 przezTwórc# lub Licencjodawc#

# ycie niekomercyjne. Nie wolno u!ywa tego utworu do celówkomercyjnych.

Na tych samych warunkach. Je"li zmienia si# lub przekszta$caniniejszy utwór, lub tworzy inny na jego podstawie, mo!narozpowszechnia powsta$y w ten sposób nowy utwór tylko na podstawietakiej 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.

Page 93: Rafał Petryniak - Praca magisterska

89

Spis rysunków

1.1. Zdj#cie rentgenowskie d oni "ony Roentgena wykonane przez samego K.W. Roentgena w 18961.2. Zdj#cie tomograficzne dziewi#cioletniej dziewczynki1.3. Zdj#cie przekrojowe g owy cz owieka wykonane w badaniu rezonansem magnetycznym1.4. Ultrasonografia czteromiesi#cznego p odu2.1. Budowa systemu PACS6.1. Koncepcja systemu7.1. Model przep ywu informacji7.2. Model architektury systemu7.3. Przegl!d aktorów systemu7.4. Kluczowe przypadki u"ycia7.5. Diagram czynno'ci dla kluczowych funkcji systemu7.6. Wymagania sprz#towe8.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ów8.5. Diagram wdro"enia8.6. Projekt bazy danych8.7. Projekt interfejsu8.8. Iteracyjny proces budowania systemu8.9. Proces V budowania i testowania poszczególnych modu ów8.10. Dekompozycja systemu8.11. Okienko logowania8.12. Strona g ówna (powitalna)8.13. Nowe badanie8.14. Nowe badanie - pomoc8.15. Wykonane badanie8.16. Potwierdzenie usuni#cia badania8.17. Wykonane badanie - pomoc8.18. Widok listy bada&

8.19. Wyszukiwanie bada&

8.20. Informacja o systemie8.21. Modu DICOM8.22. Modu DICOM - opcja 'ZOOM'8.23. Modu DICOM – filtry(1)8.24. Modu DICOM – filtry(2)8.25. Modu Wizualizacja: okno g ówne8.26. Ekran konsultacji9.1. Wizualizacja punktowa obrazów przekrojowych wygenerowana w technologii X3D10.1. Integracja z systemem PACS10.2. Integracja z systemami RIS i HIS10.3. Wsparcie poprzez wideokonferencje11.1. Certyfikat wyg oszenia pracy na konferencji11.2. Portal projektowy11.3. Repozytorium: dokumentacja11.4. Repozytorium: projekt11.5. Porównywanie wersji11.6. WIKI: edycja strony

Page 94: Rafał Petryniak - Praca magisterska

90

Spis tabel

7.1. Wymagania dot. bezpiecze&stwa systemu 3DVS7.2. Wymagania dot. sprz#tu7.3. Pozosta e wymagania dot. systemu 3DVS8.1. Filtry graficzne9.1. Zdj#cia z badania rezonansem magnetycznym10.1. System jako us uga zewn#trzna z punktu widzenia klienta i dostawcy - porównanie10.2. Instalacja systemu u klienta - porównanie zalet i wad

Spis przyk adów

8.1. Sk adnia znacznika mailto8.2. Przyk ad u"ycia znacznika mailto9.1. X3D: znacznik PointSet9.2. X3D: znacznik IndexedFaceSet9.3. X3D: znacznik ElevationGrid