Architekturwissen von BPMN Core Execution bis TI-Flow und FHIR®.
Der Wissen-Bereich zeigt die technische Plattformtiefe als zusammenhängende Architektur: BPMN-Ausführung, logische Placement- und Ownership-Grenzen, verteilte Sichten, kontrollierte Recovery sowie die versionierte TI-Flow/FHIR®-Integrationsgrenze – ergänzt um Headless, Identity/Policy, Security und Operations.
Vom BPMN-Prozess zur versionierten TI-Flow-Übergabe.
Die wichtigste Trennung: Workflow-Ausführung bleibt in einer stabilen internen Domäne. Externe Profile und Serviceversionen werden über eine kontrollierte Adaptergrenze angebunden.
Öffentliche Architekturübersicht. Implementierungsdetails und interne Betriebsparameter bleiben außerhalb des Website-Scope.
BPMN Core Execution als verteilte, aber klar begrenzte Runtime.
Fünf öffentliche Briefs erklären die vollständig umgesetzte BPMN/VBucket Foundation auf Produkt- und Architekturebene.
BPMN Core Execution
Öffentliche Architekturübersicht der vollständig umgesetzten BPMN Engineering Foundation auf Produkt- und Wirkungsebene.
Architecture Brief →BPMN RoutingVirtual-Bucket-Sharding
Warum eine virtuelle Placement-Schicht Workflow-Identität von der jeweils aktuellen physischen Verteilung entkoppelt.
Architecture Brief →Execution IsolationShard-lokale Ausführung
Warum ausführbare Arbeit und Zustandsänderung innerhalb einer klaren lokalen Ownership- und Konsistenzgrenze bleiben.
Architecture Brief →Distributed ReadsDistributed Reads & Routing
Warum clusterweite Sichten und zustandsändernde Commands unterschiedliche verteilte Semantik erhalten.
Architecture Brief →Migration SafetyWorkflow-Migration & Recovery
Warum ein Ownership-Wechsel als recoverable Betriebsoperation mit klarer Verantwortungs- und Recovery-Semantik behandelt wird.
Architecture Brief →Externe Profile ändern sich. Der Workflow-Kern soll stabil bleiben.
TI-Flow wird als eigene Integrationsdomäne erklärt: canonical process/task semantics, Flowtype- und Profilgenerationen, deterministisches FHIR®-Mapping und durable Zustellung nach dem Workflow-Commit.
TI-Flow Architektur
Architekturmodell für einen kanonischen TI-Flow-Prozess- und Task-Kontext, der von konkreten FHIR®-Profilgenerationen und externen Servicegrenzen getrennt bleibt.
Versionierte Einordnung →Versioned ProfilesTI-Flow/FHIR Versionierung
Wie explizite Flowtype- und Profilgenerationen, deterministisches Mapping und durable Übergabe regulatorische Änderungen von laufender Workflow-Semantik entkoppeln sollen.
Versionierte Einordnung →Die bisherigen Wissensbereiche bleiben vollständig erhalten.
Headless, TI 2.0, API-Verträge, Identity/Policy, Security, FHIR®, Evidence und Operations bleiben eigenständige Einstiegspunkte und werden durch die neuen Workflow-Tracks ergänzt.
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.
Einordnung lesen →Headless ClientTI-Messenger Headless Client
Technische Einordnung einer Headless-Client-Integration für PVS, KIS und Contact Center: lokale Produktgrenze, 63-Domain-Messenger-Denominator, Produktoperationskatalog, Native Bindings, Calls und Verantwortungen.
Einordnung lesen →Access & PolicyIdentität · Attribute · Policy
Warum Identitätsprüfung, Attributkontext, fachliche Policy und technische Ausführung in Health-IT-Architekturen nicht als ein einziger Allow/Denied-Schalter modelliert werden sollten.
Einordnung lesen →13 etablierte Technical Briefs – unverändert erreichbar.
Die neue Struktur ergänzt die Wissensbasis, ohne bestehende URLs oder Themen zu entfernen.
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.
Technische Einordnung →TI-Messenger Headless Client
Technische Einordnung einer Headless-Client-Integration für PVS, KIS und Contact Center: lokale Produktgrenze, 63-Domain-Messenger-Denominator, Produktoperationskatalog, Native Bindings, Calls und Verantwortungen.
Technische Einordnung →Lokale Headless-Architektur
Warum eine lokale SDK-/FFI-Grenze für Headless-Integration andere Verantwortungen erzeugt als ein zusätzlicher REST-, TCP- oder WebSocket-Steuerdienst.
Technische Einordnung →Rust & native Integration
Technische Einordnung des Rust-basierten MEMM-Kerns und einer lokalen FFI-Grenze für native Fachanwendungen – ohne pauschale Plattform- oder Performancezusage.
Technische Einordnung →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.
Technische Einordnung →Specification Change Control
Architekturprinzip für wechselnde externe Spezifikationen: Änderungen an Drafts und Profilen über versionierte Adaptergrenzen einordnen, ohne stabile Domänenlogik automatisch umzubauen.
Technische Einordnung →FHIR® & strukturierte Daten
Technische Einordnung von FHIR®-nahen strukturierten Daten, Profilversionen und Validierungsgrenzen im TI-Messenger-Kontext – ohne allgemeine Konformitätsaussage.
Technische Einordnung →Identität · Attribute · Policy
Warum Identitätsprüfung, Attributkontext, fachliche Policy und technische Ausführung in Health-IT-Architekturen nicht als ein einziger Allow/Denied-Schalter modelliert werden sollten.
Technische Einordnung →Kryptographische Isolation
Architekturprinzip für eine eingebettete Headless-Komponente: E2EE-Zustand, Host-Daten, secret-safe Diagnose, Zeroisierung und externe Transporte als getrennte Grenzen behandeln.
Technische Einordnung →Release Evidence
Wie ein Release-Nachweis Quellstand, Artefakte, Konfiguration, Kompatibilität und Prüfreferenzen zusammenführt, ohne interne Evidenzlogs öffentlich zu machen.
Technische Einordnung →Health & Readiness
Warum Liveness, Readiness, Degradation und fachliche Verfügbarkeit unterschiedliche Zustände sind und wie sie in einer Integrationsplattform getrennt betrachtet werden können.
Technische Einordnung →Fail-closed Integration
Warum unbekannte Versionen, ungültige Zustände und nicht unterstützte Capabilities in Integrationen als explizite Fehler behandelt werden sollten statt als stille Fallbacks.
Technische Einordnung →PVS/KIS Verantwortungsgrenzen
Orientierungsmodell für Verantwortungsgrenzen zwischen PVS/KIS, MEMM-Produktscope und externen Betreibern – vor Evaluation, Pilot und Produktionsvereinbarung.
Technische Einordnung →Öffentliche Produktarchitektur mit klarer Aussagegrenze.
- Produkt- und Integrationsgrenzen
- Architekturprinzipien und technische Effekte
- Versionierung und Fehlersemantik
- Verantwortungs- und Recovery-Effekte
- Implementierungsstatus wird nur für den benannten Scope verwendet
- TI-Flow/FHIR® bleibt versions- und profilgebunden
- externe Konformität und Zulassung werden getrennt bewertet
- keine Ausweitung aus Architekturtexten auf Produktfreigaben