gemKPT_Betr_V3.36.0_Aend

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

Betriebskonzept

Online-Produktivbetrieb

   

Version	3.3536.0
Revision	907631947083
Stand	1729.05.2024
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemKPT_Betr

 

Dokumentinformationen

Änderungen zur Vorversion 

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

 

Dokumentenhistorie

Inhaltsverzeichnis

Dokumentinformationen

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzung des Dokuments

1.5 Methodik

1.5.1 Anforderungen

2 Grundlagen des Betriebs

2.1 Gegenstand des Betriebskonzepts

2.2 Begriffserläuterungen

2.2.1 Business-Servicekatalog

2.2.2 Unterstützungsleistungen aller TI-ITSM-Teilnehmer

2.2.3 Service-Verzeichnis

3 Servicekonzept

3.1 Begriffserläuterungen

3.1.1 TI-Service

3.1.2 Servicenehmer

3.2 Übergreifendes IT-Service-Management der TI

3.3 TI-ITSM-Teilnehmer

3.3.1 Definition

3.3.2 Produktverantwortung der TI-ITSM-Teilnehmer

3.3.3 Serviceverantwortung (SV) der TI-ITSM-Teilnehmer

3.4 Rollen im Betrieb

3.4.1 Allgemeine Rollen

3.4.1.1 Gesamtverantwortlicher TI (GTI)

3.4.1.2 Anbieter

3.4.1.2.1 Anbieterkonstellationen / Unterauftragnehmer

3.4.1.3 Betreiber

3.4.1.4 Hersteller

3.4.1.4.1 Hersteller dezentraler Produkte

3.4.1.4.2 Hersteller zentraler Produkte

3.4.1.5 Service Provider TI unterstützender Produkte

3.4.1.6 Drittanbieter

3.4.1.7 DVO

3.4.2 Rollen in der gematik

3.4.2.1 gematik-Test in der TU

3.4.3 (End-)Nutzer

3.4.3.1 Anwender (User)

3.4.3.2 Versicherte

3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen

3.4.4.1 Anbieter VPN-ZugD

3.4.4.2 Anbieter ePA-Aktensystem

3.4.4.3 Anbieter Service Monitoring

3.4.4.4 Anbieter Basis-Consumer

3.4.4.5 Anbieter KTR-Consumer

3.4.4.6 Anbieter KTR-AdV

3.4.4.7 Anbieter KOM-LE

3.4.4.8 Anbieter Weitere Anwendungen

3.4.4.9 Anbieter Anschlusspunkt am SGW/SZZP

3.4.4.10 Anbieter TI-Messenger

3.4.4.11 Hersteller Primärsysteme

3.4.4.12 Fachdienste VSDM

3.4.4.13 Anbieter Federation Master

3.4.4.14 Anbieter Sektoraler Identity Provider Kostenträger

3.4.4.15 Anbieter TI-Gateway

3.4.4.16 Hersteller Versicherten Frontend

3.4.4.17 Anbieter eHealth-CardLink

3.5 Servicemodell

3.5.1 Servicekomponenten

3.5.2 Servicezerlegung

3.5.3 Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]

3.6 Supportkonzept

3.6.1 Begriffserläuterungen

3.6.1.1 Supportverantwortung

3.6.1.2 Lösungsverantwortung

3.6.2 Rollen / Funktionen im TI-Support

3.6.2.1 User Help Desk (UHD)

3.6.2.2 Versicherten Help Desk (VHD)

3.6.2.3 1st Level Support

3.6.2.4 2nd / 3rd Level Support

3.6.2.5 Single-Point-of-Contact (SPOC) für TI-ITSM-Teilnehmer

3.6.3 Spezifische Ausprägungen

3.6.3.1 User Help Desk (Anwendersupport)

3.6.3.2 Versicherten Help Desk (Versichertensupport)

3.6.3.3 Erreichbarkeit TI-ITSM-Teilnehmer

3.6.3.4 Anbieter Federation Master

3.6.3.5 Anbieter Sektoraler Identity Provider für Kostenträger

3.6.3.6 Anbieter TI-Gateway

4 Verantwortlichkeiten und Leistungen TI-ITSM-Teilnehmer

4.1 Begriffserläuterungen

4.1.1 Anbietertypsteckbrief

4.2 Allgemeine Anforderungen

4.2.1 Allgemeine Anforderungen für TI-ITSM-Teilnehmer

4.2.2 Allgemeine Anforderungen nur für Anbieter von Diensten

4.3 Reporting

4.4 Monitoring

4.5 Datenaufbewahrung

5 Kenngrößen und Service Level

5.1 Begriffserläuterung

5.1.1 Organisatorische Service Level (vorgangsübergreifend)

5.2 Organisatorische Service Level

5.2.1 Begriffserläuterungen

5.2.1.1 Quantil / Erfüllungsgrad

5.2.1.2 Reaktionszeit

5.2.1.3 Lösungszeit

5.2.1.4 Verifikationsfrist

5.2.2 Spezifische Ausprägungen

5.3 Technische Service Level / Performance-Kenngrößen

5.3.1 Begriffserläuterungen

5.3.1.1 Technischer Kennzahlenkatalog

5.3.2 Spezifische Ausprägungen

5.3.2.1 Erläuterungen / Festlegungen

5.3.2.2 Performance-Größen-Schemata

5.3.2.3 TSP X.509 (PDT02, PDT03, PDT36, PDT38)

5.3.2.4 Signaturdienst (PDT47)

5.3.2.5 Federation Master (PDT70)

5.3.2.6 Identity Provider (PDT52, PDT68, PDT73)

5.3.2.7 VSDM-Fachdienst (PDT20, PDT23, PDT26)

5.3.2.8 Anwendung ePA (PDT43)

5.3.2.9 Anwendung E-Rezept (PDT50, PDT59)

5.3.2.10 National Contact Point for E-Health (PDT69)

5.3.2.11 VPN-Zugangsdienst (PDT09)

5.3.2.12 Kommunikation im Medizinwesen KOM-LE (PDT24, PDT27)

5.3.2.13 TI-Gateway-Zugangsmodul (PDT72)

5.3.2.14 TI-Messenger (PDT64)

5.3.2.15 Namensdienst (PDT06)

5.3.2.16 Intermediär VSDM (PDT21)

5.3.2.17 Trust Service Provider X.509 nonQES – Komponentenzertifikate (PDT37)

5.3.2.18 Trust Service Provider X.509 nonQES – CVC (PDT31)

5.3.2.19 OCSP-Responder-Proxy (PDT01)

5.3.2.20 TSL-Dienst (PDT04)

5.3.2.21 gematik Root-CA (PDT22)

5.3.2.22 Zeitdienst (PDT07)

5.3.2.23 Zentrales Netz der TI (PDT08)

5.3.2.24 Sicherheitsgateway für Bestandsnetze (PDT10)

5.3.2.25 Konfigurationsdienst (PDT11)

5.3.2.26 Verzeichnisdienst FHIR (PDT66)

5.3.2.27 Verzeichnisdienst (PDT25)

5.4 Zulassungsverfahren - Pönalisierung

6 Spezifische betriebsrelevante Ergänzungen

6.1 Identity Management

6.2 Konfigurationen von Produkten

6.3 Digitale Gesundheitsanwendungen (DiGA)

7 Anhang A – Performance-Kenngrößen

7.1 Definitionen

7.1.1 Produkttypen (PDT-IDs)

7.1.2 Performance-Dimensionen

7.1.3 Aufrufquelle

7.1.4 Zertifikatstypen

7.1.5 Schnittstellen::Operation / Anwendungsfall (altes Format - noch zu migrieren)

7.2 Performance-Größen

7.2.1 Dimension Last

7.2.2 Dimension Bearbeitungszeit

7.2.3 Dimension Verfügbarkeit

7.3 Performance-Kenngrößen (altes Format - noch zu migrieren)

8 Anhang B – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

8.5.2 Weitere Dokumente

 

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das Betriebskonzept legt die Servicearchitektur, Rollen des Betriebs, das Supportkonzept, Service Level und die Leistungen der Teilnehmer der Telematikinfrastruktur (TI) fest.

1.2 Zielgruppe

Das Dokument richtet sich an die am Betrieb der TI beteiligten Akteure: Anbieter von Betriebsleistungen in der TI (verkürzt hier Anbieter genannt) und die gematik in ihrer koordinierenden Rolle.

1.3 Geltungsbereich

Dieses Dokument trifft normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und die Anwendung der in ihr getroffenen Festlegungen in Zulassungsverfahren werden durch die gematik in gesonderten Dokumenten (z.B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Abgrenzung des Dokuments

Die technischen Leistungsvorgaben bzw. Servicequalitäten die dieses Dokument beschreibt, werden ergänzt durch die

• Verfügbarkeit und Performanceangaben zur TI [gemSpec_Perf],
• Produkttypspezifikationen und ihren Produkttypsteckbriefen,
• Servicekataloge
• Betriebsrichtlinie [gemRL_Betr_TI],
• Anbietertypsteckbriefe.

Normative Vorgaben zu Themen wie z. B. Zulassung, Test/Testbetrieb oder die Inbetriebnahme sind nicht Bestandteil dieses Dokumentes.

1.5 Methodik

1.5.1 Anforderungen

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

Anforderungen werden im Dokument wie folgt dargestellt:

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

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

2 Grundlagen des Betriebs

2.1 Gegenstand des Betriebskonzepts

Das Betriebskonzept beschreibt die Servicearchitektur (Servicekonzept/Supportkonzept) sowie die daraus resultierenden Verantwortlichkeiten und Aufgaben für die betrieblichen Rollen

2.2 Begriffserläuterungen

2.2.1 Business-Servicekatalog

Der Business-Servicekatalog enthält alle von einem TI-ITSM-Teilnehmer angebotenen Services mit Angabe der dazugehörenden Servicekomponenten. Es wird dargestellt, zu welchen Konditionen der jeweilige Service geliefert wird. Der Business-Servicekatalog wird im Rahmen des Service-Katalog-Managements vereinbart und anderen TI-ITSM-Teilnehmern über das TI-ITSM-System bereitgestellt.

Der Business-Servicekatalog wird in TIP1-A_6367-02 definiert.

Unterstützungsservices sind Leistungen, die für die Erbringung von Services Dritter notwendig sind.

2.2.2 Unterstützungsleistungen aller TI-ITSM-Teilnehmer

Aus Servicenehmersicht ist die Verbindlichkeit der zu leistenden Unterstützungsleistung anderer TI-ITSM-Teilnehmer entscheidend. TI-ITSM-Teilnehmer nehmen definierte Rollen in der TI (Anbieter-Rollen) wahr und müssen entsprechend ihrer Rolle definierte Services unterstützen.

Der Tabelle Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer kann entnommen werden, durch welche Anbieter-Rolle eine Unterstützungsleistung für welche Services erfolgt, diese nur optional erfolgt oder ob sie ausbleibt.

Die Unterstützungsleistungen gliedern sich auf in

• eigene Services (E)
• Unterstützungsservices (U)
• vermittelnde Unterstützungsservices (V) und
• optionale Unterstützung (O).

2.2.3 Service-Verzeichnis

In einem Service-Verzeichnis werden alle Service-Kataloge aller TI-ITSM-Teilnehmer zentral aufgeführt.

Jeder TI-ITSM-Teilnehmer nimmt am Service-Katalog-Management teil, um Änderungen seines Service-Kataloges gesteuert einzubringen und mit der gematik zu vereinbaren. In der Richtlinie Betrieb [gemRL_Betr_TI] wird dieser Prozess detailliert beschrieben.

3 Servicekonzept

Das Servicekonzept regelt die Verantwortlichkeiten der TI-ITSM-Teilnehmer.

Die verbindliche Zuordnung der Anforderung zu den TI-ITSM-Teilnehmern erfolgt im zugehörigen Steckbrief.

3.1 Begriffserläuterungen

3.1.1 TI-Service

TI-Services sind die durch die gematik beschlossenen IT-basierten Dienstleistungen der TI, welche in einem Release konzipiert und implementiert werden.

Ein TI-Service ist eine durch einen TI-ITSM-Teilnehmer erbrachte Dienstleistung in der TI. TI-Services können durch Servicenehmer in Anspruch genommen werden.

TI-Services können technisch durch den Betrieb zugelassener Produkte erbracht werden oder betrieblich durch Unterstützungsleitung im Support des UHD (Anwendersupport), VHD (Versichertensupport) oder SPOC im TI-ITSM.

3.1.2 Servicenehmer

Ein Servicenehmer nimmt eine Serviceleistung (TI-Service) eines TI-ITSM-Teilnehmers in Anspruch. Servicenehmer können andere TI-ITSM-Teilnehmer oder (End-)Nutzer sein.

3.2 Übergreifendes IT-Service-Management der TI

Das TI-ITSM "Übergreifende IT-Service-Management der TI" gewährleistet eine effektive Kommunikation der an der Serviceerbringung Beteiligten und ermöglicht so ein koordiniertes Vorgehen bei der Behebung von Störungen und bei der Durchführung von Änderungen an der TI.

Die Mitwirkung der Anbieter im TI-ITSM und die Bereitstellung der benötigten Schnittstellen sind ein wichtiger Bestandteil ihrer zu erbringenden Leistungen. Diese werden im Dokument „Übergreifende Richtlinien zum Betrieb der TI“ [gemRL_Betr_TI] beschrieben.

3.3 TI-ITSM-Teilnehmer

3.3.1 Definition

TI-ITSM-Teilnehmer sind Rollen bzw. konkrete Akteure, die im Rahmen der TI-ITSM-Prozesse eine aktive oder passive Tätigkeit übernehmen. Diese Tätigkeiten können je nach Rolle und Prozess unterschiedlich ausgeprägt sein. Rollen können daher agieren als Auslöser/Melder (A) - passiv und/oder Empfänger/Bearbeiter (E) - aktiv. 

Folgende allgemeine betrieblichen Rollen sind als TI-ITSM-Teilnehmer definiert:

• Anbieter der TI in jeweiliger Konstellation (siehe Kapitel  3.4.1.2.1 Anbieterkonstellationen / Unterauftragnehmer)
  • Anbieter ohne UA (Konstellation I)
  • Anbieter mit UA (Konstellation II)
  • Anbieter mit UA (Konstellation III)
  • Anbieter mit UA (Konstellation IV)
• Unterauftragnehmer (UA)
  • UA (Konstellation II)
  • UA (Konstellation III)
  • UA (Konstellation IV)
• Hersteller
  • Hersteller dezentraler Komponenten
  • Hersteller Primärsysteme
• Service Provider TI unterstützender Produkte
• Anbieter Weitere Anwendungen
• gematik Test
• gematik Betrieb
• Gesamtverantwortlicher TI

Betreiber sind in diesem Kontext Anbieter ohne UA (Konstellation I), UA (Konstellation II/III) und Anbieter mit UA (Konstellation IV) - siehe auch Kapitel 3.4.1.3 Betreiber.

Die Teilnahme der aufgeführten Hersteller und "Service Provider TI unterstützender Produkte" am TI-ITSM erfolgt in Absprache mit der gematik auf freiwilliger Basis. Falls eine Teilnahme vereinbart wird, muss eine entsprechende vertragliche Vereinbarung geschlossen werden (Nutzungsvereinbarung).

Herstellern, denen im Rahmen ihres Produkttypsteckbriefes die Anforderung [gemRL_Betr_TI#GS-A_3984] "Service Request zur Bereitstellung der TI-Testumgebung (RU/TU)" mittels des Prüfverfahrens "funktionale Eignung: Herstellererklärung" explizit zugeordnet wurde, sind im Kontext dieser Anforderung verpflichtend TI-ITSM-Teilnehmer.

Die Teilnahme von Anbietern bzw. Unterauftragnehmern am TI-ITSM wird über den Zulassungsvertrag/Zulassungsbescheid bzw. die "Bestätigung" verbindlich festgelegt.

Explizit von der TI-ITSM-Teilnahme ausgeschlossen sind:

• DVO
• Anwender
• Versicherte
• Drittanbieter
• Hersteller zentraler Produkte (sind über ihren zugeordneten Anbieter implizit eingebunden)

Die Definition gilt für alle Betriebsumgebungen und Betriebsphasen, insbes. für

• RU/TU - Inbetriebnahme/Zulassung
• PU - Betriebliche Anlaufphase (Feldtest)
• PU - Regelbetrieb

Die Rollen werden allgemein in Kapitel 3.4 Rollen im Betrieb beschrieben. Spezifische Ausprägungen dieser Rollen werden in Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen aufgeführt.

Die erforderlichen Mitwirkungspflichten der zugelassenen bzw. bestätigten Rollen sowie die Rollen der gematik werden in Tabelle Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer festgelegt. Die Zuordnung der für die TI-ITSM-Teilnehmer jeweils relevanten Anforderungen erfolgt über die jeweiligen Anbietertypsteckbriefe.

Tabelle 1: Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer

3.3.2 Produktverantwortung der TI-ITSM-Teilnehmer

TIP1-A_7263 - Produktverantwortung der TI-ITSM-Teilnehmer

Der TI-ITSM-Teilnehmer MUSS gewährleisten, dass sämtliche in seiner Verantwortung betriebenen Produkte und Produktversionen von der gematik zugelassen sind und der Betrieb dieser jederzeit zulassungskonform unter Erfüllung aller technischen, sicherheitstechnischen und betrieblichen Anforderungen erfolgt. [<=]

3.3.3 Serviceverantwortung (SV) der TI-ITSM-Teilnehmer

Die Serviceverantwortung liegt bei dem Anbieter bzw. Service Provider TI unterstützender Produkte des Services, unabhängig davon, ob er diese selbst betreibt, oder einen Betreiber/Unterauftragnehmer (unter-)beauftragt hat.

3.4 Rollen im Betrieb

Im Folgenden sind die für den Betrieb der TI relevanten Rollen, ihre Aufgaben und Verantwortlichkeiten dargestellt. Diese bilden die Grundlage für die Definition der TI-ITSM-Teilnehmer (siehe Kapitel 3.3.1 Definition).

Hinweis zum Folgerelease:

Nach § 75b Abs. 1 SGB V legen die Kassenärztlichen Bundesvereinigungen bis zum 30. Juni 2020 die Anforderungen zur Gewährleistung der IT-Sicherheit in der vertragsärztlichen und vertragszahnärztlichen Versorgung in einer Richtlinie fest. Die Kassenärztlichen Bundesvereinigungen müssen nach § 75b Abs. 5 SGB V zusätzlich Anbieter im Einvernehmen mit dem Bundesamt für Sicherheit in der Informationstechnik auf deren Antrag zertifizieren, wenn diese über die notwendige Eignung verfügen, um die an der vertragsärztlichen und vertragszahnärztlichen Versorgung teilnehmenden Leistungserbringer bei der Umsetzung der Richtlinie sowie deren Anpassungen zu unterstützen. Inhalt der Richtlinie sowie der Zertifizierung ist auch die sichere Installation und Wartung von Komponenten und Diensten der Telematikinfrastruktur. 

Die gematik wird nach Veröffentlichung der Vorgaben für die Zertifizierung prüfen, ob und welche Anbieter in der TI sie verpflichtet, bei der Ausführung ihrer Tätigkeiten nur zertifizierte Techniker einzusetzen.

In jedem Fall haben Leistungserbringer nach § 291b Abs. 6a SGB V das Recht, dass Dienstleister auf Verlangen ihre Fachkunde nachweisen.

Der Nachweis kann aus Sicht der gematik insbesondere durch die zuvor genannte Zertifizierung der Kassenärztlichen Bundesvereinigungen erbracht werden.

3.4.1 Allgemeine Rollen

3.4.1.1 Gesamtverantwortlicher TI (GTI)

Der Gesamtverantwortliche TI (GTI) übernimmt die

• Steuerungs- und Aufsichtsfunktion gegenüber Dienstleistern (IT-Governance)
• Definition der Rahmenbedingungen (z.B. Spezifikation, Test, Zulassung)
• Überwachung der Serviceerbringung (z.B. Service Monitoring, Risikomanagement).

Diese Rolle liegt bei der gematik. Dabei übernimmt die gematik keine operativen Betriebsleistungen. Diese Leistungen sind von den Anbietern zu erbringen.

3.4.1.2 Anbieter

Ein Anbieter von Betriebsleistungen in der TI im Verständnis des vorliegenden Dokumentes ist eine Organisation, die Services gegenüber anderen Servicenehmern anbietet und verantwortet. Ein Anbieter kann seine Services selbst erbringen oder durch Unterauftragnehmer erbringen lassen, jedoch verbleibt die Serviceverantwortung (SV) beim Anbieter selbst.

Anbieter koordinieren gegenüber ihren Servicenehmern im Rahmen ihrer Service- und Supportverantwortung die Hersteller der von ihnen angebotenen Produkte und nachgelagerte Anbieter.

A_20476 - Funktionalität, Interoperabilität, Sicherheit in der PU

Der Anbieter MUSS aktiv dabei unterstützen, dass das von ihm im Rahmen des Betriebs eingesetzte, von der gematik zugelassene Produkt, in der PU weiterhin sicher, interoperabel und funktional betrieben wird. [<=]

Sowohl nach der Zulassung des Produktes, als auch des Anbieters, können Fehler im Betrieb auftreten. Die Fehler können verschiedener Natur sein und Aspekte der Funktionalität, Sicherheit als auch der Interoperabilität betreffen. In solch einem Szenario liegt es im Bestreben aller Beteiligten, eine gemeinsame und übergreifende Lösung zu finden um die Nutzbarkeit des Dienstes wieder herzustellen. Die dafür notwendigen Werkzeuge um in den Dialog zu treten und den Fehler zu beheben stellen u.a. die Betriebsprozesse bereit (z.B. Incident-, Problem-, Change-Prozess).

Betriebliche Szenarien welche die Notwendigkeit einer aktiven Unterstützung erfordern können, sind z.B.

• Konfigurationsänderungen,
• sequentielle Zulassungen,
• zero-day Lücken.

Anbieter können im Rahmen ihrer Serviceerbringung eigenständig agieren oder betrieblich zusammen mit einem Unterauftragnehmer kooperieren. Hierbei werden vier mögliche Konstellationen unterschieden, die im Folgenden beschrieben werden.

3.4.1.2.1 Anbieterkonstellationen / Unterauftragnehmer

Anbieter operativer Betriebsleitungen können sich bei der Erbringung der Betriebsleistung oder Teilen hiervon eines Unterauftragnehmers (UA) bedienen.

Abbildung 1: Anbieterkonstellation

Die Beauftragung von Unterauftragnehmern durch den zugelassenen Anbieter bedarf der vorherigen Zustimmung der gematik und wird in den Zulassungsvertrag/Zulassungsbescheid aufgenommen.

Man unterscheidet zwischen vier Anbieterkonstellationen.

Die zugehörigen betrieblichen Rollen sind:

1. Anbieter ohne UA (I) - Anbieter ohne Unterauftragnehmer in Konstellation I
2. Anbieter mit UA (II) - Anbieter mit Unterauftragnehmer in Konstellation II
3. Anbieter mit UA (III) - Anbieter mit Unterauftragnehmer in Konstellation III
4. Anbieter mit UA (IV) - Anbieter mit Unterauftragnehmer in Konstellation IV
5. UA (II) - Unterauftragnehmer in Konstellation II
6. UA (III) - Unterauftragnehmer in Konstellation III
7. UA (IV) - Unterauftragnehmer in Konstellation IV

Die Anbieter in Konstellation I, II, III oder IV können vertraglich an die gematik gebunden sein mittels

• eines Zulassungsvertrags bzw. Zulassungsbescheids für zugelassene Anbieter,
• einer Bestätigung (z. B. Fachdienst VSDM),
• einer Beauftragung, die basierend auf einer Ausschreibung erfolgt, oder
• einer gematik internen Vereinbarung (z.B. Anbieter E-Rezept FdV).

Die Rollenbeschreibungen bzw. ihre Konstellationen sind unabhängig von der vertraglichen Bindung. Im Fall eines zugelassenen Anbieters sind im folgenden Details zur Zulassung konkretisiert. Eine Abbildung von Anbieter auf zugelassene Konstellationen findet sich in Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen.

Die Verantwortung für die Erfüllung der Regelungen des Vertrages gegenüber der gematik trägt auch im Falle der Beauftragung von Unterauftragnehmern weiterhin ausschließlich der zugelassene Anbieter.

Alle Anbieter und Unterauftragnehmer unabhängig von ihrer jeweiligen Konstellation sind TI-ITSM-Teilnehmer (siehe Kapitel 3.3.1 Definition). Die jeweiligen konkreten Mitwirkungspflichten können unterschiedlich ausgeprägt sein und werden im Servicemodell festgelegt.

Konstellation I (Normalfall):

Solange der Anbieter die Erfüllung der Anforderungen für den Betrieb seiner Produkte sowie für die Bereitstellung eines UHD bzw. VHD selbst übernimmt (falls spezifiziert gemäß Festlegung in Kapitel 3.6.3 Spezifische Ausprägungen, nimmt er die Konstellation I ein und ist TI-ITSM-Teilnehmer. Er erbringt die erforderlichen Nachweise selbst.

Konstellation II (Auslagerung Betrieb):

Der Anbieter kann sich bereits im Zulassungsverfahren durch seinen Unterauftragnehmer nach § 13 SGB X vertreten und die erforderlichen Nachweise wie z.B. Betriebshandbuch, Anbietererklärung und Prozessprüfung bereits durch diesen erbringen lassen. Dann nimmt der Anbieter die Konstellation II ein. Die zum Nachweis der Anforderungen für den User Help Desk (UHD) bzw. Versicherten Help Desk (VHD) (falls spezifiziert gemäß Festlegung in Kapitel 3.6.3 Spezifische Ausprägungen) erforderliche Anbietererklärung übernimmt der Anbieter selbst. Mit Abschluss des Zulassungsvertrages bzw. des Zulassungsbescheids verpflichtet sich der Anbieter sicherzustellen, dass sein Unterauftragnehmer gegenüber der gematik zur Abgabe aller erforderlichen Erklärungen sowie zur Durchführung aller tatsächlichen Handlungen berechtigt und verpflichtet ist, soweit diese zur Erbringung der Betriebsleistung erforderlich sind.

Dazu gehört auch die Teilnahme des Unterauftragnehmers an den TI-ITSM-Prozessen der gematik.

Konstellation III (Auslagerung Betrieb und UHD bzw. VHD) (falls spezifiziert gemäß Festlegung in Kapitel 3.6.3 Spezifische Ausprägungen):

Zusätzlich zur Konstellation II kann der zugelassene Anbieter auch einen zweiten (oder denselben) Unterauftragnehmer mit der Erfüllung der Anforderungen, welche die Bereitstellung des UHD bzw. VHD betreffen, beauftragen. Dann nimmt der Anbieter die Konstellation III ein. Die Erbringung der Nachweise der Anforderungen des Anbieters erfolgen wie in der Konstellation II – hierbei aber auch für den Betrieb des UHD bzw. VHD - mit der Besonderheit, dass die Nachweise für die gesamten Betriebsleistungen inklusive UHD bzw. VHD durch den Unterauftragnehmer im Zulassungsverfahren nach § 13 SGB X selbst erbracht werden können.

Auch in der Konstellation III ist der Unterauftragnehmer Teilnehmer an den TI-ITSM-Prozessen der gematik.

Konstellation IV (Auslagerung UHD bzw. VHD) (falls spezifiziert gemäß Festlegung in Kapitel 3.6.3 Spezifische Ausprägungen):

Der Anbieter in Konstellation IV kann seinen UHD bzw. VHD an einen Unterauftragnehmer mit der Erfüllung der Anforderungen, welche die Bereitstellung des UHD bzw. VHD betreffen, beauftragen. Die Betriebsleistung und die damit verknüpften Anforderungen verbleiben beim Anbieter. Die den UHD bzw. VHD betreffenden Anforderungen werden im Zulassungsverfahren nach § 13 SGB X durch den Unterauftragnehmer erfüllt.

Den Anbietern und Unterauftragnehmern ist je nach Konstellation ein definierter Anforderungshaushalt im Anbietertypsteckbrief zugeordnet. Der Unterauftragnehmer nimmt am TI-ITSM lediglich im Rahmen des Knowledge Managements teil.

3.4.1.3 Betreiber

Ein Betreiber ist eine natürliche oder juristische Person, die die Bereitstellung einer von der gematik zugelassenen bzw. bestätigten Komponente, eines Dienstes oder einer Anwendung der Telematikinfrastruktur erbringt und verantwortet.
Das Betreiben umfasst Tätigkeiten, wie das

• Bereitstellen der erforderlichen Betriebsmittel (z.B. Hardware),
• Anschließen von Betriebsmitteln an Betriebsmedien (wie z.B. Strom, Netzwerk, Klima),
• Starten und Aufrechterhaltung der technischen Betriebsprozesse und
• Einrichten, Konfigurieren, Inbetriebnahme und Überwachen der gewünschten Funktionalität, Verfügbarkeit und Sicherheit.

3.4.1.4 Hersteller

3.4.1.4.1 Hersteller dezentraler Produkte

Hersteller dezentraler Produkte stellen ein Produkt gemäß den Spezifikationen her und übernehmen die Produkthaftung gemäß den gesetzlichen Vorgaben und den Support gegenüber ihren Käufern. Hersteller unterscheiden sich von Anbietern insbesondere dadurch, dass das verantwortete Produkt keinen IT-Service darstellt, sondern physische Geräte oder Software, welche in der Hoheit der Anwender betrieben werden.

Produkte werden durch die gematik zugelassen. Mit dieser Zulassung wird zugleich die Verkaufsgenehmigung erteilt.

3.4.1.4.2 Hersteller zentraler Produkte

Als Hersteller zentraler Produkte gilt der Antragsteller zur Produktzulassung bei der gematik. Unter diesem Produkt wird ein physisches IT-Produkt verstanden, eine Software allein erfüllt die Anforderung an ein Produkt nicht. Das Produkt muss der gematik in einer konkreten Ausprägung vorliegen, welche den normativen Anforderungen an den Produkttypen genügt.

3.4.1.5 Service Provider TI unterstützender Produkte

"Service Provider TI unterstützender Produkte" stellen Anwendungen bzw. Werkzeuge, Dienstleistungen oder Produkte zur Verfügung, die die Nutzung und betriebliche Bereitstellung von Anwendungen der TI bzw. deren beteiligte TI-Produkte unmittelbar unterstützen.

Diese Service Provider stellen Werkzeuge, Dienstleistungen oder Produkte bereit, die

• die betrieblichen Abläufe unterstützen und aus Effizienzgründen direkt von anderen TI-ITSM-Teilnehmern im Rahmen der TI-ITSM-Prozesse adressiert werden sollen (z. B. Bereitstellung des Serviceportals seitens des AZPD oder des Testportals seitens der gematik),
• aufgrund der gesetzlichen Grundlage mit ihrer Dienstleistung die Bereitstellung von TI-Produkten unterstützen (z. B. Kartenherausgeber).

Zwischen der gematik und dem jeweiligen Service Provider TI unterstützender Produkte besteht eine entsprechende vertragliche Vereinbarung.

Für eine effiziente Kommunikation aller am TI-ITSM beteiligten Rollen ist es notwendig, dass der Service Provider TI unterstützender Produkte TI-ITSM-Teilnehmer ist und im Prozessablauf direkt von anderen TI-ITSM-Teilnehmern adressiert werden kann. Die Teilnahme erfolgt auf freiwilliger Basis. Die Regeln der Zusammenarbeit werden in einer entsprechenden Vereinbarung fixiert.

3.4.1.6 Drittanbieter

Drittanbieter unterstützen Anbieter und Unterauftragnehmer bei der Erbringung ihrer im Rahmen der TI definierten Dienstleistungen. Die vertragliche Vereinbarung zwischen beiden Parteien ist für die gematik intransparent. Nur der jeweilige Anbieter tritt unmittelbar mit der gematik in Kontakt. Drittanbieter sind keine TI-ITSM-Teilnehmer.

3.4.1.7 DVO

Dienstleister vor Ort (DVOs) sind natürliche Personen. Sie unterstützen den Anwender in allen Belangen hinsichtlich der TI. Sie lösen Probleme im dezentralen Bereich. Störungsmeldungen werden durch den DVO über den UHD des VPN-Zugangsdienstes qualifiziert weitergeleitet. Störungen und Probleme, die sich nur durch Unterstützung aus dem zentralen Bereich der TI lösen lassen, werden von ihnen entsprechend weitergeleitet.

Ihr Verantwortungsbereich wird durch einen individuell zwischen ihnen und dem Anwender ausgehandelten Vertrag geregelt. Bereits heute wird für die Betreuung von Praxen in vielen Fällen ein durch die Praxen beauftragter DVO eingesetzt. Die gematik geht davon aus, dass diese Vertragsverhältnisse mit Einführung der TI weiter bestehen.

3.4.2 Rollen in der gematik

3.4.2.1 gematik-Test in der TU

Die gematik (Test) ist für die Durchführung der Zulassungstests der Produkte in der TU zuständig. Produktiv zugelassene Anbieter müssen in der Referenzumgebung (RU) und Testumgebung (TU) Referenzen der betriebenen Produkte vorhalten. Bei Störungen der Referenzprodukte und Beeinträchtigung der Testdurchführung stellt die gematik in der Rolle „Test“ gegen die Anbieter der Referenzobjekte Tickets ein.

3.4.3 (End-)Nutzer

Ein (End-)Nutzer ist eine natürliche Person oder Organisation, die berichtigt ist, einen Service oder ein Produkt zu verwenden - im TI-Kontext ist dies die Nutzung von Anwendungen der TI. Im betrieblichen Umfeld wird zwischen Anwender und Versicherter unterschieden.

3.4.3.1 Anwender (User)

Anwender sind natürliche Personen oder Organisationen, welche die Services der TI nutzen und dadurch einen Mehrwert für sich oder ihren Geschäftsprozess erwarten. Anwender in diesem Sinne sind Leistungserbringer und Leistungserbringerinstitutionen.

Anwender im Kontext der TI sind für die bestimmungsgemäße Nutzung der Systeme verantwortlich. Insofern tragen sie die Betriebsverantwortung für die dezentralen Produkte. Handelt es sich beim Anwender um eine Organisation, z.B. ein Krankenhaus, trägt die Organisation die Betriebsverantwortung und nicht die einzelnen Anwender, welche die TI nutzen.

Hersteller von Primärsystemen können, ausgenommen der vorher genannten Betriebsverantwortung, als zusätzliche Anwender dem Nutzerkreis eines UHD hinzugefügt werden. 

Dem Anwender wird zur Unterstützung und Problemlösung ein UHD angeboten. Die Anbieter, die einen UHD bereitstellen müssen, werden explizit in Kapitel 3.6.3 Spezifische Ausprägungen aufgeführt.

3.4.3.2 Versicherte

Versicherte sind natürliche Personen, die einen Vertrag mit einer Versicherungsgesellschaft oder einem Versicherungsträger zur Abdeckung eines Risikos geschlossen haben. Im Kontext der TI sind dies gesetzlich krankenversicherte oder privat krankenversicherte Personen.

Für die Serviceunterstützung der Versicherten stellen einzelne Anbieter den Versicherten einen Versicherten Help Desk (VHD) zur Verfügung. Die Anbieter, die einen VHD bereitstellen müssen, werden explizit in Kapitel 3.6.3 Spezifische Ausprägungen aufgeführt.

3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen

Die spezifischen Ausprägungen der Rolle Anbieter werden in Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen zusammenfassend aufgeführt und in den weiteren Unterkapiteln bei Bedarf konkretisiert.

Tabelle 2: Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen

3.4.4.1 Anbieter VPN-ZugD

Für die Anbieter eines VPN-Zugangsdienst gelten die Konstellationen gemäß Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen abschließend. Der Anbieter kann sich zwischen diesen Konstellationen entscheiden und den Betrieb entweder selbst organisieren und alle Anforderungen des Anbietertypsteckbriefes selbst erfüllen. Alternativ kann er sich bereits im Zulassungsverfahren durch einen Unterauftragnehmer vertreten lassen und sich somit für die Konstellation II oder III entscheiden. Mit Abschluss des Zulassungsvertrages/Zulassungsbescheides verpflichtet sich dann der Anbieter sicherzustellen, dass sein Unterauftragnehmer gegenüber der gematik zur Abgabe aller erforderlichen Erklärungen sowie zur Durchführung aller tatsächlichen Handlungen berechtigt und verpflichtet ist, soweit diese zur Erbringung der Betriebsleistung erforderlich sind.

Der Anbieter VPN-Zugangsdienst stellt seinen Anwendern (Leistungserbringern) einen UHD zur Verfügung.

TIP1-A_6455 - Verpflichtung zur Dokumentation von Service Levels im Anwendersupport des Anbieters VPN-Zugangsdienst

Der Anbieter VPN-Zugangsdienst MUSS alle Service Levels im Anwendersupport im Rahmen der Zulassung dokumentieren und die gematik über Änderungen informieren. Hierbei MUSS der Anbieter VPN-Zugangsdienst eine Einteilung in eine oder mehrere verschiedene Serviceklassen (logische Gruppierungen von Service Levels in einer definierten Servicequalität, z. B. Gold, Silber, Bronze) vornehmen.

[<=]

Hinweis: Die gematik behält sich vor, die Information zu den Service Levels im Anwendersupport im Rahmen der Veröffentlichung der Zulassung mit zu veröffentlichen.

A_18430 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter VPN-Zugangsdienst

Der Anbieter VPN-Zugangsdienst MUSS alle für die Registrierung und den Verbindungsaufbau zur TI notwendigen Netzwerkinformationen (IP-Zieladressen und Ports) veröffentlichen und dem Gesamtverantwortlichen der TI bereitstellen. Der Anbieter VPN-Zugangsdienst MUSS diese veröffentlichten Informationen stets aktuell halten. [<=]

Die Veröffentlichung dieser Informationen durch den Anbieter kann über unterschiedliche Portale erfolgen, wie z.B. eigene Support-Portale oder die TI-Wissensdatenbank. Zielgruppe für die veröffentlichten Informationen sind sowohl die Leistungserbringer selbst als auch deren betreuende IT-Dienstleister.
Mit diesen Informationen sollen die lokalen Firewalls in den dezentralen Umgebungen der Leistungserbringer möglichst restriktiv konfiguriert werden können. Zeitgleich soll damit eine fehlerfreie Kommunikation der dezentralen TI-Komponenten mit der TI über Ihren VPN-Zugangsdienst sichergestellt werden.

3.4.4.2 Anbieter ePA-Aktensystem

Für den Anbieter ePA-Aktensystem dienen die in Kapitel 3.4.1.2.1 Anbieterkonstellationen / Unterauftragnehmer aufgeführten betrieblichen Konstellationen zur Orientierung – diese Optionen sind jedoch nicht abschließend. Der Anbieter kann entscheiden, in welcher Weise er den Betrieb organisiert. An dieser Stelle ist jedoch anzumerken, dass für die TI-ITSM-Prozesse nur ein einziger Dienstleister als TI-ITSM-Teilnehmer für den Anbieter im Zulassungsvertrag/Zulassungsbescheid eingetragen werden kann. Dieser erfüllt dann die in Kapitel 3.4.1.2.1 Anbieterkonstellationen / Unterauftragnehmer aufgeführten Berechtigungen und Verpflichtungen für den Anbieter. 

Der Anbieter ePA-Aktensystem stellt den Versicherten, denen eine elektronische Patienten-Akte zur Verfügung gestellt wird, einen VHD bereit. Der VHD kann von den gesetzlichen Krankenkassen realisiert werden. Mit Blick auf die Anzahl der Zulassungsverfahren und den damit verbundenen Aufwänden, ist, in Verbindung mit der aktuellen Betreiberstruktur, die Konstellation IV besonders attraktiv. In diesem Fall erwirkt der Betreiber der operativen Betriebsleistung die Zulassung als Anbieter ePA-Aktensystem (also der Aktensystembetreiber, nicht die Krankenkassen). Der Versicherten-Helpdesk (VHD) liegt jedoch nicht bei diesem Anbieter, sondern verbleibt, wie bisher, bei den Krankenkassen.

Für die Dauer der Datenmigration zwischen ePA2.x und ePA3.0 (ePA für alle) gilt die nachfolgende Besonderheit:
Der Anbieter ePA-Aktensystem ist für den Betrieb einer Instanz des Schlüsselgenerierungsdienstes SGD 1 (FAD) verantwortlich. Abgrenzend dazu ist der zentrale Schlüsselgenerierungsdienst SGD 2 (TIP) zu sehen, wie er auch separat in Tabelle: Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer dargestellt ist.

Sobald die Phase der Datenmigration abgeschlossen ist, entfällt die Verantwortung für den Betrieb des Schlüsselgenerierungsdienstes an Fachdienst (SGD1) als auch des zentralen Schlüsselgenerierungsdienstes SGD2. Näheres dazu regelt [gemSpec_Aktensystem_ePAfuerAlle].

3.4.4.3 Anbieter Service Monitoring

Der Anbieter Service Monitoring betreibt das Produkt gemäß [gemSpec_ServiceMon] und stellt die Messergebnisse und weitere Informationen dem GTI und definierten Teilnehmern zur Verfügung. Eine Unterstützung der beteiligten TI-ITSM-Teilnehmer ist dazu bereits bei der Initialisierung des Systems bzw. bei Einrichtung und Inbetriebnahme der Probes notwendig.

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. [<=]

Hinweis: Die Einrichtung und Inbetriebnahme finden im Rahmen des betrieblichen Change Managements statt.

3.4.4.4 Anbieter Basis-Consumer

Für diese Anbieter dienen die in Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen aufgeführten betrieblichen Konstellationen abschließend.
Abweichend der Darstellung im Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen stellen die Anbieter Basis-Consumer keinen Anwender- bzw. Versichertensupport zur Verfügung.

3.4.4.5 Anbieter KTR-Consumer

Für diese Anbieter dienen die in Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen aufgeführten betrieblichen Konstellationen abschließend.
Abweichend der Darstellung im Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen stellen die Anbieter KTR-Consumer keinen Anwender- bzw. Versichertensupport zur Verfügung.

3.4.4.6 Anbieter KTR-AdV

Der Anbieter KTR-AdV wird definiert als der von den Kassen beauftragte Betreiber. Dieser wird durch die Kassen beauftragt und bietet den Service den Versicherten an. Die Kassen werden deshalb nicht zusätzlich zugelassen und sind auch nicht im TI-ITSM vertreten. Abweichend der Darstellung im Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen stellen die Anbieter KTR-AdV keinen Anwender- bzw. Versichertensupport zur Verfügung.

3.4.4.7 Anbieter KOM-LE

Für die Anbieter Fachdienst KOM-LE sind die in Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen aufgeführten betrieblichen Konstellationen möglich. Im Rahmen des Betriebs ist mit der Anwendung sicherzustellen, dass ein eigener User Help Desk (UHD) zur Verfügung gestellt wird.

3.4.4.8 Anbieter Weitere Anwendungen

Als „Weitere Anwendung“ können Leistungserbringer die unterschiedlichsten Angebote von Drittanbietern, etwa aus der Gesundheitsforschung oder Industrie, über die Telematikinfrastruktur als primäre Plattform für eine sichere Vernetzung nutzen. Die Voraussetzung ist ein Bestätigungsverfahren für "WANDA" (kurz für: Weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur), das diese Dienste bei der gematik durchlaufen und erfolgreich absolvieren müssen.

Die Anwendungen können als Option "Smart" oder "Basic" angebunden werden. "WANDA Smart"-Nutzer können dabei auf zentrale Dienste der Telematikinfrastruktur zugreifen oder kryptografische Identitäten der TI für eigene Anwendungszwecke mit nutzen, wohingegen in der Anbindungsoption "WANDA Basic" der Anschluss an die TI ohne die Nutzung dieser Dienste möglich ist. Anbieter der Option "WANDA Smart Hosting" können ihre Anwendungen beim "Anbieter Zentrale Plattformdienste" hosten lassen. Dann entfallen Anforderungen an ein eigenes Sicherheitsgutachten, die durch das Sicherheitsgutachten des Anbieters Zentrale Plattformdienste abgedeckt werden und es gelten für diese Anbieter die Anforderungen des Anwendungstypsteckbriefes "WANDA Smart Hosting".

Die Anbieter WANDA dürfen bestehende sichere zentrale Zugangspunkte (SZZP) oder Sicherheitsgateways (SGW) anderer Anbieter mit nutzen oder werden zusätzlich in der Rolle "Anbieter Anschlusspunkt" innerhalb des Bestätigungsverfahrens der Weiteren Anwendung bestätigt, wenn sie selbst den SZZP/das SGW vom "Anbieter Zentrale Plattformdienste" bestellen und diesen nach den Anforderungen des "Anbietertypsteckbriefes Anbieter Anschlusspunkt" selbst betreiben.
Dabei ist es unerheblich, ob sie diesen Anschlusspunkt nur für sich, gemischt für sich und andere oder auch ausschließlich für andere Anbieter betreiben.

Der Betrieb des Anschlusspunktes (SZZP/SGW) ist nicht auf die Anwendung WANDA beschränkt. Es dürfen jedoch nur bestätigte Anwendungen oder zugelassene Dienste daran angeschlossen werden.

Aus den alten Bezeichnern "aAdG" + "aAdG-NetG-TI" wird die Marke WANDA Smart.
Aus dem alten Bezeichner "aAdG-NetG" wird die Marke WANDA Basic.

Die Anbieter WANDA Basic, WANDA Smart, WANDA Smart Hosting und Anbieter Anschlusspunkt sind im TI-ITSM vertreten.

3.4.4.9 Anbieter Anschlusspunkt am SGW/SZZP

Die Anbieter Anschlusspunkt werden innerhalb des Bestätigungsverfahrens Weiterer Anwendungen bestätigt. Dann dürfen diese Anbieter Anschlusspunkt den SZZP/SGW vom "Anbieter Zentrale Plattformdienste" bestellen und diesen nach den Anforderungen des Anbietertypsteckbriefes "Anbieter Anschlusspunkt" selbst betreiben - auch wenn noch keine Weitere Anwendung angeschlossen ist.

Der Anbieter Anschlusspunkt darf auch über denselben Anschlusspunkt andere, durch die gematik zugelassenen Produkte eines zugelassenen oder bestätigten Anbieters oder Betreibers anschließen.

Für jeden Anschlusspunkt ist genau ein Anbieter Anschlusspunkt verantwortlich. Im Zuge des betrieblichen Changemanagements und bei der Beantragung der Freischaltungen werden diese Rahmenbedingungen sichergestellt.
Der Anbieter Anschlusspunkt hat dafür Sorge zu tragen, dass nur bestätigte Anwendungen oder zugelassene Dienste an seinem Anschlusspunkt angeschlossen werden.

3.4.4.10 Anbieter TI-Messenger

Für den Anbieter TI-Messenger sind die in Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen aufgeführten betrieblichen Konstellationen möglich.
Die Betriebsverantwortung für die Produkte TI-Messenger-Fachdienst und TI-Messenger-Client, jeweils inkl. der Ausprägungen für Versicherte, liegt beim Anbieter TI-Messenger.

Im Kontext des TI-Messengers können Anwender z.B. KTR, LE, LEI und Versicherte sein (TI-M 1.x). Die Bereitstellung des TI-Messenger Dienstes für die Versicherten erfolgt dabei durch die jeweilige Krankenkasse (TI-M 2.x) über einen zugelassenen TI-Messenger Anbieter.

3.4.4.11 Hersteller Primärsysteme

Die Hersteller von Primärsystemen (z.B. PVS, ZPVS, APVS, KIS) können auf freiwilliger Basis gemäß der Nutzungsvereinbarung Teilnehmer am TI-ITSM-System werden. Sie verpflichten sich damit an den betrieblichen Prozessen der Definition in [gemKPT_Betr#Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM] teilzunehmen und die Anforderungen der gematik umzusetzen. Dabei verantworten sie ihre jeweiligen Primärsysteme und deren Funktionalität, Sicherheit und Interoperabilität im Zusammenspiel mit anderen Diensten und Komponenten der TI.

3.4.4.12 Fachdienste VSDM

Die Fachdienste VSDM werden für den Zeitraum der Auslieferung vom strukturierten Prüfungsnachweis (VSDM++), speziell ihre Servicezeiten im TI-ITSM auf den Samstag erweitern. 

3.4.4.13 Anbieter Federation Master

Die Grundidee der Föderation ist die Erstellung eines Vertrauensraumes, in dem mehrere Anwendungen und IDP's abgesichert über Vertrauensbeziehungen miteinander kommunizieren. Der Federation Master sorgt dafür, dass über alle Teilnehmer der TI-Föderation ein gemeinsamer Vertrauensraum aufgespannt wird. Alle Anwendungen der TI können dann alle sektoralen IDPs innerhalb der Föderation nutzen. Gleichzeitig können alle sektoralen IDPs den registrierten Anwendungen vertrauen. Damit sich nicht jede einzelne Anwendung mit deren Clients bei jedem einzelnen IDP registrieren muss, erfolgt die Registrierung zentral am Federation Master. Ebenso sicher erfolgt auch eine Erneuerung der Registrierungsinformationen bzw. eine Deregistrierung.

3.4.4.14 Anbieter Sektoraler Identity Provider Kostenträger

Unter einem Identity Provider (IDP) versteht man ein zentrales Zugangssystem, an welchem sich ein Nutzer authentisieren kann, um im Anschluss die angebundenen Fachanwendungen unmittelbar nutzen zu können. In diesem Kontext kommt dem IDP eine kritische Rolle zu, da dieser das Eingangstor zur Nutzung sämtlicher Fachanwendungen bereitstellt und somit maßgeblich zur gesamtheitlichen Nutzerakzeptanz der Dienste beiträgt. Neben der Backend-Komponente zur Verwaltung der Nutzeridentitäten (IDP) gehört ein Authenticator-Modul zum Gesamtumfang eines sektoralen IDP. Dieses kann entweder in eine App integriert sein oder als eigenstehende App bereitgestellt werden, um gemeinsam mit dem Backend die Authentisierung des Nutzers durchzuführen. Der erste Sektor ist der Sektor der Kostenträger (KTR). Weitere Sektoren (Leistungserbringer, Leistungserbringerorganisationen) folgen.

Die Grundidee der Föderation ist die Erstellung eines Vertrauensraumes, in dem mehrere Anwendungen und IDP abgesichert über Vertrauensbeziehungen miteinander kommunizieren. Grundlage für die Föderation sind die Standards für Autorisierung und Authentisierung von Anwendungen und Nutzern OAuth 2.0 und OIDC.

Erster Sektor, der in der Föderation IDPs stellt, ist der Sektor der gesetzlichen Krankenkassen.

• Um eine Gesamtlösung sicherzustellen, bei der Anwendungen in möglichst einfacher Weise die verschiedenen sektoralen IDP nutzen können, sind in bestimmten Bereichen einheitliche Vorgaben für die technische und organisatorische Umsetzung zu erstellen:
  • Einheitliche Identitätsattribute für die Nutzergruppen (scopes)
  • Einheitliche Verfahren zum Auffinden von sektoralen IDP (IDP Discovery)
  • Grundstruktur der Vertrauensbeziehungen der Föderierung (Zwischen Fachdiensten und IDP)
  • Einheitliche Vertrauensniveaus (Trust Framework).

Als zukünftige Erweiterung zur Authentisierung mit Smartcards in der TI 1.0, bei der die Identitäten in den Smartcards enthalten sind, werden zukünftig die Identitäten außerhalb der Smartcards in Identitätsprovidern (IDPs) abgelegt und von dort genutzt. Das ist von Vorteil, wenn weitere Identitätsmerkmale hinzukommen oder diese sich ändern. Das kann dann deutlich einfacher an zentraler Stelle, ohne Nutzerinteraktion erfolgen. Eine Synchronisation mit den (noch) in den Authentisierungsmitteln enthaltenen Identitätsmerkmalen ist nicht vorgesehen.

Die Anbieter der sektoralen Identity Provider für Kostenträger (sek IDP KTR) betreiben pro Krankenkasse (GKV und Unternehmen der PKV usw.) Mandanten in ihren Systemen. Nach der Ausprägung eines Mandanten mit seinen Endpunkten (aufrufbare Schnittstellen) ist der Dienst des Anbieters in der TI-Föderation nutzbar. Neben der Nutzung in der TI-Föderation steht der Dienst mit seinen Schnittstellen zusätzlich weiteren TI-Diensten und kassenindividuellen Anwendungen zur Verfügung und wird im Probing zur Verfügbarkeitsmessung herangezogen. Die Anbieter sek IDP KTR können diese Schnittstellen auch für kassenindividuelle Anwendungen bereitstellen, ohne diese Anwendungen in der TI-Föderation zu registrieren. Dazu verfügen die sek IDP KTR über eine zweite Liste mit eigenen Vertrauensbeziehungen. Es können dabei dieselben Schnittstellen verwendet werden, die für die Registrierung in der TI-Föderation verwendet und im Probing überwacht werden. Sollten weitere Schnittstellen angeboten werden, sind diese der gematik mitzuteilen.

Unabhängig davon, ob pro Mandanten eine neue physische Produktinstanz durch den Anbieter ausgeprägt wird oder ob der Anbieter ein Multi-Mandanten-System betreibt, wird jedem Anbieter pro Betriebsumgebung genau eine logische Produktinstanz zugeordnet.

3.4.4.15 Anbieter TI-Gateway

Für die Anbieter TI-Gateway gelten die Konstellationen gemäß Kapitel 3.4.4 Spezifische Ausprägungen und Verpflichtungen einzelner Rollen abschließend. Der Anbieter kann sich zwischen diesen Konstellationen entscheiden und den Betrieb entweder selbst organisieren und alle Anforderungen des Anbietertypsteckbriefes selbst erfüllen. Alternativ kann er sich bereits im Zulassungsverfahren durch einen Unterauftragnehmer vertreten lassen und sich somit für die Konstellation II oder III entscheiden. Mit Abschluss des Zulassungsvertrages/Zulassungsbescheides verpflichtet sich dann der Anbieter sicherzustellen, dass sein Unterauftragnehmer gegenüber der gematik zur Abgabe aller erforderlichen Erklärungen sowie zur Durchführung aller tatsächlichen Handlungen berechtigt und verpflichtet ist, soweit diese zur Erbringung der Betriebsleistung erforderlich sind.

A_23334 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter TI-Gateway

Der Anbieter TI-Gateway MUSS alle für die Registrierung und den Verbindungsaufbau zur TI notwendigen Netzwerkinformationen (IP-Zieladressen und Ports) veröffentlichen und dem Gesamtverantwortlichen der TI bereitstellen. Der Anbieter TI-Gateway MUSS diese veröffentlichten Informationen stets aktuell halten [<=]

Die Veröffentlichung dieser Informationen durch den Anbieter kann über unterschiedliche Portale erfolgen, wie z.B. eigene Support-Portale oder die TI-Wissensdatenbank. Zielgruppe für die veröffentlichten Informationen sind sowohl die Leistungserbringer selbst als auch deren betreuende IT-Dienstleister.
Mit diesen Informationen sollen die lokalen Firewalls in den dezentralen Umgebungen der Leistungserbringer möglichst restriktiv konfiguriert werden können. Zeitgleich soll damit eine fehlerfreie Kommunikation von dezentral mit der TI über Ihr TI-Gateway sichergestellt werden.

3.4.4.16 Hersteller Versicherten Frontend

Unter dem Begriff Hersteller Versicherten Frontend wird ein Hersteller einer App verstanden, welcher Funktionen gemäß den Spezifikationen der gematik in seine App integriert. Dieser Hersteller ist zur aktiven Teilnahme am TI-ITSM verpflichtet, um eine reibungslose Einbindung in die betrieblichen Prozesse zu gewährleisten und effektive Supportkanäle zu den verschiedenen Fachdiensten sicherzustellen. Sollte eine App von einer dritten Partei um Funktionen gemäß den Spezifikationen der gematik erweitert werden, so wird diese Partei im Sinne der Verantwortlichkeiten und Pflichten gleichbedeutend als Hersteller Versicherten Frontend angesehen.
Für den Hersteller des ePA-FdV KANN diese TI-ITSM-Pflicht entfallen, sofern ausschließlich die ePA-Funktionalität umgesetzt wird, da bereits der Hersteller des Aktensystems (als Konsortialpartner) die Pflichten im TI-ITSM wahrnimmt.

3.4.4.17 Anbieter eHealth-CardLink

Für den Anbieter eHealth-CardLink dienen die in Tabelle  "Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen" aufgeführten betrieblichen Konstellationen abschließend.

3.5 Servicemodell

Anhand der fachlogischen Abhängigkeiten werden die Servicebeziehungen zwischen allen TI-ITSM-Teilnehmern aufgezeigt und Anbieter und Servicenehmer benannt.

Ein Servicemodell ist eine übersichtsartige Beschreibung eines Service und der Komponenten, die zum Erbringen des Services erforderlich sind. Das wichtigste Ziel von Servicemodellen ist, zu verstehen, welche Service-Komponenten, Assets und sonstigen Ressourcen für die Erstellung eines Service notwendig sind, einschließlich deren gegenseitiger Abhängigkeiten. Servicemodelle sind ein wichtiges Werkzeug, um den Einfluss von Services auf andere Services zu erkennen.

TI-ITSM-Teilnehmer definieren alle Leistungen, die sie anderen Servicenehmern zur Verfügung stellen in einem Business-Servicekatalog.

Zur Sicherstellung der eigenen Serviceerbringung müssen TI-ITSM-Teilnehmer alle notwendigen Unterstützungsleistungen anderer TI-ITSM-Teilnehmer intern definieren. Diese werden außerhalb der zu veröffentlichenden Kataloge beschrieben.

Das ist nicht nur für die Serviceerbringung notwendig, sondern auch für die betriebliche Unterstützung bei Problemen, Störungen oder betrieblichen Anpassungen im Produktivbetrieb.

3.5.1 Servicekomponenten

Unter Servicekomponenten werden einzelne Einheiten verstanden, die für die Erbringung eines Service notwendig sind. Die Zerlegung der TI-Services in Servicekomponenten erfolgt durch die Art der Unterstützung. Alle Servicekomponenten eines Anbieters zusammengefasst ergeben den Service des Anbieters.

Die Tabelle "Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer" zeigt die differenzierten Mitwirkungspflichten von TI-ITSM-Teilnehmern bezüglich der unterstützenden Servicekomponenten (SK).

3.5.2 Servicezerlegung

TI-Services werden in Servicekomponenten zerlegt.

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.

[<=]

Tabelle 3: Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer 

Die Tabelle ist folgendermaßen lesbar: 

„Wenn eine Servicekomponente eingeschränkt ist, WER muss dann WIE unterstützen?“

Die Unterscheidung zwischen „U“ und „V“ ist in dieser Hinsicht wichtig, weil „V“ keine aktive operative Tätigkeit bedeutet, sondern das Aufnehmen der Störung und Weiterleiten an den Lösungsverantwortlichen. (klassisches Vermitteln=„V“)

E: eigener Service

Als eigener Service (E) wird der durch den Anbieter bestimmungsgemäß angebotene Service verstanden. Dieser kann einem konkreten Anbieter zugeordnet werden.

U: Unterstützungsservice

Als Unterstützungsservice (U) wird die aktive Mitwirkung für eigene und fremde Services bezeichnet, die für das Erbringen der eigenen Dienstleistung notwendig ist.

V: Vermittelnder Anwendungsservice

Als vermittelnder Anwendungsservice (V) wird die sonstige Mitwirkung für fremde Services bezeichnet, die auf Grundlage geltender Verpflichtungen für das Erbringen fremder Dienstleistungen notwendig ist.

O: Optionale Unterstützung

Als optionale Unterstützung (O) werden sämtliche freiwillige Unterstützungsleistungen gemäß vereinbarter Verträge verstanden.

In Tabelle "Tab_gemKPT_Betr_Servicekomponente" sind die für eine Servicekomponente verantwortlichen Service Provider (Eigener Service) sowie die mit der Servicekomponente unmittelbar assoziierten Produkttypen zusammengestellt. Ein Service Provider trägt die Serviceverantwortung für die jeweils aufgeführten Produkttypen.

Im Rahmen der Serviceerbringung können für einen Service Provider Ausschlusskriterien existieren. D.h. eine Organisation darf bei einem benannten Ausschluss nicht gleichzeitig Service Provider für eine Servicekomponente SK und der unter Anbieterausschluss aufgeführten Servicekomponente sein.

Die IDs der Produkttypen sind in Tabelle "Tab_gemKPT_Betr_Produkttypen"  aufgelistet.

Tabelle 4: Tab_gemKPT_Betr_Servicekomponente

Servicekomponente (SK)	Service Provider (Eigener Service)	Produkt- typ	Produkttyp- Name	Anbieter- ausschluss (SK)
Anbindung Bestandsnetze	n/a	n/a	n/a
Anschlusspunkt	Anbieter Anschlusspunkt SGW / SZZP	PDT57	Anschlusspunkt SGW/SZZP
Apothekenverzeichnis	Anbieter Apothekenverzeichnis	PDT59	Apothekenverzeichnis
Basis-Consumer	Anbieter Basis-Consumer	PDT45	Basis-Consumer
CVC Root-CA	Anbieter CVC-Root-CA	PDT32	CVC-Root
eHealth-CardLink	Anbieter eHealth-CardLink	PDT77	eHealth-CardLink	n/a
E-Rezept Fachdienst	Anbieter E-Rezept-Fachdienst	PDT50	E-Rezept-Fachdienst
E-Rezept Frontend des Versicherten	Anbieter E-Rezept FdV	PDT58, PDT51	E-Rezept-Anwendungen des Versicherten, E-Rezept-Frontend des Versicherten
ePA-Aktensystem	Anbieter ePA-Aktensystem	PDT43	ePA-Aktensystem	Identity Provider-Dienst
Fachdienst VSDM	Fachdienst VSDM	PDT20, PDT26, PDT23	Fachdienste VSDM (UFS), Fachdienste VSDM (CMS), Fachdienste VSDM (VSDD)
Federation Master	Anbieter Federation Master	PDT70	Federation Master
Highspeed Konnektor	Anbieter Highspeed Konnektor	PDT67	Highspeed Konnektor
IdP - Dienst	Anbieter IdP-Dienst	PDT52, PDT53	IdP - Dienst, Identity Provider - Authentisierungsmodul	ePA-Aktensystem
Initiale Integration SMC-B des LE	n/a	n/a	n/a	n/a
Intermediär VSDM	Anbieter ZPD	PDT21	Intermediär VSDM
KOM-LE	Anbieter Fachdienst KOM-LE	PDT24, PDT27	Fachdienst KOM-LE, KOM-LE-Clientmodul
Konfigurationsdienst	Anbieter ZPD	PDT11	Konfigurationsdienst
Konnektor Konfigurationsservice	n/a	n/a	n/a
KTR AdV	Anbieter SGD_ePA zentral	PDT35	KTR-AdV-Terminal
KTR-Consumer	Anbieter KTR-Consumer	PDT46	KTR-Consumer
Namensdienst	Anbieter ZPD	PDT06	Namensdienst
NCPeH-Fachdienst	Service Provider NCPeH-Fachdienst	PDT69	Fachdienst National Contact Point for eHealth
OCSP Responder Proxy	Anbieter SMC-B / HSM-B, Anbieter X.509 TSP eGK, Anbieter HBA, Anbieter ZPD	PDT01	OCSP-Proxy
Sektoraler Identity Provider KTR	Anbieter Sektoraler Identity Provider Kostenträger	PDT73	Sektoraler Identity Provider - Kostenträger
Sektoraler Identity Provider V1.0	Anbieter Sektoraler Identity Provider	PDT68	Sektoraler Identity Provider
Service Monitoring	Anbieter Service Monitoring	PDT41	Servicemonitoring
SGD ePA am FD	Anbieter ePA-Aktensystem	PDT48	Schlüsselgenerierungsdienst ePA	SGD ePA zentral
SGD ePA zentral	Anbieter SGD_ePA zentral	PDT48	Schlüsselgenerierungsdienst ePA	SGD ePA am FD
Sicherer Internetzugang	Anbieter VPN-Zugangsdienst	n/a	n/a
Signatur und Verschlüsselung	Anbieter Signaturdienst	n/a	n/a
Signaturdienst	Anbieter Signaturdienst	PDT47	Signaturdienst
TI-Gateway	Anbieter TI-Gateway	PDT72 PDT67 PDT21	TI-Gateway-Zugangsmodul Highspeed Konnektor Intermediär VSDM	n/a
TI-Messenger Client	Anbieter TI-Messenger	PDT65	TI-Messenger Client
TI-Messenger Fachdienst	Anbieter TI-Messenger	PDT64	TI-Messenger Fachdienst
TSL Dienst	Anbieter ZPD	PDT04	TSL-Dienst
TSP CVC	Anbieter CVC TSPs für eGK, Anbieter ZPD, Anbieter HBA, Anbieter SMC-B / HSM-B	PDT31	Trust Service Provider CVC
TSP X.509	Anbieter SMC-B / HSM-B, Anbieter X.509 TSP eGK, Anbieter ZPD, Anbieter HBA	PDT38, PDT37, PDT36, PDT03, PDT02	Trust Service Provider X.509 nonQES - SMC-B, Trust Service Provider X.509 nonQES - Komponentenzertifikate, Trust Service Provider X.509 (nonQES) - HBA, Trust Service Provider X.509 (nonQES) - eGK, Trust Service Provider X.509 QES
Verzeichnisdienst	Anbieter ZPD	PDT25	Verzeichnisdienst
VZD FHIR Directory	Anbieter ZPD	PDT66	Verzeichnisdienst FHIR
Weitere Anwendungen	WANDA Basic, WANDA Smart, WANDA Smart-Hosting	PDT56, PDT54, PDT55	WANDA Basic, WANDA Smart, WANDA Smart Hosting
X.509 Root CA	Anbieter ZPD, Anbieter X.509 Root-CA	PDT22	gematik Root-CA
Zeitdienst	Anbieter ZPD	PDT07	Zeitdienst
Zentrales Netz	Anbieter ZPD	PDT08	Zentrales Netz der TI
Zugang zur TI	Anbieter ZPD, Anbieter TI-Gateway, Anbieter VPN-Zugangsdienst	PDT09 PDT08	VPN-Zugangsdienst Zentrales Netz der TI

3.5.3 Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]

Aufgrund der Mitwirkungs- und Unterstützungsverpflichtungen gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer besteht eine übergreifende Mitwirkungspflicht am TI-ITSM der gematik.

Folgende Tabelle zeigt die Mitwirkungsverpflichtung in den aufgeführten ITIL-Betriebsprozessen der gematik gemäß Richtlinie Betrieb [gemRL_Betr_TI]:

Tabelle 5: Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM 

Die Prozesse Servicekatalog Management und Continual Service Improvement sind auf den beauftragten Anbieter beschränkt und werden in nicht-öffentlichen Dokumenten geregelt.

Legende:

INC: Incident Management

PRO: Problem Management

CHG: Change Management

SKM: Servicekatalog Management

SLM: Service Level Management

RF: Request Fulfillment

Perf: Perfomance Management

CapM: Capacity Management

KM: Knowledge Management

CSI: Continual Service Improvement

CM: Configuration Management

NF: Notfall Management

A: Auslöser in INC, PRO, CHG

Auslöser (A) ist, wer Incidents, Problems oder Changes eröffnet.

E: Empfänger von INC, PRO, CHG

Empfänger (E) ist wer Incidents, Problems oder Changes zugewiesen bekommt und dessen vollständige Mitarbeit gewährleistet ist.

Auslöser und Empfänger im SKM

Auslöser (A) ist, wer Änderungen im Service Katalog Management einbringt.

Empfänger (E) ist, wer Änderungen im Service Katalog Management aufnimmt.

Portalanbieter (P) ist, wer das TI-Service-Portal zur Verfügung stellt und selbst Nutzer ist.

A/E: Auslöser und Empfänger im SLM

Auslöser (A) ist, wer Änderungen im Servicelevel Management einbringt.

Empfänger (E) ist, wer im Servicelevel Management an Servicelevel-Reviews teilnimmt.

A/E: Auslöser und Empfänger im RF

Auslöser (A) ist, wer Services bei anderen Anbietern abruft.

Empfänger (E) ist, wer einen Servicekatalog führt und Services anbietet.

A/E: Auslöser und Empfänger im Perf

Auslöser (A) ist, wer Performancereports bzw. Rohdaten-Performance-Berichte sendet.

Empfänger (E) ist die gematik.

A/E: Auslöser und Empfänger im CapM

Auslöser (A) ist, wer Kapazitätspläne führt und reportet.
Empfänger (E) ist die gematik (GTI).

A/E: Auslöser und Empfänger im KM

Auslöser (A) ist, wer Artikel in der Wissensdatenbank einstellt.

Empfänger (E) ist, wer Artikel aus der Wissensdatenbank bezieht.

A/E: Auslöser und Empfänger im CSI

Auslöser (A) ist, wer ein CSI-Register führt und reportet.
Empfänger (E) ist die gematik (GTI).

A/E: Auslöser und Empfänger im CM

Auslöser (A) ist, wer Reports sendet, in denen die Konfigurationen der verwendeten Produkte dargestellt werden.

Empfänger (E) ist, wer Konfigurationsvorgaben und deren Umsetzung dar z.B. im Zuge eines CRs oder Changes empfängt und umsetzt.

A/E: Auslöser und Empfänger im NM

Aktiv (A) ist, wer im Notfall zuarbeiten und unterstützen muss.

Empfänger (E) stellen einen Notfall-Ansprechpartner bereit.

3.6 Supportkonzept

Aufbauend auf der Servicearchitektur wird nachfolgend das Supportkonzept beschrieben.

3.6.1 Begriffserläuterungen

3.6.1.1 Supportverantwortung

Der Begriff soll ausschließlich im Zusammenhang mit dem 1st-Level-Support benutzt werden und bezieht sich auf die verantwortliche Koordination bei der Behebung einer Störung: Wenn ein Anwender eine Störung an einen 1st-Level-Support meldet, die dieser selbst nicht beheben kann, dann verantwortet der 1st-Level-Support Koordination.

3.6.1.2 Lösungsverantwortung

Die Lösungsverantwortung wird entweder durch den 1st-Level-Support selbst wahrgenommen, wenn sich die Störung innerhalb des 1st-Level-Supports lösen lässt, oder sie wird durch den 1st-Level-Support (Supportverantwortlicher) an den für die Servicekomponente verantwortlichen Anbieter delegiert.

3.6.2 Rollen / Funktionen im TI-Support

3.6.2.1 User Help Desk (UHD)

Der UHD verantwortet die Behebung von Störungen, die von Anwendern gemeldet werden. Ebenfalls gehört die Bearbeitung von allgemeinen Anfragen der Anwender zu den Services des Anbieters zum Leistungsumfang seines UHD. Liegt die Lösungsverantwortung nicht bei dem den UHD bereitstellenden Anbieter, erfolgt eine Weitergabe des Tickets über den SPOC an den lösungsverantwortlichen Anbieter über das TI-ITSM-System. Der Anwender erhält nach Lösung seiner Störung über seinen UHD eine Rückantwort.

3.6.2.2 Versicherten Help Desk (VHD)

Der VHD verantwortet die Behebung von Störungen, die von Versicherten gemeldet werden. Liegt die Lösungsverantwortung nicht bei dem den VHD bereitstellenden Anbieter, erfolgt eine Weitergabe des Tickets über den SPOC an den lösungsverantwortlichen Anbieter über das TI-ITSM-System. Der Versicherte erhält nach Lösung seiner Störung über seinen VHD eine Rückantwort.

3.6.2.3 1st Level Support

Der Begriff 1st Level Support bezieht sich auf die Entgegennahme von Meldungen/Anfragen von Anwendern im Rahmen einer vorhandenen Supportverantwortung gegenüber dem Melder. Im 1st Level Support erfolgt eine Qualifizierung der Meldung und wird - wenn möglich - eine Lösung gefunden bzw. die qualifizierte Meldung an den 2nd Level Support weitergeleitet (siehe [gemRL_Betr_TI]).

3.6.2.4 2nd / 3rd Level Support

2nd/3rd Level Support sind unter einem Single-Point-Of-Contact (SPOC) erreichbar, den jeder Anbieter bereitstellt.

Der Begriff 2nd/3rd Level Support bezieht sich auf die Herbeiführung einer Lösung/ Beantwortung von Anfragen durch den 1st Level Support.

Dazu koordiniert der zuständige Anbieter seine produktverantwortlichen Anbieter/Hersteller und Drittanbieter.

3.6.2.5 Single-Point-of-Contact (SPOC) für TI-ITSM-Teilnehmer

Jeder Anbieter benennt übergreifend für die von ihm zu verantwortenden Servicekomponenten einen Single-Point-of-Contact (SPOC) gegenüber allen anderen TI-ITSM-Teilnehmern. Über den SPOC erfolgt der erforderliche wechselseitige Support der Anbieter in der TI über das TI-ITSM-System.

3.6.3 Spezifische Ausprägungen

In Tabelle Tab_KPT_Betr_TI_Anbieter_UHD/VHD sind alle Anbieter von UHDs und VHDs mit ihren jeweiligen Erreichbarkeiten zusammengestellt.

Tabelle 6: Tab_KPT_Betr_TI_Anbieter_UHD/VHD

* [außer an bundeseinheitlichen Feiertagen]

3.6.3.1 User Help Desk (Anwendersupport)

TIP1-A_7260-01 - Mindesterreichbarkeitszeiten im Anwendersupport (09:00-17:00 Uhr)

Alle TI-ITSM-Teilnehmer, denen lt. TIP1-A_7266 ein UHD von 09:00 - 17:00 Uhr zugeordnet ist, MÜSSEN im Anwendersupport die gleichen Mindesterreichbarkeitszeiten einhalten:
Mo – Fr 09:00 – 17:00 Uhr im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen]. [<=]

A_19532-01 - Erreichbarkeitszeiten im Anwendersupport (24/7)

Alle TI-ITSM-Teilnehmer, denen lt. TIP1-A_7266 ein UHD 24/7 zugeordnet ist, MÜSSEN im Anwendersupport die Erreichbarkeitszeiten von 24/7 einhalten:
Mo – So 0:00 – 24:00 Uhr. [<=]

TIP1-A_6420-03 - Erreichbarkeit der 1st-Level-UHDs

Der 1st-Level-UHD eines Anbieters VPN-Zugangsdienst MUSS folgende Mindestservicezeiten nach Tab_KPT_Betr_TI_044 unterstützen.

Tabelle 7: Tab_KPT_Betr_TI_044 Mindestservicezeit Störungsmeldungen und Anfragen

[<=]

3.6.3.2 Versicherten Help Desk (Versichertensupport)

A_16217-01 - Mindesterreichbarkeitszeiten im Versichertensupport (09:00-17:00 Uhr)

Alle TI-ITSM-Teilnehmer, denen lt. TIP1-A_7266 ein VHD von 09:00 - 17:00 Uhr zugeordnet ist, MÜSSEN im Versichertensupport die gleichen Mindesterreichbarkeitszeiten einhalten:
Mo – Fr 09:00 – 17:00 Uhr im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen]. [<=]

A_20733-03 - Mindesterreichbarkeitszeiten im Versichertensupport (07:00-22:00 Uhr)

Alle TI-ITSM-Teilnehmer, denen lt. TIP1-A_7266 ein VHD von 07:00 - 22:00 Uhr zugeordnet ist, MÜSSEN im Versichertensupport die gleichen Mindesterreichbarkeitszeiten einhalten:
Mo – Fr 07:00 – 22:00 Uhr [außer an bundeseinheitlichen Feiertagen]. [<=]

A_20734-01 - Mindesterreichbarkeitszeiten im Versichertensupport (08:00-20:00 Uhr)

Alle TI-ITSM-Teilnehmer, denen lt. TIP1-A_7266 ein VHD von 08:00 - 20:00 Uhr zugeordnet ist, MÜSSEN im Versichertensupport die gleichen Mindesterreichbarkeitszeiten einhalten:
Mo – Fr 08:00 – 20:00 Uhr [außer an bundeseinheitlichen Feiertagen]. [<=]

A_20111 - Erreichbarkeit des Versicherten Help Desk (VHD)

Alle TI-ITSM-Teilnehmer, die lt. TIP1-A_7266 einen VHD besitzen MÜSSEN sicherstellen, dass ihre verantworteten HelpDesks
•    innerhalb der vereinbarten Servicezeiten elektronisch und telefonisch
•    außerhalb der vereinbarten Servicezeiten elektronisch
erreichbar sind. [<=]

3.6.3.3 Erreichbarkeit TI-ITSM-Teilnehmer

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. [<=]

3.6.3.4 Anbieter Federation Master

Der Anbieter Federation Master hat keine eigenen Endkunden (Versicherte oder Leistungserbringer). Er betreibt den Federation Master, welcher für die Föderation elementar wichtig ist. Bei Störungen ist der Anbieter Federation Master über das TI-ITSM 24/7 erreichbar.

3.6.3.5 Anbieter Sektoraler Identity Provider für Kostenträger

Der Anbieter Sektoraler Identity Provider (Sektor KTR) (Anbieter sektoraler IDP KTR) agiert im Auftrag der gesetzlichen Krankenkassen (Mandanten des IDP).
Der Regelung "Jedem Nutzer einer Anwendung ist ein Ansprechpartner zugeordnet" folgend sind die gesetzlichen Krankenkassen Ansprechpartner der Versicherten. Dieses Angebot der Ansprechbarkeit ist einheitlich von den gesetzlichen Krankenkassen geäußert und gewünscht.

Eine konkrete Regelung hierzu liegt außerhalb der Regelungshoheit der gematik. Demzufolge wird hier keine Anforderung formuliert.

Die Kommunikation zwischen gesetzlichen Krankenkassen und deren IDP erfolgt in einem lokalem ITSM - nicht über das TI-ITSM der gematik.

Der Anbieter Sektoraler Identity Provider (Sektor KTR) muss keinen VHD und keinen UHD stellen.

A_23201 - Betriebliche Konstellation des sektoralen IDP

Der Anbieter sektoraler IDP MUSS die „Konstellation I“ gemäß [gemPKT_Betr #„Anbieterkonstellationen“] einnehmen und somit den Betrieb selbst durchführen.
Der Anbieter sektoraler IDP MUSS keinen Versichertenhelpdesk (VHD) zur Verfügung stellen.
Der Anbieter sektoraler IDP MUSS keinen User Helpdesk (UHD) zur Verfügung stellen.

Hinweis:
Der Betreiber eines sektoralen IDP stellt den Anbieterzulassungsantrag bei der gematik und nimmt somit die Rolle "Anbieter sektoraler IDP" ein. 
Ansprechpartner der Versicherten ist die Krankenkasse.
In allen Konstellation [gemPKT_Betr #„Anbieterkonstellationen“] wird der Betrieb nicht zerteilt. Das heißt, es gibt immer genau einen Verantwortlichen für den Betrieb.
Dieser Verantwortliche muss bezüglich des Betriebs ein uneingeschränktes Direktions- und Weisungsrecht haben, welches auch auf mögliche Unterauftragnehmer wirkt.
Dieser Verantwortliche ist im hier vorliegenden Fall der Anbieter des sektoraler IDP.
Eine Situation, in welcher die Betriebsleistung ausschließlich durch Unterauftragnehmer erbracht wird, ist in "Konstellation I" [gemKPT_Betr #„Anbieterkonstellationen“] ausgeschlossen.
Für alle ITIL-Prozesse (z.B. INC, PRO, CHG, ... ) und für zu erbringende Leistungen (RCA, Service Level, Audits, ...) ist aus gematik-Sicht der Verantwortliche alleiniger single point of contact (SPOC).
Das Verbot der Auslagerung des Betriebs hat auch zum Hintergrund, dass der Zulassungsnehmer grundsätzlich über dieses Direktions- und Weisungsrecht verfügen muss.
Mögliche Verzögerungen im Störungsfall durch Kommunikationsübergänge zu Unterauftragnehmern fallen zulasten des Anbieters.
Der Antragsteller informiert die gematik über die Unterauftragnehmer gemäß gemSpec_IDP_Sek#A_23411. [<=]

A_23411 - Nennung der Unterauftragnehmer des Anbieters

Der Anbieter MUSS der gematik seine Unterauftragnehmer zum Zeitpunkt der Antragsstellung auf Anbieterzulassung mitteilen.
Bei Änderungen (Hinzukommen / Wegfall) der Unterauftragnehmer MUSS der Anbieter die gematik informieren.
Die gematik behält sich in begründeten Einzelfällen das Recht vor, einzelne Unterauftragnehmer vom Betrieb auszuschließen.
Hinweis:
Dieses Widerspruchsrecht ist begründet aus Verstößen gegen Anforderungen oder gesetzlichen Regelungen (z.B. Verstoß gegen gemSpec_IDP_Sek#A_23099).
Um Problemen vorzubeugen, ist eine rechtzeitige Information sinnvoll. [<=]

3.6.3.6 Anbieter TI-Gateway

A_23335 - Verpflichtung zur Dokumentation von Service Levels im Anwendersupport des Anbieters TI-Gateway

Der Anbieter TI-Gateway MUSS alle Service Levels im Anwendersupport im Rahmen der Zulassung dokumentieren und die gematik über Änderungen informieren. Hierbei MUSS der Anbieter TI-Gateway eine Einteilung in eine oder mehrere verschiedene Serviceklassen (logische Gruppierungen von Service Levels in einer definierten Servicequalität, z. B. Gold, Silber, Bronze) vornehmen. [<=]

4 Verantwortlichkeiten und Leistungen TI-ITSM-Teilnehmer

4.1 Begriffserläuterungen

4.1.1 Anbietertypsteckbrief

Für jeden TI-ITSM-Teilnehmer gibt es jeweils einen Anbietertypsteckbrief in dem die Anforderungen an sie beschrieben sind. Die Anforderungen stammen aus den Betriebsdokumenten (gemKPT_Betr, gemRL_Betr_TI).

Für die Anbieter weiterer Anwendungen gibt es davon abweichend einen Anwendungssteckbrief, in welchem die an ihn gerichteten Anforderungen beschrieben sind. Die betrieblichen Anforderungen stammen aus den Betriebsdokumenten (gemKPT_Betr, gemRL_Betr_TI).

4.2 Allgemeine Anforderungen

4.2.1 Allgemeine Anforderungen für TI-ITSM-Teilnehmer

Definition von Serviceleistungen

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. [<=]

Überwachung

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.
[<=]

Erreichbarkeit UHD, Meldungsquittung, Status, Weiterleitung

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. [<=]

Koordination von Serviceleistung

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. [<=]

Auskunftsfähigkeit bei Servicebeeinträchtigungen

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. [<=]

Mögliche Auslöser eines solchen Verdachtsmomentes sind Events aus dem Service Monitoring der TI, bereits vorliegende Incidents oder Häufungen von nutzerseitigen Meldungen mit inhaltlich ähnlicher Aussage.

4.2.2 Allgemeine Anforderungen nur für Anbieter von Diensten

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. [<=]

4.3 Reporting

Zum Zwecke der monatlichen Bewertung der Service Level müssen die von den TI-ITSM-Teilnehmern zu erfassenden und zu übermittelnden technischen Performancekenngrößen vollständig vorliegen. Die Übermittlung der dafür notwendigen Daten erfolgt entweder

• im Rahmen der Rohdatenlieferung (auch Rohdaten-Performance-Berichte) gemäß gemSpec_Perf Kapitel 2.5 oder
• im Rahmen der Übermittlung von Performance-Berichten (auch Performance-Reports)

A_18238-01 - Service Level - Übermittlung von Performance-Reports

TI-ITSM-Teilnehmer, die technische Performance-Kenngrößen in Performance-Reports liefern, MÜSSEN den Report spätestens zum 5. Werktag des auf den Berichtszeitraum folgenden Monats vollständig sowie sachlich und inhaltlich korrekt übermitteln. [<=]

Jeder TI-ITSM-Teilnehmer muss die Werte der von ihm zu verantwortenden Service Level bereitstellen, d.h. prüfen, ggf. erfassen, bewerten, kommentieren und für die weitere Verarbeitung im TI-ITSM-System freigeben (siehe [gemRL_Betr_TI#9.2.2]). Für das technische und/oder organisatorische Service Level-Reporting stellt der Gesamtverantwortliche der TI eine Reportingschnittstelle im TI-ITSM-System zur Verfügung. 

Die Bereitstellung kann vom TI-ITSM-Teilnehmer erst dann vorgenommen werden, wenn der betreffende Service Level-Report im TI-ITSM-System zur Verfügung steht. Es ist beabsichtigt, den Service Level-Report spätestens zum 10. Werktag des auf den Bewertungszeitraum folgenden Kalendermonats zur Verfügung zu stellen, so dass jedem TI-ITSM-Teilnehmer mindestens eine Frist von drei Werktagen zur Bereitstellung seiner Service Level verbleibt.

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. [<=]

Die Erfüllung der Reporting-Anforderungen [A_18238-01 sowie A_18240] wird pro Anforderung im monatlichen Service-Level-Review-Meeting ausgewiesen. 

A_24800 - Reporting - Serviceaufkommen

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

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

4.4 Monitoring

Zur Sicherstellung der vorgeschriebenen / vereinbarten Verfügbarkeit und Minimierung von Ausfallzeiten werden die  Produkte / Services u.A. im Rahmen der Betriebsüberwachung durch die gematik beobachtet (z.B. Probing oder Performance-Rohdaten-Reporting). Der Anbieter eines Dienstes ist dabei in der Lage, Störung zu erkennen, noch bevor dies im Rahmen der Betriebsüberwachung detektiert wird. Um die Störungsbeseitigung frühestmöglich einzuleiten und die Störungsdauer somit auf ein Minimum zu reduzieren, ist es notwendig, dass der Anbieter die von ihm verantworteten Systeme und Dienste bereits selbst beobachtet und im Falle einer Störung oder beim Auftreten von Besonderheiten oder Anomalien angemessen reagiert.

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 Rohdatenlieferung zugrunde liegt. In diesem Zusammenhang sind mindestens die in gemSpec_Perf für die Rohdatenlieferung 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 (z.B. plötzlicher Anstieg der Fehlerraten) oder das Verhalten der Systemumgebung (z.B. 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. [<=]

A_24609 - Anforderungskriterien an das Anomalie-Erkennungssystem

Der Anbieter MUSS sicherstellen, dass das Anomalie-Erkennungssystem die Berechnungen von Anomalien und Auffälligkeiten auf Grundlage eines Zeitraums von mindestens 3 Wochen bemisst und die Werte auf einem Zeitraum von 5 Minuten gemittelt werden.
Der Anbieter MUSS sicherstellen, dass das Anomalie-Erkennungssystem mindestens die wichtigsten Anwendungsfälle überwacht und eine hohe Genauigkeit und Zuverlässigkeit aufweist, was bedeutet das so wenig wie möglich falsch-positive oder falsch-negative Ergebnisse geliefert werden sollen.
Das Anomalie-Erkennungssystem MUSS im laufenden Betrieb kontinuierlich verbessert werden, um sich flexibel an die stetigen Veränderungen in der Telematikinfrastruktur (TI) anzupassen.
[<=]

Monitoring Spezifika E-Rezept 

A_24610 - Anomalie-Erkennungssystem Spezifika E-Rezept

Das Anomalie-Erkennungssystem MUSS in der Lage sein, Anomalien und Auffälligkeiten mindestens in den Use Cases die zum Einstellen, Versandt und Abrufen der E-Rezepte benötigt werden zu identifizieren und MUSS die Fähigkeit besitzen stetige langfristige Veränderung zu berücksichtigen. [<=]

4.5 Datenaufbewahrung

TIP1-A_6437 - Datenaufbewahrung von Performancedaten

Anbieter (ausgenommen ist TSP CVC eGK) MÜSSEN die Performancedaten 6 Monate aufbewahren.

[<=]

5 Kenngrößen und Service Level

5.1 Begriffserläuterung

5.1.1 Organisatorische Service Level (vorgangsübergreifend)

Organisatorische Service Level legen die Anforderungen an die Organisation zur Lieferung oder Bereitstellung eines Services fest.

Sie messen die Fähigkeit der für den jeweiligen Service verantwortlichen Organisation, einen Service in der geforderten Qualität zu liefern.

Die geforderte Qualität richtet sich nach der Priorität von Geschäftsvorfällen, der betroffenen Betriebsumgebung, dem Zeitpunkt des Auftretens (Haupt- oder Nebenzeit) sowie der Kritikalität des Services.

Organisatorische Service Level werden im Servicelevel-Management-Prozess vereinbart und im TI-ITSM-System hinterlegt.

5.2 Organisatorische Service Level

5.2.1 Begriffserläuterungen

5.2.1.1 Quantil / Erfüllungsgrad

Ein Quantil ist genau der Wert, der eine Reihe von der Größe nach sortierten Werten in zwei Abschnitte unterteilt z. B. 95%-Quantil ist der 95.-Wert einer der Größe nach sortierten Reihe von 100 Werten.

Dies bedeutet, dass z. B. von 20 Messwerten im Berichtszeitraum 1 Unterschreitung des definierten Grenzwertes auftreten darf, um den Service Level im 95%-Quantil noch einzuhalten. Ab 19 Messwerten im Berichtszeitraum würde dagegen jede weitere Überschreitung (z. B. Lösungszeit von Prio1 <= 2 h wurde einmal überschritten) zur Verletzung des Service Levels führen.

Der Erfüllungsgrad ist das Verhältnis von SLA-konformen Tickets (Bearbeitungszeiten) zur Gesamtzahl der Tickets im monatlichen Betrachtungszeitraum. Sollte der "SL-Wert" (identisch mit bisherigem Quantil) unterschritten werden, ist der Service Level verletzt.

Der aktuelle Erfüllungsgrad wird bei den organisatorischen Service Leveln pro Kenngröße (SL-ID) je Betriebsumgebung (RU, TU, PU) ermittelt.

Da dieser Berechnungsweg einfacher ist, frühzeitige Trend-Aussagen ermöglicht werden und in den etablierten ITSM-Tools verwendet wird, löst er den Weg über die Quantil-Berechnung ab. Das Ergebnis ist in beiden Fällen das Gleiche.

5.2.1.2 Reaktionszeit

Die Reaktionszeit ist der Zeitraum zwischen Eingang eines Vorgangs beim Empfänger und seiner Rückmeldung an den Absender. Dabei enthält die Anfrage eine durch den Empfänger zu bearbeitende Aufgabenstellung.

Die Reaktionszeit wird durch das TI-ITSM-System ermittelt. Sie beginnt mit Eingang der Meldung im TI-ITSM-System und endet mit der im TI-ITSM-System dokumentierten Rückmeldung (z. B. Annahme der angeforderten Aufgabe oder deren Ablehnung).

5.2.1.3 Lösungszeit

Die Lösungszeit ist der Zeitraum zwischen der Aufnahme der Bearbeitung eines Vorgangs und seiner finalen Lösung. Sie kann dabei durch besondere Ereignisse unterbrochen werden (z.B. durch Eskalation, Unterstützungsanfrage an Dritte, Ablehnung der zunächst gefundenen Lösung …).

Die Lösungszeit wird durch das TI-ITSM-System ermittelt. Sie beginnt nach der im TI-ITSM-System dokumentierten Annahme der Lösungsbereitschaft durch den Bearbeiter und endet mit dem Setzen des entsprechenden Status zu dem jeweiligen Vorgang.

Zeiträume während der Lösungsphase von Vorgängen, die mit "Pending" gekennzeichnet wurden, werden bei der Berechnung der organisatorischen Service Level exkludiert (z.B. bei übergreifenden Problems).

5.2.1.4 Verifikationsfrist

Die Verifikationsfrist wird durch das TI-ITSM-System ermittelt.

Sie beginnt nach der im TI-ITSM-System dokumentierten Bereitstellung der Lösung und endet mit der im TI-ITSM-System vollzogenen Schließung des Vorgangs oder Ablehnung der Lösung. Je nach Vorgang erfolgt die Schließung differenziert. Im INC schließt der einstellende Teilnehmer, im PRO der Lösende nach Bestätigung.

5.2.2 Spezifische Ausprägungen

Tabelle Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten stellt zur Schaffung eines Überblicks die im folgenden durchgeführten Zuordnungen der einzelnen betrieblichen Rollen (Anbieter, Service Provider, Hersteller) zu den beiden Varianten der organisatorischen Service Level tabellarisch dar.

Tabelle 8: Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten

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 9: Tab_KPT_Betr_TI_052 Service Level (Zeiten) im TI-ITSM

* Die Reaktionszeit gilt sowohl für die Rolle Incident/Problem - Verantwortlicher als auch Incident/Problem - Unterstützer.
H (Hauptzeit): Mo - Fr 09:00 - 17:00 im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen].
N (Nebenzeit): Alle anderen Zeiten gelten als Nebenzeit.
** Abhängig vom im Business-Servicekatalog des TI-ITSM-Teilnehmers angebotenen konkreten Service [<=]

Sind SL nur der Hauptzeit (H) zugeordnet, so kann die Bearbeitung in der Nebenzeit unterbrochen werden und wieder in der Hauptzeit aufgenommen werden. Die Einhaltung dieses SL wird nur in der Hauptzeit gemessen.

A_13573-02 - Serviceleistung der TI-ITSM-Teilnehmer im TI-ITSM-Teilnehmersupport zur Hauptzeit

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

Tabelle 10: Tab_KPT_Betr_TI_053 Alternative Service Level (Zeiten) im TI-ITSM

* Die Reaktionszeit gilt sowohl für die Rolle Problemverantwortlicher als auch Problemunterstützer.
H (Hauptzeit): Mo - Fr 09:00 - 17:00 im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen].
N (Nebenzeit): Alle anderen Zeiten gelten als Nebenzeit.
Alle SL sind nur der Hauptzeit (H) zugeordnet. Die  Bearbeitung in der Nebenzeit ruht und wird in der Hauptzeit wieder aufgenommen. Die Einhaltung dieses SL wird nur in der Hauptzeit gemessen.
** Abhängig vom im Business-Servicekatalog des TI-ITSM-Teilnehmers angebotenen konkreten Service [<=]

Für eine Erweiterung der TI-ITSM Serviceleistungen am Samstag wird folgende Festlegung für die Fachdienste VSDM gelten. 

A_23507 - Erweiterung der Serviceleistung im TI-ITSM - Samstag

Der TI-ITSM-Teilnehmer MUSS zusätzlich zu der in A_13573-01 genannten Hauptzeit in folgenden Zeiten ebenfalls zur Verfügung stehen:

• Samstag, 09:00 - 14:00 Uhr.

Die abzudeckende Hauptzeit wird im TI-ITSM für den Betreiber entsprechend erweitert auf:

• Mo - Fr, 09:00 - 17:00 Uhr, außer an bundeseinheitlichen Feiertagen.
• Samstag, 09:00 - 14:00 Uhr, außer an bundeseinheitlichen Feiertagen.

[<=]

Weitere Organisatorische Service Level

Tabelle 11: Tab_gemKPT_Betr_OrgSL_Weitere_Serviceleistung

1. Change - Ursache für Incidents
Changes beinhalten immer das Risiko, Ursache für Störungen insbesondere für kritische Störungen zu sein. TI-ITSM-Teilnehmer tragen bei der Planung und Durchführung von Changes immer die Verantwortung, negative Auswirkungen auf die TI zu vermeiden bzw. zu verhindern. Daher ist bei der Planung eines Changes sowie bei der Umsetzung (nach erfolgter Genehmigung) für entsprechende Sorgfalt zu sorgen.
Weitere Details zum Change Management siehe [gemRL_Betr_TI].

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). [<=]

Sollte im genannten Zeitraum ein entsprechender Incident der Priorität 1 zugeordnet werden, so folgt daraus eine Verletzung des hier geforderten Service-Levels. Die Ursache bzw. der Auslöser des Incidents der Priorität 1 wird deshalb an den erfolgten Change angeknüpft.

2. Störungsfreie Kommunikationsbeziehungen 

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.
[<=]

Dies betrifft u.a. auch die fristgerechte Erneuerung von Zertifikaten im Umfeld der Public Key Infrastructure (PKI) der TI.

5.3 Technische Service Level / Performance-Kenngrößen

5.3.1 Begriffserläuterungen

5.3.1.1 Technischer Kennzahlenkatalog

Relevant für TI-ITSM-Teilnehmer die Performance-Berichte bereitstellen (alt - entfällt, wenn alle auf Rohdatenlieferung umgestellt sind):

Der Technische Kennzahlenkatalog enthält alle technischen Kennzahlen zu einem TI-Service, der anderen TI-ITSM-Teilnehmern angeboten wird. Grundlage sind die in der [gemSpec_Perf] festgelegten Werte. Im Rahmen des Service-Katalog-Managements werden diese Werte im TI-ITSM-System hinterlegt.

Dieser Kennzahlenkatalog wird vom GTI gepflegt und über das TI-ITSM-System den TI-ITSM-Teilnehmern bereitgestellt.

TIP1-A_7258 - Definition eines Technischen Kennzahlenkataloges

TI-ITSM-Teilnehmer (außer FD VSDM und TSP eGK) MÜSSEN für jeden anderen TI-ITSM-Teilnehmern angebotenen Service Kennzahlen in einem Technischen Kennzahlenkatalog an den Gesamtverantwortlichen TI liefern.
[<=]

TIP1-A_7259 - Mindestinhalte des Technischen Kennzahlenkataloges

TI-ITSM-Teilnehmer, die nach TIP1-A_7258 einen Technischen Kennzahlenkatalog liefern, MÜSSEN die Qualität der angebotenen Services in den Parametern Performance, Bearbeitungszeit, Durchsatz und Verfügbarkeit definieren.
[<=]

Hinweis: Diese Kennzahlenkataloge werden im TI-ITSM-System veröffentlicht.

Relevant für TI-ITSM-Teilnehmer der Performance-Rohdaten bereitstellen (neu):

Der Technische Kennzahlenkatalog enthält alle produkttypspezifischen Performance-Kenngrößen ergänzt um die aktuell festgelegten SL-Werten (siehe Kapitel 4.4.2). Die Werte basieren auf den Daten in der [gemSpec_Perf].

Die Kenngrößen / SL-Werte werden im Rahmen des Service Level Managements (siehe [gemRL_Betr_TI)] ausgearbeitet, ermittelt und für Berichte verwendet.

Dieser Kennzahlenkatalog wird vom Gesamtverantwortlichen TI gepflegt und den TI-ITSM-Teilnehmern über das TI-ITSM-System bereitgestellt.

5.3.2 Spezifische Ausprägungen

5.3.2.1 Erläuterungen / Festlegungen

• S/A-ID = S01 bzw. S/A-ID = A01 ist als ID reserviert und repräsentiert immer das Produkt bzw. den Produkttypen als Einheit. Diese wird mit S01 = I* gekennzeichnet. Die Kennung wird verwendet zur Darstellung der Verfügbarkeit. Auch wenn für einen Produkttyp ausschließlich Anwendungsfälle definiert sind, ist immer auch S01 = I* festgelegt.
• Ist in den Performance-Kenngrößen keine Servicezeit explizit angegeben, so entspricht die Servicezeit immer der Zeitspanne, die Haupt- und Nebenzeit umfasst.
• Sind die Soll-Werte für alle Betriebsumgebungen (BU) identisch, werden diese nicht differenziert dargestellt. Sind die Soll-Werte für die einzelnen BUs unterschiedlich, so werden die Werte in der Spalte "SL-Wert" einzeln aufgeführt, ergänzt durch das Kürzel für die jeweilige BU.
• Spaltenbeschriftungen:
  • pcm (per cent mille) = % *1000 (aufgerundet), entspricht einem Hunderttausendstel und wird im System als Integer-Wert dargestellt
  • min / max 
    • min bedeutet, dass der berechnete Service-Level-Wert größer oder gleich dem Soll-Wert sein muss,
    • max bedeutet dass der berechnete Service-Level-Wert kleiner oder gleich dem Soll-Wert sein muss.

5.3.2.2 Performance-Größen-Schemata

Ein PG-Schema ist eine Gruppe von Performance-Größen. Performance-Kenngrößen (je Produkttyp) zur betrieblichen Steuerung basieren i.d.R. auf einem Standardsatz von Performance-Größen.

Im folgenden werden nur Performance-Kenngrößen aufgeführt, für die ein SL-Wert definiert wurde bzw. die von den für den jeweiligen Produkttypen definierten Schemata abweichen.

Es werden folgende Schemata gebildet:

Tabelle 12: Tab_gemKPT_Betr_PG-Schemata

5.3.2.3 TSP X.509 (PDT02, PDT03, PDT36, PDT38)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT02, PDT03, PDT36, PDT38 - [gemSpec_Perf#Kap. 3.4 TSP X.509#Tab_gemSpec_Perf_Berichtsformat_TSP-X.509]

Tabelle 13: Tab_gemKPT_Betr_TSP-X.509_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 14: Tab_gemKPT_Betr_TSP-X.509_Performance-Kenngroessen

5.3.2.4 Signaturdienst (PDT47)

Tabellen mit Operationsaufrufen:

• PDT47 - [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD]

in Kapitel "Anhang C – Performance-Berichtsformate"

Tabelle 15: Tab_gemKPT_Betr_SigD_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 16: Tab_gemKPT_Betr_SigD_Performance-Kenngroessen

5.3.2.5 Federation Master (PDT70)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 17: Tab_gemKPT_Betr_FederationMaster_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 18: Tab_gemKPT_Betr_FederationMaster_Performance-Kenngroessen

5.3.2.6 Identity Provider (PDT52, PDT68, PDT73)

Tabellen mit Operationsaufrufen:

•   PDT52 - [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_IDP]

•   PDT68 - [gemSpec_Perf#Tab_Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP]

•   PDT73 - [gemSpec_Perf#Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben]

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 19: Tab_gemKPT_Betr_IdP_S::O/A

Performance-Kenngrößen / SL-Werte
Der Betrachtungszeitraum   für die aufgeführten Soll-Werte beträgt ein Kalendermonat.

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

Tabelle 20: Tab_gemKPT_Betr_IdP_Performance-Kenngroessen

5.3.2.7 VSDM-Fachdienst (PDT20, PDT23, PDT26)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen:

• PDT20, PDT23, PDT26 - [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM]

in Kapitel "Anhang C – Performance-Berichtsformate"

Tabelle 21: Tab_gemKPT_Betr_VSDM_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 22: Tab_gemKPT_Betr_VSDM_Performance-Kenngroessen

5.3.2.8 Anwendung ePA (PDT43)

Tabellen mit Operationsaufrufen:

• PDT43 - [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA]

Kapitel 3.18.2.2 Format.

Tabelle 23: Tab_gemKPT_Betr_ePA_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 24: Tab_gemKPT_Betr_ePA_Performance-Kenngroessen

5.3.2.9 Anwendung E-Rezept (PDT50, PDT59)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen:

• PDT50 - [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst],

in Kapitel "Anhang C – Performance-Berichtsformate"

Tabelle 25: Tab_gemKPT_Betr_eRP_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 26: Tab_gemKPT_Betr_eRP_Performance-Kenngroessen

5.3.2.10 National Contact Point for E-Health (PDT69)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 27: Tab_gemKPT_Betr_NCPeH_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 28 :Tab_gemKPT_Betr_NCPeH_Performance-Kenngroessen

5.3.2.11 VPN-Zugangsdienst (PDT09)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 29 Tab_gemKPT_Betr_VPN-Zugangsdienst_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 30: Tab_gemKPT_Betr_VPN-Zugangsdienst_Performance-Kenngroessen

5.3.2.12 Kommunikation im Medizinwesen KOM-LE (PDT24, PDT27)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 31: Tab_gemKPT_Betr_KIM_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 32: Tab_gemKPT_Betr_KIM_Performance-Kenngroessen

5.3.2.13 TI-Gateway-Zugangsmodul (PDT72)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 33: Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_S::O/A

Produkttyp / Anwen-dungstyp (PDT-ID)	S/A-ID	Schnittstellen::Operation / Anwendungsfall (S/A)	Beschreibung	Berichtsformat-Alias (sofern von Schnittstellen::Operation bzw. Anwendungsfall abweichend)
PDT72	S01	I*	Generische Schnittstelle
PDT72	S02	I_Secure_Channel_Tunnel::connect	Aufbau Verbindung VPN-Tunnel	TIG.I_1
PDT72	S03	I_Secure_Channel_Tunnel::disconnect	Abbau Verbindung VPN-Tunnel	TIG.I_2

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 34: Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_Performance-Kenngroessen

5.3.2.14 TI-Messenger (PDT64)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 35: Tab_gemKPT_Betr_TI-M::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 36: Tab_gemKPT_Betr_TI-M_Performance-Kenngroessen

5.3.2.15 Namensdienst (PDT06)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT06 - [gemSpec_Perf#Kap. 3.11 Namensdienst#Tab_gemSpec_Perf_Berichtsformat_Namensdienst]

Tabelle 37: Tab_gemKPT_Betr_Namensdienst_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 38: Tab_gemKPT_Betr_Namensdienst_Performance-Kenngroessen

5.3.2.16 Intermediär VSDM (PDT21)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

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

Tabelle 39: Tab_gemKPT_Betr_Intermediär_VSDM_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 40: Tab_gemKPT_Betr_Intermediär_VSDM_Performance-Kenngroessen

5.3.2.17 Trust Service Provider X.509 nonQES – Komponentenzertifikate (PDT37)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT37 - [gemSpec_Perf#Kap. 3.13 TSP X.509 nonQES – Komp#Tab_gemSpec_Perf_Berichtsformat_TSP_X.509_nonQES_Komp]

Tabelle 41: Tab_gemKPT_Betr_TSP_X.509_nonQES_Komp_S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 42: Tab_gemKPT_Betr_TSP_X.509_nonQES_Komp_Performance-Kenngroessen

5.3.2.18 Trust Service Provider X.509 nonQES – CVC (PDT31)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

Tabelle 43: Tab_gemKPT_Betr_TSP_CVC_S::O/A

Performance-Kenngrößen / SL-Werte

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

Tabelle 44: Tab_gemKPT_Betr_TSP_CVC_Performance-Kenngroessen

5.3.2.19 OCSP-Responder-Proxy (PDT01)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT01, OCSP-Responder-Proxy -[gemSpec_Perf#Kapitel 3.15.2.2#Tab_gemSpec_Perf_Berichtsformat_OCSP-Responder-Proxy]

Tabelle 45: Tab_gemKPT_Betr_OCSP-Responder-Proxy_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 46: Tab_gemKPT_Betr_OSCP-Responder-Proxy_Performance-Kenngroessen

5.3.2.20 TSL-Dienst (PDT04)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT04, TSL-Dienst - [gemSpec_Perf#Kapitel 3.16.2.2#Tab_gemSpec_Perf_Berichtsformat_TSL-Dienst]

Tabelle 47: Tab_gemKPT_Betr_TSL-Dienst_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 48: Tab_gemKPT_Betr_TSL-Dienst_Performance-Kenngroessen

5.3.2.21 gematik Root-CA (PDT22)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT22, gematik Root-CA - [gemSpec_Perf#Kapitel 3.17.2.2#Tab_gemSpec_Perf_Berichtsformat_gematik-Root-CA]

Tabelle 49: Tab_gemKPT_Betr_gematik-Root-CA_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 50: Tab_gemKPT_Betr_gematik-Root-CA_Performance-Kenngroessen

5.3.2.22 Zeitdienst (PDT07)

Schnittstellen::Operation bzw. Anwendungsfall

Tabelle 51: Tab_gemKPT_Betr_Zeitdienst_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 52: Tab_gemKPT_Betr_Zeitdienst_Performance-Kenngroessen

5.3.2.23 Zentrales Netz der TI (PDT08)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT08, Zentrales Netz der TI - [gemSpec_Perf#3.21.2.2#Tab_gemSpec_Perf_Berichtsformat_Zentrales-Netz-TI]

Tabelle 53: Tab_gemKPT_Betr_Zentrales-Netz-TI_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 54: Tab_gemKPT_Betr_Zentrales-Netz-TI_Performance-Kenngroessen

5.3.2.24 Sicherheitsgateway für Bestandsnetze (PDT10)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT10, Sicherheitsgateway für Bestandsnetze - [gemSpec_Perf#Kapitel 3.22.2.2#Tab_gemSpec_Perf_Berichtsformat_Sicherheitsgateway-Bestandsnetze]

Tabelle 55: Tab_gemKPT_Betr_Sicherheitsgateway-Bestandsnetze_Operationen/Anwendungsfälle

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 56: Tab_gemKPT_Betr_Sicherheitsgateway-Bestandsnetze_Performance-Kenngroessen

5.3.2.25 Konfigurationsdienst (PDT11)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT11, Konfigurationsdienst - [gemSpec_Perf#3.x.2.2#Tab_gemSpec_Perf_Berichtsformat_Konfigurationsdienst]

Tabelle 57: Tab_gemKPT_Betr_Konfigurationsdienst S::O/A

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 58: Tab_gemKPT_Betr_Konfigurationsdienst_Performance-Kenngroessen

5.3.2.26 Verzeichnisdienst FHIR (PDT66)

Schnittstellen::Operationen bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT66 - [gemSpec_Perf#Kap. 3.24 Verzeichnisdienst FHIR#Tab_gemSpec_Perf_Berichtsformat_VZD_FHIR]

Tabelle 59: Tab_gemKPT_Betr_VZD_FHIR_Operationen

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 60: Tab_gemKPT_Betr_VZD_FHIR_Performance-Kenngroessen

5.3.2.27 Verzeichnisdienst (PDT25)

Schnittstellen::Operation bzw. Anwendungsfall

Liste der Operationen/Anwendungsfälle:

• PDT25 - [gemSpec_Perf#Kap. 3.25 Verzeichnisdienst#Tab_gemSpec_Perf_Berichtsformat_Verzeichnisdienst]

 

Tabelle 61: Tab_gemKPT_Betr_Verzeichnisdienst_Operationen

Performance-Kenngrößen / SL-Werte

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

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

Tabelle 62: Tab_gemKPT_Betr_Verzeichnisdienst_Performance-Kenngroessen

5.4 Zulassungsverfahren - Pönalisierung

Regeln zur Pönalisierung von organisatorischen und technischen Service Leveln finden sich in dem Dokument "Anlage 1 zum Vertrag über die Zulassung als Anbieter der operativen Betriebsleistung", dessen aktuellste Version auf dem Fachportal in der Rubrik "Zulassungen und Bestätigungen durch die gematik" veröffentlicht ist. Dieses Dokument enthält u.a. auch eine Zuordnung von Service Leveln zu betroffenen Anforderungen und ist Bestandteil des Zulassungsvertrags.

6 Spezifische betriebsrelevante Ergänzungen

6.1 Identity Management

A_22954 - Umsetzung definierter Releases durch den Anbieter

Der Anbieter MUSS umsetzungspflichtige Releases umsetzen, um weiterhin Mitglied des IDP-Vertrauensraumes zu sein.
Bei nicht rechtzeitiger Umsetzung der durch die gematik angekündigten und als solches gekennzeichneten Releases wird die gematik den Anbieter aus der Vertrauensbeziehung (Trusted Party des IDP) der Föderation ausschließen. Die Umsetzung eines Releases durch den Anbieter setzt die rechtzeitige Verfügbarkeit des damit verbundenen zugelassenen Produktes voraus.
Die Zulassung bleibt davon unberührt.
[<=]

A_25081 - Bereitstellung von Mandanten für Anbieter sek IDP KTR in RU und TU als Zulassungsvoraussetzung

Der Anbieter sek IDP KTR MUSS für die Zulassung mindestens je einen Mandanten gemäß [gemSpec_Perf#A_25079-*] des sek IDP in RU und TU mit Testidentitäten bereitstellen.
Für den RU-Mandanten und den TU-Mandanten MÜSSEN jeweils mindestens 10 Testidentitäten bereitgestellt werden.
Für den RU-Mandanten und den TU-Mandanten MUSS jeweils mindestens 1 Testidentität bereitgestellt werden, die über die verpflichtend anzubietenden Authentisierungsmittel Test-eGK und Test-Personalausweis verfügt.
Alle bereitgestellten Mandanten MÜSSEN in der jeweiligen Betriebsumgebung am Federation Master fehlerfrei registriert werden.
[<=]

A_25147 - Erfolgreiche Rohdatenlieferung Anbieter sek IDP KTR als Zulassungsvoraussetzung

Der Anbieter sek IDP KTR MUSS eine logische Produktinstanz (CI-ID) über alle seine Mandanten pro Betriebsumgebung zuordnen.
Der Anbieter sek IDP KTR MUSS diese CI-IDs eine Woche vor Beginn der Rohdatenlieferung beantragen.
Der Anbieter sek IDP KTR  MUSS mindestens eine Woche lang fehlerfrei und vollständig

• Rohdaten (Performancedaten und Selbstauskunft gemäß [gemSpec_Perf#A_17757-*])

und

• Bestandsdaten gemäß [gemSpec_Perf#A_23213-*]

liefern.
Zur Generierung von aussagekräftigen Rohdaten MUSS der Anbieter sek IDP KTR dazu mindestens eine Woche lang so viele erfolgreiche unterschiedliche Testdurchläufe absolvieren, sodass pro Rohdatentrigger (ID gemäß  [gemSpec_Perf#A_22833-*]) mindestens 20 Datensätze pro Tag in den Rohdatenlieferungen dargestellt werden. [<=]

A_25155 - Betriebliche Konkretisierung der Mandantenbereitstellung für Anbieter sek IDP KTR in RU und TU

Der Anbieter sek IDP KTR MUSS ab Zulassung mindestens je einen Mandanten gemäß [gemSpec_IDP_Sek#A_23053-*] des sek IDP in RU und TU mit Testidentitäten bereitstellen. Die Produktversion der bereitgestellten Mandanten MUSS der zuletzt zugelassenen Produktversion entsprechen, die in der PU aktiv ist.
Alle vom Anbieter bereitgestellten Mandanten MÜSSEN in der jeweiligen Betriebsumgebung am Federation Master fehlerfrei registriert werden. Pro Betriebsumgebung wird dem Anbieter für seine bereitgestellten Mandanten eine logische Produktinstanz (CI-ID) zugeordnet. Der Anbieter MUSS diese CI-IDs mindestens eine Woche vor Beginn der Rohdatenlieferung beantragen.
Der Anbieter sek IDP KTR MUSS ab Zulassung vollständig Rohdaten für die RU und TU mit der jeweiligen CI-ID liefern.

Hinweis:
Für Tests von neueren (höheren) Versionen DARF der Anbieter sek IDP KTR weitere Mandanten in RU und TU am FedMaster registrieren. Spätestens zum Zeitpunkt des Beginns der Zulassungstests in der TU MUSS der neue TU-Mandant unter der CI-ID der TU in die Rohdatenlieferung aufgenommen sein. Ein Wechsel des Mandanten ist in Absprache mit der gematik möglich.
[<=]

6.2 Konfigurationen von Produkten

Das normative Verhalten einer Produktinstanz an seiner Außenschnittstelle wird maßgeblich durch dessen individuelle und ad hoc änderbare Konfiguration definiert. Eine eindeutige Referenzierung und Versionierung von Konfigurationsparametern dient einerseits der Verhinderung von unkontrollierten Veränderungen und andererseits der konsistenten Nachvollziehbarkeit bei Änderungen im Zuge eines betrieblichen Change.

Konfigurationen in diesem Sinne folgen der Festlegung gem. [gemKPT_Test#A_20060].

Konfigurationen enthalten eine Sammlung von Konfigurationsparametern zum selben Versionsstand.

Konfigurationsparameter sind üblicherweise in Config-Dateien, Registry-Einträgen oder Aufrufparametern mit konkreten Werten hinterlegt. Sie können mit Betriebssystemversionsständen, Patchlevel und weiteren (Java-)Bibliotheksversionen angereichert sein.

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. [<=]

Die Produktinstanz entspricht der logischen Produktinstanz. 

6.3 Digitale Gesundheitsanwendungen (DiGA)

Die Gematik plant ein mehrstufiges Vorgehen.
Im ersten Schritt werden keine Verpflichtungen an die DiGA-Anbieter für das TI-ITSM aufgenommen.

Begründung:

In der ersten Zeit wird das Risiko von Betriebsstörungen als gering eingeschätzt, weil:

• die Zahl der Nutzer wird in der ersten Zeit sehr übersichtlich sein, da ja die per „Video-Ident“ identifizierten User ab Januar wegfallen
• nur ein Bruchteil der potentiell 1% Nutzer der GesundheitsID DiGAs nutzen
• es aktuell keinen UseCase gibt, der eine Authentifizierung über GesundheitsID notwendig macht.

Zukünftig wird über eine Rolle eines „DiGA-Integrators in die TI“ als Zugangsanbieter nachgedacht. Die gematik definiert diese Rolle und das Marktmodel. Die neuen Regelungen werden die bisherigen Regelungen ablösen.

Während der Ramp-Up Phase für 2024 werden keine 24/7 Präsens und keine Service Level vereinbart.

Die Nachfolgenden Anforderungen wurden als flankierende Maßnahmen vereinbart: 

A_24349 - Eigenverantwortliche Störungsabwendung einer DiGA

Der DiGA-Anbieter MUSS bei selbst erkannten oder an ihn gemeldeten Störungen der Telematikinfrastruktur, insbesondere bei Störungen der sek IPD KTR durch erhöhte Tokenanfrage, selbständig die Störung beseitigen oder die Kommunikation zur TI-Föderation unterbinden.
Falls die Unterbindung der Kommunikation durch den DiGA-Anbieter nicht innerhalb 24 Stunden erfolgt, wird der Gesamtverantwortliche TI (GTI) die DiGA aus der TI-Föderation zum Schutz vor Überlast ausschließen.

Hinweis:
Die Unterbindung kann z.B. durch Trennung der Kommunikation des Authorization Servers der DiGA erfolgen. [<=]

A_24351 - Benennung von Ansprechpartnern der DiGA

DiGA-Anbieter MÜSSEN Kontaktdaten von Ansprechpartnern bei der Registrierung zur TI-Föderation mitteilen und über den DiGA-Vertreter aktuell halten für:

• die Rolle Service Delivery Manager (agiert auch als 1. Eskalationsstufe)
• die Unternehmenskommunikation (u.a. Krisenkommunikation)
• die Informationssicherheit
• den Datenschutz
• vertragliche und kaufmännische Fragestellungen.

Dazu sind jeweils Telefonnummer und E-Mailadressen anzugeben.
Die benannten Ansprechpartner MÜSSEN mit der entsprechenden Fach- und Entscheidungskompetenz ausgestattet sein.
Selbstverständlich dürfen die einzelnen Rollen teilweise oder vollständig in Personalunion ausgeführt werden. [<=]

A_24354 - Kostenfreier Zugang zur DiGA für Fehlernachstellungen

DiGA-Anbieter MÜSSEN der gematik kostenfreien Zugang zur DiGA für Fehlernachstellungen unentgeltlich in der Produktivumgebung zur Verfügung stellen.
Der Abruf erfolgt erst bei konkreter Notwendigkeit durch die gematik.
Die Nutzung kann auch im Rahmen des §331 (5) SGB V in der Verifikationsumgebung der gematik mit Prüfnutzeridentitäten in der Produktivumgebung erfolgen. [<=]

7 Anhang A – Performance-Kenngrößen

Für die Performance-Größen (Tab_gemKPT_Betr_Performance-Groessen) zu den Performance-Dimensionen (Tab_gemKPT_Betr _Performance-Dimensionen) erfassen und reporten die Produkttypen (Tab_gemKPT_Betr _Produkttypen) für die Schnittstellenoperationen (Tab_gemKPT_Betr _Schnittstellenoperationen) die Performance-Kenngrößen gemäß Tab_gemKPT_Betr _Performance-Kenngroessen. OCSP-Responder liefern Performance-Größen getrennt nach Zertifikatstypen (Tab_gemKPT_Betr _Zertifikatstypen).

Das Zentrale Netz erfasst Ausfälle bezogen auf die Verbindungen (Vxx) zwischen konkreten Produktinstanzen pi der TI vom Typ VPN-Zugangsdienst, Zentraler Dienst TI-Plattform, Fachanwendungsspezifischer Dienst und Sicherheitsgateway Bestandsnetze. Siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“.

Der konkrete Bezeichner Vxx für eine Verbindung zwischen den beiden SZZPs szzp1 und szzp2 lautet

Vxx = „V“ +  szzp1  + „_„  + szzp2

Relevant sind dafür nur die einem Aufrufer sichtbaren SZZPs (auch als „logischer SZZP“ bezeichnet), nicht einzelne physische Instanzen, die gemeinsam zur Verfügbarkeit des SZZPs beitragen. Die konkreten Bezeichner für die logischen SZZPs sind mit gematik Betrieb (Operations) abzustimmen. szzp1 sei immer der Bezeichner, der in alphanumerischer Sortierung vor szzp2 liegt.
Beispiel: PDT08-S01-D3-G10-V0001_0007

Das Zentrale Netz erfasst gemäß [gemSpec_Perf#GS-A_5014] an seinen Sicheren Zentralen Zugangspunkten (SZZP) die Datenmengen getrennt nach Richtungen Rxx. Dabei gibt die Richtung Rxx an, welche Dienstinstanz betroffen ist und ob der Fluss zur Instanz hin (Rz) oder von der Instanz weg (Rv) erfolgt.

Der Bezeichner Rxx setzt sich zusammen aus „Rz“ für die Richtung zur Dienstinstanz hin und „Rv“ für die Richtung von der Dienstinstanz weg sowie einem Bezeichner für die Dienstinstanz. Der Bezeichner für die Dienstinstanz setzt sich aus drei durch "_" getrennten Teilen zusammen. Einem Bezeichner für den logischen SZZP, einem Bezeichner für den Produkttypen und einem Bezeichner für den Anbieter des Dienstes. Die konkreten Bezeichner für die logischen SZZPs und Anbieter sind mit gematik Betrieb (Operations) abzustimmen. Die Bezeichner für die Produkttypen gibt Tabelle Tab_gemKPT_Betr_Produkttypen vor.
Beispiel: PDT08-S11-D1-G02-Rv0001_PDT04_ARVTO

Für die VSDM-Produkttypen erfolgt abweichend zu [gemSpec_Perf#GS-A_5014] die Volumenerfassung für die VSDM-Produkttypen pro SZZP in Summe über Anbieter und VSDM-Produkttypen (nur aufgeschlüsselt nach Richtung).

Damit die Syntax der Bezeichner auch für diesen Ausnahmefall erhalten bleibt, wird als Produkttypbezeichner „VSDM“ gesetzt und als Anbieterbezeichner „XXXXX“.
Beispiel: PDT08-S11-D1-G02-Rz0035_VSDM_XXXXX

Für den Produkttyp VPN-Zugangsdienst werden zur Unterscheidung einzelner VPN-Konzentratoren zwei weitere Bezeichnungen VPNK-TI_X (VPN-Konzentrator TI) und VPNK-SIS_X (VPN-Konzentrator SIS) eingeführt. Der Platzhalter „X“ ist ein eindeutiger Bezeichner eines VPN-Konzentrators und wird durch den Anbieter des VPN-Zugangsdienstes vergeben. Es sind 32 Zeichen zulässig.
Beispiel: PDT09-S11-D1-G03-VPNK-TI_vpnk1.fra.providerx.de

Tabelle Tab_gemKPT_Betr_Beispiel_Rohdaten zeigt exemplarisch die in zwei Erfassungszeiträumen gemessenen Performance-Daten zu einzelnen Anfragen und Tabelle Tab_gemKPT_Betr_Beispiel_Performance_Kenngroessen die aus diesen generierten Performance-Kenngrößen.

7.1 Definitionen

7.1.1 Produkttypen (PDT-IDs)

Tabelle 63: Tab_gemKPT_Betr_Produkttypen

7.1.2 Performance-Dimensionen

Tabelle 64: Tab_gemKPT_Betr_Performance-Dimensionen

7.1.3 Aufrufquelle

Tabelle 65: Tab_gemKPT_Betr_Aufrufquelle

7.1.4 Zertifikatstypen

Tabelle 66: Tab_gemKPT_Betr_Zertifikatstypen

7.1.5 Schnittstellen::Operation / Anwendungsfall (altes Format - noch zu migrieren)

Tabelle 67: Tab_gemKPT_Betr_Schnittstellenoperationen

7.2 Performance-Größen

PG = Performance-Größe

7.2.1 Dimension Last

Tabelle 68: Tab_gemKPT_Betr_Performance-Groessen_Last

7.2.2 Dimension Bearbeitungszeit

Tabelle 69: Tab_gemKPT_Betr_Performance-Groessen_Bearbeitungszeit

7.2.3 Dimension Verfügbarkeit

Tabelle 70: Tab_gemKPT_Betr_Performance-Groessen_Verfügbarkeit

7.3 Performance-Kenngrößen (altes Format - noch zu migrieren)

Tabelle 71: Tab_gemKPT_Btr_Performance-Kenngroessen

Tabelle 72: Tab_gemKPT_Betr_Beispiel_Rohdaten

Tabelle 73: Tab_gemKPT_Betr_Beispiel_Performance_Kenngroessen

8 Anhang B – Verzeichnisse

8.1 Abkürzungen

Tabelle 74: Tab_KPT_Betr_TI_045 Abkürzungsverzeichnis

8.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

8.3 Abbildungsverzeichnis

Abbildung 1: Anbieterkonstellation

8.4 Tabellenverzeichnis

Tabelle 1: Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer

Tabelle 2: Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen

Tabelle 3: Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer 

Tabelle 4: Tab_gemKPT_Betr_Servicekomponente

Tabelle 5: Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM 

Tabelle 6: Tab_KPT_Betr_TI_Anbieter_UHD/VHD

Tabelle 7: Tab_KPT_Betr_TI_044 Mindestservicezeit Störungsmeldungen und Anfragen

Tabelle 8: Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten

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

Tabelle 10: Tab_KPT_Betr_TI_053 Alternative Service Level (Zeiten) im TI-ITSM

Tabelle 11: Tab_gemKPT_Betr_OrgSL_Weitere_Serviceleistung

Tabelle 12: Tab_gemKPT_Betr_PG-Schemata

Tabelle 13: Tab_gemKPT_Betr_TSP-X.509_S::O/A

Tabelle 14: Tab_gemKPT_Betr_TSP-X.509_Performance-Kenngroessen

Tabelle 15: Tab_gemKPT_Betr_SigD_S::O/A

Tabelle 16: Tab_gemKPT_Betr_SigD_Performance-Kenngroessen

Tabelle 17: Tab_gemKPT_Betr_FederationMaster_S::O/A

Tabelle 18: Tab_gemKPT_Betr_FederationMaster_Performance-Kenngroessen

Tabelle 19: Tab_gemKPT_Betr_IdP_S::O/A

Tabelle 20: Tab_gemKPT_Betr_IdP_Performance-Kenngroessen

Tabelle 21: Tab_gemKPT_Betr_VSDM_S::O/A

Tabelle 22: Tab_gemKPT_Betr_VSDM_Performance-Kenngroessen

Tabelle 23: Tab_gemKPT_Betr_ePA_S::O/A

Tabelle 24: Tab_gemKPT_Betr_ePA_Performance-Kenngroessen

Tabelle 25: Tab_gemKPT_Betr_eRP_S::O/A

Tabelle 26: Tab_gemKPT_Betr_eRP_Performance-Kenngroessen

Tabelle 27: Tab_gemKPT_Betr_NCPeH_S::O/A

Tabelle 28 :Tab_gemKPT_Betr_NCPeH_Performance-Kenngroessen

Tabelle 29 Tab_gemKPT_Betr_VPN-Zugangsdienst_S::O/A

Tabelle 30: Tab_gemKPT_Betr_VPN-Zugangsdienst_Performance-Kenngroessen

Tabelle 31: Tab_gemKPT_Betr_KIM_S::O/A

Tabelle 32: Tab_gemKPT_Betr_KIM_Performance-Kenngroessen

Tabelle 33: Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_S::O/A

Tabelle 34: Tab_gemKPT_Betr_TI-Gateway-Zugangsmodul_Performance-Kenngroessen

Tabelle 35: Tab_gemKPT_Betr_TI-M::O/A

Tabelle 36: Tab_gemKPT_Betr_TI-M_Performance-Kenngroessen

Tabelle 37: Tab_gemKPT_Betr_Namensdienst_S::O/A

Tabelle 38: Tab_gemKPT_Betr_Namensdienst_Performance-Kenngroessen

Tabelle 39: Tab_gemKPT_Betr_Intermediär_VSDM_S::O/A

Tabelle 40: Tab_gemKPT_Betr_Intermediär_VSDM_Performance-Kenngroessen

Tabelle 41: Tab_gemKPT_Betr_TSP_X.509_nonQES_Komp_S::O/A

Tabelle 42: Tab_gemKPT_Betr_TSP_X.509_nonQES_Komp_Performance-Kenngroessen

Tabelle 43: Tab_gemKPT_Betr_TSP_CVC_S::O/A

Tabelle 44: Tab_gemKPT_Betr_TSP_CVC_Performance-Kenngroessen

Tabelle 45: Tab_gemKPT_Betr_OCSP-Responder-Proxy_Operationen/Anwendungsfälle

Tabelle 46: Tab_gemKPT_Betr_OSCP-Responder-Proxy_Performance-Kenngroessen

Tabelle 47: Tab_gemKPT_Betr_TSL-Dienst_Operationen/Anwendungsfälle

Tabelle 48: Tab_gemKPT_Betr_TSL-Dienst_Performance-Kenngroessen

Tabelle 49: Tab_gemKPT_Betr_gematik-Root-CA_Operationen/Anwendungsfälle

Tabelle 50: Tab_gemKPT_Betr_gematik-Root-CA_Performance-Kenngroessen

Tabelle 51: Tab_gemKPT_Betr_Zeitdienst_Operationen/Anwendungsfälle

Tabelle 52: Tab_gemKPT_Betr_Zeitdienst_Performance-Kenngroessen

Tabelle 53: Tab_gemKPT_Betr_Zentrales-Netz-TI_Operationen/Anwendungsfälle

Tabelle 54: Tab_gemKPT_Betr_Zentrales-Netz-TI_Performance-Kenngroessen

Tabelle 55: Tab_gemKPT_Betr_Sicherheitsgateway-Bestandsnetze_Operationen/Anwendungsfälle

Tabelle 56: Tab_gemKPT_Betr_Sicherheitsgateway-Bestandsnetze_Performance-Kenngroessen

Tabelle 57: Tab_gemKPT_Betr_Konfigurationsdienst S::O/A

Tabelle 58: Tab_gemKPT_Betr_Konfigurationsdienst_Performance-Kenngroessen

Tabelle 59: Tab_gemKPT_Betr_VZD_FHIR_Operationen

Tabelle 60: Tab_gemKPT_Betr_VZD_FHIR_Performance-Kenngroessen

Tabelle 61: Tab_gemKPT_Betr_Verzeichnisdienst_Operationen

Tabelle 62: Tab_gemKPT_Betr_Verzeichnisdienst_Performance-Kenngroessen

Tabelle 63: Tab_gemKPT_Betr_Produkttypen

Tabelle 64: Tab_gemKPT_Betr_Performance-Dimensionen

Tabelle 65: Tab_gemKPT_Betr_Aufrufquelle

Tabelle 66: Tab_gemKPT_Betr_Zertifikatstypen

Tabelle 67: Tab_gemKPT_Betr_Schnittstellenoperationen

Tabelle 68: Tab_gemKPT_Betr_Performance-Groessen_Last

Tabelle 69: Tab_gemKPT_Betr_Performance-Groessen_Bearbeitungszeit

Tabelle 70: Tab_gemKPT_Betr_Performance-Groessen_Verfügbarkeit

Tabelle 71: Tab_gemKPT_Btr_Performance-Kenngroessen

Tabelle 72: Tab_gemKPT_Betr_Beispiel_Rohdaten

Tabelle 73: Tab_gemKPT_Betr_Beispiel_Performance_Kenngroessen

Tabelle 74: Tab_KPT_Betr_TI_045 Abkürzungsverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

8.5.2 Weitere Dokumente