Interoperability Standards

To achieve seamless data fluidity between the EHR, RIS, and PACS, the AWS cloud architecture relies on a "mixed estate" of legacy and modern interoperability standards. The fundamental workflow relies heavily on HL7, FHIR, DICOM, and IHE profiles.

The HL7 committee compiled strict message formats to provide a rigorous framework in which clinical information may be exchanged. In modern AWS cloud architectures, legacy HL7 v2 messages—which are often flat, pipe-delimited text strings—are frequently transformed into FHIR resources to enable scalable API architectures.

View full size

Source: AWS Architecture Blog serverless FHIR interface referenceLast verified: 2026-03-11

This diagram is intentionally narrow: it shows the FHIR facade slice of the RIS interoperability problem, not the full imaging workflow. That makes it useful here because RIS modernization often adds an API-native FHIR edge for orders, results, and patient context while DICOM and IHE profiles still govern modality worklists, acquisition state, and image retrieval.

The following sequence diagram illustrates the complete HL7 v2 to FHIR R4 transformation pipeline within the IHE Scheduled Workflow profile context. Legacy messages are ingested, transformed via AWS Lambda, and stored as FHIR resources in Amazon HealthLake.

This transformation pipeline ensures that legacy HL7 v2 messages (ORM for orders, ADT for demographics, ORU for results) are systematically converted into FHIR R4 resources. The IHE Scheduled Workflow profile governs the semantic consistency between the administrative order in the RIS and the physical image acquisition, with the transformation Lambda serving as the bridge between legacy and modern standards.

The workflow physically bridges the gap between the administrative order residing in the RIS and the physical image acquisition device operating in the scanning room. This critical junction is governed by the IHE Scheduled Workflow profile^{^}IHE Radiology Technical Framework, Volume 1, which provides explicit semantic mappings from HL7-based systems (RIS) to DICOM-based modalities.

• Modality Worklist (MWL): The RIS translates HL7 orders into DICOM MWL^{^}DICOM PS3.4 - Modality Worklist Service Class. Technologists query this to retrieve exact patient demographics and study parameters, preventing "wrong patient" errors^{^}PMCID: PMC9864478 - Prevention of wrong patient errors through MWL verification.
• Modality Performed Procedure Step (MPPS): As the scan begins and completes, the modality communicates its operational status back to the RIS and PACS using this protocol^{^}DICOM PS3.4 - Modality Performed Procedure Step Service Class. The RIS updates the workflow engine (e.g., from "In Progress" to "Completed").
• DICOM Store & Storage Commitment: The actual image pixel data is transferred to the PACS using DICOM Store commands^{^}DICOM PS3.4 - Storage Service Class, while Storage Commitment protocols^{^}DICOM PS3.4 - Storage Commitment Service Class ensure no data is lost during the transfer.
• DICOMweb: For modern web-based viewing, the architecture leverages RESTful services such as QIDO^{^}DICOM PS3.18 - QIDO-RS, WADO^{^}DICOM PS3.18 - WADO-RS, and STOW^{^}DICOM PS3.18 - STOW-RS.

The IHE Scheduled Workflow profile ensures semantic consistency between administrative systems and imaging devices. The following diagram illustrates the complete DICOM workflow integration:

This automated workflow guarantees that the DICOM metadata embedded in the generated images perfectly matches the administrative record in the HIS, thereby preventing catastrophic "wrong patient" errors. The Storage Commitment protocol provides mathematical assurance that no data is lost during custodianship transfer.