Interfaces and ownership are defined, documented and versioned for a specific integration scope.
TI-MESSENGER PRO / ENGINEERING PREVIEW
Matrix-based technology foundation for a TI-M Fachdienst Pro.
ITL is developing a specialized Rust-based Matrix technology foundation for server-side communication capabilities in healthcare. The focus is on explicit interfaces, traceable states and clearly assigned integration boundaries.
In development · no production TI-M Fachdienst Pro service
The offering is in development. Implementation, supported profiles, interoperability, operations and any gematik approval are assessed separately for each version and scope.
- Rust / Matrix
- Versioned interfaces
- Explicit ownership
TI-M FD PRO · BOUNDARY VIEW
Four boundaries. One explicit scope.
01EXTERNAL ROLEApplication / OEMPVS, hospital systems, enterprise software
Client and business logic remain outside the foundation.
02PROJECT BOUNDARYIntegration contractMatrix interfaces · versioned responsibilities
Only a specific, reviewed API and deployment scope can define an integration.
03TECHNOLOGY CANDIDATEITL Rust / Matrix FoundationServer-side technology candidate
Design intent. No claim of complete implemented Matrix or TI-M server behavior.
04NORMATIVE + EXTERNALTI-M Fachdienst Pro contextRegistration · federation · VZD FHIR · provider
Normative requirements and external dependencies, not ITL approval or full service implementation.
PTV 1.1.0-0 · 29.09.2026Conceptual only
Simplified architecture model; no claim of production operation, complete interoperability or gematik approval.
01 / CONTEXT
Why a specialized foundation?
Cross-organization messaging is more than hosting a Matrix server. Identity, permissions, federation membership, directory services, data handling and operations must be assessed for the applicable TI-M product type.
OEM, EHR/PVS and hospital/KIS teams therefore face multiple integration and ownership boundaries. Our approach treats those boundaries as explicit technical contracts rather than hiding them in the host application.
Architecture principles
A Rust/Matrix foundation is intended to support evaluation of shard-aware storage and event processing. Performance and scaling results require separate evidence.
Design intent, implementation, testing, interoperability, regulatory approval and operational readiness are distinct review levels.
MEMM, healthcare applications and external TI-M services retain independently defined responsibilities.
03 / ARCHITECTURE
Four boundaries. One explicit scope.
The simplified model shows four areas: a healthcare application or OEM, versioned integration contracts, a candidate ITL Rust/Matrix Server Foundation, and the normative or external TI-M Fachdienst Pro context.
Registration Service, TI federation, VZD FHIR Directory, identity and operator responsibilities appear as separate requirements or external dependencies. The model does not establish complete implementation.
ITLRust / Matrix FoundationServer-side technology candidate
≠NOT A COMPLETE FD PRO
gematikTI-M Fachdienst ProProduct requirements / operator responsibility
Technological basis is not equivalent to a complete approved Fachdienst.
Simplified architecture model; no claim of production operation, complete interoperability or gematik approval.
Development, evidence and scope
We examine Matrix-oriented server capabilities, API boundaries and distributed data-flow design. Specific supported functionality will only be described once its release, test environment and evidence are reviewed.
01Matrix server functionsNot independently verified
02Registration / identityNot independently verified
03VZD FHIR / federationNot independently verified
04Provider / operationsNot independently verified
In development · no production TI-M Fachdienst Pro service
Registration, federation, VZD FHIR, security and operations are assessed separately. A published normative obligation is not evidence that ITL has implemented it.
Current public status: In development. No general claim of a complete TI-M Fachdienst Pro, gematik approval or production availability.
Status & Trust →Scoped evaluation instead of direct onboarding
Define integration and messaging interfaces within existing healthcare software.
Review server-side capabilities, federation dependencies and operational responsibility together.
Compare documented requirements, design and evidence-linked implementation status.
A pilot requires an agreed scope, version, environment, named owners and a security review.
06 / SECURITY & REGULATION
Regulatory context and responsibility
TI-Messenger Pro is governed by published gematik product-type and provider requirements. The applicable PTV, ATV and specification releases must be evaluated for each planned deployment.
Client-side end-to-end encryption, server-side messaging, directory access, token issuance and provider obligations must not be represented as a single homeserver capability.
Neither this page nor its gematik references demonstrate approval, certification, endorsement or production operation of an ITL Fachdienst.
Official normative references (not ITL product evidence)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
Questions & answers
Clear answers without blanket interoperability or approval claims.
Is the technology approved by gematik?
No approval is claimed. This page describes an engineering direction in development.
Is the Rust/Matrix Foundation a complete TI-M Fachdienst Pro?
No. A complete service entails further normative and operational responsibilities.
Does it interoperate with every Matrix client?
No general compatibility is promised; profiles, versions and tests must be agreed for each evaluation.
How are federation and VZD FHIR handled?
They are separate normative or external integration boundaries requiring project-specific verification.
Does the homeserver provide client-side end-to-end encryption?
Client cryptography and server duties must be assessed independently.
Is a live test service or SLA available?
This page does not offer a general live service, self-service access or SLA.
What is required for a pilot?
A target system, version, selected functionality, security and provider boundaries, and a bounded evaluation scope.
What information may we send?
Please do not submit patient data, health data or other special-category personal data through the contact form.
08 / LET'S TALK
Review an integration scenario
Exploring TI-Messenger integration? Let us review your target system, interfaces, responsibilities, security boundaries and a bounded technical evaluation scope.
Please do not send patient, health or special-category personal data using this contact form or unencrypted email.
Request a technical discussion Product status & boundaries
Technological basis is not equivalent to a complete approved Fachdienst.