FHIR Chat · Bewegungsdaten · german (d-a-ch)

Stream: german (d-a-ch)

Topic: Bewegungsdaten


view this post on Zulip 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)?

view this post on Zulip Patrick Werner (Jul 18 2019 at 14:09):

Hi Laurence, bislang gibt es keine DE-basisprofile für Encounter und Location.

view this post on Zulip Patrick Werner (Jul 18 2019 at 14:11):

Ich vermute @Stoyan Halkaliev hat hier Erfahrung da ihre Pflegesoftware bestimmt Encounter und Betten erfasst.

view this post on Zulip 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

view this post on Zulip 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...

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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