Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 deextensionde waarden van extension.request-id en/of extension.trace-id zoals bij volgende onderdeel beschrevenid.

De mapping van het AuditEvent

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

extension.request-id

Een nieuw request IDVeldnaamWaarde

extension.correlation-id

leeg

extension.trace-id

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

type


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

 "code": "110100",

 "display":
"
 Application Activity"
}


subtype


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

 "code": "110120"
,
 "display":
"
 Application Start"
}


action

E

recordednow()

Timestamp van vastlegging, bijvoorbeeld: 2024-02-05T12:06:13+0000

outcome4 minor error of 8 fatal issue

"Verwacht"

4

"Onverwacht"

8


Zie het onderdeel Type fouten uit topic 12b

outcomeDesc

Een door mensen leesbare melding van het issuete begrijpen foutmelding.

agent.who

clientDe client_id van de eigen applicatie

Code Block
{
 "reference": "Device/<id|client_id>"
}


agent.type


Code Block
{
 "coding" : {
  "system": "http://dicom.nema.org/resources/ontology/DCM"
  "code": "110150"   
  "display": "Application"
 }
}


agent.requestor

false (deze applicatie is niet requester)

entity.what

Referentie naar de specifieke Taak, indien van toepassing.

Code Block
{
 "reference":
"<Task>/id" van de betrokken FHIR Task, indien beschikbaar.
 "Task/<id>/_history/<version>"
}


source.siteDomain

Base URL van de applicatie waar het event wordt vastgelegd.

source.observerKoppeltaal

De device reference van het device dat het event waarneemt, it dit geval de applicatie die het event aanmaakt.

Code Block
{
 "reference": "Device/<id|client_id>"
}


Voorbeelden

[code]

Links naar gerelateerde onderwerpen