Stream: german (d-a-ch)
Topic: Bewegungsdaten
Laurence Strasser (Jul 18 2019 at 13:18):
Hallo liebe Community, ich hätte eine Frage bezüglich der Encounter/Location Ressource in Verbindung mit Bewegungsdaten - gibt es hier für Deutschland bereits vorhandene Arbeit, beziehungsweise eine gute Art Bett, Raum und Station in einem Encounter zu speichern/referenzieren (Außer diese über jeweils eigene Profile und "part-of" zu Verknüpfen)?
Patrick Werner (Jul 18 2019 at 14:09):
Hi Laurence, bislang gibt es keine DE-basisprofile für Encounter und Location.
Patrick Werner (Jul 18 2019 at 14:11):
Ich vermute @Stoyan Halkaliev hat hier Erfahrung da ihre Pflegesoftware bestimmt Encounter und Betten erfasst.
Patrick Werner (Jul 18 2019 at 14:14):
Ich würde Encounter auf Station und Bed verweisen lassen. Zusätzlich mittels part of Bed -> Station
Simone Heckmann (Jul 26 2019 at 05:48):
Part-Of hat sich als nicht praktikabel erwiesen, da die Zuordnung oft nicht eindeutig ist (fachabteilungsübergreifende Nutzung). Daher ist in R4 bei Location der physicalType ergänzt worden, so dass man Bett, Raum und Zimmer jetzt direkt am Encounter festmachen und differenzieren kann.
Ich vermute, dass in vielen Fällen die Anlage von Location-Ressourcen als Overkill angesehen wird, da man außer der Bezeichnung ohnehin keine weiteren Informationen hat oder erfassen will.
In diesen Fällen könnte man überlegen, anstelle von Referenzen einfach logische Identifier zu verwenden,
siehe: http://hl7.org/implement/standards/fhir/references.html#logical
Konkretes Beispiel für Encounter in Bett 221B, Zimmer 221, Station Patho:
<location> <location> <identifier> <system value="http://mein-krankenhaus.de/NamingSystem/bettplaetze"/> <value value="221B"/> </identifier> </location> <status value="active"/> <physicalType> <system value="http://terminology.hl7.org/CodeSystem/location-physical-type"/> <code value="bd"/> </physicalType> </location> <location> <location> <identifier> <system value="http://mein-krankenhaus.de/NamingSystem/raeume"/> <value value="221"/> </identifier> </location> <status value="active"/> <physicalType> <system value="http://terminology.hl7.org/CodeSystem/location-physical-type"/> <code value="ro"/> </physicalType> </location> <location> <location> <identifier> <system value="http://mein-krankenhaus.de/NamingSystem/stationen"/> <value value="Patho"/> </identifier> </location> <status value="active"/> <physicalType> <system value="http://terminology.hl7.org/CodeSystem/location-physical-type"/> <code value="wa"/> </physicalType> </location>
Ich hätte dazu gerne Feedback/Erfahrungen aus der Community. Wenn das so passt, könnten wir das in die Basisprofile übernehmen, aber dazu warte ich erst mal Meinungen ab...
Stoyan Halkaliev (Aug 28 2019 at 09:29):
Oh je, da war ich lange nicht im Chat. Sorry, @Patrick Werner , dass ich dein Mention übersehen habe. Hi @Laurence Strasser , wir haben eine ziemlich ausführliche Implementierung der Struktur eines Krankenhauses, inkl.. Stationen, Zimmer, Betten, Fachabteilungen, usw. Mit entsprechenden Verlinkungen zu den Encountern. Ich habe da keine besondere Probleme gesehen es so zu implementieren wie im FHIR vorgegeben. Dabei haben wir auch eine schöne Visualisierung und können auch die Bettensperren verwalten. Ich kann zusätzliche Infos hier posten. Oder am besten direkt besprechen, wenn Ihr in Berlin nächste Woche seit.
Stoyan Halkaliev (Aug 28 2019 at 09:53):
Hi @Simone Heckmann, Ehrlich gesagt bin kein großer Fan von logical References. Ich habe sie immer als Hack empfunden, wenn man keine Zeit und Lust hat ordentliche Resources zu machen. Wenn überhaupt, dann contaned Resources ( http://hl7.org/implement/standards/fhir/references.html#contained ), direkt im Encounter, da hat man wenigstens klare Strukturen. Es ist aus Entwicklersicht sehr problematisch immer daran denken zu müssen, dass eine Referenz nicht auflösen könnte.
Stoyan Halkaliev (Aug 28 2019 at 10:11):
Hi, @Laurence Strasser , hier ein Paar Beispiele, was man mit Location, Organization und Encounter machen kann: BedIT0.PNG BedIT1.PNG BedIT2.PNG BedIT3.PNG
Stoyan Halkaliev (Aug 28 2019 at 10:23):
@Simone Heckmann, Part-Of hat sich bei uns soweit als praktikabel erwiesen, dass man damit die physicalische Abhängigkeit modelieren kann. z.B. ein Zimmer ist teil einer Station, und ein Bett ist Teil eines Zimmers (wobei wir notwendigerweise auch die Fluren als Zimmern definiert haben, weil es ja auch Flurbetten gibt). PhysicalType gibt es auch in STU3, nur dass man danach nicht suchen kann :-(
Das Krankenhaus selbst haben wir als Organization modeliert, die Fachabteilungen auch, wobei diese als Part-Of eines Krankenhauses definiert haben. Die Verbindung läuft dann über den Encounter. Ein Fall gehört zu einer Fachabteilung (Encounter.serviceProvider) und Patient befindet sich physicalisch in einem bestimmten Bett/Zimmer/Station (Encounter.location). Das Encounter.location an sich ist ja ein Array mit Location-References, dass wir entweder als contained oder richtige Resources refenrezieren. Logical references betrachten wir aktuell nicht.
Wir haben sogar auch eine Sonderlocke implementiert, wir können Plan(Soll)-Betten pro Station und Fachabteilung mit einer Observation abbilden (dafür gibt es lustingerweise ein passendes Loinc-Code). So kann man definieren wie viel Betten eine Fachabteilung auf einer Station haben darf (aber nicht genau welche, weil das nicht bekannt ist). Damit kann man aber über den Encounter.serviceProvider herausfinden, ob die Fachabteilung seine Betten "verbraucht" hat.
Stoyan Halkaliev (Sep 03 2019 at 08:10):
@Simone Heckmann, Part-Of hat sich bei uns soweit als praktikabel erwiesen, dass man damit die physicalische Abhängigkeit modelieren kann. z.B. ein Zimmer ist teil einer Station, und ein Bett ist Teil eines Zimmers (wobei wir notwendigerweise auch die Fluren als Zimmern definiert haben, weil es ja auch Flurbetten gibt). PhysicalType gibt es auch in STU3, nur dass man danach nicht suchen kann :-(
Das Krankenhaus selbst haben wir als Organization modeliert, die Fachabteilungen auch, wobei diese als Part-Of eines Krankenhauses definiert haben. Die Verbindung läuft dann über den Encounter. Ein Fall gehört zu einer Fachabteilung (Encounter.serviceProvider) und Patient befindet sich physicalisch in einem bestimmten Bett/Zimmer/Station (Encounter.location). Das Encounter.location an sich ist ja ein Array mit Location-References, die wir entweder als contained oder richtige Resources refenrezieren. Logical references betrachten wir aktuell nicht.
Wir haben sogar auch eine Sonderlocke implementiert, wir können Plan(Soll)-Betten pro Station und Fachabteilung mit einer Observation abbilden (dafür gibt es lustingerweise ein passendes Loinc-Code). So kann man definieren wie viel Betten eine Fachabteilung auf einer Station haben darf (aber nicht genau welche, weil das nicht bekannt ist). Damit kann man aber über den Encounter.serviceProvider herausfinden, ob die Fachabteilung seine Betten "verbraucht" hat.
Last updated: Apr 12 2022 at 19:14 UTC