Stream: german/kbv
Topic: Archiv- und Wechselschnittstelle als npm-Package
Simone Heckmann (Sep 11 2019 at 13:32):
Hallo zusammen,
da die AuW-Spezifikation bislang nur als ZIP-Paket zur Verfügung steht, habe ich aus den darin enthaltenen Dateien ein Package generiert und auf Simplifier abgelegt.
Das Package heißt auw.dummy und hat die Versionsnummer 0.0.0
Die Dependencies auf die Deutschen Basisprofile sind dort bereits hinterlegt.
Wer nun also die Daten in einen FHIR-Server laden möchte, der den npm-Standard unterstützt, braucht nur noch dieses Package zu laden.
Simone Heckmann (Sep 11 2019 at 13:47):
DISCLAIMER: Bei dem Package handelt es sich nicht um eine offizielle Publikation der KBV.
Die Nutzung erfolgt auf eigene Gefahr und der FTP-Server der KBV ist und bleibt die autoritative Quelle der Spezifikation! Das Package soll lediglich das Laden der Spezifikation in Systeme erleichtern, die FHIR Packaging unterstützen.
Jan Flörke (Sep 17 2019 at 05:23):
Hallo Simone,
vielen Dank für die Bereitstellung der AuW.Spezifikation.
Gibt es ein Werkzeug, mit dem sich die Profile hinsichtlich Anzahl der Element inkl. Unterelementen mit bestimmten Eigenschaften (Must-Support, Min-Occurence,...) auswerten lassen?
Die Zahlen sollen als Basis einer Grobschätzung für den Implementierungsaufwand genutzt werden. Dabei soll zwischen Pflichtfeldern und Gesamtanzahl der Felder differenziert werden.
Schöne Grüße, Jan
Simone Heckmann (Sep 17 2019 at 15:20):
Ein Tool kenne ich nicht, aber es dürfte einfach herauszufinden sein, indem man einfach die Anzahl der Must-Support Flags über alle Profile sucht:
Notepad findet z.B. 80 mal <mustSupport value="true" /> im Profil 74_PR_AW_Abrechnung_BG
Die Anzahl der MustSupport Flags beim Betrachten der Ressource beträgt 40. Die Duplizierung kommt daher, dass die Ressourcen der KBV sowohl das Differential als auch den Snapshot der Ressourcen enthalten.
Also gilt die Faustformel: Anzahlt Treffer/2
Allerdings sind einige der Flags hierarchich verschachtelt, z.B.
...hier muss man lediglich zwei Felder unterstützen, nicht drei...
Weiterhin wiederholen sich viele Basisprofile/Datentypen/Extensions in den Profilen, so dass die Anzahl der zu unterstützenden Elemente nicht der Menge der zu implementierenden Elemente entspricht.
pasted image
Simone Heckmann (Sep 17 2019 at 15:23):
Die selbe Extension aus diesem Bild kommt allerdings identisch in drei weiteren Claim-Profilen vor.
Gefühlt würde ich sagen, die Anzahl der unterschiedlichen Elemente liegt deutlich unter 500, aber ich fürchte, genau berechnen lässt sich das nicht...
Simone Heckmann (Sep 17 2019 at 15:28):
Naja, berechnen lässt es sich schon, man müsste halt die Pfade der Blattelemente mit MustSupport-Flag auflisten und dann Duplikate aus der Liste entfernen, aber das ist Tooling, dass man in der Tat erst mal bauen müsste...
Simone Heckmann (Sep 17 2019 at 15:44):
Falls jemand diesbezüglichen Ehrgeiz entwickelt: Hier wäre die FHIRPath-Expression, um alle Pfade in einer StructureDefinition aufzulisten, die MustSupport-Flags haben: StructureDefinition.differential.element.where(mustSupport = true).path
Das ergibt zum Beispiel bezogen auf o.g. Claim-Profil folgende Liste:
- Claim.extension - Claim.extension.extension - Claim.extension.extension - Claim.extension.extension - Claim.extension.extension - Claim.extension.extension - Claim.identifier - Claim.identifier.value - Claim.status - Claim.subType - Claim.patient - Claim.created - Claim.insurer - Claim.insurer.identifier - Claim.organization - Claim.organization.identifier - Claim.related - Claim.information - Claim.information.valueQuantity - Claim.information - Claim.information.valueString - Claim.information - Claim.information.valueReference - Claim.information.valueReference.reference - Claim.information - 'Claim.information.value[x]' - 'Claim.information.value[x].reference' - Claim.insurance - Claim.insurance.coverage.reference - Claim.insurance.coverage.identifier
Last updated: Apr 12 2022 at 19:14 UTC
