Professional Documents
Culture Documents
DVT Userguide
DVT Userguide
Version 2.1
June 03, 2005
DVT User Guide
Version 2.0
Table of Contents
UPDATE LIST ............................................................................................................................................ 6
1. LICENSE AGREEMENT............................................................................................................................................ 7
2. INTRODUCTION ........................................................................................................................................................ 8
2.1 GENERAL.......................................................................................................................................... 8
2.2 FEATURES........................................................................................................................................ 8
2.3 CAPABILITIES................................................................................................................................... 9
2.4 RESTRICTIONS ................................................................................................................................ 9
2.4.1 General...................................................................................................................................... 9
2.5 DEFINITIONS/ABBREVIATIONS:...................................................................................................... 9
2.6 REFERENCES: ............................................................................................................................... 10
2.7 RELATIONSHIP WITH THE DICOM STANDARD. .......................................................................... 10
3. GETTING STARTED................................................................................................................................................ 12
3.1 SYSTEM REQUIREMENTS............................................................................................................. 12
3.2 RELEASE PACKAGE ...................................................................................................................... 12
3.3 INSTALLATION ............................................................................................................................... 13
4. DVT PROJECTS........................................................................................................................................................ 15
5. DVT SESSIONS......................................................................................................................................................... 16
5.1 EMULATOR SESSIONS.................................................................................................................. 16
5.2 SCRIPT SESSIONS......................................................................................................................... 16
5.3 MEDIA SESSIONS .......................................................................................................................... 16
6. IMPORTANT FILES ................................................................................................................................................. 17
6.1 GENERAL........................................................................................................................................ 17
6.1.1 Comments ............................................................................................................................... 17
6.1.2 Descriptions............................................................................................................................. 17
6.2 PROJECT FILE................................................................................................................................ 17
6.3 SESSION FILE ................................................................................................................................ 17
6.3.1 SUT Test Session Properties .................................................................................................. 18
6.3.2 SUT ACSE Properties ............................................................................................................. 19
6.3.3 DVT ACSE Properties ............................................................................................................. 19
6.3.4 Socket Properties .................................................................................................................... 20
6.3.5 Test Session Properties .......................................................................................................... 21
6.3.6 Supported Transfer Syntaxes .................................................................................................. 23
6.3.7 Definitions................................................................................................................................ 23
6.3.8 DICOMScripts ......................................................................................................................... 23
6.3.9 Results .................................................................................................................................... 23
6.3.10 DICOMScript Description Directory ..................................................................................... 23
6.4 DEFINITION FILE ............................................................................................................................ 24
6.4.1 Standard Definition Files ......................................................................................................... 24
6.4.2 Private Definition Files............................................................................................................. 28
6.4.3 Special Definition Files ............................................................................................................ 28
6.5 DATA FILES .................................................................................................................................... 28
6.6 DICOMSCRIPT................................................................................................................................ 28
6.7 DICOMSUPERSCRIPT.................................................................................................................... 28
6.8 VBSCRIPT ....................................................................................................................................... 29
6.9 RESULTS FILE................................................................................................................................ 29
6.10 MEDIA STORAGE FILE................................................................................................................... 30
6.11 RAW DATASET FILE....................................................................................................................... 31
6.12 PIXEL FILE ...................................................................................................................................... 31
6.13 FILE INDEX FILE............................................................................................................................. 33
7. GRAPHICAL USER INTERFACE - GUI ................................................................................................................ 34
7.1 SESSION TREE .............................................................................................................................. 36
7.2 TAB CONTROL ............................................................................................................................... 38
7.2.1 Session Information Tab.......................................................................................................... 38
7.2.2 Specify SOP Classes Tab ....................................................................................................... 43
7.2.3 Activity Logging Tab ................................................................................................................ 44
7.2.4 Validation Results Tab............................................................................................................. 44
7.2.5 Script Tab ................................................................................................................................ 44
7.3 MAIN MENU BAR ............................................................................................................................ 46
7.3.1 File Menu................................................................................................................................. 46
7.3.2 Edit Menu ................................................................................................................................ 48
2
DVT User Guide
Version 2.0
3
DVT User Guide
Version 2.0
4
DVT User Guide
Version 2.0
5
DVT User Guide
Version 2.0
Update list
6
DVT User Guide
Version 2.0
1. License Agreement
The User is referred to the download Web site for details of the DVT license agreement.
7
DVT User Guide
Version 2.0
2. Introduction
2.1 General
DICOM is increasingly being used as the standard communication mechanism when integrating various medical
products in a hospital environment. The medical products involved include Modalities (CT, MR, X-Ray, etc.),
Workstations, Archives, Printers and HIS/RIS devices.
The intention of DICOM is to define the communication capabilities of each product type to a degree that allows
products, supplied by different vendors, to be connected together to form an open, integrated diagnostic / treatment
capability.
A need, therefore, exists to ensure that a product conforms to the DICOM standard in a way appropriate to its function.
The DICOM Validation Tool (DVT) is a software utility that will assist in testing DICOM conformance.
This document is the User Guide for the DICOM Validation Tool.
It is assumed that the reader has a basic understanding of the DICOM standard [1].
Throughout this document the product being validated by DVT is known as the “System under Test” or SUT.
2.2 Features
DVT is used to provide an independent measurement of the accuracy of a Systems DICOM Interface, according to both
the DICOM Standard and the SUT’s Conformance Statement.
DVT can be used as either SCU or SCP with a direct connection to the SUT (via TCP/IP). DVT acts as an emulator for
the DICOM Service classes being tested. DVT can also create and validate DICOM media files.
DICOM Validation
Tool
GUI
DICOM Script
Definitions
DICOM System
Engine Under Test
Test
Scenarios
DICOM
Interface
Figure 2-1: Test Tool Structure
The accuracy is measured in terms of syntax and semantic correctness. Complete inter-operability testing falls outside
of the capabilities of such a validation tool.
8
DVT User Guide
Version 2.0
2.3 Capabilities
• Data driven - tool core is independent of specific DICOM SOP Classes and Test Cases - allows future extension as
the DICOM Standard evolves.
• Capable of playing the role of SCU and SCP.
• Generate / send and receive / validate DICOM encoded messages appropriate to the SOP Class being tested.
• The conditions specified in [1] are used for Module / Attribute validation where possible. During validation, when
the condition cannot be evaluated logically, DVT displays the condition text to the User.
• Provides clear test results - including a summary of errors / warnings.
• High flexibility - access is provided to every single DICOM attribute and parameter.
• Received image data can be stored in Media Storage Format (See [1] - part 10) or in “raw” Dataset Format.
• Provides an Image (Object) Relationship Analysis for received objects.
• Allows tests to be repeated exactly as before - regression tests to check backward compatibility issues.
• Multi-platform support (Windows 2K / XP) as Command-line and GUI applications.
• Media File validation.
• Emulator for Verification, Storage and Print SOP Classes.
• Support for TLS and SSL secure sockets.
• .NET Assembly interface provides ability to write more complex test scripts in Visual Basic Script (VBScript).
2.4 Restrictions
2.4.1 General
DVT is incapable of testing all inter-operability issues. By concentrating on an interface validation, DVT has no way of
checking what a SUT does with the transferred data. Some human interpretation will always be necessary.
DVT DICOM(Super)Scripts cannot handle receiving N-EVENT-REPORT messages at unknown times. All messages
must be scripted in the exact order they are to be sent or received. If support for N-EVENT-REPORT messages is a
requirement then the test script should be written in VBS with the appropriate actions being done on receipt of an N-
EVENT-REPORT.
In general, older versions of DVT will not be able to read files created by newer versions of DVT. This includes
Session Files, Definition Files and DICOM(Super)Scripts. As new versions of DVT are released, new features will be
added to these files that the older versions of DVT will not support. The error messages generated by DVT will not
always clearly identify why the file cannot be used.
The retired SOP class definition files provided by DVT are in “as-is” condition. They are not supported. Retired SOP
class definition files are identified with RETIRED in the filename.
2.5 Definitions/Abbreviations:
The following Definitions and Abbreviations are used throughout this project:
9
DVT User Guide
Version 2.0
2.6 References:
[1] ACR/NEMA Standards Publications, No PS3, 1993-2004,
DICOM Standards:
Part 1 - Introduction,
Part 2 - Conformance,
Part 3 - Information Object Definitions,
Part 4 - Service Class Specifications,
Part 5 - Data Structures and Encoding,
Part 6 - Data Dictionary,
Part 7 - Message Exchange,
Part 8 - Network Communication Support,
Part 10 - Media Storage and File Format for Media Interchange,
Part 11 - Media Storage Application Profiles,
Part 12 - Media Formats and Physical Media for Media Interchange,
Part 14 – Grayscale Standard Display Function,
Part 15 – Security Profiles,
Part 16 – Content Mapping Resource,
& various supporting Supplements.
[2] DVT Conformance Statement,
Version 2.1
10
DVT User Guide
Version 2.0
Additions to the standard in the form of new Service Classes, can be handled by DVT by generating a Definition File
which corresponds to the new Service Class. DICOM (Super)Scripts will also be needed for any new Service Class. The
Definition Files can also be modified if any change is made to any existing IOD content.
11
DVT User Guide
Version 2.0
3. Getting started
3.1 System requirements
PC Requirements - Windows 2K /XP
• Pentium - 256 MB RAM.
• 40MB free disk space.
• Ethernet - TCP/IP interface.
• CD ROM (for Media Validation).
• Internet connection (to install the .NET runtime if needed).
• <INSTALLDIR>\
• bin\
Contains DVT executables and assemblies.
• certificates\
Contains sample secure socket certificates and credentials.
• definitions\
Contains all Definition Files.
• docs\
Contains this document, the .NET Assembly Help Files and DVT Conformance Statement [2].
• example\
• emulators\
Contains two emulators – either scu or scp.
o emulator_1\
o emulator_2\
• media\
Contains Media Session File.
• scripts\
o commit\
scp\
scu\
o mpps\
scp\
12
DVT User Guide
Version 2.0
scu\
o print\
scp\
scu\
o query\
scp\
scu\
o report\
scp\
scu\
o retrieve\
scp\
scu\
o storage\
scp\
scu\
o verification\
scp\
scu\
o worklist\
scp\
scu\
The script scp\ & scu\ directories contain example Test Scenarios for the appropriate service. Each scp\ or scu\
directory contains a results\ directory where the validation results files will be stored.
It is advised when generating SUT specific DICOM(Super)Scripts to do so in sub-directories relevant to the SOP Class
being tested, i.e., if generating SCU SUT Worklist DICOM(Super)Scripts, do so in directory:
<INSTALLDIR>\scripts\worklist\System\scu
The directory structure can be extended for other SOP Classes not released with DVT. The User will also need to
generate Definition Files for these SOP Classes.
3.3 Installation
The DVT installation may require an Internet connection to install the Microsoft “dotnetfx.exe” if the .NET runtime is
not already installed on your computer.
To install DVT under Windows 2K/XP do the following:
13
DVT User Guide
Version 2.0
• Double click on the “dvt_2_1_XXX.exe” icon - this is a self-extracting .exe which will install DVT on your
computer (XXX is current DVT 2.0 build number). Follow the given instructions.
An entry is automatically made for DVT (GUI), during installation in the “Program Files” menu option. Run DVT
(GUI) by choosing this option. Open a Command Prompt window to run DVT (Command-line).
It is possible to associate .pdvt (Project Files) and .ses (Session Files) with the DVT GUI application (Windows “Open
with…”). This will allow DVT to be started automatically when either a .pdvt file or .ses file is double-clicked.
Both GUI and Command-line versions of DVT are now ready for use.
14
DVT User Guide
Version 2.0
4. DVT Projects
The concept of a DVT Project has been introduced in V2.0. A DVT project is a container for a number of DVT
Sessions that are related to each other.
15
DVT User Guide
Version 2.0
5. DVT Sessions
The concept of a DVT Session applies to the User’s activities when performing a DICOM Validation test of a given
SUT. The Session is a very useful container for all configuration settings required to perform a set of tests on the SUT.
DVT supports three different Session types:
• Emulator (SCU or SCP).
• Script (script based).
• Media.
16
DVT User Guide
Version 2.0
6. Important files
6.1 General
DVT makes use of the following files:
File Name File Extensions
DVT Project files *.PDVT
Session Files *.SES
Definition Files *.DEF
Data Files *.DAT
DICOM Scripts *.DS
DICOM Super Scripts *.DSS
Visual Basic Scripts *.VBS
The files are all ASCII text files that can be easily modified by the User. Each file type has a given format as described
in the following sections.
The *RES.xml are transformed into corresponding *RES.html files during display by the DVT GUI. The XSLT style
sheet used for this transformation is provided in the <INSTALLDIR>\bin directory.
6.1.1 Comments
The ‘#’ (hash) symbol can be used to place a single line comment in the Session, Definition, DICOMScripts and
DICOMSuperScript files - anything, on the same line, following the ‘#’ symbol will not be interpreted by DVT.
6.1.2 Descriptions
The ‘##’ (double hash) can be placed at the beginning of a line to allow the User to place a description in the
Definition, DICOMScripts or DICOMSuperScript files. The whole line will be copied by DVT into the
corresponding Results file. The User can therefore describe a Test Scenario in a DICOM(Super)Script and have DVT
copy this description into the Results file corresponding to the Test Scenario.
17
DVT User Guide
Version 2.0
The Session filename can be composed of an alphanumeric part with a .SES extension.
The following parameters are supported:
• SUT Test Session Properties
• SUT ACSE Properties
• DVT ACSE Properties
• Socket Properties
• Test Session Properties
• Supported Transfer Syntaxes
• Definitions
• DICOMScripts
• Results
• DICOMScript Description Directory
•
6.3.1 SUT Test Session Properties
The SUT Test Session Properties are used to detail the Session specific properties and are:
The SESSION-TYPE defines the type of session being one of script, emulator or media.
The SESSION-TITLE is a free text string which can be used for a logical description of the session
The SESSION-ID is a number, ranging from 1 to 9999, used to identify the test session. The SESSION-ID is used as
part of the Results File(s) name. This means that it is possible to execute a test case several times, each time changing
the SESSION-ID, and have multiple test results available for the same test case.
The MANUFACTURER is the name of the company producing the Product being tested.
The MODEL-NAME is the Manufacturer’s name for the Product being tested.
The APPLICATION-ENTITY-NAME is the name of the application (within the Product) being tested. The default value is
“DICOM”.
The APPLICATION-ENTITY-VERSION is the version of the application (within the Product) being tested. The default
value is “3.0”.
The SOFTWARE-VERSIONS is the Manufacturer’s description of the software version(s) used by the Product being tested.
The TESTED-BY is the name of the person(s) performing the validation test.
The DATE is the date on which the validation test was performed. It must be expressed in YYYYMMDD format.
18
DVT User Guide
Version 2.0
The SUT-ROLE setting of requestor indicates that the SUT will take the role of Association Requestor and DVT the role of
Association Acceptor in this session.
The SUT-ROLE setting of acceptor indicates that the SUT will take the role of Association Acceptor and DVT the role of
Association Requestor in this session.
The SUT-MAXIMUM-LENGTH-RECEIVED is the maximum length of message fragment (P-DATA-TF PDU) that the
SUT can receive from DVT. DICOM messages are split into P-DATA-TF PDU fragments - e.g., C-STORE-RQ of a modality
image.
The SUT-IMPLEMENTATION-CLASS-UID is the DICOM UID assigned by the Manufacturer to the SUT implementation
to identify it internally. DVT checks that the value sent by the SUT matches the value given here.
The SUT-IMPLEMENTATION-VERSION-NAME is the version name given by the Manufacturer to the SUT
implementation to identify it internally. DVT checks that the value sent by the SUT matches the values given here. NOTE: The
IMPLEMENTATION-VERSION-NAME is an optional field - when the SUT does not send this value, enter “” (empty string)
here.
• DVT-AE-TITLE <string>
• DVT-MAXIMUM-LENGTH-RECEIVED <integer>
• DVT-IMPLEMENTATION-CLASS-UID <string>
• DVT-IMPLEMENTATION-VERSION-NAME <string>
The DVT-MAXIMUM-LENGTH-RECEIVED is the maximum length of message fragment (P-DATA-TF PDU) that DVT
can receive from the SUT. DICOM messages are split into P-DATA-TF PDU fragments - e.g., C-STORE-RQ of a modality
image.
19
DVT User Guide
Version 2.0
• SUT-HOSTNAME <string>
• SUT-PORT <integer>
• DVT-PORT <integer>
• DVT-SOCKET-TIMEOUT <integer>
• USE-SECURE-SOCKETS <boolean> (true, false)
• TLS-VERSION <string> (TLSv1, SSLv3)
• CHECK-REMOTE-CERTIFICATE <boolean> (true, false)
• CIPHER-LIST <string>
• CACHE-TLS-SESSIONS <boolean> (true, false)
• TLS-CACHE-TIMEOUT <integer>
• CREDENTIALS-FILENAME <pathname>\<filename>
• CERTIFICATE-FILENAME <pathname>\<filename>
The SUT-HOSTNAME is the name that DVT should use when making a connection to the SUT. It is best to enter the Internet
Address of the SUT (in dot notation).
The SUT-PORT is the port number that DVT should use when making a connection to the SUT.
The DVT-PORT is the port that the SUT should use when making a connection to DVT.
The DVT-SOCKET-TIMEOUT is the time-out in seconds used by DVT to wait for incoing data over a connected socket.
The USE-SECURE-SOCKETS is a boolean flag used to indicate whether the DICOM communication should be made over a
secure socket (set true) or non-secure socket (set false).
The TLS-VERSION indicates whether TLS V1.0 or SSL V3.0 security should be used. Only applicable when USE-SECURE-
SOCKETS is true.
The CHECK-REMOTE-CERTIFICATE is a boolean flag used to indciate whether the X.509 certificate received from the
SUT should be validated (set true) or not (set false) as part of the SSL Handshake. Only applicable when USE-SECURE-
SOCKETS is true.
The CIPHER-LIST defines the cipher list used to establish the secure connection during the SSL Handshake. The value of the
string is a concatenation of the possible settings for the SSL Authentication, Key Exchange, Data Integrity and Encryption
parameters. Only applicable when USE-SECURE-SOCKETS is true.
The CACHE-TLS-SESSIONS is a boolean flag used to indciate whether the secure session established during the SSL
Handshake should be cached for future use (set true) or not (set false). If the parameter is set true and the cache is still valid (see
TLS-CACHE-TIMEOUT) then the SSL Handshake for any new connection is much shorter and the secure connection
established more quickly. If the session cache is no longer valid then the full SSL Handshake is required to establish a new
secure connection. Only applicable when USE-SECURE-SOCKETS is true.
The TLS-CACHE-TIMEOUT defines the time in seconds for which the secure session cache is valid. Only applicable when
USE-SECURE-SOCKETS is true.
The CREDENTIALS-FILENAME defines the full pathname to a file containing the X.509 Private Key and Public Certicate
that DVT should use when trying to establish a secure connection. Only applicable when USE-SECURE-SOCKETS is true.
The CERTIFICATE-FILENAME defines the full pathname to a file containing the X.509 Trusted Certificates of all the
SUTs with which DVT will try to establish a secure connection. Only applicable when USE-SECURE-SOCKETS is true.
20
DVT User Guide
Version 2.0
The LOG-ERROR flag, when enabled (set true), causes any ERRORs detected by DVT to be logged.
The LOG-WARNING flag, when enabled (set true), causes any WARNINGs detected by DVT to be logged.
The LOG-INFO flag, when enabled (set true), causes any INFOrmation produced by DVT to be logged.
The LOG-RELATION flag, when enabled (set true), causes any DICOM Object Relationship information produced
by DVT to be logged. The analysis shows the Patient/Study/Series/Object relationship between objects.
The Patient ID (0010,0020), Study Instance UID (0020,000D), Series Instance UID (0020,000E) and SOP Instance UID
(0008,0018) are used in the relationship analysis.
In addition, DVT displays (when available) the Patient Name (0010,0010), Referenced Image Sequence (0008,1140),
Frame of Reference UID (0020,0052) for each image, together with the third value of the Image Type (0008,0008)
(e.g., for CT this defines the image as a LOCALIZER (Scout) or an AXIAL image).
NOTE: DVT does not interpret whether the relationship is correct, i.e. that intended by the SUT - that must be done by
the User according to the Test Scenario.
The LOG-DEBUG flag, when enabled (set true), causes any debug information to be logged.
The LOG-DULP-STATE flag, when enabled (set true), causes the event and state change information in the DULP Finite
State Machine to be logged.
The LOG-SCP-THREAD flag, when enabled (set true), causes the SCP threads, created to handle the SCP emulations, to log
data as described by the other LOG-xxx flags above.
21
DVT User Guide
Version 2.0
The PDU-DUMP flag, when enabled, causes the sent / received messages to be displayed in BYTE format at the socket level,
i.e., socket read & write. NOTE: Only, the first 1024 bytes of every P-DATA-TF PDU is displayed.
The LABEL-DUMP flag, when enabled, causes the final values of the LABELed attributes to be displayed to the user at the
end of the DICOM(Super)Script.
• as-media – Any received storage IOD will be stored in the DICOM Media Storage File format (i.e., including the File
Prefix, DICOM Preamble and File Meta Information) with a file extension .DCM.
• as-dataset – Any received storage IOD will be stored in a “raw” format with only the Dataset being saved. The file
extension is .RAW.
• no-storage – Do not store any received storage IOD.
The CONTINUE-ON-ERROR flag when enabled (set true), is used by DVT when executing DICOMSuperScripts, to
contiue the execution of the included DICOMScipts even if one of the DICOMScripts fails. When this flag is disabled DVT
will stop DICOMSuperScript execution after the first occurance of an error in a DICOMScript.
The STRICT-VALIDATION flag, when enabled (set true), causes DVT to perform a strict check between the received
ACSE and DICOM messages and those programmed (expected) in the DICOMScripts. It any parameter of the received
message does not match that programmed, then DVT reports a FAILED validation and aborts further DICOMScript
interpretation.
If the STRICT-VALIDATAION flag is disabled (set false), then DVT will WARN the User when a mismatch occurs
between received and programmed values. DVT will continue interpreting the DICOMScript.
This feature is particularly useful when the User wishes to test a specific (range of) SOP Class(es). Any additional SOP Classes
proposed by the Product will be automatically rejected by DVT, allowing the User to concentrate on the SOP Class(es) of
interest to the Test Scenario.
The AUTO-TYPE-2-ATTRIBUTES flag, when enabled (set true), causes DVT to add any Type 2 Attributes (with a zero-
length) to the DICOMScript defined Dataset before sending it to the Product. DVT consults to Definition File corresponding to
the Dataset in order to check the Dataset “completeness” before sending it to the Product. This feature ensures that the output
produced by DVT conforms to the Dataset definition without the User having to explicitly set any zero-length Attributes.
The AUTO-CREATE-DIRECTORY flag, when enabled (set true), causes DVT to create any missing directories when
handling the WRITE command to ensure that the pathname defined by the WRITE command is available before the file is
written. This can be disabled to allow the user to generate the directories manually thus ensuring the intended directory structure
is used.
The DEFINE-SQ-LENGTH flag, when enabled (set true), is used to make DVT encode explicit length Sequences when
sending messages. Explicit lengths are computed for both the Sequence and each Item present within the Sequence. By default
DVT uses the undefined length encoding.
The ADD-GROUP-LENGTH flag, when enabled (set true), is used to have DVT add Group Length attributes to all Groups
found in each message sent. By default DVT does not encode Group Length attributes (except for the Command Group
Length).
The DETAILED-VALIDATION-RESULTS flag, when enabled (set true), is used to have DVT produce detailed validation
results which include all the attributes of all the modules present in any dataset being validated. This property can be used
together with the SUMMARY-VALIDATION-RESULTS to get both detail and summary results during a test.
The SUMMARY-VALIDATION-RESULTS flag, when enabled (set true), is used to have DVT produce summary
validation results. The summary only shows the attributes (in their modules) which have validation errors. This property can be
used together with the DETAILED-VALIDATION-RESULTS to get both detail and summary results during a test.
The INCLUDE-TYPE-3-NOTPRESENT-INRESULTS flag, when enabled (set true), is used to have DVT include all Type
3 attributes in the detailed results even if these attributes are not present in the dataset being validated. When this property is
disabled (set false) the detailed results produced contain only the attributes present in the dataset being validated.
22
DVT User Guide
Version 2.0
6.3.7 Definitions
The Session File can contain a DEFINITION-ROOT <pathname> parameter which is used to prefix the definition file names
in order to define the full definition pathname.
The Session File can also contain an optional list of Definition Files. DVT loads this list of Definition Files when the Session
File is opened. Each entry in the Session File is as follows:
DEFINITION <pathname>\<filename>
where <pathname>\ is the optional pathname for the given Definition File and <filename> is the name of the given Definition
File. If the <pathname> is not present then the DEFINITION-ROOT will be used.
NOTE: DVT will automatically correct the pathname separator (slash or backslash) for the platform on which it is running.
The User can use either type of separator.
The DEFINITION <pathname>\<filename> is repeated in the Session File for each Definition that must be loaded.
6.3.8 DICOMScripts
The Session File can contain a DICOMSCRIPT-ROOT <pathname> parameter which is used to prefix the DICOMScript
names in order to define the full DICOMScript pathname.
The Session File can also contain an optional list of DICOMScripts. DVT will execute this list of DICOMScripts when the
Session File is opened. Each entry in the Session File is as follows:
DICOMSCRIPT <pathname>\<filename>
where <pathname>\ is the optional pathname for the given DICOMScript and <filename> is the name of the given
DICOMScript. If the <pathname> is not present then the DICOMSCRIPT-ROOT will be used.
NOTE: DVT will automatically correct the pathname separator (slash or backslash) for the platform on which it is running.
The User can use either type of separator.
The DICOMSCRIPT <pathname>\<filename> is repeated in the Session File for each DICOMScript that must be executed.
6.3.9 Results
The Session File can contain a RESULTS-ROOT <pathname> parameter which is used to prefix the Result File names in
order to define the full Result File pathname.
The HTML description file can be used to provide a full description of the test scenario covered by the DICOMScript including
graphics. The parameter has the following syntax:
DESCRIPTION-DIRECTORY <pathname>
23
DVT User Guide
Version 2.0
A subset of the above parameters is found in the emulator, scripting and media Test Session files. The mapping between
GUI property settings and Session File parameters is defined in the section on the GUI below.
Storage SOP Class SOP Class UID Definition File Name (.def)
Computed Radiography Image 1.2.840.10008.5.1.4.1.1.1 ComputedRadiographyImageStorage
Digital X-Ray Image – for 1.2.840.10008.5.1.4.1.1.1.1 DigitalX-RayImageStorage-
Presentation ForPresentation
Digital X-Ray Image – for 1.2.840.10008.5.1.4.1.1.1.1.1 DigitalX-RayImageStorage-
Processing ForProcessing
Digital Mammography X-Ray 1.2.840.10008.5.1.4.1.1.1.2 DigitalMammographyX-RayImage
Image – for Presentation Storage-Presentation
Digital Mammography X-Ray 1.2.840.10008.5.1.4.1.1.1.2.1 DigitalMammographyX-RayImage
Image – for Processing Storage-Procrocessing
Digital Intra-Oral X-Ray Image – 1.2.840.10008.5.1.4.1.1.1.3 DigitalIntra-oralX-RayImage
for Presentation Storage-Presentation
Digital Intra-Oral X-Ray Image – 1.2.840.10008.5.1.4.1.1.1.3.1 DigitalIntra-oralX-RayImage
for Processing Storage-Procrocessing
CT Image 1.2.840.10008.5.1.4.1.1.2 CTImageStorage
Enhanced CT Image 1.2.840.10008.5.1.4.1.1.2.1 EnhancedCTImageStorage.def
Ultrasound Multi-frame Image 1.2.840.10008.5.1.4.1.1.3.1 UltrasoundMulti-frameImage
Storage
MR Image 1.2.840.10008.5.1.4.1.1.4 MRImageStorage
Enhanced MR Image 1.2.840.10008.5.1.4.1.1.4.1 EnhancedMRImageStorage
MR Spectroscopy 1.2.840.10008.5.1.4.1.1.4.2 MRSpectroscopyStorage
Ultrasound Image 1.2.840.10008.5.1.4.1.1.6.1 UltrasoundImageStorage
Secondary Capture Image 1.2.840.10008.5.1.4.1.1.7 SecondaryCaptureImageStorage
Multi-frame Single Bit Secondary 1.2.840.10008.5.1.4.1.1.7.1 Multi-frameSingleBitSecondary
Capture Image CaptureImageStorage
Multi-frame Grayscale Byte 1.2.840.10008.5.1.4.1.1.7.2 Multi-frameGrayscaleByteSecondary
Secondary Capture Image CaptureImageStorage
Multi-frame Grayscale Word 1.2.840.10008.5.1.4.1.1.7.3 Multi-frameGrayscaleWordSecondary
Secondary Capture Image CaptureImageStorage
Multi-frame True Color Secondary 1.2.840.10008.5.1.4.1.1.7.4 Multi-frameTrueColorSecondary
Capture Image CaptureImageStorage
24
DVT User Guide
Version 2.0
Storage SOP Class SOP Class UID Definition File Name (.def)
Standalone Overlay 1.2.840.10008.5.1.4.1.1.8 StandaloneOverlayStorage
Standalone Curve 1.2.840.10008.5.1.4.1.1.9 StandaloneCurveStorage
12-lead ECG Waveform 1.2.840.10008.5.1.4.1.1.9.1.1 12-LeadECGWaveformStorage
General ECG Waveform 1.2.840.10008.5.1.4.1.1.9.1.2 GeneralECGWaveformStorage
Ambulatory ECG Waveform 1.2.840.10008.5.1.4.1.1.9.1.3 AmbulatoryECGWaveformStorage
Hemodynamic Waveform 1.2.840.10008.5.1.4.1.1.9.2.1 HemodynamicWaveformStorage
Cardiac Electrophysiology 1.2.840.10008.5.1.4.1.1.9.3.1 CardiacElectrophysiologyWaveform
Waveform Storage Storage
Basic Voice Audio Waveform 1.2.840.10008.5.1.4.1.1.9.4.1 BasicVoiceAudioWaveformStorage
Standalone Modality LUT 1.2.840.10008.5.1.4.1.1.10 StandaloneModalityLUTStorage
Standalone VOI LUT 1.2.840.10008.5.1.4.1.1.11 StandaloneVOILUTStorage
Grayscale Softcopy Presentation 1.2.840.10008.5.1.4.1.1.11.1 SoftcopyPresentationState
State Storage
X-Ray Angiographic Image 1.2.840.10008.5.1.4.1.1.12.1 X-RayAngiographicImageStorage
X-Ray Radiofluoroscopic Image 1.2.840.10008.5.1.4.1.1.12.2 X-RayRadiofluoroscopicImage
Storage
Nuclear Medicine Image 1.2.840.10008.5.1.4.1.1.20 NuclearMedicineImageStorage
Raw Data 1.2.840.10008.5.1.4.1.1.66 RawDataStorage
VL Endoscopic Image 1.2.840.10008.5.1.4.1.1.77.1.1 VLEndoscopicImageStorage
VL Microscopic Image 1.2.840.10008.5.1.4.1.1.77.1.2 VLMicroscopicImageStorage
VL Slide-Coordinates Microscopic 1.2.840.10008.5.1.4.1.1.77.1.3 VLSlide-CoordinatesMicroscopic
Image ImageStorage
VL Photographic Image 1.2.840.10008.5.1.4.1.1.77.1.4 VLPhotographicImageStorage
Basic Text SR 1.2.840.10008.5.1.4.1.1.88.11 BasicTextSR
Enhanced SR 1.2.840.10008.5.1.4.1.1.88.22 EnhancedSR
Comprehensive SR 1.2.840.10008.5.1.4.1.1.88.33 ComprehensiveSR
Procedure Log Storage 1.2.840.10008.5.1.4.1.1.88.40 ProcedureLogStorage
Mammography CAD SR 1.2.840.10008.5.1.4.1.1.88.55 MammographyCADSR
Key Object Selection Document 1.2.840.10008.5.1.4.1.1.88.59 KeyObjectSelectionDocument
Positron Emission Tomography 1.2.840.10008.5.1.4.1.1.128 PositronEmissionTomographyImage
Image Storage
Standalone PET Curve 1.2.840.10008.5.1.4.1.1.129 StandalonePETCurveStorage
RT Image 1.2.840.10008.5.1.4.1.1.481.1 RTImageStorage
RT Dose 1.2.840.10008.5.1.4.1.1.481.2 RTDoseStorage
RT Structure Set 1.2.840.10008.5.1.4.1.1.481.3 RTStructureSetStorage
RT Beams Treatment Record 1.2.840.10008.5.1.4.1.1.481.4 RTBeamsTreatmentRecordStorage
RT Plan 1.2.840.10008.5.1.4.1.1.481.5 RTPlanStorage
RT Brachy Treatment Record 1.2.840.10008.5.1.4.1.1.481.6 RTBrachyTreatmentRecordStorage
RT Treatment Summary Record 1.2.840.10008.5.1.4.1.1.481.7 RTTreatmentSummaryRecordStorage
Media Storage Directory Storage 1.2.840.10008.1.3.10 MediaStorageDirectoryStorage
Query / Retrieve SOP Class SOP Class UID Definition File Name (.def)
Patient Root QR – FIND 1.2.840.10008.5.1.4.1.2.1.1 PatientRootQueryRetrieve-FIND
Patient Root QR - MOVE 1.2.840.10008.5.1.4.1.2.1.2 PatientRootQueryRetrieve-MOVE
Patient Root QR - GET 1.2.840.10008.5.1.4.1.2.1.3 PatientRootQueryRetrieve-GET
Study Root QR – FIND 1.2.840.10008.5.1.4.1.2.2.1 StudyRootQueryRetrieve-FIND
Study Root QR – MOVE 1.2.840.10008.5.1.4.1.2.2.2 StudyRootQueryRetrieve-MOVE
Study Root QR – GET 1.2.840.10008.5.1.4.1.2.2.3 StudyRootQueryRetrieve-GET
Patient Study QR - FIND 1.2.840.10008.5.1.4.1.2.3.1 PatientStudyOnlyQueryRetrieve-FIND
Patient Study QR - MOVE 1.2.840.10008.5.1.4.1.2.3.2 PatientStudyOnlyQueryRetrieve-MOVE
25
DVT User Guide
Version 2.0
Query / Retrieve SOP Class SOP Class UID Definition File Name (.def)
Patient Study QR - GET 1.2.840.10008.5.1.4.1.2.3.3 PatientStudyOnlyQueryRetrieve-GET
Patient Root QR Relational - FIND 1.2.840.10008.5.1.4.1.2.1.1 PatientRootQRRelational-FIND
Patient Root QR Relational - MOVE 1.2.840.10008.5.1.4.1.2.1.2 PatientRootQRRelational-MOVE
Patient Root QR Relational - GET 1.2.840.10008.5.1.4.1.2.1.3 PatientRootQRRelational-GET
Study Root QR Relational - FIND 1.2.840.10008.5.1.4.1.2.2.1 StudyRootQRRelational-FIND
Study Root QR Relational - MOVE 1.2.840.10008.5.1.4.1.2.2.2 StudyRootQRRelational-MOVE
Study Root QR Relational - GET 1.2.840.10008.5.1.4.1.2.2.3 StudyRootQRRelational-GET
Patient Study QR Relational - FIND 1.2.840.10008.5.1.4.1.2.3.1 PatientStudyOnlyQRRelational-FIND
Patient Study QR Relational - MOVE 1.2.840.10008.5.1.4.1.2.3.2 PatientStudyOnlyQRRelational-MOVE
Patient Study QR Relational - GET 1.2.840.10008.5.1.4.1.2.3.3 PatientStudyOnlyQRRelational-GET
Print Management SOP Class SOP Class UID Definition File Name (.def)
Basic Film Session 1.2.840.10008.5.1.1.1 BasicFilmSession
Basic Film Box 1.2.840.10008.5.1.1.2 BasicFilmBox
Basic Grayscale Image Box 1.2.840.10008.5.1.1.4 BasicGrayscaleImageBox
Basic Color Image Box 1.2.840.10008.5.1.1.4.1 BasicColorImageBox
Basic Grayscale Meta 1.2.840.10008.5.1.1.9 BasicGrayscalePrintManagementMeta
Print Job 1.2.840.10008.5.1.1.14 PrintJob
Basic Annotation Box 1.2.840.10008.5.1.1.15 BasicAnnotationBox
Printer 1.2.840.10008.5.1.1.16 Printer
Printer Configuration Retrieval 1.2.840.10008.5.1.1.16.376 PrinterConfigurationRetrieval
Basic Color Meta 1.2.840.10008.5.1.1.18 BasicColorPrintManagementMeta
Presentation LUT 1.2.840.10008.5.1.1.23 PresentationLUT
Basic Print Image Overlay Box 1.2.840.10008.5.1.1.24.1 BasicPrintImageOverlayBox
Print Queue Management 1.2.840.10008.5.1.1.26 PrintQueueManagement
Stored Print Storage 1.2.840.10008.5.1.1.27 StoredPrintStorage
Hardcopy Grayscale Image Storage 1.2.840.10008.5.1.1.29 HardcopyGrayscaleImageStorage
Hardcopy Color Image Storage 1.2.840.10008.5.1.1.30 HardcopyColorImageStorage
Pull Print Request 1.2.840.10008.5.1.1.31 PullPrintRequest
Pull Stored Print Management Meta 1.2.840.10008.5.1.1.32 PullStoredPrintManagementMeta
Worklist SOP Class SOP Class UID Definition File Name (.def)
Modality Worklist 1.2.840.10008.5.1.4.31 ModalityWorklist-FIND
General Purpose Worklist 1.2.840.10008.5.1.4.32 GeneralPurposeWorklistManagementMeta
Management Meta
General Purpose Worklist 1.2.840.10008.5.1.4.32.1 GeneralPurposeWorklist-FIND
General Purpose Scheduled 1.2.840.10008.5.1.4.32.2 GeneralPurposeScheduledProcedureStep
Procedure Step
General Purpose Performed 1.2.840.10008.5.1.4.32.3 GeneralPurposePerformedProcedureStep
Procedure Step
Table 6.5 – Performed Procedure Step SOP Class - Definition File Names
PPS SOP Class SOP Class UID Definition File Name (.def)
26
DVT User Guide
Version 2.0
Table 6.5 – Performed Procedure Step SOP Class - Definition File Names
PPS SOP Class SOP Class UID Definition File Name (.def)
Modality Performed Procedure Step 1.2.840.10008.3.1.2.3.3 ModalityPerformedProcedureStep
Modality PPS Retrieve 1.2.840.10008.3.1.2.3.4 ModalityPerformedProcedureStepRetrieve
Modality PPS Notification 1.2.840.10008.3.1.2.3.5 ModalityPerformedProcedureStepNotification
Detached SOP Class SOP Class UID Definition File Name (.def)
Detached Patient Management 1.2.840.10008.3.1.2.1.1 DetachedPatientManagement
Detached Patient Management 1.2.840.10008.3.1.2.1.4 DetachedPatientManagementMeta
Meta
Detached Visit Management 1.2.840.10008.3.1.2.2.1 DetachedVisitManagement
Detached Study Management 1.2.840.10008.3.1.2.3.1 DetachedStudyManagement
Study Component Management 1.2.840.10008.3.1.2.3.2 StudyComponentManagement
Detached Results Management 1.2.840.10008.3.1.2.5.1 DetachedResultsManagement
Detached Results Management 1.2.840.10008.3.1.2.5.4 DetachedResultsManagementMeta
Meta
Detached Study Management Meta 1.2.840.10008.3.1.2.5.5 DetachedStudyManagementMeta
Detached Interpretation 1.2.840.10008.3.1.2.6.1 DetachedInterpretationManagement
Management
Commitment SOP Class SOP Class UID Definition File Name (.def)
Storage Commitment Push Model 1.2.840.10008.1.20.1 StorageCommitmentPush
Storage Commitment Pull Model 1.2.840.10008.1.20.2 StorageCommitmentPull
Table 6.8 – Study Content Notification SOP Class - Definition File Names
Notification SOP Class SOP Class UID Definition File Name (.def)
Basic Study Content Notification 1.2.840.10008.1.9 BasicStudyContentNotification
Verification SOP Class SOP Class UID Definition File Name (.def)
Verification 1.2.840.10008.1.1 Verification
Table 6.10 – Procedural Event Logging SOP Class - Definition File Names
Verification SOP Class SOP Class UID Definition File Name (.def)
Procedural Event Logging 1.2.840.10008.1.40 ProceduralEventLogging
27
DVT User Guide
Version 2.0
6.6 DICOMScript
A DICOMScript (.DS) describes a single Test Scenario. ACSE Requests & Responses and DIMSE Command / IOD
combinations are used to perform a given Test Scenario.
DVT interprets a DICOMScript in order to perform a Test Scenario. See sections on Programming DVT and Advanced
Programming for details of DICOMScript contents.
DICOMScripts should be written according to the role played by DVT:
• SCU - write a DICOMScript that plays the SCU role in a given Test Scenario.
• SCP - write a DICOMScript that plays the SCP role in a given Test Scenario.
• FSC – write a DICOMScript that plays the FSC role in a given Test Scenario (creates File-sets).
6.7 DICOMSuperScript
A DICOMSuperScript (.DSS) contains a list of DICOMScript (filenames) that together are used to describe a Test
Scenario. DVT executes the DICOMScripts in the order given in the DICOMSuperScript.
The DICOMSuperScript enables the reuse of certain DICOMScripts in various Test Scenarios - e.g., DICOMScript that
makes an Association for CT Image Storage.
It is possible to repeat the DICOMScript execution a number of times using the
DO n dicomscript
instruction where ‘n’ is the number of times that dicomscript is to be executed.
28
DVT User Guide
Version 2.0
Example 1:
ASSOC.DS
SC-IMG.DS
REL.DS
Associate using the general ASSOC.DS DICOMScript, Send a Secondary Capture image using the SC-IMG.DS
DICOMScript and then release the association using the general REL.DS DICOMScript.
Example 2:
ASSOC.DS
SC-IMG1.DS
REL.DS
ASSOC.DS
SC-IMG2.DS
REL.DS
ASSOC.DS
SC-IMG3.DS
REL.DS
As example one, but send 3 Secondary Capture images (SC-IMG1.DS, SC-IMG2.DS and SC-IMG3.DS), by making an
association for each image transfer.
Example 3:
ASSOC.DS
DO 20 SC-IMG.DS
REL.DS
Associate (using ASSOC.DS), repeat Secondary Capture image transfer 20 times and then release the association (using
REL.DS).
6.8 VBScript
A DICOM test scenario can be written using the DVTK assemblies in VBScript. The User will need a knowledge of
VBScript programming to be able to write DVT VBScripts.
MS HTML Help files are available in the <INSTALLDIR>\docs directory describing the DVTK assembly interfaces.
The following MS HTML Help files are provided:
• DvtkDataDocumentation – describes the DVT data classes.
• DvtkDocumentation – describes the general DVT classes.
These HTML Help files should be integrated into the MS Visual Studio .NET Help facility on your computer (available
only if you have MS Visual Studio .NET installed).
For the DICOMScript and DICOMSuperScript, the Result File name is generated from the combination of Session ID
(from the Session Properties) and the <scriptName>. The following filename is generated:
29
DVT User Guide
Version 2.0
For Emulation, the Result File name is generated from the combination of Session ID (from the Session Properties), the
Result File Index, and the <emulatorType>:
For the Media Validation, the Result File name is generated from the combination of Session ID (from the Session
Properties) and the <mediaFilename>:
Examples:
Summary_001_11_ds_res.xml - Summary results for DICOMScript 11.DS used in Script Session 1.
Detail_004_234_dss_res.xml - Detailed results for DICOMSuperScript 234.DSS used in Script Session
4.
Detail_008_St_Scp_Em_res12.xml - Detailed results for Results Index 12 used in Storage SCP
Emulator Session 8.
Summary _001_DICOMDIR_res.xml - DICOMDIR File result file.
Summary_001_DICOMDIR_resN.xml - for each DatasetN of the DICOMDIR File where N=(0..M).
30
DVT User Guide
Version 2.0
Pixel Filename
File Type Description
B08_ Pixel file contains 8-bit, OB data.
B08C Pixel file contains 8-bit, compressed OB data.
F32L Pixel file contains 32-bit, little endian, OF data.
F32B Pixel file contains 32-bit, big endian, OF data.
W08L Pixel file contains 8-bit, little endian OW data.
W08B Pixel file contains 8-bit, big endian OW data.
W16L Pixel file contains 16-bit, little endian OW data.
W16B Pixel file contains 16-bit, big endian OW data.
The File Type, forms part of the pixel filename, and is used by DVT to determine how the .PIX file should be read
when transmitting the contents according to the agreed Transfer Syntax. DVT cannot compress or uncompress data, so
the data in the file must match the agreed Transfer Syntax. No warning is given if the data does not match the Transfer
Syntax. When receiving OB/OF/OW data, DVT does not transform the OB/OF/OW data from the agreed Transfer
Syntax, but will generate a .PIX File Type matching the way in which the OB/OF/OW data was received.
31
DVT User Guide
Version 2.0
DVT also writes a short description of the OB/OF/OW data as a header in the Pixel File. The header has the following
format:
DVT can read Pixel Files without the Pixel File Header, in which case the filename is parsed in order to determine the
OB/OF/OW data details.
When a Pixel File contains Compressed (Encapsulated) data, it is up to the User to ensure that the file contains a correct
Basic Offset Table. DVT will simply read the Basic Offset Table as part of the OB/OF/OW data during encoding. DVT
will write any Basic Offset Table received into the Pixel File at the start position of the OB/OF/OW data. DVT will
validate the Basic Offset Table contents.
Example Filenames:
B08_0123.pix - Image Pixel File 123 contains 8-bit OB data.
B08C0012.pix - Image Pixel File 12 contains 8-bit compressed OB data.
W16L0003.pix - Image Pixel File 3 contains 16-bit little endian OW data.
32
DVT User Guide
Version 2.0
33
DVT User Guide
Version 2.0
A GUI for DVT is available to be able to work in a user-friendly way with the Sessions, which are part of a Project.
Three separate ways exist by which to start working with the GUI:
• Start working with a Project or Session by supplying the full filename as argument to Dvt.exe.
• Start DVT and load an existing Project or Session (a new Project will be automatically created for this
Session).
• Start DVT and create a new Project.
Tab
Session Tree
34
DVT User Guide
Version 2.0
When a Project is loaded, one or more Project views (more Project views may be added using the Window menu) may
be present in the GUI (see picture below for a GUI with two project views). It is important to note that all Project views
are visualizing the same Project. So when changing something in one Project view, this change is also visible (if the
same changed object is selected in the Session tree) in the other Project views.
Project View
Project View
Only one Project View is the active one: the one with the non-ghosted title bar. The specific menu items and toolbar
buttons that will be enabled only depend on the selected node in the Session tree of the active Project view.
In the rest of the sections, when referring to the Session tree, tab control, etc, the Session tree, tab control of the active
Project view is meant.
35
DVT User Guide
Version 2.0
The following table gives an overview of how objects are visualized in the Session Tree and how they are stored:
At most one node may be selected in the Session Tree. For the rest of this chapter, the following convention will be
used: when a node in the Session Tree is selected, the object visualized by the selected node will be called the selected
object. So e.g. “selected Session” is the Session visualized by the selected Session node in the Session tree.
Each type of Session is differently visualized in the Session Tree. The level of the (sub) nodes for each type of Session
node in the Session Tree is now summarized:
1) Script Session
2) Script (zero or more scripts that are stored in the Script directory of the Session)
3) Results (zero or more Results for each Script)
1) Emulator Session
2) Storage SCP Emulator
3) Results (zero or more Results)
36
DVT User Guide
Version 2.0
1) Media Session
2) Results collection
3) Results (one or more Results)
37
DVT User Guide
Version 2.0
38
DVT User Guide
Version 2.0
• Session type (cannot be changed) – see SUT Test Session Property SESSION-TYPE.
• Session title – see SUT Test Session Property SESSION-TITLE.
• Session ID – see SUT Test Session Property SESSION-ID.
• Tested by – see SUT Test Session Property TESTED-BY.
• Results dir – see Test Session Property RESULTS-ROOT.
• Scripts dir (only present for a Script Session) – see Test Session Property DICOMSCRIPT-ROOT.
• Description dir (only present for a Script Session) – see Test Session Property DESCRIPTION-
DIRECTORY.
• Storage Mode – see Test Session Property STORAGE-MODE.
• Log Relation – see Test Session Property LOG-RELATION.
• Generate detailed validation results – see Test Session Property DETAILED-VALIDATION-RESULTS.
Note: Summary validation Results will always be generated.
39
DVT User Guide
Version 2.0
NOTE: The Implementation Version Name is an optional field in DICOM. When DVT should not send this
value, leave this entry blank.
• Listen port – see Socket Property DVT-PORT.
NOTE: The default port for DICOM applications, when using no secure connections, is 104.
The default port for DICOM applications, when using secure connections, is 2762.
• Socket time-out– see Socket Property DVT-SOCKET-TIMEOUT.
• Maximum PDU length to receive– see DVT ACSE Property DVT-MAXIMUM-LENGTH-RECEIVED.
NOTE: The Implementation Version Name is an optional field in DICOM. When the SUT does not send this
value, leave this entry blank.
• Listen port– see Socket Property SUT-PORT.
NOTE: The default port for DICOM applications, when using no secure connections, is 104.
The default port for DICOM applications, when using secure connections, is 2762.
• Remote TCP/IP address– see Socket Property SUT-HOSTNAME.
• Maximum PDU length to receive– see SUT ACSE Property SUT-MAXIMUM-LENGTH-RECEIVED.
40
DVT User Guide
Version 2.0
The settings in the following sub sections will only be applied when secure sockets are used for communication
between DVT and the SUT.
7.2.1.4.1 General
• Check remote certificates. Only when this checkbox is checked, remote private keys that are received will be
checked against the DVT file containing SUT public keys. If the received private key is invalid, the connection
will be closed.
Regardless whether the checking of remote private keys is enabled or not, DVT will do the following:
• If the SUT initiates a secure socket connection, DVT will request a private key from the SUT. If no
private key is returned, the connection will be closed.
• If DVT initiates a secure socket connection, the connection will be closed if the SUT does not return a
private key.
See Socket Property – CHECK-REMOTE-CERTIFICATE.
• Cache secure sessions. Only when this checkbox is enabled, caching of secure socket Sessions will be
enabled.
7.2.1.4.2 Version
At least one of the following two secure sockets versions must be enabled.
• TLS v1. Only when this checkbox is checked, the secure sockets version TLS v1 will be enabled.
• SSL v3. Only when this checkbox is checked, the secure sockets version SSL v3 will be enabled.
See Socket Property TLS-VERSION.
7.2.1.4.3 Authentication
At least one of the following two authentications must be enabled.
• RSA. Only when this checkbox is checked, the authentication RSA will be enabled.
• DSA. Only when this checkbox is checked, the authentication DSA will be enabled.
See Socket Property CIPHER-LIST.
41
DVT User Guide
Version 2.0
7.2.1.4.6 Encryption
At least one of the following four encryptions must be enabled.
• None. Only when this checkbox is checked, no encryption will be enabled.
• Triple DES. Only when this checkbox is checked, the encryption Triple DES will be enabled.
• AES 128-bit. Only when this checkbox is checked, the encryption AES 128-bit will be enabled.
• AES 256-bit. Only when this checkbox is checked, the encryption AES 256-bit will be enabled.
See Socket Property CIPHER-LIST.
7.2.1.4.7 Keys
• File containing SUT Public Keys (certificates), the Browse button. A file browser dialog is presented by
which the file containing SUT public keys may be selected.
• File containing SUT Public Keys (certificates), the Edit button. A dialog is presented (see below for a
screenshot), in which the SUT public keys are displayed. In the same dialog, public keys may be added and
removed.
When the “Import Key” button is pressed, a public key may be imported. See the table below for the different
kind of key formats supported.
When the “Remove Key” button is pressed, the key selected will be removed.
The “Change Password” button displays a dialog box that allows the User to change the password that is used
to encrypt the public keys in the public keys file. If the “use default password” checkbox is checked, the
internal DVT password is used.
Any changes made in the dialog are not saved until the OK button is pressed. If the Cancel button is pressed,
all changes are discarded.
42
DVT User Guide
Version 2.0
• File containing DVT Private Keys (credentials), the Browse button. A file browser dialog is presented by
which the file containing DVT private keys may be selected.
• File containing DVT Private Keys (credentials), the Edit button. A dialog is presented, in which the DVT
private keys are displayed. In the same dialog, private keys may be added and removed.
See “File containing SUT Public Keys (certificates), the Edit button” for more information (the “DVT Private
Keys (credentials)” dialog is similar to the “SUT Public Keys (certificates)” dialog).
• Create Public\Private key pair, the Create Button. A wizard is presented, by which a public/private key pair
may be generated.
See Socket Properties CREDENTIALS-FILENAME and CERTIFICATE-FILENAME.
All definition files that are present in the directories specified in the “Definition file directories” listbox are shown. Each
definition file contains information about a specific SOP class. Definition file directories may be added or removed by
using the Add and Remove button. Removing a definition file directory is only allowed if more then one definition file
43
DVT User Guide
Version 2.0
directory is present. By enabling or disabling the “Loaded” checkbox, the user determines which SOP classes are
loaded. Finally, the “Select AE title – version to use” combobox determines which of the loaded SOP classes are
actually used during validation.
See properties DEFINITION-ROOT, DEFINITION, APPLICATION-ENTITY-NAME and APPLICATION-ENTITY-
VERSION.
Note that after execution or validation, the Activity Logging tab shows information about the last execution or
validation. The content of the tab is not related to e.g. a selected Result.
44
DVT User Guide
Version 2.0
45
DVT User Guide
Version 2.0
7.3.1.1 New…
Create a new Project using a wizard (the menu item is only enabled when no Session is executing).
If a Project is already loaded and unsaved changes exist in the Project and/or Session(s), a dialog is presented in which
the user can decide to save (some of) the changes, not save any changes or cancel the creation of the new Project.
The created Project will automatically be written to the Project file, as specified in the wizard.
First screen of the “New Project Wizard” in which to specify the Project file name
7.3.1.2 Open…
Open an existing Project or Session (the menu item is only enabled when no Session is executing).
If a Project is already loaded and unsaved changes exist in the Project and/or Session(s), a dialog is presented in which
the user can decide to save (some of) the changes, not save any changes or cancel the opening of the Project or Session.
A file browser is presented, by which the user can load a Project file or Session file.
46
DVT User Guide
Version 2.0
NOTE: When a Session file is loaded, a new Project will be created containing the loaded Session. The user has to
explicitly save this automatically created Project to file if needed.
7.3.1.3 Save…
Save unsaved changes to the Project file and/or Session file(s) (the menu item is only enabled when no Session is
executing).
A dialog is presented by which the user can decide what (changed Project and/or changed Session(s)) needs to be
written to file.
47
DVT User Guide
Version 2.0
A file browser is presented, by which the user can specify a new Session file. The Session will be saved to this specified
Session file. Future saves will also be saved in this specified Session file. The contents of the current Session file will
not change.
7.3.1.11 Exit
Exit the application.
If execution is going on, a dialog is presented by which the user can decide whether to stop the execution or cancel the
exit of the application.
If unsaved changes exist in the Project and/or Session(s), a dialog is presented in which the user can decide to save
(some of) the changes, not save any changes or cancel the exit of the application.
7.3.2.1 Copy
Copy the selected text to the ClipBoard (the menu item is only enabled when the tab control shows the Script tab, the
Activity Logging tab or the Validation Results tab).
When no text is selected, an empty string will be copied to the clipboard.
7.3.2.2 Find
Find a text string in the selected validation results (the menu item is only enabled when the tab control shows the
Validation Results tab).
The last text string that is entered in the “Find what” text box is also used for the “Find again” menu item.
48
DVT User Guide
Version 2.0
When the changed script is saved in Notepad (maybe to another file) this is not automatically reflected in the GUI,
because saving of the file is done outside DVT.
When the script contents has changed, and the new contents needs to be visible in the GUI, do one of the following:
• Use the menu item “View menu\Refresh Session Tree”.
• Select another Session Tree node and reselect the script.
When the script has been saved to a new file (and this new file is present in the script directory of one of the Session)
and this new script needs to be visible in the User Interface, do the following:
1. Use the menu item “View menu\Refresh Session Tree”.
2. In the Session tree, expand the Script Session containing the new script.
The shortcut key for this menu item is the F2 key.
49
DVT User Guide
Version 2.0
When this menu item is checked, all Sessions will be visible in the Session Tree. When this menu item is not checked,
only Script Sessions containing visible Scripts will be visible. Emulator and Media Sessions will always be visible,
regardless of the checked state of this menu item.
The “Printer Status Info” combo box values are taken from the loaded Print Definition File - Printer SOP Definition -
defined terms.
50
DVT User Guide
Version 2.0
51
DVT User Guide
Version 2.0
7.4 ToolBar
The toolbar contains often-used functionality. Depending on the context (Project loaded or not, which Session Tree
node is selected, etc), a toolbar button will be enabled or disabled.
The toolbar
The rest of this section describes the functionality behind each toolbar buttons.
7.4.1 New
Create a new Project using a wizard (the toolbar button is only enabled when no Session is executing).
See 7.3.1.1 (Menu item “New…”) for more information.
7.4.2 Open
Open an existing Project or Session (the toolbar button is only enabled when no Session is executing).
See 7.3.1.2 (Menu item “Open…”) for more information.
7.4.3 Save
Save unsaved changes to the Project file and/or Session file(s) (the toolbar button is only enabled when no Session is
executing).
See 7.3.1.3 (Menu item “Save…”) for more information.
7.4.4 Copy
Copy the selected text to the ClipBoard (the toolbar button is only enabled when the tab control shows the Script tab,
the Activity Logging tab or the Validation Results tab).
See 7.3.2.1 (Menu item “Copy”) for more information.
7.4.6 Find
Find a text string in the selected Results (the toolbar button is only enabled when the tab control shows the Validation
Results tab).
See 7.3.2.2 (Menu item “Find”) for more information.
7.4.9 Stop
Stop execution of the Script or Emulator (the toolbar button is only enabled when the selected Session is executing)
52
DVT User Guide
Version 2.0
53
DVT User Guide
Version 2.0
7.5.1.3 Save
Save unsaved changes to the Session file (the context menu item is only enabled when unsaved changes exist for this
Session).
54
DVT User Guide
Version 2.0
Both DICOMDIR file and/or multiple Media files may be validated at once, by selecting them in the presented file
browser.
If the checkbox “Generate detailed validation results”, present in the “Session Information” tab, is enabled, both a
Summary and Detailed Results will be generated when the validation ends. If the checkbox is disabled, only a Summary
Results will be generated.
When a DICOMDIR file has been validated, only the main Summary Results and, if configured for a Session, the main
Detailed Results will be visible in the Session Tree. When viewing:
• The main Summary Results, hyperlinks may be present in the “Validation Results” tab, which may be used to
navigate to a sub Summary Results. Each sub Summary Results represents the validation results of a
DICOMDIR record (and optional referenced file) containing warnings and/or errors. See the figure below for
an example.
• The main Detailed Results, hyperlinks may be present in the “Validation Results” tab, which may be used to
navigate to a sub Summary Results. Each sub Summary Results represents the validation results of a
DICOMDIR record (and optional referenced file).
Example of the main Summary Results for a DICOMDIR with hyperlinks to the sub Summary Results
7.5.4.2 Execute
Execute the selected script.
The following sequence of actions will take place in the Project View in which the execution is started:
1. The Session Tree is disabled.
2. If more than one Project View is open, the Session, in which the script is executed, is disabled in the other
Project views.
55
DVT User Guide
Version 2.0
3. The “Activity Logging” tab will become the selected (and only visible) tab. Executing progress may be
monitored by inspecting the “Activity Logging” tab.
4. Execution starts.
5. The execution of the script either ends automatically or ends because the user presses the (“Stop”) button in
the toolbar.
6. The “Validation Results” tab becomes the selected tab, in which the contents of the, automatically selected,
summary results file is shown.
7. If more than one Project View is open, the Session, in which the script was executed, is enabled again in the
other Project views.
8. The Session Tree is enabled.
Instead of using this context menu item, the user can accomplish the same by double-clicking on the Script.
If the checkbox “Generate detailed validation results”, present in the “Session Information” tab, is enabled, both a
Summary and Detailed Results will be generated when the execution ends. If the checkbox is disabled, only a Summary
Results will be generated.
7.5.5.1 Remove
Remove the selected Results.
7.5.6.1 Execute
Execute the selected Emulator.
The following sequence of actions will take place in the Project View in which the execution is started:
1. The Session Tree is disabled.
2. If more than one Project View is open, the Session, in which the Emulator is executed, is disabled in the other
Project views.
3. The “Activity Logging” tab will become the selected (and only visible) tab. Executing progress may be
monitored by inspecting the “Activity Logging” tab.
4. Execution starts.
5. If the selected Emulator is a SCP emulator, the user has to end execution by pressing the (“Stop”) button in
the toolbar. If it is a SCU emulator, the execution of the emulator ends automatically or ends because the user
presses the “Cancel” button.
6. The “Validation Results” tab becomes the selected tab, in which the contents of the, automatically selected,
summary Results file is shown.
7. If more than one Project View is open, the Session, in which the Emulator was executed, is enabled again in
the other Project views.
8. The Session Tree is enabled.
Instead of using this context menu item, the user can accomplish the same by double-clicking on the Emulator.
If the checkbox “Generate detailed validation results”, present in the “Session Information” tab, is enabled, both a
Summary and Detailed Results will be generated when the execution ends. If the checkbox is disabled, only a Summary
Results will be generated.
See 7.6 (Emulators) for more information about the actual usage of the different emulators.
56
DVT User Guide
Version 2.0
7.6 Emulators
The three emulators currently present in the DVT UI are discussed in this section.
An emulator is accessed through an Emulator Session. In the Session tree, use the context menu item “Execute” of one
of the Emulator nodes (present under an Emulator Session node) to execute an Emulator, or just double-click on an
Emulator node.
Pressing the “Specify TS” button in the “Session Information” tab (button is only present for an Emulator Session),
results in a dialog in which the supported Transfer Syntaxes used by the Emulators may be specified.
57
DVT User Guide
Version 2.0
The “Echo” button causes DVT to request a Verification Association and issue a C-ECHO-RQ to the SCP.
Select the Media files that should be sent by the Storage SCU. Use the “Add” and “Remove” buttons to generate the
required list. When the “Add” button is pressed, a file browser is presented for selecting extra Media file(s).
The “Send” button is used to start the Storage SCU. The way in which the selected Media files are handled can be
controlled by the following parameters.
• Single/Multiple Association – Define how the Association will be handled when more than one Media file is
selected or the Repeat count is greater than one. DVT will either send all selected Media files during a single
Association or request a new Association for each Media file selected.
• Validate on import – Validate the Media file against the appropriate Definition File during import (before sending
the Media file to SCP).
• Repeat x 1 – Indicate the number of times that the selected Media files should be sent to the SCP. This is useful
when running a duration test on the SCP.
NOTE: DVT will automatically modify the SOP Instance UID (0008,0018) for the Media files selected when the
repeat count is greater than one. This allows the same Media file content to be sent as many times, as indicated by
the count, but to be seen by the SCP as a different instance each time.
58
DVT User Guide
Version 2.0
The button Specify TS (SUPPORTED-TRANSFER-SYNTAX <uid> parameter) is used to define the Transfer
Syntaxes that DVT will accept when working in emulation mode. This parameter is repeated for each Transfer Syntax
supported by DVT.
When an SCU emulator is being used, DVT will propose all the chosen Transfer Syntaxes once per SOP Class being
used – i.e., If Implicit VR Little Endian and Explicit VR Big Endian are chosen, then DVT will propose two
Presentation Contexts for each SOP Class being used. DVT does not combine the Transfer Syntaxes into a single
Presentation Context, but allows the SCP to decide which will be supported during the Association.
When an SCP emulator is being used, DVT will accept Presentation Contexts from the SCU where the proposed SOP
Class/Transfer Syntax matches the Transfer Syntaxes chosen for the SOP Classes being used.
When the User starts a New Emulator Session, the Implicit VR Little Endian Transfer Syntax is selected as the default
value.
59
DVT User Guide
Version 2.0
8. Command Line
The Command-line version of DVT has the following usage:
Usage:
DvtCmd [-v]
<Full session file name>
<Script file name (session scriptdirectory used when file name only)>
Script filename must end with extension .dss or .vbs
or
DvtCmd -c
<Full script file name>
Script file name must end with extension .vbs
or
DvtCmd -m
<Full session file name>
<Full media file name>
Options:
-c: Only Compile, No Execute
-m: Validate media file
-v: Verbose
-h: Help
Results of running the Command-line will be written to Results Files as with the GUI version.
60
DVT User Guide
Version 2.0
9. Programming DVT
9.1 General
DVT interprets the contents of the DICOMScript files in order to perform a validation. DVT is “programmed” by
writing DICOMScripts that correspond with the given Test Scenario. Simple DICOMScripts can be written using the
following two commands:
• SEND
• RECEIVE
See section on Advanced Programming for details of the other commands supported.
DVT can SEND and RECEIVE DICOM Messages according to the sequence defined in the DICOMScript. The
following messages can be handled:
• ACSE Requests & Responses.
• DIMSE Messages.
When sending messages, the parameters / attributes defined by the given DICOMScript are encoded. In addition, for
DIMSE Messages, the corresponding Definition can be consulted to “complete” the Message (encode any Type 2
attributes with zero length).
Any parameter / attribute value can be set for sending.
The ability to set any parameter / attribute value is extremely useful when testing the robustness of a SUT’s
implementation.
Error and Exception Handling can easily be controlled - the SUT’s reaction to such events gives an indication of the
quality of the implementation.
When receiving messages, the parameters / attributes received from the SUT are first checked against the corresponding
Definition and then against those defined by the given DICOMScript.
NOTE: If the received message is different from that defined in the DICOMScript, the validation will fail even if the
received message conforms to DICOM - this is because the Test Scenario has failed.
NOTE: Since DVT uses the backslash character (“\”) as a prefix for a HEX value (see section 9.7, “Extended
Character Sets”), all backslashes in the script must be entered as a double backslash (“\\”) to be correctly read by
DVT. The exceptions to this are filenames and for the Image Display Format, DICOM tag (2010, 0010), which will
allow use of a single backslash.
Data Transfer is handled at the DIMSE / IOD level - See section Send, Receive DICOM Messages.
61
DVT User Guide
Version 2.0
<assoc_rq_param_list> (
PROTOCOL-VERSION <integer>
CALLED-AE-TITLE <string>
CALLING-AE-TITLE <string>
APPLICATION-CONTEXT-NAME <string>
PRESENTATION-CONTEXT-ITEMS
(<sop class uid/name1>, <transfer syntax>)
(<sop class uid/name2>, <transfer syntax 1>, .. , <transfer syntax n>)
…
MAXIMUM-LENGTH-RECEIVED <integer>
IMPLEMENTATION-CLASS-UID <string>
IMPLEMENTATION-VERSION-NAME <string>
SOP-CLASS-EXTENDED-NEGOTIATION
(<sop class uid/name1>, <integer>(applInfo1),..,<integer>(applInfon))
(<sop class uid/name2>, <integer>(applInfo1),..,<integer>(applInfon))
…
SCPSCU-ROLE-SELECTION
(<sop class uid/name1>, <integer>(scpRole),<integer>(scuRole))
(<sop class uid/name2>, <integer>(scpRole),<integer>(scuRole))
…
ASYNCHRONOUS-OPERATIONS-WINDOW <integer>(invoked) <integer>(performed)
)
The standard Associate Request parameters can take default values except for the PRESENTATION-CONTEXT-
ITEMS, which must be provided explicitly.
The SOP-CLASS-EXTENDED-NEGOTIATION, SCPSCU-ROLE-SELECTION and ASYNCHRONOUS-
OPERATIONS-WINDOW are optional and must be provided by the User in the DICOMScript.
The following parameters have “in-built” default values as shown:
PROTOCOL-VERSION 1
CALLED-AE-TITLE “DVT_AE”
CALLING-AE-TITLE “DVT_AE”
APPLICATION-CONTEXT-NAME “1.2.840.10008.3.1.1.1”
MAXIMUM-LENGTH-RECEIVED 16384
IMPLEMENTATION-CLASS-UID “100.118.116.Year.VersionMajor.VersionMinor”
IMPLEMENTATION-VERSION-NAME “dvtVersionMajor.VersionMinor”
62
DVT User Guide
Version 2.0
<transfer syntax> is the Transfer Syntax Name. Value is either any valid Transfer Syntax UID or the following
frequently-used text equivalent:
“Implicit VR Little Endian”
“Explicit VR Little Endian”
“Explicit VR Big Endian”
Example 1:
SEND ASSOCIATE-RQ (
PRESENTATION-CONTEXT-ITEMS
(“XA Image Storage SOP Class”,
“Explicit VR Big Endian”,
“Explicit VR Little Endian”,
“Implicit VR Little Endian”)
(“Basic Grayscale Print Management Meta SOP Class”,
“1.2.840.10008.1.2”)
)
DVT proposes XA Image Storage SOP Class and Basic Grayscale Print Management Meta SOP Class - XA with 3
possible transfer syntaxes, Print with only Implicit VR Little Endian (UID). Take all other parameters via default
mechanism.
Example 2:
SEND ASSOCIATE-RQ (
PROTOCOL-VERSION 2
PRESENTATION-CONTEXT-ITEMS
(“CT Image Storage SOP Class”, “Implicit VR Little Endian”)
)
DVT proposes CT Image Storage SOP Class with only Implicit VR Little Endian. Take all other parameters via default
mechanism, except for PROTOCOL-VERSION which is explicitly set to 2.
<assoc_ac_param_list> (
PROTOCOL-VERSION <integer>
CALLED-AE-TITLE <string>
CALLING-AE-TITLE <string>
APPLICATION-CONTEXT-NAME <string>
PRESENTATION-CONTEXT-ITEMS
(<sop class uid/name1>, <result/reason>, <accepted transfer syntax>)
(<sop class uid/name2>, <result/reason>)
…
MAXIMUM-LENGTH-RECEIVED <integer>
IMPLEMENTATION-CLASS-UID <string>
IMPLEMENTATION-VERSION-NAME <string>
SOP-CLASS-EXTENDED-NEGOTIATION
(<sop class uid/name1>, <integer>(applInfo1),..,<integer>(applInfon))
(<sop class uid/name2>, <integer>(applInfo1),..,<integer>(applInfon))
…
SCPSCU-ROLE-SELECTION
(<sop class uid/name1>, <integer>(scpRole),<integer>(scuRole))
(<sop class uid/name2>, <integer>(scpRole),<integer>(scuRole))
…
ASYNCHRONOUS-OPERATIONS-WINDOW <integer>(invoked) <integer>(performed)
)
63
DVT User Guide
Version 2.0
The standard Associate Accept parameters can take default values except for the PRESENTATION-CONTEXT-
ITEMS, which must be provided explicitly.
The SOP-CLASS-EXTENDED-NEGOTIATION, SCPSCU-ROLE-SELECTION and ASYNCHRONOUS-
OPERATIONS-WINDOW are optional and must be provided by the User in the DICOMScript.
The following parameters have “in-built” default values as shown:
PROTOCOL-VERSION 1
CALLED-AE-TITLE “DVT_AE”
CALLING-AE-TITLE “DVT_AE”
APPLICATION-CONTEXT-NAME “1.2.840.10008.3.1.1.1”
MAXIMUM-LENGTH-RECEIVED 16384
IMPLEMENTATION-CLASS-UID “100.118.116.Year.VersionMajor.VersionMinor”
IMPLEMENTATION-VERSION-NAME “dvtVersionMajor.VersionMinor”
The PRESENTATION-CONTEXT-ITEMS are the Accepted Abstract/Transfer Syntax combinations for the
Association:
(<sop class uid/name>, <result/reason>, <accepted transfer syntax >)
<sop class uid/name> is the Abstract Syntax Name. Value is either a UID or the text equivalent from the corresponding
Definition File - see (META)SOPCLASS.
<result/reason> is the Result/Reason field:
0 = acceptance
1 = user rejection
2 = no reason (provider rejection)
3 = abstract syntax not supported (provider rejection)
4 = transfer syntaxes not supported (provider rejection)
<accepted transfer syntax> is the Transfer Syntax Name. Value is either a valid Transfer Syntax UID or the following
frequently-used text equivalent:
“Implicit VR Little Endian”
“Explicit VR Little Endian”
“Explicit VR Big Endian”
NOTE: The Transfer Syntax Name should only be present when the Result/Reason field equals “acceptance”. The
value of the Transfer Syntax Name identifies the transfer syntax that the SCP wants to use for the given Abstract Syntax
Name (SOP Class UID).
SEND ASSOCIATE-AC (
PRESENTATION-CONTEXT-ITEMS
(“XA Image Storage SOP Class”, 0, “Implicit VR Little Endian”)
(“Basic Grayscale Print Management Meta SOP Class”, 3)
)
Accept the XA Image Storage SOP Class with Implicit VR Little Endian transfer syntax. Reject the Basic Grayscale
Print Management Meta SOP Class with Result/Reason “abstract syntax not supported”.
64
DVT User Guide
Version 2.0
<assoc_rj_param_list> (
RESULT <integer>
SOURCE <integer>
REASON <integer>
)
RESULT:
1 = rejected permanent
2 = rejected transient
SOURCE:
1 = DICOM UL service user
2 = DICOM UL service provider (ACSE related function)
3 = DICOM UL service provider (Presentation related function)
SOURCE = 2:
1 = no reason given
2 = protocol version not supported
SOURCE = 3:
1 = temporary congestion
2 = local limit exceeded
SEND ASSOCIATE-RJ (
RESULT 1
SOURCE 2
REASON 2
)
Reject Associate Request with “protocol version not supported”.
65
DVT User Guide
Version 2.0
<abort_rq_param_list> (
SOURCE <integer>
REASON <integer>
)
SOURCE:
0 = DICOM UL service user (initiated abort)
2 = DICOM UL service provider (initiated abort)
REASON:
0 = reason not specified 4 = unrecognized PDU parameter
1 = unrecognized PDU 5 = unexpected PDU parameter
2 = unexpected PDU 6 = invalid PDU parameter value
Example:
SEND ABORT-RQ (
SOURCE 2
REASON 6
)
SCP aborts association due to “invalid pdu parameter value”.
66
DVT User Guide
Version 2.0
9.3.1 General
DVT supports both sending and receiving of all DIMSE Commands - Requests and Responses.
IOD Support is provided by loading the appropriate Definition File. The DIMSE Command / IOD combination must
match one of the DEFINEs in the Definition File.
The following tokens are used in the syntax description.
<string n> Character String enclosed in double quotes (“) with a maximum length of ‘n’
characters.
<dataset_name> Character String enclosed in double quotes (“) that matches the name of a Dataset in
the Definition File.
<item_name> Character String enclosed in double quotes (“) that matches the name of an Item in
the Definition File.
< identifier> Identifier String, not enclosed in double quotes (“). An identifier is used to identify
an instance of the given object. Maximum length 64 characters.
An identifier may contain any character in the range A-Z, 0-9 and underscores '_'
67
DVT User Guide
Version 2.0
NOTE: The Value representations US\US, SS\US are not supported. Most of these variable VR types are handled by
DVT internally.
Command Syntax:
<dicom_object_attribute_list> (
<attribute 1>
..
<attribute n>
)
<dicom_object_attribute_list> (
<attribute 1>
..
<attribute n>
)
68
DVT User Guide
Version 2.0
When the <vr> is not defined in the DICOMScript, the <tag> must be known in the Definition File - enables <vr> look-
up.
The attribute values must be used according to the “base” type of the value - String, Integer and Hexadecimal.
The PN VR should be encoded as defined in [1] part 5. DVT supports the 3 component group format of the PN. This
should be encoded as a single string with the equals character ”=” (3DH) between the component groups. The User
should also apply the caret “^” (5EH) component delimiter where appropriate. DVT will validate the format of any PN
attributes.
Other VR values expressed as String will result in an error message from DVT during DICOMScript parsing.
Note: The maximum number of bytes that can be entered for a string value is 1024.
69
DVT User Guide
Version 2.0
Other VR values expressed as Integer will result in an error message from DVT during DICOMScript parsing.
Hexadecimal based values.
The following Attribute VR values should be used as hexadecimal:
(<tag>, AT, <hex>) 0x00100010
(<tag>, US, <hex>) 0x01FF
(<tag>, UL, <hex>) 0x02ABC10
(<tag>, OB, <hex>) 0x200 - defines pattern 512 X 512 X 8bit
(<tag>, OF, <hex>) 0x80 – defines pattern 128 X 128 X 32bit (floating point)
(<tag>, OW, <hex>) 0x400 - defines pattern 1024 X 1024 X 16bit
Other VR values expressed as Hexadecimal will result in an error message from DVT during DICOMScript parsing.
Example 1:
Send a CT Image for patient John Doe, taking the pixel data from file “ct-img.dat”.
NOTE: The CT Image example is incomplete.
Example 2:
RECEIVE C-STORE-RSP (
(0x00000900, 0x0000)
)
Receive a C-STORE-RSP with STATUS 0x0000 (OK) indicating that store operation was successful.
70
DVT User Guide
Version 2.0
(<tag>, SQ, )
(<tag>, SQ, , , )
A Sequence may also reference items previously created in the Data Warehouse (see section on Advanced
Programming for more details):
Example 1:
Example 2:
71
DVT User Guide
Version 2.0
The following examples will illustrate some patterns that can be produced for a 512 X 512 OW pattern (i.e., rows = 512
and columns = 512)
Example 1:
Example 2:
Example 3:
Example 4:
Example 5:
72
DVT User Guide
Version 2.0
The following examples will illustrate some patterns that can be produced.
Example 1:
Example 2:
The “Value” can also be a previously used “Name” so that the Attribute value associated with the “Name” gets copied
to the “Value” - example:
(0x00321032, “LABEL:ReqPhysName:Requesting^Dr”)
…
(0x00080090, “LABEL:RefPhysName:ReqPhysName”)
- can be used to set the initial value of (0032,1032) to “Requesting^Dr”, later the same value being copied to
(0008,0090). (This is useful when testing the Modality Worklist and Performed Procedure Step SOP Classes.)
The keyword NEW: is used in the DICOMScript to indicate that DVT should generate a new attribute value and map it
to the given label. DVT will translate any further occurrences of the label into the new attribute value.
The NEW: and LABEL: keywords can be used with VR types LO, SH & UI. The LABEL: keyword can be used with
VR types AE, CS, DA, PN & TM.
NOTE: The keywords LABEL: and NEW: form part of the actual labeled string.
This feature is found in DICOM Print Management where the SUT (Printer) is responsible for generating the UIDs for
each Image Box belonging to a given Film Box.
Example1:
73
DVT User Guide
Version 2.0
(0x20100510, SQ,
>(0x00081150, UI, ”Basic Grayscale Image Box SOP Class”)
>(0x00081155, UI, ”NEW:ImageBoxId1”)
)
…
)
Example 2:
9.6 VR Keywords
DVT uses certain keywords in combination with the VR as variables.
The keywords YESTERDAY, TODAY & TOMORROW when encountered by DVT as DA / DT attributes values are
translated into the corresponding calendar date (as available on the PC).
The keyword NOW when encountered by DVT as TM / DT attributes is translated into the current time (as available on
the PC).
The keywords CALLINGAETITLE and CALLEDAETITLE when encountered by DVT as AE attribute values are
translated into the CALLING-AE-TITLE and CALLED-AE-TITLE SUT ACSE Property values.
The keyword AUTOSET (not enclosed in double quotes) can be used with attributes of VR DA, TM, DT and UI to set
the attribute value to the current date, time, date/time and new UID respectively.
Examples:
74
DVT User Guide
Version 2.0
These VR Keywords are particularly useful when performing Query, Worklist and Detached Management Service
Tests.
In DICOMScripts:
SEND / RECEIVE C-STORE-RQ “Abstract Storage IOD”
If the “ct-img.def” Definition is the first loaded, then the abstract names will be translated to the concrete “CT” names
by DVT:
“Abstract Storage SOP Class” -> “CT Image Store SOP Class”
“Abstract Storage IOD” -> “CT Image”
75
DVT User Guide
Version 2.0
In DICOMScripts:
SEND / RECEIVE N-CREATE-RSP “Basic Film Box” (
(0x20100510, SQ,
>(0x00081150, UI, "Abstract Image Box SOP Class")
>(0x00081155, UI, "1.3.51.1.1.1")
)
)
If the “gry-prnt.def” Definition is the first loaded, then the abstract names will be translated to the concrete “Basic
Grayscale” names by DVT:
"Abstract Meta SOP Class" -> "Basic Grayscale Print Management Meta SOP Class"
"Abstract Image Box SOP Class"-> "Basic Grayscale Image Box SOP Class"
"Abstract Image Box" -> "Basic Grayscale Image Box"
76
DVT User Guide
Version 2.0
77
DVT User Guide
Version 2.0
10.1.1 PASSED
DVT uses the PASSED status as the final result of a successful validation. No ERRORs have been detected.
This is the goal for all DICOM conforming products!
10.1.2 FAILED
DVT uses the FAILED status as the final result of an unsuccessful validation - the total number of ERROR and/or
WARNING messages is displayed.
10.1.3 ERROR
The ERROR status is used when validating DICOM Messages. Anything which is incorrect in the syntax or semantics
of the DICOM Message will be reported as an ERROR.
Errors are prohibitive and occur when an implementation is incorrect. The cause of all ERRORs should be fixed before
a SUT can be declared as conforming to DICOM.
The total number of ERRORs detected during the validation is displayed by DVT.
10.1.4 WARNING
The WARNING status is used when validating DICOM Messages. Anything which requires further attention, but is not
incorrect, is reported as a WARNING - e.g., ACR-NEMA 2.0 Date/Time formats, unexpected Defined Terms, etc.,.
Warnings are not prohibitive. However, it may well be worth noting the cause of the warning for future reference.
The total number of WARNINGs detected during the validation is displayed by DVT.
10.1.6 DEBUG
The DEBUG status is used to have DVT display detailed debugging information. Some of this low-level information
may be useful to the User when difficult problems are encountered.
No user action is needed for DEBUG status messages.
10.1.7 RELATION
The RELATION keyword is used to mark the beginning of the Image(Object) Relationship Analysis.
78
DVT User Guide
Version 2.0
DICOM has introduced the notion that a conditional attribute “may be present otherwise” or “may not be present
otherwise”. To support the “maybe” option the concept of a WEAK condition has been introduced.
Example:
Clinical Trail Subject ID (0012,0040) shall be present if Clinical Trail Subject Reading ID is absent. May be present
otherwise.
This is defined as WEAK ((NOT PRESENT 0x00120042), TRUE) in the Definition Files.
The condition is covered by NOT PRESENT 0x00120042 and the “may be present” by TRUE (a secondary condition).
When the result is displayed, the first character, T or F, indicates the result of the overall condition evaluation. The rest
of the display gives the reason for the result.
Some examples are:
T[PRESENT 0x00081120] – indicates that the condition is true because tag 0x00081120 is present in the dataset.
F[NOT T[PRESENT 0x00081120/0x00081050]] – indicates that the overall condition is false because tag
0x00081050 is present in the first item of the sequence 0x00081120 in the dataset. The condition in this case
is “NOT PRESENT 0x00081120/0x00081050”. The validation results can be read from the “inside” of the
expression as “tag 0x00081120/0x00081050 is present (T), the not of true is false”.
F[VALUE 0x00280002 1 > 1] – indicates that the overall condition is false because the first value of tag
0x00280002 is not greater than 1.
79
DVT User Guide
Version 2.0
F[F[VALUE 0x00280004 1 = PALETTE COLOR] OR F[VALUE 0x00280004 1 = ARGB]] – indicates that the
overall condition is false. The condition in English is “the first value of tag 0x00280004 is “PALETTE
COLOR” or “ARGB””. In this case, the first value of tag 0x00280004 is not either of “PALETTE COLOR” or
“ARGB”, so the overall condition is false (false or false = false).
80
DVT User Guide
Version 2.0
11.1 Data-warehouse
DVT includes a data-warehouse in which the User stores ACSE Requests & Responses, DICOM Commands, Dataset
and Item objects (DICOMObjects) for re-use in the same or other DICOMScript.
The data-warehouse allows DICOMObjects to be shared between Test Sessions. This feature is particularly useful when
performing a full system validation where more than one DICOM connection by be used (Example: A Modality can
make use of the Basic Modality Worklist SOP Class, Storage SOP Class and Performed Procedure SOP Class. These
can be handled within separate Test Sessions with the exchanged DICOMObjects being shared between sessions.)
NOTE: The format of the ACSEObject identifier is IDnnnn when nnnn is a random number generated by DVT when
executing the DICOMScript. The use of these identifiers is purely for backwards compatibility.
Each DICOMObject must be identified in the data-warehouse.
NOTE: Take care when naming the identifiers. The names should be unique.
Once an ACSEObject or DICOMObject has been created in the data-warehouse, the paramater/attribute values can be
defined using the SET command. Any number of SET commands can be applied to an ACSEObject or DICOMObject.
The actual attribute values used will depend on the values given at the time the ACSEObject or DICOMObject is used.
The syntax for the ACSEObject SET commands is the same as that described above for the SEND/RECEIVE
commands.
81
DVT User Guide
Version 2.0
<file_tail_param_list> (
DATASET-TRAILING-PADDING <YES|NO> # Indicator if trailing padding should be added.
PADDING-VALUE <integer> # Value used for padding.
SECTOR-SIZE <integer> # Sector size when producing trailing padding.
)
An ACSEObject or DICOMObject can be removed from the data-warehouse using the DELETE command.
DELETE ASSOCIATE-RQ
DELETE ASSOICATE-AC
DELETE ASSOICATE-RJ
DELETE RELEASE-RQ
DELETE RELEASE-RP
DELETE ABORT-RQ
DELETE <command_ref>
DELETE <dataset_ref>
DELETE <item_ref>
Example 1:
CREATE N-GET-RSP NGETRSPID
Create an N-GET-RSP DICOMObject in the data-warehouse and identify it as “NGETRSPID”.
Example 2:
CREATE C-STORE-RQ CSTORERQID “CT Image” CTIMAGE1
Create a C-STORE-RQ and “CT Image” DICOMObject in the data-warehouse. The C-STORE-RQ DICOMObject will
be identified as “CSTORERQID” and the “CT Image” DICOMObject will be identified as “CTIMAGE1”.
Example 3:
CREATE “Source Image Sequence – Item” ITEMID1
Create an item in the data-warehouse representing a Source Image Sequence item and identify it as “ITEMID1”.
Example 4:
82
DVT User Guide
Version 2.0
The syntax of the SET when defining attributes and values is exactly the same as for the SEND / RECEIVE commands.
Example 5:
DELETE C-STORE-RQ CSTORERQID
Delete the C-STORE-RQ DICOMObject with identifier “CSTORERQID” from the data-warehouse.
Example 6:
DELETE “CT Image” CTIMAGE1
Delete the CT image DICOMObject with identifier “CTIMAGE1” from the data-warehouse.
IMPORT <dicom_message>
<dicom_message> <command_ref>
| <command_ref> <dataset_ref>
DICOMObjects in the data-warehouse can be exported over an existing Association (network connection) using the
EXPORT command. The Transfer Syntax agreed for the DICOMObject SOP Class will be used when exporting the
DICOMObject.
EXPORT <dicom_message>
<dicom_message> <command_ref>
| <command_ref> <dataset_ref> [ <pres_context_id> ]
Example 1:
83
DVT User Guide
Version 2.0
Example 2:
EXPORT C-STORE-RQ “MR Image” MRIMAGE2
Export the MR image identified by “MRIMAGE2” over the existing Association. The MR image must exist in the data-
warehouse to allow the export to be done.
or
The value of the attribute with <tag> will be extracted from the DICOMObject during the read. This attribute value will
then be used as the identifier for this DICOMObject. This allows reference objects to be stored in the data-warehouse
and accessed by the value of a given tag. It is possible, for example, to use the SOP Instance UID (0008,0018) as the tag
– all DICOMObjects read will then be stored using their SOP Instance UID as the identifier. During Storage SCP
Emulation and Media Validation, the data-warehouse is searched for DICOMObjects with a matching <tag>. In this
case it would be possible to have the DICOMObjects received by the Emulator or read by the Media validated against
matching reference objects. This is useful to ensure that no changes have been made in DICOMObjects used.
DICOMObjects in the data-warehouse can be written into a Media Storage file using the WRITE command. The
Transfer Syntax defined in the FILE-HEAD DICOMObject is used when writing the DICOMObject.
If the full pathname is not provided in filename, the path will be relative to the script file directory for the WRITE
command. For the READ command, the file will be looked for relative to the script file directory and, if it is not there,
then the file will be looked for relative to the session file directory.
Example 1:
READ “ctimage.dcm” “CT Image” CTIMAGE1
Read the Media Storage file ctimage.dcm and store the extracted DICOMObject in the data-warehouse with identifier
“CTIMAGE1”.
Example 2:
READ “ctimage1.dcm” 0x00080018
READ “ctimage2.dcm” 0x00080018
READ “mrimage1.dcm” 0x00080018
Read the Media Storage files ctimage1.dcm, ctimage2.dcm and mrimage1.dcm. Extract the attribute value for tag
0x00080018 from each image and use the value as the identifier when storing the DICOMObjects in the data-
warehouse.
NOTE: When using this form of the READ command it is important that all files read use the same tag value as the
identifier. The Storage SCP Emulator and Media use the value of the last tag read as the search criteria for reference
DICOMObjects in the data-warehouse.
Example 3:
84
DVT User Guide
Version 2.0
11.2.1 Compare
The COMPARE command compares two attributes identified by their tag values. These tags may be different
attributes in the same DICOMObject or in different DICOMObjects.
The comparison is made as follows:
1. Check for presence of the attributes in both DICOMObjects. Attributes must be present in both DICOMObjects.
2. Compare the VR and VM of the attributes in both DICOMObjects. VR and VM must be the same for both
attributes.
3. Compare the attribute values in both DICOMObjects. The attribute values must be the same. Insignificant leading
and trailing padding will be ignored during the comparison.
The DICOMScript will fail when COMPARE encounters a difference. COMPARE_NOT will succeed when the given
tags are not equal.
NOTE1: One or both tags not present in the DICOMObjects is interpreted as them being not equal.
NOTE2: Two different <tag> values can be compared in the same <dicom_object_ref> or the same <tag> can be
compared in two different <dicom_object_ref>s.
Example 1:
COMPARE “SC Image” IMAGE1 0x7FE00010 “SC Image” IMAGE2 0x7FE00010
The comparison operation is successful if the Pixel Data in the two Secondary Capture images is the same.
Example 2:
COMPARE_NOT “SC Image” IMAGE1 0x7FE00010 “SC Image” IMAGE2 0x7FE00010
The comparison operation is successful if the Pixel Data in the two Secondary Capture images is different.
11.2.2 Confirm
The CONFIRM command is used in conjunction with the ECHO command to enable the User to confirm that the test
may be continued now that the required actions have been done. DVT will display a message box when the
confirmation is required.
CONFIRM
Example:
ECHO “Please send CT Image number 1.”
ECHO “Hit <ENTER> when ready...”
CONFIRM
85
DVT User Guide
Version 2.0
11.2.3 Copy
The COPY command will copy attributes. This can be between two different DICOMObjects or two different attributes
within one DICOMObject.
Copying a non-existent source attribute will remove the destination attribute (if it was present before the copy). The
destination attribute will have the VR, VM and value(s) set equal to the source attribute.
The first object / attribute combination is the COPY destination. By defining the same <dicom_object_ref> twice with
different <tag> numbers, an attribute is copied within one DICOMObject.
NOTE: The copy command can add attributes that conflict with the definitions in the Definition Files (e.g., other VR,
unexpected attribute, etc).
Example:
COPY “SC Image” IMAGE1 0x7FE00010 “SC Image” IMAGE2 0x7FE00010
The examples below will copy the Pixel Data of standard secondary capture image object “IMAGE2” to the destination
object “IMAGE1”.
11.2.4 Delay
The DELAY command is used to introduce a delay, in seconds, in the execution of the DICOMScript.
DELAY <integer>
NOTE: It is not possible to interrupt a DICOMScript which as been delayed (the delay is implemented by putting the
script thread to sleep for the delay period).
Example:
DELAY 10
11.2.5 Display
The DISPLAY command can either display an attribute selection of a DICOMObject or all attributes present
in the DICOMObject.
Example 1:
DISPLAY “CT Image” IMAGE1 0x00080008 0x00080016
Display an attribute selection (two attributes).
Example 2:
DISPLAY “CT Image” IMAGE1
Display the whole object.
11.2.6 Echo
The ECHO command is used to display messages to the User. The messages may just be of an informative nature or
provide the User will instructions on how to continue with the test scenario.
86
DVT User Guide
Version 2.0
Example:
ECHO “This test scenario will form an Association with the Tested System,”
ECHO “requesting support for CT Image storage.”
11.2.7 Reset
The RESET command can be used to:
• Reset the content of the Data Warehouse (remove all entries).
• Reset the relationship analysis/stored instance list (used by the Storage Commitment SCP Emulator).
• Reset the state of the DULP Finite State Machine (to allow new Associations – Presentation Context ID is
reset to 1).
• Reset the Script Execution Context to the current Session Property values.
RESET ALL – reset Data Warehouse content, Relationship/Stored Instance List, DULP association state and Script
Execution Context.
RESET WAREHOUSE – reset Data Warehouse content only.
RESET RELATION – reset Relationship/Stored Instance List only.
RESET ASSOCIATION – reset DULP association state only.
RESET SCRIPT-EXECUTION-CONTEXT – reset the Script Execution Context only.
11.2.8 System
The SYSTEM command allows any operating system call to be made from the DICOMScript. The string given as an
argument to the SYSTEM command is passed directly to the command shell for interpretation.
The command line version of DVT can be started from within a DICOMScript. This is useful when testing the MOVE
service between three devices - DVT acting as MOVE SCP (and via second process STORE SCU).
NOTE: Be aware that system commands depend on the operating system (Unix or Windows).
Example:
SYSTEM “command to execute”
11.2.9 Time
The TIME command is used to print timestamps in the Display Pane. Successive calls will also give a delta with the
previous TIME call.
TIME
11.2.10 Validate
The VALIDATE command is used to validate DICOMObjects stored in the data-warehouse.
The first step is to validate the DICOMObject against the definitions in the Definition File. If the Definition File is
system specific (not the general DICOM.Definition), the first step ensures that the DICOMObject conforms to the
DICOM Standard and, in particular, to the SUT’s Conformance Statement.
87
DVT User Guide
Version 2.0
As a second step, the DICOMObject can be compared against an optional list of reference DICOMObjects.
Example1:
VALIDATE C-STORE-RQ STORE1 “XA Image” IMAGE1
Validation of a Standard XA image against the Definition File only.
Example 2:
VALIDATE C-STORE-RQ STORE1 “XA Image” IMAGE1
C-STORE-RQ REFSTORE1 “XA Image” REFIMAGE1
Validation against the Definition File and a reference DICOMObject.
11.2.11 Verbose
The VERBOSE command is used to enable / disable the Session “verboseness” from within the DICOMScript. The
VERBOSE ON / OFF command allows important sections of the DICOMScript to be highlighted (verbose output
produced), avoiding unnecessarily long verbose output of the whole DICOMScript. The condition of the VERBOSE
ON / OFF state is maintained even after the script finishes execution. If a script exits with VERBOSE OFF, normal
output will not resume for that session until a script is run with a VERBOSE ON command.
NOTE: The VERBOSE command is disabled when the LOG_DEBUG option is used so that the full DICOMScript can
be seen – for de-bugging purposes.
VERBOSE ON
VERBOSE OFF
Example 1:
The Verbose works like a toggle of the verbose option passed to DVT:
VERBOSE ON
Interesting Section - DICOMScript content will be displayed according to the Session “verboseness”.
VERBOSE OFF
88
DVT User Guide
Version 2.0
Example:
ADD-GROUP-LENGTH ON
The DICOM objects to be sent, following this command, will all be encoded by DVT with Group Length attributes for
all groups in the objects.
Example:
APPLICATION-ENTITY “OEM SUT” “V1.0”
VALIDATE C-STORE-RQ STORE1 “XA Image” IMAGE1
APPLICATION-ENTITY “DICOM” “3.0”
VALIDATE C-STORE-RQ STORE2 “XA Image” IMAGE2
The XA Image IMAGE1 will be validated against the SUT definition for OEM V1.0. The XA Image IMAGE2 will be
validated against the DICOM 3.0 definition.
DEFINE-SQ-LENGTH ON
DEFINE-SQ-LENGTH OFF
Example:
DEFINE-SQ-LENGTH ON
The DICOM objects to be sent, following this command, will all be encoded by DVT with Defined Sequence Lengths
for all Sequences in the objects.
11.3.4 Populate
The POPULATE command is used to enable / disable the automatic addition of Type 2 attributes during
DICOMObject encoding. This ensures that DICOMObjects used by DVT will conform to the DICOM Standard without
the User having to explicitly define values for all Type 2 attributes.
POPULATE ON
POPULATE OFF
89
DVT User Guide
Version 2.0
Example:
STRICT-VALIDATION ON
STRICT-VALIDATION OFF
Example:
STRICT-VALIDATION ON
Strict Validation of any DICOM objects will now be performed by DVT.
11.3.6 Validation
The VALIDATION command defines how the following DICOM objects will be validated by DVT. The following
options are supported:
VALIDATION ENABLED
VALIDATION ENABLED-USE-DEF-ONLY
VALIDATION ENABLED-USE-VR_ONLY
VALIDATION ENABLED-USE-REF-ONLY
VALIDATION ENABLED-USE-DEF-AND-VR
VALIDATION ENABLED-USE-DEF-AND-REF
VALIDATION ENABLED-USE-VR-AND-REF
VALIDATION DISABLED
90
DVT User Guide
Version 2.0
DVT (in this chapter, DVT refers to the GUI and command line version) offers the possibility to execute Visual Basic
Scripts. These scripts may use calls from the Dvtk and DvtkData library that are supplied with DVT to implement the
same functionality as may be implemented by Dicom Scripts. Furthermore, Visual Basic Script contains more language
constructs like e.g. the “If” statement, that may be used to implement conditional program flow (this is not possible with
Dicom Scripts).
The entry point for a Visual Basic Script executing under the command line version of DVT is the procedure
DvtCmdMain contained in the module DvtkScript. The Visual Basic Script must contain at least the following lines:
Module DvtkScript
Sub DvtCmdMain(ByVal CmdArgs() As String)
... ‘ Entry point of the code
End Sub
End Module
So a Visual Basic Script that must work with both the DVT GUI and the command line version of DVT must
implement both entry points. By having two separate entry points, it is now possible to implement slightly different
behavior between a Visual Basic Script executed by the DVT GUI and the command line version. E.g. when executed
from the DVT GUI a popup dialog requesting user input may be displayed but when executed from the command line
version no popup is displayed and default values are used. The command line version that is typically used in batch
processing can now be executed without user interaction.
91
DVT User Guide
Version 2.0
92
DVT User Guide
Version 2.0
The secure socket configuration is done on a per session basis. The same Security Credentials file and Trusted
Certificate file can be used by more than one session.
By default, the Security Credentials file and Trusted Certificate file are stored in the same directory as the session file.
In a normal application, the private key must be kept secret and secure. So it must be encrypted as it is stored on the
hard disk. DVT allows the use of password protected encrypted private keys. DVT will ask for the password when the
session is opened, or when the use of secure sockets is turned on, or when the security credentials file is selected. The
User can cancel entering the password and continue to use the session, but any attempt to open a secure socket
connection will fail. DVT also has a default password that is unknown to the User. This allows DVT to open the
session without asking the User for a password and is slightly more secure than using unencrypted private keys. It is
not truly secure, since anyone with access to DVT can access the private key. DVT also supports unencrypted private
keys by leaving the password blank.
DVT displays the certificate valid times using UTC time.
Turning on Debug logging will show details about the startup of the secure connection.
93
DVT User Guide
Version 2.0
Public Key - Used in Public Key Encryption where there is a private key that is held in secret by one of the parties and
a public key that anyone can know. Data that is encrypted with one of the keys can only be decrypted using the other
key.
Security Credentials - Security credentials are the private key and certificate chain that represent DVT.
Self-Signed Certificate - A certificate that is signed by the owner of the certificate. A self-signed certificate can also
be called a root certificate.
Trusted Certificate – A certificate that is known by DVT to be valid. Typically, trusted certificates are self-signed
certificates. If the trusted certificate is not self-signed, then the certificate’s certificate chain must be included in the
trusted certificate file.
94
DVT User Guide
Version 2.0
1. Private key
2. Certificate that corresponds with the private key
3. Certificate of the signer of the first certificate
4. Certificate of the signer of the previous certificate until the self-signed certificate is reached
5. Repeat the above for the other type of private key, if present
DVT supports 2 types of keys: RSA and DSA. The type of key used must correspond to the Authentication method
defined in the ASCE Properties dialog box. DVT can be configured to allow both types at the same time.
Note that it is valid to sign one type of key with the other type of key.
95
DVT User Guide
Version 2.0
96
DVT User Guide
Version 2.0
14. Examples
A number of example DICOM(Super)Scripts are provided, as part of the DVT release package, to show the sort of tests
that can be performed for a number of SOP classes. The examples are arranged in such a way as to allow DVT to act as
both SCU and SCP, i.e., the SCU DICOM(Super)Scripts can be used against the SCP DICOM(Super)Scripts. The new
User is advised to spend some time going through the examples in order to become more familiar with some of the
underlying concepts.
NOTE: The DICOM(Super)Scripts released as part of the DVT package only form a small subset of those needed to
perform a thorough validation of a SUT. The User is encouraged to construct a set of DICOM(Super)Scripts relevant to
the SUT being tested.
Examples for the following SOP classes are provided:
• Storage SOP Classes
• Query SOP Classes
• Retrieve SOP Classes
• Modality Worklist Management SOP Class
• Modality Performed Procedure Step SOP Class
• Storage Commitment SOP Class
• Structured Reporting SOP Class
• Print Management Meta SOP Classes
• Verification SOP Class
When using the GUI version, open the Session File using menu option File - Open in the appropriate directory, and
execute the DICOM(Super)Scripts as normal. Two parallel sessions can be opened – one as SCP and the other as SCU.
When running DVT SCU against DVT SCP always ensure that the DVT SCP is started first, thereby allowing a TCP/IP
listen socket to be created for the DVT SCU connect socket to communicate with.
97
DVT User Guide
Version 2.0
1.ds Summary_001_1_ 1.ds Summary_001_1_ Simulate Storage SOP Class not supported
ds_res.xml ds_res.xml by SCP during Association - “abstract
syntax not supported (provider rejection)”
2.dss Summary_001_2_ 2.dss Summary_001_2_ Show some of the ERROR/WARNING
dss_res.xml dss_res.xml messages produced by DVT when received
image does not conform to the given SOP
Class definition.
3.ds Summary_001_3_ 3.ds Summary_001_3_ Simulate “Out of Resources - A700” by SCP
ds_res.xml ds_res.xml on attempted image storage.
4.dss Summary_001_4_ 4.dss Summary_001_4_ Send 6 images belonging to the same patient
dss_res.xml dss_res.xml in one study and three series over a single
Association. Show Image(Object)
Relationship Analysis produced by SCP.
See patient One^Secondary Capture Image in
the Query examples.
5.dss Summary_001_5_ 5.dss Summary_001_5_ Send 4 images belonging to the same patient
dss_res.xml dss_res.xml in one study and one series. Each image is
sent in a separate Association. Show
Image(Object) Relationship Analysis
produced by SCP.
See patient Two^Secondary Capture Image
in the Query examples.
6.dss Summary_001_6_ 6.dss Summary_001_6_ Send 5 images belonging to the same patient
dss_res.xml dss_res.xml in one study and two series. Each series is
sent in a separate Association. Show
Image(Object) Relationship Analysis
produced by SCP.
See patient Three^Secondary Capture Image
in the Query examples.
98
DVT User Guide
Version 2.0
99
DVT User Guide
Version 2.0
100
DVT User Guide
Version 2.0
101
DVT User Guide
Version 2.0
15. Appendices
15.1 DICOMScript Language Reference
The DICOMScript Language supports the following commands:
Utility commands:
♦ CONFIRM - Request User confirmation for an action.
♦ DELAY - Delay further DICOMScript execution.
♦ ECHO - Display prompt / information to User.
♦ SYSTEM - Perform specified operating system call.
♦ TIME - Display the current system time.
♦ VERBOSE - Define verboseness during DICOMScript execution.
• ADD-GROUP-LENGTH ON
• ADD-GROUP-LENGTH OFF
15.1.2 APPLICATION-ENTITY
Syntax
102
DVT User Guide
Version 2.0
15.1.4 CONFIRM
Syntax
• CONFIRM
15.1.5 COPY
Syntax
15.1.6 CREATE
Syntax for creating ACSEObjects
• CREATE ASSOCIATE-RQ
• CREATE ASSOCIATE-AC
• CREATE ASSOCIATE-RJ
• CREATE RELEASE-RQ
• CREATE RELEASE-RP
• CREATE ABORT-RQ
• CREATE <command_ref>
• CREATE <command_ref> <dataset_ref>
• CREATE <item_ref> [DEFINED_LENGTH]
This command creates a reference to an item in another DICOM object addressed by <sequence_address>.
In this case there is no object explicitly created – the CREATE command simply adds an extra <item_ref> which refers
to the item addressed by <sequence_address>.
<item_nr> [ <integer> ]
| # nothing - default to 1st item
- identifies which item (0..n) in a sequence tag is addressed.
103
DVT User Guide
Version 2.0
• CREATE FILE-HEAD
• CREATE FILE-TAIL
• DEFINE-SQ-LENGTH ON
• DEFINE-SQ-LENGTH OFF
15.1.8 DELAY
Syntax
• DELAY <integer>
15.1.9 DELETE
Syntax for deleting ACSEObjects
• DELETE ASSOCIATE-RQ
• DELETE ASSOCIATE-AC
• DELETE ASSOCIATE-RJ
• DELETE RELEASE-RQ
• DELETE RELEASE-RP
• DELETE ABORT-RQ
• DELETE <command_ref>
• DELETE <dataset_ref>
• DELETE <item_ref>
• DELETE FILE-HEAD
• DELETE FILE-TAIL
15.1.10 DISPLAY
Syntax
15.1.11 ECHO
Syntax
104
DVT User Guide
Version 2.0
15.1.12 EXPORT
Syntax
• EXPORT <dicom_message>
<dicom_message> <command_ref>
| <command_ref> <dataset_ref> [ <pres_context_id> ]
15.1.13 IMPORT
Syntax
• IMPORT <dicom_message>
<dicom_message> <command_ref>
| <command_ref> <dataset_ref>
• POPULATE ON
• POPULATE OFF
15.1.15 READ
Syntax
15.1.16 RECEIVE
Syntax for receiving ACSE objects
RECEIVE <dicom_message>
15.1.17 RESET
Syntax
• RESET ALL
105
DVT User Guide
Version 2.0
• RESET WAREHOUSE
• RESET RELATION
• RESET ASSOCIATION
• RESET SCRIPT-EXECUTION-CONTEXT
15.1.18 SEND
Syntax for sending ACSE objects
SEND <dicom_message>
15.1.19 SET
Syntax for setting ACSEObject Parameters
• STRICT-VALIDATION ON
• STRICT-VALIDATION OFF
15.1.21 SYSTEM
Syntax
106
DVT User Guide
Version 2.0
15.1.22 TIME
Syntax
• TIME
15.1.23 VALIDATE
Syntax
15.1.24 VALIDATION
Syntax
• VALIDATION ENABLED
• VALIDATION ENABLED-USE-DEF-ONLY
• VALIDATION ENABLED-USE-VR-ONLY
• VALIDATION ENABLED-USE-REF-ONLY
• VALIDATION ENABLED-USE-DEF-AND-VR
• VALIDATION ENABLED-USE-DEF-AND-REF
• VALIDATION ENABLED-USE-VR-AND-REF
• VALIDATION DISABLED
• VERBOSE ON
• VERBOSE OFF
15.1.26 WRITE
Syntax for writing Dataset DICOMObjects
107
DVT User Guide
Version 2.0
SYSTEM DEFINITION
METASOPCLASS DEFINITION
COMMAND DEFINITION
108
DVT User Guide
Version 2.0
MACRO DEFINITION
SOPCLASS DEFINITION
MODULE DEFINITION
ATTRIBUTE DEFINITION
109
DVT User Guide
Version 2.0
<valuesdef> ::= ε
| , <firstvaluesdef>
| , <firstvaluesdef> , <othervaluesdeflist>
CONDITION DEFINITION
<condition> ::= ε
| ':' <string>
| ':' <conditionexpression>
| ‘:’ WEAK ( <conditionexpression> , <conditionexpression> )
<valuenumber> ::= ε
| <integer>
<operator> ::= =
110
DVT User Guide
Version 2.0
|<
|>
| <=
| >=
<attributetaghere> ::= ./
111
DVT User Guide
Version 2.0
112
DVT User Guide
Version 2.0
/****************************************************************************
Copyright (C) 1995, University of California, Davis
/***************************************************************************
*
* University of California, Davis
* UCDMC DICOM Network Transport Libraries
* Version 0.1 Beta
*
* Technical Contact: [email protected]
*
***************************************************************************/
15.4.2 OpenSSL
DVT uses the OpenSSL library to provide secure sockets support. The following is the license for the library.
LICENSE ISSUES
==============
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
the OpenSSL License and the original SSLeay license apply to the toolkit.
See below for the actual license texts. Actually both licenses are BSD-style
Open Source licenses. In case of any license issues related to OpenSSL
please contact [email protected].
OpenSSL License
---------------
/* ====================================================================
* Copyright (c) 1998-2003 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
113
DVT User Guide
Version 2.0
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* [email protected].
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* ([email protected]). This product includes software written by Tim
* Hudson ([email protected]).
*
*/
114
DVT User Guide
Version 2.0
115