mastering dicom with dvtk · mastering dicom with dvtk glenn potter,1 rick busbridge,1 michael...

Mastering DICOM with DVTk

Glenn Potter,1 Rick Busbridge,1 Michael Toland,2 and Paul Nagy2

The Digital Imaging and Communications in Medicine(DICOM) Validation Toolkit (DVTk) is an open-sourceframework with potential value for anyone working withthe DICOM standard. DICOM’s flexibility requires hands-on experience in understanding ways in which the stand-ard’s interpretation may vary among vendors. DVTk wasdeveloped as a clinical engineering tool to aid andaccelerate DICOM integration at clinical sites. DVTk isused to provide an independent measurement of theaccuracy of a product’s DICOM interface, according toboth the DICOM standard and the product’s conformancestatement. DVTk has stand-alone tools and a frameworkwith which developers can create new tools. We providean overview of the architecture of the toolkit, samplescenarios of its utility, and evidence of its relative ease ofuse. Our goal is to encourage involvement in this open-source project and attract developers to build off andfurther enrich this platform for DICOM integration testing.

KEY WORDS: DICOM, systems integration,PACS DICOM IHE conformance, Health Level 7, IHE

INTRODUCTION

D igital Imaging and Communications in Med-icine (DICOM)1 plays a major role in thehealth care information technology (IT) field as thestandard for medical images and communicationthroughout the hospital. With the organization ofthe DICOM Standards Committee in 1996 and thesupport of major medical groups and imaging ven-dors worldwide, DICOM has become a dominantintegration mechanism in the hospital enterprise.The DICOM standard version 3.0 contains 16 parts(more than 2,000 pages), and the standard itself isconstantly evolving as new software and imagingtechnologies are developed. Mastering a technologylike DICOM can be a daunting task, but the suc-cessful student will be on the right path with theDICOM Validation Toolkit (DVTk) from DVTk.

org. Consider DVTk the lab kit that is handed outwith the DICOM standard on the first day ofDICOM 101 class.As with any other technology, true learning and

understanding require hands-on experience.2 Al-though the standard itself does not define or identifytesting or validation procedures to assess confor-mance, a number of third-party tools have beendeveloped to fill that role. DVTk is a powerful toolfor mastering the intricate DICOM file format andtransfer syntax. The mantra of DVTk is to makeDICOM easy. If a picture archive and communica-tion system (PACS) adminsitrator, for example, ishaving a problem with imaging device integration,DVTk can be the first line of defense in tracking theproblem. When vendors are pointing fingers at oneanother, DVTk can help them past recriminationsand on to real solutions. For medical software de-velopers, integrators, and testers, DVTk can help tomore quickly produce robust systems.The DICOM Validation Tool (DVT) test frame-

work is a flexible architecture and uses service–object pair (SOP) class definition files, making itadaptable as the DICOM standard evolves. Itincludes a graphical user interface (GUI) and a com-mand line interface, DICOM media validation, ser-vice class user (SCU) and service class provider

1From the AGFA HealthCare, Mortsel, Belgium.2From the Radiology IT, University of Maryland School of

Medicine, Baltimore, MD, USA.

Correspondence to: Glenn Potter, AGFA HealthCare, 590North Shore Drive, Hartland,WI, 53029, USA; tel: +262-369-0900;e-mail: [email protected].

Copyright * 2007 by Society for Imaging Informatics inMedicine

Online publication 7 August 2007doi: 10.1007/s10278-007-9057-0

Journal of Digital Imaging, Vol 20, Suppl 1, 2007: pp 47Y62 47

(SCP) emulators, and a rich scripting language. Formore advanced testing, VBScript (Microsoft VisualBasic Scripting edition; Microsoft; Redmond, WA)or JScript (Microsoft) can be executed by DVT, anda set of .NET assemblies is available for developingstand-alone test tools with languages such as VisualBasic.NET (Microsoft) and C# (Microsoft).If a validation tool is to be taken seriously, it must

be vendor neutral. With the release of DVT 2.1 in2005, DVTk now exists as an open-source commu-nity project. Not only does this encourage morevendors to contribute (because of the incentive ofreduced development and integration costs), but theadoption and proliferation of standards make iteasier for individual developers to contribute toopen-source projects such as DVTk. Independentsoftware developers are sometimes discouragedfrom proceeding because of the chance that theirwork will provide a “one-off” solution only and notbe widely used. DVTk, with the backing of themature DICOM standard, is attracting talenteddevelopers with a desire to create something usefuland lasting. This success assures that time devotedto learning this toolkit will not be wasted.This article focuses primarily on the DVT main

application. We provide background on the toolkitand specific examples about the two intended rolesof DVT: service and development. Current effortswithin the DVTk project and future directions arealso highlighted.

DVTK HISTORY AND ARCHITECTURE

In 2000, Agfa HealthCare (Mortsel, Belgium) andPhilips Medical Systems (Eindhoven, The Nether-lands) decided to coordinate activities aroundDICOM validation testing by bringing togetherefforts already started by both companies under ajoint DVT project. The intention was to produce aDVT that could not only be used internally by bothcompanies to test their own products but also madefreely available to other original equipment manu-facturers (OEMs) as a means of testing theirproducts to the same level of detail. The ultimateaim was to reduce the time spent integratingproprietary systems by first exposing these systems’equipment to tests run using DVT.DVT project has a steering committee with re-

sponsibility for guiding legal, technical, and com-mercial aspects. The steering committee meets every

6 months to discuss past progress, current issues, andfuture requirements. A project manager was electedby the steering committee tomanage the DVT projecton a daily basis and report back to the committee.Development tasks were divided up based on theavailable skills of developers who report to the proj-ect manager. In its first years, Agfa and Philipsprovided the personnel to staff the DVT project.In September 2005, DVT was made into an open-

source project (http://www.dvtk.org, DICOM Vali-dation Toolkit; last accessed May 2007) underSourceForge (http://sourceforge.net/projects/dvt,SOURCEFORGE.NET ; last accessed May 2007)as DVTk and is licensed under the GNU LesserGeneral Public License (LGPL). The steering com-mittee decided that the time had come to beginpromoting DVTk to a wider audience, with the aimof attracting other companies who might join andsupply development resources. Around this time,ICT Healthcare (Eindhoven, The Netherlands),which had already been supplying development re-sources to the project, joined as a full member withrepresentation on the steering committee. The goalwas to make DVTk the independent gold standardfor DICOM validation and thereby improve theinteroperability of all vendor products using theDICOM interface.The dvtk.org Web site is now the location for

the latest downloads, defect tracking details, andforums on using DVTk. Interested individuals andcompanies may join the project through the Website. A weekly project telephone conference coor-dinates the activities of the development team.DVTk-based applications include DVT, the main

application, which together with the core forms whatis now referred to as the DICOM ValidationFramework (Fig. 1). The core includes a DICOMtesting data model and object-oriented class struc-ture. The DVTk and DVTkData libraries provideaccess to this data model and class structure via themanaged code adapter. The core includes theDICOMScript language that is supported by DVT.This language can be separated into basic program-ming, which includes the SEND and RECEIVEcommands for simulating DICOM SCPs and SCUs,and advanced programming. The advancedprogramming language includes commands suchas SYSTEM, for executing operating system nativeapplications, and a number of commands forworking with the Data Warehouse feature. TheData Warehouse is a run-time memory structure in

48 POTTER ET AL.

http://www.dvtk.orghttp://sourceforge.net/projects/dvt, SOURCEFORGE.NEThttp://sourceforge.net/projects/dvt, SOURCEFORGE.NET

which the user can store Association ControlService Element (ACSE) requests and responses,DICOM commands, and DICOM objects for reuseacross test scripts and sessions.For more advanced testing scenarios, DVTk

includes the Script Support library and the High-Level Interface (HLI) library. The HLI library is anewer abstraction built on top of the core that makesit easy to write multithreaded tests. The applicationprogram interface (API) exposed by this libraryencapsulates many of the low-level core API classesand methods that make writing VBScripts similar towriting scripts in DVTk’s native DICOMScriptlanguage. VBScripts can be executed entirely withinthe DVT GUI application or command-line execut-able or debugged in Visual Studio .NET. OtherDVTk-based applications built on the core andcurrently available on dvtk.org include: DICOMNetwork Analyzer, a network sniffer and DICOMprotocol analyzer; DICOM Editor, for displayingand editing DICOM files; DICOM Compare Tool,for comparing the attributes and values of two

DICOM files; DICOM Attribute Validator, forvalidating DICOM files, including Structured Re-port objects, against definition files; DICOM FileStripper, for removing all but mandatory attributesfrom a DICOM file; and DICOM File Anonymizer,for removing patient and physician informationfrom a DICOM file.To date, the following contributions have been

made to the DVTk project by outside parties, com-panies, and/or institutions:

� Medical Communications (UK) provided theunderlying Transmission Control Protocol/Internet Protocol (TCP/IP) Capture File to theDICOM protocol data unit (PDU) conversionutilities used by the DICOM Network Analyzerapplication.

� The National Institute of Standards and Tech-nology (NIST; Gaithersburg, MD) providedthe Health Level Seven (HL7)3 validation Webservices used in the latest DVTk HL7 valida-tion components.

Fig 1. DICOM Validation Framework.

MASTERING DICOM WITH DVTk 49

GETTING STARTED WITH DVTk OUTOF THE BOX

The latest version of DVT can be downloadedfrom http://www.dvtk.org . It comes packaged as aMicrosoft Windows InstallShield application. Theinstallation subfolder includes a user’s guide andWindows help files for the extensible .NET assemblies(available only if MS Visual Studio .NET is installed).A large number of examples on how to use the manyfeatures of DVT are included in the subfolder.Starting DVT presents the user with an empty

workspace. DVT is designed to work on a singleproject at a time, although multiple views of theproject may be opened from which multiple testsmay be simultaneously executed. A DVT project isa container for one or more test sessions. A sessionis a container for the configuration of one or moretests to be performed against a system under test(SUT). Project and session configuration proper-ties are stored in flat files. The DVT GUI exposesmost of the configuration properties, although someof the more advanced settings, such as STRICT-VALIDATION, are available only by directlyediting the session file. Some settings can also bemodified in script files. For example, the STRICT-VALIDATION script command overrides the valueof the STRICT-VALIDATION session property.Some settings, such as CALLED_AE_TITLE, alsohave built-in default values that are assumed if theproperty is not defined in a script or session file.Session files come in three types: emulator, script,

and media. Emulator sessions are used when DVTshould act as an SCU or SCP emulator to test theDICOM transfer syntax. The emulators have sup-port for Verification SCU/SCP, Storage SCU/SCP,and Print SCP. Script sessions are used when DVT isused to execute a DICOMScript, DICOMSuper-Script, or VBScript. A DICOMSuperScript issimply a script that calls one or more DICOM-Scripts. Script sessions have support for networkSCP/SCU message exchange and DICOM mediafile creation. Media sessions are used to validate theDICOM file format as a DICOMDIR and/or DCMmedia files. When validating a DICOMDIR file, anyreferenced files are also validated.An easy way to gain familiarity with DVT is go

through the examples in the subfolder using DVT asboth the test tool and the SUT. Opening up theexample project displays a tree view of all testsessions defined in the project and provides details

on the session currently selected in the tree. Clickingon the Window menu and selecting the New ProjectView and Tile item displays two views of the project.The next example will walk through the Modal-

ity Worklist (WLM) SCP/SCU test script sessions.Selecting the WLM_SCP session in the top viewand the WLM_SCU session in the bottom viewpresents a view from which two test sessions maybe executed simultaneously (Fig. 2).At the top of the Session Information tab are

general settings, including the session type, sessionID (used in uniquely naming results files), andlocation of files used/created by the test session.The DVT Roles Settings section defines the Appli-cation Entity (AE) title and some connection settingsthat DVT assumes during the test session. The SUTSettings section defines the AE title and someconnection settings, including the TCP/IP address,of the system the session is testing. Because thisexample uses DVT as both the testing system and theSUT, the DVT role settings in the top view aresynchronized to the SUT settings in the bottom view,and the SUT settings in the top view are synchro-nized to the DVT role settings in the bottom view.Locations of the SOP class definition files required

for the test session are selected under the Specify SOPClasses tab. The selected definition files are loadedinto memory when the test session starts, and DVTuses these to validate the DICOM messages andobjects it sends and receives. A definition filedescribes a single DICOM SOP class in terms of thecombination of DICOM Message Service Element(DIMSE) commands and Information Object Defini-tions (IODs) that make up the SOP class. In this case,both test sessions specify the Modality WorklistInformation Model–FIND SOP Class item. The stan-dard definition files that come with DVT in thedefinitions subfolder are taken directly from theDICOM standard parts 3 and 4. Private definitionfiles can bemade that extend the validation capabilitiesof DVT by copying one of these standard files andmodifying it with private user IDs (UIDs), modules,and attributes. A typical customization might specifythat when a particular SUT is known to always send avalue for the Patient Name (0010,0010) attribute, thecorresponding definition file can be modified to definethe Patient Name attribute as a type 1 (mandatory,nonzero-length) attribute.Opening the WLM_SCP tree node in the top view

and selecting the DICOMScript, 1.ds, displays aScript tab in the right side of the view. This script

50 POTTER ET AL.

http://www.dvtk.org

defines the test steps for the SCP. Simple DICOM-Scripts such as this can be written using only theSEND and RECEIVE commands. A large number ofadditional commands are available for more ad-vanced testing scenarios. The Script tab is read-only,but Windows Notepad can be launched from acontext menu on the script name in the tree view. Ahandy DVT DICOM script reference (dvtDICOM-script.hlp) file is in the docs folder. This script firstexecutes a RECEIVE command for an associationrequest message that specifies a single presentationcontext, consisting of the Modality Worklist Infor-mation Model–FIND SOP Class and three possibletransfer syntaxes. The SCU script in the bottom viewSENDs an association request message. The onlyrequired parameter for the ASSOCIATE-RQ mes-sage is the presentation context. For the SCP’sRECEIVE command, the ASSOCIATE-RQmessageis referred to as the reference or expected object. Thiswill be compared to the received ASSOCIATE-RQmessage. DVT will perform validation in two steps:

1. The received object is first validated against anyloaded definition files. This step ensures that the

correct attributes are present in the object andthat they are encoded correctly.

2. This step is optional and applied only if areference object is present in the script. Checksmade here are that the expected number ofattribute values has been received and that eachattribute value matches the corresponding refer-ence object attribute value.

Often, it is not known with what values an SUTwill respond, in which case no attributes can bespecified in the reference object, so that only stepone validation occurs (http://www.dvtk.org “DVTUser Guide”, version 2.1, August 2005). TheVALIDATION script command determines howthe DICOM objects are validated by DVT. Bydefault, validation is ENABLED, meaning fullvalidation will occur. The value of the STRICT-VALIDATION session property determines howthe result of the validation is handled by DVT.If STRICT-VALIDATION is enabled, the presenceof attributes in the received message must matchthe definitions exactly. If they do not match,then DVT reports a FAILED validation and aborts

Fig 2. DVT-Worklist Management SCP and SCU test sessions.


http://www.dvtk.org

further DICOMScript interpretation. If STRICT-VALIDATION is disabled and attributes do notmatch, then DVT reports a WARN message. Bydefault, STRICT-VALIDATION is disabled.Following a successful association validation and

negotiation, the SCU script SENDs a C-FIND-RQmessage of type ModalityWorklist–FIND. The SCPscript RECEIVEs the C-FIND-RQ, validates it, andproceeds to SEND three hard-coded C-FIND-RSPmessages. The SCU script was written to mirror theSCP script, so the three reference C-FIND-RSPmessages it defines match exactly with those sent bythe SCP. These scripts also demonstrate two DVTscripting features: Value Mapping and Value Rep-resentation (VR) Keywords. Value mapping allowsthe user to substitute a label for a value defined in ascript, generated by DVT, or received from the SUT,and then refer to that value with the label furtherdown in the script. The LABEL: keyword is used tomap an attribute value defined in the script orreceived from the SUT. The NEW: keyword tellsDVT to generate a new value and assign it to thegiven label. An example of this is in the SCP script,where the Study Instance UID attribute (0020,000D)is assigned a new value generated by DVT andnamed with the label StudyInstanceUid1. Thegenerated UID value can be referred to subsequentlyin the script as StudyInstanceUid1 (although thiswas not done in this example). VR keywords, suchas the AUTOSET keyword used in both the SCUand SCP scripts, tell DVT to generate a value andassign it to the corresponding attribute. In theexample case, AUTOSET is used in the ScheduledProcedure Step Start Date attribute to ensure thatvalues match between the two scripts. Both ValueMapping and VR Keywords are sensitive to the typeof attribute to which they are applied.This test is begun by right clicking on the SCP

script and selecting execute. When DVT isexecuting a test session, all tabs except theActivity Logging tab are hidden, the session treein the corresponding view is disabled, and the teststop button in the toolbar is enabled. The SCP’sActivity Log will indicate that it is waiting for aconnection on port 104. Executing the SCU scriptin the lower window will result in a number ofmessages in the Activity Logs, followed by thetermination of the test sessions. Comparing andcorrelating the SCP and SCU activity log entriesprovides a good visual reference for the DICOMmessage flow between two AEs.

By default, the AUTO-TYPE-2-ATTRIBUTESsession property is set to true in the session file,which means that DVT will automatically add anyzero-length type 2 (type 2 attributes must beincluded; however, they may be encoded with azero-length value or no value) attributes from thedefinition file to the dataset before sending to theSUT. This behavior is recorded in the SCU’s activitycolumn by the “Automatic Type 2 Attributes pop-ulation...” statement. This feature means that onlytype 1 (required, nonzero-length) attributes must beexplicitly stated in the scripts.After completion of the scripts, each view dis-

plays the Validation Results tab, where the resultsof the test sessions are displayed. DVT stores theresults of each test in a _res.xml file in the testsession’s configured results directory. The filename takes the form GDetail∣Summary9_nnn_GscriptName9_res.xml, where nnn is the sessionID from the session properties. Varying the sessionID from one test execution to the next allowsstorage of multiple sets of results in the resultsdirectory. Two session Boolean properties definewhether summary or detailed results are generated:SUMMARY-VALIDATION-RESULTS andDETAILED-VALIDATION-RESULTS. If the testsession’s STORAGE_MODE property is set to as-media or as-dataset, any media files received byDVT during the test are also stored in the resultsdirectory, again using the session ID to helpuniquely name the files. The generated results filesare listed in the session tree under the script name.Selecting one of the results files displays it in theValidation Results tab. The Validation Results tabis a Hypertext Markup Language viewer allowingnavigation between the summary results, detailedresults, and any generated media files usinghypertext links. DVT does not include a DICOMfile viewer. To automatically view a generated .dcmfile by clicking on a link in the Validation Resultstab, a DICOM image viewer must be installed andassociated with the .dcm file type.The SCP’s Validation Results tab will show a test

result of PASSED, and a .dcm media file is createdthat contains the Modality Worklist–FIND datasetreceived in the C-FIND-RQ message sent from theSCU. The SCU’s Validation Results tab also showsa result of FAILED, with nine errors reported. TheSummary Results File lists the errors; in this case,three type 1 attributes are missing from each C-FIND-RSP message sent from the SCP. Clicking on

52 POTTER ET AL.

a Link to Detailed Result link displays the errors inthe context of the complete C-FIND-RSP message.The detailed results file contains the complete contentsof each message sent and received in chronologicalorder. Any comment lines in the DICOMScript thatbegin with ## are copied directly to the detailed resultsfile. This is a good way to insert additional testinformation directly into the results. For additionaltroubleshooting output in the Activity Logging taband detailed results file, the LOG-RELATION, LOG-DEBUG, LOG-DULP-STATE, and PDU-DUMP testsession properties can be enabled. In the exampledescribed here, it is left as an exercise for the user toadd the missing type 1 attributes to the SCP script sothat the SCU test session result becomes PASSED.DICOMSuperScripts (script files with a .dss ex-

tension) enable the reuse of DICOMScripts invarious test scenarios. The storage example scriptsessions included with DVT demonstrate the bene-fits of DICOMSuperScripts.

DVTk FOR SERVICE TROUBLESHOOTING

As demonstrated in the previous section, DVTkcan be a useful tool when troubleshooting modalityworklist problems. Another common use case wouldoccur when adding new modalities to a PACSnetwork. It can be frustrating to ensure that AE titles,ports, and IP addresses match between the modalityand PACS configuration. This section will illustrateways in which DVT can be used to troubleshoot aPACS-modality interface problem and describeanother, more service-orientated tool available fromDVTk.org.Because DVT can act as both an SCP and SCU,

it is an excellent starting point for troubleshootingPACS-modality problems. One of the most com-mon and most frustrating failures is when amodality does not send images to the PACS. Mostmodalities provide little or no error informationwhen image storage problems occur with thePACS. The PACS system is often equally unhelp-ful. Without an error message of some kind, PACSadministrators have no guidance on where to beginin addressing the problem. DVT can simulate themodality or the PACS to pinpoint the source of theproblem while obtaining hard evidence that can beused to engage the involvement of additionalservice layers, such as the hospital networkinggroup or modality vendor. The Emulator_1 test

session in the example project that comes withDVT installation can be used to emulate theproblem modality. The problem modality’s AEtitle and PACS connection properties must becopied to the Emulator_1 session’s properties.Although not absolutely necessary, the modalitybeing emulated should be taken off the network toprevent any AE title conflicts during troubleshoot-ing. The first test to perform is a simple Verifica-tion to ensure that there is DICOM networkcommunication between the modality AE and thePACS. The test is started by opening the Emula-tor_1 session’s tree node, right clicking on theStorage SCU Emulator node, and selecting theExecute menu item. All tabs except the ActivityLogging tab are hidden, and a dialog box isdisplayed. Clicking on the Echo button tells DVTto send a C-ECHO message to the SUT. Theactivity logging tab will display the operationsperformed. For the purposes of this article, the testsare run against the open-source DICOM PACSDCM4CHEE (h t t p : / /www.dcm4che .o rg ,dcm4chee-2.x DICOM Clinical Data Managersystem; last accessed May 2007).If the verification test succeeds, then one can

assume the patency of DICOM network connectiv-ity between the modality and PACS. The next test isto attempt image storage to the PACS. This testrequires a set of DICOM test images, preferablyfrom the modality that is experiencing the problem.The images should contain no names, IDs, or UIDsthat will conflict with real-world data. It is impor-tant, however, that the data used to perform the testmatches the real-world data in structure as closely aspossible, including any private data elements themodality creates. A copy of the modality’s DICOMconformance statement comes in handy here. Thiswill help simulate the behavior of the modality asclosely as possible. Under the Specify TransferSyntax (TS) button on the Session Information tab,all transfer syntaxes supported by the modality as astorage SCU can be selected. For example, to test acomputed tomography (CT) modality, one wouldselect the CT Image Storage SOP Class(1.2.840.10008.5.1.4.1.1.2). For this test, the storageSOP class and transfer syntax that match theDICOM test images that will be stored to the PACSshould be selected. Note that this step is not actuallynecessary; when emulating a storage SCU, DVTwill automatically add to the association negotiationthe transfer syntaxes and SOP Classes from the


http://www.dcm4che.org, dcm4chee-2.xhttp://www.dcm4che.org, dcm4chee-2.x

DICOM media files being stored. Selecting thecorrect transfer syntaxes and SOP Classes isnecessary when emulating a storage SCP, however.Executing the Storage SCU Emulator opens theStorage SCU Emulator dialog box. In the dialogbox, the Add button is used to add the test images tothe list that will be sent to the SCP. Selecting theValidate before export option tells DVT to validatethe media files against the corresponding definitionfile prior to sending them. The number of associa-tions the modality uses when sending multipleimages is also specified here (most modalities wouldsend multiple images on a single association).Finally, clicking the Send button will tell DVT toexecute the storage test and close the dialog. DVT’sdetailed results will show the verification of eachmedia file followed by each storage transaction. TheStorage SCU emulator does not automatically dostorage commitment as the SCP emulator does. Tosimulate the modality performing a storage commit-ment request, one could create a DICOMScriptsession similar to the Commit_SCU example ses-sion, modifying the SOP instance UIDs to match theimages stored. This test should be performedimmediately after the storage test.To demonstrate some of the more advanced

DICOMScript features and the Data Warehouse inDVT, one can imagine a scenario where a CTmodality has recently undergone a software up-grade. Since the upgrade, technicians have beenreporting that although they can successfully post-process images on the modality before sending themto the PACS, processing of images retrieved fromthe PACS back to the modality fails. No errors havebeen reported by the PACS or modality on storageor retrieval. One possible reason is that the PACS isdoing something to the stored images that ispreventing the modality from processing them. Toevaluate, one can perform what is called a PACStransparency test. The idea is to make what thePACS is doing (if anything) to the images transpar-ent by comparing the before and after images. Thistest will require a DICOM CT image file from themodality on the DVT workstation and a DVT

project with two sessions. A script session playingthe role of SCU is used to put the image in the DVTData Warehouse, store it to the PACS, and initiate aC-MOVE from the PACS back to DVT. AnEmulator SCP session is used to receive the imagemoved back from the PACS and for performing thevalidation of the received image against the originalimage in the Data Warehouse.The first commands the script performs are to

reset the Data Warehouse and read the test imageinto the Data Warehouse (Fig. 3). The first READcommand loads the DICOM image into the DataWarehouse and uses the value of attribute 0×00080018, the SOP Instance UID, as a referencevalue. This will allow the SCP Emulator that sub-sequently receives the image back from the PACSto automatically compare it to the image in theData Warehouse based on the fact that the SOPInstance UID values are the same. The secondREAD command loads the same image again intothe Data Warehouse but this time references it withCTIMAGE1. This reference will be used to exportthe image directly from the Data Warehouse to thePACS. As an alternative to READing the imageinto the Data Warehouse, one could use theCREATE and SET commands to build an imageobject directly in the Data Warehouse. DVT has theability to generate pixel data patterns for VRs oftype other byte (OB), other float (OF), and otherword (OW). For the purposes of this example, it isbest to use an image from the problem CT mo-dality. The next operation the script performs is toestablish a C-STORECT Image association with thePACS. After establishing the association, the scriptcreates a C-STORE-RQ command object in the DataWarehouse and exports the CT Image referenced byCTIMAGE1 using the C-STORE-RQ commandreferenced by CSTOREREQID, over the establishedassociation (Fig. 4). After closing the storageassociation, the script creates a new association onwhich to perform the C-MOVE, sends the requestto move the image from the PACS to the DVT AE,and then closes the association (Fig. 5). Note thatthe Patient ID (0×00100020) and SOP Instance

Fig 3. PACS transparency test using DICOMScript-reading image into the Data Warehouse.

54 POTTER ET AL.

UID (0×00080018) were manually copied from theCT Image test file. Also, before executing this test,the SCP Emulator must already be started andwaiting for the C-STORE from the PACS in re-sponse to the C-MOVE request. If the test executessuccessfully, the statement “Reference Dataset withidentifier ‘1.3.46.670589.10.900123.19970114.35042000040’ found in Warehouse” should appearin the Activity Log indicating that DVT found thesame CT image previously loaded into the DataWarehouse and will use it to perform a comparisonof the dataset attributes and values.This test requires that the PatientRootQueryRe-

trieve-MOVE.def definition file is loaded in thescript session and the CTImageStorage.def definitionfile is loaded in the Emulator SCP session. If, assuspected, the PACS is modifying the CT Imageobject before returning it to the modality, theEmulator SCP results data will identify where thesemodifications occurred. In this case, the hypotheticaltester notices that DVT is indicating that a set ofprivate attributes in the Data Warehouse copy of theimage are missing from the image returned from thePACS. Upon further investigation, it turns out thatthe software upgrade performed on the modalityincluded the addition of a set of new private attributesrequired by the modality to perform new post-

processing algorithms on the images. The PACSdoes not support these new private attributes for somereason and is stripping them from the image objects.Instead of using a combination of a DICOM-

Script test session and Emulator test session, thistest could have been implemented with a singleVBScript session using the HLI library. In this case,separate threads would be created for the SCU andthe SCP parts. This approach is left up to the user asan exercise.Although DVT can analyze all aspects of DICOM

interfacing, it tends to be overloaded for field serviceissues. DVTk.org has a number of service-orientatedtools also based on the DVTk framework. One ofthese is the DICOMSniffer & Analyzer Tool. Thetool is a GUI-based network sniffer and DICOMprotocol analyzer. This tool uses the WinPcap open-source network library for packet capturing andfiltering and includes a user guide. This tool can sniffa live DICOM network stream given two endpoints,such as a modality and PACS. The troubleshootingpower of this tool should not be underestimated. Itcan perform message validation between two devi-ces similar to DVT but does not require replacing anSUT device with the testing tool. Figure 6 shows thetool capturing a modality worklist query/responsecommunication between two IP addresses.

Fig 5. PACS transparency test using DICOMScript-moving the image back to DVT.

Fig 4. PACS transparency test using DICOMScript-exporting image from the Data Warehouse.


After the capture process, the user is presentedwith a per-association analysis of the DICOMcontrol and datasets that were captured. TheAssociation Overview tab shows the requestedand accepted services and each field of theassociation PDUs. In the Service Elements Over-view tab (Fig. 7), one can see all of the DIMSEmessages that were transmitted during the associ-ation, save a copy, and view the PDUs. Thesummary and detailed validation results are similarto those produced by DVT, including messagevalidation against SOP Class definition files. Thetool also has the option of saving the captured data

to a capture file for latter analysis or for sending onto additional service personnel. The DICOMSniffer & Analyzer is a tool every PACS admin-istrator should have on his or her workstation.Two more tools built on the DVTk framework

that should be in the imaging professional’s toolboxin working with DICOM on a regular basis areDICOM Compare and DICOM Editor. DICOMCompare can compare the attributes and values oftwo DICOM files. It can also filter out of thecompare process any attributes and sequences tomake it easier to identify offending elements. Aknown “good” DICOM object can be compared to

Fig 6. DICOM Sniffer & Analyzer tool in capturing mode.

Fig 7. DICOM Sniffer & Analyzer tool in analyzing mode.

56 POTTER ET AL.

one causing a problem that was captured from thenetwork with DICOM Sniffer.With the DICOM Editor, one can add/delete/

modify any attribute or sequence and sequence itemand save the modified DICOM file to any location.This tool goes hand-in-hand with the DVT, DICOMSniffer, and DICOM Compare tools. After thosetools have identified the DICOM elements that maybe causing a DICOM object storage problem, theeditor can be used to manually fix the DICOMobject and then resend it to the system where thefailure is occurring. If the store succeeds, chancesare the source of the problem has been identified.

DVT AS A DEVELOPMENT TEST TOOL

Another use of DVT is automated unit or systemtesting in a software development environment.

Most modern source code management systemsinclude automated build-and-test subsystems.Scripts can be created to test the DICOM interfacesof a vendor’s product, and the command line versionof DVT can then be launched to execute those scriptsagainst the product as part of the normal automatedbuild-and-test processes. The DVT results andoutput files can then be saved along with the restof the build/test artifacts. The command line versionof DVT can be called on a DICOMScript as fol-lows: dvtcmd Modality_System_Test.ses Modality_System_Test.ds. The summary and detailed resultsExtensible Markup Language files output by DVTmake it easy for an automated test system todetermine the results of the test, generate a report,and take any other appropriate action, such ase-mailing the development team.A tool as programmable and rich in output as

DVT is valuable to the entire iterative develop-

Fig 8. Multithreaded stress test using VB.NET-main subroutine and imports.


ment process. Software validation teams can linktest session files, scripts, and result files tosoftware defect issues, so that a developer canthen use them to reproduce the defect. A validatorcan subsequently use those same scripts to test thefixed software. Maintaining a repository of DVTscripts is also an excellent way to run regressiontests.If the DICOM software being tested is in the

.NET language family, tighter testing integrationwith DVTk can be achieved via NUnit,4 theopen-source unit testing framework for .NET.This integration uses a DVTkInvoker class toinvoke the command line version of DVT with asession file, script file, and results file as argu-ments. One can use DVT Clients and Serverswithin NUnit to handle the various DICOM SOPClasses, starting and stopping DVT as necessaryand obtaining validation results information. One

future goal is to be able to start up and test anentire workflow scenario from NUnit using DVT.DVTk makes it quick and easy to perform

repeatable, detailed testing of DICOM interfaces.In the following example, we posit a stress test torun against a storage SCP service. Because this is astress test, the test application must hit the SCPsimultaneously from multiple SCUs, so that multi-ple threads will be needed. Writing multithreadedVisual Basic (VB) test applications is a breeze withthe new HLI library. In fact, it looks quite similar toa DICOMScript, with high-level abstractions forcreating and releasing associations and for sendingand receiving messages. This example using theHLI requires DVTk alpha version 2.1.007.006 orgreater , which can be downloaded from dvtk.orgafter registering as a Plus User. Plus Users haveaccess to early releases and draft documents, suchas the draft version of the HLI API help file.

Fig 9. Multithreaded stress test using VB.NET-MainDicomThread class.

58 POTTER ET AL.

Fig 10. Multithreaded stress test using VB.NET-CtStorageScu class.


In Visual Studio .NET, a VB console project iscreated and references to the Dvtk.dll, DvtkData.dll,and DvtkHighLevelInterface.dll libraries are added.This simple stress test application takes three argu-ments: the number of modalities to create (eachmodality runs on a separate thread), the number ofimages each modality will store to the SCP undertest, and the location of the DVTk definition files.Figure 8 shows the imports required and the SubMain(ByVal CmdArgs() As String) routine inmodule Module1. The first operation this applica-tion entry point method performs is to call Dvtk.Setup.Initialize(). This must be performed beforeany calls to the DVTk libraries, matched by the lastcall in the application, which should be Dvtk.Setup.Terminate(). Then it creates and initializes theMainDicomThread object, attaches it to the activitylogging form, starts the main DICOM thread, andfinally waits for the threads to complete. After thethreads are complete, it logs selected performancedata gathered during the stress test.Figure 9 shows the MainDicomThread class that

inherits from the DvtkHighLevelInterface.Dicom.Threads.DicomThread class. A single instance ofthis class is started from the entry point method.This class’s thread execute method starts all of themodalities and returns. As it creates each modality(instances of CtStorageScu), it generates uniqueidentifying information for each SCU, such as AE

title. Some of the options are analogous to testsession properties. This test application could haveloaded a script session configuration file and initial-ized some of the options from it, but in this case, allof the necessary session options are set directly in thecode. After an SCU is created, it is immediatelystarted by calling its thread Start() method.Figure 10 shows a CtStorageScu class that also

inherits from DvtkHighLevelInterface.DICOM.Threads.DICOMThread. The purpose of the exe-cute method is to C-STORE a specified numberof images to the SCP under test. It first createsunique patient, study, and series level identifiersfor the images that will be stored. It then createsthe C-STORE CT Image association; then loopsto store the images, cloning a CT image datasetthat was read from a DICOM CT image file in theconstructor; creates unique image identifiers foreach image; sends the C-STORE-RQ message;receives the response message; and checks theresponse status value. Finally, it logs its totalstorage time for later analysis and closes theassociation. This application could have beencreated and executed from the DVT GUI, butdeveloping it in Visual Studio allows the appli-cation to be debugged and compiled to anexecutable file. This application is executed fromthe command line as: Storage_SCP_Stress_Test.exe 20 1000 “C:\Program Files\DVT\Definitions”.

Fig 11. Multithreaded stress test-activity logging.

60 POTTER ET AL.

Figure 11 is an excerpt from the Hl1Form thatreceives all of the logging from the DicomThreadobjects. Notice the multithreading capabilities ofthe HLI in this output. While modality 10 isvalidating an A-ASSOCIATE-AC message itreceived, modality 3 is handling a CSTORERSPmessage. This test created 20 CT modalities thatare each simultaneously sending a 1,000-imageseries to the PACS.

RECENT EXTENSIONS AND FUTURE WORK

DVTk has been extended recently to supportHL7 validation in addition to DICOM validation.This is currently used by the DVTk Integrating theHealthcare Enterprise (IHE)5 Actors frameworkwhere it is possible to configure DVT to emulatethe role of certain actors in the IHE integrationprofiles. The idea is that the IHE Actors necessaryto allow the SUT to be tested are emulated byDVTk. DVTk will then validate the DICOM andHL7 transactions taking place between actors and,in addition, compare the values of certain attributessuch as Patient ID, Patient Name, etc., betweenmessages to ensure consistent use.In the future, the aim is to enhance the

capabilities of the DVTk IHE Actors frameworkby supporting additional functionality in the exist-ing actors and supporting other actors needed inthe various IHE Integration Profiles. Support forother protocols is also envisioned.The DVTk development team is also involved

in the new IHE Connectathon Toolkit (code-named “Gazelle”), which is being developed as asuccessor to the MESA Toolset. It is hoped thatthe DVTk DICOM validation engine can bewrapped as a Web service for use in Gazelle.Various new tools will be developed using the

DVTk frameworks. A GUI for the DVT-IHEframework; various new emulators, such as aradiology information system emulator and mo-dality emulator; and stand-alone validation appli-cations are likely candidates. The current numberof development resources limits what can be done—anyone wishing to contribute can do so via theWeb site.The aim for future IHE extensions is to integrate

any other validation services into the DVTk

framework as Web services. This may includeCross-Enterprise Document Sharing validation, forexample. It is hoped that the Gazelle cooperationwill result in web services that can be reused forthis purpose.

CONCLUSION

Originally developed by Agfa and Philips to testtheir products, DVTk has grown into a profession-ally managed, open-source, vendor neutral,DICOM Validation Framework. Flexible for thechanging standard, programmable, and extensible,DVTk is a powerful tool for anyone working withthe DICOM standard. The toolkit includes GUIand command line versions of the main validationapplication, DVT, and a collection of .NETlibraries for creating new validation and test tools.The large collection of example validation sessionsthat come with the toolkit are a great place to startfor understanding how the DICOM standard worksin practice.Hospital IT staff can use DVTk for simple tasks,

such as pinging the network for the existence ofmodality AE titles, or for more detailed trouble-shooting, such as checking for the presence ofspecific DICOM attributes and values in messagesand media files. Other DVTk-based tools areavailable for tasks such as editing or comparingDICOM files or for capturing and analyzingmessages on a live DICOM stream. The XML-structured test results and media files created bythe validation framework provide great evidencefor IT staff when discussing a problem withvendors. Developers and testers can create scriptsfor testing their products DICOM conformance, orbuild on the framework by creating new stand-alone test tools. NUnit integration and the com-mand line version of DVT make it possible toincorporate DVTk and the generated test resultsinto automated build-and-test systems.Current and future efforts include support for

IHE actor validation, including HL7 validation, andnew device emulators, such as a Radiology Infor-mation System (RIS) emulator. As the digitalhospital enterprise continues to grow, DVTk is wellpositioned to take on these new validation roles.We encourage the reader to continue working

with DVTk as a means to master the changing


DICOM environment. With the move to an open-source community approach, DVTk is well on itsway to becoming the independent gold standard forDICOM interface testing.

ACKNOWLEDGMENT

I would like to thank Dr. Nancy Knight from the Universityof Maryland for her expert assistance in preparing thismanuscript.

REFERENCES

1. National Electrical Manufacturers Association (NEMA).DICOM standard is available at http://medical.nema.org (lastaccessed May 2007)

2. Bidgood Jr, WD, Horii SC, Prior FW, Van Syckle DE:Understanding and using DICOM, the data interchange stan-dard for biomedical imaging. JAMIA 4:199–212, 1997

3. HL7, Health Level Seven, http://www.hl7.org/ (lastaccessed May 2007)

4. NUnit, “NUnit is a unit-testing framework for all .Netlanguages”, nunit.com, (last accessed May 2007)

5. IHE, Integrating the Healthcare Enterprise, http://www.ihe.net/ (last accessed May 2007)

62 POTTER ET AL.

http://medical.nema.orghttp://www.hl7.org/http://www.ihe.net/http://www.ihe.net/

Mastering DICOM with DVTkAbstractINTRODUCTIONDVTk HISTORY AND ARCHITECTUREGETTING STARTED WITH DVTk OUT OF THE BOXDVTk FOR SERVICE TROUBLESHOOTINGDVT AS A DEVELOPMENT TEST TOOLRECENT EXTENSIONS AND FUTURE WORKCONCLUSIONReferences

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /Warning /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 150 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 600 /MonoImageMinResolutionPolicy /Warning /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/Description >>> setdistillerparams> setpagedevice

mastering dicom with dvtk · mastering dicom with dvtk glenn potter,1 rick busbridge,1 michael...

Documents