Zwei Wege, ein Ziel
Videosprechstunden basieren auf WebRTC -- einer offenen Technologie, die Echtzeitkommunikation im Browser ermöglicht. Soweit sind sich die meisten Anbieter einig. Doch wie die Video- und Audiostreams zwischen den Teilnehmern transportiert werden, unterscheidet sich grundlegend.
Es gibt im Wesentlichen zwei Architekturen: Peer-to-Peer (P2P) und Server-basiert (SFU/MCU). Beide funktionieren, beide können KBV-zertifiziert werden -- aber sie haben unterschiedliche Konsequenzen für Datenschutz, Sicherheit und Performance.
Wer als IT-Verantwortlicher oder Datenschutzbeauftragter eine Videosprechstunden-Lösung auswählt, sollte diese Unterschiede kennen.
So funktioniert Peer-to-Peer
Bei einer P2P-Verbindung kommunizieren die Endgeräte direkt miteinander. WebRTC stellt dafür eine verschlüsselte Verbindung zwischen Browser A und Browser B her -- ohne dass die Daten über einen zentralen Server fließen.
Der Ablauf vereinfacht:
- Beide Teilnehmer kontaktieren einen Signaling-Server, der den Verbindungsaufbau koordiniert (aber keine Mediendaten sieht)
- Über STUN-Server ermitteln die Geräte ihre öffentlichen IP-Adressen
- Sobald die Verbindung steht, fließen Video und Audio direkt von Gerät zu Gerät
- Der Signaling-Server wird für die laufende Kommunikation nicht mehr benötigt
Das Ergebnis: Der Anbieter der Lösung hat keinen technischen Zugriff auf die Kommunikationsinhalte. Nicht weil er verspricht, nicht hinzuschauen -- sondern weil die Daten seine Server gar nicht passieren.
So funktioniert eine SFU
Die meisten Videokonferenz-Systeme -- Zoom, Microsoft Teams, Google Meet, aber auch viele deutsche Anbieter und Jitsi-basierte Lösungen -- nutzen eine Selective Forwarding Unit (SFU).
Das Prinzip:
- Jeder Teilnehmer sendet seinen Video- und Audiostream an einen zentralen Server
- Der Server entscheidet, welche Streams in welcher Qualität an welche Teilnehmer weitergeleitet werden
- Die Teilnehmer empfangen die Streams der anderen vom Server, nicht direkt vom Gegenüber
Die SFU sieht dabei die Mediendaten -- zumindest auf Transportebene. Sie kann Streams in verschiedenen Auflösungen weiterleiten, Bandbreite optimieren und Funktionen wie serverseitige Aufzeichnung oder Transkription ermöglichen.
Und die MCU?
Eine Multipoint Control Unit (MCU) geht noch einen Schritt weiter: Sie dekodiert alle eingehenden Streams, mischt sie zu einem einzigen Stream und sendet diesen an alle Teilnehmer. Das spart Bandbreite beim Empfänger, erfordert aber erhebliche Serverleistung -- und der Server muss die Daten zwingend entschlüsseln. MCUs spielen bei modernen Videosprechstunden-Lösungen kaum noch eine Rolle, aber das Prinzip illustriert, wie tief ein Server in die Kommunikation eingreifen kann.
Die Sicherheitsfrage: Wer kann technisch mitsehen?
Hier wird es für Ärzte und IT-Verantwortliche relevant.
Bei einer SFU-Architektur laufen alle Mediendaten über den Server des Anbieters. Viele Anbieter verschlüsseln die Verbindung zwischen Client und Server (Transport-Verschlüsselung via DTLS-SRTP). Aber auf dem Server selbst liegen die Daten entweder im Klartext vor oder der Server hat die Schlüssel, um sie zu entschlüsseln.
Das bedeutet: Der Betreiber der SFU kann technisch auf die Kommunikationsinhalte zugreifen. Ob er es tut, ist eine andere Frage -- aber die Möglichkeit besteht.
Bei einer P2P-Verbindung fließen die Daten nicht über den Server des Anbieters. Der Betreiber kann nicht mitsehen -- nicht weil eine Policy es verbietet, sondern weil die Architektur es verhindert.
Was das für § 203 StGB bedeutet
Für Ärzte als Berufsgeheimnisträger ist das mehr als ein technisches Detail. § 203 StGB stellt das Offenbaren von Geheimnissen unter Strafe. Ein Dienstleister, der technisch Zugriff auf Patientenkommunikation nehmen kann, wird potenziell zum "Mitwisser".
Zwar erlaubt § 203 Abs. 3 StGB die Einbindung von Dienstleistern unter bestimmten Bedingungen -- etwa durch Verpflichtungserklärungen. Aber viele Datenschutzaufsichtsbehörden argumentieren: Wenn technischer Zugriff vermeidbar ist, sollte er vermieden werden. Eine vertragliche Zusicherung ist kein Ersatz für technischen Schutz.
Die Architektur der Videosprechstunde ist also nicht nur eine technische Entscheidung, sondern hat unmittelbare Relevanz für die Einhaltung der ärztlichen Schweigepflicht.
Technische Details zur MeetOne-Architektur
Erfahren Sie, wie MeetOne Ihre Praxis digitalisiert
Performance: Wo P2P an Grenzen stößt
P2P hat einen klaren Nachteil: Es skaliert schlecht.
Bei einem 1:1-Gespräch -- dem typischen Szenario einer Videosprechstunde -- funktioniert P2P hervorragend. Jedes Gerät sendet einen Stream und empfängt einen. Die Anforderungen an Bandbreite und Rechenleistung sind moderat.
Bei mehreren Teilnehmern wird es anspruchsvoller:
| Teilnehmer | Streams pro Gerät (P2P) | Streams pro Gerät (SFU) |
|---|---|---|
| 2 | 1 senden, 1 empfangen | 1 senden, 1 empfangen |
| 4 | 1 senden, 3 empfangen | 1 senden, 3 empfangen |
| 6 | 1 senden, 5 empfangen | 1 senden, 5 empfangen |
| 10 | 1 senden, 9 empfangen | 1 senden, 9 empfangen |
Auf den ersten Blick sieht das gleich aus. Der Unterschied: Bei P2P muss jedes Gerät eine separate verschlüsselte Verbindung zu jedem anderen Teilnehmer aufbauen und aufrechterhalten. Bei einer SFU gibt es nur eine Verbindung -- zum Server. Die SFU kann außerdem Streams in niedrigerer Qualität weiterleiten, wenn die Bandbreite knapp wird.
In der Praxis bedeutet das: P2P funktioniert zuverlässig für Gruppen bis etwa 4-6 Teilnehmer. Für größere Konferenzen -- Fortbildungen, Teambesprechungen mit vielen Beteiligten -- ist die SFU-Architektur praktikabler.
Für den typischen Anwendungsfall der Videosprechstunde (Arzt-Patient, Konsil mit 2-3 Kollegen, Angehörigengespräch) ist das selten eine Einschränkung.
NAT-Traversal und der TURN-Fallback
P2P klingt einfach: Gerät A verbindet sich direkt mit Gerät B. In der Praxis ist es komplizierter.
Die meisten Geräte sitzen hinter einem NAT-Router (Network Address Translation) oder einer Firewall, die direkte eingehende Verbindungen blockiert. WebRTC nutzt ICE (Interactive Connectivity Establishment), um trotzdem eine Verbindung herzustellen:
- STUN: Beide Seiten ermitteln ihre öffentliche IP-Adresse. In vielen Fällen reicht das für eine direkte Verbindung.
- TURN: Wenn keine direkte Verbindung möglich ist -- etwa bei symmetrischem NAT oder restriktiven Firewalls -- leitet ein TURN-Server die Daten weiter.
Die ehrliche Einschränkung: Bei einem TURN-Fallback fließen die Mediendaten über einen Server. Das klingt zunächst so, als würde es den Vorteil von P2P aufheben. Die entscheidende Frage ist aber: Kann der TURN-Server die Daten entschlüsseln?
Bei einer sorgfältig implementierten Lösung lautet die Antwort: Nein. Der TURN-Server leitet verschlüsselte Pakete weiter, ohne die Schlüssel zu kennen. Er ist ein Transportmittel, kein Teilnehmer der Kommunikation. Wer eine P2P-Lösung evaluiert, sollte genau diese Frage stellen: Was passiert beim TURN-Fallback?
Technische Fragen zur Architektur?
Wir beantworten alle Ihre Fragen
KBV-Zertifizierung: Gleicher Stempel, unterschiedlicher Schutz
Sowohl P2P- als auch SFU-basierte Lösungen können die KBV-Zertifizierung erhalten. Die Zertifizierung prüft wichtige Kriterien -- Verschlüsselung, Serverstandort, Datenschutzkonzept -- und stellt ein Mindestmaß an Sicherheit sicher.
Aber die Zertifizierung unterscheidet nicht zwischen den Architekturansätzen. Eine SFU-basierte Lösung mit Transport-Verschlüsselung kann ebenso zertifiziert werden wie eine P2P-Lösung mit echter Ende-zu-Ende-Verschlüsselung.
Für IT-Entscheider bedeutet das: Die KBV-Zertifizierung ist eine notwendige Bedingung, aber kein ausreichendes Kriterium für die Bewertung des tatsächlichen Schutzniveaus. Wer über das Minimum hinausgehen will, muss die Architektur des Anbieters verstehen.
MeetOne nutzt eine Peer-to-Peer-Architektur, bei der Video- und Audiostreams direkt zwischen den Teilnehmern fließen. Auch beim TURN-Fallback bleiben die Daten verschlüsselt -- der Server leitet lediglich verschlüsselte Pakete weiter, ohne Zugriff auf die Inhalte. Die KBV-Zertifizierung bestätigt die Einhaltung der regulatorischen Anforderungen.
P2P vs. SFU auf einen Blick
- Datenzugriff: Bei P2P hat der Anbieter keinen technischen Zugriff auf Mediendaten. Bei SFU prinzipiell schon.
- 1:1-Gespräche: P2P bietet die direkteste und sicherste Verbindung.
- Gruppenkonferenzen: SFU skaliert besser ab etwa 6 Teilnehmern. P2P reicht für typische Praxisszenarien.
- TURN-Fallback: Auch bei P2P können Daten über einen Server laufen -- entscheidend ist, ob sie dort entschlüsselbar sind.
- KBV-Zertifizierung: Beide Architekturen können zertifiziert werden. Der tatsächliche Schutz unterscheidet sich trotzdem.
Fazit
Die Architektur einer Videosprechstunde bestimmt, wer technisch Zugriff auf die Kommunikation nehmen kann. Bei Server-basierten Lösungen ist das prinzipiell der Betreiber -- bei Peer-to-Peer nicht. Für Ärzte als Berufsgeheimnisträger ist das eine relevante Unterscheidung, die über die KBV-Zertifizierung hinausgeht. P2P hat Einschränkungen bei großen Gruppen und komplexen Netzwerkumgebungen, deckt aber die typischen Szenarien einer Arztpraxis ab.
Dieser Artikel dient der allgemeinen Information über technische Architekturen und ersetzt keine individuelle rechtliche oder technische Beratung.