Why enterprise imaging needs a workflow control plane
A health workflow orchestrator exists because large imaging environments stop behaving like one system. Orders may come from an EHR, image sets may land in a cloud imaging store, reports may return through a RIS or national exchange, and critical decisions still depend on the right human reviewer at the right moment.
The orchestrator is the durable layer that understands workflow state across those boundaries. It tracks when an exam is merely ingested, when context is complete, when AI output is advisory only, when a study is assigned to a radiologist, and when downstream publication is legally permitted.
Control-plane view of a modern imaging workflow
Loading diagram...
Orchestration is about state, not just transport
A routing engine that only moves data is not enough once timing rules, reviewer gates, retries, and publication conditions matter.
Improving medical imaging workflows with AWS HealthImaging and SageMaker
AWS Architecture Blog walkthrough showing an event-driven imaging workflow using S3, SQS, Step Functions, HealthImaging, and SageMaker.
Read the architecture walkthroughWhat is AWS HealthImaging?
Developer guide overview of the managed imaging service used as the imaging-domain store in cloud-native architectures.
Review HealthImaging in the developer guideMedical imaging system reference architecture
AWS Healthcare Industry Lens page that defines the broader cloud medical-imaging topology the orchestrator must coordinate around.
Review the AWS medical-imaging architectureOne orchestrator usually serves several workflow families
The staged material for this track is imaging-heavy, but the important idea is broader: the orchestrator must handle different workflow families with different metadata quality, different urgency, and different routing logic.
Common workflow families in enterprise imaging
| Workflow family | Typical trigger | Main orchestration concern |
|---|---|---|
| Scheduled imaging | Formal order from EHR or RIS | Maintain order fidelity and populate modality worklists correctly |
| Encounter-based imaging | Point-of-care encounter without a pre-placed order | Capture and reconcile patient and encounter context safely |
| Teleradiology and remote reading | Cross-site assignment after ingestion | Deliver the right priors and route the study to the best available reader |
How workflow families converge on one orchestration layer
Loading diagram...
What is AWS HealthLake?
Developer guide overview of the managed FHIR datastore that commonly complements HealthImaging in multimodal architectures.
Review HealthLake in the developer guideGood orchestration design keeps failure domains and audit boundaries explicit
The fastest way to make a workflow brittle is to hide every concern behind one datastore or one Lambda-heavy integration tier. Durable imaging storage, normalized clinical context, and workflow state all fail differently, scale differently, and need different governance evidence.
What each service boundary protects you from
| Boundary | What it should own | What goes wrong if you collapse it |
|---|---|---|
| Imaging-domain store | Durable image-set storage, retrieval, and image metadata access | Workflow code starts pretending it is the long-term imaging system of record |
| Clinical-context store | FHIR patient, encounter, request, and downstream report context | Image-specific routing logic starts polluting the clinical longitudinal record |
| Workflow state machine | Branching, retries, approvals, timeouts, and publication state | State transitions become hidden inside ad hoc service glue and hard to audit |
This separation also improves operational change control. You can update queueing policy or review logic without redesigning image storage, and you can evolve clinical normalization without rewriting the whole orchestration engine.
On AWS, the orchestrator should preserve clear service boundaries
A recurring design mistake is trying to make one service do everything. HealthImaging is the imaging-domain store. HealthLake is the clinical-data contract. Step Functions provides durable workflow coordination. S3, SQS, Lambda, EventBridge, CloudWatch, and CloudTrail complete the operating model.
- Use HealthImaging when the primary contract is native DICOM image storage and retrieval.
- Use HealthLake when the primary contract is queryable FHIR clinical context.
- Use Step Functions when the real problem is workflow state, branching, retries, and approvals.
- Use supporting AWS services to make ingress, eventing, security, and observability explicit.
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.