DicomReceiver 3.1

Works as stand-alone application or is created as needed by other applications
3.1.1 (See all)

Configurable DICOM receiver. Works as stand-alone application or is created as needed by other applications. Creates DICOM part 10 (*.dcm) files in an easily-interpreted directory tree (Patient/Study/Series/Image) so the user does not have to mess around with databases of filenames. Designed to be a singleton object - only one running at a time on the system - so can be shared among simultaneous applications.

Configurable database-less DICOM receiver to catch and store DICOM images on disk. It organizes the directory and file naming structure using informative descriptions rather than just using the obscure UIDs for patient/study/series/image naming.

Databases are a pain for DICOM manipulation since they will quickly get out of sync and do not allow easy and direct access to the files. This receiver provides a good way to organize files. The receive port and file directory is easily configurable. Note for now the receiver accepts any connection and files from anywhere. For testing purposes, the receiver will return a bogus response to a query, but won't report anything about what is on disk, since there is no database to summarize and the files can be located anywhere.

By default, the data will be stored as DICOM Part10 (*.dcm) files under the directory C:\dicomdb, but this location is configurable. Under this directory, the received images are organized into a readable patient/study/series tree structure so no database system is necessary to translate the image identifying information into (typically painful) DICOM disk file names.

Once an incoming connection is made on a communications port/socket, a new thread is created to handle the DICOM data/communication on the socket. That way receiving from simultaneous sources can be better managed, giving better performance.

This receiver is designed such that it can be created on the fly by other applications. In this case, it tries to ensure that all the invoking applications create and/or connect to a single (i.e. singleton) receiver object so it can be shared among simultaneous processes. If desired, this receiver can also create a DicomLogger object to show the detail or debug the DICOM communications between connecting systems.

Info updated on: