Table of Contents |
---|
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 kan benytte forskjellig teknologi for integrasjon. Aktøren velger om man ønsker å benytte meldingsbasert integrasjon eller integrasjon via API’er. For noen av grensesnittene støttes kun en av integrasjonsmetodene. Dette vil framgå av beskrivelsen av hvert enkelt grensesnitt under.
En rekke av REST-grensesnittene (som alternativ til meldingsformidling) er under utvikling (høst 2021). Endelig release dato gis på forespørsel.
Detaljert teknisk dokumentasjon finnes på denne siden (med undersider): Teknisk detalj dokumentasjon - skjemaløsning
Ekstern skjemautfyller mellomlagrer delvis utfylt skjema på Helsenorge
Innledning
Denne funksjonaliteten er kun tilgjengelig dersom utfylling er resultat av en skjemaoppgave (dvs. FHIR Task).
...
Ekstern skjemautfyller
kan selv “huske” kontekst dvs. ta vare på DocumentReference.Id mellom lagring og uthenting av mellomlagret dokument.Ekstern skjemautfyller har ikke kontekst informasjon, men må søke opp mellomlagret dokument basert på innbyggers fødselsnummer og kunnskap om skjemaoppgavens “identifier” (dvs. Task.Identifier).
Payload
Ekstern skjemautfyller antas å ha proprietært format for delvis utfylt skjema. Dette lagres derfor alltid som en binær octetstreng på Helsenorge og representeres via FHIR ressursen: FHIR DocumentReference
REST API
Rest-API er under implementering, ta kontakt for release-dato.
Scenario a): Ekstern skjemautfyller “husker” mellomlagret dokument sin ressurs.id
Lagre skjemainstans : Update (HTTP PUT): Det forutsettes at ekstern utfyller selv bestemme ressursens ID. Denne må være en UUID. Se detaljer her.
Eks: PUTEkstern skjemautfyller skal alltid benytte Create - HTTP POST for å lagre.
Når ekstern skjemautfyller skal hente ut mellomlagret skjema igjen, kan den benytte to forskjellige “patterns”:
Dersom den tar vare på ressursens ID som returneres fra Helsenorge kan denne benyttes i en Read - HTTP GET: https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1254654012/FHIR+-+REST+Operasjoner#Read---HTTP-GET
Ressursen kan hentes ut igjen med en Search - HTTP POST (_search), der man benytter kjente verdier som er lagret i elementer på ressursen (her DocumentReference) https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1254654012/FHIR+-+REST+Operasjoner#Search---HTTP-POST-(_search)
REST API
(Mellom)lagring av delvis utfylt skjemasvar
Lagre skjemainstans: Create (HTTP POST): Her bestemmer Helsenorge ressursens ID. https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1254654012/FHIR+-+REST+Operasjoner#Create---HTTP-POST
Eks:
/fe0e4d02-0d0a-43be-8784-0ac336fefec3POST [base]/skjema/v1/DocumentReference
Uthenting av tidligere mellomlagret delvis utfylt skjemasvar
Pattern 1: Ekstern skjemautfyller “husker” mellomlagret dokument sin ressurs ID slik denne ble returnert fra Helsenorge
Hente skjemainstans: Read (HTTP GET): Lagret skjemainstans hentes direkte basert på ressurs ID
...
Eks:
GET [base]/skjema/v1/DocumentReference/fe0e4d02-0d0a-43be-8784-0ac336fefec3
...
Pattern 2: Ekstern skjemautfyller
...
husker ikke
...
ressursens id, men må søke opp mellomlagret dokument
Lagre skjemainstans: Create Hente lagret dokument: Search (HTTP POST): Her bestemmer Helsenorge ressursens ID. Det forventes ikke at ekstern skjemautfyller “husker” returnert ressurs.id. Se detaljer her.
Eks:
POST [base]/skjema/v1/DocumentReference
Hente lagret dokument: Search (HTTP POST): Her skal det benyttes innbyggers fødselsnummer og skjemaoppgavens Identifier” slik disse er angitt i DocumentReference.
Eks:kan det benyttes verdier i elementer i DocumentReference som ekstern skjemautfyller kjenner. https://helsenorge.atlassian.net/wiki/spaces/HELSENORGE/pages/1254654012/FHIR+-+REST+Operasjoner#Search---HTTP-POST-(_search)
POST [base]/skjema/v1/DocumentReference/_search?
Body:
Content-Type: application/x-www-form-urlencoded
+ Eks 1: Man kjenner innbyggers fødselsnummer og oppgavens (task) sin identifier:
subject.identifier=urn:oid:2.16.578.1.12.4.1.4.1|01126222358&related.identifier=urn:ietf:rfc:3986|urn:uuid:3a5ca27f-949a-429d-ae67-d19567bc37b8
Der: 01126222358
= Innbyggers fødselsnummer (det er valgt POST og parametere i body fordi innbyggers fødselsnummer aldri skal være i URL’er)
Der: 3a5ca27f-949a-429d-ae67-d19567bc37b8
= er Task.Identifier slik denne er knyttet opp i DocumentReference som et relatert dokument. Se her for detaljer.
Body: Eks 2: Man benytter/kjenner DocumentReference.identifier
identifier=urn:ietf:rfc:3986|urn:uuid:3a5ca27f-949a-429d-ae67-d19567bc37b8
Meldingsbasert integrasjon (AMQP)
...
Ekstern skjemautfyller sender ferdig utfylt skjema til Helsenorge
Payload
Det er to varianter av payload (se Bruksscenarier):
Ekstern skjemautfyller sender selv skjemasvar til aktør og sender kun lesbar kopi av svaret til innbygger på Helsenorge: FHIR DocumentReference med PDF Se her for detaljer
Dersom Helsenorge skal formidle skjemasvar til aktør, sender ekstern skjemautfyller både skjemasvar i sitt eget (proprietære) format samt innbyggers lesbare kopi i en FHIR Bundle: Se her for detaljer
Merk! Dette er et bruksscenarie som ikke er support for enda (høst 2021), implementeres avhengig av behov.
REST API
Rest-API er under implementering, ta kontakt for release-dato.
Her kan ekstern skjemautfyller benytte to alternative HTTP verb for å lager PDF’en:
...