Vorabinformation zu den generellen Änderungen dieses Änderungseintrags: Es existieren übergreifende Festlegungen, die sich zwischen den Dokumenten [gemSpec_Perf] und [gemRL_Betr_TI] teilweise hindern. Darüber hinaus sind über die letzten Jahre verschiedene Begrifflichkeiten eingeführt und abgelöst worden, ohne die Konsistenz zur Anforderungslage oder den abgelösten Varianten eindeutig sicherzustellen. Die Vielzahl an redaktionellen Änderungen soll die schrittweisen Evolutionen von "Performance-Bericht" / "Performance-Rohdaten-Bericht" und "Berichte" aufräumen und gleichzeitig eine einheitliche Begriffsdefinition im vorhandenen Dokument stützen., die leicht und übersichtlich mit neuen Arten der Datenlieferungen ergänzt werden kann. Durch diese Änderungen werden keine Änderungen an Betriebsabläufen oder bereits etablierten Verfahren vorgenommen. Auch, wenn sich die Anforderungslage ggf. durch aktualisierte Anforderungen formal ändert, bleibt die Gesamtheit der Verfahren und der Abläufe konstant. Es ergeben sich hierbei keine neuen Verpflichtungen. 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.

Inhalt

1 Änderungen in gemSpec_Perf

Dieser Änderungseintrag ändert folgende Punkte konsistent ab: Anforderungen zu vorhandenen Betriebsdatenliefermodellen Kapitelstruktur unter gemSpec_Perf#2.5 Anpassung von Beschreibungstexten unter den angegebenen Kapiteln Trennung von Betriebsdatenlieferung Version 2 und Lieferung der Selbstauskunft Folgende Anpassungen sollen dokumentenweit redaktionell umgesetzt werden: Änderung des Betreffs der Festlegungen, betreffend Datenlieferungen zu "Performance - <Datenliefermodell> -*" Ablösung von "Rohdaten-Performance-Berichte" zum Wording des entsprechenden Datenliefermodells Ablösung von "Performance-Messwerte" zum Wording des entsprechenden Datenliefermodells Ablösung von "Berichte" zu "Lieferungen", aufgrund der automatisierten Verarbeitungslogik Streichung der Festlegungsbetreffe hinsichtlich "(Rohdatenerfassung v.02)", da bereits im Schema unter 1. deutlich Der Satz "Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN" und ähnliche werden ersetzt durch "Der Produkttyp MUSS" - der Kontext zum jeweiligen Datenliefermodell ergibt sich aus dem Titel der Anforderung.

2 Kapitel 2.4 Einsatz der Performance-Kenngrößen

Die Performance-Betrachtung dient dem Ziel, die benötigte und erwartete Leistung in Bezug auf die in [gemKPT_Betr] definierten 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 Blattanforderungen für das Bearbeitungszeitverhalten von Anwendungsfällen und Operationen an den Außenschnittstellen der Produkttypen gestellt. Dabei wird auch festgelegt unter welcher Last diese Vorgaben zu erfüllen sind. Diese sind zulassungsrelevant. Weiterhin werden betriebsbezogene Daten erfasst, welche eine direkte Rückkopplung auf verschiedenen Ebenen erlauben:

• Über die Störungsampel bzw. zukünftig über das Service Monitoring wird der aktuelle Zustand der TI reflektiert.
• Betriebsbezogene Daten 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.

Unter Kapitel 3 finden sich produktspezifische Festlegungen, die parallel im Rahmen von Performance-Kenngrößen abgebildet werden. Diese umfassen qualitative Dienstgüten. In den Unterkapiteln zu Kapitel 3 finden sich ebenfalls die Festlegungen zu den zu liefernden Betriebsdaten an den Gesamtverantwortlichen TI.

< Stornieren der Anforderung, da nicht mehr gültig - fehlende Produktzuordnung und Gültigkeit >

< Stornieren der Anforderung, da nicht mehr gültig - fehlende Produktzuordnung und Gültigkeit >

< Stornieren der Anforderung, da nicht mehr gültig - fehlende Produktzuordnung und Gültigkeit >

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.

< Stornieren der Anforderung, da nicht mehr gültig - fehlende Produktzuordnung und Gültigkeit >

< Stornieren der Anforderung, da nicht mehr gültig - fehlende Produktzuordnung und Gültigkeit >

< Die Angaben zur Datenlieferung finden sich dann im Kapitel Datenliefermodelle und die Beschreibung der Service-Level findet sich in den produktspezifischen Unterkapiteln unter Kapitel 3. >

Performance-Reporting-Daten

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

Last:

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

Bearbeitungszeit (jeweils pro Schnittstellenoperation)

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

Verfügbarkeit (jeweils pro Schnittstellenoperation)

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

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

Relevanz für Service Level Agreements

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

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

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

Die konkreten Leistungsanforderungen pro Produkttyp stellt Kapitel 4 dar.

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

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

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

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

2.1 aktualisiertes Kapitel 2.5 Datenliefermodelle

In diesem Abschnitt werden verschiedene Modelle eingeordnet, um betriebsbezogene Daten in unterschiedlichen Ausprägungen an die gematik zu liefern. Weiterhin wird eine Übersicht bereitgestellt, die den jeweils aktuellen Stand von Produkttypen und deren Zuordnung zu diesen Datenliefermodellen bereitstellt.

Zur Anlieferung von Daten an die gematik sind folgende Datenliefermodelle spezifiziert:

• Betriebsdatenlieferung 
• Version 1 (BDEv1)
• Version 2 (BDEv2)
• Bestandsdaten
• Selbstauskunft
• Version 1
• Version 2
• Ad-hoc-Reports
• Konnektordaten
• Ereignisdaten

Die Erläuterungen zu den Zielen und konkreten Festlegungen des jeweiligen Datenliefermodells findet sich in den entsprechenden Unterkapiteln.

Produktspezifische Festlegungen zu eingesetzten Datenliefermodellen finden sich größtenteils unter Kapitel 3. Sollten weitere Festlegungen außerhalb dieser Einordnung existieren, so wird in den folgenden Unterkapiteln darauf hingewiesen.

In der nachfolgenden Tabelle Tab_gemSpec_Perf_Zuordnung_Datenliefermodelle werden Produkttypen mit den aktuell spezifizierten Datenliefermodellen verknüpft. Die tatsächliche Verknüpfung erfolgt über das Zuweisen von Anforderungen und Prüfverfahren, dies wirkt sich dann auf die entsprechenden Steckbriefe aus.

Für die benannten Fälle, bei denen es keine unterschiedlichen Varianten der Datenliefermodelle gibt, wird automatisch immer die erste Version herangezogen. Sollten zu diesen Modellen zukünftig neue Varianten hinzukommen, wird eine explizite Versionierung in einem Unterkapitel eingeführt.

Maßgebend für die Ausgestaltung des Sendevorgangs zur erfolgreichen Lieferung von betrieblichen Daten ist das Dokument [gemSpec_SST_LD_BD]. Dieses Dokument soll zukünftig überarbeitet werden, um die hier aufgeführten Festlegungen zu vervollständigen.

< Link zu https://wiki.gematik.de/display/OP/6.+Performancemodell#id-6.Performancemodell-6.2.1VersionRohdatenformat-%C3%9Cberblick  >

Table # Tab_gemSpec_Perf_Zuordnung_Datenliefermodelle

PDT-ID	Name des Produkttyps	Aktuelle Datenliefermodelle
PDT01	OCSP-Responder-Proxy	BDEv2, Selbstauskunft
PDT02	Trust Service Provider X.509 QES	BDEv2, Selbstauskunft
PDT03	Trust Service Provider X.509 nonQES - eGK	BDEv2, Selbstauskunft
PDT04	TSL-Dienst	BDEv2, Selbstauskunft
PDT06	Namensdienst	BDEv2, Selbstauskunft
PDT07	Zeitdienst	Selbstauskunft, Bestandsdaten
PDT08	Zentrales Netz der TI	BDEv2, Selbstauskunft
PDT09	VPN-Zugangsdienst	BDEv2, Selbstauskunft
PDT10	Sicherheitsgateway für Bestandsnetze	BDEv2, Selbstauskunft
PDT11	Konfigurationsdienst	BDEv2, Selbstauskunft
PDT17	Konnektor	Konnektordaten
PDT20	Fachdienst VSDM (UFS)	BDEv2, Selbstauskunft
PDT21	Intermediär VSDM	BDEv2, Selbstauskunft
PDT22	gematik Root-CA	BDEv2, Selbstauskunft
PDT23	Fachdienst VSDM (VSDD)	BDEv2, Selbstauskunft
PDT24	Fachdienst KOM-LE	BDEv2, Selbstauskunft
PDT25	Verzeichnisdienst	BDEv2, Selbstauskunft
PDT26	Fachdienst VSDM (CMS)	BDEv2, Selbstauskunft
PDT27	KOM-LE-Clientmodul	-
PDT31	Trust Service Provider CVC	-
PDT32	CVC-Root	-
PDT36	Trust Service Provider X.509 nonQES - HBA	BDEv2, Selbstauskunft
PDT37	Trust Service Provider X.509 nonQES – Komponentenzertifikate	BDEv2, Selbstauskunft
PDT38	Trust Service Provider X.509 nonQES – SMC-B	BDEv2, Selbstauskunft
PDT43	ePA-Aktensystem	BDEv2, Selbstauskunft, Bestandsdaten
PDT44	ePA-Frontend des Versicherten	-
PDT47	Signaturdienst	BDEv2, Selbstauskunft
PDT48	Schlüsselgenerierungsdienst	BDEv1, Selbstauskunft
PDT50	E-Rezept-Fachdienst	BDEv2, Selbstauskunft, Bestandsdaten
PDT51	E-Rezept-Frontend des Versicherten	-
PDT52	Identity Provider Dienst	BDEv2, Selbstauskunft
PDT59	Apothekenverzeichnis	BDEv1, Selbstauskunft
PDT60	Private Key Generator	-
PDT64	TI-Messenger Fachdienst	BDEv2, Selbstauskunft
PDT66	Verzeichnisdienst FHIR	BDEv2, Selbstauskunft
PDT67	Highspeed Konnektor	BDEv2, Selbstauskunft
PDT68	Sektoraler Identity Provider (V1.0)	BDEv2, Selbstauskunft
PDT69	National Contact Point for eHealth Fachdienst	BDEv2, Selbstauskunft
PDT70	Federation Master	BDEv2, Selbstauskunft
PDT72	TI-Gateway-Zugangsmodul	BDEv2, Selbstauskunft
PDT73	Sektoraler Identity Provider - Kostenträger	BDEv2, Selbstauskunft
PDT77	eHealth-CardLink	Ereignisdaten

Hinweis zur Tabelle: Produkttypen, die von ihrer Beschaffenheit oder Intention nicht zum selbstständig wiederkehrenden Senden von Daten geeignet sind, werden hier nicht erfasst (dies umfasst v.a. physische Kartenprodukte wie eGK, SMC-B).

< Das folgende Kapitel 2.5.1 wird umbenannt in "Betriebsdatenerfassung Version 1 (BDEv1)" >

2.2 Kapitel 2.5.1 Betriebsdatenerfassung

< Der folgende Abschnitt wird entfernt >

Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 1.0 und befindet sich aktuell in der strukturellen Überarbeitung. Inhaltliche Änderung werden sich lediglich in jener Form ergeben, dass die Produkte nach und nach zur Rohdatenerfassung in der Version 2.0 verpflichtet werden. Aktuell bestehende Zulassungen sind davon nicht betroffen. Das Update wird in Kürze eingearbeitet.

Im Folgenden ist das Berichtsformat in der Version v.01 beschrieben. Produkttypen, welche auf diese Version verpflichtet sind, werden im Laufe der Zeit auf die aktuellste Version angehoben. Neuzulassungen sind auf die Version v.01 nicht mehr möglich.

< Der folgende Abschnitt wird eingefügt, übernommen aus dem ehemaligen Kapitel 2.5 >

Die Betriebsdaten eines Produkttyps erfassen das Last- und Performanceverhalten von Diensten und Komponenten der TI durchgehend und dauerhaft. Diese Daten beinhalten folgende Informationen:

• Zeitpunkt des Aufrufs
• Bearbeitungszeit des Aufrufes
• aufgerufene Operation
• Indikator zum Status der Operationsbearbeitung
• weitere produkttypspezifische und operationsspezifische Informationen

In diesem Vorgang erfassen die Produkttypen ihre Betriebsdaten und liefern sie der von der gematik bereitgestellten Schnittstelle zur Betriebsdatenerfassung, kurz BDE, in der spezifizierten Güte regelmäßig an. Die Erfassung dieser Daten führt also zu einer Betriebsdatenlieferung an die gematik. Die Begriffe Betriebsdatenlieferung und Betriebsdatenerfassung werden deshalb meist synonym verwendet und bezeichnen damit die Lieferung von spezifizierten Betriebsdaten an die gematik.

Die angelieferten Betriebsdaten werden dann mit den festgelegten Performance-Kenngrößen des jeweiligen Produkttyps abgeglichen und es wird auf deren Basis die Einhaltung der spezifizierten Service Level ermittelt. Dadurch wird zusätzlich ein zeitlicher Verlauf erstellt, welcher die Last und das Aufrufverhalten nachhaltig dokumentiert.

2.2.1 verschoben: Kapitel 2.5.1.1 Betriebsdatenerfassung Version 1

Im Folgenden werden die Festlegungen zur Betriebsdatenerfassung Version 1, auch Betriebsdatenerfassung v1 oder kurz BDEv1, näher beschrieben. Dieses Datenliefermodell und dessen Endpunkte sollen sukzessive offline genommen werden, da die Unterstützung neuer Versionen vorangetrieben wird. Eine Umstellung der betroffenen Komponenten und Dienste muss bis dahin erfolgt sein. Die hier getroffenen Festlegungen koppeln BDEv1 mit der Selbstauskunft. Eine Entkopplung wird für diese Version der Betriebsdatenerfassung nicht anstrebt.

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

Ein Beispiel für zwei Einträge, der Erste zu einem fehlerfreien Aufruf, der Zweite zu einem nicht fehlerfreien Aufruf:

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

Hinweis:

Unter einer fehlerhaften Operation wird verstanden, wenn die Operation z.B. selbst fehlerhaft abgebrochen wurde bzw. nicht oder zu spät beantwortet wurde. Eine Antwort auf ein nicht vorhandenes Datum (ICCSN, Seriennummer etc.) ist eine fehlerfreie Operation und nicht mit ".failed" zu kennzeichnen.

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

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

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v1 -*"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferung"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Berichte" zu "Lieferungen" >

< Das folgende Kapitel 2.5.2 wird umbenannt in "Betriebsdatenerfassung Version 2 (BDEv1)" >

2.2.2 verschoben: Kapitel 2.5.1.2 Betriebsdatenerfassung Version 2

Die Betriebsdatenerfassung in Version 2 aktualisiert und konkretisiert die Festlegungen der vorausgegangenen Version hinsichtlich des Inhalts, Formats und der Rahmenbedingungen und ersetzt diese vollständig. Dabei wird ein größerer Fokus auf die Rückmeldung konkreter Statuscodes gelegt und ein produktindividuelles Message-Feld im JSON-Format eingeführt.

Ziel dieses Liefermodelles ist, einen detaillierteren Einblick in die Art und Weise der Rückmeldung des Dienstes zu bekommen, damit die betriebliche Steuerung und das differenzierte Aufrufverhalten qualitativ eingeordnet werden kann.

Im Folgenden werden die Festlegungen zur Betriebsdatenerfassung Version 2, auch Betriebsdatenerfassung v2 oder kurz BDEv2, näher beschrieben.

< Der Informationsblock wird entfernt >

Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 2.0 und befindet sich aktuell in der strukturellen Überarbeitung. Die hier bereits aufgeführten Anforderungen werden dabei nicht verändert, sondern lediglich um Erläuterungen ergänzt. Das Update wird in Kürze eingearbeitet.

< Der Absatz wird entfernt >

Die Version 2 der Betriebsdatenerfassung, kurz "BDEv2", . Neuzulassungen oder Änderungszulassungen sind nur auf Basis der Rohdatenerfassung v.02 möglich.

Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02 gibt einen Überblick über die Produkttypen, welche bereits Rohdaten-Performance-Berichte in der Version v.02 übermitteln, bzw. sich aktuell in der Umstellung befinden.

< Die Tabelle wird entfernt >

Tabelle 1: Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02

PDT	Produkttyp
PDT01	OCSP-Responder-Proxy
PDT02	Trust Service Provider X.509 QES
PDT03	Trust Service Provider X.509 nonQES - eGK
PDT04	TSL-Dienst
PDT06	Namensdienst
PDT08	Zentrales Netz der TI
PDT09	VPN-Zugangsdienst
PDT10	Sicherheitsgateway für Bestandsnetze
PDT11	Konfigurationsdienst
PDT21	Intermediär VSDM
PDT22	gematik Root-CA
PDT24	Fachdienst KOM-LE
PDT31	Trust Service Provider CVC
PDT36	Trust Service Provider X.509 nonQES - HBA
PDT37	Trust Service Provider X.509 nonQES – Komponentenzertifikate
PDT38	Trust Service Provider X.509 nonQES – SMC-B
PDT43	ePA-Aktensystem
PDT47	Signaturdienst
PDT50	E-Rezept-Fachdienst
PDT52	Identity Provider Dienst
PDT64	TI-Messenger Fachdienst
PDT67	Highspeed Konnektor
PDT68	Sektoraler Identity Provider (V1.0)
PDT69	National Contact Point for eHealth Fachdienst
PDT72	TI-Gateway-Zugangsmodul

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 - Verpflichtung des Anbieters"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Rohdaten" zu "Betriebsdaten" >
• "Rohdatenerfassung v.02" zu "Betriebsdatenerfassung v2" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 - Erfassung von Betriebsdaten"
• "Performance-Rohdaten" zu "Betriebsdaten"
• "Rohdaten-Performance-Reporting" zu "Betriebsdatenlieferung v2" >

2.5.1.2.1 Umfang

<Ablösung der Anforderung durch Iteration -02>

< Neue Anforderung als Ablösung für Vorgänger >

PLUS Regelung für die Selbstauskunft im entsprechenden Kapitel zum Dateinamen

siehe 2.4.1 neu: Kapitel 2.5.3.1 Selbstauskunft Version 1 

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Berichte" zu "Lieferungen" >

Hinweis: Für weitere Informationen zum CI, siehe [gemRL_Betr_TI] Kapitel "Configuration Management".

< Ablösung der Anforderung und Aufteilung in neue Anforderung zur Betriebsdatenlieferung (A_22001-02) und Selbstauskunft (A_26173) >

PLUS neue Anforderung zur Selbstauskunft im Kapitel 2.5.X, analog zum Lieferintervall:

siehe 2.4.1 neu: Kapitel 2.5.3.1 Selbstauskunft Version 1 

< Verschiebung der Anforderung A_22429 nach Kapitel "Selbstauskunft Version 1">

A_22429 wird verschoben, siehe 2.4.1 neu: Kapitel 2.5.3.1 Selbstauskunft Version 1 

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Berichte" zu "Lieferungen" >

Hinweis: "Intervalltreu" bedeutet hierbei: Jeder Eintrag muss in die Betriebsdatenlieferung aufgenommen werden, dessen Endzeitpunkt ($timestamp + $duration_in_ms) im Berichtsintervall realisiert wurde.

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen" >

Die Nachlieferung hat dabei in der gleichen Art wie die Originallieferung zu erfolgen (keine Zusammenfassung mehrerer Betriebsdaten-Nachlieferungen). Bei mehreren Nachlieferungen sind die Einzellieferungen separat und zeitlich gestaffelt zwischen den Standardlieferungen zu tätigen (z.B. bei einem 5-Minuten-Intervall nach 2,5 Minuten EINE Nachlieferung und nach 5 Minuten dann die Standardlieferung).

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Rohdaten-Berichte" zu "Betriebsdaten"
• "des Gesamtverantwortlichen TI" zu "der gematik" >

Die vorgeschriebenen Aufbewahrungspflichten bleiben hiervon unberührt. Umfang und Details zur Nachlieferung bzgl. Nachlieferungszeitpunkt und Zusammenfassung sind mit der gematik dem Gesamtverantwortlichen TI abzustimmen. 

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Der Anbieter, der zur Rohdatenlieferung verpflichtet ist, " zu "Anbieter, deren Produkttypen ihre Betriebsdaten in Betriebsdatenlieferungen übermitteln,"
• "Rohdatenlieferung" zu "Betriebsdatenlieferung"
• "Lieferung der Rohdaten" zu "Betriebsdatenlieferung" >

2.5.1.2.2 Lieferintervalle

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Berichtsdateien" zu "Betriebsdatenlieferung" >

< Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Berichtsdateien" zu "Betriebsdatenlieferung"
• "des Gesamtverantwortlichen TI" zu "der gematik"
• Inkludieren von Regelungen nach A_21978, indem die Änderung der Konfiguration getrennt von anderen Datenmodellen möglich sein muss >

Hinweis: Die Anpassung der Lieferintervalle ist im Rahmen des TI-ITSM durch das Changemanagement zu prozessieren.

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Der Anbieter, dessen Produkt zur Umsetzung der Rohdatenerfassung v.02 verpflichtet ist, MUSS" zu "Anbieter, deren Produkttypen ihre Betriebsdaten in Betriebsdatenlieferungen übermitteln, MÜSSEN" >

< Wegfall/Stornierung der AFO durch Redundanz zu A_22047-01 >

< Ablösung der Anforderung und Anpassung in folgenden Punkten für den Nachfolger (folgt):

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen" >
• Entfernen der Selbstauskunft

< Neue Anforderung als Ablösung des Vorgängers >

PLUS LIEFERINTERVALLE SELBSTAUSKUNFT

siehe 2.4.1 neu: Kapitel 2.5.3.1 Selbstauskunft Version 1 

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "der Berichtsdateien" zu "dieser">

< Anpassung und Ablösung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• Der Satz "Für die Selbstauskunft ergibt sich daraus keine Besonderheit, sodass diese wie definiert zu übertragen ist." wird gestrichen >

< Neue Anforderung als Ablöse des Vorgängers >

2.5.1.2.3 Format

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• "Konventionen erfüllen:" zu "Konventionen umsetzen:" >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen"
• Anpassung des Tabellennamens von "Tab_gemSpec_Perf_Standard-Statuscodes" zu "Tab_gemSpec_Perf_Standard_Statuscodes" >

Hinweis: Es sind vom Hersteller, anstatt der Status Code Klassen (first digit of status code), die konkreten 3-stelligen HTTP-Statuscodes gemäß [RFC9110] zu verwenden. 

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Performance-Messwerte" zu "Betriebsdaten"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen" >

Beispielhafte Einträge eines Produktes und einer dazugehörigen Operation:

• 1000212390109;447;Beispielprodukt.Beispieloperation;200;{"ID":12}
• 1000212470109;155;Beispielprodukt.Beispieloperation;40001;{"ID":12,"Antwort":"gesperrt"}
• 1000212470109;985;Beispielprodukt.Beispieloperation;70001;{"ID":12,"Antwort":null}
• 1000212470109;985;Beispielprodukt.Beispieloperation;70001;{}

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Betriebsdatenlieferung v2 -*" und Streichen von "(Rohdatenerfassung v.02)"
• "Rohdaten-Performance-Berichte" zu "Betriebsdatenlieferungen" >

< Einfügen neues Kapitel "Bestandsdaten">

2.3 neu: Kapitel 2.5.2 Bestandsdaten

Bei den Bestandsdaten handelt es sich um eine individuell wiederkehrende Datenlieferung im JSON-Format. Diese Datenlieferart ermöglicht die Übertragung von vorher festgelegten, strukturierten Informationen an die gematik ohne den Upload einer separaten Datei. Stattdessen findet die Anlieferung der Bestandsdaten über den POST-Body statt und wird über den Aufruf an einem gesonderten Endpunkt an die gematik realisiert. Die Stärke von Bestandsdaten liegt in der Erfassung von Momentaufnahmen - also dem Zustand eines Dienstes oder einer Komponente der TI.

In Abgrenzung zur Betriebsdatenlieferung werden hier vorrangig keine transaktionalen Daten erfasst oder verarbeitet, sondern vielmehr Daten zum Gesamtzustand oder zum Zwecke der Erstellung von Übersichten, über die ebenfalls eine zeitliche Entwicklung nachvollzogen werden kann.

Die Bestandsdatenlieferung zeichnet sich durch einen hohen Individualisierungsgrad aus, welcher jeweils produktspezifisch unter Kapitel 3 festgelegt werden kann. 

< Für die produktspezifischen Bestandsdatenlieferungen wird die Regelung zum Timestamp konkretisiert:

• In die produktspezifischen Anforderungen zum Zeitstempel wird die Beschreibung mit folgendem Satz ersetzt: "Zeitangabe als String gemäß ISO 8601 ** unter expliziter Angabe ** einer Zeitzone, z.B. YYYY-MM-DDTHH:mm:ss[.fff]Z" >

< Einfügen neues Kapitel "Selbstauskunft" >

2.4 neu: Kapitel 2.5.3 Selbstauskunft

Bei der Selbstauskunft handelt es sich um eine standardisierte und wiederkehrende Datenlieferung, bei der Metainformationen über den eingesetzten Dienst oder die Komponente der TI verankert sind. Diese Informationen sind jeweils zustandsbezogen.

< Aus gemSpec_OM Kapitel 2.4>

Um während des Entwicklungsprozesses und des Betriebs der TI feststellen zu können, welche Versionen von Produkten für die einzelnen Produktinstanzen aktuell eingesetzt werden, muss es möglich sein, den Versionsstand des Produkts für alle Produktinstanzen zu ermitteln.

In vorigen Versionen dieses Dokuments war die Selbstauskunft Version 1 mit den Festlegungen der Betriebsdatenerfassung Version 1 und 2 verankert. Diese Verankerung wurde gelöst und als eigenständiges Datenliefermodell in diesem Kapitel etabliert.

Folgende Anforderungen gelten für alle Selbstauskunftslieferungen.

< Verschoben aus gemSpec_OM Kapitel 2.4 >

< Hinzufügen der Zuordnung aller Produkte (Herstellererklärung) und Anbieter (Anbietererklärung), die vorher via BDEv1 oder BDEv2 Selbstauskunft zugeordnet waren und dem Zeitdienst >

2.4.1 neu: Kapitel 2.5.3.1 Selbstauskunft Version 1

Die Selbstauskunft Version 1, auch Selbstauskunft v1, setzt bei der Datenanlieferung auf eine dateibasierte Informationsgrundlage im gegebenen Rahmen der [gemSpec_OM]. Dazu werden hinsichtlich des Inhalts, Formats und der Rahmenbedingungen folgende Festlegungen getroffen.

< Hinzufügen der Zuordnung aller Produkte (Herstellererklärung), die vorher via BDEv1 oder BDEv2 Selbstauskunft zugeordnet waren und dem Zeitdienst >

Hinweis: Die Verarbeitung kann auch in geeigneter Form außerhalb des Produkttyps umgesetzt werden, sodass der Anbieter die vollständige Aufbereitung und Übermittlung gewährleitet und die Erfüllung nicht direkt über den Produkttyp erfolgt.

< Hinzufügen der Zuordnung aller Produkte (Herstellererklärung), die vorher via BDEv1 oder BDEv2 Selbstauskunft zugeordnet waren und dem Zeitdienst >

< Redaktionelle Anpassung der Anforderung in folgenden Punkten:

• Änderung des Betreffs zu "Performance - Selbstauskunft v1 - Inhalt" und Streichen von "(Rohdatenerfassung v.02)"
• "ihre Performance-Messwerte in Rohdaten-Performance-Berichten" zu "eine Selbstauskunft"
• "Erstellung der Selbstauskunft" zu "Erstellung dieser" >

2.4.2 neu: Kapitel 2.5.3.1 Selbstauskunft Version 2

Die Selbstauskunft Version 2, auch Selbstauskunft v2, setzt bei der Erfassung und Übermittlung auf JSON-basierten Inhalt und löst die Lieferung von Dateien ab. Durch die direkte Übermittlung in einem HTTP-Request als POST-Body werden Abläufe schlanker und Automatisierung gefördert. Die Einführung eines neuen Inhaltsschemas begünstigt die zukünftige Erweiterbarkeit ohne Abhängigkeiten zu dezentralen Produkttypen und erweitert die geltenden Regelungen nach gemSpec_OM#Kapitel 2.4 in moderner Weise.

< Wird noch keinem Produkt oder Anbieter zugeordnet >

< Wird noch keinem Produkt oder Anbieter zugeordnet >

Hinweis: Die Verarbeitung kann auch in geeigneter Form außerhalb des Produkttyps umgesetzt werden, sodass der Anbieter die vollständige Aufbereitung und Übermittlung gewährleitet und die Erfüllung nicht direkt über den Produkttyp erfolgt.

< Einfügen neues Kapitel "Ad-hoc-Reports" >

2.5 neu: Kapitel 2.5.4 Ad-hoc-Reports

Bezugnehmend auf die Regelungen in [gemRL_Betr_TI], Kapitel 2.1.3 werden die Vorgaben zur Übermittlungen von Ad-hoc-Reports festgelegt.

< Umzug der Anforderung aus gemRL_Betr_TI und Abänderung der Anforderung als konkrete Anbieterpflicht (vormals TI-Teilnehmer mit aktualisierten Referenzen>

< Ändern und Verschieben nach gemSpec_Perf Kapitel "Ad-hoc-Reports">

=> Fusion mit GS-A_5248 erfolgt

< Einfügen neues Kapitel "Konnektordaten" >

2.6 neu: Kapitel 2.5.5 Konnektordaten

Konnektordaten sind die operativen Betriebsdaten aus den VPN-Zugangsdiensten gemäß [A_21160-02#gemSpec_VPN_ZugD]. Diese werden von den Konnektoren an eine Sammelschnittstelle geschickt, wo sie aufbereitet und anonymisiert werden. Nach dieser Bearbeitung werden diese Daten an die gematik gesendet und zur operativen Verfügung gestellt.

< Einfügen neues Kapitel "Ereignisdaten" >

2.7 neu: Kapitel 2.5.6 Ereignisdaten

< Der Inhalt aus gemSpec_Perf#Kapitel 2.6 "Ereignisdaten" wird hier hinein übertragen >

Die Ereignisdaten eines Produkttypen erfassen den Zustand von Anwendungsfällen und stellen diese der Ereignisdatenschnittstelle in dem hier definierten Format zur Verfügung.

< Die Tabelle wird aufgrund Redundanz entfernt >

Tabelle 3: Tab_gemSpec_Perf_Produkte_Ereignisdaten

PDT	Produkttyp
PDT77	eHealth-CardLink

2.7.1 Kapitel 2.5.6.1 Lieferintervall

2.7.2 Kapitel 2.5.6.2 Format

2.8 Weitere redaktionelle Änderungen

< Weitere redaktionelle Änderungen im Dokument werden nicht näher beschrieben, da die Vielzahl an Anpassungen die Lesbarkeit verringert. Es werden vor allem im Kapitel 3, die Titel produktspezifischer Anforderungen auf das aktuelle Format angepasst und die Begriffe wie z.B. "Rohdaten-Performance-Reporting" in jeder Form (Überschrift, Kapitelmarken, Anforderungen) konsistent ersetzt.

Insgesamt werden 123 Ersetzungen von "Rohdaten-Performance-Berichte" durchgeführt.

Insgesamt werden 135 Ersetzungen von "Rohdaten" durchgeführt und Weitere. >

Änderungen an gemRL_Betr_TI

Dieser Teil des Änderungseintrags ändert folgende Punkte konsistent ab: Analog zu den Änderungen in gemSpec_Perf wird auch hier Begriffs-Konsistenz hergestellt Festlegungen werden abgelöst, die derzeit nicht weiter in aktiver Nutzung sind oder andere Festlegungen hindern Anpassung der Beschreibungstexte in angegebenen Kapiteln Entfernen von Kapitelstrukturen, die nicht weiter genutzt werden oder ansonsten leer stünden Umzug der Anforderungslage zu Datenlieferungen in gemSpec_Perf, wo sinnvoll

3 Änderungen an gemRL_Betr_TI --- Thema/Kapitel Performance

3.1 Kapitel 10.2.1 Performance messen

Zur Zielerreichung des Performance-Managements der TI müssen TI-ITSM-Teilnehmer Performance-Messungen durchführen und die Ergebnisse als betriebliche Datenlieferung berichten.

Die Messergebnisse dienen dabei im Wesentlichen

• zur Feststellung und Analyse des aktuellen Performance-Status der TI-Anwendungen und –Services und, darauf aufbauend, der Prognostizierung zukünftiger Performance-Anforderungen hinsichtlich Verfügbarkeit, Durchsatz und Bearbeitungszeit und
• zur Planung und Steuerung von Kapazitätsanpassungen, um bestehende bzw. drohende Engpässe kompensieren und ggf. vorhandene Überkapazitäten beseitigen zu können.

Die Datenerhebung erfolgt durch den TI-ITSM-Teilnehmer innerhalb der von ihm verantworteten TI-relevanten Systeme und Prozesse basierend auf den Vorgaben der [gemSpec_Perf].

< Anforderung wird storniert und ist nicht weiter gültig >

Suche nach Referenzen A_18363 - Frage ans SIM-Team, ob die Unterstützungsleistung noch gebraucht wird.

Festlegung und Abstimmung müssen rechtzeitig vor Aufnahme des Betriebs eines Produktes in einer Betriebsumgebung des TI-ITSM-Teilnehmers im Rahmen des Anbieterzulassungsverfahrens erfolgen, damit die Bereitstellung der Werte der definierten Performance-Kenngrößen für die Betriebsüberwachung und im Service Level Reporting vor Aufnahme des Wirkbetriebes erfolgen kann.

3.2 Kapitel 10.2.2 Performance reporten

Die Übermittlung von Ergebnissen der Performance-Messung in Form von Performance-Reports befindet sich in der schrittweisen Ablösung und wird vollständig durch die Lieferung in Form von Rohdaten ersetzt.

Die Übermittlung der Ergebnisse der Performance-Messung erfolgt entweder durch die Lieferung von Performance-Reports (das Verfahren befindet sich in der schrittweisen Ablösung) oder durch die Lieferung von Rohdaten in Form von Rohdaten-Performance-Berichten. Welche der beiden möglichen Lieferarten für ein Produkt / einen Anbieter relevant ist, ist durch die Zuweisung der entsprechenden Anforderungen geregelt - eine Wahlfreiheit besteht im Allgemeinen nicht.

Die umfangreichen Details der Datenlieferungen sind in [gemSpec_Perf] geregelt.

< Anforderung wird storniert und ist nicht weiter gültig, weil die Notwendigkeit dafür entfällt >

< Anforderung wird storniert und ist nicht weiter gültig, da Doppelanforderung mit Rohdaten unter Kap 2.5 in gemSpec_Perf >

< Der Endpunkt wird nicht in der Wissensdatenbank bekannt gegeben oder dokumentiert und eine Lieferung von Performance-Rohdaten-Reports via E-Mail wird nicht mehr regelhaft praktiziert. Daher wird dieser Textabschnitt gestrichen. >

Der Endpunkt wird vom GTI in der Wissensdatenbank bekannt gegeben. Bei Änderungen des Endpunktes bzw. bei Wechsel des Verfahrens (Ablösung von E-Mail) werden die TI-ITSM-Teilnehmer mit angemessenem zeitlichen Vorlauf informiert.

< Anforderung wird storniert und ist nicht weiter gültig, da Doppelanforderung mit Rohdaten unter Kap. 2.5 in gemSpec_Perf >

< Anforderung wird storniert und ist nicht weiter gültig, weil keine Performance-Reports mehr gesendet werden >

< Anforderung wird storniert und ist nicht weiter gültig >

[..]

< Der Zusatz (finale Lösung) im Kapitelmarker 10.2.4 entfällt >

3.3 Kapitel 10.2.4 Service Monitoring

Mit Einführung der finalen Lösung des Service Monitoring der TI durch den Gesamtverantwortlichen TI wird die Neuausrichtung der TI-Betriebssteuerung auch systemtechnisch sichtbar. Mit Hilfe des neuen Systems werden einerseits Verfügbarkeit und Antwortzeit von TI-Systemen und Services bzw. Dienste gemessen und überwacht. Gleichzeitig berichten die TI-ITSM-Teilnehmer mittels spezifizierter Datenmodelle ebenfalls ausschließlich an dieses System. Neben der physikalischen Erreichbarkeit werden vom eingesetzten Service Monitoring selbst auch qualifizierte Anfragen an die Dienste gestellt und aus den Antworten dieser wird (automatisiert) auf den Servicezustand geschlossen.

Die gematik wird auf Basis dieser Auswertungen jederzeit zum aktuellen Status der TI aussagefähig sein und kann auf Basis der Kenntnis um den äußeren Gesamtstatus der TI ggf. notwendige Maßnahmen einleiten. Das Service Monitoring beinhaltet damit sämtliche Themen des hier definierten Performance Managements. Eine Überwachung aller eingesetzten Systeme und Services, die sich in der Eigenverantwortlichkeit der TI-ITSM-Teilnehmer befinden, findet allerdings nicht statt.

Nutzer des Service Monitoring Systems sind alle am Betrieb der TI Beteiligten (gemäß Definition dieser Richtlinien [gemRL_Betr_TI]). Anwender (Versicherte/Leistungserbringer) haben keinen direkten Zugriff. Die Regelung des Zugriffs auf die Darstellungseinheit des Service Monitoring Systems (z.B. mittels Live-Dashboard) erfolgt über ein Rollen- und Berechtigungskonzept. Auf der Darstellungseinheit werden z.B. die Auswirkungen eines festgestellten Servicedefizites angezeigt. Weiterhin besteht die Möglichkeit zur Anbindung von Drittsystemen bei den TI-ITSM-Teilnehmern mittels Schnittstelle gemäß den definierten Berechtigungen. Auf diese Weise können Meldungen über aktuelle Systemzustände bzw. Systemdefizite der betroffenen Dienste automatisiert auch auf Drittsysteme übertragen werden.

Nach Einführung des Service Monitorings wird das monatliche Reporting von gelieferten Daten (Verfügbarkeit, Durchsatz, Bearbeitungszeit) der TI-ITSM-Teilnehmer an den Gesamtverantwortlichen der TI angepasst mit dem Ziel einer teilweisen oder vollständigen Ersetzung. Bis zu diesem Zeitpunkt behalten die bestehenden Anforderungen und Vorgehensweisen Gültigkeit. Auch wird mit der Einführung dieses Systems die Störungsampel abgelöst. Welche betrieblichen Anforderungen mit der Einführung des Service Monitorings der TI stattdessen im Rahmen dieser Richtlinien bzgl. Performance-Management zukünftig definiert werden, ist zum jetzigen Zeitpunkt noch nicht geklärt.

4 Änderungen an gemRL_Betr_TI --- Thema ad-hoc Reporting

< Ad-hoc-Reporte werden in gemRL_Betr_TI mit zum TI-ITSM Reporting gezählt, die Festlegungen jedoch in gemSpec_Perf weitergeführt. >

4.1 Kapitel 2.1.3 TI-ITSM-Reporting

Informationen zu übergreifenden Vorgängen, wie Vorgangsdaten, Lösungsdokumentation etc., sind im zentralen TI-ITSM-System vorhanden. Der Gesamtverantwortliche TI wird die im System vorhandenen Daten zum übergreifenden TI-Reporting verwenden.

Der Gesamtverantwortliche TI wird einmal im Monat die vom TI-ITSM-System zur Verfügung gestellten und aus den übermittelten Daten das TI-Reporting aufbereiten.

Der Gesamtverantwortliche TI kann ad-hoc, also außerplanmäßig, Reports anfordern. Dabei kann es erforderlich werden, andere Kennzahlen (innerhalb eines zumutbaren Umfangs für den TI-ITSM-Teilnehmer) abzufragen. Entsteht solch eine Notwendigkeit zur Erhebung weiterer Messgrößen, werden diese gemeinsam mit den betroffenen TI-ITSM-Teilnehmern individuell abgestimmt.

Die näheren Festlegungen zu Ad-hoc-Reports sind in [gemSpec_Perf] geregelt.

< Ablösung der Anforderung durch Nachfolger und Umzug der Regelung>

< Umzug der Anforderung in die gemSpec_Perf und Abänderung der Anforderung als konkrete Anbieterpflicht; Vorschlag zur Überarbeitung und Verschieben in gemSpec_Perf unter Kapitel "Ad-hoc-Reports" >

siehe 2.5 neu: Kapitel 2.5.4 Ad-hoc-Reports 

4.2 entfällt: Kapitel 13 Vorschriften für CSV-Reporting

< Ablösung der Anforderung durch Nachfolger >

< Ändern und Verschieben nach gemSpec_Perf Kapitel "Ad-hoc-Reports">

siehe 2.5 neu: Kapitel 2.5.4 Ad-hoc-Reports 

< Ablösung der Anforderung durch Nachfolger >

< Ausreichende CSV-Reporting Themen analog Rohdaten-Lieferverpflichtung in A_21981-02>

< Änderung des Anforderungsnamens zu "Format von übermittelten CSV-Dateien in Ad-hoc-Reports", dazu Aktualisierung der Anforderung und Verschieben nach gemSpec_Perf Kapitel "Ad-hoc-Reports" >

siehe 2.5 neu: Kapitel 2.5.4 Ad-hoc-Reports 

< Stornieren der Anforderung, da nicht mehr zeitgemäß - fehlende Definition von Prozessdaten >

< Die Tabelle entfällt, da ohne Anforderungsreferenz auch keine weitere Gültigkeit >

Tabelle 5: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle

reservierte Zeichen	Muss ersetzt werden durch	Begründung
#	<Hash>	Reserviertes Zeichen, für die Feldtrennung. Sie müssen ersetzt werden durch den Text <Hash>.
Zeilenumbruch	<br>	Zeilenumbrüche in Inhaltsfeldern erhöhen die Fehlerwahrscheinlichkeit beim Einlesen der CSV-Datei durch das Zielsystem. Sie müssen ersetzt werden durch den Text <br>
Doppeltes Anführungszeichen (ASCII 34)	’ (ASCII 39)	Reserviertes Zeichen, für die Markierung der Inhalte von Feldern. Sie müssen ersetzt werden durch ein „Einfaches Anführungszeichen“.
<tr>	löschen	Reservierte Zeichen, für eine Datensatztrennung im Inhaltsfeld. Die Zeichen müssen gelöscht werden.
</tr>	löschen	Reservierte Zeichen, für eine Datensatztrennung im Inhaltsfeld. Die Zeichen müssen gelöscht werden.

< Kapitel 13.1 entfällt unverändert>

4.3 entfällt: Kapitel 13.1 Basisfeldtypen von Prozessdaten

Tabelle Tab_Betr_TIP_030 definiert Basisfeldtypen, die in konkreten Definitionen fachlicher Tabellen referenziert werden. In der Definition der fachlichen Tabellen können diese Basisfeldtypen weiter durch Constraints konkretisiert werden, z. B. durch Einschränkung auf eine fachlich definierte Wertemenge.

Tabelle 6: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien

Basisfeldtyp	Definition	Beispiel
[String]	Beliebige Zeichenkette mit den Anforderungen aus GS-A_5249	Hello World
[Date]	Gemäß [ISO-Norm 8601] folgendes Format auf Grundlage der lokalen Zeit gegenüber UTC: YYYY-MM-DDThh:mm:ss±hh	2015-02-23T01:47:36+01
[Date]	als Bestandteil eines Dateinamens: YYYYMMDDThhmmss±hh	20150223T014736+01
[Integer]	+-nnnnnnnnn	88888888
[Double]	+-nnnnn,nnn	2,456
[Auswahlfeld], (Auswahl1), (Auswahl2), (Auswahln)	Es ist immer nur ein Wert von Auswahl n gültig. Beispiel :[Auswahlfeld], (ja), (nein)	ja
[Telefonnummer]	[String] DIN 5008	+49 30 40041-999
[hh.mm]	Uhrzeit: zwei Stellen für Stunde, zwei Stellen für Minuten gemäß [ISO-Norm 8601]	12:30
[hhhh:mm:ss]	Dauer in Stunden, zwei Stellen für Minuten, zwei Stellen für Sekunden	0012:04:10

5 Änderungen an gemRL_Betr_TI: Verschiebung gemKPT_Betr Kapitel 4.3 in Kapitel 9.2.3 Teilnahme am Service Level Review

< Folgende Anforderungslage aus gemKPT_Betr, Kapitel 4.3 wird am Ende des Kapitels 9.2.3 eingefügt. >

< Die Anforderung A_24800 wird im Betreff umbenannt, um den Regelungen in gemRL_Betr_TI besser zu entsprechen >

• A_24800 - Service Level Review - Auskunft Servicebedarf

Die Auskunft über die Servicebedarfe der Nutzer (z. B. Versicherte) soll, über die Informationen des ITSM hinaus, Erkenntnisse liefern, welche Probleme/Herausforderungen Nutzer im Umgang mit dem Produkt/Service haben und welche Maßnahmen zu deren Bewältigung getroffen wurden. Die Erkenntnisse fließen auf diesem Wege auch zum Produktdesign zurück und in die Produktweiterentwicklung ein. Für die Krankenkassen leitet sich daraus keine Berichtspflicht in Richtung der von ihnen beauftragten Dienstleister ab. Der TI-ITSM-Teilnehmer berichtet über das Serviceaufkommen, das ihm bekannt ist.

6 Änderungen an gemSpec_OM Kapitel 2.4 Selbstauskunft

< Die gültigen Festlegungen aus Kapitel 2.4 "Selbstauskunft von Produkten" werden nach gemSpec_Perf Kapitel "XXX" verschoben und das Kapitel zu "Selbstauskunft von Karten und FdVs" umbenannt >

< Wird nicht verschoben, bleibt bestehen für Karten >

< Wird abgelöst, da bereits in gemSpec_Perf im Kapitel 2.5.3 für diese Produkttypen geregelt >

< Wird abgelöst, da bereits in gemSpec_Perf im Kapitel 2.5.3 für alle zugewiesenen Produkttypen geregelt >

< redaktionelle Änderung des Anforderungsnamens und des Inhalts in folgenden Punkten:

• A_17792 - Rückgabe der Versionsinformationen von Software Modulen über Benutzerschnittstelle
• Änderung "Selbstauskunft" in "Versionsinformationen"

< redaktionelle Änderung des Anforderungsnamens und des Inhalts in folgenden Punkten:

• A_17792 - Rückgabe der Versionsinformationen von Software Modulen auf Dateibasis
• Änderung "Selbstauskunft" in "Versionsinformationen"

< Wird abgelöst, da bereits in gemSpec_Perf im Kapitel 2.5.3 für Produkttypen geregelt, Störungsampel abgelöst >

< Wird abgelöst, da bereits in gemSpec_Perf im Kapitel 2.5.3 für Produkttypen geregelt, Störungsampel abgelöst >

< Wird abgelöst, da bereits in gemSpec_Perf im Kapitel 2.5.3 für Produkttypen geregelt, genauer Selbstauskunft v2 und ff.>

7 Änderungen in gemKPT_Betr

Folgende Anpassungen sollen dokumentenweit redaktionell umgesetzt werden, analog gemSpec_Perf: Ablösung von "Rohdaten-Performance-Berichte" zum Wording des entsprechenden Datenliefermodells Ablösung von "Performance-Messwerte" zum Wording des entsprechenden Datenliefermodells

< Im Kapitel "4.3 Reporting" werden eine Anforderung und ein Textbaustein in die gemRL_Betr_TI umgezogen >

7.1 Kapitel 4.3 Reporting

...

< Anforderung A_24800 wird nach gemRL_Betr_TI, Kapitel 9.2.3 verschoben >

< Text wird nach gemRL_Betr_TI, Kapitel 9.2.3 verschoben >

Die Auskunft über die Servicebedarfe der Nutzer (z. B. Versicherte) soll, über die Informationen des ITSM hinaus, Erkenntnisse liefern, welche Probleme/Herausforderungen Nutzer im Umgang mit dem Produkt/Service haben und welche Maßnahmen zu deren Bewältigung getroffen wurden. Die Erkenntnisse fließen auf diesem Wege auch zum Produktdesign zurück und in die Produktweiterentwicklung ein. Für die Krankenkassen leitet sich daraus keine Berichtspflicht in Richtung der von ihnen beauftragten Dienstleister ab. Der TI-ITSM-Teilnehmer berichtet über das Serviceaufkommen, das ihm bekannt ist.