A clinical study moves through multiple state domains
The new radiology research is a useful correction: a study is not just an imaging object flowing through storage. It crosses scheduling, acquisition, reporting, and reconciliation states, so the orchestrator needs a durable model of the whole clinical control path.
Representative study lifecycle state machine
Loading diagram...
Why the control plane needs domain-aware state
| Domain | Typical states | Why a durable model matters |
|---|---|---|
| Clinical and scheduling | order received, identity validated, procedure scheduled | Order fidelity and patient identity mistakes propagate into every downstream step. |
| Imaging and reporting | acquisition complete, images committed, report finalized | The workflow must know whether data is merely captured, durably stored, or clinically released. |
| Administrative and reconciliation | charge seeded, claim or exception, financially reconciled | Clinical completion and financial completion are related but not identical operational states. |
Non-linear entry points are normal
Encounter-based imaging, downtime recovery, and imported outside studies can enter the control plane after acquisition has already begun. The state model should support those late joins instead of assuming every case starts at scheduling.
Topology choice decides where workflow truth lives
The architectural tension is not between “modern” and “legacy.” It is between choreographed event reaction and a durable orchestrator that owns cross-system workflow state. Both are useful, but they fail in different ways.
Choreography, orchestration, and hybrid control-plane trade-offs
| Pattern | Best fit | Main risk if overused |
|---|---|---|
| Pure choreography | High-volume fan-out where downstream consumers can react independently | No single place to answer the exact end-to-end status of one patient workflow |
| Pure orchestration | Cross-system workflows with approvals, timeouts, compensation, and audit needs | The workflow engine becomes overloaded if it is used to transport raw payloads instead of state and references |
| Hybrid control plane | Durable workflow state paired with an event backbone for buffering, fan-out, and analytics | Teams blur responsibilities unless they define which layer owns truth, replay, and recovery |
Hybrid control plane for radiology workflow
Loading diagram...
Saga choreography pattern
AWS Prescriptive Guidance on event-driven saga choreography, useful for understanding when distributed event reaction is helpful and when it becomes harder to observe or recover.
Review saga choreographySaga orchestration pattern
AWS Prescriptive Guidance on coordinator-driven saga orchestration, which maps more directly to patient-facing workflows that require one durable state history.
Review saga orchestrationPrevent dual-write drift and pass references, not binaries
A health orchestrator often has to change local application state and publish an event that advances another system. If those two writes happen separately, a transient failure can leave the database updated but the downstream workflow blind. That is exactly the class of silent inconsistency the transactional outbox pattern is designed to prevent.
Representative outbox event record
A simplified outbox row showing how the local state transition, publish status, and payload reference stay together in one durable record.
Click on an annotation to highlight it in the JSON
Do not push DICOM blobs through the workflow engine
Store large payloads durably in S3 or the imaging datastore first, then pass workflow identifiers, import-job IDs, manifest locations, or object URIs through the control plane. Heavy binary transport and workflow state tracking are different jobs.
- Commit the domain row and outbox row atomically so the local system and event stream cannot drift apart silently.
- Use idempotency keys that represent the business transition, not only the transport attempt.
- Keep workflow payloads small by carrying references to DICOM imports, manifests, or report artifacts rather than the artifacts themselves.
Transactional outbox pattern
AWS Prescriptive Guidance on solving the dual-write problem between a local database transaction and event publication.
Review transactional outboxStep Functions best practices
AWS guidance that includes keeping payloads small and using Amazon S3 references instead of pushing oversized payloads through execution history.
Review Step Functions payload guidanceRecovery means compensation, suspended waits, and explicit replay rules
A failed workflow is not always safe to restart from the beginning. If an appointment slot was already reserved, a worklist entry was already created, or a document publish attempt is already pending, the orchestrator needs a policy for compensation, durable suspension, or operator intervention.
Compensation-first recovery path
Loading diagram...
Redrive and compensation are complementary, not interchangeable
Execution redrive is useful when a durable workflow can continue from the unsuccessful step. Compensation is still required when earlier steps already changed external systems and those changes must be reversed or held in an exception lane.
This is also the right mental model for external national services. If the HI Service or My Health Record path is unavailable, the safe response is usually a durable suspended state, encrypted payload retention, health-checked retry, and an explicit release only after service recovery is verified.
Saga orchestration pattern
AWS Prescriptive Guidance on coordinator-managed sagas and compensating actions.
Review orchestrated saga recoveryRestarting state machine executions with redrive in Step Functions
AWS documentation on continuing eligible Standard Workflow executions from the unsuccessful step instead of starting over.
Review execution redriveKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.