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.