Use AWS HealthImaging when the repository is truly image-centric
Generic object storage is still useful, but image-heavy document sharing programs often need more than durable files. They need study-, series-, and frame-level retrieval patterns, DICOMweb semantics, and viewer-friendly image delivery.
AWS HealthImaging provides that specialized imaging surface. In an IHE-oriented design, it can act as the imaging repository behind workflows that still depend on registry metadata, document discovery, and enterprise governance.
Imaging retrieval path with HealthImaging
Loading diagram...
Using DICOMweb with AWS HealthImaging
Official AWS documentation for DICOMweb retrieval patterns and service capabilities.
Read the DICOMweb guideMHD is the bridge from XDS concepts to FHIR-friendly document access
Mobile access to Health Documents (MHD) does not discard document-sharing ideas. It repackages them into FHIR resources and REST-style interactions. In practice, DocumentReference becomes the discoverability surface that many app teams understand more readily than ebRIM metadata.
How XDS concepts show up in a modernization path
| Legacy concept | Modern surface | Why it matters |
|---|---|---|
| XDS DocumentEntry | FHIR DocumentReference | Expose document metadata to REST-native consumers |
| Repository payload | Attachment / Binary endpoint | Keep payload retrieval separate from metadata discovery |
| Registry stored query | FHIR search parameters and MHD transactions | Reduce custom query contracts for app teams |
FHIR DocumentReference for a shared clinical document
A compact JSON example that shows how document discovery moves into a FHIR representation.
Click on an annotation to highlight it in the JSON
The important modernization detail is that MHD does not flatten every XDS concept into a single FHIR resource. DocumentReference carries discoverability. Actual payload retrieval still happens through attachment URLs, Binary resources, or repository-specific endpoints.
How common XDS concepts map into an MHD-style FHIR surface
| XDS concept | FHIR surface | Architectural implication |
|---|---|---|
| XDSDocumentEntry | DocumentReference | Document metadata is now discoverable through REST and FHIR search |
| Repository document payload | Attachment URL or Binary resource | Metadata lookup and payload retrieval stay separated on purpose |
| SubmissionSet and Folder | List plus MHD constraints | Grouping semantics survive, but they are no longer stored as ebRIM registry packages |
| Association semantics | Relationship fields, List membership, and profile constraints | Some ebRIM richness must be preserved through profile rules rather than one core resource field |
Do not promise a perfect one-to-one metadata migration
MHD is an interoperability bridge, not a claim that every ebRIM field or association has a single native FHIR equivalent. The community still has to decide which semantics remain mandatory and where profile constraints or extensions are needed.
IHE Mobile access to Health Documents (MHD)
Official IHE publication for exposing document sharing workflows through FHIR-based APIs.
Open the MHD guideMHD ITI-66 Find Document Lists
Official MHD transaction showing how clients discover document and list metadata over FHIR search.
Read ITI-66Imaging modernization needs an image-aware bridge, not only document metadata
A radiology sharing program is not finished just because a report can be found through DocumentReference. Imaging workflows also need viewer-oriented study, series, and instance retrieval patterns. That is why the IHE radiology domain includes image-sharing profiles such as XDS-I.b and web access patterns, while AWS HealthImaging provides a DICOMweb repository surface.
Registry-led discovery with image-aware retrieval
Loading diagram...
Which layer solves which imaging-sharing problem
| Layer | What it contributes | What it does not replace |
|---|---|---|
| XDS.b or MHD | Patient-centric discovery and document metadata | Image-aware viewer retrieval behavior |
| XDS-I.b and radiology profile family | Image-sharing semantics, manifests, and imaging workflow constraints | The need for a real imaging repository |
| AWS HealthImaging | Managed DICOMweb image retrieval surface | The registry or community metadata governance layer |
IHE Radiology Domain Profiles
Official radiology-domain profile catalog, including image-sharing and web-access patterns relevant to XDS-I.b modernization.
Browse the radiology profilesA realistic modernization roadmap keeps legacy interoperability alive while shifting the surface
Most organizations cannot replace XDS.b and imaging infrastructure in one move. A pragmatic path keeps existing document-sharing flows operating while introducing REST-friendly discovery, better analytics, and viewer-oriented imaging APIs around them.
Modernization path from XDS.b to FHIR and DICOMweb
Loading diagram...
Modernization principle
Preserve the business workflow and the legal record first. Then modernize the interface surface so new applications consume DocumentReference, Binary, and DICOMweb rather than bespoke enterprise SOAP endpoints.
Searching FHIR resources in AWS HealthLake
Official AWS documentation for FHIR persistence and search patterns relevant to MHD-style exposure.
Read the HealthLake search docsKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.