Stream: german/mi-initiative
Topic: encounter Feld verboten
Alexander Zautke (Oct 28 2020 at 09:59):
@Noemi Deppenwiese Folgendes Ticket müsste im Modul Diagnose noch aufgelöst werden: https://simplifier.net/medizininformatikinitiative-moduldiagnosen/~issues/831
Könntest du erläutern zu welchem Zweck Diagnose.encounter bei euch im bbmri.de IG verwendet wird?
Das Problem, dass das Kümmererteam hier vermeiden wollte ist, dass man Diagnose.encounter leichtfertig verwendet. Nicht das ich sage, dass ihr es macht! Die Diagnose sollte für sich alleine stehend sein und der Encounter sollte entsprechender darauf referenzieren. Die Befürchtung ist, dass Condition.encounter verwendet wird für mehr als den Kontakt in dem die Diagnose festgestellt wird. Dies kann immer nur ein "Versorgungsstellen-Kontakt" sein, um im MII Modell zu bleiben. In den meisten Fällen sollte jedoch der Einrichtungskontakt auf die entsprechend relevanten Diagnosen verweisen (Sorry, Encounter.diagnose mit 1..1 war keine schlaue Idee...).
Alexander Zautke (Oct 28 2020 at 10:01):
Ich würde vorschlagen, Diagnose.encounter wieder zu erlauben. Jedoch fällt mir wenig ein als eine fette Warnung im IG, dass man bitte genau hinschauen soll, welchen Encounter man dort referenziert.
Alexander Zautke (Oct 28 2020 at 10:01):
PING @Andrea Essenwanger
Sven Helfer (Oct 28 2020 at 10:23):
Ich beantworte das mal aus meiner Sicht in MIRACUM: Wichtig wäre v.A. die Verknüpfung zwischen Fall und Diagnose. Der Argumentation, dass man die Diagnosen auch an den "richtigen" Fall hängt, kann ich folgen. Für MIRACUM war es die schnellste Lösung, aufgrund der 1..1-Begrenzung den Encounter in der Diagnose zu erlauben, weil die Quellsysteme die Diagnosen meist so liefern (zugegebenermaßen nicht immer am "richtigen" Fall).
Sven Helfer (Oct 28 2020 at 10:25):
In den Quellsystemen wird eben die Diagnose nicht mit einer gewissen Gültigkeit an die Person gehängt (wie es klinisch durchaus sinnvoll ist) sondern aus Abrechnungsgründen (und nahezu nur deswegen) an den Fall. Das ist einfach ein Problem der Sekundärdatennutzung. Die Information "Von wann bis wann war der Patient an XY erkrankt." wird in absehbarer m.E. Zeit nicht so einfach verfügbar sein...
Alexander Zautke (Oct 28 2020 at 10:28):
Wenn der Encounter (ungeachtet der Ebene) 1..* Diagnosen erlauben würde, würde sich dann das Problem aus deiner Sicht erledigen?
Sven Helfer (Oct 28 2020 at 10:29):
Aus der Hüfte geschossen: Ja. Aber die Details der Modellierung kann @Noemi Deppenwiese immer besser abschätzen ;)
Alexander Zautke (Oct 28 2020 at 10:29):
Somit könnte ich immer alle Aufnahme Diagnosen und alle weiteren entstehenden Diagnosen an den Fall hängen (am Besten an den Einrichtungskontakt, falls man die Info hat)
Noemi Deppenwiese (Oct 28 2020 at 10:52):
Diagnose.encounter zu erlauben und eine Warnung dazuzuschreiben (meinetwegen auch ein warning-Constraint, ob man dieses feld WIRKLICH benutzen will) wäre meine favorisierte Lösung. Ich habe halt allgemein Bauchschmerzen, bei einem so nicht-speziellen Profil (es geht ja um alle Diagnosen im Klinikum, nicht nur z.B. um Diagnosen aufgrund von Genanalysen) ein Feld komplett zu verbieten. Wenn man dann noch einen internationalen IG implementieren will, der dieses Feld benutzt, dann hat man ein Problem.
Ich kann mir auch gerade im Onko-Kontext vorstellen, dass es schon interessant ist zu wissen, in welchem Fall as in Einrichtungskontakt eine Diagnose gestellt wurde, ohne sich hilfsweise auf das Datum verlassen zu müssen. @Jori Kern
Marvin Kampf (Oct 28 2020 at 11:00):
Ich möchte zum einen unterstützen, dass Diagnose.encounter mit 1..1 wieder erlaubt wird. Speziell im Fall MIRACUM/Erlangen liegen die Diagnosen mit Referenz auf ihren Fall vor. Mit Fall meine ich in diesem Fall, was hier (so glaube ich) als Versorgungsfall betitelt wird (also jene Entität, die eine offizielle Fallnummer hat).
Allerdings fällt mir kein Fall ein, für den auch Encounter.diagnosis auf z.B. 1..* gesetzt werden müsste. Kann mich da jemand aufklären? Es wäre jedenfalls (in meinem speziellen Fall) zusätzlicher (evtl. unnötiger?) Implementierungsaufwand.
Alexander Zautke (Oct 28 2020 at 11:51):
Marvin Kampf said:
Ich möchte zum einen unterstützen, dass Diagnose.encounter mit 1..1 wieder erlaubt wird. Speziell im Fall MIRACUM/Erlangen liegen die Diagnosen mit Referenz auf ihren Fall vor. Mit Fall meine ich in diesem Fall, was hier (so glaube ich) als Versorgungsfall betitelt wird (also jene Entität, die eine offizielle Fallnummer hat).
Allerdings fällt mir kein Fall ein, für den auch Encounter.diagnosis auf z.B. 1..* gesetzt werden müsste. Kann mich da jemand aufklären? Es wäre jedenfalls (in meinem speziellen Fall) zusätzlicher (evtl. unnötiger?) Implementierungsaufwand.
Vielen Dank für dieses Beispiel, ich gehe mal davon aus dass mit dem ersten Teil gemeint ist, dass die Diagnose und Fall Information in diesem Zusammenhang in HL7 v2 so vorliegt. In FHIR sollte die Information jedoch genau andersherum gespeichert werden (Encounter.diagnosis -> Condition). Der Kontakt der die Fallnummer ist immer eine Versorgungsfall (nach der Ballotierung nun in Einrichtungskontakt umbenannt). Diese sollte nicht in Condition referenziert werden, die Referenz sollte falls überhaupt notwendig auf einen Abteilungsfall (neu: Versorgungsstellenkontakt) zeigen.
Alexander Zautke (Oct 28 2020 at 11:53):
Der Use Case für 1..* in Encounter.diagnosis ist dass ich alle Haupt- und Nebendiagnosen abbilden kann
Alexander Zautke (Oct 28 2020 at 11:54):
Und in beiden Fällen komme ich immer über ein Reverse Chaining auf dem FHIR Server an die Diagnose wieder dran.
Alexander Zautke (Oct 28 2020 at 11:56):
In der Implementierung müsste somit zunächst der Einrichtungskontakt angelegt werden (Encounter.period.start und Fall Nr. kann angeben werden). Anschließend würde ich die Condition angelegen und dann den Encounter updaten mit einer Referenz auf die neu erstelle Diagnose.
Andrea Essenwanger (Oct 28 2020 at 12:31):
Wichtig ist vor allem auch, dass eine Diagnose nicht selber von sich aus sagen kann was sie ist im Rahmen eines Falls. Ob diese eine Haupt- oder Nebendiagnose ist z.B. würde man NUR über Encounter.diagnosis sagen können. Die Condition.encounter Referenz würde hierbei nur ausdrücken, dass die Diagnose in dem Fall festgestellt wurde.
Last updated: Apr 12 2022 at 19:14 UTC
