Elektronisk meldingsutveksling i Helse Nord

Transcript Elektronisk meldingsutveksling i Helse Nord

Rapport fra risikovurdering
Elektronisk meldingsutveksling i Helse Nord
Versjon 1.0
26.10.2012
Eva Skipenes og Eva Henriksen
Nasjonalt senter for samhandling og telemedisin
Sammendrag
Denne risikovurderingen ble gjennomført i perioden okt.2011-april 2012.
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. 2011 – juni 2012.
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.
INNHOLDSFORTEGNELSE
SAMMENDRAG .............................................................................................................................................. 2
1
BAKGRUNN............................................................................................................................................ 4
1.1
1.2
OPPDRAGSBESKRIVELSE ........................................................................................................................ 4
GJENNOMFØRING ................................................................................................................................... 5
2
NASJONALE RETNINGSLINJER FOR MELDINGSTJENESTEN .................................................. 5
3
SYSTEM- OG TJENESTEBESKRIVELSE .......................................................................................... 6
3.1 DAGENS MELDINGSFLYT ........................................................................................................................ 7
3.1.1
Arbeidsgrupper og arbeidsflyt...................................................................................................... 8
3.1.2
Transport- og applikasjonskvittering .......................................................................................... 11
3.1.2.1
3.1.2.2
Kvitteringer for utgående meldinger .............................................................................................................11
Kvitteringer for innkommende meldinger .....................................................................................................12
3.1.3
Meldingsformater ...................................................................................................................... 13
3.2 PLO-MELDINGER ................................................................................................................................. 13
3.2.1
Håndtering av PLO-meldinger i Helse Nord .............................................................................. 14
3.2.2
Håndtering av PLO-meldinger i kommunene ............................................................................. 14
3.3 TJENESTEBASERT ADRESSERING ........................................................................................................... 15
3.3.1
Kommunikasjonsparter i NHN Adresseregister .......................................................................... 15
3.3.2
Tjenestebasert adressering i Helse Nord .................................................................................... 16
3.4 HN IKT DRIFT ..................................................................................................................................... 17
4
DEFINISJON AV SANNSYNLIGHET, KONSEKVENS OG RISIKONIVÅ .................................... 18
4.1
4.2
4.3
4.4
5
SANNSYNLIGHET ................................................................................................................................. 18
KONSEKVENS ...................................................................................................................................... 18
RISIKONIVÅ ......................................................................................................................................... 19
AKSEPTKRITERIER ............................................................................................................................... 20
TRUSSELIDENTIFISERING OG -ANALYSE ................................................................................... 22
5.1
5.2
5.3
TRUSLER MED HØY RISIKO ................................................................................................................... 22
TRUSLER MED MIDDELS RISIKO ............................................................................................................ 23
TRUSLER MED LAV RISIKO .................................................................................................................... 29
6
ANBEFALTE TILTAK ......................................................................................................................... 29
7
KONKLUSJON ..................................................................................................................................... 31
REFERANSER ............................................................................................................................................... 32
VEDLEGG A TRUSSELTABELL ................................................................................................................ 33
VEDLEGG B: SYSTEMBESKRIVELSE FRA HN IKT .............................................................................. 43
B.1
SYSTEM I HELSEFORETAKENE .......................................................................................................... 43
B.1.1 System involvert i meldingsutveksling ........................................................................................ 43
B.1.2 Meldingstyper og -format ........................................................................................................... 44
B.1.3 Meldingsflyt ............................................................................................................................... 45
B.2
SYSTEM VED LEGEKONTOR OG HOS SPESIALISTER ............................................................................ 48
VEDLEGG C: STATUS FOR OPPFYLLELSE AV MELDINGSKRAV.................................................... 49
3
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:
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.
Avgrensning
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

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 7.0.
1.2 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. 2011 – april 2012.
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 2010-2011.
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 1.1.2012. Dette
innebærer at NHN skal ivareta mange av de behovene som i 2010-2011 ble dekket av
Meldingsløft-strukturen og dets etablerte nettverk.
5
Dokumentet ”Minstekrav til elektronisk meldingsutveksling” ble utviklet av en arbeidsgruppe
under Nasjonalt meldingsløft våren 20111. 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 Nord3.
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, 2011
Helsedirektoratet, Norm for informasjonssikkerhet i helse-, omsorgs- og sosialsektoren: ”Krav til elektronisk
meldingsutveksling”, Versjon 1.0, 1. desember 2011
3
Kilde: Odd-Arne Olsen, HN IKT
2
6
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
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-melding4.
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.
3.1.1 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
4
http://www.kith.no/templates/kith_WebPage____2467.aspx (sist sett 20.04.2012)
8
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
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
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.
3.1.2 Transport- og applikasjonskvittering
3.1.2.1 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
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.
3.1.2.2 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
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 2012.
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 23.04.12. 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
01.01.2012. 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 pleieog
omsorgssektoren og helseforetak5:
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: 2011
13
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.
3.2.1 Håndtering av PLO-meldinger i Helse Nord
PLO-meldingene har vært pilotert ved to avdelinger på UNN i 2011. 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 pleieog omsorgssektoren benytter PLO-meldinger mot helseforetaket for.
3.2.2 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
pleieog 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
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 pleieog
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 2008-2012, to dokumenter vedrørende adressering. Disse dokumentene var på
høring blant alle arbeidsgruppens medlemmer høsten 2009:
- Publisering av kommunikasjonsparter i spesialisthelsetjenesten (HEMIT/23.09.09)
- Organisasjonstyper Adresseregisteret (KITH/22.09.09)
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 14.12.09:
- Publisering av kommunikasjonsparter i spesialisthelsetjenesten (Helsedir./25.11.09).
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åde6
8654 – Klinisk/medisinsk service7.
Tilsvarende kodeverk som skal benyttes for tjenester i kommunene er:
8663 Kommunale helseog sosialtjenester.8
3.3.1 Kommunikasjonsparter i NHN Adresseregister
NHN Adresseregister inneholder en oversikt over kommunikasjonsparter i helse-, pleieog
omsorgssektoren. Kommunikasjonsparter som omfattes av begrepet tjenestebasert adressering
kan være helsetjenester i kommunen eller kliniske/medisinske tjenester i spesialisthelse6
http://www.volven.no/produkt.asp?id=178281&catID=3&subID=8 (sist sett 13.04.12)
http://www.volven.no/produkt.asp?id=178280&catID=3&subID=8 (sist sett 13.04.12)
8
http://www.volven.no/produkt.asp?id=178677&catID=3&subID=8 (sist sett 16.04.12)
7
15
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. 3.1.2.
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.
3.3.2 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
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 2012. 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:




12-14 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 70.000 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
1.
2.
3.
4.
5.
Kirkenes, Hammerfest, UNN Harstad med Harstad legevakt og UNN Narvik.
UNN Tromsø, Mosjøen, Sandnessjøen og Mo i Rana.
NLSH Bodø, NLSH Lofoten og Arcidis
UNN Ø-hjelp og UNN-PLO
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
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
Systemeier/HN IKT
Økonomi
Anseelse
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
Økonomi
Pasienter
Anseelse/
rykte/integritet
Betydelig
økonomisk tap.
Uopprettelig
Alvorlig tap av
anseelse,
ødeleggende
virkning for tillit og
respekt
Betydelig
økonomisk
tap.
Uopprettelig
Alvorlig tap av
anseelse/
integritet. Påvirker
liv, helse eller
økonomi
Økonomisk tap.
Uopprettelig
Alvorlig tap av
anseelse.
Vedvarende
virkning for tillit og
respekt.
Økonomisk
tap.
Uopprettelig
Alvorlig tap av
anseelse/
integritet
Betydelig
økonomisk tap.
Kan
gjenopprettes
Tap av anseelse.
Virkning for tillit og
respekt
Betydelig
økonomisk
tap. Kan
gjenopprettes.
Tap av anseelse/
integritet.
Kompromittering
av krenkende
opplysninger
Økonomisk
tap. Kan
gjenopprettes
Tap av anseelse/
integritet.
Kompromittering
av lite følsomme
opplysninger.
Ingen
økonomisk
konsekvens
Intet tap av
brukerens
anseelse/integritet
Økonomisk tap.
Kan
gjenopprettes
Ingen
økonomisk
konsekvens
Kortvarig tap av
anseelse
Ikke tap av
anseelse
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
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
o
o
o
o
for HN IKT resulterer i et betydelig, men gjenopprettelig, økonomisk tap
for HN IKT gir tap av anseelse, med virkning for tillit og respekt
for brukeren resulterer i betydelig, men gjenopprettelig, økonomisk tap
for brukeren gir tap av anseelse eller integritet og kompromittering av
krenkende opplysninger
På den annen side:
Lav risiko: Det er akseptabelt:

at det hvert andre år 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
o for HN IKT resulterer i et betydelig, men gjenopprettelig, økonomisk tap
o for HN IKT gir tap av anseelse, med virkning for tillit og respekt
o for brukeren resulterer i betydelig, men gjenopprettelig, økonomisk tap
o for brukeren gir tap av anseelse eller integritet og kompromittering av
krenkende opplysninger

at det inntil en gang i året kan inntreffe en hendelse som enten
o for HF er til kortvarig hinder for utøvelse av effektiv helsehjelp
o for HN IKT resulterer i et gjenopprettelig økonomisk tap
o for HN IKT gir tap av anseelse, med virkning for tillit og respekt
o for brukeren resulterer i gjenopprettelig økonomisk tap
o for brukeren gir tap av anseelse eller integritet og kompromittering av lite
følsomme opplysninger

at det flere ganger i måneden kan inntreffe en hendelse som
o for HF bare er et irritasjonsmoment, og
o for HN IKT ikke har noen økonomisk konsekvens
o for HN IKT ikke gir noe tap av anseelse
o for brukeren ikke har noen økonomisk konsekvens
o for brukeren ikke gir tap av anseelse eller integritet
21
5 Trusselidentifisering og -analyse
Truslene vi har identifisert gjennom møte og intervju med personell i HN IKT og andre
virksomheter er listet opp i en tabell med tilhørende årsak, sannsynlighet, konsekvens,
risikonivå mm. i Vedlegg A. Totalt ble det identifisert 48 mulige trusler. Fire av disse anses
som uaktuelle på det nåværende tidspunkt.
Truslene er plassert i ei risikomatrise for å visualisere risikonivået til den enkelte trussel og
det samlede risikobildet. Truslene med høy og middels risiko presenteres i separate
underkapitler.
Tabell 4: Risikonivå for identifiserte trusler9
Konsekvens:
Sannsynlighet:
Ubetydelig
Liten
Moderat
Alvorlig
Svært liten
1, 2, 3, 5, 26,
28, 30, 31
Liten
4, 21, 23, 24
Moderat
10, 38
Høy
9, 11, 19, 19b,
33, 37, 44
Svært høy
12, 13, 18, 32,
39
Svært
alvorlig
6, 22, 25, 34,
35, 36
14, 15, 17,
17b, 27, 42,
43, 45
7, 8, 16, 20
Som vi ser av matrisa har 4 trusler høy risiko, og 30 trusler middels risiko. Truslene som er
vurdert til å ha et uakseptabelt risikonivå er markert med fet skrift (hvit eller sort).
5.1 Trusler med høy risiko
Trusler med høy risiko er definert som uakseptable. Truslene identifisert med dette risikonivået omfatter i stor grad trusler knyttet til overvåkning av status for meldingstrafikken, både
med hensyn til dokumentasjon av prosedyrer og bruk av ebXML-rammeverket inkludert
transport- og applikasjonskvitteringer for alle meldingstyper.
Truslene 7, 8 og 20 handler om mangelfull dokumentasjon av prosedyrer for å overvåke
kvitteringsstatus på meldingene, både med hensyn til transportkvitteringer og applikasjonskvitteringer. HN IKT har ansvar for å følge opp meldingsstatus for en del av meldingstypene,
mens avdelingene på det enkelte HF har ansvar for å følge opp meldingsstatus for noen
meldingstyper. Applikasjonskvitteringer skal i hovedsak overvåkes av de kliniske avdelingene
og laboratoriene etc., men det har vært vanskelig å få oversikt over hvem som har ansvar for
hva, da det tilsynelatende ikke finnes en samlet og oversiktlig dokumentasjon av rutinene.
UNN har utarbeidet veilederen ”Retningslinjer for sending og mottak av elektroniske Pleieog omsorgsmeldinger (PLO) meldinger mellom Universitetssykehuset Nord Norge og Tromsø
kommune”. Veilederen er tilgjengelig i DocMap (RL2551) og beskriver rutinene for sending
og mottak av elektroniske PLO-meldinger og håndtering av feilmeldinger. I hvilken grad slik
dokumentasjon finnes på de kliniske avdelingene mht status for utgående epikriser og
polikliniske notat er noe mer uklart for oss, men vi antar at slike finnes tilgjengelig i DocMap.
9
Følgende trusler er ikke med i matrisa fordi de er uaktuelle (NA) for denne analysen: 29, 40, 41, 46
22
Laboratoriene har tilsynelatende dokumenterte rutiner for oppfølging av meldingsstatus.
Utfordringen med hensyn til manglende dokumentasjon av rutiner og prosedyrer gjelder
sannsynligvis først og fremst for HN IKTs ansvarsområde.
Det er spesielt mangelen på dokumenterte prosedyrer hos HN IKT som vil være en utfordring,
og da først og fremst i forbindelse med sykdom og annet fravær av nøkkelpersonell, og ved
nytilsettinger. Ved avvik vil det også kunne være en utfordring å finne ut hvem som eventuelt
ikke har oppfylt sitt ansvar dersom prosedyrene for overvåkning ikke er klart dokumentert.
Trussel 16 handler om at lab- og røntgensvar blir liggende i meldingsintegratoren (f.eks.
WinMed Connect) på mottakende legekontor pga. feil i meldingen, og at personellet på
legekontoret ikke oppdager at meldingene ikke kommer inn i fastlegenes fagsystem. Dette
gjelder spesielt meldinger som ikke har applikasjonskvitteringer. Da vil heller ikke avsender
være i stand til å oppdage at meldingene ikke når helt fram til mottaker. Personellet på
legekontorene har ansvar for å følge opp meldinger som blir liggende i meldingsintegratoren,
men ikke alle har den nødvendige forståelsen av å gjøre dette. Det kan også være manglende
kunnskap om hvordan tilbakemelding skal gis til avsender med beskjed om type feil i
meldingen slik at avsender kan generere ny korrekt melding. Håndtering av disse feilene hos
mottaker er strengt tatt ikke HN IKT eller HF-enes ansvar. HF-ene har på den annen side
ansvar for å sørge for at ebXML-rammeverket tas i bruk for alle typer meldinger, inkludert
transport- og applikasjonskvittering for alle meldinger.
5.2 Trusler med middels risiko
Trusler med middels risikonivå må analyseres ytterligere og kan da ende opp som enten
akseptable eller uakseptable. Men felles for dem alle er at de snarest bør vurderes. Tjenesten
kan etter vurdering fortsatt benyttes inntil risikoreduserende tiltak er iverksatt
Her omtales truslene med middels risiko ut fra hvor alvorlige de antas å være. De med størst
konsekvens omtales først. For hver av truslene angis det om vi vurderer dem som akseptable
eller ikke.
Trussel 6 handler om at melding vises/presenteres feil hos mottaker slik at misforståelser kan
oppstå. Bl.a. gjelder dette dersom meldingen inneholder tabeller. Dette kan skyldes at
virksomheten ikke sørger for at det gjennomføres verdikjedetesting for å påse at
presentasjonen (visningen) av innholdet i meldingen er riktig hos avsender og mottaker, noe
som skal gjøres i hht krav 20 i Normens kravdokument ”Krav til elektronisk
meldingsutveksling” [3]. – Dette er ikke bare et problem for WinMed (journalsystem på
legekontor) men også for pleieog omsorgssystemene (f.eks. Profil). Det skal komme en
oppdatert DIPS Communicator som skal fikse dette problemet. Men inntil denne er på plass
og det er testet og dokumentert at visningene er tilfredsstillende i alle mottakende systemer,
anser vi risikoen som uakseptabel.
Trussel 22 handler om at HN IKT muligens har for få ressurser med god kompetanse til å
overvåke status for meldingstrafikken. HN IKT har personell med god kompetanse på slik
overvåkning, men ved sykdom og annet fravær kan det være sårbart med hensyn til å ha
tilstrekkelig med personell som har kompetanse på overvåkning av alle de ulike deler av
meldingstrafikken. Sårbarheten gjør dette til en trussel med alvorlig konsekvens, og risikoen
anses derfor som uakseptabel.
Trussel 25 handler om manglende dokumentasjon av prosedyrer for til hvem og hvordan
avvik i meldingstrafikken skal varsles, slik at feil raskt kan rettes og gjentakelser unngås.
23
Manglende dokumentasjon av prosedyrer kan i verste fall medføre alvorlig konsekvens, og
risikoen anses derfor som uakseptabel.
Truslene 34, 35 og 36 handler alle om risikoen for at meldinger ikke kommer fram til riktig
mottaker internt i helseforetaket etter at tjenestebasert adressering er innført. Dette kan
skyldes at aktuelle tjenester/helsehjelpsområder for helseforetaket ikke er registrert i NHN
Adresseregister (34), eller at avsender ikke har oppdatert sin lokale kopi av adresseregisteret i
sitt fagsystem (35). Årsaken kan også være at avsender velger feil tjenesterekvirent, og at
meldingen havner i feil arbeidsgruppe i foretaket (36). Avsender får positiv applikasjonskvittering og er derfor uvitende om at meldingen har havnet hos feil mottaker. Dette skal
håndteres av mottaker i helseforetaket. Avdelingene har rutiner for å håndtere mottak av
feiladresserte meldinger (meldinger som skulle vært sendt til en annen avdeling). De som
oppdager meldinger som skulle til en annen avdeling, er pliktig til å videresende til riktig
arbeidsflyt i DIPS (eller på annen måte). Noen i HF-et og/eller HN IKT har som oppgave å
sjekke Udefinert arbeidsflyt. Dette praktiseres imidlertid forskjellig fra foretak til foretak.
Konklusjonen er at det mangler entydige rutiner. UNN har utarbeidet et sett med rutiner i
veilederen ”Retningslinjer for sending og mottak av elektroniske Pleie- og omsorgsmeldinger
(PLO) meldinger mellom Universitetssykehuset Nord Norge og Tromsø kommune”. I DIPS
7.0 kommer varsel fra Message Broker i den enkelte avdelings arbeidsflyt ved negativ eller
manglende applikasjonskvitteringer. Inntil DIPS 7.0 tas i bruk må helsepersonellet se i
korrespondanseloggen for å se status for PLO-meldingene. På UNN har de fått opplæring om
dette fra Gro Wangensteen. Før DIPS 7.0 kommer kan ikke helsepersonellet sjekke status for
utsendte epikriser selv. Dette må gjøres av HN IKT. Mange avdelinger sender derfor
papirkopi av epikriser med pasienten for sikkerhets skyld. Fra avdelingene kan de se i DIPS at
epikrisen er sendt men har ikke mulighet til å sjekke om den er kommet fram. Felles
Kontortjenester UNN (NST) følger med på om det mottas negative applikasjonskvitteringer
og re-sender epikrisene fra UNN. Dette gjelder muligens ikke sykepleierepikriser. Hvilke
rutiner de andre helseforetakene har er ukjent for oss. Se krav om varsling av negative
applikasjonskvitteringer i KITH-rapporten 15/04:2012 ”Applikasjonskvittering”.10
Dette er trusler som forventes å bli tatt hånd om når tjenestebasert adressering innføres, og
risikoen for disse kan derfor anses som akseptabel. Det er likevel viktig å følge med på disse
truslene ved innføring av tjenestebasert adressering, for å være sikker på at de blir ivaretatt på
en tilfredsstillende måte.
Trussel 4 handler om at det kan oppstå ulike typer feil etter oppdatering eller innføring av nye
meldingstyper. Årsaken kan være at leverandørene ikke sørger for testing mot og godkjenning
fra det nasjonale standardiseringsorganet for meldinger. Dette har spesielt vært et problem i
ProfDoc Vision. Risikoen for denne trusselen må man bare akseptere, da dette spesielle
legekontorsystemet etter hvert vil fases ut og ikke bli oppgradert med ny funksjonalitet.
Krav 19 i Normens kravdokument ”Krav til elektronisk meldingsutveksling” [3] sier at alle
meldingstyper som tas i bruk av virksomhetene skal være testet og godkjent av det nasjonale
standardiseringsorganet for meldinger. Det er virksomhetens ansvar å forvisse seg om at dette
er gjort. Helseforetakene (og HN IKT) mangler gode testomgivelser.
Trussel 21 handler om manglende opplæring av personell som har ansvar for overvåkning av
meldingstrafikken. Selv om sannsynligheten for dette er liten, er konsekvensen alvorlig,
Manglende dokumentasjon av prosedyrer for overvåkning av meldingstrafikken påvirker
denne trusselen i negativ retning, og risikoen for denne trusselen er derfor uakseptabel..
10
http://www.kith.no/upload/6466/R15-04-2012_AppRec-v1_1-2012-02-15.pdf
24
Trussel 23 handler om manglende tilgjengeliggjøring overfor kommunikasjonsparter av
kontaktinformasjon for feilsøking. Kommunikasjonspartene vil måtte bruke unødig mye tid på
å finne årsakene til feil i meldingstrafikken dersom de ikke enkelt kan finne kontaktinformasjon til de som kan kontaktes ved feilsituasjoner. Risikoen for denne trusselen anses
derfor som uakseptabel.
Trussel 24 handler om at det ikke er gode nok rutiner som sørger for at meldinger blir sendt
på nytt ved feil. HN IKT har teknisk løsning ved manglende transportkvittering. Manglende
eller negativ applikasjonskvittering er det avsenders ansvar å håndtere. I foretakene blir dette
imidlertid lettere å oppdage ved innføring av DIPS 7.0, slik at risikoen i mellomtiden kan
aksepteres.
Truslene 14 og 15 handler begge om at meldinger fra HF blir avvist hos legekontorets fagsystem (HF oppdager negativ eller manglende applikasjonskvittering). For trussel 14 kan
årsaken være at avsender har benyttet legekontoret og ikke legen som mottaker. – HN IKT
prøvde å fjerne dette fra UNN, men de ville ha det tilbake. Noen legekontor vil også ha det
slik, f.eks. der det skiftes lege ofte og legekontoret ikke sender oppdatert HPR-nr. HER-ID må
da brukes, og meldingen må håndteres manuelt i meldingstjeneren (DIPS Communicator)
eller meldingsintegratoren (f.eks. WinMed Connect) hos legekontoret.
I trussel 15 blir meldinger fra HF liggende i meldingsintegratoren på mottakende legekontor
av ulike andre årsaker, f.eks. fordi pasienten ikke er registrert i legekontorets journalsystem, at
fastlegen som er oppgitt i meldingen ikke (lenger) jobber ved legekontoret eller at
personnummeret til pasienten ikke er fullstendig. Personellet på legekontorene har ansvar for
å følge opp meldinger som blir liggende i integratoren, men det er svært varierende kunnskap
innen dette området hos hjelpepersonellet på legekontorene (Jf. trussel 16 i avsnitt 5.1 foran).
Meldinger som har kommet feil (pasienten finnes ikke i legekontorets pasientlister,
eksempelvis fordi pasienten har byttet fastlege) skal returneres. Dette gjøres fra meldingsintegratoren. Dersom hjelpepersonellet ønsker å skrive en kommentar om årsaken til
avvisningen av meldingen, må den originale meldingen hentes opp i meldingstjeneren (eks.
DIPS Communicator). Dette er mest aktuelt for meldinger som er feilsendt fra legevakt, i og
med at helseforetakene har mulighet for å søke opp pasientens fastlege direkte. Hjelpepersonellet gir uttrykk for at de har behov for mer opplæring i den tekniske håndteringen av
meldingsflyten, bl.a. mht. hva de skal gjøre med meldinger til leger som har sluttet ved
legekontoret. Dersom meldingene ikke blir videreformidlet til en annen lege, er det ingen
leger som leser og behandler disse meldingene. Det er gjerne et åpent spørsmål hvem som
skal være ansvarlig for slik opplæring, men HN IKT er sannsynligvis den aktøren som har
best forutsetning for å gi den nødvendige opplæringen.
Dette er problem som først og fremst må løses på legekontorsiden; risikoen for disse truslene
kan da anses som akseptabel for HN IKT sitt vedkommende.
Trussel 17 handler om utilfredsstillende håndtering av meldinger til røntgensystem og labsystem pga. mangelfulle tekniske løsninger og rutiner for å følge opp rekvisisjoner med feil,
f.eks. ugyldig fødselsnummer, manglende HPR-nummer eller feil mottakeradresse.
Røntgenavdelingen legger inn manglende informasjon manuelt, og her gjøres det ofte feil.
Trusselen er en medvirkende årsak til trussel 17b.
Trussel 17b handler om at røntgensvar sendes til feil mottaker fordi rekvisisjonen inneholdt
manglende eller feil rekvirentkode. Manuell innsetting av rekvirentkoden medfører ofte at feil
rekvirentkode blir valgt, med den følge at feil rekvirent mottar svaret eller at svaret blir
liggende i en ikke-aktiv arbeidsflyt i helseforetaket i inntil tre måneder. Det anses som
uakseptabelt at svar kan bli liggende ulest så lenge. Et mulig tiltak kan være hyppigere
gjennomgang av ikke-aktive arbeidsflyter, og hyppigere oppdatering av rekvirentregisteret.
25
Trussel 27 handler om brukerfeil som bl.a. kan forårsake valg av feil mottaker av en melding,
at PLO-meldinger sendes fra kommunen til foretaket før pasienten er innlagt, at legekontor
ikke har oppdatert sine rekvirentdata i Adresseregisteret etc. Dette er sannsynligvis utenfor
HN IKT sitt ansvarsområde, men vil kunne påvirke meldingsflyten. Risikoen anses som
akseptabel for HN IKT sitt vedkommende.
Trussel 42 handler om at meldinger fra legekontor eller pleieog omsorgssektoren blir avvist
i meldingstjener i foretaket slik at det sendes negativ transportkvittering ut fra foretaket.
Mange legekontor leser ikke inn mottatte partnerdefinisjoner som er sendt fra foretaket, for
eksempel med opplysning om endring i sykehusets krypteringssertifikat. HN IKT sjekker
negative transportkvitteringer ut fra HF. Dette følges opp fortløpende innenfor ordinær
arbeidstid og oppdages straks, men det kan gå noen dager i forbindelse med helg og
helligdager uten at dette blir oppdaget. I den grad dette er et problem som raskt oppdages og
håndteres, kan risikoen være akseptabel. Det kan imidlertid bli en mer alvorlig konsekvens
dersom det går lang tid før feilen håndteres, spesielt hvis dette gjelder PLO-meldinger fra
pleieog omsorgssektoren. Vi mener derfor at trusselen er uakseptabel.
Trussel 43 handler om at meldinger fra legekontor eller pleieog omsorgssektor blir avvist i
fagsystemet i foretaket slik at det sendes negativ applikasjonskvittering ut fra foretaket.
Årsaker kan bl.a. være at melding inneholder hjelpenummer i stedet for personnummer, feil i
XML, feil i EDI-oppsett på partnerne eller at rekvirent (avsender-lege) ikke er registrert i
fagsystemet fordi legekontoret har glemt å melde fra om nye leger. Feilene oppdages som
regel raskt av HN IKT og rettes, men de har ikke gode nok verktøy for å varsle mulige
feilsituasjoner. Det kreves manuell årvåkenhet for å oppdage enkelte av disse feilsituasjonene.
Når HN IKT oppdager feilen, må de be legekontoret sende info om nye leger til
”[email protected]”, ev. oppdatere NHN Adresseregister med ny lege (når
FRESH-Connector tas i bruk for å hente eksterne rekvirentadresser inn i DIPS), hvis det er
dette som er årsaken. Når dette er gjort kan feilet-melding rearkiveres.
I den grad dette er et problem som raskt oppdages og håndteres, kan risikoen være akseptabel.
Det kan imidlertid bli en mer alvorlig konsekvens dersom det går lang tid før feilen håndteres.
PLO-meldinger med informasjon om nylig innlagte pasienter kan bli liggende i to døgn hvis
de kommer i løpet av helga og feiler på denne måten. Avsender kan ha mottatt positiv
applikasjonskvittering dersom meldingen havnet i Udefinert arbeidsflyt, og vil ikke selv
oppdage at meldingen ikke har kommet fram til rett mottaker i HF-et. Vi mener derfor at
trusselen er uakseptabel.
Trussel 45 handler om utfordringene knyttet til å velge riktig meldingsmottaker i kommunens
pleieog omsorgssektor når tjenestebasert adressering mot kommunene tas i bruk.
Kommunene organiserer PLO-tjenestene ulikt, slik at det ikke vil være en enhetlig struktur på
tvers av kommunene med hensyn til hvilket helsehjelpsområde meldinger om den enkelte
pasient skal adresseres til. Valg av feil tjenestemottaker vil kunne medføre at de som skal ha
meldingen om pasienten i kommunen ikke får den, og at de som får den i sin tjeneste-innboks
ikke vil være i stand til å se meldingen fordi de ikke er autorisert for å se meldinger av den
gitte typen knyttet til denne pasienten. – Dette er problem som i hovedsak må løses på
kommunesiden (kontroll av at meldinger kommer til riktig mottakergruppe), men det er også
viktig at helsepersonell på HF-ene får nødvendig opplæring til å kunne velge riktig tjeneste
hos den enkelte kommune. Risikoen for trusselen kan da anses som akseptabel for HN IKT
sitt vedkommende.
Truslene 12 og 13 handler om de tilfellene der meldinger fra foretaket blir avvist i legekontorets fagsystem slik at det sendes negativ applikasjonskvittering tilbake. Den negative
applikasjonskvitteringen kan skyldes at pasienten er ukjent hos legekontoret (trussel 12), fordi
26
avsender kan ha valgt feil fastlege som mottaker. I andre tilfeller kan den negative
applikasjonskvitteringen inneholde begrunnelsen at legen er ukjent ved legekontoret, selv om
riktig lege er valgt (trussel 13). Dette siste skjer stadig vekk, og særlig i feriene: Hvis fastleger
som bruker Profdoc Vision (eller enkelte versjoner av Infodoc) har markert i journalsystemet
at de er på ferie, sendes det negativ applikasjonskvittering om at lege er feil. – Det er uklart
hvilke rutiner legekontorene har for å følge opp meldinger som blir liggende i meldingstjeneren. (Jf. beskrivelse av trussel 16 i avsnitt 5.1 og truslene 14 og 15 foran).
I tillegg til at avdelingene i HF har ansvar for å følge med på applikasjonskvitteringene, er
dette et problem som først og fremst må løses på legekontorsiden, der Profdoc Vision etter
hvert vil fases ut og ikke bli oppgradert med ny funksjonalitet. – Risikoen for disse truslene
kan anses som akseptabel for HN IKT sitt vedkommende.
Trussel 18 handler om at meldinger ikke kommer fram til intern mottaker i helseforetaket så
raskt som mulig. Dette kan bl.a. skyldes manglende rutiner for håndtering av meldinger i
Udefinert arbeidsflyt, spesielt når antall meldinger øker (f.eks. som følge av ”bredding” av
PLO-meldinger til alle avdelinger ved HF-ene og alle kommuner i regionen). Med dagens
meldingsmengde anses dette som en akseptabel risiko, men den vil kunne bli uakseptabel ved
økende meldingstrafikk. Inntil den nye meldingstypen for henvisning mellom foretak blir tatt i
bruk, er det også en utfordring med ruting av innkommende henvisninger fra andre HF, som
også havner i Udefinert arbeidsflyt.
Trussel 32 henger sammen med trussel 18, og handler om at personell hos HN IKT må lese
sensitive pasientopplysninger i innkommende henvisninger fra andre HF, fordi de havner i
Udefinert arbeidsflyt og må rutes manuelt til riktig arbeidsgruppe internt. Denne trusselen vil
høyst sannsynlig elimineres når meldingstypen Henvisning blir innført mellom foretak (og
HF-ene tar i bruk DIPS 7.0). Risikoen anses derfor som akseptabel.
Trussel 39 handler om utfordringene knyttet til at DIPS ikke kan hente oversikt over HER-ID
for egne interne tjenesterekvirenter fra NHN Adresseregister, fordi DIPS ikke har noe forhold
til tjenestebegrepet internt. En mapping-tabell for ruting mellom HER-ID og interne
organisasjonsenheter/avdelinger er nødvendig for å rute innkommende meldinger dit de skal
når tjenestebasert adressering innføres. Denne tabellen må populeres manuelt, og dette
innebærer en risiko for feilregistreringer. Funksjonalitet for en slik mapping-tabell kommer i
DIPS 7.0. Risikoen anses som akseptabel.
Trussel 9 handler om at meldinger fra HF blir avvist av legekontorets (eller kommunens)
meldingstjener pga at mottaker ikke har oppdatert sertifikatinformasjon og EDI-adresse i
NHN Adresseregister, eller ikke har oppdatert partnerdefinisjoner fra HF-et (enten tilsendt via
e-post eller via NHN Adresseregister). Dette oppdages ved at transportkvittering ikke mottas,
men det skaper en god del plunder og heft for HN IKT fordi mottaker gjerne må kontaktes via
telefon og gjøres oppmerksom på problemet. Ofte må HN IKT bidra med support overfor
legekontor eller kommune for å rette opp feilen. Når legekontorenes og pleieog omsorgssektorens fagsystem blir klargjort for å laste opp eksterne rekvirentadresser automatisk, vil
denne trusselen reduseres betydelig (men de må kanskje fortsatt ha hjelp for å endre
sertifikatinfo ved fornying av sertifikatet). Risikoen anses som akseptabel.
Trussel 11 handler om at meldinger blir avvist av legekontorets (eller kommunens) fagsystem
pga. manglende HPR-nr for avsender i meldingen, og at mottakende fagsystem krever slikt
HPR-nr. Negativ applikasjonskvittering mottas. Meldinger som stoppes i innlesningsmodulen
må legges manuelt inn i fagsystemet, og da sendes det en positiv applikasjonskvittering. (Jf.
beskrivelse av truslene 12 og 13 foran). – Som for truslene 12 og 13, anses risikoen for denne
trusselen også som akseptabel for HN IKT sitt vedkommende.
27
Trussel 19 handler om at innkommende meldinger ikke kommer fram til intern mottaker så
raskt som mulig pga kapasitetsproblemer i DIPS Communicator. Det er stor usikkerhet knyttet
til konsekvensene av økt meldingsmengde, bl.a. som følge av full ”bredding” av PLOmeldinger i alle avdelinger i foretakene og i alle tilhørende kommuner. Det er vanskelig å
anslå hvor store forsinkelser det vil kunne medføre at Communicator blir overbelastet, og om
dette eventuelt vil føre til andre uforutsette følgeproblemer. På UNN rutes ø-hjelpsmeldinger
til en egen Communicator for hastemeldinger. Meldinger som er merket som hastemeldinger
vil derfor ikke bli påvirket av økningen i andre typer meldinger. Noen fastlegesystem (System
X) har imidlertid ikke mulighet til å adressere meldinger med hastegrad. Med dagens
meldingsmengde anses dette som en akseptabel risiko, men den vil i verste fall kunne bli
uakseptabel ved økende meldingstrafikk. Det bør vurderes om det skal innføres en separat
Communicator for ø-hjelp på NLSH også. For Helgelandssykehuset og Helse Finnmark
forventes det ikke at meldingsmengden vil bli så stor at det vil føre til kapasitetsproblemer.
Trussel 19b handler om stans i meldingstrafikken i opptil 8 timer ved kjøring av rapport for å
sjekke infeksjonsregistrering i DIPS (rapport D7377), dersom rapporten omfatter hele
helseforetaket og ikke begrenses til en avdeling eller klinikk. Rapporten skal ikke kjøres på
dagtid uten begrenset omfang (lokalisering), men det hender at dette gjøres likevel. Dette tar
ressurser fra applikasjonsserveren som håndterer PLO-meldingene, da at rapportkjøringen
benytter samme server som PLO-Communicator. Problemet oppstår ikke hvis man kjører
rapporten for kun en gitt avdeling. Kjøring av foretakskomplett rapport påvirker webservicen
som hjelper med utsending av PLO-meldinger. Meldingene blir lagt i kø i påvente av at
kjøring av rapporten blir ferdig. I DIPS ser det ut som om meldingene er sendt, men mange av
meldingstypene stopper i DIPS Communicator. Noen meldinger går ut likevel, og dette gjør
det vanskelig å oppdage problemet. PLO-meldinger til kommunehelsetjenesten blir forsinket,
og helsepersonellet som oppdager at meldingene stanser, må bruke tid på å ringe til
mottakerne og formidle informasjonen i meldingene muntlig.
Trussel 33 handler om at epikriser og henvisninger adressert med HER-ID ikke kan håndteres
av DIPS EPJ/PAS 6.xx. Dersom legekontor eller kommuner begynner å adressere til
helseforetakene med HER-ID i stedet for org.nr. før foretakene har tatt i bruk DIPS 7.0, vil
meldingene bli avvist. Det samme gjelder hvis meldinger fra kommuner og fastleger
inneholder avsenders HER-ID i stedet for HPR-nr og/eller org.nr. Konsekvensen av dette vil
være stor, men vi antar at sannsynligheten for at dette skjer er relativt liten. Risikoen anses
som akseptabel. Vi antar at kommunikasjonspartene venter til HF-ene gir beskjed om at de er
klare til å motta henvisninger o.l. med HER-ID før de begynner å sende slike. Det er dog noe
usikkerhet knyttet til WinMed 3.0 med hensyn til om dette fagsystemet kan sende meldinger
både med HPR-nr og meldinger med HER-ID parallelt til ulike mottakere. eResept krever
HER-ID i meldingene, og ble innført på legekontorene i UNN-området medio mai 2012.
Trussel 37 handler om at DIPS EPJ/PAS ikke støtter kommunikasjonsparter av typen
tjenesterekvirenter i spesialisthelsetjenesten. En mappingtabell må benyttes i Message Broker
mellom HER-ID for tjenesten og avdelingskode for avdelingen som tilbyr tjenesten. Slik
funksjonalitet er utviklet for DIPS 7.0, men krever manuell innlegging og oppdatering. Dette
innebærer en viss risiko for feil og inkonsistens sammenlignet med det som er registrert i
NHN Adresseregister. Risikoen anses imidlertid som akseptabel., men det er viktig at den
følges nøye opp etter innføring av tjenestebasert adressering.
Trussel 44 handler om at melding fra legekontor blir avvist av fagsystemet i foretaket pga.
ukjent fødselsnummer på pasient. Dette er noe HF har rutiner for å ta seg av, f.eks. ved å
fjerne personnummeret og sette meldingen tilbake i meldingsflyten. Konsekvensen for denne
trusselen anses derfor som liten, selv om slike hendelser inntreffer ofte, og risikoen anses som
akseptabel.
28
5.3 Trusler med lav risiko
Trusler med lav risiko er akseptable. Det bør likevel holdes øye med også disse truslene fordi
en økning av sannsynlighet kan øke risikoen til middels og dermed kanskje gjøre truslene
uakseptable.
6 Anbefalte tiltak
Det er flere måter å håndtere en risiko på. Man kan:
1. Unngå risikoen (dvs. ikke utsette seg for risikoen, f.eks. ved å ikke gjennomføre det som
kan føre til den uønska hendelsen)
2. Redusere risikoen (redusere sannsynlighet og/eller konsekvens)
3. Overføre risikoen (f.eks. ved å tegne en forsikring overføres risikoen til et
forsikringsselskap)
4. Akseptere risikoen11 (leve med den, beholde den).
Man kan velge en av disse måtene, eller man kan kombinere to eller flere av dem.
Risikoreduserende tiltak må vurderes opp mot kost/nytte for tjenesten. Noen tiltak kan
redusere risikonivået for flere trusler samtidig, og enkle og billige tiltak som kan redusere en
akseptabel risiko bør gjerne iverksettes.
Som analysen i kapittel 5 viser, så er det 4 trusler som har uakseptabel høy risiko. Av de 30
truslene med middels risiko har vi vurdert 8 til å være uakseptable.
I det følgende anbefales først og fremst tiltak mot de 12 truslene med uakseptabel risiko. De
fleste av disse truslene kan få redusert risiko bare ved å sørge for å dokumentere
(eksisterende) rutiner og prosedyrer. I tillegg vil opplæring og tilstrekkelig med ressurser for
oppfølging av meldingstrafikken være viktige tiltak – både innad i HN IKT, og hos brukerne i
foretakene, legekontorene og kommunene.
Selv om mange av de identifiserte truslene hver for seg har akseptabel risiko, vil disse til
sammen kunne gi et uakseptabelt risikonivå. Ved å redusere risikoen for en eller flere av disse
truslene, vil også den totale risikoen reduseres.
Tabell 5 gir en oversikt over hvilke trusler de ulike tiltakene kan redusere risikoen for.
(Trusler angitt med fet skrift er de truslene vi har evaluert til å være uakseptable.) Som
tabellen viser vil flere av de foreslåtte sikkerhetstiltakene være med på å redusere risikoen
også til mange trusler som hver for seg er akseptable. Disse tiltakene vil da til sammen
redusere den totale risikoen for systemet.
Tabell 5: Anbefalte tiltak
Sikkerhetstiltak
Krav nr. i Normens
kravdokument
Berørte trusler
Dokumenterte prosedyrer og rutiner:
-
11
Dokumenterte prosedyrer for overvåking av
meldingstrafikk og status på transport- og
applikasjonskvitteringer.
6
7, 8, 20
Det å akseptere risikoen betyr ikke at man aksepterer den uønska hendelsen, sikkerhetsbruddet.
29
Sikkerhetstiltak
Krav nr. i Normens
kravdokument
8, 10
Berørte trusler
-
Dokumentere eksisterende prosedyrer for å varsle og
håndtere avvik/feil.
9, 10, 11, 12, 25, 42
-
Rutiner på legekontor for å følge opp meldinger som blir
liggende i legekontorets meldingstjener
-
Rutiner i HF/avdelinger for å følge opp feilsendte
meldinger og negative applikasjonskvitteringer
-
Rutiner for å anskaffe/fornye og publisere virksomhetssertifikat
13, 14, 15
-
Bekjentgjøre kontaktinformasjon til samhandlingsparter
i ved feil i meldingsoverføringen.
7, 9
23
11
17, 17b, 27
13, 14, 15, 16
24
11, 12, 13, 14, 15,
24, 36
28, 30, 31
Opplæring:
-
generelt til alle som skal sende/motta meldinger eller
drifte/overvåke meldingstrafikken
-
Brukerstøtte for å håndtere feil
9, 10
26
-
hos HN IKT i overvåkning av meldingstrafikken.
6, 11
21, 27
-
på legekontor for feilsøking og -håndtering
10, 15, 16, 27
-
på legekontor for vedlikehold av NHN Adresseregister
9, 27, 42, 43
-
i rutiner for kjøring av DIPS-rapporten
infeksjonsregistrering
19b
Ressurser:
-
Ha tilstrekkelig kompetanse for rask nok feilsøking.
7
22, 42
22
16
Tekniske tiltak/løsninger:
-
Applikasjonskvitteringer for alle typer meldinger.
-
Verdikjedetesting ved endringer og ved innføring av nye
meldingstyper
3, 19, 20
1, 2, 3, 4, 5, 6
-
Tjenesteadresser og HER-ID inn i NHN Adresseregister
16, 17
34, 35, 36, 45
-
Ta i bruk meldingstypen ”Henvisning” mellom foretak
32
-
Ta i bruk DIPS 7.0
24, 33, 37, (38)
-
Mer automatisert oppfølging og håndtering av meldinger
som blir lagt i ”Udefinert arbeidsflyt” eller tilsvarende
-
Hyppigere oppdatering av helseforetakenes rekvirentregistre
-
Øke kapasiteten i DIPS Communicator (fordele
trafikken på flere, eller skaffe oppgradert/ny løsning)
-
Legekontorsystemer som kan markere hastegrad på
meldinger
5
17b, 18, 43
17, 17b
5
19, 19b(?)
19
Ved gjennomføring av de anbefalte tiltakene for trusler med uakseptabel risiko (vist med fet
skrift i siste kolonne i tabellen over), anser vi risikonivået for å være akseptabelt for truslene
med uakseptabelt risikonivå.
30
7 Konklusjon
Fra våre funn vil vi spesielt trekke fram følgende aspekter:
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å.
Truslene identifisert med høyt risikonivå omfatter i stor grad trusler knyttet til overvåkning av
status for meldingstrafikken, både med hensyn til dokumentasjon av prosedyrer og bruk av
ebXML-rammeverket inkludert transport- og applikasjonskvitteringer for alle meldingstyper.
Av de fem uakseptable truslene med middels risikonivå, handler noen av dem om at
meldinger blir liggende for lenge ubehandlet hos en av aktørene. Dette kan bl.a. skyldes at
meldingene er feilsendt pga. manglende oppdatering av kontaktinformasjon. En av truslene
handler om at HN IKT har begrensede ressurser med tilstrekkelig kompetanse på
meldingsovervåkning, noe som kan være sårbart ved f.eks. lengre sykefravær. Godt
dokumenterte prosedyrer vil kunne gjøre at situasjonen blir mindre sårbar. Manglende
varslingsverktøy for mulige feilsituasjoner (f.eks. om innkommende meldinger som feiler og
ikke blir håndtert raskt nok) er også en medvirkende årsak til en av de uakseptable truslene.
Vi har i kap. 6 anbefalt tiltak som vil gjøre risikonivået akseptabelt for truslene med
uakseptabelt risikonivå.
31
Referanser
1. HN IKT: Prosjektbeskrivelse
2. Hdir (Nasjonalt meldingsløft): Minstekrav til elektronisk meldingsutveksling. IS-1950
Helsedirektoratet 2011
3. Hdir (Normen): Krav til elektronisk meldingsutveksling. Versjon 1.0.
Helsedirektoratet 1. desember 2011
4. HN IKT: Kartlegging av primærhelsetjenesten. Mars 2010
5. Hdir (Veileder): Bruk av elektronisk henvisning og epikrise for allmennleger og
helsepersonell i spesialisthelsetjenesten. IS-1922 Helsedirektoratet 09/2011
6. Hdir: Handlingsplan 2011. Meldingsløftet i kommunene 2010-2011. IS-1882
Helsedirektoratet 03/2011
7. KITH: Applikasjonskvitteringer. KITH-rapport 15/04:2012.
http://www.kith.no/upload/6466/R15-04-2012_AppRec-v1_1-2012-02-15.pdf
32
Vedlegg A Trusseltabell
Krav-nr i kommentarkolonnen henviser til nummerering i Normens kravdokument ”Krav til elektronisk meldingsutveksling” [3].
ID
Årsak
Sannsynlighet
Konsekvens
Risiko
Kommentarer og beskrivelse av
implementerte tiltak
Fagsystem hos HF kan ikke
lese/tolke melding fra avsender
fordi sender og mottaker har
implementert ulike versjoner av
meldinger.
HF har ikke publisert oversikt over
versjoner de har implementert.
Svært liten
Alvorlig
Lav
En av partene bruker
meldingstyper som ikke er testet
og godkjent.
Svært liten
Alvorlig
Lav
Krav om bare å bruke godkjente
meldingstyper.
Kommunikasjonspartene må gjøre kjent
for hverandre hvilke meldinger som kan
behandles.
Jf. Krav 3
3
Mottaker kan ikke lese/tolke
melding fra virksomheten.
ebXML-rammeverket er ikke
benyttet
Svært liten
Alvorlig
Lav
- Krav 18
4
Ulike feil etter oppdateringer og
innføring av nye meldingstyper
Manglende testing og godkjenning
fra det nasjonale
standardiseringsorganet for
meldinger
Liten
(spes. problem i
Profdoc Vision)
Alvorlig
Middels
Virksomheten gjennomfører ikke
verdikjedetesting
Svært liten
Alvorlig
Lav
- Krav 19
Moderat
(Skjer hele tiden
i WinMed, men
det kommer ny
DC som skal
fikse dette)
Alvorlig
Middels
- Krav 20
1
2
Trussel /
Kompromittering
5
6
Melding vises/presenteres feil hos
mottaker slik at misforståelser kan
oppstå
Virksomheten gjennomfører ikke
verdikjedetesting
7
Oppdager ikke at utgående
meldinger fra HF feiler hos
mottaker
Mangelfull dokumentasjon av
rutiner for å overvåke status på
transportkvitteringer
Høy
Alvorlig
Høy
Mangelfull dokumentasjon av
rutiner for å overvåke status på
applikasjonskvitteringer
Høy
Alvorlig
Høy
8
- Krav 19
Eks: LK bytter EPJ-syst – som ikke
støtter meldingstyper…
HF må stille krav til leverandørene.
Tiltak: Dokumentere prosedyrer for
overvåkning av meldingstrafikken.
Se krav 6
33
9
Meldinger fra HF blir ikke
behandlet hos legekontorets
meldingstjener (manglende
transportkvittering)
Manglende oppdatering av
legekontorenes sertifikatinformasjon og EDI-adresser i
NHN Adresseregister eller
manglende utveksling av
partnerdefinisjoner mellom
aktørene.
Høy
Liten
(Har
udokumenterte
rutiner for å
følge opp)
Middels
Kryptering feiler. Må sjekke oppsett hos
avsender og mottaker, ev. utveksle
partnerdefinisjoner. Personell på
legekontor har mangelfull kompetanse
på oppdatering av sertifikat i Adresseregisteret, og er heller ikke forpliktet til å
oppdatere sertifikatinformasjonen => en
utfordring.
De fleste må følges opp via telefon.
Kun et fåtall kontorer kan nås via epost.
HN IKT kan hente oppdaterte
sertifikater direkte fra Buypass.
Jf. Krav 8 (prosedyrer for overvåkning
og varsling)
10
11
12
Moderat
Liten
(Har
udokumenterte
rutiner for å
følge opp)
Lav
Manglende transportkvittering. Melding
resendes inntil 5 ganger annen hver
dag i løpet av 10 døgn. Deretter
kategoriseres meldingen som feilet ved
manglende transportkvittering.
Kontoret kontaktes for å sjekke om de
er klar over problemet. Feilede
meldinger resendes når problemet er
løst.
Jf. krav 8 (prosedyrer for varsling)
Negativ applikasjonskvittering fra
legekontorets fagsystem med
melding om manglende HPRnummer på lege på foretaket som
har sendt meldingen. Avsender
har glemt å legge inn eget HPRnummer
Høy
Liten
(HN IKT har
udokumenterte
rutiner for å
følge opp)
Middels
Varsle avsender, eller EPJ-konsulent
på lokasjonen (for eksempel HF-avd.,
lab, HN IKT) om at info om avsender
må korrigeres. Deretter må meldingen
sendes på nytt fra journalsystem. Dette
skal sjekkes i DC på avdelingene, men
har avdelingene rutiner for å sjekke og
følge opp?
Negativ applikasjonskvittering fra
fagsystem hos legekontoret med
melding om ukjent pasient.
Avsender kan ha valgt feil fastlege
som mottaker.
Svært høy
Liten
(HN IKT har
udokumenterte
rutiner for å
følge opp)
Middels
HN IKT følger opp en del av disse
meldingene og gir beskjed til
avdelingene.
Avsenderavdeling må rette opp og
sende ny melding. Avdelingene har
rutiner for å sjekke og følge opp.
Tekniske feil eller avslått server
på legekontoret
Meldinger fra HF blir avvist hos
legekontorets fagsystem (HF
oppdager neg. eller manglende
applikasjonskvittering)
34
Svært høy
- skjer stadig
vekk, og ofte i
ferien
Liten
Kan likevel
være
behandlet av
annen lege på
legekontoret
Middels
Mottaker har mottatt melding, de må
hente den inn manuelt til sitt
journalsystem fra meldingstjener.
Det er avsenderavdeling som skal følge
med på dette og ev. sjekke med
mottaker hva årsaken er.
Avsender benytter legekontoret
(og ikke legen) som
mottakerrekvirent
Høy
Moderat
Hva skjer med
slike meldinger
hos
legekontoret?
Middels
Det er ikke lov, men gjøres likevel. Det
ble forsøkt fjernet fra UNN, men de ville
ha det tilbake og noen LK vil ha det slik
– f.eks. der det skiftes lege ofte og LK
ikke sender oppdatert HPR-nr.
Melding stopper i legekontorets
meldingstjener av andre årsaker
(for eksempel pasient ikke
registrert i journalsystemet).
Varierende kunnskapsnivå hos
personell på legekontor – sjekker
kun i journalen og ikke i
meldingstjener
Høy
Moderat
Middels
Bedre opplæring trengs.
Fastlegeregisteret oppdateres f.eks. i
dag en gang i mnd i DIPS. Kunne vært
løst i DIPS med spørring mot registre
som ligger i NHN...
Lab- og rtg-svar blir liggende i
meldingstjener på legekontoret
pga feil i meldingen (eks ukjent
pasient – nyfødt eller lignende) og
blir ikke fulgt opp av hjelpepersonellet på legekontoret. Dette
gjelder meldinger som ikke har
applikasjonskvittering
Høy
Alvorlig
Antar at disse
meldingene
ikke blir
håndtert hos
legekontoret
Høy
Jf. krav 22
Personell på legekontoret bør ha rutiner
for å følge opp slike meldinger.
13
Negativ applikasjonskvittering
med melding om ukjent lege, selv
om legen er riktig (melding
stopper i legekontorets
meldingstjener).
Profdoc Vision (og noen versjoner
av Infodoc) hvor fastleger er på
ferie og har markert dette i
journalsystemet, sender negativ
app-kvittering om at lege er feil.
14
15
16
Avsender på HF oppdager ikke at
melding ikke kommer fram til
fagsystem hos mottaker – pos.
transportkvittering er mottatt
35
17
Utilfredsstillende håndtering av
innkommende meldinger til rtgsystem, lab-systemene
Mangelfulle tekniske løsninger og
rutiner for å følge opp
rekvisisjoner med feil, eks. ugyldig
fødselsnr., manglende HPR-nr,
feil mottakeradresse, etc (lab, rtg.,
etc)
Moderat
Alvorlig
hvis disse ikke
blir fulgt opp
Middels
Meldinger med manglende
applikasjonskvitteringer slik at avsender
ikke oppdager at meldingene ikke blir
håndtert av mottaker.
Lab: Legger inn manglende info
manuelt
Rtg legger inn manglende info manuelt.
Her gjøres det ofte feil
Jf. krav 22
17b
Feilsending av svar på rtgrekvisisjoner som inneholder feil
eller manglende rekvirentkode
For innkommende rekvisisjoner
som mangler rekvirentkode blir
korrekt rekvirentkode lagt inn
manuelt. Da gjøres det ofte feil,
med den følge at feil rekvirent
mottar svaret, eller at svaret blir
liggende i en ikke-aktiv arbeidsflyt
på HF-et
Høy
Moderat
Middels
Mottaker skal returnere feilmeldinger
slik at avsender kan rette opp og sende
til riktig mottaker.
Dersom rekvirentens UNN-kode blir
valgt, havner svaret i rekvirentens
inaktive arbeidsflyt på HF-et, og kan bli
liggende ulest i inntil tre mnd.
18
Meldinger kommer ikke fram til
intern mottaker så raskt som mulig
Manglende rutiner for å håndtere
meldinger i Udefinert arbeidsflyt.
Eksempler:
PLO-meldingene rutes etter hvor
pasienten er innlagt, men hvis
pasienten ikke er innlagt må
meldingen rutes manuelt (fra
Udefinert arbeidsflyt), PLOmeldinger adresseres (foreløpig)
bare til foretaket.
Henvisninger fra andre foretak
havner i oppgaven ”Eksterne
epikriser til signering” i
arbeidsgruppen Udefinert
arbeidsflyt fordi DIPS EPJ/PAS
(dvs. EDI Broker) ikke har løsning
for å adressere meldinger til
avdelingsrekvirenter på andre
foretak
Svært høy
Liten
Middels
HF skal følge nasjonale retningslinjer
for bruk og håndtering av meldinger
(sending og mottak)
Jf. Krav 4
Jf. krav 5
I dag følger Gro Wangensteen ved
SKIS på UNN opp PLO-meldingene og
HN IKT følger opp andre typer
meldinger.
Manuell oppfølging vil bli utfordrende
ved økende meldingsmengde.
Mulig tiltak for PLO-meldingene om
ikke-innlagte pasienter:
Bør kunne løses teknisk ved at DIPS
EPJ/PAS sjekker fortløpende for
meldinger i arbeidsoppgaven ”Til
vurdering” i Udefinert arbeidsflyt om
pasient er blitt innlagt, og flytter
meldingen inn i riktig arbeidsgruppe
dersom pasienten blir innlagt.
36
19
Treghet i meldingsserver (DC) og
økende meldingsmengde. Som
følge av bredding av PLOmeldinger til alle kommuner og
alle avdelinger, vil det bli en stor
utfordring med hensyn til
kapasiteten i DIPS Communicator
Høy
Når alle
kommuner og
HF-avdelinger
innfører PLOmeldinger
Liten
UNN har egen
meldingsserver for Øhjelpsmeldinger og
en egen for
PLOmeldinger
Middels
Manglende skalerbarhet i DC?
Må definere hva som er akseptabel tid.
- Krav 5
Det finnes andre system enn DIPS
Comm. ute i legekontorene, og de har
ikke egen funksjonalitet for Ø-hjelpsmeldinger. Disse kommer derfor inn via
den ”vanlige” DC i UNN, noe som kan
bety en forsinkelse.
Derfor: Papir i tillegg ved Ø-hjelp.
19b
Kjøring av en rapport for å sjekke
infeksjonsregistrering i DIPS (for
hele UNN) fører i en del tilfeller til
stopp i meldingssystemet for alle
eller utvalgte meldingstyper i
opptil flere timer.
NA
Liten
NA
Årsaken kan ha vært at rapportgenereringen ble gjort på serveren som
sender ut PLO-meldingene, og med
kapasitetsproblemer som en følge.
Muligheten for slik rapportkjøring er i
følge Gro Wangensteen nå fjernet.
Manglende prosedyrer
Høy
Alvorlig
Høy
Manglende opplæring
Liten
Alvorlig
Middels
Har ikke dokumenterte prosedyrer.
- Krav 6
Moderat
Alvorlig
Middels
- Krav 7
20
21
Feil i meldingstrafikken oppdages
ikke av HN IKT
22
Manglende kompetanse til
feilsøking eller for få ressurser
23
Mangler kontaktinfo for feilsøking
Liten
Alvorlig
Middels
Kontaktinfo for feilsøking kunne vært
knytta til UNN sin kommunikasjonspartinformasjon i NHN AR.
24
Meldinger fra HF sendes ikke på
nytt ved feil
Manglende rutiner for hvordan
melding skal sendes på nytt.
Liten
Alvorlig
Middels
HN IKT har teknisk løsning ved
manglende transportkvittering.
Manglende applikasjonskvittering er
klinikkens ansvar.
Hos HF-ene blir dette lettere å oppdage
og følge opp i DIPS 7.0. (Kan sette
timeout på manglende AppRec.)
- Krav 24
25
Avvik/feil i meldingstrafikken
varsles ikke til rette
vedkommende
Har prosedyrer, men de er ikke
dokumentert
Moderat
Alvorlig
Middels
- Krav 8
37
Alvorlig
Lav
Høy
Moderat
Middels
Svært liten
Alvorlig
Lav
- Krav 13 + 15
Helsepersonell i HF mangler
personsertifikat
NA
Ikke aktuell for
HF nå
NA
NA
Personlige sertifikat i HF kommer i
2013/2014.
- Krav 13
Samhandlingspart finner ikke
”våre” sertifikat
- ikke publisert i NHN Adr.reg
Svært liten
Alvorlig
Lav
- Krav 14
- ikke oppdatert i NHN Adr.reg
Svært liten
Alvorlig
Lav
- Krav 15
Sensitiv informasjon må leses av
personell hos HN IKT, bl.a.
henvisninger fra andre foretak, for
å rute henvisningen til riktig
arbeidsgruppe i DIPS EPJ/PAS
HN IKT må lese innhold i
meldinger som havner i udefinert
arbeidsflyt av ulike årsaker, for å
manuelt rute dem til riktig
arbeidsgruppe.
Henvisninger fra andre foretak
havner i oppgaven ”Eksterne
epikriser til signering” i arbeidsgruppen Udefinert arbeidsflyt fordi
DIPS EPJ/PAS (dvs. EDI Broker)
ikke har løsning for å adressere
meldinger til avdelingsrekvirenter
på andre foretak
Svært høy
Liten
Taushetsplikt
og
databehandler
avtale
Middels
Brukere får ikke hjelp til å
håndtere feil
Manglende brukerstøtte
(rutiner for, info om)
27
Brukerfeil
Manglende opplæring av brukere
28
Kan ikke motta elektronisk
melding fordi virksomhetssertifikat
mangler
- ikke anskaffet
- utgåtte ikke fornyet (nye ikke
anskaffet)
29
Kan ikke sende meldinger som
krever personlig signatur
30
31
32
- Krav 9 – 10
Svært liten
26
Litt utenfor HN IKT sitt ansvarsområde,
men påvirker meldingsflyten.
- Krav 11
Henvisning mellom foretak er under
utprøving.
38
33
Epikriser og henvisninger
adressert med HER-ID kan ikke
håndteres av DIPS EPJ/PAS 6.xx.
EDI-Broker (som håndterer disse
meldingene) har ikke noe forhold
til HER-ID, og Message Broker
håndterer foreløpig ikke epikriser
og henvisninger.
Høy
Liten
Lite behov før
DIPS 7.0 er
installert
Middels
EDI Broker skal fases ut når DIPS
EPJ/PAS 7.0 kommer. I mellomtiden er
det tenkt brukt en mappingtabell i
Message Broker mellom avsenders
HER-ID for virksomhet/lege og org.nr./
HPR-nr for de samme, slik at EDI
Broker kan benytte kjente koder.
Denne tabellen er foreløpig ikke innført,
det håndteres manuelt inntil DIPS 7.0
tas i bruk.
Jf. krav 17
34
Melding kommer ikke fram til riktig
mottaker i helseforetaket
- Tjenesteadresse ikke registrert
eller oppdatert (f.eks. gyldighetsdato) i NHN Adr.reg
Moderat
Alvorlig
Middels
- Krav 16 – 17
Kommer i TjenBar-prosjektet
Avsender har ikke en oppdatert
versjon av Adresseregisteret lokalt
Moderat
Alvorlig
Middels
Moderat
Moderat
Middels
HF-ene har rutiner for å håndtere dette.
En mappingtabell må benyttes i
Message Broker mellom HER-ID for
tjenesten og avdelingskode for
avdelingen som tilbyr tjenesten, også i
DIPS v.7.0. Krever manuell innlegging
og oppdatering.
35
36
Melding kommer fram til feil
mottaker i HF (feil arbeidsgruppe)
(avsender får positiv app.kvitt.)
Avsender har valgt feil tjeneste/
helsehjelpsområde
37
Kommunikasjonsparter av typen
tjenesterekvirenter i spes.helsetj.
er i utgangspunktet ikke støttet i
DIPS EPJ/PAS
Mangler generell (standardisert?)
kobling mellom tjeneste /
helsehjelpsområde og intern
arbeidsflyt/arbeidsgrupper i DIPS
Høy
Liten
Lite behov før
DIPS 7.0 er
installert
Middels
38
Vanskelig å vite hvordan
meldinger adressert med HER-ID
og med flere meldingsmottakere
skal behandles av foretaket –
uklart hvor mange app-kvitteringer
som skal sendes
I DIPS ligger det ikke HER-ID
knyttet til eget foretak, kun org.nr.,
og Message Broker ser derfor ikke
hvor mange av mottakerne som er
i eget HF
Moderat
Liten
Lav
39
Kan ikke hente HER-ID for interne
tjenesterekvirenter fra NHN
Adresseregister vhja FRESHConnector
Org-strukturen i DIPS har ikke noe
forhold til tjenester i eget foretak.
Svært høy
Liten
Manuell
løsning finnes
Middels
Det skal sendes en applikasjonskvittering pr mottaker.
Kan legge inn HER-ID på nivå 1
sammen med org.nr. i DIPS. Må ev.
gjøres i en ny release av DIPS
Jf. krav 17 og krav 22
DIPS tilbyr en mappingfunksjon mellom
HER-ID for interne tjenester og
avdelinger/arbeidsgrupper. Denne må
fylles ut og oppdateres manuelt av det
enkelte HF.
39
40
Vanskelig å vite hvordan man skal
styre tilgangskontrollen for
dokumenter som ble
tjenesteadressert
NA
NA
NA
Løses med den skisserte mappingen i
Message Broker mellom
tjenesterekvirenter og avdelinger
Ikke aktuell problemstilling for denne
risikovurderingen
41
Uklart om meldinger som benytter
tjenestebasert adressering skal ha
betydning for rapportering,
arbeidsprosesser med mer.
NA
NA
NA
Ikke aktuell problemstilling for denne
risikovurderingen
42
Meldinger fra legekontor eller PLO
blir avvist i meldingstjener i
foretaket (negativ
transportkvittering ut fra HF)
Høy
Moderat
Oppdages
straks – men
kan gå noen
dager i forb.
med helg
Middels
HN IKT sjekker negativ transportkvitteringer ut fra HF, det følges opp
hele tiden.
De fleste må følges opp via telefon.
Kun et fåtall kontorer kan nås via epost. Dette forvansker spredning av
viktig informasjon. HN IKT ender i en
20-30 minutters telefonkø for å kunne
få overbrakt informasjon essensielt for
kontorets daglige drift.
Jf. Krav 8 (prosedyrer for overvåking og
varsling)
Høy
Moderat
Ingen
overvåkning i
helgene. PLOmeldinger kan
bli liggende
over helga
uten å komme
til rett mottaker
Middels
Feilene oppdages som regel raskt av
HN IKT og rettes, men har ikke gode
nok verktøy for å varsle mulige
feilsituasjoner. Krever manuell
overvåkning.
HN IKT må be legekontoret sende info
om nye leger til
”[email protected]”, ev.
oppdatere NHN Adresseregister med
ny lege (når FRESH-Connector tas i
bruk for å hente eksterne
rekvirentadresser inn i DIPS).
Når dette er gjort kan feilet-melding
rearkiveres.
Nytter ikke dette gjennomgås loggene
for å finne ut hva årsaken er.
Jf. krav 8 (prosedyrer for overvåking og
varsling)
Mange kontorer leser ikke inn
mottatte partnerdefinisjoner (sendt
fra foretaket, for eksempel med
opplysning om endring i
sykehusets sertifikat)
Eks. sertifikatfeil, feil i XML som
gjør at meldingen tolkes som tom,
ukjent meldingstype, melding fra
ikke-godkjente partnere
For flere mulige årsaker se *)
43
Melding fra legekontor eller PLO
blir avvist av fagsystemet i
foretaket (neg. app-kvitt ut)
Som regel tekniske årsaker (eks.
melding med hjelpenummer i
stedet for personnummer, feil i
XML, feil i EDI-oppsett på
partnerne, rekvirent ikke registrert
i fagsystemet).
For flere mulige årsaker se *)
40
44
Ukjent fødselsnummer på pasient
Høy
Liten
Middels
Foretakets personell tar seg av dette.
F.eks. fjerne personnummeret og sette
meldingen tilbake i meldingsflyten.
Oppretter ny pas.
45
Utfordrende å adressere
meldinger til riktig kommunal PLOtjeneste
Ulike tjenester i de ulike
kommuner – vanskelig å velge rett
mottaker i den enkelte kommune
for de ulike meldingene
Høy
Moderat
Middels
FRESH-Connector skal ha hentet inn
oversikt over HER-ID for alle tjenester i
alle kommunikasjonsparter. Ulike
kommuner organiserer PLO-tjenestene
forskjellig. Dette medfører utfordringer
for de som skal sende meldinger til
PLO-tjenesten.
Jf. krav 17
Viktig med rutiner/prosedyrer og
opplæring i foretakene.
46
Meldinger med tjenestebasert
adressering til PLO i kommunen,
blir ikke synlig for mottaker selv
om avsender har mottatt positiv
applikasjonskvittering
Meldingen blir sendt til feil
tjenesteadresse, og de som har
tilgang til innboksen til denne
tjenesten har ikke tilgang til å se
meldinger om denne pasienten
NA
NA
NA
Fremtidig trussel når tjenestebasert
adressering tas i bruk mot kommunen.
F.o.f. kommunens ansvar.
Hvis meldingen er adressert til feil
tjeneste i kommunen, vil ikke de som
har tilgang til den tjenesten meldingen
er adressert til kunne se meldingen
fordi de ikke har tilgang til å se
meldinger om denne pasienten (har
ikke tilgang til pasientens journal),
mens de som har ansvar for pasienten
ikke får meldingen.
Tjenesten i kommunen som skulle
hatt meldingen mottar den ikke.
Saksbehandlertjenesten og
administrative IT-personer i kommunen
har mulighet til å oppdage at meldinger
ikke blir lest. Må ha kunnskap og rutiner
for å sjekke ubehandlede meldinger
fortløpende.
*) Liste over noen vanlige feilmeldinger fra Brokere (det kan også finnes andre lokasjonsmessige særegenheter):
 There are no electronic recipients to this message. Producing it makes no sense
 Populated message body text is empty
 No or ambiguous main recipient for message
41






Unable to look up sender institution. Sender hcparty has no department
Unable to find active copy recipient, cannot set main recipient
Unable to determine correct output message format. Main recipient is EDIFACT receiver
Unable to determine correct output message format. Main recipient is XML receiver
Unable to determine correct output message format. Main recipient is a paper copy recipient
Could not find patient DIPSAPI reported the following error: ErrorCode=14 Error Message: No such object exists.
42
Vedlegg B: Systembeskrivelse fra HN IKT
Odd-Arne Olsen hos HN IKT har laget denne beskrivelsen av system og meldingsflyt, med
tilhørende figurer for hvert av de fire helseforetakene.
B.1 System i helseforetakene
B.1.1 System involvert i meldingsutveksling
Applikasjoner som driftes av Seksjon for Samhandling og Integrasjon i HN IKT:






DIPS Communicator (DC) – henter klargjorte meldinger, sjekker mottaker, krypterer
og sender.
DIPS EDI Broker
o Henter henvisninger, rekvisisjoner og applikasjonskvitteringer fra DC og leverer
til DIPS.
o Henter epikriser, røntgensvar (DIPS RIS), tilbakemeldinger og applikasjonskvitteringer fra DIPS og legger klart for DC.
DIPS Rapportserver – genererer brukerbestilte rapporter internt på sykehuset
DIPS LabBroker – henter svar fra labsystemer og klargjør for DC.
Partus Meldingsutveksler – klargjør fødselsmeldinger for sending til MFR 12 via DC.
Mottar kvitteringer fra DC på innsendte fødselsmeldinger.
DIPS Message Broker
Figurene 2-5 lenger bak i dette vedlegget viser system involvert i meldingsflyt ved de ulike
foretakene i Helse Nord.
EDI-meldinger går via spesifikke mailservere kun beregnet for dette formålet. Meldinger for
andre formål håndteres ikke av disse serverne. Det er to slike, en i Tromsø og en Harstad. I
disse dager byttes den i Harstad ut med en i Bodø.
Røntgensystem
To røntgensystemer i bruk i Helse Nord: DIPS RIS og TRIS. DIPS RIS er en del av DIPS,
mens TRIS er et eget system utviklet av RisCo. RisCo står også bak Arcidis. Begge
systemene produserer røntgensvar på XML-format. DIPS RIS benytter KITH versjon 1.2.,
men TRIS benytter KITH versjon 1.3.
Arcidis er et system for overføring av rekvisisjoner for og resultater av røntgenanalyser
mellom sykehus. Analysene er til dels store filer og må sendes via SFTP-protokollen.
Arcidis opererer på to plan i Helse Nord, se Figur 2. Det ene planet er internt i Helse Nord
mellom sykehusene (blå linjer i Figur 2). Dette går vi DIPS Communicator. Det andre planet
er mot Curato og en ekstern røntgenlege tilknyttet UNN (røde linjer i Figur 2). Her
kommuniserer Arcidis-klienten mot en spesifikk SFTP-server i Helse Nord, som også har
forbindelse mot Curato og Dr. Sponga.
12
MFR – Medisinsk fødselsregister
43
Figur 2: Arcidis ved sykehusene i Helse Nord
B.1.2 Meldingstyper og -format
Det er fire meldingssyntakser i bruk nå (EDIFACT, DOLLAR, ASTM og XML). Vi er i en
overgangsfase og med tid og stunder skal vi ende opp med én hovedtype: XML.
Det er kun et fåtall meldingstyper igjen som benytter seg av EDIFACT, DOLLAR og ASTM.
Labsvar og poliklinisk oppgjør (POLK) er de som gjenstår.
DOLLAR og ASTM sendes kun fra UNN til Hammerfest. ASTM konverteres lokalt av et
hjemmesnekret program til et format som kan leses inn i DIPS. Innføring av lab-til-lab vha
Messagebroker vil ta livet av disse formatene. Kvitteringer?
Overgang fra POLK til behandlerkravmeldinger (BKM), samt lab-til-lab vil føre til at
EDIFACT også fases helt ut.
Kryptering SORIA, DES, ebXML (virksomhetssertifikat)

det aksepteres ikke lenger oppkoblingshenvendelser hvor DES og SORIA anvendes som
kryptering. Alle som vil kommunisere med Helse Nord må benytte ebXML. Det vil si at
de får utstedt et virksomhetssertifikat av Buypass. Dette sertifikatet lar deg dekryptere
meldinger sendt til deg, i tillegg til at du på en tilsvarende måte krypterer meldinger du
sender fra deg slik at kun mottakeren kan dekryptere meldingen.
44
B.1.3 Meldingsflyt
Sykehus  sykehus





Rekvisisjoner
o Lab (Mikrobiologi)
o Røntgen
Epikriser
Røntgensvar
Labsvar
o Klinisk kjemisk
o Mikrobiologi
Kvitteringer
o Transportkvittering (kvittering på at meldingen er mottatt av mottakerens EDIapplikasjon, i Helse Nord er det DIPS Communicator).
o Applikasjonskvittering (kvittering på at melding er mottatt og godkjent/avvist av
mottakerens journalsystem, i Helse Nord er dette DIPS).

Partnerdefinisjoner (sendes kun på forespørsel). Inneholder informasjon om
kommunikasjonspartner.
o Offisiell- og EDI-id (organisasjonsnummer)
o EDI-adresse
o Andre id’er, som HPR-numre, edi-rekvirentnumre osv.
o Offentlig krypterings- og signeringssertifikat.

Arcidis
o Røntgenanalyserekvisisjoner.
o Røntgenanalyse
Sykehus  legekontor/spesialister


Epikriser
Labsvar
o Klinisk kjemisk
o Mikrobiologi
o Cytologi
o Histologi



Røntgensvar
Tilbakemeldingsbrev
Kvitteringer
o Transportkvitteringer
o Applikasjonskvitteringer
Legekontor/spesialister  sykehus


Henvisning
Rekvisisjon
o Røntgen
o Lab
45

Kvitteringer
o Transportkvitteringer
o Applikasjonskvitteringer
Sykehus  andre institusjoner
 NAV
o POLK (på vei ut)
o Behandlerkravmelding (overtar for POLK)

Nasjonalt Folkehelseinstitutt
o Fødselsmelding (MFR)
o Barnemelding (neonatal) (MFR)
o Abortmelding (MFR)
o Mikrobiologi (MSIS, overvåkningssystem for smittsomme sykdommer)




Nasjonalt pasient register (NPR)
Norsk Helsenett – trafikkstatistikk rapporter
Rikshospitalet – neonatalmeldinger. Hammerfest, UNN, NLSH-Bodø.
Dokumed (diktater til utskrift (lyd) og utskrevne diktater i retur (tekst)) Kirkenes,
Hammerfest, Mosjøen, Mo i Rana
Tromsø kommune (pleie og omsorgsmeldinger, epikrise, labsvar, røntgensvar)

Figur 3: Meldingsflyt og systemer ved UNN
46
Figur 4: Meldingsflyt og systemer ved NLSH, Bodø
Figur 5: Meldingsflyt og systemer ved Helgelandssykehusene, NLSH Vesterålen
og Helse Finnmark Hammerfest
47
Figur 6: Meldingsflyt og systemer ved NLS Lofoten og Helse Finnmark Kirkenes
B.2 System ved legekontor og hos spesialister
Journalsystem
 Vision
 Winmed
 Infodoc
 System X
 Promed
48
Vedlegg C: Status for oppfyllelse av meldingskrav
Lars Andreas Wikbo hos HN IKT har gått gjennom kravene i Meldingsløftets dokument
”Minstekrav til elektronisk meldingsutveksling” [2] og angitt status for disse i Helse Nord.
Dette er tatt med i form av følgende tabell. Siden vi i denne rapporten ellers har forholdt oss
til Normens kravdokument ”Krav til elektronisk meldingsutveksling” [3], har vi i tabellen
laget en mapping mellom nummereringen i de to dokumentene.
Krav nr i
Normens
kravdok.
[3]
Krav nr i
Meldings
løftet [2]
Beskrivelse
Status for Helse Nord
1
Virksomheten skal ha inngått avtale om tilknytning
med Norsk Helsenett SF for elektronisk
kommunikasjon av helseog personopplysninger
over helsenettet. Virksomheten skal oppfylle denne
avtalens krav.
OK
31
Virksomheten skal oppfylle kravene i Normen.
Mangler f.eks. noen apprec
m.m, men Normen går langt
utover elektronisk
samhandling. Der har vi ikke
oversikt på SSI (Seksjon for
samhandling og integrasjon).
2
2
Virksomheten skal ha etablert en
kommunikasjonsløsning/meldingstjener som er
underlagt virksomhetens databehandlingsansvar.
OK
3
-
Alle meldingstyper som tas i bruk av
virksomhetene skal være testet og godkjent av det
nasjonale standardiseringsorganet for meldinger.
11
Virksomheten skal ha prosedyrer som sikrer en
oppdatert oversikt over hvilke meldinger og
meldingsversjoner som virksomheten skal kunne
sende og/eller motta.
OK
Rapporteres pr i dag til
Meldingsløftet.
(sjekk med Lars Andreas)
4
(14)
Virksomhetens prosedyrer for bruk og håndtering
av de ulike meldingene skal følge anbefalinger til
nasjonale retningslinjer.
Må avklares med HF
5
15
Virksomheten skal sikre at elektroniske meldinger
som mottas, kommer frem til riktig mottaker i egen
virksomhet så raskt som mulig.
OK
16
Virksomheten skal sørge for at meldingen følges
opp av den som har overtatt ansvaret ved
ferieavvikling og annet fravær. Virksomheter som i
perioder holder stengt, må ved behov sørge for å
varsle fraværet til aktuelle kommunikasjonsparter /
samhandlingsparter.
OK
Meldingene går til tjenesteadresser/ felles mottak, ikke
personer.
– Dokumentasjon må sjekkes
med HF
Teknisk drift har rutiner for
fravær og ferieavvikling
Tekniske krav
1
49
Krav nr i
Normens
kravdok.
[3]
Krav nr i
Meldings
løftet [2]
6
Beskrivelse
Status for Helse Nord
21
Virksomheten skal utarbeide prosedyrer for
overvåking av meldingstrafikk.
INGENTING SKRIFTLIG
Ikke OK
19
Prosedyrene skal sikre at virksomheten har definert
hvem som har ansvar for å overvåke
meldingstrafikken,
OK
20
og at vedkommende har fått nødvendig opplæring.
OK
7
22
Virksomheten skal ha tilgjengelig tilstrekkelig
kompetanse for feilsøking.
Virksomheten skal gjøre samhandlingsparter kjent
med hvem som kan kontaktes i forbindelse med
feilsøking. Virksomheten skal sørge for at
vedkommendes kontaktinformasjon er kjent for
samhandlingsparter.
OK
8
23
Virksomheten skal i prosedyrer definere hvordan
avvik, for eksempel manglende eller negative
kvitteringsmeldinger, skal følges opp. Prosedyrene
skal beskrive hvordan samhandlingsparten skal
varsles via telefon, faks og/eller e-post.
OK
Ikke nedskrevet
9
24
Virksomheten skal sørge for brukerstøtte for
meldingsutveksling, og skal påse at det er klart for
brukerne hvor de skal henvende seg ved behov for
brukerstøtte.
OK
10
26
Virksomheten skal ha klargjort hvordan
henvendelser til brukerstøtte skal følges opp,
OK
27
herunder hendelser som krever involvering av flere
virksomheter/samhandlingsparter.
OK
25
28
Hvem som har ansvaret for oppfølgning av
henvendelsene skal være tydelig presisert.
OK
11
30
Virksomheten skal sikre at alle som gis adgang til å
sende og motta meldinger og til å drifte systemer
for elektronisk meldingsutveksling, har tilstrekkelig
kunnskap til å bruke systemene og til å ivareta
personvern og informasjonssikkerhet.
OK
12
32
Virksomheten skal gjennomføre risikovurdering i
forbindelse med elektronisk meldingsutveksling,
både før oppstart og ved endringer som har
betydning for informasjonssikkerheten.
Organisatoriske krav
13
14
13
6
Virksomheten skal anskaffe og installere
virksomhetssertifikat for virksomheten
OK
7
og den enkelte bruker skal benytte personlige
kvalifiserte sertifikater når det er krav om dette.
Ikke aktuelt
HF har ikke innført dette ennå.
Kommer i 2014/201513
8
Virksomheten skal påse at informasjon om egne
sertifikater er gjort tilgjengelig i NHN
Adresseregister.
Peker til egne sertifikater i AR
OK
Innføres i TjenBar-prosjektet
Info fra IS-forum
50
Krav nr i
Normens
kravdok.
[3]
Krav nr i
Meldings
løftet [2]
15
Beskrivelse
Status for Helse Nord
9
Virksomheten skal ha prosedyrer for å fornye
sertifikatene og oppdatere informasjonen i NHN
Adresseregister.
Rutiner for å fornye sertifikater
og oppdatere informasjonen i
AR – OK
Oppdatere informasjonen
innføres i TjenBar-prosjektet
OK
Rutiner for bestilling av
sertifikat – OK
16
4
5
Virksomheten skal ha registrert - og skal løpende
oppdatere - adressen til egne tjenester eller personer
i NHN Adresseregister. Virksomheten skal ha
prosedyrer for dette.
Innføres i TjenBar-prosjektet
OK
17
3
HER-ID skal benyttes til å identifisere avsender,
mottaker og kopimottakere for alle elektroniske
meldinger.
Innføres i TjenBar-prosjektet
OK
18
10
Virksomheten skal bruke ebXML-rammeverket.
OK
19
-
Alle meldingstyper som tas i bruk av
virksomhetene skal være testet og godkjent av det
nasjonale standardiseringsorganet for meldinger.
29
Virksomheten skal sikre at det gjennomføres
forløpstesting (verdikjedetesting) ved:
- oppgraderinger som får konsekvenser for andre
samhandlingsparter
- innføring av nye elektroniske meldinger
- endringer i eksisterende meldinger
20
-
Virksomhetene skal påse at presentasjonen
(visningen) av innholdet i meldingen er riktig hos
avsender og mottaker.
21
12
Virksomheten skal sørge for at den tekniske
løsningen sender og mottar transportkvittering på
alle meldinger.
OK
22
13
Virksomheten skal sende og motta
applikasjonskvittering på alle meldinger.
MANGLER
Ikke alle meldingstyper er på
XML – mikrobiologi UNN ber
ikke om Apprec grunnet
automatisk utsending av
negativ AppRec fra enkelte EPJ
på legekontorene. LabCraft
genererer ikke AppRec.
23
17
Virksomheten skal ha en teknisk løsning for
overvåking av elektroniske meldinger.
OK
24
18
Virksomheten skal definere hvordan meldingen
skal sendes på nytt til mottaker ved feil i
forbindelse med meldingsoversendelse.
OK teknisk
Sjekk dokumentasjon hos HF
OK
51

Elektronisk meldingsutveksling i Helse Nord

Transcript Elektronisk meldingsutveksling i Helse Nord

Directory