Stream: german (d-a-ch)
Topic: ChargeItem
Simone Heckmann (Nov 30 2016 at 14:00):
Hallo,
wir wollen zum WGM in San Antonio (13.-20. Januar) ein Proposal für eine ChargeItem Resource einbringen, also das FHIR-Äquivalent des FT1-Segmente in V2. Wer möchte sich daran beteiligen?
Simone Heckmann (Nov 30 2016 at 14:04):
Hier ein ersted Draft: Vorne (blau) die Felder von FT1, hinten (rot) die jeweiligen Attribute der ChargeItem Resource
https://docs.google.com/spreadsheets/d/1CRjbyQfL4s0ZiT509lNIp2BBIHh15ZHDGxCkMdI2cIk/edit?usp=sharing
Peter Scholz (Nov 30 2016 at 14:33):
Da tue ich mir erstmal schwer mit, ich denke das es nur bedingt sinnvoll ist vom Mapping zur Resource kommen zu wollen.
Simone Heckmann (Nov 30 2016 at 14:39):
FM ist auch nicht meine stärkste Seite, aber vielleicht finden wir jemand, der sich mit sowas auskennt?
@Rico Tetmeyer @Bettina Lieske
Ich kann nur Rückschlüsse aus dem ziehen, was ich bei der Nutzung der DFT-Nachrichten beobachte. Demnach würden für die 80% ein Identifier, ein Code, ein Datum, eine Anzahl sowie Referenz zu Patient und Fall genügen.
Peter Scholz (Nov 30 2016 at 14:41):
Dem will ich nicht widersprechen,
frage mich aber was der Unterschied zwischen einer ChargeItem Resource und einer Claim Resource sein soll.
Auf den ersten Blick sehe ich da eigentlich alle die Informationen die Du gerne modellieren möchtest
Simone Heckmann (Nov 30 2016 at 14:43):
Claim ist die komplette Rechnung, die an die Kasse/den Patientn geschickt wird.
Das einzelne ChargeItem ist das, was z.B. ein Subsystem an das Administrative System schickt (eine GOÄ/EBM-Ziffer), die dann vom Administrativen System auf die Rechnung gesetzt wird.
Simone Heckmann (Nov 30 2016 at 14:45):
Dabei hat das Subsystem zunächst mal keine Ahnung davon, an wen die Rechnung geht, oder wir das Abgerechnet wird. Meist werden in den DFT-Nachrichten auch zunächst Hauskataloge verwendet, die dann erst im Administrativen System auf GÖÄ oder EBM gemapped werden (abhängig von der Versicherungsart/Fallart)
Simone Heckmann (Nov 30 2016 at 14:47):
Schätze mal, wir brauchen noch einen Status (charged/billed/balanced)...
Peter Scholz (Nov 30 2016 at 14:50):
Ich bin mir nicht sicher ob wie das brauchen, eine DFT Nachricht ist eigentlich eine Rechnung mit den FT1 Segmenten als einzelne Rechnungspositionen. Die DFT Nachrichten im Haus sind also so etwas wie interne Rechnungen.
Von daher sehe ich immer noch keinen Widerspruch, und wenn ich mir die Inhaltet von 0..* Items ansehe kriege ich dort vermutlich alle Informationen zur einzelnen Leistungsposition unter.
So das wir eigentlich keine redundante Resource brauchen.
Dafür aber vermutlich kostenlos die Verlinkung zu den anderen elementen der DFT Nachricht mit erhalten
Rico Tetmeyer (Nov 30 2016 at 14:51):
Da muss ich leider passen, hab die ganze fhirei auf Q1/2017 verschoben.
Peter Scholz (Nov 30 2016 at 14:52):
Wobei die Inhalte von DFT Nachrichten oftmals auch gar nicht in die Finanzabteilung gehen sonden lediglich zu statistischen Zwecken ans Controlling. Ändert aber nichts an der Tatsache das DFTs eine Rechnung darstellen
Simone Heckmann (Nov 30 2016 at 14:52):
Ich würde perspektivisch eigentlich eher das item-BackboneElement aus Claim in eine 1..* Referenz auf ChargeItem ändern wollen
Simone Heckmann (Nov 30 2016 at 14:54):
Aber für diesen USeCase ist die Claim Resource totaler Overkill
Peter Scholz (Nov 30 2016 at 14:56):
Profilierung ?
Ich bin eher dafür die Zahl der Resourcen endlich zu halten.
Und ich frage mich ob es wirklich Sinn macht eine einzelne Rechnungsposition als Instanz für sich existent zu halten.
Simone Heckmann (Nov 30 2016 at 14:56):
Zudem: Es ist ja gängige Praxis, dass die Positionen aus der "Rechnung" die das Subsystem an das Administrative System schickt, dann zu neuen Rechnungen an den Patienten oder den Kostenträger rekombiniert werden, weshalb sie m.E. auch außerhalb der Claim Resource existieren können müssen...
Peter Scholz (Nov 30 2016 at 14:57):
Das ist ein Argument....
Peter Scholz (Nov 30 2016 at 14:58):
obwohl das wenn nur in DE bei den privaten ein Thema ist. Obwohl das dann oft die Privatabrechnung auf anderem Weg erledigt.
In der Schweiz sieht das sicherlich noch einmal ganz anders aus, vielleicht sollten wir uns deren Use cases auch mal anhören.
Peter Scholz (Nov 30 2016 at 14:59):
Nur das die ja dafür eh die ALIS Schnittstellen nützen und vermutlich von daher nicht an einem Mapping zu FT1 interessiert sind.
Simone Heckmann (Nov 30 2016 at 15:22):
@Oliver Egger ?
Simone Heckmann (Nov 30 2016 at 15:32):
Besteht in der Schweiz ein Interesse, Leistungsdaten per FHIR zu kommunizieren, falls ja, sind die aktuell vorhandenen Resourcen dazu geeignet, falls nicht, was müsste geändert werden?
Peter Scholz (Nov 30 2016 at 15:36):
Aus den Überlegungen grade wird mir mal wieder eine Falle bei dem Mapping basierten Ansatz klar.
Es gibt nicht unbedingt immer und zwangsläufig genau eine Resource auf die ein V2 Segment gemapt werden muss sonder das kann durchaus auch noch use case abhängig sein. Oftmals hat man in V2 halt was hergenommen, was dem was man kommunizieren wollte inhaltlich nahe kam. Das können in FHIR durchaus auch mal völlig unterschiedliche Resourcen sein, oder manchmal muss man auch den Context der gesamten V2 Nachricht sehen.
Oliver Egger (Nov 30 2016 at 15:38):
Hallo @Simone Heckmann . Ich kenne micht mit V2/FT1 in der Schweiz nicht aus, ich weiss das wir dafür ein eigenes Gremium haben (http://www.alis-connect.ch/), versuche in Erfahrung zu bringen wie das funktioniert. Für Rechnungen haben wir hier ein der Schweiz einen Standard (XML4.x) der aber nicht auf HL7 basiert.
Simone Heckmann (Nov 30 2016 at 15:39):
Ja, ich denke auch nicht, dass wir uns sklavisch an die V2 Vorgaben halten müssen. Ich hatte den Ansatz eher als Checkliste gedacht, um zu sehen, was wir im Kontext von Leistungsdaten alles benötigen. Die Frage "wo finde ich Leistungsdaten" in FHIR habe ich inzwischen schon öfter gehört, daher denke ich schon, dass es einen UseCase für ChargeItems gibt...
Simone Heckmann (Nov 30 2016 at 15:46):
@Peter Scholz : Wir sind in der Diskussion mit PA sogar inzwischen davon abgerückt, das Ding BillableItem zu nennen, da es - wie Du bereits sagtest - häufig auch nur zu statistischen Zwecken oder der internen Leistungsverrechnung dient und damit ggf. nie wirklich in einer Rechnung landet...
Peter Scholz (Nov 30 2016 at 16:03):
Das vorgehen ist sicherlich auch noch was wo wir morgen drüber reden könnten / sollten
Stefan Lang (Nov 30 2016 at 19:54):
Abrechnung ist zwar nicht mein primärer Fokus (solange es nicht um Krebsregister/GKV geht ...), aber Claim erscheint mir nach wie vor sehr überfrachtet. Von daher +1 für den Ansatz, sich damit zu befassen.
Stefan Lang (Nov 30 2016 at 19:57):
Grundsätzlich finde ich den Ansatz auch gut, ein Claim|Bill(able)Item zu haben, denn das kann u.U. seine eigene Historie haben und ggf. in mehreren Forderungen auftauchen (z.B. bei Ablehnung aus formalen Gründen usw.). So ist es jedenfalls in der KR-Abrechnung geregelt.
Stefan Lang (Nov 30 2016 at 19:58):
Und es würde Claim an einer IMHO sinnhaften Stelle aufdröseln
Simone Heckmann (Nov 30 2016 at 20:18):
Ja, vor allem die Verschachtelung von item, detail und subdetail, was letzten Endes nur hierarchisch angeordnete items sind...
Stefan Lang (Nov 30 2016 at 20:30):
... was sich nur mit einer separaten Resource auflösen lässt.
Stefan Lang (Nov 30 2016 at 20:34):
Die References in Seq# 20 und 21 sind im Sheet evtl. etwas unglücklich platziert, da regt sich erstmal spontaner Widerstand, wenn Stellen/Personen auf Procedures, Requests usw. gemappt werden. Ist aber klar, dass die dort wiederum referenzierten Stellen/Personen gemeint sind. Das könnte man für ein proposal sicher noch detaillerter referenzieren
Oliver Egger (Dec 01 2016 at 06:36):
@Simone Heckmann : Beat Heggli und Christian Kohler haben verdankenswerterweise mir folgende Hintergrundinformationen bezüglich der Leistungsübermittlung in der Schweiz geliefert:
"Es gibt in HL7 v2 zwei Kapitel mit Leistungsübermittlung.
Chapter 6, entspricht der Kommunikation im Spital zwischen Spezialapplikation und Adminsitrativsystem. Das haben wir aufgrund gewisser Unzulänglichkeiten in HL7 v2 mit ALIS-Connect umgesetzt. Dies vorallem aufgrund des TarMed (Tarifsystem für ambulante Leistungen), diese können auch bei der Leistungsübermittlung beim Spital vorkommen. Es gibt aber durchaus Implementierungen in denen das HL7-DFT auch in der Schweiz verwendet wird.
Chapter 16, entspricht der Kommunikation zwischen den Leistungserbringern und den Kassen, das ist das was wir in der Schweiz mit XML 4.x bezeichnen, gemäss Forum Datenaustausch (nicht basierend auf HL7).
Beide Kapitel wurden auch in Version 3 von HL7 implementiert unter den Domänen FIAB und FICR."
Peter Scholz (Dec 01 2016 at 07:57):
Den Ansatz bei der Verlinkung zu Prozedur/Diagnose halte ich nicht für korrekt, hier wäre m.E analog zum Claim die Organisation semantisch richtiger und eingängiger
Bettina Lieske (Dec 02 2016 at 11:58):
Hallo zusammen,
ich denke, wir sehen das ähnlich wie Simone, dass es sinnvoll ist, ChargeItem (wenn das denn der richtige Name ist) und Claim zu unterscheiden.
Vielleicht hole ich ein wenig aus, um unsere Sicht der Dinge zu erläutern:
Wir sehen auf der Seite des klinischen Systems oder der Abteilungssyteme (Labor etc.) ein erbrachtes Produkt, das kommuniziert wird. Also eine Dienstleistung, ein Material (Prothese etc.) o.ä.. Diese Erbringung ist erstmal unabhängig von der Art der Abrechnung und vor allem, davon ob es überhaupt abrechenbar ist oder nur als Teil einer Pauschale oder auch nur auf der Kostenseite betrachtet wird. Diese kann, wie oben beschrieben, in einem Hauskatalog dokumentiert sein.
Dann sehen wir eine Art "Engine", ein Abrechnungssystem, das diese Leistung in etwas abrechnungsrelevantes transformiert, in Abhängigkeit von der Abrechnungsart etc. So können die einzelnen ChargeItems/Leistungen (verwende ich jetzt mal synonym) dann z.B. zu Pauschalen zusammengefasst werden.
Sehr wichtig ist uns hier auch der Kostenaspekt, d.h. manche Leistungen werden nicht abgerechnet werden können, haben aber sehr wohl Kosten verursacht, die man später dem Fall zuordnen möchte.
Peter Scholz (Dec 02 2016 at 12:03):
Dennoch bleibt auch die interne "Leistngsmeldung" eben eine interne Rechnung,
wir waren mehr oder weniger dazu gekommen ChargeItem als ersatz für das Backbone element "item" in der Claim Resource zu sehen
Bettina Lieske (Dec 02 2016 at 12:55):
Aber würde das nicht bedeuten, dass ein ChargeItem nur in Zusammenhang mit einem Claim existieren kann? Und das würde ja der Realität nicht unbedingt entsprechen, oder?
Patrick Werner (Dec 02 2016 at 12:57):
Nein das würde es nicht bedeuten. ChargeItems können für sich stehen. Sie können aber in einem Claim aggregiert werden.
Peter Scholz (Dec 02 2016 at 12:58):
Nicht zwangsläufig,
obwohl mit eigentlich in realitas bisher ja nur DFT Nachrichten untergekommen sind, die aber in der tat nichts anderes
als eine wenn auch nur interne Rechnung darstellen
Bettina Lieske (Dec 02 2016 at 13:39):
Ok, verstehe, d.h. der ChargeItem wäre schon eine eigene Resource. Und wie wäre es dann mit der Kostenseite? Eine Leistung ist ja erstmal erbracht worden, die Interpretation, was die entstandenen Kosten und erzielten Erlöse angeht, ist dann doch unabhängig davon, oder?
Peter Scholz (Dec 02 2016 at 15:02):
Mein Gefühl sagt mir das das außerhalb des scopes der resource wäre
Simone Heckmann (Dec 02 2016 at 18:19):
Hm.. ich denke, das haängt von UseCase ab. Es gibt sicherlich Szenarien, wo bei der Erstellung des CharegeItems schon klar ist, welcher Betrag nachher in der Rechnung dazu erscheint.
In anderen Fällen kennt das Subsystem vielleicht nur einen Code, hat aber keinerlei Kenntnis, zu welchen Beträgen das Item abgerechnet wird.
In wieder anderen Fällen, ist vielleicht ein Grundpreis oder EK-Preis bekannt, der VK-Preis wird dann aber erst bei der Rechnungsstellung im Admin-System festgelegt, weil dieser vielleicht auch von Kriterien abhängig ist, die weit außerhalb der Reichweite des Subsystems liegen (z.B: Fallart, Vereinbarungen mit dem Versicherungsträger, Mengenrabatt usw.)
Ich denke, für den Entwurf der Resource ist es nur wichtig dass wir alle diese Szenarien abdecken können (und mit quantity, totalPrice und unitPrice tun wir das m.E). Was im konkreten UseCase dann tatsächlich vom Subsystem gefüllt werden kann und ob das emfangende System die angegebenen Preise wirklich berücksichtigt, oder ob es die Preise selbst berechnet, das hängt dann vom UseCase bzw. der eigentlichen Implementierung ab...
Ich könnte mir vorstellen, dass das Admin-System ohnehin zunächst mal nur die geposteten ChargeItems speichert und dann beim Fallabschluss irgendein Regelwerk in Gang setzt, dass diese Items "umwandelt" in die tatsächlich abrechenbaren Items, die dann den korrekten Code (EBM/GOÄ), den tatsächlichen Preis, die anwendbaren Zu- und Abschläge enthält und gleichzeitig verhindert, dass das sendende System nach diesem Zeitpunkt nochmal Änderungen an der Resource vornimmt (daher mein Verdacht, dass wir ein status-Attribut brauchen). Diese "umgewandelten" ChargeItems wären dann letztendlich diejenigen, die als Positionen auf der Rechnung erscheinen, also die Komponenten von Claim.
Ob das dann die selben ChargeItems sind, die das Subsystem erstellt hat und somit in der Tat, jedes ChargeItem irgendwann in einem Claim endet oder ob die gewandelten Items Kopien der ursprünglich empfangenen ChargeItems sind, das würde ich der jeweiligen Implementierung überlassen wollen.
In so fern, gäbe es dann schon Items, die außerhalb eines Claims existieren könnten...
Peter Scholz (Dec 02 2016 at 18:40):
Denke mal besser bei den ChargeItems nicht an Rechnungsstellung nach extern, das ist bei uns so gut wie nicht der Fall (ausser für die privatversicherten, und dort eben auch parallel zur DFT Nachricht).
Das was bei uns in der Klinik an Leistungsmeldungen gesendet wird dient maximal der internen Verrechnung oftmals aber einfach nur für die Statistiken des Controllings. Was aber wiederrum nichts daran ändert das eine DFT Nachricht prinzipiell eine (interne) Rechnung ist (auch wenn da kein Geldbetrag steht)
Simone Heckmann (Dec 02 2016 at 20:14):
Wir sollten auch darüber nachdenken, wie sich das z.B. zur Ressource SupplyDelivery verhält...
Simone Heckmann (Dec 05 2016 at 14:28):
Vielleicht wäre es insgesamt mal hilfreich, zunächst die Relationen der Resourcen darzustellen und uns erst im zweiten Schritt über die Inhalte Gedanken zu machen, Also wie stehen Account, Claim, Coverage, ChargeItem, Procedure etc miteinander in Beziehung...?
Oder auch, ausgehend von Peters Anmerkung: Wie würde ein Claim aussehen, der anstelle einer DFT-Nachricht tritt?
Stefan Lang (Dec 05 2016 at 15:12):
Bzw. erstmal ein Klassendiagramm? ArgoUML (cross-platform Java) oder StarUML (Windows, läuft mit Wine) wären Kandidaten, für's Tooling, falls Bedarf besteht.
Simone Heckmann (Dec 05 2016 at 17:28):
Das hier wäre schon mal ein Anfang:
http://build.fhir.org/financial-module.html
Bettina Lieske (Dec 06 2016 at 13:59):
Okay, ich versuch mich mal, habe die Charge einfach mal in das Resourcen-Model reingeklebt.
Und noch ein paar zugrundeliegende Gedanken zur Erläuterung, damit Ihr ggf. bei Euren Kommentaren darauf Bezug nehmen könnt:
(a) ChargeItems sind erbrachte Leistungen oder verwendete Materialien. Sie sind tatsächlich erbracht worden und somit unabhängig von einer möglichen Abrechnung über eine Claim.
(b) ChargeItems können pro Fall oder pro Encounter dokumentiert sein, manchmal vielleicht auch nur direkt am Patienten, wenn das klinische System den Fallzusammenhang gar nicht kennt.
(c) ChargeItems haben einen Code (z.B. Prozedurencode oder GOÄ-Ziffer), einen Erbringungszeitpunkt oder –zeitraum, einen Anfordernden Arzt/Abteilung und eine erbringenden Arzt/Abteilung, eine Menge und ggf. einen Preis.
(d) Wie und ob ChargeItems in ClaimItems umgewandelt werden, hängt von der Abrechnungsart und auch von den Coverage-Information des Patienten ab.
Hier gibt es eine n:m-Beziehung, d.h. eine ChargeItem kann auf mehrere Payer/Insurer verteilt werden oder aber mehrere ChargeItems können zu einem ClaimItem wie einem DRG-Code zusammengefasst werden. Es wird auch (e) ChargeItems geben, die nur dokumentiert werden (z.B. zur internen Leistungsverrechnung wie Peter es sagt), aber nicht über eine Claim abgerechnet werden.
Geht das in die richtige Richtung?Financial_Resources_with_Charge.jpg
Peter Scholz (Dec 06 2016 at 14:08):
Um ehrlich zu sein, sieht mir das viel zu kompliziert aus
Ich sehe überhaupt keinen Unterschied zwischen ClaimItem und ChargeItem, der eine eigene Resource rechtfertigen würde
Beides sind einzelne Positionen in einer Rechnung (einmal interne Verrechnung einmal externe Rechnung) ggf. unterscheiden sich die verwendeten Codesysteme und/oder Preise aber es bleiben in beiden Fällen Rechnungspositionen
Auf das bisherige Resourcenmodel projeziert, würde ChargeItem lediglich die Nodes item, detail und subdetail ersetzen,
d.h ChargeItem würde im Claim einfach referenziert werden
Eine DFT Nachricht lässt sich dann auch einfach auf ein bundle auf einem Claim plus mehreren ChargeItems mappen.
Bettina Lieske (Dec 06 2016 at 14:43):
Vielleicht habe ich da auch einen Denkfehler, aber für mich ist eine Claim eine Zahlungsaufforderung (to claim bedeutet das ja auch), die geprüft wird und auf die eine Überweisung von Geld oder eine Ablehnung folgt.
Das, was ein Labor- oder klinisches System schickt ist für mich qualitativ etwas anderes, da es ja tatsächlich erbracht wurde. Die Interpretation dessen in Form einer Claim, wo Leistungen zusammen gefaßt werden, es Zu- und Abschläge geben kann etc. ist abhängig vom Vertragstyp und kann deshalb stark variieren. Das was tatsächlich erbracht wurde hingegen, ist immer gleich.
Vielleicht liegt es ja auch an den Begrifflichkeiten. Was würde denn ein klinisches System an ein Abrechnungssystem kommunizieren?
Stefan Lang (Dec 06 2016 at 14:48):
Ich würde hier zwischen den Betrachtungsweisen differenzieren. Um bei der Nomenklatur aus dem Diagramm zu bleiben: ein nach extern kommuniziertes ClaimItem ist sicher etwas anderes als ein nur intern kommuniziertes ChargeItem.
Andereseits sind wohl die einzelnen Items so ähnlich, dass man das durchaus mit Hilfe einer Ressource abbilden kann. Dazu evtl. noch einen type, der z.B. zwischen "intern" und "extern" unterscheidet (mal ins Unreine gesprochen).
Stefan Lang (Dec 06 2016 at 14:49):
Die n:m-Beziehung lässt sich ja hervorragend über Referenzen abbilden, also z.B. im Sinn von "extern abgerechnete Leistung x besteht aus den internen Leistungen y1, y2 und y3".
Stefan Lang (Dec 06 2016 at 14:51):
Das wäre dann evtl. eine andere Art Referenz als der Referenztyp "Die interne Leistung y besteht aus y1, y2 und y3"
Simone Heckmann (Dec 06 2016 at 14:53):
Ja, ich denke auch, dass das ChargeItem durch die Referenzierung aus einem Claim "automatisch" zum ClaimItem wird, also beides die gleiche Resource darstellt, vielleicht mit einem unterschiedlichen Status.
Die Pfeile von ChargeItem zu Patient|Encounter|EpisodeOfCare müssten m.E. anders herum sein, oder?
Stefan Lang (Dec 06 2016 at 14:57):
Generell kann es ja auch mehrere Stufen von Charges/Claims geben.
Also z.B. solche Organisationsmodelle, wo jede Abteilung ein Profit Center darstellt und quasi interne Rechnungen an das Klinikum stellt. Und das Klinikum sendet wiederum Rechnungen an die Kostenträger. Von daher könnte ein Abteilungs-ClaimItem gleichzeitig ein Kliniks-ChargeItem sein. Was ebenfalls für eine Resource spricht.
Oder bin ich da auf dem Holzweg?
Patrick Werner (Dec 06 2016 at 14:58):
Ja die Pfeile sollten andersherum sein. Ich sehe aktuell auch noch keinen Grund für 2 Items. Intern/Extern kann aus dem Verweis auf einen Claim entstehen. Wobei der Betrag sich intern/extern unterscheiden könnte
Patrick Werner (Dec 06 2016 at 14:58):
Dann wäre das Vorgehen nicht praktikabel
Stefan Lang (Dec 06 2016 at 14:59):
Der Betrag intern/extern unterscheidet sich definitiv, würde ich sagen ;-)
Daher der Vorschlag mit dem type und den Referenzen
Stefan Lang (Dec 06 2016 at 15:00):
Das ist ja auch im Sheet so drin, Kosten und Preis
Simone Heckmann (Dec 06 2016 at 15:07):
Die Hauptfrage, ob das Item ein BackboneElement bleibt oder eine eigene Resouce wird ist folgende: Würde das Subsystem die Resourcen EINZELN an das Abrechnungssystem POSTEN/UPDATEN? Oder gibt es die Items immer nur im Bauch eines Claims? Ich denke, dass es die meisten UseCases erheblich vereinfachen würde, wenn die Items einzeln kommuniziert werden dürften. Dann wiederum muss aber sichergestellt sein, dass sie alle erforderlichen Informationen enthalten, um ohne den Kontext eines Claims vom empfangenden System korrekt weiterverarbeitet werden zu können.
Stefan Lang (Dec 06 2016 at 15:13):
Darf ich noch ergänzen, dass ein Verzicht auf eine separate Ressource auch implizieren würde, dass diese redundante Hierarchie item / detail / subDetail bestehen bleibt?
Peter Scholz (Dec 06 2016 at 15:14):
Nochmal: Auch die interne Leistungsmeldung ist einfach nur eine Rechnung
Niemand meldet eigentlich ChargeItems einzeln im Normalfall geschieht das bei den DFTs als Rechnung pro Auftrag
Selbst bei suplies ist das eigentlich immer eine Sammelmeldung zu einer bestimmten Massnahme, Auftrag etc
Ich bin durchaus für die einführung einer separaten Resource, da es die Handhabung deutlich verbessern/-einfachen würde selbst wenn die Resource nur im Kontext einer Rechnung lebt.
Peter Scholz (Dec 06 2016 at 15:18):
Vielleicht ist auch Claim einfach die falsche Resource, sondern es wird eine "Invoice" Resource benötigt, um die Verwirrung mit externer Berechnung los zu werden. Mir ist hier der Claim vom Scope her eigentlich zu eng auf die wirkliche Abrechnung mit Versicherern fokussiert.
Peter Scholz (Dec 06 2016 at 15:22):
Ich bin mir auch nicht sicher, ob man den Zusammenhang zwischen internen Leistungen und Rechnung an extern überhaupt in diesem Kontext modellieren muss, das sind eigentlich Dinge die dem jeweiligen Abrechnungssystem intern obliegen und nicht in unserem Datenmodell das sich ja auf Kommunikation bezieht vorkommen müssen.
Ansonsten laufen wir m.E auch schnell in die Gefahr das eine allgemeingültige Definition die unabhängig vom jeweiligen landesspezifischen Abrechnungswesen ist nicht mehr möglich ist.
Bettina Lieske (Dec 06 2016 at 15:24):
Ich denke auch, dass wir nur die Resourcen modellieren sollten, die für die Kommunikation nötig sind und nicht für die Internas. Aber das, was in ein Abrechnungssystem rein geht, sind m.E. Leistungen aus den Subsystemen und was nach außen kommuniziert wird sind Rechnungen und EDI-Nachrichten (was wahrscheinlich das resourcen-mäßig dasselbe ist). Und Ihr meint, das sind beides ClaimItems?
Bettina Lieske (Dec 06 2016 at 15:24):
Und ja, die Pfeile sind falsch herum...
Peter Scholz (Dec 06 2016 at 15:28):
@Simone immer auch daran denken, es geht bei den Leistungsmeldungen nicht nur um Meldungen an Abrechnungsysteme sonder auch z.B, an Controlling und Statistik (bei den GKV Patienten sogar fast ausschliesslich)
@Bettina Lieske meines Erachtens sollte beides in ein wie auch immer benanntes "C***Item" passen sie unterscheiden sich lediglich dadurch das u.U andere Codesysteme für die Kodierung verwendet werden, und das interne Meldungen oft nicht "bepreist" sind sondern nur Stückzahl und Einheit enthalten.
Stefan Lang (Dec 06 2016 at 15:31):
Wie ich Simone kenne, denkt sie an die Persistenz-Möglichkeiten, die man mit FHIR im Unterschied zu v2 hat.
Ich würde die Option, dass irgendwann Abrechnungen mit FHIR-Servern als Persistenz-Layer laufen, nicht ausschließen wollen. Und dann gibt es zu irgendeinem Zeitpunkt im Workflow einzelne Items, die noch keiner Rechnung zugeordnet sind.
Peter Scholz (Dec 06 2016 at 15:33):
Falsch, auch dann sind die immer einer Rechnung zugeordnet, nur nicht der nach draussen (aber dort sind eh transformationen notwendig, die landesspezifisch sind) die möchte ich im Basisstandard nicht definiert sehen.
Peter Scholz (Dec 06 2016 at 15:33):
Die Meldung des ChargeItems ist bereits eine Rechnung, die das meldende System erstellt hat
Stefan Lang (Dec 06 2016 at 15:37):
Korrekt, bei Kommunikation zwischen >= 2 Systemen. Und landesspezifische Dinge gehören ganz sicher nicht in den Basisstandard.
Wenn ich aber so verwegen bin, anstelle einer relationalen Datenbank einen FHIR Server für mein ureigenes Abrechnungssystem zu verwenden, habe ich an der Stelle den Bedarf.
Naja, ist vielleicht zu weit gedacht ;-)
Stefan Lang (Dec 06 2016 at 15:41):
Auf jeden Fall scheinen wir uns alle einig zu sein, dass eine ***Item-Ressource sinnvoll ist.
Peter Scholz (Dec 06 2016 at 15:45):
Wenn ich einen FHIR server für mein ureigenes Abrechnungssystem zu verwenden, dann muss ich mir klar sein, das vielleicht neben den Resourcen noch was notwendig wird.
Aber ja ich denke auch das wir bzgl der ***Item Resource Konsens haben.
Stefan Lang (Dec 06 2016 at 15:50):
Das erstere wäre mal eine schöne Grundsatzdiskussion für das nächste Interop-Abendessen :D
Stefan Lang (Dec 06 2016 at 15:50):
@Bettina Lieske Bezüglich _ein_ vs. _zwei_ ***Items: was genau wären denn die inhaltlichen Unterschiede?
Simone Heckmann (Dec 06 2016 at 16:11):
Sorry Peter, mit der Auffassung "DFT = Claim" komme ich nicht klar.
DFT^P01 = Add Patient Accounts ==> Übertragen auf FHIR ist das ein create einer Account-Resource
DFT^P03 = Post detail financial transaction ==> Da steht doch schon fast Wörtlich, dass ein *Detail* (in den Account) ge*postet* wird
Warum soll das in FHIR etwas anderes sein, als ein ChargeItem (=FT1-Segment) in einen Account zu schreiben?!
Nach meinem Verständnis wurde das FT1 doch gerade deswegen aufgebohrt in RIchtung P11, eben weil die System den Bedarf hatten, die einzelnen Leistungen unabhängig voneinander zu ändern/löschen/hinzufügen.
Mein Verständnis vom Abrechnungsworkflow ist der: Zuerst eröffne ich einen Account. Das ist der Sammeltopf für alles was an (abrechenbaren) Leistungen erbracht wurde. Da kommen die ChargeItems rein.
Und irgendwann kommt jemand und kippt dem Eimer in einen Claim, oder verteilt vielleicht auf mehrere Claims, weil ein Teil von der Kasse und der Rest vom Patienten selbst bezahlt wird.
...oder der Account wird nie geschlossen, weil es sich nur um einen Dummy-Eimer für Statistiken handelt. Oder ein Eimer für irgendwelche Punkte, die am Ende in den Grouper gekippt werden...
Bettina Lieske (Dec 06 2016 at 16:12):
@Stefan Lang Wenn _ein_ die Rechnung (Claim) und _zwei_ die Leistung (Charge) wäre, dann könnte man als inhaltliche Unterschiede folgendes anführen:
- Eine Rechungsposition kann storniert werden, wohingegen eine erbrachte Leistung erbracht wurde, egal, ob sie auf einer Rechnung auftaucht oder nicht.
- Ein schönes Beispiel sind auch Pauschalen, z.B. eine DRG, die hat einen Preis, d.h. das Krankenhaus bekommt diesen Erlös dafür. Was aber alles genau leistungsmäßig erbracht wurde, ist etwas anderes. Diese einzelnen Leistungen haben Kosten und die Summe kann das Haus z.B. mit seinem erwarteten Erlös vergleichen. Wenn wir keinen Unterschied zwischen den Resourcen machen, geht das doch nicht, oder?
- Ein anderes Beispiel ist eine Abrechnungsregel aus dem ambulanten Operieren: hier ist z.B. die erste post-operative Behandlung in der Abrechnungssumme inkludiert. Dennoch wurde aber eine Leistung erbracht, der aber nur Kosten gegenüberstehen und keine direkten Erlöse.
Simone Heckmann (Dec 06 2016 at 16:18):
Mein Verständnis: Wir haben einen Account voller ChargeItems. Und irgendwann wird daraus ein Claim generiert. Dann pickt sich ein Regelwerk alles raus, was abrechenbar ist und macht daraus einen Claim. Dann kommt vielleicht ein anderes Regelwerk und schaut, ob man aus dem Rest noch irgendwas beim Patienten abrechnen kann... Irgendwann sind alle ChargeItems entweder "abgerechnet" oder "storniert" oder als "Nicht abrechenbar" gekennzeichnet und der Account wird geschlossen...
...oder liege ich da jetzt total daneben?
Bettina Lieske (Dec 06 2016 at 16:29):
Hi Simone, ich finde das klingt ziemlich gut :-)
Patrick Werner (Dec 06 2016 at 16:54):
+1 @Simone Heckmann
Stefan Lang (Dec 06 2016 at 17:07):
Ich denke auch, damit lässt sich der Workflow ziemlich gut abbilden.
Der Status ("nicht abrechenbar", "storniert", "abgerechnet", und ich möchte ergänzen "noch nicht abgerechnet") wäre dann ein Merkmal der Item-Ressource?
Stefan Lang (Dec 06 2016 at 17:11):
@Bettina Lieske Ich denke, die Gegenüberstellung Kosten vs. Erlöse bekommt man mit Referenzierung ganz gut in den Griff.
Eine interne Leistung wird erstmal Kosten verursachen, ausgedrückt z.B. durch einen negativen Betrag oder meinetwegen ein Flag.
Eine Gruppe interner Leistungen wird als ein ***Item über eine DRG nach extern abgerechnet (positiver Betrag, "Einnahme"-Flag). Und dieses Item kann ja die internn Kosten-Items referenzieren.
Simone Heckmann (Dec 07 2016 at 08:19):
...natürlich gibt es in der "echten Welt" dann wieder die klassischen Hindernisse, z.B: Woher weiß das Subsystem, auf welchen Account es die Items buchen muss? Was, wenn das Subsystem versucht ein Item zu ändern/löschen, wenn es bereits in einen Claim verschoben/kopiert wurde usw. Aber das ficht uns beim Entwurf der Strukturen zunächst mal nicht an. Das gehört dann in den Implementation Guide. Wichtig ist nur, dass alle Ideen, die uns zum Thema "Abrechnung" umtreiben, über die Struktur modelliert werden können.
Vorschlag: Wollen wir uns mal einen konkreten UseCase vornehmen, um die Kommunikation gedanklich durchzuspielen? z.B. Labor schickt eine GOÄ-Ziffer zur Privatliquidation oder so? @Bettina Lieske: hast du da was?
Simone Heckmann (Dec 07 2016 at 08:21):
...oder wäre es eher typisch, dass das Labor eine Ziffer aus einem Hauskatalog sendet, die dann in GOÄ gewandelt wird? (So kenn ich's von Orbis..)
Peter Scholz (Dec 07 2016 at 08:29):
DFT^P03 postet eine finanzielle Transaktion (Rechnung) an einen Account
diese finanzielle Transaktion enthält mehrere Rechnungspositionen (FT1 Segmente)
Und noch einmal um es ganz eindrücklich zu sagen:
mehr als 90% aller DFT Nachrichten werden ausschliesslich für das Controlling und nicht für eine Abrechnung verwendet.
Peter Scholz (Dec 07 2016 at 08:31):
Die Privatliquidation läuft in den meisten Fällen direkt beim Subsystem (so denn überhaupt ein privatliquidationsberechtiger Laborarzt beteiligt ist)
Peter Scholz (Dec 07 2016 at 08:34):
Mit dem generellen Ansatz das eine P03 Nachricht eine interne Rechnung vom leistungserbringer (labor, radiologie oder was immer) an das zentrale KH Verwaltung ist würden wir uns doch nichts vergeben.
Die Claim Ressource ist meines erachtens gnadenlos überfrachtet und viel zu sehr auf die konkrete Abrechnung zwischen Kostenträger und Krankenhaus ausgelegt. Dies bildet aber in keinster Weise irgend eine andere Rechnungsform die es in Realitas massig gibt ab.
Peter Scholz (Dec 07 2016 at 08:36):
Und noch wichtig, nicht jede Leistung wird einem Fall zugeordnet, es gibt auch noch die kostenstellen bezogene Leistungmeldung. Von funktioniert die Sicht Account voller ChargeItems nicht
Simone Heckmann (Dec 07 2016 at 09:32):
huh? Warum nicht? Ist eine Kostenstellennummer denn nichts anderes als die ID des Accounts dieser Kostenstelle? Kann man doch prima ChargeItems draufballern :)
Peter Scholz (Dec 07 2016 at 09:43):
da würde ich aber wetten, das es die als account Resource in keiner Implementierung geben wird.
das ist jetzt eine ziemliche Vergewaltigung von Ressourcen, der man am Ende nicht mehr den eigentlichen Zweck ansieht.
Warum sich das leben schwerer machen als es in wirklichkeit ist,
Rechnungen sind was völlig normales und kann man auch modellieren, damit deckt man alle Bedürfnisse auch ab.
Und das ein Item in verschiedenen Rechnungen auftaucht (ggf unter Änderung von Mengen, preisen rabatten etc ) ist auch völlig normal.
Mal ganz abstrakt und logelöst vom Gesundheitswesen:
wenn ich meiner Firma 1 Paket Druckerpapier abkaufe bekomme ich von meiner Firma eine Rechnug auf der genau dieses Paket steht.
Dasselbe Paket taucht in einer Rechnung an meine Firma als ein Item in einer Lieferantenrechnug auf (ggf in einer grösseren Verpackungseinheit)
und bei der Rechnung des Herstellers an den lieferanten.
Stefan Lang (Dec 07 2016 at 09:54):
Mal so als Einwurf: es hat doch bestimmt schon mal jemand eine Geschäftsprozess-Modellierung für Krankenhäuser gemacht. Was steht denn da so drin, das man als Grundlage für (FHIR-basierte) Worflows und schlussendlich für die Ressourcen-Spezifikation nehmen kann?
Ich gewinne nämlich den Eindruck, dass hier noch eine gewisse Uneinigkeit diesbezüglich besteht ;-)
Peter Scholz (Dec 07 2016 at 10:00):
zum ersten Teil : glaubst Du das wirklich ??? aber selbst wenn dann nur für Teilaspekte davon
Dein Eindruck trügt nicht,
aber ich fürchte ich bin hier im Kreis vermutlich derjenige der noch den grössten Erfahrungsschatz mit existierenden Leistungsschnittstellen hat
Oftmals werfen selbst die Krankenhausabteilungen die Leistungsbegriffe massiv durcheinander. Die meisten die von Leistungen reden meinen dann nämlich Prozeduren, die dann ja auch zur DRG Ermittlung mit herangezogen werden und keine "Sachleistungen" die fast ausschliesslich zu Controlling Zwecken (was kostet mich mein Labor, und was fordert welche Station so an) genutzt werden.
Stefan Lang (Dec 07 2016 at 10:13):
Sagen wir: ich möchte es gern glauben ;-)
Auf jeden Fall denke ich, dass ein Dokument gut wäre, in dem das Ziel von det janze erstmal beschrieben ist, ganz unabhängig von v2-Messages und -Segmenten oder FHIR-Ressourcen.
Peter Scholz (Dec 07 2016 at 10:19):
Jain,
die V2 Nachrichten spiegeln ja (neben den Schweizer ALIS Nachrichten) das wieder was wirklich an Kommunikation stattfindet
Der "echte" Abrechnungkontext ist da aber eher aussen vor da dies entweder einer irgend gearteten Privatliquidations SW gemacht wird (oft eben bei den Leistungsstellen selber), oder auf den 301er Schienen ausserhalb des normalen Kommunikationsflusses.
Das trifft es aber wieder nur für DE, andere länder andere Sitten
Von daher scheint es mir schwierig einen Ansatz für Abrechnung in allgemeingültig zu finden, es sei denn man löst sich vollständig vom Gesundheitswesen und definiert ganz allgemein wie eine Rechnung als Resourcen abgebildet werden kann. Das ist sicher etwas bei dem auch weltweit ein gemeinsames Verständnis herrschen kann.
Was herauskommt wenn jemand auf die typischen Prozesse seines Landes sieht, kann man am der momentanen Claim Resource sehen.
Simone Heckmann (Dec 07 2016 at 10:28):
@Peter Scholz Du hast ja weiter oben mal angeregt über eine Invoice-Reource als "abgespeckter Claim" nachzudenken. Wenn ich dem mal ein Transaction-Type Bundle voller ChargeItems gegenüberstelle: Was wäre das Delta? Was müsste die Invoice-Resource zusätzlich haben?
Stefan Lang (Dec 07 2016 at 10:28):
Schon klar. Ich denke auch eher an "Reverse Engineering" im Sinn von: "warum sind die v2-Messages so, wie sie sind?".
Die Herausforderung dabei ist, von landesspezifischen Dingen auf das globale zu abstrahieren.
Simone Heckmann (Dec 07 2016 at 10:33):
Ich denke, dass uns FHIR die Mittel und Wege gibt, die Objekte beliebig abstrakt zu definieren und dann landesspezifisch passend zu machen. Mich treibt z.B. von Anfang an der Gedanke, anstelle Referenzen auf dieses und jenes, dem ChargeItem einfach ein 0..* Attribut "context" zu geben, dass eine Referenz auf alles sein kann.
Dann kann ich in einem konkreten Profile slicen und sagen: ein ChargeItem, das eine GOÄ-Ziffer ist, braucht nur eine Referenz auf einen Encounter, ein ChargeItem, das Materialverbrauch meldet, braucht eine Referenz auf eine Kostenstelle und optional einen Patienten usw. usf.
Peter Scholz (Dec 07 2016 at 10:34):
@Stefan Lang das ist ja das was ich die ganze Zeit hier schreibe
@Simone Heckmann alles das was der Rechnung gemeinsam ist : Rechnungdatum, Kunde(Auftraggeber, ordering provider etc), Lieferant ( Order Filler, performing org etc), Auftragsnummer, Auftragsdatum , Patient, Rechnungs-/Transaktions-/Buchungs- nummer
So ad hoc
Simone Heckmann (Dec 07 2016 at 10:36):
Also hätten wir statt ChargeItem eine Charge mit vielen Items :)
Peter Scholz (Dec 07 2016 at 10:36):
Nee,
Peter Scholz (Dec 07 2016 at 10:36):
Charge ist schon semantisch anders belegt.
Simone Heckmann (Dec 07 2016 at 10:37):
Menno.
Stefan Lang (Dec 07 2016 at 10:37):
@Simone Heckmann genau so ist bestimmt die Claim-Ressource entstanden :D
Simone Heckmann (Dec 07 2016 at 10:39):
Dann nennen wir das Ding *Invoice*?
Simone Heckmann (Dec 07 2016 at 10:39):
Ich wäre ja dafür, es *Peter* zu nennen :D
Stefan Lang (Dec 07 2016 at 10:41):
besser gleich DWZ :D
Peter Scholz (Dec 07 2016 at 10:43):
@Stefan Lang ja ist sie mit Sicherheit.
Der Weg ist aber doch so schwierig nicht,
Man nehme die Claim Resource und löse die Item/Detail/Subdetail elemenete heraus und mache dafür eine Resource ChargeItem
dann strippe man die verbleibende Claim Resource noch ein bischen runter und benne sie um, das sie nicht nur den Kostenträgerfall abdeckt sondern jede Form von Rechnungen (wobei die Claims dann nur ein Spezialfall von Invoice wären)
@Simone: grumpf :frowning:
Stefan Lang (Dec 07 2016 at 10:44):
Synonyms for invoice
noun itemized bill
account
check
IOU
note
statement
bill of sale
Peter Scholz (Dec 07 2016 at 10:44):
gibt es eigentlich ein anderes Wort für Synonym ?
Stefan Lang (Dec 07 2016 at 10:44):
Synonyms for claim
noun property, right demanded or reserved
allegation
application
assertion
call
case
demand
interest
petition
plea
request
requirement
suit
affirmation
birthright
counterclaim
declaration
dibs
due
entreaty
lien
part
postulation
prerogative
pretense
pretension
privilege
profession
Simone Heckmann (Dec 07 2016 at 10:45):
Anderes Wort für Synonym: *Peter* :D
Stefan Lang (Dec 07 2016 at 10:45):
Synonyms for synonym
noun analogue
equivalent
metonym
Peter Scholz (Dec 07 2016 at 10:46):
Und wer eklärt am Ende Paul Knapp den Workflow von
Klappe auf -> Claim rein ->Klappe zu ->Müllabfuhr ?
Stefan Lang (Dec 07 2016 at 10:46):
Wer fährt nochmal nach San Antonio? :D
Simone Heckmann (Dec 07 2016 at 10:46):
*Bill* ist nett. Schön kurz. Das Grundsätzliche Vorgehen wie von Peter vorgeschlagen (ChargeItem ausgliedern uns Claim zusammenstauchen) finde ich gut. Wir müssen uns nur seelisch und moralisch darauf einstellen, dass wir an der Claim Resource nicht all zu viel werden rütteln können..
Simone Heckmann (Dec 07 2016 at 10:47):
Das Problem ist, dass es etliche Hersteller gibt, die Claim implementiert haben und die Resource "eigentlich ganz ok" fanden.
Peter Scholz (Dec 07 2016 at 10:48):
Na dann lassen wir dem Paul doch seinen Claim und stecken unseren eigenen ab
Claim wird dann unbenannt in "TRFKACUBN"
Peter Scholz (Dec 07 2016 at 10:49):
Simon lass mich raten : Alle im US/CDN realm ?
Simone Heckmann (Dec 07 2016 at 10:49):
Nee, lustigerweise Frankreich und Argentinien...
Simone Heckmann (Dec 07 2016 at 10:50):
Kann mir jemand für San Antonio einen Helm leihen?
Stefan Lang (Dec 07 2016 at 10:51):
Nimm ordentlich Haarspay, das tut's dann auch :D
Stefan Lang (Dec 07 2016 at 10:52):
Hier mal ein Auszug aus der (relationalen) Tabellenstruktur meines ureigenen kleinen Abrechngunssystems:
bill_billing_items
bill_errors
bill_numbers
billing_items
billing_procedures
billing_sources
bills
Peter Scholz (Dec 07 2016 at 10:53):
Allein das Valueset für Claim.item.service
oder auch
Claim.item.*linkId
stellen mir ja die Nackenhaare auf
Simone Heckmann (Dec 07 2016 at 10:54):
Wollen wir gleich mal anfangen Claim2.0 zu modellieren?
Patrick Werner (Dec 07 2016 at 10:55):
in Sachen BullshitBingo sollte man es Claim4.0 nennen
Stefan Lang (Dec 07 2016 at 10:55):
iHealthClaim4.0, bitte :D
Stefan Lang (Dec 07 2016 at 10:56):
@Simone Heckmann From Scratch oder auf Basis von Claim?
Peter Scholz (Dec 07 2016 at 10:56):
Aber nicht bevor das Modellierungstool für Resourcen nicht mehr excel ist 
Simone Heckmann (Dec 07 2016 at 10:57):
Ich probier's mal mit Forge & LogicalModel...?
Patrick Werner (Dec 07 2016 at 10:57):
trusted claim ;) Kann man dann in der Telekom Cloud hinterlegen. Die haben auch prima Preisstrukturen. Ein von mir gehörter Podcast müste laut Telekom Cloud Conf Tool 2.000.000€ im Jahr zahlen für das Hosting
Stefan Lang (Dec 07 2016 at 10:58):
Forge? Welch absurder Gedanke :D
Simone Heckmann (Dec 07 2016 at 10:59):
Identifier hab ich
Datum hab ich
Auftraggeber: wie nennen wir das, Datentyp ist Referenz auf was? Kardinalität 1..1?
Simone Heckmann (Dec 07 2016 at 10:59):
"orderer"?
Patrick Werner (Dec 07 2016 at 10:59):
requester
Patrick Werner (Dec 07 2016 at 11:00):
wird so auch in der Order ressource genannt
Stefan Lang (Dec 07 2016 at 11:00):
Für die generische Resource würde ich grundsätzlich zu 0..1 tendieren
Peter Scholz (Dec 07 2016 at 11:00):
yep, gibt auch implizite Rechnung ohne orderer
Patrick Werner (Dec 07 2016 at 11:00):
jopps
Simone Heckmann (Dec 07 2016 at 11:01):
https://simplifier.net/BasisprofilDE/ClaimModel
Stefan Lang (Dec 07 2016 at 11:01):
Yeah, fertig :D :D :D
Simone Heckmann (Dec 07 2016 at 11:01):
und requester referenziert auf (Practitioner|Organization|...?)
Patrick Werner (Dec 07 2016 at 11:02):
den Rest macht man dann über Extensions 
Peter Scholz (Dec 07 2016 at 11:04):
braucht man vielleicht gar keinen requester sondern eine Referenz auf einen Request ?
Stefan Lang (Dec 07 2016 at 11:05):
Requested überhaupt jemand eine gesamte Rechnung?
Simone Heckmann (Dec 07 2016 at 11:06):
An einen konkreten Rquest kann ich doch eigentlich nur die Items binden, oder? Dir könnten sich ja auf unterschiedliche Requests beziehen (Stichwort: Sammelrechnung)
Stefan Lang (Dec 07 2016 at 11:07):
Also bitte ein ClaimItemModel und den requester schonmal dort rein werfen
Simone Heckmann (Dec 07 2016 at 11:07):
Das Gegenstück zum requester? filler?
Stefan Lang (Dec 07 2016 at 11:08):
provider?
Peter Scholz (Dec 07 2016 at 11:08):
Nein,
hast Du schon mal eine Rechnung gesehen, bei der an jeder Rechnunsposition ein auftraggeber steht ?
Simone Heckmann (Dec 07 2016 at 11:08):
@Stefan Lang Habe ich das richtig verstanden? Du hast dich gerade freiwillig gemeldet, das ClaimItemModel zu erstellen, oder? :P
Patrick Werner (Dec 07 2016 at 11:08):
requester & performer?
Simone Heckmann (Dec 07 2016 at 11:09):
requester an Claim
request an ClaimItem
Stefan Lang (Dec 07 2016 at 11:09):
Da muss ich erstmal meine Windows-VM hochfahren :D
Simone Heckmann (Dec 07 2016 at 11:10):
ich hab jetzt mal performer mit (Organization|Practitioner)
Simone Heckmann (Dec 07 2016 at 11:11):
Buchungsnummer/Rechnungsnummer etc verschwindet alles in identifier, oder?
Stefan Lang (Dec 07 2016 at 11:12):
Jup
Peter Scholz (Dec 07 2016 at 11:13):
was willst Du denn jetzt mit dem Request am ClaimItem (ausser das man dann keinen requester mehr im Claim bräuchte da der Teil des Requests ist)
Simone Heckmann (Dec 07 2016 at 11:13):
Bezug zu einem Auftrag!?
Simone Heckmann (Dec 07 2016 at 11:14):
...sofern vorhanden.
Falls nicht, dann wird im Claim einfach nur der Auftraggeber genannt...
Peter Scholz (Dec 07 2016 at 11:15):
Normalfall ist doch eine 1:1 Beziehung Auftrag : Rechnung
Patrick Werner (Dec 07 2016 at 11:15):
also eine Reference auf (Organization|Practitioner|Request)
Simone Heckmann (Dec 07 2016 at 11:16):
dann nennen wir's vielleicht lieber orderReference?
Peter Scholz (Dec 07 2016 at 11:16):
@Patrick: nee kann nur Referenz auf *Request sein, darin ist dann ja die auf Organisation / Practiioner
Simone Heckmann (Dec 07 2016 at 11:17):
...wenn's doch abba keinen Request gihibt...?
Peter Scholz (Dec 07 2016 at 11:17):
dann gibt es auch keinen Requester , denn gäbe es einen hätte er ja einen Request gemacht
Patrick Werner (Dec 07 2016 at 11:17):
giihiiiiibt :)
Simone Heckmann (Dec 07 2016 at 11:18):
Wobei: dank der neuen Reference Struktur kann ich ja anstelle einer URL auch einen Identifier angeben.
Wenn ich also die Request Resource nicht kenne, könnte ich dort einfach die Auftragsnummer reinschreiben!
Patrick Werner (Dec 07 2016 at 11:19):
Request wäre dann auch eine neue Resource
Peter Scholz (Dec 07 2016 at 11:20):
nein das ist eine Referenz auf die verschiedenen *Request Resourcen : (SuplyRequest|MedicationRequest|......)
Simone Heckmann (Dec 07 2016 at 11:21):
http://build.fhir.org/references.html#logical (zur Info)
Patrick Werner (Dec 07 2016 at 11:23):
ahhh references mit identitier, eeeendlich.
Patrick Werner (Dec 07 2016 at 11:23):
sehr nice
Simone Heckmann (Dec 07 2016 at 11:25):
dann wäre das Gegenstück zu request...?
-> (MedicationDispense|DiagnosticReport|SupplyDelivery)
Simone Heckmann (Dec 07 2016 at 11:25):
und würde heißen...?
Peter Scholz (Dec 07 2016 at 11:27):
wäre es wohl, aber stellt sich die Frage ob dies benötigt wird,
oder ob wie hier eher am ChargeItem eine performedBy Referenz auf Organization|Practitioner|Device benötigen
Simone Heckmann (Dec 07 2016 at 11:29):
mit 0..* wäre es vertretbar. Ich denke, gerade den Link auf eine durchgeführte Prozedur werden wir irgendwann brauchen...
Simone Heckmann (Dec 07 2016 at 11:29):
ich würde den Namen "service" vorschlagen
Peter Scholz (Dec 07 2016 at 11:31):
würde ich nehmen, alleine weil der so schön mit der Claim Resource clashed (da ist service grade was völlig anderes bei dem sich mir die Frag stellt was das da soll)
Simone Heckmann (Dec 07 2016 at 11:31):
performedBy Organization|Practitioner|Device finde ich gut.
Simone Heckmann (Dec 07 2016 at 11:37):
https://simplifier.net/BasisprofilDE/ClaimModel (F5)
Stefan Lang (Dec 07 2016 at 11:43):
Bin gerade irritiert - service gehört doch eher ins ClaimItem?
Simone Heckmann (Dec 07 2016 at 11:46):
Angenommen, wir haben einen DiagnosticRequest (Laboruntersuchung) und einen DiagnosticReport, dann würden sich der Claim doch auf den (einen) Diagnostic Report beziehen, oder?
Im Falle einer Sammelrechnung (Claim für alle DiagnosticReport eines Patineten/Falls o.ä.) Hätte der Claim dann referenzen zu mehreren DiagnosticReports.
Simone Heckmann (Dec 07 2016 at 11:47):
Wäre es dann zusätzlich erforderlich, die jeweiligen Rechnungspositionen jeweils einem DiagnosticReport zuzuordnen?
Simone Heckmann (Dec 07 2016 at 11:49):
Ich wäre nicht völlig abgeneigt, den Items *zusätzlich* noch eine optionale service-referenz zu geben. Für den Fall, dass... Würde vielleicht auch helfen, wenn man den Claim zerpflückt, damit der Zusammenhang zum service erhalten bleibt...
Stefan Lang (Dec 07 2016 at 11:51):
Wenn ein Claim direkt 0..* auf die Leistungen referenziert und das ClaimItem solche Eigenschaft wie Menge/Einzelpreis/Gesamtpreis hat, wie stellt ClaimItem dann die Beziehung zu den Leistungen her?
Simone Heckmann (Dec 07 2016 at 11:59):
Wie gesagt: wenn das Item das muss, dann können wir ja optional eine service Referenz mit aufnehmen. Wenn sich in einem konkreten UseCase der Claim immer gesamtheitlich auf 'einen' Service bezieht, kann man's ja rausconstrainen
Simone Heckmann (Dec 07 2016 at 12:00):
Nebenbei: wir haben noch keinen Rechnungsempfänger. Dass der Auftraggeber auch der Rechnungsempfänge ist, stimmt zwar im wirklichen Leben meistens, aber im Gesundheitswesen meistens nicht :)
Simone Heckmann (Dec 07 2016 at 12:01):
Obwohl: Da wir die interne Leistungsverrechnung im Fokus haben: Da stimmt's eigentlich...
Peter Scholz (Dec 07 2016 at 12:01):
@Stefan Lang da hab ich jetzt nicht verstanden
Peter Scholz (Dec 07 2016 at 12:03):
Es schadet ja nicht eine 0..1 Relation zu einem Rechnungsempfänger einzubinden, die greift wenn der Auftraggeber aus dem Request nicht der ist wo zahlt :D
Stefan Lang (Dec 07 2016 at 12:03):
Momentan geht's glaub ich ein bisschen durcheinander :D
Stefan Lang (Dec 07 2016 at 12:05):
Also, was ich meinte:
1. Irgendwer erbringt eine Leistung, z.B. einen DiagnosticReport, eine Procedure usw. Das nennen wir jetzt "service"
Stefan Lang (Dec 07 2016 at 12:06):
2. Dieser service is "claimable" oder "billable", wie auch immer. Deshalb wird er in einem ClaimItem referenziert, mit z.B. Anzahl, Kosten, Preis
Stefan Lang (Dec 07 2016 at 12:07):
3. Die ClaimItems werden zu einem Claim zusammengefasst. Entweder 1 ClaimItem in 1 Claim (simpler Fall), oder halt Sammelrechnung 1 Claim, n ClaimItems.
Stefan Lang (Dec 07 2016 at 12:07):
Meine Frage: warum braucht der Claim eine Referenz auf den service?
Stefan Lang (Dec 07 2016 at 12:09):
https://simplifier.net/BasisprofilDE/ClaimItemModel als Startpunkt, btw
Simone Heckmann (Dec 07 2016 at 12:11):
Ich dachte jetzt eher so: Claim verweist auf DiagnosticReport ("Großes Blutbild") und hat n ClaimItems (z.B. für jede Analyse ein Item) die sich aber alle auf den gleichen DiagnosticReport beziehen, also warum das in jedem Item nochmal wiederholen...?
Simone Heckmann (Dec 07 2016 at 12:13):
@Stefan Lang totalPrice 0..* ist das Absicht?
Stefan Lang (Dec 07 2016 at 12:13):
Ups :D
Peter Scholz (Dec 07 2016 at 12:13):
Der Service ist doch nicht die Leistung, sondern der Service besteht aus einer oder mehreren Leistungen
Jetzt mal Laborsprech:
1 Auftrag = 1 Service
hat 1..n Untersuchungen = ChargeItem
1 Sammelrechnung hat n Aufträge mit m Untersuchungen
in dem Fall gibt es den Auftrag nur an der Untersuchung
1 Einzelrechnung hat 1 Auftrag mit n Untersuchungen
da benötigt es den Auftrag nur an der Rechnung
Alternative wäre es eine Rechnung immer nur als Einzelrechnung zu modellieren
und als Item eine Referenz auf ein Item oder eine Rechnung zuzulassen
Peter Scholz (Dec 07 2016 at 12:14):
Noch nicht mal GRosses Blutbild, sondern eher Laborauftrag 4711 - Standardprofil Unfall o.ä
Peter Scholz (Dec 07 2016 at 12:15):
sicher muss das 0..* für die Price dinge sein, wenn etwas nicht bepreist ist dann ist das doch so
Stefan Lang (Dec 07 2016 at 12:16):
0..1 ;)
Peter Scholz (Dec 07 2016 at 12:16):
ahhhh da fiel der Euro centweise ..... :D
Stefan Lang (Dec 07 2016 at 12:17):
Ok, service = "Großes Blutbild".
???? = "Hb, Thrombozyten, Leukozyten, ..."
Simone Heckmann (Dec 07 2016 at 12:17):
...es sei denn: verschiedene Währungen? Nee, oder?
Stefan Lang (Dec 07 2016 at 12:17):
Nah, quatsch. Layer 8 error
Peter Scholz (Dec 07 2016 at 12:17):
Du brauchst im ClaimItem noch
. factor 0..1 decimal Price scaling factor
Peter Scholz (Dec 07 2016 at 12:19):
Service = Befund
das ist ja der Diagnostic Report in unserer Welt
Stefan Lang (Dec 07 2016 at 12:20):
Gut, dann frag ich anders: _was_ wird denn im Claim Item abgerechnet?
Peter Scholz (Dec 07 2016 at 12:20):
Item kann jetzt alles mögliche sein
entweder Hb, Thromobo etc oder um das Leben kompliziert zu machen auch ein "Grosses Blutbild"
Peter Scholz (Dec 07 2016 at 12:20):
und verabschiede dich vom Wort abgerechnet
Peter Scholz (Dec 07 2016 at 12:20):
das ist semantisch vorbelastet
Stefan Lang (Dec 07 2016 at 12:21):
--abgerechnet-- referenziert
Stefan Lang (Dec 07 2016 at 12:22):
Und das nennen wir dann auch "service" oder besser anders?
Patrick Werner (Dec 07 2016 at 12:23):
wieso "service" finde den term sehr verwirrend
Peter Scholz (Dec 07 2016 at 12:24):
Es hängt immer vom Context ab,
aber sowohl bei der Abrechnung als auch für das Controlling ist es eigentlich das grosse Blutbild und nicht die einzelunterschungen
Service ist der gesamte Befund also das was vom Leistungserbringer als ergebnis des Auftrages zurück kommt
@Patrick Werner besserer Vorschlag ?
Patrick Werner (Dec 07 2016 at 12:24):
result?
Peter Scholz (Dec 07 2016 at 12:26):
nein,
a) Result wäre ein einzelnes Ergebnis einer Untersuchung
b) service ist das was als Folge des Auftrages geliefert wurde, das kann ein Befund sein, das kann eine Tüte mit Medikamenten sein, das Reihe von Massnahmen am Patienten sein
Stefan Lang (Dec 07 2016 at 12:26):
performedAction?
Simone Heckmann (Dec 07 2016 at 12:27):
Gehen wir mal zum Beispiel Supply. Da bestellt einer 15 Lappen.
Geliefert werden 10, weil mehr war nicht vorrätig.
Berechnet werden 2 Fünferpacks
Die Rechnung nimmt Bezug auf die gesamte Bestellung, einen Zusammenhang zwischen den Bestellpositionen und den Rechnungspositionen lässt sich hier kaum herstellen.
Ist bei ner normalen Rechnung ja eigentlich auch nicht der Fall, dass jede einzelne Rechnungsposition Bezug nimmt auf eine Auftragsposition, oder?
Simone Heckmann (Dec 07 2016 at 12:29):
also ich finde "service" gut, weil es sowohl auf das Liefern von Dingen als auch das Tun von Dingen passt
Peter Scholz (Dec 07 2016 at 12:30):
Das ist im Laborumfeld sogar noch schlimmer,
Da muss der Befund nicht wirklich noch was mit dem Auftrag zu tun haben.
Da werden im realen Leben angeforderte Untersuchungen rausgeworfen, weil sie in dem Kontext nach Meinung des Laborarztes keinen sinn machen, dafür werden in Abhängigkeit von einzelnen Ergebnissen automatisch weitere Analysen durchgeführt
Stefan Lang (Dec 07 2016 at 12:30):
Die Rechnungsposition muss in irgendeiner Form aussagen, was sie enthält. Also z.B. "5er-Pack Lappen". Wie drücken wir das aus?
Simone Heckmann (Dec 07 2016 at 12:30):
Ist in der Radiologie ja auch nicht anders
Peter Scholz (Dec 07 2016 at 12:31):
und ja, service finde ich hinreichend abstrakt das es auf alle Formen passt
Simone Heckmann (Dec 07 2016 at 12:31):
@Stefan Lang ClaimItem.Code.Display= 5 Lappen
Patrick Werner (Dec 07 2016 at 12:31):
performedService? providedService? Jetzt wo ich den Kontext verstanden habe finde ich Service auch gut. Nur wenn man es pur nutzt ist es glaube ich nicht sonderlich intuitiv verständlich
Peter Scholz (Dec 07 2016 at 12:31):
providedService ist gekauft
Simone Heckmann (Dec 07 2016 at 12:32):
dann nehmen wir requestedService und providedService?
Peter Scholz (Dec 07 2016 at 12:32):
@Stefan Lang @Simone Heckmann vor allem hat der 5erPack Lappen auch garantiert eine eigene Artikelnummer
Simone Heckmann (Dec 07 2016 at 12:34):
ClaimItem.Coding.Code= Artikelnummer
Simone Heckmann (Dec 07 2016 at 12:35):
Achso: Wir haben ja pro Item vermutlich sowohl eine Artikelnummer als auch eine GOÄ, als auch eine hausinterne Ziffer als auch.... Das wäre m.E. dann aber über die coding.system abgebildet.....
Peter Scholz (Dec 07 2016 at 12:37):
Äh,
Nicht eher ClaimItem.Code.coding.code ?
Code ist doch CodeableConcept
Simone Heckmann (Dec 07 2016 at 12:37):
Äh. Ja.
Stefan Lang (Dec 07 2016 at 12:37):
Das sind doch eher unabhängige Systeme?
Simone Heckmann (Dec 07 2016 at 12:38):
Das sind Sozialversicherungsnummer und Führerscheinnummer auch ;-)
Stefan Lang (Dec 07 2016 at 12:39):
Ok, dann wäre ClaimItem.code 1..1
Und ClaimItem.providedService die optionale Referenz
Peter Scholz (Dec 07 2016 at 12:40):
die wir aber wiederrum nur in sammelrechnungen benötigen, sonst kann die in Claim stehen
Simone Heckmann (Dec 07 2016 at 12:40):
Ja, Code ist Pflicht. Wobei CodableConcept streng genommen auch nur aus einem Text bestehen dürfte.
Stefan Lang (Dec 07 2016 at 12:41):
Pflicht, aber nur genau 1x
Stefan Lang (Dec 07 2016 at 12:43):
Braucht ClaimItem ein date?
Also vor dem Hintergrund, dass man bei Rechnungen oft verpflichtet wird, das Leistungserbringungsdatum zu nennen?
Peter Scholz (Dec 07 2016 at 12:43):
ja Start und Ende
Simone Heckmann (Dec 07 2016 at 12:44):
Warum nur ein Code? Darf das Item nicht verschiedene Codesysteme verwenden? Wenn z.B. das Subsystem weiß welche Hauskatalogziffer, GOÄ und EBM Ziffer dem gelieferten/erbrachten Item entsprechen, aber nicht weiß, wie das Ganze am Ende abgerechnet werden soll...? Dann kann sich das empfangende System den passenden Code rauspicken..
Simone Heckmann (Dec 07 2016 at 12:45):
@date: Ja wir brauchen period. manchmal wird statt Anzahl auch die Dauer zur Berechnung hergenommen
Peter Scholz (Dec 07 2016 at 12:45):
Simone:
code.coding[0] , code.coding[1] ....
es bleibt immer noch nur ein code denn es ist immer nur ein Ding was da auf die Rechnung kommt (das hat nur verschiedene namen)
Stefan Lang (Dec 07 2016 at 12:45):
@Peter Scholz ... das natürlich _eigentlich_ schon im providedService enthalten wäre, wenn er denn ........
Stefan Lang (Dec 07 2016 at 12:46):
Zu code 1..1 was Peter sagt
Peter Scholz (Dec 07 2016 at 12:46):
nein,
der wenn der providedService ein Befund ist, dann haben die items sehr unterschiedliche Zeiten
Simone Heckmann (Dec 07 2016 at 12:47):
Ah. Ihr redet von ClaimItem.code. Ich rede von ClaimItem.code.coding.code :D
Stefan Lang (Dec 07 2016 at 12:47):
Ich meinte ClaimItem.providedService
Stefan Lang (Dec 07 2016 at 12:47):
:D
Stefan Lang (Dec 07 2016 at 12:48):
Multithreaded thread .......
Peter Scholz (Dec 07 2016 at 12:48):
mein Gott sie hat es :D
Simone Heckmann (Dec 07 2016 at 12:48):
Ich glaube, wir müssen den Thread eh bald aufsplitten, sonst geht Zulip kaputt
Peter Scholz (Dec 07 2016 at 12:49):
ja aber ClaimItem.providedService ist Quatsch
Stefan Lang (Dec 07 2016 at 12:49):
Zulip ist Software. Software muss das abkönnen :D
Simone Heckmann (Dec 07 2016 at 12:49):
The Rain in Spain Stays Mainly in the Plain...
Stefan Lang (Dec 07 2016 at 12:50):
@Peter Scholz schrub: "die wir aber wiederrum nur in sammelrechnungen benötigen, sonst kann die in Claim stehen"
Peter Scholz (Dec 07 2016 at 12:51):
Stefan: Service = JBOI, Sammelrechnung JBOS
Stefan Lang (Dec 07 2016 at 12:52):
Also wat jetzt? Rein oder raus?
Stefan Lang (Dec 07 2016 at 13:23):
Schon wieder Thread-Wirrwarr ;)
Ich nehme jetzt ClaimItem.providedService raus und dafür erlauben wir sowas wie Claim.subClaim
Bettina Lieske (Dec 07 2016 at 13:23):
Oh weia, da ist man mal einen halben Tag nicht in Zulip und schon völlig abgehängt....
Habe ich das jetzt richtig verstanden, dass es 2 unterschiedliche Resourcen gibt, der ProvidedService und der Claim bzw. ClaimItem?
Das eine wurde erbracht und das andere abgerechnet oder in Rechnung gestellt.
Oder hab ich's nicht kapiert? Sorry, das war einfach zu viel und zu viel Hin und Her für mich...
Patrick Werner (Dec 07 2016 at 13:24):
Es sind 2 resourcen: Claim & ChargeItem
Stefan Lang (Dec 07 2016 at 13:25):
providedService ist nur die Referenz zur erbrachten Leistung, also zu der Ressource, die den medizinischen Inhalt abbildet
Peter Scholz (Dec 07 2016 at 13:26):
Stefan: streiche das Wort Leistung, das hat in diesem Zusammenhang eine andere Bedeutung (und entspricht eher dem ClaimItem)
Stefan Lang (Dec 07 2016 at 13:26):
Dienstleistung. Tätigkeit. Warenlieferung :)
Peter Scholz (Dec 07 2016 at 13:27):
Das Wort Leistung ist im klinischen Bereich verbrannt, vor allem verstehen zu viele Personen viel zu unterschiedliche Dinge darunter
Peter Scholz (Dec 07 2016 at 13:28):
und überhaupt ist der providedService nur das Gegenstück zur Anforderung nicht die einzelne Tätigkeit etc sondern eher der Lieferschein in der Warenwelt
Bettina Lieske (Dec 07 2016 at 13:28):
Okay, vielen Dank. Und wie sind die beiden Resourcen dann definiert? Sorry, hoffe die Frage ist nicht zu doof.
Patrick Werner (Dec 07 2016 at 13:29):
da sind wir gerade dran. Zu definieren wie diese beiden Resourcen aussehen und zusammenwirken
Peter Scholz (Dec 07 2016 at 13:29):
Auf keinen Fall zu doof, wir hauen uns hier ja schon den ganzen Tag die Köppe ein :D
Stefan Lang (Dec 07 2016 at 13:31):
1. Wir ham uns alle lieb.
2. Den halbwegs aktuellen Stand findet man hier:
https://simplifier.net/BasisprofilDE/ClaimModel
https://simplifier.net/BasisprofilDE/ClaimItemModel
Simone Heckmann (Dec 07 2016 at 14:40):
Ich habe soeben nochmal ein update für ClaimModel hochgeladen
Last updated: Apr 12 2022 at 19:14 UTC
