Sentral Forskrivningsmodul. Implementasjonsguide v0.9

Sentral Forskrivningsmodul Implementasjonsguide v0.9

Tittel: Sentral Forskrivningsmodul - Implementasjonsguide Utgitt: 31.10.2018 (v0.8) 24.06.2019 (v0.9) Utgitt av: Direktoratet for e-helse Kontakt: postmottak@ehelse.no Besøksadresse: Verkstedveien 1, 0277 Oslo Tlf.: 21 49 50 70 2

Innhold 1 Innledning... 5 2 Overordnet beskrivelse... 6 2.1 Introduksjon... 6 2.2 SFM som del av e-resept kjeden... 6 2.3 Alternative integrasjoner... 7 3 Hvordan komme i gang?... 9 3.1 Registrering av klient i HelseID... 10 3.2 Bruk av accesstoken, audience og exchangetokens fra HelseID... 10 3.3 Bruk av FHIR APIene... 11 3.4 Konfigurasjon... 13 4 Sikkerhetsmekanismer... 14 4.1 Bruk av accesstoken /refreshtoken... 14 4.2 Bruk av SFM Pasientbillett... 16 5 Bruk av SFM GUI... 18 5.1 Tykklient EPJ, som integrerer SFM GUI... 18 5.2 Skybasert EPJ, som integrerer SFM GUI... 19 5.3 Bruk av ComWrapper... 19 6 SFM Datadeling API... 20 6.1 Arbeidsflyt Datadeling... 20 6.1.1 Ressurs- og interaksjonsoversikt... 21 6.1.2 Opprette/endre helseperson... 25 6.1.3 Opprette/endre pasient... 26 6.1.4 Åpne pasient i EPJ/Se oppgaveliste... 27 6.1.5 Åpne Pasient... 28 6.1.6 Forskrive legemiddel... 30 6.1.7 Korrespondanse... 30 6.1.8 Administrer pasientens legemidler og næringsmidler... 31 6.2 Datadeling - API... 32 6.2.1 Bruk av HTTP URL, verb og søkeparametre... 32 6.2.2 Eksempler på bruk av RESTful FHIR:... 32 6.2.3 Swagger spesifikasjon:... 33 7 SFM Basis API... 34 7.1 Arbeidsflyt Basis... 34 3

7.1.1 Ressurs- og interaksjonsoversikt... 35 7.1.2 Les informasjon fra sentrale registre... 37 7.1.3 Lever informasjon til sentrale registre... 38 7.1.4 Spørring om endringer i sentrale registre... 39 7.1.5 Lokale endringer (asynkron kommunikasjon)... 40 7.1.6 Multidoseregistering... 41 7.2 Basis - API... 42 7.2.1 Bruk av HTTP URL, verb og søkeparametre... 42 7.2.2 Swagger spesifikasjon... 44 7.2.3 SFM Update Bundle... 44 8 Kontakt og lenker... 45 8.1 Lenker... 45 8.2 Kontaktinformasjon... 45 9 Vedlegg Signering av resept... 46 9.1 Signatur på resept... 46 9.2 Signatur basert på HelseID med person-id og virksomhetssertifikat... 47 9.3 Signatur basert på personlig sertifikat... 48 9.4 Reseptformidlerens kontroll og videre behandling... 49 9.5 Definisjoner:... 50 4

1 Innledning Denne implementasjonsguiden tilbyr støtte til EPJ-leverandører som ønsker å integrere mot SFM. Versjon 0.9 av denne implementasjonsguiden tilgjengeliggjøres for EPJ-leverandører juli 2019, slik at interesserte leverandører kan starte forberedelser for kommende integrasjoner mot SFM. Implementasjonsguiden beskriver: Hvordan komme i gang o o o o Hvordan registrere klient i HelseID (eksempelkode) Hvordan bruke accesstoken, audience og exchagetoken fra HelseID (eksempelkode) Hvordan bruke SFM pasientbillett (eksempelkode) Hvordan bruke FHIR APIene Hvordan benytte SFM GUI (eksempelkode) Spesifikasjon av Datadeling API Spesifikasjon av Basis API Tilhørende eksempelkode vil være tilgjengelig på GitHub, se "Hvordan komme i gang" for mer beskrivelse. NB! Endringer i spesifikasjoner og eksempelkode må forventes fram til endelig versjon av SFM foreligger og er godkjent for produksjon. Dette skyldes flere faktorer: SFM er under utvikling, og det må tas høyde for endringer i behov og eksterne systemer Bruksmønster for HelseID er under avklaring FHIR spesifikasjon vil endres som følge av o harmonisering mot gjeldende versjon av FHIR standarden (Release 4) o knyttning mot nasjonale profiler basert på R4 (som også er under utvikling). Bruksmønster for API Basis er i tidlig fase og må avklares med kommende konsumenter Forutsetter Pasientens legemiddelliste 5

2 Overordnet beskrivelse 2.1 Introduksjon E-resept er innført i hele landet og nå er over 90% av alle resepter som ekspederes i Norge elektroniske. Det er imidlertid identifisert flere utfordringer knyttet til e-resept og videre utbredelse. Sentrale punkter som Sentral forskrivningsmodul (SFM) skal løse er: sikre god forskrivningsfunksjonalitet for alle rekvirenter sikre oppfyllelse av lover og forskrifter sikre effektiv forvaltning av e-resept kjeden øke pasientsikkerheten gjennom økt kvalitet på informasjon som leveres til Reseptformidleren (RF), utbredelse av e-resept og effektiv sluttbrukerfunksjonalitet SFM løsningen skal dekke behovene til ulike brukergrupper og i forskjellige brukssituasjoner. Løsningen skal understøtte brukere som jobber i fastlegevirksomheter, avtalespesialistvirksomheter, legevakt, kommunal pleie- og omsorgssektor (hjemmetjeneste, KAD, sykehjem), tannlegeklinikker og helsestasjoner. For en overordnet beskrivelse av SFM, se her: https://ehelse.no/nasjonale-prosjekter/sentralforskrivningsmodul 2.2 SFM som del av e-resept kjeden SFM er en legemiddel- og rekvireringsmodul som skal kunne integreres med andre deler av brukerens EPJ. Figuren under illustrerer hvordan SFM tjenester gjøres tilgjengelig gjennom SFM GUI (browser i EPJ-GUI) og datadelings API (API mot EPJ server). SFM vil driftes sentralt og løsningen vil bli tilgjengeliggjort i Helsenettet. 6

For helseregionene vil SFM tilby et eget API som er basert på at helseregionene ikke benytter SFM GUI og dermed utvikler all brukerfunksjonalitet i deres respektive løsninger. API-et (Basis API) skal bidra til å øke kvaliteten på det som leveres fra EPJ til RF, redusere omfang av endringer som må implementeres i EPJ og levere data fra sentrale kilder slik at bruker på en effektiv måte får tilgang til relevant informasjon. I kommunikasjonen mellom EPJ og SFM så stilles det krav til bruk av access token fra HelseID (uavhengig om det er datadelings API eller Basis API). Dette brukes til å autentisere brukere i SFM løsningen. Det forutsettes at EPJ har funksjonalitet for å registrere løsningen som en klient i HelseID, støtter nivå 4 pålogging for sluttbruker og for å håndtere tokens som gir sluttbruker tilgang til SFM. Dokumentasjon og eksempelkode er utarbeidet for å understøtte at den enkelte EPJ leverandør raskt kan implementere dette. For å ivareta videre kommunikasjon med andre tjenester så benytter SFM token exchange funksjonalitet som HelseID tilbyr. SFM sender da mottatt exchange token til HelseID og ber om å få byttet det til nye access token som gir SFM rett til å gjøre spørringer mot andre tjenester (Kjernejournal, Reseptformidleren, Helfo). Access token som SFM mottar fra HelseID benyttes også som bevis i forbindelse med signering av resept (se vedlegg). 2.3 Alternative integrasjoner Som indikert over så kan EPJ velge om de vil benytte SFM GUI med tilhørende datadelings API eller om de vil benytte SFM Basis API. I alternativ 1: EPJ integrerer SFM GUI i arbeidsflaten og benytter SFM datadelings API for utveksling av pasientdata. For bruker så vil SFM oppleves som en integrert del av løsningen, men "look and feel" vil kunne være noe forskjellig fra 7

EPJ. Pasientens legemiddeldata lagres da sentralt i SFM og SFM deler informasjon med EPJ gjennom datadelings API-et. Bruk av alternativ 1 krever at EPJ har implementert integrasjon og bruk av HelseID, bruk av embeded browser/iframe og bruk av SFM datadelings API. For å ivareta personvern på best mulig måte så benyttes en "pasient billett" for at pasientens fødselsnummer ikke skal eksponeres i url. Denne må hentes via spørring i SFM datadelings API. I alternativ 2: EPJ benytter egen legemiddelmodul og kommuniserer med SFM basis API. Pasientens legemiddeldata er da lagret i det enkelte EPJ og SFM gir et forenklet grensesnitt mellom EPJ og sentrale tjenester. SFM sammenstiller informasjon fra sentrale registre og leverer til EPJ, samt kvalitetssikrer informasjon som leveres fra EPJ før det leveres til RF. 8

3 Hvordan komme i gang? Nedenfor beskrives de enkelte aktivitetene som må gjøres for komme i gang med integrasjon mot SFM. Følgende eksempelkode med tilhørende dokumenter er tilgjengelig på GitHub og Swagger, og vil bli referert til i delkapitlene nedenfor: HelseIdSampleApp - HelseId sample application v1.0: https://github.com/thulasource/helseidsampleapp o Registrering av klient i HelseID ComWrapperApp - COM Wrapper sample v1.0: https://github.com/thulasource/comwrappersampleapp o o o Bruk av accesstoken, audience og exchangetoken fra HelseID Bruk av SFM pasientbillett "Endpoint" for rett SFM-miljø er konfigurerbart i COMWrapperSampleApp/appsetting.json: i. Router endpoint @NHN is https://router.test1.forskrivning.no ii. Router endpoint @Thula is https://router.dev.sfm.cloud WebEPJSampleApp - Web basert EPJ eksempel: https://github.com/thulasource/webepjsampleapp o Hvordan integrere SFM fra en WEB basert EPJ inklusive pasientbillett og HelseID o "Endpoint" for rett SFM-miljø er konfigurerbart i WebEpj/appsetting.json : Router endpoint @NHN is https://router.test1.forskrivning.no Router endpoint @Thula is https://router.dev.sfm.cloud SFM API - Swagger: https://server.dev.sfm.cloud/index.html?urls.primaryname=fhir%20sfm- API%20V1 o Bruk av FHIR APIene Eksempelkode er utviklet i.net. Det er ikke planer om å utvikle alternativ kode i andre utviklingsomgivelser eller språk. 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 oppsetting av klienter i test, og prosjektet støtter ikke DCR funksjonalitet. HelseID tilbyr et eget API for konfigurering av klienter. Dette APIet, Dynamisk Klientregistrering, beskyttes selvsagt også av HelseID, og for å kunne benytte dette APIet må man først opprette en initiell klient manuelt, som man benytter videre for å opprette nye klienter. 1) Manuell oppretting av initiell klient gjøres ved å ta kontakt med SFM-prosjektet, som vil oppgi nødvendige parameterinnstillinger for klienten som skal kunne registrere nye klienter. 2) Konfigurasjon av nye HelseID klienter: HelseId sample application. v1.0-2018-10-11 inneholder eksempelkode for hvordan man benytter APIet for å konfigurere nye HelseID klienter. Typisk vil en EPJ-leverandør opprette klienter for sine kunder per installasjon via denne funksjonaliteten. Eksempelkoden dekker følgende steg, ved konfigurasjon av en ny HelseID klient: Hente gyldig accesstoken fra HelseID Bruke accesstokenet ved bruk av Dynamisk Klientregistrerings API for å opprette en ny klient Bruke accesstokenet ved bruk av Dynamisk Klientregistrerings API for å knytte den registrerte klienten til organisasjons-id. Konfigurere API-tilgang (audience) til SFM for den nye klienten. Les mer om Dynamisk Klientregistrering på NHN sine nettsider: https://www.nhn.no/helseid/teknisk-dokumentasjon/dynamisk-klientregistrering/ Se mer dokumentasjon av HelseID på NHN sine nettsider: https://www.nhn.no/helseid/ 3.2 Bruk av accesstoken, audience og exchangetokens fra HelseID EPJ må implementere støtte for å be HelseID om access token med audience til SFM og funksjon for å fornye tokens. Løsningen vil på denne måten understøtte single-sign-on for lokal innlogging, bruk av SFM og kommunikasjon med bakenforliggende tjenester. COM Wrapper sample v1.0 inneholder eksempelkode. Følgende prossessteg må dekkes: Åpne browser for nivå 4 pålogging for bruker Benytt id token og spør HelseID om access token 10

Benytt access token for å etterspørre pasientbillett for kommunikasjon med SFM Benytte pasientbillett for å etterspørre pasientdata fra SFM SFM benytter exchangetoken og slår opp i KJ Levering av pasientdata Fornying av accesstoken før kommunikasjon om ny pasient 3.3 Bruk av FHIR APIene FHIR (Fast Healthcare Interopereable Resources - https://www.hl7.org/fhir/) er basert på at resources tilgjengeliggjøres i et API. Det er også muligheter for kommandoer og søkeparametre, gjennom standard mekanismer. FHIR spesifikasjonene er uavhengig av teknologi, men går likevel langt i å spesifisere tilnærming til REST. Se gjerne mer her: https://www.hl7.org/fhir/http.html Ressursene er dokumentert på disse sidene som en del av prosjektarbeidet, men endelig versjon av ressurser og guide for bruk vil publiseres på https://simplifier.net/r4medication Ressurser kan utvides "lagvis" med extensions, og her arbeides det på flere plan: HL7 har presentert Release 4 av standarden, samtidig som det spesifiseres Norske basisprofiler av HL7 Norge: https://simplifier.net/hl7norwayno-basis. SFM prosjektet deltar i arbeidet, og spesielt ressursene som berører legemdiddelfeltet vil endre seg i løpet av prosjektet. SFM vil ha egne profiler av disse, men langsiktig mål er at det skal være profiler av de norske basisprofilene, som igjen skal være basert på FHIR Release 4. SFM sin prosjektside på Simplifier: https://simplifier.net/sfm 11

SFM API blir dokumentert både på simplifier.net og på Swagger: Se link over. Swaggerdokumentasjonen går i detaljer på implementasjonen av FHIR i SFM API og dokumenterer bruk av http, HelseID-tokens og pasientbillett sammen med FHIR ressursene. For å teste SFM API kan det benyttes standard verktøy som f.eks. Postman, eller det kan bygges en enkel testklient for å aksessere SFM API. Det finnes bibliotek for FHIR til flere utviklingsplattformer, men foreløpig må extensions behandles manuelt. Eksempelet nedenfor viser Get Patient. "SFM API" består av Internt API, Datadeling API og Basis API. Foreløpig er det ikke lagt inn filtrering i Swagger på internt APIer og Datadeling API (og fremtidig Basis API). Se foreløpig etter de som har FHIR i navnet, som er ressursene som er dekket av Datadeling API. Basis API er p.t ikke tilgjengelig via APIet, men foreløpig versjon av ressursene finnes på Simplifier. 12

3.4 Konfigurasjon For testformål er oppsett av SFM tjeneste per i dag en manuell prosess hvor EPJ-leverandør må etterspørre tjenesten hos Direktoratet for e-helse. Leverandørspesifikk database for test - E-helse ønsker at hver leverandør har hver sin database å teste mot, slik at ikke feil fra en aktør påvirker andre aktører. I første omgang vil EPJ-leverandør få tildelt en egen tjeneste med eget URL. SFM vil som en midlertidig løsning opprette nye brukere basert på de som logger på EPJ (SFM mottar access token på), men API for skriving av helseperson vil være tilgjengelig. Testdata - For testformål opprettes et eget legekontor i AR som benyttes til integrasjon mot SFM. Prosjektet tildeler pasienter som leverandør kan bruke til testing. Grunnen til at det reguleres i forhold til pasienter er at e-resept trenger kontroll med hvilke pasienter som får resept med ny type signatur på seg slik at test mot apotek og Helfo kan koordineres. Virksomhetssertifikater skal oppfylle krav til e-resepts testmiljø (Buypass test4 eller ekvivalente). 13

4 Sikkerhetsmekanismer Det er en rekke sikkerhetsmekanismer involvert i SFM spesielt, og e-reseptkjeden generelt. I arbeidet med konsept og løsning for Sentral forskrivningsmodul var GDPR på vei inn som gjeldende lov i Norge, og samtidig ble HelseID tilgjengeliggjort som tillitsanker for helsesektoren. Dette åpnet for å tenke nytt på noen områder hvor det allerede var etablert sikkerhetsmekanismer, samt å etablere god sikring av løsningen der hvor det skal bygges nytt og flytte etablerte mekanismer sentralt. Konseptuelt og juridisk er SFM og EPJ en del av samme journalsystem for integrasjoner utenfor sykehus. Den frittstående forskrivningsmodulen benyttes på samme måte, men driftes vanligvis i samme miljø som EPJ. Med sentraliseringen dukket det opp behov for sikring av kommunikasjonen mellom EPJ og SFM. Denne kommunikasjonen består av EPJtilgang til pasientens legemiddeldata i SFM, samt all kommunikasjon som foregår i brukergrensesnitt. I denne kommunikasjonen har vi basert sikringen på noen prinsipper, men detaljer kan bli justert underveis i utviklingen: Identitet til pasient skal, så langt det lar seg gjøre, ikke kommuniseres sammen med medisinsk informasjon Før datautveksling eller brukergrensesnitt om pasientens data kan startes må EPJ hente en midlertidig "pasientbillett" som benyttes i videre kommunikasjon. Se under. SFM er sikret med HelseID - både på klient/organisasjonsnivå og for brukeren - som identifiserer seg via f.eks IDporten. API beskyttes med TLS Database skal ikke ha innebygget knytning mellom pasientens identitet og pasientens data. SFM må benytte en krypteringsmekanisme for å opprette sammenhengen. Innhold i database er kryptert 4.1 Bruk av accesstoken /refreshtoken HelseID er basert på OAuth 2.0 og skal være en løsning for helsesektoren som tilbyr: Felles påloggingsløsning Tillitsanker for sektoren Sikring av API'er Løsningen er basert på at en klient (et bestemt system installert i en bestemt organisasjon) er forhåndsregistrert hos HelseID og kan be om et bevis (token) fra HelseID som bekrefter at systemet er den det utgir seg for å være. Tokenet er et JSON Web Token (JWT) som inneholder koder som bekrefter utgiver og system. Token kan også berikes med informasjon om innlogget person, og støtter innlogging via IDporten på høyt nivå. Tokenet er signert av HelseID og kan verifiseres. 14

Ved å be om et accesstoken kan et system dermed benytte seg av et API, og dersom sikringsmekanismene ellers er gode kan API-tilbyder stole på innholdet. Fordi systemet gir fra seg tokenet (til den som tilbyr API) er det tokenet som definerer hvilket API/ressurs det er ment å gi tilgang til. Accesstoken har relativt kort levetid. Klienten kan også be om et refreshtoken som har lengre levetid, og kan benytte dette til å fornye aksesstoken så lenge refreshtokenet lever. SFM er bygget på en slik måte at API kall som kommer inn, eller funksjoner som gjøres i GUI medfører innmelding av opplysninger eller oppslag i sentrale systemer som skal gjøres på vegne av klienten/brukeren som benytter SFM. SFM er derfor konfigurert i HelseID til å kunne utføre en "token exchange", altså å bytte ut et token med audience for SFM, til et token som gir tilgang til f.eks. Reseptformidleren. Tokenet vil da inneholde opplysninger om opprinnelig klient, om SFM som har byttet token og audience for å gi tilgang til Resetformidlerens API. Når versjon 1 av denne guiden publiseres har vi ikke endelig spesifikasjon av alle "claims" i HelseID token, men her er et eksempel på et token som gir tilgang til SFM og Kjernejournal. Bruken av dette vil bli erstattet av token exchange. eyjhbgcioijsuzi1niisimtpzci6ikiymeffmzzdmtq5m0m5mei0qkjdmem5nkfenzrbq0y1qtzfod g1mtqilcj0exaioijkv1qilcj4nxqioijzz3jqykjtvhlrdex2qxlxclhtczlhym9ouleifq.eyjuy myioje1njexmji1njksimv4cci6mtu2mteynje2oswiaxnzijoiahr0chm6ly9ozwx zzwlklxn0cy50zxn0lm5obi5ubyisimf1zci6wyjodhrwczovl2hlbhnlawqtc3rzlnrlc3qubmhul m5vl3jlc291cmnlcyisimutagvsc2uvu0znlmfwasjdlcjjbgllbnrfawqioii2zwu5yzkwns1jztb hltqwzgetodexos1jnzexmgi2yza1zjyilcjzdwiioijjzdh5u1nbtdjbwitpbffvb zven3htexltenzrsku3rwdyc1zfz1hsylnfpsisimf1dghfdgltzsi6mtu2mteymju2ocwiawrwijo idgvzdglkcc1vawrjiiwiagvsc2vpzdovl2nsywltcy9pzgvudgl0es9zzwn1cml0ev9szxzlbci6i jqilcjozwxzzwlkoi8vy2xhaw1zl2lkzw50axr5l3bpzci6ija3mde1otawmtm0iiw iagvsc2vpzdovl2nsywltcy9pzgvudgl0es9hc3n1cmfuy2vfbgv2zwwioijoawdoiiwiagvsc2vpz DovL2NsYWltcy9ocHIvaHByX251bWJlciI6IjIyMjIwMDA4MSIsImhlbHNlaWQ6Ly9jbGFpbXMvY2x pzw50l2ftcii6injzyv9wcml2yxrlx2tlesisinnjb3blijpbinbyb2zpbguilcjvc GVuaWQiLCJoZWxzZWlkOi8vc2NvcGVzL2lkZW50aXR5L3BpZCIsImhlbHNlaWQ6Ly9zY29wZXMvaWR lbnrpdhkvc2vjdxjpdhlfbgv2zwwilcjozwxzzwlkoi8vc2nvcgvzl2hwci9ochjfbnvtymvyiiwiz S1oZWxzZS9zZm0uYXBpL3NmbS5hcGkiXSwiYW1yIjpbInB3ZCJdfQ.PX79842Y7z-G NJiPlvWo7i-VqkYIA0tQgLw5t_MYJ5vkNA_qFbClsCmS5W3FbATQ2eJQdKJKlnsphasXoInDzicwuv1VRLDEVwUrMWG4VnwJejARZyKHljjGT1yi9EUY1oAgOg6FBVtVpGjOjMULfuslYAXc35Ycy- X9qT5T4qNsPhBSSBhCi1yNtqeFWw_RlcLbi7YI4gruav6nkPUKToggmLmKB1niB9NYzjkf LV9sItZWPbB4_vL4fhArISmeWm7U9fxAgk-C3QvNiHRbHqW00XmPaoMHruohPHWRaTZ- RlyJxd_hE4uRhV-LYU-ceh-vVghjRy_xshwX3g-g { "alg": "RS256", "kid": "B20AE36C1493C90B4BBC0C96AD74ACF5A6E88514", "typ": "JWT", "x5t": "sgrjbbstyqtlvaywrxss9abohrq" } { "nbf": 1561122569, "exp": 1561126169, 15

"iss": "https://helseid-sts.test.nhn.no", "aud": [ "https://helseid-sts.test.nhn.no/resources", "e-helse/sfm.api" ], "client_id": "6ee9c905-ce0a-40da-8119-c7110b6c05f6", "sub": "Id8ySSAL2AZ+ilQUo5D7xmyymzvkJE7EgXsVEgXlbSE=", "auth_time": 1561122568, "idp": "testidp-oidc", "helseid://claims/identity/security_level": "4", "helseid://claims/identity/pid": "07015900134", "helseid://claims/identity/assurance_level": "high", "helseid://claims/hpr/hpr_number": "222200081", "helseid://claims/client/amr": "rsa_private_key", "scope": [ "profile", "openid", "helseid://scopes/identity/pid", "helseid://scopes/identity/security_level", "helseid://scopes/hpr/hpr_number", "e-helse/sfm.api/sfm.api" ], "amr": [ "pwd" ] } For mer informasjon om HelseID: https://www.nhn.no/helseid/ For mer informasjon om JWT token: https://jwt.io/ 4.2 Bruk av SFM Pasientbillett For å ivareta personvern ved overføring av informasjon mellom EPJ og SFM, baseres kommunikasjonen på en to-trinns modell hvor EPJ etterspør en pasientbillett med begrenset varighet for å kunne få tilgang til pasientinformasjon fra SFM og skrive pasientinformasjon til SFM. Pasientbilletten må benyttes i URL ved åpning av SFM GUI og ved bruk av SFM Datadelings API. Pasientbilletten fungerer som en nøkkel mellom pasient ID og legemiddeldataene, slik at det ikke skal være mulig å finne fram til hvilke legemiddeldata som 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 for SFM tjenesten og spesifisert slik at det ikke skal være mulig å gjette seg fram til en gyldig billett. Dette gjør også at det ikke er mulig å skrive eller lese på tvers av virksomheter. Løsningen er på den måten feiltollerant. Spørringen for tilgang til en pasientbillett skal inneholde en pasient-id (eg. 16

fnr, dnr xxx-id). Siden billetten har begrenset levetid er det mulig å fornye billetten på lik linje med at systemet også fornyer accesstoken. Pasientbilletten er en tekststreng på maks 200 tegn. I dagens løsning er pasientbillett en GUID: 44300220-455f-4333-b6e8-1464a7f44608 Detaljert teknisk beskrivelse med eksempelkode for å etterspørre pasientbillett er publisert på Github, se beskrivelse under hvordan komme i gang Ressursen PatientTicket er beskrevet på Swagger. 17

5 Bruk av SFM GUI SFM GUI er implementert i JavaScript for bruk i standard browser. Foreløpig er SFM bare testet for bruk i Chrome, og det er kjente feil knyttet til bruk i Edge. SFM anbefaler ikke bruk av IE. På sikt vil SFM bli testet for bruk i flere browsere. Eksemplene som er tilgjengeliggjort er basert på bruk av Chrome. SFM GUI kan benyttes både i en skybasert løsning og som del av en tykk-klient. For å forenkle overgangen til bruk av SFM for aktører som i dag bruker FM, så utvikler SFM en tykk-klient (ComWrapper). Denne tjener også som eksempelkode for aktører som har tykk-klienter som skal integrere med løsningen. Det er altså 3 forskjellige måter å benytte SFM GUI på. Disse er beskrevet under. 5.1 Tykklient EPJ, som integrerer SFM GUI EPJ-systemene som dominerer markedet i dag er typiske tykke klienter. I praksis er det windows-applikasjoner som kjøres enten på rekvirentens PC eller via en terminalserverløsing. SFM kan integreres i slike EPJer ved at EPJ benytter en browserkomponent i sin EPJ hvor SFM startes via en definert URL. SFM Pasientrettet portal vil alltid startes i kontekst av et journalsystem, en bruker og en pasient. Før det kan startes en slik sesjon er det nødvendig at system og bruker er identifisert gjennom en sekvens med HelseID. For brukerinnlogging i ID-porten bør samme browserkomponent benyttes. Dette muliggjør innlogging på tvers via mekanismer i web/http. Det er også nødvendig å initiere sesjon med enkeltpasient med SFM via API for å oppnå en pasientbillett. Dette gjøres for å minimere datatrafikk som kombinerer sensitive helsedata med pasienten det gjelder. Pasientens navn eller ID vil altså ikke kommuniseres i påfølgende GUI sesjon og ikke være synlig inne i WEB GUI som SFM presenterer. Det forutsettes at EPJ alltid viser hvilken pasient som er åpnet i SFM. En slik url vil typisk inneholde: 1. basis url: https://develop.client.sfm.cloud/pages/set-context?show-cave=true& 2. pasientbillett: pasientbillett# 3. access token: AccessToken SFM har i sammenheng med forskrivning behov for å etterspørre informasjon fra EPJ. Dette skal gjøres gjennom at EPJ tilbyr API ressurser. Dette kan enten gjøres på server, eller det kan være via local host. SFM klienten vil da bruke EPJ API på samme måte som EPJ benytter SFM Datadeling API. Eksempelkode for dette er ikke med i første leveranse. All nødvendig kode for å realisere en tykk klient er eksemplifisert gjennom ComWrapper som er tilgjengelig på Github. 18

5.2 Skybasert EPJ, som integrerer SFM GUI Skybaserte EPJ systemer er på vei inn i markedet. Registrering av klienter i HelseID må gjøres per virksomhet fra serversiden av den skybaserte løsningen. Dette for å sikre sterk knytting mellom virksomhet og klient-id som igjen kan stoles på av SFM. På den måten kan kodeeksempler som tilbys for konfigurering av HelseID benyttes på samme måte som for andre EPJ. I forbindelse med utstedelse av accesstoken er det svært viktig at hemmelighet ikke blir eksponert i browser. Dette gjør at også etterspørsel etter accesstoken må basere seg på at det gjøres fra serversiden. Eksempelkode på dette vil bli levert på kort sikt ved at SFM utvikler en EPJ emulator. Denne vil da også demonstrere hvordan EPJ etterspør pasientbillett og starter SFM GUI i en iframe. 5.3 Bruk av ComWrapper SFM ComWrapper kan benyttes av leverandører som bruker FM, for migrasjon til SFM med minimal utvikling. ComWrapper vil være tilgjengelig i en overgangsperiode, men på relativt kort sikt vil den bli faset ut. ComWrapper kan benyttes med samme com api som i dag benyttes for FM, men med oppdatert namespace. EPJ leverandør kan velge å implementere integrasjon mot HelseID, eller at bruker må logge seg på når den åpner SFM, da det nye namespacet er utvidet med mulighet for å overføre accesstoken som del av startpasient. Ved bruk av ComWrapper vil det være behov for at det opprettes en klient-id uavhengig om det er EPJ eller Comwrapper som autentiserer bruker. Anbefalt løsning fra SFM er at EPJ utvikler støtte for autentisering ved hjelp av HelseID og at Comwrapper understøtter single-sign-on. I dette tilfellet trenger ikke Comwrapper en egen secret for å kommunisere med HelseID. Ved bruk av Comwrapper så vil det være noe begrenset funksjonalitet som tilgjengeliggjøres. 19

6 SFM Datadeling API SFM Datadeling API skal benyttes av de leverandører som velger å bruke SFM GUI. API-et skal da ivareta all datadeling mellom SFM og EPJ som er nødvendig for å ivareta pasientsikkerheten, personvern og en effektiv arbeidsprosess. Sentrale områder som dekkes i Datadeling API er: Skrive pasientinformasjon fra EPJ til SFM Skrive brukerinformasjon fra EPJ til SFM Lese legemiddelinformasjon fra SFM til EPJ for å administrere Lese legemiddelinformasjon fra SFM til EPJ for å vise/sende Lese legemiddelreaksjon fra SFM til EPJ Lese næringsmidler og medisinsk forbruksmateriell fra SFM til EPJ for å administrere Lese vaksiner fra SFM til EPJ Slå opp i FEST Lese oppgaver fra SFM til EPJ Lese LAB og diagnoser fra EPJ til SFM Lese pasient billett fra SFM til EPJ 6.1 Arbeidsflyt Datadeling Nedenfor beskrives noen prosesser for bruk av Datadeling API: Opprette/endre helseperson Opprette/endre pasient Åpne pasient i EPJ/Se oppgaveliste Åpne Pasient Forskrive legemiddel (hente data fra EPJ) Korrespondanse Administrer pasientens legemidler og næringsmidler 20

6.1.1 Ressurs- og interaksjonsoversikt (Inntil ferdig implementasjonsguide finnes i Simplifier, er denne oversikten tatt med her) Nasjonale basis-ressurser finnes her: https://simplifier.net/hl7norwayno-basis SFM spesifikke ressurser: https://simplifier.net/sfm Ressurs Interaksjon Parameter API API Kommentar bruker tilbyder no-basis-patient create HelseID no-basis-patient no-basis-patient update HelseID no-basis-patient no-basis-patient read HelseID patient ticket no-basis-practitoner create HelseID no-basis-practitioner EPJ SFMS Benyttes av EPJ når det opprettes en ny pasient i EPJ. Pasientinformasjon skrives da til SFM. EPJ SFM Benyttes av EPJ når det gjøres endringer på en tidligere registrert pasient i EPJ. Oppdatert pasientinformasjon skrives da til SFM. EPJ SFM Benyttes a EPJ når den ønsker å lese hvilken informasjon som er registrert på pasient i SFM. EPJ SFM Benyttes av EPJ når det opprettes en ny bruker i EPJ. Brukerinformasjon skrives da til SFM. no-basis-practioner update HelseID EPJ SFM Benyttes av EPJ når det gjøres endringer på en tidligere 21

Ressurs Interaksjon Parameter API API Kommentar bruker tilbyder no-basis-practioner no-basis-practioner read HelseID fnr/hpr/* no-basis-organization create HelseID no-basis-organization no-basis-organization update HelseID no-basis-organization registrert bruker i EPJ. Oppdatert brukerinformasjon skrives da til SFM. EPJ SFM Benyttes a EPJ når den ønsker å lese hvilken informasjon som er registrert på pasient i SFM. EPJ SFM Benyttes for å skrive informasjon om ny organisasjon. EPJ SFM Benyttes for å oppdatere informasjon om organisasjon. no-basis-humanname EPJ SFM Benyttes normalt som del av Patient og Practiotioner. no-basis-address EPJ SFM Benyttes normalt som del av annen ressurs (Patient, Organization, Practitioner). sfm-task read HelseID fnr/* sfm-task update HelseID Task EPJ SFM Benyttes av EPJ for å lese alle aktive utestående oppgaver som må løses i SFM. EPJ SFM Benyttes av EPJ for å markere at oppgave er utført. SFM vil sjekke mot intern informasjon for å bekrefte at oppgaven er utørt (ikke trenger mer 22

Ressurs Interaksjon Parameter API API Kommentar bruker tilbyder oppmerksomhet). sfm-medicationstatement read HelseID patient ticket * time period type details sfm-allergyintolerance read HelseID patient ticket * period sfm-condition read HelseID patient ticket * EPJ SFM Benyttes av EPJ for å lese pasientens legemiddelliste. Det er mulig å lese alle pasientens behandlinger eller bare en valgt behandling. Det er mulig å oppgi tidspunkt, for å få hva som var i bruk på angitt tid. Det samme gjelder når det oppgis periode. Type skiller på hvilken type dosering som returneres fra SFM. Details angir om reseptdetaljer skal returneres i svaret. EPJ SFM Benyttes av EPJ for å lese pasientens kritiske legemiddelreaksjon. Det er mulig å lese alle pasientens reaksjoner eller bare en valgt reaksjon. Det er mulig å oppgi tidsperiode, for å få hva som var registrert i oppgitt periode. SFM EPJ Benyttes av SFM for å lese diagnoser som er satt på pasient. EPJ returnerer alle pasientens diagnoser, eventuelt med skille på hva som er aktivt. 23

Ressurs Interaksjon Parameter API API Kommentar bruker tilbyder sfm-condtion create HelseID patient ticket Condition sfm-observation read HelseID Patient ticket * sfm-medication read HelseID sfm-medicationstatement SFM EPJ Benyttes hvis bruker i SFM oppretter en ny diagnose på pasienten. SFM kan da skrive diagnose til EPJ slik at informasjon blir oppdatert. SFM EPJ Benyttes for at SFM skal kunne lese labresultater fra EPJ. Dette benyttes knyttet til overvåkede legemidler og i forbindelse med søknad til Helfo. EPJ SFM Benyttes for å kunne lese hvilke merkevarer som kan utleveres til pasient ved administrering. 24

6.1.2 Opprette/endre helseperson 1. Bruker logger seg på med HelseID nivå 4 (all bruk av api mot SFM krever at bruker er pålogget med nivå 4) 2. Bruker er pålogget EPJ og EPJ har Access token til å kommunisere med SFM (all bruk av api mot SFM krever bruk av Access token fra HelseID) 3. Bruker med rettigheter i EPJ/SFM oppretter eller endrer en bruker i SFM. 4. Når bruker lagrer informasjon om ny/endret Helseperson/bruker så skriver EPJ til SFM. Alle brukere skrives til SFM ved bruk av ressursen Practitioner. 5. SFM sjekker mot HPR registeret om brukeren er helseperson 6. SFM mottar oppdatert informasjon om brukeren og lagrer den 7. SFM sender 200 OK hvis opprettelse/endring er gjennomført. Hvis ikke returneres relevant feilkode med eventuell detaljert forklaring 8. EPJ informerer bruker om resultatet. Første bruker ved opprettelse av SFM database vil alltid bli opprettet med fulle administrasjonsrettigheter. Første bruker blir alltid opprettet basert på HelseID token på nivå 4. For at andre brukere skal få administrative rettigheter så må det tildeles i SFM Virksomhetsportal. 25

6.1.3 Opprette/endre pasient 1. Bruker med rettigheter til å opprette pasienter i EPJ velger å opprette/endre en pasient i EPJ. 2. EPJ benytter SFM FHIR API for å opprette/oppdatere informasjon om pasient i SFM (create/update). 3. SFM sjekker med PREG om oppgitt fnr/dnr er gyldig og henter oppdatert informasjon om pasienten fra PREG. (Hvis pasient ikke har fnr/dnr så sjekker ikke SFM mot PREG) 4. PREG returnerer detaljer om pasient (navn, adresse), og SFM lagrer oppdatert informasjon 5. SFM sender feedback til EPJ basert på behandling av pasienten a. 200 OK hvis informasjon lagret b. 422 Feil med detaljer c. Andre feilmeldinger definert av FHIR 6. EPJ presenterer eventuell feedback til bruker. 26

6.1.4 Åpne pasient i EPJ/Se oppgaveliste 1. Helseperson logger inn i EPJ med HelseID nivå 4 2. EPJ etterspør Access token med Aud SFM 3. HelseID returnerer Access token for SFM 4. EPJ etterspør hvilke oppgaver bruker/avdeling har som må løses. Spørringen er basert på å lese FHIR ressurs: SFM-Task 5. SFM sjekke mot RF/KJ for å undersøke om det er pasienter som har ny informasjon knyttet til seg. 6. RF/KJ returnerer hvilke pasienter som trenger oppmerksomhet 7. SFM returnerer liste over oppgaver som må gjøres (pasienter som trenger oppmerksomhet og hvilken oppmerksomhet de trenger). 8. EPJ presenterer oppgaveliste for bruker 27

6.1.5 Åpne Pasient 1. Helseperson som er innlogget på nivå 4 åpner en pasient i EPJ 2. EPJ etterspør pasient-billett fra SFM 3. SFM returnerer en pasient billett til EPJ. Mulig feilsituasjon hvis pasient ikke finnes i SFM eller bruker ikke er registrert i SFM 4. EPJ benytter pasient-billetten til å etterspørre oversikt over legemidler i bruk (SFM- MedicationStatement) 5. SFM returnerer legemidler i bruk til EPJ (i figuren vises det ikke at SFM slår opp i RF/KJ slik at oppdatert data kan presenteres til bruker) 28

6. EPJ benytter pasient-billetten til å etterspørre oversikt over pasientens kritiske legemiddelreaksjoner (SFM-AllergyIntolerance) 7. SFM returnerer pasientens intoleranser (i figuren vises det ikke at SFM slår opp i RF/KJ slik at oppdatert data kan vises til bruker) 8. Informasjon om legemidler i bruk og legemiddelreaksjon vises til bruker i oversiktsbilde. 9. Bruker åpner legemiddelmodulen 10. EPJ presenterer SFM GUI i en embeded browser 11. SFM viser pasientens legemiddelinformasjon direkte til bruker gjennom SFM GUI (bruker gjør så endringer i SFM GUI som ikke er vist i figur) 12. Bruker bytter visning i EPJ, slik at oppdatert informasjon om legemidler skal vises til bruker. 13. EPJ etterspør LIB fra SFM 14. SFM returnerer LIB til EPJ 15. EPJ etterspør legemiddelreaksjon fra SFM 16. SFM returnerer legemiddelreaksjon til EPJ 17. EPJ presenterer oppdatert informasjon til bruker. 29

6.1.6 Forskrive legemiddel 1. Bruker jobber i SFM og velger å opprette ny/endre legemiddelbehandling 2. SFM benytter oppgitt URL fra EPJ for å etterspørre pasientens diagnoser (read). For lokale installasjoner vil dette normalt være localhost, mens for skybaserte løsninger vil det være URL til en sentral ressurs. 3. EPJ returnerer pasientens diagnoser i respons til SFM 4. SFM gjør (hvis behov) samme spørring som i 2, men etterspør Labsvar. 5. EPJ returnerer pasientens labsvar som er etterspurt. 6. SFM presenterer tilgjengelige diagnoser til bruker slik at de kan benyttes til å dokumentere forskrivningen. 6.1.7 Korrespondanse Lesing av informasjon for bruk i korrespondanse er viktig for å kunne kommunisere oppdatert informasjon til andre aktører. I kommunikasjon mellom EPJ og SFM så er dette dekket av beskrivelsen for å åpne pasient - steg 13-16. 30

6.1.8 Administrer pasientens legemidler og næringsmidler 1. Bruker åpner modul for administrering av legemidler og næringsmidler 2. EPJ leser en variant av pasientens legemidler i bruk som returnerer spesifikke doseringstidspunkter per dosering i valgt periode. 3. SFM returnerer administrasjonstilpasset legemiddelliste 4. EPJ leser en variant av pasientens næringsmidler for å få enkle dosering 5. SFM returnerer administrasjonstilpasset næringsmiddelliste. 6. Legemiddelliste med detaljer om doseringstidspunkt presenteres til bruker 7. bruker velger legemiddel som skal administreres 8. EPJ spør SFM om hvilke merkevarer som kan utleveres på valgt forskrivning 9. SFM returnerer relevante merkevarer 10. Bruker registrerer hva som er blitt gitt til pasienten 11. EPJ lagrer administreringsinformasjon 12. EPJ gir feedback til bruker. 31

6.2 Datadeling - API Datadeling API publiserer ressurser og funksjoner for at EPJ system som integrerer mot SFM, hvor SFM benyttes til forskrivning, kan få tilgang til data som er produsert i SFM, hentet fra nasjonale tjenester eller tidligere skrevet fra EPJ. API er eksponert som FHIR ressurser/tjenester basert på RESTful tilnærming. Noen sentrale funksjoner som tilbys i dette API er ikke rene CRUD operasjoner. API er beskyttet med HelseID, og det er essensielt at SFM kan avlede informasjon om organisasjonen og rekvirenten fra HelseID. Ressursene no-organisation og no-practitioner benyttes for å oppdatere SFM med tilstrekkelig info. 6.2.1 Bruk av HTTP URL, verb og søkeparametre Generell beskrivelse av FHIR og bruk av RESTful HTTP: https://www.hl7.org/fhir/http.html Normale operasjoner benyttes for standardressurser I interaksjon mellom SFM og EPJ er det så langt mulig forsøkt å separere informasjon om pasientens navn eller identitet fra annen sensitiv informasjon. Det er derfor støtte for at EPJ innleder en pasientsesjon med å skaffe seg en pasientbillett fra SFM, som kan benyttes i videre dialog. Dette benyttes både i API og i datatrafikk som understøtter GUI. 6.2.2 Eksempler på bruk av RESTful FHIR: Ressurs: sfm-task (oppgave til SFM bruker) Read: Read: GET [urlbase]/sfm-task/[id] sfm-task med oppgitt ID blir returnert som ressurs i HTTP body Search: Search: GET [urlbase]/sfm-task/[id]?owner=practitioner/[id] Search: GET [urlbase]/sfm-task/[id]?status=in-progress Task-er som matcher søkekriteriet returneres i en Bundle. Se: https://www.hl7.org/fhir/http.html#search for detaljer Update: Update: PUT [urlbase]/sfm-task/[id] Benyttes til å oppdatere sfm-task med ny status. 32

6.2.3 Swagger spesifikasjon: APIet er tilgjengelig her: https://server.dev.sfm.cloud/index.html?urls.primaryname=fhir%20sfm-api%20v1 Foreløpig er det ikke lagt inn filtrering i Swagger på internt APIer og Datadeling API (og fremtidig Basis API). Se foreløpig etter de som har FHIR i navnet, som er ressursene som er dekket av Datadeling API. 33

7 SFM Basis API Basis API publiserer ressurser og funksjoner som SFM tilbyr for integrasjon mot nasjonale tjenester for aktører som har egen legemiddelmodul, men som ønsker å benytte FHIR API som alternativ til annen integrasjon mot Reseptformidleren (RF), Kjernejournal (KJ) og andre tjenester som SFM representerer. Denne integrasjonen vil typisk benyttes av sykehus og andre større installasjoner som ikke benytter forskrivningsfunksjonaliteten i SFM (SFM GUI). 7.1 Arbeidsflyt Basis Nedenfor beskrives følgende prosesser for bruk av Basis API: Les info fra sentrale registre Lever info til sentrale registre Spør om endringer i sentrale registre Lokale endringer (asynkron kommunikasjon) Registrering av multidoseansvar Tjeneste for oppslag og registrering av søknad om individuell stønad flyttes til ny tjeneste hos Helfo. Det forutsettes at aktører som benytter Basis API tar i bruk denne tjenesten. 34

7.1.1 Ressurs- og interaksjonsoversikt (Inntil ferdig implementasjonsguide finnes i Simplifier, er denne oversikten tatt med her) Nasjonale basis-ressurser finnes her: https://simplifier.net/hl7norwayno-basis SFM spesifikke ressurser: https://simplifier.net/sfm Ressurs Interaksjon Parameter API bruker API tilbyder Kommentar SFM-changeBundle update SFM RHF SFM mottar informasjon fra RF/KJ og videreformidler til EPJ (dagens asynkrone meldinger og oppgaver som må løses) SFM-updateBundle read RHF SFM Leser informasjon fra sentrale registre og kommuniserer til EPJ. SFM-updateBundle update RHF SFM EPJ leverer oppdatert informasjon som SFM leverer til sentrale registre. no-basis-patient EPJ SFM Del av Bundle no-basis-practitoner EPJ SFM Del av Bundle no-basis-organization EPJ SFM Del av Bundle no-basis-humanname EPJ SFM Benyttes normalt som del av Patient og Practitioner. no-basis-address EPJ SFM Benyttes normalt som del av annen ressurs (Patient, Organization, Practitioner). sfm-task EPJ SFM Del av Bundle sfm- Medicationstatement EPJ SFM Del av Bundle sfm-allergyintolerance EPJ SFM Del av Bundle 35

Ressurs Interaksjon Parameter API bruker API tilbyder Kommentar sfm-condition SFM EPJ Mulig del av Bundle sfm-medication EPJ SFM Del av Bundle 36

7.1.2 Les informasjon fra sentrale registre 1. EPJ etterspør informasjon fra sentrale kilder 2. SFM slår opp PLL i RF 3. RF returnerer melding med PLL 4. SFM slår opp resepter i RF 5. RF returnerer pasientens resepter 6. SFM slår opp i KJ 7. KJ returnerer legemiddelinformasjon 8. SFM sammenstiller informasjon mottatt fra RF og KJ 9. SFM konverterer informasjon til FHIR format 10. SFM leverer en Bundle med all informasjon til EPJ (vil også inneholde informasjon om evt. feil og manglende oppslag) 11. Ved feil vil SFM returnere en feilmelding 37

7.1.3 Lever informasjon til sentrale registre 1. EPJ leverer en bundle med informasjon om hva som skal leveres til RF 2. SFM konverterer innholdet til e-resept format 3. SFM gjør QA på innholdet før det signeres 4. Hvis det identifiseres feil eller mangler på innholdet så gis det feilmelding tilbake til EPJ 5. SFM signerer alle meldinger som skal leveres til RF 6. SFM leverer resepter til RF 7. SFM leverer tilbakekallinger til RF 8. SFM leverer PLL til RF 9. SFM sender respons til EPJ med informasjon om alt er vellykket levert. 38

7.1.4 Spørring om endringer i sentrale registre 1. RF leverer asynkrone meldinger til SFM 2. EPJ spør SFM ved ønskede intervaller om det er endringer 3. SFM etterspør endringer på relevante pasienter i RF 4. RF returnerer eventuelle endringer 5. SFM etterspør endringer på relevante pasient i KJ 6. KJ returnerer eventuelle endringer 7. Oppretting av oppgaver basert på synkrone og asynkrone meldinger 8. SFM leverer oppgaver til EPJ 39

7.1.5 Lokale endringer (asynkron kommunikasjon) 1. Send forespørsel om levering av asynkrone meldinger 2. SFM sammenstiller asynkron informasjon 3. SFM konverterer til FHIR format 4. SFM leverer bundle til EPJ 5. Informasjon om feilsituasjoner. 40

7.1.6 Multidoseregistering 1. EPJ sender informasjon til SFM om at bruker har (av)registrert seg som MD lege for pasient 2. SFM sender informasjon til RF 3. RF returnerer at informasjon er oppdatert 4. SFM gir beskjed om status for transaksjonen 41

7.2 Basis - API API er eksponert som FHIR ressurser/tjenester basert på RESTful tilnærming. Noen sentrale funksjoner som tilbys i dette API er ikke rene CRUD operasjoner, men avanserte operasjoner hvor SFM gjør oppslag i flere tjenester, sammenstiller data og presenterer en kompleks struktur som FHIR dokument (Bundle/Composition). API er beskyttet med HelseID, og det er essensielt at SFM kan avlede informasjon om organisasjonen og rekvirenten fra HelseID. Ressursene no-organisation og no-practitioner benyttes for å oppdatere SFM med tilstrekkelig info. 7.2.1 Bruk av HTTP URL, verb og søkeparametre Normale operasjoner benyttes for standardressurser 7.2.1.1 SFM Operations Spesielle operasjoner for oppslag og innmelding av opplysninger: Definerte FHIR operations: $getmedication $sendmediaction Oppslag: GET [base]/basisapi/patient/$getmedication Operation: $getmedication input: PasientID, Referansenummer, SamtykkeKJ (TBD) - manglende samtykke forstås om at det ikke skal gjøres oppslag i KJ retur: en Bundle som resultat og som eneste parameter med navn "result". Se egen spesifikasjon av Bundle. feil: operationoutcome etter standard regler. Levering: POST [base]/basisapi/patient/$sendmediactions Operation: $sendmedication input: Bundle navngitt med parameter "medication" retur: parameters feil: operationoutcome etter standard regler. HTTP-responskoder følger standard regler. Feilkoder skal ledsages av OperationOutcome ressurs. Mer info om FHIR operations finnes her: https://www.hl7.org/fhir/operations.html 42

7.2.1.2 Meldinger fra RF til EPJ: Tasks Endringer, tidligere asynkrone meldinger kan hentes som Tasks. SFM vil opprette task når det ankommer meldinger fra Reseptformidleren av typen: M6, M7, M8, M15, M25.2 og M25.3 Tasks vil opprettes med referanser der det er relevant: ReseptID Pasient f.nr/d.nr Rekvrient HPRnr HER id til organisasjon Følgende elementer i task er relevante: State: draft Intent: proposal Code: (name or Code briefly describing what the task involves) - Task.Code: meldingsmottak Description Reason: Melingstype (kodeverk eller tekst) Owner: Logical Reference/Organisation: HER-id Note Input: o o o Referanser fra listen over. (Logical reference), MessageID for meldingen som trigget Tasken Relevante felt fra meldingen: M15: Innvilget M15: BegrunnelseAvslag M15: Saksbehandler Informasjon fra M6 Informasjon fra M8 Informasjon fra M25 (fra apotek) Hent task-liste: GET [base]/basisapi/task?owner=[her-id på mottaker] Det er opp til implementasjon i mottakersystem å vurdere hvilke tasks som kan behandles automatisk. Noen tasks skal medføre at pasient merkes med at det finnes endringer som ikke ennå er lastet ned. 43

7.2.2 Swagger spesifikasjon Spesifikasjonene vil bli gjort tilgjengelig via Swagger, se mer info på siden "Hvordan komme i gang?". Basis APIet er p.t ikke implementert, og er ikke tilgjengelig via APIet. Foreløpig versjon av ressursene finnes på Simplifier. 7.2.3 SFM Update Bundle Update bundle beskriver kompleks retur av data om en pasient i Basis-API. Når api-kallet $getmedication gjøres returnerer SFM en bundle som inneholder strukturert informasjon fra tilgjengelige kilder, basert på oppslag på pasientens legemiddelliste, resepter og multidoseinfo. Bundelstrukturen benyttes også til levering av informasjon til Reseptformidleren, hvor EPJ system bygger bundle og poster med $sendmediaction. Det er foreløpig ikke tatt stilling til om det skal profileres egen ressurs for denne eller ikke. Det er dialog med andre prosjekter og direktoratets standardiseringsavdeling om dette. Alle forbehold om endringer i løpet av utviklingsløpet. 44

8 Kontakt og lenker 8.1 Lenker Eksempelkode finnes på: https://github.com/thulasource Dokumentasjon av FHIR ressurser som benyttes i SFM finnes på: https://simplifier.net/guide/sfm-guide/introduction Swagger dokumentasjon av tjenestene som er tilgjengeliggjort finnes på: https://coreapi.api.sfm.cloud/index.html 8.2 Kontaktinformasjon Tekniske spørsmål sendes til: Dag Hammer: Dag.Hammer@ehelse.no Maria Rekdal: Maria.Rekdal@ehelse.no Ole Martin Winnem: olemw@enableit.no Spørsmål knyttet til oppsett av testomgivelser sendes til: Gunn Skogseth: Gunn.Skogseth@ehelse.no 45

9 Vedlegg Signering av resept Det har lenge vært klart at signering av XML-meldinger med bruk av personlig sertifikat med privatnøkkel på smartkort er en løsning som skaper problemer for sentralisert drift. Det har vært problematisk i noen Remote Desktop/Terminalserver løsninger, og direktoratet har fått tilbakemeldinger om at det er en løsning som er uegnet for skybaserte eller web-baserte løsninger. Den opprinnelige signaturen på resepten har to formål: Identifikasjon av rekvirenten, og integritetsbeskyttelse av meldingen. Denne spesifikasjonen beskriver både opprinnelig og alternativ signering med bruk av HelseID for identifikasjon av rekvirent (og klientsystem) og PKI signatur for integritetsbeskyttelse basert på virksomhetssertifikat. Løsningen er basert på utvidet tillit til systemet som påfører signatur, altså SFM - og selvfølgelig tillit til HelseID og IDporten. Med denne løsningen oppnår vi raskere signering av resept i WEB-baserte løsninger, og opplevelse av gjennomført single-sign-on for systemer som støtter dette. Det er fremdeles et sentralt punkt at signeringen er en tydelig handling for rekvirenten som utfører den, med andre ord: Systemet som påfører signatur med HelseID må gjøre dette som et resultat av at helsepersonen valgte å signere (og sende). 9.1 Signatur på resept Resept kan signeres elektronisk på to måter: Signatur basert på HelseID med person-id og virksomhetssertifikat Signatur basert på personlig sertifikat Begge disse kan benyttes, men den første er betinget av spesiell godkjenning av systemet som påfører signaturen og driftsleverandør for systemet 46

Figur som viser alternative signeringsmetoder for resept. SKO signaturen finnes bare på resepter som utleveres til apotek og bandasjist (og videre til Helfo) 9.2 Signatur basert på HelseID med person-id og virksomhetssertifikat Signatur basert på HelseID påføres ved at systemet som signerer resepten vedlegger JWT token som bekrefter rekvirentens identitet som en konsekvens av handlingen "signer og send". Denne koblingen mellom signeringshandlingen og eksistensen av JWT token er årsaken til at det kreves spesiell godkjenning av system og driftsleverandør som signerer etter denne metoden. JWT token fra HelseID skal ha følgende claims for identitetsbekreftelse: helseid://claims/identity/pid: <nasjonal identitet> helseid://claims/identity/security_level: 4 helseid://claims/identity/assurence_level: high (det er andre krav til format og innhold i token som ikke er dekket her) JWT token identitetsbevis legges til M1 som vedlegg. Vedlegg er en standard mekanisme for Hodemeldingen. Vedlegg til meldinger er beskrevet i eget dokument: https://ehelse.no/standarder-kodeverk-og-referansekatalog/standarder-ogreferansekatalog/elektronisk-samhandling-vedlegg-til-meldinger-his-10362011 JWT token vedlegges i <RefDoc> struktur på følgende måte: 47