Rapport fra risikovurdering. Elektronisk meldingsutveksling i Helse Nord

Transkript

1 Rapport fra risikovurdering Elektronisk meldingsutveksling i Helse Nord Versjon Eva Skipenes og Eva Henriksen Nasjonalt senter for samhandling og telemedisin

2 Sammendrag Denne risikovurderingen ble gjennomført i perioden okt.2011-april Bakgrunn for risikoanalysen Nasjonalt senter for samhandling og telemedisin (NST) fikk i oppdrag å gjennomføre risikovurdering av den elektroniske meldingsutvekslingen i Helse Nord. Gjennomføring Risikovurderingen er utført av Eva Skipenes og Eva Henriksen, sikkerhetsrådgivere ved Nasjonalt senter for samhandling og telemedisin (NST), i perioden okt juni Vi har fått muntlige og skriftlige bidra fra personell hos HN IKT, UNN (to kliniske avdelinger, lab- og rtg-avdelinger og SKIS/NST), DIPS ASA, Tromsø kommune og NHN. Vi har hatt møter med Tore Schei, Mona Leirvik, Lars Andreas Wikbo, Odd-Arne Olsen, Eila Øverland og John Inge Lestum, HN IKT Gro Wangensteen, NST/Seksjon for kliniske IKT-systemer (SKIS) Gerd Ersdal, NST/FUNNKe-prosjektet Line Nordgård, Tromsø kommune Åshild Lingrasmo, Sentrum legekontor, Tromsø Tore Dundas og Per Arne Engstad, DIPS ASA Viggo Kristiansen og Marja Leena Jokinen, alderspsykiatrisk avdeling UNN Ola Iversen, nevrologisk og nevrofysiologisk avdeling UNN Hege Gjelvold, AMS, Inger Tranung, patologen, Jorunn Norberg, Laboratoriemedisin, Bengt Hager Nilsen og Anna Bågenholm, rtg.-avdelingen, UNN Pål Arve Sollie og Axel A. Kvale, NHN Hovedkonklusjoner De analyserte systemene er beskrevet i kapittel 3. Nasjonale retningslinjer for krav for elektronisk meldingsutveksling i sektoren er beskrevet i kapittel 2. Kapittel 5 beskriver de identifiserte truslene og analysen av disse, som er basert på definisjonene av sannsynlighet, konsekvens og risikonivå i kapittel 4. Vi har funnet 48 trusler. 4 av disse er vurdert til å ha høyt risikonivå og er dermed uakseptable. Av de 30 truslene med middels risikonivå, anser vi 8 for å være uakseptable. Dette medfører at 12 trusler er vurdert til å ha uakseptabelt risikonivå. I kapittel 6 har vi anbefalt en del tiltak som på ulike måter er med på å redusere risikoen for flere av truslene. Ved gjennomføring av disse tiltakene anser vi risikonivået for å være akseptabelt for de identifiserte truslene med uakseptabelt risikonivå. Vi viser for øvrig til konklusjonene i kapittel 7.

3 INNHOLDSFORTEGNELSE SAMMENDRAG BAKGRUNN OPPDRAGSBESKRIVELSE GJENNOMFØRING NASJONALE RETNINGSLINJER FOR MELDINGSTJENESTEN SYSTEM- OG TJENESTEBESKRIVELSE DAGENS MELDINGSFLYT Arbeidsgrupper og arbeidsflyt Transport- og applikasjonskvittering Kvitteringer for utgående meldinger Kvitteringer for innkommende meldinger Meldingsformater PLO-MELDINGER Håndtering av PLO-meldinger i Helse Nord Håndtering av PLO-meldinger i kommunene TJENESTEBASERT ADRESSERING Kommunikasjonsparter i NHN Adresseregister Tjenestebasert adressering i Helse Nord HN IKT DRIFT DEFINISJON AV SANNSYNLIGHET, KONSEKVENS OG RISIKONIVÅ SANNSYNLIGHET KONSEKVENS RISIKONIVÅ AKSEPTKRITERIER TRUSSELIDENTIFISERING OG -ANALYSE TRUSLER MED HØY RISIKO TRUSLER MED MIDDELS RISIKO TRUSLER MED LAV RISIKO ANBEFALTE TILTAK KONKLUSJON REFERANSER VEDLEGG A TRUSSELTABELL VEDLEGG B: SYSTEMBESKRIVELSE FRA HN IKT B.1 SYSTEM I HELSEFORETAKENE B.1.1 System involvert i meldingsutveksling B.1.2 Meldingstyper og -format B.1.3 Meldingsflyt B.2 SYSTEM VED LEGEKONTOR OG HOS SPESIALISTER VEDLEGG C: STATUS FOR OPPFYLLELSE AV MELDINGSKRAV

4 1 Bakgrunn 1.1 Oppdragsbeskrivelse NST har fått i oppdrag av HN IKT å gjennomføre risikovurdering av den elektroniske meldingsutvekslingen i Helse Nord. I utgangspunktet skulle det være et spesielt fokus på innføringen av ny tjenestebasert adressering, men oppdraget ble utvidet til å gjelde hele systemet med elektronisk meldingsoverføring. HN IKT har etablert prosjektet Meldingsløft del II, som har to delprosjekt: Avgrensning Delprosjekt I gjelder oppgradering og innføring av nye meldingstyper, dvs. oppgradering til siste godkjente versjon fra KITH av eksisterende meldinger og innføring av noen nye meldingstyper for utveksling mellom sykehus. Delprosjekt II (TjenBar-prosjektet) har som mål å organisere arbeidet med innføring av tjenestebasert adressering og HER-ID i Helse Nord. Risikovurderingen som danner grunnlag for denne rapporten er en del av / knyttet til dette prosjektet. Risikovurderingen omfatter i hovedsak HN IKT sitt ansvar for meldingstjenesten fra meldinger kommer inn i DIPS Communicator til meldingen er avlevert til fagsystem (for eksempel DIPS EPJ/PAS, DIPS Lab, DIPS RIS, TRIS, Sympathy). Med melding er avlevert til fagsystem menes at melding er lagt inn i arbeidsflyt og/eller journalnotat i fagsystemet og applikasjonskvittering generert. Man får ikke optimal håndtering av applikasjonskvittering før i DIPS 7.0. Risikovurderingen omfatter også HN IKT sitt ansvar for utgående meldinger, fra Message Broker (eller EDI Broker) trigges til å generere XML-melding basert på meldingsinnhold opprettet i fagsystem, til applikasjonskvittering fra mottaker er registrert og om nødvendig håndtert av HN IKT. I og med at alle andre meldingssyntakser enn XML skal fases ut innen kort tid, vil vi ikke vurdere risikoer knyttet til bruk av andre meldingssyntakser enn denne. Der det er naturlig vil vi også omtale mulige sikkerhetsutfordringer knyttet til mottakers håndtering av meldinger. Fokusområder I risikovurderingen har vi valgt å fokusere på trusler knyttet til: Manglende applikasjonskvitteringer på meldinger Mangelfulle rutiner for oppfølging av kvitteringsmeldinger (for å avdekke avvik) Ruting av PLO-meldinger internt i sykehus Mangelfull behandling av PLO-meldinger i arbeidsflyten Utfordringer ved bruk av tjenestebasert adressering til/fra kommunens PLO-tjeneste, helsestasjon, legevakt, fengselshelsetjenesten og helsetjenesten ved sosialmedisinsk senter i kommunene meldinger som er feiladressert blir ikke synlig for mottakere Kapasitetsbegrensninger i DIPS Communicator Rutiner/mekanismer for mapping mellom helsehjelpsområder og interne arbeidsgrupper i DIPS for innkommende meldinger med tjenestebasert adressering 4

5 Samtidig håndtering av eksisterende meldingsadressering og tjenestebasert adressering (HER-ID) (er nødvendig fordi ikke alle kan motta nye meldingsformat, noe som er nødvendig for å kunne legge inn tjenesteadresser). Tjenestebasert adressering ut fra HF-ene kommer ikke før i DIPS Gjennomføring Risikovurderingen er utført av Eva Skipenes og Eva Henriksen, sikkerhetsrådgivere ved Nasjonalt senter for samhandling og telemedisin (NST), i perioden okt april Vi hadde innledende møter med Lars-Andreas Wikbo og Tore Schei fra HN-IKT i juli-august 2011 med en gjennomgang av oppdraget, og med Odd-Arne Olsen fra HN-IKT i oktober 2011 der drift og overvåkning av meldingsutvekslingen ble gjennomgått. I tillegg har vi underveis hatt samtaler med følgende personer: Tore Schei, Mona Leirvik, Lars Andreas Wikbo, Odd-Arne Olsen, Eila Øverland og John Inge Lestum, HN IKT Gro Wangensteen, NST/Seksjon for kliniske IKT-systemer (SKIS) Gerd Ersdal, NST/FUNNKe-prosjektet Line Nordgård, Tromsø kommune Åshild Lingrasmo, Sentrum legekontor, Tromsø Tore Dundas og Per Arne Engstad, DIPS ASA Viggo Kristiansen og Marja Leena Jokinen, alderspsykiatrisk avdeling UNN Ola Iversen, nevrologisk og nevrofysiologisk avdeling UNN Hege Gjelvold, AMS, Inger Tranung, patologen, Jorunn Norberg, Laboratoriemedisin, Bengt Hager Nilsen og Anna Bågenholm, rtg.-avdelingen, UNN Pål Arve Sollie og Axel A. Kvale, NHN 2 Nasjonale retningslinjer for meldingstjenesten Nasjonalt meldingsløft, initiert av Helsedirektoratet i 2008, skulle bidra til sterkere trykk på utbredelsen av samhandlingsløsninger i helsetjenesten. Tiltaket var en videreføring av Helseog omsorgsdepartementets krav om at helseforetakene skulle ta i bruk elektronisk kommunikasjon i sin samhandling med øvrige deler av helsetjenesten. Hovedmålet for det nasjonale meldingsløftet var at elektronisk kommunikasjon mellom helseforetak, legekontor og NAV skulle være dominerende innen utløpet av 2009 for volumtjenester som epikrise, henvisning, laboratorierekvisisjoner og -svar, røntgenrekvisisjoner og -svar, sykmeldinger, legeerklæringer og legeoppgjør. Meldingsløftet i kommunene er et nasjonalt program som ble etablert for å bistå utvalgte kommuner i arbeidet med å innføre elektronisk meldingsutveksling i kommunene, og ble berammet for perioden Norsk Helsenett (NHN) har fått i oppdrag fra HOD at de skal ha en sentral rolle innen meldingsutveksling og bistand til kommunal sektor på dette området fra Dette innebærer at NHN skal ivareta mange av de behovene som i ble dekket av Meldingsløft-strukturen og dets etablerte nettverk. 5

6 Dokumentet Minstekrav til elektronisk meldingsutveksling ble utviklet av en arbeidsgruppe under Nasjonalt meldingsløft våren Kravdokumentet gir en god oversikt over de mest sentrale kravene/forholdene som må være på plass hos en aktør i helse-, sosial- og omsorgssektoren for at elektronisk meldingsutveksling skal være forsvarlig. Hovedmålsetningen er å sikre at meldingene med korrekt innhold kommer frem til riktig mottaker til riktig tid. På bakgrunn av erfaringene fra meldingsløftet besluttet styringsgruppen for Norm for informasjonssikkerhet å utarbeide et sett med minstekrav for meldingskommunikasjon; Krav til elektronisk meldingsutveksling 2. Kravdokumentet er en omarbeiding av dokumentet fra meldingsløftet nevnt over. Kravene blir veiledende inntil videre for alle virksomheter som behandler helseopplysninger og som sender og mottar elektroniske meldinger i samhandling med andre aktører over helsenettet, men vil bli obligatoriske ved etablering av ny tilknytningsavtale med NHN. Vi har i denne risikovurderingen blant annet tatt utgangspunkt i kravene i dokumentet Krav til elektronisk meldingsutveksling. 3 System- og tjenestebeskrivelse I dette kapitlet gir vi en beskrivelse av tjenesten vi analyserer, slik vi har fått den presentert i dokumenter, skisser og forklaringer fra HN IKT, SKIS, DIPS, UNN, Tromsø kommune m.fl. Vedlegg B inneholder figurer og en detaljert beskrivelse av systemene for meldingsflyt i de ulike foretakene i Helse Nord 3. Elektroniske meldinger i helsetjenesten skal i hovedsak gå fra fagsystem hos avsender til fagsystem hos mottaker. For å sikre forsvarlig kontroll med at meldinger når fram til fagsystem hos mottaker skal systemene sende transport- og applikasjonskvitteringer for hver melding som sendes. Virksomhetene må ha gode rutiner for overvåkning av meldingstrafikken (kvitteringsmeldingene) for å sikre at feil og avvik oppdages og rettes så raskt som mulig. Internt i den enkelte virksomhet må det også være rutiner for å sjekke og følge opp at meldingene kommer fram til rett mottaker i fagsystemene og blir behandlet innen fastsatte tidsfrister. Dokumentet Krav til elektronisk meldingsutveksling illustrerer meldingsutvekslingen med tilhørende kvitteringer på følgende måte (Figur 1) 2 : 1 Helsedirektoratet, Nasjonalt meldingsløft: Minstekrav til elektronisk meldingsutveksling, IS-1950, Helsedirektoratet, Norm for informasjonssikkerhet i helse-, omsorgs- og sosialsektoren: Krav til elektronisk meldingsutveksling, Versjon 1.0, 1. desember Kilde: Odd-Arne Olsen, HN IKT 6

7 Figur 1 Meldingsutveksling i helse-, sosial- og omsorgssektoren med meldingskvitteringer 3.1 Dagens meldingsflyt Meldingsutveksling ut fra et fagsystem i helseforetaket til et fagsystem hos en annen virksomhet skjer som regel ved at det skrives en melding i helseforetakets fagsystem. Når meldingen er godkjent i fagsystemet, vil integrasjonsprogrammet (Message Broker eller EDI Broker dersom fagsystemet er DIPS) generere en melding i riktig format i henhold til en meldingsstandard (f.eks. KITH-standardmelding for poliklinisk notat eller epikrise), og sende denne til en lokal meldingstjener. Meldingstjeneren (f.eks. DIPS Communicator) pakker meldingen inn i en meldingskonvolutt, krypterer meldingen og adresserer den med den elektroniske adressen til mottakeren basert på informasjon om mottakeren i meldingen fra fagsystemet. Meldingen sendes så til meldingstjeneren hos mottakende virksomhet, som dekrypterer meldingen, sender transportkvittering og sender meldingen inn i lokalt fagsystem, som i sin tur returnerer en applikasjonskvittering til avsender (ref. Figur 1). Ett av kravene i dokumentet Krav til elektronisk meldingsutveksling er at den internasjonale standarden ebxml skal benyttes for sending og mottak av meldinger. Dette gjelder kun DIPS. Andre fagsystem har andre måter å håndtere meldinger på. De fleste fagsystemene bruker ikke Message Broker. 7

8 Fagsystemene forholder seg ikke til ebxml. Meldingsfila som Message Broker genererer er ei XML-fil og inneholder samme tekst men ikke nødvendigvis all formatinformasjon som den opprinnelige meldingen i fagsystemet. Dette innebærer at meldingen ikke nødvendigvis vil se likedan ut hos mottaker som for helsepersonellet som skrev meldingen. I tillegg er visningen av XML-fila hos mottaker avhengig av hvilken visningsfil fagsystemet hos mottaker benytter (de ulike journalsystemene har ulik implementasjon av KITHs standard for visningsfil, og noen journalsystem benytter ikke KITHs standard for visningsfil i det hele tatt). Visningsfilene benyttes for å generere en html-visning av innholdet i en XML-melding 4. Meldinger som kommer inn til helseforetakene, kommer til meldingstjeneren (f.eks. DIPS Communicator). Denne dekrypterer meldingen og sender transportkvittering til avsender (dersom meldingen er ok). Meldingen legges deretter i en katalog på et filområde. Hvert enkelt fagsystem som kan motta meldinger har sin egen katalog (en for innkommende meldinger og en for utgående meldinger). Meldingen håndteres videre av en integrasjonsmodul, for eksempel EDI Broker eller Message Broker for meldinger til DIPS. Disse modulene sjekker regelmessig om det ligger meldinger i innkatalogene på deres filområde, finner ut hvilken pasient de tilhører og knytter dataene til rett pasient i DIPS. Dersom meldingen inneholder journalinformasjon (f.eks. en henvisning eller rekvisisjon) opprettes det et journaldokument av korrekt dokumenttype (f.eks. henvisning), som dataene legges inn i. Dette dokumentet lagres i pasientens journal og det opprettes en oppgave tilknyttet dette dokumentet / denne meldingen i riktig arbeidsgruppe i fagsystemet (f.eks. DIPS EPJ/PAS). Hvis dette er vellykket sendes positiv applikasjonskvittering til fagsystemet hos avsender. Hvis operasjonen mislykkes sendes negativ applikasjonskvittering. EDI Broker og Message Broker forholder seg til det lokale oppsettet av DIPS EPJ/PAS i det enkelte foretak Arbeidsgrupper og arbeidsflyt De tradisjonelle posthyllene og den interne postgangen for papirjournaler på sykehusene er erstattet med arbeidsgrupper i DIPS EPJ/PAS. Arbeidsgruppene kan ses på som elektroniske postkasser. Arbeidsgruppene er enten personlige eller delte. For delte arbeidsgrupper er det flere som har tilgang og ansvar for å følge opp arbeidsoppgavene. Journalsystemet DIPS EPJ/PAS har også en mekanisme som kalles Arbeidsflyt. Denne mekanismen sørger for at oppgavene knyttet til ulike journaldokument forflytter seg elektronisk gjennom systemet og mellom brukerne. Arbeidsflyt i DIPS kan beskrives som en elektronisk arbeidsliste som inneholder de arbeidsoppgavene hver enkelt er ansvarlig for å utføre. Arbeidslisten kan involvere flere arbeidsgrupper hvor en person enten har ansvaret for arbeidsoppgavene alene (personlig arbeidsgruppe) eller sammen med andre (felles arbeidsgruppe). En bruker kan se sine egne oppgaver, men kan også be om å få se andre brukeres arbeidsoppgaver, eller la andre se egne arbeidsoppgaver for eksempel ved fravær eller for å overvåke andres arbeidsoppgaver. I arbeidsgruppene har en oversikt over både utførte og ikke ferdigstilte oppgaver. Det kan være ulike arbeidsflyter for ulike typer journaldokument og ulike meldinger. DIPS EPJ/PAS har også en arbeidsgruppe for meldinger som det ikke er definert en arbeidsflyt for. Denne arbeidsgruppen heter Udefinert arbeidsflyt. Her legges alt systemet ikke finner en logisk plassering for. Mange av meldingene som havner i arbeidsgruppen Udefinert arbeidsflyt håndteres av HN IKT. Grunnen til at de havner i denne arbeidsgruppen er at meldingene er adressert på en måte som systemet ikke håndterer automatisk, f.eks. at aspx (sist sett ) 8

9 melding er adressert til foretaket og ikke til en avdeling, eller til en avdeling som ikke finnes (DIPS finner ikke arbeidsflyt som passer). En annen type meldinger som havner i Udefinert arbeidsflyt er henvisninger fra andre foretak som er adressert til post eller seksjon. Så lenge det ikke er tatt i bruk en meldingstype for henvisning mellom foretak, benyttes epikriseformatet til dette. Slike meldinger havner da i oppgaven Eksterne epikriser til signering i arbeidsgruppen Udefinert arbeidsflyt. HN IKT må lese epikrisehenvisningen for å finne ut hvor den skal, og flytte den inn i riktig arbeidsgruppe. Henvisninger skal pr i dag rutes til en avdelingsrekvirent på mottakende helseforetak. Men EDI Broker (som formidler henvisninger og epikriser) har ikke informasjon om andre helseforetaks interne avdelingsrekvirenter, og støtter ikke det å sende for eksempel en epikrise til en avdelingsrekvirent på et annet foretak. Dersom henvisningen adresseres til helseforetaket og ikke til en avdeling i helseforetaket, vet ikke EDI Broker (som oversetter henvisningen fra DIPS Communicator til DIPS EPJ/PAS) hvor henvisningen skal. Det er kun UNN som har post- og seksjonsadresser. De vil ikke endre dette slik at de får henvisningene inn i arbeidsflyten til avdelingen. De vil heller ha dem i Udefinert arbeidsflyt. Henvisning mellom foretak er under utprøving. Lab-systemer som ikke er en del av DIPS opererer ikke med arbeidsflyt og arbeidsgrupper. Dette gjelder også røntgensystemer og andre mindre fagsystem som f.eks. Partus. De følgende avsnittene beskriver meldingshåndteringen på laboratorie- og røntgenavdelinger på UNN. Laboratoriemedisin UNN (omfatter medisinsk biokjemi, immunologi og farmakologi): Avdelingen bruker DIPS Lab. Rekvisisjoner kommer inn elektronisk fra noen fastlegekontor. Disse rutes til riktig fagområde. De kommer via DIPS, men legges i ei mappe på en server på nettet. De flyttes automatisk over i lab-systemet i forbindelse med at laboratoriepersonalet foretar en manuell ankomstregistrering av hver enkelt prøve. De elektroniske meldingene som kommer inn, havner alltid på rett sted, men det hender at meldinger ikke kommer i det hele tatt. Dette kan skyldes at legekontoret ikke har fullført meldingsprosessen eller at serverne er nede på sykehuset. Hvis serverne er nede får man ikke tilgang til mappene med meldinger tidsnok. Noen ganger finner man dem igjen. Laboratoriet får fysiske prøver og finner alltid ut hvor de kommer fra. Dersom rekvisisjon mangler ordner de alltid opp i det. Utgående svar fra laboratoriemedisin på UNN: Personalet på avdelingene kan se status for utgående meldinger (laboratoriesvar), og sjekke om meldingene er mottatt i fagsystemet hos mottaker. De benytter imidlertid ikke denne muligheten. HN IKT har ansvar for dette og melder fra. Avdelingen gjør revisjoner enkelte ganger i året hvor de går gjennom meldingsflyten. Applikasjonskvittering kan ikke leses i DIPS pr i dag. Ved papirrekvisisjoner kan man punche feil og svaret kan bli sendt til feil mottaker. Alle labsvar sendes elektronisk, men hvis man har tastet inn feil rekvirent for prøven, blir svaret sendt feil. Mikrobiologi og smittevern UNN: Innkommende elektroniske rekvisisjoner kommer til en egen mappe for mikrobiologi som automatisk leses inn i eget system (Analytics). Systemet genererer pop-up-meldinger dersom rekvisisjonen ikke kan lastes inn automatisk. Disse følges opp fortløpende. Noen av årsakene til at rekvisisjonene ikke kan lastes inn er at rekvirentkoden ikke er oppdatert i DIPS eller at det er benyttet en analysekode som er gått ut. Rekvirentkodene kan oppdateres manuelt slik at rekvisisjonen kan lastes inn i fagsystemet. 9

10 Avdelingen har prosedyrer for håndtering av alle feilsituasjoner. Enkelte ganger kommer ikke rekvisisjonsmeldingene fram til UNN i det hele tatt. Årsakene til dette er ukjent. Det kan muligens skyldes at personellet på legekontoret ikke har gjort alt rett mht sending av rekvisisjonen. Manglende rekvisisjoner oppdages ved at prøveglasset kommer men at man ikke finner tilhørende rekvisisjon i systemet. Pasientopplysninger og rekvirentkode står på prøveglasset, men ikke hvilke prøver som er bestilt. Legekontoret blir kontaktet for å få de nødvendige opplysninger. Ved mottak av papirrekvisisjon registreres prøven inn i systemet på rekvirent-id som legekontoret har oppgitt, slik at man kan sende elektronisk svar. For utgående meldingssvar finnes det en mulighet i fagsystemet Analytics for å sjekke at meldingen har kommet fram til mottakers fagsystem. Denne funksjonaliteten er ikke tatt i bruk ennå, da løsningen ikke fungerer sammen med eksisterende meldingsstandarder. Feltene for navnene på de elektroniske meldingene i Analytics er for korte. Leverandøren jobber med saken, og man håper å få dette på plass snart. Det finnes imidlertid mulighet for å gå inn i DIPS Interactor og sjekke status for utgående meldinger. Her ser man et statusflagg (fargekoder) på alle meldinger, som indikerer om meldingen er sendt, mottatt etc. Denne oversikten sjekkes sporadisk. Heidi Kjærran på HN IKT følger også med og tar kontakt hvis meldinger ikke har gått ut. Patologen (Klinisk patologi): Bruker ikke DIPS, de har et eget system. De har foreløpig ikke tatt i bruk elektroniske meldinger, men systemet er tilrettelagt for det, og de er i startgropa for å få på plass elektronisk rekvisisjon og svar. Blir dette innført som en del av FIKSprogrammet? Røntgenavdelingen: Til og fra primærhelsetjenesten: 1. Håndtering av innkommende elektroniske rekvisisjoner (XML-rekvisisjoner): a. Alle XML-rekvisisjoner leveres av EDI systemet (DIPS Communicator) til en mappe på en filserver. EDI systemet håndteres av HN-IKT. b. TRIS importerer filene etter gitt intervall (hvert minutt). c. Basert på informasjon om mottaker (røntgenavdeling) i XML-fila vil TRIS definere en utførende avdeling og rekvisisjonen dukker opp i TRIS tilknyttet den utførende avdeling. Dersom det er usikkert hvem som skal være mottaker blir rekvisisjonen rutet til UNN Tromsø. Mulige feilkilder håndteres forskjellig: Manglende obligatoriske ID er slik som pasient ID og/eller rekvirent ID. Dette oppdages ved innlesing til TRIS og meldingen flyttes til en ERROR mappe. Denne mappen sjekkes (daglig?) av dedikert personell på røntgenavdelingen Tromsø. Feil i rekvirent ID (HPR nummer) eller TRIS finner ikke unik rekvirent i DIPS (som holder rekvirentregisteret til TRIS). Meldingen importeres uten rekvirentkode og bruker må legge inn korrekt rekvirentkode manuelt. Dette er dessverre en gjenganger og forårsaker betydelig merarbeid og her gjøres det også mange brukerfeil. 2. Håndtering av utsendelse av elektroniske (XML) røntgensvar: a. TRIS genererer XML-svar når undersøkelse godkjennes av radiolog. b. Alle XML røntgensvar eksporteres av TRIS til en gitt mappe på en filserver og leses av DIPS Communicator. c. Det vises med fargekode (gult ikon) i TRIS at svar er sendt. 10

11 d. Når rekvirent mottar røntgensvar skjer en av tre ting: i. Ikke noe det vil si at rekvirent ikke bruker applikasjonskvittering. Ingen videre handling i TRIS. ii. Rekvirent kvitterer for mottak av svar det vises med fargekode (grønt ikon) i TRIS. iii. Rekvirent avviser svar det vises med fargekode (rødt ikon) i TRIS. Følges opp av dedikert personell på røntgenavdelingen i Tromsø e. I de tilfeller TRIS ikke finner en gyldig elektronisk mottaker for røntgensvaret vil svaret legges i en utskriftsjobb. Manuelle rutiner ivaretar utskrift på papir av svaret og oversendelse i posten. Det som oppleves som det største problemet er at det ikke finnes noe (oppegående) nasjonalt rekvirentregister som er felles for alle tjenesteleverandører i Norge. Det betyr at man aldri kan være 100 % sikker på om man kommuniserer med rett part. Man er prisgitt lokale register med feil og mangler. Et eksempel på dette er at rekvirerende leger som bestiller røntgenundersøkelser ofte oppgir sin UNN-rekvirentkode når de er i primærhelsetjenesten. Svaret går da til deres signeringsliste (personlig arbeidsflyt) på UNN og der blir det liggende (siden legen ikke jobber på UNN lenger) i inntil tre måneder innen det automatisk flyttes til en ryddegruppe. Da havner det ofte hos rtg-avdelingen fordi det er et rtg-svar. Ansatte på rtg-avdelingen mener svaret burde vært flyttet til arbeidsflyten i avdelingen der legen har vært ansatt. I dag finner ansatte på rtgavdelingen manuelt ut hvilket primærlegekontor legen jobber på, skriver ut svaret, sender det i posten og skriver logg i DIPS om at svaret er sendt manuelt. De kan ikke videresende meldinger til rekvirentkoder utenfor DIPS UNN Transport- og applikasjonskvittering Kvitteringer for utgående meldinger Meldinger som sendes ut fra foretaket, går til meldingstjeneren, for eksempel DIPS Communicator, hos mottakende virksomhet, som dekrypterer meldingen og sender transportkvittering tilbake dersom meldingen er ok. Dersom meldingen ikke er ok, for eksempel hvis krypteringen ikke var korrekt, sendes en avviksmelding. Dersom meldingen ikke blir behandlet av meldingstjeneren hos mottaker (serveren kan for eksempel være avslått), sendes det naturlig nok ingen transportkvittering. Det ligger en automatikk i DIPS Communicator i HF-ene på de partnerne som det benyttes ebxml-kryptering mot. Mottas ikke transportkvittering, sendes meldingen automatisk på nytt etter to dager. Denne gjentatte sendingen gjøres inntil meldingen har fått transportkvittering i retur, eller inntil fem gjentatte sendinger, alltid med to dagers mellomrom. Mottas ingen transportkvitteringer etter fem forsøk (10 døgn), genereres det et avvik. Hvis behandling av meldingen i mottakers meldingstjener (f.eks. DIPS Communicator) er ok, legges meldingen inn i fagsystemet hos mottaker, som sender positiv applikasjonskvittering tilbake til foretaket. Hvis meldingen ikke kan legges inn i fagsystemet, sendes det en negativ applikasjonskvittering. Årsaker til at meldingen ikke kan legges inn i fagsystemet kan for eksempel være at pasienten ikke er registrert i legekontorets journalsystem, at fastlegen som er oppgitt i meldingen ikke (lengre) jobber ved legekontoret eller at personnummeret til pasienten ikke er fullstendig (f.eks. ved bruk av hjelpenummer). Meldingen stoppes da i 11

12 innlesningsmodulen. Dersom årsaken er at legen har sluttet ved legekontoret, må meldingen legges manuelt inn i fagsystemet ved at man f.eks. kobler pasienten til riktig lege (den som har overtatt ansvaret for pasienten). Når det skjer, sendes det en positiv applikasjonskvittering. Dersom pasienten ikke eksisterer i legekontorets journalsystem, må meldingen manuelt merkes som feil og sendes i retur til avsender. Status for transport- og applikasjonskvittering fra mottaker av meldingene må sjekkes av avsender, for å være sikker på at meldingene har kommet fram til fagsystem hos mottaker. For PLO-meldinger og sykepleierepikriser kan man få oversikt over status for applikasjonskvitteringer i Korrespondanseloggen. Den blir innført for alle meldinger i DIPS 7.0, men finnes allerede i DIPS 6.x for PLO-meldinger. Applikasjonskvitteringer er tilgjengelig i Message Broker. Det er HN IKT som har ansvar for overvåkning av transportkvitteringene for utgående meldinger, mens avdelingene har ansvar for å overvåke mottak av applikasjonskvitteringer for de samme meldingene Kvitteringer for innkommende meldinger For innkommende meldinger sender DIPS Communicator hos foretaket positiv transportkvittering dersom meldingen er ok, og en avviksmelding ellers. Message Broker eller EDI Broker sender positiv applikasjonskvittering til avsender når innkommende melding er lagt inn i riktig arbeidsgruppe i DIPS EPJ/PAS (ut fra definerte regler). Message Broker legger meldingen i Udefinert arbeidsflyt hvis den ikke finner en passende arbeidsgruppe å legge meldingen i. HN IKT forsøker manuelt å løse årsaken til at den ikke kan legges i riktig arbeidsgruppe. Merk at det sendes positiv applikasjonskvittering når meldingen er mottatt, uansett hvilken arbeidsgruppe/arbeidsflyt den er lagt inn i. Meldinger som av en eller annen grunn har havnet i Udefinert arbeidsflyt (eller andre mapper de ikke skulle vært i) oppdages som regel raskt av HN IKT og rettes. HN IKT har imidlertid ikke gode nok verktøy som varsler mulige feilsituasjoner, noe som kan føre til at meldinger kan bli liggende for lenge i en udefinert arbeidsflyt før den blir behandlet av HN IKT. Det kreves manuelle overvåkning og årvåkenhet for å fange opp alle meldinger som havner feil. En grunn til at HF-et ikke mottar transportkvittering på meldinger som er sendt til for eksempel legekontor, kan være at legekontorets sertifikatopplysninger i NHN Adresseregister ikke er riktig. Virksomhetene i helsesektoren får utstedt et virksomhetssertifikat av Buypass. Aktører som vil sende melding til en virksomhet, må benytte mottakende virksomhets sertifikat for å kryptere meldingene slik at kun mottakeren kan dekryptere disse. Egen virksomhets sertifikat brukes for å dekryptere innkommende meldinger. Virksomhetene (f.eks. legekontorene) er selv ansvarlige for å legge inn og vedlikeholde egen sertifikatinformasjon i NHN Adresseregister. HN IKT har tilgang til sertifikatkatalogen hos Buypass og kan laste ned kommunikasjonspartenes sertifikat direkte derfra. De regner med å måtte gjøre dette også framover, da personellet på fastlegekontorene ikke alltid forstår hvordan de skal legge sertifikatinformasjon inn i Adresseregisteret. Det har vist seg at brukerstøtte hos en del av leverandørene av fastlegesystem har for liten kunnskap om og forståelse for ebxmlrammeverket til å kunne bistå legekontorene med riktig innlegging av sertifikatinformasjon i NHN Adresseregisteret. HN IKT må enkelte ganger hjelpe legekontorene med å legge inn sertifikatinformasjon for egen virksomhet og for kommunikasjonspartene deres. 12

13 3.1.3 Meldingsformater Det er fire meldingssyntakser i bruk nå (EDIFACT, DOLLAR, ASTM og XML). Målet er at alle meldinger innen kort tid skal være på XML-format, senest innen utgangen av ASTM-format er DIPS sitt interne format. Lab-rekvisisjon og lab-svar går på dette formatet men skal over på XML. Patologi har gått på DOLLAR-format men gikk over på XML for UNN NLSH går over til XML på patologi etter vellykket innføring på UNN. XMLversjon av svar fra klinisk kjemisk lab skal piloteres snarest fra NLSH mot et legekontor i Bodø. Når det fungerer der rulles det ut for hele NLSH og UNN. Immunologi skal også over på XML i nærmeste framtid. Overgang fra POLK til behandlerkravmeldinger ble gjort fra Dette, sammen med oppgradering og innføring av nye lab-meldinger, vil føre til at EDIFACT fases helt ut. I og med at alle andre meldingssyntakser enn XML skal fases ut innen kort tid, vil vi ikke vurdere risikoer knyttet til bruk av andre meldingssyntakser enn XML. Det aksepteres ikke lenger oppkoblingshenvendelser hvor DES anvendes som krypteringsalgoritme. Alle som vil kommunisere med Helse Nord må benytte ebxml med tilhørende krypteringsalgoritmer (virksomhetssertifikat). 3.2 PLO-meldinger Det er utarbeidet tre ulike kategorier PLO-meldinger for kommunikasjon mellom pleie- og omsorgssektoren og helseforetak 5 : 1. Logistikkmeldinger (fra HF til PLO) a. Melding om innlagt pasient b. Melding om utskrivningsklar pasient c. Avmelding utskrivningsklar pasient d. Melding om utskrevet pasient 2. Fagmeldinger a. Innleggelsesrapport (fra PLO til HF) b. Helseopplysninger ved søknad (fra HF til PLO) c. Utskrivningsrapport (fra HF til PLO) (benyttes foreløpig ikke) 3. Dialogmeldinger (til/fra HF og PLO) a. Forespørsel (helseopplysninger, legemiddelopplysninger, status/plan for utskrivning, annen henvendelse) b. Svar på forespørsel (helseopplysninger, legemiddelopplysninger, status/plan for utskrivning, annen henvendelse) c. Avviksmeldinger (feilmelding, mangelfulle opplysninger, annet) d. Svar på avviksmeldinger I følge Anbefaling til Retningslinjer for bruk av Pleie- og omsorgsmeldinger, versjon 2.0, KITH-rapport 06/08: 2011, skal logistikkmeldinger ikke inneholde medisinske opplysninger. Melding om at pasienten er utskrivningsklar skal derfor ikke inneholde informasjon om hvorfor pasienten er utskrivningsklar. Tanken er at slike opplysninger i logistikkmeldingene vil innebære brudd på taushetsplikten. Mange mener likevel at det er en selvfølge at kommunen får all den informasjonen de trenger for å ivareta pasienten videre. Dette gjøres gjennom fagmeldinger som legges ved logistikkmeldingene, og om nødvendig i dialogmeldinger. 5 Anbefaling til Retningslinjer for bruk av Pleie- og omsorgsmeldinger, versjon 2.0, KITH-rapport 06/08:

14 Når man bruker fagmeldingen Helseopplysninger ved søknad som vedlegg til logistikkmeldingen Melding om utskrivningsklar pasient, må/kan man skrive hvorfor pasienten er utskrivningsklar, og hvilke behov pasienten har videre. Denne meldingen må tagges slik at det vises at den hører sammen med Melding om utskrivningsklar pasient. Det er en utfordring av det må brukes to meldinger for å formidle nødvendige opplysninger. I tillegg må det sendes ordinær epikrise til fastlegen og ev. annen innleggende lege Håndtering av PLO-meldinger i Helse Nord PLO-meldingene har vært pilotert ved to avdelinger på UNN i PLO-meldingene til UNN kommer til en egen instans av DIPS Communicator (se Figur 3 i Vedlegg B) pga. kapasitetsutfordringer i DIPS Communicator. PLO-meldingene kan foreløpig bare adresseres til helseforetaket og ikke til avdelinger eller tjenester. For innkommende fagmeldinger og dialogmeldinger bruker man ikke informasjon om mottaker til å rute meldingene til riktig arbeidsgruppe i DIPS EPJ/PAS. Message Broker sjekker i DIPS om pasienten er innlagt. Hvis pasienten er innlagt rutes meldingen inn i arbeidsgruppa til de som behandler pasienten. PLO-meldingene blir samtidig tilordnet en somatisk eller psykiatrisk journalgruppe, avhengig av hvor pasienten er innlagt. Dette bidrar til at kun de som skal ha tilgang til meldingen får tilgang. Hvis pasienten ikke er innlagt og det kommer en PLO-innleggelsesrapport til helseforetaket, rutes meldingen til arbeidsgruppa Udefinert arbeidsflyt i DIPS EPJ/PAS. I utgangspunktet er arbeidsgruppa Udefinerte arbeidsflyt felles for hele helseforetaket. PLO-meldinger som havner i denne arbeidsgruppa, legges under oppgaven Til vurdering. Noen må manuelt følge opp meldingene i Udefinert arbeidsflyt (dvs. lese innholdet) og sørge for at de blir flyttet til riktig arbeidsgruppe. Meldingene som ligger under oppgaven Til vurdering følges på UNN daglig opp av Gro Wangensteen ved SKIS. Hun sørger for at meldingene rutes til riktig arbeidsgruppe. Systemet kan ikke finne ut hvor meldingen skal hvis pasienten ikke er innlagt. Dette er en utfordring, selv om det ikke forventes å skje særlig ofte. HF-ene bør tenke på mer permanente rutiner for å håndtere dette når mengden av PLO-meldinger øker. Avdeling for nevrologi og nevrofysiologi og alderspsykiatrisk avdeling har vært pilotavdelinger for innføring av PLO-meldinger på UNN fra Tromsø kommune. Begge avdelingene uttaler at de nesten ikke har hatt tekniske problemer med sending og mottak av PLO-meldinger. I disse dager rulles innføring av PLO-meldinger ut til alle avdelinger på UNN, og til stadig flere kommuner i UNNs nedslagsfelt. Dette bidrar til en dramatisk økning i antall elektroniske meldinger til og fra UNN. Det genereres i gjennomsnitt 20 meldinger for hver pasient som pleie- og omsorgssektoren benytter PLO-meldinger mot helseforetaket for Håndtering av PLO-meldinger i kommunene Foreløpig må alle adresser legges inn manuelt i fagsystem og meldingstjenere både i PLOsektoren og hos fastlegene. Fastlegene får tilsendt et adressekit med helseforetakenes adresselister fra leverandørene, som kan importeres inn i fagsystemet. Leverandørene av pleie- og omsorgssystem er i ferd med å utvikle funksjonalitet for automatisk oppdatering av adresser fra NHN Adresseregister. De aller fleste kommuner i Helse Nord benytter fagsystemet Visma Profil for PLO. 14

15 UNN sender i dag PLO-meldinger til én fast tjenesteadresse i hver kommune. Dette innebærer at alle som har tilgang til den aktuelle pasientens journal i PLO-systemet, og har tilgang til funksjonen elektroniske meldinger, vil kunne lese meldingen i innboksen, selv om de egentlig ikke er autorisert til å se den aktuelle type melding for denne pasienten. Ved overgang til å adressere til ulike tjenesteområder i kommunen, kan helsepersonellet i HFene komme i skade for å velge feil tjenesteadresse, med den følge at de som skal ha meldingen ikke får den. Hvis meldinger er adressert til feil tjenesteområde i pleie- og omsorgssektoren i en kommune, kan det skje at meldingen ikke blir synlig for mottakerne, fordi de som har tilgang til innboksen til tjenesteadressen meldingen er feilsendt til ikke nødvendigvis er autorisert for den aktuelle pasientens journal, og de får dermed ikke se meldingen. Og de som skulle hatt meldingen får den ikke i sin innboks. Det er viktig at kommunene har noen på overordnet nivå som kan følge opp meldinger som ikke blir håndtert innen fastsatte tidsfrister. 3.3 Tjenestebasert adressering Høsten 2009 utarbeidet arbeidsgruppen Bruk av NHN Adresseregister, Nasjonalt Meldingsløft , to dokumenter vedrørende adressering. Disse dokumentene var på høring blant alle arbeidsgruppens medlemmer høsten 2009: - Publisering av kommunikasjonsparter i spesialisthelsetjenesten (HEMIT/ ) - Organisasjonstyper Adresseregisteret (KITH/ ) Det kom ingen innspill fra arbeidsgruppen i forbindelse med denne høringen. Videre ble det fremlagt et beslutningsdokument for styringsgruppen i Nasjonalt meldingsløft den : - Publisering av kommunikasjonsparter i spesialisthelsetjenesten (Helsedir./ ). Disse dokumentene danner grunnlag for beslutningen i styringsgruppen for Nasjonalt Meldingsløft i januar 2010 om innføring av tjenestebasert adressering både for kommunale helsetjenester og kliniske/medisinske tjenester fra spesialisthelsetjenesten. Slik adressering fokuserer på helsetjenestene som ytes, og ikke på den bakenforliggende organisasjonsstrukturen i helsetjenesten, som tidligere dannet grunnlag for adresseringen. Det er besluttet at følgende kodeverk (med tjenestekoder) skal benyttes for tjenestene spesialisthelsetjenesten tilbyr pasientene: 8655 Helsehjelpsområde Klinisk/medisinsk service 7. Tilsvarende kodeverk som skal benyttes for tjenester i kommunene er: 8663 Kommunale helse- og sosialtjenester Kommunikasjonsparter i NHN Adresseregister NHN Adresseregister inneholder en oversikt over kommunikasjonsparter i helse-, pleie- og omsorgssektoren. Kommunikasjonsparter som omfattes av begrepet tjenestebasert adressering kan være helsetjenester i kommunen eller kliniske/medisinske tjenester i spesialisthelse- 6 (sist sett ) 7 (sist sett ) 8 (sist sett ) 15

16 tjenesten. Legekontor og primærlege er også kommunikasjonsparter, men omfattes foreløpig ikke av tjenestebasert adressering. Nøkkelidentifikatoren i NHN Adresseregister for den enkelte kommunikasjonspart er partens HER-ID. Dette er en unik id som tildeles alle kommunikasjonsparter etter hver som de publiseres i NHN Adresseregister. Hver enkelt virksomhet er ansvarlig for å registrere og oppdatere nødvendige opplysninger om virksomheten og tjenestene i adresseregisteret. NHN Adresseregister har to viktige bruksområder: - Finne en kommunikasjonspart (tjeneste med tilhørende HER-ID) - Finne den valgte kommunikasjonspartens EDI-adresse (e-postadresse) og sertifikatinformasjon EDI-adressen benyttes for adressering av meldinger til kommunikasjonsparten. Sertifikatinformasjonen benyttes for kryptering av meldinger som sendes til kommunikasjonsparten. Se kap I HF-ene er tanken at de enkelte fagsystem, f.eks. TRIS, skal gjøre automatiske oppslag i rekvirentregisteret i DIPS, for hver melding som skal sendes. Helsepersonell som skriver meldingen, velger riktig tjeneste å sende meldingen til fra dette registeret. Virksomhetene kan abonnere på fortløpende automatisk oppdatering av informasjonen fra NHN Adresseregister. Rekvirentregisteret i DIPS synkroniseres to ganger i døgnet fra NHN Adresseregister, FRESH-Connectorene som benyttes for å synkronisere rekvirentregisteret fra NHNs adresseregister, er satt opp i alle HF-ene og testet. Dette skal nå være klart til bruk Tjenestebasert adressering i Helse Nord Overgangen til bruk av HER-ID i all meldingsutveksling er komplisert. Det tas sikte på en kontrollert prosess i alle regioner for å ta i bruk HER-ID, der RHF/HF får en sentral rolle for utbredelse i egen region mot kommunikasjonsparter de samhandler med. Alle RHF har etablert prosjekt for å få dette på plass. På helseforetaksiden skal det være fullt mulig å håndtere elektroniske meldinger basert på organisasjonsnummer som kommunikasjonsinformasjon parallelt med HER-ID-basert meldingsutveksling. Det samme må sikres ivaretatt på legekontorsiden, ved at eksisterende partneroppsett mellom respektive helseforetak og legekontor bevares også etter at HER-IDbasert meldingsutveksling er tatt i bruk. I Helse Nord benyttes DIPS Communicator som meldingstjener i HF-ene. DIPS Communicator tar pr i dag imot meldinger (henvisninger og rekvisisjoner) adressert med avdelingskode og sender dem videre til avdelingens arbeidsgruppe i journalsystemet via EDI Broker og Message Broker. DIPS EPJ/PAS sin arbeidsflyt er organisert i henhold til avdelinger og arbeidsgrupper tilknyttet avdelinger. Fremtidige meldinger med tjenesteadresser må knyttes mot disse avdelingsvise arbeidsgruppene. DIPS er ikke designet for å ha et forhold til tjenestebegrepet. Det må gjøres en mapping mellom tjenesteadressen i en innkommende melding og avdeling/organisasjonsenhet som skal ha dokumentet i arbeidsflyten. Funksjonalitet (mapping-tabeller) for dette er laget i DIPS 7.0. HF-ene kan selv legge inn informasjon i mapping-tabellene. 16

17 Det har vært skissert en måte å lage en mapping mellom avsenderlegens HER-ID og HPR-nr. I Helse Nord har man foreløpig ikke mottatt meldinger som har gått over til å benytte avsenderlegens HER-ID i stedet for HPR-nr. For lab-meldingene har det vært en oppryddingsjobb på gang i Helse Nord over flere år. Message Broker i DIPS 7.0 håndterer alle typer standard lab-meldinger (på XML-format), men hvert enkelt foretak/lab må selv bestemme når de vil gå over til de nye standardmeldingene. Lab-systemene må også kunne håndtere de nye standardene før man går over. Mye skal klaffe og mye skal synkroniseres for at tjenestebasert adressering skal fungere. Innføring av tjenester i adresseringen er en utfordring. FRESH-Connector kan ikke brukes til å laste inn egne tjenesteadresser inn i DIPS. Den tidligere nevnte mapping-tabellen mellom tjenesteadresser og interne organisasjonsenheter må benyttes for ruting av meldinger internt i DIPS EPJ/PAS. På UNN har Gro Wangensteen, EPJ-rådgiver i SKIS, mappet UNNs tjenestekoder (som er registrert i NHN Adresseregister) mot avdelinger i UNN, i samarbeid med klinikkene. Mappingen er synkronisert mot DIPS i pilotversjonen av DIPS 7.0. På HLSH og HFHF har de også laget slike mappinger, men disse er foreløpig ikke synkronisert mot DIPS. Dette blir gjort i release-versjonen av DIPS 7.0. NLSH har ikke levert sine koder ennå. Mappingen av tjenestekoder mot avdelinger i foretaket er en forutsetning for at tjenestebasert adressering skal fungere. Bodø kommune skulle pilotere tjenestebasert adressering på PLO-meldinger mot testversjonen av DIPS 7.0 våren Dette måtte avbrytes pga. manglende løsninger i PLOsystemet Gerica. 3.4 HN IKT drift Seksjon for Samhandling og Integrasjon i HN IKT drifter elleve sykehus, to legevakter i Bodø og Longyearbyen sykehus. Dette omfatter: forskjellige DIPS-installasjoner og oppsett o 2 bruker ikke arbeidsflyt, flere bruker ufullstendig arbeidsflyt Longyearbyen bruker CGM Vision Legevaktene bruker CGM WinMed Kommunikasjon mot ca. 220 partnere i regionen (legekontorer og spesialister) UNN sender ca. 1.3 millioner meldinger pr år og mottar ca innkommende meldinger. Antallet er økende. Det forventes en tredobling når PLO-meldinger er fullt utbygd mot alle kommuner og alle UNN-avdelinger, og når rekvisisjon og svar mellom sykehus er innført. Overvåkning og rutiner Det første som gjøres hver morgen er en gjennomgang av alle applikasjonene på EDIserverne. Logger gjennomgås på applikasjoner som har slike. EDI-applikasjonene er satt opp til å sende feilmeldinger og varsler til lokasjonsansvarlig via e-post. Det er tre personer som har ordinære driftsoppgaver, i tillegg har to utfyllende driftsoppgaver. Lokasjonene er fordelt på følgende måte: 17

18 1. Kirkenes, Hammerfest, UNN Harstad med Harstad legevakt og UNN Narvik. 2. UNN Tromsø, Mosjøen, Sandnessjøen og Mo i Rana. 3. NLSH Bodø, NLSH Lofoten og Arcidis 4. UNN Ø-hjelp og UNN-PLO 5. NLSH Vesterålen med Vesterålen kommunale legevakt (seksjonsleder) I tillegg drifter seksjonen DIPS Applikasjonsservere, DIPS Message Broker servere og en rekke testservere. Totalt sett drifter seksjonen i skrivende stund ca 93 servere. 4 Definisjon av sannsynlighet, konsekvens og risikonivå I denne risikovurderingen bruker vi kvalitative verdier for sannsynlighet, konsekvens og risikonivå. 4.1 Sannsynlighet Ulike måter å definere sannsynlighetsnivåene på er vanlig, bl.a. ut fra: Frekvens: antall ganger en trussel forventes å inntreffe i forhold til antall ganger en tjeneste brukes, eller: antall ganger en trussel forventes å inntreffe i en gitt tidsperiode Letthet: hvor lett det er å bryte sikkerheten (utløse en trussel) for interne og eksterne personer Motivasjon: sannsynlighet basert på brukerens motivasjon (uaktsomhet, forsett og overlegg) og hvor interessant systemet/tjenesten eller informasjonen er Statistikk: sannsynlighet basert på erfaring fra tidligere bruk av dette eller liknende systemer/tjenester (f.eks. frekvens av hendelser) Vi har for denne risikovurderingen valgt fire nivå for sannsynlighet. I tabellen under er det vist definisjon av verdier for og beskrivelser av de ulike nivåene. Vi har bevisst valgt å ikke benytte Nasjonal IKT og Helse Nords definisjoner av frekvens. De skiller kun mellom det som skjer årlig eller sjeldnere og det som skjer flere ganger årlig. Tabell 1: Definisjon av sannsynlighetsnivå Sannsynlighet Svært høy Høy Moderat Liten Svært liten Frekvens Hendelsen inntreffer flere ganger i måneden Hendelsen inntreffer flere ganger årlig Hendelsen inntreffer årlig Hendelsen inntreffer hvert andre år eller sjeldnere Hendelsen forventes ikke å inntreffe i overskuelig framtid. 4.2 Konsekvens For definisjon av konsekvensnivåene kan også ulike kategorier benyttes, for eksempel forventet tap i antall kroner (f.eks. mulige erstatningskrav), at brukerens privatliv blir krenket, etc. Flere kategorier kan kombineres for hvert nivå, i og med at hvert nivå skal dekke konsekvenser for ulike sikkerhetstrusler og ulike målgrupper. For eksempel kan Alvorlig defineres som fare for uopprettelig økonomisk tap for systemeier og/eller alvorlig tap av anseelse og integritet for brukere, etc. 18

19 I tabellen under (Tabell 2) følger definisjon av konsekvensnivåene for denne risikovurderingen. Vi har valgt fem nivå for konsekvens. Tabell 2: Konsekvenskategorier med kriterier Konsekvens Svært alvorlig Alvorlig Moderat Liten Ubetydelig Kunden (HF) Uforsvarlig helsehjelp. Alvorlig lovbrudd, fengselsstraff/ foretaksstraff (tap av rett til å utøve virksomhet) Helsehjelp med utilstrekkelig kvalitet Vedvarende virkning for tillit og anseelse. Bøtestraff/ foretaksstraff (bot) Hinder for utøvelse av effektiv helsehjelp. Mindre alvorlig lovbrudd/ forseelse. Advarsel/ pålegg (som første reaksjon). Kortvarig hinder for utøvelse av effektiv helsehjelp. Ingen lovbrudd. Forbigående tap av tillit og anseelse. Irritasjonsmoment Systemeier/HN IKT Pasienter Økonomi Anseelse Økonomi Anseelse/ rykte/integritet Betydelig økonomisk tap. Uopprettelig Økonomisk tap. Uopprettelig Betydelig økonomisk tap. Kan gjenopprettes Økonomisk tap. Kan gjenopprettes Ingen økonomisk konsekvens Alvorlig tap av anseelse, ødeleggende virkning for tillit og respekt Alvorlig tap av anseelse. Vedvarende virkning for tillit og respekt. Tap av anseelse. Virkning for tillit og respekt Kortvarig tap av anseelse Ikke tap av anseelse Betydelig økonomisk tap. Uopprettelig Økonomisk tap. Uopprettelig Betydelig økonomisk tap. Kan gjenopprettes. Økonomisk tap. Kan gjenopprettes Ingen økonomisk konsekvens Alvorlig tap av anseelse/ integritet. Påvirker liv, helse eller økonomi Alvorlig tap av anseelse/ integritet Tap av anseelse/ integritet. Kompromittering av krenkende opplysninger Tap av anseelse/ integritet. Kompromittering av lite følsomme opplysninger. Intet tap av brukerens anseelse/integritet 4.3 Risikonivå Vi bruker en risikomatrise som verktøy for å beregne risikonivå. Risikomatrisen viser risikonivået for hver trussel som kombinasjonen av trusselens sannsynlighet og konsekvens. Matrisen under (Tabell 3) viser definisjon av de ulike risikonivå vi har valgt å benytte for denne risikovurderingen. Vi har her valgt å bruke tre risikonivå: Lav, Middels, Høy. Tabell 3: Risikomatrise med definisjon av risikonivå Konsekvens: Sannsynlighet: Ubetydelig Liten Moderat Alvorlig Svært alvorlig Svært liten Lav Lav Lav Lav Middels Liten Lav Lav Lav Middels Middels Moderat Lav Lav Middels Middels Høy Høy Lav Middels Middels Høy Høy Svært høy Lav Middels Høy Høy Høy 19

20 Risikonivåene har vi definert på følgende måte: Lav risiko: Trusler som har dette risikonivået aksepteres, men det bør rutinemessig vurderes om truslene endrer karakter og/eller bør følges nærmere opp. Åpenbare risikoreduserende tiltak vurderes. Middels risiko: Trusler som har dette risikonivået må det snarest innføres bedre rutiner for å håndtere, evt. må ytterligere analyse foretas. Tjenesten(e) kan etter vurdering fortsatt benyttes inntil risikoreduserende tiltak er iverksatt. Høy risiko: Ikke akseptabel risiko. Risikoreduserende tiltak må iverksettes før tjenesten kan benyttes videre, eventuelt må det gjøres midlertidige endringer som reduserer risikoen til middels risikonivå inntil tilstrekkelig sikkerhet er etablert. 4.4 Akseptkriterier Akseptkriteriene skal fortelle hva som er akseptabel risiko. En viss risiko må man som regel leve med. Husk at det å akseptere risikoen er ikke det samme som å akseptere den uønska hendelsen, at trusselen inntreffer. I denne rapporten kan vi bare formulere akseptkriterier basert på det vi har foreslått som definisjoner for sannsynlighet, konsekvens og risikonivå. Men akseptkriteriene bør diskuteres og formuleres sammen med kunden slik at de passer til den type tjeneste eller system analysen omfatter. Endringer i akseptkriteriene vil kunne føre til endringer i definisjonene foran. Våre definisjoner gir bl.a. følgende akseptkriterier: Høy risiko: Det er ikke akseptabelt: at det inntil en gang i året kan inntreffe en hendelse som enten o for HF medfører uforsvarlig helsehjelp o for HF innebærer alvorlig lovbrudd med fengselsstraff og/eller foretaksstraff som følge, med tap av rett til å utøve virksomhet o for HN IKT resulterer i et betydelig uopprettelig økonomisk tap o for HN IKT gir alvorlig tap av anseelse, med ødeleggende virkning for tillit og respekt o for brukeren resulterer i et betydelig uopprettelig økonomisk tap o for brukeren gir alvorlig tap av anseelse eller integritet, med påvirkning av liv, helse eller økonomi at det flere ganger årlig kan inntreffe en hendelse som enten o for HF medfører helsehjelp med utilstrekkelig kvalitet o for HF medfører foretaksbøter eller foretaksstraff o for HN IKT resulterer i et uopprettelig økonomisk tap o for HN IKT gir alvorlig tap av anseelse, med vedvarende virkning for tillit og respekt o for brukeren resulterer i et uopprettelig økonomisk tap o for brukeren gir alvorlig tap av anseelse eller integritet at det flere ganger i måneden kan inntreffe en hendelse som enten o for HF innebærer et mindre alvorlig lovbrudd eller forseelse med advarsel eller pålegg som en første reaksjon o for HF er til hinder for utøvelse av effektiv helsehjelp 20