Application note · Specialised and governed

Application Note: On-Premises Clinical Imaging AI with DICOM and MONAI

A shadow-mode-to-production architecture for DICOM routing, MONAI inference, clinical-format outputs, audit and rollback.

This pattern places an imaging-AI service inside the hospital network without giving the model uncontrolled access to PACS or the ability to overwrite clinical records. It supports research validation, shadow mode and a controlled route toward operational use.

Data path

  1. A DICOM router sends allowlisted studies to an isolated ingress.
  2. The service validates modality, series completeness and required tags.
  3. Transient pixel data is staged to encrypted local NVMe.
  4. A versioned MONAI application performs preprocessing and inference.
  5. Outputs are encoded as approved DICOM objects or a review record.
  6. A separate authorised integration returns results after policy checks.

Platform placement

AxiRelay runs several smaller modality models or replicas. AxiAnvil fits a large 96GB model in one device. AxiCrucible separates validation from operational service and supplies node-level maintenance flexibility. Size against full study size, simultaneous arrivals and p99 latency, not one image.

Model package

Pin the model, transforms, label map, framework, container digest and supported input contract. MONAI Deploy demonstrates DICOM-aware application construction; adapt it to local routing and audit requirements. Reject unsupported series explicitly rather than resizing or coercing silently.

Validation

Evaluate by scanner, protocol, site and population; include missing/corrupted series and out-of-distribution examples. Compare shadow outputs with expert review. Measure sensitivity/specificity or task-appropriate metrics plus calibration, latency, failure rate and clinician disposition.

Safety and operations

Keep a downtime route, health monitoring and one-click rollback. Do not log patient pixels or identifiers in ordinary service metrics. Every model release needs risk review, acceptance evidence and a defined owner. Hyperion provides compute and on-prem control; it does not itself confer medical-device approval.

Primary technical references

References are provided for software architecture and implementation planning. Validate the versions, licences, support matrix and regulated-use requirements applicable to the final deployment.

Relevant Hyperion platforms

Hyperion X1440

AxiRelay

A dense inference, RAG, CI and multi-service node where several independent GPU workloads must run concurrently.

One 4U node; 96 AMD EPYC cores; 768GB ECC DDR5; four NVIDIA RTX PRO 4000 24GB GPUs providing 96GB aggregate VRAM.

Hyperion X1160

AxiAnvil

A large-memory single-GPU platform for private LLM inference, retrieval-augmented generation, medical imaging and large scientific models.

One 4U node; 96 AMD EPYC cores; 768GB ECC DDR5; one NVIDIA RTX PRO 6000 96GB GPU; enterprise NVMe.

Hyperion X2260

AxiCrucible

A two-node multi-user AI workgroup for clinical research, production intelligence, training and resilient service placement.

Two 4U nodes; four NVIDIA RTX PRO 6000 96GB GPUs; 100GbE RDMA; shared protected storage; KVM and Kubernetes-ready infrastructure.

Configuration and quotation

Validate this workload on Hyperion

Final architecture and price depend on representative code and data, concurrency, storage, networking, site infrastructure, component availability and export compliance.

Request Formal Quotation