Stream: german (d-a-ch)
Topic: ClaimModel
Simone Heckmann (Dec 07 2016 at 12:52):
~~Der Übersichtlichkeit halber in separatem Thread~~
Wir haben am Claim jetzt noch keine direkte Referenz auf Patient/Encounter/Account/Coverage.
Brauchen wir das?
Peter Scholz (Dec 07 2016 at 12:53):
ja
Stefan Lang (Dec 07 2016 at 12:54):
+1 :D
Peter Scholz (Dec 07 2016 at 12:56):
Nach der ganzen Diskussion von eben bin ich verstärkt zur Überzeugung gekommen, das wir nur Einzelrechnung modellieren
und beim Item eine Referenz auf ein ClaimItem oder einen (Sub)Claim zulassen
Das würde uns erlauben orderedService und providedService nur beim Claim zu benötigen
Simone Heckmann (Dec 07 2016 at 13:00):
Ein rekursiver Claim. Verwegen. 
Stefan Lang (Dec 07 2016 at 13:01):
Was unterscheidet dann einen Claim noch von einem ClaimItem?
Stefan Lang (Dec 07 2016 at 13:01):
(ja, ok, quantity, price usw.)
Simone Heckmann (Dec 07 2016 at 13:01):
Modellierbar wäre das. Aber ist das dann auch noch Implementierbar?
...Wenn man z.B. nach allen GOÄ-Ziffern zu einem Fall suchen will?
Peter Scholz (Dec 07 2016 at 13:03):
nicht unmöglicher als manch andere krude aggregierung
wie alle Prostatauntersuchungen minderjähriger Mädchen oder so
Stefan Lang (Dec 07 2016 at 13:05):
Blöde Frage: Wie kann ich eine Resource referenzieren, die noch gar nicht im Standard existiert?
Stefan Lang (Dec 07 2016 at 13:06):
also Forge model-mäßig
Peter Scholz (Dec 07 2016 at 13:06):
da gibt es doch das "here some magic occurs :D"
Stefan Lang (Dec 07 2016 at 13:06):
Hab ich gemacht, aber er sagt mir, es validiert nicht :D
Patrick Werner (Dec 07 2016 at 13:07):
was Forge validiert und was nicht ist manchmal gewöhnungsbbedürftig. Er valdidiert auch kein slicing ohne discriminator (was aber geht)
Stefan Lang (Dec 07 2016 at 13:08):
Joah, Simplifier frisst es. Nur der Type liest sich etwas grob:
Peter Scholz (Dec 07 2016 at 13:09):
was soll das detail denn da
ClaimItem ist doch die unterste Ebene
Stefan Lang (Dec 07 2016 at 13:09):
https://simplifier.net/BasisprofilDE/ClaimItemModel
(blödes Copy&Paste zwischen VMs)
Stefan Lang (Dec 07 2016 at 13:10):
Verschachtelte Items? detail - subdetail?
Patrick Werner (Dec 07 2016 at 13:10):
kann ich auch Zugriff auf das BasisProfilDE erhalten @Simone Heckmann
Simone Heckmann (Dec 07 2016 at 13:10):
einfach die URL eintragen. Forge gibt nur ne Warnung aus, dass das Target nicht validiert werden kann
Stefan Lang (Dec 07 2016 at 13:11):
@Simone Heckmann Schon erledigt ;-)
Simone Heckmann (Dec 07 2016 at 13:11):
@Patrick Werner : Unser ForgeAccount erlaubt leider maximal 2 Autoren
Peter Scholz (Dec 07 2016 at 13:12):
wenn das überhaupt benötigt wird,
ich fürchte das die das im Claim nur so dumm gemacht haben um sowas wie teil und sammelrechnungen zu modellieren
für mich ist ein ClaimItem eine und genau eine Rechnungsposition
Patrick Werner (Dec 07 2016 at 13:12):
Kein Problem, sobald ich VDSM fertig habe sag ich einfach bescheid, dann könntet ihr das aus meinem Simplifier übernehmen. Ich bastel noch am KFZ Kennzeichen ValueSet
Stefan Lang (Dec 07 2016 at 13:13):
VorratsDatenSpeicherungsManagement? :D
Patrick Werner (Dec 07 2016 at 13:13):
VSDM, ich nenns gleich wieder EGK Datensatz
Stefan Lang (Dec 07 2016 at 13:14):
:D :P
Stefan Lang (Dec 07 2016 at 13:14):
Sorry, ich muss da ein Korinthenk...-Versprechen einlösen :)))
Stefan Lang (Dec 07 2016 at 13:15):
@Peter Scholz Unterpositionen? Kommt sowas vor?
Peter Scholz (Dec 07 2016 at 13:16):
Da bin ich mir nicht sicher, denke aber eher nicht
wenn dürfte Detail dann aber auch nur eine Referenz auf ClaimItem sein, nicht auf Claim !
Stefan Lang (Dec 07 2016 at 13:17):
Gnampf, jup
Peter Scholz (Dec 07 2016 at 13:18):
Ansonsten könnte man wunderbare zirkuläre Bezüge aufbauen, die einen Server mit einer harmlosen Query in den MarvinMode versetzen :D
Simone Heckmann (Dec 07 2016 at 13:18):
Wenn es uns hilft, die Akzeptanz bei FM für unseren Vorschlag zu erhöhen, dann könnte ich das detail tolerieren
Stefan Lang (Dec 07 2016 at 13:18):
@Peter Scholz Das kannste mit jeder Selbstreferenz sowieso
Peter Scholz (Dec 07 2016 at 13:19):
jahaaaaa...
aber dann könnte man es besser verstecken 
Stefan Lang (Dec 07 2016 at 13:20):
(hallendes Lachen aus dem Hintergrund :D)
Stefan Lang (Dec 07 2016 at 13:20):
@Simone Heckmann Ich würd's drin lassen. Und dann einen völlig unbeteiligten fragen lassen, wofür das gut sein soll, um's anschließend wegzudiskutieren ;)
Simone Heckmann (Dec 07 2016 at 13:21):
Um mal kurz zur Eingangsfrage zurückzukommen:
Wir haben am Claim jetzt noch keine direkte Referenz auf Patient/Encounter/Account/Coverage.
Brauchen wir das?
Peter sagt "ja".
Frage: wie heißen die jeweiligen Attribute? Kardinalität? oder ist das alles ein wiederholbares "context"-Attribut mir Referenz auf Wahlweise eine der genannten Resourcen?
Peter Scholz (Dec 07 2016 at 13:23):
Cardinalität m.E. 0..1
Simone Heckmann (Dec 07 2016 at 13:27):
also
Claim.patient 0..1 Referenz (Patient)
Claim.encounter 0..1 Referenz (Encounter)
Claim.account 0..1 Referenz (Account)
...ich denke Coverage ist über Account und Encounter ganz gut abgedeckt. Die Erfordernis für einen direkten Link sehe ich da jetzt nicht. Das kann das sendende System wahrscheinlich in 99% der Fälle ohnehin nicht entscheiden, welche Versicherung da zuständig ist...
Patrick Werner (Dec 07 2016 at 13:28):
Simone Heckmann (Dec 07 2016 at 13:29):
ich vermute, dass wir auch eine Referenz zu "EpisodeOfCare" benötigen, wenn sich die Leistung nicht auf einen konkreten Besuch, sonder auf einen Behandlungsfall bezieht. Ich würde das gerne als
Claim.??? 0..1 Referenz (Encounter|EpisodeOfCare) modellieren, aber mir fällt keine Bezeichnung für ??? ein.
Simone Heckmann (Dec 07 2016 at 13:30):
wie wär's ganz Old School mit Claim.patientVisit?
Bei PV1 weiß ja schon aus Tradition niemand, ob es sich um einen Besuch oder einen Fall handelt :D
Peter Scholz (Dec 07 2016 at 13:31):
eek no
Patrick Werner (Dec 07 2016 at 13:32):
ClaimPatientContext
Patrick Werner (Dec 07 2016 at 13:33):
?
Stefan Lang (Dec 07 2016 at 13:33):
NICHT visit :D
In der Onkologie nennen wir das Erkrankung, aber das passt hier keinesfalls...
Patrick Werner (Dec 07 2016 at 13:34):
Claim.patientCase ?
Simone Heckmann (Dec 07 2016 at 13:34):
nich schlecht...
Stefan Lang (Dec 07 2016 at 13:35):
Case = Fall ist zumindest in den deutschen Köpfen synonym zu Encounter
Stefan Lang (Dec 07 2016 at 13:35):
aber eigentlich passt es ganz gut
Peter Scholz (Dec 07 2016 at 13:36):
a) glaub ich nicht das irgend ein Datenproduzent weiss ob sich das auf einen Besuch oder einen Fall bezieht
b) episodeOfCare ist der Fall
Peter Scholz (Dec 07 2016 at 13:37):
Besuch ist encounter
Peter Scholz (Dec 07 2016 at 13:38):
sorry, aber das muss ich nochmal kontrollieren,
die Definitionen der beiden Resourcen sind mehr als misverständlich
Patrick Werner (Dec 07 2016 at 13:40):
was kontrollieren? Encounter ist der Besuch E.ofCare der Fall.
Peter Scholz (Dec 07 2016 at 13:44):
das ist irgendwie blöde definiert,
und ein besuch ist so richtig nicht dabei
"An Encounter encompasses the lifecycle from pre-admission, the actual encounter (for ambulatory encounters), and admission, stay and discharge (for inpatient encounters). During the encounter the patient may move from practitioner to practitioner and location to location. " - passt zu Fall
Aber:
" The EpisodeOfCare Resource contains information about an association of a Patient with a Healthcare Provider for a period of time under which related healthcare activities may occur.
In many cases, this represents a period of time where the Healthcare Provider has some level of responsibility for the care of the patient regarding a specific condition or problem, even if not currently participating in an encounter. "
das passt nicht wirklich für unsere Episoden unterhalb von Encounter
Patrick Werner (Dec 07 2016 at 13:47):
hmm aber ein Fall kann doch mehrere (ambulante) Aufenthalte beinthalten oder?
Patrick Werner (Dec 07 2016 at 13:48):
Ich hatte Encounter immer als Besuch/Aufenthalt verstanden und E.ofCare als Fall. Vom zeitlichen Scope ist E.ofCare auf jeden Fall > Encounter
Peter Scholz (Dec 07 2016 at 13:53):
eigentlich nicht,
unser System schmeisst da ja einiges an Begriffen in einen Topf die nicht unbedingt was miteinander zu tun haben nämlich Behandlungsfälle und Abrechnungsfälle.
Für ein konkretes Beispiel fehlt hier die med. Grundlage aber,
Es gibt Patienten die zur Behandlung einer Erkrankung in eine Klinik kommen
Je nach Zustand (gemessen über ein Scoring System z.B. Bathel Index) sind sie mal Akut- und mal Reha Patienten. Also in unserem normale Sprech unterschiedliche Fälle
Die EpisodeOfCare wäre dann die Behandlung wegen der Erkrankung A
Die Encounter die verschiedenen Reha- und Akut- Fälle
aber darunter haben wir ja u.U. noch meherer Verlegungen innerhalb der Einrichtung.
Simone Heckmann (Dec 07 2016 at 13:53):
Wenn ihr das in der Breite diskutieren wollt, dann macht 'nen Thread auf :D
Peter Scholz (Dec 07 2016 at 13:55):
geht doch um deine Referenzen zu Encounter und Co,
um darauf zurück zu kommen, m.E. brauchen wir nur eine Referenz auf den (abrechnungs) Fall mehr dürfte schwer zu bestimmen sein
Simone Heckmann (Dec 08 2016 at 14:11):
Lol, ich suche gerade auf Simplifier nach Profilen für Claim, um zu sehen, wie die Resource von anderen Firmen/Projekten/Affiliates genutzt wird.
Genau DAS habe ich erwartet: https://simplifier.net/MAIS-SOPORTEAFACTURA/ItemFacturacion :D
Simone Heckmann (Dec 08 2016 at 14:12):
Aus Item alles bis auf date und quantity raus constrained und dafür vier Extensions rein :D
Stefan Lang (Dec 08 2016 at 14:40):
Simone Heckmann (Jan 17 2017 at 20:30):
Zur Info: Wir hatten heut eine Session mit der Patient Administration Workgroup. Die Notwendigkeit, unseren UseCase zu erfüllen ist allseits akzeptiert. Auch unser Entwurf ist gut angekommen. Einzige Änderung: Der Konsens ist, dass die beiden Resourcen Claim und ClaimItem zu einer einzigen Resource unter dem Namen ChargeItem zusammengefasst werden sollen. Ich habe das bereits entsprechend angepasst und hochgeladen:
https://simplifier.net/BasisprofilDE/ChargeItemModel
Morgen gehen wir damit ins gemeinsame Meeting mit FM. Falls bis dahin noch jemand Kommentare/Änderungswünsche hat: Immer her damit!
Simone Heckmann (Feb 06 2017 at 12:32):
Update: nach der Entscheidung vom WGM, das ChargItem "ChargeItem" zu nennen und dem Hinweis von Lloyd, es mit dem "Event"-Pattern http://build.fhir.org/event.html) abzugleichen, habe ich die Resource überarbeitet und zur Spezifikation hinzugefügt:
http://build.fhir.org/chargeitem.html
Simone Heckmann (Feb 06 2017 at 12:33):
Hat jemand dazu eine Meinung/Vorschlag/Kritik...?
Simone Heckmann (Feb 06 2017 at 12:37):
Momentan fliegt mir der QA-Report noch um die Ohren, weil das RIM-Mapping der Attribute fehlt. :(
Simone Heckmann (Feb 07 2017 at 07:59):
Interessant: Wenn man die EBM-Offline-Version von der KBV herunterläd, wird diese vom Virenscanner (Windows Defender) einkassiert :O
Peter Scholz (Feb 13 2017 at 09:04):
Das sieht doch schon gut aus, wenngleich ich dann doch ein paar Fragen/Anmerkungen habe, die eigentlich alles Kardinalitätsfragen sind:
a) m.E ist status mit card. 1..1 und dann einem Status-Code unknown ziemlich wirr, wäre es da nicht besser das unknown rauszuwerfen und dafür 0..1 zu setzen ?
b) kann es icht eventuell auch gleichzeitig eine Referenz sowohl zum Encounter als auch zur EpisodeOfCare exisitieren
c) kann ein ChargeItem wirklich Bezug zu mehreren Accounts haben ?
Simone Heckmann (Feb 14 2017 at 10:55):
ad a): die Modellierung folgt dem Event-Modell und ist über mehrere Resourcen hinweg gleich, daher würde ich da ungerne ausbrechen. Oder wie wir in Baden sagen: des g'hört so.
ad b) wäre das nicht redundant, da der Encounter bereits auf die EpisodeOfCare verweist?
ad c) laut SAP: "ja" :)
Es könnte zunächst mal zu verschiedenen Accounts verlinkt werden, wenn noch nicht klar ist, ob die Leistung privat oder über die Kasse abgerechnet wird. Der Vorteil einer doppelten Verlinkung wäre dann (im Gegensatz zum Erstellen von Kopien), dass die Ziffer dann auch wirklich nur einmal abgerechnet werden kann.
Peter Scholz (Feb 14 2017 at 15:26):
ad a) das kann ich verstehen, find ich aber immer noch ein wenig wirr. Das wäre dann aber was für eine generelle Diskussion/Ballot
ad b) da muss ich glaube ich noch mal drüber nachdenken, ob das gleichbedeutend ist, oder aber ob es nicht so sein kann das ein charge Item einen bezug zu einer EpisodeOfCare haben kann die nicht mit dem referenzierten Encounter verknüpft ist (vor allem wenn ich mir c anschaue, gibt es da einen gewissen Verdacht in die Richtung)
ad c) verstanden
Patrick Werner (Feb 15 2017 at 10:43):
ad a) ich finde den expliziten status code unknown sehr wichtig. status nicht zu befüllen kann implizit bedeuten, dass der status unknown ist, kann aber auch bedeuten dass der status vergessen wurde zu setzen.
Stefan Lang (Feb 15 2017 at 13:33):
ad a) Richtig, "unknown" !== NULL
Und was macht man, wenn der Status "vergessen" wurde zu setzen? status="undefined" oder dergleichen?
Peter Scholz (Feb 17 2017 at 09:09):
Mit den verschiedenen Statuswerten habe ich momentan sowieso noch ein Problem, die sind mir wieder zu sehr auf die Abrechnungsicht begrenzt. Wir waren doch davon ausgegangen, das wir das ChargeItem auch für die NT1 Inhalte von DFT Nachrichten sehen, und die werden doch nun mal meist nur für das Controlling genutzt.
Aber der Absender weiss überhaupt nicht ob einzelene Positionen abrechenbar sind oder nicht .
Irgendwie ist mir die Sicht hier doch wieder viel zu monetär
Simone Heckmann (Feb 17 2017 at 19:46):
Warum ist das unklar?
Fall a) ich weiß, dass es sich um ein rein Controlling-relevantes item handelt, das nicht zur Abrechnung verwendet wird -> Stauts = non-billable
Fall b) Absender weiß es nicht -> Status = unknown
Simone Heckmann (Feb 17 2017 at 19:52):
Allerdings sind wir bei der Gestaltung des ValueSets noch relativ frei. Wenn Du Vorschläge hast...
Last updated: Apr 12 2022 at 19:14 UTC
