Uitbreiden en verbeteren Ons Wondzorg wondherkenning software

Afstudeerverslag, versie 1.0

Afstudeerperiode: 10 februari 2020 t/m 3 juli 2020 Student

Mathijs Hudepohl 434723@student.saxion.nl

Uitbreiden en verbeteren Ons Wondzorg

wondherkenning software

Afstudeeropdracht van Mathijs Hudepohl, uitgevoerd bij Nedap Healthcare voor het uitbreiden en verbeteren van wondherkenning software.

Versiebeheer

Versie Datum Beschrijving

0.1 06-04-2020 Tussentijdse oplevering

• Documentstructuur opgesteld

• Onderdelen PvA samengevoegd & verbeterd • Onderzoeksresultaten toegevoegd

• Eerste versie van ontwerp 0.2 04-05-2020 Tussentijdse oplevering

• Feedback verwerkt:

o Inleiding toegevoegd, introductie aangepast o Volgorde genoemde onderwerpen aangepast o Procesbeschrijving aangepast

o Hoofdstuknummering toegevoegd • Oude en nieuwe situatie (ontwerp) beschreven • Realisatie van basic server/client flow beschreven 0.3 18-05-2020 Tussentijdse oplevering

• Feedback verwerkt:

o Lokalisatie anders verwoord

o Huidige/nieuwe situatie anders verwoord o Onderzoeksresultaten van 1.3 beter beschreven o Onderzoeksresultaten van 2.3 beter beschreven o Gebruik van TF en TFLite beter beschreven o Visualiseren multi-task netwerk resultaten

requirement aangepast naar should • Ontwerp release structuur beschreven

• Realisatie van “Toevoegen Automatisch hertrainen” beschreven

0.4 02-06-2020 Oplevering conceptversie • Feedback verwerkt:

o Structuur van verslag veranderd (verbeteren dataverzameling systeem en uitbreiden Vesalius netwerk opgesplitst)

o API Endpoints kort beschreven, volledige beschrijving is nu te vinden in de bijlage

• Beschrijving realisatie basic server/client flow uitgebreid • Begin gemaakt in realisatie Uitbreiding Vesalius netwerk 1.0 15-06-2020 Oplevering definitieve versie

• Resultaat “Toevoegen Automatisch hertrainen” beschreven • Realisatie “Uitbreiden Vesalius Netwerk” beschreven • Reflectie toegevoegd

1 Inhoudsopgave

1 Inhoudsopgave ... 3

2 Samenvatting ... 4

3 Inleiding ... 4

4 Introductie ... 5

5 Procesbeschrijving ... 9

6 Onderzoek ... 13

7 Ontwerp ... 23

8 Realisatie ... 28

8.1 Opzetten basis server/client flow ... 28

8.2 Toevoegen Automatisch hertrainen ... 32

8.3 Uitbreiden Vesalius netwerk ... 36

9 Reflectie ... 43

10 Aanbevelingen ... 44

11 Literatuur ... 45

2 Samenvatting

Dit document heeft betrekking tot de afstudeeropdracht van Mathijs Hudepohl. De opdracht is een verplicht onderdeel van de Bachelor studie HBO-ICT Software Engineering vanuit Saxion University of Applied Sciences te Enschede. De opdracht is uitgevoerd in opdracht van Nedap N.V., gevestigd in Groenlo. Door de uitbraak van het Covid-19 virus is de opdracht voor het grootste gedeelte thuis uitgevoerd.

In dit document staat beschreven op welke manier het wondherkenningssysteem van Ons Wondzorg is verbeterd en uitgebreid. Na een korte introductie van het bedrijf en de opdracht, staat het uitvoeringsproces beschreven. Dit proces is begonnen met een algemeen onderzoek, hiervan zijn de resultaten beschreven en later toegepast in het ontwerp. Zowel in het ontwerp- als realisatiehoofdstuk staan de gemaakte keuzes beschreven.

Het resultaat van de opdracht bestaat uit twee afzonderlijke onderwerpen die te maken hebben met hetzelfde systeem. Het eerste onderwerp heeft als doel om het wondherkenningssysteem te verbeteren. Hierbij wordt het gebruik van het huidige dataverzamelingssysteem verbeterd door offline dataverzameling mogelijk te maken. Daarnaast wordt binnen dit onderwerp gekeken hoe de verzamelde data gebruikt kan worden voor het verbeteren van het wondherkenningssysteem. Het tweede onderwerp heeft als doel om meer informatie dan alleen de wondlocatie te achterhalen. Dit is een uitbreiding van het al bestaande wondherkenningssysteem.

Door het uitbreiden en verbeteren van het wondherkenningssysteem komt deze steeds dichterbij het integreren in de Ons Wondzorg applicatie. Het integreren van het systeem zal ervoor zorgen dat het registreren van wonden gedeeltelijk geautomatiseerd wordt.

3 Inleiding

In dit afstudeerverslag staat de uitwerking van het uitbreiden en verbeteren van het Ons Wondzorg wondherkenningssoftware beschreven. De opdracht bevat uitbreidingen en verbeteringen van een al bestaand systeem, Vesalius. Vesalius bestaat uit een neuraal netwerk. Dit neuraal netwerk dient voor het herkennen van wonden in een afbeelding. Mattijs Kuhlmann heeft tijdens zijn afstudeerperiode een uitbreiding aan het systeem gemaakt. Deze uitbreiding bestond uit het toevoegen van een backend/API. Deze backend werkt samen met een Android-App, zodat er meer trainingsdata verzameld kan worden met behulp van de feedback van gebruikers.

Allereerst staat de uitdaging van de opdracht en het uitvoeringsproces beschreven. Ter voorbereiding van de uitvoering is een onderzoek uitgevoerd. Dit onderzoek maakt duidelijk hoe en wat er gerealiseerd zal worden. Aan de hand van de opdrachtomschrijving zijn een aantal requirements opgesteld. Hierbij zijn passende onderzoeksvragen bedacht, zodat de juiste toepassing van de requirements bepaald kunnen worden. Voor het uitvoeren van de opdracht is er eerst een ontwerp gemaakt. In het ontwerp staan de huidige situatie, de nieuwe situatie en de verschillen beschreven. Het realisatieproces wordt uitgevoerd in drie fases. De werkzaamheden van deze fases zullen te maken hebben met verschillende onderdelen van de opdracht. De eerste fase is voor het verbeteren van de communicatie tussen de Android-App, de backend/API en het neurale netwerk. De tweede fase is voor het toepassen van de eerder verzamelde feedback data van gebruikers voor het automatisch opnieuw trainen van het netwerk. De derde fase is het uitbreiden van het netwerk, waardoor meer informatie (dan enkel het herkennen van de locatie van een wond) achterhaald zal

4 Introductie

4.1 Het bedrijf

Nedap bestaat uit een aantal marktgroepen die zich richten op het verbeteren van verschillende sectoren. De uitvoering van de opdracht zal gebeuren binnen de marktgroep Nedap Healthcare. Bij Nedap Healthcare ligt de focus bij het maken van softwareoplossingen. Met deze oplossingen kunnen processen binnen de zorg beter en efficiënter uitgevoerd worden.

Nedap Healthcare levert verschillende producten die zijn samengevoegd in een platform genaamd Ons. Een van deze producten heet Ons Wondzorg. Ons Wondzorg richt zich op de verzorging van wonden. Met het systeem van Ons Wondzorg kan de voortgang van een wond worden bijgehouden. Het bijhouden van deze voortgang wordt onder andere gedaan door het maken en opslaan van foto’s van de wond. Deze informatie is een toevoeging aan het globale dossier van een patiënt dat ook gebruikt wordt door de andere producten van Ons.

Binnen Ons Wondzorg is het project “Vesalius” gestart. Het doel van dit project is zoveel mogelijk informatie uit de afbeeldingen van een wond te halen. Hierbij kan gedacht worden aan informatie als het type wond, het soort wondweefsel, de grootte van de wond en de wondvochtigheid. Het achterhalen van dergelijke informatie zal door middel van Machine Learning gedaan worden.

4.2 Beginsituatie

Het Vesalius project bestaat uit een eerste versie van een neuraal netwerk. Dit neuraal netwerk wordt getraind om een wond in een afbeelding te herkennen. Het resultaat van het trainen van het netwerk is een getraind model. Met dit model kunnen voorspellingen op andere afbeeldingen gedaan worden. Het neurale netwerk wordt getraind met een redelijk kleine hoeveelheid trainingsdata. Er is een app ontwikkeld voor het verzamelen van meer trainingsdata. Deze data wordt verzameld, zodat het gebruikt kan worden voor het trainen van het neurale netwerk. Binnen de app kan een gebruiker een foto maken. Door middel van een externe API, wordt een resultaat opgehaald van een getraind model (getrainde versie van het neurale netwerk). Dit resultaat wordt in de app gevisualiseerd door over de gemaakte afbeelding een gebied te markeren. Dit gebied is het gebied dat het systeem herkend als wond. Er kan op verschillende manieren feedback gegeven worden op dit resultaat (meer hierover staat beschreven in Oude situatie, User-flow). De verzamelde feedback wordt verstuurd naar de API. Hier wordt het opgeslagen gebruikt te worden bij het trainen van het neurale netwerk. Met deze verzamelde data wordt echter nog niets gedaan.

4.3 Opdrachtomschrijving

Aan de hand van de beginsituatie is in overleg met de afstudeerdocent en de bedrijfsbegeleiders een opdracht samengesteld. Hierbij zal aan verschillende onderdelen gewerkt worden. De opdracht bestaat uit twee onderwerpen die elk hun eigen onderdelen hebben. De beschrijving van de twee onderwerpen en de bijbehorende onderdelen staan hieronder beschreven.

4.3.1 Verbeteren van dataverzamelingssysteem

Het eerste onderwerp van de opdracht is het verbeteren van het huidige dataverzamelingssysteem. De beginsituatie van de opdracht heeft een aantal verbeterpunten, zodat het verzamelen van data beter kan verlopen. Deze onderwerpen staan hieronder beschreven.

4.3.1.1 Local Vesalius inferencing

De huidige implementatie van de app werkt alleen indien er een internetverbinding beschikbaar is. De reden hiervoor is de locatie van het getrainde model. Deze staat namelijk op de API/backend. Het toepassen van local inferencing zal ervoor zorgen dat de app ook gebruikt kan worden met slechte of geen internetverbinding. Met deze techniek wordt het getrainde model op het apparaat van de app opgeslagen (local). Wanneer het nodig is, zal deze gebruikt worden voor het verkrijgen van resultaten (inferencing).

4.3.1.2 Opnieuw trainen met feedback data

In de beginsituatie wordt door middel van de app feedback data opgehaald en opgeslagen op de server. Met deze feedback data wordt nog niets gedaan, terwijl het gebruikt kan worden voor het opnieuw trainen van het algoritme voor betere, meer accurate resultaten. Het is niet ideaal om dit telkens weer handmatig te doen. Het idee is om dit proces te automatiseren. Door het algoritme automatisch opnieuw te trainen met nieuwe feedback data, zal deze na verloop van tijd telkens slimmer worden.

4.3.1.3 Versiebeheersysteem

Wanneer het algoritme opnieuw getraind wordt, leidt dit niet altijd tot betere resultaten. Het is dus belangrijk om eerdere versies van getrainde modellen beschikbaar te houden. Er zal gebruik gemaakt worden van een versiebeheersysteem, zodat dit gestructureerd bijgehouden kan worden. Dit systeem zal relevante informatie bijhouden van elk getraind model, zoals de datum waarop deze getraind is en de accuratie van het model. Op basis van deze informatie kan de app kiezen welke versie opgehaald moet worden. In eerste instantie zal dit gaan om de laatste versie van het model. In een later stadia kan er echter gekozen worden om de keuze bij de gebruiker te leggen. De gebruiker zal kunnen kiezen tussen bijvoorbeeld een stable of latest versie.

4.3.2 Uitbreiden Vesalius neuraal netwerk

Het tweede onderwerp van de opdracht is het uitbreiden van het Vesalius neuraal netwerk. Dit onderwerp is toegevoegd aan de opdracht, gezien het niet zeker was of de opdracht voldoende complexiteit bevatte. Het idee is om het Vesalius netwerk uit te breiden, zodat deze meer informatie achterhaald dan alleen het wondgebied. Naast het herkennen van het wondgebied zal deze dus ook informatie als de kleurstelling van een wond of de structuur van het wondweefsel herkennen.

4.4 Requirements

Per onderdeel van de opdracht zijn er een aantal requirements opgesteld aan de hand van de MoSCoW-methode. Hiermee kan per requirement gezegd worden of een requirement een ‘Must have’, ‘Should have’, ‘Could have’ of ‘Won’t have’ prioriteit heeft. De requirements hebben elk een kleur gekregen, waarmee de prioriteit wordt aangegeven.

Must have Should have Could have Won’t have

Opzetten basis server/client flow

# Requirement Toelichting

1 De app moet een resultaat kunnen krijgen zonder gebruik te maken van een internetverbinding.

Er moet lokaal (op het apparaat) een versie van het model opgeslagen worden. Dit model kan een prediction doen. Dit resultaat moet gevisualiseerd kunnen worden zonder gebruik te maken van een internetverbinding.

2 Het systeem moet de nieuwste versie van het model beschikbaar stellen.

Wanneer er een model getraind is, worden de bestanden voor het gebruik van het getrainde model opgeslagen op de server. Van het getrainde model zal informatie opgeslagen worden. Deze informatie is nodig voor het bepalen van de nieuwste versie. In de API zullen endpoints komen voor zowel het achterhalen van het nieuwste versienummer als het downloaden van het nieuwste model.

3 De app moet de nieuwste versie van het model kunnen ophalen, opslaan en toe kunnen passen.

Wanneer er een internetverbinding beschikbaar is, zal aan de API de nieuwste versie van het model gevraagd worden. Wanneer deze versie nieuwer is dan het lokaal opgeslagen model, zal het nieuwere model van de API opgehaald worden en gebruikt worden binnen de app.

4 Het systeem moet een specifieke versie van het model beschikbaar stellen.

Tijdens het uitvoeren van de opdracht zullen er verschillende versies van het model beschikbaar komen. Er zal een nieuwe versie komen wanneer het model opnieuw getraind wordt en wanneer het netwerk wordt aangepast. Voor de

ondersteuning van verschillende app versies zullen ook oudere versies van het model beschikbaar blijven. 5 Het systeem zal een logische

manier van

versienummering hebben.

In eerste instantie is het van belang om de nieuwste versie bij te houden. Voor situaties als verschillende app-versies en modelversies zal het echter zo zijn dat er andere informatie toegevoegd moet worden. Hiermee kan gecontroleerd worden of de versies met elkaar kunnen werken.

Toevoegen automatisch hertrainen

# Requirement Toelichting

1 Het systeem moet automatisch het netwerk opnieuw trainen met nieuwe data.

Elke periode zal het systeem kijken of er nieuwe trainings- en/of feedback data beschikbaar is. Wanneer er nieuwe data beschikbaar is, dan zal het netwerk opnieuw getraind

worden. De nodige bestanden om het model te gebruiken zullen worden opgeslagen. De nieuwere versie van het model zal gelijk beschikbaar gesteld worden door de API.

2 Elke versie van getrainde modellen is beschikbaar via de API.

Elk getraind model kan gebruikt worden door het beschikbaar stellen van de desbetreffende versie van het model.

Uitbreiden Vesalius netwerk

# Requirement Toelichting

1 Het systeem moet de wond in een afbeelding blijven herkennen.

De huidige functionaliteit van het Vesalius netwerk is het herkennen van een wond in een afbeelding. Het uitbreiden van het netwerk betekent dat die functionaliteit nog extra informatie zal herkennen.

2 Het systeem moet andere informatie over een wond in een afbeelding kunnen herkennen en teruggeven.

Naast de annotaties van de locatie van de wond zal ook andere informatie worden toegevoegd. Op deze manier kan er meer informatie uit een afbeelding gehaald worden. Naast de al bestaande informatie zal ook de nieuwe informatie herkend en teruggegeven worden.

3 De app moet nieuwe resultaten van het model kunnen visualiseren.

Een gebruiker wil het resultaat van het toevoegen van

nieuwe informatie aan het model zien. Dit zal gedaan worden op dezelfde manier als het markeren van de locatie van de wond.

4 In de app kan de gebruiker feedback geven per nieuwe soort toegevoegde

informatie.

In de huidige situatie van het model kan feedback op het ontvangen resultaat worden gegeven. Het is gewenst om ook op deze informatie feedback te kunnen geven, zodat het model hiermee verbeterd kan worden.

5 Procesbeschrijving

5.1 Opdracht onderdelen

De opdracht is onderverdeeld in verschillende fases, zodat het overzichtelijk blijft aan welk onderdeel er gewerkt wordt. In deze fases wordt er aan de verschillende onderdelen van de opdracht gewerkt. Elke fase heeft een doel dat gerealiseerd moet worden, zodat hier in een latere fase uitbreidingen aan gedaan kunnen worden. In Figuur 1 zijn de verschillende fases van de opdracht te zien, samen met de onderdelen waaraan gewerkt zal worden in de fase.

Figuur 1: Opdracht fasering & bijbehorende onderdelen 5.1.1 Opzetten basis server/client flow

Het eerste onderdeel van de opdracht is het opzetten van de server/client flow. Het resultaat van het onderdeel is het opzetten van de communicatie tussen de app (client) en de API/backend (server) staat. De focus ligt hierbij op het lokaal gebruik maken van een getraind model. Hiervoor zal ook de eerste versie van het versiebeheersysteem worden opgezet, zodat deze te downloaden is via de API. 5.1.2 Toevoegen automatisch hertrainen

De tweede fase van de opdracht zal het hertrainen van het model met beschikbare feedback data zijn. Het resultaat van het opnieuw trainen is een nieuw getraind model. Dit model zal gelijk in gebruik worden genomen door de app, doordat deze in het versiebeheersysteem wordt opgenomen.

5.1.3 Uitbreiden Vesalius netwerk

De derde fase is het ‘Uitbreiden Vesalius netwerk’-onderdeel. Aan dit onderdeel wordt als laatst gewerkt, gezien het onderdeel nooit echt ‘klaar’ zal zijn. Voor het afmaken van een neuraal netwerk moet deze namelijk goed geoptimaliseerd worden. Dit optimaliseren kost veel tijd en is niet haalbaar binnen de afstudeerperiode. De uitbreiding van het neuraal netwerk zal als resultaat verschillende soorten informatie uit een afbeelding halen en visualiseren in de app.

5.2 Projectfasen

5.2.1 Globale planning

De globale planningsfase heeft als doel om alle werkzaamheden van de opdracht in kaart te brengen. Dit houdt zowel het indelen van de opdracht in, als het vaststellen van de op te leveren documenten. De werkzaamheden worden beschreven en samengevoegd in een geschatte planning. Daarnaast zijn de beschrijving van de taken en de planning te vinden in het Plan van Aanpak.

5.2.2 Algemeen onderzoek

Er wordt een begin gemaakt aan het onderzoek na het afronden van het Plan van Aanpak. Het doel dit onderzoek is om de mogelijke oplossingen van de verschillende opdrachtonderdelen in kaart te brengen en te beslissen welke oplossingen gebruikt zullen worden.

5.2.3 Realisatie

Wanneer het algemeen onderzoek is afgerond, zal de realisatie per opdrachtonderdeel beginnen. De realisatiefase per onderdeel bestaat ook uit een aantal fases. Deze fases zijn hieronder te vinden.

5.2.3.1 Taakgerichte planning

Per opdrachtonderdeel is er een taakgerichte planning gemaakt. In deze planning staan de taken die uitgevoerd zullen worden. De planning is niet tijdsgebonden, maar beschrijft enkel de taken. De taken worden bijgehouden in Trello, zoals beschreven in het hoofdstuk Bijhouden van voortgang.

5.2.3.2 Specifiek onderzoek

Het algemeen onderzoek heeft geleid tot de oplossing die geïmplementeerd zal worden. De specifieke manier waarop dit gebeurt moet echter nog onderzocht worden. Het uitzoeken van deze manier gebeurt in een specifiek onderzoek. Een manier waarop dit onderzoek wordt uitgevoerd is bijvoorbeeld het maken van Proof-of-Concepts.

5.2.3.3 Code & documentatie

Tijdens het implementeren wordt er zowel code als documentatie geschreven. De documentatie zal bij de code zelf en op een algemene wiki pagina geschreven worden. Dit wordt gedaan, zodat voor anderen die aan de code werken makkelijk kunnen achterhalen waar de code voor dient.

5.2.3.4 Review

De laatste stap van het implementeren van een onderdeel is om het beoordeeld te laten worden. Dit zal gebeuren met hulp van andere personen (belanghebbenden die verstand van de code hebben) die het onderdeel testen en de code beoordelen. Wanneer het onderdeel voldoet aan de eisen van de requirements en het resultaat zoals gewenst is, zal de realisatie van het volgende onderdeel beginnen. 5.2.4 Presenteren & reflectie

Wanneer alle onderdelen zijn afgerond, zal het resultaat gepresenteerd worden aan belanghebbenden. De belanghebbenden hebben de kans om op dat moment nog feedback te geven op het product, zodat er nog kleine aanpassingen gedaan kunnen worden. Wanneer een aanpassing te groot is, zal hiervoor een advies gegeven worden voor een volgende stap in het product.

5.3 Werkwijze

5.3.1 Werkmethode

Tijdens de gehele afstudeerperiode wordt er gebruik gemaakt van SCRUM. Er zal veel gecommuniceerd worden met de bedrijfsbegeleiders en andere belanghebbenden. Dit wordt gedaan, omdat het product waaraan gewerkt wordt nog een prototype is. Hierdoor blijft iedereen up-to-date met de voortgang en zo kan er ook feedback gegeven worden.

5.3.1.1 Stand-ups

Dagelijks zal er een stand-up plaatsvinden. Tijdens deze stand-up worden taken waaraan gewerkt wordt besproken. Wanneer er problemen zijn waar ik tegen aan loop, worden deze hier ook besproken. Gezien mijn werkzaamheden met verschillende technieken zal ik ook regelmatig deelnemen aan stand-ups van andere teams binnen Nedap. Dit zal vooral voorkomen wanneer zij meer over een bepaald onderwerp weten.

5.3.1.2 Wekelijkse reflectie

Wekelijks vindt er met beide of met een van de bedrijfsbegeleiders een voorgangsgesprek plaats. Dit gesprek dient als een reflectie op de voorgaande week. Tijdens het gesprek zullen de uitgevoerde taken van de huidige en komende week besproken worden. Wanneer het nodig is, zullen hier ook onderwerpen worden besproken waar ik misschien tegen aan loop.

5.3.2 Vragen over verschillende technieken

Tijdens de uitvoering van de opdracht kan het zijn dat er over bepaalde onderwerpen onduidelijkheden zijn. Dit kunnen onduidelijkheden over al gerealiseerde producten, maar ook over de correcte implementatie van bepaalde technieken. Het kan zijn dat er binnen het Ons Wondzorg team niet voldoende kennis is over deze onderwerpen. Nedap (Healthcare) bestaat uit verschillende teams met elk hun eigen expertise. Door contact op te nemen met deze teams of personen binnen de teams kan ik op deze manier snel antwoord krijgen op eventuele vragen.

5.3.3 Bijhouden van voortgang

Door het gebruik van Trello is overzichtelijk welke taken uitgevoerd zullen worden. Daarnaast wordt de voortgang van de opdracht bijgehouden. Trello is een gratis tool waarin dashboards gemaakt kunnen worden met taken van een project. De keuze voor Trello is gemaakt, omdat ik er al eerder mee gewerkt heb. Het gebruik van Trello veroorzaakt geen problemen, gezien de taken geen gevoelige informatie bevatten.

5.3.4 Delen van code en bestanden

Voor het maken van de verschillende documenten wordt er gebruik gemaakt van de verschillende office-producten. Deze bestanden zijn voornamelijk voor Saxion en worden dus alleen uitgewisseld tussen de bedrijfsbegeleiders, de afstudeerdocent en mijzelf. De technische beschrijving van de gerealiseerde producten, samen met de gemaakte keuzes, zullen op Github beschikbaar zijn door middel van Markdown. Deze beschrijvingen zullen in het Engels zijn, zodat ook niet-Nederlands-sprekende medewerkers deze kunnen lezen.

Het bijhouden van de gemaakte aanpassingen wordt gedaan door middel van Github. Nedap heeft een eigen besloten topic ‘Nedap N.V.’. Hierin staan de Project-Boards en Repositories van de verschillende Nedap producten. Een drietal van deze Repositories zijn van belang voor de opdracht. Deze Repositories staan hieronder nader beschreven. Het realiseren van de onderdelen van de opdracht zal gebeuren door het maken van feature branches. Wanneer een feature/taak afgerond is, zal de persoon die hierover de meeste kennis heeft het werk reviewen. Op basis hiervan wordt besloten of de veranderingen samengevoegd kunnen worden met de main-branch.

5.3.4.1 Vesalius

Deze Repository bevat de logica van het opbouwen en trainen van het neurale netwerk. In de ‘Uitbreiden Vesalius netwerk’-fase zal er aan dit project gewerkt worden. Het gaat hierbij om het toevoegen van extra informatie aan het huidige netwerk. Voor het maken van deze aanpassing zullen de voorgaande onderdelen aangepast moeten worden, zodat deze de nieuwe informatie gebruiken.

5.3.4.2 Vesalius-backend

Deze Repository bevat de backend die gebruik zal maken van het getrainde model van het Vesalius netwerk. Het project wordt zo aangepast dat deze niet meer zal dienen voor het uitvoeren van het netwerk. In de nieuwe situatie zal de focus liggen op het beheren van de verschillende versies van getrainde modellen.

5.3.4.3 Vesalius-android

Deze Repository bevat de Android-App waarmee een gebruiker gebruik kan maken van het Vesalius model. De app bevat de mogelijkheid om afbeeldingen te maken, zodat deze opgestuurd kunnen worden naar de backend. Verder kan er feedback gegeven worden op een resultaat van het model. Het project wordt zo aangepast dat deze niet langer gebruik maakt van de API om resultaten te verkrijgen. Bij het maken van de uitbreiding in het Vesalius netwerk zullen de nieuwe resultaten ook gevisualiseerd worden.

6 Onderzoek

Er is een onderzoek uitgevoerd, zodat er goed van start kan worden gegaan met de opdracht. Dit onderzoek wordt gedaan aan de hand van de opgestelde requirements. Aan de hand van de requirements zijn een aantal onderzoeksvragen opgesteld. Deze onderzoeksvragen hebben als doel een duidelijk beeld te geven over het te realiseren resultaat en de daarbij te gebruiken technieken. De resultaten van deze onderzoeksvragen staan per onderdeel beschreven.

6.1 Onderzoeksvragen

Aan de hand van de requirements van de opdracht zijn er een aantal onderzoeksvragen opgesteld. Deze onderzoeksvragen sluiten aan bij de verschillende realisatiefases van de opdracht en dienen als richtlijnen voor het onderzoek. De resultaten van het onderzoek moeten genoeg duidelijkheid geven over de nodige informatie en technieken die gebruikt worden tijdens de realisatie.

1. Opzetten basis server/client flow

1. Welke technieken zijn er beschikbaar om een getraind model in een Android-App te gebruiken?

2. Welke informatie moet van een getraind model worden opgeslagen, zodat deze elders gebruikt kan worden?

3. Wat zijn de voor- en nadelen van het gebruik van een getraind model op een mobile device?

2. Toevoegen automatisch hertrainen

1. Welke manieren zijn er beschikbaar voor het automatisch opnieuw trainen van een neuraal netwerk?

2. Op welke plek zullen getrainde modellen opgeslagen worden?

3. Wat is het beste moment om het neurale netwerk opnieuw te trainen? 3. Uitbreiden Vesalius netwerk

1. Welke informatie moet herkend worden uit een afbeelding van een wond? 1. Wat is de beste manier om deze informatie te annoteren?

2. Welke techniek zal er gebruikt worden voor het achterhalen van verschillende soorten informatie?

6.2 Onderzoeksresultaten

1.1 Welke technieken zijn er beschikbaar om een getraind model in een Android-App te gebruiken? Wanneer een model getraind is, zal deze overgezet moeten worden naar het apparaat waar de Android-App op staat. Het model zal op het apparaat gebruikt worden voor het doen van predictions. Er wordt hierbij geen gebruik gemaakt van een internetverbinding.

De techniek die gebruikt kan worden voor het gebruiken van een getraind model binnen een Android-App is afhankelijk van de techniek die gebruikt is voor het opzetten en trainen van het neurale netwerk. Dit kan in dit geval alleen gedaan worden met TensorFlow-Lite (TFLite), omdat er binnen Nedap gebruik wordt gemaakt van TensorFlow (TF). Met deze techniek kan een getraind model worden omgezet naar een TFLite-model. Dit model wordt binnen de Android-App ingeladen en gebruikt om resultaten te verkrijgen. Bij het omzetten van een TF-model naar een TFLite-model wordt gebruik gemaakt van Post-Training Quantization (TensorFlow, 2020). Deze conversietechniek beperkt de opslag en de nodige CPU/GPU-kracht voor het opslaan en uitvoeren van het model. Het gebruik van de techniek gaat helaas ten koste van de accuraatheid van het resultaat. Hierover staat meer beschreven bij de volgende onderzoeksvraag.

In Figuur 2 Is de werking van TFLite te zien (TensorFlow, 2019). TFLite zal worden toegepast op twee plekken. De eerste plek is waar nieuwe modellen getraind worden. Na het trainen en opslaan van een getraind model (HDF5), zal de TFLite Converter het opgeslagen model omzetten naar een TFLite Flatbuffer. De tweede plek is de app waar het model gebruikt zal worden. Hier laadt TFLite Interpreter de TFLite Flatbuffer in, zodat deze gebruikt kan worden voor Local Inferencing.

Figuur 2: TensorFlow-Lite flow Bron: (TensorFlow, 2020)

1.2 Welke informatie moet van een getraind model worden opgeslagen, zodat deze elders gebruikt kan worden?

Er zijn twee manieren waarmee getrainde TensorFlow-modellen opgeslagen kunnen worden. De eerste manier is om deze op te slaan in een H5/HDF5 bestand. De tweede manier is een combinatie van een JSON en een H5/HDF5 bestand. Beide manieren kunnen gebruikt worden om een model in te laden en te gebruiken op een computer. Dit kan echter niet bij het inladen van een model binnen een Android-App. Bij de eerste manier wordt een definitieve versie van het model opgeslagen, zodat deze ingeladen en gebruikt kan worden. Bij de tweede manier wordt een tussentijdse state van het model opgeslagen waarmee verder getraind kan worden. Het omzetten van een TF-model naar een TFLite-model kan alleen met het H5 bestand van de eerste manier.

1.3 Wat zijn de voor- en nadelen van het gebruik van een getraind model op een mobile device? Het gebruiken van een getraind model op een mobile device heeft zowel voor- als nadelen. Er is gebruik gemaakt van een Proof-of-Concept, zodat de exacte verschillen achterhaald kunnen worden. Bij deze POC is het TF-model geconverteerd naar een TFLite-model en in een Android-App opgeslagen. Vervolgens zijn de verschillen tussen het gebruik van de app in de huidige situatie en met de POC naast elkaar gelegd. De verschillen staan hieronder beschreven. Deze zijn opgesplitst in een aantal onderwerpen.

Snelheid

Het vergelijken van de snelheid tussen de huidige en nieuwe situatie is gedaan op verschillende manieren. De resultaten staan in de tabel hieronder beschreven. De manieren waarop getest is, staan onder de tabel beschreven.

Case Netwerkverkeer CPU/GPU Snelheid

Emulator, externe API Ja API-server CPU 3000-6000ms

Emulator, interne API Ja Laptop CPU 2000-4000ms

Python ingeladen model Nee Laptop CPU 400-600ms

POC Emulator Nee Laptop CPU 400-600ms

POC Android device Nee Mobile CPU 3000-4000ms

POC Android device Nee Mobile GPU 600-1000ms

Tabel 1: Testresultaten snelheid huidige & nieuwe situatie.

De oude situatie (zonder local inferencing) is op drie manieren getest. De eerste twee manieren maken gebruik van de huidige datacollectie app. In de app kan een afbeelding worden gemaakt. Deze wordt geschaald naar een andere grootte en opgestuurd naar de API. Op de API-server wordt de prediction gemaakt en teruggestuurd naar de app. Dit is zowel getest met een externe (public development) als interne (localhost) API. Het grootste gedeelte van dit proces wordt ingenomen door het netwerkverkeer. De derde manier is getest door het getrainde model in te laden en een prediction te doen met dezelfde afbeelding. Hierdoor is het verschil tussen een prediction met en zonder netwerkverkeer goed te zien.

De nieuwe situatie (met local inferencing) is ook op drie manieren getest. Deze tests zijn gerealiseerd in een Proof-of-Concept. In deze POC zijn de technieken gebruikt zoals deze ook in het resultaat gebruikt zullen worden. De eerste manier hield in dat er werd getest op een emulator met dezelfde CPU als de vorige tests. De resultaten hiervan lagen erg dicht bij elkaar. Toch komt deze situatie niet vaak in de praktijk voor. Er is ook getest met een fysiek android-apparaat (Huawei Nova 3i). Tijdens deze tests werd zowel gebruik gemaakt van de CPU als de GPU van het apparaat. De CPU presteerde erg slecht, maar de GPU wist in de buurt te komen van de snelheid van de CPU van de laptop. Resultaat

Zoals beschreven in onderzoeksvraag 1.1 is het resultaat van een TFLite-model minder accuraat dan eenzelfde TF-model. Er zijn twee tests uitgevoerd waarbij gebruik is gemaakt van beide modellen. Deze tests werden gedaan om de exacte verschillen tussen de twee modellen te achterhalen. De resultaten van deze tests zijn te zien in Figuur 3. Voor het weergeven van de resultaten is eenzelfde structuur gebruikt zoals te zien in de afbeelding. Een goed resultaat van deze tests was dat de resultaten altijd hetzelfde zijn, ongeacht of deze meerdere keren worden uitgevoerd. Aan de linkerkant van de afbeelding is het resultaat van het TF-model te zien. Hier is het resultaat van pixel x:0 y:0, 0.6307589. Aan de rechterkant van de afbeelding is het resultaat van het TFLite-model te zien. Hier is het resultaat van dezelfde pixel 0.63038886. Het verschil dat Post-Training Quantization veroorzaakt is in dit geval 0.0003. In het geval van de app waarin de feedback gegeven kan worden in marges van 0.01, heeft dit verschil geen grote invloed.

Figuur 3: Testresultaten resultaat huidige & nieuwe situatie.

De resultaten van het TFLite-model zijn consistent. Hiermee wordt bedoeld dat het resultaat op de emulator hetzelfde is als die op een Android-device. Het verschil dat veroorzaakt wordt door Post-Train Quantization was verwacht. Het verschil is zelfs kleiner dan verwacht en is dus acceptabel. Conclusie

Op basis van voorgaande tests kunnen een aantal dingen vastgesteld worden. De snelheid van het doen van een prediction is in de nieuwe situatie een stuk sneller. Dit komt voornamelijk door het niet meer gebruik maken van netwerkverkeer. Zonder netwerkverkeer kan de gebruiker ook op locaties zonder internetverbinding gebruik maken van de app. Het nadeel van het converteren van het model is het verschil in resultaat. Het is lastig om te zeggen hoe groot de deze impact in de toekomst (met meer trainingsdata) is.

2.1 Welke manieren zijn er beschikbaar voor het automatisch opnieuw trainen van een neuraal netwerk?

Het opnieuw trainen van een netwerk kan op verschillende manieren gebeuren. Een manier om dit te doen is om het trainingsproces simpelweg opnieuw te starten. Een andere manier om dit te doen is om een bestaand getraind model verder te trainen met nieuwe data (door gebruik van de tweede manier in onderzoeksvraag 1.1). Aangezien er momenteel nog weinig data is waarmee het model getraind kan worden, is de keuze gemaakt om voor nu te kiezen voor de eerste manier. Het wordt echter wel aanbevolen om het verder trainen van een bestaand model te gebruiken op het moment er meer data bij komt.

De eerste mogelijkheid is om gebruik te maken van een Python library (schedule) om op een bepaalde tijd een functie uit te voeren. Hiervoor moet echter altijd een proces draaien, zodat de functie gestart kan worden. De tweede mogelijkheid is om gebruik te maken van crontab. Crontab is een techniek voor het uitvoeren van periodieke taken. Deze taken worden cronjobs genoemd. Het toevoegen van deze taken zal ervoor zorgen dat het trainingsproces op een bepaald tijdstip wordt uitgevoerd. Hiervoor hoeft het systeem geen afzonderlijk proces te draaien (Red Hat, Inc., 2020).

2.2 Op welke plek zullen getrainde modellen worden opgeslagen?

In de oude situatie is het zo dat een app een vaste versie van het model heeft. Bij de nieuwe situatie zal de versie van het model op de app automatisch geüpdatet worden naar een nieuwere versie wanneer dit gewenst is. Dit wordt gecontroleerd door middel van de backend/API waarvan de modellen ook gedownload kunnen worden. Dit brengt echter een aantal lastige vraagstukken met zich mee omtrent hoe de modellen op de backend terecht komen (ook door het automatisch hertrainen). Dit komt omdat het Vesalius netwerk en de backend twee verschillende producten zijn.

De eerste bedachte oplossing voor dit probleem was om de code van het trainen en opslaan van getrainde modellen te implementeren in de backend. Dit wordt geregeld door een deploy script waarmee de juiste backend instantie geselecteerd wordt. Vervolgens wordt hierin de code geplaatst waarmee een model getraind wordt. Binnen de backend wordt een taak gestart waarmee periodiek een nieuwe training plaatsvindt. Dit gebeurt op basis van de data die beschikbaar is in de backend. Deze oplossing zorgt echter voor een onoverzichtelijke bestandsstructuur. Hierbij is niet zeker wat waarbij hoort en het is tevens ook slecht schaalbaar. De reden hiervoor is dat het trainingsscript enkel kijkt naar de gegevens die te vinden zijn in die backend instantie. Wanneer er in een later stadia gebruik wordt gemaakt van meerdere backend-instanties, zal elke API-instantie eigen versies van getrainde modellen maken.

De tweede oplossing zal de twee producten los van elkaar laten werken. Het neurale netwerk zal nieuwe modellen trainen met trainingsdata afkomstig van de Github-repository en feedback data afkomstig van de backend-instantie(s). De getrainde modellen zullen na het trainen released worden op de Github-repository. Vanaf hier kunnen de getrainde modellen door de verschillende backend-instantie(s) gedownload worden. De instanties zullen periodiek kijken of er nieuwe getrainde modellen beschikbaar zijn. Vervolgens zullen zij deze downloaden en opslaan. Door de goede schaalbaarheid van dit systeem en de ondersteuning voor latere uitbreidingen is er dan ook gekozen voor deze aanpak.

2.3 Wat is het beste moment om het neurale netwerk opnieuw te trainen?

3.1 Welke informatie moet herkend worden uit een afbeelding van een wond?

Voor het uitbreiden van het Vesalius netwerk moet eerst gekeken worden met welke informatie het netwerk uitgebreid zal worden. Hiermee wordt bedoeld welke informatie nog meer uit een afbeelding herkend zal worden. Deze keuze is gemaakt aan de hand van het WCS Classificatiemodel (WCS Kenniscentrum Wondzorg, 2018). Dit model is een van de modellen die gebruikt kan worden bij het toepassen van een behandeling van een wond. Op basis van de informatie in dit model is achterhaald welke informatie interessant is om toe te voegen aan Vesalius.

Figuur 4: Het WCS Classificatiemodel Bron: (WCS Kenniscentrum Wondzorg, 2018) Kleuren van een wond

De kleurenstelling van een wond zegt veel over de gezondheid van de wond. Zoals in het model te zien is, kan een wond in drie kleuren worden ingedeeld. Wanneer de wond de kleur zwart bevat, wordt het gezien als een zwarte wond. Wanneer de wond de kleur geel bevat, wordt het gezien als een gele wond en anders wordt het gezien als een rode wond. Het herkennen van de verschillende kleuren in een wond is niet alleen een goed startpunt voor het bepalen van een behandelmethode, maar hiermee kan over langere tijd ook het verloop van de genezing van een wond gevisualiseerd worden. Het annoteren van de kleur kan op een aantal manieren gebeuren. De enige manier hiervoor is het gebruiken van zogenaamde masks. Deze masks zijn afbeeldingen waarin gebieden van de originele afbeelding zijn gemarkeerd. Een voorbeeld van hoe dit wordt toegepast in de huidige situatie voor het herkennen van de vorm van een wond is te zien in Figuur 5.

In de oude situatie werd er gebruik gemaakt van een PixelAnnotationTool. Dit is een tool waarmee met kleuren over een afbeelding getekend kan worden. Deze kleuren hebben elk hun eigen betekenis die ook gebruikt zullen worden in het netwerk. Hiervoor is gezocht naar een andere tool, aangezien de huidige trainingsdata moet worden uitgebreid en aangepast. Er is gekozen om gebruik te maken van Photoshop, omdat het makkelijke tools (Magic-wands) bevat voor het selecteren van gebieden. Wondvochtigheid

De volgende belangrijke indicator van een wond is de wondvochtigheid. Deze indicator is ook nodig voor het bepalen van een behandeling. De vochtigheid van een wond kan bepaald worden aan de hand van drie categorieën. Voor het bepalen van een behandeling is per wond de kleur en vochtigheid van belang. Bij het geval van een rode wond kan het een natte, stagnerende of droge wond zijn. Bij een gele of zwarte wond kunnen deze alleen nat of droog zijn. De combinatie van de twee indicatoren kan uiteindelijk gebruikt worden voor het bepalen van een behandeling.

Het annoteren van de wondvochtigheid van een wond kan vrij makkelijk gebeuren. De vochtigheid van de wond is namelijk één van de drie soorten. Het gegeven kan dus geannoteerd worden door middel van een ‘Vochtigheid ID’. Het nadeel hiervan kan zijn dat het netwerk zelf moet achterhalen wat de ID dan inhoudt. Hiervoor zal meer trainingsdata beschikbaar moeten zijn.

Grootte en/of vorm van de wond

Er zijn verschillende groottes en vormen van wonden. Een schaafwond kan bijvoorbeeld een groot gedeelte van een lichaamsdeel bedekken, terwijl een snijwond een langwerpig en dun gebied bedekt. Door het leggen van relaties tussen verschillende factoren, kan deze indicator helpen voor het bepalen van bijvoorbeeld de wondsoort.

Het annoteren van deze indicator kan gebeuren door bijvoorbeeld een breedte, hoogte en draaiing aan te geven. Het nadeel is wederom dat het netwerk zelf moet achterhalen wat deze informatie betekent, waardoor het dus lastig kan zijn om dit te trainen.

Wondsoort

Het type van de wond kan herkend worden door extra informatie over een wond te verkrijgen. Deze informatie kan helpen bij het bepalen van een behandeling, maar dient eerder als extra informatie die getoond kan worden aan een gebruiker.

Het annoteren van een wondsoort kan vrij simpel zijn. Het trainen van het netwerk zal daarentegen meer data nodig hebben, omdat het de verschillen moet kunnen onderscheiden. Het annoteren kan gebeuren door middel van een ‘Wondsoort ID’. Door de combinatie van verschillende relaties, zoals wond vorm/grootte, kan het netwerk beter bepalen wat voor wondsoort het is.

Conclusie

De indicator die het meeste geschikt is als eerste uitbreiding van het netwerk is de kleurstelling van een wond. Niet alleen is de kleurstelling van een wond het startpunt voor het bepalen van de behandeling, maar op deze manier is het maken van de trainingsdata ook niet al te lastig. De indicator is daarbij ook niet afhankelijk van andere gegevens.

3.2 Welke techniek zal er gebruikt worden voor het achterhalen van verschillende soorten informatie?

Tijdens de specialisatie ‘Big Data Technologies’, zijn er opdrachten gegeven om neurale netwerken te realiseren. Deze neurale netwerken leren aan de hand van Single-Task Learning (STL). Dit houdt in dat het neurale netwerk één resultaat heeft (hoogste score van meerdere mogelijkheden). Een neuraal netwerk kan ook leren met Multi-Task Learning (MTL). MTL is een uitgebreide variant van een STL. Niet alleen worden er met MTL meerdere resultaten achterhaald, maar daarnaast worden ook gelijkenissen en verschillen tussen factoren in acht genomen. Dit heeft voordelen voor de efficiëntie van het trainen en de accuraatheid van de uiteindelijke resultaten.

Een van de verschillen tussen een Single-Task en een Multi-Task netwerk is dat er dus meer informatie uit data wordt herkend. Hieronder staat een voorbeeld van de resultaten van de twee soorten netwerken. De eerste taak is het achterhalen van de locatie van de neus van een persoon. De tweede taak is het herkennen van de richting die de persoon op kijkt. Voor de eerste oplossing zou het dus zijn dat er twee aparte netwerken komen, elk met een eigen taak. De tweede oplossing voert beide taken tegelijk uit (Multitask learning in TensorFlow with the Head API, 2019).

Single-Task Learning Multi-Task Learning

Figuur 6: Verschillende resultaten van Single-Task en Multi-Task netwerken Voordelen (Tang, 2006)

Een van de voordelen van Multi-Task Learning is dat de netwerken vaak betere resultaten hebben en sneller trainen dan Single-Task netwerken. Dit komt door het leggen van relaties tussen de verschillen en overeenkomsten van de gegeven taken.

Een goed voorbeeld van taken die goed bij elkaar zouden passen zijn te zien in Figuur 6. In theorie zou het netwerk een relatie leggen, wanneer de locatie van de neus precies tussen de locatie van de ogen ligt. Hieruit blijkt dat de persoon rechtuitkijkt. Wanneer de positie van de neus dichter bij het ene oog staat dan bij het andere oog, is de kans groter dat de persoon ook die kant op kijkt.

Nadelen

Het grootste nadeel van Multi-Task Learning kan zijn wanneer er nieuwe informatie wordt toegevoegd. De nieuwe informatie kan nadelig gaan werken voor de andere taken. Wanneer een taak niet “meewerkt” aan het doel van het netwerk, kan er ruis ontstaan voor het leren van de andere taken. Een ander nadeel zou kunnen zijn dat elke taak gebruik maakt van dezelfde factoren/netwerk configuratie. Hierbij kan bijvoorbeeld gedacht worden aan de lagen van het netwerk. Bij gebruik van een techniek als Keras, die gebruikt wordt in het Vesalius netwerk, wordt de optimale configuratie van

3.3 Hoe kan de kwaliteit van het geconfigureerde neurale netwerk gecontroleerd worden?

De huidige hoeveelheid trainingsdata voor het neurale netwerk is niet erg uitgebreid. De trainingsdata bestaat namelijk maar uit negen afbeeldingen. Ondanks dat er wel een grote hoeveelheid afbeeldingen van wonden beschikbaar is (ca. zevenhonderd) kost het tijd om deze te annoteren met de gewenste informatie. Naast het annoteren van meer data (van afbeeldingen masks maken) is het belangrijk om het netwerk zo optimaal mogelijk te maken. Hierdoor zal het netwerk met meer data nog steeds goed werken. De manieren waarop dit gecontroleerd kan worden, staan hieronder beschreven.

Data augmentation

Data augmentation is een manier waarop er met weinig data toch veel variërende data gegenereerd kan worden. Deze techniek wordt voor zowel de oude als de nieuwe situatie gebruikt. De techniek past effecten toe op de data en gebruikt deze om het netwerk te trainen. Door effecten als draaiingen en kleureffecten toe te passen, ontstaat er meer variërende data.

Testen van de netwerkconfiguratie

Er is meer data nodig, zodat het netwerk op willekeurige afbeeldingen accuraat werkt. Dit hoeft het opzetten van het netwerk niet te hinderen. Het netwerk moet namelijk ook op de juiste manier geconfigureerd worden. Het controleren of een netwerk goed geconfigureerd is kan op een aantal manieren gebeuren. De manieren waarop dit gedaan kan worden, staan hieronder beschreven.

De eerste check is het bepalen van de juiste loss functie. De loss functie is essentieel voor het optimaal trainen van een neuraal netwerk. Het bepaalt namelijk de learning curve van het trainen. In Figuur 7 zijn verschillende soorten learning curves te zien. De learning curve wordt aangepast aan de hand van de learning rate die gebruikt wordt door de loss functie. Hoe beter deze geoptimaliseerd is, hoe accurater de resultaten van het netwerk zullen zijn.

Figuur 7: Visualisatie van verschillende loss functie configuraties Bron: (GitHub, sd)

De tweede check is het controleren van de structuur van het netwerk. Bij het maken van het Vesalius netwerk is ervoor gekozen om gebruik te maken van de UNet-structuur. Deze structuur is ontwikkeld voor het verwerken van biomedische afbeeldingen. Het voordeel van het gebruiken van deze standaard is dat het kan worden gebruikt voor verschillende doeleinden. Het verschil met een regulier netwerk structuur is dat er, in plaats van een resultaat over de gehele afbeelding, een resultaat per pixel van de afbeelding gegeven wordt (Zhang, 2019).

Figuur 8: UNet-structuur Bron: (Sankesara, 2019)

Aan de structuur van het netwerk zal in dit geval weinig veranderen. Dit is zo omdat het netwerk al geoptimaliseerd is voor het soort afbeeldingen. Het enige wat er met de opdracht zal veranderen, is dat er per pixel niet één resultaat (zekerheidsscore dat pixel deel is van wond), maar meerdere resultaten per pixel wordt teruggegeven (zowel zekerheidsscore pixel deel van wond als zekerheidsscore per WCS-classificatie kleur).

Bij het trainen van het netwerk moet voorkomen worden dat deze (te veel) overfit. Dit wordt voorkomen wanneer het netwerk de juiste cross-validation gebruikt. Dit kan gemeten worden door het trainingsproces te visualiseren zoals te zien in Figuur 9. De bedoeling is dat het netwerk een soortgelijke vorm aanneemt.

Figuur 9: Visualisatie gevolgen van overfitting Bron: (GitHub, sd)

De laatste controle is het uitvoeren van Sanity Checks. Deze sanity checks kunnen aantonen of het netwerk met een grotere dataset grotendeels hetzelfde zal presteren (GitHub, sd). Wanneer een netwerk goed is opgezet, zal deze uiteindelijk (onafhankelijk van de grootte van de dataset) overfitten (0 cost/loss). Dit kan getest worden met een kleine dataset. Wanneer het netwerk op deze dataset snel overfit is het netwerk goed geconfigureerd. Het kan voorkomen dat een neuraal netwerk overfit op een kleine dataset, maar niet goed geconfigureerd is. Dit kan komen door willekeurige features in de dataset die niet door de ontwikkelaar zijn aangegeven.

7 Ontwerp

In dit hoofdstuk is het globale ontwerp te vinden van de verbetering van het dataverzamelingssysteem. De globale werking van bepaalde onderdelen van het oude systeem zijn hier ook beschreven, omdat deze ook aangepast zullen worden.

7.1 Oude situatie

Het dataverzamelingssysteem is de combinatie van de Android-App en de API. In Figuur 10 is de werking van het systeem te zien. De werking wordt onder het figuur nader beschreven.

Figuur 10: Werking van het huidige dataverzameling systeem 7.1.1 User-flow

Wanneer de gebruiker de app opstart, krijgt deze een scherm te zien waar gegevens van de zorginstantie en de patiënt ingevuld moeten worden. Wanneer deze zijn ingevuld, kan de gebruiker een foto maken. Vervolgens kan de gebruiker deze foto bevestigen, waardoor deze wordt opgestuurd naar de API. Op de API wordt de foto geanalyseerd door een getraind model. Hier komt vervolgens een resultaat uit. De gemaakte afbeelding en het resultaat worden opgeslagen op de API. Daarna wordt het resultaat teruggestuurd naar de app. Het resultaat wordt in de app gevisualiseerd en de gebruiker kan hier nu feedback op geven. Na het bevestigen van de gemaakte feedback, zal ook deze data naar de API gestuurd worden en opgeslagen.

Er zijn twee manieren die gebruikt worden om feedback te geven. Deze manieren zijn te zien in Figuur 11. In het linker voorbeeld wordt een slider gebruikt om de ideale score aan te geven. Hiermee wordt het gebied van de wond uitgelicht. In het rechter voorbeeld kan de gebruiker zelf de wond markeren op de afbeelding. Zowel de ideale score als de aangepast markering worden naar de API verstuurd.

7.1.2 Python backend

De API is gerealiseerd met OpenAPI in combinatie met Connexion. OpenAPI zorgt voor een design-first structuur. Dit betekent dat de API pas kan werken wanneer deze duidelijk ontworpen en gedocumenteerd is. Connexion verzorgt de functionaliteiten van de API door gebruik te maken van Python. De API kan hierdoor een getraind model uitvoeren en verzamelde afbeeldingen, de originele resultaten en gegeven feedback opslaan.

Opslaan feedback data

Het opslaan van feedback data gebeurt aan de hand van de ingevulde gegevens van de zorginstantie en patiënt. In Figuur 12 is te zien hoe deze structuur er op de API uitziet. Er is te zien dat van elke patiënt (p123) van elke zorginstelling (c123) de originele afbeeldingen (wound_images), de originele resultaten (original_masks) en de feedback data (adjusted_masks) worden opgeslagen.

Figuur 12: Voorbeeld opslagstructuur API API-Endpoints

In de oude situaties zijn er twee endpoints voor het verzamelen van data. De functie van elke endpoint staat in de tabel hieronder beschreven. In de API-Endpoints bijlage is een uitgebreide beschrijving van de endpoints te vinden. Hierbij staat onder andere beschreven welke gegevens meegestuurd moeten worden.

Endpoint Beschrijving

/wound_image Deze endpoint wordt gebruikt om een resultaat te krijgen van een getraind model aan de hand van een gegeven afbeelding. Indien anders is aangegeven, wordt de ontvangen afbeelding en het resultaat van het model op de API opgeslagen.

/user_adjusted_mask Deze endpoint wordt gebruikt voor het opslaan van feedback data. Indien anders is aangegeven, wordt de ontvangen data op de API opgeslagen.

7.2 Nieuwe situatie

Er zijn verschillende onderdelen die zullen veranderen in de werking van het systeem. Door het verplaatsen van getrainde modellen van de backend naar de app verandert de rol van de backend. Op deze manier worden er alleen nog getrainde modellen en verzamelde data opgeslagen.

In Figuur 13 is de globale werking van het nieuwe systeem te zien. De backend van het systeem bevat enkel nog kleinere taken. Hierbij kan gedacht worden aan het beschikbaar stellen van getrainde modellen, de informatie over deze modellen en het opslaan van feedback data. De meeste taken zullen worden uitgevoerd binnen de Android-App. Het gebruik van de app zal niet veranderen, omdat gebruikers op dezelfde manier foto’s kunnen maken en hier feedback op kunnen geven. De eerste toevoeging is echter het moment wanneer er wordt gekeken naar een nieuwe modelversies. Wanneer dit het geval is, zal deze gedownload worden en lokaal worden opgeslagen. De tweede toevoeging is het lokaal uitvoeren van het opgeslagen model.

Figuur 13: Werking van het nieuwe dataverzameling systeem 7.2.1 User-flow

Wanneer de app geopend wordt, krijgt de gebruiker eerst het updatescherm van het model te zien. Hierin worden verschillende factoren in acht genomen om te kijken of de gebruiker de app kan gebruiken. Er wordt gekeken of er een internetverbinding beschikbaar is. Vervolgens wordt er gekeken of er een model op de telefoon staat opgeslagen en er wordt gekeken of er een nieuwe versie van het model beschikbaar is. De app wordt geblokkeerd op het moment dat er geen internetverbinding is en er geen model opgeslagen staat. Hierna wordt aan de gebruiker gevraagd om de app te openen wanneer er een internetverbinding beschikbaar is. De app kan wel gebruikt worden op het moment dat er een model opgeslagen staat, ongeacht de aanwezigheid van een internetverbinding. Wanneer er een nieuwe versie van het model beschikbaar is, zal aan de gebruiker toestemming gevraagd worden om deze te downloaden.

Er kan gebruik gemaakt worden van het model op het moment dat het downloaden/updaten is afgerond. Vervolgens kan de gebruiker de gegevens van de zorginstantie en de patiënt invullen en een foto maken. De gemaakte foto wordt geanalyseerd door het opgeslagen model waar vervolgens een

7.2.2 Python backend

De rol van de API is veranderd door het verplaatsen van getrainde modellen naar de app. Voorheen regelde de API het proces voor het uitvoeren van een getraind model. De API zorgde voor het opslaan van het resultaat en het veranderen van de grootte. De nieuwe functie van de API is het ophalen en beschikbaar stellen van verschillende modelversies. Daarnaast zorgt de API ook voor het opslaan van feedback data. De beschikbare modelversies worden bijgehouden in een versiebeheersysteem. Versiebeheersysteem

Het versiebeheersysteem maakt het mogelijk om te achterhalen welke verschillende modelversies er zijn opgeslagen op de backend. Bij het trainen van een model wordt een bestand aangemaakt met daarin informatie over het model. Hierbij kan gedacht worden aan de ondersteunde major en minor versies, de hoeveelheid gebruikte trainings- en feedback data, de accuraatheid van het model, het tijdstip van creatie en de gebruikte TensorFlow versie. Wanneer er verzocht wordt om de ondersteunde versies voor een bepaalde appversie te achterhalen, worden de major en minor versies van de app meegestuurd. Door het inlezen van de bestanden met informatie van alle modellen, kunnen de ondersteunde versies achterhaald worden.

API-Endpoints

In de nieuwe situatie zijn er een aantal nieuwe endpoints gemaakt. Met deze endpoints kunnen de verschillende versies van getrainde modellen opgehaald worden. Daarnaast kan een getraind model gedownload worden en feedback op de API opgeslagen worden. De verschillende endpoints staan hieronder kort beschreven. Een volledige beschrijving van de endpoints is te vinden in de API-Endpoints bijlage. Hier staat onder andere beschreven welke gegevens meegestuurd moeten worden.

Endpoint Beschrijving

/latest_model_version Deze endpoint wordt gebruikt om de nieuwste ondersteunde versie voor de app op te halen. De nodige major en minor versies staan hardcoded in de app. Deze geven aan welke getrainde modelversies door de app ondersteund worden. /supported_model_versions Deze endpoint wordt gebruikt om de alle ondersteunde versies

voor de app op te halen. De nodige major en minor versies staan hardcoded in de app. Deze geven aan welke getrainde modelversies door de app ondersteund worden.

/model Deze endpoint wordt gebruikt om een gewenste versie van een

getraind model te downloaden. De specifieke versie wordt door de app opgehaald door het uitvoeren van een van de vorige endpoints.

/wound_image_mask Deze endpoint wordt gebruikt voor het opsturen van de verzamelde data. Deze data bevat de ingevulde gegevens, de gemaakte afbeelding en de verzamelde feedback data.

7.2.3 Release structuur

In het vorige hoofdstuk is het ontwerp van de structuur van de app beschreven. In dit hoofdstuk wordt het ontwerp van de rest van de applicatie uitgelegd. Het gaat hierbij over het automatisch hertrainen van het neurale netwerk en het verzorgen van modelreleases op de Github-Repository. De manier waarop dit wordt gedaan, staat beschreven in onderzoeksvraag 2.3. In Figuur 14 is het ontwerp van het eindproduct te zien. Deze wordt onder het figuur nader beschreven.

Figuur 14: Communicatie tussen backend, neuraal netwerk training en GitHub

Zoals eerdergenoemd zijn Vesalius en Vesalius-backend twee verschillende producten. Deze moeten op een bepaalde manier met elkaar kunnen communiceren, omdat zij gegevens van elkaar gebruiken. Wanneer de twee applicaties in productie gaan (deployed worden), zullen deze op dezelfde server komen te staan. Dit heeft te maken met de verzamelde feedback data van de app. Deze data moet namelijk gesynchroniseerd worden. Wanneer dit wordt toegepast op meerdere servers, moet hier een andere oplossing voor bedacht worden. Hierover is meer informatie te vinden in de Aanbevelingen. Er is gekozen om deze oplossing nu nog niet te realiseren, omdat het project nog in een prototype fase zit.

Vesalius-training

Wanneer het Vesalius netwerk in productie gaat, zal deze automatisch modellen opnieuw gaan trainen. Dit wordt gedaan door een reeks van taken te starten, zodat de nodige gegevens worden opgehaald en het trainingsproces gestart kan worden. Eerst worden eventuele nieuwe trainingsafbeeldingen in de Github-Repository opgehaald. Vervolgens wordt de verzamelde feedback data opgehaald van de opslaglocatie in de backend applicatie. Tenslotte wordt het trainingsproces gestart. Het trainingsproces zal alleen gestart worden op het moment dat er nieuwe afbeeldingen beschikbaar zijn. Wanneer het trainingsproces is afgerond, wordt de nieuwe versie van het model bepaald. Dit wordt gedaan aan de hand van de versies die op de Github-Repository staan. Vervolgens wordt het model uitgebracht/released.

8 Realisatie

8.1 Opzetten basis server/client flow

Het opzetten van de server/client flow bestaat uit verschillende onderdelen. Deze onderdelen staan hieronder stap voor stap beschreven.

De eerste stap van het opzetten van de flow is het uitvoeren van een getraind model in de Android-app. Hiervoor moet het getrainde model worden omgezet naar TFLite-model. Dit gebeurt na het trainen. De manier waarop dit wordt omgezet, is te zien in in Figuur 2 van de Onderzoeksresultaten. Het omzetten gebeurt direct nadat een model getraind en opgeslagen is. Het opgeslagen model wordt ingeladen, omgezet en opgeslagen als een tflite bestand. Het tflite bestand maakt nu ook deel uit van de bestanden die beschikbaar zijn van een model. In Figuur 15 zijn deze bestanden te zien.

De tweede stap is het implementeren van het model in de app. Hiervoor moeten eerst de API-endpoints gerealiseerd worden. De manier waarop staat beschreven in de Nieuwe situatie: Python backend. De endpoints maken het mogelijk om te achterhalen welke versies van getrainde modellen ondersteund worden voor een bepaalde versie. Deze kunnen ook gedownload worden. In Figuur 16 zijn alle toegankelijke endpoints van de API te zien. Hierbij staan de endpoints van de nieuwe en oude situatie. De endpoints van beide situaties blijven beschikbaar voor backwards-compatibility.

Figuur 15: Structuur opgeslagen modellen

Na het toevoegen van de endpoints is er gewerkt aan het downloaden en opslaan van getrainde modellen in de app. In het begin van Figuur 13 in de Nieuwe situatie, staat dit beschreven als “nieuwste versie van model opslaan”. In de uitvoering kunnen zich echter meerdere scenario’s voordoen. Hierbij kan bijvoorbeeld gedacht worden aan het niet beschikbaar zijn van een internetverbinding en de afwezigheid van een opgeslagen model. De overige scenario’s zijn in de afbeeldingen hieronder zichtbaar.

Figuur 17: Geen internetverbinding, geen local model

Figuur 18: Wel internetverbinding, geen local model

Figuur 19: Nieuwe versie download succes

Figuur 20: Local modelversie up-to-date

Figuur 22: Geen internetverbinding, wel local model

Figuur 23: Geen server verbinding, wel local model

Nu er geregeld wordt dat er een versie van het model binnen de app beschikbaar is, is de volgende stap om te communiceren met dit model. Dit communiceren zal gedaan worden door middel van een TFLiteClassifier class. In deze class staat de code voor het inladen, instellen en uitvoeren van het model.

Het inladen van het model wordt gedaan door het model om te zetten in een ByteBuffer. Deze ByteBuffer wordt, samen met de instellingen voor het inladen, gebruikt om de Interpreter te instantiëren. Voor het gebruik van de Interpreter wordt de instelling voor het gebruik van GPU toegevoegd. Indien dit niet mogelijk is, wordt er gebruik gemaakt van de standaard instelling. De standaard instelling houdt in dat er gebruik wordt gemaakt van de CPU.

Voor het uitvoeren van het model wordt de Interpreter gebruikt. Er moeten twee stappen ondernomen worden om een resultaat van de Interpreter te krijgen. De eerste stap is om de gemaakte afbeelding aan te passen voor de invoer van de Interpreter. Hierbij wordt de afbeelding verkleind naar de nodige grootte (256x256 pixels). Vervolgens worden de RGB-waardes van elke pixel opgeslagen in een ByteBuffer. Deze ByteBuffer is de invoer voor de Interpreter. In de tweede stap wordt de uitvoer van de Interpreter beschreven. Hiervoor wordt een lege (nested) array gemaakt. De eerste twee lagen van de array zijn even groot als de breedte en hoogte van de invoer. De laatste laag heeft de grootte van het aantal resultaten dat per pixel gegeven wordt. In dit onderdeel is dit één waarde, namelijk de score voor wondsegmentatie.

De laatste uitdaging van de basis-flow is het visualiseren van de uitvoer. De uitdaging hierin is het aanpassen van de grootte van de uitvoer (256x256) naar de grootte van de afbeelding. Op deze manier kan het resultaat over de afbeelding getekend worden. Op de API werd dit gedaan door middel van verschillende functies in de opencv Python library. Deze (of soortgelijke) library is echter niet beschikbaar voor Java/Kotlin. De oplossing hiervoor is om de uitvoer “geschaald” te visualiseren over de afbeelding. Door de breedte/hoogte van de afbeelding (bijv. duizend) te delen door de invoer breedte/hoogte (256) en deze te vermenigvuldigen met het punt waarop getekend moet worden (bijv. 53), komt deze op een geschaalde positie (1000/256*53 = 207,03…). Het visualiseren tekent tussen de verschillende posities het geschatte gebied van de wond. Een voorbeeld hiervan is te zien in Figuur 24.

De laatste uitbreiding van het opzetten van de flow is het implementeren van een Request Queue. Wanneer de gebruiker de feedback data klaar heeft maar deze nog niet wil/kan versturen, wordt deze data in de queue opgeslagen. De data wordt op verschillende manieren opgeslagen. De gemaakte afbeelding wordt opgeslagen in de opslag van de app. Deze afbeelding wordt pas verwijderd op het moment dat een resultaat is verstuurd. Bepaalde gegevens, zoals de uitvoer van het model, worden opgeslagen in een object. Een object is in een programma vaak tijdelijk en verdwijnt op het moment dat deze gesloten wordt. De oplossing hiervoor is om de informatie op te slaan als tekst in de Shared Preferences. De gegevens die worden opgeslagen in de Shared Preferences zijn namelijk beschikbaar wanneer de app weer wordt opgestart. Door het object om te zetten naar een JSON-object, kan deze worden omgezet in een tekstvorm. Het omzetten naar een JSON-object wordt gedaan met behulp van GSON. Het JSON-object bevat een functie waarmee het omgezet kan worden naar een JSON-string. Deze string wordt opgeslagen in de Shared Preferences. Bij het raadplegen van de queue wordt de JSON-string omgezet naar een JSON-object. Dit object wordt door middel van GSON weer omgezet naar een object van de juiste Class. In Figuur 25 is de werking van de Request Queue te zien.

8.2 Toevoegen Automatisch hertrainen

De eerste stap van het automatisch hertrainen is het opnieuw trainen van het netwerk. Dit moet gebeuren op het moment dat er andere gegevens beschikbaar zijn. Er wordt gekeken naar de informatie van eerdere modellen, zodat er bepaald kan worden of er een nieuw model getraind moet worden. Deze informatie wordt achterhaald uit het informatiebestand dat aangemaakt is tijdens het trainingsproces. Het bestand (info.csv) is ook te zien in Figuur 15. De structuur van de inhoud van het bestand is te zien in Figuur 26. De informatie die gebruikt wordt om te kijken of een nieuw model getraind moet worden, zijn de major en minor versies en de hoeveelheid training en collected images. Wanneer er nog geen model is met een major en minor versie, wordt er altijd een nieuw model getraind. Wanneer er al wel een model met dezelfde versie is, wordt er enkel getraind wanneer er een verandering in de hoeveelheid data is.

Figuur 26: Structuur model informatie bestand

De tweede stap is het maken van scripts die gebruikt worden voor het ophalen van trainingsdata, het uploaden van een getraind model en het downloaden van getrainde modellen. De functionaliteit van deze scripts is mogelijk door de Github-API. Door middel van de API kunnen taken als het ophalen van gegevens, het downloaden van bestanden en het maken van releases (uploaden van getrainde modellen) gerealiseerd worden.

Figuur 27: Vesalius-Training scripts Figuur 28: Vesalius-Backend script

De scripts voor het downloaden van trainingsdata en modellen gebruiken dezelfde manier om de data op te halen. Het enige verschil tussen het downloaden van modellen en het downloaden van trainingsdata, is dat het downloaden van modellen via tags en releases gebeurt. Het downloaden van trainingsdata gebeurt op basis van specifieke mappen van de Repository (lichtelijk foutgevoelig wanneer deze mappen weggehaald worden). Het proces begint met het ophalen van de data die op de Github-Repository staat. Vervolgens wordt er gekeken naar de data die de applicatie al beschikbaar heeft. Op deze manier wordt achterhaald welke data nog gedownload moet worden. Wanneer er data is die alleen op de Repository staat, zal deze data gedownload worden. Dit is dus alleen de data die nog niet voor de applicatie beschikbaar is. De scripts zijn opgesplitst in een python en een bash bestand. Het bash bestand gebruikt door het python bestand gegeven data voor het ophalen van de juiste gegevens. Hierbij kan gedacht worden aan de nodige token en de Github-Repository. Het python bestand vult deze gegevens in, zodat de taak gemakkelijk uit te voeren is.

De aanvrager moet toegang krijgen tot het downloaden van de data, omdat deze data niet voor iedereen beschikbaar is. Github heeft hier een systeem voor. Door middel van een autorisatietoken kan aan dit systeem toegang gevraagd worden. Dit is te vergelijken met het invullen van een gebruikersnaam en wachtwoord. Er wordt gebruik gemaakt van een Ansible-Vault, omdat het niet veilig is om deze token hardcoded in de code te zetten. Deze ‘Vault’ slaat de token op en encrypt deze met een speciaal wachtwoord. Het resultaat van deze encryptie is te zien in Figuur 29. De token wordt pas beschikbaar op het moment dat de applicatie deployed wordt en het juiste wachtwoord wordt meegegeven.

Figuur 29: Voorbeeld inhoud Ansible-Vault

De laatste stap voor het automatisch hertrainen is het deployen van de Vesalius-training applicatie. Hiervoor is net zoals bij veel andere projecten binnen Nedap gebruik gemaakt van Ansible. Ansible is een tooling waarmee gemakkelijk en overzichtelijk een applicatie deployed kan worden. Dit wordt gedaan door gebruik te maken van de vele taken die Ansible mogelijk maakt.

De eerste stap van het deployen van een applicatie is het kopiëren van relevante bestanden naar de release omgeving (een server van Nedap). Dit kan gedaan worden door gebruik te maken van de copy functionaliteit. Met deze functionaliteit kan worden aangegeven welke bestanden/mappen gekopieerd moeten worden. Daarnaast kan de naam van het bestand/de map en de gewenste locatie meegegeven worden.