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 der Ausfallzeit, der innerhalb einer geplanten Ausfallzeit innerhalb eines genehmigten Wartungsfensters liegt, von der Verfügbarkeitsberechnung ausschließen.

Hinweis: Fällt der Dienst vor oder nach einem genehmigten Wartungsfenster 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. [<=]

A_26151 - Redundanz - Lokale Redundanz

Der Anbieter MUSS sicherstellen, dass bei Ausfall eines funktionalen Elements die Gesamtverfügbarkeit gemäß der definierten Performancevorgaben in [gemSpec_Perf] weiterhin gegeben ist.
Dazu nutzt der Anbieter beispielsweise die Verteilung der Komponenten auf Brandabschnitte des selben Standorts. Es soll dadurch das Risiko ausgeschlossen oder vermindert werden, dass lokale Beeinträchtigungen zu einem Ausfall oder verminderter Leistungskapazität führen. [<=]

A_26152 - Redundanz - Standortübergreifende Redundanz

Der Anbieter MUSS sicherstellen, dass bei Ausfall eines funktionalen Elements oder einer übergreifenden Störung an einem Standort die Gesamtverfügbarkeit gemäß der definierten Performancevorgaben in [gemSpec_Perf] weiterhin gegeben ist.
Dazu nutzt der Anbieter einen zweiten Standort, welcher in der Lage ist, die geforderten Anforderungen gemäß [gemSpec_Perf] eigenständig zu gewährleisten. Es soll dadurch das Risiko ausgeschlossen oder vermindert werden, dass übergreifende Beeinträchtigungen eines Standortes zu einem Ausfall oder verminderter Leistungskapazität führen. [<=]

A_26186 - Redundanz - Wiederherstellungszeitraum - 5 Tage

Der Anbieter MUSS sicherstellen, dass bei einer Störung (die nicht über Maßnahmen gemäß [gemRL_Betr_TI#A_26014-*] verhindert wurden), das betroffene System und seine Daten innerhalb von fünf Arbeitstagen vollständig wiederhergestellt werden. Die Maßnahmen zur Wiederherstellung MÜSSEN unter Berücksichtigung der geltenden Sicherheitsanforderungen vorgenommen werden. [<=]

TIP1-A_6437-01 - Performance - Datenlieferungen - Aufbewahrungsfrist

Der Anbieter MUSS Datenlieferungen an die gematik mindestens 6 Monate lang aufbewahren. 

A_22057 - Performance - Betriebsdatenlieferung - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Betriebsdaten gemäß der allgemeinen und spezifischen Anforderungen gewährleisten. [<=]

A_22482 - Performance - Betriebsdatenlieferung - Erfassung von Betriebsdaten

Der Produkttyp MUSS Betriebsdaten gemäß der Vorgaben erfassen. [<=]

A_17757-01 - Performance - Betriebsdatenlieferung v1 - zu liefernde Daten

Der Produkttyp MUSS jeweils zu jedem Lieferintervall zwei Dateien senden:
- eine Betriebsdatenlieferung v1 gemäß [A_17755], [A_17671], [A_17668-*] ff.
und
- eine Datei zur "Selbstauskunft" gemäß Kapitel "Selbstauskunft Version 1" im XML-Format [ProductInformation.xsd].
Beide Dateien MÜSSEN separat an den Endpunkt der Betriebsdatenerfassung v1, gemäß [gemSpec_SST_LD_BD] Schnittstelle I_OpsData_Update, gesandt werden. [<=]

A_17755 - Performance - Betriebsdatenlieferung v1 - Dateiname

Der Produkttyp MUSS beim Dateinamen der Lieferungen 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 Lieferintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC)
  
• <Ende> = Endezeitpunkt des Lieferintervalls 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 - Betriebsdatenlieferung v1 - Format der Datei

Der Produkttyp MUSS die Betriebsdatenlieferung 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 - Betriebsdatenlieferung v1 - Format der Einträge

Der Produkttyp MUSS sämtliche Zeilen (Einträge) der Betriebsdatenlieferung 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
  
• 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]".

A_17678 - Performance - Betriebsdatenlieferung v1 - Übermittlung

Der Produkttyp MUSS zur Übertragung der Datenlieferungen die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.
Die Übermittlung der Betriebsdaten MUSS pro CI (Configuration Item) erfolgen.  [<=]

A_17679 - Performance - Betriebsdatenlieferung v1 - Lieferintervall

Der Produkttyp MUSS das Lieferintervall der Datenlieferung konfigurierbar gestalten. [<=]

A_17756 - Performance - Betriebsdatenlieferung v1 - Korrektheit

Der Produkttyp MUSS die Datenlieferungen 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 der Betriebsdatenlieferung gesendet werden, in dessen Lieferintervall sein Endzeitpunkt $timestamp + $duration_in_ms liegt. [<=]

A_17758 - Performance - Betriebsdatenlieferung v1 - Frist für Nachlieferung

Der Produkttyp SOLL, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei in der geforderten Qualität bis zum Ende des folgenden Werktages nachliefern. [<=]

A_22001-02 - Performance - Betriebsdatenlieferung v2 - Dateiname der Lieferung

Der Produkttyp MUSS für die Übermittlung der Datei zur Betriebsdatenlieferung beim Dateinamen folgende Konventionen umsetzen:
<CI-ID>_<Start>_<Ende>_perf.log

• <CI-ID> = identifiziert die Produktinstanz, gemäß [A_17764] in [gemRL_Betr_TI].
  
• <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)

A_22002 - Performance - Betriebsdatenlieferung v2 - Übermittlung

Der Produkttyp MUSS zur Übertragung der Betriebsdatenlieferung die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.
Die Übermittlung der Betriebsdatenlieferung MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen.  [<=]

A_22004 - Performance - Betriebsdatenlieferung v2 - Korrektheit

Der Produkttyp MUSS die Lieferung vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden.  [<=]

A_22005 - Performance - Betriebsdatenlieferung v2 - Frist für Nachlieferung

Der Produkttyp MUSS, 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 - Betriebsdatenlieferung v2 - Nachlieferung auf Anforderung

Der Anbieter MUSS auf Anforderung der gematik eine Nachlieferung der Betriebsdaten bis zum 5. Werktag (ausgenommen bundeseinheitliche Feiertage) des auf dem Lieferzeitraum folgenden Monats ermöglichen. [<=]

A_22996 - Performance - Betriebsdatenlieferung v2 - Zeitpunkte der Übermittlungen

Der Anbieter MUSS jede Lieferung der Betriebsdaten unverzüglich - spätestens innerhalb der 10 auf das Lieferintervall folgenden Minuten - beginnen. [<=]

A_21976 - Performance - Betriebsdatenlieferung v2 - Konfigurierbarkeit der Lieferintervalle

Der Produkttyp MUSS 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 - Betriebsdatenlieferung v2 - Änderung der Konfiguration der Lieferintervalle

Der Produkttyp MUSS eine Anpassung der Lieferintervalle von Betriebsdatenlieferungen ermöglichen. [<=]

A_22620 - Performance - Betriebsdatenlieferung v2 - Umsetzungszeit für Änderung der Lieferintervalle

Der Anbieter MUSS die Anpassung der Lieferintervalle gemäß [A_22047] innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_21975-01 - Performance - Betriebsdatenlieferung v2 - Default-Wert des Lieferintervalls

Der Produkttyp MUSS den Lieferintervall von 5 Minuten als Standardeinstellung nutzen. [<=]

A_21979 - Performance - Betriebsdatenlieferung v2 - Bezug der Lieferverpflichtung

Der Produkttyp MUSS sich bei der Betriebsdatenlieferung ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]

A_21980-01 - Performance - Betriebsdatenlieferung v2 - Leerlieferung

Der Produkttyp MUSS die Lieferung gemäß des konfigurierten Lieferintervalls gewährleisten, auch wenn im dazugehörigen Lieferintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist die Datei zur Betriebsdatenlieferung mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. [<=]

A_21981-02 - Performance - Betriebsdatenlieferung v2 - Format

Der Produkttyp MUSS bei der Erstellung der Datenlieferung folgende Konventionen umsetzen:
Die Datei:

• MUSS ein CSV-Format mit den Feldern

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

A_22500-01 - Performance - Betriebsdatenlieferung v2 - Status-Block

Der Produkttyp MUSS im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard_Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.

Tabelle 4: Tab_gemSpec_Perf_Standard_Statuscodes

A_21982-01 - Performance - Betriebsdatenlieferung v2 - Message-Block

Der Produkttyp MUSS bei der Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]

A_22513-02 - Performance - Betriebsdatenlieferung v2 - Message-Block im Fehlerfall

Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln oder das gesamte Key-Value-Paar entfernen, sofern die - im Fehlerfall oder aus einem anderen Grund - für die Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) notwendigen Informationen nicht vorliegen. [<=]

GS-A_3702 - Inhalt der Selbstauskunft von Produkten außer Karten

Alle Produkte der TI (mit Ausnahme der Karten) MÜSSEN eine Selbstauskunft mit folgenden Inhalten besitzen:

• Die Selbstauskunft MUSS die vollständige Produktidentifikation (siehe [GS-A_3700] bzw. [GS-A_5025]) beinhalten.
  
• Die Selbstauskunft MUSS den Produkttyp und die kompatibilitätsrelevante Produkttypversion beinhalten.
  
• Sofern der Produkttyp eine Systemuhr besitzt, MUSS die Selbstauskunft das Abfragedatum (einschl. Uhrzeit) beinhalten.
  
• Die Selbstauskunft KANN weitere Versionsinformationen für Komponenten enthalten, aus denen sich das Produkt zusammensetzt (z. B. Betriebssystem, Datenbanksystem, Patches, Service Packs). Hierbei KANN die Anordnung der Knoten gemäß ihrer Abhängigkeits- bzw. Teilerelation (d. h. in Baumdarstellung) erfolgen.
  

A_26174 - Performance - Selbstauskunft - Verpflichtung zur Erfassung

Der Produkttyp MUSS notwendige Metadaten für die Lieferung einer Selbstauskunft erfassen und verarbeiten. [<=]

A_26175 - Performance - Selbstauskunft - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Daten zur Selbstauskunft gewährleisten. [<=]

A_26176 - Performance - Selbstauskunft - Lieferintervall

Der Produkttyp MUSS die Selbstauskunft in einem konfigurierbaren Lieferintervall senden. Sofern nicht explizit anders spezifiziert, ist das Lieferintervall von 60 Minuten als Default-Wert zu nutzen. [<=]

A_26177 - Performance - Selbstauskunft - Konfigurierbarkeit des Lieferintervalls

Der Produkttyp MUSS die Lieferintervalle der Selbstauskunft flexibel zwischen 1 Minute und 1440 Minuten (24 Stunden) konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls

Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß A_26177*) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_26173 - Performance - Selbstauskunft v1 - Format und Übermittlung

Der Produkttyp MUSS notwendige Metadaten für die Selbstauskunft gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd] erfassen, verarbeiten und an die Schnittstelle I_OpsData_Update der Betriebsdatenerfassung gemäß [gemSpec_SST_LD_BD] versenden. [<=]

A_26179 - Performance - Selbstauskunft v1 - Dateiname der Lieferung

Der Produkttyp MUSS beim Dateinamen folgende Konvention umsetzen:
<CI-ID>_<Start>_<Ende>_inf.xml

• <CI-ID> = identifiziert die Produktinstanz, gemäß [A_17764] in [gemRL_Betr_TI].
  
• <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).

A_22429 - Performance - Selbstauskunft v1 - Inhalt

Der Produkttyp MUSS 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_26181 - Performance - Selbstauskunft v2 - Format und Übermittlung

Der Produkttyp MUSS notwendige Metadaten für die Selbstauskunft im JSON-Format gemäß A_26180 erfassen, verarbeiten und an die Schnittstelle I_OpsData_Update der Betriebsdatenerfassung gemäß [gemSpec_SST_LD_BD] versenden. [<=]

A_26180 - Performance - Selbstauskunft v2 - Inhalt

Der Produkttyp MUSS folgende Werte für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

GS-A_4095-02 - Performance - Ad-hoc-Reports - Lieferverpflichtung

Anbieter MÜSSEN einen, von der gematik angeforderten, Ad-hoc-Report über die benannte Kommunikationsschnittstelle gemäß [gemRL_Betr_TI#GS-A_4085] im korrekten Format gemäß [GS-A_5608-01] und im benannten Zeitfenster, spätestens jedoch nach 7 Kalendertagen, übermitteln. [<=]

GS-A_5608-01 - Performance - Ad-hoc-Reports - Format

Anbieter MÜSSEN bei der Übermittlung von Ad-hoc-Reports an die gematik folgende Regelungen beachten:

• Der Betreff einer E-Mail ist immer der Dateiname der in der E-Mail angehängten CSV-Datei.
  
• Bei der Anwendung von E-Mail-Komprimierung gelten folgende Vorgaben: 
  
• CSV-Dateien sind von Komprimierungsmaßnahmen ausgeschlossen
  
• Komprimierung der Dateianhänge im zip-Datei-Format
  
• mit „normaler“ Kompression/Kompressionsstärke
  
• mit Kompressionsmethode/-verfahren „Deflate“ (#4.4.5 - compression method 8)
  
• unverschlüsselt, d. h. ohne Passwort
  
• nicht selbst-entpackend (d. h. zip als exe)
• Die Struktur der CSV-Dateien für Ad-hoc-Reports nach den Vorgaben aus [RFC4180] und den nachfolgenden Konkretisierungen bauen. Die CSV-Datei:
• MUSS die erste Zeile zur Definition der Feldnamen (Header) enthalten.
• MUSS ab der zweiten Zeile die zu übermittelnden Werte (den Datensatz) enthalten.
• MUSS das Semikolon ";" als Feldtrennzeichen verwenden.
• DARF das Feldtrennzeichen innerhalb der CSV-Felder NICHT inhaltlich verwenden.
• DARF Feldinhalte NICHT quotieren.
• MUSS UTF-8 Zeichensatzkodierung ohne ByteOrderMark verwenden.
• MUSS CR-LF-Zeilenumbrüche (ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed)) verwenden.
• DARF Kommentierungen NICHT verwenden.
• DARF leere Zeilen NICHT verwenden.
• DARF bei Zahlwerten das Tausendertrennzeichen NICHT verwenden.
• MUSS Leerzeichen am Rand der Feldinhalte entfernen, sofern diese nicht intendiert sind.
• MUSS Zeitangaben gemäß ISO 8601 unter expliziter Angabe einer Zeitzone, z.B. YYYY-MM-DDTHH:mm:ss[.fff]Z enthalten.

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:

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-04 - Performance – IDP-Dienst – Bearbeitungszeit unter Last

Der Produkttyp IDP-Dienst MUSS die Bearbeitungszeitvorgaben unter Last aus der Tabelle "Tab_gemSpec_Perf_IDP-Dienst: Last- und Bearbeitungszeitvorgaben" 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 nicht einberechnet - sie ist separat zu berichten.

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: Last- und 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 - Performance - Identity Provider - 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 - Performance - IDP-Dienst - Georedundanz

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 - Performance - sek IDP KTR - Verfügbarkeit

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_24558 - Verfügbarkeit - Anbieter sek IDP KTR - Definition Ausfall

Der Anbieter sek IDP KTR MUSS sein Produkttyp so betreiben, dass die geforderte Verfügbarkeit gemäß [gemSpec_Perf#A_22357-*] über alle registrierten Mandanten sichergestellt wird und auch die Schnittstellen für Anwendungen ohne Registrierung in der TI-Föderation zur Verfügung stehen.
Das heißt konkret:

• Der Dienst des Anbieters sek IDP KTR gilt dann als ausgefallen, wenn ein oder mehrere Mandanten gemäß [gemSpec_Perf#A_25079] ausgefallen sind.

• Der Dienst des Anbieters sek IDP KTR gilt dann als ausgefallen, wenn eine oder mehrere Schnittstellen gemäß [gemSpec_Perf#A_25080] für Anwendungen ohne TI-Registrierung nicht erreichbar sind.

A_25079 - Verfügbarkeit - Anbieter sek IDP für KTR - Definition Ausfall Mandant

Ein Mandant eines Anbieters sek IDP KTR MUSS die Verfügbarkeit gemäß [gemSpec_Perf#A_22357-*] erfüllen.
Unter einem Mandanten des Anbieters sek IDP KTR wird eine konkrete per Registrierung initiierte Ausprägung verstanden, welche über ein eigenes Entity Statement mit darin enthaltenen (drei) Endpunkten verfügt und über eine gemIK gemäß [gemSpec_Perf#A_25078] eindeutig identifizierbar ist.

Diese Ausprägung unterscheidet sich pro Betriebsumgebung.

Ein Mandant des Anbieters sek IDP KTR gilt dann als ausgefallen, wenn
- mindestens ein Endpunkt gemäß [gemSpec_Perf#A_25080] nicht erreichbar ist oder
- wegen einer fehlerhaften Registrierung oder Konfiguration nicht korrekt kommuniziert oder
- mehr als 20% der Anfragen des Mandanten gar nicht, nicht rechtzeitig gemäß [gemSpec_Perf#A_22833] oder fehlerhaft im Lieferintervall gemäß [gemSpec_Perf#A_21957] erfolgen. 
[<=]

A_25080 - Verfügbarkeit - Anbieter sek IDP für KTR - Definition Erreichbarkeit

Ein Mandant des Anbieters sek IDP KTR MUSS durch das Probing der gematik durchgängig erreichbar sein, um die Verfügbarkeit [gemäß A_22357-*] erfüllen zu können.
Ein Mandant des Anbieters sek IDP KTR gilt dann als nicht erreichbar, wenn dieser bei einem Erreichbarkeitsversuch nicht erreichbar war.
Bei diesen Erreichbarkeitsversuchen müssen alle Endpunkte bestimmungsgemäß korrekt antworten.

Hinweis:
Es werden die Endpunkte_
- Authorization Endpunkt
- Push Authorization Endpunkt und
- Token Endpunkt
überwacht. [<=]

A_22048-01 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP-Dienst - Übermittlung bei dislozierten CIs

Der Anbieter KANN die Übermittlung der Betriebsdatenlieferung 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 - Betriebsdatenlieferung v2 - Spezifika IDP-Dienst - Operation/Duration

Der Produkttyp MUSS bei Betriebsdatenlieferungen 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_22015-01 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP - Status

Wenn bei der Durchführung der Operation/des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp IDP-Dienst - bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika sektoraler IDP - Status

Wenn bei der Durchführung der Operation/des Use Case ein Fehler aufgetreten ist, MUSS der Produkttyp sektoraler IDP bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika sektoraler IDP - Operation/Duration

Der Produkttyp MUSS bei Betriebsdatenlieferungen 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 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP - Aufbereitung Client-ID als cidi

Für die Erfassung der Betriebsdaten 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 Betriebsdaten im Parameter cidi verwenden. [<=]

A_22504 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP - Feldtrennzeichen im Useragent

Der Produkttyp MUSS, sofern vom Client irrtümlicherweise im Useragent-Wert das verbotene Feldtrennzeichen ";"  übertragen wurde, dieses ";" gegen das Zeichen "┼" austauschen und in der Betriebsdatenlieferung 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-02 - Performance - IDP-Dienst - Abbruch bei OCSP-Timeout

Der Produkttyp IDP-Dienst MUSS nach einer konfigurierbaren Wartezeit von 5000 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 Betriebsdaten protokollieren.
[<=]

A_25989 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP-Dienst - Message Versionsinformation, ClientID und Error-Codes

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

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

• $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 
• $backendduration: Zeit in ms für Abfragen an OCSP oder analogen Backendsystemen, Datentyp Integer

A_24060-01 - Performance - Betriebsdatenlieferung v2 - Spezifika IDP - Robustheitsprüfung UserAgent

Der Produkttyp IDP-Dienst MUSS - bei Betriebsdatenlieferungen 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_25082 - Definition der Fehlercodes des Anbieter sek IDP KTR und Lieferung im Betriebshandbuch

Der Anbieter sek IDP KTR MUSS die von ihm verwendeten Fehlercodes (Integer) der gematik im Betriebshandbuch mitteilen und bei Änderungen der gematik mitteilen.  [<=]

A_24582 - Präzisierung - Spezifika sek IDP - Message - Nutzung der cidi

Der Produkttyp sek IDP MUSS bei Betriebsdatenlieferungen genau die Requests in den Betriebsdaten berücksichtigen und den zugehörigen Wert für "cidi" für A_22944 berichten, bei denen es sich um:
- Anfragen von in der TI-Föderation registrierten Authorization Servern [cidi gemäß A_24339, Integer] oder
- Anfragen von Signaturdiensten (SigD) [cidi = "111114"] oder
- Anfragen von kassenindividuellen Anwendungen unter Nutzung der GesundheitsID [cidi = "111116"]
handelt.  [<=]

A_25078 - Definition des abgestimmten IK (gemIK) für Anbieter sek IDP KTR

Der Anbieter sek IDP KTR MUSS seine Mandanten anhand deren eindeutigen und mit der gematik abgestimmten Institutskennzeichen (gemIK) der Kasse identifizieren.
Maßgeblich ist die mit der gematik abgestimmte Liste der gemIK. 
[<=]

A_22944-02 - Performance - Betriebsdatenlieferung v2 - Spezifika sek IDP - Message

Der Produkttyp sek IDP MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "cidi": $cidi, "err": $errorcode, "ik": $gemIK }

• $cidi: <Applicationidentifier> gemäß A_24582, Datentyp Integer
• $errorcode: <Fehlercode> gemäß A_25082, Datentyp Integer
• $gemIK: <abgestimmtes IK> gemäß A_25078, Datentyp Integer

A_23213-01 - Registrierungsbestandsdaten - Anbieter sek IDP KTR

Der Anbieter sek IDP KTR MUSS die Registrierungsinformationen täglich im JSON-Format gemäß [A_23236-*] als HTTP-Body an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD#A_23110-*] liefern. Die in dieser Lieferung enthaltenen Daten MÜSSEN den Stand des Vortages zum Zeitpunkt 24:00 Uhr repräsentieren.
[<=]

A_23236-06 - Format der Registrierungsinformationen Anbieter sek IDP KTR

Der Anbieter sek IDP KTR MUSS bei der Lieferung der Registrierungsinformationen folgendes Format verwenden:

{   
"datenstand": "<Datum des berichteten Vortages, als String gemäß ISO 8601 in Zeitzone UTC im konkreten Format:  YYYY-MM-DDTHH:mm:ss[.fff]Z>", 
"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>,   
"mandant": [
               {
                 "gemIK":<abgestimmtes IK> gemäß A_25078, Datentyp Integer,
                 "bestand":
                   {
                     "oaf":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren Online-Ausweisfunktion des neuen Personalausweises ...>,
                     "pif":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren POSTIDENT Filiale>
                   }
               }
             ]
}

Hinweise:
Im Bestand wird die Anzahl der zum Abfragezeitpunkt registrierten Nutzer pro 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 

[<=]

A_20165-08 - 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 Betriebsdaten - E-Rezept-Fachdienst

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

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

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

A_26079 - Performance - E-Rezept-Fachdienst - ePA Medication Service - Spitzenlastvorgaben

Der Produkttyp E-Rezept-Fachdienst MUSS als Client die Spitzenlastvorgaben aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Spitzenlastvorgaben ePA Medication Service" erfüllen.

Tabelle 16: Tab_gemSpec_Perf_eRP-Fachdienst: Spitzenlastvorgaben ePA Medication Service

A_26080 - Performance - ePA Medication Service - Maximale Übertragungszeit

Der Produkttyp E-Rezept-Fachdienst MUSS als Client des ePA Medication Service die UseCases zum Einstellen und Übermitteln der Löschinformationen von Verordnungsdaten und Dispensierinformationen spätestens nach 12 Stunden im ePA Aktenkonto durchgeführt haben, es sei denn, technische Fehler im ePA Aktensystem verhindern dies. [<=]

A_22975 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - 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 - Betriebsdatenlieferung v2 - Spezifika E-Rezept - 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 - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Operation

Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Status

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

A_23090-03 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Message

Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen 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, "it": $fhir-issue-type, "ec": $error-component, "sec": $suberror-component, "suf": $error-suffix, "epa": $epa}

• $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, für die Anfragen an die ePA Aktensysteme 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 
• $fhir-issue-type: Der Wert der Kategorie im OperationOutcome Fehlercode, Datentyp String
• $error-component: Der Wert des Objektes im OperationOutcome Fehlercode, Datentyp String
• $suberror-component: Der Wert der Regel im OperationOutcome Fehlercode, Datentyp String
• $error-suffix: Der Wert des Suffixes im OperationOutcome Fehlercode, Datentyp String
• $epa: Der Wert der Subdomain der URL des ePA-Aktensystems, Datentyp String

A_23091 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rezept - Duration

Der Produkttyp E-Rezept-Fachdienst MUSS bei Betriebsdatenlieferungen 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-02 - 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 - Betriebsdatenlieferung v2 - Spezifika Fachdienst TI-M - Duration

Der Produkttyp Fachdienst TI-Messenger MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika Fachdienst TI-M - Operation

Der Produkttyp Fachdienst TI-Messenger MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika TI-M Message

Das Produkt SOLL - bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika TSP X.509 - Duration

Der Produkttyp MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika TSP X.509 - Operation

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

A_22491 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 - Status

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp - bei Betriebsdatenlieferungen 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 21: Tab_gemSpec_Perf_Fehlercodes_TSP-X.509

A_22492 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 - Message

Der Produkttyp MUSS bei Betriebsdatenlieferungen 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 22: 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 23: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben

A_23386 - Performance - Betriebsdatenlieferung v2 - Spezifika FedM - Operation

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

A_23489 - Performance - Betriebsdatenlieferung v2 - Spezifika FedM - Duration

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

A_23387 - Performance - Betriebsdatenlieferung v2 - Spezifika FedM - Message

Der Anbieter des Federation Masters MUSS - bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika VPN-Zugangsdienst - Status

Der Produkttyp VPN-Zugangsdienst MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika VPN-Zugangsdienst - Operation

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

A_23221-01 - Performance - Betriebsdatenlieferung v2 - Spezifika VPN-Zugangsdienst - Duration

Der Produkttyp VPN-Zugangsdienst MUSS bei Betriebsdatenlieferungen 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-03 - Performance - Betriebsdatenlieferung v2 - Spezifika VPN-Zugangsdienst - Message

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

{ "cn": "$commonName", "ip" : "$IP-Address", "s" : "$source" }

• $commonName = Feld <subject:commonName> gemäß gemSpec_PKI#Tab_PKI_245 (FQDN des Zugangsdienstes), Datentyp String
• $IP-Address = IP-Adresse der bearbeitenden Fachdienstinstanz, Datentyp String
• $source = Quellregion des Operationsaufrufs, Datentyp String

A_23497-01 - 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-01 - Performance - Spezifika VPN-Zugangsdienst - Lieferweg und Format für Bestandsdaten

Der Anbieter VPN-Zugangsdienst MUSS die Informationen aus A_23497-* pro Standort, jeweils zum Wechsel in den nächsten Lieferintervall  
in folgendem JSON Format an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD::A_23110-* - Schnittstelle Betriebsdatenerfassung Content-Upload JSON Format] liefern. 
Für jeden SZZP ist dabei innerhalb des Array szzpInfo jeweils ein eigenständiges Objekt zu erstellen.   

{  

A_23067-01 - Performance - NCPeH-Fachdienst - Messung von Bearbeitungszeiten

Der NCPeH-Fachdienst MUSS die folgenden Bedingungen einhalten:

Vorbedingungen für die Messungen
Es wird davon ausgegangen, dass bei den fachlichen Anwendungsfällen ein etablierter VAU-Kanal zu Backend-Systemen (ePA-Aktensystem) bereitsteht.
Dies gilt nicht für die VAU-Anwendungsfälle - dort dient die Bearbeitungszeit (duration) als Indikator für die Dauer des Verbindungsaufbaus bis zum Etablieren eines autorisierten VAU-Kanals. Die Zeit bis zur erfolgreichen Autorisierung über den IDP wird dabei als Backend-Duration (bkdur) gemessen und gemeinsam im VAU-Anwendungsfall erfasst.

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 Beginn der Sendung eines zugehörigen Responses.
Die Zeit, die zur Kommunikation mit abhängigen Systemen (z.B. OCSP, IDP-Dienst, fachliche Operationen ePA-Aktensystem) benötigt wird, ist in einer separaten Zeitmessung zu erfassen und im Feld "backendDuration" der Betriebsdatenlieferung zu senden. Diese Zeit darf nicht auf die eigene Bearbeitungszeit (duration) angerechnet werden. Fällt der Aufbau eines VAU-Kanals zu einem Backend-System inmitten eines fachlichen Anwendungsfalls, so ist der Aufbau des VAU-Kanals gesondert als eigener Anwendungsfall (z.B. UC_VAU1) zu erfassen und darf nicht auf den fachlichen Anwendungsfall angerechnet werden.
[<=]

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

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

Tabelle 26 Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben

A_24758 - Performance - NCPeH-Fachdienst - Timeout

Der NCPeH-Fachdienst MUSS bei Anfragen von anderen NCPeH-EU gewährleisten, dass die Zeit zur Antwort (Systemreaktion) regelmäßig innerhalb von 15 Sekunden erfolgt, jedoch nicht länger als 30 Sekunden dauern darf (Timeout). [<=]

A_22979-01 - Performance - NCPeH-Fachdienst - Verfügbarkeit

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

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

A_23017 - Performance - NCPeH-Fachdienst - Skalierung

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

A_23011 - Performance - Betriebsdatenlieferung v2 - Spezifika NCPeH-Fachdienst - Operation

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

A_23012 - Performance - Betriebsdatenlieferung v2 - Spezifika NCPeH-Fachdienst - Duration

Der NCPeH-Fachdienst MUSS bei Betriebsdatenlieferungen 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-01 - Performance - Betriebsdatenlieferung v2 - Spezifika NCPeH-Fachdienst - Status

Wenn bei der Durchführung eines Anwendungsfalls ein Fehler aufgetreten ist, MUSS der NCPeH-Fachdienst - bei Betriebsdatenlieferungen 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 entsprechende Feld im Message-Block gem. [A_23118*] mit der Fehleridentifikation befüllt werden. [<=]

A_23118-02 - Performance - Betriebsdatenlieferung v2 - Spezifika NCPeH-Fachdienst - Message

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

{ "reqc": "$requestingCountry", "err": "$errorCode", "bkdur": "$backendDuration" }

• $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 gem. [A_23013*], Datentyp String. Inhalt:
• des Feldes "Code" aus der Struktur "AcknowledgementDetail" für XCPD.
• des Feldes "errorCode" aus der Struktur "RegistryError" für XCA.
• $backendduration: Benötigte Zeit in ms für Abfragen an Backendsystemen wie z.B. OCSP, ePA oder IDP, Datentyp Integer

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 28: 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 - Betriebsdatenlieferung v2 - Spezifika SigD - Duration

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

A_22478 - Performance - Betriebsdatenlieferung v2 - Spezifika SigD - Status

Wenn bei der Durchführung der Operation ein Fehler aufgetreten ist, MUSS der Produkttyp Signaturdienst - bei Betriebsdatenlieferungen 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 29: Tab_gemSpec_Perf_Fehlercodes_SigD

A_22479-01 - Performance - Betriebsdatenlieferung v2 - Spezifika SigD - Message

Der Produkttyp Signaturdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen:

{ "gm": $guest_mode, "pm": $privacy_mode}

• $guest_mode: <Gäste-Modus> gemäß A_24682-* , Datentyp Integer [0,1] wobei "0" false und "1" true bedeuten
• $privacy_mode:<Privatshäre-Modus> gemäß A_24682-* , Datentyp Integer [0,1] wobei "0" false und "1" true bedeuten

A_22477-01 - Performance - Betriebsdatenlieferung v2 - Spezifika SigD - Operation

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

Tabelle 30: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

A_20135 - Performance - Fachdienst KIM - Skalierung

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

A_20129 - Performance - Fachdienst KIM - Spitzenlastvorgaben

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

A_26323 - Performance - Fachdienst KIM - Last- und Bearbeitungszeitvorgaben

Der Fachdienst KIM MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_KIM: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast mindestens erfüllen.

Table # Tab_gemSpec_Perf_KIM: Last- und Bearbeitungszeitvorgaben

A_20134-01 - Performance - Fachdienst KIM - Robustheit gegenüber Lastspitzen

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

A_20132-01 - Performance - Anbieter Fachdienst KIM - Spitzenlastvorgaben TU

Der Anbieter Fachdienst KIM MUSS in der Testumgebung (TU) 5% der definierten Vorgaben zur Spitzenlast aus "Tab_gemSpec_Perf_KIM: Last- und Bearbeitungszeitvorgaben" erfüllen.

Ist der Marktanteil kleiner als 5% (10.500 KIM-Teilnehmer) MUSS der Anbieter Fachdienst KIM nur den entsprechenden Prozentwert seines Marktanteils in der TU bereitstellen. Der Prozentwert MUSS mit angegeben werden. [<=]

GS-A_5139-02 - Performance – Fachdienst KIM – Verfügbarkeit

Der Produkttyp Fachdienst KIM MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

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

A_24042-01 - Performance - Fachdienst KIM - Nachrichtenversand binnen 10 Minuten

Der Fachdienst KIM MUSS gewährleisten, dass eine Nachricht, nach erfolgreicher Entgegennahme, innerhalb der nächsten 10 Minuten an den Fachdienst KIM des Empfängers übertragen wird.

Hinweis: Es sollen geeignete Maßnahmen getroffen werden, welche das robuste Weiterleiten von Nachrichten an andere Fachdienst KIMe ermöglichen. [<=]

GS-A_5138-02 - Performance – Fachdienst KIM – TLS-Verbindungsaufbau unter Last

Der Produkttyp Fachdienst KIM 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 - Fachdienst KIM - Anbindungsbandbreite

Der Anbieter des Fachdienst KIMes 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-01 - Performance - Betriebsdatenlieferung v2 - Spezifika Fachdienst KIM - Status

Der Fachdienst KIM MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "status" die Angabe der Spalte "$status" gemäß "Tab_gemSpec_Perf_Berichtsformat_KIM" berücksichtigen. [<=]

A_23168 - Performance - Betriebsdatenlieferung v2 - Spezifika Fachdienst KIM - Operation/Duration

Der Produkttyp Fachdienst KIM MUSS bei Betriebsdatenlieferungen die Inhalte der Felder "$operation" und "$duration_in_ms" nach den Vorgaben der Tabelle Tab_gemSpec_Perf_Berichtsformat_KIM befüllen. [<=]

A_23167-01 - Performance - Betriebsdatenlieferung v2 - Spezifika Fachdienst KIM - Message

Der Fachdienst KIM MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

{ "size": "$size", "err": "$fehlermeldung", "sys": "$senderName", "sysv": "$senderVersion", "dka": "$dienstAnw", "dkt": "$dienstTyp","dkv": "$dienstVer","cmn": "$cmName", "cmv": "$cmVersion", "cptv": "$cmPTVersion", "ksize": "$kasSize","fromOid":"$fromOid", "toOid":"$toOid", "ccOid":"$ccOid" }

Diese message-Felder MÜSSEN immer mitgegeben werden:

• 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
  

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 - Betriebsdatenlieferung v2 - Spezifika TI-Gateway-Zugangsmodul - Duration

Der Produkttyp TI-Gateway-Zugangsmodul MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika TI-Gateway-Zugangsmodul - Operation

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

A_23988-02 - 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 TI-Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat)
• Anzahl gesperrter VPN-Zugänge aufgrund von detektierten Angriffen
• Anzahl gesperrter TI-Zugänge auf Weisung der gematik
  

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

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

{
    "ci": "<CI ID der logischen Produktinstanz des TI-Gateway-Zugangsmodul gemäß TI-ITSM als String>",
    "timestamp": "<Zeitstempel der Abfrage als String gemäß ISO 8601 unter expliziter Angabe einer Zeitzone, z.B. YYYY-MM-DDTHH:mm:ss[.fff]Z>",
    "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>,
    "numLockAccessCert":<Gesamtanzahl gesperrter TI Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat) zum Abfragezeitpunkt als Integer>,
    "numLockAccessIntDet":<Gesamtanzahl gesperrter VPN Zugänge aufgrund detektierten Angriffen zum Abfragezeitpunkt als Integer>,
    "numLockAccessGem":<Gesamtanzahl gesperrter TI Zugänge auf Weisung der gematik zum Abfragezeitpunkt als Integer>
} [<=]

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 - Betriebsdatenlieferung v2 - Spezifika Namensdienst - Operation

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

A_23435 - Performance - Betriebsdatenlieferung v2 - Spezifika Namensdienst - Duration

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

A_23920-01 - Performance - Betriebsdatenlieferung v2 - Spezifika Namensdienst - Message

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

{ "ip": "$IP-Adresse", "nraum": "$Namensraum" }

• $IP-Adresse = IP-Adresse der Instanz des Namensdienstes, Datentyp String
• $Namensraum = "Returned Value" aus der Tabelle Tab_gemSpec_Perf_Namensdienst_Namensräume basierend darauf, welcher Namensraum bei der Auflösung des FQDNs oder des Services betroffen ist, Datentyp String

A_23921 - Performance - Betriebsdatenlieferung v2 - Spezifika Namensdienst - Status

Der Produkttyp Namensdienst MUSS bei Betriebsdatenlieferungen 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 39 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben

GS-A_5030-01 - 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.
[<=]

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

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

A_23256 - Performance - Betriebsdatenlieferung v2 - Spezifika Intermediär VSDM - Operation

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

A_23253 - Performance - Betriebsdatenlieferung v2 - Spezifika Intermediär VSDM - Duration

Der Produkttyp Intermediär VSDM MUSS bei Betriebsdatenlieferungen 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-02 - Performance - Betriebsdatenlieferung v2 - Spezifika Intermediär VSDM - Message

Der Produkttyp Intermediär VSDM MUSS bei Betriebsdatenlieferungen 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 gemäß [A_25779*], 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 - Betriebsdatenlieferung v2 - Spezifika Intermediär VSDM - Status

Der Produkttyp Intermediär VSDM MUSS bei Betriebsdatenlieferungen 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-01 - Performance - OCSP Responder der TSP X.509nQ - Komp - Bearbeitungszeit unter Last

Der Produkttyp TSP-X.509 nonQES - Komp MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp unter der für alle Schnittstellenoperation parallel anliegenden Spitzenlast dauerhaft erfüllen.

Tabelle 41: Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp

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

Der TSP-X.509 nonQES für Komponenten MUSS die Vorgaben an die Spitzenlast aus Tab_gemSpec_Perf_CRL-Dienst_Lastvorgaben garantieren.

Tabelle 42: Tab_gemSpec_Perf_CRL-Dienst_Lastvorgaben

A_18013-01 - Performance – TSP – Provisioning/Revocation – Bearbeitungszeit

Der Produkttyp TSP-X.509nonQES der Komponenten-PKI MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_Provisioning_Revocation_Bearbeitungszeiten unter der für alle Schnittstellenoperation parallel anliegenden Spitzenlast dauerhaft erfüllen.

Tabelle 43: Tab_gemSpec_Perf_TSP_Provisioning_Revocation_Bearbeitungszeitvorgaben

A_23533 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 nonQES – Komp - Operation

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

A_23532 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 nonQES – Komp - Duration

Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Betriebsdatenlieferungen 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-02 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 nonQES – Komp - Message

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

{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp", "cc": $certCount, "ip": "$IP-Adresse", "rs": "$responseStatus" }

• $protocol= "ECC" | "RSA" | "WEB" | "SOAP" | "CMP", Datentyp String
• $result= "GOOD" | "REVOKED" | "UNKNOWN", Datentyp String
• $zertifikatstyp = Zertifikatstyp aus Tab_gemSpec_Perf_Berichtsformat_TSP X.509 nonQES – Komp, Datentyp String
• $certCount = Anzahl der angefragten Zertifikate innerhalb eines Requests, Datentyp Integer
• $IP-Adresse = IP-Adresse des anfragenden Dienstes, Datentyp String
• $responseStatus = Response Status der Anfrage gem. GS-A_4686, Datentyp String

A_23751 - Performance - Betriebsdatenlieferung v2 - Spezifika TSP X.509 nonQES – Komp - Status

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSP X.509 nonQES – Komp bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika OCSP-Responder-Proxy - Operation

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

A_24158 - Performance - Betriebsdatenlieferung v2 - Spezifika OCSP-Responder-Proxy - Duration

Der Produkttyp OCSP-Responder-Proxy MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika OCSP-Responder-Proxy - Status

Der Produkttyp OCSP-Responder-Proxy MUSS bei Betriebsdatenlieferungen 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 - Betriebsdatenlieferung v2 - Spezifika OCSP-Responder-Proxy - Message

Der Produkttyp OCSP-Responder-Proxy MUSS bei Betriebsdatenlieferungen 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-01 - Performance - OCSP Responder des TSL-Dienstes - Bearbeitungszeit unter Last

Der Produkttyp TSL-Dienst MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst unter der für alle Schnittstellenoperation parallel anliegenden Spitzenlast dauerhaft erfüllen.

Tabelle 50: Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst

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

Der Produkttyp TSL-Dienst MUSS die Vorgaben an Spitzenlast 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.

Tabelle 51: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben

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

Der TSL-Dienst MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

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

A_24169 - Performance - Betriebsdatenlieferung v2 - Spezifika TSL-Dienst - Operation

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

A_24168 - Performance - Betriebsdatenlieferung v2 - Spezifika TSL-Dienst - Duration

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

A_24170 - Performance - Betriebsdatenlieferung v2 - Spezifika TSL-Dienst - Status

Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSL-Dienst - bei Betriebsdatenlieferungen 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-02 - Performance - Betriebsdatenlieferung v2 - Spezifika TSL-Dienst - Message

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

{ "prot": "$protocol", "res": "$result", "url": "$usedURL", "ip": "$IP-Adresse", "rs": "$responseStatus" }

• $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
• $IP-Adresse = IP-Adresse des anfragenden Dienstes, Datentyp String
• $responseStatus = Response Status der Anfrage gem. GS-A_4686, 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. [<=]

A_24165 - Performance - Betriebsdatenlieferung v2 - Spezifika gematik Root-CA - Operation

Der Produkttyp gematik Root-CA MUSS bei Betriebsdatenlieferungen bzgl. des "operation"-Feldes die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA berücksichtigen. [<=]

A_24164 - Performance - Betriebsdatenlieferung v2 - Spezifika gematik Root-CA - Duration

Der Produkttyp gematik Root-CA MUSS bei Betriebsdatenlieferungen bzgl. des "duration_in_ms"-Feldes die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA berücksichtigen. [<=]

A_24166 - Performance - Betriebsdatenlieferung v2 - Spezifika gematik Root-CA - Status

Der Produkttyp gematik Root-CA MUSS bei Betriebsdatenlieferungen bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_gematik-Root-CA 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_24167-01 - Performance - Betriebsdatenlieferung v2 - Spezifika gematik Root-CA - Message

Der Produkttyp gematik Root-CA MUSS bei Betriebsdatenlieferungen im "message"-Feld die folgenden Daten im JSON-Format übermitteln:

{ "prot": "$protocol", "res": "$result", "cn": "$commonName", "rs": "$responseStatus"  }

• $protocol= Genutzter Schlüsselalgorithmus des angefragten Zertifikates: "ECC" | "RSA",  Datentyp String
• $result= Sperrstatus des angefragten Zertifikates gemäß GS-A_4690: "GOOD" | "REVOKED" | "UNKNOWN", Datentyp String
• $commonName = commonName des Zertifikats gem. GS-A_4737, Datentyp String
• $responseStatus = Response Status der Anfrage gem. GS-A_4686. Datentyp String

A_15031-03 - Performance - ePA-Aktensystem - Bearbeitungszeit unter Last

Der Anbieter ePA-Aktensystem MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

Die Bearbeitungszeit bemisst sich aus der Zeit vom Eintreffen des letzten Bits der Anfrage (Request) im ePA-Aktensystem bis zum Zeitpunkt, an dem das erste Bit der Antwort (Response) zurückgesendet wird.

Tabelle 58 : Tab_gemSpec_Perf_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben