Integrationsgrenze
API-, SDK-, Profil- und Adapterverträge für ausdrücklich benannte Zielsysteme und Versionen.
Plattformarchitektur
Neue TI-Vorgaben treffen bestehende Anwendungen. Wer hält die Integration überschaubar?
Wenn Profile, Protokolle oder Betriebsgrenzen wechseln, muss die Verantwortung zwischen Host und Komponenten geklärt bleiben. 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.
Änderungen gezielt zuordnen.
Fachanwendung / HostIhr Produkt und Ihre Abläufe
Versionierter Integrationsvertrag
MEMMAdapter und Verarbeitung
Benannte externe Verträge
Externer KontextDienste, Profile und Versionen
Externe Änderungen werden an der Integrationsgrenze bewertet. Ob der Host-Vertrag unverändert bleiben kann, hängt von der Bedeutung der Änderung ab.
Einen Profilwechsel nachvollziehenPlattformgrenzen
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.
Regulatory Change Containment
Ein Profilwechsel, zwei mögliche Folgen für den Host-Vertrag.
Das Ziel ist nicht, Zulassung, Qualifizierung oder regulatorische Prüfung zu umgehen. Das Ziel ist, die technische Änderungsfläche zu begrenzen: externe Deltas werden dort verarbeitet, wo sie entstehen, und Host-Verträge bleiben stabil, solange die definierte Produktgrenze nicht überschritten wird.
Ein Adapter-Update beantwortet die Host-Versionsfrage noch nicht.
Die geprüften TI-Common-Pakete unterscheiden sich am Basiselement Organization.extension. Erkunden Sie, was dieses externe Delta an einer vereinbarten Host-Grenze bedeuten kann.
TI-Common-Paket 1.3.0
Organization.extensionKeine eigene mustSupport-Kennzeichnung an diesem Basiselement.
TI-Common-Paket 1.3.1
Organization.extensionDas Basiselement ist mit mustSupport = true gekennzeichnet.
mustSupport beschreibt die geforderte Unterstützung nach dem jeweiligen IG. Das Merkmal allein macht eine Extension nicht in jeder Ressource verpflichtend und setzt keine Mindestkardinalität.
Quellengrenze: Der ePA-FdV-PTV 3.1.3-3 nennt Common 1.3.0; die geprüften Pakete Basic 1.3.2 und MHD 1.1.3 hängen von 1.3.1 ab. Die Abweichung bleibt offen. Der Vergleich gibt keine Versionsersetzung frei.
Entscheidungsfrage: Kann der vereinbarte Host-Vertrag die für den konkreten Anwendungsfall benötigten Informationen und Fehlerzustände ausdrücken?
Gleiche Host-Version — wenn ihre Semantik den Anwendungsfall weiter abdeckt.
- Adapter
Profilauswahl, Validierung und Verarbeitungsunterstützung prüfen. Mapping und Tests dort anpassen, wo der belegte Profilunterschied sie betrifft.
- Host-Vertrag
Wenn vorhandenes Datenmodell und Fehlersemantik alle benötigten Informationen bereits abdecken, kann das externe Delta im Adapter bleiben. Diese Annahme am vereinbarten Vertrag prüfen.
- Release-Nachweise
Externe Profil- und Adapterversion festhalten. Relevante Erfolgs- und Ablehnungsfälle sowie das unveränderte Host-Verhalten erneut prüfen.
Ergebnis in diesem Modellfall: ein Adapter-Release mit bestehendem Host-Vertrag. Das mustSupport-Merkmal allein beweist weder Kompatibilität noch Inkompatibilität.
Neue Host-Vertragsversion — wenn sich die benötigte Bedeutung ändert.
- Adapter
Benötigt der Anwendungsfall ein neues Host-seitiges Attribut, eine Entscheidung oder einen Fehlerzustand, kann Mapping den fehlenden Vertrag nicht ersetzen. Information erhalten und die Behandlung ausdrücklich festlegen.
- Host-Vertrag
Den vereinbarten Daten- oder Verhaltensvertrag erweitern und als neue Version veröffentlichen. Migration und Kompatibilität für bestehende Hosts festlegen; Information weder still verwerfen noch ein altes Feld umdeuten.
- Release-Nachweise
Altes und neues Client-Verhalten prüfen, einschließlich ausdrücklicher Ablehnung oder Migration für vom Vertrag nicht unterstützte Kombinationen.
Ergebnis in diesem Modellfall: Adapter- und Host-Vertragsrelease werden abgestimmt. Die Versionsänderung folgt der tatsächlichen Semantikänderung, nicht jedem externen Paketupdate.
Dies sind zwei bedingte Integrationsbeispiele. Sie beschreiben weder eine neue gematik-API noch implementierte Unterstützung in einem bestimmten MEMM-Release.
Produktgrenze: MEMM verspricht weder weniger Regulierung noch weniger Zulassungsschritte. Der Architekturansatz zielt darauf, unnötige Cross-System-Änderungen zu vermeiden, soweit externe Deltas innerhalb des vereinbarten MEMM-Scopes gekapselt werden können. Spezifikationsänderungen vertiefen →
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.
Anforderungen im Zusammenhang
Was die Spezifikationen für diese Architektur bedeuten.
Ausgewählte Anforderungen mit fester Quellenversion. Ein Thema aufklappen, um Verantwortung, Schnittstelle oder Datengrenze nachzulesen.
Drei Rollen für den HCC-Dienst
Der TI-Flow-Fachdienst-Hersteller ist HCC-Workload-Hersteller: Er entwickelt, testet, dokumentiert und registriert das Workload-Release. Der Fachdienst-Anbieter ist HCC-Dienstanbieter: Er integriert den Dienst in seinen Mandantenkontext und verantwortet Betrieb, Monitoring und Support. Der HCC-Provider stellt Plattform und HSM-Cluster sowie den providerspezifischen Trust-Domain Build Service (TDBS) und den Trust-Domain Configuration & Attestation Service (TDCAS) bereit. Der übergreifende TI Verification & Build Service liegt in der Verantwortung der gematik; die providerspezifischen Build Services sind darin eingebunden. Die Rollen können organisatorisch verbunden sein; ihre Pflichten bleiben getrennt.
Systemprotokolle und Pseudonymisierung
Sensible Informationen werden vor dem Speichern eines Systemprotokolleintrags entfernt. Zulässige Zwecke sind anlassbezogene Fehleranalyse und -behebung sowie Security Monitoring. Fehleranalyse-Protokolle sind nach Fehlerbehebung unverzüglich, Security-Monitoring-Protokolle nach drei Monaten zu löschen. Für gematik-Logdaten wird key_pn_log im Klartext ausschließlich in der VAU verarbeitet und im Vier-Augen-Prinzip eingebracht; für diesen besonderen Schlüssel ist eine Speicherung im VAU-HSM nicht zwingend.
Betriebsverantwortung für den gesamten Dienst
HCC-Dienste unterstützen mehrere Instanzen auf verschiedenen Hosts, sodass Hostwechsel oder Neustarts den Service nicht unterbrechen. Der HCC-Dienst protokolliert Fehler- und Performancedaten genutzter Cloud-Services; der HCC-Dienstanbieter überwacht und steuert Kapazitäten und testet Änderungen des HCC-Stacks vor dem produktiven Einsatz. Der TI-Flow-Anbieter erfüllt zusätzlich seinen ATV und die dienstbezogenen Performance-Vorgaben. gemSpec_Perf 2.88.0 konkretisiert die Anbieterpflichten: A_29788 verlangt 99,99 % Verfügbarkeit zur Hauptzeit und 99,97 % zur Nebenzeit in den festgelegten Servicezeiten. A_29790 verlangt die betreffenden Medication-Übermittlungen innerhalb von zwölf Stunden, sofern technische Fehler im ePA-Aktensystem dies nicht verhindern; A_29791 verlangt Versand an das Push-Gateway innerhalb von 60 Minuten nach Ereignisgenerierung, sofern das Gateway erreichbar ist. Diese normativen Zielwerte müssen im konkreten Dienstbetrieb nachgewiesen werden. Ein lokales Readiness-Signal beschreibt nur einen Teil dieses Betriebsbilds.
Kryptografie nach dem zugehörigen Produktprofil
Für den TI-Flow-PTV ist gemSpec_Krypt 2.51.0 gebunden; der G-App-PTV-Entwurf nennt 2.49.1. Diese Referenzen werden pro Produkttyp geführt. Eine neuere allgemeine Kryptografie-Ausgabe ersetzt eine im Produktprofil gebundene Fassung nicht automatisch. Algorithmen, Zertifikatsprüfung, Schlüsselverwendung und Transport müssen im jeweiligen Rollen- und Versionskontext bewertet werden.
Redaktioneller Quellenabgleich: 17. Oktober 2026. Die Zuordnung erklärt Anforderungen; Implementierungsprüfung und Produktzulassung benötigen eigene Nachweise.