Start / Lösungen

Produktbereiche

Produktbausteine für Integrations- und Betriebsgrenzen.

MEMM richtet sich an Produkt- und Plattformteams, die einen konkreten Integrationsscope, nachvollziehbare Zuständigkeiten und versionierte Schnittstellen benötigen. Die Karten beschreiben Entwicklungsbereiche, keine pauschale Verfügbarkeit.

Integrationsscope auswählen

Wer verantwortet welchen Teil?

Ihr Host-ProduktNutzeroberfläche · Prozess · Produktdaten

Versionierten Integrationsvertrag festlegen

MEMM-Entwicklungsbereiche

Headless / OEM: Lokales SDK / FFI · Kommunikationslaufzeit
FHIR / Workflow: Profiladapter · interne BPMN-Ausführung
Zugriff / Policy: Identitätsnachweise · Anwendungsautorisierung

Gesonderte externe VerträgeTI-Dienste · Provider · Zugriff und Hosting

Release-Nachweise binden eine Aussage an Version und Umgebung.

Eine Karte der Entwicklungsbereiche. Schnittstellen, Dienstabhängigkeiten und Nachweise werden je Produkt und Deployment separat festgelegt.

In Entwicklung

Headless / OEM

Für die Bewertung eines Rust-basierten Headless-Kerns mit klar abgegrenzten API-, FFI- und Laufzeitgrenzen. Der gebundene R1001-Stand weist innerhalb des festen Messenger-Denominators 63/63 Domänen sowie 100% Breadth und 100% Core Foundation aus; der definierte 37-Operationen-Produktkatalog bleibt durchgängig an die Native-Binding-Grenze gebunden. Externe Freigaben und Provider-Interoperabilität bleiben separat.

Produktoperationen und Capability-Scope
Lifecycle-, Update- und Fehlerzustände
Native Bindings und Host-Ownership

Headless-Bereich öffnen →

FHIR®

In Entwicklung

FHIR®-nahe Datenflüsse

Für ausgewählte Profil-, Validierungs- und Verarbeitungsgrenzen strukturierter Inhalte und FHIR®-bezogener Szenarien. Das TI-Messenger_26_2-Konzept zum interoperablen Austausch strukturierter Daten ist eine externe Vergleichsreferenz (Delta noch zu prüfen).

Benannte Profile und Versionen
Definierte Ablehnungs- und Übergabepunkte
Keine allgemeine Konformitätsaussage

Healthcare-/FHIR®-Bereich öffnen →

In Entwicklung

Zugriff & Policy

Für ausdrücklich definierte Identitäts-, Attribut-, Policy- und Ausführungsgrenzen mit typisierten Ergebnissen. Der aktuelle Entwicklungsstand ergänzt eine versionierte Identity-Evidence-Grenze für EUDI Wallet, Health ID und eID-LE; Identitätsprüfung und Anwendungsautorisierung bleiben getrennt.

Getrennte Prüfpfade
Versionierte Identity-Evidence-Grenze
Keine allgemeine OIDC-/Federation-Zusage

Identity & Policy öffnen →

In Entwicklung

Release & Nachweise

Für die interne Zuordnung öffentlicher Aussagen und projektspezifischer Prüfergebnisse zu einer benannten Version und Umgebung.

Release- und Konfigurationsbezug
Review- und Ablaufdatum
Vertrauliche Detailnachweise außerhalb der Website

UI-Konzept öffnen →

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.

Workflow Runtime

TI-Flow Engineering Foundation als eigener technischer Scope.

Für Teams, die FHIR-/Fachdienstverträge von der darunterliegenden verteilten Workflow-Ausführung sauber trennen wollen.

Distributed BPMN Execution Foundation

Stabile logische Placement- und Ownership-Grenzen, lokalisierte Zustandsänderungen, explizite verteilte Read-Sichten und recoverable Ownership-Transfers. TI-Flow_26_3 wird als externer Referenzrahmen eingeordnet; HCC, ZETA, FHIR-Profile und Zulassung werden nicht aus der Runtime abgeleitet.

TI-Flow Foundation öffnen →

Einsatzkontext

Krankenkassen und Contact Center als eigener Integrationsscope.

Automatisierung, technische Identitäten sowie Identifikations-, Attribut- und Raumkonzepte werden dort als eigene Verantwortungs- und Schnittstellenfragen behandelt – nicht als pauschale Produktzusage.

Integrationsarchitektur für Krankenkassen & Contact Center

Eine eigene Landing Page bündelt Automatisierung, Identity/Attribute/Room-Kontext, Betriebsgrenzen und die vorsichtige Einordnung von TI-Messenger_26_2.

Einsatzkontext öffnen →

Eine Evaluierung beginnt mit einer klaren Frage.

Gemeinsam lassen sich Zielsystem, aktueller Produktstand, gewünschte Versionen, Betriebsgrenze, Prüfbedarf und Verantwortlichkeiten eingrenzen.

Technische Einordnung anfragen →

TI-Messenger_26_2 · Product Types

Die Produktfamilie ist keine einheitliche, austauschbare Implementierung.

Client, Headless, Fachdienst und Anbieterpflichten besitzen jeweils einen eigenen Spezifikationsscope.

Headless Clientmodul Pro

Eingebettete Client-Komponente; R1001-Zähler sind intern, keine normative Abdeckung.

PTV 1.0.0-0 ↗

TI-M Client Pro

Eigenständiger professioneller Client-Produkttyp, getrennt von Headless.

PTV 1.1.0-0 ↗

TI-M Client ePA

TI-Messenger-Client für Versicherte mit eigener Authentisierung, /fdv/search und Fragebogenpflichten; getrennt vom Frontend der elektronischen Patientenakte.

PTV 1.2.0-0 ↗

TI-M Fachdienst Pro

Serverseitiger Fachdienst-Produkttyp, nicht automatisch Bestandteil von MEMM Headless.

PTV 1.1.0-0 ↗

Der TI-M Fachdienst ePA hat einen eigenen PTV. Das ePA-Aktensystem und sein Versicherten-Frontend folgen gesonderten ePA-Spezifikationen. Anbieter-ATV und direkte Quellenlinks stehen unter Specification & Trust.