Kontext erfassen
Eingang, Quelle, Version und Verarbeitungskorrelation werden für den vereinbarten Datenfluss eindeutig zugeordnet.
Healthcare / FHIR®
Nachvollziehbare Verarbeitung für ausgewählte FHIR®-nahe Datenflüsse.
MEMM beschreibt versionierte Profil-, Validierungs- und Verarbeitungsgrenzen für klar benannte Anwendungsfälle und strukturierte Inhalte. Unterstützte FHIR®-Versionen, Profile, Zielsysteme und Prüfverfahren werden projektspezifisch dokumentiert; eine allgemeine FHIR®-, ePA- oder TI-Konformität wird nicht behauptet.
Entwicklungsbezug: Die laufende Entwicklung berücksichtigt das in
Draft_TI-Messenger_26_2 aufgegriffene Konzept zum interoperablen Austausch strukturierter Daten. Diese Referenz ist keine Aussage über vollständige Umsetzung, Interoperabilität oder Konformität.Integrationsvertrag
Scope prüfen
Nur ausdrücklich freigegebene Profile, Versionen und Regeln werden als unterstützter Scope behandelt; unbekannte Kombinationen erhalten einen definierten Ablehnungszustand.
Verarbeitung begrenzen
Wiederholungen, Effekte und Verantwortungsübergaben werden innerhalb der benannten Integrationsgrenze modelliert.
Änderung zuordnen
Release-, Konfigurations- und Prüfreferenzen können einem konkreten Datenfluss oder Adapterstand zugeordnet werden.
Beispielhafte Integrationsfelder
Von Dokumentmetadaten bis zu strukturierten Folgeaktionen.
Die Beispiele beschreiben mögliche Projektfelder und keine bereits zugesicherte Unterstützung eines bestimmten gesetzlichen oder technischen Verfahrens.
Dokument- und Metadatenflüsse
Versionen, Herkunft, Status und Übergabepunkte ausgewählter Dokumentprozesse entlang eines vereinbarten Profils behandeln.
Strukturierte Inhalte & Folgeaktionen
Versionierte Profilreferenzen, Verarbeitungsstatus und Capability-Grenzen für strukturierte Inhalte mit fachlich verantworteten Folgeaktionen verbinden, ohne medizinische Entscheidungen in der Integrationsschicht zu behaupten.
Aufbewahrungs- und Zugriffsgrenzen
Projektbezogene Regeln für Speicherung, Zugriff, Einschränkung und Löschung als ausdrücklich benannte Verantwortungsgrenzen abbilden.
Versionierte Integrationsgrenze
Externe Profile können sich ändern. Der Host integriert gegen einen kontrollierten Vertrag.
Die öffentliche Architektur trennt externe FHIR®-Kontexte, eine benannte MEMM-Integrationsgrenze und hostseitige Fachprozesse. Unterstützte Profile und Versionen bleiben dabei ausdrücklich release- und projektspezifisch.
Externe KontexteFHIR®-Versionen · Profile · Zielsystemewechselnde, projektspezifische Außenwelt
MEMM IntegrationsgrenzeScope · Validation · Mapping · Error Semanticsversioniert, explizit und ablehnungsfähig
Host-VerantwortungFachanwendung · Workflow · Folgeaktionmedizinische und organisatorische Entscheidungen bleiben außerhalb der Integrationsschicht
01Version zuerst
Ein Profilname allein definiert keinen unterstützten Scope. Version, Zielsystem und Prüfreferenz gehören zur Integrationsvereinbarung.
02Fail closed
Unbekannte oder nicht freigegebene Kombinationen sollen nicht still als kompatibel behandelt werden, sondern einen definierten Ablehnungszustand behalten.
03Fachlogik bleibt beim Host
MEMM kann strukturierte Übergaben begrenzen und nachvollziehbar machen, ohne medizinische Bewertung oder organisationsspezifische Fachentscheidungen zu übernehmen.
Scope-Grenze: Das Boundary-Modell beschreibt ein Architekturprinzip. Es erweitert keine Aussage zu FHIR®-, ePA-, TI-, Profil- oder Interoperabilitätskonformität.
Technische Vertiefung
Strukturierte Daten, Profilgrenzen und Spezifikationsänderungen.
Öffentliche Architekturtexte ordnen FHIR®-nahe Datenflüsse und wechselnde externe Profile ein, ohne eine allgemeine Konformität zu behaupten.
Healthcare Integration
FHIR® & strukturierte Daten
Technische Einordnung von FHIR®-nahen strukturierten Daten, Profilversionen und Validierungsgrenzen im TI-Messenger-Kontext – ohne allgemeine Konformitätsaussage.
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 →
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 →
Concept UI · synthetische Daten
Profil- und Verarbeitungsübersicht
Beispielhafte Perspektive auf ausgewählte Profile, Versionen, Zustände und offene Prüfpunkte. Keine reale Kunden- oder Produktivumgebung.
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.
Regulatorische Grenze: Die öffentliche Darstellung ist ein Produkt- und Architekturüberblick. Sie legt keine medizinische Zweckbestimmung fest und ersetzt weder Interoperabilitätsprüfung noch Datenschutz-Folgenabschätzung, Konformitätsbewertung oder behördliche Zulassung.