From 404fb235a8be855f8613b9170264c7e7d9b8836a Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 23 Jun 2025 14:16:57 +0200 Subject: [PATCH 1/8] GSC317: Kompatibler Austausch strukturierter Daten --- proposals/317-strukturierte-daten.md | 224 +++++++++++++++++++++++++++ 1 file changed, 224 insertions(+) create mode 100644 proposals/317-strukturierte-daten.md diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md new file mode 100644 index 00000000..43873f8a --- /dev/null +++ b/proposals/317-strukturierte-daten.md @@ -0,0 +1,224 @@ +# GSC317: Kompatibler Austausch strukturierter Daten + +Matrix unterstützt neben den eingebauten Events auch den Austausch proprietärer Events. Einzige +Bedingung ist, dass neue Event-Typen gemäß [Spezifikation] mit einem Vendor-Präfix beginnen müssen +um Kollisionen untereinandeer 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 [Dienstkennung] 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. Damit diese Funktion +sinnvoll nutzbar ist, werden alle TI-M Clients verpflichtet, solche Anfragen zu beantworten. + +**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 essentiell 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. + +Im Falle, dass ein empfangender Client ein ihm unbekanntes proprietäres Event antrifft, ist es +essenziell, dass der Nutzer die Möglichkeit hat den Inhalt bei Bedarf manuell weiterzuverarbeiten. +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 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 + [Dienstkennung]: 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 From 8e8340f310e6b2e6bee9ceb4f82a76d80cc176d3 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 08:50:22 +0200 Subject: [PATCH 2/8] Vendor -> rDNS --- proposals/317-strukturierte-daten.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 43873f8a..3e84c00d 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -1,12 +1,11 @@ # GSC317: Kompatibler Austausch strukturierter Daten Matrix unterstützt neben den eingebauten Events auch den Austausch proprietärer Events. Einzige -Bedingung ist, dass neue Event-Typen gemäß [Spezifikation] mit einem Vendor-Präfix beginnen müssen -um Kollisionen untereinandeer 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. +Bedingung ist, dass neue Event-Typen gemäß [Spezifikation] mit einem rDNS-Präfix beginnen müssen um +Kollisionen untereinandeer 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: From 11161624fe74963103f133b113a2a42672b4ee40 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:05:24 +0200 Subject: [PATCH 3/8] Anfragen sind optional, Antworten nicht --- proposals/317-strukturierte-daten.md | 29 ++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 3e84c00d..62b0d977 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -26,8 +26,33 @@ 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. Damit diese Funktion -sinnvoll nutzbar ist, werden alle TI-M Clients verpflichtet, solche Anfragen zu beantworten. +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** From 8e1dd9f09a3fda7f93195da80fc887764f4723c1 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:15:23 +0200 Subject: [PATCH 4/8] =?UTF-8?q?Positiv-Beispiel=20f=C3=BCr=20Anfragen=20zu?= =?UTF-8?q?m=20Verarbeitungsstatus?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- proposals/317-strukturierte-daten.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 62b0d977..9d12d01b 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -62,10 +62,13 @@ mit einem `de.gematik.msc4300.response.status` Event antworten sofern die `lifet 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 essentiell ist. +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. +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. Im Falle, dass ein empfangender Client ein ihm unbekanntes proprietäres Event antrifft, ist es essenziell, dass der Nutzer die Möglichkeit hat den Inhalt bei Bedarf manuell weiterzuverarbeiten. From 9f962c646ba8092c3f41e5dfb2411aafb988c4d5 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:26:37 +0200 Subject: [PATCH 5/8] Manuelle Verarbeitung von unbekannten Events nur in TI-M Pro Clients --- proposals/317-strukturierte-daten.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 9d12d01b..d5ab1690 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -70,14 +70,14 @@ komplexere Inhalte wie z. B. serialisierte FHIR-Resourcen versendet, kann es sin Verarbeitungsstatus anzufragen um sicherzustellen, dass der empfangende Client die Inhalte verstanden hat. -Im Falle, dass ein empfangender Client ein ihm unbekanntes proprietäres Event antrifft, ist es -essenziell, dass der Nutzer die Möglichkeit hat den Inhalt bei Bedarf manuell weiterzuverarbeiten. +Für Mitarbeiter im Gesundheitswesen kann es hilfreich sein unbekannte Events bei Bedarf manuell +weiterzuverarbeiten, z. B. in dem 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 Clients MÜSSEN ihnen unbekannte proprietäre Events (also solche, deren Typ nicht mit `m.` +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. **\[\<=\]** From 7d1aeba22839f49d053331d931fd3fd3199977bd Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:29:58 +0200 Subject: [PATCH 6/8] Leicht Umformulierung, Typo --- proposals/317-strukturierte-daten.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index d5ab1690..87c74894 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -1,11 +1,11 @@ # GSC317: Kompatibler Austausch strukturierter Daten -Matrix unterstützt neben den eingebauten Events auch den Austausch proprietärer Events. Einzige -Bedingung ist, dass neue Event-Typen gemäß [Spezifikation] mit einem rDNS-Präfix beginnen müssen um -Kollisionen untereinandeer 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. +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: From 155029ca82ad6b732ecc7fcc26750064f5e90c50 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:31:28 +0200 Subject: [PATCH 7/8] Typo --- proposals/317-strukturierte-daten.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 87c74894..7eedee83 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -17,7 +17,7 @@ Hierbei ergeben sich allerdings folgende Probleme: 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 [Dienstkennung] von KIM zu + 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 @@ -243,7 +243,7 @@ Verarbeitungsstatus ignorieren. Keine. [Spezifikation]: https://spec.matrix.org/v1.14/appendices/#common-namespaced-identifier-grammar - [Dienstkennung]: https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le + [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 From 60c36e7a65c4c517e479636ec427c31376af2092 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 24 Jun 2025 09:34:14 +0200 Subject: [PATCH 8/8] Typo --- proposals/317-strukturierte-daten.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/317-strukturierte-daten.md b/proposals/317-strukturierte-daten.md index 7eedee83..f0fac170 100644 --- a/proposals/317-strukturierte-daten.md +++ b/proposals/317-strukturierte-daten.md @@ -71,7 +71,7 @@ Verarbeitungsstatus anzufragen um sicherzustellen, dass der empfangende Client d verstanden hat. Für Mitarbeiter im Gesundheitswesen kann es hilfreich sein unbekannte Events bei Bedarf manuell -weiterzuverarbeiten, z. B. in dem die Inhalte in ein PVS oder anderes Drittsystem exportiert werden. +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.