Change Mgmt - Überarbeitung TI-ITSM-Prozess (RL) und Implementierung Begleitdokument Leitfaden Change Management

Inhaltsverzeichnis

1 Änderungsbeschreibung

 

Vorabinformation zum Änderungseintrag: Folgende Änderungen sind Bestandteil des Änderungseintrages: Aktualisierung des Prozesse Change Management (u.a. Verallgemeinerung der Definition Change, Focus auf Produkt-Change) Initiale Erstellung und Veröffentlichung des Change Leitfadens [gemLF_ITSM-CHM] Überarbeitung der Prozesskopplung mit Config Management (eine Afo anpassen) redaktionelle Änderung an der [gemSpec_OM] (Fehlerbereinigung) Die Nummerierung der Kapitel entspricht nicht der Nummerierung aus den referenzierenden Dokumenten, da diese durch die Formatierung automatisch erzeugt wird. Dies wird bei der Einarbeitung der Änderungen entsprechend beachtet. Erläuterung: Es ist das gesamte Kapitel Change Management mit den entsprechenden Änderungen aufgeführt. Hinweise zur Lesart: <<Text, der zur Erklärung der Änderung dient - wird nicht mit eingearbeitet/übernommen.>> Text, der neu ist. Text, der entfernt wird. Text, der entfernt wird.

2 Änderung in gemRL_Betr_TI

2.1 in Kapitel 1.1: Zielsetzung

Die vorliegenden „Übergreifenden Richtlinien zum Betrieb der TI“ definieren die betrieblichen Mitwirkungspflichten und Schnittstellen zur übergreifenden Zusammenarbeit der Teilnehmer der Telematikinfrastruktur (TI) im IT-Servicemanagement (TI-ITSM) auf prozessualer Ebene. Alle operativ relevanten Mitwirkungsanteile werden ergänzend in den prozessbezogenen Leitfäden aufgeführt. Die gematik behält sich vor, diese max. einmal im Quartal anpassen zu können.  Die übergreifenden Richtlinien gelten für den Betrieb aller Betriebsumgebungen (Referenzumgebung (RU), Testumgebung (TU), Produktivumgebung (PU)).

TI-ITSM-Teilnehmer sowie ergänzende organisatorische Service Level sind Anbieter in [gemKPT_Betr] definiert. Die zur Erbringung der TI-Services benötigten Produkte müssen zugelassen sein.

<..>

Folgende Prozesse werden im TI-ITSM betrachtet:

• Incident Management: Regelungen für den Umgang mit Störungen, die zu einer Qualitätsminderung der TI-Services führen können,
• Problem Management: Regelungen für das Management von unbekannten Ursachen einer eingetretenen/möglichen Störung und der nachhaltigen Beseitigung der identifizierten Störungsursachen,
• Request Fulfillment: Regelungen für das Bearbeiten von Service Requests. Dabei handelt es sich um das Nachfragen nach vordefinierten Dienstleistungen bzw. das Stellen allgemeiner Anfragen und/oder Beschwerden, die von berechtigten TI-Akteuren oder zukünftigen TI-ITSM-Teilnehmern durchgeführt werden,
• Configuration Management: Regelungen für das Management der für die TI-Services erforderlichen Beschreibungsdaten,
• Change & Release Management: Regelungen für das Management von Änderungen der TI-Services sowie Regelungen für das Management zur Überführung von Releases in den Wirkbetrieb,
• Knowledge Management: Regelungen für das Management von Informationen aus dem und für den Wirkbetrieb der TI-Services,
• Service Level Management: Regelungen für das Management zur Definition, Kontrolle sowie Optimierung der Service Level über alle Betriebseinheiten hinweg,
• Performance Management: Regelungen für das Management zur Sicherstellung einer adäquaten Dimensionierung und definierter Service Level konformer Leistungserbringung der TI,
• Servicekatalog-Management: Regelungen für die Erstellung und Bereitstellung von Servicekatalogen der TI-ITSM-Teilnehmer,
• Notfallmanagement: Regelungen für die Notfallvorsorge und die Notfallbewältigung der TI-Services.

<..>

2.2 in Kapitel 1.4: Abgrenzungen des Dokuments

Nicht alle ITSM-Prozesse gemäß ITIL® V3  sind im Rahmen dieses Richtliniendokumentes geregelt. Dies ergibt sich insbesondere

• durch die Fokussierung auf die Mitwirkungspflichten durch TI-ITSM-Teilnehmer im Wirkbetrieb der TI und
• durch Umsetzungsanforderungen, die ausschließlich durch ein spezifisches Reporting umzusetzen sind.
  

Aus oben genannten Gründen sind innerhalb dieses Dokumentes folgende ITSM-Prozesse nicht geregelt:

• Service Design: Weiterentwicklung der TI, Information Security Management
• Service Transition: Subprozesse des Change Managements (On-/Offboarding zentraler Produktinstanzen, Inbetriebnahme und Änderung dezentraler Produktinstanzen der TI), Testmanagement, Release Management
• Service Operation: Operativer Betrieb und Überwachung.

Regelungen für Anwender, Versicherte und DVOs (Dienstleister vor Ort) werden nicht definiert.

2.3 in Kapitel 2.4.1: Eskalationen im übergreifenden TI-ITSM

<..>

<< Änderung der Afo -> Suffix 01 >>

2.4 in Kapitel 4.2.3.2: Lösung für übergreifendes Problem entwickeln und implementieren

<..>

Wird für die Lösung eines Problems eine Änderung an der TI benötigt, ist diese Änderung über den Change & Release Management-Prozess anzustoßen.

<..>

2.5 in Kapitel 6: Configuration Management

<..>

2.5.1 in Kapitel 6.1.1: Konfigurationselement (Configuration Item, CI)

<...>

Die CI-ID wird automatisiert vom GTI vergeben und dem TI-ITSM-Teilnehmer im Rahmen der betrieblichen Prozesse mitgeteilt. Eine CI-ID repräsentiert Konfigurationsdaten des betreffenden Konfigurationselementes (CIs), die in der CMDB des TI-ITSM-Systems gespeichert sind (bspw. Produkttyp, Produkt, Betriebsumgebung und Anbieter). Diese Daten können unterschiedlicher Art und Detaillierungstiefe sein (bspw. Standorte, Instanzen, weitere Konfigurationsdaten). Die CI-ID wird u.a. bei der Identifizierung von Rohdaten-Performance-Berichten (siehe [gemSpec_Perf#2.5.1]) oder bei der Durchführung von Produkt Changes im Rahmen des betrieblichen Change Management Prozesses verwendet.

2.5.2 in Kapitel 6.2.2: Konfigurationsdaten pflegen

<..>

TI-ITSM-Teilnehmer führen Änderungen nur unter Kontrolle des Change & Release Managements sowie des Request Fulfillments durch. Nach erfolgreicher Durchführung der Änderungsprozesse stehen die aktualisierten Daten den TI-ITSM-Teilnehmern bzw. dem Gesamtverantwortlichen TI zur Wahrnehmung der jeweiligen Rolle bedarfsgerecht im TI-ITSM-System zur Verfügung.

<< Kapitel-Header alt: Übermittlung von Konfigurationsdaten nach lokal autorisierten Produkt-Changes >>

2.5.3 in Kapitel 6.2.2.1: Übermittlung von Konfigurationsdaten nach autorisierten Normal-Changes

Sofern ein Change lokal autorisiert wurde, müssen die geänderten Konfigurationsdaten Produktdaten an das Configuration Management übermittelt werden.

<< Afo-Header alt: Übermittlung von Produktdaten nach Abschluss von autorisierten Normal-Changes
Änderung der Afo -> Suffix 01>>

<< Kapitel-Header alt: Change & Release Management >>

2.6 in Kapitel 7: Change Management

Das Change & Release Management stellt sicher, dass alle anzeigepflichtigen Änderungen an Produkten und den darauf basierenden Services kontrolliert durchgeführt werden. Innerhalb des Change Management werden Änderungsanträge (RfC - Request for Change) aufgezeichnet, bewertet sowie autorisiert und die daraus resultierenden Umsetzungen als Änderungsanforderungen koordiniert.

Im vorliegenden Dokument wird das übergreifende  Change Management für Produkttypen, Produkte und deren logische Produktinstanzen geregelt.

Alle Pflichten, die der Sicherstellung betrieblicher und versorgungsrelevanter Belange dienen und somit eine schnelle und flexible Anpassung auf neue oder sich ändernde Situationen erfordern, werden im Dokument "IT Servicemanagement: Leitfaden Change Management" [gemLF_ITSM_CHM] verankert. 

Es werden keine normativen Vorgaben zum lokalen Change Management der TI-ITSM-Teilnehmer gemacht.

Die Beschreibung des Change Management in diesem Kapitel wird ergänzt durch die Beschreibungen in der jeweils aktuellen Version des Dokuments "IT Servicemanagement: Leitfaden Change Management"   [gemLF_ITSM_CHM].

2.6.1 in Kapitel 7.1: Begriffsbestimmungen

2.6.1.1 in Kapitel 7.1.1: Request for Change (RfC)

<<alt>>

Unter einem Request for Change versteht man einen Antrag auf das Hinzufügen, Verändern oder Entfernen von autorisierten Services oder Servicekomponenten unter Bezug auf Configuration Items (Produkte, logische Produktinstanzen und deren Konfiguration sowie Produkttypen). Ein Request for Change wird zum Change nach dessen Autorisierung.

<<neu>>

Unter einem Request for Change (RfC) versteht man einen Antrag auf das Hinzufügen, Verändern oder Entfernen von autorisierten Services oder Servicekomponenten unter Bezug auf spezifische Configuration Items.

Die Änderungsgründe finden sich im Kapitel 2.2.1 des Leitfadens Change Management [gemLF_ITSM_CHM].

2.6.1.2 Kapitel 7.1.2: Produkt-Change - löschen

Ein Produkt-Change beinhaltet Änderungen an einem Produkt bzw. einer logischen Produktinstanz, welches sich bereits im Betrieb befindet oder in den Betrieb eingeführt oder herausgeführt werden soll.

Ein Produkt-Change ist immer eine Wartung und es gibt zwei Durchführungsvarianten.

2.6.1.3 in Kapitel 7.1.2.1: Normal-Change

Ein Normal-Change hat zwei unterschiedliche Ausprägungen. Er kann für eine dedizierte Betriebsumgebung oder für mehrere Betriebsumgebungen über den Master-Sub-Prozess gestellt werden.
Der Master-Sub-Prozess kommt zum Einsatz, wenn eine Änderung auf mindestens zwei Betriebsumgebungen angewendet wird.

Der Master-Sub-Prozess setzt ein Staging-Konzept um und sorgt für eine strukturierte und risikoreduzierende (getestete) Umsetzung der Änderung. Die Umsetzung des Stagings wird durch den Change Bedarfsträger (und Beteiligten) geplant und im Change dokumentiert.

2.6.1.3.1 in Kapitel 7.1.2.2: Master-Change

<<alt>>

Der Master-Change adressiert den Inhalt der Wartung fachlich. Er hat noch keinen konkreten Bezug zur Umsetzung in einer Umgebung (RU TU PU). Im Master-Change-Prozess werden grundsätzliche Entscheidungen (z.B.: Zulassungsrelevanz, Testumfang, oder dem zeitlichen Gesamtverlauf) vereinbart. Die mit dem Master-Change abgestimmten und freigegebenen Änderungen werden mit den sogenannten Sub-Changes in die Umgebungen eingebracht.

<<neu>>

Der Master-Change adressiert den Inhalt der Änderung fachlich. Er wird übergreifend gestellt und hat somit keinen Bezug zur Umsetzung in einer konkreten Betriebsumgebung. Im Master-Change-Prozess werden grundsätzliche Entscheidungen (z.B. Zulassungsrelevanz, Testumfang, oder dem zeitlichen Gesamtverlauf) vereinbart. Die mit dem Master-Change abgestimmten und freigegebenen Änderungen werden mit den sogenannten Sub-Changes in die Betriebsumgebungen eingebracht. 

2.6.1.3.2 in Kapitel 7.1.2.3: Sub-Change

<<alt>>

Der Sub-Change ist einem Master-Change innerhalb eines Produkt-Changes zugeordnet. Er setzt die im Master-Change definierte(n) Änderung(en) in einer konkreten Umgebung und damit der logischen Produktinstanz um. Sub-Changes werden nur im Rahmen von Produkt-Changes verwendet.

<<neu>>

Der Sub-Change ist einem Master-Change zugeordnet. Er setzt die im Master-Change definierte Änderung in einer konkreten Betriebsumgebung und der damit verbundenen logischen Produktinstanz um.

2.6.1.4 Kapitel 7.1.3: Produkttyp-Change - löschen

Ein Produkttyp-Change umfasst die konzeptionellen Änderungen an einem Produkttypen der TI. Ergebnis des Prozesses ist eine geänderte Spezifikation des Produkttypen. Ein Produkttyp-Change kann von TI-ITSM-Teilnehmern oder vom Gesamtverantwortlichen TI gestellt werden.

2.6.1.5 in Kapitel 7.1.4: Standard-Change

Beim Standard-Change handelt es sich um eine wiederkehrende, risikoarme und ausfallfreie Änderung. Ein Standard-Change KANN in einer dedizierten Betriebsumgebung oder als Master-Sub-Konstrukt umgesetzt werden.

Um eine effiziente Durchführung von unkritischen, zeitlich gut planbaren und wiederholt durchzuführenden „Routine“-Changes zu gewährleisten, können Changes als Standard-Change durchgeführt werden.
Standard-Changes werden durch den Gesamtverantwortlichen TI im Rahmen des Change Managements definiert. Jeder Change durchläuft zunächst den Non-Standard Change-Prozess.

<< Afo-Header alt: Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Produkt-Changes
Änderung der Afo -> Suffix 01>>

2.6.1.6 in Kapitel 7.1.5: Emergency-Change (eChange)

<<alt>>

Ein Emergency-Change ist eine Änderung, die aufgrund einer Notsituation durchgeführt werden muss, um so schnell wie möglich diese Notsituation zu lindern. Ein Emergency-Change kann in folgenden beispielhaften Situationen erforderlich werden:

• Nichtverfügbarkeit eines zentralen Plattformdienstes, der die höchste Auswirkung für die TI hat;
• Fehlgeschlagener Produkt-Change, der nicht durch ein Fallback zurückgenommen werden kann, da Auswirkungen auf andere Produkte bestehen;
• Entdeckte Sicherheitslücke, die umgehend behoben werden muss, um (weiteren) Schaden von der TI abzuwenden.

Die Dringlichkeit der Korrektur lässt unter Umständen kein Testen zu; die sofortige Heilung der Notsituation ist das primäre Ziel. Das damit einhergehende Risiko wird bewusst in Kauf genommen.

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

<<neu>>

Ein Emergency-Change ist eine Änderung, die aufgrund einer Notsituation durchgeführt werden muss, um so schnell wie möglich diese Notsituation zu lindern.
Die Dringlichkeit der Korrektur lässt unter Umständen kein Testen zu; die sofortige Heilung der Notsituation ist das primäre Ziel. Das damit einhergehende Risiko wird bewusst in Kauf genommen.

<< Bem: Neue Afo oder Afo GS-A_5370 aus Kapitel 7.2.1 dafür umschreiben und verwenden? >>

Ein Emergency-Change darf außerhalb der Servicezeiten der gematik ohne Genehmigung umgesetzt werden. Die Dokumentation im TI-ITSM-System kann im Nachgang erfolgen. Innerhalb der Servicezeiten der gematik ist eine Genehmigung erforderlich. Bei Bedarf KANN ein Emergency-Change Advisory Board (e-CAB) durch den Gesamtverantwortlichen TI einberufen werden.

<< redaktionelle Änderung: Change Management in Titel davor stellen>>

2.6.1.7 Kapitel 7.1.10: Wartung - verschieben nach Kapitel "Begriffsbestimmungen/Request for Change"

Die Wartung eines IT-Systems ist ein Teil der primären Lebenszyklus-Prozesse gemäß [ISO/IEC/IEEE 12207:2017]. Sie umfasst alle getroffenen Maßnahmen, welche sich korrigierend oder verbessernd auf das IT-System auswirken. Eine Wartung kann nach [ISO/IEC/IEEE 14764:2022] verschiedenen Zwecken dienen und wird im Rahmen des Change & Release Managements festgelegt und durchgeführt. 

2.6.1.8 Kapitel 7.1.11: Wartungsfenster - verschieben nach Kapitel "Change: Request for Change (RfC) erstellen"

Ein Wartungsfenster ist der definierte Zeitraum mit Start- und Endzeit, in dem eine Wartung durchgeführt wird. Wartungsfenster werden im Rahmen des Change & Release Managements vom TI-ITSM-Teilnehmer angekündigt und vor der Durchführung vom Gesamtverantwortlichen TI genehmigt. 

2.6.1.9 in Kapitel 7.1.6: Betriebliches Change-Bewertungsgremium (BCB) - löschen

Das Betriebliche Change-Bewertungsgremium (BCB) ist das Board des Gesamtverantwortlichen TI, in dem RfCs bewertet und über deren weiteren Umsetzungsverlauf entschieden wird. Dabei werden die beteiligten TI-ITSM-Teilnehmer bei Bedarf in die Entscheidungsfindung und Umsetzungsplanung durch den Gesamtverantwortlichen TI einbezogen.

2.6.1.10 in Kapitel 7.1.7: Change Advisory Board (CAB) - löschen

Das Change Advisory Board ist ein Gremium, das aus allen relevanten Vertretern der TI-ITSM-Teilnehmer, die von der Durchführung eines konkreten Changes betroffen sind, besteht. Wird eine vom BCB getroffene Entscheidung von den beteiligten TI-ITSM-Teilnehmern nicht mitgetragen, wird das CAB vom Gesamtverantwortlichen TI einberufen um das weitere Vorgehen abzustimmen oder zu eskalieren.

2.6.1.11 in Kapitel 7.1.8: Emergency Change Advisory Board (eCAB) - löschen

Das Emergency Change Advisory Board (eCAB) ist eine besondere Organisationsform des CAB, organisiert durch den Gesamtverantwortlichen TI. Die Zusammensetzung wird fallbezogen festgelegt. Ziel und Aufgabe des eCAB ist es, bei auftretenden Anforderungen zur Durchführung eines Emergency Change eine möglichst zeitnahe Bewertung und Autorisierung bzw. Ablehnung herbeizuführen. Hierfür müssen die Teilnehmer mit entsprechenden Kompetenzen ausgestattet sein.

2.6.1.12 in Kapitel 7.1.9: Post Implementation Review (PIR)

Beim Abschluss des Master-Changes führt der Gesamtverantwortliche TI bei Bedarf das Post Implementation Review gemeinsam mit dem Durchführenden des Produkt-Changes durch. Ziel ist die Identifizierung von Optimierungspotenzialen und deren Umsetzung in den weiteren Change-Durchführungen.

<< Kapitel-Header alt: Change- & Release Kalender >>

2.6.1.13 in Kapitel 7.1.10: Change-Kalender

Der Change- & Release-Kalender zeigt die laufenden Aktivitäten im Change & Release Management in einer Kalenderdarstellung übersichtlich für alle beteiligten TI-ITSM-Teilnehmer dar. Der Kalender dient allen am Betrieb der TI Beteiligten dazu, sich über anstehende und durchgeführte Änderungen informieren zu können. Er ist zugleich ein Organisations- und Planungsinstrument im Rahmen des Change Managements. Er ersetzt nicht die aktive Steuerung eines Change in der TI, sondern ermöglicht eine langfristige Vorschau auf geplante Änderungen und ist ein zusätzliches Hilfsmittel bei der Analyse von Störungsursachen bezüglich der Identifikation von Seiteneffekten bereits umgesetzter Änderungen. 

<< Kapitel-Header alt: Prozessdurchführung Change & Release Management>>

2.6.2 in Kapitel 7.2 Prozessdurchführung Change Management

Figure # : Abb_gem_Betr_Change_Management-Prozessdurchführung

<< Kapitel-Header alt: Produkt-Change: Request for Change (RfC) erstellen>>

2.6.2.1 in Kapitel 7.2.1 Change: Request for Change (RfC) erstellen

Jede Änderung an einer TI-relevanten IT-Komponente oder an einem Produkt muss als Change erfasst werden. Darüber hinaus können Produktänderungsbedarfe können durch verschiedene Einflussfaktoren bei den TI-ITSM-Teilnehmern festgestellt werden. Diese können sich aus dem Incident Management, dem Problem Management oder auch durch Änderungsbedarfe eines Produktes ergeben.

Ein Wartungsfenster ist der definierte Zeitraum mit Start- und Endzeit, in dem eine Wartung durchgeführt wird. Wartungsfenster werden im Rahmen des Change & Release Managements vom TI-ITSM-Teilnehmer angekündigt und vor der Durchführung vom Gesamtverantwortlichen TI genehmigt.

Nicht vollständig erfasste RfCs werden vom TI-ITSM-System nur gespeichert, nicht an den Gesamtverantwortlichen TI zur Bewertung und Autorisierung weitergeleitet.

<< Afo-Header alt: Produkt-RfC (Master-Change) erstellen

Änderung der Afo -> Suffix 01>>

<< Afo-Header alt: Prüfung auf genehmigungspflichtige Produktänderung

Änderung der Afo -> Suffix 01>>

<< Afo-Header alt: Produkt-RfC (Sub-Changes) erstellen

Änderung der Afo -> Suffix 01>>

Lokal autorisierte Changes sind informationspflichtig im Rahmen des Configuration Managements (GS-A_4399).

Um die Wirksamkeit eines Produkt-Changes nachzuweisen, ist eine Verifikation notwendig. Hiermit wird nachgewiesen, dass der Produkt-Change wie geplant implementiert wurde und die TI-Services TI-Fachanwendungen weiterhin verfügbar und funktional sind. Die Verifikationsbeschreibung ist Bestandteil des Master-Changes eines jeden Changes.

<< Afo-Header alt: Beschreibung der Verifikation des Produkt-Changes im RfC

Änderung der Afo -> Suffix 01>>

<< Afo GS-A_5600 löschen, ist in GS-A_5599-01 aufgegangen:>>

<< Afo-Header alt: Beschreibung der Verifikation des Produkt-Changes in Auswirkung auf andere TI-Fachanwendungen im RfC >>

<< Afo GS-A_5370 entfernen; Inhalt ist in LF übergegangen>>

<<< Kapitel-Header alt: Produkt-Change: RfC bewerten>>

2.6.2.2 in Kapitel 7.2.2 Change: RfC bewerten

Die Bewertung und Autorisierung eines RfC obliegt dem Gesamtverantwortlichen TI. Um diese Aufgabe wahrzunehmen ist er ggf. auf die Unterstützung weiterer TI-ITSM-Teilnehmer angewiesen.

<< Afo-Header alt: Mitwirkungspflicht bei der Bewertung vom Produkt-RfC

Änderung der Afo -> Suffix 01>>

Damit der Gesamtverantwortliche TI die Aufgabe der Bewertung und Autorisierung in angemessener Qualität durchführen kann sind Bearbeitungsfristen festgelegt.

<< Afo-Header alt: Bearbeitungsfristen in der Bewertung von Produkt-Changes

Änderung der Afo -> Suffix 01>>

[gemKPT_Betr]

Werden diese Fristen nicht eingehalten, so kann der Gesamtverantwortliche TI die Bewertung des Changes ablehnen. Dies führt zu einer Stornierung des RfC bzw. des gesamten Change-Vorgangs. Dies kann zu einer Stornierung des RfC bzw. des gesamten Change-Vorgangs führen.

2.6.2.3 in Kapitel 7.2.3 Change: Change Advisory Board (CAB)

Das Change Advisory Board dient der Sicherstellung eines stabilen und sicheren Betriebs. Es ist ein Gremium, das sich aus allen relevanten Vertretern der TI-ITSM-Teilnehmer und des Gesamtverantwortlichen TI zusammensetzt. Zu letzteren zählen insbes. die verantwortlichen Provider Manager sowie Change Manager. Die Teilnahme an einem CAB ist verpflichtend.

Dabei werden relevante und sich im Scope (Details siehe [gemLF_ITSM_CHM]) befindliche Changes besprochen, deren Risiken identifiziert, und ggf. abgeschwächt und bei Bedarf eine Stakeholderkommunikation abgestimmt.

2.6.2.4 in Kapitel 7.2.4 Change: Emergency Change Advisory Board (eCAB)

Das Emergency Change Advisory Board (eCAB) ist eine besondere Organisationsform des CAB, organisiert durch den Gesamtverantwortlichen TI. Die Zusammensetzung wird fallbezogen festgelegt. Ziel und Aufgabe des eCAB ist es, bei auftretenden Anforderungen zur Durchführung eines Emergency Change eine möglichst zeitnahe Bewertung und Autorisierung bzw. Ablehnung herbeizuführen. Hierfür müssen die Teilnehmer mit entsprechenden Kompetenzen ausgestattet sein.

<< Kapitel-Header alt:  Produkt-Change: RfC genehmigen >>

2.6.2.5 in Kapitel 7.2.5 Change: RfC genehmigen

Der realisierende TI-ITSM-Teilnehmer hat sich die für die Autorisierung notwendigen Genehmigungen des GesamtverantwortIichen der TI einzuholen.

<< Kapitel-Header alt:  Produkt-Change: Umsetzung verifizieren >> 

2.6.2.6 in Kapitel 7.2.6 Change umsetzen

Die Umsetzung des autorisierten Produkt-Changes obliegt dem zuständigen TI-ITSM-Teilnehmer. Die Umsetzung eines Master-Changes bedeutet, dass im nächsten Schritt die konkreten Sub-RfCs durch den TI-ITSM-Teilnehmer gestellt werden müssen.

Die Umsetzung von Sub-RfCs bedeutet die konkrete Änderung eines Produktes und damit einer logischen Produktinstanz in der jeweiligen Betriebsumgebung. Grundsätzlich wird davon ausgegangen, dass jede Änderung eines Produktes von der RU über die TU bis zur PU sequenziell durchgeführt werden muss. Ausnahmen davon müssen im Rahmen des Master-Changes zwischen TI-ITSM-Teilnehmer und dem Gesamtverantwortlichen TI vereinbart werden.

Die Referenzumgebung (RU) und die Testumgebung (TU) werden vom Gesamtverantwortlichen TI koordiniert. Der realisierende TI-ITSM-Teilnehmer stimmt sich mit der testkoordinierenden Instanz ab und berücksichtigt diese Abstimmung in der Ausprägung der entsprechenden Sub-RfCs (RU und TU).

Das Deployment eines Produkt-Changes Die Umsetzung eines Changes wird durch den Gesamtverantwortlichen TI zeitlich und verfahrenstechnisch prozessual überwacht. TI-ITSM-Teilnehmer müssen die Umsetzung des Produkt-Changes gemäß den Vorgaben vom Gesamtverantwortlichen TI durchführen und stetig deren Einhaltung prüfen und Abweichungen an den Gesamtverantwortlichen TI über das TI-ITSM-System kommunizieren.

<<Änderung der Afo -> Suffix 01>>

Ein Produkt-Change gilt als implementiert, wenn:

• bei zentralen Produkten die Integration der geänderten Produktversion in die jeweilige Betriebsumgebung abgeschlossen ist,
• bei dezentralen Produkten die geänderte Produktversion auf dem Konfigurations-Software-Repository (KSR) bereitgestellt ist.

<< Kapitel-Header alt:  Produkt-Change: Umsetzung verifizieren >>

2.6.2.7 in Kapitel 7.2.7 Change: Umsetzung verifizieren

<<Änderung der Afo -> Suffix 01>>

Organisatorische Service Level siehe [gemKPT_Betr].

<< Afo-Header alt: Nachweis der Wirksamkeit eines Changes in Auswirkung auf andere TI-Fachanwendungen
Änderung der Afo -> Suffix 01>>

<<Änderung der Afo -> Suffix 01>>

Der Gesamtverantwortliche der TI legt den Teilnehmerkreis zur Verifikation im Rahmen der Produkt-Change-Freigabe fest.

<< Kapitel-Header alt: : Produkt-Change abschließen>>

2.6.2.8 in Kapitel 7.2.8: Change abschließen

Sind die Umsetzungsarbeiten abgeschlossen, kann der Change nach erfolgreicher Verifikation und abschließender Dokumentation geschlossen werden.

<< Afo-Header alt: Bereitstellung der Dokumentation des Change Managements für genehmigungspflichtige Produkt-Changes

Änderung der Afo -> Suffix 01>>

Nach Abschluss des letzten Sub-RfCs ist der zugehörige Master-RfC ebenfalls vom TI-ITSM-Teilnehmer abzuschließen. Dabei kann der TI-ITSM-Teilnehmer Anforderungen an zukünftige Durchführungen ähnlicher Art, die zur Optimierung des Durchführungsprozesses dienen, an den Gesamtverantwortlichen TI übermitteln.

<< Afo-Header alt: Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Produkt-Changes
Änderung der Afo -> Suffix 01>>

Der Gesamtverantwortliche TI wird nach einem ggf. mit dem durchführenden TI-ITSM-Teilnehmer abschließenden PIR (Post Implementation Review) den Master-Change und damit den Gesamtvorgang schließen. 

Ziel ist die Identifizierung von Optimierungspotenzialen und deren Umsetzung in den weiteren Change-Durchführungen.
Beim Abschluss eines Changes führt der Gesamtverantwortliche TI ein Post Implementation Review durch. Ziel ist die Identifizierung von Optimierungspotenzialen und deren Umsetzung in den weiteren Change-Durchführungen. 

2.6.3 in Kapitel 7.3 Abweichungen im Prozessablauf

Bei einer festgestellten Abweichung des dem aktuellen Produkt-Change zugrunde liegenden Produkt-RfCs wird der Gesamtverantwortliche TI entscheiden, welche Konsequenzen die Feststellung bzw. Abweichung auf die weitere Durchführung des Produkt-Changes hat und welche Maßnahmen zu treffen sind.

Dazu wird sich der Gesamtverantwortliche TI mit dem durchführenden TI-ITSM-Teilnehmer und bei Bedarf mit den beteiligten TI-ITSM-Teilnehmern beraten. Die Ergebnisse werden vom Gesamtverantwortlichen TI im TI-ITSM-System dokumentiert, ebenso wie eine eventuelle Status-Änderung des Produkt-Changes (bspw. Stornierung). Die beteiligten TI-ITSM-Teilnehmer werden vom Gesamtverantwortlichen TI hierüber abschließend per E-Mail informiert.

<< Afo-Header alt: Übermittlung von Abweichungen vom Produkt-RfC
Änderung der Afo -> Suffix 01>>

Festgestellte schwerwiegende Konflikte bei der Bewertung oder Durchführung eines Produkt-Changes sind gemäß GS-A_3920 an den Gesamtverantwortlichen TI zu eskalieren.

Stellen die an einem Produkt-Change beteiligten TI-ITSM-Teilnehmer negative Auswirkungen einer Änderung während der Umsetzung fest, so kann der Gesamtverantwortliche TI die Durchführung des im Produkt-Change hinterlegten Fallbackplans anweisen.

<< Afo-Header alt: xxx
Änderung der Afo -> Suffix 01>>

<<Änderung der Afo -> Suffix 01>>

2.6.4 Kapitel 7.4: Verfahren für einen Standard-Change - löschen

Um eine effiziente Durchführung von unkritischen, zeitlich gut planbaren und wiederholt durchzuführenden „Routine“ Produkt-Changes zu gewährleisten, können Changes als „Standard-Changes“ durchgeführt werden.

Standard-Changes werden durch den Gesamtverantwortlichen TI im Rahmen des Change Managements definiert. Jeder Change durchläuft zunächst den Non-Standard Change-Prozess. Aus einem Non-Standard-Change wird ein Standard-Change, wenn folgende Kriterien erfüllt sind:

• Erstmalige, fehlerfreie Ausführung des Non-Standard-Changes und
• Minimales Risiko bei der Ausführung.

Die Abstimmung der Standard-Changes findet im Rahmen des Post Implementation Reviews statt.

<< Afos in Kapitel 7.1.4 verschoben: Kapitel kann gelöscht werden>>

2.6.5 Kapitel 7.5: Verfahren für einen Emergency-Change - löschen

<< Afos in Kapitel 7.1.5 verschoben: Kapitel kann gelöscht werden>>

2.7 in Kapitel: Dokumente der gematik

<..>

[Quelle]	Herausgeber: Titel
[gemGlossar]	gematik: Glossar der Telematikinfrastruktur
[gemKPT_Betr]	gematik: Betriebskonzept Online-Produktivbetrieb
[gemSpec_DS_Anbieter]	gematik: Spezifikation Datenschutz- und Sicherheitsanforderungen der TI an Anbieter
[gemSpec_Perf]	gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform
[gemLF_ITSM_CHM]	gematik: IT Servicemanagement: Leitfaden Change Management

2.8 Änderungen in gemKPT_Betr

2.8.1 in Kapitel 3.5.3: Mitwirkungsverpflichtung im TI-ITSM gemäß [gemRL_Betr_TI]

<..>

Tabelle 3: Tab_KPT_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	A/E X	.	.	A/E	E	E	A/E	.	A/E	A/E
Anbieter Anschlusspunkt SGW / SZZP	A/E	A/E	E X	.	A/E	A	A	A	.	.	.	A/E
Anbieter Apothekenverzeichnis	A/E	A/E	A/E X	E	A/E	A/E	A	A	A/E	A	A/E	A/E
Anbieter Basis-Consumer	A/E	A/E	A/E X	.	A/E	A	.	.	A/E	.	A/E	A/E
Anbieter CVC-Root-CA	A/E	A/E	A/E X	A/E	A/E	E	.	.	A/E	.	A/E	A/E
Anbieter eHealth-CardLink	A/E	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	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter E-Rezept-Fachdienst	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter E-Rezept FdV	A/E	A/E	A/E X	.	A/E	A	.	.	A/E	.	A/E	A/E
Anbieter E-Rezept AdV	A/E	A/E	A/E X	.	A/E	A	.	.	A/E	.	A/E	A/E
Anbieter Fachdienst KIM	A/E	A/E	A/E X	.	A/E	A	A	.	A/E	.	A/E	A/E
Anbieter Federation Master	A/E	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	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter Highspeed Konnektor	A	A	E X		.	A	.	.	A/E	.	.	A
Anbieter Identity Provider - Dienst	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter KTR-AdV	A	A	A/E X	.	.	A	.	.	A/E	.	A/E	E
Anbieter KTR-Consumer	A/E	A/E	A/E X	.	A/E	A	.	.	A/E	.	A/E	A/E
Anbieter Sektoraler Identity Provider Kostenträger	A/E	A/E	A/E X	A/E	A/E	A/E	A/E	A/E	A/E	A/E	A/E	A/E
Anbieter Service Monitoring	A/E	A/E	A/E X	.	A/E	E	A	A	A/E	.	A/E	A/E
Anbieter SGD_ePA zentral	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter Signaturdienst	A/E	A/E	A/E X	.	A/E	A	A	A	.	.	A/E	A/E
Anbieter SMC-B / HSM-B	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter TI-Messenger	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter TSP CVC eGK	.	.	A/E X	.	A/E	A	.	.	A/E	.	A/E	A/E
Anbieter TI-Gateway	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter VPN-Zugangsdienst	A/E	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	A/E X	.	A/E	A/E	.	.	A/E	.	A/E	A/E
Anbieter X.509 TSP eGK	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Anbieter ZPD	A/E	A/E	A/E X	P	A/E	E	A	A	A/E	A	A/E	A/E
Fachdienst VSDM	A/E	A/E	A/E X	.	A/E	A	A	.	A/E	.	A/E	A/E
Service Provider NCPeH-Fachdienst	A/E	A/E	A/E X	.	A/E	A	A	A	A/E	.	A/E	A/E
Hersteller Primärsysteme	A/E	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	.	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

<..>

Legende:

<..>

A: Auslöser in INC, PRO, CHG

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

E: Empfänger von INC, PRO, CHG

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

X: nimmt in INC, PRO, CHG teil

<..>

2.9 Änderungen in Steckbriefen

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemAnbT_...]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Alle Anbieter =

Anb_SMC-B, Anb_eRp_FD, Anb_HBA, Anb_IDP-D, Anb_eRp_FdV, Anb_SigD, Anb_ZD, Anb_VPN_ZugD, Anb_eRp_AdV, Anb_IDP-Sek_KTR, Anb_PKG, Anb_PoPP_Service, Anb_KTR-Consumer, Anb_Aktensystem_ePA, Anb_NCPeH_FD, Anb_FD_VSDM, Betriebsdatenerfassung, Anb_TIM_FD, Anb_eHealth-CardLink, Anb_FD_KOM-LE, Anb_APOVZD, Anb_CVC_Root, Anb_X.509_TSP_eGK, Anb_TIM_Client, Anb_SGD_ePA, Anb_Basis-Consumer, Anb_Konn_Highspeed, Anb_CVC_TSP_eGK, Anb_IDP_FedMaster, Anb_TI_Gateway, Anb_VSDM_2_FD

MWPF = Mitwirkungspflichten gemäß Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM (s.o.)

TI-ITSM-Prozess	Afo-ID	Titel	Anbietertyp / Produkttyp	Prüfverfahren Anzeige	Änderung
CFG	GS-A_4399-01	Übermittlung von Produktdaten nach Abschluss von autorisierten Normal-Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung	Änderung ML-160645
CHG	GS-A_5366-01	Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Standard-Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Anbietererklärung	Änderung ML-160613
CHG	GS-A_5378	Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-97604
CHG	GS-A_5361	Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer bei Nichterreichbarkeit des Gesamtverantwortlichen TI	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-97605
CHG	A_13575	Qualität von RfCs	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-97577
CHG	GS-A_4400-01	RfC (Master-Change) erstellen	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160620
CHG	GS-A_4398-01	Prüfung auf genehmigungspflichtige Produktänderung	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160622
CHG	GS-A_5597-01	RfC (Sub-Changes) erstellen	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160623
CHG	GS-A_5599-01	Beschreibung der Verifikation des Changes im RfC	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160624
CHG	GS-A_5600	Beschreibung der Verifikation des Changes in Auswirkung auf andere TI-Fachanwendungen im RfC			löschen, da in GS-A_5599-01 aufgegangen
CHG	GS-A_5370	Prüfung auf Emergency Change			löschen, da in Leitfaden
CHG	GS-A_4402-01	Mitwirkungspflicht bei der Bewertung vom RfC	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160625
CHG	GS-A_5610-03	Bearbeitungsfristen in der Bewertung von Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch organ./betriebl. Eignung: Prozessprüfung,	Änderung ML-160626
CHG	GS-A_5611	Umsetzung von autorisierten RFC	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-97588
CHG	GS-A_4419	Nutzung der Testumgebung (RU/TU)	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-97590
CHG	GS-A_4417-01	Stetige Aktualisierung des Change-Datensatzes im TI-ITSM-System	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	--- ML-160627
CHG	A_24799	ChangeManagement - e2e-Funktionsprüpfung nach Change	Anb_Aktensystem_ePA	organ./betriebl. Eignung: Betriebshandbuch	--- ML-147813
CHG	GS-A_5601-01	Nachweis der Wirksamkeit eines Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160634
CHG	GS-A_5602-01	Nachweis der Wirksamkeit eines Changes in Auswirkung auf andere TI-Anwendungen	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160635
CHG	A_18407-01	Unterstützung bei Change-Verifikation	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Anbietererklärung	Änderung ML-160636
CHG	GS-A_4407-01	Bereitstellung der Dokumentation des Change Managements für genehmigungspflichtige Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160637
CHG	GS-A_4425-01	Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Changes	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160639
CHG	GS-A_4418-01	Übermittlung von Abweichungen vom RfC	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160640
CHG	GS-A_4424-01	Umsetzung des Fallbackplans	Alle Anbieter gemäß MWPF	organ./betriebl. Eignung: Prozessprüfung, organ./betriebl. Eignung: Anbietererklärung, organ./betriebl. Eignung: Betriebshandbuch	Änderung ML-160641

3 Änderung in gemSpec_OM

3.1 in Kapitel 2.3.5 Zusammenfassung und Übersicht / Regelwerk relevanter Informationen

Die folgende Zusammenfassung der Definitionen und das aufgeführte Regelwerk bzgl. der Versionierung von Produkten stellt die Basis für das "Übergreifende Change Management" im Rahmen des TI-ITSM (siehe auch [gemRL_Betr_TI]) dar.

Übersicht der Definition des Änderungsumfangs:

In Tabelle "Tab_Änderungsumfang – Übersicht der Definition des Änderungsumfangs bei Versionierung" ist die  Definition der Kriterien für den Umfang einer Änderung in Abhängigkeit für die Artefakte Produkttyp und Produkt  (siehe "Tab_Änderungsumfang – Übersicht der Definition des Änderungsumfangs bei Versionierung") tabellarisch zusammengefasst,

Tabelle 4: Tab_Änderungsumfang – Übersicht der Definition des Änderungsumfangs bei Versionierung

Artefakt	Signifikante Änderung	Moderate Änderung	Änderung beeinflusst das Artefakt bezüglich seiner Außensicht nicht	Änderung beeinflusst das Artefakt bezüglich seiner Außensicht nicht und Änderung wurde nicht bereits durch die Revisionsnummer abgebildet
Produkttyp	... sind Spezifikationsänderungen, die in der Regel an den Außenschnittstellen des Produkttyps nicht mehr abwärtskompatibel sind.	... sind Spezifikationsänderungen, die eine funktionale Erweiterungen des Produkttyp umsetzen, die in der Regel an den Außenschnittstellen des Produkttyps in einem bestimmten Umfang abwärtskompatibel sind.	... sind Spezifikationsänderungen, die die Außenschnittstellen eines Produkttyps nicht beeinflussen. Eine technische Abwärtskompatibilität ist immer gegeben.	... sind Spezifikationsänderungen, die die Außenschnittstellen bzw. die technische Umsetzung des betreffenden Produkttyps nicht beeinflussen.
	Beispiel: Veränderungen der Geschäftslogik durch neue funktionale und organisatorische Spezifikationsanpassung	Beispiel: Weitere Definition von Endpunkten oder Konkretisierung des Verhaltens zu bspw. Fehlercodes an den Außenschnittstellen	Beispiel: Optimierungen in Abläufen, die für die aufrufenden Produkttypen transparent sind. Änderungen an der Betriebsdatenerfassung zur Lieferung von Rohdaten an die gematik	Beispiel: redaktionelle Änderung, Wegfall von Anforderungen
Produkt	... liegt vor, wenn die Produktänderung größere Features oder Feature-Änderungen enthält (Upgrade).	... liegt vor, wenn die Produktänderung kleinere Features oder Feature-Änderungen enthält (Upgrade).	... liegt vor, wenn die Produktänderung Fehlerkorrekturen oder Regeländerungen enthält (Upgrade).	... liegt vor, wenn die Produktänderung unterhalb der Revisionsnummer erfolgt (Update).
	Beispiel: Umfassende Quellcode-Refaktorisierung, Austausch von unterliegenden Quellsystemen / Wechsel von Quellsystemen eines Dritten	Beispiel:  Schnittstellenänderungen, Austausch von Adaptern eines Dritten, Feature-Erweiterungen	Beispiel: Java-Upgrade (mit inhaltl. Auswirkung auf das Produkt); Bereitstellung von OS-, Middleware-Upgrades mit inhaltl. Auswirkung auf das Produkt	Beispiel: Installation von Security-Updates / Hot-Fixes; Bereitstellen von Updates div. Deployment-Artefakte wie Container / Images / Pods; Installation von Security-Updates, Hotfixes mit inhaltl. Auswirkung auf das Produkt
-> Auswirkung Versionierung des Artefakts	Hauptversionsnummer	Nebenversionsnummer	Revisionsnummer	Co-Revisionsnummer / Suffix

Erläuterung zu Update / Upgrade:

Mit Upgrades gehen oft neue Datenmodelle oder neue Verknüpfungen von bestehenden Datenmodellen einher. Hierfür werden z. B. neue Software-Module eingespielt, installiert und konfiguriert. Upgrades sind funktionsverändernd.

Bei Updates werden hingegen neue Versionen von bestehenden Modulen installiert. Sie stellen Aktualisierungen eines Produktes dar, die z.B. Fehler beheben oder die Performance verbessern, Updates sind nicht funktionsverändernd.

Zusammenfassung des Regelwerks bzgl. Versionierung von Produkten:

Die detaillierte Definition der Kriterien für den Umfang einer Änderung wird für spezifische Produkttypen und Produkte durch die gematik vorgenommen (das jeweils verantwortliche Produktteam).

Jeder Änderung einer Versionsnummer muss aktiv im Rahmen des Change Managements durch die gematik zugestimmt werden.

Bei allen Änderungen an der Haupt-/Neben- und Revisionsnummer MUSS eine Neu- Bzw. Folgezulassung erfolgen.

Änderungen an der Version des Produkttypen mit Auswirkung auf die Produktversion

Tabelle 5: Tab_Änderung_Produkttyp -> Produkt – Änderung Version Produkttyp mit Auswirkung auf Produktversion

Änderung an der PTV-Version	Auswirkung auf Produktversion
PTV mit geänderter 1. Stelle	Änderung Produktversion 1. Stelle notwendig (MUSS) (basierend auf GS-A_5039-1)
PTV mit geänderter 2. Stelle	Änderung Produktversion 1. Stelle notwendig (MUSS) (basierend auf GS-A_5039-1)
PTV mit geänderter 3. Stelle	Änderung Produktversion 2. Stelle in Absprache mit der gematik
PTV mit geänderter 4. Stelle	keine Änderung der Produktversion notwendig

Die Regeln für Produkttypen sind auch auf Anbietertypen übertragbar.

Änderungen am Produkt des Herstellers (ohne Änderung der Produkttypversion)

Tabelle 6: Tab_Änderung_Produkt – Änderung am Produkt

Art der Änderung am Produkt	Beschreibung der Tätigkeiten
Signifikante Änderung - Produktänderung enthält größere Features oder Feature-Änderungen	Änderung Produktversion 1. Stelle (MUSS) (basierend auf GS-A_5040-1)
Moderate Änderung - Produktänderung enthält kleinere Features oder Feature-Änderungen	Änderung Produktversion 2. Stelle (MUSS) (basierend auf GS-A_5040-1)
Ohne Beeinflussung der Außensicht / Schnittstellen Beeinflussung der Außensicht / Schnittstellen und keine signifikante oder moderate Änderung	Änderung Produktversion 3. Stelle (MUSS) (basierend auf GS-A_5040-1)
Weitere Änderungen - Produktänderung unterhalb der 3. Stelle (optionaler Patchlevel) (beeinflusst bezüglich seiner Außensicht nicht und wurde nicht bereits durch die Revisionsnummer abgebildet)	Änderung Produktversion 4. Stelle (MUSS) (basierend auf GS-A_5040-1)