Zirkuläre Abhängigkeit zu de.gevko.evo... nicht deklariert

[hhund]

Die StructureDefinitions ExtensionSeitenlokalisation und ExtensionICD10GMDiagnosesicherheit definieren required bindings zu ValueSets aus dem Projekt eVO (Umsetzung von elektronischen Verordnungen).

basisprofil-de-r4/extensions/Extension-seitenlokalisation.xml

Lines 48 to 51 in 4045c0c

	<binding>
	<strength value="required" />
	<valueSet value="https://fhir.kbv.de/ValueSet/KBV_VS_SFHIR_ICD_SEITENLOKALISATION" />
	</binding>

basisprofil-de-r4/extensions/Extension-icd-10-gm-diagnosesicherheit.xml

Lines 63 to 66 in 4045c0c

	<binding>
	<strength value="required" />
	<valueSet value="https://fhir.kbv.de/ValueSet/KBV_VS_SFHIR_ICD_DIAGNOSESICHERHEIT" />
	</binding>

In der package.json wird jedoch keine Abhängigkeit zu einem der Pakete von eVO deklariert. Dies hat zur Folge, dass ein Validierung von Ressourcen, die diese Extensions verwenden, unter Umständen nicht vollständig durchgeführt werden kann.

Um eine zirkuläre Abhängigkeiten mit einem der Pakete (de.gevko.evo.hlm, de.gevko.evo.khb, de.gevko.evo.ekb) zu vermeiden, wäre ein mögliche Lösung, die ValueSets KBV_VS_SFHIR_ICD_SEITENLOKALISATION und KBV_VS_SFHIR_ICD_DIAGNOSESICHERHEIT in diese Projekt zu überführen.

[alexzautke]

Hi @hhund,

die ValueSets werden durch die KBV herausgegeben. Leider sind sie noch nicht innerhalb eines FHIR Packages verfügbar. Sie müssen in den meisten Fällen manuell heruntergeladen werden (die Canonical URL löst auf die entsprechende Webseite auf) und zum FHIR Server hinzugefügt werden.

Eine gemeinsame Lösung mit der KBV ist angestrebt, wird aber kurz- und mittelfristig nicht umsetzbar sein.

Das die ValueSets in den GEVKO Projekten definiert werden ist ein Fehler. Sie sollte und dürfen offiziell dort nicht vorhanden sein.

[hhund]

Die beiden fehlenden ValueSets sind in den Paketen de.gevko.evo.ekb|0.9.0, de.gevko.evo.khb|0.9.1, de.gevko.evo.hlm|1.0.3 enthalten. Eine deklarierte Abhängigkeit zu einem der Paketen würde jedoch zu einer zirkulären Abhängigkeit führen. Ob dies im FHIR Package Standard vorgesehen ist und von Tools unterstützt wird, ist mir nicht bekannt.

In einer langfristigen Lösung sollten vermutlich entweder die ValueSets in das de.basisprofil.r4 Paket- und unter seine Governance wandern oder in ein unabhängiges drittes Paket.

Kurzfristig (für das nächste Release) würde ich vorschlagen, die beiden ValueSet in dieses Paket zu kopieren.

Grundsätzlich sollte darauf geachtet werden, dass Pakete zusammen mit ihren Abhängigkeiten und transitiven Abhängigkeiten alle nötigen Metadata Ressourcen vollständig enthalten. Idealerweise abgesichert durch entsprechendes Tooling, dass auf Vollständigkeit testet. In großen Deployments sind Workarounds, die ein manuelles Herunterladen von einzelnen Ressourcen erfordern, nicht praktikabel und behindern meiner Meinung nach die Adoption von FHIR.

[patrick-werner]

da bin ich der gleich Meinung Hauke, aber so sind leider die Realitäten des dt. Gesundheitssystems. Die GEVKO VS sind ungeprüft und keine offizielle Quelle.
Offizielle Quelle ist wie bereits genannt die KBV, hier fordern wir schon länger ein Terminology package um die CS/VS leichter verteilen zu können.

Ein Kopieren der VS in die basisprofile halte ich ebenfalls für schwierig, HL7 DE ist nicht der Herausgeber der VS.
Workaround für euer Projekt wäre das herunterladen der KBV VS und das für euren use-case in ein terminology package packen.

[hhund]

Um ein Argument aus #434 zu wiederholen: Ich würde erwarten, dass die Nutzung von Metadata-Ressourcen die active sind und die nicht mit experimental gekennzeichnet wurden, ohne technische Workarounds möglich ist.

Der beschriebene Workaround ist in meinem konkreten Anwendungsfall leider nicht anwendbar, da außerhalb der Pckage-Strukturen keine Ressourcen sinnvoll manuell ergänzt werden können. Die fehlenden Ressourcen im eigenen FHIR Package oder einem abhängigen zu ergänzen, ist natürlich möglich, würde aber das Problem bzw. die Lösung nur zum Anwender verschieben.

Grundsätzlich möchte ich erneut argumentieren, dass veröffentlichte FHIR Packages in einem technisch konsistenten Zustand sein sollten, unabhängig davon welchen Reifegrad sie erreicht haben.

Inwieweit das Urheberrecht beim Einfügen der beiden ValueSets und der dazugehörigen CodeSysteme relevant sein könnte, kann ich nicht beurteilen. Da jedoch CodeSysteme und ValueSets den Herausgeber jeweils selber deklarieren, würde man sich zumindest kein fremdes geistiges Eigentum aneignen.

Schlussendlich bleibt zu diskutieren, ob eine Wiederverwendung von an anderer Stelle deklarierten CodeSystemen und ValueSets, vor allem wenn diese nicht sinnvoll zugänglich sind oder deren Governance Strukturen nicht passen, immer die beste Lösung ist.