Gegenstück zu Die sechs Fehlerkategorien: Dort steht, was es für Fehlerklassen gibt. Hier steht, in welcher Reihenfolge man vorgeht, um von „im Portal fehlt was” zu einem Befund zu kommen, den man vor einer Kunden-IT vertreten kann.
Der Leitfaden ist als Checkliste gebaut. Die Reihenfolge ist nicht beliebig — jeder Schritt setzt den vorigen voraus.
Schritt 1 — Symptom präzisieren
Bevor irgendetwas untersucht wird: Was genau ist beobachtbar?
- Was fehlt oder ist falsch, und wo genau? Nicht „Daten fehlen”, sondern „Patient existiert, Aufenthalt fehlt”.
- Seit wann? Und: Gibt es ein Ereignis, das zeitlich zusammenfällt (Release, Migration, Konfigurationsänderung)?
- Betrifft es alle Fälle oder eine Teilmenge? Eine Teilmenge ist die wertvollere Information — sie grenzt die Ursache ein. Frage: Was haben die betroffenen Fälle gemeinsam, das die anderen nicht haben?
- Ist es reproduzierbar? Falls nein: Gibt es einen konservierten Einzelfall mit Zeitstempel?
Ein Symptom ohne Abgrenzung („manchmal fehlt was”) ist kein Untersuchungsgegenstand. Der erste Arbeitsschritt ist immer, aus „manchmal” ein „bei genau diesen” zu machen.
Schritt 2 — Beweislage klären
Bevor man Ursachen sucht: Was ist tatsächlich belegt, und wodurch? Die meisten Fehlsuchen laufen deshalb in die falsche Richtung, weil eine Behauptung als Nachweis behandelt wurde.
| Aussage | Beweist tatsächlich | Beweist nicht |
|---|---|---|
| „Die Nachricht wurde gesendet” | dass das Sendesystem sie erzeugt hat | dass sie angekommen ist |
| „Wir haben unverändert aus der DB gesendet” | den Inhalt der Datenbank | die Bytefolge auf der Leitung |
„tcpdump zeigt alle Bytes” | die Zustellung auf Transportebene | dass daraus eine Nachricht wurde |
| „100 % quittiert, null NACKs” | dass geantwortet wurde | dass verarbeitet wurde — bei MSH-16 = NE ist es eine Tautologie |
„MSA|AA” | dass die Anwendung den übergebenen Ausschnitt verarbeitet hat | dass das Ergebnis stimmt oder vollständig ist |
| Screenshot aus einem Texteditor | dass Zeichen vorhanden sind | nichts über Steuerzeichen, Encoding oder Rahmenbytes |
| „Bei uns ist alles korrekt zusammengeführt / gepflegt” | den Endzustand im Quellsystem | dass die Nachricht dasselbe aussagt — Zustand und Aussage sind zwei Dinge |
| „Bei uns im KIS sieht es richtig aus” | den Zustand des Quellsystems | dass er übertragen wurde |
Die Beweismittel, die tatsächlich tragen:
| Frage | Beweismittel |
|---|---|
| Sind die Bytes angekommen? | tcpdump / Wireshark |
| Wurde daraus eine Nachricht? | Hexdump des Frames (hexdump -C, xxd, od -c, cat -v) |
| Was stand wirklich in der Nachricht? | archivierte Rohnachricht, nicht die Ansicht im Tool |
| Wurde sie angenommen? | MSA-1 = CA/CE/CR |
| Wurde sie verarbeitet? | MSA-1 = AA/AE/AR — sofern MSH-16 das überhaupt zulässt |
| Ist das Ergebnis richtig und vollständig? | nur Abgleich Quelle ↔ Ziel auf Satzebene |
Schritt 3 — Schicht bestimmen
Die Leitfrage lautet nicht „was ist falsch”, sondern „auf welcher Schicht liegt der Defekt — und welches Protokoll könnte ihn dort überhaupt sehen?”
| Schicht | Regelwerk | Typische Defekte | Wer sieht sie |
|---|---|---|---|
| Transport (TCP) | RFC | Verbindungsabbruch, halboffene Sockets | Monitoring |
| Framing (MLLP) | MLLP-Spezifikation | Steuerzeichen im Inhalt, fehlender Start Block, Encoding-Kollision | niemand automatisch |
| Nachricht (HL7 v2) | v2-Standard | Segmentfolge, Pflichtfelder, Datentypen | Validator, Parser |
| Semantik | Standard + bilaterale Absprache | falsches Event, falsche Ebene, unterbestimmte Aussage | niemand automatisch |
| Fachlogik | Prozess im Haus | plausible Nachricht, unmögliche Realität | Fachanwender, Abgleich |
„Konform wozu?” — Der Satz „der Sender ist standardkonform” ist ohne Schichtangabe keine Aussage. Ein Sender kann eine wohlgeformte v2-Nachricht in einen regelwidrigen MLLP-Rahmen legen: auf Nachrichtenebene konform, auf Transportebene nicht.
Trägt hier die Struktur die Semantik? Manche Aussagen stehen in keinem Feld, sondern in der Anordnung — welches Segment einen Wert führt, in welcher Reihenfolge Wiederholungen stehen, welche Nachrichtenstruktur MSH-9.3 benennt. Solche Aussagen sind nicht validierbar: Eine Vertauschung erzeugt keine fehlerhafte Nachricht, sondern eine wohlgeformte mit anderer Bedeutung. Wo das der Fall ist, hilft nur fachliche Plausibilisierung vor der Ausführung.
Ebenso wichtig: Wer trifft eigentlich die Entscheidung? Wenn ein Zielsystem etwas tut, das die Nachricht nicht verlangt, liegt der Defekt nicht in der Nachricht, sondern in der Implementierung des Empfängers. Das ist der Unterschied zwischen „das kommt so vom KIS” und „euer System entscheidet das, und die Nachricht gibt die Entscheidung nicht her”.
Schritt 4 — Kausalität prüfen
Ein auffälliger Befund ist nicht automatisch die Ursache. Zwei Gegenproben:
Die Ersetzungsprobe. Ersetze den Befund gedanklich durch die korrekte Variante — verschwindet das Symptom? Wenn nicht, hast du einen echten Nebenbefund gefunden, aber nicht die Ursache. Das ist die schärfste verfügbare Prüfung und kostet dreißig Sekunden.
Das ausgearbeitete Verfahren — Matrix, Rechenregeln, Ergebnisklassen, Irrelevanz-Test und die Trennung von Bestand und Zufluss — steht in Die Ersetzungsprobe. Sobald mehr als ein Befund oder mehr als eine Beobachtung im Spiel ist, trägt der Absatz hier nicht mehr.
Die Restfrage. Wenn etwas abgeschnitten, verworfen, ersetzt oder zusammengeführt wurde: wo bleibt das, was übrig ist? Ein vollständig beschriebener Mechanismus sagt immer beides — was mit dem sichtbaren Teil passiert und was mit dem Rest. Typische Stellen, an denen der Rest verschwindet:
- abgeschnittener Frame → der Teil hinter dem Schnitt
- Storno → die Objekte, die am stornierten Vorgang hingen
- Merge → die Daten der aufgegebenen Identität
- Update mit Teilinhalt → die Felder, über die nichts gesagt wurde
Schritt 5 — Einordnen, gegen die Definition
Der häufigste Fehler an dieser Stelle ist, die Kategorie nach Gefühl zu wählen. Die Kategorien haben Bedingungen; jede wird einzeln geprüft.
| Kategorie | Bedingung 1 | Bedingung 2 | beide erfüllt? |
|---|---|---|---|
| 2 Harter Fehler | Empfänger bricht ab | — | |
| 3 Empfänger rät | Aussage ist unvollständig oder mehrdeutig | Empfänger muss wählen | |
| 4 Mapping-Fehler | beide Seiten konform | die Abbildung ist falsch | |
| 5 Ungewollte Aussage | beide Seiten konform | Aussage vollständig und korrekt verstanden | |
| 6 Unterhalb des Vertrags | Regelverletzung auf nicht geprüfter Schicht | Information kommt nie an |
Der Entscheidungsbaum in Kurzform:
- Bricht etwas ab? → 2
- Kommt die Information überhaupt an? Nein → 6
- Ist die Aussage vollständig und eindeutig? Nein → 3
- Ja, vollständig — wird sie falsch verarbeitet? → 4
- Ja, vollständig, korrekt verarbeitet, Ergebnis trotzdem falsch → 5
Zwei Formulierungen, die die Antwort schon enthalten:
- „Es fehlt der entscheidende Zusatz” / „das steht da nicht” → die Aussage ist unvollständig → 3, nicht 5.
- „Beide Seiten arbeiten korrekt” → prüfen, ob das für jede Schicht gilt. Meist gilt es nur für die gerade betrachtete.
Der Befund, wie er im Ticket steht
Ein vollständiger Befund hat fünf Teile. Fehlt einer, ist er nicht vertretbar:
- Symptom — was beobachtbar ist, mit Abgrenzung
- Fundstelle — Feld, Byte-Offset oder Ereignis, mit Beweismittel
- Mechanismus — wie die Fundstelle das Symptom erzeugt, inklusive Verbleib des Rests
- Kategorie + Kahn-Ausprägung — Mechanismus und Datenwirkung (Conformance / Completeness / Plausibility)
- Konsequenz — was im Schnittstellenkonzept festzuhalten oder zu ändern ist
Trainingsteil: die wiederkehrenden Fehlgriffe
Diese fünf erklären den Großteil der falschen Befunde. Als Selbstkontrolle vor dem Absenden:
- Kategorie nach Gefühl statt gegen Definition. Symptom: Der Mechanismus ist richtig beschrieben, die Nummer stimmt nicht. Gegenmittel: Bedingungen laut mitsprechen.
- Konformität ohne Schichtangabe. Symptom: „ist standardkonform” — ohne zu sagen, wozu.
- Nur der sichtbare Teil. Symptom: Der Mechanismus endet dort, wo die Beobachtung endet. Gegenmittel: die Restfrage.
- Behauptung als Nachweis. Symptom: Eine Aussage der Gegenseite wird als Beleg übernommen. Gegenmittel: die Beweistabelle aus Schritt 2.
- Nebenbefund als Ursache. Symptom: Der auffälligste Fund wird zur Erklärung erklärt. Gegenmittel: die Ersetzungsprobe.
Und die Regel für eigene Prüfbeispiele: Ein Beispiel, das den Defekt nicht darstellen kann, prüft nichts. Byte- und positionsabhängige Beispiele generieren und die Offsets nachrechnen, nie tippen.
Fragen an die Kunden-IT, gebündelt
Die vollständigen Listen stehen thematisch auf den Konzeptseiten. Diese sechs decken die meisten Strecken ab und gehören in jedes Kick-off:
- Update-Semantik: Sendet ihr Snapshot oder Delta — bedeutet ein fehlendes Feld „unverändert” oder „leer”? Und unterstützt euer System
""? - Quittungsvertrag: Welche Werte stehen in
MSH-15/MSH-16, und wurden sie bewusst gesetzt? FallsNE: über welchen Weg erfahrt ihr von Verarbeitungsfehlern? - Identität: Was ist die stabile Fallnummer, und bleibt sie über Verlegung und Storno gleich? Ist
CX.4gesetzt und im Verbund eindeutig? - Transport: Was macht euer Reader mit Bytes ohne Start Block? Prüft der Sendepfad auf Steuerzeichen unter
0x20? Läuft die Strecke über TLS oder ein separiertes Segment? - Ereignisse: Welche Events sendet ihr — und auf welcher Ebene sprechen sie? Habt ihr ein Event für Stammdatenänderungen ohne laufenden Fall?
- Nachweis: Gibt es einen regelmäßigen Abgleich Quelle ↔ Ziel auf Satzebene? Wenn nein: bei welcher Fehlerkategorie seid ihr sicher, sie zu sehen — und bei welcher sicher nicht?
Siehe auch
Die sechs Fehlerkategorien · HL7-v2-Konzepte · Quellen & Lektüre