Betrachtungen zur Versionierung von Profilen und Profil-URLs

Wenn ein Profil den Wert von meta.profile nicht festnagelt oder einschränkt (Normalfall!), dann ist gemäß FHIR-Regeln die Validierung gegen Profilversion 1.2.3 erfolgreich für folgende Werte in meta.profile der zu validierenden Ressource:

{url}
{url}|1.2
{url}|1.2.0
...
{url}|1.2.3
{url}|1.2.4
...

({url} ist der Wert von StructureDefinition.url aus dem Profil)

Das klaglose Akzeptieren von Versionen mit höherem Patchlevel mag zwar auf den ersten Blick etwas überraschen, folgt aber aus den Regeln für FHIR (bei Gleichheit von major.minor validieren alte Ressourcen gegen neue Profile und umgekehrt).

Folgende Angaben führen zu Warnungen bzgl. nicht auffindbarer (i.e. nicht resolvierbarer) Profil-URLs:

{url}|1
{url}|1.1 
{url}|1.3

Die für alle Beteiligten beste Situation ergibt sich, wenn

(1) das Profil die URL nicht festnagelt (weil sonst ausschließlich {url}|1.2.3 akzeptiert würde), und (2) die Erzeuger von Datensätzen die tatsächlich verwendete Version mit allen drei Komponenten in meta.profile angeben

Letzteres ließe sich zwar durch Festnageln von meta.profile in der Profildefinition erzwingen, aber dadurch wird die Flexibilität der FHIR-Mechanismen komplett ausgehebelt und URLs würden nur bei exakt gleichem Inhalt (einschl. Patch-Level, Prerelease-Suffix usw.) akzeptiert werden, also {url}|1.2.3, so wie das z.B. bei den GKV-Profilen leider der Fall ist.

Wesentlich besser wäre ein Einschränken von meta.profile über einen regulären Ausdruck, der Profil-URLs nur mit wenigstens zweiteiligem Versionssuffix akzeptiert, à la matches('[^\\|]+\\|\\d+\\.\\d.*').

Ich habe für die alle drei Fälle Profile und entsprechende Testdateien erzeugt, damit diese Mechanismen bequem experimentell ausgelotet werden können. Allerdings erfordert das Testprofil mit dem regex-basierten Versions-Constraint 3+ Teile in der Versionsangabe, nicht 2+ Teile wie in obiger Empfehlung.

XP_PR_Patient_fixed.json: Profil-URL festgenagelt auf {url}|1.2.3, à la GKVSV
XP_PR_Patient_plain.json: Normalfall, keine Einschränkung von meta.profile
XP_PR_Patient_regex.json: Profil-URL eingeschränkt auf solche mit mindestens dreiteiliger Versionsangabe (major.minor.patch*)

Als zu profilierende Ressource wurde Patient gewählt, weil diese Ressource keinerlei Pflichtfelder hat und die Testfälle dadurch kurz und würzig ausfallen (frei von Ballast/Rauschen, ganz im Gegensatz zu e.g. TA7_Sammelrechnung_Bundle). Das Profil ist eine ausgefeilte, hochwissenschaftliche Geschichte, welche die zulässigen Werte einer profilierten Extension einschränkt von "42" oder "08/15" auf nur "42" (um in den Tests feststellen zu können, ob das Profil tatsächlich greift).

In der angehängten ZIP-Datei finden sich die Profile (JSON), die Testdateien (XML) sowie Batch-Dateien namens $validate.cmd.

Letztere erlauben (unter Windows) alle Dateien mit einem Rutsch dem HAPI-Validator vorzulegen, so daß die Ladezeit von 5 Sekunden nicht mehr ganz so tragisch ist wie bei Validieren einer einzigen Datei je Programmstart. Gleichzeitig werden auch die entsprechenden -ig-Schalter gesetzt, um dem Validator die notwendigen Profile unterzuschieben. Dadurch ist es nicht notwendig, erst ein Profilpaket in den lokalen FHIR-Paket-Cache zu laden. Wer das trotzdem tun möchte, findet die entsprechende tgz-Datei ebenfalls hier im Anhang.

Die beiden Batch-Dateien gehen davon aus, daß eine Batch-Datei namens $validator_cli.cmd im Suchpfad verfügbar ist, welche den HAPI-Validator (validator_cli.jar) mit den übergebenen Parametern startet und Standardschalter wie -version 4.0.1 usw. setzt. Eine Kopie dieser Batch-Datei findet sich im Wurzelverzeichnis des ZIPs; dort muß der Pfad zu validator_cli.jar angepaßt werden.

Die Namen einiger Testdateien haben vor der Endung .xml noch einen Einschub wie "WARNING" oder "ERROR". Dabei handelt es sich um die 'tragischste' erwartete Meldestufe des Validators. Das macht es einfach, beim Durchsehen des Validatorergebnisses Soll- und Iststand zu vergleichen. Die Ausgabe Validatorlaufs für die Testdateien ist in der angehängten Datei result.txt abgelegt.

Für besonders eilige hier der (leicht verdichtete) Auschnitt des Validierungsergebnisses für die Tests des Profils mit regulärem Ausdruck für meta.profile:

-- regex.ERROR.xml ----------------------------------------
*FAILURE*: 1 errors, 0 warnings, 0 notes
  Error @ Patient.meta.profile[0] (line 3, col77): ThreePartVersionSuffix: 'URL must have a 3-part version suffix' Rule 'URL must have a 3-part version suffix' Failed

-- regex_with_version_1.WARNING.xml ----------------------------------------
Success: 0 errors, 1 warnings, 1 notes
  Information @ Patient.meta.profile[0] (line 3, col79): Canonical URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1' does not resolve
  Warning @ Patient.meta.profile[0] (line 1, col38): Profile reference 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1' has not been checked because it is unknown, and fetching it resulted in the error The URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1' is not known to the FHIR validator, and has not been provided as part of the setup / parameters

-- regex_with_version_1_1.WARNING.xml ------------------------------------------
Success: 0 errors, 1 warnings, 1 notes
  Information @ Patient.meta.profile[0] (line 3, col81): Canonical URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.1' does not resolve
  Warning @ Patient.meta.profile[0] (line 1, col38): Profile reference 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.1' has not been checked because it is unknown, and fetching it resulted in the error The URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.1' is not known to the FHIR validator, and has not been provided as part of the setup / parameters

-- regex_with_version_1_2.ERROR.xml ----------------------------------------
*FAILURE*: 1 errors, 0 warnings, 0 notes
  Error @ Patient.meta.profile[0] (line 3, col81): ThreePartVersionSuffix: 'URL must have a 3-part version suffix' Rule 'URL must have a 3-part version suffix' Failed

-- regex_with_version_1_2_2.xml ----------------------------------------
Success: 0 errors, 0 warnings, 1 notes
  Information: All OK

-- regex_with_version_1_2_3.xml ----------------------------------------
Success: 0 errors, 0 warnings, 1 notes
  Information: All OK

-- regex_with_version_1_2_4.xml ----------------------------------------
Success: 0 errors, 0 warnings, 1 notes
  Information: All OK

-- regex_with_version_1_3.WARNING.xml ------------------------------------------
Success: 0 errors, 1 warnings, 1 notes
  Information @ Patient.meta.profile[0] (line 3, col81): Canonical URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.3' does not resolve
  Warning @ Patient.meta.profile[0] (line 1, col38): Profile reference 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.3' has not been checked because it is unknown, and fetching it resulted in the error The URL 'https://zrbj.eu/StructureDefinition/XP-PR-Patient-regex|1.3' is not known to the FHIR validator, and has not been provided as part of the setup / parameters

Anmerkung zu den Testfällen mit Versionsangaben '1', '1.1' und '1.3'. HAPI stellt hier korrekt fest, daß nicht gegen die vorliegende Profilversion 1.2.3 validiert werden kann. Allerdings werden nur Warnungen über nicht gefundene Profile ausgegeben, keine Fehler. Im E-Rezept-Umfeld müßten diese Warnungen eigentlich zu Fehlern hochgestuft werden - unabhängig davon, ob sie auf unpassende Versionen zurückgehen oder auf Schreibfehler in den Profil-URLs (e.g. 'Abgabadaten' oder kreative Änderungen bzgl. Groß-/Kleinschreibung, so wie bei Noventi).

Der Referenzvalidator wählt zwar das zu verwendende Profilpaket anhand von meta.profile der Ressource aus (so daß hier kein Widerspruch entstehen kann), aber manche Ressourcen können eine Reihe untergeordneter Profilreferenzen mit Versionangaben enthalten.

P.S.: ich mußte eu.zrbj.xp-1.2.3.tgz umbenennen in *.tar.gz, weil sich die Datei sonst hier nicht anhängen ließ.

result.txt eu.zrbj.xp-1.2.3.zip eu.zrbj.xp-1.2.3.tar.gz

DAV-ABDA / eRezept-Referenzvalidator

Betrachtungen zur Versionierung von Profilen und Profil-URLs #25