Wiki - Chris Seyboth

Was heißt „konform"? Die drei Ebenen und ihre Validatoren

4 Min. Lesezeit

Was heißt „konform”? Die drei Ebenen und ihre Validatoren

Die häufigste Fehlinterpretation im ISiK-Umfeld: „Der Validator sagt grün, also sind wir ISiK-konform.” Das sind drei verschiedene Aussagen, und die Sandbox belegt nur die schwächste.

Vorarbeit im Repo: ADR-005 entscheidet, welche Sandbox-Fehler dokumentiert ignoriert werden, und nennt bereits den Grundsatz („für echte Konformitätsaussagen zählt der Referenzvalidator, nicht der Sandbox-HAPI”). Dieser Eintrag macht daraus etwas Nachschlagbares: welche Ebenen es gibt, welches Werkzeug welche bedient, und was jedes von ihnen nicht kann.

Die drei Ebenen

EbeneAussageWerkzeugWas es nicht belegt
1 — Syntax„Das ist wohlgeformtes FHIR R4.”jeder Parser, /mapping selbstob irgendein Profil erfüllt ist
2 — Profil„Es erfüllt die geladenen StructureDefinitions.”HAPI $validate (unsere Sandbox), FHIR-Validator-CLIdass die geladenen Profile die richtigen sind
3 — Bestätigung„Es ist im Sinne des gematik-Bestätigungsverfahrens konform.”gematik-Referenzvalidator, Testsuite im Verfahren— (das ist die verbindliche Ebene)

Ebene 2 ist eine Aussage über ein Paket, nicht über einen Standard. Unsere Sandbox lädt ISiK 3.1.1 mit de.basisprofil.r4 1.4.0 (ADR-002). Ein Bundle, das dort grün ist, kann gegen ISiK Stufe 5 rot sein — und umgekehrt. Der KVZ10-Fall in der ADT-Mapping-Spec ist der belegte Beweis: ein Code aus der aktuellen Doku war gegen das geladene Paket falsch. Ein Code ist nur gegen eine konkrete Paketversion wahr. [Fakt]

Der gematik-Referenzvalidator

Das maßgebliche Werkzeug für Ebene 3. Kernpunkte [Fakt, gematik-Fachportal und GitHub, 28.07.2026]:

  • Er ist im Kern der HAPI-Validator — er nutzt ihn intern als Library. Der Unterschied liegt nicht in der Engine, sondern in der Startkonfiguration: er verwaltet Profile, Profilversionen, Pakete, Gültigkeitszeiträume und paketspezifische Interpretationen für TI-Anwendungen.
  • Ausgeliefert als Java-Konsolenanwendung und als Library zur Einbettung.
  • Er liefert die „autoritative Antwort” über die Gültigkeit eines Datensatzes und dient anderen FHIR-Validatoren als Referenz.
  • Zur Nutzung gibt es verbindliche Regeln aus einem INA-Arbeitskreis.

Die praktische Konsequenz für uns: Der Unterschied zwischen unserem $validate und dem Referenzvalidator ist nicht „gründlicher vs. oberflächlicher”, sondern „welche Paketversionen mit welcher Gültigkeit”. Wer den Unterschied als Qualitätsgefälle beschreibt, sucht den Fehler an der falschen Stelle.

Warum ein roter Validator oft kein Datenfehler ist

ADR-005 hat den Fall am eigenen Material durchgespielt: Das MDM→DocumentReference-Bundle warf drei Fehler (KDL-Code, IHE-formatCode, practiceSetting), obwohl die Codes korrekt waren — HAPIs In-Memory-Terminologie konnte das ValueSet nicht expandieren (child exists=false-Filter, $expand liefert 0 Codes).

Das Diagnose-Werkzeug daraus ist übertragbar und gehört in jeden Werkzeugkasten:

Gegenprobe: Die offizielle Beispielinstanz des IG durch denselben Validator schicken. Scheitert sie identisch, liegt es an der Infrastruktur, nicht an den Daten.

Das ist die Gegenprobe aus der Nein-Taxonomie, angewandt auf ein Werkzeug statt auf einen Menschen: Ein „Nein” wird erst dann adjudizierbar, wenn man es gegen einen bekannten Referenzfall hält.

Nicht ignorierbar sind Strukturfehler — Kardinalitäten, Slices, Pflichtfelder. Die Trennlinie von ADR-005 ist scharf und verlangt beides: (a) die Ursache ist eine nicht expandierbare ValueSet-Bindung und (b) die offizielle Beispielinstanz scheitert identisch. Eine der beiden Bedingungen allein reicht nicht.

Was „ISiK-Bestätigung” wirklich heißt

Das Bestätigungsverfahren nach § 373 SGB V ist für Softwareprodukte im Krankenhaus verpflichtend und wird von der gematik durchgeführt. Eine Bestätigung kann beliebig viele Module innerhalb einer Stufe umfassen. [Fakt, gematik-Fachportal]

Daraus folgen drei Dinge, die man bei einem Haus auseinanderhalten muss — und die in Gesprächen regelmäßig verschmelzen:

  1. Der Hersteller ist bestätigt — sagt nichts über dieses Haus.
  2. Das Modul ist im Haus lizenziert — sagt nichts darüber, ob es aktiviert ist.
  3. Der Endpunkt ist im Haus aktiv und erreichbar — erst das ist eine Tatsache über den Feed.

Das Vendor-Template im Katalog trennt deshalb „ISiK-Reife” ausdrücklich in Modul lizenziert? Stufe? Endpoint live? — siehe den eigenen Vendor-Notizen. Ein „wir sind ISiK-konform” beantwortet die Frage nicht, die man gestellt hat.

Was bridgekit tut und was nicht

/mapping → „Voll validieren” schickt das Bundle an den Sandbox-HAPI: Ebene 2 gegen ISiK 3.1.1. Terminologie-Artefakte nach ADR-005 sind in der Anzeige als solche markiert. Das ist ein ehrliches Entwicklungswerkzeug und keine Konformitätsaussage — der Unterschied ist genau diese Seite.

Graphansicht

Backlinks