C_12020_Anlage

Produktübergreifende Änderungen in gemKPT_Test

Inhaltsverzeichnis

1 Disclaimer

Disclaimer

Die Hinweise für diese Anlage zur iterativen Einführung der Teststrategie und zur Einführung von Solution Trains: Die vorliegende Dokumentation konzentriert sich ausschließlich auf das Testkonzept und die damit verbundenen Prozesse und Aktivitäten bis zum Abschluss der GIT-Phase (Gesamtintegrationstest). Aspekte, die die Phase nach dem GIT betreffen, wie z. B. die iterative Einführung von Lösungen oder die Einführung von Solution Trains, sind nicht Bestandteil dieses Dokuments. Die Einführung von Solution Trains wird separat behandelt und folgt einem strukturierten Vorgehen, das in einem eigenständigen Dokument detailliert beschrieben wird. Dieses Dokument wird die Anforderungen und Prozesse für die iterative Einführung neuer Releases und Solution Trains umfassend abdecken. Die hier beschriebenen Testaktivitäten stellen jedoch eine wesentliche Grundlage für die Einführung von Solution Trains dar und unterstützen den Übergang in die nachgelagerten Phasen.

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 der Telematikinfrastruktur, die gemäß den gesetzlichen Vorgaben des SGB V vorgesehen 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:

•  TI-Gateway, EBK, HSK und Kartenterminals für die Anbindung von Praxen und Krankenhäusern
• Fachdienste wie elektronische Patientenakte (ePA), TI-Messenger (TI-M) und weitere
• Frontend des Versicherten (FdV)  und Client Systeme - hierzu zählen ePA FdV und weitere
  
• Zentrale Dienste wie Namensdienst oder Zeitdienst und weitere
• Sicherheitsinfrastruktur für die Authentifizierung und Verschlüsselung wie Zero Trust und weitere

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. Dabei werden keine medizinischen Daten validiert.
• 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.

Darüber hinaus gibt es weitere Rollen, die spezifische Aufgaben innerhalb des Testprozesses übernehmen:

• Auftragnehmer (AN):
  Der Auftragnehmer ist eine besondere Rolle und in der Regel ein Hersteller, der von der gematik mit einer spezifischen Entwicklungsleistung beauftragt wird. Diese Entwicklungsleistung umfasst in der Regel auch die Durchführung von Tests. Das entwickelte Produkt muss anschließend eine Zulassung erhalten, bevor es in der Telematikinfrastruktur (TI) eingesetzt werden kann.
  
• Primärsystemhersteller:
  Primärsystemhersteller entwickeln Softwarelösungen, die von Leistungserbringern wie Arztpraxen, Apotheken oder Krankenhäusern genutzt werden, um Patientendaten zu verwalten und mit der TI zu kommunizieren.
  Je nach Produkt unterliegen Primärsysteme einer Konformitätsbewertung oder einem Bestätigungsverfahren, die teilweise freiwillig sind. Diese Bewertung und dieses Verfahren stellen sicher, dass die Systeme TI-konform sind und die Anforderungen der gematik erfüllen.
  Die Primärsystemhersteller sind für die Integration und die Qualitätssicherung ihrer jeweiligen Systeme selbst verantwortlich. Sie stellen sicher, dass ihre Systeme die Anforderungen der TI erfüllen und vollständig mit den zugelassenen Komponenten interoperabel sind.

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 der §§ 324 ff 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 Testansprechpartner, einschließlich der Vereinbarung von Lieferterminen, Wartungen, Ausfallzeiten (inkl. Changes)

• Umgebungsmanagement:
• Bereitstellung und Konfiguration der Zulassungsobjekte in den vorgegebenen Umgebungen
• Die Einbringung der Testobjekte in alle Systemumgebungen erfolgt über den betrieblichen Change Prozess.
• Herstellung der Testbereitschaft inklusive Bereitstellung der Release Notes 
• Unterstützung beim Nachstellen und Analysieren von auftretenden Fehlern in den Umgebungen

4.2 Testansprechpartner gematik

Der Testansprechpartner erfüllt den gesetzlichen Testauftrag hinsichtlich § 291b SGB V und prä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 in der RU DEV  sowie in der Zulassungstestphase in der RU
• Planung und Steuerung der Zulassungstests für  funktionale sowie Leistungstests
• 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):
• informatives Mitglied, das durch die Bereitstellung von Testergebnissen und Erkenntnissen die Entscheidungsfindung unterstützt
• 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.

Disclaimer
Übergreifende Hinweise zur Rolleninterpretation: In den folgenden Kapiteln beziehen sich die Begriffe "testdurchführende Instanz (TDI)" und "Testbetriebsinstanz (TBI)" auf den Zulassungsnehmer. Die Begriffe "Test- und Transitionmanager" 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)

Disclaimer

Aufgrund des iterativen Vorgehens bei der Einführung des neuen Testprozesses gilt: Produkte, die nach dem bisherigen Verfahren getestet werden, können die EVT-Prüfung weiterhin in der Referenzumgebung (RU) durchführen. Produkte, die dem neuen Testverfahren unterliegen, müssen die EVT-Prüfung in der Entwicklungsumgebung (RU DEV) ausführen. Diese Übergangsregelung gewährleistet eine reibungslose Migration zum neuen Testprozess, während laufende Projekte nicht beeinträchtigt werden.

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"

## Alt:

Tabelle 1 : Tab_Test_005 Eigenverantwortlicher Test (EvT)

Testphase	Eigenverantwortlicher Test
Beschreibung	In der Testphase „Eigenverantwortlicher Test“ werden die entwickelten Produkte durch die Hersteller gegen die Anforderungen aus den zugrundeliegenden Konzepten und Spezifikationen, welche in dem jeweiligen Produkttypsteckbrief zusammengefasst sind, geprüft. Dies schließt die Erfüllung der fachlichen Anforderungen (Ende-zu-Ende), der funktionalen technischen Anforderungen, der nicht-funktionalen Anforderungen und der Sicherheitsanforderungen sowie eine vollständige Integration ihres jeweiligen Produkts ein. Die Anforderungen sind in der Regel der jeweils neusten Version einer Spezifikation bzw. eines Konzepts zu entnehmen.
Ziel	Nachweis der Erfüllung der an das jeweilige Produkt gestellten Anforderungen aus den zugrundeliegenden Konzepten und Spezifikationen. Nachweis der Durchführbarkeit von den Anwendungsfällen an welchen die Produkte beteiligt sind.
Eingangskriterien	Die Systemumgebung (SU) steht zur Verfügung. Die erforderliche Testdokumentation wurde erstellt und geliefert (Testkonzept, einzelne Testspezifikationen, ggf. Dokumente zu Produktausprägungen). Das funktionierende Testobjekt wurde geliefert oder in der RU bereitgestellt. Das in Betrieb genommene Testobjekt wurde in der Referenzumgebung vollständig installiert und konfiguriert.
Ausgangskriterien	Die erforderliche Testdokumentation wurde inkl. vollständiger Testfallspezifikation erstellt und geliefert (Release Notes, Produktdokumentation, Testprotokoll, Testbericht) und von der gematik stichprobenartig geprüft. Es liegen keine zulassungstestverhindernden Probleme vor. Der vorab zwischen TDI RU und Test- & Transitionmanager vereinbarte Testabdeckungsgrad und Testumfang wurde erreicht und dokumentiert.
Testdokumentation/ Leistungsgegenstände	Testkonzept Testspezifikation inkl. Testfallspezifikationen Testprotokoll der Eigenverantwortlichen Tests Testbericht der Eigenverantwortlichen Tests Release Notes Produktdokumentation
Teststufen	Produkttest (EvT) Produktübergreifender Test (EvT)
Systemumgebung	Referenzumgebung
Aufgaben des Test- und Transitionmanagers	Prüfen, ob die Ausgangskriterien der Eigenverantwortlichen Tests erfüllt sind. Sind die Testausgangskriterien nicht erfüllt, gilt die Testphase als nicht abgeschlossen.
Aufgaben des TIZP	Anbindung des Testobjekts an das zentrale Netz und Konfiguration des zentralen Netzes (z. B. Firewallfreischaltung, IP-Adressvergabe, DNS-Vergabe)
Aufgaben der TBI	Sicherstellung der Verfügbarkeit des eigenen - am Test beteiligten - Produkts (Referenzobjekt) (detaillierte Anforderungen siehe Kapitel  ).
Aufgaben der TDI RU	Durchführung der Tests. Tests dürfen in Absprache mit dem Test- und Transitionmanager auch mittels Simulatoren durchgeführt werden. Bereitstellung der erforderlichen Testdokumentation. Im Rahmen der Testmaßnahmen die jeweils relevanten Clientsysteme berücksichtigen und in die Testmaßnahmen einbinden. Den Umfang von Regressionstests bei der Planung von Tests für neue Versionen der Fachanwendung bzw. der Produkte in Absprache mit dem Test- & Transitionmanager der gematik festlegen. Pflege der eigenen Tests im Testkalender
Pflichten Hersteller und Anbieter	Nach Vorgabe der gematik die qualitätssichernden Maßnahmen unterstützen und auf Anfrage der gematik Produktmuster inkl. einer (Vorab-) Version der Produktdokumentation liefern. Lieferung oder Anbindung des Testobjekts. Für ihren jeweiligen Produkttyp die relevanten Teststufen, Testarten und Testdaten unterstützen. Bereitstellung der erforderlichen Testdokumentation.

## Neu:

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

Tabelle 2 : Tab_Test_005_01 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 werden. 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. Zusätzlich müssen noch vor Beginn der Zulassungstestphase folgende Dokumente von den Zulassungsnehmern bereitgestellt werden: - Testspezifikation - Release Notes - Produktdokumentation - Testprotokoll - Testbericht Diese Dokumente dienen als Nachweis der erfolgreichen Durchführung der EvTs und sind Voraussetzung für den Start der Zulassungstestphase. 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

## Diese Afo wird wegen der neuen Tabelle [Tab_Test_005_01] für die speziellen Produkte angepasst.

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 Referenz der Tabelle wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 3: 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, an den Produkten mit gemeinsamen Schnittstellen und gemeinsamer Datennutzung 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)
Form des Nachweises	Testbericht
Zusätzliche Information	Die Produktzulassung wird aus Testsicht nach erfolgreichem Abschluss der PüT Teststufe erteilt, allerdings mit der Auflage, dass die Produkte an dem GIT-TI beteiligt sein müssen. Die Zulassung wird mit einem Widerrufsvorbehalt für den Fall erteilt, dass im GIT-TI schwerwiegende Fehler am Produkt aufgedeckt werden, die zu einem Widerruf der Zulassung führen.

5.1.2.2 Gesamtintegrationstest (GIT-TI)

Die Teststufe Gesamtintegrationstest umfasst mehrere Testarten, die jeweils spezifische Schwerpunkte prüfen. Bei allen Testarten wird sichergestellt, dass die Tests zielgerichtet auf das Zulassungsobjekt ausgerichtet sind. Die Tests konzentrieren sich darauf, die Integration und Funktionalität des Zulassungsobjekts im Kontext der gesamten Telematikinfrastruktur zu überprüfen, sodass die Ergebnisse der Tests direkt Aufschluss über das Zulassungsobjekt geben. Die Testarten umfassen:

• Funktionale Tests (TU)
• Generalprobe (RU)
• Leistungstest (RU)
• Möglichkeit zu Interoperabilitätstests mit Primärsysteme (RU)

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.

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

Tabelle 4: 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: Diese werden auf Basis von Risikobetrachtung und Stakeholder-Abstimmung ausgewählt, wobei Kritikalität, Nutzungshäufigkeit und potenzielle Auswirkungen berücksichtigt werden. Erfolgreiche Tests führen zur Bestätigung der Release-Kandidaten und deren Installation in der RU. Phase 2: Es sind weitere Testdurchführungen der funktionalen Ende-zu-Ende-Szenarien und Fehlerbehebungen vorgesehen.
Ziel	Ziel ist es, die Gesamtfunktionalität zu prüfen. Dabei wird sowohl das Zusammenspiel aller Produkte als auch deren individuelle Funktionalität getestet. Dies schließt ein, dass die End-to-End-Funktionalität der gesamten Infrastruktur im Kontext der spezifischen Zulassungsobjekte geprüft wird.
Testobjekt	Das Testobjekt umfasst das Gesamtsystem der Telematikinfrastruktur als integrierte Einheit. Dabei werden alle Komponenten und Produkte getestet, die für die Zulassung relevant sind. Jedes Zulassungsobjekt wird im Kontext seiner spezifischen Funktionalität und Integration innerhalb der TI geprüft.
Umgebung	Testumgebung (TU)

---

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

Tabelle 5: Tab_Test_035 Generalprobe

Testphase	Zulassungstest (ZulT)
Teststufe	Gesamtintegrationstest (GIT-TI)
Testart	Generalprobe
Beschreibung	Die Generalprobe (GP) findet in der Referenzumgebung (RU) statt, nachdem die einzelnen Testobjekte in der funktionalen GIT-TI Teststufe in der Testumgebung (TU) für die GP freigegeben wurden. In dieser Phase wird die Installation im Rahmen eines Deployment-Orchestrierungstest durchgeführt, dabei die gesamte Prozesskette des Deployments überprüft wird. Die GP konzentriert sich primär auf Fachanwendungen, während dezentrale Komponenten implizit mitgetestet werden. Dezentrale Komponenten, die ein zentrales Deployment erfahren, werden ebenfalls berücksichtigt, um eine vollständige Testabdeckung zu gewährleisten. PS-Systeme sind von der GP nicht direkt betroffen. Nach dem Deployment erfolgen dedizierte End-to-End-Tests (E2E), die die nahtlose Zusammenarbeit aller Produkte validieren. Diese Tests simulieren ausgewählte reale Anwendungsszenarien, um die Funktionalität und Interoperabilität des Gesamtsystems unter produktionsnahen Bedingungen sicherzustellen.
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 Referenz der Tabelle wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 6: 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 und  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. Der Fokus liegt hier auf der Stabilität und Performance des Systems unter erwarteter oder maximaler Last. Stresstest: Beobachtung des Systemverhaltens bei und nach Überlast, um die Belastbarkeit und Ausfallsicherheit zu testen. 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. Die Kriterien für Robustheit basieren auf den Anforderungen an die Ausfallsicherheit und Verfügbarkeit der TI sowie auf produktspezifischen Anforderungen.
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)

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

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

Tabelle 7: 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.1.2.3 Verantwortlichkeiten und Abläufe in der Teststufe GIT-TI

Die folgende RACI-Matrix bietet einen Überblick über die Verantwortlichkeiten und Beteiligungen der verschiedenen Akteure im Testprozess. Dabei steht ZN für Zulassungsnehmer und gematik für die gematik GmbH. Die Buchstaben in der Matrix haben folgende Bedeutungen:

• Responsible:  verantwortlich (Durchführungsverantwortung), zuständig für die eigentliche Durchführung - Die Person, die die Durchführung (auch durch Dritte) initiiert oder die Aktivität selbst durchführt. Sie kann die Aktivität auch selbst durchführen. 
  

• Accountable:  rechenschaftspflichtig (Kosten-, bzw. Gesamtverantwortung), verantwortlich im Sinne von „genehmigen“, „billigen“ oder „unterschreiben“ - Die Person, die im rechtlichen oder kaufmännischen Sinne die Verantwortung trägt.  
  

• Supportive:  unterstützend - Eine Person, die eine unterstützende Rolle einnehmen spielen oder Betriebsmittel zur Verfügung stellen kann. 

• Informed:  zu informieren (Informationsrecht)  - Eine Person, die eine unterstützende Rolle spielen oder Betriebsmittel zur Verfügung stellen kann. 
  

• Consulted:  konsultiert - Eine Person, die nicht direkt an der Umsetzung beteiligt ist, aber als Experte konsultiert werden kann. 

Test-stufe	Testart	Testplanung		Testvorbereitung		Testdurchführung
		ZN	gematik	ZN	gematik	ZN		gematik
PüT	funktional  TU	I	A	C	A	C	A
GIT-TI	funktional TU	I	A	C	A	C	A
	Generaleprobe  RU	S	A	R	A	R	A
	Leistungstest RU	S	A	R	A	R	A
	IOP PVS  RU	I	A	R	A	R	A

5.1.2.4 Behandlung von Fehlern in der Teststufe GIT-TI

In der Teststufe Gesamtintegrationstest (GIT-TI) können Fehler auftreten, die entweder einem spezifischen Zulassungsobjekt oder einem Referenzobjekt zugeordnet werden. Die Vorgehensweise zur Fehlerbehandlung ist wie folgt:

• Fehlerzuordnung zum Zulassungsnehmer (ZN): Wenn ein Fehler einem bestimmten Zulassungsobjekt eines Zulassungsnehmers zugeordnet werden kann, ist der ZN für die Analyse und Behebung des Fehlers verantwortlich. Der ZN sollte alle notwendigen Schritte unternehmen, um die Funktionalität und Integrität des Zulassungsobjekts zu gewährleisten.

• Fehlerzuordnung zu einem Referenzobjekt: Sollte ein Fehler bei einem Drittsystem auftreten, wird dieser Fehler dem verantwortlichen Ansprechpartner für das Drittsystem zugeordnet. Die gematik informiert den Ansprechpartner und bittet um eine zeitnahe Behebung des Fehlers.

• Folgen für den ZN: Fehler bei Drittsystemen, die außerhalb der Kontrolle des ZN liegen, haben keine direkten Auswirkungen auf die Zulassung des ZN. Solange das Zulassungsobjekt alle erforderlichen Tests erfolgreich besteht, wird der ZN nicht für Probleme haftbar gemacht, die durch Drittsysteme verursacht werden. Die gematik stellt sicher, dass solche Fehler separat behandelt werden, um die Integrität des Zulassungsverfahrens zu bewahren.

5.2 Eingangs- und Ausgangskriterien, Testabbruch

## Das ist ein neues Kapitel, das nach den Teststufen 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. Die Eingangs- und Ausgangskriterien der Zulassungstests (ZulT) sind von der gematik in den folgende Kapiteln beschrieben.

Die im Rahmen des vorliegenden Konzeptes definierten Eingangs- und Ausgangskriterien gelten als Mindestanforderungen für die jeweiligen Testphasen. In den spezifischen Testkonzepten der einzelnen Produkte können jedoch zusätzliche Kriterien definiert werden, die auf die jeweiligen Anforderungen und Besonderheiten der Produkte eingehen.

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.
• Es liegen keine blockierenden Fehler 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.
• Es liegen keine blockierenden Fehler vor.
• Ein Behebungsplan für die identifizierten und noch offenen Fehler liegt vor.
• 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.: Wenn ein Sicherheitsgateway in der Testumgebung nicht korrekt konfiguriert ist, können Tests zur Verschlüsselung und Authentifizierung nicht vollständig durchgeführt werden. Dies führt zu unvollständigen Ergebnissen, die keine zuverlässige Aussage über die Sicherheitsfunktionen des Systems zulassen.
• 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)?

• Bewertung der identifizierten Fehler
  Das Risikomanagement basiert auf einer umfassenden Analyse der identifizierten Fehler, wobei der Schweregrad der Fehler als primäre Entscheidungsgrundlage dient. Die Fehler werden den entsprechenden Funktionen und Anforderungen zugeordnet, um ihre Auswirkungen auf das Gesamtsystem besser einschätzen zu können.
  

Die Entscheidung über eine Zulassungsempfehlung wird in einem Gremium mit verschiedenen Stakeholdern diskutiert und beschlossen. Dieses Gremium setzt sich aus Vertretern unterschiedlicher Bereiche zusammen, darunter auch Repräsentanten des Betriebs. Basierend auf der gemeinsamen Bewertung der Fehler, ihrer Schweregrade und potenziellen Auswirkungen auf die Funktionalität und Sicherheit der Telematikinfrastruktur, entscheidet das Gremium, ob:

1. eine uneingeschränkte Zulassungsempfehlung ausgesprochen wird.
   
2. eine Zulassung unter bestimmten Auflagen vorläufig erteilt wird.
   
3. keine Zulassungsempfehlung ausgesprochen wird.
   

Dieser kollaborative Entscheidungsprozess gewährleistet, dass alle relevanten Perspektiven berücksichtigt werden und eine fundierte Entscheidung im Sinne der Qualität und Sicherheit der Telematikinfrastruktur getroffen wird.

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.

• Alle notwendigen Tests wurden erfolgreich abgeschlossen und die im Testkonzept definierten Testziele wurden 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.

• Alle notwendigen Tests wurden erfolgreich abgeschlossen und die im Testkonzept definierten Testziele sind 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. Ein Abbruch wird stets von einer umfassenden Kommunikation begleitet. Die gematik wird den Zulassungsnehmer über die festgestellten Abweichungen informieren und ihm die Möglichkeit geben, diese zu prüfen und gegebenenfalls zu korrigieren.

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 Vorgehensweise für Zulassungsnehmer im Release-Management der Telematikinfrastruktur (TI)

### Das Kapitel  wird nach dem Kapitel 4.4 des [gemKPT_Test] angepasst.

Das Release-Management der TI folgt fest terminierten Release-Zyklen. Für Zulassungsnehmer bedeutet dies, dass sie ihre Entwicklungsarbeiten rechtzeitig auf die festgelegten Release-Zyklen abstimmen müssen. Innerhalb jedes Release-Zyklus wird die Gesamtintegrationsteststufe durchgeführt.

Zusätzlich zu diesem regulären Prozess gibt es einen Hotfix-Prozess, der es ermöglicht, kritische Fehler oder Sicherheitslücken schnell zu beheben. Dieser Prozess erlaubt dringende Korrekturen außerhalb des regulären Release-Zyklus, um die Stabilität und Sicherheit der TI jederzeit zu gewährleisten.

Abbildung : Release Zyklen im Test

Disclaimer
Die hier beschriebene Vorgehensweise wird iterativ eingeführt. Die konkrete Umsetzung und der Zeitplan für die Einführung werden in Abstimmung mit den Zulassungsnehmern festgelegt. Dies ermöglicht eine schrittweise Anpassung an die neuen Prozesse und berücksichtigt die Rückmeldungen und Erfahrungen der beteiligten Parteien.

5.4 Interoperabilität

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

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.

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 prozessierbar 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 prozessierbar 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

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

5.5 Testdokumentation

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

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

Diese Testdokumentation eines ZN 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.

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

5.5.2 Fehlerbehebungsplan

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)

Das Management der Systemumgebungen liegt in der Verantwortung der gematik, um eine optimale Nutzung und Koordination der Ressourcen zu gewährleisten. Nachfolgend werden die Umgebungen und die Anforderungen an diese ausführlich beschrieben.

Abbildung 4: Umgebungsübersicht

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.

## Diese Anforderung kommt neu hinzu

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 Nachbau 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 Generalproben 
• Durchführung von Leistungstests
• Reproduktion von Fehlern aus der Produktivumgebung
• Ausführung von Hotfix- und Emergency-Tests
• Durchführung von Sicherheitstests
• 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 kann 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 Referenz der Tabelle wird bei der Übertragung in das [gemKPT_Test] angepasst.

Tabelle 8 : 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: Referenzumgebung für die Verifikation durch dritte	Gesamtintegrationstest (GIT-TI)

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

## Die ab hier folgenden AFOs werden angepasst.

## Alt

## Neu

## Diese Anforderungen sind hier aufgelistet zum Zwecke der Lesbarkeit

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.