Elektronische Gesundheitskarte und Telematikinfrastruktur

Testkonzept der TI

    

     

      
Version
      
3.0.0_RC
     
     

      
Revision
      
1263010
     
     

      
Stand
      
12.06.2025
     
     

      
Status
      
zur Freigabe empfohlen
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemKPT_Test
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Testkonzept der Telematikinfrastruktur (TI) definiert die Anforderungen an die notwendigen Testmaßnahmen und Rahmenbedingungen für neue oder geänderte Komponenten und Dienste (nachfolgend Produkte) der Telematikinfrastruktur (TI) im Produktivbetrieb.

Über diese Testmaßnahmen müssen die Hersteller der Produkte ihre spezifizierte Funktionalität nachweisen, bevor schrittweise die Integration und übergreifende Nutzung weiterer Produkte vorgenommen wird.

Daher werden die Produkte auf definierte Schnittstellenleistung und Funktionalität getestet sowie Interoperabilitätstests aus Anwendungs- und Gesamtprozesssicht durchgeführt. Diese dienen der vollständigen Abnahme der jeweiligen Produkte und Fachanwendungen.

Das Testkonzept folgt dem Standard des International Software Testing Qualifications Board (ISTQB).

1.2 Zielgruppe

Das Dokument richtet sich an Zulassungs- bzw. Bestätigungsnehmer (Hersteller und Anbieter) von Produkten der TI sowie an die korrespondierenden testspezifischen Rollen. Die Zulassungs- bzw. Bestätigungsnehmer werden in diesem Dokument einheitlich als Zulassungsnehmer bezeichnet. Zu den Anbietern von Produkten zählen hier auch die Betreiber von fachanwendungsspezifischen Diensten.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zu Testmaßnahmen der Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Abgrenzungen

Normative Vorgaben zu Themen, welche nicht nur den Test betreffen, wie z. B. Zulassung und Betrieb, sind nicht Bestandteil dieses Konzepts.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

2 Übersicht

Die folgenden Abschnitte bieten einen Überblick über die rechtlichen Grundlagen sowie das daraus abgeleitete Testvorgehen für die Telematikinfrastruktur (TI). Dabei wird dargestellt, wie gesetzliche Anforderungen in konkrete Testmaßnahmen überführt werden, um eine sichere und interoperable digitale Gesundheitsversorgung zu gewährleisten.

2.1 Gesetzlicher Rahmen

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 zu veranlassen.
Diese Maßnahmen bilden die Grundlage für die Prüfung von Funktionalität, Interoperabilität und Sicherheit von Produkten innerhalb der TI.

2.2 Von der gesetzlichen Vorgabe zur Teststrategie

Auf Grundlage der gesetzlichen Anforderungen an die Telematikinfrastruktur (TI) wurde von der gematik eine Teststrategie entwickelt. Diese Teststrategie hat zum Ziel, dass alle TI-Produkte nicht nur einzeln, sondern auch im Zusammenspiel den hohen Anforderungen an Funktionalität, Interoperabilität und Sicherheit genügen.
Das mehrstufige Vorgehen der Teststrategie ist so ausgestaltet, dass die Prüfungen systematisch aufeinander aufbauen. Transparenz über Abläufe, Verantwortlichkeiten und Qualitätsmaßstäbe wird geschaffen und damit das Fundament für die Zulassung neuer oder geänderter Produkte in der TI gelegt.

In den nachfolgenden Kapiteln sind vertiefende Informationen zu Testphasen, Systemlandschaft und der Integration in das Solution Train Modell enthalten:

• Ein Überblick über die Phasen und Stufen des Testvorgehens findet sich in Kapitel 3.2.
• Der Testkontext sowie die einbezogenen Produkte sind in Kapitel 5 beschrieben.
• Die zugrunde liegenden Systemumgebungen werden in Kapitel 6 erläutert.
• Die Einbindung in das Solution-Train-Modell ist Gegenstand von Kapitel 3.5.
• Spezifische Anforderungen für Fachdienste sind ab Kapitel 8 zusammengefasst.

3 Teststrategie

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: Nachweis der vollständigen Funktionsfähigkeit der eingesetzten Software.

3.2 Testphasen

Das neue Testvorgehen der Telematikinfrastruktur (TI) umfasst zwei aufeinanderfolgende Testphasen, die sich in insgesamt drei Teststufen unterteilen:

• Phase 1: Eigenverantwortliche Tests (EvT): Die Zulassungsnehmer prüfen eigenständig ihre Produkte.

• Phase 2: Zulassungstests (ZulT): Diese Phase gliedert sich in zwei Teststufen:

• Produktübergreifender Test (PüT): Interoperabilität und das Zusammenspiel mehrerer Produkte werden geprüft.

•Gesamtintegrationstest der TI (GIT-TI): Die gematik testet die vollständige Integration aller Produkte im Gesamtsystem.

Abbildung 1: Überblick der Testphasen

Jede Teststufe baut auf der vorherigen auf. Ein Übergang erfolgt nur nach erfolgreichem Abschluss.

Die beiden Testphasen unterscheiden sich im Testziel, in der Verantwortung und in der Nutzung der Systemumgebungen (hier: Obergriff aller Testumgebungen). 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.

3.2.1 Eigenverantwortlicher Test (EvT)

Festlegungen für das neue Vorgehen

Die folgende Tabelle stellt eine Übersicht über die Testphase Eigenverantwortlicher Test (EvT) dar. In der Testphase "Eigenverantwortliche Tests" gibt es nur die eine, namensgleiche Teststufe "Eigenverantwortliche Tests"

Tabelle 1: Tab_Test_005_01 Eigenverantwortlicher Test (EvT)

Festlegungen für das bisherige Vorgehen

Tabelle 2: Tab_Test_005 Eigenverantwortlicher Test

Die testdurchführende Instanz kann die benötigten Services zum Anbinden des Testobjekts beim TIZP über den Servicekatalog des AZPD buchen.

3.2.1.1 Ablauf für den Nachweis der funktionalen Eignung innerhalb eines Zulassungsverfahrens

In der folgenden Prozessgrafik sind die wesentlichen Prozessschritte beispielhaft dargestellt, die üblicherweise bei Neuzulassung eines Produkts durchlaufen werden.

Abbildung 2: Exemplarischer Ablauf eines Testverfahrens

Die Beschreibung des gesamten Zulassungsverfahrens für das jeweilige Produkt findet sich im gematik-Fachportal in der Verfahrensbeschreibung.

3.2.1.2 Qualitätssichernde Maßnahmen und Produktmuster

Im Rahmen der eigenverantwortlichen Tests behält sich die gematik folgende qualitätssichernde Maßnahmen vor:

• Anlassbezogene Anforderung eines Produktmusters 6 Wochen vor Beginn der Zulassungstests.
• Weitere anlassbezogene, vom Hersteller oder Anbieter durchzuführende Workshops zur Klärung von Fragen zur Testdokumentation oder Ergebnissen der Testdurchführung
• begleitende Stichproben:
• anlassbezogen bei der Durchführung Eigenverantwortlicher Tests
• der Entwicklungsfortschritte von Produkten

Produktmuster haben folgende Ziele:

• Aktives Risikomanagement
• Validierung der Testfälle vor Beginn der Zulassungstests

Die Bereitstellung des Produktmusters erfolgt je nach Ausprägung durch Lieferung an die gematik oder die frühzeitige Integration in die TU.

Im Rahmen der Produktmustervalidierung erfolgt durch die gematik keine Güteprüfung, Abnahme der Produktmuster oder Verantwortungsübernahme im Sinne der Produktentwicklung.

3.2.2 Zulassungstest

Festlegungen für das neue Vorgehen

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.

3.2.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).

Tabelle 3: Tab_Test_034_01 Produktübergreifender Test (PüT)

3.2.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ärsystemen (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 Produkte, unabhängig ob sie neu oder überarbeitet sind oder auch keine Veränderungen erfahren haben, in einem Testverfahren durchgeführt.

Tabelle 4: Tab_Test_035_01 Gesamtintegrationstest - Funktionale Tests (E2E)

Tabelle 5: Tab_Test_035_02 Gesamtintegrationstest - Generalprobe

Tabelle 6: Tab_Test_036 Leistungstest

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

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

Festlegungen für das bisherige Vorgehen

Tabelle 8: Tab_Test_006 Zulassungstest

3.2.2.3 Verantwortlichkeiten und Abläufe in der Teststufe GIT-TI

Die folgende RASCI-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 Aktivität entweder selbst durchführt oder deren Durchführung (z. B. durch Dritte) initiiert und steuert.
  

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

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

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

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

Tabelle 9: Tab_Test_038 Überblick über die Verantwortlichkeiten und Beteiligungen

3.2.3 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 ZN 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.

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

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

3.2.4.2 Fehlerbehebungsplan

3.3 Eingangs- und Ausgangskriterien, Testabbruch

Dieses Kapitel beschreibt die grundlegenden Rahmenbedingungen für die Durchführung und Bewertung von Teststufen im Zulassungsprozess. Es definiert 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 nachfolgenden 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.

3.3.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)?

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

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

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

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

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

Das Risikomanagement im Zulassungsprozess der Telematikinfrastruktur  basiert auf einer umfassenden Analyse der im Rahmen der Tests identifizierten Fehler. Die Fehler werden nach Schweregrad klassifiziert und den betroffenen Funktionen und Anforderungen zugeordnet, um potenzielle Auswirkungen auf das Gesamtsystem zu bewerten. Die Entscheidung über eine Zulassungsempfehlung erfolgt nicht automatisch anhand fester Ausschlusskriterien, sondern wird in einem Gremium aus verschiedenen Stakeholdern, einschließlich Vertretern des Betriebs, gemeinsam getroffen. Die Exit-Kriterien für eine erfolgreiche Testphase sind maßgeblich für die Bewertung, ob die Phase abgeschlossen werden kann oder ob weitere Maßnahmen erforderlich sind.

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

3.4 Testdokumentation

Zur Dokumentation der Testaktivitäten der verschiedenen Testphasen und Teststufen sollen durch die Zulassungsnehmer unterschiedliche Dokumente erstellt werden.

Die Testdokumentation eines Zulassungsnehmers soll dabei einheitlich strukturiert sein und alle relevanten Informationen konsolidieren (z.B. von Subunternehmen).

Der genaue Lieferzeitpunkt der Dokumente ist jeweils als Eingangs- bzw. Testausgangskriterium definiert.

Zulassungsnehmer können die Templates der Testdokumentation aus dem letzten Zulassungsverfahren weiterverwenden.

3.4.1 Testkonzept

Tabelle 10: Tab_Test_013 Testkonzept

3.4.2 Testspezifikation

Tabelle 11: Tab_Test_014 Testspezifikation

3.4.3 Release Notes

Tabelle 12: Tab_Test_015 Release Notes

3.4.4 Produktdokumentation

Tabelle 13: Tab_Test_016 Produktdokumentation

3.4.5 Testprotokoll

Tabelle 14: Tab_Test_017 Testprotokoll

3.4.6 Testbericht

Tabelle 15: Tab_Test_018 Testbericht

3.5 Vorgehensweise für Zulassungsnehmer im Solution-Management der Telematikinfrastruktur (TI)

Das Solution Management der Telematikinfrastruktur (TI) folgt fest definierten Release-Zyklen. Für Zulassungsnehmer bedeutet dies, dass Entwicklungsarbeiten und Freigaben rechtzeitig auf die vorgegebenen Release-Termine abgestimmt werden müssen. Im Rahmen jedes Release-Zyklus findet eine Gesamtintegrationsteststufe (GIT-TI) statt, um die Systemstabilität und Interoperabilität aller Komponenten sicherzustellen.
Neben diesem regulären Ablauf existiert ein Hotfix-Prozess, der es ermöglicht, kritische Fehler oder Sicherheitslücken kurzfristig zu beheben. Dringende Korrekturen können so außerhalb des normalen Release-Zyklus eingespielt werden, um die Stabilität und Sicherheit der TI jederzeit zu gewährleisten.
Das standardisierte Vorgehen gilt insbesondere für Major- und Minor-Changes. Hotfixes und Emergency Changes werden hingegen in einem beschleunigten Verfahren behandelt: Sie durchlaufen einen gezielten „Quickcheck“, um sicherzustellen, dass die Änderungen schnell und effizient produktiv gesetzt werden können, ohne die bestehenden Prozesse unnötig zu verzögern. Diese dringenden Updates unterliegen dabei nicht dem regulären Solution Train, sondern werden gesondert getestet und freigegeben.

Abbildung 3: Release Zyklen im Test

4 Rollen und Verantwortlichkeiten

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

• den Zulassungsnehmer und
• den Testansprechpartner der 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 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 Bewertung und das 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.  Ein Anbieter kann gegenüber der gematik einen Vertreter benennen, der in seinem Namen Testanforderungen erfüllt. Sie übernehmen eine zentrale Rolle als testdurchführende Instanz und tragen die Gesamtverantwortung für die Qualitätssicherung ihres Produkts im Zulassungsverfahren.

Zu den verpflichteten Aufgaben des Zulassungsnehmers gehören:

• Testdurchführung:
• Planung, Steuerung und Durchführung der Eigenverantwortlichen 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 Systemumgebungen
• Einbringung der Testobjekte in alle Systemumgebungen über den betrieblichen Change Prozess
• Herstellung der Testbereitschaft inklusive Bereitstellung der Release Notes 
• Unterstützung beim Nachstellen und Analysieren von auftretenden Fehlern in den Systemumgebungen.

4.2 Testansprechpartner gematik

Der Testansprechpartner erfüllt den gesetzlichen Testauftrag hinsichtlich § 291b SGB V, 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 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 Systemumgebungen
• 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 Testkontext TI

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, Einbau Konnektor (EBK), High Speed Konnektor (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 4: Übersicht des Gesamtsystems Telematikinfrastruktur

6 Systemumgebungen

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 Systemumgebungen und die Anforderungen an diese ausführlich beschrieben.

Abbildung 5: 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.

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, in der Hotfixes (HF) sowie zusätzliche Tests durchgeführt werden, die im Rahmen der Zulassungstests erforderlich sind. Sie 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 werden. 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:

Tabelle 16: Tab_Test_039 Überblick Umgebungen im Rahmen von Test

Die strikte Trennung von Produktivbetrieb und Testbetrieb bezüglich der Verwendung von Daten ist essentiell. Einerseits muss sichergestellt werden, dass in der Referenzumgebung und in der Testumgebung keine Echtdaten verwendet werden. Es dürfen nur Testdaten und entsprechend auch Testkarten [gemSpec_TK] verwendet werden.

Die Einhaltung dieser strikten Trennung wird durch technische Maßnahmen (z. B. physikalische Trennung der Netze, Einbau von Prüfroutinen für Testkarten) und organisatorische Maßnahmen (z. B. Vorschreiben der Verwendung von Testkarten) sichergestellt.

Alle Testmaßnahmen in der Referenz- und Testumgebung werden mit Testdaten durchgeführt. Diese werden von Herstellern, Anbietern und Kartenherausgebern zur Verfügung gestellt, sofern es sich um einen Produkttyp handelt, der Daten in die TI liefert. Das Einbringen von Echtdaten ist in diese Systemumgebungen nicht erlaubt.

Testkarten für die eigenverantwortlichen Tests eines Zulassungsnehmers können über die gematik-Website bestellt werden.

Neben den Produkttypen der TI-Plattform sind für die Tests der TI-Plattform ggf. Clientsysteme erforderlich, insbesondere für den Produktübergreifenden Test. Clientsysteme sind dezentrale Systeme (mit Hard- und/oder Software-Bestandteilen), die als Clients mit der TI interagieren, aber selbst nicht als Bestandteil der TI betrachtet werden (z. B. PVS, AVS, KIS, E-Mail-Clients).

6.5 Anforderungen an die Systemumgebungen

In den folgenden Kapiteln sind nach Themengebieten geordnet die Anforderungen aufgeführt, die die Systemumgebungen bzw. die jeweiligen Zulassungsnehmer erfüllen müssen.

6.5.1 Trennung der Netzwerke

6.5.2 Trennung der Vertrauensräume

6.5.3 Gemeinsame Eigenschaften für alle Systemumgebungen

6.5.4 Gemeinsame Eigenschaften der Referenz- und Testumgebung

6.5.5 Exklusiver Zugriff

6.5.6 Logging

Die in diesem Kapitel beschriebenen Anforderungen an ein Logging beziehen sich auf die RU und TU. In diesen Systemumgebungen werden keine Echtdaten verarbeitet. Grundsätzlich sind alle Logging-Daten vertraulich. Eine Weitergabe und die Festlegung der Form der Weitergabe erfolgt ausschließlich durch die gematik.

Sollte das in der Anforderung TIP1-A_7331 angegebene Format nicht verwendbar sein, kann in Absprache mit dem TTM auch ein anderes Format verwendet werden.

6.5.7 Testwerkzeuge

6.5.8 Test- und Referenzobjekte

Referenzobjekte

Als Basis für eigenverantwortliche Tests (RU) und Zulassungstests (TU) sind Abbilder der in der PU vorhandenen Komponenten der TI erforderlich (gleiche Produkttypversion). Diese werden als Referenzobjekte bezeichnet. Gegen sie wird das aktuelle Testobjekt des Zulassungsnehmers getestet. Deren vollständigen Betrieb und die Erbringung des zugehörigen Service Levels verantwortet der jeweilige Anbieter entsprechend [gemRL_Betr_TI]. Referenzobjekte unterliegen den Vorgaben des betrieblichen Changeprozesses und können über den TI-Servicekatalog konfiguriert werden. Anfragen zu Konfigurationen an Fachdienste werden über den Test- und Transitionmanager der gematik gesteuert.

Referenzobjekte können nur in Absprache mit der gematik Simulatoren sein.

Testobjekte

Testobjekte sind Produkte eines Zulassungsnehmers, welche über die Tests in RU und TU eine Zulassung, Bestätigung oder Freigabe der gematik erhalten sollen. Das Einbringen und Herausnehmen aus der jeweiligen Betriebsumgebung (RU/TU) erfolgt über das betriebliche Change Management. In der Referenzumgebung kann ein Testobjekt jederzeit durch den Zulassungsnehmer konfiguriert und/oder angepasst werden. Eigenverantwortliche Tests müssen für alle Beteiligten der RU im Testkalender der gematik sichtbar gemacht werden. In der Testumgebung unterliegt das Testobjekt den Vorgaben des Test- und Transitionmanagers der gematik. Jegliche Anpassungen müssen mit ihm abgestimmt werden.

6.5.9 Referenzumgebung

6.5.9.1 Qualitätssicherungsmaßnahmen der Hersteller und Anbieter

6.5.9.2 Weiterentwicklung der Referenzumgebung

6.5.9.3 Nutzung der Referenzumgebung

6.5.9.4 Instanzen der Referenzumgebung

6.5.10 Testumgebung

6.5.10.1 Bestandteile der Testumgebung

6.5.10.2 Weiterentwicklung der Testumgebung

6.5.10.3 Dimensionierung der Testumgebung

6.5.10.4 Betrieb der Testumgebung

6.5.10.5 Nachstellen von PU-Fehlern in TU

6.6 Vorgeschriebene Integration

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

7 Szenarien

7.1 Ablauf und Nachweis der funktionalen Eignung innerhalb eines Zulassungsverfahrens

In der folgenden Prozessgrafik sind die wesentlichen Prozessschritte beispielhaft dargestellt, die üblicherweise bei Neuzulassung eines Produkts durchlaufen werden.

Abbildung 6: Exemplarischer Ablauf eines Testverfahrens

Die Beschreibung des gesamten Zulassungsverfahrens für das jeweilige Produkt findet sich im gematik-Fachportal in der Verfahrensbeschreibung.

7.2 Testvorgehensweise im Rahmen der Zulassung eines neuen Produkts

Tabelle 19: Tab_Test_021 Szenario: Zulassung eines neuen Produkts

7.3 Testvorgehensweise im Rahmen der Zulassung eines geänderten Produkts

Tabelle 20: Tab_Test_022 Szenario: Zulassung eines geänderten Produkts

7.4 Regressionstest

Ein Regressionstest stellt fest, ob durch eine durchgeführte Modifikation neue Fehler erzeugt oder (bisher maskierte) Fehler freigelegt wurden und ob bisher positiv durchgeführte Tests weiterhin positiv durchgeführt werden können. Eine Modifikation kann die Installation einer neuen Fachanwendungsversion nach einer Fehlerbehebung, eine Aktualisierung von Produkten (z. B. Datenbank-Updates) sein oder auch Änderungen in den Testtools (Veränderungen an Testtreibern oder Simulatoren) bewirken.

Die für den Regressionstest verwendeten Testfälle sind eine Teilmenge der für das jeweilige Testobjekt geplanten (funktionalen) Testfälle und sollen weitgehend automatisiert durchgeführt werden. Dabei liegt der Schwerpunkt nicht nur auf der funktionalen Verifikation, sondern auch auf der Sicherstellung der richtigen Installation und Konfiguration einer Fachanwendung in der Systemumgebung. Der Regressionstest beinhaltet damit die anderen Testarten Funktionstest, Interoperabilitätstest und Leistungstest.

Nicht geänderte Produkttypen werden geprüft, wenn sie an einem Anwendungsfall beteiligt sind, an dem mindestens ein neuer oder geänderter Produkttyp beteiligt ist. Der Umfang eines Regressionstests richtet sich dabei nach Art, Umfang und Kritikalität der Änderungen. Der Regressionstest muss nicht notwendigerweise alle bereits vorhandenen Testfälle beinhalten, er muss aber mindestens sicherstellen, dass Änderungen keine unerwünschten Auswirkungen auf nicht geänderte Komponenten haben. Dafür ist es notwendig, dass die jeweils verantwortliche testdurchführende Instanz eine entsprechende Auswirkungsanalyse als Grundlage der Regressionstests durchführt.

7.5 Interoperabilität

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.

Die Nutzung von geeigneten Testobjekten kann notwendig sein, wenn zeitgleich Änderungen an mehreren Produkten der TI vorliegen. Grundvoraussetzung für ein geeignetes Testobjekt ist, dass zumindest die korrekte Umsetzung der für den jeweiligen Interoperabilitätstest benötigten Funktionalität(en) im Rahmen von Produkttests erfolgreich nachgewiesen wurde.

Die Angabe der Mindestanzahl geht davon aus, dass ausreichend viele Referenzobjekte bzw. geeignete Testobjekte vorhanden sind. Sollte die geforderte Anzahl nicht zur Verfügung stehen, kann in Abstimmung mit dem TTM gegen eine verringerte Zahl getestet werden.

Hinweis zur Lesart der IOP-Tabelle:
Die Zeilen zeigen die zu testenden Produkte, die Spalten die jeweiligen Gegenstellen. Eine Markierung in der Zelle bedeutet, dass zwischen dem Produkt (Zeile) und dem System (Spalte) ein Interoperabilitätstest vorgesehen ist. Die Tabelle ist waagerecht zu lesen.

Tabelle 21: Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung

7.6 Serviceprodukte der gematik zur Testunterstützung

Die gematik bietet Zulassungsnehmern eine Reihe von Serviceprodukten an, die für die Entwicklung der Produkte bzw. für die eigenverantwortlichen Tests genutzt werden können. Welche Services dies sind, deren Verfügbarkeit und die Konditionen zu welchen diese genutzt werden können, sind im gematik Fachportal aufgeführt.

8 Fachanwendung VSDM

8.1 Testkarten

Verschiedene Anwendungen, die durch die Telematikinfrastruktur (TI) unterstützt werden, verwenden verschiedene Typen von Smartcards. Zur Unterstützung der Entwicklung von Anwendungen der TI, von Produkten der TI, aber auch in den Zulassungstests werden Testkarten verwendet. Sie weisen eine spezifische Personalisierung auf. Auf den Testkarten personalisierte Zertifikate sind u. a. von einem testspezifischen Vertrauensraum abgeleitet und sind daher grundsätzlich nicht in der produktiven TI einsetzbar. Da Anwendungen häufig das Zusammenspiel verschiedener Smartcards erfordern, wurden Sets verschiedener Testkarten definiert. Die Testkarten-Sets können von der gematik bezogen werden. Der Einsatz physischer Testkarten zu Testzwecken schränkt die Möglichkeiten einer Testautomatisierung ein. Zur Unterstützung der Testautomatisierung können physische Testkarten durch eine Kartensimulation, ggf. durch eine Kartenterminalsimulation ergänzt, ersetzt werden. Die Kartensimulation, mit den respektiven Kartensimulationsimages, kann durch entsprechende Konfiguration die Funktionsweise aller G2- bzw. G2.1-Testkarten (eGK, HBA und SMCs) nachbilden. Für die Fachdienste VSDM wird ein Zusammenspiel von verschiedenen Testkartenarten benötigt (eGK, HBA und SMC-B).

8.1.1 Testkartenausprägungen

Für verschiedene Testmaßnahmen werden unterschiedliche Ausprägungen von Testkarten eingesetzt.

• Physische Testkarten zeichnen sich durch eine spezielle Kunststoffkarte mit eingebautem integriertem Schaltkreis (Chip) aus und werden über ein Kartenterminal angesteuert, um für Testmaßnahmen verwendet zu werden. Daher ist immer ein manueller Steckvorgang erforderlich und eine Verwendung in automatisierten Testabläufen schwierig.
• Virtuelle Testkarten werden u. a. beim Test von Fachdiensten VSDM eingesetzt. Diese Testkarten werden in den Bestandssystemen von Fachdiensten als XML-Strukturen in Datenbanken verwaltet und ermöglichen u. a. die Initialisierung von Updates der Versichertenstammdaten (VSD) auf einer elektronischen Gesundheitskarte (eGK). Virtuelle Testkarten setzen zwingend den Einsatz einer Kartensimulation voraus. Da das manuelle Stecken einer physischen Testkarte entfällt, sind virtuelle Testkarten besonders für automatisierte Testmaßnahmen (z. B. Last-, Performancetests) geeignet. Lasttests erfordern eine hohe Anzahl verschiedener Testkarten, durch den Einsatz virtueller Testkarten kann der Aufwand für den Testaufbau erheblich reduziert werden.
• Kartensimulations-Images für Testkarten sind XML-Strukturen, die eine Voraussetzung für den Einsatz einer Kartensimulation darstellen. Im Zusammenspiel mit virtuellen Testkarten wird eine effiziente Testautomatisierung möglich.
• Kartensimulations-Images können, aufgrund des normativen Formats, auch für Testmaßnahmen zu Card Operating Systemen (COS) und Objektsystemen (eGK, HBA, SMCs) verwendet werden (z. B. in einer frühen Phase von Zulassungstests einer Smartcard), wie auch zur Steuerung und Konfiguration von Testtools eingesetzt werden.

Neben den Ausprägungen weisen Testkarten auch verschiedene Personalisierungen auf, die auch mit spezifischen COS-Ausprägungen einhergehen.

• Testkarten eGK weisen personenbezogene Personalisierungen auf, die sowohl in den VSD als auch in den Zertifikaten Verwendung finden. Die personenbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Personen haben. Testkarten eGK können mit Institutskennzeichen aktiver Krankenkassen oder einem Institutskennzeichen des GKV-SV personalisiert sein, um in den Testumgebungen der Telematikinfrastruktur (TI) ggf. Fachdienste zu erreichen, die VSD-Updates auf eine Testkarte eGK schreiben können.
• Testkarten SMC-B weisen institutionsbezogene Personalisierungen auf, die in den Zertifikaten Verwendung finden. Die institutionsbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Institutionen haben.
• Testkarten HBA weisen personenbezogene Personalisierungen auf, die in den Zertifikaten Verwendung finden. Die personenbezogenen Daten werden zufällig aus einem Datenpool ausgewählt und dürfen keinen Bezug zu realen Personen haben.

8.1.2 Testkarten Verwendung

Physische Testkarten werden von verschiedenen Serviceprodukten verwendet, um die Entwicklung von Produkten und Anwendungen für die TI zu unterstützen, können aber auch in Form spezifischer Testkarten-Sets für Entwicklungstätigkeiten bezogen werden. Physische Testkarten werden auch im Rahmen von Zulassungstests, für Produkttests der Fachdienste VSDM, für produktübergreifende und Ende-zu-Ende-Tests eingesetzt. Die von den Fachdienstbetreibern VSDM bereitgestellte eGK-Testkarten FD müssen den Anforderungen der Testkartenspezifikation [gemSpec_TK_FD] genügen. Andere Testkarten können bei der gematik bestellt werden [gematikShop].

Im Rahmen von Zulassungstests werden in Produkt- und produktübergreifenden Tests der Fachdienste VSDM auch virtuelle Testkarten eGK eingesetzt, um u. a. Last- und Performancetests mit einer großen Anzahl verschiedener Personalisierungsausprägungen der eGK über einen längeren Zeitraum hinweg durchführen zu können.

Kartensimulations-Images werden für Zulassungstests unterschiedlicher Produkte verwendet, um einen möglichst hohen Testautomatisierungsgrad zu erreichen bzw. mit vereinfachten Testaufbauten arbeiten zu können.

Physische und virtuelle Testkarten wie auch Kartensimulations-Images verwenden für Updates symmetrische und/oder asymmetrische Schlüssel. Das Dokument zur "Spezifikation für Testkarten Fachdienste (eGK) der Generation 2" [gemSpec_TK_FD] definiert die zulässigen Algorithmen zur Generierung der verschiedenen Schlüssel und eröffnet damit Möglichkeiten einer Manipulation von Personalisierungsinhalten der Testkarten ohne Verwendung eines spezifischen Fachdienstes. Sofern Fachdienste für Updates von Testkartenpersonalisierungen zur Verfügung stehen, müssen durch den Fachdienst täglich wechselnde Updates der von ihm verwalteten Testkarten bereitgestellt werden. In physischen Testkarten personalisierte X.509-Zertifikate müssen online vom Trust Service Provider (TSP), der die Zertifikate erstellt hat, prüfbar sein.

8.1.3 Anforderungen an die eGK-Testkarten FD für die gematik

8.2 Flip/Flop-Verfahren

Um die Kommunikation zwischen testdurchführender Instanz und dem Betreiber des Fachdienstes VSDM zu minimieren, hat sich das sogenannte Flip/Flop-Verfahren bewährt. Der Fachdienst UFS bietet täglich ein Update für verschiedene Testkarten an.

Um in Testverfahren das erfolgreiche Update der VSD auf der eGK nachweisen zu können, werden unterschiedliche Ausprägungen der VSD verwendet.

An geraden Tagen realisiert der Fachdienst VSDD ein Update mit VSD der Variante 1 und an ungeraden Tagen ein Update mit VSD der Variante 2. Nach erfolgreichem Abschluss des jeweiligen Updates der VSD auf der eGK löscht der UFS die Update-Information.

Die Funktionalität des Fachdienstes CMS wird durch Sperren und Entsperren der Gesundheitsanwendung (DF.HCA) überprüft.

Im Kontext der Implementierung und Umsetzung des Flip/Flop-Verfahrens ergeben sich die nachfolgend aufgeführten Anforderungen.

8.3 Umgang mit mandantenfähigen Fachdiensten

Betreiber der Fachdienste VSDM können auch mehrere Anbieter von eGK unterstützen. Da die Eigenschaften der eGK auch die Zugangswege durch die Telematikinfrastruktur zum Fachdienst beeinflussen, muss jeder Anbieter von Fachdiensten Testkarten bereitstellen und durch den Betreiber seiner Fachdienste verwalten lassen.

Betreiber mandantenfähiger Fachdienste müssen mindestens zwei Testkartensätze (siehe Kapitel 8.1 Testkarten ) unterschiedlicher Anbieter (Mandanten) verwalten und für Testmaßnahmen das Flip/Flop-Verfahren aktivieren.

Im Produkttest bleiben Tests zur Mandantenfähigkeit auf 2 Mandanten beschränkt. Allerdings müssen im produktübergreifenden Test für jeden Mandanten eines Fachdienstes mindestens 2 Testkarten verwaltet und das Flip/Flop-Verfahren für Testmaßnahmen aktiv sein.

Grundsätzlich soll jeder Anbieter von Fachdiensten mindestens einen Testkartensatz für Testmaßnahmen zur Verfügung stellen, um ggf. mehrere testdurchführende Instanzen bei der Testdurchführung zu unterstützen.

8.4 Testdurchführung der EvT bei VSDM

Das Testportal bietet eine zusätzliche Qualitätssicherung und entbindet den Hersteller nicht vom Testen der korrekten Funktionalität nach Anforderungslage. Für Anforderungen, für die es im Testportal Testfälle gibt, werden allerdings keine gesonderten Nachweise verlangt.

9 Fachanwendung KIM

Die von der gematik zur Verfügung gestellten Testfälle stellen eine zusätzliche Qualitätssicherung dar und entbinden den Hersteller nicht vom Testen der korrekten Funktionalität nach Anforderungslage.

10 Fachanwendung AdV

Für die Produkttests der AdV (Anwendungen der Versicherten) und für produktübergreifende Tests werden Testkarten (physische eGK) eingesetzt. Die Testkarten müssen den Anforderungen der eGK-Testkartenspezifikationen [gemSpec_TK_FD, gemSpec_TK] genügen, von den Fachdiensten der Anwendung VSDM mit Updates versorgt werden können und auf der Testkarte personalisierte X.509-Zertifikate müssen online gegen einen Trust Service Provider (TSP) prüfbar sein.

Es können die für die Fachdienste VSDM bereitgestellten Testkartensätze genutzt werden.

Die Afo wird benötigt, um beim Test des VSDM-Anwendungsfalls mit virtuellen Karten zu arbeiten.

11 Fachanwendung ePA für alle

Für die Testbarkeit der Fachanwendung ePA ist es notwendig, dass die Hersteller die folgenden Anforderungen erfüllen.

11.1 ePA-Aktensystem

Hinweis: Dazu zählen auch von der gematik erstellte Testkarten.

11.2 ePA-Frontend des Versicherten

Für die Beschreibung von Anforderungen zum Test des ePA-Frontend des Versicherten siehe in diesem Konzept unter 12 TI-Module in FdVs der Krankenversicherungen und in [gemSpec_ePA_FdV#Testtreiber-Modul für ePA-Frontend des Versicherten].

12 TI-Module in FdVs der Krankenversicherungen

Als Frontend des Versicherten werden Programme (Apps) bezeichnet, die Versicherten Zugang zu den Anwendungen der TI ermöglichen. Von den Krankenversicherungen werden neben eigenen Funktionen auch Zugänge zu Anwendungen der TI als Frontend des Versicherten bereitgestellt (FdV der Krankenversicherungen). Die erste in den Apps der Krankenversicherungen bereitgestellte TI-Funktionalität für die Versicherten war der Zugang zur Anwendung ePA. Zukünftig werden weitere Funktions-Module für die TI (TI-Module) Einzug in das FdV der Krankenversicherungen Einzug halten, wie z. B. für das E-Rezept. Dies erfordert einen erweiterten Testaufbau, der in diesem Kapitel beschrieben wird.

Die Bereitstellung der FdVs der Krankenversicherungen wird auf zwei Wegen erfolgen:

1. Bereitstellung von FdVs in der Umgebung der FdV-Hersteller mit einer Testtreiber-Schnittstelle, auf die von der TDI remote zugegriffen werden kann (Remote-Test-FdVs). Es erfolgt keine Nutzung einer GUI durch die TDI. Diese Bereitstellung dient der Automatisierung von Testfällen mit den FdVs.
2. Bereitstellung von Softwarepaketen, die in der Umgebung des TDI auf Geräten installiert wird. Im Testverlauf wird durch die TDI die GUI der App bedient. Das Softwarepaket soll nicht versicherungsspezifisch ausgeprägt sein (Whitelabel-App).

12.1 Bereitstellung von Remote-Test-FdVs

Die gematik wird die Testtreiberschnittstellen als REST-Services definieren und deren API via github öffentlich bereitstellen.

Zu fachspezifischen Festlegungen der Testtreiberschnittstelle für das ePA-Modul im FdV der Krankenversicherungen siehe [gemSpec_ePA_FdV#Testtreiber-Modul für ePA-Frontend des Versicherten].

Zu fachspezifischen Festlegungen der Testtreiberschnittstelle für das E-Rezept-Modul im FdV der Krankenversicherungen siehe [gemSpec_eRp_FdV#Testtreiberschnittstelle für E-Rezept-Frontend des Versicherten].

Erläuterung: Die konkrete Art der Absicherung ist mit der gematik abzustimmen. Dies kann zum Beispiel mutual TLS (mTLS) oder https mit einem API-Key im http-Header sein. Ziel ist eine für alle Hersteller und alle Testtreiberschnittstellen einheitliche Lösung.

Typische Situationen für die zusätzliche Bereitstellung von Remote-Test-FdVs sind die Integration weiterer TI-Module im FdV der Krankenversicherungen oder der Test von neuen Nutzungsszenarien für bereits integrierte TI-Module mit einem erweiterten Herstellerkreis.

Es ist geplant, für jeden Testtreiber-Client ein Remote-Test-FdV fest zuzuordnen, siehe schematische Darstellung in der folgenden Abbildung:

Abbildung 7: schematische Darstellung Zuordnung Testtreiber-Client zu Remote-Test-FdV

Bei Integration des Testtreibers direkt im FdV nutzt der Testtreiber die Schnittstellen des TI-Moduls, die auch von der GUI angesprochen werden. Die GUI wird nicht zur Testausführung genutzt, siehe schematische Darstellung in der folgenden Abbildung.

Abbildung 8: Schematische Darstellung zur Integration des Testtreibers im FdV

Alternativ kann der Testtreiber über eine automatisierte Ansteuerung der GUI des FdVs bereitgestellt werden, siehe schematische Darstellung in der folgenden Abbildung.

Abbildung 9: Schematische Darstellung zur Integration des Testtreibers über die GUI des Remote-Test-FdV

12.2 Bereitstellung von Whitelabel-Apps

Der gematik bereits zuvor bereitgestellte und weiterhin nutzbare mobile Geräte werden mitgezählt.

Beispiel: Bei zwei TI-Modulen in einer Whitelabel-App und zwei zuzulassenden mobilen Betriebssystemen bedeutet das pro Betriebssystem zwei Geräte und somit insgesamt vier bereitzustellende Geräte. Es wurden für das ePA-Modul bereits zwei mobile Geräte bereitgestellt. Es bleiben also zwei mobile Geräte, die der gematik neu bereitzustellen sind.

Dies trifft zu, wenn auch mittels angebotenem OTA-Firmware-Update vom Geräte-Hersteller kein für das FdV nutzbarer Zustand hergestellt werden kann.

Hinweis: Der gematik bereits zuvor bereitgestellte und weiterhin nutzbare Kartenlesegeräte werden mitgezählt

Beispiel: Bei zwei TI-Modulen in einer Whitelabel-App und zwei zuzulassenden Desktop-Betriebssystemen bedeutet das pro Betriebssystem zwei Kartenlesegeräte und insgesamt vier Kartenlesegeräte. Es wurden für das ePA-Modul bereits zwei Kartenlesegeräte bereitgestellt. Es bleiben also zwei Kartenlesegeräte, die der gematik neu bereitzustellen sind.

13 TI-Messenger

In der RU (Referenzumgebung) werden vom Hersteller eine Referenzinstanz und mindestens eine Testinstanz zur Verfügung gestellt. Die Referenzinstanz ist dabei ein Abbild der Produktivinstanz. Sie dient dem Nachtest von Fehlerwirkungen, dem Test von Kompatibilitäten (aufwärts oder abwärts) oder wird allgemein für Interoperabilitätstests verwendet. Mit Hilfe der Testinstanz werden die jeweiligen neuen Testobjekte geprüft.

Abbildung 10: Übersicht Testarchitektur TI-Messenger

Die Hersteller von TI-Messenger-Clients bzw. Fachdiensten können für die EvT die von der gematik kostenpflichtig bereitgestellte Referenzimplementierung in Kombination mit der gematik-Testsuite nutzen. Die Testsuite deckt wesentliche, aber nicht alle funktionalen Anwendungsfälle ab. Die Prüfung der korrekten Funktionalität nach Anforderungslage liegt in der Verantwortung der Hersteller. Für die Anwendungsfälle und Akzeptanzkriterien, welche mit der Testsuite abgedeckt sind, sind für die EvT-Dokumentation die Testergebnisse ausreichend. Darüber hinaus durchgeführte Tests, müssen den Anforderungen/Anwendungsfällen zugeordnet und entsprechend dokumentiert werden. 

Für die Testbarkeit der Fachanwendung TI-Messenger-Dienst ist es notwendig, dass die Hersteller die folgenden Anforderungen erfüllen.

14 Weitere Anwendungen

Die Anbieter weiterer Anwendungen (weitere Anwendungen des Gesundheitswesens oder weiterer Anwendungen des Gesundheitswesens mit Zugriff auf Dienste der TI aus angeschlossenen Netzen des Gesundheitswesens (WANDA Smart)) durchlaufen die in den vorherigen Kapiteln genannte Testvorgehensweise nur teilweise, da sie selbst keine Erfüllung der von der gematik erstellten Spezifikationen nachweisen müssen. Sie müssen allerdings nachweisen, dass die Services bzw. Komponenten, die sie von der TI nutzen keine negativen Auswirkungen auf dieselben haben – den sogenannten Schnittstellentests.

Der Anbieter einer weiteren Anwendung hat die Möglichkeit für eigene Tests die Referenzumgebung der gematik zu nutzen. Die Koordination für den Zugang übernimmt auf Seiten der gematik der Test- & Transitionmanager.

14.1 Vorbereitung der EvT zur funktionalen Eignung

Vor Beginn der EvT in der RU ist eine Freischaltung des Serviceportals und des Testumgebungskalenders RU erforderlich. Die Freischaltung eines Zugangs zum Testkalender und zum Serviceportal der RU wird vom TTM veranlasst. Der Eintrag der geplanten Testzeiträume in den Testkalender der RU wird vom jeweiligen Antragsteller selbst durchgeführt. Der TTM führt den Bestätigungsnehmer durch die notwendigen Prozesse und unterstützt den Anbieter weiterer Anwendungen beim Zugang zur RU.

14.2 Durchführung EvT zur funktionalen Eignung

Durch den Bestätigungsnehmer ist die erforderliche Testspezifikation inkl. der Testfallspezifikationen zu erstellen und die Testdurchführung in Testprotokollen und einem Testbericht zu dokumentieren. Eine Orientierungshilfe für die Ausgestaltung der Testfallspezifikation ist im Anhang B des Testkonzepts zu finden. Für den Testbericht stellt die gematik ebenso ein Template im Anhang B zur Verfügung.

Die Dokumente werden durch die gematik einer Güteprüfung unterzogen.

14.3 Schnittstellentests in der TU

Voraussetzung für den Start der Schnittstellentests durch die gematik ist eine vollständige Installation und Konfiguration des Testobjekts durch den Anbieter der weiteren Anwendung.

Nach Durchführung der Schnittstellentests wird das Ergebnis in einem Testbericht dokumentiert. Dieser Testbericht dient bei einem positiven Ergebnis als Nachweis der funktionalen Eignung des Produkts und wird an die Zulassungsstelle der gematik übergeben.

Tabelle 22: Tab_Test_027 Eigenverantwortlicher Test WANDA

Tabelle 23: Tab_Test_007 Bestätigungstest

Der Anbieter Weiterer Anwendungen des Gesundheitswesens oder Weiterer Anwendungen des Gesundheitswesens mit Zugriff auf Dienste der TI aus angeschlossenen Netzen des Gesundheitswesens (WANDA Smart) muss die Testaktivitäten in der Testumgebung im Bestätigungsverfahren unterstützen. Dies kann bspw. das Auslösen eines bestimmten Events in seiner Anwendung sein, sodass die gematik auf Seiten der TI das richtige Verhalten der Anwendung nachvollziehen kann.

15 Anhang A – Verzeichnisse

15.1 Abkürzungen

15.2 Glossar

Ein umfangreiches Glossar findet sich im Fachportal der gematik-Website.

15.3 Abbildungsverzeichnis

15.4 Tabellenverzeichnis

15.5 Referenzierte Dokumente

15.5.1 Dokumente der gematik

15.5.2 Weitere Dokumente