State machines make healthcare workflow state explicit
Once a workflow includes routing, enrichment, reviewer approval, timeout handling, and downstream publication, the application is no longer just moving data. It is managing state. Step Functions is valuable because it makes that state visible and durable.
This module stays focused on the workflow-engine layer itself. The next module expands outward into control-plane topology, transactional outbox, and compensation design so you can decide how this state machine fits into the wider enterprise workflow.
What the state machine is responsible for
| Concern | Example | Why it matters |
|---|---|---|
| Branching | Urgent stroke study versus routine outpatient study | Different urgency levels require different queues and escalation rules |
| Retries and failure policy | Import job or notification retry | Clinical workflows need explicit recovery paths instead of silent drop behavior |
| Approval gate | Human reviewer approves AI-assisted draft | Publication should not happen just because a model produced output |
Workflow type fit in healthcare orchestration
| Workflow type | Best fit | Why architects choose it |
|---|---|---|
| Standard | Long-lived review, callback, and auditable publication workflows | Durable execution history and longer-running state are usually more important than raw throughput |
| Express | Short, high-volume supporting tasks such as lightweight event processing | It suits bursty short-lived work, but not every healthcare workflow should be flattened into that model |
Step Functions service integrations
AWS documentation on using Step Functions to connect workflows to AWS services and external actions.
Review service integrationsChoosing workflow type in Step Functions
AWS guidance on Standard versus Express workflows, which matters when the health workflow mixes long-lived approval stages with high-volume short tasks.
Compare Standard and ExpressCallback gates make human approval a real workflow step
Clinical review should be modeled as a callback boundary, not as an implied side effect. The orchestrator hands a task token to the reviewer application, pauses durably, and resumes only when an explicit success or failure response arrives.
Task-token callback state example
A simplified Amazon States Language fragment showing how a reviewer-controlled callback state carries the task token and case payload.
Click on an annotation to highlight it in the JSON
Human approval callback flow
Loading diagram...
Waiting for a callback with task token
AWS documentation for the callback pattern used in reviewer-controlled workflows.
Review task-token callbacksHuman approval tutorial
AWS tutorial illustrating the approval pattern that maps cleanly to clinical review gates.
Read the human approval tutorialDistributed Map is the scale-out primitive for large batch orchestration
Some orchestration problems are single-study flows. Others involve thousands of objects, manifests, or retrospective reprocessing jobs. Distributed Map gives the orchestrator a controlled way to run large fan-out workloads while tracking Map Runs and failure thresholds.
Distributed Map over a large imaging data set
Loading diagram...
Distributed Map
AWS documentation for large-scale parallel workflows, Map Runs, result writing, and tolerated-failure controls.
Review Distributed MapRestarting state machine executions with redrive in Step Functions
AWS documentation for continuing eligible failed Standard Workflow executions from the unsuccessful step.
Review redrive behaviorKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.