Logical placement boundary
Workflow identity stays decoupled from the current physical distribution. The website describes this product boundary without internal execution detail.
TI-Flow Engineering Foundation
BPMN workflow runtime for TI-Flow-oriented services.
MEMM exposes an implemented distributed BPMN foundation with a stable logical placement boundary, localized execution, explicit ownership and recoverable operating semantics. The claim is deliberately limited to this engineering layer; it does not turn the runtime into a complete TI-Flow, HCC, ZETA or FHIR implementation.
External development reference:
Draft_TI-Flow_26_2 is used to classify surrounding service, HCC, ZETA and FHIR contexts. It is not treated as an approval or conformance statement.Runtime Foundation
Distributed BPMN execution with clear logical boundaries.
The implemented foundation is described publicly at architecture level: stable logical boundaries, local consistency, explicit distributed views and controlled ownership changes.
Localized execution
State changes remain bound to a named local consistency and ownership boundary.
Explicit distributed reads
Cluster-wide views are deliberate distributed read operations rather than hidden global write semantics.
Fail-closed ownership
Unclear or contradictory routing state is not hidden behind a silent global default path.
Recoverable ownership transfer
Ownership changes are controlled and verifiable operating actions.
Not a business data boundary
The technical placement boundary does not automatically define medical, accounting, privacy or tenant boundaries.
BPMN 2.0 · TI 2.0 context
TI-Flow in BPMN collaboration models — with MEMM Headless as a separate product boundary.
The models combine publicly documented TI-Flow context with the public MEMM product boundaries. They are not official gematik process diagrams, not proof of complete end-to-end implementation, and do not claim that MEMM Headless is a normative TI-Flow component.
BPMN 2.0 Collaboration
Headless + TI-Flow: one domain action, two controlled product boundaries.
The host application works through stable contracts. Headless encapsulates communication semantics; the TI-Flow runtime classifies workflow context. External TI, TI-M, Matrix, TI-Flow and ZETA contexts remain outside host business logic.
↔ Swipe horizontally to view the complete BPMN model.
Scope: architecture model for product boundaries. It does not claim a normative Headless/TI-Flow coupling or complete TI-Flow, HCC, ZETA or approval coverage.
Public TI-Flow ContextE-prescription:
E-prescription: $create and $activate as two separate BPMN interactions.
The models use the publicly documented TI-Flow operations POST /Task/$create and POST /Task/<id>/$activate. The MEMM boundary remains an illustrative integration mapping; the external TI-Flow service is the normative reference context.
01
Download BPMN 2.0 XML ↓$create: create a task and return the Task ID.
A dedicated request/response path runs from prescription context through the MEMM integration boundary to the service and returns the Task ID to the host contract.
↔ Swipe horizontally to view the complete BPMN model.
02
Download BPMN 2.0 XML ↓$activate: activate an existing task with signed context.
The second request/response path starts with the Task ID and signed data, carries the activation context and returns a Task or OperationOutcome.
↔ Swipe horizontally to view the complete BPMN model.
BPMN semantics: $create and $activate are deliberately modelled as independent interactions. The Task ID from the first path is input context for the second; the model does not imply an automatic service-side transition. MEMM Headless remains a separate communication boundary.
MEMM Architecture Model
Regulatory Change Containment across Headless and TI-Flow.
An external delta is first classified and evaluated only against the product boundaries it actually affects. While the public host contract remains unchanged, adaptation stays inside the controlled MEMM boundary; an actual contract change creates explicit host impact.
↔ Swipe horizontally to view the complete BPMN model.
Principle: not less regulation, but a bounded technical change surface. No claim of fewer approval steps or specific time/cost savings.
Execution model
Local consistency for state changes. Explicit semantics for distributed views.
Write / Execution
- state changes remain bound to a valid local ownership boundary
- unclear ownership is rejected explicitly
- business and security context stays part of the execution boundary
- public statements remain limited to execution and responsibility semantics
Read / Operate
- cluster-wide views are explicit distributed reads
- unavailable sources are not silently presented as a complete result
- public statements remain limited to outcome and responsibility semantics
- the read view does not imply a global write transaction
Migration safety
Recoverable ownership transfer instead of implicit infrastructure switching.
An ownership change is a controlled, verifiable operating action. The public description stays at responsibility, consistency and recovery level.
Explicit transfer
Ownership does not change as a silent side effect of infrastructure change.
Verifiable state
An incomplete or contradictory transfer is not treated as a successful change.
Recovery boundary
Interruption remains a controlled recovery state and is not presented as a successful ownership change.
Draft_TI-Flow_26_2
The runtime is a foundation. The external TI-Flow scope is broader.
The 30 June 2026 gematik pre-release covers service concepts, HCC clusters, onboarding, product/provider profiles and multiple FHIR Implementation Guides. Those layers are not automatically derived from a BPMN/VBucket runtime.
What this page does claim
- implemented distributed BPMN workflow foundation
- stable logical placement and ownership boundary
- localized state-changing execution
- explicit distributed read and recovery semantics
What does not automatically follow
- complete TI-Flow service implementation
- HCC or ZETA conformance
- complete FHIR IG, QES or domain-profile coverage
- approval, provider release, uninterrupted operation or GDPR guarantee
Fail-closed runtime
Unclear ownership is an error state, not a reason for silent fallback.
The foundation requires an unambiguous execution boundary. The public description stays with that technical effect.
Routing state
Contradictory or incomplete routing state is not treated as a normal execution path.
Ownership
Execution requires a valid named ownership boundary.
Context
Required business and security context stays bound to the execution decision.
ZETA boundary
ZETA remains external TI 2.0/TI-Flow context; complete ZETA validation or conformance is not claimed.
Synthetic design study
Workflow and TI-Flow operations in one technical view.
The view is synthetic. It does not show a real TI-Flow instance, gematik review or measured operating data.
Concept UI · synthetic data
Workflow / Runtime View
Illustrative perspective on process state, technical execution and operating boundaries.
Do not start TI-Flow with a marketing claim. Start with the technical scope.
Separate FHIR/service contract, security/HCC context, workflow translation and the implemented runtime foundation against your target 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.