Der Audit Event Service der ePA für alle wird innerhalb eines versichertenindividuellen Health Record Context betrieben. Die einzelnen Services im ePA-Aktensystem protokollieren Ereignisse zum Zwecke der Datenschutzkontrolle für den Versicherten. Es werden sämtliche Ereignisse aufgezeichnet, die für diesen Zweck erforderlich sind. Dies umfasst insbesondere:
alle Zugriffe und Zugriffsversuche auf die Daten des Versicherten im XDS Document Service sowie in einem FHIR Data Service (z.B. Medication Service oder Audit Event Service),
das Hinzufügen und Entfernen von Befugnissen im Entitlement Management durch einen Vertreter,
den Benutzerausschluss im Entitlement Management,
Nutzung der Akte des Versicherten im EU Ausland (Entitlement_Management_EU und XDS Docuemnt Service),
alle Änderungen im Consent Management,
alle Änderungen im Constraint_Management_Insurant
den Anbieterwechsel beim Health Record Relocation Service,
Der Versicherte, ein befugter Vertreter sowie die Ombudsstelle müssen anhand des Protokolleintrags nachvollziehen können, welcher Nutzer zu welchem Zeitpunkt welche Aktion durchgeführt hat. Die Informationen im Protokolleintrag sind so gestaltet, dass sie für den Zweck der Datenschutzkontrolle geeignet sind.
Die Protokolleinträge des Audit Event Service werden als FHIR R4 AuditEvent-Instanzen bereitgestellt und können über eine FHIR R4 RESTful API abgerufen werden. Mithilfe der FHIR R4 SearchParams können die Abfragen gefiltert werden.
Schnittstellenimplementierung
Der Audit Event Service MUSS sämtliche Schnittstellen unter den folgenden Pfaden verfügbar machen:
[base]/epa/audit/api/v1/fhir/
[base]/epa/audit/render/v1/pdf
wobei [base] einem gültigen Pfadnamen eines VAU-Kanals nach folgendem Schema entsprechen muss:
http://epa4all
Der Audit Event Service MUSS die in diesem Implementation Guide definierten Schnittstellen (d.h. Query API: AuditEvent und Render API: PDF Audit) implementieren und dabei die Vorgaben der [FHIR-Spezifikation] berücksichtigen.
Der Audit Event Service MUSS – für den Fall, dass sich die Akte im Status INACCESSIBLE befindet – den HTTP Status Code 409 statusMismatch unterstützen.
Der Audit Event Service MUSS die Funktion GET [base]/epa/audit/api/v1/fhir/metadata implementieren. Diese Funktionalität stellt sicher, dass bei einem Aufruf von /metadata das FHIR CapabilityStatement mit dem Namen EPAAuditEventServer des Servers zurückgegeben wird. Dieses Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des ePA Audit Event Service und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten.
Anzeige und Ablage von Protokolldaten in Clients
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 die (Query API) des Audit Event Service, für den Abruf der Protokolleinträge im Format PDF/A (Render API).
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.
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.
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.
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.
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.
Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die vom Audit Event Service abgerufenen Protokolldaten lokal zu speichern.
Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die lokal abgespeicherten Protokolldaten einzulesen und anzuzeigen.
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-FdV muss (und darf) es dem Nutzer ermöglichen, ein Standardprogramm zur Anzeige zu verwenden.
Das Clientsystem der Ombudsstelle MUSS die Protokolldaten in für den Versicherten lesbarer Form bereitstellen.
Sicherheit
Der Audit Event Service MUSS die gesetzlich verbindlichen Regelungen der Zugriffsrechte bzgl. der Berufsgruppen und Datenkategorien aus [gemSpec_Aktensystem_ePAfueralle#Legal Policy] berücksichtigen. Die generelle Ausführung des Audit Event Service ist ausschließlich für ePA-Client-Systeme mit der Nutzergruppe aus der nachstehenden Liste durchzuführen:
professionOID
oid_versicherter
oid_ombudsstelle
Tabelle: Befugbare Nutzergruppen mit Ausführungsrecht für Suche und Herausgabe von Audit Events
Der Audit Event Service MUSS die zum Zwecke der Datenschutzkontrolle für den Versicherten erstellten Protokolleinträge für drei Jahre aufbewahren. Danach sind sie vom Audit Event Service automatisch zu löschen.
Der Audit Event Service MUSS die Daten der Protokolleinträge verschlüsselt im SecureDataStorage persistieren.
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.
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.
Durch die Baseline-Profilierung [PAdES Baseline Profile] wird festgelegt, wie der Signaturzeitpunkt, gemessen als Systemzeit des ePA-Aktensystems, in die Signatur eingebracht wird.