Ticket-Playbook — von der Störungsmeldung zum belegten Befund

Wozu diese Seite

Der Diagnoseleitfaden sagt, in welcher Reihenfolge man vorgeht. Das Fehlerraster sagt, wohin ein Befund gehört. Die Ersetzungsprobe sagt, welcher Befund der wirksame ist.

Was in allen dreien fehlt, ist die Bedienung: wie man vom Ticket zur ersten Zeile kommt, woran entlang man rechnet, und woran man merkt, dass eine Teilantwort noch nicht trägt. Diese Seite schließt die Lücke. Sie ist als Nachschlagewerk gebaut — ein Abschnitt je Analyseschritt, jeder nach demselben Muster:

Was die Frage will · Das Verfahren · Woran die Antwort scheitert · Durchgerechnet.

Das durchgehende Beispiel ist synthetisch und steht am Ende jedes Abschnitts.

Der Beispielfall

Ein Patientenportal wird über einen Adapter aus einem KIS beliefert: HL7 v2 ADT → Adapter → FHIR-Server (R4) → Portal. Der Adapter bildet die Patientennummer aus PID-3.1 auf Patient.id ab — so steht es im Schnittstellenkonzept, mit der Begründung „stabil, eindeutig, erspart einen Suchlauf”. Nach zehn Wochen Betrieb wird ein zweites Haus angeschlossen. Dessen Patientennummern tragen seit einer Fusion das Präfix SUED_. Seither schlagen rund 18 % der Patienten-Syncs mit 400 fehl; im OperationOutcome steht Patient.id. S1 ~18 % Fehler, nur zweites Haus · S2 erstes Haus fehlerfrei · S3 vorher kein einziger Fehler dieser Art · S4 betroffene Patienten fehlen im Portal vollständig, kein Teildatensatz.

---

Vor allem anderen: die Kausalkette

Alles Folgende hängt an einer einzigen Vorarbeit. Ohne sie ist keiner der sechs Schritte rechenbar.

Schreib die Kette als nummerierte Glieder hin, von der Quelle bis zum Symptom. Nicht im Kopf.

Jedes Glied ist ein Verarbeitungsschritt oder ein Element, kein Zustand und keine Absicht. „Der Adapter macht einen Fehler” ist kein Glied. „Der Adapter schreibt PID-3.1 nach Patient.id” ist eines.

1  KIS sendet ADT mit PID-3 = SUED_778123           (im KIS korrekt)
2  Adapter setzt Patient.id = PID-3.1               ← erste kritische Stelle
3  Adapter setzt request.url = "Patient/SUED_778123"
4  Bundle (transaction) geht an den FHIR-Server
5  Server prüft Patient.id gegen den Datentyp id
   [A-Za-z0-9\-\.]{1,64}  → Unterstrich unzulässig
6  Server lehnt ab: 400 + OperationOutcome auf Patient.id
7  transaction ist atomar → kein Eintrag wird geschrieben
8  Bundle geht in die Fehler-Queue                   → S1, S4

Diese acht Zeilen sind das Instrument. Die sechs Analyseschritte sind Arten, darauf zu spielen.

Prüfung der Kette, bevor es weitergeht: Lässt sich jede gemeldete Beobachtung aus ihr herleiten? Wenn nicht, ist entweder die Kette unvollständig oder eine Randbedingung fehlt. Beides gehört geklärt, bevor man weiterrechnet — nicht mittendrin.

---

(a) Mechanismus

Was die Frage will

Nicht wo der Fehler sitzt, sondern wodurch aus einem Zustand der nächste wird. Die Antwort ist eine Kette, kein Ort.

Das Verfahren

1. Kette hinschreiben (siehe oben).
2. Die eine Stelle benennen, an der aus etwas Gültigem etwas Ungültiges wird — als Element oder Schritt, mit Nummer.
3. Jede Beobachtung einzeln herleiten. Nicht „daraus folgen S1 bis S4”, sondern vier Sätze. Eine Beobachtung, die man nicht herleiten kann, ist ein Fund.
4. Den Umkehrfall prüfen: Warum tritt der Defekt dort nicht auf, wo er nicht auftritt? Das ist meist die schärfste Aussage der ganzen Analyse.
5. „Wer entscheidet?” — welches System tut etwas, das ihm niemand vorgeschrieben hat?

Woran die Antwort scheitert

Fehler	Erkennungsmerkmal	Gegenmittel
Kette endet vor dem Symptom	die letzte Zeile ist eine Zwischenstufe	Bis zu dem hinschreiben, was im Ticket gemeldet wurde
Zwischenschritt übersprungen	ein „damit” oder „dadurch” trägt die halbe Erklärung	Jedes „damit” durch ein Kettenglied ersetzen
Nebenbeobachtungen pauschal abgehandelt	„S2 und S3 folgen analog”	Vier Beobachtungen, vier Sätze
„Wer entscheidet” reflexhaft beantwortet	dieselbe Antwort wie beim letzten Ticket	Prüfen, ob überhaupt jemand einen Spielraum hatte

„Wer entscheidet?” ist eine Frage, keine Formel. Die Antwort darf auch niemand lauten — dann handeln alle Beteiligten regelkonform, und der Defekt sitzt in dem, was gesendet wurde. Ein System, das keine Wahl hat, trifft keine Entscheidung, es vollzieht eine.

Durchgerechnet

Die eine Stelle ist Glied 2: Ein fremdvergebener Geschäftswert landet in einer Adressposition mit engerem Zeichenvorrat. Der Wert wird dabei nicht verändert — er wechselt die Position, und erst die Position macht ihn ungültig.

S2 (erstes Haus fehlerfrei): Dessen Nummern sind rein numerisch und liegen zufällig innerhalb des erlaubten Vorrats. Der Defekt war zehn Wochen lang vorhanden und hatte nur keine Gelegenheit. S3 ist derselbe Satz, auf der Zeitachse gelesen. S4 folgt aus Glied 7: Die Atomarität von transaction verhindert einen Teilzustand — deshalb entsteht kein halber Datensatz, sondern gar keiner.

Wer entscheidet: der Adapter, also die eigene Seite. Der Server hat keinen Spielraum; er prüft einen Datentyp und lehnt ab.

Ein Defekt, der von der Datenlage abhängt statt vom Vertrag, ist nicht abwesend, solange er nicht auftritt — er ist unbeobachtet.

---

(b) Ebene der Aussage

Was die Frage will

Auf welcher Abstraktionsstufe wird die Behauptung gemacht, die falsch ist? Die Leitern:

HL7 v2	FHIR
Wert	Wert
Feld / Komponente	Element
Segment	Ressource
Anordnung	Interaktion (HTTP-Methode + URL)
Bezugsdokument	Referenzgeflecht
	Profil

Dazu zwei Antworten außerhalb der Leiter: nirgends (die Aussage wird im Austausch überhaupt nicht gemacht) und unterhalb der Leiter (der Defekt sitzt auf der Transportschicht).

Das Verfahren

1. Die tragende Aussage in einem Satz formulieren. „Dieser Kontakt gehört zu diesem Patienten.” Nicht das Symptom, sondern die Behauptung.
2. Sprosse benennen — als Kategorie, nicht als Fundstelle.
3. Nachweis: Zeigen, was dieser Sprosse Bedeutung zuweist. Nicht dass dort etwas schiefgeht, sondern wodurch dort überhaupt etwas behauptet werden kann.
4. Alle übrigen Sprossen einzeln ausschließen, je ein Satz, jeder am konkreten Fall.
5. Prüfbarkeitsfrage: Wogegen wäre dieser Wert prüfbar? Die Antwort gegen nichts ist häufig und aussagekräftig.

Woran die Antwort scheitert

Fehler	Erkennungsmerkmal	Gegenmittel
Koordinate statt Kategorie	die Antwort ist ein Elementpfad	Gefragt ist die Sprosse. Der Pfad gehört in den Nachweis, nicht in die Antwort
Ausschluss über die falsche Achse	der Ausschlussgrund gilt auch für jedes andere Ticket	Test: Gilt mein Satz auch für ein fremdes Ticket? Dann schließt er nichts aus
Handlung als Sprosse	„der Defekt liegt im Verhalten von X”	Die Leiter verortet Aussagen. Eine Handlung steht auf keiner Sprosse
Betriebslücke als Sprosse	„die fehlende Validierung”	Fehlende Prüfung ist keine Ebene, sondern eine organisatorische Lücke
Bezugsdokument mit Papier verwechselt	ein Schnittstellenkonzept wird als „Profil” bezeichnet	In FHIR meint die Profil-Sprosse eine StructureDefinition, nichts anderes

Ein Ausschluss, der auch für ein anderes Ticket gilt, schließt nichts aus.

Durchgerechnet

Die tragende Aussage lautet: „Diese Ressource liegt unter dieser Adresse.” Sie wird auf der Sprosse Interaktion gemacht — konkret durch request.method zusammen mit request.url. Erst diese Kombination macht aus einer Zeichenkette eine Adressbehauptung; im Rumpf allein wäre derselbe Wert bloß ein Wert.

Ausschlüsse, jeder am Fall: Wert — SUED_778123 ist die korrekte Patientennummer, im selben Bundle steht sie an einer Stelle, an der sie einwandfrei ist. Element — identifier ist mit system und value richtig belegt. Ressource — Patient ist die richtige Ressourcenart, alle fachlichen Felder stimmen. Referenzgeflecht — es gibt in dieser Nachricht keine Verweise auf andere Ressourcen. Profil — kein Profil im Spiel; verletzt wird die Basisspezifikation.

Daraus der Kernsatz:

Nicht der Wert ist falsch, sondern seine Position. Ein Wert hat keine Gültigkeit an sich, sondern nur relativ zu dem Element, in dem er steht — derselbe Wert kann in derselben Nachricht gleichzeitig einwandfrei und ungültig sein.

---

(c) Einordnung ins Fehlerraster

Was die Frage will

Eine Kategorie mit zwei belegten Bedingungen, eine geprüfte Alternative und eine Trennlinie, die auch andere Fälle entscheidet.

Das Verfahren

1. Erste Frage: Ist die Nachricht angenommen worden? Wurde sie abgelehnt, ist es 1 oder 2 — unabhängig davon, wie interessant die Ursache ist. Die Kategorien 3 bis 6 setzen alle eine angenommene und verarbeitete Nachricht voraus.
2. Kategorie wählen und beide Bedingungen einzeln am Sachverhalt belegen. Bei zweiteiligen Bedingungen beide Hälften getrennt.
3. Die nächstliegende Alternative benennen — das ist die, deren Beschreibung auf den Mechanismus passt, nicht die, die zuletzt richtig war.
4. Ihre beiden Bedingungen ebenfalls prüfen und sagen, an welcher genau sie scheitert.
5. Trennlinie formulieren, ohne den Fall zu erwähnen.
6. Prüfen, ob mehrere Befunde vorliegen. Eine Nachricht trägt pro Aussage eine Kategorie, nicht insgesamt eine.

Woran die Antwort scheitert

Fehler	Erkennungsmerkmal	Gegenmittel
Bedingung beschrieben statt belegt	die Begründung wiederholt den Kategorientext	Einen Satz aus dem Ticket zitieren, der die Bedingung erfüllt
Nachweisspalte als Bedingung benutzt	„es ist ein Abgleichproblem Quelle↔Ziel”	Dieselbe Nachweisspalte steht bei 3 und 4. Ein gemeinsames Merkmal wählt nichts aus
Keine Alternative geprüft	„hier gibt es keine Alternative”	Wenn eine Kategorie offensichtlich wirkt, ist die Trennlinie erst recht fällig — sie prüft, ob die Offensichtlichkeit trägt
Trennlinie erwähnt den Fall	im Satz stehen Feldnamen aus dem Ticket	Eine Trennlinie hält zwei Kandidaten auseinander, ohne den Fall zu nennen
Schein-Ausschlussgrund	„beide Seiten arbeiten ja vertragskonform”	Konformität zum Vertrag schließt weder 4 noch 5 aus — sie ist deren Bedingung 1

Zwei operative Tests, die fast immer entscheiden:

Kann man den Fall heilen, ohne den Sender anzufassen? Ja → 4. Nein → 5. Ist die Information am Zielpunkt noch vorhanden, nur falsch gedeutet? Ja → höchstens 4. Nein → 6.

Und ein dritter, der 3 von allem trennt:

Ein ratender Empfänger produziert ein falsches Ergebnis, kein leeres. Wo etwas Falsches herauskommt, hat jemand gewählt. Wo nichts herauskommt, hat niemand gewählt — dann ist Bedingung 2 von Kategorie 3 nicht erfüllt.

Durchgerechnet

Erste Frage: Die Nachricht wird abgelehnt — 400, OperationOutcome, nichts wird geschrieben. Damit sind 3 bis 6 raus, bevor man über die Ursache nachdenkt.

Kategorie 2 — harter Fehler. Bedingung: Der Empfänger bricht ab. Beleg: Statuscode 400, OperationOutcome mit expression: Patient.id, Bundle in der Fehler-Queue, kein Teildatensatz (S4).

Nächstliegende Alternative: 4. Ihre Bedingung 2 ist sogar erfüllt — eine Patientennummer wird auf ein Zielelement abgebildet, für das sie nicht taugt, und zwar per unterschriebenem Bezugsdokument. Ihre Bedingung 1 scheitert: Der Sender erzeugt eine gegen die Basisspezifikation ungültige Ressource, also sind nicht beide Seiten konform.

Trennlinie:

Die Kategorien 3 bis 6 setzen voraus, dass die Nachricht angenommen und verarbeitet wurde. Wird sie abgelehnt, ist die Einordnung 1 oder 2 — unabhängig davon, wie interessant die Ursache ist. Die Ursache beschreibt die Reparatur, nicht die Kategorie.

Und die Reihenfolge, die daraus folgt: Erste Frage ist nicht „wo liegt der Fehler?”, sondern „ist die Nachricht angenommen worden?”

---

(d) Ersetzungsprobe

Vollständig auf der Seite Die Ersetzungsprobe. Hier nur die Bedienung in sechs Schritten, weil genau sie in der Praxis fehlt.

Das Verfahren, pro Kandidat

Schritt 0 — Welche Stelle ändert dieser Kandidat? Als Element oder Kettenglied benennen, nicht als Absicht.

Schritt 1 — Kommt diese Stelle in der Kausalkette vor? Nein → fertig: alle Zellen unverändert, Klasse steht, kein Weiterrechnen. Ja → weiter. Dieser Schritt erledigt die Hälfte aller Kandidaten in Sekunden.

Schritt 2 — Kette ab der geänderten Stelle neu rechnen, vorwärts. Die neuen Glieder hinschreiben.

Schritt 3 — Jede Beobachtung an der neuen Kette ablesen. Drei mögliche Werte:

	Bedeutung
kippt	die Beobachtung verschwindet oder dreht sich
unverändert	die neue Kette erzeugt sie weiterhin
kippt ins Negative	eine bisher unauffällige Beobachtung wird zum Defekt

Schritt 4 — Ergebnisklasse, aus dem Muster der ganzen Zeile. Erst jetzt, und genau eine pro Kandidat.

Schritt 5 — Irrelevanz-Test: Kann die auslösende Eigenschaft sich künftig beliebig ändern, ohne dass es das System berührt?

Erst danach, und nur bei wirksamen Kandidaten: Zufluss oder auch Bestand?

Zwei Regeln, die die häufigsten Fehler verhindern

Eine Beobachtung, die sich nicht ändert, ist ein Ergebnis — kein fehlendes Ergebnis. „Unverändert” ist eine vollständige Antwort.

Beobachtungen sind Messpunkte, keine Prüfsteine. Man liest an ihnen ab, was die Änderung bewirkt; man bewertet sie nicht danach, ob sie „für die Reparatur wichtig” sind.

Durchgerechnet — zwei Kandidaten mit gegensätzlichem Verdikt

Kandidat: „Der Adapter ersetzt den Unterstrich durch einen Bindestrich.”

Schritt 0: ändert Glied 2. Schritt 1: kommt vor. Schritt 2: Der Wert wird datentypkonform, Glied 5 lässt ihn passieren, Glied 6 entfällt. Schritt 3: S1 kippt · S2 unverändert · S3 unverändert (Aussage über die Vergangenheit, von keinem Kandidaten änderbar) · S4 kippt. Schritt 4: wirksam. Schritt 5: Ist der Zeichenvorrat der Quelle danach gleichgültig? Nein — der nächste Sonderfall trifft dieselbe Stelle. Ein Zufall wurde wiederhergestellt.

Kandidat: „Der Adapter stellt auf conditional update um — keine id im Rumpf, Adressierung über den Geschäftsidentifier.”

Schritt 0: entfernt Glied 2 und 3. Schritt 1: kommt vor. Schritt 2: Die Nummer landet in einem Suchparameterwert und wird prozentkodiert; die Adressvergabe liegt wieder beim Server. Schritt 3: S1 kippt · S2 unverändert · S3 unverändert · S4 kippt. Schritt 4: wirksam — dieselben Zellen wie oben. Schritt 5: Ist der Zeichenvorrat danach gleichgültig? Ja. Er gerät nie wieder in eine Position, in der er geprüft wird.

Zwei Kandidaten mit identischen Zellen und entgegengesetztem Verdikt. Genau diesen Unterschied macht der Irrelevanz-Test sichtbar, und die Zellen allein machen ihn nicht.

Bestand: Beide heilen nur den Zufluss. Die abgelehnten Sendungen liegen in der Fehler-Queue und sind nachfahrbar — ein harter Fehler kostet Zeit, ein stiller kostet Daten.

---

(e) Die eine Frage

Was die Frage will

Eine Tatsachenfrage, deren Antwort man braucht, bevor man entscheiden kann. Keine Maßnahme, keine Bitte, kein Vorschlag.

Das Verfahren

1. Selbstherstellungstest: Kann ich mir die Antwort selbst beschaffen — aus der Nachricht, dem Bestand, einem Testlauf? Dann ist es keine Frage an die Gegenseite.
2. Steht die Antwort schon im Ticket? Dann auch nicht.
3. Adressat aus der Kategorie ableiten, nicht aus der Gewohnheit. Bekannte Formen: der Empfänger · der Sender · die Strecke und ihr Bezugsdokument · die eigene Seite.
4. Auf die Bauweise zielen, nicht auf die Wirkung. Was zwei verschiedene Bauweisen in denselben Daten hinterlassen, muss erfragt werden — es ist aus den Daten nicht ableitbar.
5. Eine Achse pro Frage. Zwei Fragen in einem Satz bekommen eine halbe Antwort.
6. Geltungsbereich mitfragen: gilt es für diesen Fall, für alle Patienten, für den ganzen Verbund?
7. Drei mögliche Antworten durchspielen, jede mit ihrer Konsequenz. Mindestens eine muss die eigene Hypothese widerlegen können. Wenn alle drei Zweige beim selben Adressaten und derselben Maßnahme enden, trennt die Frage nicht.

Woran die Antwort scheitert

Fehler	Erkennungsmerkmal	Gegenmittel
Maßnahme statt Frage	„Bitte stellen Sie um auf …”	Die Frage endet mit einem Fragezeichen und verlangt eine Auskunft
Zwei Achsen in einem Satz	ein „und” in der Mitte	Aufteilen, die tragende zuerst
Kein widerlegbarer Zweig	alle drei Antworten bestätigen die Hypothese	Den Zweig suchen, der die eigene Kette kippt
Adressat aus Gewohnheit	„die Kunden-IT”, weil es immer die Kunden-IT war	Sender ist eine Rolle, kein System — wer hat die Nachricht abgeschickt, um die es geht?
Absicherung statt Klärung	die Frage zielt auf Dokumentation	Schließt mein Vorschlag die Lücke — oder macht er sie nur sichtbar?

Durchgerechnet

Adressat: die eigene Seite, abgeleitet aus Kategorie 2 — der Sender der abgelehnten Anfrage ist der eigene Adapter, nicht das KIS. Die Rolle „Sender” wechselt entlang der Strecke; sie hängt nicht am System, sondern an der Nachricht, um die gestritten wird.

Die Frage an das Haus: „Ist die Patientennummer über den gesamten Verbund eindeutig — oder nur innerhalb des jeweiligen Hauses?”

Antwort	Konsequenz
„nur je Haus”	Namensraum je Haus nötig; die Eindeutigkeit ruht bisher auf einem Präfix im Wert
„verbundweit eindeutig”	dann erklären, warum es das Präfix gibt
„dafür ist ja das Präfix da”	durch den Sachverhalt widerlegt — ein Präfix im Wert ist ein Namensraum, der die Feldgrenze nicht respektiert

---

(f) Messbarkeit und Kahn-Kategorien

Was die Frage will

Wo zeigt sich der Defekt in einem Bestand — und woran ließe er sich täglich zählen, ohne dass jemand einen Einzelfall kennt?

Das Verfahren

1. Messpunkte trennen: Quellbestand, Zielbestand, und gegebenenfalls die Auswertung, die jemand daraus baut.
2. Vorfrage für jeden: Existiert der Defekt in dem, was hier gemessen wird — oder entsteht er erst zwischen zwei Messpunkten?
3. Erst dann eine Kategorie suchen. Keine Kategorie ist eine vollständige und häufige Antwort.
4. Kennzahl formulieren, die ohne Fallkenntnis zählbar ist.
5. Artefaktfrage: Hinterlässt der Defekt etwas Zählbares — Statuscode, OperationOutcome, Queue-Eintrag?

Woran die Antwort scheitert

Fehler	Erkennungsmerkmal	Gegenmittel
Es muss doch etwas hin	für einen einwandfreien Bestand wird eine Kategorie gesucht	Die Vorfrage stellen. Ein Quellsystem, das korrekt liefert, trägt keine Kategorie
Strecke statt Bestand gemessen	die Kategorie beschreibt eine Übertragung	Kahn misst Bestände, nicht Strecken
Übertragungsartefakt als Attribut behandelt	„das Quellsystem speichert es falsch”	Prüfen, ob der fragliche Wert im Quellsystem überhaupt gespeichert ist oder erst beim Serialisieren entsteht

Ein Monitoring findet ausschließlich Fehlerklassen, die ein Artefakt hinterlassen. Alles andere braucht eine fachliche Gegenprobe — den Abgleich Quelle ↔ Ziel —, kein Monitoring.

Durchgerechnet

Quellbestand: einwandfrei, die Nummern sind im KIS korrekt und eindeutig. Keine Kategorie. Zielbestand: Completeness — ganze Patienten fehlen, nicht 18 % der Attribute. Kennzahl: Anteil abgelehnter Sendungen je Tag, gruppiert nach sendendem Haus.

Und der Sonderfall, der diesen Fall von allen stillen unterscheidet: Hier greift die Kategorie glatt — genau weil der Fehler laut ist.

Die Grenze des Rahmens verläuft nicht entlang der Schwere eines Defekts, sondern entlang der Frage, ob er ein zählbares Artefakt hinterlässt.

---

Die Prüfliste vor dem Absenden

1. Steht die Kausalkette als nummerierte Glieder da — und ist jede gemeldete Beobachtung aus ihr herleitbar?
2. Habe ich in dieser Antwort etwas bewiesen, das eine andere Teilfrage beantwortet — und darauf verwiesen?
3. Hat jede Antwort die Art, nach der gefragt wurde? Kategorie, wo eine Kategorie verlangt war; Person, wo nach wer gefragt wurde?
4. Gilt einer meiner Ausschlussgründe auch für ein fremdes Ticket?
5. Hat jeder Kandidat genau eine Ergebnisklasse und ein Reparaturverdikt?
6. Ist mindestens einer meiner drei Antwortzweige in (e) geeignet, meine eigene Hypothese zu widerlegen?
7. Habe ich für jeden Messpunkt in (f) die Vorfrage gestellt, bevor ich eine Kategorie gesucht habe?

Lektüre & Belege

• Diagnoseleitfaden — die Reihenfolge vom Symptom zum Befund
• Die sechs Fehlerkategorien — das Raster samt aller Abgrenzungen
• Die Ersetzungsprobe — Kandidaten-Matrix, Ergebnisklassen, Irrelevanz-Test
• Das Kahn-Framework — die Messseite und ihre Grenzen
• Sandbox: FHIR-Server zum Anfassen — dieselben Mechanismen ausführbar