Teknisk om SFM og HelseID

HelseID benyttes for tilgangskontroll i både SFM Fullversjon og SFM Basis API.

HelseID er basert på OAuth 2.0 og er en løsning for helsesektoren som tilbyr:

Felles påloggingsløsning
Tillitsanker for sektoren
Sikring av API'er

For SFM har også HelseID støtte for konseptet “journal-id” som angir hvilken journalinstans i SFM som benyttes. Dette åpner for at samme organisasjon kan ha flere journalinstanser, det muliggjør journalsamarbeid og gir støtte for endringer i organisasjoner.

Single tenant

Single tenant løsningen fra HelseID er basert på at en klient (et bestemt system installert i en bestemt organisasjon) er forhåndsregistrert hos HelseID, og systemet 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 ID-porten på høyt nivå (nivå 4). Tokenet er signert av HelseID og kan verifiseres.

Multi tenant

Multi tenant løsningen fra HelseID er basert på at en driftsleverandør (ev EPJ-leverandør som drifter løsningen) registrere en HelseID klient for sin løsning/installasjon og at kunder/brukerorganisasjoner delegerer rett til representasjon via Altinn

I begge tilfeller er det definert et Klientsystem i HelseID selvbetjening med sine egenskaper, inklusive bruk av SFM API.

Innhold i token

Token skal kun ha SFM som audience.
Det er to scopes for bruk av SFM som er relevant:

SFM portaler og integrasjoner: Scope: e-helse:sfm.api/sfm.api, Beskrivelse: Benyttes for SFM Portaler, SFM Datadeling API og SFM Basis API.
SFM migrering: Scope: e-helse:sfm.api/sfm-migrering.api, Beskrivelse: Benyttes for første gangs opplasting av pasient- og virksomhetsdata fra EPJ system til SFM.

I tillegg inneholder token som benyttes mot SFM en identifikator av SFM-instans (=journal).

For single tenant token heter dette SFM-id og korresponderer med SFM-id registrert i Organization ved opprettelse. Verdien av SFM-id er konfigurert i HelseID konfigurasjonen på samme måte som organisasjonsnummer.
For multi tenant token heter dette journal-id og korresponderer på samme måte med SFM-id registrert i Organization. Token kan også ha SFM-id men denne vil ignoreres av SFM når journal-id benyttes. Verdien av journal-id settes i kjøretid av EPJ systemet gjennom forespørsel for token, på tilsvarende måte som delegert organisasjonsnummer.

Ved å be om et accesstoken kan et system dermed benytte seg av et API på vegne av organisasjon oppgitt i token. 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 (noen minutter).

Klienten som benytter brukerinnlogging kan også be om et refreshtoken som har lengre levetid, og kan benytte dette til å fornye aksesstoken så lenge refreshtokenet/innlogginen lever. Refresh-token er ikke ment å forlate klientapplikasjonen og kan derfor ha lengre levetid (noen timer).

SFM benytter en mekanisme som heter token exchange for å videre representere bruker og organisasjon som angitt i token mot andre nasjonale løsninger som Kjernejournal og Reseptformidleren. Dette gjøres gjennom kall mot HelseID hvor SFM benytter token mottatt i API til å få et nytt token med annet audience (RF/KJ). SFM benytter dette tokenet både for tilgang til API og for signering av meldinger etter gjeldende spesifikasjon.

Det er noen viktige ting å være klar over:

På grunn av mulig klokke-forskyvning anbefaler HelseID at klientapplikasjonen benytter verdien ExpiresIn (seconds) som returneres sammen med tokenet fra HelseId for å støtte refresh-algoritme internt.
SFM fullversjon med GUI klient må opprette en sesjon mot SFM med endepunktet: /api/Session/create
SFM fullversjon med GUI klient må oppfriskes med nytt token når EPJ har gjort refresh. Dette gjøres i API Datadeling med endepunktet: /api/Session/refresh
En sesjon som ikke har gyldig token vil ikke kunne brukes, men kan fremdeles oppfriskes.
På samme måte skal sesjonen lukkes dersom brukeren logger av EPJ systemet: /api/Session/end.

SFM har en sesjon for hver bruker i en virksomhet. Dette er slik for å unngå at det skal hope seg opp med sesjoner når bruker hopper mellom maskiner. Sesjon er her en knytting mellom accesstoken og cookie. En bruker kan ta create session fra mange maskiner og det fungerer for bruker i alle browsere fram til han på en av maskinene velger å logge ut. Da er det krav om å avslutte sesjon og EPJ sender avslutt sesjon. Når bruker kommer til en av de andre maskinene som bruker sesjonen, så finnes ikke cookie og kall fra SFM feiler. EPJ må da ta en ny create session og starte browser igjen for at bruker skal kunne fortsette å jobbe på pasienten.

Eksempel på request for Multi tenant klient

"authorization_details": [
    {
      "type": "helseid_authorization",
      "practitioner_role": {
        "organization": {
          "identifier": {
            "system": "urn:oid:1.0.6523",
            "type": "ENH",
            "value": "NO:ORGNR:100100126:999944582"
          }
        }
      }
    },
    {
      "type": "nhn:sfm:journal-id",
      "value": {
        "journal_id": "7fbfbcbd-6f08-4e95-9f7a-9d69c40f6a35"
      }
    }
  ]

I eksempelet over er det angitt hvilke to organisasjonsnummer (toppnivå/parent og virksomhet/child) som skal angis i token, samt at journal-id angis for korrekt instans av SFM. Det kan være flere journal-id som peker på samme instans, f.eks. en pr juridisk enhet.

Det er EPJ systemet sitt ansvar å ikke samle data om pasienter for flere virksomheter når det ikke foreligger juridiske avtaler om journalsamarbeid.

Merk: der er detalj i JSON strukturen her: JSON variabelen “journal_id” har understrek, mens helseID scope har bindestrek. Dette er av tekniske grunner.

For mer informasjon om HelseID: https://www.nhn.no/helseid/hvordan-ta-i-bruk-helseid/

For utviklere: https://utviklerportal.nhn.no/informasjonstjenester/helseid/

For mer informasjon om JWT token: https://jwt.io/