06 - ACK und NACK im Detail

Vertiefung zu ACK, NACK und MLLP. Die Kurzfassung steht dort; hier steht, wie das Verfahren tatsächlich funktioniert. Zum Nachschlagen und zur Wiederholung. Der zugehörige Konzeptgedanke: Der ACK-Vertrag.

1. Wo die Quittung im Stapel sitzt

Vier Schichten, die gern verwechselt werden - jede kann melden „alles gut”, während die darüber liegende scheitert:

Schicht	Zusage	Beleg
TCP	Bytes sind angekommen	tcpdump, Socket-Status
MLLP	Ein Rahmen war wohlgeformt (0x0B … 0x1C 0x0D)	Framing-Log
Accept-ACK (CA/CE/CR)	Nachricht angenommen, Zuständigkeit übernommen	MSA-1
Application-ACK (AA/AE/AR)	Anwendung hat verarbeitet	MSA-1

Und darüber, von keiner Schicht abgedeckt: ob das Ergebnis stimmt. Dafür gibt es in HL7 v2 keinen Mechanismus, nur den Abgleich Quelle↔Ziel.

2. Wer den Modus bestimmt

Nicht die Konfiguration des Empfängers, nicht das Schnittstellenkonzept — die einzelne Nachricht. MSH-15 (Accept Acknowledgment Type) und MSH-16 (Application Acknowledgment Type) definieren laut Standard „the conditions under which acknowledgments are required to be returned in response to this message”.

Beide Felder sind also Anforderungen an den Empfänger, keine Zusagen des Senders. Wer MSH-16 setzt, sagt nicht „ich quittiere so”, sondern „so hast du mir zu quittieren”. Diese Richtung ist die häufigste Verwechslung im Gespräch mit einer Kunden-IT.

Zustand	Modus
MSH-15 und MSH-16 leer oder nicht vorhanden	Original Mode
mindestens eines gefüllt	Enhanced Mode

Werte aus HL7-Tabelle 0155 (für beide Felder gleich):

Wert	Bedeutung
AL	always — in jedem Fall quittieren
NE	never — nie quittieren
ER	nur bei Fehler/Reject quittieren
SU	nur bei Erfolg quittieren

Vereinbarungslücke

Was gilt, wenn im Enhanced Mode nur eines der beiden Felder gefüllt ist, buchstabiert der Standard nicht durchgehend aus. Das ist eine Stelle, die ins Schnittstellenkonzept gehört — nicht in eine Annahme.

3. Die beiden Abläufe

Original Mode

Sender                          Empfänger
  |  ADT^A01 (MSH-15/16 leer)      |
  |------------------------------->|
  |                                | validieren + verarbeiten
  |  ACK^A01  MSA|AA               |
  |<-------------------------------|

Eine Nachricht, eine Antwort. Der Empfänger verarbeitet vor dem Quittieren; das ACK trägt AA, AE oder AR. Einfach, aber die Verbindung hängt so lange, wie die Verarbeitung dauert.

Enhanced Mode

Sender                          Empfänger
  |  ADT^A01 (MSH-15=AL, MSH-16=AL)|
  |------------------------------->|
  |  ACK  MSA|CA   (sofort)        | sicher verwahrt
  |<-------------------------------|
  |                                | verarbeiten (evtl. viel später)
  |  ACK  MSA|AA   (asynchron)     |
  |<-------------------------------|

Zwei getrennte Antworten mit zwei getrennten Bedeutungen:

• CA Commit Accept — angenommen und sicher verwahrt, Zuständigkeit liegt jetzt beim Empfänger.
• CR Commit Reject — MSH-9 (Message Type), MSH-11 (Processing ID) oder MSH-12 (Version ID) ist nicht akzeptabel.
• CE Commit Error — jedes andere Annahmehindernis, typischerweise „kann ich gerade nicht sicher speichern”.

Erst die zweite Antwort trägt AA/AE/AR. Weil sie asynchron kommt, ist MSA-2 hier nicht Komfort, sondern die einzige Zuordnung.

Der häufigste Konfigurationsfehler

Ein mit MSH-15 = AL angeforderter Accept-ACK wird mit MSA-1 = AA beantwortet — einem Original-Mode-Code im Enhanced-Mode-Vertrag. Die meisten Kommunikationsserver akzeptieren das tolerant und schreiben „quittiert” ins Protokoll. Das ACK geht damit nicht verloren, es wird als Bestätigung fehlgelesen — und das ist der schlechtere Fall: eine verlorene Quittung fällt irgendwann auf, eine fehlgelesene nie.

4. Das MSA-Segment

Feld	Name	Typ	Status
MSA-1	Acknowledgment Code	ID	Pflicht — Tabelle 0008
MSA-2	Message Control ID	ST	Pflicht — spiegelt MSH-10 der Ursprungsnachricht
MSA-3	Text Message	ST	ab v2.7 zurückgezogen — nie maschinell auswerten
MSA-4	Expected Sequence Number	NM	optional, nur mit Sequenznummernprotokoll (MSH-13)
MSA-5	Delayed Acknowledgment Type	—	ab v2.5 zurückgezogen
MSA-6	Error Condition	—	ab v2.7 zurückgezogen — abgelöst durch ERR-3

MSA-2 wörtlich: „contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.”

Tabelle 0008 — alle Codes auf einen Blick:

Code	Stufe	Bedeutung
AA	Application	Application Accept — verarbeitet
AE	Application	Application Error — Fehler in Inhalt oder Format
AR	Application	Application Reject — Ablehnung aus inhaltsunabhängigem Grund
CA	Accept	Commit Accept — angenommen und verwahrt
CE	Accept	Commit Error — Annahmehindernis
CR	Accept	Commit Reject — MSH-9/-11/-12 nicht akzeptabel

5. AE vs. AR — die teuerste Unterscheidung im Betrieb

Die Trennlinie ist nicht „schlimm” gegen „weniger schlimm”, sondern inhaltsbezogen gegen inhaltsunabhängig:

	AE	AR
Ursache	Pflichtfeld fehlt, Datentyp falsch, Tabellenwert unbekannt	Anwendung nicht verfügbar, Datenbank down, Sequenzproblem
Ändert sich beim nächsten Versuch?	Nein — dieselbe Nachricht, dasselbe Ergebnis	Ja, möglicherweise
Richtige Reaktion	in eine nachverfolgbare Fehlerablage, kein Retry	Retry mit Backoff

Eine Retry-Schleife, die beide gleich behandelt, erzeugt genau eines von zwei Fehlerbildern:

• Retry auf AE → vergiftete Queue: eine kaputte Nachricht blockiert oder flutet den Kanal endlos.
• Kein Retry auf AR → stiller Verlust: eine heilbare Nachricht wird nach einer Minute Wartungsfenster verworfen.

6. Das ERR-Segment

Feld	Name	Typ	Anmerkung
ERR-1	Error Code and Location	—	ab v2.4 deprecated, ab v2.7 zurückgezogen
ERR-2	Error Location	ERL	Segment ^ Segmentwdh. ^ Feld ^ Feldwdh. ^ Komponente ^ Subkomponente
ERR-3	HL7 Error Code	CWE	Tabelle 0357
ERR-4	Severity	ID	Tabelle 0516
ERR-5	Application Error Code	CWE	herstellereigen
ERR-6	Application Error Parameter	ST	herstellereigen
ERR-7	Diagnostic Information	TX	Freitext
ERR-8	User Message	TX	Freitext für Anwender

Tabelle 0357 (Auszug, die praxisrelevanten):

Code	Bedeutung
0	Message accepted
100	Segment sequence error — Segmente in falscher Reihenfolge oder Pflichtsegment fehlt
101	Required field missing
102	Data type error
103	Table value not found
104	Value too long
199	Other HL7 Error
200–203	Unsupported message type / event code / processing ID / version ID
204–206	Unknown key identifier / duplicate key identifier / application record locked
207	Application internal error

Tabelle 0516 — Severity: I Information · W Warning (Teile der Nachricht wurden womöglich nicht gespeichert) · E Error · F Fatal Error.

Warum NACKs kaum automatisierbar sind

Tabelle 0357 kennt nur Klassen. 101 sagt „ein Pflichtfeld fehlt”, nicht welches — dafür wäre ERR-2 da, das in der Praxis oft leer bleibt. Die eigentlich diagnostische Information landet in ERR-5 und ERR-7, und die sind nicht standardisiert. Jede Automatik, die NACK-Inhalte auswertet, ist damit faktisch eine Herstellerbindung. Belastbar automatisierbar ist genau eines: dass ein NACK kam.

7. Beispiele (synthetisch)

Original Mode, Erfolg:

MSH|^~\&|PORTAL|KH-NORD|KIS|KH-NORD|20260813071502||ACK^A01^ACK|PT0000991|P|2.5
MSA|AA|KN0000123

Enhanced Mode, erste Antwort (Accept):

MSH|^~\&|PORTAL|KH-NORD|KIS|KH-NORD|20260813071501||ACK^A01^ACK|PT0000990|P|2.5
MSA|CA|KN0000123

NACK mit lokalisierter Fundstelle:

MSH|^~\&|PORTAL|KH-NORD|KIS|KH-NORD|20260813071502||ACK^A01^ACK|PT0000992|P|2.5
MSA|AE|KN0000123
ERR||PID^1^3^1^4|101^Required field missing^HL70357|E|||Assigning Authority in PID-3.4 nicht gesetzt

ERR-2 liest sich hier als: Segment PID, erste Segmentwiederholung, Feld 3, erste Feldwiederholung, Komponente 4. Das ist die einzige Angabe in diesem NACK, die ein Empfänger ohne Herstellerdokumentation verarbeiten kann.

Ablehnung wegen nicht unterstützter Version:

MSA|CR|KN0000123
ERR||MSH^1^12|203^Unsupported version id^HL70357|E

8. Diagnose-Checkliste: „Bei uns ist alles quittiert”

Der Satz fällt in fast jeder Fehlersuche. Er ist meistens wahr und fast nie relevant. Vier Fragen, in dieser Reihenfolge:

1. Welcher Modus? MSH-15 und MSH-16 der tatsächlich gesendeten Nachricht ansehen — nicht die Doku, nicht das Konzept, die Nachricht.
2. Welche Stufe wurde quittiert? Bei MSH-16 = NE beweist ein volles Protokoll nur Zustellung und Annahme. „Null NACKs” ist dann keine Beobachtung, sondern eine Tautologie: Es gab keinen Kanal, auf dem je einer hätte erscheinen können.
3. Wer hat quittiert? Sitzt ein Kommunikationsserver dazwischen, quittiert oft er — sein AA sagt nichts über das Zielsystem dahinter.
4. Gegenprobe zur Ursache: Den vermuteten Defekt gedanklich durch die korrekte Variante ersetzen. Verschwindet das Symptom? Wenn nein, war es nicht die Ursache, sondern ein Nebenbefund.

Ergibt sich daraus, dass der Rückkanal fehlt, gibt es genau zwei Auswege — und beide gehören schriftlich ins Schnittstellenkonzept:

• MSH-16 auf AL und ein echtes Application-ACK, oder
• ein ausdrücklich benannter zweiter Nachweisweg: Abgleich Quelle↔Ziel, Zählerabgleich, Stichprobe.

Ohne eines von beidem ist die Strecke nicht bloß unbeobachtet, sondern unbelegbar.

9. Wiederholung

Warum ist ein CA keine schwächere Form von AA?

Weil es etwas anderes zusagt. CA = „ich habe die Nachricht angenommen und bin ab jetzt zuständig”. AA = „meine Anwendung hat sie verarbeitet”. Zwischen beiden liegt die gesamte Verarbeitung — und wenn MSH-16 auf NE steht, wird die zweite Aussage nie nachgereicht.

Ein Haus meldet: 100 % Quittungsquote, null NACKs, trotzdem fehlen 2 % der Fälle. Was ist zuerst zu prüfen?

MSH-16 der gesendeten Nachrichten. Steht dort NE, hat der Sender selbst erklärt, keine Aussage über die Verarbeitung zu wollen. Das Protokoll belegt dann ausschließlich Zustellung und Annahme — der Verlust findet dahinter statt und ist für den Sender konstruktionsbedingt unsichtbar.

Warum darf man auf AE nicht dieselbe Retry-Logik anwenden wie auf AR?

AE bezeichnet einen Fehler in Inhalt oder Format. Dieselbe Nachricht wird beliebig oft dasselbe Ergebnis liefern; ein Retry blockiert oder flutet den Kanal. AR bezeichnet eine inhaltsunabhängige Ablehnung — dort ist ein späterer Versuch genau richtig.

Welches Feld verbindet eine asynchrone Application-Quittung mit ihrer Ursprungsnachricht?

MSA-2. Es spiegelt MSH-10 der Ursprungsnachricht. Im Enhanced Mode ist das die einzige Zuordnung, weil die zweite Antwort beliebig viel später und außerhalb der ursprünglichen Verbindung kommen kann.

Ein NACK trägt ERR-3 = 101. Reicht das zur Fehlerbehebung?

Nein. Tabelle 0357 kennt nur Klassen — 101 sagt „ein Pflichtfeld fehlt”, nicht welches. Die Fundstelle steht in ERR-2, das oft leer bleibt; die eigentliche Diagnose in ERR-5/ERR-7, die nicht standardisiert sind.

Sind MSH-15 und MSH-16 Zusagen des Senders?

Nein — Anforderungen an den Empfänger. Sie legen die Bedingungen fest, unter denen der Empfänger zu quittieren hat. Der Sender quittiert in diesem Austausch überhaupt nicht.

---

Siehe auch: ACK, NACK und MLLP (Kurzfassung) · Konzept: Der ACK-Vertrag · Framing