Architekturwissen von BPMN Core Execution bis TI-Flow und FHIR®.

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28650 / A_28653 / A_28651 / A_28704 / A_28734 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28710 / A_28715 ↗
• gemSpec_TI-M_Basis 1.3.0 · A_25557 / A_25559 / A_25598 / A_25599 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28703 / A_28707 / A_28720 / A_28728 ↗

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.

• gemSpec_TI-M_Basis 1.3.0 · A_25395-03 / A_25641-02 ↗
• Matrix Client-Server API 1.17 · Voice over IP ↗
• gemSpec_TI-M_Pro 1.2.0 · A_28710 / A_28715 / A_28734 ↗

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.

• gemSpec_TI-M_Basis 1.3.0 · A_25299 / A_25573 ↗
• gemSpec_Krypt 2.50.0 · GS-A_4385 / A_18467 / A_18986 ↗
• RFC 8656 · §§ 3.1 / 12.6 / 21.1.6 ↗

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.

• Matrix 1.17 · Voice over IP / Party Identifiers ↗
• Matrix 1.17 · m.megolm.v1.aes-sha2 ↗
• Matrix 1.17 · Verification of the sending user ↗
• RFC 8827 · § 4.3 / § 6.5 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28683 ↗
• gemSpec_TI-M_Basis 1.3.0 · A_25528 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28679 / A_28681 / A_28682 / A_28849 / A_28850 ↗
• gemAnbT_TI-M_Pro ATV 1.2.0-0 · Dokument 1.0.0 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28725 / A_28733 · § 3.3.4 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_29024 / A_25546 / A_25547 / A_25553 / A_30013 / A_30014 ↗

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.

• gemSpec_TI-M_Pro 1.2.0 · A_28854 / A_28721 ↗

FHIR-Ressourcen werden mit dem Event-Typ de.gematik.fhir und fhir.json übertragen: eingebettet oder als JSON-/XML-Datei, mit Metadaten zu StructureDefinition, Ressourcentyp und FHIR-Version. Auch fhir.json verlangt einen Plaintext-Fallback unter de.gematik.text. Plaintext bezeichnet hier die Textrepräsentation im Event und hebt dessen E2EE-Schutz nicht auf. Proprietäre Events verwenden structuredData.json und einen Plaintext-Fallback unter de.gematik.text; auch unbekannte Events müssen vorhandene Text- und Datei-Fallbacks zugänglich machen. Ein Fachverfahren wird mit type und version im Block de.gematik.fachverfahren identifiziert. FHIR-VZD-Suche, TI-Flow-Operationen und dieser Nachrichtenvertrag sind getrennte Schnittstellen.

• gemSpec_TI-M_Basis 1.3.0 · A_28877 / A_28758 / A_28743 / A_28763 ↗
• fhir.json · a4c986a271faeaff1b27f4915bda3ae9b9e49487 ↗
• structuredData.json · d84b6363f1b71600a63a47361b5649b0230019c8 ↗

Client Capabilities werden unter de.gematik.client_capability.${device_id} im Nutzerprofil veröffentlicht. Bei einem vorhandenen Dehydrated Device müssen nach Logout des letzten Geräts dort Capabilities hinterlegt werden. Der Verarbeitungsstatus nutzt eigene Anfrage- und Antwortstrukturen: from_device, optional to_device und lifetime sowie einen Bezug auf die ursprüngliche event_id. Eine gültige, an das Gerät gerichtete Anfrage muss beantwortet werden. Die Antwort verknüpft success oder error über m.reference mit dem ursprünglichen Event; dieser Verarbeitungsstatus ist von Zustellung oder Lesebestätigung zu unterscheiden.

• gemSpec_TI-M_Basis 1.3.0 · A_28762 / A_29373 / A_28760 / A_28491 ↗
• clientCapabilities.json · 9e89c819080b18b5557667698d370b51d9f7da21 ↗
• statusRequest.json · d84b6363f1b71600a63a47361b5649b0230019c8 ↗
• statusResponse.json · d84b6363f1b71600a63a47361b5649b0230019c8 ↗

Der Client erfasst Metadaten gesendeter und empfangener Fachverfahren und übermittelt die Statistik per POST /report an den Fachdienst. Der Report beschreibt einen Messbeginn (start) und Zähler (Anzahl) je Fachverfahren und Version in den optionalen Listen sent und received. Das ist ein eigener Vertrag neben Matrix-Events und FHIR-VZD-Suche. Fehlgeschlagene Reports werden höchstens 14 Tage zwischengespeichert und nach konfigurierbarem Intervall oder bei der nächsten aktiven Verbindung erneut übertragen. Quellenhinweis: Die vollständige URL im Headless-PTV verweist auf Commit f8654d7…, während die Versionsspalte dcd2d280 nennt; der Link hier folgt ausdrücklich der vollständigen PTV-URL.

• gemSpec_TI-M_Basis 1.3.0 · A_28917 / A_28918 / A_28919 / A_28921 ↗
• Headless PTV 1.0.0-0 · Tabelle 2 / Table 2 ↗
• TIMessengerClientReport.yaml · f8654d73362d77ca65111845176877970dd14ecb ↗

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.

• Headless PTV 1.0.0-0 · Tabelle 2 / Table 2 ↗
• permissionConfig_V1.json · a67678018fb06bff1c14e7a1347631587dc57db5 ↗
• TiMessengerInformation.yaml · a67678018fb06bff1c14e7a1347631587dc57db5 ↗

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.

• gemSpec_TI-M_ePA 1.3.1 · A_25488 / A_25696 / A_25681-01 / A_26383-01 / A_26015-02 / A_25996-02 / A_25705 ↗
• gemSpec_TI-M_Pro 1.2.0 · § 3.3.4 Contact Center ↗

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.

• gemSpec_TI-M_ePA 1.3.1 · A_28528 ↗