Capture context
Input, source, version and processing correlation are assigned to the agreed data flow.
Healthcare / FHIR®
Traceable processing for selected FHIR®-related data flows.
MEMM defines versioned profile, validation and processing boundaries for explicitly named use cases and structured content. Supported FHIR® versions, profiles, target systems and verification methods are documented per project; no general FHIR®, ePA or TI conformance is claimed.
Development context: the current engineering work considers the structured-data interoperability concept referenced in
Draft_TI-Messenger_26_2. This is not a statement of complete implementation or interoperability.Integration contract
Check scope
Only explicitly reviewed profiles, versions and rules are treated as supported; unknown combinations receive a defined rejection state.
Bound processing
Retries, effects and responsibility hand-offs stay inside the named integration boundary.
Trace change
Release, configuration and verification references can be associated with a concrete adapter or data-flow state.
Example integration fields
From document metadata to structured follow-up actions.
These are possible project fields, not a commitment to a particular statutory or technical procedure.
Document & metadata flows
Treat version, provenance, status and hand-off points of selected document processes along an agreed profile.
Structured content & follow-up
Connect versioned profile references and processing status to host-owned follow-up actions without moving clinical decisions into the integration layer.
Retention & access boundaries
Represent project-specific storage, access, restriction and deletion rules as explicit responsibility boundaries.
Versioned integration boundary
External profiles can change. The host integrates against a controlled contract.
The public architecture separates external FHIR® contexts, a named MEMM integration boundary and host-owned workflows. Supported profiles and versions remain explicitly release- and project-specific.
External contextsFHIR® versions · Profiles · Target systemschanging, project-specific external environment
MEMM integration boundaryScope · Validation · Mapping · Error semanticsversioned, explicit and rejectable
Host responsibilityHealthcare application · Workflow · Follow-upclinical and organization-specific decisions remain outside the integration layer
01Version first
A profile name alone does not define supported scope. Version, target system and verification reference belong to the integration agreement.
02Fail closed
Unknown or unreviewed combinations should not be treated as silently compatible; they retain a defined rejection state.
03Business logic stays with the host
MEMM can bound and trace structured hand-offs without taking over clinical evaluation or organization-specific domain decisions.
Scope boundary: this model describes an architecture principle. It does not expand any FHIR®, ePA, TI, profile or interoperability conformance statement.
Technical depth
Structured data, profile boundaries and specification change.
Public architecture briefs explain FHIR®-related flows and changing external profiles without turning them into blanket conformance claims.
Healthcare IntegrationFHIR® & structured dataHow FHIR®-related structured data, profile versions and validation boundaries are classified without making a general FHIR®, ePA or TI conformance statement.Open knowledge brief →Versioned ExtensibilitySpecification Change ControlUsing versioned adapters and anti-corruption boundaries so changes in external drafts and profiles do not silently become changes in stable domain logic.Open knowledge brief →Integration ContractsVersioned API contractsMaking API version, capabilities, data contracts, lifecycle and error semantics explicit so integrations do not depend on silent fallbacks.Open knowledge brief →
Concept UI · synthetic data
Profile & processing overview
Illustrative view of selected profiles, versions, states and open review points. No real customer or production environment.
Classification: Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA and gematik refer to external standards, infrastructures or integration contexts. This site does not claim certification, approval or commissioning by gematik or another authority. Supported profiles, versions and operational boundaries are confirmed in writing before use.
Regulatory boundary: this public page is a product and architecture overview. It does not define a medical intended purpose and does not replace interoperability testing, a data-protection impact assessment, conformity assessment or regulatory approval.