Organisation
connect2x
Fehlerkategorie
Alles auswählen
Dokument
gemF_TI-M_Strukturierte_Daten_V1.0.0_CC
Kapitel
2.2
AFO
No response
Link
https://gemspec.gematik.de/prereleases/Draft_gemF_TI-M_Strukturierte_Daten/gemF_TI-M_Strukturierte_Daten_V1.0.0_CC/#2.2
Zeilennr.
No response
Änderungsvorschlag
Meiner Meinung nach fehlt eine fachliche Betrachtung. Fragen, die auch mit Blick auf den technischen Lösungsvorschlag aufkommen:
- Was genau sind Anwendungsfälle für einen "Kompatibilitätsabfrage"? Welches Problem soll gelöst werden?
- Was soll der Nutzer mit dieser Info anfangen? Die Nachricht statt mit TI-M per Telefon oder Fax übertragen? Oder anders gefragt: Warum wird das technische Problem der Interoperabilität auf den Nutzer geschoben?
- Was passiert, wenn der Sender offline geht, bevor er eine Antwort erhalten hat? Die Nachricht wird nie abgeschickt und der Sender bekommt das ggf. gar nicht mit.
- Was passiert, wenn der Empfänger offline geht. Der Sender kann nicht mehr "mal eben schnell" eine Nachricht schicken. Er muss im blödesten Fall mehrere Minuten warten, bis der Client eine Rückmeldung erhält, nur um dann festzustellen, dass der Empfänger gerade nicht online ist.
- Wie sollen die Nutzer damit umgehen, dass unterschiedliche Platformen des selben Herstellers unterschiedliche events unterstützen kann. Was, wenn mehrere Geräte antworten, gewinnt dann immer das Gerät, das zuerst geantwortet hat?
Insgesamt glaube ich, dass solch eine Funktion dafür sorgen wird, dass die Interoperabilität zwischen den TI-M Clients extrem leiden wird. Es wird darauf hinauslaufen, dass jeder Hersteller seine eigenen Events definiert und eine Kommunikation mit anderen Clients verweigert. Für letzteres gibt ihm nun die gematik sogar einen offiziellen Mechanismus an die Hand. Das halte ich für einen Fehler und es wird zu Frust bei den Endnuztern führen.
Stattdessen sollte die gematik TI-M Clients verpflichten, dass Events auch immer einen Fallback anbieten. Konkret habe ich hier MSC1767 im Hinterkopf. Die gematik könnte beispielsweise eine Text oder Datei-Repräsentation eines Events als Fallback verpflichtend machen. Möglicherweise sogar PDF. Dadurch wäre Interoperabilität weiterhin gegeben, aber ein TI-M Client ohne Unterstützung eines bestimmgen events kann dem Nutzer immer eine Fallbackrepräsentation anbieten. Für den seltenen Fall, dass es keine Fallbackrepräsentation gibt, kann das Fallback auch einfach ein Text sein: "Ihr Client scheint diesen Nachrichtentyp nicht zu unterstützen, bitte wenden Sie sich an den Absender". Aber dann würde ich aber auch gerne wissen, welche Fälle die gematik dort im Hinterkopf hat. Selbst bspw. komplexere Anwendungsfälle wie interaktive Fragebögen könnten einen PDF-Fallback haben oder einen konversationsgetriebenen Fallback oder aber eine Website, die verlinkt wird.
Zusätzlich könnte jedes device die voll unterstützten Event-Typen in den account data hinterlegen, sodass ein Gerät ohne Unterstützung den Nutzer an ein Gerät mit Unterstützung verweisen kann.
Organisation
connect2x
Fehlerkategorie
Alles auswählen
Dokument
gemF_TI-M_Strukturierte_Daten_V1.0.0_CC
Kapitel
2.2
AFO
No response
Link
https://gemspec.gematik.de/prereleases/Draft_gemF_TI-M_Strukturierte_Daten/gemF_TI-M_Strukturierte_Daten_V1.0.0_CC/#2.2
Zeilennr.
No response
Änderungsvorschlag
Meiner Meinung nach fehlt eine fachliche Betrachtung. Fragen, die auch mit Blick auf den technischen Lösungsvorschlag aufkommen:
Insgesamt glaube ich, dass solch eine Funktion dafür sorgen wird, dass die Interoperabilität zwischen den TI-M Clients extrem leiden wird. Es wird darauf hinauslaufen, dass jeder Hersteller seine eigenen Events definiert und eine Kommunikation mit anderen Clients verweigert. Für letzteres gibt ihm nun die gematik sogar einen offiziellen Mechanismus an die Hand. Das halte ich für einen Fehler und es wird zu Frust bei den Endnuztern führen.
Stattdessen sollte die gematik TI-M Clients verpflichten, dass Events auch immer einen Fallback anbieten. Konkret habe ich hier MSC1767 im Hinterkopf. Die gematik könnte beispielsweise eine Text oder Datei-Repräsentation eines Events als Fallback verpflichtend machen. Möglicherweise sogar PDF. Dadurch wäre Interoperabilität weiterhin gegeben, aber ein TI-M Client ohne Unterstützung eines bestimmgen events kann dem Nutzer immer eine Fallbackrepräsentation anbieten. Für den seltenen Fall, dass es keine Fallbackrepräsentation gibt, kann das Fallback auch einfach ein Text sein: "Ihr Client scheint diesen Nachrichtentyp nicht zu unterstützen, bitte wenden Sie sich an den Absender". Aber dann würde ich aber auch gerne wissen, welche Fälle die gematik dort im Hinterkopf hat. Selbst bspw. komplexere Anwendungsfälle wie interaktive Fragebögen könnten einen PDF-Fallback haben oder einen konversationsgetriebenen Fallback oder aber eine Website, die verlinkt wird.
Zusätzlich könnte jedes device die voll unterstützten Event-Typen in den account data hinterlegen, sodass ein Gerät ohne Unterstützung den Nutzer an ein Gerät mit Unterstützung verweisen kann.