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, SKAL den brukes som utgangspunkt.
  • Kommunale avledede profiler BØR være små, presise og begrunnet i use case.
  • Kommunale profiler SKAL ikke innføre nye lokale ressursmodeller når standard FHIR-ressurser dekker behovet.
  • Avvik fra no-basis eller nasjonal praksis SKAL dokumenteres eksplisitt.
  • Ressurser som beskriver samme tjenesteforløp BØR kobles med konsistente referanser.
  • Hver profil BØR 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.

Extensions og lokale tilpasninger

Denne versjonen definerer ingen egne extensions. Kommunale behov BØR først løses med standard FHIR-elementer, no-basis, relevante kodeverk og tydelige referanser mellom ressurser.

Extensions BØR bare vurderes når et reelt samhandlingsbehov ikke kan beskrives godt nok med eksisterende FHIR-elementer. Behov som kan uttrykkes med identifier, category, type, code, supportingInfo, basedOn, partOf eller vanlige referanser BØR ikke bli extensions i denne fasen.

Hvis et behov likevel peker mot en ny nasjonal extension, BØR det forankres i HL7 Norge-prosess og begrunnes med konkrete use case. Lokale extensions for intern systembruk bør holdes utenfor samhandlingsgrensesnitt.

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.

Samlet kan dette leses slik:

Vedtak/dokumentgrunnlag       Bestilling/oppdrag
DocumentReference             ServiceRequest
          \                   /
           \                 /
            v               v
        Kommunalt forløp: NoKommuneEpisodeOfCare
                    |
                    v
        Plan/tiltak: NoKommuneCarePlan
                    |
          +---------+---------+
          v                   v
 Gjennomført kontakt      Måling/vurdering
 NoKommuneEncounter       Observation

Hvilken profil brukes når

Profil Når den brukes Viktig minimum i praksis Samhandling
NoKommuneEncounter 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
NoKommuneEpisodeOfCare Når kommunen har et sammenhengende oppfølgingsforløp status, patient, period.start, managingOrganization Samler kontakt, plan og ansvar i samme forløp
NoKommuneCarePlan 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 BØR bruke NoKommuneEncounter.
  • Kommunalt forløp BØR bruke NoKommuneEpisodeOfCare.
  • Kommunal oppfølging over tid BØR bruke NoKommuneCarePlan.

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 SKAL representere faktisk kontakt.
  • Encounter BØR angi kontaktform i type og kontekst i class.
  • Ved digital eller virtuell kontakt BØR class normalt bruke VR når dette er dekkende.
  • Encounter BØR ha period.start og ansvarlig kommunal enhet i serviceProvider.
  • Encounter BØR 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 KAN modelleres som Appointment og kobles ved gjennomføring.

EpisodeOfCare

  • EpisodeOfCare BØR brukes for sammenhengende oppfølging over tid.
  • EpisodeOfCare SKAL ha tydelig status og tidsramme (period).
  • EpisodeOfCare BØR ha ansvarlig organisasjon i managingOrganization.

CarePlan og CareTeam

  • CarePlan BØR brukes for mål, tiltak og oppfølging over tid.
  • CarePlan.intent BØR 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.
  • Verdien av NoKommuneCarePlan er ikke å beskrive hele kommunens planmodul, men å gi et felles samhandlingsobjekt for hva som er planlagt, hvem som har ansvar, hvilken periode planen gjelder, og hvilke bestillinger, mål, observasjoner og kontakter planen henger sammen med.
  • Profilen BØR brukes når planen skal deles, forstås eller gjenfinnes på tvers av systemer. Rent lokale arbeidslister og intern turnusplanlegging bør ikke presses inn i denne profilen.
  • 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 BØR brukes for å koble planen til ServiceRequest, Task eller Appointment når dette er relevant for oppfølgingen.
  • CareTeam BØR brukes når flere roller/enheter deler ansvar.

NoKommuneCarePlan er derfor med fordi mange kommunale samhandlingsbehov ikke bare handler om enkeltkontakter. De handler om planlagt oppfølging over tid: hva kommunen følger opp, hva som er avtalt eller bestilt, hvilke mål som finnes, og hvilke kontakter eller observasjoner som viser utviklingen.

Observation

  • Observation BØR 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 BØR brukes for bestilling/initiering.
  • Task KAN brukes for arbeidsflyt knyttet til ServiceRequest.

Vedtak og dokumentasjon

  • Vedtak BØR representeres som DocumentReference.
  • Composition KAN 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 NoKommuneEpisodeOfCare på EpisodeOfCare
  3. Plan: profilen NoKommuneCarePlan på CarePlan
  4. Gjennomføring: profilen NoKommuneEncounter på Encounter

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

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

Forholdet til VKP, PMD og nasjonale informasjonstjenester

Disse profilene ligger på et annet nivå enn VKP og PMD.

VKP er under modernisering. NHN beskriver at dagens VKP skal erstattes av enkeltstående API-baserte informasjonstjenester i løpet av 2026, og at disse etableres på kommunal samhandlingsplattform. De nye tjenestene skal samlet gi funksjonalitet tilsvarende dagens VKP, men med et mer modulært og skalerbart løsningsmønster.

PMD er en nasjonal informasjonstjeneste for måledata, der Observation er den sentrale ressursen.

Denne IG-en definerer ikke en alternativ plattform, transportkanal eller journalføringsflyt. Profilene beskriver kommunal kontekst rundt oppfølging:

  • NoKommuneEpisodeOfCare gir forløpsrammen.
  • NoKommuneCarePlan beskriver plan, tiltak og oppfølgingsstruktur.
  • NoKommuneEncounter beskriver faktisk gjennomført kommunal kontakt.
  • Observation og DocumentReference kan inngå som støttedata, men eies ikke av disse profilene når nasjonale profiler eller tjenester dekker behovet bedre.

Praktisk konsekvens: VKPs nye informasjonstjenester, PMD og kommunale samhandlingstjenester kan være kanal eller tjeneste for konkrete dataflyter, mens denne IG-en beskriver hvordan kommunal oppfølging kan modelleres konsistent når data skal deles eller forstås på tvers.

Innføring i praksis

Anbefalt rekkefølge:

  1. Etabler profilen NoKommuneEpisodeOfCare.
  2. Etabler deretter NoKommuneCarePlan og koble den til forløpet.
  3. Etabler NoKommuneEncounter 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: