gemSpec_Perf_V2.8.0_Aend

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Übergreifende Spezifikation

Performance und Mengengerüst TI-Plattform

 

   

   

Version	2.78.0
Revision	548770
Stand	15.0528.06.2019
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_Perf

Dokumentinformationen

Änderungen zur Vorversion

ÄnderungenAnpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzung des Dokuments

1.5 Methodik

1.5.1 Anforderungen

2 Performance-Kenngrößen und ihr Einsatz

2.1 Bearbeitungszeit

2.2 Last

2.3 Verfügbarkeit

2.4 Einsatz der Performance-Kenngrößen

2.5 Performance-Evaluierung auf der Basis von Rohdaten

2.5.1 Performance-Berichtsformat

3 Leistungsanforderungen für Anwendungsfälle

3.1 Spitzenlasten für Anwendungsfälle

3.1.1 Mengengerüst

3.1.2 Versichertenstammdatenmanagement (VSDM)

3.1.3 Kommunikation Leistungserbringer (KOM-LE)

3.1.4 Notfalldaten-Management (NFDM)

3.1.5 eMP/AMTS-Datenmanagement

3.1.6 Elektronische Patientenakte (ePA)

3.1.7 Tokenbasierte Authentisierung (TBAuth)

3.1.8 Lastmodell auf Ebene der Anwendungsfälle

3.1.9 Betriebliche Anwendungsfälle

3.2 Bearbeitungszeiten

3.2.1 Bearbeitungszeiten KOM-LE

3.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)

3.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement

3.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)

3.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung

3.3 Verfügbarkeiten

4 Leistungsanforderungen an die Produkttypen der TI

4.1 Produkttypen der dezentralen Zone der TI-Plattform

4.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT

4.1.2 Produkttyp Konnektor

4.1.2.1 Fachmodul ePA

4.1.3 Produkttyp eHealth-Kartenterminal

4.1.4 Produkttyp Mobiles Kartenterminal

4.1.5 Produkttyp KTR-AdV

4.2 Produkttypen der zentralen Zone der TI-Plattform

4.2.1 Produkttyp Verzeichnisdienst

4.2.2 Produkttyp Konfigurationsdienst

4.2.3 Produkttypen der PKI – TSL-Dienst

4.2.4 Produkttypen der PKI – OCSP-Responder

4.2.5 Produkttyp Störungsampel

4.2.6 Produkttyp Service Monitoring

4.2.7 Produkttyp Namensdienst

4.2.8 Produkttyp Zeitdienst

4.2.9 Produkttyp Zentrales Netz der TI

4.2.10 Produkttyp VPN-Zugangsdienst

4.2.11 Produkttyp Sicherheitsgateway Bestandsnetze

4.2.12 Produkttyp Signaturdienst

4.2.13 Produkttyp Schlüsselgenerierungsdienst

4.3 Produkttypen VSDM

4.3.1 Produkttyp VSDM Intermediär

4.3.2 Produkttypen Fachdienste VSDM (UFS, VSDD, CMS)

4.4 Produkttypen KOM-LE

4.4.1 Produkttyp KOM-LE-Clientmodul

4.4.2 Produkttyp KOM-LE-Fachdienst

4.5 Produkttyp ePA-Aktensystem

5 Anhang A – Verzeichnisse

5.1 Glossar

5.2 Abbildungsverzeichnis

5.3 Tabellenverzeichnis

5.4 Referenzierte Dokumente

5.4.1 Dokumente der gematik

5.4.2 Weitere Dokumente

6 Anhang B – Modelldetails

6.1 Verteilung der Konnektorbearbeitungszeiten auf Komponenten

7 Anhang C – Performance-Kenngrößen

8 Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors

9 Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors

1 Einordnung des Dokuments

1.1 Zielsetzung

Die Performance-Spezifikation hat zum Ziel, die Performance-Kenngrößen für alle Produkttypen der TI zu definieren und die Anforderungen an die Performance der Produkttypen zu stellen. Ausgangspunkt für die Berücksichtigung des Bedarfs sind die Leistungsanforderungen für die Fachanwendungen, das sichere Übermittlungsverfahren KOM-LE, die Basisdienste QES, die tokenbasierten Authentisierung sowie für den Zugang zu Fremdnetzen (Internet, Bestandsnetz).

Die Performance-Kenngrößen decken drei Dimensionen ab:

• Durchsatz, die Anzahl an Funktionsaufrufen oder die Datenmenge, die pro Zeiteinheit durch das System oder eine seiner Komponenten abgearbeitet werden,
• die erlaubte Bearbeitungszeit je Funktionsaufruf und die
• Verfügbarkeit über die gesamte Betriebszeit.

Die Ableitung der Produktanforderungen erfolgt über ein Performance-Modell, das hier soweit skizziert wird, wie für die Nachvollziehbarkeit erforderlich.

Die Anforderungen an die Produkttypen sind so formuliert, dass sie dem Stand der Technik entsprechende Optimierungen implizit voraussetzen, aber nicht zwingendermaßen Vorgaben für konkrete Optimierungen machen. So wird das gewünschte Leistungsniveau erreicht, ohne dabei den Lösungsraum für die Anbieter unnötig einzuschränken. Spezifische Anforderungen zur Optimierung können allerdings in den produkttypspezifischen Spezifikationen gestellt werden.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens.

Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Das vorliegende Dokument stellt Performance-Anforderungen an die technischen, aber nicht an organisatorische Schnittstellen der TI-Plattform.

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

2 Performance-Kenngrößen und ihr Einsatz

Das vorliegende Kapitel definiert die Performance-Kenngrößen für die drei Performance-Dimensionen Bearbeitungszeit, Last und Verfügbarkeit. Außerdem legt es fest, welche Kenngrößen 'reported' werden. 

2.1 Bearbeitungszeit

Bearbeitungszeit bezeichnet die Zeit, welche für die Ausführung einer Funktion, sei es auf Anwendungsfallebene oder auf Ebene einer Operation an den technischen Schnittstellen eines Produkttypen anfällt.

Die auf Ebene der Anwendungsfälle gemessene Bearbeitungszeit, wird der funktionalen Zerlegung und Systemzerlegung des Gesamtsystems folgend, in Bearbeitungszeiten gemessen an den Außenschnittstellen der Produkttypen zerlegt. Dabei kommt es auf eine möglichst exakte und lückenlose Definition der einzelnen Zeitbeiträge an:

• In diesem Dokument wird die Bearbeitungszeit innerhalb der Primärsysteme nicht berücksichtigt.
• Die Bearbeitungszeit innerhalb einer Komponente kann sich aus verschiedenen Bearbeitungszeitbeiträgen zusammensetzen, beispielsweise für einen Request/Reply-Zyklus aus einem Beitrag zum Request und einem zum Reply.
• Jeder Bearbeitungszeitbeitrag innerhalb einer Komponente beginnt, wenn das letzte Bit der Eingangsdaten an die Schnittstelle der Komponente übergeben wurde, und endet, wenn das erste Bit der Ausgangsdaten an der Schnittstelle der Komponente oder des Produktes an das Netzwerk übergeben wird.
• Die einer Netzwerkstrecke zugerechnete Bearbeitungszeit (Übertragungszeit) beginnt, wenn das erste Bit der zu übertragenden Daten an das Netzwerk übergeben wird und endet mit der Übergabe des letzten Bit an die empfangende Komponente.

Die Abarbeitung eines Funktionsaufrufs kann durch die Parallelisierung von Teilschritten beschleunigt werden. Die Verarbeitungszeit entlang des Pfades durch die Teilschritte mit der längsten Bearbeitungszeit (kritischer Pfad) bestimmt die Gesamtbearbeitungszeit.

Die Performance-Dimension Bearbeitungszeit wird idealisiert durch folgende Größen für jeden einzelnen Anwendungsfallaufruf ermittelt:

• Angabe der aufgerufenen Funktion (auf oberster Ebene: Anwendungsfall),
• Zeitpunkt des Ausführungsstarts,
• Bearbeitungszeit,
• für die Bearbeitungszeit verantwortliches Produkt,
• rekursive Zerlegung entlang des kritischen Pfades in weitere Funktionen.

Die Bearbeitungszeiten für einen Anwendungsfall sind nicht für jeden Aufruf gleich. Zum einen können die ausführenden Produkte von Fall zu Fall unterschiedlich sein (z. B. verschiedene Karten), zum anderen wird die Antwortzeit jedes einzelnen Produkts variieren, oft abhängig von zufälligen Situationsparametern.

So kommt es zu einer Verteilung von Bearbeitungszeiten. Im Modell der Bearbeitungszeiten wird diese Verteilung auf zwei statistische Größen reduziert:

• Bearbeitungszeiterwartungswert
• Bearbeitungszeitvarianz

Beide Größen addieren sich für unabhängige Teilschritte unabhängig von der Verteilungsfunktion der Antwortzeiten pro Teilschritt (siehe [UnabhZufall]). Unter der Näherung einer Gaußverteilung der Antwortzeiten lässt sich die Varianz in ein p-Quantil übersetzt, dass sich selbst nicht für einzelne Teilschritte addiert.

Die Zerlegung einer Funktion in Teilfunktionen und die Nutzung der Modellgrößen und illustriert Abbildung 1.

Abbildung 1: Beispiel für Zerlegung einer Funktion und die Modell-Bearbeitungszeitgrößen

Bei Messungen korrespondiert der Erwartungswert des Modells mit dem arithmetischen Mittelwert der Bearbeitungszeiten1 über eine Gesamtheit von N Einzelmessungen. Er berechnet sich als Summe der Bearbeitungszeiten geteilt durch die Anzahl N der Einzelmessungen.

1) Mittelwert steht hier ausschließlich für den arithmetischen Mittelwert.

Als Performancevorgaben hinsichtlich Bearbeitungszeit werden für eine definierte Umgebung zwei Schranken vorgegeben:

• Mittelwertschranke für den Bearbeitungszeitmittelwert2
• Quantilschranke für das 99%-Quantil der Bearbeitungszeit

2) Vereinfachend in der Bezeichnung werden Erwartungswert des Modells und arithmetischer Mittelwert der Messungen gleichermaßen mit bezeichnet.

Für eine Gesamtheit von 100 Einzelmessungen darf der Mittelwert der Bearbeitungszeiten nicht größer als die zugehörige Schranke sein und die 99 niedrigsten Bearbeitungszeiten dürfen nicht größer als die Quantilschranke sein.

Für die Produkttypen der zentralen Zone der TI-Plattform müssen Bearbeitungszeitvorgaben unter Last erfüllt werden. Da dabei nicht immer ein Stichprobenumfang von genau 100 Einzelmessungen pro Operation realisiert werden kann, ist es notwendig das gemessene 99%-Quantil für einen allgemeinen Stichprobenumfang der Anzahl n zu definieren.

Quantil-Definition

= Bearbeitungszeit der m-ten Bearbeitungszeit, wobei diese nach aufsteigendem Wert geordnet sind. Dabei ist m[n] = (n – n mod 100) * 0,99 + n mod 100.

Beispiele: m[100] = (100 – 0) * 0,99 + 0 = 99 und m[17] = (17 – 17) * 0,99 + 17 = 17

Inhaltliche Begründung: Ein Ausreißer wird immer nur für volle 100 Aufrufe zugelassen.

2.2 Last

Jede Funktion wird von ihren Nutzern im Betrieb mit einer gewissen Häufigkeit aufgerufen. Die dem Aufruf folgende Verarbeitung innerhalb einer Produktinstanz erzeugt für diese eine Arbeitslast.

Es stellt sich die Frage, wie viele Anfragen parallel von einer Produktinstanz bearbeitet werden müssen. Um dies zu klären, wird zunächst gezeigt, welche Bedeutung der Mittelungszeitraum hat. Auf dieser Grundlage wird dann die Modellierung der Aufrufrate skizziert.

Die Performance-Dimension Last wird idealisiert durch eine Liste der einzelnen Aufrufzeitpunkte repräsentiert .

Abbildung 2 skizziert die Aufrufzeitpunkte für eine Funktion beispielhaft.

Abbildung 2: Beispiel für gemessene Aufrufe, die zu Aufrufzeitpunkten erfolgen

Eine solche exakte Verteilungsfunktion der Aufrufe kann gemittelt werden, indem man zu jedem Zeitpunkt über einen gewissen Zeitraum in der Vergangenheit die Aufrufe zählt und die Anzahl durch den Mittelungszeitraum T teilt. Man erhält so eine Aufrufrate , die auch vom Zeitintervall T abhängt.

Die Abbildung 3 skizziert die Aufrufrate zu der Situation aus Abbildung 2 und identifiziert die höchste Aufrufrate – die „Spitze“ – im Mittelungszeitraum.

Abbildung 3: Beispiel einer über den Zeitraum T gemittelten Aufrufrate

Entspricht der Mittelungszeitraum T der mittleren Antwortzeit, dann gibt eine Spitze die parallel zu bearbeitenden Aufrufe an.

Ein kleinerer Mittelungszeitraum erhöht die Spitzenraten [1/sec] beliebig. Ein größerer Mittelungszeitraum nivelliert die für die Bearbeitung praktisch relevanten, tatsächlich parallel zu verarbeitenden Aufrufzahlen.

Auf Grund dieser Überlegungen wird im Folgenden der Zeitraum T immer gleich der Schranke für den Bearbeitungszeitmittelwert gesetzt. Die Einheit der Aufrufrate kann davon unabhängig für beliebige Zeiteinheiten als [1/Zeiteinheit] angegeben werden, etwa mit [1/sec], [1/h] oder [1/ ].

Modellierung der Aufrufrate

Ziel einer modellhaften Betrachtung der Aufrufrate ist eine möglichst gute Schätzung für die Spitzen in der Aufrufrate . Ausgangspunkt ist die Anzahl der auf einen großen Zeitraum entfallenden Aufrufe, etwa pro T = 1 Jahr = 1y. Anzahl geteilt durch Zeitraum T ergibt die Aufrufrate . Diese Aufrufrate wird bis zu einer Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) entwickelt (Abbildung 4).

Abbildung 4: Entwicklung der Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) aus einer Durchschnittslast pro Jahr.

Die so bestimmte modellierte Spitzenrate hat folgende Bedeutung:

• gibt die im Mittel zu erwartende Anzahl der parallel zu verarbeitenden Aufrufe an,
• die Anzahl der parallelen Aufrufe ist genauer poisson-verteilt, d. h. die Wahrscheinlichkeit für k parallele Aufrufe zu einem Zeitpunkt ist

• Die Wahrscheinlichkeit dafür, dass 2 oder mehr Aufrufe parallel verarbeitet werden müssen ist dann

 

Die Aufrufrate wird ausgehend von einem auf ein Jahr bezogenen Mengengerüst, unter Berücksichtigung aller verfügbaren Informationen über das Benutzerverhalten, auf eine (oder mehrere fallbezogene) Spitzenlasten entwickelt. Diese Spitzenlast beschreibt für den jeweiligen Spitzenlastzeitraum zufällig verteilte Anfragen. Der zeitliche Abstand der Anfragen ist exponentialverteilt und ihre Häufigkeit für ein Zeitintervall poisson-verteilt. Wird als Zeitintervall die erwartete Bearbeitungszeit gewählt, ist durch diese Poisson-Verteilung die Anzahl der parallel zu bearbeitenden Anfragen beschrieben.

Lastbegriff

Durch zwei Anforderungen wird gewährleistet, dass Aufrufe auch erwartungsgemäß bearbeitet werden:

Für jeden Produkttyp der TI-Plattform wird gefordert, dass die an seinen Außenschnittstellen angebotenen Operationen, bei der maximal erwarteten Aufrufrate für diese Schnittstelle funktional korrekt bearbeitet werden. Beispiel für eine solche reine Durchsatzanforderung ist die Anforderung an die Störungsampel [GS-A_4160].

Sollte es vorkommen, dass die gemäß Spitzenlast maximal erwartete Aufrufrate überschritten wird, muss sich die TI-Plattform stabil verhalten, was durch die Anforderung [GS-A_4145] für Produkttypen der zentralen Zone der TI-Plattform sichergestellt wird.

Im Folgenden verwendete Lastbegriffe:

• Last – Anzahl von Aufrufen einer bestimmten Funktionalität pro Zeiteinheit.
• Lastspitze – Die im Betrieb tatsächlich auftretende Maximallast pro Sekunde für eine definierte Funktionalität.
• Spitzenlast – Die von allen Produktinstanzen eines Produkttyps für eine definierte Funktionalität gemeinsam zu bewältigende Last.

2.3 Verfügbarkeit

Folgende Begriffe werden definiert:

• Ausfall – Ein System gilt für den Erfassungszeitraum als ausgefallen, wenn im Erfassungszeitraum 20% oder mehr der Anfragen nicht erfolgreich verarbeitet werden. Gemäß [GS-A_4146] besteht der Erfassungszeitraum aus 5 Minuten.
  Die zeitnahe Feststellung von Start- und den Endzeitpunkt jedes Ausfalls regeln die Anforderungen in Kapitel 2.4.

Abweichend gilt für die Fachdienste VSDM (UFS, VSDD, CMS), dass ein Ausfall vorliegt, wenn der Fachdienst nicht zur Verfügung steht. Der Ausfall der definierten funktionalen Eigenschaften der Fachdienste VSDM wird durch das Service Monitoring ermittelt. 

• Verfügbarkeit – Die Verfügbarkeit eines Produkttyps wird unterteilt in Verfügbarkeit funktionaler und nicht-funktionaler Eigenschaften. Die Verfügbarkeit funktionaler Eigenschaften eines Produkttyps wird u.a. durch das Service Monitoring überwacht (fachliche Anfrage an den Dienst durch Probes und Interpretation der Antwort/des Ergebnisses). Der Begriff Verfügbarkeit bezeichnet im Folgenden die Verfügbarkeit der funktionalen Eigenschaften, sofern nicht anders ausgeführt.
  
  Die Verfügbarkeit wird in diesem Dokument als (Gesamtzeit – Gesamtausfallzeit)/Gesamtzeit berechnet. Die Gesamtausfallzeit setzt sich aus der Summe der Erfassungszeiträume zusammen, in denen das System ausgefallen ist.
• Längste Ausfalldauer - ist die längste Ausfalldauer am Stück.
• Hauptzeit – Zeitfenster in dem eine hohe Last zu erwarten ist.
• Nebenzeit – Zeitfenster in dem eine niedrige Last zu erwarten ist.

Die Performance-Dimension Verfügbarkeit wird über die Gesamtzeit und die Dauer der konkreten  Ausfälle berechnet. Dabei ist ein konkretes Zeitintervall durch einen konkreten Startzeitpunkt und einen konkreten Endzeitpunkt beschrieben (z. B.: 17.08.2015 16:35:00 bis 17.08.2015 16:40:00). Wenn nicht ein gesamter Dienst ausgefallen ist, muss zusätzlich noch erfasst werden, auf welche Schnittstellenoperationen oder Verbindungen im Falle des zentralen Netzes sich der Ausfall bezieht. Da Ausfälle grundsätzlich selten erfolgen dürfen, besteht kein Bedarf diese Messdaten für ein etwaiges Reporting vor der Lieferung zu aggregieren.

Aggregierte Sicht auf Verfügbarkeiten

Um die Verfügbarkeit der TI für einen Anwendungsfall zu bestimmen, muss die Verfügbarkeit aller für die Bearbeitung einer Anfrage notwendigen Produkttypen berücksichtigt werden. Genauer müssen die konkreten Zeitintervalle aller Ausfälle berücksichtigt werden.

Zwei Extremfälle können auftreten:

• Keines der konkreten Zeitintervalle überlappt mit einem anderen. Dann sind die Produkttypen in diesem Fall bezüglich der Verfügbarkeiten unabhängig und die Verfügbarkeiten können multipliziert werden.
• Alle konkreten Zeitintervalle sind identisch – etwa, weil es sich um ein gut koordiniertes Wartungsfenster handelt. In diesem Fall ist die Gesamtverfügbarkeit gleich der jeder einzelnen Produktinstanz.

Der erste Fall wird im Folgenden vereinfachend für die Modellierung der Verfügbarkeit angenommen. Der zweite Fall muss vom Betrieb berücksichtigt werden, weil hier durch Koordination von Ausfallzeitintervallen bei fixer Verfügbarkeit von Einzelkomponenten die Ende-zu-Ende-Verfügbarkeit für Anwendungsfälle gesteigert werden kann.

Caching

Der positive Effekt des Cachings auf die Verfügbarkeit von Anwendungsfällen ist tageszeitabhängig. Beim Stellen von Verfügbarkeitsanforderungen an die Produkttypen wird der Caching-Effekt daher nicht berücksichtigt.

Toleranzschranken für längste Ausfalldauer und Verfügbarkeit

Toleranzschranken für die Verfügbarkeit in Prozent und die längste Ausfalldauer bilden die zu definierenden Verfügbarkeitsanforderungen. Mit der Angabe eines Bezugszeitraumes (Monat oder Jahr) kann die Vorgabe einer Toleranzschranke für die längste Ausfalldauer entfallen, wenn die tolerierte Gesamtausfallzeit im Bezugszeitraum unterhalb der Toleranzschranke für die längste Ausfalldauer liegt.

2.4 Einsatz der Performance-Kenngrößen

Die Performance-Betrachtung dient dem Ziel, die benötigte und erwartete Leistung in Bezug auf die Performance-Dimensionen „Bearbeitungszeit, Last und Verfügbarkeit “ für die Anwendungsfälle dauerhaft im Betrieb zur Verfügung zu stellen.

Um dies zu erreichen, werden zum einen Blattanforderungen für das Bearbeitungszeitverhalten von Operationen an den Außenschnittstellen der Produkttypen gestellt. Dabei wird auch festgelegt unter welcher Last diese Vorgaben zu erfüllen sind. Diese sind zulassungsrelevant. Zum anderen werden Performance-Daten im Betrieb erfasst, die eine Rückkopplung auf verschiedenen Ebenen erlauben:

• Über die Störungsampel bzw. zukünftig über das Service Monitoring wird der aktuelle Zustand der TI reflektiert.
• Performance-Reports fließen zurück ins Performance-Modell, das dadurch nachjustiert werden kann.
• SLA-Reports zeigen, ob bestehende Service-Vereinbarungen eingehalten werden und ob die bestehenden ausreichend sind, den Bedarf zu erfüllen.

GS-A_4146 - Performance – Performance-Daten erfassen

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

Die aufzunehmenden Performance-Kenngrößen definiert Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen.
[<=]

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

Die Produkttypen der zentralen Zone der TI-Plattform, der VSDM Intermediär und der KOM-LE-Fachdienst MÜSSEN die Performance-Reporting-Daten jeweils im Zeitintervall der Erfassung von Performance-Reporting-Daten in dem durch TIP1-A_3271 definierten Übermittlungsformat an die Störungsampel senden.

Die aufzunehmenden Performance-Kenngrößen definiert Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen.
[<=]

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

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

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

[<=]

Hinweise:

• Dass Messverfahren zur Ermittlung eines Ausfalls wird nicht vorgegeben. Es wird erwartet, dass hier in Abhängigkeit von den Ausfallszenarien geeignete Verfahren gewählt werden.
• Bei der Definition des „Start/Endzeitpunkt eines Ausfalls“ ist die konkrete Implementierung des Messverfahrens unerheblich. Es geht nur um die prinzipielle Erkennbarkeit.
• Für die Feststellung eines Ausfalls muss nicht notwendigerweise in allen Ausfallszenarien eine Gesamtheit von Anfragen analysiert werden.
• Bei einem Komplettausfall eines Produkttyps der zentralen Zone der TI-Plattform bzw. des VSDM Intermediärs einschl. deren Systembestandteilen zur Überwachung des Systems kann keine Meldung des Ausfalls als Ereignisnachricht im Sinne von GS-A_4148 erfolgen.

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

Die Produkttypen der zentralen Zone der TI-Plattform, der VSDM Intermediär, der KOM-LE-Fachdienst und die Komponenten AdV-Server der KTR-AdV MÜSSEN die Performance-Reporting-Daten ohne weitere Aggregation in den Performance-Report übernehmen.

Die aufzunehmenden Performance-Kenngrößen definiert Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen.

[<=]

Performance-Reporting-Daten

Die Performance-Reporting-Daten werden von den Anbietern an die gematik übermittelt, um eine Aussage über den aktuellen Zustand der TI zu ermöglichen.  Es wird produkttypübergreifend festgelegt, welche Performance-Reporting-Daten in jedem Erfassungsintervall erfasst werden müssen.

Last:

• Anzahl der Aufrufe im Reporting-Intervall
• Anzahl der fehlerfrei bearbeiteten Aufrufe

Bearbeitungszeit (jeweils pro Schnittstellenoperation)

• Anzahl der summierten Bearbeitungszeiten
• Summe der Bearbeitungszeiten
• Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke.

Verfügbarkeit (jeweils pro Schnittstellenoperation)

• alle Ausfälle mit Angabe des konkreten Ausfallzeitintervalls
  (pro Produkttyp, wenn der gesamte Produkttyp betroffen ist, und pro Schnittstellenoperation, wenn nur einzelne Schnittstellenoperationen betroffen sind)

Produkttypspezifisch sind die Operationen und gegebenenfalls weitere Parameter nach denen ein Aufriss der Bearbeitungszeiten erfolgt. Ein etwaiger weiterer Aufriss (etwa nach Verbindungen von Produkttyp zu Produkttyp beim zentralen Netz) erfolgt ebenfalls produkttypspezifisch.

Relevanz für Service Level Agreements

Service Level Agreements (SLA) bzgl. Performance-Vorgaben werden für alle Produkttypen der zentralen Zone der TI-Plattform vereinbart.

Die Prozesse zum Service Level Management legen die Richtlinien zum Betrieb [gemRL_Betr_TI] fest. Sie beinhalten Anforderungen zum Service Level Reporting.

Welche Performance-Kenngrößen in den Service Level Reports aufgenommen werden, legt die Spalte „Service Level Report“ in Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen fest.

Die konkreten Leistungsanforderungen pro Produkttyp stellt Kapitel 4 dar.

Für die Auswertung der Bearbeitungszeiten wird geprüft, ob die Mittelwertschranke bezogen auf den Monatszeitraum eingehalten wird. Zur Überprüfung der 99%-Quantilvorgaben wird geprüft, ob die Anzahl der Antwortzeiten größer der vorgegebenen 99%-Quantilschranke kleiner gleich 1 % der Gesamtanfragen ist.

Wenn nicht explizit angegeben, ist die maximale Ausfalldauer für SLAs als
(1 – Verfügbarkeit) * 1 Monat anzusetzen.

Sind die Verfügbarkeitsanforderungen pro Produkttyp definiert, so müssen sie durch jede von ihm angebotene Schnittstellenoperation für sich erfüllt werden. Die hierfür maßgeblichen Schnittstellenoperationen gibt Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen vor. Ein Produkttyp erfüllt die Verfügbarkeitsanforderungen, wenn alle von ihm angebotenen Schnittstellenoperationen die Verfügbarkeitsanforderungen erfüllen.

Die Lastangaben gelten, soweit nicht explizit abweichend angegeben, jeweils für alle Instanzen eines Produkttypen in Summe.

2.5 Performance-Evaluierung auf der Basis von Rohdaten

Die Rohdaten eines Produkttyps erfassen das Performanceverhalten von Diensten der TI. Diese Rohdaten beinhalten folgende Informationen:

• Zeitpunkt des Aufrufs
• Aufgerufene Operation
• Bearbeitungszeit des Aufrufes
• Erfolg der Operationsbearbeitung

Aus den Rohdaten lassen sich die Performance-Kenngrößen und Service Level sowie die Abbruchquote (Anteil der nicht erfolgreich verarbeiteten Aufrufe gemessen an der Anzahl der Aufrufe) für den Produkttyp ermitteln. 

Die Rohdaten werden vom Produkttyp erfasst und durch den Anbieter an den definierten Endpunkt gemeldet. Ausfälle werden nicht gemeldet.

Produkttypen erfassen Performance-Kennzahlen, protokollieren sie in einem Performance-Protokoll und stellen sie in dem hier festgelegten Performance-Berichtsformat bereit.

2.5.1 Performance-Berichtsformat

Um die automatisierte Auswertung von Performance-Kennzahlen zu erleichtern, wird das von [Perf4J] verwendete Format übernommen. Das verwendete Format setzt nicht den Einsatz von [Perf4J] im reportenden Dienst voraus.

A_17757 - Performance - Rohdaten-Performance-Berichte - Zu liefernden Berichte

Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zu jedem Berichtsintervall zwei Dateitypen senden: Einen Performance-Bericht mit den zu liefernden Rohdaten (Performance Protokoll) und eine Datei zur Selbstauskunft gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].
[<=]

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

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

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

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

 

[<=]

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

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

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

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

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

mit

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

[<=]

Ein Beispiel für zwei Einträge, der erste zu einem fehlerfreien Aufruf, der zweite zu einem Aufruf, der nicht fehlerfrei durchlaufen wurde:

INFO: start[1000212390109] time[447] tag[UFS.GetUpdateFlags]
INFO: start[1000212470109] time[2]   tag[UFS.GetUpdateFlags.failed]

Tabelle 1: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM

$operation	Produkttyp	Operation	Beschreibung
UFS.GetUpdateFlags	UFS	GetUpdateFlags	Bei Aufruf der Operation Ge- tUpdateFlags beginnt die Mes- sung mit Annahme der Nach- richt an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum Intermediär VSDM.
VSDD.PerformUpdates	VSDD	PerformUpdates	Bei Aufruf der Operation Per- formUpdates beginnt die Mes- sung mit Annahme der Nach- richt an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum Intermediär VSDM.
VSDD.GetNextCommand- Package	VSDD	GetNextCommand-Package	Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit An- nahme der Nachricht an der Aussenschnittstelle des Pro- dukttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum Inter-mediär VSDM.
CMS.PerformUpdates	CMS	PerformUpdates	Bei Aufruf der Operation Per- formUpdates beginnt die Mes- sung mit Annahme der Nach- richt an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum Intermediär VSDM.
CMS.GetNextCommand- Package	CMS	GetNextCommand-Package	Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit An- nahme der Nachricht an der Aussenschnittstelle des Pro- dukttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum Inter-mediär VSDM.

Tabelle 2: Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA

$operation	Produkttyp	Operation	Beschreibung
VAU_Context	ePA- Aktensystem	Bereitstellung des Verarbeitungskontextes der VAU	Bei Empfang der VAUClientHello-Nachricht beginnt die Messung und endet mit dem vollständigen Versenden der VAUServerFin-Nachricht (gemäß [A_15698]).
I_Authentication_Insurant:: login	ePA-Aktensystem	login	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.
I_Authentication_Insurant:: renew	ePA-Aktensystem	renew
I_Authentication_Insurant:: logout	ePA-Aktensystem	logout
I_Authorization:: getAuthorizationKey	ePA-Aktensystem	getAuthorizationKey
I_Authorization_Insurant:: getAuthorizationKey	ePA-Aktensystem	getAuthorizationKey

Tabelle 3: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

$operation	Produkttyp	Operation	Beschreibung
SigD.sign_Data	SigD	sign_Data	Bei Aufruf der Operation sign_Data beginnt die Mes- sung mit Annahme der Nach- richt an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum ePA-Client.

Tabelle 4: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD

$operation	Produkttyp	Operation	Beschreibung
SGD.getPublicKey	SGD	getPublicKey	Bei Aufruf der Operation getPublicKey beginnt die Messung mit Annahme der Nachricht an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum ePA-Client.
SGD.KeyDerivation	SGD	KeyDerivation	Bei Aufruf der Operation getPublicKey beginnt die Messung mit Annahme der Nachricht an der Aussenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Aussenschnittstelle zum ePA-Client.

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

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

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

Hinweis: Ein CI (Configuration Item) kann auch ein Knoten oder ein Standort sein.

A_17679 - Performance - Rohdaten-Performance-Berichte - Berichtsintervall

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

[<=]

A_17756 - Performance - Rohdaten-Performance-Berichte - Korrektheit

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

[<=]

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

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

3 Leistungsanforderungen für Anwendungsfälle

Das vorliegende Kapitel erfasst die Leistungsanforderungen aus den Anwendungen der TI im Wirkbetrieb:

• Versichertenstammdaten-Management (VSDM)
• Kommunikation für Leistungserbringer (KOM-LE)
• Notfalldatenmanagement (NFDM)
• eMP/AMTS-Datenmanagement (AMTS)
• elektronische Patientenakte (ePA)
• Tokenbasierte Authentisierung (TBAuth)
• Qualifizierte Elektronische Signatur (QES)
• Digitale Signatur und Verschlüsselung
• Anbindung Bestandsnetze

Die Leistungsanforderungen werden hier der Reihe nach für die drei Performance-Dimensionen Last, Bearbeitungszeit und Verfügbarkeit aufgeführt.

3.1 Spitzenlasten für Anwendungsfälle

Ausgangspunkt für die Modellierung von Spitzenlasten auf Ebene der Anwendungsfälle ist ein Mengengerüst der Leistungserbringer in Praxen und Krankenhäuser sowie den gesetzlich Krankenversicherten und ihren Behandlungsfällen. Spitzenlasten für die Anwendungsfallnutzung berechnet das Lastmodell als Produkt aus Mengengröße und einem Proportionalitätsfaktor, welcher das bekannte und erwartete Benutzerverhalten widerspiegelt.

Der Ansatz über die Proportionalitätsfaktoren erlaubt es, die Spitzenlasten an den jeweiligen Kontext anzupassen: für eine Praxis, für ein Krankenhaus einer bestimmten Größe oder für die TI insgesamt im Produktivbetrieb.

3.1.1 Mengengerüst

Im Folgenden wird das Mengengerüst für den Produktivbetrieb aufgestellt, welches alle gesetzlich Krankenversicherte bedient.

Da letztlich die Leistungen des Gesundheitswesens für die Krankenversicherten erbracht werden, ist die Zahl des Versicherten die zentrale Mengengröße, mit der alle Mengenangaben skalieren. D. h. alle Lastangaben die sich im Folgenden auf alle 70 Mio. Versicherten beziehen, können auf kleinere Mengen heruntergerechnet werden – etwa pro 1 Mio. Versicherten, indem Lastangaben durch 70 geteilt werden.

Tabelle 3 gibt die Zahl der Versicherten, der niedergelassenen Leistungserbringer und der Krankenhäuser an. Es folgt eine Größenklassifizierung der Praxen in Tabelle 4 sowie der Krankenhäuser in Tabelle 5. Tabelle 7 trifft Annahmen zur Modellierung.

Da die Lastbetrachtung große Unwägbarkeiten bzgl. des Benutzerverhaltens enthält, ist eine Signifikanz von 1-2 Stellen in den Zahlen des Mengengerüsts ausreichend. Die Zahlen sind daher entsprechend gerundet und beim Bezugszeitpunkt der Größen wird eine entsprechende Ungenauigkeit zugelassen.

Tabelle 5: Mengengerüst: Versicherte und Leistungserbringer

ID	Größe	Anzahl	Quelle
M1	Gesetzlich Krankenversicherte der Bundesrepublik Deutschland 2008	70.000.000	[GBE_Bund]
M2	Ärzte	138.500	[KBV2010]
M3	Zahnärzte, die an der vertragszahnärztlichen Versorgung teilnehmen	54.200	[KZBV2010]
M4	Psychotherapeuten	17.300	[KBV2010]
M27	Apotheker, Apothekerassistenten und Pharmazieingenieure	56.600	[ABDA2018]
M5	Leistungserbringer (LE)	266.600	M2 + M3 + M4 + M27

Tabelle 6: Mengengerüst: Lokationen

ID	Größe	Anzahl	Quelle
M6	Einzelpraxen Ärzte	67.000	[KBVPraxen2010]
M7	Gemeinschaftspraxen Ärzte	20.000	[KBVPraxen2010]
M8	Medizinische Versorgungszentren (MVZ)	1.700	[KBVPraxen2010]
M9	Einzelpraxen Zahnärzte	36.500	[KZBV2010]
M10	Mehrfachpraxen Zahnärzte	8.400	[KZBV2010]
M11	Praxen Psychotherapeuten	17.300	Annahme: M4
M12	Krankenhäuser	2.000	[DKG2010]
M13	Lokationen (Praxen und KH)	152.900	M6 + M7 + M8 + M9 + M10 + M11 + M12
M25	Apotheken (inkl Filialapotheken)	20.249	[ABDA2016]
M26	Lokationen (Praxen, KH, Apotheken)	173.149	M13 + M25
M28	Gesetzliche Krankenkassen	109	[GKVKassen2019]

Tabelle 7: Mengengerüst: Krankenhäuser (Quelle: [DKG2010])

Krankenhäuser nach Größenklassen
ID	Größenklasse	KH	Ärzte pro KH	ltd. Ärzte + Oberärzte pro KH	Fälle pro Tag u. KH ambulant	Fälle pro Tag u. KH stationär
M14	unter 100 Betten	646	8	3	5	5
M15	100 bis 199 Betten	468	30	11	19	19
M16	200 bis 299 Betten	302	57	19	65	32
M17	300 bis 399 Betten	204	85	29	95	47
M18	400 bis 599 Betten	224	135	45	137	69
M19	600 bis 799 Betten	69	211	65	288	96
M20	800 und mehr Betten	90	559	149	537	179

Tabelle 8: Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen

Klasse der Leistunserbringer- umgebung (LE-Ux)		Großer Repräsentant in der Klasse der LE-Umgebung
		Beschreibung	Ärzte	ltd. Ärzte + Oberärzte	Fälle pro Tag
					ambulant	stationär
1	Praxis, Gemeinschaftspraxen, MVZ, KH "bis 199 Betten"	Ø KH (144 Betten) "100 bis 199 Betten"	30	11	19	19
2	KH "200 bis 599" Betten	Ø KH (482 Betten) "400 bis 599 Betten"	135	45	137	69
3	großes KH KH "600 bis 1599 Betten"	Ø KH (1219 Betten) "800 Betten und mehr"	559	149	537	179
4	sehr großes KH KH "1600 Betten und mehr"	3000 Betten	1.398	373	1.343	448

Tabelle 4 nimmt eine grobe Klassifizierung sämtlicher Leistungserbringerumgebungen in vier Größenklassen vor. Klasse LE-U1 beinhaltet Praxen, Gemeinschaftspraxen, medizinische Versorgungszentren und Krankenhäuser bis 199 Betten3. Klasse LE-U2 umfasst Krankenhäuser bis 599 Betten. Klasse LE-U3 umfasst große Krankenhäuser. Klasse LE-U4 umfasst sehr große Krankenhäuser. Im Hinblick auf Lastanforderungen ist für jede Klasse ein besonders großer Repräsentant ausgewählt. Der Repräsentant der Klasse 4 wurde so groß gewählt, dass er mit Sicherheit größer als die größten existierenden Krankenhäuser ist.

3) Perspektivisch kann es in späteren Ausrollstufen entsprechend des Lastaufkommens für weitere Anwendungsfälle notwendig werden, die Klasse weiter zu unterteilen. Neben dem Klassenrepräsentanten eines "100 bis 199 Betten"-Krankenhaus wird zusätzlich als Praxisrepräsentant eine Praxis für 1000 Versicherte berücksichtigt. Die jeweils pro Anwendungsfall höheren Spitzenlasten dieser beiden Repräsentanten sind für die Anforderungen maßgeblich.

Tabelle 9: Mengengerüst: Annahmen für Modellierung

ID	Größe	Wert	Quelle
M21	Anzahl Konnektoren	173.149	Annahme: M26
M22	Dauer Modellarbeitstag Praxis	8 h	Festlegung
M23	Dauer Modellarbeitstag Krankenhaus	16 h	Festlegung
M24	KOM-LE-Teilnehmer	210.109	Annahme: M2 + M3 + M4 + M28

3.1.2 Versichertenstammdatenmanagement (VSDM)

Das Versichertenstammdatenmanagement (VSDM) umfasst fünf performance-relevante Anwendungsfälle (siehe [gemKPT_Perf_VSDM]), die eine Kombination der folgenden drei Aktivitäten gemäß Tabelle 8 sind:

• Abfrage, ob eine Aktualisierung der Versichertenstammdaten (VSD) vorliegt,
• Aktualisierung der VSD auf der eGK, falls eine Aktualisierung vorliegt,
• Lesen der VSD von der eGK.

Tabelle 10: VSDM Anwendungsfälle

VSDM Anwendungsfälle	Prüfung Aktualität	Aktualisierung	Lesen VSD
Lesen VSD mit Online-Prüfung mit Aktualisierung der VSD	x	x	x
Lesen VSD mit Online-Prüfung ohne Aktualisierung der VSD	x		x
Lesen VSD ohne Online-Prüfung			x
Automatische Online-Prüfung mit Aktualisierung der VSD	x	x
Automatische Online-Prüfung ohne Aktualisierung der VSD	x

In der folgenden Lastbetrachtung wird vereinfachend davon ausgegangen, dass nur das Online-Szenario genutzt wird, das die Anwendungsfälle 1 und 2 umfasst. Zusätzlich wird angenommen, dass bei jedem „Lesen VSD“ auch eine Prüfung auf Aktualität erfolgt. Diese Vereinfachung in der Betrachtung ist zulässig, weil dadurch die Last allenfalls geringfügig überschätzt wird. Die daraus resultierenden Vorgaben für die Produkttypen sind dann hinreichend, um die die tatsächliche Last abzudecken. Im Lastmodell werden daher nur die ersten beiden Anwendungsfälle aus Tabelle 6 berücksichtigt.

3.1.3 Kommunikation Leistungserbringer (KOM-LE)

Für KOM-LE als sicheres Übermittlungsverfahren (SÜV) werden folgende performance-relevante Anwendungsfälle (siehe [gemSysL_KOM-LE]) betrachtet:

• Senden einer Nachricht, inklusive Schutz durch Signatur und Verschlüsselung
• Abholen einer Nachricht, inklusive Signaturprüfung und Entschlüsselung

Die Kommunikation zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst erfolgt über einen sicheren Kanal. Da ein einmal aufgebauter sicherer Kanal zum Senden und Empfangen mehrere Nachrichten verwendet werden kann, wird der Aufbau des sicheren Kanals im Folgenden als separater Anwendungsfall betrachtet.

Die eventuell notwendige Nachrichtenweiterleitung von dem KOM-LE-Fachdienst des Senders zum KOM-LE-Fachdienst des Empfängers findet asynchron sowohl zum Sende- als auch zum Abholprozess statt und wird daher separat behandelt.

3.1.4 Notfalldaten-Management (NFDM)

Das Notfalldaten-Management (NFDM) umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_NFDM]), die vom Primärsystem aufgerufen werden.

• Signieren Notfalldaten
• Speichern Notfalldaten
• Lesen Notfalldaten
• Löschen Notfalldaten
• Speichern Persönliche Erklärungen
• Lesen Persönliche Erklärungen
• Löschen Persönliche Erklärungen

Notfalldaten (NFD) haben eine maximale Größe von 11,5 KB. Die Persönlichen Erklärungen (DPE) haben eine maximale Größe von 1,5 KB.

3.1.5 eMP/AMTS-Datenmanagement

Das eMP/AMTS-Datenmanagement umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_AMTS_A]), die vom Primärsystem aufgerufen werden.

• eMP/AMTS-DATEN von eGK lesen
• eMP/AMTS-DATEN auf eGK schreiben

Die auf der eGK gespeicherten eMP/AMTS-Daten haben auf der eGK eine maximale Größe von 13,56 KB. Im XML-Format haben sie eine Größe von etwa 30 KB.

3.1.6 Elektronische Patientenakte (ePA)

Für die elektronische Patientenakte werden die sechs folgenden performance-relevanten Anwendungsfälle aus [gemSysL_ePA] betrachtet:

• Login durch einen Leistungserbringer/Versicherten
• Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern
• Dokument durch einen Leistungserbringer/Versicherten suchen
• Dokument durch einen Leistungserbringer/Versicherten anzeigen
• Dokument durch einen Leistungserbringer/Versicherten einstellen
• Dokument durch einen Leistungserbringer/Versicherten löschen

Es wird davon ausgegangen, dass beim Aufruf einer Fachoperation implizit der Aufbau einer Aktensession inkl. Login durch einen Leistungserbringer/Versicherten erfolgt. Ebenfalls wird angenommen, dass die Dokumentengröße zwischen 10 KB und 1 MB beträgt. Es wird erwartet, dass es sich bei den 10 KB Dokumenten um NFD/DPE- und eMP- Dokumente handelt. Arzt- und Entlassbriefe werden mit einer Dokumentengröße größer 100 KB geschätzt. Die maximale erlaubte Dokumentengröße beträgt 25 MB.

3.1.7 Tokenbasierte Authentisierung (TBAuth)

Die Tokenbasierte Authentisierung umfasst folgende performance-relevanten Operationen:

• I_IDP_Auth_Active_Client
  • issue_Identity_Assertion
  • renew_Identity_Assertion
  • cancel_Identity_Assertion
• I_IDP_Auth_Passive_Client
  • signin
  • signout
• I_Local_IDP_Service
  • sign_Token

3.1.8 Lastmodell auf Ebene der Anwendungsfälle

Das Lastmodell verknüpft die zu erwartende Anfragerate je Anwendungsfall mit Mengengrößen aus dem Mengengerüst per Proportionalitätsfaktor und nennt die jeweils bearbeiteten Datenmengen.

Da hier Zahlen zu Annahmen über das Benutzerverhalten einfließen, die grundsätzlich nicht exakt vorhersagbar sind, wird mit Sicherheitsfaktoren gearbeitet (siehe „Spitzenlasterhöhung“ unten).

Für die Nutzung bestehender Anwendungen und Netze liegt die Leistung der TI-Plattform auf Netzwerkebene. Tabelle 9 gibt die Spitzenlast hierfür an.

Tabelle 11: Lastmodell: Nutzung bestehender Anwendungen und Netze

Spitzenlast in MBit/sec (jeweils down- und upload-Richtung)

150

Für VSDM, KOM-LE, NFDM und die davon unabhängige Nutzung der Basisdienste QES, digitale Signatur und Verschlüsselung wird die Spitzenlast auf Ebene der Anwendungsfallaufrufe durch Tabelle 10, Tabelle 11, Tabelle 14 und Tabelle 16 für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und Medizinischen Versorgungszentren und in Tabelle 13 und Tabelle 15 für Krankenhäuser definiert. Die erwarteten Nutzungsraten für eMP/AMTS in Praxen und Apotheken definiert Tabelle 17. Die Tabellen "Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser" und "ePA-Anwendungsfälle je LE-U" geben eine Übersicht über die zu erwartete Nutzungsrate für die Fachanwendung ePA aus der Leistungserbringer/Versicherten-Umgebung.

Tabelle 10 basiert auf den Zahlen der Lastmodellierung aus [gemSpec_Intermediär_VSDM]. In die angegebene Spitzenlast fließen die Zahl der Online-Prüfungen pro Quartal, die Anzahl der Versicherten und die Modellannahme einer Häufung der Online-Abfragen in der ersten Quartalswoche ein. Die angegebenen Datenmengen ergeben sich aus den pro Anwendungsfall summierten http-Nachrichtengrößen (d.h. http-body gemäß [gemSpec_Intermediär_VSDM] zuzüglich 200 Byte http-header).

Die Spalten „Spitzenlasterhöhung“ in Tabelle 10, Tabelle 11 und Tabelle 13 geben an, um welchen Faktor die Spitzenlast pro Stunde gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag erhöht ist, wobei die Dauer des Arbeitstags ohne Beeinträchtigung der Allgemeinheit für die Modellbetrachtung in Tabelle 7 festgelegt wird. Für das Krankenhaus motiviert sich die Spitzenlasterhöhung beispielsweise bei den VSDM-Anwendungsfällen stationär dadurch, dass zwischen 9 und 14 Uhr etwa 70 % der Patienten aufgenommen werden. Um solche bekannten, aber auch unbekannte systematische Erhöhungen gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag abzudecken, ist je Anwendungsfall ein Faktor angegeben, der sich aus der Häufigkeit des Anwendungsfalles ergibt. Damit hat der Faktor zugleich die Qualität eines Sicherheitsfaktors.

Zur Erläuterung des Faktors „Spitzenlasterhöhung“ wird an Hand von Tabelle 10 exemplarisch die Spitzenlast pro Tag für 1000 Versicherte für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ sowie die Spitzenlast pro Stunde berechnet, in die der „Spitzenlasterhöhungsfaktor“ einfließt:

Spitzenlast pro Tag = 0,10 * 1000 pro Tag = 100 pro Tag

Spitzenlast pro Stunde = 100 pro Tag / 8 Stunden pro Tag * 4 = 50 pro Stunde

Tabelle 12: Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Anwendungsfall	Datenmenge pro Nachricht in kByte	Mengengröße x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs- faktor
VSD Lesen mit  Aktualisierungsprüfung ohne Update	up: 0,7 down: 0,9	Anzahl Versicherte	0,10 * x	4
VSD Lesen mit  Aktualisierungsprüfung  mit Update	up: 4,3 down: 21,7	Anzahl Versicherte	0,0025 * x	4

Bei der Verteilung der Spitzenlasten aus Tabelle 10 auf die einzelnen Praxen und MVZs wird von einer Gleichverteilung der Versicherten auf alle Leistungserbringer und einer Verteilung der Leistungserbringer auf Praxen und MVZs gemäß Tabelle 4 ausgegangen.

Tabelle 13: Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Anwendungsfall	Datenmenge pro Anwendungsfall in kByte	Mengengröße x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs- faktor
QES: Arztsignaturen erstellen (HBA)	50	Anzahl LE	5 * x	2
	100		25 * x	4
	25600		x	2
QES: Arztsignaturen prüfen (HBA)	50		5 * x	2
	100		25 * x	4
	25600		x	2
Digitale Signaturen erstellen (SMC-B)	50		0,5 * x	2
	100		11 * x	4
	25600		0,05 * x	2
Digitale Signaturen prüfen (SMC-B)	50		0,5 * x	2
	100		11 * x	4
	25600		0,05 * x	2
Daten verschlüsseln (SMC-B, HBA)	50		0,5 * x	2
	100		11 * x	4
	25600		0,05 * x	2
Daten entschlüsseln (SMC-B, HBA)	50		0,5 * x	2
	100		11 * x	4
	25600		0,05 * x	2
Authentisierung (SMC-B: C.HCI.AUT, HBA: C.HP.AUT)			2 * x	4

Tabelle 14: Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen

Anwendungsfall	Datenmenge pro Anwendungs- fall in kByte	Mengengröße x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs- faktor
QES: Arztsignaturen erstellen (HBA)	50	x: stationäre Fälle im KH pro Tag	0,5 * x	2
	100		1,3 * x	4
	25600		0,06 * x	2
QES: Arztsignaturen prüfen (HBA)	50		0,5 * x	2
	100		1,3 * x	4
	25600		0,06 * x	2
Digitale Signaturen erstellen (SMC-B)	50		0,04 * x	2
	100		0,1 * x	4
	25600		0,005 * x	2
Digitale Signaturen prüfen (SMC-B)	50		0,04 * x	2
	100		0,1 * x	4
	25600		0,005 * x	2
Daten verschlüsseln (SMC-B, HBA)	50		0,04 * x	2
	100		0,1 * x	4
	25600		0,005 * x	2
Daten entschlüsseln (SMC-B, HBA)	50		0,04 * x	2
	100		0,1 * x	4
	25600		0,005 * x	2
Authentisierung (SMC-B: C.HCI.AUT, HBA: C.HP.AUT)			0,1 * x	4

Die Mengengrößen in „Mengengröße x“ in Tabelle 11 und Tabelle 12 verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle 3.

Tabelle 15: Lastmodell: Krankenhäuser (Quelle: [DKG2010])

Anwendungsfall	Datenmenge pro Anwendungs- fall in kByte	Mengengrößen x und y	Spitzenlasten pro Tag	Spitzenlast- erhöhungs- faktor
VSD Lesen mit Aktualisierungsprüfung ambulant (*)	(*)	x = stationäre Fälle pro Tag y = ambulante Fälle pro Tag	1 * y	4
VSD Lesen mit Aktualisierungsprüfung stationär (*)	(*)		1 * x	4
QES: Arztsignaturen erstellen  (HBA) (**)	100		3,25 * x + 0,25 y	4
QES: Arztsignaturen prüfen (HBA)	100		0,5 * x + 0,25 * y	4
Digitale Signaturen erstellen (SMC-B)	100		1,25 * x	4
Digitale Signaturen prüfen (SMC-B)	100		1,25 * x	4
Daten verschlüsseln (SMC-B, HBA)	100		1,25 * x	4
Daten entschlüsseln (SMC-B, HBA)	100		1,25 * x	4

(*) Es sind zwei Situationen zu unterscheiden: In 2,5 % der Anwendungsfälle erfolgt ein Update und in 97,5 % der Anwendungsfälle erfolgt kein Update, wobei sich die prozentuale Aufteilung und die Nachrichtengrößen aus Tabelle 10 ergeben.

(**) Bei der QES wird für die Stapelgrößen angenommen, dass 75 % der Anwendungsfälle Stapelgröße 1 und 25 % die Stapelgröße 2 haben.

Die Mengengrößen in „Mengengrößen x und y“ in Tabelle 13 verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle 5 und Tabelle 6.

Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle wird in Tabelle 14 für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie in Tabelle 15 für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der KOM-LE-Teilnehmer oder der Zahl der stationären Fälle im KH pro Tag.

Zwei besondere Lastsituationen sind ergänzend zur Durchschnittsbetrachtung berücksichtigt:

• Große Nachrichten:  
  1% der Teilnehmer sendet je 100 Nachrichten je 25 MB über den Tag verteilt.
  Für diesen besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von 16 Mbit/sec in Download-Richtung und 1 Mbit/sec in Upload-Richtung ausgegangen.
• Viele Nachrichten:
  1% der Teilnehmer sendet je 800 Nachrichten je 50 KB über den Tag verteilt.

Tabelle 16: Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Anwendungsfall	Datenmenge pro Anwendungs- fall in KByte	Mengen- größe x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs-faktor
Empfängerdaten ermitteln	10	x: Anzahl KOM-LE Teilnehmer	20 * x	2
Nachricht schützen und an KOM-LE-Fachdienst senden	50		8 * x	2
	100		20 * x	2
	25600		1 * x	1
Nachricht vom KOM-LE Fachdienst holen und aufbereiten	50		8 * x	2
	100		20 * x	2
	25600		1 * x	1
Aufbau sicherer Kanal vom Clientmodul zum Fachdienst			68 * x	2
Teilnehmer pflegt seine Basisdaten			0,004 * x	2
Nachrichtenweiterleitung zwischen KOM-LE-Fden	50		8 * x	2
	100		20 x *	2
	25600		2 * x	2

Tabelle 17: Lastmodell: KOM-LE in Krankenhäusern

Anwendungsfall	Datenmenge pro Anwendungs-fall in KByte	Mengen-größe x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs-faktor
Empfängerdaten ermitteln	10	x: stationäre Fälle im KH pro Tag	2 * x	4
Nachricht schützen und an KOM-LE-Fachdienst senden	50		0,8 * x	2
	100		2 * x	4
	25600		0,1 * x	2
Nachricht vom KOM-LE Fachdienst holen und aufbereiten	50		0,8 * x	2
	100		2 * x	4
	25600		0,1 * x	2
Aufbau sicherer Kanal vom Clientmodul zum Fachdienst		x: Anzahl KOM-LE-Fachdienste  *  Anzahl KOM-LE-Client-Module	2 * x	4
Nachrichtenweiterleitung zwischen KOM-LE-Fden	50	x: Anzahl KOM-LE Teilnehmer	8 * x	1
	100		20 * x	1
	25600		1 * x	1

Annahme: KOM-LE-Teilnehmer in Krankenhausumgebung sind die in Tabelle 5 und Tabelle 6 aufgeführten „Ärzte“.

Die erwartete Nutzungsrate der NFDM-Anwendungsfälle wird in Tabelle 16 für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie inkludiert in Tabelle 13 für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der Ärzte oder der Zahl der ambulanten und stationären Fälle im KH pro Tag.

Dabei ergibt sich der Lastbeitrag für die Krankenhäuser zu Tabelle 13 wie folgt: Für das Prüfen der qualifizierten Arztsignatur wird für Prüfung der Signatur im Kontext Notfalldaten ein Faktor 0,25 (ambulant und stationär) und für Prüfung der Signatur beim Austausch von signierten Dokumenten zwischen den Krankenhäusern ein weiterer Faktor 0,25 (stationär) angesetzt.

Tabelle 18: Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Titel	Datenmenge pro Anwendungsfall in KByte	Mengengrößen	Spitzenlast pro Tag	Spitzenlast- erhöhungsfaktor
NFD signieren	10,5	x: Anzahl LE	6,1 * x	1
NFD schreiben	10,5		6,1 * x	1
NFD lesen	10,5		3,3 * x	1
NFD löschen	10,5		0,6 * x	1
DPE schreiben	1,5		0,6 * x	1
DPE lesen	1,5		0,4 * x	1
DPE löschen	1,5		0,1 * x	1

Die erwartete Nutzungsrate der eMP/AMTS-Anwendungsfälle wird in Tabelle 17 für Praxen (Mengengröße M13) und Apotheken (Mengengröße M25) beschrieben. In einzelnen Apotheken müssen parallel an 10 Arbeitsplätzen für jeweils verschiedene eGKs die Vorgänge „eMP/AMTS-Daten von eGK lesen und dann schreiben“ ausgeführt werden können.

Tabelle 19: Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken

Titel	Datenmenge auf eGK [KB]	Typ der LE-Umgebung	durchschnittliche Aufrufanzahl pro Tag pro Lokation	Spitzenlast- erhöhungsfaktor
eMP/AMTS-Daten von eGK lesen	13,6	Praxen	4	4
		Apotheken	30	4
eMP/AMTS-Daten auf eGK schreiben	13,6	Praxen	4	4
		Apotheken	30	4

Hinweis: G(iga), M(ega), K(ilo) bezeichnet hier G=(1024)3, M=(1024)2 und K=(1024)1.

Die Tabelle "Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser" stellt eine Übersicht über die zu erwartenden Nutzungsraten für ePA dar.

Tabelle 20: Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser

LEI	Mengengröße	Dokument- Typ	Datenmenge [KB]	Erwartete Anzahl an Anwendungsfälle pro Tag je LEI
Praxis	M6 + M7 + M8 + M9 + M10  + M11	eMP	10	5
		NFD/DPE	10	1
		Arztbrief	1000	5
		Sonnstige	1000	2
Apotheke	M25	eMP	10	25
Krankenhaus	M12	eMP	10	10
		NFD/DPE	10	5
		Entlassbrief	1000	(*)
		Sonnstige	1000	3

Die Mengengröße der ePA-Teilnehmer bezieht sich auf die Tabelle "Mengengerüst: Lokationen". Unter der erwarteten Anzahl an Anwendungsfällen pro Tag je LEI wird zum Beispiel das Einstellen eines Arztbriefes verstanden. In der Modellbetrachtung ist für die Anzahl der Anwendungsfälle pro Tag ein Sicherheitsfaktor von 2 mit eingerechnet.

In Praxen und Krankenhäusern wird erwartet, dass die verwendeten Dokumenttypen eMP, NFD/DPE, Arzt- und Entlassbriefe in ePA Anwendung finden. In den Apotheken wird davon ausgegangen, dass ausschließlich ePA-Anwendungsfälle mit dem Medikationsplan erfolgen.

Gemäß Kapitel 3.1.6 wird davon ausgegangen, dass die durchschnittliche Dokumentgröße der Dokumenttypen eMP und NFD/DPE 10 KB beträgt. Arzt- und Entlassbriefe werden mit einer durchschnittlichen Dokumentgröße von 1 MB angenommen.

(*) Die Anzahl der im Krankenhaus ausgestellten Entlassbriefe ist abhängig von der Anzahl der stationären Fälle pro Tag und somit von der Größe der Leistungserbringer-Umgebung (LE-U) gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen".

Zusätzlich wird vermutet, dass jeder gesetzlich Versicherte (70 Mio.) einmal im Jahr bei seiner gesetzlichen Krankenkasse eine Versichertenauskunft (Auskünfte an Versicherte) beantragt.

In Tabelle "ePA-Anwendungsfälle je LE-U" wird die erwartete Anzahl an ePA-Anwendungsfälle pro Tag je Leistungserbringer-Umgebung dargestellt.

Tabelle 21: ePA-Anwendungsfälle je LE-U

	ePA - Anwendungsfälle
Klasse der LE-Umgebung	eMP-Fälle pro Tag	NFD/DPE-Fälle pro Tag	Arztbriefe pro Tag	Entlass- briefe pro Tag	Sonnstige Dokumente pro Tag
LE-U1	5	1	5	19	2
LE-U2	10	5	-	74	4
LE-U3	35	17	-	184	7
LE-U4	87	43	-	453	17

Es sind in LE-U1 fünf Arztbriefe und 19 Entlassbriefe mit eingerechnet, da LE-U1 gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen" Praxen, Gemeinschaftspraxen, MVS und KH klassifiziert.

Die Anzahl der Entlassbriefe pro Tag für die LE-U2 – LE-U4 ergeben sich aus der Anzahl der stationären Fälle pro Tag addiert mit den fünf Arztbriefen aus LE-U1. Somit werden neben Entlassbriefen auch Arztbriefe in den jeweiligen LE-U mit berücksichtigt.

Die zu erwartete Nutzungsrate aus der Versicherten-Umgebung wird in Tabelle "Lastmodell ePA aus der Versicherten-Umgebung" dargestellt.

Tabelle 22: Lastmodell ePA aus der Versicherten-Umgebung

gesetzlich Versicherte	Anzahl ePA Teilnehmer in %	Anzahl Versicherte	Anzahl Dokumente pro Jahr je Versicherter
70 Mio.	50	35 Mio.	17

Hierbei wird davon ausgegangen, dass im Maximalausbau etwa 35 Mio. gesetztlich Krankenversicherte die Fachanwendung ePA von der Versicherten-Umgebung nutzen werden. Es wird je Versicherter eine Anzahl  von 17 Dokumenten pro Jahr erwartet.

Es wird geschätzt, dass je Akte pro Versicherter ein Speicherbedarf von a. 300 MB pro Jahr notwendig ist.

3.1.9 Betriebliche Anwendungsfälle

Betrieblicher Anwendungsfall: Update des Konnektors bzw. der Kartenterminals

Beim Ausrollen von Software auf Konnektor und Kartenterminals müssen durch Download vom Konfigurationsdienst Softwarepakete auf die Konnektoren verteilt werden. Tabelle 21 listet die Annahmen, die für den Mengenrahmen dieses betrieblichen Anwendungsfalls getroffen werden.

Tabelle 23: Mengenrahmen „Update Konnektor und Kartenterminals“

Größe	Wert	Quelle
Zeitraum, in dem ein Softwarepaket vom Konfigurationsdienst über den Download-Weg an sämtliche Konnektoren verteilt werden können muss.	5 * 24 h	Betriebliche Anforderung
maximale Größe eines Softwarepakets	1500 Mbyte	Konnektorhersteller

3.2 Bearbeitungszeiten

Der anwendungsfallübergreifende Bedarf für die Bearbeitungszeiten an den Außenschnittstellen der TI-Plattform wurde für den Erwartungswert pro Schnittstellenoperation abgestimmt.

Die Abstimmung erfolgte zweistufig, um Machbarkeit/Wirtschaftlichkeit und Bedarf in Einklang zu bringen. Im ersten Schritt wurden per Expertenschätzung die Leistungswerte für eine wirtschaftlich günstige Lösung bestimmt. Im zweiten Schritt wurde geprüft, ob mit diesen Leistungswerten der Bedarf der Fachanwendungen erfüllt werden kann.

Für den Produkttyp Konnektor kommen Bearbeitungszeiten durch das Fachmodul hinzu [gemSpec_FM_VSDM].

Für die Transportnetzanbindung über den Konnektor an Zentrale Dienste der TI-Plattform und Fachanwendungsspezifische Dienste setzt das Performance-Modell typische Bandbreiten an, die dann in Anforderungen zu Bearbeitungszeiten einfließen: Für Praxen einen asymmetrischen Zugang von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung (mit Round-Trip-Time von 50 msec) für Krankenhäuser einen symmetrischen Zugang von 2048 kbit/sec in Upload- und Download-Richtung (mit Round-Trip-Time von 40 msec).

3.2.1 Bearbeitungszeiten KOM-LE

Für KOM-LE müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle 22 angegebenen Mittelwerten sein.

Tabelle 24: Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall

Anwendungsfall	Datenmenge [KB]	Mittelwert [sec]
Empfängerdaten ermitteln	1	1,2
Nachricht schützen und an KOM-LE-Fachdienst senden	100	12,5
	25.600	260
Nachricht vom KOM-LE Fachdienst holen und aufbereiten	100	4,7
	25.600	38,5
Aufbau sicherer Kanal vom Clientmodul zum Fachdienst	(*)	3,9
Nachrichtenweiterleitung zwischen KOM-LE-Fachdiensten	(*)	(**)

(*) nicht relevant für die Bearbeitungszeit

(**) Nachrichten müssen spätestens 2 Stunden nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.

3.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)

Für NFDM müssen im stationären Einsatz unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle 23 angegebenen Mittelwertschranken sein.

Tabelle 25: Bearbeitungszeitvorgaben NFDM je Anwendungsfall

Anwendungsfall	Datenmenge [KB]	Mittelwert [sec]
NFD signieren (QES)	10,5	1,8
NFD schreiben	10,5	5,8
NFD lesen	10,5	7,3
NFD löschen	10,5	4,8
DPE schreiben	1,5	4,6
DPE lesen	1,5	4,3
DPE löschen	1,5	4,3

Für die Einsätze im mobilen Bereich sollen diese Vorgaben ebenfalls erreicht werden. Priorität hat der Anwendungsfall „NFD lesen“.

3.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement

Für eMP/AMTS müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle 24 angegebenen Mittelwertschranken sein.

Tabelle 26: Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall

Anwendungsfall	Datenmenge [KB]	Mittelwert [sec]
eMP/AMTS-Daten von eGK lesen	13,56	5,3
eMP/AMTS-Daten auf eGK schreiben	13,56	6,7

3.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)

Für ePA müssen unter den oben genannten Rahmenbedingungen der Mittelwerte der Bearbeitungszeit pro Anwendungsfall kleiner oder gleich den in Tabelle "ePA Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwertschranken sein.

Es werden nur die Anwendungsfälle betrachtet, die häufig in der LE-Umgebung Anwendung finden.

Tabelle 27: ePA Bearbeitungszeitvorgaben je Anwendungsfall

Anwendungsfall	Datenmenge [KB]	Mittelwert [sec]
Login des Versicherten in der LEI	(*)	9,5
Dokument in der LEI suchen	3	1,2
Dokument in der LEI löschen	2	1,1
Dokument in der LEI anzeigen	10	1,2
	100	2,0
	1000	10,5
	25600 (**)	30,0
Dokument in der LEI einstellen	10	1,8
	100	8,3
	1000	73,2
	25600 (**)	240,0

(*) nicht relevant für die Bearbeitungszeit

(**) Für das Anzeigen und Einstellen von 25 MB-Dokumenten in der LEI-Umgebung wird von einer Transportanbindung von 16 Mbit/s in Download-Richtung und 1024 Kbit/s in Upload-Richtung ausgegangen. 

Es wird bei den Anwendungsfällen "Dokument in der LEI suchen, löschen, anzeigen und einstellen" davon ausgegangen, dass ein Login bereits durchgeführt wurde. Sofern kein Login durchgeführt wurde, muss die Bearbeitungszeit für die Durchführung eines Logins mit berücksichtigt werden.

3.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung

Für die Tokenbasierte Authentisierung müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle 26 angegebenen Mittelwertschranken sein.

Tabelle 28: Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall

Anwendungsfall	Datenmenge [KB]	Mittelwert [sec]
I_IDP_Auth_Active_Client:: issue_Identity_Assertion	5	2,5
I_IDP_Auth_Active_Client:: renew_Identity_Assertion	20	2,5
I_IDP_Auth_Active_Client:: cancel_Identity_Assertion	20	0,5
I_IDP_Auth_Passive _Client:: signin	2	3,5
I_IDP_Auth_Passive_Client:: signout	<1	0,5
I_Local_IDP_Service:: sign_Token	5	2,5

3.3 Verfügbarkeiten

Die zu fordernde Verfügbarkeit richtet sich am Bedarf der Anwendungsfälle aus. Der höchste Bedarf entsteht in großen Krankenhäusern. Prinzipiell begrenzendes Element für die Verfügbarkeit ist das Transportnetz. Einzelne Krankenhäuser können sich für das obere Ende der am Markt erhältlichen Verfügbarkeit entscheiden, die mit 99,5 % angenommen wird. Es wird weiter angenommen, dass diese großen Krankenhäuser in der Lage sind, die Verfügbarkeit für Clientsystem und Konnektor mit Kartenterminals auf jeweils 99,9 % zu halten. Ist die Verfügbarkeit des Backend etwa genau so groß wie der für große Krankenhauseinrichtungen mögliche Beitrag von 99,3 %, dann wird ein ausgewogener Wert erreicht.

Tabelle 27 zeigt die so für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ erzielbare Gesamtverfügbarkeit von 98,5 %, die einer Ausfallzeit pro Monat von kleiner 7 Stunden entspricht. Sie ist notwendig und tragbar.

Tabelle 29: Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus

Anwendungsfall bzw. Produkttyp		Verfügbarkeit	Ausfallzeiten pro Monat in Stunden
VSD Lesen mit Aktualisierungsprüfung ohne Update		98,5%	< 7
	Clientsystem	99,9%	< 0,5
	Konnektor und eHealth-Kartenterminal	99,9%	< 0,5
	Transportnetz	99,5%	< 2,5
	Zentrale TI-Plattform: VPN-Zugangsdienst	99,9%	< 0,5
	Zentrale TI-Plattform: OCSP-Responder	99,9%	< 0,5
	Zentrale TI-Plattform: Zentrales Netz TI	99,9%	< 0,5
	Zentrale TI-Plattform: Namensdienst	99,9%	< 0,5
	VSDM Intermediär	99,8%	< 1
	Fachdienst VSDM (UFS)	99,8%	< 1

Für die Produkttypen der dezentralen Zone wird erwartet, dass sie selten ausfallen und in diesen seltenen Fällen rasch austauschbar sind. So wird erwartet [DKG2010], dass ein Konnektor, der im Krankenhaus eingesetzt wird, innerhalb von 15 Minuten ausgetauscht werden kann.

4 Leistungsanforderungen an die Produkttypen der TI

Das vorliegende Kapitel definiert die Leistungsanforderungen bzgl. der drei Performance-Dimensionen Durchsatz, Bearbeitungszeit und Verfügbarkeit für Produkttypen der TI. Die Anforderungen ergeben sich aus den in Kapitel 3 formulierten Bedarfen.

Grundlagen für die Performance-Vorgaben sind

• die in Kapitel 3 formulierten Bedarfe,
• die Definition der Produkttypen der TI-Plattform [gemKPT_Arch_TIP#5.2],
• die Definition ihrer Außenschnittstellen4 [gemKPT_Arch_TIP#5.3 und 5.4],
• die Nutzung der TI-Plattform-Operationen durch VSDM-Anwendungsfälle,
• die Annahmen zu Caching-Dauern in Tabelle 26

4) Im Rahmen der Produkttypspezifikationen werden die konzeptionellen Schnittstellen aus [gemKPT_Arch_TIP] durch technische Schnittstellen umgesetzt. Die Zuordnung der technischen auf die konzeptionellen Schnittstellen erfolgt in den Produkttypspezifikationen.

Tabelle 30: Caching-Dauer

ID	Größe	Dauer	Quelle
C1	OCSP-Caching-Dauer (non QES)	12 h	Annahme
C2	OCSP-Caching-Dauer (QES)	6 h	Annahme
C3	DNS-Caching-Dauer (Dienstlokalisierung und Namensauslösung)	12 h	Annahme

Alle Spitzenlastvorgaben beziehen sich auf den Produktivbetrieb mit 70 Mio. Versicherten.

Die Spitzenlastvorgaben für einen Produkttypen beziehen sich, soweit nicht explizit anders angegeben, auf alle Produktinstanzen des Produkttypen in Summe.

Bearbeitungszeitvorgaben unter Last

Aus Bedarfssicht sollen alle Produkttypen die Vorgaben für Bearbeitungszeiten unabhängig von den Vorgaben für ihr Lastverhalten erfüllen. D.h. dass die Bearbeitungszeitvorgaben letztlich unter Volllast erfüllt werden sollen.

Um die Überprüfbarkeit der Anforderungen beherrschbar zu halten, wird dieser Zusammenhang systematisch betrachtet und unter Beachtung der Bedarfssicht vereinfacht. Abbildung 5 unterscheidet hierzu vier Typen von Anforderungen danach, wie sehr die Anforderungen bzgl. Bearbeitungszeit und Lastverhalten ineinandergreifen.

 

Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen

Im einfachsten Fall (Quadrant 1) werden keine Anforderungen an Bearbeitungszeit und Lastverhalten gestellt, weil kein besonderer Überprüfungsbedarf jenseits funktionaler Tests besteht, etwa für Administrationsfunktionen, die weder mit einer nennenswerten Last ausgeführt werden noch notwendigerweise Bearbeitungszeitvorgaben einhalten müssen.

Im Quadrant 2 sind Anforderungen gruppiert, die dafür sorgen, dass die Produkttypen den benötigten Durchsatz (z. B. [GS-A_4161]) erreichen. Das betrifft ausschließlich Produkttypen der zentralen Zone der TI-Plattform.

Im Quadrant 3 sind Anforderungen gruppiert, die für jede Schnittstellen-Operation eines Produkttypen die lastfreie Einhaltung der Bearbeitungszeitvorgaben fordern (z. B. [GS-A_4346]).

Im Quadrant 4 sind schließlich Anforderungen gruppiert, welche die Einhaltung von Bearbeitungszeitvorgaben unter Last verlangen (z. B. [GS-A_4157], [GS-A_4159], [GS-A_4162] für Produkttypen der zentralen Zone der TI-Plattform).

4.1 Produkttypen der dezentralen Zone der TI-Plattform

An die Produkttypen der dezentralen Zone werden keine expliziten Verfügbarkeitsanforderungen gestellt5.

5) Ausnahme Konnektor für Krankenhäuser.

4.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT

Performance-Anforderungen an die Smardcards im Gesundheitswesen werden im Rahmen der Kartenspezifikationen gestellt.

4.1.2 Produkttyp Konnektor

Der Produkttyp Konnektor muss alle Einsatzumgebungen von einer Arztpraxis bis zu großen Krankenhäusern abdecken. Diese unterteilt Tabelle 4 in vier Klassen von Leistungserbringerumgebungen (LE-U1, LE-U2, LE-U3, LE-U4). Über das Lastmodell aus Kapitel 3.1.8 erhält man je Leistungserbringerumgebung die für jede Schnittstellenoperation des Konnektors zu erwartende Spitzenlast.

Tabelle "Tab_gemSpec_Perf_Konnektor" listet je Schnittstellenoperation zu den Spitzenlastvorgaben die Vorgabenwerte für Bearbeitungszeiten. Die Bearbeitungszeiten beinhalten die an den Kartenterminals und Karten anfallenden Zeiten, was der Steuerungsverantwortung des Konnektors Rechnung trägt.

Die im Folgenden formulierten Anforderungen sind so angelegt, dass sie die Vorgabenwerte möglichst gut erfüllen, aber auch die Machbarkeitsgrenzen berücksichtigen, die etwa beim konkurrierenden Zugriff des Konnektors auf eine SMC-B bestehen.

Tabelle 31: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben

Schnittstellenoperationen			Last		Bearbeitungszeit
			L E -U	Spitzen- lasten [1/h]	Größe der Anfrage-nachricht [kByte]	Mittelwert [msec]
Fachanwendung
	I_VSD_Service
		ReadVSD - mit Akt.-Prüfung, mit Update	1	1		6130
			2	1
			3	4
			4	11
		ReadVSD - mit Akt.-Prüfung, ohne Update	1	50		3940
			2	50
			3	175
			4	437
		ReadVSD - ohne Akt.-Prüfung				3820
		UpdateVSD - automat. Akt.-Prüfung, mit Update				5720
		UpdateVSD - automat. Akt.-Prüfung, ohne Update				3130
	I_NFD_Management
		NFD von eGK lesen	1	6	10,5	7260
			2	28
			3	115
			4	286
		NFD auf eGK schreiben	1	11	10,5	5780
			2	51
			3	213
			4	533
		NFD von eGK löschen	1	1	10,5	4800
			2	5
			3	21
			4	53
	I_DPE_Management
		DPE von eGK lesen	1	1	1,5	4300
			2	3
			3	14
			4	36
		DPE auf eGK schreiben	1	1	1,5	4590
			2	5
			3	20
			4	51
		DPE von eGK löschen	1	0,1	1,5	4260
			2	0,5
			3	2
			4	5
	I_IDP_Auth_Active_Client
		issue_Identity_Assertion			5	2500
		renew_Identity_Assertion			20	2500
		cancel_Identity_Assertion			20	500
	I_IDP_Auth_Passive_Client
		signin			2	3500
		signout			1	500
	I_Local_IDP_Service
		sign_Token			5	2500
	I_AMTS_Service
		ReadMP			30	5268
		WriteMP (mit C2C)			30	6625
		WriteMP (ohne C2C)			30	4020
Basisdienste
	I_Sign_Operations
		sign_Document			10	1010
			1	217	100	1030
			2	258
			3	351
			4	575
					1000	1440
		sign_Document (XAdES, XML_25MB, enveloped)		13	25000	10500
		sign_Document (CAdES, TIFF_25MB, detached)			25000	7300
		sign_Document (PAdES, PDFA_2b_25MB)			25000	7300
		verify_Document			10	1570
			1	217	100	1600
			2	258
			3	351
			4	575
					1000	1930
		verify_Document (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)		13	25000	9000
		verify_Document (CAdES, TIFF_25MB, IncludeRevocationInfo=false)			25000	9000
		verify_Document (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)			25000	10600
		external_Authenticate				885
		get_Certificate				220
	I_SAK_Operations
		sign_Document_QES (Stapelgröße 1)			10	3540
			1	17	100	3790
			2	65
			3	177
			4	442
					1000	4070
		sign_Document_QES (XAdES, XML_25MB, enveloped)			25000	12810
		sign_Document_QES (CAdES, TIFF_25MB, detached)			25000	9610
		sign_Document_QES (PAdES, PDFA_2b_25MB)			25000	9610
		sign_Document_QES (Stapelgröße 2, 2 * 100 kB Dokumente)	1	3	200	8870
			2	11
			3	30
			4	74
		verify_Document_QES			10	2580
			1	10	100	2610
			2	39
			3	113
			4	282
					1000	2940
		verify_Document_QES (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)			25000	10010
		verify_Document_QES (CAdES, TIFF_25MB, detached IncludeRevocationInfo=false)			25000	10010
		verify_Document_QES (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)			25000	11610
	I_KV_Card_Unlocking
		authorize_Card (no Cache)				2020
		authorize_Card (Cache)				1830
	I_Crypt_Operations
		encrypt_Document			10	1860
			1	217	100	1880
			2	258
			3	351
			4	575
					1000	2200
		encrypt_Document (XMLEnc, TIFF_25MB, ein Empfänger)		13	25000	10600
		encrypt_Document (CMS, TIFF_25MB, ein Empfänger)			25000	7800
		decrypt_Document			10	490
			1	217	100	510
			2	258
			3	351
			4	575
					1000	820
		decrypt_Document (XMLEnc, TIFF_25MB)		13	25000	8900
		decrypt_Document (CMS, TIFF_25MB)			25000	8900
	I_Cert_Verification
		verifyCertificate				1150
	I_Directory_Query
		search_Directory (TI-Plattform Dezentral)	1	200		2220
			2	300
			3	500
			4	1000

Die Tabelle "Tab_gemSpec_Perf_Konnektor" führt alle Schnittstellen des Konnektors auf, an die Performance-Anforderungen gestellt werden. Zu allen aufgeführten Schnittstellen sind Vorgaben an die Schranke für „Mittelwert“ der Bearbeitungszeit angegeben. Wenn die Bearbeitungszeit abhängig von der „Größe der Anfragenachricht“ ist, ist die zugehörige Spalte gefüllt. Lastvorgaben beschränken sich auf typische Nachrichtengrößen. Bei den Lastvorgaben wird nach den Leistungserbringerumgebungen LE-U1, LE-U2, LE-U3, LE-U4 unterschieden.

Zunächst wird die Einhaltung der Bearbeitungszeitvorgaben ohne Last gefordert (vgl. Abbildung 5: Quadrant 3):

GS-A_4346 - Performance – Konnektor in LE-U1 – Bearbeitungszeit lastfrei

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.

[<=]

GS-A_5096 - Performance – Konnektor in LE-U2 – Bearbeitungszeit lastfrei

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.

[<=]

GS-A_5097 - Performance – Konnektor in LE-U3 – Bearbeitungszeit lastfrei

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.

[<=]

GS-A_5098 - Performance – Konnektor in LE-U4 – Bearbeitungszeit lastfrei

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.

[<=]

Im nächsten Schritt werden die Lastangaben aus Tab_gemSpec_Perf_Konnektor berücksichtigt und Anforderungen zur Bearbeitungszeit unter Last gestellt (vgl. Abbildung 5: Quadrant 4).

Dabei wird berücksichtigt, dass die Spitzenlasten der VSDM-Anwendungsfälle und die zu den Anwendungsfällen Signatur/Verschlüsselung gemäß Bedarfsvorgabe nicht zur gleichen Zeit auftreten.

GS-A_4150 - Performance – Konnektor in LE-U1 – Parallele Verarbeitung VSDM

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle Tab_gemSpec_Perf_Konnektor einhalten, soweit diese durch den Konnektor zu verantworten sind.

Das Einhalten der Vorgabe wird durch die in Tabelle Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B definierten Tests für die Konstellationen mit einer SMC-B überprüft.
[<=]

GS-A_5099 - Performance – Konnektor in LE-U2 – Parallele Verarbeitung VSDM

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle Tab_gemSpec_Perf_Konnektor einhalten, soweit diese durch den Konnektor zu verantworten sind.

Das Einhalten der Vorgabe wird durch den in Tabelle Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B definierten Test für die Konstellation mit einer SMC-B überprüft.
[<=]

GS-A_5100 - Performance – Konnektor in LE-U3 – Parallele Verarbeitung VSDM

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle Tab_gemSpec_Perf_Konnektor einhalten, soweit diese durch den Konnektor zu verantworten sind.

Das Einhalten der Vorgabe wird durch die in Tabelle Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B definierten Tests für die Konstellationen mit einer SMC-B und zwei SMC-Bs überprüft.
[<=]

GS-A_5101 - Performance – Konnektor in LE-U4 – Parallele Verarbeitung VSDM

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle Tab_gemSpec_Perf_Konnektor einhalten, soweit diese durch den Konnektor zu verantworten sind.

Das Einhalten der Vorgabe wird durch die in Tabelle Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B definierten Tests für die Konstellationen mit einer SMC-B und zwei SMC-Bs überprüft.
[<=]

Tabelle 32: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B

Konstellation	Test
eine SMC-B	Der Konnektor muss eine Anzahl von n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec n = 10 Anfragen „ReadVSD – mit Akt.-Prüfung, ohne Update“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind: die schnellste Bearbeitungszeit < µ die langsamste Bearbeitungszeit < µ + (n - 1) * w die Summe der Bearbeitungszeiten < n * (µ + (n -1)/2 * w ) w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B. n ist die Zahl der parallel gestarteten Anfragen. µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle Tab_gemSpec_Perf_Konnektor.
zwei SMC-Bs	Der Konnektor muss in einer Konstellation mit zwei SMC-Bs eine Anzahl von n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec n = 10 Anfragen „ReadVSD – mit Akt.-Prüfung, ohne Update“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind: die schnellste Bearbeitungszeit < µ die Summe der Bearbeitungszeiten < n * µ + (p*(p-1) + q*(q-1)) / 2 * w mit p = (n – n mod 2)/2, q = (n + n mod 2)/2 w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B. n ist die Zahl der parallel gestarteten Anfragen. µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle Tab_gemSpec_Perf_Konnektor.

Hinweis: Der in den Anforderungen GS-A_4150, GS-A_5099, GS-A_5100, GS-A_5101 dargestellte Test soll den konkurrierenden Zugriff auf die SMC-B als knappe Ressource testen. Da die Situation im Fall der vielfach schnelleren HSMs nicht besteht, richtet sich die Testvorschrift an Konnektoren mit SMC-Bs und nicht an Konnektoren mit HSM-Bs.

Für die parallele Verarbeitung der Operationsaufrufe an den Basisdienstschnittstellen wird folgendes gefordert:

GS-A_4151 - Performance – Konnektor in LE-U1 – Parallele Verarbeitung

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle Tab_gemSpec_Perf_Konnektor  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungserbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.

[<=]

GS-A_5102 - Performance – Konnektor in LE-U2 – Parallele Verarbeitung

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle Tab_gemSpec_Perf_Konnektor  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungs-erbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.

[<=]

GS-A_5103 - Performance – Konnektor in LE-U3 – Parallele Verarbeitung

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle Tab_gemSpec_Perf_Konnektor  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungs-erbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.

[<=]

GS-A_5104 - Performance – Konnektor in LE-U4 – Parallele Verarbeitung

Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle Tab_gemSpec_Perf_Konnektor  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungserbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.

[<=]

Für die parallele Verarbeitung der Operationsaufrufe zur Tokenbasierten Authentisierung wird folgendes gefordert:

GS-A_5486 - Performance – Parallele Verarbeitung zur Tokenbasierten Authentisierung

Der Konnektor MUSS für eine reibungsfreie parallele Verarbeitung der Aufrufe der Operationen an den Schnittstellen I_IDP_Auth_Active_Client, I_IDP_Auth_Passive_Client und I_Local_IDP_Service sorgen, was wie folgt getestet wird: Es werden jeweils zwei Aufrufe zu I_IDP_Auth_Active_Client:issue_Identity_Assertion, ein Aufruf zu I_Local_IDP_Service:sign_Token gestartet. Die Messung der Bearbeitungszeiten ist 100 Mal auszuführen. Es sind die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Konnektor einzuhalten.

[<=]

GS-A_5487 - Performance – Konnektor – Parallele Verarbeitung AMTS

Der Konnektor MUSS parallel eintreffende AMTS-Anfragen funktional korrekt bearbeiten und die Antwortzeitvorgaben gemäß Tabelle Tab_gemSpec_Perf_Konnektor einhalten, soweit diese durch den Konnektor zu verantworten sind.

Das Einhalten der Vorgabe wird durch die in Tabelle Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS definierten Tests für die Konstellationen mit einer SMC-B überprüft.

[<=]

Tabelle 33: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS

Konstellation

Test

eine SMC-B

Der Konnektor muss eine Anzahl von n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec n = 10 Anfragen „ReadMP“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind: die schnellste Bearbeitungszeit < µ die langsamste Bearbeitungszeit < µ + (n - 1) * w die Summe der Bearbeitungszeiten < n * (µ + (n -1)/2 * w ) w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B. n ist die Zahl der parallel gestarteten Anfragen. µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle Tab_gemSpec_Perf_Konnektor.

Hinweis: Die Bearbeitungszeitvorgaben wurden unter der Annahme bestimmt, dass die Implementierung hinsichtlich Caching und Parallelisierbarkeit innerhalb eines Anwendungsfalls optimiert sind.

Stapelsignatur und gSMC-Ks

Bei der Operation sign_Document_QES in Tabelle Tab_gemSpec_Perf_Konn wurde gemäß Lastmodell aus Kapitel 3.1.7 davon ausgegangen, dass 25% der Signaturen per Stapelsignatur (Annahme Lastmodell: Stapelgröße 2) erfolgen. Tabelle 32 stellt für diese Situation dar, wie groß die Wahrscheinlichkeit ist, dass n Stapelsignaturen oder mehr parallel erfolgen müssen.

Tabelle 34: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell

Lastvorgaben		Mittelwert Bearbeitungs- zeit [msec]	Sp.Last * Mittelwert Bearbeitungs- zeit [msec]	Wahrscheinlichkeit in % für n oder mehr parallele Bearbeitungen
L E -U	Spitzen- lasten [1/h]			n=1	n=2	n=3	n=4	n=5	n=6
1	3	8870	0,01	1	0	0	0	0	0
2	11		0,03	3	0	0	0	0	0
3	30		0,07	7	0	0	0	0	0
4	74		0,18	17	1	0	0	0	0

In Tabelle 32 sind alle Wahrscheinlichkeiten über 1% rot markiert, weil hier davon ausgegangen wird, dass die Vorgaben nur erreicht werden können, wenn eine vollständige parallele Verarbeitung der Anfragen erfolgt. Geht man davon aus, dass pro gSMC-K drei logische Kanäle für die parallele Verarbeitung von Stapelsignaturen zur Verfügung stehen, dann folgt daraus, dass für das angenommene Lastszenario der Einsatz einer gSMC-K ausreichend ist.

Der Konnektor muss jedoch auch auf ein geändertes Nutzungsverhalten vorbereitet sein, wie es durch verstärkte Nutzung oder systematische Häufung von Anfragen gegen Schichtende oder durch eine verstärkte Nutzung der Stapelsignatur hervorgerufen werden kann. Angenommen in einer Leistungserbringerumgebung wird dadurch (zusätzlich zum angenommenen Spitzenlastfaktor) die Last um den Faktor 30 erhöht, dann stellt sich die Situation aus Tabelle 30 wie folgt dar:

Tabelle 35: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch

Last		Mittelwert Bearbeitungs- zeit [msec]	Sp.Last * Mittelwert Bearbeitungs- zeit [msec]	Wahrscheinlichkeit in% für n oder mehr parallele Bearbeitungen
L E -U	Sp.-lasten [1/h]			1	2	3	4	5	6	7	8	9	10	11	12
1	90	8870	0,2	19	2	0	0	0	0	0	0	0	0	0	0
2	330		0,8	55	19	5	1	0	0	0	0	0	0	0	0
3	900		2,2	89	64	37	18	7	2,4	1	0	0	0	0	0
4	2220		5,4	100	97	91	79	63	46	31	18	10	5	2	1

Um auch die perspektivischen Lastbedingungen erfüllen zu können, wird daher gefordert:

GS-A_5059 - Performance – Stapelsignatur Konnektor für LE-U1 im Auslieferungszustand

Der Konnektor MUSS im Auslieferungszustand für den Einsatz in der Leistungserbringerumgebung LE-U1 die Bearbeitungszeitvorgaben unter Last für LE-U1 gemäß Tabelle Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch erfüllen.

[<=]

GS-A_5105 - Performance – Stapelsignatur Konnektor für LE-U2 im Auslieferungszustand

Der Konnektor MUSS im Auslieferungszustand für den Einsatz in der Leistungserbringerumgebung LE-U2 die Bearbeitungszeitvorgaben unter Last für LE-U2 gemäß Tabelle Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch erfüllen.

[<=]

Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens zwei gSMC-Ks ausgestattet ist.

GS-A_5036 - Performance – Stapelsignatur Konnektor für LE-U3

Der Konnektor MUSS für den Einsatz in der Leistungserbringerumgebung LE-U3 die Bearbeitungszeitvorgaben unter Last gemäß Tabelle Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch erfüllen. Diese Leistung MUSS er entweder bereits im Auslieferungszustand erbringen oder durch Nachrüstung im Feld mit weiteren gSMC-Ks erbringen können.

[<=]

Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens drei gSMC-Ks ausgestattet ist.

GS-A_5106 - Performance – Stapelsignatur Konnektor für LE-U4

Der Konnektor MUSS für den Einsatz in der Leistungserbringerumgebung LE-U4 die Bearbeitungszeitvorgaben unter Last gemäß Tabelle Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch erfüllen. Diese Leistung MUSS er entweder bereits im Auslieferungszustand erbringen oder durch Nachrüstung im Feld mit weiteren gSMC-Ks erbringen können.

[<=]

Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens vier gSMC-Ks ausgestattet ist.

Damit zugelassene Konnektoren auch im Zusammenspiel mit G2-Karten unterschiedlicher CV-Roots die Anwendungsfälle aus Tab_gemSpec_Perf_Konnektor in akzeptabler Zeit durchführen, wird folgende Anforderung im Kontext einer definierten Rahmenbedingung für die Test- und Zulassungsverfahren gestellt:

GS-A_5247 - Performance – Konnektor – G2-Karten mit unterschiedlicher CV-Root

Der Konnektor MUSS sämtliche Performancevorgaben mit den Vorgabezeiten aus Tab_gemSpec_Perf_Konnektor auch für die Ausführung mit G2-Karten mit unterschiedlicher CV-Root erfüllen.

Rahmenbedingung für diese Vorgabe ist, dass in maximal einem von hundert Anwendungsfällen die CV-Root der zu authentifizierenden Karte nicht auf der authentifizierenden Karte vorhanden ist.
[<=]

Rahmenbedingungen für die Messungen:

Abbildung 6: Messpunkte zur Konnektor Performance-Messung

Die dem Konnektor zugerechneten Bearbeitungszeiten sind die Antwortzeit auf einen Schnittstellenaufruf im Clientsystem (tE – tA) abzüglich der Summe aller Antwortzeiten von FA-spezifischen Diensten (Summe ti,e – ti,a). Definition der Messzeitpunkte:

• tA ist der Beginn des Aufrufs im Clientsystem an die Schnittstelle des Konnektors
• tE ist der Zeitpunkt nach vollständig empfangener Antwort
• ti,e ist der Beginn der Übertragung des Requests (etwa per Snifferlog)
• ti,a ist der Zeitpunkt nach vollständig empfangener Response (etwa per Snifferlog)

Alle übrigen Aufrufe liegen im Verantwortungsbereich des Konnektors. Tatsächlich verantworten kann er nur die Koordination der Aufrufe nicht das tatsächliche Antwortzeitverhalten, das von den koordinierten dezentralen Produkttypen (Kartenterminals und Smartcards) abhängt. Für die Antwortzeitvorgaben wurden daher dezentrale Produkttypen mit einem normierten Verhalten gewählt, das wie folgt definiert ist:

• Kartenterminal und Karten mit normierten Bearbeitungszeiten gemäß Tabelle Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente.
• Beteiligte Karten sind gesteckt, SMC-B ist bzw. SMC-Bs sind freigeschaltet.
• Verbindungsaufbau ist bereits erfolgt und zugehörige OCSP-Responses (SSL Server Zertifikat und VPN-Konzentrator-Zertifikat) sind gecacht.
• Bei den VSDM-Anwendungsfällen wird davon ausgegangen, dass keine gültige OCSP-Statusauskunft über das eGK-AUT-Zertifikat im OCSP-Cache vorliegt.
• Bei den Operationen verify_Document, verify_Document_QES und encrypt_Document wird jeweils davon ausgegangen, dass keine gültige OCSP-Statusauskunft über die zu prüfenden Zertifikate vorliegen.
• Für die Abfrage der Sperrstatusinformation wird von folgenden normierten Bearbeitungszeiten ausgegangen, welche die Übertragungszeiten des Netzes inkludieren: 1095 msec für OCSP-Responder desTSP-X.509nonQES, 600 msec für OCSP-Proxy, 2105 msec für OCSP-Responder des TSP-X.509QES.

• Für die Messung wird eine Bandbreite von 1Gbit/sec zwischen Clientsystem und Konnektor angenommen.
• Wenn der Konnektor MTOM unterstützt, müssen die Performancevorgaben für Signatur- und Verschlüsselungsdienst nur unter Einsatz von MTOM nachgewiesen werden.
• Die Performancevorgaben für den Signaturdienst sind ohne Signaturproxy nachzuweisen.
• Die Performancevorgaben aus Tab_gemSpec_Perf_Konnektor für die Basisdienste I_Sign_Operations und I_Crypt_Operations sind an Hand folgender Referenzdokumente nachzuweisen:
  • XML_25MB
  • XML_1MB
  • XML_100KB
  • XML_10KB
  • TIFF_25MB
  • TIFF_1MB
  • PDFA_2b_25MB_Bilder_und_Text
  • PDFA_2b_1MB_Komplex
  • TEXT_100KB
  • TEXT_10KB

Die konkreten Dokumente zu diesen Bezeichnern legt die Dokumentenlandkarte fest.

• Für die Operationen ReadMP und WriteMP wird davon ausgegangen, dass jeweils eine Card-to-Card-Authentisierung (C2C) zwischen SM-B und eGK erforderlich ist. Werden für eine gesteckte eGK ReadMP und WriteMP in Folge (innerhalb einer eGK-Kartensitzung) ausgeführt, wird davon ausgegangen, dass C2C nur einmal in der Operation ReadMP durchgeführt wird.

Netzwerkebene

Der Konnektor ermöglicht neben der Anbindung fachanwendungsspezifischer Dienste, der Anbindung an Bestandsnetze auch die Nutzung eines Internetzugangs.

GS-A_4152 - Performance - Konnektor – Bandbreitenunterstützung

Der Produkttyp Konnektor MUSS die am Markt üblichen Bandbreiten für Internetzugänge unterstützen.

[<=]

GS-A_5509 - Performance – Konnektor (Ausbaustufe VSDM) – IPSec-Tunnel TI und SIS

Der Produkttyp Konnektor MUSS einen IPSec-Durchsatz von mindestens
25 Mbit/s bidirektional und kontinuierlich erreichen. Der Wert gilt in Summe für IPSec-Tunnel TI und SIS.

[<=]

Die Anforderung GS-A_5509 gilt ausschließlich für den Konnektor (Ausbaustufe VSDM).

GS-A_5543 - Performance – Konnektor – IPSec-Tunnel TI und SIS

Der Produkttyp Konnektor MUSS einen IPSec-Durchsatz von mindestens
30 Mbit/s bidirektional und kontinuierlich erreichen. Der Wert gilt in Summe für IPSec-Tunnel TI und SIS.

[<=]

Die folgende Abbildung erläutert die Durchsatzmessung.

 

Abbildung 7: Messaufbau zum IPSec-Durchsatzmessung

Der geforderte IPSec-Durchsatz wird unter folgenden Bedingungen ermittelt:

• Über Clientsystem<->Konnektor<->VPNKonzentratorMockup wird zwischen Clientsystem und VPNKonzentratorMockup mittels iperf3 der Durchsatz im Transport über TCP ermittelt.
• IPCompression ist durch Konfiguration am VPNKonzentratorMockup ausgeschaltet.

Verfügbarkeit

Aus dem Bedarf, einen nicht funktionsfähigen Konnektor im Krankenhaus zeitnah gegen einen bereitstehenden Ersatzkonnektor austauschen zu können, leitet sich folgende Anforderung ab:

GS-A_4153 - Performance – Konnektor in LE-U1 – Verfügbarkeit

Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U1 20 Kartenterminals zu berücksichtigen.
[<=]

GS-A_5107 - Performance – Konnektor in LE-U2 – Verfügbarkeit

Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U2 45 Kartenterminals zu berücksichtigen.
[<=]

GS-A_5108 - Performance – Konnektor in LE-U3 – Verfügbarkeit

Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U3 125 Kartenterminals zu berücksichtigen.
[<=]

GS-A_5109 - Performance – Konnektor in LE-U4 – Verfügbarkeit

Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U4 300 Kartenterminals zu berücksichtigen.
[<=]

GS-A_5332 - Performance – Konnektor – Robustheit gegenüber Lastspitzen

Der Konnektor MUSS bei Lastspitzen oberhalb der für ihn definierten Spitzenlasten verfügbar bleiben.

[<=]

Aktualisierung des Vertrauensraumes

Die Aktualisierung des Vertrauensraumes geschieht in den Konnektoren automatisch. Folgende Anforderung sorgt dafür, dass es nicht zu einer unnötig zeitlich gebündelten Aktualisierung des Vertrauensraumes aller Konnektoren kommt, was zu einer unverhältnismäßig großen Spitzenlast für den OCSP-Dienst des TSL-Signerzertifikats führen würde.

GS-A_4356 - Performance - Konnektor –Aktualisierung Vertrauensraum

Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI im Rahmen der TSL-Aktualisierung ausgelösten Downloads der TSL und die OCSP-Responder-Aufrufe zum Prüfen des TSL-Signerzertifikats möglichst gleichmäßig über den Tag verteilt sind. Die zu erwartende Spitzenlast darf nicht größer sein als bei einer Gleichverteilung über eine Stunde.

[<=]

Aktualisierung der BNetzA-VL

Wie beim Download der TSL muss beim Download der BNetzA-VL durch den Konnektor für die Vermeidung zu hoher Spitzenlasten gesorgt werden.

GS-A_5490 - Performance – Konnektor – Aktualisierung BNetzA-VL

Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI im Rahmen der BNetzA-VL-Aktualisierung ausgelösten Downloads der BNetzA-VL möglichst gleichmäßig über den Tag verteilt sind. Pro Konnektorinstanz darf maximal ein vollständiger Download einer BNetzA-VL pro Tag erfolgen. Die zu erwartende Spitzenlast darf nicht größer sein als bei einer Gleichverteilung über vier Stunden.
[<=]

Software Download

Ebenso wie bei der automatischen Aktualisierung des Vertrauensraumes gilt es beim automatisierten Download von Softwarepaketen unnötige Lastspitzen zu vermeiden:

GS-A_5013 - Performance – Konnektor – Software Download

Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI automatisiert ausgelösten Downloads von Softwarepaketen möglichst gleichmäßig über den Tag verteilt starten.

[<=]

Performance Logging

Zur Unterstützung der Performance-Analyse wird die Erfassung der Bearbeitungszeiten pro Aufruf in einem konfigurierbaren Erfassungszeitraum ermöglicht.

GS-A_5130 - Performance – Konnektor – Performance Logging

Der Produkttyp Konnektor MUSS ein Performance Logging für alle fachlichen und administrativen Anwendungsfälle erlauben. Über die Managementschnittstelle des Konnektors muss das Performance Logging per Konfiguration ein- und ausschaltbar sein (Default-Wert: ausgeschaltet).

Logging pro Anwendungsfallausführung

Für jede Ausführung eines Anwendungsfalls (etwa durch Aufruf einer Operation an der Außenschnittstelle des Konnektors) sind folgende Werte zu erfassen:

• Eindeutige Aufrufkennung
• Bezeichnung aufgerufene Operation
• Startzeitpunkt der Verarbeitung (Zeitpunkt, wenn letztes Bit von Konnektor empfangen wurde)
• Ausführungsdauer (in ms), berechnet als Differenz zwischen Endezeitpunkt (Zeitpunkt, wenn erstes Bit an den Aufrufer zurückgesendet wird) und Startzeitpunkt.
• Anzahl der Bytes in der Aufrufnachricht
• für alle Bearbeitungszeiten von Leistungen, die durch Aufruf von durch andere Produkttypen erbrachte Teiloperationen entstehen:
  • Eindeutige Aufrufkennung
  • Bezeichner des aufgerufenen Produkttyps (mit Werten aus Tab_gemSpec_Perf_Produkttypen)
  • Bezeichnung aufgerufene Teiloperation (im Fall von Kartenoperationen der Header des Kartenkommandos)
  • Startzeitpunkt der Verarbeitung (Zeitpunkt, wenn erstes Bit an den aufgerufenen Produkttypen gesendet wird)
  • Ausführungsdauer (in ms), berechnet als Differenz zwischen Endezeitpunkt (Zeitpunkt, wenn letztes Bit vom Konnektor empfangen wurde) und Startzeitpunkt.
  • Im Fall von Kartenkommandos zusätzlich: Anzahl der Bytes in der Aufrufnachricht der Teiloperation
  • Im Fall von Kartenkommandos zusätzlich: Anzahl der Bytes in der Antwortnachricht der Teiloperation

[<=]

Skalierbarkeit

Um die Skalierbarkeit des Konnektors auf weitere Anwendungen zu unterstützen, werden folgende Anforderungen gestellt:

GS-A_5325 - Performance – Konnektor – Kapazitätsplanung

Der Konnektorhersteller MUSS die internen Ressourcen des Konnektors (Prozessor, Hauptspeicher, Persistenter Speicher, etc.) so wählen, dass die Performance-Anforderungen für neue Anwendungen durch alleiniges Update der Firmware erreicht werden können.

Dabei muss der Konnektor den Ressourcenbedarf von 8 durchschnittlichen Anwendungen für die vorgesehene Leistungserbringerumgebung abdecken. Der Ressourcenbedarf einer durchschnittlichen Anwendung wird als der Gesamtressourcenbedarf der gemäß Tabelle Tab_gemSpec_Perf_Konnektor
bereitzustellenden Performanceleistung (VSDM, KOM-LE, QES) geteilt durch 3 definiert.

Den konkret ermittelten Ressourcenbedarf muss der Hersteller in einem Skalierungskonzept darstellen.

Das Skalierungskonzept muss

• alle internen Ressourcen des Konnektors (Prozessor, Hauptspeicher, Persistenter Speicher, etc.) explizit benennen, die zu einem Engpass bei der Ausführung zusätzlich aufgebrachter Anwendungen führen können,
• für jede der internen Ressourcen angeben, wie groß die für Anwendungen zur Verfügung stehende Kapazität ist,
• angeben, wie groß der Bedarf für 8 durchschnittliche Anwendungen ist, wie er berechnet wird und wie er gedeckt wird.

[<=]

GS-A_5326 - Performance – Konnektor – Hauptspeicher

Der Konnektor SOLL einen Hauptspeicher von mindestens 2 GByte haben.

[<=]

GS-A_5327 - Performance – Konnektor – Skalierbarkeit

Der Konnektor MUSS die von 8 durchschnittlichen Anwendungen erzeugte Last im vorgegebenen Bearbeitungszeitrahmen für die vorgesehene Leistungserbringerumgebung bedienen können. Dabei wird die erzeugte Last einer durchschnittlichen Anwendung als die durch Tabelle Tab_gemSpec_Perf_Konnektor definierte Last (VSDM, KOM-LE, QES) geteilt durch 3 definiert.

[<=]

Der Test von [GS-A_5327] erfolgt für den VSDM-Konnektor anhand eines QES-Produktmusters. Das QES-Produktmuster muss dafür funktional nur soweit implementiert sein, dass eine Überprüfung der Bearbeitung paralleler Requests unter der Ziellast möglich ist. Welche Tests durchgeführt werden und welche Eigenschaften dafür beim QES-Produktmuster erforderlich sind, beschreibt „Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors“.

Der Test von [GS-A_5327] erfolgt für den QES-Konnektor vom Verfahren her analog den Tests für den VSDM-Konnektor. Getestet wird an Hand eines breiteren Spektrums von Signatur- und Verschlüsselungsverfahren, beschrieben in „Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors“.

TLS-Verbindungsaufbau

GS-A_5328 - Performance – Konnektor – TLS-Handshake

Der Konnektor MUSS bei jedem TLS-Handshake die von ihm in Summe verursachten Zeiten im Fall beidseitiger Authentisierung unter 2 sec und im Fall einseitiger Authentisierung unter 1,5 sec halten. Die Anforderung gilt unabhängig davon, ob der Konnektor als TLS-Server oder TLS-Client agiert.

[<=]

GS-A_5333 - Performance – Konnektor – TLS Session Resumption 1

Der Konnektor MUSS TLS Session Resumption mittels Session-ID gemäß RFC5246 nutzen, um für den wiederholten Aufbau von TLS-Verbindungen zu fachanwendungsspezifischen Diensten oder zentralen Diensten der TI-Plattform die bereits ausgehandelten TLS-Session wiederzuverwenden und damit den TLS-Handshake abzukürzen, sofern TLS-Session Resumption vom jeweiligen Kommunikationspartner angeboten wird.

[<=]

GS-A_5334 - Performance – Konnektor – TLS Session Resumption 2

Der Konnektor MUSS TLS Session Resumption mittels Session-ID gemäß RFC5246 für TLS-gesicherte Verbindungen zum Clientsystem unterstützen, um für den wiederholten Aufbau von TLS-Verbindungen die bereits ausgehandelten TLS-Session wiederzuverwenden und damit den TLS-Handshake abzukürzen.

[<=]

Signaturproxy

GS-A_5519 - SigProxy: Performance – TLS-Handshake

Der Signaturproxy MUSS bei jedem TLS-Handshake die von ihm in Summe verursachten Zeiten im Fall beidseitiger Authentisierung unter 1,0 sec und im Fall einseitiger Authentisierung unter 0,5 sec halten. Rahmenbedingung ist die Installation des Signaturproxys auf einem durchschnittlichen PC.

[<=]

GS-A_5520 - SigProxy: Performance – TLS Session Resumption 1

Der Signaturproxy MUSS TLS Session Resumption mittels Session-ID gemäß RFC5246 nutzen, um für den wiederholten Aufbau von TLS-Verbindungen zum Konnektor die bereits ausgehandelten TLS-Sessions wiederzuverwenden und damit den TLS-Handshake abzukürzen.

[<=]

GS-A_5521 - SigProxy: Performance – Weiterleiten von Nachrichten

Der Signaturproxy MUSS Nachrichten, soweit es im Arbeitsablauf möglich ist, unverzüglich weiterleiten.

Die Einhaltung der Vorgabe wird durch folgende Messung überprüft: Mit den Dokumenten aus Tabelle Tab_gemSpec_Perf_Signaturproxy_1 wird die Operation SignDocument mit dem Parameter TvMode=NONE jeweils mit und ohne Signaturproxy ausgeführt. Die Differenz der Ausführungszeiten auf dem Clientsystem werden über 1000 Messungen pro Dokument bestimmt. Der Mittelwert der Differenzen muss kleiner als die in Tab_gemSpec_Perf_Signaturproxy_1 angegebene „Maximal erlaubte mittlere Differenz“ sein. Rahmenbedingung ist die Installation des Signaturproxys gemeinsam mit dem Clientsystem auf einem durchschnittlichen PC.
 

Tabelle 36: Tab_gemSpec_Perf_Signaturproxy_1

Dokument (konkretes Dokument legt die Dokumentenlandkarte fest)	Maximal erlaubte mittlere Differenz [msec]
TIFF_25MB	2000
TIFF_1MB	140
TEXT_100KB	70
TEXT_10KB	50

[<=]

GS-A_5522 - SigProxy: Performance – Validierung auf Anzeigbarkeit

Der Signaturproxy MUSS bei der Validierung auf einfache oder vollständige Anzeigbarkeit die Performancevorgaben aus Tab_gemSpec_Perf_Signaturproxy_2 für die mittlere Dauer der Validierung einhalten. Rahmenbedingung ist die Installation des Signaturproxys auf einem durchschnittlichen PC.
Der Signaturproxy MUSS die Dauer jeder Validierung auf einfache oder vollständige Anzeigbarkeit protokollieren. Diese Protokollierung muss per Konfiguration ein und ausschaltbar sein (default: ausgeschaltet).
 

Tabelle 37: Tab_gemSpec_Perf_Signaturproxy_2

Dokument (konkretes Dokument legt die Dokumentenlandkarte fest)	Maximal erlaubte mittlere Dauer [msec]
TIFF_25MB	1500
TIFF_1MB	1500
PDFA_2b_25MB_Bilder_und_Text	1000
PDFA_2b_1MB_Komplex	3500

[<=]

Definition des Leistungsniveaus eines „durchschnittlichen PC“: Intel Core i5-4690; 3,5 GHz; 8 GB RAM.

4.1.2.1 Fachmodul ePA

Die Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" definiert für die Schnittstellenoperationen des Fachmodules ePA die Spitzenlastvorgaben mit den jeweilig einzuhaltenden Bearbeitungszeiten.

Tabelle 38: Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben

Schnittstellenoperationen		Last		Bearbeitungszeit
		L E -U	Spitzen- lasten [1/h]	Größe der Anfrage-nachricht [kByte]	Mittelwert [msec]
PHRService
	find	1	7	3	115
		2	5
		3	14
		4	35
	getDocuments	1	1	10	275
		2	1
		3	3
		4	6
				100	290
		1	5	1000	600
		2	3
		3	6
		4	15
				25000	8680
	putDocuments	1	1	10	470
		2	1
		3	3
		4	8
				100	485
		1	1	1000	805
		2	7
		3	18
		4	44
				25000	9205
	removeDocuments	1	1	2	115
		2	1
		3	2
		4	6
	updateDocumentSet			11	115
PHRManagementService
	requestFacilityAuthorization				18715

A_17490 - Performance - Fachmodul ePA - Bearbeitungszeit

Das Fachmodul ePA MUSS die Bearbeitungszeitvorgaben aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" erfüllen.

Das Fachmodul ePA MUSS für die Zulassung den Nachweis für eine Sequenz von 100 aneinander folgende Anfragen je Schnittstellenoperation erbringen. Hierbei darf die mittlere Bearbeitungszeit nicht größer als die in Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" definierte mittlere Bearbeitungszeit sein.. Ebenfalls müssen die Aufrufe innerhalb der definierten Bearbeitungszeit korrekt bearbeitet werden. Es wird davon ausgegangen, das ein Login bereits durchgeführt worden ist.

[<=]

A_16174 - Performance - Fachmodul ePA - Bearbeitungszeit für Login

Das Fachmodul ePA MUSS für die Schnittstellenoperationen aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" das implizite Login von 7,7 Sekunden zusätzlich in die Bearbeitungszeit der Schnittstellenoperationen mit berücksichtigen. Sollte das Login schon durchgeführt worden sein, gilt für die Schnittstellenoperationen die maximale mittlere Bearbeitungszeit aus der Tabelle Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben.

[<=]

Beispielsweise ist für die Ausführung der Operation PHRService::find mit Berücksichtigung des impliziten Logins eine Bearbeitungszeitvorgabe unter 7815 ms einzuhalten.

A_17491 - Performance - Fachmodul ePA - Parallele Verarbeitung

Das Fachmodul ePA MUSS parallel eintreffende Anfragen an der Schnittstelle PHRService funktional korrekt bearbeiten und die Antwortzeitvorgaben aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" einhalten. Mehrere Anfragen gelten dann als parallel, wenn sie in einem Zeitraum von maximal 5 msec an der Schnittstelle PHRService eingehen.

Das Fachmodul ePA MUSS für die Zulassung die Testfälle aus der Tabelle Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung" für die jeweilige Leistungserbringer-Umgebung bestehen.

Tabelle 39 : Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung

LE-Umgebung	Test
LE-U1 - LE-U2	Das Fachmodul ePA muss für diese Leistungserbringer-Umgebungen mindestens 2 parallel eintreffende Anfragen funktional korrekt bearbeiten. Für den Nachweis werden folgende Testfälle überprüft: - 2 parallel eintreffende getDocuments Anfragen (10kB und 25000kB) - 2 parallel eintreffende putDocuments Anfragen (10kB und 25000kB) - 1 getDocuments und 1 putDocuments parallel eintreffende Anfragen - 1 find und 1 getDocuments parallel eintreffende Anfragen
LE-U3 - LE-U4	Das Fachmodul ePA muss für diese Leistungserbringer-Umgebungen mindestens 4 parallel eintreffende Anfragen funktional korrekt bearbeiten. Für den Nachweis werden folgende Testfälle überprüft: - 4 parallel eintreffende getDocuments Anfragen - 4 parallel eintreffende putDocuments Anfragen -  2 getDocuments und 2 putDocuments parallel eintreffende Anfragen - 2 find und 2 getDocuments parallel eintreffende Anfragen

[<=]

A_17803 - Performance - Fachmodul ePA - Bedingungen für die Messung

Das Fachmodul ePA MUSS die folgenden Bedingungen einhalten:

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

Rahmenbedingungen für die Messung
Die dem Fachmodul ePA zugerechneten Bearbeitungszeiten für die Schnittstelle PHRService ist die Zeitspanne vom Senden einer Request bis zum Eingang der zugehörigen Response der Schnittstellenoperation an der  Schnittstelle zum Clientsystem abzüglich der Summe aller Verarbeitungszeiten von ePA-spezifischen Diensten.

Die dem Fachmodul ePA zugerechneten Bearbeitungszeiten für die Schnittstelle PHRManagementService sind die Antwortzeiten für einen Request-Response Zyklus. Hierbei muss die Nutzerinteraktion (PIN-Eingabe) rausgerechnet werden.
[<=]

4.1.3 Produkttyp eHealth-Kartenterminal

GS-A_4154 - Performance – Kartenterminal – Bearbeitungszeit

Der Produkttyp Kartenterminal SOLL die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe erfüllen. Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.

[<=]

 

Tabelle 40: Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe

Schnittstellenoperation			Antwortzeitvorgaben
			Datenmenge [Byte]	Mittelwert [msec]	99%-Quantil [msec]
Infrastrukturdienste
	I_KT_Communication
		transfer_APDU(readBinary)	2000	150	240
		transfer_APDU(updateBinary)	2000	150	240

Rahmenbedingungen für die Messungen:

Abbildung 8: Messpunkte zur Kartenterminal Performance-Messung

Zur Messung werden Kommandos sequentiell gesendet, eine Parallelisierung von Kommandos durch das eHealth-Kartenterminal wird nicht betrachtet.

Der Messaufbau skizziert in Abbildung 8 besteht aus drei Komponenten: dem Konnektor (oder Konnektorsimulator), dem zu messenden Kartenterminal sowie einer normierten Karte.

Das zu messende Kommando wird zum Kartenterminal, in dem die normierte Karte steckt, gesendet. Der Zeitpunkt, bei dem das erste Byte des ersten Pakets des Kommando-Requests im Netzwerk übertragen wird, definiert den Beginn der Messung tA. Das Ende der Messung ist durch den Zeitpunkt tE bestimmt, wenn das letzte Byte des letzten Pakets der Kommando-Response empfangen wird.

Die verwendete normierte Karte verhält sich elektrisch, mechanisch und protokolltechnisch konform zur eGK-Spezifikation und wird über einen Messadapter in das zu messende Kartenterminal gesteckt. An dem Messadapter wird dabei die reine Kartenlaufzeit für das zu messende Kommando messtechnisch ermittelt (tK = tEK – tAK, mit tAK als dem Zeitpunkt der Übertragung des ersten Bytes des Kommandos und tEK dem Zeitpunkt der Versendung des letzten Bytes der zugehörigen Response).

Damit ergibt sich durch Rechnung die ermittelte Bearbeitungszeit des eHealth-Kartenterminals (tKT), in Abhängigkeit des Kommandos c wie folgt:

tKT(c) = (tE –tA)  – tK

TLS-Verbindungsaufbau

GS-A_5329 - eHealth-KT Performance – TLS-Handshake I

Der Produkttyp eHealth-Kartenterminal SOLL sicherstellen, dass die durch ihn verursachte Zeit während jedes TLS-Handshakes insgesamt maximal 5 sec beträgt.

Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.
[<=]

GS-A_5330 - eHealth-KT Performance – TLS-Handshake II

Der Produkttyp eHealth-Kartenterminal DARF bei der durch ihn verursachten Zeit während des TLS-Handshakes insgesamt 45 sec NICHT überschreiten.

[<=]

Die Anforderung [GS-A_5330] ist somit insbesondere auch von Geräten zu erfüllen, die auf bereits zugelassenen eHealth-BCS-Geräten basieren.

Rahmenbedingungen für die Messungen der Dauer des TLS-Handshakes:

Zur Messung der Dauer des TLS-Handshakes werden die durch das eHealth-Kartenterminal verursachten Zeiten vom Empfang des Client Hello durch das eHealth-Kartenterminal bis zu ChangeCipherSpec Finished gemessen und addiert. Latenzzeiten des Transportnetzes gehen in die Berechnung der Dauer nicht ein.

4.1.4 Produkttyp Mobiles Kartenterminal

An das Mobile Kartenterminal werden keine Performance-Anforderungen gestellt.

4.1.5 Produkttyp KTR-AdV

An den Produkttypen KTR-AdV werden Anforderungen bezüglich seiner Verfügbarkeit gestellt.

GS-A_5506 - Performance – AdV-Server – Verfügbarkeit

Der Produkttyp KTR-AdV MUSS für die Komponente AdV-Server zur Hauptzeit und zur Nebenzeit eine Verfügbarkeit von 98% haben.

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

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

Weitere Anforderungen: [GS-A_4146], [GS-A_4149]

4.2 Produkttypen der zentralen Zone der TI-Plattform

Um eine hohe Verfügbarkeit der TI-Plattform zu gewährleisten wird für alle Produkttypen der zentralen Zone der TI-Plattform, deren Verfügbarkeit zur Gesamtverfügbarkeit einzelner Anwendungsfälle wesentlich beiträgt, eine hohe Verfügbarkeit gefordert. Ebenso wird dies für die Störungsampel gefordert, die ein zeitnahes Monitoring von Ausfällen erlauben soll.

GS-A_4155 - Performance – zentrale Dienste – Verfügbarkeit

Die Produkttypen Namensdienst, Sicherheitsgateway Bestandsnetze, VPN-Zugangsdienst, OCSP-Proxy, TSP-X.509QES (Komponente OCSP-Responder), TSP-X.509nonQES (Komponente OCSP-Responder), gematik-Root-CA (Komponente OCSP-Responder), Verzeichnisdienst, Service Monitoring, Signaturdienst, Schlüsselgenerierungsdienst der zentralen Zone der TI und die Störungsampel MÜSSEN zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

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

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

Der Anschluss an das zentrale Netz muss über die Anschlussoption „Hohe Verfügbarkeit“ erfolgen.

[<=]

Für das Zentrale Netz der TI wird als Gesamtbeitrag zu Anwendungsfällen ebenfalls eine Verfügbarkeit von mindestens 99,9% angestrebt. Da pro Anwendungsfall mehrere Ende-zu-Ende-Verbindungen über das Netz benötigt werden, muss eine entsprechend höhere Verfügbarkeit für Ende-zu-Ende-Verbindungen auf Netzwerkebene verlangt werden.

GS-A_4156 - Performance – zentrales Netz – Verfügbarkeit – Anschlussoption „Hohe Verfügbarkeit“

Das Zentrale Netz der TI MUSS die Anschlussoption „Hohe Verfügbarkeit“ bereitstellen und eine Verfügbarkeit über alle IP-Verbindungen zwischen allen sicheren zentralen Zugangspunkten (SZZP) mit der Anschlussoption „Hohe Verfügbarkeit“ angeschlossenen Produkttypen der TI von 99,98% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen.

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

GS-A_4353 - Performance – zentrales Netz – Verfügbarkeit – Anschlussoption „Niedrige Verfügbarkeit“

Das Zentrale Netz der TI MUSS die Anschlussoption „Niedrige Verfügbarkeit“ bereitstellen und eine Verfügbarkeit über alle IP-Verbindungen zwischen sicheren zentralen Zugangspunkten (SZZP) der angeschlossenen Produkttypen der TI von 99,8% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „Niedrige Verfügbarkeit“ angeschlossen ist.

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

GS-A_5028 - Performance – zentrale Dienste – Verfügbarkeit Produktivbetrieb

Die Produkttypen Namensdienst, Sicherheitsgateway Bestandsnetze, VPN-Zugangsdienst, OCSP-Proxy, TSP-X.509QES (Komponente OCSP-Responder), TSP-X.509nonQES (Komponente OCSP-Responder), Verzeichnisdienst, Service Monitoring, Störungsampel, Signaturdienst, Schlüsselgenerierungsdienst der zentralen Zone der TI und das Zentrale Netz der TI MÜSSEN perspektivisch in der Produktivphase eine Verfügbarkeit zwischen 99,9% und 99,99% anbieten können.

[<=]

GS-A_5523 - Performance – zentrale Dienste – Redundanzlösung

Anbieter von Diensten der TI, die zur Erfüllung der geforderten Verfügbarkeit eine Redundanzlösung einsetzen, MÜSSEN die Funktionsfähigkeit der Redundanzlösung in eigenverantwortlichen Tests nachweisen und die Funktionsweise der Redundanzlösung hinreichend detailliert beschreiben, so dass, anhand der Beschreibung, Testfälle zum Test der Redundanzlösung entwickelt werden können.

[<=]

GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen

Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN bei Lastspitzen oberhalb der für den Produkttypen definierten Spitzenlasten verfügbar bleiben.
[<=]

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Produkttyp abweisen oder langsamer bearbeiten. Es wird nur Robustheit gegenüber im Feld praktisch möglichen Lastspitzen erwartet.

Ein wesentlicher Aspekt beim bundesweiten Rollout ist die Skalierung der Zahl der ausgestatteten und eingebundenen Leistungserbringer. Entsprechend müssen die zentralen Dienste skalieren.

GS-A_3055 - Performance – zentrale Dienste – Skalierbarkeit (Anbieter)

Anbieter für Produkttypen der zentralen Zone der TI-Plattform 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_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_5134 - Performance – KOM-LE-Fachdienst – Skalierbarkeit

Anbieter für den KOM-LE-Fachdienst 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_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit

Die Produkttypen der zentralen Zone der TI-Plattform SOLLEN möglichst linear skalierbar sein. Diese Skalierbarkeit ist durch den Anbieter zu dokumentieren.

[<=]

TLS-Verbindungsaufbau

GS-A_5331 - Performance – zentrale Dienste – TLS-Handshake

Die Produkttypen der zentralen Zone der TI-Plattform, zu denen der Konnektor TLS-Verbindungen aufbaut, MÜSSEN bei jedem TLS-Handshake die von ihnen in Summe verursachten Zeiten im Fall einseitiger Authentisierung unter 0,5 sec und im Fall beidseitiger Authentisierung unter 1,0 sec halten. Die Anforderung gilt unabhängig davon, ob sie als TLS-Server oder TLS-Client agieren. Etwaige Zeiten für OCSP-Aufrufe werden nur dann in der Summe der verursachten Zeiten mitgezählt, wenn sie vermeidbar sind.

[<=]

4.2.1 Produkttyp Verzeichnisdienst

GS-A_5135 - Performance – Verzeichnisdienst – Bearbeitungszeit unter Last

Der Produkttyp Verzeichnisdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Verzeichnisdienst unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

Tabelle 41: Tab_gemSpec_Perf_Verzeichnisdienst: Last- u. Bearbeitungszeitvorgaben

Schnittstellenoperation (Basisdienste)		Lastvorgaben	Bearbeitungszeitvorgaben
		Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
I_Directory_Query
	search_Directory_Entry	620	1000	1250
I_Directory_Maintenance
	add_Directory_Entry	2	1000	1250
	read_Directory_Entry	2	1000	1250
	modify_Directory_Entry	2	1000	1250
	delete_Directory_Entry	2	1000	1250
I_Directory_Application_Maintenance
	add_Directory_FA_Attributes	2	1000	1250
	delete_Directory_FA_Attributes	2	1000	1250
	modify_Directory_FA_Attributes	2	1000	1250

4.2.2 Produkttyp Konfigurationsdienst

GS-A_4157 - Performance – Konfigurationsdienst – Bearbeitungszeit unter Last

Der Produkttyp Konfigurationsdienst MUSS parallel die Last- und Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Konfigurationsdienst für die Operationen list_Updates und get_Updates(Download-Software-Pakete) erlauben. Für den Anwendungsfall get_Updates(Download-Software-Pakete) muss die Anzahl der geforderten parallelen Downloads garantiert werden. Die Download-Dateien müssen während des Download-Transports komprimiert sein.

[<=]

GS-A_4853 - Performance – Konfigurationsdienst – Verfügbarkeit

Der Konfigurationsdienst MUSS eine Verfügbarkeit von 99 % haben. In der Hauptzeit MUSS zusätzlich die Ausfallzeit auf maximal eine Stunde pro Tag limitiert sein. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

Tabelle 42: Tab_gemSpec_Perf_Konfigurationsdienst: Last- u. Bearbeitungszeitvorgaben

Schnittstellenoperation			Last			Bearbeitungszeit
			Spitzenlast [1/s]	Datenmenge [kByte]	Parallele Downloads	Mittelwert [msec]	99%-Quantil [msec]
Infrastrukturdienste
	I_KSRS_Download
		list_Updates	7	10		100	300
		get_Updates (Download-Software-Pakete)		bis zu 1500000	pro KSR Download Cache Server 1000 mit in Summe 1 Gbit/sec

4.2.3 Produkttypen der PKI – TSL-Dienst

Der TSL-Dienst stellt drei technische Schnittstellen zur Verfügung: I_TSL_Download, I_OCSP_Status_Information und I_BNetzA_VL_Download.

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

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

[<=]

Die Anforderungen bzgl. Last und Bearbeitungszeit an die Schnittstelle I_OCSP_Status_Information stellt Kapitel 4.2.4.

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

Der TSL-Dienst MUSS eine Verfügbarkeit von 99 % haben. In der Hauptzeit MUSS zusätzlich die Ausfallzeit auf maximal eine Stunde pro Tag limitiert sein. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

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

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4159], [GS-A_4160].

Tabelle 43: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben

Schnittstellenoperation			Last
			Datenmenge [kByte]	Parallele Downloads
Infrastrukturdienste
	I_TSL_Download
		download_TSL	130 (*)	60 mit in Summe 60 Mbit/sec
		get_Hash	0,1	50 mit in Summe 1 Mbit/sec
	I_BNetzA_VL_Download
		download_VL	2000 (**)	250 mit in Summe 250 Mbit/sec
		get_Hash	0,1	50 mit in Summe 1 Mbit/sec

 (*) Die Größe der TSL wird mit maximal 500 kByte angenommen. Für den Transport wird angenommen, dass sie auf 130 kByte komprimiert ist.

(**) Die Größe der BNetzA_VL wird mit maximal 6000 kByte angenommen. Für den Transport wird angenommen, dass sie auf 2000 kByte komprimiert ist.

4.2.4 Produkttypen der PKI – OCSP-Responder

Die Schnittstelle I_OCSP_Status_Information mit der Operation check_Revocation_Status zur Abfrage des Sperrstatus von X.509-Zertifikaten stellen die Produkttypen OCSP-Proxy, TSP-X.509QES und TSP-X.509nonQES bereit. Ausgelöst werden die Aufrufe durch die Prüfung der QES-Signatur durch den HBA, das Prüfen der eGK bei VSD-Anwendungsfällen, beim Prüfen der Datensignatur, beim Zertifikatsprüfen bei der Datenverschlüsselung und beim Verbindungsaufbau zwischen Konnektor und VPN-Konzentrator sowie dem Verbindungsaufbau zwischen Konnektor und VSDM-Intermediär (weitere Verbindungsaufbaue fallen im Vergleich kaum ins Gewicht).

Tabelle 44: Tab_gemSpec_Perf_OCSP_Responder – Last- und Bearbeitungszeitvorgaben

Produkttyp	Funktion	Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
OCSP-Resp. TSP-X.509QES	Prüfung von HBA-Zertifkaten aus der TI (C.HP.QES): EE-Zert	500	2.000	2.400
	Prüfung von HBA-Zertifkaten aus dem Internet (C.HP.QES): EE-Zert	30
OCSP-Resp. TSP-X.509nonQES	Prüfung von eGK-Zertifikaten aus der TI (C.CH.AUT)	1.000	1.000	1.300
	Prüfung von Zertifikaten der alternativen Versichertenidentitäten aus der TI (C.CH.AUT_ALT)	80
	Prüfung von SMC-B-Zertifikaten aus der TI (C.HCI.OSIG)	620
	Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.OSIG)	30
	Prüfung von HBA-Zertifikaten aus der TI (C.HP.ENC)	310
	Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.ENC)	15
	Prüfung von SMC-B Zertifikaten aus der TI (C.HCI.ENC)	310
	Prüfung von SMC-B Zertifikaten aus dem Internet (C.HCI.ENC)	15
	Prüfung von Konnektor-Zertifikaten aus der TI (gSMC-K, C.NK.VPN)	85
	Prüfung von SMC-B-Zertifikaten aus der TI (C.HCI.AUT)	385
	Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.AUT)	30
	Prüfung von HBA-Zertifikaten aus der TI (C.HP.AUT)	-
	Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.AUT)	30
	Prüfung von TLS Zertifikaten der  zentralen Dienste aus der TI (C.ZD.TLS)	85
	Prüfung von TLS Zertifikaten der Fachdienste aus der TI  (C.FD.TLS)	235
OCSP-Resp. TSL-Dienst	Prüfung des TSL-Signerzertifikats aus der TI	45	1.000	1.300
OCSP-Resp. gematik-Root-CA	Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.ENC): CA-Zert	15	1.000	1.300
	Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.AUT): CA-Zert	30
	Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.ENC): CA-Zert	15
	Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.AUT): CA-Zert	30
	Prüfung von SMC-B-Zertifikaten aus dem Internet Root-CA-Zert	45

 

GS-A_5550 - Performance – OCSP Responder – Grundlast

Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES, TSL-Dienst und gematik-Root-CA MÜSSEN die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder unter einer Last von 5 Anfragen pro Sekunde erfüllen.

[<=]

GS-A_4159 - Performance – OCSP Responder – Bearbeitungszeiten unter Spitzenlast

Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES, TSL-Dienst und gematik-Root-CA 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 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
• Last für OCSP-Responder TSL-Dienst und OCSP-Resp.
  gematik-Root-CA: Spitzenlastwert aus Tabelle Tab_gemSpec_Perf_OCSP_Responder

[<=]

GS-A_4160 - Performance – OCSP-Responder – Performance Reporting – Daten nach Zertifikatstyp

Die Produkttypen TSP-X.509QES, TSP-X.509nonQES, TSL-Dienst und gematik-Root-CA MÜSSEN die Performance Reporting Daten nach Zertifikatstypen aufgeschlüsselt erfassen und reporten.
[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

4.2.5 Produkttyp Störungsampel

GS-A_4161 - Performance – Störungsampel – Durchsatz

Der Produkttyp Störungsampel MUSS die Durchsatzvorgaben aus Tab_gemSpec_Perf_Störungsampel erfüllen.
[<=]

Tabelle 45: Tab_gemSpec_Perf_Störungsampel – Lastvorgaben

Schnittstellenoperation			Last
			Spitzenlast	Datenmenge
			[1/sec]	[kByte]
Infrastrukturdienste
	I_Monitoring_Update
		update_Information	2	4
	I_Monitoring_Read
		read_Information

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

4.2.6 Produkttyp Service Monitoring

Für den Produkttypen Service Monitoring gelten folgende Anforderungen: [GS-A_4155], [GS-A_5028], [GS-A_3055],[GS-A_3058], [GS-A_4145].

4.2.7 Produkttyp Namensdienst

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.

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145],
[GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

Tabelle 46: Tab_gemSpec_Perf_Namensdienst: Last- u. Bearbeitungszeitvorgaben

Schnittstellenoperation			Lastvorgaben	Bearbeitungszeitvorgaben
			Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
Infrastrukturdienste
	I_DNS_Service_Localization
		get_Service_Location	3	60	120
	I_DNS_Name_Resolution
		get_IP_Address	60	30	70
		get_FQDN	-	30	70

4.2.8 Produkttyp Zeitdienst

Als NTP-Clients, die den Zeitdienst abfragen, können neben den Hauptinstanzen der zentralen Dienste der TI-Plattform auch Switches, Router und Firewalls in Aktion treten. Es wird von maximal 1000 NTP-Clients ausgegangen. Die Clients fragen die Server nicht öfter als alle 64 Sekunden ab. Bei stabiler Zeitsynchronisation wird ein NTP-Client das Abfrage-Intervall auf bis zu 1024 Sekunden vergrößern. Daher wird bzgl. Skalierbarkeit nur die Fähigkeit gefordert, 20 Anfragen pro Sekunde (>1000/64/sec) verarbeiten zu können.

GS-A_4163 - Performance – Zeitdienst – Durchsatz

Die Stratum 1 NTP Server des Produkttyps Zeitdienst und der Stratum 2 NTP Server des Produkttyps VPN-Zugangsdienst MÜSSEN jeweils mindestens eine Spitzenlast von 200 NTP Anfragen pro Sekunde verarbeiten können.

[<=]

GS-A_4165 - Performance – Zeitdienst – Verfügbarkeit

Der Produkttyp Zeitdienst und der Produkttyp VPN-Zugangsdienst MÜSSEN jeweils eine Verfügbarkeit von 99 % mit einer maximalen Ausfalldauer von 24 Stunden für die Schnittstelle I_NTP_Time_Information haben.

Der Zeitdienst gilt als nicht verfügbar, wenn folgende Störungen auf mindestens zwei Stratum 1 NTP Server des Zeitdienstes auftreten:

• Die Abweichung von der gesetzlichen Zeit ist größer als 330 msec.
• NTP Anfragen werden nicht beantwortet.
• Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

4.2.9 Produkttyp Zentrales Netz der TI

Das zentrale Netz der TI dient der performanten Kommunikation zwischen VPN-Zugangsdiensten, zentralen Diensten und fachanwendungsspezifischen Diensten.

Die Leistungserbringer bestimmen durch die Wahl des Transportnetzanschlusses, wie performant sie sich an das zentrale Netz der TI anbinden. Es gilt das zentrale Netz von seinen Performance-Eigenschaften so auszulegen, dass es marktübliche hochwertige Transportnetzanschlüsse in diesen Eigenschaften übertrifft, und damit die Wahl der Gesamtperformance-Eigenschaften auf Netzwerkebene in der Hand der Leistungserbringer liegt.

Bzgl. Verfügbarkeit wird dies durch die Anforderungen [GS-A_4156] und [GS-A_4353] an das zentrale Netz der TI und die Anforderung [GS-A_4155] an die zentralen Dienste für den Anschluss an das zentrale Netz erreicht.

Bzgl. Last und Bearbeitungszeitverhalten ist ein wesentlicher Aspekt die Bandbreitenauslegung der einzelnen Verbindungen. Sie ist durch zwei Faktoren bestimmt: Zum einen durch die Lastspitzen der Anwendungsfälle, die hier im zeitlichen Mittel über mehrere Sekunden zu verstehen sind, zum anderen durch die marktüblichen Bandbreiten hochwertiger Transportnetzanschlüsse.

Abbildung 9 skizziert die Punkte im Netzwerk, für die Spitzenlastvorgaben gestellt werden. Bzgl. Last und Bearbeitungszeiten werden folgende Anforderungen gestellt:

GS-A_4166 - Performance – Zentrales Netz – Durchsatz

Das Zentrale Netz der TI MUSS  die Netzwerkverbindungen so auslegen, dass jede Verbindung eine Bandbreite aufweist, die gleichzeitig auftretende Spitzenlasten gemäß Tab_gemSpec_Perf_Netzlast_1 und Tab_gemSpec_Perf_Netzlast_2_12 bedient. Jede Verbindung von Anschlusspunkt zu Anschlusspunkt muss mindestens eine Bandbreite von 10 Mbit/sec haben.

[<=]

GS-A_4167 - Performance – Zentrales Netz – Roundtrip Time

Das Zentrale Netz der TI-Plattform MUSS eine RoundtripTime für IP-Pakete von höchstens 30 msec im Mittel über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt aufweisen.

[<=]

GS-A_4347 - Performance – Zentrales Netz – Paketverlustrate

Das Zentrale Netz der TI-Plattform MUSS eine Verlustrate für IP-Pakete von höchstens 0,1 % im Mittel über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt aufweisen.

[<=]

Bzgl. Robustheit gegenüber Lastspitzen ist die Anforderung [GS-A_4145] zu erfüllen. Detailregelungen zu Überlastsituationen erfolgen in [gemSpec_Net].

Anforderungen zum Reporting regeln die folgenden Anforderungen übergreifend: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

Wie die Volumenmessungen zu erfolgen haben, regeln die nachfolgenden Anforderungen. Zur Topologie siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“.

GS-A_5014 - Performance – Zentrales Netz – Volumenmessung im SZZP

Das Zentrale Netz der TI-Plattform MUSS an seinen Sicheren Zentralen Zugangspunkten (SZZPs) das Volumen der übertragenen Daten erfassen.

An SZZPs, die VPN Zugangsdienste anschließen, MUSS das Volumen getrennt nach den einzelnen VPN-Zugangsdienstinstanzen und jeweils nach der Richtung vom und zum VPN-Zugangsdienst erfasst werden.

An SZZPs, die Zentrale Dienste der TI-Plattform oder fachanwendungsspezifische Dienste anschließen, MUSS das Volumen getrennt nach Dienstinstanz und jeweils nach der Richtung vom und zum Dienst erfasst werden. Dabei meint Dienstinstanz eine Aufschlüsselung nach Produktinstanz und Anbieter. Abweichend von dieser generellen Regelung ist für die VSDM Dienstinstanzen keine Aufschlüsselung nach Produktinstanz und Anbieter gefordert, sondern nur eine Aufschlüsselung nach SZZPs und Richtung.

An SZZPs, die Sicherheitsgateways Bestandsnetze anschließen, MUSS das Volumen getrennt nach den einzelnen Instanzen der Sicherheitsgateways Bestandsnetze und jeweils nach der Richtung von und zur Instanz des Sicherheitsgateways Bestandsnetze erfasst werden.
[<=]

Die Aufschlüsselung der Volumenflüsse im SZZP nach Dienstinstanzen erfolgt über die in [gemSpec_Net] geregelte Zuordnung von IP-Adressen zu Produktinstanz und Anbieter.

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4156], [GS-A_4353], [GS-A_5028].

Hinweis: Die Spitzenlasten beziehen sich auf die Summe aller Instanzen pro Produkttyp.

Abbildung 9: Netzwerktopologie – Punkte mit Lastvorgaben (orange)

Tabelle 47: Tab_gemSpec_Perf_Netzlast_1 Spitzenlasten am VPN-Zugangsdienst (Punkt 1)

Datenstrom	Zusammensetzung		Spitzenlast Mbit/sec
VPN-Zugangsdienst zur zentralen Zone	Summe		3.417
	Bestandsnetz		150
	VSDM Intermediär		8
	OCSP-Responder + OCSP-Proxy		8
	KOM-LE-Fachdienst		3.248
	Verzeichnisdienst		3
zentrale Zone zu VPN-Zugangsdienst	Summe		4.016
	KSR (Download Softwarepakete)		100
	Bestandsnetz		150
	OCSP-Responder + OCSP-Proxy		104
	VSDM Intermediär		13
	TSL-Dienst (Download TSL, BNetzA_VL)		360
	KOM-LE-Fachdienst		3.248
	Verzeichnisdienst		41

Tabelle 48: Tab_gemSpec_Perf_Netzlast_2_12 Spitzenlasten (Punkte 2-12) 

Produkttyp	Richtung		Spitzenlast Mbit/sec
OCSP-Resp. TSP-X.509nonQES	zum Dienst		6
	vom Dienst		82
OCSP-Resp. TSP-X.509QES	zum Dienst		1
	vom Dienst		17
OCSP-Proxy	zum Dienst		1
	vom Dienst		18
TSL-Dienst	zum Dienst		1
	vom Dienst		360
VSDM Intermediär	zum Dienst		26
	vom Dienst		21
Bestandsnetz	zum Dienst		150
	vom Dienst		150
Störungsampel	zum Dienst		1
	vom Dienst		1
KSR	zum Dienst		1
	vom Dienst		100
VSDM Fachdienst	zum Dienst		8
	vom Dienst		13
KOM-LE-Fachdienst	zum Dienst		5.000
	vom Dienst		5.000
Verzeichnisdienst	zum Dienst		3
	vom Dienst		41

4.2.10 Produkttyp VPN-Zugangsdienst

Der Produkttyp VPN-Zugangsdienst verbindet Transportnetz und Zentrales Netz der TI. Für OCSP-Request sorgt er dabei für ein http-Forwarding.

Zusätzlich zu dieser über die Schnittstelle I_Secure_Channel_Tunnel angebotenen Leistung, bietet der VPN-Zugangsdienst Leistungen über die Schnittstellen I_DNS_Name_Resolution und I_NTP_Time_Information an.

Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:
[GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_4162].

Für die Schnittstelle I_NTP_Time_Information gelten die Anforderungen wie für den Zeitdienst: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4163], [GS-A_4165].

Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:

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_15574 - Performance - VPN Zugangsdienst - Performance Daten (IPsec mittlerer Datendurchsatz)

Der VPN-Zugangsdienst MUSS gemäß Tab_gemSpec_Perf_Performance-Kenngroessen für jeden VPN-Konzentrator getrennt nach TI und SIS den Gesamtdurchsatz   Datendurchsatz des IPsec-Datenstroms in Mbit/s pro nach jedem Zeitintervall erfassen und monatlich reporten.
[<=]

GS-A_4170 - Performance – VPN-Zugangsdienst – Durchsatz

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

• mindestens eine symmetrischen Bandbreitenanbindung von 10 Mbit/sec
• 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.  

Der VPN-Zugangsdienst MUSS an jedem Standort auf der Strecke von den VPN-Konzentratoren zum SZZP eine Bandbreite von 10 GBit/sec durchgehend unterstützen.
[<=]

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.

[<=]

Die Anforderung [GS-A_4155] verlangt eine Verfügbarkeit, die sowohl die primäre Leistung der Verbindung von Transportnetz und Zentralem Netz der TI mit Terminierung des VPN-Kanals beinhaltet, also auch DNS-Anfragen und http-Forwarding. Nicht inkludiert in der Verfügbarkeit ist wegen ihres asynchronen Beitrags zu Anwendungsfällen die NTP-Schnittstelle.

Anforderungen zum Reporting regeln die folgenden Anforderungen übergreifend:
[GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

Wie die Volumenmessungen zu erfolgen hat, regelt die nachfolgenden Anforderung, siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“:

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.

[<=]

Folgende Größen sollen für jedes Reportingintervall gemessen und reportet werden:

A_15554 - Performance - VPN-Zugangsdienst - Anzahl VPN-Tunnel

Der VPN-Zugangsdienst MUSS die Zahl der VPN-Tunnel getrennt nach SIS und TI erfassen und reporten. Hierfür gelten folgende Rahmenbedingungen:

• Für jeden VPN-Konzentrator TI und SIS MUSS jeweils die Anzahl der bestehenden VPN-Tunnel am Ende des Zeitintervalls der Erfassung bestimmt werden.
• Für jeden VPN-Konzentrator TI und SIS MUSS für jedes Zeitintervall der Erfassung die Zahl der in diesem Zeitintervall neu aufgebauten VPN-Tunnel erfasst werden. Die Anzahl der neu aufgebauten VPN-Tunnel wird nicht durch Re-Authentication oder Re-Keying geändert.
• Für jeden VPN-Konzentrator TI und SIS MUSS für jedes Zeitintervall der Erfassung die Zahl der in diesem Zeitintervall abgebauten Tunnel erfasst werden. Die Anzahl der abgebauten Tunnel wird nicht durch Re-Authentication oder Re-Keying geändert.
• Die Anzahl der bestehenden Tunnel in einem Zeitintervall MUSS gleich der Anzahl der Tunnel im vorherigen Zeitintervall plus der im Zeitintervall neu aufgebauten Tunnel minus der im Zeitintervall abgebauten Tunnel sein.

[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4155], [GS-A_5028].

4.2.11 Produkttyp Sicherheitsgateway Bestandsnetze

An die Schnittstelle I_Secure_Access_Bestandsnetz des Sicherheitsgateways Bestandnetze wird folgende Performance-Anforderungen gestellt:

GS-A_4171 - Performance – Sicherheitsgateway Bestandsnetze – Durchsatz

Das Sicherheitsgateway Bestandsnetze MUSS einen Durchsatz bis zu einer Spitzenlast von 150 Mbit/sec in beide Richtungen zwischen dem Anschlusspunkt zum SZZP als Übergang zum zentralen Netz der TI und dem Tunnelpunkt zum angeschlossenen Netzwerk gewährleisten.
[<=]

Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145],
[GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155].

4.2.12 Produkttyp Signaturdienst

A_18018 - 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.
[<=]

Zur Erläuterung der Anforderung [A_18018]:

Der Anbieter muss für seinen Marktanteil das System so dimensionieren, dass die Lastvorgaben am Signaturdienst eingehalten werden.
Beispielrechnung: Für ein Marktanteil von 20% und eine Lastvorgabe von 100 Anfragen pro Sekunde muss der Signaturdienst mindestens 20 Anfragen pro Sekunde an die nachgelagerten Komponenten weiterleiten können.
Beispielrechnung: Bei einem Marktanteil von 20% muss für die Operation "I_Remote_Sign_Operations:sign_Data" eine Lastvorgabe von mindestens 20 Anfragen pro Sekunde eingehalten werden (20% von 100 Anfragen pro Sekunde).

Tabelle 49: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben

Schnittstellenoperation		Lastvorgaben	Bearbeitungszeitvorgaben
		Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
I_Remote_Sign_Operations
	sign_Data	100	150	240

A_17802 - Performance – Signaturdienst – Bearbeitungszeit unter Last

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

[<=]

A_1798418178 - Performance - Signaturdienst - Erfassung von Rohdaten

Der AnbieterProdukttyp Signaturdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SigD" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]

A_17985 - Performance - Signaturdienst - Lieferung von Rohdaten

Der Anbieter Signaturdienst MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance-Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678]  liefern. Voreingestellt für das Zeitintervall ist täglich.
[<=]

Ebenfalls gelten folgende Anforderungen:  [GS-A_4155], [GS-A_5028], [GS-A_3055],[GS-A_3058], [GS-A_4145].

4.2.13 Produkttyp Schlüsselgenerierungsdienst

Für den Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform und dem Schlüsselgenerierungsdienst am Fachdienst gelten folgende Anforderungen:

A_17841 - Performance – Schlüsselgenerierungsdienst – zentral - Bearbeitungszeit unter Last

Der Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen

[<=]

Tabelle 50: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben

Schnittstellenoperationen	Lastvorgaben	Bearbeitungszeitvorgaben
	Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
GetPublicKey	100	100	174
KeyDerivation	100	3700	4147

A_1798218179 - Performance - Schlüsselgenerierungsdienst - zentral - Erfassung von Rohdaten

Der Anbieter Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SGD" erfassen

[<=]  und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]

A_17983 - Performance - Schlüsselgenerierungsdienst - zentral - Lieferung von Rohdaten

Der Anbieter Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance-Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678]  liefern. Voreingestellt für das Zeitintervall ist täglich5 Minuten.
[<=]

A_18251 - Performance - Schlüsselgenerierungsdienst - zentral - Verfügbarkeit

Der Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI MUSS eine Verfügbarkeit von 99,98 in der Haupt- und Nebenzeit für alle Operationen der technischen Schnittstellen aufweisen.

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

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

Der Anschluss an das zentrale Netz muss über die Anschlussoption „Hohe Verfügbarkeit“ erfolgen. [<=]

Ebenfalls gelten folgende Anforderungen an den Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform:
 

[GS-A_4155], [GS-A_5028], [GS-A_3055],[GS-A_3058], [GS-A_4145]. 

A_17967 - Performance – Schlüsselgenerierungsdienst – am FD - Spitzenlastvorgaben

Der Anbieter Schlüsselgenerierungsdienst am FD MUSS das System so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" erfüllt wird.

[<=]

Zur Erläuterung der Afo [A_17967]:

Der Anbieter muss die Anzahl seiner Nutzer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden. Beispielrechnung: Für 12,57 Mio. Nutzer (etwa 17,95% Marktanteil) muss für die Operation "GetPublicKey" eine Lastvorgabe von mindestens 18 Anfragen pro Sekunde eingehalten werden (17,95% von 100 Anfragen pro Sekunde).

A_17977 - Performance - Schlüsselgenerierungsdienst - am FD - Bearbeitungszeit unter Last

Der Schlüsselgenerierungsdienst am FD MUSS die Bearbeitungszeitvorgaben unter Last für die Schnittstellenoperationen aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" erfüllen.

[<=]

A_17975 - Performance - Schlüsselgenerierungsdienst - am FD - Robustheit gegenüber Lastspitzen

Der Schlüsselgenerierungsdienst am FD MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" verfügbar bleiben.

[<=]

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Signaturdienst vorübergehend abweisen. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

A_17978 - Performance - Schlüsselgenerierungsdienst - am FD - Skalierung

Der Anbieter Schlüsselgenerierungsdienst am FD MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.

[<=] 
[<=]

A_17979 - Performance - Schlüsselgenerierungsdienst - am FD - Verfügbarkeit

Der Anbieter Schlüsselgenerierungsdienst am FD MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

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

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

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

[<=]

A_1798018180 - Performance - Schlüsselgenerierungsdienst - am FD - Erfassung von Rohdaten

Der Anbieter Schlüsselgenerierungsdienst am FD MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SGD" erfassen

[<=]  und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]

A_17981 - Performance - Schlüsselgenerierungsdienst - am FD - Lieferung von Rohdaten

Der Anbieter Schlüsselgenerierungsdienst am FD MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678]  liefern.

[<=]  Voreingestellt für das Zeitintervall ist täglich.
[<=]

4.3 Produkttypen VSDM

4.3.1 Produkttyp VSDM Intermediär

GS-A_5029 - 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 sowie die Skalierung auf die im Betrieb zu bewältigende Spitzenlast durch ein Skalierungskonzept nachzuweisen.
[<=]

Tabelle 51: Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben

Bearbeitungszeitvorgaben
Mittelwert [msec]	95%-Quantil [msec]
100	150

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

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

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

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

Außerdem gelten folgende Anforderungen für das Erfassen und Reporten von Performance-Kennzahlen: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

4.3.2 Produkttypen Fachdienste VSDM (UFS, VSDD, CMS)

GS-A_5031 - Performance – VSDM Fachdienste – Bearbeitungszeit unter Last

Die Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS MÜSSEN die Bearbeitungszeitvorgaben für das 95%-Quantil unter Last aus Tab_gemSpec_Perf_VSDM_Fachdienste erfüllen. Sie SOLLEN die Bearbeitungszeitvorgaben für den Mittelwert unter Last aus Tab_gemSpec_Perf_VSDM_Fachdienste erfüllen.

Die Bearbeitungszeiten für alle Request-Response-Zyklen eines Anwendungsfalls tragen zur Bearbeitungszeit bei. Es wird davon ausgegangen, dass die Fachdienste eingeschwungen sind, so dass Verbindungen nicht neu ausgehandelt werden.
[<=]

Tabelle 52: Tab_gemSpec_Perf_VSDM_Fachdienste: Last- und Bearbeitungszeitvorgaben

Produkttypen	Anwendungsfalldetails	Lastvorgaben	Bearbeitungszeitvorgaben
		Spitzenlast [1/sec]	Mittelwert [msec]	95%-Quantil [msec]
Fachdienst UFS	Bearbeitungszeiten vom Eingang der Anfrage "GetUpdateFlags" bis zum Versand der Antwort durch den Fachdienst	1000	235	280
Fachdienst VSDD/CMS	Summe aller Bearbeitungszeiten aller VSDD/CMS-Anfragen (vom Empfang der Anfrage bis zum Versand der Antwort durch den Fachdienst), die zu jeweils einer Aktualisierung der eGK gehören. Die VSDD/CMS-Anfragen umfassen sowohl die Operation "PerformUpdates" als auch die anschließenden "GetNextCommandPackaged"-Operationen.	25	1560	5585

GS-A_5032 - Performance – VSDM Fachdienste – Verfügbarkeit

Die Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS MÜSSEN zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 98,5% haben.

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

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


[<=]

Die Verfügbarkeit der funktionalen Eigenschaften der Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

Weiterhin gelten folgende Anforderungen für das Erfassen und Liefern von Rohdaten : 

A_17268 - Performance - Erfassung von Rohdaten - Fachdienste VSDM

Die Betreiber der Fachdienste VSDM MÜSSEN Rohdaten gemäß [Tab_gemSpec_Perf_Berichtsformat_VSDM] erfassen.

[<=]

A_17267 - Performance - Lieferung von Rohdaten - Fachdienste VSDM

Die Betreiber der Fachdienste VSDM MÜSSEN in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich.
[<=]

4.4 Produkttypen KOM-LE

4.4.1 Produkttyp KOM-LE-Clientmodul

GS-A_5136 - Performance – KOM-LE-Clientmodul – Bearbeitungszeit unter Last

Der Produkttyp KOM-LE-Clientmodul MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_KOMLE_Clientmodul unter der für die Anwendungsfälle parallel anliegenden Spitzenlast erfüllen. Die Lastanforderungen müssen von den Clientmodulen für die jeweilige Leistungserbringerumgebung LE-U1, LE-U2, LE-U3 oder LE-U4 erbracht werden. Das KOM-LE-Clientmodul muss diese Zeiten unter der Nebenbedingung erbringen, dass die anderen Produkttypen die Zeiten gemäß der Zerlegung der Bearbeitungszeiten in Tabelle Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge einhalten und dass die Ausführung auf einem durchschnittlichen PC erfolgt.

[<=]

Tabelle 53: Tab_gemSpec_Perf_KOMLE_Clientmodul: Last- und Bearbeitungszeitvorgaben

Anwendungsfall	Datenmenge in KB	Spitzenlast [1/h]				Bearbeitungszeit
		LE-U1	LE-U2	LE-U3	LE-U4	Mittelwert [sec]
Empfängerdaten ermitteln	10	10	37	94	237	1,2
Nachricht schützen und an KOM-LE-Fachdienst senden	50	200	200	200	200	8,9
	100	10	35	90	224	12,5
	25600	13	13	13	13	260 (*)
Nachricht vom KOM-LE Fachdienst holen und aufbereiten	50	200	200	200	200	4,3
	100	10	35	90	224	4,8
	25600	13	13	13	13	38,5 (*)
Aufbau sicherer Kanal vom Clientmodul zum Fachdienst		34	34	70	70	3,9

(*) In diesem besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von
16 Mbit/sec in Download-Richtung und 1024 Kbit/sec in Upload-Richtung ausgegangen.

Tabelle 54: Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge: Zerlegung Bearbeitungszeiten

Anwendungsfall	Daten- menge in KB	Bearbeitungszeitbeiträge [sec]
		Konnektor, Anzeige am Arbeitsplatz, Kartenterminal, Karten, Verzeichnis- dienst	LE- LAN	Zugangs- netz	KOM- LE Client- modul	KOM- LE Fach- dienst	OCSP- Responder
Empfängerdaten ermitteln	10	1,0	0,0	0,1	0,0	0,0	0,0
Nachricht schützen und an KOM-LE Fachdienst senden	50	3,3	0,1	3,9	0,5	0,0	1,0
	100	3,3	0,1	7,5	0,5	0,0	1,0
	25600	4,6	23,5	229,3 *	1,0	0,0	1,0
Nachricht vom KOM-LE Fachdienst holen und aufbereiten	50	1,2	0,1	0,6	0,5	0,0	1,0
	100	1,2	0,1	1,1	0,5	0,0	1,0
	25600	2,3	18,8	14,4 *	1,0	0,0	1,0
Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst		1,3	0	0,4	0,1	0,1	2,0

(*) In diesem besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von
16 Mbit/sec in Download-Richtung und 1024 Kbit/sec in Upload-Richtung ausgegangen.

4.4.2 Produkttyp KOM-LE-Fachdienst

GS-A_5137 - Performance – KOM-LE-Fachdienst – Durchsatz

Der Produkttyp KOM-LE-Fachdienst MUSS die Durchsatzvorgaben aus Tab_gemSpec_Perf_KOMLE_Fachdienst erfüllen.

[<=]

GS-A_5138 - Performance – KOM-LE-Fachdienst – Bearbeitungszeit unter Last

Der Produkttyp KOM-LE-Fachdienst MUSS die Bearbeitungszeitvorgabe aus Tab_gemSpec_Perf_KOMLE_Clientmodul für den „Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst“ unter der für diesen Anwendungsfall gemäß Tabelle Tab_gemSpec_Perf_KOMLE_Fachdienst anliegenden Spitzenlast erfüllen. Der KOM-LE-Fachdienst muss diese Zeiten unter der Nebenbedingung erbringen, dass die anderen Produkttypen die Zeiten gemäß der Zerlegung der Bearbeitungszeiten in Tabelle Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge einhalten. Bei gecachten OCSP-Responses reduziert sich die Zeit um den dort angegebenen Betrag.

[<=]

Tabelle 55: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben

Anwendungsfall	Datenmenge in KB	Lastanforderungen
		Anfragen [1/sec]
Nachricht über KOM-LE-Clientmodul empfangen	100	302
	25.600	15
Nachricht über KOM-LE-Clientmodul Download	100	302
	25.600	15
Nachricht an KOM-LE-FD senden	100	160
	25.600	8
Nachricht von KOM-LE-FD empfangen	100	160
	25.600	8
Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst		820

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

Der Produkttyp KOM-LE-Fachdienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.

Auch über Ausfälle hinweg MUSS der Produkttyp KOM-LE-Fachdienst gewährleisten, dass Nachrichten spätestens 2 Stunden nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.

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

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

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

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

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

Außerdem gelten folgende Anforderungen für das Erfassen und Reporten von Performance-Kennzahlen: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

4.5 Produkttyp ePA-Aktensystem

A_15208 - Performance - ePA-Aktensystem - Spitzenlastvorgaben

Der Anbieter ePA-Aktensystem MUSS das Aktensystem so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben erfüllt wird. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl der gesetzlich Versicherten. [<=]

Zur Erläuterung der Afo [A_15208]:

Der Anbieter muss die Anzahl seiner Nutzer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 12,57 Mio. Nutzer (etwa 17,95% Marktanteil) muss für die Operation "I_Authentication_Insurant:login" eine Lastvorgabe von mindestens 11 Anfragen pro Sekunde eingehalten werden (17,95% von 60 Anfragen pro Sekunde).

Tabelle 56: Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben

Schnittstellenoperationen		Lastvorgaben	Bearbeitungszeitvorgaben
		Spitzenlast [1/sec]	Mittelwert [msec]	99%-Quantil [msec]
I_Authentication_Insurant
	login	60	755	960
	renew	240	755	960
	logout	30	100	180
I_Authorization
	getAuthorizationKey	100	770	980
I_Authorization_Management
	putAuthorizationKey	25	520	690
	checkRecordExists	25	100	180
I_Document_Management_Connect
	openContext	100	100	180
I_Document_Management
	CrossGatewayQuery	100	695	895
	CrossGatewayRetrieve	60	430	590
	CrossGatewayDocumentProvide	40	440	600
	RemoveDocuments	5	680	880
I_Proxy_Directory_Query
	Search	10	1150	1405

A_15031 - Performance - ePA-Aktensystem - Bearbeitungszeit unter Last

Das ePA-Aktensystem MUSS die Bearbeitungszeitvorgaben unter Last für die Schnittstellenoperationen aus Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben erfüllen.

Dabei gilt:
 

• Die in Tabelle Tab_ePA_Aktensystem definierte mittlere Bearbeitungszeit je Schnittstellenoperation misst die Zeit vom Eintreffen des letzten Bits des Requests im Aktensystem bis zum Zeitpunkt, zu dem das erste Bit der Response zum ePA-Client gesendet wird.
• Die Zeit, die zwischen Empfang des ersten Bit eines Requests bis zum letzten Bit des Requests liegt, darf durch das Aktensystem nicht verlängert werden (sie ist rein durch ePA-Client und effektive Bandbreite der Verbindung bestimmt).
• Die Zeit, die zwischen Senden des ersten Bit einer Response bis zum letzten Bit der Response liegt, darf durch das Aktensystem nicht verlängert werden (sie ist rein durch ePA-Client und effektive Bandbreite der Verbindung bestimmt).

[<=]

Hinweis: Bei den in Tabelle Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben angegebenen Bearbeitungszeiten sind die Zeiten für die Übertragung der eingehenden und ausgehenden Nachrichten nicht enthalten.

A_15236 - Performance - ePA-Aktensystem - Robustheit gegenüber Lastspitzen

Das ePA-Aktensystem MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben verfügbar bleiben. [<=]

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann das ePA-Aktensystem vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter ePA-Aktensystem hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

A_17998 - Performance - ePA-Aktensystem - Zugangsgateway des Versicherten - Lastvorgaben

Der Anbieter ePA-Aktensystem MUSS die Komponente Zugangsgateway des Versicherten so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast erfüllt wird. Der Marktanteil des Anbieters ist  prozentual auf die TI-Gesamtlast von 640 parallel eintreffenden Anfragen anzuwenden.  
[<=]

Zur Erläuterung der Afo [A_17998]:

Der Anbieter muss für sein Marktanteil das System so dimensionieren, dass die Lastvorgaben am Zugangsgateway des Versicherten eingehalten werden.
Beispielrechnung: Für ein Marktanteil von 20% und eine Lastvorgabe von 640 Anfragen pro Sekunde muss das Zugangsgateway des Versicherten mindestens 128 Anfragen pro Sekunde an die nachgelagerten Komponenten weiterleiten können.

A_15213 - Performance - ePA-Aktensystem - Spitzenlastvorgaben TU

Der Anbieter ePA-Aktensystem MUSS in der TU-Umgebung 5% der in Tabelle Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben geltenden Spitzenlastvorgaben unter Einhaltung der mittleren Bearbeitungszeiten erfüllen.

Ist der Marktanteil kleiner als 5% MUSS der Anbieter ePA-Aktensystem nur den entsprechenden Prozentwert seines Marktanteils in der TU umsetzen. Der Prozentwert MUSS mit angegeben werden.
[<=]

Zur Erläuterung der Afo [A_15213]:
Jeder Anbieter muss sein ePA-Aktensystem in der TU so dimensionieren, dass mindestens 5% der in Tabelle Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben erfüllt werden. 
Beispielrechnung: Für die Operation "I_Authentication_Insurant:login" müssen mindestens 3 Anfragen pro Sekunde in der TU erfolgreich verarbeitet werden (5% von 60 Anfragen pro Sekunde). Die 5% - Regel gilt auch für die Dimensionierung der parallelen Anfragen über das Zugangsgateway des Versicherten (gemäß [A_17998]).

A_15214 - Performance - ePA-Aktensystem - Speicherkapazität TU

Der Anbieter ePA-Aktensystem MUSS eine Speicherkapazität von 300 GB in der TU bereit stellen.
[<=]

Aufbau sicherer Kanal zwischen der VAU und einem ePA-Client

A_15698 - Performance - ePA-Aktensystem - Verbindungsaufbau

Das ePA-Aktensystem MUSS beim Aufbau der sicheren Verbindung zwischen VAU und einem ePA-Client die Bearbeitungszeitvorgabe aus Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau bezüglich der von ihm verursachten Verarbeitungszeit erfüllen.

Tabelle 57: Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau

Bearbeitungszeitvorgaben
Mittelwert [sec]	95%-Quantil [sec]
1,5	1,7

[<=]

Der Anbieter ePA-Aktensystem erfasst Performance-Daten für die Bereitstellung des Verarbeitungskontextes der VAU durch Messung des Zeitraumes zwischen Empfang des ersten Client-Request der Session (valides VAUClientHello) bis zum vollständigen Senden der letzten Handshake-Nachricht ( VAUServerFin) . Kann die Beantwortung nicht erfolgen und der Vorgang wird dadurch abgebrochen, dann muss dies als abgelehnter Aufruf gewertet werden. Die Zeit bis zum Abbruch wird nicht in der summierten Bearbeitungszeit erfasst.

A_15212 - Performance - ePA-Aktensystem - Skalierung

Der Anbieter ePA-Aktensystem MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]

Im Zuge des Zulassungsverfahrens hat der Anbieter ePA-Aktensystem der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

A_16177 - Performance - ePA-Aktensystem - Verfügbarkeit

Der Anbieter ePA-Aktensystem MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

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

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

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

Die Verfügbarkeit der funktionalen Eigenschaften des ePA-Aktensystems wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

A_1729218181 - Performance - Erfassung von Rohdaten - ePA-Aktensystem

Der AnbieterDas ePA-Aktensystem MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_ePA" erfassen.  und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]

A_17293 - Performance - Lieferung von Rohdaten - ePA-Aktensystem

Der Anbieter ePA-Aktensystem MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich. [<=]

A_15743 - Performance - ePA-Aktensystem - Bestandsdaten

Der Anbieter ePA-Aktensystem MUSS im Performance-Report zu einem Stichtag des betreffenden Erfassungszeitraums folgende Performance-Kenngrößen über das ePA-Aktensystem berichten:

• Anzahl der Aktenkonten
• Anzahl der Dokumente
• Gesamtkapazität

Der Anbieter ePA-Aktensystem MUSS die Bestandsdaten an den Endpunkt gemäß [gemSpec_SST_LD_BD] liefern. 



[<=]

5 Anhang A – Verzeichnisse

5.1 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

5.2 Abbildungsverzeichnis

Abbildung 1: Beispiel für Zerlegung einer Funktion und die Modell-Bearbeitungszeitgrößen

Abbildung 2: Beispiel für gemessene Aufrufe, die zu Aufrufzeitpunkten erfolgen

Abbildung 3: Beispiel einer über den Zeitraum T gemittelten Aufrufrate

Abbildung 4: Entwicklung der Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) aus einer Durchschnittslast pro Jahr.

Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen

Abbildung 6: Messpunkte zur Konnektor Performance-Messung

Abbildung 7: Messaufbau zum IPSec-Durchsatzmessung

Abbildung 8: Messpunkte zur Kartenterminal Performance-Messung

Abbildung 9: Netzwerktopologie – Punkte mit Lastvorgaben (orange)

5.3 Tabellenverzeichnis

Tabelle 1: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM

Tabelle 2: Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA

Tabelle 3: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

Tabelle 4: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD

Tabelle 5: Mengengerüst: Versicherte und Leistungserbringer

Tabelle 6: Mengengerüst: Lokationen

Tabelle 7: Mengengerüst: Krankenhäuser (Quelle: [DKG2010])

Tabelle 8: Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen

Tabelle 9: Mengengerüst: Annahmen für Modellierung

Tabelle 10: VSDM Anwendungsfälle

Tabelle 11: Lastmodell: Nutzung bestehender Anwendungen und Netze

Tabelle 12: Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 13: Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 14: Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen

Tabelle 15: Lastmodell: Krankenhäuser (Quelle: [DKG2010])

Tabelle 16: Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 17: Lastmodell: KOM-LE in Krankenhäusern

Tabelle 18: Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 19: Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken

Tabelle 20: Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser

Tabelle 21: ePA-Anwendungsfälle je LE-U

Tabelle 22: Lastmodell ePA aus der Versicherten-Umgebung

Tabelle 23: Mengenrahmen „Update Konnektor und Kartenterminals“

Tabelle 24: Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall

Tabelle 25: Bearbeitungszeitvorgaben NFDM je Anwendungsfall

Tabelle 26: Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall

Tabelle 27: ePA Bearbeitungszeitvorgaben je Anwendungsfall

Tabelle 28: Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall

Tabelle 29: Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus

Tabelle 30: Caching-Dauer

Tabelle 31: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben

Tabelle 32: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B

Tabelle 33: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS

Tabelle 34: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell

Tabelle 35: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch

Tabelle 36: Tab_gemSpec_Perf_Signaturproxy_1

Tabelle 37: Tab_gemSpec_Perf_Signaturproxy_2

Tabelle 38: Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben

Tabelle 39 : Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung

Tabelle 40: Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe

Tabelle 41: Tab_gemSpec_Perf_Verzeichnisdienst: Last- u. Bearbeitungszeitvorgaben

Tabelle 42: Tab_gemSpec_Perf_Konfigurationsdienst: Last- u. Bearbeitungszeitvorgaben

Tabelle 43: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben

Tabelle 44: Tab_gemSpec_Perf_OCSP_Responder – Last- und Bearbeitungszeitvorgaben

Tabelle 45: Tab_gemSpec_Perf_Störungsampel – Lastvorgaben

Tabelle 46: Tab_gemSpec_Perf_Namensdienst: Last- u. Bearbeitungszeitvorgaben

Tabelle 47: Tab_gemSpec_Perf_Netzlast_1 Spitzenlasten am VPN-Zugangsdienst (Punkt 1)

Tabelle 48: Tab_gemSpec_Perf_Netzlast_2_12 Spitzenlasten (Punkte 2-12) 

Tabelle 49: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben

Tabelle 50: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben

Tabelle 51: Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben

Tabelle 52: Tab_gemSpec_Perf_VSDM_Fachdienste: Last- und Bearbeitungszeitvorgaben

Tabelle 53: Tab_gemSpec_Perf_KOMLE_Clientmodul: Last- und Bearbeitungszeitvorgaben

Tabelle 54: Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge: Zerlegung Bearbeitungszeiten

Tabelle 55: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben

Tabelle 56: Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben

Tabelle 57: Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau

Tabelle 58: Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente

Tabelle 59: Tab_gemSpec_Perf_Performance-Dimensionen

Tabelle 60: Tab_gemSpec_Perf_Performance-Groessen

Tabelle 61: Tab_gemSpec_Perf_Produkttypen

Tabelle 62: Tab_gemSpec_Perf_Schnittstellenoperationen

Tabelle 63: Tab_gemSpec_Perf_Zertifikatstypen

Tabelle 64: Tab_gemSpec_Perf_Aufrufquelle

Tabelle 65: Tab_gemSpec_Perf_Performance-Kenngroessen

Tabelle 66: Tab_gemSpec_Perf_Beispiel_Rohdaten

Tabelle 67: Tab_gemSpec_Perf_Beispiel_Performance_Kenngroessen

Tabelle 68: Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen

Tabelle 69: Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen

Tabelle 70: Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen

Tabelle 71: Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen

Tabelle 72: Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben

Tabelle 73: Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen

Tabelle 74: Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen

5.4 Referenzierte Dokumente

5.4.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

5.4.2 Weitere Dokumente

6 Anhang B – Modelldetails

6.1 Verteilung der Konnektorbearbeitungszeiten auf Komponenten

Die Bearbeitungszeitvorgaben in Tabelle 23 an den Konnektor beinhalten die interne Bearbeitungszeit des Konnektors, des Kartenterminals mit Karte, des Leistungserbringer-LANs und des OCSP-Responders. Wie sich die vom Konnektor gesamt zu verantwortende Bearbeitungszeit auf diese einzelnen Komponenten verteilt, gibt Tabelle 45 an.

Tabelle 58: Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente

Schnittstellenoperationen	Konnektor Gesamt [msec]	Konnektor intern mit LE-LAN [msec]	Kartenterm. + Karte [msec]	OCSP + Zugangsnetz+ Zentr.Netz [msec]
Lesen VSD mit Onlineprüfung mit Aktualisierung	6130	1250	3780	1100
Lesen VSD mit Onlineprüfung ohne Aktualisierung	3940	790	3150	0
Lesen VSD ohne Onlineprüfung	3820	610	3210	0
Automatische Onlineprüfung mit Aktualisierung der VSD	5720	1030	3590	1100
Automatische Onlineprüfung ohne Aktualisierung der VSD	3130	460	2670	0
NFD von eGK lesen	7260	1070	4080	2110
NFD auf eGK schreiben	5780	850	4930	0
NFD von eGK löschen	4800	810	3990	0
DPE von eGK lesen	4300	935	3365	0
DPE auf eGK schreiben	4590	975	3615	0
DPE von eGK löschen	4260	810	3450	0
I_AMTS_Service::ReadMP	5268	1010	4258	0
I_AMTS_Service::WriteMP (mit C2C)	6625	1120	5505	0
I_AMTS_Service::WriteMP (ohne C2C)	4020	1020	3000	0
I_Sign_Operations::sign_Document (10 kB)	1010	300	710	0
I_Sign_Operations::sign_Document (100 kB)	1030	320	710	0
I_Sign_Operations::sign_Document (1 MB) (XAdES, XML_1MB, enveloped) (CAdES, TIFF_1MB, detached) (PAdES, PDFA_2b_1MB_Komplex)	1440	730	710	0
I_Sign_Operations::sign_Document (XAdES, XML_25MB, enveloped)	10500	9790	710
I_Sign_Operations::sign_Document (CAdES, TIFF_25MB, detached)	7300	6590	710
I_Sign_Operations::sign_Document (PAdES, PDFA_2b_25MB_Bilder_ und_Text)	7300	6590	710
I_Sign_Operations::verify_Document (10 kB)	1570	470	0	1100
I_Sign_Operations::verify_Document (100 kB)	1600	500	0	1100
I_Sign_Operations::verify_Document (1 MB) (XAdES, XML_1MB, enveloped) (CAdES, TIFF_1MB, detached) (PAdES, PDFA_2b_1MB_Komplex)	1930	830	0	1100
I_Sign_Operations::verify_Document (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)	9000	7900	0	1100
I_Sign_Operations::verify_Document   (CAdES, TIFF_25MB, IncludeRevocationInfo=false)	9000	7900	0	1100
I_Sign_Operations::verify_Document   (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)	10600	9500	0	1100
I_SAK_Operations::sign_Document_ QES (10KB)	3540	520	910	2110
I_SAK_Operations::sign_Document_ QES (100KB, Stapelgröße 1, SE#1)	3790	770	910	2110
I_SAK_Operations::sign_Document_ QES (100KB, Stapelgröße 2, SE#2)	8870	1430	5330	2110
I_SAK_Operations::sign_Document_ QES (1MB)	4070	1050	910	2110
I_SAK_Operations::sign_Document_ QES (25MB)
I_SAK_Operations::sign_Document_ QES (XAdES, XML_25MB, enveloped)	12810	9790	910	2110
I_SAK_Operations::sign_Document_ QES (CAdES, TIFF_25MB)	9610	6590	910	2110
I_SAK_Operations::sign_Document_ QES (PAdES, PDFA_2b_25MB)	9610	6590	910	2110
I_SAK_Operations::verify_Document_ QES (10KB)	2580	470	0	2110
I_SAK_Operations::verify_Document_ QES (100KB)	0 2610	500	0	2110
I_SAK_Operations::verify_Document_ QES (1 MB)	2940	830	0	2110
I_SAK_Operations::verify_Document_ QES (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)	10010	7900	0	2110
I_SAK_Operations::verify_Document_ QES  (CAdES, TIFF_25MB, IncludeRevocationInfo=false)	10010	7900	0	2110
I_SAK_Operations::verify_Document_ QES  (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)	11610	9500	0	2110
I_KV_Card_Unlocking::authorize_Card (no Cache)	2020	100	1920	0
I_KV_Card_Unlocking::authorize_Card (Cache)	1830	100	1730	0
I_Crypt_Operations::encrypt_Document (10 kB)	1860	760	0	1100
I_Crypt_Operations::encrypt_Document (100 kB)	1880	780	0	1100
I_Crypt_Operations::encrypt_Document (1 MB)	2200	1100	0	1100
I_Crypt_Operations::encrypt_Document (XMLEnc, XML_25MB, ein Empfänger)	10600	9500	0	1100
I_Crypt_Operations::encrypt_Document (CMS, TIFF_25MB, ein Empfänger)	7800	6700	0	1100
I_Crypt_Operations::decrypt_Document (10 kB)	490	150	340	0
I_Crypt_Operations::decrypt_Document (100 kB)	510	170	340	0
I_Crypt_Operations::decrypt_Document (1 MB)(XMLEnc, XML_1MB)(CMS, TIFF_1MB)	820	480	340	0
I_Crypt_Operations::decrypt_Document (XMLEnc, XML_25MB)	8900	8560	340
I_Crypt_Operations::decrypt_Document (CMS, TIFF_25MB)	8900	8560	340
I_Cert_Verification::verify_Certificate	1150	50	0	1100
I_Directory_Query::search_Directory	2220	2000	0	220

7 Anhang C – Performance-Kenngrößen

Für die Performance-Größen (Tab_gemSpec_Perf_Performance-Groessen) zu den Performance-Dimensionen (Tab_gemSpec_Perf_Performance-Dimensionen) erfassen und reporten die Produkttypen (Tab_gemSpec_Perf_Produkttypen) für die Schnittstellenoperationen (Tab_gemSpec_Perf_Schnittstellenoperationen) die Performance-Kenngrößen gemäß Tab_gemSpec_Perf_Performance-Kenngroessen. OCSP-Responder liefern Performance-Größen getrennt nach Zertifikatstypen (Tab_gemSpec_Perf_Zertifikatstypen).

Das Zentrale Netz erfasst Ausfälle bezogen auf die Verbindungen (Vxx) zwischen konkreten Produktinstanzen pi der TI vom Typ VPN-Zugangsdienst, Zentraler Dienst TI-Plattform, Fachanwendungsspezifischer Dienst und Sicherheitsgateway Bestandsnetze . Siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“.

Der konkrete Bezeichner Vxx für eine Verbindung zwischen den beiden  SZZPs szzp1 und szzp2 lautet

Vxx = „V“ +  szzp1  + „_„  + szzp2
 

Relevant sind dafür nur die einem Aufrufer sichtbaren SZZPs (auch als „logischer SZZP“ bezeichnet), nicht einzelne physische Instanzen, die gemeinsam zur Verfügbarkeit des SZZPs beitragen. Die konkreten Bezeichner für die logischen SZZPs sind mit gematik Betrieb (Operations) abzustimmen. szzp1 sei immer der Bezeichner, der in alphanumerischer Sortierung vor szzp2 ePA-Aktensystem - Bereitstellung

liegt.

Beispiel: PDT08-S01-D3-G10-V0001_0007

Das Zentrale Netz erfasst gemäß [GS-A_5014] an seinen Sicheren Zentralen Zugangspunkten (SZZP) die Datenmengen getrennt nach Richtungen Rxx. Dabei gibt die Richtung Rxx an, welche Dienstinstanz betroffen ist und ob der Fluss zur Instanz hin (Rz) oder von der Instanz weg (Rv) erfolgt.

Der Bezeichner Rxx setzt sich zusammen aus „Rz“ für die Richtung zur Dienstinstanz hin und „Rv“ für die Richtung von der Dienstinstanz weg sowie einem Bezeichner für die Dienstinstanz. Der Bezeichner für die Dienstinstanz setzt sich aus drei durch "_" getrennten Teilen zusammen. Einem Bezeichner für den logischen SZZP, einem Bezeichner für den Produkttypen und einem Bezeichner für den Anbieter des Dienstes. Die konkreten Bezeichner für die logischen SZZPs und Anbieter sind mit gematik Betrieb (Operations) abzustimmen. Die Bezeichner für die Produkttypen gibt Tabelle Tab_gemSpec_Perf_Produkttypen vor.

Beispiel: PDT08-S11-D1-G02-Rv0001_PDT04_ARVTO

Entsprechend der Umsetzung von [GS-A_4759] für die VSDM-Produkttypen erfolgt in [GS-A_5014] abweichend von der generellen Regelung die Volumenerfassung für die VSDM-Produkttypen pro SZZP in Summe über Anbieter und VSDM-Produkttypen (nur aufgeschlüsselt nach Richtung).

Damit die Syntax der Bezeichner auch für diesen Ausnahmefall erhalten bleibt, wird als Produkttypbezeichner „VSDM“ gesetzt und als Anbieterbezeichner „XXXXX“.
Beispiel:  PDT08-S11-D1-G02-Rz0035_VSDM_XXXXX

Für den Produkttyp VPN-Zugangsdienst werden zur Unterscheidung einzelner VPN-Konzentratoren zwei weitere Bezeichnungen VPNK-TI_X (VPN-Konzentrator TI) und VPNK-SIS_X (VPN-Konzentrator SIS) eingeführt. Der Platzhalter „X“ ist ein eindeutiger Bezeichner eines VPN-Konzentrators und wird durch den Anbieter des VPN-Zugangsdienstes vergeben. Es sind 32 Zeichen zulässig. 

Beispiel: PDT09-S11-D1-G03-VPNK-TI_vpnk1.fra.providerx.de

Tabelle Tab_gemSpec_Perf_Beispiel_Rohdaten zeigt exemplarisch die in zwei Erfassungszeiträumen gemessenen Performance-Daten zu einzelnen Anfragen und Tabelle Tab_gemSpec_Perf_Beispiel_Performance_Kenngroessen die aus diesen generierten Performance-Kenngrößen.

Tabelle 59: Tab_gemSpec_Perf_Performance-Dimensionen

ID	Performance-Dimension
D1	Last
D2	Bearbeitungszeit
D3	Verfügbarkeit

Tabelle 60: Tab_gemSpec_Perf_Performance-Groessen

ID	Größe	Einheit
D1-G01	Anzahl der Aufrufe im Erfassungszeitraum	Integer
D1-G02	Datenmenge [kByte] pro Richtung	Integer
D1-G03	Datenmenge [kByte] in Richtung zum Internet	Integer
D1-G04	Datenmenge [kByte] in Richtung vom Internet	Integer
D1-G05	Anzahl der bestehenden VPN-Tunnel	Integer
D1-G06	Anzahl der neu aufgebauten VPN-Tunnel	Integer
D1-G07	Anzahl der abgebauten VPN-Tunnel	Integer
D1-G08	Mittlerer Datendurchsatz pro Richtung in Mbits/s im Erfassungszeitraum	Integer
D1-G09	Anzahl der im Erfassungszeitraum abgelehnten Aufrufe	Integer
D2-G03	Anzahl der Summierten Bearbeitungszeiten	Integer
D2-G04	Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum	Integer
D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	Integer
D2-G06	Mittel der RoundtripTime für IP-Pakete über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt [msec]	Integer
D2-G07	Mittel der Verlustrate für IP-Pakete über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt [%/1000]	Integer
D2-G08	Mittlere Bearbeitungszeit pro Monat [msec]	Integer
D3-G10	Startzeitpunkt eines Ausfalls	Zeitstempel (Auflösung sec)
D3-G11	Endezeitpunkt eines Ausfalls	Zeitstempel (Auflösung sec)
D3-G12	Verfügbarkeit pro Monat [%/1000]	Integer
D3-G14	Verfügbarkeit pro Monat zur Hauptzeit [%/1000]	Integer
D3-G16	Verfügbarkeit pro Monat zur Nebenzeit [%/1000]	Integer
D3-G18	Verfügbarkeit pro Monat zur Hauptzeit über alle IP-Verbindungen zwischen SZZPs der angeschlossenen Produkttypen der TI, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „Niedrige Verfügbarkeit“ angebunden ist. [%/1000]	Integer
D3-G19	Verfügbarkeit pro Monat zur Hauptzeit, gemittelt über alle IP-Verbindungen zwischen allen SZZPs mit der Anschlussoption „Hohe Verfügbarkeit“ angeschlossenen Produkttypen der TI. [%/1000]	Integer
D3-G22	Verfügbarkeit pro Monat zur Nebenzeit, gemittelt über alle IP-Verbindungen zwischen allen SZZPs mit der Anschlussoption „Hohe Verfügbarkeit“ angeschlossenen Produkttypen der TI. [%/1000]	Integer
D2-G24	Anzahl der Bearbeitungszeiten größer als die 95%-Quantilschranke des Produkttyps	Integer
D3-G25	Verfügbarkeit pro Monat zur Nebenzeit über alle IP-Verbindungen zwischen SZZPs der angeschlossenen Produkttypen der TI, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „Niedrige Verfügbarkeit“ angebunden ist. [%/1000]	Integer
D2-G27	Summe der Bearbeitungszeiten im Erfassungszeitraum, gemessen zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE Clientmodul an den KOM-LE-Fachdienst des Email-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE Fachdienst des Email-Empfängers [sec]	Integer
D2-G28	Größte Bearbeitungszeit im Erfassungszeitraum, gemessen zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE Clientmodul an den KOM-LE-Fachdienst des Email-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE Fachdienst des Email-Empfängers [sec]	Integer
D2-G29	Anzahl der Bearbeitungszeiten mit Überschreitung der Bearbeitungszeitvorgabe	Integer

Tabelle 61: Tab_gemSpec_Perf_Produkttypen

ID	Produkttyp
PDT01	OCSP-Proxy
PDT02	TSP-X.509QES
PDT03	TSP-X.509nonQES
PDT04	TSL-Dienst
PDT05	Störungsampel
PDT06	Namensdienst
PDT07	Zeitdienst
PDT08	Zentrales Netz der TI
PDT09	VPN-Zugangsdienst
PDT10	Sicherheitsgateway Bestandsnetze
PDT11	Konfigurationsdienst
PDT12	eGK
PDT13	HBA
PDT14	SMC-B
PDT15	SMC-K
PDT16	SMC-KT
PDT17	Konnektor
PDT18	eHealth-Kartenterminal
PDT19	Mobiles Kartenterminal
PDT20	Fachdienste VSDM (UFS)
PDT21	Intermediär VSDM
PDT22	gematik-Root-CA
PDT23	Fachdienst VSDM (VSDD)
PDT24	KOM-LE Fachdienst
PDT25	Verzeichnisdienst
PDT26	Fachdienst VSDM (CMS)
PDT27	KOM-LE Clientmodul
PDT29	Fachmodul VSDM
PDT31	TSP-CVC
PDT32	CVC-Root
PDT33	HSM-B
PDT34	Fachmodul VSDM (mobKT)
PDT35	Komponente AdV-Server der KTR-AdV

Tabelle 62: Tab_gemSpec_Perf_Schnittstellenoperationen

ID	Schnittstellen::Operation
S01	I*
S02	I_KSRS_Download::list_Updates
S04	I_KSRS_Download::get_Updates
S05	I_OCSP_Status_Information::check_Revocation_Status
S06	I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
S07	I_DNS_Service_Localization
S08	I_DNS_Name_Resolution::get_IP_Address
S09	I_DNS_Name_Resolution::get_FQDN
S10	I_IP_Transport(P::Verbindung)
S11	I_IP_Transport(P::Verbindung+Richtung)
S12	I_TSL_Download
S13	I_NTP_Time_Information
S14	I_Secure_Access_Bestandsnetz
S15	I_Secure_Channel_Tunnel
S16	I_Directory_Query
S17	I_BNetzA_VL_Download::download_VL

Tabelle 63: Tab_gemSpec_Perf_Zertifikatstypen

ID	Zertifikatstypen
Z01	HBA-Zertifikate (C.HP.QES): Root-Zert
Z02	HBA-Zertifikate (C.HP.QES): CA-Zert
Z03	HBA-Zertifikate (C.HP.QES): EE-Zert
Z04	eGK-Zertifikate (C.CH.AUT)
Z05	SMC-B-Zertifikate (C.HCI.OSIG)
Z06	HBA-Zertifikate (C.HP.ENC)
Z07	SMC-B Zertifikate (C.HCI.ENC)
Z08	Konnektor-Zertifikate (SMC-K, C.NK.VPN)
Z09	SMC-B-Zertifikate (C.HCI.AUT)
Z10	TLS Zertifikate der zentralen Dienste (C.ZD.TLS)
Z11	TLS Zertifikate der Fachdienste (C.FD.TLS)
Z12	TSL-Signerzertifikat
Z13	HBA-Zertifikate (C.HP.AUT)
Z14	HBA-Zertifikate (C.HP.AUT): CA-Zert
Z16	SMC-B-Zertifikate (C.HCI.AUT): CA-Zert
Z17	SMC-B-Zertifikate (C.HCI.ENC): CA-Zert
Z18	HBA-Zertifikate (C.HP.ENC): CA-Zert
Z19	gematikRoot-CA-Zert
Z20	Sonstige oben nicht genannte Zertifikate (z.B. für HBA-Vorläuferkarten)

Tabelle 64: Tab_gemSpec_Perf_Aufrufquelle

ID	Aufrufquelle
Q1	aus der TI
Q2	aus dem Internet

Tabelle 65: Tab_gemSpec_Perf_Performance-Kenngroessen

Produkttyp - Schnittstelle
Performance- Kenngröße	Performance-Grösse	Störungs- ampel	Service- Level- Report	Performance- Report
AdV-Server
PDT35-S01-D3-G10	Startzeitpunkt eines Ausfalls			x
PDT35-S01-D3-G11	Endezeitpunkt eines Ausfalls			x
PDT35-S01-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT35-S01-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
OCSP-Proxy - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
PDT01-S06-D1-G01-Z20	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT01-S06-D2-G03-Z20	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT01-S06-D2-G04-Z20	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT01-S06-D2-G05-Z20	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT01-S06-D2-G08-Z20	Mittlere Bearbeitungszeit pro Monat		x
PDT01-S06-D3-G10-Z20	Startzeitpunkt eines Ausfalls	x		x
PDT01-S06-D3-G11-Z20	Endezeitpunkt eines Ausfalls	x		x
PDT01-S06-D3-G14-Z20	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT01-S06-D3-G16-Z20	Verfügbarkeit pro Monat zur Nebenzeit		x
TSP-X.509QES - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
PDT02-S06-D1-G01-Z03-Qy	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT02-S06-D2-G03-Z03-Qy	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT02-S06-D2-G04-Z03-Qy	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT02-S06-D2-G05-Z03-Qy	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT02-S06-D2-G08-Z03-Qy	Mittlere Bearbeitungszeit pro Monat		x
PDT02-S06-D3-G10-Z03-Qy	Startzeitpunkt eines Ausfalls	x		x
PDT02-S06-D3-G11-Z03-Qy	Endezeitpunkt eines Ausfalls	x		x
PDT02-S06-D3-G14-Z03-Qy	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT02-S06-D3-G16-Z03-Qy	Verfügbarkeit pro Monat zur Nebenzeit		x
TSP-X.509nonQES - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
PDT03-S06-D1-G01-Zxx-Qy	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT03-S06-D2-G03-Zxx-Qy	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT03-S06-D2-G04-Zxx-Qy	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT03-S06-D2-G05-Zxx-Qy	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT03-S06-D2-G08-Zxx-Qy	Mittlere Bearbeitungszeit pro Monat		x
PDT03-S06-D3-G10-Zxx-Qy	Startzeitpunkt eines Ausfalls	x		x
PDT03-S06-D3-G11-Zxx-Qy	Endezeitpunkt eines Ausfalls	x		x
PDT03-S06-D3-G14-Zxx-Qy	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT03-S06-D3-G16-Zxx-Qy	Verfügbarkeit pro Monat zur Nebenzeit		x
TSL-Dienst - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
PDT04-S06-D1-G01-Z12	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT04-S06-D2-G03-Z12	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT04-S06-D2-G04-Z12	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT04-S06-D2-G05-Z12	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT04-S06-D2-G08-Z12	Mittlere Bearbeitungszeit pro Monat		x
PDT04-S06-D3-G10-Z12	Startzeitpunkt eines Ausfalls	x		x
PDT04-S06-D3-G11-Z12	Endezeitpunkt eines Ausfalls	x		x
PDT04-S06-D3-G12-Z12	Verfügbarkeit pro Monat		x
TSL-Dienst - I_TSL_Download
PDT04-S12-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT04-S12-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT04-S12-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT04-S12-D3-G12	Verfügbarkeit pro Monat		x
TSL-Dienst - I_BNetzA_VL_Download::download_VL
PDT04-S17-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT04-S17-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT04-S17-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT04-S17-D3-G12	Verfügbarkeit pro Monat		x
Störungsampel
PDT05-S01-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT05-S01-D3-G10	Startzeitpunkt eines Ausfalls			x
PDT05-S01-D3-G11	Endezeitpunkt eines Ausfalls			x
PDT05-S01-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT05-S01-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Namensdienst - I_DNS_Service_Localization
PDT06-S07-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT06-S07-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT06-S07-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT06-S07-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT06-S07-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT06-S07-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT06-S07-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT06-S07-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT06-S07-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Namensdienst - I_DNS_Name_Resolution::get_IP_Address
PDT06-S08-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT06-S08-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT06-S08-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT06-S08-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT06-S08-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT06-S08-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT06-S08-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT06-S08-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT06-S08-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Namensdienst - I_DNS_Name_Resolution::get_FQDN
PDT06-S09-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT06-S09-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT06-S09-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT06-S09-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT06-S09-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Zeitdienst - I_NTP_Time_Information
PDT07-S13-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT07-S13-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT07-S13-D3-G12	Verfügbarkeit pro Monat		x
Zentrales Netz
PDT08-S01-D2-G06	Mittel der RoundtripTime für IP-Pakete über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt	x	x	x
PDT08-S01-D2-G07	Mittel der Verlustrate für IP-Pakete über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt	x	x	x
PDT08-S01-D3-G10-Vxx	Startzeitpunkt eines Ausfalls	x		x
PDT08-S01-D3-G11-Vxx	Endezeitpunkt eines Ausfalls	x		x
PDT08-S01-D3-G18	Verfügbarkeit pro Monat zur Hauptzeit über alle IP-Verbindungen zwischen SZZPs der angeschlossenen Produkttypen der TI, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „Niedrige Verfügbarkeit“ angebunden ist.		x
PDT08-S01-D3-G19	Verfügbarkeit pro Monat zur Hauptzeit, gemittelt über alle IP-Verbindungen zwischen allen SZZPs mit der Anschlussoption „Hohe Verfügbarkeit“ angeschlossenen Produkttypen der TI.		x
PDT08-S01-D3-G22	Verfügbarkeit pro Monat zur Nebenzeit, gemittelt über alle IP-Verbindungen zwischen allen SZZPs mit der Anschlussoption „Hohe Verfügbarkeit“ angeschlossenen Produkttypen der TI.		x
PDT08-S01-D3-G25	Verfügbarkeit pro Monat zur Nebenzeit über alle IP-Verbindungen zwischen SZZPs der angeschlossenen Produkttypen der TI, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „Niedrige Verfügbarkeit“ angebunden ist.		x
Zentrales Netz - I_IP_Transport(P::Verbindung)
PDT08-S10-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT08-S10-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT08-S11-D1-G02-Rxx	Datenmenge (kByte) und Richtung	x	x	x
VPN-Zugangsdienst
PDT09-S01-D1-G08	Mittlerer Datendurchsatz pro Richtung in Mbit/s im Erfassungszeitraum			x
VPN-Zugangsdienst - I_DNS_Name_Resolution::get_IP_Address
PDT09-S08-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT09-S08-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT09-S08-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT09-S08-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT09-S08-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT09-S08-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT09-S08-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT09-S08-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT09-S08-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
VPN-Zugangsdienst - I_NTP_Time_Information
PDT09-S13-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT09-S13-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT09-S13-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT09-S13-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
VPN-Zugangsdienst - I_Secure_Channel_Tunnel
PDT09-S15-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT09-S15-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT09-S15-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT09-S15-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
PDT09-S15-D1-G05	Anzahl der bestehenden VPN-Tunnel			X
PDT09-S15-D1-G06	Anzahl der neu aufgebauten VPN-Tunnel			X
PDT09-S15-D1-G07	Anzahl der abgebauten VPN-Tunnel			x
Sicherheitsgateway KV-Safenet - I_Secure_Access_Bestandsnetz
PDT10-S14-D1-G02	Datenmenge (kByte) pro Verbindung und Richtung	x		x
PDT10-S14-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT10-S14-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT10-S14-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT10-S14-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Konfigurationsdienst - I_KSRS_Download::get_Updates
PDT11-S04-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT11-S04-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT11-S04-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT11-S04-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT11-S04-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT11-S04-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT11-S04-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT11-S04-D3-G12	Verfügbarkeit pro Monat		x
Konfigurationsdienst – I_KSRS_Download::list_Updates
PDT11-S02-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT11-S02-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT11-S02-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT11-S02-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT11-S02-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT11-S02-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT11-S02-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT11-S02-D3-G12	Verfügbarkeit pro Monat		x
Intermediär VSDM
PDT21-S01-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT21-S01-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x	x	x
PDT21-S01-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT21-S01-D2-G24	Anzahl der Bearbeitungszeiten größer als die 95%-Quantilschranke des Produkttyps	x	x	x
PDT21-S01-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
PDT21-S01-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT21-S01-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT21-S01-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT21-S01-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
gematik-Root-CA - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp)
PDT22-S06-D1-G01-Zxx	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT22-S06-D2-G03-Zxx	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT22-S06-D2-G04-Zxx	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT22-S06-D2-G05-Zxx	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT22-S06-D2-G08-Zxx	Mittlere Bearbeitungszeit pro Monat		x
PDT22-S06-D3-G10-Zxx	Startzeitpunkt eines Ausfalls	x		x
PDT22-S06-D3-G11-Zxx	Endezeitpunkt eines Ausfalls	x		x
PDT22-S06-D3-G14-Zxx	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT22-S06-D3-G16-Zxx	Verfügbarkeit pro Monat zur Nebenzeit		x
KOM-LE Fachdienst
PDT24-S17-D2-G27	Summe der Bearbeitungszeiten im Erfassungszeitraum, gemessen zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE Clientmodul an den KOM-LE-Fachdienst des Email-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE Fachdienst des Email-Empfängers	x	x	x
PDT24-S17-D2-G03	Anzahl der Summierten Bearbeitungszeiten im Erfassungszeitraum	x	x	x
PDT24-S17-D2-G28	Größte Bearbeitungszeit im Erfassungszeitraum, gemessen zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE Clientmodul an den KOM-LE-Fachdienst des Email-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE Fachdienst des Email-Empfängers		x	x
PDT24-S01-D1-G02	Datenmenge (KByte) pro Verbindung und Richtung	x		x
PDT24-S01-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT24-S01-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT24-S01-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT24-S01-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT24-S01-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x
Verzeichnisdienst – I_Directory_Query
PDT25-S16-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT25-S16-D2-G03	Anzahl der Summierten Bearbeitungszeiten	x		x
PDT25-S16-D2-G04	Summe der Bearbeitungszeiten im Erfassungszeitraum	x		x
PDT25-S16-D2-G05	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	x		x
PDT25-S16-D2-G08	Mittlere Bearbeitungszeit pro Monat		x
Verzeichnisdienst
PDT25-S01-D1-G01	Anzahl der Aufrufe im Erfassungszeitraum			x
PDT25-S01-D3-G10	Startzeitpunkt eines Ausfalls	x		x
PDT25-S01-D3-G11	Endezeitpunkt eines Ausfalls	x		x
PDT25-S01-D3-G14	Verfügbarkeit pro Monat zur Hauptzeit		x
PDT25-S01-D3-G16	Verfügbarkeit pro Monat zur Nebenzeit		x

Tabelle 66: Tab_gemSpec_Perf_Beispiel_Rohdaten

Zeitpunkt Anfrage	fehlerfrei bearbeitet:   ja/nein	Bearbeitungsdauer [msec]
14.07.2014 13:30:01	ja	907
14.07.2014 13:30:47	ja	830
14.07.2014 13:31:05	ja	790
14.07.2014 13:31:13	ja	719
14.07.2014 13:32:02	ja	1013
14.07.2014 13:32:32	ja	1026
14.07.2014 13:32:33	ja	920
14.07.2014 13:34:23	ja	760
14.07.2014 13:34:31	ja	840
14.07.2014 13:34:55	ja	710
14.07.2014 13:35:03	ja	828
14.07.2014 13:35:09	ja	730
14.07.2014 13:35:15	ja	731
14.07.2014 13:35:17	ja	864
14.07.2014 13:35:17	ja	1708
14.07.2014 13:35:18	nein	-
14.07.2014 13:35:40	ja	901
14.07.2014 13:38:22	ja	839
14.07.2014 13:39:06	ja	1280
14.07.2014 13:39:16	ja	1189
14.07.2014 13:39:34	ja	844

Tabelle 67: Tab_gemSpec_Perf_Beispiel_Performance_Kenngroessen

TSP-X.509nonQES - I_OCSP_Status_Information::check_Revocation_Status(P::Zertifikatstyp) - HBA-Zertifikate (C.HP.ENC)
Größe		Wert
Erfassungszeitraum	von	14.07.2014 13:30:00
	bis	14.07.2014 13:34:59
PDT03-S06-D1-G01-Z06	Anzahl der Aufrufe im Erfassungszeitraum	10
PDT03-S06-D2-G03-Z06	Anzahl der Summierten Bearbeitungszeiten	10
PDT03-S06-D2-G04-Z06	Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum	8515
PDT03-S06-D2-G05-Z06	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	0
Erfassungszeitraum	von	14.07.2014 13:35:00
	bis	14.07.2014 13:39:59
PDT03-S06-D1-G01-Z06	Anzahl der Aufrufe im Erfassungszeitraum	11
PDT03-S06-D2-G03-Z06	Anzahl der Summierten Bearbeitungszeiten	10
PDT03-S06-D2-G04-Z06	Summe der Bearbeitungszeiten [msec] im Erfassungszeitraum	9914
PDT03-S06-D2-G05-Z06	Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke des Produkttyps	1

 

8 Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors

Im Folgenden werden die erforderlichen, performance-relevanten Produktmustereigenschaften des QES-Konnektors festgelegt, auf deren Basis die zum Nachweis von [GS-A_5327] erforderlichen Performance-Messungen durchgeführt werden können.

Entsprechend der Lastvorgaben aus [GS-A_5327] für 8 Anwendungen wird das Messverfahren festgelegt. Auf Grund der unterschiedlichen Lastanforderungen für die beiden Ausprägungsformen „Einbox-Konnektor“ und „HighSpeed-Konnektor“ wird das Verfahren für beide Fälle dargestellt.

Aus den Lastvorgaben in Tab_gemSpec_Perf_Konnektor und dem Skalierungsfaktor 8/3 wird die perspektivische Last für 8 Anwendungen berechnet. Dabei werden jeweils Operationen mit 25MB-Dokumenten und Operationen mit 100kB-Dokumenten als eine Klasse betrachtet. Die Wahrscheinlichkeit, dass n parallele Bearbeitungen zu einem Zeitpunkt stattfinden, ergibt sich als Poisson-Verteilung mit dem Erwartungswert „Last * Mittlere Bearbeitungszeit“.

Einbox-Konnektor

Tabelle 68: Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen

					Wahrscheinlichkeit für n parallele Aufrufe zu einem Zeitpunkt
	Last [1/h]	Last *8/3 [1/h]	Mittlere Bearb.z. [ms]	Last * Mittlere Bearb.z. [Anzahl]	0	1	2	3	4
I_Sign_Operations:: sign_Document (100 kB, LE-U2)	389	1037	840	0,24
I_Sign_Operations:: sign_Document (25 MB)	13	35	7300	0,07
I_Sign_Operations:: verify_Document (100 kB, LE-U2)	297	792	1430	0,31
I_Sign_Operations:: verify_Document (25 MB)	13	35	7900	0,08
I_Crypt_Operations:: encrypt_Document (100 kB, LE-U2)	258	688	1880	0,36
I_Crypt_Operations:: encrypt_Document (25 MB)	13	35	6700	0,07
I_Crypt_Operations:: decrypt_Document (100 kB, LE-U2)	258	688	510	0,10
I_Crypt_Operations:: decrypt_Document (25 MB)	13	35	8900	0,09
Operationen 25 MB Dokument	52	140	7700	0,30	74%	22%	3%	0%	0%
Operation 100 kB Dokument	1202	3205	1165	1,04	35%	37%	19%	7%	2%

In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen. In Situation 1 bearbeitet der Konnektor weder Operationen mit 25 MB-Dokumenten noch solche mit 100kB-Dokumenten. In den Situationen 2 und 5 bearbeitet der Konnektor genau jeweils ein Dokument. In den übrigen Situationen liegt parallele Verarbeitung vor.

Tabelle 69: Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen

Lastsituationen i
i	Parallele Bearbeitungen mit 25 MB Dokumenten [Anzahl]	Parallele Bearbeitungen mit 100 kB Dokumenten [Anzahl]	Wahrscheinlichkeit pi
1	0	0	26%
2	0	1	27%
3	0	2	14%
4	0	3	5%
5	1	0	8%
6	1	1	8%
7	1	2	4%
8	1	3	1%

Für jede der Lastsituationen i in Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 8 sind es beispielsweise 1 Thread, der 25 MB große Dokumente bearbeitet, und 3 Threads, die 100 kB große Dokumente bearbeiten.

Für jede der Lastsituationen i und der Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25MB-Dokumente und 100kB-Dokumente zu bestimmen.

Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen ist:

 

wird für 100 kB Dokumente wie folgt gemittelt:

 

wird für 25 MB Dokumente wie folgt gemittelt:

 

HighSpeed-Konnektor

Tabelle 70: Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen

					Wahrscheinlichkeit für n parallele Aufrufe zu einem Zeitpunkt
	Last [1/h]	Last *8/3 [1/h]	Mittlere Bearb.z. [ms]	Last * Mittlere Bearb.z. [Anzahl]	0	1	2	3	4	5	6	7
I_Sign_Operations:: sign_Document (100 kB, LE-U4)	1459	3891	840	0,91
I_Sign_Operations:: sign_Document (25 MB)	13	35	7300	0,07
I_Sign_Operations:: verify_Document (100 kB, LE-U4)	857	2285	1430	0,91
I_Sign_Operations:: verify_Document (25 MB)	13	35	7900	0,08
I_Crypt_Operations:: encrypt_Document (100 kB, LE-U4)	575	1533	1880	0,80
I_Crypt_Operations:: encrypt_Document (25 MB)	13	35	6700	0,06
I_Crypt_Operations:: decrypt_Document (100 kB, LE-U4)	575	1533	510	0,22
I_Crypt_Operations:: decrypt_Document (25 MB)	13	35	8900	0,09
Operationen mit 25 MB Dokument	52	139	7700	0,30	74%	22%	3%	0%	0%	0%	0%	0%
Operationen mit 100 kB Dokument	3466	9243	1165	2,99	5%	15%	22%	22%	17%	10%	5%	2%

In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen.

Tabelle 71: Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen

Situationen i
i	Parallele Bearbeitungen mit 25 MB Dokumenten [Anzahl]	Parallele Bearbeitungen mit 100 kB Dokumenten [Anzahl]	Wahrscheinlichkeit pi
1	0	0	4%
2	0	1	11%
3	0	2	17%
4	0	3	17%
5	0	4	12%
6	0	5	7%
7	0	6	4%
8	0	7	2%
9	1	0	1%
10	1	1	3%
11	1	2	5%
12	1	3	5%
13	1	4	4%
14	1	5	2%
15	1	6	1%
16	2	3	3%

Für jede der Lastsituationen i in Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100 mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 16 sind es beispielsweise 2 Threads, die 25 MB große Dokumente bearbeiten, und 3 Threads, die 100 kB große Dokumente bearbeiten.

Für jede der Lastsituationen i und die Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25 MB-Dokumente und 100 kB-Dokumente zu bestimmen.

Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen ist:

 

wird für 100 kB Dokumente wie folgt gemittelt:

 

wird für 25 MB Dokumente wie folgt gemittelt:

 

Rahmenbedingungen

Folgende konkretisierende Rahmenbedingungen gelten für Einbox-Konnektoren und HighSpeed-Konnektoren gleichermaßen:

• Die Messungen werden mit den Referenzdokumenten TIFF_25MB und TEXT_100KB durchgeführt.
• Es wird im Offline Modus (MGM_LU_ONLINE = Disabled) getestet.
• Pro Aufruferthread wird eine Karte und ein Kartenterminal für Signatur und Entschlüsselung eingesetzt.
• Die „Mittlere Bearbeitungszeit Soll“ in Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen basiert auf Kartenterminal- und Kartenzeiten von:
  • Sign_Document:             520 ms
  • Decrypt_Document:     340 ms

Weichen die in den Messungen durchgeführten Rahmenbedingungen hiervon ab, müssen die Werte entsprechend auf diese Rahmenbedingungen korrigiert werden.

• Wenn der Konnektor 1Gbit/s am LAN-Anschluss unterstützt, müssen die Performancevorgaben für Signatur- und Verschlüsselungsdienst in einem LAN nachgewiesen werden, das 1Gbit/s Bandbreite ermöglicht.
• Für die einzelnen Operationen wird konkretisiert:
  • sign_Document: CAdES Signatur (detached) des Gesamtdokuments, nonQES
  • verify_Document: Signatur verifizieren, die in sign_Document erzeugt wurde, IncludeRevocationInfo=false
  • encrypt_Document: TIFF_dokument, CMS-Verschlüsselung, ein Empfänger
  • decrypt_Document: Dokument entschlüsseln, das mit encrypt_Document verschlüsselt wurde.

9 Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors

Entsprechend der Lastvorgaben aus [GS-A_5327] für 8 Anwendungen wird das Messverfahren festgelegt. Auf Grund der unterschiedlichen Lastanforderungen für die beiden Ausprägungsformen „Einbox-Konnektor“ und „HighSpeed-Konnektor“ wird das Verfahren für beide Fälle dargestellt. Für beide Ausprägungsformen werden die Signaturverfahren CAdES, XAdES, PAdES und die Verschlüsselungsverfahren XMLEnc und CMS unterschieden.

Es gelten die Bearbeitungszeitvorgaben aus Tabelle Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben.

Tabelle 72: Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben

	Mittlere Bearbeitungszeit [ms]
	CMS, CAdES	XMLEnc, XAdES	CMS, PAdES
I_Sign_Operations::sign_Document (100 kB)	1100	1100	1100
I_Sign_Operations::sign_Document (25 MB)	7300	10500	7300
I_Sign_Operations::verify_Document (100 kB)	500	500	500
I_Sign_Operations::verify_Document (25 MB)	7900	7900	9500
I_Crypt_Operations::encrypt_Document (100 kB)	780	780	780
I_Crypt_Operations::encrypt_Document (25 MB)	6700	9500	6700
I_Crypt_Operations::decrypt_Document (100 kB)	510	510	510
I_Crypt_Operations::decrypt_Document (25 MB)	8900	8900	8900

Einbox-Konnektor

In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen. In Situation 1 bearbeitet der Konnektor weder Operationen mit 25-MB-Dokumenten noch solche mit 100-kB-Dokumenten. In den Situationen 2 und 5 bearbeitet der Konnektor genau jeweils ein Dokument. In den übrigen Situationen liegt parallele Verarbeitung vor.

Die Situationen sind getrennt für die folgenden drei Verfahrensgruppen zu betrachten:

• Verschlüsselungsverfahren CMS und Signaturverfahren CAdES,
• Verschlüsselungsverfahren XMLEnc und Signaturverfahren XAdES,
• Verschlüsselungsverfahren CMS und Signaturverfahren PAdES.

Tabelle 73: Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen

Situationen i
i	25 MB [Anzahl]	100 kB [Anzahl]	Wahrscheinlichkeiten pi
			CMS, CAdES	XMLEnc, XAdES	CMS, PAdES
1	0	0	39	37	38
2	0	1	25	24	25
3	0	2	8	8	8
4	0	3	2	2	2
5	1	0	12	13	12
6	1	1	7	8	8
7	1	2	2	3	2

Für jede der Lastsituationen i in Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 7 sind es beispielsweise 1 Thread, der 25 MB große Dokumente bearbeitet, und 2 Threads, die 100 kB große Dokumente bearbeiten.

Für jede der Lastsituationen i und der Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25-MB-Dokumente und 100-kB-Dokumente zu bestimmen.

Durch den Test ist pro Verfahrengruppe nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben ist:

 

wird für 100-kB-Dokumente wie folgt gemittelt:

 

wird für 25-MB-Dokumente wie folgt gemittelt:

 

HighSpeed-Konnektor

In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen.

Tabelle 74: Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen

Situationen i
i	25 MB [Anzahl]	100 kB [Anzahl]	Wahrscheinlichkeiten pi
			CMS, CAdES	XMLEnc, XAdES	CMS, PAdES
1	0	0	12	11	14
2	0	1	22	21	23
3	0	2	20	20	19
4	0	3	12	12	11
5	0	4	6	6	5
6	0	5	2	2	2
7	1	0	3	4	4
8	1	1	6	7	7
9	1	2	6	6	6
10	1	3	4	4	3
11	1	4	2	2	1
12	2	2	3	4	4

Für jede der Lastsituationen i in Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100 mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 12 sind es beispielsweise 2 Threads, die 25 MB große Dokumente bearbeiten, und 2 Threads, die 100 kB große Dokumente bearbeiten.

Für jede der Lastsituationen i und die Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25 MB-Dokumente und 100 kB-Dokumente zu bestimmen.

Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben ist:

 

wird für 100 kB Dokumente wie folgt gemittelt:

 

wird für 25 MB Dokumente wie folgt gemittelt:

 

Rahmenbedingungen

Folgende konkretisierende Rahmenbedingungen gelten für Einbox-Konnektoren und HighSpeed-Konnektoren gleichermaßen zusätzlich zu den generellen Rahmenbedingungen für die Messungen aus Kapitel 4.1.2:

• Die Messungen werden mit den Referenzdokumenten TIFF_25MB und TEXT_100KB durchgeführt.
• Es wird im Offline-Modus (MGM_LU_ONLINE = Disabled) getestet.
• Pro Aufruferthread wird eine Karte und ein Kartenterminal für Signatur und Entschlüsselung eingesetzt.
• Für die einzelnen Operationen wird konkretisiert:
  • sign_Document: nonQES
  • verify_Document: Signatur verifizieren, die in sign_Document erzeugt wurde, IncludeRevocationInfo=false
  • encrypt_Document: ein Empfänger
  • decrypt_Document: Dokument entschlüsseln, das mit encrypt_Document verschlüsselt wurde.