Fallbezug darstellen: Derzeit Encounter, EpisodeOfCare wäre korrekt(er)

[mlangguth]

Hallo zusammen,

eine etwas ältere aber immer noch offene (fachlich/technische) Diskussion zum Thema "Fallbezogene Kommunikation" (gemSpec_TI-Messenger-Client):

A)
Der Fallbezug soll über eine FHIR-Ressource in im Room-State Event typ "de.gematik.tim.casereference" als JSON-Daten abgelegt werden.

Die simplifier-Vorgaben der gematik-Spezifikation (https://simplifier.net/tim) sehen hierfür den Ressourcen-Typ Encounter vor.
Dieser FHIR-Ressourcen bildet genau einen Besuch / Aufenthalt eines Patienten bei einer Einrichtung ab (stationär oder ambulant).

Daher passt diese Ressource rein fachlich nicht zu einer einrichtungsübergreifenden, fallbezogenen Kommunikation. Hier muss die Beschwerde / das Problem des Patienten im Vordergrund stehen. Schließlich wird man meist dann einen fallbezogenen Raum öffnen, wenn über eine längere Zeit hinweg mehrere Einrichtungen an der Behandlung der med. Beschwerde des Patienten arbeiten. Dies beinhaltet dann natürlich auch meist mehrere Besuche / Termine / Aufenthalte in Einrichtungen. Daher passt "Encounter" fachlich nicht zum Nutzer-Bedarf.

Die aus fachliche Sicht zu bevorzugende Ressource ist daher aus meiner Sicht EpisodeOfCare.
https://hl7.org/fhir/episodeofcare.html
Wo man unter .reason den Grund der Behandlung / des Falls angeben kann und sogar die involvierten Einrichtungen / Practitioners über .careTeam fortschreiben könnte (wenn man das will).

Ich möchte daher (erneut) anregen, dass die Fall-Ressource in EpisodeOfCare geändert wird.

B)
Zusätzlich halte ich es für problematisch, dass gemäß TIM-Client-Spec nur der Event type normiert wird, der Event state_key aber "vom Sender festgelegt" werden soll, was zu beliebig vielen CaseReference-Einträgen führen kann. Dies erschwert die Client-Implementierung (ich muss mit beliebig vielen Einträgen rechnen!), die Anzeige sowie Interpretation auf User-Seite. Daher sollte für den Fallbezug nur genau eine FHIR-Ressource hinterlegt werden können, entsprechend müsste auch der Event state_key normiert werden.
:
:
Wie seht Ihr das? Habe ich etwas übersehen, was doch eher für Encouter spricht? Und für beliebig viele "Fall-Ressouren"?
Oder teilt Ihr diese Sicht eines Anpassungsbedarfs?