Stream: german (d-a-ch)
Topic: Attachment für Coverage-GKV
Simone Heckmann (Nov 10 2017 at 10:20):
Folgende Idee: Wäre es sinnvoll, zum Zwecke der Nachvollziehbarkeit den original-VSDM-Datensatz als Attachment an der Coverage mitzuführen?
Das wäre ggf. nützlich um auf die Originaldaten zugreifen zu können, wenn z.B. eingelesene Patientendaten manuell geändert werden (aktuellere Adresse...)
Außerdem würde es empfangenden Systemen ggf. das Zurückmappen auf VSDM ersparen.
Meinung?
Michael Sauer (Nov 10 2017 at 14:40):
Der Zugriff auf die Originaldaten ist ein wichtiger Aspekt. Ein KBV zertifiziertes System muss die Patientendate der Karte getrennt speichern. Bei manchen Formularen sind sogar die Daten der Karte denen im Patientenverwaltungssystem vorzuziehen, auch wenn letztere die aktuelleren sind. Dazu dann aber die schöne FHIR-Welt verlassen und auf das VSDM-XML zugreifen - da blutet einem das Herz...
Simone Heckmann (Nov 10 2017 at 14:42):
Wir würden es ja in einer Binary-Resource verstecken, dann sieht's von außen fast wie FHIR aus :)
Michael Sauer (Nov 10 2017 at 15:17):
Verstecken ist gut :-)
Prinzipiell könnte der Verweis auf
subscriber Σ 0..1 Reference(Patient | RelatedPerson) Subscriber to the policy
Im Falle des Verweises auf die Originaldaten eine "RelatedPerson" sein (Relationship: ONESELF). Dann hätte man alle Daten in strukturierter Form.
Die Original-VSDM Datensätze hätten sich auch ihren Reiz. Aber man würde dann 3 Anhänge benötigen. Oder würdest Du die zu einem zusammfassen?
Simone Heckmann (Nov 10 2017 at 15:20):
sind die nicht sowieso zu einem Paket gezippt auf der Karte? Würde ich dann genau so dranhängen...
Michael Sauer (Nov 10 2017 at 15:21):
Auf der Karte sind es auch 3 Dateien
Simone Heckmann (Nov 10 2017 at 15:25):
Hm... dann bin ich da ziemlich emotionslos. Wenn man im UseCase immer entweder alle oder keinen der Datensätze benötigt, dann würde ich alles zusammenzippen und Anhängen.
Wenn ein selektiver Zugriff auf einzelne der Dateien benötigt wird, dann müssten wir sie auch einzeln anhängen...
Michael Sauer (Nov 10 2017 at 16:12):
In welchem UseCase würde man das benötigen? Könnte die Welt irgendwann so aussehen, dass ein FHIR-Server im Mittelpunkt eines KIS oder einer Praxis-EDV steht? Und es letztlich APPs gebe, die aus diesen Daten die Abrechnung für einen bestimmten Zweck durchführen?
Michael Sauer (Nov 10 2017 at 16:13):
Generell fände ich 3 Dateien besser, da dann von aussen klar ist, was drin ist. Sonst habe ich eine gezippte Datei, die überall anders aussehen könnte.
Simone Heckmann (Nov 11 2017 at 11:15):
Vorschlag: Ich reiche einen Change Request ein, um der Coverage-Resource ein element attachment(Attachment) 0..* hinzuzufügen. Das sollte bis R4 klappen, dann haben wir das bis nächstes Jahr.
Inzwischen diskutieren wir hier die Constraints für den Datentyp Attachment: http://build.fhir.org/datatypes.html#attachment
Falls jemand einen UseCase hat, der das Element benötigt und nicht auf R4 warten kann, dann lösen wir das über eine temporäre Extension.
Last updated: Apr 12 2022 at 19:14 UTC
