DICOM Network menu, version 3.0.1 Alpha
Current version 3.0.1 Alpha DICOM Network menu screenshot.
Clinical Viewer GUI
DICOM Network Menu
The DICOM Network menu configures DICOM communication for spectrIm-QMRS. It lets the application act as a DICOM network node, receive data from scanner or PACS systems, and organize incoming DICOM files using DICOM tag-based naming rules.
DICOM concepts
DICOM is both a file format and a network protocol. As a file format, a DICOM object stores medical image or spectroscopy data together with metadata tags such as patient, study, series, modality, acquisition geometry, and scanner parameters. These tags are what allow spectrIm-QMRS to identify, sort, display, and relate MR images and MRS(I) data.
As a network protocol, DICOM defines how medical devices exchange those objects. A scanner, PACS, workstation, or spectrIm-QMRS computer can act as a DICOM application entity. Each network node is identified by an AE title, an IP address, and a port number. Both sender and receiver must usually be configured explicitly by the hospital or scanner network administrator.
For a broader clinical overview of what DICOM is and why it matters for spectroscopy, see the DICOM crash course for clinical spectroscopy. For a practical setup sequence, see the DICOM listener workflow page.
Screenshot
DICOM toolbar
Toolbar access to DICOM actions
The DICOM Network menu also has a compact toolbar in the main Clinical Viewer window. It gives direct access to the same practical DICOM operations without opening the top menu first.
Toolbar buttons from left to right
- Mount: mount a DICOM directory and populate the Patient/Study Browser.
- DICOM nodes: configure local and remote DICOM network nodes.
- Listener: open the DICOM listener and renaming control.
- 2 DCM screenshot: write the current Clinical Viewer display as a DICOM Secondary Capture.
- 2 DCM image: convert selected local image files to DICOM Secondary Capture objects.
The Secondary Capture buttons are enabled only when a spectroscopy DICOM examination has been loaded, because the created DICOM objects need patient, study, and UID context.
Clinical DICOM background
DICOM crash course
The DICOM Network menu page documents the practical controls. The crash course explains the clinical reason behind them: why MRS(I) data should be received with patient and study context, why results should be sent back as DICOM formatted objects, and how this connects spectrIm-QMRS processing, ILV simulations, pthreads-TDFDFit fitting, and MRS(I) reporting.
Network configuration
Configure DICOM Network Nodes
Opens the DICOM node configuration dialog. This dialog defines the properties of the local spectrIm-QMRS node and the remote DICOM nodes with which it should communicate, such as MR scanners, PACS systems, or satellite consoles.
For the local host, the essential fields are the IP address,
the DICOM port, and the AE title. The old website used
11112 as an example DICOM port and
SPECTRIM_QMRS_RECEIVE as an example AE title.
The AE title is effectively the DICOM service name by which
the application is known on the clinical network.
DICOM networking normally requires stable addressing. A fixed IP address is preferred because DHCP addresses can change after reboot or reconnection. In a hospital environment, scanner and PACS systems also often refuse unknown DICOM nodes. The spectrIm-QMRS computer must therefore be registered on the sending device, and the remote scanner or PACS node must be configured in spectrIm-QMRS.
Remote nodes
Remote DICOM nodes require at least an AE title, IP address, and port number. A human-readable node name can also be useful, especially when several scanners, PACS endpoints, or research workstations are available.
To be checked manually: add a current screenshot of the node configuration dialog and list the exact v3 alpha fields.
Listener and renaming
DICOM Network Listener and Renaming Control
Opens the listener and renaming control window. In this mode, spectrIm-QMRS can listen for incoming DICOM network traffic and receive DICOM objects sent from a scanner, PACS, or another DICOM-capable workstation.
The step-by-step receiver setup is documented separately on the DICOM listener workflow page.
The renaming control uses DICOM metadata tags to organize the received files. This is useful because DICOM network transfer often produces file names that are technically valid but not convenient for human review. Tag-based renaming can encode study, series, acquisition, or other identifying information in the file or folder structure.
To be checked manually: confirm whether the legacy listener screenshot still matches the version 3.0.1 Alpha control window.
Secondary Capture workflows
Export Clinical Viewer screenshots
The DICOM toolbar can create a DICOM Secondary Capture from the current Clinical Viewer window. The exported object uses the last loaded spectroscopy DICOM examination for patient and study context, derives fresh Series and SOP Instance UIDs, and can be sent to a configured DICOM node or saved to disk.
The illustrated workflow shows the 2 DCM screenshot button, the send/save decision dialog, and the DICOM node selection dialog for sending the screenshot to PACS. Open the Secondary Capture workflow.
DICOM-ize local images
Local PNG, JPEG, BMP, or GIF images can be selected and converted to Secondary Capture DICOM objects. Multiple images can be selected at once; each image is previewed and confirmed unless the user chooses not to ask again for the rest of the batch.
The illustrated 2 DCM image workflow shows the multi-file selection dialog, image preview, send/save decision, and DICOM node selection for PACS transfer. Open the Secondary Capture workflow.
Review mounted Secondary Captures
When a mounted DICOM directory contains Secondary Capture series, double-clicking that series opens the captured image in a separate viewer frame rather than loading it as spectroscopy data.
Workflow details
See the dedicated Secondary Capture DICOM workflow page for the step-by-step user workflow and safety notes.
DICOM implementation
dcm4che / dcm4chee resources
spectrIm-QMRS uses the Java DICOM library ecosystem from
dcm4che for DICOM parsing and network-related tooling. The
current project libraries include mainly dcm4che2
2.0.29 JARs, including dcm4che-core,
dcm4che-net, dcm4che-tool-dcmrcv,
dcm4che-tool-dcmsnd, dcm4che-tool-dcmecho,
and related tools. The project also contains
dcm4che-core-3.3.7.jar and
dcm4che-net-3.3.7.jar.
External references: DICOM Standard, dcm4che DICOM Toolkit & Library, and dcm4chee Archive.
To be checked manually: confirm which of the dcm4che 3.3.7
JARs are actively used at runtime and whether the DICOM Network
listener still depends entirely on dcm4che2 2.0.29.
Relevant dcm4che tools
The bundled dcm4che tools include familiar DICOM command-line
utilities such as dcmrcv for receiving DICOM
objects, dcmsnd for sending objects,
dcmecho for testing associations, and
dcm2xml for inspecting DICOM headers as XML.
These tools are useful both for application functionality and
for diagnosing hospital-network connectivity.
Automatic processing
Activate Automatic Processing
This item is visible in the version 3.0.1 Alpha menu but disabled in the screenshot. It appears to be intended for a future or controlled workflow where incoming DICOM studies can trigger a configured processing action automatically.
To be checked manually: document the enabling conditions, safety checks, and relationship to Processing Actions before describing this as an active clinical workflow.
Practical notes
Hospital network setup
DICOM networking usually requires cooperation with the local network or scanner administrator. The spectrIm-QMRS node must be reachable, firewall rules must allow the chosen DICOM port, and the scanner or PACS must know the receiving AE title, IP address, and port.
Legacy assets
The old DICOM Network help page referenced the common spectrIm
and EU project logos and one DICOM listener screenshot. These
assets have been copied into
assets/img/legacy/dicom-network for traceability.