FHIR braucht Datenqualitätsprofile

Garbage in, garbage out

Jemand möchte eine klinische Qualitätsmessung über Ihre FHIR-Daten durchführen – beispielsweise eine HEDIS-artige Messung, die in CQL geschrieben ist, oder ein Diabetes-Dashboard, oder eine Kohorte für eine Studie. Er zieht einige Millionen Ressourcen über einen Bulk FHIR-Export, richtet seine Logik darauf aus und erhält eine Zahl zurück.

Sollte er dieser Zahl vertrauen?

Alles wurde gegen US Core validiert. Jede Referenz aufgelöst. Der Validator war von oben bis unten grün. Und dennoch: Vielleicht enthalten 40 % der Laborbeobachtungen keinen numerischen Wert. Vielleicht haben die Hälfte der Patienten überhaupt keine Encounters. Vielleicht wurde eine Charge von Körpergewichtsangaben in Pfund geliefert, obwohl das Profil Kilogramm erwartet – eine vollständig konforme Quantity, die eine vollständig falsche Zahl enthält. Vielleicht fehlt jedem Patienten, der ein Diabetes-Medikament erhält, eine entsprechende Diabetesdiagnose, weil das Quellsystem diese in einer Tabelle aufbewahrte, die niemand gemappt hat.

Nichts davon verletzt eine einzige Profilregel. Alles fließt direkt in die Messung ein und verschiebt das Ergebnis still und heimlich. Garbage in, garbage out – nur ist der Müll hier unsichtbar, weil jedes Byte davon wohlgeformtes FHIR ist. Und die ehrliche Antwort auf die Frage „Wie viel von diesen Daten ist falsch?" ist heute ein Schulterzucken.

Das setzt noch voraus, dass die Daten überhaupt dort sind, wo Sie gesucht haben. FHIR bietet mehr als einen gültigen Weg, dieselbe klinische Tatsache zu erfassen. Die Diabetesdiagnose eines Patienten könnte in einer Condition stecken, oder als Observation mit einem diagnostischen Code, oder nur durch eine MedicationRequest für Metformin oder eine Procedure impliziert werden. Eine Messung, die Condition abfragt und nichts weiter, liegt nicht falsch – sie übersieht nur stillschweigend jeden Patienten, dessen Diabetes auf die andere Weise modelliert wurde. Die Daten sind gültig und konform, nur nicht dort, wo die Logik nachgeschaut hat, und kein Validator wird Sie darauf hinweisen.

Dies ist kein Hygieneproblem, das man später bereinigen kann. Es ist genau das, was zwischen FHIR-Daten und jedem Anwendungsfall steht, der ihre Erhebung motiviert hat – Analytics, Qualitätsmessung, Forschung, ein Modell.

FHIR profiliert die Instanz, nicht den Datensatz

Der erste Instinkt ist, nach Profilen zu greifen – und Profile sind tatsächlich ein Teil der Antwort, nur nicht der Teil, den die meisten erwarten. Ein Profil ist der Ort, an dem die Community eine Repräsentation vereinbart: dass Diabetes in Condition gehört, aus diesem ValueSet kodiert, mit diesen vorhandenen Elementen. Das ist genau die Mehrdeutigkeit aus dem Einstieg, die damit festgelegt wird – ohne ein Profil hat jeder Datensatz eine andere Form, und keine gemeinsame Prüfung ist überhaupt formulierbar. Profile sind das Fundament, auf dem dieser gesamte Ansatz aufbaut.

Aber ein Profil ist eine Vereinbarung, kein Audit – und FHIR-Profile sind by Design permissiv. Die meisten Elemente bleiben optional; Must-Support verlangt von einem System lediglich, ein Feld unterstützen zu können, ohne jemals einen Wert zu erfordern; Bindings sind häufig erweiterbar; Ventile wie data-absent-reason sind eingebaut. Diese Offenheit ist bewusst, damit reale Daten fließen können. Daher beschreibt ein Profil die Form guter Daten, ohne anzugeben, wie viele Ihrer Daten diese Form tatsächlich ausfüllen – ein Vertrag, keine Messung.

Und selbst die Regeln, die ein Profil tatsächlich durchsetzt, durchsetzt seine Engine eine Ressource nach der anderen. Der Validator hat keinen Begriff von einer zweiten Ressource, geschweige denn von zehn Millionen. Die Fragen, auf die es hier am meisten ankommt, sind daher genau diejenigen, die er nicht stellen kann:

• Wie hoch ist der Anteil von Observation.value, der null ist? (eine Rate, keine Regel)
• Wiederholt sich ein Identifier über zwei Patienten hinweg? (Eindeutigkeit überspannt Datensätze)
• Liegt unsere Diabetesprävalenz bei 0,1 %, obwohl sie nahe 10 % liegen sollte? (eine Verteilung)
• Haben Patienten, die Metformin erhalten, eine passende Diagnose? (ein Join)

Ein Validator kann konstruktionsbedingt nicht zählen. Kein Profil wird jemals ausdrücken „Nullwerte unter 5 % sind akzeptabel", weil ein Profil kein Konzept von wie viele hat.

Diese Asymmetrie ist das gesamte Argument in einem Bild. FHIR bietet Ihnen ein reichhaltiges Instanzprofil – eine StructureDefinition, die beschreibt, wie eine wohlgeformte Ressource aussieht – und nichts für das Datensatzprofil: keinen Standardweg, um festzulegen oder zu prüfen, wie eine gute Sammlung dieser Ressourcen aussieht. Alles Folgende handelt davon, diese fehlende Hälfte zu bauen.

Man kann beobachten, wie sich das in der Community abspielt. Es gibt einen Thread mit 109 Nachrichten auf chat.fhir.org – neunzehn Teilnehmende, darunter einige der erfahrensten Personen im Ökosystem – die durcharbeiten, was ein System mit einem Period tun soll, dessen Ende vor dem Start liegt. Reale Daten aus einer realen EHR-Konvertierung. Die Debatte dreht sich darum, ob man es senden, verwerfen, in eine Extension verschieben oder als unzuverlässig kennzeichnen soll. Es ist eine sorgfältige, durchdachte Diskussion.

Und jedes Wort davon handelt von einem einzigen fehlerhaften Zeitraum. Niemand fragt auch nur einmal, welcher Anteil der Zeiträume im Datensatz invertiert ist, weil es keine Möglichkeit gibt, diese Frage zu stellen.

Schlimmer noch: Die Schlussfolgerung, zu der die Community immer wieder gelangt, vergrößert die Lücke. Wenn die akzeptierte Praxis bei fehlerhaften Daten darin besteht, diese aus dem berechenbaren Element in eine Extension zu verschieben oder die Ressource mit einem Integritäts-Security-Tag zu kennzeichnen, dann kann ein vollständig konformer Datensatz by Design mit unbrauchbaren Daten gefüllt sein. Konformität deckt das Problem nicht auf. Sie absorbiert es.

Pflichtfeld, vorhanden und leer

Die schärfste Version davon ist die data-absent-reason Extension. Markieren Sie ein Element als 1..1, und man könnte meinen, Sie hätten einen Wert garantiert. Das haben Sie nicht. Eine Mindestkardinaliät wird erfüllt, wenn das Element lediglich vorhanden ist – und ein Element, das nichts außer einem leeren data-absent-reason trägt, ist vorhanden. Der Validator zählt es, die Ressource besteht die Prüfung, und es wurde nie ein Wert geliefert.

Dies ist keine Lücke, die jemand vergessen hat zu schließen; sie wurde bewusst aus US Core übernommen als Ventil für Legacy-, externe und geschwärzte Daten. Implementierende sind in der Praxis darauf gestoßen – ein Pflichtfeld, das durch einen absent-reason und nichts weiter erfüllt wird – und die Community selbst ist der Meinung, dass dies den Sinn der Pflichtfeldmarkierung still und leise unterläuft. Der vorgeschlagene Abhilfeansatz ist ein weiteres Invariant auf Instanzebene, das pro IG geschrieben und durchgesetzt wird und die Extension dort verbietet, wo ein echter Wert erwartet wird.

Beachten Sie, was das kostet. Um zu wissen, ob Ihre 1..1-Felder tatsächlich Daten enthalten, können Sie dem grünen Häkchen nicht vertrauen – Sie müssen fragen, welcher Anteil davon hinter einem absent-reason steckt statt hinter einem Wert. Das ist eine Rate über den gesamten Datensatz. Ein Profil kann sie nicht berechnen. Eine Abfrage schon.

Die Lücke zeigt sich sogar dort, wo man am ehesten eine Lösung erwarten würde. Da Vinci DEQM – das IG für den Austausch von Qualitätsmessdaten – hat einen Abschnitt mit dem Titel Data Quality. Sein Inhalt, vollständig, lautet, dass Messungen definierte Profile wie US Core oder QI-Core verwenden sollen, damit ausgetauschte Daten standardisiert und für die Auswertung geeignet sind. Keine Schwellenwerte. Keine Raten. Keine Aggregate. Kein einziger Mechanismus zur Beurteilung der Qualität – nur wieder Profile, dasselbe Werkzeug, das die Frage nicht beantworten kann.

Das ist also kein Argument gegen Profile – es ist ein Argument für eine zweite Art. Das Instanzprofil bleibt die Quelle der Wahrheit dafür, was eine gültige Ressource ist; ein Datensatzprofil misst, wie viele Ihrer Daten tatsächlich daran gemessen werden. Das eine gehört der Instanz, das andere dem Datensatz.

Jeder andere Datenstapel testet seine Daten bereits

Schaut man über das Gesundheitswesen hinaus, ist dieses Problem nicht nur gelöst – es ist selbstverständlich. Das Testen von Daten ist eine Standardstufe in jeder ernsthaften Analytics-Pipeline, und der Mechanismus ist immer derselbe und immer so einfach: Eine Prüfung ist eine Abfrage, die die Zeilen zurückgibt, die eine Regel verletzen. Null Zeilen – die Daten bestehen. Beliebige Zeilen – diese Zeilen sind das Problem.

Dieselbe Idee wird unter verschiedenen Namen in allen wichtigen Tools eingesetzt:

Schauen Sie, was sie alle prüfen: Werte vorhanden, Schlüssel eindeutig, Zahlen in einem akzeptierten Bereich, Referenzen, die aufgelöst werden, Verteilungen, die stimmen. Dieselbe kurze Liste überall – weil Daten auf dieselbe Handvoll von Weisen schiefgehen, unabhängig von der Domäne. Das ist ein ausgereifter, tragender Teil des Data Engineering, keine Randdisziplin.

OMOP hat dies vor einem Jahrzehnt in Gesundheitsdaten übertragen

Die Gesundheitsanalytik hat diesen Sprung bereits gemacht. OHDSIs Data Quality Dashboard wendet dasselbe Muster – eine Abfrage pro Prüfung – auf klinische Daten an: Richten Sie es auf eine OMOP CDM-Datenbank, es führt Tausende von Prüfungen durch und liefert einen bewerteten Bericht zurück. In dieser Welt würde niemand einen Datensatz ohne einen solchen veröffentlichen.

Was OMOP hinzufügt, ist eine Taxonomie der Wege, auf denen Gesundheitsdaten spezifisch schiefgehen – das Kahn-Framework, das jede Prüfung in drei Fragen einordnet:

Zwei Mechanismen lassen es funktionieren. Erstens ist ein Prüfungstyp ein Template, keine Abfrage – ein not_null-Template expandiert über jedes Pflichtfeld jeder Tabelle, so dass etwa zwei Dutzend Templates zu Tausenden konkreter Prüfungen werden. Zweitens trägt jede Prüfung einen Schwellenwert: Fehlerhafte Zeilen unter 5 % bestehen, über 5 % schlagen fehl. Das macht diese Prüfungen fuzzy in einer Weise, wie es ein Invariant nie sein kann. Ein Invariant ist binär. Eine Datenqualitätsprüfung ist statistisch – und die Realität ist statistisch.

Diese Taxonomie ist auch keine OMOP-Eigenheit. Die NCQA Bulk FHIR Quality Coalition bewertet Bulk FHIR-Daten mit genau diesen drei Kategorien. Die Medizininformatik-Initiative Deutschlands bewertet FHIR-Datenqualität mit Kahn. PhUSE hat FHIR API-Daten für FDA-Einreichungen evaluiert auf demselben Framework. Das Vokabular ist etabliert – FHIR hat es nur nie aufgegriffen.

FHIR hat jetzt die Bausteine: SQLQuery + Extensions

Lesen Sie das Diagramm von links nach rechts, und Sie haben die gesamte Idee. Eine ViewDefinition flacht FHIR in eine Tabelle. Eine SQL-Abfrage über diese Tabelle gibt die Zeilen zurück, die eine Regel verletzen – dieselbe dbt-artige Prüfung, die jeder andere Stapel ausführt. Ein paar Extensions auf dieser Abfrage – Kahn-Kategorie, Schwellenwert, Schweregrad – verwandeln eine einfache Abfrage in eine bewertete Prüfung, die Sie auf einem Dashboard anzeigen können.

Das ist der gesamte Vorschlag: Eine Datenqualitätsprüfung ist eine SQLQuery plus drei Extensions. Keine neue Ressource, keine neue Operation, keine neue Engine – eine Prüfung ist strukturell identisch mit jeder anderen Abfrage, und die Extensions sind das Einzige, was sie zu einer Prüfung macht.

Keiner der Teile ist neu – jeder Baustein, den ein Datenqualitäts-Dashboard benötigt, ist bereits in der Spezifikation vorhanden:

Das ist das, was sich verändert hat. Ein DQD zu bauen war früher ein Infrastrukturprojekt – OHDSI brauchte eine eigene SQL-Engine, ein eigenes flaches Datenmodell, Jahre der Arbeit. SQL on FHIR standardisiert diese Schicht, so dass es in FHIR kein Infrastrukturproblem mehr ist. Es ist nur noch Inhalt: Schreiben Sie die Abfragen.

Und weil eine Prüfung nichts weiter ist als SQL über eine standardisierte flache View, ist sie eine Spezifikation, keine Implementierung. Dieselbe SQLQuery läuft auf Postgres, DuckDB oder Spark – oder kompiliert zu den Engines, die jedes Analytics-Team bereits betreibt: ein dbt-Test, eine Deequ-Constraint, eine Great Expectations-Suite. Das ist der gesamte Grund für die Standardisierung. Nicht um eine weitere Datenqualitäts-Engine zu bauen – FHIR braucht keine – sondern um dem Ökosystem einen portablen, herstellerneutralen Weg zu geben, wie ein guter FHIR-Datensatz aussieht, einmal erstellt und überall ausgeführt.

Dies ist kein Gedankenexperiment. Beim jüngsten HL7 Vulcan Connectathon haben wir es durchgeführt: eine FHIR-zu-OMOP-Transformation, die ausschließlich aus diesen Primitiven aufgebaut wurde, plus 258 DQD-Prüfungen – jede davon eine Library(type=sqlquery) mit den drei oben genannten Extensions, nicht das Mockup aus dem vorherigen Abschnitt. Die Transformation bestand alle 172 Golden Cases und den 23-Fall-Antwortschlüssel mit null Konformanzfehlern. Die Prüfungen markierten 5 Fehler in unserer eigenen Ausgabe und 20 in den Gold-Tabellen der Arbeitsgruppe – jeder davon ein Vollständigkeits- oder Plausibilitätssignal, das die Arbeitsgruppe absichtlich eingebaut hatte, abgeglichen auf die Zeile (unsere plausibleGender-Prüfung erfasste genau die 6 benigne Prostatahyperplasie- und 4 Prostatakarzinom-Befunde bei weiblichen Patientinnen).

Zwei Dinge fielen auf. Das Portieren eines Jahrzehnts angesammelter Datenqualitätsprüfungen kostete praktisch nichts – eine DQD-Prüfung ist eine SQL-Abfrage, die fehlerhafte Zeilen zurückgibt, und SQL on FHIR führt genau das aus. Und die Prüfungen rechtfertigten sich sofort: plausibleStartBeforeEnd fand einen Besuch, der drei Tage vor seinem Beginn endete – in den eigenen Gold-Tabellen der Arbeitsgruppe, nicht in den 130 Quell-Encounters, nicht in den Vorhersagen von irgendjemandem, ein Artefakt, das kein Mensch bemerkt hatte. Die Community debattiert einen einzelnen invertierten Period von Hand; die Prüfung findet sie automatisch über den gesamten Datensatz hinweg.

Wie es aussieht

Alles Folgende teilt eine gemeinsame Quelltabelle – eine ViewDefinition, die Observation abflacht:

{ "resourceType": "ViewDefinition", "name": "obs_flat", "resource": "Observation",
  "select": [{ "column": [
    { "name": "id",         "path": "getResourceKey()" },
    { "name": "status",     "path": "status" },
    { "name": "loinc",      "path": "code.coding.where(system='http://loinc.org').code.first()" },
    { "name": "patient_id", "path": "subject.getReferenceKey(Patient)" },
    { "name": "value",      "path": "value.ofType(Quantity).value" },
    { "name": "unit",       "path": "value.ofType(Quantity).code" },
    { "name": "effective",  "path": "effective.ofType(dateTime)" }]}]}

Eine Prüfung ist eine SQLQuery über diese View. Die Extensions tragen die Semantik – diese hier sagt Vollständigkeit, Warnung bei über 5 % fehlenden Werten:

{ "resourceType": "Library", "id": "dqc-obs-value-complete",
  "type": { "coding": [{ "code": "sql-query" }] },
  "extension": [
    { "url": ".../dq-category",  "valueCode": "completeness" },
    { "url": ".../dq-threshold", "valueDecimal": 0.05 },
    { "url": ".../dq-severity",  "valueCode": "warning" }],
  "relatedArtifact": [
    { "type": "depends-on", "resource": "ViewDefinition/obs_flat", "label": "obs" }],
  "content": [{ "contentType": "application/sql", "data": "<base64>" }]}

Das SQL darin ist absichtlich schlicht – und das ist das Feature:

-- completeness: rows where the measurement is missing
SELECT id FROM obs WHERE value IS NULL

Referenzielle Integrität erfordert lediglich eine zweite View und eine zweite Abhängigkeit, patient_flat mit dem Label pat:

SELECT o.id, o.patient_id
FROM obs o LEFT JOIN pat ON o.patient_id = pat.id
WHERE o.patient_id IS NOT NULL AND pat.id IS NULL

Plausibilität ist der Bereich, in dem sich das Konzept wirklich bewährt – kein Profil kann irgendetwas davon ausdrücken. Das DQD von OMOP hat eine ganze Familie von Plausibilitätsprüfungen, und sie lassen sich direkt auf LOINC-kodierte Observations übertragen. Drei der nützlichsten.

Wert außerhalb des physiologischen Bereichs für seinen Code – DQDs plausibleValueLow / plausibleValueHigh. Die Grenzen liegen in einer kleinen Referenztabelle, eine Zeile pro LOINC-Code – genau das Template-Muster von früher: eine Prüfung, Tausende konkrete Grenzen.

-- 29463-7 body weight (kg)  0–650   |  8480-6 systolic BP (mm[Hg])  0–300
-- 8867-4  heart rate (/min) 0–300   |  4548-4 HbA1c (%)             0–20
SELECT o.id, o.loinc, o.value, o.unit
FROM obs o JOIN obs_range r ON o.loinc = r.loinc
WHERE o.value < r.low OR o.value > r.high

Falsche Einheit für die Messung – DQDs plausibleUnitConceptIds. Ein Körpergewicht, das in irgendetwas anderem als einer Masseneinheit aufgezeichnet wird, ist verdächtig, egal wie sinnvoll die Zahl aussieht:

SELECT id, value, unit FROM obs
WHERE loinc = '29463-7' AND unit NOT IN ('kg', 'g', '[lb_av]')

Ein Test, der dem Geschlecht des Patienten widerspricht – DQDs plausibleGender. Ein Prostata-spezifisches Antigen-Ergebnis bei einer Patientin (patient_flat enthält gender):

SELECT o.id, o.patient_id
FROM obs o JOIN pat ON o.patient_id = pat.id
WHERE o.loinc = '2857-1' AND pat.gender = 'female'

Ressourcenübergreifende Regeln fallen ebenfalls hierher. „Ein Patient, der ein Diabetes-Medikament erhält, sollte eine Diabetesdiagnose haben" ist ein Join – in SQL routine, in FHIRPath umständlich bis unmöglich.

Profilierungsmetriken sind überhaupt keine Bestehen/Nicht-Bestehen-Aussagen, sondern lediglich die Zahlen, die ein Dashboard benötigt:

SELECT count(*)                              AS "rowCount",
       count(*) FILTER (WHERE value IS NULL) AS "nullCount_value",
       count(DISTINCT patient_id)            AS "distinctCount_patient",
       min(value) AS "min_value", max(value) AS "max_value"
FROM obs

Und Rollups werden durch denselben Abhängigkeitsmechanismus komponiert, der auf andere Prüfungen statt auf Views zeigt:

SELECT category, count(*) AS checks, sum(failed) AS failed
FROM ( SELECT 'conformance'  category, (SELECT count(*) FROM c1) > 0 failed
       UNION ALL SELECT 'conformance',  (SELECT count(*) FROM c2) > 0
       UNION ALL SELECT 'completeness', (SELECT count(*) FROM c3) > 0 ) t
GROUP BY category

Der Nutzen entsteht dort, wo FHIR bereits seine Arbeit verrichtet: im Implementation Guide. Ein IG-Autor liefert heute ein Instanzprofil – die Vereinbarung darüber, was wohin gehört und wie es kodiert wird. Damit trägt dasselbe IG seine andere Hälfte, ein Datensatzprofil, im selben Bundle:

• die ViewDefinitions, die Daten, die diesen Profilen entsprechen, in Tabellen abflachen, und
• die Qualitätsprüfungen – SQLQuery-Prüfungen über diese Tabellen, jede mit ihrer Kahn-Kategorie und ihrem Schwellenwert versehen.

Jetzt sagt ein IG mehr als „Hier ist die Form, die Ihre Daten annehmen sollen." Er sagt „Hier ist die Form, hier ist, wie man sie abfragt, und hier ist, wie man feststellt, ob Ihre Daten ihr gerecht werden." Ein Nutzer richtet das Paket auf einen Bulk-Export und erhält ein Datenqualitäts-Dashboard zurück – dieser Datensatz besteht 94 von 100 Prüfungen aus diesem IG – ohne eine Zeile benutzerdefiniertem Validierungscode zu schreiben. Profile, Views und Prüfungen reisen gemeinsam, erstellt von den Menschen, die die Domäne verstehen.

Wohin das führt

Fügt man die Teile zusammen, ergibt sich ein klares Bild. Heute liefert ein Implementation Guide ein Instanzprofil und zunehmend auch ViewDefinitions. Damit liefert er die fehlende Hälfte – ein Datensatzprofil: eine kuratierte Menge von Datenqualitätsprüfungen, die festlegen, wie ein guter Datensatz für dieses IG tatsächlich aussieht. Beides zusammen veröffentlicht, und jede konforme SQL on FHIR-Engine führt die Prüfungen sofort aus. Der Autor schreibt sie einmal; jeder Server bewertet Daten auf dieselbe Weise dagegen – kein benutzerdefiniertes Tooling, kein herstellerspezifisches Setup.

Eine ehrliche Einschränkung: Diese Prüfungen können nicht automatisch aus den Invariants eines Profils abgeleitet werden, weil die FHIRPath-Teilmenge von ViewDefinition kleiner ist als das, was diese Invariants verwenden. Der Basiskatalog wird von Hand geschrieben – eine einmalige Aufgabe, die die Community teilt.

Und das ist die Einladung. Das ist kein Gedankenexperiment – es ist laufende Arbeit in der SQL on FHIR-Arbeitsgruppe, mit den Extension-Definitionen und einem Starterset von Prüfungen in Issue #375, die in den Calls der Gruppe weiterentwickelt werden. Die Taxonomie ist etabliert und die Mechanismen existieren; was noch aussteht, ist der Aufbau des Katalogs, offen und gemeinsam. Wenn Sie Datenqualitäts-Tooling über FHIR aufgebaut haben – oder sich je gewünscht haben, FHIR hätte es – kommen Sie und helfen Sie bei der Gestaltung: Bringen Sie Ihre Prüfungen in den Thread ein und nehmen Sie an einem Call teil.