Skip to end of banner
Go to start of banner

TOP-KT-012c - Foutafhandeling bij de launch

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Beschrijving

De ontvanger van een launch is verplicht om het inkomende bericht te valideren en de entiteiten waarnaar het bericht verwijst te kunnen verwerken. Daarnaast voert de autorisatieservice een autorisatie van de gebruiker uit. Op het moment dat er in dit proces iets mis gaat moet, naast dat de gebruiker op de juiste manier geïnformeerd wordt, ook de ander applicatie-instanties in het Koppeltaal domein van deze fout op de hoogte gebracht worden. 

Overwegingen 

Informeren van de eindgebruiker

De eindgebruiker moet worden geïnformeerd over het mislukken van de launch. Hoewel hier de gebruiker geïnformeerd moet worden, moet er spaarzaam omgegaan worden met het verspreiden van technische details. Dit om te voorkomen dat ongewenst technische details over het systeem kenbaar gemaakt worden aan derden.

Informeren van de infrastructuur

Er is binnen SMART on FHIR app launch of HTI geen methode om een fout in het proces te communiceren met andere applicaties in een domein. Binnen de gangbare workflow is het natuurlijk wel mogelijk met HTTP status codes de gebruiker en de betrokken systemen van een mogelijke fout op de hoogte te brengen. Om de andere applicaties in het domein te informeren over een dergelijke fout maakt koppeltaal gebruik van het AuditEvent. 

Relatie tot logging

Houd er rekening mee dat een succesvolle launch gelogd dient te worden met een AuditEvent, de foutafhandeling is dus een specifieke casus van deze logging.

Toepassing, restricties en eisen

Foutpagina

Indien er in de launch iets misgaat zodat de eindgebruiker niet verder kan, wordt de eindgebruiker hierover geïnformeerd met een foutpagina. Deze pagina kan zowel op de ontvangende applicatie als op de autorisatie service voorkomen. Deze pagina bevat geen technische details, echter, het is aan te raden iets van een referentie op de pagina te zetten waarmee de melding van de gebruiker gekoppeld kan worden aan de verdere referenties van de foutmelding in het systeem, zoals deextension.request-id en extension.trace-id zoals bij volgende onderdeel beschreven.

De mapping van het AuditEvent

Het AuditEvent wordt volgens de tabel beneden gemapped. In de mapping doen we een aantal aannames die we uitteenzetten.



extension.request-id

Een nieuw request ID

extension.correlation-id

leeg

extension.trace-id

de waarde van het jti veld uit de HTI token, indien beschikbaar.

type

"system":"http://dicom.nema.org/resources/ontology/DCM"

"code":"110100",

"display":"Application Activity"

subtype

"system":"http://dicom.nema.org/resources/ontology/DCM"

"code":"110120"

"display":"Application Start"

action

E

recorded

now()

outcome

4 minor error of 8 fatal issue

outcomeDesc

Een door mensen leesbare melding van het issue.

agent.who

"reference":"<Device>/id" van de betrokken applicatie

agent.type

Application

agent.requestor

false (deze applicatie is niet requester)

entity.what

"reference":"<Task>/id" van de betrokken FHIR Task, indien beschikbaar.

source.site

Domain

source.observer

Koppeltaal

Voorbeelden

[code]

Links naar gerelateerde onderwerpen

  • No labels