C_12085_Anlage - Supportkonzept

Inhaltsverzeichnis

1 Änderungsbeschreibung

in gemKPT_Betr Kap. 3.6:

• Neustrukturierung von Kap. 3.6 „Supportkonzept“ (Zielsetzung, Rollen/Funktionen, Meldungsarten,  Verantwortungsarten, Kommunikationswege und Erreichbarkeit, Servicezeiten der Help Desks,  Supportketten, providerspezifischer Support).
• Präzisierung der Supportrollen (1st-/2nd-/3rd-Level-Support, UHD, VHD, SPOC) und der Verantwortungsarten im Supportkontext (Support- und Lösungsverantwortung)
• Definition von Meldungsarten im Nutzersupport (Störungen/Incidents, Service Requests/Anfragen, Rückmeldungen/Beschwerden, sicherheitsrelevante Meldungen)
• Entfernen der redundanten Afo:
•  TIP1-A:6420-03 - Erreichbarkeit der 1st-Level_UHDs
• Verlagerung folgender Afos aus Kapitel 4 in das Supportkonzept (Kap. 3.6)
•  TIP1-A_6389-02 - Erreichbarkeit der 1st-Level (UHD), 2nd-Level (SPOCs) der Anbieter“ und
•  TIP1-A_6393-02 - Verantwortung für die Weiterleitung von Anfragen
• mit Zuordnung von TIP1‑A_6389‑02 zum Kapitel bzgl. Kommunikationswege/Erreichbarkeit und Zuordnung von TIP1‑A_6393‑02 zum Kapitel Weiterleitungspflicht in den Supportketten
• neue Struktur von Kap. 3.6 „Supportkonzept“ :
• Zielsetzung
• Rollen und Schnittstellen im Support (Rollen/Funktionen, Meldungsarten, Verantwortungsarten)
• Erreichbarkeit und Kommunikationswege
• Servicezeit im Anwender- und Versichertensupport
• Weiterleitung und Supportketten
• Providerspezifischer Support

• Integration des TI-Help-Desk mit UHD-Funktion und 24/7-Servicezeit und spezifischer Erreichbarkeit
• Konsolidierung providerspezifischer UHD/VHD-Regelungen (VPN-Zugangsdienst, TI-Gateway, DiGA, sektoraler IDP KTR).
• Redaktionell: Im Titel der in Kap 3.6 aufgelisteten Afos wird "Support - " vorangestellt, um die thematische Zuordnung einer Afo in den Steckbriefen kenntlich zu machen.

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

<< nach Kapitel 3.5 Servicemodell >>

2.1 in Kapitel: 3.6 Supportkonzept [ÜBERARBEITET]

2.1.1 neu Kapitel 3.6.1: Zielsetzung [NEU]

<< alt >>

Aufbauend auf der Servicearchitektur wird nachfolgend das Supportkonzept beschrieben.

<< neu >>

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

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

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

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

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

2.1.2 neu Kapitel 3.6.2: Rollen und Schnittstellen im Support [ÜBERARBEITET]

2.1.2.1 Kapitel 3.6.2.1: Rollen / Funktionen im Support

<< alt >>

User Help Desk (UHD)

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

Versicherten Help Desk (VHD)

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

1st Level Support

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

2nd / 3rd Level Support

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

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

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

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

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

<< neu >>

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

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

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

2nd-Level-Support:

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

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

3rd-Level-Support:

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

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

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

Jeder Anbieter benennt übergreifend für die von ihm zu verantwortenden Servicekomponenten einen Single‑Point‑of‑Contact (SPOC) gegenüber allen anderen TI‑ITSM‑Teilnehmern. Über den SPOC erfolgt der erforderliche wechselseitige Support der Anbieter in der TI über das TI‑ITSM‑System.
Die normative Definition und Mitwirkungspflichten des SPOC in den TI‑ITSM‑Prozessen werden in Kap. 3.5.3 „TI‑ITSM‑Rahmen und Mitwirkung“ festgelegt ([TIP1‑A_6371‑02]). Dieses Kapitel betrachtet den SPOC ausschließlich in seiner Rolle als 2nd‑Level‑Supportinstanz im Nutzersupport (Incident Management, Request Fulfillment).

Figure # : gemKPT_Betr_Supportstufen_und_Supportrollen_in_der_TI

Legende:

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

Weitere Nutzerrollen gemäß Kap. "Rollen im Betrieb" haben keinen Zugriff auf den UHD/VHD.

2.1.2.2 Kapitel 3.6.2.2: Meldungsarten im Nutzersupport

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

Meldungen werden unterschieden in:

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

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

2.1.2.3 Kapitel 3.6.2.3: Verantwortungsarten im Support

<< alt >>

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

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

<< neu >>

Es werden folgende Verantwortungsarten unterschieden:

Supportverantwortung bezeichnet die Verantwortung für:

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

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

Lösungsverantwortung bezeichnet:

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

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

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

2.1.3 Kapitel 3.6.3: Kommunikationswege und Erreichbarkeit im Support (SPOC, UHD/VHD) [ÜBERARBEITET]

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

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

Die konkreten Mindestservicezeiten der Help Desks sind in Kap. 3.6.4 beschrieben.

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

<< wird von Kapitel 4.2.1 hierhin verschoben >>

<< neue Afo für TI-Help-Desk >>

--> Zuordnung zu TI-Help-Desk mit Prüfverfahren organ./betriebl. Anbietererklärung

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

2.1.4 Kapitel 3.6.4: Mindestservicezeit im Nutzersupport [ÜBERARBEITET]

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

2.1.4.1 Kapitel 3.6.4.1: Begriffe und Abgrenzung [NEU]

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

Mindestservicezeit (HD) unterscheidet sich von:

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

2.1.4.2 Kapitel 3.6.4.2: Mindestservicezeit des UHD [ÜBERARBEITET]

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

--> Zuordnung zu TI-Help-Desk mit Prüfverfahren organ./betriebl. Anbietererklärung

<< Folgende Afo wird entfernt, da sie inhaltlich vollständig durch A_19532-01 abgedeckt ist >>

2.1.4.3 Kapitel 3.6.4.3: Mindestservicezeit des VHD [ÜBERARBEITET]

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

2.1.5 Kapitel 3.6.5: Supportketten und Weiterleitung [NEU]

In diesem Kapitel wird beschrieben, welche Akteure eine Weiterleitungspflicht haben (i.d.R. alle Provider), was diese Pflicht an Aufgaben bzw. Verantwortungen umfasst und wie typische Supportabläufe bzw. Supportketten unterschieden nach TI 1.0 bzw. TI 2.0 gestaltet sind. Die Abb. gemKPT_Betr Supportkonzept für Servicemodule (Szenario 1+2) zeigt die beschriebenen Szenarien als Schema.

2.1.5.1 Kapitel 3.6.5.1: Weiterleitung von Meldungen [NEU]

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

<< Verlagerung aus Kapitel 4.2.1 >>

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

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

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

2.1.5.2 Kapitel 3.6.5.2: Typische Supportketten bzw. -szenarien [NEU]

Es existieren für die TI 1.0 und TI 2.0 unterschiedliche Supportabläufe. Da die Akteure Anbieter VPN‑Zugangsdienst bzw. Anbieter TI-Gateway im Rahmen der TI 2.0 entfallen, übernimmt der TI-Help-Desk die Funktion des UHDs. Daher werden folgende zwei Szenarien unterschieden.

Aktuell werden folgende Dienste der TI 2.0 zugeordnet:

• VSDM 2.0
• DiPag
• TI-Messenger ePA Fachdienst

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

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

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

• Anwender bzw. DVO melden Störungen/Anfragen primär beim TI‑Help‑Desk als zentralem UHD
• Hersteller von Primärsystemen können den TI‑Help‑Desk als zentrale 1st‑Level‑Anlaufstelle für TI‑bezogene Fragestellungen und Störungen nutzen
• Versicherte bzw. ihre Vertreter melden Störungen/Anfragen weiterhin beim zuständigen VHD
• TI‑Help‑Desk bzw. VHD übernehmen Annahme, Qualifizierung und Zuständigkeitsprüfung der Meldungen.

In beiden Fällen gilt (TI 1.0 und TI 2.0):

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

Figure # : gemKPT_Betr Supportkonzept für Servicemodule (Szenario 1+2)

2.1.6 Kapitel 3.6.6: Providerspezifischer Support [NEU]

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

2.1.6.1 Kapitel 3.6.6.1: Übersicht über Umsetzung der Help Desks durch Provider [NEU]

<< überarbeitet >>

Die Zuordnung von UHD/VHD-Profilen zu Providern erfolgt auf Basis der in Kap. 3.6.4 definierten Servicezeiten.

Tabelle 2: Tab_gemKPT_Betr_TI_TI-ITSM-Teilnehmer-UHD/VHD

* [außer an bundeseinheitlichen Feiertagen]

2.1.6.2 Kapitel 3.6.6.2: Anbieter Sektoraler Identity Provider für Kostenträger [ÜBERARBEITET]

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

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

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

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

<< Folgende Afos werden in das Betreibermodell Kap 3.4.6.x verschoben, da sie thematisch nicht zum Supportkonzept gehören  >>

• A_23201 - Betriebliche Konstellation des sektoralen IDP
• A_23411 - Nennung der Unterauftragnehmer des Anbieters

2.1.6.3 Kapitel 3.6.6.3: Anbieter VPN‑Zugangsdienst / Anbieter TI-Gateway [ÜBERARBEITET]

<< Kapitel Anbieter VPN-Zugangsdienst und Anbieter TI-Gateway zusammenlegen, da sie im Rahmen des Supports die gleiche Aufgabe zu erfüllen haben. >>

<< alt >>

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

<< alt + Ergänzung>>

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

• UHD mit Mindestservicezeit 24/7 gemäß [A_19532*],
• spezifizierte 24/7-Mindestservicezeit für den 1st-Level-UHD gemäß [TIP1-A_6420*] (siehe Kap. 3.6.4.2),
• Dokumentation von Service Levels im Anwendersupport einschließlich Serviceklassen,
• Bereitstellung von Firewall-Konfigurationsdaten zur Unterstützung bei der Konfiguration lokaler Firewalls in dezentralen Umgebungen.

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.

2.1.6.4 Kapitel 3.6.6.4: gematik TI-Help-Desk [NEU]

Der TI-Help-Desk ist ein zentral durch die gematik bereit gestellter Provider, der für Anwender, Dienstleister vor Ort (DVO) und Hersteller von Primärsystemen einen zentralen Helpdesk (UHD) bereitstellt. Er übernimmt die 1st‑Level‑Supportfunktion (inkl. Annahme, Erstqualifizierung der Meldungen und Rückmeldungen) als TI‑weit einheitliche Anlaufstelle vorrangig für Dienste der TI 2.0).

Der TI-Help-Desk:

• nimmt für Anwender, Dienstleister vor Ort (DVO) und Hersteller von Primärsystemen die Supportverantwortung wahr,
• stellt sicher, dass Meldungen qualifiziert und entlang der E/U/V-Rollen an die lösungsverantwortlichen Anbieter und Hersteller weitergeleitet werden,
• bleibt gegenüber den Meldergruppen primärer Ansprechpartner, unabhängig davon, welche Provider oder Hersteller im TI-ITSM an der Lösung mitwirken.

Der TI-Help-Desk MUSS die Anforderungen an Servicezeiten und Kommunikationswege für UHD erfüllen, insbesondere:

• die Servicezeit 24/7 gemäß [A_19532*],
• die Kommunikationswege gemäß [TIP1-A_6389*] (Erreichbarkeit der 1st-Level (UHD), 2nd-Level (SPOCs) der Provider).

2.1.6.5 Kapitel 3.6.3.4: Anbieter Federation Master [ENTFERNEN]

<< wird entfernt da Informationen bereits gegeben sind und somit redundant >>

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