latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Spezifikation
Operations und Maintenance

    

     

      
Version
      
1.16.0
     
     

      
Revision
      
901993
     
     

      
Stand
      
20.02.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_OM
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

vorliegende übergreifende Spezifikation definiert Anforderungen für die Themenbereiche Versionierung, Fehlerbehandlung und Logging, die bei der Realisierung (bzw. dem Betrieb) von Produkttypen der TI zu beachten sind. Diese Anforderungen sind als übergreifende Regelungen relevant für Interoperabilität und Verfahrenssicherheit.

Dabei kann es sich um Festlegungen handeln, die direkt von Herstellern bzw. Anbietern von Produkten zu beachten sind, oder um Festlegungen, die im Rahmen von produkttypspezifischen Spezifikationen weiter detailliert werden.

Versionierung (Kap. 2)

Aus Gründen der Nachvollziehbarkeit müssen alle Artefakte im Umfeld der Telematikinfrastruktur nach definierten Vorgaben versioniert werden. Weiterhin ist die Auskunftspflicht zu Versionsnummern einzuhalten. Die Versionsnummern von Produkten und Schnittstellen dienen auch als Grundlage für die Definitionen und Auswertung von Kompatibilitäten zwischen Produkttypen.

Fehlerbehandlung (Kap. 3)

Fehlerzustände können an verschiedenster Stelle innerhalb der TI im Wirkbetrieb auftreten und haben i.d.R. Einfluss auf die Verfügbarkeit von Anwendungsfällen der Fachanwendungen und der TI-Plattform. Eine definierte und strukturierte Fehlerbehandlung ist zwingend nötig, um übergreifend aufgetretene Fehlerzustände zu beschreiben, weiterzuleiten, zu verarbeiten und anzuzeigen.

Logging (Kap. 4)    

Jede Komponente im Wirkbetrieb ist angehalten, festgelegte Ereignisse zu protokollieren („Logging“) und daher nachvollziehbar zu halten. Im Gegensatz zur Fehlerbehandlung sollen hier auch Rückschlüsse auf den Normalfall ermöglicht werden, ohne dass eine Fehlermeldung ausgelöst werden muss (beispielsweise im PerformanceLog).

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis:

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Festlegungen zum Themenbereich Migration sind nicht Bestandteil des vorliegenden Dokumentes.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselwörter MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

2 Versionierung

2.1 Grundlagen der Versionierung

2.1.1 Versionierte Artefakte

Folgende Artefakte werden in der TI versioniert:

• Produkttypen
• Produkte
• Software-Module
• Schnittstellen
• Datenstrukturen

2.1.2 Spezifikation des Formats von Versionsnummern

Z. B. können für Testzwecke Versionsnummern vergeben werden, die aufgrund von Korrekturen nie im Wirkbetrieb sichtbar werden. Die Nummerierung eines Artefakts ist damit nicht zwangsweise in jedem Kontext (z. B. im Wirkbetrieb) lückenlos.

Sowohl signifikante Änderungen (wie Hinzufügen oder Entfernen einer Funktionalität), als auch moderate Änderungen (wie die Modifikation einer bereits bestehenden Funktionalität) oder die Durchführung von Fehlerkorrekturen ziehen eine Änderung der Versionsnummer nach sich.

Die Bedeutung der einzelnen Teile der Versionsnummer für die einzelnen Artefakte ist im Rahmen dieses Dokuments in den folgenden Kapiteln näher erläutert und dient als Hilfestellung zur Interpretation der vorgenommenen Änderungen.

2.2 Versionierung von Produkttypen

Die Konzepte und Spezifikationen der gematik definieren final die Menge der Produkttypen der TI sowie ihre Umsetzungsgrundlage. Die Produkttypen werden durch die gematik entsprechend [GS-A_3695] versioniert (Produkttypversion) und entsprechend [GS-A_3696] fortgeschrieben.

Die Bedeutung der Versionsnummern bei der Fortschreibung folgt der grundlegenden Festlegung aus [GS-A_3697] mit folgender Konkretisierung:

• Die Hauptversionsnummer erhöht sich, falls aufgrund von Spezifikationsänderungen signifikante Änderungen am Produkttyp durchgeführt werden, die in der Regel an den Außenschnittstellen des Produkttyps nicht mehr abwärtskompatibel sind.
• Die Nebenversionsnummer erhöht sich, falls funktionale Erweiterungen am Produkttyp durchgeführt werden, die in der Regel an den Außenschnittstellen des Produkttyps in einem bestimmten Umfang abwärtskompatibel sind.
• Die Revisionsnummer erhöht sich, falls Änderungen notwendig werden, die die Außenschnittstellen eines Produkttyps nicht beeinflussen, wie beispielsweise Optimierungen in Abläufen, die für die aufrufenden Produkttypen transparent sind. Hier ist eine technische Abwärtskompatibilität immer gegeben.
• Die Co-Revisionsnummer, als Konkretisierung des Suffixes gemäß [GS-A_3695], erhöht sich, falls Änderungen notwendig werden, die die Außenschnittstellen bzw. die technische Umsetzung des betreffenden Produkttyps nicht beeinflussen. Die Co-Revisionsnummer wird von der Revisionsnummer mit einem „-“ getrennt angegeben.

Dabei werden die ersten drei Versionsnummernteile (Haupt-, Neben- und Revisionsnummer) als kompatibilitätsrelevante Anteile der Produkttypversion (kPTV) verstanden, die für die zu jedem Dokumentenrelease veröffentlichte technische Migrationsstrategie maßgeblich sind. Alle vier Versionsnummernteile definieren die Produkttypversion (PTV).

Obwohl die kompatibilitätsrelevante Produkttypversion für eine Kompatibilitätsbetrachtung in der TI verwendet wird, sollen Produkttypen die kompatibilitätsrelevante Produkttypversion anderer Produkttypen technisch nicht für Kompatibilitätsprüfungen heranziehen, da über die kompatibilitätsrelevante Produkttypversion keine Selektion einzelner Schnittstellenversionen erfolgt. Stattdessen sollen für Kompatibilitätsprüfung auf Schnittstellenebene die vorhandenen Versionen von Schnittstellen und Datenstrukturen verwendet werden.

Sofern in anderen technischen Spezifikationen bzw. Artefakten der Begriff Produkttypversion benutzt wird, ist immer die kompatibilitätsrelevante Produkttypversion gemeint. Weiterhin ist die von einem Produkt im Rahmen der Selbstauskunft gemeldete Produkttypversion auf deren kompatibilitätsrelevanten Teil (kPTV) beschränkt.

Als Beispiel sei das eHealth-Kartenterminal genannt, welches eine versionierte Schnittstelle zum Konnektor besitzt, dem Konnektor aber auch die kompatibilitätsrelevante Produkttypversion meldet. Der Konnektor muss die Schnittstellenversion für Kompatibilitätsprüfungen verwenden. Der Konnektor darf die kompatibilitätsrelevante Produkttypversion des eHealth-Kartenterminals hierfür nicht verwenden, da sich diese aufgrund von signifikanten Änderungen außerhalb der Schnittstelle zum Konnektor ändern kann (HW-Änderungen oder Schnittstellen zu anderen Produkttypen).

2.3 Identifikation und Versionierung von Produkten

Die folgenden Vorgaben beziehen sich auf alle Produkte, d.h. konkrete, technische Realisierungen von Produkttypen, die die von der gematik spezifizierten Funktionalitäten eines Produkttypen implementieren und dem Release-, Änderungs- und Konfigurationsmanagement der gematik unterliegen.

Bei der Identifikation von Produkten werden einheitlich für alle Produkte folgende drei Kategorien von Attributen betrachtet:

1. Spezifikationsgrundlage für Produkte
2. Produktidentifikation
3. Zusätzliche Produktattribute

2.3.1 Spezifikationsgrundlage für Produkte

Die von der gematik spezifizierte Grundlage eines Produkttyps wird als Spezifikationsgrundlage für Produkte bezeichnet und ist durch den Produkttyp und die Produkttypversion (alle vier Stellen) eindeutig festgelegt.

2.3.2 Produktidentifikation

Die eindeutige Versionierung von Produkten in der TI findet durch die Produktidentifikation statt, die eine Erweiterung der allgemeinen Versionsnummer aus Kapitel 2.1.2 darstellt.

Personalisierte Karten stellen einen Zusammenschluss unterschiedlicher Zulassungsobjekte dar. Die einzelnen Zulassungsobjekte können durch unterschiedliche Hersteller erzeugt und verantwortet werden. Da für den Betrieb der TI die Kenntnis aller Teile einer Karte relevant sein kann, werden alle Teilelemente einzeln versioniert.

Ein Software-Modul  der TI  ist ein Produkttyp, der rein durch Software realisiert wird und die Nutzung einer Fachanwendung in der dezentralen Umgebung des Anwenders ermöglicht. Er führt die dezentrale Fachlogik der Fachanwendung auf dem Gerät/System des Anwenders aus. Wenn ein Software-Modul  mit anderer Software kombiniert wird, gelten die gematik-Vorgaben nur für die - durch die gematik spezifizierte - Fachlogik der Fachanwendung.

Tabelle 1: Tab_ProdIdentD – Produktidentifikation auf Basis von dezentralen Produkttypen der TI-Plattform ohne Karten

Hierbei ist zu beachten, dass der Firmware-Anteil (kurz FW-Anteil) in der Produktspezifikation immer den gesamten Software-Anteil eines Produktes identifiziert. Es darf keine weiteren Software-Bestandteile (z. B. Bootloader) geben, die außerhalb der FW-Version durch einen Anbieter angepasst werden.

Tabelle 2: Tab_ProdIdentZ – Produktidentifikation auf Basis von zentralen Produkttypen der TI-Plattform, fachanwendungsspezifischen Diensten, Software-Modulen und Karten

Als Darstellungsform der Spezifikationsgrundlage und Produktidentifikation, z. B. an Benutzerschnittstellen, kann folgende Form genutzt werden:

• Spezifikationsgrundlage:
  Produkttyp;Produkttypversion;
• Produktidentifikation:
  Hersteller-/Anbieter-ID;ProduktKürzel;Produktversion
• Spezifikationsgrundlage und Produktidentifikation:
  Produkttyp;Produkttypversion;Hersteller-/Anbieter-ID;ProduktKürzel;Produktversion

Herstellern bzw. Anbietern von Produkten stehen die in Tab_ZusAttr genannten zusätzlichen Produktattribute zur Verfügung. Der Produktname stellt den vollständigen Namen des Produkts dar. Es wird eine Kopplung des Produktkürzels an den Produktnamen empfohlen. Diese Kopplung soll durch eine Namensähnlichkeit, aber nicht zwingend durch eine technische Umsetzung gegeben sein.

Tabelle 3: Tab_ZusAttr – Zusätzliche Produktattribute

2.3.3 Schema für Attribute zur Identifikation von Produkten

Zusammenfassend führt Abbildung 1 anhand des Schemas [ProductInformation.xsd] alle für die Selbstauskunft relevanten (sowohl normativen und auch optionalen) Bestanteile der Produktinformation auf, wie sie bereits durch die Anforderungen GS-A_4975, GS-A_5025 und GS-A_5026 erfasst wurden. Hierbei ist folgende Zuordnung von Bezeichnern zu beachten:

• „Produktkürzel“ → „ProductCode“,
• „Hersteller-/Anbieter-ID“ → „ProductVendorID“ und
• „kompatibilitätsrelevante Produkttypversion“ → „ProductTypeVersion“.

Abbildung 1: Darstellung des Schemas [ProductInformation.xsd] zur Beschreibung der Produktinformation

2.3.4 Herstellerangaben zur Produktversion (Teil der Produktidentifikation)

Zur Produktversion als Bestandteil der Produktidentifikation, welche inhaltlich durch den Hersteller vergeben wird, ist folgendes zu beachten:

Bei Änderung an der 3. oder 4. Stelle eines Produkttypen erfolgt die Änderung der Produktversion in Absprache mit der gematik.

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

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

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

2.4 Selbstauskunft von Produkten

Um während des Entwicklungsprozesses und des Betriebs der TI feststellen zu können, welche Versionen von Produkten für die einzelnen Produktinstanzen aktuell eingesetzt werden, muss es möglich sein, den Versionsstand des Produkts für alle Produktinstanzen zu ermitteln.

Für eine Versionierung einzelner Produktinstanzen kann es spezifische weitere Mechanismen und Attribute geben (z. B. Seriennummer), die nicht Gegenstand dieser Spezifikation sind.

Die Störungsampel verwaltet nur zentrale, aber keine dezentralen Produkttypen.

2.5 Konzept der Firmware-Gruppen für dezentrale Komponenten der TI-Plattform

Dieser Abschnitt beschreibt die Behandlung von Firmware-Gruppen durch die dezentralen Komponenten der TI-Plattform: Konnektor, Kartenterminal und mobiles Kartenterminal. Weitere Komponenten können Firmware-Gruppen nutzen.

In Abbildung 2 ist exemplarisch ein möglicher Ablauf erlaubter Wechsel von Firmware-Versionen und Firmware-Gruppen dargestellt, um das Firmware-Gruppenkonzept zu veranschaulichen.

Abbildung 2: Beispiel für Aktualisierungszyklen und Firmware-Gruppenwechsel

Die Definition und Verwaltung von Firmware-Gruppen sowie die Zuordnung von Firmware-Versionen zu Firmware-Gruppen liegt im Verantwortlichkeitsbereich des Herstellers der Komponente. Der Hersteller hat dabei sicherzustellen, dass die durch ihn definierten Firmware-Gruppen die folgenden Anforderungen erfüllen:

Die Behandlung von Firmware-Gruppen im Konfigurationsdienst wird in der Spezifikation des Konfigurationsdienstes [gemSpec_KSR] beschrieben.

2.6 Versionierung der Karten der TI

In diesem Kapitel werden Vorgaben zur Versionierung der Karten der TI, also für die Produkttypen eGK, HBA, SMC-B, gSMC-KT und gSMC-K, getroffen. Weiterhin ergeben sich Vorgaben für Produkttypen die auf die Karten der TI zugreifen und dazu die Versionsinformationen der Karten auswerten müssen.

Auf den Karten der TI, speziell auf der eGK (z. B. in der Datei DF.HCA - Health Care Applications), können innerhalb einzelner Dateien komplexe Datenstrukturen abgebildet werden. Falls diese Datenstrukturen durch Schreiboperationen auf die Karte (einschl. CMS) im Wirkbetrieb änderbar sind, muss eine zusätzliche Versionierung der einzelnen Datenstrukturen erfolgen und innerhalb der entsprechenden Datei abgelegt werden.

Adressiert wird hier als Umsetzungsanforderung eine getrennte Versionierung u. a. fachlicher Datenstrukturen auf der eGK. Beispielsweise soll die Version der Datei EF.eNotfalldaten auf der eGK über das Element Version in der Datei EF.StatusNotfalldaten erfasst werden. Dazu sind fachdienstspezifisch weitere Festlegungen getroffen im Dokument „Speicherstrukturen der eGK für die TI-Plattform“ [gemSpec_eGK_Fach_TIP]

Der Begriff „Gültigkeitszeiträume“ bezieht sich hier auf die Nutzungszeiträume von Karten in bestimmten Versionen.

3 Fehlerbehandlung

Nach DIN EN ISO 9000:2005 ist ein Fehler gleichzusetzen mit der „Nichterfüllung einer festgelegten Forderung“ [DIN EN ISO 9000]. Das bedeutet, ein Fehler bezeichnet die Abweichung von einem erwarteten Zustand oder Prozess.

Für aufgetretene und erkannte Fehler müssen in Rahmen der Fehlerbehandlung Fehlermeldungen an aufrufenden Produkttypen bzw. an den Systemgrenzen der TI auch an Systeme außerhalb der TI (z. B. Clientsysteme) gemeldet werden.

Dieses Kapitel definiert übergreifende Vorgaben zur Fehlerbehandlung innerhalb der TI sowie an der Grenze zu Clientsystemen für folgende zwei Themenbereiche:

• Allgemeine technologieunabhängige Vorgaben zur Fehlerbehandlung für Produkttypen
• Vorgaben zur Fehlerbehandlung für Produkttypen die mittels Webservices miteinander kommunizieren. Hierzu werden einheitliche Strukturen und Inhalte definiert.

3.1 Allgemeine Festlegungen

Lokale Fehlerbehandlung bezeichnet die Aktivitäten, die durch die den Fehler auslösende Produktinstanz auszuführen sind. Im übergeordneten Sinne kann anstelle eines Fehlerfalls auch von einem Ausnahmefall die Rede sein, wenn beispielsweise eine beabsichtigte und bekannte Abweichung vom erwarteten Zustand eintritt (bspw. im Testfall oder in der Migration).

Wenn es sich um einen echten Fehlerfall (d. h. unerwartete und unbeabsichtigte Abweichung) handelt, so soll die Ursache so weit und so konkret wie möglich in die Fehlermeldung selbst aufgenommen werden. Ist die Ursache nicht sofort erkenntlich, so soll eine generische Fehlermeldung gewählt werden, die das Problem so hinreichend wie möglich benennt. Konkrete Vorgaben hierzu legen die nachfolgenden Anforderungen fest. Wenn es sich dagegen um einen Ausnahmefall handelt, so soll in dessen Vorbereitung auch eine passende Ursachenbezeichnung festgelegt werden.

Alle Fehlermeldungen sollten grundsätzlich maschinell verarbeitbar sein. Daher ist die Struktur der gematik-Fehlermeldung fest vorgegeben (siehe Abbildung 3). Eine Ausnahme ist in dieser Struktur das Feld „Details“ (welches fehlerabhängige Zusatzinformationen transportiert). Dieses Feld ist nicht dafür vorgesehen, eine automatisierte Auswertung zu ermöglichen. Da die Verarbeitung der Fehler sehr stark von der Plattform und der Implementierung abhängig ist, erfolgen in diesem Kapitel lediglich allgemeingültige Vorgaben, die in den nachfolgenden Spezifikationen kontextabhängig differenziert werden.

Eine ausgegebene Fehlermeldung sollte natürlich für den Anwender direkt verständlich sein. Wer aber dieser Anwender ist (bspw. Administrator oder medizinische Fachkraft) und was in seiner Situation die Kriterien für Verständlichkeit sind, muss jeweils in den nachfolgenden Spezifikationen festgelegt werden.

Auch in dem Fall, dass eine Komponente in der Lage ist, einen Fehler selbst zu beheben, muss dieser Zwischenfall als „Warning“ weitergegeben werden, da durch die Fehlerbehebung Seiteneffekte auftreten könnten, die nicht die Komponente selbst, aber ihr Umfeld beeinflussen.

Remote-Fehlerbehandlung bezeichnet die Aktivitäten, die durch eine Fehler weiterleitende Produktinstanz auszuführen sind.

3.2 Fehlerbehandlung

3.2.1 Struktur der Fehlermeldungen

Abbildung 3: Abb_XML_Struktur_Fehler XML-Struktur der gematik Fehlermeldung [TelematikError.xsd], Version 2.0

Tabelle 7: Tab_Attribute_Fehler-01 – Attribute der gematik-Fehlermeldung

Tabelle 8: Tab_ErrorType – Definition ErrorType

Tabelle 9: Tab_Severity_Codes – Severity Codes

An dieser Stelle sei darauf hingewiesen, dass sowohl „Fatal“ als auch „Error“ einen Fehler bezeichnen, der zum Abbruch der Verarbeitung führt, aber jede Spezifikation diese Unterscheidung nutzen kann, um in ihrem Bereich eine Abgrenzung der Kritikalität zu erreichen.

3.2.2 Fehlermeldungen

Eine Vorgabe zur Befüllung des Feldes „Details“ soll in der Spezifikation erfolgen, die diese generische Fehlermeldung verwendet.

Tabelle 10: Tab_Gen_Fehler – Generische Fehlermeldungen

An dieser Stelle werden einige beispielhafte Ausprägungen eines Protokollfehlers (Code „6“) aufgeführt.

Tabelle 11: Beispiele für "Protokollfehler"

3.2.3 Transport der Fehlermeldungen

Alle Webservices-Fehlermeldungen werden auf Transportebene als gematik-SOAP-Fault übertragen. Bei einem gematik-SOAP-Fault handelt es sich um eine Erweiterung des Standard-SOAP-Faults. Die Struktur des SOAP-Faults unterscheidet sich je nach eingesetzter SOAP-Version.

3.2.3.1 Transport der Fehlermeldungen über SOAP 1.1

Wenn SOAP 1.1 [SOAP1.1] eingesetzt wird, gelten folgende Festlegungen:

Bei einem gematik-SOAP-Fault handelt es sich um eine Erweiterung des SOAP-Faults gemäß [SOAP1.1] und [BasicProfile1.2] (siehe auch Abb_SOAP_Fault).

Abbildung 4: Abb_SOAP_Fault - Darstellung eines SOAP-Faults

3.2.3.2 Transport der Fehlermeldungen über SOAP 1.2

Wenn SOAP 1.2 [SOAP1.2] eingesetzt wird, gelten folgende Festlegungen:

Bei einem gematik-SOAP-Fault handelt es sich um eine Erweiterung des SOAP-Faults gemäß [SOAP1.2] und [BasicProfile2.0] (siehe auch Abb_SOAP_Fault_12).

Abbildung 5: Abb_SOAP_Fault_12 - Darstellung eines SOAP-Faults 1.2

3.3 Datenschutz und Sicherheitsrelevante Fehlermeldungen

Sowohl Entwicklung, als auch Betrieb eines Produkts in der TI müssen in Abstimmung mit den sicherheitsspezifischen Konzepten und Schutzprofilen erfolgen. Daher sind die in [gemSpec_OM] festgelegten Anforderungen nur eine Teilmenge der von Herstellern und Anbietern zu beachtenden Datenschutz- und Sicherheitsanforderungen.

3.3.1 Datenschutzvorgaben für Fehlermeldungen

3.3.2 Sicherheitsrelevante Fehlermeldungen

4 Logging

4.1 Einführung

Logging kann zu verschiedenen Aufgaben eingesetzt und zur der Erfassung weiterer Ereignisse ausgeweitet werden, die in den Abschnitten 4.2.2 – 4.2.5 beispielhaft aufgeführt sind. Wieweit diese für einen Produkttyp verpflichtend sind, wird in der jeweiligen Spezifikation des Produkttypen verpflichtend festgelegt. Normativ verpflichtend für alle sind jedoch die folgenden Anforderungen zum Logging zur Fehlerbehandlung.

4.2 Grundlagen zum Logging

Grundsätzlich werden zu Analysezwecken in der TI (z. B. für eine Fehleranalyse) detaillierte Logging-Informationen benötigt. Diese Inhalte sowie die Form der Speicherung sind implementierungsabhängig und werden nicht in dieser Spezifikation festgelegt. Es werden jedoch grundlegende Anforderungen an die Informationsbereitstellung gestellt.

Folgende Log-Typen werden betrachtet:

• EventLog
• SecurityLog
• Ablaufprotokoll
• PerformanceLog
• DebugLog

Unabhängig davon ist zu gewährleistet:

• Dezentrales Logging auf der eGK selbst

Berechtigungen zum Zugriff auf Log-Dateien werden für die Test- und Referenzumgebung übergreifend in Kapitel 4.3 geregelt. Berechtigungen im regulären Wirkbetrieb sind dagegen in den einzelnen Spezifikationen festzulegen.

4.2.1 FehlerLog

Die Art und Weise der persistenten Ablage der Fehlerdetails zu Fehlermeldungen wird innerhalb der TI als FehlerLog bezeichnet. Die Grundlage für den Zusammenhang zwischen Fehlmeldungen und Einträgen im FehlerLog wurde bereits in Kapitel 3.2.1 über die Attribute der gematik Fehlermeldung getroffen (Tab_Attribute_Fehler). Das Element „LogReferenz“ einer Fehlermeldung dient zur Lokalisierung des verwendeten FehlerLog-Eintrags. Durch der Elemente „LogReference“ und „Instance“ einer Fehlermeldung ist eine TI-weite eindeutige Referenzierung eines zugehörigen FehlerLog- Eintrags möglich.

Remote-Fehler wurden bereits im Rahmen der Remote-Fehlerbehandlung eingeführt (siehe Kapitel 3.1) und sind damit eine übergreifende Bezeichnung und unabhängig vom gewählten (spezifischen) Fehlerprotokoll.

Im Rahmen einer ereignisgesteuerten Nachrichtenverarbeitung können keine Fehlermeldungen an aufrufende Produkttypen bzw. Systeme erfolgen.

Die Granularität der FehlerLog-Einträge für einen Produkttyp wird nicht vorgegeben und kann durch den Anbieter bzw. Hersteller des Produkttyps frei gewählt werden. Dabei gilt die Regel, je höher der Loglevel ist, desto höher ist die Detailtiefe der Protokollierung. Es gibt seitens der gematik ein Testkonzept [gemKPT_Test] dessen Berührungspunkte zu [gemSpec_OM] gebündelt sind im Kapitel 4.3 Logging in Test und Referenzumgebung. Davon unabhängig können für die gegebenen Loglevel im Testbetrieb weitere Festlegungen getroffen werden.

4.2.2 SecurityLog (System- und Sicherheitsprotokoll)

4.2.3 Ablaufprotokoll

4.2.4 PerformanceLog

4.2.5 DebugLog

Im Testbetrieb kann ein DebugLog implementiert werden, der ggf. auch interne Abläufe im Produkttyp ausgibt.

4.2.6 Weitere Protokollierung auf der eGK

Aufgrund der rechtlichen Festlegung müssen alle mit der eGK ausgeführten Ereignisse auf dieser protokolliert werden. Aktuelle Festlegung ist, dass zumindest die letzten 50 Zugriffe mit der eGK auf dieser protokolliert werden – unabhängig davon, ob ein Zugriff erfolgreich war.

4.3 Logging in Produktiv-, Referenz- und Testumgebung

Es ist zu unterscheiden zwischen der Arbeit in der Test-/Referenz-Umgebung, sowie der Arbeit in der Umgebung im Produktivbetrieb selbst. Im Produktivbetrieb müssen strenge Datenschutzvorgaben beachtet werden, wonach keinesfalls medizinische oder personenabhängige Daten geloggt werden dürfen. In der Test- oder Referenzumgebung kann in stark überwachten Ausnahmefällen zur Fehleranalyse nahezu alles geloggt werden. Es muss allerdings sichergestellt werden, dass bei dem Übergang von Test-/Referenzumgebung zum Produktivbetrieb keine datenschutzkritischen Ausnahmen mehr zulässig sind.

Die Festlegung wie „autorisierte Personen“ zu benennen sind, kann nicht übergreifend für alle Komponenten gleich gehandhabt werden und ist daher wie folgt festgelegt:

• Zentrale Produkttypen der TI-Plattform und fachanwendungsspezifische Dienste decken dies implizit durch die Zuweisung von Betriebsrollen ab,
• Dezentrale Produkttypen der TI-Plattform legen dies in der Spezifikation fest (bspw. [gemSpec_Kon] oder [gemSpec_KT])
• Sonstige Komponenten klären dies über den Testverantwortlichen, die den Test koordinierende Instanz und die den Test durchführende Instanz.

Die Festlegung wie diese Sperrung sicherzustellen ist, kann nicht übergreifend für alle Komponenten gleich gehandhabt werden und ist daher wie folgt festgelegt:

• Zentrale Produkttypen der TI-Plattform und fachanwendungsspezifische Dienste gewährleisten dies organisatorisch
• Dezentrale Produkttypen der TI-Plattform legen dies in ihrer Spezifikation fest.

5 Betriebsdokumentation

In den vorhergehenden Kapiteln wurden durchgehend technische Aussagen zur Identifikation (Kapitel 2 Versionierung), zum Umgang mit Ausnahmefällen (Kapitel 3 Fehlerbehandlung) und zur Nachvollziehbarkeit (Kapitel 4 Logging) getroffen. Die Dokumentation aus Nutzersicht der organisatorischen und betrieblichen Gesichtspunkte (kurz Betriebsdokumentation) wird in diesem Kapitel festgelegt.

Die Betriebsdokumentation hat das Ziel, dem Nutzer (d.h. Betreiber, Anbieter und Anwender) den betrieblichen Umgang mit einem Produkt zu ermöglichen. Dies ist vor allem notwendig, wenn eine nicht in die Herstellung involvierte Partei das Produkt betreibt. Dies wird voraussichtlich vor allem bei dezentralen Produkten der TI-Plattform der Fall sein.

Die Erstellung einer Betriebsdokumentation für Produkte im Sinne von [gemSpec_OM] muss neben Anteilen für den Betreiber des Produktes auch die notwendigen Anteile für den Anwender des Produktes beinhalten, wie z. B. Schnittstellen und betriebliche Abhängigkeiten. Die folgende Anforderung gibt die Mindestanforderungen an die nutzerorientierte Betriebsdokumentation der Produkte vor.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

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

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.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 passende jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

6.5.2 Weitere Referenzierungen

6.5.3 Schemadateien aus [gemSpec_OM]

7 Anhang B – Versionierung durch die gematik (informativ)

Dieses Kapitel stellt dar, wie die gematik-Schnittstellen und Datenstrukturen der TI strukturiert versioniert.

7.1 Versionierung von Schemadefinitionsdateien

Nachfolgend behandelt wird die Versionierung von XML-Schemadefinitionsdateien (XSD-Dateien), die von der gematik spezifiziert werden. Diese werden sowohl zur Nachrichtendefinition in WSDL-Dateien verwendet als auch zur Spezifikation weiterer schnittstellenunabhängiger Datenstrukturen. Erstere werden im Folgenden als schnittstellenspezifische XSD-Dateien, letztere als datenstrukturspezifische XSD-Dateien bezeichnet.

Es werden im Weiteren folgende Versionsnummern unterschieden:

• Die Schemaversion dient der Kennzeichnung aller Änderungen in XSD-Dateien.
• Zur Kennzeichnung von Änderungen am Schema innerhalb des Namensraums wird die Namespace-Version verwendet.
• Mit der logischen Version werden Änderungen an der Bedeutung von Struktur und Inhalten in Datenstrukturen nachvollziehbar.

Die Festlegungen der zu verwendenden Versionsnummern in XSD-Dateien sind für diese betrachteten drei Gruppen unterschiedlich, daher werden diese getrennt betrachtet.

7.1.1 Versionierung Webservice-Schnittstellen

WSDL-Dateien werden für die Definition von Webservice-Schnittstellen verwendet. Eine Versionierung der Dateien ist erforderlich, da sich Schnittstellen und Nachrichtenformate ändern können. Generell kann man bei der Versionierung von Schnittstellen bei Webservices folgende Fälle unterscheiden:

• Nachrichtenversionierung: Versionierung der Schemata, die für die Definition von Nachrichten verwendet werden. Dazu gehören die Änderung und Erweiterung existierender sowie die Definition weiterer Nachrichtentypen.
• Kontraktversionierung: Versionierung der WSDL- und Kontraktinformationen, die einen Dienst beschreiben.

7.1.2 WSDL-Version

Jede von der gematik spezifizierte WSDL-Datei hat eine eindeutige Versionsnummer, die WSDL-Version. Sie wird von der gematik definiert, die Versionsnummer muss das Format gemäß Anforderung [GS-A_3695] haben. Die Bestandteile haben folgende Bedeutung:

• Die Hauptversionsnummer erhöht sich, falls aus Sicht des Aufrufenden der Schnittstelle signifikante Änderungen an der Schnittstelle vorgenommen wurden.
• Die Nebenversionsnummer erhöht sich, falls aus Sicht des Aufrufenden der Schnittstelle moderate Anpassungen an der Schnittstelle vorgenommen wurden.
• Die Revisionsnummer erhöht sich, falls Änderungen vorgenommen werden, die keine Schnittstellenänderungen zur Folge haben.

Jede WSDL-Datei muss einzeln für sich versioniert werden. Dabei muss die Festlegung eingehalten werden, dass die Haupt- und Nebenversionsnummern einer WSDL-Datei immer identisch mit den Haupt- und Nebenversionsnummern der importierten schnittstellenspezifischen XSD-Datei ist, da nur beide Dateien zusammen als Spezifikation der Schnittstelle angesehen werden.

Die Version muss in der WSDL-Datei unterhalb des „wsdl:definitions“-Knotens im Element „wsdl:documentation“ in der Form „version=<Versionsnummer>“ abgelegt werden. Der Eintrag muss als Substring des Textknotens genau einmal vorhanden sein.

Im Folgenden ist ein beispielhafter Auszug aus einer WSDL-Datei dargestellt:

<wsdl:definitions ...>

<wsdl:documentation>

...

version=1.1.3

</wsdl:documentation>

...

</wsdl:definitions>

7.1.3 Namespace-Version

Alle von der gematik definierten WSDL-Dateien müssen im definitions-Knoten einen Zielnamensraum (TargetNamespace) definieren, in dem eine zweistellige Versionskennung steht. Der Zielnamensraum der WSDL-Datei muss identisch mit dem Zielnamensraum der importierten XSD-Datei sein, damit sind auch die jeweiligen Versionsnummern identisch. Die Angabe der Versionsnummer erfolgt nur mit zwei Stellen:

• Die Hauptversionsnummer muss identisch mit der Hauptversionsnummer der WSDL-Datei sein.
• Die Nebenversionsnummer muss identisch mit der Nebenversionsnummer der WSDL-Datei sein.

7.1.4 Allgemeine Festlegungen Versionierung Schema XSD-Dateien

Dieser Abschnitt enthält allgemeine Festlegungen, die für alle XSD-Dateien Gültigkeit haben. Weitere Festlegungen, die von der Kategorie der XSD-Datei abhängen, befinden sich in den nachfolgenden Abschnitten. Jede von der gematik spezifizierte XSD-Datei hat eine von der gematik festgelegte eindeutige Versionsnummer, die Schemaversion. Die Schemaversion muss das in Abschnitt „WSDL-Version“ festgelegte Format haben. Zusätzlich gilt: Jede XSD-Datei muss einzeln versioniert werden. Die Version muss im Attribut „version“ des „xs:schema“-Knotens in der XSD-Datei abgelegt werden.

Im Folgenden ist ein beispielhafter Auszug aus einer XSD-Datei dargestellt:

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema

elementFormDefault="qualified" attributeFormDefault="unqualified"

version="1.3.2">

...

</xs:schema>

7.1.5 Versionierung schnittstellenspezifischer XSD-Dateien

Bei schnittstellenspezifischen XSD-Dateien muss die Haupt- und Nebenversionsnummer der Schemaversion immer identisch mit der Haupt- und Nebenversionsnummer der WSDL-Datei sein, welche die XSD-Datei importiert. Zur Kennzeichnung von Schema- bzw. Schnittstellenänderungen muss der Namensraum der XSD-Datei versioniert werden. Die im Zielnamensraum einer schnittstellenspezifischen Schemadefinitionsdatei vorhandene Haupt- und Nebenversionsnummer muss dabei identisch sein mit der Haupt- und Nebenversionsnummer des Zielnamensraums der WSDL, die diese Schemadefinitionsdatei importiert.

7.1.6 Versionierung datenstrukturspezifischer XSD-Dateien

Für alle datenstrukturspezifischen XSD-Dateien müssen die Bestandteile der Schemaversion folgende Bedeutung haben:

• Die Hauptversionsnummer erhöht sich, falls signifikante Änderungen an der XSD-Datei vorgenommen werden.
• Die Nebenversionsnummer erhöht sich, falls moderate Änderungen an der XSD-Datei vorgenommen werden.
• Die Revisionsnummer erhöht sich, wenn die vorgenommenen Änderungen für die Schemavalidierung und die Verarbeitung des Inhalts irrelevant sind.

Versionierung inhaltlicher Änderungen in datenstrukturspezifischen XSD-Dateien

Zur Kennzeichnung von Änderungen (in der Bedeutung fachlicher Inhalte) in Datenstrukturen muss eine entsprechende inhaltliche Versionierung erfolgen, die im Folgenden als logische Version bezeichnet wird. (Erläuterung: Diese Änderungen umfassen sowohl strukturelle Änderungen als auch Änderungen in der Interpretation der Inhalte, die nicht notwendigerweise zu Änderungen von XSD-Dateien führen müssen.)

Die Bestandteile der logischen Version müssen folgende Bedeutung haben:

• Die Hauptversionsnummer erhöht sich, falls sich die Hauptversionsnummer der Schemaversion geändert hat oder falls Änderungen an der Bedeutung einzelner oder mehrerer Datenfelder vorgenommen werden, die bei der Interpretation der Inhalte eine geänderte Verarbeitung erfordern. Dies ist insbesondere bei Veränderungen an Werten von kodierten Einträgen zu berücksichtigen, wenn sich die zu Grunde liegende Tabelle und damit die Inhalte der Tabelle ändern.
• Die Nebenversionsnummer erhöht sich, falls sich die Nebenversionsnummer der Schemaversion geändert hat oder falls Änderungen an der Bedeutung derart vorgenommen werden, dass keine veränderte Verarbeitung erforderlich ist, z. B. bei Einschränkungen eines Wertebereichs eines Datenfeldes, der nicht mehr benutzt wird.
• Die Revisionsnummer erhöht sich, wenn die vorgenommenen Änderungen für die Verarbeitung des Inhalts irrelevant sind, z. B. wenn die Bedeutung eines Feldes näher präzisiert wird durch Kommentare in der Schemadatei, ohne das sich die Bedeutung grundlegend ändert.

Zu jeder logischen Version muss es eine eindeutige korrespondierende Schemaversion geben. Eine Abbildung von logischen Versionen zu Schemaversionen wird von der gematik bereitgestellt. Daher kann für jedes datenstrukturspezifische XML-Instanzdokument die Version des zugehörigen Schemas, etwa zu Validierungszwecken, ermittelt werden. Wenn mehrere fachliche Datenstrukturen in einer übergeordneten Datenstruktur zusammengefasst werden, müssen alle die gleiche logische Version haben: Die übergeordnete Struktur sowie die einzelnen Bestandteile.

7.2 Versionierung von Schnittstellen und Diensten

Dieses Unterkapitel geht auf die Versionskennungen für die Versionierung der Konnektor- und Fachdienstschnittstellen ein. Die Betrachtung schließt neben Schnittstellenänderungen auch Änderungen im Verhalten der Dienste ein.

7.2.1 Versionierung der Konnektordienstschnittstellen

Die Versionierung der Konnektordienste erfolgt über den Dienstverzeichnisdienst des Konnektors (siehe [gemSpec_Kon]). Er ermöglicht die Versionierung der für die Primärsysteme zur Verfügung gestellten Dienste, d. h. der Basis- und Fachanwendungen. Jeder Dienst kann in unterschiedlichen Versionen und mit unterschiedlichen Endpunkten bereitgestellt werden. Die Versionskennung eines Dienstes wird als Konnektordienstversion bezeichnet.

Bei der Verwendung von Fachmodulschnittstellen bezieht sich ein Primärsystem immer auf eine bestimmte Spezifikation einer Fachanwendung oder Spezifikation, in der die Schnittstelle und das Verhalten der Anwendung festgelegt werden. Eine Konnektordienstversion muss sich immer dann ändern, wenn unterschiedliche Versionen von Diensten für das Primärsystem unterscheidbar sein müssen. Für die Basisanwendungen des Konnektors in [gemSpec_Kon] muss die Konnektordienstversion das Format gemäß Anforderung [GS-A_3695] haben. Weiterhin muss die Erhöhung von Versionsnummern der Anforderung [GS-A_3697] folgen.

Durch die gematik muss für die Konnektordienstversion folgende Bedeutung der Versionsnummer umgesetzt werden:

• Die Hauptversionsnummer erhöht sich, falls sich die Hauptversionsnummer des Zielnamensraums der zur Schnittstelle der Basisanwendung gehörenden WSDL ändert.
• Die Nebenversionsnummer erhöht sich, falls sich die Nebenversionsnummer des Zielnamensraums der zur Schnittstelle der Basisanwendung gehörenden WSDL ändert.
• Die Revisionsnummer erhöht sich, falls an der Basisanwendung nur Änderungen vorgenommen werden, die keine Schnittstellenänderung zur Folge haben. Das wird im Allgemeinen dann der Fall sein, wenn das Verhalten des Dienstes versioniert werden soll.