diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md new file mode 100644 index 00000000..f0fac170 --- /dev/null +++ b/proposals/317-strukturierte-daten.md @@ -0,0 +1,251 @@ +# GSC317: Kompatibler Austausch strukturierter Daten + +Matrix unterstützt neben den eingebauten Events auch den Austausch proprietärer Events. Solche +Event-Typen müssen gemäß [Spezifikation] mit einem rDNS-Präfix beginnen um Kollisionen untereinander +und mit den standardisierten `m.*` Events zu vermeiden. TI-M Hersteller können daher schon heute +eigene Event-Typen für den Austausch strukturierter Daten verwenden und damit spezialisierte +Anwendungsfälle bedienen. Ebenso ist es möglich strukturierte Daten als Datei über den eingebauten +`m.file` Message-Type mit entsprechendem MIME-Type zu versenden. + +Hierbei ergeben sich allerdings folgende Probleme: + +1. Kompatibilität – Während Clients desselben Herstellers in der Regel dieselben proprietären + Inhalte unterstützen sollten, kann das für Clients verschiedener Hersteller nicht angenommen + werden. Zusätzlich beinhaltet Matrix aktuell keine Mechanismen, mit denen sich feststellen ließe + welche Event-Typen Clients unterstützen oder ob ein gesendetes Event vom Empfänger verstanden + wurde. Im schlimmsten Fall wird ein unbekanntes Event beim Empfänger überhaupt nicht angezeigt + oder verarbeitet, ohne dass der Absender Kenntnis davon erlangt. Das kann besonders dann fatal + sein, wenn automatisierte Systeme als TI-M Clients auftreten. +2. Discoverability – Um zu verhindern, dass verschiedene Hersteller vergleichbare Probleme mehrfach + lösen wäre es wünschenswert eine zentrale Übersicht ähnlich zu den [Dienstkennungen] von KIM zu + haben. + +Dieses Proposal befasst sich mit Punkt 1 und beschreibt ein Verfahren, mit dem TI-M Clients Events +mit proprietären Inhalten kompatibel austauschen können. + +## Änderungsvorschlag + +Zentrales Instrument dieses Proposals ist [MSC4300]. Dieses MSC definiert einen Mechanismus, mit dem +Absender den Verarbeitungsstatus eines Events von Empfängern anfordern können. Hierzu wird auf dem +betroffenen Event ein `de.gematik.msc4300.request.status` Content-Block gesetzt, welcher die +absendende Device-ID und eine optionale Lebensdauer enthält. + +``` json5 +{ + "event_id": "$1", + "type": "", + "content": { + + // Anfrage des Verarbeitungsstatus + "de.gematik.msc4300.request.status": { + "from_device": "RJYKSTBOIE", + "lifetime": 90_000, // 90s + } + }, + ... +} +``` + +Der Content-Block zur Anfrage des Verarbeitungsstatus ist modular und kann auf beliebigen +Event-Typen verwendet werden. Eine Verpflichtung hierzu besteht für TI-M Clients jedoch nicht. Die +gematik stellt hier lediglich die nötige Infrastruktur bereit, damit diese Anfragen bei Bedarf und +in spezilisierten Anwendungsfällen verwendet werden können um Kompatibilität zu gewährleisten. + +Damit diese Funktion sinnvoll nutzbar ist, ist es allerdings erforderlich, dass *empfangene* +Anfragen beantwortet werden. Daher werden alle TI-M Clients hierzu verpflichtet. + +**A_1 - Antwort auf Anfragen zum Verarbeitungsstatus von Events** + +TI-M Clients MÜSSEN Anfragen zum Verarbeitungsstatus von Events gemäß [MSC4300] beantworten. Enthält +ein Event einen `de.gematik.msc4300.request.status` Content-Block, so MUSS der empfangende Client +mit einem `de.gematik.msc4300.response.status` Event antworten sofern die `lifetime` der Anfrage +noch nicht verstrichen ist. **\[\<=\]** + +Absendene Clients sollten Anfragen zum Verarbeitungsstatus nicht mit jedem beliebigen Event +verschicken sondern nur in Fällen, in denen die Kenntnis des Verarbeitungsstatus essenziell ist. +Dies wird üblicherweise nur bei proprietären Events oder Dateien mit speziellem Inhalt der Fall +sein. So wäre es z. B. unsinnig den Verarbeitungsstatus von reinen Text- oder Bild-Nachrichten zu +erfragen, da alle TI-M Clients diese Nachrichten ohnehin unterstützen sollten. Werden andererseits +komplexere Inhalte wie z. B. serialisierte FHIR-Resourcen versendet, kann es sinnvoll sein, den +Verarbeitungsstatus anzufragen um sicherzustellen, dass der empfangende Client die Inhalte +verstanden hat. + +Für Mitarbeiter im Gesundheitswesen kann es hilfreich sein unbekannte Events bei Bedarf manuell +weiterzuverarbeiten, z. B. indem die Inhalte in ein PVS oder anderes Drittsystem exportiert werden. +Dazu ist es erforderlich, dass solche Events angezeigt und mit der Möglichkeit zur Einsicht der +Rohdaten versehen werden. + +**A_2 - Anzeige und Rohdaten von unbekannten proprietären Events** + +TI-M Pro Clients MÜSSEN ihnen unbekannte proprietäre Events (also solche, deren Typ nicht mit `m.` +beginnt) darstellen und dem Nutzer die Möglichkeit bieten die Rohdaten des Events anzuzeigen. +**\[\<=\]** + +*Offene Frage: Wäre es hilfreich die generelle Unterstützung eines Event-Typs schon vor dem Versand +mittels [MSC4301] anfragen zu können? Was wären konkrete Anwendungsfälle dafür?* + +*Offene Frage: Viele Probleme des medizinischen Bereichs sind bereits mit FHIR modelliert worden. In +Matrix können FHIR-Dateien schon heute über den `m.file` Message-Type mit dem MIME-Type +`application/fhir+json` bzw. `application/fhir+xml` versendet werden. Wie schmerzhaft ist hierbei +der Umweg über eine Datei? Wäre es hilfreich, die Daten mittels [MSC4302] inline in Events versenden +zu können oder den Typ der enthaltenen Resourcen auch ohne Download erkennen zu können?* + +### Beispiel + +Dr. Alice und Patient Bob befinden sich in einem Matrix-Raum. Alice ist mit nur einem Client `A` +verbunden wohingegen Bob auf zwei Geräten `B1` und `B2` angemeldet ist. Alice schickt Bob einen +Anamnese-Fragebogen als FHIR [`Questionnaire`] in einer XML-Datei. Da Alice sicher gehen möchte, +dass Bob den Fragebogen auf seinem Client ausfüllen kann, fragt sie zusammen mit dem Event auch +dessen Verarbeitungsstatus an. + +``` json5 +{ + "event_id": "$1", + "type": "m.room.message", + "sender": "@dr.alice:alice.com", + "content": { + // Fragebogen + "msgtype": "m.file", + "body": "Bitten füllen sie diesen Fragebogen aus, danke.", + "filename": "questionnaire.xml", + "info": { + "mimetype": "application/fhir+xml", + ... + }, + // Anfrage des Verarbeitungsstatus + "de.gematik.msc4300.request.status": { + "from_device": "A", + "lifetime": 600_000, // 10min + } + ... + }, + ... +} +``` + +Bobs Client `B1` ist eine ältere Version und unterstützt das Ausfüllen von FHIR [`Questionnaire`]s +nicht. Er unterstützt aber den allgemeinen Download von Dateien. Da dies bei FHIR-XML-Dokumenten +eine u. U. starke Einschränkung für den Nutzer bedeuten kann, antwortet er mit einer Warnung: + +``` json5 +{ + "type": "de.gematik.msc4300.response.status", + "sender": "@bob:bob.com", + "content": { + "m.response.status": { + "from_device": "B1", + "status": "success", + "messages": [{ + "type": "warning", + "m.text": [{ "body": "Unbekannte FHIR-Datei wird nur zum Download angeboten" }] + }] + }, + "m.relates_to": { + "event_id": "$1", + "rel_type": "m.reference", + }, + } +} +``` + +Bobs Client `B2` ist eine neuere Version und unterstützt das Ausfüllen von FHIR [`Questionnaire`]s +nativ. Er antwortet daher mit einer Erfolgsmeldung ohne Warnung. + +``` json5 +{ + "type": "de.gematik.msc4300.response.status", + "sender": "@bob:bob.com", + "content": { + "m.response.status": { + "from_device": "B2", + "status": "success", + }, + "m.relates_to": { + "event_id": "$1", + "rel_type": "m.reference", + }, + } +} +``` + +Alices Client kann nun erkennen, dass beide von Bobs Geräten den Fragebogen empfangen haben und ein +Gerät in der Lage ist ihn auszufüllen. Sie kann daher sicher sein, dass Bob den Fragebogen +bearbeiten kann. + +Bob füllt den Fragebogen auf seinem Gerät `B2` aus und sendet eine [`QuestionnaireResponse`] als +FHIR-Datei zurück. Um sicherzugehen, dass Alice, seine Antwort erhält und versteht, fragt er nun +seinerseits den Verarbeitungsstatus des Events an. + +``` json5 +{ + "event_id": "$2", + "type": "m.room.message", + "sender": "@bob:bob.com", + "content": { + // Ausgefüllter Fragebogen + "msgtype": "m.file", + "filename": "questionnaire_response.xml", + "info": { + "mimetype": "application/fhir+xml", + ... + }, + // Anfrage des Verarbeitungsstatus + "de.gematik.msc4300.request.status": { + "from_device": "B2", + "lifetime": 600_000, // 10min + } + ... + }, + ... +} +``` + +Alice Client empfängt den ausgefüllten Fragebogen, validiert den Inhalt und bietet ihn Alice zur +Weiterverarbeitung an bevor eine Erfolgsmeldung zurück gesendet wird. + +``` json5 +{ + "type": "de.gematik.msc4300.response.status", + "sender": "@dr.alice:alice.com", + "content": { + "m.response.status": { + "from_device": "A", + "status": "success", + }, + "m.relates_to": { + "event_id": "$2", + "rel_type": "m.reference", + }, + } +} +``` + +Bob kann nun sicher sein, dass sein ausgefüllter Fragebogen empfangen und verstanden wurde. + +## Sicherheit und Datenschutz + +Die verpflichtende Antwort auf Abfragen zum Verarbeitungsstatus gibt den Online-Status des +Empfängers gegenüber dem Absender preis. Zur Mitigierung dieses Problems können Clients ihre Antwort +im Rahmen der `lifetime` von Anfragen verzögern. + +In Räumen mit mehreren Teilnehmern wird der Online-Status nicht nur dem Absender sondern allen +Raumteilnehmern offengelegt. Dieses Problem erscheint vernachlässigbar, da der Regelfall in TI-M die +direkte Kommunikation sein wird. Zudem ließe sich der Verarbeitungsstatus wie in [MSC4300] +angedeutet in Zukunft auch per To-Device-Message kommunizieren. + +## Kompatibilität & Migration + +Clients, die dieses Proposal nicht implementieren werden Anfragen und Antworten zum +Verarbeitungsstatus ignorieren. + +## Alternativen + +Keine. + + [Spezifikation]: https://spec.matrix.org/v1.14/appendices/#common-namespaced-identifier-grammar + [Dienstkennungen]: https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le + [MSC4300]: https://github.com/matrix-org/matrix-spec-proposals/pull/4300 + [MSC4301]: https://github.com/matrix-org/matrix-spec-proposals/pull/4301 + [MSC4302]: https://github.com/matrix-org/matrix-spec-proposals/pull/4302 + [`Questionnaire`]: https://build.fhir.org/questionnaire-definitions.html + [`QuestionnaireResponse`]: https://build.fhir.org/questionnaireresponse.html