draftreadyErfolg ist ein bestätigter Statuswechsel
Der Versand eines Aufrufs aktiviert den Task noch nicht. Das Ergebnis folgt aus der erfolgreichen Antwort des Fachdienstes.
TI-Flow Engineering Foundation
Verteilte Healthcare-Prozesse: Was passiert bei Fehlern und Migration?
Unterbrochene Prozessschritte, Zustandswechsel und Wiederanlauf machen Ownership und Recovery zur Integrationsaufgabe. Die eigenständige Distributed BPMN Engine stellt eine verteilte Workflow-Runtime mit stabiler logischer Placement-Grenze, lokalisierter Ausführung, expliziter Ownership und kontrollierter Recovery-Semantik bereit. MEMM ist ein davon getrenntes Matrix-Enterprise-Middleware-Modul; eine Anbindung an TI-Flow-Schnittstellen ist projektspezifisch über gesonderte Integrationsadapter zu prüfen. TI-Flow_26_3 dient als externe Vergleichsreferenz, deren vollständiges Anforderungs- und Testdelta noch offen ist. Weder die BPMN Runtime noch MEMM werden dadurch zu einem zugelassenen TI-Flow-Fachdienst.
Architektur im Überblick
Laufzeit und Fachvertrag.
Extern festgelegt
TI-Flow-Fachvertrag
Operationen · FHIR-Profile · Task-Zustände
Je Projekt zuordnen und prüfen
Eigenständiges BPMN-Produkt
Distributed BPMN Engine
- Logische Zuordnung
- Ablauf und zuständige Ausführung eindeutig zuordnen.
- Lokale Ausführung
- Zustand innerhalb der benannten Ausführungsgrenze führen.
Nur mit geklärter Zuständigkeit ausführen.
Externe Spezifikationsreferenz: TI-Flow_26_3 (02.10.2026) · Die öffentliche Architekturerklärung verwendet diese feste Quellenversion. Implementierungstests, Interoperabilität und Produktzulassung benötigen eigene Nachweise. Historische Entwicklungsbasis: Draft_TI-Flow_26_2 (30.06.2026).
Vom Entwurf zur aktivierten Verordnung.
Das Primärsystem bereitet den Aufruf vor. Der externe TI-Flow-Fachdienst führt den Task-Status. Erst seine erfolgreiche Aktivierungsantwort bestätigt ready.
- $create
Den Entwurf anlegen
Der Fachdienst liefert Task-ID, PrescriptionID und AccessCode. Das Primärsystem bewahrt den geschützten Aufrufkontext auf.
Task: draft - Vorbereitung + QES
Das Dokument vorbereiten und signieren
Das Primärsystem nutzt die PrescriptionID im Verordnungsbundle. Der Leistungserbringer signiert über den Konnektor; signierter Inhalt bleibt unverändert.
Task: draft - $activate
Die Aktivierung anfordern
Task-ID, AccessCode und das unveränderte signierte Dokument gelangen über den definierten Aktivierungsaufruf zum Fachdienst.
lokal: Antwort ausstehend - Fachdienstantwort
Den neuen Status bestätigen
Der Fachdienst prüft den Aktivierungsaufruf. Eine erfolgreiche Antwort liefert den Task im Status ready.
Task: ready
Keine eindeutige Antwort? Ausgang offenhalten.
Ein Timeout belegt weder draft noch ready. Vor dem nächsten Schritt den Zustand über die jeweils erlaubte, operationsbezogene Schnittstelle klären. Den Aufruf nicht blind wiederholen.
Illustrative Lesehilfe zum externen TI-Flow-Kontext. Diese Seite führt keinen Verordnungsprozess aus. Beteiligte, Nachrichten und genaue Grenzen folgen in den BPMN-Modellen.
Weiter zu den detaillierten BPMN-Modellen →TI-Flow Core 2.0.0 · $create und $activate: $create ↗ · $activate ↗
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.
Logische Placement-Grenze
Workflow-Identität bleibt von der momentanen physischen Verteilung entkoppelt. Die Website beschreibt diese Produktgrenze ohne interne Ausführungsdetails.
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 illustrative BPMN-2.0-XML-Modelle (isExecutable=false), 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 im Status draft mit AccessCode anlegen.
Das Primärsystem übermittelt den workflowType. Bei Erfolg liefert der Fachdienst einen Task im Status draft mit Task-ID, PrescriptionID und AccessCode. Die Task-ID entspricht der PrescriptionID; der AccessCode bleibt im geschützten Integrationskontext.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
02
BPMN 2.0 XML ↓$activate: Task mit AccessCode und QES von draft nach ready aktivieren.
Das Primärsystem erstellt das profilkonforme Verordnungsbundle mit der erhaltenen PrescriptionID. Die QES führt der Leistungserbringer über die Signaturoperation des Konnektors aus. Der Adapter verpackt das unveränderte signierte Dokument als ePrescription-Binary im Parameters-Request. Der Aufruf enthält die Task-ID in der URL und den AccessCode im Header X-AccessCode oder Parameter ?ac. Erfolg liefert den Task im Status ready; FHIR-Fehlerantworten werden als OperationOutcome ausgewertet.
↔ Horizontal wischen, um das vollständige BPMN-Modell zu sehen.
BPMN-Semantik: $create und $activate sind absichtlich als eigenständige Interaktionen modelliert. Task-ID/PrescriptionID und AccessCode aus dem ersten Pfad sind Eingangskontext des zweiten. Der Statuswechsel folgt erst auf die erfolgreiche Prüfung durch den Fachdienst. Nach dem Signieren verändert der Adapter weder den signierten Inhalt noch das Signaturobjekt. Der MEMM Headless Client bleibt eine separate Kommunikationsgrenze.
Veröffentlichte gematik-Referenzen · 02.10.2026Core 2.0.0 · A223/A224 · $create ↗Core 2.0.0 · A150 · $activate ↗E-Rezept 2.0.0 · Parameters/Binary ↗
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.
State Authority · Workflow
BPMN-Ausführung bleibt intern; FHIR Task ist extern maßgeblich.
Eine BPMN-Engine kann interne fachliche Schritte orchestrieren. Sie ersetzt keine TI-Flow Task-ID, flowtype-spezifische Operation oder normativen Statusübergang. Diese Regeln sind zu implementierende und zu testende Architekturgrenzen, keine Behauptung eines vollständigen Fachdienstes.
BPMN / Rust Runtime
Interne Kommando-Planung, dauerhafte Orchestrierung, Ownership, Timer und Recovery. Kein eigenständig maßgeblicher FHIR-Status.
Versionierter FHIR-Adapter
Übersetzt einen fachlichen Intent in eine erlaubte, versionsgebundene FHIR-Operation. Erfasst Vorgangsidentität, Request-Kontext, Serverantwort und Validierungsfehler.
TI-Flow Fachdienst
Maßgeblicher Ausgang für den serverseitigen Task-Lebenszyklus. Ablehnung, Timeout oder unklarer Ausgang dürfen nie still als erfolgreicher Übergang verbucht werden.
Reconciliation / Outbox
Ein Timeout lässt den Ausgang offen. Retry, Failover und Zustandsabgleich folgen der jeweiligen TI-Flow-Operation und den veröffentlichten Fehlerregeln. Ein erneuter Aufruf kann Teil dieses Verfahrens sein; eine pauschale Retry- oder Read-first-Regel wird daraus nicht abgeleitet.
Illustrative Ergebnisse: Erfolg → bestätigten Task erfassen; Ablehnung → Fehler und zuletzt bestätigten Stand erhalten, ohne einen unveränderten Remote-Task anzunehmen; Timeout → Ausgang bis zur operationsspezifischen Klärung offenhalten. Dies sind Architekturregeln, keine geprüfte Laufzeitaussage.
FHIR · ZETA · HCC · Evidence
Normative Verantwortlichkeiten bleiben separat prüfbar.
FHIR-Validierung
Der Fachdienst-Validator verbindet CoreImage und gematik-FHIR-Konfiguration in einem isolierten OCI-ValidatorImage. Pakete, expandierte Terminologien und aus Differentials erzeugte Snapshots werden zur Build-Zeit gebunden. Eine inkonsistente Konfiguration bricht den Build ab; externe Registry- und Terminologiezugriffe zur Laufzeit sind untersagt. Die Ergebnisse müssen dem Referenzvalidator entsprechen. Die separate Client-Validierung dient Entwicklung und Integration; das produktive FD-$validate bleibt nicht exponiert.
ZETA Client / Guard
Anwendungseigene Policy-Prüfungen ersetzen keine ZETA-Zugriffsentscheidung. OAuth-, Schlüssel-, Token-, Session- und Attestierungsfunktionen des Clients sind getrennt von Guard und Fachdienst zu prüfen.
HCC / VAU
Shard-lokale Ausführung und Rust Memory Safety ersetzen weder HCC-Attestierung noch Schlüsselverwaltung, vertrauenswürdige Ausführung oder Fachdienst-Betriebszulassung.
Nachweis und Scope
Eine externe Anforderung ist erst mit Version, Komponentenzuordnung, Prüfschritt, reproduzierbarem Ergebnis und Review-Entscheid geschlossen. Owner-Aussagen und BPMN-Bilder ersetzen diese Evidenz nicht.
Core 2.0.0 · A264 · Retry / Failover ↗ · FD 1.0.0 · A_29821–A_29841 ↗ · TIFlowClientValidationServer ↗ · gemSpec_ZETA ↗
Normative Reference · gematik
Fachdienst: Produkt und Anbieter
Externe gematik-Dokumente zur Architektureinordnung. Die Nennung macht ITL weder zum zugelassenen Hersteller noch zum Betreiber.
PTV · Freigegeben02.10.2026
gemProdT_TI-Flow-FD_PTV_1.0.0-0_V1.0.0 ↗
Produkttypsteckbrief für den TI-Flow Fachdienst: normative Produktgrenze, nicht allein durch BPMN abgedeckt.
Architekturbezug: FHIR-Fachdienst / HCC- und ZETA-Grenze
ATV · Freigegeben02.10.2026
gemAnbT_TI-Flow_FD_ATV_1.0.0-0_V1.0.0 ↗
Anbietertypsteckbrief: Anforderungen an die TI-Flow-Fachdienst-Betreiberrolle, getrennt von Hersteller und Runtime.
Architekturbezug: Betrieb des TI-Flow-Fachdienstes
Die folgenden Anforderungserklärungen beziehen sich auf die geprüften Quellenversionen. Interne R1001-Zähler beschreiben einen eigenständigen Engineering-Scope.
Anforderungen im Zusammenhang
Was die Spezifikationen für diese Architektur bedeuten.
Ausgewählte Anforderungen mit fester Quellenversion. Ein Thema aufklappen, um Verantwortung, Schnittstelle oder Datengrenze nachzulesen.
Drei Rollen für den HCC-Dienst
Der TI-Flow-Fachdienst-Hersteller ist HCC-Workload-Hersteller: Er entwickelt, testet, dokumentiert und registriert das Workload-Release. Der Fachdienst-Anbieter ist HCC-Dienstanbieter: Er integriert den Dienst in seinen Mandantenkontext und verantwortet Betrieb, Monitoring und Support. Der HCC-Provider stellt Plattform und HSM-Cluster sowie den providerspezifischen Trust-Domain Build Service (TDBS) und den Trust-Domain Configuration & Attestation Service (TDCAS) bereit. Der übergreifende TI Verification & Build Service liegt in der Verantwortung der gematik; die providerspezifischen Build Services sind darin eingebunden. Die Rollen können organisatorisch verbunden sein; ihre Pflichten bleiben getrennt.
Workload, Attestierung und Konfiguration
OCI-konforme Workload-Images werden für den Trust-Domain Build Service bereitgestellt. HSM-Zugriffs-Credentials bezieht der Dienst vom Trust-Domain Attestation Service. Die Workload lädt ihre Konfiguration beim Start und muss für Änderungen neu instanziiert und attestiert werden können. Beliebige privilegierte Laufzeitadministration ist ausgeschlossen; vordefinierte Eingriffe auf Anwendungsebene und Policy-Administration bleiben im spezifizierten Rahmen möglich.
VAU, Persistenz und Client-Eingang
Der TI-Flow-Fachdienst verarbeitet alle fachlichen Operationen innerhalb der VAU. Schützenswerte Daten werden vor einer Speicherung außerhalb der VAU verschlüsselt; die Persistenzschlüssel bezieht der Dienst aus einem HSM der HCC-Plattform. Der ZETA Guard ist der einzige Eingang für Clientanfragen. Client bis Guard verwendet TLS und ASL; bei getrennten VMs sichert mTLS die Verbindung zwischen Guard und Resource Server ohne zusätzliche ASL. Die Fachautorisierung gilt weiterhin je Operation. Die E2EE-Grenze eines Headless Clients und die serverseitige VAU sind eigenständige Schutzkontexte.
Persistenzschlüssel und Zertifikatsprüfung in TI-Flow
A_29714 verlangt für persistierte Vorgangsdaten entweder einen eigenen Schlüssel je Vorgang oder mindestens einen Schlüsselwechsel pro Sekunde, sodass nur die in dieser Sekunde neu angelegten Vorgänge denselben Schlüssel nutzen. A_29715 bindet den Bezug an das HSM der HCC-Plattform. Die Spezifikation kennzeichnet eine mögliche spätere Ablösung von A_29714 als offenen Punkt; daraus folgt noch keine geänderte Vorgabe. Nach A_29732 werden aktiv verwendete Zertifikate auf Integrität und Authentizität geprüft. Ohne gültiges Ergebnis müssen die davon abhängigen Arbeitsabläufe abgelehnt werden; jeder verwendete öffentliche Schlüssel muss auf eine erfolgreiche Zertifikatsprüfung zurückführbar sein.
Systemprotokolle und Pseudonymisierung
Sensible Informationen werden vor dem Speichern eines Systemprotokolleintrags entfernt. Zulässige Zwecke sind anlassbezogene Fehleranalyse und -behebung sowie Security Monitoring. Fehleranalyse-Protokolle sind nach Fehlerbehebung unverzüglich, Security-Monitoring-Protokolle nach drei Monaten zu löschen. Für gematik-Logdaten wird key_pn_log im Klartext ausschließlich in der VAU verarbeitet und im Vier-Augen-Prinzip eingebracht; für diesen besonderen Schlüssel ist eine Speicherung im VAU-HSM nicht zwingend.
Betriebsverantwortung für den gesamten Dienst
HCC-Dienste unterstützen mehrere Instanzen auf verschiedenen Hosts, sodass Hostwechsel oder Neustarts den Service nicht unterbrechen. Der HCC-Dienst protokolliert Fehler- und Performancedaten genutzter Cloud-Services; der HCC-Dienstanbieter überwacht und steuert Kapazitäten und testet Änderungen des HCC-Stacks vor dem produktiven Einsatz. Der TI-Flow-Anbieter erfüllt zusätzlich seinen ATV und die dienstbezogenen Performance-Vorgaben. gemSpec_Perf 2.88.0 konkretisiert die Anbieterpflichten: A_29788 verlangt 99,99 % Verfügbarkeit zur Hauptzeit und 99,97 % zur Nebenzeit in den festgelegten Servicezeiten. A_29790 verlangt die betreffenden Medication-Übermittlungen innerhalb von zwölf Stunden, sofern technische Fehler im ePA-Aktensystem dies nicht verhindern; A_29791 verlangt Versand an das Push-Gateway innerhalb von 60 Minuten nach Ereignisgenerierung, sofern das Gateway erreichbar ist. Diese normativen Zielwerte müssen im konkreten Dienstbetrieb nachgewiesen werden. Ein lokales Readiness-Signal beschreibt nur einen Teil dieses Betriebsbilds.
$create: Task, PrescriptionID und AccessCode
Das verordnende Primärsystem übermittelt workflowType an POST /Task/$create. Der Fachdienst prüft die zugelassene Rolle der Leistungserbringerinstitution anhand von zeta-user-info.professionOID sowie die Eingaben, erzeugt den AccessCode und liefert bei Erfolg einen Task im Status draft. Task.id entspricht der PrescriptionID. Beide Identifikatoren und der AccessCode gehören zum nachfolgenden Aktivierungskontext; der AccessCode ist geschützt zu behandeln. Ein interner BPMN-Vorgang besitzt keine eigene Autorität über den Status dieses Tasks.
$activate: Signatur erhalten, Zugriff und Status prüfen
Das Primärsystem erzeugt das profilkonforme Verordnungsbundle mit der erhaltenen PrescriptionID. Die QES erfolgt durch den Leistungserbringer über die Konnektor-Signaturoperation als enveloping CAdES mit eingebetteter OCSP-Antwort; authoredOn und QES-Erstellung müssen taggleich sein. Der Adapter erhält Inhalt und Signaturobjekt unverändert und verpackt die signierten Daten als ePrescription-Binary in Parameters. POST /Task/<id>/$activate benötigt Task-ID, AccessCode im Header X-AccessCode oder Parameter ?ac sowie die QES-Daten. Der Fachdienst prüft unter anderem Rolle, AccessCode, Ausgangsstatus draft, Signatur, PrescriptionID und Profil. Erst Erfolg liefert Task.status = ready. FHIR-Fehlerantworten bleiben als OperationOutcome erkennbar. Die eigene Zertifikats- und Sperrstatusprüfung des Fachdienstes einschließlich einer vorgeschriebenen OCSP-Ergänzung bleibt von der Adapteraufgabe getrennt.
Unbekannte Ausgänge nach der jeweiligen Operation klären
Retry und Client-Failover richten sich nach der veröffentlichten Fehlerbehandlung und der konkreten Operation. A264 unterscheidet unter anderem 4xx außer 408/429 (kein Retry), 429 (stündlich, höchstens zehn Wiederholungen) und 502/506 (Retry nur mit Client-Failover, höchstens zehn Wiederholungen). Äußerer HTTP-Status und innerer ASL-Status werden berücksichtigt. Ein Timeout ist zunächst ein unbekannter Ausgang. Ein abgelehnter Folgeaufruf beweist nicht, dass der Remote-Task seit dem letzten bestätigten Stand unverändert blieb. Für einen verlorenen $activate-Response beschreibt der Core IG einen erneuten Aufruf; der erläuternde Client-Hinweis nennt dabei 403, die serverseitige Statusanforderung A175 dagegen 412. Diese Quellenabweichung bleibt ausdrücklich offen. Die Architektur leitet daraus weder einen universellen Fehlercode noch eine pauschale Wiederholungsregel ab.
Normativer Validator: OCI, Konfiguration und Offline-Betrieb
Der Hersteller liefert ein CoreImage; daraus entsteht mit gematik-FHIR-Konfiguration ein OCI-ValidatorImage. Pakete, Regeln, expandierte Terminologien und aus Differentials erzeugte Snapshots werden beim Build gebunden. Eine unplausible oder inkonsistente Konfiguration muss den Build abbrechen. Externe Paket-Registry- und Terminologieverbindungen zur Laufzeit sind untersagt. Die Komponente ist technisch zu isolieren und muss dieselben Ergebnisse wie der Referenzvalidator erzeugen; ein proprietärer Validator ist bei dieser Ergebnisgleichheit möglich. Die interne Anbindung kann per REST oder internem Protokoll erfolgen. Der Fachdienst exponiert $validate nicht an Clients; der separate ClientValidationServer dient Entwicklung und Integration. Betriebslogs enthalten keine validierten Nutzdaten.
TI-Flow: Profilgültigkeit pro Ressource und Zeitpunkt
Ein interner Mapper-Pin legt die extern zulässige Profilversion nicht fest. Der TI-Flow-Fachdienst bestimmt den normativen Referenzzeitpunkt je Ressource, etwa MedicationRequest.authoredOn oder MedicationDispense.whenHandedOver, und wertet ihn gegen die aktuelle FHIR-Konfiguration aus. Datums- und Zeitangaben ohne Zeitzone folgen der am jeweiligen Datum gültigen deutschen Zeit (CET/CEST). Der Core IG verlangt bei verpflichtendem meta.profile genau einen Eintrag und für generierte Ressourcen eine major.minor-Versionsangabe im Canonical; die vollständige Paketversion bleibt gesondert dokumentiert. Client-Regeln für fullUrl, auflösbare Referenzen und profilierte Extensions gelten zusätzlich. Eine optionale Vorprüfung hebt diese Erzeugungsregeln nicht auf.
ePA Medication: eigener asynchroner Übermittlungsweg
Der TI-Flow-Fachdienst übermittelt Daten der Flowtypes 160, 166, 169, 200 und 209 asynchron an den ePA Medication Service. Der erfolgreiche ursprüngliche Client-Aufruf bestätigt daher noch keine Übernahme in die ePA. Der Fachdienst ordnet Verordnungs- und Dispensierdaten den ePA-Profilen zu und nutzt die dort definierten Bereitstellungs- und Stornierungsoperationen. TI-Flow E-Rezept 2.0.0 regelt die Auslösung und das Mapping; ePA Medication 1.3.5 beschreibt den eigenen Daten- und Schnittstellenvertrag. Diese Rollen sind getrennt von einer allgemeinen ePA-FdV-Integration zu prüfen.
Redaktioneller Quellenabgleich: 17. Oktober 2026. Die Zuordnung erklärt Anforderungen; Implementierungsprüfung und Produktzulassung benötigen eigene Nachweise.
Product · Provider · Execution
Fünf Verantwortungsgrenzen; keine ersetzt die andere.
BPMN / Rust Core
Interne Orchestrierung; kein eigenständiger maßgeblicher Remote-FHIR-Task-Status.
FHIR Vertrag & Validator
Versionierte Operationen und Profile; unklare Ergebnisse erfordern Reconciliation.
TI-Flow FD Produkt · PTV
Extern spezifiziertes Fachdienst-Verhalten und unabhängige Produktnachweise.
HCC / VAU / ZETA
Vertrauen, Kryptografie, Attestierung und Netzgrenzen sind separat zu prüfen.
FD Betreiber · ATV
Betriebsorganisation und Pflichten werden abhängig von der Anbieterrolle geprüft.
Architekturübersicht, kein ausführbares BPMN-Modell und kein Nachweis eines zugelassenen Fachdienstes.
TI-Flow_26_3 · FHIR IG
FHIR-Profilfamilien sind getrennt zu versionieren und zu prüfen.
Releasegebundene IG-Referenzen, keine MEMM-Abdeckungszusage. Operationen, Validierung und Versionsverträglichkeit sind je IG und Test gesondert zu prüfen.
TI Common
FHIR IG 1.4.0
Gemeinsame FHIR-Bausteine für TI-Dienste; dienstspezifische IG referenzieren Profile, Terminologien und Grundregeln nach Bedarf.
Offizielle Quelle ↗TI-Flow Core
FHIR IG 2.0.0
Workflowübergreifende Task-Operationen, Rollenprüfung, Status, Fehlerbehandlung und FHIR-Validierung zwischen Clients und TI-Flow-Fachdienst.
Offizielle Quelle ↗E-Rezept
FHIR IG 2.0.0
Arzneimittelverordnung und Abgabe zwischen verordnendem PS, Apotheke, Versicherten und Fachdienst; zusätzlich Mapping und asynchrone Übermittlung an ePA Medication.
Offizielle Quelle ↗BfArM
FHIR IG 2.0.0
Eigener Übermittlungsvertrag vom TI-Flow-Fachdienst zum BfArM-Webdienst für den digitalen E-T-Rezept-Durchschlag an das T-Register; der Verordnungsworkflow 166 bleibt im E-Rezept-IG.
Offizielle Quelle ↗DiGA
FHIR IG 2.0.0
Workflow 162: Verordnende erstellen eine DiGA-Verordnung; Versicherte weisen sie dem Kostenträger zu. Dieser stellt einen Freischaltcode oder eine begründete Rückmeldung bereit.
Offizielle Quelle ↗ChargeItem
FHIR IG 2.0.0
PKV-Abrechnungsinformationen zu E-Rezepten: Das Apothekenverwaltungssystem stellt Daten bereit; Fachdienst und berechtigte Clients verwalten ChargeItem, Consent und zugehörige Kommunikation. Die Abrechnung außerhalb des Fachdienstes liegt außerhalb dieses IG.
Offizielle Quelle ↗ePA Medication Service
FHIR IG 1.3.5
Eigener ePA-Daten- und Schnittstellenvertrag für Medikationsliste und Medikationsplan. TI-Flow ist für seine asynchrone Übermittlung ein aufrufendes System; ein erfolgreicher TI-Flow-Request bestätigt noch keine ePA-Übernahme.
Offizielle Quelle ↗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.
TI-Flow_26_3
Die Runtime ist eine Grundlage – der normative TI-Flow_26_3-Scope ist breiter.
Die Veröffentlichung TI-Flow_26_3 vom 02.10.2026 umfasst Fachdienst- und HCC-Spezifikation V1.0.0, Inbetriebnahme-Konzept, Produkt-/Anbietersteckbriefe, die TI-Flow FHIR Implementation Guides 2.0.0 sowie TI Common 1.4.0 und ePA Medication 1.3.5. Diese Ebenen werden nicht automatisch aus der BPMN/VBucket Runtime abgeleitet.
Externer TI-Flow-VertragFHIR APIs · Profile · fachliche OperationenTI-Flow_26_3 Vergleichsreferenz (Delta offen)
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
Eigenständige BPMN RuntimeDistributed BPMN Engine · Execution Foundationseparater Produkt-Scope · logical placement · local consistency · Recovery
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
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.
Ein technischer Schritt und ein fachliches Ergebnis sind verschiedene Zustände.
Die Integration begleitet einen Aktivierungsaufruf. Maßgeblich für den Task bleibt der externe Fachdienst. Die illustrativen Bahnen erklären den Zusammenhang beider Sichten.
Externer FachdienstMaßgeblicher Task-Zustand
- draft
- Aktivierungsprüfung
- ready bei Erfolg
Integration / HostLokale Beobachtung des Aufrufs
- Aufruf vorbereiten
- Antwort abwarten
- bestätigtes Ergebnis zuordnen
Fehlt die Antwort, bleibt der fachliche Ausgang ungeklärt. Eine technische Retry-Entscheidung benötigt die Zustandsklärungsregeln der jeweiligen Operation.
State Authority und Retry-Grenzen nachlesen →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.