Integrationsgrenze
API-, SDK-, Profil- und Adapterverträge für ausdrücklich benannte Zielsysteme und Versionen.
Plattformarchitektur
Offene Integrationsgrenzen. Projektbezogen definierte Laufzeitverantwortung.
MEMM strukturiert technische Verantwortung in getrennte Ebenen. Die Darstellung beschreibt Architektur und Entwicklungsrichtung; sie ist keine pauschale Zusage für Produktivbetrieb, Plattformabdeckung oder allgemeine Spezifikationskonformität.
Runtime-Grenze
Technische Verarbeitungs-, Zustands- und Fehlerverträge mit benannter Zuständigkeit.
Zugriff & Policy
Getrennte Identitäts-, Policy- und Ausführungsentscheidungen innerhalb des vereinbarten Scopes.
Release-Referenzen
Zuordnung von Quellstand, Konfiguration, Prüfumgebung und Ergebnis für eine konkrete Version.
Integration Contracts
Stabile Integrationsverträge statt Abhängigkeit von Protokollinternas.
Die Architektur orientiert sich an versionierten Produktgrenzen. Anwendungen und Partner sollen gegen benannte Schnittstellen, Datenformen und Fehlersemantiken integrieren – nicht gegen interne Details externer Engines oder wechselnder Spezifikationsentwürfe.
4Vertragsebenen
C1API / SDKAufruf- und Lifecycle-Grenzen
C2Service / WorkflowÜbergaben und Zustandsgrenzen
C3Daten / ProfileVersionierte Datenformen
C4Fehler / LifecycleAblehnung, Retry und Migration
Vier gleichwertige Kategorien — keine Gewichtung, kein Reifegrad und keine Fortschrittsmessung.
Fachanwendung / OEM
Produktlogik
kundenseitiger Kontext
Versionierte Verträge
API / SDK
Service / Workflow
Daten / Profile
Fehler / Lifecycle
MEMM Produktgrenze
Rust-basierter Kern
interne Implementierung bleibt von der öffentlichen Vertragsgrenze getrennt
Externe Kontexte
TI-M / FHIR® / Dienste
versions- und projektbezogen
API- und SDK-Verträge
Öffentliche Aufruf-, Daten- und Lifecycle-Grenzen sollen versionsbezogen benannt werden. Unterstützte Bindings und Zielplattformen bleiben Bestandteil des jeweiligen Releasescopes.
Service- und Workflow-Verträge
Identität, Tenancy, Retry-Verhalten und Übergabepunkte sollen an der vereinbarten Systemgrenze nachvollziehbar bleiben.
Daten- und Profilverträge
Interne Produktzustände sollen von externen Matrix-, FHIR®- und Spezifikationstypen entkoppelt bleiben; konkrete Profile werden separat versioniert.
Fehler- und Lifecycle-Semantik
Ablehnung, Wiederholung, Bedienereingriff und Migration sollen explizite Zustände sein. Das ist ein Architekturziel, keine Zusage für jede aktuelle Version.
TI 2.0 Kontrollgrenzen
Externe TI-Dienste und interne Produktverantwortung bewusst trennen.
Hardwareunabhängiger TI-Zugang, digitale Identitäten und Zero Trust verändern die Integrationslandschaft. MEMM behandelt diese Themen als benannte Außen- und Kontrollgrenzen statt sie stillschweigend in einen Produktkern zu vermischen.
TI-Zugang bleibt extern
TI-Gateway und zugelassene Zugangsdienste liegen außerhalb der MEMM-Produktgrenze. MEMM wird nicht als Konnektor- oder TI-Gateway-Ersatz beschrieben.
Identity Evidence wird versioniert
Der aktuelle Entwicklungsstand führt externe Nachweise für EUDI Wallet, Health ID und eID-LE über eine versionierte Adaptergrenze in kanonische Identitäts- und Attributkontexte. Verifikation und Anwendungsautorisierung bleiben getrennt.
Zero Trust bleibt eine Architekturreferenz
Explizite Identitäts-, Attribut-, Policy- und Ausführungsentscheidungen unterstützen eine Zero-Trust-orientierte Trennung von Vertrauen und Ausführung. Daraus wird weder ZETA-Integration noch allgemeine OIDC-/Federation-Unterstützung abgeleitet.
Architektur- und Qualitätsziele
Verantwortung soll eindeutig und prüfbar bleiben.
Die folgenden Punkte sind Entwicklungs- und Prüfkriterien. Ob sie für eine konkrete Version erfüllt sind, ergibt sich ausschließlich aus dem zugehörigen Release- und Prüfnachweis.
Ereignisorientierte Zustandsänderungen
Änderungen sollen über benannte Ereignis- und Abonnementpfade verteilt werden. Extern notwendiges Polling bleibt eine ausdrücklich dokumentierte Grenze.
Explizite Ablehnung
Fehlende Konfiguration, unbekannte Versionen oder unzureichende Berechtigungen sollen zu typisierten Ablehnungen statt stillen Fallbacks führen.
Ein kanonischer Owner
Für Zustand, Workflow, Identität, Routing und Prüfreferenz soll jeweils eine benannte maßgebliche Zuständigkeit bestehen.
Begrenzte Ressourcen
Backpressure, Limits und kontrollierte Wiederholungen sollen unbounded processing und unklare Nebenwirkungen vermeiden.
Versioned Extensibility
Ändernde Spezifikationen, stabile Produktgrenzen.
Externe Profile, Entwürfe und Integrationsanforderungen können sich ändern. Die Architektur soll solche Änderungen über versionierte Adapter und Verträge einordnen, ohne daraus automatisch eine neue Zusage für den Produktkern abzuleiten.
Veränderliche Außenwelt
Profile · Drafts · Provider-APIs · Zielsysteme
können eigene Versionen und Lebenszyklen haben
Stabile Produktgrenze
Domänenzustand · Fehlersemantik · Release-Identität
Änderungen werden kontrolliert und releasebezogen bewertet
Abgrenzung: Die Trennung von Adapter- und Produktgrenze ist ein Architekturprinzip. Sie bedeutet nicht, dass ein bestimmtes externes Profil, ein Draft oder eine Plattform in einer konkreten MEMM-Version bereits unterstützt wird.
Shared Responsibility
Verantwortungsgrenzen werden vor der Integration ausdrücklich geklärt.
Die folgende Aufteilung ist ein Orientierungsmodell, keine allgemeine RACI-Zusage. Tatsächliche Rollen hängen von Deployment, Vertrag, regulatorischer Rolle, Zielsystem und konkretem Release ab.
Fachanwendung & fachlicher Kontext
- Produkt- und Prozesskontext
- organisationsspezifische Fachlogik
- lokale Betriebs- und Integrationsentscheidungen
Vereinbarte Produktgrenze
- versionierte Schnittstellen und Artefakte
- benannte Runtime- und Fehlergrenzen
- releasebezogene technische Referenzen
Externe Dienste & Infrastruktur
- providerseitige Infrastruktur und Betriebsgrenzen
- externe Identitäts-, Trust- und Kommunikationsdienste
- Vorgaben und Entscheidungen externer Stellen
Produktbeschreibung ersetzt keine vertragliche Verantwortungsmatrix. Für Pilot- oder Produktionsszenarien müssen Rollen, Eskalationswege, Nachweise und Betriebsgrenzen gesondert festgelegt werden.
Mögliche Integrationsmodelle
Von eingebettet bis betrieben – erst nach Scope-Bestätigung.
| Modell | Möglicher Einsatz | Vor einer Zusage zu klären |
|---|---|---|
| In-Process / Embedded | OEM-Integration mit enger Produktgrenze | Zielplattform, Binding, Lifecycle, Update- und Supportmodell |
| Private Service | Organisationseigener Plattformdienst | API, Identität, Netzwerk, Betrieb, Monitoring und Verantwortlichkeiten |
| Managed / Operated | Projekt mit benannter Laufzeitverantwortung | Verfügbarkeit, Support, Security Response und Nachweisumfang im Vertrag |
Vertiefung
Technische Architekturthemen im Detail.
Öffentliche Einordnungen zu Integrationsverträgen, externen Spezifikationsänderungen und Verantwortungsgrenzen – ohne interne Implementierungsartefakte.
TI 2.0
TI 2.0 Architektur
Einordnung von hardwareunabhängigem TI-Zugang, digitalen Identitäten und Zero Trust in die MEMM-Produktgrenze – ohne TI-Gateway-, ZETA- oder allgemeine TI-2.0-Konformitätsaussage.
Wissen öffnen →
Integration Contracts
Versionierte API-Verträge
Wie Versions-, Capability-, Fehler- und Lifecycle-Verträge explizit gemacht werden können, damit Integrationen nicht auf stillen Fallbacks oder impliziten Annahmen beruhen.
Wissen öffnen →
Versioned Extensibility
Specification Change Control
Architekturprinzip für wechselnde externe Spezifikationen: Änderungen an Drafts und Profilen über versionierte Adaptergrenzen einordnen, ohne stabile Domänenlogik automatisch umzubauen.
Wissen ö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.