C_12517_Anlage

1 Allgemeine Hinweise

Die bisher veröffentlichten FHIR Implementation Guides (IGs) erhalten feste, logische Spezifikationsnamen:

• gemIG_ePA_Medication
• gemIG_ePA_Basic
• gemIG_ePA_MHD
• gemIG_TI_Terminology
• gemIG_TI_Common

Anforderungen in den IGs werden den etablierten Steckbriefen (wie z. B. gemProdT_Aktensystem_ePA) zugeordnet. Die nachstehenden Dienste müssen durch das ePA-Aktensystem implementiert werden; das grundsätzliche Implementierungserfordernis der Medical Services bzw. der spezifischen FHIR Data Services ist in A_25716-02 (Services ausschließlich in der VAU) gegeben.

• EPA-Audit-Service
• EPA-Medication-Service
• EPA-Patient-Service
• EPA-MHD-Service

In Kapitel 4 erfolgt eine Zusammenfassung aller nachfolgend aufgeführten Änderungen.

2 Abzukündigende Anforderungen

2.1 gemSpec_Aktensystem_ePAfueralle

Durch die Einführung von Steckbriefen zu FHIR IGs werden die nachstehenden Anforderungen obsolet und werden abgelöst.

Diese Anforderung ist redundant zuIG-MHD96412M8R und wird deshalb gelöscht.

Die Anforderung IG-EPA67312T3G schreibt die Implementierung von Query API und Render API für den Audit Event Service vor, sodass die nachfolgenden beiden Anforderungen ebenso obsolet bzw. redundant sind und daher storniert werden:

2.2 gemSpec_ePA_FdV

Mit den Anforderungen an das ePA-FdV im Change C_12462 wird gemProdT_ePA_FdV die Schnittstellennutzung vorgeben, sodass die nachstehende Anforderung redundant ist und gelöscht wird.

Die Anforderungen IG-MHD09330VY0 und IG-MHD85182N8X-2 fordern die Nutzung der spezifischen API in gemIG_ePA_MHD, sodass die nachstehende Anforderung redundant ist und gelöscht wird.

2.3 gemILF_PS_ePA

3.10.2 Medikationsprozess

Alt

o.g. Anforderung ist durch die Nutzung der spezifischen API-Anforderungen (z.B. IG-MED43098L7G) redundant und wird gelöscht.

3.11.2.2 Dokumente suchen [ITI-67]

Alt

o.g. Anforderung ist durch die Nutzung der spezifischen API-Anforderung IG-MHD43754U4W redundant und wird gelöscht.

3.11.3.2 Dokumente laden [ITI-68]

Alt

o.g. Anforderung ist durch die Nutzung der spezifischen API-Anforderung IG-MHD43754U4W redundant und wird gelöscht.

4.2.3 Protokolldaten dem Versicherten zur Verfügung stellen

Alt

o.g. Anforderungen sind redundant zu bereits bestehender, nachstehender Anforderung und werden daher gelöscht:

IG-EPA61922SAN-3 - Schnittstellennutzung des Audit Event Service - MUSS

Das ePA-Client-System Ombudsstelle sowie das ePA-FdV MÜSSEN die Nutzung der die in diesem Implementation Guide definierten Schnittstellen (d.h. Query API: AuditEvent und Render API: PDF Audit) implementieren.
EPA-CS-Ombudsstelle, EPA-FdV [<=]

3 Zu verschiebende Anforderungen

3.1 gemSpec_Aktensystem_ePAfueralle

Anforderungen der Abschnitte 3.13.2 sowie 13.14 in gemSpec_Aktensystem_ePAfueralle werden in die dedizierten FHIR IGs verschoben und erhalten eine neue Afo-ID (d.h. alte die Anforderung bewirkt Wegfall/Ablösen der Festlegungen; neue Anforderung bewirkt neue Festlegung). Die Anforderungen selbst und die Prüfverfahren bleiben unverändert.

3.13.2.1 Patient Service

Alt

Neu

Die nachstehende Afo setzt C_12432 um.

IG-EPA95476FRN - Protokolleinträge für Zugriffe auf den Patient Service - MUSS

Der Patient Service MUSS einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen und dabei folgende Wertebelegung berücksichtigen:

Strukturelement	Wert	Erläuterung
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

3.13.2.2 Medication Service

Alt

Neu

Anforderung wird gestrichen (s.o.)

---

Alt

Neu

IG-MED72454UMG - Medication Service - Erzeugung eines XHTML-Exports - MUSS

Der Medication Service MUSS für die Generierung der Medikationsliste im XHTML-Format nach [XHTML] sicherstellen, dass kein ausführbarer Code im Export enthalten ist.
EPA-APO, EPA-PS, EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED31287N4W - Medication Service - Ablehnung von Request bei vorliegendem Widerspruch - MUSS
Der Medication Service MUSS jeden HTTP Request von Clients mit professionOID != oid_erp-vau, oid_versicherter mit dem HTTP Status Code 423 (LOCKED) abbrechen, sofern im Consent Decision Management in der Funktionsklasse ("healthCareProcess") mit der Funktion ("medication") die Entscheidung ("deny") gesetzt ist.EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED67431CY7 - Medication Service - Ablehnung neuer Daten bei vorliegendem Widerspruch - MUSS

Der Medication Service MUSS jeden HTTP Request von Clients mit professionOID == oid_erp-vau mit dem HTTP Status Code 423 (LOCKED) abbrechen, sofern im Consent Decision Management in der Funktionsklasse ("healthCareProcess") mit der Funktion ("erp-submission") die Entscheidung ("deny") gesetzt ist.
EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED29593UZM - Medication Service - Löschen der Daten des Medication Service - MUSS

Der Medication Service MUSS alle vorhandenen fachlichen Daten des Medication Service löschen, wenn im Consent Decision Management in der Funktionsklasse ("healthCareProcess") mit der Funktion ("erp-submission") die Entscheidung ("deny") gesetzt wird.
EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED25363BKT - Medication Service - Ablehnung von Request bei vorliegendem Widerspruch gegen die Nutzung durch eine spezifische LEI - MUSS

Der Medication Service MUSS jeden HTTP Request von Clients mit professionOID gemäß [gemSpec_Aktensystem_ePAfueralle#A_26406] mit dem HTTP Status Code 423 (LOCKED) abbrechen, sofern im Consent Decision Management die LEI der User Session in der User Specific Deny Policy des Medication Service enthalten ist.EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED24600WA1 - Medication Service - Schemavalidierung - MUSS

Der Medication Service MUSS im Body der HTTP-POST-Operation die übertragenen Parameter auf Schadcode prüfen und fachfremde Daten (d.h. Schemavalidierung) prüfen und im Fehlerfall das Ausführen der Operation mit dem HTTP Status Code 400 abbrechen.
EPA-Medication-Service [<=]

---

Alt

Neu

IG-MED29796HBG - Medication Service - Nutzung der FHIR-Operationen durch den E-Rezept-Fachdienst - MUSS
Der Medication Service MUSS sicherstellen, dass die folgenden FHIR-Operationen ausschließlich durch den E-Rezept-Fachdienst mit der professionOID oid_erp-vau genutzt werden dürfen:

• providePrescription_MedicationSvc
• cancelPrescription_MedicationSvc
• provideDispensation_MedicationSvc
• cancelDispensation_MedicationSvc

EPA-Medication-Service [<=]

---

Alt

Ereignisse, die gemäß A_26298* zu einer Übertragung neuer oder geänderter Daten an das FDZ führen, erzeugen grundsätzlich einen eigenen Protokolleintrag für den Vorgang gemäß der Vorgaben in A_24849*. 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.

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA14908QQV - Medication Service - Protokolleinträge für Zugriffe auf den Medication Service - MUSS
Der Medication Service MUSS einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen und dabei folgende Wertebelegung berücksichtigen:

Strukturelement [AuditEvent.]	Operationen der Schnittstellen I_Medication_Service_FHIR und I_Medication_Service_eML_Render und FHIR Query API	Wert	Erläuterung
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:updateEMLEntry_MedicationSvc	"U"	Eintrag in Medikationsliste aktualisieren
	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		"search-parameters"
entity.detail.value[x]		<ResourceName>?parameter1=<value>&parameter2=<value>& ...mehr	Suchkriterien in URL-Query-Notation

Tabelle: Medication Service Protokollierung

Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF der Medication Service einen Protokolleintrag NICHT erzeugen.
EPA-Medication-Service [<=]

Ereignisse, die gemäß [gemSpec_Aktensystem_ePAfueralle#A_26298] zu einer Übertragung neuer oder geänderter Daten an das 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.

---

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA14908CEX - Medication Service - Protokollierung des Datenexports an das FDZ - MUSS
Der 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.

Strukturelement	Wert	Erläuterung
entity.detail.type	"data-submission"	Export an das Forschungsdatenzentrum
entity.detail.value[x]	"true" oder "false"

Tabelle: Medication Service Protokollierung FDZ
Hinweis: Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF der MHD Service NICHT einen Protokolleintrag erzeugen.
EPA-Medication-Service [<=]

3.13.2.3 MHD Service

Alt

Hinweis zu A_27667-*: Auch für den MHD Service sind die übergreifenden Anforderungen A_15159 zum Schutz gegen die OWASP Risiken und A_24783 zur Eingabevalidierung zu berücksichtigen, um zu verhindern, dass Schadcode über Suchanfragen ins Aktensystem eingebracht werden kann.

Neu

A_27667-03 ist redundant zu IG-MHD96412M8R, sodass lediglich der anschließende Hinweis auf die Seite "Generelle Prinzipien" in gemIG_ePA_MHD verschoben und adaptiert wird.

IG-MHD96412M8R - Schnittstellenimplementierung des MHD Services (IHE ITI Document Responder) gemäß FHIR-Spezifikation im ePA-Aktensystem - MUSS
Der Anbieter des ePA-Aktensystems MUSS den in diesem Leitfaden definierten MHD Service implementieren und dabei die Vorgaben der [FHIR-Spezifikation] berücksichtigen. Der MHD Service MUSS den logischen IHE ITI Akteur Document Responder mit seinen Schnittstellen Find Document References [ITI-67] und Retrieve Document [ITI-68] implementieren. Der Anbieter des ePA-Aktensystems MUSS die Konformität der MHD-Service-Implementierung in einem Zulassungsverfahren nachweisen.
EPA-MHD-Service [<=]

Hinweis zu IG-MHD96412M8R-*: Für den MHD Service sind die übergreifenden Anforderungen [gemSpec_Aktensystem_ePAfueralle#A_15159] zum Schutz gegen die OWASP-Risiken und [gemSpec_Aktensystem_ePAfueralle#A_24783] zur Eingabevalidierung zu berücksichtigen, um zu verhindern, dass Schadcode über Suchanfragen ins ePA-Aktensystem eingebracht werden kann.

---

Alt

Hinweis zu A_27892-*: Nutzer dürfen durch den MHD Service keinen Zugriff auf Dokumente erhalten, auf den sie über den XDS Document Service nicht zugreifen dürften. So dürfen Nutzer mittels des MHD Services keinen Zugriff auf Dokumente einer Dokumentenkategorie erhalten, auf die sie nach der Legal Policy nicht zugreifen dürfen. Genauso dürfen sie über den MHD Service keine Dokumente finden, die auf der General Deny Policy stehen.

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_MHD

IG-MHD45146PEW - MHD Service - Durchsetzen der Zugriffskontrolle für XDS Document Service - MUSS
Der MHD Service MUSS bei einer Suchanfrage durch einen Nutzer alle Zugriffsregeln durchsetzen, die für den Zugriff dieses Nutzers bzgl. des XDS Document Service gelten.
EPA-MHD-Service [<=]

Hinweis zu IG-MHD45146PEW-*: Nutzer dürfen durch den MHD Service keinen Zugriff auf Dokumente erhalten, auf den sie über den XDS Document Service nicht zugreifen dürften. So dürfen Nutzer mittels des MHD Services keinen Zugriff auf Dokumente einer Dokumentenkategorie erhalten, auf die sie nach der Legal Policy nicht zugreifen dürfen. Genauso dürfen sie über den MHD Service keine Dokumente finden, die auf der General Deny Policy stehen.

---

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_MHD

IG-MHD64112RWT - MHD Service - Filtern von verborgenen Metadaten und Dokumenten - MUSS

Der MHD Service MUSS bei einer Suchanfrage bei jedem Dokument einer verborgenen Datenkategorie die Metadaten (bzw. korrespondierende FHIR-Ressource DocumentReference) filtern sowie den Dokumentenabruf aus DocumentReferences.content.attachment.url verhindern (HTTP Code 404 not found).
EPA-MHD-Service [<=]

---

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA29056FPX - MHD Service – Protokolleinträge für Zugriffe auf den MHD Service - MUSS

Der MHD Service MUSS einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen und dabei folgende Wertebelegung berücksichtigen:

Strukturelement [AuditEvent.]	Operationen der FHIR Query API	Wert	Erläuterung
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		"search-parameters" "file-name"	findDocumentReferences_MHDSvc retrieveDocument_MHDSvc
entity.detail.value[x]		<ResourceName>?parameter1=<value>&parameter2=<value> ...mehr	Suchkriterien in URL-Query-Notation (nur bei findDocumentReferences_MHDSvc) retrieveDocument_MHDSvc

Tabelle: MHD Service Protokollierung

Hinweis: Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF der MHD Service NICHT einen Protokolleintrag erzeugen.
EPA-MHD-Service  [<=]

3.13.2.4 Dienstübergreifende Festlegungen

Alt

Die verschiedenen Schnittstellen (z. B. XDS Document Service oder Consent Decision Management Service) definieren konkrete Fehlercodes.

Neu

IG-EPA50964Z2A - FHIR Data Service – Durchführung von Datenmigrationen - MUSS
Wenn Migrationsvorgaben für den Datenbestand eines FHIR Data Services für verschiedene Versionen des Services existieren, MUSS der FHIR Data Service alle bislang nicht angewandten Datenmigrationsvorgaben in der richtigen Reihenfolge (d.h. nacheinander die jeweils für die Version benannten Migrationsschritte beginnend mit der kleinsten Versionsnummer hin zur höchsten Versionsnummer) ausführen oder, alternativ eine Migration der Daten vornehmen, die zum selben Ergebnis führt.
EPA-Medication-Service[<=]

IG-EPA49593GT2 - FHIR Data Service – Aktenkontostatus bei fehlerhafter Datenmigration - MUSS
Wenn bei der Durchführung von Migrationen gemäß IG-EPA50964Z2A* Fehler auftreten, die eine Migration des Datenbestands verhindern, MUSS das ePA-Aktenkonto in den Aktenkontostatus INACCESSIBLE wechseln, als Ursache die fehlgeschlagene Datenmigration speichern und einen entsprechenden Fehler zurückgeben.
EPA-Medication-Service [<=]

Die verschiedenen Schnittstellen (z.B. XDS Document Service oder Consent Decision Management Service) definieren konkrete Fehlercodes.

3.14 Audit Event Service

Hinweis: Die nachstehende Auflistung ist eine 1:1 Darstellung des jeweiligen Abschnitts ohne die Afos alt/neu direkt zu nennen.

Die Anforderungen selbst haben sich inhaltlich nicht geändert, die Prüfverfahren ebensowenig.

Alt

Ereignisse und Zugriffe auf die ePA eines Versicherten werden im ePA Aktensystem protokolliert. Die Protokollierung dient der Datenschutzkontrolle für den Versicherten.
Der Audit Event Service ist ein FHIR Data Service und ermöglicht dem Versicherten, befugten Vertretern bzw. der Ombudsstelle den Zugriff auf diese Protokollinformationen.

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

Tabelle 4 : Inhaltliche Definitionen eines AuditEvent

Information	Strukturelement
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

Die spezifische Befüllung eines Audit Events gemäß A_24704* wird durch die jeweiligen Services vorgegeben. Allgemeine Elemente sind wie folgt zu befüllen:

Die Protokolleinträge können durch den Versicherten oder durch einen befugten Vertreter mittels ePA-FdV eingesehen werden. Versicherte ohne ePA-FdV können bei ihrer zuständigen Ombudsstelle beantragen, die Protokolldaten zur Verfügung gestellt zu bekommen.

Für eine Abfrage der Protokolleinträge als strukturierte Einträge nutzen ein ePA-FdV und die Ombudsstelle den Audit Event Service [IG_Basic].

Hinweis: Die Notwendigkeit eines Protokolleintrag gemäß A_25172* entfällt, wenn ein Protokolleintrag mangels eines befugten Nutzers (kein Bezug des SecureDataStorageKeys möglich) nicht im SecureDataStorage abgelegt werden kann.

Durch die Baseline-Profilierung [PAdES Baseline Profile] wird festgelegt, wie der Signaturzeitpunkt, gemessen als Systemzeit des ePA-Aktensystems, in die Signatur eingebracht wird.

Hinweis: Zugriffe des Versicherten auf die Protokolle des Aktenkontos werden nicht protokolliert.

Neu

Ereignisse und Zugriffe auf die ePA eines Versicherten werden im ePA Aktensystem protokolliert. Die Protokollierung dient der Datenschutzkontrolle für den Versicherten. Der Audit Event Service ist ein FHIR Data Service und ermöglicht dem Versicherten, befugten Vertretern bzw. der Ombudsstelle den Zugriff auf diese Protokollinformationen.

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

Information	Strukturelement
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 Events gemäß [IG_EPABasic#IG-EPA67312T3G] wird durch die jeweiligen Services vorgegeben. Allgemeine Elemente sind wie folgt zu befüllen:

IG-EPA90980V11 - ePA-Aktensystem - Befüllung der Elemente recorded, agent und source eines Audit Events - MUSS
Das ePA-Aktensystem MUSS die Audit Event Elemente AuditEvent.recorded, AuditEvent.agent und AuditEvent.source wie folgt befüllen.

Element [AuditEvent.]		Beschreibung	Beispiel
recorded		Systemzeit bei Erstellung des AuditEvents im Format YYYY-MM-DDThh:mm:ssZ	"2025-01-15T14:52:04.928Z"
purposeOfEvent		Zweck(e) des protokollierten Ereignisses gemäß des zulässigen Value-Sets. Nur zu belegen, wenn explizit bei entsprechender Protokollierungsanforderung gefordert.
	system	Das verwendete Codesystem	"https://gematik.de/fhir/epa/ValueSet/epa-auditevent-purpose-of-event-vs"
	code	Der verwendete Code aus dem Codesystem	"EXPORTFDZ"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"Export für das Forschungsdatenzentrum Gesundheit"
agent[client].type.coding.		Information zum Auslöser des Audit Events gemäß des zulässigen Value-Sets.
	system	Das verwendete Codesystem; Fest vorgegebener Wert: "http://dicom.nema.org/resources/ontology/DCM"	"http://dicom.nema.org/resources/ontology/DCM"
	code	Der verwendete Code aus dem Codesystem; Fest vorgegebener Wert: "110150"	"110150"
	display	Der Bezeichner zur Anzeige aus dem Codesystem; Fest vorgegebener Wert: "Application"	"Application"
agent[client].who.identifier.		Identifikation des Auslösers des Audit Events gemäß der zulässigen Value Sets
	system	Das verwendete Codesystem	"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 UserSession "Elektronische Patientenakte Fachdienst" für intern ausgelöste AuditEvents	"E-Rezept-Fachdienst" "Elektronische Patientenakte Fachdienst" "Portugal" (Beispiel EU-Zugriff)
	requestor	Fest vorgegebener Wert "false"	"false"
agent[user].type.coding.		Information zum Auslöser des Audit Events gemäß des zulässigen Value-Sets.
	system	Das verwendete Codesystem	"http://terminology.hl7.org/CodeSystem/v3-RoleClass"
	code	Der verwendete Code aus dem Codesystem	"PROV"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"healthcare provider"
agent[user].who.identifier.		Identifikation des Auslösers des Audit Events gemäß der zulässigen Value Sets
	system	Das verwendete Codesystem	"https://gematik.de/fhir/sid/telematik-id"
	value	<Telematik-Id> oder <KVNR>	"2-121212121212121" "Z123456789"
agent[user].	altId	<value> aus agent.who.identifier	"2-121212121212121" "Z123456789"
agent[user].role.coding.		Gilt nur für oid = oid_ncpeh: Wert aus SOAP-header des Requests: healthProfessionalRole.
	system	Das verwendete Codesystem	"urn:oid:1.3.6.1.4.1.12559.11.10.1.3.2.2.2"
	code	Der verwendete Code aus dem Codesystem	"Resident Physician"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"Resident Physician"
agent[user].extension		Gilt nur für oid = oid_ncpeh: Wert aus SOAP-header des Requests: healthcareFacilityType; extension mit url="https://gematik.de/fhir/epa/StructureDefinition/epa-healthcare-facility-type-extension"
	system	Das verwendete Codesystem	"urn:oid:2.16.840.1.113883.2.9.6.2.7"
	code	Der verwendete Code aus dem Codesystem	"221"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"Medical Doctors"
agent[user].	name	Gilt nur für oid = oid_ncpeh: Wert aus SOAP-header des Requests: <leiName> / <healthProfessionalName> Andernfalls: <display_name> des auslösenden Akteurs aus dem ID-Token der UserSession	EU-Zugriff: "Dr. Manuel Dos Santos / Clínica de Dos Santos" Andernfalls: "John Doe"
	requestor	Fest vorgegebener Wert "false"	false
agent[internal].type.coding.		Information zum Auslöser des Audit Events gemäß des zulässigen Value-Sets.
	system	Das verwendete Codesystem	"https://gematik.de/fhir/epa/CodeSystem/epa-auditevent-sourcetype-cs"
	code	Der verwendete Code aus dem Codesystem	"DATASUBSVC"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"Data Submission Service"
agent[internal].	altId	Fest vorgegebener Wert "ePA"	"ePA"
	name	Fest vorgegebener Wert "ePA"	"ePA"
	requestor	Fest vorgegebener Wert "false"	"false"
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-Sets.
	system	Das verwendete Codesystem	"https://gematik.de/fhir/epa/ValueSet/epa-auditevent-sourcetype-vs"
	code	Der verwendete Code aus dem Codesystem	"CDMGMT"
	display	Der Bezeichner zur Anzeige aus dem Codesystem	"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 Prozessen, z.B. Datenexport für das FDZ
Aktensystem_ePA [<=]

IG-EPA25373L25 - Protokollierung von nicht erfolgreichen Zugriffen - MUSS
Falls für eine Operation ein Protokolleintrag gefordert ist und mit einem Fehler abgebrochen wird, MUSS der Audit Event Service jeweils einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen. Darüberhinaus und ergänzend zu den Vorgaben aus dem Profil EPAAuditEvent sind folgende Werte entsprechend zu belegen:

Strukturelement	Wert	Erläuterung
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:
entity.detail.type	"search-parameters"
entity.detail.value[x]	<ResourceName>?parameter1=<value>parameter2=<value>& ...mehr

Tabelle: Audit Event Management Protokollierung - Fehler
Falls ein lesender Zugriff ("Read-Operation") durch den Versicherten erfolgt, DARF bei nicht erfolgreichen Zugriffen ein Protokolleintrag NICHT erzeugt werden.

Hinweis: Die Notwendigkeit eines Protokolleintrag gemäß IG-EPA40183ED3* entfällt, wenn ein Protokolleintrag mangels eines befugten Nutzers (kein Bezug des SecureDataStorageKeys möglich) nicht im SecureDataStorage abgelegt werden kann.
Aktensystem_ePA [<=]

IG-EPA08609JKL - ePA-Aktensystem - Aufbewahrungsdauer der Protokolleinträge - MUSS
Das ePa-Aktensystem MUSS die zum Zwecke der Datenschutzkontrolle für den Versicherten erstellten Protokolleinträge für drei Jahre aufbewahren. Danach sind sie vom Aktensystem automatisch zu löschen.
Aktensystem_ePA [<=]

Die Protokolleinträge können durch den Versicherten oder durch einen befugten Vertreter mittels ePA-FdV eingesehen werden. Versicherte ohne ePA-FdV können bei ihrer zuständigen Ombudsstelle beantragen, die Protokolldaten zur Verfügung gestellt zu bekommen.

Für eine Abfrage der Protokolleinträge als strukturierte Einträge nutzen ein ePA-FdV und die Ombudsstelle den Audit Event Service (Query API).

IG-EPA40183ED3 - Audit Event Service - Speicherung der Protokolldaten - MUSS
Der Audit Event Service MUSS die Daten der Protokolleinträge verschlüsselt im SecureDataStorage persistieren.
Aktensystem_ePA [<=]

Hinweis: Die Notwendigkeit eines Protokolleintrag gemäß IG-EPA40183ED3* entfällt, wenn ein Protokolleintrag mangels eines befugten Nutzers (kein Bezug des SecureDataStorageKeys möglich) nicht im SecureDataStorage abgelegt werden kann.

IG-EPA95505YF8 - Audit Event Service - PAdES-Signatur in renderAuditEventsToPDF - MUSS
Der Audit Event Service MUSS bei der Operation renderAuditEventsToPDF beim Signieren eines Protokolls im PDF/A-Format eine PAdES-Signatur gemäß [PAdES-3] und [PAdES Baseline Profile] erstellen. Bei der Signaturerstellung ist das Attribut signing certificate reference gemäß den Vorgaben aus [PAdES-3] Kapitel 4.4.3 "Signing Certificate Reference Attribute" anzulegen.
Aktensystem_ePA [<=]

Durch die Baseline-Profilierung [PAdES Baseline Profile] wird festgelegt, wie der Signaturzeitpunkt, gemessen als Systemzeit des ePA-Aktensystems, in die Signatur eingebracht wird.

IG-EPA72210MBU - Audit Event Service – Protokollierung von Zugriffen auf die Protokolldaten - MUSS
Der Audit Event Service MUSS für die Zugriffe der Ombudsstelle oder eines Vertreters auf die protokollierten Daten jeweils einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen.

Strukturelement	Wert		Erläuterung
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]
parameters	parameter1=<value>&parameter2=<value>& ...mehr	Nur bei getAuditEventList
identifier	<id> des AuditEvents	Nur bei getAuditEvent

Tabelle: Audit Event Service Protokollierung
Hinweis: Zugriffe des Versicherten auf die Protokolle des Aktenkontos werden nicht protokolliert.
Aktensystem_ePA [<=]

2.2 Patient Service

Alt

Neu

IG-EPA95476FRN - Protokolleinträge für Zugriffe auf den Patient Service - MUSS
Der Patient Service MUSS einen Protokolleintrag gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen und dabei folgende Wertebelegung berücksichtigen:

Strukturelement	Wert	Erläuterung
AuditEvent.type	"rest"
AuditEvent.action	U	Update
AuditEvent.entity.name	Patient	Service Name
AuditEvent.entity.description	upsertPatient	operationId der zu ausgeführten Operation

Tabelle: Patient-Service-Protokollierung
EPA-Patient-Service [<=]

3.2.2 Aktenkontoumzug (Health Record Relocation)

Alt

Hinweis: Das Aktensystem des bisherigen Anbieters muss keinen Protokolleintrag gemäß A_24982* erzeugen.

Neu

IG-EPA78949PKT - Health Record Relocation Service - Protokollierung des Anbieterwechsels eines Aktenkontos - MUSS
Der 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-EPA67312T3G] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Strukturelement	Wert		Erläuterung
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
EPA-Health-Record-Relocation-Service [<=]

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

3.11 Constraint Management

Alt

Neu

IG-EPA27775LWU - Constraint Management - Protokolleinträge für Zugriffe auf das Constraint Management - MUSS
Der 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-EPA67312T3G] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Strukturelement	Wert		Erläuterung
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.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"	<XDSDocumentEntry.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"	<XDSFolder.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
EPA-Constraint-Management [<=]

3.8.1 Consent Decision Managent

Alt

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

Ein Aufruf der Operationen der Schnittstelle I_ConsentDecisionManagement zur Änderung der Entscheidungen zur den Widersprüchen gegen die Nutzung von widerspruchsfähigen Funktionen der ePA kann erfolgreich beendet werden, ohne dass eine bisher gespeicherte Entschiedung zu diesen Widerspüchen im Aktensystem geändert wird. In diesem Fall erfolgt die Protokollierung gemäß A_27883-*.

Neu

IG-EPA82173QTJ - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Widersprüchen - MUSS
Das Consent Decision Management MUSS Bei Änderungen von Entscheidungen zu den widerspruchsfähigen Funktionen der ePA jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA67312T3G] erzeugen. Für die Wertebelegung ist [gemSpec_Aktensystem_ePAfueralle#A_23874] zu berücksichtigen und die Protokollstruktur entsprechend zu belegen:

Strukturelement	Wert		Erläuterung
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 - Widersprüche für Funktionen der ePA
EPA-Consent-Decision-Management [<=]

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

---

Alt

Ein Aufruf der Operationen der Schnittstelle I_ConsentDecisionManagement zur Änderung der Entscheidungen zur den Widersprüchen gegen die Verwendung von Daten für Sekundärnutzungszwecke kann erfolgreich beendet werden, ohne dass eine bisher gespeicherte Entschiedung zu diesen Widerspüchen im Aktensystem geändert wird. In diesem Fall erfolgt die Protokollierung gemäß A_27869-*.

Neu

IG-EPA53113MJ4 - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Sekundärnutzungszwecken - MUSS

Das 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-EPA67312T3G] erzeugen.

Strukturelement	Wert		Erläuterung
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 - Widersprüche zu Sekundärnutzungszwecken
EPA-Consent-Decision-Management [<=]

---

Alt

Neu

IG-EPA51779ZXV - Consent Decision Management – Protokollierung geänderter Entscheidungen der User Specific Deny Policy Medication - MUSS
Das Consent Decision Management MUSS für jede Änderung der User Specific Deny Policy Medication einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA67312T3G] erzeugen:

Strukturelement	Wert		Erläuterung
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-Decision-Management-Protokollierung - User Specific Deny Policy Medication
EPA-Consent-Decision-Management [<=]

3.9 Entitlement Management

Alt

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

neu

IG-EPA43183WW1 - Entitlement Management - Protokolleinträge für Zugriffe auf das Entitlement Management - MUSS
Das 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-EPA67312T3G] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Strukturelement	Wert		Erläuterung
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
EPA-Entitlement-Management [<=]

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

3.13.1.13 Protokollierung von Zugriffen auf den XDS Document Service

Alt

Hinweis: In der AuditEvent.entity Struktur sind Dokumente und/oder Folder zu berücksichtigen, die in der zu protokollierenden Operation referenziert werden.

Neu

IG-EPA81505MFF - XDS Document Service - Protokolleinträge für Zugriffe auf den XDS Document Service - MUSS
Der XDS Document Service MUSS für die Operationen

• ProvideAndRegisterDocumentSet-b,
• RetrieveDocumentSet,
• RemoveMetadata,
• RestrictedUpdateDocumentSet,
• RegistryStoredQuery (entfällt, wenn Nutzung durch den Versicherten erfolgt)

Protokolleinträge gemäß [IG_EPABasic#IG-EPA67312T3G] erzeugen und dabei folgende Wertebelegung berücksichtigen:

Strukturelement	Wert		Erläuterung
AuditEvent.type	"document"
AuditEvent.action	C		Für ProvideAndRegisterDocumentSet-b ohne Replace Option
	U		Für ProvideAndRegisterDocumentSet-b mit Replace Option
	U		Für RestrictedUpdateDocumentSet
	R		Für RegistryStoredQuery
	R		Für RetrieveDocumentSet
	D		Für Zugriffe mit RemoveMetadata
AuditEvent.entity.name	"XDS Document Service"		Service Name
AuditEvent.entity.description	<Operation>		ein Wert aus {ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet, RemoveMetadata, RestrictedUpdateDocumentSet, RegistryStoredQuery}
Parameterwerte für die Operationen ProvideAndRegisterDocumentSet-b, RetrieveDocumentSet und RemoveMetadata
AuditEvent.entity.detail	type	value[x]
	"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.
	"DocumentUniqueId"	<Document.uniqueId>	wenn in der entity Struktur ein XDSDocument beschrieben wird
	"DocumentEntry.title"	<DocumentEntry.title>	wenn in der entity Struktur ein XDSDocument beschrieben wird
	"Folder.title"	<Folder.title>	wenn in der entity Struktur ein XDSFolder beschrieben wird
	"Folder.codeList"	<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"
	"Folder.entryUUID"	<Folder.entryUUID>	wenn in der entity Struktur ein XDSFolder beschrieben wird
Parameterwerte für die Operation RegistryStoredQuery der Schnittstellen I_Document_Management und I_Document_Management_Insurant (nur Vertreter)
AuditEvent.entity.detail	type	value[x]
	"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.
Parameterwerte für die Operation RestrictedUpdateDocumentSet
Alle Metadaten, die geändert wurden, sind mit altem und neuem Wert mit den Parameternamen AuditEvent.entity.detail.type und .value[x] zu protokollieren. In [gemSpec_Aktensystem_ePAfueralle#A_15083] sind die Metadaten genannt, die geändert werden können. Der Parameter type ist ein Kompositum aus Objekt (Document) + Attribut in Groß-/Kleinschreibung. Wird das geänderte Metadatum adressiert, wird noch der Präfix "prev" ergänzt. z.B. Metadatum: DocumentEntry.formatCode ->Parameter value type: DocumentFormatCode und prevDocumentFormatCode. Attributunterstrukturen werden ebenfalls in gemischter Groß-/Kleinschreibung zusammengesetzt(z.B. author.Person -> AuthorPerson).

Tabelle: XDS Document Service Protokollierung
EPA-XDS-Document-Service [<=]

Hinweis: In der AuditEvent.entity Struktur sind Dokumente und/oder Folder zu berücksichtigen, die in der zu protokollierenden Operation referenziert werden.

---

Alt

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.

Neu

IG-EPA69832BUU - XDS Document Service - Protokolleinträge für Zugriffe gleicher Art - KANN
Werden 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.
EPA-XDS-Document-Service [<=]

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.

---

Alt

Neu

IG-EPA18290U4U - XDS Document Service - Nicht zu protokollierende Zugriffe - DARF NICHT

Werden 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.
EPA-XDS-Document-Service [<=]

---

Alt

Neu

IG-EPA23889BVZ - XDS Document Service - Nicht zu protokollierende Zugriffe auf Ordner "technical" - DARF NICHT

Der XDS Document Service DARF Zugriffe auf den statischen Ordner "technical" oder dessen Inhalte NICHT protokollieren.
EPA-XDS-Document-Service [<=]

---

Alt

Neu

IG-EPA35053RVM - XDS Document Service - Protokollierung von Nutzerzugriffen auf Ordner "technical" - MUSS

Der 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. EPA-XDS-Document-Service [<=]

3.21.6 Protokollierung

Alt

Hinweis: DisplayNamePusher und DisplayNameDevice können gleich lauten.

Neu

IG-EPA75442S6H - Push Notification Management- Protokollierung der ePA-FdV-Instanz-Registrierung - MUSS

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

Strukturelement	Wert		Erläuterung
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
EPA-Push-Notification-Management [<=]

Hinweis: DisplayNamePusher und DisplayNameDevice können gleich lauten.

---

Alt

Hinweis: Die Speicherung von Protokolleinträgen 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.

Neu

IG-EPA07270W9D - Push Notification Management- Protokollierung von Änderungen der Channel-Konfiguration - MUSS
Das Push Notification Management MUSS für Änderungen der Channel-Konfiguration jeweils einen Protokolleintrag gemäß [gemIG_ePA_Basic#IG-EPA67312T3G] erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Strukturelement	Wert		Erläuterung
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
EPA-Push-Notification-Management [<=]

Hinweis: Die Speicherung von Protokolleinträgen 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.

3.2 gemSpec_ePA_FdV

6.2.8.4 Patient Service

Alt

Neu

Seite "Basisdienst Patient Service" in gemIG_ePA_Basic

IG-EPA73371E2T - ePA-FdV: Schnittstellennutzung des Patient Service - KANN

Das ePA-Frontend des Versicherten KANN die Nutzung der die in diesem Implementation Guide definierte Schnittstelle "Patient Service: Query API" implementieren.
EPA-FdV [<=]

6.2.9 Protokollverwaltung

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA17406TWV - ePA-Frontend des Versicherten: Protokolldaten einsehen - MUSS

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen die Protokolldaten für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung der "Query API: AuditEvent" einzusehen.
EPA-FdV  [<=]

---

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA47641VPS - ePA-Frontend des Versicherten: Protokolldaten filtern - MUSS

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen die Protokolldaten für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung der "Query API: AuditEvent" zu filtern.
EPA-FdV [<=]

---

Alt

Die Protokolldaten sollen für den Nutzer sortierbar und filterbar dargestellt werden. Der Nutzer soll die Protokolldaten durchsuchen können.

Das ePA-Frontend des Versicherten kann Protokolleinträge für einen Nutzer übersichtlich anordnen oder einzelne Felder in der Anzeige ausblenden. Es muss einem Nutzer jedoch ermöglicht werden, alle Protokolleinträge und alle Protokollfelder einzusehen. 

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA50631N8A - ePA-Frontend des Versicherten: Anzeige der Protokolldaten - MUSS

Das ePA-Frontend des Versicherten MUSS für die Anzeige der Protokolleinträge eigene, auch für Nutzer ohne technisches Vorwissen oder spezifisches ePA-Wissen verständliche Beschreibungen anstelle der Inhalte des Protokolleintrages verwenden.
EPA-FdV [<=]

Die Protokolldaten sollen für den Nutzer sortierbar und filterbar dargestellt werden. Der Nutzer soll die Protokolldaten durchsuchen können.

Das ePA-Frontend des Versicherten kann Protokolleinträge für einen Nutzer übersichtlich anordnen oder einzelne Felder in der Anzeige ausblenden. Es muss einem Nutzer jedoch ermöglicht werden, alle Protokolleinträge und alle Protokollfelder einzusehen.

---

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA38734DFC - ePA-Frontend des Versicherten: Protokolldaten lokal speichern - MUSS

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die vom Audit Event Service abgerufenen Protokolldaten lokal zu speichern.
EPA-FdV [<=]

---

Alt

Hinweis: Bei der Verwendung eines Standardformats wie PDF für lokal gespeicherte Protokolldaten gilt weiterhin auch A_15479*, d.h. das ePA-Frontend muss (und darf) es dem Nutzer ermöglichen, ein Standardprogramm zur Anzeige zu verwenden.

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA12774JW3 - ePA-Frontend des Versicherten: lokal gespeicherte Protokolldaten anzeigen - MUSS
Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die lokal abgespeicherten Protokolldaten einzulesen und anzuzeigen. 
EPA-FdV [<=]

Hinweis: Bei der Verwendung eines Standardformats wie PDF für lokal gespeicherte Protokolldaten gilt weiterhin auch [gemSpec_ePA_FdV#A_15479], d.h. das ePA-Frontend muss (und darf) es dem Nutzer ermöglichen, ein Standardprogramm zur Anzeige zu verwenden.

3.3 gemILF_PS_ePA

4.1.1 Einstellen von Daten durch Kostenträger

Alt

Neu

Weitere Anforderungen an das Clientsystem des Kostenträgers sind im FHIR Implementation Guide für den Patient Service [IG_Basic] zu finden.

Seite "Basisdienst Patient Service" in gemIG_ePA_Basic

IG-EPA24512M1L - CS_ePA_KTR: Schnittstellennutzung des Patient Service - MUSS

Das Clientsystem des Kostenträgers MUSS die Nutzung der die in diesem Implementation Guide definierte Schnittstelle "Patient Service: Versicherteninformationen hinzufügen/aktualisieren" implementieren.
CS_ePA_KTR [<=]

4.2.3 Protokolldaten dem Versicherten zur Verfügung stellen

Alt

Neu

Seite "Datenschutz und Sicherheit" in gemIG_ePA_Basic

IG-EPA18143SE6 - CS_ePA_Ombudsstelle: Aufbereitung der Protokolldaten für den Versicherten - MUSS

Das Clientsystem der Ombudsstelle MUSS die Protokolldaten in für den Versicherten lesbarer Form bereitstellen.
CS_ePA_KTR [<=]

4 Zusammenfassung und Übersicht

4.1 Abzukündigende Anforderungen

4.1.1 gemSpec_Aktensystem_ePAfueralle

• A_26252
• A_26253
• A_27667
• A_24704
• A_24714
• A_24750

4.1.2 gemSpec_ePA_FdV

• A_27564
• A_27687

4.1.3 gemILF_PS_ePA

• A_26276
• A_27690
• A_27691
• A_24660
• A_25350
• A_26253

4.2 Zu verschiebende Anforderungen

4.2.1 gemSpec_Aktensystem_ePAfueralle

• A_26254 -> IG-EPA95476FRN
• A_26317 ->  IG-MED72454UMG
• A_24820 -> IG-MED31287N4W
• A_25152 -> IG-MED67431CY7
• A_25153 -> IG-MED29593UZM
• A_26399 -> IG-MED25363BKT
• A_24841 -> IG-MED24600WA1
• A_27894 -> IG-MED29796HBG
• A_24849 -> IG-EPA14908QQV
• A_27188 -> IG-EPA89021CEX
• A_27667 -> IG-MHD96412M8R
• A_27892 -> IG-MHD45146PEW
• A_27668 -> IG-MHD64112RWT
• A_27669 -> IG-EPA29056FPX
• A_27886 -> IG-EPA50964Z2A
• A_28039 -> IG-EPA49593GT2
• A_25154 -> IG-EPA90980V11
• A_27689 -> IG-EPA25373L25
• A_24503 -> IG-EPA08609JKL
• A_25172 -> IG-EPA40183ED3
• A_25018 -> IG-EPA95505YF8
• A_24991 -> IG-EPA72210MBU
• A_26254 -> IG-EPA95476FRN
• A_24982 -> IG-EPA78949PKT
• A_24887 -> IG-EPA27775LWU
• A_24055 -> IG-EPA82173QTJ
• A_26308 -> IG-EPA53113MJ4
• A_26405 -> IG-EPA51779ZXV
• A_24987 -> IG-EPA43183WW1
• A_24715 -> IG-EPA81505MFF
• A_24925 -> IG-EPA69832BUU
• A_25007 -> IG-EPA18290U4U
• A_27253 -> IG-EPA23889BVZ
• A_27254 -> IG-EPA35053RVM
• A_27636 -> IG-EPA75442S6H
• A_27662 -> IG-EPA07270W9D

4.2.2 gemSpec_ePA_FdV

• A_24698 -> IG-EPA17406TWV
• A_24699 -> IG-EPA47641VPS
• A_23547 -> IG-EPA50631N8A
• A_15495 -> IG-EPA38734DFC
• A_15496 -> IG-EPA12774JW3

4.2.3 gemILF_PS_ePA

• A_26275 -> IG-EPA24512M1L
• A_24711 -> IG-EPA18143SE6