A_23347-01 - Performance - Wartungsfenster - Durchführung

Der Anbieter SOLL Wartungsfenster so planen, dass diese vollständig in der Nebenzeit liegen.
Hinweis: Nach voriger Absprache mit und Genehmigung durch den Gesamtverantwortlichen TI ist ein Wartungsfenster in der Hauptzeit möglich.

Ist für einen Anbieter und einem seiner zugeordneten Produkt(e) nur eine Hauptzeit und keine Nebenzeit definiert, dann SOLL der Anbieter ein Wartungsfenster so planen, dass dieses in Zeiten mit wenig Systemlast stattfindet. Das Wartungsfenster muss mit dem Gesamtverantwortlichen TI abgesprochen und durch diesen genehmigt werden. [<=]

A_23348 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Freitag

Der Produkttyp MUSS folgende Servicezeiten gewährleisten:

• Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr.
• Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.

A_23349 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag

Der Produkttyp MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr
• Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.

A_23350 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt

Der Produkttyp MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
• Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
• Alle übrigen Stunden der Woche sind Nebenzeit.

A_23619-01 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag 24/7

Der Produkttyp MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Sonntag von 0 - 24 Uhr, inklusive bundeseinheitlicher Feiertage
• Es ist keine Nebenzeit definiert. 

A_24962 - Performance - Servicezeiten des Anbieters basierend auf Produkttypen

Der Anbieter MUSS gemäß der in [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] aufgeführten Servicekomponenten bzw. der Zuordnung von Produkttypen zu serviceverantwortlichen Anbieter die dem entsprechenden Produkttypen zugeordneten Servicezeiten erfüllen. [<=]

A_23618 - Performance - Wartungsfenster und Ausfall - Verfügbarkeitsberechnung

Der Anbieter MUSS jeden Ausfallzeitraum, ungeachtet von Wartungen, in der Verfügbarkeitsberechnung als Ausfall werten. [<=]

A_23615 - Performance - Wartungsfenster und Ausfall - Ausnahme zur Verfügbarkeitsberechnung bei Wartung

Der Anbieter MUSS den Anteil des Ausfallzeitraumes, der innerhalb eines geplanten Ausfallszeitraumes zu einem genehmigten Wartungsfenster liegt, aus der Verfügbarkeitsberechnung ausschließen.

Hinweis: Fällt der Dienst vor oder nach einem genehmigten Wartungsfensters aus, so ist die Zeit außerhalb des Wartungsfensters als Ausfall in die Verfügbarkeitsberechnung des Dienstes mit einzubeziehen. [<=]

A_23616 - Performance - Verfügbarkeit - Anschluss an zentrales Netz - Hohe Verfügbarkeit

Die Anschlüsse aller Standorte des Anbieters an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen. [<=]

GS-A_4146-01 - Performance – Performance-Daten erfassen

Die Produkttypen der zentralen Zone der TI-Plattform und die Komponente AdV-Server der KTR-AdV  MÜSSEN in einem konfigurierbaren Zeitintervall Performance-Daten erfassen. Voreingestellt für das Zeitintervall sind 5 Minuten.

Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr].
[<=]

GS-A_4147-02 - Performance – Störungsampel – Performance-Daten

Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN die Performance-Reporting-Daten jeweils im Zeitintervall der Erfassung von Performance-Reporting-Daten an die Störungsampel senden.

Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr]. [<=]

GS-A_4148-01 - Performance – Störungsampel – Ereignisnachricht bei Ausfall

Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:

• Ein Dienst gilt als ausgefallen, wenn er 20 % oder mehr Anfragen nicht mehr erfolgreich verarbeiten kann.
  
• „Startzeitpunkt eines Ausfalls“ ist der frühest mögliche Zeitpunkt, zu dem das Erkennen des Ausfalls möglich ist.
  
• „Endzeitpunkt eines Ausfalls“ ist der frühest mögliche Zeitpunkt, zu dem das Erkennen des Endes eines Ausfalls möglich ist.
  
• „Versendezeitpunkt“ ist der Zeitpunkt, zu dem das erste Bit der Ereignisnachricht an die Störungsampel abgeschickt wird
  

A_14936 - Performance - Störungsampel - Ereignisnachricht bei Ausfall zentrale Dienste

Die Produkttypen OCSP-Proxy, TSP-X.509 Komp., TSL-Dienst, Namensdienst, Störungsampel, KSR, SG-Bestandsnetze, Zeitdienst, zentrales Netz und Verzeichnisdienst MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:

• Ein Dienst gilt als ausgefallen, wenn er 20 % oder mehr Anfragen nicht mehr anforderungskonform verarbeiten kann oder dieser Dienst für Anwender nicht erreichbar ist.
  
• „Startzeitpunkt eines Ausfalls“ ist der frühestmögliche Zeitpunkt, zu dem das Erkennen des Ausfalls möglich ist.
  
• „Endzeitpunkt eines Ausfalls“ ist der frühestmögliche Zeitpunkt, zu dem das Erkennen des Endes eines Ausfalls möglich ist.
  
• „Versendezeitpunkt“ ist der Zeitpunkt, zu dem das erste Bit der Ereignisnachricht an die Störungsampel abgeschickt wird.

GS-A_4149-01 - Performance – Reporting-Daten in Performance-Report

Die Produkttypen der zentralen Zone der TI-Plattform und die Komponenten AdV-Server der KTR-AdV MÜSSEN die Performance-Reporting-Daten ohne weitere Aggregation in den Performance-Report übernehmen.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr]. [<=]

A_17757-01 - Performance - Rohdaten-Performance-Lieferung - zu liefernde Dateien

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Berichten übermitteln, MÜSSEN jeweils zu jedem separat konfigurierbaren Berichtsintervall zwei Dateien senden:
- einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten [gemSpec_Perf#A_17755, A_17671, A_17668, A_19733-*]
und
- eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].

Beide Dateien MÜSSEN separat an die Betriebsdatenerfassung gemäß gemSpec_SST_LD_BD an die Schnittstelle I_OpsData_Update gesandt werden. [<=]

A_17755 - Performance - Rohdaten-Performance-Berichte - Name der Berichte

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:

<CI-ID>_<Start>_<Ende>_<Version der Datei>_<Dateityp>.<Endung>

• <CI-ID> = Identifiziert die Produktinstanz, siehe Anforderung [A_17764] in [gemRL_Betr_TI#6.1.1].
  
• <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC)
  
• <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten)
  
• <Version der Datei> = Im Normalfall "1". Wird jeweils um 1 hochgezählt bei Korrekturlieferung zu einer Datei
  
• <Dateityp>.<Endung> = "perf.log" / "inf.xml"
  
• perf.log = Performance Protokoll
  
• inf.xml = XML-Datei zur Selbstauskunft
  

A_17671 - Performance - Rohdaten-Performance-Berichte - Format des Performance-Berichts

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN den Bericht aufbereitet als UTF-8-kodierte Textdatei ohne ByteOrderMark übermitteln. Jede der in diesem Kapitel in den jeweiligen Tabellen definierten Operationsaufrufe MUSS in einem Eintrag erfasst werden. Die Einträge MÜSSEN durch Zeilenumbruch (LF = 0x0A) getrennt werden.
[<=]

A_17668-10 - Performance - Rohdaten-Performance-Berichte - Format der Einträge des Rohdaten-Performance-Berichts

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sämtliche Zeilen (Einträge) der Berichte in der folgenden Weise formatieren:

INFO: start[$timestamp] time[$duration_in_ms] tag[$operation] size[$size_in_kb] message[$message],

mit

• $timestamp eine Unixzeit-Zeitstempel in Millisekunden,
  
• $duration_in_ms die gemessene Bearbeitungszeit einer Operation in Millisekunden,
  
• $operation die ausgeführte Operation des Produkttyps gemäß Tabellen:
  
• • Tab_gemSpec_Perf_Berichtsformat_VSDM
  • Tab_gemSpec_Perf_Berichtsformat_SGD
• Wenn die Operation nicht fehlerfrei durchlaufen wurde, wird
  $operation = $operation + ".failed"  gesetzt
• $size_in_kb ist die gemessene, übertragene Datenmenge einer Operation in Kilobyte,
• $message dient der Gruppierung verschiedener Einträge zu einem fachlichen Anwendungsfall durch einen den einzelnen Anwendungsfall identifizierende Zeichenkette, welche selbst die Zeichen "[" und "]" nicht enthält. Wenn ein fachlicher Anwendungsfall durch einen einzelnen Eintrag abgebildet wird, entfällt "message[$message]".
• • Für die Operationen der Fachdienste VSDM (VSDD, CMS) muss hier die Conversation-ID eingefügt werden.

A_17678 - Performance - Rohdaten-Performance-Berichte - Übermittlung

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zur Übertragung der Reports die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.

Die Übermittlung des Rohdaten-Performance-Berichts MUSS pro CI (Configuration Item) erfolgen. 
[<=]

A_17679 - Performance - Rohdaten-Performance-Berichte - Berichtsintervall

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN das Berichtsintervall konfigurierbar gestalten.

[<=]

A_17756 - Performance - Rohdaten-Performance-Berichte - Korrektheit

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Berichte vollständig, zeitlich lückenlos (auch über Ausfälle hinweg) beginnend um 00:00:00 Uhr, überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden. "Intervalltreu" meint: Jeder Eintrag muss in dem Rohdaten-Performance-Bericht gesendet werden, in dessen Berichtsintervall sein Endezeitpunkt $timestamp + $duration_in_ms liegt.

[<=]

A_17758 - Performance - Rohdaten-Performance-Berichte - Frist für Nachlieferung

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, SOLLEN, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei in der geforderten Qualität bis zum Ende des folgenden Werktages nachliefern.
[<=]

A_22057 - Performance - Rohdaten - Verpflichtung des Anbieters (Rohdatenerfassung v.02)

Der Anbieter von Produkten, deren zugeordnete Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MUSS die Erfassung, Aufbereitung und Übermittlung der Rohdaten bezüglich Umfang, Lieferintervalle und Format gemäß der allgemeinen und spezifischen Anforderungen (Rohdatenerfassung v.02) gewährleisten. [<=]

A_22482 - Performance - Rohdaten - Erfassung von Rohdaten (Rohdatenerfassung v.02)

Der Produkttyp MUSS Performance-Rohdaten gemäß der Vorgaben zum Rohdaten-Performance-Reporting v.02 erfassen. [<=]

A_22002 - Performance - Rohdaten - Übermittlung (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zur Übertragung der Berichte die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.

Die Übermittlung des Rohdaten-Performance-Berichts MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen.  [<=]

A_22000 - Performance - Rohdaten - zu liefernde Dateien (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN folgende zwei Dateien in den jeweils individuell konfigurierbaren Berichtsintervallen senden:
- einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten
und
- eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].

Dabei MÜSSEN beide Dateien separat an die Betriebsdatenerfassung gesendet werden. [<=]

A_22429 - Performance - Rohdaten - Inhalt der Selbstauskunft (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, müssen bei der Erstellung der Selbstauskunft folgende inhaltliche Vorgaben berücksichtigen:

• "Produkttypbezeichnung" gem. gemKPT_Betr::Tab_gemKPT_Betr_Produkttypen::Spalte ID (PDT...) --> "ProductType"
• "kompatibilitätsrelevante Produkttypversion“ gem. gemSpec_OM  „ProductTypeVersion“
• "Hersteller-/Anbieter-ID“ (5 Zeichen-Kürzel von gematik Zulassung) gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductVendorID“
• "Produktkürzel“ (8 Zeichen-Kürzel nach Herstellerfestlegung)  gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductCode“
• "Produktversion" gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> "ProductVersion"
• "Herstellername /Anbietername" gem. gemSpec_OM::Tab_ZusAttr --> "ProductVendorName"
• "Produktname" gem. gemSpec_OM::Tab_ZusAttr --> "ProductName"

A_22004 - Performance - Rohdaten - Korrektheit (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Berichte vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden.  [<=]

A_22005 - Performance - Rohdaten - Frist für Nachlieferung (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei(en) in der geforderten Qualität bis zum Ende des folgenden Werktages (Mo-Fr ausgenommen bundeseinheitliche Feiertage) nachliefern. [<=]

A_22003-01 - Performance - Rohdaten - Nachlieferung auf Anforderung (Rohdatenerfassung v.02)

Anbieter, deren Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN auf Anforderung des Gesamtverantwortlichen TI eine erneute Lieferung/Nachlieferung der Rohdaten-Berichte bis zum 5. Werktag (Mo-Fr, ausgenommen bundeseinheitliche Feiertage) des auf dem Berichtszeitraum folgenden Monats ermöglichen. [<=]

A_22996 - Performance - Rohdaten - Zeitpunkte der Übermittlungen (Rohdatenerfassung v.02)

Der Anbieter, der zur Rohdatenlieferung verpflichtet ist, MUSS jede Lieferung der Rohdaten unverzüglich - spätestens innerhalb der 10 auf das Berichtsintervall folgenden Minuten - beginnen.
[<=]

A_21976 - Performance - Rohdaten - Konfigurierbarkeit der Lieferintervalle (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferintervalle der Berichtsdateien flexibel zwischen 1 Minute und 24 Stunden (1440 Minuten) mit einer Taktung von 1 Minute konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_22047 - Performance - Rohdaten - Änderung der Konfiguration der Lieferintervalle (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine Anpassung der Lieferintervalle der Berichtsdateien auf Aufforderung des Gesamtverantwortlichen TI ermöglichen. [<=]

A_22620 - Performance - Rohdaten - Umsetzungszeit für Änderung der Lieferintervalle (Rohdatenlieferung v.02)

Der Anbieter, dessen Produkt zur Umsetzung der Rohdatenerfassung v.02 verpflichtet ist, MUSS die Änderung der Konfiguration der Lieferintervalle (gemäß A_22047) innerhalb von 5 Werktagen (Mo - Fr, ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_21978 - Performance - Rohdaten - Trennung der Lieferintervalle (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine voneinander getrennte Anpassung der Lieferintervalle für die Lieferungen von Rohdaten-Performance-Berichten, Selbstauskünften und ggf. weiteren Lieferungen (z.B. Bestandsdatenlieferung) ermöglichen. [<=]

A_21975 - Performance - Rohdaten - Default-Werte für Lieferintervalle (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN - sofern nicht explizit spezifiziert - folgende Lieferintervalle als Standardeinstellung voreinstellen:

• Rohdaten-Performance-Berichte: 5-minütig.
• Selbstauskunft: 60-minütig.

A_21979 - Performance - Rohdaten - Bezug der Lieferverpflichtung (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sich bei der Lieferung der Berichtsdateien ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]

A_21980 - Performance - Rohdaten - Leerlieferung (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferung der Berichtsdateien gemäß des konfigurierten Lieferintervalls leisten, auch wenn im dazugehörigen Berichtsintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist der Rohdaten-Performance-Bericht mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. Für die Selbstauskunft ergibt sich daraus keine Besonderheit, sodass diese wie definiert zu übertragen ist. [<=]

A_22001-01 - Performance - Rohdaten - Name der Berichte (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:

<CI-ID>_<Start>_<Ende>_<Dateityp>.<Endung>

• <CI-ID> = identifiziert die Produktinstanz, siehe Anforderung [A_17764] in [gemRL_Betr_TI#6.1.1].
  
• <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC).
  
• <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten).
  
• <Dateityp>.<Endung> = "perf.log" / "inf.xml"
  
• • perf.log = Performance Protokoll
    
  • inf.xml = XML-Datei zur Selbstauskunft.

A_21981-02 - Performance - Rohdaten - Format des Rohdaten-Performance-Berichtes (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung folgende Konventionen erfüllen:
Diese Produkttypen:

• MÜSSEN ein CSV-Format mit den Feldern

• MÜSSEN das Semikolon ";" als Feldtrennzeichen verwenden.
• DÜRFEN das Feldtrennzeichen innerhalb der CSV-Felder NICHT inhaltlich verwenden.
• DÜRFEN Feldinhalte NICHT quotieren.
• DÜRFEN Feldinhalte weggelassen, sofern diese Produkttyp- oder operationsbedingt entfallen können, was ggf. zu direkt aufeinanderfolgenden Semikola führt.
• MÜSSEN UTF-8 Zeichensatzkodierung ohne ByteOrderMark verwenden.
• MÜSSEN CR-LF-Zeilenumbrüche (ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed)) verwenden.
• DÜRFEN Kommentierungen NICHT verwenden.
• DÜRFEN leeren Zeilen NICHT verwenden.
• DÜRFEN Tausendertrennzeichen NICHT verwenden.
• DÜRFEN einen CSV-Header NICHT verwenden.
• MÜSSEN Leerzeichen am Rand der Feldinhalte entfernen, sofern diese nicht intendiert sind, da sie nicht automatisch ignoriert werden.

A_22500-01 - Performance - Rohdaten - Status-Block (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard-Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.

Tabelle 3: Tab_gemSpec_Perf_Standard-Statuscodes 

A_21982-01 - Performance - Rohdaten - Message-Block (Rohdatenerfassung v.02)

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]

A_22513-01 - Performance - Rohdaten - Message-Block im Fehlerfall (Rohdatenerfassung v.02)

Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln, wenn - im Fehlerfall oder aus einem anderen Grund - die für die Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) notwendigen Informationen nicht vorliegen.
(anstelle von key ist der entsprechende Key-Wert des Key-Value-Paares einzutragen; << und >> dienen nur der Abgrenzung)
[<=]

A_25259 - Ereignisdaten - Lieferung mittels TLS

Der Anbieter MUSS die Lieferungen von Sensordaten TLS-verschlüsselt nach GS-A_4384-03 durchführen. [<=]

A_25278 - Ereignisdaten - Authentifizierung via OAuth 2.0

Der Anbieter MUSS einen "OAuth 2.0 client credentials grant flow" in Abstimmung mit der gematik implementieren.
[<=]

A_25260 - Ereignisdaten - Lieferung mittels OAuth 2.0

Der Anbieter MUSS bei der Lieferung von Sensordaten das angebotene Zugangsverfahren zum Sensorik-Endpunkt auf Basis von OAuth 2.0 [RFC6749] umsetzen. [<=]

A_25261 - Ereignisdaten - Zeitpunkt der Lieferung

Der Anbieter MUSS nach der vollständigen Verarbeitung spezifizierter Ereignisse, die erforderlichen Daten unmittelbar an den Sensorik-Endpunkt versenden. [<=]

A_25262 - Ereignisdaten - Verhalten bei fehlgeschlagener Lieferung und Retry

Der Anbieter MUSS bei einer fehlgeschlagenen Ereignislieferung an den Sensorik-Endpunkt einen Retry-Mechanismus (z.B. Exponential Backoff) implementieren, um die Ereignislieferung nachzuholen.
Diese Nachlieferung wird nur bei folgenden Return-Codes des Sensorik-Endpunktes notwendig:

HTTP Error-Code	Nachlieferung notwendig
400	Nein
401	Nein
403	Nein
404	Nein
406	Nein
411	Nein
413	Nein
429	Nein
500	Nein
502	Ja

Eine Nachlieferung kann nach 5 Minuten ohne Erfolg, verworfen werden. Das Verwerfen von Ereignislieferungen MUSS im Applikationslog protokolliert werden.
[<=]

A_25263 - Ereignisdaten - Format der Lieferung

Der Anbieter MUSS bei der Ereignislieferung folgende Konventionen vollständig erfüllen:

• HTTP-Aufruf konform mit [RFC7231]
• Content-Encoding: erfolgt produktspezifisch
• Content-Type: application/json
• Ausschließliche Nutzung von POST-Requests
• Spezieller POST-Body nach spezifiziertem Schema
• die URL "https://<host>:<port><path>/" im POST Request wird von der gematik vorgegeben.
• keep-alive: max. 600 Sekunden
• Request Timeout: max. 120 Sekunden

A_25264 - Ereignisdaten - Format der Lieferung - POST-Body - Integervalidierung

Der Anbieter MUSS bei der Ereignislieferung im POST-Body gewährleisten, dass alle als Integer gekennzeichneten Werte als ganzzahlige Integer im POST-Body zu berücksichtigen sind und diese DÜRFEN NICHT als String übertragen werden.

Hinweis: Die Quotierung von Integerwerten z.B. 1234 und die damit einhergehende Typänderung zu String "12345" ist unzulässig.
[<=]

A_22532 - Überlastabwehr des Produktes

Der Produkttyp KANN bei einer erhöhten Anfragelast von mehr als 20 Authorization-Requests innerhalb von 5 Minuten pro "client_id" und anfragender IP-Adresse weitere Anfragen dieser Quelle mit dem HTTP-Statuscode "429 - Too Many Requests" ablehnen. [<=]

A_22227-02 - Performance – IDP-Dienst – Bearbeitungszeit unter Last

Der Produkttyp IDP-Dienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_IDP-Dienst erfüllen.

Es wird davon ausgegangen, dass der IDP-Dienst eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator (Challenge) bis zum Eintreffen der Antwort (Response) nicht zur Bearbeitungszeit. Die Dauer für die OCSP-Anfrage ist jedoch berücksichtigt.

Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.

Tabelle 6: Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben

A_22226 - Performance – Sektoraler Identity Provider – Bearbeitungszeit unter Last

Der Anbieter eines sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Sek_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß [A_22225].
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.

Tabelle 7: Tab_gemSpec_Perf_sek_IDP: Bearbeitungszeitvorgaben

A_22833 - Performance – Sektoraler Identity Provider in der Föderation – Bearbeitungszeiten unter Last

Der Anbieter des sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_sektoraler_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß [A_22225].
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.

Tabelle 8: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben

A_20243 - Performance - IdP-Dienst - Robustheit gegenüber Lastspitzen

Der IdP-Dienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_IdP-Dienst: Bearbeitungszeitvorgaben" verfügbar bleiben. [<=]

A_20153 - Performance - IdP-Dienst - Anzahl paralleler Sessions - TI

Der Produkttyp IdP-Dienst MUSS mindestens 95.000 gleichzeitige Sessions für Leistungserbringer unterstützen.
[<=]

A_20154 - Performance - IdP-Dienst - Anzahl paralleler Sessions - Internet

Der Produkttyp IdP-Dienst MUSS mindestens 2.400.000 gleichzeitige Sessions für Versicherte unterstützen.
[<=]

A_22225 - Definition Marktanteil (MA) des Anbieters einer Anwendung oder eines Dienstes

Der Anbieter MUSS entsprechend seines Marktanteils (MA) Performancevorgaben und Service Level erfüllen. Der Marktanteil ist der numerische Wert zwischen 1,00 und 0,01 [ohne Einheit, zwei Nachkommastellen, aufgerundet], der den Anteil der eigenen Kunden des Anbieters im Verhältnis zur Gesamtnutzerzahl repräsentiert. Die Gesamtnutzerzahl ist die Zahl aller Versicherten (privat + gesetzlich) oder die Anzahl aller Leistungserbringer und Leistungserbringerinstitutionen, die diese Anwendung nutzen. [<=]

A_22228 - Performance - Sektoraler Identity Provider - Anzahl paralleler Sessions - Internet

Der Anbieter eines sektoralen Identity Provider MUSS mindestens 25.000 x MA gleichzeitige Sessions für Versicherte unterstützen. MA ist der Marktanteil des Anbieters gemäß [A_22225].
[<=]

A_20244 - Performance - IdP-Dienst - Skalierung

Der Betreiber des IdP-Dienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
[<=]

A_19730-01 - Georedundanz des IdP-Dienstes

Der Anbieter des IdP-Dienstes MUSS diesen Dienst an mindestens zwei Standorten, die mindestens 50km jeweils voneinander entfernt sind, betreiben. Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
[<=]

A_19718-01 - Performance – IdP-Dienst – Verfügbarkeit

Der Produkttyp IdP-Dienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,99 % und zur Nebenzeit eine Verfügbarkeit von 99,97 % haben.
Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]

A_22357-03 - Verfügbarkeit sektoraler IDP

Der Anbieter des sektoralen IDP MUSS sein Produkttyp so betreiben, dass es zur Hauptzeit mindestens eine Verfügbarkeit von 99,90 % und zur Nebenzeit eine Verfügbarkeit von 99,00 % hat.
Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit. [<=]

A_22048-01 - Performance - Rohdaten - Übermittlung bei dislozierten CIs (Rohdatenerfassung v.02)

Der Anbieter KANN die Übermittlung der Rohdaten-Performance-Berichte in Absprache mit dem Gesamtverantwortlichen TI je Standort vollziehen, wobei diese Standorte dann eindeutig identifizierbar sein müssen, sofern das Configuration Item (CI) über mehrere Standorte verteilt ist. [<=]

A_22013-04 - Performance - Rohdaten - Spezifika IDP-Dienst - Operation/Duration (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "operation" und "duration_in_ms" die Angabe aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Produkttyp: IDP-Dienst

Tabelle 9: Tab_gemSpec_Perf_Berichtsformat_IDP

A_22944 - Performance - Rohdaten - Spezifika föderierter IDP - Message (Rohdatenerfassung v.02)

Der Produkttyp MUSS - bei Rohdaten-Performance-Berichten folgende Parameter im JSON-Format übermitteln:
       {"cv": "$client_version"}

Für "$client_version" ist die Produktversion zum korrespondierenden Authenticator-Modul zu verwenden.

• <Produktversion> im Format "H.N.U-P": Hauptnummer, Nebennummer, Unternummer, Patchlevel (jeweils Integer)

A_22015-01 - Performance - Rohdaten - Spezifika IDP - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation/des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp IDP-Dienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

Tabelle 10: Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst

A_22826 - Performance - Rohdaten - Spezifika sektoraler IDP - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation/des Use Case ein Fehler aufgetreten ist, MUSS der Produkttyp sektoraler IDP bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_sektoraler_IdP festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

Tabelle 11: Tab_gemSpec_Perf_Fehlercodes_sektoraler_IDP

A_22825-01 - Performance - Rohdaten - Spezifika sektoraler IDP - Operation/Duration (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "operation" und "duration_in_ms" die Angaben aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Produkttyp: sektoraler Identity Provider 
Schnittstelle: Internet

Tabelle 12: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP

A_24339 - Aufbereitung Fachdienst Client-ID als cidi für Rohdatenlieferung

Für die Erfassung der Rohdaten werden automatisiert verarbeitbare Informationen zum beim sektoralen IDP anfragenden Fachdienst benötigt. Zu diesem Zweck MUSS der sektorale IDP einen CRC-32 Hashwert aus der Client-ID (dem iss-claim aus dem Entity Statement des Fachdienstes) erstellen und diesen Wert in den Rohdaten im Parameter cidi verwenden. [<=]

A_22504 - Performance - Rohdaten - Spezifika IDP - Feldtrennzeichen im Useragent (Rohdatenerfassung v.02)

Der Produkttyp MUSS, sofern vom Client irrtümlicherweise im Useragent-Wert das verbotene Feldtrennzeichen ";"  übertragen wurde, dieses ";" gegen das Zeichen "┼" austauschen und in der Rohdatenlieferung senden.
(siehe: A_21981: Feldtrennzeichen  ";"
Das Zeichen  ┼   ist definiert gem.  Unicode U+253C (9532) - BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL - ALT-Code 197)
[<=]

A_21340-01 - IDP- Abbruch bei OCSP-Timeout

Der Produkttyp IdP-Dienst MUSS nach einer konfigurierbaren Wartezeit von 1100 msec auf die Antwort des OCSP den Vorgang abbrechen und diesen Abbruch gemäß [gemSpec_Perf#A_22015] und [Tab_gemSpec_Perf_Fehlercodes#"OCSP_ERROR_NO_RESPONSE"] in den Rohdaten protokollieren.
[<=]

A_22016-02 - Performance - Rohdaten - Spezifika IDP-Dienst Message Versionsinformation, ClientID und Error-Codes (Rohdatenerfassung v.02)

Der Produkttyp IDP-Dienst MUSS bei Rohdaten Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen:

{ "cid": "$clientid", "ua": "$useragent", "err": $errorCode }

• $clientid: <Client-ID> Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String
• $useragent: <User-Agent> gemäß Anforderungslage für Clientsysteme am Fachdienst [A_24060], Datentyp String
• $errorCode: <Error-Code> der entsprechende 4-stellige Fehlercode, Datentyp Integer 
  

A_24060-01 - Performance - Rohdaten - Spezifika IDP - Robustheitsprüfung UserAgent (Rohdatenerfassung v.02)

Der Produkttyp IDP-Dienst MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"- Felder den UserAgent auf die folgenden gültigen Zeichen überprüfen und bei Verstößen die Anfrage mit dem http-Status Code "400" bzw. im Falle eines "302" mit einem Error Code ablehnen. Der UserAgent muss dem folgenden Regular Expression entsprechen:

^[\w\.\/\s\-\(\)\&\%\;\[\]\+\<\>\#\?\@\:\,]+$

A_23213 - Registrierungsbestandsdaten - sektoraler IDP

Der sektorale IDP MUSS die Registrierungsinformationen jeweils täglich zur betriebsarmen Abendzeit vor 24:00 Uhr im JSON Format [gemäß A_23236] als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern.

Hinweis:
"Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig." [<=]

A_23236-04 - Format der Registrierungsinformationen des IDP

Der sektorale IDP MUSS bei der Lieferung der Registrierungsinformationen folgendes Format verwenden:

{   
"abfragezeitpunkt": "<Zeitstempel der Abfrage als String im ISO 8601 Format>",   
"ci": "<logische CI-ID des abgefragten IDP gemäß TI-ITSM; als String>",   
"dailyUser":<Anzahl der Nutzer aller Mandanten, die den IDP einmal pro Tag nutzen; als Integer>,   
"powerUser":<Anzahl der Nutzer aller Mandanten, die den IDP mehr als einmal pro Tag nutzen; als Integer>,   
"bestand":{
                 "oaf":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren Online-Ausweisfunktion des neuen Personalausweises,
                             des elektronischen Aufenthaltstitels oder der EU-Bürgerkarte>,
                 "pif":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren POSTIDENT Filiale>
               }
}

Hinweise:
Im Bestand wird die Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer übermittelt.
Nur tatsächlich verwendete Elemente (Identifizierungsverfahren <idV> wie oaf, egk, pif, kkg, bot, not, apo, ...) müssen innerhalb der Werteliste [ ] aufgeführt werden. Im Muster sind hier nur oaf und pif aufgeführt - bitte um die verwendeten Verfahren entsprechend ergänzen.
Weitere Ident-Verfahren werden hier bekanntgegeben:
https://fachportal.gematik.de/fileadmin/Fachportal/Smartcards_in_der_TI/Festlegung_Identifikationsverfahren_V1.0.pdf 

Die Anzahl der "powerUser" wird auch in der Anzahl der "dailyUser" mit erfasst. [<=]

A_20165-07 - Performance – E-Rezept-Fachdienst - Bearbeitungszeit unter Last

Der Produkttyp E-Rezept-Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

Tabelle 15 Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben

A_20166 - Performance - E-Rezept-Fachdienst - Robustheit gegenüber Lastspitzen

Der E-Rezept Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben.
[<=]

A_19737 - Performance E-Rezept-Fachdienst - Skalierung

Der Anbieter des E-Rezept Fachdienstes MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
[<=]

A_19736-02 - Performance - E-Rezept-Fachdienst - Verfügbarkeit

Der Anbieter E-Rezept-Fachdienst MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit: 99,99%
• Nebenzeit: 99,97%

A_19735-02 - Performance - Erfassung von Rohdaten - E-Rezept-Fachdienst

Der Produkttyp E-Rezept-Fachdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefern. [<=]

A_19734 - Performance - Lieferung von Rohdaten - E-Rezept-Fachdienst

Der Anbieter E-Rezept-Fachdienst MUSS das Produkt E-Rezept-Fachdienst so konfigurieren, dass dieses in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte und die Datei zur Selbstauskunft automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefert. Voreingestellt für das Zeitintervall ist 60 Minuten. [<=]

A_22975 - Performance - Rohdaten-Performance-Bericht - Konfiguration pseudonymisierte Werte der Telematik-ID

Der Produkttyp E-Rezept-Fachdienst MUSS eine Konfiguration unterstützen, welche die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen ein- bzw. abschaltet. 
[<=]

A_22976 - Performance - Rohdaten-Performance-Bericht - Steuerung Konfiguration pseudonymisierte Werte der Telematik-ID

Der Anbieter des E-Rezept-Fachdienstes MUSS die Konfiguration für die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen entsprechend den Vorgaben der gematik vornehmen. [<=]

A_23088 - Performance - Rohdaten - Spezifika E-Rezept - Operation (Rohdatenerfassung v.02)

Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "operation" die Angabe der Spalte "$FD-operation" aus Tabelle [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] berücksichtigen.
Sollte die Operation des inneren Requests nicht ermittelt werden können, so ist stattdessen für das Feld "operation" der Wert "ERP.VAU" zu verwenden. [<=]

A_23089 - Performance - Rohdaten - Spezifika E-Rezept - Status (Rohdatenerfassung v.02)

Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "status" die Angabe der Spalte "HTTP-Status-Code" gemäß A_19514-* aus [gemSpec_FD_eRp] berücksichtigen.  [<=]

A_23090-02 - Performance - Rohdaten - Spezifika E-Rezept - Message (Rohdatenerfassung v.02)

Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "cid": "$clientid", "ua": "$useragent", "leip": "$leipseudonym", "size": $size, "bkdur": $backendduration, "mvonr": $mvo-nummer, "vnr": $vorgangsnummer, "anr": $anrvalue, "zanr": $zanrvalue}

• $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String
• $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String
• $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String
• $size: Größe des Requests in kilobyte, Datentyp Integer
• $backendduration: Zeit in ms für Abfragen an OCSP oder analogen Backendsystemen, Datentyp Integer
• $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer
• $vorgangsnummer: Task-ID im Fachdienst, Datentyp String
• $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer
• $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer 

A_23091 - Performance - Rohdaten - Spezifika E-Rezept - Duration (Rohdatenerfassung v.02)

Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]

A_22520-01 - Performance – E-Rezept-Fachdienst - Bestandsdaten

Der Anbieter E-Rezept-Fachdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den E-Rezept-Fachdienst berichten:

• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Ready gestaffelt nach FlowType
• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Inprogress gestaffelt nach FlowType
• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Completed gestaffelt nach FlowType
• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Cancelled gestaffelt nach FlowType
• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Ready mit einem Tag vor der Löschfrist (Task.expiryDate > 9 Tage) gestaffelt nach FlowType
• Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Inprogress mit einem Tag vor der Löschfrist (lastmodified > 99 Tage) gestaffelt nach FlowType
  

A_22521-01 - Performance - E-Rezept-Fachdienst - Lieferweg und Format für Bestandsdaten

Der Anbieter E-Rezept-Fachdienst MUSS die Informationen aus [A_22520] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [A_23110] mit Einschränkungen* liefern:

{ 
"abfragezeitpunkt": <Zeitstempel der Abfrage als String im Format ISO 8601>,
"ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
"ready": {  

A_23116 - TI-M Fachdienst Verfügbarkeit (Produkt)

Der TI-Messenger-Fachdienst MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von mindestens 99,8 % betreibbar sein. [<=]

A_23117-01 - TI-M Fachdienst Verfügbarkeit (Anbieter)

Der Anbieter TI-Messenger MUSS sein Produkt TI-Messenger-Fachdienst mit einer vollumfänglich-funktionalen Verfügbarkeit von 99,8% in der Hauptzeit und 99,0 % in der Nebenzeit betreiben.
Die Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Zeiten gelten als Nebenzeit.

Wenn der Betrieb von Homeservern on-premise bei den Nutzern realisiert wird, KANN der Anbieter TI-Messenger für diese Produktinstanzen von den Performancevorgaben in Abstimmung mit seinen Kunden abweichen. Die Abweichungen und die betroffenen Instanzen bzw. Komponenten MÜSSEN im Betriebshandbuch für jeden on-premise Betrieb dokumentiert werden.
[<=]

A_24043 - Performance - Rohdaten - Spezifika Fachdienst TI-M - Duration (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst TI-Messenger MUSS bei Rohdaten-Performance-Berichten die Inhalte des Feldes "duration_in_ms" nach den Vorgaben der Tabelle [Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3] entsprechend der Spalten "Start der Messung" und "Ende der Messung" für die jeweilige TIM-Operation befüllen. [<=]

A_24044 - Performance - Rohdaten - Spezifika Fachdienst TI-M - Operation (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst TI-Messenger MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "operation" gemäß A_21981-02, die Angabe entsprechend der Spalte "$TIM-Operation" aus [Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3] befüllen. [<=]

A_22940-01 - Performance - Rohdaten - Spezifika TI-M Message (Rohdatenerfassung v.02)

Das Produkt SOLL - bei Rohdaten-Performance-Berichten im "message"-Feld – folgende Informationen im JSON-Format übermitteln:

{
"Inst-ID":$Instanz-ID,
"UA-PTV": $UA-Produkttypversion,
"UA-PV": $UA-Produktversion,
"UA-A": $UA-Auspraegung,
"UA-P": $UA-Plattform,
"UA-OS": $UA-OS,
"UA-OSV": $UA-OS-Version,
"UA-cid": $UA-client_id,
"M-Dom":$Matrix-Domain,
"sizeIn":$sizeIn,
"sizeOut":$sizeOut,
"tID":$telematikID,
"profOID":$professionOID,
"Res":$response
}

Für $Instanz-ID ist eine für jede Instanz eines Anwendungsfalls entsprechend [gemSpec_TI-Messenger-Dienst] gleichbleibende ID einzutragen.
Die Instanz-ID SOLL somit für die jeweiligen Operationen bzw. Teilschritte innerhalb einer Instanz eines Anwendungsfalls gleich vergeben werden. "Instanz" bezieht sich hierbei auf die Instanziierung des Anwendungsfalls, nicht die physische Instanz des Messenger-Services o.ä.
Für Felder beginnend mit "UA-" sind die entsprechenden Werte einzutragen, welche vom Client (User-Agent) übermittelt werden. Falls die Anfrage für den Teilschritt des Anwendungsfalls von einem Matrix-Server ausgeht (Server-Server API), sind die Bezeichner mit "UA-" weiterhin aufzuführen und mit dem Wert "n/a" zu befüllen.
Für $UA-Auspraegung sind ausschließlich die Werte "Org-Admin-Client" und "Messenger-Client" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-Plattform sind ausschließlich die Werte "mobil", "stationaer", "web" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-OS ist das entsprechende Betriebssystem einzutragen, z.B. Windows, iOS, MacOS, Android, GNU/Linux.
Für $UA-OS-Version ist die Version des Betriebssystems einzutragen.
Für $UA-client_id ist die client_id einzutragen wie sie auch dem zentralen IDP-Dienst bzw. TI-Messenger Fachdienst IdP übermittelt wird.
Für $Matrix-Domain ist die eigene Matrix-Domain des Messenger-Services einzutragen.
Für $sizeIn ist das eingehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für $sizeOut ist das ausgehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für die $telematikID ist die telematikID der zur Domäne zugehörigen SMC-B einzutragen.
Für die $professinoOID ist die professionOID der zugehörigen SMC-B einzutragen.
Für die $response ist der Statuscode als Rückmeldung der entsprechenden Anwendungsfälle einzutragen.

Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]

A_23119-02 - TI-Messenger Fachdienst Bestandsdaten

Der TI-Messenger-Fachdienst MUSS die nachfolgenden Informationen täglich in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD] liefern:

{

• uaList: Das Array MUSS mit Werten entsprechend ihrer Beschreibung befüllt werden. Es DÜRFEN NUR neue Kombinationen der Attribute übermittelt werden, welche zuvor noch nicht übermittelt wurden.
• $uaKen: Datentyp String, SHA1 (Base64-kodiert). Für $ua_ken MUSS die mit SHA1 kodierte Kennung einer bestimmten Client-Ausprägung in Synchronisation mit A_22940 eingetragen werden. Die Kennung MUSS eindeutig für jede einzigartige Kombination der User-Agent Attribute vergeben werden.*
• $uaPtv: Datentyp String. Für $ua-Produkttypversion MUSS die Produkttypversion des TI-Messenger Clients eingetragen werden.
• $uaPv: Datentyp String. Für $ua-Produktversion MUSS die Produktversion des TI-Messenger Clients eingetragen werden.
• $uaAus: Datentyp String. Für $ua-Auspraegung MUSS die Ausprägung des Clients entsprechend der Spezifikation eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "Org-Admin-Client" oder "Messenger-Client" verwendet werden.
• $uaPlat: Datentyp String. Für $ua-Plattform MUSS die Plattform des Clients eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "mobil", "stationaer" oder "web" verwendet werden.
• $uaOsv: Datentyp String. Für $ua-OSv MUSS das entsprechende Betriebssystem mit der Version eingetragen werden. Zum Beispiel "Windows 10 Enterprise", "iOS 16.6", "macOS Ventura 13.5.1", "Android 13", "Ubuntu 22.04 LTS" etc.
• $uaCid: Datentyp String. Für $ua-client_id MUSS die client_id eingetragen werden wie sie auch dem TI-Messenger Fachdienst gemäß A_23104 übermittelt wird.
• afList: Das Array enthält alle Teilschritte aller Anwendungsfälle die am Fachdienst erfasst werden MÜSSEN. Die Keys MÜSSEN alle exakt wie dargestellt übermittelt werden. Die erfasste Anzahl an Aufrufen je Teilschritt (inkl. Fehler) MUSS für $anzahl als Wert (Integer) übermittelt werden. Wenn ein Teilschritt in einem Zeitintervall nicht registriert wurde, MUSS der Wert 0 eingetragen werden.
• $md: Datentyp String. Für $md MUSS die eigene Matrix-Domain des Messenger-Services eingetragen werden, wie sie auch in der Föderationsliste hinterlegt ist.

A_24324 - Performance - OCSP Responder der TSP X.509 - Grundlast

Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES - HBA, TSP-X.509 nonQES - eGK und TSP-X.509 nonQES - SMC-B MÜSSEN die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSPX509 unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]

A_24325 - Performance - OCSP Responder der TSP X.509 - Bearbeitungszeiten unter Spitzenlast

Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES - HBA, TSP-X.509 nonQES - eGK und TSP-X.509 nonQES - SMC-B MÜSSEN die Bearbeitungszeitvorgaben unter der für alle Funktionen parallel anliegenden Spitzenlast dauerhaft erfüllen. Die dabei geltende Spitzenlast pro Funktion wird aus Tabelle Tab_gemSpec_Perf_OCSP_Responder_TSPX509 wie folgt abgeleitet:

• Last für Zertifikate zu HBA und SMC-B = Anzahl der herausgegebenen Karten mit zeitlich noch gültigen Zertifikaten in Tausend / 210 * Spitzenlastwert aus Tabelle Tab_gemSpec_Perf_OCSP_Responder
  
• Last für Zertifikate zu eGK: Anzahl der herausgegebenen Karten mit zeitlich noch gültigen Zertifikaten in Millionen / 70 * Spitzenlastwert aus Tabelle Tab_gemSpec_Perf_OCSP_Responder

A_22489 - Performance - Rohdaten - Spezifika TSP X.509 - Duration (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]

A_22490 - Performance - Rohdaten - Spezifika TSP X.509 - Operation (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]

A_22491 - Performance - Rohdaten - Spezifika TSP X.509 - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_TSP-X.509 festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

Tabelle 20: Tab_gemSpec_Perf_Fehlercodes_TSP-X.509

A_22492 - Performance - Rohdaten - Spezifika TSP X.509 - Message (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die Rückgabewerte der Abfrage des Sperrstatus der jeweiligen X.509 Zertifikate im JSON-Format übermitteln:
       {"Sperrstatus":"$status"}
Für $status ist der entsprechende Sperrstatus-Wert gemäß Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509 einzutragen, welcher für das jeweilige Zertifikat ermittelt wurde.

Tabelle 21: Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509

A_22957 - Performance – FedMaster – Verfügbarkeit

Der Anbieter des Federation Master MUSS sein Produkt so betreiben, dass es zur Hauptzeit und zur Nebenzeit mindestens eine Verfügbarkeit von 98,40 % hat.
Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
Hauptzeit des Produkttyps ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]

A_22950 - Performance – FedMaster – Bearbeitungszeit unter Last

Der Produkttyp Federation Master MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_FedMaster erfüllen.
Es wird davon ausgegangen, dass der Federation Master eingeschwungen ist und z.B. Verbindungen nicht neu ausgehandelt werden.
Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 10 Anfragen pro Sekunde zu erbringen.

Tabelle 22: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben

A_23386 - Performance - Rohdaten - Spezifika FedM - Operation (Rohdatenerfassung v.02)

Der Anbieter des Federation Master MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe aus der Tabelle 'Tab_gemSpec_Perf_FedMaster' in der Spalte "ID" verwenden.

A_23489 - Performance - Rohdaten - Spezifika FedM - Duration (Rohdatenerfassung v.02)

Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die konkretisierenden Hinweise unter der
Tabelle Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben berücksichtigen. [<=]

A_23387 - Performance - Rohdaten - Spezifika FedM - Message (Rohdatenerfassung v.02)

Der Anbieter des Federation Masters MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"-Felder - den Useragent im JSON-Format übermitteln:
       {"UA":"$requesting_party"}

Für $requesting_party ist MemberID des entsprechend registrierten IDP oder Fachdienst einzutragen.

Hinweis:
Die MemberID wird durch die gematik vergeben.
[<=]

GS-A_4168 - Performance – VPN-Zugangsdienst – Bearbeitungszeit

Der VPN-Zugangsdienst MUSS eine Laufzeit der IP-Pakete zwischen der Schnittstelle zum Transportnetz Internet und der Schnittstelle zum Zentralen Netz der TI von unter 20 ms aufweisen.

Der VPN-Zugangsdienst MUSS eine Laufzeit der IP-Pakete zwischen der Schnittstelle zum Transportnetz Internet und der Schnittstelle zum Internet über den SIS von unter 20 ms aufweisen.

A_24814 - Performance - VPN Zugangsdienst - Verfügbarkeit I_NTP_Time_Information

Der Produkttyp VPN-Zugangsdienst MUSS eine Verfügbarkeit von 99 % mit einer maximalen Ausfalldauer von 24 Stunden für die Schnittstelle I_NTP_Time_Information haben. [<=]

GS-A_4170-01 - Performance – VPN-Zugangsdienst – Bandbreite

Der VPN-Zugangsdienst MUSS eine Anbindungsbandbreite an das zentrale Netz mit der folgenden Eigenschaft bereitstellen:

• mindestens eine symmetrische Bandbreitenanbindung von 100 Mbit/sec
  

A_23610 - Performance – VPN-Zugangsdienst – Bandbreite - VPN-Konzentratoren

Der VPN-Zugangsdienst MUSS eine Anbindungsbandbreite ab VPN-Konzentrator in das interne Netz mit folgenden Eigenschaften bereitstellen:

• mindestens eine Bandbreitenanbindung der "Summe aus der Spitzenlastsumme gemäß Tab_gemSpec_Perf_Netzlast_1" mal Anzahl der registrierten und diesem Standort zugeordneten Konnektoren geteilt durch Gesamtanzahl der Konnektoren gemäß gemSpec_Perf#M21.  

GS-A_5510 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS

Der Produkttyp VPN-Zugangsdienst MUSS eine Anbindung zum Transportnetz von mindestens 1 Gbit/sec pro 10000 Konnektoren besitzen.

Die VPN-Konzentratoren für SIS und TI MÜSSEN einen IPSec-Durchsatz unterstützten, der sich aus der Transportnetzanbindung ergibt.
[<=]

GS-A_5545 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS Konfigurationseinstellungen

Der Produkttyp VPN-Zugangsdienst DARF den IPSec-Durchsatz der VPN-Konzentratoren pro Konnektor NICHT durch Konfigurationseinstellungen reduzieren.

GS-A_5015 - Performance – VPN-Zugangsdienst – Volumenmessung im SIS

Der SIS des VPN-Zugangsdienstes der TI-Plattform MUSS das Volumen der übertragenen Daten getrennt nach Richtung zum Internet und vom Internet erfassen.

A_23911 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Status (Rohdatenerfassung v.02)

Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Fehlercodes_VPN-ZugD berücksichtigen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
[<=]

A_23222 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Operation (Rohdatenerfassung v.02)

Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD berücksichtigen. [<=]

A_23221-01 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Duration (Rohdatenerfassung v.02)

Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten den Wert des "duration_in_ms"-Feldes in folgender Weise berücksichtigen:
Bei Aufruf der Operation beginnt die Messung mit Annahme der Aufrufnachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht.
[<=]

A_23220-02 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Message (Rohdatenerfassung v.02)

Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:

{ "cn": "$commonName", "sn": "$serialNumber", "o": "$organizationName", "c": "$countryName", "ip" : "$IP-Address", "s" : "$source" }

• $commonName = Feld <subject:commonName> gemäß gemSpec_PKI#Tab_PKI_245 (FQDN des Zugangsdienstes)
• $serialNumber = Feld <subject:serialNumber> gemäß gemSpec_PKI#Tab_PKI_245 (Seriennummer zur Unterscheidung gleichartiger Instanzen)
• $organizationName = Feld <subject:organizationName> gemäß gemSpec_PKI#Tab_PKI_245 (Name des Zugangsdienstanbieters)
• $countryName = Feld <subject:countryName> gemäß gemSpec_PKI#Tab_PKI_245 (Land der Anschrift des Zugangsdienstanbieters)
• $IP-Address = IP-Adresse der bearbeitenden Fachdienstinstanz
• $source = Quellregion des Operationsaufrufs

A_23497 - Performance - Spezifika VPN-Zugangsdienst - Bestandsdaten

Der Anbieter VPN-Zugangsdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den VPN-Zugangsdienst pro Standort berichten:

• übertragene Datenmenge in beide Richtungen am SZZP pro Standort
• Anzahl der registrierten Konnektoren gesamt
• Anzahl aktiver Verbindungen pro Standort

A_23498 - Performance - Spezifika VPN-Zugangsdienst - Lieferweg und Format für Bestandsdaten

Der Anbieter VPN-Zugangsdienst MUSS die Informationen aus  pro Standort, jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format an die Betriebsdatenerfassung (BDE)
gemäß [gemSpec_SST_LD_BD::] liefern: 

{
    "ci": "<CI ID der logischen Produktinstanz des VPN-Zugangsdienstes gemäß TI-ITSM als String>",
    "szzp": "<SZZP_ID des VPN-Zugangsdienstes als String>",
    "timestamp": "<Zeitstempel der Abfrage als String im ISO 8601 Format als String>",
    "numKon": <Gesamtanzahl der registrierten Konnektoren pro obiger CI ID zum Abfragezeitpunkt als Integer>,
    "numVPN": <Gesamtanzahl der bestehenden VPN-Tunnel pro obiger SZZP_ID zum Abfragezeitpunkt als Integer>,
    "start": "<Startzeitstempel des Berichtsintervall im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
      startend mit 00:00 Uhr UTC als geschlossener Intervallanfang, d.h. t_Messung ist größer GLEICH diesem Wert>",
    "stop": "<Stopzeitstempel des Berichtsintervalls im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
      startend mit 00:05 Uhr UTC als offenes Intervallende, d.h. t_Messung ist kleiner diesem Wert>",
    "kbIn": <Datenmenge empfangen in Kilobyte an obiger SZZP_ID im oben definierten Berichtsintervall als Integer>,
    "kbOut": <Datenmenge gesendet in Kilobyte an obiger SZZP_ID im oben definierten Berichtsintervall als Integer>

A_23067 - Performance - NCPeH-Fachdienst - Messung von Bearbeitungszeiten

Der NCPeH-Fachdienst MUSS die folgenden Bedingungen einhalten:

Vorbedingungen für die Messungen
Es wird davon ausgegangen, dass nach einem Login-Prozess alle Verbindungsaufbauten erfolgten und zugehörige OCSP-Statusauskünfte im OCSP-Cache vorliegen.

Rahmenbedingungen für die Messung
Die dem NCPeH-Fachdienst zugerechneten Bearbeitungszeiten für die entsprechende Schnittstelle ist die Zeitspanne vom vollständigen Empfang eines Requests bis zum vollständigen Ausgang der zugehörigen Response.

Die dem NCPeH-Fachdienst zugerechneten Bearbeitungszeiten für die Schnittstelle FindIdentityByTrait sind die Antwortzeiten für einen Request-Response Zyklus. Hierbei muss das Warten auf die erfolgreiche Nutzerinteraktion (ad-hoc Berechtigung) rausgerechnet werden.
[<=]

A_23016 - Performance - NCPeH-Fachdienst - Last- und Bearbeitungszeiten

Der NCPeH-Fachdienst SOLL die Bearbeitungszeitrichtwerte unter Last aus Tabelle "Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

Tabelle 25 Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben

A_22979 - Performance - NCPeH-Fachdienst - Verfügbarkeit

Der Betreiber des NCPeH-Fachdienstes MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

Wartungsfenster MÜSSEN vollständig in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

Die Anschlüsse aller Standorte an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen. [<=]

A_23017 - Performance - NCPeH-Fachdienst - Skalierung

Der Betreiber des NCPeH-Fachdienstes MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]

A_23011 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Operation (Rohdatenerfassung v.02)

Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_NCPeH berücksichtigen. [<=]

A_23012 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Duration (Rohdatenerfassung v.02)

Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]

A_23013 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung des Usecase ein Fehler aufgetreten ist, MUSS der NCPeH-Fachdienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gemäß Kapitel 6.4 "eHealth DSI Error Codes" [NCPeH Components Specifications], Table 2-4 festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden und das Feld "eCode" im message-Block mit der Fehleridentifikation befüllt werden. [<=]

A_23118-01 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Message (Rohdatenerfassung v.02)

Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "reqc": "$requestingCountry", "ecode": "$errorCode" }

• requestingCountry: Zeichenkette zur Identifikation des anfragenden NCPeHs eines EU-Mitgliedsstaates im Format ISO 3166-1 Alpha 2, Datentyp String.
• errorCode: Zeichenkette zur Identifikation der Fehlermeldung aus dem Response-Body. Datentyp String. Inhalt:
• des Feldes "Code" aus der Struktur "AcknowledgementDetail" für XCPD.
• des Feldes "errorCode" aus der Struktur "RegistryError" für XCA.

A_18018-01 - Performance - Signaturdienst - Spitzenlastvorgaben

Der Anbieter Signaturdienst MUSS das System so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle Tab_gemSpec_Perf_Signaturdienst: Last- und Bearbeitungszeitvorgaben erfüllt wird. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl der gesetzlich Versicherten.

Tabelle 27: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben

A_17802 - Performance – Signaturdienst – Bearbeitungszeit unter Last

Der Produkttyp Signaturdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Signaturdienst erfüllen.

A_22476 - Performance - Rohdaten - Spezifika SigD - Duration (Rohdatenerfassung v.02)

Der Produkttyp Signaturdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_SigD berücksichtigen. [<=]

A_22478 - Performance - Rohdaten - Spezifika SigD - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation ein Fehler aufgetreten ist, MUSS der Produkttyp Signaturdienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_SigD festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

Tabelle 28: Tab_gemSpec_Perf_Fehlercodes_SigD

A_22479 - Performance - Rohdaten - Spezifika SigD - Message (Rohdatenerfassung v.02)

Der Produkttyp Signaturdienst DARF bzgl. des "message"-Feldes KEINE Inhalte übermitteln. [<=]

A_22477-01 - Performance - Rohdaten - Spezifika SigD - Operation (Rohdatenerfassung v.02)

Der Produkttyp Signaturdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "Operation" und "Duration" die Angaben der Tabelle Tab_gemSpec_Perf_Berichtsformat_SigD berücksichtigen.

Tabelle 29: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

A_20135 - Performance - KOM-LE-Fachdienst - Skalierung

Der Anbieter KOM-LE-Fachdienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]

A_20129 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben

Der Anbieter KOM-LE-Fachdienst MUSS das System so dimensionieren, dass für seine Nutzer der erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben" erfüllt werden. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl aller KOM-LE-Teilnehmer.
[<=]

A_20127-01 - Performance - KOM-LE-Fachdienst – Spitzenlastvorgaben für den KAS

Der Anbieter KOM-LE-Fachdienst MUSS den KAS und die Anbindung an das zentrale Netz der TI mindestens so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS" erfüllt wird.

Die Lastvorgaben sind für die vom Anbieter definierte maximale Größe der Zulässigen 20 MiB Anhänge zu erfüllen

Tabelle 31: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS

A_20134 - Performance - KOM-LE-Fachdienst - Robustheit gegenüber Lastspitzen

Der KOM-LE Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus den Tabellen:

• "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben",
• "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS" verfügbar bleibt

A_20132 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben TU

Der Anbieter KOM-LE MUSS in der TU-Umgebung 5% der in den folgenden Tabellen:

• "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben",
• "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS"

GS-A_5139-02 - Performance – KOM-LE-Fachdienst – Verfügbarkeit

Der Produkttyp Fachdienst KOM-LE MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit: 99,80%
• Nebenzeit: 99,00%

GS-A_5143-01 - Performance – KOM-LE-Fachdienst – Nachricht senden

Der KOM-LE-Fachdienst MUSS die vom KOM-LE-Clientmodul empfangenen E-Mails zeitnah an den KOM-LE-Fachdienst des E-Mail-Empfängers weiterleiten.

Der KOM-LE-Fachdienst des E-Mail-Senders MUSS sicherstellen, dass der Zeitraum zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE-Clientmodul an den KOM-LE-Fachdienst des E-Mail-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE-Fachdienst des E-Mail-Empfängers kleiner 10 Minuten ist.
[<=]

A_24042 - Performance - KOM-LE Fachdienst - Nachrichtenversand binnen 10 Minuten

Der Produkttyp Fachdienst KOM-LE MUSS auch über Ausfälle hinweg gewährleisten, dass Nachrichten spätestens 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen. [<=]

GS-A_5138-02 - Performance – KOM-LE-Fachdienst – TLS-Verbindungsaufbau unter Last

Der Produkttyp Fachdienst KOM-LE MUSS erreichen, dass der TLS-Verbindungsaufbau, unter der für diesen Anwendungsfall gemäß Tabelle Tab_gemSpec_Perf_KOMLE_Fachdienst anliegenden Spitzenlast, im Mittel innerhalb von 3,9 Sekunden abgeschlossen wird. [<=]

A_20133 - Performance - KOM-LE-Fachdienst - Anbindungsbandbreite

Der Anbieter des KOM-LE-Fachdienstes MUSS die Bandbreite seiner Schnittstelle zum zentralen Netz der TI entsprechend der zu erwartenden Last auslegen. Die Auslastung der effektiven Bandbreite darf nicht dauerhaft über 90% der gewählten Anbindungsbandbreite liegen.
[<=]

A_23823 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Status (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "status" die Angabe der Spalte "$status" gemäß Tab_gemSpec_Perf_Berichtsformat_KIM_neu berücksichtigen. [<=]

A_23168 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Operation/Duration (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten die Inhalte der Felder "$operation" und "$duration_in_ms" nach den Vorgaben der Tabelle Tab_gemSpec_Perf_Berichtsformat_KIM befüllen. [<=]

A_23167 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Message (Rohdatenerfassung v.02)

Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "mid": "$messageid", "size": "$size", "err": "$fehlermeldung", "dir": "$direction", "sys": "$senderName", "sysv": "$senderVersion", "dka": "$dienstAnw", "dkt": "$dienstTyp","dkv": "$dienstVer","cmn": "$cmName", "cmv": "$cmVersion", "cptv": "$cmPTVersion", "ksize": "$kasSize", "konpn": "$konProductName","konpt": "$konProductType","konptv": "$konProductTypeVersion","konhw": "$konHWVersion","konfw": "$konFWVersion" }
Diese message-Felder MÜSSEN immer mitgegeben werden:

• messageid: <Message-ID> Zeichenkette zur Identifikation der KIM Nachricht, Datentyp String
  
• size: <Request Size> Größe des Requests in kilobyte, Datentyp Integer
  
• fehlermeldung: <X-KIM-Fehlermeldung> nach A_20771-01, Datentyp String
  
• direction: <Direction> Entweder "CM" für die Kommunikation mit einem Clientmodul (CM) ODER "FD" für die Kommunikation zwischen Fachdiensten, Datentyp String
  

• senderName: <X-KIM-Sendersystem:PS-Name> Name des Sendersystems, Datentyp String
• senderVersion: <X-KIM-Sendersystem:PS-Version> Version des Sendersystems, Datentyp String
• dienstAnw: <X-KIM-Dienstkennung:Anwendung> Name der Anwendung zur Dienstkennung, Datentyp String
• dienstTyp: <X-KIM-Dienstkennung:Nachrichten-Typ> Nachrichten-Typ zur Dienstkennung, Datentyp String
• dienstVer: <X-KIM-Dienstkennung:Anwendungsversion> Anwendungsversion zur Dienstkennung, Datentyp String
• cmName: <X-KIM-CMVersion:Name> Name des eingesetzten KOM-LE Clientmoduls, Datentyp String
• cmVersion: <X-KIM-CMVersion:Version> Version des eingesetzten KOM-LE Clientmoduls, Datentyp String
• cmPTVersion: <X-KIM-PTVersion> Produkttyp-Version des eingesetzten KOM-LE Clientmoduls, Datentyp String
• kasSize: <X-KIM-KAS-Size> Größe der KOM-LE-Nachricht in kilobyte, Datentyp Integer
• konProductName: <X-KIM-KONVersion:Productname> nach A_21388-01, Datentyp String
• konProductType: <X-KIM-KONVersion:ProductType> nach A_21388-01, Datentyp String
• konProductTypeVersion: <X-KIM-KONVersion:ProductTypeVersion> nach A_21388-01, Datentyp String
• konHWVersion: <X-KIM-KONVersion:HWVersion> nach A_21388-01, Datentyp String
• konFWVersion: <X-KIM-KONVersion:FWVersion> nach A_21388-01, Datentyp String

GS-A_5545-01 - Performance – TI-Gateway-Zugangsmodul – VPN Konfigurationseinstellungen

Der Produkttyp TI-Gateway-Zugangsmodul KANN den VPN-Durchsatz pro Leistungserbringerumgebung auf die vertraglich vereinbarte Bandbreite reduzieren. [<=]

A_23431-01 - Performance – TI-Gateway – Verfügbarkeit

Der Anbieter TI-Gateway MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit:  99,90 %
• Nebenzeit: 99,00 %

A_23433-01 - Performance - TI-Gateway - Skalierung

Der Anbieter für das TI-Gateway MUSS für seine Produkttypen skalierbar sein.
Diese Skalierbarkeit ist durch den Anbieter nachvollziehbar darzustellen, wie die Skalierung im Produktivbetrieb erreicht wird. 
[<=]

A_23269 - Performance - Rohdaten - TI-Gateway-Zugangsmodul - Duration (Rohdatenerfassung v.02)

Der Produkttyp TI-Gateway-Zugangsmodul MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul berücksichtigen. [<=]

A_23270 - Performance - Rohdaten - TI-Gateway-Zugangsmodul - Operation (Rohdatenerfassung v.02)

Der Produkttyp TI-Gateway-Zugangsmodul MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul berücksichtigen. [<=]

A_23988-01 - Performance - Spezifika TI-Gateway - Bestandsdaten

Der Anbieter TI-Gateway MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über das TI-Gateway berichten:

• Anzahl der registrierten Highspeed-Konnektor Instanzen gesamt
• Anzahl aktiver Verbindungen
• Anzahl gesperrter Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat)

A_23989-01 - Performance - Spezifika TI-Gateway - Lieferweg und Format für Bestandsdaten

Der Anbieter TI-Gateway MUSS die Informationen aus ,
jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format an die Betriebsdatenerfassung (BDE)
gemäß [gemSpec_SST_LD_BD::] liefern: 

{
    "ci": "<CI ID der logischen Produktinstanz des TI-Gateway-Zugangsmodul gemäß TI-ITSM als String>",
    "timestamp": "<Zeitstempel der Abfrage als String im ISO 8601 Format als String>",
    "numHSKInst": <Gesamtanzahl der registrierten Highspeed-Konnektor Instanzen pro obiger CI ID zum Abfragezeitpunkt als Integer>,
    "numVPN": <Gesamtanzahl der bestehenden VPN-Tunnel zum Abfragezeitpunkt als Integer>,
    "numLockAccess":<Gesamtanzahl gesperrter Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat) zum Abfragezeitpunkt als Integer>, 
    "start": "<Startzeitstempel des Berichtsintervall im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
      startend mit 00:00 Uhr UTC als geschlossener Intervallanfang, d.h. t_Messung ist größer GLEICH diesem Wert>",
    "stop": "<Stopzeitstempel des Berichtsintervalls im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
      startend mit 00:05 Uhr UTC als offenes Intervallende, d.h. t_Messung ist kleiner diesem Wert>"    
} [<=]

GS-A_4162 - Performance – Namensdienst – Bearbeitungszeit unter Last

Der Produkttyp Namensdienst und der Produkttyp VPN-Zugangsdienst MÜSSEN die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Namensdienst unter der für alle Funktionen parallel anliegenden Spitzenlast an den DNS-Schnittstellen erfüllen.
[<=]

A_23436 - Performance - Rohdaten - Spezifika Namensdienst - Operation (Rohdatenerfassung v.02)

Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Namensdienst berücksichtigen. [<=]

A_23435 - Performance - Rohdaten - Spezifika Namensdienst - Duration (Rohdatenerfassung v.02)

Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des "duration_in_ms"-Feldes die Angabe der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Namensdienst berücksichtigen. [<=]

A_23920 - Performance - Rohdaten - Spezifika Namensdienst - Message (Rohdatenerfassung v.02)

Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln: 

{ "ip": "$IP-Adresse" }

• $IP-Adresse = IP-Adresse der Instanz des Namensdienstes, Datentyp String

A_23921 - Performance - Rohdaten - Spezifika Namensdienst - Status (Rohdatenerfassung v.02)

Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_Namensdienst berücksichtigen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden. [<=]

GS-A_5073 - Performance – Intermediär VSDM – Skalierbarkeit

Anbieter für den VSDM Intermediär MÜSSEN für ihren Produkttypen nachvollziehbar darstellen, wie die für ihren Produkttyp erforderliche Skalierung bis zum vollständigen bundesweiten Rollout erreicht werden kann.
[<=]

GS-A_5029-01 - Performance – VSDM Intermediär – Bearbeitungszeit unter Last

Der Produkttyp Intermediär MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Intermediaer erfüllen. Die dabei zu unterstützende Spitzenlast pro Sekunde berechnet sich aus der durch die VSDM-Intermediär-Instanz maximal zu unterstützende Anzahl an Leistungserbringern in Tausend multipliziert mit dem Faktor 5,35.

Die Vorgaben beziehen sich auf die einzelnen Request-Response-Zyklen. Sie beinhalten die Bearbeitungszeitbeiträge aus Request und Response in Summe. Es wird davon ausgegangen, dass der Intermediär eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.

Für die Zulassung ist der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.

Tabelle 38 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben

GS-A_5030 - Performance – VSDM Intermediär – Verfügbarkeit

Der Produkttyp Intermediär MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.

Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]

A_20170 - Performance - Erfassung von Rohdaten - Intermediär VSDM

Der Intermediär VSDM MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM" erfassen und Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitinervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]

A_23256 - Performance - Rohdaten - Spezifika Intermediär VSDM - Operation (Rohdatenerfassung v.02)

Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation / Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM berücksichtigen. [<=]

A_23253 - Performance - Rohdaten - Spezifika Intermediär VSDM - Duration (Rohdatenerfassung v.02)

Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten des "duration_in_ms"-Feldes in folgender Weise berücksichtigen: Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Fachmodul, wird mit der Weiterleitung an den Fachdienst pausiert, läuft mit Erhalt der Antwort vom Fachdienst weiter und endet mit dem Versand der Antwort an das Fachmodul. [<=]

A_23750-01 - Performance - Rohdaten - Spezifika Intermediär VSDM - Message (Rohdatenerfassung v.02)

Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:

{ "vnum": $vorgangsnummer, "ik": "$InstanzKennung", "bkdur": $backendDuration }

• $vorgangsnummer = Vorgangsnummer gem. VSDM-A_2673 max. 12 Zeichen, Datentyp String
• $instanzKennung = Instanz-Kennung max. 8 Zeichen, Datentyp String
• $backendDuration = Zeit in ms, die mit der Weiterleitung der Nachricht an den Fachdienst beginnt und mit dem Erhalt der Antwort vom Fachdienst endet, Datentyp Integer

A_24070 - Performance - Rohdaten - Spezifika Intermediär VSDM - Status (Rohdatenerfassung v.02)

Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes alle HTTP-Statuscodes, die vom Fachdienst generiert und vom Intermediär VSDM an das Fachmodul weitergeleitet werden, als SUCCESS bewerten.
Vom Intermediär VSDM selbst generierte Fehlermeldungen MÜSSEN gemäß A_22500-01 einen HTTP-Statuscode aus der Statuscodegruppe CLIENT_ERROR (HTTP-Statuscodes 4xx) oder SERVER_ERROR (HTTP-Statuscodes 5xx) verwenden und werden als FAILED_OTHER bewertet. [<=]

A_24326 - Performance - OCSP Responder der TSP X.509nQ - Komp - Grundlast

Der Produkttyp TSP-X.509 nonQES - Komp MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]

A_14502 - Performance – CRL-Dienst – Last und Parallele Downloads

Der TSP-X.509 nonQES für Komponenten MUSS die Vorgaben an Last und Anzahl der parallelen Downloads aus Tab_gemSpec_Perf_CRL-Dienst garantieren. [<=]

A_18013 - Performance – TSP – Provisioning/Revocation – Bearbeitungszeit

Der Produkttyp TSP-X.509nonQES der Komponenten-PKI MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_Provisioning_Revocation bei den dort angegebenen parallelen Requests erfüllen. [<=]

A_23533 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Operation (Rohdatenerfassung v.02)

Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp berücksichtigen. [<=]

A_24045 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Operation im Fehlerfall (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist und dadurch keine eindeutige Zuordnung zu einem Usecase gem. Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp Spalte "Operation / Usecase" möglich ist, MUSS der Produkttyp TSP X.509 nonQES – Komp bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes den Usecase TSPK.UC_13 verwenden. [<=]

A_23532 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Duration (Rohdatenerfassung v.02)

Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten des "duration_in_ms"-Feldes in folgender Weise berücksichtigen: Die Messung beginnt mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. [<=]

A_23725 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Message (Rohdatenerfassung v.02)

Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:

{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp", "cc": $certCount }

• $protocol= "ECC" | "RSA" | "WEB" | "SOAP" | "CMP" als String
• $result= "GOOD" | "REVOKED" | "UNKNOWN" als String
• $zertifikatstyp = Zertifikatstyp aus Tab_gemSpec_Perf_Berichtsformat_TSP X.509 nonQES – Komp als String
• $certCount = Anzahl der angefragten Zertifikate innerhalb eines Requests als Integer

A_23751 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSP X.509 nonQES – Komp bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Statuscodes_TSP_X.509_nonQES_Komp festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden. [<=]

A_23901 - Performance – TSP CVC– Provisioning – Bearbeitungszeit

Der Produkttyp TSP CVC MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_CVC bei den dort angegebenen parallelen Requests erfüllen. [<=]

A_24159 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Operation (Rohdatenerfassung v.02)

Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes die Angabe der Spalte "Operation / Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy berücksichtigen. [<=]

A_24158 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Duration (Rohdatenerfassung v.02)

Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. des "duration_in_ms"-Feldes die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy berücksichtigen. [<=]

A_24160 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Status (Rohdatenerfassung v.02)

Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_OCSP-Responder-Proxy berücksichtigen, sofern ein spezifischer Statuscode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]

A_24161 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Message (Rohdatenerfassung v.02)

Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "bkdur": $backendDuration, "zOcsp": "$ziel-ocsp" }

• $backendDuration = Zeit in ms für Abfragen an den Ziel-OCSP im Internet, Datentyp Integer
• $ziel-ocsp = OCSP-gematik-ID des Ziel-OCSP im Internet basierend auf der Zuordnungstabelle Tab_gemSpec_Perf_OCSP-Responder-Proxy_Ziel-URLs, Datentyp String

A_24327 - Performance - OCSP Responder des TSL-Dienstes - Grundlast

Der Produkttyp TSL-Dienst MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]

GS-A_4854 - Performance – TSL-Dienst – Last und Parallele Downloads

Der Produkttyp TSL-Dienst MUSS die Vorgaben an Last und Anzahl der parallelen Downloads aus Tab_gemSpec_Perf_TSL-Dienst garantieren. Die Download-Dateien müssen während des Download-Transports komprimiert sein, wobei ein Komprimierungsverfahren für alle Dateitypen zu verwenden ist, das Textdateien mindestens um einen Faktor 3 komprimiert.
[<=]

GS-A_4158-01 - Performance – TSL-Dienst – Verfügbarkeit

Der TSL-Dienst MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
• Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
• Alle übrigen Stunden der Woche sind Nebenzeit.

• Hauptzeit: 99,90%
• Nebenzeit: 99,00%

A_24169 - Performance - Rohdaten - Spezifika TSL-Dienst - Operation (Rohdatenerfassung v.02)

Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst berücksichtigen. [<=]

A_24168 - Performance - Rohdaten - Spezifika TSL-Dienst - Duration (Rohdatenerfassung v.02)

Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst berücksichtigen. [<=]

A_24170 - Performance - Rohdaten - Spezifika TSL-Dienst - Status (Rohdatenerfassung v.02)

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSL-Dienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Statuscodes_TSL-Dienst festlegen, sofern ein spezifischer Statuscode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]

A_24171 - Performance - Rohdaten - Spezifika TSL-Dienst - Message (Rohdatenerfassung v.02)

Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:

{ "prot": "$protocol", "res": "$result", "url": "$usedURL" }

• $protocol= Genutzter Schlüsselalgorithmus des angefragten Zertifikates, Datentyp String
• $result= Sperrstatus des angefragten Zertifikates gemäß GS-A_4690, Datentyp String
• $usedURL = "Returned Value" aus der Tabelle Tab_gemSpec_Perf_TSL-Dienst_URLs basierend darauf, welche URL der Konnektor oder Dienst zum Download der jeweiligen Datei genutzt hat, Datentyp String

A_24328 - Performance - OCSP Responder der gematik Root-CA - Grundlast

Der Produkttyp gematik Root-CA MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_gematik-Root-CA unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]