[Automatisk tekstet av Autotekst med NB Whisper. Kan inneholde feil.]
Så jeg har kommet fra FHI, de vi holdt på med å ... Vi skal gjøre analyser og ting på TST.
Jeg skal takke litt om bakgrunnen for ... For hva vårt samfunnsoppdrag er, og hvordan det prosjektet jeg er i, som heter FIDA ...
Hva det skal gjøre.
Så skal vi gå inn på hvordan vi har brukt ATSD til å få brukt det her.
Så litt veien videre på hva vi har lyst til å utforske.
Men hvem er jeg?
Jeg er en innleid konsulent fra ALV.
Det skulle egentlig komme en fra FHI her, men de har en hel dag med andre kurs i dag.
Så da var det jeg som fikk lov å komme.
Jeg er en seniorpotet, som da driver med mye forskjellig.
Blant annet arkitektur og utvikling.
Og har gjort det siden 2013, så jeg har fått vekt med mye forskjellig.
Og nå har jeg fått lov til å være en av de som tester TSD, for å bruke det som plattform.
FHI sitt samfunnsoppdrag er det å drive med beredskap og det å klare å finne ... Ja, ha oversikt over hva som skjer når det er krisesituasjoner, det å drive med tilgjengeliggjøring for forskning og sånne ting, og det å ha register for helsedata og ha den typen data som er supersensitiv.
Det er ganske mange.
Det er 1300 ansatte, og de er spredt utover flere lokasjoner.
Man skal lage skalerbare løsninger for overvåkning.
Og det å ha beredskapssituasjoner, sånn som f.eks.
da korona kom, det å kunne skalere opp og gjøre det på en veldig bra måte, med data som kommer inn fra veldig mange kilder, og store datamengder, er veldig viktig.
Det å gjøre det på en effektiv måte, og det å klare å gjøre store analyser fortløpende, stiller også krav til ulike plattformer man kan ha det på.
Så litt inn på hva FIDA skal gjøre innenfor det her.
FHI gjør jo veldig mye bredt.
Mens FIDA har visst stått for FHI sin integrerte dataanalysetjeneste.
Så målet for den er det å ha en sikker tilgang til de analysetinga som man trenger.
Så man skal gjøre store, avanserte analyser, og på sensitive data.
Da kan man ikke bruke hva som helst av type løsninger.
Det er mye krav til at du må gjøre ... Du må vite hvem som har sett på hvilke data, og hvorfor, og hvilket mandat de har til å kunne se på den.
Og de må som regel være i hjemmel.
Man skal også skape en enkel hverdag for de som driver med forskning, og gjøre komplekse analyser, eller da ... De som skal lage statistikk ut mot ... ... mot helsepersonell og andre eksperter.
Så lager man altså løsninger for å bygge kompetanse, og ...
Det å kunne utvide krisesituasjoner.
For eksempel under korona skalerte man opp hele FHI som organisasjon, og gjorde ... Det å kunne klare å håndtere det å onboarde veldig mange team ... Det er viktig å ha det på en bra måte og ha gjort incert på forhånd, da.
Hovedsakelig er det veldig forenkla at det vi skal gjøre, det er ... Vi skal hente data fra kilder.
Vi har masse kilder, masse sensitive data.
Vi skal ta den dataen og få den ut til et sted vi kan gjøre analyser på den.
Og så skal vi få den ut til noen som kan gjøre noe fornuftig med resultater.
Det kan være f.eks.
kommuneoverleger eller smittesporere eller den typen ting.
Eksempel på full flyt kan være at vi har register på vaksiner og folk som har fått ... Positive resultater på tester og den type ting.
Eller at du har andre smittbare sykdommer som man har masse data på, i sikker sone, som er helt umulig å komme til.
Så skal vi klare å få henta det ut til TSD, kjøre analyse på det.
Og så skal vi kunne gi det til kommuneoverleger og visualisere det fordi ...
Sånn at de da kan vite hvilken type smitte det er på hvilke steder, hvor vi må gjøre tiltak ... For eksempel hvis det er på et sykehjem eller den type ting.
Sånn at man kan raskt komme ut og gjøre tiltak.
Teoretisk sett, hvis det hadde vært hvilken som helst type data, så hadde det vært veldig fristende å bruke Public Cloud.
Men siden vi har sensitive data, så er det ... Og det å ... Den typen sånn bruk vi har ... Er det veldig viktig at det er noen som vi kan logge og ha ordentlig audit-logg på?
Som betyr litt som det å vite hvem som har vært der, være helt sikker på identiteten.
TSD har jo igjen veldig bra sånn at man har innlogging med bank-ID.
Du vet faktisk hvem folk er.
Og man har veldig mye logging og kontroll på alt.
Du har ikke Internett på den vanlige maskina, som en vanlig person er.
Som også hjelper veldig.
Den er godkjent infrastruktur, og man kan da ha ... Den er allerede kjent for å bruke ... Du kan bruke ... Bli mye brukt på helsedata.
Og ...
Vi har også sett veldig mye potensial.
Når vi har jobba sammen med TSD, så ser vi at vi klarer å lage bedre løsninger sammen enn det vi klarer å gjøre med en vanlig skyleverandør eller infrastrukturleverandør.
For vi får ikke bare jern av noen, men vi får også noen sparringspartnere som vi kan sitte og få hjelp til å lage de optimale løsningene på hvordan syns dere vi burde gjøre det her.
Det har vært utrolig bra for FHI.
Det dere ikke nødvendigvis får ut av boksen med TSD, er infrastruktur som kode.
Det å ha felles data på tvers av prosjekter og sånt.
Det er ting som vi da bygger custom selv inn i TSD.
I samarbeid med TSD, da.
Og ... Så man kan ha ...
Man skal ha analyseprosjekter.
Sånn at man da har ett prosjekt per team.
Men vi har lyst til å bare laste opp data én gang.
Og siden vi skal ha data på tvers, som det ikke er skalert opp til, så er vi avhengig av å ha ett prosjekt som vi bygger all Audit-logg til innenfor det.
I tillegg er det da ... Standardisering på et typen ETL-verktøy er mer at man må skripte ting enn det man har på en vanlig public cloud, hvis man er vant til det.
Ja.
Extract Transform Load er ETL.
Hvis du skal gjøre store transformasjoner eller flytting av data, så må du ha noen script eller noen type teknologi som klarer å gjøre det for deg.
Eksempel er at vi har én av datakildene som vi sitter med nå, er jo 1,5 milliarder rader i bare det datasettet som vi skal analysere.
Så det begynner å bli en del data, og det å ...
Å crunche det på en effektiv måte og så gjerne uten at noen utviklere trenger å gjøre det, er det viktigste, som vi standardiserer så godt vi kan.
Kravet vi har til løsninger, er at man skal ha daglig og sikker og automatisert input og output fra dataen i TestD.
Det er noe som virker til å være et litt annet bruksmønster enn en del andre.
Som det ble sagt, at til sider så var det vanskelig å få data inn og ut, mens vi skal prøve å automatisere det, sånn at man får mange ganger daglig, fra hver kilde, inn og ut data.
Så du får deltalaster og den type ting.
Vi har krav til å ha fingranulert logging og kontroll på hvem som har gjort hva.
Så mye som mulig selvbetjening for analytikerne.
Sånn at de klarer å gjøre jobben sin uten å måtte kontakte oss så mye.
Og det å ha containerhåndtering, så man kan skalere ting ut i bredden.
Når man gjør veldig store analyser, så er det ikke nok med én maskin.
Man må skalere det ut så bra som mulig for å få det kjøretida.
Og da er det å kunne skalere ut på f.eks.
docker eller den type ting.
Å kunne schedulere det, så du slipper.
Under korona hadde man ikke muligheten til å ...
Si at en ting skulle skje så og så ofte.
Da sto forskere opp klokka tre på natta for å trykke på knappen og legge seg igjen.
Det er veldig upraktisk.
Så det å ha schedulering er også viktig.
Det å ha logging og skalering også.
Og som resultat av det her, så har vi utvikla, sammen med TSD, denne arkitekturen her.
Der man begynner å dele den litt opp, så er det her dataflyten.
Der har man ... Ned til venstre her så har man da datakildene våre.
Der vi får alle dataene våre innenfor sikker sone og sånt.
Så det her er litt teknisk, men det kommer spørsmål.
Så har vi Script for å få data inn.
Der har TSD en ferdig API-er som man kan bruke ... Som man ... Der vi får alt sammen inn, med at de har sikra inndeling og sånne ting.
Så får man det til et importområde.
Fra det importområdet passer man på at det bare er enkeltpersoner som har tilgang til det, som har veldig god kontroll.
Og all den dataen som er ...
På vei inn er ... Hele veien inn, når det er under transport i det hele tatt, så er både alle dataene kliptert, og den er signert.
Så vi er sikre på at data ikke kommer på avveie.
Når vi endelig har kommet oss forbi importområdet, så dekrypterer vi dataene og legger det inn i en stor raw database.
Den raw-databasen kan alle forskerne som har tilgang til de dataene ... Så man begynner å gjøre tilgangskontroll på tabellnivå og kolonner.
Så du kan da få tilgang til akkurat det du har krav på.
Så kan forskerne begynne å gjøre exploratory work, som de kan leke seg litt rundt.
Med å bruke Art Studio, som er satt opp til å kunne drive og ...
Bare koder litt mot de datakildene.
Så kan man automatisere de og schedulere de ut i bredde, som automatisk jobber, og kjøre core review på de.
Så vil vi da få de her ut som resultater i en ny Postgestad-base, som da vil automatisk bli slusa ut så så ofte.
Da kjører vi også kryptering og signering på all data som transporterer seg der.
Så kjører vi det ut til et publiseringslag, som er på en annen plattform.
Der f.eks.
kommuneoverleger eller den typen eksperter kan logge inn og se resultater av analyser.
Man kan også se resultatene selv som forsker eller statistiker inne i TSD.
På den andre siden har man infrastrukturen for å klare å få Hodman images inn.
Der vi har fått at den automatisk replikkerer alle imagene fra et registry på utsiden hver natt.
Sånn at man kan bygge store konteinere og gjøre en del utvikling på utsida der man har internet.
Vi har også fått tatt opp gitter-epo på innsiden.
Sånn at man kan ha god kontroll på koden.
Og det å ha en task schedule, task schedule roller, som da man kan bruke til å få ting til å skje automatisk og skalere i bredden.
Og IAM for det å bruke ...
Access management, altså ... Kunne bruke den samme innlogginga som du har i TSD, til å også bruke det på nettsider som vi har innenfor TSD, som vi bygger selv.
På den samme måten har du ett passord overalt, så du kan ha single sign-on på tvers av den typen.
For oss er det da det å protsette hele sløyfa.
Vi er fortsatt i litt pilotfase nå.
Så vi har de siste ROS-analysene, og sånt.
Ting må bare spikres, så vi kan få ting utbrudd.
Vi skal også drive med kontinuerlig forbedring av hele automatiseringsløpet.
Og den selvstyringen, selvutendringen, som ... ... som vi trenger der for å sette opp nye team og omboarde folk fort.
Og vi skal legge på flere kilder.
I dag så har vi bare ett.
Én kilde.
Som er inne enn så lenge.
Som er et stort datasett, men vi har lyst på ganske mange.
Og vi trenger flere brukere.
I dag har vi én ekspertperson som vi begynner med.
Som vi skal teste ut hva han har som krav.
Og så jobber vi oss inn flere og flere underveis.
Vi har også lyst til å teste HPC, som ble presentert tidligere.
For å gjøre storanalyser.
Det er han forskeren som allerede har begynt.
Han hadde lyst til å ha ca.
100 giga minne på én maskin for å kjøre analysene sine, og det er mye.
Det går ikke på en vanlig laptop.
Og den siste er å kjøre riped MQ, eller den meldingskøen, som er en av de nyere featurene i TSD, tror jeg jeg har forstått, som de klarer å få meldinger ut om at noe har skjedd, sånn at du vet at f.eks.
jobben din er ferdig å kjøre, eller at det har kommet noen nye overvåkingsresultater som du burde gå inn og sjekke.
Eller at systemet er nede, så du kan få denne typen konsultasjoner.
Det var det.
Spørsmål?
Jeg bruker denne her òg, jeg.
OK, ja, du kan begynne.
Du nevnte containere og container-images.
Kanskje du kan forklare litt mer hva det er, de som ikke er vant til det, og hvorfor det er viktig for dere å kunne bruke det, og hva slags problemer det løser for dere.
Konteinere er jo den enkleste forklaringen.
Du tar en hel VM, en hel virtuell maskin, og så skribler den inn til én prosess.
Og så kan du ta den prosessen og paralysere den mange ganger.
Brukes veldig mye til det å kunne ...
I microservice-tankegang, der du har mange spesialiserte microservices, så har du mange lettvektprosesser som alle sammen har akkurat minimum av hva de trenger for å kunne kjøre.
Og det er veldig viktig for oss, for å da kunne spinne opp ... Vi har veldig masse ferdigskrevne biblioteker for å gjøre analyser som vi har lyst til å ha bakt inn i én prosess.
Som er tilgjengelig for forskerne.
Mens de ... Vi har ikke lyst til at de skal påvirke hverandre på noe vis.
Så vi har lyst til å spinne opp mange forskjellige sånne paralleller hver for seg.
Og da inni der ... Så den eneste forskjellen er det ene skriptet som forskeren har skrevet, som bruker de forskjellige pakkene, da.
Så dere på en måte har en ...
Utviklermiljø utenfor, som dere replikkerer innenfor?
Yes.
Da bygger vi sånne konteinere på utsida, sånne images, som man er blueprinten på hvordan et utviklingsmiljø kan se ut.
Og så tar man det og kan spinne opp det i haugevis og få det orkestrert.
Så det er ...
Historisk, etter hva jeg har forstått, så var det veldig bra i det å kunne begynne med VM-er.
Da man kunne sette opp lettvekte datamaskiner.
Og virtuelle maskiner som, når du tar det videre til konteinerisering, som er enda mer lettvekt, og kan lett spinne opp det på utrolig kort tid, og da gjøre veldig mye bra sånn ...
Automatisk rullering når ting krasjer, eller at du kan ha høy oppetid.
Andre spørsmål?
Tusen takk for veldig fint foredrag her oppe.
Og utrolig stilig at man kan bruke TSD på den måten.
Dette er jo en del av FHIs samfunnsoppdrag.
Så er hypotesen at dette skal bli produksjon.
Eller er vi på test?
Det er ... Vi er i siste fasen med å få godkjent alt av ROS-analyser og den type ting.
Så lenge det blir godkjent, så går det i produksjon nå rett over sommeren.
Da er det ...
Vi har lyst til å gjøre enklere analyser i første omgang, mens vi har lyst til å gjøre mer og mer avanserte analyser.
FHI gjør jo mye annet analysearbeid, også i TSD, allerede, men forskjellen her, i det prosjektet her, er at man skal automatisk importere og eksportere data fra sikre kilder på en full, automatisk path, som er noe man sjelden gjør.
Veldig bra, lykke til.
Takk.
Folk ute i kommunene samler masse data.
Og kanskje det er mange hundre kommuner som leverer data hele tida inn til dette TST-prosjektet.
De leverer da til registrene, som er de der man har den strukturerte dataen.
Så der har man ekstra massesjonell som passer på at all data har høy kvalitet.
En milliard linjer, var det det?
1,5 milliarder på den ene datakilden.
Så nei, det er mye data.
Og så kommer det inn til TSD, og der skal en kjøre analysen for å se om det er noen sykdommer som ser ut til å reagere på samfunnet på en litt sånn pandemisk måte, ish, kanskje?
Det er jo mye analyser man skal gjøre for å finne ut da ... For eksempel R-tallet var jo en av analysene man gjorde.
R-tallet har vi hatt om før på denne konferansen.
Så den typen analyser gjør man.
Man gjør ...
Det enkleste er å lage statistikk.
Finne ut hvor det er mye smitte.
Og det å kunne fordele det og se trender og den type ting.
Hva er normalstandarden?
Hvordan ser en vanlig influensasesong ut?
Hvordan er outlierne i forhold til det her?
Når skal du advare om at noe gærent skjer?
Og så går dataene ut igjen automatisk.
Sånn at kommunene selv kan se på tendenser i sin kommune mot andre kommuner o.l.
Det er ganske heftig.
Veldig spennende.
Det er gøy også fordi Folkehelse har tidligere ung vi har snakket med her før.
Her kommer det et spørsmål til.
Det er bare et spørsmål om dataflyten igjen.
Du sier at det blir levert data inn til registrene.
Men er registrene innenfor TSD, eller er de utenfor TSD, og så blir dataene slusa inn i TSD utenfor?
Så det blir splusa inn i TSD etterpå, så det er en del av automatiseringa?
Yes, korrekt.
Er det vel sånn at en da inni TSD gjerne gjør en avidentifisering eller en rensing av persondata, sånn at en kan sende ut de rapportene nå begynner det å renne på?
I tillegg har vi lyst til å levere data til både kommuneoverleger, og vi leverer ganske mye data til publikum.
Det er en ting som de kaller prikking, da du anonymiserer data.
Det er også ganske mye arbeid for å ...
Jeg kom også fra FHI.
Under pandemien var det jeg som har jobbet mye med andre tiltak.
Vi samler inn masse informasjon om tiltak fra forskjellige kommuner.
Og da har vi møtt veldig store problemer med tekstanalyse.
Så i det siste skal jeg begynne å jobbe med NTSD.
Så vi prøver å samle inn tiltak, og alle spør hvem som skal lage et produkt av det.
Så dette er et fantastisk system, bortsett fra at den er doc.
Og Pottmann, det er veldig, veldig vanskelig fordi kunstintelligens kommer inn i bindet.
Vi kan ikke analysere noe effektivt uten å ha en god infrastruktur for kunststillingen.
Og hvorfor har dere protester som man har, veldig gode, med dere og Pottmann, som gjør det litt lettere?
Og folk som kunne kombinere eller innhente det og samkjøre det.
Jeg tror at du kan ha en stor datamaskin, du kan ha mye kraft, men uten å ha den komponenten som er lett å installere, lett å kjøre, det er en vekst, tror jeg.
Jeg er enig i det.
Det er mye det vi jobber med, å prøve å standardisere det som miljø for folk innenfor FHI, sånn at de kan gjenbruke så mye som mulig som skal være lett å bruke.
F.eks.
sånn som vi gjør det med RStudio.
Så vil du kunne gjøre ting der og sjekke det inn.
Så vil det automatisk bli plukka opp og skrittert uten at du trenger å bry deg om containere i det hele tatt.
Håper vi kan komme noe mer senere om hvordan vi tilbyr software fremover.
Nå har vi brukt opp din tid.
Tusen takk.