GSC317: Kompatibler Austausch strukturierter Daten

[Johennes]

Proposal

[Johennes]

@ManuelB schreibt:

@Johennes grundsätzlich eine sehr gute Idee. Ich denke aber das ein konkretes KIM Dienstkennung-Binding sinnvoll wäre.
z.B. unter Nutzung des jmap Standards: RFC 8621 - The JSON Meta Application Protocol (JMAP) for Mail https://share.google/4ChTrdx7wcD2iFiJL

Damit könnte man KIM Mails in Matrix Events versenden und ein PVS, welches bereits KIM kann, könnte mit relativ wenig Aufwand auch TIM unterstützen.

Killer Feature bei TIM ist, dass der Patient auch seine eigenen Daten bekommen kann.

[Johennes]

Sehr interessanter Gedanke. An ein Zusammenspiel von KIM und TI-M hatte ich bisher noch nicht gedacht. Eigentlich wollen wir KIM ja eher ablösen aber so eine Integration könnte den Übergang erleichtern.

Jetzt frage ich mich aber ob wir hier wirklich eine Tiefenintegration brauchen. Könnte man KIM-Nachrichten in TI-M nicht einfach als Datei verschicken? Mein KIM-fu ist schwach aber naiv stelle ich mir eine .eml Datei mit message/rfc822 MIME-Type vor. Eventuell müsste man einige Header oder andere Metadaten in den Event-Content duplizieren damit der Empfänger nicht die ganze Datei herunterladen muss um zu verstehen was drin steckt.

Was genau hattest du dir bei JMAP vorgestellt?

[ManuelB]

Kann man auch über message/rfc822 machen. Grundsätzlich bin ich leidenschaftslos über das Format, wie man es überträgt. Ich halte es nur für wichtig, dass man bereits bestehende Systeme mitdenkt z.B. laufen so gut wie alle eAUs in Deutschland über KIM (circa 500.000 am Tag) und auch alle Arztbriefe. Ein Gateway zwischen KIM und TIM wäre super cool. E-Mail an [maitrx-id]@kim-to-tim.telematik und es wird die KIM E-Mail per TI-M an die Matrix Id zugestellt. Optimalerweise gibt es das auch in die Rückrichtung.
JMap hätten den Vorteil, dass es JSON ist und somit deutlich besser in den Matrix Stack passen würde. Es gibt auch automatische Translator von Mime to JMAP (https://github.com/josephg/mime-to-jmap).

Es ist sehr unwahrscheinlich, dass so ein großes System wie KIM kurzfristig (in den nächsten 10 Jahren) abgelöst wird.

[Johennes]

Es ist sehr unwahrscheinlich, dass so ein großes System wie KIM kurzfristig (in den nächsten 10 Jahren) abgelöst wird.

Ja, richtig. Es war mehr die Hoffnung, die aus mir sprach. 😅

Ich finde die Idee einer KIM-Bridge super spannend. Das ganze ist aber etwas tangential zu diesem Proposal hier. Wir können den hier eingeführten Verarbeitungsstatus wahrscheinlich auch verwenden um KIM-Nachrichten in Matrix zu verschicken. Ich sehe momentan aber nicht so richtig wie das Design einer Bridge dieses Proposal hier beeinflussen könnte. Deshalb habe ich das Thema mal hierhin ausgelagert: #318

Ich lasse diesen Thread aber erstmal noch offen.

[NilsLieberknecht]

@Johennes wieso unsinnig? So könnte einfach abgefragt werden, ob eine Nachricht beim Empfänger eingegangen ist. Dies ist heute nicht "einfach" möglichl

[Johennes]

Guter Punkt. Ich glaube wir haben hier eventuell zwei leicht verschiedene Probleme im Sinn.

In deinem Fall geht es um Bestätigungen für den reinen Empfang von Nachrichten auf Clients. Also Nachricht angekommen und konnte entschlüsselt werden.

Was ich mit dem Verarbeitungsstatus hier im Sinn hatte geht darüber hinaus und soll beschreiben ob der Client mit den entschlüsselten Daten auch etwas anfangen konnte.

Jetzt könnte man diesen Verarbeitungsstatus natürlich prinzipiell auch für reine Empfangsbestätigungen verwenden. Im Einzelfall fände ich das ok. Für einen massenhaften Einsatz auf jedem Event ist die Statusabfrage aber eventuell zu schwergewichtig denn jede Status-Antwort ist ja ein neues Event im Raum. Dafür gäbe es alernativ die "Delivery Receipts" aus MSC4089, die auf der leichtgewichtigeren Receipt-Infrastruktur aufbauen.

[NilsLieberknecht]

Finde ich auch gut. Sollten wir nur berücksichtigen in Zukunft :)

[Johennes]

@detlefhuehnlein schreibt:

Guten Morgen @Johennes, @ManuelB, @TimoFrank, @spilikin, @NilsLieberknecht etc.

herzlichen Dank für die großartige Initiative!

Da der grundsätzliche Ansatz strukturierte Daten über Matrix-basierte Systeme auszutauschen auch in zahlreichen weiteren Anwendungsfällen jenseits der Gesundheitstelematik, wie z.B. ZaPuk, genutzt werden kann, möchte ich hier gern für eine möglichst generische, standardkonforme und langfristig international tragfähige Lösung werben.

Letztlich handelt es sich hier nach meinem Verständnis um den Austausch von Metadaten über die Fähigkeiten von Clients (vgl. RFC 7591 und matrix#4.10.4.1). Deshalb sollte man hier aus meiner Sicht in matrix#4.10.4.1 die bereits in RFC 7591 vorgesehenen Parameter software_id und software_version nachziehen und um weitere relevante Parameter ergänzen, die die technischen Fähigkeiten des Clients (z.B. type für die unterstützten Event-Types ) beschreiben. Damit alles seine "gematische Ordnung" hat, darf hier natürlich der Parameter software_type für den Produkttyp nicht fehlen. ;-)

Die Payloads der Events, von denen es langfristig viele geben kann, sollte man sauber in JSON oder JSON-LD spezifizieren und in einem geeigneten kuratierten "Katalog" (bzw. einem Directory wie z.B. VZD-FHIR) ablegen. Wir haben uns hier in TEAM-X bereits einige Gedanken gemacht, welche Events und Datenstrukturen hier möglicherweise sinnvoll sein könnten und bringen diese gern bei Bedarf in die weitere Diskussion ein. Hierbei sollte man vor Augen haben, dass es sich bei einem Teil der Events am Ende um "elektronische Attributbescheinigungen" im Sinne von Art. 3 (44) der eIDAS-Verordnung (EU) No. 910/2014 handeln könnte und es auf Europäischer Ebene einen Katalog von Attributen gemäß Art. 45e und zugehörige "Rulebooks" für die Ausstellung solcher Attributbescheinigungen geben wird. Darüber hinaus ist perspektivisch natürlich auch der EHDS zu beachten, bei dem Datensätze aller Voraussicht nach als (dcat:resources) beschrieben und katalogisiert werden.

[Johennes]

Vielen Dank für das Feedback. Ich hab den Beitrag in einen Kommentar auf der Datei kopiert weil wir so einen eigenen Thread zur Diskussion erhalten.

Letztlich handelt es sich hier nach meinem Verständnis um den Austausch von Metadaten über die Fähigkeiten von Clients [...]

Ich glaube das ist ein überlappendes Thema, trifft so aber nicht 100%ig auf dieses Proposal zu.

Scope dieses Proposals

Der Verarbeitungsstatus aus diesem Proposal soll den Erfolg / Misserfolg bei der Verarbeitung eines konkreten Matrix-Events beschreiben. Dazu gehört einerseits die Fähigkeit den Event-Typ verstehen zu können aber andererseits auch die Auswertung der konkreten Daten im Event.

Wenn man sich konzeptionell den Absender als Client und den Empfänger als Server vorstellt, ist das gesendete Matrix-Event das HTTP-Request und der Verarbeitungsstatus die HTTP-Response.

Client Capability Negotiation

Für den Austausch von Metadaten über die Fähigkeiten von Clients, haben wir aufbauened auf diesem Proposal MSC4301 veröffentlicht. Hiermit könnten Clients adhoc die Fähigkeiten anderer Clients abfragen.

Deshalb sollte man hier aus meiner Sicht in matrix#4.10.4.1 die bereits in RFC 7591 vorgesehenen Parameter software_id und software_version nachziehen und um weitere relevante Parameter ergänzen, die die technischen Fähigkeiten des Clients (z.B. type für die unterstützten Event-Types ) beschreiben.

Die Fähigkeiten in die OAuth Client Metadaten aufzunehmen ist eine interessante Idee. Dadurch wären die Informationen statisch und könnten auch abgefragt werden, ohne dass beide Clients online sind. Man müsste sich hier noch überlegen wie diese Daten zwischen Clients transportiert werden. Können Clients die Registrierungsmetadaten anderer Clients direkt und vollständig abrufen? Oder gibt es einen Endpunkt in der CS-API, mit dem der Server Teile der Metadaten bereitstellt und dabei Zugriffsrechte durchsetzt (z. B. Abfrage nur bei gemeinsamen Räumen erlaubt)?

Event-Verzeichnis

Die Payloads der Events, von denen es langfristig viele geben kann, sollte man sauber in JSON oder JSON-LD spezifizieren und in einem geeigneten kuratierten "Katalog" (bzw. einem Directory wie z.B. VZD-FHIR) ablegen. Wir haben uns hier in TEAM-X bereits einige Gedanken gemacht, welche Events und Datenstrukturen hier möglicherweise sinnvoll sein könnten und bringen diese gern bei Bedarf in die weitere Diskussion ein. Hierbei sollte man vor Augen haben, dass es sich bei einem Teil der Events am Ende um "elektronische Attributbescheinigungen" im Sinne von Art. 3 (44) der eIDAS-Verordnung (EU) No. 910/2014 handeln könnte und es auf Europäischer Ebene einen Katalog von Attributen gemäß Art. 45e und zugehörige "Rulebooks" für die Ausstellung solcher Attributbescheinigungen geben wird. Darüber hinaus ist perspektivisch natürlich auch der EHDS zu beachten, bei dem Datensätze aller Voraussicht nach als (dcat:resources) beschrieben und katalogisiert werden.

Das sind sehr interessante Punkte. Zur Struktur eines Event-Verzeichnisses haben wir uns bisher erst wenige Gedanken gemacht. Das verwandte Verzeichnis der Dienstkennungen in KIM z. B. finde ich nur bedingt hilfreich weil dort nur IDs aber keine Schemainformationen dokumentiert werden.

Naiv hatte ich mir bisher vorgestellt, dass wir die Events einfach per JSON Schema dokumentieren und in einem GitHub Repository sammeln. Führt ein Hersteller neue Typen ein und möchte anderen Herstellern ermöglichen diese zu behandeln, könnte dann einfach ein Pull Request erstellt werden. Vielleicht reicht das mit Blick auf eIDAS und EHDS aber nicht aus.