Stream: german (d-a-ch)
Topic: Account als Abrechnungsfall?
Simone Heckmann (Dec 08 2016 at 10:16):
...please discuss!
Simone Heckmann (Dec 08 2016 at 10:17):
http://build.fhir.org/account.html
Simone Heckmann (Dec 08 2016 at 10:20):
Account.type würde einen geeigneten Code für "Abrechnungsfall" benötigen, evtl auch verschiedene für Kasse/Privat/ambulant/stationär/ ....Reha?
Simone Heckmann (Dec 08 2016 at 10:20):
Account.active (period) könnte den vom Abrechnungsfall abgedeckten Zeitraum beinhalten (Stichwort "Quartalsfall")
Simone Heckmann (Dec 08 2016 at 10:21):
Account.coverage könnte auf eine oder mehrere Versicherungen verweisen (gesetzlich, privat-Zusatz, Selbstzahler)
Simone Heckmann (Dec 08 2016 at 10:22):
Account.subject (Reference) ist bereits Kardinalität 0..1 kann also nicht auf mehrere Patienten verweisen. Müsste man im Profil des Abrechnungsfalles auf Reference(Patient) constrainen.
Simone Heckmann (Dec 08 2016 at 10:23):
Account.guarantor fliegt raus?
Peter Scholz (Dec 08 2016 at 10:45):
Schnellschuss würde ich sagen:
Account.type = patient
Account .active : Ja
Account.coverage: Ja
Account.gurarantor: ja
Simone Heckmann (Dec 08 2016 at 10:50):
@Bettina Lieske : Von SAP kenne ich es, dass die (multiplen) Versicherungen zu einem Fall mit einer Priorität/Reihenfolge versehen werden. Dazu gäbe es Coverage.order (positiveInt) Wäre das aus eurer Sicht korrekt oder ist das eher ein Attribut von Account?
Simone Heckmann (Dec 08 2016 at 10:57):
Interessanter Gedanke: Da der Reference-Datentyp neuerdings auch logische Identifier enthalten darf, könnten auch Systeme, die mit Account gar nichts am Hut haben, einen oder mehrere Encounter zu einem Abrechnungsfall gruppieren, indem sie unter Encounter.account.identifier einfach die "Fall"nummer eintragen...
Damit könnte man auch "Legacy"-Systemen die neue Struktur beibringen...
Simone Heckmann (Dec 08 2016 at 11:00):
...und damit's jeder kapiert, führen wir im deutschen Encounter-Profil das Suchkriterium Encounter.fallnummer mit target Encounter.account.identifier ein :)
Peter Scholz (Dec 08 2016 at 11:01):
Aus meiner Sicht wäre Coverage.order genau das was VVF.INSRANKCAS entspricht
Peter Scholz (Dec 08 2016 at 11:01):
@Simone Heckmann YES ! (das mit dem Suchkriterium ;) )
Bettina Lieske (Dec 08 2016 at 11:04):
@Simone Heckmann Wir hatten das Ranking der VVs auch eher in der Coverage Resource gesehen.
Stefan Lang (Dec 08 2016 at 11:49):
Account.type: Kasse/Privat wäre IMHO eine Eigenschaft der jeweiligen Coverage. Besteht der Bedarf ambulant/stationär/Reha/... im Account-Kontext abzubilden oder ist das evtl. eher etwas für dem Claim?
Von daher finde ich Peters "patient" passend, differenzierend z.B. gegen "statistics", "controlling" oder wie man das dann nennen mag.
Stefan Lang (Dec 08 2016 at 11:51):
Account.active: würde also für den deutschen Kassenpatienten das jeweilige Quartal umfassen, wohingegen Coverage.period den kompletten Gültigkeitszeitraum der eGK enthält?
Peter Scholz (Dec 08 2016 at 11:55):
Coverage.period würde ich eher für den Zeitraum der Zusage zur Kostenübernahme sehen
Account.active wäre im niedergelassenen Umfeld sicher das Quartal,
bei KH Fällen
vermtl. der Zeitraum von "Fallanlage" bis "Fallabschluss", das kann für ambulante auch das Quartal sein, muss es aber wohl nicht unbedingt
Stefan Lang (Dec 08 2016 at 12:00):
+1 für die Detaillierung Account.active :)
Stefan Lang (Dec 08 2016 at 12:03):
Bei Coverage.period sehe ich gerade, dass wir da noch klären müssen, wie wir eine Coverage interpretieren.
Also: die Zusage zur finanziellen (Teil-/Voll-)Abdeckung eines konkreten "Behandlungsfalls" oder die generische Information über ein Versicherungsverhältnis eines Patienten. Oder beides?
Stefan Lang (Dec 08 2016 at 12:05):
Ist ersteres nicht eher EligibilityResponse?
Stefan Lang (Dec 08 2016 at 12:06):
"The EligibilityResponse resource provides eligibility and plan details from the processing of an EligibilityRequest resource. It combines key information from a payor as to whether a Coverage is in-force, and optionally the nature of the Policy details. "
Stefan Lang (Dec 08 2016 at 12:11):
und die period wäre dann die zugehörige EligibilityRequest.servicedPeriod
Simone Heckmann (Dec 08 2016 at 12:15):
Coverage: definitiv nur die Info, wo der Patient versichert ist. Alles weiter können und wollen die meisten Systeme nicht wissen...
Peter Scholz (Dec 08 2016 at 12:16):
hmmm, die Coverage kann eigentlich nur auf den konkreten Abrechnungsfall bezogen sein,
sonst würde auch die Prioritäten keinen Sinn machen dann da werden die Karten auch jedesmal neu gemischt
EligibilityRequest.servicedPeriod gibt es nicht
Stefan Lang (Dec 08 2016 at 12:16):
http://build.fhir.org/eligibilityrequest.html <== dort schon
Simone Heckmann (Dec 08 2016 at 12:17):
Ja, das Problem des Coverage-Prioritäten-Remixings wurde international schon mal geäußert. Daher meine Frage, ob das nicht eher ein Attribut des Accounts ist.
Simone Heckmann (Dec 08 2016 at 12:18):
Ich glaube dazu gibt es bereits einen Change Request von Cerner oder Epic, da in den USA der Prioritätenkram noch viel krasser ist als bei uns...
Wir könnten uns da sicherlich anschließen, wenn wir das genau so sehen...
Peter Scholz (Dec 08 2016 at 12:18):
@Simone Heckmann ausser dem Abrechnungssystem
@Stefan: ja das ist die Anfrage des Leistungserbringers an die Versicherung nach der Periode für der er eine Coverage möchte
Account hat ja eine 1...n Beziehung zu Coverages und die sind gerankt
Stefan Lang (Dec 08 2016 at 12:24):
@Peter Scholz Mir ging's jetzt nur um die Auffassung, was die Coverage ist, und da scheinst Du gerade orthgonal mit @Simone Heckmann zu divergieren :-)
Das Ranking ist ein separates Thema, hängt aber IMHO von der Interpretation von Coverage ab.
Wenn Coverage sich auf einen "Fall" bezieht, wäre das Ranking bei Coverage sicher angebracht. Wenn Coverage aber nur generell das Versicherungsverhältnis beschreibt, kann das Ranking von "Fall" zu "Fall" variieren, und dann wäre es sicher sinnvoll, das z.B. in Account unterzubringen.
Peter Scholz (Dec 08 2016 at 12:25):
Wenn ich mich noch mal an IS-H erinnere kann man dort Versicherungsverhältnisse sowohl Patienten- als auch Fallbezogen erfassen
das könnten wir auch so abbilden
Coverage.type = patient - Patientenbezogen dann wäre Coverage.period = Gültigkeitszeitraum der Karte und Coverage.order constrained auf 0..0
Coverage.type = accoutn - Fallbezogen dann wäre Coverage.period = Kostenübernahmezeitruam und Coverage.orfer 1..1
Stefan Lang (Dec 08 2016 at 12:27):
Also beides.
Coverage.type ist aber schon preferred für die Art des Versicherungsverhältnisses (für uns GKV/PKV/...)
Stefan Lang (Dec 08 2016 at 12:29):
Brauchen wir dann ein Coverage.realm = (patient|account) ?
Simone Heckmann (Dec 08 2016 at 12:31):
"The Coverage resource is intended to provide the *high level* identifiers and potentially descriptors of an insurance plan." Definitv keine Kostenübernahmen für eine konkrete Behandlung.
Stefan Lang (Dec 08 2016 at 12:33):
Dann wäre die nächste Konsequenz, dass Account sich 0..* auf EligibilityResponse beziehen können sollte. Und dort passt IMHO dann auch der Rank rein.
Peter Scholz (Dec 08 2016 at 12:34):
nee stefan, die Versicherung kann doch in ihrer Response nicht sagen welchen Rang sie einnehmen wird, die kennt ja die anderen gar nicht
zumal die Response selber wieder eine Coverage enthält
Stefan Lang (Dec 08 2016 at 12:36):
Eben. Die Response ist eine konkrete Behandlungszusage im Rahmen eines langfristigen Versicherungsverhältnisses aka Coverage.
Der Rank muss ja nicht in EligibilityResponse hängen, sondern kann im Kontext der Referenz gesetzt werden.
Stefan Lang (Dec 08 2016 at 12:38):
Mal ins grobe:
<coveringEligibilityResponse> <eligibilityResponse ..... /> <rank ..... /> </coveringEligibilityResponse>
Peter Scholz (Dec 08 2016 at 12:39):
Dann frag ich mich nur, wie der Rank es geschafft hat am 11. November den Weg in die Coverage zu finden
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12231&start=0
Peter Scholz (Dec 08 2016 at 12:39):
die eligibilityResponse hat keinen Zeitraum
Simone Heckmann (Dec 08 2016 at 12:40):
@Stefan Lang : wäre das nicht eher Account.coverage = Reference(Coverage|EligibilityResponse) mit zusätzlich einem Rang, der EligibilityResponses und Coverages in eine (gemeinsame) Reihenfolge bringt?
Stefan Lang (Dec 08 2016 at 12:41):
Stimmt, das würde es vereinen und jeder kann's für die konkreten Umstände profilieren
Simone Heckmann (Dec 08 2016 at 12:41):
eligibilityResponse.insurance.benefitBalance.term muss auf DT Period geändert werden
Simone Heckmann (Dec 08 2016 at 12:41):
CodableConcept ist Quark
Simone Heckmann (Dec 08 2016 at 12:42):
Blöder wäre nur noch positiveInt :D
Patrick Werner (Dec 08 2016 at 12:42):
Stefan Lang (Dec 08 2016 at 12:42):
/me fazialpalmiert
Simone Heckmann (Dec 08 2016 at 12:43):
Ich verstehe auch nicht wirklich, was das BackboneElement benefitBalance sein soll. Klassischer Paulismus.
Simone Heckmann (Dec 08 2016 at 12:43):
Oder auch "Knappschaft" genannt :D
Peter Scholz (Dec 08 2016 at 12:47):
nee , ist nur ein bischen verquast
die namen sind einfach völlig daneben
was gemeint zu sein scheint
gilt die Zahlungszusage für
a) das ganze Jahr
b) eine spezifizierte Zahl von Tagen
d) die gesamte Laufzeit des Versicherunsverhältnisses
Stefan Lang (Dec 08 2016 at 12:47):
Naja, mag sein, dass das irgendwo so zutrifft.
Stefan Lang (Dec 08 2016 at 12:48):
Aber entweder braucht EligibilityResponse eine period oder, wie oben schon geschrieben, man verwendet EligibilityResponse.request.servicedPeriod
Stefan Lang (Dec 08 2016 at 12:49):
(STU3!)
Peter Scholz (Dec 08 2016 at 12:52):
wenn dann braucht die Response eine Period,
das andere sind definitiv die Tage, Zeiträume für die der Anfrage die Deckung beantragt hat
allerdings bin ich mir nicht sicher ob es eine DT Period passt,
es gibt auch so komische Zusagen wie für 5 Behandlungstage in diesem Quartal
Stefan Lang (Dec 08 2016 at 12:52):
Für die 5 Behandlungstage hast Du ja term ...
Peter Scholz (Dec 08 2016 at 12:53):
term sagt nur Tage
Peter Scholz (Dec 08 2016 at 12:53):
genauer gesagt "pro Tag"
Stefan Lang (Dec 08 2016 at 12:54):
Korrekt. Da ist keine Mengenangabe assoziiert
Stefan Lang (Dec 08 2016 at 12:57):
Also so?
....benefitBalance.financial.type = "day"
....benefitBalance.financial.benefitUnsignedInt = 5
Stefan Lang (Dec 08 2016 at 12:59):
und zu ergänzen wäre
....benefitBalance.financial.benefitPeriod
Simone Heckmann (Dec 08 2016 at 13:00):
Jetzt mal ein ganz verwegener Gedanke: Ist so eine Zusage nicht eigentlich bezogen auf ein xxxxItem, also eine Leistung, ein Material, eine Behandlung, eine Untersuchung, repräsentiert durch eine Leistungsziffer und eine Anzahl ?
Das Item hätte praktischerweise auch eine period :)
Simone Heckmann (Dec 08 2016 at 13:01):
- ein 'oder mehrere' Items
Stefan Lang (Dec 08 2016 at 13:03):
Puh, die Items der Leistungszusage können wieder was ganz anderes sein als die tatsächlichen Items (ich sag mal: Pauschalen ....).
Ich denke, dafür ist ....benefitBalance.financial.type gedacht.
Stefan Lang (Dec 08 2016 at 13:05):
"Du darfst 5 Tage behandeln" lässt sich schwer in ein konkretes Item packen
Stefan Lang (Dec 08 2016 at 13:05):
(oder mehrere konkrete Items ;-)
Simone Heckmann (Dec 08 2016 at 13:07):
Item.code = "Behandlungstag"
Item.quantity = 5
Simone Heckmann (Dec 08 2016 at 13:08):
"5 Tage im Quartal"
Item.code= Behandlungstag
Item.quantity= 5
Item.period.start=1.1.
Item.period.end=31.3.
Stefan Lang (Dec 08 2016 at 13:09):
Ja, OK, das wäre dann letztlich eine Ummodellierung von benefitBalance.financial
Simone Heckmann (Dec 08 2016 at 13:09):
Dafür muss es doch Codes geben, oder schickt die Kasse "Wir übernehmen 5 Behandlungstage pro Quartal" als Prosa?
Stefan Lang (Dec 08 2016 at 13:10):
<freundlicherZynismus>So wie ich manche Kassen kenne, schicken die Dir das auf einem DIN-A7-Zettel handschriftlich</freundlicherZynismus>
Peter Scholz (Dec 08 2016 at 13:10):
für ambulante ja, wenn es das da gibt
für stationäre bekommst Du eh nur eine Kostenübernahme auf den Fall für einem maximale Anzahl von Tagen
und dann kann man ja Verlängerunsanzeigen / - antworten verschicken
Peter Scholz (Dec 08 2016 at 13:11):
würde ich auch jetzt nicht drüber weiter nachdenken wollen, das bleibt lange im reinen §301 Kommunikationsweg
Stefan Lang (Dec 08 2016 at 13:13):
Aber die Verwendung existierender Codes wäre ja schon schön :)
Simone Heckmann (Dec 08 2016 at 13:52):
Peter Scholz 1:39 PM
Dann frag ich mich nur, wie der Rank es geschafft hat am 11. November den Weg in die Coverage zu finden
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12231&start=0
Die Diskussion, die in GForge dokumentiert ist erläutert das ziemlich genau. (Und folgt im weitesten Sinne unserer Diskussion). Interessant jedoch, dass Brian auf die Möglichkeit verweist, die Priorität über Account abzubilden. Ich frage mal nach, wie das gemeint war...
Peter Scholz (Dec 08 2016 at 15:09):
Dem ist dann ja aber am Ende wohl nicht gefolgt worden
Stefan Lang (Dec 08 2016 at 15:59):
Ich versuche gerade noch zu verstehen, was der verlinkte Zulip-Chat mit dem Tracker-Item zu tun hat (außer ganz am Anfang).
Jedenfalls scheint es nirgendwo eine Rationale zu geben.
Aber vielleicht findet Simone ja was dazu raus.
Peter Scholz (Dec 08 2016 at 16:17):
danke, dann geht nicht nur mir das so, ich dachte schon ich wäre von der ganzen vorangegangenen Diskussion verwirrt 
Simone Heckmann (Dec 09 2016 at 11:34):
Sind wir überzeugt genug davon, dass wir eine Priorität für Account.coverage benötigen?
Falls ja, dann würde ich ein Tracker Item erstellen, damit das nicht verloren geht...
Dort kann ich ja dann auf das andere TI verweisen, in dem von Brian auf dieses nicht vorhandene Feature verwiesen wurde.
Stefan Lang (Dec 09 2016 at 11:46):
+1
Simone Heckmann (Dec 09 2016 at 12:46):
@Bettina Lieske : Wie schaut's bei euch aus?
Peter Scholz (Dec 09 2016 at 12:50):
was mich stutzig macht, der Einwand von Brian wurde aber bei der Behandlung des TI nicht berücksichtigt
Der Einwand war bevor das Ranking bei Coverage eingeführt wurde.
Stefan Lang (Dec 09 2016 at 12:58):
Entweder gibt es einen Grund der nicht kommuniziert wurde, dann möge man unser TI damit ablehnen.
Oder it happened by accident, dann ist es doch gut, das nochmal aufzugreifen.
Simone Heckmann (Dec 09 2016 at 12:59):
Ich hab das bei Brian mal angefragt, aber noch keine Antwort bekommen. Brieftaube findet Neuseeland nicht..?
Peter Scholz (Dec 09 2016 at 13:00):
Ich hab auch nichts dagegen ein TI einzureichen,
war ich nur gestern bei der analyse drüber gestolpert.
Ich bin dazu ansonsten recht wertneutral
Bettina Lieske (Dec 20 2016 at 16:15):
Hallo zusammen, nach Kurzurlaub und vielen Kundenterminen habe ich vesucht, den Stand der Diskussion zu verdauen. Vielleicht kann ich die vorgeschlagenen Ressourcen anhand eines Beispieles besser verstehen.
Nehmen wir einen stationären Aufenthalt an mit einem vorstationären Besuch und einem nachstationären (also 3 Encounter E1, E2, E3).
Beim vorstationären Besuch (E1) wurde eine Beratung gemacht, ein Blutbild und ein Medikament verabreicht.
Beim stationären Aufenthalt (E2) fand die Operation statt, hier wurde ein künstliches Hüftgelenk eingebaut (also Material), OP-Sets, Verbandmaterialien verbraucht und Medikationen gegeben. Weiterhin gab es Pflegeleistungen über die ganze Zeit. Der Patient lag in einem 2-Bett-Zimmer und hatte noch WLAN gebucht.
Beim nachstationären Besuch (E3) wurden die Fäden gezogen und noch eine Wundheilungssalbe verabreicht.
Die 3 Encounters werden über einen DRG mit Zusatzentgelt abgerechnet. Es gibt 2 Rechnungen, einen an die Kasse (DRG und 80% des 2-Bett-Zimmers) und einen an den Selbstzahler (20% des 2-Bett-Zimmers und WLAN).
Wenn ich unser Modell jetzt interpretiere, dann haben wir einen Account und 2 Claims (einen für die Kasse, einen für den Selbstzahler).
Claim 1:
Claim-Item 1.1 = DRG
Claim-Item 1.2 = Zusatzentgelt
Claim-Item 1.3 = 80% des 2-Bett-Zimmers
Claim 2:
Claim-Item 2.1 = WLAN
Claim-Item 2.2 = 20% des 2-Bett-Zimmers.
Stimmt das?
Über was werden die anderen "Leistungen" abgebildet, die nur kostenrelevant sind? Also Medikamente, Beratung, Hüftgelenk, etc....?
Patrick Werner (Dec 21 2016 at 14:22):
Encounter 1-3 gehören zu einer Episode of Care (medizinischer Fall) und verweißen zwecks Abrechnung auf den Abrechnungsfall (Account). Alle Leistungen die erbracht werden werden mittels ClaimItems und Claims (intern) erfasst.
Der Claim referenziert ebenfalls auf den Account.
Zur Abrechnung nach außen (KK bzw. Patient) gibt es auch wieder Claims, welche ClaimItems beeinhalten. Der zweck eines Claims (intern/extern) sollte mittels eines type codings erfasst werden (fehlt noch im aktuellen Entwurf https://simplifier.net/BasisprofilDE/ClaimModel).
Patrick Werner (Dec 21 2016 at 14:24):
*verweisen
Stefan Lang (Dec 22 2016 at 10:01):
"Claim 1" und "Claim 2" oben wären also die externen Abrechnungen. Für die internen Leistungen (Kosten) gibt es einen oder tendenziell eher mehrere Claims, z.B. pro Encounter und leistende Abteilung.
Patrick Werner (Dec 22 2016 at 10:21):
ja genau
Patrick Werner (Dec 22 2016 at 11:52):
aber das Feld "type" welches den Kontext verleiht fehlt noch im aktuellen Entwurf. @Bettina Lieske der Sinn ist hier die 2 Objekte: Claim & ClaimItem wiederverwenden zu können. Man könnte natürlich auch 4 Objekte definieren. Wir denken aber, es ist einfacher nur 2 Objekte zu definieren und diesen je nach Verwendungsart einen Kontext zuzuordnen
Bettina Lieske (Dec 22 2016 at 13:46):
Das ist aus unserer Sicht genauso, auch wir gehen davon aus, dass das ClaimItem internes Rechnungswesen (Kostenrechnung) als auch externes Rechnungswesen repräsentieren kann.
Problematisch ist für uns allerdings, die strikte Hierarchie zwischen Claim und ClaimItems: Aus unserer Erfahrung entstehen ClaimItems zeitlich vor den Claims, im wesentlichen mit Patient- und/oder Encounter-Bezug.
Erst im Rahmen einer Abrechnung entsteht über einen Account der Claim, dem dann die ClaimItems zugeordnet werden.
Aus unserer Sicht fehlt daher im Model der Patient-/Encounterbezug im ClaimItem.
Für den Kostenrechnungsaspekt sehen wir gar keinen Claim (die Kostenanalyse ist dazu viel zu dynamisch und komplex). Der primäre Kostensammler ist für uns der Account selbst. Auf dieser Ebene werden Profitabilitätsbetrachtungen durchgeführt.
Simone Heckmann (Feb 20 2017 at 19:26):
Update: Account hat jetzt Account.coverage.priority(positiveInt) http://build.fhir.org/account.html
Last updated: Apr 12 2022 at 19:14 UTC
