Broadcast Funktion via VZD

[Johennes]

Disclaimer: Diese Idee stammt nicht von mir selbst sondern kommt aus einem Ticket im Anfrage-Portal.

Es gibt einige wiederkehrende Situationen bei denen es nützlich wäre mehreren Einrichtungen oder Personen gleichzeitig die gleiche Nachricht zu senden.

Anwendungsfall 1: Terminvermittlung

Als Hausarzt möchte ich meinem Patienten schnell einen Termin beim Facharzt vermitteln können, um eine schnelle Weiterbehandlung zu gewährleisten (und die Vergütung für die Vermittlung zu erhalten).

Anwendungsfall 2: Entlassmanagement

Als Entlassmanager im Krankenhaus möchte ich die TI Infrastruktur nutzen können, um bei in Frage kommenden Nachversorgern nach Plätzen anfragen zu können, damit ich ein entsprechend hohes Sicherheitsniveau einhalte.

→ Dafür gibt es zwar entsprechende Plattformen, die sich über das KHZG etabliert haben, aber vielleicht wäre die TI der bessere Weg, die Prozesse zu organisieren.

Anwendungsfall 3: Benachrichtigung von Partnern

Als Gesundheitseinrichtung möchte ich meine Partner in bestimmten Bereichen über Änderungen, Neuerungen oder Stati informieren.

→ Hier gibt es eine Reihe unterschiedlicher Szenarien. Diese reichen von der Information in einem Schlaganfall-Netzwerk, dass eine Klinik nicht mehr aufnahmefähig ist, über die Information an Zuweiser, dass es einen neuen Ansprechpartner gibt, bis hin zu Informationen an Experten im Partner-Netzwerk, dass eine neue Leistung in einem Zentrum verfügbar ist.

Gewünschte Funktion im Verzeichnisdienst

Es sollte die Möglichkeit im Verzeichnisdienst geben, mehrere Kontakte auszuwählen, die dann gleichzeitig mit der gleichen Nachricht erreicht werden können.

[Johennes]

Mir stellen sich hier einige grundlegende Fragen:

• Dürfen bzw. müssen Empfänger des Broadcasts sich gegenseitig kennen?
• Dürfen Empfänger sich selbstständig für den Broadcast registrieren oder wird die Liste der Empfänger ausschließlich vom Absender verwaltet?
• Was ist der Vorteil wenn die Empfängerliste im VZD liegt?

Rein technisch gäbe es z. B. die Möglichkeit einen separaten Raum pro Empfänger einzurichten oder einen gemeinsamen Raum für alle Empfänger zu verwenden.

[phillshort]

Aus meiner Sicht sollten sich die einzelnen Empfänger besser nicht gegenseitig kennen.

Ich würde sagen, dass sich die Empfänger eher nicht anmelden, sondern dass der Versender diese anschreibt.

Ich würde grundsätzlich zustimmen, dass die technische Möglichkeit mehrere Räume anzulegen ggf. ein guter Workaround sein könnte, um die meisten Anwendungsfälle abzuwickeln.

[TimoFrank]

Für mich klingt das wie ein Feature im Kontext "öffentliche Räume".

Idee: Im Anwendungsfall 1 - Terminvermittlung, könnte es einen (nicht)-öffentlichen Raum (Community/Netzwerk) unter Kardiologen geben. Dort kann ein Hausarzt beitreten und seine Terminanfrage zu teilen. Fachlich nah dran an Überweisung ("Bitte um Mitbehandlung"...). Das klingt für mich zielführender als pro Terminvermittlung einen neuen Chat-Raum mit n= 20 Fachärzten zu öffnen. Zu bedenken gibt mir, dass alternativ für jede Terminvermittlung ein neuer Empfängerkreis zu eröffnen wäre.

Für den Anwendungsfall 2 - Entlassmanagement gilt aus meiner Sicht das selbe wie für Anwendungsfall 1. Hier denke ich fachlich - neben der Vermittlung eines verfügbaren Platzes fachlich ebenfalls an eine Übermittlung von Daten (Überleitungsbogen?). Fraglich ist tatsächlich, wie sich das mit Angeboten im KHZG konkurriert, die aktuell eigentlich eher in Richtung KIM als TIM denken.

Anwendungsfall 3 - Benachrichtigung klingt für mich weniger wie ein Broadcast, sondern eher wie ein "News-Kanal" eines Leistungserbringers mit einer Abonnement-Funktion.

[benkuly]

AF3 mit Gruppen-Räumen abzubilden ist aus Datenschutzsicht bedenklich, da ja jedes Mitglied eines Raumes auch andere Räume sieht.

[phillshort]

Ich sehe ein noch viel größeres Problem weniger in der Sichtbarkeit von Mitgliedern, sondern vor allem in der Sichtbarkeit von Antworten anderer Teilnehmer. Ich möchte wahrscheinlich selbst in einem Netzwerk nicht unbedingt, dass die Kollegen wissen, dass ich gerade keine neuen Patienten annehmen kann (aus welchen Gründen auch immer). Das ist sicher vor allem bei AF 2 ein Problem. Bei AF 3 könnte man ja tatsächlich eine unidirektionale Kommunikation einrichten. Aber auch hier ergeben sich vielleicht mal Rückfragen. Wäre ja praktisch, wenn man die direkt im gleichen Chat machen könnte.

[TimoFrank]

Wenn es um nachsorgende Einrichtungen bzw. das Entlassmanagement geht, denke ich bei Krankenhäusern zuerst an 1. Pflege und 2. Reha. Hier gibt es wie Du sagst ja schon etablierte Plattformen. Es wäre interessant zu erfahren wie die das Entlassmanagement heute lösen, da es hier schon eine relativ hohe Marktabdeckung gibt. Nach meiner Kenntnis werden diese ab diesem Jahr auf KIM setzen, um darüber die Dienstkennung Elektronischer Antrag Anschlussrehabilitation zu versenden. Hierbei handelt es sich natürlich "nur" um eine Übermittlung eines Antrags und nicht die Suche nach einem Platz. Vielleicht kann TI-M dennoch ergänzend helfen. Prinzipiell habe ich auch nichts gegen separate Chat-Räume - solange die Übersichtlichkeit der Chat-Räume nicht darunter leidet.

Darüber hinaus könnten Patienten natürlich noch in die eigene Häuslichkeit entlassen werden um eine ambulante Pflege oder haus-/fachärztliche Versorgung zu erhalten. Aber das klingt für mich dann wiederum eher nach AF 1 - Terminvermittlung.

[mlangguth]

Ich habe spontan die selbe Lösung vor Augen gehabt wie @TimoFrank und die gleichen Fragen wie @Johennes:
Eigentlich sollten alle beschriebenen Use Cases mit (öffentlichen) Räumen abbildbar sein:

• Ein Arzt wird nicht alle Bürger Deutschlands informieren wollen, sondern nur wahlweise alle seine Patienten (Impferinnerung) oder ausgewählte Patienten (z.B. einer bestimmten Erkrankung)
• Überweisung und Einweisung eigentlich immer im eigenen "Netzwerk", also im Verbund der Einrichtungen und Leistungserbringer, die sich kennen und organisieren wollen
• Eine Kasse (oder ein Arzt) kann Interesse an der "Verbreitung von Wissen" haben. Dafür könnten beide öffentliche Räume einrichten, die sozusagen als Newskanal fungieren können.

Alles kann ich perfekt über Räume abbilden.

Was übersehe ich, was bei dem Vorschlag anders gemeint ist?

[Johennes]

@benkuly hat in seinem Kommentar oben ein Problem von Räumen angesprochen: Als Raumteilnehmer hat man automatisch Einsicht in alle anderen Raumteilnehmer und zwar mit MXID, Displayname und Avatar. Broadcasts in geteilten Räumen wären also quasi wie ein Mailverteiler bei dem jeder Empfänger alle anderen Empfänger sehen kann.

Bei den oben gelisteten Anwendungsfällen wäre das wegen des "Netzwerk"-Charakters (d. h. die Teilnehmer kennen sich sowieso) wahrscheinlich nicht bedenklich. Bei einem Broadcast von einem Arzt an seine Patienten aber schon eher. Als Versicherter möchte ich wahrscheinlich nicht, dass andere Patienten herausfinden können, dass ich beim selben Arzt bin, dazu noch mit KVNR und vollständigem Namen.

Räume in Matrix so anzupassen, dass die Identität der Teilnehmer geheim bleibt erscheint schwierig. Am einfachsten wäre es wahrscheinlich wenn man für solche Anwendungsfälle einen Raum pro Empfänger verwendet. Der Absender bräuchte dann eventuell nur die Möglichkeit diese vielen Räume in seinem Client wieder zusammenführen zu können.

[mlangguth]

Ah, OK, danke.

OK, eine solche "individuelle Broadcast"-Funktion könnte ein PVS/TIM-Pro-Client abbilden, indem er

1. Einen Funktionsbereich anbietet, in dem "Broadcast-Kanäle" angelegt werden können, denen eine Reihe von Nutzern zugewiesen werden können (unabhängig vom VZD, denn es können ja auch Versicherte sein, die nicht im VZD sind)
2. Das System erzeugt pro "Kanal" je Empfänger einen Raum an und lädt jeweils nur diese Empfänger ein. Die Räume selbst werden dem Pro-Nutzer nicht angezeigt. Sie werden ausschließlich vom System im Hintergrund verwendet.
3. Die powerlevel der Empfänger in diesen "Kanal-Räumen" werden immer auf 0 gesetzt (damit es unidirektional bleibt)
4. Das System zeigt dem Nutzer an, welche eingeladenen Nutzer dem "Broadcast-Kanal" beigetreten sind
5. Sendet der User eine Nachricht in einem "Broadcast-Kanal", verschickt das System je Empfänger-Raum die selbe Nachricht

Dies wäre eine Funktion, die heutige TIM-Pro-Clients ohne Specänderung anbieten könnten.
Richtig?

[Johennes]

Richtig. Ich glaube das Senden und Empfangen von Broadcasts sollte generell schon mit der aktuellen Spec möglich sein – egal ob öffentlich oder privat bzw. uni- oder bidirektional.

Mir fallen aber zwei andere Dinge ein bei denen die Spec ins Spiel kommen könnte:

1. Kompatibilität für den Absender: Sollte ein Broadcast, der mit einem TI-M Pro Client erstellt wurde nahtlos mit einem anderen TI-M Pro Client verwendbar sein? Falls ja, müssten wir dazu vorgeben wie die Räume eines Broadcasts identifiziert und zusammengeführt werden (vielleicht über Tags oder vielleicht Spaces?).
2. Selbstregistrierung der Empfänger: Sollen sich Empfänger selbst für einen Broadcast anmelden können? Bei der Lösung mit einem einzelnen Raum wäre das schon über die Join Rules konfigurierbar. Bei der Variante mit N Räumen müssten wir den Mechanismus aber wahrscheinlich vorgeben.

[Johennes]

Wobei 2. vielleicht gar kein Use Case ist.