// NOTAT Til: Helsedirektoratet Fra: NAV/Kontor for elektronisk samhandling Dato: 15.02.16 Krav til tjenestebasert adressering - Svar på høring Dette er NAVs kommentarer til høringsutkast «Krav til tjenestebasert adressering og identifikatorer ved elektronisk samhandling» NAV har benyttet elektronisk kommunikasjon i helsesektoren vellykket siden 2003 og har lang erfaring med praktisk anvendelse av ebxml, PKI og problemstillingene tilknyttet å ha mange tusen samhandlingsparter samtidig med at det skjer kontinuerlige endringer. NAV er i utgangspunktet veldig positive til prinsippet om tjenestebasert adressering ved at man kan adressere meldingen til en tjeneste og ikke trenger vite hva som f.eks er navnet (eller HER-id) på den enkelte lege. Den enkelte avsender kan ikke alltid vite eksakt hvilken person den skal sende melding til, og siden det er så mye kontinuerlige endringer er det stor sjanse for at den person man skulle adressere forrige uke ikke lenger er den rette personen å adressere i dag. I enkelte tilfeller så ønsker man å kunne oppgi den enkelte lege i meldingen og da bør det være måter å gjøre dette innenfor tjenestebasert adressering. Ikke som en absolutt adressering, men kanskje mer som et hint om hvem denne meldingen, hvis mulig, skal rettes til. Hvis en saksbehandler f.eks ønsker å få avklart noen uklare detaljer i en sykmelding eller legeerklæring så er det en fordel at spørsmålet fortrinnsvis går til legen som skrev det og ikke til en tilfeldig lege på legekontoret forutsatt at denne legen er tilgjengelig. En absolutt kritisk ting som vi savner i denne standardiseringen av adressering er klarlegging av hvilke meldingstyper det skal gjelde for og overgangsordninger i alle de tilfellene der man må endre fagmeldingene før man kan følge de nye kravene. Mange meldingstyper benytter i dag hodemeldingen som stedet i meldingen der man angir hvilken lege det er snakk om. Som et konkret eksempel, da sykmelding ble endret i 2008 fra å være en frittstående melding ARBEIDS OG VELFERDSETATEN Postadresse: Postboks 5, St. Olavs plass // 0130 OSLO Besøksadresse: Akersgata 64-68 // Tel: 21 07 00 00 // Faks: 21 07 00 01 www.nav.no //
til å benytte KITH hodemelding (som ikke fantes da første versjon av sykmelding ble laget) så flyttet man alt om legen og pasienten ut til hodemeldingen siden dette var informasjon som lå der og ikke trengte ligge to steder. Meldingen ble laget av KITH basert på tidligere sykmelding og på papirblanketten for sykmelding. NAV lot KITH gjøre dette arbeidet for å sikre at alt var slik standarden krevde. Dermed lå legen med både navn og fødselsnummer i hodemelding et nivå under legekontoret. Når man så i etterkant endrer så hverken legen eller legens fødselsnummer ligger i hodemeldingen så må man også endre fagmeldingen inni slik at den nødvendige informasjon blir tatt vare på der i stedet for i hodemelding. For f.eks en sykmelding så er legen som lege viktigere enn både virksomheten og tjenesten. Legen har personlig, i kraft av sin autorisasjon som lege rett til å sykmelde. En tjeneste kan ikke sykmelde og en ansatt på et legekontor kan ikke sykmelde i kraft av sin stilling, kun autorisert lege kan sykmelde. (Det er også noen andre grupper som kan sykmelde etter visse regler, men alltid i kraft av sin personlige autorisasjon, aldri i kraft av en stilling eller en tjenesterolle) Samme problemstilling gjelder for mange andre meldinger som er laget fram til nå og alle disse vil nødvendigvis måtte gjøre endringer før de endringer som kommer av å innføre tjenester og bare tjenester i hodemelding. Blant de meldinger vi vet om er både behandlerkrav, reseptforskrivning og legeerklæringer i samme situasjon, og det er garantert flere meldinger som vil få problemer dersom hodemelding endres uten tilhørende endring i fagmelding. Kanskje hadde det beste vært å opprette en MsgHead v2.0 med to og bare to nivåer og at denne kan tas i bruk fortløpende for eksisterende meldinger når de er gjennomgått og godkjent for dette og for nye meldinger der det kreves endringer for å ta høyde for den nye bruken av hodemelding. Gjerne med en ny Apprec v2.0 som kan benytte samme struktur som MsgHead og dermed unngå problemene med mapping fra den ene strukturen til den andre. 2. Termer og definisjoner NAV syns det kommer alt for mange nye krav og ønsker i selve definisjonene. En definisjon skal være en enkel sak så man kan være enige om hva man snakker om, dette er ikke stedet å innføre kravene som bør innføres og grunnlegges i dokumentet. 2. Termer og definisjoner Oppføring i adresseregisteret NAV lurer på hvorfor EDI-adresse trekkes ut som noe som alltid skal ligge på en «kommunikasjonpart» og ikke andre ting som er nødvendig for elektronisk kommunikasjon, som digitale sertifikater, AMQP kø, hvilke meldinger som kan sendes og mottas, http adresser, WebServices og andre ting. Enten bør alle nødvendige ting som hører hjemme på et nivå trekkes fram eller ingen. NAV syns også prinsipielt at krav til oppføring i adresseregisteret er noe som bør defineres i forbindelse med adresseregisteret og ikke dukke opp i andre frittstående dokumenter. Det har vært alt for mange tilfeller i
sektoren der man omdefinerer ting fra et dokument som en del av innholdet i et annet dokument og dette medfører vanskeligheter med å til en hver tid vite hva som gjelder. Et godt eksempel er KITH Hodemelding (MsgHead) der definisjonen av hodemelding angir 1-N nivåer for avsender og mottaker. Senere dokumenter har omdefinert til at det skal være to og bare to nivåer til enhver tid uten at det har medført en revisjon eller oppdatering av dokumentet som definerer hodemeldingen. En som innfører støtte for hodemeldingen basert på dokumentet for hodemelding vil derfor ikke gjøre det korrekt, man må i stedet sjekke alle mulige dokumenter fra KITH og/eller Helsedirektoratet som er kommet i etterkant for å se om det er noe i dem som indirekte endrer hodemeldingen. 2. Termer og definisjoner Kommunikasjonspart NAV har påpekt tidligere og gjentar problemstillingen med at begrepet «kommunikasjonspart» får en annen definisjon i Helsedirektoratets dokumenter for kommunikasjon i helsesektoren enn det som er standard i annen faglitteratur, både når det gjelder elektronisk meldingsutveksling og når det gjelder sikkerhet. Dette uten at det er dokumentert eller på annen måte påpekt at ordet brukes i en avvikende betydning. Den normale definisjonen av ende-til-ende kryptering er at det er kryptert fra kommunikasjonspart til kommunikasjonspart. Dette betyr blant annet at dersom flere kommunikasjonsparter benytter en felles meldingstjener så er meldingene kryptert før de når EDI-tjener som skal sende og blir ikke dekryptert før etter at de forlater mottakende EDI-tjener. Noen eksempler: Datatilsynet har uttalt til helsenord (http://www.telemed.no/datatilsynets-syn-paa-ende-tilendekryptering.4981061-200102.html) at "Med ende-til-ende mener vi fra behandlingsansvarlig A til behandlingsansvarlig B, der hvor kommunikasjonen foregår utenfor den behandlingsansvarliges kontroll, jf. personopplysningsforskriftens 2-11. Med andre ord ingen brevåpning på veien. Ved mottak forventes det at opplysningene behandles i virksomhetens fagsystem med forsvarlig tilgangsstyring og hvor bruken er i samsvar med formålet." HelseNord tillegger på samme URL at «Slik vi tolker svaret, er at dagens kryptering i henhold til nasjonal standard (ebxml), er tilstrekkelig mellom EDI-tjener i Virksomhet A til EDI-tjener i Virksomhet B» Med andre ord så benytter Datatilsynet og HelseNord her den klassiske definisjon at det er virksomheten som er kommunikasjonspart. Dette er samme definisjon som NAV har fulgt i all bruk av ebxml og elektronisk meldingsutveksling. DigiPost tilbyr nå ende-til-ende kryptering for de som ønsker dette(https://labs.digipost.no/#!/item/55a51dfae4b06434542e6186 ) Da er det slik at de borgere om ønsker dette har sin egen nøkkel som ikke er tilgjengelig for DigiPost og meldingen krypteres før den sendes til DigiPost og kan kun dekrypteres av mottaker. DigiPost har her ikke tilgang til denne og kan ikke dekryptere meldingen. Dette er slik bruken vil måtte være for hver tjeneste dersom det virkelig er tjenesten som er den reelle kommunikasjonsparten. DigiPost har her samme rollen som en EDI-tjener som benyttes av flere tjenester. Begge disse eksemplene bruker definisjonen at det er den det er kryptert til som er kommunikasjonsparten, mens det i dette og tilsvarende dokumenter i helsesektoren benyttes en avvikende definisjon. Dette gjør det vanskelig å sammenstille det med f.eks sikkerhetskrav og med normal EDI bruk.
Skal man definere hver enkelt tjeneste som kommunikasjonspart så flytter man enten krypteringen på utsiden av EDI-tjeneren eller krever at hver tjeneste har sin egen EDI-tjener. På samme måte som man i dag, der man i praksis benytter den klassiske definisjonen av kommunikasjonspart, krever at kommuner som deler en felles infratruktur krever at enten EDI-tjener må sikre at dekrypterte meldinger må ligge i logisk fullt adskilte deler av EDI-tjeneren eller at de må ha hver sin EDI-tjener. Merknad 2 stiller vi store spørsmålstegn ved. Hvis en kommunikasjonspart er en person så er det per definisjon ikke tjenestebasert adressering. At det har ligget personer på nivå 2 tidligere bør dekkes under overgangsordninger fra eksisterende bruk og ikke defineres inn som en mulighet når man nå skal rydde opp. 2. Termer og definisjoner Tjenesteadresse NAV støtter at tjenester ikke skal ha noe med helsetjenester å gjøre, men også kan dekke alle mulige relevante tjenester for elektronisk meldingsutveksling. Men vi stiller spørsmålstegn med tjenestenavn som eksempelets «Teknisk avsenderadresse» da en oppgitt adresse i alle normale tilfeller også skal benyttes til å motta meldinger. Om ikke annet så vil det komme en Apprec i retur. Ord som avsender og mottaker angir kommunikasjonens forhold til den enkelte melding og bør ikke benyttes i tjenestenavn. En tjeneste bør også være en tjeneste, ikke en adresse. Adresse er en egenskap ved en hvilken som helst tjeneste At enkelte tjenester kan og bør være generelle samleposter er vi derimot enige i, så «Teknisk kommunikasjon» ville vi se på som et mer fornuftig navn som kan brukes av mange. Evt. et annet lignende begrep. NAV synes også at det er fornuftig at en del av de mer generelle navnene kan standardiseres slik at f.eks alle som har en slik tjeneste benytter samme navn og at man ikke risikerer at en kommune har «Teknisk Avsenderadresse», kommunen ved siden av har «Adresse for teknisk kommunikasjon», kommunen bortenfor der har «Teknisk kommunikasjon» og neste kommune igjen har «Teknisk kommunikasjonsardesse»(stavefeil som først har begynt å bli brukt er vanskelige å bli kvitt igjen) Litt på siden lurer NAV på hvorfor eksempelet er så generisk samtidig som Arbeids og velferdsetaten ikke kunne få tjenestenavn som «Generell Samhandling» eller lignende men at det ble forlangt at navnet måtte være med i tjenesten og det mest generiske vi kunne få var «Samhandling Arbeids- og velferdsetaten» NAV syns det er fornuftig med generelle navn som kan gjenkjennes som tilsvarende for alle typer virksomheter. Merknad 2. Hva menes med denne? Hvis fastleger skal registreres som tjenester så bryter vi med både prinsippet for tjenestebasert adressering og vi løser ikke de største problemene som eksisterer med å sende til fastlege, nemlig at mange fastleger bytter slik at den legen pasienten hadde sist ikke lenger finnes på legekontoret og pasienten selv ikke vet hva fastlegen heter og at mange er på en såkalt «liste uten lege» der det ikke finnes noen navngitt lege som er pasientens fastlege, men at det håndteres enten som en fellesliste som legekontoret håndterer i fellesskap eller ved at det er en kontinuerlig serie med midlertidige som håndterer fastlegepasientene for kommunen. Begge disse problemene løses ved at alle legekontor som har fastlege må registrere en tjeneste «Fastlege» som blir felles tjeneste for alle henvendelser til fastlege på dette legekontoret uavhengig av om antallet navngitte leger med fastlegeavtale på dette legekontoret er ti, én eller ingen. Så er det systemet på legekontoret som må vite til hvilken lege eller til hvilken journal en melding om en gitt pasient skal fordeles. Dette kan man ikke forvente at den som sender meldingen alltid vet. 3. Tjenestebasert adressering 3.2 Skjematisk oversikt Her gjentas en stor del av begrepene fra Termer og definisjoner. Det er vanskelig å skjønne hva som er tatt som forutsetninger og hva som er nye krav som innføres her. Det er samme blanding mellom hva som er tjenestebasert adressering og hva som er krav til adresseregister og oppføringene der som vi kommenterte i definisjonene. Igjen så kommer kravene før man har forklart hensikten eller begrunnelsen
3. Tjenestebasert adressering 3.3 Adressering i meldingsinstans Her blander man sammen nivåene i kommunikasjon på en slik måte at man lager unødig sammenblanding mellom de forskjellige lagene i meldingsutvekslingen. Det blir en sammenblanding av transportnivå, kommunikasjonsnivå og applikasjonsnivå. Samtidig så tar man ikke med hele bildet, men lar det stå så uklart at man ikke helt vet hva som menes. Hvis det skal være et slikt en-til-en forhold mellom ebxml MessageHeader og KITH MsgHead så ser det ut fra skissen her ut som en av dem er overflødig. Vi kunne like gjerne kjørt uten MsgHead da partene er de samme og har man HER-id på nivå 2 så er HER-id på nivå 1 også kjent (f.eks fra adresseregisteret når man fant nivå 2) og skal ikke benyttes til noe Skulle det vært noen teknisk kobling som hadde mening mellom MsgHead og ebxml MessageHeader ville det vært mer fornuftig å definere at det var nivå 1 som skulle stå i ebxml. Da ville MsgHead gi verdi internt i virksomheten for å fortelle hvordan meldingen skulle rutes videre. Slik det er definert her så er det allerede gitt fra ebxml laget. Men, siden det i enkelte tilfeller vil være slik at enkelte tjenester har adskilt teknisk infrastruktur fra andre så ser vi at det for noen virksomheter så kan det medføre komplikasjoner som ikke kan løses med en en-til-en kobling. Som eksempel på uklarhetene vi opplever så definerer man at ebxml transporten skal stiles til «kommunikasjonspart» på nivå 2 i hodemelding. Mens det ved siden av står at en melding skal være signert med «avsenders» sertifikat. Det går ikke klart fram hva som menes med avsender. Normalt vil avsender i en kommunikasjon være en av de to kommunikasjonsparter i en bilateral utveksling. Hvis mottaker og avsender ikke er kommunikasjonsparter, hva er de da? Det kan virke på teksten ellers som at man mener noe annet, uten at dette er tydelig definert. Det defineres her at informasjon om ansvarlig helsepersonell IKKE skal ligge i hodemeldingen, men kun i fagmeldingen. Vi vil på prinsipielt grunnlag spørre hvorfor data om pasienten skal ligge i hodemeldingen? Dette kunne også med fordel flyttes inn i fagmeldingen. Da kan applikasjoner som behandler fagmeldingen og har et forhold til pasienten forholde seg kun til dette og ikke trenge å gå inn i hodemeldingen. Hvis tjenesten for eksempel er «Assistert befruktning» ved OUS så har dette HER-id 112078 og en eventuell henvisning kan rutes direkte til fagsystem for dette før man har behov for å vite hvilken pasient som henvises. Dette vil også gjøre at Hodemeldingen gjøres fri for personsensitive data og at personsensitive data kun er tilgjengelig i systemer som har tjenestlig behov for dette. For eksempel så er det relativt lite sensitivt at tjenesten Fastlege på Sentrum Legekontor henviser noen til Assistert Befrukting på Oslo Universitetssykehus HF, mens det er absolutt sensitivt at pasient Eleonora Helmer fnr 12121223456 henvises til Assistert Befruktning. En endring som gjør at helsepersonell ikke lenger skal stå i hodemeldingen vil medføre tilhørende endringer i fagmeldinger likevel så vi syns det bør sterkt vurderes å gjøre det fullt og helt, ikke stykkevis og delt og i så fall fjerne pasienten også. 3. Tjenestebasert adressering 3.4 Krav til tjenestebasert adressering Vi er helt enige i at det ikke trenger være et en-til-en forhold mellom tjenester og de tekniske løsningene bak. Det trenger ikke engang være en større virksomhet for dette. Selv en selvstendig fastlege som jobber alene på et lite sted vil antagelig ha både rollene Fastlege, Sykehjemslege og Legevaktslege som fort kan defineres som tre separate tjenester. Men når man her plutselig begynner å snakke om at «flere tjenester kan være knyttet til samme kommunikasjonspart» da begynner det å halte litt. Hittil har det jo vært definert at det er den enkelte tjenesten som er kommunikasjonspartet.
Og så omtaler man at det kan være felles EPJ system som har en tilhørende EDI-adresse, mens man hopper helt over det faktum at det i alle systemer i bruk i dag er en form for kommunikasjonssystem på utsiden av EPJ systemet og at det ikke er ukjent at et kommunikasjonssystem deles av flere EPJ systemer. 3. Tjenestebasert adressering 3.5 Krav til registrering i adresseregisteret Hele dette underkapittelet burde fjernes og erstattes av et separat dokument som omtaler krav til registrering i Adresseregisteret. Og kravene bør være mye høyere enn dette og blant annet dekke hvilke meldingstyper men kan utveksle og i hvilke versjoner, samt alle de tekniske opplysningene som trengs for elektronisk samhandling i helsesektoren uansett om det er ebxml, AMQP, Web Service eller andre samhandlingsformer. Dokumentet bør være utfyllende og angi måtene man vedlikeholder informasjonen teknisk, enten det er med CPP, CPA, Web Service eller annet. Da vil man ha ett dokument å forholde seg til for å ha sine data korrekt oppført i adresseregisteret og ikke måtte forholde seg til flere delvis motstridende avsnitt i en mengde dokumenter. 4. Bruk av identifikatorer Mye av det som står her er gjentatt fra tidligere og vi vil ha samme kommentarer. Hele dette bør gjennomgås på nytt. 4. Bruk av identifikatorer 4.2 Bruk av HER-id på transportnivå ebxml rammeverket beskriver IKKE at det ikke kan være både organisasjonsnummer og HER-id i ebxml konvolutten. ebxml rammeverket beskriver at If either the From or the To elements contains multiple PartyId elements, all members of the list MUST identify the same organization. Med andre ord er det slett ikke noe i ebxml standarden som hindrer at man både kan bruke orgnr på virksomheten og HER-id på samme eller lavere nivå. Det er som kjent ikke mulig for en HER-id å tilhøre flere virksomheter, altså er det i tråd med kravet om at alle elementene må tilhøre samme virksomhet. 5. HER-id og adresseopplysninger i Hodemelding og fagmeldinger med HCP struktur Vi mener at det ryddige hadde vært å gå helt over til strukturen i hodemelding og fjerne HCP struktur både i Apprec og i eldre fagmeldinger. Systemer som er tilpasset eksisterende bruk vil sannsynligvis uansett måtte endres og da er det bedre å endre det til én felles struktur enn å fortsette med to strukturer som ikke helt matcher hverandre. De eksisterende meldingene får bare fortsette parallelt inntil de kan erstattes av ny struktur. Det er absolutt mest fremtidsrettet å få alt over på ny struktur framfor å holde på de eksisterende som i beste fall er forvirrende og som regel en kompliserende måte å håndtere data på. 6. Adresseringsprinsipper i Applikasjonskvittering Som for kapittel 5 så mener vi at når man først endrer på hva som skal ligge i hodemeldingen med de endringer i applikasjoner og fagmeldinger som dette medfører så bør man også innføre en Apprec 2.0 med adresseringsstruktur som i hodemeldingen slik at problemene med å mappe fram og tilbake elimineres og man kan bruke eksakt det avsender identifiserte seg som mottaker i Apprec. Det vil være det man er sikrest på kan håndteres korrekt når Apprec kommer tilbake til systemet som sendte den originale meldingen. Noen ytterligere kommentar uansett formen på Apprec som benyttes.
Siden hele dokumentet handler om tjenestebasert adressering, hvorfor brukes det så mye plass på å angi hvordan enkeltpersoner angitt i hodemelding skal mappes til HCP i Apprec? Er ikke hele poenget at helsepersonene IKKE skal identifiseres i hodemelding (og Apprec) Det angis som et eksempel at to leger ved samme legekontor kan være mottaker av en epikrise. Dette skal slik vi skjønner det ikke være mulig med tjenestebasert adressering, man angir kun tjenesten og ikke den enkelte lege. Dersom man likevel skal kunne angi en lege, så spesifiseres det at all adresseinformasjon fra opprinnelig melding skal returneres i Apprec. Hvis da en melding er sendt til Dr. Hansen og Dr. Olsen ved Sentrum Legekontor. Hvis så Dr. Hansen har sluttet og Dr. Jensen har tatt over for han, skal da Apprec fortsatt komme fra Dr. Jensen og Dr. Olsen? Slik at avsender av opprinnelig melding tror at Dr. Olsen har sett den og aldri får vite om Dr. Jensen? Det ser ut for oss som hele kapittel 6 bryter med både prinsippene og grunntankene for tjenestebasert adressering. Men det er ikke angitt som noe spesielt unntak. Undergraver ikke dette hele prinsippet? Eksemplene i vedleggene har vi ikke gått inn på da vi mener forutsetningene for eksemplene må rettes før det har noen hensikt å gå inn på detaljene i dem.