C_12122_Anlage

Inhaltsverzeichnis

1 Änderung in gemSpec_NCPeH_FD

1.1 Aktualisierung des Kapitels "4.5 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", "ePrescription/eDispensation Land A" und die Integration des NCPeH-FD in die Telematikinfrastruktur betrachtet.

Themen zum Compliance Check und dem zugehörigen Self-Assessments werden von der eHDSI vorgegeben und beschrieben, siehe dazu [eHDSI Compliance Check Framework] und [eHDSI 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 verschiedenste Aufgaben. Allgemein lassen sich diese aber in folgende Abschnitte aufteilen:

[...]

1.1.1 Aktualisierung des Kapitels "4.5.1 Durchführung eigenverantwortliche Tests des Herstellers bzw. Betreibers"

[...]

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.

1.1.2 Aktualisierung des Kapitels "4.5.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. Dies erfolgt zum einen entwicklungsbegleitend in der Umgebung RU und zum anderen zu Abnahme- bzw. Zulassungszwecken in der TU (siehe [gemKpt_Test]).

[...]

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 ist gemeinsam zu koordinieren.

[...]

1.1.2.1 Aktualisierung des Kapitels "4.5.3.1 Tracing in Nichtproduktivumgebungen"

<<Der Titel des Kapitels wird geändert in "Tracing mit ePA-Aktensystemen in Nichtproduktivumgebungen", da sich die Nutzung dieser Tracingfunktionalität nur auf ePA-Aktensysteme bezieht.>>

Der NCPeH-FD MUSS sicherstellen, dass die Mechanismen für das Tracing mit dem ePA-Aktensystem gemäß [gemSpec_Krypt#A_24477* in der Produktivumgebung nicht zum Einsatz kommen und dass der VAU-Kanal entsprechend Vorgaben aus [gemSpec_Krypt#Transport und Sicherung von Nutzdaten] als produktiv gekennzeichnet werden.

1.1.3 Aktualisierung des Kapitels "4.5.4 Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI"

<<Die Schnittstelle für das NCPeH-Testinterface wird um Daten und Funktionen zur Nutzung der Anwendung ePeD-A erweitert ([gemTestTriggerNCPeH]). Dies hat unter anderem auch Auswirkungen auf die Datenprofile, die vom NCPeH-Testinterface benötigt werden.>>

1.1.3.1 Aktualisierung des Kapitels "4.5.4.1 Daten für das automatisierte Auslösen von Anwendungsfällen"

Das NCPeH-Testinterface nutzt für einige Eingabeparameter Objekte, an die zu definierende Datenprofile gekoppelt 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 die Triggerschnittstelle das NCPeH-Testinterface bereitgestellt werden müssen. Damit soll auch die Komplexität der Schnittstelle 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.

[...]

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 [DECOR Dataset Description]:

• 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.

1.1.4 Aktualisierung des Kapitels "4.5.5 Testdurchführung nach Vorgaben der eHDSI"

[...]

Zur Teilnahme an den Testphasen PPT und Pre-PPT MUSS es mindestens eine rechtzeitige Abstimmung mit der gematik geben (mind. 12 Wochen vor Beginn der Testphase). Über die gematik muss hierbei die zeitliche Verfügbarkeit der benötigten Produkte der TI in der Umgebung TU einer der Umgebungen RU oder TU sichergestellt werden (z. B. zum Ausschluss von eventuellen Wartungsphasen des ePA-AktensystemsFachdienstes in der TI). Es ist außerdem zu klären, welche Unterstützung seitens der gematik im Verlauf der Testdurchführung benötigt werden.

1.1.5 Aktualisierung des Kapitels "4.5.6 Schematischer Testaufbau"

<<Die Beschreibungen werden in diesem Kapitel angepasst und erweitert, um die Szenarien PS-A und ePeD-A anzudecken. Grafische Darstellungen werden entsprechend ausgetauscht.>>

1.1.5.1 Aktualisierung des Kapitels "4.5.6.1 Testaufbau für integrative Tests in der Telematikinfrastruktur"

Der integrative Test des NCPeH-FD mit Produkten der TI (ePA FdV, ePA-AS, E-Rezept-FdV, E-Rezept-Fachdienst, IDP-Dienst und zentrale Produkte der TI) erfordert eine unabhängige Testdurchführung, da verschiedene Produkthersteller, 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 des Szenariosder Szenarien automatisiert anzustoßen, die die integrativen Aktivitäten mit den Produkten der TI auslösen. Dies sind primär die Anwendungsfälle, die in den Kapiteln 5.1 - NCPeH.UC_1 - Versicherten im Behandlungsland für PS-A identifizieren, 5.2 - NCPeH.UC_2 - Metadaten über ePKA auflisten, 5.3 - NCPeH.UC_3 - ePKA MIO des Versicherten abrufen und 5.4 - NCPeH.UC_4 - ePKA MIO des Versicherten als PDF/A abrufen  beschrieben sinddie eine Interaktion mit den Produkten der TI bewirken. Um den verschiedenen Interessententestdurchführenden Instanzen diese Testmöglichkeit zu bieten, wurde das NCPeH-Testinterface in 4.5.4 - Automatisiertes Auslösen von NCPeH-Anwendungsfällen für Tests in der TI  definiert.

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

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

<<Aktualisierte schematische Darstellung>>

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

EinVerschiedene Test-FdVs mussmüssen für die Berechtigung des NCPeH-FD in ePA-Aktensystemen bzw. dem E-Rezept-Fachdienst zum Einsatz kommen. Wenn die Mechanismen zur Berechtigung des NCPeH-FD in der ePA-Anwendung den Anwendungen ePA und E-Rezept einsatzbereit sind, wird damit eine NCPeH-FD-Identität mit 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 Test-FdV wird nach [gemKpt_Test#9.1 Bereitstellung von Remote-Test-FdVs] von den Herstellern der FdVs bereitgestellt.

[...]

Der mögliche Aufbau der Testumgebung für Testaktivitäten der gematik in der TU wird in der folgenden Grafik schematisch dargestellt.

<<Die schematische Darstellung "Schematischer Testaufbau für den integrativen Test der gematik mit der Telematikinfrastruktur" wird entfernt>>

Der größte Unterschied im schematischen Aufbau ergibt sich aus den unterschiedlichen Lokationen der Umgebungen. Dies führt zu der Notwendigkeit, das NCPeH-Testinterface über das Internet erreichbar zu machen.

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

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

1.1.5.2 Aktualisierung des Kapitels "4.5.6.2 Testaufbau für den (Pre-)PPT"

In den eHDSI-Testphasen Pre-PPT und PPT liegt der Testfokus auf der Interoperabilität der eHDSI-Schnittstellen, der Konformität der Dokumente Patient Summary, ePrescription/eDispensation und der Usability des Gesamtablaufs aus Sicht des europäischen Leistungserbringers. 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 bereitstellen zu können. Hierfür sollen Komponenten aus dem Testaufbau der TU wiederverwendet werden (Dokument oder E-Rezept einstellen via Primärsystemsimulation und KSP).

Der PPT MUSS in der TU stattfinden, um die Anforderung der eHDSI an reife, produktionsnahe nationale Produkte sicherzustellen. Typischer Weise sollten dazu die Produkte in der TU bereits eine Zulassung durch die gematik erreicht haben. 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"). Ein Prep-PPT oder PPT DARF jedoch NICHT in der PU durchgeführt werden.<<Zeilenumbruch eingefügt>>

Die Sicherstellung der Verfügbarkeit der TI-Produkte in der TU 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(z. B. zum Einstellen unterschiedlicher ePKA-Dokumente und Berechtigungserteilung via FdV).

Der mögliche Aufbau der Testumgebung zur Prüfung der Konformität und Interoperabilität mit der eHDSI wird in der folgenden Grafik schematisch dargestellt.

<<"Abbildung 5 Schematischer Testaufbau für den Konformitätstest des NCPeH-FD mit der eHDSI" wird entfernt. Die DVKA hat inzwischen Erfahrungen gesammelt und Entscheidungen bzgl. Testumgebung für (Prep-)PPT getroffen. Eine schematische Darstellung an dieser Stelle erscheint daher nicht mehr notwendig.>>

Spätestens für die Prüfung der Usability des Gesamtablaufes durch einen europäischen Leistungserbringer wird eine Integration von NCPeHs Land B mit dem NCPeH-FD über das Netzwerk TESTA-ng durchgeführt. Daraus ergibt sich folgender schematischer Aufbau.

<<"Abbildung 6 Schematischer Testaufbau für den Funktionstest des NCPeH-FD mit der eHDSI" wird entfernt.>>

1.1.5.3 Aktualisierung des Kapitels "4.5.6.3 Testaufbau für den PET"

Das [eHDSI Test Framework] definiert eine Durchführung von Tests in der Produktivumgebung nach Erteilung der Betriebserlaubnis (Product Environment Test - PET). Diese Tests MÜSSEN 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.

In Vorbereitung des PET MUSS sich die DVKA Versichertenidentitäten zu Prüfzwecken mit zugehörigen Konten in den ePA-Aktensystemen beschaffen. Dazu können eGK Prüfkarten für die Rolle und Identität eines Prüfversicherten über den gematik WEB-Shop [gemWebShop] bestellt werden. In [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 DVKA MUSS sich um LE-DE (Ärzte oder Zahnärzte) kümmern, um für den PET realitätsnahe ePKA-Dokumente in den ePA Validierungskonten eines ePA-Aktensystems und 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-DE.

Die Erteilung der Zugriffsbefugnis des NCPeH-FD auf das ePKA-Dokument der Prüfidentität kann 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 in der ePKA oder E-Rezepte bereitzustellen. Je nach Situation kann dabei die Bereitstellung von ePKA-Dokumenten vorbereitend erfolgen oder sie 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

<<Aktualisierte schematische Darstellung>>

1.2 Aktualisierung des Kapitels "8.5.2 Weitere Dokumente"

[Quelle]	Herausgeber (Erscheinungsdatum): Titel
[...]
[DIMDI_HCID_NCPeH]	https://portal.dimdi.de/websearch/servlet/Gate?accessid=showOidDoc&query=oid=1.2.276.0.76.4.291
[DECOR Dataset Description]	https://art-decor.ehdsi.eu/publication/epsos-html-20240422T073854/ds-2.16.840.1.113883.3.1937.777.11.1.2-2022-03-01T000000.html
[ebRIM_Representation_DocumentEntry]	https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.1.1
[...]