Elektronische Gesundheitskarte und Telematikinfrastruktur

Betriebskonzept

Online-Produktivbetrieb

Version
3.67.0
Revision
1656110
Stand
07.07.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemKPT_Betr

Dokumentinformationen

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion 

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

Dokumentenhistorie

Inhaltsverzeichnis

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*] 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_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_TI-ITSM-Teilnehmer" kann entnommen werden, durch welcher Akteu 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 Rollen und Akteure im TI-Betrieb

Dieses Kapitel beschreibt die im Betrieb der TI relevanten Rollen und Akteure sowie ihre Aufgaben und Verantwortlichkeiten im betrieblichen Kontext. Es bildet den Rahmen für:

• die Einordnung der Rollenarten (Governance‑Rollen, Provider‑Rollen, Hersteller, (End‑)Nutzer‑ und Umfeldrollen, spezialisierte Dienste öffentlicher Institutionen),
• die Abgrenzung von Verantwortungsarten auf Rollenebene,
• die Unterscheidung zwischen TI‑Teilnehmern und TI‑ITSM‑Teilnehmern und deren Mitwirkung im TI‑ITSM.

Generell wird zwischen einer Rolle und einem Akteur unterschieden. Im Kontext der TI ist ein Akteur eine konkrete Ausprägung einer Rolle (z. B. „Anbieter ePA‑Aktensystem“, „Hersteller Frontend des Versicherten“), die im Betriebsmodell und in entsprechenden Steckbriefen näher spezifiziert wird. Eine Rolle hingegen ist eine verallgemeinerte Beschreibung von Aufgaben, Verantwortungen und Rechten (z. B. „Anbieter“, „Hersteller“, „Anwender“).

Die Beschreibung der betrieblichen Rollen erfolgt im Kontext eines Multi‑Provider‑Managements und orientiert sich an dem SIAM Framework (Service Integration And Management). Dabei werden insbesondere folgende Ebenen unterschieden:

• Governance- und Integrations-Ebene: Rollen des Gesamtverantwortlichen TI (GTI) in seiner Governance‑Funktion sowie gematik‑interne Provider, die die Service‑Integrator‑Funktion in der TI ausprägen.
  
• Provider-Ebene: zugelassene und beauftragte Anbieter, Vertreter im Auftrag von Anbietern, Hersteller (insbesondere Hersteller mit TI‑ITSM‑Mitwirkung) sowie Anbieter weiterer Anwendungen und Dienste.
  
• (End‑)Nutzer- und Umfeld-Ebene: Anwender, Versicherte, Kostenträger in Nutzerrolle, Dienstleister vor Ort (DVO) und Drittanbieter.
  

Die Governance‑/Integrations‑Ebene umfasst dabei sowohl die Governance‑Funktion (Definition von Zielbild, Rahmenvorgaben und Betriebsmodellen der TI, Festlegung von Spezifikationen, Prozessen und Servicevorgaben, Steuerung und Bewertung des Gesamtbetriebs) als auch die Service‑Integrator‑Funktion (Gestaltung und Betrieb TI‑weiter End‑to‑End‑Prozesse, Koordination der Zusammenarbeit mehrerer Provider im laufenden Betrieb, Sicherstellung einer konsolidierten Ende‑zu‑Ende‑Sicht auf TI‑Services, Servicequalität und Performance).

Die Provider‑Ebene erbringt darauf aufbauend die fachlichen und technischen Services, während (End‑)Nutzer‑ und Umfeldrollen die TI‑Services konsumieren oder lokal unterstützen.

Eine Organisation kann gleichzeitig in mehreren Rollen bzw. Akteuren agieren (z. B. Krankenkasse als Kostenträger in Nutzerrolle und als Anbieter eines Dienstes bzw. Fachdienstes).

Eine aktuelle Definition zentraler Begriffe (z. B. „Hersteller zentraler/dezentraler Produkte“, „Anwender“, „Versicherte“) findet sich in [gemGlossar], im Glossar des Bundesministeriums für Gesundheit sowie in den einschlägigen Regelungen des SGB V. Die in diesem Kapitel verwendeten Rollenbezeichnungen konkretisieren diese Begriffe für den betrieblichen Kontext der TI.

Die in diesem Kapitel beschriebenen Rollen sind Grundlage für das Betreibermodell (Kap. 3.4 Betreibermodell) und das Servicemodell (Kap. 3.5 Servicemodell). Die konkrete Ausprägung der Pflichten und Mitwirkungen der einzelnen Rollen erfolgt in den zugehörigen Steckbriefen, Richtlinien und tabellarischen Übersichten des Betriebskonzepts.

Die Abbildung „Rollen im TI-Betrieb“ gibt einen Überblick über die im betrieblichen Kontext relevanten Rollenarten und ordnet ihnen exemplarische Rollen zu. Die weiteren Unterkapitel dieses Abschnitts erläutern diese Rollenarten und Rollen im Detail.

Abbildung 1 : Rollen im TI-Betrieb

3.3.1 Governance- und Integrations-Rollen

Governance‑Rollen beschreiben die übergreifende Steuerung und Koordination des TI‑Betriebs. Sie definieren Rahmenvorgaben (z. B. Spezifikationen, Richtlinien, Prozesse), überwachen die Einhaltung dieser Vorgaben und steuern das Zusammenwirken der verschiedenen Provider‑ und Nutzerrollen auf Gesamt‑TI‑Ebene.

Zur Governance‑/Integrations‑Ebene gehören insbesondere:

• der Gesamtverantwortliche TI (GTI) in seiner Governance‑Funktion,
• gematik‑interne Provider in Integrationsfunktion (z. B. zentrale Plattform‑, Test‑ und Monitoringdienste), die die Service‑Integrator‑Funktion technisch und organisatorisch ausgestalten.

Die Governance‑Rollen definieren damit den Rahmen, innerhalb dessen die Service‑Integrator‑Funktion und die Service Provider den operativen TI‑Betrieb umsetzen.

3.3.1.1 Gesamtverantwortlicher TI (GTI)

Der Gesamtverantwortliche TI (GTI) ist die Governance‑Rolle der gematik für die Telematikinfrastruktur. Der GTI

• übernimmt die Steuerungs- und Aufsichtsfunktion gegenüber Dienstleistern (TI‑Governance),
• definiert fachliche, technische und betriebliche Rahmenbedingungen (z. B. Architektur, Spezifikationen, Testkonzepte und Zulassungsverfahren, Betriebskonzept und -richtlinien, Umgebungsmanagement),
• legt das TI‑Betriebsmodell und den TI‑ITSM‑Rahmen fest,
• überwacht die Serviceerbringung (z. B. Provider Management, Monitoring, Reporting, Risikomanagement, Eskalations- und Taskforce-Management),
• stellt Ressourcen zur Unterstützung der Zusammenarbeit bereit (Collaboration).

Der Gesamtverantwortliche TI übernimmt keine Serviceverantwortung für konkrete TI‑Services. Die operativen Betriebsleistungen liegen bei den Providern.

Die Service-Integrator-Funktion der TI wird im Auftrag des Gesamtverantwortlichen TI durch gematik‑seitige Provider und zentrale Plattformdienste wahrgenommen. Sie umfasst insbesondere:

• die Ausgestaltung und den Betrieb TI‑weiter End‑to‑End‑Prozesse (z. B. Incident, Problem, Change, Request, Service Level),
• die Integration der Provider in diese Prozesse einschließlich Routing, Eskalation und Taskforce‑Steuerung,
• die Konsolidierung von Betriebs- und Performancedaten zu einer TI‑weiten Sicht auf Servicequalität und Performance.

Der Gesamtverantwortliche TI ist TI‑ITSM‑Teilnehmer in seiner Governance‑ und Integrationsrolle, insbesondere in Prozessen mit Steuerungs‑ und Entscheidungsfunktion (z. B. Service Level Management, Changefreigaben, Major Incident‑/Notfallmanagement). Betriebliche Akteure des Gesamtverantwortlichen TI sind u. a.:

• Service Delivery Manager
• Service Executive Manager (1. Eskalationsinstanz)
• Prozess Manager (je TI-ITSM-Prozess)
• Transition Manager

3.3.2 Provider-Rollen in der Serviceerbringung

Provider‑Rollen beschreiben Organisationen, die TI‑Services oder unterstützende Betriebsleistungen bereitstellen. Sie erbringen fachliche und technische Dienste, binden Produkte in die TI ein und wirken über definierte Schnittstellen und Prozesse am TI‑Betrieb und am TI‑ITSM mit.

3.3.2.1 Anbieter von Betriebsleistungen

Anbieter von Betriebsleistungen erbringen TI‑Services oder TI‑unterstützende Services gemäß §§  323, 324 SGB V und tragen die fachliche Verantwortung für die Umsetzung dieser Leistungen nach den Vorgaben der gematik.

Die Anforderungen der gematik umfassen dabei alle Service-relevanten Verpflichtungen, welche sich im Hinblick auf dieses Verhältnis ergeben (Ende-zu-Ende-Verantwortung) und welche zur stabilen, sicheren und interoperablen Erbringung der Betriebsleistung erforderlich sind. 

Es werden zwei Ausprägungen unterschieden:

• Zugelassener Anbieter mit Anbieterzulassung nach § 324 SGB V
• Beauftragter Anbieter auf Grundlage einer Beauftragung durch die gematik nach § 323 Abs. 2 SGB V
  

Alle Anbieter von Betriebsleistungen:

• stellen TI‑Services bzw. TI‑unterstützende Services bereit,
• tragen die Serviceverantwortung (SV) für ihre Services und Servicekomponenten,
• verantworten den Betrieb der ihnen zugeordneten Servicekomponenten,
• koordinieren beteiligte Hersteller und weitere Providerrollen,
• sind entsprechend ihrer Rolle TI-ITSM-Teilnehmer.
  

Zugelassene Anbieter werden im Betreibermodell entweder im Vertretermodell oder im Legacy-Modell der Anbieterkonstellationen geführt. Die anzuwendende Variante ergibt sich aus den durch die gematik festgelegten regulatorischen und vertraglichen Vorgaben (z. B. Anbietertypsteckbriefen). Aktuelle Zuordnungen zu den einzelnen Modellen finden sich in Kap. 3.4.4 Providerspezifische Betreibermodelle - Überblick .

Delegation von Aufgaben (z. B. Betrieb, Nachweisführung, UHD/VHD) ist gemäß den Vorgaben des jeweiligen Modells möglich, jedoch bleibt der Anbieter stets Adressat der Anforderungen der gematik. Delegation kann erfolgen an:

• Vertreter (nur bei zugelassenen Anbietern im Vertrtermodell),
• Unterauftragnehmer (nur im Legacy-Modell) oder
• Drittanbieter (nicht sichtbare Rolle im Hintergrund).
  

Die Serviceverantwortung wird bei Delegation nicht übertragen und verbleibt vollständig beim jeweiligen Anbieter von Betriebsleistungen.

Unterauftragnehmer und Anbieterkonstellationen werden ausschließlich im Rahmen des Legacy-Modells gemäß Kap. 3.4.4 Providerspezifische Betreibermodelle - Überblick beschrieben und sind nicht Bestandteil des Vertretermodells

Ein Anbieter von Betriebsleistungen stellt im Sinne des Servicemodells eigene Services (Eigener Service – E) bereit und verantwortet die Erbringung dieser Services auf Basis der vereinbarten Dienstgüten. Die Zuordnung von Servicekomponenten zu Anbietern von Betriebsleistungen und die Mitwirkungspflichten im TI-ITSM sind in der Servicearchitektur und in Tabelle "Tab_gemKPT_Betr_TI_002 „Mitwirkungspflichten der TI‑ITSM‑Teilnehmer“ beschrieben.

Soweit Anforderungen den Begriff „Anbieter“ ohne weitere Spezifikation verwenden, ist damit der jeweils serviceverantwortliche Anbieter gemeint.

3.3.2.1.1 Zugelassener Anbieter

Zugelassene Anbieter werden von der gematik nach § 324 SGB V für die Erbringung von Betriebsleistungen zugelassen und erhalten eine Anbieterzulassung.

Der zugelassene Anbieter ist Vertragspartei bzw. Adressat des Zulassungsvertrags bzw. Zulassungsbescheids.

Zugelassene Anbieter erbringen ihre Betriebsleistungen entsprechend der für sie festgelegten Variante des Betreibermodells. Je nach Variante des Betreibermodells können operative Aufgaben insbesondere beim Betrieb, der kontrollierten Inbetriebnahme (KIB), der Nachweisführung sowie im 1st Level Support (UHD/VHD) durch Vertreter bzw. Unterauftragnehmer übernommen werden.

Es gilt:

• die Serviceverantwortung (SV) und Betriebsverantwortung (BV) verbleiben vollständig beim zugelassenen Anbieter,
• der zugelassene Anbieter bleibt alleiniger Adressat der an Anbieter gerichteten Anforderungen der gematik.

3.3.2.1.2 Vertreter zugelassener Anbieter

Der Vertreter zugelassener Anbieter ist eine Rolle innerhalb der Rollenart „Anbieter von Betriebsleistungen“ und kann ausschließlich von zugelassenen Anbietern im Vertretermodell benannt werden.

Ein Vertreter übernimmt die Vertretung im Rahmen der Vertretungsbefugnis, die ihm der zugelassene Anbieter explizit übertragen hat. Dies umfasst insbesondere die Vertretung bei:

• dem Erbringen von Nachweisen im Zulassungsverfahren (z. B. Sicherheitsgutachten, Betriebshandbuch, Anbietererklärung, Prozessprüfung, Bereitstellung der geforderten Ansprechpartner),
• der Durchführung der kontrollierten Inbetriebnahme (KIB),
• der technischen Betriebsführung im Produktivbetrieb (z. B. Betrieb von Diensten, Lieferung von Betriebs‑ und Performancedaten),
• der Übernahme des 1st‑Level‑Supports (UHD/VHD) für Anwender oder Versicherte.

Der Vertreter kann die genannten operativen Tätigkeiten ausführen, handelt jedoch immer im Namen und Auftrag des zugelassenen Anbieters. Für die Verteilung der Verantwortung gilt:

• Adressat der Anforderungen bleibt stets der zugelassene Anbieter,
• der Vertreter besitzt keine eigene Anbieterzulassung,
• Serviceverantwortung und Betriebsverantwortung verbleiben beim zugelassenen Anbieter.
  

Die Benennung eines Vertreters erfolgt im Zulassungsantrag. 

Vertreter sind nicht als Unterauftragnehmer des Legacy-Modells zu interpretieren. Bestehende Anbieterkonstellationen werden im Legacy-Modell gemäß Kap. 3.4.4 Providerspezifische Betreibermodelle - Überblick  geführt.

3.3.2.1.3 Beauftragter Anbieter

Beauftragter Anbieter ist eine Ausprägung der Rolle „Anbieter von Betriebsleistungen“. Beauftragte Anbieter erbringen TI‑Services oder TI‑unterstützende Services auf Grundlage einer Beauftragung durch die gematik nach § 323 Abs. 2 SGB V. 

Sie

• tragen für die vertraglich definierten Services und zugehörigen Servicekomponenten die fachliche und betriebliche Verantwortung,
• benennen gegenüber der gematik keine Vertreter im oben beschriebenen Sinne,
• können auch eine Anbieterzulassung erhalten.

3.3.2.2 Anbieter WANDA für "Weitere Anwendungen und Dienste"

"Weitere Anwendungen oder Dienste" nach § 327 SGB V sind externe digitale Gesundheits‑, Pflege‑ oder Forschungsanwendungen, die nicht selbst Teil der Telematikinfrastruktur sind, aber deren Funktionen nutzen dürfen.

Sie nutzen hierfür Komponenten bzw. Dienste der Telematikinfrastruktur (TI) als sichere Plattform für Vernetzung und Datenaustausch und sind über entsprechende TI-Schnittstellen an die TI angebunden. Sie werden durch die gematik nach § 327 SGB V bestätigt.

Die Rolle Anbieter ist nur für WANDA relevant. Anbieter WANDA ist TI-ITSM-Teilnehmer.

3.3.2.3 gematik-seitige Provider

gematik‑seitige Provider sind interne Organisationseinheiten oder beauftragte Organisationen der gematik, die zentrale Betriebs‑, Integrations‑ und Testdienste bereitstellen. Sie:

• gehören formal zur Provider‑Ebene, sind fachlich der Governance‑Rolle (GTI) zugeordnet,
• betreiben zentrale gematik‑eigene Dienste wie TI‑ITSM‑System, zentrale Monitoring‑/Reporting‑Plattformen oder Test‑ und Referenzdienste in RU/TU ,
• unterstützen andere Rollenarten bei Betrieb, Integration und Tests,
• tragen typischerweise Serviceverantwortung (SV) und Betriebsverantwortung (BV) für die eigenen Dienste im Rahmen interner Vereinbarungen,
• sind TI‑Teilnehmer und in der Regel auch TI‑ITSM‑Teilnehmer.

Die gematik‑internen Provider sind fachlich dem Gesamtverantwortlichen TI zugeordnet, werden im Rollenmodell aber als eigenständige Providerrollen mit klar abgegrenzten Verantwortungen geführt.

3.3.3 Hersteller

Hersteller entwickeln und produzieren Komponenten oder Dienste (Produkte) gemäß den durch die gematik vorgegebenen Spezifikationen. Die Zulassung eines Produktes erfolgt auf Basis des jeweiligen Produkttypsteckbriefs; das Produkt muss der gematik in einer konkreten, prüfbaren Ausprägung vorliegen, die den normativen Anforderungen des jeweiligen Produkttyps genügt. Details zur Zulassung finden sich in § 325 SGB V „Zulassung von Komponenten und Diensten“.

Hersteller leisten – soweit vorgesehen – Support bzw. Mehrwertdienste gegenüber ihren Nutzern (z. B. Fehleranalyse, technische Unterstützung). Produkte bestehen in der Regel aus Hardware‑ und/oder Software‑Komponenten. Ein Produkt kann aus Hardware, Software oder einer Kombination aus beiden bestehen. Entscheidend für die Produktzulassung ist, dass die jeweilige Ausprägung die normativen Anforderungen des Produkttyps erfüllt, unabhängig davon, ob es sich um Hardware, Software oder eine Kombination handelt.

Die Begriffe „Hersteller dezentraler Produkte“ und „Hersteller zentraler Produkte“ sind in [gemGlossar] definiert und beschreiben hauptsächlich den technischen Zuschnitt der Produkte (z. B. Betrieb in der Hoheit der Anwender vs. zentral betriebene Produkte). Für das betriebliche Rollenmodell im Sinne dieses Betriebskonzepts ist jedoch die Unterscheidung nach TI‑ITSM‑Mitwirkung ausschlaggebend:

Hersteller ohne TI‑ITSM‑Mitwirkung:

• sind ausschließlich über die Produktzulassung eingebunden,
• tragen ausschließlich Produktverantwortung (PV) für ihre Produkte,
• tragen keine Verantwortung im TI‑Betriebskontext,
• werden nicht durch den Gesamtverantwortlichen TI gesteuert,
• sind TI‑Teilnehmer, aber keine TI‑ITSM‑Teilnehmer,
• erhalten keine Mitwirkungspflichten im Rahmen des TI‑ITSM.

Hersteller mit TI‑ITSM‑Mitwirkung:

• tragen Produktverantwortung (PV) für ihre Produkte,
• haben Mitwirkungspflichten im TI‑ITSM (z. B. im 2nd‑Level‑Support, Knowledge‑Management) gemäß Kap. 3.5.3 Mitwirkungen im TI-ITSM und [gemRL_Betr_TI],
• übernehmen Verantwortung zur Unterstützung von anderen Providern für die von ihnen verantworteten Produkte,
• werden durch den Gesamtverantwortlichen TI gesteuert,
• sind TI‑Teilnehmer und TI‑ITSM‑Teilnehmer.

Hersteller mit TI‑ITSM‑Mitwirkung unterscheiden sich u.a. in Umfang der Mitwirkung im TI-ITSM, in Nutzung der Betriebsumgebungen und in Art der vertraglichen Bindung (Betreibermodell).

Hersteller mit TI-ITSM-Mitwirkung werden mit Blick auf das Supportkonzept in zwei Untergruppen unterschieden:

• Hersteller mit Incident-Mitwirkung:
  Hersteller mit TI-ITSM-Profil, das im Incident-Management (und ggf. Problem-Management) eine Bearbeitungsrolle (E) vorsieht. Diese Hersteller können im Supportkonzept als 2nd-Level-Supportrollen für ihre eigenen Servicekomponente auftreten.
• Hersteller ohne Incident-Mitwirkung:
  Hersteller mit TI-ITSM-Profil, das im Incident-Management keine Bearbeitungsrolle (E) vorsieht (z. B. nur Mitwirkung in Request Fulfillment oder Knowledge Management). Diese Hersteller sind zwar TI-ITSM-Teilnehmer, agieren im Supportkonzept aber ausschließlich als 3rd-Level-Eskalationsinstanzen hinter einem 2nd-Level-Provider und werden nur über dessen SPOC eingebunden.

Im Supportkonzept (Kap. 3.6 Supportkonzept) werden diese Untergruppen verkürzt als „Hersteller mit Incident-Mitwirkung“ bzw. „Hersteller ohne Incident-Mitwirkung“ bezeichnet.

3.3.4 (End-)Nutzer- und Umfeldrollen

(End‑)Nutzer‑ und Umfeldrollen beschreiben Personen und Organisationen, die TI‑Services im Versorgungsalltag fachlich nutzen oder den Betrieb im lokalen Umfeld unterstützen, ohne selbst Provider in der TI zu sein. Sie nehmen keine Service‑ oder Betriebsverantwortung für zentrale TI‑Services wahr und sind – in ihrer Nutzer‑ bzw. Umfeldrolle – weder TI‑Teilnehmer noch TI‑ITSM‑Teilnehmer.

3.3.4.1 Anwender (User)

Anwender sind natürliche Personen oder Organisationen (Leistungserbringer (LE), Leistungserbringerinstitutionen (LEI)), die berechtigt sind, TI‑Services im Rahmen ihrer Versorgungsprozesse zu nutzen. Sie:

• nutzen TI‑Anwendungen bzw. TI-Services als Servicenehmer in Versorgung und Verwaltung,
• betreiben in ihrem Verantwortungsbereich dezentrale Komponenten (z. B. Konnektoren, Kartenterminals, Primärsysteme) und tragen damit die Betriebsverantwortung (BV) für diese Produkte,
• sind keine TI-Teilnehmer und keine TI‑ITSM‑Teilnehmer,
• bringen Störungen und Serviceanfragen über definierte Supportwege (z. B. UHD und DVO) in den TI‑Betrieb ein (Kap. 3.6 Supportkonzept ).

Hersteller von Primärsystemen können – ungeachtet ihrer eigenen Produktverantwortung – als zusätzliche Anwender dem Nutzerkreis eines UHD zugeordnet werden.

3.3.4.2 Versicherte, Vertreter der Versicherten

Versicherte (VERS)
sind natürliche Personen mit einem Versicherungsverhältnis mit einer gesetzlichen Krankenkasse (GKV) oder privaten Krankenversicherung (PKV) oder weitere Kostenträger (z. B. Heilfürsorge).

Vertreter der Versicherten (VVERS) 
(z. B. gesetzliche Vertreter, Bevollmächtigte oder Beistände, gewillkürte Vertretungen wie Familie, Freunde, etc.) handeln im Rahmen ihrer Vertretungsmacht für den Versicherten.

Versicherte und ihre Vertreter

• nutzen TI‑Anwendungen bzw. TI-Services als Endnutzer (z. B. ePA, E‑Rezept via FdVs),
• sind keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer,
• werden bei Störungen über nutzerseitige Supportkanäle (z. B. VHD) unterstützt (Kap. 3.6 Supportkonzept ).

3.3.4.3 Kostenträger und Institutionen in Nutzerrollen

Kostenträger und Institutionen in Nutzerrolle sind Organisationen, die TI‑gestützte Anwendungen nutzen, ohne in dieser Rolle selbst Provider in der TI zu sein.

Kostenträger (KTR) in Nutzerrolle sind insbesondere gesetzliche Krankenkassen oder private Krankenversicherungen, die

• TI‑basierte Anwendungen und Dienste nutzen (z. B. ePA, eRezept, eAU über KIM),
• gegenüber Versicherten und Leistungserbringern fachliche Aufgaben wahrnehmen (z. B. Genehmigungs‑ oder Abrechnungsprozesse),
• in dieser Nutzerrolle keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer sind.
  

Institutionen (INST) in Nutzerrolle sind z. B. Bundesbehörden oder andere öffentliche Einrichtungen, die

• TI‑gestützte Fachanwendungen oder Datenzugänge verwenden (z. B. Abruf und Verarbeitung von Meldungen, Reports),
• in dieser Rolle ausschließlich als fachliche Nutzer der TI auftreten,
• sind keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer.

Beispiele für Institutionen in Nutzerrolle (nicht abschließend):

• Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) im Kontext elektronischer BTM‑Rezepte (Empfang und Verarbeitung von BTM‑Meldungen aus eRezept‑Workflows), und  elektronischer T‑Rezepte (Empfang und Verarbeitung von Meldungen zu T‑Rezepten im eRezept‑Workflow)

3.3.4.4 Dienstleister vor Ort (DVO)

Dienstleister vor Ort (DVO) sind natürliche Personen die Anwender im lokalen Umfeld bei der Nutzung der TI unterstützen. Sie:

• installieren, konfigurieren, warten und aktualisieren dezentrale Komponenten in Einrichtungen (z. B. Konnektor, Kartenterminals, Primärsysteme),
• unterstützen bei der Fehlerdiagnose und ‑behebung im dezentralen Bereich,
• erfassen und qualifizieren Störungsmeldungen und leiten diese an den zuständigen UHD des Providers weiter,
• unterstützen Anwender bei der Problemlösung und bei der qualifizierten Störungsmeldung gegenüber den zuständigen UHD,
• übernehmen lokale Betriebs‑ und Unterstützungsverantwortung im Rahmen individuell mit Anwenderorganisationen ausgehandelter Verträge.
• sind keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer
• werden nicht durch den Gesamtverantwortlichen TI oder das TI‑ITSM gesteuert. Ihre Steuerung erfolgt ausschließlich vertraglich durch die jeweilige Anwenderorganisation (z. B. Praxis, Klinik, Apotheke).

3.3.4.5 Drittanbieter

Drittanbieter sind Dienstleister, die von Providern beauftragt werden (z. B. für Betrieb, Entwicklung, Support). Sie:

• handeln ausschließlich im Auftrag und unter Verantwortung der sichtbaren Providerrollen,
• werden im Rollenmodell nicht als eigenständige TI‑Rollen mit eigenen Verantwortungsarten geführt,
• sind keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer; sie werden nicht direkt durch den Gesamtverantwortlichen TI gesteuert.

Die Vertragsbeziehungen zwischen Drittanbieter und Auftraggeber (Provider) sind für die gematik intransparent. Aus Sicht der TI:

• tritt ausschließlich der jeweilige Anbieter als sichtbare Rolle auf,
• Drittanbieter sind keine TI‑Teilnehmer und keine TI‑ITSM‑Teilnehmer.

3.3.5 TI-Teilnehmer und TI-ITSM-Teilnehmer

Dieses Kapitel beschreibt, welche Rollen im Sinne des TI-Betriebs als Teilnehmer der TI (TI‑Teilnehmer, TI‑TLN) und welche zusätzlich als Teilnehmer des TI‑weiten IT‑Service‑Managements (TI‑ITSM‑Teilnehmer, TI‑ITSM‑TLN) gelten. Es grenzt damit Providerrollen von (End‑)Nutzer‑ und Umfeldrollen ab und bildet die Grundlage dafür, an welche Rollen sich die betrieblichen Anforderungen und Mitwirkungspflichten richten.

3.3.5.1 TI-ITSM-Teilnehmer

TI‑ITSM‑Teilnehmer (TI-ITSM-TLN) sind Rollen bzw. daraus abgeleitete konkrete Akteure (z. B. „Anbieter E‑Rezept‑Fachdienst“), denen Mitwirkungspflichten in den TI‑ITSM‑Prozessen zugewiesen sind. Die Prozesse und Mitwirkungspflichten sind in [gemRL_Betr_TI] und den begleitenden Leitfäden beschrieben und über Anforderungen den Akteuren zugeordnet.

Als TI‑ITSM‑Teilnehmer gelten folgende Rollenarten:

• Governance-/Integrationsebene:
• Gesamtverantwortlicher TI (gematik),
• Anbieter-/Provider-Ebene:
• zugelassene Anbieter von Betriebsleistungen,
• beauftragte Anbieter,
• Anbieter weiterer Anwendungen oder Dienste (soweit vertraglich explizit vereinbart, perspektivisch in der Rolle Integrator),
• Hersteller-Ebene:
• Hersteller mit TI‑ITSM‑Mitwirkung,

Explizit von der TI‑ITSM‑Teilnahme ausgeschlossen sind:

• Dienstleister vor Ort (DVO),
• (End‑)Nutzer (Anwender, Versicherte und deren Vertreter, Kostenträger und weitere Institutionen in Nutzerrolle),
• Drittanbieter,
• Hersteller ohne TI‑ITSM‑Mitwirkung, 

TI‑ITSM‑Teilnehmer sind immer auch TI‑Teilnehmer. TI‑Teilnehmer müssen jedoch nicht zwingend TI‑ITSM‑Teilnehmer sein.

Die Anforderungen des Betriebskonzepts ([gemKPT_Betr] und der übergreifenden Richtlinien zum TI-Betrieb [gemRL_Betr_TI]) richten sich im Regelfall an TI‑ITSM‑Teilnehmer.

3.3.5.2 TI-Teilnehmer

"TI-Teilnehmer (TI-TLN) sind Rollen, die an der Erbringung und dem Betrieb von TI-Services aktiv mitwirken und deren betrieblichen Ansprechpartner zur Unterstützung der Governance bekannt sein müssen.

TI-ITSM-Teilnehmer sind stets auch TI-Teilnehmer.

Zu den TI-Teilnehmern gehören neben den TI-ITSM-Teilnehmern u.a. auch:

• alle Weitere Anwendungen oder Dienste (auch die, die nicht TI-ITSM-Teilnehmer sind)

(End-)Nutzer-Rollen (Anwender, Versicherte und deren Vertreter, Kostenträger und weitere Institutionen in Nutzerrolle) sowie Umfeldrollen (Dienstleister vor Ort (DVO), Drittanbieter) sind keine TI-Teilnehmer im betrieblichen Sinne, auch wenn sie TI-Services fachlich nutzen oder lokal unterstützen.

3.3.6 Verantwortungsarten der TI-ITSM-Teilnehmer

Dieses Kapitel beschreibt die Verantwortungsarten, mit denen betriebliche Verantwortungsbereiche im TI‑Betrieb strukturiert werden. Es beantwortet die Frage, welche Rolle wofür verantwortlich ist – unabhängig davon, ob Aufgaben delegiert werden.

Zur Beschreibung der Verantwortungsbereiche im TI‑Betrieb werden folgende Verantwortungsarten unterschieden:

• Produktverantwortung (PV),
• Serviceverantwortung (SV),
• Betriebsverantwortung (BV).

Die folgenden Unterkapitel definieren diese Verantwortungsarten; ihre konkrete Zuordnung zu Rollen und Servicemodulen erfolgt über das Rollenmodell (Kap. 3.3 Rollen und Akteure im TI-Betrieb), das Betreibermodell (Kap. 3.4 Betreibermodell) und das Servicemodell (Kap. 3.5 Servicemodell).

3.3.6.1 Produktverantwortung (PV)

Die Produktverantwortung (PV) regelt die Verantwortung eines Herstellers für seine Produkte über den gesamten Produktlebenszyklus hinweg. Der Hersteller stellt insbesondere sicher, dass die Produkte:

• gemäß den Vorgaben aus [gemSpec_OM] versioniert und zugelassen werden und – sofern dem Hersteller entsprechende Anforderungen zugewiesen wurden – dem Change‑ und Configuration‑Management unterliegen,
• den Anforderungen des jeweiligen Produkttypsteckbriefs entsprechen.

Die Produktverantwortung für ein Produkt liegt beim Hersteller, der die Produktzulassung erwirkt. Produkte werden vom Hersteller in der Testumgebung (TU) und ggf. in der Referenzumgebung (RU) bereitgestellt und vom Anbieter in Referenz‑ und Produktivumgebung (RU/PU) betrieben.

Kooperiert ein Hersteller mit einem Anbieter, so vertritt der Anbieter den Hersteller in den TI‑ITSM‑Prozessen (z. B. Change‑ und Configuration‑Management). Die Produktverantwortung verbleibt jedoch beim Hersteller.

3.3.6.2 Serviceverantwortung (SV)

Die Serviceverantwortung (SV) für eine Servicekomponente liegt bei dem Anbieter von Betriebsleistungen, dem diese Servicekomponente im Servicemodell zugeordnet ist. Die Zuordnung einer Servicekomponente zu genau einem Provider wird in dem Servicemodell bzw. der  Servicearchitektur über die Beziehungsart E (Eigener Service) gekennzeichnet (Kap. 3.5 Servicemodell). Die Serviceverantwortung verbleibt vollumfänglich beim Anbieter, auch wenn betriebliche Aufgaben an Vertreter delegiert oder weitere Dienstleister im Auftrag (Drittanbieter) eingesetzt werden. Der serviceverantwortliche Anbieter agiert als „Serviceverantwortlicher“ bzw. serviceverantwortlicher TI‑ITSM‑Teilnehmer.

Die Serviceverantwortung umfasst insbesondere:

• Definition der TI‑Services im Business‑Servicekatalog (einschließlich Servicezeiten, Service Level, Supportmodell) (siehe [TIP1‑A_6367*]),
• Sicherstellung der Einhaltung organisatorischer und technischer Service Level,
• Koordination der beteiligten Provider (Hersteller, Anbieter und Vertreter, Drittanbieter) in der Serviceerbringung und im Support (siehe [TIP1‑A_6377*]),
• Einhaltung der betrieblichen und sicherheitstechnischen Anforderungen,
• Steuerung des Einsatzes von Vertretern und – aus Sicht der TI nicht sichtbaren – Drittanbietern.

Bei der Delegation von Aufgaben an Vertreter oder Drittanbieter verbleibt die Serviceverantwortung (SV) vollständig beim Provider; sie wird durch Delegation nicht übertragen (vgl. [TIP1‑A_6415*]).

3.3.6.3 Betriebsverantwortung (BV)

Die Betriebsverantwortung (BV) beschreibt die Verantwortung für den Betrieb eines Produktes oder Servicekomponente in einer definierten Betriebsumgebung. Sie liegt bei der Rolle, die das Produkt tatsächlich betreibt.

Typische Szenarien sind:

• zugelassene oder beauftragte Anbieter (ggf. mit Vertretern) als Betriebsverantwortlicher für zentrale Komponenten und Dienste der TI‑Plattform,
• Anwenderorganisationen (ggf. mit Dienstleistern vor Ort (DVO)) als Betriebsverantwortlicher für dezentrale Produkte.

Hersteller betreiben in der Regel keine Produktinstanzen in der Produktivumgebung der TI; sie tragen die Produktverantwortung (PV). Spezifische Anforderungen an den sicheren, interoperablen und funktionalen Betrieb in der Produktivumgebung (PU) sind providerspezifisch im Betreibermodell (Kap. 3.4 Betreibermodell) verankert.

3.4 Betreibermodell

Ein Betreibermodell (Delivery Model) beschreibt üblicherweise, wie IT‑Services Ende‑zu‑Ende bereitgestellt werden, welche Rollen beteiligt sind, wie Verantwortungen (fachlich und technisch) verteilt sind, auf welcher vertraglichen Basis Leistungen erbracht werden und wie die Zusammenarbeit und Schnittstellen zwischen den beteiligten Rollen über Umgebungen und Lebenszyklusphasen hinweg organisiert sind.

Im Kontext der TI konkretisiert dieses Betreibermodell,

• welche der in Kap. 3.3 Rollen und Akteure im TI-Betrieb  definierten Providerrollen welche Service‑ und Betriebsaufgaben übernehmen,
• wie die Verantwortungsarten Produkt‑, Service‑ und Betriebsverantwortung auf diese Rollen verteilt sind und
• über welche Verfahrens- und Vertragsarten diese Rollen an die TI und den Gesamtverantwortlichen TI angebunden sind,
• welche Variante des Betreibermodells für einen zugelassenen Anbieter gilt (Vertreter- oder Legacy-Modell).

Die daraus entstehenden Delivery‑Konstellationen werden in den Steckbriefen und in den Tabellen mit der spezifischen Ausprägung konkret abgebildet.

Die grundsätzliche Zuordnung von Rollen zu TI-Teilnahme und TI-ITSM-Teilnahme erfolgt in Kap. 3.3.5 TI-Teilnehmer und TI-ITSM-Teilnehmer .
Das Betreibermodell konkretisiert diese Zuordnung für einzelne Akteure und ergänzt sie um Verfahrens- und Vertragsarten sowie Umgebungen und Betriebsphasen.

Für die in den Tabellen dieses Kapitels geführten Akteure wird jeweils genau eine Variante des Betreibermodells abgebildet: das Vertretermodell als Zielbild oder das Legacy-Modell der Anbieterkonstellationen gemäß Kap. 3.3.2.1 Anbieter von Betriebsleistungen.

Ein Akteur wird entweder in der Tabelle „Tab_gemKPT_Betr_Betreibermodell_providerspezifisch“ oder in der Tabelle „Tab_gemKPT_Betr_Legacy_Anbieterkonstellationen“ geführt. Eine doppelte Abbildung ist nicht zulässig.

Die anzuwendende Variante ergibt sich aus den durch die gematik festgelegten regulatorischen und vertraglichen Vorgaben.

3.4.1 Betriebsphasen und -umgebungen

Die in diesem Betreibermodell beschriebenen Rollen, Verantwortungen und Mitwirkungen gelten grundsätzlich für alle Betriebsumgebungen und Betriebsphasen der TI, sofern in den Steckbriefen oder weiteren verbindlichen Festlegungen nichts Abweichendes geregelt ist. Hierzu zählen insbesondere:

• Testumgebung (TU) – Zulassungs- und Integrationstests,
• Referenzumgebung (RU) – Referenz- und Integrationsbetrieb,
• Produktivumgebung (PU) – betriebliche Anlaufphase (z. B. Kontrollierte Inbetriebnahme/KIB) und Regelbetrieb.

3.4.2 Legacy-Modell: Anbieterkonstellationen und Unterauftragnehmer

Dieses Kapitel beschreibt das Legacy-Modell der Anbieterkonstellationen unter Einbindung von Unterauftragnehmern. Es gilt ausschließlich für Akteure, für die diese Variante durch die gematik festgelegt ist.

Die nachfolgenden Regelungen sind aus der bisherigen Fassung des Betriebskonzepts übernommen. Der Legacy-Block kann entfallen, sobald keine Akteure mehr im Legacy-Modell geführt werden; die tabellarische Abbildung erfolgt in Kap. 3.4.4 Providerspezifische Betreibermodelle - Überblick .

3.4.2.1 Anbieterkonstellationen / Unterauftragnehmer

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

Abbildung 2 : Anbieterkonstallationen

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:

• Anbieter ohne UA (I) - Anbieter ohne Unterauftragnehmer in Konstellation I
• Anbieter mit UA (II) - Anbieter mit Unterauftragnehmer in Konstellation II
• Anbieter mit UA (III) - Anbieter mit Unterauftragnehmer in Konstellation III
• Anbieter mit UA (IV) - Anbieter mit Unterauftragnehmer in Konstellation IV
• UA (II) - Unterauftragnehmer in Konstellation II
• UA (III) - Unterauftragnehmer in Konstellation III
• 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 Tabelle "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 Kap. 3.4.2.2 Teilnahme am TI-ITSM ). 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 Kap. 3.6.5 Providerspezifischer Support), 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 Kap. 3.6.5 Providerspezifischer Support) 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 Kap. 3.6.5 Providerspezifischer Support):
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 Kap. 3.6.5 Providerspezifischer Support):
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.
Für die vorliegende Fassung ist die Abbildung der weiterhin im Legacy-Modell geführten Akteure in Tabelle „Tab_gemKPT_Betr_Legacy_Anbieterkonstellationen“ maßgeblich.

3.4.2.2 Teilnahme am TI-ITSM

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

Tabelle 1: Tab_gemKPT_Betr_TI_001 TI-ITSM-Teilnehmer

3.4.3 Verfahrens- und Vertragsarten

Die vertragliche Bindung von Providerrollen an die TI erfolgt über verschiedene Verfahrens‑ bzw. Vertragsarten. Sie bilden – zusammen mit den Rollen aus Kap 3.3 Rollen und Akteure im TI-Betrieb und der jeweils festgelegten Variante (Vertretermodell oder Legacy-Modell) – den Rahmen für das Betreibermodell.

Mögliche Verfahrensarten sind:

• Zulassung
  Die Organisation erwirbt eine Produkt‑ und/oder Anbieterzulassung bei der gematik auf Basis der jeweiligen Produkt‑ bzw. Anbietertypsteckbriefe.
  
• Beauftragung
  Die gematik beauftragt eine Organisation auf Basis von Produkt‑ bzw. Anbietertypsteckbriefen oder einem Verzeichnis betriebliche Eignung über Nutzungs‑/Dienstleistungsverträge (z. B. für zentrale Infrastruktur‑ oder Unterstützungsservices).
  
• Konformitätsbestätigung (KOB) / Zertifizierung
  Bestätigung der Konformität von Komponenten oder Diensten mit den einschlägigen TI‑Spezifikationen; dient u. a. als Nachweis betrieblicher Eignung.
  
• Bestätigung
  Bestätigung der Eignung zur Nutzung von Anwendungen und Diensten (z. B. für Anbieter weiterer Anwendungen und Dienste nach § 327 SGB V).
  
• gematik‑seitige Vereinbarung
  Wird ein Service durch einen gematik‑seitigen Provider erbracht, erfolgt die Bindung über interne Vereinbarungen auf Basis der jeweiligen Steckbriefe.
  

3.4.4 Providerspezifische Betreibermodelle - Überblick

Die spezifischen Ausprägungen der Akteure werden in Tabelle "Tab_gemKPT_Betr_Betreibermodell_providerspezifisch"  zusammenfassend aufgeführt und in den weiteren Unterkapiteln bei Bedarf konkretisiert.

Die Tabelle „Tab_gemKPT_Betr_Betreibermodell_providerspezifisch“ enthält die Akteure der neuen Tabellenstruktur; die Tabelle „Tab_gemKPT_Betr_Legacy_Anbieterkonstellationen“ enthält die weiterhin im Legacy-Modell geführten Akteure. Jeder Akteur wird genau einmal aufgeführt.

Tabelle 2: Tab_gemKPT_Betr_Betreibermodell_providerspezifisch

Die Spalte „Teilnahme am TI-ITSM (verpflichtend/freiwillig)“ kennzeichnet, ob für die jeweilige Rolle/Ausprägung eine Teilnahme am TI-ITSM:

• verpflichtend ist,
• auf freiwilliger Basis erfolgen kann oder
• nicht vorgesehen ist (n/a).

Freiwillige Teilnahme am TI-ITSM erfolgt aktuell auf Basis einer Nutzungsvereinbarung oder vergleichbarer Vertragskonstellationen zwischen gematik und der jeweiligen Organisation. Verpflichtende Teilnahme wird in der Regel über Zulassungsvertrag/Zulassungsbescheid im Rahmen der Anbieterzulassung oder der Herstellerzulassung, Bestätigung oder Beauftragung (Vertrag) festgelegt.

Tabelle 3 : Tab_gemKPT_Betr_Legacy_Anbieterkonstellaionen

Die Tabelle „Tab_gemKPT_Betr_Legacy_Anbieterkonstellationen“ enthält ausschließlich Akteure im Legacy-Modell. Diese Akteure sind nicht zusätzlich Bestandteil der Tabelle „Tab_gemKPT_Betr_Betreibermodell_providerspezifisch.

3.4.5 Providerspezifische Ergänzungen (Delivery)

Dieses Kapitel enthält providerspezifische Ergänzungen zum Betreibermodell. Es beschreibt zusätzliche betriebliche Vorgaben für ausgewählte Providerrollen, die über die allgemeinen Rollenbeschreibungen in Kap. 3.3 Rollen und Akteure im TI-Betrieb und über Inhalte der  Tabelle "Tab_gemKPT_Betr_Betreibermodell_providerspezifisch" hinausgehen.

Weitere Aspekte werden in folgenden Kapiteln behandelt:

• Supportkonzept (Kap. 3.6 Supportkonzept) – insbesondere providerspezifische Supportvorgaben,
• Monitoring/Reporting (Kap. 4.3 Reporting  / Kap. 4.4 Monitoring) – insbesondere providerspezifische Monitoring‑ und Reportingvorgaben.

3.4.5.1 Anbieter VPN-Zugangsdienst

Für den Anbieter VPN‑Zugangsdienst gelten zusätzlich folgende betriebs­spezifische Vorgaben:

Bereitstellung von Firewall‑Konfigurationsdaten:

Die Veröffentlichung kann z. B. über eigene Support‑Portale oder die TI‑Wissensdatenbank erfolgen; Zielgruppe sind Leistungserbringer und deren IT‑Dienstleister, um lokale Firewalls restriktiv zu konfigurieren und dennoch eine fehlerfreie Kommunikation mit der TI zu ermöglichen.

3.4.5.2 Anbieter ePA-Aktensystem

Für den Anbieter ePA-Aktensystem gelten die in Tabelle "Tab_gemKPT_Betr_Betreibermodell_providerspezifisch" aufgeführten Vorgaben. Der Anbieter kann entscheiden, in welcher Weise er den Betrieb organisiert. Es 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.

Der Anbieter ePA-Aktensystem stellt den Versicherten neben einer elektronische Patientenakte auch einen VHD bereit. Dieser VHD kann von den gesetzlichen Krankenkassen realisiert oder an einen Unterauftragnehmer ausgelagert werden. In jedem Fall ist die gesetzliche Krankenkasse der Adressat der Anbieterzulassung, da sie im Endnutzerverhältnis (zur versicherten Person) die Verantwortung und die Verpflichtung für die Bereitstellung der ePA für ihre Versicherten trägt. Für private Krankenkassen und weitere Kostenträger gilt die Verpflichtung nicht - sie können aber im Rahmen der Freiwilligkeit auch ihren Versicherten eine ePA anbieten.

3.4.5.3 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.5.4 Weitere Anwendungen und Dienste (DiGA)

Digitale Gesundheitsanwendungen (DiGA) werden über ein Bestätigungsverfahren in die TI eingebunden.

Weitere betriebliche Anforderungen in Kap. 6.1 Identity Management sind:

• [A_24349] – Eigenverantwortliche Störungsabwendung einer DiGA
• [A_24354] - Kostenfreier Zugang zur DiGA für Fehlernachstellungen

3.4.5.5 Anbieter Anschlusspunkt am SGW

Die Anbieter Anschlusspunkt am SGW werden innerhalb des Bestätigungsverfahrens Weiterer Anwendungen bestätigt. Dann dürfen diese Anbieter den 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 am SGW 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 am SGW verantwortlich. Im Zuge des betrieblichen Change Managements und bei der Beantragung der Freischaltungen werden diese Rahmenbedingungen sichergestellt.
Der Anbieter Anschlusspunkt am SGW hat dafür Sorge zu tragen, dass nur bestätigte Anwendungen oder zugelassene Dienste an seinem Anschlusspunkt angeschlossen werden.

3.4.5.6 Anbieter TI-Messenger Pro, Anbieter TI-Messenger ePA Fachdienst

Die Anbieter TI‑Messenger Pro und Anbieter TI‑Messenger ePA‑Fachdienst sind als zugelassene Anbieter an die TI gebunden.

Providerspezifisch gilt:

• Der Anbieter TI‑Messenger Pro verantwortet Betrieb und Service der TI‑Messenger‑Infrastruktur für die Nutzergruppe Leistungserbringer (Fachdienst und ggf. zugehörige Clients).
• Der Anbieter TI‑Messenger ePA‑Fachdienst verantwortet analog den Betrieb des TI‑Messenger‑Fachdienstes für die Nutzergruppe Versicherte.

3.4.5.7 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.5.8 Anbieter Sektoraler Identity Provider Kostenträger

Betriebliche Konstellation und Verantwortlichkeit

Unterauftragnehmer / Dienstleister

Hinweis (Übergang Anbieterkonstellationen/Unterauftragnehmer):

Die in A_23201 und A_23411 verwendeten Begriffe „Konstellation I“ und „Unterauftragnehmer“ stammen aus der bisherigen Fassung des Betriebskonzepts [gemKPT_Betr]. In der vorliegenden Version werden Anbieterkonstellationen I–IV und „Unterauftragnehmer“ als eigenständige betriebliche Rollen nicht mehr verwendet.

Die inhaltliche Anpassung der genannten Anforderungen an das neue Rollenmodell erfolgt in einem separaten Änderungsschritt.

Weitere produktspezifische Anforderungen werden in Kap. 6.1 Identity Management aufgeführt insbes.

Release-Umsetzung:

• A_22954 – Umsetzung definierter Releases sek IDP KTR

Mandantenbereitstellung und Datenlieferungen in RU/TU:

• A_25081 – Mandanten für RU/TU (Zulassung sek IDP KTR)
• A_25155 – Mandanten & Betriebsdaten RU/TU (sek IDP KTR)
• A_25147 – Rohdatenlieferung (Zulassung sek IDP KTR)

3.4.5.9 Anbieter TI-Gateway

Der Anbieter TI‑Gateway ist ein zugelassener Anbieter. Das TI‑Gateway stellt einen zentralen Zugangspunkt zur TI dar und ist eng mit weiteren Komponenten (z. B. Highspeed‑Konnektor, Intermediär VSDM) gekoppelt.

Über die allgemeinen Pflichten eines zugelassenen Anbieters hinaus gelten folgende betriebs­spezifische Vorgaben:

Bereitstellung des Dienstes in RU:

Bereitstellung von Firewall‑Konfigurationsdaten:

Die Veröffentlichung kann z. B. über eigene Support‑Portale oder die TI‑Wissensdatenbank erfolgen. Zielgruppe sind Leistungserbringer und deren IT‑Dienstleister, um lokale Firewalls restriktiv zu konfigurieren und gleichzeitig eine fehlerfreie Kommunikation über das TI‑Gateway sicherzustellen.

Supportbezogene Pflichten im Anwendersupport (z. B. Servicezeiten und Dokumentation von Service Levels) werden im Supportkonzept in Kap. 3.6 Supportkonzept beschrieben.

3.4.5.10 Hersteller Versicherten Frontend ePA FdV

Unter „Hersteller Versicherten Frontend“ werden Hersteller von Apps verstanden, die gematik‑spezifizierte Funktionen für Versicherte implementieren.

Providerspezifisch gilt:

• Hersteller Versicherten Frontend gelten als Hersteller mit TI‑ITSM‑Mitwirkung und sind zur aktiven Teilnahme an den TI‑ITSM‑Prozessen verpflichtet, um eine reibungslose Einbindung in die betrieblichen Abläufe und effektive Supportketten zu den angebundenen Fachdiensten sicherzustellen.
• Wird eine App von einer dritten Partei um Funktionen gemäß den Spezifikationen der gematik erweitert, so wird diese Partei im Sinne der Verantwortlichkeiten und Pflichten gleichbedeutend als Hersteller Versicherten Frontend angesehen.
• Für den Hersteller Versicherten Frontend KANN diese TI‑ITSM‑Mitwirkungspflicht entfallen, sofern ausschließlich die ePA‑Funktionalität umgesetzt wird, da bereits der Hersteller ePA-Aktensystems (als Konsortialpartner) die Pflichten im TI-ITSM wahrnimmt. 

3.4.5.11 Hersteller Primärsysteme

Hersteller von Primärsystemen (z. B. PVS, ZPVS, APVS, KIS) sind als Herstellerrolle in Kap. 3.3.2 Provider-Rollen in der Serviceerbringung beschrieben und tragen die Produktverantwortung (PV) für ihre Primärsysteme.

Hersteller von Primärsystemen sind Hersteller ohne TI‑ITSM‑Mitwirkung und sind nicht in das TI‑ITSM insbes. in die Prozesse eingebunden. Sie sind TI-Teilnehmer.

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_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_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.

Tabelle 4: Tab_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_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_Servicekomponenten" 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 5: Tab_gemKPT_Betr_Servicekomponenten 

3.5.3 Mitwirkungen im TI-ITSM

Aufgrund der Mitwirkungs‑ und Unterstützungsverpflichtungen gemäß Tabelle "Tab_gemKPT_Betr_TI_002 „Mitwirkungspflichten der TI‑ITSM‑Teilnehmer“ besteht eine übergreifende Pflicht zur Mitwirkung am TI‑ITSM der gematik. Die Mitwirkung der TI‑ITSM‑Teilnehmer in den TI‑ITSM‑Prozessen wird dabei über TI‑ITSM‑Profile (PP‑xx) modelliert. Jedes Profil beschreibt, in welchen Prozessen ein Akteur typischerweise als Auslöser/Melder (A), als Empfänger/Bearbeiter (E), als vollumfänglich beteiligt (x) oder nicht (.) beteiligt ist. Die Profile werden rollenübergreifend definiert.

Die nachfolgenden Tabellen zeigen – orientiert an den Vorgaben der Richtlinie Betrieb [gemRL_Betr_TI] – die Mitwirkungsverpflichtung in den TI-ITSM-Prozessen sowie die Zuordnung der im aktuellen Zwischenstand verwendeten Profile zu ausgewählten Rollen/Akteuren. Im Fall Hersteller gelten die Profile nur für Hersteller mit TI-ITSM-Mitwirkung. 

Tabelle 6: Tab_gemKPT_Betr_TI-ITSM_Prozessprofile

* sofern in TU vertreten

Bemerkungen:

• zu PP-A-1: Standardprofil für Anbieter (zugelassene/beauftragte Anbieter) mit umfassender TI-ITSM-Mitwirkung in den Kernprozessen
• zu PP-H-1: Hersteller mit sehr begrenzter TI-ITSM-Mitwirkung (Abruf von Service Requests für TU/RU, Teilnahme am Knowledge Management)
• zu PP-H-2: Hersteller mit begrenzter TI‑ITSM‑Mitwirkung für alle Betriebsumgebungen zzgl. die Bearbeitung von Changes
• zu PP-H-3: Hersteller mit erweiterter TI‑ITSM‑Mitwirkung ausschließlich für die Produktivumgebung (PU), insbesondere in Incident‑, Problem‑, Request‑ und Service‑Level‑Management. Dieses Profil ist vorgesehen für Hersteller, die im Zielbild verbindlich für die PU an den Prozessen mitwirken, ohne für die RU/TU aktiv zu sein.

Tabelle 7: Tab_gemKPT_Betr_TI-ITSM_Prozessprofile_Zuordnung_Akteure

Hinweise:

• Die Zuordnung von Herstellern zu 2nd-Level- bzw. 3rd-Level-Supportrollen im Supportkonzept ( ) erfolgt auf Basis der in Kap. 3.3.5 TI-Teilnehmer und TI-ITSM-Teilnehmer  definierten Untergruppen „Hersteller mit Incident-Mitwirkung“ und „Hersteller ohne Incident-Mitwirkung“.
• Tabelle "Tab_gemKPT_Betr_TI-ITSM_Prozessprofile" sowie die Zuordnung weiterer Akteure zu Profilen wird sukzessive ergänzt. Tabelle "Tab_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_Prozesse" wird perspektivisch abgelöst. 

Tabelle 8: Tab_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_Prozesse

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

Legende:

Tabelle 9: Tab_gemKPT_Betr_TI-ITSM-Mitwirkungspflichten_Legende

3.6 Supportkonzept

Dieses Kapitel beschreibt das Supportkonzept der Telematikinfrastruktur (TI) aus Sicht des Nutzersupports. Es legt fest,

• wie der Support für Anwender und Versicherte über UHD/VHD sowie 1st‑, 2nd‑ und 3rd‑Level‑Support organisiert ist,
• welche Supportrollen (UHD, VHD, SPOC) und Verantwortungsarten (Support‑ und Lösungsverantwortung) zu unterscheiden sind und
• welche Mindestservicezeiten und Erreichbarkeiten für die Help Desks gelten.

Das Supportkonzept beschreibt die Struktur und Zuständigkeiten im TI-Support. Die konkrete Ausgestaltung der am Support beteiligten Prozesse (z. B. Incident Management, Request Fulfillment) und der Schnittstellen zum TI-ITSM-System erfolgt in [gemRL_Betr_TI].

Providerspezifische Ergänzungen im Rahmen des Supportkonzepts werden im letzten Abschnitt separat aufgeführt.

Die in diesem Kapitel beschriebenen Supportrollen (1st‑, 2nd‑, 3rd‑Level) werden in den TI‑ITSM‑Prozessen Incident Management und Request Fulfillment genutzt.

3.6.1 Rollen und Schnittstellen im Support

3.6.1.1 Rollen / Funktionen im TI-Support

Für das Supportkonzept werden folgende Funktionsrollen und Funktionen im TI-ITSM unterschieden:

1st-Level-Support:
Eingangsebene für Meldungen von Nutzern (Anwendern und Versicherten). Die Aufgabe ist die Annahme, Klassifikation, Erstdiagnose sowie eine einfache Lösungsbereitstellung für die Meldung. Sie wird organisatorisch umgesetzt durch:

• User Help Desk (UHD) für Anwender (z. B. Leistungserbringer, Leistungserbringerinstitutionen) und DVOs sowie Hersteller Primärsysteme bei der Weiterleitung von Meldungen der Anwender
• Versicherten Help Desk (VHD) für Versicherte und deren Vertreter.

2nd-Level-Support:

Bearbeitung komplexerer Incidents und Service Requests auf Ebene der TI-ITSM-Teilnehmer (insbesondere Anbieter, Hersteller mit TI-ITSM-Mitwirkung).

• Die Anbindung an andere TI‑ITSM‑Teilnehmer erfolgt über die Funktion Single Point of Contact (SPOC) als zentrale 2nd‑Level‑Kontaktstelle eines TI‑ITSM‑Teilnehmers.
• Anbieter übernehmen als serviceverantwortliche Rollen den 2nd-Level-Support für ihre eigenen Services.
• Hersteller mit Incident-Mitwirkung (vgl. Kap. 3.3.2 Provider-Rollen in der Serviceerbringung ) übernehmen für ihre eigenen Servicekomponente die 2nd-Level-Supportrolle (E-Beziehung im Servicemodell) und werden über ihren SPOC direkt adressiert.
  
• Aufgaben des 2nd‑Level‑Supports sind insbesondere: tiefere Fehleranalyse, technische Ursachenforschung, Koordination beteiligter Hersteller und Provider sowie Einleitung notwendiger Korrekturmaßnahmen.

3rd-Level-Support:

3rd‑Level‑Support bezeichnet zusätzliche interne Eskalationsstufen innerhalb der lösungsverantwortlichen Anbieter‑ oder Herstellerorganisation, die über den regulären 2nd‑Level‑Support hinausgehen (z. B. Entwicklungsteams, hochspezialisierte technische Expertengruppen).

• 3rd‑Level‑Rollen werden nicht direkt als eigenständige TI‑ITSM‑Teilnehmer adressiert, sondern ausschließlich über den 2nd‑Level‑Support (SPOC) des jeweiligen TI‑ITSM‑Teilnehmers eingebunden.
• Hersteller ohne Incident-Mitwirkung (vgl. Kap. 3.3.2 Provider-Rollen in der Serviceerbringung) sind zwar TI-ITSM-Teilnehmer, werden im Supportkonzept aber nur als 3rd-Level-Eskalationsinstanzen hinter einem 2nd-Level-Provider geführt und ausschließlich über dessen SPOC eingebunden.
  
• Aufgaben: produktnahe Fehlerbehebung, Umsetzung von Patches/Fixes, tiefgehende Analysen, die typischerweise außerhalb der regulären Betriebsorganisation liegen.

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.
Die normative Definition und Mitwirkungspflichten des SPOC in den TI‑ITSM‑Prozessen werden in Kap. 3.5.3 Mitwirkungen im TI-ITSM festgelegt ([TIP1‑A_6371*]). Dieses Kapitel betrachtet den SPOC ausschließlich in seiner Rolle als 2nd‑Level‑Supportinstanz im Nutzersupport (Incident Management, Request Fulfillment).

Abbildung 3 : Supportkonzept - Supportstufen und Supportrollen in der TI

Legende:

• 1st‑Level = Nutzersupport (UHD/VHD),
• 2nd‑Level = SPOC‑basierter TI‑ITSM‑Support,
• 3rd‑Level = interne Expertenebenen.

Weitere Nutzerrollen gemäß Kap. 3.3 Rollen und Akteure im TI-Betrieb  haben keinen Zugriff auf den UHD/VHD.

3.6.1.2 Meldungsarten im Nutzersupport

Für das Supportkonzept werden Meldungen aus Sicht der UHD/VHD wie folgt unterschieden:

Meldungen werden unterschieden in:

• Störungen (Incidents):
  tatsächliche oder vermutete Beeinträchtigungen der Funktion eines TI-Services (z. B. Fehlermeldungen, Ausfälle, starke Performance-Einbrüche), welche die bestimmungsgemäße Nutzung beeinträchtigt.
• Anfragen (Service Requests / allgemeine Anfragen der Nutzer): jedes Anliegen ohne unmittelbare Störung, insbesondere Informations‑, Beratungs‑ oder Unterstützungsbedarf (z. B. Bedienfragen, Konfigurationsnachfragen).
• Rückmeldungen und Beschwerden: wahrgenommenen Qualitätsproblemen oder Unzufriedenheit mit der Leistungserbringung.

UHD/VHD müssen Meldungen so qualifizieren, dass eine sinnvolle Zuordnung zu den TI-ITSM-Prozessen (insbesondere Incident Management und Request Fulfillment) sowie zu den betroffenen Servicekomponenten möglich ist.

3.6.1.3 Verantwortungsarten im Support

Es werden folgende Verantwortungsarten unterschieden:

Supportverantwortung bezeichnet die Verantwortung für:

• die Annahme von Meldungen eines definierten Melderkreises,
• die Erstqualifizierung und ggf. Erstlösung einer Meldung,
• die Sicherstellung der weiteren Bearbeitung (inklusive Koordination von Weiterleitungen und Rückmeldungen) sowie
• die laufende Kommunikation mit dem Melder (Status- und Lösungsinformationen).

Sie liegt bei dem 1st‑Level‑Support des TI‑ITSM‑Teilnehmers, der die UHD-/VHD‑Funktion gegenüber dem Melder wahrnimmt. Im Rahmen dieser Supportverantwortung stellt der 1st‑Level‑Support die Einhaltung der für ihn geltenden Anforderungen bzgl. Servicezeiten und Erreichbarkeit sicher.

Lösungsverantwortung bezeichnet:

• die tatsächliche Behebung einer Störung, (Umsetzung von Korrekturen oder Workarounds),
• die Ursachenanalyse
• die Sicherstellung der dauerhaften Funktionsfähigkeit der betroffenen Servicekomponenten,
• die Rückmeldung an den meldenden UHD/VHD (falls dieser involviert war), sowie
• die Dokumentation im lokalen bzw. TI-ITSM.

Lösungsverantwortung liegt bei dem Akteur, der die jeweilige Servicekomponente TI‑weit zugeordnet ist (in der Regel der Provider des entsprechenden Dienstes, E). Die konkrete Zuordnung der Lösungsverantwortung ist in Tabelle "Tab_gemKPT_Betr_TI-ITSM_Mitwirkungspflichten_TI-ITSM-Teilnehmer" ersichtlich.

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 Provider delegiert.

3.6.2 Kommunikationswege und Erreichbarkeit im Support (SPOC, UHD/VHD)

Dieses Kapitel legt den UHD/VHD (1st‑Level) und den SPOC (2nd‑Level) als Kontaktstellen im Nutzersupport fest. Es beschreibt,

• über welche Kommunikationswege (z. B. elektronische Kanäle, Telefon) diese Kontaktstellen erreichbar sind und
• in welchem Umfang diese Kanäle innerhalb und außerhalb der Servicezeiten zur Verfügung stehen (Erreichbarkeit).

Die konkreten Mindestservicezeiten der Help Desks sind in 3.6.3 Mindestservicezeit im Nutzersupport beschrieben.

Jeder Provider benennt einen Single Point of Contact (SPOC) als zentrale 2nd‑Level‑Kontaktstelle gegenüber anderen TI‑ITSM‑Teilnehmern. UHD/VHD sind die 1st‑Level‑Kontaktstellen für Anwender und Versicherte und nehmen Meldungen aus dem Nutzersupport entgegen. Die Benennung eines SPOCs und die generellen Mitwirkungspflichten im TI‑ITSM werden in Kap.  4 Verantwortlichkeiten und Leistungen TI-ITSM-Teilnehmer  sowie in Kap. 3.5.3 Mitwirkungen im TI-ITSM  normativ festgelegt (insbesondere durch TIP1‑A_6371*). Dieses
Kapitel konkretisiert ergänzend die geforderten Kommunikationswege für UHD, VHD und SPOC.

im 1st-Level-Support:

Für den VHD gelten hinsichtlich der Kommunikationswege dieselben Grundsätze wie für UHD und SPOC. Die VHD‑spezifische Anforderung zur Erreichbarkeit (Kanäle) wird wie folgt geregelt:

im 2nd-Level-Support:

3.6.3 Mindestservicezeit im Nutzersupport

Dieses Kapitel definiert die Mindestservicezeiten der Help Desks (UHD/VHD) im Nutzersupport und grenzt sie von anderen Servicezeit‑Begriffen ab. Die Anforderungen an Kommunikationswege und Erreichbarkeit der Kontaktstellen sind in Kap. 3.6.2 Kommunikationswege und Erreichbarkeit im Support (SPOC, UHD/VHD)  beschrieben.

3.6.3.1 Begriffe und Abgrenzung

Mindestservicezeit (HD) ist der Zeitraum, in dem ein UHD bzw. VHD aktiv Supportleistungen für Anwender bzw. Versicherte mindestens erbringen muss (Annahme und Bearbeitung von Meldungen).

Mindestservicezeit (HD) unterscheidet sich von:

• Servicezeit (TI‑ITSM)  und den damit verbundenen organisatorischen Service Leveln,
• Servicezeit (Perf) im Performance‑Kontext als Bewertungszeitraum für technische Service Level und Performance‑Kenngrößen.

3.6.3.2 Mindestservicezeit des UHD

Die Mindestservicezeiten für den Anwendersupport (UHD) werden durch folgende Anforderungen festgelegt:

3.6.3.3 Mindestservicezeit des VHD

Die Mindestservicezeiten für den Versichertensupport (VHD) werden wie folgt festgelegt:

3.6.4 Supportketten und Weiterleitung

In diesem Kapitel wird beschrieben, welche Akteure eine Weiterleitungspflicht haben (i.d.R. alle Provider) und was diese Pflicht an Aufgaben bzw. Verantwortungen umfasst.    

3.6.4.1 Weiterleitung von Meldungen

Die Weiterleitungspflicht von nicht lösbaren Meldungen wird TI-weit einheitlich geregelt:

UHD/VHD und SPOC haben dabei insbesondere sicherzustellen, dass:

• Meldungen hinreichend qualifiziert werden (u. a. Beschreibung, Betroffenheit, Priorität, betroffene Servicekomponenten),
• nicht lösbare Meldungen an den lösungsverantwortlichen Anbieter delegiert werden,
• Ablehnungen nachvollziehbar und begründet erfolgen (z. B. falscher Adressat, außerhalb des Verantwortungsbereichs).

Die Supportverantwortung gegenüber dem ursprünglichen Melder verbleibt bei dem Akteur, die die UHD/VHD-Funktion wahrnimmt; diese Rolle bleibt primärer Ansprechpartner für den Melder, auch wenn die bearbeitende Instanz im TI-ITSM wechselt.

3.6.4.2 Typische Supportketten bzw. -szenarien

Szenario 1: TI 1.0 – Störungsmeldung durch Anwender/Versicherte für TI-Anwendungen:

• Anwender bzw. DVO melden Störungen/Anfragen zu TI‑Services:
• direkt beim UHD des Anbieters VPN‑Zugangsdienst bzw. TI‑Gateway oder
• zunächst beim Hersteller des Primärsystems; dieser eröffnet bei Bedarf nach einer ersten Bewertung eine Meldung beim UHD des Anbieters VPN‑Zugangsdienst/TI‑Gateway
• Versicherte bzw. ihre Vertreter melden Störungen/Anfragen beim VHD ihrer Krankenkasse oder des jeweils verantwortlichen Anbieters (z. B. ePA‑Aktensystem, eRezept‑FdV)
• UHD bzw. VHD übernehmen Annahme, Qualifizierung und Zuständigkeitsprüfung der Meldungen.

Szenario 2: TI 2.0 – Störungsmeldung durch Anwender/Versicherte für TI-Anwendungen:

< in Ausbau >

Es gilt (TI 1.0):

• Nicht lösbare Meldungen werden entsprechend der E/U/V‑Zuordnung an den lösungsverantwortlichen Provider über den 2nd‑Level‑Support (SPOC) im TI‑ITSM weitergeleitet.
• Hersteller mit TI‑ITSM‑Mitwirkung werden gemäß ihrer Supportrolle eingebunden:
• Hersteller mit Incident-Mitwirkung (TI‑ITSM‑Profil mit Bearbeitungsrolle im Incident‑Management) werden für ihre eigenen Servicekomponenten über ihren SPOC adressiert.
• Hersteller ohne Incident-Mitwirkung (TI‑ITSM‑Profil ohne Incident‑Bearbeitungsrolle, z. B. nur Request Fulfillment/Knowledge Management) werden als 3rd‑Level‑Eskalationsinstanz durch den 2nd‑Level‑Provider eingebunden.
• UHDs (einschließlich TI‑Help‑Desk), VHDs und 2nd‑Level‑Support nutzen ihre jeweiligen lokalen ITSM‑Systeme; die Kommunikation zwischen 2nd‑Level‑Supportrollen erfolgt über das TI‑ITSM‑System
• UHD/TI‑Help‑Desk bzw. VHD tragen die Supportverantwortung gegenüber den Meldergruppen (Annahme, Erstqualifizierung, Status‑/Lösungsinformationen)
• Die Verantwortung zur Weiterleitung im Sinne von [TIP1‑A_6393*] liegt bei den Supportrollen, die Meldungen entgegennehmen und weiterverteilen (insbesondere UHD/TI‑Help‑Desk, VHD und 2nd‑Level/SPOC).
• Die Lösungsverantwortung verbleibt bei den Akteuren, denen die betroffenen Servicekomponenten im Servicemodell mit der Beziehungsart E – Eigener Service zugeordnet sind.

Abbildung 4 : Supportkonzept für Servicemodule (Szenario 1)

3.6.5 Providerspezifischer Support

Dieser Abschnitt umfasst die providerspezifischen konkreten Ausprägungen des Supportkonzepts. in Tabelle "Tab_gemKPT_Betr_TI-ITSM-Teilnehmer_UHD/VHD" wird die aktuelle Konfiguration gemäß der Anforderungen als Übersicht dargestellt. Sind spezifische Ergänzungen notwendig, so werden diese in separaten Unterkapiteln ergänzt. 

3.6.5.1 Übersicht über Umsetzung der Help Desks durch Provider

Tabelle 10: Tab_gemKPT_Betr_TI-ITSM-Teilnehmer_UHD/VHD

* [außer an bundeseinheitlichen Feiertagen]

3.6.5.2 Anbieter Sektoraler Identity Provider für Kostenträger

Der Anbieter Sektoraler Identity Provider Kostenträger 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 Kostenträger muss keinen VHD und keinen UHD stellen.

3.6.5.3 Anbieter VPN‑Zugangsdienst / Anbieter TI-Gateway

Der Anbieter VPN-Zugangsdienst bzw. Anbieter TI-Gateway stellen im Rahmen der TI 1.0 den Anwendern einen UHD zur Verfügung. Es gelten insbesondere:

• UHD mit Mindestservicezeit 24/7 gemäß [A_19532*],
• spezifizierte 24/7-Mindestservicezeit für den 1st-Level-UHD gemäß [TIP1-A_6420*],
• Dokumentation von Service Levels im Anwendersupport einschließlich Serviceklassen,

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.

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

Überwachung

Koordination von Serviceleistung

Auskunftsfähigkeit bei Servicebeeinträchtigungen

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

4.3 Reporting

Als Voraussetzung für das mit den TI-ITSM-Teilnehmern monatlich durchzuführende Service Level-Review (siehe [gemRL_Betr_TI#Service Level Management]) müssen die hierfür notwendigen Service Level-Reports fristgerecht zur Verfügung stehen.

Die Service Level-Reports werden im Rahmen des Reportings vom Gesamtverantwortlichen TI generiert. Dies erfolgt i.d.R. bis zum 10. Arbeitstag des auf dem Bewertungszeitraum folgenden Kalendermonats.

Hierzu müssen spätestens alle für den jeweiligen Anbieter relevanten Performancedaten (gemäß [gemSpec_Perf]) bis zum 5. Arbeitstag dem Gesamtverantwortlichen TI vorliegen ([A_26816]).

Die Service-Level-Reports basieren auf den definierten organisatorischen Service Leveln (siehe Kap .5.2 Organisatorische Service Level) und den technischen Service Leveln (siehe Kap. 5.3 Technische Service Level / Performance-Kenngrößen sowie [gemSpec_Perf]). Erstere nutzen die Messdaten des TI-ITSM-Systems bzw. manuell erfasste Daten und letztere werden auf Basis der ordnungsgemäßen Betriebsdaten gemäß [gemSpec_Perf#Kap. 2.5.1] generiert.

Die Service Level-Reports müssen spätestens bis zum 13. Arbeitstag (entspricht 104 Stunden zur Hauptzeit) von den jeweiligen TI-ITSM-Teilnehmern kommentiert und finalisiert werden, so dass ein Service Level-Review fristgerecht durchgeführt werden kann.

Weitere Datenlieferungen (bspw. Bestandsdaten) sind in [gemSpec_Perf] definiert.

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 überwacht (z.B. Probing oder Datenlieferungen). 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 überwacht und im Falle einer Störung oder beim Auftreten von Besonderheiten oder Anomalien angemessen reagiert.

4.4.1 Probing

Das "Probing" ist ein wesentlicher Bestandteil der Überwachung der TI, bei dem über das gezielte Senden von Anfragen bzw. Aufruf der Schnittstellen der Status bzw. die Verfügbarkeit von TI-Produkten und deren Schnittstellen geprüft werden. Die gezielten Anfragen werden "Probes" genannt. Verantwortlich für die Ausführung und Auswertung der Probes ist die gematik.

4.4.2 Eigenmonitoring und Anomalieerkennung

Unter "Eigenmonitoring" wird die systematische Beobachtung des Systems des Anbieters durch den Anbieter selbst verstanden und befähigt den Anbieter dazu, dass er umgehend und selbstständig auf Fehler und unübliches Systemverhalten (Anomalien) aufmerksam wird und dementsprechende Gegenmaßnahmen und Kommunikationen einleiten kann.

Monitoring Spezifika E-Rezept 

5 Kenngrößen und Service Level

5.1 Begriffserläuterung

5.1.1 Quantil / Erfüllungsquote

Quantil

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.

Erfüllungsquote

Die Erfüllungsquote wird bei den organisatorischen Service Leveln pro Kenngröße (SL-ID) je Betriebsumgebung ermittelt.

Für Vorgänge im TI-ITSM:
Die Erfüllungsquote ist das Verhältnis von SL-konformen Vorgängen (z.B. Reaktions--/Lösungszeiten) zur Gesamtzahl der Vorgänge im Betrachtungszeitraum. Wenn die Erfüllungsquote unterschritten wird, gilt der Service Level als verletzt bzw. nicht eingehalten.

5.1.2 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 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.2 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.3 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 11: Tab_gemKPT_Betr_OrgSL_Serviceleistung_Zeiten

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

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

Tabelle 12: Tab_gemKPT_Betr_TI-ITSM_Service-Level_Zeiten

* 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-03 - Serviceleistung der TI-ITSM-Teilnehmer im TI-ITSM-Teilnehmersupport zur Hauptzeit

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

Tabelle 13: Tab_gemKPT_Betr_TI-ITSM_Service-Level_Zeiten_Alternativen

* 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. 

Weitere Organisatorische Service Level

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

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 

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

[Inhalt wurde nach gemSpec_Perf überführt]

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

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.

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: 

7 Anhang A – Ergänzende Tabellen

7.1 Definitionen

7.1.1 Produkttypen (PDT-IDs)

Tabelle 15: Tab_gemKPT_Betr_Produkttypen

7.1.2 Performance-Dimensionen

[Inhalt wurde nach gemSpec_Perf überführt]

7.1.3 Aufrufquelle

 [Inhalt wurde nach gemSpec_Perf überführt]

7.2 Performance-Größen

 [Inhalt wurde nach gemSpec_Perf überführt]

7.2.1 Dimension Last

 [Inhalt wurde nach gemSpec_Perf überführt]

7.2.2 Dimension Bearbeitungszeit

 [Inhalt wurde nach gemSpec_Perf überführt]

7.2.3 Dimension Verfügbarkeit

 [Inhalt wurde nach gemSpec_Perf überführt]

8 Anhang B – Verzeichnisse

8.1 Abkürzungen

Tabelle 16: Tab_gemKPT_Betr_Abkürzungsverzeichnis

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

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.

8.5.2 Weitere Dokumente