Cloud Architecture & Migration

Most hospitals do not replace every modality and departmental endpoint when they modernize imaging. A practical cloud architecture therefore starts by isolating local DIMSE traffic at the edge and bridging it into controlled cloud ingestion paths.

View full size

Source: AWS Industries blog on integrating on-premises imaging with HealthImagingLast verified: 2026-03-11

That boundary is where retries, buffering, audit, and de-identification choices become much easier to govern. It also lets cloud services optimize ingest without forcing every legacy device to learn a new protocol stack.

The operational risk in cloud migration is rarely the upload itself. It is proving what was scanned, what was imported, what produced warnings, and which image sets became primary versus non-primary after the service reconciled DICOM hierarchy and metadata.

AWS HealthImaging makes this behavior explicit. Import jobs organize instances into image sets based on DICOM hierarchy and metadata. If newly imported metadata conflicts with an existing primary image set, the data can still be imported, but it is placed into a non-primary image set and surfaced in audit outputs such as success.ndjson and EventBridge events with isPrimary: False.

Cloud imaging programs often need two views of the same study: an original-source representation that satisfies retention and traceability duties, and an optimized serving layer that supports modern retrieval, analytics, and viewer performance.

Stored transfer syntax becomes a real production dependency

A serious DICOM migration validates more than byte counts. It checks study, series, and instance completeness, confirms UIDs are handled as intended, tests representative transfer syntaxes, and proves that viewers and downstream workflows still behave correctly after cutover.

• Reconcile counts at study, series, and instance level rather than only at bucket level
• Sample unsupported or uncommon transfer syntaxes early, not after production cutover
• Retest query, retrieve, and viewing behavior with representative modalities and viewers
• Document regional constraints such as data residency, assurance scope, and downstream reporting duties
• Confirm contract exit, deletion, and backup-restore terms instead of assuming the cloud provider lifecycle matches healthcare retention obligations

The cutover unit should usually be a representative cohort of studies rather than the entire migration at once. That keeps rollback practical and makes warning outputs, decoder mismatches, and viewer defects actionable instead of burying them inside one giant batch status.

Australia is a useful example because the architecture constraints are explicit. Australian Digital Health Agency guidance says cloud services operate under a shared responsibility model and that healthcare organisations remain accountable for protecting health information, data sovereignty, backups, and contractual exit terms. The imaging standard alone does not answer those questions.

The broader workflow obligations matter too. On 8 January 2026, the Australian Government stated that from March 2026 some limb X-ray reports become immediately visible in My Health Record, while other diagnostic imaging reports use a 5-day delay, and from July 2026 providers will be required to upload pathology and diagnostic imaging reports by default. That means a cloud-imaging program should design report distribution, audit, and residency controls alongside the DICOM archive, not as a separate afterthought.