A_24986 - ePA-Aktensystem - Rollentrennung ePA-Aktensystem und IDP-Dienst

Falls der Betreiber des ePA-Aktensystems auch den IDP-Dienst betreibt, MUSS der Betreiber sicherstellen, dass die Erstellung oder Änderungen von IDToken beim IDP-Dienst und die Verarbeitung und Prüfung der Client-Attestation im ePA-Aktensystem durch geeignete technische und organisatorische Maßnahmen so wirkungsvoll voneinander getrennt werden, dass ein einzelner Mitarbeiter des Betreibers nicht beide Aktivitäten durchführen kann. [<=]

A_25149-01 - ePA-Aktensystem - Rollentrennung ePA-Aktensystem und sektoraler IDP

Falls der Betreiber des ePA-Aktensystems auch einen sektoralen IDP betreibt, MUSS der Betreiber sicherstellen, dass die Erstellung oder Änderungen von ID-Token beim sektoralen IDP und die Erstellung oder Änderungen der Mailadresse für die Geräteverwaltung im ePA-Aktensystem durch geeignete technische und organisatorische Maßnahmen so wirkungsvoll voneinander getrennt werden, dass ein einzelner Mitarbeiter des Betreibers nicht die Aktivitäten in beiden Diensten durchführen kann. [<=]

A_24673 - Zeitsynchronisation über Zeitdienst in der TI

Das ePA-Aktensystem MUSS die Systemzeit über den Zeitdienst in der TI gemäß [gemSpec_Net#6.2] synchronisieren
[<=]

A_25612 - ePA-Aktensystem - Authentisierung gegenüber einem Client innerhalb der TI

Das ePA Aktensystem MUSS sich beim Aufruf durch einen Client innerhalb der TI mit der TLS-Identität oid_epa_dvw und Zertifikatsprofil C.FD.TLS-S authentisieren. [<=]

A_24676 - Useragent Information in HTTP Header außerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass  in der Kommunikation mit den ePA-Clients außerhalb des VAU-Kanals ein HTTP Header Element mit dem Namen "x-useragent" gesendet wird und andernfalls den Request mit HTTP-Fehler 400 ablehnen. [<=]

A_24677 - Useragent Information in HTTP Header innerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass in der Kommunikation mit den ePA-Clients innerhalb des VAU-Kanals ein HTTP Header Element mit dem Namen "x-useragent" gesendet wird und andernfalls den Request mit HTTP-Fehler 400 ablehnen. [<=]

A_24592-02 - Anbieter ePA-Aktensystem -Registrierung an übergreifender ePA-Domäne

Der Anbieter des ePA-Aktensystems MUSS seine Hosts und IP-Adressen für Services, die über das zentrale Netz der TI angeboten werden, in der übergreifenden ePA-Domäne epa4all.de für die Sub-Domänen ref (RU1), dev (RU2), test (TU) und prod (PU) unter folgend aufgeführten DNS-Namen (FQDN) registrieren. Diese sind

1. Host und IP-Adressen für den Endpunkt I_Information_Service und der Services in der VAU:
   epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de.
2. Host und IP-Adressen für den Endpunkt I_Information_Service_Accounts:
   epa-asisa-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de.

A_14128-04 - Anbieter ePA-Aktensystem - Resource Records FQDN ePA

Der Anbieter des ePA-Aktensystems MUSS in seinen Nameservern im Internet den FQDN des Aktensystems für das ePA-FdV auflösen.
[<=]

A_22688-03 - Anbieter ePA-Aktensystem, Konfiguration Schnittstellen über /.well-known/

Der Anbieter des ePA-Aktensystems MUSS an seinen Access Gateway des Versicherten über den URL-Pfadnamen (bzw. die Datei) /.well-known/epa-configuration.json eine JSON-Repräsentation aller Pfade zu seinen Komponenten verfügbar machen.
D. h. der Aufrufende (ePA-FdV) MUSS wenn er diesen Pfad per HTTP-GET abfragt ein JSON-Objekt (also Content-Type "application/json") vom Access Gateway des Versicherten erhalten der Art

{
    "version" : "<Produkttypversion des Aktensystems im Format[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}>",
    "sgd1"  : "<pfad_Schlüsselgenerierungsdienst_typ1>",
    "sgd2"  : "<pfad_Schlüsselgenerierungsdienst_typ2>",
    ....
} [<=]

A_22687 - Aktensystem, Konfiguration Schnittstellen über /.well-known/

Das ePA-Aktensystem MUSS sicherstellen, dass dem Anbieter des ePA-Aktensystems die technische Möglichkeit bereitgestellt wird A_22688-* umzusetzen. [<=]

A_17969-06 - Anbieter ePA-Aktensystem - Schnittstellenadressierung

Der Anbieter des ePA-Aktensystems MUSS alle nach außen angebotenen Dienste gemäß der ePA-OpenAPI-Spezifikationen ([I_Information_Service] etc.) an seinen ePA-spezifischen HTTPS-Schnittstellen anbieten (insbesondere mit den in den ePA-OpenAPI-Spezifikationen aufgeführten Pfadnamen). Falls die Operationen innerhalb einer ePA-VAU liegt, so gilt der Pfadname der ePA-OpenAPI-Spezifikation für den inneren HTTP-Request (übertragen innerhalb eines VAU-Kanals).

Ein ePA-Client verwendet, falls die Operation innerhalb einer VAU liegt gemäß [gemSpec_Krypt#A_24428-*] den Pfadnamen /VAU für die Initiierung eines VAU-Kanals. Beim Aufbau des VAU-Kanals gibt das Aktensystem den für den VAU-Kanal weiter zu verwendenden Pfadnamen vor [gemSpec_Krypt#A_24608]. Innerhalb des VAU-Kanals, d. h. für innere HTTP-Request, MÜSSEN die Pfadnamen der ePA-OpenAPI-Spezifikationen umgesetzt werden. Für Schnittstellen, die außerhalb einer VAU liegen, gelten ebenfalls die jeweilige ePA-OpenAPI-Spezifikation mit den dort aufgeführten Pfadnamen. [<=]

A_24801 - Aktensystem, Liste von FQDN im Internet

Das ePA-Aktensystem MUSS dem ePA-FdV eine Liste aller Kostenträger und der FQDN, unter der deren ePA-Aktensystem im Internet erreichbar ist, bereitstellen. Die Liste setzt sich zusammen aus den selbst verwalteten Kostenträgern und den über I_Information_Service_Accounts bezogenen Teillisten der anderen ePA-Aktensysteme. [<=]

A_14921 - Anbieter ePA-Aktensystem - lokale Redundanz im Standort des ePA-Aktensystems

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass bei Ausfall einer oder mehrerer Komponenten des ePA-Aktensystems die verbleibenden Komponenten des ePA-Aktensystems in demselben Standort den Datenverkehr aller Clients der ausgefallenen Komponente zusätzlich übernehmen, die Konsistenz der persistenten Daten erhalten bleibt und die Verfügbarkeit der Komponenten gemäß den geforderten SLAs in [gemSpec_Perf] weiterhin gegeben ist. [<=]

A_15245 - Anbieter ePA-Aktensystem - standortübergreifende Redundanz und Verfügbarkeit

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass bei Ausfall eines Standorts (Rechenzentrum) die Konsistenz der persistenten Daten erhalten bleibt und die Verfügbarkeit der Komponenten gemäß der geforderten SLAs in [gemSpec_Perf] gegeben ist. [<=]

A_24862-03 - Anbieter ePA-Aktensystem – Georedundanz: Verfügbarkeit der Akten innerhalb von fünf Arbeitstagen

Der Betreiber des ePA-Aktensystems MUSS Maßnahmen zur Verfügbarkeit der Akten ergreifen, die sicherstellen, dass bei einem Großereignis, bei dem alle Aktensysteminstanzen ausfallen, die betroffenen Akten innerhalb von fünf Arbeitstagen wieder vollumfänglich für die Versorgung genutzt werden können. Die Maßnahmen zur Erhaltung der Verfügbarkeit des Aktensystems müssen die Sicherheitsanforderungen für das ePA-Aktensystem erfüllen. [<=]

A_15128 - Anbieter ePA-Aktensystem - Schutz der transportierten Daten im ePA-Aktensystem

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die Vertraulichkeit und Integrität der innerhalb des ePA-Aktensystems transportierten Daten gewährleistet ist. [<=]

A_15103 - Anbieter ePA-Aktensystem - Konzept zur Verhinderung von Profilbildung

Der Anbieter des ePA-Aktensystems MUSS ein Konzept erstellen und umsetzen, dass sicherstellt, dass Mitarbeiter des Anbieters die im ePA-Aktensystem verarbeiteten Daten nicht für Profilbildungen über Versicherte oder Leistungserbringer(-institutionen) nutzen können. [<=]

A_25722 - ePA-Aktensystem - Löschen von personenbezogenen Daten von Vertretern nach Wegfall der Notwendigkeit

Das ePA-Aktensystem MUSS die personenbezogenen Daten eines Vertreters löschen, sofern der Vertreter kein Aktenkonto im ePA-Aktensystem besitzt und der Vertreter keine Versicherten im ePA-Aktensystem mehr vertritt. [<=]

A_15104 - Anbieter ePA-Aktensystem - Ordnungsgemäße IT-Administration

Der Anbieter des ePA-Aktensystems MUSS die Maßnahmen für erhöhten Schutzbedarf des BSI-Bausteins „OPS.1.1.2 Ordnungsgemäße IT-Administration“ [BSI-Grundschutz] während des gesamten Betriebs des ePA-Aktensystems umsetzen.    [<=]

A_15824 - Anbieter ePA-Aktensystem - Sichere Speicherung von Daten

Unabhängig davon, ob die Daten schon verschlüsselt vorliegen, MUSS der Anbieter des ePA-Aktensystems  die Daten des ePA-Aktensystems bei der Speicherung verschlüsseln.   [<=]

A_24774 - Anbieter ePA-Aktensystem - Zwei-Faktor-Authentisierung von Administratoren

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass sich Administratoren mindestens mit einer Zwei-Faktor-Authentisierung anmelden. [<=]

A_15107-02 - Anbieter ePA-Aktensystem - Keine unzulässige Weitergabe von Daten

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die in seinem Aktensystem verarbeiteten Daten nicht weitergegeben werden, auch nicht in pseudonymisierter oder anonymisierter Form. Davon ausgenommen sind Weitergaben an berechtigte Nutzer der Aktenkonten, an einen durch den Versicherten gewählten Anbieter beim Anbieterwechsel sowie Übermittlungen an das Forschungsdatenzentrum Gesundheit soweit dagegen kein Widerspruch durch den Versicherten oder einen Vertreter vorliegt. [<=]

A_15119 - Anbieter ePA-Aktensystem - Löschkonzept

Der Anbieter des ePA-Aktensystems MUSS in einem Löschkonzept für die im ePA-Aktensystem verarbeiteten personenbezogenen Daten mindestens folgende Aspekte beschreiben:

• die umgesetzten organisatorischen und technischen Löschmaßnahmen (dies beinhaltet insbesondere auch die Löschung von Backups, Protokollen etc.),
• die Löschregeln und Löschfristen zusammen mit einer nachvollziehbaren Begründung für die getroffenen Fristfestlegungen,
• wie sichergestellt wird, dass alle Auftragnehmer die Löschpflichten ihrerseits umsetzen.

A_15169 - ePA-Aktensystem - Verbot von Werbe- und Usability-Tracking

Die Komponenten des ePA-Aktensystems DÜRFEN im Produktivbetrieb ein Werbe- und Usability-Tracking NICHT verwenden.
Davon ausgenommen ist das Erfassen des standardmäßigen quantitativen Nutzerverhaltens zur Ermittlung der Standard-Aktennutzung entsprechend der Anforderung A_15154. [<=]

A_15154 - Anbieter ePA-Aktensystem - Ermittlung von Standard-Aktennutzung

Der Anbieter des ePA-Aktensystems MUSS mindestens einmal im Jahr Werte zu einer Standard-Aktennutzung von LE und Versicherten durch die Profilierung anonymer Zugriffsstatistiken auf das ePA-Aktensystem zum Zweck der Erkennung von Zugriffen gemäß A_15155 ermitteln. [<=]

A_15155 - Anbieter ePA-Aktensystem - Abweichung von Standard-Aktennutzung

Der Anbieter des ePA-Aktensystems MUSS Zugriffe und Zugriffsmuster, die nicht einer Standard-Aktennutzung entsprechen, erkennen und Maßnahmen zur Schadensreduzierung umsetzen.  [<=]

A_24778 - Anbieter ePA-Aktensystem - Einsatz zertifizierter HSM

Der Anbieter des ePA-Aktensystems MUSS beim Einsatz eines HSM sicherstellen, dass dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage.    
Die Prüftiefe MUSS mindestens 

1. FIPS 140-2 Level 3 oder
2. FIPS 140-3 Level 3 oder  
   
3. Common Criteria EAL 4+ (mit AVA_VAN.5)

A_15157 - Anbieter ePA-Aktensystem - Sicherer Betrieb und Nutzung eines HSMs

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die auf dem HSM verarbeiteten privaten Schlüssel, Konfigurationen und eingesetzte Software nicht unautorisiert ausgelesen, unautorisiert verändert, unautorisiert ersetzt oder in anderer Weise unautorisiert benutzt werden können. [<=]

A_15159 - Anbieter ePA-Aktensystem - Schutzmaßnahmen gegen die OWASP Top 10 Risiken

Der Anbieter des ePA-Aktensystems MUSS in allen Komponenten des ePA-Aktensystems technische Maßnahmen zum Schutz vor den in der aktuellen Version genannten OWASP-Top-10-Risiken umsetzen. [<=]

A_24780 - Anbieter ePA-Aktensystem – Versicherte über sensible Änderungen informieren

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass der Versicherte über Änderungen in den folgenden Anwendungsfällen informiert wird,  

• E-Mail-Adresse ändern,
• Aktenkonto schließen

A_15163 - Anbieter ePA-Aktensystem - Angriffen entgegenwirken

Der Anbieter des ePA-Aktensystems MUSS Maßnahmen zur Erkennung von Angriffen und zur Reduzierung bzw. Verhinderung von Schäden aufgrund von Angriffen in allen Komponenten des ePA-Aktensystems umsetzen. [<=]

A_15167 - Anbieter ePA-Aktensystem - Social Engineering Angriffen entgegenwirken

Der Anbieter des ePA-Aktensystems MUSS Maßnahmen zur Erkennung und Verhinderung von Social Engineering Angriffen umsetzen. [<=]

A_24989 - Anbieter ePA-Aktensystem - Schutz vor Angriffen über die TI

Die Anbieter des ePA-Aktensystems MUSS für alle über die TI erreichbaren Schnittstellen des ePA-Aktensystems Maßnahmen zum Schutz vor DoS-Angriffen auf Anwendungsebene treffen. Weitere Angriffe auf Anwendungsebene MÜSSEN mindestens durch Einsatz geeigneter IDS/IPS Lösungen verhindert werden. [<=]

A_15168 - ePA-Aktensystem - Verbot vom dynamischen Inhalt

Die Komponenten des ePA-Aktensystems DÜRFEN dynamischen Inhalt von Drittanbietern NICHT herunterladen und verwenden. 
[<=]

A_17080 - Verhindern von Session Hijacking

Die Komponenten des ePA-Aktensystems MÜSSEN geeignete Schutzmaßnahmen gegen Session-Hijacking implementieren.
[<=]

A_16323-01 - ePA-Aktensystem - Verbot von medizinisch irrelevantem Inhalt

Der Anbieter des ePA-Aktensystems MUSS der Ablage von Dokumenten, die für die medizinische Versorgung oder für die Eigenorganisation medizinischer Belange des Versicherten oder zur Erstattung der Behandlungskosten irrelevant sind, mittels AGB auf Anbieterseite entgegenwirken.
[<=]

A_24781 - Sicherer Betrieb des Produkts nach Handbuch

Der Anbieter eines ePA-Aktensystems MUSS die im Handbuch des eingesetzten ePA-Aktensystems beschriebenen Voraussetzungen für den sicheren Betrieb des Produktes gewährleisten. [<=]

A_18953 - Darstellen der Voraussetzungen für sicheren Betrieb des Produkts im Handbuch

Der Hersteller des ePA-Aktensystems MUSS für sein Produkt im dazugehörigen Handbuch leicht ersichtlich darstellen, welche Voraussetzungen vom Betreiber und der Betriebsumgebung erfüllt werden müssen, damit ein sicherer Betrieb des Produktes gewährleistet werden kann. [<=]

A_19122-01 - Anbieter ePA-Aktensystem – Trennung zu anderen Mandanten

Ein Betreiber eines ePA-Aktensystems MUSS sicherstellen, dass die Daten von unterschiedlichen Mandanten organisatorisch und technisch getrennt sind.  [<=]

A_21106 - Anbieter ePA-Aktensystem – Signaturschlüssel für Protokolle

Das ePA-Aktensystem MUSS für die Signatur von Listen von Protokollen des Versicherten Schlüsselmaterial der Ausstelleridentität ID.FD.SIG mit einem zugehörigen Zertifikat C.FD.SIG mit der Rolle oid_epa_logging gemäß [gemSpec_OID] besitzen. [<=]

A_21107 - Anbieter ePA-Aktensystem – Speicherung Signaturschlüssel für Protokolle im HSM

Das ePA-Aktensystem MUSS das private Schlüsselmaterial der Ausstelleridentität ID.FD.SIG für die Signatur von Listen von Protokollen des Versicherten in einem HSM speichern.
[<=]

A_22409 - Anbieter ePA-Aktensystem - CA-Anbieterwechsel

Der Anbieter des ePA-Aktensystems MUSS mindestens drei Monate vor dem Wechsel des CA-Anbieters für die Ausstellung der TLS_Zertifikate des Access Gateways die gematik darüber informieren, wer der alte Anbieter war und wer der neue Anbieter wird. [<=]

A_19118-01 - Komponenten des Aktensystems, Schutz vor XSW-Angriffen

Die Komponenten des ePA-Aktensystems, die XML-Signaturen prüfen, MÜSSEN geeignete Maßnahmen gegen XSW-Angriffe umsetzen. Mindestens MÜSSEN sie die FastXPath-Auswertung der XML-Daten und XML-Signaturen gemäß [GJLS-2009] (vgl. auch [BSI-XSpRES]) umsetzen. [<=]

A_24783 - ePA-Aktensystem - Eingabevalidierung von Operationen

Das ePA-Aktensystem MUSS alle Operationsaufrufe seiner Schnittstellen (Requests) sowie die Antwortmeldung auf seine Anfragen (Responses) auf Wohlgeformtheit und Zulässigkeit prüfen und bei Encoding-, Schema-, Semantik- oder Protokollverletzungen die Operation abbrechen. [<=]

A_24992 - ePA-Aktensystem - Zugriffe durch Versicherte übers Access Gateway

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session für einen Versicherten (NutzerID ist KVNR) ausschließlich über das Access Gateway erreichbar ist. [<=]

A_24993 - ePA-Aktensystem - Zugriffe übers Access Gateway ausschließlich für Versicherte

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session für einen Nutzer, dessen NutzerID keine KVNR ist (z.B. Leistungserbringerinstitutionen) nicht über das Access Gateway erreichbar ist. [<=]

A_25006 - ePA-Aktensystem - User Session bei Inaktivität Beenden

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session nach 20 Minuten Inaktivität beendet wird. [<=]

A_25022 - ePA-Aktensystem - Debug-Protokoll für Testbetrieb

Das ePA-Aktensystem KANN im Testbetrieb ein Debug-Protokoll schreiben, welches eine erweiterte Protokollierung für Testzwecke ermöglicht. [<=]

A_25023 - ePA-Aktensystem - Keine Echtdaten im Testbetrieb

Das ePA-Aktensystem MUSS sicherstellen, dass im Testbetrieb keine Echtdaten verarbeitet werden. [<=]

A_25042 - ePA-Aktensystem - Prüfung von Signaturen

Das ePA-Aktensystem MUSS bei der Prüfung von Signaturen

• das Signaturzertifikat gemäß A_25040-* prüfen,
• die Signatur prüfen (i. S. v. Verify()-Funktion des kryptographischen Signaturverfahrens ergibt "valid")

A_25040-01 - ePA-Aktensystem - Prüfung Signaturzertifikate

Das ePA-Aktensystem MUSS Signaturzertifikate gemäß [gemSpec_PKI#TUC_PKI_018] mit folgenden Parametern auf Gültigkeit prüfen:

Tabelle 1: Tab_Prüfung_Signaturzertifikate Parameter Prüfung Signaturzertifikat 

A_18168-01 - Anbieter des ePA-Aktensystem - Validierungsaktenkonto für gematik

Nach Aufforderung durch die gematik MUSS der Anbieter des ePA-Aktensystems

• für die gematik ein Validierungsaktenkonto im ePA-Aktensystem für die von der gematik übergebene KVNR anlegen, wobei die KVNR die Festlegungen für die Versichertennummer [gem. gemSysL_PK_eGK] erfüllen muss.
• das durch die gematik angegebene Validierungsaktenkonto löschen, sofern die gematik dessen Anlage beantragt hatte.

A_18169-02 - Anbieter des ePA-Aktensystem - Validierungsaktenkonto für eigene Zwecke

Falls sich der Anbieter des ePA-Aktensystems ein Validierungsaktenkonto für eigene Zwecke anlegen möchte, MUSS er sicherstellen, dass nur eine Versichertennummer aus dem von der gematik für diesen Anbieter freigegebenen Nummernkreis [gem. gemSysL_PK_eGK] verwendet wird.
[<=]

A_22522-01 - Anbieter des ePA-Aktensystems - Validierungskonto für Dritte

Der Anbieter des ePA-Aktensystems MUSS auf Antrag der gematik

• Validierungsaktenkonten für Dritte (z.B. DVO, PS-Hersteller) für eine vom Antragsteller übermittelte KVNR anlegen, sofern die KVNR die Festlegungen für die Versichertennummer [gem. gemSysL_PK_eGK] erfüllt ist.

• das durch einen Antragsteller angegebene Validierungsaktenkonto löschen, sofern der Antragsteller dessen Anlage beantragt hatte.

A_26187 - Anlage von Validierungsaktenkonten

Das Aktensystem MUSS die Anlage von Validierungsaktenkonten auch ohne KTR- und Ombudsstellen-Befugnisse zulassen. [<=]

A_26188 - Anbieter des ePA-Aktensystems -Aktivierung von Validierungsaktenkonten

Der Anbieter des ePA-Aktensystems MUSS den Status von Validierungsaktenkonten, welche für die gematik (gem. A_18168-*) oder für Dritte (gem. A_22522-*) angelegt wurden, nach der Anlage auf ACTIVATED setzen. [<=]

A_22524-01 - Anbieter des ePA-Aktensystems - Löschen von Validierungsaktenkonten nach 5 Jahren

Der Anbieter des ePA-Aktensystems MUSS ein Validierungsaktenkonto spätestens fünf Jahre nach Anlage des Validierungsaktenkontos, frühestens jedoch nach Ablauf der Gültigkeit der dazugehörigen Prüf-eGK, löschen. [<=]

A_22684-01 - Validierungsaktenkonten im Store-Review der FdVs

Der Anbieter/Hersteller des ePA-Aktensystems bzw. Hersteller des ePA-FdVs KANN - ausschließlich für dedizierte KVNRn von Validierungsaktenkonten zum Zwecke der Verwendung im Store-Review der FdVs – Vorkehrungen treffen, die es ermöglichen auf Gerätebindung, E-Mail-Validierung oder andere Aktivitäten des Registrierungs-/Anmeldeprozesses zu verzichten, um eine Prüfung der FdVs durch die App-Store-Betreiber zu ermöglichen.  [<=]

A_22942 - Besonderheiten bei Validierungaktenkonten für StoreReviews

Bei Validierungsaktenkonten, für die die Regelung gem. A_22684-* gilt [Validierungsaktenkonten im StoreReview der FdVs], MÜSSEN folgende Besonderheiten berücksichtigt werden:

• die entsprechenden Validierungsaktenkonten dürfen nur für den Zeitpunkt des Reviews aktiviert und erreichbar sein,
• die entsprechenden Validierungsaktenkonten sind unmittelbar nach dem Review zu leeren,
• es sind Zeitraum der Erreichbarkeit und eine eindeutige Referenz auf den Review (z.B. Vorgangsnummer) zu dokumentieren und auf Anforderung an die gematik zu übertragen

A_24539 - Nutzung von Validierungsaktenkonten via FdV

Der Anbieter des ePA-Aktensystems bzw. Hersteller des ePA-FdVs MUSS ein FdV bereitstellen, mit dem der Zugriff auf Validierungsaktenkonten möglich ist. [<=]

A_26209 - Prüfung auf Vertretungsberechtigung für Prüfidentität

Das Aktensystem MUSS sicherstellen, dass bei der Vertreterbefugnis ausschließlich "echte" Vertreter für "echte" Konten befugt, bzw. auf Validierungsaktenkonten ausschließlich "Validierungs-Vertreter" eingerichtet werden können. [<=]

A_21887-01 - Tracing, Sensorpunkt nahe vor den VAU-Instanzen (Nichtproduktivumgebungen)

Ein Aktensystem MUSS sicherstellen, dass genau in Nichtproduktivumgebungen der Datenverkehr zur und von den VAU-Instanzen auf TCP-Ebene mitgeschnitten wird (Sensorpunkt). Der aktuell mitgeschnittene Datenverkehr MUSS auf einen TCP-Port im Access Gateway gestreamt werden (siehe A_21890-*). D. h. wenn ein Client sich zu diesem TCP-Port verbindet, MUSS er die aktuell auf dem Interface durchlaufenden Daten gestreamt lesen können.
[<=]

A_21891-01 - Tracing, Tiger-Standalone-Proxy

Ein Aktensystem MUSS zum Mitschneiden und Streamen der Testdaten in Nichtproduktivumgebungen nach A_21887-* den von der gematik bereitgestellten aggregierenden Tiger-Standalone-Proxy (mindestens der Version 0.20) verwenden. [<=]

A_22581 - Tracing, Abschaltbarkeit

Ein Aktensystem MUSS den Tiger-Standalone-Proxy (und die damit verbunden Sensorpunkte) gemäß A_21891-* im Rahmen der Zulassungstests auf Wunsch der gematik aktivieren und insbesondere deaktivieren können. [<=]

A_15842 - Anbieter ePA-Aktensystem - Ergonomie der Benutzerführung

Der Anbieter des ePA-Aktensystems MUSS eine ergonomisch gestaltete Benutzerführung nach den Vorgaben zur Ergonomie in [DIN EN ISO 9241-171] anbieten. [<=]

A_15846 - Anbieter ePA-Aktensystem - Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit

Der Anbieter des ePA-Aktensystems SOLL die Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit, welche vom Betriebssystem zur Verfügung gestellt werden, unterstützen. [<=]

A_22470-05 - Definition Useragent

Das Produkt MUSS für das UserAgent-Element in Eingangs- oder Ausgangsparametern einer Operation folgende Formatvorgaben berücksichtigen:

• der Useragent umfasst 2 Informationen, welche als 1 String - getrennt durch "/" (Slash) - im Header übertragen werden
• erster Teil: ClientID = ein bis zu 20 Zeichen langer String (a-z A-Z 0-9, "-"), welcher im Rahmen der Produktregistrierung bei der gematik erzeugt wird,
• zweiter Teil: Versionsnummer = bis zu 15 Zeichen langer String (a-z A-Z 0-9, "-", ".") welcher die aktuelle Produktversion des Clients repräsentiert.

A_24995 - Migration: Sicherheitskonzept für Datenmigration

Der Hersteller des ePA-Aktensystems MUSS ein Sicherheitskonzept zur Datenmigration erstellen, in welchem er beschreibt, mit welchen Maßnahmen die zu migrierenden Daten im gesamten Datenmigrationsprozess geschützt werden. [<=]

A_25000 - Migration: Stärke der Sicherheitsmaßnahmen für Datenmigration

Das ePA-Aktensystem MUSS sicherstellen, dass die zu migrierenden Daten im gesamten Datenmigrationsprozess mit technischen Maßnahmen geschützt werden, die auch gegen einzelne Innentäter beim Betreiber des ePA-Aktensystems wirken. [<=]

A_25049 - Migration: Migrationskonzept

Der Anbieter des ePA-Aktensystems MUSS ein Migrationskonzept erstellen, welches sowohl die Aktensystemmigration, als auch die Datenmigration, mitsamt der Bereitstellungs- und ggf. Außerbetriebnahme-Zeitpunkte der benötigten Komponenten berücksichtigt. Das Migrationskonzept MUSS dabei auch aufzeigen, welche Abhängigkeiten zu anderen TI-Diensten bestehen, wann und in welchem Umfang die Migration getestet wird und wie eventuelle Roll-Back-Szenarios aussehen.
[<=]

A_25148 - Migration: Information des Versicherten

Der Anbieter des ePA-Aktensystems MUSS den Versicherten über die Notwendigkeit und die Folgen einer Migration vor der eigentlichen Migration informieren, insbesondere darüber, welche Dokumentenformate und welche Berechtigungen übernommen und welche nicht übernommen werden, über die Freiwilligkeit einer Migration. [<=]

A_24922 - Migration: Schnittstellen zur Durchführung der Migration

Das ePA-Aktensystem MUSS für jedes Aktenkonto eine Migration von ePA 2.6 auf ePA 3.0 durchführen und geeignete Schnittstellen zum FdV anbieten, mit denen der Versicherte vom FdV das Entschlüsseln der verschlüsselten ePA 2.6-Akteninhalte anstoßen kann.  [<=]

A_24964 - XDS Document Service - Migration: Isolation der Migration

Der XDS Document Service MUSS die Verarbeitung von entschlüsselten Dokumenten, die im Rahmen der Migration durchgeführt werden, so technisch isolieren, dass kein Schaden für Aktenkonten oder das ePA-Aktensystem selbst entsteht. [<=]

A_25730 - XDS Document Service - Konvertierung von PDF in PDF/A bei der Datenmigration

Der XDS Document Service MUSS die Konvertierung von entschlüsselten PDF-Dokumenten in PDF/A-Dokumente, die im Rahmen der Migration durchgeführt wird, in einer Aktenkontoverwaltungs-VAU oder in einer getrennten VAU-Instanz durchführen, wobei

• die Konvertierung innerhalb der Aktenkontoverwaltungs-VAU ausschließlich für die Datenmigration von ePA2.6 auf die ePA3.0 verwendet werden darf und
  
• es bei einer getrennten VAU-Instanz eine 1:1-Beziehung zur Aktenkontoverwaltungs-VAU geben muss (d.h. die getrennte VAU-Instanz zur Konvertierung ist nur mit einer (1) Aktenkontoverwaltungs-VAU verbunden und eine Aktenkontoverwaltungs-VAU nur mit einer (1) VAU-Instanz für die Konvertierung) und die getrennte VAU-Instanz für die Konvertierung ausschließlich für die Datenmigration von ePA2.6 auf die ePA3.0 verwendet werden darf.

A_25002 - XDS Document Service - Migration: Umbenennung von Ordnern

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 in den Werten von Folder.codeList die mit ePA 3.0 gegebenenfalls geänderten Kategoriennamen als Werte verwenden.  [<=]

A_24562 - XDS Document Service - Migration: Auflösung abgekündigter Ordner

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 die abgekündigten Kategorien auflösen. Dabei MÜSSEN sämtliche Dokumente gemäß der Einordnungsregeln in A_19388-* neu Ordnern zugeordnet werden und die Ordner der abgekündigten Kategorien gelöscht werden. [<=]

A_24963 - XDS Document Service - Migration: Keine Übernahme von Dokumenten mit unzulässigem Format

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 sämtliche Dokumente der ePA2.6 gemäß A_24864-* auf die zulässigen Dokumentenformate prüfen und Dokumente in einem nicht erlaubten Format nicht in die "ePA für alle" migrieren. [<=]

A_24966 - XDS Document Service - Migration: Konvertieren von PDF- in PDF/A-Dokumente

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 Dokumente im PDF-Format in ein PDF/A-Format konvertieren und ausschließlich das Dokument im PDF/A-Format in das Aktenkonto übernehmen. [<=]

A_25032 - XDS Document Service - Migration: Information des Versicherten zur Nichtübernahme von Dokumenten in bestimmten Formaten

Der Anbieter des ePA-Aktensystems MUSS den Versicherten darüber informieren, das Dokumente in der ePA2.6, die ein bestimmtes Format besitzen, nicht in die "ePA für alle" übernommen werden und informieren, um welche Formate es sich handelt. [<=]

A_24520 - XDS Document Service - Migration: Prüfsumme Dokument erzeugen

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 für jedes Dokument, das im Klartext vorliegt, die kryptographische Prüfsumme des Dokumentes berechnen und in DocumentEntry.hash hinterlegen. Dabei MUSS SHA-256 verwendet werden. Außerdem MUSS die Dokumentengröße für das Feld DocumentEntry.size berechnet und gesetzt werden.  [<=]

A_24847 - XDS Document Service - Migration: Identifizieren und Auflösen von Dokumenten-Dubletten

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 zum Zeitpunkt der Entschlüsselung eine Dublettenerkennung durchführen. Dabei werden entschlüsselte Dokumente innerhalb und außerhalb von Sammlungen verglichen mit Dokumenten, die durch eine zwischenzeitliche Nutzung von ePA für alle in die Akte eingestellt worden sind. Dubletten werden anhand der Gleichheit des Hash-Wertes im Feld documentEntry.hash identifiziert. Das Dokument mit dem älteren Einstelldatum wird verworfen. [<=]

A_24851 - XDS Document Service - Migration: Dokumente und Ordner mergen

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 zum Zeitpunkt der Entschlüsselung des Datenbestands die Ordnerinhalte einer Kategorie vergleichen, falls es neben den migrierten ePA 2.6-Akteninhalten durch eine ePA3-Aktennutzung ebenfalls Ordnerinhalte gibt. Unter Berücksichtigung der Dublettenprüfung werden alle Dokumente von zwei Ordnern derselben Kategorie (in ePA 2.6 bzw. 3.0 entstanden) in einen Ordner zusammengeführt. Dokumente und RPLC-Ketten, die durch die documentEntry.uniqueId erkennbar zusammen gehören, werden unter Wahrung der Abfolge der Einstelldaten zusammengeführt und das jüngste Dokument als aktives Dokument der Kette behandelt. Dokumente erhalten eine rootDocumentUniqueId gemäß A_24451-*, falls noch nicht vorhanden.  [<=]

A_24848 - XDS Document Service - Migration: Auflösung von duplizierten dynamischen Ordnern

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 anhand des Titels dynamischer Ordner erkennen, ob zwei dynamische Ordner zur selben Kategorie vorliegen, z.B. zur selben Schwangerschaft. In diesem Falle werden alle vorhandenen Einträge in einen der Ordner hinein gemergt und der andere Ordner gelöscht.
[<=]

A_24522 - XDS Document Service - Migration: Erzeugen von Titeln für Dokumente

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 sicherstellen, dass bei jedem Dokument das Metadatum DocumentEntry.title belegt ist. documentEntry.title=" " oder "" ist gleichbedeutend mit einem nicht vorhandenen Titel. Wenn title nicht belegt ist, MUSS title gemäß folgender Tabelle belegt werden. 

A_24523 - XDS Document Service - Migration: Löschen von ConfidentialityCodes

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 Dokumente und Ordner mit dem confidentialityCode "very restricted" auf die GeneralDenyPolicy setzen. Danach werden die confidentialityCodes gelöscht.   [<=]

A_24817 - XDS Document Service - Migration: Normalisieren und Validieren der URI

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 die ePA 3.0 für sämtliche Dokumente die documentEntry.URI gemäß A_24524-* und A_23447-* normalisieren und validieren. [<=]

A_24866 - Audit Event Service - Migration: Übernahme von Protokolldaten

Der Audit Event Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 sämtliche Protokolldaten des Versicherten in die migrierte Akte übernehmen. Für die Migration werden alte Protokolldaten in ein PDF/A überführt und in die Kategorie "patient" eingestellt. [<=]

A_25029 - XDS Document Service - Protokollierung der Migration der medizinischen Daten

Der XDS Document Service MUSS den Vorgang der Migration der medizinischen Daten (Dokumente, Folder, Metadaten) gemäß A_24704* protokollieren. Dabei ist die Migration als atomares Ereignis zu betrachten und mit einem Protokolleintrag zu dokumentieren. Für den Protokolleintrag ist folgende Wertebelegung zu berücksichtigen:

Tabelle 2: Protokollierung der Migration der medizinischen Daten

A_25031 - Audit Event Service - Protokollierung der Migration der Protokolldaten des Versicherten

Der Audit Event Service MUSS den Vorgang der Migration der Protokolldaten des Versicherten gemäß A_24704* protokollieren.
Dabei ist die Migration als atomares Ereignis zu betrachten und mit einem Protokolleintrag zu dokumentieren.
Für den Protokolleintrag ist folgende Wertebelegung zu berücksichtigen:

Tabelle 3: Protokollierung der Migration der Protokolldaten des Versicherten

A_24570-01 - Verarbeitung von UX-Messdaten

Das Aktensystem MUSS für die im zu betrachtenden Zeitintervall der Rohdatenlieferung (gemäß [gemSpec_Perf]) eingegangenen Messdaten je UX-Usecase, je ClientID und je Client-Version folgende Werte ermitteln und gemäß [gemSpec_Perf] übermitteln:
- Durchschnittswert der Messergebnisse
- Anzahl der berücksichtigten Messergebnisse
- Maximalwert
- Minimalwert [<=]

A_23886 - Anbieter ePA-Aktensystem - Keine Aktenkontoanlage bei Widerspruch des Versicherten

Der Anbieter des ePA-Aktensystems DARF ein Aktenkonto für den Versicherten NICHT anlegen, wenn ein Widerspruch des Versicherten gegen die Nutzung der elektronischen Patientenakte vorliegt. [<=]

A_25181 - Anbieter ePA-Aktensystem - Aktenkontoanlage bei Zurücknahme des Widerspruchs des Versicherten

Falls ein Versicherter den Widerspruch gegen die grundsätzliche Nutzung der ePA zurücknimmt MUSS der Anbieter des ePA-Aktensystems ein Aktenkonto für den Versicherten unverzüglich anlegen. [<=]

A_24980 - Aktenkontoverwaltung – Protokollierung des Aktenkontostatus

Die Aktenkontoverwaltung MUSS bei Änderungen des Status eines Aktenkontos jeweils einen Protokolleintrag gemäß A_24704* erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 5: Protokollierung von Änderungen des Aktenkontostatus

A_24336 - Anbieter ePA-Aktensystem - Identifizerung eines Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS bei der Anlage eines neuen Aktenkontos die KVNR des Versicherten zur Identifikation des Aktenkontos im Aktensystem verwenden und sicherstellen, dass diese Identifikation eines Aktenkontos nicht verändert werden kann. [<=]

A_24302 - Anbieter ePA-Aktensystem - verpflichtende Nutzung von startRelocation

Der Anbieter des ePA-Aktensystems MUSS bei der Anlage eines neuen Aktenkontos durch Verwendung der Operation startRelocation gemäß [I_Information_Service_Accounts] auf Existenz eines Aktenkontos des Versicherten bei allen anderen Anbietern prüfen. [<=]

A_24790 - Anbieter ePA-Aktensystem - keine unbegründete Nutzung von startRelocation

Der Anbieter des ePA-Aktensystems DARF die Operation startRelocation gemäß [I_Information_Service_Accounts] für Zwecke abweichend der Vorgaben in A_24302* NICHT nutzen. [<=]

A_24789 - Anbieter ePA-Aktensystem - verpflichtender Import eines existierenden Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS die Inhalte eines existierenden Aktenkontos in ein neues, initialisiertes Aktenkonto vor dessen Aktivierung übernehmen. [<=]

A_15870-01 - Anbieter ePA-Aktensystem - Abbruch bei Nichtverfügbarkeit anderer Anbieter

Der Anbieter des ePA-Aktensystems MUSS die Erstellung eines Aktenkontos abbrechen, wenn die Operation startRelocation gemäß [I_Information_Service_Accounts] mindestens bei einem anderen Anbieters eines ePA-Aktensystems eine technische Fehlermeldung liefert oder dieser nicht erreichbar ist. [<=]

A_23775 - Anbieter ePA-Aktensystem - Neues Aktenkonto anlegen

Der Anbieter des ePA-Aktensystems MUSS für Versicherte jeweils ein Aktenkonto anlegen, wenn kein Widerspruch des Versicherten gegen die Nutzung der ePA vorliegt, und dabei die KVNR des Versicherten zur Identifikation eines Aktenkontos im Aktenkonto registrieren. Das initialisierte Aktenkonto MUSS den Status INITIALIZED erhalten. [<=]

A_14996-01 - Anbieter ePA-Aktensystem - Manuelle Ergänzung E-Mail-Adresse

Der Anbieter des ePA-Aktensystems MUSS es dem Versicherten auf geeignetem Weg ermöglichen, die Registrierung einer E-Mail-Adresse für die Geräteverwaltung auch nachträglich vorzunehmen. [<=]

A_14993-02 - Anbieter ePA-Aktensystem - Mailadresse validieren

Der Anbieter des ePA-Aktensystems MUSS eine Mailadresse

• bei der ersten Hinterlegung im Aktensystem,
• bei einer Änderung der Mailadresse

A_24369 - Anbieter ePA-Aktensystem - Initialisierung des Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS die Initialisierung der Bestandteile

• Consent Decision Management (initiale Entscheidungen)
• Constraint Management (Policies)
• Entitlement Management (initiale Befugnisse und Befugnisausschlüsse)
• Information Service (initiale Entscheidungen "Versorgungsprozess")
• XDS Document Service (statische Aktenkontoinhalte)
• Device Management 
• Authorization Service
• Audit Event Service
• Medication Service

A_26005 - ePA-Aktensystem – Optionale Schnittstelle zum Einbringen von initialen Befugnissen

Das ePA-Aktensystem KANN eine Schnittstelle für Kostenträger anbieten, über die Kostenträger die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle ins ePA-Aktensystem einbringen können. [<=]

A_26006 - ePA-Aktensystem – Nutzen der optionalen Schnittstelle zum Einbringen von initialen Befugnissen ausschließlich im Status INITIALIZED

Falls das ePA-Aktensystem eine Schnittstelle für Kostenträger anbietet, über die Kostenträger die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle für ein Aktenkonto einbringen können, MUSS das ePA-Aktensystem sicherstellen, dass diese Schnittstelle ausschließlich genutzt werden kann, wenn sich das Aktenkonto im Status INITIALIZED befindet.
[<=]

A_24335 - Anbieter ePA-Aktensystem - Neues Aktenkonto aktivieren

Der Anbieter des ePA-Aktensystems MUSS ein neues Aktenkonto nach Abschluss der Initialisierung aktivieren (Status ACTIVATED), wenn die gesetzliche Widerspruchsfrist abgelaufen ist. [<=]

A_25289 - Anbieter ePA-Aktensystem - Löschen des Aktenkontos durch den Kostenträger

Der Anbieter des ePA-Aktensystems MUSS das Aktenkonto eines Versicherten inklusive aller enthaltenen Daten löschen (sämtliche Dokumente, Schlüsselmaterial, Protokolle, Widerspruchsinformation, Befugnisse und Beschränkungen), wenn dies durch den zuständigen Kostenträger beauftragt wird. [<=]

A_24786 - Health Record Relocation Service - Realisierung der Schnittstelle I_Health_Record_Relocation_Service

Der Health Record Relocation Service MUSS die Operationen der Schnittstelle I_Health_Record_Relocation_Service gemäß [I_Health_Record_Relocation_Service] umsetzen. [<=]

A_24821 - Health Record Relocation Service - Suspendierung des Aktenkontos

Der Health Record Relocation Service MUSS sicherstellen, dass das Aktenkontos für die Erstellung eines Exportpakets auf den Status SUSPENDED gesetzt wird. [<=]

A_24827 - Health Record Relocation Service - Reaktivierung des Aktenkontos

Der Health Record Relocation Service MUSS sicherstellen, dass ein Aktenkonto im Status SUSPENDED nach einem Abbruch eines Transfers von einem Anbieter zu einem anderen Anbieter aufgrund eines Fehlers (Datenübertrag ist nicht erfolgt) in den Status ACTIVATED gesetzt wird. [<=]

A_25005-01 - Health Record Relocation Service - Daten des Exportpakets

Der Health Record Relocation Service MUSS sicherstellen, dass alle Daten des Aktenkontos in das Exportpaket übernommen werden aus:

• XDS Document Service
• Medication Service
• Consent Management
• Constraint Management
• Audit Event Service
• Entitlement Management (außer Befugnisse für Versicherter, E-Rezept-Fachdienst, Kostenträger und Ombudsstelle).
• E-Mail Management (die E-Mail-Adresse des Aktenkontoinhabers (falls vorhanden) sowie für alle Vertreter die E-Mail-Adressen, sofern sie die dem exportierenden Aktensystem bekannt sind).
  

A_25605 - Health_Record_Relocation_Service - Erstellung des Exportpakets

Der Health Record Relocation Service MUSS sicherstellen, dass das Exportpaket gemäß der Vorgaben in [HealthRecordMigration] bezüglich der Struktur, der Formate für die enthaltenen Daten und die Verschlüsselung erfolgt.  [<=]

A_25012 - Health Record Relocation Service - Signatur der Befugnisse

Der Health Record Relocation Service MUSS sicherstellen, dass die gemäß A_23734-* signierten Anteile einer Befugnis mit der Signaturidentität ID.FD.SIG (Rolle oid_epa_vau) signiert werden. [<=]

A_25719 - Health Record Relocation Service - JWT der Befugnis im Exportpaket

Der Health Record Relocation Service MUSS sicherstellen, dass die Befugnisse im Exportpaket als gültig signierte JWT mit den dargestellten Inhalten abgelegt sind:

A_24787-01 - Health Record Relocation Service - Verschlüsselung des Exportpaktes

Der Health Record Relocation Service MUSS sicherstellen, dass Exportpakete ausschließlich verschlüsselt für den Download zu einem anderen Betreiber zur Verfügung stehen. Für die Verschlüsselung MUSS das kryptographische Material des ENC-Zertifikats verwendet werden, welches mittels der Regel hsm-r7 vom VAU-HSM abgerufen wurde. [<=]

A_24942 - Health Record Relocation Service – Prüfung Provider ENC Zertifikat

Der Health Record Relocation Service MUSS das übergebene Provider ENC-Zertifikat mittels TUC_PKI_018 (OCSP-Graceperiod=12h, PolicyList= oid_fd_enc, professionOID = oid_epa_vau ) prüfen und ungültige Zertifikate mit der Fehlermeldung " CERTICATE_INVALID " ablehnen. [<=]

A_21750 - Health Record Relocation Service – Integritätsschutz Exportpaket

Der Health Record Relocation Service MUSS das erstellte Exportpaket mit einem "Digest" HTTP Response Header (https://tools.ietf.org/html/rfc5843) als Integritätsschutz  versehen und dabei als Digest Algorithmus SHA-256 verwenden.
Beispiel Digest-Header:
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
[<=]

A_15051 - Health Record Relocation Service - Authentisierung gegenüber einem neuen Aktenanbieter

Der Health Record Relocation Service, welcher das Exportpaket zur Verfügung stellt, MUSS sich beim Abruf des Exportpakets durch ein anderes ePA-Aktensystem mit der TLS-Identität oid_epa_mgmt und Zertifikatsprofil C.FD.TLS-S authentisieren.
[<=]

A_15048 - Health Record Relocation Service - Authentifizierung des neuen Aktenanbieters

Der Health Record Relocation Service MUSS den Abruf des Exportpakets durch ein anderes ePA-Aktensystem ablehnen, wenn sich der abrufende Client nicht als ePA-Aktensystem in der Rolle oid_epa_mgmt in einem TLS-Zertifikat C.FD.TLS-C authentisiert. [<=]

A_17236 - Health Record Relocation Service - Prüfung der TLS-Zertifikate

Der Health Record Relocation Service MUSS bei der Authentifizierung eines anderen Aktensystems beim Abruf des Exportpakets die Prüfung der verwendeten TLS-Zertifikate entsprechend TUC_PKI_018 durchführen. Zur Prüfung des TLS-Zertifikats C.FD-TLS-S sind dabei die Parameter PolicyList=oid_fd_tls_s, IntendedKeyUsage=digitalSignature, intendedExtendedKeyUsage=id-kp-serverAuth, OCSP-Graceperiod=60 Minuten, Offline-Modus=nein zu verwenden. Zur Prüfung des TLS-Zertifikats C.FD-TLS-C sind dabei die Parameter PolicyList=oid_fd_tls_c, IntendedKeyUsage=digitalSignature, intendedExtendedKeyUsage=id-kp-clientAuth, OCSP-Graceperiod=60 Minuten, Offline-Modus=nein  zu verwenden.
[<=]

A_15703 - Health Record Relocation Service - Verfügbarkeit Export-Paket

Der Health Record Relocation Service MUSS ein erstelltes Export-Paket für maximal sieben Kalendertage zum Abruf durch einen anderen Anbieter eines ePA-Aktensystems bereithalten. [<=]

A_21239 - Health Record Relocation Service – Verhalten bei Nichtabholen des Exportpakets

Der Health Record Relocation Service MUSS nach Ablauf des Bereithaltungszeitraums entsprechend A_15703* ein erstelltes Export-Paket löschen und den Status des Aktensystems von  SUSPENDED auf ACTIVATED zurücksetzen. [<=]

A_14905-04 - Health Record Relocation Service – Import des Exportpakets des vorhergehenden Aktenkontos

Der Health Record Relocation Service MUSS das vom vorhergehenden Anbieter ePA-Aktensystem des Versicherten bezogene Exportpaket, in das neue Aktenkonto importieren und dazu:

• das Exportpaket mittels des privaten ENC-VAU-Schlüssels des neuen Betreibers entschlüsseln,
• den Digest gemäß A_21750-* prüfen,
• die Befugnisse mit Regel "rr5" (siehe Tab_AS_Entitlement_Registration_Rules im Aktensystem) registrieren und
• falls DocumentEntry.originalURI im Exportpaket vorhanden ist, wird für jedes Dokument eines SubmissionSet der Inhalt von DocumentEntry.URI durch den Inhalt von DocumentEntry.originalURI ersetzt. (Hinweis: DocumentEntry.originalURI darf nicht als eigenständiges Metadatum in die Registry übernommen werden, da es lediglich dem Transport des Originalwertes von DocumentEntry.URI aus dem alten Aktensystem dient.

A_21548-01 - Health Record Relocation Service - Information der Vertreter über neuen FQDN nach Abschluss des Anbieterwechsels

Der Health Record Relocation Service MUSS sicherstellen, dass alle Vertreter nach erfolgreichem Import des Exportpakets und somit Abschluss des Anbieterwechsels über Anbieterwechsel und den FQDN des neuen Aktensystems des Versicherten informiert werden, so dass sie in der Lage sind, die erforderliche initiale Anmeldung und Geräteregistrierung durchzuführen und informiert sind, welche Art von personenbezogenen Daten vom Vertreter im Rahmen der Vertreterberechtigung im ePA-Aktensystem verarbeitet werden, wie der Vertreter eine Vertreterberechtigung widerrufen kann und gegenüber wem er seine datenschutzrechtlichen Betroffenenrechte wahrnehmen kann. [<=]

A_26257 - Health Record Relocation Service - Löschen der im Exportpaket enthaltenen E-Mail-Adressen der Vertreter

Der Health Record Relocation Service MUSS sicherstellen, dass die im Exportpaket enthaltenen E-Mail-Adressen von Vertretern ausschließlich zur Information der Vertreter gemäß A_21548-* genutzt werden und nach Abschluss des Anbieterwechsels im importierenden Aktensystem gelöscht werden, d.h. nicht im importierenden Aktensystem gespeichert werden. [<=]

A_24788 - Health Record Relocation Service - Löschen des Exportpakets nach Umzug des Aktenkontos

Das Aktensystem MUSS sicherstellen, dass ein vorhandenes Exportpaket nach einem erfolgreichen Transfer eines Aktenkontos eines Versicherten von einem Anbieter zu einem anderen Anbieter gelöscht wird. [<=]

A_24982 - Health Record Relocation Service – Protokollierung des Anbieterwechsels eines Aktenkontos

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äß A_24704* erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 6 : Health Record Relocation Service Protokollierung

A_24611-02 - ePA-Aktensystem - Im VAU-HSM gespeicherte Schlüssel und Informationen für VAU-Betrieb

Das ePA-Aktensystem MUSS sicherstellen, dass folgende, für den Betrieb der VAU notwendigen Schlüssel und Informationen in einem HSM (als VAU-HSM bezeichnet) gespeichert werden:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU (u.a. genutzt für die Authentisierung der VAU beim Aufbau des VAU-Kanals)
• ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel
• Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel
• Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung")
• symmetrische Schlüssel für die HMAC-Prüfung der VSDM-Prüfziffern (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

A_26109 - ePA-Aktensystem - Unterschiedliche private Authentisierungsschlüssel für AK-, Befugnisverifikations- und Service-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass für die Authentisierungsidentitäten für Aktenkontoverwaltungs-VAUs, Befugnisverifikations-VAUs und Service-VAUs unterschiedliche private Schlüssel verwendet werden. [<=]

A_26110 - ePA-Aktensystem - Unterschiedliche private Authentisierungsschlüssel für unterschiedliche Service-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass für unterschiedliche Typen von Service-VAUs unterschiedliche private Schlüssel für die Authentisierung genutzt werden. [<=]

A_24612-03 - ePA-Aktensystem - Erzwingen von 4-Augen-Prinzip für Einbringen und Verwalten von Informationen ins VAU-HSM

Das ePA-Aktensystem MUSS technisch erzwingen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip in das VAU-HSM eingebracht und verwaltet werden können:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
• ggf. privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

A_24614-02 - ePA-Aktensystem - Einbringung von Informationen ins VAU-HSM im 4-Augen-Prinzip mit der gematik

Der Betreiber des ePA-Aktensystems MUSS sicherstellen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip ins VAU-HSM eingebracht und im VAU-HSM verwaltet werden, bei dem eine von der gematik benannte Person beteiligt ist:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
• ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

A_24618-02 - ePA-Aktensystem - Zugriff auf Schlüssel und Informationen im VAU-HSM

Das ePA-Aktensystem MUSS sicherstellen, dass auf die folgenden, für den Betrieb der VAU notwendigen und im VAU-HSM gespeicherten Schlüssel und Informationen ausschließlich über attestierte VAU-Instanzen zugegriffen werden kann:

• privater Schlüssel der Authentisierungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
• privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU ausschließlich durch eine Befugnisverifikations-VAU-Instanz
• privater Schlüssel der Authentisierungsidentität eines Service-VAU-Typs ausschließlich durch eine Service-VAU-Instanz dieses Service-VAU-Typs
• privater Schlüssel der Verschlüsselungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• privater Schlüssel der Signaturidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentiät des anderen ePA-Aktensystembetreibers ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
• Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung") ausschließlich durch die Aktenkontoverwaltungs-VAU-Instanz oder durch eine dedizierte Überschlüsselungs-VAU
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz
  
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz.

A_25281 - ePA-Aktensystem - VAU-Token-Modul ausschließlich im HSM

Das ePA-Aktensystem MUSS sicherstellen, dass ein VAU-Token-Modul ausschließlich in einem VAU-HSM ausgeführt wird. [<=]

A_24574 - ePA-Aktensystem - Befugnisverifikations-Modul im HSM oder Befugnisverifikations-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass ein Befugnisverifikations-Modul ausschließlich in einem VAU-HSM oder in einer Befugnisverifikations-VAU ausgeführt wird. [<=]

A_25050 - ePA-Aktensystem - 1:1-Beziehung zwischen Befugnisverifikations-VAU und Aktenkontoverwaltungs-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass eine 1:1-Beziehung zwischen einer Instanz einer Befugnisverifikations-VAU und einer Instanz einer Aktenkontoverwaltungs-VAU gibt. [<=]

A_24712-01 - ePA-Aktensystem - VAU-Token-Modul nur durch Befugnisverifikations-Modul oder Aktenkontoverwaltungs-VAU aufrufbar

Das ePA-Aktensystem MUSS sicherstellen, dass die Regeln hsm-r1 bis hsm-r3 des VAU-Token-Moduls ausschließlich von einem Befugnisverifikations-Modul und die Regeln hsm-r4 bis hsm-r7 ausschließlich von einer Aktenkontoverwaltungs-VAU aufgerufen werden. [<=]

A_25282-01 - ePA-Aktensystem - Regeln des VAU-Token-Moduls

Das VAU-Token-Modul MUSS die in Tabelle Tab_AS_VAU_Token_Modul_Rules definierten Regeln umsetzen. [<=]

A_24667 - ePA-Aktensystem -VAU-HSM - Prüfen des VAU-Attestierungstokens

Das VAU-HSM MUSS bei der Prüfung eines VAU-Attestierungstokens sicherstellen, dass dieses zeitlich gültig ist und Replay-Attacken abwehren. [<=]

A_26303 - ePA-Aktensystem - Abgeleitete Verschlüsslungsschlüssel sind ausschließlich einer VAU zugänglich

Das ePA-Aktensystem MUSS sicherstellen, dass ein mit Regel hsm-r8 abgeleiteter Schlüssel ausschließlich einer VAU zugänglich ist und ausschließlich mittels AES/GCM analog [gemSpec_Krypt#GS-A_4389] verwendet wird. [<=]

A_24573-02 - ePA-Aktensystem - Regeln des Befugnisverifikations-Moduls

Das Befugnisverifikations-Modul  MUSS die in den Tabellen Tab_AS_Entitlement_Registration_Rules und Tab_AS_SDS-Key_Rules definierten Regeln umsetzen. [<=]

A_24690-01 - ePA-Aktensystem - Befugnisverifikations-Modul: Prüfen des ID-Tokens

Das Befugnisverifikations-Modul MUSS folgende Prüfungen bei der Prüfung eines ID-Tokens durchführen: 

• das ID-Token muss gemäß A_25042-* valide signiert sein durch einen sektoralen Identity Provider oder den IDP-Dienst (professionOID ist oid_idpd_sek oder oid_idpd),
• das ID-Token muss zeitlich gültig sein (Felder: iat, exp),
• das ID-Token muss im Feld aud das ePA-Aktensystem eingetragen haben.

A_24691 - ePA-Aktensystem - Befugnisverifikations-Modul: Prüfen von übers ePA-FdV erstellten Befugnissen

Das Befugnisverifikations-Modul MUSS folgende Prüfungen bei der Prüfung einer von einem Versicherten bzw. Vertreter über das ePA-FdV eingestellten signierten Befugnis durchführen:

• die Befugnis muss gemäß A_25042-* valide signiert sein durch einen Versicherten bzw. Vertreter (C.CH.SIG, professionOID ist oid_versicherter),
• das JWT für die Befugnis gemäß A_24587-* darf nicht abgelaufen sein (Feld: exp),
  
• das Feld insurantID des JWT muss eine KVNR sein,
• das Feld actorID des JWT muss eine KVNR oder eine Telematik-ID sein,
• das Feld validTO des JWT muss ein zeitliches Datum sein.

A_25716-01 - ePA-Aktensystem - Services ausschließlich in der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass die folgenden Services ausschließlich innerhalb einer VAU ausgeführt werden können und ein Zugriff auf die Schnittstellen ausschließlich über einen VAU-Kanal erfolgen kann:

• Consent Decision Management Service
  
• Entitlement Management
  
• Constraint Management
  
• Device Management
• E-Mail Management
• Audit Event Service
• Authorization Service
• Health Record Relocation Service
• alle Medical Services
• Data Submission Service.

A_24613 - ePA-Aktensystem - Bildung Hashwertrepräsentation des VAU-Images

Der Hersteller des VAU-Images MUSS für seine zugelassenen VAU-Images Hashwertrepräsentationen bilden. Diese MÜSSEN signiert und die signierten Hashwertrepräsentationen an die gematik übermitteln. Dabei SOLLEN bezüglich der kryptographischen Vorgaben zur Signatur die Vorgaben aus [gemSpec_Krypt] eingehalten werden. [<=]

A_24642 - ePA-Aktensystem - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU MUSS die Integrität der eingesetzten Hardware schützen und damit insbesondere Manipulationen an der Hardware durch den Betreiber des ePA-Aktensystems ausschließen. [<=]

A_24616 - ePA-Aktensystem - Attestierung des VAU-Images und der VAU-Hardware beim Start

Das ePA-Aktensystem MUSS beim Start einer VAU das genutzte VAU-Image sowie die VAU-Hardware, auf der die VAU ausgeführt werden soll, kryptographisch attestieren und ein signiertes VAU-Attestierungstoken erzeugen, welches vom VAU-HSM geprüft werden kann. [<=]

A_24684 - ePA-Aktensystem - Hardwarebasierter Vertrauensanker für Attestierung der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass der kryptographische Vertrauensanker für die Attestierung des VAU-Images und der VAU-Hardware in einem hardwarebasierten sicheren Schlüsselspeicher gesichert ist. [<=]

A_24617 - ePA-Aktensystem - Betreiberunabhängiger Vertrauensanker für Attestierung der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass der kryptographische Vertrauensanker für die Attestierung des VAU-Images und der VAU-Hardware nicht in der Hoheit des Betreibers des Aktensystems liegt.  [<=]

A_24620 - ePA-Aktensystem - Attestierung durch Systeme außerhalb der VAU zur Laufzeit

Das ePA-Aktensystem MUSS technisch ermöglichen, dass Änderungen an der VAU-Software und der VAU-Hardware während der Laufzeit durch Systeme außerhalb der VAU automatisiert geprüft werden können.  [<=]

A_24621 - ePA-Aktensystem - Äußere Isolation der VAU von Datenverarbeitungsprozessen des Betreibers

Die VAU MUSS die in ihr ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Betreibers technisch trennen und damit gewährleisten, dass der einzelne Mitarbeiter des Betreibers vom Zugriff auf die in der VAU verarbeiteten Daten technisch ausgeschlossen ist.  [<=]

A_24638 - ePA-Aktensystem - Schutz der Daten vor physischem Zugang zu Systemen der VAU

Die VAU MUSS mit technischen Mitteln sicherstellen, dass bei einem physischen Zugang zu Hardware-Komponenten der VAU keine Daten aus der VAU extrahiert oder manipuliert werden können.  [<=]

A_24651 - ePA-Aktensystem - Betreiber ergreift Maßnahmen gegen physische Angriffe auf die VAU

Der Betreiber des ePA-Aktensystems MUSS mit technischen und/oder organisatorischen Maßnahmen ausschließen, dass ein einzelner Innentäter beim Betreiber des ePA-Aktensystems physische Angriffe auf eine VAU ausführen kann.   [<=]

A_24641 - ePA-Aktensystem - Löschen aller Daten beim Beenden einer VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass beim Beenden einer VAU-Instanz sämtliche Daten dieser VAU-Instanz aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist. [<=]

A_25244 - ePA-Aktensystem - x-insurantId nicht außerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass das HTTP Header-Element mit dem Namen "x-insurantId" nicht außerhalb des VAU-Kanals gesendet wird. [<=]

A_26314 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Daten

Das ePA-Aktensystem MUSS sicherstellen, dass eine VAU Daten, die im System des Aktensystembetreibers gespeichert werden sollen und für die keine spezifischen Anforderungen zum Schutz der gespeicherten Daten existieren, ausschließlich verschlüsselt gespeichert werden und der verwendete Verschlüsselungsschlüssel mittels der Regel hsm-r8 vom VAU-HSM abgeleitet wird. [<=]

A_26322 - ePA-Aktensystem - Unterschiedliche Schlüssel für die Verschlüsselung von außerhalb der VAU gespeicherten Daten bei unterschiedlichen Verarbeitungszwecken

Falls Daten außerhalb der VAU im System des Aktensystembetreibers gespeichert werden, MUSS das ePA-Aktensystem sicherstellen, dass für die Verschlüsselung von Daten, die zu unterschiedlichen Zwecken verarbeitet werden, unterschiedliche Verschlüsselungsschlüssel genutzt werden. [<=]

A_24653 - ePA-Aktensystem - Sichere Verbindung zwischen VAU und VAU-HSM

Das ePA-Aktensystem MUSS technisch sicherstellen, dass zwischen einer VAU und einem VAU-HSM eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

A_24910 - ePA-Aktensystem - Erlaubte Zwecke der Betreiberprotokolle

Der Betreiber des Aktensystems MUSS sicherstellen, dass die durch die VAU für den Betrieb erstellten Protokolle des Betreibers ausschließlich zum Zwecke der Fehleranalyse und -behebung anlassbezogen sowie zum Zwecke des Security Monitorings verwendet werden. [<=]

A_24649 - ePA-Aktensystem - Datenschutzkonformes Logging und Monitoring der VAU

Die VAU MUSS die für den Betrieb des ePA-Aktensystems erforderlichen Logging- und Monitoring-Informationen in solcher Art und Weise erheben und verarbeiten, dass mit technischen Mitteln ausgeschlossen ist, dass dem Betreiber des ePA-Aktensystems vertrauliche oder zur unautorisierten Profilbildung geeignete Daten zur Kenntnis gelangen.  [<=]

A_24695 - ePA-Aktensystem - Keine medizinische Informationen in VAU-Protokollen des Betreibers

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers keine personenbezogenen medizinischen Informationen enthalten sind (u. a. medizinische Daten von Versicherten oder Informationen, aus denen sich ableiten lässt, bei welchen Leistungserbringerinstitutionen ein Versicherter in Behandlung ist).
[<=]

A_24909 - ePA-Aktensystem - Nicht KVNR und Telematik-ID gemeinsam protokollieren

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers höchstens die KVNR oder höchstens die Telematik-ID enthalten ist, aber nicht eine Kombination aus KVNR und Telematik-ID und keine solche Verbindung über mehrere Protokolle hergestellt werden kann. [<=]

A_24719 - ePA-Aktensystem - Kein kryptographisches Schlüsselmaterial in VAU-Protokollen des Betreibers

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers kein kryptographisches Schlüsselmaterial enthalten ist. [<=]

A_24911 - Löschfristen Protokolle

Das ePA-Aktensystem MUSS sicherstellen, dass die

• zum Zwecke der Fehleranalyse erhobenen Protokolle nach Behebung des Fehlers unverzüglich gelöscht werden,
• zum Zwecke des Security Monitorings erhobenen Protokolle nach 3 Monaten gelöscht werden.
  

A_26316 - Anbieter ePA-Aktensystem - Schutz der Protokolle des Betreibers

Der Betreiber des ePA-Aktensystems MUSS sicherstellen, dass die durch die VAU für den Betrieb erstellten Protokolle des Betreibers durch technische und organistorische Maßnahmen vor einer missbräuchlichen Nutzung geschützt werden. [<=]

A_24636 - ePA-Aktensystem - Innere Isolation zwischen Datenverarbeitungsprozessen innerhalb einer VAU-Instanz

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus ausschließen, dass sich innerhalb einer VAU-Instanz die Verarbeitungen eines Health Record Context oder einer User Session schadhaft auf die Verarbeitungen eines anderen Health Record Context oder einer anderen User Session auswirken können.
[<=]

A_24885 - ePA-Aktensystem - Innere Isolation zwischen Datenverarbeitungsprozessen unterschiedlicher VAU-Instanzen

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus, der unabhängig vom Separationsmechanismus in A_24636-* ist, ausschließen, dass sich Verarbeitungen in einer VAU-Instanz schadhaft auf die Verarbeitungen einer anderen VAU-Instanz auswirken können.
[<=]

A_24637 - ePA-Aktensystem - Maximale Health Record Context in einer VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass maximal 80 Health Record Context gleichzeitig in einer VAU-Instanz laufen können.
[<=]

A_25028 - ePA-Aktensystem - Keine Kommunikation zwischen Aktenkontoverwaltungs-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass es keine direkte Kommunikation zwischen VAU-Instanzen von Aktenkontoverwaltungs-VAUs gibt. [<=]

A_26111 - ePA-Aktensystem - Keine Kommunikation zwischen Health Record Contexts

Das ePA-Aktensystem MUSS sicherstellen, dass es innerhalb einer Aktenkontoverwaltungs-VAU-Instanz keine Kommunikation zwischen Health Record Contexts gibt. [<=]

A_24639 - ePA-Aktensystem - Löschen aller Daten beim Beenden eines Health Record Context

Die VAU MUSS sicherstellen, dass beim Beenden eines Health Record Context sämtliche Daten dieses Health Record Context aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist.  [<=]

A_24640 - ePA-Aktensystem - Löschen aller Daten beim Beenden einer User Session

Die VAU MUSS sicherstellen, dass beim Beenden einer User Session sämtliche Daten dieser User Session aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist. [<=]

A_25231 - ePA-Aktensystem - Schließen des Health Record Context beim Beenden einer User Session

Die VAU MUSS sicherstellen, dass beim Beenden einer User Session alle mit dieser User Session verknüpften Health Record Context beendet werden, wenn der jeweilige Health Record Context nicht mit mindestens einer weiteren User Session verknüpft ist. [<=]

A_25051 - ePA-Aktensystem - VAU-Kanal endet immer in einer Aktenkontoverwaltungs-VAU

Die VAU MUSS sicherstellen, dass ein VAU-Kanal von einem Client der ePA (ePA-Client oder ePA-FdV) ausschließlich in einer Aktenkontoverwaltungs-VAU endet. [<=]

A_24643 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Daten mit dem Datenpersistierungsschlüssel

Die VAU MUSS sicherstellen, dass die in einem Health Record Context verarbeiteten

1. Daten des FHIR-Data Service
2. Daten des XDS Document Service
3. Daten des Audit Event Service (Protokolle für den Versicherten zum Zwecke der Datenschutzkontrolle)
   
4. Daten des Constraint Managements (Policies zu verborgenen Daten)
   
5. Daten des Consent Managements (Widersprüche des Versicherten)

A_24644 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Befugnissen mit dem Befugnispersistierungsschlüssel

Die VAU MUSS sicherstellen, dass die in einem Health Record Context verarbeiteten Daten des Entitlement Managements, d. h. Befugnisse und Befugnisverbote, vor der Speicherung in den Systemen des Betreibers des ePA-Aktensystems innerhalb des Health Record Context mit dem zum Health Record gehörenden versichertenindividuellen Befugnispersistierungsschlüssel verschlüsselt werden. [<=]

A_24650 - ePA-Aktensystem - Konsistenter Systemzustand eines Health Record Context

Die VAU MUSS sicherstellen, dass ein konsistenter Zustand eines Health Record Context auch bei Bedienfehlern oder technischen Problemen immer erhalten bleibt bzw. wiederhergestellt werden kann. [<=]

A_24696 - ePA-Aktensystem - Konsistenz bei parallelen Zugriffen

Die VAU MUSS auch bei parallelen Zugriffen auf dasselbe Aktenkonto durch mehrere Nutzer immer einen konsistenten Zustand des Aktenkontos gewährleisten. [<=]

A_24646 - ePA-Aktensystem - Befugnisverifikations-VAU verarbeitet ausschließlich ein Befugnisverifikations-Modul

Das ePA-Aktensystem MUSS sicherstellen, dass in einer Befugnisverifikations-VAU ausschließlich ein Befugnisverifikations-Modul ausgeführt wird. [<=]

A_24647 - ePA-Aktensystem - Befugnisverifikations-VAU speichert keine Daten

Eine Befugnisverifikations-VAU DARF die Daten, die sie im Rahmen der Regeln des Befugnisverifikations-Moduls verarbeitet, NICHT außerhalb der Befugnisverifikations-VAU speichern. [<=]

A_24648 - ePA-Aktensystem - Befugnisverifikations-VAU löscht Daten nach Regelbearbeitung

Eine Befugnisverifikations-VAU MUSS sämtliche Daten, die sie im Rahmen eines Regelaufrufs des Befugnisverifikations-Moduls verarbeitet, sofort nach Abarbeitung der Regel sicher aus der Befugnisverifikations-VAU löschen bzw. einen Zugriff auf diese Daten technisch ausschließen. [<=]

A_24671 - ePA-Aktensystem - Sichere Verbindung zwischen VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass zwischen einer VAU-Instanz einer Befugnisverifikations-VAU und einer VAU-Instanz einer Aktenkontoverwaltungs-VAU eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

A_24856 - ePA-Aktensystem - Private Authentisierungsschlüssel für sichere Verbindung zwischen VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass sich die VAU-Instanzen bei einer Verbindung zwischen einer VAU-Instanz einer Befugnisverifikations-VAU und einer VAU-Instanz einer Aktenkontoverwaltungs-VAU mit privaten Schlüsseln authentisieren, die ausschließlich über die jeweilige VAU-Instanz nutzbar sind. [<=]

A_26112 - ePA-Aktensystem - Maximale Isolated Workspaces in einer Service-VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass maximal 80 Isolated Workspaces gleichzeitig in einer Service-VAU-Instanz laufen können. [<=]

A_26113 - ePA-Aktensystem - Isolation zwischen Isolated Workspaces innerhalb einer Service-VAU-Instanz

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus ausschließen, dass sich innerhalb einer Service-VAU-Instanz die Verarbeitungen eines Isolated Workspaces schadhaft auf die Verarbeitungen eines anderen Isolated Workspaces auswirken können. [<=]

A_26114 - ePA-Aktensystem - Isolation zwischen unterschiedlichen Service-VAU-Instanzen

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus, der unabhängig vom Separationsmechanismus in A_26113-* ist, ausschließen, dass sich Verarbeitungen in einer Service-VAU-Instanz schadhaft auf die Verarbeitungen einer anderen Service-VAU-Instanz auswirken können. [<=]

A_26115 - ePA-Aktensystem - Isolated Workspace verarbeitet maximal einen Request einer AK-VAU

Nachdem ein Isolated-Workspace einen (1) Service-Request einer Aktenkontoverwaltungs-VAU-Instanz verarbeitet hat, MUSS das ePA-Aktensystem sicherstellen, dass alle Daten des Isolated-Workspaces sicher gelöscht werden, um den Isolated-Workspace für nachfolgende Service-Requests wieder neu zu initialisieren.  [<=]

A_26116 - ePA-Aktensystem - In einem Isolated Workspace sind zu einem Zeitpunkt nur Daten eines Versicherten

Das ePA-Aktensystem MUSS sicherstellen, dass in einem Isolated Workspace zu einem Zeitpunkt ausschließlich Daten eines Versicherten verarbeitet werden können, sofern die Auswahl der zu verarbeitenden Daten durch die Logik im ePA-Aktensystem bestimmt wird. [<=]

A_26117 - ePA-Aktensystem - Keine Kommunikation zwischen Isolated Workspaces

Das ePA-Aktensystem MUSS sicherstellen, dass es innerhalb einer Service-VAU-Instanz keine Kommunikation zwischen Isolated Workspaces gibt. [<=]

A_26118 - ePA-Aktensystem - Keine Kommunikation zwischen Service-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass es keine Kommunikation zwischen Instanzen von Service-VAUs gibt. [<=]

A_26119 - ePA-Aktensystem - Service-VAUs speichern keine Daten in Aktenkonten

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen keine Daten in einem Aktenkonto eines Versicherten persistieren. [<=]

A_26120 - ePA-Aktensystem - Service-VAUs verarbeiten keine Identitätstoken

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen keine Identitätstoken von Nutzern verarbeiten. [<=]

A_26123 - ePA-Aktensystem - Service-VAU-Instanzen haben maximale Lebensdauer

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen nach einer definierten Lebensdauer (abhängig von der Funktionalität der Services) keine neuen Service-Requests mehr annehmen können und, nachdem die laufenden Requests abgearbeitet wurden, beendet und neu gestartet werden. [<=]

A_26124 - ePA-Aktensystem - Information über neuen Service-VAU-Typ

Der Hersteller des ePA-Aktensystems MUSS die gematik über die Absicht der Einführung eines neuen Service-VAU-Typs informieren und ggf. für diesen neuen Service-VAU-Typ zu erfüllende Rahmenbedingungen abstimmen. [<=]

A_26125 - ePA-Aktensystem - Starten ausschließlich attestierter Service-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass ausschließlich attestierte Service-VAU-Instanzen gestartet werden können. [<=]

A_26126 - ePA-Aktensystem - Gesicherte und authentisierte Verbindung zwischen AK-VAU- und Service-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass zwischen einer Aktenkontoverwaltungs-VAU-Instanz und einer Service-VAU-Instanz eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

A_26127 - ePA-Aktensystem - Kein Kommunikationsaufbau von Service-VAU-Instanzen zu AK-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass eine Service-VAU-Instanz keine Kommunikation zu einer AK-VAU-Instanz aufbauen kann. [<=]

A_26128 - ePA-Aktensystem - Kein Aufruf von Schnittstellen von AK-VAU-Instanzen durch Service-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass eine Service-VAU-Instanz keine Schnittstellen/Services aufrufen kann, die in einer AK-VAU-Instanz ausgeführt werden. [<=]

A_26197 - ePA-Aktensystem - betreiberspezifische Schlüssel: Überschlüsselungs-Masterkeys

Ein ePA-Aktensystem MUSS sicherstellen, dass die Menge der betreiberspezifischen Schlüssel aus [gemSpec_Krypt#A_15745-*] um die Kategorie Überschlüsselungs-Masterkeys erweitert wird. Für die Überschlüsselungsschlüssel MÜSSEN die gleichen Vorgaben wie für alle bestreiberspezifischen Schlüssel gemäß A_15745-* gelten.
Die betreiberspezifischen Schlüssel werden mindestens jährlich aktualisiert (A_20519-*), die alten Schlüssel MÜSSEN solange im VAU-HSM verfügbar sein, solange Chiffrate im Aktensystem existieren (bspw. Daten einer Akte), die mit diesen Schlüsseln kryptographisch gesichert sind. [<=]

A_26198 - ePA-Aktensystem - neuer Überschlüsselungsschlüssel bei Erneuerung betreiberspezifischen Schlüssel

Ein ePA-Aktensystem MUSS sicherstellen, dass bei jeder Erneuerung der Masterkeys zur Aktenpersistierung ein weiterer neuer Überschlüsselungsmasterkey zufällig im VAU-HSM erzeugt wird.
[<=]

A_26204 - ePA-Aktensystem - zeitliche Vorgaben zur Durchführung der Umschlüsselung und Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass es ein konfigurierbares Zeitintervall alpha gibt, so dass nach einer Schlüsselerneuerung der betreiberspezifischen Schlüssel innerhalb von alpha bei einer Aktennutzung eine Umschlüsselung in einer AK-VAU vorgenommen wird, falls die Verschlüsselung der Akte auf einem älteren Masterkey basiert. Das Zeitintervall alpha startet jeweils direkt mit jedem neuen Intervall (Schlüsselerneuerung der betreiberspezifischen Schlüssel).
Weiter MUSS es sicherstellen, dass es ein konfigurierbares Zeitintervall beta gibt beginnend direkt nach alpha, so dass nach ablaufen von alpha eine Überschlüsselung von Chiffraten von Akten, bei denen keine Umschlüsselung (wegen Nichtaktennutzung innerhalb von alpha) durchgeführt werden konnte, vorgenommen wird.

Der Default-Wert für die Länge von alpha MUSS 100 Tage und für die Länge von beta 60 Tage betragen. ("Default-Wert" bedeutet, Wert wenn der AS-Betreiber dort keinen anderen Wert konfigurieren möchte.)
[<=]

A_26205 - ePA-Aktensystem - Umschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass wenn die AK-VAU eine Akte verwendet und feststellt, dass diese Akte nicht überschlüsselt ist und die versichertenindividuelle Aktenverschlüsselung auf einem älteren Masterkey (i. S. v. eben nicht aus dem aktuellen Intervall kommend) basiert, die AK-VAU eine Umschlüsselung vornimmt. Die alten Chiffrate der Akten (also die Chiffrate die auf Basis eines älteren Masterkeys verschlüsselt sind), MÜSSEN im Aktensystem nach erfolgreicher Umschlüsselung gelöscht werden.

Wenn die AK-VAU eine Akte verwendet und feststellt, dass diese überschlüsselt ist, so MUSS die AK-VAU die Überschlüsselung entschlüsseln und die nun verfügbaren Chiffrate der Akten auf Grundlage des aktuellen Masterkeys umschlüsseln. (Hinweis: nach Konstruktion muss die innere Aktenverschlüsselung auf einem älteren Masterkey basieren, ansonsten hätte keine Überschlüsselung stattgefunden.) Nach erfolgreicher Umschlüsselung MÜSSEN die alten Chiffrate (das Überschlüsselungschiffrat und das alte "innere" Chiffrat der Akte) im Aktensystem gelöscht werden. [<=]

A_26206 - ePA-Aktensystem - Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass jeweils im aktuellen Intervall nach Ablauf des Zeitintervalls alpha Akten, die nicht überschlüsselt sind und deren Verschlüsselung auf einem älteren Masterkey (i. S. v. nicht aus dem aktuellen Zeitintervall) basiert, überschlüsselt werden auf Basis des aktuellen Überschlüsselungs-Masterkeys. Diese Umschlüsselung MUSS jeweils innerhalb des Zeitintervalls beta für alle solche Akten abgeschlossen werden. Die "alten" Chiffrate (Chiffrate von solchen Akten vor der Überschlüsselung) MÜSSEN im Aktensystem gelöscht werden. [<=]

A_26208 - ePA Aktensystem - Umschlüsselung einer Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass jeweils in einem Intervall innerhalb von beta überprüft wird, ob überschlüsselte Akten existieren, deren Überschlüsselung auf Basis eines alten Überschlüsselungs-Masterkeys (also aus einem früheren Intervall stammend) durchgeführt wurde. Die AK-VAU (oder eine dedizierte Überschlüsselungs-VAU) MUSS die überschlüsselten Akten umschlüsseln, d. h. die Überschlüsselung auf Grundlage eines älteren Überschlüsselungs-Masterkeys wird aufgehoben (äußeren Verschlüsselungsschicht innerhalb der VAU entschlüsselt) und das Ergebnis (= Chiffrat einer Akte) neu verschlüsselt auf Basis des aktuellen Überschlüsselungs-Masterkeys. Die alten Chiffrate (also vor der Umschlüsselung der Überschlüsselung) MÜSSEN gelöscht werden. Das ePA-Aktensystem MUSS sicherstellen, dass nach Ablauf von beta keine überschlüsselten Akten existieren, deren Überschlüsselung auf Basis eines Überschlüsselungsschlüssel, der nicht aus dem aktuellen Intervall stammt, durchgeführt wurde.
[<=]

A_26199 - ePA-Aktensystem - Notfall-Aktivierung Umschlüsselung/Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass das ePA-Aktensystem es einem ePA-Betreiber ermöglicht eine Erneuung der betreiberspezifischen Schlüssel zu starten/aktivieren. Es MUSS also dem ePA-Betreiber möglich sein neben der regelmäßigen Erneuerung der betreiberspezifischen Schlüssel (A_205019-*) eine Erneuerung zu initiieren.
[<=]

A_26223 - ePA-Aktensystem - Metadaten von ePA-spezifischen Chiffraten

Ein ePA-Aktensystem MUSS sicherstellen, dass bei ePA-spezifischen Daten (Datenpersistierung von Akten, überschlüsselte Aktenchiffrate, verschlüsselte Befugnisse etc.) an den äußeren (also unverschlüsselten) Meta-Daten des Chiffrat erkennbar ist mithilfe welches (oder welcher) Masterkeys die Chiffrate entschlüsselbar sind. [<=]

A_23874-01 - Consent Decision Management - Definition der widerspruchsfähigen Funktionen der ePA

Das Consent Decision Management MUSS die Attribute zu widerspruchsfähigen Funktionen der ePA gemäß der folgenden Tabelle verwenden.

Tabelle 11: Widerspruchsfähige Funktionen der elektronischen Patientenakte

A_25300 - Consent Decision Management - Untereinander abhängige Entscheidungen zu Widersprüchen

Das Consent Decision Management MUSS durch interne Maßnahmen sicherstellen, dass bei Erteilung eines Widerspruchs gegen die Nutzung der Funktion der elektronischen Patientenakte 'erp-submission' ('deny') auch der Widerspruch gegen die Nutzung der Funktion 'medication' gesetzt wird ('deny') und dass bei der Rücknahme ('permit') des Widerspruchs gegen die Nutzung der Funktion 'medication' auch der Widerspruch gegen die Nutzung der Funktion 'erp-submission' zurückgenommen wird. [<=]

A_23766 - Consent Decision Management - Initialisierung der Widerspruchsinformation zur Nutzung von Funktionen der ePA

Das Consent Decision Management MUSS die Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte bei Erstellung eines neuen Aktenkontos oder bei Übernahme eines existierenden Aktenkontos einer älteren ePA-Version für alle Funktionen, gegen die der Versicherte nicht widersprochen hat mit der Entscheidung "kein Widerspruch erklärt" ("permit") initialisieren sowie alle Funktionen, gegen die der Versicherte widersprochen hat, mit "deny" initialisieren.
[<=]

A_24343 - Consent Decision Management - Speichern der Inhalte

Das Consent Decision Management MUSS die Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_23712 - Consent Decision Management - Übertrag der Widerspruchsinformation zur Nutzung von Funktionen der ePA für den Informationsdienst

Das Consent Decision Management MUSS die aktuellen Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte der Funktionsklassen

• Versorgungsprozess ("healthCareProcess")

A_24040 - Consent Decision Management - Periodischer Übertrag der Widerspruchsinformation zur Nutzung von Funktionen der ePA für den Informationsdienst

Das Consent Decision Management MUSS die aktuellen Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte der Funktionsklassen

• Versorgungsprozess ("healthCareProcess")

A_23824 - Aktensystem - Realisierung der Schnittstelle I_Consent_Decision_Management

Das Aktensystem MUSS die Operationen der Schnittstelle I_Consent_Decision_Management gemäß [I_Consent_Decision_Management] umsetzen. [<=]

A_23919 - Consent Decision Management - unveränderte Übernahme der Widerspruchsentscheidung

Das Consent Decision Management MUSS die über Operationen der Schnittstellen des Consent Managements übermittelten Entscheidungen (consent decisions) zu widerspruchsfähigen Funktionen der ePA in das Aktenkonto übernehmen. Die Entscheidungen zu den in den Operationen nicht adressierten widerspruchsfähigen Funktionen MÜSSEN im Aktenkonto unverändert bleiben. [<=]

A_24844 - Consent Decision Management - Information über Änderungen der Widerspruchsinformation

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung einer Widerspruchsinformation, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass Widerspruchsinformationen geändert wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_24055 - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Widersprüchen

Das Consent Decision Management MUSS Bei Änderungen von Entscheidungen zu den widerspruchsfähigen Funktionen der ePA jeweils einen Protokolleintrag gemäß A_24704* erzeugen. Für die Wertebelegung ist A_23874* zu berücksichtigen und die Protokollstruktur entsprechend zu belegen:

Tabelle 12: Consent Decision Management Protokollierung - Widersprüche für Funktionen der ePA

A_26293 - Consent Decision Management – Weiterleitung von Widersprüchen gegen die Sekundärdatennutzung durch das FDZ

Das Consent Decision Management MUSS die Information über einen erklärten Widerspruch die Sekundärdatennutzung durch das FDZ über den Data Submission Service an das FDZ weiterleiten. [<=]

A_26286 - Consent Decision Management - Initialisierung der Sekundärnutzungszwecke

Das Consent Decision Management MUSS jeden in § 303e Absatz 2 SGB V aufgeführten Sekundärnutzungszweck der elektronischen Patientenakte bei Erstellung eines neuen Aktenkontos oder bei Übernahme eines existierenden Aktenkontos einer älteren ePA-Version mit der Entscheidung "kein Widerspruch erklärt" ("permit") initialisieren. [<=]

A_26287 - Consent Decision Management - Speichern der Entscheidungen zu Sekundärnutzungszwecken

Das Consent Decision Management MUSS die Entscheidungen zu Sekundärnutzungszwecken der elektronischen Patientenakte unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_26288 - Consent Decision Management - Übertragen der Entscheidungen zu Sekundärnutzungszwecken an das FDZ

Das Consent Decision Management MUSS die Entscheidungen zu Sekundärnutzungszwecken sofort im Anschluss an eine Änderung der Entscheidung im Consent Decision Management in das Paket zur Übermittlung von pseudonymisierten medizinischen Daten zu Sekundärnutzungszwecken an das FDZ aufnehmen. [<=]

A_26291 - Consent Decision Management - unveränderte Übernahme der Widerspruchsentscheidung

Das Consent Decision Management MUSS die über Operationen der Schnittstellen des Consent Managements [I_Consent_Decision_Management] übermittelten Entscheidungen zu Sekundärnutzungszwecken in das Aktenkonto übernehmen. [<=]

A_26292 - Consent Decision Management - Information über Änderungen der Entscheidungen zu Sekundärnutzungszwecken

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung der Entscheidungen zu Sekundärnutzungszwecken, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass Entscheidungen zu Sekundärnutzungszwecken geändert wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_26294 - Consent Decision Management – Weiterleitung von Widersprüchen gegen Sekundärnutzungszwecken an das FDZ

Das Consent Decision Management MUSS die Information über einen erklärten Widerspruch gegen Sekundärnutzungszwecke  über den Data Submission Service an das FDZ weiterleiten. [<=]

A_26310 - Consent Decision Management – Rücknahme des Widerspruchs gegen die Sekundärdatennutzung durch das FDZ

Falls ein Widerspruch gegen die Sekundärdatennutzung durch das FDZ zurückgenommen wird MUSS das Consent Decision Management die Entscheidungen zu Sekundärnutzungszwecken über den Data Submission Service an das FDZ weiterleiten. [<=]

A_26308 - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Sekundärnutzungszwecken

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äß A_24704* erzeugen.

Tabelle 13: Consent Decision Management Protokollierung - Widersprüche zu Sekundärnutzungszwecken

A_26400 - Consent Decision Management - Initialisierung der User Specific Deny Policy Medication

Das Consent Decision Management MUSS für ein Aktenkonto eine User Specific Deny Policy Medication ohne initiale Einträge, bereitstellen und die Konfiguration der Einträge der Policy über die Schnittstelle I_Constraint_Management_Insurant gemäß [I_Constraint_Management_Insurant] ermöglichen. [<=]

A_26401 - Consent Decision Management - Speichern der Inhalte der User Specific Deny Policy Medication

Das Consent Decision Management MUSS Einträge aus der User Specific Deny Policy Medication unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_26403 - Consent Decision Management - Information über Änderungen der User Specific Deny Policy Medication

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung der Entscheidungen zu der User Specific Deny Policy Medication , sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, welche Änderungen der User Specific Deny Policy Medication vorgenommen wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_26406 - Consent Decision Management - Policy für berechtigte Nutzergruppen und Nutzer

Das Consent Decision Management MUSS die Konfiguration der User Specific Deny Policy Medication auf die folgenden Nutzergruppen einschränken:

A_26405 - Consent Decision Management – Protokollierung geänderter Entscheidungen der User Specific Deny Policy Medication

Das Consent Decision Management MUSS für jede Änderung der User Specific Deny Policy Medication einen Protokolleintrag gemäß A_24704* erzeugen:

Tabelle 14: Consent Decision Management Protokollierung - User Specific Deny Policy Medication

A_23734-01 - Entitlement Management - Definition einer Befugnis

Das Entitlement Management MUSS für eine individuelle Befugnis die folgenden Daten nutzen und verwalten: 

Tabelle 15: Inhalt einer Befugnis

A_23941-01 - Entitlement Management - Erteilung von Befugnissen für berechtigte Nutzergruppen und Nutzer

Das Entitlement Management MUSS die Erteilung von Befugnissen in der jeweiligen Umgebung auf die folgenden Nutzergruppen und Nutzer einschränken:

Tabelle 16: Befugnisse für berechtigte Nutzergruppen und Nutzer

A_26167 - Entitlement Management (EU) - Erteilung der Befugnis EU-Zugriff

Das Entitlement Management MUSS die Erteilung einer Befugnis EU-Zugriff in der jeweiligen Umgebung zusätzlich zu A_23941-* auf die folgenden Nutzergruppen und Nutzer einschränken:

Tabelle 17: Befugnisse EU-Zugriff für berechtigte Nutzergruppen und Nutzer

A_24371 - Entitlement Management - Verschlüsselung der Befugnisse

Das Entitlement Management MUSS Befugnisse mit dem versichertenindividuellen SecureAdminStorageKey verschlüsseln und im Aktenkonto persistieren. [<=]

A_24372 - Entitlement Management - Keine persistente Ablage unverschlüsselter Befugnisse

Das Entitlement Management  MUSS sicherstellen, dass Befugnisse ausschließlich verschlüsselt unter Verwendung des versichertenindividuellen SecureAdminStorageKey im Aktenkonto gespeichert werden. [<=]

A_24687 - Entitlement Management - Keine Speicherung oder Verwendung nicht verifizierter Befugnisse

Das Entitlement Management  MUSS sicherstellen, dass ausschließlich Befugnisse persistiert oder für eine Befugnisprüfung verwendet werden, die erfolgreich durch das HSM unter Verwendung der adäquaten Regeln 'rr1 - rr4' gemäß A_24573* befugnisverifiziert sind. [<=]

A_23842 - Entitlement Management - Eindeutigkeit der Befugnisse im Befugniskontext

Das Entitlement Management MUSS sicherstellen, dass im Befugniskontext keine zwei oder mehr Befugnisse existieren, die als Identifier des befugten Nutzers die gleiche Identifikation (actorId) aufweisen. [<=]

A_24785 - Entitlement Management - VSDM-Prüfungsnachweis kann höchstens einmal genutzt werden

Das Entitlement Management MUSS sicherstellen, dass ein VSDM-Prüfungsnachweis (Prüfziffer) höchstens einmal zur Registrierung einer Befugnis genutzt werden kann. [<=]

A_24506 - Entitlement Management- Realisierung der Schnittstelle I_Entitlement_Management

Das Entitlement Management MUSS die Operationen der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] umsetzen. [<=]

A_26168 - Entitlement Management (EU)- Realisierung der Schnittstelle I_Entitlement_Management_EU

Das Entitlement Management MUSS die Operationen der Schnittstelle I_Entitlement_Management_EU gemäß [I_Entitlement_Management_EU] umsetzen. [<=]

A_24987-01 - Entitlement Management - Protokolleinträge für Zugriffe auf das Entitlement Management

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äß A_24704 erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 18: Entitlement Management Protokollierung

A_24145 - Entitlement Management – Implizite initiale (statische) Befugnisse

Das Entitlement Management MUSS sicherstellen, dass der Versicherte (KVNR des Akteninhabers, oid_versicherter), und der E-Rezept-Fachdienst (registrierte Telematik-ID, oid_erp-vau) dauerhaft den versichertenindividuellen SecureDataStorageKey beziehen können und Zugriff auf die Dokumenten- und Datenverwaltung erhalten. Die Befugnisse MÜSSEN den Vorgaben der folgenden Tabelle entsprechen:

A_24374 - Entitlement Management – Signierte initiale (statische) Befugnisse

Das Entitlement Management MUSS sicherstellen, dass für den Kostenträger und die Ombudsstelle gültige Befugnisse mit unbegrenzter Gültigkeitsdauer zum Zeitpunkt der Aktivierung des Aktenkontos gemäß der Vorgaben der folgenden Tabelle vorliegen:

A_24688-01 - Entitlement Management – Befugnisverifikation signierter initialer Befugnisse

Das Entitlement Management MUSS sicherstellen, dass die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle spätestens beim ersten Zugriff auf das Aktenkonto durch das HSM unter Verwendung der Regel 'rr4' gemäß A_24573* befugnisverifiziert sind. [<=]

A_24533 - Entitlement Management - Keine Änderung statischer Befugnisse

Das Entitlement Management MUSS sicherstellen, dass die dauerhaften Befugnisse des Versicherten, des E-Rezept-Fachdiensts, des Kostenträgers und der Ombudsstelle nicht verändert oder gelöscht werden können. [<=]

A_24784 - Entitlement Management - Höchstens eine Befugnis für KTR und Ombudsstelle pro Aktenkonto

Das Entitlement Management MUSS sicherstellen, dass in einem Aktenkonto höchstens eine Befugnis für einen Kostenträger und höchstens eine Befugnis für eine Ombudsstelle hinterlegt ist. [<=]

A_24955 - Entitlement Management - Befugnis für KTR und Ombudsstelle nur bei Anlage und betreiberinterner Anbieterwechsel

Das Entitlement Management MUSS sicherstellen, dass eine signierte Befugnis des Kostenträgers und eine signierte Befugnis der Ombudsstelle ausschließlich bei einer Anlage eines Aktenkontos (Initialisierung) oder bei einem betreiberinternen Anbieterwechsel in die Befugnisse des Aktenkontos aufgenommen werden.
[<=]

A_24587-01 - Entitlement Management - Befugnis durch ein ePA-FdV

Das Entitlement Management MUSS sicherstellen, dass die Befugnisvergabe durch ePA-FdV über die Schnittstelle I_Entitlement_Management durch Verwendung eines gültig signierten JWT mit den dargestellten Mindest-Inhalten erfolgt:

A_24689 - Entitlement Management - Befugnisverifikation einer Befugnis durch ein ePA-FdV

Das Entitlement Management MUSS für ein signiertes JWT zur Befugnisvergabe durch ein ePA-FdV unter Verwendung der Regeln 'rr1' (Befugnisvergabe durch den Versicherten) bzw. 'rr2' (Befugnisvergabe durch einen Vertreter) des HSM eine Befugnisverifikation durchführen. [<=]

A_24535 - Entitlement Management - Befugnisse für Vertreter

Das Entitlement Management MUSS sicherstellen, dass Befugnisse für Vertreter (actorId = KVNR) ausschließlich durch den Versicherten erstellt oder gelöscht werden können. [<=]

A_24536 - Entitlement Management - Gültigkeitsdauer der Befugnisse für Vertreter

Das Entitlement Management MUSS sicherstellen, dass Befugnisse für Vertreter (actorId = KVNR) ausschließlich mit einer unbegrenzten Gültigkeit erstellt werden. [<=]

A_24754 - Entitlement Management - E-Mail-Adresse des Vertreters

Das Entitlement Management MUSS sicherstellen, dass bei Befugnissen für Vertreter (actorId = KVNR) eine E-Mail-Adresse des Vertreters für dessen Benachrichtigung angegeben wird. [<=]

A_24755-01 - Entitlement Management - Benachrichtigung des Vertreters bei Befugnisserstellung

Das Entitlement Management MUSS im Anschluss an die erfolgreiche, neue Befugniserstellung für einen Vertreter eine E-Mail an die E-Mail-Adresse des Vertreters senden, die diesen über die Befugniserstellung für das Aktenkonto des Versicherten geeignet informiert. In der Nachricht MUSS der Name des Versicherten enthalten sein und welche Art von personenbezogenen Daten vom Vertreter im Rahmen der Vertreterberechtigung im ePA-Aktensystem verarbeitet werden, wie der Vertreter eine Vertreterberechtigung widerrufen kann und gegenüber wem er seine datenschutzrechtlichen Betroffenenrechte wahrnehmen kann. [<=]

A_24590 - Entitlement Management - Befugnis durch ein Primärsystem

Das Entitlement Management MUSS sicherstellen, dass die Befugnisvergabe durch ein Primärsystem über die Schnittstelle I_Entitlement_Management durch Verwendung eines gültig signierten JWT mit den dargestellten Mindest-Inhalten erfolgt:

A_25249 - Entitlement Management - Befugnisverifikation einer Befugnis durch ein Primärsystem

Das Entitlement Management MUSS für ein signiertes JWT zur Befugnisvergabe durch ein Primärsystem unter Verwendung der Regeln 'rr3' (Stecken der eGK in einer Leistungserbringerumgebung) des HSM eine Befugnisverifikation durchführen. [<=]

A_24537 - Entitlement Management - Standardgültigkeitsdauer für Befugnisse

Das Entitlement Management MUSS sicherstellen, dass neue Befugnisse, die unter Verwendung der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] erstellt werden, eine vorgegebene, rollenspezifische Befugnisdauer gemäß A_23941-* erhalten. [<=]

A_24504 - Entitlement Management - Löschen ungültiger Befugnisse

Das Entitlement Management MUSS vorhandene Befugnisse, deren Enddatum der Gültigkeit überschritten ist, unverzüglich aus dem Befugniskontext des Aktenkontos vollständig löschen. [<=]

A_25246 - Entitlement Management - Löschen von Befugnissen durch einen Vertreter

Das Entitlement Management MUSS sicherstellen, dass eine erteilte Befugnis für einen Vertreter (actorId der Befugnis == KVNR) durch einen Vertreter nur dann gelöscht werden kann, wenn die KVNR des löschenden Vertreters der KVNR der actorId der zu löschenden Befugnis entspricht. [<=]

A_25269 - Entitlement Management - Benachrichtigung des Versicherten bei Löschen einer Vertreterbefugnis durch Vertreter

Falls ein Vertreter seine eigene Vertreterbefugnis löscht MUSS das Entitlement Management für den Fall, dass für den Versicherten mindestens eine E-Mail-Adresse hinterlegt ist, den Versicherten über das Löschen der Vertreterbefugnis an alle seine hinterlegten E-Mail-Adressen informieren. [<=]

A_24463-01 - Entitlement Management - zulässige Rollen für den Widerspruch gegen die Nutzung durch eine Leistungserbringerinstitution

Das Entitlement Management  MUSS den Widerspruch gegen die Nutzung durch eine Leistungserbringerinstitution ausschließlich für Nutzer der folgenden Nutzergruppen zulassen:

A_25135 - Entitlement Management - Initialisierung der Blocked User Policy

Das Entitlement Management MUSS für ein Aktenkonto eine Blocked User Policy ohne initiale Einträge, bereitstellen und die Konfiguration der Einträge der Policies über die Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] ermöglichen. [<=]

A_24514 - Entitlement Management - Keine Befugnis für von einer Befugnis ausgeschlossene Nutzer

Das Entitlement Management  MUSS sicherstellen, dass für keinen durch einen Eintrag der Blocked User Policy referenzierten Nutzer eine Befugnis existiert oder erstellt werden kann. [<=]

A_24515 - Entitlement Management- Verschlüsselung der Einträge der Blocked User Policy

Das Entitlement Management MUSS Einträge der Blocked User Policy mit dem Befugnispersistierungsschlüssel (SecureAdminStorageKey) verschlüsseln und im Aktenkonto persistieren. [<=]

A_24965 - Entitlement Management - Information über Änderungen der Blocked User Policy

Das Entitlement Management MUSS den Aktenkontoinhaber bei einer Änderung der Blocked User Policy, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass ein Befugnisausschluss geändert wurde, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_19303-20 - Legal Policy – gesetzlich vorgegebene Zugriffsrechte

Das Aktensystem MUSS alle in der folgenden Tabelle aufgeführten Regeln der Legal Policy bei jedem Zugriff auf Daten und Dienste des Aktenkontos durchsetzen.

Tabelle 20: Legal Policy

• Med = Arztpraxis, Zahnarztpraxis, Krankenhaus, Psychotherapeut, Vorsorge- und Rehabilitation, Öffentlicher Gesundheitsdienst
• (oid_praxis_arzt,, oid_krankenhaus, oid_institution-vorsorge-reha, oid_zahnarztpraxis, oid_praxis_psychotherapeut oid_institution-oegd)
• Apo = Öffentliche Apotheke
• (oid_öffentliche_apotheke)
• Pflege = Gesundheits-, Kranken- und Altenpflege
• (oid_institution-pflege)
• GH = Geburtshilfe
• (oid_institution-geburtshilfe)
• HME = Heilmittelerbringer
• (oid_praxis-physiotherapeut, oid_praxis-ergotherapeut, oid_praxis-logopaede, oid_praxis-podologe, oid_praxis-ernaehrungstherapeut)
• AM = Arbeitsmedizin
• (oid_institution-arbeitsmedizin)
• KTR = Kostenträger
• (oid_kostentraeger)
• OM = Ombudsstelle
• (oid_ombudsstelle)
• DiGA = Digitale Gesundheitsanwendung
• (oid_diga)
• eRP = E-Rezept vertrauenswürdige Ausführungsumgebung 
• (oid_erp-vau)
• Ver = Versicherter / Vertreter
  
• (oid_versicherter)

• CRUD = create, read, update, delete; update: Aktualisierung von Metadaten, Aktualisierung eines Dokuments
• "-" = keine Zugriffsrechte;
• "x" - grundsätzliches Zugriffsrecht (detaillierte Zugriffsausprägung wird durch den Dienst (Service) definiert)
• "nicht belegt" - diese Kategorie wird nicht verwendet und ist absichtlich unbelegt
• "reserviert für zukünftige Anwendung" - diese Kategorie ist für eine Verwendung in einer zukünftigen Version der ePA vorgesehen.

• (*) Der Einsteller einer Elternnotiz eines Kinderuntersuchungshefts kann der Versicherte bzw. sein Vertreter oder eine Leistungserbringerinstitution gemäß der zuvor genannten Liste definierter professionOIDs sein. Sofern ein Versicherter/Vertreter der Einsteller der Elternnotiz ist, darf er abweichend von den oben aufgeführten Zugriffsunterbindungsregeln in die Datenkategorie mit dem technischen Identifier 'child' schreiben.

A_26166-01 - Legal Policy (EU) – EU-Zugriff: gesetzlich vorgegebene Zugriffsrechte

Das Aktensystem MUSS zusätzlich zu den Regeln aus A_19303-* alle in der folgenden Tabelle aufgeführten Regeln der Legal Policy bei jedem Zugriff auf Daten und Dienste des Aktenkontos durchsetzen.

Tabelle 21: Legal Policy - EU-Zugriff

• NCPeH = NCPeH-Fachdienst (oid_ncpeh)

• CRUD = create, read, update, delete; update: Aktualisierung von Metadaten, Aktualisierung eines Dokuments
• "-" = keine Zugriffsrechte;
• "x" - grundsätzliches Zugriffsrecht (detaillierte Zugriffsausprägung wird durch den Dienst (Service) definiert)
• "nicht belegt" - diese Kategorie wird nicht verwendet und ist absichtlich unbelegt
• "reserviert für zukünftige Anwendung" - diese Kategorie ist für eine Verwendung in einer zukünftigen Version der ePA vorgesehen.

A_21211-01 - Legal Policy - Änderungen der Legal Policy nicht erlauben

Das Aktensystem MUSS durch technische Maßnahmen sicherstellen, dass Änderungen der Konfiguration der Legal Policy gemäß A_19303-* ausgeschlossen sind. [<=]

A_24548 - Legal Policy - Durchsetzung der Zugriffsrechte der Legal Policy

Das Aktensystem MUSS sicherstellen, dass Operationen auf Daten und Operationen der Dienste eines Aktenkontos abgebrochen und mit einer Fehlermeldung beendet werden, wenn diese Operation durch die Vorgaben der Legal Policy gemäß A_19303-* für die Nutzergruppe des Aufrufers der Operation nicht zulässig ist. [<=]

A_24306-02 - Constraint Management - Policy für berechtigte Nutzergruppen und Nutzer

Das Constraint Management MUSS die Konfiguration der General Deny Policy auf die folgenden Nutzergruppen einschränken:

A_24390-01 - Constraint Management- Anwendung der General Deny Policy

Das Constraint Management MUSS bei jedem Zugriff auf Daten durch den XDS Document Service durch befugte Nutzer oder Nutzergruppen die General Deny Policy anwenden und den Zugriff verhindern, wenn ein Dokument oder dessen assoziierter Ordner oder dessen assoziierte Datenkategorie in der Policy konfiguriert ist.
[<=]

A_24395 - Constraint Management - Realisierung der Schnittstelle I_Constraint_Management_Insurant

Das Constraint Management MUSS die Operationen der Schnittstelle I_Constraint_Management_Insurant gemäß [I_Constraint_Management_Insurant] umsetzen. [<=]

A_24887-01 - Constraint Management - Protokolleinträge für Zugriffe auf das Constraint Management

Das Constraint Management MUSS für das Aufnehmen und Löschen von Einträgen in die General Deny Policy jeweils einen Protokolleintrag gemäß A_24704* erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 23: Constraint Management Protokollierung

A_24393-01 - Constraint Management - Initialisierung der General Deny Policy

Das Constraint Management MUSS für ein Aktenkonto eine General Deny Policy ohne initiale Einträge, bereitstellen und die Konfiguration der Einträge der Policy über die Schnittstelle I_Constraint_Management_Insurant gemäß [I_Constraint_Management_Insurant] ermöglichen. [<=]

A_24462-01 - Constraint Management - Konfiguration der General Deny Policy anpassen nach Löschen von Ordnern

Das Constraint Management MUSS Einträge aus der General Deny Policy entfernen, wenn diese einen Ordner referenzieren und dieser Ordner aus dem Aktenkonto gelöscht wird. [<=]

A_24461-01 - Constraint Management - Konfiguration der General Deny Policy anpassen nach Löschen von Dokumenten

Das Constraint Management MUSS Einträge aus der General Deny Policy entfernen, wenn diese ein spezifisches Dokument referenzieren und dieses Dokument aus dem Aktenkonto gelöscht wird. [<=]

A_24516-01 - Constraint Management - Speichern der Inhalte der General Deny Policy

Das Constraint Management MUSS Einträge aus der General Deny Policy unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_24828 - Device Management - Realisierung der Schnittstelle I_Device_Management_Insurant

Das Device Management MUSS die Operationen der Schnittstelle I_Device_Management_Insurant gemäß [I_Device_Management_Insurant] umsetzen. [<=]

A_25164 - Device Management - Beschränkung der Schnittstellenoperationen auf Geräte des Nutzers

Das Device Management MUSS die Operationen der Schnittstelle I_Device_Management_Insurant gemäß [I_Device_Management_Insurant] auf die Geräte des aufrufenden Nutzers einschränken. [<=]

A_26153 - Device Management - Nutzen von Device Management auch bei Widerspruch gegen Aktenkonto

Das Device Management MUSS sicherstellen, dass das Device Management auch von Versicherten genutzt werden kann, die einem Aktenkonto widersprochen haben. [<=]

A_26154 - ePA-Aktensystem - Ausschließlich Nutzen von Email Management und Device Management bei Widerspruch

Das ePA-Aktensystem MUSS sicherstellen, dass Versicherte, die einem Aktenkonto widersprochen haben, ausschließlich das Email Management und das Device Management nutzen können. [<=]

A_26155 - Device Management - Versicherte nutzen Device Management ausschließlich im Home-AS

Das Device Management des ePA-Aktensystems MUSS sicherstellen, dass das Device Management ausschließlich von Versicherten genutzt werden kann, für die das ePA-Aktensystem das Home-AS ist. [<=]

A_24979 - Device Management - Sicheres Löschen von Geräten

Das Device Management MUSS beim Entfernen eines Gerätes sicherstellen, dass das Gerät gelöscht ist und dass das Gerät nicht mehr als verifiziertes Gerät genutzt werden kann.   [<=]

A_17947-03 - Device Management - Gültigkeitszeitraum und Löschung der Devicekennung

Das Device Management MUSS jede generierte und zu einem Nutzer gespeicherte Geräteregistrierung nach 2 Jahren löschen und darf Nutzeranfragen mit dieser Device-Kennung nach diesem Zeitpunkt nicht mehr akzeptieren.
[<=]

A_14595-02 - Device Management - Pflegeprozess Geräteverwaltung

Das Device Management MUSS die interne Liste aller bekannten Geräte derart pflegen, dass ein Gerät nach spätestens 1 Jahr nach der letzten Nutzung des Gerätes automatisch aus der Liste der registrierten Geräte gelöscht wird. [<=]

A_25270 - Device Management - Erzeugung von Geräteinformationen und Geräteregistrierungscode bei der Geräteregistrierung

Das Device Management MUSS bei der Geräteregistrierung für das zu registrierende Gerät eines Nutzers

• einen deviceIdentifier als aktensystemweit eindeutigen Gerätebezeichner (uuid),
  
• ein deviceToken als eine Zufallszahl als String mit 64 Zeichen mit einer Mindestentropie von 120 Bit gemäß [gemSpec_Krypt#GS-A_4367] und
  
• eine zufällige sechsstellige natürliche Zahl als Geräteregistrierungscode

A_25271-01 - Device Management - Speicherung der Geräteinformationen

Das Device Management MUSS bei einer Geräteregistrierung eines Geräts eines Nutzers folgende Inhalte für den Nutzer verschlüsselt persistieren:

• decviceIdentifier
• deviceToken
• createdAt (Zeitpunkt der Erzeugung des deviceTokens)
• lastUse
  
• status
• displayName
• Geräteregistrierungscode,
• Fehlerzähler.

A_25272 - Device Management - Pseudonyme Speicherung der Geräteinformationen

Das Device Management MUSS sicherstellen, dass die Zuordnung der außerhalb der VAU persistierten verschlüsselten Geräteinformationen zum Nutzer eindeutig ist und durch ein Pseudonym erfolgt. [<=]

A_25273 - Device Management - Gültigkeitsdauer des Geräteregistrierungscodes

Das Device Management MUSS sicherstellen, dass der bei der Geräteregistrierung erzeugte Geräteregistrierungsscode maximal 6 Stunden nach Erzeugung der DeviceID (createdAt) für die Verifikation eines Gerätes genutzt werden kann. [<=]

A_25274 - Device Management - Löschen nach Gültigkeitsdauer des Geräteregistrierungscodes

Das Device Management MUSS sicherstellen, dass die Geräteinformationen für eine nicht bestätigte Geräteregistrierung nach Ende der Gültigkeitsdauer des Geräteregistrierungscodes gelöscht werden. [<=]

A_25275 - Device Management - Versenden des Geräteregistrierungscodes per E-Mail

Das Device Management MUSS bei der Geräteregistrierung für den Nutzer, für den das Gerät registriert werden soll, alle im Aktensystem hinterlegten E-Mail-Adressen ermitteln und an alle ermittelten E-Mail-Adressen eine E-Mail in einer für den Nutzer verständlichen Form mit folgenden Informationen versenden:

• Zweck der E-Mail,
• Geräteregistrierungsscode,
• Gültigkeitsdauer des Geräteregistrierungscodes.

A_25276 - Device Management - Bestätigung mittels Geräteregistrierungscodes

Das Device Management MUSS für einen übergebenen Geräteregistrierungscode und eine übergebene DeviceID (deviceIdentifier und deviceToken) prüfen, ob der vom Device Management bei der Geräteregistrierung erzeugte Geräteregistrierungscode für das angegebene Gerät (deviceIdentifier, deviceToken) mit dem übergebenen Geräteregistrierungscode übereinstimmt sowie der Geräteregistrierungscode zeitlich gültig ist und

1. bei Gleichheit und
1. zeitlicher Gültigkeit
• den Status für die Geräteregistrierung wechseln, so das die erfolgreiche Bestätigung des Geräts aus dem Status hervorgeht,
• den Geräteregistrierungscode und den Fehlerzähler aus den Geräteinformationen löschen und
• den Zeitpunkt der erfolgreichen Bestätigung in lastUsed erfassen,
2. zeitlicher Ungültigkeit
• alle Geräteinformationen zu diesem deviceIdentifier löschen,
2. bei Ungleichheit den Fehlerzählerder Geräteinformation um eins erhöhen und
• falls der Fehlerzähler größer oder gleich fünf ist,
• alle Geräteinformationen zu diesem Gerät löschen.

A_25277 - Device Management - Sperrung bei vermehrter Anzahl von abgebrochenen Geräteregistrierungen

Falls für einen Nutzer innerhalb von 8 Stunden drei Geräteregistrierungen abgebrochen werden mussten, MUSS das Device Management sicherstellen, dass dieser Nutzer für 8 Stunden ab dem Zeitpunkt der dritten abgebrochenen Geräteregistrierung keine Geräte mehr registrieren darf. [<=]

A_25291 - ePA-Aktensystem - Health Record Context nur mit verifizierten Gerät

Das ePA-Aktensystem MUSS sicherstellen, dass ein Versicherter (auch wenn er als Vertreter agiert) einen Health Record Context ausschließlich mit einem verifizierten Gerät öffnen kann, außer für den Fall, dass sich der Versicherte am ePA-FdV des Vertreters anmeldet (d.h. x-authorize-representative=True bei der Operation I_Authorization_Service::sendAuthorizationRequestFdV). [<=]

A_26157 - Device Management - Device Attestation kann nur mit verifiziertem Gerät abgerufen werden

Das Device Management MUSS sicherstellen, dass die Operation getDeviceAttestation ausschließlich nach erfolgreicher Authentifizierung des Nutzers und mit einem auf den Nutzer registrierten und verifizierten Gerät erfolgt.
[<=]

A_26156 - Device Management - Inhalte der Device Attestation

Das Device Management MUSS sicherstellen, dass eine von einem ePA-FdV über die Operation getDeviceAttestation abgerufene Device Attestation folgende Inhalte enthält:

A_26158 - Device Management - Signatur der Device Attestation

Das Device Management MUSS sicherstellen, dass die über getDeviceAttestation abgerufene Device Attestation mit dem privaten Schlüssel der Signaturidentität der VAU des Home-AS signiert wird. [<=]

A_25830-02 - Medical Services - Reihenfolge der Auswertung Legal Policy, Consent Decisions und Constraints

Die Medical Services MÜSSEN bei der Ausführung von Operationen der Schnittstellen der Medical Services sicherstellen, dass die Prüfung zu Bedingungen

1. der Einschränkung der Rolle des Aufrufenden (oid),
2. der Existenz des Aktenkontos (Status UNKNOWN oder INITIALIZED),
3. des Zustands des Aktenkontos (Status ACTIVATED),
4. der Befugnis des Aufrufenden,
5. der Legal Policy,
6. der Entscheidungen zu widerspruchsfähigen Funktionen der ePA,
7. der Einträge der General Deny Policy
8. des Entscheidungen zum nutzerspezifischen Ausschluss von der Teilnahme am digital  gestützten Medikationsprozess

A_25233 - XDS Document Service - erlaubte Formate für PDF-Dokumente

Der XDS Document Service MUSS sicherstellen, dass ausschließlich die folgenden PDF/A-Formate unterstützt werden:

• PDF/A-1a
• PDF/A-1b
• PDF/A-2a
• PDF/A-2u
• PDF/A-2b

A_24864-02 - XDS Document Service - Prüfen auf zulässiges Format beim Einstellen von Dokumenten

Der XDS Document Service MUSS beim Einstellen eines Dokumentes prüfen, dass das Dokument eines der folgenden MIME-Type-Formate (DocumentEntry.mimeType) und den in Klammern angegebenen Dateiendungen (DocumentEntry.URI) besitzt

• application/pdf nur PDF/A gemäß A_25233 (pdf)
  
• image/jpeg (jpeg oder jpg)
• image/png (png)
• image/tiff (tiff)
• text/plain (txt)
• application/xml (xml)
• application/hl7-v3 (xml)
  
• application/pkcs7-mime (p7)
  
• application/fhir+xml (xml)
  
• application/fhir+json (json)
• application/json (json)

A_25009-02 - XDS Document Service - Prüfen auf zulässiges Format beim Einstellen von Dokumenten durch Versicherte

Der XDS Document Service MUSS sicherstellen, dass Versicherte ausschließlich Dokumente eines der folgenden MIME-Type-Formate (DocumentEntry.mimeType) und den in Klammern angegebenen Dateiendungen (DocumentEntry.URI) einstellen können:

• application/pdf nur PDF/A gemäß A_25233 (pdf)
  
• image/jpeg (jpeg oder jpg)
• image/png (png)
• image/tiff (tiff)
• text/plain (txt)
• application/fhir+xml (xml).
• application/json (json)

A_24867 - XDS Document Service - Isolation der Formatprüfung

Der XDS Document Service MUSS die Prüfung des Dateiformats (siehe A_24864-*) beim Einstellen eines Dokuments so technisch isolieren, dass kein Schaden für Aktenkonten oder das ePA-Aktensystem selbst entsteht.
[<=]

A_25285 - XDS Document Service - Sicheres Löschen von Dokumenten mit unzulässigem Format

Falls der XDS Document Service bei der Prüfung des Dateiformats (siehe A_24864-*) beim Einstellen eines Dokuments ein unzulässiges Format erkennt, MUSS der XDS Document Service das Dokument sicher löschen.
[<=]

A_24943 - XDS Document Service - Formatprüfung exponiert keine Daten aus der VAU heraus

Der XDS Document Service MUSS sicherstellen, dass bei der Formatprüfung (siehe A_24864-*) keine innerhalb der VAU verarbeiteten Daten die VAU verlassen. [<=]

A_15035 - XDS Document Service – Verwendung von SOAP Message Security 1.1

Der XDS Document Service MUSS die Sicherheitsanforderungen aus SOAP Message Security 1.1 [WSS] für die Verarbeitung von SOAP 1.2-Nachrichten umsetzen. [<=]

A_15034 - XDS Document Service – Unterstützung von Profilen der Web Services Interoperability Organization (WS-I)

Der XDS Document Service MUSS das WS-I Basic Profile V2.0 [WSIBP], das WS-I Basic Security Profile Version V1.1 [WSIBSP] sowie das WS-I Attachment Profile V1.0 [WSIAP] für die Kommunikation über Web Services berücksichtigen. [<=]

A_15186 - XDS Document Service – Prüfung der Kombination von WS-Addressing Action und SOAP Body

Der XDS Document Service MUSS vor einer Weiterverarbeitung sämtliche SOAP 1.2-Eingangsnachrichten dahingehend prüfen, ob die angegebene WS-Addressing Action zum SOAP Body passt. Ist diese Kombination nicht passend, MUSS der XDS Document Service die Nachricht mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren und die Verarbeitung der Nachricht abbrechen. [<=]

A_15585 - XDS Document Service – Gleichheit von SOAP Action und WS-Addressing Action

Der XDS Document Service MUSS SOAP 1.2-Eingangsnachrichten mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren und die Verarbeitung der Nachricht abbrechen, falls die Werte aus SOAP Action (HTTP Header) und des Action-Elements [WSA] des SOAP Headers nicht übereinstimmen. [<=]

A_14465-01 - XDS Document Service – XML Schema-Validierung für SOAP-Eingangsnachrichten

Der XDS Document Service MUSS vor einer Weiterverarbeitung sämtliche SOAP 1.2-Eingangsnachrichten einer XML Schema-Validierung auf Basis ausschließlich intern vorliegender XML Schema-Definitionen unterziehen und gemäß [SOAP] verarbeiten. Sind Nachrichten nicht wohlgeformt oder ungültig, MUSS der XDS Document Service die Nachricht mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren. [<=]

A_14809 - XDS Document Service – Keine Verwendung des "xsi:schemaLocation"-Attributs

Der XDS Document Service MUSS SOAP 1.2-Eingangsnachrichten mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren, falls ein xsi:schemaLocation-Attribut gemäß [XMLSchema#2.6.3] enthalten ist.  [<=]

A_14811-01 - XDS Document Service – Ablehnung von SOAP 1.2-Nachrichten ohne UTF-8 Kodierung

Der XDS Document Service MUSS SOAP 1.2-Nachrichten dahingehend prüfen, dass diese der Zeichenkodierung UTF-8 entsprechen, und andernfalls die Operation einem geeigneten HTTP-Statuscode gemäß [RFC7231] ablehnen. [<=]

A_21200 - XDS Document Service und Clients – UTF-8 Kodierung von SOAP 1.2-Nachrichten

Der XDS Document Service und Clients des XDS Document Service MÜSSEN sicherstellen, dass die XML-Inhalte der SOAP 1.2-Nachrichten, die sie senden, der Zeichenkodierung UTF-8 entsprechen.<= [<=]

A_17826-01 - XDS Document Service – Außenverhalten der IHE ITI-Implementierung

Der XDS Document Service DARF NICHT vom Verhalten der definierten Außenschnittstellen I_Document_Management,  sowie I_Document_Management_Insurant aus Abschnitt 3.13.1.6 Schnittstellen im XDS Document Service abweichen. Dies schließt über die Anforderungslage hinausgehende Implementierungen von IHE ITI-Akteuren und Optionen innerhalb des XDS Document Service mit ein, sodass zusätzlich implementierte IHE-Funktionalitäten keine Auswirkungen an den definierten Außenschnittstellen aufweisen dürfen. [<=]

A_13806 - XDS Document Service – Implementierung des IHE ITI-Akteurs XDS Document Registry

Der XDS Document Service MUSS den IHE ITI-Akteur "XDS Document Registry" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14727 - XDS Document Service – Implementierung des IHE ITI-Akteurs XDS Document Repository

Der XDS Document Service MUSS den IHE ITI-Akteur "XDS Document Repository" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_13809 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs ATNA Audit Record Repository

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "ATNA Audit Record Repository" gemäß [IHE-ITI-TF1] implementieren.  [<=]

A_17166 - XDS Document Service – Keine Implementierung der IHE ITI-Akteure ATNA Secure Node sowie ATNA Secure Application für Node Authentication

Der XDS Document Service DARF zur Node Authenticaton die IHE ITI-Akteure "ATNA Secure Node" sowie "ATNA Secure Application" gemäß [IHE-ITI-TF1] NICHT implementieren.  [<=]

A_14654 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs CT Time Client

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "CT Time Client" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14665 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs XDS Document Source

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "XDSDocument Source" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14667 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs XDS Integrated Document Source/Repository

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "XDS Integrated Document Source/Repository" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14668 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs XDS Document Consumer

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "XDS Document Consumer" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14666 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs XDS Patient Identity Source

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "XDS Patient Identity Source" gemäß [IHE-ITI-TF1] implementieren.
[<=]

A_14669 - XDS Document Service – Keine Implementierung des IHE ITI-Akteurs XDS On-Demand Document Source

Der XDS Document Service DARF NICHT den IHE ITI-Akteur "XDS On-Demand Document Source" gemäß [IHE-ITI-TF1] implementieren. [<=]

A_14950 - XDS Document Service – Keine Angabe einer Fehlerlokalisierung im RegistryError-Element

Der XDS Document Service DARF NICHT das location-Attribut im rs:RegistryError-Element in der IHE ITI-Ausgangsnachricht verwenden, sofern ein Fehler bei der Verarbeitung einer IHE ITI-Eingangsnachricht auftritt. Diese Einschränkung gilt nur für Error Stack Traces bzw. der Offenbarung von Programmierdetails. [<=]

A_15081 - XDS Document Service – Implementierung des IHE ITI-Akteurs RMU Update Responder

Der XDS Document Service MUSS den IHE ITI-Akteur "RMU Update Responder" gemäß [IHE-ITI-RMU] implementieren. [<=]

A_15093-02 - XDS Document Service – Gruppierung RMU Update Responder mit Document Registry

Der XDS Document Service als RMU-Akteur "Update Responder" MUSS mit dem XDS-Akteur "Document Registry" gemäß [IHE-ITI-RMU] gruppiert sein. [<=]

A_15094 - XDS Document Service – RMU Update Responder ohne "Forward Update"-Option

Der XDS Document Service als RMU-Akteur "Update Responder" DARF NICHT die Option "Forward Update" unterstützen.
[<=]

A_15095-02 - XDS Document Service – RMU Update Responder ohne "XCA Persistence"-Option

Der XDS Document Service als RMU-Akteur "Update Responder" DARF NICHT die Option "XCA Persistence" unterstützen. [<=]

A_15096-02 - XDS Document Service – RMU Update Responder mit "XDS Persistence"-Option

Der XDS Document Service als RMU-Akteur "Update Responder" MUSS die Option "XDS Persistence" unterstützen. [<=]

A_15097 - XDS Document Service – RMU Update Responder ohne "XDS Version Persistence"-Option

Der XDS Document Service als RMU-Akteur "Update Responder" DARF NICHT die Option "XDS Version Persistence" unterstützen. [<=]

A_14637 - XDS Document Service – XDS Document Registry ohne "Asynchronous Web Services Exchange"-Option

Der XDS Document Service als XDS-Akteur "Document Registry" DARF NICHT die Option "Asynchronous Web Services Exchange" unterstützen. [<=]

A_14638 - XDS Document Service – XDS Document Registry mit "Reference ID"-Option

Der XDS Document Service als XDS-Akteur "Document Registry" MUSS die Option "Reference ID" unterstützen. [<=]

A_14639 - XDS Document Service – XDS Document Registry ohne "Patient Identity Feed"-Option

Der XDS Document Service als XDS-Akteur "Document Registry" DARF NICHT die Option "Patient Identity Feed" unterstützen.
[<=]

A_14640 - XDS Document Service – XDS Document Registry ohne "Patient Identity Feed HL7v3"-Option

Der XDS Document Service als XDS-Akteur "Document Registry" DARF NICHT die Option "Patient Identity Feed HL7v3" unterstützen. [<=]

A_14641 - XDS Document Service – XDS Document Registry ohne "On-Demand Documents"-Option

Der XDS Document Service als XDS-Akteur "Document Registry" DARF NICHT die Option "On-Demand Documents" unterstützen. [<=]

A_14636 - XDS Document Service – XDS Document Repository ohne "Asynchronous Web Services Exchange"-Option

Der XDS Document Service als XDS-Akteur "Document Repository" DARF NICHT die Option "Asynchronous Web Services Exchange" unterstützen. [<=]

A_17832 - XDS Document Service – Unterstützung MTOM/XOP

Der XDS Document Service MUSS gemäß den Anforderungen von [IHE-ITI-TF2x#V.3.6] zur Übertragung von Dokumenten eine Kodierung mittels MTOM/XOP [MTOM] verwenden. [<=]

A_24524 - XDS Document Service - Migration, Upload: Normalisieren des URI

Der XDS Document Service MUSS bei jedem Upload von Dokumenten oder Metadaten den DocumentEntry.URI normalisieren. Dies gilt für FileURI, z. B. “file:///C/path/to/file/#anchor” oder “/C/path/to/file.html#anchor”. Die URI MUSS auf den reinen Dateinamen mit Extension (d. h. ohne Pfadangaben) reduziert werden, z. B. "file.html". Nach der Normalisierung MUSS eine Validierung der Extension gemäß A_23447-* erfolgen. [<=]

A_23447-01 - XDS Document Service - DocumentEntry.URI extension entspricht mimetype

Der XDS Document Service MUSS bei jedem Upload von Dokumenten oder Metadaten das Metadatum DocumentEntry.URI daraufhin prüfen, ob DocumentEntry.URI eine filename extension aufweist, die nicht dem DocumentEntry.mimetype entspricht. Zuvor muss die URI mittels A_24524-* normalisiert worden sein. Danach MUSS der XDS Document Service sicherstellen, dass in Document.URI die filename extension dem DocumentEntry.mimeType entspricht. Im Falle einer Abweichung MUSS an die ursprüngliche DocumentEntry.URI die filename extension gemäß A_24864*, bzw. A_25009*, angehängt werden, die dem mimeType entspricht. Die Groß-/Kleinschreibung der filename extension ist bei der Prüfung nicht relevant. [<=]

A_24451-01 - XDS Document Service - Automatisches initales Erzeugen einer versionsübergreifenden ID für Dokumente

Der XDS Document Service MUSS beim initialen Einstellen eines Dokumentes die DocumentEntry.uniqueId als Eintrag einer ReferenceID in die ReferenceIDList in folgendem Format einstellen:
<DocumentEntry.uniqueId>^^^^urn:gematik:iti:xds:2023:rootDocumentUniqueId
Beim Upload einer neuen Version des Dokumentes DARF dieser Eintrag in der ReferenceIDList, d.h. die rootDocumentUniqueId,  NICHT verändert werden. Er bleibt über alle Versionen des Dokumentes hinweg unverändert erhalten. Der Versuch eines Clients, die rootDocumentUniqueId durch ein Metadata-Update oder im Zuge des Einstellens einer neuen Dokumentenversion zu verändern, MUSS mit einem IHE-Error XDSRegistryMetadataError abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRegistryMetadataError-Elements der Text „rootDocumentUniqueId must not be changed“ zurückgegeben werden. [<=]

A_14926-03 - XDS Document Service – Automatisiertes Löschen oder Verbergen von Dokumenten

Der XDS Document Service MUSS bei zu löschenden oder zu verbergenden Dokumenten und DocumentEntry-Einträgen im selben Zuge auch alle assoziierten DocumentEntry-Einträge und Dokumente löschen bzw. verbergen. [<=]

A_13715 - XDS Document Service – Ablauflogik für ProvideAndRegisterDocumentSet-b

Der XDS Document Service MUSS die Umsetzung der Operation ProvideAndRegisterDocumentSet-b gemäß den definierten Ablauflogiken in [IHE-ITI-TF2b#3.41.4.1.2 und 3.41.4.1.3 ] und [IHE-ITI-TF2b#3.41.4.2.2 und 3.41.4.2.3 ] implementieren. [<=]

A_15162-05 - XDS Document Service – Keine Registrierung bei Angabe von Document Entry Relationships in Metadaten

Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError-Fehlercode quittieren, sofern die Metadaten andere Association Types nach [IHE-ITI-TF3#4.2.2.2] als die Folgenden enthalten: 

• urn:ihe:iti:2007:AssociationType:RPLC (Replace)
• urn:ihe:iti:2007:AssociationType:APND (Append).

A_14938-02 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen

Der XDS Document Service MUSS die SubmissionSet- sowie die DocumentEntry-Metadaten der eingehenden Nachricht vor einer Zugriffskontrolle gemäß Konformität zu den Nutzungsvorgaben in [A_14760-*] prüfen. Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden, welches Metadatenattribut nicht den Nutzungsvorgaben entspricht. [<=]

A_23538-01 - XDS Document Service - vereinfachte Prüfung der Metadaten in DocumentEntry.eventCodeList

Der XDS Document Service KANN einen eventCode in DocumentEntry.eventCodeList ohne eine Prüfung, ob dieser eventCode im angegebenen Code System enthalten ist, akzeptieren, wenn das angegebene Code System eines der folgenden ist:

• ICD10gm (urn:oid:1.2.276.0.76.5.518)
• OPS (urn:oid:1.2.276.0.76.5.519)
• KDL (urn:oid:1.2.276.0.76.5.552).

A_23123 - XDS Document Service – APND-Assoziation mit existierenden Dokument oder Dokument aus SubmissionSet

Der XDS Document Service MUSS bei APND-Assoziationen sowohl Verknüpfungen auf ein existierendes Dokument im Status "Approved" als auch auf ein Dokument aus dem übergebenen SubmissionSet ermöglichen. [<=]

A_23124 - XDS Document Service – Addendum nur mit einem Dokument verknüpfen

Der XDS Document Service DARF ein Addendum NICHT mit mehr als einem Dokument verknüpfen. [<=]

A_23125 - XDS Document Service – Kein automatisches "Deprecated" des Addendums

Der XDS Document Service DARF abweichend von [IHE-ITI-TF3#4.2.2.2.3] einem Addendum NICHT den availabilityStatus = Deprecated zuweisen, wenn das verknüpfte Dokument den availabilityStatus Depracated erhält. [<=]

A_24521 - XDS Document Service - Erzeugen von Prüfsummen für Dokumente

Der XDS Document Service MUSS beim Einstellen von Dokumenten in die Akte für jedes Dokument seine kryptographische Prüfsumme berechnen und in DocumentEntry.hash hinterlegen. Dabei MUSS SHA-256 verwendet werden. Außerdem MUSS die Dokumentengröße in DocumentEntry.size berechnet und gesetzt werden. [<=]

A_24988 - XDS Document Service - Dublettenprüfung für Dokumente

Der XDS Document Service MUSS beim Einstellen von Dokumenten in die Akte für jedes Dokument den hash-Wert vergleichen mit allen bereits in dieser Akte existierenden hash-Werten der Dokumente und bei einer Übereinstimmung das Einstellen mit dem Fehlercode XDSDuplicateDocument ablehnen. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die Liste der UUIDs (DocumentEntry.entryUUID) der identifizierten Dokumente angegeben werden. [<=]

A_24990 - XDS Document Service - Dublettenprüfung für dynamische Ordner

Der XDS Document Service MUSS beim Anlegen dynamischer Folder prüfen, ob ein Ordner bereits existiert, der gemäß vom Titel her identisch ist mit demjenigen, den der Client einzustellen versucht. Im Falle eines identischen Titels MUSS der Einstellversuch mit dem Fehlercode XDSDuplicateFolder abgelehnt werden. [<=]

A_14937 - XDS Document Service – Dokumentengröße prüfen

Der XDS Document Service MUSS die Dateigröße jedes übergebenen Dokuments ermitteln, bevor das SubmissionSet verarbeitet wird. Der XDS Document Service MUSS die Verarbeitung ablehnen und mit einem MaxDocSizeExceeded- bzw. MaxPkgSizeExceeded-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren, wenn die Gesamtgröße aller übermittelten Dokumente 250 MByte übersteigt oder die Größe mindestens eines einzelnen Dokuments 25 MByte übersteigt.
[<=]

A_23098-01 - XDS Document Service – Keine Registrierung bei zeitlicher Ungültigkeit von strukturierten Dokumenten

Der XDS Document Service MUSS beim Einstellen eines strukturierten Dokuments sicherstellen, dass die Vorgaben gemäß [gemSpec_IG_ePA] hinsichtlich der zeitlichen Gültigkeit erfüllt werden und andernfalls das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRepositoryMetadataError-Elements der Text „Version of submitted structured document is not supported“ zurückgegeben werden. [<=]

A_21610-03 - Sonderfälle Anlegen von Foldern durch Clientsysteme

Der XDS Document Service MUSS sicherstellen, dass ausschließlich dynamische Ordner vom Typ "Schwangerschaft und Geburt" (Folder.Code = pregnancy_childbirth) durch Clients angelegt werden können. [<=]

A_22400-01 - XDS Document Service - Ablehnung Upload bei abweichenden confidentialityCode

Der XDS Document Service MUSS Uploads, die als Resultat einen uneinheitlichen documentEntry.confidentialityCode über alle Dokumente in einer mixed- oder uniform-Sammlung haben, mit einem XDSRegistryMetadataError ablehnen. [<=]

A_24797-02 - XDS Document Service - Ablehnung Upload bei veränderten Metadaten bei einer RPLC Assoziation

Der XDS Document Service MUSS Uploads, die als Resultat ein zum Vorgängerdokument verändertes Metadatum enthalten, mit einem XDSRegistryMetadataError ablehnen. Einzige Ausnahmen sind die Metadatenattribute creationTime, entryUUID sowie uniqueId und confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491). [<=]

A_24531-03 - Constraint Management - Verbergen von Dokumenten durch confidentialityCode

Falls das Dokument, welches mit confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) durch eine Nutzergruppe der Rolle gemäß A_24306* oder oid_versicherter eingestellt wird, nicht Bestandteil einer Sammlung, also eines Ordners der Ausprägung "mixed" oder "uniform" ist, und kein Dokument der Kategorie "emp" ist, dann MUSS der XDS Document Service sicherstellen, dass das Dokument durch einen Eintrag in der General Deny Policy verborgen wird.  Es MUSS ein Eintrag mit denyType = "document" für die General Deny Policy erzeugt werden. [<=]

A_25856-01 - XDS Document Service - Fehlerhaftes Verbergen von Dokumenten durch confidentialityCode

Falls das Dokument, welches mit confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) nicht durch eine Nutzergruppe der Rolle gemäß A_24306* oder oid_versicherter eingestellt wird, oder Bestandteil einer Sammlung, also eines Ordners der Ausprägung "mixed" oder "uniform" ist, dann MUSS der XDS Document Service die Operation abbrechen und mit einem Fehlercode ConstraintViolation beenden. [<=]

A_14913 - XDS Document Service – Ablauflogik für Registry Stored Query

Der XDS Document Service MUSS die Umsetzung der Operation RegistryStoredQuery gemäß der definierten Ablauflogik in [IHE-ITI-TF2a#3.18.4.1.2 und 3.18.4.1.3 ] implementieren. [<=]

A_24761 - XDS Document Service – Ermitteln verknüpfter Approved Documents für Registry Stored Query

Der XDS Document Service MUSS einen zusätzlichen Anfragetyp "GetRelatedApprovedDocuments" mit der Query-ID "urn:uuid:1c1f1cea-ad3a-11ed-afa1-0242ac120002" mit denselben Parameternutzungsvorgaben der Registry Stored Query „GetDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.5] mit der Multiplizität 1 unterstützen. Das resultierende DocumentEntry Objekt MUSS 

• mit dem Ergebnis von GetDocuments übereinstimmen, falls dieses sich im Zustand approved befindet;
• andernfalls über Associations ermittelt werden. Dabei wird jeweils ausgehend von der übergebenen DocumentEntry.EntryUUID oder DocumentEntry.UniqueId über die Replace- Associations dasjenige DocumentEntry Objekt ermittelt, das sich im Zustand approved befindet.

A_24762 - XDS Document Service – Suchanfragen über das Metadatenattribut DocumentEntry.title

Der XDS Document Service MUSS einen zusätzlichen Anfragetyp "FindDocumentsByTitle" mit der Query-ID "urn:uuid:ab474085-82b5-402d-8115-3f37cb1e2405" und denselben Parameternutzungsvorgaben der Registry Stored Query "FindDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.1] sowie den weiteren verpflichtenden Suchparameter $XDSDocumentEntryTitle unterstützen, sodass eine Suchergebnismenge über das Attribut XDSDocumentEntry.title eingeschränkt werden kann. Weiterhin MUSS dieselbe Suchmusterlogik mittels Platzhalter implementiert sein, wie für Suchanfragen über den Parameter $XDSDocumentEntryAuthorPerson. Das wsa:Action-Element MUSS den Wert "urn:ihe:iti:2007:RegistryStoredQuery" besitzen. [<=]

A_25183 - XDS Document Service – Suchanfragen über das Metadatenattribut DocumentEntry.comment

Der XDS Document Service MUSS einen zusätzlichen Anfragetyp "FindDocumentsByComment" mit der Query-ID "urn:uuid:2609dda5-2b97-44d5-a795-3e999c24ca99" und denselben Parameternutzungsvorgaben der Registry Stored Query "FindDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.1] sowie den weiteren verpflichtenden Suchparameter $XDSDocumentEntryComment unterstützen, sodass eine Suchergebnismenge über das Attribut XDSDocumentEntry.comment eingeschränkt werden kann. Weiterhin MUSS dieselbe Suchmusterlogik mittels Platzhalter implementiert sein, wie für Suchanfragen über den Parameter $XDSDocumentEntryAuthorPerson. Das wsa:Action-Element MUSS den Wert "urn:ihe:iti:2007:RegistryStoredQuery" besitzen. [<=]

A_24763 - XDS Document Service – Suche über Author Institution bei Registry Stored Query

Der XDS Document Service MUSS für den Anfragetyp "FindDocumentsByTitle" den weiteren optionalen Parameter $XDSDocumentEntryAuthorInstitution verarbeiten können, sodass eine Suchergebnismenge über den authorInstitution-Slot der XDSDocumentEntry.author-Classification (Wertemenge des authorInstitution-Sub-Attributs) eingeschränkt werden kann. Weiterhin MUSS dieselbe Suchmusterlogik mittels Platzhalter implementiert sein, wie für Suchanfragen über den Parameter $XDSDocumentEntryAuthorPerson. [<=]

A_24764 - XDS Document Service – Rückgabe unscharfer Suchergebnisse für Registry Stored Query

Der XDS Document Service MUSS bei der Ermittlung der Ergebnisse einer Registry Stored Query bei Auswertung der folgenden Queries und deren Suchparametern beim Durchsuchen des dazugehörigen Suchfelds auch unscharfe, d. h. bezogen auf das jeweilige Suchfeld nicht nur exakt auf die Metadaten passende, sondern auch leicht abweichende Ergebnisse zurück liefern können:

• Query "FindDocuments" und Query "FindDocumentsByTitle" und Query "FindDocumentsByComment"
• $XDSDocumentEntryTitle
• $XDSDocumentEntryAuthorInstitution
• $XDSDocumentEntryAuthorPerson
• $XDSDocumentEntry.comment
• Query "FindSubmissionSets"
• $XDSSubmissionSetAuthorPerson

A_14908-02 - XDS Document Service – Ablauflogik für Remove Metadata

Der XDS Document Service MUSS die Umsetzung der Operation RemoveMetadata gemäß der definierten Ablauflogik in [IHE-ITI-RMD#3.62.4.1.2 und 3.62.4.1.3 ] implementieren. [<=]

A_20701 - XDS Document Service – Unwiderrufliches Löschen bei Remove Metadata

Der XDS Document Service MUSS sicherstellen, dass einmal gelöschte Dokumente und Metadatenobjekte nicht wiederhergestellt werden können. [<=]

A_21715 - XDS Document Service – Kein Löschen von "replaced"-Dokumenten im Status "Deprecated"

Der XDS Document Service MUSS sicherstellen, dass keine Löschanfrage eines ePA-Client auf Dokumenten mit dem  availabilityStatus = Deprecated ausgeführt werden darf. [<=]

A_21714-03 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein ePA-FdV

Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein ePA-FdV ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit dem XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Wert "Anfragenachricht darf ausschließlich entryUUID für Folder beinhalten" belegt werden. [<=]

A_21817-02 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein Primärsystem

Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein Primärsystem ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Wert "Anfragenachricht darf ausschließlich entryUUID für Folder beinhalten" belegt werden. [<=]

A_24663-01 - XDS Document Service – Bereinigung der General Deny Policy

Der XDS Document Service MUSS als Folge von erfolgreichen Löschanfragen alle Einträge der General Deny Policy entfernen, welche die betroffenen Dokumente oder dynamischen Ordner referenzieren. [<=]

A_24765 - XDS Document Service – Kein Löschen von statischen Ordnern und Associations

Der XDS Document Service MUSS sicherstellen, dass eine Löschanfrage keine statischen Ordner und Assoziationen löschen darf. Dies gilt nicht für dynamische Ordner. Der XDS Document Service MUSS bei Löschung eines Dokumentes die Assoziation zum Folder löschen. [<=]

A_20579-01 - XDS Document Service – Löschen von Ordnern

Der XDS Document Service MUSS Requests, die darauf abzielen, einen statischen Folder direkt zu löschen, mit einem XDSRegistryMetadataError ablehnen. [<=]

A_14914 - XDS Document Service – Ablauflogik für Retrieve Document Set

Der XDS Document Service MUSS die Umsetzung der Operation RetrieveDocumentSet gemäß den definierten Ablauflogiken in [IHE-ITI-TF2b#3.43.4.1.2 und 3.43.4.1.3 ] und [IHE-ITI-TF2b#3.43.4.2.2 und 3.43.4.2.3 ] implementieren. [<=]

A_16201 - XDS Document Service – Prüfung der zurückgegebenen Paketgröße

Der XDS Document Service MUSS anhand der übergebenen DocumentUniqueIDs die Gesamtgröße ermitteln und bei Überschreitung von 250 MByte die Verarbeitung ablehnen und die Nachricht mit einem MaxPkgSizeExceeded-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren. [<=]

A_15061-05 - XDS Document Service – Ablauflogik für Restricted Update Document Set

Der XDS Document Service MUSS die Umsetzung der Operation RestrictedUpdateDocumentSet gemäß der definierten Ablauflogik in [IHE-ITI-RMU#3.92.4.1.2 und 3.92.4.1.3] implementieren und sicherstellen, dass (nur) die folgenden Metadatenobjekte gesendet werden:

• ein neues SubmissionSet,
• einen DocumentEntry inklusive der entryUUDI des zu ändernden DocumentEntry-Objekts. Das übermittelte DocumentEntry-Objekt kann sowohl alle vollständigen Metadatenattribute als auch nur zu ändernde Metadatenattribute enthalten. In jedem Fall dürfen Änderungen ausschließlich gemäß A_15083-* angenommen und durchgeführt werden.
• eine SS-DE HasMember-Association, die das SubmissionSet mit dem geschickten DocumentEntry verbindet.
• Die „lid“ (logicalID) DARF NICHT gesendet werden.
• Der Slot "PreviousVersion" MUSS immer mit dem Wert "1" gesendet werden.
• Der Slot „associationPropagation“ MUSS auf „no“ gesetzt werden.

A_15082-02 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen

Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten die geänderten Metadaten konform zu den Nutzungsvorgaben in [A_14760-*] geändert werden. Der XDS Document Service MUSS das Aktualisieren der Metadatenattribute ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden, welches Metadatenattribut nicht den Nutzungsvorgaben entspricht. [<=]

A_15083-07 - XDS Document Service – Prüfung auf ausschließliche Aktualisierung der erlaubten Metadaten

Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten ausschließlich die folgenden Metadaten geändert werden:

• DocumentEntry.author
• DocumentEntry.classCode
• DocumentEntry.comments
• DocumentEntry.confidentialityCode  (confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) ist nicht erlaubt)
• DocumentEntry.creationTime
• DocumentEntry.eventCodeList
• DocumentEntry.formatCode
• DocumentEntry.healthcareFacilityTypeCode 
• DocumentEntry.languageCode
• DocumentEntry.legalAuthenticator
• DocumentEntry.practiceSettingCode
• DocumentEntry.referenceIdList
• DocumentEntry.serviceStartTime
• DocumentEntry.serviceStopTime
• DocumentEntry.title
• DocumentEntry.typeCode
• DocumentEntry.URI

A_21533 - XDS Document Service – Kein Anlegen von Versionen für Restricted Update Document Set

Der XDS Document Service DARF eine echte Versionierung NICHT umsetzen, d. h. er DARF den alten DocumentEntry NICHT speichern. Insbesondere DARF der XDS Document Service DocumentEntry.version NICHT anlegen und verwalten. [<=]

A_21783-03 - XDS Document Service - Vererbung der geänderten Metadaten für Restricted Update Document Set

Der XDS Document Service MUSS die neu gesetzten Metadaten ebenfalls auf alle mit dem geänderten Dokument assoziierten Dokumente setzen. Als assoziierte Dokumente sind im Sinne dieser Anforderung Dokumente einer RPLC-Kette zu betrachten. [<=]

A_25173 - XDS Document Service - Restricted Update Document Set nicht für MIOs

Falls die Operation RestrictedUpdateDocumentSet für Dokumente einer mixed- oder uniform-Sammlung aufgerufen wird MUSS der XDS Document Service das Aktualisieren der Metadatenattribute ablehnen, mit einem XDSRepositoryMetadataError quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "Metadata Update for MIOs not allowed" angeben.
[<=]

A_24508-01 - XDS Document Service – Prüfung der Policies bei Suchanfrage

Der XDS Document Service MUSS bei einer Suchanfrage für einen angemeldeten Nutzer die Suchergebnismenge entsprechend der Legal Policy und der General Deny Policy filtern, d. h. die Suchergebnismenge enthält ausschließlich XDS-Metadaten, die für einen angemeldeten Nutzer nicht diesen Policies widersprechen. [<=]

A_26222 - XDS Document Service (EU) – Prüfung Zugriffscode bei Suchanfrage EU-Zugriff

Der XDS Document Service MUSS für einen angemeldeten Nutzer mit der Rolle oid_ncpeh bei jeder Suchanfrage und jeder Retrieve-Operation prüfen, dass der im SOAP-Header der Operation übergebene Zugriffscode identisch ist mit dem im Entitlement Management für diesen Nutzer hinterlegten Zugriffscode und andernfalls die Operation mit dem Fehlercode AccessCodeViolation beenden. [<=]

A_24509 - XDS Document Service - Prüfung der Legal Policy außer Suchanfragen

Der XDS Document Service MUSS die Ausführung einer Operation mit dem Fehlercode LegalPolicyViolation beenden, wenn für den angemeldeten Nutzer die Regeln der Legal Policy nicht erfüllt sind und es sich nicht um eine Suchanfrage handelt.
Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die Liste der UUIDs (DocumentEntry.entryUUID) der identifizierten Dokumente angegeben werden. [<=]

A_24510-01 - XDS Document Service – Prüfung Herunterladen eines verborgenen Dokuments

Der XDS Document Service MUSS die Ausführung der Retrieve-Operation mit dem Fehlercode XDSDocumentUniqueIdError beenden, wenn für den angemeldeten Nutzer die Regeln der General Deny Policy nicht erfüllt sind. [<=]

A_24511-01 - XDS Document Service – Prüfung Löschen eines verborgenen Dokuments oder dynamischen Ordners

Der XDS Document Service MUSS die Ausführung der Remove-Operation mit dem Fehlercode XDSDocumentUniqueIdError beenden, wenn für den angemeldeten Nutzer die Regeln der General Deny Policy nicht erfüllt sind.
[<=]

A_24512-02 - XDS Document Service – Prüfung Schreiben eines Dokuments in einen nicht vorhandenen oder verborgenen dynamischen Ordner

Der XDS Document Service MUSS die Ausführung der Provide-Operation mit dem Fehlercode UnresolvedReferenceException beenden, wenn der Ordner nicht existiert oder für den angemeldeten Nutzer die Regeln der General Deny Policy nicht erfüllt sind. 
[<=]

A_24513-02 - XDS Document Service – Prüfung Aktualisierung Metadaten eines verborgenen oder nicht vorhandenen Dokuments

Der XDS Document Service MUSS die Ausführung der Update-Operation mit dem Fehlercode UnresolvedReferenceException beenden, wenn das assoziierte Dokument nicht vorhanden ist oder für den angemeldeten Nutzer die Regeln der General Deny Policy nicht erfüllt sind.  [<=]

A_22516-02 - XDS Document Service - Alternative Verwendung von XDSRegistryMetadataError anstelle von XDSRepositoryMetadataError

Der XDS Document Service  KANN alternativ zum Fehler "XDSRepositoryMetadataError" den Fehler "XDSRegistryMetadataError" verwenden. [<=]

A_23148-01 - XDS Document Service – Festlegung zu http-Statuscode bei IHE-Responses

Der XDS Document Service MUSS für den Fall, dass eine IHE-Response in der HTTP-Response enthalten ist, den http-Statuscode 200 zurückgeben. Das gilt auch, wenn die IHE-Response einen IHE-Fehler überträgt. [<=]

A_26324-01 - XDS Document Service - Aktenkonto im Umzug

Falls sich ein Aktenkonto im Zustand SUSPENDED befindet MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem StatusMismatch-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren.<= [<=]

A_26325-01 - XDS Document Service - Aktenkonto unbekannt oder im Zustand INITIALIZED

Falls sich ein Aktenkonto im Zustand UNKNOWN oder INITIALIZED befindet MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem NoHealthRecord-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren.<= [<=]

A_25683-01 - XDS Document Service - Prüfung auf Befugnis

Falls keine gültige Befugnis für den aufrufenden Nutzer vorliegt MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem NotEntitled-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren. [<=]

A_26459 - XDS Document Service - keine Authentisierung des Nutzers

Falls keine erfolgreiche Authentifizierung des Nutzers vorliegt MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem InvalAuth-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren.<= [<=]

A_14152-02 - XDS Document Service – Implementierung der Schnittstelle I_Document_Management

Der XDS Document Service MUSS die in der nachstehenden Tabelle definierte Web-Service-Schnittstelle für den Zugriff von ePA-Clients, die über das zentrale Netz zugreifen implementieren.

Tabelle 28: Schnittstelle I_Document_Management