DICOM GRID DG Gateway User manual

1
DG Gateway
User Manual
July 2014

2
Table of Contents
Introduction 3
Installation and Sizing 4
Gateway Configurations 5
Component Implementation 17
DICOM Services 21

3
Introduction
DG Gateway is a Windows software application that is both a
DICOM router and an HL7 listener.
Specifically, DG Gateway is used for the following:
To securely send studies from a DICOM device to DG Suite.•
To securely send studies from DG Suite to a DICOM device.•
To securely send HL7 messages from any HL7 sender to DG Suite.•
DG Gateway supports all HL7 v2 versions
To securely send HL7 messages from DG Suite to any HL7 receiver.•
DG Gateway supports the following DICOM protocols:
C-store
C-store is a DICOM push. This is when studies are sent to DICOM
Grid or sent from DICOM Grid.
When studies are sent to DICOM Grid, base DG Gateway
functionality is used (the storage folder) or the Dropbox functionality is
used.
When studies are sent from DICOM Grid to a DICOM destination,
base DG Gateway functionality is used (the storage folder). In order
to send to a DICOM device, the DICOM device must be configured
as a destination (port, ae title, and ip) in the DG application. Also,
in the receiving DICOM device, DG Gateway must be configured as
a valid sender. Typically, this includes the port, ae title, and ip of the
DG Gateway
C-find
The query part of the query retrieve service.
C-move
The retrieval part of the query retrieve service. In order for a
DICOM device to retrieve from DICOM Grid, the DICOM device
must be configured as a destination (port, ae title, and ip) in the DG
application.

4
Installation and Sizing
The DG Gateway application is a Windows software application installed on a gateway server,
workstation, or virtual machine that securely links an entity’s physical local area network to DG
Suite. DG Gateway communicates with DICOM devices (PACS, modalities, workstations, etc.) to
send and receive medical images across the network. DG Gateway is downloaded from within
DG Suite. To access the installation file, go to Administration > [Your Account] > Gateways > click
the blue Download Gateway Software button in the top right.
It is important to size the gateway server appropriately. Server sizing guidelines are:
2 Threads
4GB of RAM
500GB thin provisioned or 100GB thick
provisioned for the OS, 400GB thin provisioned
for the Gateway Drive
Appliance
Appliance
Appliance
VM
Provided by you
VM
Provided by you
VM
Provided by you
Low-Use Under 6GB (~60 100MB) studies per day
High-Use Over 80GB (~800 100MB) studies per day
Mid-Use 6 to 80GB (~60 to 800 100MB) studies per day
i3-4010U processor
8GB DDR3 RAM
120GB SSD
Gigabit ethernet
Displayport and HDMI out
Windows 7 Professional 64 Bit OEM
Onsite NBD Warranty with 8/5 support 3 years
4-12 Threads
8GB-16GB of RAM
100GB OS thick Provisioned -
500GB thin provisioned for the Gateway drive,
Medium IOP requirement
1u form factor
Intel E5-2620V2 6C/12T 2.1Ghz 15mb Cache
16GB 1600MHz ECC DDR3 RAM
2 500GB Samsung 840 Series SSDs
2 Seagate 4TB 7.2k RPM SATA3 Drives
1 LSI 9271-4i with CacheVault and BBU
Onsite NBD Warranty with 24/7 support 3 years
1 Windows Server 2012 Standard x64 OEM
12-24 Threads
16-32GB of RAM
100GB OS thick provisioned -
1.5TB thin provisioned for the Gateway drive,
High IOP requirement
2u form factor
2 Intel E5-2620v2 6C/12T 2.1GHz 15mb Cache
32GB 1600MHz ECC DDR3 RAM
4 500GB Samsung 840 Serles SSDs
3 Seagate 4TB 7.2k RPM SATA3 Drives
1 LSI 9271-8i with CacheVault and BBU
Onsite NBD Warranty with 24/7 support 3 years
1 Windows Server 2012 Standard x64 OEM

5
Gateway Configurations
To access, go to Administration > [Your Account] > Gateways > Edit
Gateway name
A custom name for the Gateway.
Type
Always Gateway. Never changed.
ae_title
The calling application entity title of the Gateway. Default is “DG_HARVESTER”.
allow_duplicates
Obsolete
ccis_study_update_override
Obsolete
client_malingering_timeout
Timeout period in decimal minutes from last activity before aborting an inactive DICOM association
from a client. Default is 10 minutes.
create_phantoms
A true/false value that determines whether the gateway should create a phantom for the study
before the upload. Default is false.
custom_queue_max_attempts
JSON array of key/value pairs where the key(s) are “queuename_max_attempts”. The integer value
for each key sets the maximum number of attempts that queue will try to process a given queue
item. Defaults to 20 for all queues not specifically set.
All possible queue names:
download•
downloadtranscode•
hl7client•
hl7upload•
move•
queryclient•
retrieveclient•
upload•
uploadtranscode•
Sample:
{
‘hl7upload_max_attempts’:’100’,
‘moveclient_max_attempts’:’20’
}

6
custom_queue_retry_coefficient
JSON array of key/value pairs where the key(s) are “queuename_retry_coefficient”. The decimal
value for each key sets a factor used to determine the delay in seconds before subsequent retry
attempts. The retry delay is determined by the number of attempts cubed times the retry coefficient
value; i.e.: [retry delay] = [retry count]**3 x [retry coefficient]. Defaults to 10 for all queues not
specifically set.
All possible queue names:
download•
downloadtranscode•
hl7client•
hl7upload•
move•
queryclient•
retrieveclient•
upload•
uploadtranscode•
Sample:
{
‘hl7upload_retry_coefficient’:’10’,
‘download_retry_coefficient’:’5’,
‘queryclient_retry_coefficient’:’20’
}
destination_push_rules
JSON hash of all custom settings for pushing studies to specific destinations. Used to give fine-
grained control over what images get pushed to a destination during subsequent pushes of the
same study. If the given AE, port and IP address match the study’s destination AE, port and IP
address, then these custom settings are applied to the push. Not set by default, which results in
the default values listed below being used to push the study to the destination’s AE, port and IP
address.
All possible settings for each defined destination (All are required. Any missing or invalid settings
for a destination will result in default settings for all values for that destination):
address: IP address of the destination•
port: Port of the destination•
aetitle: AE Title of the destination•
automated_study_push_cutoff_in_minutes: For automated (via routing rules) study pushes to this•
destination, this is the decimal cutoff time in minutes after the initial study push determining
whether the “automated_before_cutoff” or the “automated_after_cutoff” behavior should
be enforced for subsequent pushes of the same study. Default is 2 minutes.
user_requested_study_push_cutoff_in_minutes: For manual or user requested (via web) study•
pushes to this destination, this is the decimal cutoff time in minutes after the initial study
push determining whether the “user_requested_before_cutoff” or the “user_requested_after_
cutoff” behavior should be enforced for subsequent pushes of the same study. Default is 2
minutes.
automated_before_cutoff: Behavior to be enforced for automated (via routing rules) subsequent•
pushes of the same study to this destination BEFORE the cutoff time defined by “automated_
study_push_cutoff_in_minutes” has been reached. Default is “REPUSH_UPDATES_ONLY”.
automated_after_cutoff: Behavior to be enforced for automated (via routing rules) subsequent•
pushes of the same study to this destination AFTER the cutoff time defined by “automated_
study_push_cutoff_in_minutes” has been reached. Default is “REPUSH_UPDATES_ONLY”.
user_requested_before_cutoff: Behavior to be enforced for manual or user requested (via web)•
subsequent pushes of the same study to this destination BEFORE the cutoff time defined by
“user_requested_study_push_cutoff_in_minutes” has been reached. Default is “REPUSH_

7
ALL”.
user_requested_after_cutoff: Behavior to be enforced for manual or user requested (via web)•
subsequent pushes of the same study to this destination AFTER the cutoff time defined by
“user_requested_study_push_cutoff_in_minutes” has been reached. Default is “REPUSH_
ALL”.
All valid values for “automated_before_cutoff”, “automated_after_cutoff”, “user_requested_before_
cutoff” and “user_requested_after_cutoff” settings (not all are required):
REPUSH_ALL: Re-push all study images regardless of prior push attempts.•
REPUSH_UPDATES_ONLY: Re-push any updated images for the study, which includes new•
images for the study and existing images that have been modified in any way.
PUSH_NEW_IMAGES_ONLY: Push only new images for the study.•
NEVER_REPUSH_STUDY: Do not push or re-push any study images regardless of prior push•
attempts.
Sample:
{
“destinations”: [
{
“address”: “127.0.0.1”,
“port”: “5104”,
“aetitle”: “CCIS”,
“automated_study_push_cutoff_in_minutes”: “1”,
“user_requested_study_push_cutoff_in_minutes”: “3”,
“automated_before_cutoff”: “REPUSH_UPDATES_ONLY”,
“automated_after_cutoff”: “PUSH_NEW_IMAGES_ONLY”,
“user_requested_before_cutoff”: “NEVER_REPUSH_STUDY”,
“user_requested_after_cutoff”: “REPUSH_ALL”
},
{
“address”: “127.0.0.1”,
“port”: “1044”,
“aetitle”: “CCW”,
“automated_study_push_cutoff_in_minutes”: “10”,
“user_requested_study_push_cutoff_in_minutes”: “3”,
“automated_before_cutoff”: “REPUSH_ALL”,
“automated_after_cutoff”: “REPUSH_UPDATES_ONLY”,
“user_requested_before_cutoff”: “REPUSH_ALL”,
“user_requested_after_cutoff”: “REPUSH_ALL”
}
]
}
dicom_buffer_size
Obsolete
disk_management
JSON array of key/value pairs for all disk management settings. Not set by default, which results in
the use of the default values for each setting given below.
All possible settings (not all are required):
dm_run_interval_minutes: Interval in decimal minutes between executions of the disk•
management process. Default is 1 minute.
dm_upload_retention_minutes: Minimum time in decimal minutes to retain data in Storage folder.•
Used to prevent duplicate images being processed and uploaded during this retention
period. Note that data in the storage folder is never deleted if not uploaded to the cloud.
Default is 240 minutes (4 hours).
dm_download_retention_minutes: Minimum time in decimal minutes to retain data in Download•
folder. Used to prevent unnecessary duplicate downloads of studies/images for multiple
DICOM study pushes during this retention period. Default is 240 minutes (4 hours).

8
Sample:
{
“dm_run_interval_minutes”:1.0,
“dm_upload_retention_minutes”:5.0,
“dm_download_retention_minutes”:5.0
}
do_local_push
A true/false value that determines whether the gateway should push the raw study images received
directly to any destinations before (or concurrently with) uploading to the cloud. NOTE: Local
pushes REQUIRE that “create_phantoms” be set to “true”. Default is false.
download_image_max_threads
For each study being downloaded, the maximum number of images to download concurrently to
the gateway from the cloud. Default is 10 images.
download_max_threads
The maximum number of studies to download concurrently to the gateway from the cloud. Default
is 5 studies. Setting “download_max_threads” to 0 or less will disable the download component
entirely and block the normal flow of data through the gateway.
download_root_path
The local directory path where downloaded images are stored before being pushed to the
destination. Default is “C:\Program Files\DICOMGrid\Download”.
dropbox_batch_size
The maximum number of images to be processed by the Dropbox per execution as defined by the
dropbox_search_interval configuration.
dropbox_disabled_times
Used to set the peak time windows for each day of the week during which the Dropbox is disabled.
Setting the time to the same value (ie ‘0-0’) means this is no peak time for that day. Setting the
time to 0-2400 means it is always peak time for that day. Sample: ‘SU:0-0;MO:930-1630;TU:930-
1730;WE:930-1630;TH:930-1630;FR:930-1630;SA:0-0
dropbox_root_path
The local directory path to place DICOM studies/images to be ingested by the Dropbox feature.
Note that the “Query_Retrieve_Dropbox” folder for processing bulk Query/Retrieve files is
automatically placed at the same level as the “Dropbox” folder. Default is “C:\Program Files\
DICOMGrid\Dropbox”.
dropbox_search_interval
The interval in milliseconds that the gateway checks the dropbox_root_path for the existence of
DICOM files prior to processing. Default is 10000 (10 seconds).
dropbox_temp_path
The local directory path where DICOM files are temporarily stored by the Dropbox feature during
processing. Default is “C:\Program Files\DICOMGrid\Dropbox_Temp”.
enable_gzip
A true/false value that enables the compression of DICOM images during uploading to the cloud

9
and downloading from the cloud. Note that compression affects performance and, depending on
the image type and existing compression, may not reduce the image file sizes. Default is true.
filestream_sop_classes
A comma-separated list of SOP class UIDs which should be streamed to disk (rather than only in
memory) upon receipt by the gateway due to the large size of the images. This prevents out-of-
memory exceptions and additional SOP classes with very large image sizes should be added to
this configuration as they are discovered. Default is “1.2.840.10008.5.1.4.1.1.12.1,1.2.840.10008.5
.1.4.1.1.12.2”.
hl7_accession_field
Obsolete
hl7_listening_ports
The designated local port used for HL7 communication by the gateway. Default is 12000.
hl7_spec_validation
A true/false value that determines whether the gateway should perform validation on HL7
messages that are received before uploading them to the cloud. The default is true.
implementation_version_name
The DICOM implementation version name for the gateway. Should never be changed. Set to
“1.2.840.10008.052007.0.7.1.3”.
implementation_version_uid
The DICOM implementation version UID for the gateway. Should never be changed. Set to
“DGSTORESCPV3”.
ingress_filter
A JSON hash of all custom settings to define which images received by the gateway should be
filtered out (ie not processed or uploaded) based on the given evaluation of the value contained in
the element specified. Not set by default and therefore disabled.
All possible settings for each defined filter (All are required. Any missing or invalid settings
anywhere in the JSON hash will result in the disabling of ingress filters for the gateway.):
groupElement: The DICOM tag to filter on.•
evaluation: The condition for evaluation of the DICOM tag value versus the given ‘value’.•
Supported evaluation types (Note that any other input evaluation will result in the image
always NOT being filtered out):
‘==’ : values are equal◦
‘!=’ : values are not equal◦
value: The value to compare to the DICOM tag value.•
Sample:
{
‘filters’:[
{
‘groupElement’:’0008,1030’,
‘evaluation’:’==’,
‘value’:’OUT MRI - NEURO’
},
{
‘groupElement’:’0008,1030’,

10
‘evaluation’:’==’,
‘value’:’OUTSIDE MRI NEURO’
},
{
‘groupElement’:’0008,0060’,
‘evaluation’:’==’,
‘value’:’OX’
}
]
}
listening_ports
The designated local port(s) used for DICOM communication by the gateway. Default is
“104,4006”.
local_storage_vm
Services value. Not used by gateway.
logging_levels
A comma-separated list of log levels to be applied to each of the loggers used by the gateway,
which include “root”, “DICOMlogger”, “rabbitlogger”, “healthlogger”, in that order. Note that
inputting a single log level value will apply that log level to all four loggers. Default is “INFO”.
All possible log levels:
DEBUG•
INFO•
WARN•
ERROR•
FATAL•
Samples:
“INFO,WARN,DEBUG,INFO” (without quotes) will set log levels as follows: root=INFO,
DICOMlogger=WARN, rabbitlogger=DEBUG, healthlogger=INFO
or
“INFO” (without quotes) will set log levels as follows: root=INFO, DICOMlogger=INFO, rabbitlogger=INFO,
healthlogger=INFO
max_clients
Obsolete
max_pdu_size
Sets the maximum PDU size in the DICOM associations. Rarely changed. Default is 65536.
max_records_per_ping
Services value. Not used by the gateway, but limits the number of data records returned to the
gateway by services in a single ping. Rarely changed. Default is 100 records.
move_client_max_threads
The maximum number of studies to move concurrently from the gateway to a destination. Default is
5 studies. If no value is input or value is invalid, default is 10 images. Setting “move_client_max_
threads” to 0 or less will disable the move_client component entirely and block the normal flow of
data through the gateway.

11
ping_interval
The interval, in milliseconds, that the gateway attempts to confirm basic communication with, and
receive instructions from, the cloud. Default is 10000 (10 seconds).
pipe_hl7_to_destination
Services value. Not used by the gateway directly, but used by services to route HL7 to an arbitrary
destination.
qr_default_request_ae
Sets the default AE Title from which the gateway should try to retrieve studies when receiving a
receive request from services. Used when services broadcasts out retrieve requests to all gateways
within an organization, yet it is desired that the retrieves be made only from the specified
destination for this gateway. By default, this value is not set and all retrieve requests are processed.
query_retrieve
JSON array of key/value pairs for all settings required to activate automated query/retrieve, which
enables the gateway to automatically (on a schedule) query for studies from a DICOM device
(normally a PACS) and optionally retrieve studies from that device if they do not already exist on
the grid. Used for regular querying and retrieving at customer sites which do not automatically push
studies into a gateway, and also to collect historical archived data from a customer site. Not set by
default and therefore disabled.
All query/retrieve settings:
qr_scheduler_enabled: Enable scheduled querying of studies? FALSE by default•
qr_retrieve_enabled: Enable retrieval of studies which were queried by the scheduler?•
qr_min_retrieve_delay: Minimum delay in seconds between initiating retrieves. Single value okay•
for all times, or ‘int,int’ for ‘Peak,OffPeak’ times.
qr_max_query_timespan: Queries over a large timespan are broken down into individual queries•
of this max timespan (to avoid truncating results)
qr_max_concurrent_retrieves: Maximum number of studies that will be concurrently retrieved from•
the PACS
qr_retrieve_timeout_minutes: Timeout in minutes after which a retrieve will be considered to have•
failed
qr_scheduler_dest_ae: PACS AE title•
qr_scheduler_dest_address: PACS IP address•
qr_scheduler_dest_port: PACS port•
qr_scheduler_process_odd: Flag to process odd-ending UIDs (enables load balancing)•
qr_scheduler_process_even: Flag to process even-ending UIDs (enables load balancing)•
qr_peaksystemloadtimes: ‘0-2400’ => always peak, but if both numbers the same => never peak•
qr_customalgenabled: Enable custom image count algorithm to account for series/image count•
returned by PACS?
qr_retrievenewstudiesfirst: Enable ordering of retrievals so newest studies are retrieved first?•
qr_dbselectlimit: Limit for results when selecting from local QR database•
qr_completeonpacs_interval: Delay in seconds between checks for new studies on PACS ready•
to be processed
qr_scheduler_timer_interval: Interval in milliseconds for executing the QR scheduler process.•
1000 by default
qr_retrieve_timer_interval: Interval in milliseconds for executing the QR retrieval process. 1000•
by default
qr_pendingretrieval_interval: Delay in seconds between checks for studies ready to be retrieved•
qr_pendingverification_interval: Delay between checks for studies verified to have been•
successfully harvested
qr_schedule: Defines any number of individual query processes which query the device on•
regular intervals. Each process is delimited by ‘|’ and contains 5 ‘;’ delimited fields. Field
#1 is the datetime to start executing the query process. Field #2 is the time between each
run of the query process in days.hours:minutes:seconds. Field #3 is the datetime defining

12
the end time of the query (if in the future, uses current time). Field #4 is the timespan to
query back from Field #3 in days.hours:minutes:seconds. Field #5 is a flag whether to run
the process just once (0... note this nullifies Field #2) or continuously (1).
Sample:
{
‘qr_scheduler_enabled’:’true’,
‘qr_retrieve_enabled’:’true’,
‘qr_min_retrieve_delay’:’60,10’,
‘qr_max_query_timespan’:’4:00:00’,
‘qr_max_concurrent_retrieves’:’3’,
‘qr_retrieve_timeout_minutes’:’30’,
‘qr_scheduler_dest_ae’:’CCIS’,
‘qr_scheduler_dest_address’:’127.0.0.1’,
‘qr_scheduler_dest_port;’:’5104’,
‘qr_scheduler_process_odd’:’true’,
‘qr_scheduler_process_even’:’true’,
‘qr_peaksystemloadtimes’:’SU:1100-1100;MO:930-1630;TU:930-930;WE:930-1630;TH:930-1630;FR:930-
16 30; SA:110 0 -110 0 ’,
‘qr_customalgenabled’:’TRUE’,
‘qr_retrievenewstudiesfirst’:’TRUE’,
‘qr_dbselectlimit’:’20’,
‘qr_scheduler_timer_interval’:’1000’,
‘qr_retrieve_timer_interval’:’1000’,
‘qr_completeonpacs_interval’:’10’,
‘qr_pendingretrieval_interval’:’1’,
‘qr_pendingverification_interval’:’300’,
‘qr_schedule’:’5/26/2011 00:00:00;0.0:1:0;1/1/2050;30.0:00:0;0|5/26/2011 00:00:00;0.0:10:0;1/1/2050
;0.2:00:0;1|5/26/2011 00:15:00;0.0:30:0;1/1/2050;0.8:00:0;1|5/26/2011 20:00:00;1.0:00:0;1/1/2050;7.
0:00:0;1|5/27/2011 22:00:00;7.0:00:0;1/1/2050;28.0:00:0;1’
}
queue_recovery_interval
The amount of time in milliseconds between attempts by the gateway to recover HL7 messages that
failed to process and DICOM images that failed to upload. Default is 600000 (10 minutes). If value
is not set or value is invalid, default is 3600000 (1 hour).
remote_logging
Not yet implemented.
services_delay_seconds
Services value. Not used by the gateway. Sets the delay in seconds before services will send a
study push request to the gateway. Used mainly to ensure studies are complete before pushing into
a destination. Default is 0 seconds.
storage_commitment_timeout
The length of time in minutes to maintain images in the storage committment database. Disabled by
setting to null or 0, which is the default. Note that this is rarely used, if at all.
storage_root_path
The local directory path where DICOM files are stored when received by the gateway and then
uploaded to the cloud. Default is “C:\Program Files\DICOMGrid\Storage”.
store_clients_enabled
A comma-separated list of DICOM libraries to be used when pushing studies to a destination. This
is useful when either the MyDICOM library (denoted “DG”) or the Clear Canvas library (denoted
“CC”) fail to push a particular study. Default is “DG,CC”.

13
All possible settings (without quotes):
“DG,CC” : Try MyDICOM library first, then Clear Canvas library for any images that failed to•
push.
“CC,DG” : Try Clear Canvas library first, then MyDICOM library for any images that failed to•
push.
“DG” : Only push studies using the MyDICOM library.•
“CC” : Only push studies using the Clear Canvas library.•
store_commit_ttl
Obsolete
study_done_timeout
The minimum wait time in minutes before processing a local push to ensure all images have been
received, even if via multiple associations. Useful because local pushes only occur on initial study
receipt. Study updates cannot use local push and require the study to be routed through the cloud
before it can be pushed. Default is 0, but any value less than 0.1 results in a minimum setting of 0.1
(6 seconds).
submit
An administrative setting. Should never be changed.
transcode_max_threads
The maximum number of images to transcode concurrently. Applies to both upload and download
transcoding. Note that transcoding is CPU intensive. Default is 2 images. Setting “transcode_max_
threads” to 0 or less will disable the transcode components entirely and block the normal flow of
data through the gateway.
transcode_tsns
A JSON hash of all custom settings to define which image transfer syntax types should be
transcoded by the gateway. There is an “upload” section for defining transcoding rules before
uploading the images to the cloud, and a “download” section for defining transcoding rules after
downloading images from the cloud. Not set by default and therefore disabled.
All possible settings for each defined transcoding rule (Only “input_tsn” and “output_tsn” are
required for each rule. However, if a “conditions” field is declared for an input/output combo,
then that conditions array must contain “parameter”, evaluation” AND “value” fields. Any missing
or invalid settings anywhere in the JSON hash will result in the disabling of both upload and
download transcoding for the gateway.):
conditions: Optional, but defines a set of “parameter”, evaluation” and “value” fields to use to•
determine whether to transcode the given “input_tsn” to the given “output_tsn”. Multiple
conditions can be applied to the same rule. If no “conditions” section exists then all images
of “input_tsn” transfer syntax will attempt to be transcoded to the “output_tsn” transfer
syntax.
parameter: The DICOM tag to evaluate. For upload transcoding, this field may◦
optionally contain either “sourceae” or “filesize” rather than a DICOM tag for
evaluating whether to transcode based on the DICOM source AE Title or image
filesize, respectively. For download transcoding, this field may optionally contain
“destinationae” rather than a DICOM tag for evaluating whether to transcode
based on the destination AE Title.
evaluation: The condition for evaluation of the “parameter” value versus the given◦
“value”. Supported evaluation types (Note that any other input evaluation will result
in the image always NOT being transcoded):

14
‘==’ : “parameter” and “value” are equal◦
‘!=’ : “parameter” and “value” are not equal◦
‘<’ : “parameter” is less than “value”◦
‘<=’ : “parameter” is less than or equal to “value”◦
‘>’ : “parameter” is greater than “value”◦
‘>=’ : “parameter” is greater than or equal to “value”◦
value: The value to compare to the “parameter” value.◦
◦
Transcoding to/from DICOM-wrapped mp4 (H.264) is enabled by using “dcm-mp4”◦
in place of a transfer syntax UID. Transcoding DICOM-wrapped AVI files uploaded
via the web uploader are automatically and always transcoded upon download into
Ultrasound Multi-frame Image Storage Explicit VR Little Endian. No transcode settings in
the gateway configurations are necessary for this.
◦
For more granular control, the “input_tsn” value can also be in the format “abstract◦
syntax:transfer syntax”. This enables only the specified abstract/transfer syntax
combination to get transcoded.
◦
Transcoding downloaded DICOM-wrapped mp4 is configured with a download◦
transcode rule with “input_tsn” set to “1.2.840.10008.5.1.4.1.1.3.1:1.2.840.10008.1.2
.1” (the default abstract and transfer syntaxes for DICOM-wrapped mp4 files) and the
“output_tsn” set to “dcm-mp4”. Note this is somewhat inconsistent with the normal format
since the final abstract/transfer syntax of these files will actually be Ultrasound Multi-
frame Image Storage Explicit VR Little Endian as stated above.
◦
Sample:
{
“upload”:[
{
“input_tsn”:”1.2.840.10008.5.1.4.1.1.3.1:1.2.840.10008.1.2.4.50”,
“output_tsn”:”dcm-mp4”
},
{
“input_tsn”:”1.2.840.10008.1.2.1”,
“output_tsn”:”1.2.840.10008.1.2.4.57”,
“conditions”:[
{
“parameter”:”0008,0050”,
“evaluation”:”==”,
“value”:”2043”
}
]
},
{
“input_tsn”:”1.2.840.10008.1.2.2”,
“output_tsn”:”1.2.840.10008.1.2.4.70”,
“conditions”:[
{
“parameter”:”sourceae”,
“evaluation”:”==”,
“value”:”OUTSIDE”
},
{
“parameter”:”0008,1030”,
“evaluation”:”==”,
“value”:”anonymized description”
}
]
},
{
“input_tsn”:”1.2.840.10008.1.2.1”,
“output_tsn”:”1.2.840.10008.1.2.4.70”,

15
“conditions”:[
{
“parameter”:”filesize”,
“evaluation”:”>”,
“value”:”1000000”
},
{
“parameter”:”0008,1030”,
“evaluation”:”==”,
“value”:”anonymized description”
}
]
},
],
“download”:[
{
“input_tsn”:”1.2.840.10008.5.1.4.1.1.3.1:1.2.840.10008.1.2.1”,
“output_tsn”:”dcm-mp4”
},
{
“input_tsn”:”1.2.840.10008.1.2”,
“output_tsn”:”1.2.840.10008.1.2.4.70”,
“conditions”:[
{
“parameter”:”destinationae”,
“evaluation”:”==”,
“value”:”CCW”
}
]
},
{
“input_tsn”:”1.2.840.10008.1.2.4.91”,
“output_tsn”:”1.2.840.10008.1.2.4.70”,
“conditions”:[
{
“parameter”:”destinationae”,
“evaluation”:”==”,
“value”:”CCW”
}
]
},
{
“input_tsn”:”1.2.840.10008.1.2.4.70”,
“output_tsn”:”1.2.840.10008.1.2.1”,
“conditions”:[
{
“parameter”:”0008,0090”,
“evaluation”:”!=”,
“value”:”TEST VALUE”
},
{
“parameter”:”0002,0010”,
“evaluation”:”==”,
“value”:”1.2.840.10008.1.2.4.70”
}
]
},
{
“input_tsn”:”1.2.840.10008.1.2.4.91”,
“output_tsn”:”1.2.840.10008.1.2.1”
}
]
}

16
type
Always Harvester. Should never be changed.
upload_max_threads
The maximum number of concurrent image uploads by the gateway to the cloud. Default is 5
images. If no value is input or value is invalid, default is 10 images. Setting “upload_max_threads”
to 0 or less will disable the upload component entirely and block the normal flow of data through
the gateway.
use_all_transfer_syntaxes
Enables the gateway to use an extended set of DICOM transfer syntaxes when pushing images
to DICOM destinations. This maximizes the chances of finding an acceptable abstract/transfer
syntax combo to the destination, but should only be enabled where needed since it adds significant
overhead to the DICOM association. Default is false.
use_clearcanvas_store_scu
Obsolete

17
Component Implementation
Ping Worker
You can think of the Ping Worker as the heartbeat of the gateway. Currently there is only a single
command which comes from the cloud via the ping command. This command is a command that
tells the system to download a set, or sets, of studies. Once downloaded the system will move the
data to the destination specified in the ping command.
DropBox
The DropBox is a drop box for DICOM files. When a file is placed in to the drop box path the
system will, at a configurable interval, upload any valid DICOM files to the namespace of the given
Gateway. Any non-DICOM files placed in the DropBox folder will be deleted The Dropbox can
be temporarily disabled during peak times using the ‘dropbox_disabled_times’ configuration as
described in the Gateway Configurations section.
Query/Retrieve DropBox
As of the August 21, 2013 release, a ‘Query_Retrieve_Dropbox’ folder is also available at the
same level as the existing ‘Dropbox’ folder. Only .csv files placed in the ‘Query_Retrieve_Dropbox’
folder are processed, and they are deleted immediately afterward. The ‘Query_Retrieve_Dropbox’
folder is examined for new .csv files at the same frequency as the normal ‘Dropbox’ folder for
images. The records in the .csv file must contain the following 14 comma-separated fields:
IPAddress,Port,AETitle,StudyUid,AccessionNumber,StudyDateTimeRange,PatientId,PatientName,Date
OfBirth,PatientSex,Modality,ReferringPhysician,InstitutionName,StudyDescription
IPAddress, Port and AETitle are required fields. In order to prevent unintended excessive study
retrievals, the record must contain at least one of the following fields: StudyUid, AccessionNumber,
PatientId, PatientName, ReferringPhysician. All fields are exact matches only-- no wildcards.
Validation is performed on some of the fields. All study results from each query are queued up for
automatic retrieval via the RetrieveClient, so care should be taken to avoid duplication.
Invalid records are ignored and logged. In the following test .csv file, only the last record is invalid
because it doesn’t contain one of the required fields:
127.0.0.1,1044,CCW,,1009,,,,,,,,,
127.0.0.1,1044,CCW,1.3.6.1.4.1.25403.158234509605.9228.20120723015358.1,1008,,1008,,,,,,,
127.0.0.1,1044,CCW,1.3.6.1.4.1.25403.158234509605.9228.20120723015356.1,1007,,1007,Pat10 07^Ano
ny1007,,,,,,
127.0.0.1,1044,CCW,1.3.6.1.4.1.25403.158234509605.9228.20120723015354.1,10 06,,1006,Pat1006^An
ony1006,19580204,,,,,
127.0.0.1,1044,CCW,,,,1008,Pat1008^Anony1008,19360703,M,,,,
127.0.0.1,1044,CCW,,,,,,19360703,,,,,
Windowing can be used with the QR Dropbox to control retrieves during on-peak and off-peak
hours. When activated, retrieves are disabled during the on-peak hours. Queries continue to
execute. To turn on windowing, set the gateway config “query_retrieve” to the following with the
desired peak times for each day:
{
‘qr_peaksystemloadtimes’:’SU:1100-1100;MO:1030-1830;TU:930-930;WE:930-1630;TH:930-1630;FR:930-
16 30; SA:110 0 -110 0 ’
}
Note that if the automated query/retrieve scheduler is already enabled for regular, periodic
querying and retrieving of studies from a device into the gateway, then windowing for the QR
Dropbox is disabled.

18
HL7 Dropbox
An ‘HL7_Dropbox’ folder is also available at the same level as the Dropbox folder. The HL7
Dropbox will process any HL7 messages stored as text files that are copied into this folder in the
same manner as if the HL7 message were received via the gateway’s HL7 Listener. Valid HL7
messages are uploaded to the gateway’s account and deleted, while files that do not contain valid
HL7 messages are simply deleted.
Disk Management
The Disk Management component runs on a timer and removes unneeded gateway data when
appropriate. The run interval is configurable as are the retention times for data in the Storage and
Download folders. The default retention times are 4 hours each. Note that data maintained in the
Storage folder prevents duplicates from being processed and uploaded by the gateway, a common
problem at some sites. See the configuration section for a sample “disk_management” configuration
in json format.
Upload
The Upload component is responsible for uploading DICOM files to the grid. It takes a queue item
containing the location of a file to be uploaded to the Grid. The upload component, when invoked,
will capture this file and stream it up to the cloud. GZip compression is supported for uploads.
Download
The Download component is responsible for ensuring that the DICOM files of a study that has been
requested to be pushed to a destination are all available locally. Normally this means it retrieves
DICOM images from the grid via a download. However, in the case of a ‘local push’, the download
component identifies the local images in the Storage folder to be pushed and enqueues their
information onto the harvester.move_client queue for pushing.
UploadTranscode
The UploadTranscode component converts images into a desired transfer syntax prior to uploading
the image to the grid. The UploadTranscode queue is always utilized before the Upload queue
but only acts upon the DICOM images when it has been properly configured in the gateway
configuration “transcode tsns” (see DownloadTranscode below for sample configuration value).
The maximum number of concurrent upload transcoding threads can be set with the gateway
configuration “transcode_max_threads” (the default is 2). Setting “transcode_max_threads” to 0 or
less will disable the transcoding components entirely and block the normal flow of data through the
gateway. See the configuration section for a sample upload transcode configuration in json format.
To enhance upload performance, the UploadTranscode component is bypassed when upload
transcoding has not been configured.
DownloadTranscode
The DownloadTranscode component converts images into a desired transfer syntax just
prior to pushing the image to a destination. It effectively replaces the “pushtool” service.
The DownloadTranscode queue and the component itself is only enabled when the gateway
configuration “transcode tsns” contains at least one valid “download” section as shown below. This
configuration is very flexible, enabling both upload and download transcoding to and from any
supported transfer syntaxes, with conditional filtering based on any DICOM tag or the file size or
source AE Title (in the case of upload transcoding) or any DICOM tag or destination AE title (in the
case of download transcoding). The maximum number of concurrent transcoding threads can be
set with the gateway configuration “transcode_max_threads” (the default is 2). Setting “transcode_
max_threads” to 0 or less will disable the transcoding components entirely and block the normal
flow of data through the gateway. Note that either the “upload” section or the “download” section
of “transcode_tsns” can be left out if either of those components are to be disabled. See the

19
configuration section for a sample download transcode configuration in json format.
The following most common transfer syntaxes are suggested for transcoding:
Uncompressed:
1.2.840.10008.1.2 Implicit VR Little-endian
1.2.840.10008.1.2.1 Explicit VR Little-endian
1.2.840.10008.1.2.2 Explicit VR Big-endian
Compressed:
1.2.840.10008.1.2.4.50 JPEG Baseline (Process 1)
1.2.840.10008.1.2.4.51 JPEG Extended (Process 2 & 4)
1.2.840.10008.1.2.4.55 JPEG Full Progression, Non-Hierarchical (Process 10 & 12) (Retired)
1.2.840.10008.1.2.4.57 JPEG Lossless, Non-Hierarchical (Process 14)
1.2.840.10008.1.2.4.58 JPEG Lossless, Non-Hierarchical (Process 15) (Retired)
1.2.840.10008.1.2.4.70 JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14
[Selection Value 1])
1.2.840.10008.1.2.4.80 JPEG-LS Lossless Image Compression
1.2.840.10008.1.2.4.81 JPEG-LS Lossy (Near-Lossless) Image Compression
1.2.840.10008.1.2.4.90 JPEG 2000 Image Compression (Lossless Only)
1.2.840.10008.1.2.4.91 JPEG 2000 Image Compression
Query/Retrieve Scheduler
The Query/Retrieve Scheduler provides a way for a gateway to automatically (on a schedule)
query for studies from a destination (normally a PACS) and optionally retrieve studies if they do not
already exist on the grid. It replaces the capability formerly provided in V1 by the ‘Query/Retrieve
Service’. Aside from regular querying and retrieving from customers which do not automatically
push studies into a gateway, the Query/Retrieve Scheduler is also used to collect historical archived
data from a customer site. The Query/Retrieve Scheduler determines individual queries that need
to be made and enqueues them onto the QueryClient and then uses the RetrieveClient queue to
retrieve them as needed. The Query/Retrieve Scheduler performs the following main tasks:
breaks configuration-defined query processes into smaller individual queries (to avoid truncation•
of results by the PACS) and enqueues them onto the QueryClient queue
after the queries are executed, excludes studies that have already previously been queried and/•
or processed
studies that have been previously processed or uploaded to the grid but have incorrect image•
counts are re-processed (in a limited way to avoid thrashing in cases where data on the
PACS itself differs from the PACS database)
verifies that a new study found on the PACS is not still being received by the PACS (to avoid•
retrieving incomplete studies)
enqueues studies for retrieval, depending on several configuration values which control data flow•
and appropriate time windows for operation
studies that are retrieved via the RetrieveClient are verified that the correct number of images for•
the study were uploaded to the grid
The Query/Retrieve scheduler feature is complex, with a total of 19 separate configuration values
which are all contained in JSON format within the “query_retrieve” gateway configuration value.
Care must be taken to ensure that the settings are correct so as to avoid impacting the perfomrance
of the destination PACS. The scheduler is disabled by default on all gateways (the configuration is
blank by default as well). To activate it, the values within the “query retrieve” configuration should
be set in json format as shown in the configuration section.

20
DICOM Clients
Move Client (Store Client)
The MoveClient name is misleading as it actually performs the StoreSCU (the DICOM push or
‘C-STORE’) feature of the gateway using the MoveClient class (study-based) which then uses the
appropriate store client class (image-based) for pushing images. Files that are downloaded by
the Download component are transcoded, if necessary and configured, and then DICOM pushed
into the appropriate destination by the MoveClient. As of the 6-26-13 release, the gateway
configuration ‘use_clearcanvas_store_scu’ is no longer used. Instead, two store client options are
always available: the standard gateway store client using MyDICOM and the Clear Canvas store
client. They are enabled using the ‘store_clients_enabled’ gateway configuration. The default value
is ‘DG,CC’ which indicates that the gateway will use MyDICOM first for pushes, and if unsuccessful,
will attempt the push using the Clear Canvas SCU. Setting it to ‘CC,DG’ will reverse this order, and
setting it to just ‘DG’ or ‘CC’ will limit push attempts to only that store client.
The MoveClient also keeps track of which images were previously pushed to each destination and
applies destination-specific push rules defined in the gateway configuration “destination_push_
rules” to determine which images, if any, should be pushed based on the push rule defined for user
requested studies and automated requests and whether the pending push job comes before or after
the cutoff time defined for the request type. See the configuration section for a sample “destination_
push_rules” configuration in json format.
The Move Client can also be configured to send studies via the Gateway to a directory, rather than
a DICOM device.
To enable, create a destination with the following settings:
Give the destination a name with meaning to you.•
Put the directory path in the aetitle field (i.e. c:\DICOMGrid\Storage)•
Put anything in the address field (i.e. 100.101.102)•
Put -1 in the port field.•
Select the gateway you want to use.•
You do not need to check the ‘This destination supports query retrieve’ or the ‘This destination•
supports search check boxes.
Once the destination is configured, you can use DG’s DICOM Send function or routing rules to send
studies to the directory path defined in the aetitle field.
Echo Client
The gateway can be configured to automatically execute DICOM C-ECHO commands at regular
intervals to any DICOM destination associated with the gateway in order to verify DICOM
communication with the destination. In the event the C-ECHO fails, an alert email will be sent to any
users who have the event_node flag enabled for that namespace. Once an alert email has been
sent, no additional emails will be sent for that destination for additional C-ECHO failures until either
24 hours passes or there is a successful echo before another failed echo. Contact DICOM Grid
support for assistance with configuring this feature.