Elektronische Gesundheitskarte und Telematikinfrastruktur

Testkonzept der TI

    

     

      
Version
      
2.10.0
     
     

      
Revision
      
1156041
     
     

      
Stand
      
20.11.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
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. Releasemanagement, Migration, 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 Allgemeine Testvorgehensweise

2.1 Einleitung

Das Ziel der Testaktivitäten ist es, den Nachweis zu erbringen, dass zuzulassende Produkte alle aus den jeweiligen Produkttypsteckbriefen gestellten funktionalen und nichtfunktionalen Anforderungen erfüllen. Schwerpunkt sind hier Funktionalität, Sicherheit und Interoperabilität. Die Strukturierung in Testphasen soll die Testprozesse bis in den Produktivbetrieb der Komponenten unterstützen. Um das zu erreichen, wird das Testen in zwei Testphasen eingeteilt, die aufeinander aufbauen:

• Eigenverantwortliche Tests der Zulassungsnehmer (Hersteller und Anbieter)
• Zulassungs- bzw. Bestätigungstests der gematik (im Folgenden einheitlich als Zulassungstests bezeichnet)

Die jeweiligen Aktivitäten der Testphasen finden in eigenen Systemumgebungen (siehe Kapitel 3 Systemumgebungen ) statt:

• Referenzumgebung: Eigenverantwortliche Tests
• Testumgebung: Zulassungstests der gematik

Durch den Aufbau unterschiedlicher Systemumgebungen werden die Rahmenbedingungen geschaffen, die die einzelnen Teststufen unterstützen (siehe Kap. 4.5 Teststufen ).

Zur Verbesserung der Produktreife im Rahmen der Zulassungstests wird die Eigenverantwortung der Industrie durch Produkttests und produktübergreifende Tests gefordert. Eine Überprüfung der Produktreife erfolgt im Rahmen der Eingangsprüfung in der Testumgebung.

Hersteller und Anbieter von Produkten tragen zur Ende-zu-Ende-Funktionalität bei, da reine Tests der Produktschnittstellen nicht ausreichen, um Interoperabilität zu gewährleisten. Zur Wahrnehmung dieser Verantwortung ist es notwendig, den Herstellern und Anbietern die Möglichkeit zu geben, koordinierte Ende-zu-Ende-Tests durchzuführen.

Die genannten Zusammenhänge werden in der nachfolgenden Abbildung dargestellt.

Abbildung 1: Überblick der Testphasen

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

2.3 Testspezifische Rollen

Die betrieblichen Rollen und Akteure werden im spezifischen Betriebskonzept der TI [gemKPT_Betr] definiert. Darüber hinaus gibt es im Rahmen des Testgeschehens spezifische Aufgaben, die die allgemeine Definition ergänzen. Außerdem gibt es zusätzliche Rollen, die nur im Testgeschehen wirksam werden.

Die folgenden Rollen werden im Test wahrgenommen:

• Testkoordinierende Instanz (TKI) RU/TU (gematik)
• Testintegrator zentrale Plattformdienste (TIZP)
  
• Testbetriebsinstanz (TBI) (Anbieter bereits zugelassener Dienste)
  
• testdurchführende Instanz (TDI) RU (Hersteller)
• testdurchführende Instanz (TDI) TU (gematik)
• Test- & Transitionmanager (TTM) (gematik)

werden im Anschluss definiert.

Der Anbieter zentrale Plattformdienste (AZPD) hat die Rollen TBI und TIZP inne.

Die folgende Abbildung zeigt einen Überblick des Rollenkonzepts:

Abbildung 3: Rollen innerhalb der Systemumgebungen

2.3.1 Testkoordinierende Instanz (TKI)

Die testkoordinierende Instanz erfüllt den gesetzlichen Testauftrag hinsichtlich § 291b SGB V und hat die übergreifende Koordinationsverantwortung für alle Test- und Wartungsmaßnahmen in der Referenz- und Testumgebung. Die testkoordinierende Instanz hat die übergreifende Verantwortung zur Sicherstellung der qualitäts- und termingerechten Umsetzung aller geplanten Test- und Wartungsvorhaben an Test- und Referenzobjekten.

In diesem Zusammenhang vertritt die testkoordinierende Instanz die Interessen der gematik zur Wahrung des diskriminierungsfreien Zugangs auf die Umgebungen durch Dritte und der gematik selbst. Die Hauptaufgaben der testkoordinierenden Instanz sind:

• Gewährleistung des diskriminierungsfreien Zugangs für alle Zulassungsnehmer
• Koordination von produktübergreifenden Tests
• Eskalative Instanz bei Termin- und Interessenskonflikten seitens der Zulassungsnehmer
• Regelmäßige Abstimmung mit TBI und TDI aller Zulassungsnehmer bezüglich aktueller und geplanter Test- und Wartungsaktivitäten
• Kontrolle der Testbelegungsplanung der Referenzumgebung mittels Test-Kalender
• Bewertung und Kommunikation von Risiken und Problemen an die Beteiligten der jeweiligen Systemumgebung
• Beauftragung von Services beim Testbetriebsverantwortlichen

2.3.2 Testintegrator zentrale Plattformdienste (TIZP)

Der TIZP ist für die Integration von Komponenten, Diensten und weiterer Anwendungen in RU und TU verantwortlich. Er bietet anderen Zulassungsnehmern die Anbindung an die TI an und integriert deren Produkte netztechnisch in die jeweilige Testbetriebsumgebung (RU/TU). Hierzu legt er z. B. IP-Adressen fest und konfiguriert Firewallregeln.

Der AZPD bietet über die Rolle TIZP einen Servicekatalog an, über die die in den Systemumgebungen nutzbaren zentralen Services abgerufen werden können.

2.3.3 Testbetriebsinstanz (TBI)

Die Testbetriebsinstanz für die Referenz- und Testumgebung gewährleistet den Betrieb ihrer jeweiligen Produkte in den Systemumgebungen RU und TU.

Die Verantwortung für die dezentrale Zone liegt bei der gematik (TU) bzw. bei einem von der gematik beauftragten Dienstleister (RU). Die Rolle der TBI wird vom jeweiligen Anbieter bzw. Hersteller des Dienstes oder der Komponente ausgeübt, wie in Abbildung 3: Rollen innerhalb der Systemumgebungen dargestellt.

Sofern in den jeweiligen Produkttypsteckbriefen gefordert wird, dass Services angeboten werden müssen, ist die TBI auch hierfür verantwortlich.

2.3.4 Testdurchführende Instanz (TDI) Referenzumgebung (RU)

Die testdurchführende Instanz der RU plant, steuert und verantwortet die Durchführung von Testmaßnahmen im Sinne der Qualitätssicherung seitens der Zulassungsnehmer. Diese Testmaßnahmen haben zum Ziel, der gematik die Funktionalität, Interoperabilität und Sicherheit in Form von eigenverantwortlichen Tests nachzuweisen. Die testdurchführende Instanz in der Referenzumgebung ist in der Regel der Zulassungsnehmer.

Die testdurchführende Instanz muss eigenverantwortlich die Durchführung von Testmaßnahmen als Qualitätssicherungsmaßnahme im Rahmen weiterer Lieferungen und Leistungen vollziehen (z. B. zur Fehlernachstellung als Wartungsleistung). Sie besitzt die zentrale Ergebnisverantwortung für alle eigenen Testmaßnahmen in der RU.

Testinhalte, -umfang und Testtiefe werden auf Grundlage des aktuellen Produkttypsteckbriefes von der Testdurchführenden Instanz mit dem jeweiligen Test & Transitionmanager der gematik abgestimmt und müssen die funktionalen Anforderungen zunächst vollumfänglich abdecken. Weitere Testdurchläufe können im Rahmen eines Regressionstests in Abstimmung mit dem Test & Transitionmanager der gematik durchgeführt werden.

Die TDI RU trägt die Verantwortung zur Einbindung ihres Produkts in alle Systemumgebungen (RU, TU) als Testobjekt und nach erfolgter Zulassung als Referenzobjekt in alle Systemumgebungen und die Produktivumgebung. Eine Erklärung von Test- und Referenzobjekten folgt in Kapitel 3.2.8. Die Einbringung als Referenzobjekt in alle Systemumgebungen erfolgt über den betrieblichen Changeprozess. Hier kann das ursprüngliche Testobjekt als Referenzobjekt genutzt werden, sobald dieses zugelassen ist.

In der Testphase der Eigenverantwortlichen Tests muss die TDI RU folgende Leistungen erbringen:

• Herstellung der Testbereitschaft inklusive Testdokumentation
• Durchführung der Tests (Gewährleistung der Durchführung aller geforderten Testarten)
• Erstellung eines schriftlichen Testberichts über die eigenverantwortlichen Tests
• Planung aller Testaktivitäten in der RU
• Fachkundige Beratung bei der Planung und Vorbereitung von Tests in der TU
• Unterstützung beim Nachstellen und Analysieren von auftretenden Fehlern in der TU
• Behebung von Fehlern seines Produkts

2.3.5 Testdurchführende Instanz (TDI) Testumgebung (TU)

Die testdurchführende Instanz der TU wird durch den Test- & Transitionmanager der gematik repräsentiert. Er hat die zentrale Ergebnisverantwortung für alle Testmaßnahmen in der TU für das jeweilige Produkt.

2.3.6 Test- & Transitionmanager (TTM)

Der Test- & Transitionmanager führt den Zulassungsnehmer durch den Prozess der funktionalen Nachweisführung (Test) in der Zulassung und koordiniert die Einbringung der Testobjekte in RU/TU und Bereitstellung der Konfigurationen. Er stellt durch Koordination der Güteprüfung, der Testberichte der TDI RU und der gematik-eigenen Testmaßnahmen in der TU die Qualität der jeweiligen Produkte sicher. Folgende Punkte gehören zu seinen Hauptaufgaben:

• Planung von kostenpflichtigen Diensten oder Konfigurationen für Testmaßnahmen mit der TDI RU
• Beteiligung im CAB und Vorgabe der Testmaßnahmen in den Systemumgebungen
• Prüfung von produkttypspezifischen Testkonzepten und Testfallspezifikationen des Zulassungsnehmers
• Planung und Steuerung der Zulassungstests
• Unterstützung bei der Einbindung der Testobjekte in die Systemumgebungen
• Koordination und Steuerung von Fehlerabsprachen
• Eskalation von Problemen im Zulassungsprozess
• Begleitung des Changeprozesses zur Einbindung der Referenzobjekte in die Systemumgebungen in enger Abstimmung mit den Service Delivery Managern (SDM) der gematik

2.4 Testphasen

Um den Zweck der Aufteilung in die Testphasen zu verdeutlichen, werden die zwei Testphasen durch eine kurze Beschreibung charakterisiert. Die Testziele und die jeweiligen Eingangs- und Ausgangskriterien werden aufgeführt.

Eingangskriterien beschreiben Mindestkriterien für den Beginn einer Testphase bzw. deren jeweiligen Teststufen. Erst wenn diese Kriterien erfüllt sind, darf mit einer Testphase begonnen werden. Durch die Definition und Prüfung von Eingangskriterien ist ein effizienter Test in der Testphase gewährleistet.

Ausgangskriterien beschreiben Mindestkriterien für den Abschluss einer Testphase, bzw. deren jeweiligen Teststufen. Erst wenn diese Kriterien erfüllt sind, ist die Testphase beendet um das geforderte Qualitätsniveau zu erreichen.

Wenn Eingangs- oder Ausgangskriterien nicht wie gefordert erfüllt sein sollten, 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 Simulatoren entwickelt und eingesetzt werden? Müssen Testfälle mehrfach durchgeführt werden (nach Korrektur von möglichen Fehlern aus den vorigen Testphasen)?

Die Anforderungen für den jeweiligen Produkttyp sind dem Produkttypsteckbrief zu entnehmen.

In den nachfolgenden Kapiteln werden die Details zu den Teststufen (Kapitel 4.5), Testarten (Kapitel 2.5), Regressionstest (Kapitel 4.4), Systemumgebungen (Kapitel 3) und Testdokumentation (Kapitel 4.7) beschrieben.

2.4.1 Eigenverantwortlicher Test

Tabelle 1: 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.

2.4.1.1 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 Zulassungstest

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.

2.4.2 Zulassungstest

Tabelle 2: Tab_Test_006 Zulassungstest

2.4.2.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 zur Verfügung zu haben. 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.

2.4.2.2 Testabbruch

Der Zulassungstest kann grundsätzlich in jeder Testphase bzw. Teststufe sowohl durch den Antragsteller als auch durch die gematik abgebrochen werden.
Die gematik behält sich einen Abbruch der Zulassungstests insbesondere vor, wenn abweichende Ergebnisse gegenüber den dokumentierten Ergebnissen zu Eigenverantwortlichen Tests in der RU 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 dem Antragsteller über das Vorliegen von Gründen für einen Testabbruch, einschließlich der Auswertung bis dahin festgestellter Fehler, schriftlich informieren.

2.5 Testarten

Die folgende Abbildung zeigt die Zuordnung der in diesem Kapitel beschriebenen Testarten zu den jeweiligen Testphasen und Teststufen.

Abbildung 4: Zuordnung Testarten

2.5.1 Güteprüfung

Die Güteprüfung ist eine statische Testart der gematik, in welcher die Testdokumentationen der eigenverantwortlichen Tests hinsichtlich Vollständigkeit, formaler und inhaltlicher Korrektheit, Konsistenz und Widerspruchsfreiheit und Nachvollziehbarkeit geprüft werden. Die Ergebnisse werden in einem Güteprüfungsprotokoll dokumentiert. Eine abgeschlossene Güteprüfung ist eine Voraussetzung für den Abschluss der Zulassungstests der gematik.

2.5.2 Funktionstest

Der Funktionstest überprüft, ob die Fachanwendung bzw. die Produkte den funktionalen Anforderungen genügen.

Für die Tests muss es einen definierten Ausgangszustand geben (Testdaten, Systemumgebungseinstellungen). Dieser muss nach einer Anzahl von durchgeführten Tests wiederhergestellt werden können, um eine verlässliche Ausgangsbasis für die Tests zu haben.

2.5.3 Interoperabilitätstest

Das Testziel des Interoperabilitätstests ist der Nachweis der korrekten funktionalen Interaktion der Produkte untereinander. Die Integration erfolgt stufenweise. Für den Interoperabilitätstest werden speziell vier Hauptkategorien unterschieden:

• Ende-zu-Ende-Tests der Anwendungsfälle (Use Cases)
• Fehlersituationen – unter anderem Tests von Fehlercodes, Zeittests, unspezifizierte Fehler
• Ausfalltests – mögliche Auswirkungen von Ausfällen von Produkten auf andere Produkte
• Tests der Public-Key-Infrastructure (PKI) (z. B. Zertifikatsmanagement, Wechsel Vertrauensanker)

2.5.4 Leistungstest

Der Leistungstest beinhaltet die Überprüfung des geforderten Antwortzeit- und Durchsatzverhaltens der in [gemSpec_Perf] definierten Anwendungsfälle. Außerdem wird getestet, ob sich Produkte unter Last beim Ausfall von aufgerufenen Produkten robust verhalten. Im Rahmen des Leistungstests werden Einzelinstanzen oder integrierte Teilsysteme einem Leistungstest unterzogen. Beim Leistungstest des Gesamtsystems unter Einbeziehung der dezentralen Komponenten wird Last auf die zentralen Dienste gelegt und parallel dazu Ende-zu-Ende-Antwortzeiten von Anwendungsfällen an der Schnittstelle Clientsystem – TI gemessen.

3 Systemumgebungen

Für die Tests der Zulassungsobjekte sind die Systemumgebungen „Referenzumgebung“ und „Testumgebung“ vorgesehen. Hierbei wird in einen zentralen und einen dezentralen Bereich unterschieden.

Die folgende Tabelle listet auf, was die Systemumgebungen für die Tests leisten sollen.

Tabelle 3: Tab_Test_001 Überblick Systemumgebungen 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.

Produkte müssen im Sinne dieser Trennung ebenfalls für jede Systemumgebung separat bereitgestellt werden. Hierbei sind grundsätzlich folgende Quellen für Mengengerüste zu beachten:

RU: Anzahl der Produkte wird von den Herstellern und Anbietern bzw. der testdurchführenden Instanz der RU verantwortet. Für einzelne Produkttypen werden in der RU mehrere Instanzen betrieben. In der Regel handelt es sich dabei zum einen um Entwicklungsversionen und zum anderen produktionsnahe Systeme.

TU: Anzahl der Produkte ergibt sich aus der Spezifikation bzw. für dezentrale Produkte aus der Verfahrensbeschreibung der Zulassung. Für einzelne Produkttypen werden in der TU mehrere Instanzen betrieben. In der Regel handelt es sich dabei zum einen um Entwicklungsversionen und zum anderen produktionsnahe Systeme.

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.

3.1 Testobjekte

Die folgende Grafik gibt eine Übersicht des Gesamtsystems TI und der Verteilung der Produkttypen der TI:

Abbildung 5: Übersicht des Gesamtsystems Telematikinfrastruktur

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

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

3.2.1 Trennung der Netzwerke

3.2.2 Trennung der Vertrauensräume

3.2.3 Gemeinsame Eigenschaften für alle Systemumgebungen

3.2.4 Gemeinsame Eigenschaften der Referenz- und Testumgebung

3.2.5 Exklusiver Zugriff

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

3.2.7 Testwerkzeuge

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

3.2.9 Referenzumgebung

3.2.9.1 Qualitätssicherungsmaßnahmen der Hersteller und Anbieter

3.2.9.2 Weiterentwicklung der Referenzumgebung

3.2.9.3 Nutzung der Referenzumgebung

3.2.9.4 Instanzen der Referenzumgebung

3.2.10 Testumgebung

3.2.10.1 Bestandteile der Testumgebung

3.2.10.2 Weiterentwicklung der Testumgebung

3.2.10.3 Dimensionierung der Testumgebung

3.2.10.4 Betrieb der Testumgebung

3.2.10.5 Nachstellen von PU-Fehlern in TU

4 Szenarien

4.1 Einleitung

In diesem Kapitel werden zunächst die verschiedenen Szenarien identifiziert unter denen Testmaßnahmen durchgeführt werden müssen. Anschließend werden für jedes Szenario die Rahmenbedingungen und konkrete Anwendung der in Kapitel 2 beschriebenen allgemeinen Testvorgehensweise beschrieben.

Die Unterscheidung nach zentralen und dezentralen Produkten sowie Fachanwendungen erfolgt gemäß Kapitel 3.1.

4.2 Testvorgehensweise im Rahmen der Zulassung eines neuen Produkts

Tabelle 6: Tab_Test_021 Szenario: Zulassung eines neuen Produkts

4.3 Testvorgehensweise im Rahmen der Zulassung eines geänderten Produkts

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

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

4.5 Teststufen

Die Teststufen laufen sequentiell ab. Eine Teststufe beginnt erst, wenn die vorherige Teststufe erfolgreich abgeschlossen ist. Dieses Vorgehen erfolgt sowohl bei den Eigenverantwortlichen Tests (EvT) wie auch bei den Zulassungstests (ZulT).

4.5.1 Produkttest (EvT)

Tabelle 8: Tab_Test_008 Produkttest (EvT)

4.5.2 Produktübergreifender Test (EvT)

Tabelle 9: Tab_Test_009 Produktübergreifender Test (EvT)

4.5.3 Eingangsprüfung (ZulT)

Tabelle 10: Tab_Test_010 Eingangsprüfung (ZulT)

4.5.4 Produkttest (ZulT)

Tabelle 11: Tab_Test_011 Produkttest (ZulT)

4.5.5 Produktübergreifender Test (ZulT)

Tabelle 12: Tab_Test_012 Produktübergreifender Test (ZulT)

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

Tabelle 13: Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung

4.7 Testdokumentation

Zur Dokumentation der Testaktivitäten der verschiedenen Testphasen und Teststufen sollen durch die Hersteller bzw. die testdurchführende Instanz unterschiedliche Dokumente erstellt werden.

Die Testdokumentation eines Herstellers 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.

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

4.7.1 Testkonzept

Tabelle 14: Tab_Test_013 Testkonzept

4.7.2 Testspezifikation

Tabelle 15: Tab_Test_014 Testspezifikation

4.7.3 Release Notes

Tabelle 16: Tab_Test_015 Release Notes

4.7.4 Produktdokumentation

Tabelle 17: Tab_Test_016 Produktdokumentation

4.7.5 Testprotokoll

Tabelle 18: Tab_Test_017 Testprotokoll

4.7.6 Testbericht

Tabelle 19: Tab_Test_018 Testbericht

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

5 Fachanwendung VSDM

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

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

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

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

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

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

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

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

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

8 Fachanwendung ePA für alle

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

8.1 ePA-Aktensystem

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

8.2 ePA-Frontend des Versicherten

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

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

9.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 6: 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 7: 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 8: Schematische Darstellung zur Integration des Testtreibers über die GUI des Remote-Test-FdV

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

10 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 9: Ü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.

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

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

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

11.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 20: Tab_Test_027 Eigenverantwortlicher Test WANDA

Tabelle 21: 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.

12 Anhang A – Verzeichnisse

12.1 Abkürzungen

12.2 Glossar

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

12.3 Abbildungsverzeichnis

12.4 Tabellenverzeichnis

12.5 Referenzierte Dokumente

12.5.1 Dokumente der gematik

12.5.2 Weitere Dokumente