Elektronische Gesundheitskarte und Telematikinfrastruktur

IT-Servicemanagement:

Leitfaden Change Management

    

     

      
Version
      
1.0.0 CC
     
     

      
Revision
      
1051006
     
     

      
Stand
      
21.11.2024
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemLF_ITSM_CHM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einleitung

1.1 Zielsetzung

Der Leitfaden Change Management beschreibt alle operativen Mitwirkungsanteile der TI-ITSM-Teilnehmer im Rahmen des TI-ITSM-Prozesses Change Management. Er dient als Ergänzung zu dem Dokument „Übergreifende Richtlinien zum Betrieb der TI“ [gemRL_Betr_TI] in seiner aktuellen Version.

Dieser Leitfaden soll dazu beitragen, dass der Prozess Change Management operativ auf sich schnell ändernde Situationen angepasst werden kann. Um diese Flexibilität zu gewährleisten, kann der Leitfaden bis zu einmal im Quartal angepasst werden.

1.2 Zielgruppe

Das Dokument richtet sich an die am Betrieb der TI beteiligten Akteure: Anbieter von Betriebsleistungen in ihrer Rolle als TI-ITSM-Teilnehmer und die gematik in ihrer koordinierenden Rolle (Gesamtverantwortlicher TI).

1.3 Abgrenzungen

Dieser Leitfaden gilt ergänzend zum Dokument „Übergreifende Richtlinien zum Betrieb der TI“ [gemRL_Betr_TI] in seiner aktuellen Version. In diesem Dokument werden daher keine normativen Anforderungen beschrieben. Alle referenzierten, normativen Anforderungen werden in den jeweiligen Richtlinien behandelt.

2 Change Workflow

2.1 Workflow Change Management

Abbildung 1 beschreibt den Workflow des gematik Change Management am Beispiel eines Normal Changes.

Abbildung 1 : Abb_gemLF_ITSM_CHM_Workflow Change Management

2.2 Change Erfassung

Für die Annahme eines Request for Change (RfC) werden die nachfolgend aufgezeigten Qualitätskriterien vorausgesetzt. Bei Nichteinhaltung kann dies zu einer Ablehnung des eingereichten Changes führen.

2.2.1 Änderungsgründe

Folgende Änderungsgründe stehen im Change-Formular zur Auswahl:

Tabelle 1: Tab_gemLF_ITSM_CHM_Änderungsgründe

2.2.2 Qualitätskriterien

Folgende Angaben müssen in jedem Change dokumentiert werden (siehe A_13575):

Tabelle 2: ab_gemLF_ITSM_CHM_Qualitätskriterien

2.2.3 Vorlaufszeiten

Alle TI-ITSM-Teilnehmer müssen folgende Change-Vorlaufszeiten bei der Erstellung und Umsetzungsplanung (im Sinne Vorlaufzeiten vor Implementierungsbeginn) eines RfCs berücksichtigen:

• Master-Change: mindestens 24 Stunden zur Hauptzeit (zwischen Validierungsanforderung und Umsetzungsbeginn des 1. Sub-Changes)

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

Werden diese Fristen nicht eingehalten, so kann der Gesamtverantwortliche TI die Bewertung des Changes ablehnen. Dies kann zu einer Stornierung oder Neuplanung des RfC bzw. des gesamten Change-Vorgangs führen (siehe GS-A_5610*).

2.2.4 Normal-Change

Ein Master-Change ohne verknüpfte Sub-Changes ist nicht zulässig.

Somit stellt ein genehmigter Master-Change keine Genehmigung für Änderungen in den dedizierten Betriebsumgebungen dar. Jeder Sub-Change muss separat genehmigt werden (siehe GS-A_5597-*).

2.2.5 Standard-Change vs. Pre-approved-Change

Abweichend von dem Dokument "Übergreifenden Richtlinie zum Betrieb der TI" [gemRL_Betr_TI] wird der Begriff "Standard-Change" bei der gematik als "Normal Change" bezeichnet und für eine definierte Änderung in einer konkreten Betriebsumgebung verwendet.

Der Pre-approved-Change wurde eingeführt, um standardisierte Changes (gem. ITIL Standard Change) durchzuführen. Dabei handelt es sich um eine wiederkehrende, risikoarme („Risikobewertung“ mit max. 1-geringes Risiko) und ausfallfreie Änderung. Inhaltsgleiche Änderungen sind in der Vergangenheit problemlos verlaufen. Wird ein Pre-approved-Change mehrmalig und ohne Ausfall umgesetzt, kann in Absprache mit dem Gesamtverantwortlichen TI eine Umsetzung in der Hauptzeit erfolgen.

Pre-approved-Changes können sowohl in einer dedizierten Betriebsumgebung, als auch im Staging-Verfahren gestellt werden.

Die Anlage eines Pre-approved-Change erfolgt vorlagenbasiert (1 Vorlage je UseCase). Die Vorlage ist vorab mit der gematik abzustimmen. Mit der Freigabe durch den Gesamtverantwortlichen TI kann der TI-Teilnehmer auf diese zugreifen und Pre-approved-Changes für den jeweiligen UseCase umsetzen. Die Genehmigung des Changes erfolgt dabei nach 24 Stunden zur Hauptzeit automatisch. Bis zur automatischen Genehmigung kann die gematik den Change ablehnen.

Die gematik behält sich vor, pre-approved-Changes bei vorliegenden Situationen wieder zu deaktivieren:

• Eintreten einer unerwarteten Störung
• Missachtung prozessualer Regeln
• Missbrauch der pre-approved-Changevorlage.

2.2.6 Emergency-Change

Ein Emergency-Change kann in folgenden beispielhaften Situationen erforderlich werden:

• Nichtverfügbarkeit eines zentralen Plattformdienstes oder Fachdienstes;
• Fehlgeschlagenes Deployment, welches nicht durch ein Rollback zurückgenommen werden kann;
• Entdeckte kritische Sicherheitslücke, die umgehend behoben werden muss, um (weiteren) Schaden von der TI abzuwenden.

Voraussetzung für die Durchführung eines Emergency Changes ist das Vorliegen eines entsprechend klassifizierten Incidents. Dieser muss im Emergency Change unter „Verbundene Datensätze“ verknüpft sein.

Innerhalb der Servicezeiten der gematik ist eine Genehmigung erforderlich. Bei Bedarf KANN ein TI Emergency Change Advisory Board (TI-eCAB) durch den Gesamtverantwortlichen TI einberufen werden.

Ein eChange darf außerhalb der Servicezeiten der gematik ohne Genehmigung umgesetzt werden. In diesem Fall MUSS der Gesamtverantwortliche TI vor der Durchführung des Changes informiert werden. Die Information ist an folgende Adressaten zu richten:

• Service Delivery Manager (sdm@gematik.de),
• Change Management (change_management@gematik.de),
• Incident Management (Incident_Management@gematik.de) und
• Rufbereitschaft (Rufbereitschaft-TI@gematik.de).

Die Dokumentation im TI-ITSM Tool kann im Nachgang erfolgen. 

2.3 Change-Bewertung (Validierung und fachliche Bewertung)

In diesen Phasen erfolgt die Bewertung des Changes seitens der gematik. Der Gesamtverantwortliche TI prüft den Change auf die Konsistenz und Korrektheit aller formalen, inhaltlichen, qualitativen und fachlichen Kriterien. Ziel der Bewertung ist es, einen stabilen und sicheren Betrieb für alle Dienste hinweg sicherzustellen, indem Risiken identifiziert und ausreichend genug berücksichtigt werden.

Bei nicht ausreichender Qualifizierung eines Changes kann der Gesamtverantwortliche TI einen RFC jederzeit mit entsprechender Begründung zurückweisen/ablehnen.

2.3.1 Wartungsfenster

Ein Wartungsfenster ist der definierte Zeitraum mit Start- und Endzeit, in dem eine geplante Änderung durchgeführt wird. Wartungsfenster werden im Rahmen des Change Managements vom TI-ITSM-Teilnehmer angekündigt und vor der Durchführung vom GTI (Gesamtverantwortlicher der Telematikinfrastruktur) genehmigt (siehe gemRL_Betr_TI). Das definierte Wartungsfenster, insbesondere für die Produktionsumgebung (PU) muss mit Augenmaß gewählt werden, unter Berücksichtigung eines ggf. erforderlichen Rollbacks.

Der Gesamtverantwortliche TI kann eine Umplanung eines Changes einfordern, selbst wenn die Zeiten in den aktuell definierten Nebenzeiten liegen, sofern dies als betriebsstabilisierende Maßnahme erforderlich ist.

2.3.2 TI Change Advisory Board (TI-CAB)

Im Rahmen der Change-Bewertung führt der Gesamtverantwortliche TI einmal wöchentlich ein TI Change Advisory Board (TI-CAB) durch.

Das TI Change Advisory Board dient der Sicherstellung eines stabilen und sicheren Betriebs der Telematik Infrastruktur. Es ist ein Gremium, das sich aus allen relevanten Vertretern der TI-ITSM-Teilnehmer und des Gesamtverantwortlichen TI zusammensetzt. Zu letzteren zählen insbesondere die verantwortlichen Provider Manager sowie Change Manager der gematik.

Dabei werden relevante und sich im Scope befindliche Änderungen besprochen. Kernaktivitäten des TI-CAB sind:

• Identifizierung von ggf. auftretenden Risiken,
• Vereinbarung und Umsetzung von Maßnahmen zur Reduzierung bzw. Eliminierung der spezifischen Risiken,
• Besprechen der Auswirkungen einer Änderung auf einen Leistungserbringer / Versicherten, insbesondere im Falle einer geplanten Downtime eines Dienstes,
• Abstimmung einer Stakeholderkommunikation.

Um eine ressourcenschonende Umsetzung des TI-CAB zu gewährleisten, wird unterteilt in ständige CAB-Mitglieder und temporäre CAB-Mitglieder. Die Teilnahme der ständigen Vertreter ist verpflichtend.

Temporäre Mitglieder sind:

• alle TI-Teilnehmer deren Änderungen gemäß Definition In-Scope sind und somit im TI-CAB vorgestellt werden müssen,
• alle TI-Teilnehmer die einen Handlungsbedarf sehen um diesen im TI-CAB vorzustellen,
• alle TI-Teilnehmer die ein Interesse an der Teilnahme haben (niemand wird ausgeladen).
  

Ständige Mitglieder sind:

• IBM Deutschland GmbH als Anbieter des Fachdienstes E-Rezept
• Arvato Systems als Anbieter der zentralen Plattformdienste
• RISE GmbH als Anbieter des zentralen Identity Provider Dienstes
• CompuGroup Medical Deutschland AG, T-Systems International GmbH, Arvato Systems Digital als Anbieter der zentralen VPN-Zugangsdienste
• CompuGroup Medical Deutschland AG, T-Systems International GmbH, akquinet health service GmbH, Arvato Systems Digital GmbH, IBM Deutschland GmbH, BITMARCK Service GmbH, RISE GmbH als Anbieter des Fachdienstes Kommunikation im Medizinwesen (KIM)
• BITMARCK Technik GmbH, IBM Deutschland GmbH als Anbieter des Fachdienstes elektronische Patientenakte (ePA)

Folgende Dienste und TI-Teilnehmer befinden sich im Scope:

Tabelle 3: Tab_gemLF_ITSM_CHM_Dienste_Teilnehmer

*ständige Vertreter des TI-CAB (fettgedruckt)

Betrachtet werden alle geplanten anzeigepflichtigen Änderungen (fachlicher Scope):

Tabelle 4: Tab_gemLF_ITSM_CHM_fachlicher_Scope

Folgende Rahmenbedingungen / Erwartungshaltung sind zu erfüllen:

• Alle potentiell betroffenen TI-Teilnehmer nehmen an dem TI-CAB teil und wurden informiert.
• Die Teilnahme ist verpflichtend.
• Scope der zu besprechenden Changes ist bekannt.
• TI-CAB-Meeting findet wöchentlich statt.
• Besprochen werden alle bei der gematik eingereichten Changes mindestens der darauf folgenden Woche.
• Besprochen werden darüber hinaus noch nicht eingereichte Changes (Status "Erfassung") mit einem geplanten. Umsetzungsdatum von maximal 10 Tagen in der Zukunft.
• Teilnehmer haben in dem TI-CAB die Gelegenheit begründete Bedenken bzgl. der Umsetzung eines Changes zu äußern.
• Jeder TI-CAB-Teilnehmer bereitet sich entsprechend vor.
• Alle Changes müssen 2 Tage vor dem TI-CAB in dem TI-ITSM der gematik (ZIS) erfasst sein.
• max. 1 zusätzlicher Kollege darf „mitgebracht“ werden.
• Jeder Change Bedarfsträger hat eine Redezeit von max. 5 Minuten um den Change vorzustellen.
• Teilnehmer haben max. 5 Minuten Zeit um Fragen zu stellen.
• Die Freigabe einer Änderung erfolgt nur, wenn diese zuvor im CAB besprochen wurde.
• Die formale Genehmigung erfolgt nach wie vor nachgelagert im ZIS.

2.3.3 TI Emergency Change Advisory Board (TI-eCAB)

Für die kontrollierte Durchführung eines Emergency-Change kann ein Entscheidungsgremium einberufen werden, das TI Emergency Change Advisory Board (TI-eCAB), das den beteiligten TI-ITSM-Teilnehmern bei der Bewertung des auftretenden Emergency-Change wirksam unterstützt.

2.3.4 Change-Freeze

Der Gesamtverantwortliche TI kann jederzeit einen Change-Freeze ausrufen. In dieser Zeit dürfen keine Änderungen in der/den betroffenen Betriebsumgebung/en durchgeführt werden.

Umfang und Dauer eines Change-Freezes wird rechtzeitig und umfassend kommuniziert.

Aktuell gelten folgende wiederkehrende Change-Freezes für Änderungen in der PU:

• jeder Sonntag von 18:00 Uhr bis Montag 6:00 Uhr
• jeden Samstag von 8:00 Uhr bis 20:00 Uhr für Anbieter Versichertenstammdaten Management
• der Werktag vor dem Quartalswechsel ab 18:00 Uhr bis den darauffolgenden Tag 6:00 Uhr
• die Zeiten zwischen Weihnachten und Neujahr

2.4 Change Umsetzung

Bei erfolgreicher Umsetzung fordert der TI-ITSM-Teilnehmer so schnell als möglich die Verifizierung des Changes an.

Kommt es während der Umsetzung zu unvorhergesehenen Problemen, die innerhalb des terminierten Wartungsfensters nicht gelöst werden können, ist umgehend ein Rollback zu initiieren und im TI-ITSM-Tool zu dokumentieren.

Es wird ein 4-Augenprinzip sowohl bei der Umsetzung, als auch bei der Verifikation durch die TI-ITSM-Teilnehmer erwartet. 

Es wird erwartet, dass von dem Change betroffene TI-ITSM-Teilnehmer und/oder Kunden eigenverantwortlich vorab informiert werden.

2.5 Change Verifikation

Es wird erwartet, dass unmittelbar mit der Umsetzung eines Changes der Dienst hinreichend auf Verfügbarkeit und Funktionalität hin getestet wird (siehe GS-A_5601-*). Dafür werden mindestens die in dem Feld „Plan für das Erstellen und Testen“ aufgeführten Testszenarien berücksichtigt. Die Dokumentation der Ergebnisse erfolgt im Feld „Build- und Testergebnis“ und muss dem Gesamtverantwortlichen TI innerhalb von 16 Stunden zur Hauptzeit vorliegen (siehe gemRL_Betr_TI).

Der TI-ITSM-Teilnehmer kann den Nachweis über die erfolgreiche Umsetzung des Changes auch als Anhang dem RFC beifügen.

Als Nachweise werden folgende Anhänge beispielsweise akzeptiert:

• Erfolgreicher Login in einer Versicherten-App
• Protokoll eines friendly User Tests
• Auszug von Loganalysen
• Screenshot eines Monitoring Dashboards, das die Verfügbarkeit des Dienstes unmittelbar nach Umsetzung des Changes zeigt

Im Falle einer nicht erfolgreichen Verifikation ist umgehend ein Incident im TI-ITSM-System zu erstellen.

2.6 Change Abschluss

Der Gesamtverantwortliche TI führt bei Bedarf ein Post Implementation Review (PIR) durch. Im Rahmen des PIR identifizierte Abweichungen werden durch den Gesamtverantwortlichen TI aufgenommen und nachverfolgt. Dies kann zu Maßnahmen führen, die in den jeweiligen Betriebsmeetings thematisiert werden.

Nach Change-Abschluss werden die Konfigurationsdaten in der CMDB aktualisiert.

2.7 TI Change-Planungskalender

Der Change-Planungskalender zeigt die geplanten Änderungen aller TI-ITSM-Teilnehmer in einer Kalenderdarstellung an. Es wird erwartet, dass jeder TI-Teilnehmer sich über anstehende Änderungen informiert (siehe Policies). Er ist zugleich ein Organisations- und Planungsinstrument im Rahmen des Change Managements.

3 Anhang A – Verzeichnisse

3.1 Abkürzungen

3.2 Glossar

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

3.3 Abbildungsverzeichnis

3.4 Tabellenverzeichnis

3.5 Referenzierte Dokumente

3.5.1 Dokumente der gematik

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