Rekordmange ambulanseenheter var i aksjon den 22. juli. Det medførte en overbelastning på delsystemer i AMK-sentralen på Ullevål. Dermed måtte mye av kommunikasjonen gå over sambandet.

Artikkel i Ambulanseforum nr. 4 2011

Ønsker du å abonnere? Klikk her!

I vanlig daglig drift regnes disse systemene som driftssikre, og de brukes av alle AMK-sentraler i landet.

Nå fikk man verken sendt oppdrag ut til enhetene eller kartmarkeringer, ambulansene fikk ikke mottatt statusmeldinger og AMK mistet posisjonene til enhetene. Tetra taklet trafikken, mobiltelefoni gikk tregt.

- Ugreit

- Det er ugreit at et system som brukes i hele landet er av en kvalitet som ikke tåler hendelser med et større antall pasienter, sier Rune Gehrken, som er avdelingssjef for AMK Oslo og Akershus.

Roy Smedhaugen fungerte som operativ leder på samlingsplassen på Youngstorget under innsatsen i regjeringskvartalet. Han erfarte dette under innsatsen i sentrum:

- Under aksjonen i Oslo slet AMK Oslo og Akershus med at en del av støtteverktøyet til AMK falt sammen, dette medførte at vi ikke kunne følge enhetene i kartverket og heller ikke fikk registrert tidsstatuser. Så det er en del personer som har gjort en formidabel jobb med etterregistreringer, og det ble hektiske dager også etter den 22/7.

Locus, Nirvaco, Telenor og flere andre underleverandører har fått en del etterarbeid i kjølvannet av innsatsene. Det samme har Sykehuspartner når det gjelder etterregistrering.

- Ja, det var en del problemer med å få meldinger til og fra ambulansene, bekrefter Kjellrun Borgmo, som er produktsjef for AMIS i Nirvaco AS. – Det var visstnok i TransMed meldingene stoppet opp, men det er en veldig tett integrasjon med AMIS,  slik at vi også måtte bidra med ressurser for å avhjelpe situasjonen.

Programfeil eller kompleks feil?

Nirvaco fikk beskjed om problemene ved midnatt. Locus var involvert fra halvsekstiden, et par timer etter at innsatsen i regjeringskvartalet var startet.

- Locus hadde beredskap tilgjengelig umiddelbart når feilen ble meldt fra Ullevål og bistod Ullevål i feilsøking og utbedring kontinuerlig gjennom det første døgnet, sier Magne Glittum, teknologidirektør i Locus.

Locus er klare på at selv om det kan oppfattes som om TransMed var hovedproblemet, var det ikke nødvendigvis der det feilet i første omgang.

- Etter vår oppfatning var problemene  på Ullevål mer sammensatt enn man i utgangspunktet kan få inntrykk av. Det er derfor viktig i etterkant å analysere og forbedre alle delsystemer etter denne hendelsen. Dette arbeidet pågår og vi har aktiviteter sammen med kunden og de andre leverandørene for i fremtiden å forbedre både systemer og rutiner i alle deler av kjeden, sier Glittum.

Kort fortalt mener Locus at alle disse delsystemene utgjør et komplekst system som gjør at problemer i et system påvirker de andre.

- I store hendelser får man andre effekter som man ikke har laget eller har tenkt på. Er det problemer et sted, så blir det som en flodbølge som slår inn flere steder samtidig, sier Glittum.

- Den store oppdragsmengden på to enkelthendelser, henholdsvis i Oslo og Utøya, utgjorde en belastning som flåtestyringssystemet Transmed ikke taklet ved OUS. Den store meldingsmengden kom fra journalsystemet AMIS via integrasjon med TransMed. Det store antallet oppdrag og tiltak registrert på hendelsene førte til ekstraordinært antall meldinger gjennom integrasjonen til ambulansene. Informasjon om alle tiltakene (ambulanser, politi, brann osv) sendes til alle bilene. Antallet meldinger øker derfor som en eksponentiell kurve. Som følge av dette ble det større og større forsinkelse i elektronisk kommunikasjon til bilene utover ettermiddagen og kvelden den 22. juli, sier Cecilie Melland, kommunikassjonssjef i Sykehuspartner.

GSM-tilknytning en årsak?

- Man har tidligere ikke sett slike tregheter verken i drift eller ved test før den 22/7, sier hun. (Red.anm. Ambulanseforum kjenner til at det er rapportert inn tidligere at AMIS er ustabil ved større hendelser.)

Glittum mener at disse systemene er tilknyttet GSM-nettet og ikke Nødnett kan ha vært en av årsakene.

- Dette kan være en av hovedårsakene til problemene som ga følgefeil andre steder i systemene. Det er derfor riktig og viktig at man nå har besluttet og bygge ut et nytt Nødnett i hele Norge. Det er også viktig å nevne at systemet som dekket Utøya – AMK i Drammen ikke hadde disse problemene, sier Glittum.

Men AMK i Oslo og Akershus som hadde mange ressurser på Utøya opplevde fremdeles problemer.

- Belastningstester utført av Locus har i ettertid vist at en loggefunksjon i Transmed utgjør en flaskehals ved så store belastninger. Loggingen lagrer alle meldinger som sendes i systemet. Denne loggefunksjonen var skrudd på i Oslo, og skrudd av i Buskerud. Dette kan forklare forskjellene mellom sentralene, sier Melland i Sykehuspartner.

Gehrken tror heller ikke GSM-nettet var årsaken til problemene:

- Jeg tror ikke dette har noe som helst med GSM-nettet, det var det fysiske programmet som har noen mangler, mener Gehrken. – Systemet fikk ikke til å dumpe gammel informasjon og genererte så mye data at det ikke greide å håndtere det.

Dermed fikk AMK ikke bare problemer med de eksisterende oppdragene, men fikk også problemer med å skrive inn nye oppdrag.

- Det som skjedde var at det visstnok ble så mange meldinger at det hopet seg opp i systemet. I og med at det var bortimot 50 ressurser på hendelsen, og alle skulle motta hver eneste oppdatering som skjedde, sier Borgmo i Nirvaco.

Massivt etterarbeid

Borgmo poengterer  også at problemene trolig ikke fikk noen konsekvenser for innsatsen.

- Ambulansene var tidlig framme, og så vidt vi kjenner til forårsaket ikke disse problemene noen forsinkelser.

Så hva har man gjort i etterkant for at noe lignende ikke skal skje igjen?

- AMIS overfører i dag hver minste endring til TransMed i sanntid, siden kapasitet ikke har vært noen begrensning. Men vi ser nå at med ekstremt mange ressurser på en hendelse bør en samle sammen informasjonen, bufre som vi sier, og sende samlede oppdateringer i stedet for hver gang det er en endring som i dag. Dette har vi allerede innført i AMIS, noe som vil være like bra i normalsituasjoner og samtidig langt mer robust i ekstremsituasjoner. Man må huske på at dette var en hendelse man aldri tidligere har opplevd maken til i Norge. Men det er klart at man skal lære av dette, sier Borgmo.

Locus sier de har gått gjennom TransMed, og at de er i dialog med de andre leverandørene.

- Vi har rettet opp, gjort noe med robustheten,  og gjort en rekke tiltak som ikke bare går på våre systemer, og hatt en dialog med Sykehuspartner rundt hvilke tiltak som skal bli iverksatt, sier Glittum.

Han mener at dette er scenarioer selv militæret ikke har kunnet forestille seg.

- Katastrofens omfang viser hvor viktig det er å øve på alle deler av slike katastrofer. Det gjelder prosedyrer og rutiner i tillegg til hvordan man benytter de tekniske hjelpemidlene som systemene på AMK. Sånn sett vil disse forferdelig hendelsene gjøre oss i stand til å forberede oss også teknisk på slike hendelser og løse problemer i forkant så godt det lar seg gjøre, avslutter Glittum.

Sykehuspartner er glade for at det til nå ikke er avdekket at problemene har utgjort noen fare for pasientbehandlingen under aksjonen.

- Begge leverandører har stilt opp med betydelige ressurser og håndtert problemene på en god måte, sier Melland avslutningsvis.

Oppsummerer man ser det likevel ut til at Locus skylder på komplekse systemer og GSM-nettet, mens alle de andre peker på integrasjonen mellom TransMed og AMIS som hovedårsaken til teknologisvikten den 22. juli.