Radiology Service — Service Overview
Status: populated
Owner: TBD
Last updated: 2026-04-18
Companion: Service Template · 03 platform-services · 02 DDD
1. Purpose
The radiology-service is the platform bounded context for imaging workflow integration. It owns the lifecycle of imaging study metadata, PACS/DICOMweb endpoint configuration, radiology report ingestion and versioning, and secure viewer launch. It makes imaging studies accessible within the EHR without replacing the PACS as the pixel data system-of-record.
2. Bounded Context
| Attribute | Value |
|---|
| DDD context name | radiology |
| Source module ID | CLIN-RAD-PACS |
| Licensing category | Optional add-on (diag.radiology) |
| FHIR resource owners | ImagingStudy, DiagnosticReport (imaging workflow copy) |
| ServiceRequest reader | Consumes imaging orders from orders-service |
3. Responsibilities
| Responsibility | Detail |
|---|
| PACS endpoint registry | Per-tenant/facility DICOMweb endpoint configuration (QIDO-RS, WADO-RS, STOW-RS) |
| Imaging study metadata | Store and expose ImagingStudy resources linked to patient/encounter/order |
| DICOMweb integration | QIDO-RS query for study metadata; WADO-RS references for viewer |
| Radiology report lifecycle | Ingestion of structured/narrative reports; prelim → final → amended versioning |
| Structured reporting workflow | Radiologist worklist → dictate → verify → sign |
| Viewer launch | Signed URL / SMART on FHIR token-based handoff to imaging viewer |
| Critical finding events | Publish diag.radiology.finding.critical for urgent findings |
| HL7 v2 adapter | ORM/ORU notifications via interop-service |
4. Non-Responsibilities
- Pixel data storage (owned by external PACS)
- Chart-filed
DiagnosticReport after clinical review (owned by patient-chart-service)
- Critical finding acknowledgment inbox (owned by laboratory-service results sub-domain and communication-service)
- Patient portal display (patient-portal-service)
- Order placement (orders-service)
5. Upstream Dependencies
| Service | Type | Detail |
|---|
| orders-service | Event consumer + FHIR read | clinical.orders.placed → imaging ServiceRequest |
| registration-service | FHIR read | Patient, Encounter resolution |
| provider-directory-service | FHIR read | Performing radiologist Practitioner |
| interop-service | HL7 v2 passthrough | ORM/ORU exchange with external RIS/PACS |
6. Downstream Consumers
| Service | What it consumes |
|---|
| patient-chart-service | diag.radiology.report.signed events; ImagingStudy FHIR reads |
| patient-portal-service | Released imaging reports (policy-filtered) via FHIR gateway |
| communication-service | diag.radiology.finding.critical events → urgent notification |
| audit-service | All view, launch, and state-change events |
7. Slice Involvement
| Slice | Scope |
|---|
| S0 | PACS endpoint registry, study metadata ingestion, report ingestion |
| S1 | Report lifecycle (prelim/final/amended), viewer launch |
| S2 | HL7 v2 ORM/ORU via interop, structured reporting workflow |
| S3 | Radiologist worklist, dictation integration, WADO-RS advanced retrieval |
8. Key Architectural Decisions
| Decision | Rationale |
|---|
| Pixel data stays in PACS | EHR stores only references/metadata; avoids duplicating large DICOM files |
| FHIR ImagingStudy owned here | Single source for study metadata; gateway routes to this service |
| Chart DiagnosticReport in patient-chart | After radiologist sign-off, the filed report is a chart fact — separate context |
| DICOMweb over custom vendor APIs | Standards-based integration; vendor independence per tenant |
| Signed viewer launch URL | Prevents direct PACS credential leakage to browser |
9. Context Diagram