Was ist die eigentliche Integrationsfrage?
Für Hersteller von PVS, KIS oder Contact-Center-Lösungen ist nicht nur entscheidend, ob Messaging technisch möglich ist. Entscheidend ist, an welcher Grenze Lifecycle, Identität, Zustände, Fehler und Updates zwischen Primärsystem und Headless-Komponente übergeben werden.
Die öffentliche MEMM-Architektur beschreibt deshalb zuerst die lokale Produktgrenze und erst danach einzelne Protokoll- oder Plattformdetails. Das reduziert implizite Annahmen darüber, welcher Teil des Gesamtsystems welchen Zustand besitzen oder betreiben soll.
Welche Fragen sollten vor einer Integration beantwortet sein?
- Welche lokale API- oder Binding-Grenze wird für den konkreten Release unterstützt?
- Wer besitzt Session-, Geräte-, Update- und Diagnoseverantwortung?
- Welche externen Profile und Versionen gehören zum vereinbarten Scope?
- Welche Zustände werden an das Primärsystem zurückgegeben und welche bleiben innerhalb der Produktgrenze?
Welche Funktionsbereiche bildet der aktuelle Katalog ab?
- Produktinformation, Service-Account und Session-Lifecycle.
- Directory-/Discovery-Funktionen einschließlich FHIR-VZD-bezogener Zuordnungen und Suche.
- Messaging, Historie, Bearbeitung und Redaktionsvarianten.
- Räume, Einstellungen, Mitgliedschaft und State-Events.
- Media-Upload und authentisierter Abruf.
- Explizite Authorization-Modi sowie Allow-/Block-Listen.
Wie ist 63/63 Messenger-Abdeckung einzuordnen?
- 26 Core-Foundation-Domänen bilden Lifecycle, Updates, Projektionen, Conversation/Timeline, Delivery, Rooms, Realtime, Media, Search sowie E2EE-/Cache-Grundlagen ab.
- 9 Account-/Room-Safety-Domänen decken Profile, Safety, Pins, Bookmarks, Permalinks, Directory/Aliases, Preferences und Device Sessions im deklarierten Scope ab.
- 15 Rich-/Presentation-Domänen umfassen Polls, Location, Voice, Stickers sowie Accessibility-, Locale-, Theme-, Composer- und Darstellungszustände.
- 9 Call-Domänen decken Availability, Invite, Ringing, Session, Participants, Media State, Permissions, Transport und Encryption innerhalb der deklarierten Verantwortung ab; 4 interne Domänen betreffen Widgets, Bridge State, Bot Integrations und Integration Permissions. Bridge State ist eine interne Katalogbezeichnung: Im TI-M-Pro-Betrieb darf der Anbieter den Headless Client weder direkt noch indirekt zum Bridging in andere Messenger-Systeme verwenden (gemSpec_TI-M_Pro 1.2.0, A_28683).
- Die Call-Surface nutzt die bestehende Messenger-Operation-Grenze: fünf Signalisierungsoperationen plus elf Media-/Session-Operationen, ohne den separaten 37/37-Produktoperationszähler künstlich zu erhöhen.
- Die 63-Domain-Abdeckung ist ein eigener Messenger-Denominator und nicht identisch mit dem 37-Operationen-Host-/Native-Katalog.
Einordnung zu TI-Messenger_26_2
Die laufende Entwicklung berücksichtigt ausgewählte Anforderungen der gematik-Veröffentlichung TI-Messenger_26_2 und den dort beschriebenen Headless-Client-Produkttyp als veröffentlichte Vergleichsreferenz. Die Anforderungsdifferenz zur früheren Draft-Fassung ist separat zu bewerten. Eine solche Referenz ist keine Aussage über vollständige Umsetzung, Konformität, Zertifizierung, Zulassung oder allgemeine Verfügbarkeit.