C_12176_Anlage_V1.0.0_CC
Prereleases:
C_12176 - E-Rechnung - Änderungen in gemKPT-Test
ML-167546 - E-Rechnung - Änderungen in gemKPT_Test
[<=]
Inhaltsverzeichnis
1 Änderungsbeschreibung
Dieser Änderungseintrag dokumentiert die Änderungen zum [gemKPT_Test], welche die Testanforderungen für die neue Anwendung E-Rechnung (eRg) enthalten. Produktübergreifende Anforderungen sind im Anhang C_12020 zusammengefasst.
1.1 Testregelungen und Festlegungen bei Beauftragungen
## Der Abschnitt 1.1 wird in das [gemKPT_Test] übernommen.
Es 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 (TI) ab.
Dieser ganzheitliche Ansatz gewährleistet, dass die Produkte sowohl eigenständig funktionieren als auch nahtlos mit anderen Komponenten interagieren und zudem 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 zu erstellende 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 Testverantwortliche ( ? Testansprechpartner [der] ) gematik begleitet den gesamten Prozess von der Beauftragung bis zur Abnahme und übernimmt verschiedene Verantwortlichkeiten. Folgende Tätigkeiten sind dabei relevant:
- Kontrollpunkte
- Ziel: Überprüfung des Projektfortschritts, ( durch ) regelmäßige Bewertung von Zwischenergebnissen, ( und der ) Möglichkeit für zeitnahe Korrekturen
- Art: informativ
- Aufgabe Test Consultant: begleitend
- Information
- Ziel: kontinuierlicher Austausch mit dem AN, ( durch ) proaktive Mitteilung über Meilensteine und potenzielle Blocker vom AN, ( und der ) Sicherstellung der Transparenz im Projektverlauf
- Art: informativ
- Aufgabe Test Consultant: begleitend
- Güteprüfung
- Ziel: detaillierte Bewertung der Testdokumentation
- Art: formal
- Aufgabe Test Consultant: Prüfung ( prüfend )
- Zulassungstests
- Ziel: Gesamtintegration in der TI
- Art: Test
- Aufgabe Test Consultant: durchführend
- 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:
- Testkonzept: Entsprechend den Vorgaben in Tab_Test_013 des [gemKPT_Test],
- Testspezifikation: Gemäß den Anforderungen in Tab_Test_014 des [gemKPT_Test],
- Testbericht: Konform zu Tab_Test_018 des [gemKPT_Test],
- Produktdokumentation: entsprechend der Vorgaben in "Tab_Test_016 Produktdokumentation" des [gemKPT_Test],
- Afo-Testmatrix: In Übereinstimmung mit den Richtlinien des [gemKPT_Test].
[<=]
A_27141 - Testmanagementsystem des AN
Der AN MUSS für die Testaktivitäten ein umfassendes Testmanagementsystem einsetzen und dem AG den vollen Zugriff hierfür gewähren. Das Testmanagementsystem MUSS folgende Testaktivitäten unterstützen:
- Testdurchführung: Alle Tests im System durchführen und dokumentieren, einschließlich E2E-Tests und BDD-Szenarien.
- Fehlermanagement: Fehler erfassen, mit Details versehen und sichtbar machen.
- Fortschritt und Berichte: Testfortschritt jederzeit einsehbar, automatische Berichtgenerierung.
- Artefakte: Testartefakte im System verwalten.
- Dokumentation: Benutzerdokumentation und Systemanleitungen bereitstellen.
- Zugriffsrechte: AG erhält Lesezugriff, bei Bedarf auch Schreibrechte.
- Versionskontrolle: Für Testfälle, Skripte und andere Artefakte.
- Nachverfolgbarkeit: Zwischen Anforderungen, Testfällen und Ergebnissen.
[<=]
A_27142 - Anforderungen an Testreporting
Der AN MUSS über den Teststatus regelmäßig berichten (Frequenz noch zu definieren), dabei wird:
- Eine Darstellung des aktuellen Testfortschritts, einschließlich der Anzahl durchgeführter, erfolgreicher und fehlgeschlagener Tests.
- Einer detaillierten Erfassung aller gefundenen Fehler, inklusive Schweregrad, Priorität und Status.
- Informationen zur Testabdeckung, um sicherzustellen, dass alle kritischen Funktionen getestet wurden.
- Eine Einschätzung der identifizierten Risiken basierend auf den Testergebnissen.
1.2 Fachanwendung E-Rechnung
## Dieser Abschnitt 1.2 bis 1.2.2 wird nach dem Kapitel 9 im [gemKPT_Test] eingefügt.
Es enthält spezielle Anforderungen für E Rechnung.
Die Anwendung E-Rechnung (eRg) stellt eine auf digitalen Daten basierende Lösung für den Abrechnungsprozess medizinischer oder sonstiger Leistungen, die nicht dem Sachleistungsprinzip unterliegen, zur Verfügung.
Wichtige Kernaspekte für die Testplanung :
Der E-Rechnung Fachdienst (eRg FD) wird als Relying-Party in die IDP- und Dienste-Föderation aufgenommen.
Die Authentisierung der Leistungserbringerinstitutionen (LEI) und Abrechnungsdienstleister (ADL) erfolgt in der ersten Version der eRg mittels einer Security Module Card Typ B (SMC-B) - bzw. eines Security Module Typ B (SM-B) bei HSM-basierten Identitäten. Eine Umstellung auf digitale Identitäten für Leistungserbringer (LE) ist Gegenstand einer zukünftigen Ausbaustufe.
Der eRg FD ist in der ersten Version der eRg für Versicherte, LEI und ADL über das Internet erreichbar. Die Kommunikation mit dem eRg FD erfolgt über eine standardisierte Schnittstelle (REST API). Ein Zugang über das geschlossene Netz der Telematikinfrastruktur (TI) ist dafür nicht vorgesehen.
Die fachlichen Schnittstellen der eRg und ihre Informationsobjekte basieren auf Health Level 7 Fast Healthcare Interoperable Resources (HL7 FHIR).
1.2.1 Einordnung in die Telematikinfrastruktur
Die Integration der E-Rechnung (eRg) in die bestehende Telematikinfrastruktur (TI) umfasst folgende Komponenten:
- Primärsysteme (PS) der Leistungserbringer (LE) und Abrechnungsdienstleister (ADL):
- Die PS erzeugen und übermitteln E-Rechnungen an den Fachdienst (eRg FD).
- ADL können als Dienstleister für LE-Institutionen fungieren.
- Frontend des Versicherten der E-Rechnung (eRg FdV):
- Empfang, Einsicht und Einreichung von E-Rechnungen
- Verwaltung des Bearbeitungsstatus
- Übertragung in persönliche Ablage oder ePA-Aktenkonto
- ( als erster Punkt ) Zugriff nach Authentisierung mittels GesundheitsID
- Frontend des Versicherten für die elektronische Patientenakte (ePA FdV):
- Übertragung von E-Rechnungen in die ePA
- vorerst mittels Übergabe von PDF-Rechnungen an das ePA FdV
- IT-Systeme der Kostenträger (KTR-Systeme):
- Entgegennahme und Bearbeitung eingereichter Rechnungen
- Verarbeitung digital und postalisch eingereichter Rechnungen
- Abruf von E-Rechnungen aus dem eRg FD mittels Barcode bei Postweg
Die Rückmeldung des Bearbeitungsstatus ( an wen ) und die Bereitstellung der Leistungsabrechnung durch die KTR erfolgt in der ersten Ausbaustufe ( noch ) nicht über die ( Anwendung ) E-Rechnung.
Abbildung 1: Einordnung der Anwendung E-Rechnung in die TI
1.2.2 Allgemeine Anforderungen an den Test der E Rechnung Fachdienst
A_26673-01 - Testumgebung in der Produktentwicklungsphase
Der Zulassungsnehmer MUSS in der EvT Testphase das Testobjekt in der Vorintegrationsumgebung RU DEV bereitstellen. Der genaue Zeitpunkt für diese Bereitstellung MUSS mit dem Testverantwortlichen der gematik abgestimmt werden. Dies dient dazu, Interoperabilitätstests mit Dritten zu ermöglichen. Die Tests MÜSSEN Funktions- und Integrationstests umfassen, deren Ergebnisse zu dokumentieren und dem Auftraggeber vorzulegen sind.
[<=]
A_26674-01 - Bereitstellung von Testkomponenten und Testartefakten in den Testumgebungen
Der Zulassungsnehmer MUSS Testkomponenten und Testartefakte so entwickeln und bereitstellen, dass diese in allen Testumgebungen genutzt werden können.
[<=]
A_26675-01 - Format der Testszenarien
Der Zulassungsnehmer 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 Zulassungsnehmer 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_26680 - Versionierung der Testkomponenten
Der Hersteller des PoPP-Services MUSS alle für den Test genutzten Komponenten mit Datum und Version auflisten.
[<=]
A_26678 - Tests der einzelnen Systemkomponenten über die externe Schnittstelle
Der AN MUSS für die Komponententests alle darin verorteten funktionalen Anforderungen über die dokumentierte externe Schnittstelle testen.
[<=]
A_27540 - Bereitstellungsprozess RU DEV
Um die Stabilität der gemeinsamen RU DEV Umgebung zu gewährleisten, MUSS der Auftragnehmer (AN) sich an folgenden agilen Prozess halten:
Änderungsmanagement
Der AN DARF Modifikationen an den Testobjekten nur in Absprache mit dem Testverantwortlichen der gematik ausführen.
Automatisierte Qualitätssicherung
Der AN MUSS nach jedem Deployment in der RU DEV Umgebung eine automatisierte Smoke-Test-Suite ausführen. Diese Suite MUSS:
- unmittelbar nach dem Deployment ausgeführt werden.
- grundlegende Funktionalitäten und ( die ) Stabilität ( von ) überprüfen um sicherzustellen, dass es keine kritischen Fehler gibt, die die Anwendung ( für wen/was ) unbrauchbar machen könnten.
- potenzielle Probleme identifizieren können, die andere Hersteller ( Teilnehmer der TI ) beeinträchtigen könnten.
- automatisiert ablaufen und schnell durchführbar sein.
Der AN MUSS während der Testdurchführung aufgetretene Fehler nach der Bereitstellung analysieren, um die betroffenen Komponenten zu identifizieren.
Rollback-Prozess
Der AN MUSS das Testobjekt am Ende der Fehleranalyse-Phase auf die letzte bekannte, fehlerfreie Version zurücksetzen, falls Fehler im Testobjekt festgestellt wurden, welche die IOP Tests gefährden.
Kontinuierliche Verbesserung
Der AN SOLL den Bereitstellungsprozess regelmäßig überprüfen und Verbesserungsmöglichkeiten identifizieren, um die Effizienz und Effektivität des Prozesses zu steigern.
[<=]
A_27574 - Freie Nutzung der entwickelten Testartefakte
Der Auftragnehmer 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_27575 - Automatisierung der Testartefakte
Der Auftragnehmer MUSS alle Testartefakte so entwickeln und bereitstellen, dass diese eine kontinuierliche, automatisierte Testausführung ermöglichen. [<=]
A_27576 - Verwendbarkeit von Testkomponenten und Testartefakten in automatisierten CI/CD-Pipelines
Der Auftragnehmer MUSS ausführbare Testartefakte so entwickeln und bereitstellen, dass sie in automatisierten CI/CD-Pipelines verwendet werden können. [<=]
A_27577 - Übergreifende Testmaßnahmen
Der Auftragnehmer MUSS bei der Vorbereitung und Durchführung von übergreifenden Testmaßnahmen, ( z.B ) wie z. B. Durchstichtests oder Connectathons, auch nach der Zulassung auf Aufforderung der gematik mitwirken, z. B. durch Bereitstellung und Konfiguration der benötigten Komponenten und Testumgebungen oder Unterstützung bei der Problemanalyse.
[<=]