Stream: german (d-a-ch)
Topic: MI-I-Kerndatensatz: Entgelte
Simone Heckmann (Mar 13 2018 at 12:50):
@Bettina Lieske @Udo Siefker
für den MI-I Kerndatensatz sollen die §21-Entgelte auf FHIR gemapped werden (siehe https://docs.google.com/spreadsheets/d/1SGiSNUL4Y4y_jcr7By2lskDRqPH27BmOEPAFblZedSA/edit?usp=sharing)
Claim halte ich da für suboptimal. Eher ChargeItem...? Hat euerTeam dazu schon eine Meinung?
Birger (Sep 06 2018 at 07:36):
Hallo Simone, kurze Frage zu eurer Modellierung. Ich hätte hier "semantisch" die Verwendung einer Episode of Care zur Repräsentation von administrativen Fällen erwartet und nicht den Encounter. Kannst Du die Abwägung zwischen den Resources kurz erläutern? (Ich frage vor dem Hintergrund, dass wir da pontentiell von den openEHR Archetypen mappen wollen)
Simone Heckmann (Sep 06 2018 at 07:50):
Hi, mir fehlt leider immer noch das Verständnis, was "ein Entgelt" überhaupt ist um die Frage qualifiziert beantworten zu können...
Simone Heckmann (Sep 06 2018 at 07:52):
Grundsätzlich ist in FHIR die EpisodeOfCare der medizinische Behandlungsfall (also z.B. alles was im Kontext der gleichen Primärdiagnose steht: Voruntersuchung+OP+Nach-OP+Kontrolle 1..n
Ein Encounter ist wirklich genau das: Patient kommt und geht wieder (ein ambulanter Besuch oder ein stationärer Aufenthalt oder ein Kontrolltermin.
Mehrere Encounter können also auf die gleiche EpisodeOfCare verlinkt werden.
Simone Heckmann (Sep 06 2018 at 07:55):
Dann gibt es aber noch den "Abrechnungsfall", eine aus medizinischer Sicht völlig willkürliche Zusammenfassung von Encountern, die gemeinsam abgerechnet werden.
Dazu wird in FHIR der Account verwendet. Also man kann mehrere Ecounter unabhängig vom medizinischen Kontext mit einem Account verknüpfen, der dann der Abrechnung dient.
Birger (Sep 06 2018 at 07:55):
Ich denke aus der Sicht einer DRG (wohl der Hauptanteil an den Entgelten) ist hier vermutlich die EpisodeOfCare passender. Ich bin beim Modellieren aber auch gar nicht so sicher, ob ich hier Dinge aus dem klinischen Kontext wiederverwenden möchte, da ich eigentlich im Repository nicht nach administrativen Daten suchen möchte. D.h. man muss überhaupt mal schauen, ob man hier das klinische Konzept einer Diagnose wiederverwenden möchte
Birger (Sep 06 2018 at 07:56):
OK, noch ne dritte Option, auf die war ich bisher nicht gestoßen. Schaue ich mir auch gleich mal an :) Danke für das schnelle Feedback!!
Simone Heckmann (Sep 06 2018 at 07:57):
Leider werden die Begriffe "Abrechnungsfall, Besuch und medizinischer Fall" in DE recht willkürlich zusammengeworfen. Was die meisten KIS-System als "Fall" bezeichnen entspricht wohl am ehesten dem Abrechnungsfall.
Simone Heckmann (Sep 06 2018 at 07:58):
Der Account ist im Prinzip der Eimer, in den alles reinkommt, was im Kontext einer Behandlung abgerechnet werden soll...
Also aus meiner Sicht auch die ermittelte DRG.
Die einzelnen Positionen werden als ChargeItem modelliert.
Birger (Sep 06 2018 at 08:00):
Ja, absolut. Und für die MI-Initiative (zumindest für HiGHmed) ist das auch ziemlich randständig, aber wenn es Richtung administrative Daten geht, müssen wir das ja auch bedienen...
Simone Heckmann (Sep 06 2018 at 08:04):
Ich vermute, ihr verwendet die DRG um Fälle zu klassifizieren, nicht weil ihr ein Abrechnungssystem bauen wollt ;-) Daher ist die Lösung über Account+ChargeItem vermutlich etwas over-engineered.
Die Frage ist: Was genau klassifiziert ein DRG? Und wie wird es in eurem Kontext verwendet?
Birger (Sep 06 2018 at 08:04):
Wobei ich die Account Resource gerade als "Konto" lese...ich denke, das trifft es für den Entgelt Bereich auch nicht wirklich.
Birger (Sep 06 2018 at 08:05):
Es geht ja nicht um unseren spezifischen (HiGHmed-)Kontext, sondern um eine abfragbare Repräsentation des P21 Meldedatensatzes
Birger (Sep 06 2018 at 08:18):
Ich werde aber mal die AG Interoperabilität anhauen, dass wir uns das mal zusammen anschauen. Ich denke, hier brauchen wir den Input aller Konsortien... :D
Simone Heckmann (Sep 06 2018 at 08:19):
ich zitiere mal §21:
je Krankenhausfall einen Datensatz mit folgenden Leistungsdaten [...] e) Aufnahmedatum, Aufnahmegrund und -anlass, aufnehmende Fachabteilung, [...] f) Haupt- und Nebendiagnosen sowie Datum und Art der durchgeführten Operationen und Prozeduren nach den jeweils gültigen Fassungen der Schlüssel nach § 301 Abs. 2 Satz 1 und 2 des Fünften Buches Sozialgesetzbuch, einschließlich der Angabe der jeweiligen Versionen, bei Beatmungsfällen die Beatmungszeit in Stunden entsprechend der Kodierregeln nach § 17b Abs. 5 Nr. 1 des Krankenhausfinanzierungsgesetzes und Angabe, ob durch Belegoperateur, -anästhesist oder Beleghebamme erbracht, g) Art aller im einzelnen Behandlungsfall abgerechneten Entgelte, h) Höhe aller im einzelnen Behandlungsfall abgerechneten Entgelte.
...da hier von "einem Krankenhausfall" (was immer das sein mag) und der Übermittlung eines Aufnahmedatums die rede ist, würde ich das am ehesten als Encounter abbilden. Mehr semantische Differenzierung wird dem Datensatz nicht zu entlocken sein.
Da dieser Encounter nun offensichtlich mehrere Entgelte haben kann und hier obendrein von Beträgen die Rede ist, tendiere ich doch zu der Modellierung mit Account + ChargeItem, wobei der Account vermutlich wenig Infos enthält und hauptsächlich als Verknüpfungspunkt von DRG+Encounter+Kostenträger dient.
Simone Heckmann (Sep 06 2018 at 08:21):
...hast du mal einen Beispieldatenssatz, anhand dessen man die Szenarien durchspielen könnte...?
Simone Heckmann (Sep 06 2018 at 08:26):
um den Teil hier geht's, oder?
pasted image
Simone Heckmann (Sep 06 2018 at 08:38):
...das sieht mir schon ziemlich nach ChargeItem aus:
<ChargeItem> <status value="billed"/> <code> <coding> <system value="http://fhir.de/CodeSystem/DRG"/><!--tbd--> <code value="1234"/><!--Entgeltart--> </coding> </code> <subject> <reference value="Patient/12345"/> </subject> <occurencePeriod> <start value="2018-01-01"/><!--Abrechnung von--> <end value="2018-01-01"/><!--Abrechnung bis--> </occurencePeriod> <quantity> <value value="2"/><!--Entgeltanzahl--> </quantity> <priceOverride> <value value="1.345,69"/> <!--Entgeltbetrag--> <currency value="EUR"/> </priceOverride> <account> <reference value="Account/54321"/> </account> </ChargeItem>
Simone Heckmann (Sep 06 2018 at 08:41):
priceOverride passt natürlich nicht so gut. In FHIR wird davon ausgegangen, dass der Betrag zu einer Entgeltziffer in deren Definition (ChargeItemDefinition) festgelegt ist und nicht nach gusto selbst bestimmt werden kann ;-)
Daher wird der Betrag in einer Instanz normalerweise nicht explizit ausgewiesen, es sei denn, es besteht die erklärte Absicht, den definierten Preis manuell zu überschreiben.
Simone Heckmann (Sep 06 2018 at 08:53):
<Account> <status value="active"/> <!--Link auf Patient--> <subject> <reference value="Patient/12345"/> </subject> <!--Link auf Versicherungsverhältnis--> <coverage> <reference value="Coverage/12345"/> </coverage> <!--Link auf erbringendes Krankenhaus--> <owner> <reference value="Organization/12345"/> <!--eventuell reicht hier auch die IK-Nummer--> <identifier> <system value="http://fhir.de/NamingSystem/arge-ik/iknr"/> <value value="123456789"/> </identifier> </owner> </Account>
Sowohl die ChargeItems als auch der/die Encounter verlinken dann auf den Account.
Patrick Werner (Sep 06 2018 at 09:28):
Da der §21 meines Wissens nach nur eine Struktur für Daten vorgeben soll, und der MI Kerndatensatz ja nichts mit Abrechnung zu tun haben soll, hätte ich spontan gesagt Encounter passt ganz gut.
Patrick Werner (Sep 06 2018 at 09:29):
Episode of Care hingegen geht länger und ist Problemorientiert, fasst also alle Encounter innerhalb eines Problems/Krankheit zusammen.
Stefan Lang (Sep 06 2018 at 09:29):
"Krankenhausfall" alias "Abrechnungsepisode" ist der Encounter.
Etwas anders ist das im Niedergelassenen-Bereich (Praxisbesuch vs. Quartalsabrechnung). Ist aber auch bei Bedarf verschachtelt abbildbar (Encounter.partOf)
Stefan Lang (Sep 06 2018 at 09:30):
" The primary difference between the EpisodeOfCare and the Encounter is that the Encounter records the details of an activity directly relating to the patient, while the EpisodeOfCare is the container that can link a series of Encounters together for problems/issues."
Simone Heckmann (Sep 06 2018 at 09:30):
...ich dachte, die Quartalsfälle wären abgeschafft...?
Simone Heckmann (Sep 06 2018 at 09:32):
Regardless: +1 für Encounter. Aber die DRGs direkt (als Extension?) dort anzubringen, widerstrebt mir...
Simone Heckmann (Sep 06 2018 at 09:33):
...zumal wir den Account ohnehin benötigen, um den Link zur Coverage hinzubekommen...
Stefan Lang (Sep 06 2018 at 09:33):
M.W. gibt es nach wie vor Quartalsabrechnung
Patrick Werner (Sep 06 2018 at 09:34):
neeee. Schön, Encounter, Patient, Condition, Procedure ....
@Birger ihr mappt direkt auf R4 FHIR, oder?
Stefan Lang (Sep 06 2018 at 09:37):
Auf jeden Fall sauber abbilden.
Für Extensions mit Inhalten, die es in anderen Ressourcen bereits gibt, sollte man sehr gute Gründe haben
Simone Heckmann (Sep 06 2018 at 09:45):
Man muss ich halt daran gewöhnen, das die Inhalte des §21-Datensatzes in FHIR in sehr viele Einzelteile zerfallen, was einfach der Tatsache geschuldet ist, dass der Datensatz Informationen zu dutzenden verschiedenen Objekten enthält (Patient, Kostenträger, Fall, Entgelt, Diagnose, Prozedur...) die alle unabhängig von dem Datensatz existieren können.
Aber das wird in OpenEHR sicherlich auch nicht anders sein, wenn ich das Konzept der Artefakte richtig verstanden habe...
Stefan Lang (Sep 06 2018 at 09:46):
Es geht ja doch auch nicht darum, §21 exakt abzubilden, sondern dessen Inhalte sind Grundlage für einen Basis-/Minimaldatensatz, wenn ich es richtig verstehe
Birger (Sep 06 2018 at 11:15):
Ich sehe auch gerade, dass das bei openEHR anders definiert ist als hier. Zitat: "Not to be used to represent the FHIR resource of the same name - there is a mismatch scope and intent" :face_with_rolling_eyes:
Birger (Sep 06 2018 at 11:16):
"Use as a generic document-level container for recording details of a single interaction, contact or care event between a subject of care and healthcare provider(s).
The contact may be face-to-face, via telephone or another electronic medium. Modality can be captured, if required, via the reference model COMPOSITION/mode attribute."
Birger (Sep 06 2018 at 11:25):
@Stefan Lang Ja gut, aber : "when it walks like a duck and quacks like a duck...". Und nach meinem Verständnis (ich bin immer noch recht neu bei FHIR), sieht das bei der Modellierung so aus, als ob das ein(e) FHIR Document/Composition werden soll, oder? Zumindest bei HiGHmed würden wir diese Daten nicht in getrennt in die Patientenakte legen, sondern als zusammenhängenden Report irgendwo hintun.
Simone Heckmann (Sep 06 2018 at 11:32):
Wenn man das als "Dokument" verpacken will, kann man das in FHIR so machen. D.h. die Daten würden schon "getrennt" abgelegt, aber das Dokument würde Sie in einen gemeinsamen Kontext stellen. Und man könnte zum Zwecke des Austausches auch alle Resourcen, auf die eine Composition verweist mit Hilfe der $document-Operation zu einem Paket (Bundle) zusammenschnüren.
Simone Heckmann (Sep 06 2018 at 11:32):
..und signieren, wenn man's braucht.
Stefan Lang (Sep 06 2018 at 11:32):
Exakt, was ich gerade schreiben wollte
Patrick Werner (Sep 06 2018 at 11:34):
+1
Stefan Lang (Sep 06 2018 at 11:34):
Signierfähig ist das Bundle, die reine Zusammenstellung ist durch die Composition definiert.
Simone Heckmann (Sep 06 2018 at 11:36):
Aber es gibt auch andere Möglichkeiten. Wenn es einfach nur darum geht, nachzuhalten, dass diese X Ressourcen aus einem §21-Datensatz heraus erzeugt wurden, dann genügt es, eine Provenance-Resource zu erzeugen, die auf diese Resourcen verweist.
Das würde auch ausreichen, um über die API alle Resourcen anfragen zu können, die zu ein und dem selben §21-Datensatz gehören...
Wenn's Sinn macht, kann sogar der Originaldatensatz in Provenance.entity.whatals Binary abgelegt werden.
Stefan Lang (Sep 06 2018 at 11:40):
Kurz: man braucht den Use Case, dann kann man schauen, mit welchen Mitteln es sinnvoll geklammert werden sollte
Stefan Lang (Sep 06 2018 at 11:42):
Provenance und FHIR document schließen sich auch nicht aus. Es ginge beides parallel.
Simone Heckmann (Sep 06 2018 at 11:47):
Redundancy Department of Redundancy :D
Birger (Sep 06 2018 at 11:47):
Für mich ist eher die Frage, ob man es umgekehrt machen müsste. Zur Erläuterung: wir wollen ja eine elektronische Patientenakte für die Versorgung bauen. Dort würde ich ungerne P21 Daten neben den "richtigen" Behandlungsdaten vorhalten. In der Realität würde ich ja aus der Patientenakte heraus den P21 Report extrahieren und nicht umgekehrt (d.h. ich würde definitiv keinen Importer für P21 Daten nach openEHR wollen). Das heißt, ich würde dort vermutlich irgendwo in der Dokumentation das Geburtsgewicht und Diagnosen drin stehen haben, nur haben die hier keinen Kontext zu P21. Um zum P21 zu kommen, müsste man hier viel anreichern (was ja die Controller machen, um den P21 übermitteln zu können). Also ist dann schon die Frage, ob einige Schlüsselelemente des P21 ausreichen, oder man auch Dinge wie DRG, Entgelte etc. vorhalten muss.
Ich tendiere momentan dazu: P21 abbilden, aber als separaten "Business Intelligence" Report, den ich nicht aus einzelnen Daten des Repository, die auch anderen Zwecken dienen könnten, zusammensetze.
Simone Heckmann (Sep 06 2018 at 11:50):
Oha! Ich dachte immer der UseCase wäre der Massendaten-Import von §21 in ein CDR! :open_mouth:
Stefan Lang (Sep 06 2018 at 11:51):
... weil diese Daten sowieso vorliegen => Minimal Dataset
Birger (Sep 06 2018 at 11:51):
Ja, die CSV in i2b2 reinkloppen machen wir ja. Nur hatte ich es auch so verstanden, dass wir das wohl langfristig vorhalten müssen als Teil des Kerndatensatzes
Stefan Lang (Sep 06 2018 at 11:52):
Die Daten oder die formatierte Struktur mit Daten?
Birger (Sep 06 2018 at 11:52):
Das Problem ist halt, dass die Konsortien da sehr verschieden herangehen. Wir bauen halt ne neue Versorgungsplattform, also eine neue Architektur für Krankenhausinformationssysteme, während andere eher einen Data Warehouse Ansatz fahren
Birger (Sep 06 2018 at 11:53):
Man erstellt ne i2b2 Ontologie aus der Definition und lädt dann die Daten rein
Simone Heckmann (Sep 06 2018 at 11:58):
Das Erstellen von §21-Daten aus einem vorhandenen, FHIR-basierten bzw. -APIsierten Repository heraus klingt für mich eher nach einem "Active Questionnaire". Der Questionnaire definiert welche Daten erfasst werden müssen. Die "active"-Extensions annotieren die einzelnen Questionnaire.items mit FHIRPath-Expressions, wie die Informationen im Repository zu suchen sind, bzw. welche Elemente aus den jeweiligen Ressourcen benötigt werden um eine Frage zu beantworten.
Im Idealfall reicht das aus, um die QuestionnaireResponse direkt vollständig und automatisch auszufüllen. Was im Repository nicht gefunden wird, müsste dann manuell ergänzt werden. Siehe dazu: http://www.healthintersections.com.au/?p=2835
Simone Heckmann (Sep 06 2018 at 11:59):
Die QuestionnaireResponse müsste man dann nur noch durch einen Konverter jagen um die einzelnen Items in eine CSV zu serialisieren...
Birger (Sep 06 2018 at 12:00):
Also quasi ein "on demand" Dokument, oder?
Simone Heckmann (Sep 06 2018 at 12:00):
Nö, ein ausgefüllter Fragebogen :)
Birger (Sep 06 2018 at 12:00):
Ja, aber zur Laufzeit wird der automatisch gefüllt, oder?
Simone Heckmann (Sep 06 2018 at 12:00):
...on demand ausgefüllt...
Simone Heckmann (Sep 06 2018 at 12:01):
Ja. Könnte man an eine Operation koppeln...
Simone Heckmann (Sep 06 2018 at 12:01):
http://myFhirServer.de/Questionnaire/p21/$populate
Simone Heckmann (Sep 06 2018 at 12:02):
z.B. und den Fall, für den der Datensatz erstellt werden soll dann als Parameter übergeben
Birger (Sep 06 2018 at 12:02):
OK, dann mappe ich quasi vom FHIR Interface auf mein openEHR Repository zur Laufzeit anhand eine Active Questionnaire, um eine CSV für einen P21-ähnlichen Datensatz zu erstellen :upside_down_face:
Birger (Sep 06 2018 at 12:03):
Sorry :D
Stefan Lang (Sep 06 2018 at 12:03):
Das erscheint mir ein wenig den Sinn von Questionnaires auf den Kopf gestellt :)
Simone Heckmann (Sep 06 2018 at 12:04):
So hab ich den Use case verstanden :P
Stefan Lang (Sep 06 2018 at 12:04):
Nochmal die Prozesse bitte, um die es geht
Stefan Lang (Sep 06 2018 at 12:05):
A: Der CSV-Datensatz kommt rein, wird auf FHIR gemappt und geht ins Repo
Simone Heckmann (Sep 06 2018 at 12:06):
Die Frage war "Wie kann man über die FHIR API eine CSV aus einem OpenEHR-Repository exportieren", oder? :D
Stefan Lang (Sep 06 2018 at 12:06):
B: Die Daten werden in $whatever Kontext weiter-/wieder-genutzt
Stefan Lang (Sep 06 2018 at 12:07):
C: Die originalen CSV-Daten sollen auch wieder exakt so abrufbar sein
Stefan Lang (Sep 06 2018 at 12:07):
Ja/nein/völlig falsch?
Birger (Sep 06 2018 at 12:07):
Die erste Frage ist: P21 Datensatz exakt vorhalten (CSV import) ODER vorhalten der Daten, die für das Erstellen des P21 gebraucht werden
Stefan Lang (Sep 06 2018 at 12:08):
Richtig. Wenn das nicht klar ist, spekulieren wir hier nur :)
Birger (Sep 06 2018 at 12:08):
Hier ist also die Frage: Report austauschbar machen oder die Quelldaten des Reports
Stefan Lang (Sep 06 2018 at 12:11):
Und die Folgefrage: wird das Original jemals wieder gebraucht?
Birger (Sep 06 2018 at 12:11):
Ich denke auch nicht, dass wir hier zu einer Lösung kommen. Ich glaube für die MI-I ist das auch erstmal OK, wenn man die P21 Daten abrufbar vorhält und einige Bestandteile sind sowieso so basal, dass sie in die Patientenakte gehören. Bleibt nur die Frage, ob man dann das FHIR Mapping auch entsprechend zerlegt auf die einzelnen Ressourcen oder einen zusammenhängenden Report darstellt. Vermutlich muss man beides machen
Stefan Lang (Sep 06 2018 at 12:12):
In FHIR enthält ein zusammenhängender "Report" (also ein "FHIR Document" ohnehin immer die Einzelressourcen
Birger (Sep 06 2018 at 12:13):
Ich denke auch das kommt auf den Use-Case an. Der Wort Case aus meiner Sicht: ein Data Repository mit importierten Daten aus der Patientenakte und dann kommt ein CSV Import der P21 Daten hinzu und ich habe doppelte Resources
Birger (Sep 06 2018 at 12:14):
Ja, das ist auch soweit OK, solange ich nach dem Kontext filtern kann. Oder das vielleicht in eine andere Domäne (z.B. "Administrative Daten") lege.
Stefan Lang (Sep 06 2018 at 12:15):
In der Instanz möglicherweise. Dem kann man aber z.B. mit conditional update und/oder conditional create begegnen
Stefan Lang (Sep 06 2018 at 12:15):
Die entsprechenden Profile braucht es in jedem Fall
Stefan Lang (Sep 06 2018 at 12:20):
Generell muss man da ohnehin aufpassen - Abrechnungsdiagnosen und medizinische Diagnosen sind ja nicht selten inkongruent
Birger (Sep 06 2018 at 12:21):
Mh, ich glaube ich will schon eine Kopie der Daten mit eigener Versionierung haben (gerne auch mit Provenance-Nachweis, wobei das hier extrem schwierig sein dürfte), nur nicht bei Abfragen doppelte Ergebnisse bekommen. Das geht aus meiner Sicht nur durch getrennte Instanzen...
Birger (Sep 06 2018 at 12:22):
Ja, das ist das nächste Problem. Daher vorhin auch meine Anmerkung, ob man wirklich die Diagnosen Resource verwenden möchte für diese Felder, denn semantisch ist eine Abrechnungsdiagnose aus meiner Sicht eben was anderes als eine klinische Diagnose
Birger (Sep 06 2018 at 12:23):
Ich denke da immer etwas im Sinn von Queries: wenn ich da eine Abfrage für einen Patienten stelle "gib mir alle seine Diagnosen aus dem letzten halben Jahr", bekomme ich dann eine verlässliche Antwort beim Nutzen der Resource/Archetype, oder gibt es da semantische Abweichungen.
Stefan Lang (Sep 06 2018 at 12:23):
Beides ist eine FHIR-Condition ;)
Kann man aber entsprechend flaggen
Birger (Sep 06 2018 at 12:25):
Klar, aber dann hat man wieder diese Probleme wie bei CDA, dass man da irgendwo weiter oben ein Flag hat und der fröhliche Forscher bekommt das nicht mit. Aus dem Grund gibt es beispielsweise Diagnose und "Exclusion" Archetypes, um diese Probleme zu verhindern
Stefan Lang (Sep 06 2018 at 12:26):
Also z.B. Condition.category verwenden.
Hat der fröhliche Forscher nicht einen abgeklärten Datenmanager zur Seite, der das weiß? ;)
Stefan Lang (Sep 06 2018 at 12:31):
Blasphemischer: wie kann ich sinnhaft mit Daten forschen, wenn ich die Semantik teilweise ignoriere?
Birger (Sep 06 2018 at 12:31):
Wir würden schon gerne irgendwann self-service haben, zumindest bei Kohorten-Queries...
Simone Heckmann (Sep 06 2018 at 12:32):
Ich teile nicht notwendigerweise die Auffassung, dass Diagnose und Abrechnungsdiagnose das gleiche (=Condition) sein müssen. Gerade in dem hier diskutierten Kontext, wo eine Trennung der medizinischen Sicht und der Abrechnungs-Sicht Sinn macht, könnte man darüber nachdenken, alles Abrechnungsrelevante (was ohnehin meist nur aus Ziffer/Anzahl/Datum besteht) als ChargeItem zu behandeln und nur die qualifizierten medizinischen Diagnosen wirklich als solche zu erfassen. Das würde dann auch das Problem der doppelten Diagnosen umgehen...
Birger (Sep 06 2018 at 12:32):
Nein, die Semantik soll nicht ignoriert werden, aber es gibt ja verschiedene Varianten, wie man es deutlich machen kann, dass es hier Unterschiede gibt
Birger (Sep 06 2018 at 12:34):
@Simone Heckmann ja, das ist genau der Punkt. Oder, wie erwähnt, die erst gar nicht zusammen speichern. In einer relationalen Datenbank könnte man verschiedene Namespaces/Domänen wählen
Stefan Lang (Sep 06 2018 at 12:34):
Simone, geht natürlich auch.
Das ist aber ein generisches Problem. Ich sage nur: Hb auswerten (13,0 - super) und dabei die Labornormalwerte ignorieren (16-18 - ups)
Simone Heckmann (Sep 06 2018 at 12:37):
Beispiel: Eine OPS-Ziffer wird zur Abrechnung in den Account geworfen (ChargeItem) um den Grouper zu füttern. Daneben wir der Eingriff selbst dokumentiert (Procedure) mit allen klinisch relevanten Informationen zu dem Eingriff. Beide Ressourcen haben zwar den selben OPS-Code, aber unterschiedliche Lebenszyklen. Über ChargeItem.service ist der Zusammenhang ersichtlich.
Birger (Sep 06 2018 at 12:39):
Ja, sowas finde ich sinnvoll
Simone Heckmann (Sep 06 2018 at 12:39):
Bei Queries ist ja dann klar, ob man nach ChargeItem?code=1234-5 oder nach Procedure?code=1234-5 sucht. Man könnte sich über den Link dann auch von ChargeItem auf Procedure durchklicken um die Details zu dem Eingriff zu erfahren.
Stefan Lang (Sep 06 2018 at 12:40):
D'accord. Solange in der Realität immer klar ist which is which
Birger (Sep 06 2018 at 12:41):
Ja, das ist doch hier ziemlich eindeutig
Stefan Lang (Sep 06 2018 at 12:43):
Nicht jeder Code aus einer Fachabteilung wird notwendigerweise aus medizinischer Sicht erstellt ;)
Simone Heckmann (Sep 06 2018 at 12:43):
Ich könnte mir auch vorstellen, dass ChargeItems aus den unmöglichsten Gründen geändert, storniert oder als "nicht abrechenbar" gekennzeichnet werden könnten, was auf die Prozedur aus medizinischer Sicht keine Auswirkung haben sollte.
Ich denke, wir tun dem §21 auch kein Unrecht, wenn wir sagen: Die Information, die wir daraus gewinnen besagt nur, dass für den Patienten mal "akuter Blinddarm" abgerechnet wurde. Das legt zwar nahe, dass er diese Diagnose tatsächlich hatte, aber das ist schon fast klinisch fragwürdige Deutung
Birger (Sep 06 2018 at 12:43):
Mir bekannt, ich war ja mal Dokumentar haha
:)
Birger (Sep 06 2018 at 12:44):
@Simone Heckmann Ja, sehe ich absolut genauso. Das für einen Forschungs-UC zu nutzen ist eh schon grenzwertig :)
Simone Heckmann (Sep 06 2018 at 12:44):
Und nur weil mal "Inkontinenz" in den Grouper ging... ;-)
Simone Heckmann (Sep 06 2018 at 12:45):
Das könnte zu epidemiologisch stark verfälschten Ergebnissen führen...
Birger (Sep 06 2018 at 12:46):
Hauptsache die Diagramme sind schick
Simone Heckmann (Sep 06 2018 at 12:46):
Inkontinenz haben und Inkontinenz abrechnen sind zwei völlig verschiedene Dinge :D
Stefan Lang (Sep 06 2018 at 12:47):
Deswegen nochmal die Frage: was hat §21 hier überhaupt zu suchen, wenn es explizit um die zu §21 erfassten Daten geht?
Birger (Sep 06 2018 at 12:47):
OK, ich nehme erstmal ganz viele neue Infos mit. So richtig weiß ich jetzt noch nicht, wie wir damit umgehen, aber das Problem ist mir jetzt immerhin etwas klarer :D
Patrick Werner (Sep 06 2018 at 12:47):
Hmmm, ich stelle nochmal die Frage: soll der §21 nicht als Anhalts/Startpunkt dienen um erwünschte Datenpunkte in einer Fallakte zu definieren.
Stefan Lang (Sep 06 2018 at 12:48):
Patrick, genau dahin zielte meine Frage
Birger (Sep 06 2018 at 12:50):
Wie gesagt, das sind 2 Aspekte: 1) Demonstratorstudie mit CSV Import 2) Kerndatensatz, wo die "Quelldaten" des P21 abgebildet sind
Birger (Sep 06 2018 at 12:52):
Für 2) ist der Umfang unklar, aber Diagnosen, Prozeduren etc. müssen ja sowieso abgebildet werden. Da geht es dann vielleicht um "edge" cases. Wir hatten z.B. für unsere openEHR Akte erstmal nicht vor, dass wir dort Fälle abbilden, aber durch die Vorgaben machen wir das jetzt wohl doch
Birger (Sep 06 2018 at 12:52):
Das muss man dann wohl in der AG Interop aushandeln
Patrick Werner (Sep 06 2018 at 12:52):
:thumbs_up:
Birger (Sep 06 2018 at 12:54):
Die Frage ist dann halt nur, wo FHIR ne Rolle spielt und ob man dann die "Quelldaten" einfach auf Ressourcen abbildet oder ob man da ne Repräsentation des kompletten P21 benötigt.
Birger (Sep 06 2018 at 12:55):
:scream:
Birger (Sep 06 2018 at 12:57):
Danke erstmal für eure Hilfe, ich glaube das wird noch insgesamt sehr interessant :)
Patrick Werner (Sep 06 2018 at 12:58):
Ich habe es wie gesagt immer so verstanden, dass dies nur ein Startpunkt sein soll - bzw. diese Daten liegen bereits elektronisch vor.
Birger (Sep 06 2018 at 13:05):
Ja schon, aber gewisse Schwierigkeiten macht auch bereits das hier :) Ich war gerade mal neugierig, sehe ich das eigentlich richtig, dass Du an der HS Heilbronn bist?
Patrick Werner (Sep 06 2018 at 13:10):
Ja, auch. Ich arbeite mit Hauke zusammen
Birger (Sep 06 2018 at 13:13):
Ah, dann bist Du sein FHIR-Experte für die Definition des Federation-Layers :) Dann habe ich Dich jetzt zumindest mal virtuelle kennengelernt. Irgendwann ist das Projekt so groß, dass man nicht mehr alle kennt haha :grin:
Evelyn Dröge (Sep 07 2018 at 11:07):
neeee. Schön, Encounter, Patient, Condition, Procedure ....
Falls das hilft: wir nutezn die von Patrick Werner oben vorgeschlagenen Ressourcen bei stationären Aufenthalten plus Claim und Organization. Ein Encounter umfasst den ganzen stationären Aufenthalt. In der Beschreibung von Encounter steht ja: "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. " Und wie Stefan schon gesagt hat kann man notfalls auch Sub-Encounter anlegen.
Christof Gessner (Sep 07 2018 at 19:41):
Ich verfolge die Diskussion mit interesse. Habe den Eindruck, das es hier um sehr zementierte Medienbrüche zwischen Nutzung der Med. Dok. zur Abrechnung (P21, DRGs) und “für die Medizin” geht. Wenn die Aktivisten es hier schaffen, eine begriffsklärung und einen Lösungsansatz zu erzeugen, bin ich sehr froh. Wünsche viel Erfolg dabei!
Birger (Oct 18 2018 at 09:06):
Danke! Es ist gut, dass das Problem hier genauso verstanden und gesehen wird (unabhängig von dem Ergebnis, zu dem wir hoffentlich kommen).
Last updated: Apr 12 2022 at 19:14 UTC
