Die MEMM Plattform beschreibt die Integration von TI-2.0-Anwendungen und gemeinsamen Diensten über versionierte Schnittstellen und klare Verantwortungsgrenzen. BPMN Core Execution und Matrix Middleware Module ergänzen das Architekturmodell um Prozessausführung und Kommunikation. Konkrete Integration, Nachweise und Produktstatus bleiben an den jeweiligen Projekt-Scope gebunden.
App des VersichertenTI-FlowTI-M Fachdienst ProTI-M Client ProHCL Headless ClientEinen der fünf Bausteine auswählenEine mobile Oberfläche für Versicherte – mit DiPag, TI-M, ePA und E-Rezept als dargestellten Integrationsfeldern.
HCSA entdeckenFachanwendungen sollen nicht jede Protokoll-, Identitäts-, Daten- oder Workflow-Änderung als eigene Produktarchitektur nachbauen. MEMM ordnet diese technischen Verantwortungen hinter expliziten Verträgen ein, damit Host-Systeme gegen eine klarere, versionierbare Grenze entwickeln können.
MEMM reduziert nicht die Regulierung. MEMM reduziert die Fläche, auf der regulatorische Änderungen technische Folgen haben.
Änderungen an TI-, TI-M-, Matrix- oder anderen externen Spezifikationen sollen hinter versionierten Integrationsgrenzen gekapselt werden, soweit sie innerhalb des vereinbarten MEMM-Scopes bleiben.
Architekturmodell — die Zahlen bezeichnen Ebenen und Flächen, keine Messwerte zu Effizienz, Reife, Zulassungsaufwand oder Änderungsreduktion.
Die Produktbereiche teilen dieselben Prinzipien: versionierte Verträge, klare Verantwortungsgrenzen und ein projektbezogener Scope. Technische Detailnachweise stehen auf den jeweiligen Produktseiten statt im Überblick.
Einbettbare Kommunikationslaufzeit für PVS, KIS, OEM und Plattformprodukte. Ein Rust-basierter Kern wird über klar abgegrenzte Host-, API- und Native-Verträge integriert; detaillierte R1001-Evidenz bleibt im technischen Produktpass.
Bereich ansehen →Versionierte Profil-, Validierungs- und Verarbeitungsgrenzen für strukturierte Inhalte und ausgewählte FHIR®-bezogene Szenarien. Fachanwendung und externer Profilkontext bleiben getrennte Verantwortungsbereiche.
Bereich ansehen →Identität, Attribute, Policy und Ausführung werden als getrennte Kontrollfragen behandelt. Externe Nachweise können an einer versionierten Identity-Evidence-Grenze eingeordnet werden, ohne Identitätsprüfung mit fachlicher Autorisierung gleichzusetzen.
Architektur ansehen →Versionierte Referenzen für Quellstand, Konfiguration und Prüfergebnisse. Umfang und Gültigkeit werden je Release abgegrenzt.
Status ansehen →Externe Spezifikationen und Infrastruktur sind Referenzkontext, nicht Bestandteil eines pauschalen Produktversprechens. Die technische Produktgrenze bleibt deshalb explizit.
MEMM ordnet Headless-, Identity-/Policy- und Daten-/Profilgrenzen auf der Anwendungsseite ein. TI-Gateway, ZETA und externe Identitätsdienste bleiben eigenständig. TI-Messenger_26_2 wird als veröffentlichte Vergleichsreferenz berücksichtigt, nicht als Konformitätszusage.
TI-2.0-Architektur einordnen →Die implementierte Foundation trennt stabile Workflow-Platzierung, shard-lokale Transaktionen und Failure Containment vom darüberliegenden FHIR-, HCC-, ZETA- und Betriebsvertrag. TI-Flow_26_3 ist die veröffentlichte externe Vergleichsreferenz (Delta offen).
TI-Flow Foundation ansehen →MEMM richtet sich an technische Organisationen, die Schnittstellen, Ownership und externe Voraussetzungen vor einer Integration bewusst festlegen.
Kommunikations- und Workflow-Funktionen in bestehende Fachanwendungen einordnen.
Versionen, Übergabepunkte und Betriebsverantwortung als explizite Verträge behandeln.
Automatisierungs- und Kommunikationsszenarien mit klarer technischer Scope-Grenze bewerten.
Einsatzkontext ansehen →Der Knowledge Layer übersetzt versionsgebundene Entwicklungsunterlagen in kurze, öffentlich prüfbare Architekturtexte – ohne interne Implementierungsdetails oder Roh-Evidence offenzulegen.
Zwei illustrierte Beispiele zeigen, was der Host übernimmt, was MEMM verarbeitet und wie eine Änderung eingeordnet wird. Jeder Schritt verwendet synthetische Daten.
Verfolgen Sie die Auswirkung auf Adapter und Host-Vertrag.
Beispiel P-021 · externe Profiländerung
Zuerst wird geklärt, was die neue Quelle ändert: Syntax, Validierung oder fachliche Bedeutung.
Adapter und Prüfung werden gemeinsam angepasst. Der Host-Vertrag wird gegen das neue Ergebnis geprüft.
Bei gleicher Semantik kann die Schnittstelle stabil bleiben. Ein geänderter Fachvertrag verlangt eine explizite Host-Versionierung.
Verfolgen Sie eine Nachricht von der Host-Oberfläche bis zur Client-Rückmeldung.
Beispiel H-104 · Rückrufwunsch
Der Host verantwortet Oberfläche und erlaubte Eingabe. Ein Entwurf stellt noch keine TI-M-Sitzung her.
Das Modul übernimmt den TI-M-Client-Kontext. Der Host wird weder zum zweiten Matrix-Client noch zur Messenger-Bridge.
Der Host zeigt den gemeldeten Zustand. Die Annahme durch den Client ist keine Zustell- oder Lesebestätigung.
Ein erstes technisches Gespräch kann Zielsystem, Entwicklungsstand, Verantwortungsgrenzen, Prüfbedarf und einen begrenzten Evaluierungsumfang klären.
Vom HCSA-Startbildschirm über einen beispielhaften Zugriffspfad bis zur Entscheidung und zum Nachweis. Alle Ergebnisse werden ausschließlich im Browser simuliert.
HCSA iPhone-Prototyp mit 12 Screens
Interaktives UI-Konzept · vollständig synthetische Daten · keine Verbindung zu ZETA Client/Guard, ePA, TI-M oder Identitätsdiensten.
Gestaltung auf Basis früherer HCSA-iPhone-Entwürfe. Freigaben, Gerätevertrauen und Audit-Zustände sind hier vollständig synthetisch und keine ZETA-Konformitätsaussage.