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 modernisert VKP beveger seg i retning av API-baserte informasjonstjenester.

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 modernisert VKP 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 SHALL avklare rolle/kontekst før pasientdata hentes nĂĽr flere roller finnes.
  • Hver prioritert use case SHALL ha minst ett dokumentert anbefalt søkemønster i IG-en.
  • Tjenester SHOULD representere gyldig tomt søkeresultat som tom Bundle.

Tomt søkeresultat og feilrespons (normativ del)

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

Avgrensning for skriving og journalføring (normativ del)

  • v0.2 SHALL ikke forstĂĽs som krav om full støtte for oppretting, oppdatering eller sletting av ressurser.
  • v0.2 SHALL 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, SHOULD dette beskrives eksplisitt i egen tjenestedokumentasjon og i CapabilityStatement der dette er relevant.

Versjonering av API (normativ del)

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

Søk, operasjoner og CapabilityStatement (normativ del)

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

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

  • Søk pĂĽ personidentifikator SHOULD 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, SHALL dette stĂĽ i CapabilityStatement.
  • Kravet SHOULD ogsĂĽ dokumenteres tydelig i denne IG-en for hver relevant ressurs (Patient, Person, RelatedPerson).

Referanser