Sentral Forskrivningsmodul. Implementasjonsguide v1.0

Transkript

1 Sentral Frskrivningsmdul Implementasjnsguide v1.0

2 Tittel: Sentral Frskrivningsmdul - Implementasjnsguide Utgitt: (v0.8) (v0.9) (v1.0) Utgitt av: Direktratet fr e-helse Kntakt: pstmttak@ehelse.n Besøksadresse: Verkstedveien 1, 0277 Osl Tlf.:

3 Innhld 1 Innledning Overrdnet beskrivelse Intrduksjn SFM sm del av e-resept kjeden Alternative integrasjner Hvrdan kmme i gang? Registrering av klient i HelseID Bruk av accesstken, audience g exchangetkens fra HelseID Bruk av FHIR APIene Knfigurasjn Sikkerhetsmekanismer Bruk av accesstken /refreshtken Bruk av SFM Pasientbillett Bruk av SFM GUI Tykklient EPJ, sm integrerer SFM GUI Skybasert EPJ, sm integrerer SFM GUI Bruk av CmWrapper SFM Datadeling API Bruk av HTTP URL, verb g søkeparametre Eksempler på bruk av RESTful FHIR: SFM Basis API Kntakt g lenker Lenker Kntaktinfrmasjn Vedlegg Signering av resept Signatur på resept Signatur basert på HelseID med persn-id g virksmhetssertifikat Signatur basert på persnlig sertifikat Reseptfrmidlerens kntrll g videre behandling Definisjner:

4 1 Innledning Denne implementasjnsguiden tilbyr støtte til EPJ-leverandører sm ønsker å integrere mt SFM. Versjn 1.0 av denne implementasjnsguiden tilgjengeliggjøres fr EPJ-leverandører september 2019, slik at interesserte leverandører kan starte frberedelser fr kmmende integrasjner mt SFM. Implementasjnsguiden beskriver: Hvrdan kmme i gang Hvrdan registrere klient i HelseID (eksempelkde) Hvrdan bruke accesstken, audience g exchagetken fra HelseID (eksempelkde) Hvrdan bruke SFM pasientbillett (eksempelkde) Hvrdan bruke FHIR APIene Hvrdan benytte SFM GUI (eksempelkde) Spesifikasjn av Datadeling API Spesifikasjn av Basis API Tilhørende eksempelkde vil være tilgjengelig på GitHub, se "Hvrdan kmme i gang" fr mer beskrivelse. NB! Endringer i spesifikasjner g eksempelkde må frventes fram til endelig versjn av SFM freligger g er gdkjent fr prduksjn. Dette skyldes flere faktrer: SFM er under utvikling, g det må tas høyde fr endringer i behv g eksterne systemer Bruksmønster fr HelseID er under avklaring FHIR spesifikasjn vil endres sm følge av knytning mt nasjnale basis-prfiler basert på R4 (er under utvikling/i standardiseringsprsess). tilbakemeldinger fra utvikling av API g funksjnalitet tilbakemeldinger fra EPJ-leverandører detaljer er ikke på plass før API er implementert Bruksmønster fr API Basis er i tidlig fase g må avklares med kmmende knsumenter API design frutsetter Pasientens legemiddelliste. Dersm det skal tas i bruk før PLL er innført vil det kunne kmme nødvendige endringer. 4

5 2 Overrdnet beskrivelse 2.1 Intrduksjn E-resept er innført i hele landet g nå er ver 90% av alle resepter sm ekspederes i Nrge elektrniske. Det er imidlertid identifisert flere utfrdringer knyttet til e-resept g videre utbredelse. Sentrale punkter sm Sentral frskrivningsmdul (SFM) skal løse er: sikre gd frskrivningsfunksjnalitet fr alle rekvirenter sikre ppfyllelse av lver g frskrifter sikre effektiv frvaltning av e-resept kjeden øke pasientsikkerheten gjennm økt kvalitet på infrmasjn sm leveres til Reseptfrmidleren (RF), utbredelse av e-resept g effektiv sluttbrukerfunksjnalitet SFM løsningen skal dekke behvene til ulike brukergrupper g i frskjellige brukssituasjner. Løsningen skal understøtte brukere sm jbber i fastlegevirksmheter, avtalespesialistvirksmheter, legevakt, kmmunal pleie- g msrgssektr (hjemmetjeneste, KAD, sykehjem), tannlegeklinikker g helsestasjner. Fr en verrdnet beskrivelse av SFM, se her: SFM sm del av e-resept kjeden SFM er en legemiddel- g rekvireringsmdul sm skal kunne integreres med andre deler av brukerens EPJ. Figuren under illustrerer hvrdan SFM tjenester gjøres tilgjengelig gjennm SFM GUI (brwser i EPJ-GUI) g datadelings API (API mt EPJ server). SFM vil driftes sentralt g løsningen vil bli tilgjengeliggjrt i Helsenettet. 5

6 Fr helsereginene vil SFM tilby et eget API sm er basert på at helsereginene ikke benytter SFM GUI g dermed utvikler all brukerfunksjnalitet i deres respektive løsninger. API-et (Basis API) skal bidra til å øke kvaliteten på det sm leveres fra EPJ til RF, redusere mfang av endringer sm må implementeres i EPJ g levere data fra sentrale kilder slik at bruker på en effektiv måte får tilgang til relevant infrmasjn. I kmmunikasjnen mellm EPJ g SFM så stilles det krav til bruk av access tken fra HelseID (uavhengig m det er datadelings API eller Basis API). Dette brukes til å autentisere brukere i SFM løsningen. Det frutsettes at EPJ har funksjnalitet fr å registrere løsningen sm en klient i HelseID, støtter nivå 4 pålgging fr sluttbruker g fr å håndtere tkens sm gir sluttbruker tilgang til SFM. Dkumentasjn g eksempelkde er utarbeidet fr å understøtte at den enkelte EPJ leverandør raskt kan implementere dette. Fr å ivareta videre kmmunikasjn med andre tjenester benytter SFM tken exchange funksjnalitet sm HelseID tilbyr. SFM sender da mttatt Access tken til HelseID g ber m å få byttet det til nye exchange tken sm gir SFM rett til å gjøre spørringer mt andre tjenester (Kjernejurnal, Reseptfrmidleren, Helf) på vegne av sluttbruker (persn g rganisasjn). Exchange tken sm SFM mttar fra HelseID benyttes gså sm identitetsbevis i frbindelse med signering av resept (se vedlegg). 6

7 2.3 Alternative integrasjner Sm indikert ver så kan EPJ velge m de vil benytte SFM GUI med tilhørende datadelings API eller m de vil benytte SFM Basis API. I alternativ 1: EPJ integrerer SFM GUI i arbeidsflaten g benytter SFM datadelings API fr utveksling av pasientdata. Fr bruker så vil SFM ppleves sm en integrert del av løsningen, men "lk and feel" vil kunne være ne frskjellig fra EPJ. Pasientens legemiddeldata lagres da sentralt i SFM g SFM deler infrmasjn med EPJ gjennm datadelings API-et. Bruk av alternativ 1 krever at EPJ har implementert integrasjn g bruk av HelseID, bruk av embeded brwser/iframe g bruk av SFM datadelings API. Fr å ivareta persnvern på best mulig måte så benyttes en "pasient billett" fr at pasientens fødselsnummer ikke skal ekspneres i url. Denne må hentes via spørring i SFM datadelings API. I alternativ 2: EPJ benytter egen legemiddelmdul g kmmuniserer med SFM basis API. Pasientens legemiddeldata er da lagret i det enkelte EPJ g SFM gir et frenklet grensesnitt mellm EPJ g sentrale tjenester. SFM sammenstiller infrmasjn fra sentrale registre g leverer til EPJ, samt kvalitetssikrer infrmasjn sm leveres fra EPJ før det leveres til RF. 7

8 3 Hvrdan kmme i gang? Nedenfr beskrives de enkelte aktivitetene sm må gjøres fr kmme i gang med integrasjn mt SFM. Følgende eksempelkde med tilhørende dkumenter er tilgjengelig på GitHub g Swagger, g vil bli referert til i delkapitlene nedenfr: HelseIdSampleApp - HelseId sample applicatin v1.0: Registrering av klient i HelseID basert på Dynamic Client Registratin (DCR) API fra HelseID. (Ikke klart pr. 30. september 2019) CmWrapperApp - COM Wrapper sample v1.0: Bruk av accesstken med tilhørende claims fra HelseID Bruk av SFM pasientbillett "Endpint" fr rett SFM-miljø er knfigurerbart i COMWrapperSampleApp/appsetting.jsn : Ruter is (fretrukket) Ruter is (hyppige endringer) WebEPJSampleApp - Web basert EPJ eksempel: Hvrdan integrere SFM fra en WEB basert EPJ inklusive pasientbillett g HelseID "Endpint" fr rett SFM-miljø er knfigurerbart i WebEpj/appsetting.jsn : Ruter is Ruter is SFM API - Swagger: M-API%20V1 Detaljer g bruk av FHIR APIene NB: Pr 30. september 2019 er endelige endpints (URL) fr API ikke definert. API sm i dag heter /fhir er API Datadeling g vil få nytt navn nå API Basis blir definert. Se gså fr ppdatert infrmasjn m linker g testmiljø. Eksempelkde er utviklet i.net. Det er ikke planer m å utvikle alternativ kde i andre utviklingsmgivelser eller språk. 8

9 3.1 Registrering av klient i HelseID NOTE: Fram til HelseID v 2.0 er lansert første halvår 2020 vil det være manuell ppsetting av klienter i test, g prsjektet støtter ikke DCR funksjnalitet. HelseID tilbyr et eget API fr knfigurering av klienter. Dette APIet, Dynamisk Klientregistrering, beskyttes selvsagt gså av HelseID, g fr å kunne benytte dette APIet må man først pprette en initiell klient manuelt, sm man benytter videre fr å pprette nye klienter. 1) Manuell ppretting av initiell klient gjøres ved å ta kntakt med SFM-prsjektet, sm vil ppgi nødvendige parameterinnstillinger fr klienten sm skal kunne registrere nye klienter. 2) Knfigurasjn av nye HelseID klienter: HelseId sample applicatin. v innehlder eksempelkde fr hvrdan man benytter APIet fr å knfigurere nye HelseID klienter. Typisk vil en EPJ-leverandør pprette klienter fr sine kunder per installasjn via denne funksjnaliteten. Eksempelkden dekker følgende steg, ved knfigurasjn av en ny HelseID klient: Hente gyldig accesstken fra HelseID Bruke accesstkenet ved bruk av Dynamisk Klientregistrerings API fr å pprette en ny klient Bruke accesstkenet ved bruk av Dynamisk Klientregistrerings API fr å knytte den registrerte klienten til rganisasjns-id. Knfigurere API-tilgang (audience) til SFM fr den nye klienten. Les mer m Dynamisk Klientregistrering på NHN sine nettsider: Se mer dkumentasjn av HelseID på NHN sine nettsider: Bruk av accesstken, audience g exchangetkens fra HelseID EPJ må implementere støtte fr å be HelseID m access tken med audience til SFM g funksjn fr å frnye tkens. Løsningen vil på denne måten understøtte single-sign-n fr lkal innlgging, bruk av SFM g kmmunikasjn med bakenfrliggende tjenester. COM Wrapper sample v1.0 innehlder eksempelkde. Følgende prssessteg må dekkes: 1. Åpne brwser fr nivå 4 pålgging fr bruker 2. Benytt id tken g spør HelseID m access tken 3. Benytt access tken fr å etterspørre pasientbillett fr kmmunikasjn med SFM 9

10 4. Benytte pasientbillett fr å etterspørre pasientdata fra SFM 5. SFM benytter exchangetken g slår pp i KJ 6. Levering av pasientdata 7. Frnying av accesstken før kmmunikasjn m ny pasient 3.3 Bruk av FHIR APIene FHIR (Fast Healthcare Interpereable Resurces - er basert på at resurces tilgjengeliggjøres i et API. Det er gså muligheter fr kmmander g søkeparametre, gjennm standard mekanismer. FHIR spesifikasjnene er uavhengig av teknlgi, men går likevel langt i å spesifisere tilnærming til REST. Se gjerne mer her: Ressursene er dkumentert g FHIR Implementatin Guides publiseres på Ressurser kan utvides "lagvis" med extensins, g det gjøres på flere plan: HL7 har presentert Release 4 av standarden, samtidig sm det spesifiseres Nrske basisprfiler av HL7 Nrge: SFM prsjektet deltar i arbeidet, g spesielt ressursene sm berører legemiddelfeltet kan endre seg i løpet av prsjektet. SFM API blir dkumentert både på simplifier.net g på Swagger: Se link ver. Swaggerdkumentasjnen går i detaljer på implementasjnen av FHIR i SFM API g dkumenterer bruk av http, HelseID-tkens g pasientbillett sammen med FHIR ressursene. 10

11 Fr å teste SFM API kan det benyttes standard verktøy sm f.eks. Pstman, eller det kan bygges en enkel testklient fr å aksessere SFM API. Det finnes biblitek fr FHIR til flere utviklingsplattfrmer, men freløpig må extensins behandles manuelt. Eksempelet nedenfr viser Get Patient. "SFM API" består av Internt API, Datadeling API g Basis API. Se freløpig etter de sm har FHIR i navnet, Ressursene finnes på Simplifier. 3.4 Knfigurasjn Fr testfrmål er ppsett av SFM tjeneste per i dag en manuell prsess hvr EPJ-leverandør må etterspørre tjenesten hs Direktratet fr e-helse. 11

12 Fr testfrmål er ppsett av SFM tjeneste per i dag en manuell prsess hvr EPJ-leverandør må etterspørre tjenesten hs Direktratet fr e-helse. Leverandørspesifikk database fr test - E-helse ønsker at hver leverandør har hver sin database å teste mt, slik at ikke feil fra en aktør påvirker andre aktører. Testdata - Fr testfrmål pprettes et eget legekntr i AR sm benyttes til integrasjn mt SFM. Prsjektet tildeler pasienter sm leverandør kan bruke til testing. E-resept ønsker kntrll med hvilke pasienter sm får resept med ny type signatur slik at test mt aptek g Helf kan krdineres. Virksmhetssertifikater skal ppfylle krav til e-resepts testmiljø (Buypass test4 eller ekvivalente). 12

13 4 Sikkerhetsmekanismer Det er en rekke sikkerhetsmekanismer invlvert i SFM spesielt, g e-reseptkjeden generelt. I arbeidet med knsept g løsning fr Sentral frskrivningsmdul var GDPR på vei inn sm gjeldende lv i Nrge, g samtidig ble HelseID tilgjengeliggjrt sm tillitsanker fr helsesektren. Dette åpnet fr å tenke nytt på nen mråder hvr det allerede var etablert sikkerhetsmekanismer, samt å etablere gd sikring av løsningen der hvr det skal bygges nytt g flytte etablerte mekanismer sentralt. Knseptuelt g juridisk er SFM g EPJ en del av samme jurnalsystem fr integrasjner utenfr sykehus. Den frittstående frskrivningsmdulen benyttes på samme måte, men driftes vanligvis i samme miljø sm EPJ. Med sentraliseringen dukket det pp behv fr sikring av kmmunikasjnen mellm EPJ g SFM. Denne kmmunikasjnen består av EPJtilgang til pasientens legemiddeldata i SFM, samt all kmmunikasjn sm fregår i brukergrensesnitt. I denne kmmunikasjnen har vi basert sikringen på nen prinsipper, men detaljer kan bli justert underveis i utviklingen: Identitet til pasient skal, så langt det lar seg gjøre, ikke kmmuniseres sammen med medisinsk infrmasjn Før datautveksling eller brukergrensesnitt m pasientens data kan startes må EPJ hente en midlertidig "pasientbillett" sm benyttes i videre kmmunikasjn. Se under. SFM er sikret med HelseID - både på klient/rganisasjnsnivå g fr brukeren - sm identifiserer seg via f.eks IDprten. API beskyttes med TLS Database skal ikke ha innebygget knytning mellm pasientens identitet g pasientens data. SFM må benytte en krypteringsmekanisme fr å pprette sammenhengen. Innhld i database er kryptert 4.1 Bruk av accesstken /refreshtken HelseID er basert på OAuth 2.0 g skal være en løsning fr helsesektren sm tilbyr: Felles pålggingsløsning Tillitsanker fr sektren Sikring av API'er Løsningen er basert på at en klient (et bestemt system installert i en bestemt rganisasjn) er frhåndsregistrert hs HelseID g kan be m et bevis (tken) fra HelseID sm bekrefter at systemet er den det utgir seg fr å være. Tkenet er et JSON Web Tken (JWT) sm innehlder kder sm bekrefter utgiver g system. Tken kan gså berikes med infrmasjn m innlgget persn, g støtter innlgging via IDprten på høyt nivå. Tkenet er signert av HelseID g kan verifiseres. Ved å be m et accesstken kan et system dermed benytte seg av et API, g dersm sikringsmekanismene ellers er gde kan API-tilbyder stle på innhldet. Frdi systemet gir 13

14 fra seg tkenet (til den sm tilbyr API) er det tkenet sm definerer hvilket API/ressurs det er ment å gi tilgang til. Accesstken har relativt krt levetid. Klienten kan gså be m et refreshtken sm har lengre levetid, g kan benytte dette til å frnye aksesstken så lenge refreshtkenet lever. SFM er bygget på en slik måte at API kall sm kmmer inn, eller funksjner sm gjøres i GUI medfører innmelding av pplysninger eller ppslag i sentrale systemer sm skal gjøres på vegne av klienten/brukeren sm benytter SFM. SFM er derfr knfigurert i HelseID til å kunne utføre en "tken exchange", altså å bytte ut et tken med audience fr SFM, til et tken sm gir tilgang til f.eks. Reseptfrmidleren. Tkenet vil da innehlde pplysninger m pprinnelig klient, m SFM sm har byttet tken g audience fr å gi tilgang til Resetfrmidlerens API. Fr mer infrmasjn m HelseID: Fr mer infrmasjn m JWT tken: Bruk av SFM Pasientbillett Fr å ivareta persnvern ved verføring av infrmasjn mellm EPJ g SFM, baseres kmmunikasjnen på en t-trinns mdell hvr EPJ etterspør en pasientbillett med begrenset varighet fr å kunne få tilgang til pasientinfrmasjn fra SFM g skrive pasientinfrmasjn til SFM. Pasientbilletten må benyttes i URL ved åpning av SFM GUI g ved bruk av SFM Datadelings API. Pasientbilletten fungerer sm en nøkkel mellm pasient ID g legemiddeldataene, slik at det ikke skal være mulig å finne fram til hvilke legemiddeldata sm er relatert til hvilken pasient. Eksempel på sekvens ved bruk av Pasientbillett er beskrevet i "Åpne pasient" i beskrivelsen av datadelingsapi: SFM Datadeling API. Pasientbilletten er unik fr SFM tjenesten g spesifisert slik at det ikke skal være mulig å gjette seg fram til en gyldig billett. Dette gjør gså at det ikke er mulig å skrive eller lese på tvers av virksmheter. Løsningen er på den måten feiltllerant. Spørringen fr tilgang til en pasientbillett skal innehlde en pasient-id (eg. fnr, dnr xxx-id). Siden billetten har begrenset levetid er det mulig å frnye billetten på lik linje med at systemet gså frnyer accesstken. Pasientbilletten er en tekststreng på maks 200 tegn. I dagens løsning er pasientbillett en GUID: f-4333-b6e8-1464a7f44608 Detaljert teknisk beskrivelse med eksempelkde fr å etterspørre pasientbillett er publisert på Github, se beskrivelse under hvrdan kmme i gang Ressursen PatientTicket er beskrevet på Swagger. 14

15 5 Bruk av SFM GUI SFM GUI er implementert i JavaScript fr bruk i standard brwser. Freløpig er SFM bare testet fr bruk i Chrme, g det er kjente feil knyttet til bruk i Edge. SFM anbefaler ikke bruk av IE. På sikt vil SFM bli testet fr bruk i flere brwsere. Eksemplene sm er tilgjengeliggjrt er basert på bruk av Chrme. SFM GUI kan benyttes både i en skybasert løsning g sm del av en tykk-klient. Fr å frenkle vergangen til bruk av SFM fr aktører sm i dag bruker FM, så utvikler SFM en tykk-klient (CmWrapper). Denne tjener gså sm eksempelkde fr aktører sm har tykk-klienter sm skal integrere med løsningen. Det er altså 3 frskjellige måter å benytte SFM GUI på. Disse er beskrevet under. 5.1 Tykklient EPJ, sm integrerer SFM GUI EPJ-systemene sm dminerer markedet i dag er typiske tykke klienter. I praksis er det windws-applikasjner sm kjøres enten på rekvirentens PC eller via en terminalserverløsing. SFM kan integreres i slike EPJer ved at EPJ benytter en brwserkmpnent i sin EPJ hvr SFM startes via en definert URL. SFM Pasientrettet prtal vil alltid startes i kntekst av et jurnalsystem, en bruker g en pasient. Før det kan startes en slik sesjn er det nødvendig at system g bruker er identifisert gjennm en sekvens med HelseID. Fr brukerinnlgging i ID-prten bør samme brwserkmpnent benyttes. Dette muliggjør innlgging på tvers via mekanismer i web/http. Det er gså nødvendig å initiere sesjn med enkeltpasient med SFM via API fr å ppnå en pasientbillett. Dette gjøres fr å minimere datatrafikk sm kmbinerer sensitive helsedata med pasienten det gjelder. Pasientens navn eller ID vil altså ikke kmmuniseres i påfølgende GUI sesjn g ikke være synlig inne i WEB GUI sm SFM presenterer. Det frutsettes at EPJ alltid viser hvilken pasient sm er åpnet i SFM. All nødvendig kde fr å realisere rammeverket i en tykk klient er eksemplifisert gjennm CmWrapper sm er tilgjengelig på Github. 15

16 5.2 Skybasert EPJ, sm integrerer SFM GUI Skybaserte EPJ systemer er på vei inn i markedet. Registrering av klienter i HelseID må gjøres per virksmhet fra serversiden av den skybaserte løsningen. Dette fr å sikre sterk knytting mellm virksmhet g klient-id sm igjen kan stles på av SFM. På den måten kan kdeeksempler sm tilbys fr knfigurering av HelseID benyttes på samme måte sm fr andre EPJ. I frbindelse med utstedelse av accesstken er det svært viktig at hemmelighet ikke blir ekspnert i brwser. Dette gjør at gså etterspørsel etter accesstken må basere seg på at det gjøres fra serversiden. Se frøvrig eksempelkde. Denne demnstrerer hvrdan EPJ etterspør pasientbillett g starter SFM GUI i en iframe. 5.3 Bruk av CmWrapper SFM CmWrapper kan benyttes av leverandører sm bruker FM, fr migrasjn til SFM med minimal utvikling. CmWrapper vil være tilgjengelig i en vergangsperide, men på relativt krt sikt vil den bli faset ut. CmWrapper kan benyttes med samme cm api sm i dag benyttes fr FM, men med ppdatert namespace. EPJ leverandør kan velge å implementere integrasjn mt HelseID, eller at bruker må lgge seg på når den åpner SFM, da det nye namespacet er utvidet med mulighet fr å verføre accesstken sm del av startpasient. Ved bruk av CmWrapper vil det være behv fr at det pprettes en klient-id uavhengig m det er EPJ eller Cmwrapper sm autentiserer bruker. Anbefalt løsning fra SFM er at EPJ utvikler støtte fr autentisering ved hjelp av HelseID g at Cmwrapper understøtter single-sign-n. I dette tilfellet trenger ikke Cmwrapper en egen secret fr å kmmunisere med HelseID. Ved bruk av Cmwrapper så vil det være ne begrenset funksjnalitet sm tilgjengeliggjøres. 16

17 6 SFM Datadeling API SFM Datadeling API skal benyttes av de leverandører sm velger å bruke SFM GUI. API-et skal da ivareta all datadeling mellm SFM g EPJ sm er nødvendig fr å ivareta pasientsikkerheten, persnvern g en effektiv arbeidsprsess. Guide fr bruk av SFM Datadeling API er publisert på: Ressursene sm benyttes i SFM Datadelings API er publisert på: Datadeling API publiserer ressurser g funksjner fr at EPJ system sm integrerer mt SFM, hvr SFM benyttes til frskrivning, kan få tilgang til data sm er prdusert i SFM, hentet fra nasjnale tjenester eller tidligere skrevet fra EPJ. API er ekspnert sm FHIR ressurser/tjenester basert på RESTful tilnærming. Nen sentrale funksjner sm tilbys i dette API er ikke rene CRUD perasjner. API er beskyttet med HelseID, g det er essensielt at SFM kan avlede infrmasjn m rganisasjnen g rekvirenten fra HelseID. I interaksjn mellm SFM g EPJ er det så langt mulig frsøkt å separere infrmasjn m pasientens navn eller identitet fra annen sensitiv infrmasjn. Det er derfr støtte fr at EPJ innleder en pasientsesjn med å skaffe seg en pasientbillett fra SFM, sm kan benyttes i videre dialg. Dette benyttes både i API g i datatrafikk sm understøtter GUI. 6.1 Bruk av HTTP URL, verb g søkeparametre Generell beskrivelse av FHIR g bruk av RESTful HTTP: Nrmale perasjner benyttes fr standardressurser 6.2 Eksempler på bruk av RESTful FHIR: Ressurs: sfm-task (ppgave til SFM bruker) Read: GET [urlbase]/sfm-task/[id] sfm-task med ppgitt ID blir returnert sm ressurs i HTTP bdy Search: GET [urlbase]/sfm-task/[id]?wner=practitiner/[id] Search: GET [urlbase]/sfm-task/[id]?status=in-prgress Task-er sm matcher søkekriteriet returneres i en Bundle. Se: fr detaljer Update: PUT [urlbase]/sfm-task/[id] Benyttes til å ppdatere sfm-task med ny status. 17

18 7 SFM Basis API Basis API publiserer ressurser g funksjner sm SFM tilbyr fr integrasjn mt nasjnale tjenester fr aktører sm har egen legemiddelmdul, men sm ønsker å benytte FHIR API sm alternativ til annen integrasjn mt Reseptfrmidleren (RF), Kjernejurnal (KJ) g andre tjenester sm SFM representerer. Denne integrasjnen vil typisk benyttes av sykehus g andre større installasjner sm ikke benytter frskrivningsfunksjnaliteten i SFM (SFM GUI). Guide fr bruk av SFM Basis API er publisert på: Ressursene sm benyttes i SFM Basis API er publisert på: API er ekspnert sm FHIR ressurser/tjenester men på grunn av perasjnene sm gjøres i bakkant er det ikke en RESTful tilnærming. Sentrale funksjner sm tilbys i dette API er ikke rene CRUD perasjner, men avanserte perasjner hvr SFM gjør ppslag i flere tjenester, sammenstiller data g presenterer en kmpleks struktur sm FHIR dkument (Bundle/Cmpsitin). Operatins i FHIR understøtter dette paradigmet. API er beskyttet med HelseID, g det er essensielt at SFM kan avlede infrmasjn m rganisasjnen g rekvirenten fra HelseID. Ressursene n-organisatin g n-practitiner benyttes fr å ppdatere SFM med tilstrekkelig inf. 18

19 8 Kntakt g lenker 8.1 Lenker SFM har reservert dmentet frskrivning.n fr servere g API i løsningen. Det vil pprettes subdmener fr prduksjn g test. Prduksjnsmiljøet vil bare være tilgjengelig i Nrsk Helsenett. Oppdatert infrmasjn m lenker til ressurser i løsningen vil finnes på: Nen av lenkene gjengis her: Eksempelkde finnes på: Dkumentasjn av FHIR ressurser sm benyttes i SFM finnes på: Swagger dkumentasjn av tjenestene sm er tilgjengeliggjrt finnes på: API%20V1 8.2 Kntaktinfrmasjn Tekniske spørsmål sendes til: Dag Hammer: Dag.Hammer@ehelse.n Maria Rekdal: Maria.Rekdal@ehelse.n Ole Martin Winnem: lemw@enableit.n Spørsmål knyttet til ppsett av testmgivelser sendes til: Gunn Skgseth: Gunn.Skgseth@ehelse.n 19

20 9 Vedlegg Signering av resept Det har lenge vært klart at signering av XML-meldinger med bruk av persnlig sertifikat med privatnøkkel på smartkrt er en løsning sm skaper prblemer fr sentralisert drift. Det har vært prblematisk i nen Remte Desktp/Terminalserver løsninger, g direktratet har fått tilbakemeldinger m at det er en løsning sm er uegnet fr skybaserte eller web-baserte løsninger. Den pprinnelige signaturen på resepten har t frmål: Identifikasjn av rekvirenten, g integritetsbeskyttelse av meldingen. Denne spesifikasjnen beskriver både pprinnelig g alternativ signering med bruk av HelseID fr identifikasjn av rekvirent (g klientsystem) g PKI signatur fr integritetsbeskyttelse basert på virksmhetssertifikat. Løsningen er basert på utvidet tillit til systemet sm påfører signatur, altså SFM - g selvfølgelig tillit til HelseID g IDprten. Med denne løsningen ppnår vi raskere signering av resept i WEB-baserte løsninger, g pplevelse av gjennmført single-sign-n fr systemer sm støtter dette. Det er fremdeles et sentralt punkt at signeringen er en tydelig handling fr rekvirenten sm utfører den, med andre rd: Systemet sm påfører signatur med HelseID må gjøre dette sm et resultat av at helsepersnen valgte å signere (g sende). 9.1 Signatur på resept Resept kan signeres elektrnisk på t måter: Signatur basert på HelseID med persn-id g virksmhetssertifikat Signatur basert på persnlig sertifikat Begge disse kan benyttes, men den første er betinget av spesiell gdkjenning av systemet sm påfører signaturen g driftsleverandør fr systemet 20

21 Figur sm viser alternative signeringsmetder fr resept. SKO signaturen finnes bare på resepter sm utleveres til aptek g bandasjist (g videre til Helf) 9.2 Signatur basert på HelseID med persn-id g virksmhetssertifikat Signatur basert på HelseID påføres ved at systemet sm signerer resepten vedlegger JWT tken sm bekrefter rekvirentens identitet sm en knsekvens av handlingen "signer g send". Denne kblingen mellm signeringshandlingen g eksistensen av JWT tken er årsaken til at det kreves spesiell gdkjenning av system g driftsleverandør sm signerer etter denne metden. JWT tken fra HelseID skal ha følgende claims fr identitetsbekreftelse: helseid://claims/identity/pid: <nasjnal identitet> helseid://claims/identity/security_level: 4 helseid://claims/identity/assurence_level: high (det er andre krav til frmat g innhld i tken sm ikke er dekket her) JWT tken identitetsbevis legges til M1 sm vedlegg. Vedlegg er en standard mekanisme fr Hdemeldingen. Vedlegg til meldinger er beskrevet i eget dkument: JWT tken vedlegges i <RefDc> struktur på følgende måte: 21

22 <RefDc> <IssueDate V=" T09:30:12"/> <MsgType V="A" DN="Vedlegg"/> <MimeType>applicatin/jwt</MimeType> <Descriptin>HelseID</Descriptin> JWT tken skal BASE64 kdes g legges ved i: <Cntent> <Base64Cntainer...> (JWT tken) </Base64Cntainer> Signatur med virksmhetssertifikat påføres meldingen (M1) i eget felt spesifisert fr dette i Hdemeldingen (Signature): "Elektrnisk signatur. En XML-realisering av meldingen skal benytte XML Digital Signature i henhld til XML-Signature Syntax and Prcessing W3C Recmmendatin 12 February 2002, Signaturen skal være påført med virksmhetssertifikat på spesifisert nivå av driftsleverandøren sm sender inn resepten. Signaturen har etter denne metden t frmål: Driftsleverandøren digitale signatur på resept Integritetsbeskyttelse av innldet i en resept inkusive HelseID tken. Signatur etter denne metden inkluderer rekvirentens nasjnale id (persnnummer/dnummer) samt HPR nummer (helsepersnell ID) g rekvirentens identitet er således entydig g sikkert bekreftet. Identiteten benyttes fr ppslag i helesepersnellregisteret fr kntrll av autrisasjn g rekvireringsrett. 9.3 Signatur basert på persnlig sertifikat Fr signering av resept etter denne metden påføres meldingen (M1) et signaturelement i eget felt spesifisert fr dette i Hdemeldingen (Signature): "Elektrnisk signatur. En XML-realisering av meldingen skal benytte XML Digital Signature i henhld til XML-Signature Syntax and Prcessing W3C Recmmendatin 12 February 2002, Signaturen skal være påført med et Persnlig sertifikat på spesifisert nivå av rekvirenten sm sender inn resepten. Signaturen har etter denne metden t frmål: Rekvirentens signatur på resept Integritetsbeskyttelse av innldet i en resept. Signatur etter denne frmen inkluderer rekvirentens ffentlige sertifikat. Dette benyttes videre fr entydig g sikker identifikasjn av rekvirent via ppslag hs sertifikat-utsteder. Identiteten 22

23 benyttes fr ppslag i helesepersnellregisteret fr kntrll av autrisasjn g rekvireringsrett. 9.4 Reseptfrmidlerens kntrll g videre behandling Reseptfrmidleren gjør mfattende kntrller av autrisasjn g rekvireringsrett ved mttak av resept. I tillegg valideres signaturer g gyldighet av alle benyttede sertifikater. Deretter genereres en kpi av resepten med et signaturkntllbjekt (SKO) sm bekrefter valideringene g kntrllene sm er gjrt på mttakstidspunktet. SKO bjektet fungerer sm dkumentasjn av fretatt kntrll, samt at tilleggsinfrmasjn m rekvireringsrett g autrisasjn inkluderes. SKO signeres med Reseptfrmidlerens sertifikat. Resept med SKO benyttes på utleverersiden g danner grunnlag fr refusjnskrav fra utleverer. Resepter uten benyttes i rekvirentdelen av e-reseptkjeden. 23

24 9.5 Definisjner: Elektrnisk signatur Begreper knyttet til elektrnisk signatur er kmplisert. Dels er det verlappende begrepsbruk fr tiltenkt nøkkelbruk i sertifikatene, dels er det frskjellige nivåer av signatur. Begreper sm "avansert elektrnisk signatur" g "kvalifisert sertifikat" er ment å presisere dette. De t løsningene spesifisert i dette dkumentet har frskjellig tilnærming, men løser begge kravet til entydig g sikker identifikasjn av rekvirent, g beskyttelse mt endring av resept etter innsending (integritetsbeskyttelse) Persnlig sertifikat Sertifikat sm er utstedt til en persn av en Certificate Authrity sm er gdkjent fr bruk i e- resept, med plicy sm identifiserer det sm persnlig sertifikat: eller Nøkkelbruk (Key usage) fr signatur skal være Ikke-avvisning = Nn-repudiatin = Cntent cmitment (0x40) Sertifikatet skal minst støtte signatur-algritme sha256withrsaencryptin Virksmhetssertifikat Sertifikat sm er utsedt til en virksmhet, hvedenhet eller rganisasjnsledd av en Certificate Authrity sm er gdkjent fr bruk i e-resept, med plicy sm identifiserer det sm et virksmhetssertifikat: eller Sertifikatet skal minst støtte signatur-algritme sha256withrsaencryptin Elektrnisk resept Begrenses her til å mfatte meldingen M1 i gyldige versjner sm spesifisert av Direktratet fr e-helse. (Strengt tatt er resept sendt med telefaks mfattet av begrepet "elektrnisk kmmunikasjn" i persnvernsammenheng, men det er ikke relevant her). HelseID Tjeneste g frmat fr sikker identifikasjn av systemer g persner i helsetjenesten. Integrert med nasjnale identitetstilbydere. Hdemeldingen Struktur i XML fr kding av meldinger i helsesektren. Utgjør i denne sammenheng meldingen "M1 - Resept" med fagmelding "Resept", seksjn fr avsender, mttaker g pasient g signatur. Se egen definisjn fr detaljer. 24

25 Besøksadresse Verkstedveien Osl 25