C_12020_Anlage

Produktübergreifende Änderungen in gemKPT_Test

Inhaltsverzeichnis

1 Änderungsbeschreibung

Dieser Änderungsantrag zielt auf eine weitreichende Aktualisierung der produktübergreifenden Anforderungen in der [gemKPT_Test] - aufbauend auf Version 2.10.0 - ab. Die vorgeschlagenen Änderungen umfassen:

• eine grundlegende Überarbeitung des Testvorgehens und die Anpassung an die neue Teststrategie 2.0
• Erweiterung des Testkontexts
• Anpassung der Rollen
• übergreifende Anforderungen für die Produkte 
• PoPP
• ZETA
• VSDM 2
• E-Rechnung
• Aktualisierung der Interoperabilitätstabelle (IOP):
• Einbindung neu hinzugekommener Produkte
• Überprüfung und Anpassung bestehender Kompatibilitätsangaben
• Erweiterung der Anforderungen an die Systemumgebungen 

2 Einführung und Überblick

## Das Kapitel 2.1 des [gemKPT_Test] wird komplett durch diesen Abschnitt 2 ersetzt.

Das SGB V enthält die zentralen Bestimmungen für die gesetzliche Krankenversicherung und bildet die rechtliche Grundlage für die Einführung und Nutzung der Telematikinfrastruktur im Gesundheitswesen. Gemäß § 311 Abs. 1 Nr. 1 lit. d hat die gematik die Aufgabe, die zur Schaffung der Telematikinfrastruktur notwendigen Test-, Bestätigungs- und Zertifizierungsmaßnahmen sicherzustellen. Diese Maßnahmen sind Voraussetzung für die Überprüfung der Funktionsfähigkeit und Interoperabilität von TI-Produkten. Die in diesem Dokument beschriebene Teststrategie der Telematikinfrastruktur ermöglicht eine schrittweise Integration, bei der Produkte sowohl einzeln als auch im Verbund (Gesamtsystem) geprüft werden.

Diese Methode kombiniert:

• ein integriertes Testmanagement innerhalb der Projektorganisation,
• einheitliche, aufeinander aufbauende Teststufen für eine nachvollziehbare Prüfung und
• strukturierte Teststandards wie ISTQB und ISO 29119.

Besonderes Augenmerk liegt auf der parallelen Koexistenz der TI 1.0 und der neuen TI 2.0.

3 Testkontext TI

## Das Kapitel 2.3 des [gemKPT_Test] wird komplett durch diesen Abschnitt 3 bis einschließlich Abschnitt 4.2 ersetzt.

Testgegenstand sind alle Produkte und Anwendungen, die gemäß der gesetzlichen Vorgaben SGB V enthalten sind.

Die TI bildet – als sicheres digitales Gesundheitsnetz – die Grundlage für den einrichtungsübergreifenden Austausch von behandlungsnotwendigen, medizinischen Daten und Informationen zwischen den Beteiligten im Gesundheitswesen. Dazu gehören unter anderem:

• Konnektoren und Kartenterminals für die Anbindung von Praxen und Krankenhäusern
• Fachdienste wie elektronische Patientenakte (ePA) und weitere
• Zentrale Dienste wie Namensdienst oder Zeitdienst
• Sicherheitsinfrastruktur für die Authentifizierung und Verschlüsselung

Um dies zu ermöglichen, werden gesicherte Verbindungen zwischen den verschiedenen Komponenten und zu zentralen Diensten implementiert, die den strengen Datenschutz- und Sicherheitsanforderungen im Gesundheitswesen entsprechen. Die Testaktivitäten zielen darauf ab, die Funktionalität und Interoperabilität aller Produkte und Anwendungen sowohl einzeln als auch im Zusammenspiel zu überprüfen. Dabei werden verschiedene Testszenarien durchgeführt, die reale Anwendungsfälle im Gesundheitswesen simulieren. Die nachfolgende Abbildung veranschaulicht den Testkontext.

Abbildung 1: Übersicht des Gesamtsystems Telematikinfrastruktur

3.1 Testziel

Das oberste Testziel der gematik besteht darin, die Interoperabilität der Telematikinfrastruktur (TI) und ihrer Peripherie sicherzustellen. Dies bedeutet, dass alle Komponenten und Systeme der TI nahtlos zusammenarbeiten müssen, um einen zuverlässigen und effizienten Datenaustausch zu gewährleisten. Die Interoperabilitätstests sind darauf ausgelegt, um sicherzustellen, dass unterschiedliche Systeme, Softwareprodukte und Hardwarelösungen reibungslos miteinander kommunizieren und funktionieren. Darüber hinaus wird explizit die Interoperabilität bei der Verarbeitung medizinischer Daten geprüft, um eine konsistente und fehlerfreie Handhabung dieser sensiblen Informationen über alle Systeme hinweg zu garantieren.

Um diese übergeordneten Ziele zu erreichen, findet eine risikobasierte, auf mehrere Teststufen verteilte Testabdeckung statt. Jede Teststufe verfolgt ein konkretes Testziel, das die Qualitätssicherung für die nächste Teststufe darstellt. Die unterschiedlichen Teststufen der TI fokussieren jeweils auf die folgenden Überprüfungen:

• Umsetzung der Anforderungen: Sicherstellung, dass alle Anforderungen durch funktional korrekte und betriebsfähige Artefakte umgesetzt worden sind.
• Korrekte Schnittstellenfunktion: Überprüfung, dass alle Schnittstellen korrekt arbeiten und dabei Datenkonsistenz und Datenformat eingehalten werden.
• Korrekte Datenverarbeitung: Sicherstellung, dass in den Produkten die persönlichen und medizinischen Daten korrekt sowie unter Beibehaltung der Datenkonsistenz verarbeitet werden.
• Verhinderung von Datenverlust: Sicherstellung, dass Datenverlust verhindert wird.
• Systemperformanz und Stabilität: Überprüfung, dass das Gesamtsystem mit ausreichender Performanz und Stabilität die geforderten Mengengerüste verarbeiten kann.
• Betriebsfähigkeit der Komponenten: Sicherstellung, dass alle TI-Produkte betriebsfähig sind.
• Nachweis der Softwarefunktionsfähigkeit: Überprüfung, damit die Funktionsfähigkeit der Software nachgewiesen werden kann.

4 Rollen und Mitwirkungspflichten im Test

Im Testkonzept der Telematikinfrastruktur (TI) sind die Rollen und Verantwortlichkeiten klar definiert und auf zwei Hauptakteure konzentriert:

• den Zulassungsnehmer und
• den Testansprechpartner gematik.

Diese Hauptakteure fungieren als Schnittstellen und Koordinatoren für alle testbezogenen Aktivitäten. Sie repräsentieren und orchestrieren verschiedene spezialisierte Funktionen wie Testmanagement, Fehlermanagement und Umgebungsmanagement. Diese Vereinfachung der Rollenstruktur dient der Straffung der Kommunikation und Prozesse, während die notwendige Komplexität intern beibehalten wird.

4.1 Zulassungsnehmer

Zulassungsnehmer, die als Hersteller oder Anbieter die Testanforderungen im Rahmen einer Zulassung oder Bestätigung erfüllen müssen, unterliegen den Bestimmungen des § 291b Abs. 1a SGB V. Sie übernehmen eine zentrale Rolle als testdurchführende Instanz und tragen die Gesamtverantwortung für die Qualitätssicherung ihres Produkts im Zulassungsverfahren.

Zu seinen verpflichteten Aufgaben gehören:

• Testdurchführung:
• Planung, Steuerung und Durchführung der Eigenverantwortliche Tests (EvT)
• Durchführung zusätzlicher Tests während der Zulassungsteststufen in der RU:
  
• Generalprobe: Durchführung Installationstests und abschließender Tests zur Sicherstellung der Betriebsfähigkeit
• Leistungstests: Durchführung von Last- und Performance-Tests, sofern diese von der gematik gefordert werden.

• Fehlermanagement:
• Analyse von Fehlern aus den gematik-Zulassungstests
• Behebung identifizierter Fehler sowie erneute Prüfung
• Abstimmung mit gematik Test und Zulassung

• Umgebungsmanagement:
• Bereitstellung und Konfiguration der Zulassungsobjekte in den vorgegebenen Umgebungen
• Herstellung der Testbereitschaft inklusive Dokumentation
• Unterstützung beim Nachstellen und Analysieren von auftretenden Fehlern in den Umgebungen

4.2 Testansprechpartner gematik

Der Testansprechpartner repräsentiert die gematik in allen testbezogenen Aspekten des Zulassungsverfahrens und unterstützt den Zulassungsnehmer während des gesamten Testprozesses. Er verantwortet darüber hinaus die Testdurchführung der einzelnen Zulassungsteststufen.

Zu den wesentlichen Aufgaben des Testansprechpartners im gesamten Testprozess gehören:

• Prüfung der produkttypspezifischen Testkonzepte und Testabdeckungen
• Koordination von Tests:
• Organisation von Connectathons während der EvT sowie produktübergreifender Interoperabilitätstests (IOP) in der RU DEV
• Planung und Steuerung der Zulassungstests
• Unterstützung des Zulassungsnehmers:
• Primärer Ansprechpartner während des gesamten Verfahrens
• Unterstützung bei der Einbindung von Testobjekten in die Umgebungen
• Fehlermanagement:
• Koordination der Fehlerbehebung sowie Bewertung von Fehlern nach Schweregrad
• Eskalationsmanagement:
• Eskalation von Problemen im Zulassungstest sowie bei Termin- oder Interessenskonflikten
• Mitwirkung im Change Advisory Board (CAB):
• Festlegung erforderlicher Testmaßnahmen innerhalb der Umgebungen
• Sicherstellung eines diskriminierungsfreien Zugangs:
• Gewährleistung fairer Bedingungen für alle Zulassungsnehmer

5 Teststrategie

## Das Teskonzept ist in Testphasen, Teststufen u. Testarten gestaffelt. Daher werden die Kapitel 2.4, 4.5 u. 2.5 des [gemKPT_Test] zusammengefasst u. durch diesen Abschnitt 5 u. 5.1 ersetzt.

Übergreifender Hinweis zur Rolleninterpretation:

• In den folgenden Kapiteln beziehen sich die Begriffe "testdurchführende Instanz (TDI)" und "Testbetriebsinstanz (TBI)" auf den Zulassungsnehmer.

• Die Begriffe "Test- und Transition Manager" sowie "Testkoordinierende Instanz (TKI)"  beziehen sich auf den Testansprechpartner  der gematik.

Die Digitalisierung des Gesundheitswesens stellt einen bedeutenden Fortschritt in der medizinischen Versorgung dar. Als Nationale Agentur für Digitale Medizin nimmt die gematik eine Schlüsselrolle bei der Gestaltung und Umsetzung dieses Transformationsprozesses ein. Die gematik trägt die Gesamtverantwortung für die Telematikinfrastruktur (TI), die als sichere digitale Plattform den Austausch medizinischer Daten im deutschen Gesundheitswesen ermöglicht.

Ihre Aufgaben umfassen die Definition und Durchsetzung verbindlicher Standards für die TI sowie die Festlegung und Durchführung von Zulassungsverfahren für TI-Produkte und -Anwendungen.

Um die Funktionalität und Interoperabilität aller TI-Produkte zu gewährleisten, hat die gematik eine umfassende Teststrategie entwickelt. Diese gliedert sich in zwei Haupttestphasen:

• EvT: Eigenverantwortliche Tests durch die Zulassungsnehmer
• ZulT: Zulassungstests durch die gematik bestehend aus
• PüT: Produktübergreifenden Tests und
• GIT-TI: Gesamtintegrationstests der TI.

Abbildung 2 : Überblick der Testphasen

5.1 Testphasen

Die Testvorgehensweise teilt sich in zwei Testphasen. Diese unterscheiden sich im Testziel, in der Verantwortung und in der Nutzung der Systemumgebungen (hier als Obergriff aller Testumgebungen gemeint). Des weiteren werden in den Testphasen unterschiedliche Teststufen durchlaufen, die wiederum durch spezifische Testarten ergänzt und detailliert ausgestaltet werden.

 Die Teststufen laufen sequenziell ab. Eine Teststufe beginnt erst, wenn die vorherige Teststufe erfolgreich abgeschlossen wurde.

In den folgenden Kapiteln werden diese Testphasen und die darin enthaltenen Teststufen beschrieben.

5.1.1 Eigenverantwortlicher Test (EvT)

Die folgende Tabelle gibt eine Übersicht über die Testphase Eigenverantwortlicher Test (EvT).

In der Testphase "Eigenverantwortliche Tests" gibt es nur die eine, namensgleiche Teststufe "Eigenverantwortliche Tests"

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 1 : Tab_Test_005 Eigenverantwortlicher Test (EvT)

Testphase	Eigenverantwortlicher Test (EvT)
Beschreibung	Im EvT werden für die jeweiligen Produkte, Module und Komponenten Tests durchgeführt. Diese Testaktivitäten werden autark durch die entsprechenden Zulassungsnehmer ausgeführt und verantwortet. Weiterhin werden je nach Anforderungen dedizierte Interoperabilitätstests (IOP-Tests) ausgeführt. Diese Tests können durch die gematik unterstützt. Die Zulassungsnehmer weisen mit den Tests die Erfüllung der an die Produkte und Anwendungen gestellten Anforderungen gemäß den zugrundeliegenden Spezifikationen und Konzepten nach. Darüber hinaus stellen sie Informationen zum Testvorgehen sowie die Testergebnisse für die Produkte und Anwendungen bereit. Das konkrete Vorgehen der Zulassungsnehmer für den Nachweis der EvTs wird auf der Grundlage eines von ihnen selbst vorgelegten Testkonzepts festgelegt. Der Testansprechpartner der gematik prüft die Testkonzeption sowie die Afo-Testmatrix auf Einhaltung der Vorgaben. Ziel dieser Prüfung ist es, die Freigabe für die nächste Testphase  zu erteilen.
Ziel	Das Ziel des EvT besteht darin, sowohl die funktionalen als auch die nicht-funktionalen Anforderungen nachzuweisen und dabei die Interoperabilität der Systeme sicherzustellen.
Testobjekt	Produkt des Zulassungsnehmers
Umgebung	Lokale Umgebung und / oder RU DEV, je nach Produktanforderung

## Alt:

## Neu:

## Alt: Diese Afo wird für das Leseverständnis lediglich erwähnt. Allerdings ist die referenzierte [Tab_Test_005] angepasst worden.

5.1.1.1 Qualitätssichernde Maßnahme: Service Produkte zur Testunterstützung

Die gematik bietet Zulassungsnehmern als unterstützende Maßnahme eine Reihe von Serviceprodukten an, die für eigenverantwortliche Tests genutzt werden können. Welche Services dies im Einzelnen sind, deren Verfügbarkeit und die Konditionen, zu welchen diese genutzt werden können, sind im gematik Fachportal aufgeführt.

5.1.2 Zulassungstest (ZulT)

In der Testphase Zulassungstest werden nacheinander die beiden Teststufen Produktübergreifende Tests (PüT) und Gesamtintegrationstest der Telematikinfrastruktur (GIT-TI) durchlaufen.

 Im Rahmen dieser Tests können Fehler oder Verbesserungspotenziale identifiziert werden. Dies kann dazu führen, dass während des laufenden Zulassungstests neue Lieferungen berücksichtigt werden müssen, etwa zur Fehlerbehebung, Anpassung an geänderte Spezifikationen oder Optimierung.

In solchen Fällen wird risikobasiert entschieden, ob spezifische Testfälle wiederholt oder angepasst werden müssen, oder ein vollständiger Regressionstestzyklus erforderlich ist.

5.1.2.1 Produktübergreifender Test (PüT)

Die folgende Tabelle gibt im Rahmen der Testphase Zulassungstest (ZulT) eine Übersicht über die Teststufe produktübergreifender Test (PüT) .

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 2: Tab_Test_034 Produktübergreifende Tests

Testphase	Zulassungstest (ZulT)
Teststufe	Produktübergreifender Test (PüT)
Beschreibung	Aufbauend auf die Testphase EvT werden in den funktionalen Tests die Use Cases, für die eine technische Integration abgeschlossen ist, fachlich getestet.  Mit dem PüT erfolgt der Nachweis der korrekten Interaktion der Produkte und Anwendungen untereinander.
Ziel	Ziel des Produktübergreifenden Tests (PüT) ist es, die technische Funktionsfähigkeit und Interoperabilität der  beteiligten Produkte zu verifizieren und die korrekte Umsetzung der spezifizierten Schnittstellen und Workflows sicherzustellen.
Testobjekt	Produkte mit gemeinsamen Schnittstellen und Datennutzung
Umgebung	Testumgebung (TU)

5.1.2.2 Gesamtintegrationstest (GIT-TI)

Die Teststufe Gesamtintegrationstest umfasst mehrere Testarten, von denen jede jeweils spezifische Schwerpunkte prüft:

• Funktionale Tests (E2E)
• Generalprobe
• Leistungstest
• Interoperabilitätstests TI-Primärsysteme

Diese Teststufe wird durch die gematik in einem definierten Zeitfenster für alle Produkte zusammen innerhalb der Telematikinfrastruktur durchgeführt.

Das Testvorgehen in dieser Teststufe wird für alle ausgewählte Produkte, unabhängig ob sie neu sind, überarbeitet sind oder auch keine Veränderungen erfahren haben, in einem Testverfahren durchgeführt.

Nach dieser Teststufe werden die Produkte, die einer Zulassung unterliegen, entweder für die Zulassung empfohlen oder es wird keine Empfehlung ausgesprochen.

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 3: Tab_Test_034 Funktionale Tests (E2E)

Testphase	Zulassungstest (ZulT)
Teststufe	Gesamtintegrationstest (GIT-TI)
Testart	Funktionale Tests (E2E)
Beschreibung	Die funktionalen E2E in der Teststufe GIT-TI dienen der Überprüfung der Gesamtfunktionalität der Telematikinfrastruktur. Hierbei wird sowohl das Zusammenspiel aller Produkte als auch deren individuelle Funktionalität getestet. Der besondere Fokus liegt hier auf der End-to-End-Funktionalität. Diese Teststufe wird in zwei Phasen unterteilt: Phase 1: Es werden die Use Cases mit höchster Priorität (Prio 1) getestet. Wenn diese Tests erfolgreich (keine Freigabeverhindernden Fehler (FF)) abgeschlossen werden, sind die Testobjekte als Release-Kandidaten bestätigt. Nach Abschluss dieser Phase erfolgt die Installation der Testobjekte in der Referenzumgebung (RU). Phase 2: Es sind weitere Testdurchführungen der Ende-zu-Ende Szenarien und Fehlerbehebungen vorgesehen.
Ziel	Ziel ist es, die Gesamtfunktionalität zu prüfen. Zudem können Produkte oder Anwendungen identifiziert werden, die noch nicht betriebsbereit sind. Denn für diese muss dann jeweils die Go-Live-Planung entsprechend angepasst werden.
Testobjekt	Gesamtsystem der Telematikinfrastruktur als integrierte Einheit
Umgebung	Testumgebung (TU)

---

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 4: Tab_Test_035 Generalprobe

Testphase	Zulassungstest (ZulT)
Teststufe	Gesamtintegrationstest (GIT-TI)
Testart	Generalprobe
Beschreibung	Die Generalprobe wird als Deployment-Orchestrierungstest durchgeführt und überprüft die gesamte Prozesskette des Deployments. Dabei liegt der Schwerpunkt darauf, dass alle Produkte  und Systeme reibungslos deployed werden. Nach dem Deployment wird die nahtlose Zusammenarbeit aller Komponenten durch dedizierte End-to-End (E2E) Tests überprüft. Diese Tests simulieren reale Anwendungsszenarien und validieren die Funktionalität des Gesamtsystems.
Ziel	Ziel der Generalprobe ist es, die Deployment-Prozedur der TI-Produkte in ihrer Gesamtheit zu validieren. Insbesondere werden Reihenfolge und Abhängigkeiten der einzelnen Systeme berücksichtigt. Damit wird sichergestellt, dass alle Komponenten reibungslos und im richtigen Ablauf zusammenarbeiten. Nicht nur die Installations-, Konfigurations- und Integrationsprozesse getestet, sondern auch mögliche Schwachstellen aufgedeckt, die im Zusammenspiel der verschiedenen Systeme auftreten können. Ein weiterer wichtiger Aspekt der Generalprobe ist die Überprüfung der Rollback- und Wiederherstellungsverfahren, um sicherzustellen, dass das Produkt im Falle eines Fehlers schnell und effizient zurückgesetzt oder wiederhergestellt werden kann: Validierung der Deployment-Reihenfolge: Sicherstellen, dass die Reihenfolge der Deployments korrekt und optimal ist, um die Integrität und Funktionalität des Gesamtsystems zu gewährleisten. Überprüfung der Abhängigkeiten und Interoperabilität: Es wird sichergestellt, dass alle Abhängigkeiten zwischen den verschiedenen Komponenten und Services korrekt berücksichtigt und erfüllt sind. Zusätzlich wird die Interoperabilität, also die nahtlose Zusammenarbeit und Kommunikation zwischen den Systemen, getestet, um einen reibungslosen Datenaustausch und eine korrekte Funktionalität im Zusammenspiel zu gewährleisten. Koordination zwischen Teams (eher für den Betrieb/OPS): Sicherstellen, dass alle beteiligten Teams (Entwicklung, QA, Operations) synchronisiert arbeiten und die Deployment-Aktivitäten gut koordiniert sind Dokumentation und Berichterstattung: Aufzeichnung der Deployment-Aktivitäten sowie der Testergebnisse zur Unterstützung bei der Entscheidungsfindung und zur weiteren Optimierung des Deployment-Prozesses.
Testobjekt	Vollständige Prozesskette des Deployments, einschließlich: Installations- und Konfigurationsprozesse Integrationsprozesse Rollback- und Wiederherstellungsverfahren
Umgebung	Referenzumgebung (RU)

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 5: Tab_Test_036 Leistungstest

Testphase	Zulassungstest (ZulT)
Teststufe	Gesamtintegrationstest (GIT-TI)
Testart	Leistungstest
Beschreibung	Die Leistungstests überprüfen, mit welcher Qualität die Produkte und Anwendungen ihre Funktionen unter Last erbringen. Dabei können je nach Anforderungen Qualitätsmerkmale wie Leistungsfähigkeit, Zuverlässigkeit betrachtet werden. Im Umfang des Leistungstests befinden sich anforderungsbasiert die folgenden Tests: Performanztest: Überprüfung des geforderten Antwortzeit- und Durchsatzverhaltens (Verarbeitungsgeschwindigkeit) definierter Anwendungsfällen, in Abhängigkeit steigender Last. Lasttest: Prüfung des Systemverhaltens bei steigender Last unter Nutzung unterschiedlicher Lastmodelle. Stresstest: Beobachtung des Systemverhaltens bei und nach Überlast. Robustheitstest: Prüfung, ob sich Produkte und Anwendungen bei Ausfall von aufgerufenen Produkten (z. B. Hardwareausfall) entsprechend robust verhalten. Dabei werden auch Fehlerbehandlung und Wiederanlaufverhalten (Recovery) betrachtet.
Ziel	Ziel des Leistungstests ist die Überprüfung und Sicherstellung der Qualität und Effizienz der Produkte und Anwendungen unter verschiedenen Lastbedingungen.
Testobjekt	Gesamtsystem der Telematik Infrastruktur als integrierte Einheit
Umgebung	Referenzumgebung (RU)

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 6: Tab_Test_037 Interoperabilitätstests TI-Primärsysteme

Testphase	Zulassungstest (ZulT)
Teststufe	Gesamtintegrationstest (GIT-TI)
Testart	Interoperabilitätstests TI-Primärsysteme
Beschreibung	Diese Teststufe zielt darauf ab, die Interoperabilität zwischen der Telematikinfrastruktur und den angeschlossenen peripheren Systemen umfassend zu prüfen und zu bestätigen.
Ziel	Ziel ist der Nachweis der korrekten funktionalen Interaktion zwischen der TI und den verschiedenen peripheren Systemen, mit besonderem Fokus auf die Interoperabilität der Primärsysteme mit der TI.
Testobjekt	Schnittstellen zwischen TI und Primärsystemen
Umgebung	Referenzumgebung (RU)

5.2 Eingangs- und Ausgangskriterien, Testabbruch

## Das ist ein neues Kapitel, das nach den Testsstufen 4.5 in das [gemKPT_Test] eingefügt wird. Es ersetzt die Eingangs-, Ausgangs- und Abbruchskriterien in den Tabellen [Tab_Test_005] und [Tab_Test_006].

Dieses Kapitel beschreibt die grundlegenden Rahmenbedingungen für die Durchführung und Bewertung von Teststufen im Zulassungsprozess. Es definiert klare Kriterien für den Beginn (Eingangskriterien) und den Abschluss (Ausgangskriterien) jeder Teststufe sowie die Bedingungen für einen möglichen Testabbruch.

Die jeweiligen Eingangs- und Ausgangskriterien für die Eigenverantwortlichen Tests (EvT) sind in den Testkonzepten zu definieren. Eingangs- und Ausgangskriterien der Zulassungstests (ZulT) sind von der gematik in den jeweiligen Prozessen festgelegt.

Hinweis: In den folgenden Anforderungen beziehen sich die Begriffe "testdurchführende Instanz" auf den Zulassungsnehmer und "Test- und Transitionmanager" auf den Testansprechpartner der gematik.

5.2.1 Eingangskriterien

Eingangskriterien beschreiben Mindestkriterien für den Beginn einer Testphase bzw. deren jeweiligen Teststufen. Durch die Definition und Prüfung von Eingangskriterien ist ein effizienter Test in einer Testphase bzw. einer Teststufe gewährleistet.

Wenn Eingangskriterien nicht wie gefordert erfüllt sind, muss eine Risikobewertung vorgenommen und dokumentiert werden. Darin sollen folgende Punkte adressiert werden:

• Auswirkung auf den Zeitplan – z. B.: Können Teile des Tests erst später (nach Vorliegen der Eingangskriterien) durchgeführt werden? Was sind die Auswirkungen auf den Gesamtplan?
• Auswirkung auf die Qualität der Testergebnisse und des Tests - z. B.: Können bestimmte Testfälle nicht durchgeführt werden?
• Auswirkung auf die Kosten des Tests - z. B.: Müssen Testfälle angepasst werden? Müssen ggf. Simulatoren entwickelt und eingesetzt werden? Müssen Testfälle mehrfach durchgeführt werden (nach Korrektur von möglichen Fehlern aus den vorigen Testphasen)?

5.2.1.1 Eingangskriterien für die Teststufe PüT:

Die Festlegung von Eingangskriterien für die PüT gewährleistet, dass alle notwendigen Bedingungen erfüllt sind, bevor die Testdurchführung startet.

• Die Eigenverantwortlichen Tests (EvT) sind abgeschlossen, die Testergebnisse liegen vor.
• Ein Behebungsplan für die identifizierten und noch offenen Fehler liegt vor.
• Die Testumgebung (TU) steht zur Verfügung.
• Die erforderliche Testdokumentation wurde erstellt und geliefert.
• Das Testobjekt wurde komplett erstellt und geliefert.
• Testdaten, Testkarten und alle Konfigurationsdaten (inkl. Bereitstellung von Zertifikaten) liegen vor.

5.2.1.2 Eingangskriterien für die Teststufe GIT-TI

 Die Festlegung von Eingangskriterien für die GIT-TI gewährleistet, dass alle notwendigen Bedingungen erfüllt sind, bevor die Testdurchführung startet.

• Die Ausgangskriterien der Produktübergreifenden Tests sind erfüllt.
• Die Testumgebung (TU) und die Referenzumgebung (RU) stehen zur Verfügung.
• Die erforderliche Testdokumentation wurde erstellt und geliefert.
• Testdaten, Testkarten und alle Konfigurationsdaten (inkl. Bereitstellung von Zertifikaten) liegen vor.

5.2.2 Ausgangskriterien

Ausgangskriterien beschreiben Mindestkriterien für den Abschluss einer Testphase, bzw. deren jeweiligen Teststufen. Erst wenn diese Kriterien erfüllt sind, ist die Testphase beendet.

Wenn Ausgangskriterien nicht wie gefordert erfüllt sind, muss eine Risikobewertung vorgenommen und dokumentiert werden. Darin sollen folgende Punkte adressiert werden:

• Auswirkung auf die Qualität der Testergebnisse und des Tests - z. B.: Können bestimmte Testfälle nicht durchgeführt werden?
• Auswirkung auf die Kosten des Tests - z. B.: Müssen Testfälle angepasst werden? Müssen Simulatoren entwickelt und eingesetzt werden? Müssen Testfälle mehrfach durchgeführt werden (nach Korrektur von möglichen Fehlern aus den vorigen Testphasen)?

Hinweis: Die Kriterien für den jeweiligen Produkttyp sind aus dem Produkttypsteckbrief zu entnehmen.

5.2.2.1 Ausgangskriterien für die Teststufe PüT

Die Festlegung von Ausgangskriterien für die PüT gewährleistet, dass alle notwendigen Bedingungen erfüllt sind, bevor der Übergang zur nächsten Phase erfolgt.

• Der erforderliche Testabdeckungsgrad und Testumfang wurde erreicht.
• Die erforderliche Testdokumentation wurde erstellt.
• Ein Behebungsplan für die erkannten und noch offenen Fehler liegt vor.

5.2.2.2 Ausgangskriterien für die Teststufe GIT-TI

Die Festlegung von Ausgangskriterien für GIT-TI gewährleistet, dass alle notwendigen Bedingungen für eine Zulassungsempfehlung erfüllt sind.

• Der erforderliche Testabdeckungsgrad und Testumfang wurde erreicht.
• Die erforderliche Testdokumentation wurde erstellt.
• Es liegen keine zulassungsverhindernden Fehler vor.

5.2.3 Abbruch

Der Zulassungstest kann grundsätzlich in jeder Testphase bzw. Teststufe sowohl durch den Zulassungsnehmer als auch durch die gematik abgebrochen werden.

Die gematik behält sich einen Abbruch der Zulassungstests insbesondere dann vor, wenn abweichende Ergebnisse gegenüber den dokumentierten Ergebnissen zu Eigenverantwortlichen Tests ermittelt werden oder aus den Ergebnissen der bereits durchgeführten Testfälle hinreichend und objektiv ersichtlich ist, dass das Testobjekt Fehler enthält, aufgrund derer eine Zulassung nicht erteilt werden kann.

Dies ist vor allem dann gegeben, wenn wesentliche Funktionalitäten bzw. Anforderungen nicht, nicht vollständig oder fehlerhaft umgesetzt wurden.

Die gematik wird den Antragsteller über das Vorliegen von Gründen für einen Testabbruch schriftlich informieren, einschließlich der Auswertung der bis dahin festgestellten Fehler.

5.3 Interoperabilität

## Das Kapitel 4.6 des [gemKPT_Test] wird angepasst. Der Text bis zur Abbildung dient hier lediglich der Verortung und zur Hinführung für diese Anpassung. Die Abbildung wird ersetzt.

Um die korrekte funktionale Zusammenarbeit der Produkte untereinander nachzuweisen, müssen im Rahmen der Interoperabilitätstests die anwendungsfallbasierten Tests mit vielen verschiedenen Produktkombinationen durchgeführt werden. Allerdings würde die Abdeckung aller möglichen Produktkombinationen zu einer zeitlich und wirtschaftlich nicht vertretbaren Menge von Tests führen. Somit muss die Interoperabilität mit einer begrenzten, aber fachlich ausreichenden Mindestanzahl von Produkten der beteiligten Produkttypen und anderer am Anwendungsfall beteiligter Komponenten nachgewiesen werden. Nachfolgende Tabelle zeigt für die zuzulassenden oder freizugebenden Produkte die Mindestanzahl der Interoperabilitätspartner. Zum Beispiel müssen für den Konnektor (VSDM) die VSDM-Anwendungsfälle mit mindestens drei verschiedenen eHealth-Kartenterminals und drei Fachdiensten nachgewiesen werden. Es muss dabei aber nicht jedes Kartenterminal mit jedem Fachdienst kombiniert werden.

## Diese Afo wird dem Produkt "VSDM2.0_FD" mit dem Prüfverfahren "funkt. Eignung: Test" zugeordnet werden.

Bei den Angaben zur Mindestanzahl wird davon ausgegangen, dass ausreichend viele Referenzobjekte bzw. geeignete Testobjekte vorhanden sind. Sollte die geforderte Anzahl nicht vorliegen, können in Abstimmung mit dem Testansprechpartner Gegenmaßnahmen definiert werden.

## Die Abbildung ist um weitere Produkte erweitert worden.

Abbildung 3 : Interoperabilitätstabelle

a = alle zugelassenen

1) soweit verfügbar

2) QES-Signatur-Erstellen bzw. überprüfen

3) bei Verwendung mit einem VPN-Zugangsdienst

4) bei Verwendung in einem TI-Gateway

5) verschiedene Fachdienste KIM müssen untereinander interoperabel sein

6) FdVs in den Ausprägungen Android, iOS, Desktop Client des Herstellerkonsortiums sowie eine Ausprägung eines anderen FdV-Herstellers.

7) Ergebnisse eines Dokumentenhandlings via KON oder FdV muss auf der jeweils anderen Seite sicht- und prozesszierbar sein. Es sind FdV’s in zwei verschiedenen Ausprägungen (Android, iOS oder Desktop Client zu verwenden).

8) Ergebnisse eines Dokumentenhandlings via KON oder FdV muss auf der jeweils anderen Seite sicht- und prozesszierbar sein.

9) Nur, wenn die Option KTR-Consumer mit einem KIM-CM gewählt ist.

10) Der Test kann mit einem hersteller-eigenen und muss mit einem -fremden Primärsystem durchgeführt werden

11) Auch integriertes Clientmodul

12) incl. Gerätekarten gSMC-K und gSMC-KT

13) Alle zugelassenen Clientmodule

14) Alle zugelassenen Fachdienste

15) Gilt nicht für integriertes Clientmodul

16) gilt nicht für integriertes Clientmodul, wenn IOP mit E-Mail-Client (auch PVS)

19) nur Operationen checkRecordExists und getExportPackage

20) Der Hersteller des ePA-Frontend des Versicherten testet die Interoperabilität gegen das ePA-Aktensystem seines Herstellerkonsortiums. Der Anbieterwechsel ist mit zwei weiteren Aktensystemen zu prüfen.

21) soweit alternative Authentisierung unterstützt wird

22) Jeder Hersteller eines TI-M Fachdienstes muss einen Org-Admin Client bereitstellen

23) Eine Versicherter-Versicherter Kommunikation kann nur durch einen Akteur, der nicht die Rolle Versicherter hat, eingeleitet werden.

24) Der Hersteller eines Basis-Consumers muss IOP-Tests mit einem KIM-Fachdienst von einem anderen Hersteller durchführen. neu

25) Der Hersteller nutzt den PoPP Token in unterschiedliche Konstellation, dabei müssen folgende Konstalationen mindestens  getestet werden,  

Zwei (2) elektronische Gesundheitskarten (eGK) von unterschiedlichen Anbietern (incl. zugehörige TSP X.509 nonQES und TSP CVC) 

Ein (1) Einbox Konnektor (EBK)

Ein (1) Highspeed Konnektor (HSK)

Zwei (2) SM(C)-B von unterschiedlichen Anbietern (incl. zugehörige TSP X.509 nonQES und TSP CVC)

Ein (1) sektoraler Identitätsprovider (IDP)

5.4 Testdokumentation

## Das Kapitel 4.7 des [gemKPT_Test] wird um den Fehlerbehebungsplan und das Fehlermanagement erweitert. Der einführende Text bis zum Abschnitt 5.4.1 dient hier lediglich der Orientierung.

Für die Dokumentation der Testaktivitäten der verschiedenen Testphasen und Teststufen sollen durch den Zulassungsnehmer unterschiedliche Dokumente erstellt werden.

Diese Testdokumentation eines Zulassungsnehmers soll dabei einheitlich strukturiert sein und zugleich alle relevanten Informationen konsolidiert vorlegen (z.B. von Subunternehmen).

Der genaue Lieferzeitpunkt der Dokumente ist pro Test jeweils als Eingangs- bzw. Ausgangskriterium definiert.

Hinführung u. nach Testbereicht 4.7.6 kommt das neu

5.4.1 Fehlerbehebungsplan

5.5 Fehlermanagement

Ein verteiltes System mit verschiedenen Zulassungsnehmern und Stakeholdern erfordert ein abgestimmtes Fehlermanagement. Ab dem Beginn der Zulassungstests ist die enge Zusammenarbeit aller Beteiligten in einem gemeinsamen System (Jira) notwendig. 

Je nach Entdecker und Adressat einer Abweichung gelten unterschiedliche Workflows und Zuständigkeiten. Während jeder Teststufe können Fehler auftreten. Für jeden Testfall wird ein Erfolgreich-/Fehlgeschlagen-Kriterium festgelegt, das die erwarteten Ergebnisse bewertet. Werden diese nicht erreicht, analysiert der Tester die Fehlerursache und entscheidet, ob es sich um einen externen Produktfehler oder einen internen Fehler (z.B. in der Spezifikation oder dem Testskript) handelt.

5.5.1 Fehlerschweregrade

Die gematik verwendet für die Klassifizierung von Fehlern die folgenden Schweregrade:

Schweregrad „Sehr schwer“: Das betroffene Testobjekt oder eine wesentliche Funktionalität sind nicht nutzbar. Es gibt keine Problemumgehung, um die fehlende oder fehlerhafte Funktion auszuüben. Das Testobjekt kann nicht eingesetzt werden.

Schweregrad „Schwer“: Das betroffene Testobjekt oder eine wesentliche Funktionalität ist nur mit großen Einschränkungen nutzbar. Es besteht die Gefahr von Datenverlust, Speicher- und Performanzproblemen. Es ist jedoch möglich, durch eine Problemumgehung die Funktionalität dennoch zur Verfügung zu stellen. Das Testobjekt könnte auch dann nur mit Einschränkungen für die Nutzer eingesetzt werden.

Schweregrad „Mittel“: Das betroffene Testobjekt oder eine wesentliche Funktionalität ist nur mit geringfügigen Einschränkungen, welche nicht den Nutzer betreffen, einsetzbar.

Schweregrad „Leicht“: Die gefundenen Mängel haben keine Auswirkungen auf die Funktionalität oder Leistungsfähigkeit des Testobjekts. Das betroffene Testobjekt ist ohne Einschränkungen nutzbar. Es handelt sich um geringfügige Abweichungen, wie z. B. Rechtschreibfehler in Meldungstexten.

6 Systemumgebungen

## Der übergreifende Teil von Kapitel 3 und das Unterkapitel 3.1 des [gemKPT_Test] wird durch diesen Abschnitt 6 ersetzt. Damit wird über diese C_12020_Anlage die C_12019_Anlage erweitert.

Für die Testdurchführung sind verschiedene Umgebungen vorgesehen, die jeweils spezifische Zwecke erfüllen und individuell zu nutzen sind:

• Vorintegrationsumgebung (RU DEV)
• Testumgebung (TU)
• Referenzumgebung (RU)

6.1 Vorintegrationsumgebung (RU DEV)

Die RU DEV ist eine flexible Entwicklungsumgebung, in der Hersteller schnell Änderungen vornehmen und testen, ohne einen formalen Änderungsprozess durchlaufen zu müssen. Sie dient der Vorintegration und ermöglicht z.B. entwicklungsbegleitende Interoperabilitätstests mit Primärsystemen im Vorfeld der offiziellen Zulassung. Diese Vorstufe zur Testumgebung (TU) erfüllt folgende zentrale Funktionen:

• frühzeitige Erkennung von Integrationsproblemen in der Telematikinfrastruktur (TI)
• Ermöglichung einer schrittweisen und gezielten Integration von Primärsystemen und Anwendungen
• Identifikation potenzieller Interoperabilitätsprobleme vor Beginn der offiziellen Zulassungsphase
• Bereitstellung einer Testplattform für Primärsystemhersteller zur iterativen Produktintegration
• Schaffung eines kontrollierten Raums für Tests und notwendige Anpassungen vor der Überführung in die TU

Für diese Umgebungen können, falls Echtkomponenten noch nicht bereitgestellt werden können, auch Simulatoren und Mocks eingesetzt werden.

6.2 Testumgebung (TU)

Die Testumgebung (TU) ist eine zentrale Komponente in der Testinfrastruktur der gematik. Sie ist speziell für die Durchführung umfassender Ende-zu-Ende (E2E)- und Interoperabilitätstests ausgelegt. Darüber hinaus dient sie als realitätsnaher Aufbau der gesamten Telematikinfrastruktur. und ermöglicht die Integration und Prüfung aller relevanten Produkte in einem kontrollierten Umfeld.

Die TU wird primär für die Durchführung von funktionalen Zulassungstests genutzt.

Um die Integrität der Umgebung sicherzustellen, sind strenge und produktionsnahe Zugangskontrollen und Sicherheitsmaßnahmen eingeführt worden.

6.3 Referenzumgebung (RU)

Diese Umgebung dient als Referenz für die Telematikinfrastruktur und unterstützt folgendes:

• Durchführung von Generalprobe 
• Durchführung von Leistungstests
• Reproduktion von Fehlern aus der Produktivumgebung
• Ausführung von Hotfix- und Emergency-Tests
• Bereitstellung von Serviceprodukten durch die gematik
• Unterstützung bei der Entwicklung neuer Anwendungen für Dritte
• Förderung der Ende-zu-Ende-Verantwortung von Herstellern und Anbietern

Die RU wird von Herstellern und interessierten Teilnehmern , wie Universitäten, für Schulungszwecke genutzt. Der dezentrale Bereich wird von Industriepartnern (Enabler) unabhängig organisiert. Dies ermöglicht eine flexible und praxisnahe Nutzung der Umgebung für verschiedene Zwecke innerhalb der TI.

In den nachfolgenden Kapiteln sind die Umgebungen und die Anforderungen an diese beschrieben.

6.4 Überblick

Jede der Umgebungen ist in einen zentralen und einen dezentralen Bereich unterteilt, um die unterschiedlichen Aspekte der TI-Infrastruktur abzubilden.

Die folgende Tabelle gibt einen Überblick über die Leistungen und Funktionen der jeweiligen Umgebungen für die verschiedenen Testphasen:

## Die Referenzierung wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 7 : Tab_Test_0xx Überblick Umgebungen im Rahmen von Test

Umgebung	Ziele	Teststufe
Vorintegrations-umgebung (RU DEV)	Ergänzung der Entwicklungsumgebungen der Zulassungsnehmer von Produkten IOP Tests Durchführung von Connectathons Zulassungsnehmern wird Zugang zur RU DEV in Abstimmung mit der gematik gewährt	EvT
Testumgebung (TU)	Separate Testumgebung für die Durchführung von funktionalen Tests im Rahmen der Zulassungstests Nachstellung von Fehlern Dauerhafte Einrichtung für die Durchführung von Zulassungstests neuer Produkte oder Produktversionen	Produktübergreifender Test (PüT) Gesamtintegrationstest (GIT-TI)
Referenzumgebung (RU)	Deploymenttests aller Produkte Leistungstests Durchführung von Hotfix-Tests Durchführung von Connectathons RU as a Service	Gesamtintegrationstest (GIT-TI)

## Die folgenden AFOs werden lediglich zum besseren Verständnis des Zusammenhangs aufgelistet.

## Die ab hier folgenden AFOs werden angepasst.

## Alt

## Neu

## Alt 

## Neu

6.5 Vorgeschriebene Integration

## Das Kapitel 4.6 des [gemKPT_Test] erhält durch diesen Abschnitt 6.5 ein Unterkapitel.

Für jede TI 2.0-Komponente sind verschiedene Integrationsmaßnahmen vorgeschrieben und müssen durch Tests überprüft werden.

7 Glossar

## Dieser Abschnitt erweitert den Glossar des [gemKPT_Test] unter dem Kapitel 12.2.

Begriff	Erläuterung
Connectathon	Der gematik Connectathon ist eine Veranstaltung, bei der Dienste und Komponenten auf ihre Interoperabilität getestet werden.