Autentisering og tilgang

Open Aidn API-er krever OAuth 2.0 bearer tokens utstedt for den godkjente integrasjonen. Tilgang styres av klientkonfigurasjon, kommunekonfigurasjon og scopes per endepunkt.

OAuth-klientautentisering

De fleste system-til-system-integrasjoner bruker en konfidensiell OAuth-klient med private_key_jwt som klientautentisering.

Klienten trenger minst ett nøkkelpar. Dette kan håndteres på to måter:

• Leverandøren genererer et nøkkelpar og sender bare den offentlige nøkkelen til kommunen eller Aidn-administrator for registrering i administrasjonsportalen.
• Kommunen eller Aidn-administrator genererer nøkkelparet i administrasjonsportalen og overfører privatnøkkelen sikkert til leverandøren.

Integrasjonen lagrer privatnøkkelen i sitt eget sikre hemmelighetslager og bruker den til å signere token-forespørsler.

Hvis administrasjonsportalen genererer nøkkelparet, vises privatnøkkelen bare én gang og kan ikke hentes frem senere. Lagre den før dialogen lukkes.

Privatnøkler skal aldri legges i kildekode, skrives til logger eller deles via e-post eller chat.

Scopes

Scopes begrenser hva en klient kan gjøre. En klient kan bare be om scopes som er konfigurert for den klienten.

Open Aidn bruker scope-navn inspirert av SMART on FHIR. For eksempel krever EpisodeOfCare-søk:

Scope	Formål
episodeofcare.search	Søke etter EpisodeOfCare-ressurser.
episodeofcare.read	Lese én EpisodeOfCare-ressurs med ID.

De konkrete scopes for en integrasjon avtales som del av oppstarten og skal samsvare med det godkjente bruksområdet.

Kalle Open Aidn API-er

Hver API-forespørsel må inkludere access token i Authorization-headeren:

Authorization: Bearer <ACCESS_TOKEN>
Accept: application/fhir+json

Forespørsler og svar bruker FHIR JSON der det er relevant. Søkeendepunkter returnerer en FHIR Bundle med type satt til searchset.

Etterlevelse og dataminimering

Open Aidn-integrasjoner må følge avtalt formål og datatilgang for kommunen. Som integrasjonspartner forventes det at du:

• Ber om bare scopes som trengs for det godkjente bruksområdet.
• Lagrer nøkler, credentials og tokens sikkert.
• Unngår å lagre helsedata med mindre det er del av avtalt behandlingsformål.
• Logger tilgang på en måte som støtter feilsøking uten å eksponere unødvendige helseopplysninger.
• Koordinerer nøkkelrotasjon og hendelseshåndtering med kommunen og Aidn.

Aidn håndhever autentisering, autorisasjon, kommunekonfigurasjon og revisjonsspor på plattformsiden. Disse kontrollene erstatter ikke leverandørens ansvar for å beskytte credentials og håndtere helsedata i tråd med avtalen.