Dokumentasjon CarePlan-API

Her ligger dokumentasjon på hvordan man kommer i gang med CarePlan-API. Spørsmål blir raskest besvart i slack, så dersom du mangler tilgang til slack kan du sende epost til produkteier Asefeh.

Kom i gang

Api beskriver hvordan man tar i bruk APIet, samt alle tilgjengelige endepunkter.

For tilgjengelige test-miljøer se Miljøoversikt.

Autorisasjon og autentisering gjøres med HelseID - se Authorization

Ulike feilscenarioer og hvordan disse håndteres er beskrevet i ErrorHandling

For eksempler på hvordan gjøre REST-kall mot tjenesten se CurlEksempler.

Intro til Careplan FHIR-API

APIet er et standard FHIR REST API (fasade, ikke FHIR server), basert på HL7 CarePlan og tilknyttede profiler. Foreløpig støttes Condition, Goal og ServiceRequest, i tillegg til CarePlan.

Profilene er versjon R4, og vi bruker standard-profilene til HL7 uten endringer, bortsett fra tags i meta-objektet for å si hvem som sist har oppdatert ressursen. Se Metadata for videre forklaring.

FHIR-profiler

CarePlan er hovedprofilen som har referanser til de andre informasjonselementene. For å sikre en helthetlig behandling er det valgt at en pasient kun har én plan i første omgang - men planen kan gjelde for mange problemstillinger/diagnoser. Se CarePlan for hvilke felter som bør fylles ut.

For pasientens diagnoser og problemstillinger brukes profilen Condition. Condition for hvilke felter som bør fylles ut.

Goal profilen brukes for mål for pasient og behandling. Goal for hvilke felter som bør fylles ut.

ServiceRequest profilen brukes for tiltak og aktiviter som skal gjøres. Mål og tiltak bør ha en referanse til hvilken diagnose de gjelder for. ServiceRequest for hvilke felter som bør fylles ut.

For å hente CarePlan med tilhørende refererte ressurser tilbyr vi søke-endepunkt, som returnerer en bundle med ressurser. Se Bundle for beskrivelse av dette, samt Api for ytterligere beskrivelse av endepunkter.

Samtykke fra pasient

For at kjernejournalen til en pasient skal kunne inneholde en behandlingsplan kreves det at pasient samtykker. Vi tilbyr endepunkt for å sette dette på vegne av pasient. Se Samtykke.md

Status-endepunkt

Vi tilbyr også endepunkt for å se om en pasient har en plan eller ikke, og når denne sist ble oppdatert med maskin-til-maskin token. Se Status

Merk:
Det forventes at klienter alltid kaller status-endepunktet først for å se om pasient har satt sperring, eller blokkering.

Security

We do our best to keep the data we receive clean from malicious content to avoid potentially sending malicious content back to the clients which read the data. However this is not a failsafe approach so we expect the clients to always validate and clean data for any malicious content before sending it to the API. If we detect malicious content the request will be rejected. A good starting point is to follow the OWASP guidelines and the HelseID checklist for securing APIs.

Also note that we expect that the main defense against security breaches caused by malicious content should be implemented by every client in the application layer by using good practices like e.g. proper html escaping or using prepared statements in the database.