Einführung der Gesundheitskarte Spezifikation Fehlerbehandlung

Transkript

1 Einführung der Gesundheitskarte Spezifikation Version: Stand: Status: freigegeben gematik_ga_spezifikation V1_3_0.doc Seite 1 von 50

2 Dokumentinformationen Änderungen zur Vorversion Eine Liste der generischen Fehler wurde eingeführt. Datentypen oder Befüllung in der Error Struktur wurden verändert (timestamp, severity, componenttype, errortype). Die Transportwege der Fehlermeldung wurden präzisiert. Ein Template zur Beschreibung der Fehlermeldungen in Spezifikationen und Facharchitekturen wurde eingefügt. Der Transport und die generelle Behandlung sicherheitsrelevanter Fehlermeldungen wurden präzisiert. Die Ausgangsanforderungen wurden in separater Tabelle aufgeführt (Anhang G). Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel eingefügt oder grundlegend überarbeitet wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gemspec FM] gematik ( ): Einführung der Gesundheitskarte - Spezifikation Version Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung bis Neuerstellung gematik, AG Einarbeitung von Review-Kommentaren Erweiterung um Alertmanagement gematik, AG Weiterführung gematik, AG Interne AG1 Kommentierung eingearbeitet gematik, AG Formale Korrekturen gematik, IQS zur Freigabe vorgelegt gematik freigegeben gematik gematik_ga_spezifikation V1_3_0.doc Seite 2 von 50

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Ticketdienst eingefügt gematik, AG Einarbeitung offener Punkte, Präzisierungen gematik Version für Review gematik formelle Überarbeitung QM Einarbeitung Reviewkommentare ITS/AP freigegeben gematik gematik_ga_spezifikation V1_3_0.doc Seite 3 von 50

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Zielgruppe Geltungsbereich Abgrenzung des Dokuments Methodik Verwendung von Schüsselworten Anforderungen Einleitung Fachliche Anforderungen Übersicht Einführung Mögliche Fehlerfälle (exemplarisch) Abläufe Übersicht Fehlerkontext Lokale Bereitstellung von Mechanismen zur Fehlererkennung Speicherung von Fehlerdetails und Erzeugung einer Fehlermeldung Verarbeitungsabbruch bei synchroner Nachrichtenverarbeitung Verwendung von Fehlerqueues für asynchrone Aufrufe Verarbeitungsabbruch bei Ereignis getriggerter Nachrichtenverarbeitung Rückgabe der Fehlermeldung an das aufrufende System Verwendung von Retry-Mechanismen Protokollierung der Fehler verursachenden Nachricht Transport von Fehlermeldungen Fehler auf Transportprotokollebene Umsetzung von Fehlermeldungen in eine für Endanwender verständliche Form Fehlertexte für das Primärsystem Fachliche Service-Aufrufe Nicht-fachliche Service-Aufrufe gematik_ga_spezifikation V1_3_0.doc Seite 4 von 50

5 6 Informationsmodell der Fehlermeldung Fehlercodes Verwaltung von Fehlercodes Lokale Fehlerdetails Details zum Transport von Fehlern in der Telematikinfrastruktur Transport als gematik Payload Fehlermeldung Transport als gematik SOAP Fault Transport der Fehlermeldung vom Konnektor zum Primärsystem Fehlerverfolgung Datenstruktur der gematik-fehlermeldung Betrachtung zur Datensicherheit Sicherheitsrelevante Fehlermeldungen Anhang A - Komponenten Typ...37 Anhang B - Severity Codes...38 Anhang C - Error Typen...39 Anhang D - Fehlerdetails...40 Anhang E Allgemeiner Fehlercode...42 Anhang F Error-Schema...45 Anhang G Ausgangsanforderungen...46 Anhang H...48 H1 Abkürzungen H2 Glossar H3 Abbildungsverzeichnis H4 Tabellenverzeichnis H5 Referenzierte Dokumente H6 Klärungsbedarf gematik_ga_spezifikation V1_3_0.doc Seite 5 von 50

6 1 Zusammenfassung Die Telematikinfrastruktur (TI) wird als verteiltes System, d. h. als Zusammenschluss unabhängiger Services, implementiert. Die Kombination dieser Services bildet die funktionalen Anforderungen an die TI ab. Zur Laufzeit besteht sie aus einer Menge interagierender Infrastruktur- und Fachdienste, die über keinen gemeinsamen Datenspeicher verfügen und daher über http(s) basierte SOAP-Aufrufe kommunizieren. Die zugrunde liegende Architektur der TI wird in [gemgesarch] definiert. Zur Laufzeit kann es aus verschiedensten Gründen zu Ausnahmefällen (Fehlern) und sicherheitsrelevanten Ereignissen kommen. Sicherheitsrelevante Ereignisse müssen von einem Alertmanagement erkannt werden können, Ausnahmefälle müssen protokolliert werden, wobei die zugrunde liegenden Ursachen lokalisierbar und analysierbar sein müssen. Zusätzlich muss, sofern die Ausnahmebehandlung eine für den Endanwender sichtbare Auswirkung hat, eine Meldung an diesen erfolgen. Die Kombination von Ausnahmefällen und sicherheitsrelevanten Ereignissen ist ebenfalls möglich und zwar dann, wenn es sich bei einem Ausnahmefall um einen sicherheitsrelevanten Ausnahmefall handelt, wie dies zum Beispiel bei einer ungültigen Nachrichtensignatur der Fall wäre. Die Möglichkeit für die Erkennung, Erzeugung, den Transport und die Auswertung von Fehlern und sicherheitsrelevanten Ereignissen werden für die TI übergreifend spezifiziert. Die Festlegung der hierzu notwendigen Strukturen und Informationsmodelle ist Bestandteil der Spezifikation. Eine detaillierte Spezifikation eines betreiberinternen Systemmanagements erfolgt nicht, es werden lediglich Anforderungen an dieses spezifiziert. Nachfolgend werden kritische Fehler und sicherheitsrelevante Ereignisse als Fehler beschrieben. Soweit nicht unbedingt nötig, erfolgt keine Unterscheidung. gematik_ga_spezifikation V1_3_0.doc Seite 6 von 50

7 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Dieses Dokument beschreibt das Format und den Transport von kritischen Fehlermeldungen. Kritisch bezeichnet hier Fehler, die Gegenstand einer komponentenbezogenen Protokollierung zum Zwecke der späteren Auswertung sind. Die Definition, welcher Fehler als kritisch im Sinne der Definition zu betrachten ist, erfolgt durch die einzelnen Komponenten. Kriterien können hier zum Beispiel Auswirkungen auf die Service-Qualität oder die Verletzung bestimmter definierter Schwellwerte sein. Zusätzlich müssen diese Fehler der Art sein, dass sie als Fehlermeldung letztendlich einem Endnutzer zugeführt werden müssen. Endnutzer sind hier sowohl Anwender von Primärsystemen als auch Anwender von Systemüberwachungskomponenten. Ausdrücklich nicht betroffen sind Fehler, die nicht außerhalb der Komponente bekannt sein müssen, sowie Tracing-Informationen oder Warnungen, die innerhalb einer Komponente auftreten und vornehmlich dem Verfolgen des normalen Ablaufes dienen. 2.2 Zielgruppe Das Dokument richtet sich an Entwickler der Komponenten und Dienste sowohl innerhalb als auch außerhalb der gematik. Interne Zielgruppen Innerhalb der gematik sind folgende Aufgabenbereiche identifiziert, für welche Festlegungen getroffen werden: Facharchitekturen: Das Dokument definiert die Grundlage des Fehlermanagements. Es ist Aufgabe der Facharchitekturen und anderer Schnittstellen beschreibender Dokumente, für jeden Fachdienst und jede Schnittstelle Fehlertabellen gemäß Anhang zur Verfügung zu stellen. Diese Fehlertabellen müssen alle möglichen Fehler inklusive ihrer fachlichen Auswirkung in Form einer Fehlermeldung definieren. Dezentrale Komponenten: Das Dokument definiert den Transport von Fehlercodes aus der Telematikinfrastruktur zu den Primärsystemen. Betrieb: Das Dokument bildet die Grundlage für den Aufbau übergreifender Mechanismen zum Monitoring und zur Fehlerverfolgung für Softwarekomponenten, die unter Verwendung von SOAP-Nachrichten kommunizieren. Durch den Betrieb ist die Vergabe von eindeutigen Identitätsmerkmalen für Instanzen (z. B. Instanznummern) vorzusehen, die dem Betreiber einer Instanz mitzuteilen sind, und die für die eindeutige Lokalisierung eines Fehlers verwendet werden. Detailspezifikationen für Anwendungsinfrastrukturdienste: Die Detailspezifikationen für Anwendungsinfrastrukturdienste müssen die Erzeugung, gematik_ga_spezifikation V1_3_0.doc Seite 7 von 50

8 den Transport und die Bereitstellung von Fehlerschlüsseln (siehe Tabelle 15: Template Fehler Tabelle) umsetzen. Test: Die Umsetzung des Fehlermanagements durch Telematikinfrastruktur- Komponenten muss durch den Bereich Test überprüft werden. Datenschutz und -sicherheit: Das Dokument bildet die Grundlage für die Abstimmung und Definition der Datenschutzanforderungen zum Fehlermanagement. Externe Zielgruppen Darüber hinaus informiert das Dokument die Beteiligten der Einführung der Gesundheitskarte über die. Dieses Dokument wird in den Arbeitsergebnissen der internen Zielgruppen verwendet werden und in diesem Sinne auch für alle Interessenten an deren Arbeitsergebnissen von Interesse sein. Eine Auflistung dieser Zielgruppen erfolgt hier nicht, vor allem angesprochen sind hier Hersteller und Betreiber von Komponenten. 2.3 Geltungsbereich Das Dokument entsteht im Rahmen der Arbeiten der gematik zur Umsetzung der Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte [RVO2006] in der Bundesrepublik Deutschland. Die spezifizierten Inhalte gelten für die Abschnitte 1 bis 3, entsprechend Release 1 (Offline) und Release 2 (Online). 2.4 Abgrenzung des Dokuments Die Aufgabe der Spezifikation ist die Definition eines TI-übergreifenden Konzeptes zum Format und zum Transport von Fehlerinformationen. Zur Analyse eines Fehlers durch einen Administrator oder Entwickler werden detaillierte Logging- und Tracing-Informationen benötigt. Diese benötigten Informationen sowie die effizienteste Form der Speicherung sind implementierungsabhängig und werden nicht durch die gematik spezifiziert. Es werden jedoch grundlegende Anforderungen an die Informationsbereitstellung und Auffindung von Fehlerdetails gestellt. Diese werden unter anderem in diesem Dokument beschrieben. Die Berechnung und Überwachung von Service Level Agreements (SLAs) erfolgt nicht über die Anzahl fehlgeschlagener Nachrichten und ist daher nicht Bestandteil des Dokuments. Das vorliegende Dokument betrachtet die ausschließlich für Software- Komponenten, die durch Zuhilfenahmen von SOAP über http(s), also Webservices, miteinander kommunizieren. Die Betrachtung des Fehlertransportes von Hardware- Komponenten oder Komponenten, die über andere Kommunikationsprotokolle kommunizieren, erfolgt nicht. Das Dokument definiert nicht, wie Fehlermeldungen technisch gesehen abgelegt werden. Dies obliegt den jeweiligen Herstellern der entsprechenden Komponenten. gematik_ga_spezifikation V1_3_0.doc Seite 8 von 50

9 Des Weiteren ist es nicht Aufgabe dieses Dokumentes, mögliche konkrete Fehlermeldungen zu definieren. Dabei bilden die Vorgaben dieses Dokumentes den Rahmen bezüglich der Formate der Fehlerinformationen, der möglichen Transportwege der Fehler und der festzulegenden Meta-Informationen. Grundsätzlich obliegt es den einzelnen Komponenten, in welcher Granularität sie Fehler weiterleiten und wie sie die einzelnen Fehler klassifizieren. Dieses Dokument liefert dazu Entscheidungshilfen. 2.5 Methodik Das Dokument führt zunächst die Anforderungen an eine auf. Darauf aufbauend werden Festlegungen zur Einbettung der in die Gesamtarchitektur der Telematikinfrastruktur beschrieben Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. gematik_ga_spezifikation V1_3_0.doc Seite 9 von 50

10 3 Anforderungen 3.1 Einleitung Nach DIN EN ISO 8402, , Ziffer 2.10 ist ein Fehler gleichzusetzen mit der Nichterfüllung einer festgelegten Forderung. Das bedeutet, ein Fehler bezeichnet die Abweichung von einem erwarteten Zustand oder Prozess. Im Allgemeinen wird davon ausgegangen, dass die hier betrachteten Fehler zu einem Abbruch der Durchführung des Verarbeitungsprozesses oder zum Wechseln in einen Fehlerzweig der Durchführung führen können. Alle hier betrachteten Fehler müssen eine Information an einen Nutzer innerhalb (z. B. Fehlermanagement) oder außerhalb (z. B. Primärsystem Nutzer) der Telematikinfrastruktur erfordern. Das heißt Fehler, die nicht diese Eigenschaft aufweisen, sind keine Fehler im Sinne der Definition. Nachfolgend wird nicht mehr zwischen einem Fehler und einem Verarbeitungsabbruch unterschieden. Im Weiteren werden zur Beschreibung des Fehlerkontextes und des Fehlers selbst Attribute eingeführt, die als Fehlerdetails bezeichnet werden. Innerhalb der Fehlerdetails gibt es Attribute, nachfolgend als Fehlerschlüssel bezeichnet, die eine eindeutige Identifizierung eines aufgetretenen Fehlers ermöglichen. Dieses Kapitel beschreibt die allgemeinen Anforderungen an ein Fehlermanagement. 3.2 Fachliche Anforderungen Die Anforderungen werden nachfolgend tabellarisch aufgelistet. Die Realisierung der Anforderungen wird an anderer Stelle in diesem Dokument beschrieben. Tabelle 1: Funktionale Anforderungen AnforderungsID Bezeichnung Anford.- Level AF-GA Protokollierung von Fehlern MUSS Beschreibung Das Auftreten von Fehlern im Sinne der Definition in einem verteilten, lose gekoppelten System hat einerseits zur Folge, dass Verarbeitungsprozesse nicht durchgeführt werden können, kann auf der anderen Seite im ungünstigsten Fall aber auch zu inkonsistenten, fehlenden oder doppelten Datensätzen führen. Diese Auswirkung auf Daten soll erkannt werden und eine soll möglich sein. Basierend auf dieser Grundlage soll die Protokollierungsstrategie einerseits sicherstellen, dass jeglicher Verarbeitungsabbruch protokolliert wird, und dass zudem das unerkannte Auftreten von Fehlern nahezu unmöglich ist. AF-GA Eingrenzung auf MUSS Es MUSS zwischen Fehlern im Sinne der Defini- gematik_ga_spezifikation V1_3_0.doc Seite 10 von 50

11 AnforderungsID Bezeichnung Anford.- Level Fehler mit Verarbeitungsabbrüchen Beschreibung tion und Warnungen unterschieden werden. Ein Fehler hat eine für den Endanwender sichtbare Auswirkung in der Form, dass ein Geschäftsprozess nicht erfolgreich durchgeführt werden konnte. Im Gegensatz dazu dienen Warnungen den Administratoren eines Systems zur pro-aktiven Fehlervermeidung und sind daher nicht instanzübergreifend relevant. Der Transport von Warnungen wird in der TI nicht unterstützt. Die Speicherung von Warnungen obliegt der Hoheit des Betreibers. AF-GA Informationen für den Endanwender MUSS Aufgetretene Fehler müssen dem Endanwender dargestellt werden. Die Darstellung der Informationen muss instanzübergreifend identisch sein. AF-GA Lokalisierung von Fehlerdetails MUSS Zu einer Fehleranalyse benötigte Fehlerdetails müssen aus der Kombination Instanz, Komponente, MessageID und Code eindeutig lokalisierbar sein. (Siehe Tabelle 6: Datenstruktur der Fehler) AF-GA Tierübergreifende Fehlernummern für generische Fehler MUSS Generische Fehler, die Tier-unabhängig auftreten können, wie beispielsweise http(s)-fehler oder Timeouts, sollten Tier-übergreifend eindeutige Codes verwenden. AF-GA Verwendung von Retry- Mechanismen MUSS Von der Möglichkeit, eine fehlgeschlagene Operation erneut zu versuchen, darf nur Gebrauch gemacht werden, wenn sichergestellt werden kann, dass keine Duplizierung der Nachricht erfolgt. Insbesondere ist jeweils zu prüfen, ob ein Retry über eine Instanzgrenze hinaus zulässig ist. AF-GA Speicherung von Fehlerdetails MUSS Sofern auf einem System ein Fehler erkannt wurde, wird lokal ein Fehler-Schlüssel erzeugt, die Details werden persistent gespeichert und an alle rückwärtigen Systeme gegeben. Alle rückwärtigen Systeme können ebenfalls weiterführende spezifische Details persistent speichern und über den Fehler-Schlüssel auffindbar machen. AF-GA Bereitstellung von Fehlern für übergreifendes Systemmanagement MUSS Die persistent abgelegten Fehlerdetails müssen für ein übergreifendes Fehlermanagement zugreifbar sein. Die Art und Weise der Ablage der Fehlerdetails und der Schnittstelle zu ihnen wird hier nicht festgelegt, sie müssen durch die jeweiligen Betreiber definiert und bereitgestellt werden. Festgelegt wird hier nur, welche Informationen abgelegt werden müssen. gematik_ga_spezifikation V1_3_0.doc Seite 11 von 50

12 Tabelle 2: Nicht-funktionale Anforderungen AnforderungsID Bezeichnung Anford.- Level Beschreibung AN-GA Fehlertransport muss standardkonform erfolgen. MUSS Der Transport von Fehlern innerhalb der TI muss standardisierten Mechanismen und Protokollen folgen, um eine einfache Umsetzung zu gewährleisten. Die Standards werden in diesem Dokument beschrieben. Tabelle 3: Sicherheitsanforderungen AnforderungsID Bezeichnung Anford.- Level Beschreibung AS-GA Speicherung von Nachrichten MUSS Nachrichten dürfen nur zum Zweck der und Wiederaufnahme gespeichert werden. AS-GA Vorhaltezeit von Nachrichten MUSS Telematik-SOAP-Nachrichten, die zum Zweck der gespeichert wurden, müssen nach 30 Tagen gelöscht werden. AS-GA Manipulation und Löschen von Fehlernachrichten MUSS Fehlernachrichten dürfen nicht unbefugt gelöscht oder manipuliert werden. Diese Anforderung KANN durch Zugriffsregeln auf die Daten erfolgen, sie besagt nicht, dass die Fehlermeldungen integritätsgeschützt (signiert) werden sollen. gematik_ga_spezifikation V1_3_0.doc Seite 12 von 50

13 4 Übersicht Dieses Kapitel beschreibt, basierend auf den Anforderungen, den übergreifenden Ablauf der. Es wird nicht auf technische Einzelheiten eingegangen, diese werden in den folgenden Kapiteln erläutert. Vornehmlich dient dieses Kapitel dazu, den grundsätzlichen Ablauf zu beschreiben und verständlich zu machen. 4.1 Einführung Bei der Durchführung von Geschäftsprozessen innerhalb der Telematikinfrastruktur (TI) kann es zu Ausnahmefällen kommen. Diese können durch technische Probleme, fachlich bedingte Probleme wie zum Beispiel falsche oder ungültige Parametrisierung oder andere Ursachen wie ungültige Zertifikate ausgelöst werden. Zur Laufzeit kann es aus verschiedensten Gründen zu Ausnahmefällen und deren Behandlung sowie zu sicherheitsrelevanten Ereignissen kommen. Sicherheitsrelevante Ereignisse müssen für ein Alertmanagement erkennbar sein, Ausnahmefälle müssen protokolliert und die zugrunde liegenden Ursachen müssen lokalisierbar und analysierbar sein. Zusätzlich muss, da die Ausnahmebehandlung eine für den Endanwender sichtbare Auswirkung hat, eine für den Endanwender lesbare Meldung erzeugt werden, aus der er die Ursache bzw. die Bezeichnung für den Ausnahmefall ersehen kann. Zusätzlich muss eine Fehlermeldung an das aufrufende System zurückgegeben werden, mit der der aufgetretene Fehler referenziert werden kann und Details des Fehlers auffindbar sind. Die Umsetzung der Fehler in eine Fehlermeldung, die die fachliche Auswirkung enthält, erfolgt anhand von Mapping-Tabellen durch den Konnektor. Grundsätzlich werden die Details zu dem Fehler nicht an den Aufrufenden weitergegeben. Die Fehlerdetails sollen von der ersten Komponente in der Aufrufkette, die dazu in der Lage ist, lokal abgelegt werden. Die aufrufenden Komponenten erhalten nur die oben erwähnte standardisierte Fehlermeldung, die es unter anderem erlaubt, die lokal abgelegten Fehlerdetails wieder zu finden. Die Erkennung eines Fehlers und die anschließende Protokollierung der relevanten Informationen muss durch alle Anwendungsinfrastruktur- und Fachdienste umgesetzt werden. Damit die vorgehaltenen Informationen als Grundlage für ein TI-weites Fehlermanagement dienen können, müssen instanzübergreifend einheitliche Strukturen und Informationsmodelle verwendet werden. Die Festlegung dieser Strukturen und Informationsmodelle ist Bestandteil dieses Dokuments. Die konkreten Fehlermeldungen MÜSSEN in den Facharchitekturen bzw. Detailspezifikationen der einzelnen Komponenten erfolgen. Grundsätzlich gibt es zwei unterschiedliche technische Wege, diese standardisierten Fehlermeldungen zum Aufrufer eines Request zu liefern, zum einen als Teil der normalen fachlichen Payload und zum anderen als Information in einem SOAP Fault. Letzteres basiert auf der Wahl von SOAP 1.1 als Transportprotokoll. Die beiden Arten des Transportes werden mit gematik Payload Fehlermeldung bzw. gematik SOAP Fault bezeichnet. gematik_ga_spezifikation V1_3_0.doc Seite 13 von 50

14 In der folgenden Tabelle werden die verschiedenen Ausnahmebehandlungen und die daraus resultierenden möglichen Aktivitäten aufgeführt und kurz beschrieben. Im weiteren Dokument wird auf die jeweiligen Reaktionen auf Ausnahmefälle Bezug genommen, ohne sie nochmals zu erklären. Tabelle 4: Reaktionen auf Ausnahmefälle Reaktion Typ Erläuterung Ausnahmebehandlung kann lokal erfolgen. Ausnahmebehandlung kann nicht lokal erfolgen. Ausnahme wird lokal protokolliert. Ausnahme kann lokal nicht protokolliert werden. Fehlermeldung wird an den Aufrufenden zurückgegeben. Fehlermeldung wird nicht an den Aufrufenden zurückgegeben. Die Ausnahme soll den übergreifenden Ablauf abbrechen. Die Ausnahme muss den übergreifenden Ablauf nicht abbrechen. Ausnahmetext (Fehler) wird nicht signiert. Allgemein Allgemein Protokollierung Protokollierung Transport Transport Abbruch Abbruch Signatur Die die Ausnahme feststellende Komponente kann so reagieren, dass keine weiteren Aktionen anderer Komponenten notwendig sind. Die Ausnahme ist für andere Komponenten nicht sichtbar. Diese Ausnahme ist nicht Gegenstand dieses Dokuments. Die die Ausnahme feststellende Komponente kann die Ausnahme nicht auflösen und die Ausnahme muss an die Aufrufende weitergegeben werden. Der normale Ablauf ist unterbrochen. Die Ausnahme wird protokolliert und die Fehlermeldung weitergereicht. Die die Ausnahme erzeugende Komponente kann die Ausnahmedetails selbst protokollieren. Die die Ausnahme erzeugende Komponente kann die Ausnahmedetails nicht selber protokollieren. Die aufrufende Komponente erhält eine Fehlermeldung, protokolliert deswegen die Ausnahme unter Vermerk auf die aufgerufene Komponente und die von dort verfügbaren Ausnahmedetails. Die Fehlermeldung wird an die aufrufende Komponente weitergegeben. Die Ausnahme wird in der Konsequenz dem Endnutzer angezeigt. Die Ausnahme wird nicht weitergereicht. Diese Ausnahme ist nicht Gegenstand dieses Dokuments. Die Fehlermeldung wird per gematik SOAP Fault an den Aufrufer übergeben. Die Fehlermeldung wird per gematik Payload Fehlermeldung an den Aufrufer übergeben. Die Fehlermeldung kann als gematik SOAP Fault oder als gematik Payload Fehlermeldung an den Aufrufer übergeben werden. gematik_ga_spezifikation V1_3_0.doc Seite 14 von 50

15 Reaktion Typ Erläuterung Ausnahmetext (Fehler) muss signiert werden. Ausnahme ist sicherheitstechnisch relevant. Signatur Alert Die Fehlermeldung muss als gematik Payload Fehlermeldung transportiert werden, gematik SOAP Fault DÜRFEN nicht signiert sein. Bei signierten Fehlermeldungen DÜRFEN keine Erweiterungen an der Nachricht (z. B. im Trace Zweig der Nachricht) vorgenommen werden. Die Ausnahme soll zusätzlich zu dem normalen Ausnahmehandling einen Sicherheits-Alert ermöglichen. 4.2 Mögliche Fehlerfälle (exemplarisch) Die hier aufgeführten Fehler geben exemplarisch einen Ausschnitt aus der Menge der möglichen Fehler wieder. Die Liste soll Spezifikatoren und Facharchitekten Anregungen liefern, welche Fehler im Sinne des Fehlermanagements zu betrachten und in den jeweiligen Dokumenten zu spezifizieren sind. Hierbei werden zu den Fehlermeldungen jeweils angegeben. der Text der Fehlermeldung, die Art des Transports der Fehlermeldung zur aufrufenden Komponente und die auslösende Komponente Tabelle 5: Reaktionen auf Ausnahmefälle Fehlermeldung Transport Art Auslösende Komponente Ein Webservice-Provider ist nicht erreichbar. gematik SOAP Fault Broker Ein medizinisches Objekt konnte aufgrund eines technischen Fehlers nicht geschrieben werden. gematik Payload Fehlermeldung Fachdienst Authentisierung der egk ist fehlgeschlagen. gematik SOAP Fault Fachdienst Authentisierung des HBA ist fehlgeschlagen. gematik SOAP Fault Fachdienst Autorisierung der egk ist fehlgeschlagen. gematik SOAP Fault Fachdienst egk ist nicht mehr gültig (gesperrt in PKI). gematik Payload Fehlermeldung Konnektor Eine epa konnte nicht verändert werden, da sie derzeit durch einen anderen Nutzer blockiert ist (zwei Nutzer versuchen gleichzeitig zu ändern). gematik SOAP Fault Fachdienst Eine Verordnung wurde bereits dispensiert. gematik SOAP Fault Fachdienst Es wurden keine Verordnungen für diese egk gefunden. gematik Payload Fehlermeldung Konnektor gematik_ga_spezifikation V1_3_0.doc Seite 15 von 50

16 Fehlermeldung Transport Art Auslösende Komponente Der Audit Service ist nicht verfügbar. gematik SOAP Fault Broker Ein Fachdienst konnte nicht lokalisiert werden. Eine SSL-Verbindung ist unerwartet abgebrochen. Es gibt keine Berechtigung für die SSL- Verbindung (Client Auth. fehlgeschlagen). Es liegt ein ungültiges XML-Schema der SOAP Nachricht vor. Ungültiges XML-Schema der Nutzlast liegt vor. Der Heilberufler ist für diesen Geschäftsprozess nicht berechtigt. Bei der Verarbeitung einer Nachricht ist ein unerwarteter Fehler aufgetreten. gematik SOAP Fault gematik SOAP Fault gematik SOAP Fault gematik SOAP Fault gematik Payload Fehlermeldung gematik SOAP Fault gematik Payload Fehlermeldung Broker Broker Broker Broker Fachdienst Fachdienst Fachdienst Es gibt ein Timeout bei einer Anfrage. gematik SOAP Fault Broker Löschen einer everordnung beim Dispensieren schlägt fehl. gematik SOAP Fault Fachdienst gematik_ga_spezifikation V1_3_0.doc Seite 16 von 50

17 5 Abläufe Die Umsetzung der in Kapitel 3 definierten Anforderungen muss einerseits durch eine persistente Speicherung der für die notwendigen Informationen erfolgen, zusätzlich muss aber auch die Verarbeitung von aufgetretenen Fehlern und Verarbeitungsabbrüchen Tier-übergreifend einheitlich erfolgen. Die Abläufe zur Verarbeitung von Fehlern werden in diesem Kapitel festgelegt. 5.1 Übersicht Die innerhalb der Telematikinfrastruktur kann in vier Teilbereiche zerlegt werden: (1) Das Erkennen und die lokale Verarbeitung eines Fehlers, (2) den Transport der relevanten Informationen zurück an das aufrufende Primärsystem, (3) die Umsetzung technischer Fehlercodes in eine für den Endanwender verständliche Fehlermeldung, sowie (4) die Bereitstellung von Fehlerschlüsseln für das übergreifende System Management. Abbildung 1 stellt die logische Verarbeitung von Fehlern exemplarisch dar. Nicht dargestellte Anwendungsinfrastrukturdienste, wie zum Beispiel der Audit- oder ServiceDirectoryService können analog zu Fachdiensten betrachtet werden. gematik_ga_spezifikation V1_3_0.doc Seite 17 von 50

18 Abbildung 1: Übersicht Das nachfolgende Bild zeigt die definierten Möglichkeiten zur Rückmeldung eines Fehlers im Sinne der Definition an die aufrufende Komponente. (Die Farben sind an die Übersicht angelehnt.) Nicht dargestellt werden hier Fehler, die unterhalb des SOAP-Protokolls liegen. Diese sollen von der ersten Komponente in der Aufruffolge, die dazu in der Lage ist, in die hier definierten Formate transformiert und danach weitergeleitet werden. Abbildung 2: Transport der Fehlermeldung gematik_ga_spezifikation V1_3_0.doc Seite 18 von 50

19 5.1.1 Fehlerkontext Zum Kontext jeden Fehlers gehören die Komponente, in der er auftrat, und die Instanz, in der die Komponente ausgeführt wurde. Des Weiteren können lokale weiterführende Informationen zu einem Fehler abgelegt sein. Diese Ablage wird über die Bezeichnung einer LogReferenz lokalisierbar. Komponenten sind logische Module, die eine bestimmte Funktion aufweisen und durch eigene Spezifikationen oder Facharchitekturen beschrieben sind. Beispiele sind hier Konnektor, Fachdienste, der Broker oder der Telematik Transport Service. Die Instanzen bezeichnen eine Umgebung, in der eine Komponente ausgeführt wird, die durch einen Betreiber zur Verfügung gestellt wird. Jeder Fehlermeldung werden diese Informationen beigefügt. Eine Ausnahme bilden hier Fehlermeldungen des Konnektors, der aus Sicht des Primärsystems direkt angesprochen wird. Die Instanz ist damit klar definiert und muss in diesem Falle nicht in der Fehlermeldung bezeichnet werden Lokale Lokale bezeichnet hier die Aktivitäten, die durch die den Fehler auslösende Instanz auszuführen sind. Die Verarbeitung der Fehler ist sehr stark von der Plattform und der Implementierung abhängig. Aus diesem Grund erfolgt keine detaillierte Spezifikation der lokalen durch die gematik, es werden stattdessen in den nachfolgenden Abschnitten die Anforderungen an die lokale aufgeführt und im Detail erläutert. Die Fehlerdetails SOLLEN von der ersten Komponente in der Aufrufkette, die dazu in der Lage ist, lokal abgelegt werden Bereitstellung von Mechanismen zur Fehlererkennung Jede Instanz MUSS Fehler, die während der lokalen Verarbeitung auftreten, erkennen und verarbeiten können. Dies bedeutet insbesondere, dass kein Fehler unprotokolliert bleiben DARF. Insbesondere für schwere Fehler, die die Nichtverfügbarkeit einer Komponente zur Folge haben, MUSS dies sichergestellt und im Zuge der Zulassung einer Komponente durch die gematik nachgewiesen werden Speicherung von Fehlerdetails und Erzeugung einer Fehlermeldung Nach dem Auftreten eines Fehlers SOLLEN Details, die zur Analyse des Fehlers durch einen Administrator oder Entwickler benötigt werden, persistent gespeichert und eine Fehlermeldung (siehe Abschnitt 6 zur Definition der Datenstruktur Fehlermeldung) erzeugt werden. Der Ort bzw. die Art und Weise der persistenten Ablage der Fehlerdetails wird verallgemeinernd als EventLog bezeichnet. Damit wird nur ein Begriff festgelegt und keine technischen Umsetzungsvorgaben. Das EventLog muss folgende Eigenschaften haben. Die Ablage der Fehlerdetails MUSS so erfolgen, dass sie anhand der Fehlermeldung eindeutig referenzierbar sind. gematik_ga_spezifikation V1_3_0.doc Seite 19 von 50

20 Die Ablage MUSS persistent erfolgen. Das EventLog MUSS einen, auf die Instanz des Betreibers bezogen eindeutigen logischen Bezeichner, die LogReferenz besitzen. Die Einträge im EventLog MÜSSEN einen eindeutigen Rückschluss auf die Applikation in der der Fehler aufgetreten ist, enthalten. Die Kombination Instanz ID und LogReferenz MUSS TI weit eindeutig sein. Die Granularität der EventLogs pro Instanz der Betreiber wird nicht vorgegeben und kann durch die Betreiber bzw. Hersteller der Komponenten frei gewählt werden. Der Entwickler einer Komponente MUSS die Möglichkeit bieten, Fehlerdetails mit unterschiedlicher Granularität abzulegen. Die Granularität wird durch Loglevel bezeichnet. Dabei gilt die Regel, je höher der Loglevel ist, desto höher ist die Detailtiefe der Protokollierung. Loglevel, in denen personenbezogene Daten gespeichert werden, müssen als sicherheitsrelevant gekennzeichnet und verarbeitet werden. Die Verwendung von Logleveln, in denen personenbezogene Daten gespeichert werden, müssen den Vorgaben des [gemsiko] folgen Verarbeitungsabbruch bei synchroner Nachrichtenverarbeitung Fehler, die bei synchroner Nachrichtenverarbeitung auftreten, führen zu einem Abbruch der Verarbeitung. Die empfangene Nachricht MUSS verworfen werden Verwendung von Fehlerqueues für asynchrone Aufrufe Asynchrone Aufrufe stellen in der Telematikinfrastruktur eine Ausnahme dar und sind aktuell nur für die Verwendung des AuditService spezifiziert. Da bei fachlich asynchronen Aufrufen die Verarbeitung der Nachricht zeitversetzt zum Empfang der Nachricht erfolgen kann und das sendende System nicht auf das Ergebnis der Verarbeitung wartet, darf die Nachricht vom empfangenden Dienst in diesem Fall nicht verworfen werden. Die Nachricht MUSS stattdessen in eine Warteschlange aufgenommen werden, um sie nach der Behebung der Fehlerursache verarbeiten zu können. Das Systemmanagement des asynchronen Dienstes hat besonderes Augenmerk darauf zu richten, dass Fehler erkannt und behandelt werden Verarbeitungsabbruch bei Ereignis getriggerter Nachrichtenverarbeitung In diesem Fall wird der Aspekt betrachtet, dass bei ereignisgetriggerten Verarbeitungen Fehler auftreten. Ereignisse bezeichnen hier Trigger zum Starten von Aktivitäten, die nicht mittelbar oder unmittelbar durch Aufrufe von Services durch ein Primärsystem erfolgen. Beispiele sind hier der Updates von Caches, Housekeeping-Aktivitäten und andere. Auch für diese Fehler sollen die Fehlerdetails in ein EventLog geschrieben werden. Die Fehlermeldung kann hier nicht an einen Aufrufenden weitergegeben werden. Die Fehlermeldung MUSS entweder persistent abgelegt werden und dem Systemmanagement zu- gematik_ga_spezifikation V1_3_0.doc Seite 20 von 50

21 gänglich sein oder diesem direkt zugeführt werden. Hier werden keine weiteren Vorgaben gemacht. Es MUSS sichergestellt sein, dass ein Systemmanagement die Fehlermeldung erhält, um auf diese Fehler reagieren zu können Rückgabe der Fehlermeldung an das aufrufende System Nach dem persistenten Speichern der Fehlerdetails und dem Erzeugen der Fehlermeldung MUSS die Anfrage zur Verarbeitung der fehlgeschlagenen Nachricht mit einem Fehler beantwortet werden und die Fehlermeldung gemäß Abschnitt 5.2 übertragen werden. Von der auslösenden Komponente darf jeweils nur genau eine auf die Komponente bezogene Fehlermeldung zurückgegeben werden. Wurde die einen Fehler meldende Komponente von einer anderen Komponente aufgerufen, so KANN die aufrufende Komponente an die empfangene Fehlermeldung eine den eigenen Kontext beschreibende Fehlermeldung anfügen. Siehe dazu die Trace Elemente der Fehlerstruktur. Fehlermeldungen werden stets am Ende der Trace Liste angefügt Verwendung von Retry-Mechanismen Das Verarbeiten einer Nachricht kann aufgrund der temporären Nicht-Verfügbarkeit einer Komponente fehlschlagen. In solchen Fällen kann ein erneuter Versuch der Verarbeitung, ein so genanntes Retry, erfolgreich sein und die Verarbeitung der Nachricht fortgeführt werden. Für die Verwendung von Retry-Mechanismen MUSS sichergestellt werden, dass keine zweimalige Verarbeitung der Nachricht erfolgt. Dies bedeutet insbesondere, dass die Verwendung von Retry-Mechanismen über Tier-Grenzen genau zu prüfen ist, da bei lose gekoppelten Systemen dies nicht immer sichergestellt werden kann. Zusätzlich kann davon ausgegangen werden, dass nur sehr kurze Verarbeitungszeiträume zur Verfügung stehen. Somit führt in den meisten Fällen das erneute Versuchen eines Aufrufs ohnehin zu einer Überschreitung der zulässigen Verarbeitungszeit und somit zu einem Timeout. Aus diesem Grund werden Retries über Komponentengrenzen hinaus generell ausgeschlossen. Diese Regelung kann aber durch Spezifikationen und Architekturen in begründeten Einzelfällen außer Kraft gesetzt werden. Die Kommunikation über Komponentengrenzen hinaus erfolgt immer mittels definierter Interfaces. Sollte eine Spezifikation oder Architektur das Verbot von Retries außer Kraft setzen, so MUSS die das Interface verwendende Spezifikation oder Architektur begründen, warum ein Retry notwendig ist und explizit die Verwendung von Retries spezifizieren. Die ein Interface bereitstellende Architektur oder Spezifikation muss ihrerseits spezifizieren, warum ein doppelter Aufruf zulässig ist und keine Probleme bereitet oder wie sichergestellt wird, dass ein doppelter Aufruf erkannt und die doppelte Verarbeitung verhindert wird Protokollierung der Fehler verursachenden Nachricht Bei dem Auftreten eines lokalen Fehlers KANN die zugehörige Nachricht bzw. Teile der Nachricht zur Analyse des Fehlers persistent gespeichert werden. Es gelten hierzu die Datenschutzbestimmungen aus Abschnitt 6.4. In keinem Fall dürfen unverschlüsselte medizinische Daten protokolliert werden. gematik_ga_spezifikation V1_3_0.doc Seite 21 von 50

22 5.2 Transport von Fehlermeldungen Wie in Abschnitt 5.1 aufgeführt ist es die Aufgabe jeder Instanz, innerhalb der TI lokale Fehler zu erkennen und bei synchronen Aufrufen Informationen, die zur Lokalisierung und Einordnung des Fehlers dienen, an die jeweils aufrufende Instanz zurückzumelden. Hierdurch wird der Transport der Fehlermeldung zu einem Konnektor und von dort zum Primärsystem umgesetzt. Zu jedem Fehler werden Kontextinformationen und die den eigentlichen Fehler beschreibenden Informationen übergeben. Die Implementierungen aller Telematik- und Fachdienst-Services können Fehler in gematik SOAP Faults oder als Element der Payload transportieren. Die Bezeichnung für die Art des Transportes kann den Wert gematik SOAP Fault für den Transport der Fehlermeldung als SOAP Fault gemäß Abschnitt 6.3.2, oder gematik Payload Fehlermeldung für den Transport der Fehlermeldung als Teil der Payload gemäß Abschnitt 6.3.1, annehmen. Kriterien für die Auswahl des Transportweges sind: Fehler, die auf dem Transport des Serviceaufrufes zwischen dem Konnektor und den Fachdiensten auftreten, MÜSSEN als gematik SOAP Faults zum Aufrufenden übertragen werden. Dies gilt auch für Security-Fehler innerhalb der Fachdienste (Prüfung Nachrichtensignaturen der Telematik-Transport- Schicht). Alle anderen Fehler im Zusammenhang mit der Verarbeitung der fachlichen Payload SOLLEN als gematik Payload Fehlermeldung übertragen werden. Fehler, die in der Telematikinfrastruktur durch andere Komponenten als den Konnektor erkannt werden sollen, MÜSSEN als gematik SOAP Fault übertragen werden. Dies liegt darin begründet, dass nur der Konnektor und der Fachdienst den Inhalt der Payload betrachten. Gemeint sind hier Fehler, die zum Beispiel im Broker erkannt werden sollen, da sie für die dort ablaufende Logik als Entscheidungskriterium gelten. Fehler, die fachlich begründet sind, MÜSSEN als gematik Payload Fehlermeldung übertragen werden. Diese Festlegung gilt für die Kommunikation von Fehlern zwischen ConnectorService und BrokerService, zwischen BrokerService und Fachdiensten und zwischen BrokerService und zugeordneten Telematik-Services. Für die Kommunikation zwischen dem Primärsystem und dem Konnektor werden keine gematik SOAP Faults verwendet. Stattdessen gilt: Alle Fehler werden als Payload der Konnektor Response übertragen. Weitere Wege des Transports von Fehlern sind nicht zulässig, es kann jedoch in begründeten Fällen von den Auswahlkriterien abgewichen werden. Sollte in einer Facharchitektur oder einer Spezifikation ein von dem Defaultwert abweichender Transportweg gewählt werden, so ist dies explizit anzugeben. Dazu MUSS in dem Dokument, in dem die Auslösung des betreffenden Fehlers beschrieben ist, der vom Defaultwert abweichende Transportweg so angegeben werden, dass für jeden Fall, in dem der Fehler auftritt, klar ist, auf welchem Transportweg er transportiert werden soll. gematik_ga_spezifikation V1_3_0.doc Seite 22 von 50

23 5.3 Fehler auf Transportprotokollebene Fehler, die im OSI Modell unterhalb des SOAP-Protokolls auftauchen, SOLLEN entsprechend der Möglichkeiten des verwendeten Protokolls übertragen werden. Beispiele hierfür sind Fehler auf VPN, TCP/IP oder http(s) Ebene. Hier kann es abhängig von Protokoll oder Protokollhändler unter Umständen nicht möglich sein, gematik SOAP Faults oder gematik SOAP Payloads zu erzeugen. In diesem Fall soll die aufrufende Komponente die Fehlermeldung entsprechend entgegennehmen und die hier verwendete Fehlerstruktur zum Weiterleiten des Fehlers verwenden. Sofern eine Komponente mit Fehlern auf Transportprotokollebene in Berührung kommen kann, MUSS durch die Spezifikation oder Architektur spezifiziert werden, wie Fehler auf einer tieferen Ebene des OSI-Modells auf gematik SOAP Faults abgebildet werden. Dazu sind den einzelnen nicht von der gematik definierten Fehlern die entsprechenden gematik- Fehler, auf die der Fehler abgebildet werden soll, zuzuordnen. Dazu folgendes Beispiel: Faultcode gemäß WSS Gematik Fehlercode wsse:unsupportedsecuritytoken Gematik SOAP Fault mit Code wsse:unsupportedalgorithm Gematik SOAP Fault mit Code wsse:invalidsecuritytoken Gematik SOAP Fault mit Code Umsetzung von Fehlermeldungen in eine für Endanwender verständliche Form Zu Fehlern innerhalb der Telematikinfrastruktur werden immer Fehlercodes mitgeliefert. Zusätzlich zu den Fehlercodes MÜSSEN Fehlertexte mit übertragen werden. Der Konnektor KANN eine Umsetzung des Fehlercodes in eine für den Endanwender verständlichere Form durchführen, sofern er weitere Kontextinformationen besitzt oder eine Fehlercodetabelle explizit die Anzeige einer abweichenden Meldung erfordert. Die Spezifikation dieser Fehlercodetabelle KANN durch den Konnektorhersteller erfolgen. Die lesbare Fehlermeldung wird an das Primärsystem weitergeleitet. Das Primärsystem muss dem Endanwender die lesbare Fehlermeldung anzeigen und die Möglichkeit bieten, die beigefügten Fehlermeldungen, die optionale Liste der Fehlermeldungen der einzelnen Komponenten, anzuzeigen. Jeder Fehler SOLL in einer Fehlertabelle aufgeführt sein. In der Fehlertabelle werden pro Komponente die möglichen Fehler unter Angabe des für diese Komponente eindeutigen Fehlercodes und des Fehlertextes aufgeführt. Zusätzlich kann pro Fehler die Art des Transportes des Fehlers und der mögliche Inhalt der Fehlerdetails (siehe Kapitel 6 ) spezifiziert werden. Die Fehlercodetabelle ist exemplarisch im Anhang E aufgezeigt. 5.5 Fehlertexte für das Primärsystem Die durch ein Primärsystem einem Endnutzer anzuzeigende Fehlermeldung wird durch die am Konnektor aufgerufene fachliche Schnittstelle definiert. Dazu MUSS in dem die Schnittstelle beschreibenden Dokument, in der Regel die Facharchitektur oder die Spezifikation, definiert werden, welcher Fehler (Fehlercode und Text) bei einem Abbruch der gematik_ga_spezifikation V1_3_0.doc Seite 23 von 50

24 Funktion durch einen Fehlerzustand dem Endnutzer angezeigt wird. Dieser Fehler MUSS dem Endanwender primär angezeigt werden. Der anzuzeigende Fehler MUSS der letzte Eintrag in der Trace Liste der Fehlerstruktur sein. Der Endnutzer MUSS die Möglichkeit haben, auf die diesen Fehler zugeordneten und im Trace Zweig der Fehlermeldung dokumentierten weiteren Fehler zugreifen zu können Fachliche Service-Aufrufe Die dem Primärsystemnutzer anzuzeigenden Fehlermeldungen zu fachlichen Services werden durch die Facharchitekturen festgelegt. Dazu wird in den Facharchitekturen jeweils der Fehler definiert, der dem Aufrufer eines Services mindestens zu übergeben ist. Vorherige Fehler können als Liste weiterer Fehler mit übergeben werden Nicht-fachliche Service-Aufrufe Fehler, die nicht durch einen in einer Facharchitektur beschriebenen Serviceaufruf erzeugt werden, werden mit dem Fehlertext an den Aufrufer übergeben, der in der aufgerufenen Funktion definiert wurde. gematik_ga_spezifikation V1_3_0.doc Seite 24 von 50

25 6 Informationsmodell der Fehlermeldung Die Fehlermeldung, im Modell Error benannt, dient der räumlichen Eingrenzung eines Fehlers auf eine Tier bzw. auf ein SLO-Segment (siehe [gemgesarch]). Sie soll dem Anwender genügend Informationen zur Verfügung stellen, um eine Einschätzung vorzunehmen, wie mit diesem Fehler zu verfahren ist und liefert technische oder fachliche Informationen, die eine genaue Analyse des Fehlers erlauben. In dem folgenden Diagramm ist das Informationsmodell zur abgebildet. Entsprechend den Konventionen der gematik sind die Klassen und Attribute englisch notiert, wenngleich in diesem Dokument versucht wird, die jeweiligen deutschen Begriffe zu nutzten. class «enumeration» Instance Error - MessageID: String - Timestamp: String 1 1..* Trace - EventID: String - Detail: String [0..1] Instance «enumeration» LogReference LogReference 1 1..* «enumeration» ErrorCode ErrorCode ErrorText «enumeration» ComponentType CompType «enumeration» SeverityType Severity 1 «enumeration» ErrorType ErrorType Abbildung 3: Infomodell Fehlermeldung Im Kontext dieses Dokumentes bezeichnet der Begriff Instanz nicht einen einzelnen Server, der zur Bereitstellung eines Anwendungsdienstes dient, sondern die Gesamtheit aller Komponenten eines Betreibers, die für andere Telematik-Dienste über eine einheitliche Adresse (beispielsweise eine virtuelle IP oder eine URL) ansprechbar sind. Gleichzeitig soll auch der Bezug zu der Nachricht, die den Fehler ausgelöst hat, möglich sein, um so eine Nachverfolgung des Fehlers durch alle Tier zu erlauben. Hierzu wird die eindeutige MessageID der den Fehler auslösenden Nachricht vermerkt. gematik_ga_spezifikation V1_3_0.doc Seite 25 von 50

26 Tabelle 6: Datenstruktur der Fehlermeldung Datenelement Definition Optional Beschreibung Wertebereich MessageID UUID Nein UUID der Nachricht, durch die der Fehler ausgelöst wurde, bzw. leer falls keine triggernde Nachricht existiert. Timestamp datetime Nein Zeitstempel des auftretenden Fehlers. Als Zeitzone KANN UTC verwendet werden. Das Format entspricht der Definition in [XML Datatypes] Beispiel: " T09:30:47.0Z" Dynamisch, bestimmt durch die MessageId der triggernden Nachricht, bzw leer Zeit EventID String (Maximale Länge 100) Nein Die EventID ist das Identifikationsmerkmal eines Fehlers. Das Format und der Inhalt der ID können durch den Betreiber bzw. den Ersteller einer Komponente frei vergeben werden. Die Kombination aus EventID und LogReference MUSS innerhalb der Domäne einer Instanz eine eindeutige Referenzierung des Fehlers erlauben. Das bedeutet, dass die Kombination aus EventID, LogReference und Instance eine telematikweit eindeutige Referenzierung eines Fehlers erlaubt. Instanzabhängig, keine syntaktischen Vorgaben Instance String (Maximale Länge 100) Nein Eindeutiges Identitätsmerkmal der Instanz, die das Fehlermanagement angestoßen hat und in deren Logging/Tracing weitere Details über den Fehler zu finden sind. Das Identitätsmerkmal wird der Instanz bei Akkreditierung durch die gematik mitgeteilt und muss dementsprechend innerhalb der fehlererzeugenden Komponenten konfigurierbar sein. Für alle Konnektoren ist dieses Element immer auf Konnektor-Lokal zu setzen, da eine Vergabe von Instanzkennungen für Konnektoren einen unnötigen Aufwand verursachen würde. Die Instance ID wird durch die gematik vergeben und ist dann betreiberabhängig. LogReference String (Maximale Länge 100) Nein Die LogReference ist ein verpflichtendes Merkmal, das die Lokalisierung des verwendeten EventLogs innerhalb der Instanz eines Betreibers ermöglicht. Die Granularität der verwendeten EventLogs kann durch den Betreiber gewählt werden. Definiert durch Betreiber der Instanz Die Verwendung des zu verwendenden EventLogs für eine Instanz MUSS konfigurierbar sein. Der Konnektor gematik_ga_spezifikation V1_3_0.doc Seite 26 von 50

27 Datenelement Definition Optional Beschreibung Wertebereich liefert hier einen leeren String an die Primärsysteme. CompType String Nein Das Element CompType enthält den Komponenten-Typ bzw. den Fachdienst-Typ, auf dem der Fehler aufgetreten ist. Dies dient zur Entkopplung der Codes zwischen den Komponenten bzw. den Facharchitekturen. Die maschinelle Verarbeitung eines Fehlers soll immer die Kombination aus CompType und Code verwenden um einen spezielle Art von Fehler zu erkennen. Definiert durch gematik Code Positive Integer Nein Das Element Code wird als Integer hinterlegt und enthält den Fehlercode. Die nähere Definition der Fehlercodes erfolgt in Abschnitt 6.1. Die maschinelle Verarbeitung eines Fehlers MUSS immer die Kombination aus CompType und Code verwenden um einen spezielle Art von Fehler zu erkennen. Definiert durch gematik ErrorText String (Maximal Länge 250) Nein Beschreibt den Fehler in deutscher Sprache. Dient vor allem dazu, einen Standardtext pro Fehler vorhalten zu können. Definiert durch gematik ErrorType String Nein Das Element ErrorType enthält den Typ eines Fehlers. Dies dient zur Gruppierung der Codes, übergreifend für Komponenten und Facharchitekturen. Die Gruppierung erfolgt bezüglich technischer, fachlicher oder die Sicherheitsaspekte betreffende Fehler. Siehe dazu Tabelle 14: Error Typen Severity String Nein Die Severity gibt den Schweregrad des Fehlers an. Siehe dazu Für die Abbildung der Severity in den Fehlermeldungen MÜSSEN folgende Kürzel verwendet werden. Definiert durch gematik Definiert durch gematik Tabelle 13: Severity Codes Detail String Ja Beschreibt weitere nicht standardisierte Details zu dem Fehler. Die Befüllung ist Hersteller spezifisch. Es DÜRFEN KEINE unverschlüsselten medizinischen Daten übertragen werden. Dieses Feld ist nicht dafür vorgesehen, eine automatisierte Auswertung zu ermöglichen. Es soll fehlerabhängige Zusatzinformationen transportieren. Dynamisch gematik_ga_spezifikation V1_3_0.doc Seite 27 von 50