# Audit Event Service: Belegung der Protokolldaten - Implementation Guide ePA Basisfunktionalitäten v1.3.2

Implementation Guide

ePA Basisfunktionalitäten

Version 1.3.2 - release 

* [**Table of Contents**](toc.md)
* [**Basisdienst Audit Event Service**](api-audit.md)
* **Audit Event Service: Belegung der Protokolldaten**

## Audit Event Service: Belegung der Protokolldaten

Die folgenden Festlegungen beschreiben die Belegung der Protokolldaten bei der Ausgabe über die FHIR-Schnittstelle des Audit Event Services. Definiert wird, welche Informationen in welchem AuditEvent-Element bereitzustellen sind und wie die Struktur der ausgegebenen AuditEvent-Ressourcen zu verwenden ist.

In der Struktur eines Protokolleintrages (Audit Event) sind folgende Zugriffsinformationen hinterlegt: 

| | |
| :--- | :--- |
| Wann ist der Zugriff erfolgt bzw. hat das Ereignis stattgefunden? | AuditEvent.recorded |
| Wer war der Akteur/Auslöser? | AuditEvent.agent |
| Welcher Art Service wurde angefragt? | AuditEvent.type |
| Worauf wurde zugegriffen? | AuditEvent.source |
| Welcher Art war der Zugriff? | AuditEvent.action |
| War der Zugriff erfolgreich? | AuditEvent.outcome |
| Informationen zu Daten/Dokumente/Objekte | AuditEvent.entity |

**Tabelle:**Inhaltliche Definitionen eines Audit Event

 Die spezifische Befüllung eines Audit Event wird durch die jeweiligen Services vorgegeben. Allgemeine Elemente sind wie folgt zu befüllen:

funkt. Eignung: Test Produkt/FADer Audit Event Service MUSS die Audit-Event-Elemente
*AuditEvent.recorded*,
*AuditEvent.agent*und
*AuditEvent.source*wie folgt befüllen.

| | | | |
| :--- | :--- | :--- | :--- |
| recorded |  | Systemzeit bei Erstellung des Audit Event im Format YYYY-MM-DDThh:mm:ssZ | "2025-01-15T14:52:04.928Z" |
| agent[client].type.coding. |  | Information zum Auslöser des Audit Event gemäß des zulässigen Value Set |  |
| system | Das verwendete Code System; fest vorgegebener Wert: "http://dicom.nema.org/resources/ontology/DCM" | "http://dicom.nema.org/resources/ontology/DCM" | |
| code | Der verwendete Code aus dem Code System; Fest vorgegebener Wert: "110150" | "110150" | |
| display | Der Bezeichner zur Anzeige aus dem Code System; Fest vorgegebener Wert: "Application" | "Application" | |
| agent[client].who.identifier. |  | Identifikation des Auslösers des Audit Event gemäß der zulässigen Value Sets |  |
| system | Das verwendete Code System | "https://gematik.de/fhir/sid/telematik-id" | |
| value | <Telematik-Id> | "1-883110000092404" | |
| agent[client]. | altId | <value> aus agent.who.identifier | "1-883110000092404" |
| name | * <display_name> des auslösenden Akteurs aus dem ID-Token der User Session
* "Elektronische Patientenakte Fachdienst" für intern ausgelöste Audit Events
 | 1. "E-Rezept-Fachdienst"
1. "Elektronische Patientenakte Fachdienst"
1. "Portugal" (Beispiel EU-Zugriff)
 | |
| requestor | "true", wenn dieser "agent" Auslöser des AuditEvents ist oder wenn es der einzige beteiligte "agent" ist, ansonsten "false". |  | |
| agent[user].type.coding. |  | Information zum Auslöser des Audit Event gemäß des zulässigen Value Set |  |
| system | Das verwendete Code System | "http://terminology.hl7.org/CodeSystem/v3-RoleClass" | |
| code | Der verwendete Code aus dem Code System | "PROV" | |
| display | Der Bezeichner zur Anzeige aus dem Code System | "healthcare provider" | |
| agent[user].who.identifier. |  | Identifikation des Auslösers des Audit Event gemäß der zulässigen Value Sets |  |
| system | Das verwendete Code System | "https://gematik.de/fhir/sid/telematik-id" | |
| value | <Telematik-Id> oder <KVNR> | 1. "2-121212121212121"
1. "Z123456789"
 | |
| agent[user]. | altId | <value> aus agent.who.identifier | 1. "2-121212121212121"
1. "Z123456789"
 |
| agent[user].role.coding. |  | Gilt nur für professionalOID = oid_ncpeh:Wert aus SOAP eHader des Request: healthProfessionalRole |  |
| system | Das verwendete Code System | "urn:oid:2.16.840.1.113883.2.9.6.2.7" | |
| code | Der verwendete Code aus dem Code System | "221" | |
| display | Der Bezeichner zur Anzeige aus dem Code System | "Medical Doctors" | |
| agent[user].extension |  | Gilt nur für professionalOID = oid_ncpeh:Wert aus SOAP Header des Request: healthcareFacilityType;extension mit url="https://gematik.de/fhir/epa/StructureDefinition/epa-healthcare-facility-type-extension" |  |
| system | Das verwendete Code System | "urn:oid:1.3.6.1.4.1.12559.11.10.1.3.2.2.2" | |
| code | Der verwendete Code aus dem Code System | "Resident Physician" | |
| display | Der Bezeichner zur Anzeige aus dem Code System | "Resident Physician" | |
| agent[user]. | name | Gilt nur für professionalOID = oid_ncpeh:Wert aus SOAP Header des Request: <leiName> / <healthProfessionalName>Andernfalls: <display_name> des auslösenden Akteurs aus dem ID-Token der User Session | EU-Zugriff:"Clínica de Dos Santos / Dr. Manuel Dos Santos"Anderenfalls:"John Doe" |
| requestor | Fest vorgegebener Wert "true" |  | |
| agent[internal].type.coding. |  | Information zum Auslöser des Audit Event gemäß des zulässigen Value Sets |  |
| system | Das verwendete Code System | "https://gematik.de/fhir/epa/CodeSystem/epa-auditevent-sourcetype-cs" | |
| code | Der verwendete Code aus dem Code System | "HRRSVC" | |
| display | Der Bezeichner zur Anzeige aus dem Code System | " Health Record Relocation Service" | |
| agent[internal]. | altId | Fest vorgegebener Wert "epa" | "epa" |
| name | Fest vorgegebener Wert "ePA" | "ePA" | |
| requestor | Fest vorgegebener Wert "true" |  | |
| source |  | Informationen zum auslösenden Service des Aktensystems |  |
| source.observer. | display | Fester Wert "Elektronische Patientenakte Fachdienst" | "Elektronische Patientenakte Fachdienst" |
| source.type. |  | Der auslösende Service gemäß des zulässigen Value Set |  |
| system | Das verwendete Code System | "https://gematik.de/fhir/epa/ValueSet/epa-auditevent-sourcetype-vs" | |
| code | Der verwendete Code aus dem Code System | "CDMGMT" | |
| display | Der Bezeichner zur Anzeige aus dem Code System | "Consent Decision Management" | |

**Tabelle:**Befüllung AuditEvent

Hinweis:

agent[client]: Angaben zur Applikation, z.B. eRezept-Fachdienst, NCPeH

agent[user]: Angaben zu LEI oder Vertreter oder Versicherter

agent[internal]: Angaben zu systemeigenen Services.
*Hinweis: Die Speicherung von Protokolleinträgen durch einen Service erfordert einen berechtigten Benutzer, um den Zugriff auf den sicheren Datenspeicher zu gewährleisten. Daher wird die Erstellung von Protokolleinträgen immer übersprungen und es wird kein Protokolleintrag gespeichert, wenn diese Bedingung nicht erfüllt ist.*

Protokolleinträge enthalten in der Regel genau einen Eintrag zu `agent` gemäß der Protokollierungssituation. Das ist entweder ein `agent[client]`, ein `agent[user]` oder ein `agent[internal]`. Diese Einzelvorkommen von `agent` sind dann immer auch Auslöser der Protokollierung (`requestor=true`). Eine Ausnahme sind Protokolleinträge bei einem EU-Zugriff, wo ein `agent[client] (NCPeH)` und ein `agent[user] (LE)` vermerkt werden. Auslöser (`requestor = true`) ist dabei der `agent[user]`.

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenFalls für eine Operation ein Protokolleintrag gefordert ist und mit einem Fehler abgebrochen wird, MUSS der Audit Event Service jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Darüberhinaus und ergänzend zu den Vorgaben aus dem Profil EPAAuditEvent sind folgende Werte entsprechend zu belegen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.action | C, R, U, D | Create | Read | Update | Delete | |
| AuditEvent.entity.name | <service name> | Service Name, wie für Protokollierung im Service gefordert | |
| AuditEvent.entity.description | <operationId> | OperationId der mit einem Fehler abgebrochenen Operation, z.B. "providePrescription_MedicationSvc" | |
| **Nur bei FHIR Query API:** | | | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "search-parameters" | <ResourceType>?parameter1=<value>&parameter2=<value>& ...mehr | | |

**Tabelle:**Audit Event Management - Protokollierung von Fehlern

Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF bei nicht erfolgreichen Zugriffen ein Protokolleintrag NICHT erzeugt werden.

Hinweis: Die Notwendigkeit eines Protokolleintrags gemäß IG-EPA40183ED3* entfällt, wenn ein Protokolleintrag mangels eines befugten Nutzers (kein Bezug des SecureDataStorageKeys möglich) nicht im SecureDataStorage abgelegt werden kann.
#### Beispiel AuditEvent für eine fehlgeschlagene Operation

### Health Record Relocation Service

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Health Record Relocation Service des neuen (importierenden) Aktensystems MUSS nach der erfolgreichen oder einer abgebrochenen Übertragung der Inhalte eines Aktenkontos vom bisherigen Anbieter einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "object" |  | |
| AuditEvent.action | E | Übertrag von Daten eines Aktenkontos von einem anderen Anbieter | |
| AuditEvent.agent.type | PAYOR | Umzug wurde ausgelöst vom Kostenträger | |
| AuditEvent.entity.name | "HealthRecordRelocation" |  | |
| AuditEvent.entity.description | <operationId> |  | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "OriginName" | <Name des Kostenträgers> | Name des Kostenträgers, von welchem ein bestehendes Aktenkonto übernommen wird | |

**Tabelle:**Health Record Relocation Service - Protokollierung einer Relocation

*Hinweis: Der Health Record Relocation Service des bisherigen ePA-Aktensystemanbieters muss keinen Protokolleintrag gemäß IG-EPA78949PKT* erzeugen.*

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Health Record Relocation Service des neuen (importierenden) Aktensystems MUSS bei der Operation startPackageMergeImport jedes Hinzufügen eines Objekts zum Aktensystem (Merge), ausgenommen der Objekte des Medication Service, entsprechend der Protokollierungsregeln für das Objekt und der folgenden Vorgaben protokollieren.

| | | |
| :--- | :--- | :--- |
| AuditEvent.agent.type | PAYOR | Die Zusammenführung der Daten wurde durch den Kostenträger ausgelöst |
| AuditEvent.source.type | HRRSVC | Der Protokolleintrag wurde durch den Health Record Relocation Service erstellt. |
| AuditEvent.entity.name | "SystemMerge" | Zusammenführung von Daten |
| AuditEvent.entity.description | "startPackageMergeImport"; | Identifier der auslösenden Operation |

**Tabelle:**Health Record Relocation Service - Protokollierung der Zusammenführung von Daten

Operationen des Medication Service erzeugen in der Regel mehrere unterschiedliche Objekte in einem Vorgang. Die Protokollierung der Zusammenführung erfasst dabei lediglich die FHIR-Instanzen der führenden Profile, also MedicationRequest, MedicationStatement und MedicationDispense. Für die Zusammenführung der anhänglichen weiteren FHIR-Instanzen, z.B. Medication, Provenance und andere, wird kein AuditEvent erzeugt. Die Herkunft der zu protokollierenden Objektzusammenführungen des Medication Service kann nicht eindeutig einer verursachenden Operation zugeordnet werden, sondern es werden statt dessen, abhängig von Objekttyp -kontext, generische Bezeichnungen verwendet.

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Health Record Relocation Service MUSS für das Zusammenführen von Objekten der Ressourcenprofile EPA MedicationRequest, EPA MedicationStatement, EPA MedicationDispense und eMP MedicationRequest des Medication Service jeweils einen Protokolleintrag gemäß der folgenden Vorgaben erstellen.

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.agent.type | PAYOR | Die Zusammenführung der Daten wurde durch den Kostenträger ausgelöst | |
| AuditEvent.source.type | HRRSVC | Der Protokolleintrag wurde durch den Health Record Relocation Service erstellt. | |
| AuditEvent.entity.name | "SystemMerge" | Zusammenführung von Daten | |
| AuditEvent.entity.description | "startPackageMergeImport"; | Identifier der auslösenden Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** | **wenn Ressourcenprofil** |
| "Event" | "Abgabe Medikament übernommen" | EPA MedicationDispense | |
| "Verschreibung Medikament übernommen" | EPA MedicationRequest | | |
| "Nachtrag Medikament übernommen" | EPA MedicationStatement, wenn keine Referenz in`derivedFrom`enthalten ist | | |
| "Eintrag Medikationsplan übernommen" | eMP MedicationRequest | | |

**Tabelle:**Health Record Relocation Service - Protokollierung der Zusammenführung von Daten des Medication Service

*Hinweis: für die Zusammenführung von Objekten des Medication Service, welche auf anderen als den in IG-EPA83763PTC aufgeführten Ressourcenprofilen basieren, beispielsweise `EPA Medication`, wird kein AuditEvent erstellt.*

Bei der Zusammenführung (Merge) von Daten des Aktenkontos können auch Audit Event Instanzen übernommen werden. Diese werden gemäß [gemSpec_Aktensystem_ePAfueralle#A_28412-*] mit einem zusätzlichen `entity.detail` ergänzt und wie folgt belegt:

| | | |
| :--- | :--- | :--- |
| AuditEvent.entity.detail.type | System-Zusammenführung |  |
| AuditEvent.entity.detail.valueString | true |  |

**Tabelle:**Health Record Relocation Service - Markierung der Protokolle zusammengeführter Daten
#### Beispiel AuditEvent für einen regulären Aktenumzug

#### Beispiel AuditEvent für eine System-Merge-Operation, bei der ein Dokument zum XDS-Dokumentendienst hinzugefügt wird

#### Beispiel AuditEvent für eine System-Merge-Operation, bei der ein Audit Event hinzugefügt wird

#### Beispiel AuditEvent für eine System-Merge-Operation, bei der ein eMP MedicationRequest hinzugefügt wird

### Constraint Management

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDas Constraint Management MUSS für das Aufnehmen und Löschen von Einträgen in die General Deny Policy jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" | Bei Änderungen über die API | |
|  | "object" | Bei intern ausgelösten Änderungen (XDS Document Service confidentiality code ("CON"), Löschen von  Dokumenten oder Ordnern) | |
| AuditEvent.action | C, D |  | |
| AuditEvent.entity |  | Pro geändertem Eintrag der General Deny Policy ist ein entity-Element anzulegen, bei gleichzeitiger Verarbeitung von mehr als einem Eintrag (Batch-Operation) sind entsprechend mehrere entity-Einträge zu verwenden. Die Befüllung für entity.name und entity.description muss bei Verwendung von mehreren entity-Elementen gleich sein. | |
| AuditEvent.entity.name | "GeneralDenyPolicy" | Hinzufügen oder Löschen von Einträgen der GeneralDenyPolicy | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation,"internal" bei intern ausgelöster Änderung | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "DocumentTitle" | <DocumentEntry.title> | wenn sich der Eintrag (Create oder Delete) der Policy auf ein Dokument bezieht | |
| "RootDocumentId" | <rootDocumentId> | wenn sich der Eintrag (Create oder Delete) der Policy auf ein Dokument bezieht | |
| "FolderTitle" | <Folder.title> | wenn sich der Eintrag (Create oder Delete) der Policy auf einen Folder bezieht | |
| "FolderEntryUUID" | <Folder.entryUUID> | wenn sich der Eintrag (Create oder Delete) der Policy auf einen Folder bezieht | |
| "CategoryId" | <categoryId> | wenn sich der Eintrag (Create oder Delete) der Policy auf eine Kategorie bezieht | |

**Tabelle:**Constraint Management - Protokollierung Änderungen der General Deny Policy

#### Beispiel AuditEvent für das Verbergen einer Kategorie

#### Beispiel AuditEvent für gleichzeitiges Verbergen von Dokumenten und einer Kategorie

### Consent Decision Management

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDas Consent Decision Management MUSS Bei Änderungen von Entscheidungen zu den widerspruchsfähigen Funktionen der ePA jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Für die Wertebelegung ist [gemSpec_Aktensystem_ePAfueralle#A_23874] zu berücksichtigen und die Protokollstruktur entsprechend zu belegen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" |  | |
| AuditEvent.action | U |  | |
| AuditEvent.entity.name | "ConsentDecision" | Eintrag protokolliert eine Widerspruchsentscheidung | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "ConsentClass" | <consent class> | z.B. "healthCareProcess" | |
| "ConsentClassId" | <consent class Id> | z.B. "medication" | |
| "ConsentDecision" | <consent decision> | "deny" oder "permit" | |

**Tabelle:**Consent Decision Management - Protokollierung Änderungen der Entscheidungen zu widerspruchsfähigen Funktionen der ePA

*Hinweis: Die initiale Entscheidung zu den Widersprüchen bei Anlage eines Aktenkontos wird nicht protokolliert. Die spezifische Protokollierung erfolgt für Folgeänderungen.*

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDas Consent Decision Management MUSS bei jeder Änderung einer Widerspruchsentscheidung zur Verwendung der an das Forschungsdatenzentrum übermittelten Daten für bestimmte Sekundärnutzungszwecke einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen.

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" |  | |
| AuditEvent.action | U |  | |
| AuditEvent.entity.name | "DataUsagePurpose" | Eintrag protokolliert eine Widerspruchsentscheidung zu Sekundärnutzungszwecken | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** | Liste aller geänderten Widersprüche zu Sekundärnutzungszwecken |
| "purpose id" | <consent decision> | Auswahl aus <purpose Id> mit den Werten: [purpose1, purpose2, purpose3, purpose4, purpose5, purpose6, purpose7, purpose8, purpose9, purpose10] und den Werten für die Widerspruchsentscheidung <consent decision>: ["permit", "deny"] | |

**Tabelle:**Consent Decision Management - Protokollierung Änderungen der Entscheidungen zu Widersprüchen gegen Zwecke der Sekundärnutzungs

Sich.techn. Eignung: Produktgutachten
funkt. Eignung: Test Produkt/FADas Consent Decision Management MUSS für jede Änderung der User Specific Deny Policy Medication einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" |  | |
| AuditEvent.action | C, D |  | |
| AuditEvent.entity.name | "UdpMedication" | Eintrag protokolliert eine Änderung der User Specific Deny Policy für Medication Service | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "UserId" | <Telematik-ID der LEI> | Telematik-ID der LEI, welche zur User Specific Deny Policy Medication hinzugefügt oder gelöscht wurde | |
| "UserName" | <displayName> | Name der LEI, welche zur User Specific Deny Policy Medication hinzugefügt oder gelöscht wurde | |

**Tabelle:**Consent- ecision Management - Protokollierung Änderungen der User Specific Deny Policy Medication

#### Beispiel AuditEvent für Änderungen an Consent Decisions

#### Beispiel AuditEvent für Änderungen an Widersprüchen zur Sekundärdatennutzung

#### Beispiel AuditEvent für den Ausschluss einer Leistungserbringerorganisation vom Medikationsprozess

### Entitlement Management

Sich.techn. Eignung: Produktgutachten
funkt. Eignung: Test Produkt/FADas Entitlement Management MUSS für das Erteilen und Entziehen von Befugnissen und das Setzen und Löschen von Befugnisausschlüssen jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" |  | |
| AuditEvent.action | C, D, U |  | |
| AuditEvent.entity.name | "UserBlocking" | Setzen und Löschen von Befugnisausschlüssen | |
| "EntitlementManagement" | Erteilen oder Entziehen von Befugnissen | | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "blockedUserName" | <Name der LEI> | Name der LEI, für die der Befugnisausschluss gesetzt bzw. der Ausschluss zurückgenommen wurde | |
| "blockedUserId" | <Telematik-ID der LEI> | Telematik-ID der LEI, für die der Befugnisausschluss gesetzt bzw. der Ausschluss zurückgenommen wurde | |
| "UserName" | <Name der Institution oder des Vertreters> | Name der Institution oder des Nutzers für die eine Befugnis erteilt oder gelöscht wurden | |
| "UserId" | <Identifier der Institution oder des Vertreters> | ID der Institution oder des Nutzers für die eine Befugnis erteilt oder gelöscht wurden | |
| "entitledValidTo" | <Endzeitpunkt der Gültigkeit der Befugnis> | Angabe des Endes einer erteilten Befugnis, Format gemäß [RFC3339] YYYY-MM-DDThh:mm:ssZ oder YYYY-MM-DDThh:mm:ss+/-time zone | |

**Tabelle:**Entitlement Management - Protokollierung Änderungen zu Befugnissen und Befugnisausschlüssen

*Hinweis: Ein Update ("U") eines Entitlements liegt vor, wenn ein existierendes Entitlement aufgrund des längeren Gültigkeitszeitraums eines neuen Entitlements überschrieben wird.*

#### Beispiel AuditEvent für die Entitlementerstellung durch ein PVS

#### Beispiel AuditEvent für das Ausschließen einer Arztpraxis von der Befugnisvergabe (BlockedUser)

### Push Notification Management

Sich.techn. Eignung: ProduktgutachtenDas Push Notification Management MUSS für Erstellung und Änderung (CUD) von ePA-FdV-Instanz-Registrierungen jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" | Bei Änderungen über die API | |
|  | "object" | Bei intern ausgelösten Änderungen (internes Löschen einer ePA-FdV-Instanz-Registrierung nach Löschen Device Registration) | |
| AuditEvent.action | C, U, D |  | |
| AuditEvent.entity.name | "PushNotificationManagement" |  | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation, "internal" bei intern ausgelöster Änderung | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "DisplayNamePusher" | <device_display_name aus der Pusher-Registrierung> |  | |
| "DisplayNameDevice" | <displayName der Device Registration> |  | |

**Tabelle:**Push Notification Management - Protokollierung Änderungen der Pusherregistrierung

*Hinweis: DisplayNamePusher und DisplayNameDevice können gleich lauten.*

Sich.techn. Eignung: ProduktgutachtenDas Push Notification Management MUSS für Änderungen der Channel-Konfiguration jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" | Bei Änderungen über die API | |
|  | "object" | Bei intern ausgelösten Änderungen (internes Löschen einer ePA-FdV-Instanz-Registrierung nach Löschen Device Registration) | |
| AuditEvent.action | U |  | |
| AuditEvent.entity.name | "PushNotificationManagement" |  | |
| AuditEvent.entity.description | <operationId> | Id der verwendeten Operation, "internal" bei intern ausgelöster Änderung | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "channelId" | <[enabled, disabled]> | `value`wird auf den neuen Wert gesetzt | |
| Die Kardinalität der <`channelId`> | <`value`> Paare ist 1 .. *. Für jeden geänderte Wert eines Channels ist ein Eintrag erforderlich. Erfolgt der Protokolleintrag aufgrund Löschung eines Pushers, so sind die Channels zu erfassen, die vor der Löschung den Wert`enabled`hatten | | | |
| "DisplayNamePusher" | <device_display_name aus der Pusher-Registrierung> |  | |
| "DisplayNameDevice" | <displayName der Device Registration> |  | |

**Tabelle:**Push Notification Management - Protokollierung Änderungen der Channelkonfiguration

#### Beispiel AuditEvent für die Registrierung eines ePA-FdV im Aktensystem für Pushnachrichten

#### Beispiel AuditEvent für eine gelöschte Push-Registrierung aufgrund intern gelöschter Device-Registrierung

#### Beispiel AuditEvent für die Änderung der abonnierten Push-Kanäle einer Push-Registrierung

### Audit Event Service

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Audit Event Service MUSS für die Zugriffe der Ombudsstelle oder eines Vertreters auf die protokollierten Daten jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen.

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "rest" |  | |
| AuditEvent.action | R | Read | |
| AuditEvent.entity.name | "AuditEvent"   | Service Name | |
| AuditEvent.entity.description | Passend zur ausgeführten Operation ein Wert aus folgender Liste:* listAuditEvents
* getAuditEventById
* renderAuditEventsToPDF
 | operationId der zu protokollierenden Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "search-parameters" | <ResourceType>?parameter1=<value>&parameter2=<value>& ...mehr | Nur getAuditEventList |  |
| "identifier" | <id> des AuditEvents | Nur getAuditEvent |  |

**Tabelle:**Audit Event Service - Protokollierung Abrufe der AuditEvents

*Hinweis: Zugriffe des Versicherten auf die Protokolle des Audit Event Service werden nicht protokolliert.*
#### Beispiel AuditEvent für den Protokollabruf durch eine Ombudsstelle

### Patient Service

funkt. Eignung: Test Produkt/FADer Patient Service MUSS einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen und dabei folgende Wertebelegung berücksichtigen:

| | | |
| :--- | :--- | :--- |
| AuditEvent.type | "rest" |  |
| AuditEvent.action | U | Aktualisierung Basisdaten des Versicherten |
| AuditEvent.entity.name | Patient | Service Name |
| AuditEvent.entity.description | upsertPatient_PatientSvc | operationId der zu ausgeführten Operation |

**Tabelle:**Patient Service - Protokollierung Änderungen der Patient Information
#### Beispiel AuditEvent für die Änderung der Patient-Information durch einen Kostenträger

### Medication Service

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Medication Service MUSS einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen und dabei folgende Wertebelegung berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| type |  | "rest" |  |
| action | OperationId: providePrescription_MedicationSvc | "C" | Einstellen von Verschreibungsdaten |
| OperationId: provideDispensation_MedicationSvc | "C" | Einstellen einer Medikamentenabgabe | |
| OperationId: cancelPrescription_MedicationSvc | "U" | Stornieren von Verschreibungsdaten | |
| OperationId: cancelDispensation_MedicationSvc | "U" | Stornieren einer Medikamentenabgabe | |
| OperationId: getMedicationList_MedicationSvc | "R" | Abruf der Medikationsliste | |
| OperationId: renderMedicationListToHTML_MedicationSvc | "R" | Abruf der Medikationsliste im HTML-Format | |
| OperationId: renderMedicationListToPDF_MedicationSvc | "R" | Abruf der Medikationsliste im PDF-Format | |
| OperationId: listMedications_MedicationSvc | "R" | Abruf von Medikatimenteninformationen | |
| OperationId: listMedicationDispenses_MedicationSvc | "R" | Abruf von Medikamentenabgabeinformationen | |
| OperationId: listMedicationRequests_MedicationSvc | "R" | Abruf von Verschreibungsinformationen | |
| OperationId: listMedicationStatements_MedicationSvc | "R" | Abruf von Medikationsinformationen | |
| OperationId: listOrganizations_MedicationSvc | "R" | Abruf von Leistungserbringerinstitutionen | |
| OperationId: listPractitioners_MedicationSvc | "R" | Abruf von Leistungserbringern | |
| OperationId: listPractitionerRoles_MedicationSvc | "R" | Abruf von Zuordnungen von Leistungserbringenden zu Leistungserbringerinstitutionen | |
| OperationId: listProvenances_MedicationSvc | "R" | Abruf von Änderungs- oder Medikationsplanchronologieeinträgen | |
| OperationId: addEMLEntry_MedicationSvc | "C" | Eintrag in Medikationsliste hinzufügen | |
| OperationId: cancelEMLEntry_MedicationSvc | "U" | Eintrag in Medikationsliste stornieren | |
| OperationId: addEMPEntry_MedicationSvc | "C" | Eintrag in Medikationsplan hinzufügen | |
| OperationId: updateEMPEntry_MedicationSvc | "U" | Eintrag in Medikationsplan aktualisieren | |
| OperationId: linkEMP_MedicationSvc | "U" | Eintragsverknüpfung Medikationsplan/Medikationsliste | |
| OperationId: unlinkEMP_MedicationSvc | "U" | Aufhebung Eintragsverknüpfung Medikationsplan/Medikationsliste | |
| OperationId: renderMedicationPlanToPDF_MedicationSvc | "R" | Abruf des Medikationsplans im PDF-Format | |
| OperationId: getMedicationPlan_MedicationSvc | "R" | Abruf des Medikationsplans | |
| OperationId: getMedicationPlanChronologyLog_MedicationSvc | "R" | Abruf der Medikationsplanchronologie | |
| OperationId: batchEMPEntries_MedicationSvc | "C" | Stapelbasierte Erstellung/Aktualisierung des Medikationsplans | |
| entity.name |  | "Medication Service" | Service Name |
| entity.description |  | <operationId> | operationId der ausgeführten Operation |
| **Nur bei FHIR Query API:** | | | |
| entity.detail | **type** | **value[x]** |  |
| "search-parameters" | <ResourceType>?parameter1=<value>&parameter2=<value>& ...mehr | Suchkriterien in URL-Query-Notation | |

**Tabelle:**Medication Service - Protokollierung von Operations

*Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF der Medication Service einen Protokolleintrag NICHT erzeugen.*
Ereignisse, die gemäß [gemSpec_Aktensystem_ePAfueralle#A_26298] zu einer Übertragung neuer oder geänderter Daten an das Forschungsdatenzentrum (FDZ) führen, erzeugen grundsätzlich einen eigenen Protokolleintrag für den Vorgang gemäß der Vorgaben in IG-EPA14908QQV-*. Liegt kein Widerspruch des Versicherten gegen die Übermittlung der Daten an das FDZ vor und ist eine Übertragung der Daten des Ereignisses aufgrund der Pseudonymisierbarkeit dieser Daten  möglich, so folgt auf das ursächliche Ereignis automatisch der Export der pseudonymisierten Daten.

Diese Übertragung der Daten muss für einen Versicherten aus der Protokollierung ersichtlich sein. Anstelle eines dedizierten Protokolleintrags für die Datenübertragung wird die Datenübertragung als ergänzendes entity.detail des auslösenden Ereignisses protokolliert. Aus dem Protokolleintrag des Ereignisses ist dann ersichtlich, ob die betroffenen Daten in pseudonymisierter Form auch der sekundären Datennutzung zugeführt wurden.

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer Medication Service MUSS einen Protokolleintrag gemäß A_24849* um das folgend aufgeführte
`entity.detail`  mit dem Wert
`true`ergänzen, wenn aus der Operation eine Übertragung von Daten an das FDZ folgt. Diese Ergänzung MUSS entweder den Wert
`false`haben oder entfallen, wenn aus der Operation keine Übertragung von Daten an das FDZ folgt.

| | | |
| :--- | :--- | :--- |
| entity.detail.type | "data-submission" | Export an das Forschungsdatenzentrum |
| entity.detail.value[x] | "true" oder "false" |  |

**Tabelle:**Medication Service - Protokollierung der Verwendung für sekundäre Nutzungszwecke
#### Beispiel AuditEvent für den Medication Service beim Stornieren einer Dispensierung

#### Beispiel AuditEvent des Medication Service für eine Suche

#### Beispiel AuditEvent für den Medication Service bei Verschreibungsdaten einstellen mit Datenübermittlung

### MHD Service

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer MHD Service MUSS einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen und dabei folgende Wertebelegung berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| type |  | "rest" |  |
| action | OperationId: findDocumentReferences_MHDSvc | "R" | Suche von Dokumenten |
| OperationId: retrieveDocument_MHDSvc | "R" | Abruf eines Dokuments | |
| entity.name |  | "MHD Service" |  |
| entity.description |  | <operationId> | operationId der ausgeführten Operation |
| entity.detail | **type** | **value[x]** |  |
| "search-parameters" | <ResourceType>?parameter1=<value>&parameter2=<value>& ...mehr | Nur findDocumentReferences_MHDSvcSuchkriterien in URL-Query-Notation | |
| "file-name" | <DocumentReference.identifier.entryUUID>.<file_extension> | Nur retrieveDocument_MHDSvc | |

**Tabelle:**MHD Service - Protokollierung MHD Operationen

*Hinweis: Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF der MHD Service einen Protokolleintrag NICHT erzeugen.*
#### Beispiel AuditEvent aus dem MHD-Service für eine Suche

### XDS Document Service

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer XDS Document Service MUSS für die Operationen
* ProvideAndRegisterDocumentSet-b,
* RetrieveDocumentSet,
* RemoveMetadata,
* RegistryStoredQuery (entfällt, wenn Nutzung durch den Versicherten erfolgt)
Protokolleinträge gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen und dabei folgende Wertebelegung berücksichtigen:

* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.type
  * ?: "document"
  * ?: 
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.action
  * ?: C
  * ?: Für ProvideAndRegisterDocumentSet-b ohne Replace-Option
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: U
  * ?: Für ProvideAndRegisterDocumentSet-b mit Replace-Option
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: R
  * ?: Für RegistryStoredQuery
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: R
  * ?: Für RetrieveDocumentSet
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: D
  * ?: Für Zugriffe mit RemoveMetadata
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.entity.name
  * ?: "XDS Document Service"
  * ?: Service Name
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.entity.description
  * ?: <Operation>
  * ?: ein Wert aus {ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet, RemoveMetadata, RegistryStoredQuery}
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.entity.detail
  * ?: **type**
  * ?: **value[x]**
  * ?: 
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "DocumentFormatCode"
  * ?: <DocumentEntry.formatCode>
  * ?: wenn in der entity Struktur ein XDSDocument beschrieben wird. kodiert als Datentyp "Coded String" gemäß [IHE-ITI- TF3]. Wenn es sich beim Wert von DocumentEntry.formatCode um den Code urn:ihe:iti:xds:2017:mimeTypeSufficient (Code System 1.3.6.1.4.1.19376.1.2.3) handelt, MUSS stattdessen der Wert von DocumentEntry.mimeType hier eingetragen werden.
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "DocumentUniqueId"
  * ?: <Document.uniqueId>
  * ?: wenn in der entity Struktur ein XDSDocument beschrieben wird
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "DocumentEntryTitle"
  * ?: <DocumentEntry.title>
  * ?: wenn in der entity Struktur ein XDSDocument beschrieben wird
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "FolderTitle"
  * ?: <Folder.title>
  * ?: wenn in der entity Struktur ein XDSFolder beschrieben wird
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "FolderCodeList"
  * ?: <Folder.codeList>
  * ?: wenn in der entity Struktur ein XDSFolder beschrieben wird kodiert als Datentyp "Coded String" gemäß [IHE-ITI-TF3] z.B. "pregnancy_childbirth^^^&1.2.276.0.76.5.512&ISO"
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "FolderEntryUUID"
  * ?: <Folder.entryUUID>
  * ?: wenn in der entity Struktur ein XDSFolder beschrieben wird
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: Parameterwerte für die Operation RegistryStoredQuery (entfällt, wenn der Versicherte der Nutzer ist)
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: AuditEvent.entity.detail
  * ?: **type**
  * ?: **value[x]**
  * ?: 
* Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata: "QueryId"
  * ?: <Parameter Query ID>
  * ?: Der Wert MUSS der Parameter Query ID gemäß [IHE-ITI-TF2]#3.18.4.1.2.4 und für das Aktensystem definierten Anfragetypen entsprechen.

**Tabelle:**XDS Document Service - Protokollierung der Dokumentenoperationen
*Hinweis: In der `AuditEvent.entity` Struktur sind Dokumente und/oder Folder zu berücksichtigen, die in der zu protokollierenden Operation referenziert werden.*

funkt. Eignung: Test Produkt/FA
Sich.techn. Eignung: ProduktgutachtenDer XDS Document Service MUSS für die Operationen RestrictedUpdateDocumentSet Protokolleinträge gemäß [gemIG_ePA_Basic#IG-EPA90980V11] erzeugen und dabei folgende Wertebelegung berücksichtigen:

| | | | |
| :--- | :--- | :--- | :--- |
| AuditEvent.type | "document" |  | |
| AuditEvent.action | U |  | |
| AuditEvent.entity |  | Kann gemäß folgender Regeln mehrfach vorhanden sein | |
| AuditEvent.entity.name | "XDS Document Service" | Service Name | |
| AuditEvent.entity.description | "RestrictedUpdateDocumentSet" | Id der Operation | |
| AuditEvent.entity.detail | **type** | **value[x]** |  |
| "DocumentTitle" | <Titel des Dokuments> | Titel des betroffenen Dokuments. Dieser Eintrag ist pro entity einmal vorhanden und identisch in allen verwendeten entity des AuditEvents | |
| geänderte Metadaten in jeweils einem`detail` | die geänderten Metadaten gemäß folgender Regeln | | |

**Tabelle:**XDS Document Service - Protokollierung der Operation RestrictedUpdateDocumentSet

| | | |
| :--- | :--- | :--- |
| 1 | Alle geänderten Metadaten MÜSSEN mit altem und neuem Wert in je einem`AuditEvent.entity.detail`protokolliert werden. Der Parameter`detail.type`enthält ein Kompositum aus Objekt (Document) und Attribut in Groß/Kleinschreibung (CamelCase). Einem alten Wert wird zusätzlich der Präfix "prev" vorangestellt. | "DocumentEntry.formatCode" wird zu "DocumentFormatCode", bzw. "prevDocumentFormatCode" |
| 2 | Attributunterstrukturen werden ebenfalls in Groß/Kleinschreibung (CamelCase) erstellt. | "DocumentEntry.authorPerson" wird zu "DocumentAuthorPerson", bzw. "prevDocumentAuthorPerson" |
| 3 | Das`detail.value[x]`(valueString) ist mit dem jeweiligen Wert zu belegen. Das Format der Zeichenkette entspricht der des Metadatums | Kann gemäß folgender Regeln mehrfach vorhanden sein |
| 4 | Jede`AuditEvent.entity` MUSS ein detail mit dem Titel des betroffenen Dokuments enthalten ("DocumentTitle"), um den Bezug der | "DocumentTitle" | "Titel des Dokuments" |
| 5 | Ist der Dokumententitel selbst Bestandteil der Änderung der Metadaten, MUSS dieses detail den neuen Titel des Dokuments enthalten (Das`entity.detail`zu "DocumentTitle" wird innerhalb einer`entity`nicht mehrfach aufgeführt). |  |
| 6 | Werden mehrere gleichartige Metadaten geändert, so MÜSSEN diese in jeweils einem eigenen`entity.detail`erfasst werden. |  |
| 7 | Eine geänderte Reihenfolge gleichartiger Metadaten ist keine Änderung der Metadaten und wird nicht protokolliert. |  |
| 8 | Erfolgen Änderungen an Attributunterstrukturen, deren übergreifendes Attribut eine Kardinalität (u .. v) mit v-u > 1 aufweist, so MÜSSEN die einzelnen Instanzen des übergreifenden Attributs in jeweils einer eigenen`AuditEvent.entity`erfasst werden.  | Diese Regel ist bei Änderungen an Unterstrukturen zu "author" anzuwenden |
| 9 | Werden mehrere`AuditEvent.entity`zur Separation von Instanzen übergreifender Attribute für die Protokollierung verwendet, dann MUSS in jeder dieser`AuditEvent.entity`die gleiche Angabe zu`name`und`description`enthalten sein |  |
| 10 | Werden mehrere`AuditEvent.entity`zur Separation von Instanzen übergreifender Attribute für die Protokollierung verwendet, dann MÜSSEN alle Änderungen an Metadaten (`detail`) ohne Bezug auf das übergreifende Attribut innerhalb der gleichen`AuditEvent.entity`aufgeführt werden.  |  |
| 11 | Werden durch eine Operation die Metadaten mehrerer Dokumente verändert, dann MUSS pro Dokument mindestens eine`AuditEvent.entity`, im Bedarfsfall aufgrund von Änderungen an übergreifenden Attributen auch mehrere (siehe Regel Nr. 8), angelegt werden.`AuditEvent.entity`des gleichen Dokuments MÜSSEN im`AuditEvent`aufeinanderfolgen |  |

**Tabelle:**Regeln für die Protokollierung der Operation RestrictedUpdateDocumentSet
*Hinweis zur Protokollierung der Operation RestrictedUpdateDocumentSet: 
Ein Protokolleintrag für eine Operation RestrictedUpdateDocumentSet enthält in der Regel genau einen Eintrag `AuditEvent.entity` und darin die Liste der (`type` | `value`)-Pärchen mit den Änderungen an Metadaten in `entity.detail`, inklusive eines Eintrags für den Dokumententitel des betroffenen Dokuments. Als übergreifendes Attribut gibt es derzeit unter den änderbaren Metadaten nur das Attribut "author". Dieses ist selbst kein änderbares Metadatum, sonder dient der Gruppierung der untergeordneten Metadaten (beispielsweise "authorPerson" oder "authorSpeciality"). Hat ein Dokument mehr als einen "author" (Instanz) zugeordnet, so muss im Protokoll der Bezug der Metadatenänderung eines "author" zu seiner Instanz erkennbar sein. Dieses wird durch die Verwendung einer jeweils eigenen `AuditEvent.entity` zu Separation ermöglicht.*

*Hinweis zur Protokollierung RestrictedUpdateDocumentSet: 
Bei Änderungen von Metadaten eines übergreifenden Attributs (hier "author") wird immer der vollständige Satz der resultierenden Attributunterstrukturen in der Operation angegeben (beispielsweise "authorPerson", "authorSpeciality" und andere), auch wenn diese bisher schon vorhanden sind. Ein AuditEvent kann dann in zwei Varianten erstellt werden:*

* *Kurzform:  In der `AuditEvent.entity` für die betroffene "author"-Instanz sind nur die tatsächlich geänderten Metadaten aufgeführt (Metadatum + prevMetadatum).*
* *Langform: Die Operation wird als vollständiger Austausch eines oder mehrerer "author"-Instanzen betrachtet. Es sind dann je eine `AuditEvent.entity` pro bisherigem "author" zu verwenden (nur prevMetadatum, alle Metadaten zu dieser "author"-Instanz werden entfernt) und je eine `AuditEvent.entity` pro "author" aus der Operation (nur Metadaten, alle Metadaten zu dieser "author"-Instanz kommen neu hinzu).*

*Die Auswahl der Variante obliegt dem realisierenden System. *

funkt. Eignung: Test Produkt/FAWerden mehrere XDS Dokumente bzw Folder in der zu protokollierenden Operation referenziert und die Zugriffe sind gleicher Art (AuditEvent.action) KANN der XDS Document Service einen Protokolleintrag erzeugen, der mehreren
*AuditEvent.entity*Strukturen enthält.
Das bedeutet, wenn in einer ProvideAndRegisterDocumentSet-b Operation zehn Dokumente eingestellt werden, kann für diesen Zugriff ein AuditEvent mit zehn Entity Strukturen erzeugt werden. Werden zehn Dokumente eingestellt und das zehnte Dokument ersetzt ein bereits vorhandenes, kann in einem Protokolleintrag das Einstellen (Create) mit neun Entity Strukturen dokumentiert und muss in einem weiteren Protokolleintrag ein Ersetzen (Update) (zehnte Dokument) protokolliert werden.

funkt. Eignung: Test Produkt/FAWerden mit der Operation RestrictedUpdateDocumentSet keine geänderten Metadaten eines referenzierten DocumentEntry gesendet, d.h. die gesendeten Metadateninhalte unterscheiden sich nicht von bereits persistierten Werten, DARF der XDS Document Service diesen Zugriff NICHT protokollieren.
#### Beispiel AuditEvent für eine XDS-Dokumentservice-Operation, bei der ein Dokument hinzugefügt wird

#### Beispiel AuditEvent für einen EU-Zugriff mit Dokumentabruf

#### Beispiel AuditEvent für die Änderung der Metadaten eines XDS Dokuments

#### Beispiel AuditEvent für die Änderung an mehreren 'author' Metadaten eines XDS Dokuments

Hinweis: Für das Beispiel wird angenommen, dass eine Zuordnung der 'author'-Inhalte aus der Operation zu den hinterlegten 'author'-Daten möglich ist (z.B.: anhand der ebRIM 'author' Classification)

### Spezieller Ordner "technical"

funkt. Eignung: Test Produkt/FADer XDS Document Service DARF Zugriffe auf den statischen Ordner "technical" oder dessen Inhalte NICHT protokollieren.

Sich.techn. Eignung: ProduktgutachtenDer XDS Document Service MUSS Nutzerzugriffe auf den Ordner "technical" dann protokollieren, wenn durch den Zugriff Dokumente Protokolldokumente einer ePA-2.6 Aktenkontomigration betroffen sind. Diese Protokollierung MUSS gemäß der Vorgaben in IG-EPA81505MFF-* erfolgen. 

