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

Modellering og profilering

Denne siden samler modellering og profilering for kommunal bruk av FHIR.

Målet er å gjøre det enkelt å gå fra behov til riktig ressurs, riktig profil og riktig kobling mellom data.

Bindende prinsipper

  • Der no-basis-profil finnes, SHALL den brukes som utgangspunkt.
  • Kommunale avledede profiler SHOULD være små, presise og begrunnet i use case.
  • Kommunale profiler SHALL ikke innføre nye lokale ressursmodeller når standard FHIR-ressurser dekker behovet.
  • Avvik fra no-basis eller nasjonal praksis SHALL dokumenteres eksplisitt.
  • Ressurser som beskriver samme tjenesteforløp SHOULD kobles med konsistente referanser.
  • Hver profil SHOULD ha minst ett ikke-normativt eksempel.

Designvalg for kommunale profiler

Disse profilene er tenkt som en forsiktig første iterasjon av kommunale områdeprofiler, ikke som nye basisprofiler.

  • Profilene bygger på no-basis der relevante nasjonale basisprofiler finnes.
  • Profilene innfører bare noen få ekstra krav som er nyttige på tvers av kommuner.
  • Obligatoriske felter er holdt på et lavt nivå for å bevare lokal fleksibilitet.
  • MustSupport brukes ikke i denne versjonen. Viktige minimumskrav uttrykkes i stedet med kardinalitet og referanser.
  • Profilene innfører ikke nye nasjonale kodeverk i denne versjonen.

Noen læringspunkter fra eksisterende arbeid

Det finnes annet kommunalt arbeid som peker i samme retning som denne IG-en. Vi bruker dette som inspirasjon, men uten å gjøre guiden avhengig av mer spesialiserte profiler eller kodeverk på nåværende tidspunkt.

  • digital kontakt kan med fordel bruke Encounter.class = VR når dette er dekkende
  • CarePlan kan brukes bredt til ulike typer kommunal oppfølging
  • identifier kan være nyttig når kommunen trenger en stabil forretningsidentifier, men gjøres ikke obligatorisk

Fra behov til data

Bruk denne enkle logikken:

  1. Bestilles en tjeneste? Bruk ServiceRequest.
  2. Skal oppfølging planlegges? Bruk CarePlan.
  3. Skal gjennomført kontakt dokumenteres? Bruk Encounter.
  4. Trenger du samlet kontekst over tid? Bruk EpisodeOfCare.
  5. Skal vedtak eller dokumentgrunnlag deles? Bruk DocumentReference.

Hvilken profil brukes når

Profil Når den brukes Viktig minimum i praksis Samhandling
KommuneKontakt Når en konkret kontakt er gjennomført (fysisk, digital, telefon) status, class, subject, type, period.start, serviceProvider Kobles til bestilling via basedOn og til forløp via episodeOfCare
KommuneForløp Når kommunen har et sammenhengende oppfølgingsforløp status, patient, period.start, managingOrganization Samler kontakt, plan og ansvar i samme forløp
KommuneOppfølgingsplan Når mål, tiltak og planlagt oppfølging skal beskrives status, intent=plan, subject, period.start, author Knytter vedtak/bestilling til praktisk oppfølging

Normativ bruk:

  • Kommunal kontakt SHOULD bruke KommuneKontakt.
  • Kommunalt forløp SHOULD bruke KommuneForløp.
  • Kommunal oppfølging over tid SHOULD bruke KommuneOppfølgingsplan.

Dette betyr i praksis:

  • Bruk profilene når data skal deles eller brukes som felles samhandlingsgrunnlag.
  • Ikke forsøk å modellere all lokal journalstruktur i disse profilene.
  • Hold lokale tilpasninger utenfor så langt det er mulig.

Modellregler per ressurs

Encounter

  • Encounter SHALL representere faktisk kontakt.
  • Encounter SHOULD angi kontaktform i type og kontekst i class.
  • Ved digital eller virtuell kontakt SHOULD class normalt bruke VR når dette er dekkende.
  • Encounter SHOULD ha period.start og ansvarlig kommunal enhet i serviceProvider.
  • Encounter SHOULD inkludere participant og location der relevant.
  • Encounter.location er valgfri og bør normalt brukes for fysisk kontakt. Ved telefon- eller videokontakt kan location utelates.
  • Planlagte kontakter MAY modelleres som Appointment og kobles ved gjennomføring.

EpisodeOfCare

  • EpisodeOfCare SHOULD brukes for sammenhengende oppfølging over tid.
  • EpisodeOfCare SHALL ha tydelig status og tidsramme (period).
  • EpisodeOfCare SHOULD ha ansvarlig organisasjon i managingOrganization.

CarePlan og CareTeam

  • CarePlan SHOULD brukes for mål, tiltak og oppfølging over tid.
  • CarePlan.intent SHOULD være plan når profilen brukes som oppfølgingsplan.
  • CarePlan i denne IG-en er bevisst holdt bred. Den skal kunne brukes i flere kommunale sammenhenger uten å forutsette fullstendig strukturert planinnhold.
  • CarePlan.category kan brukes for å skille mellom for eksempel tjenesteoversikt, tiltaksplan og besøksplan.
  • goal, addresses (problem/tilstand) og activity (tiltak/intervensjon) er ofte relevante elementer, men de er ikke gjort obligatoriske i denne første versjonen.
  • CarePlan.activity.reference SHOULD brukes for å koble planen til ServiceRequest, Task eller Appointment når dette er relevant for oppfølgingen.
  • CareTeam SHOULD brukes når flere roller/enheter deler ansvar.

Observation

  • Observation SHOULD brukes for strukturert måling og vurdering når informasjonen skal deles maskinelt.
  • Dette er særlig relevant for vitale målinger, NEWS2-lignende vurderinger og pasientgenererte måledata fra digital hjemmeoppfølging eller velferdsteknologi.
  • I denne versjonen brukes Observation som støtteressurs og eksempel, ikke som egen kommunal profil.

ServiceRequest og Task

  • ServiceRequest SHOULD brukes for bestilling/initiering.
  • Task MAY brukes for arbeidsflyt knyttet til ServiceRequest.

Vedtak og dokumentasjon

  • Vedtak SHOULD representeres som DocumentReference.
  • Composition MAY brukes når dokumentet skal struktureres i seksjoner.

Referansekjede i et kommunalt forløp

Anbefalt flyt:

  1. Vedtak og bestilling: DocumentReference + ServiceRequest
  2. Forløpskontekst: profilen KommuneForløp på EpisodeOfCare
  3. Plan: profilen KommuneOppfølgingsplan på CarePlan
  4. Gjennomføring: profilen KommuneKontakt på Encounter

Koblinger som bør være på plass:

  • Encounter.episodeOfCare SHOULD peke til relevant EpisodeOfCare.
  • Encounter.basedOn SHOULD peke til relevant ServiceRequest.
  • CarePlan SHOULD kobles til ServiceRequest via aktivitet/referanse når aktiviteten sporbart springer ut av bestillingen.
  • CarePlan SHOULD kobles til EpisodeOfCare når planen er del av aktivt forløp.

Innføring i praksis

Anbefalt rekkefølge:

  1. Etabler profilen KommuneForløp.
  2. Etabler deretter KommuneOppfølgingsplan og koble den til forløpet.
  3. Etabler KommuneKontakt for gjennomførte kontakter.
  4. Koble inn ServiceRequest og DocumentReference der bestilling eller vedtak inngår.

Sjekkliste før produksjon:

  • meta.profile er satt riktig.
  • Referanser mellom ressurser er konsistente.
  • no-basis brukes der relevant profil finnes.
  • CapabilityStatement dokumenterer støttede søk og avvik.

Eksempler i denne IG-en

Eksemplene er veiledende.

Forankring i no-basis

Sentrale no-basis-profiler i denne sammenhengen:

Referanser og modellvalg

Modellvalg er inspirert av: