latest
Elektronische Gesundheitskarte und Telematikinfrastruktur
Übergreifende Spezifikation
Performance und Mengengerüst TI-Plattform
| Version | 2.41.0 |
| Revision | 878816 |
| Stand | 28.03.2024 |
| Status | freigegeben |
| Klassifizierung | öffentlich |
| Referenzierung | gemSpec_Perf |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
| Version | Stand | Kap./ Seite | Grund der Änderung, besondere Hinweise | Bearbeitung |
|---|---|---|---|---|
| ... | ||||
| 2.30.0 | 31.07.2023 | Einarbeitung KIM Maintenance 23.2 (KIM 1.5.3), Betr_Maintenance_23.3, E-Rezept_Maintenance_23.2 und TI-Messenger_Maintenance_23.1, Ergänzung der Anteile aus gemF_TI-Gateway |
gematik | |
| 2.30.1 | 04.08.2023 | Anpassung zu Betr_Maintenance_23.3 (Spalte in Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul ergänzt) | gematik | |
| 2.31.0 | 01.09.2023 | Einarbeitung IdP_Maintenance 23.4 | gematik | |
| 2.32.0 | 19.09.2023 | Einarbeitung Änderungsliste NCPeH_23.1 | gematik | |
| 2.33.0 | 29.09.2023 | Einarbeitung Änderungsliste CI_Maintenance_23.2 | gematik | |
| 2.34.0 | 04.12.2023 | Einarbeitung Release KIM 1.5.3 und der Änderungslisten E-Rezept_Maintenance_23.3 und CI_Maintenance_23.4 | gematik | |
| 2.35.0 | 30.01.2024 | Einarbeitung ePA für alle, Wechsel von BDEv01 auf v02 für ePA, Verlagerung der Performance-/Lastvorgaben ePA in separates Unterkapitel 3.18, Entfernen der Anforderungen ePA-Konnektor-Fachmodul | gematik | |
| 2.36.0 | 20.02.2024 | Einarbeitung Betr_Maintenance_23.4 und Änderungsliste CI_Maintenance_24.1 | gematik | |
| 2.37.0 | 23.02.2024 | Einarbeitung TI-Gateway_23.1, HSK_23.6 und IDP_24.4 | gematik | |
| 2.38.0 | 19.03.2024 | Einarbeitung Änderungsliste TI-M_24.1 | gematik | |
| 2.39.0 | 19.03.2024 | Einarbeitung Änderungsliste Smartcards_23.3 | gematik | |
| 2.40.0 | 22.03.2024 | Einarbeitung Änderungsliste VZD_24.1 | gematik | |
| 2.41.0 | 28.03.2024 | Einarbeitung ePA für alle Release 3.0.1 | gematik |
Inhaltsverzeichnis
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. 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.
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. - Ausfallzeitraum - Ein Ausfallzeitraum ist die Zeit zwischen Beginn und Ende einer Nichtverfügbarkeit eines Dienstes. Der Zeitraum ist unabhängig von der Durchführung einer Wartung.
- 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.3.1 Wartungsfenster und Servicezeiten
Dieses Kapitel fasst generelle Festlegungen zur Durchführung von Wartungen, den Geltungsbereich von Servicezeiten und der damit verbundenen Verfügbarkeitsberechnung zusammen. Die verbundenen Begriffe zu Wartung und Wartungsfenster sind weiterführend in [gemRL_Betr_TI#Change & Release Management] definiert.
Gemäß [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] im Rahmen der Spezifikation des Servicemodells stellt eine Servicekomponente die logische Verbindung zwischen Produkttypen und ihrem serviceverantwortlichen Anbieter (Eigener Service) dar. Wartungsfenster und Servicezeiten gelten daher für den Betrieb immer in Kombination von Anbietertyp und Produkttyp.
Folgende Tabelle "Tab_gemSpec_Perf_Servicekomponente->Servicezeit, Wartungsfenster" stellt in einer Übersicht alle Servicekomponenten bzw. Produkttypen und ihre serviceverantwortlichen Anbieter dar, die bereits auf die generischen Festlegungen in diesem Kapitel umgestellt wurden.
Tabelle 1: Tab_gemSpec_Perf_Servicekomponente->Servicezeit, Wartungsfenster
| Servicekomponente | Servicezeit | Wartungsfenster |
|---|---|---|
| KOM-LE | A_23348 - HZ Mo-Fr | A_23347-01 |
| E-Rezept Fachdienst | A_23350 - HZ Mo bis So eingeschränkt | A_23618 |
| TI-Messenger Fachdienst | A_23348 - HZ Mo-Fr | A_23347-01 |
| TI-Gateway | A_23350 - HZ Mo bis So eingeschränkt | A_23347-01 |
| Konfigurationsdienst | A_23350 - HZ Mo bis So eingeschränkt | A_23615 |
| eHealth-CardLink | - | A_23347-01 |
2.3.1.1 Wartungsfenster
A_23347-01 - Performance - Wartungsfenster - Durchführung
Der Anbieter SOLL Wartungsfenster so planen, dass diese vollständig in der Nebenzeit liegen.
Hinweis: Nach voriger Absprache mit und Genehmigung durch den Gesamtverantwortlichen TI ist ein Wartungsfenster in der Hauptzeit möglich.
Ist für einen Anbieter und einem seiner zugeordneten Produkt(e) nur eine Hauptzeit und keine Nebenzeit definiert, dann SOLL der Anbieter ein Wartungsfenster so planen, dass dieses in Zeiten mit wenig Systemlast stattfindet. Das Wartungsfenster muss mit dem Gesamtverantwortlichen TI abgesprochen und durch diesen genehmigt werden. [<=]
2.3.1.2 Servicezeiten
Die Servicezeit ist die Zeitspanne, in der ein zugeordnetes Produkt in entsprechender Ausprägung verpflichtend verfügbar sein soll. Servicezeiten werden überwiegend in Haupt- und Nebenzeiten gegliedert. Für diese Zeiten werden zusätzlich spezielle Kriterien zum Grad der Erfüllung festgelegt, welche produktspezifisch in den dafür vorgesehenen Kapiteln zu finden sind.
A_23348 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Freitag
Der Produkttyp MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr.
- Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.
A_23349 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag
Der Produkttyp MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr
- Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.
A_23350 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt
Der Produkttyp MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
- Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
- Alle übrigen Stunden der Woche sind Nebenzeit.
A_23619-01 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag 24/7
Der Produkttyp MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Sonntag von 0 - 24 Uhr, inklusive bundeseinheitlicher Feiertage
- Es ist keine Nebenzeit definiert.
A_24962 - Performance - Servicezeiten des Anbieters basierend auf Produkttypen
Der Anbieter MUSS gemäß der in [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] aufgeführten Servicekomponenten bzw. der Zuordnung von Produkttypen zu serviceverantwortlichen Anbieter die dem entsprechenden Produkttypen zugeordneten Servicezeiten erfüllen. [<=]
2.3.2 Verfügbarkeitsberechnung
A_23618 - Performance - Wartungsfenster und Ausfall - Verfügbarkeitsberechnung
Der Anbieter MUSS jeden Ausfallzeitraum, ungeachtet von Wartungen, in der Verfügbarkeitsberechnung als Ausfall werten. [<=]
A_23615 - Performance - Wartungsfenster und Ausfall - Ausnahme zur Verfügbarkeitsberechnung bei Wartung
Der Anbieter MUSS den Anteil des Ausfallzeitraumes, der innerhalb eines geplanten Ausfallszeitraumes zu einem genehmigten Wartungsfenster liegt, aus der Verfügbarkeitsberechnung ausschließen.
Hinweis: Fällt der Dienst vor oder nach einem genehmigten Wartungsfensters aus, so ist die Zeit außerhalb des Wartungsfensters als Ausfall in die Verfügbarkeitsberechnung des Dienstes mit einzubeziehen. [<=]
2.3.3 Anschlussoptionen an das zentrale Netz
A_23616 - Performance - Verfügbarkeit - Anschluss an zentrales Netz - Hohe Verfügbarkeit
Die Anschlüsse aller Standorte des Anbieters an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen. [<=]
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-01 - Performance – Performance-Daten erfassen
Die Produkttypen der zentralen Zone der TI-Plattform und die Komponente AdV-Server der KTR-AdV MÜSSEN in einem konfigurierbaren Zeitintervall Performance-Daten erfassen. Voreingestellt für das Zeitintervall sind 5 Minuten.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr].
[<=]
GS-A_4147-02 - Performance – Störungsampel – Performance-Daten
Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN die Performance-Reporting-Daten jeweils im Zeitintervall der Erfassung von Performance-Reporting-Daten an die Störungsampel senden.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr]. [<=]
GS-A_4148-01 - Performance – Störungsampel – Ereignisnachricht bei Ausfall
Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:
- Ein Dienst gilt als ausgefallen, wenn er 20 % oder mehr Anfragen nicht mehr erfolgreich verarbeiten kann.
- „Startzeitpunkt eines Ausfalls“ ist der frühest mögliche Zeitpunkt, zu dem das Erkennen des Ausfalls möglich ist.
- „Endzeitpunkt eines Ausfalls“ ist der frühest mögliche Zeitpunkt, zu dem das Erkennen des Endes eines Ausfalls möglich ist.
- „Versendezeitpunkt“ ist der Zeitpunkt, zu dem das erste Bit der Ereignisnachricht an die Störungsampel abgeschickt wird
[<=]
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.
A_14936 - Performance - Störungsampel - Ereignisnachricht bei Ausfall zentrale Dienste
Die Produkttypen OCSP-Proxy, TSP-X.509 Komp., TSL-Dienst, Namensdienst, Störungsampel, KSR, SG-Bestandsnetze, Zeitdienst, zentrales Netz und Verzeichnisdienst MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:
- Ein Dienst gilt als ausgefallen, wenn er 20 % oder mehr Anfragen nicht mehr anforderungskonform verarbeiten kann oder dieser Dienst für Anwender nicht erreichbar ist.
- „Startzeitpunkt eines Ausfalls“ ist der frühestmögliche Zeitpunkt, zu dem das Erkennen des Ausfalls möglich ist.
- „Endzeitpunkt eines Ausfalls“ ist der frühestmögliche Zeitpunkt, zu dem das Erkennen des Endes eines Ausfalls möglich ist.
- „Versendezeitpunkt“ ist der Zeitpunkt, zu dem das erste Bit der Ereignisnachricht an die Störungsampel abgeschickt wird.
GS-A_4149-01 - Performance – Reporting-Daten in Performance-Report
Die Produkttypen der zentralen Zone der TI-Plattform und die Komponenten AdV-Server der KTR-AdV MÜSSEN die Performance-Reporting-Daten ohne weitere Aggregation in den Performance-Report übernehmen.
Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr]. [<=]
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_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] 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_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] 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
- Bearbeitungszeit des Aufrufes
- aufgerufene Operation
- Erfolg der Operationsbearbeitung
- weitere produkttypspezifische und operationsspezifische Informationen
Aus den Rohdaten lassen sich die Performance-Kenngrößen (z.B. die Abbruchquote als Anteil der nicht erfolgreich verarbeiteten Aufrufe gemessen an der Anzahl der Aufrufe) für den Produkttyp ermitteln und auf deren Basis die Einhaltung der Service Level bestimmen.
Dazu erfassen Produkttypen die Rohdaten und stellen sie der Betriebsdatenerfassung in dem hier festgelegten Performance-Berichtsformat zur Verfügung.
2.5.1 Rohdaten-Performance-Reporting (Rohdatenerfassung v.01)
| Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 1.0 und befindet sich aktuell in der strukturellen Überarbeitung. Inhaltliche Änderung werden sich lediglich in jener Form ergeben, dass die Produkte nach und nach zur Rohdatenerfassung in der Version 2.0 verpflichtet werden. Aktuell bestehende Zulassungen sind davon nicht betroffen. Das Update wird in Kürze eingearbeitet. |
Im Folgenden ist das Berichtsformat in der Version v.01 beschrieben. Produkttypen, welche auf diese Version verpflichtet sind, werden im Laufe der Zeit auf die aktuellste Version angehoben. Neuzulassungen sind auf die Version v.01 nicht mehr möglich.
A_17757-01 - Performance - Rohdaten-Performance-Lieferung - zu liefernde Dateien
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Berichten übermitteln, MÜSSEN jeweils zu jedem separat konfigurierbaren Berichtsintervall zwei Dateien senden:
- einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten [gemSpec_Perf#A_17755, A_17671, A_17668, A_19733-*]
und
- eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].
Beide Dateien MÜSSEN separat an die Betriebsdatenerfassung gemäß gemSpec_SST_LD_BD an die Schnittstelle I_OpsData_Update gesandt werden. [<=]
A_17755 - Performance - Rohdaten-Performance-Berichte - Name der Berichte
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:
<CI-ID>_<Start>_<Ende>_<Version der Datei>_<Dateityp>.<Endung>
- <CI-ID> = Identifiziert die Produktinstanz, siehe Anforderung [A_17764] in [gemRL_Betr_TI#6.1.1].
- <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
(immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC)
- <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
(offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten)
- <Version der Datei> = Im Normalfall "1". Wird jeweils um 1 hochgezählt bei Korrekturlieferung zu einer Datei
- <Dateityp>.<Endung> = "perf.log" / "inf.xml"
- perf.log = Performance Protokoll
- inf.xml = XML-Datei zur Selbstauskunft
A_17671 - Performance - Rohdaten-Performance-Berichte - Format des Performance-Berichts
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN den Bericht aufbereitet als UTF-8-kodierte Textdatei ohne ByteOrderMark übermitteln. Jede der in diesem Kapitel in den jeweiligen Tabellen definierten Operationsaufrufe MUSS in einem Eintrag erfasst werden. Die Einträge MÜSSEN durch Zeilenumbruch (LF = 0x0A) getrennt werden.
[<=]
A_17668-10 - Performance - Rohdaten-Performance-Berichte - Format der Einträge des Rohdaten-Performance-Berichts
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sämtliche Zeilen (Einträge) der Berichte in der folgenden Weise formatieren:
INFO: start[$timestamp] time[$duration_in_ms] tag[$operation] size[$size_in_kb] message[$message],
mit
- $timestamp eine Unixzeit-Zeitstempel in Millisekunden,
- $duration_in_ms die gemessene Bearbeitungszeit einer Operation in Millisekunden,
- $operation die ausgeführte Operation des Produkttyps gemäß Tabellen:
-
- Tab_gemSpec_Perf_Berichtsformat_VSDM
- Tab_gemSpec_Perf_Berichtsformat_SGD
- Wenn die Operation nicht fehlerfrei durchlaufen wurde, wird
$operation = $operation + ".failed" gesetzt - $size_in_kb ist die gemessene, übertragene Datenmenge einer Operation in Kilobyte,
- $message dient der Gruppierung verschiedener Einträge zu einem fachlichen Anwendungsfall durch einen den einzelnen Anwendungsfall identifizierende Zeichenkette, welche selbst die Zeichen "[" und "]" nicht enthält. Wenn ein fachlicher Anwendungsfall durch einen einzelnen Eintrag abgebildet wird, entfällt "message[$message]".
-
- Für die Operationen der Fachdienste VSDM (VSDD, CMS) muss hier die Conversation-ID eingefügt werden.
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]
Hinweis:
Unter einer fehlerhaften Operation wird verstanden, wenn die Operation z.B. selbst fehlerhaft abgebrochen wurde bzw. nicht oder zu spät beantwortet wurde. Eine Antwort auf ein nicht vorhandenes Datum (ICCSN, Seriennummer etc.) ist eine fehlerfreie Operation und nicht mit ".failed" zu kennzeichnen.
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.
[<=]
2.5.2 Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)
| Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 2.0 und befindet sich aktuell in der strukturellen Überarbeitung. Die hier bereits aufgeführten Anforderungen werden dabei nicht verändert, sondern lediglich um Erläuterungen ergänzt. Das Update wird in Kürze eingearbeitet. |
Die Version v.02 der Rohdatenerfassung ersetzt die bisher zulassungsfähige Version v.01 und ist im Folgenden näher definiert. Neuzulassungen oder Änderungszulassungen sind nur auf Basis der Rohdatenerfassung v.02 möglich.
Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02 gibt einen Überblick über die Produkttypen, welche bereits Rohdaten-Performance-Berichte in der Version v.02 übermitteln, bzw. sich aktuell in der Umstellung befinden.
Tabelle 2: Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02
| PDT | Produkttyp |
|---|---|
| PDT01 | OCSP-Responder-Proxy |
| PDT02 | Trust Service Provider X.509 QES |
| PDT03 | Trust Service Provider X.509 nonQES - eGK |
| PDT04 | TSL-Dienst |
| PDT06 | Namensdienst |
| PDT08 | Zentrales Netz der TI |
| PDT09 | VPN-Zugangsdienst |
| PDT10 | Sicherheitsgateway für Bestandsnetze |
| PDT11 | Konfigurationsdienst |
| PDT21 | Intermediär VSDM |
| PDT22 | gematik Root-CA |
| PDT24 | Fachdienst KOM-LE |
| PDT31 | Trust Service Provider CVC |
| PDT36 | Trust Service Provider X.509 nonQES - HBA |
| PDT37 | Trust Service Provider X.509 nonQES – Komponentenzertifikate |
| PDT38 | Trust Service Provider X.509 nonQES – SMC-B |
| PDT43 | ePA-Aktensystem |
| PDT47 | Signaturdienst |
| PDT50 | E-Rezept-Fachdienst |
| PDT52 | Identity Provider Dienst |
| PDT64 | TI-Messenger Fachdienst |
| PDT66 | Verzeichnisdienst FHIR |
| PDT67 | Highspeed Konnektor |
| PDT68 | Sektoraler Identity Provider (V1.0) |
| PDT69 | National Contact Point for eHealth Fachdienst |
| PDT72 | TI-Gateway-Zugangsmodul |
A_22057 - Performance - Rohdaten - Verpflichtung des Anbieters (Rohdatenerfassung v.02)
Der Anbieter von Produkten, deren zugeordnete Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MUSS die Erfassung, Aufbereitung und Übermittlung der Rohdaten bezüglich Umfang, Lieferintervalle und Format gemäß der allgemeinen und spezifischen Anforderungen (Rohdatenerfassung v.02) gewährleisten. [<=]
A_22482 - Performance - Rohdaten - Erfassung von Rohdaten (Rohdatenerfassung v.02)
Der Produkttyp MUSS Performance-Rohdaten gemäß der Vorgaben zum Rohdaten-Performance-Reporting v.02 erfassen. [<=]
2.5.2.1 Umfang
A_22002 - Performance - Rohdaten - Übermittlung (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zur Übertragung der Berichte die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.
Die Übermittlung des Rohdaten-Performance-Berichts MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen. [<=]
(Hinweis: Für weitere Informationen zum CI, siehe [gemRL_Betr_TI] Kapitel "Configuration Management".)
A_22000 - Performance - Rohdaten - zu liefernde Dateien (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN folgende zwei Dateien in den jeweils individuell konfigurierbaren Berichtsintervallen senden:
- einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten
und
- eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].
Dabei MÜSSEN beide Dateien separat an die Betriebsdatenerfassung gesendet werden. [<=]
A_22429 - Performance - Rohdaten - Inhalt der Selbstauskunft (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, müssen bei der Erstellung der Selbstauskunft folgende inhaltliche Vorgaben berücksichtigen:
- "Produkttypbezeichnung" gem. gemKPT_Betr::Tab_gemKPT_Betr_Produkttypen::Spalte ID (PDT...) --> "ProductType"
- "kompatibilitätsrelevante Produkttypversion“ gem. gemSpec_OM „ProductTypeVersion“
- "Hersteller-/Anbieter-ID“ (5 Zeichen-Kürzel von gematik Zulassung) gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductVendorID“
- "Produktkürzel“ (8 Zeichen-Kürzel nach Herstellerfestlegung) gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductCode“
- "Produktversion" gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> "ProductVersion"
- "Herstellername /Anbietername" gem. gemSpec_OM::Tab_ZusAttr --> "ProductVendorName"
- "Produktname" gem. gemSpec_OM::Tab_ZusAttr --> "ProductName"
A_22004 - Performance - Rohdaten - Korrektheit (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Berichte vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden. [<=]
"Intervalltreu" bedeutet hierbei: Jeder Eintrag muss in dem Rohdaten-Performance-Bericht gesendet werden, in dessen Berichtsintervall sein Endezeitpunkt $timestamp + $duration_in_ms liegt.
A_22005 - Performance - Rohdaten - Frist für Nachlieferung (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei(en) in der geforderten Qualität bis zum Ende des folgenden Werktages (Mo-Fr ausgenommen bundeseinheitliche Feiertage) nachliefern. [<=]
Die Nachlieferung hat dabei in der gleichen Art wie die Originallieferung zu erfolgen (keine Zusammenfassung mehrerer Rohdaten-Nachlieferungen). Bei mehreren Nachlieferungen sind die Einzellieferungen separat und zeitlich gestaffelt zwischen den Standardlieferungen zu tätigen (z.B. bei einem 5-Minuten-Intervall nach 2,5 Minuten EINE Nachlieferung und nach 5 Minuten dann die Standardlieferung).
A_22003-01 - Performance - Rohdaten - Nachlieferung auf Anforderung (Rohdatenerfassung v.02)
Anbieter, deren Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN auf Anforderung des Gesamtverantwortlichen TI eine erneute Lieferung/Nachlieferung der Rohdaten-Berichte bis zum 5. Werktag (Mo-Fr, ausgenommen bundeseinheitliche Feiertage) des auf dem Berichtszeitraum folgenden Monats ermöglichen. [<=]
Die vorgeschriebenen Aufbewahrungspflichten bleiben hiervon unberührt. Umfang und Details zur Nachlieferung bzgl. Nachlieferungszeitpunkt und Zusammenfassung sind mit dem Gesamtverantwortlichen TI abzustimmen.
A_22996 - Performance - Rohdaten - Zeitpunkte der Übermittlungen (Rohdatenerfassung v.02)
Der Anbieter, der zur Rohdatenlieferung verpflichtet ist, MUSS jede Lieferung der Rohdaten unverzüglich - spätestens innerhalb der 10 auf das Berichtsintervall folgenden Minuten - beginnen.
[<=]
2.5.2.2 Lieferintervalle
A_21976 - Performance - Rohdaten - Konfigurierbarkeit der Lieferintervalle (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferintervalle der Berichtsdateien flexibel zwischen 1 Minute und 24 Stunden (1440 Minuten) mit einer Taktung von 1 Minute konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]
A_22047 - Performance - Rohdaten - Änderung der Konfiguration der Lieferintervalle (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine Anpassung der Lieferintervalle der Berichtsdateien auf Aufforderung des Gesamtverantwortlichen TI ermöglichen. [<=]
Die Anpassung der Lieferintervalle ist im Rahmen des TI-ITSM durch das Changemanagement zu prozessieren.
A_22620 - Performance - Rohdaten - Umsetzungszeit für Änderung der Lieferintervalle (Rohdatenlieferung v.02)
Der Anbieter, dessen Produkt zur Umsetzung der Rohdatenerfassung v.02 verpflichtet ist, MUSS die Änderung der Konfiguration der Lieferintervalle (gemäß A_22047) innerhalb von 5 Werktagen (Mo - Fr, ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]
A_21978 - Performance - Rohdaten - Trennung der Lieferintervalle (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine voneinander getrennte Anpassung der Lieferintervalle für die Lieferungen von Rohdaten-Performance-Berichten, Selbstauskünften und ggf. weiteren Lieferungen (z.B. Bestandsdatenlieferung) ermöglichen. [<=]
A_21975 - Performance - Rohdaten - Default-Werte für Lieferintervalle (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN - sofern nicht explizit spezifiziert - folgende Lieferintervalle als Standardeinstellung voreinstellen:
- Rohdaten-Performance-Berichte: 5-minütig.
- Selbstauskunft: 60-minütig.
A_21979 - Performance - Rohdaten - Bezug der Lieferverpflichtung (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sich bei der Lieferung der Berichtsdateien ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]
A_21980 - Performance - Rohdaten - Leerlieferung (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferung der Berichtsdateien gemäß des konfigurierten Lieferintervalls leisten, auch wenn im dazugehörigen Berichtsintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist der Rohdaten-Performance-Bericht mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. Für die Selbstauskunft ergibt sich daraus keine Besonderheit, sodass diese wie definiert zu übertragen ist. [<=]
2.5.2.3 Format
A_22001-01 - Performance - Rohdaten - Name der Berichte (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:
<CI-ID>_<Start>_<Ende>_<Dateityp>.<Endung>
- <CI-ID> = identifiziert die Produktinstanz, siehe Anforderung [A_17764] in [gemRL_Betr_TI#6.1.1].
- <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
(immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC). - <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
(offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten). - <Dateityp>.<Endung> = "perf.log" / "inf.xml"
-
- perf.log = Performance Protokoll
- inf.xml = XML-Datei zur Selbstauskunft.
- perf.log = Performance Protokoll
A_21981-02 - Performance - Rohdaten - Format des Rohdaten-Performance-Berichtes (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung folgende Konventionen erfüllen:
Diese Produkttypen:
- MÜSSEN ein CSV-Format mit den Feldern
-
timestamp = unix-Epoch Zeitstempel in Millisekunden (Integer),
- duration_in_ms = Dauer der Ausführung gemäß produkttypspezifischer Definition in Millisekunden (Integer),
- operation = Operationsbezeichnung gemäß produkttypspezifischer Definition (String),
- status = max. 5-stelliger Statuscode gemäß A_22500 (String),
- message = JSON-formatierter String gemäß produkttypspezifischer Definition (String)
- MÜSSEN das Semikolon ";" als Feldtrennzeichen verwenden.
- DÜRFEN das Feldtrennzeichen innerhalb der CSV-Felder NICHT inhaltlich verwenden.
- DÜRFEN Feldinhalte NICHT quotieren.
- DÜRFEN Feldinhalte weggelassen, sofern diese Produkttyp- oder operationsbedingt entfallen können, was ggf. zu direkt aufeinanderfolgenden Semikola führt.
- MÜSSEN UTF-8 Zeichensatzkodierung ohne ByteOrderMark verwenden.
- MÜSSEN CR-LF-Zeilenumbrüche (ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed)) verwenden.
- DÜRFEN Kommentierungen NICHT verwenden.
- DÜRFEN leeren Zeilen NICHT verwenden.
- DÜRFEN Tausendertrennzeichen NICHT verwenden.
- DÜRFEN einen CSV-Header NICHT verwenden.
- MÜSSEN Leerzeichen am Rand der Feldinhalte entfernen, sofern diese nicht intendiert sind, da sie nicht automatisch ignoriert werden.
A_22500-01 - Performance - Rohdaten - Status-Block (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard-Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.
Tabelle 3: Tab_gemSpec_Perf_Standard-Statuscodes
| HTTP-Statuscodes |
Name der Statuscodegruppe | Beschreibung |
|---|---|---|
| 1xx | INFORMATIONAL | Der Server hat die Anfrage erhalten und befindet sich in der Bearbeitung. |
| 2xx |
SUCCESSFUL |
Die Operation wurde erfolgreich durchgeführt. |
| 3xx | REDIRECTION | Der Client muss zusätzliche Maßnahmen ergreifen, um die Anfrage abzuschließen. |
| 4xx |
CLIENT_ERROR |
Ein Client-seitiger Fehler verhindert die erfolgreiche Durchführung der Operation. |
| 5xx |
SERVER_ERROR |
Ein Server-seitiger Fehler verhindert die erfolgreiche Durchführung der Operation. |
Hinweis: Es sind die konkreten HTTP-Statuscodes zu verwenden und die "xx" entsprechend zu ersetzen.
A_21982-01 - Performance - Rohdaten - Message-Block (Rohdatenerfassung v.02)
Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]
A_22513-01 - Performance - Rohdaten - Message-Block im Fehlerfall (Rohdatenerfassung v.02)
Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln, wenn - im Fehlerfall oder aus einem anderen Grund - die für die Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) notwendigen Informationen nicht vorliegen.
(anstelle von key ist der entsprechende Key-Wert des Key-Value-Paares einzutragen; << und >> dienen nur der Abgrenzung)
[<=]
Zwei beispielhafte Einträge eines Beispielproduktes und einer dazugehörigen Beispieloperation:
I: 1000212390109;447;Beispielprodukt.Beispieloperation;200;{"ID":12}
II: 1000212470109;12;Beispielprodukt.Beispieloperation;40001;{"ID":12,"Antwort":"gesperrt"}
2.6 Ereignisdaten
Die Ereignisdaten eines Produkttypen erfassen den Zustand von Anwendungsfällen und stellen diese der Ereignisdatenschnittstelle in dem hier definierten Format zur Verfügung.
Tabelle 4: Tab_gemSpec_Perf_Produkte_Ereignisdaten
| PDT | Produkttyp |
|---|---|
| PDT77 | eHealth-CardLink |
A_25259 - Ereignisdaten - Lieferung mittels TLS
Der Anbieter MUSS die Lieferungen von Sensordaten TLS-verschlüsselt nach GS-A_4384-03 durchführen. [<=]
A_25278 - Ereignisdaten - Authentifizierung via OAuth 2.0
Der Anbieter MUSS einen "OAuth 2.0 client credentials grant flow" in Abstimmung mit der gematik implementieren.
[<=]
A_25260 - Ereignisdaten - Lieferung mittels OAuth 2.0
Der Anbieter MUSS bei der Lieferung von Sensordaten das angebotene Zugangsverfahren zum Sensorik-Endpunkt auf Basis von OAuth 2.0 [RFC6749] umsetzen. [<=]
2.6.1 Lieferintervall
A_25261 - Ereignisdaten - Zeitpunkt der Lieferung
Der Anbieter MUSS nach der vollständigen Verarbeitung spezifizierter Ereignisse, die erforderlichen Daten unmittelbar an den Sensorik-Endpunkt versenden. [<=]
A_25262 - Ereignisdaten - Verhalten bei fehlgeschlagener Lieferung und Retry
Der Anbieter MUSS bei einer fehlgeschlagenen Ereignislieferung an den Sensorik-Endpunkt einen Retry-Mechanismus (z.B. Exponential Backoff) implementieren, um die Ereignislieferung nachzuholen.
Diese Nachlieferung wird nur bei folgenden Return-Codes des Sensorik-Endpunktes notwendig:
| HTTP Error-Code | Nachlieferung notwendig |
|---|---|
| 400 | Nein |
| 401 | Nein |
| 403 | Nein |
| 404 | Nein |
| 406 | Nein |
| 411 | Nein |
| 413 | Nein |
| 429 | Nein |
| 500 | Nein |
| 502 | Ja |
[<=]
2.6.2 Format
A_25263 - Ereignisdaten - Format der Lieferung
Der Anbieter MUSS bei der Ereignislieferung folgende Konventionen vollständig erfüllen:
- HTTP-Aufruf konform mit [RFC7231]
- Content-Encoding: erfolgt produktspezifisch
- Content-Type: application/json
- Ausschließliche Nutzung von POST-Requests
- Spezieller POST-Body nach spezifiziertem Schema
- die URL "https://<host>:<port><path>/" im POST Request wird von der gematik vorgegeben.
- keep-alive: max. 600 Sekunden
- Request Timeout: max. 120 Sekunden
A_25264 - Ereignisdaten - Format der Lieferung - POST-Body - Integervalidierung
Der Anbieter MUSS bei der Ereignislieferung im POST-Body gewährleisten, dass alle als Integer gekennzeichneten Werte als ganzzahlige Integer im POST-Body zu berücksichtigen sind und diese DÜRFEN NICHT als String übertragen werden.
Hinweis: Die Quotierung von Integerwerten z.B. 1234 und die damit einhergehende Typänderung zu String "12345" ist unzulässig.
[<=]
3 Produkttypspezifische Vorgaben
Die produkttypspezifischen Vorgaben dieses Kapitels ergänzen die allgemeinen Anforderungen der Rohdatenerfassung für jeden Produkttypen zusammengefasst und übersichtlich.
| Anmerkung: Das Kapitel befindet sich derzeit im Aufbau und wird im Laufe der Zeit die Festlegungen der Folgekapitel 4 und 5 zusammenfassen. Dies geschieht stets produkttypbezogen, sodass es in der Übergangszeit Produkttypen geben kann, welche bereits in die neue produkttyporientierte Dokumentenstruktur überführt wurden, während sich andere noch in der thematisch-fokussierten Dokumentenstruktur wiederfinden. |
3.1 IDP-Dienste
3.1.1 Leistungsanforderungen IDP-Dienste
3.1.1.1 Lastmodell IDP-Dienste
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
[Weiteres im Folgekapitel "Performancevorgaben IDP-Dienste" enthalten]
3.1.1.2 Bearbeitungszeiten IDP-Dienste
Für die Tokenbasierte Authentisierung müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall" angegebenen Mittelwertschranken sein.
Tabelle 5: Tab_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 |
A_22532 - Überlastabwehr des Produktes
Der Produkttyp KANN bei einer erhöhten Anfragelast von mehr als 20 Authorization-Requests innerhalb von 5 Minuten pro "client_id" und anfragender IP-Adresse weitere Anfragen dieser Quelle mit dem HTTP-Statuscode "429 - Too Many Requests" ablehnen. [<=]
3.1.1.3 Performancevorgaben IDP-Dienste
A_22227-02 - Performance – IDP-Dienst – Bearbeitungszeit unter Last
Der Produkttyp IDP-Dienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_IDP-Dienst erfüllen.
Es wird davon ausgegangen, dass der IDP-Dienst eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator (Challenge) bis zum Eintreffen der Antwort (Response) nicht zur Bearbeitungszeit. Die Dauer für die OCSP-Anfrage ist jedoch berücksichtigt.
Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.
Tabelle 6: Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben
|
ID
|
Anwendungsfälle
|
Lastvorgaben
|
Bearbeitungszeitvorgaben
|
|
|
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
||
| IDP.UC_1 IDP.UC_3 IDP.UC_11 IDP.UC_13 |
Authorization Requests |
450 |
500 |
664 |
| IDP.UC_5 IDP.UC_6 IDP.UC_7 IDP.UC_8 IDP.UC_9 IDP.UC_10 IDP.UC_12 IDP.UC_14 |
Processing of Client-Response |
450 |
1750 |
2250 |
| IDP.UC_2 IDP.UC_4 |
Token Requests | 450 | 500 | 664 |
A_22226 - Performance – Sektoraler Identity Provider – Bearbeitungszeit unter Last
Der Anbieter eines sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Sek_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß [A_22225].
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.
Tabelle 7: Tab_gemSpec_Perf_sek_IDP: Bearbeitungszeitvorgaben
|
ID
|
Anwendungsfälle
|
Lastvorgaben
|
Bearbeitungszeitvorgaben
|
|
|
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
||
| IDP.UC_20 |
Processing of Authorization Request (third-party-based authentication) | 10 + (450 x MA) |
1500 |
1964 |
| IDP.UC_21 |
Token Request (third-party-based authentication) | 10 + (450 x MA) |
500 |
664 |
Hinweis:
Die Duration für IDP.UC_20 beginnt mit der Annahme des Authorization Request am Authorization-Endpunkt und endet mit der Herausgabe des Authorization_Code.
Die Duration für IDP.UC_21 beginnt mit der Annahme des Token Request am Token-Endpunkt und endet mit der Herausgabe des Token.
A_22833 - Performance – Sektoraler Identity Provider in der Föderation – Bearbeitungszeiten unter Last
Der Anbieter des sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_sektoraler_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß [A_22225].
Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.
Tabelle 8: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben
| ID |
Anwendungsfälle | Lastvorgaben |
Bearbeitungszeitvorgaben |
| Spitzenlast [1/sec] |
Maximalwert [msec] |
||
| IDP.UC_30 | Processing of Pushed Authorization Requests | 10 + (450 x MA) | 800 |
| IDP.UC_31 |
Processing of Authorization Requests (alle Authentisierungsverfahren) |
10 + (450 x MA) | 2000 |
| IDP.UC_32, IDP.UC_33 IDP.UC_34 |
Response of Authorization Requests (mit online Ausweisfunktion) Response of Authorization Requests (mit eGK und PIN) Response of Authorization Requests (alternatives Authentisierungsverfahren) |
10 + (450 x MA) | 100 |
| IDP.UC_39 | Token Requests | 10 + (450 x MA) | 800 |
[<=]
A_20243 - Performance - IdP-Dienst - Robustheit gegenüber Lastspitzen
Der IdP-Dienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_IdP-Dienst: Bearbeitungszeitvorgaben" verfügbar bleiben. [<=]
Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Dienst 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 Betreiber des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.
A_20153 - Performance - IdP-Dienst - Anzahl paralleler Sessions - TI
Der Produkttyp IdP-Dienst MUSS mindestens 95.000 gleichzeitige Sessions für Leistungserbringer unterstützen.
[<=]
A_20154 - Performance - IdP-Dienst - Anzahl paralleler Sessions - Internet
Der Produkttyp IdP-Dienst MUSS mindestens 2.400.000 gleichzeitige Sessions für Versicherte unterstützen.
[<=]
A_22225 - Definition Marktanteil (MA) des Anbieters einer Anwendung oder eines Dienstes
Der Anbieter MUSS entsprechend seines Marktanteils (MA) Performancevorgaben und Service Level erfüllen. Der Marktanteil ist der numerische Wert zwischen 1,00 und 0,01 [ohne Einheit, zwei Nachkommastellen, aufgerundet], der den Anteil der eigenen Kunden des Anbieters im Verhältnis zur Gesamtnutzerzahl repräsentiert. Die Gesamtnutzerzahl ist die Zahl aller Versicherten (privat + gesetzlich) oder die Anzahl aller Leistungserbringer und Leistungserbringerinstitutionen, die diese Anwendung nutzen. [<=]
Hinweis: Die potentiellen Gesamtnutzerzahlen je Sektor können bei den Standesorganisationen oder der gematik erfragt werden.
A_22228 - Performance - Sektoraler Identity Provider - Anzahl paralleler Sessions - Internet
Der Anbieter eines sektoralen Identity Provider MUSS mindestens 25.000 x MA gleichzeitige Sessions für Versicherte unterstützen. MA ist der Marktanteil des Anbieters gemäß [A_22225].
[<=]
A_20244 - Performance - IdP-Dienst - Skalierung
Der Betreiber des IdP-Dienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
[<=]
Im Zuge des Zulassungsverfahrens hat der Betreiber des IdP-Dienst 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_19730-01 - Georedundanz des IdP-Dienstes
Der Anbieter des IdP-Dienstes MUSS diesen Dienst an mindestens zwei Standorten, die mindestens 50km jeweils voneinander entfernt sind, betreiben. Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
[<=]
A_19718-01 - Performance – IdP-Dienst – Verfügbarkeit
Der Produkttyp IdP-Dienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,99 % und zur Nebenzeit eine Verfügbarkeit von 99,97 % haben.
Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]
A_22357-03 - Verfügbarkeit sektoraler IDP
Der Anbieter des sektoralen IDP MUSS sein Produkttyp so betreiben, dass es zur Hauptzeit mindestens eine Verfügbarkeit von 99,90 % und zur Nebenzeit eine Verfügbarkeit von 99,00 % hat.
Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit. [<=]
3.1.2 Rohdaten-Performance-Reporting Spezifika IDP-Dienste
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.1.2.1 Spezifika Umfang IDP-Dienste
A_22048-01 - Performance - Rohdaten - Übermittlung bei dislozierten CIs (Rohdatenerfassung v.02)
Der Anbieter KANN die Übermittlung der Rohdaten-Performance-Berichte in Absprache mit dem Gesamtverantwortlichen TI je Standort vollziehen, wobei diese Standorte dann eindeutig identifizierbar sein müssen, sofern das Configuration Item (CI) über mehrere Standorte verteilt ist. [<=]
3.1.2.2 Spezifika Format IDP-Dienste
A_22013-04 - Performance - Rohdaten - Spezifika IDP-Dienst - Operation/Duration (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "operation" und "duration_in_ms" die Angabe aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Produkttyp: IDP-Dienst
Tabelle 9: Tab_gemSpec_Perf_Berichtsformat_IDP
| $IDP-Operation |
Operation | Endpunkt | Anwendungsfälle | $Duration |
|---|---|---|---|---|
| IDP.UC_1 |
Processing of Authorization Requests |
GET/ auth |
Authorization Requests (TI) | Die Duration beginnt mit der Annahme des Authorization Request und endet mit der Übermittlung der signierten Challenge zum Authenticator. |
| IDP.UC_2 | Token Requests | POST/ Token |
Token Request (TI) | Die Duration beginnt mit der Annahme des Token Request und endet mit der Auslieferung der Token. |
| IDP.UC_3 | Processing of Authorization Requests | GET/ auth |
Authorization Requests (Internet) | Die Duration beginnt mit der Annahme des Authorization Request und endet mit der Übermittlung der signierten Challenge zum Authenticator. |
| IDP.UC_4 | Token Request | POST/ Token |
Token Request (Internet) | Die Duration beginnt mit der Annahme des Token Request und endet mit der Auslieferung der Token. |
| IDP.UC_5 |
Processing of Client-Response (pairing-based authentication) |
POST/ auth |
Processing of Client-Response (TI) | Die Duration beginnt mit der Annahme der signierten Authentication_Data-Struktur am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_6* |
Processing of Client-Response (SSO_TOKEN) |
POST/ auth/ sso_response |
Processing of Client-Response (TI) | Die Duration beginnt mit der Annahme des SSO_TOKEN am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_7* |
Processing of Client-Response (Card-based authentication) |
POST/ alternative |
Processing of Client-Response (TI) | Die Duration beginnt mit der Annahme der signierten Authentication_Data-Struktur am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_8 |
Processing of Client-Response (pairing-based authentication) |
POST/ auth |
Processing of Client-Response (Internet) | Die Duration beginnt mit der Annahme der signierten Authentication_Data-Struktur am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_9 |
Processing of Client-Response (SSO_TOKEN) |
POST/ auth/ sso_response |
Processing of Client-Response (Internet) | Die Duration beginnt mit der Annahme des SSO_TOKEN am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_10 |
Processing of Client-Response (Card-based authentication) |
POST/ alternative |
Processing of Client-Response (Internet) | Die Duration beginnt mit der Annahme der signierten Authentication_Data-Struktur am Authorization-Endpunkt und endet mit der Rückgabe des produzierten Authorization_Code und SSO_TOKEN an das Authenticator-Modul. |
| IDP.UC_11 | Processing of Authorization Requests (third-party-based) | GET/ extauth |
Authorization Requests (Internet) | Die Duration beginnt mit der Annahme des Authorization Request des Client und endet mit der Übermittlung des eigenen Authorization Request zum Authenticator Modul des sektoralen IDP |
| IDP.UC_12 | Processing of Client-Response (third-party-based) | POST/ extauth |
Processing of Client-Response (Internet) | Die Duration beginnt mit der Annahme des Authorization Code und endet mit der Auslieferung des Authorization Response (Authorization Code, SSO Token). |
| IDP.UC_13 | Processing of Authorization Requests (third-party-based, IDP 2.0) | GET/ fedauth |
Authorization Requests (Internet) | Die Duration beginnt mit der Annahme des Authorization Request des Client und endet mit der Übermittlung des eigenen Authorization Request zum Authenticator Modul des sektoralen IDP. Die Zeiten der direkten Kommunikation mit dem sekt. IDP mittels Pushed Authorization Request sind hierbei enthalten. |
| IDP.UC_14 | Processing of Client-Response (third-party-based, IDP 2.0) | POST/ fedauth |
Processing of Client-Response (Internet) | Die Duration beginnt mit der Annahme des Authorization Code und endet mit der Auslieferung des Authorization Response (Authorization Code). |
Anmerkungen:
* Diese Use Cases wurden im Sinne der Vollständigkeit definiert. In der Praxis wird aber weder der SSO Flow noch die alternative Authentisierung in der TI genutzt.
[<=]
A_22944 - Performance - Rohdaten - Spezifika föderierter IDP - Message (Rohdatenerfassung v.02)
Der Produkttyp MUSS - bei Rohdaten-Performance-Berichten folgende Parameter im JSON-Format übermitteln:
{"cv": "$client_version"}
Für "$client_version" ist die Produktversion zum korrespondierenden Authenticator-Modul zu verwenden.
- <Produktversion> im Format "H.N.U-P": Hauptnummer, Nebennummer, Unternummer, Patchlevel (jeweils Integer)
A_22015-01 - Performance - Rohdaten - Spezifika IDP - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation/des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp IDP-Dienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
Tabelle 10: Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 79001 |
OCSP_ERROR_NO_RESPONSE |
Keine Antwort des OCSP oder Timeout |
| 79879 |
OCSP_ERROR_WRONG_SIGNATURE |
Falsche oder fehlende Signatur in der OCSP-Antwort |
| 79875 |
OCSP_ERROR_WRONG_DATA |
Format der OCSP-Anfrage fehlerhaft |
| 79881 |
OCSP_ERROR_INVALID_RESPONSE |
Antwort des OCSP fehlerhaft |
| 79873 |
OCSP_CERT_MISSING |
OCSP-Zertifikat nicht in TSL enthalten |
| 79101 | SEK_IDP_ERROR_NO_RESPONSE | Keine Antwort des sektoralen IDP oder Timeout |
| 79102 | SEK_IDP_ERROR_INVALID_RESPONSE | Antwort des sektoralen IDP fehlerhaft |
| 79105 | SEK_IDP_ERROR_NOT_ALLOWED_USER | Useragent/Version/ClientID nicht erlaubt |
| 79000 |
IDP_ERROR |
alle internen Fehler des IDP |
A_22826 - Performance - Rohdaten - Spezifika sektoraler IDP - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation/des Use Case ein Fehler aufgetreten ist, MUSS der Produkttyp sektoraler IDP bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_sektoraler_IdP festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
Tabelle 11: Tab_gemSpec_Perf_Fehlercodes_sektoraler_IDP
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 79000 |
IDP_ERROR |
alle internen Fehler des sektoralen IDP |
| 79105 | SEK_IDP_ERROR_NOT_ALLOWED_USER | Useragent/Version/ClientID-Kombination nicht erlaubt |
| 79106 | SEK_IDP_AS_nPA_TIME_OUT | Abbruch der Anfrage nach time-out (online Ausweisfunktion) |
| 79107 | SEK_IDP_AS_nPA_USER_FAILURE | Alle Fehler der third party online Ausweisfunktion |
| 79108 | SEK_IDP_AS_eGK_TIME_OUT | Abbruch der Anfrage nach time-out (eGK) |
| 79109 | SEK_IDP_AS_eGK_USER_FAILURE | Alle Fehler der third party eGK |
| 79110 | SEK_IDP_AS_native_TIME_OUT | Abbruch der Anfrage nach time-out |
| 79111 | SEK_IDP_AS_native_USER_FAILURE | Alle Fehler der third party |
A_22825-01 - Performance - Rohdaten - Spezifika sektoraler IDP - Operation/Duration (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "operation" und "duration_in_ms" die Angaben aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Produkttyp: sektoraler Identity Provider
Schnittstelle: Internet
Tabelle 12: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP
| $IDP-Operation |
Operation | $Duration |
|---|---|---|
| IDP.UC_30 |
Processing of Pushed Authorization Requests |
Die Duration beginnt mit der Annahme des Pushed Authorization Request (PAR) vom Authorization-Server des Fachdienstes und endet mit der Übermittlung der "URI-PAR" zum Authorization-Server des Fachdienstes. Zeiten zwischen der optionalen Anfrage "Get Entity Statement RP" des sektoralen IDP an den Fachdienst und der Antwort "Entity Statement" sowie der optionalen Anfrage "Fetch Entity Statement RP" des sektoralen IDP an den Federation Master und Antwort "Entity Statement" sind in der Berechnung für den IDP.UC_30 herauszurechnen. |
| IDP.UC_31 | Processing of Authorization Requests (alle Authentisierungsverfahren) | Die Duration beginnt mit der Annahme des Authorization-Request (URI-PAR) und enden mit dem Absenden der Anfrage zur Authentifizierung. |
| IDP.UC_32 | Response of Authorization Requests (mit online Ausweisfunktion) | Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826). |
| IDP.UC_33 | Response of Authorization Requests (mit eGK und PIN) | Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826). |
| IDP.UC_34 | Response of Authorization Requests (alternatives Authentisierungsverfahren) | Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826). |
| IDP.UC_39 | Token Requests | Die Duration für IDP.UC_39 beginnt mit der Annahme des AUTH_CODE vom Authorization-Server des Fachdienstes und endet mit der Übermittlung des ID_TOKEN (ACCESS_TOKEN) zum Authorization-Server des Fachdienstes. |
A_24339 - Aufbereitung Fachdienst Client-ID als cidi für Rohdatenlieferung
Für die Erfassung der Rohdaten werden automatisiert verarbeitbare Informationen zum beim sektoralen IDP anfragenden Fachdienst benötigt. Zu diesem Zweck MUSS der sektorale IDP einen CRC-32 Hashwert aus der Client-ID (dem iss-claim aus dem Entity Statement des Fachdienstes) erstellen und diesen Wert in den Rohdaten im Parameter cidi verwenden. [<=]
A_22504 - Performance - Rohdaten - Spezifika IDP - Feldtrennzeichen im Useragent (Rohdatenerfassung v.02)
Der Produkttyp MUSS, sofern vom Client irrtümlicherweise im Useragent-Wert das verbotene Feldtrennzeichen ";" übertragen wurde, dieses ";" gegen das Zeichen "┼" austauschen und in der Rohdatenlieferung senden.
(siehe: A_21981: Feldtrennzeichen ";"
Das Zeichen ┼ ist definiert gem. Unicode U+253C (9532) - BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL - ALT-Code 197)
[<=]
A_21340-01 - IDP- Abbruch bei OCSP-Timeout
Der Produkttyp IdP-Dienst MUSS nach einer konfigurierbaren Wartezeit von 1100 msec auf die Antwort des OCSP den Vorgang abbrechen und diesen Abbruch gemäß [gemSpec_Perf#A_22015] und [Tab_gemSpec_Perf_Fehlercodes#"OCSP_ERROR_NO_RESPONSE"] in den Rohdaten protokollieren.
[<=]
Abbrüche des Anwendungsfalls können so differenziert erfasst werden. In den Fällen, bei denen die OCSP-Anfrage des zuständigen TSP zu spät beantwortet wird, erfolgt eine gesonderte Markierung in den Rohdaten. Dies ist notwendig zur Errechnung der Performancevorgaben des IDP. Hierbei werden diese Abbrüche nicht dem IDP angelastet.
A_22016-02 - Performance - Rohdaten - Spezifika IDP-Dienst Message Versionsinformation, ClientID und Error-Codes (Rohdatenerfassung v.02)
Der Produkttyp IDP-Dienst MUSS bei Rohdaten Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen:
{ "cid": "$clientid", "ua": "$useragent", "err": $errorCode }
- $clientid: <Client-ID> Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String
- $useragent: <User-Agent> gemäß Anforderungslage für Clientsysteme am Fachdienst [A_24060], Datentyp String
- $errorCode: <Error-Code> der entsprechende 4-stellige Fehlercode, Datentyp Integer
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden.
[<=]
A_24060-01 - Performance - Rohdaten - Spezifika IDP - Robustheitsprüfung UserAgent (Rohdatenerfassung v.02)
Der Produkttyp IDP-Dienst MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"- Felder den UserAgent auf die folgenden gültigen Zeichen überprüfen und bei Verstößen die Anfrage mit dem http-Status Code "400" bzw. im Falle eines "302" mit einem Error Code ablehnen. Der UserAgent muss dem folgenden Regular Expression entsprechen:
^[\w\.\/\s\-\(\)\&\%\;\[\]\+\<\>\#\?\@\:\,]+$
Hinweis: In den Rohdatenlieferungen zur Betriebsdatenerfassung ist bei Verstoß gegen die Regular Expression der Wert für "ua":"$useragent" mit "invalid" zu belegen. [<=]
3.1.3 Bestandsdaten sektoraler IDP
A_23213 - Registrierungsbestandsdaten - sektoraler IDP
Der sektorale IDP MUSS die Registrierungsinformationen jeweils täglich zur betriebsarmen Abendzeit vor 24:00 Uhr im JSON Format [gemäß A_23236] als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern.
Hinweis:
"Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig." [<=]
A_23236-04 - Format der Registrierungsinformationen des IDP
Der sektorale IDP MUSS bei der Lieferung der Registrierungsinformationen folgendes Format verwenden:
{
"abfragezeitpunkt": "<Zeitstempel der Abfrage als String im ISO 8601 Format>",
"ci": "<logische CI-ID des abgefragten IDP gemäß TI-ITSM; als String>",
"dailyUser":<Anzahl der Nutzer aller Mandanten, die den IDP einmal pro Tag nutzen; als Integer>,
"powerUser":<Anzahl der Nutzer aller Mandanten, die den IDP mehr als einmal pro Tag nutzen; als Integer>,
"bestand":{
"oaf":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren Online-Ausweisfunktion des neuen Personalausweises,
des elektronischen Aufenthaltstitels oder der EU-Bürgerkarte>,
"pif":<Anzahl der registrierten Nutzer mit Identifizierungsverfahren POSTIDENT Filiale>
}
}
Hinweise:
Im Bestand wird die Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer übermittelt.
Nur tatsächlich verwendete Elemente (Identifizierungsverfahren <idV> wie oaf, egk, pif, kkg, bot, not, apo, ...) müssen innerhalb der Werteliste [ ] aufgeführt werden. Im Muster sind hier nur oaf und pif aufgeführt - bitte um die verwendeten Verfahren entsprechend ergänzen.
Weitere Ident-Verfahren werden hier bekanntgegeben:
https://fachportal.gematik.de/fileadmin/Fachportal/Smartcards_in_der_TI/Festlegung_Identifikationsverfahren_V1.0.pdf
Die Anzahl der "powerUser" wird auch in der Anzahl der "dailyUser" mit erfasst. [<=]
3.2 E-Rezept
3.2.1 Leistungsanforderungen E-Rezept
3.2.1.1 Lastmodell E-Rezept
Die Anwendungsfälle zum E-Rezept setzen den Workflow der Verordnung von apothekenpflichtigen Arzneimitteln um. Dabei werden die folgenden performance-relevanten Anwendungsfälle gemäß [gemSpec_FD_eRp] betrachtet:
- E-Rezept durch Verordnenden erzeugen und einstellen
- E-Rezept durch Abgebenden abrufen
- Nachricht durch Abgebenden übermitteln/empfangen
- Abgabe durch Abgebenden vollziehen
- E-Rezept durch Versicherten abrufen
- Nachricht durch Versicherten übermitteln/empfangen
Bei jedem der genannten UseCases wird von einer existierenden, authentifizierten Nutzer-Session ausgegangen. Die jeweils übertragene Datenmenge hängt von der Anzahl der transportierten E-Rezepte ab. Je Anwendungsfall wird von einer Datenmenge von 10 kByte ausgegangen.
Die Tabelle "Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte" stellt eine Übersicht über die zu erwartenden Nutzungsraten für das E-Rezept dar. In der Lastbetrachtung wird von 4,8 Mio. ausgestellten und 3,7 Mio eingelöste Verordnungszeilen pro Tag ausgegangen. Das entspricht dem höchsten Aufkommen von Rezepten an einem Tag im Jahre 2018. Ebenfalls wird je Patient mit 1,4 Verordnungen (gerundet auf 2) kalkuliert.
Tabelle 13: Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte
| Anwendungsfall |
Datenmenge pro Anwendungs-fall in KByte |
Mengen-größe x |
Spitzenlasten pro Tag |
Spitzenlast- erhöhungs-faktor |
|---|---|---|---|---|
| E-Rezept durch Verordnenden erzeugen |
10 |
x: (M2+M3) |
25 * x |
2 |
| E-Rezept durch Verordnenden einstellen |
10 |
25 * x |
2 |
|
| E-Rezept durch Abgebenden abrufen |
10 |
x: M27 |
65 * x |
2 |
| Nachricht durch Abgebenden übermitteln/empfangen |
10 |
20 * x |
2 |
|
| Abgabe durch Abgebenden vollziehen |
10 |
x: M25 |
182 * x |
1 |
| E-Rezept durch Versicherten abrufen |
10 |
x: 2,4 Mio Versicherte |
2 * x |
2 |
| Nachricht durch Versicherten übermitteln/empfangen |
10 |
0,6 x |
- |
Zur Ermittlung der Last in der (Zahn-)Arztpraxis/Krankenhaus wird die Anzahl der verordnenden Leistungserbringer zugrunde gelegt, da für die Verordnung zwingend ein Heilberufsausweis für die QES benötigt wird und ebenso nur Ärzte/Zahnärzte zur Verordnung von Medikamenten berechtigt sind.
Der Vollzug der Abgabe durch den Abgebenden erfordert eine weitere Signatur durch einen Heilberufler bzw. in besonderen Fällen eine QES durch den Apotheker, weshalb hier M25 anstelle von M27 betrachtet wird.
In der Kommunikation zwischen Apotheken und Versicherten zur Abfrage der Verfügbarkeit von Medikamenten wird von einer Nutzungsrate von 30% ausgegangen.
3.2.1.2 Bearbeitungszeiten E-Rezept
Für das E-Rezept müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwerten sein.
Tabelle 14: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall
| ID |
Anwendungsfall
|
Datenmenge [KB] |
Mittelwert [sec] |
|---|---|---|---|
| ERP.UC_2_1 |
E-Rezept durch Verordnenden erzeugen |
10 |
4,2 |
| ERP.UC_2_3* |
E-Rezept durch Verordnenden einstellen mit Flowtype 160 |
10 |
1,4 |
| ERP.UC_3_1 | Nachrichten durch Abgebenden übermitteln/empfangen | 10 | 1,3 |
| ERP.UC_3_3 | Nachrichten durch Versicherten übermitteln/empfangen | 10 | 1,3 |
| ERP.UC_3_7 | Abrechnungsinformationen durch den Versicherten abrufen | 20 | 1,5 |
| ERP.UC_4_1 |
E-Rezept durch Abgebenden abrufen |
10 |
3,1 |
| ERP.UC_4_4 | E-Rezept durch Versicherten abrufen | 10 | 2,5 |
| ERP.UC_4_7 |
Abgabe durch Abgebenden vollziehen |
10 |
1,3 |
| ERP.UC_4_10 | Abrechnungsinformationen durch Abgebenden abrufen | 10 | 1,5 |
| ERP.UC_4_11 | Abrechnungsinformationen durch Abgebenden bereitstellen | 10 | 1,4 |
| ERP.UC_4_16 | Dispensierinformationen durch Abgebenden bereitstellen | 10 | 2,5 |
Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp].
Die erhöhte Bearbeitungszeit bei den Anwendungsfällen zur Erstellung eines E-Rezepts beim Verordnenden und dem Abruf eines Rezeptes beim Abgebenden sind daraus zu begründen, dass hier die Konnektor-Operationen für das QES-Signieren und QES-Verifizieren von 10 KB-Dokumenten enthalten sind.
Ebenfalls ist die erhöhte Bearbeitungszeit daraus zu begründen, dass ist in der Modellbetrachtung von einer Transportanbindung von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung für die Leistungserbringer-Umgebung sowie für die des Versicherten ausgegangen wird.
(*) In der Bearbeitungszeit wird mit dem aktuellen Referenzwert für die QES-Erstellung gerechnet, da noch keine Aussage zur Bearbeitungsdauer der QES-Erstellung mittels Komfortsignatur getroffen werden kann.
Hinweis: In den Bearbeitungszeitvorgaben der jeweiligen Anwendungsfälle ist die Ausstellung der ID-Tokens des Identity Providers nicht berücksichtigt.
3.2.1.3 Performancevorgaben E-Rezept
A_20165-07 - Performance – E-Rezept-Fachdienst - Bearbeitungszeit unter Last
Der Produkttyp E-Rezept-Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.
Tabelle 15 Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben
| UseCase-Bezug | Fachdienstoperation | Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|
| ERP.UC_1_1 | GET /Device | 10 | 120 | 200 |
| ERP.UC_1_2 | GET /metadata | 10 | 120 | 200 |
| ERP.UC_2_1 | POST /Task/$create | 390 | 250 | 400 |
| ERP.UC_2_3* | POST /Task/<id>/$activate | 390 | 460 | 620 |
| ERP.UC_2_5 | POST /Task/<id>/$abort | 25 | 330 | 470 |
| ERP.UC_3_1 | GET /Task | 310 | 380 | 530 |
| ERP.UC_3_2 | POST /Task/<id>/$abort | 10 | 330 | 470 |
| ERP.UC_3_3 | POST /Communication | 50 | 430 | 590 |
| ERP.UC_3_4 | GET /Communication | 40 | 540 | 720 |
| ERP.UC_3_5 | GET /AuditEvent | 30 | 540 | 720 |
| ERP.UC_3_6 | GET /Task/<id> | 40 | 380 | 530 |
| ERP.UC_3_7 | GET /ChargeItem/<id> | 40 | 480 | 650 |
| ERP.UC_3_8 | DELETE /Communication/<id> | 10 | 540 | 720 |
| ERP.UC_3_9 | GET /MedicationDispense?<parameter>= | 30 | 540 | 720 |
| ERP.UC_3_10 | GET /ChargeItem | 10 | 540 | 720 |
| ERP.UC_3_11 | DELETE /ChargeItem/<id> | 10 | 430 | 590 |
| ERP.UC_3_12 | PATCH /ChargeItem/<id> | 10 | 310 | 440 |
| ERP.UC_3_13 | GET /Consent | 10 | 280 | 410 |
| ERP.UC_3_14 | POST /Consent | 10 | 340 | 480 |
| ERP.UC_3_15 | DELETE /Consent | 10 | 430 | 600 |
| ERP.UC_4_1 | POST /Task/<id>/$accept | 240 | 340 | 480 |
| ERP.UC_4_2 | POST /Task/<id>/$reject | 40 | 300 | 430 |
| ERP.UC_4_3 | POST /Task/<id>/$abort | 10 | 330 | 470 |
| ERP.UC_4_4 | POST /Task/<id>/$close | 120 | 460 | 620 |
| ERP.UC_4_6 | GET /Communication | 75 | 540 | 720 |
| ERP.UC_4_7 | POST /Communication | 75 | 430 | 590 |
| ERP.UC_4_8 | GET /Task/<id> | 30 | 615 | 800 |
| ERP.UC_4_9 | DELETE /Communication/<id> | 10 | 290 | 420 |
| ERP.UC_4_10 | GET /ChargeItem/<id> | 10 | 480 | 650 |
| ERP.UC_4_11 | POST /ChargeItem | 30 | 510 | 680 |
| ERP.UC_4_12 | GET /Task(PNW) | 220 | 650 | 840 |
| ERP.UC_4_13 | PUT /ChargeItem/<id> | 10 | 510 | 670 |
| ERP.UC_4_14 | POST /Subscription | 40 | 230 | 350 |
| ERP.UC_4_16 | POST /Task/<id>/$dispense | 25 | 460 | 620 |
Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp]. Die in der Tabelle definierten Bearbeitungszeiten beziehen sich auf die vom Fachdienst umzusetzenden Operationen in den referenzierten Anwendungsfällen.
A_20166 - Performance - E-Rezept-Fachdienst - Robustheit gegenüber Lastspitzen
Der E-Rezept Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben.
[<=]
Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der E-Rezept-Fachdienst 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 des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.
A_19737 - Performance E-Rezept-Fachdienst - Skalierung
Der Anbieter des E-Rezept Fachdienstes MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
[<=]
Im Zuge des Zulassungsverfahrens hat der Anbieter des E-Rezept-Fachdienstes 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_19736-02 - Performance - E-Rezept-Fachdienst - Verfügbarkeit
Der Anbieter E-Rezept-Fachdienst MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:
- Hauptzeit: 99,99%
- Nebenzeit: 99,97%
Die Verfügbarkeit der funktionalen Eigenschaften des E-Rezept-Fachdienstes wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.
A_19735-02 - Performance - Erfassung von Rohdaten - E-Rezept-Fachdienst
Der Produkttyp E-Rezept-Fachdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefern. [<=]
A_19734 - Performance - Lieferung von Rohdaten - E-Rezept-Fachdienst
Der Anbieter E-Rezept-Fachdienst MUSS das Produkt E-Rezept-Fachdienst so konfigurieren, dass dieses in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte und die Datei zur Selbstauskunft automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefert. Voreingestellt für das Zeitintervall ist 60 Minuten. [<=]
3.2.2 Rohdaten-Performance-Reporting Spezifika E-Rezept
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.2.2.1 Umfang
A_22975 - Performance - Rohdaten-Performance-Bericht - Konfiguration pseudonymisierte Werte der Telematik-ID
Der Produkttyp E-Rezept-Fachdienst MUSS eine Konfiguration unterstützen, welche die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen ein- bzw. abschaltet.
[<=]
A_22976 - Performance - Rohdaten-Performance-Bericht - Steuerung Konfiguration pseudonymisierte Werte der Telematik-ID
Der Anbieter des E-Rezept-Fachdienstes MUSS die Konfiguration für die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen entsprechend den Vorgaben der gematik vornehmen. [<=]
3.2.2.2 Format
A_23088 - Performance - Rohdaten - Spezifika E-Rezept - Operation (Rohdatenerfassung v.02)
Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "operation" die Angabe der Spalte "$FD-operation" aus Tabelle [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] berücksichtigen.
Sollte die Operation des inneren Requests nicht ermittelt werden können, so ist stattdessen für das Feld "operation" der Wert "ERP.VAU" zu verwenden. [<=]
A_23089 - Performance - Rohdaten - Spezifika E-Rezept - Status (Rohdatenerfassung v.02)
Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "status" die Angabe der Spalte "HTTP-Status-Code" gemäß A_19514-* aus [gemSpec_FD_eRp] berücksichtigen. [<=]
A_23090-02 - Performance - Rohdaten - Spezifika E-Rezept - Message (Rohdatenerfassung v.02)
Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.
{ "cid": "$clientid", "ua": "$useragent", "leip": "$leipseudonym", "size": $size, "bkdur": $backendduration, "mvonr": $mvo-nummer, "vnr": $vorgangsnummer, "anr": $anrvalue, "zanr": $zanrvalue}
- $clientid: Zeichenkette zur Identifikation des Herstellers in einer Betriebsumgebung, Datentyp String
- $useragent: HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme, Datentyp String
- $leipseudonym: Stark pseudonymisierte Telematik-ID, Datentyp String
- $size: Größe des Requests in kilobyte, Datentyp Integer
- $backendduration: Zeit in ms für Abfragen an OCSP oder analogen Backendsystemen, Datentyp Integer
- $mvo-nummer: Der Wert Nummer des Rezepts der Mehrfachverordnung, Datentyp Integer
- $vorgangsnummer: Task-ID im Fachdienst, Datentyp String
- $anrvalue: Der Wert des Feldes identifier:ANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer
- $zanrvalue: Der Wert des Feldes identifier:ZANR.value bei aufgetretenem Prüfungsfehler gem. A_24032, Datentyp Integer
A_23091 - Performance - Rohdaten - Spezifika E-Rezept - Duration (Rohdatenerfassung v.02)
Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]
Tabelle 16: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst
| $FD-operation |
Operation |
Schnittstelle zu |
|---|---|---|
| ERP.UC_1_1 | GET /Device | alle |
| ERP.UC_1_2 | GET /metadata | alle |
| ERP.UC_2_1 |
POST /Task/$create |
verordnende LEI |
| ERP.UC_2_3 |
POST /Task/<id>/$activate mit Flowtype 160 |
verordnende LEI |
| ERP.UC_2_3_169 | POST /Task/<id>/$activate mit Flowtype 169 | verordnende LEI |
| ERP.UC_2_3_200 | POST /Task/<id>/$activate mit Flowtype 200 | verordnende LEI |
| ERP.UC_2_3_209 | POST /Task/<id>/$activate mit Flowtype 209 | verordnende LEI |
| ERP.UC_2_5 | POST /Task/<id>/$abort | verordnende LEI |
| ERP.UC_3_1 | GET /Task | Versicherte |
| ERP.UC_3_2 | POST /Task/<id>/$abort | Versicherte |
| ERP.UC_3_3 | POST /Communication | Versicherte |
| ERP.UC_3_5 | GET /AuditEvent | Versicherte |
| ERP.UC_3_6 | GET /Task/<id> | Versicherte |
| ERP.UC_3_7 | GET /ChargeItem/<id> | Versicherte |
| ERP.UC_3_8 | DELETE /Communication/<id> | Versicherte |
| ERP.UC_3_9 | GET /MedicationDispense?<parameter>= | Versicherte |
| ERP.UC_3_10 | GET /ChargeItem | Versicherte |
| ERP.UC_3_11 | DELETE /ChargeItem/<id> | Versicherte |
| ERP.UC_3_12 | PATCH /ChargeItem/<id> | Versicherte |
| ERP.UC_3_13 | GET /Consent | Versicherte |
| ERP.UC_3_14 | POST /Consent | Versicherte |
| ERP.UC_3_15 | DELETE /Consent | Versicherte |
| ERP.UC_4_1 | POST /Task/<id>/$accept | abgebende LEI |
| ERP.UC_4_2 | POST /Task/<id>/$reject | abgebende LEI |
| ERP.UC_4_3 | POST /Task/<id>/$abort | abgebende LEI |
| ERP.UC_4_4 | POST /Task/<id>/$close | abgebende LEI |
| ERP.UC_4_7 | POST /Communication |
abgebende LEI |
| ERP.UC_4_8 | GET /Task/<id> | abgebende LEI |
| ERP.UC_4_9 | DELETE /Communication/<id> | abgebende LEI |
| ERP.UC_4_10 | GET /ChargeItem/<id> | abgebende LEI |
| ERP.UC_4_11 | POST /ChargeItem | abgebende LEI |
| ERP.UC_4_12 | GET /Task(PNW) | abgebende LEI |
| ERP.UC_4_13 | PUT /ChargeItem/<id> | abgebende LEI |
| ERP.UC_4_14 | POST /Subscription | abgebende LEI |
| ERP.UC_4_16 | POST /Task/<id>/$dispense | abgebende LEI |
| ERP.nonVAU_1 | GET /VAUCertificate | alle |
| ERP.nonVAU_2 | GET /VAUCertificateOCSPResponse | alle |
| ERP.nonVAU_3 | GET /CertList | alle |
| ERP.nonVAU_4 | GET /OCSPList | alle |
| ERP.nonVAU_5 | POST /ocspf | alle |
3.2.3 Bestandsdaten E-Rezept-Fachdienst
A_22520-01 - Performance – E-Rezept-Fachdienst - Bestandsdaten
Der Anbieter E-Rezept-Fachdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den E-Rezept-Fachdienst berichten:
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Ready gestaffelt nach FlowType
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Inprogress gestaffelt nach FlowType
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Completed gestaffelt nach FlowType
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Cancelled gestaffelt nach FlowType
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Ready mit einem Tag vor der Löschfrist (Task.expiryDate > 9 Tage) gestaffelt nach FlowType
- Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Inprogress mit einem Tag vor der Löschfrist (lastmodified > 99 Tage) gestaffelt nach FlowType
Voreingestellt für das Zeitintervall ist: täglich.
[<=]
A_22521-01 - Performance - E-Rezept-Fachdienst - Lieferweg und Format für Bestandsdaten
Der Anbieter E-Rezept-Fachdienst MUSS die Informationen aus [A_22520] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [A_23110] mit Einschränkungen* liefern:
{
"abfragezeitpunkt": <Zeitstempel der Abfrage als String im Format ISO 8601>,
"ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
"ready": {
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 im Status Ready als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 im Status Ready als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 im Status Ready als Integer>
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 im Status Inprogress als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 im Status Inprogress als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 im Status Inprogress als Integer>
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 im Status Completed als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 im Status Completed als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 im Status Completed als Integer>
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 im Status Cancelled als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 im Status Cancelled als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 im Status Cancelled als Integer>
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 zur Löschung am Folgetag im Status Ready als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 zur Löschung am Folgetag im Status Ready als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 zur Löschung am Folgetag im Status Ready als Integer>
"169": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=169 zur Löschung am Folgetag im Status Inprogress als Integer>,
"200": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=200 zur Löschung am Folgetag im Status Inprogress als Integer>,
"209": <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte mit FlowType=209 zur Löschung am Folgetag im Status Inprogress als Integer>
}
* Einschränkungen: Da bei dieser Lieferung keine Datei übermittelt wird, sondern die Daten direkt im Request-Body geliefert werden, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_23110] NICHT notwendig.
[<=]
3.3 TI-Messenger (TI-M)
Dieses Kapitel dient der Ergänzung der TI-Messenger (TI-M) Spezifikationen [gemSpec_TI-Messenger-Dienst], [gemSpec_TI-Messenger-FD] und [gemSpec_TI-Messenger-Client]. Der gesamte Anforderungshaushalt inkl. Referenzen auf weitere normative Dokumente an die jeweiligen TI-M Produkte und Anbieter findet sich in diesen Dokumenten als auch in den entsprechenden Produkt- bzw. Anbietertypsteckbriefen.
3.3.1 Leistungsanforderungen TI-M
3.3.1.1 Lastmodell TI-M
keine spezifischen Anforderungen zum Lastmodell
3.3.1.2 Bearbeitungszeiten TI-M
keine spezifischen Anforderungen zu Bearbeitungszeiten
3.3.1.3 Performancevorgaben TI-M
A_23116 - TI-M Fachdienst Verfügbarkeit (Produkt)
Der TI-Messenger-Fachdienst MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von mindestens 99,8 % betreibbar sein. [<=]
A_23117-01 - TI-M Fachdienst Verfügbarkeit (Anbieter)
Der Anbieter TI-Messenger MUSS sein Produkt TI-Messenger-Fachdienst mit einer vollumfänglich-funktionalen Verfügbarkeit von 99,8% in der Hauptzeit und 99,0 % in der Nebenzeit betreiben.
Die Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Zeiten gelten als Nebenzeit.
Wenn der Betrieb von Homeservern on-premise bei den Nutzern realisiert wird, KANN der Anbieter TI-Messenger für diese Produktinstanzen von den Performancevorgaben in Abstimmung mit seinen Kunden abweichen. Die Abweichungen und die betroffenen Instanzen bzw. Komponenten MÜSSEN im Betriebshandbuch für jeden on-premise Betrieb dokumentiert werden.
[<=]
3.3.2 Rohdaten-Performance-Reporting Spezifika TI-M
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.3.2.1 Umfang TI-M
Es werden keine speziellen Anforderungen zum Umfang der Rohdatenlieferung getroffen.
3.3.2.2 Format TI-M
A_24043 - Performance - Rohdaten - Spezifika Fachdienst TI-M - Duration (Rohdatenerfassung v.02)
Der Produkttyp Fachdienst TI-Messenger MUSS bei Rohdaten-Performance-Berichten die Inhalte des Feldes "duration_in_ms" nach den Vorgaben der Tabelle [Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3] entsprechend der Spalten "Start der Messung" und "Ende der Messung" für die jeweilige TIM-Operation befüllen. [<=]
A_24044 - Performance - Rohdaten - Spezifika Fachdienst TI-M - Operation (Rohdatenerfassung v.02)
Der Produkttyp Fachdienst TI-Messenger MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "operation" gemäß A_21981-02, die Angabe entsprechend der Spalte "$TIM-Operation" aus [Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3] befüllen. [<=]
Tabelle 17: Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3
| Messung am Produkt | $TIM-Operation (Referenz Use Case / Anwendungsfall) |
Beschreibung | Start der Messung | Ende der Messung (siehe Hinweis *1) |
|---|---|---|---|---|
| TI-Messenger-Fachdienst | TIM.UC_10103-01_01 | 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst: Redirect to IdP |
Request: POST I_Registration (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) |
Response: Redirect to IDP Authorization Endpoint (Antwort an Frontend des Registrierungs-Dienstes) |
| TI-Messenger-Fachdienst | TIM.UC_10103-01_02 | 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst: Authentisierung |
Request: POST /register (Authorization code) (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) |
Response: status (Antwort an Frontend des Registrierungs-Dienstes) |
| TI-Messenger-Fachdienst | TIM.UC_10103-01_03 | 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst: Admin Account anlegen |
Request: POST I_Registration (Admin-Account Credentials + 2. Faktor) (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) |
Response: status (Antwort an Frontend des Registrierungs-Dienstes) |
| TI-Messenger-Fachdienst | TIM.UC_10060_01 | 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation: Login |
Request: POST /login (Client-Credentials) (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) |
Response: status (Antwort an Frontend des Registrierungs-Dienstes) |
| TI-Messenger-Fachdienst | TIM.UC_10060_02 | 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation: Messenger-Service erstellen |
Request: POST /create (Matrix-Domain) (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) |
Response von Messenger-Service: status (Antwort an Registrierungs-Dienstes) |
| TI-Messenger-Fachdienst | TIM.UC_10060_03 | 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation: Messenger-Service in die Föderation aufnehmen |
Request: POST /token (client_id) (Registrierungs-Dienst an OAuth-Service des VZD-FHIR-Directory) |
Response: status (Antwort an Frontend des Registrierungs-Dienstes) |
| TI-Messenger Fachdienst | TIM.UC_10059-01_02 | 6.3 AF - Organisationsressourcen im Verzeichnisdienst hinzufügen: Get RegService-OpenID-Token |
Request: RegService-OpenID-Token anfragen (z.B. GET /regserv/request_Token) (TI-Messenger-Client mit Org-Admin Funktionalität an Registrierungsdienst) |
Response: RegService-OpenID-Token {telematikID, professionOID, Signaturzertifikat (x5c)} (Antwort an TI-Messenger-Client mit Org-Admin Funktionalität) |
| TI-Messenger-Fachdienst | TIM.UC_10057_01 | 6.4 AF - Anmeldung eines Akteurs am Messenger-Service: Client-Login, Auswahl Authentifizierungsverfahren |
Request: GET /_matrix/client/login (TI-Messenger-Client an Messenger-Proxy) |
Response: HTTPS Forward inkl. unterstützte Authentifizierungsverfahren (Antwort an TI-Messenger-Client) |
| TI-Messenger-Fachdienst | TIM.UC_10057_02 | 6.4 AF - Anmeldung eines Akteurs am Messenger-Service: Erstellung Matrix-ACCESS_TOKEN |
Request: POST /_matrix/client/login (TI-Messenger-Client an Messenger-Proxy) |
Response: HTTPS Forward inkl. Matrix-ACCESS_TOKEN, device_ID, MXID (Antwort an TI-Messenger-Client) |
| TI-Messenger-Fachdienst | TIM.UC_10057_03 | 6.4 AF - Anmeldung eines Akteurs am Messenger-Service: Erstellung Matrix-OpenID-Token |
Request: POST /_matrix/client/user/{userid}/openid/request_token (TI-Messenger-Client an Messenger-Proxy) |
Response: HTTPS Forward inkl. Matrix-OpenID-Token (Antwort an TI-Messenger-Client) |
| TI-Messenger-Fachdienst | TIM.UC_10104-01_01 | 6.7 AF - Einladung von Akteuren innerhalb einer Organisation: Akteur suchen |
Request: POST /_matrix/client/user_directory/search (TI-Messenger Client A an Messenger-Proxy) |
Response: HTTPS Forward inkl MXID (Messenger-Proxy an TI-Messenger Client A) |
| TI-Messenger-Fachdienst | TIM.UC_10104-01_02 | 6.7 AF - Einladung von Akteuren innerhalb einer Organisation: Akteur einladen |
Request: POST /_matrix/client/r0/rooms/{roomId}/invite (TI-Messenger Client A an Messenger-Proxy) |
Response: status (Messenger-Proxy an TI-Messenger-Client Akteur A) |
| TI-Messenger-Fachdienst | TIM.UC_10063_01 | 6.8 AF - Austausch von Events innerhalb einer Organisation | Request: Matrix-Request (TI-Messenger Client an Messenger-Proxy) |
Response: HTTPS Forward Status (Matrix-Request) (Antwort an TI-Messenger-Client Akteur A) |
| TI-Messenger-Fachdienst | TIM.UC_10061-01_01 | 6.9 AF - Einladung von Akteuren außerhalb einer Organisation: Eintrag in Freigabeliste erzeugen |
Request: POST /tim-contact-mgmt/createContactSetting (MXID, start, end, Matrix-OpenID-Token) (TI-Messenger-Client an TI-Messenger Proxy) |
Response: status (Antwort an TI-Messenger-Client) |
| TI-Messenger-Fachdienst (Sendersystem) | TIM.UC_10061-01_02 | 6.9 AF - Einladung von Akteuren außerhalb einer Organisation: Einladung Sendersystem |
Request: POST /_matrix/client/r0/rooms/{roomId}/invite (TI-Messenger Client an Messenger-Proxy) |
Response: HTTPS Forward Status (Antwort an TI-Messenger-Client Akteur A) |
| TI-Messenger-Fachdienst (Sendersystem) | TIM.UC_10061-01_03 | 6.9 AF - Einladung von Akteuren außerhalb einer Organisation: Einladung Empfangssystem(e) |
Request: HTTPS Forward (POST /_matrix/federation/v1/invite/{roomId}/{eventId}) (Messenger-Proxy des Sendersystems an Messenger-Proxy des Empfangssystems) |
Response: Status (Antwort an Messenger-Proxy des Sendersystems) |
| TI-Messenger-Fachdienst (Sendersystem) | TIM.UC_10062-01_01 | 6.10 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation: Event Sendersystem |
Request: Matrix-Request (TI-Messenger Client an eigenen Messenger-Proxy) |
Response: HTTPS Forward Status (Antwort an TI-Messenger-Client Akteur A |
| TI-Messenger-Fachdienst (Sendersystem) | TIM.UC_10062-01_02 | 6.10 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation: Event Empfangssystem(e) |
Request: HTTPS Forward Matrix-Request (Messenger-Proxy Sendersystem an Messenger-Proxy Empfangssystem) |
Response: HTTPS Forward Status (Antwort an Messenger-Proxy des Sendersystems) |
*1) Hinweis: Die Beschreibung entspricht dem Ende eines erfolgreichen Anwendungsfalls. Wenn der Anwendungsfall abbricht und/oder eine Fehlermeldung erzeugt, so MUSS im JSON-message-Block für das Feld httpStatus der negative http-Statuscode entsprechend der Beschreibung im Anwendungsfall eingetragen werden. Für jede Anwendungsfall-Instanz MUSS eine eindeutige ID vergeben werden. Die ID KANN mit einem Abstand von 6 Monaten neu vergeben werden um die Operationen innerhalb eines Anwendungsfalls konsolidieren zu können und gleichzeitig von anderen Anwendungsfall-Instanzen abzugrenzen.
A_22940-01 - Performance - Rohdaten - Spezifika TI-M Message (Rohdatenerfassung v.02)
Das Produkt SOLL - bei Rohdaten-Performance-Berichten im "message"-Feld – folgende Informationen im JSON-Format übermitteln:
{
"Inst-ID":$Instanz-ID,
"UA-PTV": $UA-Produkttypversion,
"UA-PV": $UA-Produktversion,
"UA-A": $UA-Auspraegung,
"UA-P": $UA-Plattform,
"UA-OS": $UA-OS,
"UA-OSV": $UA-OS-Version,
"UA-cid": $UA-client_id,
"M-Dom":$Matrix-Domain,
"sizeIn":$sizeIn,
"sizeOut":$sizeOut,
"tID":$telematikID,
"profOID":$professionOID,
"Res":$response
}
Für $Instanz-ID ist eine für jede Instanz eines Anwendungsfalls entsprechend [gemSpec_TI-Messenger-Dienst] gleichbleibende ID einzutragen.
Die Instanz-ID SOLL somit für die jeweiligen Operationen bzw. Teilschritte innerhalb einer Instanz eines Anwendungsfalls gleich vergeben werden. "Instanz" bezieht sich hierbei auf die Instanziierung des Anwendungsfalls, nicht die physische Instanz des Messenger-Services o.ä.
Für Felder beginnend mit "UA-" sind die entsprechenden Werte einzutragen, welche vom Client (User-Agent) übermittelt werden. Falls die Anfrage für den Teilschritt des Anwendungsfalls von einem Matrix-Server ausgeht (Server-Server API), sind die Bezeichner mit "UA-" weiterhin aufzuführen und mit dem Wert "n/a" zu befüllen.
Für $UA-Auspraegung sind ausschließlich die Werte "Org-Admin-Client" und "Messenger-Client" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-Plattform sind ausschließlich die Werte "mobil", "stationaer", "web" entsprechend der TI-M Client Spezifikation erlaubt.
Für $UA-OS ist das entsprechende Betriebssystem einzutragen, z.B. Windows, iOS, MacOS, Android, GNU/Linux.
Für $UA-OS-Version ist die Version des Betriebssystems einzutragen.
Für $UA-client_id ist die client_id einzutragen wie sie auch dem zentralen IDP-Dienst bzw. TI-Messenger Fachdienst IdP übermittelt wird.
Für $Matrix-Domain ist die eigene Matrix-Domain des Messenger-Services einzutragen.
Für $sizeIn ist das eingehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für $sizeOut ist das ausgehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
Für die $telematikID ist die telematikID der zur Domäne zugehörigen SMC-B einzutragen.
Für die $professinoOID ist die professionOID der zugehörigen SMC-B einzutragen.
Für die $response ist der Statuscode als Rückmeldung der entsprechenden Anwendungsfälle einzutragen.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]
Bestandsdaten
A_23119-02 - TI-Messenger Fachdienst Bestandsdaten
Der TI-Messenger-Fachdienst MUSS die nachfolgenden Informationen täglich in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD] liefern:
{
"ci": <CI-ID des abgefragten Fachdienstes gemäß [A_17764] als String>,
"anzMs": <Anzahl der zum Abfragezeitpunkt instanziierten Messenger-Service als Integer>,
"anzNu": <Anzahl der zum Abfragezeitpunkt registrierten Nutzer über alle Messenger-Services als Integer>,
"anzRa": <Anzahl der zum Abfragezeitpunkt offenen Räume als Integer>,
"anzEv": <Anzahl Message-Events als Integer, kumuliert>,
"uaPtv": $ua-Produkttypversion,
"uaPv": $ua-Produktversion,
"uaAus": $ua-Auspraegung,
"uaPlat": $ua-Plattform,
"uaOsv": $ua-OSv,
"uaCid": $ua-client_id,
"afList": [
{
"md": "$md",
"TIM.UC_10103-01_01": $anzahl,
"TIM.UC_10103-01_02": $anzahl,
"TIM.UC_10103-01_02a": $anzahl,
"TIM.UC_10103-01_03": $anzahl,
"TIM.UC_10060_01": $anzahl,
"TIM.UC_10060_02": $anzahl,
"TIM.UC_10060_03": $anzahl,
"TIM.UC_10059-01_02": $anzahl,
"TIM.UC_10057_01": $anzahl,
"TIM.UC_10057_02": $anzahl,
"TIM.UC_10057_03": $anzahl,
"TIM.UC_10104-01_01": $anzahl,
"TIM.UC_10104-01_02": $anzahl,
"TIM.UC_10063_01": $anzahl,
"TIM.UC_10061-01_01": $anzahl,
"TIM.UC_10061-01_02": $anzahl,
"TIM.UC_10061-01_03": $anzahl,
"TIM.UC_10062-01_01": $anzahl,
"TIM.UC_10062-01_02": $anzahl,
}
]
- uaList: Das Array MUSS mit Werten entsprechend ihrer Beschreibung befüllt werden. Es DÜRFEN NUR neue Kombinationen der Attribute übermittelt werden, welche zuvor noch nicht übermittelt wurden.
- $uaKen: Datentyp String, SHA1 (Base64-kodiert). Für $ua_ken MUSS die mit SHA1 kodierte Kennung einer bestimmten Client-Ausprägung in Synchronisation mit A_22940 eingetragen werden. Die Kennung MUSS eindeutig für jede einzigartige Kombination der User-Agent Attribute vergeben werden.*
- $uaPtv: Datentyp String. Für $ua-Produkttypversion MUSS die Produkttypversion des TI-Messenger Clients eingetragen werden.
- $uaPv: Datentyp String. Für $ua-Produktversion MUSS die Produktversion des TI-Messenger Clients eingetragen werden.
- $uaAus: Datentyp String. Für $ua-Auspraegung MUSS die Ausprägung des Clients entsprechend der Spezifikation eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "Org-Admin-Client" oder "Messenger-Client" verwendet werden.
- $uaPlat: Datentyp String. Für $ua-Plattform MUSS die Plattform des Clients eingetragen werden. Es DÜRFEN AUSSCHLIEßLICH die Werte "mobil", "stationaer" oder "web" verwendet werden.
- $uaOsv: Datentyp String. Für $ua-OSv MUSS das entsprechende Betriebssystem mit der Version eingetragen werden. Zum Beispiel "Windows 10 Enterprise", "iOS 16.6", "macOS Ventura 13.5.1", "Android 13", "Ubuntu 22.04 LTS" etc.
- $uaCid: Datentyp String. Für $ua-client_id MUSS die client_id eingetragen werden wie sie auch dem TI-Messenger Fachdienst gemäß A_23104 übermittelt wird.
- afList: Das Array enthält alle Teilschritte aller Anwendungsfälle die am Fachdienst erfasst werden MÜSSEN. Die Keys MÜSSEN alle exakt wie dargestellt übermittelt werden. Die erfasste Anzahl an Aufrufen je Teilschritt (inkl. Fehler) MUSS für $anzahl als Wert (Integer) übermittelt werden. Wenn ein Teilschritt in einem Zeitintervall nicht registriert wurde, MUSS der Wert 0 eingetragen werden.
- $md: Datentyp String. Für $md MUSS die eigene Matrix-Domain des Messenger-Services eingetragen werden, wie sie auch in der Föderationsliste hinterlegt ist.
* Hinweis:
Die Kennung dient in erster Linie dem Anbieter zur Differenzierung der Clients im anbieterübergreifenden Betrieb falls der TI-M Client (als zugelassenes Produkt) selbst keine unterschiedliche Kennung (client_id) aufweist.
[<=]
3.4 TSP X.509 QES, nQ-eGK, nQ-HBA, nQ-SMC-B
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat für folgende Produkttypen aufgeführt:
- Trust Service Provider X.509 QES,
- Trust Service Provider X.509 nonQES - eGK,
- Trust Service Provider X.509 nonQES - HBA,
- Trust Service Provider X.509 nonQES - SMC-B
Die Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat für den Produkttyp TSP X.509 nQ - Komp werden im aufgeführt.
3.4.1 Leistungsanforderungen TSP X.509
3.4.1.1 Lastmodell TSP X.509
Keine spezifischen Anforderungen zum Lastmodell.
3.4.1.2 Bearbeitungszeiten TSP X.509
Sind im Folgekapitel "Performancevorgaben TSP X.509" mit enthalten.
3.4.1.3 Performancevorgaben TSP X.509
A_24324 - Performance - OCSP Responder der TSP X.509 - Grundlast
Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES - HBA, TSP-X.509 nonQES - eGK und TSP-X.509 nonQES - SMC-B MÜSSEN die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSPX509 unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]
A_24325 - Performance - OCSP Responder der TSP X.509 - Bearbeitungszeiten unter Spitzenlast
Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES - HBA, TSP-X.509 nonQES - eGK und TSP-X.509 nonQES - SMC-B MÜSSEN die Bearbeitungszeitvorgaben unter der für alle Funktionen parallel anliegenden Spitzenlast dauerhaft erfüllen. Die dabei geltende Spitzenlast pro Funktion wird aus Tabelle Tab_gemSpec_Perf_OCSP_Responder_TSPX509 wie folgt abgeleitet:
- Last für Zertifikate zu HBA und SMC-B = Anzahl der herausgegebenen Karten mit zeitlich noch gültigen Zertifikaten in Tausend / 210 * Spitzenlastwert aus Tabelle Tab_gemSpec_Perf_OCSP_Responder
- Last für Zertifikate zu eGK: Anzahl der herausgegebenen Karten mit zeitlich noch gültigen Zertifikaten in Millionen / 70 * Spitzenlastwert aus Tabelle Tab_gemSpec_Perf_OCSP_Responder
Tabelle 18: Tab_gemSpec_Perf_OCSP_Responder_TSPX509
| Operation |
Produkttyp | Anwendungsfall |
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|---|
| TSP.UC_1_Q |
Trust Service Provider X.509 QES (PDT02) | 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 |
||||
| TSP.UC_2_nQ |
Trust Service Provider X.509 nonQES - eGK (PDT03) | 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 |
||||
| Trust Service Provider X.509 nonQES - HBA (PDT36) | Prüfung von HBA-Zertifikaten aus der TI (C.HP.ENC) |
310 | 1.000 | 1.300 | |
| Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.ENC) |
15 | ||||
| Prüfung von HBA-Zertifikaten aus der TI (C.HP.AUT) |
- | ||||
| Prüfung von HBA-Zertifikaten aus dem Internet (C.HP.AUT) |
30 | ||||
| Trust Service Provider X.509 nonQES – SMC-B (PDT38) | Prüfung von SMC-B-Zertifikaten aus der TI (C.HCI.OSIG) |
1100 |
1.000 | 1.300 | |
| Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.OSIG) |
30 |
||||
| 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 SMC-B-Zertifikaten aus der TI (C.HCI.AUT) |
385 | ||||
| Prüfung von SMC-B-Zertifikaten aus dem Internet (C.HCI.AUT) |
30 |
3.4.2 Rohdaten-Performance-Reporting Spezifika TSP X.509
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.4.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.4.2.2 Format
A_22489 - Performance - Rohdaten - Spezifika TSP X.509 - Duration (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]
A_22490 - Performance - Rohdaten - Spezifika TSP X.509 - Operation (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]
Tabelle 19: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509
| Operation/Usecase | Produkttyp |
Duration |
|---|---|---|
| TSP.UC_1_Q | TSP-X.509QES |
Bei Aufruf der Operation check_Revocation_Status beginnt die Messung mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. |
| TSP.UC_2_nQ | TSP-X.509nonQES |
Bei Aufruf der Operation check_Revocation_Status beginnt die Messung mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. |
A_22491 - Performance - Rohdaten - Spezifika TSP X.509 - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_TSP-X.509 festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
Tabelle 20: Tab_gemSpec_Perf_Fehlercodes_TSP-X.509
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 79875 |
OCSP_ERROR_WRONG_DATA |
Format der OCSP-Anfrage fehlerhaft |
A_22492 - Performance - Rohdaten - Spezifika TSP X.509 - Message (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die Rückgabewerte der Abfrage des Sperrstatus der jeweiligen X.509 Zertifikate im JSON-Format übermitteln:
{"Sperrstatus":"$status"}
Für $status ist der entsprechende Sperrstatus-Wert gemäß Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509 einzutragen, welcher für das jeweilige Zertifikat ermittelt wurde.
Tabelle 21: Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509
| Sperrstatus |
|---|
| GOOD |
| REVOKED |
| UNKNOWN |
3.5 IDP-Federation Master
3.5.1 Leistungsanforderungen IDP-Federation Master
3.5.1.1 Lastmodell IDP-Federation Master
3.5.1.2 Bearbeitungszeiten IDP-Federation Master
3.5.1.3 Performancevorgaben IDP-Federation Master
A_22957 - Performance – FedMaster – Verfügbarkeit
Der Anbieter des Federation Master MUSS sein Produkt so betreiben, dass es zur Hauptzeit und zur Nebenzeit mindestens eine Verfügbarkeit von 98,40 % hat.
Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
Hauptzeit des Produkttyps ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]
A_22950 - Performance – FedMaster – Bearbeitungszeit unter Last
Der Produkttyp Federation Master MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_FedMaster erfüllen.
Es wird davon ausgegangen, dass der Federation Master eingeschwungen ist und z.B. Verbindungen nicht neu ausgehandelt werden.
Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 10 Anfragen pro Sekunde zu erbringen.
Tabelle 22: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben
|
ID
|
Anwendungsfälle
|
Lastvorgaben
|
Bearbeitungszeitvorgaben
|
|
Spitzenlast [1/sec] |
Maximalwert [msec] |
||
| FEDM.UC_1 |
get_IDP_list (Internet) |
10
|
20000
|
| FEDM.UC_2 |
fetchEntityStatement (Internet) |
10
|
20000
|
Die Duration für FEDM.UC_1 beginnt mit der Annahme der getIDP_list-Anfrage und endet mit der Lieferung der IDP-Liste als Antwort zum Fachdienst.
Die Duration für FEDM.UC_2 beginnt mit der Annahme der fetchEntityStatement-Anfrage und endet mit der Lieferung der StatementResponse als Antwort zum IDP.
Es ist eine ausreichend großzügige Performance-Vorgabe von 20 Sekunden als Antwortzeit vorgegeben, jedoch darf diese in keinem Fall überschritten werden. Eine Quantil-Schranke wird nicht gewährt.
[<=]
3.5.2 Rohdaten-Performance-Reporting Spezifika IDP-Federation Master
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.5.2.1 Spezifika Umfang IDP-Federation Master
3.5.2.2 Spezifika Format IDP-Federation Master
A_23386 - Performance - Rohdaten - Spezifika FedM - Operation (Rohdatenerfassung v.02)
Der Anbieter des Federation Master MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe aus der Tabelle 'Tab_gemSpec_Perf_FedMaster' in der Spalte "ID" verwenden.
A_23489 - Performance - Rohdaten - Spezifika FedM - Duration (Rohdatenerfassung v.02)
Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die konkretisierenden Hinweise unter der
Tabelle Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben berücksichtigen. [<=]
A_23387 - Performance - Rohdaten - Spezifika FedM - Message (Rohdatenerfassung v.02)
Der Anbieter des Federation Masters MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"-Felder - den Useragent im JSON-Format übermitteln:
{"UA":"$requesting_party"}
Für $requesting_party ist MemberID des entsprechend registrierten IDP oder Fachdienst einzutragen.
Hinweis:
Die MemberID wird durch die gematik vergeben.
[<=]
3.6 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.
3.6.1 Leistungsanforderungen VPN-Zugangsdienst
3.6.1.1 Lastmodell VPN-Zugangsdienst
Keine spezifischen Anforderungen zum Lastmodell.
3.6.1.2 Bearbeitungszeiten VPN-Zugangsdienst
Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:
[GS-A_4162 - Performance – Namensdienst – Bearbeitungszeit unter Last]
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.
[<=]3.6.1.3 Performancevorgaben VPN-Zugangsdienst
Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:
[GS-A_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit]
[GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen]
[GS-A_4155 - Performance – zentrale Dienste – Verfügbarkeit]
Für die Schnittstelle I_NTP_Time_Information gelten die folgenden Anforderungen:
[GS-A_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit]
[GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen]
[GS-A_4163 - Performance – Zeitdienst – Durchsatz]
A_24814 - Performance - VPN Zugangsdienst - Verfügbarkeit I_NTP_Time_Information
Der Produkttyp VPN-Zugangsdienst MUSS eine Verfügbarkeit von 99 % mit einer maximalen Ausfalldauer von 24 Stunden für die Schnittstelle I_NTP_Time_Information haben. [<=]
Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:
GS-A_4170-01 - Performance – VPN-Zugangsdienst – Bandbreite
Der VPN-Zugangsdienst MUSS eine Anbindungsbandbreite an das zentrale Netz mit der folgenden Eigenschaft bereitstellen:
- mindestens eine symmetrische Bandbreitenanbindung von 100 Mbit/sec
[<=]
A_23610 - Performance – VPN-Zugangsdienst – Bandbreite - VPN-Konzentratoren
Der VPN-Zugangsdienst MUSS eine Anbindungsbandbreite ab VPN-Konzentrator in das interne Netz mit folgenden Eigenschaften bereitstellen:
- mindestens eine Bandbreitenanbindung der "Summe aus der Spitzenlastsumme gemäß Tab_gemSpec_Perf_Netzlast_1" mal Anzahl der registrierten und diesem Standort zugeordneten Konnektoren geteilt durch Gesamtanzahl der Konnektoren gemäß gemSpec_Perf#M21.
[<=]
GS-A_5510 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS
Der Produkttyp VPN-Zugangsdienst MUSS eine Anbindung zum Transportnetz von mindestens 1 Gbit/sec pro 10000 Konnektoren besitzen.
Die VPN-Konzentratoren für SIS und TI MÜSSEN einen IPSec-Durchsatz unterstützten, der sich aus der Transportnetzanbindung ergibt.
[<=]
GS-A_5545 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS Konfigurationseinstellungen
Der Produkttyp VPN-Zugangsdienst DARF den IPSec-Durchsatz der VPN-Konzentratoren pro Konnektor NICHT durch Konfigurationseinstellungen reduzieren.
[<=]Die Anforderung [GS-A_4155 - Performance – zentrale Dienste – Verfügbarkeit] 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.
Wie die Volumenmessungen zu erfolgen hat, regelt die nachfolgende 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.
[<=]Weitere Anforderungen:
[GS-A_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit]
[GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen]
[GS-A_4155 - Performance – zentrale Dienste – Verfügbarkeit]
3.6.2 Rohdaten-Performance-Reporting Spezifika VPN-Zugangsdienst
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.6.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.6.2.2 Format
A_23911 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Status (Rohdatenerfassung v.02)
Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Fehlercodes_VPN-ZugD berücksichtigen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
[<=]
Tabelle 23: Tab_gemSpec_Perf_Fehlercodes_VPN-ZugD
| Statuscode | Returncode | Definition | Beschreibung | Bewertung |
|---|---|---|---|---|
| 78000 | 0 | NoError | NoError | SUCCESS |
| 78001 | 1 | FormErr | Format Error | FAILED_OTHER |
| 78002 | 2 | ServFail | Server Failure | FAILED_SERVICE |
| 78003 | 3 | NXDomain | Non-Existent Domain | FAILED_OTHER |
| 78004 | 4 | NotImp | Not Implemented | FAILED_OTHER |
| 78005 | 5 | Refused | Query Refused | FAILED_OTHER |
| 78006 | 6 | YXDomain | Name Exists when it should not | FAILED_OTHER |
| 78007 | 7 | YXRRSet | RR Set Exists when it should not | FAILED_OTHER |
| 78008 | 8 | NXRRSet | RR Set that should exist does not | FAILED_OTHER |
| 78009 | 9 | NotAuth | Server Not Authoritative for zone | FAILED_OTHER |
| 78010 | 9 | NotAuth | Not Authorized | FAILED_OTHER |
| 78011 | 10 | NotZone | Name not contained in zone | FAILED_OTHER |
| 78012 | 11 | DSOTYPENI | DSO-TYPE Not Implemented | FAILED_OTHER |
| 78013 | 16 | BADVERS | Bad OPT Version | FAILED_OTHER |
| 78014 | 16 | BADSIG | TSIG Signature Failure | FAILED_OTHER |
| 78015 | 17 | BADKEY | Key not recognized | FAILED_OTHER |
| 78016 | 18 | BADTIME | Signature out of time window | FAILED_OTHER |
| 78017 | 19 | BADMODE | Bad TKEY Mode | FAILED_OTHER |
| 78018 | 20 | BADNAME | Duplicate key name | FAILED_OTHER |
| 78019 | 21 | BADALG | Algorithm not supported | FAILED_OTHER |
| 78020 | 22 | BADTRUNC | Bad Truncation | FAILED_OTHER |
| 78021 | 23 | BADCOOKIE | Bad/missing Server Cookie | FAILED_OTHER |
A_23222 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Operation (Rohdatenerfassung v.02)
Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD berücksichtigen. [<=]
A_23221-01 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Duration (Rohdatenerfassung v.02)
Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten den Wert des "duration_in_ms"-Feldes in folgender Weise berücksichtigen:
Bei Aufruf der Operation beginnt die Messung mit Annahme der Aufrufnachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht.
[<=]
A_23220-02 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Message (Rohdatenerfassung v.02)
Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "cn": "$commonName", "sn": "$serialNumber", "o": "$organizationName", "c": "$countryName", "ip" : "$IP-Address", "s" : "$source" }
- $commonName = Feld <subject:commonName> gemäß gemSpec_PKI#Tab_PKI_245 (FQDN des Zugangsdienstes)
- $serialNumber = Feld <subject:serialNumber> gemäß gemSpec_PKI#Tab_PKI_245 (Seriennummer zur Unterscheidung gleichartiger Instanzen)
- $organizationName = Feld <subject:organizationName> gemäß gemSpec_PKI#Tab_PKI_245 (Name des Zugangsdienstanbieters)
- $countryName = Feld <subject:countryName> gemäß gemSpec_PKI#Tab_PKI_245 (Land der Anschrift des Zugangsdienstanbieters)
- $IP-Address = IP-Adresse der bearbeitenden Fachdienstinstanz
- $source = Quellregion des Operationsaufrufs
Für die jeweilige Operation sind dabei nur die in der Spalte "Message" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD angegebenen Key-Value Paare zu übermitteln.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden.
[<=]
Tabelle 24: Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD
| Operation / Usecase | Schnittstellenaufruf | Message |
|---|---|---|
| VPN.UC_1 | I_DNS_Name_Resolution::get_IP_Address | { "ip" : "$IP-Address", "s" :"$source" }
|
| VPN.UC_2 | I_NTP_Time_Information::receive | { "ip" : "$IP-Address" }
|
| VPN.UC_3 | I_Registration_Service::registerKonnektor | { "ip" : "$IP-Address" }
|
| VPN.UC_4 | I_Registration_Service::deregisterKonnektor | { "ip" : "$IP-Address" }
|
| VPN.UC_5 | I_Secure_Channel_Tunnel::connect | { "cn": "$commonName", "sn": "$serialNumber", "o": "$organizationName", "c": "$countryName" } Definierte Unterelemente aus Feld <subject> von C.VPNK.VPN |
| VPN.UC_6 | I_Secure_Channel_Tunnel::disconnect | { "cn": "$commonName", "sn": "$serialNumber", "o": "$organizationName", "c": "$countryName" } Definierte Unterelemente aus Feld <subject> von C.VPNK.VPN |
3.6.3 Bestandsdaten VPN-Zugangsdienst
A_23497 - Performance - Spezifika VPN-Zugangsdienst - Bestandsdaten
Der Anbieter VPN-Zugangsdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den VPN-Zugangsdienst pro Standort berichten:
- übertragene Datenmenge in beide Richtungen am SZZP pro Standort
- Anzahl der registrierten Konnektoren gesamt
- Anzahl aktiver Verbindungen pro Standort
[<=]
A_23498 - Performance - Spezifika VPN-Zugangsdienst - Lieferweg und Format für Bestandsdaten
Der Anbieter VPN-Zugangsdienst MUSS die Informationen aus pro Standort, jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format an die Betriebsdatenerfassung (BDE)
gemäß [gemSpec_SST_LD_BD::] liefern:
{
"ci": "<CI ID der logischen Produktinstanz des VPN-Zugangsdienstes gemäß TI-ITSM als String>",
"szzp": "<SZZP_ID des VPN-Zugangsdienstes als String>",
"timestamp": "<Zeitstempel der Abfrage als String im ISO 8601 Format als String>",
"numKon": <Gesamtanzahl der registrierten Konnektoren pro obiger CI ID zum Abfragezeitpunkt als Integer>,
"numVPN": <Gesamtanzahl der bestehenden VPN-Tunnel pro obiger SZZP_ID zum Abfragezeitpunkt als Integer>,
"start": "<Startzeitstempel des Berichtsintervall im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
startend mit 00:00 Uhr UTC als geschlossener Intervallanfang, d.h. t_Messung ist größer GLEICH diesem Wert>",
"stop": "<Stopzeitstempel des Berichtsintervalls im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
startend mit 00:05 Uhr UTC als offenes Intervallende, d.h. t_Messung ist kleiner diesem Wert>",
"kbIn": <Datenmenge empfangen in Kilobyte an obiger SZZP_ID im oben definierten Berichtsintervall als Integer>,
"kbOut": <Datenmenge gesendet in Kilobyte an obiger SZZP_ID im oben definierten Berichtsintervall als Integer>
3.7 NCPeH-Fachdienst
Im folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des NCPeH-Fachdienstes (National Contact Point for eHealth) aufgeführt.
3.7.1 Leistungsanforderungen NCPeH-Fachdienst
3.7.1.1 Lastmodell NCPeH-Fachdienst
Es werden keine Vorgaben zum Lastmodell des NCPeH-Fachdienstes getroffen.
3.7.1.2 Bearbeitungszeiten NCPeH-Fachdienst
A_23067 - Performance - NCPeH-Fachdienst - Messung von Bearbeitungszeiten
Der NCPeH-Fachdienst MUSS die folgenden Bedingungen einhalten:
Vorbedingungen für die Messungen
Es wird davon ausgegangen, dass nach einem Login-Prozess alle Verbindungsaufbauten erfolgten und zugehörige OCSP-Statusauskünfte im OCSP-Cache vorliegen.
Rahmenbedingungen für die Messung
Die dem NCPeH-Fachdienst zugerechneten Bearbeitungszeiten für die entsprechende Schnittstelle ist die Zeitspanne vom vollständigen Empfang eines Requests bis zum vollständigen Ausgang der zugehörigen Response.
Die dem NCPeH-Fachdienst zugerechneten Bearbeitungszeiten für die Schnittstelle FindIdentityByTrait sind die Antwortzeiten für einen Request-Response Zyklus. Hierbei muss das Warten auf die erfolgreiche Nutzerinteraktion (ad-hoc Berechtigung) rausgerechnet werden.
[<=]
A_23016 - Performance - NCPeH-Fachdienst - Last- und Bearbeitungszeiten
Der NCPeH-Fachdienst SOLL die Bearbeitungszeitrichtwerte unter Last aus Tabelle "Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.
Tabelle 25 Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben
| UseCase-Bezug |
Fachdienstoperation |
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|
| NCPeH.UC_1 |
FindIdentityByTrait |
5 |
300 |
500 |
| NCPeH.UC_2 |
FindDocuments |
5 |
300 |
500 |
| NCPeH.UC_3 | RetrieveDocument | 5 | 350 | 550 |
| NCPeH.UC_4 | RetrieveDocumentPDF | 5 | 350 | 550 |
| NCPeH.UC_8 | InitializeEpaSession | 5 | 7.700 | 10.000 |
Die Zeitmessung beginnt mit dem letzten Bit eines eingehenden Schnittstellenaufrufes und endet mit dem ersten Bit der versendeten Antwort an den Absender.
3.7.1.3 Performancevorgaben NCPeH-Fachdienst
A_22979 - Performance - NCPeH-Fachdienst - Verfügbarkeit
Der Betreiber des NCPeH-Fachdienstes MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.
Wartungsfenster MÜSSEN vollständig in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.
Die Anschlüsse aller Standorte an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen. [<=]
A_23017 - Performance - NCPeH-Fachdienst - Skalierung
Der Betreiber des NCPeH-Fachdienstes MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]
Im Zuge der Testaktivitäten hat der Betreiber des NCPeH-Fachdienstes 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.
3.7.2 Rohdaten-Performance-Reporting Spezifika NCPeH-Fachdienst
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.7.2.1 Umfang
Es werden keine speziellen Anforderungen zum Umfang der Rohdatenlieferung getroffen.
3.7.2.2 Format
A_23011 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Operation (Rohdatenerfassung v.02)
Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_NCPeH berücksichtigen. [<=]
Tabelle 26: Tab_gemSpec_Perf_Berichtsformat_NCPeH
| UseCase | Operation |
Beschreibung |
|---|---|---|
| NCPeH.UC_1 | Cross_Gateway_Patient_Discovery::findIdentityByTraits | Abfrage aus dem EU-Ausland zur Authentifizierung eines Versicherten |
| NCPeH.UC_2 | Cross_Gateway_Query::FindDocuments | Abfrage aus dem EU-Ausland zur Auflistung der verfügbaren Dokumente eines Versicherten |
| NCPeH.UC_3 | Cross_Gateway_Retrieve::RetrieveDocument | Abfrage aus dem EU-Ausland zum Download des ausgewählten Dokuments eines Versicherten |
| NCPeH.UC_4 | Cross_Gateway_Retrieve::RetrieveDocumentPDF | Abfrage aus dem EU-Ausland zum Download des ausgewählten Dokuments eines Versicherten im Format PDF |
A_23012 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Duration (Rohdatenerfassung v.02)
Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]
A_23013 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung des Usecase ein Fehler aufgetreten ist, MUSS der NCPeH-Fachdienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gemäß Kapitel 6.4 "eHealth DSI Error Codes" [NCPeH Components Specifications], Table 2-4 festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden und das Feld "eCode" im message-Block mit der Fehleridentifikation befüllt werden. [<=]
A_23118-01 - Performance - Rohdaten - Spezifika NCPeH-Fachdienst - Message (Rohdatenerfassung v.02)
Der NCPeH-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.
{ "reqc": "$requestingCountry", "ecode": "$errorCode" }
- requestingCountry: Zeichenkette zur Identifikation des anfragenden NCPeHs eines EU-Mitgliedsstaates im Format ISO 3166-1 Alpha 2, Datentyp String.
- errorCode: Zeichenkette zur Identifikation der Fehlermeldung aus dem Response-Body. Datentyp String. Inhalt:
- des Feldes "Code" aus der Struktur "AcknowledgementDetail" für XCPD.
- des Feldes "errorCode" aus der Struktur "RegistryError" für XCA.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und die Spezifikation [RFC7493] eingehalten wird. [<=]
Die Aussagefähigkeit der gelieferten Daten zur Betriebsdatenerfassung des NCPeH wird im Betrieb in regelmäßigen Abständen vom Gesamtverantwortlichen TI validiert und in Abstimmung mit dem Anbieter gegebenenfalls überarbeitet und aktualisiert.
3.8 Signaturdienst (SigD)
Im folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des Signaturdienstes aufgeführt.
3.8.1 Leistungsanforderungen SigD
3.8.1.1 Lastmodell SigD
[Sind im Folgekapitel "Performancevorgaben SigD" enthalten.]
3.8.1.2 Bearbeitungszeiten SigD
[Sind im Folgekapitel "Performancevorgaben SigD" enthalten.]
3.8.1.3 Performancevorgaben SigD
A_18018-01 - Performance - Signaturdienst - Spitzenlastvorgaben
Der Anbieter Signaturdienst MUSS das System so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle Tab_gemSpec_Perf_Signaturdienst: Last- und Bearbeitungszeitvorgaben erfüllt wird. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl der gesetzlich Versicherten.
Tabelle 27: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben
| UseCase-Bezug |
Fachdienstoperation |
Spitzenlast [1/sec] |
Mittelwert [msec] |
Maximalwert [msec] |
|---|---|---|---|---|
| SigD.sign_Data |
I_Remote_Sign_Operations |
100 * (MA + 0.05) |
150 |
500 |
| SigD.get_Certificate |
I_Remote_Get_Certificate |
100 * (MA +0.05) |
150 |
500 |
Hinweis:
Der Anbieter muss für seinen Marktanteil das System so dimensionieren, dass die Lastvorgaben am Signaturdienst eingehalten werden.
Beispielrechnung:
Bei einem Marktanteil von 20% muss für die Operation "I_Remote_Sign_Operations:sign_Data" eine Lastvorgabe von mindestens 25 Anfragen pro Sekunde eingehalten werden (20% von 100 Anfragen pro Sekunde plus 5% Grundlast).
MA ist der Marktanteil des Anbieters gemäß [A_22225]. [<=]
A_17802 - Performance – Signaturdienst – Bearbeitungszeit unter Last
Der Produkttyp Signaturdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Signaturdienst erfüllen.
[<=]Ebenfalls gelten folgende Anforderungen:
[GS-A_4155 - Verfügbarkeit, Wartungsfenster, HZ/NZ]
[GS-A_3055 - Skalierbarkeit Rollout]
[GS-A_3058 - Skalierbarkeit Betrieb]
[GS-A_4145 - Robustheit bei Lastspitzen]
3.8.2 Rohdaten-Performance-Reporting Spezifika SigD
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.8.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.8.2.2 Format
A_22476 - Performance - Rohdaten - Spezifika SigD - Duration (Rohdatenerfassung v.02)
Der Produkttyp Signaturdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_SigD berücksichtigen. [<=]
A_22478 - Performance - Rohdaten - Spezifika SigD - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation ein Fehler aufgetreten ist, MUSS der Produkttyp Signaturdienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_SigD festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
Tabelle 28: Tab_gemSpec_Perf_Fehlercodes_SigD
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 79001 |
OCSP_ERROR_NO_RESPONSE |
Keine Antwort des OCSP oder Timeout |
| 79879 |
OCSP_ERROR_WRONG_SIGNATURE |
Falsche oder fehlende Signatur in der OCSP-Antwort |
| 79875 |
OCSP_ERROR_WRONG_DATA |
Format der OCSP-Anfrage fehlerhaft |
| 79881 |
OCSP_ERROR_INVALID_RESPONSE |
Antwort des OCSP fehlerhaft |
| 79873 |
OCSP_CERT_MISSING |
OCSP-Zertifikat nicht in TSL enthalten |
A_22479 - Performance - Rohdaten - Spezifika SigD - Message (Rohdatenerfassung v.02)
Der Produkttyp Signaturdienst DARF bzgl. des "message"-Feldes KEINE Inhalte übermitteln. [<=]
A_22477-01 - Performance - Rohdaten - Spezifika SigD - Operation (Rohdatenerfassung v.02)
Der Produkttyp Signaturdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der Felder "Operation" und "Duration" die Angaben der Tabelle Tab_gemSpec_Perf_Berichtsformat_SigD berücksichtigen.
Tabelle 29: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD
| Operation |
Duration |
|---|---|
| SigD.sign_Data |
Bei Aufruf der Operation sign_Data beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client. |
| SigD.get_Certificate | Bei Aufruf der Operation get_Certificate beginnt die Messung mit Annahme der Aufforderung zur Lieferung an der Außenschnittstelle des Produkttyps und endet mit der Lieferung des Signaturzertifikat C.CH.SIG des aufrufenden Nutzers (Identifier) an der Außenschnittstelle. |
3.9 Fachdienst KOM-LE
3.9.1 Leistungsanforderungen Fachdienst KOM-LE
3.9.1.1 Lastmodell Fachdienst 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.
Hinweis: In der Version KOM-LE 1.0 ist die Nachrichtengröße auf 15 MiB begrenzt. Ab KOM-LE 1.5 ist es auch möglich E-Mail-Nachrichten mit Anhängen größer 15 MiB zu versenden bzw. zu empfangen. Der Mail-Body ohne Anhänge darf aber weiterhin die Größe von 15 MiB nicht übersteigen und muss durch das KOM-LE-Clientmodul und den KOM-LE-Fachdienst verarbeitet werden.
A_20135 - Performance - KOM-LE-Fachdienst - Skalierung
Der Anbieter KOM-LE-Fachdienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]
Im Zuge des Zulassungsverfahrens hat der Anbieter Fachdienst KOM-LE dem Gesamtverantwortlichen TI 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_20129 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben
Der Anbieter KOM-LE-Fachdienst MUSS das System so dimensionieren, dass für seine Nutzer der erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben" erfüllt werden. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl aller KOM-LE-Teilnehmer.
[<=]
Zur Erläuterung zu [A_20129]:
Der Anbieter muss die Anzahl seiner KOM-LE-Teilnehmer kennen und sein System mindestens so dimensionieren, damit die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KOM-LE-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).
Tabelle 30: 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 |
A_20127-01 - Performance - KOM-LE-Fachdienst – Spitzenlastvorgaben für den KAS
Der Anbieter KOM-LE-Fachdienst MUSS den KAS und die Anbindung an das zentrale Netz der TI mindestens so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS" erfüllt wird.
Die Lastvorgaben sind für die vom Anbieter definierte maximale Größe der Zulässigen 20 MiB Anhänge zu erfüllen
Tabelle 31: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS
| Schnittstellenoperationen | Spitzenlast [1/sec] |
|---|---|
| I_Attachment_Service::add_Attachment | 5 |
| I_Attachment_Service::read_Attachment | 5 |
A_20134 - Performance - KOM-LE-Fachdienst - Robustheit gegenüber Lastspitzen
Der KOM-LE Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus den Tabellen:
- "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben",
- "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS" verfügbar bleibt
Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der KOM-LE-Fachdienst 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 hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.
A_20132 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben TU
Der Anbieter KOM-LE MUSS in der TU-Umgebung 5% der in den folgenden Tabellen:
- "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben",
- "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS"
Ist der Marktanteil kleiner als 5% (10.500 KOM-LE-Teilnehmer) MUSS der Anbieter des KOM-LE-FAchdienstes nur den entsprechenden Prozentwert seines Marktanteils in der TU bereitstellen. Der Prozentwert MUSS mit angegeben werden. [<=]
3.9.1.2 Bearbeitungszeiten Fachdienst KOM-LE
Für den Fachdienst KOM-LE müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall" angegebenen Mittelwerten sein.
Tabelle 32: Tab_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 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.
3.9.1.3 Performancevorgaben Fachdienst KOM-LE
GS-A_5139-02 - Performance – KOM-LE-Fachdienst – Verfügbarkeit
Der Produkttyp Fachdienst KOM-LE MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:
- Hauptzeit: 99,80%
- Nebenzeit: 99,00%
GS-A_5143-01 - Performance – KOM-LE-Fachdienst – Nachricht senden
Der KOM-LE-Fachdienst MUSS die vom KOM-LE-Clientmodul empfangenen E-Mails zeitnah an den KOM-LE-Fachdienst des E-Mail-Empfängers weiterleiten.
Der KOM-LE-Fachdienst des E-Mail-Senders MUSS sicherstellen, dass der Zeitraum zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE-Clientmodul an den KOM-LE-Fachdienst des E-Mail-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE-Fachdienst des E-Mail-Empfängers kleiner 10 Minuten ist.
[<=]
A_24042 - Performance - KOM-LE Fachdienst - Nachrichtenversand binnen 10 Minuten
Der Produkttyp Fachdienst KOM-LE MUSS auch über Ausfälle hinweg gewährleisten, dass Nachrichten spätestens 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen. [<=]
GS-A_5138-02 - Performance – KOM-LE-Fachdienst – TLS-Verbindungsaufbau unter Last
Der Produkttyp Fachdienst KOM-LE MUSS erreichen, dass der TLS-Verbindungsaufbau, unter der für diesen Anwendungsfall gemäß Tabelle Tab_gemSpec_Perf_KOMLE_Fachdienst anliegenden Spitzenlast, im Mittel innerhalb von 3,9 Sekunden abgeschlossen wird. [<=]
Zu [GS-A_5138-02]:
Der Anbieter muss die Anzahl seiner KOM-LE-Teilnehmer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KOM-LE-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Spitzenlast von 41 Anfragen pro Sekunde mit einer mittleren Bearbeitungszeit von 3,9 Sekunden für den Aufbau des TLS-Kanals zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst. (5% von 820 Anfragen pro Sekunde).
Die Anforderung gilt für alle Server-Komponenten des KOM-LE-Fachdienstes (Mailserver, Account Manager und KAS).
A_20133 - Performance - KOM-LE-Fachdienst - Anbindungsbandbreite
Der Anbieter des KOM-LE-Fachdienstes MUSS die Bandbreite seiner Schnittstelle zum zentralen Netz der TI entsprechend der zu erwartenden Last auslegen. Die Auslastung der effektiven Bandbreite darf nicht dauerhaft über 90% der gewählten Anbindungsbandbreite liegen.
[<=]
3.9.2 Rohdaten-Performance-Reporting Spezifika Fachdienst KOM-LE
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.9.2.1 Umfang
Es existieren keine spezifischen Anforderungen zum Umfang der Rohdatenlieferung.
3.9.2.2 Format
A_23823 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Status (Rohdatenerfassung v.02)
Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "status" die Angabe der Spalte "$status" gemäß Tab_gemSpec_Perf_Berichtsformat_KIM_neu berücksichtigen. [<=]
A_23168 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Operation/Duration (Rohdatenerfassung v.02)
Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten die Inhalte der Felder "$operation" und "$duration_in_ms" nach den Vorgaben der Tabelle Tab_gemSpec_Perf_Berichtsformat_KIM befüllen. [<=]
Tabelle 33: Tab_gemSpec_Perf_Berichtsformat_KIM
| $operation |
Schnittstellenaufruf |
$status | $duration_in_ms |
|---|---|---|---|
| KIM.UC_1 | I_Message_Service::send_Message | SMTP-Statuscode | Bei Aufruf der Operation send_Message beginnt die Messung mit dem Zeitpunkt der quittierten Übergabe der Nachricht vom KIM Clientmodul an den KIM Fachdienst des E-Mail-Senders und endet mit dem Zeitpunkt der quittierten Übergabe an den KIM Fachdienst des E-Mail-Empfängers. |
| KIM.UC_2 | I_Message_Service::receive_Message | POP3-Statuscode | Bei Aufruf der Operation receive_Message beginnt die Messung mit dem Zeitpunkt der Annahme der Operation an der Außenschnittstelle des Produkttyps und endet mit dem Zeitpunkt der quittierten Übergabe der Nachricht an das KIM Clientmodul des E-Mail-Empfängers. |
| KIM.UC_3 |
I_Attachment_Service::add_Attachment | HTTP-Statuscode | Bei Aufruf der Operation add_Attachment beginnt die Messung mit Annahme der E-Mail-Daten an der Außenschnittstelle des Produkttyps und endet mit dem quittierten Versand der Antwort an der Außenschnittstelle zum KIM Clientmodul. |
| KIM.UC_4 | I_Attachment_Service::read_Attachment | HTTP-Statuscode | Bei Aufruf der Operation read_Attachment beginnt die Messung mit der Anfrage des KIM Clientmoduls an der Außenschnittstelle des Produkttyps und endet mit dem quittierten Ende des Versands der E-Mail-Daten. |
A_23167 - Performance - Rohdaten - Spezifika Fachdienst KOM-LE - Message (Rohdatenerfassung v.02)
Der Produkttyp Fachdienst KOM-LE MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.
{ "mid": "$messageid", "size": "$size", "err": "$fehlermeldung", "dir": "$direction", "sys": "$senderName", "sysv": "$senderVersion", "dka": "$dienstAnw", "dkt": "$dienstTyp","dkv": "$dienstVer","cmn": "$cmName", "cmv": "$cmVersion", "cptv": "$cmPTVersion", "ksize": "$kasSize", "konpn": "$konProductName","konpt": "$konProductType","konptv": "$konProductTypeVersion","konhw": "$konHWVersion","konfw": "$konFWVersion" }
Diese message-Felder MÜSSEN immer mitgegeben werden:
- messageid: <Message-ID> Zeichenkette zur Identifikation der KIM Nachricht, Datentyp String
- size: <Request Size> Größe des Requests in kilobyte, Datentyp Integer
- fehlermeldung: <X-KIM-Fehlermeldung> nach A_20771-01, Datentyp String
- direction: <Direction> Entweder "CM" für die Kommunikation mit einem Clientmodul (CM) ODER "FD" für die Kommunikation zwischen Fachdiensten, Datentyp String
- senderName: <X-KIM-Sendersystem:PS-Name> Name des Sendersystems, Datentyp String
- senderVersion: <X-KIM-Sendersystem:PS-Version> Version des Sendersystems, Datentyp String
- dienstAnw: <X-KIM-Dienstkennung:Anwendung> Name der Anwendung zur Dienstkennung, Datentyp String
- dienstTyp: <X-KIM-Dienstkennung:Nachrichten-Typ> Nachrichten-Typ zur Dienstkennung, Datentyp String
- dienstVer: <X-KIM-Dienstkennung:Anwendungsversion> Anwendungsversion zur Dienstkennung, Datentyp String
- cmName: <X-KIM-CMVersion:Name> Name des eingesetzten KOM-LE Clientmoduls, Datentyp String
- cmVersion: <X-KIM-CMVersion:Version> Version des eingesetzten KOM-LE Clientmoduls, Datentyp String
- cmPTVersion: <X-KIM-PTVersion> Produkttyp-Version des eingesetzten KOM-LE Clientmoduls, Datentyp String
- kasSize: <X-KIM-KAS-Size> Größe der KOM-LE-Nachricht in kilobyte, Datentyp Integer
- konProductName: <X-KIM-KONVersion:Productname> nach A_21388-01, Datentyp String
- konProductType: <X-KIM-KONVersion:ProductType> nach A_21388-01, Datentyp String
- konProductTypeVersion: <X-KIM-KONVersion:ProductTypeVersion> nach A_21388-01, Datentyp String
- konHWVersion: <X-KIM-KONVersion:HWVersion> nach A_21388-01, Datentyp String
- konFWVersion: <X-KIM-KONVersion:FWVersion> nach A_21388-01, Datentyp String
[<=]
Metadatenbeispiel für eine Clientmodul-Kommunikation und Rohdatenlieferung des message-Blockes:
{ "mid": "$messageid", "size": "$size", "err": "$fehlermeldung", "dir": "$direction", "sys": "$senderName", "sysv": "$senderVersion", "dka": "$dienstAnw", "dkt": "$dienstTyp","dkv": "$dienstVer","cmn": "$cmName", "cmv": "$cmVersion", "cptv": "$cmPTVersion", "ksize": "$kasSize", "konpn": "$konProductName","konpt": "$konProductType","konptv": "$konProductTypeVersion","konhw": "$konHWVersion","konfw": "$konFWVersion" }
Metadatenbeispiel für eine Fachdienst zu Fachdienst-Kommunikation und Rohdatenlieferung des message-Blockes:
{ "mid": "$messageid", "size": "$size", "err": "$fehlermeldung", "dir": "$direction" }
3.10 TI-Gateway
3.10.1 Leistungsanforderungen TI-Gateway
3.10.1.1 Lastmodell TI-Gateway
Keine spezifischen Anforderungen zum Lastmodell.
3.10.1.2 Bearbeitungszeiten TI-Gateway
Keine spezifischen Anforderungen zu Bearbeitungszeiten.
3.10.1.3 Performancevorgaben TI-Gateway
GS-A_5545-01 - Performance – TI-Gateway-Zugangsmodul – VPN Konfigurationseinstellungen
Der Produkttyp TI-Gateway-Zugangsmodul KANN den VPN-Durchsatz pro Leistungserbringerumgebung auf die vertraglich vereinbarte Bandbreite reduzieren. [<=]
A_23431-01 - Performance – TI-Gateway – Verfügbarkeit
Der Anbieter TI-Gateway MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:
- Hauptzeit: 99,90 %
- Nebenzeit: 99,00 %
Messung der Verfügbarkeit:
Die Messung könnte z.B. durch eine lokale Softwarekomponente des Zugangsmoduls erfolgen. Für Testaufrufe muss sich eine solche Probe authentifizieren und korrekte Context-Parameter verwenden.
A_23433-01 - Performance - TI-Gateway - Skalierung
Der Anbieter für das TI-Gateway MUSS für seine Produkttypen skalierbar sein.
Diese Skalierbarkeit ist durch den Anbieter nachvollziehbar darzustellen, wie die Skalierung im Produktivbetrieb erreicht wird.
[<=]
Im Zuge des Zulassungsverfahrens hat der Anbieter des TI-Gateways 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.
3.10.2 Rohdaten-Performance-Reporting Spezifika TI-Gateway
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.10.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.10.2.2 Format
A_23269 - Performance - Rohdaten - TI-Gateway-Zugangsmodul - Duration (Rohdatenerfassung v.02)
Der Produkttyp TI-Gateway-Zugangsmodul MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul berücksichtigen. [<=]
A_23270 - Performance - Rohdaten - TI-Gateway-Zugangsmodul - Operation (Rohdatenerfassung v.02)
Der Produkttyp TI-Gateway-Zugangsmodul MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul berücksichtigen. [<=]
Tabelle 34: Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul
| Operation / Usecase | Schnittstellenaufruf |
Duration |
|---|---|---|
| TIG.I_1 | I_Secure_Channel_Tunnel::connect |
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. |
| TIG.I_2 | I_Secure_Channel_Tunnel::disconnect |
-''- |
3.10.3 Bestandsdaten TI-Gateway
A_23988-01 - Performance - Spezifika TI-Gateway - Bestandsdaten
Der Anbieter TI-Gateway MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über das TI-Gateway berichten:
- Anzahl der registrierten Highspeed-Konnektor Instanzen gesamt
- Anzahl aktiver Verbindungen
- Anzahl gesperrter Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat)
A_23989-01 - Performance - Spezifika TI-Gateway - Lieferweg und Format für Bestandsdaten
Der Anbieter TI-Gateway MUSS die Informationen aus ,
jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format an die Betriebsdatenerfassung (BDE)
gemäß [gemSpec_SST_LD_BD::] liefern:
{
"ci": "<CI ID der logischen Produktinstanz des TI-Gateway-Zugangsmodul gemäß TI-ITSM als String>",
"timestamp": "<Zeitstempel der Abfrage als String im ISO 8601 Format als String>",
"numHSKInst": <Gesamtanzahl der registrierten Highspeed-Konnektor Instanzen pro obiger CI ID zum Abfragezeitpunkt als Integer>,
"numVPN": <Gesamtanzahl der bestehenden VPN-Tunnel zum Abfragezeitpunkt als Integer>,
"numLockAccess":<Gesamtanzahl gesperrter Zugänge aufgrund nicht gültigen C.HCI.AUT (SM-B-AUT-Zertifikat) zum Abfragezeitpunkt als Integer>,
"start": "<Startzeitstempel des Berichtsintervall im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
startend mit 00:00 Uhr UTC als geschlossener Intervallanfang, d.h. t_Messung ist größer GLEICH diesem Wert>",
"stop": "<Stopzeitstempel des Berichtsintervalls im ISO 8601 Format in UTC im Schema YYYY-MM-DDThh:mmZ als String,
startend mit 00:05 Uhr UTC als offenes Intervallende, d.h. t_Messung ist kleiner diesem Wert>"
} [<=]
3.11 Namensdienst
Im Folgenden werden die produkttypspezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Reporting des Namensdienst aufgeführt.
3.11.1 Leistungsanforderungen Namensdienst
3.11.1.1 Lastmodell Namensdienst
Keine spezifischen Anforderungen zum Lastmodell.
3.11.1.2 Bearbeitungszeiten 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.
[<=]
Tabelle 35: 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 |
200
|
60
|
120
|
| |
I_DNS_Name_Resolution |
|
|||
| |
|
get_IP_Address |
200
|
30
|
70
|
| |
|
get_FQDN |
400
|
30
|
70
|
3.11.1.3 Performancevorgaben Namensdienst
Es gelten die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.11.2 Rohdaten-Performance-Reporting Spezifika Namensdienst
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.11.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.11.2.2 Format
A_23436 - Performance - Rohdaten - Spezifika Namensdienst - Operation (Rohdatenerfassung v.02)
Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Namensdienst berücksichtigen. [<=]
A_23435 - Performance - Rohdaten - Spezifika Namensdienst - Duration (Rohdatenerfassung v.02)
Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des "duration_in_ms"-Feldes die Angabe der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Namensdienst berücksichtigen. [<=]
Tabelle 36: Tab_gemSpec_Perf_Berichtsformat_Namensdienst
| Operation / Usecase |
Duration |
|---|---|
| DNS.LOC |
Operation: I_DNS_Service_Localization - Die Messung beginnt mit jeder einzelnen Anfrage und endet mit der dazugehörigen versendeten Antwort. |
| DNS.GIP | Operation: I_DNS_Name_Resolution::get_IP_Address - Die Messung beginnt mit der Anfrage der Auflösung des FQDN und endet mit der Lieferung der IP-Adresse. |
A_23920 - Performance - Rohdaten - Spezifika Namensdienst - Message (Rohdatenerfassung v.02)
Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "ip": "$IP-Adresse" }
- $IP-Adresse = IP-Adresse der Instanz des Namensdienstes, Datentyp String
A_23921 - Performance - Rohdaten - Spezifika Namensdienst - Status (Rohdatenerfassung v.02)
Der Produkttyp Namensdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_Namensdienst berücksichtigen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 37: Tab_gemSpec_Perf_Statuscodes_Namensdienst
| Statuscode | Returncode | Definition | Beschreibung | Bewertung |
|---|---|---|---|---|
| 78000 | 0 | NoError | NoError | SUCCESS |
| 78001 | 1 | FormErr | Format Error | FAILED_OTHER |
| 78002 | 2 | ServFail | Server Failure | FAILED_SERVICE |
| 78003 | 3 | NXDomain | Non-Existent Domain | FAILED_OTHER |
| 78004 | 4 | NotImp | Not Implemented | FAILED_OTHER |
| 78005 | 5 | Refused | Query Refused | FAILED_OTHER |
| 78006 | 6 | YXDomain | Name Exists when it should not | FAILED_OTHER |
| 78007 | 7 | YXRRSet | RR Set Exists when it should not | FAILED_OTHER |
| 78008 | 8 | NXRRSet | RR Set that should exist does not | FAILED_OTHER |
| 78009 | 9 | NotAuth | Server Not Authoritative for zone | FAILED_OTHER |
| 78010 | 9 | NotAuth | Not Authorized | FAILED_OTHER |
| 78011 | 10 | NotZone | Name not contained in zone | FAILED_OTHER |
| 78012 | 11 | DSOTYPENI | DSO-TYPE Not Implemented | FAILED_OTHER |
| 78013 | 16 | BADVERS | Bad OPT Version | FAILED_OTHER |
| 78014 | 16 | BADSIG | TSIG Signature Failure | FAILED_OTHER |
| 78015 | 17 | BADKEY | Key not recognized | FAILED_OTHER |
| 78016 | 18 | BADTIME | Signature out of time window | FAILED_OTHER |
| 78017 | 19 | BADMODE | Bad TKEY Mode | FAILED_OTHER |
| 78018 | 20 | BADNAME | Duplicate key name | FAILED_OTHER |
| 78019 | 21 | BADALG | Algorithm not supported | FAILED_OTHER |
| 78020 | 22 | BADTRUNC | Bad Truncation | FAILED_OTHER |
| 78021 | 23 | BADCOOKIE | Bad/missing Server Cookie | FAILED_OTHER |
3.12 Intermediär VSDM
Im Folgenden werden die produkttypspezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Reporting des Intermediär VSDM aufgeführt.
3.12.1 Leistungsanforderungen Intermediär VSDM
3.12.1.1 Lastmodell Intermediär VSDM
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.
[<=]
3.12.1.2 Bearbeitungszeiten Intermediär VSDM
GS-A_5029-01 - Performance – VSDM Intermediär – Bearbeitungszeit unter Last
Der Produkttyp Intermediär MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Intermediaer erfüllen. Die dabei zu unterstützende Spitzenlast pro Sekunde berechnet sich aus der durch die VSDM-Intermediär-Instanz maximal zu unterstützende Anzahl an Leistungserbringern in Tausend multipliziert mit dem Faktor 5,35.
Die Vorgaben beziehen sich auf die einzelnen Request-Response-Zyklen. Sie beinhalten die Bearbeitungszeitbeiträge aus Request und Response in Summe. Es wird davon ausgegangen, dass der Intermediär eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.
Für die Zulassung ist der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.
Tabelle 38 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben
|
Bearbeitungszeitvorgaben
|
|
|---|---|
|
Mittelwert
[msec] |
95%-Quantil
[msec] |
|
100
|
150
|
3.12.1.3 Performancevorgaben Intermediär VSDM
GS-A_5030 - Performance – VSDM Intermediär – Verfügbarkeit
Der Produkttyp Intermediär MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.
Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
[<=]
A_20170 - Performance - Erfassung von Rohdaten - Intermediär VSDM
Der Intermediär VSDM MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM" erfassen und Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitinervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
[<=]
3.12.2 Rohdaten-Performance-Reporting Spezifika Intermediär VSDM
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.12.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.12.2.2 Format
A_23256 - Performance - Rohdaten - Spezifika Intermediär VSDM - Operation (Rohdatenerfassung v.02)
Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation / Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM berücksichtigen. [<=]
Tabelle 39: Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM
| Operation / Usecase |
Beschreibung |
|---|---|
| INT.UFS |
Operation: Intermediaer_VSDM.UFS |
| INT.VSD | Operation: Intermediaer_VSDM.VSD |
| INT.CMS | Operation: Intermediaer_VSDM.CMS |
A_23253 - Performance - Rohdaten - Spezifika Intermediär VSDM - Duration (Rohdatenerfassung v.02)
Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten des "duration_in_ms"-Feldes in folgender Weise berücksichtigen: Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Fachmodul, wird mit der Weiterleitung an den Fachdienst pausiert, läuft mit Erhalt der Antwort vom Fachdienst weiter und endet mit dem Versand der Antwort an das Fachmodul. [<=]
A_23750-01 - Performance - Rohdaten - Spezifika Intermediär VSDM - Message (Rohdatenerfassung v.02)
Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "vnum": $vorgangsnummer, "ik": "$InstanzKennung", "bkdur": $backendDuration }
- $vorgangsnummer = Vorgangsnummer gem. VSDM-A_2673 max. 12 Zeichen, Datentyp String
- $instanzKennung = Instanz-Kennung max. 8 Zeichen, Datentyp String
- $backendDuration = Zeit in ms, die mit der Weiterleitung der Nachricht an den Fachdienst beginnt und mit dem Erhalt der Antwort vom Fachdienst endet, Datentyp Integer
A_24070 - Performance - Rohdaten - Spezifika Intermediär VSDM - Status (Rohdatenerfassung v.02)
Der Produkttyp Intermediär VSDM MUSS bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes alle HTTP-Statuscodes, die vom Fachdienst generiert und vom Intermediär VSDM an das Fachmodul weitergeleitet werden, als SUCCESS bewerten.
Vom Intermediär VSDM selbst generierte Fehlermeldungen MÜSSEN gemäß A_22500-01 einen HTTP-Statuscode aus der Statuscodegruppe CLIENT_ERROR (HTTP-Statuscodes 4xx) oder SERVER_ERROR (HTTP-Statuscodes 5xx) verwenden und werden als FAILED_OTHER bewertet. [<=]
3.13 Trust Service Provider X.509 nonQES – Komponentenzertifikate
Im Folgenden werden die produkttypspezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Reporting des TSP-X.509nonQES aufgeführt.
3.13.1 Leistungsanforderungen TSP X.509 nonQES – Komp
3.13.1.1 Lastmodell TSP X.509 nonQES – Komp
Keine spezifischen Anforderungen zum Lastmodell.
3.13.1.2 Bearbeitungszeiten TSP X.509 nonQES – Komp
Sind im Folgekapitel "Performancevorgaben TSP X.509 nonQES - Komp" mit enthalten.
3.13.1.3 Performancevorgaben TSP X.509 nonQES – Komp
A_24326 - Performance - OCSP Responder der TSP X.509nQ - Komp - Grundlast
Der Produkttyp TSP-X.509 nonQES - Komp MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]
Tabelle 40: Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp
| Operation | Anwendungsfall |
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|
| TSPK.UC_1 | Prüfung von Konnektor-Zertifikaten aus der TI ( C.NK.VPN | C.AK.AUT | C.SAK.AUT) |
110 |
1.000 | 1.300 |
| TSPK.UC_2 | Prüfung von Konnektor-Zertifikaten über das Internet (C.NK.VPN | C.AK.AUT | C.SAK.AUT) | 45 | ||
| TSPK.UC_3 | Prüfung von VPN-Konzentratorzertifikaten durch Konnektoren über das Internet (C.VPNK.VPN | C.VPNK.VPN-SIS) |
45 |
||
| TSPK.UC_4 | Prüfung von TLS Zertifikaten der zentralen Dienste aus der TI (C.ZD.TLS | C.ZD.SIG) | 260 | ||
| TSPK.UC_5 | Prüfung von Zertifikaten der zentralen Dienste über das Internet (C.ZD.TLS | C.ZD.SIG) | 45 | ||
| TSPK.UC_6 | Prüfung von Zertifikaten der Fachdienste aus der TI (C.FD.TLS | C.FD.SIG | C.FD.AUT | C.FD.ENC | C.FD.OSIG) |
650 |
||
| TSPK.UC_7 | Prüfung von Zertifikaten der Fachdienste über das Internet (C.FD.TLS | C.FD.SIG | C.FD.AUT | C.FD.ENC | C.FD.OSIG) | 45 |
A_14502 - Performance – CRL-Dienst – Last und Parallele Downloads
Der TSP-X.509 nonQES für Komponenten MUSS die Vorgaben an Last und Anzahl der parallelen Downloads aus Tab_gemSpec_Perf_CRL-Dienst garantieren. [<=]
Tabelle 41: Tab_gemSpec_Perf_CRL-Dienst: Lastvorgaben
| Operation | Schnittstellenoperation |
Last [kByte] |
Parallele Downloads |
|---|---|---|---|
| TSPK.UC_8 | I_CRL_Download::download_CRL | 10 | 30 mit in Summe 2 Mbit / sec |
A_18013 - Performance – TSP – Provisioning/Revocation – Bearbeitungszeit
Der Produkttyp TSP-X.509nonQES der Komponenten-PKI MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_Provisioning_Revocation bei den dort angegebenen parallelen Requests erfüllen. [<=]
Tabelle 42: Tab_gemSpec_Perf_TSP_Provisioning_Revocation: Bearbeitungszeitvorgaben
| Operation | Schnittstellenoperation |
Parallele Requests | Mittelwert [sec] |
|---|---|---|---|
| TSPK.UC_9 | I_Cert_Provisioning::provide_Certificate (SOAP / CMP) (*) | 3 | 30 |
| TSPK.UC_10 | I_Cert_Provisioning::provide_Certificate (WEB Benutzerschnittstelle) | 1 | 5 |
| TSPK.UC_11 | I_Cert_Revocation::revoke_Certificate (SOAP / CMP) (*) | 3 | 30 |
| TSPK.UC_12 | I_Cert_Revocation::revoke_Certificate (WEB Benutzerschnittstelle) | 1 | 5 |
(*) Bezogen auf 100 Zertifikatsanfragen pro Request
Es gelten zusätzlich die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.13.2 Rohdaten-Performance-Reporting Spezifika TSP X.509 nonQES – Komp
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.13.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.13.2.2 Format
A_23533 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Operation (Rohdatenerfassung v.02)
Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp berücksichtigen. [<=]
A_24045 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Operation im Fehlerfall (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist und dadurch keine eindeutige Zuordnung zu einem Usecase gem. Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp Spalte "Operation / Usecase" möglich ist, MUSS der Produkttyp TSP X.509 nonQES – Komp bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes den Usecase TSPK.UC_13 verwenden. [<=]
Tabelle 43: Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp
| Operation / Usecase |
Beschreibung | Message |
|---|---|---|
| TSPK.UC_1 | Operation I_OCSP_KOMP_TI_KON: "I_OCSP_Status_Information::check_Revocation_Status Liste Zertifikatstyp: Prüfung von Konnektor-Zertifikaten aus der TI. (C.NK.VPN | C.AK.AUT | C.SAK.AUT) |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_2 | Operation I_OCSP_KOMP_INET_KON: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von Konnektor-Zertifikaten über das Internet. (C.NK.VPN | C.AK.AUT | C.SAK.AUT) |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_3 | Operation I_OCSP_KOMP_VPNK: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von VPN-Konzentratorzertifikaten durch Konnektoren über das Internet. (C.VPNK.VPN | C.VPNK.VPN-SIS) |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_4 | Operation I_OCSP_KOMP_TI_ZD: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von TLS Zertifikaten der zentralen Dienste aus der TI. (C.ZD.TLS | C.ZD.SIG) |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_5 | Operation I_OCSP_KOMP_INET_ZD: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von Zertifikaten der zentralen Dienste über das Internet. (C.ZD.TLS | C.ZD.SIG) |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_6 | Operation I_OCSP_KOMP_TI_FD: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von Zertifikaten der Fachdienste aus der TI. (C.FD.TLS | C.FD.SIG | C.FD.AUT | C.FD.ENC | C.FD.OSIG). |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_7 | Operation I_OCSP_KOMP_INET_FD: "I_OCSP_Status_Information::check_Revocation_Status" Liste Zertifikatstyp: Prüfung von Zertifikaten der Fachdienste über das Internet. (C.FD.TLS | C.FD.SIG | C.FD.AUT | C.FD.ENC | C.FD.OSIG). |
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp" }
|
| TSPK.UC_8 | Operation TSPK.UC_DOWN: "I_CRL_Download" |
{ "prot": "$protocol" }
|
| TSPK.UC_9 | Operation TSPK.UC_PRO: "I_Cert_Provisioning" |
{ "prot": "$protocol", "cc": $certCount }
|
| TSPK.UC_10 | Operation TSPK.UC_PRO_WEB: "I_Cert_Provisioning" | { "prot": "$protocol", "cc": $certCount }
|
| TSPK.UC_11 | Operation TSPK.UC_REV: "I_Cert_Revocation" |
{ "prot": "$protocol", "cc": $certCount }
|
| TSPK.UC_12 | Operation TSPK.UC_REV_WEB: "I_Cert_Revocation" | { "prot": "$protocol", "cc": $certCount }
|
| TSPK.UC_13 | Operation I_OCSP_KOMP_UNKNOWN: "I_OCSP_Status_Information::check_Revocation_Status" im Fehlerfall | { "prot": "$protocol", "res": "$result" }
|
A_23532 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Duration (Rohdatenerfassung v.02)
Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten des "duration_in_ms"-Feldes in folgender Weise berücksichtigen: Die Messung beginnt mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. [<=]
A_23725 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Message (Rohdatenerfassung v.02)
Der Produkttyp TSP X.509 nonQES – Komp MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:
{ "prot": "$protocol", "res": "$result", "zert": "$zertifikatstyp", "cc": $certCount }
- $protocol= "ECC" | "RSA" | "WEB" | "SOAP" | "CMP" als String
- $result= "GOOD" | "REVOKED" | "UNKNOWN" als String
- $zertifikatstyp = Zertifikatstyp aus Tab_gemSpec_Perf_Berichtsformat_TSP X.509 nonQES – Komp als String
- $certCount = Anzahl der angefragten Zertifikate innerhalb eines Requests als Integer
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]
A_23751 - Performance - Rohdaten - Spezifika TSP X.509 nonQES – Komp - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSP X.509 nonQES – Komp bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Statuscodes_TSP_X.509_nonQES_Komp festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 44: Tab_gemSpec_Perf_Statuscodes_TSP_X.509_nonQES_Komp
| Statuscode |
Definition |
Beschreibung |
Bewertung |
|---|---|---|---|
| 79875 |
OCSP_ERROR_WRONG_DATA |
Format der OCSP-Anfrage fehlerhaft |
FAILED_OTHER |
3.14 Trust Service Provider CVC
Im Folgenden werden die produkttypspezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Reporting des Trust Service Provider CVC aufgeführt.
3.14.1 Leistungsanforderungen Trust Service Provider CVC
3.14.1.1 Lastmodell Trust Service Provider CVC
Keine spezifischen Anforderungen zum Lastmodell.
3.14.1.2 Bearbeitungszeiten Trust Service Provider CVC
A_23901 - Performance – TSP CVC– Provisioning – Bearbeitungszeit
Der Produkttyp TSP CVC MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_CVC bei den dort angegebenen parallelen Requests erfüllen. [<=]
Tabelle 45: Tab_gemSpec_Perf_TSP_CVC: Bearbeitungszeitvorgaben
| Schnittstellenoperation (Basisdienste) |
Bearbeitungszeitvorgaben
|
||
|
Anzahl paralleler Requests |
Mittelwert [sec] |
||
| I_Cert_Provisioning |
|||
| provide_Certificate (Web-Benutzerschnittstelle) |
1
|
5
|
|
| provide_Certificate (SOAP) – bezogen auf 100 Zertifikatsbeantragungen pro SOAP-Request |
3
|
30
|
|
| provide_Certificate (CMP) – bezogen auf 100 Zertifikatsbeantragungen pro CMP-Request |
3
|
30
|
|
3.14.1.3 Performancevorgaben Trust Service Provider CVC
Keine spezifischen Performancevorgaben.
3.14.2 Rohdaten-Performance-Reporting Spezifika Trust Service Provider CVC
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.
3.14.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.14.2.2 Format
Die Rohdatenlieferung des TSP CVC erfolgt in Zusammenhang mit der Lieferung von Rohdaten durch den jeweiligen TSP X.509 nonQES.
3.15 OCSP-Responder-Proxy
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des OCSP-Responder-Proxy aufgeführt.
3.15.1 Leistungsanforderungen OCSP-Responder-Proxy
3.15.1.1 Lastmodell OCSP-Responder-Proxy
Keine spezifischen Anforderungen zum Lastmodell
3.15.1.2 Bearbeitungszeiten OCSP-Responder-Proxy
Keine spezifischen Anforderungen zu den Bearbeitungszeiten
3.15.1.3 Performancevorgaben OCSP-Responder-Proxy
Es gelten die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.15.2 Rohdaten-Performance-Reporting Spezifika OCSP-Responder-Proxy
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.15.2.1 Umfang
keine Spezifischen Anforderungen zum Umfang
3.15.2.2 Format
A_24159 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Operation (Rohdatenerfassung v.02)
Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes die Angabe der Spalte "Operation / Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy berücksichtigen. [<=]
A_24158 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Duration (Rohdatenerfassung v.02)
Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. des "duration_in_ms"-Feldes die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy berücksichtigen. [<=]
Tabelle 46: Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy
| Operation / Usecase |
Duration |
|---|---|
| OCSPPX | Bei Aufruf der Operation "check_Revocation_Status" beginnt die Messung der Bearbeitungszeit mit der Annahme der Nachricht durch den OCSP Responder Proxys, wird mit der Weiterleitung an den Ziel-OCSP im Internet pausiert, läuft mit Erhalt der Antwort vom Ziel-OCSP im Internet weiter und endet mit dem Versand der Antwort an den Client. |
A_24160 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Status (Rohdatenerfassung v.02)
Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_OCSP-Responder-Proxy berücksichtigen, sofern ein spezifischer Statuscode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 47: Tab_gemSpec_Perf_Statuscodes_OCSP-Responder-Proxy
| Statuscode |
Definition |
Beschreibung |
Bewertung |
|---|---|---|---|
| 200 |
OK |
Anfrage wurde erfolgreich verarbeitet |
SUCCESS |
| 413 | Payload too large | Die Datenmenge der Anfrage ist größer als der Server verarbeiten kann. | FAILED_OTHER |
| 415 | Unsupported Media Type | Die Daten liegen in einem Format vor, welches auf dem Zielsystem nicht unterstützt wird. | FAILED_OTHER |
| 500 | Internal Error | Ein unerwarteter Fehler ist aufgetreten | FAILED_SERVICE |
| 504 | Gateway Timeout | Der Ziel-OCSP im Internet antwortet nicht auf die Anfrage des OCSP-Responder-Proxys. | FAILED_SERVICE |
| 79875 | OCSP_ERROR_WRONG_DATA | Format der OCSP-Anfrage fehlerhaft | FAILED_OTHER |
A_24161 - Performance - Rohdaten - Spezifika OCSP-Responder-Proxy - Message (Rohdatenerfassung v.02)
Der Produkttyp OCSP-Responder-Proxy MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "bkdur": $backendDuration, "zOcsp": "$ziel-ocsp" }
- $backendDuration = Zeit in ms für Abfragen an den Ziel-OCSP im Internet, Datentyp Integer
- $ziel-ocsp = OCSP-gematik-ID des Ziel-OCSP im Internet basierend auf der Zuordnungstabelle Tab_gemSpec_Perf_OCSP-Responder-Proxy_Ziel-URLs, Datentyp String
Tabelle 48: Tab_gemSpec_Perf_OCSP-Responder-Proxy_Ziel-URLs
| OCSP Proxy: Ziel URL |
OCSP-gematik-ID |
|---|---|
| http://ocsp.d-trust.net |
ZIELURL_1 |
| http://ocsp-qes.egk-tsp.de | ZIELURL_2 |
| http://qocsp-eA.medisign.de:8080/ocsp | ZIELURL_3 |
| http://qocsp-eZAA.medisign.de:8080/ocsp | ZIELURL_4 |
| http://ocsp.bzaek.de:8080/ocsp-ocspresponder | ZIELURL_5 |
| http://qocsp.hba.telesec.de/ocspr | ZIELURL_6 |
| http://qocsp-ea.medisign.de:8080/ocsp | ZIELURL_7 |
| http://ocsp-qes.egk-test-tsp.de | ZIELURL_8 |
| http://qocsp.hba.test.telesec.de/ocspr | ZIELURL_9 |
| http://ehca.gematik.de/ecc-ocsp | ZIELURL_10 |
| http://ehca.gematik.de/ecc-ocsp | ZIELURL_11 |
| http://ehca.gematik.de/ecc-qocsp | ZIELURL_12 |
| http://d-trust-hba-qca4.ocsp.d-trust.net/ | ZIELURL_13 |
| http://d-trust-hba-qca5.ocsp.d-trust.net/ | ZIELURL_14 |
| http://staging.ocsp.d-trust.net | ZIELURL_15 |
| Andere Zieladressen | Vollständige URL |
Hinweis: Ein Mapping auf OSCP-gematik-ID muss auch erfolgen, wenn der FQDN Escape-Sequenzen enthält, z.B. %3A oder %2F.
3.16 TSL-Dienst
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des TSL-Dienstes aufgeführt.
3.16.1 Leistungsanforderungen TSL-Dienst
3.16.1.1 Lastmodell TSL-Dienst
Keine spezifischen Anforderungen zum Lastmodell
3.16.1.2 Bearbeitungszeiten TSL-Dienst
Sind im Folgekapitel "Performancevorgaben TSL-Dienst" mit enthalten.
3.16.1.3 Performancevorgaben TSL-Dienst
A_24327 - Performance - OCSP Responder des TSL-Dienstes - Grundlast
Der Produkttyp TSL-Dienst MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]
Tabelle 49: Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst
| Operation | Anwendungsfall | Spitzenlast [1/sec] | Mittelwert [msec] | 99%-Quantil [msec] |
|---|---|---|---|---|
| TSL.UC_1 | Prüfung des TSL-Signerzertifikats aus der TI | 45 | 1.000 | 1.300 |
| TSL.UC_2 | Prüfung des TSL-Signerzertifikats aus dem Internet | 45 |
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.
[<=]
Tabelle 50: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben
| Operation | Schnittstellenoperation | Last [kByte] | Parallele Downloads |
|---|---|---|---|
| TSL.UC_3 | I_BNetzA_VL_Download::download_VL | 6000 (**) | 250 mit in Summe 250 Mbit/sec |
| TSL.UC_4 | I_BNetzA_VL_Download::get_Hash | 0,1 | 10 mit in Summe 1 MBit/sec |
| TSL.UC_5 | I_TSL_Download::download_TSL (TI) | 200 (*) | 60 mit in Summe 60 MBit/sec |
| TSL.UC_6 | I_TSL_Download::get_Hash (TI) | 0,1 | 50 mit in Summe 1 MBit/sec |
| TSL.UC_7 | I_TSL_Download::download_TSL (Internet) | 200 (*) | 5 mit in Summe 5 MBit/sec |
| TSL.UC_8 | I_TSL_Download::get_Hash (Internet) | 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.
GS-A_4158-01 - Performance – TSL-Dienst – Verfügbarkeit
Der TSL-Dienst MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
- Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
- Alle übrigen Stunden der Woche sind Nebenzeit.
- Hauptzeit: 99,90%
- Nebenzeit: 99,00%
Es gelten die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.16.2 Rohdaten-Performance-Reporting Spezifika TSL-Dienst
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.16.2.1 Umfang
keine Spezifischen Anforderungen zum Umfang
3.16.2.2 Format
A_24169 - Performance - Rohdaten - Spezifika TSL-Dienst - Operation (Rohdatenerfassung v.02)
Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst berücksichtigen. [<=]
A_24168 - Performance - Rohdaten - Spezifika TSL-Dienst - Duration (Rohdatenerfassung v.02)
Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst berücksichtigen. [<=]
Tabelle 51: Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst
| Operation / Usecase |
Aufgerufende Schnittstelle::Operation | Duration | Message |
|---|---|---|---|
| TSL.UC_1 | I_OCSP_Status_Information::check_Revocation_Status (TI) | Die Messung der Bearbeitungszeit beginnt mit der Annahme der Nachricht durch den OCSP Responder des TSL-Dienstes und endet mit dem Versand der Antwort an den Client. |
{ "prot": "$protocol", "res": "$result" }
|
| TSL.UC_2 | I_OCSP_Status_Information::check_Revocation_Status (Internet) | ||
| TSL.UC_3 | I_BNetzA_VL_Download::download_VL | Die Messung der Bearbeitungszeit beginnt mit der Annahme der Nachricht durch den TSL-Dienst und endet mit dem Versand des letzten Bytes der Antwortnachricht. |
{ "url": "$usedURL" }
|
| TSL.UC_4 | I_BNetzA_VL_Download::get_Hash | ||
| TSL.UC_5 | I_TSL_Download::download_TSL (TI) | ||
| TSL.UC_6 | I_TSL_Download::get_Hash (TI) | ||
| TSL.UC_7 | I_TSL_Download::download_TSL (Internet) | ||
| TSL.UC_8 | I_TSL_Download::get_Hash (Internet) | ||
| TSL.UC_9 | I_TSL_Download::download_TSL (Notfall) |
A_24170 - Performance - Rohdaten - Spezifika TSL-Dienst - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp TSL-Dienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Statuscodes_TSL-Dienst festlegen, sofern ein spezifischer Statuscode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 52: Tab_gemSpec_Perf_Statuscodes_TSL-Dienst
| Status- code |
Definition |
Beschreibung |
Bewertung |
|---|---|---|---|
| 200 |
OK |
Anfrage wurde erfolgreich verarbeitet |
SUCCESS |
| 413 | Payload too large | Die Datenmenge der Anfrage ist größer als der Server verarbeiten kann. | FAILED_OTHER |
| 415 | Unsupported Media Type | Die Daten liegen in einem Format vor, welches auf dem Zielsystem nicht unterstützt wird. | FAILED_OTHER |
| 500 | Internal Error | Ein unerwarteter Fehler ist aufgetreten | FAILED_SERVICE |
A_24171 - Performance - Rohdaten - Spezifika TSL-Dienst - Message (Rohdatenerfassung v.02)
Der Produkttyp TSL-Dienst MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:
{ "prot": "$protocol", "res": "$result", "url": "$usedURL" }
- $protocol= Genutzter Schlüsselalgorithmus des angefragten Zertifikates, Datentyp String
- $result= Sperrstatus des angefragten Zertifikates gemäß GS-A_4690, Datentyp String
- $usedURL = "Returned Value" aus der Tabelle Tab_gemSpec_Perf_TSL-Dienst_URLs basierend darauf, welche URL der Konnektor oder Dienst zum Download der jeweiligen Datei genutzt hat, Datentyp String
Tabelle 53 :Tab_gemSpec_Perf_TSL-Dienst_URLs
3.17 gematik Root-CA
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat der gematik Root-CA aufgeführt.
3.17.1 Leistungsanforderungen gematik Root-CA
3.17.1.1 Lastmodell gematik Root-CA
keine spezifischen Anforderungen zum Lastmodell
3.17.1.2 Bearbeitungszeiten gematik Root-CA
Sind im Folgekapitel "Performancevorgaben gematik Root-CA" mit enthalten.
3.17.1.3 Performancevorgaben gematik Root-CA
A_24328 - Performance - OCSP Responder der gematik Root-CA - Grundlast
Der Produkttyp gematik Root-CA MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder_gematik-Root-CA unter einer Last von 5 Anfragen pro Sekunde erfüllen. [<=]
Tabelle 54: Tab_gemSpec_Perf_OCSP_Responder_gematik-Root-CA
| Operation | Anwendungsfall | Spitzenlast [1/sec] | Mittelwert [msec] | 99%-Quantil [msec] |
|---|---|---|---|---|
| ROOTCA | Prüfung von eGK-CA-Zertifikaten aus dem Internet: CA-Zert | 45 | 1.000 | 1.300 |
| Prüfung von HBA-CA-Zertifikaten aus dem Internet: CA-Zert | 45 | |||
| Prüfung von SMC-B-CA-Zertifikaten aus dem Internet: CA-Zert | 45 | |||
| Prüfung von KOMP-CA-Zertifikaten aus dem Internet: CA-Zert | 45 | |||
| Prüfung von VPNK-CA-Zertifikaten aus dem Internet: CA-Zert | 45 | |||
| Prüfung von Root-CA-Zertifikaten aus dem Internet: Root-CA-Zert | 45 |
Es gelten zusätzlich die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.17.2 Rohdaten-Performance-Reporting Spezifika gematik Root-CA
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.17.2.1 Umfang
keine Spezifischen Anforderungen zum Umfang
3.17.2.2 Format
A_24165 - Performance - Rohdaten - Spezifika gematik Root-CA - Operation (Rohdatenerfassung v.02)
Der Produkttyp gematik Root-CA MUSS bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA berücksichtigen. [<=]
A_24164 - Performance - Rohdaten - Spezifika gematik Root-CA - Duration (Rohdatenerfassung v.02)
Der Produkttyp gematik Root-CA MUSS bei Rohdaten-Performance-Berichten bzgl. des "duration_in_ms"-Feldes die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA berücksichtigen. [<=]
Tabelle 55: Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA
| Operation / Usecase |
Duration |
|---|---|
| ROOTCA | Bei Aufruf der Operation "check_Revocation_Status" beginnt die Messung der Bearbeitungszeit mit der Annahme der Nachricht durch den OCSP Responder der gematik Root-CA und endet mit dem Versand der Antwort an den Client. |
A_24166 - Performance - Rohdaten - Spezifika gematik Root-CA - Status (Rohdatenerfassung v.02)
Der Produkttyp gematik Root-CA MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_gematik-Root-CA berücksichtigen, sofern ein spezifischer Statuscode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 56: Tab_gemSpec_Perf_Statuscodes_gematik-Root-CA
| Statuscode |
Definition |
Beschreibung |
Bewertung |
|---|---|---|---|
| 200 |
OK |
Anfrage wurde erfolgreich verarbeitet |
SUCCESS |
| 413 | Payload too large | Die Datenmenge der Anfrage ist größer als der Server verarbeiten kann. | FAILED_OTHER |
| 415 | Unsupported Media Type | Die Daten liegen in einem Format vor, welches auf dem Zielsystem nicht unterstützt wird. | FAILED_OTHER |
| 500 | Internal Error | Ein unerwarteter Fehler ist aufgetreten | FAILED_SERVICE |
A_24167 - Performance - Rohdaten - Spezifika gematik Root-CA - Message (Rohdatenerfassung v.02)
Der Produkttyp gematik Root-CA MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:
{ "prot": "$protocol", "res": "$result", "cn": $commonName }
- $protocol= Genutzter Schlüsselalgorithmus des angefragten Zertifikates: "ECC" | "RSA", Datentyp String
- $result= Sperrstatus des angefragten Zertifikates gemäß GS-A_4690: "GOOD" | "REVOKED" | "UNKNOWN", Datentyp String
- $commonName = commonName des Zertifikats gem. GS-A_4737, Datentyp String
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]
3.18 ePA-Aktensystem
Im folgenden werden die produkttypspezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des ePA-Aktensystems aufgeführt.
3.18.1 Leistungsanforderungen ePA-Aktensystem
3.18.1.1 Lastmodell ePA-Aktensystem
Lastannahmen sind im Folgekapitel "Performancevorgaben ePA-Aktensystem" enthalten.
3.18.1.2 Bearbeitungszeiten ePA-Aktensystem
Anforderungen zu Bearbeitungszeiten sind im Folgekapitel "Performancevorgaben ePA-Aktensystem" enthalten.
3.18.1.3 Performancevorgaben ePA-Aktensystem
A_15031-02 - Performance - ePA-Aktensystem - Bearbeitungszeit unter Last
Der Anbieter ePA-Aktensystem MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.
Die Bearbeitungszeit bemisst sich aus der Zeit vom Eintreffen des letzten Bits der Anfrage (Request) im ePA-Aktensystem bis zum Zeitpunkt, an dem das erste Bit der Antwort (Response) zurückgesendet wird.
Tabelle 57 : Tab_gemSpec_Perf_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben
| UseCase-Bezug | Fachdienstoperation | Spitzenlast [1/sec] |
Mittelwert [msec] |
Maximalwert [msec] |
Erfüllungsquote [%] |
|---|---|---|---|---|---|
| EPA.UC_1 | <<Login für einen Versicherten (VAU + Etablierung User Session)>> | 160 | 1500 | 2000 | 99,95 |
| EPA.UC_B4.x | I_Contraint_Management_Insurant::setDenyPolicyAssignment | 10 | 420 | 800 | |
| EPA.UC_A2.2 | I_Entitlement_Management_Insurant::setEntitlement (durch Versicherte) | 20 | 280 | 600 | |
| EPA.UC_A2.5 | I_Entitlement_Management_Insurant::setEntitlement (durch Vertreter) | 10 | 280 | 600 | |
| EPA.UC_2 | <<Aufbau der VAU für einen LE>> | 340 | 1500 | 2000 | |
| EPA.UC_2x | <<Laden des Health Record Contextes>> | 340 | 650 | 1200 | |
| EPA.UC_A3.9 | I_Information_Service::getConsentDecisionInformation | 120 | 300 | 600 | |
| EPA.UC_6.1y | I_Medication_Service::getMedicationList | 400 | 1300 | 2500 | |
| EPA.UC_A2.1 | I_Entitlement_Management::setEntitlementPs | 120 | 280 | 600 | |
| EPA.UC_C6.1 | I_Medication_Service::putPrescription | 400 | 250 | 500 | |
| EPA.UC_C6.1x | I_Medication_Service::putDispensation |
200 | 250 | 500 |
Hinweis: Die Lastvorgaben entsprechen einem Marktanteil von 100% und sind entsprechend des realen Marktanteils des Produktes/Anbieters anzupassen. Die Vorgaben für die Bearbeitungszeiten beziehen sich nur auf den Anteil, welcher auch durch das Aktensystem zu verantworten ist. Ggf. notwendige "Wartezeiten" die sich durch andere TI-Services ergeben, werden nicht berücksichtigt. Näheres dazu liefert auch Tab_gemSpec_Perf_Berichtsformat_ePA.
A_15236-02 - Performance - ePA-Aktensystem - Robustheit gegenüber Lastspitzen
Das ePA-Aktensystem MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_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 mit einem HTTP-Statuscode 503 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-01 - Performance - ePA-Aktensystem - Access Gateway - Lastvorgaben
Der Anbieter ePA-Aktensystem MUSS die Komponente Access Gateway 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 seinen Marktanteil das System so dimensionieren, dass die Lastvorgaben am Access Gateway eingehalten werden. Beispielrechnung: Für ein Marktanteil von 20% und eine Lastvorgabe von 640 Anfragen pro Sekunde muss das Access Gateway mindestens 128 Anfragen pro Sekunde an die nachgelagerten Komponenten weiterleiten können.
A_15214 - Performance - ePA-Aktensystem - Speicherkapazität TU
Der Anbieter ePA-Aktensystem MUSS eine Speicherkapazität von 300 GB in der TU bereit stellen.
[<=]
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-02 - Performance - ePA-Aktensystem - Verfügbarkeit
Die Anbieter ePA-Aktensystem MUSS die folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:
- Hauptzeit: 99,90%
- Nebenzeit: 99,00%
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.
3.18.2 Rohdaten-Performance-Reporting Spezifika ePA-Aktensystem
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.18.2.1 Umfang
keine spezifischen Anforderungen zum Umfang
3.18.2.2 Format
A_22466 - Performance - Rohdaten - Spezifika ePA-Aktensystem - Duration (Rohdatenerfassung v.02)
Der Produkttyp Aktensystem_ePA MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_ePA berücksichtigen. [<=]
A_22467 - Performance - Rohdaten - Spezifika ePA-Aktensystem - Operation (Rohdatenerfassung v.02)
Der Produkttyp Aktensystem_ePA MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_ePA berücksichtigen.
[<=]
Tabelle 58 : Tab_gemSpec_Perf_Berichtsformat_ePA
| Usecase / Anwendungsfall-ID |
Duration | Message-Block | |
|---|---|---|---|
| EPA.UC_1 | Login Versicherter | Beginnt mit VAU-Hello und endet mit dem Abschluss des Aufbaus der VAU. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_B1.1 | Dokument hochladen Versicherter | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. | { "cid": "$clientID", "cv" : "$version", "size": $size } |
| EPA.UC_B4.x | Verbergen von Dokumenten / Kategorien | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_A2.2 | Befugnis ablegen Versicherter | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_A2.5 | Befugnis ablegen Vertreter | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_2 | Login PS | Beginn mit VAU-Hello und endet mit dem Abschluss des Aufbaus der VAU. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version", "profOID": "$professionOID" } |
| EPA.UC_2x | Aktenkontext öffnen PS | Beginnt mit dem (ggf. impliziten) Request zum Öffnen eines bestimmten Health Record Contextes und endet mit Abschluss des Absendens der Response. | { "cid": "$clientID", "cv" : "$version", "profOID": "$professionOID" } |
| EPA.UC_B1.2 | Dokument hochladen PS | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. | { "cid": "$clientID", "cv" : "$version", "size": $size, "profOID": "$professionOID", "cat": "$category" } |
| EPA.UC_A3.9 | Abfragen von Widersprüchen PS | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_6.1y | Medikationsliste abrufen PS | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version", "size": $size } |
| EPA.UC_A2.1 | Befugnis ablegen PS | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. Während ggf. notwendigem Request an externen Komponenten pausiert die Messung. | { "cid": "$clientID", "cv" : "$version" } |
| EPA.UC_C6.1 | Verordnungen einstellen eRP-FD | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. | { } |
| EPA.UC_C6.1x | Dispensierung einstellen eRP-FD | Beginnt mit dem Erhalt des Requests und endet mit Abschluss des Absendens der Response. | { } |
Hinweis bzgl. der Ermittlung der Bearbeitungszeiten der Usecases aus Tab_gemSpec_Perf_Berichtsformat_ePA: Falls ein Usecase in einem anderen inkludiert ist (z.B. UC_a läuft innerhalb von UC_b ab), so darf keine doppelte Erfassung der Bearbeitungszeit (von UC_a) erfolgen. Die Messung von UC_b pausiert, während der Durchführung von UC_a, und beide Messergebnisse werden separat im Rahmen der Rohdatenlieferung übertragen.
A_22468 - Performance - Rohdaten - Spezifika ePA-Aktensystem - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp Aktensystem_ePA - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gemäß Tab_gemSpec_Perf_Fehlercodes_ePA-AS festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
Tabelle 59: Tab_gemSpec_Perf_Fehlercodes_ePA-AS
| Statuscode |
Definition |
Beschreibung |
Bewertung |
|---|---|---|---|
| 79001 |
OCSP_ERROR_NO_RESPONSE |
Keine Antwort des OCSP oder Timeout |
FAILED_OTHER |
| 79879 |
OCSP_ERROR_WRONG_SIGNATURE |
Falsche oder fehlende Signatur in der OCSP-Antwort |
FAILED_OTHER |
| 79875 |
OCSP_ERROR_WRONG_DATA |
Format der OCSP-Anfrage fehlerhaft |
FAILED_OTHER |
| 79881 |
OCSP_ERROR_INVALID_RESPONSE |
Antwort des OCSP fehlerhaft |
FAILED_OTHER |
| 79873 |
OCSP_CERT_MISSING |
OCSP-Zertifikat nicht in TSL enthalten |
FAILED_OTHER |
| 79112 | USERAGENT_WRONG_FORMAT | Format des Useragents fehlerhaft | FAILED_OTHER |
A_22469-01 - Performance - Rohdaten - Spezifika ePA-Aktensystem - Message (Rohdatenerfassung v.02)
Der Produkttyp Aktensystem_ePA MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.
{ "cid": "$clientID", "cv" : "$version", "size": $size, "profOID": "$professionOID", "cat": "$category" }
- $clientID: ClientID-Parameter aus dem HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme aus [gemSpec_Aktensystem_ePAfuerAlle#A_22470-04] (erster Teil des Useragent-Parameters), Datentyp String
- $version: Versionsnummer-Parameter aus dem HTTP-Header-Feld gemäß Anforderungslage für Clientsysteme aus [gemSpec_Aktensystem_ePAfuerAlle#A_22470-04] (zweiter Teil des Useragent-Parameters), Datentyp String
- $size: Größe des Requests in kilobyte, Datentyp Integer
- $professionOID: professionOID gemäß [gemSpec_Aktensystem_ePAfuerAlle#A_23941], Datentyp String
- $category: Dokumentenkategorie gemäß der Spalte "technischer Identifier" in [gemSpec_Aktensystem_ePAfuerAlle#A_19303-*], Datentyp String.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]
3.18.3 Bestandsdaten ePA Aktensystem
A_15743-02 - Performance - ePA-Aktensystem - Bestandsdaten
Der Anbieter ePA-Aktensystem MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über das ePA-Aktensystem berichten:
- je Mandant
-
- Anzahl von Aktenkonten
- Anzahl von im Zeitintervall neu hinzugefügten Dokumenten, Datensätzen und Artefakten
- Anzahl von im Zeitintervall entfernten Dokumenten, Datensätzen und Artefakten
- Anzahl von abgelegten Widersprüchen zum Medikationsprozess
- Anzahl von abgelegten Widersprüchen gegen des Einstellen durch den eRP-FD
- Anzahl von abgelegten Widersprüchen zur Forschungsfreigabe
- Anzahl von im Zeitintervall neu hinzugefügten Abrechnungsinformationen
- Anzahl von Aktenkonten
- je UX-Usecase:
-
- je ClientID und Versionsnummer
-
- Arithmetisches Mittel der Einzelmessungen
- Anzahl der in die Konsolidierung eingeflossenen Einzelwerte
- höchster Einzelwert der konsolidierten Messewerte
- niedrigster Einzelwert der konsolidierten Messewerte.
Voreingestellt für das Zeitintervall ist: täglich. [<=]
A_20204-04 - Performance - ePA-Aktensystem - Lieferweg und Format für Bestandsdaten
Das ePA-Aktensystem MUSS die Informationen aus [A_15743-*] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD [A_23110] liefern:
{
"ci" : "<CI ID des abgefragten Aktensystems gemäß TI-ITSM als String>",
"kassendaten" : [
"dokplus" : <Anzahl von im Zeitintervall hinzugefügten Elemente (über alle Konten) als Integer>,
"dokminus" : <Anzahl von im Zeitintervall entfernten Elemente (über alle Konten) als Integer>,
"wmed" : <Anzahl der zum Abfragezeitpunkt vorhandenen Widersprüchen zum Medikationsprozess als Integer>,
"werp" : <Anzahl der zum Abfragezeitpunkt vorhandenen Widersprüchen gegen das Einstellen von Verordnungsdaten durch den eRezept-Fachdienst als Integer>,
"wfor" : <Anzahl der zum Abfragezeitpunkt vorhandenen Widersprüchen zur Forschungsfreigabe als Integer>,
"abrech" : <Anzahl von im Zeitintervall neu hinzugefügten Abrechnungsinformationen als Integer>
"ux_daten" : [
"cv" : "<ClientVersion der ClientID deren Messergebnisse konsolidiert wurden, String>",
"anz" : <Anzahl der Einzelmessungen für die o.a. ClientID und den dazugehörigen UX-Usecase im Betrachtungszeitraum, Integer>,
"max" : <höchste Einzelmessung für die o.a. ClientID und den dazugehörigen UX-Usecase im Betrachtungszeitraum, Integer>,
"min" : <niedrigste Einzelmessung für die o.a. ClientID und den dazugehörigen UX-Usecase im Betrachtungszeitraum, Integer>
Hinweis zur Zählung der Dokumente in A_20204-x:
1. Um für die Bestandsdatenlieferung die Anzahl der neu hinzugefügten Elemente zu ermitteln, werden folgende Elemente gezählt:
· alle Elemente, für die beim Hochladen ohne RPLC Option ein XDSDocumentEntry erzeugt wird
· alle Einträge zu Verordnungen
· alle Einträge zu Dispensierungen
2. Für die gleichen Elemente wird gezählt, wenn sie gelöscht werden (bei Verordnungen und Dispensierungen, wenn sie storniert werden). Dieser Wert wird dann bei der Bestandsdatenlieferung für die Anzahl der entfernten Elemente übermittelt.
3. Ferner gilt: Werden die oben definierten Elemente per Replacement ersetzt, so gilt dies als Löschung (2.) UND Hochladen (1.)
4. Werden stornierte Verordnungen oder Dispensierungen aus der ePA gelöscht z.B. durch Widerspruch gegen den Medikationsprozess, ist dieses Löschen nicht erneut zu zählen.
Tabelle 60: Tab_UX-Usecases
| UX-Usecase-Name |
|---|
| EPA.UX_Login_V |
| EPA.UX_Doc_Upload_V |
| EPA.UX_Doc_Download_V |
| EPA.UX_LEI_search |
| EPA.UX_Login_PS |
| EPA.UX_Doc_Upload_PS |
| EPA.UX_Doc_Download_PS |
3.19 Konfigurationsdienst
Der Produkttyp Konfigurationsdienst der TI ist ein betriebsunterstützendes System und speichert Update-Pakete für dezentrale Produkte der TI (z. B. Konnektoren und eHealth-Kartenterminals).
3.19.1 Leistungsanforderungen Konfigurationsdienst
3.19.1.1 Lastmodell Konfigurationsdienst
A_24532 - Performance – Konfigurationsdienst – Lastvorgaben – parallele Downloads
Für den Anwendungsfall get_Updates(Download-Software-Pakete) MUSS die Anzahl der geforderten parallelen Downloads pro KSR Download Cache Server von Tab_gemSpec_Perf_Konfigurationsdienst: Lastvorgaben garantiert werden. Die Download-Dateien müssen während des Download-Transports komprimiert sein. [<=]
Tabelle 61: Tab_gemSpec_Perf_Konfigurationsdienst: Lastvorgaben
| Operation | Schnittstellenaufruf | Parallele Downloads [Anzahl] |
maximal Bandbreite [Mbit/sec] |
|---|---|---|---|
| KSR.I_3 | I_KSRS_Download::get_Updates | 1000 |
1000 |
GS-A_4853-01 - Performance – Konfigurationsdienst – Verfügbarkeit
Der Konfigurationsdienst MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:
- Hauptzeit: 99,00%
- Nebenzeit: 99,00%
[A_23350 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt]
3.19.1.2 Bearbeitungszeiten Konfigurationsdienst
GS-A_4157-01 - Performance – Konfigurationsdienst – Bearbeitungszeit unter Last
Der Produkttyp Konfigurationsdienst MUSS parallel die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Konfigurationsdienst:Bearbeitungszeitvorgaben für die Operation list_Updates erlauben. [<=]
Tabelle 62: Tab_gemSpec_Perf_Konfigurationsdienst: Bearbeitungszeitvorgaben
| Operation | Schnittstellenaufruf | Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|
| KSR.I_1 | I_KSRS_Download::list_Updates | 7 | 100 | 300 |
3.19.1.3 Performancevorgaben Konfigurationsdienst
Es gelten die Anforderungen:
[GS-A_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit]
[GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen]
[GS-A_5331 - Performance – zentrale Dienste – TLS-Handshake]
3.19.2 Rohdaten-Performance-Reporting Spezifika Konfigurationsdienst
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.19.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang.
3.19.2.2 Format
A_24300 - Performance - Rohdaten - Spezifika Konfigurationsdienst - Operation (Rohdatenerfassung v.02)
Der Produkttyp Konfigurationsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Konfigurationsdienst berücksichtigen. [<=]
A_24299 - Performance - Rohdaten - Spezifika Konfigurationsdienst - Duration (Rohdatenerfassung v.02)
Der Produkttyp Konfigurationsdienst MUSS bei Rohdaten-Performance-Berichten den Wert des "duration_in_ms"-Feldes in folgender Weise berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]
A_24301 - Performance - Rohdaten - Spezifika Konfigurationsdienst - Message (Rohdatenerfassung v.02)
Der Produkttyp Konfigurationsdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die folgenden Daten im JSON-Format übermitteln:
{ "pvid": "$ProductVendorID", "pc": "$ProductCode", "hwv": "$HardwareVersion", "fwv": "$FirmwareVersion", "s":"$State", "szzpid":"$SZZPID", "p":"$Priority", "dl":"$Deadline", "fn":"$FileName", "cf":"$CountFiles"}
- $ProductVendorID = ProductVendorID (z.B. Konnektor) gemäß [ProductInformation.xsd]
- $ProductCode= ProductCode (z.B. Konnektor) gemäß [ProductInformation.xsd]
- $HardwareVersion= HardwareVersion (z.B. Konnektor) gemäß [ProductInformation.xsd]
- $FirmwareVersion= FirmwareVersion (z.B. Konnektor) gemäß [ProductInformation.xsd]
- $State= Status des verarbeiteten Update-Pakets gemäß gemSpec_KSR::Tab_KSR_050 Status Definition
- $SZZPID = SZZP ID von dem die Anfrage beantwortet wird
- $Priority= Priority Flag (Critical Flag Konnektor)
- $Deadline= Datum bis wann das Update-Paket aktiviert sein soll.
- $FileName=Name der Datei die geladen werden soll.
- $CountFiles=Anzahl der Dateien im FirmwarePaket
Für die jeweilige Operation sind dabei nur die in der Spalte "Message" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Konfigurationsdienst angegebenen Key-Value Paare zu übermitteln.
Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]
Tabelle 63: Tab_gemSpec_Perf_Berichtsformat_Konfigurationsdienst
| Operation / Usecase | Schnittstellenaufruf | Message |
|---|---|---|
| KSR.I_1 | I_KSRS_Download::list_Updates | { "pvid": "$ProductVendorID", "pc": "$ProductCode", "hwv": "$HardwareVersion", "fwv": "$FirmwareVersion", "szzpid":"$SZZPID"}
|
| KSR.I_2 | I_KSRS_Download::get_Ext_Net_Config | { "szzpid":"$SZZPID"}
|
| KSR.I_3 | I_KSRS_Download::get_Updates | { "pvid": "$ProductVendorID", "pc": "$ProductCode", "hwv": "$HardwareVersion", "fwv": "$FirmwareVersion","fn":"$FileName", "szzpid":"$SZZPID"}
|
| KSR.I_4 | P_KSRS_Upload | { "pvid": "$ProductVendorID", "pc": "$ProductCode", "hwv": "$HardwareVersion", "fwv": "$FirmwareVersion","p":"$Priority", "dl":"$Deadline", "cf":"$CountFiles"}
|
| KSR.I_5 | P_KSRS_Operations | { "pvid": "$ProductVendorID", "pc": "$ProductCode", "hwv": "$HardwareVersion", "fwv": "$FirmwareVersion", "s": "$State"}
|
A_24340 - Performance - Rohdaten - Spezifika Konfigurationsdienst- Status (Rohdatenerfassung v.02)
Der Produkttyp Konfigurationsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "status"-Felder die Angabe der Spalte "Statuscode" aus Tab_gemSpec_Perf_Statuscodes_Konfigurationsdienst berücksichtigen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.
[<=]
Tabelle 64: Tab_gemSpec_Perf_Statuscodes_Konfigurationsdienst
| Statuscode | Definition nach Tab_KSR_047 I_KSRS_Download::listUpdates Fehlercodes |
Beschreibung | Bewertung |
|---|---|---|---|
| 78022 | Verbindung zurückgewiesen |
Die Verbindung wurde vom angefragten System zurückgewiesen | FAILED_OTHER |
| 78023 | Nachrichtenschema fehlerhaft | Das Nachrichtenschema war inkorrekt | FAILED_OTHER |
| 78024 | Version Nachrichtenschema fehlerhaft | Die Version des Nachrichtenschemas stimmt nicht mit der geforderten Version überein | FAILED_OTHER |
| 78025 | Protokollfehler | Genauere Aufschlüsselung des Protokollfehlers werden in den Details erfasst | FAILED_OTHER |
3.20 Zeitdienst
Der Zeitdienst in der TI basiert auf dem Network Time Protocol (NTP) und ermöglicht es, eine einheitliche Zeit innerhalb der TI zu nutzen. Der Produkttyp Zeitdienst besteht dabei aus mehreren Stratum 1 NTP Servern, welche sich mit der gesetzlichen Zeit (Zeitquelle) synchronisieren. Diese wird anschließend über mehrere Stufen in der gesamten TI verteilt und zur Abfrage bereitgestellt.
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des Zeitdienstes aufgeführt.
3.20.1 Leistungsanforderungen Zeitdienst
3.20.1.1 Lastmodell Zeitdienst
Keine spezifischen Anforderungen zum Lastmodell
3.20.1.2 Bearbeitungszeiten Zeitdienst
Sind im Folgekapitel "Performancevorgaben Zeitdienst" mit enthalten.
3.20.1.3 Performancevorgaben 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_4165-01 - Performance – Zeitdienst – Verfügbarkeit
Der Zeitdienst MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Sonntag von 0 - 24 Uhr, inklusive bundeseinheitlicher Feiertage.
Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet. [<=]
A_24812 - Performance - Zeitdienst - Abweichung zur gesetzlichen Zeit
Für alle Stratum 1 NTP Server des Produkttyps Zeitdienst DARF die Abweichung von der gesetzlichen Zeit NICHT größer sein als 330msec. [<=]
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.
[<=]
Es gelten zusätzlich die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.20.2 Rohdaten-Performance-Reporting Spezifika Zeitdienst
Für den Produkttypen Zeitdienst ist kein Rohdaten-Performance-Reporting spezifiziert. Benötigte Informationen zum Zeitdienst werden über eine Bestandsdaten-Lieferung übermittelt, welche im Folgekapitel 3.20.3 Bestandsdaten Zeitdienst spezifiziert sind.
3.20.3 Bestandsdaten Zeitdienst
Bestandsdaten sind im Gegensatz zum Rohdaten-Performance-Reporting die Abfragen von Statusinformationen zu einem spezifizierten Abfragezeitpunkt. Im Folgenden sind Bestandsdaten Anforderungen für den Produkttypen Zeitdienst spezifiziert.
A_24858 - Performance - Zeitdienst - Bestandsdaten
Der Anbieter des Produkttypen Zeitdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den Zeitdienst berichten:
- Wert der zeitlichen Abweichung eines jeden Stratum 1 NTP Servers zur gesetzlichen Zeit (Zeitquelle)
Voreingestellt für das Zeitintervall ist: stündlich. [<=]
A_24861 - Performance - Zeitdienst - Lieferweg und Format für Bestandsdaten
Der Anbieter des Produkttypen Zeitdienst MUSS die Informationen aus [A_24858] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [A_23110] mit Einschränkungen* liefern. Für jeden Stratum 1 NTP Server ist dabei innerhalb des JSON Objektes offsetValues ein eigenständiger Integer Key ntp_x zu erstellen. Das x ist durch eine Nummer zu ersetzen, wodurch der jeweilige Stratum 1 NTP Server eindeutig zugeordnet werden kann.
{
"timestamp": <Zeitstempel der Abfrage als String im Format ISO 8601>,
"ci": <CI-ID der abgefragten Produktinstanz gemäß [A_17764] als String>,
"offsetValues": {
"ntp_x": <Zeitliche Abweichung in msec vom Stratum 1 NTP Server zur gesetzlichen Zeit (Zeitquelle) als Integer>
}
}
* Einschränkungen: Da bei dieser Lieferung keine Datei übermittelt wird, sondern die Daten direkt im Request-Body geliefert werden, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_23110] NICHT notwendig. [<=]
A_25071 - Performance - Zeitdienst - Selbstauskunft
Der Produkttyp Zeitdienst MUSS eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd] an die Betriebsdatenerfassung senden. Bei der Erstellung der Selbstauskunft müssen folgende inhaltliche Vorgaben berücksichtigt werden:
- "Produkttypbezeichnung" gem. gemKPT_Betr::Tab_gemKPT_Betr_Produkttypen::Spalte ID (PDT...) --> "ProductType"
- "kompatibilitätsrelevante Produkttypversion“ gem. gemSpec_OM „ProductTypeVersion“
- "Hersteller-/Anbieter-ID“ (5 Zeichen-Kürzel von gematik Zulassung) gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductVendorID“
- "Produktkürzel“ (8 Zeichen-Kürzel nach Herstellerfestlegung) gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> „ProductCode“
- "Produktversion" gem. gemSpec_OM::Tab_ProdIdentD ODER gemSpec_OM::Tab_ProdIdentZ --> "ProductVersion"
- "Herstellername /Anbietername" gem. gemSpec_OM::Tab_ZusAttr --> "ProductVendorName"
- "Produktname" gem. gemSpec_OM::Tab_ZusAttr --> "ProductName"
3.21 Zentrales Netz der TI
Das zentrale Netz der TI dient der performanten Kommunikation zwischen VPN-Zugangsdiensten, zentralen Diensten und fachanwendungsspezifischen Diensten. Es besteht aus folgenden Komponenten:
- Anbindungstypen (SZZP, SZZP-light)
- Netzwerk (Backbone / Routing)
Die Anbindungstypen stellen den Anschluss von Produkttypen (z.B. VPN-Zugangsdienst) an das zentrale Netz der TI her und werden in folgenden Anschlussvarianten angeboten:
- Einfache Anbindung
- Redundante Anbindung
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des zentralen Netzes der TI aufgeführt. Weitere Informationen zum zentralen Netz der TI sind in der [gemSpec_Net] zu finden.
3.21.1 Leistungsanforderungen Zentrales Netz der TI
3.21.1.1 Lastmodell Zentrales Netz der TI
Die Abbildung "Netzwerktopologie - Punkte mit Lastvorgaben (orange)" skizziert die Punkte im Netzwerk, für die Spitzenlastvorgaben gestellt werden. Die Spitzenlasten beziehen sich auf die Summe aller Instanzen pro Produkttyp.
Abbildung 5: Netzwerktopologie – Punkte mit Lastvorgaben (orange)
In der Tabelle Tab_gemSpec_Perf_Netzlast_1 sind die Spitzenlastvorgaben am VPN-Zugangsdienst (Punkt 1) aufgelistet.
Tabelle 65: 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 |
3.21.1.2 Bearbeitungszeiten Zentrales Netz der TI
Sind im Folgekapitel "Performancevorgaben Zentrales Netz der TI" mit enthalten.
3.21.1.3 Performancevorgaben Zentrales Netz der TI
A_24472 - Performance - Zentrales Netz - Verfügbarkeit
Der Produkttyp Zentrales Netz der TI MUSS folgende Servicezeiten gewährleisten:
- Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr.
- Bundeseinheitliche Feiertage werden wie ein Sonntag behandelt, alle übrigen Feiertage wie ein Montag.
- Alle übrigen Stunden der Woche sind Nebenzeit.
Tabelle 66 Tab_gemSpec_Perf_Zentrales-Netz-TI_Verfügbarkeiten
| Anbindungstyp | Anschlussvariante | Verfügbarkeit Hauptzeit im Mittel |
Verfügbarkeit Nebenzeit im Mittel |
Hinweis |
|---|---|---|---|---|
| SZZP | Einfache Anbindung | 99,8% | 99% | - |
| Redundante Anbindung | 99,98% | 99% | - | |
| SZZP-light | Einfache Anbindung | 99,8% | 99% | Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen |
| Redundante Anbindung | 99,98% | 99% | Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen |
Hinweis: Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet. [<=]
GS-A_4166-01 - Performance – Zentrales Netz – Durchsatz
Das Zentrale Netz der TI MUSS die Netzwerkverbindungen so auslegen, dass die an den Anbindungstypen vereinbarte Bandbreite nutzbar ist und jederzeit über das zentrale Netz transportiert werden kann. [<=]
GS-A_4167-01 - 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 SZZP zu SZZP und SZZP zum VPN-Konzentrator des SZZP-lights aufweisen. [<=]
GS-A_4347-01 - 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 SZZP zu SZZP und SZZP zum VPN-Konzentrator des SZZP-lights aufweisen. [<=]
GS-A_5014-01 - Performance – Zentrales Netz – Volumenmessung im SZZP
Das Zentrale Netz der TI-Plattform MUSS an seinen Sicheren Zentralen Zugangspunkten (SZZPs) und an SZZP-light 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 SZZPs, an denen Transfernetze angebunden sind, keine Aufschlüsselung nach Produktinstanz und Anbieter gefordert, sondern nur eine Aufschlüsselung nach SZZP und Richtung.
An SZZP-light, die WANDA Smart und Cloud-Anbieter an das zentrale Netz der TI 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.
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.
Es gelten zusätzlich die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.21.2 Rohdaten-Performance-Reporting Spezifika Zentrales Netz der TI
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.21.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang
3.21.2.2 Format
A_24871 - Performance - Rohdaten - Spezifika Zentrales Netz - Operation (Rohdatenerfassung v.02)
Der Produkttyp Zentrales Netz der TI MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Zentrales-Netz-TI berücksichtigen.
Für die Schnittstellenoperation I_IP_Transport::check_Simple_Connection MUSS gewährleistet sein, dass die Schnittstelle innerhalb von 5 Minuten für alle Verbindungen der Anschlussvariante "Einfache Anbindung" jeweils mindestens einmal ausgeführt wird. Erfolgt dies nicht und erfolgt keine Nachlieferung gemäß A_22005, gilt das Zentrale Netz der TI in der Anschlussvariante "Einfache Anbindung" für diesen Zeitraum als nicht verfügbar.
Für die Schnittstellenoperation I_IP_Transport::check_Redundant_Connection MUSS gewährleistet sein, dass die Schnittstelle innerhalb von 5 Minuten für alle Verbindungen der Anschlussvariante "Redundante Anbindung" jeweils mindestens einmal ausgeführt wird. Erfolgt dies nicht und erfolgt keine Nachlieferung gemäß A_22005, gilt das Zentrale Netz der TI in der Anschlussvariante "Redundante Anbindung" für diesen Zeitraum als nicht verfügbar. [<=]
Tabelle 67: Tab_gemSpec_Perf_Berichtsformat_Zentrales-Netz-TI
| Operation / Usecase |
Aufgerufene Schnittstelle::Operation |
|---|---|
| ZN_1 | I_IP_Transport::check_Simple_Connection |
| ZN_2 | I_IP_Transport::check_Redundant_Connection |
A_24872 - Performance - Rohdaten - Spezifika Zentrales Netz - Duration (Rohdatenerfassung v.02)
Der Produkttyp Zentrales Netz der TI MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder folgendes berücksichtigen: Die Messung der Bearbeitungszeit (Roundtrip Time) beginnt mit dem Versenden des ersten Bytes der zu übertragenden IP-Pakete vom Start-SZZP zum Ziel-SZZP oder vom Start-SZZP zum VPN-Konzentrator des SZZP-light und endet mit der Annahme des letzten Bytes der Antwortnachricht. [<=]
A_24873 - Performance - Rohdaten - Spezifika Zentrales Netz - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp Zentrales Netz der TI - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_Zentrales Netz-TI festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 68 : Tab_gemSpec_Perf_Fehlercodes_Zentrales-Netz-TI
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 77101 |
ZN_ERROR_OPERATION_FAILURE |
Schnittstellenaufruf konnte nicht durchgeführt werden |
A_24874 - Performance - Rohdaten- Spezifika Zentrales Netz - Message (Rohdatenerfassung v.02)
Der Produkttyp Zentrales Netz der TI MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:
{ "srcid": "$source-id", "dstid": "$destination-id", "plr": "$packageLostRate", "bkdur": "$backendDuration" }
- $source-id= SZZP-ID gem. IP-Config-Management des Senders, Datentyp Integer
- $destination-id= SZZP-ID gem. IP-Config-Management des Empfängers, Datentyp Integer
- $packageLostRate = Prozentuale Verlustrate der IP-Pakete vom Start-SZZP zum Ziel-SZZP oder vom Start-SZZP zum VPN-Konzentrator des SZZP-light, Datentyp Integer
- $backendDuration= RoundTrip Zeit in msec für den Transport der IP-Pakete über das Internet beim Anbindungstypen SZZP-light, Datentyp Integer
3.21.3 Bestandsdaten Zentrales Netz der TI
Bestandsdaten sind im Gegensatz zum Rohdaten-Performance-Reporting die Abfragen von Statusinformationen zu einem spezifizierten Abfragezeitpunkt. Im Folgenden sind Bestandsdaten Anforderungen für den Produkttypen Zentrales Netz der TI spezifiziert.
A_24898 - Performance - Zentrales Netz - Bestandsdaten
Der Anbieter des Produkttypen Zentrales Netz der TI MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen für jeden SZZP und SZZP-light des zentralen Netzes der TI berichten:
- Wert der aktuellen eingehenden Datenrate des Interfaces in Bits/Sekunde
- Wert der aktuellen ausgehenden Datenrate des Interfaces in Bits/Sekunde
- Wert des gesamt aufgetretenen Datenvolumens im Zeitintervall (seit letzten Messpunkt) in KByte
A_24899 - Performance - Zentrales Netz - Lieferweg und Format für Bestandsdaten
Der Anbieter des Produkttypen Zentrales Netz der TI MUSS die Informationen aus [A_24898] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [A_23110] mit Einschränkungen* liefern. Für jeden SZZP / SZZP-light ist dabei innerhalb des JSON Objektes szzp-information ein eigenständiges JSON Objekt szzp-x zu erstellen. Das x ist durch die jeweilige SZZP-ID gem. IP-Config-Management zu ersetzen:
{
"timestamp": <Zeitstempel der Abfrage als String im Format ISO 8601>,
"ci": <CI-ID der abgefragten Produktinstanz gemäß [A_17764] als String>,
"szzpInfo": {
"szzp_x": {
"rate_in": <Aktuell eingehende Datenrate des Interfaces in Kbit/sek als Integer>,
"rate_out": <Aktuell ausgehende Datenrate des Interfaces in Kbit/sek als Integer>,
"total": <Gesamt aufgetretenes Datenvolumen in KByte im Zeitintervall (seit letzten Messzeitpunkt) als Integer>
}
}
}
* Einschränkungen: Da bei dieser Lieferung keine Datei übermittelt wird, sondern die Daten direkt im Request-Body geliefert werden, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_23110] NICHT notwendig. [<=]
3.22 Sicherheitsgateway für Bestandsnetze
Das Sicherheitsgateway für Bestandsnetze ist ein Anbindungstyp zur Anbindung von Standorten an das Zentrale Netz der TI. Der Produkttyp Sicherheitsgateway für Bestandsnetze besteht aus den folgenden Komponenten:
- VPN-Konzentrator und Sicherheitsgateway
- Internetanschluss für die Komponenten VPN-Konzentrator und Sicherheitsgateway
- VPN-Anschlusspunkt
Über das Sicherheitsgateway Bestandsnetze sind die Dienste von Bestandsnetzen für Clientsysteme erreichbar. Das zentrale Netz der TI dient dabei nur dem Transport der Daten. Ein Zugriff der Dienste von Bestandsnetzen auf zentrale Dienste der TI-Plattform oder auf fachanwendungsspezifische Dienste wird durch das Sicherheitsgateway verhindert.
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des Produkttypen Sicherheitsgateway für Bestandsnetze aufgeführt.
3.22.1 Leistungsanforderungen Sicherheitsgateway für Bestandsnetze
3.22.1.1 Lastmodell Sicherheitsgateway für Bestandsnetze
Keine spezifischen Anforderungen zum Lastmodell
3.22.1.2 Bearbeitungszeiten Sicherheitsgateway für Bestandsnetze
Sind im Folgekapitel "Performancevorgaben Zentrales Netz der TI" mit enthalten.
3.22.1.3 Performancevorgaben Sicherheitsgateway für Bestandsnetze
Es gelten die zugeordneten Performancevorgaben aus Kapitel 5.2 Produkttypen der zentralen Zone der TI-Plattform:
3.22.2 Rohdaten-Performance-Reporting Sicherheitsgateway für Bestandsnetze
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.22.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang
3.22.2.2 Format
A_24902 - Performance - Rohdaten - Spezifika Sicherheitsgateway Bestandsnetze - Operation (Rohdatenerfassung v.02)
Der Produkttyp Sicherheitsgateway für Bestandsnetze MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Sicherheitsgateway-Bestandsnetze berücksichtigen.
Für die Schnittstellenoperation I_Secure_Access_Bestandsnetz::check_Connection MUSS gewährleistet sein, dass die Schnittstelle innerhalb von 5 Minuten für alle Verbindungen vom zentralen AZPD SZZP zum VPN-Anschlusspunkt im jeweiligen Bestandsnetz jeweils mindestens einmal ausgeführt wird. Erfolgt dies nicht und erfolgt keine Nachlieferung gemäß A_22005, gilt das Sicherheitsgateway für Bestandsnetze für diesen Zeitraum als nicht verfügbar. [<=]
Tabelle 69: Tab_gemSpec_Perf_Berichtsformat_Sicherheitsgateway-Bestandsnetze
| Operation / Usecase |
Aufgerufene Schnittstelle::Operation |
|---|---|
| SGW_CHECK | I_Secure_Access_Bestandsnetz::check_Connection |
A_24903 - Performance - Rohdaten - Spezifika Sicherheitsgateway Bestandsnetze - Duration (Rohdatenerfassung v.02)
Der Produkttyp Sicherheitsgateway für Bestandsnetze MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder folgendes berücksichtigen: Die Messung der Bearbeitungszeit (Roundtrip Time) beginnt mit dem Versenden des ersten Bytes der zu übertragenden IP-Pakete vom zentralen AZPD SZZP zum VPN-Anschlusspunkt im jeweiligen Bestandsnetz und endet mit der Annahme des letzten Bytes der Antwortnachricht. [<=]
A_24904 - Performance - Rohdaten - Spezifika Sicherheitsgateway Bestandsnetze - Status (Rohdatenerfassung v.02)
Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp Sicherheitsgateway für Bestandsnetze - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_Sicherheitsgateway-Bestandsnetze festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS ein definierter Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler verwendet werden. [<=]
Tabelle 70: Tab_gemSpec_Perf_Fehlercodes_Sicherheitsgateway-Bestandsnetze
| Statuscode |
Definition |
Beschreibung |
|---|---|---|
| 77201 |
SGW_ERROR_OPERATION_FAILURE |
Schnittstellenaufruf konnte nicht durchgeführt werden |
A_24905 - Performance - Rohdaten - Spezifika Sicherheitsgateway Bestandsnetze - Message (Rohdatenerfassung v.02)
Der Produkttyp Sicherheitsgateway für Bestandsnetze MUSS bei Rohdaten-Performance-Berichten im "message"-Feld die folgenden Daten im JSON-Format übermitteln:
{ "srcid": "$source-id", "dstid": "$destination-id", "plr": "$packageLostRate" }
- $source-id= SZZP-ID gem. IP-Config-Management des Senders, Datentyp Integer
- $destination-id= SZZP-ID gem. IP-Config-Management des Sicherheitsgateways, Datentyp Integer
- $packageLostRate = Prozentuale Verlustrate der IP-Pakete, Datentyp Integer
3.22.3 Bestandsdaten Sicherheitsgateway für Bestandsnetze
Bestandsdaten sind im Gegensatz zum Rohdaten-Performance-Reporting die Abfragen von Statusinformationen zu einem spezifizierten Abfragezeitpunkt. Im Folgenden sind Bestandsdaten Anforderungen für den Produkttypen Zentrales Netz der TI spezifiziert.
A_24907 - Performance - Sicherheitsgateway Bestandsnetze - Bestandsdaten
Der Anbieter des Produkttypen Sicherheitsgateway für Bestandsnetze MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen für das Sicherheitsgateway für Bestandsnetze berichten:
- Wert des gesamt aufgetretenen Datenvolumens je Sicherheitsgateway im Zeitintervall (seit letzten Messpunkt) in KByte
A_24908 - Performance - Sicherheitsgateway Bestandsnetze - Lieferweg und Format für Bestandsdaten
Der Anbieter des Produkttypen Sicherheitsgateway für Bestandsnetze MUSS die Informationen aus [A_24907] jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [A_23110] mit Einschränkungen* liefern. Für jedes Sicherheitsgateway ist dabei innerhalb des JSON Objektes sgwInfo ein eigenständiger Integer Key names sgw-x zu erstellen. Das x ist durch die jeweilige SZZP-ID gem. IP-Config-Management zu ersetzen:
{
"timestamp": <Zeitstempel der Abfrage als String im Format ISO 8601>,
"ci": <CI-ID der abgefragten Produktinstanz gemäß [A_17764] als String>,
"sgwInfo": {
"sgw_x": <Gesamt aufgetretenes Datenvolumen in KByte im Zeitintervall (seit letzten Messzeitpunkt) als Integer>
}
}
* Einschränkungen: Da bei dieser Lieferung keine Datei übermittelt wird, sondern die Daten direkt im Request-Body geliefert werden, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_23110] NICHT notwendig. [<=]
3.23 eHealth-CardLink
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an die Lieferung von Ereignisdaten des eHealth-CardLink aufgeführt.
3.23.1 Leistungsanforderungen eHealth-CardLink
Die Anwendungsfälle zum eHealth-CardLink setzen den Workflow zur Authentifizierung der eGK des Versicherten und dem Konnektor einer Leistungserbringerinstitution zur Erstellung eines VSDM-Prüfnachweises „VSDM+“ um. Dieser Prüfnachweis dient zur Autorisierung von Leistungserbringerinstitutionen an TI-Fachdiensten.
Dabei wird der folgende performance-relevante Anwendungsfall gemäß [gemSpec_eHealth-CardLink] betrachtet:
- Mobiles Erstellen eines VSDM-Prüfungsnachweises mit eGK ohne PIN
Bei dem genannten UseCase wird von einer existierenden, authentifizierten Nutzer-Session ausgegangen. Die jeweils übertragene Datenmenge hängt von der Anzahl der Authentifizierungsvorgänge ab. Je Anwendungsfall wird von einer Datenmenge von 10 kByte ausgegangen.
In der Lastbetrachtung wird von 834.000 Authentifizierungsvorgängen pro Tag ausgegangen.
3.23.1.1 Lastmodell eHealth-CardLink
3.23.1.2 Bearbeitungszeiten eHealth-CardLink
A_24810 - Performance - eHealth-CardLink - Bearbeitungszeit unter Last
Der Produkttyp eHealth-CardLink MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eHealth-CardLink: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.
Die Messung für die Bearbeitungszeit beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem SICCT Kommando des Konnektors an den Produkttypen, den erstellten Prüfungsnachweis in die Karte zu schreiben.
Tabelle 71 Tab_gemSpec_Perf_eHealth-CardLink: Last- und Bearbeitungszeitvorgaben
| UseCase-Bezug | Operation | Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|---|---|---|---|---|
| CL.UC_1 | Mobiles Erstellen eines VSDM-Prüfungsnachweises mit eGK ohne PIN | 58 | 645 | 832 |
3.23.1.3 Performancevorgaben eHealth-CardLink
A_24811 - Performance - eHealth-CardLink - Robustheit gegenüber Lastspitzen
Der eHealth-CardLink MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_eHealth-CardLink: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben. [<=]
Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß den definierten Spitzenlasten zu verarbeitende Anzahl von Anfragen hinausgehen, kann der eHealth-CardLink 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 des eHealth-CardLinks hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.
Im Zuge des Zulassungsverfahrens hat der Anbieter des eHealth-CardLinks 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_24813 - Performance eHealth-CardLink - Skalierung
Der Anbieter des eHealth-CardLink MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]
3.23.2 Ereignisdaten eHealth-CardLink
A_25265 - Ereignisdaten - Ereignisoperationen - eHealth-CardLink
Der Anbieter MUSS bei jeder Ausführung des Anwendungsfalles "Mobiles Erstellen eines VSDM-Prüfungsnachweises mit eGK ohne PIN" gemäß [gemSpec_eHealth-CardLink], eine dazugehörige Ereignislieferung auslösen.
[<=]
A_25266 - Ereignisdaten - Format der Lieferung - POST-Body - eHealth-CardLink
Der Anbieter MUSS bei der Ereignislieferung im POST-Body folgendes Schema vollständig implementieren:
{
Einschränkung: Wird das Feld "eventId" mit einem validen Wert, z.B. 3 beschrieben, so ist per Definition das Feld "err" mit dem Null-Objekt zu hinterlegen und umgekehrt.
Hinweis: Bei der Erstellung des JSON-Inhalts ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden.
[<=]
A_25284 - Ereignisdaten - Format der Lieferung - eHealth-CardLink
Der Anbieter MUSS bei der Ereignislieferung folgende produktspezifischen Konvention erfüllen:
- Content-Encoding: kein Content Encoding Header und keine Komprimierung
3.24 Verzeichnisdienst FHIR
Der Verzeichnisdienst FHIR ist eine Erweiterung des bisherigen LDPA Verzeichnisdienstes der TI. Im VZD FHIR werden Einträge von Organisationen und Leistungserbringern gespeichert. Die Einträge aus dem bisherigen LDAP VZD werden in den VZD FHIR synchronisiert. Der VZD FHIR ist eine Implementierung basierend auf der FHIR-Spezifikation. FHIR ist ein von HL7 entwickelter Interoperabilitätsstandard, der den elektronischen Austausch von Gesundheitsdaten zwischen verschiedenen Systemen im Gesundheitswesen ermöglichen soll (http://hl7.org/fhir/summary.html).
Im Folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat des Verzeichnisdienstes FHIR aufgeführt.
3.24.1 Leistungsanforderungen Verzeichnisdienst FHIR
3.24.1.1 Lastmodell Verzeichnisdienst FHIR
Sind im Folgekapitel "Performancevorgaben Verzeichnisdienst" mit enthalten.
3.24.1.2 Bearbeitungszeiten Verzeichnisdienst FHIR
Sind im Folgekapitel "Performancevorgaben Verzeichnisdienst" mit enthalten.
3.24.1.3 Performancevorgaben Verzeichnisdienst FHIR
A_25215 - Performance - Verzeichnisdienst FHIR - Last- und Bearbeitungszeiten
Der Produkttyp Verzeichnisdienst FHIR MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_VZD_FHIR: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.
Table # Tab_gemSpec_Perf_VZD_FHIR: Last- und Bearbeitungszeitvorgaben
| UseCase-Bezug | Fachdienstoperation | Spitzenlast [1/s] |
Mittlere Bearbeitungszeit [ms] |
Maximale Bearbeitungszeit [ms] |
|---|---|---|---|---|
| VZDF.UC_1_1 | GET [baseUrl]/search | 500 | 1000 | 1250 |
| VZDF.UC_2_1 | GET [baseUrl]/fdv/search | 500 | 1000 | 1250 |
| VZDF.UC_3_1 | GET [baseUrl]/owner | 20 | 1000 | 1250 |
| VZDF.UC_3_2 | POST [baseUrl]/owner | 20 | 1000 | 1250 |
| VZDF.UC_3_3 | PUT [baseUrl]/owner | 20 | 1000 | 1250 |
| VZDF.UC_3_4 | DELETE [baseUrl]/owner | 20 | 1000 | 1250 |
| VZDF.UC_4_1 | GET [baseUrl]/tim-provider-services/ | 1 | 1000 | 1250 |
| VZDF.UC_4_2 | GET [baseUrl]/tim-provider-services/FederationList/federationList.jws | 1 | 1000 | 1250 |
| VZDF.UC_4_3 | GET [baseUrl]/tim-provider-services/localization | 50 | 1000 | 1250 |
| VZDF.UC_4_4 | GET [baseUrl]/tim-provider-services/federationCheck | 1 | 1000 | 1250 |
| VZDF.UC_4_5 | GET [baseUrl]/tim-provider-services/federation | 1 | 1000 | 1250 |
| VZDF.UC_4_6 | POST [baseUrl]/tim-provider-services/federation | 1 | 1000 | 1250 |
| VZDF.UC_4_7 | PUT /tim-provider-services/federation | 1 | 1000 | 1250 |
| VZDF.UC_4_8 | DELETE [baseUrl]/tim-provider-services/federation | 1 | 1000 | 1250 |
| VZDF.UC_5_1 | GET [baseUrl]/PersonInstitutionLink/ | 1 | 1000 | 1250 |
| VZDF.UC_5_2 | GET [baseUrl]/PersonInstitutionLink/Link | 1 | 1000 | 1250 |
| VZDF.UC_5_3 | POST [baseUrl]/PersonInstitutionLink/Link | 1 | 1000 | 1250 |
| VZDF.UC_5_4 | PUT [baseUrl]/PersonInstitutionLink/Link | 1 | 1000 | 1250 |
| VZDF.UC_5_5 | DELETE [baseUrl]/PersonInstitutionLink/Link | 1 | 1000 | 1250 |
| VZDF.UC_6_1 | GET [baseUrl]/tim-authenticate | 50 | 1000 | 1250 |
| VZDF.UC_6_2 | GET [baseUrl]/service-authenticate | 20 | 1000 | 1250 |
| VZDF.UC_6_3 | GET [baseUrl]/owner-authenticate | 20 | 1000 | 1250 |
| VZDF.UC_6_4 | POST [baseUrl]/owner-authenticate-decoupled | 20 | 1000 | 1250 |
| VZDF.UC_6_5 | POST [baseUrl]/owner-authenticate-poll | 20 | 1000 | 1250 |
| VZDF.UC_6_6 | GET [baseUrl]/ti-provider-authenticate | 20 | 1000 | 1250 |
| VZDF.UC_7_1 | POST [baseUrl]/ti-provider/token | 20 | 1000 | 1250 |
3.24.2 Rohdaten-Performance-Reporting Spezifika Verzeichnisdienst FHIR
In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.
3.24.2.1 Umfang
Keine spezifischen Anforderungen zum Umfang
3.24.2.2 Format
A_25216 - Performance - Rohdaten - Spezifika Verzeichnisdienst FHIR - Operation (Rohdatenerfassung v.02)
Der Produkttyp Verzeichnisdienst FHIR MUSS bei Rohdaten-Performance-Berichten bzgl. des "operation"-Feldes die Angabe der Spalte "Operation / Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VZD_FHIR berücksichtigen.
Table # Tab_gemSpec_Perf_Berichtsformat_VZD_FHIR
| Operation / Usecase | Fachdienstoperation | Message |
|---|---|---|
| VZDF.UC_1_1 | GET [baseUrl]/search | { "rt": "$resourceType", "serc": $searchedResourceCount, "sepc": $searchedParameterCount, "size": $responseSize } |
| VZDF.UC_2_1 | GET [baseUrl]/fdv/search | { "rt": "$resourceType", "serc": $searchedResourceCount, "sepc": $searchedParameterCount, "size": $responseSize } |
| VZDF.UC_3_1 | GET [baseUrl]/owner | { "rt": "$resourceType", "serc": $searchedResourceCount, "sepc": $searchedParameterCount, "size": $responseSize } |
| VZDF.UC_3_2 | POST [baseUrl]/owner | { "rt": "$resourceType" } |
| VZDF.UC_3_3 | PUT [baseUrl]/owner | { "rt": "$resourceType" } |
| VZDF.UC_3_4 | DELETE [baseUrl]/owner | { "rt": "$resourceType" } |
| VZDF.UC_4_1 | GET [baseUrl]/tim-provider-services/ | - |
| VZDF.UC_4_2 | GET [baseUrl]/tim-provider-services/FederationList/federationList.jws | - |
| VZDF.UC_4_3 | GET [baseUrl]/tim-provider-services/localization | - |
| VZDF.UC_4_4 | GET [baseUrl]/tim-provider-services/federationCheck | - |
| VZDF.UC_4_5 | GET [baseUrl]/tim-provider-services/federation | - |
| VZDF.UC_4_6 | POST [baseUrl]/tim-provider-services/federation | - |
| VZDF.UC_4_7 | PUT /tim-provider-services/federation | - |
| VZDF.UC_4_8 | DELETE [baseUrl]/tim-provider-services/federation | - |
| VZDF.UC_5_1 | GET [baseUrl]/PersonInstitutionLink/ | - |
| VZDF.UC_5_2 | GET [baseUrl]/PersonInstitutionLink/Link | { "size": $responseSize , "sest": $searchedStatus} |
| VZDF.UC_5_3 | POST [baseUrl]/PersonInstitutionLink/Link | - |
| VZDF.UC_5_4 | PUT [baseUrl]/PersonInstitutionLink/Link | - |
| VZDF.UC_5_5 | DELETE [baseUrl]/PersonInstitutionLink/Link | - |
| VZDF.UC_6_1 | GET [baseUrl]/tim-authenticate | { "bkdur": $backendDuration } |
| VZDF.UC_6_2 | GET [baseUrl]/service-authenticate | - |
| VZDF.UC_6_3 | GET [baseUrl]/owner-authenticate | { "bkdur": $backendDuration } |
| VZDF.UC_6_4 | POST [baseUrl]/owner-authenticate-decoupled | { "bkdur": $backendDuration } |
| VZDF.UC_6_5 | POST [baseUrl]/owner-authenticate-poll | - |
| VZDF.UC_6_6 | GET [baseUrl]/ti-provider-authenticate | - |
| VZDF.UC_7_1 | POST [baseUrl]/ti-provider/token | - |
A_25217 - Performance - Rohdaten - Spezifika Verzeichnisdienst FHIR - Duration (Rohdatenerfassung v.02)
Der Produkttyp Verzeichnisdienst FHIR MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger.
Für die UseCases VZDF.UC_6_1, VZDF.UC_6_3 und VZDF.UC_6_4 MUSS der Produkttyp Verzeichnisdienst FHIR zusätzlich die Angabe der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Duration_VZD_FHIR berücksichtigen.
Table # - Tab_gemSpec_Perf_Duration_VZD_FHIR
| UseCase | Fachdienstoperation | Duration |
|---|---|---|
| VZDF.UC_6_1 | GET [baseUrl]/tim-authenticate | Die Messung der Bearbeitungszeit pausiert mit der Weiterleitung der Nachricht an den Matrix-Homeserver und läuft mit Erhalt der Antwort vom Matrix-Homeserver weiter. |
| VZDF.UC_6_3 | GET [baseUrl]/owner-authenticate | Die Messung der Bearbeitungszeit pausiert mit Aufruf der Authenticator App durch den Client und läuft mit Erhalt des auth_codes von der Authenticator App weiter. Die Messung der Bearbeitungszeit pausiert erneut mit Versand des auth_codes durch den Auth-Service an den Identity Provider und läuft mit Erhalt des ID_Tokens vom Identity Provider weiter. |
| VZDF.UC_6_4 | POST [baseUrl]/owner-authenticate-decoupled | Die Messung der Bearbeitungszeit pausiert mit Aufruf der Authenticator App durch den Client und läuft mit Erhalt des auth_codes von der Authenticator App weiter. Die Messung der Bearbeitungszeit pausiert erneut mit Versand des auth_codes durch den Auth-Service an den Identity Provider und läuft mit Erhalt des ID_Tokens vom Identity Provider weiter. Die Messung endet mit der Bereitstellung des owner-access-token. |
A_25218 - Performance - Rohdaten - Spezifika Verzeichnisdienst FHIR - Message (Rohdatenerfassung v.02)
Der Produkttyp Verzeichnisdienst FHIR MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.
{ "rt": "$resourceType", "serc": $searchedResourceCount, "sepc": $searchedParameterCount, "size": $responseSize, "sest": $searchedStatus, "bkdur": $backendDuration }
- $resourceType = Aufgerufener FHIR-Ressource-Typ gem. [gemSpec_VZD_FHIR_Directory#Kap. 4.1.1 Datenmodell#VZD-FHIR-Directory, FHIR-Ressourcen], Datentyp String
- $searchedResourceCount = Anzahl der in der Suche genutzten FHIR-Ressourcen-Typen, die in Verbindung mit den Suchparametern verwendet werden, Datentyp Integer
- $searchedParameterCount = Anzahl der in der Suche genutzten FHIR-Ressourcen-Parameter, Datentyp Integer
- $responseSize = Größe der Antwortnachricht der Suchanfrage in Kbyte, Datentyp Integer
- $searchedStatus = Gesuchter Status gem. Parameter "status" der Operation GET [baseURL]/PersonInstitutionLink/Link, Datentyp String
- $backendDuration = Zeit in ms, welche die Kommuniktion mit dem Matrix-Homeserver oder dem Identity Provider beinhaltet und nicht Bestandteil der Bearbeitungszeit ist, Datentyp Integer
Für die jeweilige Operation sind dabei nur die in der Spalte "Message" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VZD_FHIR angegebenen Daten zu übermitteln. Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und die Spezifikation [RFC7493] eingehalten wird. [<=]
A_25228 - Performance - Rohdaten - Spezifika Verzeichnisdienst FHIR - Status (Rohdatenerfassung v.02)
Der Produkttype Verzeichnisdienst FHIR-Directory MUSS - bei Rohdaten-Performance-Berichten bzgl. des "status-Feldes" - einen definierten Standard-Statuscode gemäß A_22500 für interne bzw. externe Fehler senden. [<=]
4 Leistungsanforderungen für Anwendungsfälle
Das vorliegende Kapitel erfasst die Leistungsanforderungen aus den Anwendungen der TI im Wirkbetrieb:
- Versichertenstammdaten-Management (VSDM)
- 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.
4.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.
4.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.
Die Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer" gibt die Zahl der Versicherten, der niedergelassenen Leistungserbringer und der Krankenhäuser an. Es folgt eine Größenklassifizierung der Praxen in Tabelle "Tab_Mengengerüst: Lokationen" sowie der Krankenhäuser in Tabelle "Tab_Mengengerüst: Krankenhäuser". Die Tabelle "Tab_Mengengerüst: Annahmen für Modellierung" 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 72: Tab_Mengengerüst: Versicherte und Leistungserbringer
|
ID
|
Größe
|
Anzahl
|
Quelle
|
|---|---|---|---|
|
M1
|
Gesetzlich Krankenversicherte der Bundesrepublik Deutschland 2008 |
70.000.000 (74.000.000) |
[GBE_Bund] (BMG 2024) |
|
M2
|
Ärzte |
138.500 (421.000) |
[KBV2010] (BÄK 2022) |
|
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 73: Tab_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 74: Tab_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 75: Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen
| Klasse der Leistungserbringer- 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 "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" 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 76: Tab_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 |
| M29 |
Dauer Modellarbeitstag Apotheke | 10 h |
Festlegung |
| M24 |
KOM-LE-Teilnehmer |
210.109 |
Annahme: M2 + M3 + M4 + M28 |
4.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 "Tab_VSDM Anwendungsfälle" 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 77: Tab_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 "Tab_VSDM Anwendungsfälle" berücksichtigt.
4.1.3 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.
4.1.4 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.
4.1.5 Elektronische Patientenakte (ePA)
[verschoben / bereinigt ... siehe Kapitel 3.18- ePA-Aktensystem]
4.1.6 Tokenbasierte Authentisierung (TBAuth)
[verschoben in 3.1.1.1 Lastmodell IDP-Dienste]
4.1.7 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).
Lastmodell: Nutzung bestehender Anwendungen und Netze
Für die Nutzung bestehender Anwendungen und Netze liegt die Leistung der TI-Plattform auf Netzwerkebene. Tabelle "Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze" gibt die Spitzenlast hierfür an.
Tabelle 78: Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze
| Spitzenlast in MBit/sec (jeweils down- und upload-Richtung) |
|---|
| 150 |
Lastmodell: VSDM-Anwendungsfälle und die davon unabhängige Nutzung der Basisdienste
Für VSDM und die davon unabhängige Nutzung der Basisdienste QES, digitale Signatur und Verschlüsselung wird die Spitzenlast auf Ebene der Anwendungsfallaufrufe durch die folgenden vier Tabellen definiert.
Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" 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 den folgenden Tabellen 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 "Tab_Mengengerüst: Annahmen für Modellierung" 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 "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" 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 79: Tab_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 "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" 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 "Tab_Mengengerüst: Lokationen" ausgegangen.
Tabelle 80: Tab_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 81: Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen
| Anwendungsfall |
Datenmenge pro Anwendungsfall 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 "Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" und Tabelle "Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer".
Tabelle 82: Tab_Lastmodell: Krankenhäuser (Quelle: [DKG2010])
| Anwendungsfall |
Datenmenge pro Anwendungsfall 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 "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" 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 "Tab_Lastmodell: Krankenhäuser" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen".
Lastmodell: KOM-LE-Anwendungsfälle
Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle wird in Tabelle "Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie in Tabelle "Lastmodell: KOM-LE in Krankenhäusern" 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 83: Tab_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 84: Tab_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 "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" aufgeführten „Ärzte“.
Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle für Nachrichten mit Anhängen größer 25 MB ist in Tabelle "Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten" dargestellt.
Tabelle 85: Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten
| Anwendungsfall |
Mengengröße x |
Spitzenlasten pro Tag |
Spitzenlast- erhöhungsfaktor |
|---|---|---|---|
| Abrechnungsdaten übermitteln |
x: Anzahl KOM-LE Teilnehmer |
1 * x |
2 |
| Abrechnungsdaten empfangen |
1 * x |
2 |
|
| Bilder oder andere Aufnahmen zur Diagnostik senden |
0,15 * x |
2 |
|
| Bilder oder andere Aufnahmen zur Diagnostik empfangen |
0,45 * x |
2 |
|
| Sonstige Große Anhänge in Mail senden |
0,25 * x |
2 |
|
| Sonstige Große Anhänge in Mail empfangen |
0,50 * x |
2 |
|
| Herausgabe von Patientendaten |
x: Anzahl d. Versicherten |
0,12 * x |
- |
In der Lastbetrachtung wird davon ausgegangen, dass für den Anwendungsfall: "Bilder oder andere Aufnahmen zur Diagnostik empfangen" es je Sender 3 Empfänger gibt. Für den Anwendungsfall: "Sonstige Große Anhänge in Mail empfangen" wird angenommen, dass es je Sender 2 Empfänger gibt.
Lastmodell: NFDM-Anwendungsfälle
Die erwartete Nutzungsrate der NFDM-Anwendungsfälle wird in Tabelle "Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie inkludiert in Tabelle "Tab_Lastmodell: Krankenhäuser" 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 "Tab_Lastmodell: Krankenhäuser" 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 86: Tab_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 |
Lastmodell: Für eMP/AMTS-Anwendungsfälle
Die erwartete Nutzungsrate der eMP/AMTS-Anwendungsfälle wird in Tabelle "Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken" 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 87: Tab_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.
4.1.8 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 "Tab_Mengenrahmen „Update Konnektor und Kartenterminals“" listet die Annahmen, die für den Mengenrahmen dieses betrieblichen Anwendungsfalls getroffen werden.
Tabelle 88: Tab_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 |
4.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).
4.2.1 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 "Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall" angegebenen Mittelwertschranken sein.
Tabelle 89: Tab_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“.
4.2.2 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 "Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall" angegebenen Mittelwertschranken sein.
Tabelle 90: Tab_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 |
4.2.3 Bearbeitungszeiten elektronische Patientenakte (ePA)
[verschoben / bereinigt ... siehe 3.18]
4.2.4 Bearbeitungszeiten Tokenbasierte Authentisierung
[verschoben in 3.x.1.2 Bearbeitungszeiten IDP-Dienste]
4.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 "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus" 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 91: Tab_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.
Die Tabelle "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept" zeigt beispielhaft für den Anwendungsfall „E-Rezept einstellen“ eine erzielbare Gesamtverfügbarkeit von 99,90 %, die einer Ausfallzeit pro Monat von kleiner 7 Minuten entspricht.
Tabelle 92: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept
| Anwendungsfall bzw. Produkttyp |
Verfügbarkeit |
Ausfallzeiten pro Monat in Minuten |
|
|---|---|---|---|
| E-Rezept einstellen |
99,90% |
< 7 |
|
| |
Clientsystem |
99,99% |
< 1 |
| Konnektor und eHealth-Kartenterminal |
99,99% |
< 1 |
|
| Transportnetz |
99,98% |
< 1 |
|
| Zentrale TI-Plattform: VPN-Zugangsdienst |
99,99% |
< 1 |
|
| Zentrale TI-Plattform: OCSP-Responder |
99,99% |
< 1 |
|
| Zentrale TI-Plattform: Zentrales Netz TI |
99,99% |
< 1 |
|
| Zentrale TI-Plattform: Namensdienst |
99,99% |
< 1 |
|
| E-Rezept-Fachdienst |
99,99% |
< 1 |
|
| IdP | 99,99% |
< 1 |
|
5 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 "Tab_Caching-Dauer"
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 93: Tab_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 6 unterscheidet hierzu vier Typen von Anforderungen danach, wie sehr die Anforderungen bzgl. Bearbeitungszeit und Lastverhalten ineinandergreifen.
Abbildung 6: 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).
5.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.
5.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT
Performance-Anforderungen an die Smartcards im Gesundheitswesen werden im Rahmen der Kartenspezifikationen gestellt.
5.1.2 Produkttyp Konnektor
Der Produkttyp Konnektor muss alle Einsatzumgebungen von einer Arztpraxis bis zu großen Krankenhäusern abdecken. Diese unterteilt Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebung" 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 94: 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 95: 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 Leistungserbringerumgebung 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 96: 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 "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" stellt für diese Situation dar, wie groß die Wahrscheinlichkeit ist, dass n Stapelsignaturen oder mehr parallel erfolgen müssen.
Tabelle 97: 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 der Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" 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 "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" wie folgt dar:
Tabelle 98: 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 7: 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 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
- 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 8: 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_gemKPT_Betr_Produkttypen gemäß [gemKPT_Betr])
- 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.
[<=]5.1.2.1 Fachmodul ePA
[nicht mehr relevant mit ePA3.0]
5.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 99: 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 9: 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.
5.1.4 Produkttyp Mobiles Kartenterminal
An das Mobile Kartenterminal werden keine Performance-Anforderungen gestellt.
5.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]
5.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 /CRL-Dienst und Komponente Provisioning/Revocation), gematik-Root-CA (Komponente OCSP-Responder), Verzeichnisdienst, Service Monitoring, Signaturdienst 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 „redundante Anbindung“ 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 „redundante Anbindung“ bereitstellen und eine Verfügbarkeit über alle IP-Verbindungen zwischen allen sicheren zentralen Zugangspunkten (SZZP) mit der Anschlussoption „redundante Anbindung“ 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 „einfache Anbindung“ 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 „einfache Anbindung“ 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. [<=]
A_14738 - Performance – zentrales Netz – Verfügbarkeit – SZZP-light, Anschlussvariante „redundante Anbindung“
Das Zentrale Netz der TI MUSS für den Anschlusstyp SZZP-light die Anschlussvariante „redundante Anbindung“ bereitstellen und in dieser Variante eine Verfügbarkeit über alle Komponenten des SZZP-light Anschlusses von 99,98% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen. Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen.
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. [<=]
A_14739 - Performance – zentrales Netz – Verfügbarkeit – SZZP-light, Anschlussoption „einfache Anbindung“
Das Zentrale Netz der TI MUSS für den Anschlusstyp SZZP-light die Anschlussvariante „einfache Anbindung“ bereitstellen und in dieser Variante eine Verfügbarkeit über alle Komponenten des SZZP-light Anschlusses von 99,8% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen. Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen.
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_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.
[<=]A_20570 - Performance – Standortübergreifende Redundanz
Der Anbieter MUSS zur Erfüllung der geforderten Verfügbarkeit eine standortübergreifende Redundanzlösung einsetzen. Dazu MUSS der Anbieter bei der Inbetriebnahme die Funktionsfähigkeit der standortübergreifende Redundanz eigenverantwortlich nachweisen und die Funktionsweise der standortübergreifende Redundanzlösung hinreichend detailliert beschreiben. Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
[<=]
A_20569 - Performance – Standortredundanz
Der Anbieter MUSS zur Erfüllung der geforderten Verfügbarkeit eine Standortredundanzlösung einsetzen. Dazu MUSS der Anbieter bei der Inbetriebnahme die Funktionsfähigkeit der Standortredundanz eigenverantwortlich nachweisen und die Funktionsweise der Standortredundanzlösung hinreichend detailliert beschreiben.. [<=]
Am selben Standort wird die netzwerktechnische Anbindung zu einer Instanz eines mehrfach ausgeprägten Produktes getrennt. Die Last muss von den anderen, verbliebenen Instanzen übernommen werden, ohne Fehlermeldungen. Der Standort muss dabei die Performancevorgaben ohne diese eine getrennte Instanz weiterhin erfüllen.
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_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.
[<=]5.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].
Tabelle 100: 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 |
1000
|
1000
|
1250
|
| I_Directory_Maintenance |
|
|||
| |
add_Directory_Entry |
50
|
1000
|
1250
|
| |
read_Directory_Entry |
50
|
1000
|
1250
|
| |
modify_Directory_Entry |
50
|
1000
|
1250
|
| |
delete_Directory_Entry |
50
|
1000
|
1250
|
| I_Directory_Application_Maintenance |
|
|||
| |
add_Directory_FA_Attributes |
50
|
1000
|
1250
|
| |
delete_Directory_FA_Attributes |
50
|
1000
|
1250
|
| |
modify_Directory_FA_Attributes |
50
|
1000
|
1250
|
5.2.2 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 101: 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].
5.2.3 Produkttyp Service Monitoring
Für den Produkttypen Service Monitoring gelten folgende Anforderungen: [GS-A_4155],[GS-A_3055],[GS-A_3058], [GS-A_4145].
5.2.4 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 102: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben
|
Schnittstellenoperationen
|
Lastvorgaben
|
Bearbeitungszeitvorgaben
|
|
|
Spitzenlast [1/sec] |
Mittelwert [msec] |
99%-Quantil [msec] |
|
| GetPublicKey |
100
|
100
|
174
|
| GetAuthenticationToken und KeyDerivation |
jeweils 100 |
in Summe 3700 |
in Summe 4147 |
A_18179 - Performance - Schlüsselgenerierungsdienst - zentral - Erfassung von Rohdaten
Der 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 5 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_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_20518 - Performance - Schlüsselgenerierungsdienst - am FD - Spitzenlastvorgaben TU
Der Anbieter Schlüsselgenerierungsdienst am FD MUSS in der TU-Umgebung 5% der für die in Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" genannten Operationen geltenden Spitzenlastvorgaben unter Einhaltung der mittleren Bearbeitungszeiten erfüllen.
Ist der Marktanteil kleiner als 5% MUSS der Anbieter Schlüsselgenerierungsdienst am FD nur den entsprechenden Prozentwert seines Marktanteils in der TU umsetzen. Der Prozentwert MUSS mit angegeben werden.
[<=]
A_18180 - Performance - Schlüsselgenerierungsdienst - am FD - Erfassung von Rohdaten
Der 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.
[<=]
5.3 Produkttypen VSDM
5.3.1 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 103: 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.
[<=]
5.4 Produkttyp APOVZD
5.4.1 Verfügbarkeit
Die Anforderungen an die Verfügbarkeit des Apothekenverzeichnisses richten sich nach der geforderten Verfügbarkeit der Schnittstellen des neuen Produkttyps, d.h. die Schnittstellen zum Abruf und Pflege der Apothekeninformationen müssen die gleiche Verfügbarkeit aufweisen.
A_21270 - Performance - Apothekenverzeichnis - Verfügbarkeit
Der Produkttyp Apothekenverzeichnis MUSS zur Hauptzeit eine Verfügbarkeit von 99,8 % 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.
[<=]
5.4.2 Last
Zur Abschätzung der Leistung der benötigten Hardware wird ein Anfrageaufkommen durch Clients (E-Rezept-FdV) geschätzt.
Tabelle 104: Tab_eRp_APOVZD_Anfrageaufkommen
| Anzahl potentieller Nutzer | ~80.000.000 |
|---|---|
| Annahme regelmäßige Nutzer E-Rezept-FdV (mittelfristig): 10 % der potentiellen Nutzer | 8.000.000 |
| Anzahl Rezepte pro Quartal: (1,7 - Dauermedikation, Chroniker) ~2, ergibt eine Anzahl Apothekenbesuche pro Quartal. |
1 |
| Unabhängig vom Cache der Apothekeninformationen wird angenommen, dass ein Client den Cache innerhalb eines Quartals aktualisiert, ergibt Aufrufe am Apothekenverzeichnis pro Quartal. | 16.000.000 |
| Anzahl Wochentage pro Quartal (Mo. – Fr.), abgeleitet aus durchschnittlichen Praxisöffnungszeiten). | 65 |
| Ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Tag. | ~246.000 |
| Anteil Spitzenstunde werktags: 1/5, ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Spitzenstunde. | ~50.000 |
| Ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Minute der Spitzenstunde. | ~833 |
| ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Sekunde der Spitzenstunde | ~14 |
Die Abschätzung ergibt ca. 14 parallele Aufrufe pro Sekunde.
5.4.3 Antwortzeiten
Die Informationen des Apothekenverzeichnisses stellen keine Voraussetzung für die Use Cases des E-Rezepts dar. Zudem wird davon ausgegangen, dass Clients Apothekeninformationen aus vorangegangenen Abfragen cachen. Eine Abschätzung der erwarteten Ergebnismenge pro Anfrage durch Clients ist ebenso schwer umzusetzen, da Suchkriterien von Versicherten stark variieren können und ebenso eine "Standardumkreissuche" an verschiedenen Orten in Deutschland eine verschiedene Anzahl Apotheken zurückgeben würde.
Die gematik beobachtet das Antwortzeitverhalten des Apothekenverzeichnisses im Rahmen des Servicemonitorings.
A_21189 - Apothekenverzeichnis - Bearbeitungszeit unter Last
Der Produkttyp Apothekenverzeichnis MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben" bei anliegender Spitzenlast erfüllen.
Tabelle 105: Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben
| UseCase Bezug | Operation | Spitzenlast [1/s] |
Mittelwert [ms] |
99 %-Quantil [ms] |
|---|---|---|---|---|
| APO.UC_1_1 | GET /Location GET /HealthcareService |
14 | 1000 | 1300 |
5.4.4 Bereitstellung Betriebsdaten
Die Rohdatenlieferung eines Produkttyps erfasst das Performanceverhalten von Diensten der TI.
Diese Rohdaten beinhalten folgende Informationen:
- Zeitpunkt des Aufrufs
- aufgerufene Operation
- Bearbeitungszeit des Aufrufes
- Datenmenge des durchgeführten Aufrufes
- Erfolg der Operationsbearbeitung
- gegebenenfalls weitere produkttypspezifische Informationen
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 eines Produkttyps werden über die Rohdaten nicht direkt gemeldet, dies erfolgt über das parallel durchgeführte Probing. Produkttypen erfassen Performance-Kenngrößen, protokollieren sie in einem Performance-Protokoll und stellen sie in dem hier festgelegten Performance-Berichtsformat bereit.
A_21271 - Apothekenverzeichnis - Erkennung Clientsystem User-Agent
Das Apothekenverzeichnis MUSS das vom aufrufenden Nutzer verwendete Clientsystem anhand des im HTTP-Request enthaltenen Header-Feld "User-Agent" gemäß [RFC7231] erkennen und in den Einträgen zur Performance-Rohdatenerfassung als $useragent gemäß [A_21272] protokollieren.
Das Apothekenverzeichnis MUSS bei fehlendem User-Agent-Header den Request mit dem HTTP-Status-Code 403 beantworten, damit in der Betriebsüberwachung des E-Rezept-Fachdienstes die Nutzung unzulässiger Frontends erkannt werden kann.
Dabei MUSS die Lieferung für $message im JSON-Format erfolgen, das heißt für $message der Wert $message = {"UA": "$useragent ", " Status ": $status}. Für $status ist der http-Code gemäß [A_21272] zu verwenden und es sind die folgenden Datenformate zu benutzen:
Typ UA: string
Typ Status: number (int)
[<=]
A_21272 - Apothekenverzeichnis - Rohdaten-Performance-Berichte - Format der Einträge des Performance Berichts Apothekenverzeichnis
Das Apothekenverzeichnis MUSS beim Übermitteln der Performance-Messwerte in einem Rohdaten-Performance-Bericht sämtliche Zeilen (Einträge) der Berichte in der folgenden Weise formatieren:
INFO:start[$timestamp] time[$duration_in_ms] tag[$operation] size[$size_in_kb] message[$message],
mit
$timestamp ein Unixzeit-Zeitstempel in Millisekunden,
$duration_in_ms die gemessene Bearbeitungszeit einer Operation in Millisekunden,
$operation ist die ausgeführte Operation $APO-operation des Produkttyps gemäß Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis
$size_in_kb ist die gemessene, übertragene Datenmenge einer Operation in Kilobyte.
$message (gemäß [A_21271])
Tabelle 106 : Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis
| $APO-operation | Produkttyp | Operation |
|---|---|---|
| APO.UC_1_1 | Apothekenverzeichnis | GET /Location GET /HealthcareService |
| APO.UC_2_1 | Apothekenverzeichnis | POST/PUT/PATCH/DELETE /Location POST/PUT/PATCH/DELETE /HealthcareService |
A_21273 - Apothekenverzeichnis - Messpunkte für die Erfassung von Rohdaten am E-Rezept-Fachdienst
Das Apothekenverzeichnis MUSS die in der Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis aufgeführten Operationen/Use Cases messen. Die Messung beginnt mit der Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht an die annehmende Schnittstelle des Empfängers. Registriert wird der Zeitpunkt und die HTTP-Statuscodes aus dem Header und wird gemäß A_21272 formatiert sowie für $operation der Wert $operation = $APO-operation gemäß der Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis gesetzt. [<=]
A_21276 - Apothekenverzeichnis - Erfassung von Rohdaten bei fehlerhaften Operationen
Das Apothekenverzeichnis MUSS jede Operation, welche nicht fehlerfrei durchlaufen wurde, in den Rohdaten gemäß A_21272 formatieren. Dabei MUSS für $operation der Wert $operation = $APO-operation + ".failed" gesetzt werden, wobei +".failed" nur anzuhängen ist, insofern einer der HTTP-Statuscodes gemäß Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure vom Apothekenverzeichnis zurückgeliefert wird.
Tabelle 107: Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure
| HTTP-Statuscode | Beschreibung |
|---|---|
| 408 | Das Apothekenverzeichnis ist überlastet und kann die Anfrage innerhalb der Wartezeit des Clients nicht beantworten. |
| 5xx | Alle HTTP-Statuscodes, die auf einen internen Systemfehler hinweisen. |
Zusätzlich MUSS die Lieferung für $message im JSON-Format erfolgen, das heißt für $message der Wert $message = {"UA": "$useragent ", " Status ": $status}. Für $status ist der http-Code gemäß [A_21272] zu verwenden und es sind die folgenden Datenformate zu benutzen:
Typ UA: string
Typ Status: number (int)
[<=]
A_21331 - Apothekenverzeichnis - Lieferung von Rohdaten
Der Anbieter Apothekenverzeichnis MUSS das Produkt Apothekenverzeichnis so konfigurieren, dass dieses in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte und die Datei zur Selbstauskunft automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefert. Voreingestellt für das Zeitintervall sind 5 Minuten.
[<=]
6 Anhang A – Verzeichnisse
6.1 Glossar
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
6.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: Netzwerktopologie – Punkte mit Lastvorgaben (orange)
- Abbildung 6: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen
- Abbildung 7: Messpunkte zur Konnektor Performance-Messung
- Abbildung 8: Messaufbau zum IPSec-Durchsatzmessung
- Abbildung 9: Messpunkte zur Kartenterminal Performance-Messung
6.3 Tabellenverzeichnis
- Tabelle 1: Tab_gemSpec_Perf_Servicekomponente->Servicezeit, Wartungsfenster
- Tabelle 2: Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02
- Tabelle 3: Tab_gemSpec_Perf_Standard-Statuscodes
- Tabelle 4: Tab_gemSpec_Perf_Produkte_Ereignisdaten
- Tabelle 5: Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall
- Tabelle 6: Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben
- Tabelle 7: Tab_gemSpec_Perf_sek_IDP: Bearbeitungszeitvorgaben
- Tabelle 8: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben
- Tabelle 9: Tab_gemSpec_Perf_Berichtsformat_IDP
- Tabelle 10: Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst
- Tabelle 11: Tab_gemSpec_Perf_Fehlercodes_sektoraler_IDP
- Tabelle 12: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP
- Tabelle 13: Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte
- Tabelle 14: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall
- Tabelle 15 Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben
- Tabelle 16: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst
- Tabelle 17: Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3
- Tabelle 18: Tab_gemSpec_Perf_OCSP_Responder_TSPX509
- Tabelle 19: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509
- Tabelle 20: Tab_gemSpec_Perf_Fehlercodes_TSP-X.509
- Tabelle 21: Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509
- Tabelle 22: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben
- Tabelle 23: Tab_gemSpec_Perf_Fehlercodes_VPN-ZugD
- Tabelle 24: Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD
- Tabelle 25 Tab_gemSpec_Perf_NCPeH: Last- und Bearbeitungszeitvorgaben
- Tabelle 26: Tab_gemSpec_Perf_Berichtsformat_NCPeH
- Tabelle 27: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben
- Tabelle 28: Tab_gemSpec_Perf_Fehlercodes_SigD
- Tabelle 29: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD
- Tabelle 30: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben
- Tabelle 31: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS
- Tabelle 32: Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall
- Tabelle 33: Tab_gemSpec_Perf_Berichtsformat_KIM
- Tabelle 34: Tab_gemSpec_Perf_Berichtsformat_TI-Gateway-Zugangsmodul
- Tabelle 35: Tab_gemSpec_Perf_Namensdienst: Last- u. Bearbeitungszeitvorgaben
- Tabelle 36: Tab_gemSpec_Perf_Berichtsformat_Namensdienst
- Tabelle 37: Tab_gemSpec_Perf_Statuscodes_Namensdienst
- Tabelle 38 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben
- Tabelle 39: Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM
- Tabelle 40: Tab_gemSpec_Perf_OCSP_Responder_TSPX509nQ-Komp
- Tabelle 41: Tab_gemSpec_Perf_CRL-Dienst: Lastvorgaben
- Tabelle 42: Tab_gemSpec_Perf_TSP_Provisioning_Revocation: Bearbeitungszeitvorgaben
- Tabelle 43: Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp
- Tabelle 44: Tab_gemSpec_Perf_Statuscodes_TSP_X.509_nonQES_Komp
- Tabelle 45: Tab_gemSpec_Perf_TSP_CVC: Bearbeitungszeitvorgaben
- Tabelle 46: Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy
- Tabelle 47: Tab_gemSpec_Perf_Statuscodes_OCSP-Responder-Proxy
- Tabelle 48: Tab_gemSpec_Perf_OCSP-Responder-Proxy_Ziel-URLs
- Tabelle 49: Tab_gemSpec_Perf_OCSP_Responder_TSL-Dienst
- Tabelle 50: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben
- Tabelle 51: Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst
- Tabelle 52: Tab_gemSpec_Perf_Statuscodes_TSL-Dienst
- Tabelle 53 :Tab_gemSpec_Perf_TSL-Dienst_URLs
- Tabelle 54: Tab_gemSpec_Perf_OCSP_Responder_gematik-Root-CA
- Tabelle 55: Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA
- Tabelle 56: Tab_gemSpec_Perf_Statuscodes_gematik-Root-CA
- Tabelle 57 : Tab_gemSpec_Perf_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben
- Tabelle 58 : Tab_gemSpec_Perf_Berichtsformat_ePA
- Tabelle 59: Tab_gemSpec_Perf_Fehlercodes_ePA-AS
- Tabelle 60: Tab_UX-Usecases
- Tabelle 61: Tab_gemSpec_Perf_Konfigurationsdienst: Lastvorgaben
- Tabelle 62: Tab_gemSpec_Perf_Konfigurationsdienst: Bearbeitungszeitvorgaben
- Tabelle 63: Tab_gemSpec_Perf_Berichtsformat_Konfigurationsdienst
- Tabelle 64: Tab_gemSpec_Perf_Statuscodes_Konfigurationsdienst
- Tabelle 65: Tab_gemSpec_Perf_Netzlast_1 Spitzenlasten am VPN-Zugangsdienst (Punkt 1)
- Tabelle 66 Tab_gemSpec_Perf_Zentrales-Netz-TI_Verfügbarkeiten
- Tabelle 67: Tab_gemSpec_Perf_Berichtsformat_Zentrales-Netz-TI
- Tabelle 68 : Tab_gemSpec_Perf_Fehlercodes_Zentrales-Netz-TI
- Tabelle 69: Tab_gemSpec_Perf_Berichtsformat_Sicherheitsgateway-Bestandsnetze
- Tabelle 70: Tab_gemSpec_Perf_Fehlercodes_Sicherheitsgateway-Bestandsnetze
- Tabelle 71 Tab_gemSpec_Perf_eHealth-CardLink: Last- und Bearbeitungszeitvorgaben
- Tabelle 72: Tab_Mengengerüst: Versicherte und Leistungserbringer
- Tabelle 73: Tab_Mengengerüst: Lokationen
- Tabelle 74: Tab_Mengengerüst: Krankenhäuser (Quelle: [DKG2010])
- Tabelle 75: Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen
- Tabelle 76: Tab_Mengengerüst: Annahmen für Modellierung
- Tabelle 77: Tab_VSDM Anwendungsfälle
- Tabelle 78: Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze
- Tabelle 79: Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
- Tabelle 80: Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
- Tabelle 81: Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen
- Tabelle 82: Tab_Lastmodell: Krankenhäuser (Quelle: [DKG2010])
- Tabelle 83: Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
- Tabelle 84: Tab_Lastmodell: KOM-LE in Krankenhäusern
- Tabelle 85: Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten
- Tabelle 86: Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
- Tabelle 87: Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken
- Tabelle 88: Tab_Mengenrahmen „Update Konnektor und Kartenterminals“
- Tabelle 89: Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall
- Tabelle 90: Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall
- Tabelle 91: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus
- Tabelle 92: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept
- Tabelle 93: Tab_Caching-Dauer
- Tabelle 94: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben
- Tabelle 95: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B
- Tabelle 96: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS
- Tabelle 97: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell
- Tabelle 98: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch
- Tabelle 99: Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe
- Tabelle 100: Tab_gemSpec_Perf_Verzeichnisdienst: Last- u. Bearbeitungszeitvorgaben
- Tabelle 101: Tab_gemSpec_Perf_Störungsampel – Lastvorgaben
- Tabelle 102: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben
- Tabelle 103: Tab_gemSpec_Perf_VSDM_Fachdienste: Last- und Bearbeitungszeitvorgaben
- Tabelle 104: Tab_eRp_APOVZD_Anfrageaufkommen
- Tabelle 105: Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben
- Tabelle 106 : Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis
- Tabelle 107: Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure
- Tabelle 108: Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente
- Tabelle 109: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM
- Tabelle 110: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD
- Tabelle 111: Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM – Operationen des Performance-Berichts Intermediär VSDM
- Tabelle 112: Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen
- Tabelle 113: Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen
- Tabelle 114 : Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen
- Tabelle 115: Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen
- Tabelle 116: Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben
- Tabelle 117: Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen
- Tabelle 118: Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen
6.4 Referenzierte Dokumente
6.4.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.
| [Quelle] |
Herausgeber: Titel |
|---|---|
| [gemGlossar] |
gematik: Glossar |
| [gemKPT_Arch_TIP] |
gematik: Architekturkonzept der TI-Plattform |
| [gemKPT_Perf_VSDM] |
gematik: Systemspezifisches Konzept Performanceuntersuchung (VSDM) |
| [gemRL_Betr_TI] |
gematik: Übergreifende Richtlinien zum Betrieb der TI |
| [gemKPT_Betr] | gematik: Betriebskonzept Online-Produktivbetrieb |
| [gemSpec_FM_VSDM] |
gematik: Spezifikation Fachmodul VSDM |
| [gemSpec_Intermediär_VSDM] |
gematik: Spezifikation Intermediär VSDM |
| [gemSpec_Net] |
gematik: Spezifikation Netzwerk |
| [gemSpec_COS] |
gematik: Spezifikation des Card Operating System (COS) – Elektrische Schnittstelle |
| [gemKPT_Test] |
gematik: Testkonzept |
| [gemSysL_KOM-LE] |
gematik: Systemspezifisches Konzept – Kommunikation Leistungserbringer (KOM-LE) |
| [gemSysL_NFDM] | gematik: Systemspezifisches Konzept Notfalldaten-Management (NFDM) |
| [gemSysL_AMTS_A] |
gematik: Systemspezifisches Konzept eMP/AMTS-Datenmanagement (Stufe A) |
| [gemSysL_ePA] |
gematik: Systemspezifisches Konzept elektronische Patientenakte (ePA) |
| [gemSpec_OM] |
gematik: Übergreifende Spezifikation Operations und Maintenance |
| [gemSpec_Aktensystem_ePAfuerAlle] |
gematik: Spezifikation ePA-Aktensystem |
| [gemSpec_SST_LD_DB] |
gematik: Spezifikation Schnittstelle Logdaten- und Betriebsdatenerfassung |
| [gemSysL_eRp] | gematik: Systemspezifisches Konzept E-Rezept |
6.4.2 Weitere Dokumente
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| [DKG2010] |
Deutsche Krankenhaus Gesellschaft (DKG): Kenngrößen für den Konnektor im Krankenhaus |
| [GBE_Bund] |
Gesundheitsberichterstattung des Bundes |
| [KBV2010] |
Kassenärztliche Bundesvereinigung, Grunddaten 2011, http://www.kbv.de/publikationen/125.html |
| [KBVPraxen2010] |
Kassenärztliche Bundesvereinigung (16.09.2011): Praxen / MVZ http://www.kbv.de/print/24853.html |
| [KZBV2010] |
Kassenzahnärztliche Bundesvereinigung (Jahrbuch 2011) http://www.kzbv.de/statistische-basisdaten.5.de.html |
| [UnabhZufall] |
Herleitung der Summenregeln für Mittelwerte und Varianzen aus dem Additionssatz für Verteilungen http://www.vwi.tu-dresden.de/~treiber/statistik2/statistik_download/exkurse15.pdf |
| [ABDA2016] |
DIE APOTHEKE – ZAHLEN, DATEN, FAKTEN 2016, ABDA – Bundesvereinigung Deutscher Apothekerverbände https://www.abda.de/uploads/tx_news/ABDA_ZDF_2016_Brosch.pdf |
| [ABDA2018] |
DIE APOTHEKE – ZAHLEN, DATEN, FAKTEN 2018, ABDA – Bundesvereinigung Deutscher Apothekerverbände https://www.abda.de/fileadmin/assets/ZDF/ZDF_2018/ABDA_ZDF_2018_Brosch.pdf |
| [GKVKassen2019] |
GKV-Spitzenverband (21.01.2019): Krankenkassenliste https://www.gkv-spitzenverband.de/krankenkassenliste.pdf |
| [Perf4J] |
Performance Monitoring and Statistics for Java Code https://github.com/perf4j |
7 Anhang B – Modelldetails
7.1 Verteilung der Konnektorbearbeitungszeiten auf Komponenten
Die Bearbeitungszeitvorgaben in "Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben" 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 "Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente" an.
Tabelle 108: 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
|
8 Anhang C – Performance-Berichtsformate
Im Folgenden werden die zur Erstellung des Rohdaten-Performance-Berichts zu verwendenden Operationen je Produkttyp aufgelistet.
Tabelle 109: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM
| $operation |
Produkttyp |
Operation
|
Beschreibung |
|---|---|---|---|
| UFS.GetUpdateFlags |
UFS |
GetUpdateFlags |
Bei Aufruf der Operation GetUpdateFlags beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM. |
| VSDD.PerformUpdates |
VSDD |
PerformUpdates |
Bei Aufruf der Operation PerformUpdates beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM. |
| VSDD.GetNextCommand- Package |
VSDD |
GetNextCommand-Package |
Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM. |
| CMS.PerformUpdates |
CMS |
PerformUpdates |
Bei Aufruf der Operation PerformUpdates beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM. |
| CMS.GetNextCommand- Package |
CMS |
GetNextCommand-Package |
Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM. |
Tabelle 110: 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 Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client. |
| SGD.getAuthenticationToken | SGD | getAuthenticationToken | Bei Aufruf der Operation getAuthenticationToken beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client. |
| SGD.KeyDerivation |
SGD |
KeyDerivation |
Bei Aufruf der Operation KeyDerivation beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client. |
Tabelle 111: Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM – Operationen des Performance-Berichts Intermediär VSDM
| $operation | Produkttyp | Operation/ ServiceType | Beschreibung |
|---|---|---|---|
| Intermediaer_VSDM.UFS | Intermediaer-VSDM |
UFS | Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client. |
| Intermediaer_VSDM.VSD | Intermediaer-VSDM | VSD | Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client. |
| Intermediaer_VSDM.CMS | Intermediaer-VSDM | CMS | Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client. |
9 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 112: 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 113: 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 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 114 : 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 115: 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.
10 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 116: 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 117: 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 118: 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.