Stream: german (d-a-ch)
Topic: QS für Implementierungsleitfäden
Simone Heckmann (Mar 15 2021 at 13:41):
Ich eröffne hier mal die Diskussion zu der Frage: Was sind die minimalen Qualitätsanforderungen an einen FHIR-Implementierungsleitfaden? Es sollten möglichst einfach zu überprüfende Kriterien sein, die es dem TC erlauben, möglichst schnell zu entscheiden, ob ein Leitfaden die Mindest-Anforderungen erfüllt, um ein Abstimmungsverfahren zu durchlaufen.
Hier mal eine grobe Ideensammlung, die ich zur Diskussion stellen möchte:
- verständlich formulierter Implementierungsleitfaden mit menschenlesbaren Repräsentationen der technischen Profile
- valide technische Spezifikation, publiziert als Package, bereitgestellt unter https://registry.fhir.org/
- valide Beispieldaten zu allen enthaltenen Profilen
- Verwendung internationaler Terminologien
- Relevanz
Pavlo Dyban (Mar 15 2021 at 13:49):
Hallo Frau Heckmann,
aus meiner Sicht sollte der IG einen beispielhaften klinischen Ablauf darstellen, damit die zeitliche Reihenfolge der zu verwendenden Ressourcen (soweit vorgesehen) für die Abbildung eines Usecases aus dem IG ersichtlich ist.
Simone Heckmann (Mar 15 2021 at 13:50):
@Alexander Zautke Der Quality Check ist in Simplifier erst in der Team Lizenz verfügbar. Aber vielleicht könnten wir den Check auch auf andere Art zur Verfügung stellen...z.B. in GitHub...?
Alexander Zautke (Mar 15 2021 at 13:51):
Oh ok, das wusste ich selbst nicht
Alexander Zautke (Mar 15 2021 at 13:52):
Das erklärt das Problem von @Mareike Przysucha
Mareike Przysucha (Mar 15 2021 at 13:52):
Das hatte ich mir schon glatt gedacht, daher meine Frage vorhin...
Simone Heckmann (Mar 15 2021 at 13:52):
Pavlo Dyban said:
Hallo Frau Heckmann,
aus meiner Sicht sollte der IG einen beispielhaften klinischen Ablauf darstellen, damit die zeitliche Reihenfolge der zu verwendenden Ressourcen (soweit vorgesehen) für die Abbildung eines Usecases aus dem IG ersichtlich ist.
Ich denke nicht, dass man das als pauschale Voraussetzung sehen kann. Eine FHIR-Spezifikation kann auch einfach nur ein Datenexport-Format festlegen (DiGa/ KBV-AWS) oder einen Verzeichnisdienst (Weisse Liste, Apothekenverzeichnis). Da gibt es keinen klinischen Workflow in diesem Sinne.
Alexander Zautke (Mar 15 2021 at 13:52):
Es würde nur gehen, wenn man Firely Terminal laufen lässt, aber auch da wäre eine Lizenz notwendig
Simone Heckmann (Mar 15 2021 at 13:54):
Schade. Also müssten wir die Packages temporär auf ein HL7-Projekt werfen, QS laufen lassen und dann dem Einreichenden die Fehlerliste zur Korrektur zurückgeben und das ggf in mehreren Iterationen. Suboptimal.
Simone Heckmann (Mar 15 2021 at 14:00):
Die Frage ist ohnehin, nehmen wir Simplifier in DE als gesetzt an (zumindest in der freien Version), oder müssen wir Kriterien formulieren, die auch mit dem IG Publisher erfüllt werden könnten...? Letzten Endes kommt es ja nur darauf an, dass ein valides Package in der Registry landet. wie das dahin kommt, sollte eigentlich egal sein...
Mareike Przysucha (Mar 15 2021 at 14:03):
@Pavlo Dyban Ich sehe das ebenfalls kritisch vor dem Hintergrund, dass wir auch Leitfäden für Dokumente haben. Hier ist die Reihenfolge meist nicht so relevant, außer dass die Composition nach den anderen Ressourcen erstellt werden und das Bundle als letztes. Natürlich kann es auch da feste Reihenfolgen geben, aber z.B. bei einem Wundbericht setze ich im Idealfall auf bestehende Ressourcen auf, deren Erstellungsreihenfolge nicht in meinem Scope liegt.
Simone Heckmann (Mar 15 2021 at 14:03):
Es müsste einen öffentlichen Endpunkt geben, an dem man ein Package QSsen lassen kann...
Mareike Przysucha (Mar 15 2021 at 14:04):
Ich wollte gerade etwas ähnliches schreiben wie Simone Heckmann
Maximilian Reith (Mar 15 2021 at 14:11):
Könnte man nicht ein Github-ACC mit Firely und hl7 Validator Unterstützung einrichten, so wie Alex es gezeigt hat...Dann könnte die Leute dort einfach ihre Profile hochladen
Simone Heckmann (Mar 15 2021 at 14:34):
Jeder kann einen PR erstellen, der dann die QS durchläuft, und die PRs werden einfach nie gemerged... :thinking:
Könnte gehen...
Simone Heckmann (Mar 16 2021 at 12:39):
Wir haben das Thema gestern abend nochmal weiter diskutiert und sind bei folgender revidierten Liste gelandet, die möglichst nicht die Verwendung konkreter Tools voraussetzt und auch die Anmerkung von @Pavlo Dyban berücksichtigt:
- verständlich formulierter Implementierungsleitfaden, der die FHIR-Artefakte textuell oder visuell repräsentiert.
- Beschreibung/Visualisierung des Daten- und oder Workflowmodelles
- valide technische Spezifikation, publiziert als FHIR-Package, bereitgestellt unter https://registry.fhir.org/
- valide, aussagekräftige, repräsentative Beispieldaten
- korrekter Umgang mit Terminologien, Vermeidung proprietärer Codes
Last updated: Apr 12 2022 at 19:14 UTC
