Eine TI-M-Nachricht geht ein.
Der Host zeigt das Anliegen am Arbeitsplatz der Sachbearbeitung. Die Nachricht allein startet keinen Audioanruf.
- Ein Mitarbeiter sichtet das Anliegen.
- Der Fachprozess bestimmt die nächste Handlung.
Krankenkassen & Contact Center
Krankenkassen-Contact-Center: Wenn eine Anfrage mehrere Systeme durchläuft.
Eine Versichertenanfrage kann zwischen Service-Desk, Fachanwendung und TI-M unterschiedliche Zuständigkeiten berühren. Ein zentrales Contact Center kann TI-M über ein lokal eingebundenes Headless-Modul im eigenen Backend nutzen. Sachbearbeitende arbeiten in ihrer gewohnten Oberfläche; Prozesszuordnung, technische Identität und Anbieter TI-M Pro erhalten klar benannte Aufgaben. MEMM beschreibt hier die Integrationsarchitektur und den normativen Rahmen für einen projektspezifischen Scope.
Entfernter Arbeitsplatz. Lokales Modul.
Arbeitsplatz der MitarbeitendenDesktop- oder Web-Oberfläche
Transportverschlüsselte Verbindung
Host-BackendFachprozess und Zuordnung
Lokaler API-Aufruf
MEMM HeadlessEingebundener TI-M-Client
TI-M-Kommunikation
TI-M-FachdienstAnbieter TI-M Pro
Mitarbeitende greifen auf den Host zu. Nur der Host ruft sein lokales Headless-Modul auf. Dieser Überblick zeigt die Nachrichtenintegration; Calling-Pfade werden gesondert beschrieben.
Ein Anliegen durchspielenNormatives Architekturbeispiel: gemSpec_TI-M_Pro 1.2.0, Abschnitt 3.3.4 ↗ beschreibt ausdrücklich die zentrale Contact-Center-Integration bei einem Kostenträger: Arbeitsplatz- oder Web-Clients greifen transportverschlüsselt auf den Host zu; dessen Headless-Modul wird ausschließlich lokal angesteuert.
Übungsszenario · synthetische Inhalte · keine Live-Verbindung
Ein Anliegen vom Eingang bis zum Abschluss begleiten.
Übernehmen Sie die Rolle der Sachbearbeitung: Öffnen Sie ein Anliegen, wählen Sie eine Antwort und verfolgen Sie den zentralen Audiopfad. Jede Aktion verändert nur dieses Beispiel auf der Seite.
- Anliegen
- Entscheidung
- Verbindung
- Gespräch
- Abschluss
Lesefassung: Der vollständige Ablauf und seine alternativen Ergebnisse stehen im Folgenden.
Wie möchten Sie antworten?
Bieten Sie ein Audiogespräch an oder antworten Sie schriftlich. Die Auswahl von Audio bereitet eine Einladung vor; die Gegenstelle muss noch zustimmen.
- Die Mitarbeiteridentität ist im Host zugeordnet.
- Ein Matrix-Account allein identifiziert nicht den einzelnen Mitarbeiter.
Den zentralen Audiopfad vorbereiten.
Dieser Erfolgspfad setzt bestandene Prüfungen voraus. Headless tauscht die Anrufsignalisierung aus; Audio beginnt erst nach Zustimmung der Gegenstelle und Aufbau des geschützten Medienpfads.
- Authentifizierter Operator, Mandant, Gerät und Call an eine aktive Lease gebunden.
- Beide TLS-Allocations auf derselben kontrollierten TURN-Instanz / VM bestätigt; Relay-Verkehr bleibt innerhalb der VM.
- Geprüfte Herkunft des Gegenstellengeräts bindet den Medien-Fingerprint.
Das Audiogespräch ist verbunden.
TI-M E2EE schützt Medien zwischen Gegenstelle und Headless im Server. Der vertrauenswürdige Host verarbeitet Klartext-Audio und überträgt es über den separaten WSS/TLS-Kanal an die Sachbearbeitung.
- Headless und Gegenstelle behalten die Medienschlüssel.
- Dieses zentrale Profil umfasst Audio; Aufzeichnung ist standardmäßig aus.
- Verlust der Berechtigung oder des geforderten Pfads beendet das Gespräch.
Anruf schließen und Anliegen weiterbearbeiten.
Der dargestellte Abbau stoppt Medien, gibt die Call-Lease frei und leert temporäre Medienpuffer. Danach kann die Sachbearbeitung das fachliche Ergebnis in ihrem Host-Prozess festhalten.
- Dieses Beispiel erzeugt keine Audioaufzeichnung.
- Weitere Bearbeitungsschritte gehören zum Fachprozess.
Alternative: Der erforderliche Pfad ist nicht bestätigt.
Audio startet nicht. Der Host zeigt den Grund; Headless weicht weder auf eine Direktverbindung noch auf einen externen UDP-Pfad aus.
- Kein automatischer Downgrade.
- Die Sachbearbeitung kann bewusst zur schriftlichen Antwort zurückkehren.
Alternative: Das Gespräch schriftlich fortsetzen.
Der Host zeigt eine vorbereitete Beispielantwort. Es entsteht weder eine Anrufeinladung noch eine Audiositzung.
„Wir können Ihre allgemeine Frage hier im Chat beantworten.“
- Der Mitarbeiter wählt die schriftliche Antwort.
- Die Nachrichtenverarbeitung bleibt im TI-M-Integrationsscope.
Der schriftliche Weg ist abgeschlossen.
Das Beispiel endet mit einer schriftlichen Antwort. Es wurde kein Anruf geöffnet; weder Medien-Lease noch Audioaufzeichnung sind entstanden.
- Der nächste fachliche Schritt gehört zum Host-Prozess.
Integrationsscope
Automatisierung wird erst belastbar, wenn die Kontextgrenzen benannt sind.
Für Krankenkassen und Contact Center reicht ein technischer Nachrichtenkanal allein nicht aus. Entscheidend sind Identität, zulässige Attribute, Raumkontext, Fehlersemantik und die Verantwortung zwischen Fachsystem, Automatisierung und externen Diensten.
01
Versorgungszweck
Nur berechtigte Gesundheitsorganisationen dürfen Headless integrieren und betreiben. Medizinische Daten dienen der Gesundheitsversorgung oder deren Organisation; Mehrzwecksysteme schützen sie vor fachfremdem Zugriff (A_28725, A_28733).
02
Kontaktart
Person, menschlich betreuter Funktionsaccount und automatisierter Account erhalten unterschiedliche FHIR-VZD-Kennungen. Ein Chatbot bleibt für Gesprächspartner als solcher erkennbar.
03
Profil & Berechtigung
Der Org-Admin pflegt das verpflichtende Organisationsfeld de.gematik.user.orgname und optionale Zusatzfelder. Profilangaben unterstützen die Identifikation; Berechtigungsprüfungen bleiben ein eigener Vertrag (A_30013, A_30014).
04
Anbieter & Change
Der Anbieter TI-M Pro dokumentiert System, Hersteller und Architektur, prüft sein Handbuch mindestens halbjährlich und holt die GTI-Freigabe vor Integration sowie bei wesentlichen Änderungen ein (A_28681, A_28682, A_28849, A_28850).
Zentrale Contact-Center-Integration
TLS zum Host, lokale Funktionen zum Modul, TI-M zum Fachdienst.
Dieses Chat- und Host-Modell folgt dem gematik-Beispiel in Abschnitt 3.3.4. Für Calling legt der unten beschriebene ITL-Entwurf die Medien- und TLS-Endpunkte zusätzlich fest; das gematik-Beispiel allein spezifiziert keinen zentralen Echtzeit-Audiotransport.
ArbeitsplatzSachbearbeitung / Web-ClientHost-Oberfläche · TLS-Verbindung
HostContact-Center-BackendProzesszuordnung · lokale Modulaufrufe
ModulTI-M Pro Headless ClientE2EE-Endpunkt · keine Netzwerk-API zum Host
FachdienstTI-M Fachdienst ProMatrix-/TI-M-Kommunikation · Anbieterbetrieb
Auch localhost REST, TCP oder WebSocket ist als Headless-Modul-API ausgeschlossen (A_28651). Der Host darf eigene TLS-gesicherte Netzwerkschnittstellen besitzen (A_28734). Direktes und indirektes Bridging in andere Messenger-Systeme ist für den Anbieter verboten (A_28683).
ITL · ADR-001 · R24.23
Calling: ein Headless-Endpunkt, zwei klar benannte Einsatzprofile
ITL legt für diesen Referenzentwurf Matrix-Signalisierung, PeerConnection und DTLS-SRTP-Schlüssel in das Headless-Modul. Der Host übernimmt Bedienung sowie erlaubte Medien-Ein- und -Ausgabe über lokale Funktionsaufrufe. TI-M Basis 1.3.0 führt VoIP als KANN-Modul; die folgende konkrete Aufteilung ist eine ITL-Entscheidung. Sie beschreibt die ausgewählte Architektur und Abnahmekriterien, keine bereits ausgeführte Medienlaufzeit oder gematik-Freigabe.
Ein aktiver Call je lokalem Account-/Gerätekontext, zwei TI-M-Geräte und ein privater, verschlüsselter Raum mit zwei Benutzern. Mehrere Geräte eines Benutzers können ein Invite erhalten; erst die Auswahl des beantwortenden Geräts bestimmt den Medienpartner. Mehrparteienkonferenz, MCU/SFU, SIP/PSTN und Messenger-Bridging gehören nicht zu diesem Entwurf. [3] [5] [2]
Für den zentralen Contact-Center-Pfad wird Profil B gewählt: Der TI-M-Medienendpunkt liegt im Headless-Modul des Servers. Das Arbeitsgerät besitzt eine eigene, authentisierte TLS-Verbindung zum Host. Wer E2EE bis zum Arbeitsgerät benötigt, wählt stattdessen Profil A am Arbeitsplatz bei zentraler Chat- und Fachprozessführung.
A · Lokaler Arbeitsplatz · Audio und Video
Nativer Host und Headless-Modul laufen im kontrollierten Prozess am Bedienarbeitsplatz. Headless hält PeerConnection, Matrix- und Medienschlüssel; der Host stellt Freigabe, Mikrofon/Kamera, Wiedergabe und sichtbare Bedienelemente. PCM-/Bilddaten passieren die lokale Funktionsgrenze. Der Host ist damit ein vertrauenswürdiger Klartextteilnehmer; E2EE schützt nicht vor ihm oder einer kompromittierten Plattform. Die externe Medienroute muss zusätzlich das unten festgelegte TURN/TLS-Profil erfüllen. [2] [9]
B · Zentrales Contact Center · zunächst Audio
Host und Headless-Modul laufen zusammen auf dem zentralen Server. TI-M-E2EE endet dort. Ein authentisiertes Arbeitsgerät überträgt Audio über den eigenen WSS/TLS-1.3-Kanal des Hosts; erst dessen lokale Funktionen greifen auf Headless zu. Der Host darf die freigegebenen Audiodaten im vorgesehenen Versorgungsprozess verarbeiten. Der WSS-Abschnitt ist ein eigener Transport, keine Fortsetzung derselben TI-M-E2EE und keine Headless-Netzwerk-API. Video, Aufzeichnung und Transkription sind in diesem ersten zentralen Profil nicht aktiviert. [2] [9]
Calling · ausgewählter ITL-Referenzentwurf
Wo endet das verschlüsselte Gespräch?
Wählen Sie den Ort des Headless-Moduls. Er bestimmt, wo TI-M-Medien entschlüsselt werden und wie Mitarbeitende am Gespräch teilnehmen.
A · Audio und Video am Arbeitsplatz
Der TI-M-Endpunkt ist das Headless-Modul am Arbeitsplatz.
ArbeitsplatzHost + Headless
Oberfläche, Mikrofon und Lautsprecher
TI-M-E2EE-Endpunkt im lokalen ModulEnde-zu-Ende verschlüsseltAudio / Video
GesprächspartnerTI-M-Client
Gerät des anderen Teilnehmers
Der andere TI-M-E2EE-EndpunktDer vertrauenswürdige lokale Host verarbeitet die erlaubte Klartext-Ein- und -Ausgabe von Audio und Video. Medienschlüssel bleiben in Headless und der Gegenstelle.
B · Zentrales Audio mit eigenem Mitarbeiterkanal
Der TI-M-Endpunkt ist das Headless-Modul im Server. Mitarbeitende verbinden sich separat mit dessen Host.
MitarbeitergerätOberfläche + Audio
Authentifizierter Zugang zum Host
Eigener OperatorabschnittEigener TLS-KanalWSS / TLS 1.3
Contact-Center-ServerHost + Headless
Lokale Modulaufrufe im Prozess
TI-M E2EE endet in diesem ModulEnde-zu-Ende verschlüsseltAudio
GesprächspartnerTI-M-Client
Gerät des anderen Teilnehmers
Der andere TI-M-E2EE-EndpunktDer vertrauenswürdige Server-Host verarbeitet Klartext-Audio. Der Operatorabschnitt erhält eigenen TLS-Schutz; er liegt außerhalb der TI-M-E2EE-Sitzung zwischen Headless und Gegenstelle. Medienschlüssel werden nicht an den Operator exportiert.
Beide Modelle benötigen den vereinbarten Weg über eine kontrollierte TURN-Instanz in einer VM: beide Client-Allocations über TLS, Relay-Weiterleitung nur innerhalb dieser VM. Lässt sich dies nicht nachweisen, bleibt Calling nicht verfügbar.
Technische Diagramme: Medienschutz, TLS-Wege und Modulgrenzen
Türkis markiert den Ende-zu-Ende-Medienschutz; Blau markiert die einzelnen TLS-Transportabschnitte. Die Diagramme in voller Größe lassen sich horizontal verschieben. Der ausgewählte Referenzentwurf und seine Laufzeit-Abnahmekriterien stehen in ADR-001; die Laufzeit-Abnahme ist nicht ausgeführt.
Die TLS-Auslegung ist bewusst eng: In den geprüften Quellen wurde keine ausdrückliche VoIP-Ausnahme von A_25299/A_25573 gefunden. Das ausgewählte TURN-Profil ist eine technische Herleitung, keine offizielle Auslegung der gematik. Seine Realisierbarkeit, Gegenstellenkompatibilität und Freigabe müssen am konkreten Deployment nachgewiesen werden. Ohne belegten Pfad wird der Call nicht zugelassen. [3] [4] [10]
Drei Datenflüsse mit getrennten Endpunkten
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| Signalisierung · beide Profile ITL-Entscheidung | Host-Befehl → lokale Headless-Funktion → E2EE-geschütztes Matrix-Raum-Event über TLS zum TI-M-Fachdienst → Gegenstelle. Die Antwort wird erst nach Prüfung von Raum, Benutzer, Session-Ursprung, Call und ausgewählter Partei wirksam. [5] [6] [3] |
| TI-M-Medien · beide Profile Technische Herleitung | Headless verschlüsselt Medien für das ausgewählte Gegengerät mit SRTP/SRTCP. Die Pakete reisen innerhalb einer TLS/TCP-Verbindung zur eigenen TURN-Allocation, werden innerhalb derselben kontrollierten VM zur Gegen-Allocation weitergereicht und reisen in deren TLS/TCP-Verbindung zum Gegengerät. Auch ICE-/DTLS-Pakete bleiben auf diesem Pfad; der TURN-Dienst erhält keine SRTP-Schlüssel. [10] [11] [3] |
| Bediener-Audio · nur Profil B ITL-Entscheidung | Arbeitsplatz-Aufnahme → authentisierter WSS/TLS-Kanal → zentraler Host → lokale Medienfunktion → Headless. Empfang in Gegenrichtung: Headless entschlüsselt → lokale Medienfunktion → Host → WSS/TLS → Wiedergabe. Klartext entsteht im Servermodul, im autorisierten Host und am Arbeitsgerät. Das Host-WSS transportiert keine TI-M-DTLS-/SRTP-Schlüssel. [2] |
Lokaler Modulvertrag und zentraler Audiokanal
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| Opaque Handles und begrenzte Befehle ITL-Entscheidung | Der lokale Vertrag bietet Call starten/annehmen/ablehnen/beenden, Mikrofon/Kamera-Zustand, Medien-I/O sowie abonnierte Zustandsmeldungen. Opaque Handles sind an Tenant, Account, Gerät, Call und Generation gebunden; ungültige oder wiederverwendete Handles werden abgelehnt. Der Host erhält keine Crypto-Objekte, Rohschlüssel, generischen Netzwerk-Proxy oder API zum Umgehen der Ereignisprüfung. Die C-ABI-Ausprägung ist ITL-Design. [2] |
| Profil B · versionierter WSS-Frame-Kanal ITL-Entscheidung | ITL-Referenzprofil v1: mono PCM16LE mit 48 kHz in 20-ms-Blöcken (1.920 Audio-Bytes), Resampling im vertrauenswürdigen Audioadapter. Jeder Block trägt Kanal-ID, Lease-Generation, Richtung, Sequenz und Capture-Zeit; seine serverseitige Bindung umfasst Tenant, Bediener, Account, Gerät und Call. Nur die vereinbarte Länge und Folge sind zulässig. Zugangstoken stehen nicht in der WebSocket-URL; Frames enthalten keine TI-M-Schlüssel. Dies ist eine Vertragsdefinition, kein ausgelieferter Transport. [2] |
| Profil B · genau ein autorisierter Bediener ITL-Entscheidung | Ein serverseitiger exklusiver Call-Lease verhindert die parallele Medienbedienung einer gemeinsamen Matrix-ID. Referenzwerte: authentisierter Heartbeat alle 5 Sekunden, Lease-Ablauf nach 15 Sekunden ohne gültige Erneuerung; Audio-Puffer höchstens 200 ms je Richtung, danach veraltete Frames verwerfen. WSS-Abbruch, Entzug der Berechtigung oder Lease-Verlust stoppen Medien und Call. Aufzeichnung, persistente Audio-Puffer und Transkription bleiben standardmäßig aus; eine Änderung benötigt einen eigenen Scope und Change. [2] |
Vollständige Calling-Architektur mit Zuständen und Abnahmekriterien öffnen →
Architekturvertrag R24.23 als JSON herunterladen ↓
Versionsgebundene Quellen und technische Referenzen
- gemAnbT_TI-M_Pro ATV 1.2.0-0 · V1.0.0 · Table 1: Krypt 2.50.0 / Basis 1.3.0 / Pro 1.2.0 ↗
- gemSpec_TI-M_Pro 1.2.0 · § 3.3 · A_28651, A_28703/04/10/15/34, A_28849/50 ↗
- gemSpec_TI-M_Basis 1.3.0 · A_25395-03, A_25299, A_25573, A_25598/99 ↗
- gemSpec_Krypt 2.50.0 · GS-A_4385, A_18467, A_18986 ↗
- Matrix Client-Server API 1.17 · Voice over IP ↗
- Matrix 1.17 · m.megolm.v1.aes-sha2 ↗
- Matrix 1.17 · Verification of the sending user for incoming events ↗
- W3C WebRTC 1.0 · Recommendation 2025-03-13 ↗
- RFC 8827 · WebRTC Security Architecture · §§ 4.3, 6.2, 6.4, 6.5 ↗
- RFC 8656 · TURN · §§ 3.1, 12.6, 21.1.6 ↗
- RFC 5764 · DTLS Extension to Establish Keys for SRTP ↗
Kontaktmodell · gemSpec_TI-M_Pro 1.2.0
Person, Funktionsaccount und Chatbot sind verschiedene Kontaktarten.
Der Org-Admin setzt den ConnectionType der Endpoint-Ressource im FHIR-VZD. Die Kennung beschreibt die Art des Kontakts; sie ersetzt weder Rollenberechtigungen noch die Prüfung des fachlichen Zwecks.
| Kontakt | ConnectionType | Normativer Bezug |
|---|---|---|
| Natürliche Person | tim | A_29024 |
| Von Menschen betreuter Funktionsaccount | tim-fa | A_25546 |
| Automatisierter Account / Chatbot | tim-bot | A_25547; Displayname: Name (Chatbot) nach A_25553 |
Primärquelle: gemSpec_TI-M_Pro 1.2.0, Abschnitte 5.2 und 5.4.1 ↗
Host-Anmeldung und Matrix-Account sind getrennte Zuordnungen: Abschnitt 3.3 beschreibt sowohl individuelle Mitarbeiterkonten am Host mit einer gemeinsamen Matrix-ID als auch persönliche Matrix-Accounts. Wer im Fachprozess handelt, muss deshalb im Host- und Berechtigungskonzept benannt werden; aus einer technischen Matrix-ID allein folgt keine individuelle Sachbearbeiteridentität.
Integrationsscope
Produkt, Host und Betrieb konkret zuordnen.
- Modulhersteller und Host-Hersteller benennen
- Anbieter TI-M Pro und GTI-Change zuordnen
- Zweckbindung, Kontaktart und Berechtigungen festlegen
- Matrix-/TI-M-Fehlercodes am Host erhalten (A_28854)
- Profile, Versionen und Abnahmekriterien abstimmen
Gegenstelle des Versicherten
TI-M Client ePA und professioneller Pro-Pfad.
Versicherte nutzen TI-M Client ePA mit TI-M Fachdienst ePA. Die Sachbearbeitung kommuniziert über den professionellen Pro-Pfad des Contact Centers. Der Zugriff auf die elektronische Patientenakte besitzt einen eigenen Vertrag; eine TI-M-Nachricht gewährt keinen Aktenzugriff.
Der TI-M Fachdienst ePA verweigert Profilabfragen ohne gemeinsame Räume mit HTTP 403 und M_FORBIDDEN; /user_directory/search liefert eine leere Ergebnisliste. Das Contact Center erhält dadurch kein allgemeines Verzeichnis der Versicherten. TI-M ePA 1.3.1 · A_26290-01 / A_26375 ↗
Einordnung:
Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA und gematik bezeichnen externe Standards, Infrastrukturen oder Integrationskontexte. Keine Zertifizierung, Zulassung oder Beauftragung durch gematik oder eine andere Behörde wird behauptet. Unterstützte Profile, Versionen und Betriebsgrenzen werden vor einem Einsatz schriftlich bestätigt.
Technische Vertiefung
Headless, Identität/Attribute/Policy und Verantwortungsgrenzen.
Die verlinkten Wissensseiten beantworten Architekturfragen ohne interne Source-Pfade, Runbooks, Roh-Evidence oder Implementierungsdetails offenzulegen.
Headless Client
TI-Messenger Headless Client
Technische Einordnung einer Headless-Client-Integration für PVS, KIS und Contact Center: lokale Produktgrenze, 63-Domain-Messenger-Denominator, Produktoperationskatalog, Native Bindings, Calls und Verantwortungen.
Wissen öffnen →
Access & Policy
Identität · Attribute · Policy
Warum Identitätsprüfung, Attributkontext, fachliche Policy und technische Ausführung in Health-IT-Architekturen nicht als ein einziger Allow/Denied-Schalter modelliert werden sollten.
Wissen öffnen →
Shared Responsibility
PVS/KIS Verantwortungsgrenzen
Orientierungsmodell für Verantwortungsgrenzen zwischen PVS/KIS, MEMM-Produktscope und externen Betreibern – vor Evaluation, Pilot und Produktionsvereinbarung.
Wissen öffnen →
Automatisierung beginnt mit einem klaren Integrationsszenario.
Prozess, Identität, Attribute, Raumkontext, Release und Verantwortungsgrenzen gemeinsam eingrenzen.
Normative Reference · gematik
TI-M im Kassen- und Kontaktcenter-Kontext
Externe gematik-Dokumente zur Architektureinordnung. Die Nennung macht ITL weder zum zugelassenen Hersteller noch zum Betreiber.
PTV · Freigegeben29.09.2026
gemProdT_TI-M_Client_ePA_PTV_1.2.0-0_V1.0.0 ↗
Produkttypsteckbrief TI-M ePA Client; eigener Prüfumfang gegenüber TI-M Pro und Headless.
Architekturbezug: Eigenständiger TI-M-ePA-Client
ATV · Freigegeben29.09.2026
gemAnbT_TI-M_ePA_ATV_1.1.0-0_V1.0.0 ↗
Anbieterverantwortung für TI-Messenger ePA; getrennt von TI-M Client ePA, elektronischer Patientenakte und Headless-Modul.
Architekturbezug: TI-M-ePA-Anbieter / Betrieb
PTV · Freigegeben29.09.2026
gemProdT_TI-M_Client_Pro_PTV_1.1.0-0_V1.0.0 ↗
Produkttypsteckbrief TI-M Pro Client; nicht gleichzusetzen mit TI-M Headless Clientmodul.
Architekturbezug: Eigenständiger TI-M-Pro-Client
ATV · Freigegeben29.09.2026
gemAnbT_TI-M_Pro_ATV_1.2.0-0_V1.0.0 ↗
Anbieterverantwortung für TI-M Pro; unabhängig von Clientmodul, Pro Client und Pro Fachdienst zu prüfen.
Architekturbezug: TI-M-Pro-Anbieter / Betrieb
Die folgenden Anforderungserklärungen beziehen sich auf die geprüften Quellenversionen. Interne R1001-Zähler beschreiben einen eigenständigen Engineering-Scope.
Anforderungen im Zusammenhang
Was die Spezifikationen für diese Architektur bedeuten.
Ausgewählte Anforderungen mit fester Quellenversion. Ein Thema aufklappen, um Verantwortung, Schnittstelle oder Datengrenze nachzulesen.
Lokale Modul-API und Host-Netzwerk
Der TI-M Pro Headless Client muss eine Integrations-API anbieten und darf weder eine eigene Endanwender-GUI noch eine lokale oder öffentliche Netzwerk-API bereitstellen. Das gilt auch für localhost. Das integrierende System darf eigene Netzwerkschnittstellen besitzen und das Modul ausschließlich über die vorgesehenen lokalen Funktionen ansteuern; der Anbieter sichert die integrierenden Netzwerkverbindungen durch TLS. Rust, Flat C ABI und Sprachbindings sind die ITL-Architekturwahl innerhalb dieser Vorgabe.
Alleiniger E2EE-Endpunkt und auditierte Kryptografie
Der TI-M Pro Headless Client muss der alleinige kryptografische Endpunkt der Ende-zu-Ende-verschlüsselten Kommunikation sein. Schlüsselmaterial, interne E2EE-Zustände und rekonstruierbare Sicherheitsinformationen bleiben innerhalb seines geschützten Kontexts; Diagnose-Dumps dürfen sie nicht offenlegen. Für die Nachrichtenverschlüsselung verlangen TI-M Clients eine auditierte, als ausreichend sicher bewertete Olm/Megolm-Implementierung. Die Basis nennt Vodozemac und libolm; andere Implementierungen benötigen einen gleichwertigen Sicherheitsnachweis durch geeignete unabhängige Prüfer. Cross-Signing und Secure Secret Storage and Sharing (SSSS) zur Geräteverifikation sind ebenfalls zu unterstützen. Rust oder ein lokales ABI allein erfüllen diese Anforderungen nicht.
Geschützte Laufzeit, Artefaktprüfung und Audit-Ereignisse
Zum Headless-Betrieb gehören wirksame Prozess- und Zugriffskontrollen, freigegebene Software und der Ausschluss unautorisierter Manipulations- oder Debug-Mechanismen. Der Anbieter beschränkt den Einsatz auf signierte, geprüfte und freigegebene Versionen. Der Integrator prüft beim Laden die Signatur offline gegen einen lokalen Vertrauensanker, soweit technisch möglich, und verweigert die Ausführung bei einem Verifikationsfehler. Sicherheitsrelevante Ablehnungen, Zustandsänderungen und Missbrauchssituationen müssen unverändert und zeitlich korrekt protokolliert werden. Anbieterhinweise müssen klarstellen, dass externe Konfigurationen oder Komponenten diese Audit-Logs nicht unterdrücken oder manipulieren dürfen. A_28703 umfasst keinen Schutz gegen eine kompromittierte Plattform oder privilegierte Administratoren.
Calling: gewählter Headless-Medienendpunkt
TI-M Basis führt VoIP als KANN-Modul. Matrix 1.17 beschreibt Call-Signalisierung über Raum-Events und WebRTC mit zwei Geräten je Call. Der R24.23-Referenzentwurf legt Matrix-E2EE, PeerConnection und DTLS-SRTP-Schlüssel in das Headless-Modul; der Host übernimmt Bedienung und autorisierte lokale Medien-I/O. Das ordnet die Architektur dem alleinigen E2EE-Endpunkt und der Isolation nach A_28710/A_28715 zu. Lokal endet TI-M-E2EE am Arbeitsplatzmodul, zentral am Servermodul mit einem eigenen TLS-Audiokanal zum Bediener. Der Entwurf ist keine geprüfte Runtime oder gematik-Freigabe.
Calling: TLS ist nicht mit DTLS gleichzusetzen
A_25299 verlangt TLS zwischen TI-M-Komponenten über virtuelle/physische Maschinengrenzen; A_25573 bindet gemSpec_Krypt ein. Eine ausdrückliche VoIP-Ausnahme wurde in den geprüften Quellen nicht gefunden. Deshalb beschränkt ITL den Entwurf auf zwei TURN-Allocations über TLS/TCP an derselben kontrollierten Instanz/VM und ausschließlich lokale Relay-Weiterleitung. turns-URL und relay-Candidate allein belegen den Pfad nicht; bei fehlender beidseitiger Zusicherung bleibt Calling nicht verfügbar. Das ist eine enge technische Herleitung, keine offizielle Auslegung. Allgemeine TLS-1.2-Unterstützung bleibt erhalten; TLS 1.3 ist die Wahl dieses Medienprofils.
Calling: Session-Ursprung und Medienpartner prüfen
party_id identifiziert eine Call-Partei, muss aber nicht der Matrix-Geräte-ID entsprechen. Matrix 1.17 verbietet, äußere Megolm-Felder sender_key/device_id als Ursprungsnachweis oder Session-Index zu verwenden. Der Entwurf bindet den geprüften Benutzer und Geräte-Vertrauensnachweis über die validierte Session an Raum, call_id, party_id und SDP-Fingerprint. Erst ein passender DTLS-Handshake und der zulässige Relay-Pfad geben Medien frei. Explizit bestätigtes Gerätevertrauen vor Calling ist eine strengere ITL-Policy; TLS zum Homeserver allein authentisiert den Medienpartner nicht.
TI-M-Scope des Matrix-Integrationsmodells
Der Anbieter TI-M Pro darf den Headless Client weder unmittelbar noch mittelbar für Bridging in andere Messenger-Systeme verwenden. Zusätzlich verbietet die Basis-Spezifikation serverseitiges Bridging in andere Nachrichtenprotokolle. Ein interner R1001-Eintrag mit der Bezeichnung Bridge State ist deshalb keine freigegebene TI-M-Bridge-Funktion. Host-Prozessintegration und zulässige Automatisierung müssen diese Grenze einhalten.
Hersteller, Integrator und Anbieter
Der Modulhersteller verantwortet den Produkttyp; der Host-Hersteller integriert das Modul in sein System. Der Anbieter TI-M Pro übernimmt die betriebliche Verantwortung, wenn er das Headless-Produkt anbietet. Auch On-Premise-Betrieb ist mit ihm abzustimmen. Er benennt jedes integrierende System samt Hersteller und Architektur im Betriebshandbuch und prüft dessen Aktualität mindestens halbjährlich ab Zulassung. Vor Integration und bei wesentlichen Änderungen muss er die Freigabe des Gesamtverantwortlichen für die TI (GTI) im betrieblichen Change-Verfahren einholen.
Berechtigte Organisation und Versorgungszweck
Headless-Integration und Betrieb sind auf Systeme von Gesundheitsorganisationen beschränkt, die TI-M bestellen und nutzen dürfen. Die verarbeiteten medizinischen Daten dienen ausschließlich der Gesundheitsversorgung oder deren Organisation. Mehrzwecksysteme benötigen technische und organisatorische Maßnahmen gegen unbefugten Zugriff anderer Organisationseinheiten. Ein Contact Center kann im zentralen Host Chats im Versorgungsprozess zuordnen; daraus folgt keine Erlaubnis für fachfremde Datennutzung.
Kontaktarten und Profilangaben
Der Org-Admin kennzeichnet Kontakte in der FHIR-VZD-Endpoint-Ressource: tim für eine natürliche Person, tim-fa für einen von Menschen betreuten Funktionsaccount und tim-bot für einen automatisierten Account. Ein Chatbot führt den Zusatz (Chatbot) im Displaynamen. Im Nutzerprofil ist de.gematik.user.orgname verpflichtend; orgtype, orgfachrichtung, orgaddress und beruf sind optionale Zusatzfelder. Der Org-Admin-Client bietet passende FHIR-VZD-Werte zur Übernahme an. Diese Profilangaben ersetzen keine Berechtigungsprüfung.
Protokollfehler bleiben auswertbar
Der Headless Client muss die Fehlercodes der Matrix Client-Server API und der TI-M-Spezifikation an das integrierende System weiterreichen. Ein typisierter ITL-Vertrag muss diese Codes semantisch erhalten. Diagnose- und Stack-Texte mit Geheimnissen können redigiert werden; ein allgemeines internes Fehler-Enum darf den erforderlichen Protokollcode nicht ersetzen. Sicherheitsvorfälle können zusätzlich eine begrenzte Außendiagnose und Schutzmaßnahmen erfordern.
Berechtigungskonfiguration und Auskunft
permissionConfig_V1.json beschreibt die Pro-Berechtigungskonfiguration mit defaultSetting und Ausnahmen für Server, Nutzer oder Gruppen. TiMessengerInformation.yaml bietet eine gesonderte HTTP-Auskunft mit Matrix-OpenID-Token: findByIk löst eine IK-Nummer zu einem Servernamen auf; isInsurance prüft dessen Kennzeichnung als Versichertendomäne. Der Domainteil einer MXID dient damit der Gruppenzuordnung, nicht der Prüfung einer individuellen medizinischen Berechtigung. Beide Schnittstellen sind im Headless-PTV auf Commit a67678018fb06bff1c14e7a1347631587dc57db5 festgelegt. Ein allgemeiner ITL-Begriff wie Authorization ist auf diese konkreten Protokollverträge abzubilden.
TI-M Pro, TI-M ePA und elektronische Patientenakte
Versicherte kommunizieren über TI-M Client ePA und TI-M Fachdienst ePA. Fachanwender und der zentrale Contact-Center-Host nutzen die Pro-Produktrollen. TI-M ePA ergänzt die Basis um Authentisierung am sektoralen KTR-IDP mit OIDC/PAR und die Verzeichnissuche /fdv/search. Client und Fachdienst verhindern die Raumeinstellungen public/knock für Join Rules, world_readable für History Visibility, public für das Raumverzeichnis und inaktive Verschlüsselung; unzulässige Raumänderungen lehnt der Fachdienst mit HTTP 400 und M_INVALID_ROOM_STATE ab. Versicherte erhalten keine Administration fremder Nutzerkonten; Einladungen zwischen zwei Versicherten werden durch den TI-M-ePA-Proxy im Client-Server-Pfad abgelehnt. Der Zugriff auf die elektronische Patientenakte besitzt einen eigenen ePA-FdV-/Aktensystemvertrag.
Fragebögen als konkreter TI-M-ePA-Vertrag
TI-M ePA Clients müssen de.gematik.questionnaire.generic v1 und de.gematik.questionnaire.consent v1 auf Empfängerseite unterstützen: Capabilities unmittelbar nach Login veröffentlichen, empfangene Fragebögen einschließlich Vorbelegungen ausfüllbar darstellen, finale Antworten als de.gematik.fhir-Event zurücksenden und beantwortete Fragebögen später wieder anzeigen. Die Pflicht betrifft den TI-M Client ePA. Sie beschreibt keinen bereits nachgewiesenen MEMM-Formularumfang und gewährt keinen Zugriff auf die elektronische Patientenakte.
Redaktioneller Quellenabgleich: 17. Oktober 2026. Die Zuordnung erklärt Anforderungen; Implementierungsprüfung und Produktzulassung benötigen eigene Nachweise.