Logische Placement-Grenze
Workflow-Identität bleibt von der momentanen physischen Verteilung entkoppelt. Die Website beschreibt diese Produktgrenze ohne interne Ausführungsdetails.
TI-Flow Engineering Foundation
BPMN Workflow Runtime für TI-Flow-orientierte Fachdienste.
MEMM verbindet eine verteilte BPMN-Ausführung mit stabiler logischer Placement-Grenze, lokalisierter Ausführung, expliziter Ownership und recoverable Betriebssemantik. Draft_TI-Flow_26_2 dient dabei als externe Entwicklungsreferenz und stellt keinen Konformitäts- oder Zulassungsnachweis dar.
Implemented workflow foundation
Workflow→logische Placement-Grenze→verantwortliche Ausführung
Logicalplacement boundary
Localexecution consistency
Fail-closedownership
Technischer Stand: implementierte BPMN Distributed Execution Foundation. Die öffentliche Darstellung bleibt auf Produktgrenzen, Verantwortlichkeiten und technische Effekte begrenzt.
Runtime Foundation
Verteilte BPMN-Ausführung mit klaren logischen Grenzen.
Die implementierte Foundation wird öffentlich auf Architektur-Ebene beschrieben: stabile logische Grenzen, lokale Konsistenz, explizite verteilte Sichten und kontrollierte Ownership-Wechsel.
Lokalisierte Ausführung
Zustandsänderungen bleiben an eine benannte lokale Konsistenz- und Ownership-Grenze gebunden.
Explizite distributed reads
Clusterweite Sichten sind bewusst verteilte Read-Operationen und keine versteckte globale Write-Semantik.
Fail-closed Ownership
Unklarer oder widersprüchlicher Routing-Zustand wird nicht über einen stillen globalen Default-Pfad kaschiert.
Recoverable Ownership Transfer
Ownership-Wechsel werden als kontrollierte und überprüfbare Betriebsoperation behandelt.
Keine fachliche Datentyp-Grenze
Die technische Placement-Grenze definiert nicht automatisch medizinische, buchhalterische, Datenschutz- oder Mandantengrenzen.
BPMN 2.0 · TI 2.0 Kontext
TI-Flow in BPMN-Collaboration-Modellen – mit MEMM Headless als eigener Produktgrenze.
Die Modelle verbinden öffentlich dokumentierten TI-Flow-Kontext mit den öffentlich beschriebenen MEMM-Produktgrenzen. Sie sind keine offiziellen gematik-Prozessdiagramme, kein Nachweis einer vollständigen End-to-End-Implementierung und keine Aussage, dass der MEMM Headless Client Bestandteil eines normativen TI-Flow-Prozesses ist.
BPMN 2.0 Collaboration
Headless + TI-Flow: eine Fachaktion, zwei kontrollierte Produktgrenzen.
Die Fachanwendung arbeitet mit stabilen Host-Verträgen. Der Headless Client kapselt Kommunikationssemantik; die TI-Flow Runtime ordnet den Workflow-Kontext ein. Externe TI-, TI-M-, Matrix-, TI-Flow- und ZETA-Kontexte bleiben außerhalb der Host-Fachlogik.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
Scope: Architekturmodell zur Produktgrenze. Es behauptet weder eine normative Kopplung von Headless und TI-Flow noch eine vollständige TI-Flow-, HCC-, ZETA- oder Zulassungsabdeckung.
Public TI-Flow ContextE-Rezept:
E-Rezept: $create und $activate als zwei getrennte BPMN-Interaktionen.
Die Modelle verwenden die öffentlich dokumentierten TI-Flow-Operationen POST /Task/$create und POST /Task/<id>/$activate. Die MEMM-Grenze bleibt eine illustrative Integrationsabbildung; der externe TI-Flow-Fachdienst ist der normative Referenzkontext.
01
BPMN 2.0 XML ↓$create: Task anlegen und Task-ID zurückgeben.
Ein eigener Request/Response-Pfad führt vom Verordnungskontext über die MEMM-Integrationsgrenze zum Fachdienst und mit der Task-ID zurück zum Host-Vertrag.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
02
BPMN 2.0 XML ↓$activate: vorhandenen Task mit signiertem Kontext aktivieren.
Der zweite Request/Response-Pfad beginnt mit Task-ID und signierten Daten, überträgt den Aktivierungskontext und gibt Task beziehungsweise OperationOutcome zurück.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
BPMN-Semantik: $create und $activate sind absichtlich als eigenständige Interaktionen modelliert. Die Task-ID aus dem ersten Pfad ist Eingangskontext des zweiten; das Modell behauptet keinen automatischen Übergang im Fachdienst. Der MEMM Headless Client bleibt eine separate Kommunikationsgrenze.
MEMM Architecture Model
Regulatory Change Containment über Headless und TI-Flow.
Ein externes Delta wird zunächst klassifiziert und nur gegen die tatsächlich betroffenen Produktgrenzen geprüft. Solange der öffentliche Host-Vertrag unverändert bleibt, wird die Anpassung innerhalb der kontrollierten MEMM-Grenze verarbeitet; erst ein tatsächlicher Contract Change erzeugt expliziten Host-Impact.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
Prinzip: Nicht weniger Regulierung, sondern eine begrenzte technische Änderungsfläche. Keine Aussage über weniger Zulassungsschritte, konkrete Zeit- oder Kostenersparnis.
Execution Model
Lokale Konsistenz für Zustandsänderungen. Explizite Semantik für verteilte Sichten.
Write / Execution
- Zustandsänderungen bleiben an eine gültige lokale Ownership-Grenze gebunden
- unklare Ownership wird explizit abgelehnt
- fachlicher und sicherheitsrelevanter Kontext bleibt Teil der Ausführungsgrenze
- öffentliche Aussagen bleiben auf Ausführungs- und Verantwortungssemantik begrenzt
Read / Operate
- clusterweite Sichten werden als explizit verteilte Reads behandelt
- unvollständige Quellen werden nicht still als vollständiges Ergebnis dargestellt
- öffentliche Aussagen bleiben auf Ergebnis- und Verantwortungssemantik begrenzt
- keine Ableitung einer globalen Write-Transaktion aus der Read-Sicht
EinordnungDiese Seite beschreibt das öffentliche Konsistenz- und Ownership-Prinzip, nicht die konkrete Implementierung des verteilten Runtimes.
Migration Safety
Recoverable Ownership-Transfer statt impliziter Infrastrukturumschaltung.
Ein Ownership-Wechsel ist eine kontrollierte, überprüfbare Betriebsoperation. Die öffentliche Beschreibung bleibt auf Verantwortungs-, Konsistenz- und Recovery-Ebene.
Expliziter Transfer
Ownership ändert sich nicht als stiller Nebeneffekt einer Infrastrukturänderung.
Überprüfbarer Zustand
Ein unvollständiger oder widersprüchlicher Transfer wird nicht als erfolgreicher Wechsel behandelt.
Recovery-Grenze
Unterbrechung bleibt ein kontrollierter Recovery-Zustand und wird nicht als erfolgreicher Ownership-Wechsel dargestellt.
Draft_TI-Flow_26_2
Die Runtime ist eine Grundlage – der offizielle TI-Flow-Scope ist breiter.
Die gematik-Vorabveröffentlichung vom 30.06.2026 umfasst TI-Flow-Fachdienst, HCC-Cluster, Inbetriebnahme-Konzept, Produkt-/Anbietersteckbriefe und mehrere FHIR Implementation Guides. Diese Ebenen werden nicht automatisch aus der BPMN/VBucket Runtime abgeleitet.
Externer TI-Flow-VertragFHIR APIs · Profile · fachliche OperationenDraft_TI-Flow_26_2 Entwicklungsreferenz
Security / Service ContextHCC · ZETA · Identität · Signatur · Betriebseparat source-bound und deploymentbezogen zu bestätigen
MEMM IntegrationsgrenzeProfile / Validation / Authorization / Workflow Translationprojektspezifische Abbildung auf Runtime-Verträge
Implementierte FoundationBPMN Workflow Runtime · Distributed Execution Foundationlogical placement · local consistency · recoverable ownership transfer
Was diese Seite bereits behauptet
- implementierte verteilte BPMN Workflow Foundation
- stabile logische Placement- und Ownership-Grenze
- lokalisierte Zustandsänderungen
- explizite verteilte Read- und Recovery-Semantik
Was daraus nicht automatisch folgt
- vollständige Umsetzung des TI-Flow-Fachdienstes
- HCC- oder ZETA-Konformität
- vollständige FHIR-IG-/QES-/Fachprofil-Abdeckung
- Zulassung, Providerfreigabe, unterbrechungsfreier Betrieb oder DSGVO-Garantie
Offizielle gematik Vorabveröffentlichung Draft_TI-Flow_26_2 öffnen →
Fail-closed Runtime
Unklare Ownership ist ein Fehlerzustand – kein Anlass für stilles Fallback.
Die technische Foundation verlangt eine eindeutig bestimmbare Ausführungsgrenze. Die öffentliche Beschreibung bleibt bei diesem technischen Effekt.
Routing State
Widersprüchlicher oder unvollständiger Routing-Zustand wird nicht als normaler Ausführungspfad behandelt.
Ownership
Execution benötigt eine gültige benannte Ownership-Grenze.
Context
Der notwendige fachliche und sicherheitsrelevante Kontext bleibt an die Ausführungsentscheidung gebunden.
ZETA Boundary
ZETA bleibt externer TI-2.0-/TI-Flow-Kontext; vollständige ZETA-Validierung oder Konformität wird nicht behauptet.
Synthetische Designstudie
Workflow- und TI-Flow-Betrieb als gemeinsame technische Sicht.
Die Darstellung ist ein UI-Konzept mit synthetischen Daten. Sie zeigt keine reale TI-Flow-Instanz, keine gematik-Prüfung und keine gemessenen Betriebswerte.
Concept UI · synthetische Daten
Workflow / Runtime View
Beispielhafte Perspektive auf Prozesszustand, technische Ausführung und Betriebsgrenzen.
TI-Flow nicht mit einem Marketingclaim beginnen. Mit dem technischen Scope.
Wir können FHIR-/Service-Vertrag, Security-/HCC-Kontext, Workflow Translation und die bereits implementierte Runtime Foundation getrennt gegen Ihren Zielkontext einordnen.
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.