Protokollierung¶
Das ELGA Protokollierungssystem dient der Wahrung von Transparenz und Nachvollziehbarkeit aller erfolgten Aktionen, wie z.B. auf personenbezogene, medizinische Dokumente in der ELGA Infrastruktur. Protokollnachrichten werden in lokale Audit Record Repositories (L-ARR) der ELGA-Bereiche und im L-ARR der zentralen Komponenten persistiert (Z-L-ARR). Die Gesamtmenge der einzelnen L-ARR und Z-L-ARR Protokolle dient einer lückenlosen, forensisch nachvollziehbaren Aufzeichnung aller lesenden, schreibenden und modifizierenden Aktionen im ELGA / e-Health Kontext.
Generell soll im e-Health Kontext jede Transaktion sowohl in L-ARR wie auch in Z-L-ARR protokolliert werden, wie dies in ELGA bereits üblich ist. Die Events, welche im e-Health Kontext stattfinden, sind als solche speziell zu markieren, um eine eindeutige Trennung bzw. Filtermöglichkeit der ELGA / e-Health Protokolldaten durch die gemeinsame Verwendung der bereits in ELGA etablierten Infrastruktur zu gewährleisten.
Im aggregierten Audit Record Repository (A-ARR) findet die Protokollierung nur bei bestimmten e-Health Anwendungen statt. Im Kontext des e-Impfpasses findet die Protokollierung im A-ARR auch statt. Im Gegensatz dazu werden z.B. bei einer VO keine A-ARR Protokolle erzeugt.
Alle Aktivitäten der ZGF werden mittels ATNA Audit Trails in das Audit Repository der Fachlogik der AC Anwendung protokolliert. Zusätzlich werden festgelegte Dokumententransaktionen an das A-ARR weitergeleitet. Für alle empfangenen und weitergeleiteten Anfragen schreibt die initiierende und antwortende ZGF L-ARR ATNA Audits.
Trennung der Protokolleinträge im Kontext von ELGA und e-Health¶
Um eine eindeutige Trennung / Filtermöglichkeit zu schaffen, ist wo möglich das Attribut Purpose of Use (PoU) mitzuführen. Wie in den nächsten Kapiteln beschrieben wird im Z-L-ARR und A-ARR eine Datenbankspalte hinzugefügt. Im L-ARR wird die Anwendung-ID in einem bereits existierenden Attribut gespeichert.
Z-L-ARR & A-ARR¶
Um eine klare Trennung zwischen ELGA und den jeweiligen e-Health Anwendungen zu gewährleisten, wird in den zentralen Protokolldiensten Z-L-ARR und A-ARR eine zusätzliche Spalte eingeführt, um den Applikationskontext zu speichern.
In der neuen Datenbankspalte wird die Anwendung-ID gespeichert. Im Kontext von e-Health Anwendungen wird die Anwendung-ID dem Attribute Purpose of Use der SAML-Assertion entnommen. Im Kontext ELGA gibt es keine klare Unterscheidung der Applikationen e-Befund und e-Medikation in der SAML-Assertion, wo möglich wird versucht vom Transaktionskontext die Anwendung-ID zu entnehmen. Für e-Befunde wäre dies "101", für die e-Medikation "102", für den e-Impfpass "103", etc. und für die Virtuellen Organisationen sind die Wertebereiche "150 – 200" reserviert (organisatorische Einschränkung). Sollte keine Trennung für die Anwendungen e-Befunde und e-Medikation möglich sein, so führen diese den gemeinsamen Anwendungscode "100" für ELGA allgemein. Derzeit ist der Wert "100" nicht in Verwendung, da alle Transaktionen außerhalb des Kontexts VO und e-Impfpass, als e-Befund "101" geführt werden.
- Tabelle table audit_event_a2r2 wurde um das Attribut AUDIT_EVENT_POU Number(5,0) erweitert
- Tabelle table audit_event_lar2 wurde um das Attribut AUDIT_EVENT_POU Number(5,0) erweitert
L-ARR¶
Um die lokale Trennung der Audits zu ermöglichen, wird bei L-ARR Audits die ELGA e-Health Anwendung-ID der e-Health Applikation mitgeführt.
Beim L-ARR werden die applikatorischen Daten im Attribut "UserID" des Elements "ActiveParticipant" im Suffix "@" mit der Anwendung ID angeführt. Diese soll auch im Kontext der Weiterentwicklungen beibehalten werden.
Im ELGA Kontext erfolgt diesbezüglich keine Änderung der Protokollierung.
A-ARR Audit Events¶
Es werden nur bei vorkonfigurierten Transaktionen A-ARR Audits geschrieben. Die vollständige Liste ist Kapitel Audit Events des A-ARR Pflichtenheft zu entnehmen.
Das Datenelement poU wird in der Datenbank gespeichert, aber dem EBP nicht zurückgegeben.
Wenn ein AC spezifische A-ARR Audits schreiben muss, müssen die Audit Events definiert werden. Dazu muss im AC die neue Audit Event ID mit einer Interaktion verlinkt werden und auch im A-ARR muss die neue Event ID definiert werden.
Beispielhafte Auditeinträge für einen AC können im e-Impfpass PH nachgelesen werden.
Es kann im acImport.xml mittels "DocEvents/DocEvent/A2R2Event" der jeweilige Audit für eine Transaktionen definiert werden.
Der AC PAP schreibt beim Einbringen von Einwilligungen einen A-AAR Audit. Es wird der AuditEvent 6 (Submit BPPC) verwendet.. Die Audit Event Codes sind nicht konfigurierbar sondern für alle AC gleich.
Z-L-ARR Audit Events (zentral)¶
Für alle im AC Kontext durchgeführten Zentraltransaktionen wird ein Protokolleintrag im Z-L-ARR geschrieben. Weiter Informationen zu Z-L-ARR Audits sind dem BeS PH zu entnehmen.
Beispielhafte Auditeinträge für einen AC können im e-Impfpass PH nachgelesen werden.
Z-L-ARR Audit Events DSUB Subscribe¶
| Erstellende Komponente | DSUB |
| Trigger Event | "DSUB Subscribe" Transaktion |
| Enthaltene Assertion | AC Kontext Assertion |
Attribute des Elements <AuditEvent>:
| Attribut | Inhalt |
|---|---|
| msgID | Der Wert des <wsa:MessageID> Elements der zugrunde liegenden Transaktion |
| eventType | "71" (Benachrichtigungsvermerk eingetragen), Wert aus Codeliste "ELGA_AuditEventType_VS". |
| result | Ergebnis der zugrunde liegenden Transaktion. "0" (Erfolg) oder "1" (Fehler) |
| datetime |
Zeitpunkt (Datum und Uhrzeit), wann die zugrunde liegende Transaktion empfangen wurde, UTC Repräsentation Format CCYY-MM-DDThh:mm:ssZ gemäß XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 Oct 2004, Datentyp "dateTime" |
| auditSrcType | "14" (DSUB Broker), Wert aus Codeliste "ELGA_AuditSourceType_VS". |
| siteID | ELGA Bereichs-OID des zentralen Berechtigungssystems. |
| srcID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der AC Kontext Assertion |
| srcIPAddrChain | Inhalt des HTTP Header Parameter 'x-forwarded-for' des empfangenen Requests. |
| destID | DSUB URL |
| destIPAddr | IP Adresse der DSUB Komponente |
| userID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:1.0:subject:subject-id" der SERVICE Assertion. |
| userRole | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:2.0:subject:role" der SERVICE Assertion. |
| trID | Transaktions ID (Transaktionsklammer) der zugrunde liegenden Transaktion. |
| patID | Patient ID auf die Subscribed wurde |
| poU | AC App ID |
| errorMsg | Fehlermeldung der zugrunde liegenden Transaktion, wenn diese nicht erfolgreich war, sonst ‘[0] success’. |
Tabelle: AuditEvent Attribute DSUB Subscribe
Z-L-ARR Audit Events DSUB Unsubscribe¶
| Erstellende Komponente | DSUB |
| Trigger Event | "DSUB Unsubscribe" Transaktion |
| Enthaltene Assertion | AC Kontext Assertion |
Attribute des Elements <AuditEvent>:
| Attribut | Inhalt |
|---|---|
| msgID | Der Wert des <wsa:MessageID> Elements der zugrunde liegenden Transaktion |
| eventType | "72" (Benachrichtigungsvermerk entfernt), Wert aus Codeliste "ELGA_AuditEventType_VS". |
| result | Ergebnis der zugrunde liegenden Transaktion. "0" (Erfolg) oder "1" (Fehler) |
| datetime |
Zeitpunkt (Datum und Uhrzeit), wann die zugrunde liegende Transaktion empfangen wurde, UTC Repräsentation Format CCYY-MM-DDThh:mm:ssZ gemäß XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 Oct 2004, Datentyp "dateTime" |
| auditSrcType | "14" (DSUB Broker), Wert aus Codeliste "ELGA_AuditSourceType_VS". |
| siteID | ELGA Bereichs-OID des zentralen Berechtigungssystems. |
| srcID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der AC Kontext Assertion |
| srcIPAddrChain | Inhalt des HTTP Header Parameter 'x-forwarded-for' des empfangenen Requests. |
| destID | DSUB URL |
| destIPAddr | IP Adresse der DSUB Komponente |
| userID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:1.0:subject:subject-id" der SERVICE Assertion. |
| userRole | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:2.0:subject:role" der SERVICE Assertion. |
| trID | Transaktions ID (Transaktionsklammer) der zugrunde liegenden Transaktion. |
| patID | Patient ID aus die initialen Subskription oder null wenn keine Subskription gefunden wurde. |
| poU | AC App ID |
| errorMsg | Fehlermeldung der zugrunde liegenden Transaktion, wenn diese nicht erfolgreich war, sonst ‘[0] success’. |
Tabelle: AuditEvent Attribute DSUB Unsubscribe
Z-L-ARR Audit Event AC Consent Einbringen¶
| Erstellende Komponente | PAP |
| Trigger Event | "AC PAP Consent einbringen" Transaktion |
| Enthaltene Assertion | AC Kontext Assertion |
Attribute des Elements <AuditEvent>:
| Attribut | Inhalt |
|---|---|
| msgID | Der Wert des <wsa:MessageID> Elements der zugrunde liegenden Transaktion |
| eventType | "6" (Submit BPPC), Wert aus Codeliste "ELGA_AuditEventType_VS". |
| result | Ergebnis der zugrunde liegenden Transaktion. "0" (Erfolg) oder "1" (Fehler) |
| datetime |
Zeitpunkt (Datum und Uhrzeit), wann die zugrunde liegende Transaktion empfangen wurde, UTC Repräsentation Format CCYY-MM-DDThh:mm:ssZ gemäß XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 Oct 2004, Datentyp "dateTime" |
| auditSrcType | "1" (PAP), Wert aus Codeliste "ELGA_AuditSourceType_VS". |
| siteID | ELGA Bereichs-OID des zentralen Berechtigungssystems. |
| srcID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der AC Kontext Assertion |
| srcIPAddrChain | Inhalt des HTTP Header Parameter 'x-forwarded-for' des empfangenen Requests. |
| destID | AC PAP URL |
| destIPAddr | IP Adresse der AC PAP Komponente |
| userID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:1.0:subject:subject-id" der SERVICE Assertion. |
| userRole | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:2.0:subject:role" der SERVICE Assertion. |
| trID | Transaktions ID (Transaktionsklammer) der zugrunde liegenden Transaktion. |
| patID | Patient ID aus den BPPC Metadaten |
| poU | AC App ID |
| errorMsg | Fehlermeldung der zugrunde liegenden Transaktion, wenn diese nicht erfolgreich war, sonst ‘[0] success’. |
Tabelle: AuditEvent Attribute Audit Events AC Consent einbringen
Z-L-ARR Audit Event AC Consent Abfragen¶
| Erstellende Komponente | PAP |
| Trigger Event | "AC PAP Consent abfragen" Transaktion |
| Enthaltene Assertion | AC Kontext Assertion |
Attribute des Elements <AuditEvent>:
| Attribut | Inhalt |
|---|---|
| msgID | Der Wert des <wsa:MessageID> Elements der zugrunde liegenden Transaktion |
| eventType | "7" (Query BPPC), Wert aus Codeliste "ELGA_AuditEventType_VS". |
| result | Ergebnis der zugrunde liegenden Transaktion. "0" (Erfolg) oder "1" (Fehler) |
| datetime |
Zeitpunkt (Datum und Uhrzeit), wann die zugrunde liegende Transaktion empfangen wurde, UTC Repräsentation Format CCYY-MM-DDThh:mm:ssZ gemäß XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 Oct 2004, Datentyp "dateTime" |
| auditSrcType | "1" (PAP), Wert aus Codeliste "ELGA_AuditSourceType_VS". |
| siteID | ELGA Bereichs-OID des zentralen Berechtigungssystems. |
| srcID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xspa:1.0:subject:organization-id" der AC Kontext Assertion |
| srcIPAddrChain | Inhalt des HTTP Header Parameter 'x-forwarded-for' des empfangenen Requests. |
| destID | AC PAP URL |
| destIPAddr | IP Adresse der AC PAP Komponente |
| userID | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:1.0:subject:subject-id" der AC Kontext-Assertion. |
| userRole | Inhalt des SAML2 Attributs "urn:oasis:names:tc:xacml:2.0:subject:role" der AC Kontext-Assertion. |
| trID | Transaktions ID (Transaktionsklammer) der zugrunde liegenden Transaktion. |
| patID | Patient ID aus den BPPC Metadaten |
| poU | AC App ID |
| errorMsg | Fehlermeldung der zugrunde liegenden Transaktion, wenn diese nicht erfolgreich war, sonst ‘[0] success’. |
Tabelle: AuditEvent Attribute Audit Events AC Consent abfragen
L-ARR Audit Events (ATNA dezentral)¶
Von der initiierenden ZGF werden für jede Transaktion (schreibend und lesend) im initiierenden ELGA Bereich abhängig vom Transaktionstyp ATNA Protokolleinträge geschrieben. Es wird ein Audit in der Rolle als Server und ein weiterer Audit in der Rolle als Client (Weiterleitung an die antwortende ZGF) geschrieben.
Zusätzlich schreibt die antwortende ZGF für jede empfangene Transaktion einen Client und einen Server ATNA Audit.
Beispielhafte Auditeinträge für einen AC können im e-Impfpass PH nachgelesen werden.