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.

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 Draft_TI-Messenger_26_2-Konzept zum interoperablen Austausch strukturierter Daten wird als Entwicklungsreferenz berücksichtigt.

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.

VBucket / ShardManager Runtime

Begrenzter VBucket-Raum, stabile Workflow-Zuordnung, shard-lokale Queues und Transaktionen, explizite Scatter-Gather-Reads, fail-closed Ownership sowie recoverable Migration. Draft_TI-Flow_26_2 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 Draft_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 →