Skip to content

Commit 404fb23

Browse files
JohennesJohennes
committed
GSC317: Kompatibler Austausch strukturierter Daten
1 parent bd7fb61 commit 404fb23

File tree

1 file changed

+224
-0
lines changed

1 file changed

+224
-0
lines changed

‎proposals/317-strukturierte-daten.md

Lines changed: 224 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,224 @@
1+
# GSC317: Kompatibler Austausch strukturierter Daten
2+
3+
Matrix unterstützt neben den eingebauten Events auch den Austausch proprietärer Events. Einzige
4+
Bedingung ist, dass neue Event-Typen gemäß [Spezifikation] mit einem Vendor-Präfix beginnen müssen
5+
um Kollisionen untereinandeer und mit den standardisierten `m.*` Events zu vermeiden. TI-M
6+
Hersteller können daher schon heute eigene Event-Typen für den Austausch strukturierter Daten
7+
verwenden und damit spezialisierte Anwendungsfälle bedienen. Ebenso ist es möglich strukturierte
8+
Daten als Datei über den eingebauten `m.file` Message-Type mit entsprechendem MIME-Type zu
9+
versenden.
10+
11+
Hierbei ergeben sich allerdings folgende Probleme:
12+
13+
1. Kompatibilität – Während Clients desselben Herstellers in der Regel dieselben proprietären
14+
Inhalte unterstützen sollten, kann das für Clients verschiedener Hersteller nicht angenommen
15+
werden. Zusätzlich beinhaltet Matrix aktuell keine Mechanismen, mit denen sich feststellen ließe
16+
welche Event-Typen Clients unterstützen oder ob ein gesendetes Event vom Empfänger verstanden
17+
wurde. Im schlimmsten Fall wird ein unbekanntes Event beim Empfänger überhaupt nicht angezeigt
18+
oder verarbeitet, ohne dass der Absender Kenntnis davon erlangt. Das kann besonders dann fatal
19+
sein, wenn automatisierte Systeme als TI-M Clients auftreten.
20+
2. Discoverability – Um zu verhindern, dass verschiedene Hersteller vergleichbare Probleme mehrfach
21+
lösen wäre es wünschenswert eine zentrale Übersicht ähnlich zu den [Dienstkennung] von KIM zu
22+
haben.
23+
24+
Dieses Proposal befasst sich mit Punkt 1 und beschreibt ein Verfahren, mit dem TI-M Clients Events
25+
mit proprietären Inhalten kompatibel austauschen können.
26+
27+
## Änderungsvorschlag
28+
29+
Zentrales Instrument dieses Proposals ist [MSC4300]. Dieses MSC definiert einen Mechanismus, mit dem
30+
Absender den Verarbeitungsstatus eines Events von Empfängern anfordern können. Damit diese Funktion
31+
sinnvoll nutzbar ist, werden alle TI-M Clients verpflichtet, solche Anfragen zu beantworten.
32+
33+
**A_1 - Antwort auf Anfragen zum Verarbeitungsstatus von Events**
34+
35+
TI-M Clients MÜSSEN Anfragen zum Verarbeitungsstatus von Events gemäß [MSC4300] beantworten. Enthält
36+
ein Event einen `de.gematik.msc4300.request.status` Content-Block, so MUSS der empfangende Client
37+
mit einem `de.gematik.msc4300.response.status` Event antworten sofern die `lifetime` der Anfrage
38+
noch nicht verstrichen ist. **\[\<=\]**
39+
40+
Absendene Clients sollten Anfragen zum Verarbeitungsstatus nicht mit jedem beliebigen Event
41+
verschicken sondern nur in Fällen, in denen die Kenntnis des Verarbeitungsstatus essentiell ist.
42+
Dies wird üblicherweise nur bei proprietären Events oder Dateien mit speziellem Inhalt der Fall
43+
sein. So wäre es z. B. unsinnig den Verarbeitungsstatus von reinen Text- oder Bild-Nachrichten zu
44+
erfragen, da alle TI-M Clients diese Nachrichten ohnehin unterstützen sollten.
45+
46+
Im Falle, dass ein empfangender Client ein ihm unbekanntes proprietäres Event antrifft, ist es
47+
essenziell, dass der Nutzer die Möglichkeit hat den Inhalt bei Bedarf manuell weiterzuverarbeiten.
48+
Dazu ist es erforderlich, dass solche Events angezeigt und mit der Möglichkeit zur Einsicht der
49+
Rohdaten versehen werden.
50+
51+
**A_2 - Anzeige und Rohdaten von unbekannten proprietären Events**
52+
53+
TI-M Clients MÜSSEN ihnen unbekannte proprietäre Events (also solche, deren Typ nicht mit `m.`
54+
beginnt) darstellen und dem Nutzer die Möglichkeit bieten die Rohdaten des Events anzuzeigen.
55+
**\[\<=\]**
56+
57+
*Offene Frage: Wäre es hilfreich die generelle Unterstützung eines Event-Typs schon vor dem Versand
58+
mittels [MSC4301] anfragen zu können? Was wären konkrete Anwendungsfälle dafür?*
59+
60+
*Offene Frage: Viele Probleme des medizinischen Bereichs sind bereits mit FHIR modelliert worden. In
61+
Matrix können FHIR-Dateien schon heute über den `m.file` Message-Type mit dem MIME-Type
62+
`application/fhir+json` bzw. `application/fhir+xml` versendet werden. Wie schmerzhaft ist hierbei
63+
der Umweg über eine Datei? Wäre es hilfreich, die Daten mittels [MSC4302] inline in Events versenden
64+
zu können oder den Typ der enthaltenen Resourcen auch ohne Download erkennen zu können?*
65+
66+
### Beispiel
67+
68+
Dr. Alice und Patient Bob befinden sich in einem Matrix-Raum. Alice ist mit nur einem Client `A`
69+
verbunden wohingegen Bob auf zwei Geräten `B1` und `B2` angemeldet ist. Alice schickt Bob einen
70+
Anamnese-Fragebogen als FHIR [`Questionnaire`] in einer XML-Datei. Da Alice sicher gehen möchte,
71+
dass Bob den Fragebogen auf seinem Client ausfüllen kann, fragt sie zusammen mit dem Event auch
72+
dessen Verarbeitungsstatus an.
73+
74+
``` json5
75+
{
76+
"event_id": "$1",
77+
"type": "m.room.message",
78+
"sender": "@dr.alice:alice.com",
79+
"content": {
80+
// Fragebogen
81+
"msgtype": "m.file",
82+
"body": "Bitten füllen sie diesen Fragebogen aus, danke.",
83+
"filename": "questionnaire.xml",
84+
"info": {
85+
"mimetype": "application/fhir+xml",
86+
...
87+
},
88+
// Anfrage des Verarbeitungsstatus
89+
"de.gematik.msc4300.request.status": {
90+
"from_device": "A",
91+
"lifetime": 600_000, // 10min
92+
}
93+
...
94+
},
95+
...
96+
}
97+
```
98+
99+
Bobs Client `B1` ist eine ältere Version und unterstützt das Ausfüllen von FHIR [`Questionnaire`]s
100+
nicht. Er unterstützt aber den allgemeinen Download von Dateien. Da dies bei FHIR-XML-Dokumenten
101+
eine u. U. starke Einschränkung für den Nutzer bedeuten kann, antwortet er mit einer Warnung:
102+
103+
``` json5
104+
{
105+
"type": "de.gematik.msc4300.response.status",
106+
"sender": "@bob:bob.com",
107+
"content": {
108+
"m.response.status": {
109+
"from_device": "B1",
110+
"status": "success",
111+
"messages": [{
112+
"type": "warning",
113+
"m.text": [{ "body": "Unbekannte FHIR-Datei wird nur zum Download angeboten" }]
114+
}]
115+
},
116+
"m.relates_to": {
117+
"event_id": "$1",
118+
"rel_type": "m.reference",
119+
},
120+
}
121+
}
122+
```
123+
124+
Bobs Client `B2` ist eine neuere Version und unterstützt das Ausfüllen von FHIR [`Questionnaire`]s
125+
nativ. Er antwortet daher mit einer Erfolgsmeldung ohne Warnung.
126+
127+
``` json5
128+
{
129+
"type": "de.gematik.msc4300.response.status",
130+
"sender": "@bob:bob.com",
131+
"content": {
132+
"m.response.status": {
133+
"from_device": "B2",
134+
"status": "success",
135+
},
136+
"m.relates_to": {
137+
"event_id": "$1",
138+
"rel_type": "m.reference",
139+
},
140+
}
141+
}
142+
```
143+
144+
Alices Client kann nun erkennen, dass beide von Bobs Geräten den Fragebogen empfangen haben und ein
145+
Gerät in der Lage ist ihn auszufüllen. Sie kann daher sicher sein, dass Bob den Fragebogen
146+
bearbeiten kann.
147+
148+
Bob füllt den Fragebogen auf seinem Gerät `B2` aus und sendet eine [`QuestionnaireResponse`] als
149+
FHIR-Datei zurück. Um sicherzugehen, dass Alice, seine Antwort erhält und versteht, fragt er nun
150+
seinerseits den Verarbeitungsstatus des Events an.
151+
152+
``` json5
153+
{
154+
"event_id": "$2",
155+
"type": "m.room.message",
156+
"sender": "@bob:bob.com",
157+
"content": {
158+
// Ausgefüllter Fragebogen
159+
"msgtype": "m.file",
160+
"filename": "questionnaire_response.xml",
161+
"info": {
162+
"mimetype": "application/fhir+xml",
163+
...
164+
},
165+
// Anfrage des Verarbeitungsstatus
166+
"de.gematik.msc4300.request.status": {
167+
"from_device": "B2",
168+
"lifetime": 600_000, // 10min
169+
}
170+
...
171+
},
172+
...
173+
}
174+
```
175+
176+
Alice Client empfängt den ausgefüllten Fragebogen, validiert den Inhalt und bietet ihn Alice zur
177+
Weiterverarbeitung an bevor eine Erfolgsmeldung zurück gesendet wird.
178+
179+
``` json5
180+
{
181+
"type": "de.gematik.msc4300.response.status",
182+
"sender": "@dr.alice:alice.com",
183+
"content": {
184+
"m.response.status": {
185+
"from_device": "A",
186+
"status": "success",
187+
},
188+
"m.relates_to": {
189+
"event_id": "$2",
190+
"rel_type": "m.reference",
191+
},
192+
}
193+
}
194+
```
195+
196+
Bob kann nun sicher sein, dass sein ausgefüllter Fragebogen empfangen und verstanden wurde.
197+
198+
## Sicherheit und Datenschutz
199+
200+
Die verpflichtende Antwort auf Abfragen zum Verarbeitungsstatus gibt den Online-Status des
201+
Empfängers gegenüber dem Absender preis. Zur Mitigierung dieses Problems können Clients ihre Antwort
202+
im Rahmen der `lifetime` von Anfragen verzögern.
203+
204+
In Räumen mit mehreren Teilnehmern wird der Online-Status nicht nur dem Absender sondern allen
205+
Raumteilnehmern offengelegt. Dieses Problem erscheint vernachlässigbar, da der Regelfall in TI-M die
206+
direkte Kommunikation sein wird. Zudem ließe sich der Verarbeitungsstatus wie in [MSC4300]
207+
angedeutet in Zukunft auch per To-Device-Message kommunizieren.
208+
209+
## Kompatibilität & Migration
210+
211+
Clients, die dieses Proposal nicht implementieren werden Anfragen und Antworten zum
212+
Verarbeitungsstatus ignorieren.
213+
214+
## Alternativen
215+
216+
Keine.
217+
218+
[Spezifikation]: https://spec.matrix.org/v1.14/appendices/#common-namespaced-identifier-grammar
219+
[Dienstkennung]: https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le
220+
[MSC4300]: https://github.com/matrix-org/matrix-spec-proposals/pull/4300
221+
[MSC4301]: https://github.com/matrix-org/matrix-spec-proposals/pull/4301
222+
[MSC4302]: https://github.com/matrix-org/matrix-spec-proposals/pull/4302
223+
[`Questionnaire`]: https://build.fhir.org/questionnaire-definitions.html
224+
[`QuestionnaireResponse`]: https://build.fhir.org/questionnaireresponse.html

0 commit comments

Comments
 (0)