Posts by wfooshee

I will restate that I do not know who built or configured this server, and that I'm learning it on the fly. I do know that this particular server's only purpose is to forward studies from the numerous modalities at the hospital onward to the night reading company. Nothing comes back from them, as their reports are posted on their web site for the techs to retrieve, and local storage is temporary, managed by the disk cleanup threshold (as best I can tell.....)

When talking to support at the target site, they noted that received folders had a significantly higher number of files than the actual number of images. He suggested that the tech may have been resending when their site had a delay in reporting successful receipt, which he speculated would place multiple copies of the study into the DICOM server, and it would not show complete until ALL copies had transmitted. Today he called back and asked about associations, saying that studies sent closely enough together may be gathered into a single association. For example, 2 or 3 X-rays and a CT scan study wold become a single association, and he suggested looking for ways to break that up and keep it more granular, as an association is not shown as complete until all files within it are received. Thus the small X-ray studies would be unavailable until the 200-plus-image CT scan was complete as well. I do not understand the association process at all, although I understand what he was driving at by ensuring an association contains a single study.

Contents of dicom.ini:

# This file contains configuration information for the DICOM server
# Do not edit unless you know what you are doing

[sscscp]
MicroPACS = sscscp
Edition = Personal

# Network configuration: server name and TCP/IP port#
MyACRNema = RADIUSGW235
TCPPort = 104

# Reference to other files: known dicom servers; database layout; sops
ACRNemaMap = acrnema.map
kFactorFile = dicom.sql
SOPClassList = dgatesop.lst

# Host(ignored), name, username and password for ODBC data source
SQLHost = localhost
SQLServer = C:\Users\user\Desktop\DicomServer\Data\dbase\conquest.db3
Username =
Password =
SqLite = 1
BrowseThroughDBF = 1
DoubleBackSlashToDB = 0
UseEscapeStringConstants = 0

# Configure database
TruncateFieldNames = 10
MaxFieldLength = 254
MaxFileNameLength = 255
FixPhilips = 0
FixKodak = 0
KeepAlive = 60
LargeFileSizeKB = 4096
PrintSquareLandscape = 0
UseKpacsDecompression = 1
ZipTime = 05:
UIDPrefix = 1.2.826.0.1.3680043.2.135.735807.49992919
EnableReadAheadThread = 1
PatientQuerySortOrder =
StudyQuerySortOrder =
SeriesQuerySortOrder =
ImageQuerySortOrder =
EnableComputedFields = 1
IndexDBF = 1
PackDBF = 0
LongQueryDBF = 1000
TCPIPTimeOut = 300
FailHoldOff = 60
RetryDelay = 100
RetryForwardFailed = 0
ImportExportDragAndDrop = 0
QueueSize = 128
WorkListMode = 0
WorkListReturnsISO_IR_100 = 1
DebugLevel = 0
Prefetcher = 0
LRUSort =
AllowTruncate =
DecompressNon16BitsJpeg = 1
UseBuiltInJPEG = 1
LossyQuality = 95
IgnoreOutOfMemoryErrors = 0
NoDICOMCheck = 0
PadAEWithZeros = 0
AllowEmptyPatientID = 0
FileNameSyntax = 4

# Configuration of compression for incoming images and archival
DroppedFileCompression = un
IncomingCompression = un
ArchiveCompression = as

# Names of the database tables
PatientTableName = DICOMPatients
StudyTableName = DICOMStudies
SeriesTableName = DICOMSeries
ImageTableName = DICOMImages
WorkListTableName = DICOMWorkList
DMarkTableName = DICOMAccessUpdates
RegisteredMOPDeviceTable = RegisteredMOPIDs
UIDToMOPIDTable = UIDToMOPID
UIDToCDRIDTable = UIDToCDRID

# Banner and host for debug information
PACSName = RADIUSGW235
OperatorConsole = 127.0.0.1

# Configure email of error messages
MailHost =
MailPort = smtp
MailSignon =
MailFromName =
MailRcptName1 =
MailCollectTime = 1
MailWaitTime = 10

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 100000
MAGDeviceFullThreshHold = 30
IgnoreMAGDeviceThreshold = 0
MAGDevices = 1
MAGDevice0 = C:\users\user\desktop\dicomserver\data\
NightlyCleanThreshhold = 100000

# Configuration of forwarding and/or converter programs to export DICOM slices
ForwardAssociationLevel = *
ForwardAssociationCloseDelay = 5
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 1

ExportConverters = 2
ExportConverter0 = forward to VRAD_012949

ForwardCollectDelay = 600
MaximumExportRetries = 0
MaximumDelayedFetchForwardRetries = 0

I am new to the Conquest DICOM application, and actually new to medical imaging, period.

The IT company I work for has taken on IT support for a local radiology firm. They have a PC running Conquest DICOM Server 1.4.17d to forward studies from the local hospital to an outside reading service at night when no local radiologists are on hand. Upload speed is an issue on this system, as we never see anything more than 1.1 Mb/s.

The studies being uploaded look to to broken into a very large number of very small files, and there is a very high amount of latency in the process of uploading a 512KB file, getting an acknowledgement, proceeding with the next 512KB file, and so on, until all 200, 400, or even 1200 megabytes have been uploaded.

The receiving service has suggested looking into multi-threaded sending. I see that I can specify multiple export converters, but it is unclear whether they can all actually run the same "forward to" going to the same destination. If so, that would appear to give me a multi-threaded send, but if that's not a valid configuration, or perhaps even a dangerous one, I need to know before I make the experiment.

Can I configure multiple export converters with the same task, specifically "forward to AE-whatever," all going to the same AE?