Projektgruppe 856a 8. semester Medicinsk Informatik 2008

Transkript

1 Projektgruppe 856a 8. semester Medicinsk Informatik 2008 Niels Hald Ninna Kæseler Jonas Nørgaard Lauritzen Kirstine Hjære Rosenbeck Line Rugholm Sanden Institut for Sundhedsvidenskab og Teknologi Aalborg Universitet

2 .

3 Ingeniør-, Natur- og Sundhedsvidenskabelige Fakultet Aalborg Universitet Titel: System til visualisering af cortex cerebri til brug i klinisk forskning. P8-projektperiode: 4. februar - 2. juni 2008 Projekt gruppe: 856a Gruppemedlemmer: Jonas Nørgaard Lauritzen Kirstine Hjære Rosenbeck Line Rugholm Sanden Niels Hald Ninna Kæseler Vejledere: Kamille Madsen Rosenfalck Simon Fristed Eskildsen Antal kopier: 8 Sideantal: 69 Hovedrapport: 78 Bilag: Kildekode er vedlagt på CD Synopsis: Kortikal atrofi forekommer ved en række neurodegenerende sygdomme som fx Alzheimers sygdom. Kortikal atrofi vurderes i klinisk sammenhæng ved, at en kliniker foretager en subjektiv vurdering af tykkelsen af cortex cerebri udfra MR-skanninger. Dette kan medføre bias mellem forskellige klinikeres vurdering af atrofi hos patienter, og gør det svært at lave pålidelig forskning indenfor området. Der er på Aalborg Universitet udviklet en algoritme, der udfra MR-skanninger kan generere 3D modeller af cortex cerebri og herudfra udregne kvantitativ information i form af mål for tykkelse, volumen og overfladeareal på forskellige områder af cortex cerebri. Algoritmen er endnu ikke implementeret i et brugervenligt system, og kan derfor ikke anvendes i kliniske sammenhæng. I dette projekt er det analyseret, hvorledes et system til visualisering af strukturel og kvantitativ information om cortex cerebri kan opfylde klinikeres behov for objektive vurderinger af kortikal atrofi. Der er i dette projekt udviklet en prototype af et sådant system, der implementerer førnævnte algoritme. Prototypen kan via en grafisk brugergrænseflade visualisere 3D modeller af cortex cerebri, samt inddele disse i hjernelapper og visualisere tykkelsen på cortex cerebri via en farveskala. Yderligere kan kvantitative mål tilhørende modellen ses, og disse kan også eksporteres til andre programmer. For at indføre systemet i klinisk sammenhæng, er en videreudvikling af prototypen nødvendig, men det vurderes, at prototypen kan bruges som et redskab til at foretage en objektiv vurdering af atrofi i cortex cerebri.

4 .

5 The Faculty of Engineering, Science and Medicine Aalborg University Titel: A system for visualization of the cortex cerebri for use in clinical research. P8-project periode: 4. February - 2. June 2008 Project group: 856a Group members: Jonas Nørgaard Lauritzen Kirstine Hjære Rosenbeck Line Rugholm Sanden Niels Hald Ninna Kæseler Supervisors: Kamille Madsen Rosenfalck Simon Fristed Eskildsen Number of copies: 8 Pages: 69 Main rapport: 78 Appendix: Source code included on CD Synopsis: Cortical atrophy occurs in a number of neurodegenerative diseases such as Alzheimer s disease. When cortical atrophy is evaluated in a clinical setting, a clinician makes a subjective assessment of the thickness of the cerebral cortex based on MR-scans. This can lead to bias between different clinicians assessments of atrophy in patients, and makes it difficult to make reliable research in this field. At Aalborg University an algorithm has been developed which can generate 3D models of the cerebral cortex based on MR-scans. The algorithm can calculate quantitative measurements related to the cerebral cortex such as the thickness, volume and surface in different areas. The algorithm is not yet implemented in a user-friendly system, and therefore can not be used in a clinical setting. In this project, it is analyzed how a system for visualization of structural and quantitative information on the cerebral cortex can meet clinicians need for objective assessments of cortical atrophy. In this project a prototype has been developed that implements the aforementioned algorithm. In the graphical user interface of the prototype 3D models of the cerebral cortex can be visualized and categorized in brain lobes and visualize thickness of the cerebral cortex using a colour garmut. Furthermore, the quantitative measurements of the model is presented, and it is possible to export these to other programs. In order to introduce the system into a clinical setting, a further development of the prototype is necessary. For now the prototype can help to make an objective assessment of atrophy of the cerebral cortex.

6 .

7 Forord Denne rapport er udarbejdet af gruppe 856a i projektperioden fra 4. februar til 2. juni 2008 på 8. semester ved Institut for Sundhedsvidenskab og Teknologi ved Aalborg Universitet. Rapporten henvender sig til medstuderende og andre med interesse i 3D modeller af cortex cerebri. Formålet for specialeretningen medicinsk informatik er, At give mulighed til at analysere hvordan modellering af medicinske data og information kan bidrage til at skabe ny viden i klinisk forskning. At kunne bruge metoder til syntese af systemer til repræsentation og fortolkning af medicinske data/information. At kunne anvende videnskabelige metoder i en syntese (design, gennemførsel og rapportering) af et forskningsprojekt. Projektet omhandler analyse, design og implementering af et elektronisk system til visualisering af modeller af cortex cerebri til anvendelse i klinisk forskning. Projektgruppen ønsker at takke professor, speciallæge i radiologi Elna-Marie Larsson og ph.d., speciallæge i neurologi Peter Johannsen, for afklaring af spørgsmål relateret til modellering af cortex cerebri samt spørgsmål relateret til design af et system til præsentation af cortexmodeller. Aalborg Universitet, Juni 2008 Jonas Nørgaard Lauritzen Niels Hald Kirstine Hjære Rosenbeck Ninna Kæseler Line Rugholm Sanden

8 .

9 Læsevejledning Denne læsevejledning har til formål at give overblik over indholdet og strukturen af denne rapport. Overordnet kan projektet inddeles i 7 forskellige dele, som er dokumenteret fortløbende i rapporten. Disse dele er: Introduktion Analyse Krav Design Implementering Test Diskussion og konklusion Introduktionen til rapporten, som findes i kapitel, belyser en ny metode til at modellere cortex cerebri samt dokumentation for, hvorfor modellering af cortex cerebri er anvendelig i forsknings og kliniske sammenhænge. På baggrund af dette er målet for projektet opstillet, som omhandler at udvikle et system, der kan præsentere modeller og kvantitative mål for cortex cerebri. For at opfylde målet for projektet, er der lavet en analyse, som tager udgangspunkt i at identificere systemets potentielle brugere samt at undersøge, hvilke funktionaliteter et system til cortexmodellering skal indeholde. Systemets funktionaliteter er analyseret på baggrund af vidensindsamling fra interviews og spørgeskemaundersøgelser. Analysen kan findes i kapitel 2. Analysen indbefatter også en beskrivelse af de funktionaliteter som skal være indeholdt i den prototype, som udvikles i dette projekt. Yderligere findes en kort beskrivelse af den overordnede arkitektur af prototypen i kapitel 3. For at opfylde krav potentielle brugere har til et system til modellering af cortex cerebri, er der opstillet krav til hvilke funktionaliteter prototypen skal indeholde. Dette er gjort i form af use cases, som kan findes i kapitel 4. I projektet er der lagt vægt på at designe et brugervenligt system, som opfylder alle use cases. Derfor er der designet en grafisk brugergrænseflade. Designet af denne er dokumenteret i kapitel 5. Designet tager udgangspunkt i den viden, som er fremkommet i analysen samt generelle designovervejelser fra litteraturen. Rapporten dokumenterer yderligere design af den anvendte database, samt design af komponentarkitektur og dataflow. Dette findes i henholdsvis kapitel 6 og 7. Implementeringen af prototypen er dokumenteret i kapitel 8. Her tages der udgangspunkt i implementering af funktioner, som adskiller sig ud fra designet af systemet. I kapitel 9 findes en præsentation af det endelige system, som tager udgangspunkt i skærmbilleder fra prototypen. Efter implementering af prototypen, er denne blevet testet i en systemtest og en brugertest, hvor to potentielle brugere

10 iv Forord har afprøvet prototypen. Resultaterne herfra findes i kapitel 0, og tilhørende testprotokoller kan findes i appendiks. Sidst i hovedrapporten afrundes projektet med en diskussion og en konklusion. Udviklingsprocessen, der er dokumenteret gennem rapporten, er inspireret af Unified Process (UP) og er udført iterativt, med fokus på risiko og drevet af use cases. Kun den nyeste iteration af krav, analyse, design og implementering er dokumenteret i rapporten. I udvikling af prototypen er der anvendt udvalgte principper og dokumentationsmetoder fra Unified Modeling Language (UML). Designet af databasen er foretaget ud fra en Entitet-Relationship modellering. Henvisninger der starter med et bogstav, refererer til appendiks, som findes sidst i rapporten. Bilag er vedlagt på en cd eller findes bagerst i rapporten. Litteraturhenvisninger er angivet efter Harvard-metoden. Rapporten læses med fordel fortløbende for at opnå bedst mulig forståelse. Anvendt notation Følgende notationer er anvendt i rapporten. Use cases angives gennem hele rapporten med kursiv. fx Generer cortexmodel Grafiske elementer angives gennem hele rapporten med maskinskrift. fx Værktøjskasse Klasser angives gennem hele rapporten med fed.fx Database

11 Indhold Introduktion. Forandringer i cortex cerebri Måling af kortikal atrofi Modellering af cortex cerebri Anvendelsesmuligheder for cortexmodeller Opsummering af introduktion og mål for projektet Analyse 7 2. Vidensindsamling Systemets brugere Systemets funktionaliteter Systembeskrivelse af prototype Systemets overordnede arkitektur 3 4 Krav 5 4. Aktører Use cases Design af grafisk brugergrænseflade Identifikation af grafiske elementer Sammenhæng mellem grafiske elementer Design af grafiske elementer Design af datahåntering Data ER-diagram Tabeller på databasen Design af komponentarkitektur og dataflow Systemets komponentarkitektur Ikke oprettende associationer Systemets dataflow Implementering Programmeringssprog og implementerede klasser Database Klient/server forbindelse Visualisering af cortexmodeller Visning af elementer på canvas Måleresultater

12 vi Indhold 8.7 Afvigelser fra brugergrænsefladedesign Software og hardware Præsentation af prototypen Overblik over brugergrænsefladen Åbning / sammenligning af cortexmodeller Eksportering af kvantitative mål Visning af kvantitative mål Værktøjer til manipulering af cortexmodel Visualisering af cortexmodeller Test Modultest og integrationstest Systemtest Brugertest Diskussion 69. Brugerinddragelse Test Anvendelse af prototypen Konklusion Opsummering Konklusion Litteratur 75 I Appendiks 79 A Hjernen 8 A. Hjernes anatomi og funktion B Sygdomme med forandringer i cortex cerebri 83 B. Alzheimers Sygdom B.2 Frontotemporal demens B.3 Lewy body demens B.4 Parkinsons sygdom B.5 Huntingtons chorea B.6 Multipel sclerose B.7 Depression B.8 Skizofreni C Algoritme til udtrækning af cortex cerebri 89 C. Algoritmens overordnede trin C.2 Præprocessering C.3 Konstruktion af initiel indre overflade C.4 Deformation mod den korrekte indre overflade C.5 Deformation mod den korrekte ydre overflade C.6 Algoritmens output D Inddragelse af brugere 93 D. Vigtighed af brugerinddragelse

13 Indhold vii D.2 Behovsafklaring D.3 Bestemmelse af systemets funktionalitet D.4 Brugergrænsefladedesign E Designprincipper 95 F ER-modellering 97 F. Omsætning af ER-diagram til normaliserede tabeller F.2 Normalisering G Java3D scenegrafen 0 G. Anvendte objekter G.2 Opbygning H Klassediagram med metoder 03 I Testprotokol for systemtest 07 I. Test data I.2 Systemtest af Generer cortexmodel I.3 Systemtest af Søg MR-skanning I.4 Systemtest af Vis standardmodel I.5 Systemtest af Vis hemisfære I.6 Systemtest af Sammenlign to modeller I.7 Systemtest af Sammenlign to hemisfærer I.8 Systemtest af Roter, flyt og zoom model I.9 Systemtest af Vis hjernelap I.0 Systemtest af Vis farveskala for cortextykkelse I. Systemtest af Vis verificeringsbilleder I.2 Systemtest af Eksporter kvantitative mål I.3 Systemtest af yderligere krav hørende til brugergrænsefladedesign J Brugertest 2 J. Formål J.2 Metode J.3 Testmaterialer J.4 Resultater II Bilag 33 Interviewguide 35. Introduktion Indledende spørgsmål Hoveddel Afsluttende spørgsmål Afslutning Systemets funktion 39 3 Mock up til brug i interview 4 4 Cortexmodel inklusiv parameterliste 43

14 viii Indhold 5 Sammenlign cortexmodeller inklusiv parameterliste 45 6 Referater af interviews Referat af interview med Peter Johannsen d. 3. marts Referat af interview med Elna-Marie Larsson d. 6. marts Spørgeskema undersøgelse Forberedelse af undersøgelsen Resultat af undersøgelsen Low-fidelity test 6 8. Formål Metode Testmaterialer Resultater

15 Introduktion I dette kapitel beskrives forekomsten af forandringer i cortex cerebri ved en række sygdomme. Herefter belyses, at der er problemer relateret til de metoder, der på nuværende tidspunkt anvendes til kvantificering af disse forandringer. På baggrund af disse problemer foreslås en ny metode til modellering af cortex cerebri og desuden belyses anvendelsesmulighederne for denne i klinisk praksis og forskning. Afslutningsvis formuleres målet for dette projekt.. Forandringer i cortex cerebri Ved en række sygdomme, ses der kortikal atrofi og dermed forandringer i cortex cerebri. Dette gælder blandt andet følgende sygdomme. Alzheimers sygdom [Busatto et al., 2003] [Duarte et al., 2006] Frontotemporal demens [Du et al., 2007] [Perry et al., 2006] Lewy body demens [Burton et al., 2002] Mild Cognitive Impairment [Bell-McGinty et al., 2005] Parkinsons sygdom [Brück et al., 2004] [Ramírez-Ruiz et al., 2005] [Ramírez-Ruiz et al., 2007] Huntingtons chorea [Rosas et al., 2002] Multipel sclerose. [Sailer et al., 2003] Ud over disse somatiske sygdomme, er der også eksempler på psykiatriske sygdomme, hvor der er observeret kortikal atrofi. Dette gælder fx i forbindelse med depression [Taylor et al., 2007] og skizofreni [Whitford et al., 2006]. En beskrivelse af de nævnte sygdomme og deres relation til atrofi i cortex cerebri findes i appendiks B, desuden findes der i appendiks A en introduktion til hjernes anatomi og funktion med fokus på cortex cerebri. Ved en række af disse sygdomme diagnosticeres der i dag ud fra patienternes symptomer. Dette gælder fx Alzheimers sygdom, hvor diagnosen bygger på et interview med patienten og eventuelt neuropsykologiske tests [Baddeley, 2004]. Problemet ved denne diagnosemetode er, at den først sikkert diagnosticerer patienter, der er i et relativt sent stadie af Alzheimers sygdom [Fillit et al., 2006] [Auer og Reisberg, 997]. Dette er problematisk, fordi der i dag kun findes symptomatiske behandlinger, der får udviklingen af Alzheimers sygdom til at stagnere. Derfor er det ønskeligt at kunne diagnosticere patienter i et tidligt stadie af sygdommen. [Fillit et al., 2006] Hermed kan behandlingen igangsættes tidligt i sygdomsforløbet, hvilket medfører et forlænget funktionsdygtig liv for patienten samt besparelser i patientudgifter. Dette er en økonomisk gevinst, fordi udgifterne til medicin udgør et mindre beløb end udgifterne til pleje og indlæggelser. [Ferri et al., 2005] Problemet ved en sen diagnosticering gøres større af, at der er en stigning i antallet af patienter, der er ramt af Alzheimers sygdom, hvilket medfører en øget belastning af plejesektoren og øgede udgifter til behandling og pleje. Dette skaber et behov for at mindske antallet af patienter, som har Alzheimers sygdom i et stadie, hvor pleje er påkrævet. [Fillit et al., 2006] Af disse grunde er der behov for nye diagnosticeringsmetoder, hvorved patienter kan diagnosticeres tidligere. En måde at gøre dette på kunne være at måle den atrofi, som neurodegenerative sygdomme er karakteriseret af. I det følgende beskrives, hvordan atrofi i cortex cerebri kan måles.

16 2 Introduktion.2 Måling af kortikal atrofi Cerebral kortikal atrofi vurderes i klinisk praksis oftest ved, at en kliniker foretager en subjektiv vurdering af tykkelsen af cortex cerebri udfra en MR-skanning. Så vidt vides, anvendes der på nuværende tidspunkt ikke kvantitative oplysninger i form af tykkelse, volumen og areal for cortex cerebri i klinisk praksis, idet der ikke er værktøjer til rådighed, der kan udtrække disse informationer. [Larsson, 2008] [Johannsen, 2008] En subjektiv vurdering af atrofigraden kan medføre bias imellem klinikerne og besværliggøre vurderingen af en eventuel udvikling over tid eller afvigelse fra en rask hjerne. Hvis kortikal atrofi kunne kvantificeres, kunne en eventuel bias imellem klinikernes vurderinger undgås, hvorved der ville haves et præcist mål der kunne benyttes til sammenligning over tid eller med normalmateriale. Der er udviklet adskillige billedprocesserende algoritmer til at kvantificere blandt andet volumen af den grå substans udfra MR-skanninger. Ingen af de segmenteringsalgoritmer som er forelagt i litteraturen, adskiller væv pålideligt nok til at blive anvendt uden at skulle fortolkes af en radiolog. Desuden er mange segmenteringsalgoritmer afhængige af en til tider svært håndterbar parameterjustering, som hindrer anvendelse i daglig klinisk praksis. [Barra og Lundervold, 2008] I forskning indenfor neurodegenerative sygdomme er information om degeneration i cortex cerebri typisk ikke detaljeret, idet viden om hastigheden, lokaliteten og udviklingen i degeneration af cortex cerebri ved forskellige sygdomme er begrænset. Dette skyldes, at det er svært at studere cortex cerebri ved neurodegenerative sygdomme, hovedsageligt på grund af dets komplekse foldningsmønster og regionale variabilitet. Forståelse af hvordan en sygdom er relateret til ændringer i cortex cerebri kan give en ny og vigtig indsigt i sygdommen. [Rosas et al., 2002] [Sailer et al., 2003] I klinisk praksis vurderes atrofi oftest subjektivt og indenfor den kliniske forskning er informationen om degeneration i cortex typisk ikke detaljeret. Af disse grunde vil det være hensigtsmæssigt, hvis der kunne opnås pålidelig og konsistent kvantitativ information om cortex cerebri, der ikke omfatter operatørinduceret bias. Det belyses i det efterfølgende, hvordan denne kvantificering kan opnås..3 Modellering af cortex cerebri Der er udviklet en algoritme, hvis formål er at modellere cortex cerebri udfra T-vægtede MR-skanninger, og med hvilken der er opnået gode resultater på MR-skanninger fra raske og patienter med Alzheimers sygdom. Ved hjælp af denne algoritme fås en 3D model af cortex cerebri, hvor den indre og den ydre overflade af cortex cerebri er præsenteret, det vil sige overfladestrukturen af hele cortex cerebri, herefter omtalt som cortexmodeller. Det overordnede koncept i algoritmen er baseret på en active surface model, der konstruerer en indre overflade af cortex cerebri og en ydre overflade ved deformation af den indre. Denne algoritme er tilgængelig og giver som output kvantitativ information om strukturen af cortex cerebri, så som cortextykkelse. [Eskildsen et al., 2005] [Eskildsen og Østergaard, 2006] [Eskildsen og Østergaard, 2007] På figur. ses en række cortexmodeller genereret af algoritmen, hvor tykkelsen af cortex er visualiseret med en farveskala på modellens overflade. På figur.2 ses, hvordan algoritmens segmentering ser ud i forskellige snitplaner, således kun cortex cerebri er med i cortexmodellen. En mere detaljeret beskrivelse af algoritmen findes i appendiks C

17 .3 Modellering af cortex cerebri 3 Figur.: Figuren viser 8 cortexmodeller generet af algoritmen udfra MR-skanninger, hvor cortextykkelsen er indtegnet således, at de mørke farver svarer til tynde områder, og lyse farver svarer til tykke områder. MRskanningerne der er brugt som input er fra raske personer og kommer fra ICBM databasen(international consortium for brain mapping). [Eskildsen et al., 2005] Figur.2: I den øverste række er det illustreret, hvordan den indre overflade af cortexmodellen ligger i forhold til en MR-skanning i tre forskellige snit. Ligeledes er den ydre overflades placering i forhold til en MR-skanning illustreret i den nederste række. [Eskildsen et al., 2005]

18 4 Introduktion Denne algoritme er et bud på, hvordan kvantitativ information vedrørende cortex cerebris struktur kan udtrækkes fra en MR-skanning. Herved ville blandt andet kortikal atrofi kunne belyses, men der ville også være andre anvendelsesmuligheder. Anvendelsesmulighederne uddybes i det efterfølgende..4 Anvendelsesmuligheder for cortexmodeller Hvis klinikere havde adgang til kvantitative mål for strukturen af cortex cerebri, så som tykkelse og volumen, ville der kunne laves klinisk forskning på baggrund heraf vedrørende neurodegenerative sygdomme. På sigt ville denne viden kunne bruges i diagnosesammenhæng og til at vurdere effekt af en given behandling. [Larsson, 2008] [Johannsen, 2008] Desuden ses en mulighed i at anvende strukturel information vedrørende cortex cerebri i forbindelse med neurokirurgisk operationsplanlægning [Johannsen, 2008] [Spørgeskemaundersøgelse, 2008]. Følgende er mere specifikke eksempler på anvendelsesområder, hvor klinikere finder cortexmodellen og den deraf følgende kvantitative information om strukturen af cortex cerebri anvendelige. I forbindelse med diffuse hjernesygdomme. [Spørgeskemaundersøgelse, 2008] Ved demensudredning. [Spørgeskemaundersøgelse, 2008] Ved vurdering af omfanget af en kortikal skade ved traume. [Spørgeskemaundersøgelse, 2008] Ved stereotaktisk behandling. [Spørgeskemaundersøgelse, 2008] Hos patienter, som skal opereres for elokvent beliggende patologier. [Spørgeskemaundersøgelse, 2008] Som supplement til eksisterende neuronavigationssystem. [Spørgeskemaundersøgelse, 2008] I planlægning af tumorkirurgi. [Spørgeskemaundersøgelse, 2008] På sigt, sandsynligvis i forbindelse med en tidlig diagnose af demens. [Larsson, 2008] Ved forskning i Alzheimers sygdom, hvor en måde at skabe mere indsigt i sygdommen, kunne være ved at visualisere cortex cerebri midt-sagitalt, således der kan detekteres forandringer i dette område. Dette område er der så vidt vides ikke mulighed for at visualisere på nuværende tidspunkt. [Johannsen, 2008] Ved visse subkortikale sygdomme har det muligvis en værdi at undersøge, om der sker kortikale forandringer. [Johannsen, 2008] Som regel vil nye metoder, som fx modellering af cortex cerebri, blive afprøvet i et forskningsprojekt, hvor de kan udvikles og optimeres, inden de indføres i klinisk radiologisk diagnostisk arbejde. [Larsson, 2008] Derfor vil cortexmodeller i første omgang blive anvendt i forbindelse med klinisk forskning [Larsson, 2008] [Johannsen, 2008]. På nuværende tidspunkt er den beskrevne algoritme til cortexmodellering ikke nem at anvende for klinisk personale, idet den ikke er implementeret i en applikation. Hvis algoritmen implementeres i en applikation med en hensigtsmæssig brugergrænseflade, kan der præsenteres kvantitativ information om strukturen af cortex cerebri, som kan anvendes til klinisk forskning..5 Opsummering af introduktion og mål for projektet Der anvendes ikke information om cortex cerebri i form af kvantitative mål som tykkelse, volumen og overfladeareal i klinisk praksis, idet denne information ikke er til rådighed. Anvendelsen i klinisk forskning er ligeledes begrænset, fordi metoder til udtrækning af kvantitative mål ikke er let tilgængelige.

19 .5 Opsummering af introduktion og mål for projektet 5 Der findes en gruppe sygdomme, hvor mere viden om kvantitative mål af cortex cerebri kan anvendes til forskning vedrørende relationer mellem sygdomme og kortikale ændringer. Hvis sådan en viden bliver konsolideret, kan den bruges i forbindelse med diagnosticering og behandling. Derfor er der endnu ikke behov for kvantitative målinger af cortex cerebri i klinisk praksis, men derimod indenfor klinisk forskning. På baggrund af overstående er målet for projektet at udvikle et system, der kan visualisere en 3D model af cortex cerebri med tilhørende kvantitativ information om cortextykkelser, arealer og volumener. Informationen om cortex cerebri fås fra en algoritme, som er udviklet til at generere cortexmodeller ud fra MR-skanninger, men som endnu ikke er implementeret i et brugervenligt system. Systemet tænkes anvendt i klinisk forskning, men skal udvikles med henblik på senere anvendelse i klinisk praksis.

20 .

21 Analyse 2 Dette kapitel indeholder en analyse, der er baseret på en vidensindsamling, som er beskrevet i det første afsnit i kapitlet. Efterfølgende identificeres systemets brugere. Det analyseres hvilke funktionaliteter, der er påkrævet for at et system til cortexmodellering skal kunne tilgodese de ønsker, de forventede brugere har til systemet. Yderligere beskrives det hvilke af disse funktionaliteter, som medtages i den prototype, som udvikles i dette projekt. Sidst i kapitlet findes en systembeskrivelse, der kort opsummerer de funktionaliteter, som skal indgå i prototypen. 2. Vidensindsamling For at fastlægge hvilke funktionaliteter systemet skal indeholde, er der taget udgangspunkt i den baggrundsviden, der er givet i appendiks B, omhandlende sygdomme, der er relateret til forandringer i cortex cerebri. Denne viden har dannet grundlag for ideer til systemets funktionaliteter. Disse funktionaliteter er blevet fremlagt for henholdsvis en neurolog og en radiolog ved to interviews, som der kan ses referater af i bilag 6. Disse interviews gav input til systemets funktionaliteter fra domæneeksperter. Formålet med undersøgelsen var hermed at få vurderet relevansen af de opstillede funktionaliteter og at få input til eventuelt manglede funktionaliteter i systemet. For at uddybe og understøtte de informationer som blev opnået gennem de to interviews, blev der udarbejdet et spørgeskema, som blev sendt ud til 6 relevante brugere, hvoraf 8 besvarelser blev modtaget. Besvarelserne kom fra 7 neurokirurger og fysiker. Resultatet af spørgeskemaundersøgelsen kan ses i bilag 7. Selvom spørgeskemaundersøgelsen og interviewene ikke giver et repræsentativt indtryk fra alle potentielle brugere af systemet, er de baseret på meninger og domæneviden fra fire forskellige faggrupper. Derfor er det vurderet, at denne viden er tilstrækkelig for at kunne designe og udvikle et brugervenligt system til cortexmodellering. 2.2 Systemets brugere Idet systemet i første omgang skal udvikles til forskning, er brugerne af systemet personer, som forsker indenfor specialer, der er relateret til forandringer af cortex cerebri. Disse personer kunne være kliniske assistenter, neuroradiologer og Ph.D-studerende. [Johannsen, 2008] Systemet skal senere kunne udvides til klinisk praksis, hvor personer som vil kunne anvende systemet er radiografer [Johannsen, 2008] [Larsson, 2008], radiologer [Johannsen, 2008] og neurokirurger [Larsson, 2008] [Spørgeskemaundersøgelse, 2008]. I relation til psykiatriske sygdomme ville neuropsykologer også kunne anvende det [Larsson, 2008]. 2.3 Systemets funktionaliteter Inden selve analysen defineres en række begreber, der anvendes gennem resten af rapporten. Kvantitative mål er en samlet betegnelse for den gennemsnitlige tykkelse, overfladeareal og volumen af cortex cerebri for følgende områder: Hele cortex, hver hemisfære og de fire hjernelapper. Et eksempel på et kvantitativt mål er den gennemsnitlige tykkelse for venstre frontallap. Normaldata er kvantitative mål for en normalhjerne, hvor en normalhjerne forstås som en gennemsnitlig model der repræsenterer en population af normale hjerner der antages normalfordelt. Derfor består hver værdi af normaldata af et gennemsnit med tilhørende standardafvigelse.

22 8 Analyse Følgende gennemgås funktionaliteterne systemet skal indeholde for at opfylde brugernes ønsker og der argumenteres for relevansen af de enkelte funktionaliteter. Yderligere vurderes, hvilke funktionaliteter prototypen skal understøtte. Brugeridentifikation Når der udvikles et system, der indeholder personfølsomme data, og som på sigt skal anvendes i klinisk praksis, er det vigtigt at systemet har en login funktion, da det er et krav fra datatilsynet, at det kan registers, hvem der har tilgået personfølsomme data samt hvilke data [Olsen, 998]. Systemet skal på sigt implementeres i sygehusenes billedadministrative systemer (PACS, Picture Archiving Communication System) der inkluderer den påkrævede brugeridentifikation og registrering. Der afgrænses fra at implementere et system på sygehusene i sammenspil med deres PACS systemer. Der udvikles dog ikke anden metode til brugeridentifikation, da prototypen på sigt skal kunne implementeres i sygehusenes PACS systemer, som har den påkrævede brugeridentifikation og registrering. Personlige indstillinger Da klinikere har forskellige virkeområder, skal det være muligt at indstille programmet til den enkelte klinikers behov. Dette indbefatter placering af informationer og værktøjer, samt at klinikeren selv kan definere værktøjer, der henvender sig til dennes forskning og/eller arbejdsgange. Systemet skal kunne gemme personlige indstillinger for den enkelte kliniker, og indstillingerne skal kunne genkaldes ved login [Larsson, 2008]. Der afgrænses i prototypen for at kunne lave personlige indstillinger og få dem gemt til en brugerprofil, da prototypen er afgrænset fra brugeridentifikation. Generering af cortexmodel For at systemet skal kunne anvendes, er det essentielt, at der kan genereres en model af cortex cerebri ud fra en MRskanning [Larsson, 2008]. Til at generere cortexmodeller skal algoritmen beskrevet i appendiks C anvendes. Når en cortexmodel med tilhørende kvantitative mål er genereret, skal dette gemmes på en database, så det er tilgængeligt for alle brugere af systemet. Systemet skal integreres direkte i sygehusenes egne PACS systemer, så der er direkte adgang til MR-skanninger indeholdt heri [Larsson, 2008]. Prototypen skal kunne generere en model af cortex cerebri, men den anvendte algoritme betragtes som en black box, og systemet integreres ikke direkte i sygehusenes PACS systemer, da dette ikke er realistisk i et studieprojekt. I stedet udvikles systemet, så det har adgang til en server, hvorpå der ligger MR-skanninger. Verificering af cortexmodel Når informationer om cortextykkelse og volumen skal præsenteres på en ny måde, som i dette system, er det vigtigt brugeren har mulighed for at foretage en vurdering af cortexmodellen [Johannsen, 2008]. I systemet skal det derfor være muligt at verificere en cortexmodel ved at få indtegnet cortexmodellens kontur på den originale MR-skanning. Et eksempel på dette kan ses på figur.2 i introduktionen. På denne måde kan brugeren visuelt kontrollere, om cortexmodellen stemmer overens med den originale MR-skanning, og dermed se om segmentering af cortex cerebri er forløbet tilfredsstillende. Konturen fra modellen skal kunne indtegnes på den originale MR-skanning i de snit, som brugeren ønsker. Kvalitativ vurdering af cortexmodellen skal også indgå i prototypen, dog afgrænses der fra at kunne se alle snit som brugeren ønsker. I stedet anvendes der verificeringsbilleder, som algoritmen automatisk producerer under en cortexmodellering.

23 2.3 Systemets funktionaliteter 9 Visualiseringsmuligheder Ud over at generere en model af cortex cerebri, er det væsentligt for systemets anvendelighed, at det kan visualisere cortexmodeller på en let og overskuelig måde for brugeren. Derfor skal systemet kunne visualisere hele cortex cerebri for brugeren. Da det i forskning kan være anvendeligt at betragte cortex cerebri midt-sagitalt, da dette område kan være relevant i forbindelse med neurodegenerative sygdomme som Alzheimers sygdom [Johannsen, 2008], skal systemet også kunne vise hver hemisfære seperat. For at brugeren kan få det optimale ud af at se en model af cortex cerebri, skal det være muligt at rotere modellen, så den kan ses fra alle sider. Dette gælder både for visning af hele cortex cerebri og visning af en hemisfære. Yderligere skal det være muligt at zoome ind og ud på modellen og flytte den på skærmen, så brugeren kan få den ønskede visualisering. Når klinikere arbejder med MR-skanninger, er de vant til at betragte cortex cerebri i coronale, sagitale og axiale snit [Larsson, 2008], hvorfor denne visualisering også skal være mulig. I prototypen som udvikles i dette projekt, implementeres alle visualiseringsmuligheder på nær at kunne betragte cortexmodellen i coronale, sagitale og axiale snit. Der afgrænses fra dette, da funktionaliteten ikke vil give yderligere informationer, end når der vises verificeringsbilleder. Inddeling af cortexmodel i områder Ved at inddele cortexmodeller i forskellige områder, kan der opnås kvantitative mål for disse områder, hvilket er væsentligt, da forskellige områder på cortex cerebri, forbindes med forskellige sygdomme [Larsson, 2008]. Derfor skal cortexmodellen kunne inddeles i forskellige områder, hvortil det er muligt at få tilhørende kvantitative mål. En kliniker vil typisk anvende information, der knytter sig til de fire hjernelapper [Johannsen, 2008] [Larsson, 2008], hvorfor systemet skal understøtte, at cortexmodellen visuelt kan inddeles i de fire hjernelapper. Dette skal ske ved at de fire lapper hver især bliver markeret. Inddelingen af cortexmodeller i hjernelapper foretages automatisk af algoritmen under cortexmodelleringen. En kliniker kan ønske at tilpasse de områder algoritmen identificerer som de fire hjernelapper, hvis vedkommende vurderer, at områderne ikke er korrekte, eller blot ønsker at udvide/indskrænke områderne. Derfor skal det være muligt at ændre de definerede områder for hjernelapperne, som algoritmen foreslår. Udover at inddele cortexmodellen i hjernelapper, skal det være muligt at inddele den i andre anatomiske og funktionelle områder. I denne forbindelse er det vigtigt, at brugeren også selv kan indtegne og definere områder på cortexmodellen, ved at indsætte punkter, så anatomiske strukturer på cortex cerebri kan følges. [Johannsen, 2008] I prototypen skal det være muligt at få vist de fire hjernelapper på cortexmodellen og indtegne brugerdefinerede områder. Der afgrænses fra at kunne korrigere algoritmens inddeling af hjernelapper på cortexmodellen samt at kunne inddele cortexmodellen i andre anatomiske og funktionelle områder. Sidstnævnte skyldes, at algoritmen ikke udleder andre områder end de fire hjernelapper, og det er vurderet, at det vil kræve for mange ressourcer at lave en automatisk funktion, som kan inddele cortexmodellen i andre områder. Visualisering af cortextykkelse Tykkelsen af cortex cerebri skal illustreres på cortexmodellen ved en farvekode. Denne funktionalitet havde ikke stor interesse hos de adspurgte brugere [Johannsen, 2008] [Larsson, 2008], men medtages alligevel i prototypen, da det giver en intuitiv fornemmelse af variationen af cortex cerebris tykkelse. Funktionaliteten gør det muligt for erfarne brugere at vurdere, hvorvidt de forskellige tykkelser på cortex cerebri er realistiske, ved at genkende farvemønstre på cortex. Figur. i introduktionen er et eksempel på en sådan visualisering. Informationer om kvantitative mål For at brugeren kan få mest muligt ud af systemets forskellige visualiseringsmuligheder, samt inddelinger af cortexmodeller i forskellige områder, er det vigtigt at brugeren kan få informationer om de kvantitative mål, der hører til

24 0 Analyse de forskellige visninger og områder. Derfor skal systemet kunne vise mål for hele cortexmodellen, de to hemisfærer, hjernelapperne, andre anatomiske og funktionelle områder, samt brugerdefinerede områder. I prototypen skal det kun være muligt at få kvantitative mål til hele cortexmodellen, hver hemisfære, hjernelapperne samt brugerdefinerede områder. Dette skyldes, at det er disse områder, som kan visualiseres i prototypen, og derfor er relevante at få vist kvantitative værdier for. Sammenligning af to cortexmodeller Det er relevant at kunne sammenligne to cortexmodeller fra en patient, som er genereret fra MR-skanninger optaget til to forskellige tidspunkter [Larsson, 2008], [Johannsen, 2008]. Dette kan give mulighed for at undersøge, hvordan en sygdom udvikler sig over tid og for at evaluere virkningen af en behandling. For at dette kan lade sig gøre, skal systemet kunne visualisere forskellen mellem to cortexmodeller, således de områder som har forandret sig bliver markeret. Samtidig skal informationer om forandringer i form af differencen mellem de kvantitative mål vises. [Larsson, 2008] I prototypen skal det ikke være muligt at få visualiseret forskellen mellem to cortexmodeller i én samlet model. I stedet skal begge cortexmodeller kunne vises på brugergrænsefladen, og brugeren må herudfra vurdere, om der er sket forandringer med cortex cerebri. Forskellen mellem to cortexmodellers kvantitative mål skal også være til stede i prototypen. Sammenligning med normaldata At kunne sammenligne områder af en cortexmodel med normaldata hørende til en specifik aldersgruppe er relevant for systemets potentielle brugere [Spørgeskemaundersøgelse, 2008] [Larsson, 2008], ligesom yderligere opdeling efter køn også vil være relevant i forskningssammenhæng [Johannsen, 2008]. Det er relevant at få afvigelserne mellem en cortexmodel og normaldata angivet som kvantitative mål, samt at få visualiseret, hvor på cortexmodellen afvigelserne er. [Larsson, 2008] Systemet skal indeholde andre sammenligningsdata end blot normaldata, fx tilsvarende data der repræsenterer en hjerne med Alzheimers sygdom. Dette tiltænkes at kunne benyttes i forbindelse med diagnosticering eller overvågning af sygdomsudvikling. Ud over de eksisterende sammenligningsdata skal det være muligt for brugeren at definere egne sammenligningsdata ud fra cortexmodeller af brugerens eget valg. Sidstnævnte er tiltænkt forskningsregi. I prototypen afgrænses der fra at have flere sammenligningsdata, og selv at kunne definere nye. Der afgrænses fra at kunne visualisere forskellen mellem en cortexmodel og normaldata på en cortexmodel. I stedet skal informationen forefindes som tal. Yderligere afgrænses for at have normaldata for forskellige aldersgrupper og køn, men i stedet anvendes et eksempel ét sæt normaldata, der kan benyttes til sammenligning. Noteværktøj I klinisk sammenhæng kan det være svært at beskrive specifikke områder på cortex cerebri i ord, hvorfor et noteværktøj der kan påhæfte noter til et specifikt område på cortexmodellen vil være anvendeligt [Johannsen, 2008]. Noteværktøjer, dog ikke på førnævnte form, eksisterer og anvendes på nuværende tidspunkt i billedvisualiseringssystemer [Johannsen, 2008], hvorfor et noteværktøj skal være tilgængeligt i systemet. Hele funktionaliteten implementeres i prototypen. Eksportering af kvantitative mål For at systemet kan anvendes til forskning, er det nødvendigt at kunne udtrække kvantitative mål for en række cortexmodeller og overføre dem til et statistikprogram [Larsson, 2008] [Johannsen, 2008]. Det skal være muligt at vælge

25 2.4 Systembeskrivelse af prototype hvilken/hvilke modeller, der ønskes eksporteret data fra samt hvilke kvantitative mål, som ønskes eksporteret. Udvælgelsen af data skal være tilgængelige via en søgefunktion, som gør det nemt at udvælge det ønskede data. Eksport af data skal ske til en kommasepareret fil, således denne kan anvendes i andre statistikprogrammer. I prototypen skal denne funktionalitet indgå i form af præsentation af de kvantitative mål for brugeren og eksportering af målene til en fil, der kan anvendes i statistikprogrammer. Sprog Systemet skal primært anvendes til forskning. Da dette kan finde sted mange steder i verden, skal det være muligt at ændre systemets sprogindstillinger, således disse kan ændres til et andet sprog. I prototypen implementeres det ikke, at det skal være muligt at ændre sprogindstillingerne i programmet. Da systemet skal udvikles til forskning og i første omgang forventes afprøvet i Danmark, designes programmet med en dansk brugergrænseflade. 2.4 Systembeskrivelse af prototype Dette afsnit giver et overblik over hvilke funktionaliteter prototypen, som udvikles i dette projekt, skal indeholde. Det skal være muligt at generere en model af cortex cerebri ud fra en MR-skanning. Det skal være muligt at få vist billeder af segmenteringskonturen superpositioneret på det originale MR-billede til verificering af cortexmodelleringen. Det skal være muligt at få visualiseret en model af cortex cerebri, samt visualisering af højre og venstre hemisfære hver for sig. Det skal være muligt at rotere, zoome og flytte cortexmodellerne. Det skal være muligt at inddele cortexmodeller i hjernelapper samt brugerdefinerede områder. Det skal være muligt at få præsenteret kvantitative mål for hele cortex cerebri, hver hemisfære, de fire hjernelapper samt brugerdefinerede områder. Det skal være muligt at få tykkelsen på cortex cerebri illustreret på cortexmodeller med en farveskala. Det skal være muligt at betragte to cortexmodeller på brugergrænsefladen på samme tid og få informationer om forskellen mellem disse. Det skal være muligt at få vist forskellen mellem en cortexmodel og normaldata i tal. Det skal være muligt at eksportere relevante kvantitative mål. Prototypens grafiske brugergrænseflade skal være dansk.

26 .

27 Systemets overordnede 3 arkitektur På baggrund af foregående kapitel defineres systemets overordnede arkitektur. På figur 3. er den overordnede arkitektur illustreret. Det er valgt at systemet skal have en klient-server arkitektur, da dette har en række fordele for den måde systemet skal anvendes på. Flere brugere skal fra forskellige arbejdsstationer kunne tilgå systemets funktionaliteter, og for at undgå at en brugers arbejdsstation bliver belastet i længere tid, er det valgt at ligge hoveddelen af processeringen på en server. Alle større datavolumener skal opbevares på serveren. Dette gøres for at gøre data tilgængelig for alle brugere af systemet, minimere mængden af data som skal uploades fra klienten, samt for at gøre det muligt at implementere eventuelle sikkerhedssystemer og loginfunktioner. De data som skal gemmes på serveren omfatter MR-skanninger, patientinformation, cortexmodeller og tilhørende kvantitative mål. Klienten skal kun downloade det data, som der er behov for til en enkelt session. Når sessionen er afsluttet, data på klienten slettes. Bruger Visualisering Interaktion Arbejdsstation Netværk Bruger 2 Visualisering Interaktion Arbejdsstation 2 Netværk Netværk Server der bruges til processering og indeholder systemets database Visualisering Interaktion Bruger n Arbejdsstation n Figur 3.: Systemets overordnede arkitektur. Flere brugere kan fra forskellige arbejdsstationer tilgå samme server. Flere brugere kan også anvende den samme arbejdsstation.

28 .

29 Krav 4 På baggrund af analysen og systembeskrivelsen i kapitel 2, opstilles der i dette kapitel funktionelle krav til systemet. Dette gøres udfra en beskrivelse af systemets use cases. Use cases bruges til at beskrive systemets funktionelle krav, det vil sige hvilke services, opgaver og funktioner systemet skal varetage. En use case defineres som en afsluttet arbejdsgang, hvilket vil sige, at den håndterer en proces, fra den initieres af en aktør og til den ønskede funktionalitet er udført. Aktører fastlægges først i kapitlet, hvorefter de de enkelte use cases specificeres. 4. Aktører En aktør er en person eller ting, som bruger eller interagerer med systemet. I den prototype som udvikles og designes i dette projekt, er den eneste aktør til systemet brugeren af systemet. Forventede brugere af systemet er beskrevet i afsnit Use cases Dette afsnit indeholder et use case diagram, som viser relationer mellem de opstillede use cases. Efterfølgende gennemgås alle use cases med en beskrivelse og en specifikation. Figur 4. viser use case diagrammet for prototypen. De tre pile tilkoblet brugeren skal illustrere, at brugeren er aktør til samtlige use cases. De fire use cases placeret til højre i diagrammet extender alle use casene Vis hemisfære, Vis standard model, Sammenlign to modeller og Sammenlign to hemisfærer. Use casene Vis standard model, Vis hemisfære, Sammenlign to hemisfærer og Sammenlign to modeller skal håndtere alle visninger af cortexmodeller samt tilhørende kvantitative mål. Use casen Roter, flyt og zoom model skal håndtere rumlig manipulation af cortexmodeller. Use casene Vis farveskala for cortextykkelsen, Vis hjernelapper og Optegn område skal håndtere farvelægning og udvælgelse af områder på cortexmodellen. Yderligere findes fire use cases, som skal håndtere separate funktioner i systemet. Dette er Søg MR-skanning, Vis verificeringsbillede, Generer cortexmodel og Eksporter kvantitative mål. I det følgende vil der være en beskrivelse af samtlige use cases. Der er to prekonditioner, som er gældende for alle use cases, hvorfor disse nævnes her, og ikke gengives i alle beskrivelserne. Prekonditioner til alle use cases er, at systemet skal være tændt, og der skal være forbindelse til serveren.

30 6 Krav System Generer cortexmodel Søg MR-skanning Bruger Vis hemisfære <<extends>> <<extends>> Roter, flyt og zoom model Vis standardmodel <<extends>> Vis hjernelapper <<extends>> Sammenlign to modeller <<extends>> Sammenlign to hemisfærer <<extends>> <<extends>> Optegn område Vis farveskala for cortextykkelse Vis verificeringsbillede Eksporter kvantitative mål Figur 4.: Use case diagram for prototypen. Aktøren Bruger skal være aktør til alle use cases. De fire use case til højre i diagrammet skal extende use casene Vis hemisfære, Vis standard model, sammenlign to modeller og Sammenlign to hemisfærer, hvilket betyder, at de skal være afhængige af den use case de extender for at blive initieret Generer cortexmodel Denne use case skal initieres, når en bruger ønsker at generere en model af cortex cerebri. Det skal kun være muligt at generere en model, hvis der ikke eksisterer en i forvejen. Dette er baseret på, at der er en betydelige processeringstid forbundet med genereringen af en ny cortexmodel, samt at en ny generering ikke vil give flere informationer, end dem der allerede eksisterer. Når en ny model skal genereres, skal en MR-skanning vælges, hvorefter der skal sendes besked til serveren, om at denne skal generere modellen. Når en ny cortexmodel er genereret, skal denne gemmes i databasen og brugeren skal have besked om at genereringen er fuldendt. Når serveren genererer en model skal tilhørende kvantitative mål for cortexmodellen udledes og gemmes. Når en modellering er foretaget skal cortexmodellen og tilhørende kvantitative mål kunne hentes og visualiseres for alle brugere af systemet.

31 4.2 Use cases 7 Use case: Generer cortexmodel Prekonditioner: En MR-skanning uden tilhørende cortexmodel skal være tilgængelig Hændelser:. En MR-skanning skal vælges 2. En cortexmodel skal genereres og kvantitative mål skal udledes 3. Cortexmodel og kvantitative mål skal gemmes på databasen 4. Brugeren skal informeres om, at en generering er fuldendt Postkonditioner: Systemet skal have genereret en model af cortex cerebri med tilhørende kvantitative mål ud fra en MR-skanning Tabel 4.: Use case specifikation for Generer cortexmodel Søg MR-skanning Denne use case skal understøtte at brugeren skal have mulighed for søge efter MR-skanninger i databasen. Søgningen skal kunne finde sted ud fra kombinationer af CPR-nummer, køn, navn og alder. Det skal yderligere være muligt for brugeren at se om der findes en cortexmodel til en konkret MR-skanning, eller om det er nødvendigt at generere en. Når der indtastes et eller flere søgekriterier, skal det vises for brugeren hvilke MR-skanninger, som opfylder kriterierne og hvilke af disse, der allerede findes en cortexmodel til. Det skal også være muligt at se, hvis en cortexmodel er ved at blive genereret. Hvis en cortexmodel er genereret skal denne kunne åbnes ved at initialisere use casen Vis standard model. Ligeledes skal cortexmodeller kunne genereres ved at initialisere use casen Generer cortexmodel. Use case: Søg MR-skanning Prekonditioner: Hændelser:. Brugeren skal indtaste et eller flere søgekriterier 2. Søgningen skal foretages på databasen 3. Søgeresultaterne skal præsenteres for brugeren Postkonditioner: Systemet skal have vist søgeresultaterne for brugeren Tabel 4.2: Use case specifikation for Søg MR-skanning Vis standardmodel Denne use case understøtter, at brugeren kan få en standardmodel samt tilhørende kvantitative mål og forskelle fra normaldata vist. En standardmodel defineres som en model uden farve. Use casen skal igangsættes, når en cortexmodel åbnes, eller hvis brugeren ønsker at returnere til en standardmodel, hvis en anden visning er aktuel. Når en standardmodel vises, skal det være muligt at se hvilken patient og hvilken MR-skanning, cortexmodellen hører til.

32 8 Krav Use case: Vis standardmodel Prekonditioner: En cortexmodel skal være til rådighed Hændelser:. Brugeren skal åbne en cortexmodel eller returnere til visning af standardmodellen 2. En cortexmodel og tilhørende kvantitative mål skal vises på brugergrænsefladen Postkonditioner: En cortexmodel og tilhørende kvantitative mål skal være vist på på brugergrænsefladen Tabel 4.3: Use case specifikation for Vis standardmodel Vis hemisfære Denne use case skal understøtte at vise en hemisfære alene. Brugeren skal via brugergrænsefladen specificere at en hemisfære ønskes vist samt hvilken. Herefter skal en hemisfære vises i 3D og hvis systemet er indstillet med en bestemt formatering, fx med visning af hjernelapper, når funktionaliteten vælges, skal denne formatering bibeholdes. Kvantitative mål for begge hemisfærer og forskel fra normal data skal også visualiseres for brugeren. Når en hemisfære vises, skal det være muligt at se, hvilken patient og hvilken MR-skanning, hemisfæren hører til. Use case: Vis hemisfære Prekonditioner: En cortexmodel skal være til rådighed Hændelser:. Brugeren skal vælge at se højre eller venstre hemisfære 2. Den valgte hemisfære skal vises på brugergrænsefladen med tilhørende kvantitative mål og forskelle fra normaldata Postkonditioner: Systemet skal have vist en hemisfære sammen med tilhørende kvantitative mål og forskelle fra normaldata Tabel 4.4: Use case specifikation for Vis hemisfære Sammenlign to modeller Denne use case gør det muligt at sammenligne to cortexmodeller med hinanden. Dette sker ved, at brugeren vælger at sammenligne to cortexmodeller, hvorefter disse visualiseres for brugeren. Ud over at visualisere de to cortexmodeller er use casen ansvarlig for at beregne og visualisere kvantitative mål samt forskellen i tykkelse, volumen og overfladeareal for de fire hjernelapper, hver hemisfære samt hele hjernen. Når to cortexmodeller sammenlignes, skal det være muligt at se, hvilke patienter og hvilke MR-skanninger, begge cortexmodellen hører til.

33 4.2 Use cases 9 Use case: Sammenlign to modeller Prekonditioner: To cortexmodeller skal være tilgængelige Hændelser:. Brugeren skal vælge to cortexmodeller, som skal sammenlignes 2. Forskellen imellem to cortexmodeller skal udregnes 3. To modeller skal visualiseres med tilhørende kvantitative mål og forskellen mellem modellerne skal opgives i tal Postkonditioner: Forskellen imellem to cortexmodeller skal være beregnet Systemet skal have visualisere to modeller af cortex cerebri med tilhørende kvantitative mål og forskelle Tabel 4.5: Use case specifikation for Sammenlign to modeller Sammenlign to hemisfærer Denne use case gør det muligt at sammenligne to hemisfærer med hinanden. Dette sker ved, at en bruger skal vælge at sammenligne enten højre eller venstre hemisfære for to modeller, hvorefter disse visualiseres. Ud over at visualisere to cortexmodeller skal use casen være ansvarlig for at beregne og visualisere kvantitative mål samt forskellen i tykkelse, volumen og overfladeareal for de fire hjernelapper, hver hemisfære samt hele hjernen. Når to hemisfærer skal sammenlignes, skal det være muligt at se, hvilke patienter og hvilke MR-skanninger, begge hemisfærer hører til. Use case: Sammenlign to hemisfærer Prekonditioner: To cortexmodeller skal være tilgængelige Hændelser:. To hemisfærer skal vælges til sammenligning 2. Forskellen imellem to hemisfærer skal beregnes 3. To hemisfærer skal visualiseres med tilhørende kvantitative mål og forskelle imellem hemisfærerne angives Postkonditioner: Forskellen imellem to hemisfærer skal være beregnet Systemet skal have visualiseret to hemisfærer med tilhørende kvantitative mål og forskelle Tabel 4.6: Use case specifikation for Sammenlign to hemisfærer Roter, flyt og zoom model Denne use case skal understøtte at brugeren kan se cortexmodeller fra alle sider og vinkler. For alle visninger, som er specificeret af use casene Vis standard model og Vis hemisfære, skal det være muligt at zoom ind og ud, flytte modellen i det horisontale og vertikale plan, det vil sige mod højre, venstre, frem og tilbage samt at rotere modellen omkring en vertikal og horisontal akse. Funktionaliteten skal være tilstede i form af knapper på brugergrænsefladen, via et tastatur og vis en mus. Dette skyldes, at når klinikere arbejder med medicinske billeder, anvender de musen meget, hvorfor det er hensigtsmæssigt at have forskellige værktøjer, som kan bruges til navigering [Johannsen, 2008]. Desuden skal seks predefinerede visninger være tilgængelige, som brugeren kan indrette modellen efter ved et enkelt klik. Disse

34 20 Krav visninger er frontalt, posterior, superior, inferior og venstre lateral og højre lateral. Dette var ligeledes et ønske fra de adspurgte klinikere. Use case: Roter, flyt og zoom model Prekonditioner: Use casen Vis standard model, Vis hemisfære, Sammenlign to hemisfærer eller Sammenlign to modeller skal være initieret Hændelser:. Brugeren skal vælge zoom, flyt, roter eller en predefineret visning 2. Den viste model skal indstilles som specificeret af brugeren Postkonditioner: Den viste model skal være placeret som specificeret af brugeren Tabel 4.7: Use case specifikation for Roter, flyt og zoom model Vis hjernelapper Denne use case skal understøtte indtegning af hjernelapper på cortexmodellen således, at brugeren får visualiseret, hvilken del af cortex cerebri, der hører til frontal-, parietal-, temporal- og occipitallappen. Hjernelapper skal kunne optegnes i visningerne specificeret af use casene Vis standard model, Vis hemisfære, Sammenlign to hemisfærer og Sammenlign to modeller. Use case: Vis hjernelapper Prekonditioner: Use casen Vis standard model, Vis hemisfære, Sammenlign to hemisfærer eller Sammenlign to modeller skal være initieret Hændelser:. Brugeren skal vælge at få vist hjernelapper på en cortexmodel 2. Hjernelapper skal vises på cortexmodellen Postkonditioner: Hjernelapper skal være indtegnet på den viste cortexmodel Tabel 4.8: Use case specifikation for Vis hjernelapper Optegn område Denne use case skal understøtte optegnelsen af et brugerdefineret område på en cortexmodel. Yderligere skal den understøtte, at kvantitative mål for det brugerdefinerede område udregnes og vises for brugeren. Use casen kræver, at en cortexmodel vises på brugergrænsefladen. Dette skal enten være en cortexmodel eller en enkelt hemisfære. Use casen skal give brugeren mulighed for at udtrække kvantitative mål for det optegnede område. Det skal desuden være muligt at få cortextykkelsen vist i et enkelt punkt.

35 4.2 Use cases 2 Use case: Optegn område Prekonditioner: Use casen Vis standard model eller Vis hemisfære skal være initieret Hændelser:. Brugeren skal vælge at optegne et område 2. Brugeren skal optegne et område eller et enkelt punkt på cortexmodellen 3. Området skal visualiseres på den viste model 4. Kvantitative mål for området eller punktet skal vises Postkonditioner: Brugeren skal få vist information om et optegnet område Tabel 4.9: Use case specifikation for Optegn område Vis farveskala for cortextykkelse Denne use cases skal understøtte, at brugeren kan få vist en model, hvor cortextykkelsen er visualiseret med en farveskala. Forskellige farver i farveskalaen skal være et direkte udtryk for forskellige tykkelser på cortex cerebri. Farveskalaen skal kunne anvendes i forbindelse med visninger specificeret af use casene Vis standard model, Vis hemisfære, Sammenlign to modeller og Sammenlign to hemisfærer. Use case: Vis farveskala for cortextykklse Prekonditioner: Use casen Vis standardmodel, Vis hemisfære, Sammenlign to hemisfærer eller Sammenlign to modeller er aktiv Hændelser:. Brugeren skal vælge at se en cortexmodel markeret med en farveskala, som viser tykkelsen af cortex cerebri. 2. En cortexmodel skal visualiseres med en farveskala, som indikere tykkelsen Postkonditioner: Farveskalaen skal være visualiseret på cortexmodellen Tabel 4.0: Use case specifikation for Vis farveskalaen for cortextykkelse 4.2. Vis verificeringsbilleder Denne use case skal understøtte, at brugeren har mulighed for at foretage en kvalitativ verificering af om cortexmodellerne er korrekte. Dette skal sker ved, at brugeren skal præsenteres for verificeringsbilleder, som er 2D-snitplaner af cortexmodellen indtegnet på oprindelige MR-skanninger. Herudfra skal brugeren kunne verificere cortexmodellen. Det skal herefter være op til brugeren at vurdere, om segmenteringskonturen ligger tilfredsstillende på cortex cerebris kontur. Når et verificeringsbillede vises, skal det være muligt at se hvilken patient og hvilken MR-skanning, verificeringsbillederne hører til.

36 22 Krav Use case: Vis verificeringsbilleder Prekonditioner: En cortexmodel skal være til rådighed Hændelser:. Brugeren skal vælge at få verificeringsbilleder vist 2. Verificeringsbilleder skal vises Postkonditioner: Verificeringsbilleder skal være vist på brugergrænsefladen. Tabel 4.: Use case specifikation for Vis verificeringsbilleder Eksporter kvantitative mål Denne use case skal understøtte, at det skal være muligt at eksportere kvantitative mål fra systemet. Når kvantitative mål skal eksporteres, skal brugerne vælge hvilke kvantitative mål, som ønskes eksporteret, samt hvilke modeller disse mål skal stamme fra. Det skal være muligt at eksportere kvantitative mål fra flere patienter på samme tid. Yderligre skal det være muligt at igangsætte eksport, selvom en model endnu ikke er genereret, eller hvis en model er under generering. Eksport af kvantitative mål skal ske til en kommasepareret fil. Use case: Eksporter kvantitative mål Prekonditioner: Hændelser:. Brugeren skal vælge hvilke kvantitative mål, der skal eksporteres, samt hvilke modeller disse skal komme fra 2. Data skal eksporteres til en komma separeret fil Postkonditioner: Systemet skal have gemt det ønskede data i en kommasepareret fil. Tabel 4.2: Use case specifikation for Eksporter kvantitative mål

37 Design af grafisk 5 brugergrænseflade I projektet er der designet en grafisk brugergrænseflade, som skal gøre det muligt at anvende funktionaliteterne defineret i use casene i afsnit 4.2, samt håndtere informationsudveksling mellem bruger og program. Der er under designet taget højde for feedback fra interviews, som der findes referater af i bilag 6 og low-fidelity test, som der findes beskrivelse af i bilag 8. Desuden er der anvendt generelle designprincipper vedrørende design af brugergrænseflader. Den overordnede teori bag disse principper findes i appendiks E. Den grafiske brugergrænseflade er designet ved først at identificere grafiske elementer, som skal være indeholdt i designet. Med et grafisk element menes et område af brugergrænsefladen, hvori der skal præsenteres funktionaliteter af en bestemt type, fx visualisering. I dette kapitel identificeres de grafiske elementer, hvorefter sammenhængen mellem disse præsenteres. Herefter præsenteres hvert grafisk element seperat. Alle grafiske elementer er igennem rapporten præsenteret med skrifttypen: GrafiskElement. 5. Identifikation af grafiske elementer Følgende grafiske elementer er blevet identificeret under design af systemet. Programramme skal danne selve rammen omkring prototypen, hvori andre grafiske elementer skal placeres. Med til Programramme skal høre en programmenu, hvorfra det skal være muligt at tilgå andre grafiske elementer, som ikke skal vises som faste elementer i Programramme. Visualisering skal varetage visualisering af cortexmodeller og verificeringsbilleder. Baggrundsfarven på dette element skal være sort, da denne baggrundsfarve er set anvendt i andre brugergrænseflader til visualisering af kliniske billeder. Patientinformation skal varetage præsentation af information om patienten. Denne information skal være tilgængelig, når en cortexmodel eller verificeringsbilleder vises. Værktøjskasse skal samle alle funktionaliteter, der gør det muligt for brugeren at manipulere med cortexmodeller og verificeringsbilleder, som er vist i Visualisering. Ved at samle disse i elementet Værktøjskasse, vil brugeren let kunne finde alle værktøjer. Desuden understøttes, at det område hvori musen skal bevæges for at tilgå disse funktionaliteter mindskes, hvilket gør brugen af prototypen mere effektiv. Et eksempel på et værktøj er rotering af cortexmodeller. Måleresultater skal varetage visning af kvantitative mål. Visningen skal altid være opdateret, således den viser kvantitative mål for den eller de cortexmodeller, som findes i Visualisering. Åbn/Generer skal varetage åbning og generering af cortexmodeller. Elementet skal vise brugeren, hvilke MRskanninger der er tilgængelige i systemet, og hvilke af disse, der har en cortexmodel tilknyttet. Elementet skal yderligere gøre det muligt at generere cortexmodeller til de MR-skanninger, der endnu ikke har en tilknyttet. Det skal desuden understøttes, at flere genereringer af cortexmodeller kan sættes i kø. Sammenlign skal varetage åbningen af en ny cortexmodel, der skal sammenlignes med en cortexmodel, som i forvejen er vist på brugergrænsefladen. Funktionaliteten som skal varetages af Sammenlign, minder meget om de funktionaliteter, som skal varetages af Åbn/Generer. Grunden til at Sammenlign alligevel identificeres som et separat element er, at brugeren derved aktivt skal vælge at sammenligne to cortexmodeller. Hvis det kun var muligt at vælge Åbn/Generer, kunne der opstå tvivl om, hvorvidt den nuværende cortexmodel skulle lukkes eller bruges under sammenligning.

38 24 Design af grafisk brugergrænseflade Eksporter skal varetage udvælgelse og udtræk af kvantitative mål hørende til forskellige cortexmodeller. Elementet skal præsentere brugere for tilgængelige MR-skanninger og kvantitative mål, og gøre det muligt at eksportere disse til en fil. Hvis der ikke er tilknyttet en cortexmodel til en MR-skanning, skal brugeren have mulighed for at generere denne. Dialogbokse skal gøre brugeren opmærksom på hændelser i systemet. Dette kan fx være, når en generering af en cortexmodel er fuldført, eller hvis der er sket en fejl i systemet. 5.2 Sammenhæng mellem grafiske elementer Det er valgt at de grafiske elementer Patientinformation, Visualisering, Værktøjskasse og Måleresultater skal have en fast placering i Programramme. Denne placering er illustreret i en konceptuel model, som kan ses på figur 5.. Figur 5.: Konceptuelt design over placeringen af grafiske elementer, som skal være indeholdt i Programramme Det grafiske element Patientinformation skal placeres i øverste venstre hjørne af Visualisering. Dette skyldes, at det er her klinikere er vant til at kunne finde oplysninger om patienten på medicinske billeder [Larsson, 2008] [Johannsen, 2008]. De to elementer Måleresultater og Værktøjskasse skal placeres yderst til højre i en søjle. Denne placering er valgt, fordi det er disse to elementer, som brugerne forventes at komme til at anvende mest. Elementerne skal dermed også som standard være synlige på brugergrænsefladen, for at følge et designprincip om synlighed af mest anvendte funktionaliteter. Ved at placere elementerne tæt på hinanden minimeres bevægelse med musen, hvilket gør brugen af systemet mere effektiv. Yderligere giver denne placering mest muligt plads til Visualisering, som skal udgøre den resterende plads i Programramme. De to klinikere, som er blevet interviewet i dette projekt, var ikke enige om vigtigheden af at kunne skjule Værktøjskasse og Visualisering, således Visualisering kan fylde hele skærmbilledet. Argumentet imod var, at den ekstra plads som menuerne repræsenterer, ikke er vigtig, idet cortexmodeller allerede kan vises i tilnærmelsesvis fuld størrelse på en normal skærm [Johannsen, 2008]. Den ekstra plads findes derimod værdifuld af andre brugere [Larsson, 2008], hvorfor det skal være muligt at skjule de grafiske elementer Værktøjskasse og Visualisering.

39 5.3 Design af grafiske elementer 25 Det skal yderligere være muligt, at skjule Patientinformation, da det er vigtigt at kunne præsentere billeder i forskellige sammenhænge, uden at der er personfølsomme oplysninger tilknyttet [Larsson, 2008]. Et alternativ til det valgte design er, at alle grafiske elementer kunne have et selvstændigt vindue, der frit kan flyttes og skaleres. Dette ville øge brugerens valgfrihed i systemet og understøtte brugen af flere skærme, som det ofte ses på kliniske afdelinger. Grunden til det er valgt at fastholde de fire grafiske elementer i Programramme er, at det er blevet vurderet, at dette vil øge overskueligheden for brugeren, og gøre programmet lettere at anvende. Dette skyldes, at der ikke kan forekomme skjulte eller lukkede vinduer, der gør manipulering fra et grafisk element til et andet uoverskueligt. Da funktionaliteterne, som de fire grafiske elementer understøtter, er meget sammenkoblede, er det yderligere uhensigtsmæssigt at adskille dem fra hinanden. Dog vil et endeligt system skulle understøtte brugen af flere skærme. Dette kunne implementeres, ved at gøre det muligt at fritstille en eller flere instanser af det grafiske element Visualisering med tilhørende Patientinformation. Denne funktionalitet udvikles dog ikke i prototypen. I designet er de grafiske elementer Åbn/Generer, Sammenlign, Eksporter og DialogBokse ikke indeholdt, fordi de ikke skal være faste elementer i Programramme. Åbn/Generer, Sammenlign og Eksporter beskæftiger sig alle med, hvilke cortexmodeller og/eller kvantitative mål, brugeren skal se. Når en bruger anvender programmet, vil disse funktioner derfor benyttes sjældent i forhold til de funktioner, der er indeholdt i de grafiske elementer på figur 5.. Åbn/Generer, Sammenlign og Eksporter skal derfor være mindre tilgængelig og skal tilgås via programmenuen. Dette er hensigtsmæssigt, fordi drop down menuer i øverste venstre hjørne ofte bruges til åbning af filer i windowsbaserede programmer, hvorfor brugere vil have en reference til deres daglige brug af software. DialogBokse skal ikke initieres direkte af brugeren, men skal være dialogbokse, der genereres automatisk efter behov, hvorfor placeringen af disse i relation til andre grafiske elementer ikke omtales yderligere. 5.3 Design af grafiske elementer 5.3. Programramme Det grafiske element Programramme skal udgøre brugergrænsefladens yderste kanter, knapper til at minimere, maximere og lukke brugergrænsefladen samt en menulinie, som skal indeholde drop-down menuen programmenu. Det overordnede design af Programramme kan ses på figur 5.. Placering og udformning af minimer, maksimer og afslut program knapperne i Programramme, følger et design, der er tilsvarende software, som er velkendt for brugeren. Ligeledes skal det være muligt at ændre størrelsen på Programramme ved at hive i kanterne. Programmenuen, som skal være indeholdt i Programramme, kan ses på figur 5.2. I menuen skal der være menupunkter, som skal gøre det muligt at initiere de grafiske elementer Åbn/Generer, Sammenlign og Eksporter. Programmenuen skal yderligere indeholde menupunkter, som gør det muligt at lukke de viste cortexmodeller samt at afslutte programmet. Indholdet i drop down menuen er sorteret efter de overordnede funktionalitetstyper åbn og luk, som er adskilt med en separator. Det skal ikke være muligt at vælge et menupunkt, hvis funktionalitet ikke giver mening. Fx skal der ikke kunne vælges luk cortexmodeller, hvis der ikke er nogle cortexmodeller åbne.

40 26 Design af grafisk brugergrænseflade Figur 5.2: Design af programmenu Visualisering Det grafiske element Visualisering skal varetage forskellige visuelle præsentationer af cortexmodeller og verificeringsbilleder. De forskellige visualiseringsmuligheder skal initialiseres ved, at brugeren vælger dette via det grafiske elementet Værktøjskasse. Der er dog defineret en standardvisning, som altid skal præsenteres som det første, når en cortexmodel åbnes. I det følgende beskrives forskellige visualiseringsmuligheder, som alle er illustreret på figur 5.3. Vis hele cortex cerebri. Denne visning skal være standardvisningen i systemet, og præsenteres når brugeren åbner en ny cortexmodel. Standardvisningen skal vise en cortexmodel med en ensfarvet grå overflade og være orienteret superiort. Et eksempel på en standardvisning kan ses på figur 5.3a. Brugeren skal altid have mulighed for at vende tilbage til denne visning. Vis venstre eller højre hemisfære. Hver hemisfære skal kunne vises seperat. En illustration med én hemisfære vist ses på figur 5.3b. Inddel cortexmodel i lapper. Cortexmodeller skal kunne inddeles i frontal-, parietal-, occipital- og temporallappen ved at repræsentere forskellige lapper med forskellige farver. Farverne skal være blå, gul, rød og grøn, således at der let kan differentieres mellem lapperne, se figur 5.3c. Disse farver er valgt, fordi det ifølge retningslinjer for farver i brugergrænsefladedesign, er farver der er lette at huske [Wright et al., 2004]. Farverne skal yderligere dæmpes til pastelfarver, da meget mættede farver kan gøre øjet træt [Wright et al., 2004]. Vis tykkelse på cortexmodellen. Tykkelsen af cortex cerebri skal kunne visualiseres således, at overfladen af cortexmodellen er farvelagt med en farveskala, der indikerer, hvordan cortextykkelsen varierer på modellen. Der skal i denne visning være en skala nederst i Visualisering, der viser farvernes korrespondance til tykkelserne af cortex cerebri. Denne illustrering af cortextykkelse ved brug af farveskala er illustreret på figur 5.3d. I litteraturen er forskellige farveskalaer brugt til repræsentation af cortextykkelse. Eksempler gående fra tynd til tyk er grå/rød/gul [Plesniak et al., 2007], blå/turkis/hvid/gul/rød [Chung et al., 2007], grøn/grå/rød [Fischl og Dale, 2000] og grøn/brun/orange [Zeng et al., 999]. Det generelle billede er, at farveskalaerne går fra klare kolde farver over en neutral farve til klare varme farver. Skalaen der vælges i dette projekt er blå/turkis/hvid/gul/orange. Denne skalaen er er valgt efter forslag fra Chung et. al 2007, dog med undtagelse af den røde farve, da denne kan signalere fejl eller fare [Wright et al., 2004]. Farveskalaen i prototypens design, inklusiv visning af tykkelse på cortexmodellen, kan ses på figur 5.4. Vis to cortexmodeller. To cortexmodeller skal kunne præsenteres på samme tid i det grafiske element Visualisering, som er illustreret på figur 5.3e. De skal vises på denne måde for at opnå størst mulig plads til cortexmodellerne. Denne visningstype skal også kunne anvendes, når to hemisfærer skal vises, og cortexmodellerne skal kunne farvelægges efter tykkelse og lappeinddeling. Når to cortexmodeller er vist, skal tabellerne, der indgår i det grafiske element Måleresultater ændres, så disse indeholder information om begge hjerner.

41 5.3 Design af grafiske elementer 27 Vis verificeringsbilleder. Verificeringsbilleder skal kunne vises i elementet Visualisering, ligesom det ses på figur 5.3f. Vis brugerdefinerede områder. Hvis en cortexmodel har tilkoblet et eller flere brugerdefinerede områder, skal disse kunne visualiseres på cortexmodellen. Der er illustreret et brugerdefineret område på figur 5.3g. Når brugerdefinerede områder er markeret på en cortexmodel, skal det grafiske element Måleresultater vise kvantitative mål hørende til brugerdefinerede områder Figur 5.3: Figuren illustrerer de forskellige visninger, der skal være mulige i det grafiske element Visualisering. Figur 5.4: Farveskala og tilhørende tykkelsesangivelse, der skal bruges til at visualisere cortextykkelse Patientinformation Patientinformation skal indeholde følgende: Oplysning om patientens CPR-nummer, navn og optagelsedato for MR-skanningen. I forhold til prototypens formål, er det denne information, der er relevant [Johannsen, 2008]. Det grafiske element designes således, at baggrunden er gennemsigtig, så cortexmodellen kan ses bag teksten, hvis denne skulle overlappe elementet. Designet af Patientinformation er illustreret i figur 5.5.

42 28 Design af grafisk brugergrænseflade Figur 5.5: Det grafiske element Patientinformation Værktøjskasse Det grafiske element Værktøjskasse skal indeholde værktøjer, som gør det muligt for brugeren at ændre visningen i det grafiske element Visualisering. Det er valgt, at inddele funktionaliteterne i kategorier afhængigt af, hvad den enkelte funktionalitet har indflydelse på. Der identificeres fem kategorier af funktionaliteter nemlig navigering, visualisering, farvelæg, indtegn område og skjul. Funktionaliteterne navigering, visualisering, farvelæg og indtegn område skal præsenteres for brugeren med fire faneblade, et til hver kategori. Dette gøres for at præsentere brugeren for et minimum af valg af gangen, og dermed følge et designprincip om begrænsning. Brugeren vil således kunne finde et værktøj ud fra, hvilken kategori værktøjet hører ind under. Fanebladet navigering skal være det faneblad, der som standard er synligt, da værktøjer til navigering i følge de adspurgte klinikere typisk vil være de mest anvendte værktøjer. Indholdet af de fire faneblade kan ses på figur 5.6, 5.7, 5.8 og 5.9 og beskrives nærmere i de følgende afsnit. Da det skal være muligt at skjule Værktøjskassen, skal der nederst i dette element findes en knap med titlen skjul menuer, som gør det muligt at skjule både Værktøjskasse og Måleresultater. Når de to grafiske elementer skjules skal de erstattes af en knap vis menuer, der kan få menuerne frem igen. Desuden skal der nederst i Værktøjskasse være en knap, der har titlen skjul patientinformation. Ved tryk på denne knap skal elementet Patientinformation skjules. Når Patientinformation skjules, skal der fremkomme en knap med titlen vis patientinformation, der kan vise patientinformationen igen. Navigering Værktøjer som skal være tilgængelige via fanebladet navigering, skal gøre det muligt for brugeren at rotere, flytte og zoome ind og ud på cortexmodeller samt flytte og zoome ind og ud på verificeringsbilleder, der vises i Visualisering. Indholdet af fanebladet navigering er illustreret på figur 5.6. Fanebladet skal desuden indeholde knapper, som ved et enkelt klik gør det muligt, at kunne se cortexmodeller fra følgende vinkler: Anterior, posterior, superior, inferior, venstre lateral og højre lateral. Knapperne til navigering skal designes med ikoner, så det nemt kan ses, hvilken knap der udfører hvilken navigeringsfunktion. Det skal også være muligt at navigere mellem hvilken/hvilke modeller, som skal reagere på knapperne i fanebladet. Dette skal gøres ved, at designe radio buttons, som giver brugeren mulighed for at vælge om den øvre model, den nedre model eller begge modeller skal reagere på knapperne til navigering. Når systemet åbnes, skal det som standard være afkrydset, at begge cortexmodeller skal reagere på knapperne, hvis der er valgt sammenligning af to cortexmodeller. Hvis kun en cortexmodel er åben, skal feltet være inaktivt.

43 5.3 Design af grafiske elementer 29 Ud over at kunne navigere via værktøjerne i Værktøjskasse, er det et krav, at navigering skal kunne foregå via musen og tastaturet. Prototypen skal derfor designes således, at cortexmodeller kan vises fra de seks prædefinerede vinkler ved at anvende knapperne <> til <6> på tastaturet. Cortexmodeller skal kunne flyttes ved at holde højre museknap inde og flytte på musen eller ved at bruge piletasterne på tastaturet. Rotation skal være mulig ved at holde venstre museknap inde og flytte på musen eller ved at holde <Ctrl> inde og bruge piletasterne på tastaturet. Yderligere skal det være muligt at zoome på cortexmodeller ved at scrolle med musen og trykke på <+> og <-> knapperne på tastaturet. En beskrivelse af alle genvejstaster, der kan anvendes, skal være at finde i brugergrænsefladen. Figur 5.6: Indholdet i Værktøjskasse under fanebladet navigering. Visualisering Fanebladet visualisering skal håndtere, hvilken del af cortexmodellen, der skal vises i Visualisering. Valg af visning skal foretages med radio buttons. Dette skyldes, at kun en form for visualisering er mulig, hvorfor det ikke vil give mening at kunne afkrydse to visningsmuligheder. Som standard skal systemet vise hele cortex cerebri. Indholdet af fanebladet er illustreret på figur 5.7. Der skal desuden kunne skiftes mellem de forskellige visninger af cortexmodeller ved at bruge knappen <7> på tastaturet. Knappen <9> på tastaturet skal kunne frembringe visualiseringsbilleder for den valgte cortexmodel.

44 30 Design af grafisk brugergrænseflade Figur 5.7: Indholdet i Værktøjskasse under fanebladet visualisering. Farvelæg Fanebladet Farvelæg skal gøre det muligt for brugeren at få farvelagt cortexmodeller. Designet af fanebladet kan ses på figur 5.8. Fanebladet skal indeholde radio buttons, som gør det muligt at vælge, hvordan cortexmodeller skal farvelægges. Som standard skal det være afkrydset at cortexmodeller skal vises uden farve. Der skal desuden kunne skiftes mellem de forskellige farvelægninger af cortexmodellen ved at anvende knappen <8> på tastaturet. Figur 5.8: Indholdet i Værktøjskasse under fanebladet farvelæg.

45 5.3 Design af grafiske elementer 3 Indtegn område Fanebladet indtegn område skal gøre det muligt for brugeren at indtegne et område af interesse på cortexmodellen, navngive dette samt slette eksisterende brugerdefinerede områder. Indholdet af fanebladet indtegn område er illustreret på figur 5.9 Figur 5.9: Indholdet i Værktøjskasse under fanebladet indtegn område. Efter tryk på knappen indtegn nyt område skal brugeren kunne indtegne et område på cortexmodellen. Musemarkøren skal ved indtegning være ændret fra en pil til et kryds. Ved placering af punkter på cortexmodellen skal disse forbindes, så snart brugeren har placeret dem. Hermed kan brugeren se, hvordan området kommer til at se ud. En optegning skal afsluttes med <Enter>. Brugeren skal have mulighed for at navngive et område, så der kan differentieres mellem brugerdefinerede områder, såfremt der er indtegnet flere. Desuden skal det være muligt at gemme områder, ved at trykke på knappen gem som, der skal åbne et vindue, hvor det er muligt at navngive et område. Ligeledes skal brugeren have mulighed for at slette et område ved at trykke på knappen slet markeret område. Knappen skal kunne bruges, når et område er under optegning, og hvis et område er markeret Måleresultater Det grafiske element Måleresultater skal formidle kvantitative mål for cortexmodeller til brugeren. Informationen skal formidles via tabeller under fire forskellige faneblade: volumen, tykkelse, areal og brugerdefinerede områder. Fanebladet volumen skal være det faneblad, der som standard skal være synligt, da de adspurgte klinikere gav udtryk for, at det hovedsageligt er disse mål, der vil være interessante. Det grafiske element kan ses på figur 5.0 Tabelindholdet afhænger af, om der er én eller to cortexmodeller åbne. Hvis én model er åben, er tabelindholdet følgende: Første kolonne skal indeholde navnene på regioner i cortexmodellen. Rækkerne tilhørende de fire hjernelapper skal markeres med farver, der matcher de farver, som benyttes til at illustrere de forskellige hjernelapper på cortexmodellen. Dette er gjort for at gøre tabellen overskuelig, da lo-fi testen viste at overskueligheden af tabellerne kunne være et problem.

46 32 Design af grafisk brugergrænseflade Anden kolonne skal indeholde mål for volumen, tykkelse eller overfladeareal til de forskellige regioner afhængigt af hvilket faneblad, der er åbent. Når tykkelse er valgt, skal gennemsnitstykkelse for de forskellige områder vises. Disse skal derfor repræsenteres som en værdi og en standardafvigelse. Areal og volumen skal kun repræsenteres som værdier. Tredje kolonne skal indeholde normaldata for areal, tykkelse og volumen. Disse skal angives med en værdi og en standardafvigelse, der repræsenterer biologisk variation. Fjerde og femte kolonne skal vise, hvor meget cortex cerebri afviger fra normaldata, angivet i metrisk afvigelse og antal standardafvigelser (antal std.). Afvigelserne repræsenteres metrisk og i antal standardafvigelser efter ønske fra de adspurgte klinikere [Larsson, 2008] [Johannsen, 2008]. Figur 5.0: Figuren illustrerer det grafiske element Måleresultater, når én cortexmodel er valgt. I dette faneblad præsenteres kvantitative mål for gennemsnitstykkelsen. Hvis to modeller er åbne, skal fanebladet se ud som på figur 5., og tabelindholdet skal være som følgende: Første kolonne skal indeholde navnet på regionerne og er tilsvarende tabelindholdet på figur 5.0 Anden og tredje kolonne skal indeholde volumen, tykkelse eller areal for den cortexmodel, der vises henholdsvis øverst og nederst i elementet Visualisering. Fjerde og femte kolonne skal indeholde differencen mellem de to modeller. Differencen skal angives i metriske værdier og i procent, da de adspurgte klinikere fandt disse differencer mest anvendelige, når to cortexmodeller skulle sammenlignes [Larsson, 2008] [Johannsen, 2008].

47 5.3 Design af grafiske elementer 33 Figur 5.: Det grafiske element Måleresultater, når to cortexmodeller er valgt. I dette eksempel præsenteres kvantitative mål for volumen. Det skal være muligt at få uddybende informationer om, hvad hver kolonne indeholder, da lo-fi testen viste, at dette kunne være svært at gennemskue udfra de korte navne på kolonnerne. Den uddybende information skal præsenteres ved, at der skal fremkomme tooltips, når musen holdes hen over det øverst felt i hver kolonne. Fanebladet brugerdefinerede områder skal indeholde kvantitative mål for brugerdefinerede områder. Tabellen skal indeholde følgende fire kolonner: region, tykkelse, volume og areal. Første kolonne skal indeholde navne på de brugerdefinerede områder, og de tre sidste kolonner skal indeholde tilhørende kvantitative mål, se figur 5.2. Da brugerdefinerede områder defineres af brugeren, eksisterer der ikke et sammenligningsgrundlag, hvorfor der ikke skal være en kolonne til differencer. Fanebladet skal med samme begrundelse ikke kunne benyttes, hvis to cortexmodeller er åbne. Tabellen for de brugerdefinerede områder skal også kunne benyttes til at vælge et område med henblik på at omdøbe eller slette dette. Trykkes på en række i tabellen, skal rækken markeres, og det skal være muligt at omdøbe eller slette dette område i Værktøjskasse.

48 34 Design af grafisk brugergrænseflade Figur 5.2: Indholdet af fanebladet brugerdefinerede områder Åbn/Generer Det grafiske element Åbn/Generer skal initialiseres ud fra programmenuen. Når menupunktet Åbn/generer cortexmodel vælges, skal der åbnes et vindue som på figur 5.3. Formålet med dette vindue er at give brugeren et overblik over, hvilke MR-skanninger der findes i systemet. Efterfølgende skal det være muligt for brugeren at vælge at få genereret cortexmodeller eller åbne eksisterende cortexmodeller. Åbn/Generer er inddelt i 3 områder. Panel a som indeholder en skanningsliste over patienter i systemet, panel b som er søgefelter, og panel c som indeholder knapper. De tre paneler gennemgås herunder enkeltvist. a b c Figur 5.3: Det grafiske element Åbn/Generer består af en skanningsliste (panel a), et søgefelt (panel b) og knapper (panel c). Skanningsliste Skanningslisten, som er illustreret på figur 5.3a, skal vise MR-skanninger af patienter og være sorteret efter CPRnummer, da dataselektering primært forventes at blive foretaget herudfra [Larsson, 2008] [Johannsen, 2008]. Når

49 5.3 Design af grafiske elementer 35 Åbn/Generer initieres, skal MR-skanninger for alle patienter i systemet vises for brugeren. For hurtigt at kunne verificere, at det er den rigtige patient brugeren kigger på, skal patientens navn angives ved siden af CPR-nummeret. I skanningslisten skal det yderligere kunne ses, hvor mange MR-skanninger som findes til hver patient, samt hvilken dato disse er foretaget. Hvis der findes mere end én MR-skanning til en patient, skal det altid være den nyeste dato, som kan ses. Datoerne for de resterende MR-skanninger skal kunne tilgås ved at klikke i patientens række i tabellen, hvorved en liste over tilgængelige MR-skanninger skal fremkomme. Listen skal også indeholde information om, hvorvidt der findes en cortexmodel hørende til MR-skanningerne. Søgefelter Søgefelteterne, som er illustreret på figur 5.3 i panel b, skal være indtastningsfelter, som gør det muligt at søge efter patienter. Dette gør, at MR-skanninger og cortexmodeller for bestemte patienter kan findes hurtigt og let. I tilfælde af, at der ikke er indtastet noget i søgefelterne, skal listen vise samtlige patienter i systemet. Ved indtastning i fx CPR søgefeltet, skal listen reduceres til kun at vise patienten med det indtastede CPR-nummer. Ved kun delvis indtastning af CPR-nummer skal listen stadig reduceres, så den kun indeholder patienter, hvis CPR-nummer indeholder samme tal, som det i søgefeltet indtastede. Slettes det indtastede CPR-nummer, skal listeindholdet udvides igen til den komplette liste over patienter i systemet. Det samme princip skal gælde, når der søges i andre søgefelter. Knapper Knapperne, som er illustreret på figur 5.3 i panel c, skal benyttes til at åbne en eksisterende cortexmodel, starte en cortexmodellering af en MR-skanning og lukke vinduet. For at øge brugervenligheden i systemet, skal alle knapper designes således, at det kun skal være muligt at trykke på dem i det tilfælde, hvor funktionaliteten kan anvendes. En hensigtsmæssig måde at vise brugeren at en funktionalitet ikke er tilgængelig, er ved at gøre knapper der ikke kan anvendes inaktive. En anvendt måde at gøre dette på, er ved at gøre teksten på knapperne grå [Cooper et al., 2007]. Knappen åbn cortexmodel skal derfor kun være aktiv, når en MR-skanning med en cortexmodel tilknyttet, er valgt i skanningslisten. Knappen generer cortexmodel skal kun være aktiv, når der ikke findes en cortexmodel hørende til en valgt MR-skanning. Knappen luk skal altid være aktiv, da det altid skal være muligt at lukke vinduet. I de tilfælde, hvor en knap ikke er aktiv, skal disse markeres som inaktive, ligesom det er illustreret på figur 5.4. Hvis en cortexmodellering igangsættes, skal det grafiske element Åbn/Generer forblive åbent, således at der kan sættes flere cortexmodelleringer igang, eller der kan åbnes eksisterende cortexmodeller. Figur 5.4: Figuren illustrerer, hvorledes knapperne åbn cortexmodel og generer cortexmodel er inaktive Sammenlign Det grafiske element Sammenlign skal gøre det muligt at vise en ekstra cortexmodel, hvis en allerede åben cortexmodel ønskes sammenlignet med en anden. Som før nævnt er funktionaliteten i Sammenlign stort set ens med funktionaliteten i Åbn/Generer og initieres ligeledes fra programmenuen i brugergrænsefladen. Derfor er det valgt at lave et ensartet design i disse elementer og dermed følge et generelt designprincip om konsistent design for ensartede funktionaliteter.

50 36 Design af grafisk brugergrænseflade Eksporter Det grafiske element Eksporter skal gøre det muligt at udtrække måleresultater fra flere cortexmodeller. Elementet skal opbygges, så det ligner elementerne Åbn/Generer og Sammenlign, da alle tre elementer overordnet skal have mange lignende funktionaliteter. Eksporter er illustreret i figur 5.5. Figur 5.5: Figuren illustrerer det grafiske element Eksporter Elementet skal gøre det muligt at udvælge MR-skanninger, som det ønskes at eksportere data fra. Dette skal være muligt via knappen udvælg patient, og efterfølgende skal den udvalgte MR-skanning vises i en liste i nederste venstre hjørne, så det er muligt at se hvilke MR-skanninger, der er valgt. Det skal også være muligt at vælge hvilke kvantitative mål, som ønskes eksporteret. Dette skal håndteres af knappen udvælg måleresultater, som ved aktivering skal frembringe et vindue, hvor alle måleresultater kan vælges eller fravælges ved afkrydsning af check boxes. Vinduet kan ses på figur 5.6. For at effektivisere udvælgelsen af data, skal vinduet indeholde knapper, som gør det muligt at vælge og fravælge alle måleresultater. Vinduet skal yderligere indeholde en knap, som registrerer indtastningen og vender tilbage til Eksporter og en knap der gør det muligt at annullere udvælgelsen. Da dette vindue lukkes igen, når brugeren har valgt hvilke mål, vedkommende ønsker at eksportere, skal disse mål kunne ses i Eksporter. Dette skal vises i en tabel, som skal placeres i nederste højre hjørne af Eksporter. Listen skal automatisk opdateres, hvis udvælgelsen af kvantitative mål ændres. Når brugeren har valgt, hvilke modeller og hvilke kvantitative mål vedkommende ønsker at eksportere, skal det være muligt at gemme disse i en fil. Dette skal være muligt via knappen gem valgte datasæt til fil. I det tilfælde, at der er valgt en MR-skanning uden tilhørende cortexmodel, skal brugeren have mulighed for at generere modellen eller

51 5.3 Design af grafiske elementer 37 eksportere data uden de mål, der hører til ikke genererede cortexmodeller. Dermed kan brugeren mindske ventetiden, hvis der ikke ønskes at vente på, at en eller flere cortexmodeller genereres. Figur 5.6: Listen hvorfra brugeren selv skal udvælge hvilke kvantitative mål, der ønskes eksporteret Dialogbokse De grafiske elementer Dialogbokse skal give fornuftig feedback til brugeren under anvendelsen af prototypen. Dette medvirker til at følge et generelt designprincip om at give brugeren feedback. Dialogbokse kan med fordel bruges til at informere om sjældne hændelser, som ikke er relateret til brugerens øjeblikkelige anvendelse af systemet. Dialogbokse kan desuden anvendes ved hændelser, det er vigtigt at inddrage brugeren i. Brugen af dialogbokse bør dog samtidig minimeres til det absolut nødvendige, da de fjerner brugerens fokus fra den oprindelige opgave [Cooper et al., 2007]. I prototypen skal der anvendes dialogbokse til at give fejlbeskeder, når der opstår hændelser, der kan have konsekvens for brugerens arbejde og arbejdsgang, som ved programfejl, der kan resultere i tab af data. Fejlbeskeder skal designes således, at de er oplysende og behjælpelige. Dette skal ske via velformuleret tekst, som klargør problemet for brugeren, så denne kan få overblik over, hvad der er sket, hvad konsekvenserne af fejlen er, og hvilke valg der er i den pågældende situation. Dette er i overensstemmelse med design, som foreslås af Cooper et al., Det skal via disse dialogbokse være muligt at få uddybende teknisk information om fejlen, hvis det ønskes. Der skal via en dialogboks gives besked til brugeren, når en generering af en cortexmodel er fuldført. Via denne dialogboks skal brugeren også kunne vælge at åbne den genererede cortexmodel. Dermed gøres en relevant funktionalitet let tilgængelig for brugeren, hvilket følger et generelt designprincip om synlighed. Designet af beskeden som

52 38 Design af grafisk brugergrænseflade skal vises, når en ny cortexmodel er genereret, kan ses i figur 5.7. Der skal ligeledes gives besked til brugeren, når eksportdata er genereret eller gemt i en fil. Figur 5.7: Dialogboksen som brugeren skal præsenteres for, når serveren har afsluttet en cortexgenerering. Desuden skal brugeren via en dialogboks have besked, når systemet eller en cortexmodel lukkes, og brugerdefinerede områder ikke er gemt.

53 Design af datahåntering 6 I dette kapitel beskrives først hvilket data der anvendes i systemet, herefter beskrives designet af systemets database, som der er designet ved hjælp af Entity-Relationship (ER) modellering. Først vises et ER-diagram, som giver overblik over hvilke informationer, der skal gemmes på databasen. Dernæst beskrives hvilke tabeller, som skal implementeres på databasen for at strukturere de informationer, som skal gemmes. 6. Data For at kunne dele dataen, som er nødvendig for at understøtte de designede funktionaliteter, imellem flere klienter, har det været nødvendigt at identificere og strukturere det data som skal udveksles imellem serveren og klienten. De grafiske objekter Åbn/Generer, Sammenlign, Exporter og Patientinformation skal alle bruge information om patienterne i systemet. Dette data er patienternes navn og CPR-nummer og hvilke MR-skanninger, der hører til den pågældende patient, samt tidspunktet skanningen er foretaget. Desuden skal Åbn/Generer cortexmodel, Sammenlign cortexmodel og Export have information om, hvorvidt der er foretaget eller igangsat en cortexmodellering for skanningerne. Det grafiske objekt Måleresultater skal præsentere information om overfladeareal, tykkelse, volumen for hele cortex, hver hemisfære, hver hjernelap og alle brugerdefinerede områder. Ud over de egentlige mål for overfladeareal, tykkelse og volumen skal den metriske afvigelse samt hvor mange standardafvigelser dette data afviger fra normaldata med, præsenteres. Desuden skal det angives hvor stor spredning tykkelserne ligger med i de enkelte lapper. Der findes ikke normaldata for brugerdefinerede områder, hvorfor dette ikke skal præsenteres. Navnene for de brugerdefinerede områder skal også præsenteres i Måleresultater. For at præsentere cortexmodellerne som beskrevet i kapitel 5, skal det grafiske objekt Visualisering bruge data med geometrisk information om hver hemisfære, teksturkort for de ensfarvede modeller for hver hemisfære, teksturkort med lappeinddeling for hver hemisfære og et teksturkort som kortlægger tykkelsen af cortex for hver hemisfære. Visualisering skal desuden bruge teksturer til de to teksturkort for lappeinddeling og tykkelse. Desuden skal der kunne præsenteres et verificeringsbillede for hver cortexmodel. For at kunne genindlæse de brugerdefinerede områder, skal de vertices som definerer grænsen imellem området og resten af cortex gemmes. De ovenstående data skal, med undtagelse af normaldata og teksturer, deles imellem systemets klienter, hvorfor de skal gemmes i en fælles database. Teksturerne er altid de samme og ligges derfor på klientcomputerne ved installation. Der afgrænses fra at generere og distribuere normaldata til klienterne, istedet ligges en fil på klientcomputerne, som indeholder et bud på normaldata. Det vælges at ligge filstien til alle større filer i databasen, fremfor at ligge filerne selv ind i databasen. Dette gælder MRskanningerne, verificeringsbillederne, filerne med geometrisk information og alle teksturkort. Næste afsnit beskriver hvordan dataen på databasen er struktureret.

54 40 Design af datahåntering 6.2 ER-diagram navn CPR lappetekstur map sti hjernehalvdel STD fra normaldata forskel fra normaldata Patient tykkelsetekstur map sti Hemisfære 4 volumen inddeles i...* standardtekstur map sti tykkelse lap spredning af tykkelse får foretaget model sti areal areal tykkelse Hjernelap MR-skanning skannings tidspunkt MR sti inddeles i forskel fra normaldata STD fra normaldata volumen 0... model status har tilknyttet Verificeringsbillede billedesti volumen tykkelse 2 navn vertices har tilknyttet Cortexmodel 0...* inddeles i Brugerdefineret område areal STD fra normaldata forskel fra normaldata areal tykkelse volumen Figur 6.: ER-diagram som viser entiteter, relationer imellem entiteter og tilhørende attributter. Understregede attributter er nøgler. Entiteter og relationer som er markeret med en dobbeltstreg indeholder ikke selv deres primærnøgle. Det opstillede ER-diagram viser et overblik over strukturen af det data, som skal gemmes på databasen. Firkanterne i diagrammet er entiteter, som er objekter eller ting, som skal gemmes på databasen. Rhomberne i diagrammet beskriver relationer mellem entiteter. Ovalerne som er tilknyttet en entitet eller relation er attributter, som beskriver en bestemt egenskab eller karakteristika. Attributter som er understreget indikerer, at attributten er en nøgle. Nøgler skal bruges til at identificere en primærnøgle, som er en nøgle eller en samling af nøgler, som unikt identificerer en entitet. Nogle entiteter og relationer er svage, da de ikke indeholder en primærnøgle. Disse er markeret med en dobbeltstreg.

55 6.3 Tabeller på databasen Tabeller på databasen En del af ER-modelleringen er at mappe ER-diagrammet til tabeller, således at det opnås optimal strukturering af data på databasen. Transformationen af ER-diagrammet til tabeller er beskrevet i appendiks F. De resulterende tabeller, som skal implementeres på databasen, er givet i det følgende. Patient CPR BIGINT navn VARCHAR MR-skanning Patient.CPR skanningstidspunkt modelstatus MR sti BIGINT BIGINT SET TEXT Hemisfære Patient.CPR MR-skanning.skanningstidspunkt hjernehalvdel lappeteksturmap sti tykkelseteksturmap sti BIGINT BIGINT SET TEXT TEXT standardteksturmap sti model sti volumen areal TEXT FLOAT FLOAT TEXT Hjernelap Patient.CPR MR-skanning- hjernehalvdel lap areal tykkelse volumen spredning af tykkelse.skanningstidspunkt BIGINT BIGINT SET SET FLOAT FLOAT FLOAT FLOAT Brugerdefineretomrode Patient.CPR MR-skanning.skanningstidspunkt navn vertices areal tykkelse volumen BIGINT BIGINT VARCHAR TEXT FLOAT FLOAT FLOAT Verificeringsbillede Patient.CPR MR-skanning.skanningstidspunkt billedesti BIGINT BIGINT TEXT

56 .

57 Design af komponentarkitektur 7 og dataflow I dette kapitel identificeres designet af systemets komponentarkitektur og dataflow. Med komponentarkitektur menes sammenhængen imellem prototypens klasser og pakker. Med dataflow menes den måde, data distribueres gennem systemet. Disse designes således, at de kan varetage de funktionaliteter, der er beskrevet i kapitel 4 og 5, omhandlende krav og design af brugergrænseflade. Først gives et overblik over systemets pakker udfra et pakkediagram, hvorefter de enkelte pakker samt deres tilhørende klasser beskrives. Der præsenteres yderligere et klassediagram, som viser hvordan klasser skal oprette hinanden. Herefter præsenteres et andet klasse diagram som viser alle associationer mellem pakker og klasser, som ikke vedrøre oprettelse af andre klasser. Til sidst i kapitlet beskrives systemets dataflow. Dette gøres ved at identificere de klasser, som er involveret i dataflowet, samt ved at illustrere sammenspillet mellem disse i et sekvensdiagram. 7. Systemets komponentarkitektur For at give et overblik over hvilke pakker som skal indgå i prototypen, er der opstillet et pakkediagram, som ses på figur 7.. De pakker, hvor navnet står inden i kassen, er pakker som ikke indeholder andre pakker. En beskrivelse af alle pakkerne og deres tilhørende klasser findes i de efterfølgende afsnit. Først beskrives pakken Prototype og efterfølgende Serverpakken og alle pakker og klasser, som hører herunder. Dernæst beskrives pakken ServerInterface og til sidst beskrives pakken Client. Indholdet af klasser og relationer mellem disse kan ses på klassediagrammet på figur 7.2. Det anbefales at kigge på klassediagrammet samtidig med at beskrivelsen af pakkerne læses. Prototype Server CortexExtraction Database ServerInterface Client Net GUI Menu CortexVisualizer Measurements Toolbox Figur 7.: Inddeling af pakker i prototypen.

58 44 Design af komponentarkitektur og dataflow 7.. Pakken Prototype Pakken prototype skal være rammen om hele systemet, og derved indeholde alle andre pakker og klasser Pakken Server Pakken Server skal håndtere den del af systemet, som skal eksekveres på serveren. Dette drejer sig om genereringen af cortexmodeller og teksturkort samt lagring af data fra disse. Desuden varetages kommunikationen til databasen. Pakken indeholder pakkerne CortexExtraction og Database. Serverpakken skal desuden indeholde klassen Network- ConnectionServer. Denne klasse skal være mainklassen i serverapplikationen og stå for netværkskommunikation på serversiden Pakken CortexExtraction Pakken CortexExtraction skal facilitere genereringen af en cortexmodel med tilhørende kvantitative mål og efterfølgende starte genereringen af teksturkort for tykkelse og lappeinddeling. Pakken skal indeholde klassen CortexExtraction, som skal igangsætte en generering ud fra en MR-skanning ved at kalde algoritmen, som foretager genereringen af modellerne. Teksturer for tykkelse og hjernelapper til hver model, skal håndteres af klassen GenerateTexture Pakken Database Pakken Database skal håndtere lagring af data på databasen, samt gøre det muligt at hente data fra databasen. Når der skal hentes eller gemmes oplysninger på databasen, skal dette ske via klassen Database, som skal være ansvarlig for databasekommunikationen Pakken ServerInterface Pakken ServerInterface skal danne interfacet mellem serveren og klienten. Selve kommunikationsinterfacet defineres af interfacet ServerInterface. Pakken skal yderligere indeholde klasserne Export, PatientInformation, VisualData og QuantitativeMeasures, som bruges til at sende grupperet data fra serveren til klienten, når en cortexmodel skal vises, eller kvantitative mål skal eksporteres Pakken Client Pakken Client skal indeholde den del af prototypen, som skal foregå på klienten. Pakken er inddelt i pakkerne Net og GUI. Pakken skal yderligere indeholde klassen Client, som skal indeholde klientens main metode Pakken Net Pakken Net skal håndtere netværkskommunikation på klienten. Pakken indeholder klassen NetworkConnection- Client, som skal sende forespørgsler fra klienten til serveren, når cortexmodeller med tilhørende data eller data til export efterspørges fra klienten og derfor skal hentes. Desuden skal klassen håndtere forespørgsler på nye cortexmodeller med tilhørende kvantitative mål. Pakken skal via klassen OpenCortexEvent distribuere data, når der bliver modtaget en cortexmodel fra serveren. Dette sker ved, at data tilføjes som attributter i eventet, som efterfølgende fyres, hvorved relevante klasser modtager det nødvendige data, når det er til rådighed. Ligeledes findes klassen Scan- ListEvent i pakken, som bruges til at videresende lister over tilgængelige MR-skanninger til de relevante objekter Pakken GUI Pakken GUI skal håndtere den grafiske brugergrænseflade og er designet i henhold til de designovervejelser, som er beskrevet i kapitel 5. Pakken er inddelt i pakker, som håndterer forskellige grafiske funktionaliteter på brugergrænsefladen. Disse pakker er Menu, CortexVisualizer, Measurements og Toolbox. Pakken skal yderligere indeholde klassen

59 7. Systemets komponentarkitektur 45 GUIMain, som skal definere rammen om den grafiske brugergrænseflade og skal håndtere oprettelse og placering af alle grafiske elementer, som skal fremkomme på brugergrænsefladen Pakken Menu Pakken Menu skal håndtere prototypens programmenu, hvorfra det skal være muligt at åbne en ny cortexmodel, generere nye cortexmodeller, sammenligne to modeller, eksportere kvantitative mål, lukke cortexmodeller samt lukke programmet. Administreringen af programmenuen, skal håndteres i klassen ProgramMenu. Samme klasse skal administrere, at de grafiske elementer, som er tilknyttet valg i programmenuen, bliver vist. Ligeledes skal ProgramMenu oprette og fyre events af klassen ServerRequestEvent, der skal fortælle NetworkConnectionClient, som skal lytte på disse events, hvad den skal efterspørge på serveren. Det grafiske element som skal vises, når en ny cortexmodel skal indlæses, skal håndteres i klassen Open. Ligeledes skal det grafiske element, som skal vises, når to modeller skal sammenlignes, håndteres i Compare og når data skal eksporteres, skal det håndteres i klassen Export. Når kvantitative mål skal udvælges til eksport, skal dette håndteres af klassen ChooseMeasurement. De grafiske elementer som er nævnt, skal alle vise et søgefelt og en patientliste. Disse fælles grafiske elementer skal håndteres separat i klasserne SearchPanel og ScanList Pakken CortexVisualizer Pakken CortexVisualizer skal håndtere det grafiske element Visualisering, som har til formål at vise cortexmodeller for brugeren. Pakken skal derfor indeholde klassen CortexVisualizer, som skal præsentere det grafiske element Visualisering og håndtere brugerinteraktion i dette element. Det vil sige, at klassen skal håndtere at indlæse og visualisere en cortexmodel, vise hver hemisfære, skifte tekstur på cortexmodeller samt håndtere zoom, rotation og flytning af cortexmodeller. CortexVisualizer skal yderligere gøre det muligt at optegne brugerdefinerede områder på cortexmodeller. Når en cortexmodel vises på den grafiske brugergrænseflade, skal der kunne vises patientinformationer på skærmen, hvilket skal håndteres af klassen PatientInformation. 7.. Pakken Measurements Pakken Measurements skal håndtere det grafiske element Måleresultater. Til dette formål defineres klassen Measurements, som skal håndtere visningen af de forskellige faneblade, som skal være i Måleresultater. Indholdet under fanebladene volumen, tykkelse, areal og brugerdefinerede område, skal håndteres i hver deres klasse, som skal være Volume, Thickness, Area, og UserDefined Pakken Toolbox Pakken Toolbox skal håndtere det grafiske element Værktøjskasse. Til dette formål defineres klassen Toolbox, som skal håndtere visningen af de forskellige faneblade, som skal være i det grafiske element. Indholdet i fanebladene navigering, visualisering, farvelæg og indtegn område, skal håndteres i hver deres klasse, som skal være Navigate, ModelChooser, Colorizer og DefineArea. Brugerinteraktion i Værktøjskasse skal formidles videre til Cortex- Visualizer ved hjælp af eventklassen CortexUpdateEvent.

60 opretter indeholder 46 Design af komponentarkitektur og dataflow Prototype Server CortexExtraction GenerateTexture CortexExtraction 0.. NetworkConnectionServer opretter opretter opretter Database Database ServerInterface interface indeholder indeholder indeholder «interface» ServerInterface 0..* 0..* 0..* 0..* QuantitativeMeasures VisualData PatientInformation Export 0.. Client opretter Net OpenCortexEvent 0.. opretter og fyrer NetworkConnectionClient opretter Client ScanListEvent 0.. opretter og fyrer CloseCortexEvent opretter og fyrer opretter GUI Menu opretter og fyrer CortexVisualizer ServerRequestEvent opretter og fyrer 0.. opretter opretter 0.. ProgramMenu 0.. opretter GUIMain opretter 0..2 opretter 0.. opretter CortexVisualizer opretter PatientInfo Export Open Compare ChooseMeasurements Measurements MeasurementEvent 0.. UserDefined opretter opretter opretter SearchPanel Thickness opretter opretter og fyrer opretter opretter opretter ScanList Area opretter Measurements Volume opretter opretter Toolbox ModelChooser opretter opretter opretter 0.. Colorizer 0.. Toolbox opretter opretter 0.. opretter Navigate opretter CortexUpdateEvent opretter og fyrer opretter ToolboxEvent DefineArea opretter Figur 7.2: Klassediagram der viser relationer mellem systemets klasser. De klasser der er illustreret med blåt er involveret i systemets dataflow.

61 7.2 Ikke oprettende associationer Ikke oprettende associationer Det foregående afsnit beskrev sammenspillet mellem klasserne i forhold til hvilke klasser, som opretter hinanden. Der er dog flere vigtige associationer mellem klasserne, som ikke er vist i diagrammet. Disse associationer omhandler oprettelse og nedlæggelse af lyttere, samt informationer som objekter skal anvende fra andre objekter. Dette beskrives i det følgende afsnit. Associationerne som beskrives er illustreret på figur 7.3 Prototype Server ServerInterface Client Net OpenCortexEvent CloseCortexEvent Client ScanListEvent NetworkConnectionClient GUI Menu Export tilføjes som lytter på event fra ServerRequestEvent Measurements MeasurementEvent tilføjes som lytter på event fra kalder eventfyring på Open tilføjes som lytter på event fra SearchPanel tilføjes som lytter på event fra kalder eventfyring på tilføjes som lytter på event fra tilføjes som lytter på event fra Compare kalder eventfyring på opdaterer ProgramMenu nedlægges af ChooseMeasurements ScanList Measurements tilføjes som lytter på events fra kalder eventfyring på tilføjes som lytter på event fra GUIMain Toolbox tilføjes som lytter på event fra tilføjes som lytter på event fra ModelChooser kalder eventfyring på anvender Colorizer CortexVisualizer CortexVisualizer Toolbox tilføjes som lytter på event fra Navigate PatientInfo ToolboxEvent DefineArea anvender anvender anvender UserDefined Thickness Area Volume CortexUpdateEvent Figur 7.3: Her illustreres alle ikke oprettende associationer.

62 48 Design af komponentarkitektur og dataflow 7.2. Associationer relateret til events og lyttere Klassen NetworkConnectionClient skal fyre alle OpenCortexEvents og ScanListEvents, ligesom den også skal indeholde lister over hvem der skal lytte på disse events. Derfor skal alle klasser som skal lytte på disse events have en reference til NetworkConnectionClient. På figur 7.3 kan det ses hvilke klasser det drejer sig om. ProgramMenu skal have en reference til NetworkConnectionClient, fordi den skal give referencen videre til instanser af Open,Compare og Export så de kan tilføjes og fjernes som lyttere på ScanlistEvents. NetworkConnectionClient skal også kende ProgramMenu. Dette skyldes at ProgramMenu skal fyre ServerRequestEvents og administrere den tilhørende lytterliste. NetworkConnectionClient skal tilføjes denne liste, da den via disse events får information om, hvilket data der skal efterspørges på serveren. GUIMain skal fyre alle CloseCortexEvents og indeholde en liste over lyttere til denne type event. Derfor skal Measurements have en reference til GUIMain. Alle instanser af CortexVisualizer skal kende Toolbox, da Toolbox skal indeholde listen over lyttere på CortexUpdateEvents. Events fyres dog af instanser af klasserne ModelChooser, Colorizer, Navigate og DefineArea, hvilket kræver at de har en reference til lytterlisten. Toolbox og Measurements skal kende hinanden. Dette skyldes, at Toolbox skal fyre ToolboxEvents og administrerer den tilhørende lytterliste, som Measurements skal tilføjes på. Measurements fyrer MeasurementEvents og administrerer den tilhørende lytterliste, som Toolbox skal tilføjes på. Disse events skal understøtte funktionaliteten at fanebladene, der har indhold relateret til de brugerdefinderede områder, vises samtidig Anvendelse af information og funktionalitet fra andre objekter ProgramMenu og CortexVisualizer skal kende GUIMain, da de skal registrere når en bruger ønsker at lukke en cortexmodel. Instanser af disse klasser skal have mulighed for at få GUIMain til at nedlægge instanser af CortexVisualizer. Associationen fra ProgramMenu til GUIMain har yderligere den funktion, at ProgramMenu skal have mulighed for at administrere programrammens indhold, fordi den skal bruge denne plads, hver gang der oprettes instanser af Open, Compare, Export og ChooseMeasurements. Desuden skal ProgramMenu have viden om, hvor mange cortexmodeller, der er åbne, således at der ikke oprettes instanser af Open og Compare, når dette ikke skal være muligt. ProgramMenu skal have denne information via associationen til GUIMain, der løbende holder styr på dette, ved registrering af OpenCortexEvents og CloseCortexEvents. Toolbox skal have en reference til GUIMain, da GUIMain skal være ansvarlig for at skjule menuer og patientinformationen, når brugeren vælger at gøre det fra Toolbox. Open, Compare, Export og ChooseMeasurements skal alle være i stand til at få ProgramMenu til at nedlægge dem. Ligeledes skal Open, Compare og Export kunne få ProgramMenu til at fyre et ServerRequestEvent, således at brugerens valg sendes videre til NetworkConnectionClient og derfra videre til serveren. SearchPanel skal have en reference til ScanList. Når der er indtastet en søgning i søgefeltet som håndteres af Search- Panel, skal dette resultere i at ScanList, som skal vise søgeresultatet, opdateres. Dette skal gøres ved at SearchPanel kalder en metode på ScanList til dette formål. Thickness, Area og Volume skal have en association til Measurements for at kunne anvende en fælles metode i denne klasse, som skal gøre det muligt at indlæse normaldata fra en fil på klientens harddisk.

63 7.3 Systemets dataflow Systemets dataflow I dette afsnit beskrives, hvordan dataflowet er designet i systemet. Dette gøres ved først at give en overordnet beskrivelse af dataflowet. Herefter gives et mere detaljeret indblik i hvilke klasser, som skal indgå i dataflowet, hvilket illustreres i et sekvensdiagram Konceptet bag dataflow Det data, som skal bruges til at visualisere en cortexmodel, ligger gemt på en database på serveren. Dette betyder, at der skal udveksles data mellem serveren og klienten, hver gang der skal vises en cortexmodel på brugergrænsefladen. Data som skal bruges til præsentation af en cortexmodel er patient- og skanningsinformation, cortexmodellen med tilhørende teksturkort og verificeringsbilleder samt kvantitative mål. Når systemet skal udveksle data mellem klienten og serveren, skal det ske ved at klienten sender en forespørgsel til serveren. Herefter skal det relevante data overføres til det sted på klienten, hvor det skal anvendes. I det følgende gives et eksempel på, hvordan data skal distribueres i systemet, når en bruger ønsker at få genereret og præsenteret en ny cortexmodel. Dette er illustreret på figur 7.4. Klient 6 2 Server QuantitativeMeasures Cortexmodel genereres VisualData PatientInformation 5 3 Cortexmodel Kvantitative mål 4 Database Figur 7.4: Dataflow i systemet. : En bruger ønsker at få genereret og visualiseret en cortexmodel. 2: Brugeren igangsætter en generering igennem Åbn/genererer menuen fra menulinien. 3: En cortexmodel med tilhørende kvantitative mål genereres på serveren. 4: Det genererede data gemmes på databasen. 5: Data, som skal bruges til visualisering, kan hentes på serveren i klasserne QuantitativeMeasures, VisualData og Patient- Information. 6: En cortexmodel og tilhørende kvantitative mål visualiseres for brugeren. Når brugeren vælger at generere en ny model, skal der sendes besked til serveren om, at der skal igangsættes en generering ud fra en bestemt MR-skanning. Når serveren har genereret en ny cortexmodel med tilhørende kvantitative mål, teksturkort og verificeringsbilleder, skal disse informationer gemmes på databasen. Når alle informationer om en

64 50 Design af komponentarkitektur og dataflow cortexmodel er gemt, skal disse altid kunne tilgås af klienten, når der er forbindelse til serveren. Når cortexmodellen skal visualiseres, skal det nødvendige data hentes i klasser designet til dette. I det tilfælde hvor en cortexmodel, skal vises, er det klasserne VisualData, QuantitativeMeasures og PatientInformation der benyttes. Når klasserne med det nødvendige data er tilgængelige på klienten, er det muligt at vise cortexmodellen med tilhørende kvantitative mål, skanningsinformation og verificeringsbilleder Klasser involveret i dataflow Overførslen af data skal håndteres af en række klasser, der ligger på både klienten og serveren. Følgende beskrives hvilke klasser, der primært skal være involveret i dataflowet, og hvordan disse bidrager til dataoverførslen. Klasserne, der er involveret i dataflowet, er markeret med blåt på klassediagrammet på figur 7.2. Sammenspillet mellem de involverede klasser kan ses på sekvensdiagrammet på figur 7.5. Klienten skal anvende data fra databasen i klasserne ProgramMenu, CortexVisualizer og Measurements. Program- Menu skal anvende data til listen over tilgængelige MR-skanninger og tilhørende informationer, således at disse informationer kan visualiseres. CortexVisualizer skal anvende data til at visualisere cortexmodeller. Measurements skal anvende data i form af kvantitative mål hørende til den eller de visualiserede cortexmodeller. Når der fra klienten skal sendes forespørgsler til serveren, skal det ske igennem klassen Programmenu, som skal oprette og fyre events af klassen ServerRequestEvent. Klassen NetworkConnectionClient skal lytte på disse events og reagerer herpå ved at sende en forespørgsel om det ønskede data til serveren. På serveren skal klassen CortexExtraction generere en cortexmodel og data hørende hertil, og klassen Database skal gemme data i databasen. Når data skal overføres fra serveren til klienten, skal det pakkes ned på serveren af klassen NetworkConnection- Server og udpakkes på klienten af klassen NetworkConnectionClient. Disse klasser skal dermed skabe interfacet mellem klienten og serveren ved at definere den protokol, data skal overføres med. På serveren oprettes objekter af dataklasserne Export, PatientInformation, QuantitativeMeasures og VisualData, som på figur 7.5 er illustreret som én klasse, DataClass. Disse klasser skal stilles til rådighed af pakken ServerInterface, så både klient og server kender disse klasser. Når data af de førnævnte dataklasser modtages af klienten, skal klassen NetworkConnectionClient sørge for, at der fyres events, således at klasser på klienten kan registrere, når denne data er tilgængelig. Disse events skal håndteres af klasserne ScanListEvent og OpenCortexEvent, som på figur 7.5 er illustreret som den samme klasse, DataEvent. Klasserne ProgramMenu, CortexVisualizer og Measurements skal lytte på disse events og tilgå det relevante data, når det er tilgængeligt. ProgramMenu, CortexVisualizer og Measurements er samlet til klassen ListenerClass på sekvensdiagrammet.

65 7.3 Systemets dataflow 5 Dataflow Programmenu NetworkConnectionClient NetworkConnectionServer CortexExtraction Database ListenerClass ServerRequestEvent() ServerRequestEvent serverrequesteventrecived() geteventattribute() serverrequest() generatedata() savedata() getdata() DataClass() DataClass DataEvent() DataEvent dataeventrecieved geteventattribute() getdataattribute() Figur 7.5: Sekvensdiagram over hvordan data skal distribueres mellem systemets klasser. Diagrammet beskriver konceptet i dataflowet og er derfor simplificeret, således at den konceptuelle klasse Dataclass illustrerer, hvordan klasserne Export, PatientInformation, QuantitativeMeasures og VisualData skal indgå i dataflowet. Ligeledes illustrerer den konceptuelle klasse ListnerClass, hvordan klasserne ProgramMenu, CortexVisulizer og Measurements skal indgå i dataflowet.

66 .

67 Implementering 8 Dette kapitel beskriver, hvordan prototypen er implementeret. I dette kapitel gives først et overblik over implementeringen af prototypen i forhold til kommunikation mellem klient, server og database. Der gives ligeledes et overblik over implementeringen af de mest væsentlige områder, hvor der i implementeringen er sket ændringer i forhold til kravene og designet af systemet. Sidst i kapitlet beskrives hvilket software og hardware, der anbefales for at anvende den udviklede prototype. 8. Programmeringssprog og implementerede klasser Det er valgt at udvikle prototypen som et Javaprogram, og udviklingen er sket i Java IDE NetBeans version 6.0. Der gives et overblik over de implementerede klasser med metoder i appendiks H og kildekode og dokumentation i form af javadocs kan findes på den vedlagte CD. 8.2 Database Databasen som er installeret på den anvendte server er en MySQL database, hvorfor alt kommunikation til databasen foregår ved hjælp af sproget Structured Query Language (SQL). Da kommunikationen til databasen forgår ved hjælp af SQL og prototypen er udviklet i Java, anvendes Java DataBase Connectivity (JDBC). JDBC er en Java API, der muliggør indlejrede SQL-kommandoer i Java-kode. Derved kan Javaprogrammet benytte den SQL-kompliante database, som ligger på serveren. Serveren der er anvendt i dette projekt, er en lokal server, som er tilgængelig via Aalborg Universitet. Databasen tilgås gennem et database-management system (DBMS), som håndterer fysisk lagring af data. Det er således DBMS, der står for at tilføje nye tabeller, samt tilføje, ændre og slette data i databasen. 8.3 Klient/server forbindelse Prototypen er implementeret således, at koden til serveren og koden for klienten er programmeret som separate applikationer. For at kommunikere imellem de to applikationer, er der programmeret et interface, som indeholder serverens og klientens fællesklasser samt selve interfacet til netværkskommunikationen. Netværkskommunikationen mellem klienten og serveren er designet til at blive håndteret i klasserne Network- ConnectionClient, NetworkConnectionServer og ServerInterface. I implementeringen er netværkskommunikationen håndteret ved hjælp af en Remote Method Invocation (RMI) forbindelse. RMI gør det muligt virtuelt at arbejde direkte med objekter, som eksisterer på en anden Java Virtuel Maskine, som havde de været lokale objekter. Dette gør det nemt at håndtere data, som ikke er gemt lokalt. Da netværkskommunikationen er blevet implementeret som en RMI forbindelse, er klasserne NetworkConnectionClient og NetworkConnectionServer blevet omdøbt til RMI- Client og RMIServer. På den anvendte server, som har GiB RAM, tager det over en time at generere en cortexmodel. Da det tager forholdsvis lang tid at generere en cortexmodel, har det været nødvendigt at køre de processer, hvor der kan genereres cortexmodeller i tråde, for at kunne generere mere end én cortexmodel af gangen. De processer det handler om er, når en cortexmodel genereres, og når der hentes eksportdata fra serveren. For at håndtere generering af flere cortexmodeller af gangen fra den samme klient, er der implementeret to ekstra klasser, RunExport og RunExtract, til at foretage disse processer trådet. Begge klasser implementerer interfacet Runnable. Implementeringen har ikke omfattet muligheden for at anvende prototypen fra mere end en klient.

68 54 Implementering 8.4 Visualisering af cortexmodeller Selve visualiseringen af cortexmodeller i Java er implementeret ved hjælp af Java3D pakken, der er anvendt til at generere scenegrafer, der indeholder alle 3D-objekter, som er nødvendige for at få visualiseret en eller to cortexmodeller på den grafiske brugergrænseflade. En uddybning af implementeringen af scenegrafer findes i appendiks G. For at kunne flytte, rotere og zoome på en cortexmodel ved hjælp af en mus, er der implementeret en standardklasse, som kan håndtere dette. Desuden er denne navigation designet til at kunne foretages ved at anvende tastatur og knapper på brugergrænsefladen. De ovennævnte former for navigation med cortexmodeller er sat op ved, at ligge objektet fast og flytte kameraet, som håndtere den vinkel, brugeren ser objektet fra. Under implementering har der været problemer med manipulation af kameraet, hvilket forårsager, at rotation, translation og zoom kun fungerer over x- og y-akserne alene. Dette skyldes, at det umiddelbart har været svært at finde de korrekte rotationsmatricer. Translation og zoom med musen virker dog, som det er designet. Kravet om at cortexmodeller skal kunne inddeles i hjernelapper er opfyldt under implementeringen. Dette er implementeret således, at både lappeinddelingen og tykkelsen vises på hjernen. Dette er gjort for at få dybde i visualiseringen af cortexmodellen, når den inddeles i lapper. Teksturkortet til lappeinddeling indeholder derfor både information om lappeinddelingen og tykkelse. Teksturkortet for lappeinddeling kan ses på figur 8.. Den blå farve angiver området for frontallappen, den gule farve angiver paritallappen, den røde farve angiver occipitallappen og den grønne farve angiver området for temporallappen. Dette teksturkort, bevirker at overgangen mellem alle hjernelapperne blive markeret med en hvid streg, hvilket giver en klar adskillelse af hjernelapperne. På figuren er det illustreret et eksempel på, hvordan et face antager farverne fra teksturkortet. Her er der tale om et face, der ligger hen over grænsen mellem occipitallappen og temporallappen. På figuren ses desuden, hvordan farverne for lapperne ændres i forhold til tykkelsen af cortexmodellen i de enkelte vertices. Occipitallap Frontallap Temporallap Parietallap 0mm 0mm 0mm Figur 8.: Teksturkort for lappeinddeling. Når en cortexmodel skal inddeles i hjernelapper kunne dybden af modellen også vises ved at beholde de samme materiale egenskaber, som der anvendes, når en cortexmodel ikke er farvelagt. Disse ser ud til at give en bedre dybde i visualiseringen af en cortexmodel. Under implementeringen har det været nødvendigt at tilføje en ekstra klasse til prototypen, for at kunne håndtere det data, der anvendes til visualisering af cortexmodeller. Dette skyldes, at algoritmen til generering af cortexmodeller danner en OBJ fil efter MNI-syntaksen, som indeholder geometrisk information om cortexmodeller. Dette filformat er ikke kompatibel med loadere i Java3D. Det er derfor valgt at tilføje klassen OBJconverter, der konverterer OBJ filerne til OBJ filer, som følger WAVEFRONT syntaksen. Denne syntaks er kompatibel med loaderen ObjectLoader i Java. 8.5 Visning af elementer på canvas Visningen af patientinformation er designet til altid at blive vist øverst i venstre hjørne i Visualisering. Under implementering af dette, viste det sig, at der var problemer med at placere swing-komponenter ovenpå et Canvas3D objekt, som der anvendes i Visualisering. Dette skyldes, at swing-komponenter er lightweight komponenter, hvilket betyder, at de låner plads på et andet element, og at et canvas er et heavyweight komponent, som ikke kan låne sin plads til andre komponenter. Problemet er blevet forsøgt løst ved at placere patientinformation som et grafisk element i 3D miljøet i canvaset, men her er der opstået problemer i forhold til placeringen af elementet, som flyttede sig hver

69 8.6 Måleresultater 55 gang, der blev zoomet med en cortexmodel på canvaset. Derfor er den endelige implementering af patientinformation, håndteret ved at lave et nyt punkt i menulinien, som kan vise patientinformationer. Denne løsning er lavet, da det er vigtigt at brugeren altid kan få oplysninger, om hvilken patient de viste modeller hører til. 8.6 Måleresultater Den gennemsnitlige cortextykkelse for alle otte forskellige hjernelapper er et direkte output fra algoritmen, se eventuelt appendiks C. I prototypen skal der anvendes en total gennemsnitlig tykkelse for hver af de fire hjernelapper, det vil fx for frontallappen sige gennemsnittet af den højre og den venstre frontallap. Det totale gennemsnit for fx frontallapperne er estimeret ved at addere gennemsnittet for højre og venstre frontallap og dividere resultatet med 2. Dette giver dog ikke et korrekt udtryk for den totale gennemsnitlige tykkelse af frontallapperne, da der ikke nødvendigvis er lige mange vertices i hver frontallap. Ved den anvendte estimering vægtes den højre og den venstre hjernelap ens, men der burde vægtes efter antallet af vertices. Det samme problem opstår, når den gennemsnitlige tykkelse for hver hemisfærer og hele hjernen udregnes. Mål for ovefladeareal og volumen for de enkelte hjernelapper, er ikke implementeret i i prototypen, da disse ikke er et direkte output fra algoritmen. 8.7 Afvigelser fra brugergrænsefladedesign Der er anvendt dialogbokse i et større omfang i implementeringen af brugergrænsefladen, end det der var designet. Dette er tilfældet, når der interageres med det grafiske element Programmenu. Her er der implementeret dialogbokse til at give brugeren feedback, hvis der klikkes på funktioner, som ikke er tilladte i den givne situation, istedet for at maskere disse funktioner. Optimalt set bør funktioner, der ikke kan tilgås, vises som inaktive ved at gøre dem grå, som omtalt i afsnit under brugergrænsefladedesign. Desuden er der implementeret flere dialogbokse til at give brugeren feedback ved interaktion med det grafiske element Eksportering. Dette har været nødvendigt for at give brugere fornuftig feedback. Der bør overvejes andre måder at give brugeren feedback, da dialogbokse kan virke forstyrrende for brugen af brugergrænsefladen. Der kunne fx designes og implementeres et mindre område i brugergrænsefladen, dedikeret til feedback og status for forskellige handlinger. Funktionaliteten bag use casen Optegn område er ikke blevet implementeret i prototypen. Brugergrænsefladen til denne use casen er delvist implementeret, således at placeringen og opbygningen af denne funktion kan ses i forhold til den øvrige brugergrænseflade, dog uden at have nogen funktionalitet tilknyttet. 8.8 Software og hardware Prototypen kan køres med Java 2 Platform, Standard Edition, version.6 installeret på serveren og klienten. For at programmet kan køre optimalt på klientsiden, anbefales det, at den anvendte PC har minimum GiB RAM og et grafikkort med minimum 28 MiB dedikeret hukommelse. Dette begrundes udfra, at det er nødvendigt at kunne allokere op til 500 MiB RAM for at kunne køre prototypen. Der er ingen specielle krav til valg af styresystemet på klientsiden. Algoritmen til generering af cortexmodeller kan køres på en server med et Linux styresystem, som i prototypen. Programmet gzip skal desuden være installeret på serveren. På grund af algoritmen til segmentering af cortex cerebri, anbefales det, at den anvendte server har minimum GiB

70 56 Implementering RAM. Desuden skal serveren bruge MiB harddiskplads per cortexmodellering. Dette kan dog reduceres til MiB harddiskplads per cortexmodellering, da prototypen ikke anvender alt det data, som algoritmen producerer, hvorfor dette kan slettes efter segmenteringen. Grunden til dette data ikke slettes i prototypen, er at det kan være en fordel at have alt data tilgængeligt, så længe systemet er i en udviklingsfase, idet der kan opstå behov for anvendelse af mere data fra algoritmen end det, der anvendes på nuværende tidspunkt. De MiB data, som anvendes i prototypen, udgøres hovedsageligt af det geometriske data, som anvendes til visualisering af cortexmodeller. Det betyder, at hver gang en bruger skal have visualiseret en cortexmodel, skal der downloades MiB data. For at systemet kan køre optimalt, skal hastigheden af forbindelsen brugeren er tilkoblet serveren tages i betragtning. Det anbefales derfor at anvende minimum en 50 eller 00 Mbit/s forbindelse, hvilket vil give en download tid på 9-3 sekunder. Idet der kan være ventetid, imens systemet downloader data, bør der tilføjes en progressbar, som viser hvordan en downloadopgave skrider frem.

71 Præsentation af prototypen 9 I dette kapitel præsenteres det endelige design af prototypen. Først gives et kort overblik over indholdet på brugergrænsefladen, når en model er åben. Herefter vises forskellige eksempler på hvordan brugergrænsefladen ser ud, når forskellige funktionaliteter skal udføres i prototypen. Præsentationen er lavet ud fra en række skærmbilleder fra prototypen. 9. Overblik over brugergrænsefladen På figur 9. ses prototypens brugergrænseflade, som den ser ud, når en cortexmodel er åben. I felt a ses en menubar, hvorfra programmenuen er tilgængelig. Ligeledes findes der i menubaren drop down menuen model, hvor patientinformationer hørende til den viste cortexmodel kan findes. I felt b ses visualiseringsfeltet, hvor en eller to cortexmodeller kan vises. I højre side af brugergrænsefladen ses vinduet, hvor kvantitative mål præsenteres (felt c på figur 9.). Under vinduet med kvantitative mål, i felt d, ses vinduet med faneblade, som indeholder værktøjer til at manipulere med de indlæste cortexmodeller. I felt e ses knapper til at skjule fanebladene i højre side, og maksimere visualiseringsfeltet. a c b d e Figur 9.: Overblik over brugergrænsefladen.

72 58 Præsentation af prototypen 9.2 Åbning / sammenligning af cortexmodeller På figur 9.2 ses vinduet, som vises når der skal åbnes eller genereres cortexmodeller til sammenligning. Et lignende vindue anvendes til at igangsætte en generering af en cortexmodel eller åbne en eksisterende cortexmodel. På figuren er det illustreret, at en patient er valgt på listen, og MR-skanninger hørende til patienten er vist under den valgte patient. Der er klikket på patientens eneste MR-skanning i vinduet, hvorfor knappen sammenlign cortexmodel kan vælges, som det ses på figuren. Da MR-skanningen allerede har tilknyttet en cortexmodel, er det som det ses ikke muligt at trykke på knappen generer cortexmodel Figur 9.2: Vinduet hvorfra det vælges at sammenligne cortexmodeller. 9.3 Eksportering af kvantitative mål Øverst på figur 9.3 ses vinduet, der anvendes til at eksportere kvantitative mål fra flere cortexmodeller. I dette vindue er det illustreret, hvordan der er udvalgt datasæt, som der skal eksporteres kvantitative mål for. De udvalgte datasæt ses i nederste venstre hjørne af vinduet, med angivelse af CPR-nummer og skanninsdato. Hvis der i dette vindue trykkes på knappen udvælg måleresultater, som er markeret med rødt på figuren, fremkommer vinduet, som ses nederst på figur 9.3. I dette vindue er det valgt, at eksportere alle kvantitative mål. De valgte mål vises i nederste højre hjørne i vinduet til eksportering, som det ses øverst i figur 9.3.

73 9.3 Eksportering af kvantitative mål 59 Figur 9.3: Øverst ses vinduet, der anvendes til eksportering af data, og nederst ses vinduet, hvor det udvælges hvilke kvantitative mål, der skal eksporteres.

74 60 Præsentation af prototypen 9.4 Visning af kvantitative mål På figur 9.4 ses tre forskellige faneblade, som findes i vinduet, hvor de kvantitative mål præsenteres. De viste faneblade præsenterer mål for henholdsvis volumen, tykkelse og areal og hører i dette tilfælde til en sammenligning af to cortexmodeller. Desuden findes fanebladet brugerdefinerede områder i dette vindue, men indholdet under dette er ikke implementeret i prototypen, hvorfor dette ikke vises. Som det også ses i figuren understøtter prototypen ikke estimering af mål for volumen og areal, for de enkelte hjernelapper. Vinduet er implementeret således disse mål kan implementeres, hvis de gøres tilgængelige. På figuren ses desuden, hvordan hver hjernelap er markeret med en farve, som tilsvarer de farver hjernelapperne har på cortexmodellerne. Figur 9.4: Faneblade i vinduet hvor de kvantitative mål præsenteres: Fra venstre mod højre ses: volumen, tykkelse og areal. 9.5 Værktøjer til manipulering af cortexmodel På figur 9.5 ses tre forskellige faneblade, som findes i vinduet, hvor funktionaliteter til manipulering af cortexmodeller præsenteres. På fanebladet navigering ses, hvordan ikonerne til navigering med cortexmodeller er implementeret. De viste faneblade hører til sammenligning af to cortexmodeller, og det ses på fanebladet navigering, at der er valgt navigering for begge cortexmodeller. På fanebladet visualisering er det valgt, at cortexmodellerne skal vise hele cortex cerebri. På fanebladet farvelæg er det valgt, at cortexmodellerne skal vises uden farve. Indholdet under fanebladet indtegn område er ikke implementeret i prototypen.

75 9.6 Visualisering af cortexmodeller Figur 9.5: Implementerede faneblade til manipulation af cortexmodellerne: Fra venstre mod højre ses: navigering, visualisering og farvelæg. 9.6 Visualisering af cortexmodeller På figur 9.6 ses til venstre en visning af en hemisfære fra den venstre laterale visningsvinkel. Til højre ses skærmbilledet der fremkommer, efter den markerede knap skjul menuer er valgt. Det ses hvordan cortexmodellen kan betragtes mere detaljeret på den givne skærm, når menuerne skjules. Figur 9.6: Brugergrænsefladen med og uden vinduerne i højre side af skærmen: De røde rammer markerer de knapper, som er brugt til at skifte imellem de to modes. På figur 9.7 ses implementeringen af tre ud af de seks prædefinerede visningsvinkler af en cortexmodel. Her ses visningerne anterior (øverst), venstre lateral (i midten) og superior (nederst). På hvert skærmbillede er den knap, der er anvendt for at skifte til visningen, markeret. På disse figurer er det desuden valgt, at farvelægge cortexmodellen efter tykkelse. 6

76 62 Præsentation af prototypen Figur 9.7: På disse skærmbilleder ses tre af de seks forskellige prædefinerede visningsvinkler for cortexmodellerne.

77 9.6 Visualisering af cortexmodeller På figur 9.8 ses en visualisering af hele cortex cerebri og på figur 9.9 ses, en visning af de enkelte hemisfærer for cortex cerebri. Figur 9.8: Visualisering af en cortexmodel hvor begge hemisfærer er vist. Figur 9.9: Visualisering af en cortexmodel hvor det er valgt at vise henholdsvis højre og venstre hemisfære. På figur 9.0 ses de forskellige farvelægninger, som prototypen understøtter, henholdsvis farvelægning efter tykkelse og farvelægning efter lappeinddelinger. På det øverste skærmbillede ses hvordan farveskalaen til angivelse af tykkelse 63

78 64 Præsentation af prototypen er implementeret. På det nederste skærmbillede ses inddelingen i hjernelapper ved hjælp af farver. Det kan ses hvordan lapperne er separeret med en hvid streg. Figur 9.0: De to forskellige farvelægninger af cortexmodeller som er implementeret i prototypen. Øverst ses farvelægning efter tykkelse, og nederst ses farvelægning efter lappeinddeling.

79 9.6 Visualisering af cortexmodeller På figur 9. ses hvordan verificeringsbilleder af segmenteringskonturen præsenteres for brugeren. Som det ses på skærmbilledet, er den ydre segmenteringskontur optegnet med en grøn streg, og den indre segmenteringskontur er optegnet med en blå streg. Figur 9.: Et verificeringsbillede hørende til en cortexmodel. 65