IKT-hendelse 18.-19. juni 2011 Avdelingssjef Øyvind Waal, E-helse og IKT ow@owaal.no
Innhold Litt bakgrunns info Hva hendte? (IT-teknisk) Konsekvenser Håndtering underveis Hva er gjort i etterkant? Erfaringer? Veien videre
Kort om meg Erfaring med Drift/driftsutvikling OS/Nettverk Sikkerhet (CERT) Over 15 år erfaring fra USIT/UiO leverandør Teknisk og ledelse Nå kunde Leder E-helse og IKT på AHUS Jobbet litt under 2 år på sykehus IT-innsatsleder AHUS under hendelsen 18/6-11 Fra 1/8-12 løsningsarkitekt i Basefarm A/S
HSØ HELSE SØRØST (RHF) En av fire helseregioner i Norge Består av flere HF (Dekker Sør- og Østlandet) Hovedkontor på Hamar HSØ dekker ca 52% av landets befolkning + nasjonale oppgaver Fellesdrift IKT og HR av Sykehuspartner Y modell Sykehuspartner har kort driftstid i dagens organisering Ikke felles IKT plattform innen RHF et Underinvestering over tid innen IKT
Fakta AHUS Nedslagsfelt: 10% av Norges befolkning Norges største akuttsykehus Virksomhet innen de fleste medisinske disipliner Ansatte: ca 8500+ Lokasjoner: hoved lokasjon Nordbyhagen i Lørenskog, flere titalls andre større og mindre enheter. Innflyttet i nytt sykehus 2008 (høst) Budsjett omkring 7 milliarder 2012 10 år som universitetssykehus høst 2011 HP s Health Center of Excellence åpnet høst 2011 dekker EMEA
IT Fakta: Akershus universitetssykehus, Lørenskog (ca tall) 3 datarom 4900 IP-telefoner, hvorav 1800 trådløse 350 linjesvitsjede telefoner 4500 PC er hovedvekt stasjonære, men økende andel bærbare 850 skrivere 480 svitsjer 400 servere 400 applikasjoner/systemer Trådløst nettverk i hele bygningsmassen på Lørenskog 28 bygninger utenfor Ahus, sentralisert drift
IT fakta 18.-19.juni En serversvitsj (bladesenter) i det ene datarommet startet av ukjente årsaker å sende unormalt mange meldinger/pakker (loop) mot en av kjernesvitsjene (en av 4 stk) lørdag kveld ca 22:30. I stedet for å kutte forbindelsen mot serversvitsjen som genererte loop ble trafikken sendt ut på kjernenettet og videre ut i hele nettverket. Nettet ble da nær 100% mettet med trafikk og var for alle praktiske formål slått ut. Trafikken slo ut et betydelig antall andre svitsjer som måtte skrus på igjen for hånd. Dette inkluderte de fleste kantsvitsjene. Nedetid 14 timer Som det ofte er når noe går galt. Flere ting feilet samtidig
IT konsekvens for sykehusets systemer Hva sluttet å virke: Alle datasystemer som er avhengig av nett (nær 100%) All IP telefoni, inkludert meldinger mot bærbare håndsett (f. eks pasientsignal mot håndsett) Hva var uberørt: Linjesvitsjede telefoner virket (men ingen viste om det!) Sentralbord hadde bylinje Pasientsignaler mot tablåer MTU, bilde, lab systemer virket lokalt Lokalt nødnett for meldinger (Må ikke forveksles med nasjonalt nødnett)
Manuell nødrutine; Skriver ut på papir Noen kritiske IKT systemer og back-up Elektronisk pasientjournal Elektronisk medisinkurve Pas Overvåknings systemer Fungerer lokalt Manuell nødrutine Papirrekvisisjon, ringe ut svar Manuell nødrutine; Ta og se bilde på lab Laboratorie- Data system Nettverk Bilde diagnostikk Andre systemer IP-telefoni Akuttmed. alarmer Telefoni ASCOM p-søk Mobiltelefoner L Sv telefoner
Medisinsk nødrapport for alle inneliggende PC knyttet direkte til produksjonsserveren med egen skriver som står i det 3.dje datarommet. Dumper DIPS sin database jevnlig på lokal harddisk. Viktig medisinsk pasientinformasjon inkludert medikasjon var tilgjengelig på papir i sengeområdene etter senest 3,5 timer Løsningen øves med jevne mellomrom, noe som viste seg svært nyttig Litt avhengig av antall pasienter og informasjon registrert på hver pasient, men det er en ca 3500 siders rapport. AHUS er eneste sykehus med elektronisk nødrapport! AHUS er også eneste sykehus med elektronisk medikasjon
Alarmering ved IKT hendelsen 18.-19.6 Vaktsentralen, samt klinikken oppdaget at systemer var ute av drift Primært katastrofeteam ble varslet Katastrofekontoret ble etablert og primært katastrofeteam samles Sentrale funksjoner utover katastrofeteamet møtte uoppfordret for informasjon på katastrofekontoret Beredskapsnivå ble aldri satt og derfor selektiv innkalling ut fra behov
Håndtering av IKT hendelsen 18.-19.6 Pasienter omdirigert via AMK og Legevakt informert Akuttmedisinske alarmer ble reetablert (private mobiltelefoner + Ascom + AMK samband) Generell back-up for telefoni ble reetablert i sykehuset (mobil + nødnett) Nødjournaler skrevet ut og distribuert Livsviktige funksjoner i sykehuset fungerte i henhold til sykehusets manuelle nødrutiner Hendelsen håndtert tilfredsstillende meget hektisk mediakjør, rolig inne på sykehuset Ingen kjente avvikshendelser
Erfaringer og veien videre 1 (generelt) Hendelsene i 2011 har gitt økt fokus på beredskap på alle nivå Informasjon Talevarsling ut i sykehuset for å sikre alle informasjon Informasjonsmøter i sykehuset Kommunikasjon med media for å sikre korrekt informasjon Planverket Opplæring Linjeansvar og individuelt ansvar Oppdatert og tilgjengelig planverk i papir Interne hendelser utfordringsbilde Praktisk rettet planverk med sjekklister Forebyggende tiltak rundt systemer og avhengigheter Merkede telefoner og telefonlister for linjesvitsjede telefoner Talevarsling Ivareta sårbarheten i moderne sykehus Risiko- og sårbarhetsanalyse med forebyggende tiltak
Erfaringer og veien videre 2 (generelt) Opplæring og vedlikehold av kompetanse Opplæring for særfunksjoner katastrofesjef, -sekretær Alle ansatte (e-læring, powerpoint til intern opplæring) Ledelsesmessig fokus Nyansattprogram Systematisk bruk av årlige øvelser Varsling Enkelthendelser Fullskala Trene på interne katastrofer! Sykehuset godt trent på eksterne katastrofer, men ikke like godt på interne katastrofer
IT erfaringer og hva er gjort? 1 Backup løsninger må vedlikeholdes, rutiner gjøres kjent og inngå i øvelser. Om ikke så er det bedre å fjerne løsningene! Lages egen telefonliste for linjesvitsjede telefoner og de merkes bedre Sykehusets backup mobiltelefoner kuttes ut. Dekningen av jobb og privatmobiler anses god nok ROS analyser: Folk er generelt for positive og mangler fantasi. I dagens komplekse verden er det ikke usannsynlig at flere ting svikter samtidig Løsninger integreres og utfall får store konsekvenser
IT erfaringer og hva er gjort? 2 Utstyret som feilet: Utstyret som feilet var gammelt og EOL (end of life) dvs ikke støttet fra leverandør lenger. Det fantes patcher til utstyret som ikke var lagt inn Hva er gjort? Programvaren for å detektere loop i nettet er oppgradert Gammelt utstyr av typen som feilet tas ut av drift og erstattes med nytt Erfaringer/undring: Utstyr må vedlikeholdes (patches) og tas ut av nettet ved EOL
Veien videre Total gjennomgang av nettet pågår Vurdere farer ved delt infrastruktur eller hvor mange egg i samme kurv?: Skal tale og data gå på samme nett? Skal viktig datatrafikk gå på eget kablet nett? Hva med sentraliserte (sky) tjenester? Teknologi kan svikte, backup/redundans kan svikte. Vi kunne sende pasienter til Ullevål. Hva om alle tjenestene i en fjellhall som betjener hele HSØ i en tenkt fremtid går ned. Hva gjør vi da? 17 10.05.2012
Spørsmål? Send evt også til ow@owaal.no Gammel teknologi kan være morsomt og virke også!