API- und Verantwortungsgrenzen werden für einen konkreten Integrationsscope definiert, dokumentiert und versioniert.
TI-MESSENGER PRO / ENGINEERING PREVIEW
Matrix-basierte Technologiegrundlage für einen TI-M Fachdienst Pro.
ITL entwickelt eine spezialisierte Rust-basierte Matrix-Technologiegrundlage für serverseitige Kommunikationsfunktionen im Gesundheitswesen. Im Mittelpunkt stehen explizite Schnittstellen, nachvollziehbare Zustände und klar benannte Integrationsgrenzen.
In Entwicklung · kein produktiver TI-M Fachdienst Pro
Das Angebot befindet sich in Entwicklung. Implementierung, unterstützte Profile, Interoperabilität, Betrieb und gematik-Zulassung werden getrennt und versionsbezogen geprüft.
- Rust / Matrix
- Versionierte Schnittstellen
- Klare Zuständigkeiten
TI-M FD PRO · GRENZEN
Vier Grenzen. Ein expliziter Scope.
01EXTERNE ROLLEFachanwendung / OEMPVS, KIS, Unternehmenssoftware
Client und Fachlogik bleiben außerhalb der Technologiegrundlage.
02PROJEKTGRENZEIntegrationsvertragMatrix-Schnittstellen · versionierte Zuständigkeiten
Nur ein vereinbarter, geprüfter API- und Betriebsscope definiert die Integration.
03TECHNOLOGIEKANDIDATITL Rust / Matrix FoundationKandidat für serverseitige Technologie
Architekturziel; keine Zusage eines vollständig implementierten Matrix- oder TI-M-Servers.
04NORMATIV + EXTERNTI-M Fachdienst Pro KontextRegistrierung · Föderation · VZD FHIR · Anbieter
Normative Anforderungen und externe Abhängigkeiten, keine ITL-Zulassung oder Vollimplementierung.
PTV 1.1.0-0 · 29.09.2026Nur konzeptionell
Vereinfachtes Architekturmodell. Keine Aussage über produktiven Betrieb, vollständige Interoperabilität oder gematik-Zulassung.
01 / CONTEXT
Warum eine spezialisierte Grundlage?
Kommunikation über Organisationsgrenzen hinweg ist mehr als die Bereitstellung eines Matrix-Homeservers. Identität, Rechte, Föderationszugehörigkeit, Verzeichnisdienste, Datenhaltung und Betrieb müssen für den jeweiligen Produkttyp zusammen betrachtet werden.
Für OEM-, PVS- und KIS-Teams entstehen dadurch viele Integrations- und Verantwortungsgrenzen. Wir betrachten diese Grenzen als explizite technische Verträge, statt sie im Fachsystem zu verstecken.
Klare Architekturprinzipien
Eine Rust/Matrix-Grundlage soll die Prüfung shard-bewusster Speicher- und Ereignisverarbeitung ermöglichen. Belastbare Leistungs- und Skalierungswerte sind separat nachzuweisen.
Architekturziel, Implementierung, Tests, Interoperabilität, Zulassung und Betriebsbereitschaft erscheinen als unterschiedliche Prüfebenen.
MEMM, Fachsysteme und externe TI-M-Dienste bleiben eigenständige, vertraglich abgegrenzte Komponenten.
03 / ARCHITECTURE
Vier Grenzen. Ein expliziter Scope.
Das vereinfachte Modell zeigt vier Bereiche: Fachanwendung oder OEM, versionierte Integrationsverträge, eine mögliche ITL Rust/Matrix Server Foundation und den normativen beziehungsweise externen TI-M Fachdienst Pro Kontext.
Registrierungs-Dienst, TI-Föderation, VZD-FHIR, Identitätsprüfung und Betreiberpflichten werden als gesonderte Anforderungen oder externe Abhängigkeiten ausgewiesen. Die Darstellung belegt keine vollständige Implementierung.
ITLRust / Matrix FoundationTechnologiekandidat für serverseitige Funktionen
≠KEIN VOLLSTÄNDIGER FD PRO
gematikTI-M Fachdienst ProProdukttypanforderungen / Betreiberverantwortung
Die Technologiegrundlage ist kein vollständiger, zugelassener Fachdienst.
Vereinfachtes Architekturmodell. Keine Aussage über produktiven Betrieb, vollständige Interoperabilität oder gematik-Zulassung.
Entwicklung, Nachweise und Grenzen
Wir untersuchen Matrix-nahe Serverfunktionen, API-Verträge und Konzepte für verteilte Datenflüsse. Ein konkret unterstützter Umfang wird erst nach Prüfung von Version, Testumgebung und Nachweisen veröffentlicht.
01Matrix-ServerfunktionenNicht unabhängig verifiziert
02Registrierung / IdentitätNicht unabhängig verifiziert
03VZD FHIR / FöderationNicht unabhängig verifiziert
04Anbieter / BetriebNicht unabhängig verifiziert
In Entwicklung · kein produktiver TI-M Fachdienst Pro
Die Einordnung zu Registrierung, Föderation, VZD-FHIR, Sicherheit und Betrieb erfolgt getrennt. Die normative Forderung an eine Schnittstelle ist kein Nachweis ihrer Umsetzung durch ITL.
Aktueller öffentlicher Status: In Entwicklung. Kein allgemeiner Nachweis eines vollständigen TI-M Fachdienst Pro, keiner gematik-Zulassung und keiner zugesagten Produktivverfügbarkeit.
Produktstatus & Trust →Technische Evaluation statt Direktanschluss
Abgrenzung von Integrations- und Messaging-Schnittstellen in bestehenden Fachsystemen.
Gemeinsame Prüfung von Serverfunktionen, föderationsbezogenen Abhängigkeiten und operativer Zuständigkeit.
Nachvollziehbarer Vergleich von Anforderungen, Konzeption und prüfbarem Implementierungsstand.
Ein Pilot setzt abgestimmten Scope, Version, Umgebung, Verantwortlichkeiten und Sicherheitsprüfung voraus.
06 / SECURITY & REGULATION
Normativer Kontext und Verantwortlichkeit
TI-Messenger Pro unterliegt veröffentlichten Produkt- und Anbieteranforderungen der gematik. Die jeweils anwendbaren PTV-, ATV- und Spezifikationsstände werden je Vorhaben überprüft.
Clientseitige Ende-zu-Ende-Verschlüsselung, serverseitige Nachrichtenfunktionen, Verzeichniszugriff, Token-Ausstellung und Betriebspflichten dürfen nicht als identische Leistung eines einzelnen Homeservers dargestellt werden.
Weder diese Seite noch verlinkte gematik-Dokumente bestätigen eine Zulassung, Zertifizierung, Beauftragung oder produktive Bereitstellung eines ITL Fachdienstes.
Offizielle Normreferenzen (keine ITL-Produktnachweise)TI-Messenger_26_2 · 29.09.2026 ↗FD Pro PTV 1.1.0-0 · Anbieter Pro ATV 1.2.0-0gemSpec_TI-M_Pro 1.2.0 · gemSpec_TI-M_Basis 1.3.0
07 / FAQ
Fragen und Antworten
Klare Antworten ohne pauschale Zulassungs- oder Kompatibilitätszusage.
Ist die Technologie bereits gematik-zugelassen?
Nein. Die Darstellung beschreibt eine Entwicklungslinie; eine Zulassung wird nicht behauptet.
Ist die Rust/Matrix Foundation ein kompletter TI-M Fachdienst Pro?
Nein. Ein vollständiger Fachdienst umfasst weitere normative und betriebliche Verpflichtungen.
Ist die Lösung mit jedem Matrix Client interoperabel?
Das wird nicht allgemein zugesagt. Profile, Versionen und Tests werden je Evaluation festgelegt.
Wie wird mit Föderation und VZD-FHIR umgegangen?
Als gesonderte normative bzw. externe Integrationsgrenzen, die je Projekt zu klären und nachzuweisen sind.
Wird Ende-zu-Ende-Verschlüsselung serverseitig bereitgestellt?
Clientseitige Kryptografie und serverseitige Aufgaben sind getrennt zu betrachten.
Gibt es einen Testzugang oder SLA?
Ein allgemeiner Live-Dienst, Zugang oder SLA wird über diese Seite nicht angeboten.
Was wird für einen Pilot benötigt?
Zielsystem, Version, gewünschte Funktionen, Sicherheits- und Betreibergrenzen sowie einen begrenzten Prüfumfang.
Welche Daten dürfen wir senden?
Über das Kontaktformular keine Patienten-, Gesundheits- oder anderen besonderen Kategorien personenbezogener Daten.
08 / LET'S TALK
Integration gemeinsam bewerten
Sie prüfen eine mögliche TI-Messenger-Integration? Lassen Sie uns Zielsystem, Schnittstellen, Zuständigkeiten, Sicherheitsgrenzen und einen begrenzten Evaluierungsumfang gemeinsam einordnen.
Bitte keine Patienten-, Gesundheits- oder sonstigen besonders schutzwürdigen personenbezogenen Daten über das Kontaktformular oder unverschlüsselte E-Mail senden.
Technisches Gespräch anfragen Produktstatus & Grenzen ansehen
Die Technologiegrundlage ist kein vollständiger, zugelassener Fachdienst.