C_12373_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

Im Zuge der Umstellung des Dokuments gemSpec_NCPeH_FD auf einen vollständig AFO-basierten Anforderungskatalog für das Anwendungsszenario ePeD-A müssen die testbezogenen Anforderungen mit Bezug auf den NCPeH-FD auch auf eine AFO-basierte Anforderungslage umgestellt werden. Dies wird umgesetzt, indem der normative Anteil des Kapitels 4.5 "Test des NCPeH-FD" auf einzelne Blattanforderungen mit entsprechenden Prüfverfahren umgestellt wird.

Mit der Umstellung auf Blattanforderungen soll auch die Umsetzung optionaler Anwendungsszenarien über den Produkttypsteckbrief wählbar werden. Dies wird auch Auswirkungen auf den Testumfang und den Testaufbau haben. Um dies im Produkttypsteckbrief passend abbilden zu können, wird den hier zu erstellenden Anforderungen ein entsprechend unterscheidbares NCPeH-Konfig-Element im Prüfverfahren zugeordnet:

• "NCPeH_FD" für Basis-Anforderungen,
• "NCPeH_ePeDA" für Anforderungen nur relevant für das Anwendungsszenario ePrescription/eDispensation Country A,
• "NCPeH_PSA" nur relevant für das Anwendungsszenario Patient Summary Country A.

Zusätzlich müssen die testbezogenen Anforderungen im Dokument gemKPT_Test untergebracht werden. Damit wird der Umzug des Kapitels 4.5 aus gemSpec_NCPeH_FD nach gemKPT_Test notwendig. Die konkrete Kapitelnummer in gemKPT_Test und die entsprechende Nummerierung der Unterkapitel erfolgen bei der Einarbeitung in die Release-Version des Dokuments. Das neue Hauptkapitel wird in dieser Anlage deshalb mit dem Nummer-Platzhalter "#" versehen. Da das Test-Kapitel in gemSpec_NCPeH_FD mit der zweiten Kapitelebene begann, werden alle Kapitel in gemKPT_Test eine Ebene nach oben rücken.

Die zukünftige AFO-basierte Spezifikation ermöglicht den Einsatz des gematik Standard-Prüfprozesses der EvTs. Die bisherige exemplarische Vorführung von EvTs in einem Meeting wird deshalb durch den Standardprozess für EvTs ersetzt. Im Rahmen dieser Änderung wird dies anforderungsseitig eingefordert. Dies erfolgt durch die Erstellung neuer Anforderungen für den NCPeH-FD oder durch Zuordnung von Prüfverfahren zu den relevanten Anforderungen, die im gemKPT_Test vorhanden sind. Im Zuge dessen wird auch die Verfahrensbeschreibung für das Bestätigungsverfahren des NCPeH-FD in Bezug auf das Vorgehen zum EvT angepasst.

Mit der Veröffentlichung von [gemKPT_Test] gab es größere Umstellungen, unter anderem mit Hinblick auf das Testvorgehen für die kommende TI 2.0. Diese Änderungen sind mit Bezug auf den Bestätigungstest des NCPeH-FD zu prüfen und die entsprechende Anforderungslage des konzeptuellen Rahmens auf den Anforderungskatalog des NCPeH-FD umzusetzen, soweit diese auf die Tests in den Umgebungen der TI 1.0 anwendbar sind bzw. angewendet werden müssen. Dies erfolgt durch die Zuordnung von Prüfverfahren zu den relevanten, im gemKPT_Test definierten Anforderungen bzw. neuen Anforderungen für den NCPeH-FD.

Die im gemKPT_Test neu eingeführten Rollendefinitionen "Zulassungsnehmer" und "Testansprechpartner gematik" werden in die Texte und Anforderungen mit eingearbeitet.

2 Änderung in gemSpec_NCPeH_FD

Das Kapitel 4.5 samt Unterkapiteln wird aus dem Dokument entfernt. Die Inhalte werden in das Dokument gemKPT_Test verlagert. Die neu zu erstellenden Blattanforderungen und weiteren inhaltlichen Anpassungen bzgl. EvTs erfolgen dort in einem eigenen Hauptkapitel.

Abweichend davon werden die Kapitel 4.5.3 "Testspezifische Funktionen im NCPeH-FD" und 4.5.3.1 "Tracing mit ePA-Aktensystemen in Nichtproduktivumgebungen" nicht in den gemKPT_Test übernommen. Alle relevanten, testspezifischen Anforderungen aus der ePA-Spezifikation werden durch das Prüfverfahren im Produkttypsteckbrief mit Zuordnung zu "NCPeH_PSA" eingefordert. Ein redundantes Erstellen dieser Anforderungen ist deshalb nicht sinnvoll.

3 Änderung in gemKPT_Test

Das Kapitel 4.5 aus gemSpec_NCPeH_FD wird samt Unterkapiteln in ein eigenes Hauptkapitel in der gemKPT_Test verlagert.

Da hauptsächlich Inhalte aus gemSpec_NCPeH_FD übetragen werden, sind nur die zusätzlich geänderten Kapitelanteile farblich gelb hinterlegt (neue Blattanforderungen, Anpassungen in Bezug auf EvTs, Testumfang anhand der laut Bestätigungsantrag benannten Anwendungsszenarien).

3.1 neues Kapitel # Test des NCPeH-FD

Zum Test des NCPeH-FD werden hier im engeren Sinne die technischen Aktivitäten zur Prüfung der Funktionalität der Anwendungsszenarien "Patient Summary Land-A" (PS-A), "ePrescription/eDispensation Land-A" (ePeD-A) und die Integration des NCPeH-FD in die Telematikinfrastruktur betrachtet.

Themen zum Compliance Check und dem zugehörigen Self-Assessment werden von der eHDSI vorgegeben und beschrieben; siehe dazu [MyHealth@EU Compliance Check Framework] und [MyHealth@EU Compliance Check Services].

Zur Sicherung der Funktionalität, Interoperabilität und Nutzbarkeit der Anwendungsszenarien "Patient Summary Land-A" und "ePrescription/eDispensation Land-A" ergeben sich für den Test verschiedene Aufgaben. Allgemein lassen sich diese in folgende Abschnitte aufteilen:

1. Test der Anwendung während der Entwicklung in der eigenen Entwicklungsumgebung mit Integration in die Testumgebungen RU DEV oder RU der Telematikinfrastruktur.
2. Bestätigungstest des NCPeH-FD zum Nachweis der Interoperabilität mit der TI durch die gematik, mit Integration in die Testumgebung (TU) und Unterstützung bei Zulassungstests anderer am Anwendungsverlauf beteiligter TI-Produkte (E-Rezept-Fachdienst, E-Rezept-FdV, ePA-FdV, ePA-Aktensysteme, IDP-Dienst).
3. Test der Anwendung mit Integration in die Umgebung der eHDSI.
4. Test der Anwendung in der Produktivumgebung (PU).

3.1.1 neues Unterkapitel #.1 Durchführung eigenverantwortliche Tests des Zulassungsnehmers

Der Titel des Kapitels wird umbenannt: Durchführung eigenverantwortliche Tests des Herstellers bzw. BetreibersZulassungsnehmers

Der EvT ist künftig nach den allgemeinen Vorgaben aus [gemKPT_Test#4.2.1] durchzuführen. Die dazu vorhandenen Anforderungen werden mit einem entsprechenden Prüfverfahren versehen.

Aufgrund der sehr langen Entwicklungszyklen und den zusätzlichen Testzyklen mit der EU kann der Zulassungsnehmer zur Durchführung seiner EvT seine RU DEV Instanz an TI-Fachdienstinstanzen der Umgebungen RU DEV oder der RU anbinden.

Der Hersteller bzw. Anbieter des NCPeH-FD MUSS eigenverantwortliche Tests ("EvT") des NCPeH-FD durchführen. Dabei wird davon ausgegangen, dass sich Hersteller und Anbieter untereinander abstimmen, wer für die Durchführung der verschiedenen Testarten verantwortlich ist.

Für die Durchführung der EvTs gilt als Grundlage [gemKpt_Test#2.4.1 Eigenverantwortlicher Test]. Abweichend von den dortigen Vorgaben erfolgt eine Prüfung der EvTs nicht über die Bereitstellung von Testprotokollen und Testberichten, sondern über einer Vorführung, bei dem der gematik die wichtigsten Ergebnisse der Tests in einem Vor-Ort-Termin präsentiert und Funktionalitäten vorgeführt werden. Der Umfang und Fokus der Vorführung wird vorab mit der gematik abgestimmt. Das mit der gematik abgestimmte Protokoll der Vorführung wird als Dokumentation des EvT von der gematik aufgenommen.

Ergänzend zu den Festlegungen von [gemKpt_Test#2.4.1 Eigenverantwortlicher Test] KANN der Produkttest als Teil des EvT ohne weitere Abstimmung mit dem Testmanager mit Simulatoren in einer eigenen Testumgebung durchgeführt werden (ohne Anbindung an die RU). Damit soll insbesondere die Durchführung von negativen Tests erleichtert werden. Es gilt jedoch weiterhin, dass der produktübergreifende Test als Teil des EvT gemäß [gemKpt_Test] in der RU integriert durchgeführt werden muss.

3.1.2 neues Unterkapitel #.2 Bereitstellung von Testobjekten des NCPeH-FD in der TI

Im Rahmen der Entwicklung der Anwendungsszenarien PS-A und ePeD-A sind integrative Tests mit den daran beteiligten Produkten der TI (NCPeH-FD, ePA-FdV, ePA-Aktensystem, E-Rezept-FdV, E-Rezept-Fachdienst, IDP-Dienst und zentrale Produkte der TI) durchzuführen. Die integrativen Tests erfolgen entwicklungsbegleitend und im Rahmen der EU-Zulassung in der RU DEV oder RU. Die Tests zur Bestätigung durch die gematik werden in der TU durchgeführt.

Der Zulassungsnehmer muss sein Produkt gemäß TIP-A_4923-* dauerhaft in den Umgebungen RU und TU bereitstellen. Die Bereitstellung der dauerhaft verfügbaren RU-Instanz zum Zwecke einer Referenz zur Produktionsumgebung wird spätestens zum Zeitpunkt der produktiven Bereitstellung des NCPeH-FD erforderlich. Die Weiterentwicklung des NCPeH-FD muss spätestens dann mit einer separaten Instanz in der RU DEV erfolgen.  

Die für den NCPeH-FD momentan relevanten anwendungsspezifischen Fachdienste, ePA-Aktensystem, und E-Rezept-Fachdienst, haben nach Tab_Test_019_01 in der RU jeweils 2 Instanzen - eine zur Weiterentwicklung der Anwendung und eine als Produktionsreferenz - entsprechend den Nutzungszielen von RU DEV und RU gemäß [gemKPT_Test/#6.1 Vorintegrationsumgebung (RU DEV)] bzw. [gemKPT_Test#6.3 Referenzumgebung (RU)]. 

Aus den Testaktivitäten zum NCPeH-FD Version 1.x wurde erkennbar, dass der sehr große zeitliche Rahmen der EU-Zulassung und die zeitliche Planung der Weiterentwicklung der Fachdienste der TI nur schwer miteinander abzustimmen sind. Je nach Situation kann ein benötigtes Produkt der TI sich noch in funktionaler Weiterentwicklung befinden, sich bereits sehr weit im Zulassungsprozess befinden oder sogar schon zugelassen sein. Dementsprechend kann es nötig sein, den NCPeH-FD für Testaktivitäten mit den EU-Partnern an eine Entwicklungsinstanz eines Fachdienstes (RU DEV) oder an eine bereits zugelassene Instanz des Fachdienstes (RU) anzubinden. Sofern dies funktional möglich und sinnvoll ist, wird die gematik jedoch die Anbindung des NCPeH-FD als Client einer Anwendung an den jeweiligen Fachdienst der TI in der RU (Fachdienst als Produktionsreferenz) bevorzugen. Dies gilt insbesondere für die Zulassungstests auf europäischer Ebene.

Der Anbieter des NCPeH-FD MUSS jeweils ein Testobjekt NCPeH-FD in den Umgebungen RU und TU bereitstellen. Er MUSS eigene integrative Tests mit Produkten der TI in der RU durchführen. Der Anbieter MUSS anderen Herstellern bzw. Betreibern von beteiligten TI-Produkten die Du rchführung integrativer Tests in der RU und der gematik die Durchführung von Zulassungs- bzw. Abnahmetests in der TU ermöglichen. Er MUSS der BfArM im Rahmen der Entwicklung und Pflege des MTCs die Durchführung von Tests ermöglichen. Er MUSS sich mit der gematik zur Durchführung gemeinsamer, integrativer Tests (Connectathon) abstimmen, um die Verfügbarkeit der zu integrierenden Produkte und die Teilnahme der Hersteller dieser Produkte sicherzustellen.

Der Anbieter des NCPeH-FD MUSS der gematik Abnahmetests zur Prüfung der korrekten Integration in die TI - insbesondere der Anwendungen ePA und E-Rezept - ermöglichen. Die Durchführung dieser Tests sind gemeinsam zu koordinieren.

Für die Bereitstellung der Produkte in den beiden Umgebungen gilt [gemKpt_Test#3 Systemumgebungen]. Die konkret umzusetzenden Anforderungen sind im [gemProdT_NCPeH_FD] aufgeführt.

3.1.3 neues Unterkapitel #.3 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI

Die konkrete technische Beschreibung der Triggerschnittstelle [gemTestTriggerNCPeH] wird in GitHub bereitgestellt.

Das NCPeH-Testinterface SOLL in Form einer Simulation eines NCPeH Land-B erfolgen, in der auch die eHDSI-Schnittstellen zur Kommunikation mit dem NCPeH-FD genutzt werden. In den nachfolgenden schematischen Darstellungen der Testaufbauten wird sie als Simulation des NCPeH Land-B dargestellt.

In den nachfolgenden schematischen Darstellungen der Testaufbauten wird siedas Testinterface als Simulation des NCPeH Land-B dargestellt.

3.1.3.1 neues Unterkapitel #.3.1 Daten für das automatisierte Auslösen von Anwendungsfällen

Das NCPeH-Testinterface verwendet für einige Eingabeparameter Objekte, die mit zu definierenden Datenprofilen verknüpft sind (EuCountryCode, IdAAssertionProfile/ProfileName, TRCAssertionProfile/ProfileName, DispenseProfile, PatientProfile).

Ein Datenprofil fungiert einerseits wie ein Template, in dem die Daten hinterlegt sind, die für die Kommunikation über die eHDSI-Schnittstelle verwendet werden sollen, so dass diese nicht alle über das NCPeH-Testinterface bereitgestellt werden müssen. Damit soll auch die Komplexität der Testschnittstelle reduziert werden. Andererseits definiert es auch Daten, die in die Kommunikation mit dem NCPeH-FD eingehen. Am wichtigsten ist hier die Referenz auf die zu verwendenden Zertifikate.

Die weiterführenden Erläuterungen zu den Datenprofilen sind bereits teilweise in https://github.com/gematik/NCPeH-Simulation-API/blob/main/README.md enthalten. Der noch fehlende Anteil wird dort ergänzt und die nachfolgende Beschreibung hier entfernt.

Das Objekt EuCountryCode referenziert folgendes Datenprofil:

• Das TLS-Zertifikat, das für die Kommunikation mit dem NCPeH-FD genutzt werden soll.
• Die HomeCommunityId, die in dem Profil per Default für den NCPeH Land-B genutzt werden soll.

Das Objekt IdAAssertionProfile referenziert folgendes Datenprofil:

• Das Signatur-Zertifikat, das zum Signieren der IdA-Assertion zum Einsatz kommen soll.
• Der Wert, der im SAML-Element Assertion/Subject/NameID einzutragen ist (Identifier des LE-EU) als auch das Format des Wertes (Attribut @Format).
• Die Werte, die in dem Profil per Default in den Attributen der Struktur AttributeStatement einzutragen oder wegzulassen sind:
• urn:oasis:names:tc:xspa:1.0:subject:subject-id,
• urn:oasis:names:tc:xacml:2.0:subject:role,
• urn:ehdsi:names:subject:clinical-speciality,
• urn:ehdsi:names:subject:on-behalf-of,
• urn:oasis:names:tc:xspa:1.0:subject:organization,
• urn:oasis:names:tc:xspa:1.0:subject:organization-id,
• urn:ehdsi:names:subject:healthcare-facility-type,
• urn:oasis:names:tc:xspa:1.0:environment:locality,
• urn:oasis:names:tc:xspa:1.0:subject:hl7:permission.

Das Objekt TRCAssertionProfile referenziert folgendes Datenprofil:

• Das Signatur-Zertifikat, das zum Signieren der TRC Assertion zum Einsatz kommen soll.
• Der Wert, der im SAML-Element Assertion/Subject/NameID einzutragen ist (Identifier des LE-EU) als auch das Format des Wertes (Attribut @Format).

Das DispenseProfile wird definiert, da für den Test der Dispensierung ein oder mehrere Dokumente im eHDSI CDA-Pivotformat generiert werden müssen, die aus einem Land-B stammen. Die Erstellung dieser Dokumente MUSS der Land-B Simulator durchführen, bei denen die angegebenen DispenseProfile und den weiteren übergebenen Parametern zugrunde liegen.

Das Objekt DispenseProfile definiert benötigte Datenanteile für ein Dispense-Dokument nach [eHDSI_CDA_Format]:

• Medicinal Product Identifier,
• Medicinal Product Brand Name,
• Medicinal Product Classification,
• Medicinal Product Package Data,
• Active Ingredients Data,
• Marketing Authorization Holder,
• Falls nötig und in gemeinsamer Abstimmung, weitere benötigte medizinische Daten zur Dispensierung.

Mit der KVNR wird für die Generierung von Dispensier-Dokumenten zukünftig auch ein PatientProfile referenziert. Neben der KVNR selbst werden dafür folgende weitere Daten benötigt:

• Insurance Number,
• Given Name,
• Family Name,
• Gender.

Das NCPeH-Testinterface gibt als Response auf die REST-Requests die Inhalte der Nachrichten von der eHDSI-Schnittstelle zurück (siehe [gemTestTriggerNCPeH]). Also den jeweiligen IHE-Request und die IHE-Responses, die mit dem NCPeH-FD ausgetauscht wurden. Beides wird jeweils aufgeteilt in die HTTP-Request bzw. HTTP-Response-Zeile, den http-Header und den http-Body, jeweils Base64-kodiert. Damit soll dem aufrufenden Testfall die Möglichkeit gegeben werden, die Reaktion des NCPeH-FD direkt zu prüfen und zu bewerten.

3.1.4 neues Unterkapitel #.4 Testdurchführung nach Vorgaben der eHDSI

Die eHDSI beschreibt in [eHDSI Test Services], insbesondere im [eHDSI Test Framework] ihre Anforderungen und das Vorgehen für den Test der verschiedenen Anwendungsszenarien. Die dort definierten Testphasen "Formal / Upgrade Pre-Production Test" (PPT) und "Produktion Environment Test" (PET), sind verpflichtend. Der Anbieter MUSSmuss an diesen Testphasen teilnehmen und die Vorgaben aus dem [eHDSI Test Framework] umsetzen. Verantwortlich für Organisation und Teilnahme an den eHDSI Testevents ist der deutsche Anbieter des NCPeH.

Der Anbieter des NCPeH-FD SOLL frühzeitig Tests mit einem europäischen Partner durchführen, um die beidseitige Interoperabilität der NCPeHs zu prüfen. Der Anbieter SOLL zusätzlich an den Testphasen Connectivity Testing und Preparatory Pre-Production Testing (Pre-PPT) teilnehmen.

Über die gematik muss hierbei die zeitliche Verfügbarkeit der benötigten Produkte der TI in einer der Umgebungen RU DEV oder TURU sichergestellt werden (z. B. zum Ausschluss von eventuellen Wartungsphasen von Fachdiensten in der TI). Es ist außerdem zu klären, welche Unterstützung seitens der gematik im Verlauf der Testdurchführung benötigt werden.

3.1.5 neues Unterkapitel #.5 Schematischer Testaufbau

In den folgenden Kapiteln wird informativ der geplante bzw. mögliche Aufbau der Testumgebungen für die verschiedenen Testphasen dargestellt. Abweichungen können auftreten und sind zwischen Anbieter und der gematik im Rahmen der Entwicklung abzustimmen.

3.1.5.1 neues Unterkapitel #.5.1 Testaufbau für integrative Tests in der Telematikinfrastruktur

Der integrative Test des NCPeH-FD mit Produkten der TI (ePA-FdV, ePA-Aktensystem, E-Rezept-FdV, E-Rezept-Fachdienst, IDP-Dienst und zentrale Produkte der TI) erfordert eine unabhängige Testdurchführung, da verschiedene Produkthersteller Zulassungsnehmer von an den Anwendungsszenarien beteiligten Produkten der TI, das BfArM und die gematik Bedarf an einer eigenen Qualitätssicherung haben. Da in dieser Entwicklungsphase die Tests noch auf das deutsche Umfeld beschränkt sind, muss es eine Möglichkeit geben, die verschiedenen Anwendungsfälle der Szenarien automatisiert anzustoßen, die die integrativen Aktivitäten mit den Produkten der TI auslösen. Dies sind die Anwendungsfälle, die eine Interaktion des NCPeH-FD mit den Produkten der TI bewirken. Um den verschiedenen testdurchführenden Instanzen Zulassungsnehmern diese Testmöglichkeit zu bieten, wurde das NCPeH-Testinterface in [Referenz auf das neue Kapitel #.3 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI] definiert.

Der mögliche Aufbau der TU für den Anbieter des NCPeH-FD in der RU wird in der folgenden Grafik schematisch dargestellt. Je nach testdurchführender Instanz Zulassungsnehmer der an den Anwendungsszenarien beteiligten Produkten der TI kann die Zuordnung zu den herstellerspezifischen Umgebungsanteilen variieren.

Abbildung 1: Schematischer Testaufbau für den integrativen Test des NCPeH-FD mit der Telematikinfrastruktur 

redaktioneller Hinweis: die Grafik wird aktualisiert, Cloud-Testkomponenten der gematik für E-Rezept wurden besser dargestellt

Der Testaufbau erfordert die Nutzung eines ePA Remote-Test-FdV bzw. der Simulation des E-Rezept FdV, um integrativ mit ePA Aktensystemen bzw. dem E-Rezept-Fachdienst testen zu können. Nur mit Hilfe der FdV-Funktionalität ist es möglich, dem NCPeH-FD regelmäßig die auf eine Stunde begrenzte Zugriffsberechtigung auf die Daten eines Testversicherten in den Fachdiensten erteilen zu können. Ein integrativer Test mit dem FdV im Sinne einer EvT Nachweiserbringung ist hier nicht erforderlich.

Die Simulation der E-Rezept-App und die Primärsystemsimulation werden zusammen mit der Konnektor Service Plattform (KSP) von der gematik bereitgestellt. Dies soll vor allem die Möglichkeit bieten, in einem testvorbereitenden Schritt jeweils ein spezifisches, zum Testfall passende Dokumente im relevanten Fachdienst der TI einzustellen (automatisiertes Testdatenmanagement für Testdokumente und Berechtigungsmanagement).

Verschiedene Test-FdV müssen für die Berechtigung des NCPeH-FD in ePA-Aktensystemen bzw. im E-Rezept-Fachdienst zum Einsatz kommen. Wenn die Mechanismen zur Berechtigung des NCPeH-FD in den Anwendungen ePA und E-Rezept einsatzbereit sind, wird damit eine NCPeH-FD-Identität mit der Repräsentation eines EU-Landes berechtigt. Vor diesem Zeitpunkt kann mit einer deutschen LE-Identität anstelle einer NCPeH-FD-Identität getestet werden. Das Remote-Test-FdV  wird nach [gemKPT_Test#9.1 Bereitstellung von Remote-Test-FdVs ] von den Herstellern der FdV bereitgestellt.

Die ePA-Aktensysteme müssen in den Umgebungen RU und TU einen Sensorpunkt zum Aufzeichnen der TLS-entschlüsselten Kommunikation mit den ePA-Clients bereitstellen. Der Sensorpunkt ist über das Access Gateway des ePA-Aktensystems nach [gemSpec_Aktensystem_ePAfueralle#3.19.4 Tracing in Nichtproduktivumgebungen gemSpec_Aktensystem_ePAfueralle#3.19.3 Tracing in Nichtproduktivumgebungen] erreichbar. Das von der gematik zur externen Nutzung bereitgestellte Tool [gemTigerProxy] kann mit Hilfe der Vorgaben aus [gemSpec_Krypt] und des Sensorpunkts die VAU-Kommunikation entschlüsseln (siehe auch [4.5.3.1 Tracing mit ePA-Aktensystemen in Nichtproduktivumgebungen]). Auf diese Weise wird eine Überprüfbarkeit der VAU-verschlüsselten Kommunikation eines ePA-Clients mit einer VAU-Instanz eines ePA Aktensystems ermöglicht.

Ein ähnlicher ATestaufbau ergibt sich für die Hersteller der ePA- und E-Rezept-Produkte und bei Bedarf für die BfArM in der RU DEV bzw. RU. Abweichungen können hier je nach Nutzer im (Nicht-)Bedarf eines Konnektors oder eines FdV zum Dokumenten- und Berechtigungsmanagement auftreten.

Abweichend von der schematischen Darstellung erfolgt der Testaufbau für den Test durch die gematik in der TU.

3.1.5.2 neues Unterkapitel #.5.2 Testaufbau für den (Prep-)PPT

In den eHDSI-Testphasen Prep-PPT und PPT liegt der Testfokus auf der Interoperabilität der eHDSI-Schnittstellen, der Konformität der Dokumente "Patient Summary" und "ePrescription/eDispensation" (im Format Clinical Document Architecture, CDA) und der Usability des Gesamtablaufs aus Sicht deines europäischen LELeistungserbringers. Der PPT ist dabei Bestandteil des Zulassungsverfahrens der EU. Die Forderung der eHDSI nach verschiedenen, realitätsnahen Dokumenten macht es wiederum notwendig, unterschiedliche ePKA-Dokumente im ePA-Aktensystem und verschiedene E-Rezepte im E-Rezept-Fachdienst bereitstellen zu können. Hierfür sollen Komponenten aus dem Testaufbau wiederverwendet werden (ePKA-Dokument oder E-Rezept einstellen via Primärsystemsimulation und KSP bzw. Konnektorsimulation).

redaktioneller Hinweis: die folgenden beiden Absätze entfallen, da sie bereits in #.2 Bereitstellung von Testobjekten des NCPeH-FD in der TI thematisiert werden

Da der zeitliche Rahmen für die Entwicklung der Produkte der TI und die zeitliche Organisation der Testphasen in der EU nicht leicht in Übereinstimmung zu bringen sind, muss für die Durchführung des PPT eine Entscheidung über die zu nutzende Umgebung in Abstimmung mit der gematik getroffen werden. Die Herausforderungen zur Festlegung einer Umgebung werden vor allem auf die Neu-Entwicklung von EU-Szenarien zutreffen. Ziel ist es, den PPT möglichst nicht auf Produktinstanzen der RU durchzuführen, die zur Weiterentwicklung der jeweiligen Produkte genutzt werden ("RU-Dev").

Die Sicherstellung der Verfügbarkeit der TI-Produkte erfolgt über die in [4.5.5 Testdurchführung nach Vorgaben der eHDSI] geforderte Abstimmung mit der gematik. Je nach Absprache und Vorbereitung kann hier auch eine Unterstützungsleistung durch die gematik notwendig werden.

3.1.5.3 neues Unterkapitel #.5.3 Testaufbau für den PET

Das [eHDSI Test Framework] definiert die Durchführung von Tests in der Produktivumgebung nach Erteilung der Betriebserlaubnis (Product Environment Test - PET). Diese Tests MÜSSENmüssen nach Vorgaben der eHDSI im Rahmen der Inbetriebnahme eines neuen Anwendungsszenarios bzw. des Upgrades auf eine neue eHDSI Releaseversion ("Wave") erfolgen. Dementsprechend muss produktübergreifend eine Möglichkeit geschaffen werden, diese Tests mit der Produktivumgebung der TI durchzuführen.

Das eHDSI Testframework verbietet die Nutzung von echten Patientendaten im PET. Deshalb müssen Prüfidentitäten der TI für Versicherte zum Test von Land-A Szenarien zum Einsatz kommen.

Dazu könnenDie eGK-Prüfkarten für die Rolle und Identität eines Prüfversicherten können über den gematik WEB-Shop [gemWebShop] bestellt werden. Im [gemSpec_Aktensystem_ePAfueralle#2.4 Validierungskonto] werden Festlegungen getroffen, um Validierungskonten mit Hilfe der KVNR der eGK-Prüfkarten erstellen lassen zu können. Diese eGK-Prüfkarten sind auch für die Durchführung von PETs mit E-Rezepten und dem produktiven E-Rezept-FdV zu nutzen.

Die DVKADer Zulassungsnehmer MUSSmuss sich außerdem um LE-DE (Ärzte, Zahnärzte oder Apotheker) kümmern, um für den PET realitätsnahe ePKA-Dokumente in den Validierungskonten eines ePA-Aktensystems sowie realitätsnahe E-Rezepte in den E-Rezept-Fachdienst einstellen zu können. Das Einstellen der ePKA-Dokumente und E-Rezepte erfolgt dabei in der Umgebung des jeweiligen LE-DEArztes, Zahnarztes oder Apothekers.

Die Erteilung der Zugriffsbefugnis des NCPeH-FD auf das ePKA-Dokument der Prüfidentität kannmuss mittels ePA-FdV einer Krankenversicherung erfolgen, für die der Betreiber eines ePA-Aktensystems die Prüfidentität bereitstellt. Die Erteilung der Zugriffsberechtigung des NCPeH-FD auf E-Rezepte der Prüfidentität kann mittels gematik E-Rezept-App erfolgen.

Da die eHDSI im [eHDSI Test Framework] auch festlegt, dass im PET Nachweise zu durchgeführten Anpassungen bzw. zur Erfüllung von Auflagen erbracht werden können bzw. sollen, ist - je nach konkreter Situation - mit umfangreicheren Testaktivitäten und Bedarf an ePKA-Testdokumenten oder E-Rezepten zu rechnen. Demzufolge sollten friendly User LE-DE mit verschiedenen Primärsystemen und Konnektoren zum Einsatz kommen können, um unterschiedlich erzeugte ePKA-Dokumente oder E-Rezepte bereitzustellen. Je nach Situation kann dabei die Bereitstellung von Dokumenten vorbereitend erfolgen oder siedie Bereitstellung muss zum Zeitpunkt der Testdurchführung erfolgen.

Die Testdurchführung ist mit dem Betrieb der gematik abzustimmen. Insbesondere die Sicherstellung der Verfügbarkeit der TI Produkte und passenden Produktversionen ist hier relevant.

Abbildung 2: Schematischer Aufbau für den Produktivtest des NCPeH-FD mit der eHDSI

3.2 Änderungen im Kapitel 6.4 "Überblick"

Erweiterung von TIP1-A_6526-02, in der Tabelle "Tab_Test_019_01 Produkttypen der TI" um einen Eintrag für den NCPeH-FD:

Tabelle #: Tab_Test_019_01 Produkttypen der TI

...	...	...
Digitale Patientenrechnung	Digitale Patientenrechnung Fachdienst	1x für RU, 1x für TU, 1x RU DEV
EU Gateway
NCPeH-FD		1x für RU, 1x für TU, 1x RU DEV

Redaktionelle Korrektur in TIP1-A_4923-02 der Referenz auf TIP1-A_6526-*:

"Der Zulassungsnehmer MUSS sicherstellen, dass seine Produkte in der Systemumgebung, für die er gemäß AFO TIP1-A_6526-* verantwortlich ist, dauerhaft zur Verfügung stehen. Geplante Wartungsfenster, Updates und notwendige Changes sind hiervon ausgenommen, sofern diese gemäß dem etablierten Change-Management-Prozess erfolgen."

3.3 Änderungen im Kapitel 7.4 "Interoperabilität"

Die zur Anforderung TIP1-A_6529 gehörende Tabelle "Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung" wird um eine Zeile für den NCPeH-FD derart ergänzt, dass eine integrativer Interoperabilitätstest mit folgenden Produkten vorgeschrieben wird:

• E-Rezept-Fachdienst: 1^{<Fußnote 1>}
• ePA-Aktensystem: 2^{<Fußnote 2>}
• IDP-Dienst: 1
• TSP X.509 nonQES: 3

<Fußnote 1>: Wenn die Funktionalität für ePrescription/eDispensation Land-A Bestandteil der Bestätigung ist.

<Fußnote 2>: Wenn die Funktionalität für Patient Summary Land A Bestandteil der Bestätigung ist, IOP mit zwei Aktensystemen, wenn beide Aktensysteme die Anbindung an den NCPeH-FD bereitstellen.

Der Index der Fußnoten wird bei Einarbeitung in gemKPT_Test konkretisiert.

Es wird außerdem eine Spalte für den NCPeH-FD hinzugefügt, so dass zukünftigen Zulassungen für ePA- bzw. E-Rezept-Produkten ein IOP-Test vorgegeben werden kann.

3.4 Änderungen im Kapitel 18.5.1 "Dokumente der gematik"

In der Tabelle der "Dokumente der gematik" wird eine Zeile eingefügt:

[Quelle]	Herausgeber: Titel
...	...
[gemTestTriggerNCPeH]	gematik: Schnittstelle zum Triggern von eHDSI-Anwendungsfällen für den NCPeH-FD [https://github.com/gematik/NCPeH-Simulation-API/tree/main], und mit einem Release-Tag zum passenden Spezifikations-Release versehen. Die Zuordnung zum passenden Spezifikationsrelease ist der dortigen ReleaseNote zu entnehmen. Die Datei YAML-Datei zur OpenAPI Spezifikation ist in einer ZIP-Datei zu finden im entsprechenden Release-Pfad unter [https://repo1.maven.org/maven2/de/gematik/api/ncpeh-simulation-td-api/]

3.5 Änderungen im Kapitel 18.5.2 "Weitere Dokumente"

In der Tabelle der "Weitere Dokumente" werden folgende Zeilen hinzugefügt:

[Quelle]	Herausgeber (Erscheinungsdatum): Titel
...	...
[MyHealth@EU Compliance Check Framework]	MyHealth@EU:  https://webgate.ec.europa.eu/fpfis/wikis/display/EHDSI/4.+MyHealth@EU+Compliance+Checks+Services
...	...
[gemWebShop]	https://fachportal.gematik.de/gematik-onlineshop/pruefkarte-egk-fuer-dvo?ai%5Baction%5D=detail&ai%5Bcontroller%5D=Catalog&ai%5Bd_name%5D=Prufkarten-eGK&ai%5Bd_pos%5D=0

4 Änderungen am Produkttypsteckbrief NCPeH mit Bezug zum Test des Produktes

redaktioneller Hinweis: Im Folgenden wird nur beschrieben, welche Anforderungen sich basierend auf dieser Anlage in den Angaben des Produkttypsteckbriefes ändern werden. Da sich die Nummerierung der Tabellen ebenfalls ändern wird, erfolgt die Angaben der Änderungen hier nach Prüfverfahren gruppiert.

Prüfverfahren: funkt. Eignung: Herstellererklärung

Anforderung	Titel	Dokument	Änderungsbeschreibung
TIP1-A_6517-01	Eigenverantwortlicher Test: TBI	gemKPT_Test	entfällt, wird abgelöst von TIP1-A_6517-02
TIP1-A_6517-02	Eigenverantwortlicher Test: Zulassungsnehmer	gemKPT_Test	neu, löst TIP1-A_6517-01 ab
TIP1-A_6518	Eigenverantwortlicher Test: TDI	gemKPT_Test	entfällt, wird abgedeckt durch TIP1-A_6517-02 und TIP1-A_6519-01
TIP1-A_6519	Eigenverantwortlicher Test: Hersteller und Anbieter	gemKPT_Test	entfällt, wird abgelöst von TIP1-A_6519-01
TIP1-A_6519-01	Eigenverantwortlicher Test: Hersteller und Anbieter	gemKPT_Test	neu, löst TIP1-A_6519 ab
TIP1-A_4923	Dauerhafte Verfügbarkeit RU und TU	gemKPT_Test	entfällt, wird abgelöst von TIP1-A_4923-02
TIP1-A_4923-02	Dauerhafte Verfügbarkeit RU und TU	gemKPT_Test	neu, löst TIP1-A_4923 ab
A_20061	Beschreibung Art und Umfang der Fehlerkorrektur	gemKPT_Test	wird neu zugeordnet
A_27475	Fehlerbehebungsplan	gemKPT_Test	wird neu zugeordnet
TIP1-A_6533	Zulassung eines neuen Produkts: Aufgaben der Hersteller und Anbieter	gemKPT_Test	wird neu zugeordnet
TIP1-A_6537	Zulassung eines geänderten Produkts: Aufgaben der Hersteller und Anbieter	gemKPT_Test	wird neu zugeordnet
TIP1-A_6526-02	Produkttypen: Bereitstellung	gemKPT_Test	wird neu zugeordnet
GS-A_2158-01	Trennung von kryptographischen Identitäten und Schlüsseln in Produktiv- und Testumgebungen	gemKPT_Test	wird neu zugeordnet
A_28178	Wahlweise Anbindung des NCPeH-FD als Client von Fachdiensten der TI an RU oder RU DEV	gemKPT_Test	neu, siehe oben: 3.1.2 "neues Unterkapitel #.2 Bereitstellung von Testobjekten des NCPeH-FD in der TI"
A_28179	Abstimmung mit der gematik zur Anbindung des NCPeH-FD an die RU	gemKPT_Test
A_28181	Bereitstellen eines NCPeH-Testinterface zum Auslösen von Land-A Anwendungsfällen in RU und TU	gemKPT_Test	neu, siehe oben: 3.1.4 "neues Unterkapitel #.3 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI"
A_28183	NCPeH-Testinterface als Land-B Simulation	gemKPT_Test
A_28182	Parallele Nutzbarkeit des NCPeH-Testinterfaces	gemKPT_Test
A_28184	Bereitstellung des NCPeH-Testinterface über das Internet	gemKPT_Test
A_28185	Bereitstellung von Datenprofilen für das NCPeH-Testinterface	gemKPT_Test	neu, siehe oben: 3.1.4.1 "neues Unterkapitel #.3.1 Daten für das automatisierte Auslösen von Anwendungsfällen"
A_28186	Modifizierbarkeit der Datenprofile für das NCPeH-Testinterface	gemKPT_Test

Prüfverfahren: Sich.techn. Eignung: Anbietererklärung

Anforderung	Titel	Dokument	Änderungsbeschreibung
A_28194	Beschaffung von eGK Prüfkarten für die Durchführung des PET	gemKPT_Test	neu, siehe oben: 3.1.6.3 "neues Unterkapitel #.5.3 Testaufbau für den PET"

Prüfverfahren: organ./betriebl. Eignung: Anbietererklärung

Anforderung	Titel	Dokument	Änderungsbeschreibung
A_28192	Abstimmung mit der gematik zur Nutzung der Testumgebung in den EU-Testphasen	gemKPT_Test	neu, siehe oben: 3.1.5 "neues Unterkapitel #.4 Testdurchführung nach Vorgaben der eHDSI"