Bakgrunn for oppdatering

  • FHIR versjon R4 ble publisert i desember 2018, versjon 4.0.1 oktober 2019

  • Følge siste versjon av standarden + oppdaterte verktøy og biblioteker (bl.a. validering)

  • Gjennomføre diverse oppsamlede endringer i vkp-profiler basert på erfaringer + rydding

  • Noen større endringer: Encounter, Composition, MedicationDispense

  • Diverse mindre endringer, spesielt kardinalitet på felter

  • Generelt: Stort sett samme informasjon (noen få nye felter), men endringer i struktur

  • Endringer og forenklinger på adressering,

Hovedendringer

Bruk av Encounter + Composition

Endring i hvordan vi representerer hendelser og digitale tilsyn:

  • Alltid Encounter (apparat/device + hendelsestype)

  • I tillegg Composition hvis behov for notat fra responssenter

  • Encounter = strukturert informasjon om apparat og hendelser

  • Composition = informasjon/beskrivelse fra responssenter om oppfølging

Bakgrunn

  • Enklere regler for de ulike tilfellene, færre varianter

  • Representere samme ting på samme måte (f.eks. device)

  • Mer strukturert representasjon (alltid apparat og hendelse som strukturert informasjon, ikke tekst)

  • Dermed også enklere å lage ny funksjonalitet, f.eks. filtre på Min side

  • Felles kodeverk (f.eks. hendelser)

  • Tilsvarende representasjon som for medisindispenserhendelser: MedicationDispense og evt. Composition

Picture

Hovedendring 1: Adressering

Vi har tidligere brukt HER-id for adressering og identifisering av avsender/mottaker. Vi tenkte at dette var et godt alternativ da man hadde et regiserter (Grunndatas Adresseregisteret) som man kunne slå opp og finne HER-idene. Men vi har sett at dette ikke har blitt brukt og at det er forvirrende at både mottaker og avsender har egne HER-ider. I tillegg så blir bestillingen av nye HER-ider er forsinkende ledd i utrullingen av en ny kommune.

På grunn av dette så har vi

Hovedendring 1: Encounter - detaljer

Encounter.device

  • identifier

  • display

  • type

  • typeName

  • location

Encounter.classHistory.device

  • Kun identifier – refererer til en device i Encounter.device

Reason skifter navn til reasonCode (R4-endring)

Subject og participant blir obligatoriske

Hovedendring 2: Composition

Dagens Composition

  • Hovedhendelser i forløpet i events (bl.a. til behandling), resten i section.

  • Tidsstempler innbakt i teksten i sections

  • Seksjonstittel identifiserer type section

Ny versjon

  • Innføre egen profil, vkp-composition

  • Alle hendelser i forløpet legges i sections, dvs. hele hendelsesloggen på ett sted

  • Kode for å identifisere type hendelse (utvidet til å dekke alle hendelser)

  • Tidsstempel som eget felt på alle hendelser

  • Kode for å identifisere seksjon (signature)

  • Composition.class -> category (R4)

  • Tekst i events

Hovedendring 3: REST-API for MedicationDispense

  • Endring fra meldingsbasert (IoT-hub) til REST

  • Trenger ikke lenger MessageHeader

  • Ellers ingen endringer i profilene

Hovedendring 4: Forenkling av feilmedingsformat

I STU3-versjonen av APIet ble det retunert en Bundle med en MessageHeader og en OperationOutcome hvis kallet feilet. Grunnen til at man returnerete en MessageHeader var fordi man ønsket å støtte meldingsbasert utvekslinger. Nå har vi sett at de aller fleste fortrekker rene REST-apier, vi har derfor valgt å fjerne MessageHeader fra feilmeldinger, noe som gjør at vi heller ikke trenger å returnere en Bundle. Det gjør at vi nå ved feilsituasjoner vil returener en enkel OperationOutcome.

Vil du vite mer om Velferdsteknologisk knutepunkt, send oss en e-post.