Page Comparison

001. Met Koppeltaal Logging wordt Toegangslog bedoeld. Een Toegangslog wordt gebruikt om verzoeken en/of reacties van berichten/ op te slaan (te loggen) die door het systeem worden ontvangen en verwerkt, evenals berichten die door het systeem worden gegenereerd en verzonden. 

002. De verantwoordelijkheid van Koppeltaal Logging wordt aan een specifiek gebruikers of beheerder account gebonden.

003. De Logging maakt gebruik van het FHIR protocol en gebruikt de HTTP POST methode om de FHIR AuditEvent resource te verzenden. Voor betrouwbare levering van een Log record, maak bij de Logging gebruik van Transmission Control Protocol (TCP) .

004. De FHIR AuditEvent resource mag NOOIT aangepast of verwijderd worden met HTTP PUT, PATCH of DELETE.

005. Het formaat van de FHIR AuditEvent resource wordt in XML of JSON formaat aangeleverd.

006. Koppeltaal Logging voldoet aan de wet en regelgeving zoals AVG, WGBO, WABVPZ, NEN-7510, NEN-7513 en WEGIZ.

007. Koppeltaal Logging bevat de registratie van alle uitgevoerde relevante 'Koppeltaal' activiteiten (kenmerken) of operationele gebeurtenissen, zoals (in een tabel wordt vastgelegd):

a. (FHIR REST API) Koppeltaal interacties tussen applicaties en/of voorzieningen.  

b. Lanceer interacties

c. Notificatie interacties 

d. Foutafhandelingen

e. Performance statistieken (zoals duur, capaciteit, beschikbaarheid en bereikbaarheid van interacties)

008. Koppeltaal Logging MOET zijn afgezonderd en afgeschermd van elke mogelijkheid tot wijziging, aanvulling of verminking, inclusief die van systeembeheer. 

009. Koppeltaal Logging is specifiek voor Koppeltaal ingericht en mag niet geïntegreerd zijn met logging voor andere doelen zoals systeembeheer of herstel.

010. Koppeltaal Logging wordt op een gestandaardiseerde vastgelegd, gebaseerd op de volgende onderliggende standaarden:

a. HL7 FHIR standard R4 (http://hl7.org/fhir/R4/index.html). Gebruik makend van de volgende FHIR resources:

b. AuditEvent (https://www.hl7.org/fhir/auditevent.html)

c. OperationOutcome (https://www.hl7.org/fhir/operationoutcome.html)

d. Bundle (https://www.hl7.org/fhir/bundle.html)

e. RFC -6585 Additional HTTP Status Code (https://datatracker.ietf.org/doc/html/rfc6585)

f. RFC-5424 The Syslog Protocol (https://datatracker.ietf.org/doc/html/rfc5424)

g. IHE-ATNA supplement ( Add RESTful ATNA (Query and Feed) Supplement )  → worden de verschillende interactie patronen in beschreven

h. IHE Appendix on HL7 FHIR – Z.8.1 Auditing Considerations → audit requirements voor het lanceren van app's of modules

i. W3C Trace Context standaard. Zie: https://www.w3.org/TR/trace-context-1/

011. Koppeltaal Logging bevat (minimaal) de volgende gegevens:

a. Type en subtype van de gebeurtenis.

b. Soort gebeurtenis.

c. datum en tijd van gebeurtenis.

d. unieke vraag en eventuele antwoord identifier voor gebeurtenis. Opmerking: NEN 7513 gaat niet in op het gebruik van de logging en dit is geen standaard attribuut van de NEN7513 . 

e. trace identifier tussen en over gebeurtenissen. Opmerking: Binnen de NEN7513 wordt er geen unieke identifier gedefinieerd voor een gebeurtenis en is er geen (directe) veld beschikbaar om een correlatie te leggen tussen en over gebeurtenissen.

f. Betrokken applicatie. 

g. Rol van betrokken applicatie.

h. Initiator 

i. Resource type wat gelogd wordt.

j. Resource instantie id + versie van resource.

k. Observeerder.

l. Locatie van loggegevens.

012. Bij de Koppeltaal Logging kunnen 1 of meerdere objecten/resources gelogd worden. Afhankelijk van het type gebeurtenis (type interactie) wordt vastgelegd welke objecten/resources uniek geïdentificeerd moeten worden.

a. Bij een te loggen of gelogde gebeurtenis kunnen verschillende objecten en verschillende typen objecten betrokken zijn.

b. Bij een dossieractie, zoals het invoeren van gegevens, kan bijvoorbeeld een uitslag het betrokken object zijn en bij een zoekactie is de zoekvraag het betrokken object. Gebeurtenissen als het instellen van een toestemmingsprofiel hebben het profiel en de cliënt als betrokken objecten.

c. Verschillende typen objecten worden ook op verschillende wijzen geïdentificeerd. Een uitslag is bijvoorbeeld gekoppeld aan een uitslagnummer. Een cliënt heeft als identificatie het patiëntnummer, maar in een bepaald informatie domein daarnaast mogelijk ook identificatoren van een ander type, zoals een opnamenummer.

d. Ter identificatie van de betrokken objecten zijn het type en id van het betrokken object verplicht. 

013. Om interoperabiliteit tussen systemen te waarborgen, wordt geadviseerd om zoveel mogelijk gebruik te maken van toegepaste codering of codestelsels voor gegevensvelden in loggegevens te verwerken. Voor het specificeren van de gegevensvelden is uitgegaan van IETF/RFC 3881 [1] en is de opzet gevolgd zoals die te vinden is in DICOM PS 3.15: Part 15: Security and Systems Management Profiles zoals opgenomen in NEN‐EN‐ISO 12052:2011 en het ATNA profiel in het ITI Technical Framework 1 [2] en 2 [3]. Onder meer DICOM en ATNA gebruiken meer gegevensvelden dan hier worden gespecificeerd. Om interoperabiliteit met bestaande systemen te waarborgen is het toegestaan om deze additionele gegevensvelden in loggegevens te verwerken.

014. Voor gegevensvelden waarvoor een algemeen toegepaste codering bestaat, wordt die codering (enumeratie) in het Logging gegevensmodel voorgeschreven.

015. Voor gegevensvelden waar geen algemene toegepaste codering bestaat wordt in het gegevensveld behalve de code ook een verwijzing opgenomen naar het feitelijk toegepaste codestelsel of (code)systeem. Zo kan gebruik gemaakt worden van een codestelsel dat voor het desbetreffende informatiedomein bestaat of is ontwikkeld. 

016. Maak gebruik van gebruiker specifieke eenduidige (HTTP) headers om (gelogde) gebeurtenissen uniek te identificeren. De volgende gebruiker specifieke (HTTP) headers worden geadviseerd:

a. X-Request-Id. Een uniek identifier voor elk verzoek of antwoord bericht dat is toegewezen door de cliënt of de server.

b. X-Correlation-Id. Door de cliënt toegewezen correlatie identifier die meegestuurd wordt in het antwoord van een verzoek of header informatie als onderdeel van een notificatie. Deze (HTTP) header wordt alleen gebruikt bij asynchrone gebeurtenissen. (Zie lanceer- en notificatie interacties)

c. X-Trace-id. Een uniek identifier die gebruikt wordt om een gehele spoor (overspanning) in een keten uniek te kunnen identificeren, deze wordt toegewezen door de initiërende partij (cliënt of server die een gebeurtenis initieert) en vervolgens overgenomen wordt door de niet initiërende partijen. 

017. De afgegeven datum en tijd van een gebeurtenis van alle applicaties binnen een domein of organisatie moeten worden gesynchroniseerd met één referentietijdbron om zo de tijdlijnen te kunnen traceren en te reconstrueren van deze gebeurtenissen. 

018. Bij de Logging kunnen asynchrone gebeurtenissen via traceringscontext elementen/velden aan elkaar gerelateerd worden. Zet hiervoor gebruiker specifieke (HTTP) headers. Enkele use cases zijn:

a.  Het lanceren en/of opstarten van systemen en de daarbij behorende responses;

b. Het asynchroon versturen van  berichten naar een ander systeem, en op een later moment een response te versturen;

c. Het relateren van notificaties en aanverwante gebeurtenissen die in abonnementen worden vastgelegd;

d. Het relateren van berichten in een keten van/tussen systemen.   

019. Elke interactie in de Logging MOET uniek identificeerbaar zijn d.m.v. een identifier. De volgende eisen worden hieraan gesteld:

a. De identifier moet betekenisloos zijn. Dus nooit herleidbaar naar betekenisvolle informatie.

b. De identifier moet uniek zijn. Dit veld wordt doorgaans gebruikt voor unieke identificatie van objecten/resources/entiteiten in een gedistribueerd systeem.

c. De identifier moet een willekeurige (random) waarde bevatten, dat niet herleidbaar en te ordenen is.

d. De identifier moet URL vriendelijk "Base64" encoding zijn.

020. Een cliënt applicatie mag gebruik maken van gebruiker specifieke eenduidige (HTTP) headers om interacties uniek te identificeren voor de Logging bij een cliënt verzoek.

021. Indien een cliënt applicatie niet gebruik maakt van gebruiker specifieke eenduidige (HTTP) headers voor de Logging om interacties uniek te identificeren MOET de server in het antwoord van een (cliënt) verzoek de volgende velden vullen:

a. X-Request-Id. Een 8 bytes identifier. 0000000000000000 is NIET toegestaan als X-Request-Id. 

b. X-Trace-Id. Een 16 bytes identifier. 00000000000000000000000000000000 is NIET toegestaan als X-Trace-Id.

c. Alleen bij asynchrone communicatie de X-Correlation-Id vullen . Een 8 bytes identifier. De X-Correlation-Id is een kopie van een asynchroon (cliënt) verzoek (de X-Request-Id) of van een notificatie behorende bij een trigger.request-id. 

022. Voor de vertrouwelijkheid van een Log record maak gebruik van het Transport Layer Security (TLS)-protocol. TLS kan de berichten beschermen tijdens hun volledige overdracht tussen verschillende systemen. TLS kan alleen de payloads van het pakket beschermen, niet hun IP-headers, wat betekent dat een waarnemer op het netwerk de bron en bestemming van verzonden log records kan identificeren, waardoor mogelijk het IP-adres wordt onthuld, de adressen van de log server en de bronnen van de log.

023. Om de integriteit en authenticatie van een Log record te waarborgen, maak gebruik van een ondertekend authenticatie JSON Web Token, waarin de client_id in is vastgelegd.