You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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, derEvent 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 derEvent 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?
The text was updated successfully, but these errors were encountered: