C_12019_Anlage_V1.1.0

Prereleases:

PDF HTML Excel XML
C_12019_Anlage_V1.1.0

C_12019_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

Dieser Änderungseintrag dokumentiert die Änderungen zur [gemKPT_Test], welche die Testanforderungen für den neuen Produkttyp PoPP-Service enthalten. Produktübergreifende Anforderungen sind im Anhang C_12020 zusammengefasst.

2 Änderungen in gemKPT_Test

2.1 Testregelungen und Festlegungen bei Beauftragungen

Dieses Kapitel wird vor Kapitel 6.1 in gemKPT_Test übernommen und enthält spezielle Anforderungen für Testregelungen und Festlegungen bei Beauftragungen.

Die Test- und Prüfaktivitäten der gematik bei Beauftragungen zielen auf eine umfassende Validierung der Qualität, Funktionalität und Interoperabilität der entwickelten Produkte und Anwendungen im Gesamtkontext der Telematikinfrastruktur ab.

Dieser ganzheitliche Ansatz gewährleistet, dass die Produkte sowohl eigenständig funktionieren als auch nahtlos mit anderen Komponenten interagieren und die vorgegebenen Qualitätsstandards erfüllen. Der Testprozess umfasst produktspezifische und -übergreifende Tests, um die Ende-zu-Ende-Funktionalität und Interoperabilität im gesamten System sicherzustellen. Der Auftragnehmer (AN) muss die Erfüllung aller funktionalen und nicht-funktionalen Anforderungen nachweisen.

Während der Entwicklung ist der AN verpflichtet, den Fortschritt an definierten Kontrollpunkten transparent darzulegen und das Erreichen von Meilensteinen proaktiv der gematik mitzuteilen. Nach Abschluss der Entwicklung erfolgt eine Güteprüfung durch die gematik, bei der die vom AN erstellte Testdokumentation eingehend bewertet wird. In der Gesamtintegration testet die gematik das Zusammenspiel aller Komponenten der TI.

Die erfolgreiche Gesamtintegration ist Voraussetzung für die Produktivsetzung, eine formale Abnahme wird im jeweiligen Vertrag mit dem AN geregelt.

Der Test Consultant begleitet den gesamten Prozess von der Beauftragung bis zur Abnahme und übernimmt verschiedene Verantwortlichkeiten. Folgende Tätigkeiten sind relevant:

  1. Kontrollpunkte
    • Ziel: Überprüfung des Projektfortschritts, regelmäßige Bewertung von Zwischenergebnissen, Möglichkeit für zeitnahe Korrekturen
    • Art: Informativ
    • Aufgabe Test Consultant: Begleitend
  2. Information
    • Ziel: Kontinuierlicher Austausch mit dem Auftragnehmer, proaktive Mitteilung über Meilensteine und potenzielle Blocker vom Auftragnehmer, Sicherstellung der Transparenz im Projektverlauf
    • Art: Informativ
    • Aufgabe Test Consultant: Begleitend
  3. Güteprüfung
    • Ziel: Detaillierte Bewertung der Testdokumentation
    • Art: Formal
    • Aufgabe Test Consultant: Prüfung
  4. Zulassungstests
    • Ziel: Gesamtintegration in der Telematikinfrastruktur
    • Art: Test
    • Aufgabe Test Consultant: Durchführend
  5. Abnahme
    • Ziel: Überprüfung und Freigabe der Gesamtleistung
    • Art: Formal
    • Aufgabe Test Consultant: Begleitend

A_27248 - Güteprüfung Test

Die Güteprüfung stellt eine zentrale Qualitätssicherungsmaßnahme im Rahmen von Beauftragungen dar. Sie dient der detaillierten Prüfung und Bewertung der geforderten Testdokumente und die jeweiligen Produkte. 
Der Auftragnehmer MUSS mindestens folgende Testdokumente als Liefergegenstände bereitzustellen:

  1. Testkonzept: Entsprechend den Vorgaben in Tab_Test_013 des [gemKPT_Test],
  2. Testspezifikation: Gemäß den Anforderungen in Tab_Test_014 des [gemKPT_Test],
  3. Testbericht: Konform zu Tab_Test_018 des [gemKPT_Test],
  4. Produktdokumentation: entsprechend der Vorgaben in "Tab_Test_016 Produktdokumentation" des [gemKPT_Test],
  5. Afo-Testmatrix: In Übereinstimmung mit den Richtlinien des [gemKPT_Test].
Diese Dokumente bilden die Grundlage für eine umfassende Beurteilung der Testqualität und -Vollständigkeit. Der Auftraggeber (AG) prüft die Dokumente auf Einhaltung der definierten Vorgaben  gemäß [TIP1-A6524-01] und protokolliert die Prüfung.
 [<=]

A_27141 - Testmanagementsystem des AN

Der AN MUSS für die Testaktivitäten während der eigenverantwortlichen Tests ein umfassendes Testmanagementsystem einsetzen und dem AG den vollen Zugriff hierfür gewähren. Das Testmanagementsystem MUSS folgende Testaktivitäten unterstützen:

  1. Testdurchführung: Alle Tests im System durchführen und dokumentieren, einschließlich E2E-Tests und BDD-Szenarien.
  2. Fehlermanagement: Fehler erfassen, mit Details versehen und sichtbar machen.
  3. Fortschritt und Berichte: Testfortschritt jederzeit einsehbar, automatische Berichtgenerierung.
  4. Artefakte: Testartefakte im System verwalten.
  5. Dokumentation: Benutzerdokumentation und Systemanleitungen bereitstellen.
  6. Zugriffsrechte: AG erhält Lesezugriff, bei Bedarf auch Schreibrechte.
  7. Versionskontrolle: Für Testfälle, Skripte und andere Artefakte.
  8. Nachverfolgbarkeit: Zwischen Anforderungen, Testfällen und Ergebnissen.
Der AN MUSS die Erfüllung dieser Anforderungen für eine transparente Zusammenarbeit gewährleisten.
[<=]

A_27142 - Anforderungen an Testreporting

Der AN MUSS über den Teststatus regelmäßig berichten (Frequenz noch zu definieren), dabei wird:

  1. Eine Darstellung des aktuellen Testfortschritts, einschließlich der Anzahl durchgeführter, erfolgreicher und fehlgeschlagener Tests.
  2. Einer detaillierten Erfassung aller gefundenen Fehler, inklusive Schweregrad, Priorität und Status.
  3. Informationen zur Testabdeckung, um sicherzustellen, dass alle kritischen Funktionen getestet wurden.
  4. Eine Einschätzung der identifizierten Risiken basierend auf den Testergebnissen.
[<=]

A_27142-01 - Anforderungen an Testreporting

Der AN MUSS über den Teststatus der eigenverantwortlichen Tests in der RU DEV regelmäßig berichten (Frequenz noch zu definieren), dabei werden folgende Informationen bereitgestellt: 

  1. Eine Darstellung des aktuellen Testfortschritts, einschließlich der Anzahl durchgeführter, erfolgreicher und fehlgeschlagener Tests.
  2. Einer detaillierten Erfassung aller gefundenen Fehler, inklusive Schweregrad, Priorität und Status.
  3. Informationen zur Testabdeckung, um sicherzustellen, dass alle kritischen Funktionen getestet wurden.
  4. Eine Einschätzung der identifizierten Risiken basierend auf den Testergebnissen.
[<=]

2.2 Proof of Patient Presence PoPP

Dieses Kapitel wird nach Kapitel 9 in gemKPT_Test übernommen und enthält spezielle Anforderungen für den PoPP -Service.

Die Telematikinfrastruktur erfährt im Zuge ihrer Modernisierung auf Version 2.0 diverse architektonische Verbesserungen.
Ein Kernaspekt der TI 2.0 ist die Nutzung der TI-Fachdienste "Anytime Anywhere" über das Internet.

Der PoPP-Service erzeugt die Bestätigung eines Versorgungskontextes in Form des kryptographisch gesicherten PoPP-Token. Dieses bestätigt, dass ein bestimmter Versicherter mit einer bestimmten Leistungserbringerinstitution zusammengekommen ist. Der PoPP-Token wird beim Zugriff von Leistungserbringern auf TI-Fachdienste (z. B. VSDM2, ePA für alle, E-Rezept) mit übergeben.

2.2.1 Allgemeine Anforderungen an den Test der PoPP-Service-Komponenten

A_26673 - Testumgebung in der Produktentwicklungsphase

Der Hersteller des PoPP-Service MUSS in der Produktentwicklungsphase das Testobjekt in der Vorintegrationsumgebung RU DEV bereitstellen, um Tests für die Kontrollpunkte unter [A_26676] zu ermöglichen. 
[<=]

A_26674 - Bereitstellung von Testkomponenten und Testartefakten in den Testumgebungen

Der Hersteller des PoPP-Service MUSS das Testobjekt und Testartefakte so entwickeln und bereitstellen, dass diese in allen Testumgebungen genutzt werden können.
[<=]

A_26675 - Format der Testszenarien

Der Hersteller des PoPP-Service MUSS alle für den funktionalen Test erforderlichen Testszenarien und Testfälle nach der Behavior Driven Development (BDD)-Technik erstellen und z. B. in der Beschreibungssprache "Gherkin" formulieren.
[<=]

A_26676 - Kontrollpunkte während der Entwicklungsphase

Der AN MUSS die von der gematik vorgegebenen Kontrollpunkte während der Entwicklungsphase durchführen. Dadurch wird die Reife und der Fortschritt der in Entwicklung befindlichen Produktkomponenten überprüft.

[<=]

A_26677 - Herstellerspezifische Kontrollpunkte

Der Hersteller des PoPP-Service KANN weitere Kontrollpunkte in seinem Qualitätsprozess vorsehen und umsetzen. In diesem Fall KÖNNEN die Testergebnisse in einer von der gematik bereitgestellten Datenaustauschplattform abgelegt werden.
 [<=]

A_26680 - Versionierung der Testkomponenten

Der Hersteller des PoPP-Service MUSS alle für den Test genutzten Komponenten mit Datum und Version auflisten. 
[<=]

A_26680-01 - Versionierung der Testkomponenten

Der AN MUSS alle für den Test genutzten Komponenten mit Datum und Version auflisten. 
[<=]

2.2.1.1 Testumgebungen für PoPP

Die neue Teststrategie der gematik unterscheidet zwischen einer Phase "Eigenverantwortlicher Test (EvT)", welcher durch den Hersteller des PoPP-Service selbst und einer Phase "Zulassungstest (ZulT)", welcher durch die gematik im Zusammenspiel mit dem Hersteller des PoPP-Service durchgeführt wird. Diese Testphasen werden in verschiedenen Testumgebungen absolviert, für die der Hersteller des PoPP-Service Testobjekte (Produktmuster, Zulassungsobjekt) zur Verfügung stellen müssen. Die folgenden Systemumgebungen werden für den Test des PoPP-Service mindestens benötigt:

Tabelle 1: Testumgebungen für PoPP

Bezeichnung Verantwortung Testphase Teststufe(n) Testobjekt
RU DEV gematik EvT Produktübergreifender Interoperabilitätstest (IOP) Hersteller
TU gematik  ZulT Produktübergreifender Test, Gesamtintegrationstest Betreiber
RU gematik  ZulT  Gesamtintegrationstest, Hotfix-Test Betreiber

2.2.1.2 Bereitstellung PoPP-Service für die Testphase "Eigenverantwortlicher Test"

Der Hersteller des PoPP-Service soll zukünftig die Möglichkeit erhalten, produktübergreifende, eigenverantwortliche IOP noch vor den Zulassungstests ausführen zu können. Hierzu stellt die gematik eine neue Testumgebung bereit, die RU DEV. Für die Bereitstellung des PoPP-Service in der RU DEV während der Entwicklungsphase ist der Hersteller des PoPP-Service verantwortlich. In der RU DEV können E2E-Testszenarien für PoPP und Interoperabilität auch mit Primärsystemherstellern getestet werden.

Die gematik koordiniert die Entwicklung einer Testsuite, welche auf gitHub zur gemeinsamen Weiterentwicklung und Nutzung zur Verfügung gestellt wird. Die Testsuite bietet die Möglichkeit, die wichtigsten E2E-Testszenarien für PoPP automatisch ausführbar zu machen. Der erfolgreiche Testdurchlauf gilt als Vorbedingung für den Einsatz des Produktes in der jeweiligen Testumgebung.

A_27393 - Bereitstellung als signiertes OCI konformes Image

Der Hersteller des PoPP-Service MUSS jedes Release des Testobjektes als signiertes OCI konformes Image gemeinsam mit der Konfigurationsanleitung zur Integration in die gemeinsame RU DEV Umgebung liefern. [<=]

A_27394 - Agiler Bereitstellungsprozess

Um die Stabilität der gemeinsamen RU DEV Umgebung zu gewährleisten, MUSS der Hersteller des PoPP-Service sich an folgendem agilen Prozess halten.

  1. Änderungsmanagement: Der Hersteller des PoPP-Service DARF Modifikationen an den Komponenten ausschließlich innerhalb der dafür vorgesehenen Zeitfenster zwischen den durch gematik festgelegten Sprints vornehmen.
  2. Flexibilität bei der Bereitstellung: Der Hersteller des PoPP-Service MUSS das aktuelle Bereitstellungsfenster überspringen, wenn das Testobjekt noch keinen stabilen Status erreicht hat.
  3. Automatisierte Qualitätssicherung: Nach dem Schließen des Änderungszeitfensters werden in der RU DEV Umgebung über Nacht automatisierte E2E-Tests ausgeführt. Diese haben zum Ziel, potenzielle Probleme in den Komponenten zu identifizieren, die möglicherweise negative Auswirkungen auf die Tests anderer Hersteller haben könnten.
  4. Fehleranalyse-Phase: Der Hersteller des PoPP-Service MUSS während der Testdurchführung aufgetretene Fehler, nach der Bereitstellung analysieren, um die betroffenen Komponenten zu identifizieren. Die gematik legt die Länge der Fehleranalyse-Phase anlassbezogen fest.
  5. Rollback: Der Hersteller des PoPP-Service MUSS das Testobjekt am Ende der Fehleranalyse-Phase auf die letzte bekannte, fehlerfreie Version zurückzusetzen, falls Fehler im Testobjekt festgestellt wurden, welche die Integrität des Gesamtsystems gefährden. Der Hersteller des PoPP-Service MUSS die festgestellten Fehler im Testobjekt in den nächsten Sprints beheben.
  6. Abschluss der Änderungen: Nach dem Rollback prüft die automatisierte Qualitätssicherung erneut, ob die Stabilität der gemeinsamen Umgebung gewährleistet ist. Sollte dies nicht der Fall sein, werden die Schritte 4 bis 6 solange überprüft, bis die gemeinsame Umgebung die notwendige Stabilität erreicht.
Durch diese strukturierte Vorgehensweise wird eine hohe Systemstabilität gewährleistet und gleichzeitig die notwendige Flexibilität für kontinuierliche Verbesserungen und Anpassungen ermöglicht.
[<=]

2.2.2 Anforderungen an die Testinfrastruktur und Testartefakte der PoPP-Service-Komponenten

A_26684 - Freie Nutzung der entwickelten Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte, die für die Testaktivitäten vom Hersteller entwickelt werden, der gematik Kosten- und Lizenzfrei zur Nutzung und Weiterentwicklung zur Verfügung stellen.
[<=]

A_27053 - Freie Nutzung der erworbenen Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte, die für die Testaktivitäten von Dritten erworben werden, der gematik Kosten- und lizenzfrei zur Nutzung zur Verfügung stellen.
[<=]

A_26685 - Automatisierung der Testartefakte

Der Hersteller des PoPP-Service MUSS alle Testartefakte so entwickeln und bereitstellen, dass diese eine kontinuierliche, automatisierte Testausführung ermöglichen.
[<=]

A_26686 - Verwendbarkeit von Testkomponenten und Testartefakten in automatisierten CI/CD-Pipelines

Der Hersteller des PoPP-Service MUSS ausführbare Testartefakte so entwickeln und bereitstellen, dass sie in automatisierten CI/CD-Pipelines verwendet werden können.
[<=]

A_26688 - Labeln von Komponenten

Der Hersteller des PoPP-Service MUSS seine Komponenten mit einem zur Umgebung gehörenden Label versehen. Dadurch sollen Komponenten im Produktlebenszyklus eindeutig identifiziert werden, ob sie in der TU oder PU eingesetzt werden dürfen.
[<=]

A_26689 - Keine Hardware-Abhängigkeiten bei Komponenten in Testumgebungen

Der Hersteller des PoPP-Service MUSS seine Komponenten so entwickeln und bereitstellen, dass keine Hardware-Abhängigkeiten, z. B. zu einem HSM entstehen. Dies kann z. B. durch den Einsatz von Simulatoren oder Mocks erreicht werden.
[<=]

A_26690 - Nutzung von Private oder Secret Keys in Testumgebungen

Der Hersteller des PoPP-Service MUSS in Testumgebungen sicherstellen, dass die verwendeten Private oder Secret Keys bekannt sind.
[<=]

Hinweis: Dies kann z. B. durch das Einbringen von bekannten Private bzw. Secret Keys erfolgen, oder durch dessen Auslesen aus einem Schlüsselspeicher der Testumgebung.

A_27100 - Übergreifende Testmaßnahmen

Der Hersteller des PoPP-Service MUSS bei der Vorbereitung und Durchführung von übergreifenden Testmaßnahmen, wie z. B. Durchstichtests oder Connectathons, auch nach der Zulassung auf Aufforderung des AG mitwirken, z. B. durch Bereitstellung und Konfiguration der benötigten Komponenten und Testumgebungen oder Unterstützung bei der Problemanalyse. [<=]

Eine genaue Definition von Art und Umfang des zu leistenden Supports wird vertraglich zwischen gematik und Hersteller abgestimmt.