Produkt & Session
Produktinformation, Service-Account-Kontext, Login/Logout und ein ausdrücklich nicht-produktiver Cleanup-Pfad.
TI-Messenger Headless Client
TI-Messenger Headless Client für PVS, KIS und Contact Center
Kommunikation als Produktkomponente – nicht als zweites Produkt.
MEMM bringt Kommunikationsfunktionen als lokale, versionierbare Produktkomponente in PVS, KIS, OEM- und Contact-Center-Architekturen. Die Fachanwendung integriert gegen klar abgegrenzte Host-, API- und Native-Verträge, während der technische R1001-Nachweis separat und überprüfbar bleibt.
Entwicklungsreferenz: Die laufende Entwicklung berücksichtigt ausgewählte Anforderungen der gematik-Vorabveröffentlichung
Draft_TI-Messenger_26_2 und des dort beschriebenen Headless-Client-Produkttyps. Daraus wird keine Konformität, Zulassung oder allgemeine Verfügbarkeit abgeleitet.Integrationsnutzen
Komplexität kontrollieren, statt sie in die Fachanwendung zu verschieben.
Der Nutzen liegt in expliziten, versionierbaren Produktgrenzen, gegen die Fachanwendungen ihre UI/UX- und Prozesslogik entwickeln können. Regulatorische und externe Betriebsverantwortung bleibt davon getrennt.
01Fachlogik entkoppeln
Ausgewählte Protokoll-, E2EE- und Integrationsdetails bleiben hinter einer benannten Headless-Grenze statt in jeder Fachanwendung neu zu entstehen.
02Integration planbar machen
Lifecycle, Fehler, Ownership und Releasewechsel werden als versionierbare Verträge behandelt.
03Wiederholung reduzieren
Der Rust-basierte Kern bündelt technische Verantwortungen, die Host-Systeme im vereinbarten Scope nicht erneut als eigene Runtime bauen müssen.
Zielbild: ein schnellerer Weg vom Architektur-Scope zur belastbaren Integration – ohne pauschale Time-to-Market-Zusage.
Einordnung Diese Aussagen beschreiben Architekturziele und mögliche Integrationsvorteile. Sie sind keine Garantie für Entwicklungsdauer, Compliance, Zulassung, vollständige regulatorische Entlastung oder ein bestimmtes Projektergebnis.
Produktoperations-Katalog
37 Produktoperationen in sechs Host-/Native-Clustern – plus eine eigene Call-Surface.
Der source-local Host-/Native-Katalog umfasst weiterhin 37 Produktoperationen in sechs Clustern. R1001 führt Calls zusätzlich über die bestehende Messenger-Operation-Grenze; diese Call-Surface wird separat ausgewiesen und erhöht den 37/37-Zähler nicht künstlich.
Directory & Discovery
FHIR-VZD-bezogene Sichtbarkeit, Authentisierung und MXID-Zuordnung sowie Practitioner- und Homeserver-Suche innerhalb des gebundenen Headless-Scope.
Messaging
Direkte und raumbezogene Nachrichten, Historie, Bearbeitung sowie kontrollierte Redaktions- und Ersetzungsvarianten.
Rooms
Raumlisten, Erstellung, Einstellungen, Mitgliedschaftsübergänge, Forget und State-Event-Abfragen.
Media
Upload und authentisierter Abruf als benannte Produktoperationen innerhalb derselben Host- und Ownership-Grenze.
Authorization
Expliziter Autorisierungsmodus sowie Allow-/Block-Listen als typisierte Headless-Produktgrenzen.
Calls9 / 9 Domänen16 bounded Messenger-Operationen
Matrix-VoIP-Signalisierung + hostseitige WebRTC-Media-/Session-Grenze
R1001 bildet Call-Verfügbarkeit, Invite, Ringing, Session, Participants, Media State, Permissions, Transport und Encryption als 9/9 vollständig belegte Messenger-Domänen ab. Auf der bestehenden Messenger-Operation-Grenze stehen fünf Signalisierungsoperationen für Verfügbarkeit, Invite, Answer, Reject und Hangup sowie elf begrenzte Media-/Session-Operationen für Session-Open/Close, Transport/ICE, Berechtigungen, Verschlüsselungsfakten, Media State, Session-Phasen, Teilnehmer, Renegotiation und Finality bereit.
MEMM / Matrix signaling→bounded Call contracts→Host-owned WebRTC media runtime
Die Media-Laufzeit bleibt Verantwortung des integrierenden Systems. MEMM bündelt Signalisierung sowie versionierte Media-/Session-/Security-Facts und bildet diese Grenze auch in Java 21 Panama, Kotlin und Swift ab.
Einordnung 37 Operationen sind der definierte aktuelle Headless-Produktoperationskatalog. Die zusätzliche Call-Surface nutzt die bestehende Messenger-Operation-Grenze und wird deshalb separat gezählt. Weder 37/37 noch die Calling-Surface sind ein Zähler für vollständige TI-M-Spezifikation, gematik-Zulassung, Produktionsfreigabe oder externe Provider-Interoperabilität.
Messenger Functional Breadth
63/63 Domänen im festen Messenger-Denominator – source-local auf 100% geschlossen.
R1001 hält den bereits fixierten Messenger-Denominator unverändert und bindet jede Domäne an ausführbaren Source-/Testnachweis innerhalb ihrer deklarierten Verantwortungsgrenze.
Alle 63 Domänen sind im gebundenen R1001-Stand als executable_source mit Reifegrad 100 geführt.
Arithmetische Breadth über den festen 63-Domain-Denominator: 100,00%.
Die 26 Core-Foundation-Domänen liegen innerhalb ihres deklarierten Scope bei 100,00%.
R1001 bindet Verhalten an ausführbare Evidenz; reine Marker- oder Zahleneinträge reichen für den 100%-Status nicht aus.
Core Foundation
Lifecycle, Update Stream, Projektionen, Conversation/Timeline, Delivery, Security, Rooms, Realtime, Media, Search und E2EE-/Cache-Grundlagen.
Account & Room Safety
Profile/Safety, Pins, Bookmarks, Permalinks, Directory/Aliases, Preferences und Device Sessions.
Rich & Presentation
Polls, Location, Voice, Stickers sowie Accessibility, Locale, Theme, Composer-, Draft-, Preview- und Delivery-Darstellung.
Calls & Integrations
9 Call-Domänen: Availability, Invite, Ringing, Session, Participants, Media State, Permissions, Transport und Encryption. 4 Integrationsdomänen: Widgets, Bridge State, Bot Integrations und Integration Permissions.
Einordnung 100% bezieht sich ausschließlich auf den festen, verantwortungsbegrenzten 63-Domain-Messenger-Denominator und dessen Core-Foundation-Teilmenge. Daraus werden weder vollständige TI-M-Spezifikationsabdeckung noch Produkt-Funktionsvollständigkeit, Release-Reife, gematik-Zulassung, Provider-Interoperabilität oder externe Konformität abgeleitet.
Technischer Produktpass
Versionsgebundener Headless-Stand – kompakt und nachvollziehbar.
Für bestehende Kunden und technische Evaluierungen trennt dieser Status den aktuell öffentlich belegbaren Headless-Scope von Release-, Provider- und Produktionsfreigaben.
Gebundene source-local Reviewbasis. Website-Beschreibung geprüft: 23.08.2026.
Fester verantwortungsbegrenzter Messenger-Denominator; Breadth und Core Foundation jeweils 100%.
Source-bound Produktoperationsparität bleibt über Rust, Flat C ABI, Java 21, Kotlin und Swift erhalten.
Exakte aktuelle Rust-Workspace-/Native-Sanitizer-, autorisierte Release- und externe Provider-/Konformitätsnachweise bleiben separate Gates.
Versionierter Produktpass
Technical Product Brief · R1001
Architektur, Messenger-Denominator, Native Boundary, Calling Surface und Runtime-Invarianten in einem kompakten Dokument für technische Reviews.
Headless Website ChangelogStand 23.08.2026
Product Passport UX Polish. PDF-Produktpass und Scope-Composer sind prominenter, der technische Stand wird als source-bound R1001 statt als Git-Freshness-Signal geführt; Capability- und Evidence-Claims bleiben unverändert.
R1001 Calling Surface. Die Headless-Seite weist die 9/9 Call-Domänen und die getrennte, bestehende Messenger-Operation-Grenze für Signalisierung und hostseitige WebRTC-Media-/Session-Facts jetzt explizit aus.
R1001 Messenger Breadth. Der feste 63-Domain-Messenger-Denominator wird mit 63/63, 100% Breadth und 100% Core Foundation öffentlich eingeordnet; die Aussage bleibt source-local und responsibility-bounded.
Product Passport & Conversion. Technischer Status, versioniertes PDF-Briefing, kontextuelle CTA und lokaler Scope-Composer auf Basis des damaligen R984-Headless-Standes.
R984 Headless Operations. Öffentliche Einordnung des 37-Operationen-Katalogs, der sechs Funktionscluster und der aktuellen nativen Integrationsgrenze.
Einordnung Der Status dokumentiert die öffentliche Integrations- und Reviewgrenze. Er ist kein Ersatz für projektspezifische Abnahme, Zulassung, Providerfreigabe, SLA oder Produktionsentscheidung.
TI 2.0 Einordnung
Headless Integration als Anwendungsgrenze – nicht als Ersatz des TI-Zugangs.
Der Wandel zu hardwareunabhängigem TI-Zugang und digitalen Identitäten erhöht die Bedeutung klarer Software- und Verantwortungsgrenzen. MEMM positioniert den Headless Client innerhalb der Fachanwendung; TI-Gateway und externe TI-Zugangsdienste bleiben außerhalb dieses Scopes.
Identity-Evidence als eigene Grenze
Der aktuelle versionsgebundene Entwicklungsstand umfasst eine separate Adaptergrenze für EUDI Wallet, Health ID und eID-LE. Identitätsverifikation erzeugt dabei nicht automatisch eine fachliche Autorisierung.
Keine implizite TI-2.0-Zusage
Headless, Identity/Policy und E2EE werden als Integrationsbausteine eingeordnet. Eine ZETA-, OIDC-, TI-Gateway-, PoPP-, VSDM-2.0-, ePA- oder E-Rezept-Implementierung wird daraus nicht abgeleitet.
Native Integrationsgrenzen
Ein klarer Host-Vertrag statt impliziter Laufzeitannahmen.
Die technische Konkretisierung bleibt bewusst auf der öffentlich relevanten Grenze: Host, Binding, Flat C ABI / FFI und Rust-basierter Kern. Packaging, Plattformfreigaben und Performance werden daraus nicht abgeleitet.
HostPVS / KIS / Contact Centerbestehende Fachanwendung
BindingsJava 21 · Kotlin · Swiftim aktuellen Prüfkontext gegen die ABI gebaut
ContractFlat C ABI / FFIlokale, explizite Host-Grenze
CoreRust-basierter Kernfachliche Ownership bleibt unterhalb der Binding-Grenze
Java 21 Panama, Kotlin und Swift wurden im verfügbaren Prüfkontext gegen die aktuelle ABI gebaut. Der exakte aktuelle Rust-Workspace-Run sowie autorisierte Release- und Provider-Nachweise bleiben separate Voraussetzungen.
Runtime-Invarianten
Headless-Betrieb ohne neue Pooling- oder Polling-Inseln.
Der aktuelle source-local Reviewstand hält die Integrationsarchitektur auf wenige benannte Ownership- und Update-Grenzen begrenzt.
01Keine Pooling-Insel
Die Native-Grenze führt keinen zweiten Datenbank-, Connection-, Worker- oder Async-Runtime-Owner ein.
02Keine Polling-Insel
Update- und Laufzeitpfade bleiben producer-notified oder ausdrücklich begrenzt statt einen unabhängigen Poller aufzubauen.
03Subscription-first
Fortlaufende Updates werden über die bestehende Subscription-/Host-Executor-Grenze eingeordnet statt über einen zweiten Hintergrundowner.
04Begrenzte Facades
Native Bindings sind in Capability-Objekte aufgeteilt; der Root-Client bleibt Owner/Factory statt zu einer monolithischen Weiterleitungsfassade zu wachsen.
Einordnung Diese Invarianten sind source-local/static geprüft. Sie ersetzen keinen exakten aktuellen Rust-Workspace-, Last-, Betriebssystem- oder Provider-Test.
Host Boundary
Was der Host sieht – und was keine Host-Oberfläche sein soll.
Für eine eingebettete Headless-Komponente ist die wichtigste Sicherheitsfrage nicht ein abstrakter Score, sondern die explizite Trennung von Produktdaten, Lifecycle, Diagnose und kryptographischem Zustand.
Öffentliche Integrationsgrenze
Host / Primärsystem
- versionierte Eingaben und Produktdaten
- typisierte Status- und Fehlerklassen
- Lifecycle- und Update-Verträge
- redigierte Diagnoseinformationen
MEMM BoundaryHeadless Runtimeproduktseitig kontrollierter E2EE-Kontext
Keine öffentliche Host-Oberfläche
Kryptographischer Zustand
- rohes Schlüssel- oder Sessionmaterial
- rekonstruierbarer Crypto-Runtime-Zustand
- interne Security-Authority-Mechanik
- Raw-Memory- oder Dump-Funktionen
Diese Darstellung beschreibt die aktuelle Architektur- und Reviewgrenze. Sie ist kein Nachweis vollständiger Isolation in jeder Zielumgebung und keine Produktionsfreigabe.
Kryptographische Zustandsgrenze
Vier konkrete Schutzprinzipien aus dem aktuellen versionsgebundenen Reviewstand.
Die Begriffe bleiben bewusst auf Mechanismus- und Boundary-Ebene. Es werden weder absolute Sicherheit noch bestandene externe Produktions- oder Betriebsevidenz behauptet.
01Produktseitiger E2EE-Endpunkt
Der betrachtete Headless-Pfad hält kryptographische Zuständigkeit innerhalb einer benannten Produktgrenze statt eine austauschbare Host-Security-Authority als öffentlichen Vertrag zu behandeln.
02Begrenzte Secret Ownership
Für ausgewählte sensible Speicherinhalte sieht der aktuelle Entwicklungsstand begrenzte Ownership- und Zeroisierungsmechanismen vor. Daraus wird keine allgemeine Memory-Safety-Garantie abgeleitet.
03Secret-safe Diagnose
Fehler- und Diagnosepfade werden auf typisierte oder redigierte Informationen begrenzt; rohe Abhängigkeitstexte und geheimes Material gehören nicht zur öffentlichen Diagnosegrenze.
04Transport & Host-Betrieb
Weiterleitung über Netzwerkgrenzen benötigt einen expliziten TLS- und Verantwortungsrahmen. Dump-, Debug- und Raw-Memory-Fragen bleiben zusätzlich eine Host- und Deployment-Verantwortung.
Einordnung Quell-/Static-Review und lokal ausführbare Prüfungen sind nicht gleichbedeutend mit externer Produktionsvalidierung. Controlled OS dump/memory exercises, Live-Provider-Interoperabilität und autorisierte Release-Freigaben bleiben separate Nachweise.
Integrationsvertrag
FFI ist nicht das Produktversprechen. Der kontrollierte Vertrag ist es.
Enterprise-Integration wird durch Typ-, Lifecycle-, Fehler- und Ownership-Grenzen belastbar – nicht durch die bloße Existenz eines Bindings.
01API & ABI
Aufrufbare Oberfläche, Version und zulässige Übergabepunkte.
02Lifecycle & Ownership
Start, Shutdown, Zustandsübergaben und Host-Verantwortung.
03Fehler & Update
Fehlerklassen, Wiederanlauf und Releasewechsel als Teil des Vertrags.
No-UI / lokale Host-Grenze
Eine eingebettete Komponente muss nicht zum zweiten Administrationsprodukt werden.
Im betrachteten Headless-Pfad wird die Host-Integration als lokale Funktionsgrenze eingeordnet. Externe Kommunikation bleibt davon getrennt; die Seite behauptet nicht, dass jede MEMM-Funktion ausschließlich lokal oder ohne Netzwerkkommunikation arbeitet.
Host-Perspektive
- lokaler Integrationsvertrag
- explizite Zustands- und Fehlerübergabe
- benannter Lifecycle- und Update-Scope
Abgrenzung
Generische Management-Oberflächen, externe Provider-Dienste und projektspezifische Betriebsmodelle werden nicht aus der lokalen Headless-Grenze abgeleitet.
Lokale Headless-Architektur vertiefen →Technische Vertiefung
Headless Client, native Verträge und kryptographische Grenze.
Die Wissensseiten erklären Architekturprinzipien, ohne interne Implementierungsdetails, Runbooks oder Roh-Evidence 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 →
Technologiegrenze
Rust & native Integration
Technische Einordnung des Rust-basierten MEMM-Kerns und einer lokalen FFI-Grenze für native Fachanwendungen – ohne pauschale Plattform- oder Performancezusage.
Wissen öffnen →
Security Boundary
Kryptographische Isolation
Architekturprinzip für eine eingebettete Headless-Komponente: E2EE-Zustand, Host-Daten, secret-safe Diagnose, Zeroisierung und externe Transporte als getrennte Grenzen behandeln.
Wissen öffnen →
Sie evaluieren einen konkreten Headless-Scope?Ordnen Sie Zielsystem, Bindings und benötigte Produktoperationen ein, ohne einen generischen Demo-Prozess zu starten.
Concept UI · synthetische Daten
Headless Client – Betriebskonzept
Beispielhafte Perspektive auf Instanzen, Zustandswechsel, offene Hinweise und Integrationsstände. Alle Inhalte sind synthetisch.
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.
Nächster technischer Schritt
Nicht mit einer Demo beginnen. Mit dem Integrationsscope.
Ein erstes technisches Gespräch dient dem Abgleich Ihrer Zielarchitektur mit den aktuellen MEMM Produkt- und Integrationsgrenzen – ohne daraus Verfügbarkeit, Konformität oder Liefertermin abzuleiten.
Architektur-Check
PVS, KIS, AVS, OEM oder Contact Center: Wir ordnen Host-Grenze, native Integration und erforderliche Headless-Produktoperationen ein.
Spezifikations- & Architekturabgleich
Wir betrachten relevante externe Profile und Versionsstände im Kontext Ihres Zielsystems und benennen offene, externe oder projektspezifische Voraussetzungen ausdrücklich.
Scope vor Pilot
Frühe Scope-Klärung reduziert technische und organisatorische Unsicherheit: Fachanwendung, MEMM-Produktgrenze und externe TI-/Provider-Verantwortung werden vor Pilotannahmen getrennt.
Technischer Scope-Composer
Gespräch strukturiert vorbereiten.
Die Eingaben werden nicht an diese Website übertragen. Nach dem Klick öffnet sich Ihr lokales E-Mail-Programm mit einem vorbefüllten Scope. Bitte senden Sie keine Gesundheits- oder Patientendaten.
Wenn Ihr System keinen mailto:-Handler verwendet, können Sie die Kontaktadresse direkt über die allgemeine Kontaktseite öffnen.
Einordnung Architektur- und Spezifikationsabgleich sind technische Einordnung, keine Rechtsberatung, Zertifizierung, Zulassung, Verfügbarkeitszusage oder verbindliche Aufwandsschätzung.