Vier Grenzen, die bewusst getrennt bleiben
- Canonical TI-Flow domain: stabile Process-, Task-, Actor- und Transition-Semantik unabhängig von der Wire-Repräsentation.
- Lokale Flowtype-/Mapper-Generation: versioniert das interne Rendering; zulässige externe Operationen und Task-Übergänge bestimmt der Fachdienst-Vertrag.
- FHIR® adapter: deterministische Abbildung und lokale Profilvalidierung außerhalb der Workflow-Transaktion.
- Delivery boundary: durable Intent/Payload wird erst nach erfolgreichem Commit über die externe Integrationsgrenze zugestellt und reconciled.
Interner BPMN-Zustand und maßgeblicher FHIR-Task-Status sind getrennte Zustandsräume
Der BPMN-Zustand beschreibt die interne Orchestrierung. Für den externen TI-Flow-Task-Lebenszyklus sind die am Fachdienst geführte Task-ID, der dortige Task-Status und die normativ zulässigen Übergänge maßgeblich. MEMM kann externe Ergebnisse abbilden, darf einen abgelehnten oder ungewissen Statusübergang aber nicht lokal als erfolgreich festschreiben. Eine getrennte Domänengrenze schützt die interne Semantik vor Änderungen der FHIR-Repräsentation.
Externe Zustände und Wiederholungen
Ein erfolgreicher $create-Aufruf liefert den Task in draft mit Task-ID/PrescriptionID und AccessCode. $activate benötigt zusätzlich die unveränderten QES-Daten und führt bei Erfolg zu ready. Ein Timeout lässt den Ausgang offen; Retry und Failover richten sich nach der konkreten Operation und der veröffentlichten Fehlerbehandlung. Ein abgelehnter Folgeaufruf beweist keinen unveränderten Remote-Task.