Stream: german (d-a-ch)
Topic: Coverage (Profil GKV)
Simone Heckmann (Jun 13 2017 at 20:43):
Erster (Ent-)Wurf:
https://simplifier.net/BasisprofilDE/coverage-de-gkv
Stefan Lang (Jun 15 2017 at 08:31):
Auch hier schlage ich (analog zu Patient Basis) vor, identifier.type für die definierten Slices auf 0..1 zu belassen, um Implementierern Möglichkeiten offen zu halten
H. Ristok (Mar 12 2019 at 22:26):
Für die Abbildung der Pflegeversicherung (aktuell in der Langzeitpflege ambulant oder staionär - in Kürze ggf. auch für Krankenhäuser relevant)
würde ich gerne in
https://simplifier.net/BasisprofilDE/versicherungsart-de-basis:
Bisher:
Code Display
GKV gesetzliche Krankenversicherung
PKV private Krankenversicherung
BG Berufsgenossenschaft
SEL Selbstzahler
SOZ Sozialamt
nun weitere Codes eintragen für
GPV gesetzliche Pflegeversicherung
PPV private Pflegeversicherung.
Was ist die empfohlene Vorgehensweise für eine solche Erweiterung?
Stefan Lang (Mar 13 2019 at 08:07):
Da es sich hier m.E. um eine bundesweit relevante Erweiterung des bestehenden ValueSets handelt, würde ich für eine Erweiterung des ValueSets und ggf. des o.g. CodeSystems der Basisprofile plädieren.
Formal kann das jederzeit in den Issue Tracker der Basisprofile eingetragen werden: https://github.com/hl7germany/basisprofil-de/issues
H. Ristok (Mar 17 2019 at 18:15):
Danke für den Hinweis!
Hier gehören allerdings noch mehr Informationen in die Coverage wie z.B.
a) Die Pflegeversicherung zahlt je nach Pflegegrad des Patienten nur einen Maximalbetrag. Der Rest muss vom Patienten selbst oder dem Sozialamt getragen werden.
- Eine weitere Komplikation sind Beihilfeberechtige Personen: Diese erhalten von von der Kasse in der Regel nur einen bestimmten %-Satz. Der Rest muss selbst übernommen werden.
Im deutschen Profil habe ich dazu noch nichts gefunden - gibt es US-Beispiele für solche komplexen Situationen die man als Referenz verwenden kann?
Stefan Lang (Mar 17 2019 at 22:32):
Das US-System ist, denke ich, so anders strukturiert, dass man hier wenig übernehmen kann.
In den deutschen Basisprofilen sind Themen wie Beihilfe (die gibt es ja nicht nur im PV-, sondern auch im KV-Bereich) sicher noch nicht detaillert abgebildet.
Da die Basisprofile eher Grundlage als Ausdetaillierung sein sollen, muss man schauen, welche Inhalte hier Einzug in die Basisprofile finden sollten (z.B. bundesweit vorgeschriebene Codierungen), und was dann z.B. Bestandteil eines speziellen Implementierungsleitfadens "Pflegeversicherung" o.ä. wäre.
Ich denke das ist, unabhängig von aktuell auftretenden Detailfragen, ein interessantes Thema für das Interoperabilitätsforum. Ich meine mich zu erinnern, dass Sie vor einiger Zeit dort schon einmal waren? Wäre schön, wenn man hier anknüpfen könnte.
Christof Gessner (Mar 17 2019 at 23:36):
anknüpfen
Christof Gessner (Mar 17 2019 at 23:36):
gerne!
H. Ristok (Mar 18 2019 at 07:05):
Noch einen Verständnisfrage:
Die angepassten deutschen Basisprofile basieren auf STU3, während auf der englischsprachigen Seite
http://hl7.org/fhir/coverage.html
schon die Version R4 definiert ist.
Speziell bei coverage gibt es hier doch mehrere Änderungen und Erweiterungen.
Auf welcher Basis soll hier sinnvollerweise gearbeitet werden?
Stefan Lang (Mar 18 2019 at 07:19):
Die deutschen Basisprofile basieren in der Tat noch auf STU3, veröffentlicht hier: https://www.hl7.org/fhir/STU3/
Aktuell ist das Tooling für FHIR R4 noch nicht durchgehend verfügbar. Dies wird für Mai erwartet; anschließend werden die deutschen Basisprofile auf FHIR R4 umgesetzt.
Es hängt also ein wenig an Ihren Zeitvorgaben: Profilierung jetzt erfordert quasi das vorläufige Verbleiben auf STU3, es sei denn, Sie verzichten auf die entsprechenden Tools.
Wenn der Zeitrahmen nicht eng gesteckt ist, würde ich zunächst auf die Datenelemente von FHIR R4 mappen und mit Verfügbarkeit des Toolings und der deutschen R4-Basisprofile direkt auf FHIR R4 gehen.
Simone Heckmann (Aug 08 2019 at 13:41):
Hier würde ich gerne wieder ansetzen, da wir gerade dabei sind, die Profile auf R4 zu migrieren.
Wer hat Anmerkungen, Wünsche, Vorschläge zur GKV-Coverage (https://simplifier.net/basisprofilde/coverage-de-gkv-0.2)?
Verwendet schon irgendwer die extensions und kann uns ein Feedback darüber geben, ob die Gruppierung von zusatzinfos-allgemein und zusatzinfos-geschützt so sinnvoll ist, oder sollten wir statt dessen besser mit einzelnen einfachen Extensions arbeiten?
Simone Heckmann (Aug 08 2019 at 13:41):
@Helmut Ristok Gerne können wir auch die Profile für PPV und GPV in Angriff nehmen...
H. Ristok (Aug 09 2019 at 12:26):
Hier kann ich gerne zur Diskussion beitragen:
Generell gibt es für die Pflegeversicherung erst mal die folgenden Beteiligten die die Kosten der Pflege übernehmen
-
gesetzliche (oder private) Pflegeversicherung
diese übernehmen als erster in Anspruch genommener Zahler einen bestimmten (vom Pflegegrad abhängigen)
Maximalbetrag pro Monat- der verbleibende Rest wird dann auf die anderen Beteiligten (Zahler) aufgeteilt
-
ggf. ein Sozialamt, das Kosten übernimmt wenn der Klient selbst nicht in der Lage ist die Kosten (ganz oder teilweise) zu übernehmen
- Privatperson (Klient oder Angehöriger, ggf. auch ein gesetzlicher Betreuer) als privater Restzahler
Technisch gesehen sind hier mehrere Zahler(=Coverages?) im Spiel,
- die nacheinander in Anspruch genommen werden (==> Reihenfolge der Coverage Einträe ist wichtig)
- die jeweils einen Maximalbetrag pro Monat, einen Prozentsatz(vom Gesamtbetrag oder vom verbleibenden Rest) oder final den **Rest" der Kosten übernehmen.
Simone Heckmann (Aug 09 2019 at 13:44):
Ok, ich denke gesetzliche/private Pflegeversicherung in die Liste der Versicherungsarten aufzunehmen ist der einfachste Punkt.
Pflegegrad ist hier zwar relevant, aber m.E. keine Eigenschaft von Coverage, sondern eine separate Observation(?)
Sozialversicherung und (ggf. abweichender) Selbstzahler können wir auch mit Bordmitteln abbilden. Die Reihenfolge der Coverages wird dann am Account festgelegt, da diese von Fall zu Fall unterschiedlich ist...
Was wäre sonst noch in der Instanz einer solchen Coverage festzuhalten...? Werden Pflegeversicherungen auch über IK-Nummern identifiziert?
H. Ristok (Aug 09 2019 at 13:50):
Zu 1) GPV und PPV in die Liste der Versicherungsarten aufnehmen :
OK
können wir das schon in den deuschen Basisprofilen machen o(ohhne weitere Ableitung)?
Zu 2) Pflegegrad als Observation:
Stimme ich gerne zu - soll ich dazu mals eine Beispiel machen?
Zu 4) Pflegeversicherung wird auch über IK-Nummern identifiziert -
diese unterschieden sich nur in einer Stelle von der IK der zugehörigen Krankenkasse
Zu 3) Selbstzahler /Sozialamt
Account habe ich mir noch nicht angesehen - ob das für den Fall passt
==> würde ich später noch eine Rückmeldung geben
Simone Heckmann (Aug 09 2019 at 13:52):
...nun weitere Codes eintragen für
GPV gesetzliche Pflegeversicherung
PPV private Pflegeversicherung.Was ist die empfohlene Vorgehensweise für eine solche Erweiterung?
Wir nehmen das in das ValueSet in R4 auf, gehen damit ins Ballot und schauen, ob sich jemand beschwert :)
https://simplifier.net/basisprofil-de-r4/versicherungsart-de-basis-r4
Simone Heckmann (Aug 09 2019 at 13:53):
Zu 2) Pflegegrad als Observation:
Stimme ich gerne zu - soll ich dazu mals eine Beispiel machen?
Sehr gerne!
Simone Heckmann (Aug 09 2019 at 14:35):
Bitte alles zum Thema "Pflegestufe" hier hin --> https://chat.fhir.org/#narrow/stream/179183-german-(d-a-ch)/topic/Observation.20(Pflegestufe)
Simone Heckmann (Aug 09 2019 at 15:39):
ad Account: hier gibt es 0..* links auf Coverage, mit einer ganzzahligen prioritykönnen die Coverages in eine logische Reihenfolge gebracht werden.
Der Account ist in unserem Sprachgebrauch der "Abrechnungsfall", also die Sammelmappe für alle Leistungen, Prozeduren etc, die ein einem gemeinsamen Kontext zur Abrechnung gebracht werden. Der "Encounter" stellt in FHIR wirklich nur den physikalischen Besuch eines Patienten (Tür rein -- Tür raus) dar.
Bisher wurde das in DE alles ziemlich pauschal zusammengeworfen und als "Fall" bezeichnet ;-)
Simone Heckmann (Aug 30 2019 at 13:37):
Hier würde ich gerne wieder ansetzen, da wir gerade dabei sind, die Profile auf R4 zu migrieren.
Wer hat Anmerkungen, Wünsche, Vorschläge zur GKV-Coverage (https://simplifier.net/basisprofilde/coverage-de-gkv-0.2)?
Verwendet schon irgendwer die extensions und kann uns ein Feedback darüber geben, ob die Gruppierung von zusatzinfos-allgemein und zusatzinfos-geschützt so sinnvoll ist, oder sollten wir statt dessen besser mit einzelnen einfachen Extensions arbeiten?
ich krame die Frage mal wieder hoch für @Bettina Lieske :)
Bettina Lieske (Sep 04 2019 at 09:52):
Wir fanden es in der Tat als etwas kompliziert mit mehreren Ebenen von Extensions zu arbeiten und würden die einfachen bevorzugen. Auch haben wir uns gefragt, ob es nicht sinnvoll wäre, die eGK als eigene Ressource zu definieren, damit all die eingelesenen Daten "as is" persistiert / kommuniziert werden können. Jedes Land hat wahrscheinlich seine eigene Versichertenkarte mit landesspezifischen Feldern. Ein generisches Objekt "Healthcare Smart Card" habe ich aber nicht gefunden.
Simone Heckmann (Sep 04 2019 at 10:58):
Es bestünde natürlich immer die Möglichkeit, die Datensätze nativ zu kommunizieren, d.h. Base64-codiert in der Basic-Ressource. Dazu müssten wir dann nur eine DocumentReference spezifizieren, die auf die Basic-Ressource zeigt und spezifiziert, um was es sich da eigentlich handelt. Wir bräuchten also nur einen einheitlichen DocumentReference.type-code. Allerdings wären die Informationen in den Datensätzen dann nicht über die FHIR-API abrufbar. Wäre das in eurem UseCase ein Problem?
Patrick Werner (Sep 04 2019 at 11:41):
2. Möglichkeit wäre ein strikt profiliertes Bundle mit allen benötigten Resourcen (Patient,Coverage) mit einem contained binary welches das/die zip Files der EKG nativ enthält.
Simone Heckmann (Sep 04 2019 at 11:47):
Klar, ich fände auch ein Mapping (@Alexander Zautke ;-) ) schön, um zwischen EKG und FHIR zu brokern. Wenn man das Binary aber immer parallel mitführt, müsste man sich nicht die Mühe machen 100% zu mappen, sondern könnte sich auf die wirklich relevanten und benötigten Daten fokussieren...
Alexander Zautke (Sep 04 2019 at 13:12):
Von base64 Binary würde ich abraten, wir könnten jedoch die ganzen Extensions als eigene Elemente in Basic modellieren.
Simone Heckmann (Sep 04 2019 at 13:35):
Mmmhhhjaaaa, aber wenn der UseCase tatsächlich nur der Transport und die Persistenz des EGK-Datensatzes ist, dann ist Binary nicht die schlechteste Variante. Es wäre ziemlicher overkill, von EGK nach Basic zu mappen, nur um die Information per REST zu kommunizieren und am Ziel wieder von Basic nach EGK zu mappen.
Wir hatten die selbe Diskussion vor Jahren schon mla in Bezug auf V2, wo wir genau zu diesem Schluss gekommen waren...
Simone Heckmann (Sep 04 2019 at 13:36):
...was natürlich nicht ausschließen soll, dass es sinvoll ist, einige der Elemente der EGK bspw. auf Extensions in Coverage zu mappen, weil die Informationen dort relevant sind und über die FHIR-API auffindbar sein sollten...
Patrick Werner (Sep 04 2019 at 13:41):
Von base64 Binary würde ich abraten, wir könnten jedoch die ganzen Extensions als eigene Elemente in Basic modellieren.
Ja, bläht alles etwas auf. Aber eine (contained) Media/DocumentReference Ressource könnte direkt per URL auf das Binary des VSDM Datensatzes zeigen.
Simone Heckmann (Sep 04 2019 at 13:43):
Die schlankeste Variante wäre eine DocumentReference mit Base64 eingebettet in DocumentReference.content.attachment.data. Da der Datensatz nicht so umfangreich ist, wäre das Trennen von Metadaten und Content hier weniger wichtig als z.B. bei einem PDF oder CDA
Alexander Zautke (Sep 04 2019 at 13:53):
Gut, wenn es nur Persistence ist dann geschenkt. Ich dachte es ginge auch am Ende darum Daten gut wieder heraus holen zu können.
Bettina Lieske (Sep 04 2019 at 14:18):
Bin mir nicht sicher, ob ich es richtig verstehe. Heißt dies, wir hätten ein Bundle, das eGK-Daten heißt und explizites Ressourcen wie Patient mit den demographischen Daten und Coverage mit den Versicherungsinfos beeinhaltet und die gesamten Daten der eGK (inkl. technische wie Einlesedatum etc.) wären als Datensatz attachment abgebildet?
Bettina Lieske (Sep 04 2019 at 14:59):
Und noch eine direkte Frage zum dt. Coverage Profil: wie würde man denn eine Kostenübernahme der Kasse abbilden, die die Antwort auf eine Aufnahmeanzeige darstellt und Informationen wie Kostenübernahme von .. bis, Zuzahlungstage und Höchstbetrag je Tag umfasst?
Simone Heckmann (Sep 04 2019 at 15:02):
Ausgehen würde ich hier von http://hl7.org/fhir/coverageeligibilityresponse.html
Simone Heckmann (Sep 04 2019 at 15:11):
Die genannten Dinge könnten - auf den ersten Blick - als benefit Elemente mit entsprechendem TypeCode modelliert werden...?
Simone Heckmann (Sep 04 2019 at 15:15):
Zur EGK kann ich mal ein Beispiel modellieren, allerdings tendenziell nicht vor Freitag...
Simone Heckmann (Sep 04 2019 at 15:18):
Ich nehme an, es gibt eine feste Menge von Infos, die in einer Kostenübernahme vorkommen können? Gibt’s dazu eine Spezifikation?
Johannes Höhn (Sep 05 2019 at 09:46):
Eine weitere Frage zur Coverage: Wäre Selektivvertragliche Versorgung nicht auch eine Versichertenart?
Simone Heckmann (Sep 05 2019 at 10:08):
Ich hätte das jetzt intuitiv eher als eine GKV mit einem zusätzlichen Flag/Attribut gesehen, aber ich lasse mich gerne vom Gegenteil überzeugen...
Stefan Lang (Sep 05 2019 at 10:15):
Selektivverträge sind Verträge zwischen Kostenträgern im GKV-Bereich und einzelnen Leistungserbringern.
Coverage repräsentiert das Verhältnis zwischen Patient und Kostenträger.
Die KBV stellt Selektivverträge als FHIR-Contract dar. Sinnhaft wäre also evtl. eine entsprechende Referenz von Coverage auf Contract, wenn man das detailliert machen möchte.
Ansonsten gibt es derzeit im Coverage-GKV-Basisprofil die Extension gkv-zusatzinfos-geschuetzt und darin wiederum Flags für die Selektivverträge.
Bettina Lieske (Sep 05 2019 at 13:17):
Ja, die Spezifikation ist hier: https://www.dkgev.de/themen/digitalisierung-daten/elektronische-datenuebermittlung/datenuebermittlung-zu-abrechnungszwecken/datenuebermittlung-nach-301-abs-3-sgb-v/ Dort Gesamtdokumentation und dann Seite 70/71 oder nach KOUB suchen
Johannes Höhn (Sep 05 2019 at 14:56):
In den gkv-zusatzinfos-geschuetzt sind doch nur was auf der eGK steht, oder? Das hat keinen Normativen Charakter ob ein Patient wirklich an Selektivverträgen teilnimmt. Den Hinweis mit Referenzen auf Contract finde ich sehr Hilfreich. Danke!
Alexander Zautke (Sep 06 2019 at 14:30):
Deleted, weil falscher Thread
Simone Heckmann (Sep 06 2019 at 15:35):
Hallo zusammen, hier geht gerade ziemlich viel durcheinander.
Ich würde vorschlagen, dass wir die Themen
- Selektivverträge
- Übermittlung/Mapping EGK-Datensatz
- Kostenübernahme durch Kasse
in jeweils separaten Threads weiterdiskutieren.
H. Ristok (Sep 19 2019 at 07:32):
Entwurf für eine Coverage bei gesetzlicher Krankenversicherung
Ich habe das GAnze mal erstellt um einen Überblick über die wichtigsten Elemente zu erhalten - von daher noch keine Anspruch auf Vollständigkeit.
Kann hier jemand mal drüberschauen, ob die Konzepte richtig sind @Simone Heckmann
<?xml version="1.0" encoding="UTF-8"?>
<Coverage xmlns="http://hl7.org/fhir">
<id value="9876B1"/>
<text value="Gesetzliche Pflegeversicherung">
<identifier>
<system value="http://sozialstation-st-elisabeth-ulm/nord"/>
<value value="12345"/>
</identifier>
<status value="active"/>
<type>
<coding>
<system value="http://fhir.de/CodeSystem/versicherungsart-de-basis" />
<code value="GKV" />
<display value="Gesetzliche Krankenversicherung"/>
</coding>
</type>
<!-- Policy Holder wird für Pflegeversicherung in D nicht benötigt-->
<subscriber>
<reference value="RelatedPerson/123"/>
</subscriber>
<beneficiary>
<reference value="Patient/4"/>
</beneficiary>
<!-- Dependant wird in Altenhilfe D nicht benötigt -->
<relationship>
<coding>
<code value="spouse"/>
</coding>
</relationship>
<period>
<start value="2018-08-01"/>
</period>
<payor>
<reference value="Organization/102"/>
</payor>
<!-- Mehrere Class Einträge wären möglich, werden aber in D nicht genutzt -->
<class>
<type>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/coverage-class"/>
<code value="class"/>
</coding>
</type>
<value value="GKV"/>
<name value="Gesetzliche Krankenversicherung"/>
</class>
<!-- Order entfällt bei ges. Krankenversicherung -->
</Coverage>
Simone Heckmann (Sep 19 2019 at 14:36):
Bin verwirrt. Ist das ein Beispiel für Gesetzliche Krankenversicherung oder Pflegeversicherung?
H. Ristok (Oct 16 2019 at 20:55):
Überarbeitete Fassung einer Coverage für die gesetzliche Krankenversicherung (Fehlerjafte Referenz auf Pflegeversicherung wurd korrgiert)
mit der Bitte um Feedback:
<?xml version="1.0" encoding="UTF-8"?>
<Coverage xmlns="http://hl7.org/fhir">
<id value="9876B1"/>
<text value="Gesetzliche Krankenversicherung">
<identifier>
<system value="http://sozialstation-st-elisabeth-ulm/nord"/>
<value value="12345"/>
</identifier>
<status value="active"/>
<type>
<coding>
<system value="http://fhir.de/CodeSystem/versicherungsart-de-basis" />
<code value="GKV" />
<display value="Gesetzliche Krankenversicherung"/>
</coding>
</type>
<!-- Policy Holder wird für Krankenversicherung in D nicht benötigt-->
<subscriber>
<reference value="RelatedPerson/123"/>
</subscriber>
<beneficiary>
<reference value="Patient/4"/>
</beneficiary>
<!-- Dependant wird in Altenhilfe D nicht benötigt -->
<relationship>
<coding>
<code value="spouse"/>
</coding>
</relationship>
<period>
<start value="2018-08-01"/>
</period>
<payor>
<reference value="Organization/102"/>
</payor>
<!-- Mehrere Class Einträge wären möglich, werden aber in D nicht genutzt -->
<class>
<type>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/coverage-class"/>
<code value="class"/>
</coding>
</type>
<value value="GKV"/>
<name value="Gesetzliche Krankenversicherung"/>
</class>
<!-- Order entfällt bei ges. Krankenversicherung
??? Offen ist aber die Umsetzung der Beihilfeversicherung, die nur %-Anteile der Gesamtkosten im Krankheitsfall bezahlt-->
</Coverage>
H. Ristok (Oct 16 2019 at 21:12):
Darstellung von Patienten (Beamte), die über Beihilfe versichert sind:
Beamte sind in Deutschland weder gesetzlich noch privat Krankenversichert.
Sie erhalten Beihilfe von ihrem Dienstherren
"Die Höhe der Beihilfe macht für den Beamten in der Regel 50 Prozent aus, für den Ehepartner 70 Prozent und für die Kinder 80 Prozent. Da die Beihilfe im Krankheitsfall immer nur einen Teil der Kosten abdeckt, müssen Beamte die Versorgungslücke mit einer privaten Restkostenversicherung schließen."
Ich habe zu dieser Problemstellung in Zulip & FHIR Doku bisher nichts gefunden.
Um diese Art der Coverage abbilden zu können schlage ich vor die "VersicherungsartDEBasis" (https://simplifier.net/basisprofil-de-r4/versicherungsart-de-basis-r4) zu erweiteren um einen Wert
"BEI" = Beihilfeanspruch von Beamten
zu ergänzen.
Bitte um Feedback zu diesem Lösungsvorschlag oder gerne auch Beispiele wie diese im Krankenhaus in der Abrechnung umgesetzt wird.
Ansonsten:
Was muss ich tun um disen Valueset generell zu erweitern? @Simone Heckmann
H. Ristok (Oct 16 2019 at 21:49):
Beihilfe fü Beamte: Umsetzung als Coverage (Beispiel)
Hier habe ich versucht die Beihilfe für Beamte als Coverage zu implementieren:
Bitte um Feedback
<?xml version="1.0" encoding="UTF-8"?>
<Coverage xmlns="http://hl7.org/fhir">
<!-- Beispiel für die Umsetzung der Beihilfe für Beamte -->
<id value="9876B1"/>
<text value="Beihilfe">
<identifier>
<system value="http://sozialstation-st-elisabeth-ulm/nord"/>
<value value="12345"/>
</identifier>
<status value="active"/>
<type>
<coding>
<system value="http://fhir.de/CodeSystem/versicherungsart-de-basis" />
<code value="BEI" />
<display value="Beihilfe"/>
</coding>
</type>
<!-- Policy Holder wird für Krankenversicherung in D nicht benötigt-->
<subscriber>
<reference value="RelatedPerson/123"/>
</subscriber>
<beneficiary>
<reference value="Patient/4"/>
</beneficiary>
<!-- Dependant wird in Altenhilfe D nicht benötigt -->
<relationship>
<coding>
<code value="spouse"/>
</coding>
</relationship>
<period>
<start value="2018-08-01"/>
</period>
<payor>
<reference value="Organization/102"/>
</payor>
<!-- Mehrere Class Einträge wären möglich, werden aber in D nicht genutzt -->
<class>
<type>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/coverage-class"/>
<code value="class"/>
</coding>
</type>
<value value="BEI"/>
<name value="Beihilfe"/>
</class>
<!-- Order entfällt auch bei Beihilfe, da Privatanteil mit CostToBeneficiary umgesetzt wird.
??? Es folgt die beispielhafte Umsetzung der Privatanteils von 30% für den Ehegatten-->
<costToBeneficiary>
<type>
<coding>
<system value="https://terminology.hl7.org/CodeSystem/coverage-copay-type"/>
<code value="copaypct"/> <!-- Typ = Prozent -->
</coding>
</type>
<valueQuantity>
<value value="0.30"/> <!-- Beispiel: 30% -->
</valueQuantity>
</costToBeneficiary>
</Coverage>
Simone Heckmann (Oct 17 2019 at 12:13):
Ist die Information zu einer ggf. vorhandenen Beihilfe für die Leistungserbringer relevant? Bzw. wird unmittelbar zwischen Leistungserbringer und Beihilfe abgerechnet, oder zahlt hier zunächst mal der Patient und kann dann die ausgelegten Kosten zur Erstattung bei der Beihilfe einreichen?
Stefan Lang (Oct 17 2019 at 16:12):
Den Use Case (oder eher: Abrechnungs-Problemfall) "Beihilfe" gibt es z.B. auch bei der Krebsregister-Vergütung.
H. Ristok (Oct 21 2019 at 21:27):
ERläuterung Beihilfe (-versicherung)
Die Beihilfe ist bei der Krankenversicherung eine Erstattungsversicherung.
D.h. die Rechnung geht an den Patienten selbst und dieser reicht die Rechnung an seine Beihilfekasse zur Erstattung ein.
Die Erstattung erfolgt aber nicht zu 100%, so daß der Patient einen Rest selbst bezahlen muss oder dafür einen private Zusatzversicherung abschliesst.
Stefan Lang (Oct 21 2019 at 22:36):
Genau. Deswegen ist das aus Sicht des typischen (Versorgungs-)Leistungserbringers eigentlich kein Unterschied zum Selbstzahler.
Daher vermutlich auch Simones Frage - in welchem Fall muss/möchte man die Beihilfe-spezifischen Informationen überhaupt erfassen?
Die KFRG-Krebsregister haben z.B. hier das Thema, dass sie eine Erstattung erstmal nur von den GKVen bekommen (fall- und ereignisbezogen).
Für die PKVen gibt es zwei mehr oder weniger pauschalierende Vertragsoptionen und die Beihilfe ist wieder anders (bzw. evtl. auch noch nicht endgültig) geregelt. In allen Fällen müssen die Register wissen, welche Kostenträgerart zuständig ist und ggf. weitere Detaildaten zum Kostenträger.
Die Versichertendaten erhalten die Krebsregister aber zusammen mit den medizinischen Daten aus den versorgenden Einrichtungen (Krankenhäusern und Praxen), so dass diese Informationen letztlich auch durch die Leistungserbringer in der Versorgung dokumentierbar/übermittelbar sein muss.
Simone Heckmann (Oct 28 2019 at 09:03):
Genau. Deswegen ist das aus Sicht des typischen (Versorgungs-)Leistungserbringers eigentlich kein Unterschied zum Selbstzahler.
Daher vermutlich auch Simones Frage - in welchem Fall muss/möchte man die Beihilfe-spezifischen Informationen überhaupt erfassen?
Exakt :)
Aber da es einen umschriebenen UseCase dafür zu geben scheint, können wir den Code gerne aufnehmen.
Ist der Display-Value "Beihilfe" ausreichend oder brauchen wir etwas verboseres?
Welches der im Beispiel genannten Daten wären minimal erforderlich, um eine gültige Beihilfe-Coverage anzulegen (Pflichtfelder?)
Simone Heckmann (Dec 09 2019 at 07:35):
Liebe Gemeinde,
wir werden in den nächsten Tagen die Coverage-Profile von STU3 auf R4 migrieren.
Zu den Extensions, die die Inhalte des VSDM-Datensatzes abbilden wurde der Wunsch geäußert, diese in einzelne Extensions anstatt zweier komplexter Extensions aufzusplitten und Coding anstelle des Datentyps code zu verwenden.
Falls dazu noch jemand eine Meinung, Vorschläge oder Einwände hat, so möge er/sie jetzt sprechen...
Simone Heckmann (Dec 09 2019 at 14:18):
Da ich heute leider zu nix komme :angry: bisher nur ein mageres Zwischenergebnis:
Coverage-GKV auf R4 mit den beiden Extensions "einlesedatum-karte" und "kostenerstattung-aerztlich":
(letztere Extension wurde aus der komplexen Extension in STU3 herausgelöst und auf den Datentyp codinggeändert. Das vorgehen für die weiteren Bestandteile der komplexten Extension wäre dann analog...
https://simplifier.net/basisprofil-de-r4/coveragedegkv
....und ein dazu valides Beispiel:
https://simplifier.net/basisprofil-de-r4/coverage-example
Edit: Ich habe die Felder, die bislang den Wertebereich 0..1 (in VSDM Datentyp "booelanInt") hatten auf boolean gesetzt und die Kostenerstattungen ärztlich, zahnärztlich, stationär und veranlasste Leistungen zu einer komplexen Extension zusammengefasst, da das auch im VSDM-Datensatz ein Objekt ist.
Simone Heckmann (Dec 10 2019 at 11:02):
Heute ging's etwas flotter von der Hand.
Hier der das aktuelle (vollständige?) Beispiel einer GKV-Coverage in R4:
https://simplifier.net/ui/publication/show?projectkey=Basisprofil-DE-R4&pubUrlKey=Coverage-example
und das Profil dazu:
https://simplifier.net/ui/publication/show?projectkey=Basisprofil-DE-R4&pubUrlKey=CoverageDeGkv
Erbitte kritische Würdigung...
Simone Heckmann (Dec 10 2019 at 11:53):
Für mehr visuell geneigte Leser gibt's jetzt auch die entsprechenden Kapitel im Implementierungsleitfaden:
https://simplifier.net/guide/basisprofil-de-r4/Versicherungs-Informationen
https://simplifier.net/guide/basisprofil-de-r4/Extensions
Simone Heckmann (Dec 10 2019 at 19:40):
eben hab ich dazu noch ein offenes Issue aus dem letzten Ballot gefunden: https://github.com/hl7germany/basisprofil-de-r4/issues/27
...falls jemand dazu eine Meinung hat...
Last updated: Apr 12 2022 at 19:14 UTC
