Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abbildung Krankenkassenkartendaten im GKV-Profil #268

Open
alexzautke opened this issue Apr 11, 2021 · 1 comment
Open

Abbildung Krankenkassenkartendaten im GKV-Profil #268

alexzautke opened this issue Apr 11, 2021 · 1 comment

Comments

@alexzautke
Copy link
Member

Kommentar eingereicht durch: Udo Siefker, Bettina Lieske, SAP SE
Kategorie: Ablehnende Kritik
Bezug im Dokument: GKV-Profil
https://ig.fhir.de/basisprofile-de/stable/Ressourcen-VersicherungsInformationenCoverage.html#Ressourcen-Coverage-GKV-Profil

Änderungsvorschlag: "Anstatt der Extension für die Kartendaten würden wir einen eigenen ResourceType HealthcareSmartcard oder HealthinsuranceCard o.ä. empfehlen.
Auf diesen sollte von der Coverage-Resource aus referenziert werden.
Das direkte Replizieren von einzelnen Daten in die Coverage-Resource führt u.E. in die verkehrte Richtung. "
Kommentar / Begründung: "Grade in Deutschland hat die Versichertenkarte immer mehr Bedeutung in Himblick auf verschiedene Anwendungsfälle wie VSDM, EPA, eRezept, Medikationsplan etc.
Deshalb sollten deren Inhalte strukturiert abgelegt und versionierbar sein.
Dies würde das Handling und auch das Verständnis deutlich erleichtern.
"

@simoneOnFhir
Copy link
Contributor

Wir gehen davon aus, dass Coverage-Informationen im Kontext einer gesetztlichen Versicherung i.d.R. durch das EInlesen der Versichertenkarte erfasst werden, so dass die Versionierung der Coverage-Ressource mit den Extensions synchron läuft. Jenseits von VSDM sehen wir keinen weiteren Bedarf, Informationen von der eGK als Extensions abzulegen, da alle anderen Informationen (eRezept, Medikationsplan, Notfalldaten) über entsprechende bestehende FHIR-Ressourcen abgelegt werden können. Wir haben jedoch bereits in Betracht gezogen, die eingelesenen XML-Daten auch im Original abzulegen (als DocumenteReference mit Verlinkung auf eine Binary-Ressource), so dass mit Hilfe einer Provenance-Ressource die aus dem Datensatz erzeugten Klinischen Informationen mit den Kartendaten verknüpft werden können.
Wir werden ein entsprechendes DocumentReference-Profil in künftigen Releases berücksichtigen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants