ML-158622 - PoPP-Service - Einführung (Betrieb)

[<=]

A_18176 - Mitwirkungspflichten bei der Einrichtung von Probes des Service Monitorings

Alle TI-ITSM-Teilnehmer, welche gemäß [gemKPT_Betr#Tab_KPT_Betr – Mitwirkungspflichten der TI-ITSM-Teilnehmer] die Servicekomponente Service Monitoring unterstützen, MÜSSEN den Anbieter Service Monitoring bei der Einrichtung bzw. Änderung und Inbetriebnahme von Probes gemäß [gemSpec_ServiceMon#5.4 ff.] unterstützen. [<=]

TIP1-A_7266 - Mitwirkungspflichten im TI-ITSM-System

Alle TI-ITSM-Teilnehmer MÜSSEN die Mitwirkungspflichten nach Tabelle Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer befolgen.

TIP1-A_7261 - Erreichbarkeit der TI-ITSM-Teilnehmer untereinander

Alle TI-ITSM-Teilnehmer MÜSSEN untereinander uneingeschränkt elektronisch erreichbar sein, aufgeteilt in Haupt- und Nebenzeit mit differenzierten Reaktionszeiten. [<=]

TIP1-A_7262 - Haupt- und Nebenzeit der TI-ITSM-Teilnehmer

Alle TI-ITSM-Teilnehmer MÜSSEN untereinander folgende Hauptzeit einhalten:
Mo – Fr 09:00 – 17:00 im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen]. Alle anderen Zeiten gelten als Nebenzeit. [<=]

TIP1-A_6367-02 - Definition eines Business-Servicekatalog der angebotenen TI Services

Anbieter MÜSSEN alle von ihnen angebotenen TI Services und -qualitäten gegenüber den Anwendern und anderen Anbietern in einem Business-Servicekatalog dokumentieren und diese Dokumentation der gematik vorlegen. [<=]

TIP1-A_6359-02 - Definition der notwendigen Leistung anderer Anbieter durch Anbieter

Definition der notwendigen Leistung anderer Anbieter durch Anbieter MÜSSEN sicherstellen, dass alle zu ihrer Serviceerbringung notwendigen Leistungen anderer Anbieter im Sinne eines Servicekataloges der unterstützenden Services definiert sind. [<=]

TIP1-A_6360-02 - Kontrolle bereitgestellter Leistungen durch Anbieter

Anbieter MÜSSEN die von anderen beteiligten Anbietern an sie bereitgestellten Leistungen bezüglich deren Eignung im Betrieb kontrollieren und Optimierungsbedarf der gematik mitteilen.
[<=]

TIP1-A_6388-02 - Bereitstellung eines lokalen IT-Service-Managements durch Anbieter für ihre zu verantwortenden Servicekomponenten

Anbieter MÜSSEN für die von ihnen verantworteten Servicekomponenten ein lokales ITSM etablieren. [<=]

TIP1-A_6390-02 - Mitwirkung im TI-ITSM durch Anbieter

Anbieter MÜSSEN die in den Richtlinien zum Betrieb der TI [gemRL_Betr_TI] geforderten Anbieter-Schnittstellen bereitstellen und ihren Mitwirkungspflichten gegenüber der gematik und den anderen Teilnehmern nachkommen.
[<=]

TIP1-A_6389-02 - Erreichbarkeit der 1st-Level (UHD), 2nd-Level (SPOCs) der Anbieter

Anbieter MÜSSEN sicherstellen, dass ihre verantworteten UHDs bzw. SPOCs
    innerhalb der vereinbarten Servicezeiten elektronisch und telefonisch
    außerhalb der vereinbarten Servicezeiten elektronisch
erreichbar sind. [<=]

TIP1-A_6393-02 - Verantwortung für die Weiterleitung von Anfragen

Anbieter MÜSSEN von ihnen nicht lösbare Anwenderanfragen/Störungsmeldungen an den lösungsverantwortlichen Anbieter delegieren oder begründet ablehnen. [<=]

TIP1-A_6377-02 - Koordination von produktverantwortlichen Anbietern und Herstellern

Anbieter MÜSSEN im Rahmen der Service- und Supporterbringung die erforderlichen Leistungen von produktverantwortlichen Anbietern, Herstellern und Drittanbietern integrieren und koordinieren. [<=]

TIP1-A_6415-02 - Fortgeführte Wahrnehmung der Serviceverantwortung bei der Delegation von Aufgaben

Anbieter MÜSSEN bei der Delegation von Aufgaben an durch sie beauftragte Anbieter, Hersteller oder Drittanbieter weiterhin ihre Serviceverantwortung gegenüber ihren Servicenehmern und der gematik wahrnehmen. [<=]

A_24981 - Auskunftsfähigkeit bei Verdacht einer Servicebeeinträchtigung im Verantwortungsbereich

Der TI-ITSM-Teilnehmer MUSS unverzüglich jedoch spätestens 10 Minuten nach expliziter Aufforderung durch den Gesamtverantwortlichen TI eine erste Einschätzung abgeben können, ob der von ihm verantwortete Service bzw. das in seiner Verantwortung liegende Produkt aktuell einer oder keiner Servicebeeinträchtigung unterliegt. [<=]

TIP1-A_6371-02 - 2nd-Level-Support: Single Point of Contact (SPOC) für Anbieter

Jeder Anbieter MUSS für die an der TI teilnehmenden anderen Anbieter einen Single Point of Contact (SPOC) benennen, über den sein 2nd-Level-Support erreichbar ist. [<=]

A_18240 - Reporting der technischen Service Level

TI-ITSM-Teilnehmer, welche gemäß [gemSpec_Perf] technische Performance-Kenngrößen erfassen und liefern, MÜSSEN die Werte der Service Level Performance-Kenngrößen gemäß [gemRL_Betr_TI#GS-A_4100, GS-A_4101 und GS-A_5604] einmal im Monat - spätestens zum 13. Werktag des auf den Bewertungszeitraum folgenden Monats - vollständig sowie sachlich und inhaltlich korrekt bereitstellen. Der Bewertungszeitraum umfasst einen vollen Kalendermonat. [<=]

A_23551 - Eigenmonitoring

Der Anbieter MUSS ein Eigenmonitoring etablieren und in seiner Zuständigkeit betreiben.
Das Eigenmonitoring MUSS mindestens alle Anwendungsfälle erfassen und die auf Protokollebene gelieferten Error Codes beinhalten.

Erläuterung:
Unter "Eigenmonitoring" wird die systematische Beobachtung des Systems des Anbieters durch den Anbieter selbst verstanden. Dabei ist für diese Beobachtung und Analyse mindestens der Datenumfang zu berücksichtigen, welcher der Betriebsdatenlieferung zugrunde liegt. In diesem Zusammenhang sind mindestens die in gemSpec_Perf für die Betriebsdatenlieferung festgelegten Anwendungsfälle und Schnittstellenoperationen zu berücksichtigen. Das Eigenmonitoring soll den Anbieter dazu befähigen, dass er umgehend und selbstständig auf Fehler und unübliches Systemverhalten aufmerksam wird und dementsprechende Gegenmaßnahmen und die Kommunikation der Beobachtung einleiten kann. [<=]

A_23552 - Verhalten bei Auffälligkeiten oder Anomalien

Der Anbieter MUSS Auffälligkeiten und Anomalien im Verhalten seines Systems erkennen und entsprechende, an die Beobachtung angepasste Maßnahmen einleiten und darüber hinaus mit dem Gesamtverantwortlichen für die TI (GTI) in die Kommunikation treten.

Hinweis:
Auffälligkeiten und Anomalien können vielschichtig auftreten und sind vorab nicht exakt definierbar. Im Allgemeinen sprechen wir dann von Anomalien/Auffälligkeiten, wenn das Systemverhalten selbst (bspw. plötzlicher Anstieg der Fehlerraten) oder das Verhalten der Systemumgebung (bspw. ungewöhnlich hohes Anfrageaufkommen) vom üblichen Maß deutlich abweichen. Eine als relevant geltende Abweichung kann nicht definiert werden, da dies stark vom System selbst, der Volatilität des Systemumfeldes und weiterer Faktoren abhängt. Das "übliche Maß" ist dabei ein Wert, der sich aus der Extrapolation von Vergangenheitswerten ergibt und welcher im Zeitverlauf an Stabilität gewinnen wird.
Die betrieblichen Rahmenbedingungen (Wartungsfenster beantragen, Prioritätsbewertung, Störungsmeldungen ...) bleiben hiervon unberührt. [<=]

TIP1-A_6437-01 - Performance - Datenlieferungen - Aufbewahrungsfrist

Der Anbieter MUSS Datenlieferungen an die gematik mindestens 6 Monate lang aufbewahren. 

TIP1-A_7265-04 - Serviceleistung der TI-ITSM-Teilnehmer im TI-ITSM-Teilnehmersupport zur Haupt- und Nebenzeit

TI-ITSM-Teilnehmer mit Mitwirkungsverpflichtung zur Haupt- und Nebenzeit gemäß
Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer 
MÜSSEN die folgenden Service Level (Zeiten) einhalten:

Tabelle 6: Tab_KPT_Betr_TI_052 Service Level (Zeiten) im TI-ITSM

A_23664 - Service Level - Kein Incident der Priorität 1 innerhalb 24 Stunden resultierend aus einem genehmigten Change

Der TI-ITSM-Teilnehmer, der einen Change umsetzt, DARF NICHT innerhalb von 24 Stunden einen Incident der Priorität 1 zum von ihm verantworteten CI auslösen.
Grundlage für das Zeitintervall von 24 Stunden ist die Zeitspanne zwischen Ende des definierten Wartungsfensters und dem Beginn eines Incidents mit Priorität 1 (das jeweilige CI betreffend). [<=]

A_23665-01 - Service Level - Störungsfreie Kommunikationsbeziehungen ohne resultierenden Incident

TI-ITSM-Teilnehmer MÜSSEN zur Aufrechterhaltung der technischen Kommunikationsbeziehung alle notwendigen Handlungen so rechtzeitig und fehlerfrei durchführen, dass keine Störung (Incident der Priorität 1 bis 4) auf die fehlenden notwendigen Handlungen zurückzuführen ist.
[<=]

A_20218-01 - Versionierung der Konfiguration von Produktinstanzen

TI-ITSM-Teilnehmer  MÜSSEN ihre Konfigurationsdaten anhand einer eindeutigen Versionsbezeichnung nachvollziehbar referenzieren, sodass jederzeit eine detailliere Auskunft über die exakte Konfiguration möglich ist.
[<=]

A_20219-01 - Versionierung bei Veränderungen der Konfiguration von Produktinstanzen

TI-ITSM-Teilnehmer  MÜSSEN ihre Konfigurationsdaten anhand einer eindeutigen Versionsbezeichnung bei Veränderungen nachvollziehbar, inklusive Historiendarstellung, referenzieren, sodass jederzeit eine detailliere Auskunft über die exakte Konfiguration möglich ist. [<=]

A_20220 - Festlegung von Konfiguration durch die gematik

TI-ITSM-Teilnehmer  MÜSSEN aufgrund einer Anforderung der gematik bestimmte Werte in ihre Konfiguration aufnehmen. [<=]

A_20221-01 - Rückspielbarkeit bei Veränderungen der Konfiguration von Produktinstanzen

TI-ITSM-Teilnehmer  MÜSSEN bei der Durchführung eines Changes die Konfigurationen ihrer zu ändernden Produktinstanzen versionieren und rückspielbar ablegen sowie auf Anfrage des GTI jederzeit eine detaillierte Auskunft über die verwendete Konfiguration bereitstellen. [<=]

A_23347-01 - Performance - Wartungsfenster - Durchführung

Der Anbieter SOLL Wartungsfenster so planen, dass diese vollständig in der Nebenzeit liegen.
Hinweis: Nach voriger Absprache mit und Genehmigung durch den Gesamtverantwortlichen TI ist ein Wartungsfenster in der Hauptzeit möglich.

Ist für einen Anbieter und einem seiner zugeordneten Produkt(e) nur eine Hauptzeit und keine Nebenzeit definiert, dann SOLL der Anbieter ein Wartungsfenster so planen, dass dieses in Zeiten mit wenig Systemlast stattfindet. Das Wartungsfenster muss mit dem Gesamtverantwortlichen TI abgesprochen und durch diesen genehmigt werden. [<=]

A_23349 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Sonntag

Der Produkttyp MUSS folgende Servicezeiten gewährleisten: 

• Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr
• Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.

A_24962 - Performance - Servicezeiten des Anbieters basierend auf Produkttypen

Der Anbieter MUSS gemäß der in [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] aufgeführten Servicekomponenten bzw. der Zuordnung von Produkttypen zu serviceverantwortlichen Anbieter die dem entsprechenden Produkttypen zugeordneten Servicezeiten erfüllen. [<=]

A_23618-01 - Performance - Wartungsfenster und Ausfall - Verfügbarkeitsberechnung

Der Anbieter MUSS jeden Ausfallzeitraum, inklusive Wartungen, in der Verfügbarkeitsberechnung als Ausfall werten. [<=]

A_26151-01 - Redundanz - Lokale Redundanz

Der Anbieter MUSS sicherstellen, dass bei Ausfall eines funktionalen Elements die Gesamtverfügbarkeit gemäß der definierten Performancevorgaben in [gemSpec_Perf] weiterhin gegeben ist.
Das Ziel der Maßnahme ist, dass lokale Beeinträchtigungen nicht zu einem Ausfall oder verminderter Leistungsfähigkeit des angebotenen Dienstes führen.

Hinweis: Dazu nutzt der Anbieter beispielsweise die Verteilung der eingesetzten Instanzen auf verschiedene Abschnitte eines Standorts. [<=]

A_26152 - Redundanz - Standortübergreifende Redundanz

Der Anbieter MUSS sicherstellen, dass bei Ausfall eines funktionalen Elements oder einer übergreifenden Störung an einem Standort die Gesamtverfügbarkeit gemäß der definierten Performancevorgaben in [gemSpec_Perf] weiterhin gegeben ist.
Dazu nutzt der Anbieter einen zweiten Standort, welcher in der Lage ist, die geforderten Anforderungen gemäß [gemSpec_Perf] eigenständig zu gewährleisten. Es soll dadurch das Risiko ausgeschlossen oder vermindert werden, dass übergreifende Beeinträchtigungen eines Standortes zu einem Ausfall oder verminderter Leistungskapazität führen. [<=]

A_26186 - Redundanz - Wiederherstellungszeitraum - 5 Tage

Der Anbieter MUSS sicherstellen, dass bei einer Störung (die nicht über Maßnahmen gemäß [gemRL_Betr_TI#A_26014-*] verhindert wurden), das betroffene System und seine Daten innerhalb von fünf Arbeitstagen vollständig wiederhergestellt werden. Die Maßnahmen zur Wiederherstellung MÜSSEN unter Berücksichtigung der geltenden Sicherheitsanforderungen vorgenommen werden. [<=]

A_22057 - Performance - Betriebsdatenlieferung - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Betriebsdaten gemäß der allgemeinen und spezifischen Anforderungen gewährleisten. [<=]

A_22482-01 - Performance - Betriebsdatenlieferung - Erfassung von Betriebsdaten

Der Produkttyp MUSS Betriebsdaten gemäß der Vorgaben an der Außenschnittstelle erfassen.

Hinweis: Der Begriff Außenschnittstelle ist im Kapitel 1.1 Bearbeitungszeit definiert.
[<=]

A_22002 - Performance - Betriebsdatenlieferung v2 - Übermittlung

Der Produkttyp MUSS zur Übertragung der Betriebsdatenlieferung die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.
Die Übermittlung der Betriebsdatenlieferung MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen.  [<=]

A_22047 - Performance - Betriebsdatenlieferung v2 - Änderung der Konfiguration der Lieferintervalle

Der Produkttyp MUSS eine Anpassung der Lieferintervalle von Betriebsdatenlieferungen ermöglichen. [<=]

A_21981-02 - Performance - Betriebsdatenlieferung v2 - Format

Der Produkttyp MUSS bei der Erstellung der Datenlieferung folgende Konventionen umsetzen:
Die Datei:

• MUSS ein CSV-Format mit den Feldern

• MUSS das Semikolon ";" als Feldtrennzeichen verwenden.
• DARF das Feldtrennzeichen innerhalb der CSV-Felder NICHT inhaltlich verwenden.
• DARF Feldinhalte NICHT quotieren.
• DARF Feldinhalte weggelassen, sofern diese Produkttyp- oder operationsbedingt entfallen können, was ggf. zu direkt aufeinanderfolgenden Semikola führt.
• MUSS UTF-8 Zeichensatzkodierung ohne ByteOrderMark verwenden.
• MUSS CR-LF-Zeilenumbrüche (ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed)) verwenden.
• DARF Kommentierungen NICHT verwenden.
• DARF leeren Zeilen NICHT verwenden.
• DARF Tausendertrennzeichen NICHT verwenden.
• DARF einen CSV-Header NICHT verwenden.
• MUSS Leerzeichen am Rand der Feldinhalte entfernen, sofern diese nicht intendiert sind.

A_21975-01 - Performance - Betriebsdatenlieferung v2 - Default-Wert des Lieferintervalls

Der Produkttyp MUSS den Lieferintervall von 5 Minuten als Standardeinstellung nutzen. [<=]

A_22001-02 - Performance - Betriebsdatenlieferung v2 - Dateiname der Lieferung

Der Produkttyp MUSS für die Übermittlung der Datei zur Betriebsdatenlieferung beim Dateinamen folgende Konventionen umsetzen:
<CI-ID>_<Start>_<Ende>_perf.log

• <CI-ID> = identifiziert die Produktinstanz, gemäß [A_17764] in [gemRL_Betr_TI].
  
• <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC).
  
• <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten)

A_21979 - Performance - Betriebsdatenlieferung v2 - Bezug der Lieferverpflichtung

Der Produkttyp MUSS sich bei der Betriebsdatenlieferung ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]

A_22996 - Performance - Betriebsdatenlieferung v2 - Zeitpunkte der Übermittlungen

Der Anbieter MUSS jede Lieferung der Betriebsdaten unverzüglich - spätestens innerhalb der 10 auf das Lieferintervall folgenden Minuten - beginnen. [<=]

A_22620 - Performance - Betriebsdatenlieferung v2 - Umsetzungszeit für Änderung der Lieferintervalle

Der Anbieter MUSS die Anpassung der Lieferintervalle gemäß [A_22047] innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_22500-01 - Performance - Betriebsdatenlieferung v2 - Status-Block

Der Produkttyp MUSS im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard_Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.

Tabelle 13: Tab_gemSpec_Perf_Standard_Statuscodes

A_22003-01 - Performance - Betriebsdatenlieferung v2 - Nachlieferung auf Anforderung

Der Anbieter MUSS auf Anforderung der gematik eine Nachlieferung der Betriebsdaten bis zum 5. Werktag (ausgenommen bundeseinheitliche Feiertage) des auf dem Lieferzeitraum folgenden Monats ermöglichen. [<=]

A_22513-02 - Performance - Betriebsdatenlieferung v2 - Message-Block im Fehlerfall

Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln oder das gesamte Key-Value-Paar entfernen, sofern die - im Fehlerfall oder aus einem anderen Grund - für die Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) notwendigen Informationen nicht vorliegen. [<=]

A_21982-01 - Performance - Betriebsdatenlieferung v2 - Message-Block

Der Produkttyp MUSS bei der Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]

A_21980-01 - Performance - Betriebsdatenlieferung v2 - Leerlieferung

Der Produkttyp MUSS die Lieferung gemäß des konfigurierten Lieferintervalls gewährleisten, auch wenn im dazugehörigen Lieferintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist die Datei zur Betriebsdatenlieferung mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. [<=]

A_22004 - Performance - Betriebsdatenlieferung v2 - Korrektheit

Der Produkttyp MUSS die Lieferung vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden.  [<=]

A_21976 - Performance - Betriebsdatenlieferung v2 - Konfigurierbarkeit der Lieferintervalle

Der Produkttyp MUSS die Lieferintervalle der Berichtsdateien flexibel zwischen 1 Minute und 24 Stunden (1440 Minuten) mit einer Taktung von 1 Minute konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_22005 - Performance - Betriebsdatenlieferung v2 - Frist für Nachlieferung

Der Produkttyp MUSS, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei(en) in der geforderten Qualität bis zum Ende des folgenden Werktages (Mo-Fr ausgenommen bundeseinheitliche Feiertage) nachliefern. [<=]

A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls

Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß [A_26177*]) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_26177 - Performance - Selbstauskunft - Konfigurierbarkeit des Lieferintervalls

Der Produkttyp MUSS die Lieferintervalle der Selbstauskunft flexibel zwischen 1 Minute und 1440 Minuten (24 Stunden) konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_26176 - Performance - Selbstauskunft - Lieferintervall

Der Produkttyp MUSS die Selbstauskunft in einem konfigurierbaren Lieferintervall senden. Sofern nicht explizit anders spezifiziert, ist das Lieferintervall von 60 Minuten als Default-Wert zu nutzen. [<=]

A_26175 - Performance - Selbstauskunft - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Daten zur Selbstauskunft gewährleisten. [<=]

A_26174 - Performance - Selbstauskunft - Verpflichtung zur Erfassung

Der Produkttyp MUSS notwendige Metadaten für die Lieferung einer Selbstauskunft erfassen und verarbeiten. [<=]

A_26181 - Performance - Selbstauskunft v2 - Format und Übermittlung

Der Produkttyp MUSS notwendige Metadaten für die Selbstauskunft im JSON-Format gemäß A_26180 erfassen, verarbeiten und an die Schnittstelle I_OpsData_Update der Betriebsdatenerfassung gemäß [gemSpec_SST_LD_BD] versenden. [<=]

A_26180 - Performance - Selbstauskunft v2 - Grundgerüst

Der Produkttyp MUSS folgende Werte als Grundgerüst für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

A_27271 - Performance - Selbstauskunft v2 - Schemaversion 1

Der Produkttyp MUSS folgende Werte für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

A_27495 - Performance - PoPP-Service - Datenlieferung an ZETA-Guard

Der Anbieter PoPP-Service MUSS folgende Daten an die OpenTelemetry-Schnittstelle des Telemetrie-Daten-Service vom ZETA-Guard gemäß [Kapitel 5.7 Telemetrie-Daten Service#gemSpec_ZETA] senden. Alternativ ist es möglich, die Datenlieferung von einer Adapterkomponente des Anbieters, außerhalb des PoPP-Service, an die Schnittstelle des ZETA-Guard zu gewährleisten.

• Daten zu jedem Schnittstellenaufruf (transaktionales Schema):
• Den Wert "proofMethod", Datentyp Sring: Wert von proofMethod aus dem PoPP-Token gem. [A_26431*].
  
• Den Wert "resourceServerDuration", Datentyp Integer: gemäß der Vorgaben von [A_27477*].
  
• Den Wert "backendduration", Datentyp Integer: gemäß der Vorgaben von [A_27477*].
• Den Wert "cardCheckTime", Datentyp Integer: gemäß der Vorgaben von [A_27477*].
• Daten zum Zustand des eingesetzten Produkts (zustandsbasiertes Schema gemäß [A_27494*#gemSpec_ZETA]):
• Die Version des zugelassenen Produkttyps (Produkttypversion).
• Die Version des Resource-Servers (Produktversion).
• Die Version der Konfiguration gemäß [A_20219*] (Konfigurationsversion).

A_27494 - Telemetrie-Daten Service, Custom Collector für Selbstauskunft

Der Telemetrie-Daten Service MUSS einen Custom Collector für die Selbstauskunft des Resource Servers implementieren.
Die Selbstauskunft des Resource Servers erfolgt für jede eigenständige Instanz.
Die OTLP Metrik ist wie folgt definiert:
Name: product_info
Typ: Gauge (zeigt den aktuellen Zustand)
Labels/Attributes:

• product.name – Name des Produkts
• product.version – Aktuelle Produktversion
• producttype.version – Version des Produkt-Typs
• configuration.version – Konfigurationsversion
• pod.name – Name des Pods/der Instanz des Resource Servers
• timestamp – Zeitpunkt der letzten Änderung

A_27473 - Performance - PoPP-Service - Messung von Bearbeitungszeiten

Der PoPP-Service MUSS alle Zeiten zu einem Request/Response-Paar aufzeichnen und verarbeiten. Unterzeiträume werden gleichzeitig gesondert gemessen und verarbeitet.

Rahmenbedingungen:
Die Zeit (in ms) vom vollständigen Eingang eines Requests an der Außenschnittstelle bis hin zum Start des Versands einer Antwortnachricht (Response) an derselben ist die Gesamtbearbeitungszeit.
Die Gesamtbearbeitungszeit unterteilt sich ggf. in Unterzeiträume, die gesondert gemessen und ausgewertet werden (z.B. gemäß [A_27477*] und [A_27030*]).

Die vom PoPP-Service zu verantwortende Bearbeitungszeit umfasst alle Zeiten, die der PoPP-Service zur Bearbeitung des Requests selbstständig aufwendet. Die vom PoPP-Service zu verantwortende Bearbeitungszeit erfasst NICHT die Zeiten, die den Abruf an Drittsysteme (z.B. an OCSP) betreffen. [<=]

A_27477 - Performance - PoPP-Service - Bearbeitungszeiten für Unterzeiträume

Der PoPP-Service MUSS zu folgenden Zeiträumen eigene Unterzeiträume selbstständig erfassen, verarbeiten und im Rahmen des Monitorings weiterleiten.

• Backend-Duration: Zeit in ms für Anfragen an TI-Komponenten und Systeme außerhalb des PoPP-Service, z.B. OCSP.
• ResourceServer-Duration: Zeit in ms bei jedem Aufruf des Resource Servers ab Erhalt des Requests vom ZeTA-Guard bis zum vollständigen Versand der Antwort an den ZeTA-Guard.
• cardCheckTime: Zeit in ms bei jedem Aufruf mit Validierung einer eGK ab Start der APDU-Kommandos bis zum Abschluss der Bearbeitung der APDU-Kommandos.

A_27030 - Performance - PoPP-Service - Bearbeitungszeit unter Last

Der PoPP-Service MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" erfüllen.

Tabelle 14: Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben

A_26332 - Performance - PoPP-Service - Verfügbarkeit

Der Anbieter PoPP-Service MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit: 99,99%
• Nebenzeit: 99,97%

A_26335 - Performance - PoPP-Service - Skalierung

Der Anbieter PoPP-Service MUSS die Skalierbarkeit des angebotenen Dienstes im laufenden Betrieb jederzeit gewährleisten und der gematik nachvollziehbar darstellen. Dazu dokumentiert er das eingesetzte Skalierungskonzept im Betriebshandbuch.

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

A_26336 - Performance - PoPP-Service - Robustheit gegenüber Lastspitzen

Der PoPP-Service MUSS auch bei Lastspitzen oberhalb der definierten Spitzenlasten gemäß der Tabelle "Tab_gemSpec_Perf_PoPP_Service: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben.
[<=]

A_27316 - Performance - Betriebsdatenlieferung v2 - Spezifika PoPP-Service - Status

Der PoPP-Service MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "status" vorrangig den Fehlercode aus der Spalte "Errorcode" gemäß [A_27317] verwenden. In allen anderen Fällen ist der gültige, an den Client zurückgemeldete, HTTP-Response Code in das Feld einzutragen. [<=]

A_27049 - PoPP-Service, Mapping von Smartcard Fehlercodes

Der PoPP-Service MUSS interne Fehlermeldungen während des eGK-Handling auf folgende an Außenschnittstellen sichtbare Fehlermeldungen abbilden:

Tabelle 15: Fehlermeldungen eGK-Handling

A_27317 - PoPP-Service - interne Fehlercodes

Der PoPP-Service MUSS folgende interne Fehlercodes verwenden:

Tabelle 16: Tab_PoPP_Service_interne_Fehlercodes

A_26333 - Performance - Betriebsdatenlieferung v2 - Spezifika PoPP-Service - Operation

Der PoPP-Service MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "operation" die Angabe der Spalte "UseCase" aus Tabelle [Tab_gemSpec_Perf_PoPP_Service: Performancerelevante UseCases] nutzen.

A_27381 - Performance - Betriebsdatenlieferung v2 - Spezifika PoPP-Service - Konfigurierbarkeit der Lieferung

Der PoPP-Service MUSS bei Betriebsdatenlieferungen das an- und abschalten von gelieferten Operationen gemäß [A_26333] konfigurativ ermöglichen. Standardmäßig ist die Lieferung aller definierten Operationen angeschaltet.

Hinweis: Die Änderung dieser Konfiguration darf nur auf betriebliche Anordnung der gematik vorgenommen werden. [<=]

A_26334 - Performance - Betriebsdatenlieferung v2- Spezifika PoPP-Service - Duration

Der PoPP-Service MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem Beginn des Versands der Antwortnachricht.

Hinweis: Anfragen an andere Produkte der TI (z.B. OCSP) oder zu speziellen Verfahrenszeiten sind als Unterzeitraum gem. [A_27473] getrennt zu erfassen und dürfen aus der duration_in_ms nicht herausgerechnet werden. [<=]

A_26532 - Performance - Betriebsdatenlieferung v2 - Spezifika PoPP-Service - Message

Der PoPP-Service MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen:

{ "cid": "$clientid", "cv": "$clientversion", "size": $size, "bkdur": $backendduration, "cct": $cardCheckTime, "rsdur": $resourceServerDuration, "ikn": $iknummer, "pmth": "$proofmethod" }

• $clientid: <product_id> gemäß Token Self-Assessment des Clientsystems, Datentyp String
• $clientversion: <product_version> gemäß Token Self-Assessment des Clientsystems, Datentyp String
• $size: Größe des Requests in kilobyte, Datentyp Integer
• $backendduration: Zeit in ms für Abfragen an Drittsystemen (z.B. OCSP), Datentyp Integer
• $resourceServerDuration: Zeit in ms für die Bearbeitungszeit im Resource-Server, Datentyp Integer 
• $cardCheckTime: Zeit in ms für die Echtheitsprüfung der eGK mittels APDU-Kommandos gem. [Kapitel 6.2.1 "eGK Handling"#gemSpec_PoPP_Service], Datentyp Integer
• $iknummer: Wert von insurerId des PoPP-Token gem. [A_26431*], Datentyp Integer
• $proofmethod: Wert von proofMethod aus dem PoPP-Token gem. [A_26431*], Datentyp String.

A_27320 - Performance - Bestandsdaten - Spezifika PoPP-Service

Der Anbieter PoPP-Service MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Informationen berichten:

• Anzahl der vorhandenen eGK Hashes in der eGK-Hash-Datenbank, gemäß [A_27046].

A_27319 - Performance - Bestandsdaten - Spezifika PoPP-Service - Format

Der Anbieter PoPP-Service MUSS jeweils zum Wechsel in den nächsten Berichtsintervall, folgende Informationen im JSON-Format als HTTP Body an die Betriebsdatenerfassung gemäß [A_23110-*] liefern.

{ 
"timestamp": "<Zeitstempel der Abfrage gemäß ISO 8601 unter expliziter Angabe der Zeitzone UTC im konkreten Format: YYYY-MM-DDTHH:mm:ss[.fff]Z, als String>",
"ci": "<CI-ID der abgefragten Produktinstanz gemäß [A_17764], als String>",
"egkhashcount": <Anzahl der gespeicherten Hashwerte in der eGK-Hash-Datenbank gemäß [A_27046], als Integer>
} [<=]

GS-A_4090 - Kommunikation - Kommunikationssprache

Alle TI-ITSM-Teilnehmer MÜSSEN sowohl schriftlich als auch mündlich in deutscher Sprache kommunizieren. Dies gilt insbesondere für die gemäß [GS-A_4085] festgelegten Kommunikationsschnittstellen und für alle Dokumentationen.
[<=]

GS-A_3886-01 - Kommunikation - Nutzung des TI-ITSM-Systems bei der Übermittlung eines übergreifenden Vorgangs

Alle TI-ITSM-Teilnehmer MÜSSEN alle übergreifenden Vorgänge, zwecks Informationsübermittlung, im TI-ITSM-System erfassen.
[<=]

GS-A_4085 - Kommunikation - Etablierung von Kommunikationsschnittstellen durch die TI-ITSM-Teilnehmer

Alle TI-ITSM-Teilnehmer MÜSSEN im Rahmen der übergreifenden Betriebsprozesse mindestens die nachfolgenden Kommunikationsschnittstellen etablieren:

• Telefon (bspw. zur Rücksprache zu einem TI-ITSM-Vorgang);
  
• E-Mail (bspw. zur Übermittlung von Ad-hoc-Reports);
  
• TI-ITSM-System zur Informationsübermittlung eines übergreifenden Vorgangs entsprechend [GS-A_3886-*].

GS-A_4088-01 - Benennung von Ansprechpartnern

TI-ITSM-Teilnehmer MÜSSEN Kontaktdaten von Ansprechpartnern im TI-ITSM-System eintragen und aktuell halten für

• die Rolle Service Delivery Manager (agiert auch als 1. Eskalationsstufe),
• die 2. Eskalationsstufe,
• für alle für den TI-ITSM-Teilnehmer relevanten Prozesse gemäß Tabelle gemKPT_Betr#Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM
• das Notfall-Management,
• die Unternehmenskommunikation (u.a. Krisenkommunikation).
• die Informationssicherheit,
• den Datenschutz, 
• vertragliche und kaufmännische Fragestellungen.

GS-A_4086 - Kommunikation - Erreichbarkeit der Kommunikationsschnittstellen

Alle TI-ITSM-Teilnehmer MÜSSEN die Kommunikationsschnittstellen während der festgelegten Servicezeiten erreichbar halten und einer regelmäßigen Eingangsprüfung und Bearbeitung unterziehen.
[<=]

GS-A_5402 - Kommunikation - Eigenverantwortliches Handeln bei Ausfall von Kommunikationsschnittstellen

Bei Ausfall des TI-ITSM-Systems oder anderer Kommunikationsschnittstellen MUSS die Kommunikation durch die TI-ITSM-Teilnehmer eigenverantwortlich untereinander sichergestellt werden. Vorgänge müssen im TI-ITSM-System nachdokumentiert werden.
[<=]

GS-A_5401-01 - Kommunikation - Verschlüsselte E-Mail-Kommunikation

Der Informationsaustausch per E-Mail zwischen allen TI-ITSM-Teilnehmern MUSS verschlüsselt nach dem Stand der Technik erfolgen. [<=]

GS-A_5343-01 - Betriebshandbuch - Definition inhaltlicher Auszüge aus dem Betriebshandbuch

Die Auszüge aus dem Betriebshandbuch des TI-ITSM-Teilnehmers MÜSSEN nachfolgende Themen beinhalten:

1. Einführung
   

• Betriebliche Rolle und Identifikation
  
• Version
  
• Freigabe- und Prüfungsverantwortung
  
• Ergänzende Dokumente soweit vorhanden
  
• Dokumentenstand-Basis
  

1. Systemüberblick
   

• Architektur
  
• System
  
• Komponenten
• Außenschnittstelle des Produkttypen

1. Aufnahme, Unterbrechung und Beendigung des Betriebes
   

• Initiale Aufnahme des Betriebs (insbesondere Reihenfolge, Rahmenbedingungen)
  
• (kontrollierte) Unterbrechung des Betriebs (Übergang in den Notbetrieb)
  
• Wiederaufnahme des Normalbetriebs (Wiederherstellung des Normalbetriebs)
  
• Beendigung des Betriebs (insbesondere Reihenfolge der Abschaltung, Aufräumarbeiten)

1. Darstellung des lokalen ITSM (vor- und nachgelagerte Prozesse im Verhältnis zu den übergreifenden ITSM-Prozessen)

• Insbesondere sind hier die in diesen Richtlinien beschriebenen ITSM-Prozesse in den internen Prozessabläufen des Anbieters kompakt darzustellen.
  
• Alle weiteren internen ITSM-Prozesse des Anbieters sind aufzulisten und kurz zu beschreiben soweit diese für die Prozesse gemäß diesen Richtlinien begleitend erforderlich sind.
  
• Das Ziel der Darstellung ist die korrekte Verzahnung zwischen dem lokalen ITSM und den übergreifenden ITSM-Prozessen.
  

1. Integration des lokalen ITSM in das übergreifende ITSM der TI (übergreifende Prozesse)

• Die Bedienung der in diesen Richtlinien beschriebenen TI-ITSM-Prozesse durch den Anbieter ist ausführlich zu beschreiben.
  
• Schnittstellen und Interaktionen zwischen den internen ITSM-Prozessen des Anbieters und übergreifenden TI-ITSM-Prozessen sind zu dokumentieren.
  

1. Relevanter Teil des Servicekataloges
   
2. Nachweis zur Umsetzung der Anforderungen.
   

GS-A_4855-02 - Audit - Auditierung von TI-ITSM-Teilnehmern

TI-ITSM-Teilnehmer MÜSSEN Auditierungen durch Gesamtverantwortlichen TI zur Überprüfung der Einhaltung von Betriebs- und Produktvorgaben ermöglichen und angemessen unterstützen.
Sofern ein TI-ITSM-Teilnehmer bereits gesetzlichen Vorgaben einer Auditierung unterliegt, ihm also eine Prüfung durch eine in der gesetzlichen Vorgabe benannte Instanz vorgeschrieben ist, unterliegt er nicht der Auditierung gemäß dieser Anforderung. Der TI-ITSM-Teilnehmer MUSS die gesetzliche Vorgabe gegenüber dem Gesamtverantwortlichen TI benennen. Fachdienste VSDM, KTR-AdV und KTR-Consumer sind von dieser Anforderung ausgeschlossen.
[<=]

GS-A_3917 - Audit - Bereitstellung der ITSM-Dokumentation bei Audits

TI-ITSM-Teilnehmer MÜSSEN bei der Durchführung von Audits auf Verlangen alle relevanten Informationen (z.B. TI-ITSM relevante Tickets im ITSM-System) im Rahmen der Umsetzung bzw. Erfüllung der betrieblichen Anforderungen bereitstellen. [<=]

GS-A_3920 - Eskalationseinleitung durch den TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer MÜSSEN bei übergreifenden Vorgängen eine hierarchische Eskalation an den Gesamtverantwortlichen TI einleiten, wenn einer der nachfolgenden Aspekte zutrifft:

• es kann kein serviceverantwortlicher TI-ITSM-Teilnehmer (entsprechend [gemKPT_Betr#Tab_KPT_Betr_TI_002]) ermittelt werden
  

• es kann keine Einigung über die Serviceverantwortung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
  

• es kann keine Einigung über die Lösungsunterstützung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
  

• es treten bei der Bewertung oder Durchführung eines Produkt-Changes schwerwiegende Konflikte auf
  

• es ist zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte eine übergeordnete Koordination notwendig.

GS-A_3922 - Koordinierung - Mitwirkung bei Taskforces

TI-ITSM-Teilnehmer MÜSSEN bei Aufforderung durch den Gesamtverantwortlichen TI an einer Taskforce zur Behebung von übergreifenden Vorgängen mit der Priorität 1 oder 2 teilnehmen, der Taskforce gemäß der zeitlichen Vorgabe der Aufforderung beitreten, die Lösungsfindung und die Erstellung des Abschlussberichtes unterstützen.
[<=]

GS-A_3876 - Incident Management - Prüfung auf übergreifenden Incident

TI-ITSM-Teilnehmer MÜSSEN jeden gemeldeten Incident dahingehend prüfen, ob es sich um einen übergreifenden Incident handelt, für den zur Incident-Lösung die serviceverantwortlichen und/oder lösungsunterstützenden TI-ITSM-Teilnehmer und/oder der Gesamtverantwortliche TI herangezogen werden sollen. [<=]

GS-A_5449 - Incident Management - Typisierung eines übergreifenden Incidents als „sicherheitsrelevant“

TI-ITSM-Teilnehmer MÜSSEN einen Vorgang als „sicherheitsrelevant“ markieren, wenn die Vertraulichkeit bzw. Integrität eines schutzbedürftigen Informationsobjektes gefährdet ist.
[<=]

GS-A_5450 - Incident Management - Typisierung eines übergreifenden Incidents als „datenschutzrelevant“

TI-ITSM-Teilnehmer MÜSSEN eine Störung als „datenschutzrelevant“ markieren, wenn personenbezogene Daten gemäß Art. 4 Nr. 1 DSGVO betroffen sind.
[<=]

GS-A_4125 - Incident Management - TI-Notfallerkennung

TI-ITSM-Teilnehmer MÜSSEN potenzielle TI-Notfälle im operativen Betrieb im Rahmen des Incident Managements feststellen. Potenzielle TI-Notfälle werden als Incidents der Priorität 1 mit Kennzeichnung „TI-Notfall“ klassifiziert.
[<=]

GS-A_3884 - Incident Management - Festlegung von Dringlichkeit und Auswirkung von übergreifenden Incidents

TI-ITSM-Teilnehmer MÜSSEN zur Ermittlung der Priorität eines übergreifenden Incidents die beiden Faktoren „Dringlichkeit“ und „Auswirkung“ festlegen.

Tabelle 17: Tab_Betr_TIP_026 INC – Festlegung der Dringlichkeit

Tabelle 18: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung

GS-A_3902 - Incident Management - Prüfung auf Serviceverantwortung

TI-ITSM-Teilnehmer MÜSSEN jeden an sie gerichteten übergreifenden Incident dahingehend prüfen, ob der Incident in der eigenen Serviceverantwortung liegt.
[<=]

GS-A_3904 - Incident Management - Annahme eines übergreifenden Incidents

TI-ITSM-Teilnehmer MÜSSEN einen übergreifenden Incident annehmen, wenn sie die Serviceverantwortung haben.
[<=]

GS-A_3905 - Incident Management - Ablehnung eines übergreifenden Incidents

TI-ITSM-Teilnehmer MÜSSEN die Ablehnung eines übergreifenden Incidents mit einer qualifizierten Rückmeldung an den meldenden TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Bearbeitung erfolgen kann.
[<=]

GS-A_3907 - Incident Management - Lösung von übergreifenden Incidents

Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS nach erfolgter Erstellung bzw. Annahme eines übergreifenden Incidents unverzüglich mit der Incident-Bearbeitung beginnen und – innerhalb der vereinbarten Lösungszeiten – eine Lösung für den Incident herbeiführen und diesen beheben.
[<=]

A_24983 - Incident Management - Erstellung einer Root Cause Analysis im Incident - Prio 1 bis 2

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN bei Incidents der Priorität 1 oder 2 unaufgefordert im Rahmen der vereinbarten organisatorischen Service Level eine Root Cause Analysis erstellen und an den Gesamtverantwortlichen TI fristgerecht übermitteln.
Die notwendigen Informationen werden vom Gesamtverantwortlichen TI bereitgestellt.

Hierbei kann eine erste Draft-Version durch den Gesamtverantwortlichen TI vorab eingefordert werden.
[<=]

A_24984 - Incident Management - Erstellung einer Root Cause Analysis im Incident - Prio 3 bis 4

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN bei Incidents der Priorität 3 oder 4 auf Anfrage des Gesamtverantwortlichen TI im Rahmen der vereinbarten organisatorischen Service Level eine Root Cause Analysis erstellen und an den Gesamtverantwortlichen TI fristgerecht übermitteln.
Die notwendigen Informationen werden vom Gesamtverantwortlichen TI bereitgestellt.

Hierbei kann eine erste Draft-Version durch den Gesamtverantwortlichen TI vorab eingefordert werden.
[<=]

A_18405 - Incident Management - Erstellung einer Root Cause Analysis durch am Incident beteiligte TI-ITSM-Teilnehmer

Am Incident beteiligte TI-ITSM-Teilnehmer MÜSSEN auf Anfrage des Gesamtverantwortlichen der TI mit der Erstellung einer Root Cause Analysis beginnen, dafür das vom Gesamtverantwortlichen der TI bereitgestellte Formular nutzen und anschließend ausgefüllt an ihn übermitteln. [<=]

A_18406 - Incident Management - Nachlieferung zu einer Root Cause Analysis

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN auf Rückfrage des Gesamtverantwortlichen der TI Informationen zur Root Cause Analysis nachreichen. [<=]

GS-A_5587 - Incident Management - Ablehnung der Lösungsunterstützung bei einem übergreifenden Incident

TI-ITSM-Teilnehmer, die die Lösungsunterstützung eines übergreifenden Incidents ablehnen, MÜSSEN dies mit einer qualifizierten Rückmeldung an den anfragenden TI-ITSM-Teilnehmer durchführen, aus der nachvollziehbar zu entnehmen ist, warum keine Lösungsunterstützung möglich ist.
[<=]

GS-A_5400 - Incident Management - Prüfung der Lösung durch den Melder eines übergreifenden Incidents

Der meldende TI-ITSM-Teilnehmer MUSS die ihm vorgelegte Lösung des übergreifenden Incidents prüfen und sein Ergebnis dem serviceverantwortlichen TI-ITSM-Teilnehmer innerhalb der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265-03]) über das TI-ITSM-System mitteilen.
[<=]

GS-A_5250 - Incident Management - Ablehnung der Lösung eines übergreifenden Incidents

Wird die Lösung eines Incidents durch den meldenden TI-ITSM-Teilnehmer abgelehnt MUSS der serviceverantwortliche TI-ITSM-Teilnehmer den übergreifenden Incident erneut bearbeiten, die Messung der Lösungszeit wird dann fortgesetzt.
[<=]

GS-A_3888 - Incident Management - Verifikation vor Schließung eines übergreifenden Incident

TI-ITSM-Teilnehmer MÜSSEN vor der Schließung einer übergreifenden Incident-Dokumentation sicherstellen, dass der Incident behoben ist.
Ist der Incident nicht behoben, dann ist der bestehende Incident weiterzubearbeiten. Es beginnt keine erneute Lösungszeit.
Liegt nach Ablauf der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265-03]) keine Rückmeldung durch den meldenden TI-ITSM-Teilnehmer vor, KANN der übergreifende Incident geschlossen werden.
[<=]

GS-A_3889 - Incident Management - Schließung eines übergreifenden Incidents

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach verifizierter Behebung der Störung die Dokumentation eines übergreifenden Incidents abschließend bearbeiten und diesen Incident schließen.
[<=]

GS-A_3958 - Problem Management - Problemerkennung durch TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer MÜSSEN geeignete Maßnahmen implementieren, um proaktiv und reaktiv eine Problemerkennung zu ermöglichen.
[<=]

GS-A_3959 - Problem Management - Prüfung auf übergreifendes Problem

TI-ITSM-Teilnehmer MÜSSEN jedes erkannte Problem dahingehend prüfen, ob es sich um ein übergreifendes Problem handelt, für das zur Problem-Lösung die serviceverantwortlichen und/oder lösungsunterstützenden TI-ITSM-Teilnehmer sowie der Gesamtverantwortliche TI herangezogen werden sollen.
[<=]

GS-A_3964 - Problem Management - Festlegung von Dringlichkeit und Auswirkung von übergreifenden Problems

TI-ITSM-Teilnehmer MÜSSEN zur Ermittlung der Priorität eines übergreifenden Problems die beiden Faktoren „Dringlichkeit“ und „Auswirkung“ festlegen.

Tabelle 20: Tab_Betr_TIP_102 PRO – Festlegung von Dringlichkeit

Tabelle 21: Tab_Betr_TIP_103 PRO – Festlegung von Auswirkung

GS-A_3975 - Problem Management - Prüfung auf Serviceverantwortung zum übergreifenden Problem

TI-ITSM-Teilnehmer MÜSSEN jedes an sie gerichtete übergreifende Problem dahingehend prüfen, ob das Problem in der eigenen Serviceverantwortung liegt. [<=]

GS-A_3981 - Problem Management - Annahme eines übergreifenden Problems

TI-ITSM-Teilnehmer MÜSSEN das übergreifende Problem annehmen, wenn sie die Serviceverantwortung haben.
[<=]

GS-A_3982 - Problem Management - Ablehnung eines übergreifenden Problems

TI-ITSM-Teilnehmer MÜSSEN das abgelehnte übergreifende Problem mit einer qualifizierten Rückmeldung an den meldenden TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Bearbeitung erfolgen kann.
[<=]

GS-A_3983 - Problem Management - Ursachenanalyse eines übergreifenden Problems durch Serviceverantwortlichen

Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS nach erfolgter Erstellung bzw. Annahme eines übergreifenden Problems unverzüglich mit der Problem-Bearbeitung beginnen und – innerhalb der vereinbarten Lösungszeiten – eine Lösung für das Problem herbeiführen und dieses beheben.
[<=]

GS-A_3986 - Problem Management - Koordination bei übergreifenden Problems

Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS die Koordination zwischen allen erforderlichen Lösungs- bzw. Unterstützungsbeteiligten im Rahmen der Problemlösungsentwicklung übernehmen.
[<=]

GS-A_3987 - Problem Management - Initiierung eines Change Request

Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS während der Problemlösungsentwicklung einen Change Request über das TI-ITSM-System mit Verweis auf das zugrundeliegende Problem initiieren, in dem die Durchführung von Autorisierung, Entwicklung, Test und Implementierung der Lösung dokumentiert wird.
[<=]

GS-A_5377 - Problem Management - Durchführung einer Problemstornierung

Der serviceverantwortliche TI-ITSM-Teilnehmer KANN ein Problem stornieren, falls einer der folgenden Aspekte zutrifft:

• die ursächliche Störung, der bekannte Fehler oder die bekannte Ursache hat sich nachvollziehbar und dokumentiert erledigt;

• das Ticket wurde irrtümlich angelegt.

GS-A_5588 - Problem Management - Abbruch der Problembearbeitung

Der serviceverantwortliche TI-ITSM-Teilnehmer KANN die Problembearbeitung mit Zustimmung des Gesamtverantwortlichen TI abbrechen, falls die Auswirkungen des Problems und der Aufwand zu deren Behebung in keinem wirtschaftlichen oder sicherheitsrelevanten Verhältnis zueinander stehen.
[<=]

GS-A_5589 - Problem Management - Prüfung auf Verantwortung zur Lösungsunterstützung

TI-ITSM-Teilnehmer MÜSSEN jede an sie gerichtete Anfrage zur Lösungsunterstützung eines übergreifenden Problems dahingehend prüfen, ob sie zur Lösungsunterstützung gemäß Betriebskonzept verpflichtet sind.
[<=]

GS-A_3977 - Problem Management - Annahme der Verantwortung zur Lösungsunterstützung

TI-ITSM-Teilnehmer MÜSSEN die Anfrage zur Lösungsunterstützung eines übergreifenden Problems annehmen, wenn sie die gemäß TIP1-A_7266 [gemKPT_Betr] für die Servicekomponenten mitverantwortlich sind.
[<=]

GS-A_3976 - Problem Management - Ablehnung der Lösungsunterstützung

TI-ITSM-Teilnehmer MÜSSEN die Ablehnung der Lösungsunterstützung des übergreifenden Problems mit einer qualifizierten Rückmeldung an den serviceverantwortlichen TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Lösungsunterstützung erfolgen kann.
[<=]

GS-A_3988 - Problem Management - Prüfung der Lösung durch den Melder eines übergreifenden Problems

Der meldende TI-ITSM-Teilnehmer MUSS die ihm vorgelegte Lösung des übergreifenden Problems prüfen und sein Ergebnis dem serviceverantwortlichen TI-ITSM-Teilnehmer innerhalb der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265-03]) über das TI-ITSM-System mitteilen.
[<=]

GS-A_3989 - Problem Management - Ablehnung der Lösung eines übergreifenden Problems

Wird die Lösung eines übergreifenden Problems durch den meldenden TI-ITSM-Teilnehmer abgelehnt, MUSS der serviceverantwortliche TI-ITSM-Teilnehmer das übergreifende Problem erneut bearbeiten, die Messung der Lösungszeit wird dann fortgesetzt.
[<=]

GS-A_3971 - Problem Management - Verifikation vor Schließung eines übergreifenden Problems

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN vor der Schließung einer übergreifenden Problem-Dokumentation sicherstellen, dass das Problem gelöst ist.
Ist das Problem nicht gelöst, dann ist das bestehende Problem weiterzubearbeiten. Es beginnt keine erneute Lösungszeit.
Liegt nach Ablauf der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265-03]) keine Rückmeldung durch den problemerkennenden TI-ITSM-Teilnehmer vor, KANN das übergreifende Problem geschlossen werden.
[<=]

GS-A_3990 - Problem Management - Schließung eines übergreifenden Problems

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach verifizierter Lösung des Problems die Dokumentation des übergreifenden Problems abschließend bearbeiten und das Problem schließen.
[<=]

GS-A_3991 - Problem Management - WDB-Aktualisierung nach Schließung eines übergreifenden Problems

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach der Behebung eines übergreifenden Problems die Wissensdatenbank der TI um die relevanten Problemlösungsinformationen aktualisieren.
[<=]

A_24968 - Problem Management - Probleme während Lösungsphase als "Pending" kennzeichnen

Der serviceverantwortliche TI-ITSM-Teilnehmer KANN für begründete administrativen oder organisatorische Aktivitäten, welche nicht durch ihn verschuldet und auch nicht planbar sind, beim Gesamtverantwortlichen TI veranlassen, dass ein spezifischer Zeitraum während der Lösungsphase eines Problems als "Pending" markiert wird. Die Entscheidung bzgl. der Markierung des Zeitraums liegt ausschließlich bei dem Gesamtverantwortlichen TI (Realisierung, Dauer, Zeitpunkt). [<=]

GS-A_5590 - Request Fulfillment - Nutzung Business-Servicekatalog bei der Erfassung von Service Requests

TI-ITSM-Teilnehmer MÜSSEN den im TI-ITSM-System veröffentlichten Business-Servicekatalog bei der Erfassung von Service Requests nutzen und alle geforderten Informationen laut der dort genannten Servicebeschreibung dem Service Request beifügen.
[<=]

GS-A_5351 - Request Fulfillment - Prüfung von Service Requests

Der Serviceverantwortliche MUSS den Service Request eines TI-ITSM-Teilnehmers auf Vollständigkeit und Plausibilität prüfen.
[<=]

GS-A_5352 - Request Fulfillment - Lösung bzw. Bearbeitung des Service Requests

Der Serviceverantwortliche MUSS sicherstellen, dass jeder Service Request gemäß Bedingungen des Servicekataloges (SLA) bearbeitet und abgeschlossen wird.
[<=]

GS-A_5591 - Request Fulfillment - Verifikation des Service Requests

TI-ITSM-Teilnehmer MÜSSEN die Verifikation eines ausgeführten Services gemäß der im Servicekatalog beschriebenen Angaben durchführen und das Ergebnis im TI-ITSM-System dokumentieren.
[<=]

GS-A_5592 - Request Fulfillment - Schließung des Service Requests

TI-ITSM-Teilnehmer MÜSSEN vor Schließung eines Service Requests die fehlerfreie Lieferung des Services durch den Servicenehmer verifizieren lassen. Bei negativer Verifikation ist für diesen Service kein neuer Request zu stellen. Stattdessen ist der bestehende Service Request weiterzubearbeiten.
[<=]

GS-A_5593 - Request Fulfillment - Schließung des Service Requests ohne Verifikation

TI-ITSM-Teilnehmer DÜRFEN Service Requests schließen, wenn die Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265-03]) ohne Rückmeldung überschritten ist.
[<=]

A_17764 - Configuration Management - Verwendung CI-ID

Der TI-ITSM-Teilnehmer MUSS die von dem Gesamtverantwortlichen TI vorgegebene CI-ID für jede von ihm betriebene Produktinstanz verwenden. [<=]

GS-A_4114 - Configuration Management - Bereitstellung von TI-Konfigurationsdaten

TI-ITSM-Teilnehmer MÜSSEN entsprechend ihrer Rolle (vgl. [gemKPT_Betr#Tab_KPT_Betr_TI_002]) TI-Konfigurationsdaten mit dem Gesamtverantwortlichen TI zu Beginn der Serviceerbringung initial abstimmen und im TI-ITSM-System hinterlegen.
[<=]

GS-A_5594 - Configuration Management - Identifikation von TI-Konfigurationsdaten

TI-ITSM-Teilnehmer MÜSSEN TI-Konfigurationsdaten gemäß Konfigurationsschema im TI-ITSM-System ermitteln und definieren.
[<=]

GS-A_4115 - Configuration Management - Datenänderung für TI-Konfigurationsdaten

TI-ITSM-Teilnehmer MÜSSEN TI-Konfigurationsdaten über den gesamten Zeitraum der Serviceerbringung aktuell halten und im TI-ITSM-System hinterlegen.

GS-A_4399 - Übermittlung von Produktdaten nach Abschluss von lokal autorisierten Produkt-Changes

Alle TI-ITSM-Teilnehmer MÜSSEN nach dem Abschluss (nach der Produktivsetzung des Produkt-Changes) von lokal autorisierten Produkt-Changes die geänderten Produktdaten an das TI-ITSM-System übermitteln.
[<=]

A_13575 - Change Management - Qualität von RfC

Der RfC-stellende TI-ITSM-Teilnehmer MUSS die RfC so formulieren, dass der Umfang und der Bedarf in sich vollständig ist, so dass der Gesamtverantwortliche TI den RfC ohne Hinzuziehung weiterer Dokumente bewerten kann. [<=]

GS-A_4400 - Produkt-RfC (Master-Change) erstellen

Alle TI-ITSM-Teilnehmer MÜSSEN für genehmigungspflichtige Produktänderungen einen Produkt-RfC (Master-Change) im TI-ITSM-System erstellen.
[<=]

GS-A_4398 - Prüfung auf genehmigungspflichtige Produktänderung

Alle TI-ITSM-Teilnehmer MÜSSEN jeden festgestellten Produktänderungsbedarf einer Prüfung gemäß der unten abgebildeten Tab_Betr_TIP_024 CHG – Vorprüfung Produktänderungsbedarf unterziehen. Dabei ist - durch Feststellung der Wechselwirkungen mit anderen Produkten sowie der Abweichung von Produkttypvorgaben - zu prüfen, ob es sich um eine genehmigungspflichtige Produktänderung handelt.

Tabelle 22: Tab_Betr_TIP_024 CHG – Vorprüfung. Produktänderungsbedarf

GS-A_5597 - Produkt-RfC (Sub-Changes) erstellen

Der TI-ITSM-Teilnehmer MUSS zur Umsetzung der Änderungen des Master-Changes in den konkreten Betriebsumgebungen die abgeleiteten Sub-Changes auf Basis des autorisierten Master-Changes und der abgestimmten Rahmenbedingungen stellen.
[<=]

GS-A_5599 - Beschreibung der Verifikation des Produkt-Changes im RfC

Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, MUSS für diesen eine Verifikation beschreiben, welche die Wirksamkeit des Changes nachweist.
[<=]

GS-A_5600 - Beschreibung der Verifikation des Produkt-Changes in Auswirkung auf andere TI-Fachanwendungen im RfC

Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, MUSS eine Verifikation beschreiben, welche die Ende-zu-Ende-Verfügbarkeit und -Funktionalität der entsprechenden Anwendungsfälle nach der vollständigen Implementierung des Changes in Auswirkung auf andere TI-Fachanwendungen nachweist.
[<=]

GS-A_5370 - Prüfung auf Emergency Change

Alle TI-ITSM-Teilnehmer MÜSSEN auf Grundlage der in Tabelle Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes genannten Kriterien prüfen, ob die Notwendigkeit zur Durchführung eines Emergency Change besteht.

Tabelle 23: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes

GS-A_4402 - Mitwirkungspflicht bei der Bewertung vom Produkt-RfC

Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN bei der Bewertung eines Produkt-RfC mitwirken. Die Mitwirkung erfolgt innerhalb der Bewertungsphase im BCB oder bilateral zwischen TI-ITSM-Teilnehmer und Gesamtverantwortlichen TI.
[<=]

GS-A_5610-02 - Bearbeitungsfristen in der Bewertung von Produkt-Changes

Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN mindestens folgende Change-Bewertungszeiten des GTI bei der Erstellung und Umsetzungsplanung (im Sinne Vorlaufzeiten vor Implementierungsbeginn) eines RfC berücksichtigen:

• Produkt-Change (Master): mindestens 5 Werktage (zwischen Beantragung und Umsetzung)
  
• Produkt-Change (Sub): mindestens 3 Werktage (zwischen Beantragung und Umsetzung)
  

GS-A_5611 - Change Management - Umsetzung von autorisierten RfC

TI-ITSM-Teilnehmer MÜSSEN vor der Umsetzung eines RfC die Autorisierung des Gesamtverantwortlichen TI einholen. Ausnahmeregelungen beziehen sich einzig auf Emergency Changes.
[<=]

GS-A_4419 - Change Management - Nutzung der Testumgebung (RU/TU)

TI-ITSM-Teilnehmer MÜSSEN die Anforderungen und die geplante Belegung an die Nutzung der Referenzumgebung (RU) und der Testumgebung (TU) für ihre Produkttests mit dem Gesamtverantwortlichen TI abstimmen.
[<=]

GS-A_4417 - Stetige Aktualisierung des Change-Datensatzes im TI-ITSM-System

Realisierende TI-ITSM-Teilnehmer MÜSSEN die interne Dokumentation der Planungs- und Realisierungsdaten von autorisierten Produkt-Changes stetig im TI-ITSM-System aktuell halten.
[<=]

A_24799 - Change Management - End-to-End-Funktionsprüpfung nach Change

Der TI-ITSM-Teilnehmer MUSS nach der Durchführung eines jeden Changes durch geeignete Maßnahmen überprüfen, dass die Funktionalität beim Client wie erwartet wieder hergestellt ist bzw. noch immer/weiterhin besteht. [<=]

GS-A_5601 - Nachweis der Wirksamkeit eines Changes

Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, SOLL eine Verifikation durchführen, welche die Wirksamkeit des Changes nachweist. Der TI-ITSM-Teilnehmer SOLL dem Gesamtverantwortlichen TI die entsprechenden Nachweise vorlegen.
[<=]

GS-A_5602 - Nachweis der Wirksamkeit eines Changes in Auswirkung auf andere TI-Fachanwendungen

Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, SOLL auf Anfrage des Gesamtverantwortlichen TI eine Verifikation durchführen, welche die Ende-zu-Ende-Verfügbarkeit und -Funktionalität eines entsprechenden Anwendungsfalls der veränderten Produktinstanz nachweist. Der TI-ITSM-Teilnehmer SOLL dem Gesamtverantwortlichen TI die entsprechenden Nachweise vorlegen.
[<=]

A_18407 - Unterstützung bei Change-Verifikation

TI-ITSM-Teilnehmer, deren Service von einem Produkt-Change betroffen ist, MÜSSEN nach der Change-Implementierung bei der Ende-zu-Ende-Verifikation unterstützen.
[<=]

GS-A_4407 - Bereitstellung der Dokumentation des Change Managements für genehmigungspflichtige Produkt-Changes

TI-ITSM-Teilnehmer MÜSSEN für jeden genehmigungspflichtigen Produkt-Change eine Dokumentation der Aktivitäten und Nachweise im TI-ITSM-System ablegen. [<=]

GS-A_4425 - Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Produkt-Changes

TI-ITSM-Teilnehmer MÜSSEN mit erfolgtem Abschluss oder Abbruch des Produkt-Changes eine Bewertung des Master-Changes durchführen und dabei gegebenenfalls erkannte Potenziale für mögliche Optimierungen zukünftiger Durchführungen von Produkt-Changes dem Gesamtverantwortlichen TI mitteilen.
[<=]

GS-A_4418 - Übermittlung von Abweichungen vom Produkt-RfC

TI-ITSM-Teilnehmer, die während der Umsetzung des autorisierten Produkt-Changes Abweichungen zur Planung in Bezug auf zeitliche, inhaltliche und in der Auswirkung im Produkt-RfC feststellen, MÜSSEN diese unverzüglich dem Gesamtverantwortlichen TI melden.
[<=]

GS-A_4424 - Umsetzung des Fallbackplans

TI-ITSM-Teilnehmer MÜSSEN einen Fallbackplan nach den Vorgaben des Gesamtverantwortlichen TI erstellen und – bei erkannter Notwendigkeit während des Change Deployments – umsetzen.
[<=]

GS-A_5366 - Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Standard-Produkt-Changes

TI-ITSM-Teilnehmer MÜSSEN zur abschließenden Kategorisierung von Produkt-Changes als „Standard-Change“ den Gesamtverantwortlichen TI unterstützen, indem sie die zur Prüfung erforderlichen Inhalte auf Anforderung an den Gesamtverantwortlichen TI liefern.
TI-ITSM-Teilnehmer MÜSSEN für die zukünftige Umsetzung des Produkt-Changes als „Standard-Change“ die zum jeweiligen Produkt-Change dazugehörigen Umsetzungsaktivitäten dokumentieren und diese dem Gesamtverantwortlichen TI übergeben.
[<=]

GS-A_5378 - Change Management - Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer MÜSSEN bei der Umsetzung eines Emergency-Changes die zeitliche Kritikalität beachten, d. h., die eingetretene Notsituation schnellstmöglich beseitigen und bei der Umsetzung den Anweisungen (Freigabe, Ablehnung, Testanforderungen, Dokumentation) des Gesamtverantwortlichen TI folgen.
[<=]

GS-A_5361 - Change Management - Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer bei Nichterreichbarkeit des Gesamtverantwortlichen TI

TI-ITSM-Teilnehmer MÜSSEN bei Nichterreichbarkeit des Gesamtverantwortlichen TI außerhalb der Servicezeit - und daraus resultierenden fehlenden Freigabe – einen Emergency Change in eigenem Ermessen durchführen.
TI-ITSM-Teilnehmer MÜSSEN dabei das Zutreffen aller drei folgenden Bedingungen beachten:

1. Es handelt sich nach fachlich-fundierter Bewertung des TI-ITSM-Teilnehmers um eine Notsituation, die nur durch einen Emergency-Change gelöst werden kann.
   
2. Der TI-ITSM-Teilnehmer wird nach erfolgter Umsetzung des Emergency-Changes unverzüglich die Dokumentation im TI-ITSM-System erstellen und an den Gesamtverantwortlichen TI übermitteln.
   
3. Es entstehen – soweit durch den TI-ITSM-Teilnehmer in dieser Situation erkennbar – durch die Umsetzung des Emergency Changes keine finanziellen Auswirkungen für den Gesamtverantwortlichen TI.
   

GS-A_4117 - Knowledge Management - Informationsbereitstellung durch TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer KÖNNEN Produkt- bzw. Serviceinformationen, mögliche Störungsursachen und Hinweise zu deren Behebung elektronisch an den Gesamtverantwortlichen TI übermitteln und stets aktuell halten. [<=]

GS-A_5603 - Knowledge Management - Eingangskanal für Informationen von TI-ITSM-Teilnehmern

TI-ITSM-Teilnehmer MÜSSEN den vom Gesamtverantwortlichen TI bereitgestellten Eingangskanal für die Einlieferung von Informationen nutzen.
[<=]

GS-A_4100 - Service Level Management - Messung der Service Level

TI-ITSM-Teilnehmer MÜSSEN alle nicht durch das TI-ITSM-System gemessenen Service Level gemäß [gemKPT_Betr] bzw. [gemSpec_Perf] messen. [<=]

GS-A_5604 - Service Level Management - Bewertung der Messergebnisse

TI-ITSM-Teilnehmer MÜSSEN in allen Fällen einer Untererfüllung der gemessenen Werte von den Zielwerten eine Begründung für die Untererfüllung sowie eine Information zu getroffenen und geplanten Maßnahmen angeben.
[<=]

GS-A_4101 - Service Level Management - Übermittlung der Service Level Messergebnisse

TI-ITSM-Teilnehmer MÜSSEN die Service Level Messergebnisse an die durch den Gesamtverantwortlichen TI benannte Kommunikationsschnittstelle übermitteln.
[<=]

GS-A_4397 - Service Level Management - Teilnahme am Service Review

TI-ITSM-Teilnehmer MÜSSEN am Service Review teilnehmen und die bilateral vereinbarten Optimierungsaktivitäten umsetzen.

A_24800 - Service Level Management - Auskunft Servicebedarf im Rahmen des Service Review

Der TI-ITSM-Teilnehmer MUSS im Rahmen der Service-Review-Meetings Auskunft über die Servicebedarfe seiner Nutzer geben (qualitativ und quantitativ). [<=]

GS-A_5606 - Performance Management / Capacity - Unterstützung bei Definition von Kapazitätsanforderungen

TI-ITSM-Teilnehmer MÜSSEN auf Anforderung des Gesamtverantwortlichen TI an Gesprächen zur Bewertung der aktuellen Kapazitätssituation teilnehmen. Sie MÜSSEN den Gesamtverantwortlichen TI bei der Entwicklung und Definition von zukünftigen Kapazitätsanforderungen unterstützen.
[<=]

A_25903 - Redundanz - Definition inhaltlicher Auszüge aus dem Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS in dem Redundanzkonzept die nachfolgenden Themen betrachten.

1. Einleitung

A_25902 - Redundanz - Bereitstellung Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS auf Basis der definierten Performancevorgaben und der durchgeführten Business Impact Analyse (siehe [ISO/TS 22317:2021])

• ein Redundanzkonzept erstellen, das sich an den Leitlinien von Industriestandards für Planung, Aufbau und dem kontinuierlichen Betrieb von Rechenzentren orientiert,
• • in dem eine Identifizierung von Redundanzstrategien,
  • eine risikobasierte Bewertung insbesondere in Bezug auch auf mögliche Gefährdungen erfolgt
    

A_26014 - Redundanz - Umsetzung Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS die aus dem Konzept abgeleiteten Maßnahmen und die dafür geeignete Redundanzstrategie umsetzen. Die Umsetzung kann in Abstimmung mit dem Gesamtverantwortlichen TI in Ausbaustufen erfolgen. [<=]

A_25917 - Redundanz - Kontrollierte Validierung des Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS in Abstimmung mit dem Gesamtverantwortlichen TI mindestens einmal jährlich eine praktische Validierung des vorliegenden Redundanzkonzeptes durchführen.
Die Validierung des Redundanzkonzeptes ist möglichst in allen angebotenen Betriebsumgebungen durchzuführen. Dabei sollen unterschiedliche Ausfallszenarien praktisch überprüft und die zur Wiederherstellung erforderlichen Tätigkeiten erfasst und mit dem Konzept abgeglichen werden. Es ist maßgeblich darauf zu achten, dass die im Redundanzkonzept angegebenen Wiederherstellungszeiten eingehalten werden. Werden bei dieser Durchführung Abweichungen vom Konzept oder den erwarteten Zeiten festgestellt, so sind vom Anbieter in Abstimmung mit dem Gesamtverantwortlichen TI entsprechende Folgemaßnahmen zu planen und priorisiert umzusetzen.
[<=]

GS-A_4121 - Notfall Management - Analyse Auswirkungen möglicher Schadensereignisse auf Sicherheit und Funktion der TI-Services

TI-ITSM-Teilnehmer MÜSSEN die Auswirkungen möglicher Schadensereignisse auf von ihnen verantworteten TI-Services analysieren und bewerten. Die Auswirkungsanalyse MUSS mit mindestens folgenden Vorgaben erstellt werden:

• angenommener Ausfall einer tatsächlichen Funktionalität bzw. Eigenschaft des Produkts (Notfallszenario),
  
• Beschreibung der Auswirkung möglicher Wechselwirkung mit anderen Produkten bzw. auf den TI-Service,
  
• Risikobewertung des Notfallszenarios.

GS-A_4123 - Notfall Management - Entwicklung und Pflege der TI-Notfallvorsorgedokumentation

TI-ITSM-Teilnehmer MÜSSEN eine TI-Notfallvorsorgedokumentation, welche die Ergebnisse der Auswirkungsanalyse sowie Vorkehrungen zur TI-Notfallvorsorge des Serviceverantwortlichen enthält, entwickeln und pflegen. In der TI-Notfallvorsorgedokumentation sind die Aktivitäten festgelegt, die bei Eintritt eines TI-Notfalls durchzuführen sind.
[<=]

GS-A_4124 - Notfall Management - Umsetzung Vorkehrungen zur TI-Notfallvorsorge

TI-ITSM-Teilnehmer MÜSSEN die erarbeiteten Vorkehrungen zur TI-Notfallvorsorge umsetzen.

GS-A_4126 - Notfall Management - Eskalation TI-Notfälle

TI-ITSM-Teilnehmer MÜSSEN erkannte TI-Notfälle unverzüglich an den Gesamtverantwortlichen TI eskalieren. Eine Meldung an den Gesamtverantwortlichen TI MUSS im Sinne einer umgehenden und persönlichen Benachrichtigung erfolgen.
[<=]

GS-A_4127 - Notfall Management - Sofortmaßnahmen TI-Notfälle

TI-ITSM-Teilnehmer, deren Dienste von einem TI-Notfall betroffen sind, MÜSSEN entsprechende Maßnahmen einleiten, mit dem Ziel die Auswirkungen der TI-Notfälle eigenständig zu reduzieren oder einzuschränken.
[<=]

GS-A_4128 - Notfall Management - Bewältigung der TI-Notfälle

TI-ITSM-Teilnehmer MÜSSEN vom EMC autorisierte TI-Notfallmaßnahmen zur Bewältigung von TI-Notfällen im eigenen Verantwortungsbereich umsetzen.

GS-A_4129 - Notfall Management - Unterstützung bei TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN bei der Bewältigung sowie Koordination der TI-Notfälle den Gesamtverantwortlichen TI oder andere TI-ITSM-Teilnehmer im erforderlichen Umfang unterstützen.
[<=]

GS-A_4130 - Notfall Management - Festlegung der Schnittstellen des EMC

Prozessbeteiligte TI-ITSM-Teilnehmer MÜSSEN die vom Gesamtverantwortlichen TI bereitgestellten Schnittstellen im Rahmen der Einberufung des EMC nutzen.
[<=]

GS-A_4132 - Notfall Management - Durchführung der Wiederherstellung und TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN alle Aktivitäten, welche der Wiedererreichung und Stabilisierung des Leistungsumfangs im eigenen Verantwortungsbereich dienen, durchführen und dokumentieren.
[<=]

GS-A_4134 - Notfall Management - Auswertungen von TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN nach Abschluss der TI-Notfallbewältigung den TI-Notfall hinsichtlich seiner Ursache, Auswirkung, Dauer, Wahrscheinlichkeit eines erneuten Eintritts und der Angemessenheit der ergriffenen Maßnahmen zur TI-Notfallbewältigung auswerten. Die Auswertungsergebnisse sind zusammen mit TI-Notfall-Logbuch und Wiederherstellungsbericht, an den Gesamtverantwortlichen TI zu übergeben.
[<=]

GS-A_4136 - Notfall Management - Statusinformation bei TI-Notfällen

TI-ITSM-Teilnehmer, die von einem TI-Notfall betroffen sind, MÜSSEN im Rahmen der TI-Notfallbewältigung den Gesamtverantwortlichen TI ständig über den aktuellen Status der Durchführung der TI-Notfallmaßnahmen informieren.
[<=]

GS-A_4137 - Notfall Management - Dokumentation im TI-Notfall-Logbuch

TI-ITSM-Teilnehmer MÜSSEN zu jedem TI-Notfall ein TI-Notfall-Logbuch erstellen.

TI-ITSM-Teilnehmer MÜSSEN im Rahmen der TI-Notfallbewältigung im eigenen Verantwortungsbereich folgende Angaben im TI-Notfall-Logbuch dokumentieren:

• Zeit (Wann?)

• Verantwortung (Wer?)

• Durchführung (Was, Wie?)

• Ergebnis einer Maßnahme

TI-ITSM-Teilnehmer MÜSSEN dabei das TI-Notfall-Logbuch in den Phasen vom Bekanntwerden des Notfalls bis zur Notfalldeeskalation ständig aktualisieren.

GS-A_4138 - Notfall Management - Erstellung des Wiederherstellungsberichts nach TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN zu jeder Wiederherstellung in der TI-Notfallbewältigung einen Wiederherstellungsbericht erstellen.

TI-ITSM-Teilnehmer MÜSSEN einen Wiederherstellungsbericht mit allen durchgeführten Aktionen und Änderungen sowie Angaben zu Erfolg und Misserfolg jeder einzelnen Aktivität im eigenen Verantwortungsbereich, welche im Rahmen der Wiederherstellung durchgeführt wurden, erstellen.

GS-A_3695 - Grundlegender Aufbau Versionsnummern

Versionsnummern der TI MÜSSEN folgenden grundlegenden Aufbau haben:
Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer<Trenner>Suffix
Die Bestandteile „Trenner“ und Suffix sind optional. Details hierzu werden pro Artefakttyp (vgl. 2.1.1) festgelegt.
Die kleinste Versionsnummer ist 0.0.1<Trenner>0. Die Bestandteile der Nummerierung sind numerisch.

[<=]

GS-A_3696 - Zeitpunkt der Erzeugung neuer Versionsnummern

Neue Versionsnummern für zu versionierende Artefakte der TI MÜSSEN mindestens dann erzeugt werden, wenn die Artefakte zur Nutzung freigegeben werden, unabhängig vom Grund ihrer Erstellung im Entwicklungsprozess.

GS-A_3697 - Anlass der Erhöhung von Versionsnummern

Bei der Erhöhung von Versionsnummern MUSS nach folgenden Regeln verfahren werden:

• Die Hauptversionsnummer eines Artefakts MUSS sich erhöhen, falls daran signifikante Änderungen durchgeführt werden.

• Die Nebenversionsnummer MUSS sich erhöhen, falls moderate Änderungen durchgeführt werden.

• Die Revisionsnummer MUSS sich erhöhen, falls Änderungen notwendig werden, die das Artefakt bezüglich seiner Außensicht nicht beeinflussen.

• Das optionale Suffix MUSS sich erhöhen, falls Änderungen notwendig werden, die das Artefakt bezüglich seiner Außensicht nicht beeinflussen und nicht bereits durch die Revisionsnummer abgebildet wurden.

• Bei einer Erhöhung eines Versionsnummernteils (Haupt-, Neben-, Revisionsnummer) MÜSSEN alle rechts davon angegebenen Versionsnummernanteile auf null gesetzt werden.

GS-A_4541 - Nutzung der Produkttypversion zur Kompatibilitätsprüfung

Produkte der TI DÜRFEN im Rahmen von Kompatibilitätsprüfungen die Produkttypversion anderer genutzter Produkte technisch NICHT heranziehen, sofern dies nicht ausdrücklich durch die gematik in konkreten Einzelfällen festgelegt wird.
[<=]

GS-A_4542 - Spezifikationsgrundlage für Produkte

Alle Produkte der TI MÜSSEN auf einer durch die gematik definierten Spezifikationsgrundlage (Produkttyp und Produkttypversion) basieren.

GS-A_5025 - Versionierung von Produkten auf Basis von zentralen Produkttypen der TI-Plattform und fachanwendungsspezifischen Diensten durch die Produktidentifikation

Alle Produkte der TI, die auf zentralen Produkttypen der TI-Plattform oder einem fachspezifischen Dienst beruhen, MÜSSEN eine eindeutige Produktidentifikation entsprechend den Vorgaben in Tab_ProdIdentZ besitzen.
Das Produktkürzel der Produktidentifikation MUSS für alle Umgebungen (RU/TU/PU) gleich sein und dem Zulassungsantrag entsprechen.

[<=]

GS-A_5054 - Versionierung von Produkten durch die Produktidentifikation erweitert um Klartextnamen

Alle Produkte der TI, die auf Produkttypen beruhen, KÖNNEN zusätzlich zu ihrer eindeutigen Produktidentifikation sowohl Herstellernamen, als auch den Produktnamen als Klartext, entsprechend den Vorgaben in Tab_ZusAttr, besitzen.
[<=]

GS-A_5038 - Festlegungen zur Vergabe einer Produktversion

Hersteller bzw. Anbieter von Produkten MÜSSEN folgende Festlegungen bei der Vergabe einer Produktversion berücksichtigen:

• Jede Produktänderung MUSS durch eine Änderung an den Produktversionsanteilen Hauptversionsnummer, Nebenversionsnummer, Revisionsnummer bzw., wenn vorhanden, Patchlevel(Suffix) gekennzeichnet werden.

• Jede Produktänderung MUSS eine höhere Produktversion aufweisen, als die zugrundeliegende Vorgängerversion.

• Wenn ein von der Stelligkeit höherer Versionsanteil geändert wird, MÜSSEN die Versionsanteile mit niedrigerer Stelligkeit auf „0“ gesetzt werden.

• Für die Versionsanteile MÜSSEN ausschließlich Dezimalzahlen verwendet werden. Führende Nullen in einzelnen Anteilen DÜRFEN NICHT bei der Anzeige in einer textuellen Darstellungsform verwendet werden.

GS-A_5039-01 - Änderung der Produktversion bei Änderungen der Produkttypversion

Hersteller bzw. Anbieter von Produkten MÜSSEN folgende Festlegungen bei der Vergabe einer Produktversion bei Produktänderungen berücksichtigen, falls sich die zugrundeliegende Produkttypversion durch die gematik ändert:

• Die Hauptversionsnummer MUSS geändert werden, wenn sich die Haupt- oder Nebenversionsnummer des zugrundeliegenden Produkttypen ändert.

GS-A_5040-01 - Änderung der Produktversion bei Produktänderungen außerhalb von Produkttypänderungen

Hersteller bzw. Anbieter von Produkten MÜSSEN folgende Festlegungen bei der Vergabe einer Produktversion bei Produktänderungen berücksichtigen, falls die zugrundeliegende Produkttypversion durch die gematik unverändert bleibt oder die Produktänderung neben Änderungen aufgrund einer neuen Produkttypversion weitere Anteile enthält:

• Die Hauptversionsnummer MUSS geändert werden, wenn die Produktänderung größere Features oder Feature-Änderungen enthält (Signifikante Änderung).
  
• Die Nebenversionsnummer MUSS geändert werden, wenn die Produktänderung kleinere Features oder Feature-Änderungen enthält (Moderate Änderung).
• Die Revisionsnummer MUSS geändert werden, wenn die Produktänderung das Verhalten des Produktes an den Außenschnittstellen beeinflusst, jedoch keine signifikante oder moderate Änderung vorliegt.
• Das optional vorhanden Patchlevel MUSS geändert werden, wenn die Produktänderung das Verhalten des Produktes an den Außenschnittstellen nicht beeinflusst und auch keine signifikante oder moderate Änderung vorliegt.

A_17416-01 - Schnittstelle Betriebsdatenerfassung Prüfung des TLS-Server-Zertifikats durch Fach- und zentrale Dienste

Der Client der Schnittstelle I_OpsData_Update MUSS bei der Absicherung der Verbindung durch TLS die serverseitige Authentisierung durch Prüfung des I_OpsData_Update-X.509-Komponentenzertifikats mit der TLS-Server-Identität ID.ZD.TLS_S zur Serverauthentisierung entsprechend [gemSpec_Krypt#TLS-Verbindungen] umsetzen.
[<=]

A_17733-02 - Schnittstelle Betriebsdatenerfassung Datei-Upload

Die Schnittstelle I_OpsData_Update MUSS die Operation I_OpsData_Update::fileUpload für die Übertragung von Dateien von Clients zur Schnittstelle Betriebsdatenerfassung entsprechend Tabelle Tab_I_OpsData_Update_002 bereitstellen.

Tabelle 24: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload

A_23110-01 - Schnittstelle Betriebsdatenerfassung Content-Upload JSON Format

Die Schnittstelle I_OpsData_Update MUSS die Operation I_OpsData_Update::contentUploadJSON für die Übertragung von Content im JSON Format von Clients zur Schnittstelle Betriebsdatenerfassung entsprechend Tabelle Tab_I_OpsData_Update_004 bereitstellen.
 
Tabelle #: Tab_I_OpsData_Update_004 Operation I_OpsData_Update::contentUploadJSON