C_11933_Anlage_V1.0.0


C_11933_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

in gemKPT_Betr:

  • Entfernen der Anbieterkonstellationen (I–IV) und der Rolle „Unterauftragnehmer“ sowie Einführung der Rolle „Vertreter" für zugelassener Anbieter (inkl. rechtlicher Herleitung aus § 323/324 SGB V).
  • Präzisierung der Rolle „zugelassener Anbieter“ und Ergänzung der Rolle „beauftragter Anbieter“ als eigenständige Providerrolle.
  • Entfernen der Rolle „Service Provider TI‑unterstützender Produkte“ als eigenständige betriebliche Rolle; Einordnung entsprechender Akteure in die neuen Rollenarten (insb. Hersteller mit TI‑ITSM‑Mitwirkung bzw. beauftragte Anbieter).
  • Restrukturierung des bisherigen Kapitels „Rollen im Betrieb“ zu einem Rollenmodell mit klaren Rollenarten (Governance, Provider, Hersteller, (End‑)Nutzer, Umfeld, spezialisierte Fachdienste öffentlicher Institutionen).
  • Entfernen der betrieblichen Rolle „Betreiber“ und Einführung der Betriebsverantwortung als eigener Verantwortungsart; Betreibermodelle werden über Provider‑, Anwender‑ und gematik‑seitige Rollen beschrieben
  • Zusammenführung der gematik‑Rollen zu Governance‑/Providerrollen (GTI + gematik‑seitige Provider); „gematik Test“, „gematik Betrieb“ entfallen und „gematik TI‑Help‑Desk“ wird als gematik‑seitiger Provider geführt.
  • Konkretisierung der Rolle „TI‑ITSM‑Teilnehmer“ und Ergänzung der Rolle „TI‑Teilnehmer“ mit klarer Abgrenzung;
  • Konkretisierung der Rollenbeschreibungen für (End‑)Nutzer und Umfeld (Anwender, Versicherte/Vertreter, Kostenträger, Drittanbieter, Dienstleister vor Ort).
  • Unterteilung der Rolle „Hersteller“ in Hersteller mit TI‑ITSM‑Mitwirkung und Hersteller ohne TI‑ITSM‑Mitwirkung; Klarstellung, dass Hersteller ohne TI‑ITSM‑Mitwirkung nicht in TI‑ITSM‑Prozesse eingebunden sind.
  • Neustrukturierung des Betreibermodells in Kap. 3.4 (Verfahrens‑ und Vertragsarten, providerspezifische Betreibermodelle inkl. Tabelle „Tab_gemKPT_Betr_Betreibermodell_providerspezifisch“ sowie providerspezifische Ergänzungen für ausgewählte Rollen wie VPN‑Zugangsdienst, ePA‑Aktensystem, WANDA/DiGA, sek IDP KTR, TI‑Gateway, Hersteller Versicherten‑Frontend, Hersteller Primärsysteme, gematik TI‑Help‑Desk).
  • Ergänzung von Kap.  3.5.3 „Mitwirkungen im TI‑ITSM“ um eine profilbasierte Darstellung der Mitwirkung in den TI‑ITSM‑Prozessen sowie Übernahme der bisherigen Mitwirkungsmatrix; Kennzeichnung der Tabelle „Tab_gemKPT_Betr_TI_003 Mitwirkungsverpflichtung im TI‑ITSM“ als Übergangsartefakt, das perspektivisch durch die profilbasierte Darstellung abgelöst wird.
  • Einfügen eines Kapitels zu den Verantwortungsarten (Produkt‑, Service- und Betriebsverantwortung) mit Zuordnung zu Rollen; die Produktverantwortung wird primär beim Hersteller verortet; die Serviceverantwortung verbleibt bei den Rollen, die Betriebsverantwortung liegt bei den Rollen, die Produkte oder Services tatsächlich betreiben.
  • Ersetze Service Provider Fachdienst National Contact Point for eHealth durch Anbieter Fachdienst National Contact Point for eHealth.

in gemRL_Betr_TI:

  • Anpassung der Anforderung A‑26502 zu A‑26502‑01 „Kommunikation – Benennung von Ansprechpartnern und Kontakten (LITE)“: Klarstellung, dass alle TI‑ITSM‑Teilnehmer (außer (End‑)Nutzer) benannte Ansprechpartner und Funktionskontakte im TI‑ITSM‑System hinterlegen und aktuell halten müssen; die Zuordnungen zu bestehenden Rollen bleiben unverändert.

Rechtliche Grundlage für die Entfernung der verschiedenen Anbieterkonstellationen und der Einführung der Rolle Vertreter im Rahmen der Anbieterzulassung:

Die Anbieterzulassung der gematik basiert u.a. auf den gesetzlichen Vorgaben in §§ 323, 324 SGB V. Demnach werden Anbieter von Betriebsleistungen durch die gematik zugelassen, wenn die in § 324 Abs. 1 SGB V genannten Voraussetzungen vorliegen.

Anknüpfungspunkt für die Anforderungslage der von der gematik auszusprechenden Anbieterzulassung ist das Rechtsverhältnis zwischen dem Nutzer der Leistung bzw. dem datenschutzrechtlich Betroffenen (im Folgenden einheitlich: Endkunden) und demjenigen, der die Leistung an den Endkunden bereitstellt, da die Anforderungen der gematik im Verhältnis zum Endkunden ihre Wirkung entfalten sollen (Ende-zu-Ende-Verantwortung).

Gleichzeitig soll der zugelassene Anbieter die Möglichkeit erhalten, sich im Rahmen der betrieblichen Prozesse innerhalb der TI vertreten zu lassen. Um ihm dies zu ermöglichen, wird es künftig im Rahmen der Beantragung einer Zulassung die Möglichkeit geben einen Vertreter für das TI-ITSM zu benennen, der als Ansprechpartner im Rahmen der betrieblichen Prozesse auf Seiten des zugelassenen Anbieters dient.

Hinweise zur Lesart (Markierungen im Änderungseintrag)

Zur besseren Nachvollziehbarkeit der Änderungen werden im Änderungseintrag folgende Markierungen verwendet:

  • << neu >> kennzeichnet neu eingefügten oder vollständig neu formulierten Text, der in das Zieldokument (z. B. gemKPT_Betr) übernommen werden soll
  • << alt >> kennzeichnet die bisherige Fassung eines Textabschnitts, die durch die unter << neu >> angegebene Fassung ersetzt bzw. entfernt wird.
  • << Kommentar … >> oder ähnliche eingeschobene Hinweise dienen ausschließlich der Erläuterung im Rahmen des Änderungseintrags und werden nicht in das Zieldokument übernommen.
  • Text, der neu ist
  • Text, der entfernt wird.

Die farbliche Hervorhebung, Durchstreichungen oder Kommentar‑Blöcke im Word‑Dokument dienen ebenfalls nur der Dokumentation der Änderungen und haben keine normative Wirkung in der endgültigen Spezifikation.

2 Änderung in gemKPT_Betr

<<

Restrukturierung der Kapitel sowie thematischer Ausbau der Inhalte:

  • Thema Rollen und Akteure wird vor die Definition der TI-ITSM-Teilnehmer gesetzt (Kap 3.3).
  • Nach Kapitel Rollen und Akteure werden die TI- und TI-ITSM-Teilnehmer spezifiziert (Kap 3.3.6).
  • Darauf baut in jeweils einem separaten Unterkapitel das Betreibermodell (Kap. 3.4) und die Mitwirkungen im TI-ITSM auf (Kap 3.5.3); das Supportkonzept schließt in Kap. 3.6 an. 
  • Weitere Kapitel von gemKPT_Betr bleiben unverändert.

>>

2.1 Kap 3: Servicekonzept

2.1.1 Kap 3.1: Begriffserläuterungen

<< unverändert >>

2.1.2 Kap 3.2: Übergreifendes IT-Service-Management der TI

<< unverändert >>

2.1.3 Kap 3.3: Rollen und Akteure im TI-Betrieb - [NEU STRUKTURIERT]

<< alt>>

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

Hinweis zum Folgerelease:

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

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

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

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

<< neu >>

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) und das Servicemodell (Kap. 3.5). 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.

Figure # : Rollen im TI-Betrieb

2.1.3.1 Kap 3.3.1: Governance- und Integrations-Rollen [NEU]

<< neu >>

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, Help-Desk), 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.

2.1.3.1.1 in Kap 3.3.1.1: Gesamtverantwortlicher TI (GTI)

<< alt>>

Der Gesamtverantwortliche TI (GTI) übernimmt die

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

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

<< neu >>

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

2.1.3.2 Kap 3.3.2: Provider-Rollen in der Serviceerbringung [NEU]

<< neu >>

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.

2.1.3.2.1 neu Kap 3.3.2.1: Anbieter von Betriebsleistungen

<< alt>>

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

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

<< Folgende Afo und nachfolgender Text entfällt, da der Inhalt der Anforderung bereits im Gesetz verankert ist und hier im Rahmen des Betriebsmodells keinen inhaltlichen Mehrwert liefert >>

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

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

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

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

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

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

<< neu >>

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.

Delegation von Aufgaben (z. B. Betrieb, Nachweisführung, UHD/VHD) ist möglich, jedoch bleibt der Anbieter stets Adressat der Anforderungen der gematik. Delegation erfolgt an:

  • Vertreter (nur bei zugelassenen Anbietern; sichtbare Rolle im TI‑Betrieb), oder
  • Drittanbieter (nicht sichtbare Rolle im Hintergrund).

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

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

2.1.3.2.1.1 neu Kap 3.3.2.1.1: Zugelassener Anbieter

<< neu >>

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 können sich im Rahmen der Anbieterzulassung und des Betriebs durch Vertreter vertreten lassen. Der zugelassene Anbieter kann sich insbesondere beim Betrieb, der kontrollierten Inbetriebnahme (KIB), der Nachweisführung sowie den 1st‑Level‑Support (UHD/VHD) durch einen benannten Vertreter vertreten lassen.

Es gilt:

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

2.1.3.2.1.2 neu Kap 3.3.2.1.2: Vertreter zugelassener Anbieter

<< alt>>

<< Unterauftragnehmer entfällt>>

<< neu >>

Der Vertreter zugelassener Anbieter ist eine Rolle innerhalb der Rollenart „Anbieter von Betriebsleistungen“ und kann ausschließlich von zugelassenen Anbietern 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. 

Hinweis: Die in vorherigen Versionen von [gemKPT_Betr] dargestellten Unterauftragnehmer und ihre Konstellationen in Bezug zum Anbieter werden nun durch das Modell Zugelassener Anbieter / Vertreter ersetzt.


2.1.3.2.1.3 neu Kap 3.3.2.1.3: Beauftragter Anbieter

<< neu >>

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 gegenüber ihren Servicenehmern,
  • benennen gegenüber der gematik keine Vertreter im oben beschriebenen Sinne,
  • können auch eine Anbieterzulassung erhalten.

2.1.3.2.2 Kap 3.3.2.5: Anbieter WANDA für "Weitere Anwendungen und Dienste"[NEU]

<< alt>>

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” … Die Anbieter WANDA Basic, WANDA Smart, WANDA Smart Hosting und Anbieter Anschlusspunkt sind im TI-ITSM vertreten.

<< neu >>

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

2.1.3.2.3 in Kap 3.3.2.6: gematik-seitige Provider [ÜBERARBEITET]

<< Rollen gematik Test und gematik Betrieb werden aktuell nicht im Kontext des TI-Betriebsmodells genutzt; Rollen können bei erfolgter Definition (inkl. der Aufgaben) wieder itengriert werden >

<< alt>>

gematik-Test in der TU

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

<< neu >>

gematik‑seitige Provider sind interne Organisationseinheiten oder beauftragte Organisationen der gematik, die zentrale Betriebs‑, Integrations‑ und Test- und Supportdienste 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 sowie zentrale Support‑Funktionen für TI‑ITSM‑Teilnehmer,
  • unterstützen andere Rollenarten bei Betrieb, Integration und Tests und übergreifenden Support,
  • 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.

Aktuell relevante Rolle ist:

  • gematik TI‑Help-Desk (Detaillierung in Kap. 3.6 "Supportkonzept"):
    • gematik‑interner Provider, der für Anwender, Dienstleister vor Ort (DVO) und Hersteller von Primärsystemen einen zentralen User Help Desk (UHD) als 1st‑Level‑Support bereitstellt,
    • übernimmt die Supportverantwortung gegenüber diesen Meldergruppen (Annahme, Erstqualifizierung, Status‑ und Lösungsinformationen) im Rahmen eines eigenen lokalen ITSM‑Systems,
    • ist TI‑Teilnehmer im Sinne eines zentralen UHD‑Providers, aber kein TI‑ITSM‑Teilnehmer; die Kommunikation mit anderen TI‑ITSM‑Teilnehmern erfolgt über die SPOC‑/2nd‑Level‑Rollen der jeweiligen Provider,
    • wird im Zielbild ausschließlich für TI‑2.0‑Services eingesetzt; in diesem Kontext stellen Anbieter VPN‑Zugangsdienst bzw. Anbieter TI‑Gateway keinen eigenen UHD mehr bereit.

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

2.1.3.2.4 Kap 3.4.x: Betreiber [ENTFÄLLT]

<< Betreiber wird normativ nicht verwendet. Es ist aktuell nur die Kombination zugelassener Anbieter und Vertreter gültig. >>

<< alt>>

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

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

2.1.3.2.5 Kap 3.4.x: Service Provider TI‑unterstützender Produkte [ENTFÄLLT]

<< wird aktuell nicht genutzt; kann bei konkretem Bedarf wieder eingearbeitet werden >>

<< alt>>

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

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

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

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

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

2.1.3.3 Kap 3.3.3: Hersteller [ÜBERARBEITET]

<< alt>>

Hersteller dezentraler Produkte

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

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

Hersteller zentraler Produkte

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

<< neu >>

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 übernehmen die Produkthaftung gemäß den gesetzlichen Vorgaben und 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 „TI‑ITSM‑Mitwirkung“ 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) werden diese Untergruppen verkürzt als „Hersteller mit Incident-Mitwirkung“ bzw. „Hersteller ohne Incident-Mitwirkung“ bezeichnet.

2.1.3.4 Kap 3.3.5: (End-)Nutzer- und Umfeldrollen [ÜBERARBEITET]

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

2.1.3.4.1 in Kap 3.3.5.1: Anwender

<< alt>>

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

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

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

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

<< neu >>

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

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

In der TI‑2.0‑Zielarchitektur werden Anwender und DVO primär über den zentralen TI‑Help‑Desk (UHD) unterstützt, nicht mehr über UHDs der Anbieter VPN‑Zugangsdienst bzw. TI‑Gateway.

2.1.3.4.2 in Kap 3.3.5.2: Versicherte, Vertreter der Versicherten

<< alt>>

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

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

<< neu >>

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

2.1.3.4.3 Kap 3.3.5.3: Kostenträger und Institutionen in Nutzerrolle [NEU]

<< neu >>

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)

2.1.3.4.4 in Kap 3.3.5.4: Dienstleister vor Ort (DVO)

<< alt>>

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

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

<< neu >>

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

2.1.3.4.5 in Kap 3.3.5.5: Drittanbieter

<< alt>>

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

<< neu >>

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.

2.1.3.5 in Kap 3.3.6: TI‑Teilnehmer und TI‑ITSM‑Teilnehmer [ÜBERARBEITET]

<< alt>>

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

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

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

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

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

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

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

Explizit von der TI-ITSM-Teilnahme ausgeschlossen sind:

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

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

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

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

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

Tabelle 1: Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer

Rolle
(Anbieter/Hersteller/Verantwortliche)
Teilnahme am TI-ITSM Mitwirkungspflicht am TI-ITSM
Anbieter ohne UA (Konstellation I) ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer

Anbieter mit UA (Konstellation II) ja nur A/E (Auslöser/Empfänger) bzgl. Knowledge Management
Anbieter mit UA (Konstellation III) ja nur A/E (Auslöser/Empfänger) bzgl. Knowledge Management
Anbieter mit UA (Konstellation IV) ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer
UA (Konstellation II) ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer, da UA (Konstellation II) auch gleichzeitig Anbieter ohne UA (Konstellation I) ist
UA (Konstellation III) ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer, da UA (Konstellation II) auch gleichzeitig Anbieter ohne UA (Konstellation I) ist
UA (Konstellation IV) ja nur A/E (Auslöser/Empfänger) bzgl. Knowledge Management
Hersteller dezentraler Komponenten ja auf freiwilliger Basis gemäß Nutzungsvereinbarung;
produkttypspezifisch verpflichtend gemäß [gemRL_Betr_TI#GS-A_3984]
Hersteller Primärsysteme ja auf freiwilliger Basis gemäß Nutzungsvereinbarung
Service Provider TI unterstützender Produkte ja auf freiwilliger Basis gemäß Nutzungsvereinbarung
gematik Test ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer
gematik Betrieb ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer
Gesamtverantwortlicher TI (GTI) ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer
Dienstleister vor Ort (DVO) nein n/a
Anwender nein n/a
Versicherte nein n/a
Drittanbieter nein n/a
Hersteller Versicherten Frontend ja gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer

<< neu >>

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.

2.1.3.5.1 in Kap 3.3.6.1: TI‑ITSM‑Teilnehmer

<< neu >>

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,
  • gematik TI‑Help‑Desk (UHD‑Funktion mit lokalem ITSM, kein eigener TI‑ITSM‑Teilnehmer).

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.


2.1.3.5.2 neu Kap 3.3.6.2: TI‑Teilnehmer

<< neu >>

TI‑Teilnehmer (TI‑TLN) sind Rollen, die an der Erbringung und dem Betrieb von TI‑Services Ende‑zu‑Ende aktiv mitwirken oder TI‑Komponenten nutzen.

TI‑ITSM‑Teilnehmer sind stets auch TI‑Teilnehmer.

Zu den TI‑Teilnehmern gehören neben den TI-ITSM-Teilnehmern auch:

  • alle Anbieter weiterer Anwendungen oder Dienste (auch die, die nicht TI-ITSM-Teilnehmer sind)
  • der gematik TI‑Help‑Desk als zentraler UHD‑Provider im Rahmen der TI 2.0.

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

2.1.3.6 in Kap 3.3.7: 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), das Betreibermodell (Kap. 3.4) und das Servicemodell (Kap. 3.5).

2.1.3.6.1 in Kap 3.3.7.1: Produktverantwortung (PV)

<< neu >>

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

2.1.3.6.2 in Kap 3.3.7.2: Serviceverantwortung (SV)

<< alt >>

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

<< neu >>

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

2.1.3.6.3 neu Kap 3.3.7.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 verankert.

<< Perspektivisch wird der Titel folgender Anforderung angepasst >>

Betriebsverantwortung der TI-ITSM-Teilnehmer - Zulassungskonformität - ohne Suffix / redaktionell

TIP1-A_7263 - Produktverantwortung der TI-ITSM-Teilnehmer

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

2.1.4 Kap 3.4: Betreibermodell [NEU]

<< neu >>

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 definierten Providerrollen welche Service‑ und Betriebsaufgaben übernehmen,
  • wie die Verantwortungsarten Produkt‑, Service‑ und Betriebsverantwortung auf diese Rollen verteilt sind und
  • über welche Vertragsarten diese Rollen an die TI und den Gesamtverantwortlichen TI angebunden sind.

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.6.
Das Betreibermodell konkretisiert diese Zuordnung für einzelne Akteure und ergänzt sie um Verfahrens- und Vertragsarten sowie Umgebungen und Betriebsphasen.


2.1.4.1 neu Kap 3.4.1: Betriebsphasen und -umgebungen

<< verlagert aus Kapitel 3.3.1 >>

Die in diesem Betreibermodell beschriebenen Rollen, Verantwortungen und Mitwirkungen gelten grundsätzlich für alle Betriebsumgebungen und Betriebsphasen der TI, sofern in Produkttypsteckbriefen oder Steckbriefen 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.

2.1.4.2 neu Kap 3.4.2: Verfahrens- und Vertragsarten

<< neu >>

Die vertragliche Bindung von Providerrollen an die TI erfolgt über verschiedene Verfahrens‑ bzw. Vertragsarten. Sie bilden – zusammen mit den Rollen aus Kap. 3.3 – 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.

Delegationsszenarien (Einsatz von Vertretern) werden rollenbezogen in Kap. 3.3 beschrieben. Die Tabelle  zur Konkretisierung des Betreibermodells veranschaulicht, ob und wenn ja welche Art von Vertretung ein zugelassener Anbieter nutzen darf. [TIP1‑A_6415‑02] stellt klar, dass die Delegation von Aufgaben nichts an der Rolle des zugelassenen Anbieters als Adressat der Anforderungen der gematik ändert.

2.1.4.3 in Kap 3.4.4: Providerspezifische Betreibermodelle – Überblick [ÜBERARBEITET]

<< alt>>

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

Tabelle 2: Tab_KPT_Betr_Betriebliche Rolle_Anbieterkonstellationen

Spezifische Ausprägung der Rolle Zulässige Anbieterkonstellationen Bemerkung
Anbieter ZPD I
<...>

<< neu >>

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

Table # : Tab_gemKPT_Betr_Betreibermodell_providerspezifisch

Verfahrensart Vertreter mögl. Teilnahme am TI-ITSM
(verpflichtend / freiwillig, n/a)
Akteur
Beauftragung  n/a verpflichtend Anbieter Anschlusspunkt am SGW
Anbieter CVC-Root-CA
Anbieter E-Rezept-Fachdienst
Anbieter Federation Master
Anbieter Identity Provider - Dienst
Anbieter Proof-of-Patient-Presence-Service
Anbieter X.509 Root-CA
Anbieter ZPD
Anbieterzulassung

ja verpflichtend  Anbieter CVC TSPs für eGK
Anbieter X.509 TSPs für eGK
Anbieter HBA
Anbieter SMC-B / HSM-B
Anbieter CVC TSPs für eGK
Anbieter X.509 TSPs für eGK
Anbieter HBA
Anbieter SMC-B / HSM-B
Anbieter VPN-Zugangsdienst
Anbieter Fachdienst KOM-LE
Anbieter Basis-Consumer
Anbieter KTR-Consumer
Anbieter TI Messenger
Anbieter Aktensystem ePA
Anbieter Fachdienst National Contact Point for eHealth
Anbieter TI-Gateway
Anbieter Fachdienst VSDM 2.0
Anbieter TI-Messenger ePA Fachdienst
nein
verpflichtend  Anbieter KTR-AdV
Anbieter Signaturdienst
Anbieter Highspeed Konnektor
Anbieter Sektoraler Identity Provider Kostenträger
Anbieter eHealth-CardLink
Bestätigung ja verpflichtend  Fachdienst VSDM
(Bem: relevant für VSDM 1)
Produktzulassung
n/a
freiwillig Hersteller eHealth Kartenterminal
Hersteller TI-M Pro Client
Hersteller ePA-Aktensystem
Hersteller Highspeed Konnektor
Hersteller Konnektor

Hersteller TI-Gateway-Zugangsmodul
Hersteller Intermediär VSDM
Hersteller VSDM 2 Fachdienst
Hersteller TI-Messenger ePA Fachdienst
Hersteller TI-Messenger Pro Fachdienst
Herstellerzulassung n/a verpflichtend  Hersteller Frontend des Versicherten
(Bem: aktuell nur ePA FdV)
KOB n/a n/a Hersteller Primärsysteme
Bestätigung n/a verpflichtend  WANDA Basic
WANDA Smart
WANDA Smart Hosting
n/a DiGA
gematik-seitig
n/a
verpflichtend  Anbieter E-Rezept-Frontend des Versicherten
Anbieter E-Rezept-Anwendung des Versicherten
n/a gematik TI-Help-Desk

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.

2.1.4.4 in Kap 3.4.6: Providerspezifische Ergänzungen (Delivery)

<< neu >>
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 und über Inhalte der  Tabelle "Tab_gemKPT_Betr_Betreibermodell_providerspezifisch" hinausgehen.

Weitere Aspekte werden in folgenden Kapiteln behandelt:

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

2.1.4.4.1 in Kap 3.4.6.x: Anbieter VPN‑Zugangsdienst [ÜBERARBEITET]

<< alt>>

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

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

<< Afo wird verschoben in providerspez. Kapitel von 3.6 Supportkonzept >>

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

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.

<< Afo wird behalten >>

  • A_18430 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter VPN-Zugangsdienst

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

<< neu >>

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

Bereitstellung von Firewall‑Konfigurationsdaten:

A_18430 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter VPN-Zugangsdienst

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

Die Veröffentlichung 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.

2.1.4.4.2 Kap 3.4.6.x: Anbieter ePA-Aktensystem [ÜBERARBEITET]

<< geändert >>

Für den Anbieter ePA-Aktensystem gelten die in Tab._"gemKPT_Betr_Betreibermodell_providerspezifisch" aufgeführten Vorgaben Kapitel 3.4.1.2.1 aufgeführten betrieblichen Konstellationen. 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. Dieser erfüllt dann die in Kapitel 3.4.1.2.1 aufgeführten Berechtigungen und Verpflichtungen für den Anbieter. 

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. Sofern sie sich dazu entscheiden, gelten für sie hinsichtlich der möglichen betrieblichen Konstellationen die gleichen Regelungen.

2.1.4.4.3 Kap 3.4.6.x: Weitere Anwendungen und Dienste (WANDA)

<< unverändert >>

2.1.4.4.4 Kap 3.4.6.x: Weitere Anwendungen und Dienste (DiGA) [NEU]

<< neu >>

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

Weitere betriebliche Anforderungen in Kap. 6.1 sind:

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

2.1.4.4.5 Kap 3.4.6.x: Anbieter Anschlusspunkt am SGW

<< unverändert >>

2.1.4.4.6 in Kap 3.4.6.x: Anbieter TI-Messenger Pro, Anbieter TI-Messenger ePA Fachdienst

<< alt>>

Für den Anbieter TI-Messenger Pro bzw. Anbieter TI-Messenger ePA Fachdienst sind die in Kapitel 3.4.4 aufgeführten betrieblichen Konstellationen möglich.
Die Betriebsverantwortung für die Produkte TI-Messenger Pro und TI-Messenger Pro Client liegt beim jeweiligen Anbieter.

Der Anbieter TI-Messenger Pro verantwortet den Betrieb des Fachdienstes und des Clients, der die Nutzergruppe Leistungserbringer unterstützt, und der Anbieter TI-Messenger ePA Fachdienst analog den Fachdienst für die Nutzergruppe Versicherter.

<< neu >>

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.

2.1.4.4.7 in Kap 3.4.6.x: Anbieter Federation Master

<< unverändert >>

2.1.4.4.8 in Kap 3.4.6.x: Anbieter Sektoraler Identity Provider Kostenträger (sek IDP KTR)

<< alt>>

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

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

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

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

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

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

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

<< hinzugefügt >>

Betriebliche Konstellation und Verantwortlichkeit

<< übernommen aus Kap. 3.6.3.5 >>

A_23201 - Betriebliche Konstellation des sektoralen IDP

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

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

Unterauftragnehmer / Dienstleister

<< übernommen aus Kap. 3.6.3.5 >>

A_23411 - Nennung der Unterauftragnehmer des Anbieters

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

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 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)


2.1.4.4.9 in Kap 3.4.6.x: Anbieter TI-Gateway

<< alt>>

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

  • A_23334 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter TI-Gateway

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

<< neu >>

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:

<< Afo übernommen aus Kap. 4.2.2, da spezifisch >>

A_27428 - Referenzumgebung - Verpflichtung zur Bereitstellung des Dienstes

Der Anbieter MUSS dauerhaft in der Referenzumgebung (RU) den zur Produktivumgebung (PU) identisch konfigurierten Dienst bereitstellen.

Hinweis: Das bedeutet, dass des Management und die Verfügbarkeit des angebotenen Dienstes auch im Rahmen des TI-ITSM zu gewährleisten ist. [<=]

Bereitstellung von Firewall‑Konfigurationsdaten:

A_23334 - Bereitstellung Firewall-Konfigurationsdaten vom Anbieter TI-Gateway

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

Die Veröffentlichung 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 beschrieben.

2.1.4.4.10 in Kap 3.4.6.x: Hersteller Versicherten Frontend ePA FdV

<< alt >>

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

<< neu >>

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. 

2.1.4.4.11 in Kap 3.4.6.x: Hersteller Primärsysteme

<< alt >>

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

<< neu >>

Hersteller von Primärsystemen (z. B. PVS, ZPVS, APVS, KIS) sind als Herstellerrolle in Kap. 3.3.3 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.

2.1.4.4.12 neu Kap 3.4.6.x: gematik TI-Help-Desk (gematik-seitiger Provider)

<< neu >>
Der TI‑Help‑Desk ist ein gematik‑interner Provider mit UHD‑Funktion (1st‑Level‑Support) für Anwender, DVO und 
Hersteller von Primärsystemen im Kontext der TI 2.0. 

Er erbringt Supportleistungen auf Basis interner Vereinbarungen mit dem Gesamtverantwortlichen TI und ist kein Adressat einer Anbieterzulassung. 

Er trägt die Service- und Betriebsverantwortung (SV/BV) für den UHD‑Service und erfüllt die Anforderungen an Servicezeit und Erreichbarkeit gemäß [A_19532*] und [TIP1‑A_6389*]. 

Die Einbindung in Supportketten, die Weiterleitungsverantwortung [TIP1‑A_6393*] sowie die Zuordnung zu HD‑Profilen 

werden im Supportkonzept (Kap. 3.6) und in den zugehörigen Tabellen beschrieben.


--------------------------------------------------------------

2.1.4.4.13 entferne Kap 3.4.6.x: Anbieter eHealth-CardLink

<< alt >>

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

<< neu >>

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.4.4.14 entferne Kap 3.4.6.x: Anbieter Basis-Consumer

<< alt>>

Für diese Anbieter dienen die in Kapitel  aufgeführten betrieblichen Konstellationen abschließend.
Abweichend der Darstellung im Kapitel stellen die Anbieter Basis-Consumer keinen Anwender- bzw. Versichertensupport zur Verfügung.

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.4.4.15 entferne Kap 3.4.6.x: Anbieter KTR-Consumer

<< alt>>

Für diese Anbieter dienen die in Kapitel aufgeführten betrieblichen Konstellationen abschließend.
Abweichend der Darstellung im Kapitel stellen die Anbieter KTR-Consumer keinen Anwender- bzw. Versichertensupport zur Verfügung.

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.4.4.16 entferne Kap 3.4.6.x: Anbieter KTR-AdV

<< alt>>

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

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.4.4.17 entferne Kap 3.4.6.x: Anbieter KIM

<< alt>>

Für die Anbieter Fachdienst KIM sind die in Kapitel aufgeführten betrieblichen Konstellationen möglich. Im Rahmen des Betriebs ist mit der Anwendung sicherzustellen, dass ein eigener User Help Desk (UHD) zur Verfügung gestellt wird.

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.4.4.18 entferne Kap 3.4.6.x: Fachdienste VSDM

<< alt>>

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

<< Kapitel wird entfernt, da hier keine ergänzenden Informationen geliefert werden >>

2.1.5 Kapitel 3.5: Servicemodell

<< unverändert >>

2.1.5.1 Kapitel 3.5.1 Servicekomponenten

<< unverändert >>

2.1.5.2 Kapitel 3.5.2 Servicezerlegung

<< unverändert >>

2.1.5.3 in Kapitel 3.5.3: Mitwirkungen im TI-ITSM [ÜBERARBEITET]

<< vorheriger Kapitelname "Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]" >>

<< alt >>

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

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

<< neu >>

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.

Table # : gemKPT_Betr_Tab_TI-ITSM-Prozess-Profile

TI-ITSM-Mitwirkung / Profil INC PRO CHG CM NM RF SLM SKM Perf  - Av Perf -CapM CSI KM BU
PP-A-1 x x x x x x x x x x x x TU, RU, PU
PP-H-1 . . . . . A . . . . . x TU, RU
PP-H-2 . . x . . A . . . . . x TU, RU, PU
PP-H-3 x x . . . A x . . . . x PU

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

Table # : TI-ITSM-Prozessprofile – Zuordnung zu Rollen/Akteuren

TI-ITSM-Profil ist relevant für Akteur
PP-A-1 Anbieter Sektoraler Identity Provider Kostenträger
Anbieter Federation Master
Anbieter ZPD
PP-H-1 Hersteller eHealth Kartenterminal
Hersteller TI-M Pro Client
Hersteller TI-Messenger ePA Fachdienst
Hersteller TI-Messenger Pro Fachdienst
PP-H-2 Hersteller ePA-Aktensystem
Hersteller Highspeed Konnektor
Hersteller Konnektor
Hersteller TI-Gateway-Zugangsmodul
Hersteller Intermediär VSDM
Hersteller VSDM 2 Fachdienst
PP-H-3 Hersteller Frontend des Versicherten

Hinweise:

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

Tabelle 3: Tab_gemKPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM 

Mitwirkung in den TI-ITSM-Prozessen: INC PRO CHG SKM SLM RF Perf CapM KM CSI CM NM
gematik Test A A A . . A/E . . A/E . A/E A/E
gematik Betrieb A A A . . A/E . . A/E . A/E A/E
Gesamtverantwortlicher TI (GTI) A A/E X . . A/E E E A/E . A/E A/E
Anbieter Anschlusspunkt SGW / SZZP A/E A/E X . A/E A A . . . A/E
Anbieter Basis-Consumer A/E A/E X . A/E A . . A/E . A/E A/E
Anbieter CVC-Root-CA  A/E A/E X A/E A/E E . . A/E . A/E A/E
Anbieter eHealth-CardLink A/E A/E X . A/E A A/E A/E A/E . A/E A/E
Anbieter ePA-Aktensystem A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter Digitale Patientenrechnung Fachdienst A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter E-Rezept-Fachdienst A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter E-Rezept FdV A/E A/E X . A/E A . . A/E . A/E A/E
Anbieter E-Rezept AdV A/E A/E X . A/E A . . A/E . A/E A/E
Anbieter Fachdienst KIM A/E A/E X . A/E A A . A/E . A/E A/E
Anbieter Federation Master A/E A/E X A/E A/E A/E A/E A/E A/E A/E A/E A/E
Anbieter HBA A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter Highspeed Konnektor A A X . . A . . A/E . . A
Anbieter Identity Provider - Dienst A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter KTR-AdV A A X . . A . . A/E . A/E E
Anbieter KTR-Consumer A/E A/E X . A/E A . . A/E . A/E A/E
Anbieter Sektoraler Identity Provider Kostenträger A/E A/E X A/E A/E A/E A/E A/E A/E A/E A/E A/E
Anbieter Signaturdienst A/E A/E X . A/E A A A . . A/E A/E
Anbieter SMC-B / HSM-B A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter TI-Messenger Pro A/E A/E X A/E A/E A/E A A A/E . A/E A/E
Anbieter TI-Messenger ePA Fachdienst A/E A/E X A/E A/E A/E A A/E . A/E A/E
Anbieter TSP CVC eGK . . X . A/E A . . A/E . A/E A/E
Anbieter TI-Gateway A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter VPN-Zugangsdienst A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter X.509 Root-CA A/E A/E X . A/E A/E . . A/E . A/E A/E
Anbieter X.509 TSP eGK A/E A/E X . A/E A A A A/E . A/E A/E
Anbieter ZPD A/E A/E X P A/E E A A A/E A A/E A/E
Fachdienst VSDM A/E A/E X . A/E A A . A/E . A/E A/E
Anbieter VSDM 2 Fachdienst A/E A/E X A/E A/E A/E A A A/E A/E A/E A
Service Provider Anbieter NCPeH-Fachdienst A/E A/E X . A/E A A A A/E . A/E A/E
Hersteller Primärsysteme A/E A/E X . . . . . E . A/E A/E
Hersteller Versicherten Frontend A/E A/E . . A/E A . . A/E . . .
WANDA Basic A/E . X . . A . A E . A/E .
WANDA Smart A/E A/E . . . A . A A/E . . E
WANDA Smart-Hosting A/E A/E . . . A . A A/E . . E

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

Legende:

Table # : Tab_gemKPT_Betr_TI-ITSM-Mitwirkungspflichten_Legende

TI-ITSM-Prozess Abkürzung Auslöser (A) = Empfänger (E) = nimmt teil (X) =
Incident Management INC erstellt Incidents kann Incidents zugewiesen werden und bearbeitet diese nimmt am Problem Management in allen Aktivitäten teil
Problem Management PRO erstellt Problems kann Problems zugewiesen werden und bearbeitet diese nimmt am Problem Management in allen Aktivitäten teil
Change Management CHG - - nimmt am Change Management in allen Aktivitäten teil
Configuration Management CM sendet Reports, in denen die Konfigurationen der verwendeten Produkte dargestellt werden empfängt und setzt Konfigurationsvorgaben um  z.B. im Zuge eines CRs oder Changes
nimmt am Configuration Management in allen Aktivitäten teil
Notfall Management NM muss im Notfall zuarbeiten und unterstützen
einen Notfall-Ansprechpartner bereit nimmt am Notfall Management in allen Aktivitäten teil
Request Fulfillment RF ruft Services bei anderen Providern ab stellt Services auf Basis des Business-Servicekatalogs zum Abruf bereit nimmt am Request Fulfillment in allen Aktivitäten teil
Service Level Management SLM bringt Änderungen im Service Level Management ein
nimmt an Service-Reviews teil nimmt am Service Level Management in allen Aktivitäten teil
Service Katalog Management SKM bringt Änderungsvorschläge an dem Business-Servicekatalog anderer Akteure ein
führt einen Business-Servicekatalog und 
setzt Änderungen an seinem zu verantwortenden Servicekatalog um
nimmt am Service Katalog Management teil - erstellt und pflegt Einträge im Business-Servicekatalog
Performance Management (Availability) Perf -Av übermittelt Performancedaten Gesamtverantwortlicher TI nimmt am Performance Management speziell Availibility in allen Aktivitäten teil
Performance Management (Capacity) Perf -CapM führt Kapazitätspläne und berichtet diese an den Empfänger Gesamtverantwortlicher TI nimmt am Performance Management speziell Capacity Management in allen Aktivitäten teil 
Continual Serivce Improvement CSI führt ein CSI-Register und berichtet dieses an den Empfänger Gesamtverantwortlicher TI nimmt am Continual Service Improvement in allen Aktivitäten teil
Knowledge Management KM kann Artikel in die Wissensdatenbank einstellen kann Artikel aus der Wissensdatenbank beziehen nimmt am Knowledge Management in allen Aktivitäten teil

2.1.6 Kap 3.6: Supportkonzept

<< In diesem Kontext unverändert >>

3 Änderung in gemRL_Betr_TI

3.1 in Kapitel 2.1.2.1: Notwendige Kontakte und Ansprechpartner

A_26502 - Kommunikation - Benennung von Ansprechpartnern und Kontakten (LITE)

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

  • die Rolle Partner Manager,
  • die Rolle Service Delivery Manager,
  • den Ansprechpartner Unternehmenskommunikation / Krisenkommunikation,
  • den Ansprechpartner Informationssicherheit,
  • den Ansprechpartner Datenschutz,
  • den Ansprechpartner für vertragliche und kaufmännische Fragestellungen.
Alle oben benannten Ansprechpartner sind Personenkontakte und MÜSSEN mit der entsprechenden Fach- und Entscheidungskompetenz ausgestattet sein.

[<=]

<< wird ersetzt durch >>

A_26502-01 - Kommunikation - Benennung von Ansprechpartnern und Kontakten (LITE)

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

  • die Rolle Partner Manager,
  • die Rolle Service Delivery Manager,
  • den Ansprechpartner Unternehmenskommunikation / Krisenkommunikation,
  • den Ansprechpartner Informationssicherheit,
  • den Ansprechpartner Datenschutz,
  • den Ansprechpartner für vertragliche und kaufmännische Fragestellungen.
Alle oben benannten Ansprechpartner sind Personenkontakte und MÜSSEN mit der entsprechenden Fach- und Entscheidungskompetenz ausgestattet sein.

[<=]

--> Zuordnungen bleiben unverändert