search

gematik / app-referencevalidator

The reference validator is a tool to perform advanced validation of FHIR resources for TI applications and interoperability standards
https://fachportal.gematik.de/hersteller-anbieter/primaersysteme/referenzvalidator
Other
22 stars 4 forks source link

hapi-fhir-validation Version #24

Closed tnus closed 3 months ago

tnus commented 3 months ago

Hallo,

ich würde den Validator gerne in unserem Projekt verwenden. Wir verwenden allerdings die hapi fhir Version 7.4.0, welche nicht kompatibel mit dem Validator ist. Ist geplant die Version demnächst zu aktualisieren? Ich habe es mal kurz versucht, aber auf die schnelle hat es leider nicht funktioniert.

Viele Grüße

scanacs-agruhn commented 3 months ago

Lagern Sie das Ganze als Microservice aus. Innerhalb einer monolithischen Architektur bekommt man da immer nur Probleme mit den Dependencies. Ist dann auch einfacher skalierbar.

alexey-tschudnowsky commented 3 months ago

Hallo @tnus , wir evaluieren gerade die Version 7.4.0, da sie im Bereich der FHIR-Validierung etliche Korrekturen und Verbesserungen mitbringt. Wir streben die Aktualisierung in Q4/2024. Ansonsten wäre eine Prozessauslagerung wie von @scanacs-agruhn vorgeschlagen in der Tat zu empfehlen. Ein "unkontrollierter" Austausch der Abhängigkeiten kann nämlich (in Randfällen) zu einem abweichenden Validierungsergebnis führen.

DarthGizka commented 3 months ago

Wir streben die Aktualisierung in Q4/2024

Existierende Ressourcen (E-Rezepte) mit ungültigen relativen Referenzen können diesbezüglich zum Problem werden. Die Umstellung der Gematik-Quittungen erfolgte erst im Frühjahr diesen Jahres (Ende März IIRC), und seitens einiger Apotheken-Softwarehäuser wurden noch lange Zeit danach kaputte PharmDL-Rezepte generiert. Selbst jetzt gibt es gelegentlich noch welche.

Der Referenzvalidator soll vereinbarungsgemäß eine gewisse 'historische Reichweite' nach rückwärts haben, so daß selbst eine hypothetische Version aus dem Jahr 2026 noch die kaputten E-Rezepte von Anfang 2024 akzeptieren muß.

Falls die aktuelle HAPI-Version keinen Legacy-Schalter zum Akzeptieren der bis Sommer '23 auch von HAPI akzeptierten unorthodoxen Referenzen nach der Notnagelregel hat, dann kann das praktische Probleme aufwerfen. Der internationale Referenzvalidator (validator_cli.jar von HL7.org) hat definitiv keinen, geht aber unter dem Hut zum Teil ganz andere Wege als die HAPI-Validierungsinfrastruktur.

Entweder gibt man den Anspruch auf, mit einer einzigen Version des Referenzvalidators alle produktionsrelevanten Profilpaketversionen abzudecken, oder man muß den Referenzvalidtor in die Lage versetzen, durch Umhacken der zu validierenden Ressourcen das Aussteigen von HAPI bei der Validierung zu verhindern ...

Im Zweifelsfall wäre ich definitiv für ersteres; in Anbetracht der für eine Validierung notwendigen Zeit (typischerweise 2stellige Millisekunden oder länger) fallen die Millisekundenbruchteile für einen zusätzlichen rechnerlokalen HTTP-Hop überhaupt nicht ins Gewicht. Daher kann man leicht einen Versions-Dispatcher vor die Referenzvalidator-Dienste schalten. Da Zäsuren wie die durch den HAPI-Versionswechsel bedingte (hoffentlich) relativ selten sein sollten, bräuchte man sich realistisch nur auf das Vorhalten von maximal zwei produktionsrelevanten Validator-Varianten einzurichten.

Wir hatten dieses Thema in der uAG zwar schon mehrfach angeschnitten, aber noch nie so richtig auf einen Punkt gebracht. Wenn ein HAPI-Versionwechsel tatsächlich schon auf dem Radar ist, dann haben wir da etwas Nachholbedarf.

tnus commented 3 months ago

Hallo zusammen,

vielen Dank für die Antworten. Aktuell konnte ich das Problem lösen, in dem ich einfach eine ältere hapi fhir Version verwende. Ich werde mal schauen wie wir das in den nächsten Monaten dann lösen werden. Ausgelagerter Micro Service wäre definitiv ein Ansatz.

Viele Dank

alexey-tschudnowsky commented 3 months ago

Danke für die Hinweise, @DarthGizka

Der Referenzvalidator soll vereinbarungsgemäß eine gewisse 'historische Reichweite' nach rückwärts haben, so daß selbst eine hypothetische Version aus dem Jahr 2026 noch die kaputten E-Rezepte von Anfang 2024 akzeptieren muß.

Das haben wir auf dem Schirm und testen alle Aktualisierungen mit möglichst vielen alten Daten.

Falls die aktuelle HAPI-Version keinen Legacy-Schalter zum Akzeptieren der bis Sommer '23 auch von HAPI akzeptierten unorthodoxen Referenzen nach der Notnagelregel hat, dann kann das praktische Probleme aufwerfen. Der internationale Referenzvalidator (validator_cli.jar von HL7.org) hat definitiv keinen, geht aber unter dem Hut zum Teil ganz andere Wege als die HAPI-Validierungsinfrastruktur.

Im Referenzvalidator haben wir gewissen Einfluss auf die Ausgaben von HAPI und könnten diese theoretisch durch eigene Mechanismen datumsabhängig anpassen. Damit experimentieren wir und diskutieren die Testergebnisse sowie der Umgang damit anschließend in der uAG.