Stream: german (d-a-ch)
Topic: Coverage (Versicherungsverhältnis)
Simone Heckmann (Mar 14 2016 at 17:54):
Hallo,
bitte mal die Augen über die überarbeitete "Coverage" Resource gleiten lassen.
Einige unserer Forderungen vom letzten WGM wurden eingearbeitet (z.B. den direkten Link auf den Patienten), andere nicht (z.B. "bin" in extensions verschieben). Auch die Forderung, den "issuer" in "payor" umzubenennen und sowohl auf Organization als auch auf Patient referenzieren zu lassen, um damit auch Selbstzahlerverhältnisse ausdrücken zu können, ist (noch) nicht wiederzufinden.
Simone Heckmann (May 08 2017 at 11:09):
Hallo,
ich bitte um Input zu der Frage, was wir in einem Basis-Profil für die Coverage-Resource erwarten würden:
http://hl7.org/implement/standards/fhir/coverage.html
Es geht jetzt zunächst mal um allgemeine Dinge, die wir unabhängig von der Art der Versicherung konsistent halten wollen.
Frage 1: Welche Versicherungs-Arten gibt es in DE überhaupt?
Oder, in Tech-Sprech: Welche Codes aus dem ValueSet für Coverage.Type wollen wir zulassen?
Benötigen wir zusätzliche Codes?
http://hl7.org/implement/standards/fhir/valueset-coverage-type.html
Simone Heckmann (May 08 2017 at 11:26):
PAY = Selbstzahler
EHCPOL = private Zusatzversicherung
MANDPOL = gesetzl. Versicherung?
SOCIAL = Sozialamt?
WCBPOL = BG?
...oder finden wir das ValueSet so schräg, dass wir lieber gleich unser eigenes definieren?
Simone Heckmann (May 08 2017 at 13:58):
Es ist ein "Preferred"-Binding, ein eigenes ValueSet zu verwenden wäre daher legal, wenn auch nicht optimal im Sinne einer Interoperabilität jenseits der Landesgrenzen. Allerdings ist es fraglich, in wie weit die korrekte Typisierung deutscher Versicherungsverhältnisse außerhalb Deutschlands eine Rolle spielt.
Simone Heckmann (May 22 2017 at 17:59):
Hallo alle,
bitte um Meinungen hierzu: https://chat.fhir.org/#narrow/stream/implementers/topic/payor's.20bank.20account.20information
Hintergrundinfo: Wir haben dieses Rad erst kürzlich für V2 gedreht, mit folgendem Ergebnis:
http://wiki.hl7.de/index.php?title=SepaHl7V2
Nun geht es darum, das nach FHIR zu übersetzen!
@Peter Scholz : ..und wir dachten, wir hätten's hinter uns :D
Peter Scholz (May 23 2017 at 08:05):
@Simone Heckmann
dafür hab ich eben neben der Ausprägung "DWZ" noch ein
"DWSKGW (der wem sein Konto genommen wird)" gefunden :grin:
Stefan Lang (May 23 2017 at 08:16):
Während Du hier rumalberst, hab ich mal die Struktur beschrieben 
Peter Scholz (May 23 2017 at 08:49):
gefühlt sieht die Struktur einfach falsch aus,
ich weiss nur im Moment noch nicht wie man es besser machen könnte
Meine Bauchschmerzen liegen a) darin das meines Erachtens eine Kontonummer niemals ein Identifier einer Person sein kann (vor allem dann nicht wenn die betreffende Person nicht einmal der Kontoinhaber ist)
Es passt aber eben auch nicht zur Definition von Identifier bei einer Person (A human identifier for this person)
Zudem ist mir das Konstrukt für den von mir beschriebenen komplizierten Fall,
"Mutter ist die Zahlende für ihr Kind, nutzt aber das Konto ihres Lebensabschnittsgefährten für das sie eine Vollmacht hat."
sehr kontraintuitiv.
Irgendwie werde ich hier das Gefühl nicht los, das uns hier einfach noch entweder eine Ressource oder ein Datentyp fehlt
Oder anders augedrückt: Wenn es kompliziert aussieht ist es falsch.
Peter Scholz (May 23 2017 at 08:49):
vielleicht warten wir mal ab, was an input aus anderen Zeitzonen eintrudelt
Stefan Lang (May 23 2017 at 08:57):
Genau, "unverbesserlich hässlich" :-/
Wegen der Identifier-Thematik würde ich wahrscheinlich wirklich eine komplexe Extension bevorzugen. Oder, falls das in die 80% zu packen ist, eine Anpassung/Erweiterung von Coverage.payor.
Ich hoffe wirklich, da kommt aus den anderen Zeitzonen noch was. Heute Nacht wäre ja schon Gelegenheit gewesen ...
Gibt's eventuell jemand speziellen, den man dazu-pingen könnte?
Simone Heckmann (May 23 2017 at 11:35):
Also ich bin ebenfalls der Meinung, dass die gesamte Bank-Verbindungs-Information an die Coverage gehört, nicht an die Person, da niemand eine pauschale Einwilligung erteilt, sich zeitlich unbegrenzt von dessen Konto zu bedienen, sondern die Einzugsermächtigung/Mandatsreferenz/Kreditkarteninformation erteilt man immer zweckgebunden.
Z.B. zum Begleichen der Telefonrechnung. Und eine solche service-bezogene Kostenübernahme entspräche nach meinem Verständnis einer Coverage.
Peter Scholz (May 23 2017 at 12:04):
Sehe ich auch so.
Wir müssen aber aufpassen die korrekten Begrifflichkeiten zu verwenden:
Einzugsermächtigung : gibt es nicht mehr sie wurde ersetzt durch
=> SEPA Mandat --> dieses wird bei dem Gläuber mit einer
==> Mandatsferenz versehen, die der späteren Idenfikation des Mandats dient und die er bei einer SEPA Lastschrift zusammen mit der Gläubiger-ID bei der Transaktion angibt.
Kreditkarteninformation wiederrum ist nichts anderes als eine besondere Form eines Kontos. Wobei es hier aber keinerlei rechtlich sichere Form einer Ermächtigung gibt, es sei denn es wird vom Kreditkarteninhaber ein irgend geartetes schriftliches Dokument mit rechtsverbindlicher Unterschrift ausgefertigt das den Zugriff auf das Kreditkartenkonto regelt. Andernfalls hat der Gläubiger bei dem Einzug via Kreditkartenkonto ein leichtes Beweisproblem wenn er keinen unterschriebenen Transaktionsbeleg vorweisen kann oder die Transaktion online über Kartenleser und PIN autorisiert wurde.
Stefan Lang (May 23 2017 at 12:18):
Was für mich an Coverage nicht schlüssig ist, ist die Kardinalität 0..* von payor. Wenn es mehrere payors gäbe, muss die Bankverbindung irgendwie darauf referenzieren, und das macht es hässlich.
Konsequent wäre ein CRQ für payor 0..1 in Verbindung mit neuen Attributen für die Bankverbindung.
Die Mandatsreferenz wäre dann tendenziell eine Extension. Oder (hier tatsächlich) ein Identifier der Coverage?
Bleibt evtl. noch die Zahlungsmethode, die im deutschen v2-Profil vorkommt
Stefan Lang (May 23 2017 at 12:20):
Ob die Bankverbindung an Coverage oder Coverage.payor hängt, wäre im Grund mit payor 0..1 egal. Ich tendiere dann allerdings auch direkt zu Coverage
Simone Heckmann (May 23 2017 at 12:21):
@Peter Scholz Covereage kann ja auf Contract verlinken, in so fern könnte man schon das schriftliche Dokument mit der rechtsverbindlichen Unterschrift unterbringen....
Simone Heckmann (May 23 2017 at 12:23):
payor 0..* kommt m.W. daher, dass es in den USA nicht unüblich ist, dass Kosten prozentual geteilt werden (50% der Patient, 50% die Versicherung) Das ist bei uns mit Zahn-Zusatz ja ähnlich. Fraglich ist nur, ob man das dann über eine Coverage abbilden muss, oder ob das nicht zwei Coverages sein können, die mit je 50% den gleichen Account abdecken...
Stefan Lang (May 23 2017 at 12:27):
Die prozentuale Verteilung ist in Coverage.payor aber nicht abgebildet, auch nicht die Priorisierung (wenn "eh klar" ist, dass einer 80% übernimmt und einer den Rest) von daher ist es in dieser Form nicht schlüssig. Eine Priorisierung existiert allerdings in Account.coverage ....
Stefan Lang (May 23 2017 at 12:29):
Was imho auf 2 Coverages deutet, mit je einem payor
Peter Scholz (May 23 2017 at 13:44):
Die Verlinkung von Coverage auf Contract ist aber lediglich die rechtsverbindliche Unterschrift für die Kostenübernahme selber, nicht jedoch für eine einzelne Kreditkartentransaktion. Das sind 2 völlig unterschiedliche Paar Schuhe.
De facto wird so was zwar immer wieder gemacht, aber de jure kann das für den Gläubiger ein Problem werden.
Simone Heckmann (Jun 01 2017 at 06:59):
Die Tendenz der Patient Administration WorkGroup geht in die Richtung, ein BackboneElement für Coverage.payor einzuführen, um die Bankdaten zu hinterlegen. Die Frage ist, wie müsste ein solches Element aussehen, um unseren Anforderungen zu genügen?
Mir wäre daran gelegen, dass wir bis spätestens nach dem kommenden Interop-Forum einen Konsens formen, den ich als Vorschlag in die Arbeitsgruppe einbringen kann.
Last updated: Apr 12 2022 at 19:14 UTC
