Das Kahn-Framework in Schnittstellenstrecken

Konzept: ein Raster für die Ausprägung, nicht für die Ursache

Wer eine Störung untersucht, braucht zwei Beschreibungen: wodurch sie entstanden ist und wie sie sich in den Daten zeigt. Die sechs Fehlerkategorien beantworten das Erste. Das Kahn-Framework beantwortet das Zweite — es ordnet Datenmängel danach, wogegen sie messbar abweichen.

Die Trennung ist nicht akademisch. Ein Befund ohne Ursache lässt sich nicht abstellen, ein Befund ohne Ausprägung nicht messen — und was nicht gemessen wird, taucht in keinem Monitoring auf.

Kahn et al. (2016) haben die bis dahin uneinheitliche Terminologie der Datenqualitätsforschung zu drei Kategorien harmonisiert. Der Rahmen stammt aus der Sekundärnutzung von EHR-Daten — Forschung, Register, Auswertung — nicht aus dem Schnittstellenbetrieb. Er lässt sich übertragen, aber nicht bruchlos; siehe den Abschnitt über die Grenzen weiter unten.

Die drei Kategorien

Kategorie	Definition (Kahn et al. 2016)	Unterkategorien
Conformance	„Data quality features that describe the compliance of the representation of data against internal or external formatting, relational, or computational definitions.”	Value · Relational · Computational
Completeness	„Data quality features that describe the frequencies of data attributes present in a data set without reference to data values.”	—
Plausibility	Merkmale, die „the believability or truthfulness of data values” beschreiben.	Uniqueness · Atemporal · Temporal

Die Definition von Completeness enthält den Satz, den man am häufigsten falsch liest: Completeness misst Häufigkeiten, nicht Inhalte. Ein Feld, das in jeder Nachricht belegt und in jeder Nachricht falsch ist, ist vollständig. Wer „vollständig” sagt und „richtig” meint, hat die Kategorie verwechselt.

Zwei Kontexte: Verification und Validation

Quer zu den Kategorien liegt die Frage, wogegen geprüft wird:

• Verification — Prüfung gegen die eigenen Vorgaben: Modell, Metadaten, Profil, Systemannahmen, lokales Wissen. Ohne externe Referenz.
• Validation — Prüfung gegen einen externen Bezugspunkt: ein zweites System, eine amtliche Codeliste, eine Referenzverteilung, ein Goldstandard.

Ob das eine vollständige Matrix ergibt, wird in der Sekundärliteratur unterschiedlich dargestellt — das Book of OHDSI beschreibt Verification und Validation als zwei parallele Bewertungsmethoden statt als Kreuzung mit den Kategorien. Für die Praxis ist die genaue Lesart zweitrangig; entscheidend ist die Frage, die sich jedes Mal stellt: Prüfe ich gegen mein eigenes Regelwerk oder gegen die Wirklichkeit außerhalb davon?

Der Unterschied entscheidet über den Aufwand. Verification läuft im eigenen System und kostet nichts außer Implementierung. Validation braucht einen zweiten Datenbestand, einen Terminologieserver oder eine Referenzstatistik — und ist genau deshalb die Prüfung, die in Projekten regelmäßig fehlt.

---

Conformance

Value Conformance

„Are data elements in agreement with a prespecified, constraint-driven data architecture?”

Ein Wert verletzt Format, Datentyp oder Wertevorrat.

Verification — Beispiele aus der Strecke:

Befund	Wo
PID-8 (Administrative Sex) trägt einen Wert außerhalb HL7-Tabelle 0001	HL7 v2
Ein TS-Feld enthält 20260230 — syntaktisch ein Datum, kalendarisch keins	HL7 v2
Ein Z-Segment-Feld trägt einen Aktionscode außerhalb des vereinbarten Vorrats	HL7 v2
Encounter.status enthält einen Code außerhalb des required-ValueSets — die Ressource ist ungültig, nicht nur auffällig	FHIR
Ein identifier.system fehlt, der Wert steht ohne Namensraum da	FHIR
Eine Nachricht deklariert in MSH-18 einen Zeichensatz, den ihre Bytes nicht einhalten	HL7 v2

Validation — Beispiele:

Befund	Referenz
Ein ICD-10-GM-Code existiert im Haus, im amtlichen Jahresstand aber nicht mehr	amtliche Codeliste
Ein LOINC-Code stammt aus einer älteren Release und wurde inzwischen deprecated	Terminologieserver
Ein Code ist im Profil erlaubt, im nachgelagerten ValueSet des Empfängers nicht	ValueSet-Expansion

Die Voraussetzung, die im Namen steckt: prespecified. Ohne vereinbarte Werteliste ist Value Conformance nicht messbar — es gibt dann nichts, wogegen der Wert falsch sein könnte. Das ist kein theoretischer Fall: Bei lokal definierten Segmenten und Feldern ohne festgelegtes Bezugsdokument fällt diese Kategorie ersatzlos aus (siehe Das Z-Kürzel ist kein Namensraum).

Relational Conformance

„Are data elements in agreement with additional structural constraints imposed by the physical database structures that store data values?”

Beziehungen zwischen Objekten stimmen nicht — die Einzelwerte können dabei alle korrekt sein.

Verification:

• Ein Aufenthalt verweist auf eine Fallnummer, zu der kein Patient existiert
• Encounter.subject zeigt auf Patient/…, das im Zielsystem nicht angelegt ist
• Ein Bundle enthält eine interne Referenz, die auf keine fullUrl im selben Bundle auflöst
• Ein Beobachtungssegment steht ohne das Auftragssegment, zu dem es gehört
• Zwei Ressourcen referenzieren sich gegenseitig, aber nur eine ist angekommen

Validation:

• Referenzintegrität nach dem Transport: Beide Nachrichten waren für sich korrekt, aber die Reihenfolge kippte — der Aufenthalt traf vor dem Patienten ein, und das Zielsystem hat die Beziehung verworfen statt gewartet. Bei parallel arbeitenden Queues der häufigste Fall.

Dieser Untertyp ist der am meisten unterschätzte: Er entsteht regelmäßig erst durch die Strecke, obwohl an der Quelle alles konsistent war.

Computational Conformance

„Do computations used to create derived values from existing variables yield the intended results either within a data set (Verification) or between data sets (Validation)?”

Abgeleitete Werte stimmen nicht mit ihrer Berechnungsgrundlage überein.

Verification:

• Ein übermitteltes Alter passt nicht zum übermittelten Geburtsdatum
• Eine mitgelieferte Verweildauer passt nicht zu Aufnahme- und Entlasszeitpunkt
• Ein Zielsystem berechnet dieselbe Kennzahl aus anderen Feldern als das Quellsystem

Validation:

• Dieselbe Kennzahl weicht zwischen zwei Systemen ab, weil sie auf unterschiedlichen Basisfeldern beruht — etwa Verweildauer aus dem administrativen Entlasszeitpunkt gegen Verweildauer aus der letzten Bewegung

Der Sonderfall, der als Rechenfehler auftritt und keiner ist: fehlende oder falsche Zeitzonen-Offsets. Eine Verweildauer verschiebt sich um Stunden, Tagesgrenzen kippen, und die Berechnung selbst ist dabei fehlerfrei. Der Defekt sitzt im Eingangswert, zeigt sich aber in der Ableitung.

---

Completeness

„Data quality features that describe the frequencies of data attributes present in a data set without reference to data values.”

Verification:

• Anteil der Fälle ohne Aufnahmezeitpunkt
• Anteil der Bewegungsnachrichten ohne das Segment, das die Bewegungs-ID trägt
• Ein im Profil als Must Support gekennzeichnetes Element ist in keiner einzigen Ressource belegt
• Ein Feld, das seit einem Release-Wechsel in 100 % der Nachrichten leer ist

Validation — und hier liegt der Kern:

• Zählabgleich Quelle ↔ Ziel. 1.284 Bewegungen im Quellsystem, 1.279 im Ziel.

Ohne diese Gegenzählung ist Completeness in einer Schnittstellenstrecke nicht feststellbar, weil ein nicht angekommener Datensatz keine Spur hinterlässt. Er erzeugt keinen Wert, der auffällig wäre, keinen Logeintrag und keine Quittung — die Quittung galt einer Nachricht, die nie gesendet oder still verworfen wurde. Das ist der Grund, warum der Abgleich Quelle ↔ Ziel in keinem Betriebskonzept fehlen darf und trotzdem meistens fehlt.

Zwei häufige Verwechslungen:

1. Completeness ≠ Richtigkeit. Die Kategorie sieht Werte nicht an.
2. Completeness auf Feldebene ≠ auf Satzebene. „Alle Felder belegt” sagt nichts darüber, ob alle Sätze da sind. Die teureren Lücken liegen auf Satzebene.

---

Plausibility

Alle drei Untertypen haben eine Gemeinsamkeit, die sie von Conformance trennt: Die Werte sind formal gültig. Kein Parser, kein Schema, kein Profil schlägt an. Plausibility ist die Kategorie der Befunde, die nur auffallen, wenn jemand fachlich hinsieht.

Uniqueness Plausibility

„Do objects (entities, observations, facts) appear multiple times in settings where they should not be duplicated?”

Verification:

• Derselbe Patient existiert zweimal, weil eine Zusammenführungsnachricht nicht verarbeitet wurde
• Dieselbe Bewegung erscheint zweimal, weil eine Wiederholung mangels stabiler Bewegungs-ID nicht als Dublette erkennbar war
• Zwei Aufenthalte tragen dieselbe Fallnummer

Validation:

• Abgleich gegen einen Master Patient Index oder ein führendes Identitätssystem

Der Mechanismus dahinter steht in PV1 und die Fallidentität: Es gibt keinen nachrichtenübergreifenden Zähler. Dubletten entstehen fast immer aus einem Identifier, der sich geändert hat oder gefehlt hat — nicht aus einem Zählfehler.

Atemporal Plausibility

„Do observed data values, distributions, or densities agree with local or ‚common’ knowledge?”

Verification — der Wert selbst ist unmöglich oder unwahrscheinlich:

• Eine Verweildauer von 412 Tagen auf einer Station mit typischer Liegedauer von zwei Tagen
• Ein Geburtsjahr 1899 bei einem aktiven Fall
• Ein Aufenthaltsort, den es im Bettenplan nicht gibt
• Ein Fall mit 40 Diagnosen

Validation — die Verteilung stimmt nicht:

• Der Anteil ambulanter Fälle springt binnen einer Woche von 30 auf 70 % — nicht weil sich die Versorgung geändert hat, sondern weil eine Feldbelegung umgestellt wurde
• Die Geschlechterverteilung einer Fachabteilung weicht deutlich von der Vorjahresstatistik ab

Der zweite Fall ist der wertvollere und wird selten gemessen: Verteilungsbrüche sind der zuverlässigste Frühindikator für Konfigurationsänderungen an der Quelle — sie zeigen sich, bevor jemand ein Ticket schreibt.

Temporal Plausibility

„Do time varying variables change values as expected based on known temporal properties?”

Verification:

• Eine Entlassung liegt vor der zugehörigen Aufnahme
• Eine Bewegung datiert nach dem Entlasszeitpunkt
• Zwei Aufnahmen ohne dazwischenliegende Entlassung
• Ein abgeschlossener Aufenthalt rutscht in einer Zeitleiste an die Spitze, weil ein Aktualisierungsereignis mit aktuellem Zeitstempel auf ihn angewandt wurde (siehe A08 vs. A31)

Validation:

• Das Nachrichtenaufkommen einer Strecke bricht gegenüber der Vorwoche ein — nachts vollständig, tagsüber um ein Drittel
• Eine Tageskurve verschiebt sich um exakt eine Stunde nach einer Zeitumstellung

Dies ist die einzige Kategorie, die Stille entdeckt. Ein Ausfall, bei dem gar nichts mehr ankommt, erzeugt keinen falschen Wert, keine Dublette und keinen Konformitätsverstoß — er erzeugt nur die Abwesenheit von Bewegung über die Zeit. Wer Silent Failures messen will, misst hier oder gar nicht.

---

Wie die beiden Raster zusammenhängen

Die Zuordnung von Ursache zu Ausprägung ist n:m, nicht 1:1. Dieselbe Ursache kann verschiedene Ausprägungen erzeugen, und dieselbe Ausprägung entsteht aus verschiedenen Ursachen.

Fehlerkategorie (Ursache)	Typische Kahn-Ausprägungen
1 Transportausfall	Completeness · Temporal Plausibility
2 Harter Fehler	Completeness (der Satz fehlt) — der auslösende Verstoß selbst ist meist Value Conformance
3 Empfänger rät	Value Conformance · Atemporal Plausibility · Uniqueness Plausibility
4 Mapping-Fehler	Value Conformance · Relational Conformance · Completeness (ein Feld fällt weg)
5 Ungewollte Aussage	Atemporal · Temporal Plausibility — selten Conformance, weil die Nachricht formal einwandfrei ist
6 Unterhalb des Vertrags	Completeness · Temporal Plausibility

Merksatz für die Befundformulierung:

Ursache aus dem Sechserraster, Ausprägung aus Kahn, Nachweisweg dazu. Ein Befund ohne alle drei Angaben ist unvollständig: „Feld fehlt” sagt nichts über die Ursache, „Framing-Fehler” nichts über die Auswirkung im Datenbestand, und beides zusammen nichts darüber, wie man es zeigt.

Was das Framework nicht leistet

Fünf Grenzen, die man kennen muss, bevor man es einem Kunden gegenüber als Messsystem anbietet.

1. Es benennt keine Ursachen. „Value Conformance verletzt” sagt nichts darüber, wer den Defekt erzeugt hat und auf welcher Seite er repariert wird.
2. Es liefert keine Schwellwerte. Ob 3 % fehlende Entlasszeitpunkte akzeptabel oder alarmierend sind, steht nirgends im Rahmen. Schwellwerte sind eine fachliche Festlegung und gehören ins Betriebskonzept.
3. Es setzt eine Spezifikation voraus. Conformance ist ohne vereinbarte Vorgabe nicht messbar. Fehlt sie, bleibt nur Plausibility — und die ist ohne Referenzverteilung Meinung.
4. Es misst einen Datenbestand, keine Strecke. Ein Fehler, der Quelle und Ziel gleichermaßen betrifft, ist in keiner der Kategorien sichtbar. Deshalb braucht der Abgleich Quelle ↔ Ziel eine unabhängige Quelle, nicht denselben Export zweimal.
5. Es kennt keine Kategorie für „kam nie an”. Der Rahmen ist für ruhende Datenbestände entworfen. In einer Strecke ist der häufigste Betriebsfehler ein Satz, der nie eingetroffen ist — er erscheint hier nur indirekt, als Completeness- und als Temporal-Plausibility-Befund, und beide erkennen ihn nur mit einem Gegenwert von außen.

Punkt 5 ist der Grund, warum die beiden Raster nebeneinander stehen und nicht ineinander aufgehen.

Portalbezug

Patientenportale zeigen Daten direkt dem Patienten. Damit verschiebt sich die Gewichtung: Ein Conformance-Verstoß führt meist zu einer abgewiesenen Nachricht und fällt auf. Ein Plausibility-Befund — eine Bewegung in der falschen Reihenfolge, ein Aufenthalt, den es nicht gab, ein doppelter Termin — wird angezeigt und vom Patienten gelesen, bevor irgendein Monitoring anschlägt. Für patientensichtbare Strecken sind Temporal und Uniqueness Plausibility deshalb keine nachgelagerten Qualitätskennzahlen, sondern Betriebsüberwachung.

Messpraxis — was sich täglich zählen lässt

Ein brauchbares Minimum, ohne Werkzeuganschaffung:

Kennzahl	Kategorie	Aufwand
Nachrichten je Typ und Stunde, gegen die Vorwoche	Temporal Plausibility	gering, entdeckt Stille
Satzzahlen Quelle gegen Ziel, je Objekttyp und Tag	Completeness	mittel, braucht Quellzugriff
Anteil abgewiesener Nachrichten mit Grund	Value Conformance	gering
Ins Leere zeigende Referenzen im Ziel	Relational Conformance	mittel
Objekte mit identischem fachlichem Schlüssel	Uniqueness Plausibility	gering
Verteilung einer Leitgröße gegen den Vormonat	Atemporal Plausibility	gering, hoher Frühwarnwert
Datensätze mit unmöglicher Zeitreihenfolge	Temporal Plausibility	gering

Die erste und die letzte Zeile zusammen decken den größten Teil der stillen Fehler ab und kosten am wenigsten. Wer nur zwei Kennzahlen einführen kann, nimmt diese beiden.

---

Transfer

Auswertende Systeme — Register, Kennzahlensysteme, Modelle — sehen die Nachricht nicht mehr, aus der ein Datensatz entstanden ist. Sie sehen nur das Ergebnis, und in diesem Ergebnis ist ein Übertragungsdefekt nicht mehr von einer Dokumentationsrealität unterscheidbar. Genau an dieser Stelle wird das Kahn-Framework nützlich und gleichzeitig unzureichend: Es beschreibt präzise, was mit den Daten nicht stimmt, und schweigt darüber, wo auf dem Weg es passiert ist.

Daraus die praktische Konsequenz: Datenqualität ist keine Eigenschaft eines Datenbestands, sondern eines Übergangs. Gemessen werden muss deshalb an jedem Übergang, nicht nur am Ende — sonst misst man die Summe aller Defekte und kann keinen einzelnen zuordnen.

Fragen an die Kunden-IT

1. Welche der sieben Ausprägungen (drei Conformance, Completeness, drei Plausibility) messt ihr heute — und mit welcher Kennzahl?
2. Gibt es einen Zählabgleich auf Satzebene zwischen Quell- und Zielsystem, und aus welcher Quelle stammt die Vergleichszahl?
3. Welche Prüfungen laufen gegen eine externe Referenz (Codeliste, zweites System, Referenzverteilung) statt nur gegen das eigene Modell?
4. Wo sind Schwellwerte festgelegt, ab denen eine Abweichung ein Ticket erzeugt — und wer hat sie fachlich bestätigt?
5. Wie würdet ihr merken, dass eine Strecke seit drei Stunden nichts mehr liefert? (Antwort „am Monitoring” reicht nicht — welche Größe wird beobachtet?)

Regel fürs Schnittstellenkonzept

Zu jeder Strecke ist festzuhalten, welche Kahn-Ausprägungen auf ihr überhaupt messbar sind und mit welcher Kennzahl. Ausprägungen ohne Kennzahl sind kein Restrisiko, sondern eine offene Anforderung. Und: Für jede Conformance-Prüfung ist das Dokument zu benennen, gegen das geprüft wird — ohne Bezugsdokument ist Conformance keine Messgröße.

Lektüre & Belege

• Kahn MG, Callahan TJ, Barnard J et al. (2016), A Harmonized Data Quality Assessment Terminology and Framework for the Secondary Use of Electronic Health Record Data, eGEMs 4(1):1244 — PDF · PubMed
• The Book of OHDSI, Kapitel 15 „Data Quality” — ohdsi.github.io — Anwendung des Rahmens auf ein konkretes Datenmodell, mit Beispielprüfungen

Querverweise: Die sechs Fehlerkategorien · Diagnoseleitfaden · Das Z-Kürzel ist kein Namensraum · A08 vs. A31 · PV1 und die Fallidentität · Der ACK-Vertrag