Innledning

Gjennom bruk av FHIR-ressurser i skjemaløsningen har vi lagt til rette for at flere av grensesnittene som er beskrevet i den overordnede beskrivelse aktørene kan benytte forskjellig teknologi for integrasjon. Aktøren velger om man ønsker å benytte meldingsbasert integrasjon eller integrasjon via API’er.

Detaljert teknisk dokumentasjon finnes på denne siden (med undersider): Teknisk detalj dokumentasjon - skjemaløsning

...

Oppdatere innsendt oppgave

Payload

• En skjemaoppgave Alle oppgaver er alltid representert ved en FHIR Task: Detaljert beskrivelse: FHIR Task - Oppgave

• Noen av feltene på en allerede innsendt oppgave kan endres i ettertid:

  • Oppgavens status (Task.status)

  • Tekst med grunn for at siste statusendring skjedde (Task.statusReason)

  • Det kan legges til tekstlige notater (Task.note)

  • Fristene kan endres - NB! Dette er ikke bestemt at skal være mulig enda. Behov vurderes.

• Payload er av type: http://hl7.org/fhir/fhirpatch.html

REST API

• (HTTP POST): Her bestemmer Helsenorge ressursens ID.

  • :

    • Task.restriction.periode.end

    • Eventuelt også extension: Task.restriction.http://helsenorge.no/fhir/StructureDefinition/hn-task-deadline MERK: Dersom opsjonen med “deadline” extension benyttes i første innsendte oppgave, må denne alltid også settes ved FHIR PATCH dersom Task.restriction.period.end endres (selv om “deadline” ikke er endret). Man må altså angi begge elementer i Task.restriction ved en PATCH.

  • Beskrivelsen kan endres (Task.description)

  • Referanse til annet Helsenorge-element kan endres (Task.basedOn, ny funksjonalitet 2H 2024)

• Ved oppdatering av et eller flere av disse benyttes FHIR PATCH (Se underside for detaljer: Oppdatering av attributter på Task (FhirPatch) )

Følgende begrensninger/forretningsregler er definert på Helsenorge for hva som kan oppdateres når:

• Enkelte felter kan ikke oppdateres:

  • Dersom:

    • Task.status = “completed”', “cancelled” eller “entered-in-error”

    • Oppgavens gyldighet er passert, dvs. nåværende tidspunkt er etter det siste av:

      • Task.restriction.periode.end

      • Task.restriction.http://helsenorge.no/fhir/StructureDefinition/hn-task-deadline

  • Så kan følgende felter ikke lenger oppdateres:

    • Gyldighet (Task.restriction.periode.end og/eller Task.restriction.http://helsenorge.no/fhir/StructureDefinition/hn-task-deadline)

    • Beskrivelse (Task.description)

    • Status (Task.status)

    • Begrunnelse for siste statusoppdatering (Task.statusReason)

    • Referanse til annet Helsenorge-element (Task.basedOn)

• Begrunnelse for siste statusoppdatering (Task.statusReason) kan kun settes når Status (Task.status) endres samtidig

• Angivelse av gyldighet

  • Gyldighet (Task.restriction.periode.end og/eller Task.restriction.http://helsenorge.no/fhir/StructureDefinition/hn-task-deadline) må være frem i tid (minst en dag)

  • Task.restriction.http://helsenorge.no/fhir/StructureDefinition/hn-task-deadline) må være senere enn Task.restriction.periode.end

• Notat til oppgaven (Task.note) kan når som helst legges til oppgaven

• Referanse til annet Helsenorge-element (Task.basedOn) (https://helsenorge.atlassian.net/wiki/x/IwAZZ )

  • Legg til (add): Oppgaven oppdateres ved at det legges til en ny referanse

  • Slett (delete): Oppgaven oppdateres ved at alle eksisterende referanser slettes

  • Bytt ut (replace): Oppgaven oppdateres ved at alle eksisterende referanser byttes ut med referansene i oppdateringen

REST API

• Det benyttes sikkerhetsmodell system-til-system: 01 - System til System

• (HTTP POST): https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1254654012/FHIR+-+REST+Operasjoner#Patch---HTTP-PATCH

  • Eks Task: PATCH [base]/oppgave/v1/Task/[id]

  • Se underside for FHIRPath Patch eksempler: Oppdatering av attributter på Task (FhirPatch)

Meldingsbasert integrasjon (AMQP)

Vi vil også tillate PATCH ved hjelp av Meldingsformidling. Positiv APREC tilbake fra Helsenorge indikerer at PATCH-operasjonen var vellykket. (Melding eksempel kommer)

Hodemelding + vedlegg:

• Vedlegg av typeie Bundle

  • Bundle.type = “transaction”

  • Bundle.entry = FHIRPatch (samme som i REST-API)

  • Bundle.request

    • method = “PATCH”

    • url = “Task/[id] (samme id som i URL ved REST kall)

Eksempel på FHIRPath Patch via meldingsformidling (benytter kansellering av oppgave, dvs. oppdatere Task.status samt sette Task.statusReason):

Undertrykke varsling av innbygger ved endring

Når oppgaver mottas vil alltid innbygger varsles. Dersom ikke noe angis vil innbygger også varsles når et eller flere elementer på oppgaven endres.

Det er (så langt) identifisert en UseCases der man ikke ønsker at innbygger skal varsles når et element endres. Dette er når en oppgave i sin helhet utføres i eksternt system, og dette systemet endrer oppgaves status på Helsenorge til “completed”. Det kan også være at aktøren i andre UseCases ikke ønsker varsling ved endring. For å gi avsender mulighet til å undertrykke varsling (ved endring) er det innført et nytt metadatafelt for dette formål som kan settes for FHIRPath patch ressursen (Parameters).

<?xml version="1.0" encoding="UTF-8"?>
<Parameters xmlns="http://hl7.org/fhir">
    <meta>
        <tag>
            <system value="http://helsenorge.no/fhir/varsling"/>
            <code value="1"/>
            <display value="Innbygger skal ikke varsles."/>
        </tag>
    </meta>
    <!-- FHIRPath PATCH -->
    <parameter>
        .................
    </parameter>
</Parameters>