HL7 Norway
FHIR implementasjonsguide for norsk kommunesektor
Felles startpunkt for forstĂĽelse og omforent bruk av FHIR i kommunal helse- og omsorgstjeneste.

FHIR implementasjonsguide for norsk kommunesektor
0.1.0 - ci-build NO

FHIR implementasjonsguide for norsk kommunesektor - Local Development build (v0.1.0) built by the FHIR (HL7ÂŽ FHIRÂŽ Standard) Build Tools. See the Directory of published versions

API

Denne siden beskriver API-prinsipper og dokumentasjonskrav for denne IG-en.

Hva siden styrer

API-siden styrer:

  • hvordan søk knyttes til prioriterte use case
  • hvilke API-krav som er normative i v0.2
  • hvilke forventninger som gjelder for CapabilityStatement

Hva er viktigst i v0.2 (veiledende del)

  • API-bruk bør vĂŚre use case-drevet: klinisk behov kobles til konkrete FHIR-søk.
  • Klienten avklarer først riktig rolle/kontekst nĂĽr bruker har flere roller.
  • Deretter hentes pasientdata med standard FHIR REST/search.
  • "Ingen data funnet" tolkes som gyldig tomt resultat, ikke automatisk feil.
  • v0.2 er et pragmatisk minimum uten nye egendefinerte operasjoner.
  • v0.2 beskriver primĂŚrt lesing og søk i FHIR API.
  • Full støtte for oppretting, oppdatering og journalføring er ikke del av normativt minimum i denne versjonen.
  • Dette er i trĂĽd med pĂĽgĂĽende nasjonalt arbeid i KS/NHN der kommunale samhandlingstjenester og modernisering av VKP beveger seg i retning av enkeltstĂĽende API-baserte informasjonstjenester pĂĽ kommunal samhandlingsplattform.

Prioritert minimumssett av ressurser (veiledende del)

  • Patient
  • Encounter
  • EpisodeOfCare
  • CarePlan
  • DocumentReference
  • ServiceRequest

Neste bølge (ikke normativt minimum i v0.2):

  • MedicationStatement
  • AllergyIntolerance
  • Condition
  • Observation

Observation er sĂŚrlig relevant som neste steg fordi bĂĽde NEWS2 mĂĽlinger, pasientens mĂĽledata og VKPs nye informasjonstjenester peker i retning av strukturert deling av mĂĽlinger og vurderinger.

Anbefalte søkemønstre for prioriterte use case (veiledende del)

Se ogsĂĽ Use cases for full kontekst og flere eksempler.

Prioritert use case Ressurser Søk (eksempel)
Utskrivning og oppfølging EpisodeOfCare, CarePlan GET [base]/EpisodeOfCare?patient=Patient/[id]&status=active og GET [base]/CarePlan?subject=Patient/[id]&status=active
Planlagt oppfølging ServiceRequest, Encounter GET [base]/ServiceRequest?subject=Patient/[id]&status=active og GET [base]/Encounter?subject=Patient/[id]&date=ge[YYYY-MM-DD]
Tjenestebehov og vedtak DocumentReference, ServiceRequest GET [base]/DocumentReference?subject=Patient/[id]&type=[kode] og GET [base]/ServiceRequest?subject=Patient/[id]&status=active

Normative hovedpunkter (normativ del)

  • Klienter SKAL avklare rolle/kontekst før pasientdata hentes nĂĽr flere roller finnes.
  • Hver prioritert use case SKAL ha minst ett dokumentert anbefalt søkemønster i IG-en.
  • Tjenester BØR representere gyldig tomt søkeresultat som tom Bundle.

Tomt søkeresultat og feilrespons (normativ del)

  • Vellykket søk uten treff SKAL returneres som HTTP 200 med Bundle.type=searchset og uten treff i entry.
  • Klienter BØR tolke slikt svar som et gyldig tomt resultat.
  • Feil i request (for eksempel ugyldig parameterformat) SKAL returneres som 4xx med OperationOutcome.

Avgrensning for skriving og journalføring (normativ del)

  • v0.2 SKAL ikke forstĂĽs som krav om full støtte for oppretting, oppdatering eller sletting av ressurser.
  • v0.2 SKAL ikke forstĂĽs som en komplett spesifikasjon for journalføring fra eksterne løsninger til kommunal journal.
  • Hvis en implementasjon støtter skriving eller journalføring, BØR dette beskrives eksplisitt i egen tjenestedokumentasjon og i CapabilityStatement der dette er relevant.

Versjonering av API (normativ del)

  • API-versjonering SKAL følge SemVer-prinsipper (MAJOR.MINOR.PATCH).
  • MAJOR-endringer (breaking changes) SKAL publiseres slik at klienter kan skille gammel og ny API-versjon (for eksempel egen URL-path).
  • MINOR/PATCH-endringer SKAL vĂŚre bakoverkompatible for eksisterende klienter.
  • API-versjon og FHIR-versjon SKAL behandles som separate versjoneringsløp.

Søk, operasjoner og CapabilityStatement (normativ del)

  • API-et SKAL dokumentere hvilke søk som støttes per ressurs.
  • API-et SKAL dokumentere hvilke sentrale FHIR-søk som ikke støttes.
  • API-et SKAL dokumentere hvilke operasjoner som støttes.
  • Egendefinerte søkeparametere SKAL beskrives som SearchParameter og oppgis i CapabilityStatement.
  • Egendefinerte operasjoner SKAL beskrives som OperationDefinition og oppgis i CapabilityStatement.
  • Eventuelle avgrensninger fra standard FHIR REST-atferd SKAL dokumenteres eksplisitt.

Søk pü personidentifikator (FNR/DNR) (normativ del)

  • Søk pĂĽ personidentifikator BØR bruke POST [base]/<Resource>/_search for ĂĽ redusere risiko for logging av sensitiv informasjon i URL.
  • Hvis tjenesten stiller krav om POST for slike søk, SKAL dette stĂĽ i CapabilityStatement.
  • Kravet BØR ogsĂĽ dokumenteres tydelig i denne IG-en for hver relevant ressurs (Patient, Person, RelatedPerson).

Referanser