FHIR Subscription delivers events on resource changes; a workflow engine composes those events into multi-step processes. The two are complementary, not overlapping, and picking the right primitive matters for maintainability.
When Subscription alone is enough.
- Single-step reaction: new Observation → run one function → done. - Notification-only workflows: send a message when a Task is created. - Event-driven data replication.
When you need a workflow engine.
- Multi-step with branching: order lab → wait for result → route to clinician → wait for signoff → close order. - Time-dependent state: wait 24 hours, then remind if no action. - Retry with backoff on external service failures. - Compensation/rollback: if step 3 fails, undo steps 1-2.
Workflow engines that speak FHIR
Camunda and Temporal are the two general-purpose engines used in FHIR deployments. Camunda's BPMN model fits clinical workflow diagrams; Temporal's code-first model fits engineering-heavy teams. Both integrate with FHIR via custom activities.
FHIR-native workflow options: Medplum bots and Aidbox app SDK provide event-driven scripting inside the FHIR server, which cuts a network hop but lock you into the vendor.
Decision matrix
| Situation | Choice |
|---|---|
| Single-step reactive | FHIR Subscription |
| Multi-step clinical workflow | Camunda / BPMN |
| Multi-step code-first | Temporal |
| Vendor-locked event scripting | Medplum bots / Aidbox app |
| Complex compensation | Temporal (best), Camunda (works) |
Common mistakes. Using Subscription for multi-step workflows leads to distributed state that's hard to reason about. Using a workflow engine for single-event reactions adds unnecessary infrastructure. Match the primitive to the problem.
Workflow engines are worth the investment when clinical processes span days and touch multiple systems. They're overkill when the process is a single Observation → single function reaction.