Feature: Filter
Dit is het scherm waar de gebruiker zijn/haar geüploade MRI-scan kan vergelijken met de dataset. Door filters in te vullen, die het belangrijkst zijn voor de patiënt en relavant kunnen zijn voor het opstellen van een behandelplan, zal er een steeds specifiekere patiëntengroep overblijven met een vergelijkbaar ziektebeeld. Op deze manier kan er nauwkeuriger gekeken worden naar de behandelbaarheid van de tumor en de complexiteit.
Het ontwerpen van de filter was de omvangrijkste, en ook lastigste opgave tijdens mijn afstudeerproject en dat kwam door de volgende punten:
- 1.Er zijn 40 klinische variabelen: tijdens mijn dataonderzoek kwam ik tot de conclusie dat er maar liefst 40 klinische variabelen waren die in 1 scherm getoond moesten worden
- 2.Er zijn 4 subcategorieën: binnen deze variabelen heb ik vier categorieën geconstateerd; general (zoals age, gender), surgery, radiotheraphy en chemotherapy.
- 3.Er zijn 5 soorten visualisaties: deze variabelen kunnen ook weer opgedeeld worden 5 soorten data visualisaties.
Om de data te kunnen structureren heb ik een dataonderzoek gedaan. Op voorhad had ik een grote set met MRI-data gekregen van PICTURE en ben ik als eerste gaan kijken welke data filterbaar was en welke data niet. Vervolgens heb ik het opgedeeld in categorieën, en heb ik de filter categorie opgedeeld in subcategorieën. De eerste validatie heb ik gedaan door mijn eerste versie naar het VUmc te sturen en feedback te vragen, ook heb ik tijdens coachingsessies overlegd hoe ik de data het beste kon structureren. Ik heb er lang over na moeten denken hoe ik het beste deze filters in een scherm kon krijgen, er zijn veel iteraties overheen gegaan maar door constant te testen, te valideren en te itereren met de opdrachtgever heb ik een zo goed mogelijke filter gecreeërd.
Exclusion criteria zijn niet nodig in de dataset.
Dit gaat om variabelen die aangeven of een MRI-scan bruikbaar is of niet en waar dit aan moet voldoen. Alle scans die geüpload zijn in de tool zijn al bruikbaar.
De prefilter kan eruit. Deze data kan automatisch uitgelezen a.h.v de data die je meegeeft met het uploaden van de scan.
In mijn eerste 4 iteraties heb ik een prefilter opgenomen in de Brain Map Manager. Op basis van mijn data onderzoek had ik de data opgedeeld in 4 fases: input, parse, compare, output. Input gaat over de ge-prefilterde data. De gebruiker dient aan te geven in de prefilter welk scan type, sessie type en links- of rechtszijdigheid van hun scan is.
Echter kreeg ik in een van de laatste co-creatie sessie met de projectleider te horen dat tijdens het uploaden deze data al wordt meegegeven. Dit kan er dus voor zorgen dat de tool automatisch de juiste scan type en sessie type uitleest.
Ook zegt de links en rechts zijdigheid van de tumor niet genoeg. Hoe de tumor locatie bepaald moet worden is nog een vraag die bij PICTURE ligt, maar dit zou iets kunnen zijn o.b.v een anatomische locatie.
De uiteindelijk conclusie was dat deze locatie bepaling zou kunnen vallen onder de detailed filter. Dit zorgt ervoor dat de prefilter overbodig wordt.
Er moet een mogelijkheid zijn om te kunnen switchen tussen scan types.
Met het verwijderen van de prefilter vervalt ook de functie om een scan type te kunnen selecteren. Echter moet deze functionaliteit wel ergens terug komen in de Brain Map Viewer. De gebruiker wil kunnen switchen tussen scan types aangezien dit de view (achtergrond) van de MRI-scan aanpast. Dit zou dus logischer zijn in het midden, bij de daadwerkelijke scan en niet in het linker filter panel. Omdat ik steeds meer functionaliteiten erbij kreeg die gingen over de MRI-scan heb ik ervoor gekozen om bovenin nog een toolbar toe te toegen met functionaliteiten die te maken hebben met de MRI-scan of het bestand.
Afb 1. Voorbeeld scans
Locatie filter panel
Ik heb ervoor gekozen om het filter panel aan de linkerkant te zetten. Ik heb hiervoor gekozen omdat de gebruiker in de meeste gevallen begint met het invullen van de filters. Ik heb er ook voor gekozen om het filter panel standaard open te zetten omdat ik niet wil dat belangrijke informatie over het hoofd gezien kan worden. Ook wilde ik ervoor zorgen dat het panel van de filter én de visualisatie tegelijk open kunnen zodat de gebruiker real time in de visualisaties kan zien wat het effect is van de ingevulde filter.
Aanmaken van filter presets
In de co-creatie sessie heeft Roelant aangegeven dat het wenselijk is als filters opgeslagen kunnen worden. Het kost even tijd om de juiste filters in te stellen en is het onhandig als deze, bij het heropenen van de tool, opnieuw ingesteld moeten worden. Deze functionaliteit heb ik in de toolbar geplaatst. De filter preset maakt als het ware een snapshot van alle gemanipuleerde data; filter, scan type en coördinaten van de filter. Omdat dit dus een functionaliteit is die niet alleen over de filter criteria, maar ook over de MRI-scan gaat heb ik deze in de toolbar geplaatst.
Afb 2. Preset Manager
Actieve filters
Naar aanleiding van de feedback van de coachingsessie ben ik gaan kijken hoe ik kon tonen aan de gebruiker dat een filter bewerkt is. Dit heb ik opgelost door middel van een witte tekst. De niet gebruikte filters zijn grijs. Ook had ik actieve filters eerst gemarkeerd met een blauwe stip aan de rechterkant. Echter bleek uit de co-creatie sessie dat het wenselijker is als er op deze plek een toggle komt te staan om een laag aan of uit te kunnen zetten. Deze toggle dient nu ook als markering van een ingevulde filter omdat deze alleen verschijnt als er iets is gewijzigd. Op deze manier wil ik de gebruiker een duidelijk overzicht geven van de actieve filter.
Toggle filters aan of uit
Uit overleg is gebleken dat het fijn zou zijn als je ingevulde filters tijdelijk uit kunt zetten om deze niet mee te laten tellen in de berekeningen. Om dit patroon herkenbaar te maken voor de gebruiker heb ik het patroon van Photoshop (en vele andere tools) overgenomen door het oogje als icoon te gebruiken om een laag aan/uit te zetten.
Ordening van de filters variabelen
De ordening van de filters is gebaseerd op relevantie. Het zou in de ideale situatie het meest wenselijk zijn om de filters te sorteren op relevantie. Dit zou dan een selectie zijn op basis van de meest gebruikte filters onder alle gebruikers van PICTURE. Echter is dat lastig te realiseren en hebben we besloten om de belangrijkste key filter variabelen bovenaan de filter te zetten. De rest van de filter variabelen staat geordend op alfabetische volgorde.
Slimme zoekfunctionaliteit
De benaming van de filter criteria is niet onder elk behandelcentra gelijk en hier moest dus een slimme oplossing voor bedacht worden. Hiervoor dat ik twee scenario's bedacht:
- 1.Een slimme zoekbalk die de gebruiker relevante filtercriteria geeft a.h.v de zoekterm(en).
- 2.Een "i" met uitleg over de variabelen.
Uiteindelijk heb ik besloten om toch te gaan voor de eerste optie. Er staat al veel in de header van een tabje: expand, titel, toggle en de komst van nog een item in deze header zou ervoor zorgen dat het rommelig en druk over zou komen. Als de gebruiker zoekt op een algemene term zoals "overleving" dan blijven de relevante variabelen zoals KPS en survival time bijvoorbeeld over. Op deze manier heb ik de verschillende terminologie van behandelcentra overbrugt.
Afb 3. Slimme zoekfunctionaliteit
Op basis van de co-creatie sessie met Roelant heb ik gevraagd wat een valide populatie is. Dit moet, zonder een specifieke tumor locatie, rond de 100 zijn en anders 10. Om de gebruiker te laten weten dat de populatie nu te klein en dus minder betrouwbaar wordt heb ik een eerste schets gemaakt van hoe dit er ongeveer uit zou kunnen zien.
Afb 4. Concept: warning te lange patient amount
Last modified 2yr ago