En trenings- og evalueringspipeline for 3D-segmentering av medisinske bildevolumer. Prosjektet samler hjerne, hjerte, lever og prostata i samme oppsett, men hjertemodellen er den som er trent og dokumentert i denne versjonen.
PythonPyTorchMONAI3D U-NetMR og CT
Spørsmålet
Hvordan kan én ryddig pipeline håndtere ulike typer medisinske volumdata uten å blande sammen forbehandling, modellvalg og evaluering?
Fremgangsmåte
Oppgavene styres av egne YAML-filer, mens datalasting, transformasjoner, trening og prediksjon er felles kode.
MR og CT behandles forskjellig. CT bruker et vevstilpasset Hounsfield-vindu, mens MR normaliseres per kanal.
Evalueringen rapporterer Dice, HD95, følsomhet og spesifisitet for hvert valideringsvolum.
Resultat
Hjertemodellen oppnådde gjennomsnittlig Dice på 0,856 på fem holdt-utenfor-volumer. Resultatene viser både sterke og svakere enkeltvolumer, som er viktigere enn å bare vise gjennomsnittet.
Prosjektet er laget for teknisk utforsking. Segmenteringen gir ikke diagnose eller sykdomsvurdering.
Et klassifikasjonsprosjekt for 14 røntgenfunn. Jeg har bygget modellen og gjort en ny, fullstendig evaluering på NIH sin offisielle holdt-utenfor-testliste.
Arbeidet bygger på 112 120 frontale bryst-røntgenbilder fra NIH. Den nye treningsrunden bruker 77 785 bilder til læring og 8 739 bilder til pasientadskilt validering. De 25 596 resterende bildene holdes utenfor helt til sluttkontrollen, slik at testresultatet sier noe reelt om modellen.
Spørsmålet
Kan en fleretikettmodell skille mellom røntgenbilder med og uten registrerte funn, og er modellskårene pålitelige nok til å bli vist utenfor en forskningskontekst?
Fremgangsmåte
Videreførte en ResNet-50-modell med 14 utganger fra et lagret kontrollpunkt.
Brukte 77 785 bilder i trening og 8 739 i pasientadskilt validering. Hele testlisten på 25 596 bilder ble holdt utenfor til slutt.
Valgte kontrollpunktet med høyest validerings-AUROC og kjørte deretter en uavhengig sluttest med per-klasse AUROC og average precision.
Resultat
Den valgte modellen oppnådde gjennomsnittlig AUROC 0,800 på den holdt-utenfor sluttesten. Det er en liten forbedring fra den tidligere kontrollen på 0,795. Skårene er ikke kalibrert som sykdomsrisiko og skal ikke brukes som medisinsk råd.
Dokumentasjon
Sluttrunden er dokumentert med modellfil, treningshistorikk og per-klasse-målinger. Kurvene under er fra den tidligere, fullstendige kontrollen og beholdes som metodeillustrasjon. De skal ikke leses som kurver for sluttmodellen.
Tidligere ROC-kurver som viser hvordan målet fungerer. Høyere kurve betyr bedre evne til å skille positive og negative testbilder.Tidligere trenings- og valideringshistorikk. Sluttrunden har en egen lagret treningshistorikk og per-klasse-tabell.
Kodeinnsikt
Jeg viser bare den delen av koden som forklarer modellvalget. Resten holdes ryddig i prosjektet, med egen kode for data, trening og evaluering.
Prosjektet viser en viktig del av arbeidsmåten min. Jeg kjørte en uavhengig kontroll av en eksisterende modell, dokumenterte begrensningene og valgte å ikke publisere en åpen opplastingsdemo før den kan forbedres og valideres på nytt.
Dette er et forskningsprosjekt. Det gir ikke diagnose, sykdomssannsynlighet eller beslutningsstøtte for pasienter.
Et maskinlæringsprosjekt på kliniske data fra kritisk syke pasienter. Målet var å anslå forventet liggetid fra demografiske, fysiologiske og sykdomsrelaterte opplysninger.
7 734 pasientforløp i analysen5 medisinske sentre9 sykdomskategorierPythonpandasscikit-learn
Det kliniske spørsmålet
Kan opplysninger som er tilgjengelige tidlig i et sykehusforløp brukes til å anslå liggetid? En slik modell er relevant for kapasitetsplanlegging, men lange og uforutsigbare forløp gjør oppgaven krevende.
Datakvalitet først
Råfilene inneholdt 7 740 pasienter. I en ny etterkontroll pakket jeg alvorlighetsdataene korrekt ut fra fire sykdomsgrupper, fjernet seks registreringer med ikke-positiv liggetid og sto igjen med 7 734 forløp.
Sykehusdød, senere registrert dødsfall, dag-7-målinger og tidspunkt for DNR-ordre ble holdt utenfor modellen. Dermed brukes ikke opplysninger fra fremtiden til å forutsi et tidligere tidspunkt.
Evaluering
Dataene ble delt i 6 187 treningsforløp og 1 547 holdt-utenfor testforløp. Imputering, skalering og kategorikoding ble lært kun fra treningsdata. Tre regresjonsmodeller ble sammenlignet mot en enkel gjennomsnittsbaseline med femfolds kryssvalidering.
Resultat
Random forest ga lavest gjennomsnittlig kryssvalidert RMSE med 19,9 dager, mot 21,4 dager for baseline. På det urørte testsettet ble RMSE 21,0 dager, MAE 11,4 dager og R² 0,14. Resultatet er en reell, men beskjeden forbedring og viser hvor vanskelig lange pasientforløp er å anslå.
Liggetiden er kraftig høyreskjev. Medianen er 11 dager, mens ti prosent av forløpene varer minst 38 dager. De lange forløpene påvirker RMSE sterkt.
Gjennomsnittlig RMSE for fem valideringsfolder, med hvert enkelt foldresultat vist som punkt. Random forest var marginalt best, men variasjonen mellom foldene er tydelig.
Prediksjoner mot faktiske verdier for 1 547 holdt-utenfor forløp. Modellen treffer hovedtyngden bedre enn de lange oppholdene og undervurderer flere ekstreme forløp.
Etterkontrollen er den viktigste delen av prosjektet: den avdekket en feil i den opprinnelige JSON-innlesingen, bygget analysen på nytt og rapporterer et nøkternt testresultat fremfor et penere, men misvisende tall.
Dette er en retrospektiv studentanalyse av historiske amerikanske data fra 1989–1994. Modellen er ikke validert for klinisk bruk og skal ikke brukes til pasientbehandling eller kapasitetsbeslutninger.
Molekylmodellering · KJEM220
Borrelia OspA og Lyme-vaksineantigen
Et semesterprosjekt om hvordan valg av strukturmodell påvirker videre analyser av OspA, et antigen relevant for Lyme-vaksiner. Jeg sammenligner røntgenstruktur med AlphaFold2 og AlphaFold3, og ser spesielt på det beskyttende LA-2-epitopet.
AlphaFold2AlphaFold3HADDOCKGROMACSCHARMM36mPython
Spørsmålet
Gir startstrukturen systematiske forskjeller i docking og molekylærdynamikk, og er LA-2-epitopet stabilt og gjenkjennbart på tvers av strukturkildene?
Fremgangsmåte
Hentet eksperimentelle strukturer og sammenlignet dem med predikerte modeller ved strukturjustering, RMSD og pLDDT.
Forberedte docking av OspA og LA-2 med HADDOCK. OspC brukes som en mer rigid kontroll.
La opp en GROMACS-pipeline med replikater, RMSD, RMSF, hydrogenbindinger og MM/PBSA som analysegrunnlag.
Skrev plotte- og statistikkode slik at samme analyse kan brukes når fullstendige trajektorier er tilgjengelige.
Hva det viser
Prosjektet viser en arbeidsmåte der strukturkilde, kontrollsystem, målevalg og usikkerhet henger sammen. Det er ikke bare en modell sammenligning, men et forsøk på å undersøke hvor robust en videre biologisk tolkning er.
Dokket CspA–faktor H-kompleks. Kontaktpunkter i grensesnittet ble brukt som utgangspunkt for videre strukturell analyse.Utvalgte målinger fra molekyldynamikk. RMSD, radius of gyration og avstand i faktor H-kløften gir komplementære mål på stabilitet og bevegelse.
Strukturjustering mellom predikert og eksperimentell struktur. Sammenligningen brukes før docking og dynamikk, slik at videre tolkning bygger på målbar strukturell likhet.AlphaFold2 sin lokale konfidensvurdering. Den peker på hvilke deler av modellen som er mest og minst sikre før de brukes i videre analyse.
Den reproduserbare demoen bruker tydelig merkede, syntetiske dynamikkmålinger. Analyse- og visualiseringskoden er reell, men fullstendige mikrosekund-simuleringer er ikke kjørt innenfor semesterets ramme.
Digital tjeneste
Datahjelp
En konkret tjeneste for personlig IT-hjelp hjemme hos folk. Målet er å gjøre det lettere å be om hjelp med mobil, PC, nettverk og hverdagslige digitale problemer.
HTMLCSSJavaScriptFirebaseFirestore
Behovet
Teknisk hjelp oppleves ofte som uoversiktlig. Datahjelp samler tjenester, priser, kontakt og videre oppfølging på ett sted.
Fremgangsmåte
Utformet en enkel offentlig side med tjenestebeskrivelser, prisinformasjon og kontaktskjema.
Bygget et eget administrasjonsområde der forespørsler kan leses og håndteres.
Brukte Firebase Authentication og Firestore slik at henvendelser ikke blir liggende i en vanlig e-postinnboks.
Resultat
En publisert tjenesteside med en tydelig vei fra spørsmål til henvendelse. Arbeidet viser både brukerflate, datalagring og administrasjon av en liten digital tjeneste.
En norsk båtnavigasjonsapp med åpne kart- og værdata. Den samler ruteplanlegging, posisjon, turlogg og informasjon som er nyttig før og under en tur.
Next.jsTypeScriptLeafletKartverketMET Norge
Behovet
På sjøen trenger man kart, vær, rute og båtinformasjon i en arbeidsflyt som fungerer på mobil. Havkart er et forsøk på å samle dette rundt norske datakilder.
Fremgangsmåte
Integrerte Kartverkets åpne WMTS-kart med Leaflet.
La til GPS, fart og kurs, ruteplanlegging i nautiske mil og lokal lagring av ruter.
Bygget værproxyer mot MET Norge og funksjoner for turlogg, båtprofil og sikker dybde.
Resultat
En PWA som kan brukes som hjelpemiddel på mobil. Den viser hvordan jeg jobber med eksterne datakilder, kartinteraksjon og praktiske brukerbehov.
Navigasjonsvisning med rute, kurs, fart og neste veipunkt. Kartet bygger på gratis, åpne norske datakilder.Funksjonsmenyen samler ruteplanlegging, turregistrering, ankervakt, vær, ferger og kartinnstillinger i én mobiltilpasset arbeidsflyt.
Havkart erstatter ikke offisielle sjøkart, godkjente navigasjonssystemer eller godt sjøvett.
En simulator for pendelmaleri der brukeren kan utforske hvordan fysikk, maling og bevegelse skaper ulike mønstre.
Next.jsTypeScriptCanvas APIIndexedDB
Ideen
Prosjektet startet med ønsket om å lage et maleri som de fascinerende pendelvideoene på Instagram, der fysiske lover bestemmer sirkler, former og spor. Jeg ville gjøre den opplevelsen mulig å utforske selv.
Fremgangsmåte
Modellerte dempet pendelbevegelse og Lissajous-baner.
Bygget kontroller for maling, kast, lerretsbevegelse og symmetri.
Brukte et offscreen-lerret og lagret arbeider lokalt slik at brukeren kan fortsette senere.
Resultat
En responsiv, interaktiv start på et fysisk styrt maleverktøy. Den har flere forhåndsinnstillinger og eksport i høy oppløsning, men skal videreutvikles.
Et lagret eksempel fra simulatoren. Snoren og pendelen er synlige, slik at koblingen mellom bevegelsen og det ferdige mønsteret blir tydelig.
Et flerspiller-kortspill for venner på mobil og PC. Spillet handler om å bli kvitt kortene først, og om å oppdage når andre overser et mulig trekk.
Next.jsTypeScriptFirebase AuthFirestore
Utfordringen
Et kortspill med flere spillere må holde alle klienter oppdatert uten at spillet mister flyt eller regler blir inkonsekvente.
Fremgangsmåte
Skilte spillregler, handlinger, grensesnitt og Firebase-integrasjon i egne deler av prosjektet.
Brukte Firestore-lytting for oppdatert spilltilstand på tvers av enheter.
La til innlogging, venneliste, lobby, spillrom og håndtering av Moggie-straff.
Resultat
Et spill som viser arbeid med tilstand, regler og sanntidsoppdateringer. Det er bygget for at en vennegjeng skal kunne starte et spill uten teknisk oppsett.
Moggie Classic viser et kompakt, todimensjonalt spillbord med flere spillere og tydelig spillstatus.Moggie Club er en mer romlig spillopplevelse med bordvisning, spillere, siste kort og neste trekk samlet i samme grensesnitt.
Prosjektet krevde at en gruppe utviklet et komplett spill med menyer, baner, spillmekanikk og en spillbar sluttversjon.
Fremgangsmåte
Arbeidet ble delt opp med brukerhistorier, oppgavefordeling og felles planlegging.
Spillet fikk seks baner, plasserbare tårn, tre oppgraderingsnivåer og bølger av fiender.
Prosjektet ble pakket med Maven og kjører som en Java-applikasjon.
Resultat
En spillbar gruppeleveranse som viser hvordan jeg arbeider i et større kodeprosjekt med delt ansvar og et tydelig sluttprodukt. Jeg bygget og testet den siste lokale Java-versjonen på nytt før denne presentasjonen ble oppdatert.
Map1 under spill. Bildet viser spillbrett, tårnvalg, penger, aktive bølger og kontrollene for oppgradering og salg.Startmenyen fra den kjørende LibGDX-versjonen.Kartvelgeren viser de seks banene i den opprinnelige spillversjonen.
Leser dato, klokkeslett, GPS og kameradata fra EXIF før bildene behandles.
Grupperer bilder til turforslag ut fra tid og avstand, finner stedsnavn og henter historisk vær automatisk.
Lager WebP-visninger og miniatyrbilder i nettleseren, slik at originalfilene ikke må lastes opp.
Lar brukeren justere tittel, reisetype, aktiviteter, deltakere, høydepunkter, vurdering og egne notater.
Et levende minnearkiv
Forsiden samler siste tur, nøkkeltall, favoritter, mest besøkte steder og en visuell bildestrøm.
«På denne dagen», «Rundt denne tiden» og «Overrask meg» henter frem minner som ellers lett blir glemt.
Turer kan finnes igjen gjennom tidslinje, bildearkiv, personer, steder, land, kategorier, aktiviteter og søk.
Reisebøker kan settes sammen, lagres og gjøres klare for utskrift.
Kart, spor og steder
Norgeskart fra Kartverket, med OpenStreetMap og Esri utenfor Norge.
GPX-import beregner distanse, høydemeter, høyeste punkt og varighet på serveren, og forenkler lange spor uten synlig tap.
Stedssider samler besøk, favoritter, ønskeliste og egne eller delte anbefalinger.
Pågående turer kan følges og oppdateres mens de skjer.
Deling og fellesskap
Hver tur er privat som standard, men kan deles med venner, via en egen lenke eller i Utforsk.
Offentlige kartposisjoner avrundes for å beskytte nøyaktige hytte- og teltplasser.
Venner, medreisende, feed, kommentarer, reaksjoner, varsler og korte samtaler gjør minnene sosiale uten å ta over opplevelsen.
Delingsoversikten viser tydelig hvem som kan se hva.
Bygget som et ordentlig produkt
Ferd har egen innlogging med scrypt-hashede passord og JWT i httpOnly-cookie, serverstyrt tilgangskontroll, databasebaserte begrensninger mot misbruk og direkte bildeopplasting. Next.js-appen er selvhostet på en Node.js-server på min egen PC. Domenet ligger bak Cloudflare, som håndterer HTTPS og proxytrafikken inn til appen. Serveren er normalt tilgjengelig kl. 08.30–23.00 norsk tid.
Ferd er et av prosjektene jeg er mest stolt av. Det kombinerer produktidé, visuell utforming, personvern, kart, bildebehandling og et omfattende full-stack-system i én helhet.
Demonstrasjonsvisning med nøytralt eksempelinnhold. Oppbygningen og funksjonene er fra den faktiske appen; private turbilder er ikke brukt.Den offentlige inngangen til Ferd forklarer hvordan bilder blir til turer med dato, sted, vær og minner.
Et sett verktøy som gjør fotografier om til blyant- og fargeblyanttegninger.
PythonOpenCVNumPypygame
Prosjektet
Jeg kombinerte kantdeteksjon, tonelegging, fargebehandling og teksturer for å gi vanlige fotografier et håndtegnet uttrykk.
Resultat
En eksperimentell bildepipeline med en interaktiv pygame-visning for å sammenligne uttrykk og innstillinger underveis.
Et nøytralt, syntetisk kildefoto uten personer eller private omgivelser, brukt som inngang til den faktiske OpenCV-pipelinen.Resultatet fra Bildegenerator med OpenCVs kantbevarende filtrering, tonelegging og blyantskisse-effekt.
Personvern · Digital dagbok
Tankebok
En privat digital dagbok formet som en faktisk bok.
JavaScriptWeb CryptoElectronPWA
Prosjektet
Tankebok kombinerer et rolig, boklignende grensesnitt med lokal kryptering. Målet er at personlige notater skal føles gode å skrive og samtidig behandles med respekt for personvern.
Resultat
En nett- og desktopløsning med papirtekstur, sidevending og kryptert lagring i brukerens egen enhet.
Organisering · PWA
Hjemarkiv
En samlet oversikt over hjem, hytte, kjøretøy og viktige dokumenter.
JavaScriptFirebasePWALeaflet
Prosjektet
Hjemarkiv er laget for å gjøre praktisk familieinformasjon enklere å finne og følge opp, med dokumenter, frister, varsler og kartstøtte samlet på ett sted.
Kunnskapsdeling · PWA
Småbruk Kunnskapsbase
En kunnskapsbase for å bevare praktisk erfaring mellom generasjoner.
ES ModulesFirebasePWASøk
Prosjektet
Løsningen organiserer erfaring, rutiner og observasjoner slik at kunnskapen blir enkel å finne igjen. Den utforsker tydelig struktur, søk og lette visualiseringer.
Familiearkiv · PWA
Familiens Kokebok
En digital kokebok som tar vare på familiens håndskrevne oppskrifter.
JavaScriptFirebasePWABilder
Prosjektet
Gamle oppskrifter kan fotograferes, transkriberes og organiseres med bilder og kategorier, slik at de blir lettere å bruke og bevare.
Tilgjengelighet · Helse
Daglig Helse
En tilgjengelig helse- og hverdagsapp utviklet med eldre brukere i sentrum, med påminnelser, enkel registrering og trygghetsfunksjoner.
Faste medisiner kan registreres med dosering og ett eller flere klokkeslett.
Dagens doser vises samlet, kan markeres som tatt og lagres i historikken med tidspunkt.
Planlagte pushvarsler minner om medisiner, vann, bevegelse og daglig innsjekk, også når appen er lukket på støttede enheter.
Varslingsvindu, intervaller og lyd kan tilpasses, og oppsettet kan testes direkte i appen.
Oversikt og trygghet
Appen samler vanninntak, søvn, aktivitet, humør, smerte, blodtrykk, puls og vekt. Nødkontakter og legevakt er lett tilgjengelige, mens valgte venner kan få avgrenset innsyn og sende vennlige påminnelser når brukeren har gitt tillatelse.
Laget for enkel bruk
Store trykkflater, tydelig språk og tre tekststørrelser gjør appen lettere å bruke. Den kan installeres som PWA, har offline-støtte og synkroniserer brukerens egne data gjennom Firebase Authentication og Firestore-regler.
Daglig Helse er et hjelpemiddel for struktur og egenregistrering. Appen gir ikke medisinske råd og erstatter ikke helsepersonell.
Daglig Helse i bruk. Dagens viktigste registreringer er samlet i store, tydelige kort med enkel navigasjon.
En rolig, reklamefri Sudoku bygget spesielt til morfaren min.
JavaScriptAlgoritmerPWAIngen sporing
Prosjektet
Hintmotoren forklarer neste logiske trekk steg for steg i stedet for bare å avsløre svaret. Målet er en behagelig opplevelse som også hjelper spilleren å lære.
Offline først · Familie
Hyttebok
En digital gjestebok for små og store minner fra hytta.
ReactViteSupabaseIndexedDB
Prosjektet
Familien kan skrive innlegg med dato, vær, humør og bilder. Innholdet lagres lokalt først og kan synkroniseres når nettet er tilgjengelig.