Versions Compared

Key

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




...

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.

...

#EisFHIR serviceBron applicatieDomein
001Koppeltaal maakt gebruik van AuditEvents voor het vastleggen van gebeurtenissen in de vorm van een logboek.xxx
002AuditEvents zijn onveranderlijk (immutable) en mogen onder geen geding gewijzigd worden. x

003De FHIR resource service is verantwoordelijk voor het loggen van de gebeurtenissen die voortkomen uit de interactie met de FHIR resource service. De applicaties in het domein zijn verantwoordelijk voor het loggen van gebeurtenissen rondom de launch en de logging van eventuele problemen die zich voordoen met het verwerken van resources in de eigen database, zowel resources die uit eigen initiatief verwerkt worden, in de context van een launch of in de context van een notificatie van een abonnement (Subscription). xx
004Het formaat van de FHIR AuditEvent resource wordt in XML of JSON formaat aangeleverd.

...

xx
005Koppeltaal 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 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 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 het verzoek of antwoord dat is toegewezen door de cliënt of de server.

b. X-Correlation-Id. Door de cliënt toegewezen identifier (X-Request-Id) die meegestuurd wordt in het antwoord van een verzoek. Dit mechanisme wordt veelal gebruikt bij asynchrone gebeurtenissen.

c. X-Trace-id. Een uniek identifier die gebruikt wordt om een gehele spoor (overspanning) in een keten uniek te kunnen identificeren. 

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:

    1. X-Request-Id. Een 8 bytes identifier. 0000000000000000 is NIET toegestaan als X-Request-Id.
    2. X-Correlation-Id. Een 8 bytes identifier. De X-Correlation-Id is een kopie van het (cliënt) verzoek (de X-Request-Id). Bij synchrone interacties is de X-Correlation-Id gelijk aan de X-Request-Id.
    3. X-Trace-Id. Een 16 bytes identifier. 00000000000000000000000000000000 is NIET toegestaan als X-Trace-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.

...

xxx
006In de interactie met de FHIR resource service dient gebruik gemaakt te worden van de tracing headers X-Request-Id, X-Correlation-Id  en X-Trace-id. De waarde van deze headers MOET gelogd worden in AuditEvents indien deze van toepassing zijn.xx
007Elk request ZOU een uniek  X-Request-Id header moeten hebben dat bestaat uit een globaal unieke waarde. Hier wordt aangeraden van een uuid v4 gebruik te maken. Indien een request wordt uitgevoerd zonder X-Request-Id header MAG de ontvangende partij een waarde voor het veld genereren.xx
008Een request MAG een X-Correlation-Id header hebben, deze moet gevuld zijn met de X-Request-Id van het bovenliggende request. Het is niet toegestaan deze te vullen met enkel nullen.xx
009Een request MAG een X-Trace-id header hebben, deze moet gevuld zijn met een gegenereerde waarde als de aanvrager de initiërende partij van het request is. Indien de header aanwezig is MOET deze ongewijzigd doorgegeven worden aan de onderliggende requests in de X-Trace-id header. Indien de  X-Trace-id header ontbreekt en er toch sprake is van onderliggende requests MAG de uitvoerder van de onderliggende requests de waardevan de  X-Request-Id header van het bovenliggende request gebruiken.