gemSpec_Perf_V2.9.1

Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Spezifikation

Performance und Mengengerüst TI-Plattform

    

     

      
Version
      
2.9.1
     
     

      
Revision
      
548770
     
     

      
Stand
      
15.11.2019
     
     

      
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

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. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

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

1.4 Abgrenzung des Dokuments

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

1.5 Methodik

1.5.1 Anforderungen

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

Sie werden im Dokument wie folgt dargestellt:

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

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

2 Performance-Kenngrößen und ihr Einsatz

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

2.1 Bearbeitungszeit

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

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

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

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

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

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

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

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

• Bearbeitungszeiterwartungswert
• Bearbeitungszeitvarianz

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

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

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

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

¹⁾ 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 Bearbeitungszeitmittelwert²
• Quantilschranke für das 99%-Quantil der Bearbeitungszeit

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

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

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

Quantil-Definition

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

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

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

2.2 Last

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

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

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

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

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

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

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

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

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

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

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

Modellierung der Aufrufrate

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

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

Die so bestimmte modellierte Spitzenrate hat folgende Bedeutung:

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

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

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

Lastbegriff

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

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

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

Im Folgenden verwendete Lastbegriffe:

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

2.3 Verfügbarkeit

Folgende Begriffe werden definiert:

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

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

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

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

Aggregierte Sicht auf Verfügbarkeiten

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

Zwei Extremfälle können auftreten:

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

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

Caching

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

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

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

2.4 Einsatz der Performance-Kenngrößen

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

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

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

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.

Performance-Reporting-Daten

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

Last:

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

Bearbeitungszeit (jeweils pro Schnittstellenoperation)

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

Verfügbarkeit (jeweils pro Schnittstellenoperation)

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

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

Relevanz für Service Level Agreements

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

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

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

Die konkreten Leistungsanforderungen pro Produkttyp stellt Kapitel 4 dar.

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

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

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

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

2.5 Performance-Evaluierung auf der Basis von Rohdaten

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

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

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

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

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

2.5.1 Performance-Berichtsformat

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

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

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

Tabelle 1: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM

Tabelle 2: Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA

Tabelle 3: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

Tabelle 4: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD

Tabelle 5: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 – Operationen des Performance-Berichts TSP-X.509

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

3 Leistungsanforderungen für Anwendungsfälle

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

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

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

3.1 Spitzenlasten für Anwendungsfälle

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

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

3.1.1 Mengengerüst

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

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

Tabelle 5 gibt die Zahl der Versicherten, der niedergelassenen Leistungserbringer und der Krankenhäuser an. Es folgt eine Größenklassifizierung der Praxen in Tabelle 6 sowie der Krankenhäuser in Tabelle 7. Tabelle 9 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 6: Mengengerüst: Versicherte und Leistungserbringer

Tabelle 7: Mengengerüst: Lokationen

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

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

Tabelle 8 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 Betten³. 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.

³⁾ 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 10: Mengengerüst: Annahmen für Modellierung

3.1.2 Versichertenstammdatenmanagement (VSDM)

Das Versichertenstammdatenmanagement (VSDM) umfasst fünf performance-relevante Anwendungsfälle (siehe [gemKPT_Perf_VSDM]), die eine Kombination der folgenden drei Aktivitäten gemäß Tabelle 10 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 11: VSDM Anwendungsfälle

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

3.1.3 Kommunikation Leistungserbringer (KOM-LE)

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

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

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

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

3.1.4 Notfalldaten-Management (NFDM)

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

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

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

3.1.5 eMP/AMTS-Datenmanagement

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

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

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

3.1.6 Elektronische Patientenakte (ePA)

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

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

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

3.1.7 Tokenbasierte Authentisierung (TBAuth)

Die Tokenbasierte Authentisierung umfasst folgende performance-relevanten Operationen:

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

3.1.8 Lastmodell auf Ebene der Anwendungsfälle

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

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

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

Tabelle 12: Lastmodell: Nutzung bestehender Anwendungen und Netze

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

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

Die Spalten „Spitzenlasterhöhung“ in Tabelle 12, Tabelle 13 und Tabelle 15 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 11 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 12 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 13: Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Bei der Verteilung der Spitzenlasten aus Tabelle 12 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 6 ausgegangen.

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

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

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

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

(*) 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 12 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 15 verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle 7 und Tabelle 8.

Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle wird in Tabelle 16 für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie in Tabelle 17 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 17: Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

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

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

Die erwartete Nutzungsrate der NFDM-Anwendungsfälle wird in Tabelle 16 für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie inkludiert in Tabelle 15 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 15 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 19: Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Die erwartete Nutzungsrate der eMP/AMTS-Anwendungsfälle wird in Tabelle 19 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 20: Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken

Hinweis: G(iga), M(ega), K(ilo) bezeichnet hier G=(1024)³, M=(1024)² und K=(1024)¹.

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

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

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

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

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

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

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

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

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

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

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

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

Tabelle 23: Lastmodell ePA aus der Versicherten-Umgebung

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

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

3.1.9 Betriebliche Anwendungsfälle

Betrieblicher Anwendungsfall: Update des Konnektors bzw. der Kartenterminals

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

Tabelle 24: Mengenrahmen „Update Konnektor und Kartenterminals“

3.2 Bearbeitungszeiten

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

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

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

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

3.2.1 Bearbeitungszeiten KOM-LE

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

Tabelle 25: Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall

(*) nicht relevant für die Bearbeitungszeit

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

3.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)

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

Tabelle 26: Bearbeitungszeitvorgaben NFDM je Anwendungsfall

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

3.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement

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

Tabelle 27: Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall

3.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)

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

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

Tabelle 28: ePA Bearbeitungszeitvorgaben je Anwendungsfall

(*) nicht relevant für die Bearbeitungszeit

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

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

3.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung

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

Tabelle 29: Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall

3.3 Verfügbarkeiten

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

Tabelle 29 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 30: Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus

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

4 Leistungsanforderungen an die Produkttypen der TI

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

Grundlagen für die Performance-Vorgaben sind

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

⁴⁾ 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 31: Caching-Dauer

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

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

Bearbeitungszeitvorgaben unter Last

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

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

Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen

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

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

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

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

4.1 Produkttypen der dezentralen Zone der TI-Plattform

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

⁵⁾ Ausnahme Konnektor für Krankenhäuser.

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

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

4.1.2 Produkttyp Konnektor

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

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

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

Tabelle 32: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben

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):

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.

Tabelle 33: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B

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:

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

Tabelle 34: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS

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

Stapelsignatur und gSMC-Ks

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

Tabelle 35: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell

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

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

Tabelle 36: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch

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

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

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

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:

Rahmenbedingungen für die Messungen:

Abbildung 6: Messpunkte zur Konnektor Performance-Messung

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

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

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

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

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

Die konkreten Dokumente zu diesen Bezeichnern legt die Dokumentenlandkarte fest.

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

Netzwerkebene

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

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

Die folgende Abbildung erläutert die Durchsatzmessung.

Abbildung 7: Messaufbau zum IPSec-Durchsatzmessung

Der geforderte IPSec-Durchsatz wird unter folgenden Bedingungen ermittelt:

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

Verfügbarkeit

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

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.

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.

Software Download

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

Performance Logging

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

Skalierbarkeit

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

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

Signaturproxy

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

4.1.2.1 Fachmodul ePA

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

Tabelle 39: Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben