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

[<=]

A_18176-01 - Unterstützung bei der Einrichtung und Betrieb von Probes

Der TI-ITSM-Teilnehmer MUSS dem Gesamtverantwortlichen TI (gematik) bei der Einrichtung bzw. Änderung und Inbetriebnahme von Probes unterstützen. Dazu zählen:

• Unterstützung bei der Ersteinrichtung und Aktualisierung von Probes
• Bereitstellung von Credentials, Accounts usw. für die Inbetriebnahme bzw. Aktualisierung von Probes
• Bereitstellung von Scripts zum Probing oder gemeinsame Entwicklung mit dem Gesamtverantwortlichen TI (gematik)
• Überprüfung, ob Änderungen / Updates des Produktes die Probes beeinflussen

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_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-05 - 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_27718 - Telemetriedatenlieferung - Konnektivität zur gematik gewährleisten

Der Anbieter MUSS die Konnektivität zu der Telemetriedaten-Schnittstelle der gematik durchgehend gewährleisten.
[<=]

A_27719 - Telemetriedatenlieferung - Nutzung eines gültigen Client-Zertifikats

Der Anbieter MUSS für den Verbindungsaufbau zum Telemetriedaten-Service der gematik ein gültiges TLS Client-Zertifikat nutzen.
Hinweis: Ein entsprechendes TLS Client-Zertifikat muss vor Inbetriebnahme bei der gematik beantragt werden. [<=]

A_27724-01 - Performance - Telemetriedatenlieferung - Korrektheit der Datenlieferung

Der Produkttyp MUSS die Fachdienstinformationen vollständig, lückenlos für jeden ausgeführten Aufruf, überlappungsfrei, syntaktisch und semantisch korrekt an den Telemetriedaten-Service senden.

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik. [<=]

A_27723-01 - Performance - Telemetriedatenlieferung - Ad-hoc Lieferung

Der Produkttyp MUSS für jede ausgeführte Operation direkt die Betriebsdaten gemäß der Tabelle "Tab_gemSpec_Perf_Trace_Parameter_Telemetriedatenlieferung" Trace-Parameter einer Telemetriedatenlieferung an den Telemetriedaten-Service senden.

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik. [<=]

A_27722-01 - Performance - Telemetriedatenlieferung - Status Code des Ressource Servers

Der Produkttyp MUSS im Parameter rs.status entweder einen HTTP-Statuscode des Ressource Servers gemäß Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes oder gemäß produkttypspezifischer Definition an den Telemetriedaten-Service  übermitteln.

Tabelle 13: Tab_gemSpec_Perf_Telemetriedaten_RS_Statuscodes

A_27729-01 - Performance - Telemetriedatenlieferung - Selbstauskunft

Der Produkttyp MUSS die in der Tabelle "Tab_gemSpec_Perf_Telemetriedaten_product_info" gelisteten Parameter des Open Telemetry Logs "product_info" befüllen und die Produktinformation bei jeder Änderung an den Telemetriedaten-Service überliefern.

Hinweis: Ist der ZETA Guard Teil des Produkttyps (z.B. VSDM2) gilt die Nachweispflicht für die Sendung an den Telemetriedaten-Service des ZETA Guards, in anderen Fällen (z.B. sektoraler IDP) an den Telemetriedaten-Service der gematik.
[<=]

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-01 - Telemetrie-Daten Service, Custom Collector für Selbstauskunft

Der Telemetrie-Daten Service MUSS einen Custom Collector (oder einen Collector mit einem Custom Processor) für die Selbstauskunft des Resource Servers implementieren. Die Selbstauskunft des Resource Servers erfolgt für jede eigenständige Instanz als OTLP Log Record.
Der OTLP Log Record für die Selbstauskunft ist wie folgt definiert:
Body: "Selbstauskunft".
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 – Der Zeitpunkt der Erstellung des Log Records (wird automatisch gesetzt).

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.
• Resource Server-Duration: Zeit in ms bei jedem Aufruf des Resource Server 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_28190 - Performance - PoPP-Service - Bearbeitungszeiten für Operation PoPP.5

Der PoPP-Service MUSS unabhängig vom Füllstand der eGK-Hash-Datenbank, aber unter Berücksichtigung der in A_27046 vorgegebenen Maximalbefüllung der eGK-Hash-Datenbank in der Lage sein, die import-Funktion in weniger als einer Minute oder mit einer Geschwindigkeit von mindestens fünftausend Einträgen pro Sekunde zu verarbeiten.

Hinweis: Der Passus "weniger als eine Minute" ist relevant, wenn die signierte Nachricht nur wenige Einträge enthält. Der Passus "mindestens fünftausend Einträge pro Sekunde" ist relevant, wenn die signierte Nachricht sehr viele Einträge enthält. Wegen des Overheads der Signaturprüfung ist eine hohe Geschwindigkeit für signierte Nachrichten mit wenigen Einträgen nicht realistisch. Der Overhead der Signaturprüfung fällt für viele Einträge in einer signierten Nachricht nicht ins Gewicht. [<=]

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_27390 - Performance - PoPP-Service - Zugriff für den Nutzer

Der Anbieter PoPP-Service MUSS den Zugriff auf den Dienst über einer einzigen URL ermöglichen. Die Nutzung von diensteigenen Redundanzmechanismen zur Aufrechterhaltung der Verfügbarkeit im Falle eines Teilausfalls darf keine Nutzerinteraktion erfordern. [<=]

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 - Telemetriedatenlieferung - Spezifika PoPP-Service - Status

Der PoPP-Service MUSS bei Telemetriedatenlieferung im Trace Span zugehörig zum Resource Server 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 - Telemetriedatenlieferung - Spezifika PoPP-Service - Operation

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

A_26532 - Performance - Telemetriedatenlieferung - Spezifika PoPP-Service - Message

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

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

• $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
• $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
• $telidP: Telematik-ID des angemeldeten Nutzers, verschlüsselt gemäß [A_28578-*], 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-*].

A_26501 - Kommunikation - Benennung von Ansprechpartnern und Kontakten (FULL)

Der TI-ITSM-Teilnehmer MUSS Kontaktdaten von Ansprechpartnern und bei Bedarf auch von notwendigen Funktionskontakten im TI-ITSM-System erfassen und stets aktuell halten. Der vom TI-ITSM-Teilnehmer benannte Partner Manager übernimmt für seine Organisation verantwortlich diese Aufgabe.
Kontaktdaten werden jeweils benötigt für

• die Rolle Partner Manager,
• die Rolle Service Delivery Manager,
• die Rolle Service Executive Manager,
• die Rolle TI-ITSM Prozess-Manager,
• die Rolle Notfallbeauftragter,
• den Ansprechpartner Unternehmenskommunikation / Krisenkommunikation,
• den Ansprechpartner Informationssicherheit,
• den Ansprechpartner Datenschutz,
• den Ansprechpartner für vertragliche und kaufmännische Fragestellungen.

• Erreichbarkeit des jeweiligen Help Desks (Funktionskontakt)
• verantwortlicher Ansprechpartner für den Help Desk

• 24/7-Kontaktpunkt,
• Single-Point-of-Contact (SPOC),
• Manager-on-Duty.

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-01 - Koordinierung - 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 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 19: Tab_Betr_TIP_102 PRO – Festlegung von Dringlichkeit

Tabelle 20: 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-01 - Configuration Management - Übermittlung von Produktdaten nach Abschluss von autorisierten Normal-Changes

Alle TI-ITSM-Teilnehmer MÜSSEN mit der Umsetzung eines Software Deployments die Konfigurationsdaten im TI-ITSM übermitteln. Die Übermittlung der Konfigurationsdaten erfolgt mit der Beantragung eines Change Requests im TI-ITSM-System. Nach Abschluss des Changes werden die Konfigurationsdaten in der CMDB aktualisiert.
[<=]

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-01 - Change Management - Request for Change erstellen

Alle TI-ITSM-Teilnehmer MÜSSEN je nach Änderungsbedarf einen Request for Change im TI-ITSM-System erstellen.
[<=]

GS-A_4398-02 - Change Management - Prüfung auf genehmigungspflichtige Änderung

Alle TI-ITSM-Teilnehmer MÜSSEN jeden festgestellten Änderungsbedarf einer Prüfung gemäß der unten abgebildeten Tab_Betr_TIP_024 CHG – Vorprüfung Ä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 Änderung handelt.

Tabelle 21: Tab_Betr_TIP_024 CHG – Vorprüfung. Änderungsbedarf

GS-A_5599-01 - Change Management - Beschreibung der Verifikation des Changes im RfC

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

Mit der Verifikation wird nachgewiesen, dass der Change wie geplant Ende-zu-Ende implementiert wurde und die TI-Services weiterhin verfügbar und funktional sind. Die Verifikationsbeschreibung ist Bestandteil eines jeden Changes.

[<=]

GS-A_4402-01 - Change Management - Mitwirkungspflicht bei der Bewertung vom RfC

Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN bei der Bewertung eines RfC mitwirken. [<=]

GS-A_5610-03 - Change Management - Vorlaufzeiten in der Bewertung von Changes

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

• Master-Change: mindestens 24 Stunden zur Hauptzeit (zwischen Validierungsanforderung und Umsetzungsbeginn des ersten Sub-Changes)
• Standard-/Sub-Change: mindestens 24 Stunden zur Hauptzeit (zwischen Validierungsanforderung und Umsetzungsbeginn

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-01 - Change Management - Stetige Aktualisierung des Change-Datensatzes im TI-ITSM-System

Realisierende TI-ITSM-Teilnehmer MÜSSEN die interne Dokumentation der Planungs- und Realisierungsdaten von autorisierten 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-01 - Change Management - Nachweis der Wirksamkeit eines Changes (Verifikation)

Jeder TI-ITSM-Teilnehmer, der einen RfC stellt , MUSS unmittelbar mit der Umsetzung eines Changes eine Verifikation durchführen, welche die Wirksamkeit des Changes hinsichtlich der Verfügbarkeit und Funktionalität des Dienstes nachweist. Der TI-ITSM-Teilnehmer MUSS dem Gesamtverantwortlichen TI die entsprechenden Nachweise spätestens 16 Stunden zur Hauptzeit nach der Umsetzung vorlegen und im TI-ITSM dokumentieren.
[<=]

GS-A_5602-01 - Change Management - Nachweis der Wirksamkeit eines Changes in Auswirkung auf andere TI-Anwendungen (Verifikation)

Jeder TI-ITSM-Teilnehmer, der einen 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-01 - Change Management - Unterstützung bei Change-Verifikation

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

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

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

GS-A_4425-01 - Change Management - Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Changes

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

GS-A_4418-01 - Change Management - Übermittlung von Abweichungen vom RfC

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

GS-A_4424-01 - Change Management - Umsetzung des Fallbackplans

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

GS-A_5366-01 - Change Management - Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Standard-Changes

TI-ITSM-Teilnehmer MÜSSEN zur abschließenden Kategorisierung von 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 Changes als „Standard-Change“ die zum jeweiligen 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.