The orchestrator lives above a stack of complementary standards
DICOM, HL7 v2, FHIR, and IHE profiles solve different problems. A workflow orchestrator fails when it treats one of them as if it were the whole system contract.
Layered standards view
Loading diagram...
How the standards usually divide responsibilities
| Standard | Primary role | Why the orchestrator cares |
|---|---|---|
| DICOM | Image object and metadata contract | Study, series, modality, and identifiers drive routing and retrieval |
| HL7 v2 | Legacy event and order messaging | Many real source systems still emit ADT, ORM, ORU, and related events |
| FHIR | Modern clinical API and resource model | Longitudinal context, request linkage, and downstream apps depend on it |
| IHE profiles | Cross-system workflow expectations | Profiles define how actors behave together in scheduled or encounter-based flows |
DiagnosticReport - FHIR R4
FHIR R4 DiagnosticReport shows how reports connect back to encounters, observations, and related imaging context.
Review DiagnosticReportServiceRequest - FHIR R4 definitions
FHIR R4 ServiceRequest definitions document the order-side contract for requested diagnostic services.
Review ServiceRequestClinical linkage means preserving the order, encounter, and result chain
A useful orchestration target is not just “store the exam.” It is “store the exam with enough clinical context that the right clinician can understand why it was ordered, in which encounter it belongs, and how the final result should come back.”
For a beginner, the easiest way to make that idea concrete is to look at the official FHIR resource shape that closes the loop. DiagnosticReport is a good teaching anchor because it visibly ties the final report back to the original request, the encounter, and the related imaging study.
FHIR ImagingStudy is helpful at this boundary because it can carry study, series, performer, and retrieval-endpoint context without pretending to contain the DICOM instances themselves. That makes it a good bridge between workflow-aware APIs and DICOMweb retrieval systems.
FHIR linkage example
A simplified report payload showing how the report can link back to an order and an encounter.
Click on an annotation to highlight it in the JSON
Encounter - FHIR R4
FHIR Encounter is the core context resource for visit, location, and status transitions in many health workflows.
Review EncounterImagingStudy - FHIR R4
FHIR ImagingStudy defines the study and series metadata bridge that links workflow-aware APIs to DICOM retrieval endpoints.
Review ImagingStudyIHE Radiology Technical Framework Volume 1
IHE Radiology technical framework that defines the cross-actor workflow expectations sitting above individual messages and resources.
Review the radiology technical frameworkUsing DICOMweb with AWS HealthImaging
AWS documentation on DICOMweb-conformant responses, including retrieval, search, and OIDC-related topics.
Review DICOMweb behaviorKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.