Vorabinformation zum Änderungseintrag: Folgende Änderungen sind Bestandteil des Änderungseintrages: Aktualisierung der Schnittstellen / Operationen im Kontext der Betriebsdatenerfassung Aktualisierung von Last-, Verfügbarkeit- und Servicezeit-Anforderungen Hinzufügen von Anforderungen zur Erhöhung der Resilienz und des Monitorings Migration und Aktualisierung des Lastmodels von der gemSpec_Intermediär_VSDM in die gemSpec_Perf Generelle Aktualisierung der Anforderungen zur Betriebsdatenerfassung Einführung von Bestandsdaten-Anforderungen Einführung einer maximalen Anzahl an HTTP-Verbindungen, die ein Intermediär zu den Fachdiensten aufbauen darf Die Nummerierung der Kapitel entspricht nicht der Nummerierung aus den referenzierenden Dokumenten, da diese durch die Formatierung automatisch erzeugt wird. Dies wird bei der Einarbeitung der Änderungen entsprechend beachtet. Hinweise zur Lesart: Text, der zur Erklärung der Änderung dient - wird nicht mit eingearbeitet/übernommen. Text, der neu ist oder aktualisiert wurde. Text, der entfernt wird.

Änderungen gemSpec_Intermediär_VSDM

1 gemSpec_Intermediär_VSDM - Nicht-Funktionale Anforderungen

Das Kapitel 4.3 Performance wird umgeschrieben und die Tabelle TAB_INTM_VSDM_16 aus dem Kapitel 4.4 Mengengerüst in das Kapitel 4.3 migriert. Hierbei wird zusätzlich der Vermerk "in der ersten Stunde des Arbeitstages" entfernt, da die Spitzenlasten zu unterschiedlichen Tageszeiten stattfinden können.

1.1 Performance

Der Intermediär muss die in [gemSpec_Perf] definierten Bearbeitungszeiten unter Last [gemSpec_Perf#GS-A_5029-02] einhalten, damit die Anwendungsfälle der Fachanwendung VSDM in akzeptabler Zeit ausgeführt werden. Die Performancevorgaben richten sich an die reine Bearbeitungszeit des Intermediärs ohne Kommunikation mit externen Systemen. Damit der Intermediär die Bearbeitungszeit unter Last gewährleisten kann, muss er die Anzahl der Verbindungsversuche zu Spitzenlastzeiten in Tabelle TAB_INTM_VSDM_16 bewältigen können.

Tabelle 1: Tab_INTM_VSDM_16 – Anzahl der Verbindungsversuche zu Spitzenlastzeiten [VSDM-A_2706]

	Wert
Anzahl der Verbindungsversuche in den ersten Stunde des Arbeitstages bei 200.000 Fachmodule pro Sekunde	56
Anzahl der Verbindungsversuche in den ersten Stunde des Arbeitstages bei 20.000 Fachmodulen pro Sekunde (gerundet)	6

Das Kapitel 4.4 Mengengerüst wird aus der gemSpec_Intermediär_VSDM gelöscht und noch relevante Inhalte nach gemSpec_Perf Kapitel 3.12.1.1 Lastmodell Intermediär VSDM übertragen.

1.2 Mengengerüst

Dieses Kapitel beschreibt die Grundlagen und Annahmen für das Mengengerüst, das zur Kalkulation der Anfragen pro Sekunde und Anzahl der Verbindungsaufnahmen genutzt wird. Es werden das Mengengerüst des [gemLH_VSDM] und das Performancemodell [gemKPT_Perf_VSDM] zugrunde gelegt. Die Zahlen beziehen sich auf das maximale Mengengerüst bei Teilnahme aller Versicherten und Vollausstattung der Telematikinfrastruktur.

Tabelle 2: Tab_INTM_VSDM_11 – Grundlagen des Mengengerüsts

	Wert	Quelle
Gesetzlich Krankenversicherte der Bundesrepublik Deutschland 2008	70.244.000	[gemLH_VSDM]
Onlineprüfung und -aktualisierung mit Aktualisierung der VSD pro Quartal	3.512.000	[gemLH_VSDM]
Onlineprüfung und -aktualisierung ohne Aktualisierung der VSD	146.150.000	[gemLH_VSDM]
Angenommene Dauer eines Arbeitstages in Stunden	8	-
Anzahl der Requests-Response-Zyklen bei VSD-Aktualisierung ohne Update	1	[gemSysL_VSDM]
Anzahl der Requests-Response-Zyklen bei VSD-Aktualisierung mit Update	5	[gemSysL_VSDM]

Tabelle 3: Tab_INTM_VSDM_12 – Nachrichtengröße, aus typisierten Nachrichten ermittelt

	Wert
Typische Größe eines UFS-Requests in Byte	500
Typische Größe einer UFS-Response in Byte	700
Durchschnittliche Größe eines VSDD/CMS-Requests in Byte	700
Durchschnittliche Größe einer VSDD/CMS-Response in Byte	5.000

Tabelle 4: Tab_INTM_VSDM_13 – Antwortzeiten der Fachdienste im 95%-Grenzwert-Szenario

	Wert	Quelle
Antwortzeit auf UFS-Anfrage in ms	70 280	[gemKPT_Perf_VSDM]
Antwortzeit auf VSDD-Anfrage in ms (gemittelt aus PerformUpdates und GetNextCommandPackage)	230 1396	[gemKPT_Perf_VSDM]

Aufgrund der Regelung, einmal pro Arzt und Versicherten im Quartal die Aktualität der VSD zu prüfen, kommt es in der ersten Woche eines Quartals vermehrt zu Anfragen zur Aktualität der VSD. Um die zu erwartende Spitzenlast abzuschätzen, wird im Mengengerüst der Tabelle Tab_INTM_VSDM_14 angenommen, dass 25 % aller Anfragen im Quartal in der ersten Woche erfolgen. Zusätzlich wird das Lastaufkommen mit einem Sicherheitsfaktor von 4 multipliziert, um zu erwartenden Lastspitzen abzudecken.

Der Intermediär muss unter den oben getroffenen Annahmen die Anzahl der gleichzeitigen Anfragen der Tabelle Tab_INTM_VSDM_14 in der in definierten Ausführungszeit verarbeiten.

Tabelle 5: Tab_INTM_VSDM_14 – Anzahl der Anfragen

	Wert
Anzahl der UFS-Anfragen in der ersten Woche des Quartals	37.415.625
Anzahl der VSDD-Anfragen in der ersten Woche des Quartals	3.512.250
Anfragen für Intermediär in der ersten Woche des Quartals	163.711.500 40.927.875 (ohne Sicherheitsfaktor 4)
Anzahl der Anfragen an den Intermediär pro Sekunde in der ersten Woche des Quartals	1136 284 (ohne Sicherheitsfaktor 4)
Anzahl der Anfragen an Intermediär pro Sekunde bei 1.000.000 Versicherten in der ersten Woche des Quartals	etwa 16 etwa 4 (ohne Sicherheitsfaktor 4)

Für die Anzahl der Verbindungen vom Fachmodul zum Intermediär müssen die Anzahl der niedergelassenen Ärzte und Zahnärzte, Krankenhäuser und weiterer Clientsysteme in Tabelle Tab_INTM_VSDM_15 berücksichtigt werden. Für jeden Arzt und Zahnarzt wird vereinfachend angenommen, dass jeder über ein Fachmodul verfügt. Weitere Einflussfaktoren wie Urlaubszeiten, MVZ oder Gemeinschaftspraxen mit mehreren niedergelassenen Ärzten, Zahnärzten werden nicht weiter betrachtet.

Es wird angenommen, dass der Verbindungsaufbau von jedem Fachmodul einmal täglich erfolgt und dass sich ohne weitere Maßnahmen die Verbindungsversuche in der ersten Stunde des Arbeitstages konzentrieren. Der Intermediär muss die Anzahl der Verbindungsversuche in Tabelle Tab_INTM_VSDM_16 bewältigen.

Tabelle 6: Tab_INTM_VSDM_15 – Mengengerüst zur Berechnung der Anzahl der Verbindungen

	Wert	Quelle
Anzahl niedergelassener Ärzte	125.000	[KBV]
Anzahl niedergelassener Psychotherapeuten (nicht ärztliche Psychotherapeuten)	17.000	[KBV]
Anzahl niedergelassener Zahnärzte	56.000	[KZBV2010]
Anzahl Krankenhäuser	2.000	[DKG2010]
Gerundete Gesamtanzahl der Fachmodule	200.000

Tabelle 7: Tab_INTM_VSDM_16 – Anzahl der Verbindungsversuche [VSDM-A_2706]

	Wert
Anzahl der Verbindungsversuche in den ersten Stunde des Arbeitstages bei 200.000 Fachmodule pro Sekunde	56
Anzahl der Verbindungsversuche in den ersten Stunde des Arbeitstages bei 20.000 Fachmodulen pro Sekunde (gerundet)	6

2 gemSpec_Intermediär_VSDM - Anhang B

2.1 Ausgangsanforderungen

Von der Anforderung VSDM-A_2673 wird eine neue Version erstellt, um die Anforderungen an die Vorgangsnummer zu konkretisieren. Im Dokument werden alle Verweise auf die VSDM-A_2673 aktualisiert.

Änderungen gemKPT_Betr

3 gemKPT_Betr - Kenngrößen und Service Level

3.1 Technische Service Level / Performance Kenngrößen

3.1.1 Spezifische Ausprägungen

3.1.1.1 Intermediär VSDM (PDT21)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT21 - [gemSpec_Perf#Kap. 3.12 Intermediär VSDM#Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM]

Die Intermediär Operationen werden auf einen Anwendungsfall reduziert. Aus diesem Grund wird die Tabelle Tab_gemKPT_Betr_Intermediär_VSDM_S::O/A angepasst:

Tabelle 8: Tab_gemKPT_Betr_Intermediär_VSDM_S::O/A

Produkttyp / Anwen-dungstyp (PDT-ID)	S/A-ID	Schnittstellen::Operation / Anwendungsfall (S/A)	Beschreibung	Berichtsformat-Alias (sofern von Schnittstellen::Operation bzw. Anwendungsfall abweichend)
PDT21	S01	I*	verwendet für Verfügbarkeitsberechnung
PDT21	S02	Intermediaer_VSDM.UFS	Aufrufe der VSDM UFS Schnittstelle.	INT.UFS
PDT21	S03	Intermediaer_VSDM.VSD	Aufrufe der VSDM VSD Schnittstelle.	INT.VSD
PDT21	S04	Intermediaer_VSDM.CMS	Aufrufe der VSDM CMS Schnittstelle.	INT.CMS
PDT21	A02	INT.UC_1	Aufruf einer Intermediär-Instanz durch ein Fachmodul	-

Performance-Kenngrößen / SL-Werte

Der Erfassungszeitraum    für die aufgeführten Soll-Werte beträgt ein Kalendermonat.

Die Bildung der Performance-Kenngrößen basiert auf folgenden PG-Schemata: PG-Schema-I

Die Performance-Kenngrößen / SL-Werte wurden angepasst. Deshalb sind folgende Änderungen an der Tab_gemKPT_Betr_Intermediär_VSDM_Performance-Kenngroessen notwendig:

Tabelle 9: Tab_gemKPT_Betr_Intermediär_VSDM_Performance-Kenngroessen

Performance- Kenngröße (PKG-ID)	Beschreibung	berechnet aus (Betriebsdaten, Probing)	SL-Wert (Soll-Wert)	min / max	Normative Referenz
Intermediär VSDM - PDT21
PDT21-S01-D3-G14	Relative Verfügbarkeit im Betrachtungszeitraum zur Hauptzeit exkl. Wartung. [%*1000]	Probing	99900	min	GS-A_5030-02
PDT21-S01-D3-G16	Relative Verfügbarkeit im Betrachtungszeitraum zur Nebenzeit exkl. Wartung. [%*1000]	Probing	99000	min	GS-A_5030-02
Intermediär VSDM - PDT21 - INT.UC_1
PDT21-A02-D2-G08	Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec]	Betriebsdaten	100	max	GS-A_5029-02
PDT21-A02-D2-G30	Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec]	Betriebsdaten	150	max	GS-A_5029-02
PDT21-A02-D2-G31	Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000]	Betriebsdaten	99990	min	GS-A_5029-02

4 gemKPT_Betr - Neue AFO Zuordnungen

Folgende AFOs aus der gemKPT_Betr werden, den jeweils in der Tabelle angegebenen Steckbriefen mit dem hinterlegten Prüfverfahren, neu zugeordnet:

AFO-ID	Titel	Betroffener Steckbrief	Zuordnung zu Prüfverfahren
A_20476	Funktionalität, Interoperabilität, Sicherheit in der PU	Anb_VPN_ZugD	betriebliche Eignung: Anbietererklärung
A_23551	Eigenmonitoring	Anb_VPN_ZugD	betriebliche Eignung: Anbietererklärung
A_23552	Verhalten bei Auffälligkeiten oder Anomalien	Anb_VPN_ZugD	betriebliche Eignung: Anbietererklärung

Begründung: Erhöhung der Resilienz und des Monitorings der zu betreibenden Produkte.

Änderungen gemSpec_Perf

5 Performance-Kenngrößen und ihr Einsatz

5.1 Verfügbarkeit

5.1.1 Wartungsfenster und Servicezeiten

Die Servicezeit des Intermediär VSDM liegt unter der Servicezeit anderer TI Produkte und das, obwohl es sich hierbei um ein essentielles Produkt handelt, welches u.a. Bestandteil der Wertschöpfungskette E-Rezept ist. Aus diesem Grund soll die Servicezeit erhöht werden:

Servicekomponente	Servicezeit	Wartungsfenster
Intermediär VSDM	A_23348 - HZ Mo-Fr A_23350 - HZ Mo bis So eingeschränkt	A_23347-01 A_23615

6 gemSpec_Perf - Produktspezifische Vorgaben

6.1 Intermediär VSDM (PDT21)

<...>

6.1.1 Leistungsanforderungen Intermediär VSDM

Alle Performance-Anforderungen der Kapitel "3.12.1.1 Lastmodell Intermediär VSDM" und "3.12.1.2 Bearbeitungszeiten Intermediär VSDM" werden unter der Überschrift "3.12.1.1 Performancevorgaben Intermediär VSDM" zusammengeführt, um den Kapitelstruktur zu anderen Produkten zu standardisieren. Zusätzlich werden relevante Inhalte aus dem ehemaligen Kapitel "Mengengerüst" aus der gemSpec_Intermediär_VSDM hier integriert und das Lastmodell des Intermediär aktualisiert.

6.1.1.1 Lastmodell Intermediär VSDM

Der Intermediär VSDM unterstützt die Anwendungsfälle des Versichertenstammdatenmanagements (VSDM), indem er Nachrichten vom Fachmodul an die Fachdienste VSDM weiterreicht und die Antworten zustellt. Die für den Intermediär VSDM zu erwartenden Lasten leiten sich deshalb unmittelbar von der Lastbetrachtung der für die Fachdienste VSDM relevanten Anwendungsfälle ab (siehe Kapitel 3.26.1.1 Lastmodell Fachdienste 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. Aufgrund der Regelung, einmal pro Arzt und Versicherten im Quartal die Aktualität der VSD zu prüfen, wird angenommen, dass 10% aller Online-Prüfungen im Quartal an einem Tag erfolgen und dass bei 2,5% dieser Prüfungen eine Aktualisierung der Daten erforderlich ist. Zusätzlich wird das Lastaufkommen pro Stunde mit einem Sicherheitsfaktor von 4 multipliziert, um zu erwartenden Lastspitzen abzudecken.

Tabelle 10: Tab_Lastmodell Intermediär VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Anwendungsfall	Mengengröße x	Spitzenlasten pro Tag	Spitzenlast- erhöhungs- faktor
VSD Lesen mit  Aktualisierungsprüfung ohne Update	x: Anzahl Versicherter	x * 0,10	4
VSD Lesen mit  Aktualisierungsprüfung  mit Update	x: Anzahl Versicherte	x * 0,0025	4

Bei der Verteilung der Spitzenlasten aus Tabelle "Tab_Lastmodell Intermediär 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. Für jeden Arzt und Zahnarzt wird vereinfachend angenommen, dass jeder über ein Fachmodul verfügt. Weitere Einflussfaktoren wie Urlaubszeiten, MVZ oder Gemeinschaftspraxen mit mehreren niedergelassenen Ärzten, Zahnärzten werden nicht weiter betrachtet.

Die vom Intermediär zu bewältigende Spitzenlast unter den oben getroffenen Annahmen ergibt sich aus der Summierung der zwei Anwendungsfälle. Zur Erläuterung wird an Hand von Tabelle "Tab_Lastmodell Intermediär VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" exemplarisch die Spitzenlast pro Tag berechnet. Der Einfachheit halber wird in diesem Beispiel angenommen, dass alle Prüfungen von einem zentralen Intermediär verarbeitet werden:

Spitzenlast VSD ohne Update:

• Spitzenlast pro Tag: 74.000.000 * 0,10 pro Tag = 7.400.000 pro Tag
• Spitzenlast pro Stunde: 7.400.000 pro Tag / 8 Stunden pro Tag * 4 = 3.700.000 pro Stunde

Spitzenlast VSD mit Update:

• Spitzenlast pro Tag: 74.000.000 * 0,0025 pro Tag = 185.000 pro Tag
• Spitzenlast pro Stunde: 185.000 pro Tag / 8 Stunden pro Tag * 4 = 92.500 pro Stunde

Spitzenlast Intermediär:

• Spitzenlast pro Stunde: 3.700.000 + 92.500 = 3.792.500 pro Stunde
• Spitzenlast pro Sekunde: 3.792.500 pro Stunde / 60 Minuten / 60 Sekunden = 1.053 pro Sekunde

Die Überschrift 3.12.1.2 Bearbeitungszeiten Intermediär VSDM wird gelöscht, da in diesem Kapitel kein Inhalt mehr vorhanden ist.

3.12.1.2 Bearbeitungszeiten Intermediär VSDM

6.1.1.2 Performancevorgaben Intermediär VSDM

Für die AFO GS-A_5029-01 wird eine neue Version erstellt mit folgenden Änderungen:

• Die Tabelle "Tab_gemSpec_Perf_Intermediaer: Last- u. Bearbeitungszeitvorgaben" wird an den aktuellen Standard angepasst und das 95% Quantil durch eine höhere Erfüllungsquote ersetzt.
• Die Spitzenlast wird gemäß des Lastmodell Intermediär VSDM so gewählt, als wenn ein zentraler Intermediär alle Anfragen bearbeiten können müsste. Diese muss dann je Marktanteil der jeweiligen Anbieter angepasst werden.
• Für die Zulassung muss zukünftig ein Nachweis von 10% der geforderten Spitzenlast nachgewiesen werden, anstelle von 100 Anfragen / Sekunde.

Hinweise zur gewählten Spitzenlast:

• Spitzenlast gemäß Lastmodell = 1.053 Aufrufe / Sekunde
• Zusätzlich zum Lastmodell Intermediär VSDM wird der Anwendungsfall "ERP.UC_4_12" [gemSpec_Perf - A_20165-*] mit berücksichtigt. Bei diesem Anwendungsfall ruft ein Krankenversicherter sein E-Rezept in der Apotheke ab, was ebenfalls zu einer VSDM Anfrage und somit zu einer Laststeigerung beim Intermediär führt. (gemäß A_20165-* = 220 Aufrufe / Sekunde)
• Zusätzlich wird die Einbindung der Pflegeberufe (stationäre Pflegeeinrichtungen / ambulante Pflegedienste) mit berücksichtigt. Erste Hochrechnungen lassen auf eine Spitzenlast von bis zu 300 Aufrufen / Sekunde vermuten. 
• Da sich die Spitzenlasten aus ERP.UC_4_12 und der Pflegeberufe aller Voraussicht nach zu anderen Zeiten ereignen werden, werden die jeweiligen Spitzenlasten nicht vollständig dazu addiert, sondern in Relation gesetzt.

Die Verfügbarkeit des Intermediär VSDM liegt unter der Verfügbarkeit anderer TI Produkte und das, obwohl es sich hierbei um ein essentielles Produkt handelt, welches u.a. Bestandteil der Wertschöpfungskette E-Rezept ist. Aus diesem Grund soll die Verfügbarkeit erhöht werden:

Zuweisen zu Anb_VPN-ZugD / Anb_TI-GW - Prüfverfahren: Funktionale Eignung: Anbietererklärung

Für die AFO GS-A_5073 wird eine neue Version erstellt, da der bundesweite Rollout bereits erreicht ist und die Skalierung nun im produktiven Betrieb gewährleistet sein soll:

Neue Anforderung für die Robustheit gegenüber Lastspitzen. Aktuell ist der Intermediär der AFO GS-A_4145 zugeordnet, welche diese Vorgabe für Produkttypen der zentralen Zone regelt. Hier gibt es immer wieder Klärungsbedarf, da der Intermediär nicht zur zentralen Zone sondern zur Provider Zone zählt. Aus diesem Grund wird eine dedizierte AFO für den Intermediär erstellt:

Zuweisen zu Intermediär VSDM - Prüfverfahren: Funktionale Eignung: Test Produkt /FA

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.

6.1.2 Betriebsdatenerfassung v2 Spezifika Intermediär VSDM

Mit der bisherigen Spezifikation der Operationen kommt es zu einem Fehlerfall, wenn der Intermediär aus dem HTTP-Request vom Fachmodul keine ServiceType ermitteln kann. In dem Fall ist es nicht möglich, den Vorgang einer Operation zuzuordnen. Aus diesem Grund soll es zukünftig nur noch einen Anwendungsfall geben, der alle Vorgänge abdeckt und die ServiceType soll im Message Block mitgesendet werden.

Es wird eine neue Version der Tabelle "Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM" zur Reduzierung der Operationen auf einen Anwendungsfall erstellt. Zeitgleich wird eine redaktionelle Änderung der AFO A_23253 durchgeführt, da diese zukünftig auf die Tabelle verweisen soll.

Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM -> Alte Version:

Operation / Usecase	Beschreibung
INT.UFS	Operation: Intermediaer_VSDM.UFS
INT.VSD	Operation: Intermediaer_VSDM.VSD
INT.CMS	Operation: Intermediaer_VSDM.CMS

Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM -> Neue Version:

Operation / Usecase	Duration
INT.UC_1	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_23253 -> Redaktionelle Änderung:

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

Der Produkttyp Intermediär VSDM MUSS bei Betriebsdatenlieferungen bzgl. 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. die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM berücksichtigen.

A_23750-02 -> Erstellung neuer Version der AFO, zur Integration weiterer Informationen im Message-Block. Diese Informationen sollen das Monitoring und die Fehlererkennung optimieren. Zudem wird zukünftig der ServiceType im Message Block mit gesendet, was vorher über die Operationen abgebildet war:

  

A_24070 -> Die Anforderung für die Status Codes muss aktualisiert werden, da diese aktuell vermehrt zu Rückfragen führt. Hierbei soll zum Einen auf AFO VSDM-A_2353 verwiesen werden (HTTP-StatusCodes Intermediär). Des Weiteren soll mit individuellen Statuscodes sichergestellt werden, dass eine Unterscheidung getroffen werden kann, ob der HTTP-Statuscode vom Fachdienst geschickt oder vom Intermediär selber erzeugt wurde.

Für den Intermediär VSDM sollen vom jeweiligen Anbieter Informationen aus dem Verbindungsprotokoll als Bestandsdaten geliefert werden. Dadurch wird die Möglichkeit geschaffen, das Verbindungsverhalten des Intermediärs zu den Fachmodul und zu den Fachdiensten besser analysieren und Anomalien im Verhalten frühzeitig erkennen zu können. Zusätzlich wird der Vorteil geschaffen, dass nachgewiesen werden kann, ob Hersteller das Verbindungsverhalten gemäß der Anforderungen [VSDM-A_3022], [VSDM-A_3023] und [VSDM-A_3028] richtig implementiert haben.

6.1.3 Bestandsdaten Intermediär VSDM

Bestandsdaten sind im Gegensatz zur Betriebsdatenlieferung die Abfragen von Statusinformationen zu einem spezifizierten Abfragezeitpunkt. Im Folgenden sind Bestandsdaten Anforderungen für den Produkttypen Intermediär VSDM spezifiziert.

Zuweisen zu Anb_VPN-ZugD / Anb_TI-GW - Prüfverfahren: Organ./betriebl. Eignung:  Anbietererklärung

Zuweisen zu Anb_VPN-ZugD / Anb_TI-GW - Prüfverfahren: Organ./betriebl. Eignung:  Anbietererklärung

6.2 Fachdienste VSDM (PDT20, PDT23, PDT26)

In das Kapitel 3.26.1.1 Lastmodell Fachdienste VSDM wird der Verweis auf die gemSpec_Intermediaer_VSDM entfernt.

6.2.1 Lastmodell Fachdienste VSDM

Das Versichertenstammdatenmanagement (VSDM) umfasst fünf performance-relevante Anwendungsfälle (siehe [gemKPT_Betr]), 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 13: 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.

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 14: 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.

7 gemSpec_Perf - Zusätzliche AFO Zuordnungen

Dieses Kapitel listet alle neuen oder zu entfernende AFO Zuordnungen im Dokument auf.

7.1 Neue AFO Zuordnungen

Folgende AFOs aus der gemSpec_Perf werden, den jeweils in der Tabelle angegebenen Steckbriefen mit dem hinterlegten Prüfverfahren, neu zugeordnet:

AFO-ID	Titel	Betroffener Steckbrief	Zuordnung zu Prüfverfahren
A_23350	Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag eingeschränkt	Intermediär VSDM	Funkt. Eignung: Herstellererklärung
A_26151	Redundanz - Lokale Redundanz	Anb_VPN-ZugD	Betrieb. Eignung: Anbietererklärung
A_26152	Redundanz - Standortübergreifende Redundanz	Anb_VPN-ZugD	Betrieb. Eignung: Anbietererklärung
A_26186	Redundanz - Wiederherstellungszeitraum - 5 Tage	Anb_VPN-ZugD	Betrieb. Eignung: Anbietererklärung

Begründung: Erhöhung der Servicezeiten und Ablösung bisheriger produktspezifischer Redundanzanforderungen gegen die aktuellen übergreifenden Standardanforderungen im Kontext Redundanz.

7.2 Zu entfernende AFO Zuordnungen

Folgende AFOs aus der gemSpec_Perf werden von den jeweils in der Tabelle angegebenen Steckbriefen entfernt:

AFO-ID	Titel	Betroffener Steckbrief
GS-A_3055	Performance - zentrale Dienste - Skalierbarkeit (Anbieter)	Intermediär VSDM

Begründung: Der bundesweite Rollout ist bereits abgeschlossen und die lineare Skalierbarkeit im Betrieb ist durch die AFO GS-A_5073 abgedeckt.

AFO-ID	Titel	Betroffener Steckbrief
A_20170	Performance - Erfassung von Betriebsdaten - Intermediär VSDM	Intermediär VSDM

Begründung: Es gibt eine übergreifende Anforderung (A_22482), welche dem Intermediär bereits zugewiesen ist und fordert, dass Betriebsdaten gemäß der Vorgaben zu erfassen sind. Des Weiteren sind dem Produkttypen bereits alle notwendigen Anforderungen bzgl. Betriebsdatenlieferung v2 zugewiesen. Die AFO wird deshalb nicht mehr benötigt.

AFO-ID	Titel	Betroffener Steckbrief
GS-A_4145	Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen	Intermediär VSDM

Begründung: Der Intermediär zählt nicht zur zentralen Zone der TI-Plattform sondern zur Provider Zone. Aus diesem Grund wird für den Intermediär eine dedizierte AFO erstellt.

AFO-ID	Titel	Betroffener Steckbrief
A_23348	Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Freitag	Intermediär VSDM

Begründung: Es wird stattdessen die AFO A_23350 zugeordnet, um dieselbe Servicezeit wie beim E-Rezept zu gewährleisten.

AFO-ID	Titel	Betroffener Steckbrief
GS-A_5523	Performance – zentrale Dienste – Redundanzlösung	Intermediär VSDM

Begründung: Die bisherigen produktspezifischen Redundanzanforderungen werden von den aktuell standardisierten übergreifenden Redundanzanforderungen abgelöst. 

Änderungen gemRL_Betr_TI

8 gemRL_Betr_TI - Neue AFO Zuordnungen

Folgende AFOs aus der gemRL_Betr_TI werden, den jeweils in der Tabelle angegebenen Steckbriefen mit dem hinterlegten Prüfverfahren, neu zugeordnet:

AFO-ID	Titel	Betroffener Steckbrief	Zuordnung zu Prüfverfahren
GS-A_5590	Nutzung Business-Servicekatalog bei der Erfassung von Service Requests	Anb_VPN_ZugD	betriebliche Eignung: Anbietererklärung

Begründung: Standard-Anforderungen für alle Anbieter, da bei der Erfassung von Service Requests immer darauf zu achten ist, den Business-Servicekatalog zu nutzen. 

AFO-ID	Titel	Betroffener Steckbrief	Zuordnung zu Prüfverfahren
A_25903	Redundanz - Definition inhaltlicher Auszüge aus dem Redundanzkonzept	Anb_VPN-ZugD	betriebliche Eignung: Betriebshandbuch Sich.techn. Eignung: Dokumentenprüfung
A_25902	Redundanz - Bereitstellung Redundanzkonzept	Anb_VPN-ZugD	betriebliche Eignung: Anbietererklärung
A_26014	Redundanz - Umsetzung Redundanzkonzept	Anb_VPN-ZugD	betriebliche Eignung: Anbietererklärung
A_25917	Redundanz - Kontrollierte Validierung des Redundanzkonzept	Anb_VPN-ZugD	betriebliche Eignung: Anbietererklärung

Begründung: Hinzufügen zusätzlicher Redundanzanforderungen zur Verbesserung der Resilienz.

Änderungen gemSpec_SST_VSDM

9 gemSpec_SST_VSDM - Allgemeine Festlegungen

Es soll sichergestellt werden, dass die Anzahl der zusätzlichen HTTP-Verbindungen, die ein Intermediär zum Fachdienst aufbauen kann [VSDM-A_3023] mit einem maximalen Wert limitiert ist und er die Verbindungen ressourcenschonend und effizient nutzt. Dafür wird ein Beschreibungstext in Kapitel 9.1 ergänzt.

9.1 Connection pooling durch den Intermediär

Der Aufbau einer Verbindung vom Intermediär zum Fachdienst (im folgenden HTTP-Verbindung genannt) ist auf Grund von TCP-Handshake, TLS-Handshake und Abfragen auf anderen Schnittstellen zeitaufwendig. Um Verzögerungen bei der Abarbeitung eines Aufrufs vom Fachmodul zu minimieren, wird die HTTP-Verbindung zum Fachdienst nicht für jedes Request/Response-Paar neu aufgebaut. Der Intermediär hält dauerhaft HTTP-Verbindungen (persistent Connection) zu den Fachdiensten offen. Diese werden für mehrere Request/Response Paare wiederverwendet.

Connection Pool

Der Intermediär muss zu jedem Fachdienst (UFS, VSDD und CMS) einen Pool von HTTP-Verbindungen vorhalten. Die Anzahl der Verbindungen muss konfigurierbar sein. Wenn eine der vorgehaltenen Verbindungen, z.B. durch einen Fehler, vom Server abgebaut wird, dann muss der Intermediär die Verbindung innerhalb einer Zeit von höchstens 1s wieder aufbauen. Wenn der Server beim Aufbau der Verbindungen nicht erreichbar ist, dann soll der Intermediär das Connection pooling für einen Zeitraum aussetzen, bis der Endpunkt wieder erreichbar ist. [VSDM-A_3022] [A_17644][A_17645]

Zwei Request/Response-Paare, die auf Anwendungsebene zu einer Online-Aktualisierung gehören, können über verschiedene HTTP-Verbindungen übertragen werden.

Sollten die vorgehaltenen Verbindungen bei Lastspitzen nicht ausreichen, muss der Intermediär zusätzliche HTTP-Verbindungen etablieren, die dann nach Bedarf wieder geschlossen werden [VSDM-A_3023] [VSDM-A_3028]. Um eine effiziente Nutzung der Verbindungen zu gewährleisten, ist die Anzahl der gleichzeitig offenen Verbindungen so zu steuern, dass sie sowohl den Bedarf während der Spitzenlast als auch die Systemressourcen optimal ausnutzt. Damit eine Überlast am Fachdienst VSDM durch zu viele Verbindungen vermieden wird, ist für den Intermediär VSDM eine maximale Anzahl an HTTP-Verbindungen vorgegeben, die er zu den Fachdiensten aufbauen darf [A_27451].

Intermediär - Maximale Anzahl an HTTP-Verbindungen

Die maximale Anzahl an  HTTP-Verbindungen, die ein Intermediär zum Fachdienst VSDM aufbauen darf, ergibt sich aus der vom Intermediär zu unterstützenden Spitzenlast pro Sekunde [gemSpec_Perf#GS-A_5029-02] im Kontext zur maximalen Bearbeitungszeit in Millisekunden, die ein Fachdienst benötigt, um eine Anfrage beantworten zu können [gemSpec_Perf#GS-A_5031-01] und wird wie folgt abgeleitet:

• Maximale Anzahl HTTP-Verbindungen zum Fachdienst UFS = Spitzenlast Intermediär * Anbieter Marktanteil in %  / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM)
• Maximale Anzahl HTTP-Verbindungen zum Fachdienst CMS/VSD = Spitzenlast Intermediär * Anbieter Marktanteil in % * 0,025 / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM)

Hinweis zum Faktor 0,025: Gemäß des Mengengerüsts aus [gemSpec_Perf#3.12.1.1 Lastmodell Intermediär VSDM] wird angenommen, dass bei lediglich 2,5% der Online-Prüfungen eine Aktualisierung der Daten durch die Fachdienste CMS/VSD erforderlich ist. 

Beispiel 1 (UFS): Die Spitzenlast des Intermediäres beträgt 1.400 Anfragen / Sekunde. Ein Anbieter hat einen Marktanteil von 30%. Die maximale Bearbeitungszeit zum Beantworten einer UFS-Anfrage vom Fachdienst UFS beträgt 280msec. Das ergibt eine maximale Anzahl an HTTP-Verbindungen von 118 (Maximale Anzahl HTTP-Verbindungen = 1.400 * 0,30 / (1000/280)).

Beispiel 2 (CMS): Die Spitzenlast des Intermediäres beträgt 1.400 Anfragen / Sekunde. Ein Anbieter hat einen Marktanteil von 30%. Die maximale Bearbeitungszeit zum Beantworten einer CMS-Anfrage vom Fachdienst CMS beträgt 5.585msec. Lediglich 2,5% der Anfragen erfordern eine Aktualisierung der Daten. Das ergibt eine maximale Anzahl an HTTP-Verbindungen von 59 (Maximale Anzahl HTTP-Verbindungen = 1.400 * 0,30 * 0,025 / (1000/5585)).

10 gemSpec_SST_VSDM - Anhang B - Anforderungshaushalt

10.1 Ausgangsanforderungen

Hinzufügen neuer Anforderungen, damit sichergestellt ist, dass die Anzahl der zusätzlichen HTTP-Verbindungen, die ein Intermediär zum Fachdienst aufbauen kann [VSDM-A_3023] mit einem maximalen Wert limitiert ist und er die Verbindungen ressourcenschonend und effizient nutzt.

Zuweisen zu Intermediär VSDM - Prüfverfahren: Funktionale Eignung: Test Produkt / FA

Zuweisen zu Intermediär VSDM - Prüfverfahren: Funktionale Eignung: Herstellererklärung