DICOM Multi-tool is a highly configurable multi-role DIPACS agent, capable of filling many SCU and SCP roles, including find, store, worklist and MPPS.
Able to act in mix of SCU and SCP contexts, including store, find, worklist and MPPS.
Highly extensible TCP, pipe or file-based XML interface can be used by applications, scripts and devices.
Rock-solid code can be left unattended even in the most demanding applications.
General Features
DMT is really simple to integrate into your workflow.
Can be given a set of use-cases via an XML file, through STDIN, or by a TCP request.
Once started, DMT exchanges information either through STDIN/OUT, or via TCP (and DICOM of course!).
Can quit after a single-use, or remain operational, providing uninterrupted DICOM services.
DMT Explained
DMT is a multi-purposed DICOM engine. It was originally written to provide functionality for specific medical devices, but has been authored in such a way that it can be used in a variety of contexts, including Query, Store, Move, and Worklist in both SCU and SCP roles.
The following is a largely technical discussion of the DMT use model. We understand that this kind of reading is not for the faint of heart, so we suggest that you either have a PACS person handy, are one yourself, or contact us so we can field any questions directly.
Interface Design
DMT provides both a server and client application. Although these are separate, with significantly different use-case models, they share the same governor for user interface task communication.
Communication between users and DMT is conducted using the following messages:
- Requests, which are created by a user and sent, using one several available channels, to DMT instances,
- Responses which are sent by DMT instances.
A sample QUERY request:
<Request version="0.0.1">
<Command>START QueryScu</Command>
<Arguments>
<QueryScuParameters>
<ConnectionParameters>
<MyAeTitle>DMT_AE</MyAeTitle>
<PeerAeTitle>PACS</PeerAeTitle>
<HostAddress>10.10.16.2</HostAddress>
<Port>104</Port>
</ConnectionParameters>
<Type>PATIENT</Type>
<Level>PATIENT</Level>
<Identifier>
<Dataset>
<Tag element="0020" group="0010"></Tag>
<Tag encoding="Base64" element="0010" group="0010">PATIENTID12345</Tag>
</Dataset>
</Identifier>
</QueryScuParameters>
</Arguments>
<ExpirationTime>2012-11-14T14:57:18</ExpirationTime>
<Uuid>635cda2e-6073-4739-8934-5a424f118b00</Uuid>
</Request>
Message Exchange Pattern
A variation of a standard request-response pattern is used, where for one client request, there are one or more responses.
To avoid mismatching responses during multiple request transmission, every request has a Universally Unique Identifier (UUID), appended to respective responses.
Message Types
The following description lists defined message types used during transmission.
- Request
- A call sent by a client application. Specifies a _Command_ to be executed and, optionally, its arguments.
- ACK
- Response having _Status_ code equal to the `ACK` and _Data_ element containing a _data channel_ indicator. Issued right after DMT receives a _Request_.
- Response
- A reply with _Status_ code equal to `PENDING`. Contains a result of an operation but also indicates that there are more results to come.
- Final Response
- Has _Status_ code `FINISHED`. Marks the end of a message exchange process.
- Error
- Has _Status_ code `ERROR`. Marks the end of message exchange process as well.
Communication Channels
The DMT governor interface is accessible through:
- standard input and output, aka. the Console Communication Channel, and
- TCP/IP ports specified by command-line options (-control-port, -response-port-range) which, combined, describe Network Communication Channel properties.
Console Communication Channel
A typical way of passing on messages between a user and DMT. The former employs STDIN to send requests and the latter replies using STDOUT.
Please note that this mode of message transmission should only be used when running single instances of DMT. Although it is enabled for the Server as well, as a consequence of its service-based character, it can be used there only during testing.
Network Communication Channel
A TCP/IP based channel. Allows for connecting multiple clients to one instance of DMT. Implemented similarly to a passive FTP session. Communication can be depicted using the following schema (assuming command line parameters: -request-port 3000 -response-ports-range [4000,4010]):
1. (3000) → _Request_
2. (3000) ← _ACK_, containing chosen response port number: 4005
3. (4005) ← _Response_
4. ⋮
5. (4005) ← _Final Response_
List of Command-line Options
All command line parameters should be passed using a
| Switch | Type | Description | Default |
|---|---|---|---|
| -log-mode | unsigned byte | One of enumerated values controlling verbosity of logs. In ascending order: 3, 7, 15, 31 | 7 |
| -control-port | unsigned short | TCP/IP port on which a tool should be listening for incoming requests (Server only). | |
| -response-ports-range | unsigned short interval | A set of TCP/IP port numbers, given by the endpoints in ISO notation, from which a tool will randomly choose a value and use it to send responses when using the Network Communication Channel (Server only). | |
| -communication-channel | string | Label of the communication channel to use, either NETWORK or CONSOLE (Server only). |
NETWORK |
| -exec | Executes a Server like a normal, standalone application, not a service. | ||
| -install | Installs Server as a Windows service. | ||
| -uninstall | Uninstalls Server from Windows service list. |
Messages Structure
Message structure must follow the following general schema for both requests and responses. The sample Query request above can be used as a reference for how this schema is implemented in practise.
Request
<!ELEMENT Request ((Command),(Arguments?),(ExpirationTime),(Uuid))>
<!ATTLIST Request version (0.0.1) #REQUIRED >
<!ELEMENT Command (#PCDATA)>
<!ELEMENT Arguments (#PCDATA)>
<!ELEMENT ExpirationTime (#PCDATA)>
<!ELEMENT Uuid (#PCDATA)>
Response
<!ELEMENT Response ((Status),(Message?),(Data),(RequestUuid))>
<!ATTLIST Response version (0.0.1) #REQUIRED >
<!ELEMENT Status (#PCDATA)>
<!ELEMENT Message (#PCDATA)>
<!ELEMENT Data (#PCDATA)>
<!ELEMENT RequestUuid (#PCDATA)>
Obtaining an Evaluation Copy
DICOM Multi-Tool can only be obtained by request. Please contact us and we’ll be happy to provide you with a binary and assistance with getting it implemented.