Time series forecasting has several applications and can provide valuable information. Recently I worked on a project forecasting ambulance demand for the emergency medical dispatch in Oslo. Using machine learning, statistical methods and a combination of the two, we explored how to forecast the demand as accurately as possible. The aim of this article is to give a general introduction to the process we used to create these models, which I believe can be relevant for many other applications as well.

Forecasting ambulance demand is critical for emergency medical services to allocate their resources as efficiently as possible. One year ago, working with Oslo University Hospital and their emergency medical dispatch, I worked on a project to create a forecasting model for the ambulance demand in and around Oslo.  Our goal was to give the ambulance dispatchers a clearer understanding of when and where there likely will be demand for ambulances, to aid their decision making in placing and dispatching ambulances.

Based on previous research, we created one model for predicting the number of dispatches at a given time slot which we will refer to as the volume. We create a separate model for predicting the spatial distribution or in other words the geographic location of the incidents demanding an ambulance are. The overall idea, is that it is better to have two models solve two separate and simpler problems, in this case volume and distribution, rather than one model on one difficult problem which would be the combination of the two. This article focuses on the volume forecasting model.

 In order to forecast the volume, we group the gathered data into a time series. A time series is sequence of data points indexed with a time of equal interval lengths. For this problem, we use hourly intervals, and the corresponding data point refers to the number of ambulance dispatches for that given hour. Time series forecasting, is the art of predicting the value, in this case the number of ambulance dispatches required, for future time periods.

Our data set consisted of several data points for all events received by the medical dispatch unit over a three year period. These events were grouped into hourly intervals, resulting in a time series ready for predictions! 

Initial data analysis

The images below shows som early data visualisation we generated to get a better understanding of the time series we worked on.





Examining the time series above, we can see that during the day there are more events than during the evening. Additionally, there seems to be slightly more incidents during friday and saturday evening while having lower peaks during the day, compared to the other days of the week. From this, we can deduct that the ambulance demand follows some patterns based on the time of day, as well as day of the week.  Interesting! What else can we learn just by visually examining our data? Well, let us put the annual demand into a table, to see if we can see another pattern.



Inspecting the table, we can see that every year the ambulance demand increases. 



Creating a forecasting model

Ahead of our project, there was already done some published research on using neural networks and machine learning to forecast the same problem, using the same data set. Our goal, was to create models that could provide more accurate forecasts than previous models. Like previous work, we wanted to use neural networks, since they have proven to be a state of the art tool for time series forecasting. So, what can we do to improve provide more accurate forecasts than previous machine learning models?

Based on initial data analysis, we knew that the time series followed two patterns. One is the weekly pattern, where the average volume is based on the day of the week, as well as the time of day. The other is the yearly steady increase in demand. What if we could extract this information from our time series, resulting in a less complex time series for our machine learning model to forecast.

Well, this is what inspired our model architecture. Using tools from statistical decomposition, we could simplify the time series. We experimented using both singular spectrum analysis and seasonal trend decomposition using LOESS, for this purpose. Using these tools we could extract the two patterns mentioned above, namely the seasonality and trend in the time series. Using regression, we could also predict what these values would be in future events. We trained a neural network on what was left after decomposition, and used the trained network to predict future values. The final predictions, consisted of the sum of the predicted values of these models. 

Results and  reflections

Our final models, combining statistical decomposition and neural networks, outperformed previous models using only neural networks. This confirmed our suspicion, that simplifying the time series before applying machine learning, resulted in more precise predictions. 

So, how can these resulted be translated to other applications? Looking at the bigger picture, this illustrates the benefits of analysing a problem before trying to solve it. By breaking it down to smaller, simpler problems and using the right tools to solve each of these problems, we could make more precise forecasts. This also applies when using machine learning, even though one would believe they could learn this problem area without simplifying the time series. 

If you are interested in learning more details about the details of these models or the project, I co-wrote a published research article, that is linked to below, that goes into the technical details of our models. 







Saving lives with data: Oslo's journey in ambulance demand forecasting

Mange virksomheter sitter på store mengder data som kunne blitt brukt til å ta bedre beslutninger hvis den hadde vært tilgjengelig for potensielle brukere. Utilgjengeligheten opprettholdes grunnet en ond sirkel der ingen bruker dataen fordi den ikke er tilgjengelig (nok), samtidig som økt tilgjengelighet ikke prioriteres fordi ingen bruker dataen, og verdien blir dermed ikke synlig. Nøkkelen til å bryte denne sirkelen ligger i å synliggjøre verdien av dataen.

Nøkkelen ligger altså i å synliggjøre verdien av dataen, men det er lettere sagt enn gjort å synliggjøre verdien av å ha noe du ikke har. La oss tenke litt på hvordan det kan gjøres.

Økt datatilgjengelighet kan gi verdi på to måter. Den første handler om at data kommer inn som beslutningsgrunnlag og fører til bedre beslutninger. Den andre handler om at økt tilgjengelighet reduserer kostnaden ved å hente inn dataen som beslutningsgrunnlag. Uavhengig av hvilken type verdi det er snakk om, er det lurt å kvantifisere den. Å investere i økt datatilgjengelighet er en kostbar affære, og det er derfor viktig å synliggjøre verdien i kroner og øre for at det skal prioriteres. Hvis du har en hypotese om at økt tilgjengelighet vil være verdifullt, men vil kreve store investeringer, så finnes det måter å synliggjøre verdien med relativt lav risiko.

Et proof of concept kan synliggjøre verdien av å få inn ny data som beslutningsgrunnlag

Hvis tilgjengeligheten har vært så dårlig at det ikke har vært mulig å ta i bruk dataen, så vil verdien bestå i at dataen blir så tilgjengelig at den kan brukes som beslutningsgrunnlag, enten direkte eller som input for å gjøre mer sofistikerte analyser. Her er det nyttig med et eksempel.

Se for deg at du er ansatt som analytiker i en produksjonsbedrift med en gjennomsnittlig nedetid på 500 timer i året grunnet uforutsett vedlikehold av maskiner. Hver time koster 100 000 kroner i tapt produksjon. Du har en hypotese om at sensor-loggene fra maskinene kunne blitt brukt til å predikere tilstanden til maskinene slik at vedlikeholdet kunne blitt planlagt bedre. Infrastrukturen som kreves for å sensor-dataen inn i sanntid er kostbar, og ledelsen vil ikke prioritere dette.

En måte å synliggjøre verdien av denne dataen på er å lage et proof of concept (POC) basert på manuell uthenting av en andel historisk data. Basert på denne dataen estimerer du at nedetiden kan reduseres med 5% dersom vi gjør den samme analysen i full skala i sanntid. Verdien av å få denne dataen tilgjengelig er altså 2,5 millioner kroner årlig.

Å øke tilgjengeligheten på allerede eksisterende data har flere typer verdier

I eksempelet over kan vi si at data allerede er tilgjengelig i det man har laget et POC. Likevel kan det være tidkrevende å hente ut data og gjøre analyser manuelt. Hvis vi fortsetter med det samme eksempelet og antar at det krever to dagsverk á 5 000 kr hver uke å gjøre uthenting og analyse i full skala, så tilsvarer det ca. en halv million kroner årlig. Dette er en vesentlig kostnad som kan reduseres ved å investere i å tilgjengeliggjøre data på en slik måte at prosessen kan automatiseres. Når man allerede har en benchmark-kostnad på en halv million kroner årlig, er det ganske rett fram å sammenligne investeringskostnaden knyttet til automatisering med gevinsten i tid spart på den manuelle prosessen.

Videre kan det hende at ledetiden knyttet til den manuelle prosessen gjør at man ikke klarer å ta ut hele potensialet på 5% reduksjon i nedetid. I så fall vil ytterligere redusert nedetid også være en verdi av å investere i infrastruktur for automatisert analyse.

Sett i gang

Så, har du en hypotese om at din virksomhet kunne hatt nytte av data som ikke er tilgjengelig per i dag? Det aller viktigste er å synliggjøre verdien av å få den tilgjengeliggjort. Hvis det ikke er mulig å få data inn automatisk, er det kanskje mulig å få tilsendt en avgrenset datadump fra det aktuelle systemet. Dette kan være nok til å få til et POC som gjør at ledelsen kan se verdien og prioritere grep for å gjøre data tilgjengelig på en bedre måte.

Hvorfor bør du synliggjøre verdien av data du ikke har?

Det er 2038. Ingen utviklere finnes lenger, kunstig intelligens har fått litt regulering og Carl I Hagen sitter fortsatt på Stortinget. Du føler deg litt småsyk, og drar til din lokale AI-fastlege™. En halvdystopisk robot ruller over gulvet og tar noen blodprøver. Du taster inn de andre symptomene dine på en interaktiv skjerm og venter spent. Snart, med en nesten uhyggelig effektivitet, vises diagnosen tydelig på skjermen foran deg. Stoler du på den?

Se for deg at du er i situasjonen beskrevet ovenfor. Stoler du mest på diagnosen fra din AI-fastlege™ der du får en forklaring på hvorfor du fikk den diagnosen, eller fra en der du ikke får noe forklaring? 



Uten å tilegne andre mennesker meninger, vil jeg påstå at brorparten velger førstnevnte. Derfor burde kanskje din AI-fastlege™ bruke gode, gamle lineære modeller.



Grøss og gru tenker du kanskje, og mimrer kanskje litt tilbake til statistikk-faget fra studietiden. Husker noen hypotesetesting, konfidensintervall og momentgenererende funksjon? Hva er vitsen med å forholde seg til slike ting, når legen din kan bruke maskinlæringsmodeller som kunstige nevrale nettverk der vi gjerne får langt mer presise diagnoser?




Først og fremst, la oss definere hva jeg mener med maskinlæring i denne konteksten. Enkelt forklart: Vi presenterer en maskinlæringsmodell med en gitt input og det ønskede outputet. Deretter, når vi introduserer ny, ukjent input til modellen, forventer vi at den genererer et passende output basert på hva den tidligere ble lært opp til. For din AI-fastlege™, se for deg input som symptomer, og output som diagnose. Dette kalles supervised learning.


Så, hvorfor mener jeg at din AI-fastlege™ bør bruke lineære modeller istedenfor nevrale nettverk?



Forklarbarhet. 



Det er ekstremt viktig å forstå hvorfor en modell tar de valgene den gjør, av flere årsaker. Hvordan vil en endring i symptomene påvirke diagnosen, og hvorfor?





Når brukere og beslutningstakere forstår hvordan en modell fungerer og tar beslutninger, øker det tilliten til systemet. Dette er spesielt viktig i anvendelser der beslutninger tatt av en AI kan ha store konsekvenser, for eksempel innenfor:

Helse(referer tilbake til din AI-fastlege™)

Finans(Hvorfor ble lånerammen min så lav?)

Rettslige systemer(Hvis vi begår justismord, så er det greit å vite hvorfor)



Forklarbarhet er også viktig for etisk bruk av AI og maskinlæring.  Det hjelper til med å sikre at AI-systemer og maskinlæringsmodeller ikke forsterker bias eller diskriminerer, og at de opptrer i tråd med samfunnsmessige normer og verdier.



Hvorfor er lineære modeller mer forklarbare enn nevrale nettverk? 

Dette blir litt mer teknisk, men det handler i grunn om modellstruktur og kompleksitet.

Lineære modeller, som lineær regresjon, har en direkte og lettforståelig relasjon mellom input og output. Hver forklaringsvariabel(tenk et symptom, f.eks feber) har en koeffisient som tydelig viser dens innvirkning på resultatet. Dette gjør det enkelt å se hvordan endringer i for eksempel feber påvirker diagnosen.

De grunnleggende prinsippene bak lineære modeller er relativt enkle å forstå og tolke, selv for de med begrenset statistisk kunnskap. Dette gjør det lettere å forklare og rettferdiggjøre modellens beslutninger til sluttbrukere.

I motsetning til nevrale nettverk, som gjerne har mange skjulte lag der inputdata transformeres på måter som kan være vanskelig å tolke(hva betyr ReLU?), har lineære modeller en direkte vei fra input til output. Det er ingen "skjulte" behandlinger av dataene, modellen er transparent.

Selv om nevrale nettverk kan gi høyere prediktiv nøyaktighet, spesielt i komplekse eller ikke-lineære problemstillinger, kan deres "black box"-natur gjøre det vanskelig å tolke nøyaktig hvordan og hvorfor de kommer til en bestemt prediksjon. Hvorfor fikk jeg akkurat den diagnosen?

Lineære modeller kan i tillegg utvides til å bli generaliserte lineære modeller. Dette øker fleksibiliteten til en modell, noe som gjør den mer lik et nevralt nettverk, men bevarer de gode egenskapene med forklarbarhet.

Men nøyaktig hvordan?

Det kan være nyttig med et simpelt, konkret eksempel for å vise hvordan og hvorfor en enkel lineær modell er lett å forklare. Anta at din AI-fastlege™ har en modell for å predikere sannsynligheten for at en pasient har en bestemt sykdom, for eksempel halsbetennelse, basert på forskjellige symptomer. Et av symptomene vi ser på er feber. I denne modellen vil hver forklaringsvariabel, som feber, ha en tilhørende koeffisient som kvantifiserer dens innvirkning på diagnosen. 

Si at koeffisienten for feber i modellen er 9. Dette tallet indikerer hvor mye sannsynligheten for halsbetennelse øker for hver enhet økning i feber, hvis ingen andre forklaringsvariabler endrer seg. 

Anta at en pasient uten feber har en 20% sannsynlighet for å bli diagnostisert med halsbetennelse, ifølge modellen. Hvis denne pasienten deretter utvikler en feber som er 1 grad over gjennomsnittet, vil den økte sannsynligheten for sykdommen være 

20% + 1 × 9 =20% + 9 = 29%

Denne direkte og kvantifiserbare sammenhengen mellom symptomer og diagnoser i en slik lineær modell gjør den mer forklarbar og transparent sammenlignet med komplekse modeller som nevrale nettverk, hvor slik direkte tolkning ofte er umulig.  

Dog er fremtiden potensielt lys for de mer kompliserte maskinlæringsmodellene der ute i verden. Det har kommet metodikker som f.eks SHAP-verdier, som er utviklet for å gi innsikt i komplekse maskinlæringsmodeller sine beslutningsprosesser, noe jeg selv brukte i min masteroppgave. Selv om disse metodene har en del potensiale, er de fortsatt i en tidlig fase og anses derfor som umodne.



Så når vi er i 2038, og du får valget mellom en fastlege som enten er basert på lineær regresjon, eller på nevrale nettverk, velg med omhu ;) God jul!



Disclaimer: Jeg håper egentlig ikke at fastlegen din kommer til å diagnosistere deg basert på lineær regresjon, eksempelet er satt på spissen for å understreke et poeng.




Lineære modeller: Hvorfor din AI-fastlege™ ikke bør bruke nevrale nettverk

I november samlet vi flere av Bekks faggrupper for å snakke om krysningspunktet «Data og brukerinnsikt» – og for en kveld det ble! UX-designere, forretningsrådgivere og utviklere var samlet for å diskutere utfordringer og lære om hverandres perspektiv. 



Hvorfor samlet vi en tverrfaglig gjeng for å snakke om data? Vi ser et stort  forbedringspotensiale i hvordan vi samarbeider rundt datainnhenting og dataanalyse. Konsumenter av data bør vite mer om hvordan data samles, bearbeides og lagres. Datainginører og analytikere bør vite mer om hvordan denne dataen kommer til å bli brukt. Dette må vi som bransje bli flinkere til, slik at vi klarer å ta bedre beslutninger basert på data både i produktteamet og i hele organisasjonen. 

Vi hadde mange gode diskusjoner i løpet av kvelden, og så at hva som ble oppfattet som de viktigste utfordringene rundt temaet varierte avhengig av fagbakgrunn, rolle og erfaring. Diskusjonene gjennom kvelden ble noe todelt:

🚀 Behovet for data i produktteam: Vi som jobber med å kontinuerlig lansere og forbedre funksjonalitet trenger kontinuerlige målinger av produktet vårt for å ta bedre beslutninger. Hvem bruker løsningen? Har vi fått flere til å klikke på denne knappen etter vi endret noe?

🏢  Behovet for data på et strategisk nivå: Vi som setter strategiske prioriteringer trenger data som kan hjelpe oss å forstå prosesser i organisasjonen og sette prioriteringer. Vi trenger ikke like hyppige oppdateringer som et produktteam, men har ofte et større og mer komplekst datasett. Hva slags innsikt kan vi få av den dataen vi har? Hva er den beste måten å skaffe den innsikten?

__________

Fagkvelden ga oss tid til refleksjon rundt temaet og denne artikkelen oppsummerer noe av det vi var innom gjennom kvelden. Under har vi samlet noen inntrykk fra deltakere på fagkvelden:

Samarbeid mellom designer og utvikler for å hente ut innsikt fra data er gull!

Ida – designer i faggruppen Psykologi og adferd

Det var veldig spennende å høre mer om hva utviklere og forretningsutviklere tenker om data og brukerinnsikt. Vi snakket om at det gir stor verdi når utviklere og designere samarbeider om å hente ut innsikt fra dataen ved å diskutere hva tallene representerer fordi man gjerne ser etter litt ulike ting i tallene. Et slikt samarbeid i mitt team har ført til at vi måtte endre tallene vi inkluderte i datagrunnlaget for å få en riktigere representasjon av virkeligheten.

Det kan være overveldende med mye data og det er ikke alltid rett frem hvor man skal starte. Da har det vært godt å alliere meg med noen som kan det tekniske og vet hvordan målingene er satt opp. Vi sparrer sammen rundt hvordan vi finner tall som kan svare på det vi lurer på og hva vi skal sette opp av nye metrikker.

Vi snakket også om at det kan være nyttig med en skjerm på kontoret som viser et dashboard med viktige tall og målinger teamet er opptatt av å følge med på. Det kan føre til gode diskusjoner og gjør at man kan ta pulsen på tjenesten.



Hvordan kan vi jobbe smidig og transparent på tvers av fagområder i datasfæren? 

August – utvikler og dataingeniør i faggruppen Data Engineering

Gruppa jeg var i diskuterte hvordan vi unngår silo-jobbing i verdikjeden fra rådata til innsikt. Det var en del frustrasjon ute å gikk fra forretningsrådgivere og designere, fordi dataingeniørene brukte utrolig lang tid på det som i deres øyne var en enkel oppgave. Det var uklart for dem at det kan være høy kompleksitet i datariggen som gjør det å hente ut et, tilsynelatende, enkelt tall kan være ganske tidkrevende. Det virket som flere hadde erfaring med at det var dårlig kommunikasjon rundt temaet på tvers av fagdisipliner, og at vi bør jobbe med å få en større interesse for hverandres perspektiv.

Jeg føler at det ofte er en mangel på eierskap for prosessen som helhet blant alle roller. Det er lett for en dataingeniør å si seg ferdig med sine oppgaver og forpliktelser så fort datasettet er ferdigbehandlet, på samme måte som at en designer ikke starter sitt innsiktsarbeid før dataen er på plass. Programvareutvikling har beveget seg fra dedikerte frontend- og backend-roller til fullstack og bidrag inn mot innsiktsarbeidet. Dette burde datasfæren dra inspirasjon fra og legge opp til tettere samarbeid på større deler av verdikjeden. Får man til å jobbe smidig på tvers av siloene tror jeg frustrasjonen over hverandre minker og verdien som helhet styrkes. Feedback-loopen fra bruker blir kortere og man vil lettere kunne justere datakildene, transformasjonene og analysen basert på det faktiske behovet.



Hvilke data snakker vi egentlig om?

Jørgen – utvikler i faggruppen Smarte beslutninger

Vi snakket mye om måling av brukermetrikker i smidige team, hvordan gjøre dette på en god måte og hva slags kompetanse det forutsetter. Her må det skilles på behov som kan dekkes i teamet og behov som trenger en større rigg, kanskje i form av dedikerte team. Ellers blir det lett å tenke at datadrevet utvikling krever spesialkompetanse man ikke har – og realistisk sett ikke kommer til å få.

For å iterere på et produkt og velge retning basert på målbare data er det viktig med eierskap innad i teamet. Eierskap til hva som måles og hvorfor det måles, og som følges aktivt opp som del av det daglige arbeidet; gjerne i form av nøkkelresultater (OKR) på brukermetrikker (interaksjon/adopsjon) og domenemetrikker. Dette mener jeg at alle produktteam burde gjøre: Start enkelt og iterer på målingene ettersom behovene konkretiseres.

Ut over dette er det mye som kan gjøres med store datamengder, men det krever dybdekompetanse. Da blir det fort ikke gjennomførbart i fokuserte produktteam og må ikke forveksles med smidig iterasjon, men sees i en større sammenheng i organisasjonen avhengig av hva man ønsker å oppnå.


Ikke la utopien stå i veien for å gjøre det dere kan på teamnivå. Sett opp noen greier med strikk og binders og kom i gang!

Dykk inn i dataen i databasen og finn mer forståelse om brukerne!

Linn – designer i faggruppen UX-nerding

UX-designere (og resten av produktteamet) må åpne opp øynene, se hvilken gullgruve databasen er, og forstå hvilken innsikt den kan gi! Mitt inntrykk er at bransjen begynner å bli gode på å måle klikk på knapper, men at det fortsatt er et stort potensiale i å dykke inn i databasen sammen for å virkelig prøve å forstå brukerne bedre. Både å forstå bruken av produktet og forstå mer om hvem brukerne er. Slik at teamet kan ta bedre valg for produktet basert på god brukerinnsikt.

Det var interessant å høre om utviklere som jobber i data-team, som går dypt inn i å bygge opp datarigger, men som synes det er vanskelig å se hva den konkrete outcomen blir. Hvilke muligheter ligger det i å få en UX-designer på slike team? Hvordan kan en UX-designer bidra med å analysere og forstå organisasjonens behov? Og bidra med å gjøre innsikten mer tilgjengelig for flere ved å visualisere dataen?



Fagkvelden var kun starten på reisen

Kvelden ga rom for mange gode diskusjoner, oppklaringer og refleksjoner, men vi satt igjen med enda flere spørsmål enn svar. Vi skal bli mye bedre på samarbeid om data og analyse på tvers av forretning, design og utvikling. 

Denne kvelden viste noe av jobben som gjenstår for å forstå hverandres perspektiv og arbeidshverdag. For å realisere dette potensialet, må vi jobbe for et tettere samarbeid mellom de som samler og lagrer data, de som analyserer det, og de som trenger innsikten. Det kan både starte i det små i enkelte produktteam, og det kan skje gjennom større initiativ. Vi gleder oss til å fremover høre om team som bruker data mer i beslutninger og om hvordan de helt konkret gjør det i hverdagen!

Data and analytics

Saving lives with data: Oslo's journey in ambulance demand forecasting

Hvorfor bør du synliggjøre verdien av data du ikke har?

Lineære modeller: Hvorfor din AI-fastlege™ ikke bør bruke nevrale nettverk

Data og brukerinnsikt