Elektronische Gesundheitskarte und Telematikinfrastruktur
Testkonzept der TI
Version | 2.10.0 |
Revision | 1156041 |
Stand | 20.11.2024 |
Status | freigegeben |
Klassifizierung | öffentlich |
Referenzierung | gemKPT_Test |
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version |
Datum |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
... | ||||
2.8.0 | 19.02.2021 | Einarbeitung Änderungsliste 22.5 | gematik | |
2.8.1 | 09.07.2021 | Einarbeitung Änderungsliste ePA_Maintenance_21.2 | gematik | |
2.8.2 | 02.09.2021 | Einarbeitung Konn_Maintenance_21.5, Umbenennung der Begriffe "aAdG-NetG" durch "WANDA Basic", "aAdG" und "aAdG-NetG-TI" durch "WANDA Smart" |
gematik | |
2.8.3 | 07.10.2021 | Einarbeitung gemF_APOVZD und E-Rezept_Maintenance_21.2 | gematik | |
2.8.4 | 28.10.2021 | 4.6 | Einarbeitung Test_Maintenance_21.1 | gematik |
2.8.5 | 31.01.2022 | 4.6 | Einarbeitung Konn_Maintenance_21.6 | gematik |
2.8.6 | 03.02.2023 | Einarbeitung IDP_Maintenance_22.2 | gematik | |
2.8.7 | 10.07.2023 | 4.6 | Einarbeitung Test_Maintenance_23.1, HSK_Maintenance_23.1 | gematik |
2.8.8 | 20.09.2023 | 5.1, 5.2, 5.3, 10.5.1 | Einarbeitung Smartcard_23.1 | gematik |
2.9.0 | 30.01.2024 | 4.6 8 9 10 |
Überarbeitung IOP-Tabelle Einarbeitung Fachanwendung ePA für alle Einarbeitung TI-Module in FdVs der Krankenversicherungen Einarbeitung TI-Messenger |
gematik |
2.9.1 | 13.06.2024 | Einarbeitung TI-Messenger_24.1 | gematik | |
2.9.2 | 13.06.2024 | Einarbeitung CI_24.3, ePAfueralle_3.0.3 | gematik | |
2.10.0 | 20.11.2024 | Einarbeitung Test_24.1 (C_11618, C_11735, C_11857) | gematik |
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).
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.
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.
Normative Vorgaben zu Themen, welche nicht nur den Test betreffen, wie z. B. Releasemanagement, Migration, Zulassung und Betrieb, sind nicht Bestandteil dieses Konzepts.
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.
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:
Die jeweiligen Aktivitäten der Testphasen finden in eigenen Systemumgebungen (siehe Kapitel 3 Systemumgebungen ) statt:
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
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.
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:
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
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:
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.
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.
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:
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.
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:
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:
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.
Tabelle 1: Tab_Test_005 Eigenverantwortlicher Test
Testphase |
Eigenverantwortlicher Test |
---|---|
Beschreibung |
In der Testphase „Eigenverantwortlicher Test“ werden die entwickelten Produkte durch die Hersteller gegen die Anforderungen aus den zugrundeliegenden Konzepten und Spezifikationen, welche in dem jeweiligen Produkttypsteckbrief zusammengefasst sind, geprüft. Dies schließt die Erfüllung der fachlichen Anforderungen (Ende-zu-Ende), der funktionalen technischen Anforderungen, der nicht-funktionalen Anforderungen und der Sicherheitsanforderungen sowie eine vollständige Integration ihres jeweiligen Produkts ein. Die Anforderungen sind in der Regel der jeweils neusten Version einer Spezifikation bzw. eines Konzepts zu entnehmen. |
Ziel |
Nachweis der Erfüllung der an das jeweilige Produkt gestellten Anforderungen aus den zugrundeliegenden Konzepten und Spezifikationen. Nachweis der Durchführbarkeit von den Anwendungsfällen an welchen die Produkte beteiligt sind. |
Eingangskriterien |
Die Systemumgebung steht zur Verfügung. Die erforderliche Testdokumentation wurde erstellt und geliefert (Testkonzept, einzelne Testspezifikationen, ggf. Dokumente zu Produktausprägungen). Das funktionierende Testobjekt wurde geliefert oder in der RU bereitgestellt. Das in Betrieb genommene Testobjekt wurde in der Referenzumgebung vollständig installiert und konfiguriert. |
Ausgangskriterien |
Die erforderliche Testdokumentation inkl. vollständiger Testfallspezifikation wurde erstellt und geliefert (Release Notes, Produktdokumentation, Testprotokoll, Testbericht) und von der gematik stichprobenartig geprüft. Es liegen keine zulassungstestverhindernden Probleme vor. Der vorab zwischen TDI RU und Test- & Transitionmanager vereinbarte Testabdeckungsgrad und Testumfang wurde erreicht und dokumentiert. |
Testdokumentation/ Leistungsgegenstände |
Testkonzept Testspezifikation inkl. Testfallspezifikationen Testprotokoll der Eigenverantwortlichen Tests Testbericht der Eigenverantwortlichen Tests Release Notes Produktdokumentation |
Teststufen |
Produkttest (EvT) Produktübergreifender Test (EvT) |
Systemumgebung |
Referenzumgebung |
Aufgaben des Test & Transitionmanagers |
Prüfen, ob die Ausgangskriterien der Eigenverantwortlichen Tests erfüllt sind. Sind die Testausgangskriterien nicht erfüllt, gilt die Testphase als nicht abgeschlossen. |
Aufgaben des TIZP | Anbindung des Testobjekts an das zentrale Netz und Konfiguration des zentralen Netzes (z. B. Firewallfreischaltung, IP-Adressvergabe, DNS-Vergabe) |
Aufgaben der TBI |
Sicherstellung der Verfügbarkeit des eigenen - am Test beteiligten - Produkts (Referenzobjekt) (detaillierte Anforderungen siehe Kapitel 3 Systemumgebungen ). |
Aufgaben der TDI RU |
Durchführung der Tests. Tests dürfen in Absprache mit dem Test- und Transitionmanager auch mittels Simulatoren durchgeführt werden. Bereitstellung der erforderlichen Testdokumentation. Im Rahmen der Testmaßnahmen die jeweils relevanten Clientsysteme berücksichtigen und in die Testmaßnahmen einbinden. Den Umfang von Regressionstests bei der Planung von Tests für neue Versionen der Fachanwendung bzw. der Produkte in Absprache mit dem Test- & Transitionmanager der gematik festlegen. Pflege der eigenen Tests im Testkalender |
Pflichten Hersteller und Anbieter |
Nach Vorgabe der gematik die qualitätssichernden Maßnahmen unterstützen und auf Anfrage der gematik Produktmuster inkl. einer (Vorab-) Version der Produktdokumentation liefern. Lieferung oder Anbindung des Testobjekts. Für ihren jeweiligen Produkttyp die relevanten Teststufen, Testarten und Testdaten unterstützen. Bereitstellung der erforderlichen Testdokumentation. |
Die testdurchführende Instanz kann die benötigten Services zum Anbinden des Testobjekts beim TIZP über den Servicekatalog des AZPD buchen.
TIP1-A_6517-01 - Eigenverantwortlicher Test: TBI
Die TBI der Referenzumgebung MUSS seine Aufgaben gemäß Tabelle Tab_Test_005 Eigenverantwortlicher Test erfüllen. [<=]
TIP1-A_6518 - Eigenverantwortlicher Test: TDI
Die TDI der Referenzumgebung MUSS ihre Aufgaben gemäß Tabelle Tab_Test_005 Eigenverantwortlicher Test erfüllen. [<=]
TIP1-A_6519 - Eigenverantwortlicher Test: Hersteller und Anbieter
Hersteller und Anbieter MÜSSEN im Rahmen der Eigenverantwortlichen Tests ihre Pflichten gemäß Tabelle Tab_Test_005 Eigenverantwortlicher Test erfüllen. [<=]
Im Rahmen der eigenverantwortlichen Tests behält sich die gematik folgende qualitätssichernde Maßnahmen vor:
TIP1-A_7358 - Qualität des Produktmusters
Produktmuster haben folgende Ziele:
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.
Tabelle 2: Tab_Test_006 Zulassungstest
Testphase |
Zulassungstest |
---|---|
Beschreibung |
Nachweis von Funktionalität und Interoperabilität durch den Test der gematik. Die gematik behält sich vor, das Produkt ggf. weitgehender zu testen als dies über die ursprüngliche im Testkonzept beschriebene Anforderungslage an die eigenverantwortlichen Tests gefordert wird. |
Ziel |
Sicherstellung, dass die an die Produkte gestellten Anforderungen zur funktionalen Eignung (Produkttest/Produktübergreifender Test) aus den zugrundeliegenden Konzepten und Spezifikationen erfüllt werden. Sicherstellung, der Durchführbarkeit der Anwendungsfälle an denen das Produkt beteiligt ist. |
Eingangskriterien |
|
Ausgangskriterien |
|
Testdokumentation/ Leistungsgegenstände |
|
Teststufen |
|
Systemumgebung |
Testumgebung |
Aufgaben der Test- & Transitionmanager |
Prüfen, ob die Eingangskriterien der Zulassungstests erfüllt sind. Sind die Eingangskriterien nicht erfüllt, kann der Zulassungstest in der TU nicht gestartet werden. Bei positivem Ausgang der Eingangsprüfung das jeweilige Produkt dem Produkttest zuführen. Bei positivem Ausgang des Produkttests das jeweilige Produkt dem produktübergreifenden Test zuführen. Die Testdurchführung trotz ermittelter Probleme eines Produkts fortsetzen, sofern die ermittelten Probleme es qualitativ und/oder quantitativ nicht verhindern. Ermittelte Probleme eines Produkts zeitnah und klassifiziert nach Schweregrad an den Hersteller bzw. Anbieter übermitteln. Gewährleisten, dass Probleme entsprechend nachfolgenden Kategorien zugeordnet werden: „Sehr schwer“, „Schwer“, „Mittel“, „Leicht“. Prüfen, ob die Ausgangskriterien der Zulassungstests erfüllt sind. Sind die Testausgangskriterien nicht erfüllt, gilt die Testphase als nicht abgeschlossen. |
Aufgaben des TIZP | Installation und Konfiguration des Testobjekts an das zentrale Netz (z. B. Firewallfreischaltung, IP-Adressvergabe, DNS-Vergabe) |
Aufgaben der TBI | Sicherstellung der Verfügbarkeit des eigenen - am Test beteiligten - Produkts (Referenzobjekt) (detaillierte Anforderungen siehe Kapitel 3 Systemumgebungen ). |
Aufgaben der TDI TU |
Bereitstellung der erforderlichen Testdokumentation. Vorbereitung und Durchführung des Zulassungstests |
Pflichten Hersteller und Anbieter |
Die Testaktivitäten in der Testumgebung gemäß den Mitwirkungspflichten im jeweiligen Zulassungsverfahren unterstützen. Erstellung und Lieferung des Testobjekts. Nach Vorgabe der gematik die qualitätssichernden Maßnahmen unterstützen und bei Bedarf Produktmuster sowie Testdaten bzw. Testkarten liefern/bereitstellen. Für ihren jeweiligen Produkttyp die relevanten Teststufen und Testarten in unterstützen. Keine eigenständigen Tests durchführen. Einen Ansprechpartner für Rückfragen bei den Zulassungstests benennen. Änderungen am TU-Testobjekt nur in Absprache mit dem Test- & Transitionmanger der gematik durchführen. |
TIP1-A_6521 - Zulassungstest: TBI
Die TBI der Testumgebung MUSS ihre Aufgaben gemäß Tabelle Tab_Test_006 Zulassungstest erfüllen. [<=]
TIP1-A_6523 - Zulassungstest: Hersteller und Anbieter
Hersteller und Anbieter MÜSSEN im Rahmen der Zulassungstests ihre Pflichten gemäß Tabelle Tab_Test_006 Zulassungstest erfüllen. [<=]
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.
A_20061 - Beschreibung Art und Umfang der Fehlerkorrektur
Der Hersteller eines Produktes MUSS auf Anfrage der gematik bei Fehlern, die im Zulassungstests festgestellt worden sind, vor der Fehlerbehebung eine kurze Beschreibung hinsichtlich Art und Umfang der Fehlerkorrektur an die gematik liefern und mit ihr abstimmen.
[<=]
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.
Die folgende Abbildung zeigt die Zuordnung der in diesem Kapitel beschriebenen Testarten zu den jeweiligen Testphasen und Teststufen.
Abbildung 4: Zuordnung Testarten
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.
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.
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:
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.
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
Systemumgebung |
Ziele |
Teststufe |
---|---|---|
Referenzumgebung |
|
|
Testumgebung |
|
|
Labortestumgebung der Hersteller (ohne TI-Anbindung) |
|
|
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.
TIP1-A_4923 - Dauerhafte Verfügbarkeit RU und TU
Die jeweilige Testbetriebsinstanz (TBI) der Referenzumgebung und der Testumgebung MUSS sicherstellen, dass ihre Produkte dauerhaft zur Verfügung stehen. [<=]
TIP1-A_2724 - TBI verantwortet Betrieb RU und TU
Die jeweilige Testbetriebsinstanz MUSS den technischen Betrieb in der Referenzumgebung und in der Testumgebung für ihr jeweiliges Referenzobjekt verantworten. [<=]
Die folgende Grafik gibt eine Übersicht des Gesamtsystems TI und der Verteilung der Produkttypen der TI:
Abbildung 5: Übersicht des Gesamtsystems Telematikinfrastruktur
TIP1-A_6526-01 - Produkttypen: Bereitstellung
Die Hersteller oder Anbieter eines Produkttyps MÜSSEN ihr Produkt pro Version gemäß Tabelle Tab_Test_019 Produkttypen der TI vorsehen.
Tabelle 4: Tab_Test_019 Produkttypen der TI
TI-Plattform zentral |
Bereitstellung |
|
---|---|---|
CVC-Root |
1x für RU/TU |
|
gematik Root-CA |
1x für RU/TU |
|
Konfigurationsdienst |
1x für RU, 1x für TU |
|
Namensdienst |
1x für RU, 1x für TU |
|
OCSP-Responder Proxy |
1x für RU, 1x für TU |
|
Sicherheitsgateway Bestandsnetze |
1x für RU/TU |
|
TSL-Dienst |
1x für RU, 1x für TU |
|
VPN-Zugangsdienst |
1x für RU, 1x für TU |
|
Zeitdienst |
1x für RU/TU |
|
Zentrales Netz |
1x für RU, 1x für TU |
|
Verzeichnisdienst (LDAP) |
1x für RU, 1x für TU |
|
Verzeichnisdienst FHIR | 1x für RU, 1x für TU |
|
Service Monitoring |
1x für RU, 1x für TU |
|
Schlüsselgenerierungsdienst | 1x für RU, 1x für TU | |
Trust Service Provider zentral |
||
TSP X.509 nonQES |
OCSP-Responder Komponenten |
1x für RU, 1x für TU |
CA-Instanz Komponenten (inkl. Datenbank) |
1x für RU/TU |
|
Trust Service Provider CVC |
Komponenten |
1x für RU/TU |
Trust Service Provider dezentral |
||
TSP X.509 nonQES |
OCSP-Responder eGK |
1x für RU/TU |
CA-Instanz eGK (inkl. Datenbank) |
1x für RU/TU |
|
OCSP-Responder HBA |
1x für RU/TU |
|
CA-Instanz HBA (inkl. Datenbank) |
1x für RU/TU |
|
OCSP-Responder SMC-B |
1x für RU/TU |
|
CA-Instanz SMC-B (inkl. Datenbank) |
1x für RU/TU |
|
Trust Service Provider CVC |
HBA |
1x für RU/TU |
SMC-B |
1x für RU/TU |
|
Trust Service Provider X.509 ES |
OCSP-Responder HBA |
1x für RU/TU |
CA-Instanz HBA (inkl. Datenbank) |
1x für RU/TU |
|
eHealth-CardLink | 1x für RU, 1x für TU | |
TI-Plattform dezentral |
||
eGK |
--- |
|
eHealth-Kartenterminal |
1x für TU |
|
gSMC-K |
--- |
|
gSMC-KT |
--- |
|
HBA |
--- |
|
Konnektor |
1x für RU, 1x für TU |
|
Highspeed Konnektor (HSK) | 1x für RU, 1x für TU |
|
Mobiles Kartenterminal |
1x für TU |
|
SMC-B |
--- |
|
KTR-AdV | 1x TU | |
Sichere Übermittlungsverfahren |
||
KIM |
Clientmodul (CM) |
1x für RU/TU |
Fachdienst (FD) |
1x für RU, 1x für TU |
|
integriertes Clientmodul (iCM) | 1x für RU/TU | |
Fachanwendungen | ||
VSDM |
Intermediär VSDM |
1x für RU, 1x für TU |
Fachdienst UFS |
1x für RU, 1x für TU |
|
Fachdienst VSDD |
1x für RU, 1x für TU |
|
Fachdienst CMS |
1x für RU, 1x für TU |
|
ePA |
ePA-Aktensystem |
2x für RU, 1x für TU |
ePA-Frontend des Versicherten |
1x für TU |
|
Signaturdienst |
1x für RU, 1x für TU |
|
Schlüsselgenerierungsdienst | 1x für RU, 1x für TU |
|
E-Rezept | E-Rezept-Fachdienst | 1x für RU, 1x für TU |
IDP | 1x für RU, 1x für TU |
|
Apothekenverzeichnis | 1x für RU/TU | |
E-Rezept FdV | 2x für RU, 1x für TU | |
TI-Messenger | TI-Messenger Fachdienst | 1x für RU |
TI-Messenger ePA Fachdienst | 1x für RU | |
TI-Messenger Pro Fachdienst | 1x für RU | |
TI-Messenger Client | 1x für RU | |
TI-Messenger ePA Client | 1x für RU | |
TI-Messenger Pro Client | 1x für RU |
TIP1-A_5053 - Nutzbarkeit Konnektor in RU/TU und PU
Der Hersteller / Anbieter eines Konnektors MUSS sicherstellen, dass dieser in allen Systemumgebungen (RU/TU und PU) betreibbar ist. Hierbei MUSS der Wechsel des Vertrauensankers und die Erkennung der unterschiedlichen Systemumgebung berücksichtigt werden. [<=]
TIP1-A_6527 - Testkarten
Die jeweiligen testdurchführenden Instanzen (TDI) der Referenzumgebung und der Testumgebung MÜSSEN sicherstellen, dass für den Testbetrieb nur die Testkarten verwendet werden, die gemäß der [gemSpec_TK] befüllt sind. [<=]
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).
In den folgenden Kapiteln sind nach Themengebieten geordnet die Anforderungen aufgeführt, die die Systemumgebungen bzw. die jeweiligen Zulassungsnehmer erfüllen müssen.
TIP1-A_3194 - Informationstechnische Trennung PU von RU/TU
Der TIZP MUSS sicherstellen, dass die RU und die TU von der PU dadurch informationstechnisch getrennt werden, dass unterschiedliche Namensräume, Vertrauensräume und Kommunikationspfade eingerichtet werden. [<=]
TIP1-A_3195 - Logische Trennung RU und TU
Der TIZP MUSS sicherstellen, dass die Referenzumgebung von der Testumgebung bis zu den Zugangspunkten des Zentralen Netzes logisch separiert ist. [<=]
TIP1-A_2710 - Netzwerktechnologie Testumgebung
Der TIZP MUSS für die Testumgebung die identische Netzwerktechnologie wie in der Produktivumgebung verwenden. [<=]
TIP1-A_2713 - Separate Vertrauensräume
Der TIZP MUSS sicherstellen, dass neben dem Vertrauensraum der Produktivumgebung genau ein davon völlig separierter und rückwirkungsfreier Vertrauensraum für die Referenzumgebung und die Testumgebung eingerichtet werden (Nicht-Produktiv-Vertrauensraum). [<=]
TIP1-A_3016 - Nutzung Nicht-Produktiv-Vertrauensraum für RU und TU
Der TIZP MUSS sicherstellen, dass der für die Testsysteme definierte Vertrauensraum gleichermaßen für die Referenzumgebung und Testumgebung genutzt werden kann. [<=]
TIP1-A_4191 - Keine Echtdaten in RU und TU
Die jeweiligen testdurchführenden Instanzen (TDI) der Referenzumgebung und der Testumgebung MÜSSEN sicherstellen, dass keine Echtdaten in die Referenzumgebung und in die Testumgebung eingebracht werden. [<=]
TIP1-A_4928 - Testidentitäten für RU und TU
Der TIZP MUSS sicherstellen, dass nicht smartcard-basierte Testidentitäten (z. B. Softwarezertifikate) für Geräte in der Referenzumgebung und der Testumgebung bereitgestellt werden. [<=]
GS-A_2162 - Kryptographisches Material in Entwicklungs- und Testumgebungen
Die jeweiligen testdurchführenden Instanzen (TDI) und die jeweilige Testbetriebsinstanz (TBI) der Referenzumgebung und der Testumgebung MÜSSEN sicherstellen, dass in diesen Umgebungen keine kryptographischen Identitäten bzw. Schlüssel der Produktivumgebung der TI (Umgebungen mit Echtdaten) genutzt werden. [<=]
TIP1-A_5049 - Betriebliche Umsetzung von Teststufen
Der TIZP MUSS die Durchführbarkeit einzelner Teststufen in der jeweiligen Systemumgebung sicherstellen. [<=]
TIP1-A_2718 - Betriebliche Zielstellungen in RU und TU
Der TIZP MUSS sicherstellen, dass alle Systemumgebungen entsprechend der Vorgaben aus den übergreifenden Richtlinien zum Betrieb der TI [gemRL_Betr_TI] ausgeprägt sind. [<=]
TIP1-A_4930 - Automatisierung von Tests
Die testdurchführenden Instanzen der Referenzumgebung und der Testumgebung SOLLEN Tests automatisieren. [<=]
TIP1-A_3360 - Zentraler Anlaufpunkt für Anfragen und Probleme in RU und TU
Der TIZP MUSS sicherstellen, dass in der Referenzumgebung und in der Testumgebung ein zentraler Anlaufpunkt für Anfragen und Probleme hinsichtlich Bereitstellung sowie Integration von Produkten und des Betriebs der RU oder TU eingerichtet wird. [<=]
TIP1-A_2720 - RU/TU: Funktionales Abbild der Produktivumgebung
Die jeweilige TBI MUSS sicherstellen, dass die Produkte der Referenzumgebung und Testumgebung bei laufendem Produktivbetrieb ein funktionales Abbild (Produkte und Konfigurationen) der Produkte der Produktivumgebung sind. [<=]
TIP1-A_2726 - Bestandteile RU und TU
Die jeweilige TBI MUSS sicherstellen, dass ihre zugelassenen Produkte (Referenzobjekte) in der Referenzumgebung und der Testumgebung enthalten sind, die durch die Architekturen der TI-Plattform und der Fachprojekte festgelegt wurden. [<=]
TIP1-A_2727 - Sicherstellung der Kommunikation in RU und TU
Der TIZP MUSS sicherstellen, dass in der Referenzumgebung und in der Testumgebung die gleiche Netzwerkarchitektur wie in der Produktivumgebung genutzt wird. [<=]
TIP1-A_2722-01 - TBI integriert die Produkttypen in seine Systemumgebung
Die jeweilige TBI MUSS Testobjekte und Referenzobjekte in die Referenzumgebung und die Testumgebung integrieren. [<=]
TIP1-A_3017 - Systemumgebungsmanagement RU sowie TU
Die jeweilige TBI MUSS sicherstellen, dass das Systemumgebungsmanagement unterschiedliche Konfigurationen und Wiederherstellungspunkte für die Referenzumgebung und Testumgebung ermöglicht (Testdatenbestand, Konfigurationseinstellungen, Versionen).
Die Fachdienstbetreiber VSDM müssen keine älteren Konfigurationseinstellungen und Versionen bereitstellen. [<=]
TIP1-A_3361 - Dokumentation für den Betrieb in der RU und TU bereitstellen
Die TBI MUSS sicherstellen, dass alle erforderlichen Dokumente (z.B. der Netzplan) für den Betrieb der Referenzumgebung und der Testumgebung den Beteiligten vor Testbeginn zur Verfügung gestellt werden. [<=]
TIP1-A_6083 - Anzahl der Fachdienste als Referenzobjekte
Es SOLLEN mindestens zwei Fachdienste VSDM in TU und RU permanent als Referenzobjekt zur Verfügung stehen. Eine Abstimmung und die Koordination findet über den Test & Transitionmanager der gematik statt. Ausnahmen für die Verfügbarkeit von weniger als zwei Fachdiensten als Referenzobjekte SOLLEN mit dem Test & Transitionmanager der gematik abgestimmt werden. [<=]
TIP1-A_2737 - Exklusiver Zugriff bestimmter Akteure
Der TIZP MUSS sicherstellen, dass auf Anfrage der jeweiligen testdurchführenden Instanz (Zulassungsnehmer) der jeweiligen Systemumgebung ein zeitlich exklusiver und diskriminierungsfreier Zugriff auf Produkte, Fachdienstschnittstellen und Kommunikationspfade in der Referenzumgebung bzw. in der Testumgebung in Abstimmung mit der TKI der gematik bereit gestellt werden kann. [<=]
TIP1-A_2738 - Exklusiver Zugriff organisatorisch
Die jeweilige TBI SOLL den zeitlich exklusiven Zugriff für bestimmte Akteure (Personen, Produkte, Testwerkzeuge) in der Referenzumgebung und in der Testumgebung durch organisatorische Maßnahmen unterstützen. [<=]
TIP1-A_2739 - Exklusiver Zugriff technisch unterstützt
Der TIZP SOLL den zeitlich exklusiven Zugriff für bestimmte Akteure (Personen, Produkte, Testwerkzeuge) in der Referenzumgebung und in der Testumgebung durch technische Mittel unterstützen. [<=]
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.
TIP1-A_2740 - Logging von Produktaußenaktivitäten
Der TIZP MUSS für ein detailliertes Logging von Aktivitäten an Außenschnittstellen aller am Test beteiligten Produkte mit Hilfe geeigneter Testwerkzeuge in der Referenzumgebung und Testumgebung sorgen (Produkte als Black-Box). [<=]
TIP1-A_2745 - Außenlogging zeitgleich mit Produktbereitstellung
Der TIZP MUSS sicherstellen, dass zeitgleich mit der Bereitstellung von Produkten für die TI das Loggen an den Außenschnittstellen der betreffenden Produkte in der Referenzumgebung und Testumgebung erfolgen kann. [<=]
TIP1-A_2741 - Logging auf Applikationsebene
Der TIZP MUSS sicherstellen, dass Außenaktivitäten von allen am Test beteiligten Produkten in der Referenzumgebung und Testumgebung auf Applikationsebene protokolliert werden. [<=]
TIP1-A_2742 - Logging von Aktivitäten auf Transportebene
Der TIZP MUSS sicherstellen, dass Außenaktivitäten von allen am Test beteiligten Produkten in der Referenzumgebung und Testumgebung auf Transportebene protokolliert werden. [<=]
TIP1-A_2743 - Logging von Aktivitäten auf Netzwerkebene
Der TIZP MUSS sicherstellen, dass Außenaktivitäten von allen am Test beteiligten Produkten in der Referenzumgebung und Testumgebung auf Netzwerkebene protokolliert werden. [<=]
TIP1-A_3362 - Bereitstellung Logdaten in RU und TU
Der TIZP MUSS sicherstellen, dass die Logdaten der am Test beteiligten Produkte sofort nach deren Erzeugung der testdurchführenden Instanz der betreffenden Systemumgebung zur Verfügung gestellt werden. [<=]
TIP1-A_7330 - Tracedaten von echten Außenschnittstellen
Die testdurchführende Instanz SOLL seine eigenverantwortlichen Tests an den Außenschnittstellen des Testobjekts und nicht an internen Loopback Devices durchführen.
[<=]
TIP1-A_7331 - Bereitstellung von Tracedaten an Außenschnittstelle
Die testdurchführende Instanz SOLL bei eigenverantwortlichen Tests an denen an der Außenschnittstelle des Produkts Daten transferiert werden der gematik einen Mitschnitt zur Verfügung stellen, der die folgenden Punkte erfüllt:
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.
TIP1-A_2731 - Integration von Testwerkzeugen in RU und TU
Der TIZP MUSS in der Referenzumgebung und in der Testumgebung die Möglichkeit bieten, Testwerkzeuge hardware- und softwaremäßig zu integrieren. Der TIZP MUSS den Zugriff und die Nutzung dieser Testwerkzeuge der jeweiligen testdurchführenden Instanz jederzeit gewähren und sicherstellen. Der TIZP MUSS der testdurchführenden Instanz die entsprechenden Rechte auf dem Testwerkzeug gewähren. [<=]
TIP1-A_2735 - Testwerkzeug Netzwerk-Sniffer
Der TIZP MUSS sicherstellen, dass er den Netzwerkverkehr auf allen Netzwerkmedien bis zu den Zugangspunkten des Zentralen Netzes der TI durch Netzwerk-Sniffer ohne Paketverluste und rückwirkungsfrei in Referenz- und Testumgebung mitschneiden kann.
Der Mitschnitt MUSS vollständig (komplette Paketgröße und gesamte MTU-Size), mit tatsächlichen Daten (insbesondere Messdaten, wie z. B. Zeitstempel) und in einem auswertbaren Format (pcap) erfolgen. [<=]
TIP1-A_7332 - Bereitstellung Remotezugang zu Netzwerksniffer
Der TIZP MUSS der testdurchführenden Instanz einen sicheren Zugang (z.B. SSH) zum Steuern der Netzwerksniffer bereitstellen.
[<=]
A_13505 - Bereitstellung von Log- und Tracedaten
Der TIZP MUSS Log- und Trace-Daten der jeweiligen testdurchführenden Instanz unmittelbar nach deren Generierung bereitstellen. [<=]
TIP1-A_2751 - Flexibel einstellbarer Sniffing-Detaillierungsgrad
Der TIZP MUSS sicherstellen, dass der Detaillierungsgrad der durch Netzwerk-Sniffer mitgeschnittenen Netzwerkdaten aller am Test beteiligten Produkte in der Referenzumgebung und Testumgebung flexibel (Dauer, Detailierung und Umfang) einstellbar ist. [<=]
TIP1-A_2736 - Testwerkzeug Man-in-the-Middle-Box
Der TIZP MUSS sicherstellen, dass die Referenzumgebung und Testumgebung die Möglichkeit bieten, zeitlich begrenzt den Netzwerkverkehr auf allen Netzwerkmedien durch Man-in-the-Middle-Boxen hindurchzuleiten, um Netzwerkpakete gezielt zu unterdrücken, umzuordnen oder zu modifizieren sowie Replay-Attacken und Penetrationstests durchzuführen. [<=]
TIP1-A_2732-01 - Zentrale Sammelstelle für Logdaten
Der TIZP MUSS sicherstellen, dass für die Referenzumgebung und für die Testumgebung je eine zentrale Speichermöglichkeit bereitgestellt wird für:
TIP1-A_2734 - Separate Netzwerkanbindung für Test
Der TIZP MUSS für die Referenzumgebung und für die Testumgebung separate Netzwerkanschlüsse für Testwerkzeuge bereitstellen. Die gematik wird über diese Anschlüsse eigene Laborumgebungen anbinden.
[<=]
A_15593 - Ersatz bei defekten dezentralen Produkten
Bei Schäden am Gerät, die üblicherweise über Garantie- bzw. Gewährleistungen geregelt werden, MUSS der Hersteller von dezentralen Komponenten diese reparieren oder ersetzen. Ebenso MUSS der Hersteller die regelmäßigen Wartungsarbeiten (wie z.B. Batteriewechsel oder Zertifikatstausch) ermöglichen/unterstützen, so dass die gematik die Testbereitschaft aufrechterhalten kann. [<=]
A_15594 - Vorhalten testbereiter dezentraler Komponenten
Ein Hersteller eines zugelassenen dezentralen Produktes (außer AdV-Server) MUSS der gematik für die Tests im Rahmen der Zulassungsverfahren von jeder zugelassenen Produktversion auf Aufforderung der gematik innerhalb von einer Woche unentgeltlich für einen von der gematik festgelegten Zeitraum zwei Geräte zur Verfügung stellen. Darüber hinaus kann der Hersteller für angeforderte Geräte einen marktüblichen Preis verlangen.
[<=]
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.
TIP1-A_6084-01 - Konfigurationen und Dienste im Servicekatalog
Anbieter des VPN-Zugangsdienstes MÜSSEN für ihr Referenzobjekt in der TU Konfigurationen und Dienste, welche für den Test der gematik genutzt werden, in einem Servicekatalog zu marktüblichen Konditionen anbieten. Der Mindestumfang ist in der Tabelle „Inhalte und Bedingungen des Servicekatalogs“ beschrieben.
Tabelle 5: Inhalte und Bedingungen des Servicekatalogs
Service-Beschreibung |
---|
Remote-Anbindung via Internet im Rahmen des Zulassungstests in der TU im gematik-Zulassungsverfahren. Beinhaltet die Nutzung, Bereitstellung von Registrierungsinformationen und Dokumentation für die Remote-Anbindung an den VPN-Zugangsdienst der TU. |
Testunterstützung „Remote“ im Rahmen des Tests in der TU für die gematik. Allgemeine Test- und Problemlösungsunterstützung, insb. das Bereitstellen von Log und Debug-Informationen im Rahmen des Tests in der TU. Beinhaltet die Nutzung, Bereitstellung von Registrierungsinformationen und Dokumentationen für die Remote-Anbindung an den VPN-Zugangsdienst der TU. |
Testunterstützung der gematik. |
TIP1-A_6079 - Updates von Referenzobjekten
Die Hersteller bzw. Anbieter von Referenzobjekten MÜSSEN Hotfixes, Patches und Updates für die Systemumgebungen einspielen oder zur Verfügung stellen.
[<=]
TIP1-A_6080 - Softwarestand von Referenzobjekten
Die Hersteller bzw. Anbieter von Referenzobjekten SOLLEN dafür sorgen, dass der Software-Stand bzw. Versions- oder Patchstand dem der Komponenten der PU entspricht.
[<=]
TIP1-A_6081 - Bereitstellung der Referenzobjekte
Hersteller und Anbieter von Komponenten der TI-Plattform Zone zentral und der Provider Zone MÜSSEN in RU und TU Referenzobjekte bereitstellen, welche ein funktionales Abbild der PU-Komponente sind.
[<=]
TIP1-A_6093 - Ausprägung der Referenzobjekte
Möchte ein Hersteller oder Anbieter von Komponenten der TI-Plattform Zone zentral und der Provider Zone die Ausprägung seines Referenzobjektes anpassen, so MUSS dies in Abstimmung mit dem Test- und Transition-Manager der gematik geschehen.
[<=]
TIP1-A_6082-01 - Versionen der Referenzobjekte
Sollten mehrere Versionen eines Produkts der TI-Plattform Zone dezentral bzw. der Personal Zone in der PU betrieben werden, so MUSS der Hersteller bzw. Anbieter dafür sorgen, dass alle Versionen als Referenzobjekte in RU und TU zur Verfügung stehen. Von der Anforderung unberührt gelten die Festlegungen in TIP1-A_6526-01.
[<=]
TIP1-A_6088 - Unterstützung bei Fehlernachstellung
Der Zulassungsnehmer eines Produkts MUSS bei der Fehlernachstellung, an denen sein Produkt beteiligt ist, die gematik bzw. einen Dritten unterstützen. [<=]
A_20059 - Festlegung von Konfiguration von Produktinstanzen durch die gematik
Ein Hersteller MUSS für den Zeitraum des Zulassungstests auf Anfrage der gematik die Konfiguration seiner Produktinstanz auf von der gematik festgelegte Werte anpassen. [<=]
A_20060 - Versionierung der Konfiguration von Produktinstanzen
Der Hersteller MUSS für den Zeitraum des Zulassungstests die Konfigurationen seiner Produktinstanz versionieren und rückspielbar ablegen sowie auf Anfrage der TDI TU jederzeit eine detaillierte Auskunft über die verwendete Konfiguration bereitstellen.
[<=]
TIP1-A_2757 - Qualitätssicherungsmaßnahmen der Hersteller und Anbieter
Der TIZP MUSS in der Referenzumgebung die Qualitätssicherungsmaßnahmen der Hersteller und Anbieter zur Erzielung einer Zulassungseignung für die durch die Hersteller und Anbieter umzusetzenden Produkte der TI ermöglichen. [<=]
TIP1-A_4124 - Aufbau RU
Der TIZP MUSS sicherstellen, dass alle erforderlichen Testobjekte, Testwerkzeuge und Kommunikationspfade bereitgestellt und verfügbar gehalten werden. [<=]
TIP1-A_2758 - Ermöglichen von Tests im Rahmen einer (Teil-)Integration (RU)
Der TIZP MUSS in der Referenzumgebung Tests im Rahmen einer (Teil-)Integration ermöglichen. [<=]
TIP1-A_2760 - Performance
Die TBI KANN die Performance (Durchsatz, Bearbeitungszeit) seiner Dienste in der Referenzumgebung in Abstimmung mit der testkoordinierenden Instanz auch abweichend von der Performance der Produktivumgebung vorgeben. [<=]
TIP1-A_5052 - Dauerhafte Verfügbarkeit in der RU
Hersteller und Anbieter von Produkten der TI MÜSSEN mindestens eine konkrete Ausprägung von jedem Produkttyp dauerhaft in der Referenzumgebung zur Verfügung stellen. [<=]
TIP1-A_2766 - Zugang zur Referenzumgebung durch gematik
Der TIZP MUSS der gematik Zugang zur Referenzumgebung gewähren, um ihre Testwerkzeuge einzubringen und diese für den Einsatz in der Testumgebung weiter entwickeln zu können. [<=]
TIP1-A_2767 - Splittung der Referenzumgebung
Der TIZP KANN die Referenzumgebung auf der Ebene von Instanzen von Produkten der TI oder durch Virtualisierung in eine oder mehrere Referenzumgebungen splitten. [<=]
TIP1-A_2768 - Zweck von Instanzen der Referenzumgebung
Der TIZP SOLL in der Referenzumgebung durch Bereitstellung von Instanzen von Komponenten der TI die ungestörte, selbständige und unabhängige Testdurchführung für die Entwicklung und Herstellung von TI-Produkten durch die Hersteller und Anbieter ermöglichen. [<=]
TIP1-A_6538 - Durchführung von Produkttests
Der TIZP MUSS in der Referenzumgebung die Durchführung von Produkttests ermöglichen. [<=]
TIP1-A_6539 - Durchführung von Produktübergreifenden Tests
Der TIZP MUSS in der Referenzumgebung die Durchführung von Produktübergreifenden Tests ermöglichen. [<=]
TIP1-A_2773 - Simulatoren als Ersatz für Dienste
Die TDI KANN zentrale Dienste und fachanwendungsspezifische Dienste für EvT in den Produkttests durch Simulatoren ersetzen. [<=]
TIP1-A_2775 - Performance in RU
Die testdurchführende Instanz der Referenzumgebung SOLL in der Referenzumgebung das Leistungsverhalten der zuzulassenden Komponente simulieren und die Einhaltung der Leistungsanforderungen prüfen. [<=]
A_26241 - Erstellung Performancetestbericht
Die testdurchführende Instanz RU MUSS für die Performance-Vorgaben aus gemSpec_Perf einen separaten Performance-Testbericht anfertigen und bereitstellen. Die Ergebnisse sind auf Anfrage der gematik von der testdurchführenden Instanz RU in einem Workshop zu präsentieren. [<=]
TIP1-A_6085 - Referenzobjekte eines Produkts
Nach Zulassung eines Produkts der TI-Plattform Zone zentral sowie des Intermediärs VSDM und der Fachdienste ePA MUSS der Hersteller oder Anbieter dieses als Referenzobjekt in der TU bereitstellen. Die Bereitstellung bezieht sich auf den Zeitraum, in dem das Produkt in der TI (PU) eingesetzt wird. [<=]
TIP1-A_6086 - Unterstützung bei Anbindung eines Produktes
Der Zulassungsnehmer MUSS nach erfolgter Zulassung die Anbindung der Referenzobjekte produktseitig unterstützen. Dies entfällt, wenn das bereits vorhandene Testobjekt zum Referenzobjekt wird. [<=]
TIP1-A_2783 - Marktübliche Testwerkzeuge
Der TIZP MUSS marktübliche Testwerkzeuge und Testtreiber dauerhaft in der Testumgebung zur Verfügung stellen. Hierzu gehört z. B. Wireshark. [<=]
TIP1-A_2785 - Simulatoren für Fehleranalyse
Der TIZP MUSS in der Testumgebung sicherstellen, dass Simulatoren, die er für eigene Tests genutzt hat, erhalten bleiben.
[<=]
TIP1-A_6087 - Zugang zur Adminschnittstelle bei dezentralen Produkten
Der Hersteller von dezentralen Produkten MUSS der gematik Zugang zur administrativen Schnittstelle für Referenzobjekte bereitstellen. Der Hersteller MUSS ein Benutzerhandbuch für diese Produkte bereitstellen. [<=]
TIP1-A_3363 - Nutzung von Produkt-Schnittstellen in der TU
Die TBI MUSS der testdurchführenden Instanz ermöglichen, alle Außenschnittstellen eines in die Testumgebung integrierten Produkts zu nutzen. [<=]
TIP1-A_3364 - Produktspezifische Parameter in der TU
Der TIZP MUSS vor Testbeginn produktspezifische Anbindungsparameter für die Integration des jeweiligen Produkts in die Testumgebung definieren. [<=]
TIP1-A_3365 - Publikation Produktspezifische Parameter in der TU
Der TIZP MUSS vor Testbeginn die definierten produktspezifischen Parameter für die Integration des jeweiligen Produkts in die Testumgebung den Herstellern und Anbietern übermitteln. [<=]
TIP1-A_2790 - Leistungstest
Die TBI MUSS sicherstellen, dass im Rahmen von Leistungstests temporär die Testumgebung stufenweise skaliert werden kann, um das Verhalten des Systems bei Laststeigerungen und Systemausbau zu überprüfen. [<=]
TIP1-A_4192 - Dimensionierung TU für PU-Fehlernachstellung
Die TBI MUSS sicherstellen, dass die Testumgebung ausreichend dimensioniert ist, um eine Fehlernachstellung für die Produktivumgebung zu ermöglichen. [<=]
TIP1-A_2792 - Splitten der Testumgebung
Der TIZP KANN in Abstimmung mit der TDI der gematik die Testumgebung splitten, wenn:
TIP1-A_2795 - Parallele Tests
Die TBI MUSS, auf Anfrage der TDI der gematik, zwecks paralleler Durchführung von Tests bei unterschiedlichen Versionsständen die Testumgebung in mehreren Instanzen ausprägen, sofern die Produkte die Ausprägung mehrerer Instanzen in unterschiedlichen Versionen unterstützen. [<=]
TIP1-A_2797 - Örtliche Verteilung von Testobjekten und Testtreibern
Der TIZP MUSS die Möglichkeit der Verteilung von Testobjekten und Testtreibern über Standortgrenzen hinweg schaffen. [<=]
TIP1-A_2800 - Nachweis der Anforderungserfüllung
Der TIZP MUSS, auf Anfrage der TDI der gematik, die Testumgebung so gestalten, dass in einer verteilten und produktivnahen Umgebung der Nachweis der Erfüllung von funktionalen und nicht-funktionalen sowie der Sicherheitsanforderungen an einzelne Produkte erbracht werden kann. [<=]
TIP1-A_2802 - Integration und produktübergreifende Tests
Der TIZP MUSS die Integration von Produkten und produktübergreifende Tests in mehreren Ausbaustufen, angefangen von der Integration der TI-Plattform bis zur vollständigen Abbildung der Funktionalität der Produktivumgebung, ermöglichen. [<=]
TIP1-A_2805 - Zeitnahe Anpassung von Produktkonfigurationen
Der Hersteller oder Anbieter von Produkten MUSS sicherstellen, dass in der Testumgebung die Produkte (außer Smartcards) sich in ihren Konfigurationen zeitnah (möglichst kleiner 1 Arbeitstag) anpassen lassen. [<=]
TIP1-A_2806 - Zeitnahe Anpassung der Konfiguration der Testumgebung
Die TBI MUSS sicherstellen, dass die Testumgebung sich in ihren Konfigurationen zeitnah anpassen lässt. [<=]
TIP1-A_2807 - Zentrale Steuerung paralleler Tests
Der TIZP MUSS in Zusammenarbeit mit der testdurchführenden Instanz TDI in der Testumgebung parallele Testaktivitäten ermöglichen. [<=]
TIP1-A_2808 - Produkttests
Der TIZP MUSS in der Testumgebung die Unterstützung von Produkttests ermöglichen. [<=]
TIP1-A_2810 - Produktübergreifende Tests
Der TIZP MUSS in der Testumgebung die Unterstützung von produktübergreifenden Tests (schrittweise Integration aller Produkte) ermöglichen. [<=]
TIP1-A_2803-01 - Nachstellen von PU-Fehlern in der TU
Die Testbetriebsinstanz (TBI) der Testumgebung MUSS das Nachstellen von Fehlern, die in der Produktivumgebung auftreten, in der Testumgebung ermöglichen. [<=]
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.
Tabelle 6: Tab_Test_021 Szenario: Zulassung eines neuen Produkts
Szenario |
Zulassung eines neuen Produkts |
---|---|
Beschreibung |
Ein Hersteller oder Anbieter möchte ein Produkt erstmalig zulassen. |
Testziele |
|
Testobjekt(e) |
Das zuzulassende Produkt |
Testbasis |
|
Besetzung der Rollen |
|
Systemumgebung |
|
Testphasen und Teststufen |
|
Zusätzliche Eingangskriterien EvT |
keine |
Zusätzliche Ausgangskriterien EvT |
|
Zusätzliche Eingangskriterien ZulT |
keine |
Zusätzliche Ausgangskriterien ZulT |
keine |
TIP1-A_6532 - Zulassung eines neuen Produkts: Aufgaben der TDI
Die jeweilige TDI MUSS für die Zulassung eines neuen Produkts ihre Testvorgehensweise gemäß Tabelle Tab_Test_021 Szenario: Zulassung eines neuen Produkts umsetzen. [<=]
TIP1-A_6533 - Zulassung eines neuen Produkts: Aufgaben der Hersteller und Anbieter
Die Hersteller und Anbieter von Produkten MÜSSEN für die Zulassung eines neuen Produkts ihre Testvorgehensweise gemäß Tabelle Tab_Test_021 Szenario: Zulassung eines neuen Produkts umsetzen. [<=]
Tabelle 7: Tab_Test_022 Szenario: Zulassung eines geänderten Produkts
Szenario |
Zulassung eines geänderten Produkts |
---|---|
Beschreibung |
Ein Hersteller oder Anbieter möchte ein Produkt ändern und erneut zulassen. |
Testziele |
|
Testobjekt(e) |
Das zuzulassende Produkt |
Testbasis |
|
Besetzung der Rollen |
|
Systemumgebung |
|
Testphasen und Teststufen |
|
Zusätzliche Eingangskriterien EvT |
keine |
Zusätzliche Ausgangskriterien EvT |
|
Zusätzliche Eingangskriterien ZulT |
keine |
Zusätzliche Ausgangskriterien ZulT |
keine |
TIP1-A_6536 - Zulassung eines geänderten Produkts: Aufgaben der TDI
Die jeweilige TDI MUSS für die Zulassung eines geänderten Produkts ihre Testvorgehensweise gemäß Tabelle Tab_Test_022 Szenario: Zulassung eines geänderten Produkts umsetzen. [<=]
TIP1-A_6537 - Zulassung eines geänderten Produkts: Aufgaben der Hersteller und Anbieter
Die Hersteller und Anbieter von Produkten MÜSSEN für die Zulassung eines geänderten Produkts ihre Testvorgehensweise gemäß Tabelle Tab_Test_022 Szenario: Zulassung eines geänderten Produkts umsetzen. [<=]
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.
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).
Tabelle 8: Tab_Test_008 Produkttest (EvT)
Teststufe |
Produkttest (EvT) |
---|---|
Beschreibung |
Im Rahmen des Produkttests (EvT) werden Produkte einzeln getestet. |
Ziel |
Nachweis der Erfüllung der funktionalen und nicht-funktionalen Anforderungen. |
Testarten |
Funktionstest Leistungstest |
Tabelle 9: Tab_Test_009 Produktübergreifender Test (EvT)
Teststufe |
Produktübergreifender Test (EvT) |
---|---|
Beschreibung |
Im Rahmen des Produktübergreifenden Tests (EvT) werden Produkte im Zusammenspiel getestet. |
Ziel |
Nachweis, dass Implementierungen von Produkten verschiedenen Typs zueinander interoperabel sind. Nachweis der Erfüllung der Anwendungsfälle. |
Testarten |
Interoperabilitätstest |
Tabelle 10: Tab_Test_010 Eingangsprüfung (ZulT)
Teststufe |
Eingangsprüfung (ZulT) |
---|---|
Beschreibung |
Die Eingangsprüfung prüft exemplarisch, ob das Testobjekt zur Entlastung der Zulassungstests geeignet ist. Erkennbar ungeeignete Produkte werden zurück an die Hersteller bzw. Anbieter verwiesen. |
Ziel |
Nachweis (durch exemplarische Prüfung), dass das Testobjekt geeignet ist, die Zulassungstests erfolgreich zu durchlaufen. |
Testarten |
Güteprüfung Funktionstest |
Tabelle 11: Tab_Test_011 Produkttest (ZulT)
Teststufe |
Produkttest (ZulT) |
---|---|
Beschreibung |
Der Produkttest prüft auf der Grundlage von Vorgaben durch die testkoordinierende Instanz, ob das Produkt, als konkrete Ausprägung eines Produkttyps, die geforderten Funktionen und Schnittstellen spezifikationskonform realisiert hat. Im Gegensatz zum EvT, werden die interne Struktur und das interne Verhalten eines Produkts nicht berücksichtigt. Es wird lediglich das Verhalten der Produkte an ihren Außenschnittstellen geprüft. Der Produkttest der gematik wird nicht bei jedem Produkttyp durchgeführt. |
Ziel |
Nachweis der Erfüllung aller an das Produkt gestellten Anforderungen der Prüfart Produkttest gemäß Produkttypsteckbrief. Nachweis, dass die an die Produkte gestellten Anforderungen hinsichtlich [ISO25000 oder vergleichbarer Norm] Funktion, Interoperabilität, Benutzbarkeit und Sicherheit. |
Testarten |
Funktionstest |
Tabelle 12: Tab_Test_012 Produktübergreifender Test (ZulT)
Teststufe |
Produktübergreifender Test (ZulT) |
---|---|
Beschreibung |
Ergänzend zum Produkttest, der sich jeweils auf ein einzelnes Produkt bezieht, müssen Produkte auch integriert getestet werden. |
Ziel |
Nachweis, (durch Integrationstests der einzelnen Produkte) des Zusammenwirkens von Produkten und Fachanwendungen. Nachweis dass die Ende-zu-Ende-Funktionalitäten der Produkte und Fachanwendungen erfüllt werden und die fachlichen Abläufe der Anwendung in die Geschäftsprozesse der Endanwender integriert werden können. |
Testarten |
Interoperabilitätstest |
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.
TIP1-A_7333 - Parallelbetrieb von Release oder Produkttypversion
In der Übergangsphase von Dokumentenreleases in welcher mehrere Produkttypversionen parallel Gültigkeit haben SOLL die testdurchführende Instanz die Interoperabilitätstests immer gegen die aktuell höchste verfügbare Produktversionsnummer des bzw. der jeweiligen Hersteller durchführen (je nach Anzahl in Tabelle 13: Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung). Für alle weiteren, zum Zeitpunkt der Inbetriebnahme in der PU vorhandenen, Produktversionsnummern SOLLEN, in Abstimmung mit dem Test- und Transitionmanager der gematik, angemessene Regressionstests im Rahmen der Interoperabilitätstests durchgeführt werden.
Eventuell zu beachtende Integrations- bzw. Testreihenfolgen gehen aus der von der gematik veröffentlichten Migrationsstrategie des jeweiligen Releases hervor.
[<=]
TIP1-A_7334 - Risikoabschätzung bezüglich der Interoperabilität
Die testdurchführende Instanz MUSS eine Risikoabschätzung für eventuelle Interoperabilitätsprobleme mit Komponenten, welche in einer neuen Produkttypversion noch nicht oder gemäß Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung nicht in ausreichender Anzahl verfügbar sind, auf Grundlage der Migrationsstrategie durchführen und der gematik vorlegen.
[<=]
TIP1-A_6772 - Partnerprodukte bei Interoperabilitätstests
Der Zulassungsnehmer MUSS die Interoperabilitätstests gegen Referenzobjekte durchführen. Sind Referenzobjekte nicht verfügbar, ist in Abstimmung mit der gematik die Nutzung von geeigneten Testobjekten möglich. [<=]
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.
TIP1-A_6529 - Produkttypen: Mindestumfang der Interoperabilitätsprüfung
Die testdurchführende Instanz der RU (TDI RU) MUSS zum Nachweis der Interoperabilität alle für das jeweilige Produkt relevanten anwendungsfallbasierten Tests mit der Mindestanzahl von Produkten gemäß Tabelle 13: Tab_Test_033 Mindestumfang der Interoperabilitätsprüfung durchführen. [<=]
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
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.
TIP1-A_7335 - Bereitstellung der Testdokumentation
Der Zulassungsnehmer MUSS die geforderte Testdokumentation auf geeignete Weise in Abstimmung mit dem Test- & Transitionmanager der gematik zur Verfügung stellen.
[<=]
TIP1-A_6524-01 - Testdokumentation gemäß Vorlagen
Der Zulassungsnehmer MUSS sich bei der Erstellung der Testdokumentation an die Tabellen Tab_Test_013 Testkonzept, Tab_Test_014 Testspezifikation, Tab_Test_015 Release Notes, Tab_Test_016 Produktdokumentation, Tab_Test_017 Testprotokoll und Tab_Test_018 Testbericht halten. [<=]
A_20065 - Nutzung der Dokumententemplates der gematik
Die Testdokumentation SOLL gemäß der Templates, die im Rahmen des Zulassungsverfahrens von der gematik zur Verfügung gestellt werden, erstellt werden. Abweichungen sind mit dem jeweiligen Testmanager der gematik abzustimmen.
[<=]
Hersteller können die Templates der Testdokumentation aus dem letzten Zulassungsverfahren weiterverwenden.
A_25392 - Nutzung Testfallmatrix-Template der gematik
Der Hersteller MUSS das gematik "Afo_Testmatrix" Template als Teil der Dokumentation der ausgeführten / nicht ausgeführten Testfälle nutzen und der gematik zur Verfügung stellen. [<=]
Tabelle 14: Tab_Test_013 Testkonzept
Testdokument |
Testkonzept |
---|---|
Beschreibung |
Das Testkonzept beschreibt die Vorgehensweise hinsichtlich der Testaktivitäten für einen Produkttyp sowie das konkrete Vorgehen entsprechend der jeweiligen Integrationsstufe bezogen auf die TI. Es operationalisiert die Vorgaben aus diesem Testkonzept. Testvorgehen und Dokumente halten sich an Standards des ISTQB. Die testdurchführende Instanz erstellt pro Testphase je ein Testkonzept pro Produkttyp, wobei die Testkonzepte einheitlich strukturiert sein sollen und alle relevanten Informationen konsolidieren (z. B. von Subunternehmen). Das Testkonzept soll auf der Inhaltsstruktur des „Master Test Plan“ bzw. „Level Test Plan“ nach ISO/IEC/IEEE 29119 basieren. Das Testkonzept muss für sämtliche Produkttypen einheitlich gestaltet werden. Das Dokument wird entsprechend der Erfordernisse im Projekt fortgeschrieben. Das Testkonzept muss darstellen, wie die Testfälle den Nachweis über die Anforderungen oder Anwendungsfälle führen bzw. welche Anforderungen oder Anwendungsfälle mit welchen Testfällen in einem Testbericht nachgewiesen werden. Für das Testkonzept stellt die gematik eine Vorlage zur Verfügung. |
Geforderte Inhalte |
|
Lieferzeitpunkt |
Vor Beginn der Eigenverantwortlichen Tests bzw. Zulassungstests (Eingangskriterium der jeweiligen Testphasen) |
Einreichungsbedarf bei Zulassungen | Das Testkonzept ist bei Erstzulassungen immer einzureichen. Das Testkonzept muss bei Folgezulassungen nur angepasst werden, wenn es wesentliche Änderungen im Testvorgehen gibt. |
Verantwortlich |
Testdurchführende Instanz der RU |
Vorlage |
Können beim Test- & Transitionmanager der gematik erfragt werden. |
Tabelle 15: Tab_Test_014 Testspezifikation
Testdokument |
Testspezifikation |
---|---|
Beschreibung |
Die Testspezifikation dokumentiert auf logischer Ebene die Ergebnisse des Testentwurfs sowie auf konkreter Ebene die einzelnen Testfälle und deren Konfigurationen sowie den geplanten Ablauf der Testdurchführung. Die Testspezifikation soll auf der Inhaltsstruktur des „Level Test Design“, „Level Test Case“ sowie „Level Test Procedure“ der ISO/IEC/IEEE 29119 basieren und umfasst die folgenden Teildokumente:
Bei der Verwendung von Testskripten im Rahmen einer Testautomatisierung müssen die Skripte selbst entsprechend getestet werden. |
Geforderte Inhalte |
Testentwurfsspezifikation:
|
Lieferzeitpunkt |
Vor Beginn der Eigenverantwortlichen Tests bzw. Zulassungstests (Eingangskriterium der jeweiligen Testphasen) |
Einreichungsbedarf bei Zulassungen |
Die Testspezifikation ist bei Erstzulassungen immer einzureichen. Die Testspezifikation muss bei Folgezulassungen erweitert werden, wenn zusätzliche Testfälle hinzugekommen bzw. vorhandene Testfälle geändert worden sind. |
Verantwortlich |
Testdurchführende Instanz der RU |
Vorlage |
Können beim Test- & Transitionmanager der gematik erfragt werden. |
Tabelle 16: Tab_Test_015 Release Notes
Testdokument |
Release Notes |
---|---|
Beschreibung |
Release Notes dokumentieren beim Release eines Produkts die Änderungen des Produkts gegenüber dem vorherigen Release. |
Geforderte Inhalte |
|
Lieferzeitpunkt |
Vor Beginn Zulassungstests (Eingangskriterium) sowie bei Einreichung aktualisierter Produkte in einem Zulassungsverfahren. |
Einreichungsbedarf bei Zulassungen |
Die Release Notes sind sowohl bei Erstzulassungen als auch bei Folgezulassungen immer beizubringen. |
Verantwortlich |
Hersteller und Anbieter |
Tabelle 17: Tab_Test_016 Produktdokumentation
Testdokument |
Produktdokumentation |
---|---|
Beschreibung |
Das Dokument wird entsprechend der Erfordernisse durch den Hersteller oder Anbieter fortgeschrieben. |
Geforderte Inhalte |
|
Lieferzeitpunkt |
Vor Beginn Zulassungstests (Eingangskriterium) |
Einreichungsbedarf bei Zulassungen |
Die Produktdokumentation ist bei Erstzulassungen immer einzureichen. Die Produktdokumentation muss bei Folgezulassungen nur eingereicht werden, wenn wesentliche Änderungen in der Produktdokumentation erforderlich sind. |
Verantwortlich |
Hersteller und Anbieter |
Tabelle 18: Tab_Test_017 Testprotokoll
Testdokument |
Testprotokoll |
---|---|
Beschreibung |
Das Testprotokoll muss die detaillierten Ergebnisse der Testdurchführung je Produktversion enthalten. Das Testprotokoll soll auf der Inhaltsstruktur des „Level Test Log“ bzw. „Anomaly Report“ nach ISO/IEC/IEEE 29119 basieren. Das Dokument wird entsprechend der Erfordernisse im Projekt durch den Hersteller oder Anbieter fortgeschrieben. |
Geforderte Inhalte |
|
Lieferzeitpunkt |
Mit Abschluss der Eigenverantwortlichen Tests bzw. Zulassungstests (Aus- bzw. Eingangskriterium der jeweiligen Testphasen) |
Einreichungsbedarf bei Zulassungen |
Das Testprotokoll ist sowohl bei Erstzulassungen als auch bei Folgezulassungen immer beizubringen. |
Verantwortlich |
Testdurchführende Instanz der RU |
Vorlage |
Können beim Test- & Transitionmanager der gematik erfragt werden. |
Tabelle 19: Tab_Test_018 Testbericht
Testdokument |
Testbericht |
---|---|
Beschreibung |
Der Testbericht muss je Produktversion mindestens die Angaben entsprechend den Vorgaben des Testkonzepts enthalten und der abgestimmten Vorlage entsprechen. Darüber hinaus muss der Testbericht einen zusammenfassenden Problemreport und eine abschließende Risikobetrachtung und Einschätzung der testdurchführenden Instanz enthalten. Testberichte werden zum Abschluss einer Teststufe von der testdurchführenden Instanz verfasst und dienen dazu, den Testumfang und das Ergebnis nachvollziehbar zu dokumentieren. In den Testphasen sind die Testberichte das wesentliche Mittel, um vor dem Start einer Teststufe den Reifegrad des Testobjekts oder einer Anwendung einzuschätzen und ggf. die Testvoraussetzungen als nicht erfüllt zu beurteilen. Damit ein Testbericht diesen Zweck erfüllt, müssen das Testobjekt, der Testaufbau, die durch Tests abgedeckten Anforderungen, gefundene und behobene sowie nicht behobene Fehler beschrieben sein. Das Testbericht soll auf der Inhaltsstruktur des „Level Test Report“ bzw. „Master Test Report“ nach ISO/IEC/IEEE 29119 basieren. Für den Testbericht stellt die gematik eine Vorlage zur Verfügung. Anhand des Testberichts kann die gematik in der Eingangsprüfung die Aufnahme einer Teststufe oder die Zulassung eines Produkts begründet ablehnen. Mögliche Gründe für die Ablehnung eines Testberichtes sind: Die Anforderungen sind unzureichend abgedeckt, so dass wichtige Funktionen des Produkttyps nicht qualitätsgesichert sind und anzunehmen ist, dass folgende Teststufen nicht erfolgreich absolviert werden können. Die nicht behobenen Fehler sind so schwerwiegend, dass die Teststufen der Zulassungstestphase nicht in der vorgesehen Zeit durchlaufen werden können. Der Testaufbau und die eingesetzten Testmittel sind offensichtlich ungeeignet, um die abzudeckenden Anforderungen zu prüfen. |
Geforderte Inhalte |
Testobjekt: Die Beschreibung des Testobjekts umfasst in tabellarischer Form den Produkttyp, die Herstellerversion des Produkts und die Version der gematik-Spezifikation. Zudem soll das Produkt in kurzer Form z. B. als Komponentendiagramm mit Erläuterungen, beschrieben werden. Testaufbau: Die Dokumentation des Testaufbaus umfasst die Beschreibung der Testinfrastruktur, Testtreiber, Platzhalter und Simulatoren, die zur Durchführung der Tests eingesetzt werden. Testumfang: Der Testbericht enthält folgende Angaben in tabellarischer Form:
Risiken: Dokumentation von nicht erfüllten Eingangs- oder Ausgangskriterien sowie eine Bewertung der damit verbundenen Risiken. |
Lieferzeitpunkt |
Mit Abschluss der Eigenverantwortlichen Tests bzw. Zulassungstests (Aus- bzw. Eingangskriterium der jeweiligen Testphasen) |
Einreichungsbedarf bei Zulassungen |
Der Testbericht ist sowohl bei Erstzulassungen als auch bei Folgezulassungen immer beizubringen. |
Verantwortlich |
Testdurchführende Instanz der RU |
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.
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).
Für verschiedene Testmaßnahmen werden unterschiedliche Ausprägungen von Testkarten eingesetzt.
Neben den Ausprägungen weisen Testkarten auch verschiedene Personalisierungen auf, die auch mit spezifischen COS-Ausprägungen einhergehen.
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.
VSDM-A_2812-01 - Bereitstellung Testkartensätze
Betreiber und Anbieter von Fachdiensten VSDM MÜSSEN eGK-Testkarten FD für die gematik gemäß [gemSpec_TK_FD] für RU und TU von den Krankenkassen bereitstellen, deren produktive eGK sie mit VSD-, CMS - Updates versorgen. [<=]
VSDM-A_3029 - Bereitstellung von Testkarten
Betreiber der Fachdienste VSDM MÜSSEN spezifikationskonform physische und virtuelle Testkarten eGK und täglich wechselnde Updates bereitstellen, wie im Kapitel Flip/Flop Verfahren formuliert.
[<=]
VSDM-A_3030 - Bereitstellung von spezifikationsabweichende Testkarten
Bewusst spezifikationsabweichende Testkarten eGK KÖNNEN (physisch oder virtuell) von den Betreibern der Fachdiensten VSDM bereitgestellt werden. [<=]
VSDM-A_2815-01 - Berücksichtigung von Vorgaben zur Schlüsselerzeugung
Betreiber und Anbieter der Fachdienste VSDM MÜSSEN bei der Generierung symmetrischer Schlüssel für die Testkarten FD, die in [gemSpec_TK_FD#Vorgaben zu symmetrischen Schlüsseln] definierten Vorgaben berücksichtigen. [<=]
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.
VSDM-A_2825-01 - Bereitstellen von VSD-Updates
Betreiber der Fachdienste VSDM MÜSSEN für die bereitgestellten Testkarten FD täglich ein VSD-Update gemäß [gemSpec_TK_FD#Testdatenmanagement und Erkennbarkeit des Testdatentyps] zu Testzwecken bereitstellen. [<=]
VSDM-A_2826-01 - Bereitstellen datumsbasierter VSD-Updates
Betreiber der Fachdienste VSDM MÜSSEN für die Testkarten FD mit zugeordnetem VSD-Update zu Testzwecken für gerade und ungerade Tage zwei unterschiedliche VSD-Updates bereitstellen. [<=]
VSDM-A_2827-01 - Bereitstellen von CMS-Updates
Betreiber der Fachdienste VSDM MÜSSEN für die bereitgestellten Testkarten FD täglich ein CMS-Update gemäß [gemSpec_TK_FD#Testdatenmanagement und Erkennbarkeit des Testdatentyps] zu Testzwecken bereitstellen. [<=]
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.
VSDM-A_2830 - Integration multipler Anbieter
Der Fachdienstbetreiber des mandantenfähigen Fachdienstes MUSS mindestens zwei Anbieter integrieren. [<=]
VSDM-A_2832 - Umsetzung des Flip/Flop-Verfahrens
Der Fachdienstbetreiber des mandantenfähigen Fachdienstes MUSS sicherstellen, dass das Flip/Flop-Verfahren für Testmaßnahmen für alle Mandanten aktiviert wird. [<=]
A_18807 - Durchführung von gematik-Testfällen (EvT) beim Fachdienst VSDM
Hersteller von Fachdiensten VSDM MÜSSEN im Rahmen ihrer eigenverantwortlichen Tests, die von der gematik zur Verfügung gestellten Testfälle durchführen. [<=]
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.
A_18892 - Durchführung von gematik-KIM-Testfällen (EvT)
Hersteller von KIM-Clientmodulen und integrierten KIM-Clientmodulen MÜSSEN im Rahmen ihrer eigenverantwortlichen Tests die von der gematik zur Ausführung bereitgestellten Testfälle durchführen. [<=]
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.
A_25831 - Erstellung von KIM-Testaccounts
Die KIM-Fachdienst-Anbieter und KIM-Clientmodul-Hersteller MÜSSEN die Registrierung und Verfügbarkeit der KIM-Test-Accounts in der RU und TU sicherstellen. [<=]
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.
TIP1-A_7338-01 - Anzahl der KTR-AdV als Referenzobjekte
Hersteller einer KTR-AdV SOLLEN mindestens ein KTR-AdV Produkt in der TU permanent als Referenzobjekt zur Verfügung stellen. Eine Abstimmung und die Koordination finden über den Test & Transitionmanager der gematik statt. Ausnahmen für die Verfügbarkeit von weniger als einem KTR-AdV als Referenzobjekt SOLLEN mit dem Test & Transitionmanager der gematik abgestimmt werden. [<=]
TIP1-A_7339-01 - Bereitstellung Testkartensätze für KTR-AdV
Hersteller der KTR-AdV MÜSSEN der gematik personalisierte Testkartensätze eGK nach [gemSpec_TK_FD] bereitstellen. [<=]
Es können die für die Fachdienste VSDM bereitgestellten Testkartensätze genutzt werden.
TIP1-A_7340-01 - Bereitstellung von Testkarten KTR-AdV
Hersteller der KTR-AdV MÜSSEN spezifikationskonform physische und virtuelle Testkarten eGK nach [gemSpec_TK_FD] bereitstellen. [<=]
TIP1-A_7342-01 - Eindeutigkeit der Testkarte pro Testkartenkategorie
Hersteller der KTR-AdV SOLLEN sicherstellen, dass eGK Testkarten für KTR-AdV so personalisiert sind, dass jeweils eine definierte Testkategorie berücksichtigt wird. [<=]
Die Afo wird benötigt, um beim Test des VSDM-Anwendungsfalls mit virtuellen Karten zu arbeiten.
TIP1-A_7343-01 - Berücksichtigung von Vorgaben zur Schlüsselerzeugung eGK Testkarten für KTR-AdV
Hersteller der KTR-AdV SOLLEN sicherstellen, dass bei der Generierung symmetrischer Schlüssel für die eGK Testkarten, die definierten Vorgaben nach [gemSpec_TK_FD] der testdurchführenden Instanz der TU berücksichtigt werden. [<=]
TIP1-A_7344-01 - Integration multipler Anbieter für KTR-AdV
Hersteller eines mandantenfähigen Produktes KTR-AdV MÜSSEN mindestens 2 Krankenkassen integrieren. [<=]
TIP1-A_7345-01 - Bereitstellung SM-B für KTR-AdV
Hersteller einer mandantenfähigen KTR-AdV MÜSSEN sicherstellen, dass während des produktübergreifenden Tests für jeden Mandanten eine SM-B verwaltet wird. [<=]
Für die Testbarkeit der Fachanwendung ePA ist es notwendig, dass die Hersteller die folgenden Anforderungen erfüllen.
A_17809-02 - Bereitstellung weiterer ePA-Produkttypen für Zulassungstest
Der Hersteller eines der im Folgenden genannten Produkttypen MUSS die in seinen produktübergreifenden EvT genutzten ePA-Produkte der TDI der TU für den Zulassungstest zur Verfügung stellen. Hierzu gehören das ePA-Aktensystem, das ePA-Frontend des Versicherten, der sektorale IDP sowie der Signaturdienst. [<=]
A_15643 - Legitimierung von Testidentitäten
Der Hersteller eines ePA-Aktensystems MUSS die von der TDI der TU vorgegebenen Testidentitäten für die Eröffnung und Verwaltung eines Kontos legitimieren. [<=]
Hinweis: Dazu zählen auch von der gematik erstellte Testkarten.
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].
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:
A_24726 - Bereitstellung FdV der Krankenversicherungen als Remote-Test-FdV zum Zulassungstest
Der Hersteller eines Frontend des Versicherten der Krankenversicherungen, das ein oder mehrere TI-Module einbindet, MUSS entsprechend Zulassungsantrag für jedes Betriebssystem vorinstallierte Testobjekte mittels Testtreiberschnittstellen bereitstellen. Die Testtreiberschnittstellen werden von der gematik pro TI-Modul definiert und MÜSSEN vom Hersteller entsprechend umgesetzt werden. Die Bereitstellung bzw. Übergabe erfolgt in Absprache mit der gematik.
Der Hersteller eines FdV der Krankenversicherungen MUSS das vollständige Vorhandensein benötigter Lizenzen für die bereitgestellten Remote-Test-FdVs sicherstellen. [<=]
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].
A_24747 - Bereitstellung weiterer Versionen von Remote-Test-FdVs
Der Hersteller von FdVs der Krankenversicherungen MUSS in Abstimmung mit der gematik Remote-Test-FdVs bereitstellen, mit denen bereits zugelassene oder noch nicht zugelassene Versionen von TI-Modulen in FdVs getestet werden können. [<=]
A_24727 - Zugriff auf Remote-Test-FdV über das Internet
Der Hersteller eines FdV der Krankenversicherungen MUSS die Testtreiberschnittstellen der Testtreiber-Module über das Internet zugänglich machen und einen Fernzugriff ermöglichen (Remote-Test-FdV). Hierfür MUSS der Hersteller die Testtreiberschnittstellen der Testtreiber-Module absichern, damit nur berechtigte Test-Clients Zugriff auf diese Schnittstellen erhalten. [<=]
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.
A_24728 - Bereitstellung zusätzlicher Instanzen von Remote-Test-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS bei Bedarfsmeldung der gematik weitere Instanzen von Remote-Test-FdVs innerhalb von 20 Arbeitstagen bereitstellen. [<=]
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
A_24729 - Dauerhafte Bereitstellung von Remote-Test-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS die angeforderten Instanzen der Remote-Test-FdVs dauerhaft in der jeweiligen Umgebung bereitstellen, um der TDI jederzeit eine Ausführung von Tests zu ermöglichen. [<=]
A_24730 - Bereitstellungsform der Remote-Test-FdVs
Der Hersteller eines FdVs der Krankenversicherungen MUSS die Instanzen von Remote-Test-FdVs entweder auf virtualisierten oder auf physischen Geräten mit den Betriebssystemen (entsprechend Zulassungsantrag) bereitstellen. [<=]
A_24731 - Integration des Testtreibers für das Remote-Test-FdV in die Testumgebung
Der Hersteller eines FdV der Krankenversicherungen MUSS den Testtreiber für Remote-Test-FdVs entweder über eine Integration direkt im FdV oder extern über eine automatisierte GUI-Ansteuerung des FdVs bereitstellen. [<=]
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
A_24732 - Zuordnung einer Identität eines Test-Versicherten zu einem Remote-Test-FdV
Der Hersteller eines FdV der Krankenversicherungen MUSS für die Instanzen der Remote-Test-FdVs die Identität eines Test-Versicherten mit der gematik abstimmen und diese den Instanzen der FdVs zuordnen und konfigurieren. Der Hersteller MUSS die Zuordnung von Instanz zur KVNR eines Testversicherten der gematik mitteilen. [<=]
A_24733 - Automatisiertes Login an den TI-Modulen des Remote-Test-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS für die TI-Module des Remote-Test-FdVs ein automatisiertes Login des Test-Versicherten sicherstellen. Dies MUSS im Rahmen der Login-Funktion einer Testtreiberschnittstelle erfolgen, sofern die jeweilige Schnittstelle eine Login-Funktion definiert. [<=]
A_24734 - Geräteregistrierung für Remote-Test-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS für jede Instanz der Remote-Test-FdVs eine gültige Geräteregistrierung sicherstellen, sofern für die jeweilige Anwendung der TI eine Geräteregistrierung erforderlich ist. [<=]
A_24735 - Keine Fachlogik in den Testtreibern für Remote-Test-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS sicherstellen, dass in den Testtreiber-Modulen keine Fachlogik des jeweils zugehörigen TI-Moduls implementiert ist. [<=]
A_24736 - Version des Testtreibers passend zur Version des TI-Moduls
Der Hersteller eines FdV der Krankenversicherungen MUSS in jeder Instanz eines Remote-Test-FdVs die Version eines Testtreibers bereitstellen, die zur mit dem FdV bereitgestellten Version des TI-Moduls gehört. [<=]
A_24737 - Anbindung von Remote-Test-FdVs an die Fachdienste der TI
Der Hersteller eines FdV der Krankenversicherungen MUSS die mit den Remote-Test-FdVs bereitgestellten TI-Module an die zugehörigen Fachdienste der RU oder TU anbinden. Die Festlegung, welche FdV-Instanz mit welcher Umgebung verbunden wird, MUSS mit der gematik abgestimmt werden. [<=]
A_24738 - Keine Testtreiber-Module in den produktiven FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS sicherstellen, dass keine Testtreiber-Module in den produktiven Versionen des FdVs enthalten ist. [<=]
A_24739 - Bereitstellung von Test-FdVs als Softwarepaket ohne Testtreiber
Der Hersteller eines FdV der Krankenversicherungen, das ein oder mehrere TI-Module einbindet, MUSS der gematik entsprechend Zulassungsantrag für jede mobile und Desktop-Betriebssystemversion ein Zulassungsobjekt als Softwarepaket ohne Testtreiberschnittstellen bereitstellen. Die Bereitstellung bzw. Übergabe erfolgt in Absprache mit der gematik.
Der Hersteller eines FdV der Krankenversicherungen MUSS das vollständige Vorhandensein benötigter Lizenzen für die Nutzung der bereitgestellten Geräte und der Whitelabel-Apps sicherstellen. [<=]
A_24740 - Bereitstellung der FdV-Software als Whitelabel-App
Die vom Hersteller eines FdV der Krankenversicherungen an die gematik zu liefernden Softwarepakete SOLLEN NICHT versicherungsspezifisch ausgeprägt sein (Whitelabel-App). [<=]
A_25145 - Bereitstellung der Whitelabel-App ohne Kassen-Services
Der Hersteller eines FdV der Krankenversicherungen KANN der gematik eine Whitelabel-App zur Verfügung stellen, die abweichend zum Zulassungsobjekt die kassenindividuellen Funktionen nicht beinhaltet, sofern alle TI-Module inkl. Authentisierung gemäß Zulassungsantrag mit GUI in der Whitelabel-App enthalten sind. [<=]
A_24741 - Dokumentation für Whitelabel-Apps
Der Hersteller eines FdV der Krankenversicherungen MUSS der gematik für jede zuzulassende Betriebssystemversion eine Installationsanleitung und eine Dokumentation oder Bedienungsanleitung für die Whitelabel-App bereitstellen. [<=]
A_24742 - Bereitstellung mobiler Geräte für den Test von Whitelabel-Apps
Der Hersteller eines FdV der Krankenversicherungen MUSS für jedes zuzulassende mobile Betriebssystem pro TI-Modul ein mobiles Gerät als Leihstellung zur Installation einer entsprechenden Whitelabel-App bereitstellen. [<=]
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.
A_24743 - Erneute Bereitstellung mobiler Geräte für den Test von Whitelabel-Apps
Der Hersteller eines FdV der Krankenversicherungen MUSS bereitgestellte mobile Geräte durch neue Geräte ersetzen, wenn auf den zuvor gelieferten Geräten die verfügbare Betriebssystemversion von der Whitelabel-App nicht mehr unterstützt wird. [<=]
Dies trifft zu, wenn auch mittels angebotenem OTA-Firmware-Update vom Geräte-Hersteller kein für das FdV nutzbarer Zustand hergestellt werden kann.
A_24744 - Kartenlesegeräte für den Test von Desktop-FdVs
Der Hersteller eines FdV der Krankenversicherungen MUSS für die Nutzung von Whitelabel-Apps auf Desktopgeräten pro TI-Modul und zuzulassendem Desktop-Betriebssystem der gematik Kartenlesegeräte bereitstellen, sofern ein Kartenlesegerät durch die App benötigt wird. Wenn bestimmte Modelle oder Klassen von Kartenlesegeräten zur Nutzung vorgegeben sind, so MUSS von diesen Modellen oder Klassen je ein Gerät bereitgestellt werden. [<=]
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.
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.
A_24933 - Testtreiber für TIM
Der Hersteller eines TIM-Clients und TIM-Fachdienstes MUSS eine Testtreiberschnittstelle implementieren, über welche der Client für Tests angesprochen und gesteuert werden kann. [<=]
A_24934 - Bereitstellung TI-Messenger-Fachdienst bei Clientzulassung
Der Hersteller eines TI-Messenger-Clients (z. B. Android, iOS, Web, integriertes Client Modul) MUSS dafür sorgen, dass ein TI-Messenger-Fachdienst für die Anmeldung seines Clients zur Verfügung steht. [<=]
A_24935 - Bereitstellung TI-Messenger-Clients bei Fachdienstzulassung
Der Hersteller eines TI-Messenger-Fachdienstes MUSS dafür sorgen, dass ein TI-Messenger-Client (z. B. Android, iOS, Web, integriertes Client Modul) für die Anmeldung an seinen Fachdienst zur Verfügung steht. [<=]
A_24939 - Präsentation der Anwendungsfälle
Die Hersteller MÜSSEN anhand eines Look & Feel Workshops die Usability und User Experience des zuzulassenden Clients vorführen, in dem sie die Anwendungsfälle demonstrieren. [<=]
A_24940 - Bereitstellung von TI-Messenger-Clients als Softwarepaket ohne Testtreiber
Der Hersteller eines TI-Messenger-Clients MUSS der gematik entsprechend Zulassungsantrag für jede mobile und Desktop-Betriebssystemversion ein Zulassungsobjekt als Softwarepaket ohne Testtreiberschnittstellen bereitstellen. Die Bereitstellung bzw. Übergabe erfolgt in Absprache mit der gematik.
Der Hersteller MUSS das vollständige Vorhandensein benötigter Lizenzen für die Nutzung der Whitelabel-Apps sicherstellen. [<=]
A_24941 - Dokumentation für TI-Messenger-Clients
Der Hersteller eines TI-Messenger-Clients MUSS der gematik für jede zuzulassende Betriebssystemversion eine Installationsanleitung und eine Dokumentation oder Bedienungsanleitung für die App bereitstellen. [<=]
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.
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.
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.
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.
WA-A_2121 - Verfügbarkeit der Anwendung in der Testumgebung
Der Anbieter einer WANDA Smart MUSS auf Anfrage der gematik alle für Bestätigungstests bereitgestellten Dienste einer WANDA Smart in der Testumgebung zur Verfügung stellen. [<=]
WA-A_2122 - Eigenverantwortlicher Test: Anbieter weiterer Anwendungen
Der Anbieter einer WANDA Smart MUSS im Rahmen der Eigenverantwortlichen Tests seine Pflichten gemäß Tabelle Tab_Test_027 Eigenverantwortlicher Test WANDA erfüllen. [<=]
Tabelle 20: Tab_Test_027 Eigenverantwortlicher Test WANDA
Testphase |
Eigenverantwortlicher Test |
---|---|
Beschreibung |
In der Testphase „Eigenverantwortlicher Test“ werden die weiteren Anwendungen durch die Anbieter gegen die Anforderungen aus dem Abschnitt „Schnittstellentest“ des Anwendungssteckbriefs für andere Anwendungen des Gesundheitswesens geprüft, sofern sie für die Anwendung relevant sind. |
Ziel |
|
Eingangskriterien |
|
Ausgangskriterien |
|
Testdokumentation/ Leistungsgegenstände |
|
Teststufen |
|
Systemumgebung |
|
Aufgaben des Test & Transitionmanagers |
|
Pflichten Anbieter weiterer Anwendungen |
|
WA-A_2123 - Eigenverantwortlicher Test: Verwendung Template
Der Anbieter einer WANDA Smart SOLL im Rahmen der Eigenverantwortlichen Tests das von der gematik erstellte Template für den Testbericht nutzen. [<=]
WA-A_2124 - Bestätigungstest: Anbieter weiterer Anwendungen
Der Anbieter einer WANDA Smart MUSS im Rahmen der Bestätigungstests seine Pflichten gemäß Tabelle Tab_Test_007 Bestätigungstest erfüllen. [<=]
Tabelle 21: Tab_Test_007 Bestätigungstest
Testphase |
Bestätigungstest |
---|---|
Beschreibung |
In der Testphase „Bestätigungstest“ werden Produkte zum Nachweis der Produktivbetriebsreife geprüft. |
Ziel |
|
Eingangskriterien |
|
Ausgangskriterien |
|
Testdokumentation/ Leistungsgegenstände |
|
Teststufen |
|
Systemumgebung |
|
Aufgaben der Test- & Transitionmanager |
|
Aufgaben der Testdurchführenden Instanz TU |
|
Pflichten Hersteller und Anbieter |
|
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.
Kürzel |
Erläuterung |
---|---|
AdV | Anwendung(en) des Versicherten |
AZPD |
Anbieter zentrale Plattformdienste |
CAB |
Change Advisory Board |
EVT |
Eigenverantwortliche Tests |
FdV | Frontend des Versicherten |
NFC | Near Field Communication |
OTA | Over the Air |
PU |
Produktivumgebung |
RU |
Referenzumgebung |
TBI |
Testbetriebsinstanz |
TIZP | Testintegrator zentrale Plattformdienste |
TDI |
Testdurchführende Instanz |
TKI |
Testkoordinierende Instanz |
TSP |
Trusted Service Provider |
TU |
Testumgebung |
WANDA Basic | Weitere Anwendungen für den Datenaustausch ohne Nutzung der TI oder derer kryptografischen Identitäten |
WANDA Smart | Weitere Anwendungen für den Datenaustausch mit Nutzung der TI oder derer kryptografischen Identitäten für eigene Anwendungszwecke |
ZulT |
Zulassungstest |
Begriff |
Erläuterung |
---|---|
Anforderungsbasierter Test |
Bezeichnet eine Testvorgehensweise, bei der die Testfälle von den Anforderungen abgeleitet werden. Grundsätzlich soll für jede Anforderung die Erfüllung nachgewiesen werden. |
Anwendungsfallbasierter Test |
Bezeichnet eine Testvorgehensweise, bei der die Testfälle von den (technischen oder fachlichen) Anwendungsfällen abgeleitet werden. Grundsätzlich soll für jeden Anwendungsfall die positive Durchführung nachgewiesen werden. |
Change Advisor Board |
Gremium im ITSM-TI-Prozess Change Management zur Bewertung und Autorisierung von Requests for Change (RfC), die potenziell übergreifende Auswirkungen auf andere TI-Produktinstanzen haben. Das CAB wird anlassbezogen vom Servicebetriebsverantwortlichen (SBV) einberufen, Teilnehmer sind Stakeholder der vom Change betroffenen Produkte und TI-Services. |
FdV | Frontend des Versicherten, ist ein Programm, das den Versicherten zur Nutzung von Anwendungen der TI bereitgestellt wird. |
Remote-Test-FdV | Ist ein FdV, das zu Testzwecken in der Umgebung des FdV-Herstellers bereitgestellt wird. Um dieses FdV im Testverlauf nutzen zu können, wird eine oder mehrere Testtreiberschnittstellen bereitgestellt, die über das Internet angesprochen werden. Die Testtreiberschnittstellen für die verschiedenen Funktionsmodule der TI werden von der gematik spezifiziert. |
Whitelabel-App | Eine Whitelabel-App ist ein Programm, dass zu Testzwecken von einem Hersteller bereitgestellt wird, ohne konfigurative Anpassungen für einen konkreten Anbieter (z. B. eine Krankenversicherung) in dieses Programms zu integrieren (kein "Branding"). |
Ein umfangreiches Glossar findet sich im Fachportal der gematik-Website.
[Quelle] |
Herausgeber: Titel |
---|---|
[gematikShop] | gematik: https://fachportal.gematik.de/gematik-onlineshop |
[gemKPT_Betr] |
gematik: Betriebskonzept Online-Produktivbetrieb (OPB) |
[gemSpec_eRp_FdV] | gematik: Spezifikation E-Rezept-Frontend des Versicherten |
[gemSpec_Perf] |
gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform |
[gemSpec_TK] |
gematik: Spezifikation für Testkarten gematik (eGK, HBA, (g)SMC) der Generation 2 |
[gemSpec_Krypt] |
gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur |
[gemSpec_TK_FD] |
gematik: Spezifikation für Testkarten Fachdienste (eGK) der Generation 2 |
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
[RFC2119] |
RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner |
[IEEE829] |
Software & Systems Engineering Standards Committee: IEEE Standard für Software and System Test Documentaion, Revision 2008 |